El Protocolo de Configuración de Red (NETCONF) es un protocolo de administración de red desarrollado y estandarizado por el IETF. Fue desarrollado en el grupo de trabajo NETCONF y publicado en diciembre de 2006 en el RFC 4741 y luego revisado en junio de 2011 y publicado en el [rfc:6241 RFC 6241.][1] La especificación de protocolo NETCONF es un documento del grupo de Estándares de Internet .
NETCONF proporciona mecanismos para instalar, manipular y eliminar la configuración de dispositivos de red. Sus operaciones se ejecutan sobre una capa sencilla de Llamada de Procedimiento Remota (RPC). El protocolo NETCONF utiliza codificación de datos basados en Extensible Markup Language (XML) para la configuración de datos así como el protocolo de mensajes. Los mensajes de protocolo se intercambian sobre un protocolo de transporte seguro.
El protocolo NETCONF puede ser conceptualmente separado en cuatro capas:
- La capa de Contenido consta de datos de configuración y datos de notificación.
- La capa de Operaciones define un conjunto de operaciones base para recuperar y editar los datos de configuración.
- La capa de Mensajes proporciona un mecanismo para codificar llamadas de procedimiento remoto (RPCs) y notificaciones.
- La capa de Transporte Segura proporciona un transporte seguro y confiable de los mensajes entre un cliente y un servidor.
El protocolo NETCONF ha sido implementado en dispositivos de red como routers y switches por algunos vendedores de equipamiento importantes. Una fortaleza particular de NETCONF es su soporte para cambios de configuración robustas que utilizan transacciones que implican una cantidad de dispositivos.
Historia
El IETF desarrolló el Protocolo de Administración de Red Sencillo (SNMP) a fines de los 80s y resultó ser un protocolo de administración de red muy popular. En la parte temprana del siglo XXI se hace aparente que a pesar de lo que se intentó originalmente, SNMP no estaba siendo utilizado para configurar equipamiento de red, sino que principalmente era utilizado para monitoreo de red. En junio del 2002, el Directorio de Arquitectura del Internet y algunos miembros claves de la comunidad de administración de red del IETF se reunieron con operadores de red para discutir la situación. Los resultados de esta reunión se documentaron en [rfc:3535 RFC 3535.] Resultó que los operadores principalmente utilizaban Interfaces de Línea de Orden propietarias (CLI) para configurar sus dispositivos. Esto tenía una cantidad de características que a los operadores les gustaba, incluyendo el hecho que estaba basado en texto, en oposición al SNMP que estaba codificado en BER. Además, muchos vendedores de equipamiento no proporcionaban la opción para configurar completamente sus dispositivos vía SNMP. Aun cuando a los operadores generalmente les gustaba escribir scripts para facilitar la configuración de sus cajas, encontraban que el CLI SNMP era insuficiente en varios temas. Aún más importante era la naturaleza imprevisible del resultado. El contenido y formato del resultado era propenso a cambiar de maneras imprevisibles.
Más o menos al mismo tiempo, Juniper Networks había tomado una aproximación de administración de red utilizando XML. Esto se compartió con IETF y luego se compartió con el resto de la comunidad. En conjunto, estos dos acontecimientos dirigieron el IETF en mayo de 2003 a la creación del NETCONF grupo laborable. Este grupo de trabajo fue comisionado para trabajar en un protocolo de configuración de la red, el cual alineara mejor las necesidades de los operadores de red y de los vendedores de equipamiento. La primera versión del protocolo base de NETCONF fue publicado como RFC 4741 en diciembre de 2006. Varias extensiones se publicaron en años subsiguientes (notificaciones en RFC 5277 en julio del 2008, cierres parciales en RFC 5717 en diciembre del 2009, valores por defecto en RFC 6243 en junio del 2011, notificaciones de sistema en RFC 6470 en febrero del 2012, control de acceso en RFC 6536 en marzo de 2012). Una versión revisada del protocolo base de NETCONF fue publicado como RFC 6241 en junio de 2011.
Capas de protocolo
Contenido
El contenido de las operaciones de NETCONF es un XML bien formado. La mayoría de contenido está relacionado con administración de red. Posteriormente se agregó soporte para codificar en Notación de Objeto del Javascript (JSON) también.
El grupo de trabajo NETMOD ha completado trabajo para definir un lenguaje de modelamiento "amistoso para el humano" para definir la semántica de datos operacionales, datos de configuración, notificaciones y operaciones, llamado YANG. YANG está definido en RFC 6020 (versión 1) y RFC 7950 (versión 1.1), y está acompañado por el "Tipos de Datos comunes YANG" definidos en RFC 6991.
Durante el verano de 2010, el grupo de trabajo NETMOD fue re-comisionado para trabajar en modelos de configuración del núcleo (sistema, interfaz, y encaminamiento) así como trabajar en compatibilidad con el lenguaje de modelamiento SNMP.
Operaciones
El protocolo de base define las operaciones de protocolo siguientes:
| Operación | Descripción |
|---|---|
| <get> | Recupera la configuración activa y la información del estado del dispositivo |
| <get-config> | Recupera todo o parte de los datos de una configuración especificada |
| <Edit-config> | Editar una configuración de datos al crear, eliminar, fusionar o reemplazar contenido |
| <Copy-config> | Copia una configuración entera a otra configuración |
| <delete-config> | Eliminar los datos de una configuración |
| <lock> | Bloquea los datos de una configuración entera de un dispositivo |
| <unlock> | Liberación de datos de configuración anteriormente obtenidos con la operación <lock> |
| <close-session> | Pedir la terminación correcta de una sesión NETCONF |
| <kill-session> | Fuerza la terminación de una sesión NETCONF |
La funcionalidad básica de NETCONF puede ser extendida por la definición de capacidades NETCONF. El conjunto de funcionalidades adicionales que son soportados en una implementación se comunica entre el servidor y el cliente durante la porción de intercambio de la capacidad de la puesta en marcha de la sesión. Las características obligatorias del protocolo obligatorio no se incluyen en el intercambio de capacidad ya que se asumen presentes. ElRFC 4741 define un número de las capacidades opcionales que incluyen :xpath y :validate. Es necesario notar que el RFC 6241 deja obsoleto el RFC 4741.
Una capacidad para permitir suscribir y recibir notificaciones de eventos asíncronos fue publicada en [rfc:5277 RFC 5277.] Este documento define la operación <crear-suscripción> (<create-subscription>), el cual habilita crear suscripciones en tiempo-real y de replay. Las notificaciones son enviadas en forma asincrónica utilizando el constructo <notificación> (<notification>). También define la capacidad :interleave, la cual facilita la modificación de la subscripción al permitir el procesamiento de otras operaciones NETCONF mientras la suscripción está activa.
Una capacidad para permitir el bloqueo parcial de la configuración en uso está definida en [rfc:5717 RFC 5717.] Esto permite que múltiples sesiones editen subárboles no superpuestos dentro de la configuración en uso. Sin esta capacidad, la única posibilidad de bloqueo sería bloquear toda la configuración.
Una capacidad para controlar el protocolo NETCONF está definido en [rfc:6022 RFC 6022.] Este documento contiene un modelo de datos que incluye información sobre los registros de datos NETCONF, sesiones, bloqueos, y estadísticas que facilita la administración de un servidor NETCONF. También define métodos para clientes NETCONF para descubrir modelos de datos soportados por un servidor NETCONF y define la operación <get-schema> para recuperarles.
Mensajes
La capa de mensajes de NETCONF proporciona un mecanismo marco sencillo, independiente del transporte para codificar
- Invocaciones RPC (mensajes <rpc>),
- Resultados RPC (mensajes <rpc-reply>), y
- Notificaciones de acontecimiento (mensajes de <notificación>).
Cada mensaje NETCONF es un documento XML bien-formado. Un resultado RPC está enlazado a una invocación RPC por un atributo id-mensaje. Los mensajes NETCONF pueden ser ejecutados en serie, i.e., un cliente puede invocar múltiple RPCs sin tener que esperar los mensajes de resultado RPC primero. Los mensajes RPC están definidos en RFC 6241 y los mensajes de notificación están definidos en RFC 5277.
Véase también
Referencias
| Control de autoridades |
|
|---|
Datos: Q4044832