ES2951319T3 - Puesta en servicio/desmantelamiento de redes en entornos informáticos definidos por software - Google Patents

Abstract

Según un aspecto, se proporciona un ordenador servidor (DNPS) para poner en marcha/desmantelar redes que se activarán/desactivarán mediante un controlador (SDNC) de red definido por software, SDN, que constituye una arquitectura cliente-servidor con el ordenador servidor (DNPS). . La computadora servidor (DNPS) comprende además una base de datos (DB) que comprende datos, una interfaz de usuario remoto (Ul) para la gestión remota de un controlador SDN (SDNC) para proporcionar acceso a los datos gestionados por el controlador SDN (SDNC), un conector de cliente (CLC) para comunicarse con una interfaz de programación de aplicaciones (SDN-API) del controlador SDN (SDNC) y un motor de gestión de red (NME) para asignar y liberar dinámicamente redes para ser activadas/desactivadas por el controlador SDN (SNDC). El motor de gestión de red (NME) está conectado a la base de datos (DB), la interfaz de usuario remota (Ul) y el conector de cliente (CLC). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Puesta en servicio/desmantelamiento de redes en entornos informáticos definidos por software

Campo

La presente invención se refiere a la puesta en servicio y desmantelamiento de redes IP y recursos IP en entornos informáticos en la nube.

Antecedentes

Como se sabe desde hace mucho tiempo, el Protocolo de Internet v. 4 (IPv4) está bastante limitado en términos de espacio de direcciones disponible. Para abordar el problema, la norma RFC1918 define tres redes pretendidas para uso privado, en concreto, 10.0.0.0 (Clase A), 172.16.0.0 (Clase B) y 192.168.0.0 (Clase C). Ninguna de estas redes privadas se ha enrutado a la Internet pública. Las grandes corporaciones y los proveedores de servicios típicamente tienen espacio de direcciones de red de Clase A (10.0.0.0) para ampliar el espacio de direcciones disponible para ellos, mientras que los módems de cable y ADSL que se usan comúnmente en hogares y oficinas pequeñas distribuyen direcciones IP desde redes privadas 192.168. Las conexiones con el mundo exterior se proporcionan utilizando la tecnología de traducción de direcciones de red (NAT), en donde un dispositivo NAT ubicado entre las redes públicas y privadas actúa como un puente. Dado que varias redes privadas comparten el mismo espacio de direcciones 10.0.0.0, se superponen. La superposición ha sido un problema insignificante siempre que estas redes privadas se hayan ejecutado internamente, en lugar de enrutarlas a la Internet pública.

La superposición de redes privadas se convierte en un problema en relación con la informática en la nube o los servicios basados en la nube. Por ejemplo, los proveedores de servicios IaaS (infraestructura como servicio) están desplegando cada vez más entornos informáticos de múltiples abonados que se usan para ofrecer servicios al mismo tiempo a varios clientes comerciales, todos los cuales pueden usar el mismo espacio de direcciones 10.0.0.0, especialmente en el contexto de la nube privada virtual y/u otras tecnologías similares. En casos de uso como este, las redes privadas usadas por diferentes abonados típicamente están superpuestas.

En la siguiente descripción, "orquestación" se usa en su significado establecido dentro del ámbito de la arquitectura orientada a servicios ("SOA"), cuando se analizan flujos de trabajo automatizados entre el procesamiento de datos y los sistemas de comunicación. Las empresas y los proveedores de servicios usan soluciones de orquestación para alinear las solicitudes comerciales con las aplicaciones, los datos y la infraestructura. Dichas soluciones se usan típicamente para definir las políticas y los niveles de servicio a través de flujos de trabajo automatizados, aprovisionamiento y gestión de cambios. Con esta tecnología, las organizaciones pueden crear una infraestructura alineada con las aplicaciones que se puede escalar hacia arriba, hacia abajo o lateralmente basándose en las necesidades de cada aplicación. La orquestación también proporciona una gestión centralizada del grupo de recursos, incluyendo la facturación, la medición y el cobro por consumo.

La asignación de direcciones IP, nombres y otros parámetros de red a los diversos servidores, comúnmente denominados cargas de trabajo, que ejecutan aplicaciones en entornos orquestados, se ha realizado tradicionalmente configurando una dirección IP en dichos servidores y añadiendo el nombre del servidor con la correspondiente dirección IP a un servidor de nombres de dominio (DNS) manualmente, o haciendo que tal asignación se realice dinámicamente usando el protocolo de configuración dinámica de host (anfitrión) (DHCP) y DNS dinámico. Dado que las direcciones IP y los nombres de los servidores físicos que se ejecutan en entornos informáticos orquestados tradicionales han sido relativamente estáticas, sus procesos de gestión de flujo de trabajo automatizados basados en SOA no se han ampliado para integrarse con los mecanismos de puesta en servicio de IP y nombres. A medida que las soluciones de orquestación existentes se amplían a los entornos informáticos basados en la nube, los métodos tradicionales usados para gestionar las direcciones IP y los nombres descritos anteriormente crearán diversos problemas. Por ejemplo, dado que el paradigma de la informática basada en la nube requiere que las nuevas máquinas virtuales se aprovisionen bajo demanda, el proceso de asignación de IP y nombres manual asociado con los métodos de la técnica anterior usados para asignar recursos y nombres de IP en entornos informáticos orquestados tradicionales se convierte rápidamente en un cuello de botella en lo que respecta a la escalabilidad de todo el entorno informático basado en la nube. Además, aunque el paradigma de informática bajo demanda basado en la nube requiere que el ciclo de vida de una instancia de servidor virtual pueda ser de minutos a varios años, los servidores DHCP proporcionan un tiempo de concesión predefinido y fijo para las direcciones IP asignadas automáticamente, de esta manera haciéndolo imposible alinear los tiempos de concesión de IP con la naturaleza dinámica del entorno informático virtual. Además, las técnicas de la técnica anterior hacen que sea imposible reclamar automáticamente una dirección IP cuando se desmantela una máquina virtual, ya que, incluso con DHCP, el desmantelamiento está vinculado al tiempo de concesión predefinido de las direcciones IP que se han emitido. Por lo tanto, los métodos de la técnica anterior hacen que sea imposible alinear el tiempo de concesión de una dirección IP con el ciclo de vida único de cada máquina virtual que se ejecuta dentro de la nube.

Las limitaciones de DHCP se revelan rápidamente al intentar usarlo en relación con la informática en la nube. Una de las razones de la pobre compatibilidad entre DHCP y la informática en la nube es que DHCP nunca se diseñó para la informática en la nube o los modelos de integración basados en la web. Por ejemplo, DHCP opera en la capa 2 (L2) de OSI. En la práctica, un cliente envía un mensaje de difusión a una red de área local (LAN). Un servidor DHCP en esa LAN captura el mensaje de difusión, inspecciona la dirección de control de acceso al medio (MAC) del cliente, que es una dirección única del adaptador de interfaz de red, y devuelve una dirección IP con otros parámetros de red a la dirección MAC. Después de eso, el cliente configura los parámetros de red por sí mismo y puede adoptar una conexión TCP/IP, que opera en capas OSI superiores.

En la práctica, la metodología descrita anteriormente requiere que el cliente y el servidor DHCP estén interconectados por una conexión L2. En la práctica, el cliente y el servidor DHCP deben estar conectados a la misma red LAN. La LAN puede estar comprendida por múltiples redes VLAN, pero estas deben estar interconectadas en la capa L2. En los casos donde los clientes tienen espacios de direcciones 10.0.0.0 superpuestos, el proveedor de servicios debe aislarlos entre sí configurando los espacios de direcciones superpuestos en distintas redes LAN. Como resultado, todas las redes privadas están aisladas entre sí, lo que permite el tráfico IP dentro de la red por un lado y evita que los clientes accedan a las redes de otros clientes.

Una consecuencia del hecho de que, en primer lugar, DHCP opera en L2 y, en segundo lugar, los espacios de direcciones superpuestos deben aislarse en LAN separadas, es que un único DHCP no puede residir lógicamente en múltiples LAN por separado. En otras palabras, en el caso de múltiples redes privadas, cada una de ellas debe tener un servidor DHCP especializado.

El protocolo de Internet versión 6 (IPv6) proporciona dos mecanismos para asignaciones IP dinámicas. Estos mecanismos se denominan autoconfiguración con estado y autoconfiguración sin estado. Ninguno de los mecanismos de autoconfiguración resuelve los problemas identificados anteriormente porque, en primer lugar, la autoconfiguración con estado (DHCPv6) no es realmente diferente de DHCPv4 usado en entornos IPv4. Esto se debe a que cada vez que se asigna un recurso de IP a una máquina virtual, el recurso de IP asignado obtiene un valor de concesión fijo, lo que básicamente significa que el recurso de IP deberá permanecer asignado durante un período de tiempo predefinido, independientemente de si el recurso IP asignado sigue siendo utilizado en realidad por la máquina virtual. Dentro de los entornos basados en la nube, esto no es deseable, porque las direcciones IP deben ponerse en servicio (emitirse) cada vez que se activa una nueva máquina virtual y (liberarse) cada vez que esa máquina virtual se retira del entorno informático virtualizado.

Por otro lado, la autoconfiguración sin estado significa que un cliente obtiene de forma autónoma una dirección IP basándose en los anuncios del enrutador. En lo que respecta a las arquitecturas SOA y de orquestación, hay dos razones por las que este esquema puede no funcionar. En primer lugar, en entornos donde se usa orquestación, es un requisito típico que la dirección IP se obtenga de una red que coincida con la red de área local virtual (VLAN) en la que se pretende ejecutar una máquina virtual. En otras palabras, la dirección IP debe asignarse desde una red específica correspondiente a la VLAN en la que ha de desplegarse la máquina virtual, en lugar de darle a la máquina virtual una dirección IP arbitraria que esté disponible (esto último es a lo que conduce la autoconfiguración sin estado). La segunda razón por la que la autoconfiguración sin estado puede no funcionar en este caso de uso es que los entornos típicamente son entornos de múltiples abonados donde el administrador debe poder monitorizar activamente los niveles de asignación de cada red y determinar qué equipos y clientes se ejecutan en las redes. En el caso de que las direcciones IP se obtengan de forma autónoma por los clientes, no hay forma de controlar las direcciones IP que habrá obtenido una determinada máquina virtual, ni habrá transparencia en este proceso que permita al administrador gestionar estas relaciones. y/o rastrear la asignación de asignaciones de IP.

La solicitud de patente de propiedad común US20130346618 propone soluciones a los problemas identificados anteriormente mediante la enseñanza de técnicas que permiten a múltiples orquestadores (servidores que ejecutan la solución de orquestación) obtener parámetros de red de una única fuente autorizada denominada servidor de puesta en servicio/desmantelamiento de IP (="IPCDS"). El método enseñado en la solicitud de propiedad común se puede usar para aprovisionar parámetros de red desde redes tanto elásticas como tradicionalmente conmutadas, siempre que las redes se hayan registrado en el sistema IPCDS.

Después del despliegue de las técnicas propuestas por la solicitud US20130346618, se identificó un número de problemas relacionados. Por ejemplo, las redes TCP/IP se están moviendo hacia arquitecturas elásticas y automatización de procesos a través de tecnologías tales como la interconexión en red definida por software (SDN). Los beneficios proporcionados por tales tecnologías incluyen una mayor agilidad del servicio a través de procesos de gestión y configuración automatizados, seguridad mejorada a través de metodologías tales como la microsegmentación, así como la agilidad del servicio introducida por la integración con flujos de trabajo y procesos de servicio automatizados ejecutados por orquestadores responsables de desplegar cargas de trabajo y servicios virtualizados, infraestructura convergente, contenedores o similares.

Sin embargo, en muchos casos, SDN no se despliega en entornos completamente nuevos. Más bien, SDN se usa a menudo para crear redes dentro de bloques de red que también contienen redes tradicionalmente conmutadas basándose en el modelo de interconexión en red TCP/IP tradicional que se remonta a la década de 1980. Por lo tanto, las organizaciones que pretendan usar SDN deben asegurarse de que las nuevas redes elásticas y los microsegmentos no se superpongan con las redes tradicionales que ya se han activado dentro de los mismos bloques de IPv4 públicos, bloques de IPv4 privados y/o bloques de IPv6 públicos (juntos, "bloques de red compartidos").

Como las pilas en la nube y los controladores SDN típicamente permiten que los prefijos de red gratuitos se configuren manualmente en ellos, pueden asignar redes automáticamente a partir de los prefijos que se han configurado en ellos. Sin embargo, una fuente común de problemas es que las tecnologías mencionadas anteriormente no conocen el estado de asignación global de los bloques de red compartidos a los que pertenecen dichos prefijos de red. Esto hace que la automatización de servicios sea problemática en casos de uso tales como interconexión en red de área amplia definida por software (SD-WAN) o red como servicio (NaaS) en las que el prefijo o prefijos de red gratuitos que usará el controlador SDN deben ubicarse automáticamente, reservarse y/o asignarse al controlador SDN como parte del flujo de trabajo de automatización del servicio.

Además, cuando se aprovisionan parámetros de red a uno o más orquestadores responsables de desplegar servicios cargas de trabajo (de red) virtualizados, infraestructura convergente, contenedores o similares, se requiere que se aprovisionen los parámetros de red relacionados tanto con las redes elásticas como las redes tradicionales de una única fuente autorizada (IPCDS), ya que los recursos mencionados anteriormente que se conectan a la red desconocen el método por el que se ha configurado la red TCP/IP subyacente. Esto permite procesos orquestados que son independientes de las tecnologías que se han usado para implementar las redes TCP/IP subyacentes.

Para resolver parcialmente el problema, la publicación de solicitud de patente de propiedad común US20130346618 enseña un método que permite que múltiples orquestadores obtengan parámetros de red de una única fuente autorizada (IPCDS). El método enseñado en dicha solicitud se puede usar para aprovisionar parámetros de red desde redes tanto elásticas como tradicionalmente conmutadas, siempre que las redes se hayan registrado en el sistema IPCDS. Esto típicamente requiere el despliegue manual de las redes que proporcionan los recursos IP gestionados por el IPCDS.

En este sentido, todavía hay margen de mejora en la incorporación de la gestión, la asignación y la liberación de bloques de red y/o su contenido en los flujos de trabajo de automatización de servicios, así como en la gestión y la asignación y/o liberación automatizada de bloques de red, prefijos de red y similares en uno o más controladores SDN.

Divulgación

Por lo tanto, un objeto de la presente invención es proporcionar métodos, equipos y productos de programas informáticos para paliar uno o más de los problemas identificados anteriormente. Un objeto particular es proporcionar una gestión mejorada de los bloques de red y sus contenidos, que incluyen, pero sin limitación, bloques de red pública y privada y las redes que caen bajo ellos, para permitir la asignación y liberación automatizadas de los recursos mencionados anteriormente como parte de procesos y/o flujos de trabajo automatizados. En el presente contexto, el "contenido" del bloque de red puede entenderse como sigue. Las partes de los bloques de red serían prefijos, redes y datos administrativos asociados. La diferencia entre un prefijo de red y una red es que una red está conectada. Un prefijo es solo un término para un subconjunto de un bloque. Siempre habrá un prefijo de red que coincida con una red, pero no todos los prefijos coinciden con una red porque un prefijo se puede dividir en prefijos más pequeños. Los bloques de red privada superpuestos pueden coexistir en el mismo aparato usando técnicas desveladas en dicha solicitud de propiedad común US20130346618. El acto de dividir los bloques de red en prefijos, redes, subredes, microsegmentos o similares se puede llevar a cabo usando herramientas que implementan algoritmos generalmente conocidos y usados para el propósito. La lógica que combina algunas o todas las técnicas mencionadas anteriormente se denominará proceso de aprovisionamiento de red dinámico o "DNPP".

El objeto de la invención se consigue mediante aspectos de las invenciones como se definen en las reivindicaciones independientes adjuntas. Más específicamente, la presente invención proporciona métodos, equipos y productos de programas informáticos que pueden usarse para gestionar, asignar o liberar bloques de red, prefijos de red, subredes de redes, microsegmentos y similares como parte de flujos de trabajo orquestados o automatizados de otra manera, de forma que palia al menos uno de los problemas descritos anteriormente. Las reivindicaciones dependientes y la siguiente descripción detallada y dibujos se refieren a realizaciones específicas que resuelven problemas adicionales y/o proporcionan beneficios adicionales.

Una realización de la presente divulgación es un ordenador servidor para poner en servicio/desmantelar redes, comprendiendo el ordenador servidor una base de datos que comprende datos y está configurada para poner en servicio/desmantelar redes para que se activen/desactiven por un controlador de interconexión en red definido por software (SDN) que constituye una arquitectura cliente-servidor con el ordenador servidor, comprendiendo el ordenador servidor, además:

- una interfaz de usuario remota para la gestión remota de un controlador SDN, en donde la interfaz de usuario remota proporciona acceso a los datos gestionados por el controlador SDN;

- un conector de cliente para comunicarse con una interfaz de programación de aplicaciones del controlador SDN; y

- un motor de gestión de red para asignar y liberar dinámicamente redes para activarse/desactivarse por el controlador SDN, en donde el motor de gestión de red está conectado a la base de datos, a la interfaz de usuario remota y al controlador de cliente, en donde el motor de gestión de red está configurado para realizar:

recibir, desde el controlador SDN, una solicitud en la que se solicita una red;

comprobar si la solicitud incluye un nombre de cliente o abonado etiquetado, en el ordenador servidor, en un bloque de red gestionado por el ordenador servidor, comprendiendo el bloque de red prefijos, redes y datos administrativos asociados;

en respuesta a que la solicitud incluye dicho nombre de cliente o abonado etiquetado en el bloque de red, realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red, comprobar si está disponible la red y/o máscara de red solicitadas en el bloque de red etiquetado con dicho nombre de cliente o abonado, y, si está disponible dicha red y/o máscara de red solicitadas, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN, en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red, comprobar si una máscara de red por defecto está configurada en el ordenador servidor y, si una máscara de red por defecto está configurada en el ordenador servidor, si está disponible dicha máscara de red por defecto en el bloque de red etiquetado con dicho nombre de cliente o abonado y, si está disponible dicha máscara de red por defecto, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN; y

en respuesta a que solicitud falla al incluir dicho nombre de cliente o abonado etiquetado en el bloque de red, realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red, comprobar si está disponible la red y/o una red pública solicitadas del tamaño de la máscara de red en un bloque de red pública o privada gestionado por el ordenador servidor y, si está disponible la red y/o dicha red pública solicitadas, reservar una red que se considere disponible y devolverla al controlador SDN, y en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red, comprobar si una máscara de red por defecto está configurada en el ordenador servidor y, si la máscara de red por defecto está configurada, si está disponible una red con un tamaño de máscara de red por defecto en al menos un bloque de red pública gestionada por el ordenador servidor y, si está disponible la red con el tamaño de la máscara de red por defecto, reservar la red con el tamaño de la máscara de red por defecto y devolverla al controlador SDN.

Realizaciones adicionales más de la presente divulgación comprenden métodos y memorias legibles por ordenador que almacenan instrucciones de código de programa, en donde la ejecución del método o las instrucciones de código de programa en el ordenador servidor implementa las características del ordenador servidor basado en SDN.

La presente invención mejora por lo tanto el proceso de aprovisionamiento de red dinámico (DNPP). Antes de que se pueda usar la técnica IPCDS descrita en la solicitud de propiedad común US20130346618, las redes que están etiquetadas y desde las cuales se están poniendo en servicio los recursos de IP, deben ponerse en servicio de alguna manera, tal como manualmente, por ejemplo. La presente invención se basa en la idea de que esta puesta en servicio de la red debería mejorarse y automatizarse. Antes de que el IPCDS pueda funcionar, la red necesita activarse y debe provenir de alguna parte. El DNPP tiene como objetivo resolver este problema 1) describiendo cómo se gestionan los bloques de red.

En una implementación típica, el equipo de cliente DNPP comprende una lógica de cliente configurada para realizar las siguientes tareas:

- solicitar uno o más bloques de red, prefijos de red, redes, microsegmentos o similares, basándose en un nombre de abonado, nombre de cliente o cualquier otro identificador que se haya usado en DNPP para reservar un bloque de red dado o una parte de un bloque de red dado en un uso específico; y

- desencadenar la liberación del uno o más bloques de red, prefijos de red, redes, microsegmentos y similares ya asignados una vez que se desactive dicho recurso.

Las funcionalidades del lado del cliente no están incluidas en la redacción de las reivindicaciones, pero se consideran útiles para comprender la invención.

Otros aspectos de la invención incluyen métodos para operar el servidor DNPP inventivo y productos de programas informáticos cuya ejecución en servidores equipados apropiadamente les proporciona características del servidor DNPP y, por lo tanto, hacen que el servidor DNPP lleve a cabo el método inventivo. Como alternativa, la lógica DNPP también puede incorporarse a otro servidor que también implementa la metodología IPCDS descrita en la solicitud de patente de propiedad común US20130346618.

Debido a que los intentos anteriores para resolver los problemas señalados por esta invención han asumido únicamente una única pila en la nube, no pueden resolver los problemas de interoperabilidad en entornos que consisten en múltiples orquestadores, controladores SDN y/o servicios y/o infraestructura existentes. A diferencia de los intentos anteriores de gestionar, asignar y liberar bloques de red y su contenido en relación con flujos de trabajo orquestados o automatizados, o directamente dentro de los controladores SDN o como parte de diversas pilas en la nube, la presente invención reconoce que los bloques de red usados en entornos de producción típicamente se comparten entre redes tradicionalmente conmutadas y elásticas, y esa interoperabilidad sin interrupciones entre las dos requiere que todo el contenido de cada bloque de red se gestione en un sistema unificado que tenga autoridad para gestionar, asignar y liberar todos los bloques de red y/o su contenido bajo gestión, independientemente de qué tecnologías se usen para activar, configurar o conmutar las redes TCP/IP que se encuentran dentro de un bloque de red dado.

De acuerdo con una característica preferida pero opcional, la lógica DNPP también puede funcionar como una capa de integración entre los flujos de trabajo orquestados que se usan para desplegar servicios (de red), aplicaciones, cargas de trabajo, contenedores y similares, y los controladores SDN que son responsables de la activación automatizada y configuración continua de las redes elásticas. Este método opcional se usa para asignar y/o liberar bloques de red o su contenido según se solicite por el cliente DNPP, y para efectuar un cambio asociado en un controlador SDN que se ha integrado, ya sea directa o indirectamente, con el aparato que implementa la lógica de servidor DNPP. El propósito de este método opcional es implementar un modelo de integración bidireccional (Norte-Sur) mediante el cual uno o más orquestadores, en el norte, responsables de la lógica de negocios de diversos portales de interfaz de clientes, pueden ofrecer prefijos de red, redes, subredes o microsegmentos disponibles a usuarios finales (clientes internos o externos), potencialmente como un servicio; y de modo que dichos orquestadores en el norte podrán usar la lógica incluida en DNPP para activar automáticamente los prefijos de red, redes, subredes y/o microsegmentos seleccionados por los usuarios finales, en uno o más controladores SDN que se hayan integrado en el sur con DNPP.

Los elementos identificados anteriormente se describirán con más detalle a continuación, en donde las interfaces "sur" y "norte" se definen como sigue. Una interfaz norte de un componente conceptualiza los detalles de nivel inferior (por ejemplo, datos o funciones) usados por o en el componente. Una interfaz norte se usa para interactuar con capas de nivel superior usando la interfaz sur del componente o componentes de nivel superior. Una interfaz sur descompone los conceptos en los detalles técnicos, en su mayoría específicos a un único componente de la arquitectura. Las interfaces norte y sur se dibujan respectivamente en la parte superior e inferior de una vista general de la arquitectura. Las interfaces norte normalmente se comunican con las interfaces sur de componentes de nivel superior y viceversa. La invención implica, en primer lugar, un proceso de aprovisionamiento de red dinámica (DNPP) que se usa para gestionar y rastrear, distribuir y asignar bloques de red, prefijos de red individuales, redes, subredes y microsegmentos dentro de cada bloque de red, propiedades y atributos administrativos relacionados, y para leer las configuraciones de red realizadas de forma autónoma por los controladores SDN en el sur. A diferencia de las soluciones de gestión de direcciones IP convencionales que se han diseñado para gestionar redes, subredes y direcciones IP manualmente por los administradores de red y otros profesionales de la tecnología de la información, el DNPP de acuerdo con la presente invención está configurado con todos los bloques de redes y sus contenidos existentes usados en el entorno, después de lo cual puede asignar y/o liberar automáticamente bloques de red, prefijos de red, redes, subredes, microsegmentos y similares a los orquestadores de servicios norte y a los controladores SDN sur, y, opcionalmente, para mediar en los cambios realizados, ya sea en dirección norte o en dirección sur, al orquestador u orquestadores y/o controlador o controladores en el lado opuesto.

El DNPP, por lo tanto, tiene orquestadores que configuran cargas de trabajo (hosts de red) en su lado norte, e infraestructura de red (que incluye los controladores SDN) en su lado sur. Técnicamente, la diferencia en este punto es que, en las integraciones norte, el DNPP es la tecnología que tiene una API lógica de negocios y los clientes se ubican en los orquestadores. En las integraciones sur (como SDN), el DNPP tiene un cliente lógica de negocios y el controlador SDN (o SD-WAN) proporciona la API. El esquema de pensamiento se puede visualizar como una pila, en donde cada capa que se conecta hacia abajo es la que tiene el cliente que está conectado "sur" a una API.

El IPCDS incluye una API y una lógica de negocios. El cliente siempre está en el orquestador. El DNPP incluye una API, una lógica de negocio y un cliente. La API se usa cuando el DNPP proporciona redes (ampliamente usadas) a un orquestador y, en este caso, el cliente está en el orquestador. Pero para introducir una red (nuevamente en términos generales) en un controlador SDN o SD-WAN, en realidad usaríamos un cliente que está en nuestro dispositivo y usaríamos la API que proporciona el SDN o SD-WAN (o pila en la nube).

Una de las características de la presente invención se refiere a situaciones en donde una red, subred o un microsegmento que se ejecuta en el entorno de red elástica deja de existir o se migra a otro entorno de red elástica. Esto es posible en entornos de red de la próxima generación en los que las redes se tratan como un recurso bajo demanda, activado y reactivado automáticamente según sea necesario. En el estado de la técnica, la falta de información precisa sobre qué recursos de red se están usando y cuáles simplemente se asignan, pero no se usan, hace imposible crear un flujo de trabajo de servicio automatizado en torno a la asignación y liberación de recursos de red. En la presente invención, la información sobre el recurso de red liberado puede obtenerse leyéndolo de las configuraciones de un controlador SDN integrado. Como resultado de esta información, el proceso DNPP inventivo liberará automáticamente los recursos, tal como el prefijo de red, anteriormente asignados a una red que ya no existe. El DNPP de la presente invención se comunica con el controlador SDN integrado cuando dicho sistema se está desactivando o migrando redes a otro entorno. El uso de la arquitectura cliente-servidor proporciona el beneficio de que el proceso DNPP inventivo puede obtener información en tiempo real con respecto a si un recurso de red dado se está usando o no realmente para algo.

La invención se refiere a entornos informáticos orquestados que utilizan arquitecturas basadas en API, y en los que la asignación de recursos de red debe llevarse a cabo como parte del proceso de activación y/o desactivación gestionado por el controlador SDN.

El proceso DNPP comprende además una interfaz de usuario remota, tal como una interfaz de usuario basada en web, que se puede usar para acceder a los datos gestionados en/por el proceso DNPP. La interfaz de usuario remota proporciona la capacidad de rastrear la asignación y los niveles de uso de los bloques de red casi en tiempo real. Otras características deseables incluyen la capacidad de los administradores para monitorizar de manera transparente estos niveles en tiempo real; para soportar entornos de múltiples abonados, incluyendo la posibilidad de ofrecer a los usuarios finales internos y/o externos un acceso restringido/derechos de visualización a los bloques de red usados por ellos; y la capacidad de gestionar bloques de red etiquetándolos con los atributos o propiedades seleccionados. La razón por la que la última parte es importante es que, para asignar prefijos de red, redes, subredes, microsegmentos y similares desde el bloque de red correcto, el bloque de red debe estar etiquetado con uno o más identificadores únicos presentes en las llamadas del cliente. Y para gestionar todo esto, se prefiere una interfaz gráfica de usuario (GUI) para muchos usuarios administrativos.

El proceso DNPP comprende además una segunda lógica configurada para asociar bloques de red y/o prefijos de red individuales con un cliente dado y, en caso de que un bloque de red y/o prefijos de red asignados estén llenos, el proceso DNPP está configurado para aprovisionar automáticamente un recurso de red (por ejemplo, un prefijo de red) de un bloque de red alternativo con el cliente y/o de un grupo de reserva de recursos de red.

Aún más, el DNPP también contiene una o más implementaciones de software de cliente mediante las que la arquitectura cliente-servidor está comprendida entre el DNPP (cliente) y un controlador SDN (servidor).

En lo que respecta al cliente (no incluido en la redacción de las reivindicaciones), el cliente implementado en el DNPP recoge el recurso de red asignado a un orquestador y envía el mismo recurso de red al controlador SDN integrado para su activación. Como alternativa, el cliente implementado en el DNPP también puede tomar un recurso de red del proceso DNPP y enviar el recurso de red al controlador SDN integrado para su activación, sin implicar a ningún orquestador en dicho proceso.

Se puede acceder a la lógica de proceso de aprovisionamiento de red dinámica ("DNPP") a través de una interfaz gráfica de usuario (GUI), una interfaz de línea de comandos (CLI) y/o una interfaz de programación de aplicaciones (API), y también puede usarse para asignar automáticamente prefijos de red adecuados a través de llamadas realizadas por sistemas de terceros, tales como orquestadores de servicios a través de la API.

El DNPP puede implementarse como un aparato independiente (servidor) cuando se usa para aprovisionar definiciones de red a orquestadores de terceros. Como se usa en el presente documento, una definición de red significa información (conjunto de parámetros) que define a cuál de varias redes se refiere. Una lista ilustrativa de definiciones de red incluye prefijos de red gratuitos, subredes, máscaras de red (máscaras de red) o similares. Si el DNPP se implementa como un servidor, puede denominarse servidor de aprovisionamiento de red dinámica o "servidor DNPP". En la mayoría de los casos, servidor DNPP y DNPP son intercambiables.

El DNPP busca tales definiciones de red gratuitas basándose en identificadores únicos que incluyen, pero sin limitación, el nombre del abonado y/o cliente asociado con cada bloque de red gestionado. A continuación, el DNPP reserva un recurso de red del tamaño solicitado o configurado usando las herramientas de cálculo incluidas en el sistema; y, dependiendo del caso de uso, simplemente devuelve el recurso de red reservado al orquestador o devuelve el recurso de red reservado al orquestador y lo envía a un controlador SDN integrado (SDNC) o un controlador SD-WAN (SDWANC) a través de una interfaz ofrecida por el SDNC y/o SDWANC para servicio y/o activación de red.

Adicionalmente, una vez que el recurso de la red se ha introducido en el SDNC y/o SDWANC, el DNPP empieza a sondear el SDNC y/o SDWANC integrado para los parámetros de red configurados automáticamente y otras piezas de información disponibles a través de la interfaz proporcionada por el SDNC y/o el SDWANC. A medida que se descubren parámetros de red y otra información, el DNPP recupera esta información y la almacena en el aparato para su uso posterior. Los usos de tales datos incluyen, pero sin limitación, ver y gestionar los datos configurados automáticamente y el aprovisionamiento de los datos almacenados a organizadores de terceros, según sea apropiado.

Adicionalmente, en el caso de que los datos recuperados se usen para aprovisionar parámetros de red, la lógica puede combinarse con la solicitud de patente de Estados Unidos n.° USD20130346618 para llevar a cabo el aprovisionamiento según enseña dicha solicitud de patente a orquestadores de terceros.

Breve descripción de los dibujos

A continuación, la invención se describirá en mayor detalle por medio de realizaciones específicas con referencia a los dibujos adjuntos, en los que:

La Figura 1 es un diagrama a nivel de bloques de la arquitectura cliente-servidor de acuerdo con una realización de la invención;

La Figura 2, que consiste en los dibujos parciales 2A y 2B, es un diagrama de flujo que ilustra la operación de un servidor de proceso de aprovisionamiento de red dinámica (DNPP) durante el procesamiento de una solicitud de red desde un sistema de orquestación;

La Figura 3 es un diagrama a nivel de bloques de un servidor de aprovisionamiento de red dinámica (DNP) y un servidor de puesta en servicio/desmantelamiento de IP (IPCD) combinados;

La Figura 4, que consiste en los dibujos parciales 4A y 4B, es un diagrama de flujo que ilustra la operación de un servidor IPCD de acuerdo con un ejemplo;

La Figura 5 es un diagrama de flujo que ilustra un ejemplo de un proceso de aprovisionamiento de red dinámica (DNPP); y

La Figura 6 muestra esquemáticamente un diagrama de bloques ilustrativo para los diversos ordenadores servidor y/o cliente.

Descripción detallada de realizaciones específicas

La Figura 1 es un diagrama a nivel de bloques de una arquitectura cliente-servidor de acuerdo con una forma de realización de la invención. El signo de referencia DNPS indica un servidor de aprovisionamiento de red dinámica, que implementa el proceso de aprovisionamiento de red dinámica (DNPP) descrito anteriormente. El signo de referencia IU indica una interfaz de usuario que, preferentemente, es una interfaz de usuario remota, tal como una interfaz de usuario basada en web. La interfaz de usuario puede usarse para acceder a los datos que el servidor DNPS gestiona en una base de datos BD. El signo de referencia NME indica un motor de gestión de red, que implementa diversas lógicas de gestión relacionadas con redes de puesta en servicio/desmantelamiento y, opcionalmente, recursos IP dentro de las redes gestionadas.

La Figura 1 muestra una realización ambiciosa que tiene dos mecanismos paralelos para la puesta en servicio/desmantelamiento dinámico de redes. El lado izquierdo de la Figura 1, debajo del motor de gestión de red NME, está relacionado con una implementación que utiliza uno o más orquestadores (servidores que ejecutan la solución de orquestación). El signo de referencia API indica una interfaz de programación de aplicaciones en el motor de gestión de red NME que soporta la arquitectura orientada a servicios (SOA) para un cliente (conector de cliente) en un SO de orquestador. El lado derecho de la Figura 1, debajo del motor de gestión de red NME, está relacionado con una implementación que utiliza uno o más controladores de red definidos por software SDNC. Para la implementación basada en SDNc , el motor de gestión de red NME tiene un conector de cliente CLC, que se conecta a una interfaz de programación de aplicaciones en el controlador SDN, indicada SDN-API. Una realización del motor de gestión de red NME de acuerdo con la presente divulgación puede implementar tanto la implementación basada en SOA como la implementación basada en SDN, o ambas.

La lógica implementada por el motor de gestión de red NME asigna y libera dinámicamente recursos de red, tales como bloques de red, prefijos de red, redes, subredes o microsegmentos basándose en las solicitudes recibidas a través de la interfaz de programación de aplicaciones API y/o el conector de cliente CLC. El motor de gestión de red NME asocia además bloques de red y/o prefijos de red individuales con clientes dados y, en caso de que un bloque de red y/o prefijos de red asignados estén llenos, aprovisiona automáticamente un recurso de red (por ejemplo, un prefijo de red) de un bloque de red alternativo con el cliente y/o de un grupo de reserva de recursos de red.

Para la implementación basada en SOA, el signo de referencia CL indica un ordenador cliente de la arquitectura cliente-servidor. El ordenador cliente CL se ejecuta en, o en conexión con, un SO de solución de orquestación que se comunica con el servidor DNPS a través de la API de interfaz de programación de aplicaciones basada en s Oa . El SO de la solución de orquestación soporta un número de instancias de servidor SI. En una implementación típica, las instancias de servidor SI son máquinas virtuales VM, cada una de las cuales tiene una carga de trabajo respectiva. El servidor DNPP se muestra como un servidor separado del sistema operativo del sistema de orquestación (orquestador), pero las implementaciones integradas son igualmente posibles. La implementación basada en SDN opera de manera análoga a la basada en SOA. Una o ambas tecnologías pueden implementarse en una realización física.

La Figura 2, que consiste en los dibujos parciales 2A y 2B, es un diagrama de flujo que ilustra etapas de procesamiento detalladas en una realización de un proceso DNPP, durante el procesamiento de una solicitud de red desde un sistema de orquestación SO. Para los propósitos de la Figura 2, el proceso DNP ("DNPP") y el servidor DNP ("DNPS") son intercambiables. El "servidor" implica un servidor especializado, mientras que "proceso" implica que la funcionalidad puede proporcionarse a través de otras implementaciones, tales como servidores distribuidos y/o servidores que también se usan para otros propósitos.

En la etapa 2-2, el SO del sistema de orquestación envía una solicitud de red, que se recibe por el DNPP. En la etapa 2-4, el DNPP comprueba si la solicitud de red incluye un nombre de abonado/cliente. En caso afirmativo, el proceso continúa a la etapa 2-10, en la que el DNPP comprueba si el nombre del abonado/cliente se ha etiquetado en un bloque de red. En caso afirmativo, el proceso continúa a la etapa 2-16, en la que el DNPP comprueba si la solicitud incluye una dirección IP o una máscara de bits. En caso afirmativo, el DNPP comprueba, en la etapa 2­ 20, si está disponible la red y/o la máscara de bits solicitadas en un bloque de red etiquetado con el nombre del abonado/cliente. Si el resultado de todas las comprobaciones 2-4, 2-10, 2-16 y 2-20 es positivo, la DNPP continúa a la etapa 2-24, en la que reserva la red solicitada del bloque de red marcado para el abonado/cliente y la devuelve al orquestador.

Si la comprobación 2-16 devuelve un resultado negativo, el DNPP comprueba, en la etapa 2-18, si se ha configurado una máscara de bits por defecto para el DNPP. En caso afirmativo, el proceso continúa a la etapa 2­ 22 para comprobar si está disponible la máscara de bits por defecto en el bloque de red etiquetado con el nombre de abonado/cliente. Si es así, el proceso continúa a la etapa 2-24, que se ha descrito anteriormente.

La lógica que se describe en este punto se basa en la opinión de que la red se asignaría principalmente basándose en un nombre de cliente (abonado), que se etiquetaría en el bloque de red o, posiblemente, en un prefijo dado debajo de él. Si no hay un nombre de abonado o cliente, la segunda posibilidad es que el orquestador a) solicite un prefijo específico de un bloque de red dado (esto se escribiría como IP/máscara de bits, por ejemplo, 123.123.123.123/28), o b) solicitando una máscara de bits específica (por ejemplo, solo /28). Si no se aplica ni a) ni b), a continuación, lo más probable es que una red de tamaño por defecto provenga de un bloque/prefijo público donde el único requisito es que la asignación no se superponga. Si se solicita un tamaño de máscara de bits específico (pero no hay una dirección IP delante), a continuación, la asignación probablemente sea una red de tamaño adecuado desde un bloque/prefijo público. Una suposición adicional en este punto es que, si la solicitud incluye una dirección/prefijo IP, podría provenir de un bloque privado o público. Si es solo un prefijo (sin dirección IP), a continuación, lógicamente uno por defecto sería un bloque público.

Si la comprobación 2-4 o 2-10 devuelve un resultado negativo, el DNPP continúa a la etapa 2-6, en la que el DNPP comprueba si la solicitud incluye una dirección IP o una máscara de bits. En caso afirmativo, el DNPP comprueba, en la etapa 2-12, si está disponible la red y/o la red pública solicitadas del tamaño de mapa de bits solicitado. En caso afirmativo, el DNPP reserva la red solicitada y la devuelve al orquestador en la etapa 2-26. Si la comprobación 2-6 devuelve un resultado negativo, el DNPP comprueba, en la etapa 2-8, si se ha configurado una máscara de bits por defecto para el DNPP. En caso afirmativo, el proceso continúa a la etapa 2-14 para comprobar si está disponible una red con el tamaño de máscara de bits por defecto en el bloque o bloques públicos. En caso afirmativo, el DNPP reserva la red solicitada y la devuelve al orquestador en la etapa 2-26.

Si alguna de las comprobaciones 2-8, 2-12, 2-14, 2-18, 2-20 o 2-22 devuelve un resultado negativo, el proceso continúa con a una de las etapas 2-30, 2-32, 2- 34 o 2-36, para devolver una condición de error. El diagrama de flujo de la Figura 2 muestra una leyenda idéntica para todas las indicaciones de error, pero las condiciones e indicaciones de error detalladas pueden diferir.

La Figura 2 ilustra por lo tanto la operación de una realización ambiciosa, en donde el motor de gestión de red NME puede asignar redes de múltiples maneras (como se muestra, a través de procesos que conducen a las etapas 2-20, 2-22, 2-12 y 2-14). Una realización menos ambiciosa puede implementar cualquier subconjunto de estos procesos.

La Figura 3 es un diagrama a nivel de bloques de una arquitectura cliente-servidor de acuerdo con una forma de realización de la invención. El signo de referencia IPCDS indica un servidor de puesta en servicio/desmantelamiento de IP (servidor IPCD). El signo de referencia IU indica una interfaz de usuario que, preferentemente, es una interfaz de usuario remota, tal como una interfaz de usuario basada en web. La interfaz de usuario se puede usar para acceder a los datos gestionados en el servidor IPCDS. El signo de referencia API indica una interfaz de programación de aplicaciones que soporta la arquitectura orientada a servicios (SOA). El signo de referencia BL indica una lógica de negocios, que puede asignar y liberar dinámicamente recursos IP, tales como direcciones IP, nombres y otras configuraciones de red basadas en llamadas recibidas a través de la API. La presente realización del servidor IPCDS comprende dos motores de gestión ME1 y ME2, que corresponden respectivamente a la primera lógica y la segunda lógica, y que están configurados colectivamente para asociar redes individuales con usuarios finales dados y, en el caso de que se haya asignado por completo una red, el servidor IPCDS está configurado para aprovisionar automáticamente un recurso IP (por ejemplo, una dirección IP) desde una red alternativa asociada con el usuario final interno y/o externo y/o desde un grupo de reserva de recursos IP.

El signo de referencia CL indica un ordenador cliente de la arquitectura cliente-servidor inventiva. El ordenador cliente CL se ejecuta en, o en conexión con, un SO de solución de orquestación que se comunica con el servidor IPCDS a través de la API de interfaz de programación de aplicaciones basada en SOA. El SO de la solución de orquestación soporta un número de instancias de servidor SI. En una implementación típica, las instancias de servidor SI son máquinas virtuales, cada una de las cuales tiene una carga de trabajo respectiva.

La Figura 4, que consiste en los dibujos parciales 4A y 4B, es un diagrama de flujo que ilustra la operación de un servidor IPCDS de acuerdo con un ejemplo. En la etapa 4-2, el sistema de orquestación envía una solicitud al servidor IPCDS, en donde la solicitud identifica la VLAN de red de área local virtual en la que ha de desplegarse un host. En la etapa 4-4, el servidor IPCDS examina si la VLAN está etiquetada en una red gestionada por el sistema IPCD actual. Si no, el flujo continúa a la etapa 4-46 (véase el dibujo 2B), en donde el servidor IPCD devuelve un mensaje de error que indica la causa del error. Si en la etapa 4-4 el resultado es positivo, el flujo continúa a la etapa 4-6, en donde el servidor IPCD examina si la emisión de una dirección IP fue parte de la solicitud. En caso afirmativo, el flujo continúa a la etapa 4-14, en donde el servidor IPCD examina si hay disponible una dirección IP libre en la primera red asociada con la VLAN. En caso afirmativo, el flujo continúa a la etapa 4-20, en donde el servidor IPCD examina si la emisión de un nombre fue parte de la solicitud. Si lo fue, el flujo continúa a la etapa 4-30, en donde el servidor IPCD reserva una dirección IP libre y genera un nombre único que lo adjunta a una zona por defecto configurada en la red asociada con la VLAN. A continuación, el servidor IPCD devuelve el nombre único y la dirección IP al SO del sistema de orquestación y marca la dirección IP como usada en la red desde la que se asignó. Si el resultado de la etapa 4-20 fue negativo, el flujo continúa a la etapa 4-32, en donde el servidor IPCD reserva una dirección IP libre, la devuelve al SO del sistema de orquestación y marca la dirección IP como usada en la red desde la que se asignó.

Si el resultado de la etapa 4-6 fue negativo, el flujo continúa a la etapa 4-8, en donde el servidor IPCD examina si la emisión de un nombre fue parte de la solicitud. En caso afirmativo, el flujo continúa a la etapa 4-38, en donde el servidor IPCD devuelve un nombre generado automáticamente que lo adjunta a una zona por defecto configurada en la red asociada con la VLAN y devuelve el nombre único al SO del sistema de orquestación. Si el resultado de la etapa 4-8 fue negativo, el flujo continúa a la etapa 4-10, en donde el servidor IPCD examina si la liberación de una dirección IP fue parte de la solicitud. En caso afirmativo, el flujo continúa a la etapa 4-18, en donde el servidor IPCD examina si la liberación de un nombre usado fue parte de la solicitud. En caso afirmativo, el flujo continúa a la etapa 4-40, en donde el servidor IPCD libera el nombre y la dirección IP usados de la red que coincide con la VLAN asociada y devuelve una confirmación al SO del sistema de orquestación. Si el resultado de la etapa 4-18 fue negativo, el flujo continúa a la etapa 4-42, en donde el servidor IPCD libera la IP usada de la red que coincide con la VLAN asociada y devuelve una confirmación al SO del sistema de orquestación.

En el presente ejemplo, si el resultado de la etapa 4-10 fue negativo, el flujo continúa a la etapa 4-12, en donde el servidor IPCD advierte que la solicitud no se relaciona con ninguna de las funciones del servidor IPCD y devuelve un mensaje de error. En implementaciones más ambiciosas con más funciones, el ramal de la etapa 4-12 a la derecha puede continuar con más pruebas y funciones.

Si el resultado de la etapa 4-14 fue negativo, el flujo continúa a la etapa 4-16, en donde el servidor IPCD examina si hay otras redes etiquetadas con la misma VLAN. Si las hay, el flujo continúa a la etapa 4-22, en donde el servidor de IPCD examina si hay direcciones IP libres en las otras redes. Si las hay, el servidor IPCD examina, en la etapa 4- 24, si la emisión de un nombre fue parte de la solicitud. En caso afirmativo, el flujo continúa a la etapa 4-30 descrita anteriormente. Si no, el flujo continúa a la etapa 4-34, en donde el servidor IPCD devuelve la dirección IP libre al SO del sistema de orquestación y la marca como usada en la red desde la que se asignó la IP.

Si el resultado de la etapa 4-16 o 4-22 es negativo, el flujo continúa a la etapa 4-36, en donde el servidor IPCD devuelve un nombre generado automáticamente que lo adjunta a una zona por defecto configurada en la red asociada con la VLAN y devuelve el nombre único al SO del sistema de orquestación.

La Figura 5 es un diagrama de flujo que ilustra un ejemplo de un proceso de aprovisionamiento de red dinámica (DNPP). En la etapa 5-2, el servidor DNPP crea una nueva red dentro de un bloque de red existente. En la etapa 5- 10, el servidor DNPP comprueba si un orquestador inició la adición de la nueva red. En caso afirmativo, el flujo continúa a la etapa 5-20. Si no, el flujo continúa a la etapa 5-22. En la etapa 5-20, el DNPP comprueba si la llamada solicitó que la red se añada al controlador SDN o SD-WAN. En caso afirmativo, el flujo continúa a la etapa 5-22, en donde el DNPP comprueba si el usuario especificó manualmente un controlador SDN/SD-WAN responsable de la red.

Si el resultado de la comprobación 5-20 es negativo, el flujo continúa a la etapa 5-30, en donde el DNPP comprueba si la llamada especificó un controlador SDN o SD-WAN responsable que debe monitorizarse para la red. En caso afirmativo, el flujo continúa a la etapa 5-40, en donde el DNPP marca la red como reservada en el DNPP y la devuelve al orquestador. También empieza a monitorizar el controlador SDN/SD-WAN especificado para la nueva red a través de su API y sincroniza de vuelta las configuraciones creadas y/o realizadas por el controlador SDN/SD-WAN en intervalos regulares con la red coincidente en DNPP.

Si el resultado de la comprobación 5-30 es negativo, el flujo continúa a la etapa 5-42, en donde el DNPP marca la red como reservada en el DNPP y la devuelve al orquestador, omitiendo por lo tanto los aspectos de monitorización y sincronización relacionados con SDN de la etapa 5-40.

Si el resultado de la comprobación 5-22 es positivo y el usuario especificó manualmente un controlador SDN/SD-WAN responsable de la red, el flujo continúa a la etapa 5-44, en donde el DNPP añade la nueva red al controlador SDN/SD-WAN especificado a través de su API. Una vez configurado, el DNPP lee las configuraciones realizadas por el controlador SDN/SD-WAN a intervalos regulares y las sincroniza de vuelta al DNPP.

Si el resultado de la comprobación 5-22 es negativo, el flujo continúa a la etapa 5-32, en donde el DNPP comprueba si existe un controlador SDN por defecto asociado con el bloque de red. En caso afirmativo, el flujo continúa a la etapa 5-46, en donde DNPP añade la nueva red al controlador SDN/SD-WAN por defecto a través de su API. Una vez añadido, el DNPP lee las configuraciones creadas o efectuadas por el controlador SDN/SD-WAN a intervalos regulares y las sincroniza de vuelta con una red coincidente en el DNPP. Finalmente, si el resultado de la comprobación 5-32 es negativo, el flujo continúa a la etapa 5-48, en donde el DNPP marca la red como reservada en el DNPP.

La Figura 6 muestra esquemáticamente un diagrama de bloques ilustrativo para los diversos elementos de procesamiento de información. La arquitectura de procesamiento de datos mostrada en la Figura 6, indicada generalmente por el número de referencia 6-100, puede usarse para implementar los servidores y clientes de la presente invención. Se muestra una configuración apropiada para un servidor; la configuración de un ordenador cliente puede ser más sencilla. Los dos bloques funcionales principales de la arquitectura de procesamiento de datos son un sistema de procesamiento 6-100 y un sistema de almacenamiento 6-190. El sistema de procesamiento 6-100 comprende una o más unidades centrales de procesamiento CP1... CPn, generalmente indicadas por el número de referencia 6-110. Las unidades de procesamiento pueden ser unidades de procesamiento nativas o virtuales. Las realizaciones que comprenden múltiples unidades de procesamiento 6-110 se proporcionan preferentemente con una unidad de equilibrio de carga 6-115 que equilibra la carga de procesamiento entre las múltiples unidades de procesamiento 6-110. Las múltiples unidades de procesamiento 6­ 110 pueden implementarse como componentes de procesador separados o como núcleos de procesador físico o procesadores virtuales dentro de una carcasa de un único componente. El sistema de procesamiento 6-100 comprende además una interfaz de red 6-120 para comunicarse con diversas redes de datos, que generalmente se indican por el signo de referencia DN. Las redes de datos DN pueden incluir redes de área local, tales como una red Ethernet, y/o redes de área amplia, tales como Internet. El número de referencia 6-125 indica una interfaz de red móvil, a través de la que el sistema de procesamiento 6-100 puede comunicarse con diversas redes de acceso AN, que dan servicio a los nodos de red inalámbrica. Una configuración que soporta múltiples redes diferentes permite que el sistema de procesamiento 6-100 soporte múltiples tipos de clientes, tales como terminales terrestres 6-200 y terminales móviles 6-210.

El sistema de procesamiento 6-100 de la presente realización también puede comprender una interfaz de usuario local 6-140. Dependiendo de la implementación, la interfaz de usuario 6-140 puede comprender circuitería de entrada-salida local para una interfaz de usuario local, tal como un teclado, un ratón y una pantalla (no mostrados). Como alternativa o adicionalmente, la gestión del sistema de procesamiento 6-100 puede implementarse de forma remota, utilizando la interfaz de red 6-120 y cualquier terminal habilitado para Internet que proporcione una interfaz de usuario. La naturaleza de la interfaz de usuario depende del tipo de ordenador que se use para implementar el sistema de procesamiento 6-100. Si el sistema de procesamiento 6-100 es un ordenador especializado, es posible que no necesite una interfaz de usuario local, y el sistema de procesamiento 6-100 se puede gestionar de forma remota, tal como desde un navegador web a través de Internet, por ejemplo. Tal gestión remota se puede realizar a través de la misma interfaz de red 6-120 que utiliza el ordenador para el tráfico entre él mismo y los terminales cliente.

El sistema de procesamiento 6-100 también comprende memoria 6-150 para almacenar instrucciones de programa, parámetros operativos y variables. El número de referencia 6-160 indica un conjunto de programas para el sistema de procesamiento 6-100.

El sistema de procesamiento 6-100 también comprende circuitería para diversos relojes, interrupciones y similares, y estos se representan generalmente con el número de referencia 6-130. El sistema de procesamiento 6-100 comprende además una interfaz de almacenamiento 6-145 para el sistema de almacenamiento 6-190. Cuando el sistema de procesamiento 6-100 se apaga, el sistema de almacenamiento 6-190 puede almacenar el software que implementa las funciones de procesamiento y, al encenderse, el software se lee en la memoria de semiconductores 6-150. El sistema de almacenamiento 6-190 también mantiene variables y operaciones durante los períodos de apagado. En implementaciones de gran volumen, es decir, implementaciones en donde un único sistema de procesamiento 6-100 da servicio a un gran número de clientes a través de terminales móviles respectivos MT, el sistema de almacenamiento 6-190 puede usarse para almacenar las matrices de diálogo dinámico asociadas con los clientes y terminales móviles MT. Los diversos elementos 6-110 a 6-150 se intercomunican a través de un bus 6-105, que lleva señales de dirección, señales de datos y señales de control, como es bien conocido por los expertos en la materia.

Será evidente para un experto en la materia que, a medida que la tecnología avanza, el concepto inventivo puede implementarse de diversas maneras. La invención y sus realizaciones no están limitadas a los ejemplos anteriormente descritos, sino al alcance de las reivindicaciones.

Claims (7)

REIVINDICACIONES

1. Un ordenador servidor (DNPS) para la puesta en servicio/desmantelamiento de redes que comprende una base de datos (BD) que comprende datos, caracterizado por que el ordenador servidor (DNPS) está configurado para poner en servicio/desmantelar redes para activarse/desactivarse por un controlador (SDNC) de interconexión en red definida por software, SDN, que constituye una arquitectura cliente-servidor con el ordenador servidor (DNPS), comprendiendo además el ordenador servidor (DNPS):

- una interfaz de usuario remota (IU) para la gestión remota de un controlador SDN (SDNC), en donde la interfaz de usuario remota (IU) proporciona acceso a los datos gestionados por el controlador SDN (SDNC); - un conector de cliente (CLC) para comunicarse con una interfaz de programación de aplicaciones (SDN-API) del controlador SDN (SDNC); y

- un motor de gestión de red (NME) para asignar y liberar dinámicamente redes para activarse/desactivarse por el controlador SDN (SNDC), en donde el motor de gestión de red (NME) está conectado a la base de datos (BD), a la interfaz de usuario remota (IU) y al conector de cliente (CLC), en donde el motor de gestión de red (NME) está configurado para realizar:

recibir, desde el controlador SDN (SDNC), una solicitud en la que se solicita una red; comprobar (2-4, 2-10) si la solicitud incluye un nombre de cliente o abonado etiquetado, en el ordenador servidor (DNPS, en un bloque de red gestionado por el ordenador servidor (DNPS), comprendiendo el bloque de red prefijos, redes y datos administrativos asociados;

en respuesta a que la solicitud incluye dicho nombre de cliente o abonado etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red (2-16), comprobar si está disponible la red y/o máscara de red solicitadas en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-20), y, si está disponible dicha red y/o máscara de red solicitadas, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN (SDNC) (2-24),

en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red (2-16), comprobar si una máscara de red por defecto está configurada en el ordenador servidor (DNPS) (2-18) y, si una máscara de red por defecto está configurada en el ordenador servidor (DNPS), si está disponible dicha máscara de red por defecto en el bloque de red etiquetado con dicho nombre de cliente o abonado (2­ 22) y, si está disponible dicha máscara de red por defecto, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN (SDNC) (2-24); y en respuesta a que la solicitud falla al incluir dicho nombre de cliente o abonado etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red (2-6), comprobar si está disponible la red y/o una red pública solicitadas del tamaño de la máscara de red (2-12) en un bloque de red pública o privada gestionado por el ordenador servidor (DNSP) y, si está disponible la red y/o dicha red pública solicitadas, reservar una red que se considere disponible y devolverla al controlador SDN (SDNC) (2-26), y

en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red (2-6), comprobar si una máscara de red por defecto está configurada en el ordenador servidor (DNPS) (2-8) y, si la máscara de red por defecto está configurada, si está disponible una red con un tamaño de máscara de red por defecto en al menos un bloque de red pública gestionada por el ordenador servidor (DNPS) (2-14) y, si está disponible la red con el tamaño de la máscara de red por defecto, reservar la red con el tamaño de la máscara de red por defecto y devolverla al controlador SDN (SDNC) (2­ 26).

2. El ordenador servidor (DNPS) de la reivindicación 1, en donde el motor de gestión de red (NME) está configurado además para realizar:

en respuesta a que cualquiera de una pluralidad de comprobaciones (2-8, 2-12, 2-14, 2-18, 2-20, 2-22) devuelve un resultado negativo, devolver una condición de error, en donde la pluralidad de comprobaciones consiste en:

la comprobación de si la máscara de red por defecto está configurada para el ordenador servidor (DNPS) (2­ 8), la comprobación de si está disponible la red y/o la red pública solicitadas del tamaño de la máscara de red (2-12),

la comprobación de si está disponible la red con el tamaño de la máscara de red por defecto en dicho al menos un bloque de red pública (2-14),

la comprobación de si la máscara de red por defecto está configurada para el ordenador servidor (DNPS) (2­ 18),

la comprobación de si está disponible la red y/o máscara de red solicitadas en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-20) y

la comprobación de si está disponible dicha máscara de red por defecto en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-22).

3. El ordenador servidor (DNPS) de la reivindicación 1, en donde el motor de gestión de red (NME) está configurado para asignar y liberar dinámicamente bloques de red y prefijos de red individuales, redes, subredes y microsegmentos dentro de cada bloque de red.

4. El ordenador servidor (DNPS) de la reivindicación 1, en donde el ordenador servidor (DNPS) está configurado, en respuesta a la detección de que una red previamente asignada ya no se está usando más, para liberar la red previamente asignada.

5. El ordenador servidor (DNPS) de la reivindicación 1, en donde el ordenador servidor (DNPS) está configurado para realizar dicha detección rastreando el uso real de la red previamente asignada.

6. Un método para la puesta en servicio/desmantelamiento de redes, caracterizado por que el método comprende:

- usar un ordenador servidor (DNPS) para la puesta en servicio/desmantelamiento de redes que van a activarse/desactivarse por un controlador de interconexión en red definida por software, SDN, (SDNC), comprendiendo el ordenador servidor (DNPS) una base de datos, un conector de cliente (CLC), una interfaz de usuario remota (IU) y un motor de gestión de red (NME) conectado a la base de datos (BD), el conector de cliente (CLC) y la interfaz de usuario remota (IU), en donde el controlador SDN (SDNC) y el ordenador servidor (DNPS) constituyen una arquitectura cliente-servidor;

- gestionar el controlador ^s Dⁿ (SDNC) de forma remota usando la interfaz de usuario remota (IU), en donde la interfaz de usuario remota (IU) proporciona acceso a los datos gestionados por el controlador SDN (SDNC); - comunicarse con la interfaz de programación de aplicaciones (SDN-API) del controlador SDN (SDNC) usando el conector de cliente (CLC); y

- asignar y liberar dinámicamente redes para que se activen/desactiven por uno o más controladores SDN (SDNC) usando el motor de gestión de red (NME), en donde la asignación comprende:

- recibir, desde el controlador SDN (SDNC), una solicitud en la que se solicita una red;

- comprobar (2-4, 2-10) si la solicitud incluye un nombre de cliente o abonado etiquetado, en el ordenador servidor (DNPS, en un bloque de red gestionado por el ordenador servidor (DNPS), comprendiendo el bloque de red prefijos, redes y datos administrativos asociados;

- en respuesta a que la solicitud incluye dicho nombre de cliente o abonado etiquetado en el bloque de red (2­ 4, 2-10), realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red (2-16), comprobar si está disponible la red y/o máscara de red solicitadas en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-20), y, si está disponible dicha red y/o máscara de red solicitadas, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN (SD-NC) (2-24),

en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red (2-16), comprobar si una máscara de red por defecto está configurada en el ordenador servidor (DNPS) (2-18) y, si una máscara de red por defecto está configurada en el ordenador servidor (DNPS), si está disponible dicha máscara de red por defecto en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-22) y, si está disponible dicha máscara de red por defecto, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN (SDNC) (2-24); y

- en respuesta a que la solicitud falla al incluir dicho nombre de cliente o abonado etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red (2-6), comprobar si está disponible la red y/o una red pública solicitadas del tamaño de la máscara de red en un bloque de red pública o privada gestionado por el ordenador servidor (DNSP) (2-12) y, si está disponible la red y/o dicha red pública solicitadas, reservar una red que se considere disponible y devolverla al controlador SDN (SDNC) (2-26), y

en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red (2-6), comprobar si una máscara de red por defecto está configurada en el ordenador servidor (DNPS) (2-8) y, si la máscara de red por defecto está configurada, si está disponible una red con un tamaño de máscara de red por defecto en al menos un bloque de red pública gestionada por el ordenador servidor (DNPS) (2-14) y, si está disponible la red con el tamaño de la máscara de red por defecto, reservar la red con el tamaño de la máscara de red por defecto y devolverla al controlador SDN (SDNC) (2-26).

7. Una memoria legible por ordenador que almacena instrucciones de código de programa para un ordenador servidor (DNPS) para poner en servicio/desmantelar redes, caracterizada por que dichas redes han de activarse/desactivarse por un controlador (SDNC) de red definida por software, SDN, y el ordenador servidor (DNPS) comprende una base de datos (BD), un conector de cliente (CLC), una interfaz de usuario remota (IU) y un motor de gestión de red (NME) conectado a la base de datos (BD), al conector de cliente (CLC) y a la interfaz de usuario remota (IU) y el controlador SDN (SDNC) y el ordenador servidor (DNPS) constituyen una arquitectura cliente-servidor, en donde la ejecución de las instrucciones de código de programa almacenadas en el ordenador servidor (DNPS) da instrucción al ordenador servidor (DNPS) para:

- permitir la gestión del controlador SDN (SDNC) de forma remota usando la interfaz de usuario remota (IU), en donde la interfaz de usuario remota (IU) proporciona acceso a los datos gestionados por el controlador SDN (SDNC);

- comunicarse con una interfaz de programación de aplicaciones (SDN-API) del controlador SDN (SDNC) usando el conector de cliente (CLC); y

- asignar y liberar dinámicamente redes para activarse/desactivarse por el controlador SDN (SDNC), en donde la asignación comprende:

- recibir, desde el controlador SDN (SDNC), una solicitud en la que se solicita una red;

- comprobar (2-4, 2-10) si la solicitud incluye un nombre de cliente o abonado etiquetado, en el ordenador servidor (DNPS, en un bloque de red gestionado por el ordenador servidor (DNPS), comprendiendo el bloque de red prefijos, redes y datos administrativos asociados;

- en respuesta a que la solicitud incluye dicho nombre de cliente o abonado etiquetado en el bloque de red (2­ 4, 2-10), realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red (2-16), comprobar si está disponible la red y/o máscara de red solicitadas en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-20), y, si está disponible dicha red y/o máscara de red solicitadas, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN (SD-NC) (2-24),

en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red (2-16), comprobar si una máscara de red por defecto está configurada en el ordenador servidor (DNPS) (2-18) y, si una máscara de red por defecto está configurada en el ordenador servidor (DNPS), si está disponible dicha máscara de red por defecto en el bloque de red etiquetado con dicho nombre de cliente o abonado (2-22) y, si está disponible dicha máscara de red por defecto, reservar la red solicitada del bloque de red etiquetado con dicho nombre de cliente o abonado y devolverlo al controlador SDN (SDNC) (2-24); y

- en respuesta a que la solicitud falla al incluir dicho nombre de cliente o abonado etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente:

en respuesta a que la solicitud incluye una dirección IP o una máscara de red (2-6), comprobar si está disponible la red y/o una red pública solicitadas del tamaño de la máscara de red en un bloque de red pública o privada gestionado por el ordenador servidor (DNSP) (2-12) y, si está disponible la red y/o dicha red pública solicitadas, reservar una red que se considere disponible y devolverla al controlador SDN (SDNC) (2-26), y

en respuesta a que la solicitud falla al incluir una dirección IP o una máscara de red (2-6), comprobar si una máscara de red por defecto está configurada en el ordenador servidor (DNPS) (2-8) y, si la máscara de red por defecto está configurada, si está disponible una red con un tamaño de máscara de red por defecto en al menos un bloque de red pública gestionada por el ordenador servidor (DNPS) (2-14) y, si está disponible la red con el tamaño de la máscara de red por defecto, reservar la red con el tamaño de la máscara de red por defecto y devolverla al controlador SDN (SDNC) (2-26).