ES2881188T3 - Un clúster de bordes de proveedores virtuales para su utilización en una arquitectura de SDN - Google Patents

Abstract

Un subsistema operativo para su utilización como un clúster de bordes de proveedores virtuales (vPE: virtual Provider Edge) de un sistema de comunicación de SDN, y caracterizado por el hecho de que dicho clúster de bordes de proveedores virtuales (vPE) comprende una pluralidad de elementos de red y una entidad de gestión, en el que dicho clúster de vPE comprende además uno o más motores de enrutamiento virtuales para enrutar el tráfico hacia/desde dicha pluralidad de elementos de red, dichos uno o más motores de enrutamiento virtuales están configurados para comunicarse con dicha entidad de gestión y con una pluralidad de motores de transmisión virtuales, y en el que dicha entidad de gestión está configurada para gestionar la operación del uno o más motores de enrutamiento virtuales y la pluralidad de motores de transmisión virtuales.

Description

DESCRIPCIÓN

Un clúster de bordes de proveedores virtuales para su utilización en una arquitectura de SDN

CAMPO TÉCNICO

La presente divulgación se refiere en general al campo de sistemas de comunicación. Más en particular, la presente divulgación se refiere a sistemas que implementan redes definidas por software.

GLOSARIO AAA -Autenticación, Autorización y Contabilización (Authentication, Authorization and Accounting)

ARP - Protocolo de resolución de direcciones (Address Resolution Protocol)

BGP - Protocolo de Puerta de enlace de Frontera (Border Gateway Protocol)

CBB - Red Central (Core Backbone)

CC - Controlador centralizado (Centralized Controller)

CE - Equipo cliente (Customer Equipment)

CLI - Interfaz de línea de comandos (Command Line Interface)

CRS - Sistema de enrutamiento de operador (Carrier Routing System)

eBGP - BGP exterior

FE - Motor de transmisión (Forwarding Engine)

FIB - Base de Información de transmisión (Forwarding Information Base)

FPM - Gestor de rutas de transmisión (Forwarding Path Manager)

GRE - Encapsulamiento de enrutamiento genérico (Generic Routing Encapsulation)

iBGP - BGP interior

LACP - Protocolo de control de agregación de enlaces (Link Aggregation Control Protocol)

LAN - Red de área local

lo - Bucle de retorno (Loopback)

MC-LAG - Grupo de agregación de enlaces de múltiples chasis (Multi Chassis Link Aggregation Group)

NB - Dirección Norte (Northbound)

OSPF - Abrir el camino más corto primero (Open Shortest Path First)

PE - Borde de proveedor (Provider Edge)

RE - Motor de enrutamiento (Routing Engine)

RIB - Base de información de enrutamiento (Routing Information Base)

SNMP - Protocolo simple de gestión de red (Simple Network Management Protocol)

|jBFD - Detección de transmisión micro bidireccional (Micro Bidirectional Forwarding Detection)

UI - Interfaz de usuario (User Interface)

VLAN - LAN virtual

VM - Máquina virtual (Virtual Machine)

vPE - Borde de proveedor virtual (Virtual Provider Edge)

VPN - Red privada virtual (Virtual Prívate Network)

VTEP - Punto final de túnel VXLAN (VXLAN Tunnel Endpoint)

VXLAN - LAN virtual extensible (Virtual Extensible LAN)

Servicio de Ruta de Datos (Data Path Service) - un servicio proporcionado por todos los Motores de transmisión que son responsables de transmitir todos los paquetes que llegan al plano de ruta de datos hacia los equipos cliente, bordes de proveedor y enrutadores centrales, e implementar las características de ruta de datos, por ejemplo, QoS, ACL, clasificación de paquetes, y similares.

Contenedor de Docker (Docker Container): un contenedor de Docker proporciona un sistema de archivos completo que contiene todo lo que el software incluido en ese contenedor de Docker necesita para ejecutarse: código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema, de hecho todo lo que se puede instalar en un servidor. Esto garantiza que el software incluido en el contenedor de Docker siempre se ejecutará igual, con independencia del entorno en el que se ejecute.

Servicio de gestión (Management Service) - un servicio proporcionado por una entidad de gestión (Manager) que es responsable de la configuración del sistema y de la monitorización de su rendimiento, en el que sus elementos dirección norte (NB: Northbound) se utilizan para proporcionar una funcionalidad de control y administración.

Servicio de Enrutamiento (Routing Service) - un servicio proporcionado por un Motor de Enrutamiento (RE) que es responsable de utilizar el protocolo de enrutamiento apropiado de entre todos los protocolos de enrutamiento soportados por el sistema, cuando se comunica con equipos clientes, bordes de proveedor y enrutadores centrales específicos, y opcionalmente controlar y sincronizar ciertas características relacionadas con la ruta de datos tal como QoS distribuida.

Caja blanca (White Box): un producto, que es un hardware abierto o que cumple con los estándares de la industria para conmutadores y/o enrutadores dentro del plano de transmisión. Las cajas blancas proporcionan a los usuarios los elementos de hardware fundamentales de una red.

ANTECEDENTES

Una red definida por software (en adelante "SDN" - Software-defined networking) es un concepto con el que se puede inicializar, controlar, cambiar y gestionar dinámicamente el comportamiento de una red mediante programación de interfaces abiertas y abstracción de funcionalidad de nivel inferior. Una SDN pretende resolver el hecho de que la arquitectura estática de redes tradicionales no soporta unas necesidades dinámicas y escalables de procesamiento y almacenamiento de entornos informáticos modernos, tales como centros de datos. Para ello, se desacopla o disocia el sistema que toma decisiones sobre dónde se envía el tráfico (el controlador de SDN, o el plano de control) con respecto de los sistemas subyacentes que transmiten el tráfico al destino seleccionado (el plano de datos).

La arquitectura de SDN es una arquitectura dinámica, gestionable, rentable y adaptable, que pretende adaptarse a la naturaleza dinámica y de gran ancho de banda de las aplicaciones actuales. Las arquitecturas SDN típicas desacoplan las funciones de control y transmisión de la red, lo que permite que el control de la red sea directamente programable y la abstracción de la infraestructura subyacente con respecto de las aplicaciones y los servicios de red.

El gran y creciente número de dispositivos y contenidos móviles, la virtualización de servidores y la llegada de los servicios en la nube son algunas de las tendencias que hacen que el sector de las redes reexamine las arquitecturas de red tradicionales. Muchas redes convencionales son jerárquicas, construidas con niveles de conmutadores Ethernet dispuestos en una estructura de árbol. Este diseño tenía sentido cuando dominaba la informática cliente-servidor, pero esta arquitectura estática no se ajusta a las necesidades dinámicas de procesamiento y almacenamiento de los centros de datos de empresa y entornos de operadores de hoy en día. Entre las tendencias informáticas clave que impulsan la necesidad de un nuevo concepto de red, se encuentran:

a) Cambios en los patrones de tráfico

Dentro del centro de datos de una empresa, los patrones de tráfico han cambiado significativamente. A diferencia de las aplicaciones cliente-servidor, en las que la mayor parte de la comunicación se produce entre un cliente y un servidor, las aplicaciones actuales acceden a diferentes bases de datos y servidores. Al mismo tiempo, los usuarios están cambiando los patrones de tráfico de la red, ya que solicitan acceso a los contenidos y aplicaciones corporativas desde cualquier tipo de dispositivo (incluido el suyo propio), conectándose desde cualquier lugar y en cualquier momento. Además, muchos gestores de centros de datos de empresa están contemplando un modelo de procesamiento de servicios, que podría incluir una nube privada, una nube pública o alguna combinación de las mismas, lo que da lugar a un tráfico adicional que se transmite a través de la red de área amplia.

b) Aumento de la carga de las tecnologías de información

Los usuarios emplean cada vez más dispositivos personales móviles, tales como teléfonos inteligentes, tabletas y ordenadores portátiles, para acceder a redes corporativas. Como resultado, las tecnologías de información se ven sometidas a una presión para dar cabida a estos dispositivos personales con una granularidad fina y al mismo tiempo proporcionar una protección adecuada a los datos corporativos.

c) Crecimiento de servicios en la nube

Las empresas han adoptado servicios en la nube, tanto públicos como privados, lo que ha provocado un crecimiento sin precedentes de estos servicios. Las unidades de negocio de las empresas necesitan ahora tener agilidad para acceder a las aplicaciones, la infraestructura y otros recursos de tecnologías de la información TI bajo demanda. Como complejidad añadida, la planificación de los servicios en la nube se debe realizar en un entorno de mayor seguridad junto con reorganizaciones, consolidaciones y fusiones de negocio que pueden cambiar los supuestos de la noche a la mañana. Proporcionar un aprovisionamiento de autoservicio, ya sea en una nube privada o pública, requiere un escalado elástico de los recursos informáticos, de almacenamiento y de red, idealmente desde un punto de vista común y con un conjunto común de herramientas.

d) Mayores requisitos de ancho de banda

El manejo de los actuales "Big Data" o mega conjuntos de datos requiere un procesamiento paralelo masivo en miles de servidores, todos los cuales necesitan unas conexiones directas entre sí. El aumento de los mega conjuntos de datos es una fuente de demanda constante de capacidad de red adicional en el centro de datos. Los operadores de redes de centros de datos a hiper escala se enfrentan a la tarea de escalar la red a un tamaño antes inimaginable, manteniendo al mismo tiempo una conectividad de cualquiera con cualquiera, todo ello con un gasto de capital (Capex) asequible.

La siguiente lista se refiere a diversos elementos que componen dicha arquitectura de red:

Aplicación de SDN

Las aplicaciones de SDN son programas que comunican sus requisitos de red y el comportamiento de red deseado directamente al controlador de SDN a través de una interfaz dirección norte ("NBI": northbound interface). Además, pueden consumir una vista abstracta de la red para su toma de decisiones interna. Una aplicación de SDN suele estar formada por una lógica de aplicación de SDN y uno o diversos controladores de interfaz NBI. Las Aplicaciones de SDN pueden exponer por sí mismas otra capa de control de red abstraído, ofreciendo de este modo una o más interfaces NBI de nivel superior a través de respectivos agentes de interfaz NBI.

Controlador de SDN

El Controlador de SDN es una entidad lógicamente centralizada encargada de (i) traducir los requisitos procedentes de la capa de Aplicación de SDN de bajada hacia las Rutas de datos de SDN y (ii) proporcionar a las Aplicaciones de SDN una vista abstracta de la red (por ejemplo, estadísticas y eventos). Un controlador de SDN está formado por uno o más agentes de interfaz NBI, la lógica de control de SDN y el controlador de Interfaz de Plano Datos-Controlador ("CDPI": Control to Data-Plane Interface).

Ruta de datos de SDN

La Ruta de datos de SDN es un dispositivo de red lógico que expone la visibilidad y el control sobre sus capacidades de transmisión y procesamiento de datos anunciadas. La representación lógica puede abarcar todos los recursos de sustrato físico o un subconjunto de los mismos. Una Ruta de datos de SDN comprende un agente de interfaz CDPI y un conjunto de uno o más motores de transmisión de tráfico y, opcionalmente, una o más funciones de procesamiento de tráfico. Estos motores y funciones pueden incluir una simple transmisión entre las interfaces externas de las rutas de datos o funciones internas de procesamiento o terminación del tráfico. Una o más rutas de datos de SDN pueden estar contenidas en un único elemento de red (físico) - una combinación física integrada de recursos de comunicaciones, gestionada como una sola unidad. Una Ruta de datos de SDN también se puede definir a través de múltiples elementos físicos de red.

Interfaz de Plano Datos-Controlador (CDPI) de SDN

La interfaz CDPI de SDN es la interfaz definida entre un controlador de SDN y una Ruta de datos de SDN, que proporciona (i) un control programático de todas las operaciones de transmisión, (ii) un anuncio de capacidades, (iii) un informe de estadísticas, y (iv) una notificación de eventos.

Interfaces dirección norte (NBI: Northbound interface) de SDN

Las interfaces NBI de SDN son interfaces situadas entre aplicaciones de SDN y controladores de SDN. Suelen proporcionar unas vistas abstractas de la red y permiten una expresión directa del comportamiento y requisitos de la red.

Plano de control de SDN

Las primeras propuestas de plano de control de SDN se centraban en una solución centralizada, en las que una única entidad de control tiene una visión global de la red. Aunque esto simplifica la implementación de la lógica de control, tiene limitaciones de escalabilidad a medida que aumentan el tamaño y la dinámica de la red. Para superar estas limitaciones, se han propuesto diversos enfoques en la técnica que se dividen en dos categorías, enfoques jerárquicos y totalmente distribuidos. En las soluciones jerárquicas, los controladores distribuidos operan en una vista de la red particionada, si bien las decisiones que requieren un conocimiento de toda la red son tomadas por un controlador raíz centralizado lógicamente. En los enfoques distribuidos, los controladores operan en su vista local o pueden intercambiar mensajes de sincronización que les permiten mejorar sus conocimientos. Las soluciones distribuidas son más adecuadas para soportar aplicaciones de SDN adaptativas. Una cuestión clave a la hora de diseñar un plano de control de SDN distribuido es decidir el número y la ubicación de las entidades de control. Un factor importante que se debe tener en cuenta a la hora de tomar estas decisiones es el retardo asociado con la propagación de la comunicación entre los controladores y los dispositivos de red, especialmente en redes grandes. Otros factores son la fiabilidad de la ruta de control, la tolerancia a fallos y los requisitos de las aplicaciones.

OpenFlow es un protocolo que se utiliza para transmitir flujos en una red que implementa una arquitectura de SDN. Este protocolo proporciona acceso al plano de transmisión de un conmutador (o un enrutador) de red a través de la red. El protocolo OpenFlow utiliza unas tablas de memoria direccionable de contenido ternario ("TCAM": Ternary Content Addressable Memory) para enrutar flujos de tráfico (secuencias de paquetes). Cuando los flujos llegan a un conmutador, se realiza una búsqueda en una tabla de flujos. En función de la implementación de la tabla de flujos, esto se hace en una tabla de flujos de software. En caso de que no se encuentre ningún flujo que se corresponda, se transmitirá una solicitud al controlador a la espera de nuevas instrucciones. Esto puede ser gestionado de uno de entre tres modos diferentes. En un modo reactivo, el controlador responde a estas solicitudes generando e instalando una regla en la tabla de flujos para el paquete correspondiente si es necesario. En un modo proactivo, el controlador rellena de forma anticipada las entradas en la tabla de flujos para todas las correspondencias de tráfico posibles para este conmutador. Este modo se puede comparar con las típicas entradas de la tabla de enrutamiento de hoy en día, en el que todas las entradas estáticas se instalan de forma anticipada. Siguiendo este modo, no se enviaría ninguna solicitud al controlador, ya que todos los flujos entrantes encontrarán una entrada correspondiente. Una de las principales ventajas del modo proactivo es que todos los paquetes se transmiten a la velocidad de la línea (teniendo en cuenta todas las entradas de la tabla de flujos en la memoria TCAM) y no se añade ningún retraso. El tercer modo, el modo híbrido, sigue la flexibilidad de un modo reactivo para un conjunto de tráfico y la transmisión de baja latencia (modo proactivo) para el resto del tráfico.

La solicitud con número de publicación US2014/365634 describe un procedimiento y un aparato para procesar un análisis de red programable a través de una acción de inspección/aplicación-de-acción aplicada a entidades físicas y virtuales implementadas en un sistema de comunicación de SDN con máquinas virtuales que incluyen enrutadores de borde de proveedor virtual (vPE: virtual Provider Edge) que sirven como dispositivos de borde del cliente virtual.

RESUMEN

La invención se define en un primer aspecto en la reivindicación 1.

De acuerdo con una forma de realización, el clúster de vPE está conectado con una red central a través de una configuración de nodos hoja y nodos de columna vertebral (leaf-spine configuration), o cualquier otra configuración aplicable en la que se utiliza una estructura para conectar los servidores de clúster de vPE con una respectiva red central.

De acuerdo con otra forma de realización, la configuración de nodos hoja y nodos de columna vertebral es una disposición que comprende una pluralidad de cajas blancas. Opcionalmente, la pluralidad de cajas blancas comprende una pluralidad de hardware básico (por ejemplo, conmutadores L2, estructura L1, o cualquier otro dispositivo básico de red basado en silicio) que opera bajo control de la entidad de gestión que actúa como un controlador centralizado.

Según otra forma de realización más, teniendo los elementos de red uno o más puertos cada uno para permitir la transmisión de tráfico a través de los mismos, y donde al menos uno de los puertos asociados con dicho subsistema está configurado para dar servicio a una pluralidad de clientes.

Según todavía otra forma de realización, el clúster de vPE comprende uno o más motores de enrutamiento (RE: routing engine), cada uno de los cuales tiene una funcionalidad de distribución de gestor de rutas de transmisión (FPM: forwarding path manager) y es operativo para proporcionar a los motores de transmisión (FE: forwarding engine) asociados con el clúster de vPE, toda la información de enrutamiento necesaria para que manejen todo el tráfico que necesita ser transmitido desde el mismo.

De acuerdo con otra forma de realización, se proporciona la información de enrutamiento a los motores de transmisión asociados con el clúster de vPE utilizando unos túneles de encapsulamiento de enrutamiento genérico (GRE: generic routing encapsulation) predefinidos (o cualesquiera otros túneles aplicables) que se extienden entre el motor de enrutamiento y un respectivo motor de transmisión.

De acuerdo con otra forma de realización, los túneles de GRE están adaptados para permitir portar el tráfico hasta el motor de enrutamiento y el tráfico de gestión hasta la entidad de gestión.

De acuerdo con otra forma de realización, el clúster de vPE está provisto de su propia gestión unificada, y la gestión se lleva a cabo utilizando una pluralidad de interfaces dirección norte (NB: northbound) para gestionar todas las máquinas virtuales asociadas con ese clúster de vPE, y preferiblemente también todos los contenedores de tráfico (tales como los contenedores de Docker).

Según otra forma de realización, el motor de enrutamiento único reside en una sola máquina virtual junto con un motor de transmisión.

Según todavía otra forma de realización, el motor de enrutamiento único reside en una pluralidad de máquinas virtuales, junto con un motor de transmisión.

En otra forma de realización, una pluralidad de motores de enrutamiento reside en una sola máquina virtual junto con un motor de transmisión.

Otra ventaja que se puede derivar a partir del uso de las formas de realización que se han descrito anteriormente, es que una pluralidad de las mismas direcciones IP pueden ser utilizadas por diferentes combinaciones de motores de enrutamiento y motores de transmisión, si bien la entidad de gestión del clúster de vPE está configurada para garantizar que estas direcciones no se utilicen de una manera que crearía colisiones entre las mismas. En consecuencia, se puede garantizar a diferentes clientes asociados con el clúster de vPE que su tráfico es transmitido por separado con respecto de otros clientes a los que también da servicio el mismo clúster de vPE.

De acuerdo con otra forma de realización, el subsistema proporcionado comprende además un procesador configurado para generar contenedores de tipo docker y/o una máquina virtual que permite al clúster de vPE establecer una pluralidad de micro servicios. Opcionalmente, se proporciona una identificación de punto final de túnel de red de área local extensible virtual (VTEP: Virtual Extensible LAN Tunnel Endpoint) con los contenedores de tipo docker, y/o utilizando máquinas virtuales o cualquier otra tecnología de virtualización aplicable.

En otro aspecto, la invención define un sistema de comunicación de SDN según la reivindicación 13.

De acuerdo con una forma de realización de este aspecto, el sistema de comunicación de SDN comprende además un procesador (o cualquier otro dispositivo de toma de decisiones aplicable) configurado para añadir una o más indicaciones a paquetes de comunicación incluidos en flujos de tráfico que son enrutados en el sistema de comunicación de SDN.

Según otra forma de realización más, la una o más indicaciones están asociadas con al menos una respectiva característica de los paquetes de comunicación.

Según todavía otra forma de realización, la al menos una respectiva característica de los paquetes de comunicación es un miembro de un grupo que consiste en: un nivel de seguridad asociado con un tráfico al que pertenecen los paquetes de comunicación; un acuerdo de nivel de servicio al cliente asociado con el tráfico al que pertenecen los paquetes de comunicación; un tipo de servicio (vídeo, IOT, 5G, voz, etc.) del tráfico al que pertenecen los paquetes de comunicación; y un tipo de protocolo asociado con el tráfico al que pertenecen los paquetes de comunicación.

De acuerdo con otra forma de realización, el sistema de comunicación de SDN comprende además un procesador (o cualquier otro dispositivo de toma de decisiones aplicable) configurado para reorganizar el tráfico recibido, de modo que al menos uno de los flujos de tráfico comprende solo paquetes de comunicación que cumplen uno o más criterios predefinidos.

BREVE DESCRIPCION DE LOS DIBUJOS

Los dibujos adjuntos, que se incorporan al presente documento y constituyen una parte de esta especificación, ilustran diversas formas de realización de la divulgación y, junto con la descripción, sirven para explicar los principios de las formas de realización que se divulgan en el presente documento.

La Figura 1 ilustra una vista esquemática de un clúster de vPE interpretado de acuerdo con una forma de realización de la presente divulgación;

La Figura 2 muestra una conectividad de rack opcional;

La Figura 3 muestra un ejemplo de una conectividad de red interpretada de acuerdo con una forma de realización de la presente divulgación;

La Figura 4 muestra una configuración de servicio de enrutamiento centralizado, en la que un clúster de vPE comprende un solo motor de enrutamiento (RE).

La Figura 5 ilustra una forma de realización de una configuración de servicio de enrutamiento centralizado en la que el motor de enrutamiento reside con un motor de transmisión maestro en una sola máquina virtual;

La Figura 6 ilustra otra forma de realización de una configuración de servicio de enrutamiento centralizado en la que el motor de enrutamiento único reside en una sola máquina virtual;

La Figura 7 presenta un sistema de vPE centralizado interpretado de acuerdo con una forma de realización de la presente divulgación;

La Figura 8 presenta un sistema de vPE centralizado interpretado de acuerdo con otra forma de realización de la presente divulgación; y

La Figura 9 ilustra un ejemplo de un clúster de vPE y diferentes funcionalidades asociadas con el mismo.

DESCRIPCIÓN DE FORMAS DE REALIZACIÓN DE EJEMPLO

Algunos de los detalles y valores específicos en la siguiente descripción detallada se refieren a ciertos ejemplos de la divulgación. Sin embargo, esta descripción se proporciona sólo a modo de ejemplo y no pretende limitar el alcance de la invención de ninguna manera. Como apreciarán los expertos en la materia, el procedimiento y el dispositivo reivindicados se pueden implementar utilizando otros procedimientos conocidos en la técnica per se. Además, las formas de realización que se describen comprenden diferentes etapas, no todas las cuales son necesarias en todas las formas de realización de la invención. El alcance de la invención se puede resumir en referencia a las reivindicaciones adjuntas.

La Figura 1 ilustra una vista esquemática de un clúster de vPE 100 que comprende uno o más motores de enrutamiento virtuales 110 que es operativo para comunicarse con una entidad de gestión 120 por un lado y con una pluralidad de N motores de transmisión virtuales 130 por otro lado. La entidad de gestión 120 es operativa para gestionar la operación tanto de los motores de enrutamiento virtuales como de los motores de transmisión virtuales, en el que estos últimos pueden ser gestionados directamente por la entidad de gestión 120 o indirectamente, a través de sus respectivos motores de enrutamiento virtuales.

La Figura 2 ilustra una forma de realización de una conectividad de rack. Según esta forma de realización, el clúster de vPE está conectado con una red central a través de una configuración de nodos hoja y nodos de columna vertebral, en la que la capa hoja y la capa columna vertebral en este caso pueden estar compuestos por cajas blancas. Además, el equipo cliente (en adelante "CE": customer equipment) también puede estar conectado con el clúster de vPE a través de unos puertos de caja blanca. Además, la conectividad para este caso puede estar dispuesta en una configuración de dos racks, con el fin de proporcionar una redundancia solicitada para una correcta operación del sistema.

La Figura 3 ilustra una forma de realización de una configuración de red de vPE, que comprende dos nodos de columna vertebral y dos nodos hoja, y la forma en que los dos nodos de columna vertebral están conectados con dos sistemas de enrutamiento de operador (CRS: Carrier Routing Systems) y los nodos hoja con respectivos motores de enrutamiento de vPE.

Las siguientes formas de realización se refieren al aprovisionamiento de un servicio de enrutamiento unificado.

La Figura 4 muestra una configuración de servicio de enrutamiento centralizado, en el que el clúster de vPE comprende un solo motor de enrutamiento (RE). El motor de enrutamiento tiene una funcionalidad de distribución del gestor de rutas de transmisión (FPM), con el fin de proporcionar a todos los motores de transmisión (FE) toda la información de enrutamiento necesaria para que puedan tratar cada caso de enrutamiento específico. El proceso de comunicación en el que se proporcionan unas actualizaciones de transmisión y enrutamiento (por ejemplo, después de su recuperación de una base de información de transmisión (FIB) y/o de una base de información de enrutamiento) utilizando unos túneles de encapsulamiento de enrutamiento genérico (GRE), que se extienden entre el motor de enrutamiento y cada motor de transmisión. La gestión del clúster de vPE se lleva a cabo para cada una de las máquinas virtuales (VM), utilizando múltiples interfaces dirección norte (NB: northbound) e implementando unos protocolos tales como CLI, SNMP, y similares.

A continuación, ténganse en cuenta las siguientes suposiciones:

1) Se utilizará un motor de transmisión (FE) específico como el motor de transmisión maestro en un respectivo servicio de ruta de datos;

2) El servicio de enrutamiento no cambia la dirección IP (la dirección del siguiente salto) mientras se está prestando el servicio;

3) No debe haber ningún cambio después de la eliminación de la interfaz interna en la respectiva máquina.

Las Figuras 5 y 6 ilustran dos formas de realización interpretadas de acuerdo con la presente invención para un solo motor de enrutamiento que reside con un motor de transmisión. La primera, en la que el motor de enrutamiento reside con un motor de transmisión maestro en una sola máquina virtual (Figura 5) y en que la otra forma de realización comprende un solo motor de enrutamiento que reside en una sola máquina virtual. La última opción tiene la ventaja de que proporciona una mayor disponibilidad del sistema.

De acuerdo con otra forma de realización de la presente divulgación, el clúster de vPE tiene su propio servicio de gestión unificado, de manera que el servicio tiene control sobre todo el clúster de vPE. Las Figuras 7 y 8 ilustran un sistema de vPE centralizado interpretado de acuerdo con esta forma de realización.

Opcionalmente, todos los protocolos de enrutamiento pueden ser manejados por el controlador centralizado. Por ejemplo, utilizando un protocolo eBGP para el tráfico de enrutamiento hacia el cliente, un protocolo iBGP para el reflector de rutas, un protocolo OSPF hacia la red central y otros bordes de proveedor, y similares.

Una forma de llevar a cabo un procedimiento para implementar esta forma de realización comprende las siguientes fases:

En primer lugar, una fase de inicio del servicio de enrutamiento (por ejemplo, inicializar el servicio de enrutamiento y sus interfaces virtuales). A continuación, la siguiente fase es iniciar el servicio de ruta de datos. En esta fase se pueden realizar preferiblemente las siguientes etapas:

- inicializar las interfaces virtuales;

- inicializar el controlador de mensajes

- Configurar los túneles de GRE (configuración asíncrona)

- Configurar los gestores de rutas de transmisión (FPM) (configuración asíncrona)

- Configuración de las interfaces (por ejemplo, proporcionando direcciones IP y direcciones MAC).

Un gestor para la forma de realización que se ha descrito anteriormente puede comprender diferentes interfaces API para proporcionar diferentes servicios (por ejemplo, servicios de ruta de datos y servicios de enrutamiento).

La Figura 9 muestra un ejemplo de un clúster de vPE y las diferentes funciones asociadas con dicho clúster.

Los servicios proporcionados por el gestor interno que se describen en el presente documento a modo de ejemplo, son los siguientes:

Servicio de registro

- registro en servidor TCP

- Configurar el gestor de la ruta de datos

Gestor de interfaces (API)

- impone una validación de la configuración

- consideraciones de tiempo de espera

Servicio de mantener vivo el Docker (Docker Keep Alive Service)

Servicio de mantener viva la máquina (Machine Keep Alive Service).

De acuerdo con todavía otra forma de realización de la divulgación, se utilizan unas interfaces dirección norte unificadas para proporcionar el servicio de gestión. Estas interfaces pueden ser compatibles con: CLI, SNMP, AAA, Netconf, Syslog, Web UI RestConf y similares.

Para el aprovisionamiento del servicio de enrutamiento, se requiere un procesamiento de rutas. Este procesamiento puede incluir un cálculo de rutas, un mantenimiento de la tabla de enrutamientos y una propagación de la accesibilidad, así como la ejecución de todos los protocolos de enrutamiento necesarios (OSPF, BGP, lDp , ISIS, RSVP) hacia los equipos cliente, los bordes de proveedor y los enrutadores centrales. Además, el motor de enrutamiento se utiliza para actualizar el motor de transmisión de todas sus bases de información de transmisión (FIB) y bases de información de enrutamiento (RIB) conocidas. Además, el servicio de ruta de datos puede ser utilizado por el servicio de enrutamiento para conectar el clúster de vPE con el mundo exterior (por ejemplo, con una red diferente).

La elasticidad de la red que se describe en el presente documento se puede mejorar aún más utilizando una o más de las siguientes opciones.

A. Utilizar contenedores de Docker mientras se opera el vPE. Este uso tiene una serie de ventajas, entre las que se encuentran: el uso de contenedores de Docker permite que el vPE comprenda un conjunto (es decir, una pluralidad) de micro servicios, y permite la ejecución en una sola VM, Multi-VM o hosts bare metal, en función de los requisitos de uso reales. El término "micro servicio", tal y como se utiliza en el presente documento, se refiere a un servicio que tiene las mismas características/funcionalidades que el servicio normal correspondiente, pero que se lleva a cabo a menor escala, por ejemplo, con una menor capacidad y/o un menor número de rutas y/o un menor número de clientes, etc.

B. El punto final de túnel de red de área local extensible virtual (VTEP: Virtual Extensible LAN Tunnel Endpoint) se encuentra en los contenedores de Docker y debe funcionar con independencia de la interfaz utilizada, todo ello sin afectar a ningún cambio en la interfaz subyacente. La superposición de la LAN extensible virtual ("VXLAN") debe transportar mensajes unidifusión para cada comunicación intercambiada entre los contenedores (la comunicación VTEP podría utilizar Multidifusión para ciertos mensajes de difusión L2 como las solicitudes ARP).

C. Uso de túneles de GRE que se extienden desde los motores de transmisión que se generan en base a cada puerto físico, y están adaptados para transportar:

- Tráfico de ruta hacia el motor de enrutamiento; y

- Tráfico de gestión hacia el gestor.

D. Uso de una gestión dentro de banda a través de la dirección lo-0.

Además, se debe tener en cuenta que cada micro pipeline es preferiblemente responsable de una función específica (por ejemplo, Tx, Rx, QoS, modelado, enrutamiento). Las pipelines Tx y Rx se pueden comunicar con el controlador de interfaz de red (NIC: network interface controller) utilizando un controlador de modo de sondeo (PMD: Poll Mode Driver).

La solución que se describe en el presente documento, permite la transmisión de tráfico al siguiente salto a lo largo de la ruta seleccionada con una velocidad de procesamiento de bits extremadamente alta. Las tareas de transmisión de paquetes realizadas por la ruta de datos pueden incluir además: una validación de paquetes, un control del tiempo de vida de los paquetes (TTL: time to live) y un cálculo de suma de comprobación.

Según otro aspecto de la divulgación, se proporciona una solución para su utilización en un sistema de comunicación de SDN, mediante la cual el tráfico que se transmite en una nube unificada (por ejemplo, una nube metropolitana (metro cloud)), es reorganizado en base a criterios predefinidos. Por ejemplo:

- Distribución del tráfico por nivel de seguridad requerido;

- Distribución del tráfico por nivel de servicio al cliente;

- Distribución del tráfico por tipo de servicio (por ejemplo, vídeo, IOT, 5G, voz, etc.)

- Distribución del tráfico por protocolo/servicio (vídeo/TCP).

Una forma de implementar esta solución es disponer de un procesador que está adaptado para añadir una o más indicaciones a los paquetes de comunicación incluidos en los flujos de tráfico que se enrutan en el sistema de comunicación de SDN, de modo que cuando estos paquetes de comunicación son transmitidos, la una o más indicaciones serán utilizadas por los motores de transmisión adecuados para que los paquetes de comunicación se transmitan de acuerdo con un criterio predefinido asociado con cada respectiva indicación.

Esto, a su vez, mejora la experiencia del usuario, así como la agilidad de la red, y al mismo tiempo, la gestión de una nube unificada reduce drásticamente los gastos implicados (gasto de capital (capex) y gasto de operación (opex)), ya que sólo hay que gestionar una nube metropolitana (Metro Cloud), en lugar de tener que gestionar tres redes metropolitanas (metro networks) separadas (Movilidad, Banda Ancha y Empresa), como ocurre actualmente.

Además, se pueden reducir los gastos de transporte y de borde/núcleo al implementar esta solución reduciendo (hairpinning) el tráfico en la red metropolitana (metro network).

Otras formas de realización de la invención serán evidentes para los expertos en la materia a partir de la consideración de la especificación y la puesta en práctica de la invención que se divulga en el presente documento.

Claims (16)

REIVINDICACIONES

1. Un subsistema operativo para su utilización como un clúster de bordes de proveedores virtuales (vPE: virtual Provider Edge) de un sistema de comunicación de SDN, y

caracterizado por el hecho de que dicho clúster de bordes de proveedores virtuales (vPE) comprende una pluralidad de elementos de red y una entidad de gestión, en el que dicho clúster de vPE comprende además uno o más motores de enrutamiento virtuales para enrutar el tráfico hacia/desde dicha pluralidad de elementos de red, dichos uno o más motores de enrutamiento virtuales están configurados para comunicarse con dicha entidad de gestión y con una pluralidad de motores de transmisión virtuales, y en el que dicha entidad de gestión está configurada para gestionar la operación del uno o más motores de enrutamiento virtuales y la pluralidad de motores de transmisión virtuales.

2. El subsistema de la reivindicación 1, en el que dicho clúster de vPE está conectado con una red central a través de una configuración de nodos hoja y nodos de columna vertebral.

3. El subsistema de la reivindicación 2, en el que dicha configuración de nodos hoja y nodos de columna vertebral es una disposición que comprende una pluralidad de cajas blancas.

4. El subsistema de la reivindicación 1, en el que dicho clúster de vPE comprende un solo motor de enrutamiento (RE) que tiene una funcionalidad de distribución de gestor de rutas de transmisión (FPM), y es operativo para proporcionar a los motores de transmisión (FE) asociados con dicho clúster de vPE, toda la información de enrutamiento necesaria para que puedan tratar todo el tráfico que necesita ser transmitido desde los mismos.

5. El subsistema de la reivindicación 4, en el que dicha información de enrutamiento es proporcionada a dichos motores de transmisión asociados con dicho clúster de vPE utilizando unos túneles de encapsulamiento de enrutamiento genérico (GRE) predefinidos que se extienden entre dicho motor de enrutamiento y un respectivo motor de transmisión.

6. El subsistema de la reivindicación 5, en el que dichos túneles de GRE están adaptados para permitir la transmisión de tráfico al motor de enrutamiento y el tráfico de gestión a la entidad de gestión.

7. El subsistema de la reivindicación 4, en el que dicho clúster de vPE está provisto con su propia gestión unificada, y la gestión se lleva a cabo utilizando una pluralidad de interfaces dirección norte (NB: northbound) para gestionar todas las máquinas virtuales asociadas con el clúster de vPE.

8. El subsistema de la reivindicación 4, en el que dicho motor de enrutamiento único reside en una sola máquina virtual junto con un motor de transmisión, o dicho motor de enrutamiento único reside en una pluralidad de máquinas virtuales junto con un motor de transmisión.

9. El subsistema de la reivindicación 4, en el que dicho clúster de vPE comprende una pluralidad de motores de enrutamiento, cada uno de los cuales tiene una funcionalidad de distribución de gestor de rutas de transmisión (FPM), y en el que la pluralidad de motores de enrutamiento reside en una sola máquina virtual junto con un motor de transmisión.

10. El subsistema de la reivindicación 3, en el que dicha pluralidad de cajas blancas comprende una pluralidad de hardware básico, que funciona bajo el control de la entidad de gestión que actúa como un controlador centralizado.

11. El subsistema de la reivindicación 1, que comprende un procesador configurado para generar contenedores de tipo docker que permiten al clúster de vPE establecer una pluralidad de micro servicios.

12. El subsistema de la reivindicación 11, en el que se proporciona una identificación de VTEP (Virtual Extensible LAN Tunnel Endpoint) con los contenedores de tipo docker.

13. Un sistema de comunicación de SDN que comprende una pluralidad de subsistemas de la reivindicación 1, y en el que todo el tráfico hacia/desde una pluralidad de elementos móviles, hacia/desde una pluralidad de elementos de comunicación de banda ancha y hacia/desde empresas, es transmitido a través de una sola nube unificada, después de haber sido reorganizado en base a criterios predefinidos.

14. El sistema de comunicación de SDN de la reivindicación 13, que comprende además un procesador operativo para añadir una o más indicaciones a los paquetes de comunicación incluidos en los flujos de tráfico que son enrutados en el sistema de comunicación de SDN, y en el que la una o más indicaciones están asociadas con al menos una respectiva característica de dichos paquetes de comunicación.

15. El sistema de comunicación de SDN de la reivindicación 14, en el que la al menos una respectiva característica de dichos paquetes de comunicación es un miembro de un grupo que consiste en: un nivel de seguridad asociado con el tráfico al que pertenecen los paquetes de comunicación; un acuerdo de nivel de servicio al cliente asociado con el tráfico al que pertenecen los paquetes de comunicación; un tipo de servicio de tráfico al que pertenecen los paquetes de comunicación; y un tipo de protocolo asociado con el tráfico al que pertenecen los paquetes de comunicación.

16. El sistema de comunicación de SDN de la reivindicación 13, que comprende además un procesador configurado para reorganizar el tráfico recibido, de modo que al menos uno de los flujos de tráfico comprende únicamente paquetes de comunicación que cumplen uno o más criterios predefinidos.