ES2876245T3

ES2876245T3 - Redes de puesta en servicio/desmantelamiento en entornos informáticos orquestados o definidos por software

Info

Publication number: ES2876245T3
Application number: ES17706207T
Authority: ES
Inventors: Juha Holkkola
Original assignee: FusionLayer Oy
Current assignee: FusionLayer Oy
Priority date: 2016-02-18
Filing date: 2017-02-17
Publication date: 2021-11-12
Anticipated expiration: 2037-02-17
Also published as: CN108886475B; CN108886475A; EP3860050A1; EP3417570B1; WO2017140867A1; FI3860050T3; EP3860050B1; JP2019506095A; JP6905990B2; ES2951319T3; EP3417570A1

Abstract

Un ordenador servidor (DNPS) para redes de puesta en servicio/desmantelamiento y aprovisionamiento de dichas redes a un sistema de orquestación (OS) que constituye una arquitectura cliente-servidor con el ordenador servidor (DNPS), comprendiendo el ordenador servidor (DNPS): - una base de datos (DB) que comprende datos; - una interfaz de usuario (UI) remota para gestión remota del ordenador servidor (DNPS), en donde la interfaz de usuario (UI) remota proporciona acceso a los datos en la base de datos (DB); - una interfaz de programación de aplicaciones (API) basada en red que soporta arquitectura orientada a servicios ["SOA"] para un cliente (CL) del sistema de orquestación (OS); y - un motor de gestión de red (NME) para asignar y liberar redes dinámicamente y aprovisionar dichas redes al cliente (CL) del sistema de orquestación (OS), en donde el motor de gestión de red (NME) está conectado a la base de datos (DB), la interfaz de usuario (UI) remota y la interfaz de programación de aplicaciones (API) basada en red, estando el motor de gestión de red (NME) Z configurado para recibir, desde el sistema de orquestación (OS), una solicitud en la cual se solicita una red caracterizado porque el motor de gestión de red está configurado para realizar: verificar (2-4, 2-10) si la solicitud incluye un nombre de cliente o inquilino 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 la solicitud que incluye dicho nombre de cliente o inquilino etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente: en respuesta a la solicitud que incluye una dirección de IP o una máscara de red (2-16), verificar si la red solicitada y/o máscara de red está disponible en el bloque de red etiquetado con dicho nombre de cliente o inquilino (2-20), y, si dicha red solicitada y/o máscara de red está disponible, reservar la red solicitada desde el bloque de red etiquetado con dicho nombre de cliente o inquilino y retornarla al sistema de orquestación (OS) (2-24), en respuesta a la solicitud que falla en incluir ya sea una dirección de IP o una máscara de red (2-16), verificar si una máscara de red predeterminada está configurada para el ordenador servidor (DNPS) (2-18) y, si una máscara de red predeterminada está configurada en el ordenador servidor (DNPS), si dicha máscara de red predeterminada está disponible en el bloque de red etiquetado con dicho nombre de cliente o inquilino (2-22), y, si dicha máscara de red predeterminada está disponible, reservar la red solicitada desde el bloque de red etiquetado con dicho nombre de cliente o inquilino y retornarla al sistema de orquestación (OS) (2-24); y en respuesta a la solicitud que falla en incluir dicho nombre de cliente o inquilino etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente: en respuesta a la solicitud que incluye una dirección de IP o una máscara de red (2-6), verificar si la red solicitada y/o una red pública de un tamaño de la máscara de red está disponible (2-12) en un bloque de red pública o privada gestionado por el ordenador servidor (DNPS), y, si la red solicitada y/o dicha red pública está disponible, reservar una red considerada que va a estar disponible y retornarla al sistema de orquestación (OS) (2-26), y en respuesta a la solicitud que falla en incluir una dirección de IP o una máscara de red (2-6), verificar si una máscara de red predeterminada está configurada para el ordenador servidor (DNPS) (2-8) y, si la máscara de red predeterminada está configurada, si una red con un tamaño de la máscara de red predeterminada está disponible en al menos un bloque de red pública gestionado por el ordenador servidor (DNPS) (2-14), y, si la red con el tamaño de la máscara de red predeterminada está disponible, reservar la red con el tamaño de la máscara de red predeterminada y retornarla al sistema de orquestación (OS) (2-26).

Description

DESCRIPCIÓN

Redes de puesta en servicio/desmantelamiento en entornos informáticos orquestados o definidos por software

Historia de caso anterior

La presente solicitud es una continuación en parte de la solicitud de patente de propiedad común número de serie 13/921,361, titulada "Method and apparatus for IP commissioning and decommissioning in orchestrated computing environments", presentada el 19 de junio de 2013, publicada como US20130346618, que reivindica la prioridad de la solicitud de patente finlandesa 20125680, presentada el 20 de junio de 2012.

Campo

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

Antecedentes

Como se ha conocido desde hace mucho tiempo, el Protocolo de Internet v. 4 (IPv4) es bastante limitado en términos de espacio de direcciones disponible. Para abordar el problema, el estándar RFC1918 define tres redes previstas para uso privado, a saber 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 al Internet público. Las grandes corporaciones y proveedores de servicios típicamente tienen un espacio de direcciones de red Clase A (10.0.0.0) para expandir el espacio de direcciones disponible para ellos, mientras que los módems de ADSL y cable comúnmente usados en viviendas y oficinas pequeñas distribuyen direcciones de IP desde redes privadas 192.168. Las conexiones con el mundo exterior se proporcionan utilizando tecnología de Traducción de Direcciones de Red (NAT), en donde un dispositivo de 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 al Internet público.

La superposición de redes privadas se convierte en un problema en relación con informática en la nube, o servicios basados en la nube. Por ejemplo, los proveedores de servicios de IaaS (Infraestructura como un Servicio) están desplegando cada vez más entornos informáticos de multi-inquilinos usados para ofrecer servicios simultáneamente a varios clientes comerciales, todos los cuales pueden usar el mismo espacio de direcciones 10.0.0.0 especialmente en el contexto de Nube Privada Virtual y/u otras tecnologías similares. En casos de uso tales como este, las redes privadas usadas por diferentes inquilinos típicamente se superponen.

En la siguiente descripción, "orquestación" se usa en su significado establecido dentro del ámbito de Arquitectura Orientada a Servicios ("SOA"), cuando se discute de flujos de trabajo automatizados entre el procesamiento de datos y sistemas de comunicación. Las empresas y proveedores de servicios usan soluciones de orquestación para alinear solicitudes comerciales con las aplicaciones, datos e infraestructura. Las dichas soluciones se usan típicamente para definir las políticas y 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 aplicación que se puede escalar hacia arriba, hacia abajo o hacia los lados con base en las necesidades de cada aplicación. La orquestación también proporciona una gestión centralizada del grupo de recursos, incluyendo facturación, medición, y contracargo por consumo.

La asignación de direcciones de IP, nombres y otros parámetros de red a los diversos servidores, comúnmente denominados como cargas de trabajo, que ejecutan aplicaciones en entornos orquestados, se ha logrado tradicionalmente configurando una dirección de IP en los dichos servidores y agregando el nombre del servidor con la dirección de IP correspondiente a un servidor de nombres de dominio (DNS) manualmente, o haciendo que tal asignación se realice dinámicamente usando Protocolo de Configuración Dinámica de Anfitrión (DHCP) y DNS dinámico. Dado que las direcciones de IP y los nombres de los servidores físicos que se ejecutan en entornos informáticos orquestados tradicionales han sido relativamente estáticos, sus procesos de gestión de flujo de trabajo automatizados basados en SOA no se han extendido para integrarse con los mecanismos de puesta en servicio de IP y nombres. A medida que las soluciones de orquestación existentes se expanden a entornos informáticos basados en la nube, los métodos tradicionales usados para gestionar direcciones de IP y nombres descritos anteriormente crearán diversos problemas. Por ejemplo, dado que el paradigma informático basado en la nube requiere que las nuevas máquinas virtuales se aprovisionen bajo demanda, el proceso manual de asignación de IP y nombre asociado con los métodos de la técnica anterior usados para asignación de 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 informático bajo demanda basado en la nube requiere que el ciclo de vida de una instancia de servidor virtual pueda estar en cualquier lugar desde minutos hasta varios años, los servidores de DHCP proporcionan un tiempo de arrendamiento predefinido y fijo para las direcciones de IP asignadas automáticamente, haciendo de esa manera imposible alinear los tiempos de arrendamiento de IP con la naturaleza dinámica del entorno informático virtual. Adicionalmente, las técnicas del arte anterior hacen imposible recuperar automáticamente una dirección de IP cuando se desmantela una máquina virtual, ya que incluso con DHCP, el desmantelamiento está unido al tiempo de arrendamiento predefinido de las direcciones de IP que se han emitido. Los métodos de la técnica anterior hacen de este modo imposible alinear el tiempo de arrendamiento de una dirección de IP con el ciclo de vida único de cada máquina virtual ejecutada dentro de la nube.

Las limitaciones de DHCP se revelan rápidamente al intentar usar en relación con la informática en la nube. Una de las razones de la pobre compatibilidad entre DHCP e informática en la nube es que DHCP nunca fue diseñado para la informática en la nube o modelos de integración basados en la web. Por ejemplo, DHCP opera en Capa 2 (L2) OSI. En la práctica, un cliente envía un mensaje de radiodifusión a una red de área local (LAN). Un servidor de DHCP en esa lAn captura el mensaje de radiodifusió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 retorna una dirección de IP con otros parámetros de red a la dirección de MAC. Después de eso el cliente configura los parámetros de red por sí mismo y puede adoptar una conexión de TCP/IP, que opera en capas OSI más altas.

En la práctica, la metodología descrita anteriormente requiere que el cliente y el servidor de DHCP deben estar interconectados mediante una conexión de L2. En la práctica, el cliente y el servidor de DHCP deben estar conectados a la misma red LAN. La LAN puede estar compuesta 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 unas de otras, lo cual habilita el tráfico de 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 LANs separadas, es que un único DHCP no puede residir lógicamente en múltiples LANs por separado. En otras palabras, en el caso de múltiples redes privadas, cada una de estas debe tener un servidor de DHCP dedicado.

El Protocolo de Internet versión 6 (IPv6) proporciona dos mecanismos para asignaciones de IP dinámicas. Estos mecanismos se denominan autoconfiguración de cortafuegos con estado y autoconfiguración de cortafuegos sin estado. Ninguno de los mecanismos de autoconfiguración resuelve los problemas identificados anteriormente debido a que, en primer lugar, la autoconfiguración de cortafuegos con estado (DHCPv6) no es realmente diferente de DHCPv4 usado en entornos de 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 arrendamiento fijo, lo cual básicamente significa que el recurso de IP permanecerá asignado durante un período predefinido de tiempo, independientemente de si el recurso de IP asignado continúa realmente siendo utilizado por la máquina virtual o no. Dentro de entornos basados en la nube, esto es indeseable, debido a que las direcciones de IP deben ponerse en servicio (emitirse) cada vez que una nueva máquina virtual se activa, y (liberarse) cada vez que esa máquina virtual se elimina desde el entorno informático virtualizado.

Por otro lado, la autoconfiguración de cortafuegos sin estado significa que un cliente obtiene de manera autónoma una dirección de IP sobre la base de anuncios de enrutador. En lo que respecta a las arquitecturas y orquestación de SOA, hay dos razones por las que este esquema puede no funcionar. Primero, en entornos donde se usa orquestación, es un requisito típico que la dirección de IP se obtenga desde una red que coincida con la Red de Área Local Virtual (VLAN) en la cual se pretende que se ejecute una máquina virtual. En otras palabras, la dirección de IP debe asignarse desde una red específica que corresponde a la VLAN en la cual va a ser desplegada la máquina virtual, en lugar de darle a la máquina virtual una dirección de IP arbitraria que pasa a estar disponible (esta última es la que conduce a la autoconfiguración de cortafuegos sin estado). La segunda razón por la que la autoconfiguración de cortafuegos sin estado puede no funcionar en este caso de uso es que los entornos son típicamente entornos de multi-inquilinos donde el administrador debe poder monitorizar activamente los niveles de asignación de cada red y determinar qué equipos y clientes están siendo ejecutados en las redes. En el caso de que las direcciones de IP sean obtenidas de manera autónoma por los clientes, no hay forma de controlar las direcciones de IP que habrá obtenido una máquina virtual dada, ni habrá ninguna transparencia en este proceso que permitiría 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 técnicas de enseñanza que permiten a múltiples orquestadores (servidores que ejecutan una solución de orquestación) obtener parámetros de red desde 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 tanto desde redes elásticas como tradicionalmente conmutadas siempre que las redes hayan sido registradas en el sistema de IPCDS.

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

En muchos casos, sin embargo, SDN no se despliega en entornos no urbanizados puros. Más bien, SDN se usa a menudo para crear redes dentro de bloques de red que también contienen redes conmutadas tradicionalmente basadas en el modelo de red de 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 microsegmentos no se superpongan con las redes tradicionales que ya han sido activadas dentro de los mismos bloques de IPv4 públicos, bloques de IPv4 privados y/o bloques de IPv6 públicos (en conjunto, "bloques de red compartidos").

Como los apilamientos en la nube y controladores de SDN típicamente permiten que los prefijos de red libres sean configurados manualmente en ellos, pueden asignar automáticamente redes a partir de los prefijos que se han configurado en ellos. Sin embargo, una fuente común de problema es que las tecnologías mencionadas anteriormente no son conscientes del estado de asignación global de los bloques de red compartidos a los cuales pertenecen los dichos prefijos de red. Esto hace problemática la automatización de servicio en casos de uso tales como Red de Área Amplia Definida por Software (SD-WAN) o Red como un Servicio (NaaS) en las cuales los prefijos de red libres van a ser usados por el controlador de SDN deben ubicarse, reservarse y/o asignarse automáticamente en el controlador de SDN como parte del flujo de trabajo de automatización de servicio.

Adicionalmente, cuando se aprovisionan parámetros de red a uno o más orquestadores responsables para desplegar servicios y cargas de trabajo (de red) virtualizados, infraestructura convergente, contenedores o similares, se requiere que los parámetros de red relacionados tanto con las redes elásticas como con las redes tradicionales estén siendo aprovisionados desde una única fuente autorizada (IPCDS), ya que los recursos mencionados anteriormente que se conectan a la red no son conscientes del método mediante el cual se ha configurado la red de TCP/IP subyacente. Esto habilita procesos orquestados que son independientes de las tecnologías que se han usado para desplegar las redes de 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 desde 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 hayan sido registradas en el sistema de IPCDS. Típicamente esto requiere despliegue manual de las redes que proporcionan los recursos de IP gestionados por IPCDS.

Por consiguiente, todavía hay margen para mejoras en la incorporación de la gestión, la asignación y la liberación de bloques de red y/o sus contenidos 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 de SDN.

Divulgación

Un objeto de la presente invención es de este modo proporcionar métodos, equipos y productos de programas de ordenador de tal manera que se alivie uno o más de los problemas identificados anteriormente. Un objeto particular es proporcionar una gestión mejorada de bloques de red y sus contenidos, incluyendo pero no limitados a bloques de red pública y privada y las redes que caen bajo estos, para habilitar la asignación y liberación automatizadas de los recursos mencionados anteriormente como parte de procesos automatizados y/o flujos de trabajo. En el presente contexto, "contenido" de bloque de red se puede entender como sigue. Partes de 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 debido a que un prefijo se puede dividir además en prefijos más pequeños. Los bloques de red privada superpuestos pueden coexistir en el mismo aparato usando técnicas divulgadas 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 usados con el propósito. La lógica que combina algunas o todas las técnicas mencionadas anteriormente se denominará como Proceso de Aprovisionamiento Dinámico de Red o "DNPP".

El objeto de la invención se logra mediante aspectos de las invenciones como se define en las reivindicaciones independientes adjuntas. Más específicamente, la presente invención proporciona métodos, equipos y productos de programas de ordenador que se pueden usar 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 de otra manera automatizados, de una forma que alivia al menos uno de los problemas descritos anteriormente. Las reivindicaciones dependientes y la siguiente descripción detallada y dibujos se relacionan con realizaciones específicas que resuelven problemas adicionales y/o proporcionan beneficios adicionales.

Una realización de la presente divulgación es un ordenador servidor que comprende un sistema de procesamiento que comprende al menos una unidad de procesamiento que almacena aplicaciones y datos. El ordenador servidor pone en servicio/desmantela redes y las aprovisiona para una o más soluciones de orquestación. La una o más soluciones de orquestación y el ordenador servidor constituyen una arquitectura cliente-servidor. El sistema de procesamiento comprende instrucciones de código de programa que instruyen al sistema de procesamiento para implementar una interfaz de usuario para la gestión del ordenador servidor, en donde la interfaz de usuario proporciona acceso a datos gestionados por el ordenador servidor; una interfaz de programación de aplicaciones basada en web que soporta arquitectura orientada a servicios ["SOA"]; y una lógica de gestión de red que asigna y libera dinámicamente redes y las aprovisiona para una o más soluciones de orquestación y la interfaz de programación de aplicaciones basada en web.

Otra realización de la presente divulgación es un ordenador servidor que comprende un sistema de procesamiento que comprende al menos una unidad de procesamiento que almacena aplicaciones y datos. El ordenador servidor pone en servicio/desmantela redes para ser activadas/desactivadas por uno o más controladores de SDN. El uno o más controladores de SDN y el ordenador servidor constituyen una arquitectura cliente-servidor. El sistema de procesamiento comprende instrucciones de código de programa que instruyen al sistema de procesamiento para implementar una interfaz de usuario para la gestión remota del controlador de SDN, en donde la interfaz de usuario proporciona acceso a datos gestionados por el controlador de SDN; un controlador de cliente basado en web que se comunica con una interfaz de programación de aplicaciones del controlador de SDN; y una lógica de gestión de red que asigna y libera dinámicamente redes para ser activadas/desactivadas por uno o más controladores de SDN.

Una realización física de la presente divulgación puede implementar cualquiera o ambas de las implementaciones basadas en SOA y basadas en SDN.

Aún realizaciones adicionales 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 instrucciones de código de programa en el ordenador servidor implementa las características de cualquier o ambos de los ordenadores servidor basados en SOA y basados en SDN.

La presente invención mejora de este modo el Proceso de Aprovisionamiento Dinámico de Red (DNPP). Antes de que se pueda usar la técnica de IPCDS descrita en la solicitud de propiedad común US20130346618, las redes que están etiquetadas y desde las cuales están siendo puestos 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 vista de que esta puesta en servicio de red debería mejorarse y automatizarse. Antes de que el IPCDS pueda funcionar, la red necesita ser activada y necesita provenir de algún lugar. El DNPP tiene como objetivo resolver este problema, 1) describiendo cómo están siendo gestionados los bloques de red.

En una implementación típica, el equipo cliente de 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, basados en un nombre de inquilino, nombre de cliente o cualquier otro identificador que haya sido 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 de uno o más bloques de red ya asignados, prefijos de red, redes, microsegmentos y similares una vez que el dicho recurso va a ser desactivado.

Otros aspectos de la invención incluyen métodos para operar el servidor de DNPP y cliente de DNPP de la invención, y productos de programas de ordenador cuya ejecución en ordenadores servidor y cliente apropiadamente equipados les proporcionan características del servidor de DNPP y del cliente de DNPP y de este modo hacen que el servidor de DNPP y cliente de DNPP lleven a cabo el método inventivo. Alternativamente, la lógica de DNPP también puede incorporarse en otro servidor y/o un cliente que también implemente la metodología de IPCDS descrita en la solicitud de patente de propiedad común US20130346618.

Debido a que los intentos anteriores para resolver los problemas descritos por esta invención han asumido solo un único apilamiento en la nube, no pueden resolver los problemas de interoperabilidad en entornos que consisten en múltiples orquestadores, controladores de SDN y/o servicios y/o infraestructura existentes. A diferencia de los intentos anteriores para gestionar, asignar y liberar bloques de red y sus contenidos en relación con flujos de trabajo orquestados o de otra manera automatizados, o directamente dentro de controladores de SDN o como parte de diversos apilamientos 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 todos los contenidos de cada bloque de red se gestionen en un sistema unificado que es autorizado para gestionar, asignar y liberar todos los bloques de red y/o sus contenidos bajo gestión independientemente de cuáles tecnologías están siendo usadas para activar, configurar o conmutar las redes de TCP/IP que caen dentro de un bloque de red dado.

De acuerdo con una característica preferida pero opcional, la lógica de DNPP también puede funcionar como una capa de integración entre los flujos de trabajo orquestados usados para desplegar servicios (de red), aplicaciones, cargas de trabajo, contenedores y similares, y los controladores de s Dn que son responsables de la activación automatizada y configuración en curso de las redes elásticas. Este método opcional se usa para asignar y/o liberar bloques de red o sus contenidos según se solicite por el cliente de DNPP, y para efectuar un cambio asociado en un controlador de SDN que ha sido integrado, ya sea directa o indirectamente, con el aparato que implementa la lógica de servidor de 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 dirección norte, responsables de la lógica comercial de diversos portales de interfaz con cliente son capaces de ofrecer prefijos de red, redes, subredes o microsegmentos disponibles a usuarios finales (clientes internos o externos), potencialmente como un servicio; y mediante el cual los dichos orquestadores en dirección norte pueden usar la lógica opcional 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 de SDN que han sido integrados en dirección sur con DNPP.

Los elementos identificados anteriormente se describirán con más detalle en lo siguiente, en donde las interfaces "en dirección sur" y "en dirección norte" se definen como sigue. Una interfaz en dirección norte de un componente conceptualiza los detalles de nivel inferior (por ejemplo, datos o funciones) usados por, o en, el componente. Se usa una interfaz en dirección norte para hacer interfaz con capas de nivel superior usando la interfaz en dirección sur de los componentes de nivel superior. Una interfaz en dirección sur descompone conceptos en los detalles técnicos, en su mayoría específicos a un único componente de la arquitectura. Las interfaces en dirección norte y en dirección sur se dibujan respectivamente en la parte superior e inferior de una visión general de arquitectura. Las interfaces en dirección norte normalmente hablan con interfaces en dirección sur de componentes de nivel superior y viceversa. La invención involucra, en primer lugar, un Proceso de Aprovisionamiento Dinámico de Red (DNPP) que se usa para gestionar y rastrear, distribución y asignación de 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 hechas de manera autónoma por controladores de SDN en la dirección sur. A diferencia de las soluciones convencionales de Gestión de Direcciones de IP que han sido diseñadas para gestionar redes, subredes y direcciones de IP manualmente por los administradores de red y otros profesionales de Tecnologías de Información, el DNPP de acuerdo con la presente invención está configurado con todos los bloques de red y sus contenidos existentes usados en el entorno, después de lo cual es capaz de asignar y/o liberar automáticamente bloques de red, prefijos de red, redes, subredes, microsegmentos y similares a los orquestadores de servicio en la dirección norte y a los controladores de SDN en la dirección sur, y opcionalmente mediar los cambios llevados a cabo ya sea en la dirección norte o en la dirección sur a los orquestadores y/o a los controladores en el lado opuesto.

El DNPP de este modo tiene orquestadores que configuran cargas de trabajo (anfitriones de red) en su lado en dirección norte, e infraestructura de red (incluyendo Controladores de SDN) en su lado en dirección sur. Técnicamente, la diferencia aquí es que en las integraciones en dirección norte, el DNPP es la tecnología que tiene una lógica empresarial de API , y los clientes están situados en los orquestadores. En las integraciones en dirección sur (similar a SDN), el DNPP tiene una lógica empresarial de cliente , y la API se proporciona por el Controlador de SDN (o SD-WAN). El esquema de pensamiento se puede visualizar como un apilamiento, 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 empresarial. El cliente siempre está en el orquestador. El DNPP incluye una API, una lógica empresarial y un cliente. La API se usa cuando el DNPP da redes (ampliamente usadas) a un orquestador, y en este caso el cliente está en el orquestador. Pero para empujar una red (ampliamente de nuevo) a un controlador de SDN o SD-WAN, en realidad se usaría un cliente que está en nuestro dispositivo, y se usaría la API que se proporciona por la SDN o SD-WAN (o apilamiento en la nube).

Una de las características de la presente invención se relaciona con situaciones en donde una red, subred o un microsegmento ejecutado en el entorno de red elástica cesa de existir o se migra a otro entorno de red elástica. Esto es posible en entornos de red de próxima generación en los cuales las redes se tratan como un recurso bajo demanda, se activan y reactivan automáticamente según sea necesario. En la técnica anterior, la falta de información precisa sobre cuáles recursos de red están siendo usados y cuáles simplemente son asignados pero no se usan hace imposible crear un flujo de trabajo de servicio automatizado en torno a la asignación y la liberación de recursos de red. En la presente invención, el cliente que se ejecuta en el sistema de orquestación puede notificar al DNPP cuando una red está a punto de ser desmantelada, o se migra a otro entorno de red elástica o controlador de SDN, según sea el caso. Alternativamente, la información sobre el recurso de red liberado puede obtenerse leyéndolo desde las configuraciones de un controlador de SDN integrado. Como resultado de esta información, el proceso de DNPP inventivo liberará automáticamente los recursos, tales como el prefijo de red, anteriormente asignado a una red que ya no existe. El DNPP de la presente invención se comunica con el sistema de orquestación y/o el controlador de SDN integrado cuando el dicho sistema está desactivando o migrando redes a otro entorno. El uso de arquitectura clienteservidor proporciona el beneficio de que el proceso de DNPP inventivo puede obtener información en tiempo real con respecto a si un recurso de red dado está siendo usado realmente o no para algo.

La invención se relaciona con entornos informáticos orquestados que utilizan arquitecturas basadas en API, y en los cuales 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 sistema de orquestación y/o el controlador de SDN.

El proceso de 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 de DNPP. La interfaz de usuario remota proporciona la capacidad de rastrear los niveles de asignación y uso de bloques de red muy cerca al tiempo real. Otras características deseables incluyen la capacidad de administradores para monitorizar de manera transparente estos niveles en tiempo real; para soportar entornos de multi-inquilinos, 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 para gestionar bloques de red etiquetando los atributos o propiedades seleccionados en ellos. La razón por la que la última parte es importante es que con el fin de asignar prefijos de red, redes, subredes, microsegmentos y similares desde el bloque de red correcto, el bloque de red debe etiquetarse con uno o más identificadores únicos presentes en las llamadas de cliente. Y para gestionar todo esto, una interfaz gráfica de usuario (GUI) es preferible para muchos usuarios administrativos.

El proceso de DNPP comprende además una Interfaz de Programación de Aplicaciones (API) que soporta la Arquitectura Orientada a Servicios (SOA) más una primera lógica capaz de asignar y liberar dinámicamente recursos de red, tales como bloques de red, prefijos de red, redes, subredes o microsegmentos basados en llamadas recibidas a través de la API.

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

Aún además, el proceso de DNPP comprende una arquitectura cliente-servidor que involucra a un cliente ejecutado en la solución de orquestación que se comunica con el proceso de DNPP a través de API basada en SOA. En una realización alternativa, el DNPP también contiene una o más implementaciones de software de cliente en donde la arquitectura cliente-servidor está comprendida entre el DNPP (cliente) y un controlador de SDN (servidor).

En cuanto al cliente, el cliente comprende una lógica de cliente que solicita un recurso de red, tal como un bloque de red, prefijo de red, red, subred o un microsegmento, desde el proceso de DNPP cuando una nueva red va a ser desplegada por la solución de orquestación. En caso de que la realización opcional se implemente en DNPP, el cliente implementado en el DNPP recoge el recurso de red asignado al orquestador, y envía el mismo recurso de red al controlador de SDN integrado para activación. Alternativamente, el cliente implementado en el DNPP también puede recoger un recurso de red desde el proceso de DNPP y enviar el recurso de red al controlador de SDN integrado para activación, sin involucrar a ningún orquestador en el dicho proceso.

La lógica de Proceso de Aprovisionamiento Dinámico de Red ("DNPP") es accesible a través de una interfaz gráfica de usuario (GUI), interfaz de línea de comandos (CLI) y/o interfaz de programación de aplicaciones (API), y también se puede usar para asignar automáticamente prefijos de red adecuados a través de llamadas hechas por sistemas de terceros tales como orquestadores de servicios a través de la API.

El DNPP puede implementarse como un aparato autónomo (servidor) cuando se usa para aprovisionar definiciones de red a orquestadores de terceros. Como se usa en este 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, subredes, máscaras de red (máscaras de red) libres o similares. Si el DNPP se implementa como un servidor, puede denominarse un Servidor de Aprovisionamiento Dinámico de Red o "Servidor de DNPP". En la mayoría de los casos, DNPP y Servidor de DNPP son intercambiables.

El DNPP busca tales definiciones de red libres con base en identificadores únicos que incluyen pero no se limitan al nombre de inquilino y/o cliente asociado con cada bloque de red gestionado. El DNPP luego reserva un recurso de red de tamaño solicitado o configurado usando las herramientas de cálculo incluidas en el sistema; y, dependiendo del caso de uso, solo ya sea retorna el recurso de red reservado al orquestador, o retorna el recurso de red reservado al orquestador y lo envía a un Controlador de SDN (SDNC) integrado o Controlador de 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 red se ha enviado en el SDNC y/o SDWANC, el DNPP inicia a sondear el SDNC integrado y/o SDWANC 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 los parámetros de red y otra información, el DNPP recupera entonces esta información y la almacena en el aparato para uso posterior. Los usos de tales datos incluyen pero no se limitan a visualizar y gestionar los datos configurados automáticamente, y el aprovisionamiento de los datos almacenados a orquestadores 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 se puede combinar con la Solicitud de Patente de los Estados Unidos no. USD20130346618 para llevar a cabo el aprovisionamiento según lo enseñado por la dicha solicitud de patente a orquestadores de terceros.

Breve descripción de los dibujos

En lo siguiente se describirá la invención con mayor detalle por medio de realizaciones específicas con referencia a los dibujos adjuntos, en los cuales:

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

La figura 2, que consiste en dibujos parciales 2A y 2B, es un diagrama de flujo que ilustra operación de un servidor de Proceso de Aprovisionamiento Dinámico de Red (DNPP) durante procesamiento de una solicitud de red desde un sistema de orquestación;

La figura 3 es un diagrama a nivel de bloques de servidor de Aprovisionamiento Dinámico de Red (DNP) y servidor de Puesta en servicio/Desmantelamiento de IP (IPCD) combinados;

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

La figura 5 es un diagrama de flujo que ilustra un ejemplo de un Proceso de Aprovisionamiento Dinámico de Red (DNPP); y

La figura 6 muestra esquemáticamente un diagrama de bloques de ejemplo para los diversos servidores y/u ordenadores 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 realización de la invención. El signo de referencia DNPS denota un servidor de aprovisionamiento dinámico de red, que implementa el proceso de aprovisionamiento dinámico de red (DNPP) descrito anteriormente. El signo de referencia UI denota una interfaz de usuario, que preferiblemente 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 datos, que el servidor de DNPS gestiona en una base de datos DB. El signo de referencia NME denota un motor de gestión de red, que implementa diversas lógicas de gestión relacionadas con las redes de puesta en servicio/desmantelamiento y, opcionalmente, recursos de 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, se relaciona con una implementación, que utiliza uno o más orquestadores (servidores que ejecutan solución de orquestación). El signo de referencia API denota una interfaz de programación de aplicaciones en el motor de gestión de red NME que soporta Arquitectura Orientada a Servicios (SOA) para un cliente (conector de cliente) en un orquestador OS. El lado derecho de la figura 1, debajo del motor de gestión de red NME, se relaciona 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 de SDN, denotada SDN-API. Una realización del motor de gestión de red NME de acuerdo con la presente divulgación puede implementar cualquiera o ambas de la implementación basada en SOA y la implementación basada en SDN.

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 con base 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 individuales y/o prefijos de red con clientes dados y, en el caso de que un bloque de red y/o prefijos de red asignados estén completos, aprovisiona automáticamente un recurso de red (por ejemplo un prefijo de red) desde 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 denota un ordenador cliente de la arquitectura cliente-servidor. El ordenador cliente CL se ejecuta en, o en conexión con, una solución de orquestación OS que se comunica con el servidor de DNPS sobre la interfaz de programación de aplicaciones API basada en SOA. La solución de orquestación OS 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 de DNPP se muestra como un servidor separado del sistema de orquestación (orquestador) OS, pero las implementaciones integradas son igualmente posibles. La implementación basada en SDN opera de manera análoga a la basada en SOA. Cualquiera o ambas tecnologías se pueden implementar 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 las etapas de procesamiento detalladas en una realización de un proceso de DNPP, durante el procesamiento de una solicitud de red desde un sistema de orquestación OS. Para los propósitos de la figura 2, el Proceso de DNP ("DNPP") y el Servidor de DNP ("DNPS") son intercambiables. "Servidor" implica un servidor dedicado, 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 sistema de orquestación OS envía una solicitud de red, que es recibida por el DNPP. En la etapa 2-4, el DNPP verifica si la solicitud de red incluye un nombre de inquilino/cliente. Si es así, el proceso procede a la etapa 2-10, en la cual el DNPP verifica si el nombre de inquilino/cliente se ha etiquetado en un bloque de red. Si es así, el proceso procede a la etapa 2-16, en la cual el DNPP verifica si la solicitud incluye una dirección de IP o máscara de bits. Si es así, el DNPP verifica, en la etapa 2-20, si la red solicitada y/o máscara de bits en un bloque de red etiquetado con el nombre de inquilino/cliente está disponible. Si el resultado de todas las verificaciones 2-4, 2-10, 2 16 y 2-20 son positivos, el DNPP procede a la etapa 2-24, en la cual reserva la red solicitada del bloque de red marcado para el inquilino/cliente y la retorna al orquestador.

Si la verificación 2-16 retorna un resultado negativo, el DNPP verifica, en la etapa 2-18, si ha sido configurada una máscara de bits predeterminada para el DNPP. Si es así, el proceso procede a la etapa 2-22 para verificar si la máscara de bits predeterminada está disponible en el bloque de red etiquetado con el nombre de inquilino/cliente. Si es así, el proceso procede a la etapa 2-24, la cual se ha descrito anteriormente.

La lógica que se describe aquí se basa en la opinión de que la red se asignaría principalmente con base en un nombre de cliente (inquilino), que se etiquetaría en el bloque de red o posiblemente en un prefijo dado debajo de este. Si no hay un nombre de inquilino o cliente, la segunda posibilidad es que el orquestador estaría ya sea a) solicitando un prefijo específico desde 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 aplican ni a) ni b), entonces las posibilidades son que una red de tamaño predeterminado provendría desde 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 dirección de IP delante de esta), entonces la asignación probablemente sería una red de tamaño adecuado desde un bloque/prefijo público. Una suposición adicional aquí es que si la solicitud incluye una dirección de IP/prefijo, podría provenir ya sea desde un bloque privado o uno público. Si es solo un prefijo (sin dirección de IP), entonces lógicamente se tomaría por defecto un bloque público.

Si ya sea la verificación 2-4 o 2-10 retorna un resultado negativo, el DNPP procede a la etapa 2-6, en la cual el DNPP verifica si la solicitud incluye una dirección de IP o máscara de bits. Si es así, el DNPP verifica, en la etapa 2-12, si la red solicitada y/o red pública del tamaño de mapa de bits solicitado está disponible. Si es así, el DNPP reserva la red solicitada y la retorna al orquestador en la etapa 2-26. Si la verificación 2-6 retorna un resultado negativo, el DNPP verifica en la etapa 2-8 si se ha configurado una máscara de bits predeterminada para el DNPP. En caso afirmativo, el proceso procede a la etapa 2-14 para verificar si una red con el tamaño de máscara de bits predeterminado está disponible en bloques públicos. Si es así, el DNPP reserva la red solicitada y la retorna al orquestador en la etapa 2 26.

Si alguna de las verificaciones 2-8, 2-12, 2-14, 2-18, 2-20 o 2-22 retorna un resultado negativo, el proceso procede a una de las etapas 2-30, 2-32, 2- 34 o 2-36, para retornar 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 detalladas de error pueden diferir.

La figura 2 ilustra de este modo la operación de una realización ambiciosa, en donde el motor de gestión de red NME puede asignar redes en múltiples formas (como se muestra, a través de procesos que llevan a través de 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 realización de la invención. El signo de referencia IPCDS denota un servidor de Puesta en servicio/Desmantelamiento de IP (servidor de IPCD). El signo de referencia UI denota una interfaz de usuario, que preferiblemente 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 de IPCDS. El signo de referencia API denota una Interfaz de Programación de Aplicaciones que soporta la Arquitectura Orientada a Servicios (SOA). El signo de referencia BL denota una lógica empresarial, que es capaz de asignar y liberar dinámicamente recursos de IP, tales como direcciones de IP, nombres, y otras configuraciones de red basadas en llamadas recibidas a través de la API. La presente realización del servidor de IPCDS comprende dos motores de gestión ME1 y ME2, que corresponden respectivamente a la primera lógica y 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 totalmente una red, el servidor de IPCDS está configurado para aprovisionar automáticamente un recurso de IP, (por ejemplo, una dirección de IP) desde una red alternativa asociada con el usuario final interno y/o externo y/o desde un grupo de reserva de recursos de IP.

El signo de referencia CL denota un ordenador cliente de la arquitectura cliente-servidor de la invención. El ordenador cliente CL se ejecuta en, o en conexión con, una solución de orquestación OS que se comunica con el servidor de IPCDS sobre la Interfaz de Programación de Aplicaciones API basada en SOA. La solución de orquestación OS 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 dibujos parciales 4A y 4B, es un diagrama de flujo que ilustra la operación de un servidor de IPCDS de acuerdo con un ejemplo. En la etapa 4-2 el sistema de orquestación envía una solicitud al servidor de IPCDS, en donde la solicitud identifica la red de área local virtual VLAN en la cual va a ser desplegado un anfitrión. En la etapa 4-4 el servidor de IPCDS examina si la VLAN está etiquetada en una red gestionada por el sistema de IPCD actual. Si no es así, el flujo procede a la etapa 4-46 (véase dibujo 2B), en donde el servidor de IPCDs retorna un mensaje de error que indica la causa del error. Si en la etapa 4-4 el resultado es positivo, el flujo procede a la etapa 4-6, en donde el servidor de IPCDs examina si la emisión de una dirección de IP fue parte de la solicitud. En caso afirmativo, el flujo procede a la etapa 4-14, en donde el servidor de IPCDs examina si una dirección de IP libre está disponible en la primera red asociada con la VLAN. En caso afirmativo, el flujo procede a la etapa 4-20, en donde el servidor de IPCDs examina si la emisión de un nombre fue parte de la solicitud. Si lo fue, el flujo procede a la etapa 4 30, en donde el servidor de IPCDs reserva una dirección de IP libre y genera un nombre único adjuntándolo a una zona predeterminada configurada a la red asociada con la VLAN. Luego el servidor de IPCDs retorna el nombre único y la dirección de IP al sistema de orquestación OS y marca la dirección de IP como usada en la red desde la cual fue asignada. Si el resultado de la etapa 4-20 fue negativo, el flujo procede a la etapa 4-32, en donde el servidor de IPCDs reserva una dirección de IP libre, la retorna al sistema de orquestación OS, y marca la dirección de IP como usada en la red desde la cual fue asignada.

Si el resultado de la etapa 4-6 fue negativo, el flujo procede a la etapa 4-8, en donde el servidor de IPCDs examina si la emisión de un nombre fue parte de la solicitud. En caso afirmativo, el flujo procede a la etapa 4-38, en donde el servidor de IPCDs retorna un nombre generado automáticamente adjuntándolo a una zona predeterminada configurada a la red asociada con la VLAN, y retorna el nombre único al sistema de orquestación OS. Si el resultado de la etapa 4-8 fue negativo, el flujo procede a la etapa 4-10, en donde el servidor de IPCDs examina si la liberación de una dirección de IPfue parte de la solicitud. En caso afirmativo, el flujo procede a la etapa 4-18, en donde el servidor de IPCDs examina si la liberación de un nombre usado fue parte de la solicitud. En caso afirmativo, el flujo procede a la etapa 4-40, en donde el servidor de IPCDs libera el nombre y dirección de IP usados desde la red que coincidía con la VLAn asociada, y retorna una confirmación al sistema de orquestación OS. Si el resultado de la etapa 4-18 fue negativo, el flujo procede a la etapa 4-42, en donde el servidor de IPCDs libera el IP usado desde la red que coincide con la VLAN asociada y retorna una confirmación al sistema de orquestación OS.

En el presente ejemplo, si el resultado de la etapa 4-10 fue negativo, el flujo procede a la etapa 4-12, en donde el servidor de IPCDs notifica que la solicitud no se relaciona con ninguna de las funciones del servidor de IPCD, y retorna un mensaje de error. En implementaciones más ambiciosas con más funciones, la rama desde la etapa 4-12 hacia la derecha puede proceder a pruebas y funciones adicionales.

Si el resultado de la etapa 4-14 fue negativo, el flujo procede a la etapa 4-16, en donde el servidor de IPCDs examina si hay otras redes etiquetadas con la misma VLAN. Si las hay, el flujo procede a la etapa 4-22, en donde el servidor de IPCD examina si hay direcciones de IP libres en las otras redes. Si las hay, el servidor de IPCDs examina en la etapa 4-24 si la emisión de un nombre fue parte de la solicitud. En caso afirmativo, el flujo procede a la etapa 4-30 descrita anteriormente. Si no es así, el flujo procede a la etapa 4-34, en donde el servidor de IPCDs retorna la dirección de IP libre al sistema de orquestación OS y la marca como usada en la red desde la cual fue asignado el IP.

Si el resultado de la etapa 4-16 o 4-22 es negativo, el flujo procede a la etapa 4-36, en donde el servidor de IPCDs retorna un nombre generado automáticamente adjuntándolo a una zona predeterminada configurada a la red asociada con la VLAN, y retorna el nombre único al sistema de orquestación OS.

La figura 5 es un diagrama de flujo que ilustra un ejemplo de un Proceso de Aprovisionamiento Dinámico de Red (DNPP). En la etapa 5-2, el servidor de DNPP crea una nueva red dentro de un bloque de red existente. En la etapa 5-10, el servidor de DNPP verifica si la adición de la nueva red fue iniciada por un orquestador. Si es así, el flujo procede a la etapa 5-20. Si no es así, el flujo procede a la etapa 5-22. En la etapa 5-20, el DNPP verifica si la llamada solicitó que la red sea agregada al Controlador de SDN o SD-WAN. Si es así, el flujo procede a la etapa 5-22, en donde el DNPP verifica si el usuario especificó manualmente un controlador de SDN/SD-WAN responsable de la red.

Si el resultado de la verificación 5-20 es negativo, el flujo procede a la etapa 5-30, en donde el DNPP verifica si la llamada especificó un Controlador de SDN o SD-WAN responsable que debería ser monitorizado para la red. Si es así, el flujo procede a la etapa 5-40, en donde el DNPP marca la red como reservada en el Dn Pp y la retorna al orquestador. También inicia a monitorizar el Controlador de SDN/SD-WAN especificado para la nueva red a través de su API, y sincroniza de vuelta las configuraciones creadas y/o hechas por el Controlador de SDN/SD-WAN a intervalos regulares con la red coincidente en DNPP.

Si el resultado de la verificación 5-30 es negativo, el flujo procede a la etapa 5-42, en donde, el DNPP marca la red como reservada en el DNPP y la retorna al orquestador, omitiendo de este modo los aspectos de monitorización y sincronización relacionados con SDN de etapa 5-40.

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

Si el resultado de verificación 5-22 es negativo, el flujo procede a la etapa 5-32, en donde, el DNPP verifica si existe un controlador de SDN predeterminado asociado con el bloque de red. Si es así, el flujo procede a la etapa 5-46, en donde el DNPP agrega la nueva red al Controlador de SDN/SD-WAN predeterminado a través de su ApI. Una vez agregado, el DNPP lee configuraciones creadas o efectuadas por el Controlador de SDN/SD-WAN a intervalos regulares y las sincroniza de vuelta con una red coincidente en el DNPP. Finalmente, si el resultado de verificación 5 32 es negativo, el flujo procede 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 de ejemplo para los diversos elementos de procesamiento de información. La arquitectura de procesamiento de datos mostrada en la figura 6, generalmente denotada 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 simple. Los dos bloques funcionales principales de la arquitectura de procesamiento de datos son un sistema 6-100 de procesamiento y un sistema 6-190 de almacenamiento. El sistema 6-100 de procesamiento comprende una o más unidades centrales de procesamiento CP1 ... CPn, generalmente denotadas por el número de referencia 6-110. Las unidades de procesamiento pueden ser unidades de procesamiento nativas o virtuales. Realizaciones que comprenden múltiples unidades 6-110 de procesamiento se proporcionan preferiblemente con una unidad 6-115 de equilibrio de carga que equilibra la carga de procesamiento entre las múltiples unidades 6-110 de procesamiento. Las múltiples unidades 6-110 de procesamiento pueden implementarse como componentes de procesador separados o como núcleos de procesador físicos o procesadores virtuales dentro de una caja de un único componente. El sistema 6-100 de procesamiento comprende además una interfaz 6-120 de red para comunicarse con diversas redes de datos, que generalmente se denotan por el signo de referencia DN. Las redes de datos DN puede incluir redes de área local, tales como una red Ethernet, y/o redes de área amplia, tales como el Internet. El número de referencia 6-125 denota una interfaz de red móvil, a través de la cual el sistema 6-100 de procesamiento puede comunicarse con diversas redes de acceso AN, que sirven a nodos de red inalámbrica. Una configuración que soporta múltiples redes diferentes habilita que el sistema 6-100 de procesamiento soporte múltiples tipos de clientes, tales como terminales 6-200 terrestres y terminales 6-210 móviles.

El sistema 6-100 de procesamiento de la presente realización también puede comprender una interfaz 6-140 de usuario local. Dependiendo de la implementación, la interfaz 6-140 de usuario puede comprender circuitería de entrada-salida local para una interfaz de usuario local, tal como un teclado, ratón y pantalla (no se muestran). Alternativa o adicionalmente, la gestión del sistema 6-100 de procesamiento puede implementarse de manera remota, utilizando la interfaz 6-120 de red 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 6-100 de procesamiento. Si el sistema 6-100 de procesamiento es un ordenador dedicado, puede no ser necesaria una interfaz de usuario local, y el sistema 6-100 de procesamiento se puede gestionar de manera remota, tal como desde un navegador web sobre el Internet, por ejemplo. Tal gestión remota se puede lograr a través de la misma interfaz 6 120 de red que utiliza el ordenador para tráfico entre él mismo y los terminales cliente.

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

El sistema 6-100 de procesamiento también comprende circuitería para diversos relojes, interrupciones y similares, y estos se representan generalmente mediante el número de referencia 6-130. El sistema 6-100 de procesamiento comprende además una interfaz 6-145 de almacenamiento para el sistema 6-190 de almacenamiento. Cuando el sistema 6-100 de procesamiento está apagado, el sistema 6-190 de almacenamiento puede almacenar el software que implementa las funciones de procesamiento, y al encenderlo, el software se lee en la memoria 6-150 de semiconductores. El sistema 6-190 de almacenamiento también conserva operativos y variables sobre períodos de apagado. En implementaciones de gran volumen, es decir, implementaciones en donde un único sistema 6-100 de procesamiento sirve a un gran número de clientes a través de los respectivos terminales móviles MT, el sistema 6-190 de almacenamiento 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 hasta 6-150 se intercomunican a través de un bus 6-105, que transporta señales de dirección, señales de datos y señales de control, como es bien conocido por los expertos en la técnica.

Será evidente para una persona experta en la técnica que, a medida que avanza la tecnología, el concepto inventivo se puede implementar de diversas formas. La invención y sus realizaciones no están limitadas a los ejemplos descritos anteriormente sino al alcance de las reivindicaciones.

Claims

REIVINDICACIONES

1. Un ordenador servidor (DNPS) para redes de puesta en servicio/desmantelamiento y aprovisionamiento de dichas redes a un sistema de orquestación (OS) que constituye una arquitectura cliente-servidor con el ordenador servidor (DNPS), comprendiendo el ordenador servidor (DNPS):

- una base de datos (DB) que comprende datos;

- una interfaz de usuario (UI) remota para gestión remota del ordenador servidor (DNPS), en donde la interfaz de usuario (UI) remota proporciona acceso a los datos en la base de datos (DB);

- una interfaz de programación de aplicaciones (API) basada en red que soporta arquitectura orientada a servicios ["SOA"] para un cliente (CL) del sistema de orquestación (OS); y

- un motor de gestión de red (NME) para asignar y liberar redes dinámicamente y aprovisionar dichas redes al cliente (CL) del sistema de orquestación (OS), en donde el motor de gestión de red (NME) está conectado a la base de datos (DB), la interfaz de usuario (UI) remota y la interfaz de programación de aplicaciones (API) basada en red,

estando el motor de gestión de red (NME) Z configurado para recibir, desde el sistema de orquestación (OS), una solicitud en la cual se solicita una red caracterizado porque el motor de gestión de red está configurado para realizar:

verificar (2-4, 2-10) si la solicitud incluye un nombre de cliente o inquilino 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 la solicitud que incluye dicho nombre de cliente o inquilino etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente:

en respuesta a la solicitud que incluye una dirección de IP o una máscara de red (2-16), verificar si la red solicitada y/o máscara de red está disponible en el bloque de red etiquetado con dicho nombre de cliente o inquilino (2-20), y, si dicha red solicitada y/o máscara de red está disponible, reservar la red solicitada desde el bloque de red etiquetado con dicho nombre de cliente o inquilino y retornarla al sistema de orquestación (OS) (2-24),

en respuesta a la solicitud que falla en incluir ya sea una dirección de IP o una máscara de red (2-16), verificar si una máscara de red predeterminada está configurada para el ordenador servidor (DNPS) (2-18) y, si una máscara de red predeterminada está configurada en el ordenador servidor (DNPS), si dicha máscara de red predeterminada está disponible en el bloque de red etiquetado con dicho nombre de cliente o inquilino (2-22), y, si dicha máscara de red predeterminada está disponible, reservar la red solicitada desde el bloque de red etiquetado con dicho nombre de cliente o inquilino y retornarla al sistema de orquestación (OS) (2-24); y

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

en respuesta a la solicitud que incluye una dirección de IP o una máscara de red (2-6), verificar si la red solicitada y/o una red pública de un tamaño de la máscara de red está disponible (2-12) en un bloque de red pública o privada gestionado por el ordenador servidor (DNPS), y, si la red solicitada y/o dicha red pública está disponible, reservar una red considerada que va a estar disponible y retornarla al sistema de orquestación (OS) (2-26), y

en respuesta a la solicitud que falla en incluir una dirección de IP o una máscara de red (2-6), verificar si una máscara de red predeterminada está configurada para el ordenador servidor (DNPS) (2-8) y, si la máscara de red predeterminada está configurada, si una red con un tamaño de la máscara de red predeterminada está disponible en al menos un bloque de red pública gestionado por el ordenador servidor (DNPS) (2-14), y, si la red con el tamaño de la máscara de red predeterminada está disponible, reservar la red con el tamaño de la máscara de red predeterminada y retornarla al sistema de orquestación (OS) (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 cualquiera de una pluralidad de verificaciones (2-8, 2-12, 2-14, 2-18, 2-20, 2-22) que retornan un resultado negativo, retornar una condición de error, en donde la pluralidad de verificaciones consiste en:

la verificación de si la máscara de red predeterminada está configurada para el ordenador servidor (DNPS) (2-8),

la verificación de si la red solicitada y/o la red pública del tamaño de la máscara de red está disponible (2-12),

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

la verificación de si la máscara de red predeterminada está configurada para el ordenador servidor (DNPS) (2-18), la verificación de si la red solicitada y/o máscara de red está disponible en el bloque de red etiquetado con dicho nombre de cliente o inquilino (2-20) y

la verificación de si dicha máscara de red predeterminada está disponible en el bloque de red etiquetado con dicho nombre de cliente o inquilino (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 para, en respuesta a detectar que una red previamente asignada ya no está siendo usada, liberar la red previamente asignada.

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

6. El ordenador servidor (DNPS) de la reivindicación 1, en donde el ordenador servidor (DNPS) está configurada para implementar las siguientes características:

- asignar y liberar dinámicamente recursos de Protocolo de Internet ["IP"] a una pluralidad de anfitriones (SI) a través del sistema de orquestación (OS) y la interfaz de programación de aplicaciones (API) basada en red;

- crear al menos un recurso de IP único para cada uno de dos o más anfitriones (SI), en donde los dos o más anfitriones (SI) son nodos de redes con espacios de direcciones superpuestos, y

- en donde el al menos un recurso de IP único se basa en una combinación de un nombre de una red privada de uno respectivo de los dos o más anfitriones, y una dirección de IP dentro de esa red privada.

7. Un método de redes de puesta en servicio/desmantelamiento y aprovisionamiento de dichas redes a un sistema de orquestación (OS), comprendiendo el método:

- usar un ordenador servidor (DNPS) que comprende una base de datos (DB), una interfaz de programación de aplicaciones (API) basada en red que soporta arquitectura orientada a servicios ["SOA"], una interfaz de usuario (Ul) remota y un motor de gestión de red (NME) conectado a la base de datos (DB), la interfaz de programación de aplicaciones (API) basada en red y la interfaz de usuario (Ul) remota, en donde el sistema de orquestación (OS) y el ordenador servidor (DNPS) constituyen una arquitectura cliente-servidor;

- gestionar el ordenador servidor (DNPS) de manera remota usando la interfaz de usuario (Ul) remota, en donde la interfaz de usuario (Ul) remota proporciona acceso a datos gestionados por el ordenador servidor (DNPS) en la base de datos (DB);

- asignar y liberar dinámicamente redes y aprovisionar dichas redes usando el motor de gestión de red (NME) a un cliente (CL) del sistema de orquestación (OS), la asignación comprende

- recibir, desde el sistema de orquestación (OS), una solicitud en la cual se solicita una red caracterizado porque la asignación comprende además

-verificar (2-4, 2-10) si la solicitud incluye un nombre de cliente o inquilino 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 la solicitud que incluye dicho nombre de cliente o inquilino etiquetado en el bloque de red (2-4, 2-10), realizar lo siguiente:

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

en respuesta a la solicitud que incluye una dirección de IP o una máscara de red (2-6), verificar si la red solicitada y/o una red pública de un tamaño de la máscara de red está disponible en un bloque de red pública o privada gestionado por el ordenador servidor (DNPS) (2-12), y, si la red solicitada y/o dicha red pública está disponible, reservar una red considerada que va a estar disponible y retornarla al sistema de orquestación (OS) (2-26), y

8. Una memoria legible por ordenador que almacena instrucciones de código de programa para que un ordenador servidor (DNPS) ponga en servicio/desmantele redes y aprovisione dichas redes a un sistema de orquestación (OS), en donde el ordenador servidor (DNPS) comprende una base de datos (DB), una interfaz de programación de aplicaciones (API) basada en red que soporta arquitectura orientada a servicios ["SOA"], una interfaz de usuario (Ul) remota y un motor de gestión de red (NME) conectado a la base de datos (DB), la interfaz de programación de aplicaciones (API) basada en red y la interfaz de usuario (Ul) remota y el sistema de orquestación (OS) 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 la memoria legible por ordenador instruye al ordenador servidor (DNPS) a:

- habilitar gestión del ordenador servidor (DNPS) de manera remota usando la interfaz de usuario (UI) remota, en donde la interfaz de usuario (UI) remota proporciona acceso a datos gestionados por el ordenador servidor (DNPS) en la base de datos (DB);

- asignar y liberar dinámicamente redes y aprovisionar dichas redes usando el motor de gestión de red (NME) a un cliente (CL) del sistema de orquestación (OS), la asignación comprende: