ES2807507T3

ES2807507T3 - Protocolos de control de sistema de chasis virtual

Info

Publication number: ES2807507T3
Application number: ES13795080T
Authority: ES
Inventors: Ignatius Santoso; De Silva Roberto H Jacob; Nalinakshan Kunnath; Anand Vinayagam; Chang Chung-Hua
Original assignee: Alcatel Lucent SAS
Current assignee: Alcatel Lucent SAS
Priority date: 2012-11-12
Filing date: 2013-11-06
Publication date: 2021-02-23
Anticipated expiration: 2033-11-06
Also published as: CN104919760B; WO2014074542A1; KR101691759B1; EP2918049B1; CN104919760A; EP2918049A1; JP2016501462A; KR20150067365A; JP6072278B2

Abstract

Un nodo de red (110a-110f) adaptado para ser parte de un sistema de chasis virtual (100) que tiene una pluralidad de nodos de red dispuestos de modo que la pluralidad de nodos es vista como un único nodo por nodos de red externos (112a, 112b) fuera del sistema de chasis virtual y en donde la gestión de la pluralidad de nodos es una función de cada nodo, teniendo el nodo de red una dirección de MAC local y en donde el nodo de red: está dispuesto, en una base seleccionada, para ser operable como uno de un nodo maestro y un nodo esclavo en el sistema de chasis virtual (100); está dispuesto para provocar que la dirección de MAC local del nodo de red, cuando se opera como el nodo de red maestro, se adopte como la dirección de MAC maestra para el sistema de chasis virtual (100) por cada uno de la pluralidad de nodos de red (110a-110f), y está dispuesto cuando se opera el nodo de red como un nodo esclavo en el sistema de chasis virtual para adoptar una dirección de MAC diferente de otro nodo de red diferente del sistema de chasis virtual como la dirección de MAC para el nodo de red, comprendiendo el nodo de red: a) al menos un módulo de interfaz de red, NIM, (152a) que tiene un módulo de conmutación (210a-210n) que proporciona interconexión a: una pluralidad de puertos de enlace de tejido virtuales (252) proporcionando cada uno acceso a uno diferente de los enlaces de tejido virtual, VFL, (120) que acoplan operativamente el nodo de red (110) a una pluralidad de otros nodos de red en el sistema de chasis virtual; y al menos un puerto externo (240) dispuesto para conectar el nodo de red (110) con un nodo (112) externo al sistema de chasis virtual a través de al menos uno de (i) un grupo de agregado de enlace, LAG, (116) y (ii) un grupo de agregado de enlace de chasis virtual, VC-LAG, (114) y en donde el LAG y/o el VC-LAG comprenden una pluralidad de enlaces dispuestos para comunicar información de control y de direccionamiento como VFL; en donde dicho al menos un NIM (152a) es operable para recibir, de un nodo de red adyacente en el sistema de chasis virtual, un primer mensaje de protocolo usado para descubrir la topografía del sistema de chasis virtual y en donde el primer mensaje de protocolo incluye un identificador de chasis de origen del nodo de red adyacente de la pluralidad de otros nodos de red y un contador de saltos de número entero que varía numéricamente, que cuando cero se interpreta en el nodo de red para evitar la regeneración en, o el reenvío del primer mensaje de protocolo por el nodo de red y cuando distinto de cero se interpreta en el nodo de red para provocar que el nodo de red regenere el primer mensaje de protocolo para incluir su información de nodo de red de origen para transmisión del primer mensaje de protocolo regenerado a un nodo de red adyacente; y b) un gestor de chasis virtual (400) operable para: determinar un identificador de VFL de entrada de un primer VFL que recibe el primer mensaje de protocolo; y almacenar el identificador de chasis de origen del nodo de red adyacente y el identificador de VFL de entrada en una base de datos de topologías (144) para crear y rellenar la base de datos de topologías (144) con información de topología para el sistema de chasis virtual (100).

Description

DESCRIPCIÓN

Protocolos de control de sistema de chasis virtual

Antecedentes de la invención

Campo técnico de la invención

Esta invención se refiere en general a redes de datos y en particular a un nodo de red y un método, para proporcionar redundancia topológica y resistencia entre nodos de una o más redes de datos.

Descripción de la técnica relacionada

Las redes de datos incluyen diversos dispositivos informáticos, por ejemplo, ordenadores personales, dispositivos de telefonía de IP o servidores que se comunican entre sí y/o con diversos otros elementos de red o servidores remotos conectados a la red. Por ejemplo, las redes de datos pueden comprender, sin limitación, redes Ethernet Metro o Ethernet Empresarial que soportan múltiples aplicaciones que incluyen, por ejemplo, aplicaciones voz a través de IP (VoIP), de datos y de vídeo. Tales redes en general incluyen nodos interconectaos, comúnmente conocidos como conmutadores o encaminadores, para encaminar tráfico a través de la red.

Uno de los desafíos clave al que se enfrentan las redes de datos es la necesidad de resistencia de red, es decir, la capacidad para mantener alta disponibilidad a pesar de fallos de componente eventuales, fallos de enlace o similares, que son críticos para proporcionar rendimiento de red satisfactorio. La resistencia de red puede conseguirse, en parte, a través de redundancia topológica, es decir, proporcionando nodos redundantes (y componentes redundantes en nodos) y múltiples rutas físicas entre nodos evita puntos únicos de fallo, y en parte a través de protocolos L2/L3 para aprovechar la redundancia tras las ocurrencias de fallos para converger en rutas alternativas para conmutar/encaminar flujos de tráfico a través de la red. Como se apreciará, los tiempos de detección y convergencia deben tener lugar rápidamente (ventajosamente, en menos de un segundo) en redes para conseguir transición sin interrupciones a las rutas alternativas. Se implementan diversos tipos de topologías de red en una red para proporcionar redundancia entre elementos de red, tales como redes en anillo, redes de malla parcial, redes de malla completa, redes de concentrador, etc. Los tiempos de convergencia y redundancia entre elementos de red a menudo varían dependiendo del tipo de tipología de red implementada en una red.

Las arquitecturas de elementos de red también varían y afectan la resistencia de red. Por ejemplo, diversas arquitecturas de nodo incluyen elementos de conmutación únicos, elementos de conmutación apilables, elementos de red basados en chasis de múltiples ranuras, etc. En general, dependiendo de las necesidades de coste y red, se selecciona e implementa uno de estos tipos de arquitecturas de nodo en uno de los tipos de topologías de red. Sin embargo, una vez implementado, en ocasiones es difícil actualizar o transitar de un tipo de topología de red a otro tipo de topología de red.

También es difícil transitar de un tipo de arquitectura de nodo a otro tipo de arquitectura de nodo en una topología de red o incorporar diversos tipos de arquitecturas de nodo en una red.

Por consiguiente, existe una necesidad para que los sistemas y métodos proporcionen resistencia entre nodos que tienen uno o más diferentes tipos de arquitecturas de nodo en uno o más diferentes tipos de topologías de red.

El documento US2012039335 desvela un chasis apilado que comprende múltiples conmutadores/encaminadores físicos y que no tiene hardware de apilamiento especial o canales de apilamiento. Un LAG de apilamiento se instala entre puertos de conmutación de extremo frontal en el chasis apilado. Los controladores de chasis negocian un maestro, que controla la operación de todos los chasis en la pila. Se usa un esquema de numeración de puerto a nivel de chasis apilado para distribuir información a todas las tarjetas de línea en el sistema. Cada tarjeta de línea procesa la información para destilar información significativa de chasis físico para la operación de ese chasis en la pila.

Breve descripción de las diversas vistas de los dibujos

Las Figuras 1a-c ilustran diagramas esquemáticos de bloques de las realizaciones de un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 2 ilustra un diagrama de flujo lógico de una realización de un proceso de descubrimiento de topología de red en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 3 ilustra un diagrama de bloques esquemático de una realización de base de datos de topologías en un nodo de red en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 4 ilustra un diagrama de bloques esquemático de una realización de nodos de red en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 5 ilustra un diagrama de bloques esquemático de unas realizaciones de un módulo de interfaz de red de un nodo de red en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 6 ilustra un diagrama de bloques esquemático de una realización de un encabezado antepuesto de un paquete en el sistema de chasis virtual de acuerdo con la presente invención;

La Figura 7 ilustra un diagrama de bloques esquemático de una realización de flujo de paquetes a través de un nodo de red en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 8 ilustra un diagrama de bloques esquemático de una realización de una aplicación de gestor de chasis virtual de acuerdo con la presente invención;

La Figura 9 ilustra un diagrama de bloques esquemático de una realización de un módulo gestor de configuración de acuerdo con la presente invención;

La Figura 10 ilustra un diagrama de flujo lógico de una realización de un método para determinar un modo de operación de un nodo de red en un sistema de chasis virtual de acuerdo con la presente invención.

La Figura 11 ilustra un diagrama de flujo lógico de una realización de un método para configurar un nodo de red en arranque en modo de chasis virtual de acuerdo con la presente invención;

La Figura 12 ilustra un diagrama de bloques esquemático de una realización de descubrimiento de topología en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 13 ilustra un diagrama de flujo lógico de una realización de un método para selección de un nodo de red maestro en un sistema de chasis virtual de acuerdo con la presente invención;

Las Figuras 14a-b ilustran un diagrama de bloques esquemático de una realización de tráfico de unidifusión de encaminamiento en un sistema de chasis virtual de acuerdo con la presente invención;

Las Figuras 15a-b ilustran un diagrama de bloques esquemático de una realización de encaminamiento de tráfico no de unidifusión en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 16 ilustra un diagrama de flujo lógico de una realización de un método para encaminar tráfico no de unidifusión en un sistema de chasis virtual de acuerdo con la presente invención;

La Figura 17 ilustra un diagrama de bloques esquemático de uno de una unión de sistema de chasis virtual de acuerdo con la presente invención;

La Figura 18 ilustra un diagrama de flujo lógico de una realización de un método para una unión de sistema de chasis virtual de acuerdo con la presente invención;

La Figura 19 ilustra un diagrama de bloques esquemático de una realización de monitorización de la condición en un sistema de chasis virtual de acuerdo con la presente invención; y

La Figura 20 ilustra un diagrama de flujo lógico de una realización de un método para monitorización de la condición en un sistema de chasis virtual de acuerdo con la presente invención.

Descripción detallada de la invención

Se hace referencia a las siguientes normas en esta solicitud: 1) el Protocolo de Control de Agregación de Enlace (LACP) que era anteriormente el artículo 43 de la norma IEEE 802.3 añadida en marzo de 2000 por el grupo de trabajo del IEEE 802.3ad y está actualmente incorporado en el IEEE 802.1AX-2008 el 3 de noviembre de 2008; y 2) norma IEEE. 802.1Q, Redes de Área Local Puenteadas Virtuales, edición de 2003.

La Figura 1a ilustra una realización de un sistema de chasis virtual 100 que incluye una pluralidad de nodos de red 110 operativamente acoplados por grupos de agregados de enlace especializado para comunicar información de control y direccionamiento denominados enlaces de tejido virtual (VFL) 120. Los VFL 120 y su operación se describen en más detalle en la Solicitud de Patente de Estados Unidos con N.° de Serie 13/010.168 (número de solicitud de patente US 2012-0033665), titulada, "SYSTEM AND METHOD FOR MULTI-CHASSIS LINK AGGREGATION" presentada el 20 de enero de 2011. Los VFL 120 proporcionan conexiones entre los nodos de red 110 para intercambio de información relacionada con reenvío de tráfico, direccionamiento de MAC, flujos de multidifusión, tablas de protocolo de resolución de dirección (ARP), protocolos de control de capa 2 (por ejemplo, árbol de expansión, protección de anillo de Ethernet, protocolo de detección de enlace lógico), protocolos de encaminamiento (por ejemplo RIP, OSPF, BGP) y el estado de los nodos de red y enlaces externos.

En una realización, la pluralidad de nodos de red 110 opera como un único nodo de red virtual con capacidades de gestión unificadas. Se selecciona un nodo de red maestro, por ejemplo el nodo de red 110a, y la dirección de MAC local del nodo de red maestro 110 se adopta como la dirección de m Ac maestra para el sistema de chasis virtual 100 por los otros nodos de red 110. La dirección de MAC maestra se utiliza por nodos externos 112 para tratar los nodos de red 110 en el sistema de chasis virtual 100. Como tal, los nodos de red 110 operan de manera transparente para los nodos externos 112 y se tratan como un único dispositivo lógico por los nodos externos 112.

Los nodos externos 112 son operables para acoplarse a uno o más nodos de red 110 en el sistema de chasis virtual 100 usando un enlace troncal único o enlace, un grupo de agregado de enlace (LAG) 116 o grupos de agregado de enlace de chasis virtual (VC-LAG) 114. Para proporcionar resistencia aumentada y eliminar un único punto o incluso dos puntos de fallo, VC-LAG 114 es operable para acoplar un nodo externo a dos o más nodos de red 110 en el sistema de chasis virtual 100. El nodo externo puede usar técnicas de equilibrio de carga para distribuir tráfico a través de los enlaces disponibles de VC-LAG 114. Por ejemplo, se selecciona uno de los enlaces físicos del VC-LAG 114 por el nodo externo para transmitir un paquete basándose en un algoritmo de equilibrio de carga (que implica normalmente una función de troceo que opera en la información de dirección del Protocolo de Internet (IP) o Control de Acceso al Medio (MAC) de origen y de destino) para un uso más eficaz de ancho de banda.

Durante operación normal, los nodos de red 110 en el sistema de chasis virtual comparten la dirección de MAC maestra para identificación de sistema por una amplia diversidad de protocolos de capa 2 y de capa 3. Por ejemplo, el protocolo del árbol de expansión y los protocolos de LACP usan la dirección de m Ac maestra como el identificador para el sistema de chasis virtual 110. El encaminamiento de Protocolo de Internet (IP) también utiliza la dirección de MAC maestra para identificar el sistema de chasis virtual 100 a elementos de red externos en la red, por ejemplo los pares usan la dirección de MAC maestra como la dirección de destino de Ethernet para paquetes destinados al sistema de chasis virtual 100. Como tal, los nodos de red 110 en el sistema de chasis virtual 100 se observan como un único nodo lógico por los nodos de red externos 112. Además, los nodos de red 110 en un sistema de chasis virtual 100 se gestionan como un único nodo con un sistema de administración, operaciones y gestión de mantenimiento unificado.

Puesto que los nodos de red 110 en un sistema de chasis virtual 100 se tratan como un único dispositivo lógico por los nodos externos 112, los nodos externos 112 son operables para reenviar de manera activa tráfico en todos los enlaces del VC-LAG 114. Esta característica posibilita múltiple encauzamiento de los nodos externos 112 a los nodos de red 110 sin requerir protocolos de árbol de expansión entre los nodos externos y nodos de red mientras que aún facilita una detección de calidad de portadora y tiempo de convergencia para fallos de enlace ascendente de borde así como fallos de nodo de red 110. Otra ventaja del modo de reenvío activo de todos los enlace ascendente de VC-LAG 114 al sistema de chasis virtual 100 es eficacia aumentada del uso de ancho de banda de los enlaces de VC-LAG 114.

En el sistema de chasis virtual 100, se asigna a un nodo de red 110 un identificador globalmente único denominado un identificador de chasis o ID de chasis. El nodo de red 110 asigna un identificador de VFL interno (VFID) a cada uno de sus VFL configurados 120 en el sistema de chasis virtual 100. Puesto que el VFID para un VFL se utiliza para identificación interna y configuración de los VFL 120, un nodo de red 110 puede asignar el mismo o un VFID diferente a un VFL 120 según se asigna por otro nodo de red 110. Los VFL 120 proporcionan una conexión para intercambio de información entre los nodos de red 110 con respecto a reenvío de tráfico, direccionamiento de MAC, flujos de multidifusión, tablas de protocolo de resolución de dirección (ARP), protocolos de control de capa 2 (por ejemplo, árbol de expansión, protección de anillo de Ethernet, protocolo de detección de enlace lógico), protocolos de encaminamiento (por ejemplo RIP, OSPF, BGP), como se describe en más detalle en el documento US20120033665 A1, titulado, "SYSTEM AND METHOD FOR MULTI-CHASSIS LINK AGGREGATION" presentado el 20 de enero de 2011. En una realización, la sincronización de tablas de dirección de capa 2, tales como tablas de direcciones de control de acceso al medio (MAC), entre los nodos de red 110 se controla por flujos de paquetes de capa 2 a través de los VFL 120 así como mediante un mecanismo de mantenimiento de la conexión periódico mediante el cual el nodo de red 110 que tiene propiedad de una dirección de MAC dada inunda paquetes específicos que llevan tal dirección de MAC como la dirección de origen. El mecanismo de sincronización también necesita implementar el mecanismo de descarga de MAC convencional para manejar casos donde se cae un nodo de red 110 o alguno de sus componentes. Se posibilita el aprendizaje de origen de dirección de MAC a través de los VFL 120 a través de inundación de direcciones de m Ac de destino desconocidas. Durante el aprendizaje de origen, los nodos de red 110 intercambian paquetes con encabezados antepuestos a través de los VFL 120 que incluyen direcciones de MAC de origen e información de dispositivo de hardware asociado, tal como un ID de chasis de origen, identificador de interfaz de red de origen e información de identificador de puerto de origen. Los nodos de red 110 usan esta información para mantener tablas de direcciones de MAC sincronizadas con sincronización de tabla de MAC basada en mensajería mínima. Utilizando la tabla de direcciones de MAC sincronizada, los nodos de red 110 son operables para procesar y reenviar paquetes entre los nodos de red 110 en el sistema de chasis virtual 100.

La Figura 1a ilustra que los nodos de red 110 están acoplados en una topología de red de malla parcial. Sin embargo, los nodos de red 110 en un sistema de chasis virtual 100 pueden estar acoplados en cualquiera de una pluralidad de tipos de topologías de red sin afectar la operación del sistema de chasis virtual 100. La Figura 1b ilustra un sistema de chasis virtual 100 con una pluralidad de nodos de red 110 configurados en una topología de red de anillo acoplada por los VFL 120. La Figura 1c ilustra un sistema de chasis virtual 100 con una pluralidad de nodos de red 110 configurados en una topología de red de tipo interconexión radial o tipo estrella. Otras topologías de red no representadas, tales como lineal, árbol, malla completa, híbrida, etc., también se soportan por el sistema de chasis virtual 100. Para soportar la pluralidad de diferentes tipos de topologías de red, los nodos de red 110 en un sistema de chasis virtual 100 son operables para realizar un proceso de descubrimiento de topología de red.

La Figura 2 ilustra un diagrama de flujo lógico de una realización de un proceso de descubrimiento de topología de red 130 en un sistema de chasis virtual 100. El proceso se realiza por los nodos activos de red 110 en el sistema de chasis virtual 100 en arranque, reinicio o en la indicación de un cambio de estado en la red o a periodos de tiempo predeterminados. En la etapa 132, un nodo de red 110 detecta que está operando en un modo de chasis virtual. Por ejemplo, uno o más parámetros del nodo de red 110 están configurados para indicar un modo de operación de chasis virtual. El nodo de red 110 detecta que los parámetros indican operación de modo de chasis virtual (por ejemplo, en lugar de modo independiente o modo de múltiples chasis). El nodo de red 110 a continuación realiza en la etapa 134 uno o más protocolos para descubrir otros nodos de red 110 en el sistema de chasis virtual 100 y para intercambiar información de topología y configuración. El nodo de red 110 usa la información para crear una base de datos de topologías del sistema de chasis virtual 100. La base de datos de topologías incluye: información de identificación para los otros nodos de red 110 (por ejemplo, dirección de MAC local, identificador de chasis), información de identificación para interfaces de red que alojan VFL activos 120 (u otros enlaces inter-conmutador activos), información de identificación para los VFL 120 y sus puertos de miembro asociados en los nodos de red 110. El nodo de red 110 por lo tanto aprende las conexiones activas entre los nodos de red 110 y la información de configuración de los otros nodos de red 110 en el sistema de chasis virtual 100. La siguiente tabla 1 es un ejemplo de una base de datos de topologías para un nodo de red 110a, en este ejemplo con, por ejemplo, el ID de chasis=1, que siguen la fase de descubrimiento. La tabla 1 incluye información a modo de ejemplo almacenada en la base de datos de topologías, aunque puede incluirse también otra información y datos no ilustrados en la base de datos de topologías. Además, la base de datos de topologías puede almacenarse en base de datos separadas o tablas o combinarse con otras tablas o bases de datos en el nodo de red 110.

TABLA 1

En la etapa 136 de la Figura 2, se selecciona un nodo de red maestro para realizar tareas de gestión y otras para el sistema de chasis virtual 100. La dirección de MAC local del nodo de red maestro se adopta a continuación por los otros nodos de red 110. La siguiente tabla 2 es un ejemplo de una base de datos de topologías para el nodo de red maestro 110 elegido con el ID de chasis=1. Como se observa en la tabla 2, el nodo de red con el ID de chasis=1 se indica como que tiene el papel maestro y los otros nodos se indican como que tienen un papel esclavo en la base de datos de topologías.

TABLA 2

continuación

La selección de un nodo de red maestro 110 está basada en una lista priorizada de parámetros que incluyen prioridad de chasis, tiempo de actividad, el ID de chasis y dirección de MAC de chasis. El parámetro de tiempo de actividad proporciona prioridad a nodos de red 110 en la operación durante periodos de tiempo más largos. El parámetro de prioridad de chasis es una prioridad configurada de usuario que define la preferencia de usuario de un nodo de red maestro 110 independientemente del ID de chasis o tiempo de actividad. El uso de diversos parámetros añade flexibilidad a la selección de un nodo de red maestro 110. El parámetro de grupo de chasis mostrado en la base de datos de topologías identifica el sistema de chasis virtual 100. Uno o más sistemas de chasis virtual 100 adicionales con diferentes identificaciones de grupo de chasis pueden ser operables también en una red. La base de datos de topologías también identifica los módulos de gestores de control activo o primario (CMM) en un nodo de red 110 y el tipo de chasis del nodo de red 110.

En la etapa 138 del proceso de descubrimiento de topología de red 130, el nodo de red 110 realiza uno o más protocolos para monitorizar el estado o estados de las conexiones y los nodos de red 110 en el sistema de chasis virtual 100. El estado actual de los nodos de red 110 se mantiene en la base de datos de topologías. Un cambio de estado detectado en un nodo de red 110 en el sistema de chasis virtual 100 puede iniciar un cambio en encaminamiento, un cambio en el nodo maestro, etc., a través de auto-descubrimiento de topología y monitorización de los nodos de red 110, el sistema de chasis virtual 100 es operable para soportar una pluralidad de diferentes tipos de topologías de red con configuración previa e intervención mínima.

La Figura 3 ilustra un ejemplo de bases de datos de topologías 144 en nodos de red 110 en un sistema de chasis virtual 100 después de la selección de un nodo de red maestro 110. En este ejemplo, se adopta el nodo de red 110a como el nodo de red maestro y los nodos de red 110b y 110c son nodos esclavos. La dirección de MAC local de nodo de red 110a (por ejemplo, dirección de MAC maestra=A) se adopta por los nodos de red 110a-c como la dirección de MAC de chasis virtual. Además, la dirección de MAC maestra (MAC=A) se adopta como la dirección de aplicación MAC para aplicaciones de gestión.

El sistema de chasis virtual 100 también es operable para incluir nodos de red 110 con uno o más diferentes tipos de arquitecturas de nodo, tales como un único módulo, apilable, o arquitecturas basadas en chasis de múltiples ranuras. La Figura 4 ilustra un diagrama de bloques esquemático de una realización de nodos de red 110 en un sistema de chasis virtual 100 con diferentes tipos de arquitecturas de nodo. En este ejemplo, el nodo de red 110a tiene una arquitectura basada en chasis de múltiples ranuras con una pluralidad de módulos de interfaz de red 152a-n. En general, las arquitecturas basadas en chasis de múltiples ranuras comparten un recinto, módulos gestores de control (CMM) 150a-b y una fuente de alimentación común con uno o más módulos de interfaz de red (NIM) 152a-n, tales como tarjetas de línea o módulos de puerto. Los módulos de interfaz de red 152n incluyen un módulo de puesta en cola 212 y módulo de conmutación 210 y se conectan por un conmutador de tejido 214 integrado en el panel de conexiones del chasis.

El nodo de red 110b en este ejemplo tiene una arquitectura de nodo apilable e incluye una pluralidad de elementos de red 140a-n acoplados por conexiones del panel de conexiones 142. Cada elemento de red 140a-n es operable como un nodo independiente e incluye su propio recinto, módulo gestor de control (CMM) 150, módulo de computación 210, módulo de puesta en cola 212 y fuente de alimentación. En algunas arquitecturas de apilamiento, un elemento de red (elemento de red 140a en este ejemplo) se designa como la unidad principal o maestra del apilamiento para fines de gestión.

El nodo de red 110c tiene una arquitectura de nodo de módulo único, tal como un único elemento apilable 140 o como alternativa, una arquitectura basada en chasis de múltiples ranuras con un único módulo de interfaz de red 152.

Los nodos de red 110a-c corresponden a uno o más de los elementos de red 110 en sistema de chasis virtual 100 en las Figuras 1a-c. Por ejemplo, el sistema de chasis virtual 100 es operable para incluir nodos de red 110 con únicamente arquitecturas de nodo basadas en chasis de múltiples ranuras o incluye nodos de red 110 con únicamente arquitecturas de nodo apilables o incluyen una combinación de nodos de red 110 con dos o más tipos de arquitecturas de nodo, tales como arquitecturas basadas en chasis de múltiples ranuras, arquitecturas de nodo apilables y arquitecturas de nodo de módulo único. Aunque no se muestra, el sistema de chasis virtual 100 puede incluir también nodos de red 110 comprendidos de otros tipos de arquitecturas de nodo y configuraciones.

El nodo de red 110a y el nodo de red 110b están operativamente acoplados por el VFL 120a. Los nodos de red 110a y 110b designan VFL 120a con un identificador de VFL interno (VFID), tal como VFID=3 para el nodo de red 110a y VFID=0 por el nodo de red 110b como se muestra en la Figura 3. El nodo de red 110a y el nodo de red 110c están operativamente acoplados por el VFL 120b. Los nodos de red 110a y 110c designan VFL 120b con un identificador de VFL interno (VFID), tal como VFID=2 para el nodo de red 110a y VFID=1 por el nodo de red 110c como se muestra en la Figura 3. Además, los nodos de red 110a-c también son operables para acoplarse por VFL adicionales 120s a uno o más otros nodos de red 110 como se muestra en las Figuras 1a-c. El VFL 120a entre los nodos de red 110a y 110b se describe a continuación como una generalización de la operación y configuración de los VFL 120 entre los diversos nodos de red 110 en un sistema de chasis virtual 100.

El VFL 120a entre el nodo de red 110a y el nodo de red 110b está operativamente acoplado a uno o más puertos de membro de VFL en uno o más módulos de conmutación 210. Para redundancia en caso de fallo de uno o más puertos, enlaces o módulos, el VFL 120a es operable para incluir una pluralidad de enlaces agregados generados usando el LACP o protocolo de agregado similar entre diferentes módulos de conmutación 210 de los nodos de red 110a y 110b. Por ejemplo, en la Figura 4, el VFL 120a incluye un primer subconjunto A de enlaces físicos entre NIM 152a del nodo de red 110a y elemento de red apilable 140a del nodo de red 110b y un segundo subconjunto B de enlaces físicos entre NIM 152b del nodo de red 110a y elemento de red apilable 140b del nodo de red 110b.

Los nodos de red 110 se asignan un único identificador de chasis en el sistema de chasis virtual 100. El ID de chasis para cada nodo de red 110 es único y global y a través del descubrimiento de topología, los nodos de red 110 tienen conocimiento del ID de chasis de sus nodos de red de pares 110 en el sistema de chasis virtual 100. Además, se generan identificadores de dispositivo de hardware o identificadores de módulo (MID) únicos para diversos componentes, tales como los módulos de conmutación 210 e interfaces de puerto en los nodos de red 110, que permiten la gestión de objetos locales y remotos. En una realización, los MID de identificadores de dispositivo de hardware para los módulos de conmutación 210 tienen significado global en el sistema de chasis virtual mientras que los MID para otros componentes, tales como módulos de puesta en cola 212, pueden tener únicamente significado local. Por ejemplo, los identificadores de dispositivo de hardware asignados a los módulos de conmutación 210 son conocidos por otros nodos de red 110 mientras que los identificadores de dispositivo de hardware para otros dispositivos están restringidos a un nodo de red local 110 y no tienen significado para otros nodos de red 110. Por ejemplo, las interfaces de puerto de un módulo de conmutación 210 se asignan a un identificador de dispositivo de hardware único global que incluye el ID de chasis, ID de módulo de conmutación e ID de interfaz de puerto. En una realización, los nodos de red 110 en el sistema de chasis virtual operan en un modo de encabezado antepuesto para intercambiar paquetes de datos y de control a través de los VFL 120.

La Figura 5 ilustra un diagrama de bloques esquemático de una realización de un módulo de interfaz de red (NIM) 152 que opera en un modo de encabezado antepuesto en más detalle. Aunque se ilustra un módulo de interfaz de red 152, un elemento de red apilable 140 o un único elemento de red de módulo es operable para realizar funciones similares para operar en un modo de encabezado antepuesto. El módulo de conmutación 210 incluye una pluralidad de puertos externos 240 que están conectados a nodos externos 112 del sistema de chasis virtual 100. Uno o más de los puertos externos 240 pueden incluir puertos de miembro para un VC-LAG 114, LAG 116, enlace troncal único u otro grupo de enlace troncal, enlace fijo, etc. Los puertos externos 240 pueden tener el mismo tipo de interfaz física, tal como puertos de cobre (CAT-5E/CAT-6), puertos de fibra multimodo (SX) o puertos de fibra monomodo (LX). En otra realización, los puertos externos 240 pueden tener uno o más tipos de interfaz física diferentes.

Los puertos externos 240 se asignan identificadores de interfaz de puerto externo (ID de puerto), por ejemplo, valores de puerto de dispositivo, tales como valores de gport y dport, asociados al módulo de conmutación 210. En una realización, el ID de chasis del nodo de red 110, el MID del módulo de conmutación 210 y el identificador de interfaz de puerto externo (ID de puerto) se usan como un identificador único global de una interfaz de puerto externo físico 240 en un nodo de red 110 en el sistema de chasis virtual 100. En otra realización, se asignan identificadores de módulo globalmente único (MID) a los módulos de conmutación 210 de los nodos de red en el sistema de chasis virtual basándose en los identificadores de chasis. Por ejemplo, los MID de conmutación 0-31 se asignan al ID de chasis=1, los MID de conmutación 32-63 se asignan al ID de chasis=2, etc. En este caso, los MID de conmutación globalmente únicos e identificadores de puerto externos (ID de puerto) se usan como un identificador único global de una interfaz de puerto externo físico 240 en un nodo de red 110 en el sistema de chasis virtual 100.

Cuando se recibe un paquete en un puerto externo 240, el módulo de conmutación 210 transfiere el paquete a una interfaz de encabezado de paquete antepuesto (PPHI) 246 que añade un encabezado antepuesto (o modifica de otra manera el encabezado de paquete) para incluir información de dispositivo de hardware (h D i) asociada a la dirección de MAC de origen y/o de destino del paquete. En una realización, el encabezado antepuesto puede incluir otra información tal como identificadores de prioridad de paquete y de equilibrio de carga. Para obtener información asociada de HDI con la dirección de MAC del paquete, el PPHI realiza un proceso de búsqueda en la tabla de reenvío de MAC/HDI 250. La tabla de reenvío de MAC/HDI 250 almacenada en la memoria de tabla de direcciones 248 incluye una lista de direcciones de MAC e información de dispositivo de hardware asociada. La información de dispositivo de hardware identifica de manera inequívoca un nodo de red 110, módulo de conmutación 210 y/o una interfaz de puerto 240 para encaminar el paquete. La información de dispositivo de hardware incluye, por ejemplo, el ID de chasis, MID de un módulo de conmutación 210 y/o ID de interfaz de puerto de un puerto 240 asociado a la dirección de MAC de destino. La tabla de reenvío de MAC/HDI 250 puede incluir una o más tablas, tal como mapa de enlace troncal de origen, tabla de mapa de bits de enlace troncal, tablas de grupo de enlace troncal, tabla de mapeo de VLAN, etc. En una realización, la tabla de reenvío de MAC/HDI 250 o partes de la misma pueden ubicarse en el módulo de puesta en cola del NIM 152 o en otro módulo también.

Basándose en la base de datos de topologías 144, se genera una tabla de configuración de encaminamiento de VFL 254 en un nodo de red 110 para determinar encaminamiento de tráfico de unidifusión. La tabla de configuración de encaminamiento de VFL 254 incluye un ID de chasis y un ID de VFL asociado (VFID). El VFID asociado al ID de chasis identifica un VFL 120 en el sistema de chasis virtual 100 para encaminar el paquete a un nodo de red 110 identificado por el ID de chasis de destino. En otra realización, cuando se asignan identificadores de módulo globalmente únicos (MID) a los módulos de conmutación 210 de los nodos de red 110 en el sistema de chasis virtual 100, la tabla de configuración de encaminamiento de VFL 254 incluye los MID globalmente únicos y un ID de VFL asociado (VFID). En una realización, la tabla de configuración de encaminamiento de VFL 254 se genera usando un algoritmo de ruta más corta, algoritmo basado en tráfico u otro tipo de algoritmo de encaminamiento. Un ejemplo de tablas de configuración de encaminamiento de VFL 254 para el sistema de chasis virtual 100 mostrado en la Figura 1a se ilustra a continuación en la tabla 3.

TABLA 3

Aunque la tabla de reenvío de MAC/HDI 250 y la tabla de encaminamiento de VFL 254 se ilustran como tablas separadas en la memoria de tabla de direcciones 248, las tablas pueden combinarse o incluirse datos de una de las tablas en la otra tabla o las tablas pueden separarse en una o más otras tablas.

En una realización, la información de dispositivo de hardware HDI en el encabezado antepuesto de un paquete incluye el VFID de salida para el puerto de VFL 252 asociado al ID de chasis de destino, como se muestra en la tabla 3. El encabezado antepuesto también incluye información de dispositivo de hardware HDI asociada al puerto de origen que recibe el paquete, tal como el ID de interfaz de puerto, MID del módulo de conmutación 210 y el ID de chasis. También se añade información adicional, tal como ID de VLAN, tipo de paquete (multidifusión, unidifusión, difusión), identificador de prioridad de paquete y de equilibrio de carga al encabezado antepuesto en una realización.

El paquete con el encabezado antepuesto se transmite a continuación al módulo de puesta en cola 212 para encaminar a través del conmutador de tejido 214. Basándose en la tabla de configuración de encaminamiento de VFL 254, el módulo de puesta en cola 212 encamina el paquete con el encabezado antepuesto al módulo de conmutación 210 conectado al VFL de salida 120.

El módulo de puesta en cola 212 incluye una memoria intermedia de paquete 260, una gestión de colas 262 para proporcionar gestión de tráfico y de memoria intermedia y una tabla de direcciones de HDI global 264. La tabla de direcciones de HDI global 264 mapea el ID de VFL de salida a las colas apropiadas en módulos de puesta en cola 212 en uno o más de los otros NIM 152. Por ejemplo, el módulo de puesta en cola 212 conmuta el paquete a una cola de salida apropiada para una o más de las interfaces de puerto de VFL 252 para transmisión a través del VFL de salida 120. En una realización, una determinación de la cola de salida que corresponde a una interfaz de puerto de VFL particular está operativamente basada en un identificador de equilibrio de carga en el encabezado antepuesto.

Aunque el módulo de conmutación 210 y el módulo de puesta en cola 212 se ilustran como circuitos integrados o módulos separados, una o más funciones o componentes de los módulos pueden incluirse en el otro módulo o combinarse en un módulo alternativo o implementarse de otra manera en uno o más circuitos integrados.

La Figura 6 ilustra un diagrama de bloques esquemático de una realización de un encabezado antepuesto de un paquete en el sistema de chasis virtual 100. El encabezado antepuesto 300 incluye campos para HDI de origen 302, HDI de destino 304, ID de VLAN 306, tipo de paquete 308, dirección de MAC de origen 310 y dirección de MAC de destino 312. En una realización, el encabezado antepuesto puede incluir también, identificador de equilibrio de carga 314 y prioridad de paquete 316. La HDI de destino 304 incluye, por ejemplo, el identificador de puerto (valor de puerto de dispositivo (dport) y/o puerto global (GPV)), MID del módulo de conmutación 210 y/o el ID de chasis del nodo de red de destino 110 asociado a la dirección de MAC de destino. La HDI de origen 302 incluye, por ejemplo, el identificador de puerto (el valor de puerto de dispositivo (dport) y/o puerto global (GPV)), MID del módulo de conmutación 210 y/o el ID de chasis del nodo de red de origen asociado a la dirección de MAC de origen. El identificador de equilibrio de carga 314 se utiliza por el módulo de puesta en cola 212 para determinar un puerto de miembro de VFL para transmisión del paquete a través del VFL de salida 120. La prioridad de paquete 316 se utiliza por el módulo de puesta en cola 212 para determinar la cola de prioridad específica.

La Figura 7 ilustra un diagrama de bloques esquemático de una realización de un flujo de paquete a través de un nodo de red 110a a otro nodo de red 110b en un sistema de chasis virtual 100. En este ejemplo, un dispositivo externo 300 del sistema de chasis virtual 100 con dirección de MAC de origen "MAC1" transmite un paquete con una dirección de MAC de destino "MAC2". El nodo de red 110a, con el ID de chasis=1 en este ejemplo, recibe el paquete en la interfaz de puerto externa 240, por ejemplo con el ID de puerto=2 en el módulo de conmutación 210n, por ejemplo con MID=31. El módulo de conmutación 210n extrae la dirección de MAC de destino MAC2 y realiza una búsqueda de tabla de direcciones en la tabla de reenvío de MAC/HDI 250 para determinar información de dispositivo de hardware (HDI) asociada a la dirección de MAC de destino MAC2. La HDI de destino puede incluir, por ejemplo, el ID de chasis de destino y el identificador de módulo de dispositivo (MID) e identificadores de puerto asociados a la dirección de MAC de destino. La HDI de destino puede incluir identificadores de uno o más otros nodos de red o módulos de hardware en una ruta al dispositivo de destino asociado a la dirección de MAC de destino. Cuando la dirección de MAC de destino está asociada a otro nodo de red, por ejemplo el ID de chasis de destino no es el ID de chasis local, el módulo de conmutación 210 determina un ID de VFL de salida asociado al ID de chasis de destino. El ID de VFL de salida puede añadirse al HDI de destino en el encabezado antepuesto. Para el ejemplo en la Figura 5, la tabla de encaminamiento de VFL 254 indica que el ID de chasis de destino=2 está asociado al VFL 120 que tiene VFID=3.

El módulo de conmutación 210n también incluye en el encabezado antepuesto información de dispositivo de hardware de origen (HDI) asociada a la interfaz de puerto externa de origen, por el ID de puerto=2. La HDI de origen puede incluir uno o más identificadores de dispositivo de hardware, tales como MID del módulo de conmutación de origen 210, identificador de puerto de origen, MID para NIM de origen 152, el ID de chasis de fuente, etc. Adicionalmente, en una realización, el encabezado antepuesto incluye un identificador de prioridad de paquete y de equilibrio de carga determinado basándose en parámetros recuperados del paquete original (dirección de MAC de origen, dirección de MAC de destino, dirección de IP de origen, dirección de iP de destino).

El paquete con encabezado antepuesto se transmite al módulo de puesta en cola 212n que a continuación determina un NIM 152 en el nodo de red 110 para transmitir el paquete basándose en la HDI de destino. Cuando la HDI de destino indica una interfaz de puerto externo local en el nodo de red (por ejemplo basándose en el MID de destino contenido en el encabezado antepuesto), el módulo de puesta en cola coloca el paquete en una cola de salida para su transmisión al correspondiente NIM 152 de la interfaz de puerto externa local. En otro ejemplo ilustrado en la Figura 5, cuando la HDI de destino indica que el paquete necesita transmitirse a través de un VFL 120 a otro nodo de red 110 en el sistema de chasis virtual 100, el módulo de puesta en cola determina desde el ID de VFL el NIM de salida 152 para transmitir el paquete. En este ejemplo, el módulo de puesta en cola determina que VFID=3 está acoplado operativamente a NlM 152a y transmite el paquete con encabezado antepuesto a través del conmutador de tejido 214 a NlM 152a. Cuando múltiples módulos de conmutación 210 están operativamente acoplados al VFL de salida 120, el tráfico a transmitirse puede distribuirse entre los múltiples módulos de conmutación 210 en un método de equilibrio de carga. Además, la selección de un puerto de miembro de VFL (cola de alta prioridad, baja prioridad, etc.) en un módulo de conmutación 210 está operativamente basada en parámetros de identificador de equilibrio de carga llevados en el encabezado antepuesto. El módulo de puesta en cola 212a en NlM 152a recibe el paquete con encabezado antepuesto y pone en cola el paquete para su transmisión a través de VFL 120 con VFID=3. El módulo de conmutación 210a a continuación transmite el paquete con encabezado antepuesto que incluye la HDI de origen y/o de destino al nodo de red 110b, el ID de chasis=2 a través del VFL 120 con VFlD=3.

En una realización, el módulo de conmutación 210a puede modificar el encabezado antepuesto antes de la transmisión a través del VFL 120. Por ejemplo, el módulo de conmutación 210a puede traducir una HDI de destino con significado local (por ejemplo, un valor gport o identificador de dispositivo de hardware local MID) a una HDI con significado global o eliminar el v FiD de salida del encabezado antepuesto.

En una realización, las tablas de reenvío de MAC/HDI 250 en los NIM 152 se rellenan y actualizan en respuesta a flujos de paquete de capa 2 a través del sistema de chasis virtual 100. Puesto que el encabezado antepuesto incluye información de dirección de MAC de origen e información de HDI de origen, los NIMS 152, por ejemplo en los módulos de conmutación específicos 210 en una realización, pueden rellenar la tabla de reenvío de MAC/HDI 250 con esta información. Operando en un modo de encabezado antepuesto para intercambiar paquetes de capa 2 con direcciones de MAC de origen y HDI de origen a través del VFL 120, los módulos de conmutación 210 pueden sincronizar las tablas de reenvío de MAC/HDI 250 entre los módulos de red 110 en un sistema de chasis virtual 100. Aunque la tabla de reenvío de MAC/HDI 250 y la tabla de encaminamiento de VFL 254 se describen como ubicadas en los módulos de conmutación 210, las tablas pueden incluirse, como alternativa o además, en el módulo de puesta en colas 212n u otro módulo del nodo de red 110. En otra realización, el CMM 150 (primario y secundario) pueden incluir también la tabla de reenvío de MAC/HDI 250 y la tabla de encaminamiento de VFL 254.

La Figura 8 ilustra un diagrama de bloques esquemático de una realización de una aplicación o módulo de gestor de chasis virtual 400 operable en los nodos de red 110 en el sistema de chasis virtual 100. En una realización de un nodo de red 110 con una arquitectura de nodo basado en chasis de múltiples ranuras, el módulo gestor de chasis virtual 400 incluye una distribución de funcionalidad entre el módulo de gestión central (CMM) 150 del nodo de red 110 (denominado VCM-CMM 402) y un módulo de procesamiento 266 en un módulo de interfaz de red designado (NIM) 152 del nodo de red (denominado VCM-NIM 404). En una arquitectura de nodo apilable, un elemento de red desinado o apilable maestro 140 opera el VCM-NIM 404. El uso de un NIM designado 152 o elemento apilable 140 evita centralizar las funciones del módulo de VCM 400 únicamente en un CMM 150. Un ejemplo de una distribución de funcionalidad del módulo gestor de chasis virtual 400 se muestra en la tabla 4.

TABLA 4

En una realización, el VCM-CMM 402 incluye una interfaz entre el módulo gestor de chasis virtual 400 y el módulo gestor de elemento y/o de red 406 así como una interfaz a otras aplicaciones 408 registradas con el módulo de VCM 400 operable en el nodo de red 110. El módulo gestor de chasis virtual 400 informa las aplicaciones registradas 408 cuándo operar en el modo de chasis virtual. Más en general, el módulo gestor de chasis virtual 400 proporciona una amplia gama de notificaciones para informar a las aplicaciones interesadas acerca del estado del sistema de chasis virtual tanto en el contexto del nodo local como otros nodos de red 110 en el sistema de chasis virtual 100. Alguna de la información de estado se acciona por la configuración de gestión, mientras que otra información de estado se activa por decisiones de tiempo de ejecución tomadas por el nodo de red individualmente o por una pluralidad de los nodos de red 110 en el sistema de chasis virtual después del intercambio, negociación y acuerdo de datos de control. El módulo gestor de chasis virtual 400 también interconecta con el módulo de Aplicación de Gestor de VLAN 410, módulo de aplicación de Protocolo del Árbol de Expansión (STP) 412, módulo de aplicación de Aprendizaje de Origen 414, módulo de aplicación de Agregación de Enlace 416 y módulo de aplicación de Gestor de Puerto 418 para los fines de solicitud de servicios de estos componentes de sistema. Por ejemplo, el VCM 400 puede solicitar al gestor de VLAN que configure un puerto de miembro de VFL como un miembro de la VLAN de control para permitir la configuración de un canal de comunicación inter-proceso entre los nodos de red 110 en el sistema de chasis virtual 100.

El VCM-NIM 404 realiza configuración de identificación de módulo (por ejemplo MID) de módulos de hardware. El VCM-NIM 404 también interconecta con la gestión de puesta en cola 262 en los módulos de puesta en cola 212 para realizar las funciones de mapeo de dispositivo/puesta en cola de hardware y funciones de evitación de bucle inter chasis. El VCM-NIM 404 también incluye funcionalidad de estado de chasis virtual para el control y gestión de los VFL 120. El Control de Enlace de Tejido Virtual gestiona y configura los VFL 120 e interconecta con el módulo de aplicación de gestor de puerto 418 para monitorizar y/o controlar el estado de los VFL 120 y sus correspondientes puertos de miembro. También rastrea y actualiza el estado de los VFL 120. El VCM-NIM 404 rastrea el estado de cada puerto de miembro de VFL usando el protocolo de LACP convencional, u otro protocolo similar, junto con el estado del enlace en la capa física. Además del protocolo de LACP, un protocolo de estado de chasis virtual realiza comprobaciones de mantenimiento de la conexión periódicas (protocolo hello) para comprobar los componentes de estado y/u operabilidad que se ejecutan en el NIM designado en ambos conmutadores de chasis virtual. Todos los paquetes de protocolo de chasis virtual deben tener asignada una prioridad alta en el sistema para evitar detección de fallo falsa/prematura puesto que una detección de fallo prematura de este tipo puede tener un efecto muy disruptivo en el sistema. Ejecutando el protocolo de estado de chasis virtual en un NIM designado primario 152, el módulo de NIM designado de respaldo puede asumir el control del procesamiento de protocolo de estado en el caso de fallo.

El VCM-CMM 402 y el VCM-NIM 404 se registran con el módulo de aplicación de gestor de puerto 418 para recibir eventos de estado de puerto y estado de enlace acerca de los puertos de miembro y enlaces de los VFL 120. En otra realización, el módulo gestor de chasis virtual 400 puede incluir un módulo de aplicación gestor de puerto para monitorizar el estado de puerto y enlace de los VFL 120. El módulo gestor de chasis virtual 400 rastrea el estado operacional de los VFL 120 y procesa eventos acerca del estado de VFL, es decir agregado creado/borrado/arriba/abajo. El módulo de aplicación gestor de puerto 418 proporciona notificaciones de estado de enlace a tanto el VCM-CMM 402 como el VCM-NIM 404.

En una realización, se implementa un protocolo de control de transporte en un sistema de chasis virtual 100 a los paquetes de protocolo de control de transporte entre NIM designados 152 o elementos de red apilables 140 de nodos de red 110. El protocolo de control de transporte es operable en los nodos de red 110 con diferentes arquitecturas de nodo. Para una arquitectura de nodo basada en chasis de múltiples ranuras, un NIM designado 152 con un módulo de procesamiento designado 266 opera el protocolo de control de transporte, por ejemplo como parte del VCM-NIM 404. En una arquitectura de nodo apilable, un elemento de red designado o apilable maestro 140 opera el protocolo de control de transporte.

El módulo de supervisor de chasis 420 proporciona una interfaz a hardware del nodo de red 110 y controla la monitorización y arranque o reinicio de los diversos módulos de aplicación, controla las recargas de software y actualizaciones de software (tales como actualizaciones de software en servicio ISSU), que proporcionan una interfaz de línea de comando (CLI) para el módulo gestor de elemento 406 y controlan el acceso a ficheros de estado o imagen del sistema del nodo de red 110. Durante el modo de chasis virtual, el módulo de supervisor de chasis 420 controla la secuencia de arranque, controla recargas de software y ISSU y proporciona una interfaz para acceder a parámetros de chasis virtual.

El módulo gestor de configuración 422 es operable para convertir la operación del nodo de red 110 de un modo de chasis virtual a un modo independiente o convertir un nodo de red 110 de un modo independiente a un modo de chasis virtual. El módulo gestor de configuración también es operable para configurar el módulo gestor de chasis virtual 400 y módulo gestor de múltiples chasis 424. La operación del módulo gestor de configuración 422 y estados de operación de un nodo de red 110 se describen en más detalle a continuación.

Los nodos de red 110 en un sistema de chasis virtual 100 pueden operar en una pluralidad de modos de operación, que incluyen modo de chasis virtual, modo independiente y modo de múltiples chasis (MCLAG). Se modifican diversos parámetros y configuraciones dependiendo del modo de operación. La tabla 5 ilustra la asignación de ID de chasis a nodos de red 110 que dependen del modo de operación.

TABLA 5

En modo independiente, un nodo de red 110 se opera como un único nodo y utiliza su dirección de MAC local configurada en lugar de una dirección de MAC de chasis virtual global. En modo de múltiples chasis, dos nodos de red están configurados como nodos virtuales cuyas tablas de reenvío de MAC y tablas de ARP están sincronizadas, pero aún operan como puentes y encaminadores separados, usando cada uno de ellos su propia dirección de MAC de chasis local, como se describe en más detalle en el documento US20120033665 A1, titulado, "SYSTEM AND METHOD FOR MULTI-CHASSIS LINK AGGREGATION" presentada el 20 de enero de 2011. En modo de chasis virtual como se describe en el presente documento, una pluralidad N de nodos de red están configurados como nodos de chasis virtuales en un sistema de chasis virtual 100. Un ID de chasis globalmente único de chasis de 1 a N se asigna a cada uno de la pluralidad de nodos de red en el sistema de chasis virtual 100.

Cuando un nodo de red 110 opera en modo independiente, los identificadores de puerto y las configuraciones permiten un formato: 0/<ranura>/<puerto>, donde el ID de chasis equivale a "cero", la ranura identifica cada Módulo de Interfaz de Red (NIM) 152 en una arquitectura de múltiples ranuras o elemento de red apilable 140 y puesto es el identificador de interfaz de cuerpo. Cuando un nodo de red 110 opera en modo de múltiples chasis, las configuraciones de puerto permiten un formato: <chasis>/<ranura>/<puerto>, donde el ID de chasis equivale a 1 o 2 y representa el ID de chasis de operación/actual/en ejecución. Cuando un nodo de red 110 opera en modo de chasis virtual, las configuraciones de puerto permiten un formato: <chasis>/<ranura>/<puerto>, donde el ID de chasis es un número en el intervalo 1, 2 ... N y representa el ID de chasis de operación/actual/en ejecución.

La Figura 9 ilustra un diagrama de bloques esquemático del módulo gestor de configuración 422 en más detalle. El módulo gestor de configuración 422 incluye diversos módulos de configuración para soportar los diferentes modos de operación de un nodo de red 110. El módulo de configuración de arranque 440 en una realización soporta modos de operación independiente y de múltiples chasis. El modo de Chasis Virtual (VC) o el módulo de configuración de modo 450 soporta modo de chasis virtual. El módulo gestor de configuración 422 lee y valida los ficheros de configuración relevantes (módulo de configuración de arranque 440 o módulo de configuración de modo de VC 450) en arranque y tiempo de ejecución que dependen del modo de operación del nodo de red.

El módulo de configuración de arranque 440 incluye un conjunto de comandos de gestión que definen recursos y especifican los parámetros de nodo de red y funciones en modo independiente o de múltiples chasis. El módulo de configuración de arranque 440 incluye el módulo de configuración de aplicación 442 y el módulo de configuración de gestor de VC 446a. El módulo de configuración de aplicación 442 se usa para controlar la configuración de diversas aplicaciones en el nodo de red 110. Por ejemplo, el módulo de configuración de aplicación 442 configura el módulo de supervisor de chasis 420, módulo de aplicación de gestor de VLAN 410, módulo de aplicación de STP 412, gestor de múltiples chasis 424, etc. El módulo de configuración de gestor de VC 446a incluye parámetros de configuración y comandos de proceso controlados por el gestor de chasis virtual 400. El módulo de configuración de gestor de VC 446a se actualiza y utiliza en el módulo de configuración de arranque 440 cuando está operando en modo independiente. Los comandos que son específicos al nodo de red local y se requieren para pasar al nodo de red a un modo de chasis virtual se incluyen en el módulo de configuración gestor de VC 446a.

Sin embargo, cuando opera en modo de chasis virtual, se actualiza y utiliza el módulo de configuración de gestor de VC 446b en módulo de configuración de modo de VC 450. Incluyendo los módulos de configuración de gestor de VC 446a y 446b en el módulo de configuración de arranque 440 y módulo de configuración de modo de VC 450, el nodo de red 110 es operable para realizar configuraciones relacionadas con chasis virtual y funciones mientras opera en modo de múltiples chasis o modo independiente o modo de chasis virtual.

El módulo de configuración de modo de VC 450 incluye un conjunto de comandos de gestión que definen recursos y especifican los parámetros de nodo de red y funciones en modo de chasis virtual. El módulo de configuración de arranque de VC 452 incluye las configuraciones de chasis virtual 458a-n de la pluralidad de nodos de red en el sistema de chasis virtual 100 mientras que el módulo de configuración de VC 460 incluye las configuraciones de chasis local.

La Figura 10 ilustra un diagrama de flujo lógico de una realización de un método 470 para determinar un modo de operación de un nodo de red 100 en un sistema de chasis virtual 100. El módulo de supervisor de chasis 420 necesita determinar el modo de operación (por ejemplo, chasis virtual, independiente o de múltiples chasis) del nodo de red 110 en arranque antes de la configuración puesto que el modo de operación determina si el módulo de supervisor de chasis 420 iniciará el gestor de múltiples chasis 424 o el gestor de chasis virtual 400. En la etapa 472, el nodo de red arranca y en la etapa 474, módulo de supervisor de chasis 420 determina si el módulo de configuración de VC 460 (vcsetup.cfg) está presente en el nodo de red 110. Cuando el módulo de configuración de VC 460 (vcsetup.cfg) no está presente, el nodo de red no está operando en el modo de chasis virtual, y el módulo gestor de configuración 422 analiza el módulo de configuración de arranque 440 (boot.cfg file) en la etapa 476 para su operación en modo independiente o de múltiples chasis. El gestor de múltiples chasis 424 se inicia a continuación para el procesamiento del módulo de configuración de arranque 440 (boot.cfg file) en la etapa 4781.

Cuando el módulo de configuración de VC 460 (vcsetup.cfg) está presente en la etapa 474, el nodo de red opera en modo de chasis virtual, y módulo de supervisor de chasis 420 inicia el gestor de chasis virtual 400. El módulo de supervisor de chasis 420 establece un parámetro denominado "modo de chasis virtual" en un fichero de memoria compartida usado por otras aplicaciones durante el proceso de arranque en la etapa 480 para indicar la operación de modo de chasis virtual. El módulo gestor de configuración 422 a continuación analiza los módulos de configuración de chasis virtuales, módulo de configuración de VC 460 (vcsetup.cfg) y módulo de configuración de arranque de VC (vcboot.cfg), e inicia el gestor de chasis virtual 400 en la etapa 482. En la etapa 484, el gestor de chasis virtual 400 confirma que el módulo de configuración de VC 460 (vcsetup.cfg) incluye configuraciones de chasis virtual válidas (por ejemplo, un ID de chasis válido). De otra manera, el gestor de chasis virtual 400 informa al módulo de supervisor de chasis 420 que ha fallado el modo de chasis virtual. El módulo de supervisor de chasis 422 a continuación desactiva las interfaces de puerto y puertos de miembro de VFL. Como tal, un nodo de red 110 que tiene un fichero de módulo de configuración de VC 460 (vcsetup.cfg) pero sus contenidos son inválidos (por ejemplo fuera de alcance del ID de chasis, fichero corrupto, editado manualmente), no se hará operacional. No se hace intento para operar el nodo de red 110 en modo independiente puesto que, en algunos escenarios, esto puede crear problemas de red debido a conflictos entre la configuración independiente y la configuración de chasis virtual de otro nodo de red 110 en el sistema de chasis virtual 100.

La Figura 11 ilustra un diagrama de flujo lógico de una realización de un método 500 para configurar un nodo de red 110 en arranque en modo de chasis virtual. En arranque de sistema, cuando se determina el nodo de red 110 para operar en modo de chasis virtual en la etapa 502 con configuraciones válidas, el gestor de chasis virtual 400 procesa comandos de configuración en el módulo de configuración de VC 460 para pasar al nodo de red 110 en el sistema de chasis virtual 100. Sin embargo, en esta fase inicial, el gestor de chasis virtual 400 no procesa los comandos de módulo de configuración de arranque de VC 452 hasta que es conocido un nodo de red maestro 110 y se crea la base de datos de topologías 144 por el nodo de red 100. La tabla 6 a continuación ilustra la configuración del nodo de red 110 en esta fase inicial. Obsérvese que aunque la tabla 6 representa únicamente dos nodos de red, se soporta cualquier número de nodos de red. El parámetro de configuración de tiempo de ejecución en la tabla 6 ilustra los módulos o conjunto de comandos procesados por los nodos de red 110 durante esta fase inicial.

TABLA 6

Después de que se elige un nodo de red maestro y se crea la base de datos de topologías en la etapa 506, tiene lugar la segunda fase de procesamiento de configuración. Durante la segunda fase, el nodo de red maestro 110 en el sistema de chasis virtual 100 realiza una unión del módulo de configuración de arranque de VC 452 en el nodo de red maestro (por ejemplo, vcboot1.cfg) y los nodos de red esclavos (por ejemplo, vcboot2.cfg) en la etapa 508. Cuando un nodo de red falla al tener el mismo conjunto de configuraciones designadas en su módulo de configuración de arranque de VC 452, a continuación el nodo de red esclavo recupera las configuraciones del nodo de red maestro y sobrescribe sus propios ficheros. El nodo de red esclavo puede a continuación necesitar reiniciar de modo que tenga efecto lugar el nuevo conjunto de parámetros. Cuando se

configuración de arranque de VC 452, el módulo de configuración de arranque de VC copiado 452 (por ejemplo, vcboot1.cfg) se procesa a continuación por los nodos de red esclavos en la etapa 510. La tabla 7 ilustra la configuración de los nodos de red durante la segunda fase.

TABLA 7

El módulo de configuración de arranque de VC 452 del nodo de red maestro (vcboot1.cfg) se ha copiado ahora al nodo de red esclavo 2. Para conservar las configuraciones del nodo de red esclavo, el nodo de red maestro analiza la configuración comandos en el módulo de configuración de arranque de VC del nodo de red esclavo (vcboot2.cfg). El análisis puede realizarse fuera de línea o mediante un gestor de elemento o gestor de red. Los comandos que entran en conflicto en el módulo de configuración de arranque de VC esclavo (vcboot2.cfg) se determinan y se graban para su análisis. El nodo de red maestro elimina los comandos que entran en conflicto y escribe los comandos que no entran en conflicto en un módulo de configuración de arranque de VC unido 452 (vcboot2'.cfg) para los nodos de red esclavos en la etapa 512.

En una etapa final, el módulo de configuración de arranque de VC unido 452 (vcboot2'.cfg) se copia a los nodos de red esclavos en el sistema de chasis virtual. El módulo de configuración de arranque de VC 452 se ejecuta a continuación por los nodos de red 110 en la etapa 514. La tabla 8 ilustra la configuración de los nodos de red 110 después de esta fase final.

TABLA 8

Como resultado, se utiliza la configuración de los nodos de red esclavos 110 excepto para comandos que entran en conflicto sin una necesidad de reiniciar cada nodo de red esclavo 110. Además, se conserva la configuración de los nodos de red esclavos 110.

Durante la configuración de un nodo de red 110 en un sistema de chasis virtual, el nodo de red 110 realiza descubrimiento vecino, por ejemplo, para crear la base de datos de topologías 144, elegir un nodo de red maestro, etc. Sin embargo, en la configuración, los identificadores de chasis y enlaces de VFL 120 entre nodos de red 110 son desconocidos. Para comunicar, se utiliza un protocolo de control de chasis virtual por los nodos de red 110 para descubrir otros nodos de red e intercambiar información para crear la base de datos de topologías 144. El protocolo de control de chasis virtual opera en una base punto a punto o de salto a salto de manera que un nodo de red 110 es operable para transmitir y recibir mensajes de protocolo antes de descubrimiento de topología. En una realización, el protocolo de control de chasis virtual incluye protocolos y funciones del protocolo de encaminamiento de Sistema Intermedio a Sistema Intermedio (IS-IS), por ejemplo definido en el RFC de Grupo de Trabajo de Red del IEEE 1142, "OSI IS-IS Intra-domain Routing Protocol", febrero de 1990 y el RFC 1195 de Grupo de Trabajo de Red del IEEE, "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", diciembre de 1990, que se incorporan en el presente documento por referencia, aunque pueden utilizarse otros protocolos o procesos de encaminamiento como una base para realizar las funciones y características del protocolo de control de chasis virtual descrito en el presente documento (por ejemplo, primer trayecto más corto abierto para redes IP, por ejemplo, definido en el RFC 2740 del Grupo de Trabajo de RED del IEEE, "OSPF for IPv6", diciembre de 1999).

En una realización, los mensajes de protocolo de control de chasis virtual se intercambian entre nodos de red que usan una dirección de destino de MAC de multidifusión asignada. Cuando un módulo de conmutación 210 de un nodo de red 110 recibe un mensaje de protocolo de control de chasis virtual con la dirección de destino de MAC de multidifusión asignada, el módulo de conmutación 210 reenvía el protocolo de mensaje de control a su módulo de procesamiento 266 para procesar del mensaje de protocolo por el VCM 400 que opera en el VCM-NIM 404 o VCM-CMM 402. En otra realización, los mensajes de protocolo de control de chasis virtual incluyen un código de operación predeterminada como parte del encabezado antepuesto 300. Cuando un módulo de conmutación 210 recibe un mensaje de protocolo de control de chasis virtual con el código de operación predeterminada en el encabezado antepuesto 300, los módulos de conmutación 210 a continuación reenvían el protocolo de mensaje de control a su módulo de procesamiento 266 para su procesamiento.

Antes del descubrimiento de topología, el protocolo de control de chasis virtual usa un proceso de punto a punto o de salto a salto para intercambiar mensajes de protocolo entre nodos de red adyacentes. Para transmitir mensajes de protocolo a nodos de red 110 que no son vecinos adyacentes, el protocolo de control de chasis virtual incluye un proceso de propagación interno basándose en un campo de contador de saltos. El campo de contador de saltos se decrementa en mensajes de protocolo en cada nodo de red 110 y ayuda a evitar bucles de paquete en el sistema de chasis virtual 100. En una realización, el protocolo de control de chasis virtual está incluido en el gestor de chasis virtual 400 que opera como parte del VCM-CMM o como parte del VCM-NIM 404 aunque el protocolo de control de chasis virtual puede ser operable también en uno o más módulos alternativos o adicionales en un nodo de red 110.

La Figura 12 ilustra un diagrama de bloques esquemático de una realización de descubrimiento de topología usando el protocolo de chasis virtual en un sistema de chasis virtual 100. Tras el arranque o configuración, cuando un primer VFL, tal como el VFL 120a se hace operacional, el nodo de red 110a comienza el descubrimiento de topología del sistema de chasis virtual 100. El módulo gestor de chasis virtual 400 (u otro protocolo de módulo que opera el chasis virtual) inicia un mensaje de protocolo 550a al módulo de conmutación 210 del NIM 152 acoplado al VFL 120a. El mensaje de protocolo 550a incluye un campo de chasis de origen 552 que incluye el ID de chasis del nodo de red de origen que origina el mensaje de protocolo y un campo de VFL de origen 554 que incluye el VFID del VFL de salida 120a para el mensaje de protocolo 550a. El mensaje de protocolo 550 también incluye un campo de contador de saltos 556. En este ejemplo, el mensaje de protocolo 550 incluye el ID de chasis de origen=1, el VFID de origen=0 y el contador de saltos=2. El mensaje de protocolo 550 puede incluir campos adicionales o alternativos con información de topología similar o adicional.

Cuando el nodo de red adyacente 110b recibe el mensaje de protocolo 550a, anexa el VFID del VFL de entrada 120a, por ejemplo VFID=1 de entrada, al mensaje de protocolo 550a y transmite el mensaje de protocolo a su gestor de chasis virtual 400, por ejemplo, el VCM 400, para procesar de acuerdo con el protocolo de control de chasis virtual. A partir del mensaje de protocolo 550a, el VCM 400 es operable para determinar que el nodo de red 110a con el ID de chasis=1 es un nodo adyacente. El VCM 400 también determina que el nodo de red 110a está acoplado al mismo por VFL 120a que tiene un identificador de VFL del VFID=1 para el nodo de red 110b y VFID=0 para el nodo de red 110a. El VCM 400 es operable para actualizar o rellenar su base de datos de topologías 144 con esta información de topología. El contador de saltos=2 del mensaje de protocolo se decrementa al contador de saltos=1. Puesto que el contador de saltos es distinto de cero, el VCM 400 del nodo de red 110b regenera el mensaje de protocolo para su transmisión al nodo de red 110c para incluir su información de nodo de red de origen. El mensaje de protocolo regenerado 550b incluye un ID de chasis de origen=2 del nodo de red de origen 110b, VFID de origen =2 del VFL de origen 120b y decrementa el contador de saltos=1.

Cuando nodo de red 110c recibe el mensaje de protocolo 550b, anexa el VFID del VFL de entrada 120b, por ejemplo VFID de entrada=3, al mensaje de protocolo 550b y transmite el mensaje de protocolo al VCM 400 para procesar de acuerdo con el protocolo de control de chasis virtual. A partir del mensaje de protocolo 550b, el VCM 400 es operable para determinar que el nodo de red 110b con el ID de chasis=2 es un nodo adyacente. El VCM 400 también determina el VFID=2 para que el nodo de red 110b acople al VFID=3 para el nodo de red 110c. El VCM 400 es operable para actualizar o rellenar su base de datos de topologías 144 con esta información de topología. El contador de saltos=1 se decrementa al contador de saltos=0. Puesto que el contador de saltos es cero, el VCM 400 que opera el protocolo de control de chasis virtual no regenera o reenvía el mensaje de protocolo.

Cuando un nodo de red 110 determina información de topología de un nodo de red adyacente 110, el nodo de red actualiza su base de datos de topologías 144 con la información de topología y reenvía la información de topología a otros nodos adyacentes conocidos acoplados mediante otros enlaces de VFL. Por ejemplo, en la Figura 12, cuando un nodo de red 110b determina que el nodo de red 110a es un nodo adyacente a través del mensaje de protocolo 550a, el nodo de red 110b genera un mensaje de protocolo 550c para conocer el nodo de red adyacente 110d. El mensaje de protocolo 550c incluye información de topología actualizada en uno o más campos de topología 558. Cuando un nodo de red 110d recibe el mensaje de topología 550c, reenvía el mensaje de topología 550c al VCM 400 para procesar de acuerdo con el protocolo de control de chasis virtual. El VCM 400 actualiza su base de datos de topologías 144 con la información de topología en el uno o más campos de topología 558, por ejemplo que el VFID=1 del ID de chasis=2 está acoplado al VFID=0 del ID de chasis=1.

En una realización, en la configuración de un sistema de chasis virtual 100, un periodo de descubrimiento predeterminado está configurado para los nodos de red 110 para intercambiar información de topología y generar respectivas bases de datos de topologías 144. Cuando el periodo de descubrimiento se agota, se selecciona un nodo de red maestro de los nodos de red conocidos 110. Otros nodos de red 110 que se descubren o se vuelven operacionales en el sistema de chasis virtual 100 después del agotamiento del periodo de descubrimiento no están incluidos en el proceso de selección de nodo de red maestro. Estos nodos de red nuevamente añadidos 110 se designan como nodos de red esclavos.

La Figura 13 ilustra un diagrama de flujo lógico de una realización de un método 580 para selección de un nodo de red maestro usando el protocolo de chasis virtual. En la etapa 582, los nodos de red 110 intercambian mensajes de protocolo para crear sus propias bases de datos de topologías durante un periodo de descubrimiento predeterminado. La selección de un nodo de red maestro comienza tras el agotamiento del periodo de descubrimiento. En una realización, el periodo de descubrimiento predeterminado comienza tras el arranque de un primer nodo de red en el sistema de chasis virtual aunque pueden implementarse otros tiempos de inicio. El periodo de descubrimiento puede variar también dependiendo de las arquitecturas de topología y nodo en el sistema de chasis virtual 100. Por ejemplo, se selecciona la longitud del periodo de descubrimiento para facilitar la precisión y selección maestra predecible sin prolongar excesivamente tiempos de arranque. Implementando un periodo de tiempo predeterminado, la selección de un nodo de red maestro no se retarda indefinidamente debido a nodos de red desconocidos o espera de otro nodo de red con una prioridad superior para conectar.

Tras la expiración del periodo de descubrimiento en la etapa 584, los nodos de red 110 que han rellenado y actualizado sus respectivas bases de datos de topologías 144 con la información de topología para el sistema de chasis virtual 100 comienzan el proceso de selección para el nodo de red maestro. El módulo gestor de chasis virtual (VCM) 400 u otro módulo que opera el protocolo de control de chasis virtual en un nodo de red 110 determina su elegibilidad para que sea el nodo de red maestro en la etapa 586. En una realización, un nodo de red 110 determina su elegibilidad determinando una clave de elección basándose en uno o más parámetros. La lista priorizada de parámetros proporciona preferencia, por ejemplo, a prioridad de chasis mayor, tiempos de actividad más largos, el ID de chasis menor y dirección de MAC de chasis menor. El uso de los parámetros priorizados añaden flexibilidad al proceso de selección. El parámetro de prioridad de chasis es una prioridad preconfigurada y define preferencia de usuario para el nodo de red maestro. El parámetro de prioridad de chasis tiene el peso más grande en el proceso de selección.

Cuando un nodo de red determina que esa clave de elección se compara de manera favorable a otra clave de elección de los nodos y es elegible como un nodo de red maestro en la etapa 588, el nodo de red 110 transmite una solicitud para selección como el nodo de red maestro en la etapa 590. En la etapa 592, el nodo de red monitoriza si se recibe otra solicitud durante un periodo de tiempo predeterminado en la etapa 592. Cuando no hay otra solicitud después del periodo de tiempo predeterminado, el nodo de red 110 transmite un mensaje de selección maestro que anuncia que es el nodo de red maestro en la etapa 596. Cuando se recibe el mensaje de selección maestro, los otros nodos de red actualizan su base de datos de topologías 144 que indica el nodo de red seleccionado como el maestro y que designa los otros nodos de red como nodos esclavos en la etapa 598.

En la etapa 592, cuando más de un nodo de red transmite una solicitud para selección como el nodo de red maestro durante el periodo de tiempo predeterminado, se compara la clave de elección del uno o más nodos que solicitan la selección como maestro. El nodo de red 110 con la clave de elección más favorable en la etapa 594 se selecciona como el nodo de red maestro y transmite el mensaje de selección maestro que anuncia que es el nodo de red maestro en la etapa 596. Este proceso de selección maestro ayuda a evitar el problema de dos o más nodos de red que asumen el papel como nodo de red maestro.

Las Figuras 14a-b ilustran un diagrama de bloques esquemático de una realización de encaminamiento de tráfico de unidifusión en un sistema de chasis virtual 100. La Figura 14a ilustra un diagrama de bloques esquemático de una topología de chasis virtual a modo de ejemplo. En una realización, el gestor de chasis virtual 400 de un nodo de red 110 que opera el protocolo de control de chasis virtual analiza información de topología en la base de datos de topologías 144 y determina una ruta más corta (por ejemplo, mínimo contador de saltos) para encaminar paquetes de unidifusión a través de los VFL 120 a los otros nodos de red 110 en el sistema de chasis virtual 100. La Figura 14b ilustra un diagrama de bloques esquemático de árboles de encaminamiento de las rutas más cortas determinadas para los nodos de red 110a-d en la topología de chasis virtual en la Figura 14a. Basándose en las rutas más cortas determinadas, el VCM 400 genera tablas de encaminamiento de VFL 254 y almacena las tablas de encaminamiento de VFL 254 en los módulos de conmutación 210 de los nodos de red 110.

En una realización, se soportan múltiples rutas más cortas (por ejemplo, menos costosas o mínimo contador de saltos) entre nodos de red, y el tráfico se distribuye entre las múltiples rutas más cortas como se ilustra por un ejemplo de tablas de configuración de encaminamiento de VFL 254 en la tabla 3 en el presente documento. En otra realización como se muestra en la Figura 14b, en el caso de múltiples rutas más cortas, el VCM 400 selecciona una de las múltiples rutas más cortas para configurar las tablas de encaminamiento de VFL 254. La selección puede basarse en una o más métricas, tales como los ID de chasis, características de enlace de VFL, patrones de tráfico, etc. Por ejemplo, el VCM 400 puede seleccionar una de la pluralidad de rutas más cortas basándose en la suma de los ID de chasis en las rutas más cortas. En otra realización, la selección de una de las rutas más cortas está basada en características de enlace de VFL, tal como tasa de datos o velocidad de enlace de los VFL 120. Los patrones de tráfico u otros métodos o procesos alternativos pueden implementarse también para seleccionar una de las rutas más cortas entre nodos de red 110 en el sistema de chasis virtual 100. Los árboles de encaminamiento en la Figura 14b son ilustraciones esquemáticas de las rutas más cortas configuradas en las tablas de encaminamiento de VFL 254. Un ejemplo de las tablas de encaminamiento de VFL 254 que corresponden a las rutas más cortas mostradas en la Figura 14b se ilustra a continuación en la Tabla 9.

TABLA 9

Las tablas de encaminamiento de VFL 254 ilustradas en la tabla 9 incluyen únicamente una ruta más corta para un ID de chasis de destino a través de una o más múltiples rutas igualmente costosas que puedan existir. En otra realización, una pluralidad de rutas más cortas pueden incluirse junto con una o más métricas para determinar una de la pluralidad de rutas para seleccionar un flujo de paquetes de unidifusión particular. Las tablas de encaminamiento de v Fl 254 en una realización incluyen los ID de módulo de destino además de, o como alternativa a, los ID de chasis. En una realización, se asignan identificadores de módulo globalmente únicos (MID) a los módulos de conmutación 210 en la pluralidad de nodos de red 110 en un sistema de chasis virtual 100. Los MID globalmente únicos de los módulos de conmutación de destino 210 se incluyen en las tablas de encaminamiento de VFL 254 (y encabezados antepuestos de paquetes) además de, o como alternativa a, los ID de chasis de destino.

Las Figuras 15a-b ilustran un diagrama de bloques esquemático de una realización de encaminamiento de tráfico no de unidifusión en un sistema de chasis virtual 100. El módulo gestor de chasis virtual (VCM) 400 de un nodo de red 110 que opera el protocolo de control de chasis virtual analiza información de topología en la base de datos de topologías 144 y determina rutas para encaminar paquetes no de unidifusión, tal como paquetes de multidifusión o difusión, a los otros nodos de red 110 a través de los VFL 120 en el sistema de chasis virtual 100. El VCM 400 encamina los paquetes no de unidifusión en un intento para evitar bucles y duplicar paquetes que se reciben en un nodo de red 110. En una realización, el VCM 400 determina la ruta para un paquete no de unidifusión basándose en las rutas más cortas de unidifusión configuradas para el nodo de red de origen del paquete no de unidifusión.

La Figura 15a ilustra un diagrama de bloques esquemático de un sistema de chasis virtual 100 con un paquete de multidifusión de entrada 600 recibido por el nodo de red 110a en una interfaz de puerto externa 240. El nodo de red 110a reenvía el paquete de multidifusión 600 al nodo de red 110b a través del VFL y genera una copia duplicada para reenviar al nodo de red 110d a través del VFL 120d. El nodo de red 110b recibe el paquete no de unidifusión 600 y lo reenvía al nodo de red 110c. Sin configuración de encaminamiento adicional, el nodo de red 110b también generaría una copia duplicada del paquete no de unidifusión 600 para reenviar al nodo de red 110d a través del VFL 120e. De manera similar, el nodo de red 110c reenviaría también una copia del paquete no de unidifusión 600 a través del VFL 120c al nodo de red 110d. Como tal, el nodo de red 110d recibiría tres copias del paquete no de unidifusión. Para evitar que se reciban tales copias múltiples de un paquete en un nodo de red, el VCM 400 bloquea ciertas rutas basándose en el nodo de red de origen o de entrada del paquete no de unidifusión 600 y las rutas más cortas configuradas para paquetes de unidifusión para el nodo de red de origen.

La Figura 15b ilustra un diagrama de bloques esquemático de una realización de un árbol de encaminamiento para encaminar un paquete no de unidifusión 600 a través del sistema de chasis virtual 100 para evitar bucles y paquetes duplicados en un nodo de red. El árbol de encaminamiento ilustra una configuración de los nodos de red 110a-d para encaminar paquetes no de unidifusión que entran en el sistema de chasis virtual 100 en nodo de red de origen o entrada 110a. El VCM 400 determina el encaminamiento de paquetes no de unidifusión basándose en el nodo de red de origen y basándose en el árbol de encaminamiento o rutas más cortas configuradas para paquetes de unidifusión para el nodo de red de origen 110. Por ejemplo, el nodo de red 110b recibe el paquete no de unidifusión 600 en VFL 120a. El nodo de red 110b determina que la información de dispositivo de hardware de origen (el ID de chasis o ID de módulo) del encabezado antepuesto del paquete no de unidifusión 600 está asociada a nodo de red 110a. El nodo de red 110b determina de las tablas de encaminamiento de VFL 254 (tal como se muestra en la tabla 9 y la Figura 15b) las rutas más cortas configuradas de sus paquetes de unidifusión para el nodo de red de origen 110a. Las tablas de encaminamiento de VFL 254 indican que las rutas más cortas para el nodo de red 110a incluyen VFID=2 del ID de chasis=2 al ID de chasis=3. Como tal, el nodo de red 110b (el ID de chasis=2) reenvía el paquete no de unidifusión al nodo de red 110c (el ID de chasis=3) a través de VFL 120b con VFID=2. El nodo de red 110b no reenvía el paquete no de unidifusión 600 a través de VFL 120e al nodo de red 110d ya que esta ruta no está incluida en las rutas más cortas configuradas para el nodo de red 110a. Como tal, los paquetes no de unidifusión se encaminan en respuesta al nodo de red de origen o entrada y las rutas más cortas para paquetes de unidifusión configuradas para el nodo de red de origen.

En una realización, para implementar este encaminamiento, se implementa filtración de salida para bloquear paquetes no de unidifusión de los VFL 120 excluidos de las rutas más cortas configuradas del nodo de red de origen. En otra realización, para implementar el encaminamiento, se implementa la filtración de entrada recibiendo nodos de red para bloquear paquetes no de unidifusión de entrada de los VFL 120 excluidos de las rutas más cortas configuradas del nodo de red de origen. Por ejemplo, el nodo de red 110d con el ID de chasis=4 bloquea el tráfico no de unidifusión con un nodo de red de origen del nodo de red 110a de VFID=1 y VFID=2. Por lo tanto, para filtración de entrada, un nodo de red bloquea paquetes no de unidifusión con un nodo de red de origen en enlaces de VFL no incluidos en la ruta más corta desde el nodo de red de origen para paquetes de unidifusión. En una realización, se implementa filtración de salida en arquitecturas de tipo basadas en chasis de múltiples ranuras mientras se implementa filtración de entrada en elementos de red de única ranura o independientes aunque son posibles otras implementaciones de filtración en diferentes tipos de nodos y módulos de interfaz de red.

La Figura 16 ilustra un diagrama de flujo lógico de una realización de un método 610 para encaminar tráfico no de unidifusión en un sistema de chasis virtual 100. En la etapa 612, un nodo de red 110 en un sistema de chasis virtual 100 recibe un paquete no de unidifusión en un VFL 120. El nodo de red de recepción 110 determina el nodo de red de origen (por ejemplo, desde el ID de chasis de origen o MID de origen) del paquete no de unidifusión del encabezado antepuesto en la etapa 614. El nodo de red de recepción accede a sus tablas de direcciones para determinar las rutas más cortas configuradas para paquetes de unidifusión para el nodo de red de origen 110 en la etapa 616. En la etapa 618, el nodo de red de recepción determina encaminamiento para el paquete no de unidifusión basándose en las rutas más cortas configuradas para paquetes de unidifusión para el nodo de red de origen. El nodo de red de recepción a continuación renvía el paquete no de unidifusión a través de uno o más VFL en las rutas más cortas para paquetes de unidifusión desde el nodo de red de recepción configurado para el nodo de red de origen.

Durante la operación, un nodo de red 110 en un sistema de chasis virtual 100 es operable para detectar y recuperar de uno o más tipos de fallos que incluyen fallo de nodo de red, fallo de interfaz de red, fallo de módulo de aplicación y fallos de VFL. En una realización, el modo de paso a través proporciona un sistema y método para que los datos de usuario y el tráfico de control fluyan a través de un nodo de red en un sistema de chasis virtual en respuesta a la detección de configuración incorrecta, inconsistencias o fallos en un nodo de red 110. El modo de paso a través ayuda a evitar fractura de topología e interrupción de servicio en un sistema de chasis virtual y se describe en más detalle con respecto al documento US20130064137 A1, titulado "SYSTEM AND METHOD FOR A PASS THRU MODE IN A VIRTuA l CHASSIS SYSTEM", presentado en el mismo día con el mismo.

Un nodo de red 110 también es operable para detectar y recuperar de diversos problemas de red, tales como unión de dos o más sistemas de chasis virtual 100. Un sistema de chasis virtual 100 está configurado con un identificador de grupo de chasis virtual. En algunos casos, es ventajoso unir dos o más sistemas de chasis virtual 100 con diferentes identificadores de grupo. Cuando se unen dos sistemas de chasis virtual 100, se selecciona un nodo de red maestro de los dos sistemas de chasis virtual como el nodo de red maestro para el sistema de chasis virtual unido. Los nodos de red en los otros sistemas de chasis virtual reconfiguran y resincronizan a las configuraciones y parámetros del nodo de red de maestro seleccionado de manera similar como se describe con respecto a la Figura 11 para unir los módulos de configuración de arranque de VC. Tal reconfiguración puede requerir el reinicio de los nodos de red 110.

La Figura 17 ilustra un diagrama de bloques esquemático de una realización de una unión de sistema de chasis virtual. Un primer sistema de chasis virtual 100a con un primer grupo de chasis virtual ID=1 se une con un segundo sistema de chasis virtual 100a con un segundo grupo de chasis virtual ID=2. Para seleccionar entre los nodos de red maestros de los dos sistemas de chasis virtual 100a y 100b, en una realización se comparan las claves de elección, por ejemplo una lista priorizada de parámetros, de los nodos de red maestros aunque pueden implementarse también otros métodos. El nodo de red maestro con una clave de elección que se compara de manera favorable se selecciona como el nodo de red maestro unido. En el ejemplo de la Figura 17, el nodo de red 110a se selecciona como el nodo de red maestro unido. El nodo de red maestro no seleccionado 110c pasa al modo esclavo y sincroniza sus configuraciones al nodo de red maestro seleccionado 110a. Además, los otros nodos de red, tal como el nodo de red 110d, en el sistema de chasis virtual con el nodo de red no seleccionado también sincroniza sus configuraciones al nodo de red maestro seleccionado 110a.

La Figura 18 ilustra un diagrama de flujo lógico de una realización de un método 620 para una unión de sistema de chasis virtual. En la etapa 622, se selecciona un nodo de red maestro para el sistema de chasis virtual unido. En una realización, se selecciona el nodo de red maestro de los nodos de red maestro existentes en los dos o más sistemas de chasis virtual de unión. Se comparan las claves de elección, por ejemplo una lista priorizada de parámetros, para seleccionar entre los nodos de red maestro existentes de red aunque pueden implementarse también otros métodos. En otra realización, se selecciona un nodo de red no maestro (tal como un nodo esclavo) como el nodo de red maestro para el sistema de chasis virtual unido. Por ejemplo, puede seleccionarse un nodo de red no maestro cuando los nodos de red maestros existentes incluyen identificadores de chasis duplicados o tiene lugar un fallo en uno o más de los nodos de red maestros existentes o un nodo de red no maestro tiene una clave de elección más favorable.

Cuando se selecciona el nodo de red maestro para el sistema de chasis virtual unido, los nodos de red maestros no seleccionados pasan al modo esclavo en la etapa 624. Los nodos de red a continuación actualizan sus bases de datos de topologías 144 con la información de topología del sistema de chasis virtual unido en la etapa 626 y configuraciones de unión al nodo de red maestro seleccionado en el sistema de chasis virtual unido en la etapa 628. Los nodos de red pueden necesitar reiniciarse o volver a arrancarse para unir configuraciones con el nodo de red maestro seleccionado como se describe adicionalmente con respecto a la Figura 11. Los nodos de red que ya se han sincronizado con el nodo de red maestro seleccionado, por ejemplo, previamente un nodo esclavo al nodo de red maestro seleccionado, pueden no realizar esta etapa. Otros procesos o métodos adicionales pueden implementare para situaciones que implican nodos de red 110 con los ID de chasis duplicados en un sistema de chasis virtual unido como se describe en más detalle con respecto a la Solicitud de Estados Unidos 13/674.352 (número de publicación US 2013-0064137), titulada, "SYSTEM AND METHOD FOR A PASS THRU MODE IN A VIRTUAL CHASSIS SYSTEM".

Además del protocolo de control de chasis virtual, un nodo de red 110 en un sistema de chasis virtual 100 puede operar protocolos de control o transporte adicionales para realizar diversas funciones. Por ejemplo, pueden implementarse protocolos de control adicionales entre módulos de aplicación en un nodo de red o entre módulos en diferentes nodos de red para facilitar las comunicaciones y datos que comparten entre las aplicaciones para monitorización de la condición u otras funciones. En una realización, se implementa un protocolo de comunicación inter-proceso (ICP) como se describe en más detalle en la Solicitud de Estados Unidos N.° 2012/0033678, titulada, "Multi-Chassis Inter-Process Communication" presentada el 20 de enero de 2011. El protocolo IPC implementado por los conmutadores agregados en un sistema de múltiples chasis descrito en la misma puede utilizarse también de manera similar por nodos de red 110 en un sistema de chasis virtual 100 para facilitar las comunicaciones y compartición de datos entre los módulos de aplicación de los nodos de red 100. En una realización, se implementa IPC para facilitar funciones de monitorización de la condición entre nodos de red 110 en un sistema de chasis virtual 100, aunque pueden implementarse también protocolos alternativos o adicionales para realizar las funciones de monitorización de la condición descritas en el presente documento. Las funciones de monitorización de la condición incluyen comprobaciones periódicas en un nodo de red y entre nodos de red 110 para asegurar que los módulos de aplicación 408-418 en un nodo de red son operacionales y que los nodos de red 110 pueden comunicar con los otros nodos de red 110 en el sistema de chasis virtual 100. La monitorización de la condición también detecta cualesquiera fallos en las conexiones virtuales entre módulos de aplicación y ayuda a evitar la detección de fallo prematuro o falso.

La Figura 19 ilustra un diagrama de bloques esquemático de una realización de monitorización de la condición en un sistema de chasis virtual 100. En una realización, la monitorización de la condición incluye el establecimiento de una o más conexiones lógicas o virtuales entre nodos de red adyacentes 110 a través de VFL 120. Las conexiones virtuales para monitorización de la condición se hacen referencia en el presente documento como conexiones críticas. Dependiendo de la topología de chasis virtual y la arquitectura de los nodos de red 110, pueden usarse diversos protocolos de control y transporte para soportar las conexiones críticas. Por ejemplo, en una realización, se usa IPC (Comunicación Inter-Proceso) a través de una conexión de protocolo de internet (tal como conexiones de Protocolo de Control de Transporte (TCP), conexiones de Protocolo de Datagrama de Usuario (UDP), etc.) para implementar las conexiones críticas entre nodos de red adyacentes 110. Por ejemplo, en una realización, los módulos de aplicación 408-418 en nodos de red 110 utilizan conexiones de IPC a través de conexiones de TCP para comunicación y para compartir datos. Como tal, el uso de las mismas conexiones de IPC a través de conexiones de TCP para monitorización de la condición proporciona una indicación que los módulos de aplicación 408-418 también pueden comunicar usando estas conexiones. Aunque se describe el IPC a través de TCP en el presente documento, pueden implementarse otros tipos de conexiones virtuales usando uno o más otros protocolos y mecanismos de control o de transporte así como para soportar la monitorización de la condición y la compartición de datos entre los módulos de aplicación 408-418.

En una realización, como se muestra en la Figura 19, se establece una o más conexiones críticas 650 entre nodos de red adyacentes 110 para monitorización de la condición. Por ejemplo, en una realización, se establecen tres conexiones críticas entre el nodo de red 110a y nodo de red adyacente 110b. Se establece una conexión crítica entre el NIM designado 152b del nodo de red 110a y el CMM primario 150a del nodo de red adyacente 110b. Se establece otra conexión crítica entre el NIM designado 152b del nodo de red 110a y el CMM secundario 150b del nodo de red adyacente 110b. Y se establece otra conexión crítica entre el NIM designado 152b del nodo de red 110a y el NIM designado 152a del nodo de red adyacente 110. La identidad del CMM primario y secundario 150 y los NIM designados 152 se determinan a través de descubrimiento de topología usando el protocolo de control de chasis virtual. Aunque no se muestra, también se establecen conexiones críticas entre el NIM designado 152a del nodo de red 110b y el NIM designado 152b, CMM primario 150a y CMM primario 150b del nodo de red 110a. Una o más otras conexiones críticas o alternativas pueden establecerse también entre los nodos de red 110.

El estado del nodo de red adyacente 110b se monitoriza por el nodo de red 110a transmitiendo mensajes de monitorización de condición periódicos, tal como mensajes de hello o mantenimiento de la conexión, a través de las conexiones críticas 510. Cuando una respuesta a un número umbral de mensajes de hello o mantenimiento de la conexión no se recibe en un periodo de tiempo predeterminado, la conexión crítica 650 se pasa a un estado de estado fallido (por ejemplo, tiempo de espera agotado). En una realización, cuando un número umbral de las conexiones críticas han fallado o tienen tiempo de espera agotado, el estado del nodo de red adyacente 110b se pasa a inactivo o no operacional. Por ejemplo, en una realización, cuando al menos una de las conexiones críticas 650a-c es operacional, el nodo de red 110b aún se considera en un estado operacional. Cuando han fallado todas las conexiones críticas, a continuación el nodo de red 110b se pasa a un estado no operacional.

En otra realización, se implementan diversa reglas que rigen las conexiones críticas 650 para determinar el estado del nodo de red adyacente 110b. Por ejemplo, cuando fallan dos conexiones críticas 650a y 650b al CMM primario 150a y CMM secundario 150b del nodo de red 110b, a continuación el nodo de red 110b se considera no operacional. Sin embargo, si fallan dos conexiones críticas 650b al CMM secundario 150b y conexión crítica 650c al NIM designado 152a, el nodo de red 110b aún se considera operacional. En otro ejemplo, cuando falla la conexión crítica 650c al NIM designado 152a del nodo de red 110b, se establece un periodo de tiempo predeterminado para esperar que un nuevo NIM designado tome el control. Si ningún NIM nuevo designado 152 se ha hecho operacional tras el agotamiento del periodo de tiempo predeterminado, a continuación se considera el nodo de red 110b no operacional.

Cuando un nodo de red 110 pasa a un estado no operacional, se cierran las conexiones críticas 650 entre el nodo de red no operacional y otros nodos de red en el sistema de chasis virtual 100. Los otros nodos de red 110 descargan las direcciones de MAC para el nodo de red no operacional de sus tablas de direcciones de MAC/HDI 250 y pasan al papel del nodo de red no operacional en la base de datos de topologías 144 a no operacional o inconsistente o descargan la información de topología para el nodo no operacional. Cuando el nodo de red no operacional tiene el papel maestro, se selecciona otro nodo de red maestro. Puesto que el protocolo de control de chasis virtual usa un protocolo de transporte diferente, puede aún ser funcional cuando se cierran (o fallan) las conexiones críticas (usando por ejemplo, IPC a través de TCP). En este caso, el nodo de red no operacional puede pasar a un modo de paso a través, especialmente si el nodo de red no operacional provoca que un chasis virtual se divida en la topología.

Cuando la monitorización de la condición determina que ha fallado un VFL 120 acoplado a un nodo de red 110, la información de topología se analiza para determinar si el VFL fallido 120 provoca una división de chasis virtual. En el caso de una división de chasis virtual, el uno o más nodos de red 110 aislados de la topología por el VFL fallido 120 se pasan a un estado no operacional y se realizan etapas similares como se ha descrito anteriormente para los nodos de red no operacionales. Cuando el VFL fallido 120 no provoca una división de chasis virtual, por ejemplo uno o más otros VFL 120 están operativamente acoplados a los nodos de red 110, la base de datos de topologías 144 se actualiza para eliminar el VFL fallido 120 y las tablas de direcciones se reconfiguran para determinar rutas a través del sistema de chasis virtual a través de los VFL operacionales restantes 120.

Cuando la monitorización de condición determina que un NIM 152 de un nodo de red 110 ha fallado, se cierran las conexiones críticas 650 con el NIM fallido 152. Las direcciones MAC asociadas con los módulos de conmutación 210 e interfaces de puerto externas 240 del NIM fallido 152 se descargan de las tablas de direcciones de MAC/HDI de los nodos de red 110 en el sistema de chasis virtual 100. Cuando el NIM fallido 152 incluye puertos de miembro de VFL a uno o más VFL 120, se analiza información de topología para determinar si los puertos de miembro de VFL fallidos provocan una división de chasis virtual. En caso afirmativo, el uno o más nodos de red 110 aislados de la topología por los puertos de miembro de VFL fallidos se pasan a un estado no operacional y se realizan etapas similares como se ha descrito anteriormente para los nodos de red no operacionales.

Cuando la monitorización de condición determina que un CMM 150 de un nodo de red 110 ha fallado, se cierran las conexiones críticas 650 con el NIM fallido 152. Cuando el CMM fallido es el primario, el CMM secundario pasará al CMM primario.

La Figura 20 ilustra un diagrama de flujo lógico de una realización de un método 700 para monitorización de la condición de un nodo de red 110 en un sistema de chasis virtual 100. En la etapa 702, se establecen una o más conexiones críticas por un nodo de red de monitorización con uno o más módulos de aplicación, módulos de control o módulos de conmutación de un nodo de red adyacente. La una o más conexiones críticas pueden establecerse a través de VFL 120 acoplados al nodo de red adyacente o a través de otros enlaces físicos que se acoplan al nodo de red adyacente. Las conexiones críticas en una realización son conexiones virtuales basándose en ICP a través de conexiones de TCP aunque pueden implementarse otros protocolos de transporte o control para establecer las conexiones críticas. En la etapa 704, el nodo de red de monitorización monitoriza el nodo de red adyacente a través de las conexiones críticas usando protocolos de monitorización de mantenimiento de la conexión, hello u otros. En una realización, se transmite un mensaje de monitorización a intervalos predeterminados a través de las conexiones críticas al nodo de red adyacente. El nodo de red de monitorización espera un periodo de tiempo predeterminado para una respuesta a los mensajes de monitorización. Cuando no se recibe respuesta, el nodo de red de monitorización transmite otro mensaje de monitorización y espera otro periodo de tiempo predeterminado. Cuando el nodo de red adyacente falla al responder a un número predeterminado de mensajes de monitorización a través de una o más conexiones críticas, el nodo de red de monitorización determina que la una o más de las conexiones críticas ha fallado en la etapa 706. En respuesta a la una o más conexiones críticas fallidas, el nodo de red de monitorización 110 determina en la etapa 708 si el nodo de red adyacente, VFL (u otro enlace físico), módulo de aplicación, módulo de control o módulo de conmutación del nodo de red adyacente ha fallado o se vuelve no operacional. En caso afirmativo, el nodo de red adyacente realiza operaciones de recuperación en la etapa 710 como se describe en el presente documento.

Los nodos de red 110 en un sistema de chasis virtual 100 se tratan como un único dispositivo lógico con una dirección de MAC de chasis virtual común. Como tal, los nodos externos 112 son operables para reenviar de manera activa tráfico en todos los enlaces de un VC-LAG 114 operativamente acoplado a dos o más nodos de red 110. Esta característica posibilita múltiple encauzamiento de los nodos externos 112 a los nodos de red 110 sin requerir protocolos de árbol de expansión entre los nodos externos y nodos de red mientras que aún facilita una detección de calidad de portadora y tiempo de convergencia para fallos de enlace ascendente de borde así como fallos de nodo de red 110. Otra ventaja del modo de reenvío activo de todos los enlace ascendente de VC-LAG 114 al sistema de chasis virtual 100 es eficacia aumentada del uso de ancho de banda de los enlaces de VC-LAG 114. El sistema de chasis virtual 100 por lo tanto proporciona una red resistente entre nodos de red que tienen uno o más diferentes tipos de arquitecturas de nodo en uno o más diferentes tipos de topologías de red.

Como puede usarse también en el presente documento, los términos y expresiones "operativamente acoplado a", "acoplado a", y/o "acoplar" incluyen acoplamiento directo entre elementos y/o acoplamiento indirecto entre elementos mediante un elemento intermedio (por ejemplo, un elemento incluye, pero sin limitación, un componente, un elemente, un circuito, y/o un módulo) donde, para acoplamiento indirecto, el elemento intermedio no modifica la información de una señal sino que puede ajustar su nivel de corriente, nivel de tensión y/o nivel de potencia. Como puede usarse adicionalmente en el presente documento, acoplamiento inferido (es decir, donde un elemento se acopla a otro elemento por inferencia) incluye acoplamiento directo e indirecto entre dos elementos de la misma manera que "acoplado a".

Como puede incluso usarse adicionalmente en el presente documento, la expresión "operable a" o "operativamente acoplado a" indica que un elemento incluye una o más de las conexiones de potencia, entrada o entradas, salida o salidas, etc., para realizar, cuando se activa, una o más de sus correspondientes funciones y puede incluir adicionalmente acoplamiento inferido a uno o más otros elementos. Como puede usarse adicionalmente en el presente documento, la expresión "asociado a", incluye acoplamiento directo y/o indirecto de elementos separados y/o incrustándose un elemento en otro elemento, o un elemento configurado para su uso con o por otro elemento. Como puede usarse en el presente documento, la expresión "se compara de manera favorable", indica que una comparación entre dos o más elementos, señales, etc., proporciona una relación deseada. Por ejemplo, cuando la relación deseada es que la señal 1 tiene una magnitud mayor que la señal 2, una comparación favorable puede conseguirse cuando la magnitud de la señal 1 es mayor que la de la señal 2 o cuando la magnitud de la señal 2 es menor que la de la señal 1.

Como puede usarse también en el presente documento, las expresiones "módulo de procesamiento", "circuito de procesamiento", y/o "unidad de procesamiento" pueden ser un único dispositivo de procesamiento o una pluralidad de dispositivos de procesamiento. Un dispositivo de procesamiento de este tipo puede ser un microprocesador, microcontrolador, procesador de señales digitales, microordenador, unidad de procesamiento central, campo de matriz de puertas programables, dispositivo de lógica programable, máquina de estado, circuitería lógica, circuitería analógica, circuitería digital, y/o cualquier dispositivo que manipula señales (analógicas y/o digitales) basándose en codificación pregrabada de la circuitería y/o instrucciones operacionales. El módulo de procesamiento, módulo, circuito de procesamiento, y/o unidad de procesamiento pueden ser, o incluir adicionalmente, memoria y/o un elemento de memoria integrado, que puede ser un dispositivo de memoria único, una pluralidad de dispositivos de memoria, y/o circuitería embebida de otro módulo de procesamiento, módulo, circuito de procesamiento y/o unidad de procesamiento. Un dispositivo de memoria de este tipo puede ser una memoria de solo lectura, memoria de acceso aleatorio, memoria volátil, memoria no volátil, memoria estática, memoria dinámica, memoria flash, memoria caché, y/o cualquier dispositivo que almacena información digital. Obsérvese que si el módulo de procesamiento, módulo, circuito de procesamiento y/o unidad de procesamiento incluye más de un dispositivo de procesamiento, el dispositivo de procesamientos puede ubicarse centralmente (por ejemplo, directamente acoplado junto mediante una estructura de bus alámbrica y/o inalámbrica) o puede ubicarse de manera distribuida (por ejemplo, informática en la nube mediante acoplamiento indirecto mediante una red de área local y/o una red de área extensa). Obsérvese además que si el módulo de procesamiento, módulo, circuito de procesamiento y/o la unidad de procesamiento implementa una o más de sus funciones mediante una máquina de estado, circuitería analógica, circuitería digital, y/o circuitería lógica, la memoria y/o elemento de memoria que almacenan las correspondientes instrucciones operacionales pueden incorporarse en, o ser externas a, la circuitería que comprende la máquina de estado, circuitería analógica, circuitería digital, y/o circuitería lógica. Aun adicionalmente obsérvese que, el elemento de memoria puede almacenar, y el módulo de procesamiento, módulo, circuito de procesamiento, y/o unidad de procesamiento ejecutan, instrucciones pregrabadas y/u operacionales que corresponden a al menos alguna de las etapas y/o funciones ilustradas en una o más de las figuras. Un dispositivo de memoria o elemento de memoria de este tipo puede estar incluido en un artículo de fabricación.

La presente invención se ha descrito anteriormente con la ayuda de las etapas de método que ilustran el rendimiento de funciones especificadas y relaciones de los mismos. Los límites y secuencia de estos bloques de creación funcionales y etapas de método se han definido arbitrariamente en el presente documento por conveniencia de descripción. Los límites y secuencias alternativos pueden definirse siempre que estén dentro del alcance de la invención reivindicada. Además, los límites de estos bloques de construcción funcionales se han definido arbitrariamente por conveniencia de descripción. Podrían definirse límites alternativos siempre que se realicen de manera apropiada las ciertas funciones significativas. De manera similar, pueden haberse definido también de manera arbitraria bloques de diagrama de flujo definidos en el presente documento para ilustrar cierta funcionalidad significativa. En la medida en que se usen, los límites y secuencia del bloque de diagrama de flujo podrían haberse definido de otra manera y aún realizar la cierta funcionalidad significativa, estando tales definiciones alternativas de tanto los bloques de construcción funcionales como de los bloques de diagrama de flujo y secuencias dentro del alcance de la invención reivindicada. Un experto en la materia reconocerá también que los bloques esquemáticos funcionales, y otros bloques ilustrativos, módulos y componentes en el presente documento, pueden implementarse como se ilustran o combinarse o separarse en componentes discretos, circuitos integrados específicos de la aplicación, procesadores que ejecutan software apropiado y similares o cualquier combinación de los mismos.

La presente invención se describe en el presente documento, al menos en parte, en términos de una o más realizaciones. Se describe una realización en el presente documento para ilustrar la presente invención, un aspecto de la misma, un concepto de la misma y/o un ejemplo de la misma. Una realización física de un aparato, un artículo de fabricación, una máquina y/o de un proceso que incorpora la presente invención puede incluir uno o más de los aspectos, características, conceptos, ejemplos, etc., descritos con referencia a una o más de las realizaciones analizadas en el presente documento.

Además, de figura a figura, las realizaciones pueden incorporar las mismas funciones o nombradas de manera similar, etapas, módulos, etc., que pueden usar los mismos o diferentes números de referencia y, como tal, las funciones, etapas, módulos, etc., pueden ser las mismas o diferentes funciones, etapas, módulos, etc., o similares.

A menos que se indique específicamente al contrario, las señales a, desde y/o entre elementos en una figura presentada en el presente documento pueden ser analógicas o digitales, de tiempo continuo o de tiempo discreto y de único extremo o diferenciales. Por ejemplo, si se muestra una ruta de señal como una ruta de único extremo, también representa una ruta de señal diferencial. De manera similar, si se muestra una ruta de señal como una ruta diferencial, también representa una ruta de señal de único extremo. Aunque se han descrito una o más arquitecturas particulares en el presente documento, otras arquitecturas pueden implementarse análogamente que usan uno o más buses de datos no expresamente mostrados, conectividad directa entre elementos, y/o acoplamiento indirecto entre otros elementos.

El término "módulo" se usa en la descripción de las diversas realizaciones de la presente invención. Un módulo incluye un módulo de procesamiento (como se ha descrito anteriormente), un bloque funcional, hardware, y/o software almacenado en memoria operable para realizar una o más funciones como se describe en el presente documento. Obsérvese que, si el módulo se implementa mediante hardware, el hardware puede operar independientemente y/o en conjunto con software y/o firmware. Cuando un módulo se implementa como software almacenado en memoria, el módulo es operable para usar un módulo de procesamiento u otro hardware para ejecutar el software almacenado en memoria en el módulo para realizar las funciones como se describe en el presente documento. Un módulo descrito en el presente documento puede incluir uno o más submódulos, cada uno de los cuales puede ser uno o más módulos, incorporarse en uno o más otros módulos o incluir uno o más otros módulos.

Aunque se han descrito expresamente combinaciones particulares de diversas funciones y características de la presente invención en el presente documento, son igualmente posibles otras combinaciones de estas características y funciones. La realización descrita en el presente documento no está limitada por los ejemplos particulares descritos y puede incluir otras combinaciones y realizaciones.

Claims

REIVINDICACIONES

1. Un nodo de red (110a-110f) adaptado para ser parte de un sistema de chasis virtual (100) que tiene una pluralidad de nodos de red dispuestos de modo que la pluralidad de nodos es vista como un único nodo por nodos de red externos (112a, 112b) fuera del sistema de chasis virtual y en donde la gestión de la pluralidad de nodos es una función de cada nodo, teniendo el nodo de red una dirección de MAC local y en donde el nodo de red:

está dispuesto, en una base seleccionada, para ser operable como uno de un nodo maestro y un nodo esclavo en el sistema de chasis virtual (100);

está dispuesto para provocar que la dirección de MAC local del nodo de red, cuando se opera como el nodo de red maestro, se adopte como la dirección de MAC maestra para el sistema de chasis virtual (100) por cada uno de la pluralidad de nodos de red (110a-110f), y

está dispuesto cuando se opera el nodo de red como un nodo esclavo en el sistema de chasis virtual para adoptar una dirección de MAC diferente de otro nodo de red diferente del sistema de chasis virtual como la dirección de MAC para el nodo de red, comprendiendo el nodo de red:

a) al menos un módulo de interfaz de red, NIM, (152a) que tiene un módulo de conmutación (210a-210n) que proporciona interconexión a:

una pluralidad de puertos de enlace de tejido virtuales (252) proporcionando cada uno acceso a uno diferente de los enlaces de tejido virtual, VFL, (120) que acoplan operativamente el nodo de red (110) a una pluralidad de otros nodos de red en el sistema de chasis virtual; y

al menos un puerto externo (240) dispuesto para conectar el nodo de red (110) con un nodo (112) externo al sistema de chasis virtual a través de al menos uno de (i) un grupo de agregado de enlace, LAG, (116) y (ii) un grupo de agregado de enlace de chasis virtual, VC-LAG, (114) y en donde el LAG y/o el VC-LAG comprenden una pluralidad de enlaces dispuestos para comunicar información de control y de direccionamiento como VFL;

en donde dicho al menos un NIM (152a) es operable para recibir, de un nodo de red adyacente en el sistema de chasis virtual, un primer mensaje de protocolo usado para descubrir la topografía del sistema de chasis virtual y en donde el primer mensaje de protocolo incluye un identificador de chasis de origen del nodo de red adyacente de la pluralidad de otros nodos de red y un contador de saltos de número entero que varía numéricamente, que cuando cero se interpreta en el nodo de red para evitar la regeneración en, o el reenvío del primer mensaje de protocolo por el nodo de red y cuando distinto de cero se interpreta en el nodo de red para provocar que el nodo de red regenere el primer mensaje de protocolo para incluir su información de nodo de red de origen para transmisión del primer mensaje de protocolo regenerado a un nodo de red adyacente; y

b) un gestor de chasis virtual (400) operable para:

determinar un identificador de VFL de entrada de un primer VFL que recibe el primer mensaje de protocolo; y

almacenar el identificador de chasis de origen del nodo de red adyacente y el identificador de VFL de entrada en una base de datos de topologías (144) para crear y rellenar la base de datos de topologías (144) con información de topología para el sistema de chasis virtual (100).

2. El nodo de red de la reivindicación 1, en donde el gestor de chasis virtual es operable adicionalmente para:

decrementar el contador de saltos en el mensaje de protocolo; y

generar un segundo mensaje de protocolo con un identificador de chasis de origen del nodo de red y el contador de saltos decrementado para su transmisión a través de un segundo VFL a otro nodo de red adyacente.

3. El nodo de red de las reivindicaciones 1 o 2, en donde el al menos un módulo de interfaz de red es operable adicionalmente para:

recibir un paquete de datos con una dirección de MAC de destino asociada alal nodo de red adyacente; determinar información de dispositivo de hardware de destino asociada alal nodo de red adyacente de una o más tablas de direcciones, en donde la una o más tablas de direcciones se generan basándose en la base de datos de topologías; y generar un paquete con un encabezado de paquete antepuesto para la transmisión a través del primer VFL al nodo adyacente,

en donde el encabezado antepuesto incluye la información de dispositivo de hardware de destino del nodo de red adyacente.

4. El nodo de red de las reivindicaciones 1, 2 o 3, en donde el gestor de chasis virtual está incluido en uno o más de: el al menos un módulo de interfaz de red y un módulo gestor de control (150) en el nodo de red.

5. El nodo de red de cualquier reivindicación anterior, en donde el gestor de chasis virtual (400), que opera un protocolo de control para el chasis virtual en un nodo de red (110), es operable adicionalmente para:

determinar la elegibilidad del nodo de red para que sea un nodo de red maestro determinando una clave de elección basándose en una lista priorizada de parámetros para el nodo de red;

cuando la clave de elección del nodo de red se compara de manera favorable a una o más claves de elección de otros nodos de red en el sistema de chasis virtual, transmitir (590) una solicitud para selección como el nodo de red maestro del sistema de chasis virtual.

6. El nodo de red de cualquier reivindicación anterior, en donde el gestor de chasis virtual (400) de cada nodo de red (110) está dispuesto para operar un protocolo de control de chasis virtual configurado para:

analizar información de topología en la base de datos de topologías (144); y

determinar una ruta más corta para encaminar paquetes de unidifusión a través de los VFL (120) a los otros nodos de red en el sistema de chasis virtual (100).

7. Un método realizado por un nodo de red de acuerdo con cualquier reivindicación anterior, comprendiendo el método:

recibir un primer mensaje de protocolo que incluye un identificador de chasis de origen de un nodo de red adyacente y un contador de saltos a través de un primer enlace de tejido virtual, VFL, operativamente acoplado entre el nodo de red y una pluralidad de otros nodos de red en el sistema de chasis virtual, dicho sistema de chasis virtual configurado para gestionar una pluralidad de nodos de red en el sistema de chasis virtual de modo que la pluralidad de nodos es vistacomo un único nodo por nodos de red externos y en donde dicho sistema de chasis virtual incluye una pluralidad de enlaces de tejido virtual, VFL, (120) operativamente acoplados entre el nodo de red (110) y una pluralidad de otros nodos de red en el sistema de chasis virtual y al menos uno de (i) un grupo de agregado de enlace, LAG, (116) y (ii) un grupo de agregado de enlace de chasis virtual, VC-LAG, (114) y conecta el nodo (110) del sistema de chasis virtual (100) con un nodo (120) externo al sistema de chasis virtual y en donde el LAG y/o el VC-LAG comprenden una pluralidad de enlaces dispuestos para comunicar información de control y direccionamiento como VFL;

determinar un identificador de VFL del primer VFL;

almacenar el identificador de chasis de origen del nodo adyacente y el identificador de VFL del VFL en una base de datos de topologías.

8. El método de la reivindicación 7, que comprende adicionalmente:

decrementar el contador de saltos en el mensaje de protocolo; y

9. El método de las reivindicaciones 7 u 8, que comprende adicionalmente:

recibir un paquete de datos con una dirección de MAC de destino asociada alal nodo de red adyacente; determinar información de dispositivo de hardware de destino asociada a la dirección de MAC de destino de una o más tablas de direcciones, en donde la una o más tablas de direcciones se generan basándose en la base de datos de topologías; y

generar un paquete con encabezado de paquete, en donde el encabezado incluye la información de dispositivo de hardware de destino del nodo de red adyacente; y

transmitir el paquete con encabezado a través del primer VFL al nodo adyacente.

10. El método de las reivindicaciones 7, 8 o 9, que comprende adicionalmente:

determinar una clave usada para una elección basándose en una lista priorizada de parámetros para el nodo de red; y

transmitir una solicitud para selección como un nodo de red maestro del sistema de chasis virtual, en donde la solicitud incluye la clave usada para una elección.