ES2429219A1 - Método de composición de cambios de configuración en un elemento de red - Google Patents

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

Info

Publication number
ES2429219A1
ES2429219A1 ES201130725A ES201130725A ES2429219A1 ES 2429219 A1 ES2429219 A1 ES 2429219A1 ES 201130725 A ES201130725 A ES 201130725A ES 201130725 A ES201130725 A ES 201130725A ES 2429219 A1 ES2429219 A1 ES 2429219A1
Authority
ES
Spain
Prior art keywords
configuration
network element
network
file
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
ES201130725A
Other languages
English (en)
Other versions
ES2429219B1 (es
Inventor
Rafael Alejandro LÓPEZ DA SILVA
Gerardo GARCÍA DE BLAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Priority to ES201130725A priority Critical patent/ES2429219B1/es
Priority to US14/115,993 priority patent/US20140156816A1/en
Priority to BR112013028676A priority patent/BR112013028676A2/pt
Priority to PCT/EP2012/058330 priority patent/WO2012152736A1/en
Priority to EP12719007.2A priority patent/EP2705630A1/en
Publication of ES2429219A1 publication Critical patent/ES2429219A1/es
Application granted granted Critical
Publication of ES2429219B1 publication Critical patent/ES2429219B1/es
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
    • H04L41/0843—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on generic templates

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

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.

Description

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 Proprietary 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 ambos protocolos se usan para obtener una dirección IP y una imagen de configuración remota. Además, estos protocolos tienen opciones extendidas para solicitar otros parámetros de configuración (RFC 2132 DHCP Options and BOOTP Vendor Extensions. http://tools.ietf.org/html/rfc2132, March 1997. Last visit, 11-Nov-2010; RFC 3046 DHCP Relay Agent Information Option. http://tools.ietf.org/html/rfc3046, March 1997. Last visit, 11-Nov-2010; RFC 3004 The User Class Option for DHCP. http://tools.ietf.org/html/rfc3004, March 1997. Last visit, 11-Nov-2010; Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters. http://www.iana.org/assignements/bootp-dhcp-parameters/. Last visit, 11-Nov-2010.).
La lista de parámetros de configuración, aunque suficientemente amplia para entornos de empresa y hogares, no es lo suficientemente extensa ni flexible como para soportar el rango total de parámetros de configuración necesarios para los equipos de los operadores de red. De hecho, la red de los operadores no usa protocolos como DHCP o BOOTP para conseguir parte de su configuración, tal y como se hace en entornos de empresas y hogares. El enfoque en la red de los operadores es un modelo controlado por el sistema (push model) en el que el NMS tiene que saber del equipo antes de conectarse a la red, y, una vez que se ha conectado, se requiere de intervención humana para comprobar que la instalación se ha realizado como se esperaba por el NMS y entonces permitir al NMS que proceda a configurar el equipo.
Sin embargo, las tecnologías existentes de configuración de red solo permiten procedimientos en los que los cambios de configuración que se van a aplicar al elemento de red en una operación de configuración indivisible estén totalmente comunicados al elemento de red por un único sistema, el NMS. Esto es de aplicación a los cambios de configuración que resultan de tanto procedimientos de tecnologías pull (del inglés BOOTP/TFTP procedures) como de procedimientos push (NETCONF, SNMP, configuración CLI).
No hay una solución técnica que habilite la composición de cambios de configuración para ser aplicados al elemento de red en una operación de configuración indivisible de una forma distribuida.
RESUMEN DE LA INVENCIÓN
La presente invención trata de resolver los inconvenientes mencionados arriba mediante un procedimiento para la composición distribuida de los cambios de configuración que deben aplicarse a un nodo de red en cooperación con el propio nodo de red.
El procedimiento se lleva a cabo por varias entidades que cooperan. Las entidades involucradas son: un primer servidor (o servidor de configuración de disparo (del inglés triggering configuration server)); el equipo de red; y varios servidores adicionales(o servidores de configuración de apoyo (del inglés supporting configuration servers)).
Para habilitar la composición distribuida del conjunto final de cambios de configuración, las entidades involucradas en el procedimiento intercambian un nuevo tipo de fichero de configuración. En una realización particular, este fichero de configuración se llama metaconf.
En un primer aspecto de la presente invención, se proporciona un método para componer cambios de configuración para ser aplicados a un elemento de red de forma distribuida. El método comprende las etapas de: en un primer servidor, generar un fichero de configuración y señalizar el contenido de dicho fichero de configuración al elemento de red; de acuerdo con el contenido de dicho fichero de configuración, ponerse en contacto dicho elemento de red con una pluralidad de servidores de apoyo y descargar de cada uno de dichos servidores de apoyo trozos parciales de los cambios de configuración para ser aplicados a un elemento de red; combinar dichos trozos parciales de cambios de configuración en dicho elemento de red, obteniendo así un conjunto de cambios de configuración resultantes; aplicar en dicho elemento de red dicho conjunto de cambios de configuración resultantes.
La etapa de señalizar un fichero de configuración al elemento de red es o bien desencadenada por el propio elemento de red solicitando su configuración a dicho primer servidor (modelo pull o en inglés, pull model), o bien determinada y desencadenada por una lógica de configuración de acuerdo con un Sistema de Gestión de Red (NMS) (modelo push o en inglés, push model).
El 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.
En ese caso, el fichero de configuración se configura preferentemente para identificar un punto de anclaje para cada plantilla en el árbol de configuración del elemento de red.
El fichero de configuración se configura para permitir al elemento de red descargar las plantillas y los datos de configuración especificados en los URLs desde dicha pluralidad de servidores de apoyo.
El fichero de configuración se configura preferentemente para permitir al elemento de red 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.
En otro aspecto de la presente invención, se proporciona un sistema que comprende un primer servidor, un elemento de red y una pluralidad de servidores de apoyo, donde dicho sistema está configurado para llevar a cabo las etapas del método descrito anteriormente.
Por último, la invención proporciona un programa informático que comprende medios de código de programa informático adaptados para realizar las etapas del método descrito anteriormente, 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.
En resumen, la invención proporciona un procedimiento para la composición distribuida de los cambios de configuración para ser aplicados a un nodo de red en una operación de configuración indivisible en cooperación con el propio nodo de red y la puesta a punto automática (self commission) de los cambios de configuración resultantes por el nodo de red. Otras ventajas adicionales de la invención se desprenderán a la vista de la siguiente descripción.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para completar la descripción y con objeto de ayudar a comprender mejor la invención, se proporciona un conjunto de dibujos. Dichos dibujos forman parte integrante de la descripción e ilustran realizaciones preferidas de la invención, lo cual no debe interpretarse de forma restrictiva del alcance de la invención, sino más bien como ejemplos de cómo la invención puede implementarse. Los dibujos comprenden las siguientes figuras:
La figura 1 muestra un esquema típico de configuración de red remota donde el NMS crea la lógica de configuración y la envía al equipo de red.
La figura 2 muestra un diagrama de flujo esquemático de un método de configuración de equipo de red convencional.
La figura 3 muestra una vista estructural esquemática de un equipo de red convencional.
La figura 4 muestra un esquema de una configuración de red sobre la cual se implementa el método inventivo.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
A lo largo de este texto, el término “comprende” y sus derivados no debe interpretarse en un sentido excluyente o
limitativo, es decir, no debe interpretarse en el sentido de excluir la posibilidad de que el elemento o concepto al que se refiere incluya elementos o etapas adicionales.
A continuación, se proporcionan realizaciones preferidas de la invención. Estas realizaciones preferidas se ofrecen de forma ilustrativa y no se pretende que se consideren limitaciones a la presente invención. Además, la presente invención cubre todas las posibles combinaciones de las realizaciones particulares y preferidas aquí indicadas. Los expertos en la materia entenderán que otros objetivos, ventajas y características de la invención se derivan en parte de la descripción y en parte de la implementación práctica de la invención.
El método inventivo se describe a continuación. Permite la composición distribuida de los cambios de configuración que se deben aplicar a un elemento de red en una operación indivisible y su puesta a punto automática (self-commission) por el elemento de red.
La figura 4 muestra un elemento de red (NE) 41, un primer servidor 42, también llamado servidor de desencadenamiento de configuración (en inglés, triggering configuration server), y una pluralidad de servidores adicionales 43 44 45, también llamados servidores de apoyo a la configuración (en inglés, supporting configuration servers). En la ilustración particular de la figura 4, se muestran tres servidores adicionales 43 44 45, pero puede haber un número mayor o menor de de servidores adicionales.
La composición y puesta a punto automática (en inglés, self commission) de los cambios de configuración se realiza de acuerdo con el esquema general que se indica a continuación:
-
En primer lugar, el primer servidor 42 (o servidor de desencadenamiento de configuración) señaliza al elemento de red 41 un fichero de configuración intermedio. En una realización particular, este fichero de configuración se llama metaconf. Esto se representa en la etapa o paso 1. Este fichero de configuración es utilizado por ciertas líneas de comando de aplicaciones, scripts o programas ejecutables.
-
Con la información del fichero de configuración (metaconf), el elemento de red 41 se pone en contacto con varios servidores de apoyo adicionales (servidores de apoyo a la configuración) 43 44 45 y descarga desde cada servidor 43 44 45 trozos parciales de los cambios de configuración que se deben aplicar. Esto se representa en las etapas o pasos 2, 2’, 2’’.
-
La información del fichero de configuración (metaconf) permite al elemento de red 41 combinar los trozos parciales de los cambios de configuración que se deben aplicar, en un conjunto completo de cambios de configuración que deben aplicarse al elemento de red 41 en una operación indivisible. Esto se representa en la etapa o paso 3.
-
El propio elemento de red 41 aplica el conjunto completo de cambios de configuración resultantes en una operación de configuración indivisible. Esto se representa en la figura 4 en la etapa 4 o paso.
Evento de desencadenamiento (Triggering event) El evento de desencadenamiento para el procedimiento de configuración, llevado a cabo por el primer servidor 42
(servidor de desencadenamiento de configuración o triggering configuration server) queda fuera del ámbito de la invención. Puede ser cualquier clase de evento de autoconfiguración (en inglés, pull event) (por ejemplo un procedimiento BOOTP o puede ser desencadenado como parte de la lógica de negocio de un sistema de gestión de red.
Generación del fichero de configuración (por ejemplo, generación de Metaconf) Esta invención define un nuevo fichero de configuración (llamado metaconf) que se construye y señaliza al elemento de red 41 por el servidor de desencadenamiento de la configuración (en inglés triggering configuration server) 42 y que proporciona las siguientes características:
-
Está compuesto por un conjunto de URLs (Localizadores de Recurso Uniformes, en inglés Uniform Resource Locator) para plantillas de configuración y datos de configuración. Los URLs de las plantillas de configuración incluyen comandos de configuración con referencias a variables. Los URLs de los datos de configuración definen valores para las variables referenciadas en las plantillas de configuración.
-
Identifica el punto de anclaje de cada plantilla en el árbol de configuración del elemento de red 41.
-
Permite al elemento de red 41 descargar las plantillas y los datos de configuración especificados en los URLs desde diversos servidores de apoyo a la configuración 41 42 43, diferente del servidor de desencadenamiento de la configuración 42 que proporcionaba el fichero de configuración (metaconf) al elemento de red 41, y haciendo uso del protocolo apropiado tal y como señalizaba en el URL.
-
Permite al elemento de red 41 producir su propio conjunto completo de cambios de configuración mediante la combinación de plantillas, en su punto de anclaje correspondiente, con los datos de configuración.
-
El fichero de configuración syntax (Metaconf syntax) define un carácter como “delimitador de variable”, de forma que las variables embebidas en las plantillas de configuración son reconocidas por los procesos de fusión en el elemento de red 41.
-
Permite recursión, es decir, algunos URLs del fichero de configuración (metaconf) son ellos mismos ficheros de configuración (metaconfs) y el dispositivo de red puede descargar recursivamente los URLs en los ficheros de configuración de siguiente nivel metaconfs) y combinarlos con las plantillas y datos de configuración de niveles previos de recursión.
-
Permite el uso de plantillas de configuración y datos de configuración propietarios de proveedores. Con ese propósito, las plantillas de configuración y los datos de configuración son tratados como elementos opacos (no aplicados) por el elemento de red 41, en tanto en cuanto una configuración final (no hay recursión pendiente) no se produce mediante la fusión de plantillas de configuración en su correspondiente punto de anclaje con los datos de configuración.
Con objeto de que el servidor de desencadenamiento de configuración 42 genere el fichero de configuración (metaconf), tiene que seleccionar las plantillas y los URLs de datos de configuración (configuration data URLs), y sus correspondientes puntos de anclaje, para ser proporcionados al elemento de red 41 en el fichero de configuración (metaconf). Los criterios de acuerdo con los cuales el servidor de desencadenamiento de configuración 42 selecciona las plantillas y los URLs de datos de configuración (configuration data URLs) para ser incluidos en el fichero de configuración (metaconf) quedan fuera del ámbito de esta invención.
A continuación, se describen en detalle las etapas del método de la presente invención, mostradas en la figura 4:
Entrega del fichero de configuración (entrega del Metaconf) (etapa 1) Una vez que el servidor de desencadenamiento de configuración 42 ha generado un fichero de configuración (metaconf) para el nodo de red o elemento de red 41, señaliza los contenidos del fichero de configuración (metaconf) al elemento de red 41.
Adquisición de plantilla y datos (etapa 2) (y etapa 2’ etapa 2’’…) El elemento de red 41 inspecciona el fichero de configuración (metaconf) y analiza y extrae los URLs contenidos. El elemento de red 41 descarga los contenidos (plantillas y datos de configuración) de los URLs especificados.
El elemento de red 41 inspecciona las plantillas descargadas. Si alguno de ellos es un fichero de configuración (metaconf), el elemento de red 41 descarga recursivamente los contenidos de los URLs especificados en el fichero de
configuración (metaconf).
Composición de la Configuración Objetivo (Target Configuration Composition) (etapa 3) Una vez que el elemento de red 41 ha cogido todas las plantillas y datos de configuración de forma recursiva, procede a fusionarlos en el punto de anchor correspondiente para cada uno de ellos tal y como se especifica en el fichero de configuración (metaconf).
La salida de esta etapa es el conjunto final de cambios de configuración que deben ser aplicados al elemento de red 41 en una operación indivisible expresada en el “lenguaje” adecuado al dispositivo (interfaz de línea de comando, formato XML, etc.). Esto lo asegura el servidor de desencadenamiento de la configuración 42 que selecciona las plantillas apropiadas (en el “lenguaje” apropiado) al elemento de red para que se incluya como URLs en el fichero de configuración (metaconf).
Puesta a punto automática de la configuración objetivo (Target Configuration Self-Comission) (etapa 4) El elemento de red 41 pone a punto el conjunto final de cambios de configuración y el nodo se vuelve operativo con la configuración pretendida.
A continuación, se describen algunas realizaciones específicas de la invención, en relación con el fichero de configuración llamado metaconf.
Definición del metaconf basada en XML A continuación se describe la definición del metaconf en formato XML. El fichero de configuración metaconf se compone de un número de etiquetas XML de plantilla y datos de configuración.
Las etiquetas XML de la plantilla tienen un atributo que tiene el valor del punto de anclaje en el árbol de configuración en el que la plantilla se va a incrustar. Las etiquetas de plantilla contienen los URLs a los que el nodo 41 tiene que acceder para descargar los contenidos de la plantilla. Las plantillas tienen comandos específicos (o CLI o XML) con referencias a variables de datos.
Las etiquetas XML de datos de configuración contienen los URLs a los que el nodo 41 tiene que acceder para descargar el valor de las variables de datos.
Definición del metaconf basado en CLI
A continuación se describe el metaconf en formato CLI. El fichero de configuración metaconf se compone de un número de comandos CLI que permiten la definición de plantillas de URLs y sus correspondientes puntos de anclaje y la definición de URLs de datos de configuración a los que acceder para variables de datos.
Las plantillas de los URLs especificados tienen comandos específicos de nodo (o CLI o XML) con referencias a variables de datos.
Entrega de metaconf basada en Transferencia de ficheros (aplicable a la etapa o paso 1)
A continuación se describe la entrega de metaconf por el servidor de desencadenamiento de configuración 42 al elemento de red 41, basado en un protocolo de transferencia de ficheros (por ejemplo TFTP, FTP) como resultado de un procedimiento de autoconfiguración (pull procedure) (por ejemplo procedimiento DHCP/BOOTP).
El DHCP ACK a la operación de autoconfiguración (Pull operation) incluye:
-
En la Opción DCHP de Siguiente-Servidor (Next-Server DCHP Option) la dirección IP del servidor de desencadenamiento de configuración 42 y el protocolo de transferencia de ficheros que se va a usar (FTP/TFTP)
-
En la Opción DHCP del Nombre-de-Fichero (File-Name DHCP Option) el camino del metaconf generado para el elemento de red 41 por el servidor de desencadenamiento de configuración 42.
Cuando se recibe el DHCP ACK, el nodo lee los campos Siguiente-Servidor (Next-Server) y Nombre-de-Fichero (File-Name) en la petición DHCP y envía una solicitud de transferencia de fichero al servidor para el fichero que contiene su metaconf.
Entrega del metaconf basado en NETCONF (aplicable a la etapa o paso 1)
A continuación se describe la entrega del metaconf basada en una invocación del método NETCONF por el servidor de desencadenamiento de la configuración 42 en el elemento de red 41.
El servidor de desencadenamiento de la configuración 42 se conecta al servidor NETCONF en el elemento de red 41 e invoca un método NETCONF que acepta como argumento los contenidos del metaconf. Esto entrega el metaconf al nodo de forma efectiva.
Entrega del metaconf basada en TELNET/SSH (aplicable a la etapa o paso 1)
A continuación se describe la entrega del metaconf vía una sesión interactiva de línea de comando (Telnet/SSH). Vía esta sesión la definición del metaconf se introduce al elemento de red 41. Inspección de la entrega del metaconf basado en script/NETCONF (Delivery script/NETCONF based metaconf inspection) (aplicable a la etapa o paso 2)
A continuación, se desencadena o lanza la ejecución de un script interno en el nodo 42, una vez que la definición del metaconf ha sido entregada por el servidor de desencadenamiento de configuración 42. El script invoca un método NETCONF local que analiza el metaconf y extrae los URLs que se va a acceder. El método NETCONF local es programable abiertamente para hacer el análisis.
Inspección de la entrega del metaconf basado en script/CLI (Delivery script/CLI based metaconf inspection) (aplicable a la etapa o paso 2)
A continuación, se desencadena o lanza la ejecución de un script interno en el nodo 42, una vez que el metaconf se ha entregado. El propio script interno analiza el metaconf y extrae los URLs que se va a acceder.
Adquisición de datos de plantilla o configuración basados en transferencia de ficheros (File Transfer based template/configuration data acquisition) (aplicable a la etapa o paso 2)
A continuación se describe la adquisición de datos de plantilla o configuración vía un protocolo de transferencia de ficheros desde un servidor de apoyo a la configuración 43 44 45.
Las etiquetas en el metaconf contienen URLs que especifican un protocolo de Transferencia de Ficheros y todos los detalles para acceder al contenido requerido (dirección IP del servidor de apoyo a la configuración, camino al fichero, usuario, contraseña, etc). El nodo 41 accede a los contenidos en el servidor de apoyo a la configuración 43 44 45 haciendo uso del Protocolo de Transferencia de Ficheros especificado y credenciales.
Adquisición de datos de plantilla o configuración basada en NETCONF (aplicable a la etapa o paso 2)
A continuación se describe la adquisición de datos de plantilla o configuración vía la invocación de un método NETCONF remoto en un servidor de apoyo a la configuración 43 44 45.
Las etiquetas en el metaconf contienen URLs que especifican un método NETCONF para ser invocado (por ejemplo ”obtener plantilla”) en un servidor de apoyo a la configuración remoto 43 44 45 (por ejemplo una dirección IP de repositorio de plantilla) y los argumentos para conseguir los contenidos deseados (nombre de la plantilla, nombre del fichero de datos de configuración o nombre de variable). El nodo accede los contenidos invocando el método en el servidor de apoyo remoto con los argumentos especificados.
Adquisición de datos de plantilla o configuración basada en DHCP (aplicable a la etapa o paso 2)
A continuación se describe la adquisición de datos de plantilla o configuración vía mecanismos DHCP.
Las etiquetas del metaconf contienen URLs que especifican DHCP como el protocolo a utilizar, el nombre del servidor que se va a aceptar como servidor DHCP.
Adquisición de datos o plantilla basada en servicio web (Web Service based template/data acquisition) (aplicable a la etapa o paso 2)
Los datos de configuración no se restringen a ficheros URL, sino que otros tipos de URLs son posibles, tales como un URL de servicio web (Web Service URL) que proporcione al dispositivo de red 41 una forma de solicitar sus datos de configuración data (o parte de ello) a un elemento encargado de asignar recursos disponibles (por ejemplo un servidor de auto-descubrimiento).
Composición de configuración objetivo basada en NETCONF (NETCONF based Target Configuration composition) (aplicable a la etapa o paso 3)
Una vez que se han descargado en el elemento de red 41 todos los datos de plantillas/configuración, se desencadena o lanza en el elemento de red 41 un script que invoca un método NETCONF local en el elemento de red 41 que combina las plantillas en sus correspondientes puntos de anclaje tal y como se especifica en el metaconf y sustituye las variables de las plantillas por sus valores tal y como se define en los elementos de datos de la configuración.
Composición de configuración objetivo basada en CLI interno (Internal CLI based Target Configuration composition) (aplicable a la etapa o paso 3)
Una vez que se han descargado en el elemento de red 41 todos los datos de plantillas/configuración, se desencadena o lanza en el elemento de red 41 un script interno que combina las plantillas en sus correspondientes puntos de anclaje tal y como se especifica en el metaconf y sustituye las variables de las plantillas por sus valores tal y como se define en los elementos de datos de la configuración.
A continuación se describe un ejemplo de una implementación real de la invención. En particular, se divulga un prototipo.
Se ha implementado haciendo uso de los encaminadores Juniper de la serie EX (Juniper EX-series routers). Estos encaminadores soportan métodos NETCONF que pueden ser invocados como parte de los scripts de puesta a punto (commit scripts). Todas estas capacidades se ofrecen en un paquete comercial en el soporte Juniper JUNOScript.
Otra característica de la serie EX usada en la implementación mencionada antes es su capacidad de autoinstalación en una configuración por defecto de fábrica que permite el uso de procedimientos DHCP/TFTP para la instalación de una configuración inicial en el encaminador. En el prototipo, esta configuración inicial fue un metaconf entregado por TFTP.
La definición del metaconf se basó en la característica de aplicación de macros (apply-macros) del software JUNOS que permite la copia de expresiones a medida en una configuración que no interpreta el encaminador, pero que al final puede usarse por algún tipo de script local.
Para el prototipo, los scripts de puesta a punto se aplicaron como parte de la configuración inicial. Estos scripts de puesta a punto se invocaron una vez que la configuración inicial (que contenía el metaconf como declaraciones de la aplicación de macros) fue entregada al equipo.
Dos de estos scripts de puesta a punto fueron invocados secuencialmente después de que la configuración inicial se auto-pusiera a punto como parte de la característica de auto-instalación. El primer script estaba dedicado a inspeccionar el metaconf (las declaraciones de la aplicación de macros de la configuración inicial), analizando los URLs y descargándolos (plantillas y datos de configuración). El segundo script se ejecutó una vez que la descarga fue completada se encargaba de combinar las plantillas en su punto de anclaje con los valores de las variables en los ficheros de datos de configuración y a aplicar el conjunto final de cambios de configuración.
En resumen, el prototipo se puede categorizar como una implementación de las siguientes realizaciones o características:
-definición del metaconf basado en CLI (como declaraciones de macros de aplicación en la configuración JUNOS) -entrega del metaconf basada en transferencia de ficheros (TFTP) (como resultado de la característica de autoinstalación a partir de una configuración por defecto de fábrica) -inspección de metaconf basada en el script de puesta a punto/NETCONF (haciendo uso del método “de descarga” de NETCONF auto-desarrollado) -adquisición de la plantilla basada en FTP (haciendo uso de la copia del fichero NETCONF mediante transferencia del fichero JUNOScript dentro del método “de descarga”) -adquisición de datos de configuración basados en FTP (haciendo uso de la copia del fichero NETCONF mediante transferencia del fichero JUNOScript dentro del método “de descarga”) -composición de la configuración objetivo basada en el script de puesta a punto/NETCONF (haciendo uso del
método de combinación auto-desarrollado por NETCONF “merge”)
Entre las ventajas de la invención, se pueden mencionar las siguientes: Todas las soluciones de Gestión de Red existentes están basadas en un método monolítico controlado por el sistema (push model). La configuración es empujada (pushed) en su totalidad al dispositivo de red, que simplemente pone a punto los cambios de configuración. Toda la lógica de configuración reside en el NMS. Esto lleva a un diseño opaco del NMS que está a cargo de:
-
procesar los pools de recursos y asignar recursos para los datos de configuración (por ejemplo
direcciones IP, identificadores de VLAN, etc.)
-
conocimiento a priori de los equipos que se van a desplegar (modelo, papel que desempeñan, puertos,
puntos de conexión, etc.)
-
selección de plantillas que se van a usar en diferentes niveles del árbol de configuración (por ejemplo una
plantilla para una configuración global, otra para el encaminamiento, otra para las interfaces en uplink, otra
para las interfaces de usuario…) basada en el conocimiento sobre los equipos y su conexión esperada a la
red
-
combinación de los datos de configuración y plantillas para producir un nuevo cambio de configuración
completo para enviar al dispositivo
Este diseño opaco y monolítico del NMS conduce a altos costes porque hay demasiadas cosas bajo el control de una sola pieza de software. Como resultado de esto, cualquier cambio posterior para acomodar nuevas configuraciones en el dispositivo de red es costoso para el operador de red debido a la naturaleza ad-hoc para su red del NMS. Los costes son muy altos incluso cuando el NMS tiene que tratar solo con equipos que están configurados de una forma muy similar, como es el caso de los nodos de acceso (DSLAMs, OLTs).
No solo son altos los costes para cambiar el NMS, sino que también lo es el tiempo de desarrollo para incorporar una nueva funcionalidad en la red. Esto conduce a un mayor Tiempo-de-llegada-a-mercado (Time-to-Market) en el despliegue de nuevos servicios.
Algunas mejoras bien conocidas en las capacidades de procesado del dispositivo de red permiten algo de subcontratación (“outsourcing”) en la lógica de configuración del NMS al dispositivo de red. Sin embargo, esta lógica debe pre-almacenarse en el dispositivo de red y sigue siendo monolítica en el sentido de que codifica toda la lógica aplicable a la totalidad de la configuración que se va a cambiar. En vez de “empujar” toda la configuración al dispositivo de red, todos los datos de configuración deben ser “empujados” al dispositivo de red, que entonces hace correr la lógica de configuración, que debe estar pre-almacenada. Esto no soluciona el problema, porque la solución sigue siendo rígida e inflexible.
Este acercamiento monolítico al NMS hace irrelevante la necesidad de cambiar de un modelo de empuje o controlado por el sistema (push model) a un modelo de atracción o controlado por el cliente (pull model) en el que el dispositivo de red pregunta por su configuración cuando se conecta a la red. La configuración producida por el NMS es tan específica para ese nodo particular que se requiere un técnico en campo para chequear que cada puerto se conecta donde debe o incluso para informar de qué puertos están siendo usados para qué propósito (uplink, downlink, etc.) si eso no está fijado de antemano. Además de esto, el flujo de trabajo del NMS necesita tanto tiempo para producir una configuración para un nodo específico (principalmente porque la asignación de recurso depende de la entrada de personal a los departamentos del operador de red), que el avance en el tiempo conseguido por un modelo controlado por el cliente no compensa el cambio.
La conclusión es que para desplegar nuevos equipos, se debe enviar al sitio personalmente a un técnico cualificado que sepa cómo configurar los equipos (al menos una mínima configuración para hacer que el equipo esté disponible en el NMS) y dónde conectarlos (este puerto como uplink, etc.).
En general, la principal ventaja de la presente invención es que permite la “deconstrucción” del NMS en entidades separadas con módulos expuestos e interfaces que son ampliables de forma independiente entre sí. El NMS restante queda simplificado, y por tanto se reducen sus costes y se mejora el tiempo de llegada al mercado necesario para incluir modificaciones en la configuración de red:
-
en cuanto a la asignación de recurso, gracias a esta invención, el NMS puede simplemente proporcionar al dispositivo de red el URL de un servidor de auto descubrimiento como datos de configuración, en vez de gestionar la asignación del recurso en el NMS. Esta “delegación” del recurso asignado desde el NMS tiene la ventaja de simplificar el NMS.
-
Gracias a esta invención, el NMS no tiene que tardar más con la combinación de datos de configuración y plantillas porque esto lo hace el dispositivo de red. Esto proporciona simplificación adicional en el NMS.
-
La única funcionalidad mantenida por el NMS es la selección de plantillas para ser usadas por cada modelo/papel a desempeñar, mientras que el almacenamiento y versionado de las plantillas está separado del NMS.
-
Un cambio en la arquitectura de la red no requiere una nueva versión del NMS, sino solamente nuevas plantillas para la nueva arquitectura.
Otra ventaja es que la invención, usada conjuntamente con tecnologías pull como DHCP (no cubiertas por esta solicitud de patente) puede proporcionar auto-configuración efectiva del equipo de red, reduciendo los costes del despliegue de los equipos de red (personal menos cualificado).
Por otra parte, solo se requiere que el dispositivo de red se aumente con las siguientes capacidades:
-
Soporte del fichero de configuración metaconf, preferentemente definido en formato XML e implementado mediante un método NETCONF RPC (por tanto soporte a NETCONF)
-
El fichero de configuración metaconf implica capacidad de procesado en el dispositivo de red de forma que pueda combinar las plantillas descargadas con datos. La principal idea detrás del fichero de configuración metaconf es que las capacidades de procesado están limitadas a la fusión “ciega” de plantillas que incluyen referencias a variables los valores de estas variables obtenidos como URLs de datos de configuración. En el elemento de red no se necesitan otros métodos ad-hoc que la composición de la configuración objetivo basada en estas reglas.
Estos nuevos requisitos del dispositivo de red están en línea con la potencia de procesado de los equipos del estado de la técnica usados hoy día por las redes IP de operadores.
Obviamente la invención no se limita a las realizaciones específicas que se han descrito aquí, sino que también abarca cualquier variación que un experto en la materia pueda considerar (por ejemplo, en lo que concierne a la elección de componentes, configuración, etc.), dentro del ámbito de la invención tal y como se define en las reivindicaciones que se adjuntan.

Claims (9)

  1. REIVINDICACIONES
    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. 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. 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. 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. 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. 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. 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. 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.
    OFICINA ESPAÑOLA DE PATENTES Y MARCAS
    N.º solicitud: 201130725
    ESPAÑA
    Fecha de presentación de la solicitud: 06.05.2011
    Fecha de prioridad:
    INFORME SOBRE EL ESTADO DE LA TECNICA
    51 Int. Cl. : H04L12/24 (2006.01)
    DOCUMENTOS RELEVANTES
    Categoría
    56 Documentos citados Reivindicaciones afectadas
    A
    EP 1376930 A2 (MICROSOFT CORP) 02.01.2004, párrafos [24-25,37-39,42-48,52,58-59,62-63,tabla 1,70-74,96-102]. 1-8
    Categoría de los documentos citados X: de particular relevancia Y: de particular relevancia combinado con otro/s de la misma categoría A: refleja el estado de la técnica O: referido a divulgación no escrita P: publicado entre la fecha de prioridad y la de presentación de la solicitud E: documento anterior, pero publicado después de la fecha de presentación de la solicitud
    El presente informe ha sido realizado • para todas las reivindicaciones • para las reivindicaciones nº:
    Fecha de realización del informe 12.07.2013
    Examinador J. Santaella Vallejo Página 1/4
    INFORME DEL ESTADO DE LA TÉCNICA
    Nº de solicitud: 201130725
    Documentación mínima buscada (sistema de clasificación seguido de los símbolos de clasificación) H04L Bases de datos electrónicas consultadas durante la búsqueda (nombre de la base de datos y, si es posible, términos de
    búsqueda utilizados) INVENES, EPODOC, wPI
    Informe del Estado de la Técnica Página 2/4
    OPINIÓN ESCRITA
    Nº de solicitud: 201130725
    Fecha de Realización de la Opinión Escrita: 12.07.2013
    Declaración
    Novedad (Art. 6.1 LP 11/1986)
    Reivindicaciones Reivindicaciones 1-8 SI NO
    Actividad inventiva (Art. 8.1 LP11/1986)
    Reivindicaciones Reivindicaciones 1-8 SI NO
    Se considera que la solicitud cumple con el requisito de aplicación industrial. Este requisito fue evaluado durante la fase de examen formal y técnico de la solicitud (Artículo 31.2 Ley 11/1986).
    Base de la Opinión.-
    La presente opinión se ha realizado sobre la base de la solicitud de patente tal y como se publica.
    Informe del Estado de la Técnica Página 3/4
    OPINIÓN ESCRITA
    Nº de solicitud: 201130725
    1. Documentos considerados.-
    A continuación se relacionan los documentos pertenecientes al estado de la técnica tomados en consideración para la realización de esta opinión.
    Documento
    Número Publicación o Identificación Fecha Publicación
    D01
    EP 1376930 A2 (MICROSOFT CORP) 02.01.2004
  9. 2. Declaración motivada según los artículos 29.6 y 29.7 del Reglamento de ejecución de la Ley 11/1986, de 20 de marzo, de Patentes sobre la novedad y la actividad inventiva; citas y explicaciones en apoyo de esta declaración
    La invención reivindicada presenta un método y un sistema para la configuración de un elemento de red de manera distribuida. El sistema esta compuesto de un primer servidor, disparador de configuración, que envía un de “archivo de configuración” al elemento de red, de acuerdo con el contenido de “archivo de configuración”, el elemento de red se comunica con una red servidores de soporte y se descarga de cada uno de los servidores soporte ficheros de configuración, extrayendo y combinando estos ficheros de acuerdo al “archivo de configuración” y aplicando estos cambios de configuración en el elemento de red.
    El documento del estado de la técnica más próximo a la invención es D01 y divulga un método y un sistema para la descarga de ficheros de configuración de una PDA o un teléfono móvil. El sistema está compuesto por un servidor de gestión que comunica instrucciones de descarga para la gestión de la configuración de la PDA. El PDA recibe la instrucción de descarga desde el servidor de gestión y determina el conjunto de archivos disponibles para su descarga e instalación desde la última operación de descarga con éxito. El fichero de descarga puede indicar distintas direcciones de servidero para descargar distintos ficheros.
    La diferencia técnica entre D01 y la solicitud se encuentra en que D01 carece del paso de “combinar dichos trozos parciales de cambios de configuración en dicho elemento de red obteniendo así un conjunto de cambios de configuración resultantes”. El efecto técnico que se desprende es que “permite la deconstrucción” de los ficheros de configuración y así se evita una configuración indivisible pudiendo aplicar una parte a un tipo de nodo y otra parte a otro nodo.
    La invención reivindicada no es obvia para un experto en la materia, ya que no hay información en los documentos citados que puedan dirigir al experto en la materia al método reivindicado.
    Por lo tanto a la luz de D01, la invención es nueva y posee actividad inventiva tal como se establece en los artículos 6 y 8 de la Ley de Patentes 1986
    Informe del Estado de la Técnica Página 4/4
ES201130725A 2011-05-06 2011-05-06 Método de composición de cambios de configuración en un elemento de red Expired - Fee Related ES2429219B1 (es)

Priority Applications (5)

Application Number Priority Date Filing Date Title
ES201130725A ES2429219B1 (es) 2011-05-06 2011-05-06 Método de composición de cambios de configuración en un elemento de red
US14/115,993 US20140156816A1 (en) 2011-05-06 2012-05-07 Method for composing configuration changes in a network element
BR112013028676A BR112013028676A2 (pt) 2011-05-06 2012-05-07 método para compor alterações de configuração em um elemento de rede
PCT/EP2012/058330 WO2012152736A1 (en) 2011-05-06 2012-05-07 Method for composing configuration changes in a network element
EP12719007.2A EP2705630A1 (en) 2011-05-06 2012-05-07 Method for composing configuration changes in a network element

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201130725A ES2429219B1 (es) 2011-05-06 2011-05-06 Método de composición de cambios de configuración en un elemento de red

Publications (2)

Publication Number Publication Date
ES2429219A1 true ES2429219A1 (es) 2013-11-13
ES2429219B1 ES2429219B1 (es) 2014-09-03

Family

ID=46027981

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201130725A Expired - Fee Related ES2429219B1 (es) 2011-05-06 2011-05-06 Método de composición de cambios de configuración en un elemento de red

Country Status (5)

Country Link
US (1) US20140156816A1 (es)
EP (1) EP2705630A1 (es)
BR (1) BR112013028676A2 (es)
ES (1) ES2429219B1 (es)
WO (1) WO2012152736A1 (es)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9286047B1 (en) * 2013-02-13 2016-03-15 Cisco Technology, Inc. Deployment and upgrade of network devices in a network environment
US9887878B2 (en) * 2014-06-06 2018-02-06 Microsoft Technology Licensing, Llc Dynamic scheduling of network updates
CN107294750B (zh) * 2016-04-01 2020-10-30 阿里巴巴集团控股有限公司 一种云集群能自识别的分布配置管理方法和装置
US10171295B2 (en) * 2016-04-07 2019-01-01 Red Hat, Inc. Distributed remote execution
US10382269B2 (en) * 2016-05-26 2019-08-13 Ricoh Company, Ltd. Configuring devices using device management templates
CN107528788B (zh) * 2016-06-20 2020-12-04 新华三技术有限公司 实现网络设备之间自动堆叠的方法和装置
US10382262B1 (en) 2017-05-10 2019-08-13 Appian Corporation Dynamic application configuration techniques
US10701414B2 (en) 2018-04-18 2020-06-30 Arris Enterprises Llc Legacy video network configuration in a distributed access architecture
US11424984B2 (en) * 2018-10-30 2022-08-23 Elasticsearch B.V. Autodiscovery with dynamic configuration launching
US11461288B2 (en) * 2019-03-14 2022-10-04 Servicenow, Inc. Systems and methods for database management system (DBMS) discovery
US11281438B2 (en) * 2020-04-09 2022-03-22 Modak Technologies FZE Platform for web services development and method therefor
EP4243361A3 (en) * 2020-04-16 2023-11-22 Juniper Networks, Inc. Model driven configuration management for microservices
US11252025B2 (en) 2020-04-16 2022-02-15 Juniper Networks, Inc. Model driven configuration management for microservices
US11770299B2 (en) * 2021-02-26 2023-09-26 Hewlett Packard Enterprise Development Lp Systems and methods for preprocessing automated network device configuration generation templates
US11777800B2 (en) * 2021-06-24 2023-10-03 Juniper Networks, Inc. Identifying out-of-band configuration changes to validate intent files

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1376930A2 (en) * 2002-06-28 2004-01-02 Microsoft Corporation Systems and methods for application delivery and configuration management of mobile devices

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7089259B1 (en) * 2001-08-03 2006-08-08 Mcafee, Inc. System and method for providing a framework for network appliance management in a distributed computing environment
EP1782246B1 (en) * 2004-07-07 2020-02-12 Sciencelogic, LLC Self configuring network management system
CN101321080B (zh) * 2007-06-04 2010-07-28 华为技术有限公司 配置网络设备的方法、网络设备、网络系统
US8037135B2 (en) * 2007-06-29 2011-10-11 Microsoft Corporation Automatic distributed downloading
US8977766B2 (en) * 2010-09-21 2015-03-10 Edgecast Networks, Inc. Scalability and redundancy enhancements for content streaming
US8719381B2 (en) * 2010-10-05 2014-05-06 Edgecast Networks, Inc. Reconfigurable download manager
US20120174093A1 (en) * 2011-01-05 2012-07-05 Divx, Llc Systems and method for dynamically loading software platforms onto playback devices

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1376930A2 (en) * 2002-06-28 2004-01-02 Microsoft Corporation Systems and methods for application delivery and configuration management of mobile devices

Also Published As

Publication number Publication date
WO2012152736A1 (en) 2012-11-15
ES2429219B1 (es) 2014-09-03
US20140156816A1 (en) 2014-06-05
EP2705630A1 (en) 2014-03-12
BR112013028676A2 (pt) 2017-01-24

Similar Documents

Publication Publication Date Title
ES2429219B1 (es) Método de composición de cambios de configuración en un elemento de red
EP3432517B1 (en) Device configuration method and apparatus based on network configuration protocol
EP2098028B1 (en) Method for logical deployment, undeployment and monitoring of a target ip network
US10129206B2 (en) Addressing and managing an internal network of a virtual branch node
ES2375323T3 (es) Aparato de integración, red de comunicación y método para integrar un nodo de red en una red de comunicación.
US10534600B2 (en) Method and system for uniform remote management of network devices
EP1780941B1 (en) Network configuration
CN105359458B (zh) 网络设备通信方法及网络设备
CN112104473B (zh) 基于图形的意图控制器中的可编程配置模板
US10282346B1 (en) Scalable network device self-configuration in large networks
Demchenko et al. Enabling automated network services provisioning for cloud based applications using zero touch provisioning
CN107113333B (zh) 在服务器计算机上安装软件的方法和通信接口装置
Matias et al. The EHU-OEF: an OpenFlow-based layer-2 experimental facility
US11522759B2 (en) Method and device manager for controlling program components in a network device
Cisco Configuring DHCP Servers
Wijaya Network Automation using Ansible for Cisco Router Basic Configuration
Starschenko et al. Auto-configuration of OSPFv3 routing in fixed IPv6 networks
Escrich et al. WiBed, a platform for commodity wireless testbeds
Janovic Integrating ACI with Virtualization and Container Platforms
Both NetworkManager
CN115550764A (zh) 基于自动开通系统的网元配置方法、系统、设备和介质
Visscher Kube on Openstack
Anderhub et al. CentriFi: A CentralizedWireless Access Point Management Platform
Gonzalez Barreto et al. Wireless sensor network: control and power monitoring
Muhamad Development of Fastnet config application

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2429219

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20140903

FD2A Announcement of lapse in spain

Effective date: 20181015