ES2735006T3 - Colocación del controlador para la falta rápida en la arquitectura dividida - Google Patents

Colocación del controlador para la falta rápida en la arquitectura dividida Download PDF

Info

Publication number
ES2735006T3
ES2735006T3 ES13716052T ES13716052T ES2735006T3 ES 2735006 T3 ES2735006 T3 ES 2735006T3 ES 13716052 T ES13716052 T ES 13716052T ES 13716052 T ES13716052 T ES 13716052T ES 2735006 T3 ES2735006 T3 ES 2735006T3
Authority
ES
Spain
Prior art keywords
controller
node
network
nodes
protected
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13716052T
Other languages
English (en)
Inventor
Neda Beheshti-Zavareh
Ying Zhang
Joel Halpern
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2735006T3 publication Critical patent/ES2735006T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0823Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/0836Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability to enhance reliability, e.g. reduce downtime
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • H04L41/122Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14Network analysis or design
    • H04L41/145Network analysis or design involving simulating, designing, planning or modelling of a network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/12Shortest path evaluation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/48Routing tree calculation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/64Routing or path finding of packets in data switching networks using an overlay routing layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W16/00Network planning, e.g. coverage or traffic planning tools; Network deployment, e.g. resource partitioning or cells structures
    • H04W16/18Network planning tools

Abstract

Un método implementado por un sistema de diseño de topología de red, el sistema de diseño de topología de red que incluye un dispositivo de procesamiento, el método para determinar la colocación de un controlador (315) dentro de una red con una arquitectura dividida donde los componentes del plano de control de la red de arquitectura dividida son ejecutados por un controlador (315) y los componentes del plano de control están separados de los componentes del plano de datos de la red de arquitectura dividida, en el que la colocación del controlador se selecciona para minimizar la interrupción de la red de arquitectura dividida causada por un fallo de enlace, un fallo de conmutador o una pérdida de conectividad entre el controlador y los componentes del plano de datos, el método comprendiendo los pasos de: a) hacer el gráfico (401) de una topología de la red de arquitectura dividida, con enlaces en la red de arquitectura dividida representados como un conjunto de bordes en un gráfico y elementos (317) de red en la red de arquitectura dividida representados como un conjunto de nodos (S1-S10) en los que el tráfico de control se envía desde y hacia el controlador a través de un árbol de enrutamiento de controlador enraizado en el controlador; b) para cada nodo (S1-S10) del gráfico generar un árbol de enrutamiento de controlador con cada nodo dicho que sirve como la raíz del árbol y recorrer (403) el conjunto de nodos (S1-S10) dentro del gráfico para calcular una métrica de protección para cada nodo, en el que la métrica de protección mide la resistencia de la red de arquitectura dividida como un grado de protección de fallo de nodo dentro de la red de arquitectura dividida para una colocación del controlador potencial, el grado de protección de fallo del nodo que determina un subconjunto de nodos protegidos en el conjunto de nodos, o en el que dicha métrica de protección es el número de nodos vecinos protegidos, donde un nodo protegido puede encapsular el tráfico de control dentro de un mensaje de datos y redirigir dicho tráfico de control a través de un túnel a un nodo intermedio en el gráfico que no está en sentido descendente del nodo protegido, y en el que dicho tráfico de control encapsulado es desencapsulado, y donde el túnel recorre al menos un nodo descendente del nodo protegido; y seleccionar (405) el elemento (317, 315) de red correspondiente al nodo que sirve como una raíz del árbol con una mejor métrica de protección para ser el controlador (315) para la red de arquitectura dividida.

Description

DESCRIPCIÓN
Colocación del controlador para la falta rápida en la arquitectura dividida
Campo de la invención
Las realizaciones de la invención se refieren a la organización y diseño de redes. Específicamente, las realizaciones de la invención se refieren a un método y sistema para determinar la colocación del controlador para conmutadores en una red de arquitectura dividida con un control desacoplado del reenvío.
Antecedentes
Un diseño de red de arquitectura dividida introduce una separación entre los componentes de control y reenvío de una red. Entre los casos de uso de dicha arquitectura se encuentran el dominio de acceso/agregación de redes de nivel de portadora, retorno móvil, computación en la nube y soporte multicapa (L3 & L2 & L1, OTN, WDM), centros de datos, todos los cuales se encuentran entre los principales bloques de construcción de una arquitectura de red. Por lo tanto, el diseño adecuado, la gestión y la optimización del rendimiento de estas redes son de gran importancia.
A diferencia de la arquitectura de red tradicional, que integra tanto el reenvío (datos) como los planos de control en la misma caja (elemento de red), una red de arquitectura dividida desacopla estos dos planos y ejecuta el plano de control en servidores que pueden estar en diferentes ubicaciones físicas de los elementos de reenvío (conmutadores). El uso de una arquitectura dividida en una red permite la simplificación de los conmutadores que implementan el plano de reenvío y cambia la inteligencia de la red a un número de controladores que supervisan los conmutadores.
El acoplamiento ajustado de los planos de reenvío y control en una arquitectura tradicional generalmente resulta en un plano de control demasiado complicado y una gestión de red compleja. Se sabe que esto crea una gran carga y una alta barrera para los nuevos protocolos y desarrollos tecnológicos. A pesar de la rápida mejora de las velocidades de línea, las densidades de puerto y el rendimiento, los mecanismos del plano de control de red han avanzado a un ritmo mucho más lento que los mecanismos del plano de reenvío.
En una red de arquitectura dividida, los controladores recopilan información de los conmutadores y calculan y distribuyen las decisiones de reenvío adecuadas a los conmutadores. Los controladores y conmutadores usan un protocolo para comunicarse e intercambiar información. Un ejemplo de dicho protocolo es OpenFlow (véase www.openflow.org), que proporciona un método abierto y estándar para que un conmutador se comunique con un controlador, y ha atraído un interés significativo tanto de los académicos como de la industria. La figura 1 es un diagrama que muestra una descripción general de la interfaz OpenFlow entre un conmutador y un controlador. La tabla de reenvío en un conmutador OpenFlow se llena con entradas que consisten en: una regla que define coincidencias para campos en encabezados de paquetes; una acción asociada a la coincidencia de flujo; y una recopilación de estadísticas sobre el flujo.
Cuando un paquete entrante coincide con una regla particular, las acciones asociadas se realizan en el paquete. Una regla contiene campos clave de varios encabezados en la pila de protocolos, por ejemplo, direcciones mAc de Ethernet, dirección IP, protocolo IP, números de puerto TCP/UDP, así como el número de puerto entrante. Para definir un flujo, se pueden usar todos los campos coincidentes disponibles. Pero también es posible restringir la regla coincidente a un subconjunto de los campos disponibles mediante el uso de comodines para los campos no deseados.
La plataforma de control desacoplada de la arquitectura dividida facilita la tarea de modificar la lógica de control de la red y proporciona una interfaz programática sobre la cual los desarrolladores pueden construir una amplia variedad de nuevos protocolos y aplicaciones de gestión. En este modelo, los datos y planos de control pueden evolucionar y escalar de forma independiente, mientras que el costo de los elementos del plano de datos se reduce.
Los siguientes documentos divulgan técnicas de antecedentes tecnológicos adicionales en relación con redes de arquitectura dividida:
D1 YING ZHANG ET AL.: “Sobre resistencia de redes de arquitectura”, CONFERENCIA DE TELECOMUNICACIONES GLOBAL, (GLOBECOM 2011), 2011, IEEE, IEEE, 5 de diciembre de 2011 (.201105-12-2011), páginas 1-6,
XP032119688,
DOI: 10.1109/GLOCOM.2001.6134496
ISBN: 978-1-4244-9266-4
D2 Nick McKeown ET AL.: “OpenFlow: permitir la innovación en redes de campo”, 14 de marzo de 2008 (14-03­ 2008), páginas 1-6, XP055002028,
Recuperado de Internet: URL: http://www.openflow.org/documents/openflow-wp-latest.pdf [recuperado el 05­ 07-2011]
D3 EP 2552065 A1 (ERICSSON TELEFON AB L M [SE]) 30 de enero de 2013 (30-01-2013)
D4 NEDA BEHESHTI ET AL.: “Conmutación por error rápida para tráfico de control en redes definidas por software”, CONFERENCIA DE COMUNICACIÓN GLOBAL (GLOBECOM), 2012 IEEE, IEEE, 3 de diciembre de 2012, (03-12-2012), páginas 2665-2670, XP032375076,
DOI: 10-1109/GLOBOCOM.2012-6503519
ISBN: 978-1-4673-0920-2
El documento D1 explica la colocación del controlador y la resistencia de la red con respecto a los algoritmos llamados “algoritmo de corte mínimo” y “algoritmo codicioso”. La topología de la red se mapea a un gráfico y una función de coste es minimizada para encontrar una colocación óptima del controlador de tal manera que se protegen tantos conmutadores como sea posible.
El documento D2 explica el protocolo OpenFlow para el uso de redes de arquitectura dividida.
El documento D3 también explica el concepto de considerar la resistencia de red para calcular la métrica para los conmutadores. Una colocación óptima del controlador es determinada también con un algoritmo.
En el documento D4 un “algoritmo óptimo” y un “algoritmo codicioso” son explicados para la colocación del controlador.
Sumario
Las realizaciones de la invención incluyen un método implementado por un sistema de diseño de topología de red, como se reivindica en la reivindicación independiente 1.
Las realizaciones incluyen una red con una arquitectura dividida, como se reivindica en la reivindicación independiente 9.
Las realizaciones incluyen un sistema informático como se reivindica en la reivindicación independiente 12.
Se proporcionan aspectos adicionales en las reivindicaciones independientes
Breve descripción de los dibujos
La presente invención se ilustra a modo de ejemplo, y no a modo de limitación, en las figuras de los dibujos adjuntos, en los que las referencias similares indican elementos similares. Se debe tener en cuenta que las diferentes referencias a "una" o "una sola" realización en esta divulgación no son necesariamente a la misma realización, y tales referencias significan al menos una. Además, cuando un rasgo, estructura o característica particular se describe en relación con una realización, se afirma que es del conocimiento de un experto en la técnica afectar dicho rasgo, estructura o característica en relación con otras realizaciones, tanto s se describe explícitamente como si no.
La figura 1 es un diagrama de una realización de una arquitectura de ejemplo para una red OpenFlow.
Las figuras 2A y 2B son diagramas de una realización de una red de arquitectura dividida que contiene conmutadores tanto protegidos como no protegidos, cada figura ilustra un mecanismo de protección separado. La figura 3 es un diagrama de una realización de un sistema de diseño acoplado a una red con colocación del controlador optimizada.
La figura 4 es un diagrama de flujo de una realización de un proceso de optimización de colocación del controlador. La figura 5 es un diagrama de flujo de una realización de un proceso de colocación del controlador óptimo.
La figura 6 es un diagrama de flujo de una realización de un proceso de colocación del controlador "codicioso". Descripción detallada
En la siguiente descripción, se exponen numerosos detalles específicos. Sin embargo, se entiende que las realizaciones de la invención pueden ponerse en práctica sin estos detalles específicos. En otros casos, los circuitos, estructuras y técnicas bien conocidos no se han mostrado en detalle para no dificultar la comprensión de esta descripción. Sin embargo, un experto en la técnica apreciará que la invención puede ponerse en práctica sin tales detalles específicos. Los expertos en la técnica, con las descripciones incluidas, podrán implementar la funcionalidad apropiada sin experimentación excesiva.
Las operaciones de los diagramas de flujo se describirán con referencia a las realizaciones de ejemplo de diagramas. Sin embargo, debe entenderse que las operaciones de los diagramas de flujo pueden realizarse mediante realizaciones de la invención distintas de las discutidas con referencia a los diagramas, y las realizaciones explicadas con referencia a diagramas pueden realizar operaciones diferentes a las explicadas con referencia a los diagramas de flujo.
Las técnicas mostradas en las figuras se pueden implementar usando el código y los datos almacenados y ejecutados en uno o más dispositivos electrónicos (por ejemplo, una estación de extremo, un elemento de red, un servidor o dispositivos electrónicos similares). Tales dispositivos electrónicos almacenan y comunican (internamente y/o con otros dispositivos electrónicos a través de una red) el código y los datos usando medios no transitorios legibles por máquina o legibles por ordenador, tales como medios de almacenamiento no transitorios legibles por máquina o legibles por ordenador (por ejemplo, discos magnéticos, discos ópticos, memoria de acceso aleatorio, memoria de solo lectura, dispositivos de memoria flash y memoria de cambio de fase). Además, tales dispositivos electrónicos incluyen típicamente un conjunto de uno o más procesadores acoplados a uno o más componentes, como uno o más dispositivos de almacenamiento, dispositivos de entrada/salida del usuario (por ejemplo, un teclado, una pantalla táctil y/o una pantalla), y conexiones de red. El acoplamiento del conjunto de procesadores y otros componentes se realiza típicamente a través de uno o más buses y puentes (también denominados controladores de bus). Los dispositivos de almacenamiento representan uno o más medios de almacenamiento no transitorios legibles por máquina o legibles por ordenador y medios de comunicación no transitorios legibles por máquina o legibles por ordenador. Por lo tanto, el dispositivo de almacenamiento de un dispositivo electrónico dado típicamente almacena código y/o datos para su ejecución en el conjunto de uno o más procesadores de ese dispositivo electrónico. Por supuesto, una o más partes de una realización de la invención pueden implementarse usando diferentes combinaciones de software, firmware y/o hardware.
Como se usa en el presente documento, un elemento de red (por ejemplo, un enrutador, un conmutador, un puente o un dispositivo de red similar) es una pieza de equipo de red, que incluye hardware y software que interconecta de forma comunicativa a otros equipos en la red (por ejemplo, otros elementos de red, estaciones de extremo o dispositivos de red similares). Algunos elementos de red son "elementos de red de servicios múltiples" que proporcionan soporte para múltiples funciones de red (por ejemplo, enrutamiento, conexión en puente, conmutación, agregación de Capa 2, control de borde de sesión, multidifusión y/o gestión de abonados), y/o proporcionan soporte para múltiples servicios de aplicación (por ejemplo, recolección de datos). Las realizaciones descritas en el presente documento usan el ejemplo de elemento de red en forma de un conmutador. Sin embargo, las realizaciones no están limitadas a los conmutadores y son aplicables a otros tipos de elementos de red.
Tal como se usa en el presente documento, la resistencia es la capacidad de proporcionar y mantener un nivel aceptable de servicio ante fallos y desafíos para el funcionamiento normal. Como se usa en el presente documento, la probabilidad de fallo es la frecuencia con la que falla un sistema o componente diseñado, expresado como el número de fallos por hora, o la probabilidad de que cada nodo falle a largo plazo.
Al evaluar el diseño de una red, la resistencia de la red es un factor importante, ya que un fallo de unos pocos milisegundos puede fácilmente ocasionar pérdidas de datos de terabyte en enlaces de alta velocidad. En las redes tradicionales, donde tanto el control como los paquetes de datos se transmiten en el mismo enlace, el control y la información de los datos se ven igualmente afectados cuando hay un fallo. El trabajo existente en la resistencia de la red, por lo tanto, ha asumido un modelo de control en banda, lo que significa que el plano de control y el plano de datos tienen las mismas propiedades de resistencia. Sin embargo, este modelo no es aplicable a las redes de arquitectura dividida.
Un fallo de enlace indica que el tráfico que recorre un enlace ya no se puede transferir a través del enlace. El fallo puede ser un enlace entre dos conmutadores o un enlace entre un controlador y el conmutador al que se conecta. En la mayoría de los casos, estos enlaces fallan de forma independiente.
Un fallo de conmutación indica que el elemento de red correspondiente no puede originar, responder ni reenviar ningún paquete. Los fallos de conmutador pueden ser causados por errores de software, fallos de hardware, configuraciones erróneas y problemas similares. En la mayoría de los casos, estos conmutadores fallan independientemente.
Los casos especiales de fallo incluyen la pérdida de conectividad entre un conmutador y un controlador. Un conmutador puede perder la conectividad con su controlador debido a fallos en los enlaces intermedios o nodos a lo largo de la ruta entre el conmutador y el controlador. En una realización, siempre que un conmutador no pueda comunicarse con su controlador asignado, el conmutador descartará todos los paquetes en el plano de reenvío gestionado por el controlador, incluso aunque la ruta en el plano de reenvío aún sea válida. En otras realizaciones, un subconjunto del tráfico puede reenviarse en un plano de reenvío o una funcionalidad limitada similar puede continuar por un tiempo limitado hasta que se restablezca una conexión con un controlador asignado u otro controlador. Por lo tanto, esto puede ser considerado como un caso especial de fallo de conmutador.
Los paquetes de control en redes de arquitectura dividida se pueden transmitir en diferentes rutas del paquete de datos (o incluso en una red separada). Por lo tanto, la confiabilidad del plano de control en estas redes ya no está directamente vinculada con la del plano de reenvío. Sin embargo, la desconexión entre el controlador y el plano de reenvío en la arquitectura dividida podría deshabilitar el plano de reenvío; cuando un conmutador se desconecta de su controlador, no puede recibir ninguna instrucción sobre cómo reenviar nuevos flujos y queda prácticamente fuera de línea.
En una realización de una red de arquitectura dividida, cada conmutador está preprogramado con una ruta para llegar al controlador. Al producirse un fallo de enlace o nodo, el conmutador confía en el controlador para detectar tal fallo y volver a calcular la nueva ruta para el conmutador. Sin embargo, el manejo de todos los fallos por parte del controlador podría resultar en grandes retrasos en la red. En otra realización, la configuración previa de una ruta de respaldo y/o una tunelización hacia un conmutador intermedio se usa para restablecer la comunicación con un controlador, de modo que si el enlace de salida primario no funciona correctamente, se podría usar el enlace de salida de respaldo (secundario) o una encapsulación del tráfico de control a través de un túnel a un conmutador intermedio.
Cuando un conmutador detecta un fallo en su enlace saliente o su nodo ascendente inmediato, inmediatamente cambia su camino hacia el controlador y usa la ruta de respaldo, es decir, la interfaz saliente, preprogramada en el conmutador para volver a conectarse al controlador. En la alternativa, el conmutador detecta el fallo y encapsula el tráfico de control para la transmisión a través de un túnel a un conmutador intermedio que desencapsula el tráfico de control y reenvía el tráfico de control al controlador. Esto se lleva a cabo sin necesidad de involucrar al controlador y sin ningún efecto en el resto de los caminos de la red y en las conexiones de los nodos descendentes al controlador. En otras palabras, solo habrá un cambio local en la interfaz saliente del conmutador afectado. Todas las demás conexiones en la red permanecerán intactas. Sin tales rutas de respaldo u opciones de encapsulación, la detección de cualquier fallo en los conmutadores o enlaces por parte del controlador debe basarse en algunos mecanismos implícitos, como cuando el controlador no recibe los mensajes de saludo de un conmutador. Esto introduce grandes retrasos en la red para detectar la ubicación exacta del fallo y restablecer las conexiones de conmutador-controlador. Si no se puede configurar una ruta de respaldo o una opción de tunelización para un conmutador, entonces la conexión de conmutador a controlador se interrumpirá en caso de un fallo en la ruta primaria al controlador.
Como se usa en el presente documento, se considera que un conmutador está protegido (en su conexión con el controlador) contra el fallo de su conmutador ascendente inmediato y su enlace saliente si se cumple alguna de las siguientes condiciones: i) el conmutador puede usar un enlace saliente de respaldo para su tráfico de control hacia el controlador, o ii) el conmutador puede enviar su tráfico de control a través de un túnel a otro conmutador (intermedio) y desde allí al controlador.
Cuando hay un fallo en el enlace saliente o en el nodo ascendente inmediato de un conmutador protegido, el conmutador puede usar el enlace saliente de respaldo (si la condición i es válida) para volver a conectarse al controlador. En la alternativa (si se cumple la condición ii), el conmutador puede encapsular el mensaje de control dentro de un mensaje de datos y enviarlo a otro conmutador (intermedio). Cuando el conmutador intermedio recibe este mensaje, desencapsulará el mensaje y lo enviará, como su propio tráfico de control, al controlador.
Si no se cumple ninguna de las dos condiciones anteriores, en caso de un fallo en el enlace saliente o el conmutador ascendente inmediato, la conexión entre el conmutador y el controlador se interrumpirá. El objetivo es minimizar la posibilidad de tal interrupción. El escenario más resistente es, claramente, cuando cada conmutador en la red está protegido. Pero si ese no es el caso, entonces se requiere cierta optimización para minimizar el riesgo de interrupción del tráfico de control.
Al usar este esquema de protección en una red de arquitectura dividida, es importante colocar el controlador de modo que sea menos probable que se interrumpa la conexión entre el plano de control y el plano de reenvío. Una buena selección de la ubicación del controlador debe dar como resultado rutas confiables desde los conmutadores al controlador, en el sentido de que una gran cantidad de conmutadores deben tener rutas de respaldo al controlador. Las realizaciones de la invención proporcionan un método y un sistema para evitar las desventajas de la técnica anterior. Las propuestas existentes en el diseño de red de arquitectura dividida asumen ubicaciones fijas para los controladores de red. Si bien ha habido algunas investigaciones sobre los mecanismos de enrutamiento entre los controladores de red y los conmutadores, no se han desarrollado estrategias para elegir la ubicación optimizada para el controlador de red. Como resultado, la colocación del controlador en arquitecturas divididas no tiene en cuenta la posibilidad de desconexión entre un controlador y el plano de reenvío y busca minimizar esta posibilidad.
Además, los esquemas para redes de arquitectura dividida con múltiples controladores se centran en la partición de la red y la asignación de un controlador a cada partición de tal manera que los conmutadores dentro de cada partición estén bien conectados. Esto no aborda la búsqueda de una ubicación óptima para un controlador en una red determinada sin partición. Los esquemas para colocar un solo controlador en una red de arquitectura dividida pueden colocar al controlador en un nodo que maximice la resistencia de la conexión entre el controlador y los conmutadores, sin embargo, estos esquemas se basan en una definición de protección restringida. En tales esquemas, un conmutador protegido es un conmutador con un enlace saliente de respaldo y no considera la posibilidad de enviar el tráfico de control a través de un túnel a otro conmutador y desde allí al controlador.
Las realizaciones de la invención superan estas desventajas de la técnica anterior. Las realizaciones de la invención colocan un solo controlador en un área de arquitectura dividida, en una ubicación seleccionada para optimizar la resistencia de la conexión entre el controlador y los conmutadores en esa área. No se hacen suposiciones sobre cómo se realiza la partición de las áreas de arquitectura dividida. La partición, en su caso, puede basarse en cualquier métrica arbitraria, como las restricciones geográficas. Las realizaciones de la invención abarcan dos procesos de ejemplo (es decir, un proceso óptimo y un proceso codicioso) para elegir la ubicación del controlador para optimizar la resistencia de la conexión entre el controlador y los conmutadores, es decir, para maximizar el número de conmutadores con rutas de respaldo preconfiguradas al controlador a través de enlaces de respaldo directos o mediante el tráfico de control de tunelización a un elemento de red intermedio que no se encuentra en sentido descendente desde el punto de fallo.
Las realizaciones soportan una definición más general para un conmutador protegido. Si no hay una interfaz saliente de respaldo para un conmutador, el conmutador todavía se considera protegido si puede enviar su tráfico de control a otro conmutador (intermedio) y desde allí al controlador. En este caso, el conmutador encapsula el mensaje de control dentro de un mensaje de datos al conmutador intermedio. Cuando el conmutador intermedio recibe este mensaje, desencapsulará el mensaje y lo enviará (como su propio tráfico de control) al controlador. Este mecanismo de protección alternativo se refiere en el presente documento como protección basada en tunelización, y el término tunelización se refiere al proceso de encapsular el mensaje de tráfico dentro de un mensaje de datos, enviarlo al conmutador intermedio y, finalmente, desencapsularlo en el conmutador intermedio. Usando esta definición más general de protección, las realizaciones incluyen procesos y sistemas para colocar de manera óptima el controlador en la red de manera que se maximice la resistencia.
Ubicación del controlador de red
La resistencia de la conexión entre el plano de control y el plano de reenvío es de gran importancia en las redes de arquitectura dividida. Si se interrumpe esta conexión, entonces el plano de reenvío no sabrá cómo reenviar nuevos flujos (es decir, esos flujos sin reglas existentes en los conmutadores) y perderá su funcionalidad de reenvío. Las realizaciones de la invención proporcionan un proceso para decidir dónde colocar el controlador de arquitectura dividida, de manera que es menos probable que se interrumpa esta conexión (entre el plano de control y el plano de reenvío). Dada una topología de red, el proceso busca elegir el nodo correcto en la red para ubicar el controlador en ese nodo. Una buena selección de la ubicación del controlador de una red debe dar como resultado rutas confiables desde los conmutadores al controlador, en el sentido de que cada conmutador debe tener una ruta de respaldo (secundaria) al controlador o una protección basada en tunelización que no se verá afectada por el mismo fallo, en caso de que su ruta principal falle, esta ruta de respaldo puede ser un enlace directo entre el conmutador que detecta el fallo y otro conmutador en la red que permanece en comunicación con el controlador o una protección basada en tunelización en forma de un enlace indirecto entre el conmutador que detecta el fallo y un conmutador intermedio sobre un túnel donde el túnel recorre al menos un conmutador descendente.
Métrica de protección
Para evaluar diferentes estrategias de colocación del controlador en una red (y para desarrollar una política para elegir una buena ubicación), se utiliza una métrica de protección, que se basa en la protección de nodos. Esta métrica se aplica a la arquitectura dividida para evaluar la resistencia de la red frente a fallos de enlace, como se define anteriormente y se explica con más detalle en el presente documento a continuación.
Los fallos transitorios ocurren con relativa frecuencia incluso en redes de protocolo de Internet (IP) bien gestionadas. Sin embargo, se espera que el servicio de red esté siempre disponible con la creciente demanda de entrega de servicios críticos. Con los altos requisitos de confiabilidad de la red, las realizaciones de la invención buscan mejorar la resistencia de la conectividad entre el controlador y los conmutadores en una red de arquitectura dividida.
Entorno de red
Las realizaciones de la invención proporcionan un proceso en el que el reenvío de paquetes de datos se reanuda después de un fallo tan pronto como sea posible. Los protocolos de pasarela interior (IGP) existentes, como abrir primero la ruta más corta (OSPF) y el sistema intermedio al sistema intermedio (IS-IS), típicamente tardan varios segundos en converger, lo que no alcanza un nivel de recuperación de fallos inferior a 50 ms. que se espera para la confiabilidad de la red. El controlador podría detectar los fallos en los conmutadores o enlaces usando algunos mecanismos implícitos, por ejemplo, cuando el controlador no recibe mensajes de saludo desde un conmutador. Sin embargo, este método también introducirá un gran retraso en la red para la detección de fallos y la restauración del servicio.
En una realización, la decisión de conmutación de protección se realiza localmente y está predeterminada por el controlador (es decir, en el elemento de red que detecta el fallo). Esto es diferente del escenario en una red tradicional, porque el elemento de red no tiene una topología completa de la red. El elemento de red es solo un simple conmutador en el plano de reenvío y solo recibe reglas de reenvío desde el controlador. Cuando se pierde la conectividad con el controlador, el conmutador debe tomar la decisión de realizar una conmutación por error de forma independiente sin recibir instrucciones del controlador. En otras palabras, solo habrá un cambio local en la interfaz saliente del conmutador afectado. Todas las demás conexiones en la red permanecerán intactas. De esta manera, el proceso mantiene el elemento de reenvío, es decir, el conmutador, lo más simple posible.
En una realización, el controlador está en la misma red física que los conmutadores. Es decir, la infraestructura existente de la red de arquitectura dividida (enlaces y conmutadores existentes) se usa para conectar el controlador a todos los conmutadores de la red, en lugar de usar una infraestructura separada para conectar los planos de control y reenvío.
Como se usa en el presente documento, una red de conmutadores se indica mediante un gráfico G = (V, E), donde V es el conjunto de nodos (conmutadores y el controlador) en la red y E es el conjunto de bordes bidireccionales (enlaces) entre nodos. Se asocia un costo a cada enlace en la red. Basándose en los costos de enlace asignados, los caminos de ruta más corta se calculan entre dos nodos cualesquiera en la red. Se supone que el costo en cada enlace se aplica a ambas direcciones del enlace. También se supone que no hay equilibrio de carga en el tráfico de control enviado entre los conmutadores y el controlador. Por lo tanto, cada nodo tiene solo una ruta para llegar al controlador. En otras palabras, el tráfico de control se envía desde y hacia el controlador a través de un árbol, enraizado en el controlador, al que se hará referencia en el presente documento como un árbol de enrutamiento del controlador. Este árbol de enrutamiento cubre todos los nodos de la red y un subconjunto de los bordes. El mismo árbol de enrutamiento se usa para las comunicaciones entre el controlador y los conmutadores en ambas direcciones.
Con una ubicación de controlador determinada, cualquier protocolo de enrutamiento de ruta más corta forma un árbol T, enraizado en el nodo del controlador, que cubre todos los nodos y un subconjunto de los bordes. Como se mencionó anteriormente, este árbol se conoce como el árbol de enrutamiento del controlador. Las figuras 2A y 2B muestran una red y su árbol de enrutamiento del controlador. En estas figuras, las líneas discontinuas muestran todos los enlaces en la red, y las líneas continuas muestran los enlaces usados en el árbol de enrutamiento del controlador. Cada nodo puede llegar al controlador enviando su tráfico de control a lo largo de las rutas en el árbol de enrutamiento del controlador. En estos ejemplos, ambas direcciones de cada enlace tienen el mismo costo y, por lo tanto, el mismo árbol de enrutamiento se usará para las comunicaciones entre el controlador y los conmutadores en ambas direcciones.
En el árbol de enrutamiento del controlador T, el nodo u es un nodo ascendente del nodo v si hay una ruta en T desde el nodo v al nodo u hacia el controlador. El nodo u se denomina nodo descendente del nodo v si hay una ruta en T desde el nodo u al nodo v hacia el controlador. En el ejemplo de redes ilustradas en las figuras 2A y 2B, por ejemplo, el nodo S4 es un nodo ascendente de los nodos S7 y S8, y estos dos nodos son nodos descendentes del nodo S4. En el árbol de enrutamiento del controlador, el padre de un nodo es su nodo ascendente inmediato y los hijos de un nodo son sus nodos descendentes inmediatos. Debido a la estructura de árbol asumida, cada nodo tiene solo un nodo ascendente inmediato en T. En el ejemplo y en las realizaciones del proceso de colocación del controlador, se supone que no hay equilibrio de carga en el tráfico de control enviado desde los conmutadores al controlador. Es decir, asumimos que cada nodo en la red tiene solo un nodo ascendente inmediato en T. Los símbolos introducidos en el presente documento (por ejemplo, G, T, u y v) se usan en el presente documento a continuación para representar estos conceptos por razones de claridad y precisión.
Fallos de nodo y enlace
Como se explicó anteriormente en el presente documento, se considera que un conmutador está protegido (en su conexión con el controlador) contra el fallo de su conmutador ascendente inmediato y su enlace saliente si el conmutador puede:
i) Usar un enlace saliente de respaldo para controlar el tráfico hacia el controlador; o
ii) Enviar su tráfico de control a través de un túnel a otro conmutador (intermedio) y desde allí al controlador.
Por ejemplo, un conmutador protegido que detecta un fallo en su enlace saliente o su nodo ascendente inmediato si la condición (i) se cumple, tan pronto como se detecte el fallo, cambiará inmediatamente su camino hacia el controlador y usará el enlace saliente de respaldo para reconectarse al controlador. Si se cumple la condición (ii), entonces el conmutador puede encapsular el mensaje de control dentro de un mensaje de datos al conmutador intermedio. Cuando el conmutador intermedio recibe este mensaje, desencapsulará el mensaje y lo enviará (como su propio tráfico de control) al controlador. En ambos casos, el redireccionamiento del tráfico de control tiene lugar sin ningún impacto en el resto de las conexiones de otros conmutadores al controlador. En otras palabras, solo habrá un cambio local en la interfaz saliente del conmutador afectado. Todas las demás conexiones en la red permanecerán intactas. En una realización, el conmutador puede llevar a cabo cualquiera de estos procesos de conmutación por error (es decir, aquellos vinculados a la condición (i) o (ii)) automáticamente sin la participación del controlador.
Si ninguna de estas dos condiciones se cumple, entonces, en caso de un fallo en la ruta primaria al controlador, la conexión entre el conmutador y el controlador se interrumpirá. El proceso de colocación del controlador y el sistema descritos en la presente invención están diseñados para minimizar la posibilidad de tal interrupción. La configuración más resistente de la red es, claramente, cuando todos los conmutadores de la red están protegidos. Pero si esa configuración no es posible, entonces se requiere cierta optimización de la colocación del controlador para minimizar el riesgo de interrupción del tráfico de control entre el controlador y los conmutadores en la red.
Para aquellos conmutadores que están conectados directamente al controlador, la protección del nodo ascendente no está definida ni cuantificada, ya que el nodo ascendente inmediato es el controlador. En las redes de arquitectura dividida en las que se implementan las herramientas tradicionales de gestión de fallos, no existe un mecanismo de señalización extendido para que un nodo informe a sus nodos descendentes de un fallo. Por lo tanto, si un conmutador se desconecta del controlador, todos sus nodos descendentes también se desconectarán, incluso si ellos mismos están protegidos contra sus enlaces salientes o fallos inmediatos de los nodos ascendentes. Esto significa que al evaluar la resistencia de las redes, se debe asignar más importancia a los nodos más cercanos al controlador (que es la raíz del árbol de enrutamiento del controlador). Para representar estas facetas de la red que afectan la resistencia de la red, se definen ponderaciones para cada nodo que se basan en el número de sus nodos descendentes.
Una ponderación de un árbol de enrutamiento puede definirse como la suma de las ponderaciones de todos sus nodos no protegidos. Esta ponderación se puede usar para medir la "desprotección" o la resistencia de la red para una posición de controlador asociada. Para un árbol de enrutamiento T dado, esta ponderación del árbol de enrutamiento se puede describir o representar con la "ponderación (T)", que debe minimizarse para maximizar la resistencia de la red.
Las figuras 2A y 2B muestra un ejemplo de redes y dos escenarios de fallo. Las líneas continuas entre los conmutadores y el controlador en estas figuras muestran el árbol de ruta más corta entre el controlador y los conmutadores. Si no hay fallos en la red, el tráfico de control se enviará a/desde el controlador en este árbol representado por las líneas continuas.
Por ejemplo, el conmutador S4 en esta red está conectado al controlador a través de su padre ascendente S1. En ambos escenarios mostrados en las figuras 2A y 2B, el conmutador S4 está protegido. Esto se debe a que en caso de fallo en el conmutador ascendente inmediato S1 o el enlace que conecta S4 y S1, todavía hay una ruta de respaldo para que el tráfico de control del conmutador S1 llegue al controlador. En el caso ilustrado en la figura 2A, hay un enlace entre S4 y S5 representado por la línea de puntos. Este enlace no forma parte del árbol de enrutamiento, por lo que este enlace se puede configurar en el conmutador S4 como un enlace saliente de respaldo para el tráfico de control. Por lo tanto, si S4 detecta un fallo en el enlace saliente primario entre los conmutadores S4 y S1 o en el conmutador ascendente S1, entonces el conmutador S4 puede usar el enlace saliente de respaldo entre los conmutadores S4 y S5.
En el caso ilustrado en la figura 2B, no hay un enlace que conecte S4 a otro conmutador que pueda usarse como enlace de respaldo. Se debe tener en cuenta que ninguno de los enlaces que conectan S4 con sus hijos (conmutadores S6 y S8) se pueden usar como un enlace saliente de respaldo para el tráfico de control, ya que no tienen una ruta en el árbol de enrutamiento al controlador que no pasa por el enlace fallido o el conmutador fallido (es decir, el enlace entre los conmutadores S4 y S1 o el conmutador S1). En este caso, sin embargo, hay un enlace entre los conmutadores S8 y S9. Aquí, el conmutador S4 puede hacer un túnel desde el conmutador S8 al conmutador S9 (encapsulando el tráfico de control con el conmutador S9 como destino). Cuando el conmutador S9 recibe y desencapsula este tráfico, puede enviar el tráfico al controlador (como su propio tráfico de control) en la ruta S9-S5-S2-controlador. Cabe señalar que esta ruta no pasa a través de S4 y S1, evitando así el enlace o conmutador fallido en este ejemplo. En otras palabras, el controlador ha seleccionado un conmutador intermedio cuya ruta hacia el controlador no se ve afectada por el fallo de conmutador S1 o el enlace entre los conmutadores S4 y S1.
Evaluación del estado de protección de un conmutador
En una realización, cada conmutador S en una red de arquitectura dividida puede tener evaluado su estado de protección. Tal como se usa en el presente documento, 'padre (S)' indica el conmutador ascendente inmediato del conmutador S, y 'sentido descendente (S)' indica todos los conmutadores descendentes del conmutador S (es decir, sus hijos e hijos de hijos y así sucesivamente). Cada conmutador S en una red dada está protegido de acuerdo con nuestra definición anterior si, y solo si, existen los conmutadores A y B en la red, de manera tal que se use la notación de teoría de conjuntos estándar:
1. A está en {S} U sentido descendente (S), es decir, A es S o uno de los nodos descendentes del conmutador S. 2. B no está en el sentido descendente (padre (S)).
3. Existe un enlace entre A y B, que no forma parte del árbol de enrutamiento del controlador.
Si se cumplen las tres condiciones anteriores, en caso de fallo, el conmutador S puede enviar su tráfico de control a través de un túnel al conmutador B y de allí al controlador. Si el conmutador A es S, el conmutador S puede usar el enlace S-B como enlace saliente de respaldo para el tráfico de control; por lo tanto, no hay necesidad de tunelización en este caso especial. Básicamente, las condiciones anteriores garantizan que el tráfico de control pueda enviarse a través de un subárbol diferente al enraizado en el padre del nodo S. Es decir, el tráfico podría omitir el conmutador/enlace fallido.
Dado que el árbol de enrutamiento del controlador es el árbol de ruta más corta, las tres condiciones anteriores también garantizan que la ruta desde el conmutador B al controlador no pase por S y su nodo ascendente inmediato (padre). Por lo tanto, el controlador S-B de ruta podría usarse cuando el conmutador S detecta un fallo (ya sea en su nodo ascendente inmediato o en el enlace que conecta S a su nodo ascendente inmediato).
Volviendo a los ejemplos de las figuras 2A y 2B, los conmutadores A = S4 y B = S5 en la figura 2A satisfacen las tres condiciones anteriores, y en la figura 2B, los conmutadores A = S8 y B = s 9 satisfacen estas condiciones.
Implementación de protección usando OpenFlow
En una realización, el proceso de colocación del controlador puede aplicarse a cualquier implementación de una red de arquitectura dividida. La tabla de reenvío en un conmutador OpenFlow, por ejemplo, se rellena con entradas que consisten en una regla que define coincidencias para campos en encabezados de paquetes, un conjunto de acciones asociadas con la coincidencia de flujo y una colección de estadísticas sobre el flujo. La versión 1.1 de la especificación OpenFlow introduce un método para permitir que un único activador de coincidencia de flujo se envíe en más de uno de los puertos del conmutador. La conmutación por error rápida es uno de estos métodos. Usando este método, el conmutador ejecuta el primer conjunto de acciones en vivo. Cada conjunto de acciones está asociado con un puerto especial que controla su vida. El método rápido de conmutación por error de OpenFlow permite que el conmutador cambie el reenvío sin requerir un viaje de ida y vuelta al controlador.
Proceso de colocación del controlador
La protección de los nodos en una red depende tanto de la selección de las rutas primarias (para una ubicación del controlador dada) como de la elección de la ubicación del controlador. Como se establece a continuación, se define una política de enrutamiento general que, para cada elección de la ubicación del controlador, selecciona las rutas principales en la red para llegar al controlador. Esta selección podría basarse en cualquier métrica deseada, por ejemplo, métricas de rendimiento como retraso o carga. También se analiza lo que incluye una búsqueda exhaustiva para encontrar la mejor ubicación para estas rutas primarias seleccionadas arbitrariamente.
Arquitectura del sistema de diseño y red de ejemplo con ubicación de controlador optimizada
La figura 3 es un diagrama de una realización de un sistema de diseño acoplado a una red con una colocación del controlador optimizada. El diagrama proporciona una ilustración de un ejemplo de sistema 301 de diseño de red para ejecutar la herramienta del sistema de diseño de red. El sistema 301 de diseño de red puede ser cualquier tipo de dispositivo informático, incluida un ordenador de escritorio, un servidor, un dispositivo informático de mano, un dispositivo de consola, un dispositivo portátil o un dispositivo informático similar. El sistema 301 de diseño de red incluye un conjunto de procesadores 303 para ejecutar los componentes de la herramienta del sistema de diseño de red que incluye un módulo 305 de gráfico de topología, un módulo 307 de colocación del controlador y componentes similares. En otras realizaciones, cualquiera o todos estos módulos pueden implementarse como un conjunto de módulos o dispositivos de hardware. El procesador 303 también puede ejecutar un módulo 309 de gestión de red para comunicarse y/o gestionar la red de arquitectura dividida.
El módulo 305 de gráfico de topología puede convertir una topología de red en un gráfico representativo y realizar funciones gráficas en el gráfico representativo para soportar el módulo 307 de colocación del controlador. El módulo 307 de colocación del controlador opera en el gráfico generado por el módulo 305 de gráfico de topología y dirige las operaciones gráficas para implementar un proceso de colocación óptimo o un proceso de colocación "codicioso" para determinar una ubicación para un controlador como se describe más adelante en el presente documento. El módulo 309 de gestión de red puede comunicarse con el módulo 303 de colocación del controlador y/o el módulo 305 de gráfico de topología para descubrir la topología de la red para un proceso automatizado y/o para implementar la colocación del controlador en un proceso automatizado. En otras realizaciones, el módulo 307 de colocación del controlador genera un informe o salida similar a un usuario para implementar una organización de red y el módulo 309 de gestión de red puede omitirse.
La red de arquitectura dividida ilustrada es una implementación de ejemplo con una colocación del controlador de ejemplo consistente con la optimización de la colocación del controlador. En el ejemplo, hay un controlador 315 para controlar el dominio o el área de arquitectura dividida que consta de los conmutadores 317. Los conmutadores 317 son gestionados por el controlador 315 usando el árbol 319 de enrutamiento del controlador mostrado como líneas de puntos que conectan los conmutadores 317, donde las líneas continuas 321 son los enlaces entre los conmutadores 317. El proceso para determinar la ubicación del controlador 315 se describe a continuación en el presente documento.
Ubicación optimizada del controlador para una conmutación por error rápida
El proceso general de colocación del controlador se describe con respecto a la figura 4. La entrada del proceso de colocación del controlador es el gráfico de topología de la red G = (V, E), y la salida es el controlador_ubicación, es decir, el nodo de red en el que se ubicará el controlador.
El proceso general de colocación del controlador se inicia haciendo un gráfico la topología de la red de arquitectura dividida (bloque 401). Los nodos y los enlaces entre los nodos se pueden determinar mediante la entrada del administrador, los procesos de descubrimiento automatizados o cualquier combinación de los mismos. El gráfico representa elementos de red (por ejemplo, conmutadores) en la red como nodos en un gráfico con los enlaces de comunicación entre estos elementos de red representados como enlaces o bordes en el gráfico.
Después, el proceso recorre los nodos en el gráfico para calcular una métrica de protección para cada nodo en el gráfico (bloque 403). La métrica de protección como se describe en el presente documento anteriormente y más adelante en el presente documento, mide la resistencia de la red de arquitectura dividida como un grado de protección de fallo de nodo para cada ubicación de controlador posible dentro de la red, es decir, para cada nodo o elemento de red posible en la red que puede hospedar el controlador. La métrica de protección mide la resistencia de la red de arquitectura dividida como un grado de protección de fallo de nodo dentro de la red de arquitectura dividida para una posible colocación del controlador. El grado de protección de fallo de nodo determina un subconjunto de nodos protegidos (es decir, elementos de red protegidos) en el conjunto de nodos (es decir, el conjunto de elementos de red), donde un nodo protegido en el subconjunto de nodos protegidos puede redirigir el tráfico de control a través de un túnel a un nodo intermedio en el gráfico que no esté en sentido descendente del nodo protegido, y donde el túnel recorra al menos un nodo descendente del nodo protegido.
Una vez que se determina la métrica de protección para cada nodo en el gráfico, se selecciona el elemento de red correspondiente al nodo en el gráfico con la mejor métrica de protección (bloque 405). El elemento de red seleccionado se envía luego al administrador de red para la implementación manual o a un módulo de gestión de red para la implementación automatizada o cualquier combinación de los mismos. La selección de un elemento de red mediante este proceso proporciona una estrategia de protección optimizada para la red en su conjunto.
Hay dos procesos de ejemplo más específicos para recorrer el gráfico y determinar la métrica de protección para los nodos en ella. En el primer proceso, un proceso de colocación óptimo, se buscan todas las ubicaciones posibles para el controlador y se elige la que maximiza el número de conmutadores protegidos. En un segundo proceso, un proceso 'codicioso', se realiza un recorrido más rápido y sencillo de los nodos con una evaluación más aproximada. Colocación del controlador - Proceso de colocación óptima
Una realización del proceso se ilustra a continuación en la Tabla I como pseudocódigo.
Tabla I
Proceso de colocación óptima
1. V = conjunto de todos los nodos en la red; n = |V|
2. para cada nodo v en V hacer
3. T = árbol de enrutamiento del controlador enraizado en v
4. ponderación (T) = 0
5. para cada nodo u t v hacer
6. ponderación (u) = 0
7. Si (u no está protegido) entonces
8. ponderación (u) = 1 número de nodos descendentes de u en T 9 fin
10. ponderación (T) = ponderación (T) ponderación (u);
11. fin
12. fin
13. controlador_ubicación= nodo v con ponderación mínima (T)
Como se describe brevemente en la sección anterior, la métrica de protección para cada nodo en una red de gráfico se basa en la ponderación de un árbol arraigado en ese nodo. La ponderación del árbol se calcula donde cada nodo descendente desprotegido en el árbol tiene un árbol enraizado que se agrega a un valor inicial de la ponderación del árbol que se establece en cero (línea 4). Para cada nodo en el árbol que está desprotegido, se asigna una ponderación que se basa en el número de sus nodos descendentes (líneas 7 y 8). Las ponderaciones de cada uno de estos nodos no protegidos se acumulan para calcular la ponderación del árbol (línea 10). Una vez que se generan todas las ponderaciones de los árboles, se selecciona el árbol con la ponderación mínima para la colocación del controlador, ya que proporcionará a la configuración la mayor resistencia debido a que tiene la menor cantidad de nodos desprotegidos cerca del controlador.
Este proceso se describe en relación con el diagrama de flujo de la figura 5. El proceso de colocación óptima es iniciado por el módulo de colocación del controlador en respuesta a la recepción de un gráfico topológico de la red de arquitectura dividida del módulo de gráfico de topología (bloque 501). El proceso luego comienza a iterar a través de cada uno de los nodos en el gráfico (bloque 503). Los nodos se pueden iterar en serie o en paralelo, ya que el orden de evaluación no es importante, ya que cada nodo debe examinarse y se debe generar una métrica de protección.
Para cada nodo en el gráfico, se genera un árbol de enrutamiento del controlador con el nodo dado que sirve como la raíz del árbol (bloque 505). La ponderación de este árbol tiene un valor inicial de cero. Después, para cada uno de estos árboles de enrutamiento, se recorren los nodos dentro de estos árboles (bloque 507). El orden de recorrido de los nodos dentro de los árboles de enrutamiento no es importante y cada uno puede examinarse en paralelo o en serie. Para cada nodo en cada árbol de enrutamiento se da una ponderación inicial de cero (bloque 509). Luego se verifica si el nodo seleccionado actualmente está protegido como se define en el presente documento anteriormente (bloque 51 1). Si el nodo seleccionado actualmente no está protegido, se calcula una ponderación para este nodo (bloque 515). La ponderación se puede calcular por un recuento de la cantidad de nodos que están en sentido descendente del nodo actualmente seleccionado. Este número de nodos descendentes sirve como la ponderación para el nodo seleccionado actualmente en el cálculo de la ponderación del árbol de enrutamiento global. Si el nodo seleccionado actualmente en el árbol de enrutamiento está protegido como se define en el presente documento anteriormente, entonces retiene la ponderación de cero.
A medida que se calcula la ponderación de cada nodo, se suma con la ponderación del árbol actual o la 'ponderación del nodo de raíz actual' (bloque 517). Este proceso de suma se puede hacer de forma iterativa, en cuyo caso se realiza una verificación para determinar si es necesario examinar nodos adicionales en el árbol (bloque 519). El proceso de suma también se puede hacer en un proceso paralelo o un proceso similar.
De manera similar, se realiza una verificación para determinar si todos los nodos de un gráfico se han revisado para determinar la ponderación de su respectivo árbol de enrutamiento del controlador (bloque 521). Esta ponderación del árbol de enrutamiento del controlador puede ser la métrica de protección para el nodo de raíz correspondiente. Una vez que se hayan calculado todas las métricas de protección para todos los nodos en el gráfico, entonces se puede seleccionar el nodo con la mejor métrica de protección (por ejemplo, la ponderación de árbol asociado más bajo o mínimo) para asignar el controlador (bloque 523).
Colocación del controlador - Proceso de colocación codiciosa
Si el tamaño de la red de arquitectura dividida es grande, entonces una búsqueda exhaustiva entre todas las ubicaciones podría volverse muy compleja. En este segundo proceso, presentamos una manera codiciosa de encontrar una ubicación con conexiones ricas entre sus conmutadores conectados directamente. En este proceso, el grado de un nodo v (número de sus vecinos en G) se indica mediante D (v). El proceso comienza seleccionando el nodo v(1) (línea 3), el primer nodo de una lista ordenada de nodos de red, ordenados en un orden de grado decreciente.
Tabla II
Proceso de colocación codicioso
1. V = conjunto de todos los nodos en la red; = |V|;
2. Ordenar los nodos en V de modo que D(v(1)) > D(v(2)) > ... >D(v(n))
3. nodo seleccionado ^ v(1)
4.
5. para i = 1 a n hacer
6. A = vecinos de v(i) en V
7. D'(v(i)) = número de miembros de A que están conectados a al menos otro miembro de A a través de una ruta que no pasa a través de v(i)
8. si D'(v(i))> D' (nodo seleccionado) entonces nodo seleccionado ^ v(i)
9. si (D'(v(i)) == D(v(i)) entonces romper
10. fin
11. controlador_ubicación ^ nodo seleccionado
El objetivo de este proceso es encontrar el nodo con el número máximo de vecinos protegidos. Aquí, D'(v) indica el número de vecinos protegidos del nodo v. En la iteración zésima del proceso, se calcula el número de vecinos protegidos (tal como se define en el presente documento anteriormente) del nodo v(i) (línea 6), y la ubicación del controlador se actualiza al nodo v(i) si se cumple, en términos del número de vecinos protegidos, los nodos buscados anteriormente (líneas 7 y 8). El proceso se detiene cuando encuentra el nodo con el número máximo de vecinos protegidos, que se elegirá como el nodo donde se ubicará el controlador.
La métrica de protección usada en este proceso es el número máximo de vecinos protegidos. Como se explicó anteriormente, los nodos más cercanos al controlador pesan más (que los que están más alejados del controlador), porque si se interrumpe su conexión a la red, todos sus nodos descendentes se verán afectados y desconectados. Por lo tanto, es importante elegir una ubicación para el controlador de modo que sus vecinos, es decir, aquellos conmutadores que están directamente conectados al controlador, estén bien protegidos.
La figura 6 es un diagrama de flujo de una realización del proceso de colocación codicioso. El proceso puede iniciarse recibiendo un gráfico topológico de la red de arquitectura dividida por el módulo de colocación del controlador (bloque 601). El conjunto de nodos se examina para determinar el número de enlaces a los nodos vecinos para cada uno de los nodos del gráfico. Los nodos se ordenan basándose en esta evaluación del número de vecinos (bloque 603). Inicialmente, el nodo con la mayoría de los enlaces vecinos se establece como la ubicación predeterminada o actual para el controlador. Después, el proceso comienza a iterar a través de cada uno de los nodos ordenados comenzando con el nodo con el mayor número de vecinos y avanzando a través de la lista ordenada en orden descendente (bloque 605).
El nodo seleccionado luego se analiza para determinar el número de enlaces a vecinos que están protegidos (bloque 607). Luego se realiza una verificación para comparar el número de enlaces protegidos de este nodo con el número de enlaces protegidos del nodo establecido o inicialmente seleccionado como la ubicación actual (bloque 609). Si el nodo que se está analizando supera el nodo de ubicación actual, entonces, el nodo de ubicación actual se actualiza (bloque 611). El proceso continúa verificando si el número de nodos protegidos del nodo de ubicación actual es menor que el número de vecinos para que se examine el siguiente nodo (bloque 613). Si el número de nodos protegidos excede el siguiente nodo en el número de vecinos de la lista ordenada, entonces el proceso puede completar y generar el nodo seleccionado actual para usarlo como ubicación de colocación del controlador (bloque 615). De lo contrario, el proceso continúa en el siguiente nodo en la lista ordenada.
La resistencia de la red es uno de los factores más importantes en la evaluación de cualquier diseño de red. Un fallo de unos pocos milisegundos puede fácilmente resultar en pérdidas de datos de terabyte en los enlaces de velocidades de transmisión de alta velocidad. Desde la perspectiva de la implementación práctica, estos procesos para la ubicación optimizada del controlador maximizan la resistencia entre el controlador y los conmutadores en la arquitectura dividida. Estos procesos maximizan la resistencia de la red al maximizar el número de conmutadores que están protegidos con rutas de respaldo preconfiguradas o protección basada en tunelización que se encuentran cerca del controlador. En caso de fallos, los elementos de reenvío afectados podrían cambiar inmediatamente a sus rutas de respaldo o caminos basadas en túneles y restaurar sus conexiones con el controlador.
Las realizaciones de la invención pueden proporcionar directrices para que los operadores implementen su red de una manera rentable. Pueden mejorar la resistencia de la red de arquitectura dividida, lo que puede evitar que cientos de miles de flujos se vean afectados por fallos transitorios.
Uso de las redes de arquitectura dividida
Se puede implementar una red de arquitectura dividida para el retorno celular para soportar el reenvío basado en MPLS. En LTE, también se puede implementar en el núcleo móvil para enrutar el tráfico de usuarios entre MME, GW de servicio y PDN-GW. En este caso, el controlador puede implementarse en múltiples sitios o múltiples ubicaciones en un sitio. Los procesos en esta invención se pueden usar para calcular la mejor ubicación para la colocación del controlador.
Cuando coexisten múltiples tecnologías, por ejemplo, GSM, 3G, LTE, pueden compartir las mismas redes de transporte de paquetes. En este ejemplo, se puede usar un conjunto común de controladores para controlar las funciones de conmutación de paquetes para todas las redes juntas. Esta invención se puede usar para determinar la ubicación del controlador para controlar múltiples redes de tecnología.
En la computación en la nube, especialmente las redes de centro de datos, para reducir el costo de la infraestructura de red, se prefiere la arquitectura dividida con un controlador inteligente y un conjunto de conmutadores de bajo costo. En el entorno de red de centro de datos, el proceso de colocación del controlador se puede aplicar para implementar los controladores.
Debe entenderse que la descripción anterior pretende ser ilustrativa y no restrictiva. Muchas otras realizaciones serán evidentes para los expertos en la técnica al leer y comprender la descripción anterior. El alcance de la invención, por lo tanto, debe determinarse con referencia a las reivindicaciones adjuntas.

Claims (19)

REIVINDICACIONES
1. - Un método implementado por un sistema de diseño de topología de red, el sistema de diseño de topología de red que incluye un dispositivo de procesamiento, el método para determinar la colocación de un controlador (315) dentro de una red con una arquitectura dividida donde los componentes del plano de control de la red de arquitectura dividida son ejecutados por un controlador (315) y los componentes del plano de control están separados de los componentes del plano de datos de la red de arquitectura dividida, en el que la colocación del controlador se selecciona para minimizar la interrupción de la red de arquitectura dividida causada por un fallo de enlace, un fallo de conmutador o una pérdida de conectividad entre el controlador y los componentes del plano de datos, el método comprendiendo los pasos de:
a) hacer el gráfico (401) de una topología de la red de arquitectura dividida, con enlaces en la red de arquitectura dividida representados como un conjunto de bordes en un gráfico y elementos (317) de red en la red de arquitectura dividida representados como un conjunto de nodos (S1-S10) en los que el tráfico de control se envía desde y hacia el controlador a través de un árbol de enrutamiento de controlador enraizado en el controlador;
b) para cada nodo (S1-S10) del gráfico
generar un árbol de enrutamiento de controlador con cada nodo dicho que sirve como la raíz del árbol
y recorrer (403) el conjunto de nodos (S1-S10) dentro del gráfico para calcular una métrica de protección para cada nodo, en el que la métrica de protección mide la resistencia de la red de arquitectura dividida como un grado de protección de fallo de nodo dentro de la red de arquitectura dividida para una colocación del controlador potencial, el grado de protección de fallo del nodo que determina un subconjunto de nodos protegidos en el conjunto de nodos, o en el que dicha métrica de protección es el número de nodos vecinos protegidos,
donde un nodo protegido puede encapsular el tráfico de control dentro de un mensaje de datos y redirigir dicho tráfico de control a través de un túnel a un nodo intermedio en el gráfico que no está en sentido descendente del nodo protegido, y en el que dicho tráfico de control encapsulado es desencapsulado, y donde el túnel recorre al menos un nodo descendente del nodo protegido; y
seleccionar (405) el elemento (317, 315) de red correspondiente al nodo que sirve como una raíz del árbol con una mejor métrica de protección para ser el controlador (315) para la red de arquitectura dividida.
2. - El método de la reivindicación 1, en el que recorrer el conjunto de nodos para calcular la métrica de protección comprende además el paso de calcular un árbol de enrutamiento para cada nodo en el conjunto de nodos con cada nodo en una raíz de un árbol de enrutamiento correspondiente, teniendo cada árbol de enrutamiento una estructura de árbol con cada nodo que solo tiene un nodo ascendente inmediato en la estructura de árbol.
3. - El método de la reivindicación 2, en el que recorrer el conjunto de nodos para calcular la métrica de protección comprende además los pasos de determinar la ponderación del árbol de enrutamiento basándose en un número de nodos descendentes desprotegidos en el árbol de enrutamiento.
4. - El método de la reivindicación 3, en el que recorrer el conjunto de nodos para calcular la métrica de protección comprende además el paso de sumar todas las ponderaciones de nodo en cada árbol de enrutamiento para obtener la métrica de protección para cada nodo correspondiente en la red de arquitectura dividida.
5. - El método de la reivindicación 4, en el que seleccionar el elemento de red correspondiente al nodo con una mejor métrica de protección para que sea el controlador (315) de la red de arquitectura dividida comprende además el paso de seleccionar el nodo con una ponderación de nodo mínimo para un árbol de enrutamiento correspondiente entre todas las ponderaciones de nodo para todos los árboles de enrutamiento correspondientes al conjunto de nodos en la red de arquitectura dividida.
6. - El método de la reivindicación 1, en el que recorrer el conjunto de nodos para calcular la métrica de protección comprende además el paso de ordenar el conjunto de nodos en orden descendente basándose en un número de enlaces a nodos vecinos para cada nodo.
7. - El método de la reivindicación 6, en el que recorrer el conjunto de nodos para calcular la métrica de protección comprende además el paso de determinar un número de nodos vecinos protegidos con una conexión a otros nodos.
8. - El método de la reivindicación 7, en el que seleccionar el elemento de red correspondiente al nodo con una mejor métrica de protección para que sea el controlador (315) para la red de arquitectura dividida comprende el paso de seleccionar un nodo con el mayor número de nodos vecinos protegidos para que sea el controlador (315).
9. - Una red con una arquitectura dividida donde los componentes del plano de control de la red de arquitectura dividida son ejecutados por un controlador (315) y los componentes del plano de control están separados de los componentes del plano de datos de la red de arquitectura dividida, en la que la colocación del controlador (315) se selecciona para minimizar la interrupción de la red de arquitectura dividida causada por un fallo de enlace, un fallo de conmutación o una pérdida de conectividad entre el controlador (315) y los componentes del plano de datos, comprendiendo la red:
a) un conjunto de elementos (317) de red interconectados por un conjunto de enlaces de comunicación, cada elemento de red en el conjunto de elementos de red ejecutando un conmutador (317) que está controlado por y en comunicación con el controlador (315); y el controlador ejecutado por uno de los conjuntos de elementos de red, en el que una posición del elemento de red en el conjunto de elementos de red dentro de la red de arquitectura dividida proporciona un número optimizado de enlaces protegidos entre el controlador (315) y cada uno de los elementos (317) de red en el conjunto de elementos de red, el número optimizado correspondiente a una mejor métrica de protección para el elemento de red en el conjunto de elementos de red, en el que una topología de la red de arquitectura dividida es tal que los enlaces en la red de arquitectura dividida se representan como un conjunto de bordes en un gráfico y los elementos (317) de red en la red de arquitectura dividida se representan como un conjunto de nodos (S1-S10), en el que el tráfico de control se envía hacia y desde el controlador a través de un árbol de enrutamiento de controlador enraizado en el controlador;
b) en el que la métrica de protección mide la resistencia de la red de arquitectura dividida como un grado de protección de fallo de nodo dentro de la red de arquitectura dividida para una colocación del controlador potencial, el grado de protección de fallo de nodo determinando un subconjunto de elementos de red protegidos en el conjunto de elementos de red, o en el que la métrica de protección es el número de nodos vecinos protegidos;
donde un elemento de red protegido o nodo protegido puede encapsular el tráfico de control dentro de un mensaje de datos y redirigir el tráfico de control encapsulado a través de un túnel a un nodo intermedio en el gráfico que no está en sentido descendente del elemento de red protegido, y en el que dicho tráfico de control encapsulado es desencapsulado, y donde el túnel recorre al menos un elemento de red descendente del elemento de red protegido.
10. - La red de la reivindicación 9, en la que el conjunto de elementos de red forma un plano de datos de un núcleo de paquete evolucionado (EPC) en una red de evolución a largo plazo (LTE), y el controlador (315) proporciona un plano de control del EPC en la red LTE.
11. - La red de la reivindicación 9, en la que el conjunto de elementos (317) de red forma un conjunto de planos de datos para una pluralidad de tecnologías de red celular, y el controlador proporciona un plano de control para cada una de la pluralidad de tecnologías de red celular.
12. - Un sistema informático para determinar una colocación de un controlador (315) para una red de arquitectura dividida donde los componentes del plano de control de la red de arquitectura dividida son ejecutados por el controlador (315) y los componentes del plano de control están separados de los componentes del plano de datos de la red de arquitectura dividida, en el que el tráfico de control enviado hacia y desde el controlador a través de un árbol de enrutamiento de controlador enraizado en el controlador; en el que la colocación del controlador (315) se selecciona para minimizar la interrupción de la red de arquitectura dividida causada por un fallo de enlace, un fallo de conmutador o una pérdida de conectividad entre el controlador y los componentes del plano de datos, el sistema informático comprendiendo:
a) un procesador (303) configurado para ejecutar un módulo (305) de gráfico de topología y un módulo (307) de colocación del controlador, el módulo (305) de gráfico de topología configurado para hacer el gráfico una topología de la red de arquitectura dividida, con enlaces en la red de arquitectura dividida representados como un conjunto de bordes en un gráfico y elementos (317) de red en la red de arquitectura dividida representados como un conjunto de nodos (S1-S10);
b) el módulo (307) de colocación del controlador configurado para generar para cada nodo (S1-S10) en el gráfico un árbol de enrutamiento de controlador con cada dicho nodo sirviendo como la raíz del árbol
y recorrer el conjunto de nodos dentro del gráfico para calcular una métrica de protección para cada nodo (S1-S10), en el que la métrica de protección mide la resistencia de la red de arquitectura dividida como un grado de protección de fallo de nodo dentro de la red de arquitectura dividida para una colocación del controlador potencial, el grado de protección de fallo de nodo determinando un subconjunto de nodos protegidos en el conjunto de nodos, o en el que dicha métrica de protección es el número de nodos vecinos protegidos;
donde un nodo protegido en el subconjunto de nodos protegidos puede encapsular el tráfico de control dentro de un mensaje de datos y redirigir dicho tráfico de control encapsulado a través de un túnel a un nodo intermedio en el gráfico que no está en sentido descendente del nodo protegido, y en el que dicho tráfico de control encapsulado se desencapsula, y donde el túnel recorre al menos un nodo descendente del nodo protegido,
c) el módulo (307) de colocación del controlador está configurado además para seleccionar el elemento de red correspondiente a un nodo que sirve como una raíz del árbol con la mejor métrica de protección para ser el controlador (315) de la red de arquitectura dividida.
13. - El sistema informático de la reivindicación 12, en el que el módulo (307) de colocación del controlador está configurado además para calcular un árbol de enrutamiento para cada nodo en el conjunto de nodos con cada nodo en una raíz de un árbol de enrutamiento correspondiente, cada dicho árbol de enrutamiento teniendo una estructura de árbol con cada nodo teniendo solo un nodo ascendente inmediato en la estructura de árbol.
14. - El sistema informático de la reivindicación 12, en el que el módulo (307) de colocación del controlador está configurado además para determinar la ponderación del árbol de enrutamiento basándose en un número de nodos descendentes desprotegidos en el árbol de enrutamiento.
15. - El sistema informático de la reivindicación 14, en el que el módulo (307) de colocación del controlador está configurado además para sumar todas las ponderaciones de nodo en cada árbol de enrutamiento para obtener la métrica de protección para cada nodo correspondiente en la red de arquitectura dividida.
16. - El sistema informático de la reivindicación 15, en el que el módulo (307) de colocación del controlador está configurado además para seleccionar el nodo con una ponderación de nodo mínimo para un árbol de enrutamiento correspondiente entre todas las ponderaciones de nodos para todos los árboles de enrutamiento correspondientes al conjunto de nodos en la red de arquitectura dividida.
17. - El sistema informático de la reivindicación 12, en el que el módulo (307) de colocación del controlador está configurado además para ordenar el conjunto de nodos en orden descendente basándose en un número de enlaces a nodos vecinos para cada nodo.
18. - El sistema informático de la reivindicación 17, en el que el módulo (307) de colocación del controlador está configurado además para determinar un número de nodos vecinos protegidos con una conexión a otros nodos.
19. - El sistema informático de la reivindicación 18, en el que el módulo (307) de colocación del controlador está configurado además para seleccionar un nodo con el mayor número de nodos vecinos protegidos para que sea el controlador (315).
ES13716052T 2012-02-22 2013-02-18 Colocación del controlador para la falta rápida en la arquitectura dividida Active ES2735006T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/402,732 US8811212B2 (en) 2012-02-22 2012-02-22 Controller placement for fast failover in the split architecture
PCT/IB2013/051320 WO2013124783A1 (en) 2012-02-22 2013-02-18 Controller placement for fast failover in the split architecture

Publications (1)

Publication Number Publication Date
ES2735006T3 true ES2735006T3 (es) 2019-12-13

Family

ID=48093037

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13716052T Active ES2735006T3 (es) 2012-02-22 2013-02-18 Colocación del controlador para la falta rápida en la arquitectura dividida

Country Status (5)

Country Link
US (3) US8811212B2 (es)
EP (1) EP2817928B1 (es)
CN (1) CN104247344B (es)
ES (1) ES2735006T3 (es)
WO (1) WO2013124783A1 (es)

Families Citing this family (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9185027B2 (en) * 2011-07-29 2015-11-10 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resilient routing of control traffic in a split-architecture system
US8804490B2 (en) * 2011-07-29 2014-08-12 Telefonaktiebolaget L M Ericsson (Publ) Controller placement for fast failover in the split architecture
US8811212B2 (en) 2012-02-22 2014-08-19 Telefonaktiebolaget L M Ericsson (Publ) Controller placement for fast failover in the split architecture
US9264295B1 (en) * 2012-03-02 2016-02-16 Big Switch Networks, Inc. Systems and methods for forwarding broadcast network packets with a controller
WO2013152496A1 (zh) * 2012-04-12 2013-10-17 华为技术有限公司 接收信息的方法、发送信息的方法及装置
US9374270B2 (en) * 2012-06-06 2016-06-21 Juniper Networks, Inc. Multicast service in virtual networks
US9898317B2 (en) 2012-06-06 2018-02-20 Juniper Networks, Inc. Physical path determination for virtual network packet flows
US9276877B1 (en) 2012-09-20 2016-03-01 Wiretap Ventures, LLC Data model for software defined networks
US9787567B1 (en) * 2013-01-30 2017-10-10 Big Switch Networks, Inc. Systems and methods for network traffic monitoring
FI20135519A (fi) * 2013-05-15 2014-11-16 Tellabs Oy Ohjelmallisesti määriteltävän verkon verkkoelementti
US9667447B2 (en) * 2013-07-08 2017-05-30 Nicira, Inc. Managing context identifier assignment across multiple physical domains
US10454714B2 (en) 2013-07-10 2019-10-22 Nicira, Inc. Method and system of overlay flow control
US9374308B2 (en) * 2013-08-30 2016-06-21 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Openflow switch mode transition processing
US9397917B2 (en) * 2014-01-10 2016-07-19 Huawei Technologies Co., Ltd. System and method for zoning in software defined networks
US9736558B2 (en) * 2014-01-17 2017-08-15 Cisco Technology, Inc. Optical path fault recovery
KR20150088559A (ko) * 2014-01-24 2015-08-03 한국전자통신연구원 네트워크의 장애를 복구하는 방법 및 장치
US9479457B2 (en) 2014-03-31 2016-10-25 Juniper Networks, Inc. High-performance, scalable and drop-free data center switch fabric
US9485191B2 (en) 2014-03-31 2016-11-01 Juniper Networks, Inc. Flow-control within a high-performance, scalable and drop-free data center switch fabric
US9703743B2 (en) 2014-03-31 2017-07-11 Juniper Networks, Inc. PCIe-based host network accelerators (HNAS) for data center overlay network
US9294304B2 (en) 2014-03-31 2016-03-22 Juniper Networks, Inc. Host network accelerator for data center overlay network
JP6287518B2 (ja) * 2014-04-14 2018-03-07 富士通株式会社 オープンフロースイッチおよびオープンフローネットワークの障害復旧方法
US20170118066A1 (en) * 2014-04-30 2017-04-27 Hewlett-Packard Development Company, L.P. Data plane to forward traffic based on communications from a software defined (sdn) controller during a control plane failure
US10389117B2 (en) * 2014-05-13 2019-08-20 Georgia Tech Research Corporation Dynamic modeling and resilience for power distribution
US9407534B2 (en) * 2014-05-27 2016-08-02 Telefonaktiebolaget L M Ericsson (Publ) Enhanced procedure to compute LFAs with IGP max metric
US9973393B2 (en) 2014-07-01 2018-05-15 International Business Machines Corporation Utilizing a controller for preprogramming a network before removal of a network device
CN104125147B (zh) * 2014-08-11 2017-05-17 烽火通信科技股份有限公司 实现下一跳的配置数据分离的方法
US9473832B2 (en) * 2014-11-13 2016-10-18 Fujitsu Limited GCC0 tunneling over an OTN transport network
US10091082B2 (en) 2014-11-28 2018-10-02 At&T Intellectual Property I, L.P. Methods and apparatus to capture data plane information
CN107006050A (zh) 2014-12-12 2017-08-01 瑞典爱立信有限公司 用于处理控制平面信令的方法和节点
US10135670B2 (en) 2014-12-22 2018-11-20 Hewlett Packard Enterprise Development Lp Response to an inoperative network device managed by a controller
US9684433B2 (en) * 2014-12-30 2017-06-20 Ebay Inc. Trusted device identification and event monitoring
CN105812170B (zh) * 2014-12-31 2019-01-18 华为技术有限公司 基于数据中心的故障分析方法和装置
US9807019B2 (en) * 2015-03-30 2017-10-31 Alcatel Lucent Offline optimization for traffic engineering with segment routing
US10135789B2 (en) 2015-04-13 2018-11-20 Nicira, Inc. Method and system of establishing a virtual private network in a cloud service for branch networking
US10298515B1 (en) * 2015-06-05 2019-05-21 VCE IP Holding Company LLC Methods, systems, and computer readable mediums for creating a tenant cloud
US9923811B2 (en) 2015-06-27 2018-03-20 Nicira, Inc. Logical routers and switches in a multi-datacenter environment
US9825850B2 (en) 2015-06-30 2017-11-21 Industrial Technology Research Institute Network controlling method and network controller
US10868708B2 (en) 2015-11-02 2020-12-15 Google Llc System and method for handling link loss in a network
CN105307182B (zh) * 2015-11-10 2021-03-12 南京佰联信息技术有限公司 移动通信设备的部署方法及装置
US9813286B2 (en) 2015-11-26 2017-11-07 Industrial Technology Research Institute Method for virtual local area network fail-over management, system therefor and apparatus therewith
FR3044849A1 (fr) * 2015-12-07 2017-06-09 Orange Procede anti-micro-boucle pendant la convergence de tables de commutation
CN105553728B (zh) * 2015-12-18 2018-07-03 南京大学 一种基于软件定义网络技术的网络容灾恢复系统及方法
US9794805B1 (en) * 2016-06-21 2017-10-17 International Business Machines Corporation Robustness of a cellular network by using synergistic shapley values to identify censorious macrocells
US10103968B2 (en) 2016-12-13 2018-10-16 Industrial Technology Research Institute Tree recovery method, controller and recording medium for software-defined network
US10397044B2 (en) * 2017-01-13 2019-08-27 New York University Network function virtualization (“NFV”) based communications network resilience
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US11706127B2 (en) 2017-01-31 2023-07-18 Vmware, Inc. High performance software-defined core network
US20200036624A1 (en) 2017-01-31 2020-01-30 The Mode Group High performance software-defined core network
US10243840B2 (en) 2017-03-01 2019-03-26 Juniper Networks, Inc. Network interface card switching for virtual networks
US20180287858A1 (en) * 2017-03-31 2018-10-04 Intel Corporation Technologies for efficiently managing link faults between switches
WO2018222838A1 (en) * 2017-05-31 2018-12-06 Affirmed Networks, Inc. Decoupled control and data plane synchronization for ipsec geographic redundancy
US10708138B2 (en) 2017-06-09 2020-07-07 Datera, Inc. System and method for an improved placement of storage resources on nodes in network
US10594516B2 (en) 2017-10-02 2020-03-17 Vmware, Inc. Virtual network provider
US11115480B2 (en) 2017-10-02 2021-09-07 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10999100B2 (en) * 2017-10-02 2021-05-04 Vmware, Inc. Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider
US10419327B2 (en) 2017-10-12 2019-09-17 Big Switch Networks, Inc. Systems and methods for controlling switches to record network packets using a traffic monitoring network
US11223514B2 (en) 2017-11-09 2022-01-11 Nicira, Inc. Method and system of a dynamic high-availability mode based on current wide area network connectivity
CN108667650B (zh) * 2018-04-10 2020-10-20 北京航空航天大学 考虑业务流程特征的网络拓扑优化设计方法
CN110658415B (zh) * 2018-06-29 2022-09-16 许继集团有限公司 一种低压配电线路故障检测方法及系统
US11251245B1 (en) * 2019-01-21 2022-02-15 Xsight Labs Ltd. Responding to a failure of a main die of a switch data-plane device
US10958567B1 (en) 2019-03-29 2021-03-23 Juniper Networks, Inc. Controlling paths in a network via a centralized controller or network devices
US11121985B2 (en) 2019-08-27 2021-09-14 Vmware, Inc. Defining different public cloud virtual networks for different entities based on different sets of measurements
US11394733B2 (en) * 2019-11-12 2022-07-19 Bank Of America Corporation System for generation and implementation of resiliency controls for securing technology resources
US11290475B2 (en) 2019-11-12 2022-03-29 Bank Of America Corporation System for technology resource centric rapid resiliency modeling
US11489783B2 (en) 2019-12-12 2022-11-01 Vmware, Inc. Performing deep packet inspection in a software defined wide area network
US11418997B2 (en) 2020-01-24 2022-08-16 Vmware, Inc. Using heart beats to monitor operational state of service classes of a QoS aware network link
US11088902B1 (en) 2020-04-06 2021-08-10 Vmware, Inc. Synchronization of logical network state between global and local managers
US11088919B1 (en) 2020-04-06 2021-08-10 Vmware, Inc. Data structure for defining multi-site logical network
US11394634B2 (en) 2020-04-06 2022-07-19 Vmware, Inc. Architecture for stretching logical switches between multiple datacenters
US11683233B2 (en) 2020-04-06 2023-06-20 Vmware, Inc. Provision of logical network data from global manager to local managers
US11777793B2 (en) 2020-04-06 2023-10-03 Vmware, Inc. Location criteria for security groups
US11363124B2 (en) 2020-07-30 2022-06-14 Vmware, Inc. Zero copy socket splicing
US11757940B2 (en) 2020-09-28 2023-09-12 Vmware, Inc. Firewall rules for application connectivity
US11601356B2 (en) 2020-12-29 2023-03-07 Vmware, Inc. Emulating packet flows to assess network links for SD-WAN
US11792127B2 (en) 2021-01-18 2023-10-17 Vmware, Inc. Network-aware load balancing
US11979325B2 (en) 2021-01-28 2024-05-07 VMware LLC Dynamic SD-WAN hub cluster scaling with machine learning
US11388086B1 (en) 2021-05-03 2022-07-12 Vmware, Inc. On demand routing mesh for dynamically adjusting SD-WAN edge forwarding node roles to facilitate routing through an SD-WAN
US11729065B2 (en) 2021-05-06 2023-08-15 Vmware, Inc. Methods for application defined virtual network service among multiple transport in SD-WAN
CN113411403B (zh) * 2021-06-23 2021-12-14 北京邮电大学 一种快速数据同步方法及装置
US11943146B2 (en) 2021-10-01 2024-03-26 VMware LLC Traffic prioritization in SD-WAN
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs

Family Cites Families (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5898843A (en) 1997-10-08 1999-04-27 International Business Machines Corporation System and method for controlling device which is present in media console and system unit of a split computer system
EP1212686A4 (en) * 1999-05-26 2009-04-01 Fujitsu Ltd SYSTEM FOR MANAGING NETWORK ELEMENTS
US6865609B1 (en) 1999-08-17 2005-03-08 Sharewave, Inc. Multimedia extensions for wireless local area network
US6928484B1 (en) 2000-01-18 2005-08-09 Cisco Technology, Inc. Method and apparatus for discovering edge-disjoint shortest path pairs during shortest path tree computation
US6996065B2 (en) 2000-07-06 2006-02-07 Lucent Technologies Inc. Dynamic backup routing of network tunnel paths for local restoration in a packet network
CN1218543C (zh) 2000-10-10 2005-09-07 辐射网络公司 通信格网
US7075892B2 (en) 2000-11-03 2006-07-11 Telecommunications Research Laboratories Topological design of survivable mesh-based transport networks
US20040179471A1 (en) 2001-03-07 2004-09-16 Adisak Mekkittikul Bi-directional flow-switched ring
US20030009598A1 (en) 2001-04-12 2003-01-09 Gunluk Oktay Necip Method for designing demand-sensitive rings
US7035937B2 (en) 2001-04-25 2006-04-25 Cornell Research Foundation, Inc. Independent-tree ad hoc multicast routing
US20040105136A1 (en) 2001-05-08 2004-06-03 Corvis Corporation Interconnections and protection between optical communications networks
US6778492B2 (en) * 2002-01-17 2004-08-17 Cisco Technology, Inc. Load balancing for fast reroute backup tunnels
JP3855809B2 (ja) * 2002-03-14 2006-12-13 日本電気株式会社 経路制御方法、経路制御装置
US7046634B2 (en) 2002-04-15 2006-05-16 Tropic Networks Inc. Method and apparatus for selecting maximally disjoint shortest paths in a network
US7315517B2 (en) 2002-05-22 2008-01-01 Board Of Supervisors Of Louisiana State University And Agricultural And Mechanical College Non-blocking WDM optical networks
US20050060319A1 (en) 2002-08-02 2005-03-17 Cisco Technology, Inc. Method for central planning and distributed control of client roaming and reassociation
CA2434115A1 (en) * 2002-12-05 2004-06-05 Telecommunications Research Laboratories Method for design of networks based on p-cycles
US7366113B1 (en) 2002-12-27 2008-04-29 At & T Corp. Adaptive topology discovery in communication networks
US7283465B2 (en) * 2003-01-07 2007-10-16 Corrigent Systems Ltd. Hierarchical virtual private LAN service protection scheme
US7545735B1 (en) * 2003-03-11 2009-06-09 Atrica Israel Ltd. Scalable protection mechanism for hierarchical multicast service in ring based networks
US8018860B1 (en) 2003-03-12 2011-09-13 Sprint Communications Company L.P. Network maintenance simulator with path re-route prediction
US7451340B2 (en) * 2003-03-31 2008-11-11 Lucent Technologies Inc. Connection set-up extension for restoration path establishment in mesh networks
US7453864B2 (en) 2003-04-30 2008-11-18 Harris Corporation Predictive route maintenance in a mobile ad hoc network
US7701848B2 (en) * 2003-07-11 2010-04-20 Chunming Qiao Efficient trap avoidance and shared protection method in survivable networks with shared risk link groups and a survivable network
US6956820B2 (en) 2003-10-01 2005-10-18 Santera Systems, Inc. Methods, systems, and computer program products for voice over IP (VoIP) traffic engineering and path resilience using network-aware media gateway
US7609624B2 (en) * 2004-05-03 2009-10-27 Alcatel-Lucent Usa Inc. Method and apparatus for pre-provisioning networks to support fast restoration with minimum overbuild
US7680952B1 (en) * 2004-06-16 2010-03-16 Juniper Networks, Inc. Protecting connection traffic using filters
US8996722B2 (en) 2004-11-01 2015-03-31 Alcatel Lucent Softrouter feature server
US7616584B2 (en) 2004-11-12 2009-11-10 Cisco Technology, Inc. Minimizing single points of failure in paths with mixed protection schemes
US7440393B2 (en) 2004-12-09 2008-10-21 Scalent Systems, Inc. Method and system for managing communication in a data network
US7512063B2 (en) * 2004-12-14 2009-03-31 Cisco Technology, Inc. Border router protection with backup tunnel stitching in a computer network
KR20070095374A (ko) 2004-12-31 2007-09-28 브리티쉬 텔리커뮤니케이션즈 파블릭 리미티드 캄퍼니 비연결형 통신 트래픽을 위한 연결형 통신 방법
US20060215666A1 (en) 2005-03-23 2006-09-28 Shepherd Frederick B Methods and devices for routing traffic using randomized load balancing
US8228818B2 (en) * 2005-06-24 2012-07-24 At&T Intellectual Property Ii, Lp Systems, methods, and devices for monitoring networks
GB0519648D0 (en) 2005-09-27 2005-11-02 Roke Manor Research Resilient path protocol
WO2007044939A2 (en) 2005-10-13 2007-04-19 Opvista Incorporated Optical ring networks using circulating optical probe in protection switching with automatic reversion
WO2007057301A1 (de) 2005-11-16 2007-05-24 Nokia Siemens Networks Gmbh & Co. Kg Verfahren zum ermitteln einer schleifenfreien baumstruktur in einem datenübertragungsnetz und zugehöriges netzelement
US8364515B1 (en) 2005-12-30 2013-01-29 At&T Intellectual Property Ii, L.P. Method and system for facility location optimization
US8274989B1 (en) * 2006-03-31 2012-09-25 Rockstar Bidco, LP Point-to-multipoint (P2MP) resilience for GMPLS control of ethernet
US7808921B2 (en) * 2006-05-19 2010-10-05 The Research Foundation Of State University Of New York Bridging centrality: a concept and formula to identify bridging nodes in scale-free networks
US7746796B2 (en) 2006-09-29 2010-06-29 Cisco Technology, Inc. Directed echo requests and reverse traceroute
IL179026A (en) 2006-11-02 2011-04-28 Eci Telecom Ltd Method for finding protected path in mesh networks
US7961603B2 (en) 2006-12-14 2011-06-14 Telefonaktiebolaget L M Ericsson (Publ) Path management for enhanced protection
US8006061B1 (en) * 2007-04-13 2011-08-23 American Megatrends, Inc. Data migration between multiple tiers in a storage system using pivot tables
US8913481B2 (en) * 2007-06-30 2014-12-16 Alcatel Lucent Method and system for efficient provisioning of multiple services for multiple failure restoration in multi-layer mesh networks
US20090013091A1 (en) * 2007-07-03 2009-01-08 Microsoft Corporation Customer based message routing
US8705345B2 (en) * 2007-11-26 2014-04-22 Iowa State University Research Foundation, Inc. Network protection using network coding
US7911944B2 (en) * 2007-12-26 2011-03-22 Nortel Networks Limited Tie-breaking in shortest path determination
US8761022B2 (en) * 2007-12-26 2014-06-24 Rockstar Consortium Us Lp Tie-breaking in shortest path determination
US8045551B2 (en) 2008-02-18 2011-10-25 Ciena Corporation Systems and methods for private network-to-network interface out-of-band signaling and path blocking
US7861110B2 (en) * 2008-04-30 2010-12-28 Egenera, Inc. System, method, and adapter for creating fault-tolerant communication busses from standard components
US8175103B2 (en) 2008-06-26 2012-05-08 Rockstar Bidco, LP Dynamic networking of virtual machines
US8873960B2 (en) 2008-12-30 2014-10-28 Broadcom Corporation Techniques for detecting optical faults in passive optical networks
WO2010078506A1 (en) 2008-12-31 2010-07-08 Paul Borrill Self-healing communication trees
EP2377363B1 (en) * 2009-01-15 2016-05-04 Telefonaktiebolaget LM Ericsson (publ) PROXY MOBILE IPv6 SUPPORT IN RESIDENTIAL NETWORKS
US8867507B2 (en) 2009-05-14 2014-10-21 Avaya Inc. Split-plane wireless network architecture
US8869035B2 (en) 2009-06-29 2014-10-21 International Business Machines Corporation Increasing resilience of a network service
US8351456B2 (en) 2009-06-29 2013-01-08 Qualcomm Incorporated Method and apparatus for radio filtering in a multi-radio device
US9014156B2 (en) 2009-08-25 2015-04-21 Aruba Networks, Inc. Traffic forwarding in mesh networks
US8311014B2 (en) * 2009-11-06 2012-11-13 Telefonaktiebolaget L M Ericsson (Publ) Virtual care-of address for mobile IP (internet protocol)
US8428006B2 (en) 2010-05-04 2013-04-23 Cisco Technology, Inc. Hierarchical control signaling for mobile clients in distributed wireless controller system
US8520595B2 (en) 2010-05-04 2013-08-27 Cisco Technology, Inc. Routing to the access layer to support mobility of internet protocol devices
US8675601B2 (en) 2010-05-17 2014-03-18 Cisco Technology, Inc. Guest access support for wired and wireless clients in distributed wireless controller system
US8301694B2 (en) 2010-05-20 2012-10-30 Sandisk Il Ltd. Host device and method for accessing a virtual file in a storage device by bypassing a cache in the host device
EP2586157B1 (en) 2010-06-28 2019-08-07 Telefonaktiebolaget LM Ericsson (publ) Network management
US20120096085A1 (en) 2010-10-14 2012-04-19 Province of Ontario, Canada) Communications system including instant message device control and related methods
US8446818B2 (en) * 2010-11-01 2013-05-21 Avaya Inc. Routed split multi-link trunking resiliency for wireless local area network split-plane environments
US8817593B2 (en) 2010-11-01 2014-08-26 Avaya Inc. Method and apparatus providing failover for a point to point tunnel for wireless local area network split-plane environments
US8787394B2 (en) 2011-02-01 2014-07-22 Ciena Corporation Separate ethernet forwarding and control plane systems and methods with interior gateway route reflector for a link state routing system
US8804748B2 (en) 2011-03-31 2014-08-12 Nokia Siemens Networks Ethernet Solutions Ltd. Hitless node insertion for Ethernet networks
US8717875B2 (en) 2011-04-15 2014-05-06 Alcatel Lucent Condensed core-energy-efficient architecture for WAN IP backbones
US8873398B2 (en) 2011-05-23 2014-10-28 Telefonaktiebolaget L M Ericsson (Publ) Implementing EPC in a cloud computer with openflow data plane
US20120317058A1 (en) * 2011-06-13 2012-12-13 Abhulimen Kingsley E Design of computer based risk and safety management system of complex production and multifunctional process facilities-application to fpso's
US9148223B2 (en) 2011-07-07 2015-09-29 Ciena Corporation Ethernet private local area network systems and methods
US9185027B2 (en) 2011-07-29 2015-11-10 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for resilient routing of control traffic in a split-architecture system
US8804490B2 (en) 2011-07-29 2014-08-12 Telefonaktiebolaget L M Ericsson (Publ) Controller placement for fast failover in the split architecture
US8559314B2 (en) 2011-08-11 2013-10-15 Telefonaktiebolaget L M Ericsson (Publ) Implementing OSPF in split-architecture networks
US8593958B2 (en) 2011-09-14 2013-11-26 Telefonaktiebologet L M Ericsson (Publ) Network-wide flow monitoring in split architecture networks
US8811212B2 (en) 2012-02-22 2014-08-19 Telefonaktiebolaget L M Ericsson (Publ) Controller placement for fast failover in the split architecture
US8824323B2 (en) 2012-01-10 2014-09-02 Avaya Inc. Wireless control plane failure handling in a split-plane deployment
US9391784B2 (en) * 2012-02-23 2016-07-12 Cisco Technology, Inc. Computing risk-sharing metrics in shared-media communication networks
US20130346403A1 (en) * 2012-06-25 2013-12-26 Google Inc. Signal based recommender
US9137119B2 (en) * 2013-03-07 2015-09-15 Cisco Technology, Inc. Efficient handling of multi-destination traffic in an internet protocol fabric data center

Also Published As

Publication number Publication date
CN104247344A (zh) 2014-12-24
US20140321330A1 (en) 2014-10-30
EP2817928A1 (en) 2014-12-31
US9225591B2 (en) 2015-12-29
EP2817928B1 (en) 2019-04-10
US20130215769A1 (en) 2013-08-22
US9059928B2 (en) 2015-06-16
WO2013124783A1 (en) 2013-08-29
US8811212B2 (en) 2014-08-19
CN104247344B (zh) 2018-04-24
US20150180705A1 (en) 2015-06-25

Similar Documents

Publication Publication Date Title
ES2735006T3 (es) Colocación del controlador para la falta rápida en la arquitectura dividida
KR102002189B1 (ko) 분할 아키텍처 시스템에서의 제어 트래픽의 탄력적 라우팅을 위한 방법 및 장치
US8804490B2 (en) Controller placement for fast failover in the split architecture
US8780696B2 (en) System and method of implementing lightweight not-via IP fast reroutes in a telecommunications network
US10298499B2 (en) Technique of operating a network node for load balancing
US20170237654A1 (en) Fast failover recovery in software defined networks
US20210306908A1 (en) Scalable reachability for movable destinations attached to a leaf-spine switching architecture
Sarje et al. MPLS implementation in MANET with fast re-route mechanism in multiple link failure environments