MÉTODO DE COMPOSICIÓN DE CAMBIOS DE CONFIGURACIÓN EN UN ELEMENTO DE RED.

Método de composición de cambios de configuración en un elemento de red.

Un método para componer cambios de configuración para ser aplicados a un elemento de red (41) de forma distribuida. El método comprende las etapas de: en un primer servidor (42), generar un fichero de configuración y señalizar el contenido de dicho fichero de configuración al elemento de red (41); de acuerdo con el contenido de dicho fichero de configuración, ponerse en contacto dicho elemento de red (41) con una pluralidad de servidores de apoyo (43, 44, 45) y descargar de cada uno de dichos servidores de apoyo (43, 44, 45) trozos parciales de los cambios de configuración para ser aplicados a un elemento de red (41); combinar dichos trozos parciales de cambios de configuración en dicho elemento de red (41), obteniendo así un conjunto de cambios de configuración resultantes; aplicar en dicho elemento de red (41) dicho conjunto de cambios de configuración resultantes.

Método de composición de cambios de configuración en un elemento de red

CAMPO DE LA INVENCIÓN

La presente invención pertenece al campo de la gestión de red. En particular, se relaciona con la configuración remota de equipos de red.

ESTADO DE LA TÉCNICA

La Gestión de Red (en ingles, Network Management) ha dependido tradicionalmente de un Sistema de Gestión de Red (del inglés, Network Management System (NMS) ) , externo a los dispositivos de red en sí mismo, para realizar toda la lógica requerida para producir la configuración para todos y cada uno de los dispositivos de la red que se va a gestionar. La participación de los dispositivos de red en el proceso de gestión de la red se ha limitado a que estos dispositivos han sido capaces de recibir y aplicar grandes cantidades de datos de configuración dirigidos por el NMS. La figura 1 muestra el esquema típico de configuración remota de equipos de red, en la que el NMS crea la lógica de configuración y la envía al equipo de red (en inglés, network equipment (NE) ) . En particular, en primer lugar el NMS solicita información de configuración del equipo de red. A continuación, el equipo de red devuelve información de configuración al usuario de gestión en función de esa petición. A continuación, después de obtener la información de gestión, el NMS complete el procesado lógico de la configuración en un cliente y determina si la configuración puede ser entregada o no en función de un resultado de procesado. Y finalmente, el NMS entrega el resultado del procesado lógico de la configuración al equipo de red.

El proceso de construcción de la lógica de configuración para el equipo de red ha evolucionado, de forma que se ha ido añadiendo más inteligencia al equipo de red. El NMS, en vez de enviar toda la lógica de configuración al equipo de red, es capaz remotamente de enviar comandos y parámetros al equipo de red y el equipo de red ejecuta esos comandos, proporcionando el resultado de esa ejecución al NMS. Esto permite la ejecución remota de operaciones indivisibles en el equipo de red. Existen distintos modos de abordar esta ejecución remota de operaciones:

-Interfaces de Línea de Comandos Propietarias (del inglés Proprietar y Command Line

Interfaces (CLI) )

-Protocolo de Gestión de Red Simple (del inglés Simple Network Management Protocol

(SNMP) )

-Protocolo de configuración NETCONF

Una Interfaz de Línea de Comando (CLI) es un mecanismo para interactuar con un dispositivo electrónico mediante el tecleo de comandos para realizar tareas. Cada proveedor (vendor) tiene su CLI propietario, que consiste en un lenguaje propio para especificar cualquier comando de configuración a los dispositivos de red. Por ejemplo, CISCO tiene su Cisco Command Line Interface (http://www.cisco.com/warp/cpropub/45/tutorial.htm, last visit, 11-Nov-2010) .

Algo común a todos los dispositivos es que los comandos de configuración se organizan en el CLI en un “árbol de configuración” propietario. El NMS típicamente usa una conexión Telnet o SSH para ganar acceso al dispositivo de red remoto y después ejecuta los comandos CLI.

El protocolo SNMP (RFC 1157, A Simple Network Management Protocol. http://tools.ietf.org/html/rfc1157, Last visit, 11Nov-2010) fue un intento de unificar la configuración remota del equipo de red. Básicamente proporciona dos métodos de configuración de un dispositivo (“get” para leer la información de configuración del dispositivo, y “set” para escribir parámetros de configuración dentro del dispositivo) . Cada parámetro de configuración tiene un identificador específico, recogido en una Base de Información de Gestión (del inglés Management Information Base (MIB) ) , que debe ser conocida por el NMS y por el equipo de red. Las MIBs están pensadas para ser genéricas para todos los dispositivos; sin embargo, la situación real es que hay una carencia de un modelo de datos unificados para las diferentes, variadas y a menudo propietarias funcionalidades que implementan los dispositivos de red. Esto ha hecho que sean los CLIs proporcionados por los dispositivos de red la opción preferida para el propósito de proporcionar datos de configuración desde el NMS hacia los dispositivos de red sobre los protocolos de gestión como el SNMP (aunque usado para monitorización de rendimiento y alarmas) .

En 2006 el IETF estandarizó un nuevo protocolo para la configuración de dispositivos de red, NETCONF (RFC 4741, NETCONF Configuration Protocol. http://tools.ietf.org/html/rfc4741, December 2006. Last visit, 11-Nov-2010) . NETCONF usa datos basados en XML y una capa de Llamada de Procedimiento Remota (del inglés, Remote Procedure Call (RPC) ) para invocar métodos que residen en el dispositivo de red. El NMS trabaja como un cliente de NETCONF que invoca métodos en los dispositivos de red (el servidor NETCONF) . Este modelo disocia el protocolo de gestión (NETCONF) de los métodos implementados por el dispositivo de red. Los métodos ya no se restringen a operaciones “get” o “set” como en SNMP, sino que se programan y almacenan en el dispositivo de red y se invocan remotamente desde el cliente NETCONF. Ya existen proveedores de red que proporcionan soporte NETCONF (por ejemplo la funcionalidad JunoScript disponible en los encaminadores de Juniper Networks, JUNOScript API. http://www.juniper.net/support/products/junoscript/ Last visit, 11-Nov-2010) . En el caso de Juniper, el soporte NETCONF sigue el mismo curso que capacidades abiertas de programación y procesado en el dispositivo de red, de forma que el operador de red puede distribuir sus propios métodos al dispositivo de red.

De forma similar a NETCONF, Huawei tiene una solicitud de patente, US 2010/0049837 A1, en la que el equipo de red recibe un identificador de una plantilla de configuración (del inglés configuration template) para ser llamado y parámetros de configuración. El equipo de red llama a una plantilla de configuración que está pre-almacenada localmente e identificada por el identificador de la plantilla de configuración, y pone los parámetros de configuración en la plantilla de configuración, de forma que el equipo de red es configurado. Este proceso se puede ver en la figura 2, extraída de la mencionada solicitud de patente, que muestra el organigrama esquemático de un método de configuración de equipo de red de acuerdo con una realización de esa solicitud de patente. En particular, en primer lugar el equipo de red recibe la información de configuración. A continuación, el equipo de red encuentra localmente una plantilla de configuración para ser llamada de acuerdo con un identificador de plantilla de configuración de la información de configuración. Por último, el equipo de red llama a la plantilla de configuración y pone los parámetros de configuración en la plantilla de configuración para configurar el equipo de red.

Con respecto a esa solicitud de patente, es necesario clarificar que el NMS solo proporciona un identificador de plantilla. Las plantillas de configuración se almacenan en local en el dispositivo de red y no se proporcionan por el NMS, como puede verse en la figura 3, extraída de la misma solicitud de patente mencionada. En particular, el sistema de gestión del equipo de red NMS tiene una unidad de entrega de información de configuración y una unidad de entrega de plantilla de configuración; y el equipo de red tiene una unidad receptora, una unidad de almacenamiento de plantilla y una unidad de configuración.

Todos los métodos mencionados previamente para la configuración remota se basan en un modelo controlado por el sistema (del inglés push model) , es decir, la iniciativa para aplicar cambios de configuración al equipo de red reside en el NMS, y el NMS indica explícitamente los comandos y parámetros de configuración que deben aplicarse al equipo de red.

Existen otros mecanismos diferentes para la configuración remota basada en un modelo controlado por el cliente (del inglés, pull model) .

Estos mecanismos se conocen comúnmente como métodos de auto-configuración. Ejemplos de estos métodos son el Protocolo de Configuración de Host Dinámico (del inglés, Dynamic Host Configuration Protocol (DHCP) ) (RFC2131 Dynamic Host Configuration Protocol. http://tools.ietf.org/html/rfc2131, March 1997. Last visit, 11-Nov-2010) and y el Protocolo Bootstrap (del inglés, Bootstrap Protocol (BOOTP) ) (RFC 951 Bootstrap Protocol. http://tools.ietf.org/html/rfc0951, September 1985. Last visit, 11-Nov-2010) .

En ambos protocolos, el dispositivo de red (cliente) solicita parámetros de configuración a una dirección de broadcast, y el NMS (servidor) los proporciona. Típicamente...

1. Un método para componer cambios de configuración para ser aplicados a un elemento de red (41) de forma distribuida, donde el método está caracterizado por que comprende las etapas de:

- en un primer servidor (42) , generar un fichero de configuración y señalizar el contenido de dicho fichero de configuración al elemento de red (41) ; -de acuerdo con el contenido de dicho fichero de configuración, ponerse en contacto dicho elemento de red (41) con una pluralidad de servidores de apoyo (43 44 45) y descargar de cada uno de dichos servidores de apoyo (43 44 45) trozos parciales de los cambios de configuración para ser aplicados al elemento de red (41) ; -combinar dichos trozos parciales de cambios de configuración en dicho elemento de red (41) , obteniendo así un conjunto de cambios de configuración resultantes; -aplicar en dicho elemento de red (41) dicho conjunto de cambios de configuración resultantes.

2. El método de la reivindicación 1, donde dicha etapa de señalizar un fichero de configuración al elemento de red (41) es o bien desencadenada por el propio elemento de red solicitando su configuración a dicho primer servidor, o bien determinada y desencadenada por una lógica de configuración de acuerdo con un Sistema de Gestión de Red.

3. El método de cualquiera de las reivindicaciones anteriores, donde dicho fichero de configuración comprende un conjunto de URLs para plantillas de configuración y datos de configuración, donde dichos URLs de plantillas de configuración incluyen comandos de configuración con referencias a variables y los URLs de datos de configuración definen valores para las variables referenciadas en las plantillas de configuración.

4. El método de la reivindicación 3, donde dicho fichero de configuración se configura para identificar un punto de anclaje para cada plantilla en el árbol de configuración del elemento de red (41) .

5. El método de cualquiera de las reivindicaciones 3 ó 4, donde dicho fichero de configuración se configura para permitir al elemento de red (41) descargar las plantillas y los datos de configuración especificados en los URLs desde dicha pluralidad de servidores de apoyo (43 44 45) .

6. El método de cualquiera de las reivindicaciones 3 a 5, donde dicho fichero de configuración se configura para permitir al elemento de red (41) producir su propio conjunto completo de cambios de configuración mediante la combinación de plantillas en sus correspondientes puntos de anclaje con los datos de configuración.

7. Un sistema que comprende un primer servidor (42) , un elemento de red (41) y una pluralidad de servidores de apoyo (43 44 45) , donde dicho sistema está configurado para llevar a cabo las etapas del método de cualquiera de las reivindicaciones anteriores.

8. Un programa informático que comprende medios de código de programa informático adaptados para realizar las etapas del método según cualquiera de las reivindicaciones de la 1 a la 6, cuando dicho programa se ejecuta en un ordenador, un procesador de señal digital, una disposición de puertas de campo programable, un circuito integrado de aplicación específica, un microprocesador, un microcontrolador, y cualquier otra forma de hardware programable.