ES2662111T3

ES2662111T3 - Método y sistema para sincronizar con un vecino en un grupo de agregación de enlaces de interconexión de redes resilientes distribuidas (DRNI)

Info

Publication number: ES2662111T3
Application number: ES14727236.3T
Authority: ES
Inventors: Panagiotis Saltsidis
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2013-04-23
Filing date: 2014-04-23
Publication date: 2018-04-05
Anticipated expiration: 2034-04-23
Also published as: US20140313938A1; US20170141956A1; TR201802416T4; MX2015014762A; EP2989757A1; CN105308913B; CL2015003149A1; US20140321268A1; HK1222266A1; ES2626391T3; US20140314097A1; CA2910159A1; US9503316B2; WO2014174439A1; AU2014259017A1; MX2015014821A; PL2989759T3; US9497074B2; US20190207816A1; CN105308914B

Abstract

Un método que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces en un dispositivo de red, en el que el dispositivo de red y un dispositivo vecino de red están incluidos en un primer portal del grupo de agregación de enlaces, en el que el primer portal está acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que incluye uno o más dispositivos de red remotos, y en el que el dispositivo de red está acoplado comunicativamente al dispositivo vecino de red mediante un puerto intraportal (IPP), usando un enlace intraportal (IPL), comprendiendo el método: inicializar (3302) el dispositivo de red para operar el protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo vecino de red usando el IPL, incluyendo la inicialización configurar valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos del dispositivo de red proporcionados por un administrador del primer portal; comprobar (3304) que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP; introducir (3306) un estado expirado en el dispositivo de red, en el que el dispositivo de red lleva a cabo: la configuración de un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado; la configuración de la actividad del IPP del dispositivo vecino de red para que esté inactivo, y la configuración de un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU) tras recibir (3307) una DRCPDU antes de que expire el temporizador, incluyendo la DRCPDU información de estado del dispositivo vecino de red; determinar (3308) que la DRCPDU recibida está asociada con el primer portal; determinar (3310), si se determinó que la DRCPDU recibida está asociada con el primer portal, que la DRCPDU recibida es compatible con el dispositivo de red, comprendiendo la determinación determinar que los valores configurados administrativamente asociados con el primer portal son coherentes con el de la DRCPDU recibida; y registrar (3312), si se determinó que la DRCPDU recibida es compatible con el dispositivo de red, información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, incluyendo la información de estado del dispositivo vecino de red variables de DRCP para el IPP.

Description

5

10

15

20

25

30

35

40

45

50

55

DESCRIPCION

Método y sistema para sincronizar con un vecino en un grupo de agregación de enlaces de interconexión de redes resilientes distribuidas (DRNI)

Campo

Las realizaciones de la presente invención versan, en general, sobre la agregación de enlaces y, más en particular, versa sobre métodos y aparatos para implementar la interconexión de redes resilientes distribuidas (DRNI) para un grupo de agregación de enlaces (LAG).

Antecedentes

Según se ilustra en la Figura 1A, una agregación de enlaces es una configuración y un procedimiento de red usados para agregar múltiples enlaces entre un par de nodos 120, 122 en la red para permitir la transmisión de datos de usuario en cada uno de los enlaces que participan en un grupo 101 de agregación de enlaces (LAG) (véase, por ejemplo, el estándar 802.1AX del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE)). Agregar múltiples conexiones de red de esta forma puede aumentar caudal de procesamiento más allá de lo que puede sostener una sola conexión, y/o puede ser usado para proporcionar resiliencia en caso de fallo de uno de los enlaces. La “Interconexión de redes resilientes distribuidas” (DRNI) 102 (véase la Cláusula 8 de IEEE P802.1AX-REV™/D1.0, titulado “Draft Standard for Local and Metropolitan Area Networks - Link Aggregation”, fechado el 1 de febrero de 2013, que es incorporado por referencia en su integridad en la presente memoria, especifica extensiones a la agregación de enlaces para poder usar la agregación de enlaces en una interfaz de red incluso entre más de dos nodos, por ejemplo entre cuatro nodos K, L, M y O ilustrados en la Figura 1B.

Según se muestra en la Figura 1B, se forma un LAG entre la red 150 y la red 152. Más específicamente, se forma un LAG entre nodos o “portales” virtuales 112, 114 de LAG. El primer nodo o portal virtual 112 de LAG incluye un primer nodo (K) y un segundo nodo (L). El segundo nodo o portal virtual 114 de LAG incluye un tercer nodo (M) y un cuarto nodo (O). Estos nodos también pueden ser denominados “sistemas de portal”. Obsérvese que tanto el primer nodo o portal virtual 112 de LAG como el segundo 114 pueden incluir un solo nodo o más de dos nodos en un portal. Los nodos K y M de LAG están conectados como nodos del mismo nivel, y los nodos L y O de LAG también están conectados como nodos del mismo nivel. Según se usa en la presente solicitud, un “nodo virtual de LAG” se refiere a un portal de DRNI en la documentación del IEEE presentada anteriormente (es decir, dos o más nodos que parecen un solo nodo a sus respectivos dispositivos del mismo nivel). Además, la afirmación de que el nodo o portal virtual 112 “incluye” dos nodos K, L significa que el nodo o portal virtual 112 es emulado por los nodos K, L; esto puede ser denominado un “sistema emulado”. De modo similar, la afirmación de que el nodo o portal virtual 114 “incluye” dos nodos M, O significa que el nodo o portal virtual 114 es emulado por los nodos M, O. Obsérvese que entre los enlaces K-M y L-O también se forma el grupo 161 de agregación de enlaces.

Múltiples nodos que participan en el LAG parecen ser el mismo nodo o portal virtual con un único ID de sistema a su dispositivo asociado del mismo nivel en el LAG. El ID de sistema es usado para identificar cada nodo (por ejemplo, el nodo K, el nodo L, el nodo M y el nodo O). El ID de sistema está incluido en las unidades de datos de protocolo del control de agregación de enlaces (LACPDU) enviadas entre los nodos asociados individuales del LAG (por ejemplo, entre K y M o entre L y O). El ID de sistema puede ser generado en función de identificadores de los nodos constituyentes de un portal usando cualquier identificador individual o cualquier combinación de los mismos. Puede generarse sistemáticamente un ID de sistema común y único para el correspondiente nodo o portal virtual de LAG. Así, según se muestra en la Fig. 1B, el nodo K y el nodo L pertenecen a la misma red 150 y forman parte del mismo portal 112 de DRNI (es decir, del mismo nodo virtual de lAg), y usan un ID común de sistema de “K” para el nodo virtual emulado 112 de LAG. De modo similar, los nodos M y O de la red 152 son vistos por los nodos K y L como un solo nodo o portal virtual 114 de LAG con un ID de sistema “M”.

La Figura 1B también muestra una asignación de enlaces de DRNI de un servicio particular (véase el enlace en negrita entre K y M en la Fig. 1B). El enlace asignado es el enlace operativo entre dos nodos operativos K y M para el servicio particular, mientras que se puede proporcionar el enlace no asignado como enlace de protección entre dos nodos L y O de protección. La asignación de servicio de una interfaz puede implicar una red virtual de área local (VLAN), y un identificador para el servicio puede ser un identificador de VLAN (VID), tal como un VID de servicio (es decir, “S-VID”) (que normalmente identifica servicios en interfaces entre redes (NNI)), o un VID de cliente (es decir, “C-VID”) (que normalmente identifica servicios en interfaces entre usuario y red (UNI)). (Obsérvese que los VID troncales son indistinguibles de los S-VID, dado que tienen el mismo campo EtherType). En el ejemplo de la Fig. 1B, el servicio está asignado al enlace superior (entre los nodos superiores K, M). Así, se elige el enlace superior como el enlace “operativo” y el enlace inferior (entre los nodos L, O) es el enlace de “reserva” o enlace de “protección”. Es sumamente deseable la asignación de enlaces de servicio, es decir, el uso del mismo enlace físico para la transmisión de tramas tanto en la dirección directa como en la inversa.

Aunque la Figura 1B muestra que cada uno de los portales 112 y 114 de DRNI contiene dos nodos, los portales de DRNI no están así limitados. Cada portal puede contener de uno a tres nodos. La Figura 1C ilustra una DRNI en una realización alternativa. Con referencia a la Figura 1C, el grupo 131 de agregación de enlaces contiene el portal 142

5

10

15

20

25

30

35

40

45

50

55

60

(un dispositivo 130 de red) en un extremo, y el portal 144 (dos dispositivos 132 y 134 de red) en el otro extremo. Obsérvese también que la Figura 1C muestra una asignación de enlaces de DRNI de un servicio particular (véase el enlace en negrita entre los dispositivos 130 y 134 de red). El enlace asignado es el enlace operativo entre dos nodos operativos (los dispositivos 130 y 134 de red) para el servicio particular, mientras que se puede proporcionar el enlace no asignado como enlace de protección entre dos nodos de protección (los dispositivos 130 y 132 de red). El nodo operativo es un único nodo en esta configuración, pero puede contener conjuntos diferentes de puertos de agregación para conectar los enlaces operativos y de protección entre los portales 142 y 144.

Los proveedores de servicios utilizan diversas realizaciones de grupos de agregación de enlaces (según se ilustra en las Figuras 1A-C y en otros sistemas alternativos de DRNI) para proporcionar servicios a los usuarios finales. Cómo proporcionar servicios, en particular por medio de un sistema de DRNI, es un reto.

El documento EP 2.701.342 da a conocer un método y un sistema para implementar una interfaz y una interconexión de red resilientes. El método incluye la agregación de puertos en nodos en un grupo de agregación de enlaces distribuidos y la implementación de una interfaz de red resiliente distribuida por parte del grupo de agregación de enlaces distribuidos.

Compendio

Se da a conocer un método que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación en un dispositivo de red. El dispositivo de red y un dispositivo vecino de red están incluidos en un primer portal del grupo de agregación de enlaces, estando el primer portal acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que comprende la inclusión de uno o más dispositivos remotos de red, estando el dispositivo de red acoplado comunicativamente con el dispositivo vecino de red mediante un puerto intraportal (IPP) usando un enlace intraportal (IPL). El método comienza con la inicialización del dispositivo de red para operar un protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo vecino de red usando el IPL, incluyendo la inicialización la configuración de valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos del dispositivo vecino de red proporcionados por un administrador del primer portal. El método continúa con la comprobación por parte del dispositivo de red de que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP. El dispositivo de red introduce entonces un estado expirado en el dispositivo de red, en el que el dispositivo de red pone un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado, configura la actividad del IPP del dispositivo vecino de red para que esté inactivo, y configura un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU). El dispositivo de red recibe entonces una DRCPDU, incluyendo la DRCPDU información de estado del dispositivo vecino de red. El dispositivo de red determina entonces que la DRCPDU recibida está asociada con el primer portal, y determina que la DRCPDU recibida es compatible con el dispositivo de red, comprendiendo la determinación determinar que los valores configurados administrativamente asociados con el primer portal son coherentes con el de la DRCPDU recibida, y registra información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, incluyendo la información de estado del dispositivo vecino de red variables de DRCP para el IPP.

Se da a conocer un dispositivo de red que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces. El dispositivo de red y un dispositivo vecino de red están incluidos en un primer portal del grupo de agregación de enlaces, estando el primer portal acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que comprende la inclusión de uno o más dispositivos remotos de red, estando el dispositivo de red acoplado comunicativamente con el dispositivo vecino de red mediante un puerto intraportal (IPP) usando un enlace intraportal (IPL). El dispositivo de red comprende puertos acoplados al enlace físico o de agregación del grupo de agregación de enlaces y un procesador de red acoplado a los puertos. El procesador de red ejecuta una función de DRNI, siendo operativa la función de DRNI para inicializar el dispositivo de red para operar un protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo vecino de red usando el IPL, incluyendo la inicialización la configuración de valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos del dispositivo vecino de red proporcionados por un administrador del primer portal. La función de DRNI es operativa, además, para comprobar que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP, y para introducir un estado expirado en el dispositivo de red, en el que la función de DRNI es para configurar un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado, para configurar la actividad del IPP del dispositivo vecino de red para que esté inactivo, y para configurar un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU). La función de DRNI es operativa, además, para recibir una DRCPDU, incluyendo la DRCPDU información de estado del dispositivo vecino de red, y es operativa, además, para determinar que la DRCPDU recibida está asociada con el primer portal, determinar que la DRCPDU recibida es compatible con el dispositivo de red, siendo la determinación, además, para determinar que los valores configurados administrativamente asociados con el primer portal son coherentes con el de la DRCPDU recibida. La función de DRNI es operativa, además, para registrar información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, siendo la información de estado del dispositivo vecino de red para incluir variables de DRCP para el IPP.

Se da a conocer un soporte de almacenamiento no transitorio legible por máquina para soportar una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces. El soporte de almacenamiento tiene instrucciones almacenadas en el mismo que, cuando son ejecutadas por un procesador, hacen que el procesador lleve a cabo operaciones en un dispositivo de red. El dispositivo de red y un dispositivo vecino de red están incluidos 5 en un primer portal del grupo de agregación de enlaces, estando el primer portal acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que comprende la inclusión de uno o más dispositivos remotos de red, estando el dispositivo de red acoplado comunicativamente con el dispositivo vecino de red mediante un puerto intraportal (IPP) usando un enlace intraportal (IPL). Las operaciones comienzan con la inicialización del dispositivo de red para operar un protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo 10 vecino de red usando el IPL, incluyendo la inicialización la configuración de valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos del dispositivo vecino de red proporcionados por un administrador del primer portal. Las operaciones continúan con la comprobación, por parte del dispositivo de red, de que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP. El dispositivo de red introduce entonces un estado 15 expirado en el dispositivo de red, en el que el dispositivo de red configura un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado, configura la actividad del IPP del dispositivo vecino de red para que esté inactivo, y configura un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU). El dispositivo de red recibe entonces una DRCPDU, incluyendo la DRCPDU información de estado del dispositivo vecino de red. El dispositivo de red determina entonces 20 que la DRCPDU recibida esté asociada con el primer portal, y determina que la DRCPDU recibida sea compatible con el dispositivo de red, comprendiendo la determinación, además, determinar que los valores configurados administrativamente asociados con el primer portal sean coherentes con el de la DRCPDU recibida, y registra información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, incluyendo la información de estado del dispositivo 25 vecino de red variables de DRCP para el IPP.

Se da a conocer un programa informático que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces en un dispositivo de red. El programa informático comprende instrucciones que, cuando son ejecutadas en al menos un procesador, hacen que el al menos un procesador lleve a cabo el método expuesto anteriormente en la presente memoria.

30 Las realizaciones de la invención proporcionan maneras eficaces para que un nodo de DRCP procese información embebida en una DRCPDU recibida de un nodo vecino de DRCP. La información es procesada en etapas y se determina que la DRCPDU recibida esté asociada con el portal del nodo de DRCP y que sea compatible con el nodo antes de registrar la información de estado del nodo vecino.

Breve descripción de los dibujos

35 La invención puede ser entendida de forma óptima por referencia a la siguiente descripción y a los dibujos adjuntos, que son usados para ilustrar realizaciones de la invención. En los dibujos:

La Figura 1A es un diagrama de una realización de un grupo de agregación de enlaces entre dos dispositivos de red.

La Figura 1B es un diagrama de una realización de dos portales que conectan dos redes por medio de un grupo de agregación de enlaces.

40 La Figura 1C es un diagrama de otra realización de dos portales que conectan dos redes por medio de un grupo de agregación de enlaces.

La Figura 2 es un diagrama de una realización de una subcapa de agregación de enlaces.

La Figura 3A es un diagrama de una realización de un sistema básico de retransmisiones distribuidas.

La Figura 3B es un diagrama de una realización de un sistema emulado creado a partir de dos sistemas de portal.

45 La Figura 4 es un diagrama de una realización de dos funciones de DR de una retransmisión distribuida.

La Figura 5 es un diagrama de una estructura de datos de DRCPDU.

La Figura 6A es un diagrama de estado del protocolo de control de retransmisiones distribuidas (DRCP).

La Figura 6B es un diagrama de una realización de DRCP.

La Figura 6C es un campo de estado de topología de una estructura DRCPDU según una realización de la 50 invención.

La Figura 7 es un diagrama de flujo que ilustra relaciones entre máquinas de estado.

La Figura 8 es un diagrama de flujo que ilustra una máquina de estado para una máquina receptora.

5

10

15

20

25

30

35

40

La Figura 9 es un diagrama de flujo que ilustra una máquina de estado para transmisión periódica.

La Figura 10 es un diagrama de flujo que ilustra una máquina del sistema de portal.

La Figura 11 es un diagrama de flujo que ilustra la operación de una máquina de DRNI y de agregador.

La Figura 12 es un diagrama de flujo que ilustra el estado de máquina IPP de DRNI.

La Figura 13 es un diagrama de una realización de un dispositivo de red que implementa la DRNI.

La Figura 14 es otro diagrama de una estructura de datos de DRCPDU según una realización de la invención.

La Figura 15 es otro diagrama de flujo que ilustra relaciones entre máquinas de estado según una realización de la invención.

La Figura 16 es otro diagrama de flujo que ilustra una máquina de estado para una máquina receptora según una realización de la invención.

La Figura 17 es otro diagrama de flujo que ilustra una máquina de estado para transmisión periódica según una realización de la invención.

La Figura 18 es otro diagrama de flujo que ilustra una máquina del sistema de portal según una realización de la invención.

La Figura 19 es un diagrama de flujo que ilustra las operaciones de un nodo de DRCP tras perder la comunicación con su nodo vecino según una realización de la invención.

La Figura 20 es un diagrama de flujo que ilustra la operación de un nodo de DRCP en la coordinación con su nodo vecino tras recibir múltiples flujos de tráfico según una realización de la invención.

La Figura 21 es un diagrama de la topología de portales según una realización de la invención.

La Figura 22 es un diagrama de una máquina de estado de recepción de puertos agregadores según una realización de la invención.

La Figura 23 es un diagrama de una máquina de estado de distribución de pasarelas según una realización de la invención.

La Figura 24 es un diagrama de una máquina de estado de recepción del IPP N según una realización de la invención.

La Figura 25 es otro diagrama de una estructura de datos de DRCPDU según una realización de la invención.

La Figura 26A ilustra un TLV de una máscara de conversación para un puerto de agregación según una realización de la invención.

La Figura 26B ilustra un campo de estado de una máscara de conversación dentro de un TLV de una máscara de conversación de un puerto de agregación según una realización de la invención.

La Figura 27 ilustra la operación de un nodo de DRCP en la coordinación con su nodo vecino tras una condición de fallo en las comunicaciones según una realización de la invención.

La Figura 28 ilustra la operación de un nodo de DRCP tras un fallo en las comunicaciones según una realización de la invención.

La Figura 29 es otro campo de estado de topología de una estructura DRCPDU según una realización de la invención.

La Figura 30 ilustra una máquina de compartición de red/IPL según una realización de la invención.

La Figura 31 ilustra a método para la compartición de red/IPL en un nodo según una realización de la invención.

La Figura 32 ilustra a método de comunicación por medio de una trama que contiene una estructura DRCPDU según una realización de la invención.

La Figura 33 ilustra a método para la sincronización con un vecino en un nodo de un grupo de agregación de enlaces DRNI según una realización de la invención.

La Figura 34 ilustra a método para actualizar estados operativos de un nodo en una interconexión de redes resilientes distribuidas (DRNI) según una realización de la invención.

5

10

15

20

25

30

35

40

45

50

La Figura 35 ilustra a método para la configuración un conjunto de ID de conversación para agregador o pasarela en un nodo de DRCP en una interconexión de redes resilientes distribuidas (DRNI) según una realización de la invención.

La Figura 36 ilustra un método para la configuración un conjunto de ID de conversación para IPP en un nodo de DRCP en una interconexión de redes resilientes distribuidas (DRNI) según una realización de la invención.

Descripción detallada

En la descripción siguiente se definen numerosos detalles específicos. Sin embargo, se entiende que realizaciones de la invención pueden ser puedas en práctica sin estos detalles específicos. En otros casos, circuitos, estructuras y técnicas muy conocidos no han sido mostrados con detalle para no ofuscar la comprensión de esta descripción.

Sin embargo, un experto en la técnica apreciará que la invención puede ser puesta en práctica sin tales detalles específicos. En otros casos, no se han mostrado con detalle estructuras de control, circuitos a nivel de puertas y secuencias completas de instrucciones de soporte lógico para no ofuscar la invención. Las personas con un dominio normal de la técnica, con las descripciones incluidas, podrán implementar la funcionalidad apropiada sin experimentación indebida.

Las referencias en la memoria a “una realización, “una realización ejemplar”, etc., indican que la realización descrita puede incluir un rasgo, una estructura o una característica particular, pero cada realización puede no incluir necesariamente el rasgo, la estructura o la característica particular. Además, tales frases no se refieren necesariamente a la misma realización. Además, cuando se describe un rasgo, una estructura o una característica particular en conexión con una realización, se entiende que forma parte del conocimiento de un experto en la técnica realizar tal rasgo, estructura o característica en conexión con otras realizaciones, con independencia de que estén o no descritas explícitamente.

Términos

En la descripción pueden usarse los términos siguientes.

Actor: La entidad (es decir, el nodo o dispositivo de red) local en un intercambio del protocolo de control de agregación de enlaces (LACP).

Clave de agregación: Un parámetro asociado con cada puerto de agregación y con cada agregador de un sistema de agregación que identifica a los puertos de agregación que pueden agregarse entre sí. Los puertos de agregación en un sistema de agregación que comparten el mismo valor de la clave de agregación son potencialmente capaces de agregarse entre sí.

Puerto de agregación: Un punto de acceso al servicio (SAP) en un sistema de agregación que está soportado por un agregador.

Sistema de agregación: Una entidad identificable de forma única que comprende (entre otras cosas) una agrupación arbitraria de uno o más puertos de agregación con el propósito de la agregación. Entre dos sistemas de agregación siempre se produce un caso de enlace agregado. Un dispositivo físico puede comprender un sistema de agregación de señales o más de un sistema de agregación.

Cliente de agregación: La entidad estratificada inmediatamente por encima de la subcapa de agregación de enlaces, para la cual la subcapa de agregación de enlaces proporciona una instancia de los servicios internos de subcapa (ISS).

Conversación: Un conjunto de tramas transmitidas desde una estación terminal a otra en el que todas las tramas forman una secuencia ordenada y en el que las estaciones terminales en comunicación requieren que se mantenga la ordenación entre el conjunto de tramas intercambiadas.

ID de conversación: Un identificador que usa valores (por ejemplo, en el intervalo 0-4095) para identificar conversaciones.

Equipo terminal de datos (DTE): Cualquier fuente o destino de datos conectado a la red de área local.

Retransmisor distribuido (DR): Una entidad funcional, distribuida en un portal por una función de DR en cada uno de los sistemas de agregación que comprenden un portal, que distribuye tramas salientes de las pasarelas a los agregadores, y distribuye las tramas entrantes de los agregadores a las pasarelas.

Interconexión de redes resilientes distribuidas (DRNI): Agregación de enlaces expandida para que incluya cada uno de un portal y un sistema de agregación, o dos (o más) portales.

Función de DR: La parte de un retransmisor distribuido que reside en un sistema de un solo portal.

5

10

15

20

25

30

35

40

45

50

Pasarela: Una conexión, normalmente virtual (no un enlace físico entre sistemas) que conecta un retransmisor distribuido con un sistema, que consiste en un enlace de pasarela y dos puertos de pasarela.

ID de conversación de pasarela: El valor del ID de conversación que es usado para seleccionar tramas que pasan a través de una pasarela.

Servicio interno de subcapa (ISS): Una versión aumentada del servicio MAC, definida en el estándar 802.1AC-2012 del IEEE.

Enlace intraportal (IPL): Un enlace usado para conectar las funciones de DR que comprenden un retransmisor distribuido.

Grupo de agregación de enlaces (LAG): Un grupo de enlaces que le aparecen a un cliente agregador como si fuera un único enlace. Un grupo de agregación de enlaces puede conectar dos sistemas de agregación, un sistema de agregación y un portal, o dos portales. Puede haber asociadas una o más conversaciones con cada enlace que forme parte de un grupo de agregación de enlaces.

Socio: La entidad (es decir, el nodo o dispositivo de red) remota en un intercambio del protocolo de control de agregación de enlaces.

Identificador (ID) de conversación de puerto: Un valor identificador de conversación que es usado para seleccionar tramas que pasan a través de un puerto de agregación.

Portal: Un extremo de una DRNI que incluye uno o más sistemas de agregación, cada uno con enlaces físicos que, conjuntamente, comprenden un grupo de agregación de enlaces. Los sistemas de agregación del portal cooperan para emular la presencia de un único sistema de agregación al que está conectado todo el grupo de agregación de enlaces.

Número de sistema de portal: Un entero (por ejemplo, del 1 al 3, inclusive) que identifica de forma única un sistema de portal dentro de su portal.

Algoritmo de selección: El algoritmo usado para asignar tramas a los ID de conversación y los ID de conversación a puertos de agregación y pasarelas.

ID de servicio: Un valor extraído de la cabecera (VID, I-SID, etc.) de una trama que identifica la instancia de servicio con la que está asociada esta trama.

Instancia de servicio: Una instancia de servicio es un conjunto de puntos de acceso al servicio (SAP), tal como que una primitiva de Data.Request presentada a un SAP pueda dar como resultado que ocurra una primitiva de Data.Indication en uno o más de los otros SAP de ese conjunto. En el contexto de empresas explotadoras y clientes, la empresa explotadora da a un cliente particular acceso a todos los SAP de tal conjunto.

Tipo/longitud/valor (TLV): Una codificación corta de longitud variable de un elemento de información que consiste en campos secuenciales de tipo, longitud y valor en los que el campo tipo identifica el tipo de información, el campo longitud indica la longitud del campo de información en octetos, y el campo valor contiene la información en sí. El valor del tipo es definido localmente y es preciso que sea único dentro del protocolo definido en este estándar.

En la descripción y las reivindicaciones siguientes pueden usarse los términos “acoplado” y “conectado”, junto con sus derivados. Debería entenderse que no se pretende que estos términos sean sinónimos el uno del otro. Se usa “acoplado” para indicar que dos o más elementos pueden o no estar en contacto físico o eléctrico directo entre sí, cooperando o interactuando entre sí. Se usa “conectado” para indicar el establecimiento de una comunicación entre dos o más elementos que están acoplados entre sí. Un “conjunto”, tal como se usa el término en la presente memoria, se refiere a cualquier número entero positivo de elementos, incluyendo un elemento.

Un dispositivo electrónico (por ejemplo, una estación terminal, un dispositivo de red) almacena y transmite (internamente y/o con otros dispositivos electrónicos por una red) código (compuesto de instrucciones de soporte lógico, por ejemplo un programa informático que comprenda instrucciones) y datos usando soportes legibles por máquina, tales como soportes no transitorios legibles por máquina (por ejemplo, soportes de almacenamiento legibles por máquina, tales como discos magnéticos; discos ópticos; memoria de solo lectura; dispositivos de memoria flash; memoria de cambio de fase) y soportes transitorios de transmisión legibles por máquina (por ejemplo, señales eléctricas, ópticas, acústicas u otra forma de señales propagadas, tales como ondas portadoras o señales infrarrojas). Además, tales dispositivos electrónicos incluyen soporte físico, tal como un conjunto de uno o más procesadores acoplados a uno o más componentes adicionales; por ejemplo, uno o más soportes no transitorios de almacenamiento legibles por máquina (para almacenar código y/o datos) y conexiones de red (para transmitir código y/o datos usando señales que se propagan), así como dispositivos de usuario de entrada/salida (por ejemplo, un teclado, una pantalla táctil, y/o un dispositivo de visualización) en algunos casos. El acoplamiento

5

10

15

20

25

30

35

40

45

50

55

60

del conjunto de procesadores y otros componentes se efectúa normalmente a través de una o más interconexiones dentro de los dispositivos electrónicos (por ejemplo, buses y posiblemente puentes). Así, normalmente un soporte no transitorio de un dispositivo electrónico dado legible por máquina almacena instrucciones para ser ejecutadas en uno o más procesadores de ese dispositivo electrónico. Una o más partes de una realización de la invención puede ser implementadas usando diferentes combinaciones de soporte lógico, soporte lógico inalterable y/o soporte físico.

Según se lo usa en la presente memoria, un dispositivo de red (por ejemplo, un dispositivo de encaminamiento, un conmutador, un puente) es un equipo de red, que incluye soporte físico y soporte lógico, que se interconecta comunicativamente con otros equipos de la red (por ejemplo, otros dispositivos de red, estaciones terminales). Algunos dispositivos de red son “dispositivos de red de servicios múltiples” que proporcionan soporte para múltiples funciones de conexión en red (por ejemplo, encaminamiento, puenteo, conmutación, agregación de la capa 2, control de límites de sesiones, calidad de servicio, y/o gestión de abonados), y/o proporcionan soporte para servicios de aplicaciones múltiples (por ejemplo, datos, voz y vídeo), contenido de acceso/servicios de estaciones terminales de usuario (por ejemplo, servidores, estaciones de trabajo, portátiles, ordenadores superportátiles de red, agendas electrónicas, teléfonos móviles, teléfonos inteligentes, teléfonos multimedia, teléfonos de voz sobre protocolo de Internet (VOiP), equipos de usuario, terminales, reproductores multimedia portátiles, unidades de GPS, sistemas de juego, decodificadores) proporcionados mediante Internet y/o contenido/servicios proporcionados en redes privadas virtuales (VPN) superpuestas sobre Internet (por ejemplo, tuneladas a través de la misma). El contenido y/o los servicios son proporcionados normalmente por una o más estaciones terminales (por ejemplo, estaciones terminales servidoras) pertenecientes a un proveedor de servicios o contenidos o estaciones terminales que participan en un servicio entre dispositivos del mismo nivel (P2P), y pueden incluir, por ejemplo, páginas electrónicas públicas (por ejemplo, contenido gratuito, interfaces de usuario en tiendas de venta electrónica, servicios de búsqueda), páginas electrónicas privadas (por ejemplo, páginas electrónicas objeto de acceso por nombre de usuario/contraseña que proporcionen servicios de correo electrónico), y/o redes empresariales sobre las VPN. Normalmente, las estaciones terminales de abonado están acopladas (por ejemplo, mediante equipos en las oficinas del cliente acoplados a una red de acceso (de forma cableada o inalámbrica)) a dispositivos periféricos de red, que están acoplados (por ejemplo, mediante uno o más dispositivos centrales de red) a otros dispositivos periféricos de red, que están acoplados a otras estaciones terminales (por ejemplo, estaciones terminales servidoras).

Comúnmente, los dispositivos de red están separados en un plano de control y un plano de datos (denominado a veces plano de transmisión o plano multimedia). En caso de que el dispositivo de red sea un dispositivo de encaminamiento (o esté implementando una funcionalidad de encaminamiento), el plano de control determina normalmente cómo han de encaminarse (por ejemplo, el siguiente salto para los datos y el puerto saliente para esos datos) los datos (por ejemplo, paquetes), y el plano de datos está encargado de transmitir esos datos. Por ejemplo, el plano de control normalmente incluye uno o más protocolos de encaminamiento (por ejemplo, un protocolo de pasarela exterior, tal como el protocolo de pasarela límite (BGP) (RFC 4271), uno o varios protocolos de pasarela interior (IGP) (por ejemplo, apertura primero de la ruta más corta (OSPF) (RFC 2328 y 5340), encaminamiento entre sistemas intermedios (IS-IS) (RFC 1142), protocolo de información de encaminamiento (RIP) (versión 1 RFC 1058, versión 2 RFC 2453, y siguiente generación RFC 2080)), protocolo de distribución de etiquetas (LDP) (RFC 5036), protocolo de reserva de recursos (RSVP) (RFC 2205, 2210, 2211, 2212, así como RSVP-Gestión de tráfico (Te): extensiones a RSVP para túneles LSP RFC 3209, RSVP-TE de señalización de conmutación generalizada de etiquetas multiprotocolo (GMPLS) RFC 3473, RFC 3936, 4495 y 4558)) que se comunican con otros dispositivos de red para intercambiar rutas y seleccionar esas rutas en función de una o más métricas de encaminamiento. Además, el plano de control también incluye normalmente protocolos ISO de control de la capa 2, tales como el protocolo de árbol de expansión rápida (RSTP), el protocolo de árbol de expansión múltiple (MSTP), y SPB (derivación por la ruta más corta), que han sido estandarizados por diversos organismos de certificación (por ejemplo, SPB ha sido definido en el estándar 802.1aq-2012 del IEEE.

Las rutas y las adyacencias son almacenadas en una o más estructuras de encaminamiento (por ejemplo, la base de información de encaminamiento (RIB), la base de información de etiquetas (LIB), una o más estructuras de adyacencia) en el plano de control. El plano de control programa el plano de datos con información (por ejemplo, información de adyacencia y ruta) en función de la estructura o las estructuras de encaminamiento. Por ejemplo, el plano de control programa la información de adyacencia y ruta en una o más estructuras de derivación (por ejemplo, la base de información de derivación (FIB), la base de información de derivación por etiquetas (LFIB), y una o más estructuras de adyacencia) en el plano de datos. El plano de datos usa estas estructuras de derivación y adyacencia cuando deriva el tráfico.

Cada uno de los protocolos de encaminamiento descarga anotaciones de ruta a una RIB principal en función de cierta métrica de encaminamiento (la métrica puede ser diferente para diferentes protocolos de encaminamiento). Cada uno de los protocolos de encaminamiento puede almacenar las anotaciones de ruta, incluyendo las anotaciones de ruta que no se descargan a la RIB principal, en una RIB local (por ejemplo, una RIB local OSPF). Un módulo RIB que gestiona la RIB principal selecciona rutas de las rutas descargadas por los protocolos de encaminamiento (en función de un conjunto de métricas) y descarga esas rutas seleccionadas (denominadas a veces anotaciones de ruta activas) al plano de datos. El módulo RIB también puede hacer que las rutas sean redistribuidas entre protocolos de encaminamiento. Para la derivación de la capa 2, el dispositivo de red puede almacenar una o más tablas de puenteo que se usan para derivar datos en función de la información de la capa 2 en esos datos.

5

10

15

20

25

30

35

40

45

50

55

60

Normalmente, un dispositivo de red incluye un conjunto de una o más tarjetas de línea, un conjunto de una o más tarjetas de control y, opcionalmente, un conjunto de una o más tarjetas de servicios (denominadas a veces tarjetas de recursos). Estas tarjetas están acopladas entre sí mediante uno o más mecanismos de interconexión (por ejemplo, una primera interconexión total que acople las tarjetas de línea y una segunda interconexión total que acople todas las tarjetas de control). El conjunto de tarjetas de línea forma el plano de datos, mientras que el conjunto de tarjetas de control proporciona el plano de control e intercambia paquetes con dispositivos externos de red a través de las tarjetas de línea. El conjunto de tarjetas de servicios puede proporcionar procesamiento especializado (por ejemplo, servicios de la capa 4 a la capa 7 (por ejemplo, cortafuegos, protocolo de seguridad de Internet (IPsec) (RFC 4301 y 4309), sistema de detección de intrusiones (IDS), comunicaciones entre dispositivos del mismo nivel (P2P), controlador de límites de sesiones de voz sobre IP (VoIP), pasarelas inalámbricas móviles (nodo de soporte de pasarela del servicio general de radiotransmisión por paquetes (GPRS) (GGSN), pasarela de central de paquetes evolucionados (EPC))). A título de ejemplo, se puede usar una tarjeta de servicios para terminar túneles IPsec y ejecutar los algoritmos concomitantes de autentificación y cifrado.

Según se usa en la presente memoria, un nodo envía paquetes IP en función de parte de la información de la cabecera IP en el paquete IP, incluyendo la cabecera IP la dirección IP de origen, la dirección IP de destino, el puerto de origen, el puerto de destino (refiriéndose en la presente memoria “puerto de origen” y “puerto de destino” a puertos de protocolo, en contraposición con los puertos físicos de un dispositivo de red), el protocolo de transporte (por ejemplo, el protocolo de datagramas de usuario (UDP) (RFC 768, 2460, 2675, 4113 y 5405), el protocolo de control de transmisiones (TCP) (RFC 793 y 1180), y valores de servicios diferenciados (DSCP) (RFC 2474, 2475, 2597, 2983, 3086, 3140, 3246, 3247, 3260, 4594, 5865, 3289, 3290 y 3317). Los nodos son implementados en dispositivos de red. Un nodo físico se implementa directamente en el dispositivo de red, mientras que un nodo virtual es una abstracción de soporte lógico, y posiblemente soporte físico, implementada sobre el dispositivo de red. Así, en un solo dispositivo de red pueden implementarse múltiples nodos virtuales.

Una interfaz de red puede ser física o virtual; y una dirección de interfaz es una dirección IP asignada a una interfaz de red, ya sea una interfaz física de red o una interfaz virtual de red. Una interfaz física de red es un soporte físico en un dispositivo de red a través del cual se realiza una conexión de red (por ejemplo, inalámbricamente a través de un controlador de interfaz de red inalámbrica (WNIC) o a través de la conexión de un cable a un puerto conectado a un controlador de interfaz de red (NIC)). Normalmente, un dispositivo de red tiene múltiples interfaces físicas de red. Una interfaz virtual de red puede estar asociada con una interfaz física de red, con otra interfaz virtual o ser autónoma (por ejemplo, una interfaz de bucle de retorno, una interfaz de protocolo punto a punto). Una interfaz (física o virtual) de red puede estar numerada (una interfaz de red con una dirección IP) o no numerada (una interfaz de red sin una dirección IP). Una interfaz de bucle de retorno (y su dirección de bucle de retorno) es un tipo específico de interfaz virtual de red (y una dirección IP) de un nodo (físico o virtual) usado a menudo con fines de gestión; denominándose a tal dirección IP dirección nodal del bucle de retorno. La dirección o las direcciones IP asignadas a la interfaz o las interfaces de red de un dispositivo de red son denominadas direcciones IP de ese dispositivo de red; en una escala más granular, la dirección o las direcciones IP asignadas a la interfaz o las interfaces de red asignadas a un nodo implementado en un dispositivo de red pueden ser denominadas direcciones IP de ese nodo.

Algunos dispositivos de red proporcionan soporte para implementar VPN (redes privadas virtuales) (por ejemplo, VPN de la capa 2 y/o VPN de la capa 3). Por ejemplo, los dispositivos de red en los que se acoplan una red del proveedor y una red del cliente son denominados, respectivamente, PE (periferia del proveedor) y CE (periferia del cliente). En una VPN de la capa 2, el envío es realiza normalmente en la o las CE en cualquier extremo de la VPN y el tráfico se envía a través de la red (por ejemplo, a través de una o más PE en las que se acoplan otros dispositivos de red). Se configuran circuitos de la capa 2 entre las CE y las PE (por ejemplo, un puerto Ethernet, un circuito virtual permanente (PVC) de ATM, un PVC de retransmisor de tramas). Normalmente, en una VPN de la capa 3, las PE llevan a cabo el encaminamiento. A título de ejemplo, puede desplegarse como PE un dispositivo periférico de red que soporte contextos múltiples; y puede configurarse un contexto con un protocolo VPN, y así ese contexto es denominado contexto VPN.

Algunos dispositivos de red proporcionan soporte para VPLS (servicio de LAN privada virtual) (RFC 4761 y 4762). Por ejemplo, en una red VPLS, las estaciones terminales de abonado acceden a contenido/servicios proporcionados mediante la red VPLS acoplándose a las CE, que están acopladas a través de las PE con las que se acoplan otros dispositivos de red. Las redes VPLS pueden ser usadas para implementar aplicaciones de red de conmutación de tres funciones (por ejemplo, aplicaciones de datos (por ejemplo, acceso de alta velocidad a Internet), aplicaciones de vídeo (por ejemplo, un servicio de televisión tal como IPTv (televisión con protocolo de Internet), servicio VoD (vídeo a la carta)), y aplicaciones de voz (por ejemplo, servicio VoIP (voz sobre protocolo de Internet))), servicios VPN, etc. VPLS es un tipo de VPN de la capa 2 que puede ser usado para una conectividad multipunto. Las redes VPLS también permiten que las estaciones terminales de abonado que estén acopladas con las CE en ubicaciones geográficas separadas se comuniquen entre sí en una red de área amplia (WAN) como si estuvieran directamente conectadas entre sí en una red de área local (LAN) (denominado LAN emulada).

En las redes VPLS, cada CE se conecta normalmente, posiblemente a través de una red de acceso (cableada y/o inalámbrica), a un módulo puente de una PE a través de un circuito de conexión (por ejemplo, un enlace o conexión virtual entre la CE y la PE). El módulo puente de la PE se conecta a una LAN emulada a través de una interfaz de

5

10

15

20

25

30

35

40

45

50

55

LAN emulada. Cada módulo puente actúa como una “instancia de conmutación virtual” (VSI) manteniendo una tabla de transmisión que correlaciona direcciones MAC a pseudohilos y circuitos de conexión. Las PE envían tramas (recibidas de las CE) a destinos (por ejemplo, otras Ce, otras PE) en función del campo de dirección de destino MAC incluido en esas tramas.

Subcapa de agregación de enlaces

La Figura 2 es un diagrama de una realización de subcapa 200 de agregación de enlaces. El cliente agregador 202 se comunica con un conjunto de puertos 292, 294, 296 de agregación a través del agregador 250. En una realización, el agregador 250 presenta una interfaz estándar del servicio interno de subcapa (ISS) del estándar 802.1Q del IEEE al cliente agregador 202. El agregador 250 se conecta a uno o más puertos de agregación, incluyendo los puertos 292, 294, 296 de agregación. El agregador 250 distribuye las transmisiones de tramas procedentes del cliente agregador 202 a los puertos 292, 294, 296 de agregación, y junta las tramas recibidas de los puertos 292, 294, 296 de agregación y las pasa al cliente agregador 202 de forma transparente.

La conexión de los puertos 292, 294, 296 de agregación al agregador 250 es gestionada por el control 210 de agregación de enlaces, que es responsable de determinar qué enlaces pueden ser agregados, agregarlos, conectar los puertos de agregación a un agregador apropiado y monitorizar las condiciones para determinar cuándo se necesita un cambio en la agregación. Tal determinación y tal conexión pueden ser bajo control manual a través de la manipulación directa de las variables de estado de la agregación de enlaces (por ejemplo, a través de claves de agregación) por un gestor de red. Además, la determinación, la configuración, la conexión y la monitorización automáticas pueden producirse mediante el uso del protocolo 214 de control de agregación de enlaces (LACP). El LACP 214 usa intercambios entre dispositivos del mismo nivel a través de los enlaces para determinar, de forma continua, la capacidad de agregación de los diversos enlaces, y proporciona continuamente el nivel máximo de la capacidad de agregación lograble entre un par dado de sistemas de agregación.

Un sistema de agregación puede contener múltiples agregadores, que sirven a múltiples clientes agregadores. Un puerto dado de agregación se conectará (como máximo) con un único agregador en cualquier momento. Un cliente agregador es servidor por un único agregador en un momento dado.

La ordenación de tramas es mantenida para ciertas secuencias de intercambios de tramas entre clientes agregadores (denominadas conversaciones). El distribuidor 234 de tramas garantiza que todas las tramas de una conversación dada sean pasadas a un único puerto de agregación. Para una conversación dada, se requiere que el colector 224 de tramas pase las tramas al cliente agregador 202 para que sean recibidas desde el puerto de agregación. El colector 224 de tramas está, por lo demás, libre para seleccionar las tramas recibidas de los puertos 292, 294, 296 de agregación en cualquier orden. Dado que no hay ningún medio para que las tramas se desordenen por un único enlace, esto garantiza que se mantenga la ordenación de tramas para cualquier conversación. Las conversaciones pueden ser movidas entre los puertos de agregación dentro de un grupo de agregación de enlaces, tanto para la distribución compensada de carga como para el mantenimiento de la disponibilidad en caso de fallos de enlace.

A cada uno de los puertos 292, 294, 296 de agregación se le asignan direcciones del control de acceso al medio (MAC), que son únicas en el grupo de agregación de enlaces y a cualquier red de área local (LAN) puenteada (por ejemplo, una que se atenga a la LAN puenteada 802.1Q del IEEE) a la que el grupo de agregación de enlaces esté conectado. Estas direcciones MAC son usadas como direcciones de origen para los intercambios de tramas que sean iniciados por entidades dentro de la propia subcapa 270 de agregación de enlaces (es decir, los intercambios de protocolo LACP 214 y marcador).

Al agregador 250 (y a otros agregadores si son desplegados) se le asigna dirección MAC, única en el grupo de agregación de enlaces y a la LAN puenteada (por ejemplo, una que se atenga a la LAN puenteada 802.1Q del IEEE) a la que el grupo de agregación de enlaces esté conectado. Esta dirección es usada como la dirección MAC del grupo de agregación de enlaces desde la perspectiva del cliente agregador 202, como dirección de origen para las tramas transmitidas y también como dirección de destino para las tramas recibidas. La dirección MAC del agregador 250 puede ser una de las direcciones MAC de un puerto de agregación en el grupo asociado de agregación de enlaces.

Interconexión de redes resilientes distribuidas (DRNI)

La agregación de enlaces crea un grupo de agregación de enlaces que es una colección de uno o más enlaces físicos que, a las capas superiores, parece un único enlace lógico. El grupo de agregación de enlaces tiene dos extremos, cada uno de los cuales termina en un sistema de agregación. La DRNI expande el concepto de agregación de enlaces para que, en cualquiera de los dos extremos de un grupo de agregación de enlaces, o en ambos, el único sistema de agregación sea sustituido por un portal, cada uno de los cuales está compuesto por uno o más sistemas de agregación.

Se crea la DRNI usando un retransmisor distribuido para interconectar dos o más sistemas, cada uno de los cuales ejecuta una agregación de enlaces, para crear un portal. Cada sistema de agregación en el portal (es decir, cada sistema de portal) ejecuta una agregación de enlaces con un solo agregador. El retransmisor distribuido permite que

5

10

15

20

25

30

35

40

45

50

los sistemas de portal terminen conjuntamente un grupo de agregación de enlaces. A todos los demás sistemas de agregación a los que está conectado el portal, el grupo de agregación de enlaces parece terminar en un sistema emulado de agregación separado creado por los sistemas de portal.

La intención es crear una DRNI introduciendo un retransmisor distribuido para interconectar dos o tres sistemas, cada uno de los cuales ejecuta una agregación de enlaces, para crear un portal. Cada sistema en el portal (es decir, cada sistema de portal) ejecuta una agregación de enlaces con un único agregador. El retransmisor distribuido está pensado para permitir que los sistemas de portal terminen conjuntamente un grupo de agregación de enlaces. A todos los demás sistemas a los que está conectado el portal, el grupo de agregación de enlaces parecerá terminar en un sistema emulado separado creado por los sistemas de portal. El estándar anteriormente mencionado IEEE 802.1AX-REV/D1.0 no proporciona suficiente información con respecto a cómo ha de funcionar el retransmisor distribuido.

Retransmisores distribuidos

Se crea una DRNI usando un retransmisor distribuido para interconectar dos o tres sistemas, cada uno de los cuales ejecuta una agregación de enlaces, para crear un portal. Cada sistema en el portal (es decir, cada sistema de portal) ejecuta una agregación de enlaces con un único agregador. El retransmisor distribuido permite que los sistemas de portal terminen conjuntamente un grupo de agregación de enlaces. A todos los demás sistemas a los que está conectado el portal, el grupo de agregación de enlaces parecerá terminar en un sistema emulado separado creado por los sistemas de portal.

La Figura 3A ilustra un sistema básico de retransmisiones distribuidas como punto de partida para describir el retransmisor distribuido. Los enlaces de red en la Figura 3A y expuestos en la presente memoria corresponden a enlaces físicos o lógicos que son visibles a los protocolos de red y están bajo el control de los mismos. En este diagrama, cada uno de los sistemas A y B se caracteriza por llevar a cabo una “función 1”, que es algún tipo de función de retransmisión de paquetes, por ejemplo, un dispositivo de encaminamiento o un puente. La “función 1” también podría ser una operación de un servidor de ficheros, en cuyo caso lo más probable es que los dos “puertos” exteriores de cada sistema no estuvieran presentes. Cada sistema ejecuta una sola instancia de una subcapa de agregación de enlaces. En una realización, se desea que los puertos sombreados estén asociados en un portal con un retransmisor distribuido.

La Figura 3A es un ejemplo, no el caso general. En general, el retransmisor distribuido soporta:

a) Los protocolos y los procedimientos necesarios para únicamente las configuraciones enumeradas a continuación en la presente memoria son proporcionados por esta solicitud.

b) Las funciones de agregación de enlaces, cada una de las cuales subsume uno o más MAC.

c) Las conexiones entre los sistemas de portal del retransmisor distribuido.

El propósito de introducir la capa funcional del retransmisor distribuido en este ejemplo es hacer que estos dos sistemas de portal, a los sistemas conectados a ellos, parezcan estar en la configuración ilustrada en la Figura 3B. Parece existir un tercer sistema emulado C, conectado a los sistemas originales de portal mediante un enlace que ha sido insertado entre la función 1 y la agregación de enlaces. Es decir, los sistemas de portal A y B conspiran para comportarse, hasta donde pueda discernir cualquier otro sistema al que estén conectados, como si el sistema emulado C existiera realmente, según se muestra en la Figura 3B. Aunque la Figura 3B es un ejemplo, ilustra los principios del retransmisor distribuido.

d) El retransmisor distribuido en el sistema emulado C es un retransmisor de (N+1) puertos parar N sistemas de portal, con N puertos de pasarela conectados a los sistemas de portal, y una sola subcapa emulada de agregación de enlaces asociada con los sistemas originales de portal.

e) Los puertos de agregación (también denominados MAC en la presente memoria) han sido movidos al sistema emulado y, así, a todos los demás sistemas, parecen estar igualmente distantes de los sistemas reales de portal que comprenden el retransmisor distribuido.

Los constructos reales usados por los dos sistemas de portal para crear el sistema emulado C están ilustrados en la Figura 4. La Figura 4 muestra las dos funciones de DR del retransmisor distribuido, una función de DR en cada sistema A y B. Este ejemplo ilustra los restantes principios del retransmisor distribuido:

f) En cada sistema A y B, los puertos que han de asociarse con el sistema C son movidos a una posición por debajo de la subcapa de agregación de enlaces de la función de DR.

g) Se construye un enlace virtual y sus MAC virtuales terminales, denominados “pasarela”, para conectar cada función de DR a su función 1.

5

10

15

20

25

30

35

40

45

50

h) Entre cada par de funciones de DR en el portal se construye un enlace intraportal (IPL), terminado en cada extremo por un puerto intraportal (IPP). (Este puede existir en muchas formas; véase la exposición posterior en la presente memoria).

i) Hay un “algoritmo de pasarela” que decide a través de qué pasarela una trama puede entrar o salir del retransmisor distribuido emulado.

j) De modo similar, un “algoritmo de puerto” decides a través de qué puertos de agregación del sistema de portal una trama puede entrar o salir del retransmisor distribuido emulado.

k) Según se ha mencionado anteriormente, puede haber tres sistemas participantes para crear un portal y un sistema emulado C. En ese caso, el retransmisor distribuido en el sistema emulado C tiene un puerto adicional de pasarela, uno para cada sistema de portal, y varios IPL para interconectar las funciones de DR.

l) Las funciones de DR, especificadas posteriormente en la presente memoria, trabajan conjuntamente para mover tramas entre las pasarelas, el IPL, y las subcapas de agregación de enlaces.

Operación y procedimientos del retransmisor distribuido

La función de DR en cada sistema de portal (Figura 4) está previsto que tenga (sujeto a fallos operativos) tres tipos de puertos:

A) Puertos intraportal, como máximo un puerto IPL (quizá complejo en alguna realización) conectado a cada uno de los demás sistemas de portal pertenecientes al mismo portal;

B) Exactamente un puerto virtual de pasarela con un enlace virtual a un puerto virtual de pasarela en el sistema de portal en el que reside la función de DR; y

C) Exactamente un puerto agregador (el puerto que está soportado por la instancia de ISS identificada por el prefijo Agg) a la subcapa de agregación de enlaces con un número cualquiera de puertos de agregación, previsto para conectarse a otros sistemas de una manera tal que esos otros sistemas crean que están conectados a un único sistema emulado.

En la Figura 3B, los enlaces intraportal y los puertos IPL son invisibles, y el retransmisor distribuido del sistema emulado de agregación C tiene una pasarela a cada uno de los sistemas de su portal.

El propósito del retransmisor distribuido emulado es pasar cada trama recibida de un puerto de agregación (“trama ascendente”) a una pasarela, o descartarla, y cada trama recibida de una pasarela (“trama descendente”) a un puerto agregador, o descartarla. A veces, las funciones de DR que comprenden el retransmisor distribuido deben enviar una trama a través de uno o dos enlaces intraportal para llevarla hasta el puerto agregador o pasarela correcto. Una función de DR realiza la elección de descartar o dejar pasar una trama a su pasarela, su puerto agregador, o uno de sus IPL asignando cada trama a dos ID de conversación, un ID de conversación de pasarela y un ID de conversación de puerto, y configurando las pasarelas, los puertos de agregación y los IPL en términos de estos ID de conversación.

El “algoritmo de pasarela” mencionado consiste en dos partes: un algoritmo para asignar cualquier trama dada a un ID de conversación de pasarela, y una asignación de los ID de conversación de pasarela a pasarelas (usando, por ejemplo, Drni_Gateway_Conversation).

Si el sistema de portal es un puente VLAN que realiza un aprendizaje, la correlación de una trama con un ID de conversación de pasarela estará basada en su ID de VLAN; si no, el proceso de aprendizaje se rompe en toda la red. Para implementaciones de DRNI en estos casos, puede haber una correlación biunívoca de ID de VLAN a ID de conversación.

De modo similar, el “algoritmo de puerto” del elemento j de la anterior sección “Retransmisores distribuidos” consiste en un algoritmo para asignar cualquier trama dada a un ID de conversación de puerto, y una asignación de los ID de conversación de puerto a puertos de agregación (usando, por ejemplo, aAggConversationAdminPort[]).

Posteriormente en la presente memoria se especifican medios para garantizar que todas las funciones de DR en un portal dado usen el mismo algoritmo de pasarela y el mismo algoritmo de puerto para asignar tramas a sus respectivos ID de conversación, y para garantizar que cualquier ID dado de conversación de pasarela sea asignado, como máximo, a una de las pasarelas, y cualquier ID dado de conversación de puerto, como máximo, a uno de los puertos de agregación de un portal, en cualquier momento dado.

Se permite, pero no se requiere, que el algoritmo de pasarela y el algoritmo de puerto usen los mismos medios para asignar una trama a un ID de conversación, para que el ID de conversación de pasarela sea igual al ID de conversación de puerto.

5

10

15

20

25

30

El algoritmo de puerto siempre es aplicado a una trama cuando entre en la función de DR procedente de la pasarela para determinar si procede enviarla al puerto agregador o a un IPP particular. El algoritmo de pasarela siempre se aplica a una trama cuando entra procedente del puerto agregador para determinar si procede enviarla a la pasarela o a un IPP particular. Ambos algoritmos tienen que ser aplicados, y sus resultados comparados, para enviar una trama que entra en una función de DR procedente de un IPL, según se muestra en la Tabla 1.

Tabla 1. Función de DR: Envío de trama recibida del enlace intraportal n

El algoritmo de pasarela dice: “La pasarela es/está ...”: El algoritmo de puerto dice: “El puerto de agregación es/está ...” La función de DR emite la trama a:

mi pasarela: cualquiera*
mi pasarela

detrás del IPL n: uno de mis puertos de agregación mi puerto agregador

detrás del IPL n: descartar

detrás del IPL m (£ n): IPL m (* n)

detrás del IPL m (£ n): cualquiera1 IPL m (* n)

A) [1] “Cualquiera” significa que no se usa la salida del algoritmo de puerto; el algoritmo de pasarela determina a qué puerto se envía la trama.

B) [2] Las funciones de DR en diferentes sistemas de portal tienen configuraciones incompatibles, o hay un fallo. Descartar la trama para evitar la entrada en bucle.

C) La Tabla 1 da por sentada una de tres configuraciones:

• Dos sistemas de portal conectados por un único IPL;

• Tres sistemas de portal conectados linealmente por dos IPL; o

• Tres sistemas de portal conectados circularmente por tres IPL.

D) El algoritmo de pasarela es impuesto en ambas direcciones a través de la pasarela; es decir, una trama que entre en la función de DR procedente de una pasarela es descartada si el algoritmo de pasarela, aplicado a esa trama, no lo devolvería ascendentemente a la pasarela. Esto es necesario para impedir que las tramas recibidas de una pasarela sean enviadas a través de un IPL y devueltas a la red a través de otra pasarela.

E) Si el algoritmo de pasarela indica que la trama debería pasar a través de la pasarela, debe ser una trama ascendente, porque una trama descendente no podría entrar en el portal de cualquier otra función de DR, por el elemento D) anterior.

F) Si no, si el algoritmo de pasarela indica que la trama vino desde del IPL al que sería enviada, entonces es una trama descendente y, así, es enviada usando el algoritmo de puerto. (Si el algoritmo de puerto la devolvería al puerto por el que llegó, hay algún tipo de fallo o de configuración indebida, y se descarta la trama).

G) Si no, el algoritmo de pasarela indica que la trama no vino del IPL al que sería enviada, por lo que debe de ser una trama ascendente, y la trama es dirigida según el algoritmo de pasarela.

NOTA: El algoritmo de puerto y el protocolo de control de retransmisiones distribuidas del retransmisor distribuido determinan conjuntamente la correlación entre los ID de conversación de puerto con puertos de agregación individuales, y las variables en su control determinan la operación del distribuidor de tramas y el colector de tramas. Sin embargo, esto no altera la trayectoria de los datos ni el control descritos, dado que el retransmisor distribuido pasa a través del agregador todos los datos destinados a los puertos de agregación, o procedentes de los mismos.

La Tabla 2 y la Tabla 3 muestran, respectivamente, la aplicación de los algoritmos de pasarela y puerto a las tramas que entran en una función de DR procedentes de una pasarela y de un puerto agregador.

Tabla 2. Función de DR: Envío de trama recibida de mi pasarela

mi pasarela: uno de mis puertos de agregación mi puerto agregador

detrás del IPL n: IPL n

detrás del IPL n: cualquiera descartar

5

10

15

20

25

30

35

40

Tabla 3. Función de DR: Envío de trama recibida de uno de mis puertos de agregación

El algoritmo de pasarela dice: “La pasarela es/está ...": El algoritmo de puerto dice: “El puerto de agregación es/está ..." La función de DR emite la trama a:

mi pasarela: cualquiera
mi pasarela

detrás del IPL n: cualquiera IPL n

Topología de portales

La topología de portal más general es tres sistemas de portal conectados en un anillo por tres enlaces intraportal, según se ilustra en la Figura 21. Otras topologías soportadas según otras realizaciones de la invención son subconjuntos de esta, incluyendo:

• Tres sistemas de portal conectados en una cadena por dos IPL,

• Dos sistemas de portal conectados por un único IPL,

• Un sistema de portal sin ningún IPL activo.

Se usan los términos Propio (Home), Vecino y Otro vecino para identificar los sistemas de portal desde el punto de vista de un puerto intraportal dado. El propio es el sistema que contiene el IPP. El vecino es el sistema conectado al IPP. El otro vecino es el sistema conectado al otro IPP (si está presente) en el sistema propio. Con referencia a la Figura 21, usando el IPP B1 como ejemplo, su sistema propio es B, su vecino inmediato es A (porque está conectado al IPP B1 a través del IPL AB), y su otro vecino es C (porque está conectado al IPP B2 mediante el IPL BC). Obsérvese que el otro vecino del IPP A2 también es C (porque está conectado al IPP A1 mediante el IPL AC), por lo que comparar los ID de los otros vecinos de los IPP B1 y A2 verifica que hay no más de tres sistemas en un anillo o cadena.

Enlace intraportal

Un enlace intraportal (IPL) es un único enlace lógico punto a punto entre funciones de DR en dos sistemas diferentes. Una función de DR tiene, como máximo, un IPL para cada uno de los demás sistemas que comprenden un extremo de un grupo de agregación de enlaces DRNI. Los IPL y los enlaces de red pueden compartir un enlace físico o una agregación de enlaces (siendo la agregación de enlaces una agregación de un conjunto de enlaces).

Un IPL puede ser físico (por ejemplo, una LAN Ethernet 802.3) o lógico (por ejemplo, una instancia de servicio troncal 802.1Q o un pseudohilo IETF). Un enlace intraportal puede compartir un enlace físico con otros enlaces intraportal o enlaces de red. Un enlace intraportal puede ser un grupo de agregación de enlaces, y consistir así en varios enlaces físicos.

Ocurrirá a menudo en las redes desplegadas que dos sistemas serán configurados tanto con un enlace normal de red conectándolos, como con un IPL, según se ilustra en la Figura 4. Reduciría la utilidad de la DRNI si cada portal requiriese su propio IPL físico separado, especialmente si se configura un par de sistemas para soportar portales múltiples. La DrNi soporta varios métodos mediante los cuales los sistemas pueden distinguir tramas en un enlace de red con respecto a las tramas en un IPL particular:

• Físico. Puede usarse un enlace físico separado para soportar cualquier enlace de red particular o IPL.

• Agregado. Puede usarse un puerto agregador separado para soportar un IPL.

• De compartición de tiempo. Un enlace de red y uno o más IPL pueden usar el mismo enlace físico (o puerto agregador), pero en diferentes momentos. Esto requiere que los sistemas inhabiliten el uso del enlace de red cuando se requiere el IPL para la conectividad, o, si no, que el uso de los enlaces de agregación y la selección de pasarelas sean regulados para eliminar la necesidad de uso del IPL cuando se requiere el enlace de red. En la presente memoria se describe esta técnica.

• De compartición de etiqueta. Un enlace de red y uno o más IPL pueden usar el mismo enlace físico (o puerto agregador), usando diferentes ID de servicio. En la presente memoria se describe la compartición de etiqueta.

• Lógico. Las tramas en el enlace de red y el o los IPL pueden ser encapsuladas, según se describe en la presente memoria.

Un sistema que implemente la DRNI puede soportar el uso de enlaces físicos separados para los IPL y los enlaces de red, y puede soportar cualquiera de los otros métodos.

5

10

15

20

25

30

35

40

45

50

55

En cada extremo del enlace físico o del puerto agregador compartidos, hay un puerto virtual para cada función (enlace de red o un IPL particular) para el que es usado el enlace o el puerto agregador. Cualesquiera de los anteriores métodos pueden ser usados simultáneamente entre dos sistemas, por elección administrativa, siempre y cuando ambos extremos de cualquier enlace físico o puerto agregador dado use el mismo método.

Compartición de red/IPL por tiempo

La meta de la compartición de red/IPL por tiempo es soportar la DRNI sin requerir enlaces físicos separados para una conexión de red y el IPL, y sin requerir ninguna modificación de las tramas. Cuando se comparte un enlace, es necesario poder determinar para cada trama si se quiere que esa trama atraviese la conexión de red o el IPL. Esta determinación puede realizarse sin modificar la trama (por ejemplo, sin traducir el ID de VLAN ni añadir una etiqueta o encapsulación) si, en cualquier momento dado, se sabe que el enlace físico es utilizado únicamente como un enlace de red o es utilizado únicamente como un IPL. Que el enlace sea usado como un enlace de red o como un IPL en cualquier momento dado lo establece el protocolo de control usado para establecer una topología activa plenamente conectada sin bucles para cada VLAN de la red.

Si el enlace no está incluido en la topología activa de una VLAN (por ejemplo, ha sido bloqueado por la operación del protocolo de control de red), está disponible para ser usado como iPl. En este caso, el enlace es usado por la DRNI exactamente como si fuera un IPL dedicado (no compartido).

Si el enlace está incluido en la topología activa de una VLAN, entonces no hay ningún IPL disponible para esa VLAN. En este caso, la DRNI es incapaz de pasar una trama entre un puerto de agregación en un sistema de portal y una pasarela en otro sistema de portal. Por lo tanto, para cualquier trama dada, la DRNI está restringida a tener la pasarela y el puerto de agregación en el mismo sistema de portal.

NOTA 1: El hecho de que el enlace compartido pueda estar disponible para la transferencia de tramas entre una pasarela y un puerto de agregación específico no restringe la capacidad de intercambiar las DRCPDU en el enlace compartido.

Hay dos casos a considerar en la satisfacción de la restricción de que, para cualquier trama dada, la pasarela y el puerto de agregación estén en el mismo sistema de portal. El caso sencillo es cuando los ID de conversación de puerto concuerdan y son simétricos en la DRNI, y todas las tramas con un ID dado de VLAN se correlacionan con los ID de conversación de puerto que seleccionan puertos de agregación en el mismo sistema de portal. Entonces, ese sistema de portal es seleccionado como pasarela para ese ID de VLAN, y no hay ninguna necesidad de que ninguna trama de datos atraviese el IPL. En cualquier otra circunstancia, la única manera de garantizar que la pasarela y un puerto de agregación específico estén en el mismo sistema de portal es que, cuando se reciba una trama en cualquier puerto distinto del puerto de red/IPL compartido, ese sistema de portal sea considerado la pasarela para esa trama y en cada sistema de portal todos los ID de conversación de puerto se correlacionen con un puerto de agregación conectado a ese sistema. En este modo, un sistema de portal que reciba cualquier trama por un puerto de red (que no sea el IPP o el puerto de agregación) es responsable de enviar esa trama al puerto de agregación si se requiere. Un sistema de portal que reciba una trama por el IPP nunca envía esa trama al puerto de agregación. En este caso, la selección de pasarela no puede basarse necesariamente en el VID, por lo que, cuando los sistemas de portal son puentes 802.1Q, el proceso de aprendizaje en el enlace de red/IPL compartido se ve comprometido. Dado que los problemas de aprendizaje están limitados a este puerto, ello puede remediarse sincronizando las direcciones aprendidas en la DRNI con el otro sistema de portal.

Compartición de red/IPL por etiqueta

Si se emplea la distribución de tramas por servicio y si el número de servicios requeridos para soportar el enlace de red, más el número de servicios requeridos para soportar uno o más IPL, es menor que el número de servicios suministrados por el formato de trama usado (por ejemplo, los ID 4094 S-VLAN), entonces puede usarse la traducción del VID para separar las tramas en los diferentes enlaces lógicos.

El método se selecciona configurando el aDrniEncapsulationMethod con el valor 2. Si está habilitado, según indica la variable Enabled_EncTag_Shared, que es controlada por la máquina de compartición de red/IPL, cada trama que haya de ser transportada por el IPL al sistema de portal vecino y esté asociada con un ID de conversación de pasarela, es traducida para que use un valor configurado en una aDrniIPLEncapMap y cada trama que haya de ser transportada por el enlace de red, compartido con el IPL, y esté asociada con un ID de conversación de pasarela, es traducida para que use un valor configurado en una aDrniNetEncapMap.

Compartición de red/IPL por encapsulación

Este método permite compartir un IPL con un enlace de red usando técnicas de encapsulación (por ejemplo, una instancia de servicio troncal 802.1Q, una B-VLAN, un pseudohilo IETF, etc.)

El método se selecciona configurando el aDrniEncapsulationMethod con un valor que representa el método de encapsulación que es usado para transportar tramas IPL (tramas de datos que atraviesan un IPL, es decir, tramas que no tienen una DRCPDU) al sistema de portal vecino cuando el IPL y el enlace de red comparten el mismo

5

10

15

20

25

30

35

40

45

50

enlace físico. Este valor consiste en el identificador único de organización (OUI), de tres octetos, que identifica a la organización que es responsable de esta encapsulación, y un octeto posterior usado para identificar el método de encapsulación definido por esa organización. Si está habilitado, según indica la variable Enabled_EncTag_Shared, que es controlada por la máquina de compartición de red/IPL, cada trama que haya de ser transmitida por el IPL al sistema de portal vecino y esté asociada con un ID de conversación de pasarela, es encapsulada con un método especificado por un aDrniEncapsulationMethod para que use un valor configurado en una aDrniIPLEncapMap y cada trama que haya de ser recibida por el IPL es desencapsulada y correlacionada con un ID de conversación de pasarela usando la misma tabla.

Máquina de estado de función de DR

Las máquinas de estado de función de DR implementarán las reglas de derivación especificadas en las Tablas 1-3. Estas reglas de derivación pueden resumirse como sigue:

a) Para tramas que entran a través de un puerto de agregación, tramas ascendentes, el algoritmo de pasarela decide si procede transmitirlas al enlace de pasarela o al IPP según su ID de conversación de pasarela. Si el ID de conversación de pasarela de la trama coincide con el ID de conversación de pasarela operativa del sistema de portal, la trama será enviada a la pasarela; si no, será enviada al IPP.

b) Para tramas que entran a través de una pasarela, tramas descendentes, el algoritmo de puerto decide si procede transmitirlas al puerto de agregación o al IPP según su ID de conversación de puerto. Si el ID de conversación de puerto de la trama coincide con el ID de conversación de puerto operativo del sistema de portal, la trama será enviada al puerto de agregación; si no, será enviada al IPP.

c) Una trama ascendente ofrecida a un IPP es transmitida únicamente si el sistema de portal para este ID de conversación de pasarela se encuentra detrás de ese IPP; si no, es descartada.

d) Una trama descendente ofrecida a un IPP es transmitida únicamente si el sistema de portal diana para este ID de conversación de puerto se encuentra detrás de ese IPP; si no, es descartada.

Algunas de las variables de agregación de enlaces usadas por un retransmisor distribuido tienen que estar formadas de una manera particular, para que múltiples sistemas de portal puedan cooperar para crear un único sistema emulado:

e) Los dos bits menos significativos de la prioridad de puerto en el ID de puerto para cada puerto de agregación en puerto agregador de un retransmisor distribuido son puestos al valor de DRF_Portal_System_Number. El resto de los bits recibe un valor único dentro de la función de DR.

f) Los dos bits más significativos de la clave administrativa para cada puerto de agregación y el agregador asociado en el puerto agregador de un retransmisor distribuido son puestos al valor de DRF_Portal_System_Number. El resto de los bits puede ser usado según se ha descrito para reflejar las características físicas de los puertos de agregación.

Interfaces de servicios

Dado que una función de DR usa diversas instancias de los ISS, es necesario introducir una convención de notación para que el lector pueda tener claro en cuanto a qué interfaz se hace referencia en cualquier momento dado. Por lo tanto, se asigna un prefijo a cada primitiva de servicio que indica cuál de las interfaces se invoca. Los prefijos son los siguientes:

a) Agg: para primitivas emitidas por la interfaz entre la función de DR y la subcapa de agregación de enlaces.

b) Gate: para primitivas emitidas por la pasarela.

c) MacIppN: para primitivas emitidas por la interfaz entre las entidades MAC que soportan el IPL n y el analizador/multiplexor de control de DRCP.

d) DRCPCtrlMuxN: para primitivas emitidas por la interfaz entre el analizador/multiplexor N de control de DRCP y la entidad de control de DRCP (identificando N el IPP asociado con el analizador/multiplexor de control de DRCP).

e) IppN: para primitivas emitidas por la interfaz de la función de DR soportada por el analizador/multiplexor N de control de DRCP (identificando N el IPP asociado con el analizador/multiplexor de control de DRCP).

Variables por cada función de DR

La siguiente exposición se centra en diversas variables por cada función de DR según una realización de la invención.

DA: Dirección de destino

5

10

15

20

25

30

35

40

45

SA: Dirección de origen mac_service_data_unit

Priority (Prioridad): Los parámetros de la primitiva M_UNITDATA.indication.

BEGIN (INICIO): Una variable booleana que está puesta a TRUE (VERDADERO) cuando se inicia o reinicializa el sistema, y está puesta a FALSE (FALSO) cuando se ha completado la (re)inicialización. Valor: booleano.

Drni_Portal_System_Gateway_Conversation: Vector booleano operativo, indexado por ID de conversación de pasarela, que indica si se permite que el ID de conversación de pasarela indexado atraviese esta pasarela de función de DR (TRUE = pasa). Sus valores son calculados por la función updatePortalSystemGatewayConversation en una realización. En otra realización, esta variable es construida a partir de la variable Drni_Gateway_Conversation, poniendo a FALSE todas las anotaciones de ID de conversación de pasarela indexado que estén asociadas con otros sistemas de portal en el portal y, de las restantes anotaciones de ID de conversación de pasarela indexado, todas las que no coincidan con otros sistemas de portal.

Valor: secuencia de valores booleanos, indexados por el ID de conversación de pasarela.

Drni_Portal_System_Port_Conversation: Vector booleano operativo, indexado por ID de conversación de puerto, que indica si se permite que el ID de conversación de puerto indexado sea distribuido a través del agregador de esta función de DR (TRUE = pasa). Sus valores son calculados por la función updatePortalSystemPortConversation en una realización. En otra realización, esta variable es construida a partir de la variable Drni_Port_Conversation, poniendo a FALSE todas las anotaciones de ID de conversación de puerto indexado que estén asociadas con otros sistemas de portal en el portal y, de las restantes anotaciones de ID de conversación de pasarela indexado, todas las que no coincidan con otros sistemas de portal. Valor: secuencia de valores booleanos, indexados por el ID de conversación de puerto.

Mensajes

Agg:M_UNITDATA.indication

Gate:M_UNITDATA.indication

IppN:M_UNITDATA.indication

Agg:M_UNITDATA.request

Gate:M_UNITDATA.request

IppN:M_UNITDATA.request

Las primitivas de servicio usadas para pasar una trama recibida a un cliente con los parámetros especificados.

Si se usan los métodos de compartición de red/IPL por etiqueta o de compartición de red/IPL por encapsulación, es preciso manipular las primitivas de servicio IppN:M_UNITDATA.indication e IppN:M_UNITDATA.request mediante la operación de funciones que son controladas por la máquina de compartición de red/IPL

Función de DR: Máquina de estado de recepción de puertos agregadores

La función de DR: Máquina de estado de recepción de puertos agregadores puede implementar la función especificada en la Figura 22 con sus parámetros asociados según una realización de la invención. Hay una función de DR: Máquina de estado de recepción de puertos agregadores por sistema de portal y hay tantos estados PASS_TO_IPP_N como los IPP en un sistema de portal, cada uno de los cuales está identificado por el índice n. En el diagrama, se usa el prefijo “n.” para identificar el IPP n específico con el que está relacionada la variable asociada.

Función de DR: Máquina de estado de distribución de pasarelas

La función de DR: Máquina de estado de distribución de pasarelas puede implementar la función especificada en la Figura 23 con sus parámetros asociados según una realización de la invención. Hay una función de DR: Máquina de estado de distribución de pasarelas por sistema de portal y hay tantos estados PASS_TO_IPP_N como los IPP en un sistema de portal, cada uno de los cuales está identificado por el índice n. En el diagrama, se usa el prefijo “n.” para identificar el IPP n específico con el que está relacionada la variable asociada.

Función de DR: Máquina de estado de recepción del IPP N

La función de DR: Máquina de estado de recepción del IPP N puede implementar la función especificada en la Figura 24 con sus parámetros asociados según una realización de la invención. Hay una función de función de DR: Máquina de estado de recepción del IPP N por IPP por sistema de portal y hay tantos estados PASS_TO_IPP_M

5

10

15

20

25

30

35

40

45

como los IPP en un sistema de portal, cada uno de los cuales está identificado por el índice m. En el diagrama, se usa el prefijo “n.” o “m.” para identificar el IPP n o IPP m específico con el que está relacionada la variable asociada.

Protocolo de control de retransmisiones distribuidas

El propósito del protocolo de control de retransmisiones distribuidas (DRCP) es:

A) Establecer una comunicación entre sistemas de portal a través de un enlace intraportal;

B) Verificar la configuración coherente de los sistemas de portal;

C) Determinar la identidad que ha de usarse para el sistema emulado;

D) Distribuir entre sí los estados actuales de los sistemas de portal y sus puertos de agregación;

E) Calcular la trayectoria resultante de cualquier trama obligada a atravesar cada IPL, e intercambiar la información con sistemas de portal adyacentes según se requiera para garantizar que no se producen bucles de derivación ni una entrega duplicada de tramas;

F) Intercambiar información entre sistemas de portal para soportar funciones distribuidas no especificadas en la presente memoria;

El resultado de la operación del DRCP es mantener las variables que controlan el envío de tramas por el retransmisor distribuido.

El DRCP intercambia información para garantizar que los sistemas de portal pueden trabajar conjuntamente. La primera clase de tal información incluye los objetos y las variables gestionados, que deben ser compatibles para pasar cualquier dato en absoluto (anterior elemento A). En una realización, estos incluyen:

G) aAggPortAlgorithm: Todos los sistemas de portal deben usar el mismo algoritmo de puerto.

H) aDrniGatewayAlgorithm: Todos los sistemas de portal deben usar el mismo algoritmo de pasarela.

I) aDrniPortalId: Todos los sistemas de portal deben tener el mismo valor para aDrniPortalId, para garantizar la suposición de que todos pertenecen al mismo portal.

J) aDrniPortalTopology: Todos los sistemas de portal deben tener el mismo valor para aDrniPortalTopology y, en el caso de un portal de tres sistemas de portal conectados en anillo, es preciso configurar coherentemente el mismo aDrniLoopBreakLink, “enlace de ruptura de bucle”, en el portal.

K) aDrniPortalSystemNumber: Todos los sistemas de portal deben tener valores aDrniPortalSystemNumber diferentes, y todos estos valores deben estar en el intervalo 1 ... 3, para garantizar que la información pueda ser etiquetada de forma significativa.

L) aAggActorAdminKey: Los dos bits más significativos de la clave administrativa para cada agregador en el puerto agregador de un retransmisor distribuido son puestos al valor de DRF_Portal_System_Number. El resto de los bits refleja las características físicas de los puertos de agregación asociados y tienen que ser los mismos para todos los sistemas de portal en el portal.

La segunda clase de objetos gestionados (elemento B) controla a través de qué pasarela y de qué puertos de agregación pasa cada ID de conversación. Para estos objetos gestionados, si la información sobre un ID de conversación está configurada diferentemente en diferentes sistemas de portal, solo se ve afectado ese ID de conversación. Por lo tanto, el portal puede operar normalmente, y los mecanismos que garantizan que no se produzcan una entrega duplicada ni bucles de derivación bloquearán el paso de cualquier trama perteneciente a ID de conversación mal configurados. Para detectar una mala configuración, para que el bloqueo no sea permanente, las funciones de DR pueden notificar al administrador de la red si las configuraciones difieren. Dado que estas configuraciones son bastante grandes, se intercambia una suma de verificación de su contenido, no las propias configuraciones. Este método detecta diferencias con una alta probabilidad, pero no con certeza. En una realización, estos objetos gestionados incluyen:

L) aDrniConvAdminGateway[]: La lista que se usa para determinar dinámicamente qué ID de conversación atraviesa qué pasarela.

M) aAggConversationAdminPort[]:La lista que se usa para determinar dinámicamente qué ID de conversación atraviesa qué puerto de agregación.

El DRCP usa su información sobre cuáles de los sistemas de portal previstos están conectados o no a través de los IPL para determinar la identidad del retransmisor distribuido emulado (anterior elemento C en esta sección).

5

10

15

20

25

30

35

40

45

Se intercambian los estados operativos actuales de todos los sistemas de portal y sus puertos de agregación para que cada una de las funciones de DR pueda determinar a qué pasarela o puerto agregador del sistema de portal ha de ser entregada cada trama (anterior elemento D en esta sección). Cada función de DR calcula un vector que especifica exactamente cuáles ID de conversación de puerto y cuáles ID de conversación de pasarela pueden atravesar cada pasarela, puerto de agregación o IPP. Esta información se intercambia en cada IPP (anterior elemento E en esta sección). Si hay diferencia entre dos vectores de funciones de DR para cualquier ID dado de conversación, las variables de salida son configuradas para que la función de DR bloquee las tramas con ese ID de conversación. Este evita la entrada en bucle o la entrega duplicada de ninguna trama.

Establecimiento del portal y del retransmisor distribuido

A la creación de portales no se le especifica automáticamente la dirección. En vez de ello, el DRCP compara las intenciones del administrador de la red, definidas por los objetos gestionados, con la topología física de los sistemas configurados y, si las configuraciones de los sistemas conectados son compatibles, el DRCP establece y habilita la operación del portal. Para establecer un retransmisor distribuido en un portal, un administrador de la red configura los siguientes objetos gestionados:

A) Puede haber muchos sistemas en una red, y algunos o la totalidad de los sistemas de portal seleccionados pueden participar en otros portales. Determinar qué otros sistemas de portal pertenecen al portal de este sistema de portal se logra configurando variables tales como aDrniPortalId y aDrniPortalSystemNumber.

B) Según se ha descrito anteriormente en la presente memoria, cualquier instancia punto a punto del servicio MAC puede ser asignada para que sea un enlace intraportal. Las instancias particulares asignadas al uso de una función de DR están configuradas, por ejemplo, en aDrnilntraPortalLinkList.

C) Qué agregador en cada sistema de portal ha de ser asignado a esta función de DR se configura en aDrniAggregator en una realización.

D) Los métodos que han de ser usados por las funciones de DR para asignar tramas a los ID de conversación de pasarela y los ID de conversación de puerto son configurados en dos objetos gestionados, aDrniGatewayAlgorithm y aAggPortAlgorithm en una realización.

E) Las asignaciones inicial y de reserva de los ID de conversación a pasarelas y puertos de agregación para cubrir modos de fallo están configuradas en varios objetos gestionados: aDrniConvAdminGateway[], y aAggConversationAdminPort[] en una realización.

Transmisión, direccionamiento e identificación de protocolo en las DRCPDU

Las unidades de datos del protocolo de control de retransmisiones distribuidas (DRCPDU) son transmitidas y recibidas usando el servicio proporcionado por una entidad de LLC que usa, a su vez, una única instancia del servicio MAC proporcionado en un MSAP asociado con un IPP. Cada DRCPDU es transmitida como una sola solicitud al servicio MAC, y recibida como una sola indicación del servicio MAC, con los siguientes parámetros:

• dirección de destino

• dirección de origen

• MSDU (unidad de datos de servicio MAC)

• prioridad

La MSDU de cada solicitud y cada indicación comprende varios octetos que proporcionan una identificación del protocolo EtherType seguida por la DRCPDU propiamente dicha.

NOTA 1: Para los fines de este estándar, la expresión incluye entidades que soportan la discriminación de protocolos usando el campo EtherType, según se especifica en el estándar 802 del IEEE.

NOTA 2: El formato completo de una trama de DRCP depende no solo del formato DRCPDU, aquí especificado, sino también de los procedimientos dependientes del método de acceso a medios usado para soportar el servicio MAC.

Dirección MAC de destino

La dirección de destino para cada solicitud de servicio MAC usada para transmitir una DRCPDU puede ser una dirección de grupo seleccionada por objetos gestionados por el IPP. Sus valores por defecto pueden ser la dirección de grupo de los puentes más cercanos no TPMR (retransmisor de control de acceso al medio (MAC) de dos puertos).

5

10

15

20

25

30

35

40

45

50

Dirección MAC de origen: La dirección de origen para cada solicitud de servicio MAC usada para transmitir una DRCPDU puede ser una dirección individual asociada con el MSAP (punto de acceso al servicio MAC) del IPP en el que se realiza la solicitud.

Prioridad: La prioridad asociada con cada solicitud de servicio MAC debería ser la prioridad por defecto asociada con el MSAP del IPP.

Encapsulación de las DRCPDU en tramas

Hay una DRCPDU codificada en el parámetro mac_service_data_unit de una M_UNITDATA.request o una M_UNITDATA.indication. Los primeros octetos del parámetro mac_service_data_unit son un identificador de protocolo, seguido por la DRCPDU, seguida por octetos de relleno, si los hay, según requiera el servicio MAC subyacente.

Cuando la instancia de ISS usada para transmitir y recibir tramas es proporcionada por un método de control de acceso al medio que pueda soportar directamente la codificación EtherType (que sea, por ejemplo, un MAC IEEE

802.3) , el identificador de protocolo tiene dos octetos de longitud. Todas las DRCPDU son identificadas por el EtherType especificado. Cuando la instancia de ISS es proporcionada por un método de acceso al medio que no pueda soportar directamente la codificación EtherType (que sea, por ejemplo, un MAC IEEE 802.11), el TPID es codificado según la regla para un protocolo de acceso a subred (cláusula 10 del estándar 802 del IEEE) que encapsula tramas Ethernet sobre LLC, y comprende la cabecera SNAP (hexadecimal AA-AA-03) seguida por el SNAP PID (hexadecimal 00-00-00) seguido por el EtherType del protocolo (hexadecimal xx-xx).

Estructura y codificación de las DRCPDU

Transmisión y representación de octetos

Todas las DRCPDU comprenden un número entero de octetos. Los bits de cada octeto están numerados de 0 a 7, siendo 0 el bit de orden menor. Cuando se usan octetos consecutivos para representan un valor numérico, el octeto más significativo se tramite primero, seguido por octetos sucesivamente menos significativos.

Cuando en un diagrama se representa la codificación de (un elemento de) una DRCPDU:

A) Los octetos son transmitidos de arriba abajo.

B) Dentro de un octeto, los bits son mostrados con el bit 0 a la izquierda y el bit 7 a la derecha, y son transmitidos de izquierda a derecha.

C) Cuando se usan octetos consecutivos para representar un número binario, el octeto transmitido primero tiene el valor más significativo.

D) Cuando se usan octetos consecutivos para representar una dirección MAC, al bit menos significativo del primer octeto se le asigna el valor del primer bit de la dirección MAC, al siguiente bit más significativo el valor del segundo bit de la dirección MAC, y así sucesivamente hasta el octavo bit. De modo similar, a los bits del menos significativo al más significativo del segundo octeto se les asigna el valor de los bits noveno a decimoséptimo de la dirección MAC, y así sucesivamente para todos los octetos de la dirección MAC.

Encapsulación de las DRCPDU en tramas

Hay una DRCPDU codificada en el parámetro mac_service_data_unit de una M_UNITDATA.request o una M_UNITDATA.indication en una realización. Los primeros octetos del parámetro mac_service_data_unit son un identificador de protocolo, seguido por la DRCPDU, seguida por octetos de relleno, si los hay, según requiera el servicio MAC subyacente.

802.3) , el identificador de protocolo tiene dos octetos de longitud, y el valor es el EtherType del protocolo (hexadecimal xx-xx).

Cuando la instancia de ISS es proporcionada por un método de acceso al medio que no pueda soportar directamente la codificación EtherType (que sea, por ejemplo, un MAC IEEE 802.11), el TPID es codificado según la regla para un protocolo de acceso a subred (cláusula 10 del estándar 802 del IEEE) que encapsula tramas Ethernet sobre LLC, y comprende la cabecera SNAP (hexadecimal AA-AA-03) seguida por el SNAP PID (hexadecimal 00-00

00) y el EtherType (hexadecimal xx-xx).

Estructura de la DRCPDU

La Figura 5 ilustra una realización de la estructura de la DRCPDU según la invención. Los campos se definen como sigue:

5

10

15

20

25

30

35

40

45

50

A) Subtype (Subtipo). El campo Subtype identifica el protocolo lento específico que se encapsula. Las DRCPDU llevan el valor de Subtipo 0x0X. Nota: A) puede no estar presente si la elección no es el uso del EtherType de protocolo lento para identificar la operación de DCRP.

B) Version_Number (Número de versión). Este identifica la versión de DRCP; las implementaciones según una realización llevan el valor 0x01.

C) TLV_type (Tipo de TLV) = Información del portal. Este campo indica la naturaleza de la información contenida en esta tupla de tLv. La información de DRNI es identificada por el valor 0x01 en una realización.

D) Portal_Information_Length (Longitud de la información del portal). Este campo indica la longitud (en octetos) de esta tupla de TLV. La información de actor usa un valor de longitud de 18 (0x12) en una realización.

E) Aggregator_Priority (Prioridad de agregador). La prioridad asignada al ID de sistema del actor (por las directrices de gestión o administración) del agregador unido a la función de DR, codificada como un entero sin signo a partir de aAggActorSystemPriority en una realización.

F) Aggregator_ID (ID de agregador). La componente de dirección MAC del ID de sistema del actor del agregador unido a la función de DR a partir de a en una realización.

G) Portal_Priority (Prioridad del portal). La prioridad asignada al ID del portal (por las directrices de gestión o administración), codificada como un entero sin signo a partir de aDrniPortalPriority en una realización.

H) Portal_ID (ID de portal). La componente de dirección MAC de los ID de portal a partir de aDrniPortalId en una realización.

I) TLV_type (Tipo de TLV) = Información de la configuración del portal. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. La información de configuración del portal es identificada por el valor 0x02 en una realización.

J) Portal_Configuration_Information_Length (Longitud de la información de configuración del portal). Este campo indica la longitud (en octetos) de esta tupla de TLV. La información de configuración del portal usa un valor de longitud de 46 (0x2E) en una realización.

K) Topology_State (Estado de la topología). Las variables para el IPP relativas a la topología de esta función de DR, codificadas como bits individuales dentro de un único octeto, como sigue y según se ilustra en la Figura 6C:

1) Portal_System_Number (Número del sistema de portal) está codificado en los bits 0 y 1. Es el número del sistema de portal de esta función de DR a partir de aDrniPortalSystemNumber.

2) Portal_Topology (Topología de portal) está codificado en los bits 2 y 3. Es la topología de portales de esta función de DR configurada en aDrniPortalTopology.

3) Neighbor_Conf_Portal_System_Number (Número de sistema del portal de configuración del vecino) está codificado en los bits 4 y 5. Es el número de sistema de portal del sistema de portal que está conectado a este IPP.

4) Loop_Break_Link (Enlace de ruptura de bucle) está codificado en el bit 6. Esta bandera indica que el IPL conectado a este IPP está configurado como un enlace ruptura de bucle. TRUE indica que el IPL está configurado en aDrniLoopBreakLink y está codificado como un 1; si no, la bandera es codificada como un 0.

5) El bit 7 está reservado para un uso futuro. Es puesto a 0 para transmitir y es ignorado cuando se recibe.

K2) Topology_State (Estado de la topología). En una realización alternativa, el estado de la topología puede ser codificado en un octeto diferente, como sigue y según se ilustra en la Figura 29.

1) Portal_System_Number (Número del sistema de portal) está codificado en los bits 0 y 1. El número de sistema de portal de esta función de DR a partir de aDrniPortalSystemNumber en una realización.

2) Neighbor_Conf_Portal_System_Number (Número de sistema del portal de configuración del vecino) está codificado en los bits 2 y 3. El número configurado de sistema de portal del sistema de portal que está conectado a este IPP en una realización.

3) Los bits 4 a 6 están reservados para un uso futuro. Están puestos a 0 al transmitir y son ignorados cuando se reciben en una realización.

4) Other_Non_Neighbor (Otro no vecino) está codificado en el bit 7. TRUE (codificado como 1) indica que el TLV de información de otros puertos no está asociado con un vecino inmediato de este sistema de portal. fAlSE (codificado como 0) indica que el TLV de información de otros puertos es un vecino inmediato por el otro IPP en este sistema de portal en una realización.

5

10

15

20

25

30

35

40

45

50

L) Oper_Aggregator_Key (Clave de agregador operativo). El valor actual de la clave de agregador operativo del agregador unido a la función de DR.

M) Port_Algorithm (Algoritmo de puerto). El algoritmo de puerto usado por esta función de DR y agregador a partir de aAggPortAlgorithm en una realización.

N) Gateway_Algorthm (Algoritmo de pasarela). El algoritmo de pasarela usado por esta función de DR a partir de aDrniGatewayAlgorithm en una realización.

O) Port_Digest (Compendio de puertos). Un compendio de las asignaciones priorizadas de ID de conversación de puerto a puerto de agregación de esta función de DR a partir de aAggConversationAdminPort[] en una realización.

P) Gateway_Digest (Compendio de pasarelas). Un compendio de las asignaciones priorizadas de ID de conversación de pasarela a pasarela de esta función de DR a partir de aDrniConvAdminGateway[] en una realización.

Q) TLV_type (Tipo de TLV) = Estado del DRCP. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. El estado del DRCP es identificado por el valor 0x03 en una realización.

R) DRCP_State_Length (Longitud del estado del DRCP). Este campo indica la longitud (en octetos) de esta tupla de TLV. El estado del DRCP usa un valor de longitud de 3 (0x03) en una realización.

S) DRCP_State (Estado del DRCP). Variables de DRCP para el IPP de esta función de DR, codificadas como bits individuales dentro de un único octeto, como sigue y según se ilustra en la Figura 6B:

1) Home_Gateway (Pasarela propia). En una realización, está codificado en el bit 0. Esta bandera indica el estado operativo de la pasarela de esta función de DR. TRUE indica operativo y está codificado como un 1, y no operativo está codificado como un 0.

2) Neighbor_Gateway (Pasarela vecina) está codificado en el bit 1 en una realización. Esta bandera indica el estado operativo de la pasarela de la función de DR del vecino. TRUE indica operativo y está codificado como un 1, y no operativo está codificado como un 0.

3) Other_Gateway (Pasarela de otro) está codificado en el bit 2 en una realización. Esta bandera indica el estado operativo de una pasarela potencial de la función de DR de otro. TRUE indica operativo y está codificado como un 1, y no operativo está codificado como un 0.

4) IPP_Activity (Actividad del IPP) está codificado en el bit 3 en una realización. Esta bandera indica la actividad del DRCP del vecino en este IPP. El vecino de DRCPP activo está codificado como un 1 y la falta de actividad de DRCP es codificada como un 0.

5) DRCP_Timeout (Tiempo de espera de DRCP) está codificado en el bit 4 en una realización. Esta bandera indica el valor de control del tiempo de espera con respecto a este enlace. El tiempo de espera corto está codificado como un 1 y el tiempo de espera largo está codificado como un 0.

6) Gateway_Sync (Sincronización de pasarelas) está codificado en el bit 5 en una realización. Si TRUE (codificado como un 1), esta función de DR considera que los sistemas socios vecinos de este IPP tienen sus pasarelas IN_SYNC; es decir, el vector operativo de este sistema de portal que enumera qué pasarela del sistema de portal (si la hay) está dejando pasar cada ID de conversación de pasarela está de acuerdo con el vector operativo de los vecinos de este IPP. Si FALSE (codificado como un 0), entonces este IPP está actualmente OUT_OF_SYNC; es decir, el vector operativo de los vecinos de este IPP que enumera qué pasarela del sistema de portal (si la hay) está dejando pasar cada ID de conversación de pasarela está en desacuerdo.

7) Port_Sync (Sincronización de puertos) está codificado en el bit 6. Si TRUE (codificado como un 1), esta función de DR considera que los sistemas socios vecinos de este IPP tienen sus puertos agregadores IN_SYNC; es decir, el vector operativo de este sistema de portal que enumera qué puerto de agregación del sistema de portal (si lo hay) está dejando pasar cada ID de conversación de puerto está de acuerdo con el vector operativo de los vecinos de este IPP. Si FALSE (codificado como un 0), entonces este IPP está actualmente OUT_OF_SYNC; es decir, el vector operativo de los vecinos de este IPP que enumera qué puerto de agregación del sistema de portal (si lo hay) está dejando pasar cada ID de conversación de puerto está en desacuerdo.

8) Expired (Expirado) está codificado en el bit 7. Si TRUE (codificado como un 1), esta bandera indica que la máquina de recepción de la función de DR está en el estado EXPIRED o DEFAULTED (por omisión); si FALSE (codificado como un 0), esta bandera indica que la máquina de recepción de la función de DR no está en el estado EXPIRED o DEFAULTED.

Los valores recibidos del estado Expired no son usados por el DRCP; sin embargo, saber sus valores puede ser útil cuando se diagnostican problemas de protocolo. Obsérvese también que el orden de los campos y la longitud de los

5

10

15

20

25

30

35

40

45

50

campos pueden ser diferentes en una realización diferente, pero se sigue acatando el espíritu de la presente invención.

T) TLV_type (Tipo de TLV) = Información de los puertos propios. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. La información de los puertos propios es identificada por el valor entero 0x04 en una realización.

U) Home_Ports_Information_Length (Longitud de la información de los puertos propios). Este campo indica la longitud (en octetos) de esta tupla de TLV. La información de los puertos propios usa un valor de longitud de 4 veces el número de puertos de agregación de este sistema de portal que estén incluidos.

V) Home_Admin_Aggregator_Key (Clave de agregador administrativo propio). El valor de la clave de agregador administrativo del agregador unido a esta función de DR a partir de aAggActorAdminKey.

W) Home_Oper_Partner_Aggregator_Key (Clave de agregador de socio operativo propio). La clave de agregador de socio operativo asociada con el ID LAG del agregador de este sistema de portal.

X) Active_Home_Ports (Puertos propios activos). La lista de puertos de agregación activos en orden creciente de número de puerto. La lista está controlada por la operación del LACP (enumerar todos los puertos de este sistema de portal para los que el LACP declare Actor_Oper_Port_State.Distributing = TRUE).

Y) TLV_type (Tipo de TLV) = Información de los puertos de vecinos. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. La información de los puertos de vecinos es identificada por el valor entero 0x05.

Z) Neighbor_Ports_Information_Length (Longitud de la información de los puertos de vecinos). Este campo indica la longitud (en octetos) de esta tupla de TLV. La información de los puertos de vecinos usa un valor de longitud de 4 veces el número de puertos de agregación vecinos que estén incluidos.

Aa) Neighbor_Admin_Aggregator_Key (Clave de agregador administrativo vecino). El valor de la clave de agregador administrativo del agregador unido al sistema de portal vecino.

Ab) Neighbor_Oper_Partner_Aggregator_Key (Clave de agregador del socio operativo vecino). La clave de agregador socio operativo asociada con el ID LAG del agregador del sistema de portal vecino.

Ac) Active_Neighbor_Ports (Puertos vecinos activos). La lista de puertos de agregación activos en orden creciente de número de puerto. La lista está controlada por la operación del LACP (enumerar todos los puertos del sistema vecino inmediato de portal para los que el LACP declare Actor_Oper_Port_State.Distributing = TRUE).

Ad) TLV_type (Tipo de TLV) = Información de otros puertos. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. La información de otros puertos es identificada por el valor entero 0x06. Este TLV es usado únicamente si la topología de portales contiene tres sistemas de portal.

Ae) Other_Ports_Information_Length (Longitud de la información de puertos de otro). Este campo indica la longitud (en octetos) de esta tupla de TLV. La información de otros puertos usa un valor de longitud de 4 veces el número de puertos de agregación de otro sistema de portal que estén incluidos.

Af) Other_Admin_Aggregator_Key (Clave de agregador administrativo de otro). El valor de la clave de agregador administrativo del agregador conectado al sistema de portal del otro vecino.

Ag) Other_Oper_Partner_Aggregator_Key (Clave de agregador del socio operativo de otro). La clave de agregador socio operativo asociada con el ID LAG del agregador del sistema de portal de otro vecino.

Ah) Active_Other_Ports (Puertos activos de otro). La lista de puertos de agregación activos en orden creciente de número de puerto. La lista está controlada por la operación del LACP (enumerar todos los puertos del sistema de portal de otro opcional para los que el LACP declare Actor_Oper_Port_State.Distributing = TRUE).

Ai) TLV_type (Tipo de TLV) = Información de otro. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. La información de otro es identificada por el valor entero 0x0x en una realización.

Aj) TLV_type (Tipo de TLV) = Terminador. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. La información de terminador (fin de mensaje) es identificada por el valor entero 0x00 en una realización.

Ak) Terminator_Length (Longitud del terminador). Este campo indica la longitud (en octetos) de esta tupla de TLV. La información de terminador usa un valor de longitud de 0 (0x00) en una realización.

Obsérvese que el uso de una Terminator_Length de 0 es intencional. En esquemas de codificación de TLV es práctica común que la codificación de terminador sea 0, tanto para el tipo como para la longitud.

5

10

15

20

25

30

35

Obsérvese también que está garantizado que la implementación de la versión 1 podrá recibir con éxito las PDU de versión N, aunque las PDU de la versión N puedan contener información adicional que no puede ser interpretada (y será ignorada) por la versión 1. En factor crucial para garantizar la retrocompatibilidad es que se requiere que cualquier versión futura del protocolo no redefina la estructura ni la semántica de la información definida para la versión previa; solo puede añadir al conjunto anterior elementos de información nuevos. Por ende, en una PDU de versión N, una implementación de la versión 1 puede esperar encontrar la información de la versión 1 en exactamente los mismos lugares que en una PDU de la versión 1, y puede esperar interpretar esa información según se define para la versión 1.

Obsérvese que la DRCPDU aumenta de tamaño con el número de puertos de agregación. Se soporta un máximo de (1500 - 88) / 4 = 353 puertos de agregación dispersos por los sistemas de portal de un portal. El número mínimo de puertos de agregación que precisa estar soportado por un portal es dos.

La siguiente tabla proporciona una lista de los TLV que son aplicables para el DRCP.

Tabla 4. Valores del campo de tipo de los TLV del DRCP

TLV: Campo de tipo

TLV de terminador: 0x00

TLV de información de portal: 0x01

TLV de información de configuración del portal: 0x02

TLV de estado de DRCP: 0x03

TLV de información de puertos propios: 0x04

TLV de información de puertos de vecinos: 0x05

TLV de puertos de otros: 0x06

TLV del método de compartición de red/IPL: 0x07

TLV de encapsulación de compartición de red/IPL: 0x08

Reservado para IEEE 802.1: 0x09 - 0x0E

TLV específico a una organización: 0x0F

Reservado para IEEE 802.1: 0x10 - 0xFF

Así, las realizaciones proporcionan encapsulación de las DRCPDU en tramas, comprendiendo cada DRCPDU un campo que indica el estado del DRCP, tal como variables de DRCP para un IPP. El campo puede ser de un solo octeto. El campo puede incluir, además, codificada en los diferentes bits del octeto, información que especifica uno o más de los siguientes: Home_Gateway; Neighbor_Gateway; Other_Gateway; IPP_Activity; DRCP_Timeout; Gateway_Sync; Port_Sync; Expired.

La Figura 14 ilustra otra realización de la estructura de las DRCPDU según la invención. Aunque la estructura de la DRCPDU de la Figura 14 es similar a la de la Figura 5, varios campos son diferentes. Por ejemplo, el campo Home_Ports_Information_Length es 2 + 4 * PN en la Figura 14, no 2 + 2 * PN como en la Figura 5. De modo similar, varios campos más de la estructura DRCPDU en la Figura 14 contienen longitudes diferentes de las de la estructura DRCPDU en la Figura 5, y las dos estructuras DRCPDU también contienen campos no presentes en la otra realización. En cada estructura DRCPDU ejemplar, los campos tienen nombres descriptivos del contenido de los campos. Algunos de los distintos campos contienen información similar, pero han sido renombrados o reorganizados. Un experto en la técnica entendería que son posibles otras estructuras DRCPDU similares coherentes con los principios y las estructuras descritos en la presente memoria.

La Figura 25 ilustra otra realización de la estructura DRCPDU según la invención. La estructura DRCPDU de la Figura 25 es similar a la de las Figuras 5 y 14 con varias diferencias. Por ejemplo, las longitudes de información de puertos (para los puertos propios, de vecinos y de otros) son diferentes. Además, la estructura DRCPDU de la Figura 25 incluye un estado de la topología, y varios campos para claves de agregador, tales como Oper_Aggregator_Key, Home_Admin_Aggregator_Key, Home_Oper_Partner_Aggregator_Key,

Neighbor_Admin_Aggregator_Key, Other_Admin_Aggregator_Key y Other_Oper_Partner_Aggregator_Key, expuestas anteriormente en la presente memoria.

La Figura 32 ilustra un método de comunicación a través de una trama que incluye la estructura DRCPDU según una realización de la invención. El método 3200 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C.

5

10

15

20

25

30

35

40

45

50

55

En 3202, un nodo de DRCP de un portal encapsula una DRCPDU en una trama. La DRCPDU incluye una estructura que incluye (1) un campo de tipo (denominado subtipo) que indica que la PDU es para DRCP, (2) un campo de versión que indica el número de versión de la DRCPDU, y (3) un conjunto de varios TLV. En conjunto de los TLV incluye un TLV de terminador, un TLV de información de portal, un TLV de configuración de portal, un TLV de estado de DRCP, un TLV de información de puertos propios y un TLV de información de puertos de vecinos. Cuando un portal incluye más de dos nodos, la estructura de la PDU puede incluir otro TLV de puertos en una realización.

En una realización, el conjunto de los TLV incluye, además, al menos uno del TLV del método de compartición de red/IPL, TLV de encapsulación de compartición de red/IPL, uno o más TLV reservados para IEEE 802.1, y TLV específicos a una organización, exponiéndose cada TLV en la presente memoria.

Cada uno del conjunto de los TLV incluye un campo de tipo de TLV. En una realización, el campo de tipo de TLV de cada uno incluye valores especificados en la Tabla 4 ilustrada más arriba. Cada uno de los TLV incluye campos que pueden configurarse en los valores expuestos anteriormente en la presente memoria. Por ejemplo:

• El TLV de terminador indica el fin de la estructura PDU. En una realización, incluye un campo de tipo de TLV y un campo de longitud de terminador, indicando el campo de longitud de terminador una longitud de cero, según se ha expuesto anteriormente en la presente memoria.

• El TLV de información de portal indica características del portal al que pertenece el nodo de DRCP. En una realización, las características están indicadas en (1) un campo de prioridad de agregador que indica una prioridad asignada al agregador del nodo, (2) un campo identificador (ID) de agregador que indica un ID del agregador, (3) un campo de prioridad del portal que indica una prioridad asignada al portal, y (4) un campo de dirección del portal que indica una componente de dirección MAC asociada con el dispositivo de red, según se ha expuesto anteriormente en la presente memoria.

• El TLV de información de configuración del portal indica información de configuración del portal al que pertenece el nodo de DRCP. En una realización, la información de configuración está indicada en (1) un campo de estado de topología que indica un estado de la topología del portal tal como se ilustra en las Figuras 6C y 29, (2) un campo de la clave de agregador operativo que indica una clave de agregador operativo del nodo, (3) un campo de algoritmo de portal que indica el algoritmo de portal usado, (4) un campo de algoritmo de pasarela que indica un algoritmo de pasarela usado, (5) un campo de compendio de puertos que indica un compendio de puertos usado para el identificador (ID) de conversación de puerto a la asignación de puertos de agregación, y (6) un campo de compendio de pasarelas que indica un compendio de pasarelas usado para el ID de conversación de pasarela a la asignación de pasarelas, según se ha expuesto anteriormente en la presente memoria.

• El TLV de estado de DRCP indica variables asociadas con el IPP. En una realización, el estado del DRCP incluye valores codificados ilustrados en la Figura 6B, según se ha expuesto anteriormente en la presente memoria.

• El TLV de información de puertos propios indica el estado actual del nodo en asociación con el nodo de DRCP. En una realización, el estado actual del nodo está indicado en (1) un campo de clave de agregador administrativo que indica un valor de clave de agregador administrativo del agregador conectado, (2) un campo de clave de agregador de socio operativo que indica una clave de agregador de socio operativo asociada con el ID LAG del agregador del nodo, (3) un campo de puertos de agregación activos que indica una lista de puertos de agregación activos en el nodo, según se ha expuesto anteriormente en la presente memoria.

• El TLV de información de puertos de vecinos indica el estado actual del nodo vecino en asociación con la DRNI. En una realización, el estado actual del nodo vecino está indicado en (1) un campo de clave de agregador administrativo que indica un valor de clave de agregador administrativo del agregador conectado al dispositivo de red vecino, (2) un campo de clave de agregador de socio operativo que indica una clave de agregador de socio operativo asociado con el ID LAG del agregador del nodo vecino, y (3) un campo de puertos de agregación activos que indica una lista de puertos de agregación activos en un sistema de portal de vecino inmediato asociado con el IPP, según se ha expuesto anteriormente en la presente memoria.

• El TLV de información de puertos de otros indica el estado actual del nodo vecino de otros asociado con la DRNI cuando el portal local incluye más de dos nodos. En una realización, el estado actual del nodo vecino de otros está indicado en (1) un campo de clave de agregador administrativo que indica un valor de clave de agregador administrativo del agregador conectado al nodo de otros, (2) un campo de clave de agregador de socio operativo que indica una clave de agregador de socio operativo asociado con el ID LAG del agregador del nodo vecino del otro, y (3) una lista de puertos de agregación activos en el nodo vecino de otros en el IPP, según se ha expuesto anteriormente en la presente memoria.

• El TLV del método de compartición de red/IPL indica un método de compartición de red e IPL asociado con el nodo; y •

• El TLV de encapsulación de compartición de red/IPL indica información relativa a la encapsulación del método de compartición.

En 3206, el nodo de DRCP envía la trama a su nodo vecino del portal a través del IPP, usando el nodo vecino la información encapsulada para controlar el envío de tramas.

Según se ha expuesto anteriormente en la presente memoria, a través del método 3200, el nodo intercambia información con su nodo vecino y así establece y habilita las operaciones de DRCP del portal. El método 3200 5 proporciona una manera eficaz para que el nodo intercambie información con su nodo vecino.

TLVde compartición de red/IPL

Estos TLV son requeridos únicamente cuando el método de compartición de red/IPL usado es uno de la compartición de red/IPL por etiqueta, o la compartición de red/IPL por encapsulación para garantizar una configuración coherente entre los sistemas de portal. El método de compartición de red/IPL por tiempo requiere el 10 intercambio del TLV del método de compartición de red/IPL, pero no el TLV de encapsulación de compartición de red/IPL.

NOTA: No se requiere ningún TLV de compartición de red/IPL cuando el método de compartición de red/IPL usado es el método físico o agregado expuesto en la presente memoria.

La siguiente tabla proporciona una lista de los TLV que son aplicables para métodos de compartición de red/IPL.

15

Tabla 5. Valores del campo de tipo de los TLV de compartición de red/IPL

TLV: Campo de tipo

TLV del método de compartición de red/IPL: 0x07

TLV de encapsulación de compartición de red/IPL: 0x08

TLV del método de compartición de red/IPL

La estructura del TLV del método de compartición de red/IPL puede ser mostrada como la tabla siguiente y es descrita adicionalmente en las siguientes definiciones de campos:

20

Tabla 6. TLV del método de compartición de red/IPL

TLV: Longitud (Octetos)

TLV_type = Método de compartición de red/IPL: 1

Network/IPL_Sharing_Method_Length = 6: 1

DRF_Home_Network/IPL_Sharing_Method: 4

TLV_type = TLV del método de compartición de red/IPL. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. El TLV de compartición de red/IPL está identificado por el valor entero 0x07.

Network/IPL_Sharing_Method_Length. Este campo indica la longitud (en octetos) de esta tupla de TLV. El TLV de 25 compartición de red/IPL usa un valor de longitud de 6 (0x06). DRF_Home_Network/IPL_Sharing_Method. Este campo contiene el valor que representa el método de compartición de red/IPL que es usado para transportar tramas IPL al sistema de portal vecino por este IPP cuando el IPL y el enlace de red comparten el mismo enlace físico. Consiste en el identificador único de organización (OUI), de tres octetos, que identifica la organización que es responsable de esta encapsulación y en un octeto adicional usado para identificar el método de encapsulación 30 definido por esa organización. Configurado siempre igual que aDrniEncapsulationMethod. Un valor de 1 indica que se usa la compartición de red/IPL por tiempo. Un valor de 2 indica que el método de encapsulación usado es el mismo que el usado por las tramas de red y que se usa la compartición de red/IPL por etiqueta. La siguiente tabla proporciona las codificaciones del método de encapsulación IEEE OUI (01-80-C2).

5

10

15

20

25

30

Tabla 7. Métodos de encapsulación IEEE

Campo de método de encapsulación: Valor

El IPL está usando un enlace físico o de agregación separado: 0

Compartición de red/IPL por tiempo: 1

Compartición de red/IPL por etiqueta: 2

Encapsulación basada en IEEE802.1Q I-TAG: 3

Encapsulación basada en IEEE802.1Q B-VLAN: 4

Encapsulación basada en pseudohilos IETF: 5

Reservado: 6-255

TLVde encapsulación de compartición de red/IPL

La estructura del TLV de encapsulación de compartición de red/IPL puede ser según se muestra a continuación y según se describe adicionalmente en las siguientes definiciones de campos.

Tabla 8. TLV de encapsulación de compartición de red/IPL

TLV: Longitud (Octetos)

TLV_type = Encapsulación de compartición de red/IPL: 1

Network/IPL_Sharing_Encapsulation_Length = 34: 1

DRF_Home_Network/IPL_IPLEncap_Digest: 16

DRF_Home_Network/IPL_NetEncap_Digest: 16

TLV_type = TLV de encapsulación de compartición de red/IPL. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. El TLV de compartición de red/IPL está identificado por el valor entero 0x08.

Network/IPL_Sharing_Encapsulation_Length. Este campo indica la longitud (en octetos) de esta tupla de TLV. El TLV de compartición de red/IPL usa un valor de longitud de 34 (0x22).

DRF_Home_Network/IPL_IPLEncap_Digest. Este campo contiene el valor del compendio MD5 calculado a partir de aDrniIPLEncapMap para el intercambio con el sistema de portal vecino por el IPL.

DRF_Home_Network/IPL_NetEncap_Digest. Este campo contiene el valor del compendio MD5 calculado a partir de aDrniNetEncapMap para el intercambio en el enlace de red compartido.

DrniEncapsulationMethod

ATRIBUTO

SINTAXIS APROPIADA

UNA SECUENCIA DE OCTETOS consistente en un identificador único de organización (OUI) y un octeto adicional.

COMPORTAMIENTO DEFINIDO COMO: Este objeto gestionado es aplicable únicamente cuando está soportada la compartición de red/IPL por tiempo, la compartición de red/IPL por etiqueta o la compartición de red/IPL por encapsulación. El objeto identifica el valor que representa el método de encapsulación que se usa para transportar tramas IPL al sistema de portal vecino cuando el IPL y el enlace de red están compartiendo el mismo enlace físico. Consiste en el identificador único de organización (OUI), de tres octetos, que identifica la organización que es responsable de esta encapsulación y en un octeto adicional usado para identificar el método de encapsulación definido por esa organización. La tabla sobre métodos de encapsulación IEEE proporciona las codificaciones del método de encapsulación IEEE OUI (01-80-C2). Un valor por defecto de 0x01 - 80-C2-00 indica que el IPL está usando un enlace físico o de agregación separado. Un valor de 1 indica que se usa la compartición de red/IPL por tiempo. Un valor de 2 indica que el método de encapsulación usado es el mismo que el usado por las tramas de red y que se usa la compartición de red/IPL por etiqueta.

DrniIPLEncapMap

ATRIBUTO

SINTAXIS APROPIADA

5

10

15

20

25

30

35

40

45

UNA SECUENCIA DE ENTEROS, indexada por el ID de conversación de pasarela.

COMPORTAMIENTO DEFINIDO COMO: Este objeto gestionado es aplicable únicamente cuando está soportada la compartición de red/IPL por etiqueta o la compartición de red/IPL por encapsulación. Cada anotación representa el valor del identificador usado para una trama de IPL asociada con ese ID de conversación de pasarela para el método de encapsulación especificado en la presente memoria.

aDrniNetEncapMap

ATRIBUTO

SINTAXIS APROPIADA

UNA SECUENCIA DE ENTEROS, indexada por el ID de conversación de pasarela.

COMPORTAMIENTO DEFINIDO COMO: Este objeto gestionado es aplicable únicamente cuando está soportada la compartición de red/IPL por etiqueta. Cada anotación representa el valor traducido del identificador usado para una trama de red asociada con ese ID de conversación de pasarela cuando el método especificado en la presente memoria es el método de compartición de red/IPL por etiqueta especificado en la presente memoria y las tramas de red necesitan compartir el espacio de etiqueta usado por las tramas IPL.

aAggPortAlgorithm

ATRIBUTO

SINTAXIS APROPIADA

UNA SECUENCIA DE OCTETOS consistente en un identificador único de organización (OUI), de tres octetos, y un octeto adicional.

COMPORTAMIENTO DEFINIDO COMO: Este objeto identifica el algoritmo usado por el agregador para asignar tramas a un ID de conversación de puerto.

aAggActorSystemID

ATRIBUTO

SINTAXIS APROPIADA MACAddress

COMPORTAMIENTO DEFINIDO COMO: Un valor de dirección MAC de lectura-escritura de 6 octetos usado como identificador único para el sistema que contiene este agregador.

Nota: Desde la perspectiva de los mecanismos de agregación de enlaces descritos en la Cláusula 6, solo se considera una única combinación de ID de sistema del actor y prioridad de sistema, y no se hace ninguna distinción entre los valores de estos parámetros para un agregador y el puerto o los puertos de agregación que estén asociados con él (es decir, el protocolo está descrito en términos de la operación de agregación dentro de un único sistema). Sin embargo, los objetos gestionados proporcionados para el agregador y el puerto de agregación permiten ambos la gestión de estos parámetros. El resultado de esto es permitir que se configure un solo equipo mediante la gestión para que contenga más de un sistema desde el punto de vista de la operación de la agregación de enlaces. Esto puede ser de uso particular en la configuración de equipos que tienen una capacidad de agregación limitada.

aAggActorSystemPriority

ATRIBUTO

SINTAXIS APROPIADA ENTERO

COMPORTAMIENTO DEFINIDO COMO: Un valor de lectura-escritura de 2 octetos que indica el valor de prioridad asociado con el ID de sistema del actor.

TLVespecífico a una organización

Cualquier organización puede definir los TLV para ser usados en DRCP. Se proporcionan estos TLV para permitir que diferentes organizaciones, tales como IEEe 802.1, ITU-T, IETF, así como vendedores individuales de soporte lógico y equipos, definan los TLV que anuncian información a sistemas de portal vecinos. La estructura del TLV

5

10

15

20

25

30

35

40

45

específico a una organización será como se muestra en la siguiente tabla y según se describe, además, en las siguientes definiciones de campos.

1

3

7

LL-12....

TLV_type = TLV específico a una organización. Este campo indica la naturaleza de la información contenida en esta tupla de TLV. El TLV específico a una organización está identificado por el valor entero 0x0F.

Network/IPL_Sharing_Encapsulation_Length. Este campo indica la longitud (en octetos) de esta tupla de TLV. El TLV específico a una organización usa un valor de longitud de LL.

OUI. Este campo contiene el identificador único a la organización, de 3 bytes de longitud, obtenible del IEEE.

Subtipo. Este campo contiene un valor de subtipo, para que no se requiera un OUI adicional si el propietario de un OUI requiere más TLV específicos a una organización.

Valor. Este campo contiene la información que precisa ser comunicada a los sistemas de portal vecinos.

Visión general de las máquinas de estado de DRCP

La operación del protocolo es controlada por varias máquinas de estado, cada una de las cuales lleva a cabo una función distinta. Estas máquinas de estado son descritas en su mayor parte por cada IPP; en el texto se destaca cualquier desviación de la descripción por puerto de agregación. Los acontecimientos (tales como el vencimiento de un temporizador o de las DRCPDU recibidas) pueden causar transiciones de estado y también provocar que se emprendan acciones; esas acciones pueden incluir la necesidad de la transmisión de una DRCPDU que contenga información repetida o nueva. Las transmisiones periódicas y desencadenadas por eventos son controladas por el estado de una variable Need-To-Transmit (NTT, necesario transmitir) variable, generada por las máquinas de estado según sea necesario.

Las máquinas de estado son como sigue:

A) Máquina de recepción (véase la Figura 8). Esta máquina de estado recibe las DRCPDU del sistema de portal vecino por este IPP, registra la información contenida y determina su expiración, usando bien tiempos de espera cortos o bien tiempos de espera largos, según la configuración de DRCP_Timeout. Evalúa la información entrante procedente del sistema de portal vecino para determinar si tanto el propio como el vecino han acordado la información de protocolo intercambiada hasta el punto de que el sistema de portal propio pueda ser usado ahora con seguridad, ya sea en un portal con otros sistemas de portal o como un portal individual; si no, afirma NTT para transmitir información de protocolo nueva al sistema de portal vecino. Si expira la información de protocolo procedente de los sistemas de portal vecinos, la máquina de recepción instala valores de parámetros por defecto para ser usados por las otras máquinas de estado.

B) Máquina de transmisión periódica (PTS: véase la Figura 9). Esta máquina de estado determina el periodo que el sistema de portal propio y sus vecinos intercambiarán unas DRCPDU para mantener el portal.

C) Máquina de sistema de portal (PS: véase la Figura 10). Esta máquina de estado es responsable de actualizar el estado operativo de todas las pasarelas y los puertos de agregación en el portal en función de información local y de las DRCPDU recibidas por los IPP del sistema de portal propio. Esta máquina de estado es por cada sistema de portal.

D) Máquinas de DRNI de pasarela y de agregador (DGA: véase la Figura 11). Estas máquinas de estado son responsables de configurar los ID de conversación de pasarela a los que se permite atravesar esta pasarela de función de DR y los ID de conversación de puerto a los que se permite que se distribuyan a través del agregador de esta función de DR. Estas máquinas de estado son por cada sistema de portal.

E) Máquina de IPP de DRNI (IPP: véase la Figura 12). Estas máquinas de estado son responsables de configurar los ID de conversación de pasarela y los ID de conversación de puerto a los que se permite atravesar los IPP de esta función de DR.

F) Máquina de transmisión (TX: véase la subsección Máquina de transmisión posteriormente en la presente memoria). Esta máquina de estado gestiona la transmisión de las DRCPDU, tanto a petición de otras máquinas de estado, como de forma periódica.

TLV_type = Específico a una organización Organization_Specific_Length = LL OUI Subtipo

Valor (Opcional)

5

10

15

20

25

30

35

40

45

La Figura 7 ilustra las relaciones entre estas máquinas de estado y el flujo de información entre ellas según una realización de la invención. El conjunto de flechas etiquetado Información de estado del vecino representa nueva información del vecino, contenida en una DRCPDU entrante o suministrada mediante valores administrativos por defecto, que son suministrados a cada máquina de estado por la máquina de recepción. El conjunto de flechas etiquetado Información de estado propio representa el flujo de información de estado propio actualizada entre las máquinas de estado. La transmisión de las DRCPDU se produce ya sea como resultado de que la máquina periódica determine la necesidad de transmitir una DRCPDU periódica, o como resultado de cambios a la información de estado propio que precisa ser comunicada a los vecinos. La necesidad de transmitir una DRCPDU es señalada a la máquina de transmisión afirmando NTT. Las flechas restantes representan variables compartidas en la descripción de las máquinas de estado que permiten que una máquina de estado provoque que ocurran acontecimientos en otra máquina de estado.

La Figura 15 ilustra las relaciones entre estas máquinas de estado y el flujo de información entre ellas según otra realización de la invención. La realización alternativa opera de forma similar según los principios y las estructuras descritos en la presente memoria e ilustrados en el diagrama de la Figura 15. Así, la descripción de aplica de forma general a ambas realizaciones, salvo donde se haga notar.

Estas máquinas de estado utilizan un conjunto de constantes, variables, mensajes y funciones según se detalla a continuación en la presente memoria.

Gestión para la interconexión de redes resilientes distribuidas

Atributos del retransmisor distribuido

aDrniPortalId

ATRIBUTO

SINTAXIS APROPIADA: UNA SECUENCIA DE 8 OCTETOS que coinciden con la sintaxis de una dirección MAC de 48 bits

COMPORTAMIENTO DEFINIDO COMO: Un identificador de lectura-escritura de un portal particular. aDrniPortalId tiene que ser único entre al menos todos los sistemas potenciales de portal a los que un sistema dado de portal podría conectarse por medio de un IPL. También usado como ID de sistema del actor para el sistema emulado.

DrniDescription

ATRIBUTO

SINTAXIS APROPIADA:

Una cadena imprimible, de 255 caracteres como máximo.

COMPORTAMIENTO DEFINIDO COMO: Una cadena de texto legible por seres humanos que contiene información sobre el retransmisor distribuido. Esta cadena es de solo lectura. El contenido es específico al vendedor.

aDrniName

ATRIBUTO

SINTAXIS APROPIADA:

Una cadena imprimible, de 255 caracteres como máximo.

COMPORTAMIENTO DEFINIDO COMO: Una cadena de texto legible por seres humanos que contiene un nombre localmente significativo para el retransmisor distribuido. Esta cadena es de solo lectura-escritura.

aDrniPortalAddr

ATRIBUTO

SINTAXIS APROPIADA:

UNA SECUENCIA DE 6 OCTETOS que coinciden con la sintaxis de una dirección MAC de 48 bits

COMPORTAMIENTO DEFINIDO COMO: Un identificador de lectura-escritura de un portal particular. aDrniPortalAddr tiene que ser único entre al menos todos los sistemas potenciales de portal a los que un sistema dado de portal podría conectarse por medio de un IPL. También usado como ID de sistema del actor (6.3.2) para el sistema emulado.

5

10

15

20

25

30

35

40

aDmiPortalPriority

ATRIBUTO

SINTAXIS APROPIADA:

ENTERO

COMPORTAMIENTO DEFINIDO COMO: Un valor de lectura-escritura de 2 octetos que indica el valor de prioridad asociado con el ID del portal. También usado como prioridad del sistema del actor para el sistema emulado.

aDrniPortalTopology

ATRIBUTO

SINTAXIS APROPIADA:

ENTERO

COMPORTAMIENTO DEFINIDO COMO: Un valor de lectura-escritura que indica la topología del portal. El valor 3 significa un portal de tres sistemas de portal conectados en anillo por tres enlaces intraportal, el valor 2 significa un portal de tres sistemas de portal conectados en una cadena dos por IPL, el valor 1 significa un portal de dos sistemas de portal conectados por un único IPL y el valor 0 significa un portal de un sistema de un solo portal sin ningún IPL activo. El valor por defecto es 1.

aDrniPortalSystemNumber

ATRIBUTO

SINTAXIS APROPIADA: Un número de sistema de portal, que es un entero en el intervalo de 1 a 3, ambos inclusive.

COMPORTAMIENTO DEFINIDO COMO: Un identificador de lectura-escritura de este sistema particular de portal dentro de un portal. Debe ser único entre los sistemas de portal con el mismo aDrniPortalId.

aDrniIntraPortalLinkList

ATRIBUTO

SINTAXIS APROPIADA: UNA SECUENCIA DE ENTEROS que coinciden con la sintaxis de un identificador de interfaz.

COMPORTAMIENTO DEFINIDO COMO: Lista de lectura-escritura de los enlaces intraportal asignados a este retransmisor distribuido. El número de portal de cada IPL se configura para que coincida con el número de sistema de portal del sistema de portal conectado.

aDrniLoopBreakLink

ATRIBUTO

SINTAXIS APROPIADA:

Un ENTERO que coincide con la sintaxis de un identificador de interfaz.

COMPORTAMIENTO DEFINIDO COMO: Un identificador de lectura-escritura que coincide con uno de los identificadores de interfaz de la aDrnilntraPortalLinkList. Su valor identifica la interfaz (“enlace de ruptura de bucle”) que precisa romper el bucle de datos, en el caso de un portal de tres sistemas de portal conectados en anillo, cuando todos los IPL son operativos. Este objeto gestionado es usado únicamente cuando el valor de aDrniPortalTopology es 3.

aDrniAggregator

ATRIBUTO

SINTAXIS APROPIADA: Un ENTERO que coincide con la sintaxis de un identificador de interfaz.

COMPORTAMIENTO DEFINIDO COMO: Identificador de interfaz de lectura-escritura del puerto agregador asignado a este retransmisor distribuido.

aDrniConvAdminGateway[]

ATRIBUTO

5

10

15

20

25

30

35

40

45

SINTAXIS APROPIADA: Una matriz de SECUENCIAS DE ENTEROS que coinciden con la sintaxis del número de sistema de portal.

COMPORTAMIENTO DEFINIDO COMO: Hay 4096 variables aDmiConvAdminGateway[], de

aDrniConvAdminGateway[0] a aDrniConvAdminGateway[4095], indexadas por el ID de conversación de pasarela. Cada una contiene el valor administrativo actual de la lista de prioridades de selección de pasarela para el retransmisor distribuido. Esta lista de prioridades de selección, una secuencia de enteros para cada ID de conversación de pasarela, es una lista de números de sistema de portal en el orden de preferencia, de mayor a menor, para que la correspondiente pasarela preferida del sistema de portal transporte esa conversación.

NOTA: En la medida en que el administrador de red no llegue a configurar los mismos valores para las variables aDrniConvAdminGateway[] en todas las funciones de DR of un portal, las tramas pueden ser dirigidas indebidamente. El protocolo de control de retransmisiones distribuidas (DRCP, 9.4) previene tal tipo de configuraciones indebidas.

aDrniGatewayAlgorithm

ATRIBUTO

SINTAXIS APROPIADA: UNA SECUENCIA DE OCTETOS consistente en un identificador único de organización (OUI) y uno o más octetos adicionales.

COMPORTAMIENTO DEFINIDO COMO: Este objeto identifica el algoritmo usado por la función de DR para asignar tramas de un ID de conversación de pasarela.

Constantes

La siguiente exposición se centra en diversas constantes aplicables según una realización de la invención. Todos los temporizadores especificados en esta sección tienen una tolerancia de implementación de ± 250 ms.

Fast_Periodic_Time: El número de segundos entre transmisiones periódicas usando tiempos de espera cortos. Valor: Entero; 1

Slow_Periodic_Time: El número de segundos entre transmisiones periódicas usando tiempos de espera largos. Valor: Entero; 30

Short_Timeout_Time: El número de segundos antes de invalidar la información de LACPDU recibida cuando se usan tiempos de espera cortos (3 * Fast_Periodic_Time). Valor: Entero; 3

Long_Timeout_Time: El número de segundos antes de invalidar la información de LACPDU recibida cuando se usan tiempos de espera largos (3 * Slow_Periodic_Time). Valor: Entero; 90

Aggregate_Wait_Time: El número de segundos que demorar la agregación, para permitir que se agreguen simultáneamente múltiples enlaces. Valor: Entero; 2

Variables asociadas con el retransmisor distribuido

La siguiente exposición se centra en diversas variables asociadas con los retransmisores distribuidos según una realización de la invención.

Drni_Aggregator_Priority: La prioridad de sistema del agregador asociado con este portal. Configurada siempre igual que aAggActorSystemPriority. Transmitida en las DRCPDU.

Valor: Entero. Asignada por el administrador o por directrices del sistema.

Drni_Aggregator_ID: La componente de dirección MAC del identificador de sistema del agregador asociado con este portal. Siempre puesta igual que aAggActorSystemID y transmitida en las DRCPDU.

Valor: 48 bits

Drni_Gateway_Conversation: Vector operativo que enumera qué pasarela del sistema de portal (si la hay) está dejando pasar cada ID de conversación de pasarela.

Valor: Secuencia de números de sistema de portal (0 para ninguno), indexada por el ID de conversación de pasarela.

Valor calculado a partir de aDrniConvAdminGateway[] y Drni_Portal_System_State[] tras la inicialización y siempre que el objeto gestionado o la variable cambie.

5

10

15

20

25

30

35

40

45

Dmi_Port_Conversation: Vector operativo que enumera qué sistema de portal (si lo hay) está dejando pasar cada ID de conversación de puerto.

Valor: Secuencia de números de sistema de portal (0 para ninguno), indexada por el ID de conversación de puerto.

Valor calculado a partir de aAggConversationAdminPort[] y Drni_Portal_System_State[] tras la inicialización y siempre que el objeto gestionado o la variable cambie.

Drni_Portal_Priority: La prioridad de sistema del portal. Siempre configurada igual que aDrniPortalPriority. Transmitida en las DRCpDu.

Valor: Entero.

Asignada por el administrador o por directrices del sistema.

Dmi_PortalID (o Drni_Portal_Addr en alguna realización): La componente de dirección MAC del identificador de sistema del portal. Siempre configurada igual que aDrniPortalId. Transmitida en las DRCPDU.

Valor: 48 bits.

Asignada por el administrador o por directrices del sistema.

Drni_Portal_Topology: La topología configurada del portal. Siempre configurada igual que aDrniPortalTopology. Transmitida en las DRCPDU.

Valor: Un entero en el intervalo [0 ... 3].

Asignada por el administrador o por directrices del sistema.

Variables por cada función de DR

ChangeDRFPorts: Esta variable sigue el rastro del estado operativo de la pasarela y de todos los puertos de agregación asociados a este sistema de portal y es puesta a TRUE cuando cualquiera de ellos cambia. Esta variable también puede ser puesta a TRUE si se inician valores nuevos para la Drni_Conversation_GatewayList[] o la Drni_Conversation_PortList[].

Valor: Booleano

ChangePortal: Esta variable es puesta a TRUE cuando cambia DRF_Neighbor_Oper_DRCP_State.IPP_Activity en cualquier IPP en este sistema de portal.

Drni_Conversation_GatewayList[]: Una matriz de 4096 listas, indexadas por el ID de conversación de pasarela, que determina qué pasarela de este portal transporta qué ID de conversación de pasarela. Cada elemento de la matriz es una lista de pasarelas en este portal, en orden de prioridad de la más deseada a la menos deseada, para transportar el ID indexado de conversación de pasarela. Asignada por el administrador o por directrices del sistema. Configurada siempre igual que aDrniConvAdminGateway[].

Drni_Conversation_PortList[]:Una matriz de 4096 listas, indexadas por el ID de conversación de puerto, que determina qué puerto de agregación en este portal transporta qué ID de conversación de puerto. Cada elemento de la matriz es una lista de puertos de agregación en este portal, en orden de prioridad del más deseado al menos deseado, para transportar el ID indexado de conversación de puerto. Asignada por el administrador o por directrices del sistema. Configurada siempre igual que aAggConversationAdminPort[].

Valor: Secuencia de varios ID de puerto

Drni_Portal_System_State[]: Los estados de todos los sistemas de portal en este portal, indexados por número de sistema de portal. Valor: Bandera booleana que indica el estado de operación del portal (TRUE indica operativo), una lista (quizá vacía) de los ID de puerto de los puertos de agregación operativos en ese sistema de portal, y la identidad del IPP, si lo hay, desde el cual se obtuvo el estado del sistema de portal. Esta variable es configurada por la función updatePortalState. Transmitida en las DRCPDU.

DRF_Home_Admin_Aggregator_Key: El valor de clave de agregador administrativo asociado con el agregador de este sistema de portal. Transmitida en las DRCPDU.

Valor: Entero

En una realización, DRF_Home_Admin_Aggregator_Key es asignada por el administrador o por directrices del sistema. La DRF_Home_Admin_Aggregator_Key es configurada y debe ser diferente para cada sistema de portal. Específicamente, los dos bits más significativos deben ser diferentes en cada sistema de portal. Los 14 bits

5

10

15

20

25

30

35

40

45

inferiores pueden ser cualquier valor, no precisan ser iguales en cada sistema de portal, y tienen un valor por defecto de cero.

Asignada por el administrador o por directrices del sistema.

DRF_Home_Conversation_GatewayList_Digest: Un compendio de aDrniConvAdminGateway[], configurado en esta función de DR, para su intercambio con los sistemas de portal vecinos. Esta variable es referenciada por la DRCPDU.

Valor: Compendio MD5

DRF_Home_Conversation_PortList_Digest: Un compendio de aAggConversationAdminPort[],configurado en esta función de DR, para su intercambio con los sistemas de portal vecinos. Transmitido en las DRCPDU.

Valor: Compendio MD5

DRF_Home_Gateway_Algorithm: El algoritmo de pasarela usado por esta función de DR para asignar tramas a los ID de conversación de pasarela. Siempre configurado igual que aDrniGatewayAlgorithm. Transmitido en las DRCPDU.

Valor: 4 octetos (OUI de 3 octetos que identifica la organización que es responsable de establecer este algoritmo, seguido por dos octetos que identifican este algoritmo específico). En otra realización, se usan 5 octetos.

DRF_Home_Port_Algorithm: El algoritmo de puerto usado por esta función de DR para asignar tramas a los ID de conversación de puerto. Configurado siempre igual que el aAggPortAlgorithm del agregador asociado. Transmitido en las DRCPDU.

DRF_Home_Oper_Aggregator_Key: El valor de la clave de agregador operativo asociado con el agregador de este sistema de portal. Su valor es calculado por la función updateKey. Transmitido en las DRCPDU.

Valor: Entero

DRF_Home_Oper_Partner_Aggregator_Key: La clave de agregador de socio operativo asociada con el ID LAG del agregador de este sistema de portal. Transmitido en las DRCPDU.

Valor: Entero

DRF_Home_State: El estado operativo de esta función de DR. Transmitido en las DRCPDU.

Valor: Bandera booleana que indica el estado de operación de la pasarela de este sistema de portal (TRUE indica operativa) y una lista (quizá vacía) de los ID de puerto de los puertos de agregación operativos en este sistema de portal.

DRF_Neighbor_Admin_Conversation_GatewayList_Digest: El valor para el algoritmo del sistema de portal vecino, asignada por el administrador o por directrices del sistema para ser usado cuando la información del vecino es desconocida. Su valor por defecto es el compendio MD5 calculado a partir de aDrniConvAdminGateway[].

Valor: Compendio MD5

DRF_Neighbor_Admin_Conversation_PortList_Digest: El valor para el algoritmo del sistema de portal vecino, asignada por el administrador o por directrices del sistema para ser usado cuando la información del vecino es desconocida. Su valor por defecto es el compendio MD5 calculado a partir de aAggConversationAdminPort[].

Valor: Compendio MD5

DRF_Neighbor_Admin_Gateway_Algorithm: El valor para el algoritmo de pasarela de los sistemas vecinos, asignada por el administrador o por directrices del sistema para ser usado cuando la información del vecino es desconocida. Su valor por defecto es configurado igual que aDrniGatewayAlgorithm.

DRF_Neighbor_Admin_DRCP_State: Valor por defecto para los parámetros de estado del DRCP del portal vecino, asignado por el administrador o por directrices del sistema, para ser usado cuando la información del vecino es desconocida o ha expirado. El valor consiste en el siguiente conjunto de variables, según se describe en una realización:

5

10

15

20

25

30

35

40

45

HomeGateway NeighborGateway OtherGateway IPPActivity Timeout GatewaySync PortSync Expired Valor: 8 bits

DRF_Neighbor_Admin_Port_Algorithm: El valor para el algoritmo de puerto de los sistemas vecinos, asignado por el administrador o por directrices del sistema para ser usado cuando la información del vecino es desconocida. Su valor por defecto se configura igual que aAggPortAlgorithm.

DRF_Portal_System_Number: Un identificador único para este sistema de portal en el portal.

Valor: Un entero en el intervalo [1.. .3] en una realización.

Copiado de aDrniPortalSystemNumber. Transmitido en las DRCPDU.

PSI (sistema de portal aislado): Esta variable es puesta a TRUE por la función updateDRFHomeState cuando el sistema de portal está aislado de otros sistemas de portal dentro del mismo portal.

Valor: Booleano.

Variables por cada IPP

La siguiente exposición se centra en diversas variables por cada IPP según una realización de la invención.

Ipp_Gateway_Conversation_Direction: Lista operativa de cuáles ID de conversación de pasarela atraviesan pasarelas alcanzables por medio de este IPP. Se configura mediante la operación del DRCP.

Valor: Vector de banderas booleanas indexadas por el ID de conversación de pasarela; TRUE= alguna pasarela alcanzable por medio de este IPP está habilitada para este ID de conversación de pasarela.

Para cada ID de conversación de pasarela, el valor es TRUE si y solo si a) las variables Drni_Gateway_Conversation y Drni_Portal_System_State[] indican que el sistema de portal diana para este ID de conversación de pasarela se encuentra detrás de este IPP, y b) Drni_Gateway_Conversation y Ipp_Other_Gateway_Conversation coinciden en cuanto a qué sistema de portal debería obtener este ID de conversación de pasarela. Ipp_Gateway_Conversation_Direction es inicializado a FALSE y recalculado siempre que cualquiera de sus variables contribuyentes cambie. Para tramas recibidas por este IPP, TRUE significa que la trama es una trama descendente, destinada en último término para un agregador (o para su descarte), y FALSE significa que la trama es una trama ascendente, destinada en último término para una pasarela (o para su descarte). Para tramas ofrecidas para la transmisión por este IPP, TRUE indica que la trama puede pasar, y FALSE que no. Esta variable no es usada para controlar tramas descendentes.

Ipp_Port_Conversation_Passes: Lista operativa de a cuáles ID de conversación de puerto se les permite ser transmitidos a través de este IPP.

Valor: Vector of banderas booleanas indexado por ID de conversación de puerto.

Esta variable es examinada únicamente cuando una trama descendente es ofrecida para su transmisión por este IPP. Para cada ID de conversación de puerto, el valor es TRUE (el ID pasa) si y solo si a) las variables Drni_Port_Conversation y Drni_Portal_System_State[] indican que el sistema de portal diana para este ID de conversación de puerto se encuentra detrás de este IPP, y b) Drni_Port_Conversation e Ipp_Other_Port_Conversation_Portal_System coinciden en cuanto a qué sistema de portal debería obtener este ID de conversación de puerto. Ipp_Port_Conversation_Passes es inicializado a FALSE y recalculado siempre que cambie cualquiera de sus variables contribuyentes.

5

10

15

20

25

30

35

40

45

ChangePortal: Esta variable es puesta a TRUE cuando cambia el DRF_Neighbor_Oper_DRCP_State.IppActivity en cualquier IPP en este sistema de portal.

Valor: Booleano

CC_Time_Shared: Un booleano que indica que sistemas de portal vecino y propio en este IPP están configurados coherentemente para usar la compartición de red/IPL por tiempo.

Valor: Booleano

CC_EncTag_Shared: Un booleano que indica que sistemas de portal vecino y propio en este IPP están configurados coherentemente para usar la compartición de red/IPL por etiqueta o la compartición de red/IPL por encapsulación, según dicte el Network/IPL método seleccionado en el aDrniEncapsulationMethod.

Valor: Booleano

Differ_Conf_Portal: Un booleano que indica que los parámetros de portal configurados usados por el sistema de portal vecino inmediato en este IPP son diferentes de los previstos.

Valor: Booleano

Differ_Portal: Un booleano que indica que la DRCPDU recibida por este IPP está asociada con un portal diferente. Valor: Booleano

DRF_Home_Conf_Neighbor_Portal_System_Number: El valor de configuración de este sistema de portal para el número de sistema de portal del sistema de portal vecino conectado a este IPP. Configurado siempre igual que el valor asignado a los dos bits menos significativos de la componente de prioridad del ID de puerto de este IPP. Transmitido en las DRCPDU.

Valor: Un entero en el intervalo [1...3].

DRF_Home_Loop_Break_Link: Un booleano que indica que el IPL conectado a este IPP está configurado en aDrniLoopBreakLink como un enlace de ruptura de bucle. Transmitido en las DRCPDU.

Valor: Booleano

DRF_Home_Network/IPL_IPLEncap_Digest: Un compendio de aDrniIPLEncapMap, configurado en este IPP, para su intercambio con el sistema de portal vecino por el IPL. Transmitido en el TLV de encapsulación de compartición de red/IPL.

Valor: Compendio MD5

DRF_Home_Network/IPL_NetEncap_Digest: Un compendio de aDrniNetEncapMap, configurado en este IPP, para su intercambio por el enlace de red compartido. Transmitido en el TLV de encapsulación de compartición de red/IPL.

Valor: Compendio MD5

DRF_Home_Network/IPL_Sharing_Method: El método de compartición de red/IPL usado por esta función de DR para compartir este IPP con datos de red. Configurado siempre igual que el campo aDrniEncapsulationMethod. Transmitido en el TLV del método de compartición de red/IPL cuando el campo aDrniEncapsulationMethod no está configurado al valor por defecto de NULL (NULO).

Valor: 4 octetos (OUI de 3 octetos que identifica la organización que es responsable de establecer este método, seguido por un octeto que identifica este método específico).

DRF_Home_Oper_DRCP_State: Los valores operativos de los parámetros de estado del DRCP de este sistema de portal documentados en este IPP. Esto consiste en el siguiente conjunto de variables, descrito anteriormente en la presente memoria:

HomeGateway

NeighborGateway

OtherGateway

IPPActivity

Timeout

GatewaySync

5

10

15

20

25

30

35

40

• PortSync

• Expired Valor: 8 bits

DRF_Neighbor_Admin_Aggregator_Key: En una realización, se define como el valor de clave de agregador administrativo del sistema de portal vecino en este IPP. Transmitido en las DRCPDU.

Valor: Entero

DRF_Neighbor_Aggregator_Priority: La última prioridad de sistema recibida del agregador del vecino por este IPP. Valor: Entero

DRF_Neighbor_AggregatorID: La última componente recibida de dirección MAC del ID del sistema de agregador del sistema de portal vecino, por este IPP.

Valor: 48 bits

DRF_Neighbor_Aggregator_Priority: La última prioridad de sistema recibida del agregador del portal vecino por este IPP.

Valor: Entero

DRF_Neighbor_Conversation_GatewayList_Digest: El último compendio recibido de ID de conversación de pasarela del sistema de portal vecino por este IPP.

Valor: Compendio MD5

DRF_Neighbor_Conversation_PortList_Digest: El último compendio recibido de ID de conversación de puerto del sistema de portal vecino por este IPP.

Valor: Compendio MD5

DRF_Neighbor_Gateway_Algorithm: El valor del algoritmo usado por el sistema de portal vecino para asignar tramas a los ID de conversación de pasarela recibidos por este IPP.

DRF_Neighbor_Loop_Break_Link: Un booleano que indica que el IPL conectado a este IPP es identificado por el sistema de portal vecino en este IPP como un enlace de ruptura de bucle.

Valor: Booleano

DRF_Neighbor_Network/IPL_IPLEncap_Digest: El último compendio recibido del aDrniIPLEncapMap del sistema de portal vecino por este IPP.

Valor: Compendio MD5

DRF_Neighbor_Network/IPL_NetEncap_Digest: El último compendio recibido del aDrniNetEncapMap, para su intercambio por el enlace de red compartido del sistema de portal vecino por este IPP.

Valor: Compendio MD5

DRF_Neighbor_Network/IPL_Sharing_Method: El último método recibido de compartición de red/IPL usado del sistema de portal vecino en este IPP.

DRF_Neighbor_Oper_Aggregator_Key: El último valor recibido de clave de agregador operativo del sistema de portal vecino por este IPP.

Valor: Entero

DRF_Neighbor_Oper_Partner_Aggregator_Key: El valor de la clave de agregador de socio operativo del sistema de portal vecino por este IPP. Transmitido en las DRCPDU.

Valor: Entero

5

10

15

20

25

30

35

40

DRF_Neighbor_Oper_DRCP_State: El valor operativo de la visión de este sistema de portal de los valores actuales de los parámetros del estado del DRCP del vecino. La función de DR propia pone esta variable a cualquier valor recibido del sistema de portal vecino en una DRCPDU. El valor consiste en el siguiente conjunto de variables, según se ha descrito anteriormente en la presente memoria:

: HomeGateway

: NeighborGateway

: OtherGateway

: IPPActivity

: Timeout

: GatewaySync

: PortSync

: Expired

Valor: 8 bits

DRF_Neighbor_Conf_Portal_System_Number: El valor del número de sistema de portal de la configuración del sistema de portal vecino para este sistema de portal que se recibió la vez última por este IPP.

Valor: Un entero en el intervalo [1...3].

DRF_Neighbor_Port_Algorithm: El valor del algoritmo usado por el sistema de portal vecino para asignar tramas a los ID de conversación de puerto recibidos por este IPP.

DRF_Neighbor_Portal_System_Number: El último identificador recibido del sistema de portal vecino por este IPP.

Valor: Un entero en el intervalo [1.3].

DRF_Neighbor_Portal_Topology: El último identificador recibido de la topología de portales del vecino por este IPP. Valor: Un entero en el intervalo [0 ... 3].

DRF_Neighbor_State: El estado operativo del sistema de portal vecino inmediato por este IPP.

Valor: Bandera booleana que indica el estado operativo de la pasarela del sistema de portal vecino (TRUE indica operativa) y una lista (quizá vacía) de los ID de puerto de los puertos de agregación operativos en este IPP.

Drni_Neighbor_ONN

La última bandera ONN recibida del sistema de portal vecino en este IPP transportada dentro del campo de estado de topología.

Valor: Entero

DRF_Other_Neighbor_Admin_Aggregator_Key: El valor de clave de agregador administrativo del sistema de portal de otro vecino asociado con este IPP. Transmitido en las DRCPDU.

Valor: Entero

DRF_Other_Neighbor_Oper_Partner_Aggregator_Key: El valor de la clave de agregador de socio operativo de Sistema de portal de otro vecino asociado con este IPP. Transmitido en las DRCPDU.

Valor: Entero

DRF_Other_Neighbor_State: El estado operativo del sistema de portal de otro vecino en este IPP.

Valor: Bandera booleana que indica el estado operativo de la pasarela del sistema de portal de otro vecino (TRUE indica operativa) y una lista (quizá vacía) of los ID de puerto de los puertos de agregación operativos en este IPP.

Drni_Neighbor_Portal_Addr: La última componente recibida de dirección MAC del ID del sistema de porta del sistema de portal vecino por este IPP.

5

10

15

20

25

30

35

40

45

Valor: 48 bits

Dmi_Neighbor_Portal_Priority: La última prioridad de sistema recibida del sistema de portal vecino por este IPP. Valor: Entero

Drni_Neighbor_PortaND: La última componente recibida de dirección MAC del ID de sistema de portal del sistema de portal vecino por este IPP.

Valor: 48 bits

Drni_Neighbor_State[]: El último valor operativo recibido de Drni_Portal_System_State[] usado por el sistema de portal vecino por este IPP.

Valor: Para cada sistema de portal, bandera booleana que indica el estado operativo de la pasarela del sistema de portal actual (TRUE indica operativa) y una lista (quizá vacía) de los ID de puerto de los puertos de agregación operativos en este sistema de portal según documenta el sistema de portal vecino en este IPP.

Enabled_Time_Shared: Un booleano que indica que los sistemas de portal propio y vecino en este IPP están configurados coherentemente y que están habilitados los métodos de compartición de red/IPL por tiempo especificados en la presente memoria.

Valor: Booleano

Enabled_EncTag_Shared: Un booleano que indica que los sistemas de portal propio y vecino en este IPP están configurados coherentemente para usar los métodos de manipulación de etiquetas de compartición de red/IPL por etiqueta o compartición de red/IPL por encapsulación, según dicte el método de red/IPL, seleccionado por el aDrniEncapsulationMethod.

Valor: Booleano

Ipp_Other_Gateway_Conversation: La enumeración de vectores operativos para los cuales la pasarela del sistema de portal (si la hay) deja pasar cada ID de conversación de pasarela documentado por el vecino inmediato en este IPP.

Valor: Secuencia de números de sistema de portal (0 para ninguno), indexados por el ID de conversación de pasarela. Valor calculado a partir de aDrniConvAdminGateway[] y DRF_Neighbor_State[] tras la inicialización y siempre que cambie el objeto gestionado o GatewayConversationUpdate sea FALSE.

Ipp_Other_Port_Conversation_Portal_System: La enumeración de vectores operativos para los cuales el sistema de portal (si lo hay) deja pasar cada ID de conversación de puerto documentado por el vecino inmediato en este IPP.

Valor: Secuencia de números de sistema de portal (0 para ninguno), indexados por el ID de conversación de puerto. Valor calculado a partir de aAggConversationAdminPort[] y DRF_Neighbor_State[] tras la inicialización y siempre que cambie el objeto gestionado o PortConversationUpdate sea FALSE.

IPP_port_enabled: Una variable que indica que el enlace se ha establecido y que el IPP es operable.

Valor: Booleano.

TRUE si el IPP es operable (MAC_Operational == TRUE).

FALSE en los demás casos.

NOTA: El medio por medio del cual el MAC subyacente genera el valor de la variable IPP_port_enabled depende de la implementación.

Ipp_Portal_System_State[]: La lista de los estados de los sistemas de portal alcanzables por medio de este IPP que fue recibida por última vez en una DRCPDU procedente de este IPP. Esta variable es actualizada por la función updatePortalSystem.

Valor: Para cada sistema de portal, bandera booleana que indica el estado operativo de la pasarela del sistema de portal actual alcanzable por medio de este IPP (TRUE indica operativa) y una lista (quizá vacía) de los ID de puerto de los puertos de agregación en ese sistema de portal.

En esta lista, el estado del sistema de portal inmediatamente adyacente es el primer estado de la lista. La lista puede tener, como mucho, dos estados de sistema de portal:

NTTDRCPDU: TRUE indica que hay nueva información de protocolo que debería ser transmitida por este IPP, o que es preciso recordar al sistema de portal vecino la información antigua. En los demás casos se usa FALSE.

5

10

15

20

25

30

35

40

ONN

Other_Non_Neighbor_flag. Este valor es actualizado por la función updatePortalState y es aplicable únicamente en portales que consistan en tres sistemas de portal. Transmitido en las DRCPDU.

Valor: Booleano

TRUE indica que el TLV de información de puertos de otros no está asociado con un vecino inmediato de este sistema de portal. FALSE (cifrado como 0) indica que el TLV de información de puertos de otros es un vecino inmediato por el otro IPP en este sistema de portal.

DRCP_current_while_timer.

Este temporizador es usado para detectar si ha expirado la información de protocolo recibida. Si DRF_Home_Oper_DRCP_State.DRCP_Timeout está configurado a un tiempo de espera corto, el temporizador se pone en marcha con el valor Short_Timeout_Time. Si no, se pone en marcha con el valor Long_Timeout_Time.

DRCP_periodic_timer (valor temporal).

Este temporizador es usado para generar transmisiones periódicas. Es puesto en marcha usando el valor Slow_Periodic_Time o Fast_Periodic_Time, según se especifique en la máquina de estado de transmisión periódica.

Constantes

Todos los temporizadores especificados en esta subcláusula tienen una tolerancia de implementación de ± 250 ms. Drni_Fast_Periodic_Time

El número de segundos entre transmisiones periódicas usando tiempos de espera cortos.

Valor: Entero; 1 Drni_Slow_Periodic_Time

El número de segundos entre transmisiones periódicas usando tiempos de espera largos.

Valor: Entero; 30 Drni_Short_Timeout_Time

El número de segundos antes de invalidar la información de DRCPDU recibida cuando se usan tiempos de espera cortos (3 x Fast_Periodic_Time).

Valor: Entero; 3

Drni_Long_Timeout_Time

El número de segundos antes de invalidar la información de DRCPDU recibida cuando se usan tiempos de espera largos (3 x Slow_Periodic_Time).

Valor: Entero; 90

Variables usadas para gestionar la operación de las máquinas de estado

La siguiente exposición se centra en diversas variables usadas para gestionar la operación de las máquinas de estado según una realización de la invención.

BEGIN: Esta variable indica la inicialización (o reinicialización) de la entidad de protocolo de DRCP. Está puesta a TRUE cuando se inicia o reinicializa el sistema, y está puesta a FALSE cuando se ha completado la (re)inicialización. Valor: booleano.

DRCP_Enabled

Esta variable indica que el IPP asociado está operando el DRCP. Si el enlace no es un enlace punto a punto, el valor de DRCP_Enabled será FALSE. Si no, el valor de DRCP_Enabled será TRUE.

Valor: booleano.

GatewayConversationUpdate: Esta variable indica que es preciso actualizar las distribuciones por ID de conversación de pasarela.

Valor: booleano.

IppGatewayAllUpdate: Esta variable es el O lógico de las variables IppGatewayUpdate para todos los IPP en este sistema de portal.

Valor: booleano.

5 IppGatewayUpdate: Esta variable indica que es preciso actualizar las distribuciones por ID de conversación de pasarela por el IPP asociado. Hay una variable IppGatewayUpdate por IPP en este sistema de portal.

Valor: booleano.

IppPortAllUpdate: Esta variable es el O lógico de las variables IppPortUpdate para todos los IPP en este sistema de portal.

10 Valor: booleano.

IppPortUpdate: Esta variable indica que es preciso actualizar las distribuciones por ID de conversación de puerto por el IPP asociado. Hay una variable IppPortUpdate por IPP en este sistema de portal.

Valor: booleano.

PortConversationUpdate: Esta variable indica que es preciso actualizar las distribuciones por ID de conversación de 15 puerto.

Valor: booleano.

Funciones

La siguiente exposición se centra en diversas funciones según una realización de la invención. extractGatewayConversationID

20 Esta función extrae un valor de ID de conversación de pasarela aplicando el algoritmo de pasarela a los valores de los parámetros de la primitiva de servicio que es invocada en la entidad de retransmisión de la función de DR a la recepción de una primitiva de ISS en uno de los puertos de la función de DR. La relación de los valores de parámetros en las primitivas de ISS y las primitivas de servicio en los puertos de la entidad de retransmisión de la función de DR es proporcionada por las funciones asociadas de soporte por esos puertos y su configuración.

25 NOTA: Estas funciones de soporte pueden ser tan simples como las funciones de soporte EISS especificadas en la versión 6.9 del estándar 802.1Q-2011 del IEEE, para el caso de una DRNI soportada en un puerto de red de cliente o un puerto de red de proveedor en un puente de proveedor (cláusula 15 en el estándar 802.1Q del IEEE), o más complejas, como las funciones de soporte EISS especificadas en las versiones 6.10 o 6.11 en el estándar 802.1Q- 2011 del IEEE, para el caso de DRNI soportada en un puerto de instancia de proveedor o un puerto troncal de 30 cliente, respectivamente, en un puente periférico troncal (cláusula 16 del estándar 802.1Q del IEEE) o, como las funciones de soporte de la interfaz de servicio con etiquetado C o las funciones de soporte de la interfaz de servicio de cliente remoto especificadas en las versiones 15.4 o 15.6 en el estándar 802.1Q-2013 del IEEE para el caso de la DRNI soportada en un puerto periférico de cliente o un puerto de acceso remoto, respectivamente, en un puente periférico de proveedor.

35 Valor: Entero en el intervalo de 0 a 4095. extractPortConversationID extractPortConversationID

Esta función extrae un valor de ID de conversación de puerto aplicando el algoritmo de puerto a los valores de los parámetros de la primitiva de servicio que es invocada en el agregador a la recepción de una primitiva de ISS en uno 40 de los puertos de la función de DR. La relación de los valores de parámetros en las primitivas de ISS en el agregador y las correspondientes primitivas de servicio en el puerto de la entidad de retransmisión de la función de DR es proporcionada por la función asociada de soporte en el agregador y el puerto de la función de DR y sus configuraciones. Revísese la NOTA anterior.

Valor: Entero en el intervalo de 0 a 4095.

45 InitializeDRNIGatewayConversation

Esta función pone el campo Drni_Portal_System_Gateway_Conversation a una secuencia de ceros, indexada por el ID de conversación de pasarela.

5

10

15

20

25

30

35

40

InitializeDRNIPortConversation

Esta función pone el campo Dmi_Portal_System_Port_Conversation a una secuencia de ceros, indexada por el ID de conversación de puerto.

InitializeIPPGatewayConversation

Esta función pone el campo Ipp_Gateway_Conversation_Direction a una secuencia de ceros, indexada por el ID de conversación de pasarela.

InitializeIPPPortConversation

Esta función pone el campo Ipp_Port_Conversation_Passes a una secuencia de ceros, indexada por el ID de conversación de puerto.

recordDefaultDRCPDU

Esta función pone los valores de los parámetros por defecto para el sistema de portal vecino en el IPP, proporcionados por el administrador, a los valores actuales de los parámetros operativos del sistema de portal vecino como sigue:

DRF_Neighbor_Port_Algorithm = DRF_Neighbor_Admin_Port_Algorithm;

DRF_Neighbor_Gateway_Algorithm= DRF_Neighbor_Admin_Gateway_Algorithm; DRF_Neighbor_Conversation_PortList_Digest = DRF Neighbor_Admin_Conversation_PortList_Digest; DRF_Neighbor_Conversation_GatewayList_Digest = DRF Neighbor_Admin_Conversation_GatewayList_Digest; DRF_Neighbor_Oper_DRCP_State = DRF_Neighbor_Admin_DRCP_State;

DRF_Neighbor_Aggregator_Priority = aAggPortPartnerAdminSystemPriority;

DRF_Neighbor_Aggregator_ID = aAggPortPartnerAdminSystemID;

Drni_Neighbor_Portal_Priority = aAggPortPartnerAdminSystemPriority;

Drni_Neighbor_Portal_Addr = aAggPortPartnerAdminSystemID;

DRF_Neighbor_Portal_System_Number = DRF Home_Conf_Neighbor_Portal_System_Number; DRF_Neighbor_Portal_Topology = Drni_Portal_Topology;

DRF_Neighbor_Loop_Break_Link = DRF_Home_Loop_Break_Link; y DRF_Neighbor_Conf_Portal_System_Number = DRF Portal_System_Number.

Además, para el sistema de portal vecino en el IPP:

• El campo DRF_Neighbor_State está puesto a NULL (la bandera booleana para la pasarela del sistema de portal vecino está puesta a FALSE y se vacía la lista de los puertos de agregación operativos en el sistema de portal vecino en este IPP) y si se configura el campo aDrniPortalTopology para que contenga tres sistemas de portal, el campo DRF_Other_Neighbor_State también está puesto a NULL (la bandera booleana para la pasarela del sistema de portal de otro vecino está puesta a FALSE y se vacía la lista de los puertos de agregación operativos en el sistema de portal de otro vecino en este IPP). No hay disponible ninguna información de estado del sistema de portal para ningún sistema de portal en este IPP;

• El campo DRF_Neighbor_Admin_Aggregator_Key en este IPP está puesto a cero;

• El campo DRF_Other_Neighbor_Admin_Aggregator_Key en este IPP está puesto a cero;

• El campo DRF_Neighbor_Oper_Partner_Aggregator_Key en este IPP está puesto a cero;

• El campo DRF_Other_Neighbor_Oper_Partner_Aggregator_Key en este IPP está puesto a cero; y

• La variable ChangePortal está puesta a TRUE.

Por último, pone CC_Time_Shared y CC_EncTag_Shared a FALSE. recordNeighborState

5

10

15

20

25

30

35

40

45

50

Esta función registra los valores de parámetros para los campos Drni_Portal_System_State[] y DRF_Home_Oper_DRCP_State transportados en una DRCPDU recibida por el IPP como los valores actuales de parámetros para los campos Drni_Neighbor_State[] y DRF_Neighbor_Oper_DRCP_State asociados con este IPP, respectivamente, y pone el campo DRF_Neighbor_Oper_DRCP_State.IPP_Activity a TRUE.

También registra las siguientes variables como sigue:

• Los valores de parámetros para el campo Home_Gateway en el DRF_Home_Oper_DRCP_State y el campo Active_Home_Ports en el TLV de información de puertos propios, transportados en una DRCPDU recibida por el IPP, son usados como valores actuales para el campo DRF_Neighbor_State en este IPP y asocia la información de estado de este sistema de portal en este IPP con el sistema de portal identificado por DRF_Neighbor_Portal_System_Number;

• Los valores de parámetros para el campo Other_Gateway en el DRF_Home_Oper_DRCP_State y el campo Other_Neighbor_Ports en el TLV de información de puertos de otros, transportados en una DRCPDu recibida por el IPP, son usados como valores actuales para el campo DRF_Other_Neighbor_State en este IPP y asocia la información de estado de este sistema de portal en este IPP con el sistema de portal identificado por el valor asignado a los dos bits más significativos del campo DRF_Other_Neighbor_Admin_Aggregator_Key transportado dentro del TLV de información de puertos de otros en la DRCPDU recibida. Si no se transporta ningún TLV de información de puertos de otros en la DRCPDU recibida y la topología de portales contiene tres sistemas de portal, el campo DRF_Other_Neighbor_State es puesto a NULL (el campo Other_Gateway es puesto a FALSE y se vacía la lista de los puertos de agregación operativos en el sistema de portal de otro vecino en este IPP) y no hay disponible ninguna información de estado del sistema de portal en este IPP para el sistema de portal vecino distante en el IPP;

• DRF_Neighbor_Admin_Aggregator_Key = DRF Home_Admin_Aggregator_Key;

• DRF_Neighbor_Oper_Partner_Aggregator_Key = DRF_Home_Oper_Partner_Aggregator_Key;

• DRF_Other_Neighbor_Admin_Aggregator_Key = DRF Other_Neighbor_Admin_Aggregator_Key; y

• DRF_Other_Neighbor_Oper_Partner_Aggregator_Key N=

DRF_Other_Neighbor_Oper_Partner_Aggregator_Key.

• Tanto DRF_Other_Neighbor_Admin_Aggregator_Key como DRF_Other_Neighbor_Oper_Partner_Aggregator_Key son puestos a NULL cuando la DRCPDU recibida no contiene el TLV de información de puertos de otros.

Además, si está soportada la compartición de red/IPL por tiempo, la función registra el valor del parámetro para el campo DRF_Home_Network/IPL_Sharing_Method transportado en el TLV recibido del método de compartición de red/IPL como el valor actual del parámetro para el campo DRF_Neighbor_Network/IPL_Sharing_Method y, si este es igual que el DRF_Home_Network/IPL_Sharing_Method del sistema, pone CC_Time_Shared a TRUE; si no, pone CC_Time_Shared to FALSE.

Además, si están soportadas la compartición de red/IPL por etiqueta o la compartición de red/IPL por encapsulación, la función registra los valores de los parámetros relativos a la compartición de la red/IP del sistema de portal vecino transportados en los TLV de compartición de red/IPL recibidos de un IPP, como los valores actuales de los parámetros operativos para el sistema de portal vecino inmediato en este IPP como sigue:

DRF_Neighbor_Network/IPL_Sharing_Method = DRF_Home_Network/IPL_Sharing_Method, transportado en el TLV recibido del método de compartición de red/IPL;

DRF_Neighbor_Network/IPL_IPLEncap_Digest = DRF_Home_Network/IPL_IPLEncap_Digest, transportado en el TLV recibido de encapsulación de compartición de red/IPL; y

DRF_Neighbor_Network/IPL_NetEncap_Digest = DRF_Home_Network/IPL_NetEncap_Digest transportado en el TLV recibido de encapsulación de compartición de red/IPL.

A continuación, compara los valores recién actualizados del sistema de portal vecino con las expectativas de este sistema de portal y, si

DRF_Neighbor_Network/IPL_Sharing_Method == DRF_Home_Network/IPL_Sharing_Method, y DRF_Neighbor_Network/IPL_IPLEncap_Digest == DRF_Home_Network/IPL_IPLEncap_Digest, y DRF_Neighbor_Network/IPL_N etEncap_Digest == DRF_Home_Network/IPL_NetEncap_Digest, entonces pone CC_EncTag_Shared a TRUE;

5

10

15

20

25

30

35

40

si no, si una o más de las comparaciones muestra que los valores difieren, pone CC_EncTag_Shared a FALSE.

A continuación, compara el estado operativo de la pasarela para cada sistema de portal según lo documenta el campo Drni_Portal_System_State[] de este sistema de portal con el estado operativo de la pasarela para el mismo sistema de portal según documenta el campo Drni_Neighbor_State[] y, si cualesquiera de estos difieren, pone GatewayConversationUpdate a TRUE y DRF_Home_Oper_DRCP_State.Gateway_Sync a FALSE; si no, GatewayConversationUpdate sigue inalterado y DRF_Home_Oper_DRCP_State.Gateway_Sync es puesto a TRUE.

También compara la lista de los ID de puerto de los puertos de agregación operativos para cada sistema de portal documentada por el campo Drni_Portal_System_State[] de este sistema de portal con la lista de los ID de puerto de los puertos de agregación operativos para los mismos sistemas de portal documentados por el campo Drni_Neighbor_State[] y, si cualesquiera de estos difieren, pone PortConversationUpdate a TRUE y DRF_Home_Oper_DRCP_State.Port_Sync a FALSE; si no, PortConversationUpdate sigue inalterado y DRF_Home_Oper_DRCP_State.Port_Sync es puesto a TRUE.

recordPortalConfValues

Esta función registra los valores de parámetros configurados para el sistema de portal vecino transportados en una DRCPDU recibida de un IPP, como los valores actuales de parámetros operativos para el sistema de portal vecino inmediato en este IPP como sigue:

DRF_Neighbor_Portal_System_Number = DRF_Portal_System_Number;

DRF_Neighbor_Portal_Topology = Drni_Portal_Topology;

DRF_Neighbor_Conf_Portal_System_Number = DRF Home_Conf_Neighbor_Portal_System_Number; DRF_Neighbor_Loop_Break_Link = DRF Home_Loop_Break_Link;

DRF_Neighbor_Oper_Aggregator_Key = DRF_Home_Oper_Aggregator_Key;

DRF_Neighbor_Port_Algorithm = DRF_Home_Port_Algorithm;

DRF_Neighbor_Conversation_PortList_Digest = DRF_Home_Conversation_PortList_Digest; DRF_Neighbor_Gateway_Algorithm = DRF_Home_Gateway_Algorithm; y

DRF_Neighbor_Conversation_GatewayList_Digest = DRF Home_Conversation_GatewayList_Digest.

DRF_Neighbor_Portal_System_Number == DRF_Home_Conf_Neighbor_Portal_System_Number, y DRF_Neighbor_Portal_Topology == Drni_Portal_Topology, y DRF_Neighbor_Loop_Break_Link == DRF_Home_Loop_Break_Link, y DRF_Neighbor_Conf_Portal_System_Number == DRF_Portal_System_Number, y DRF_Neighbor_Oper_Aggregator_Key == DRF_Home_Oper_Aggregator_Key, y DRF_Neighbor_Port_Algorithm == DRF Home_Port_Algorithm, y

DRF_Neighbor_Conversation_PortList_Digest == DRF_Home_Conversation_PortList_Digest, y DRF_Neighbor_Gateway_Algorithm == DRF_Home_Gateway_Algorithm, y

DRF_Neighbor_Conversation_GatewayList_Digest == DRF_Home_Conversation_GatewayList_Digest, entonces la variable Differ_Conf_Portal es puesta a FALSE;

si no, si una o más de las comparaciones muestran que los valores difieren,

la variable Differ_Conf_Portal es puesta a TRUE y los pares asociados de variables que tienen los valores diferentes están disponibles en aDrnilPPDebugDifferPortalReason.

recordPortalValues

5

10

15

20

25

30

35

40

Esta función registra los valores de parámetros para los campos

Dmi_Aggregator_Priority, Drni_Aggregator_ID, Dmi_Portal_Priority y Dmi_PortalID, transportados en una DRCPDU recibida de un IPP, como los valores actuales de parámetros operativos para el sistema de portal vecino inmediato en este IPP, como sigue:

DRF_Neighbor_Aggregator_Priority = Drni_Aggregator_Priority;

DRF_Neighbor_Aggregator_ID = Drni_Aggregator_ID;

Drni_Neighbor_Portal_Priority = Drni_Portal_Priority; y Drni_Neighbor_Portal_Addr = Drni_Portal_Addr.

DRF_Neighbor_Aggregator_Priority == Drni_Aggregator_Priority y DRF_Neighbor_Aggregator_ID == Drni_Aggregator_ID y Drni_Neighbor_Portal_Priority == Drni_Portal_Priority y Drni_Neighbor_Portal_Addr == Drni_Portal_Addr, entonces la variable Differ_Portal es puesta a FALSE;

si no, si una o más de las comparaciones muestran que los valores difieren,

la variable Differ_Portal es puesta a TRUE y el conjunto asociado de variables que tienen los valores diferentes están disponibles en aDrnilPPDebugDifferPortalReason.

reportToManagement

Esta función alerta al sistema de gestión de la existencia potencial de un error de configuración del sistema de portal en este portal debido a la recepción de una DRCPDU mal configurada y le envía la información contradictoria de la DRCPDU mal configurada recibida.

setDefaultPortalSystemParameters

Esta función configura las variables de este sistema de portal a valores configurados administrativamente como sigue:

Drni_Aggregator_Priority = aAggActorSystemPriority;

Drni_Aggregator_ID = aAggActorSystemID;

Drni_Portal_Priority = aDrniPortalPriority;

Drni_Portal_Addr = aDrniPortalAddr;

DRF_Portal_System_Number = aDrniPortalSystemNumber;

DRF_Home_Admin_Aggregator_Key = aAggActorAdminKey;

DRF_Home_Port_Algorithm = aAggPortAlgorithm;

DRF_Home_Gateway_Algorithm = aDrniGatewayAlgorithm;

DRF_Home_Conversation_PortList_Digest = el compendio MD5 de aDrniConvAdminGateway[];

DRF_Home_Conversation_GatewayList_Digest = el compendio MD5 de aAggConversationAdminPort[]; y

DRF_Home_Oper_DRCP_State = DRF_Neighbor_Admin_DRCP_State.

Además, pone el campo Drni_Portal_System_State[] como si todas las pasarelas en el portal estuvieran documentadas como FALSE y no se documentase como operativo ningún puerto de agregación en ningún sistema de portal.

setGatewayConversation

5

10

15

20

25

30

35

40

45

Esta función pone Dmi_Gateway_Conversation a los valores calculados a partir de aDrniConvAdminGateway[] y el actual Drni_Portal_System_State[] como sigue:

Para cada ID indexado de conversación de pasarela, se identifica un número de sistema de portal escogiendo el número de sistema de portal de mayor prioridad en la lista de números de sistema de portal proporcionados por aDrniConvAdminGateway[] cuando solo están incluidas las pasarelas operativas, proporcionadas por las banderas booleanas de pasarela de la variable Drni_Portal_System_State[].

setIPPGatewayConversation

Esta función pone Ipp_Other_Gateway_Conversation a los valores calculados a partir de aDrniConvAdminGateway[] y el campo Drni_Neighbor_State[] como sigue:

Para cada ID indexado de conversación de pasarela, se identifica un número de sistema de portal escogiendo el número de sistema de portal de mayor prioridad en la lista de números de sistema de portal proporcionados por aDrniConvAdminGateway[] cuando solo están incluidas las pasarelas operativas, proporcionadas por las banderas booleanas de pasarela de la variable Drni_Neighbor_State[].

setIPPGatewayUpdate

Esta función pone el campo IppGatewayUpdate en cada IPP de este sistema de portal a TRUE. setIPPPortConversation

Esta función pone el campo Ipp_Other_Port_Conversation_Portal_System a los valores calculados a partir de aAggConversationAdminPort[] y el campo Drni_Neighbor_State[] como sigue:

Para cada ID indexado de conversación de puerto, se identifica un número de sistema de portal escogiendo el número de sistema de portal de mayor prioridad en la lista de números de sistema de portal proporcionados por aAggConversationAdminPort[] cuando solo están incluidos los puertos de agregación operativos, proporcionados por las listas asociadas de la variable Drni_Neighbor_State[].

setIPPPortUpdate

Esta función pone el campo IppPortUpdate en cada IPP de este sistema de portal a TRUE. setPortConversation

Esta función pone el campo Drni_Port_Conversation a los valores calculados a partir de aAggConversationAdminPort[] y el actual Drni_Portal_System_State[] como sigue:

Para cada ID indexado de conversación de puerto, se identifica un número de sistema de portal extrayendo los dos bits menos significativos de la componente de prioridad del ID de puerta de mayor prioridad (6.3.4) en la lista de los ID de puerto proporcionada por aAggConversationAdminPort[] cuando solo están incluidos los puertos de agregación operativos, proporcionados por las listas asociadas de la variable Drni_Portal_System_State[].

updateDRFHomeState

Esta función actualiza el campo DRF_Home_State en función del estado operativo de los puertos locales como sigue:

La pasarela es puesta a TRUE o FALSE en función de los mecanismos que se usen para identificar el estado operativo de la pasarela local (TRUE indica operable y que la conectividad no está bloqueada por la operación del protocolo de control de red).

La lista de puertos de agregación operativos se crea incluyendo únicamente aquellos ID de puerto de agregación que el agregador conectado documenta que tienen Actor_Oper_Port_State.Distributing == TRUE (condición que excluye los casos en los que los puertos de agregación asociados son no operables (port_enabled = FALSE), están en un estado ExPiRED, o no en el LAG), y el PSI es puesto a TrUe si DRF_Neighbor_Oper_DRCP_State.IPP_Activity == FALSE en todos los IPP en este sistema de portal; si no, PSI es puesto a FALSE.

Además, si PSI == TRUE y Gateway == FALSE, entonces Actor_Oper_Port_State.Sync es puesto a FALSE en todos los puertos de agregación en este sistema de portal.

La función también pone:

GatewayConversationUpdate a TRUE si han cambiado el estado operativo de la pasarela o las listas configuradas para Drni_Conversation_GatewayList[] y pone PortConversationUpdate a TRUE si ha habido algún cambio en la lista

5

10

15

20

25

30

35

40

de los puertos de agregación operativos según documentan los cambios en las variables asociadas Actor_Oper_Port_State.Distributing o las listas configuradas para el campo Dmi_Conversation_PortList[]; si no,

GatewayConversationUpdate y PortConversationUpdate permanecen inalterados.

updateIPPGatewayConversationDirection

Esta función calcula un valor para Ipp_Gateway_Conversation_Direction como sigue:

Para cada ID de conversación de pasarela, el valor es TRUE si y solo si:

a) las variables Drni_Gateway_Conversation e Ipp_Portal_System_State[] indican que el sistema de portal diana para este ID de conversación de pasarela se encuentra detrás de este IPP, y

b) Drni_Gateway_Conversation e Ipp_Other_Gateway_Conversation coinciden en cuanto a qué sistema de portal debería obtener este ID de conversación de pasarela.

Además, si Drni_Gateway_Conversation e Ipp_Other_Gateway_Conversation están es desacuerdo para cualquier ID de conversación de pasarela,

pone DRF_Home_Oper_DRCP_State.Gateway_Sync a FALSE, y NTTDRCPDU a TRUE.

Si no,

DRF_Home_Oper_DRCP_State.Gateway_Sync y NTTDRCPDU quedan inalterados.

Ipp_Gateway_Conversation_Direction es inicializado a FALSE y recalculado siempre que cambie cualquiera de sus variables contribuyentes.

updateIPPPortConversationPasses

Esta función calcula un valor para Ipp_Port_Conversation_Passes como sigue:

Para cada ID de conversación de puerto, el valor es TRUE (el ID pasa) si y solo si:

a) las variables Drni_Port_Conversation e Ipp_Portal_System_State[] indican que el sistema de portal diana para este ID de conversación de puerto se encuentra detrás de este IPP, y

b) Drni_Port_Conversation e Ipp_Other_Port_Conversation_Portal_System coinciden en cuanto a qué sistema de portal debería obtener este ID de conversación de puerto.

Además, si Drni_Port_Conversation e Ipp_Other_Port_Conversation_Portal_System están es desacuerdo para cualquier ID de conversación de puerto,

pone DRF_Home_Oper_DRCP_State.Port_Sync a FALSE, y

NTTDRCPDU a TRUE.

Si no,

DRF_Home_Oper_DRCP_State.Port_Sync y NTTDRCPDU quedan inalterados.

Ipp_Port_Conversation_Passes es inicializado a FALSE y recalculado siempre que cambie cualquiera de sus variables contribuyentes.

updateKey

Esta función actualiza la clave de agregador operativo, DRF_Home_Oper_Aggregator_Key, como sigue:

Si enable_long_pdu_xmit == TRUE, entonces:

DRF_Home_Oper_Aggregator_Key se pone al valor de DRF_Home_Admin_Aggregator_Key sustituyendo sus dos bits más significativos por el valor 01; si no, DRF_Home_Oper_Aggregator_Key se pone al valor numérico menor distinto de cero del conjunto que comprende los valores de los campos DRF_Home_Admin_Aggregator_Key, DRF_Neighbor_Admin_Aggregator_Key y DRF_Other_Neighbor_Admin_Aggregator_Key, en cada IPP.

updateNTT

5

10

15

20

25

30

35

40

45

50

Esta función pone NTT a TRUE si cualquiera de DRF_Home_Oper_DRCP_State.GatewaySync, o DRF Home_Oper_DRcP_State.PortSync, o DRF_Neighbor_Oper_DRCP_State.GatewaySync, o

DRF_Neighbor_Oper_DRCP_State.PortSync es FALSE.

updatePortalState

En todas las operaciones asociadas con esta función, la información proporcionada por el campo DRF_Other_Neighbor_State en un IPP es considerada únicamente si Drni_Neighbor_ONN en el mismo IPP es FALSE.

Esta función actualiza el campo Drni_Portal_System_State[] como sigue: La información para este sistema de portal, DRF_Home_State, indexada por el número de sistema de portal, está incluida en Drni_Portal_System_State[]. Para cada uno de los otros sistemas de portal en el portal, si cualquiera de la información de estado del sistema de portal de otro está disponible desde dos IPP en este sistema de portal, entonces:

Para ese sistema de portal, solo la información de estado del sistema de portal proporcionada por el campo DRF_Neighbor_State por el IPP que tiene el otro sistema de portal como un sistema de portal vecino, indexada por el número de sistema de portal, será incluida en Drni_Portal_System_State[].

Si no, si la información de estado de un sistema de portal está disponible únicamente desde un solo IPP en este sistema de portal, entonces:

la información de estado de ese sistema de portal, indexada por el número asociado de sistema de portal, será incluida en el campo Drni_Portal_System_State[] con independencia de si esa información está siendo proporcionada por DRF_Neighbor_State o DRF_Other_Neighbor_State en este IPP. Si la información para un sistema de portal está disponible únicamente en el campo DRF_Other_Neighbor_State en este IPP, entonces se pone ONN a TRUE en este IPP.

Cada sistema de portal incluido en la topología de portales para el cual no haya disponible información de estado del sistema de portal de ninguno de los IPP, tiene su Drni_Portal_System_State[]asociado de información de estado del sistema de portal puesto a NULL (la pasarela está puesta a FALSE y se vacía la lista de los puertos de agregación operativos en el sistema de portal).

Esta función actualiza también el campo Ipp_Portal_System_State[] para cada IPP en este sistema de portal como sigue:

Si hay cualquier información de estado de otro sistema de portal disponible de dos IPP, entonces:

Si el sistema de portal propio que no tiene ningún IPL configurado como un enlace de ruptura de bucle, entonces, para cada IPP del sistema de portal, solo la información de estado del sistema de portal proporcionada por el campo DRF_Neighbor_State por ese IPP será incluida en el campo Ipp_Portal_System_State[] asociado, indexado por el número asociado de sistema de portal; si no

el campo DRF_Neighbor_State en un IPP, indexada por el número asociado de sistema de portal, será incluido como un primer estado en el correspondiente Ipp_Portal_System_State[] y cualquier otro estado adicional asociado con otro sistema de portal documentado en la DRCPDU recibida en este IPP, indexado por el número asociado de sistema de portal, será incluido como el segundo estado en el campo Ipp_Portal_System_State[] solo si Drni_Neighbor_ONN en el mismo IPP es FALSE.

[De modo similar al campo Drni_Portal_System_State[], cada sistema de portal incluido en la topología de portales para el cual la información de estado del sistema de portal no esté disponible de ninguno de los IPP, tiene su Ipp_Portal_System_State[] asociado de información asociada de estado del sistema de portal puesto a NULL (la pasarela está puesta a FALSE y se vacía la lista de los puertos de agregación operativos en el sistema de portal).

updatePortalSystemGatewayConversation

Esta función pone el campo Drni_Portal_System_Gateway_Conversation al resultado de la operación Y lógica entre el vector booleano del campo Drni_Gateway_Conversation, poniendo a FALSE todas las anotaciones indexadas del ID de conversación de pasarela que estén asociadas con otros sistemas de portal en el portal, y el vector booleano construido del campo Ipp_Other_Gateway_Conversation procedente de todos los IPP, poniendo a FALSE todas las anotaciones indexadas del ID de conversación de pasarela que están asociadas con otros sistemas de portal en el portal.

updatePortalSystemPortConversation

Esta función pone el campo Drni_Portal_System_Port_Conversation al resultado de la operación Y lógica entre el vector booleano del campo Drni_Port_Conversation, poniendo a FALSE todas las anotaciones indexadas del ID de conversación de puerto que estén asociadas con otros sistemas de portal en el portal, y el vector booleano

5

10

15

20

25

30

35

40

45

50

construido del campo Ipp_Other_Port_Conversation_Portal_System, poniendo a FALSE todas las anotaciones indexadas del ID de conversación de puerto que están asociadas con otros sistemas de portal en el portal.

Temporizadores

La siguiente exposición se centra en diversos temporizadores aplicables según una realización de la invención.

current_while_timer: Este temporizador es usado para detectar si la información de protocolo recibida ha expirado. Si Actor_Oper_State.LACP_Timeout está puesto a un tiempo de espera corto, el temporizador es puesto en marcha con el valor Short_Timeout_Time. Si no, es puesto en marcha con el valor Long_Timeout_Time.

periodic_timer (valor temporal): Este temporizador es usado para generar transmisiones periódicas. Es puesto en marcha usando el valor Slow_Periodic_Time o Fast_Periodic_Time, según se especifique en la máquina de estado de transmisión periódica.

wait_while_timer: Este temporizador proporciona histéresis antes de llevar a cabo un cambio de agregación, para permitir que todos los enlaces que se unirán al grupo asociado de agregación de enlaces lo hagan. Es puesto en marcha usando el valor Aggregate_Wait_Time.

Mensajes

En una realización, se utiliza un único mensaje:

IppM:M_UNITDATA.indication(DRCPDU): Este mensaje es generado por el analizador de control de DRCP como consecuencia de la recepción de una DRCPDU.

DRCPCtrlMuxN:M_UNITDATA.indication(DRCPDU)

Este mensaje es generado por el analizador/multiplexor de control de DRCP como consecuencia de la recepción de una DRCPDU.

Obsérvese que los dos mensajes son mensajes similares para dos realizaciones diferentes.

Operaciones de máquinas de estado

Volviendo a la operación del procedimiento general de las máquinas de estado, el diagrama de flujo de la Figura 7 define un conjunto de operaciones que dependen, en una realización, de las funciones, las variables y los mensajes descritos anteriormente en la presente memoria. El proceso puede iniciarse en respuesta a la recepción de una DRCPDU. Esta DRCPDU es pasada inicialmente a la unidad de recepción (bloque 702). El conjunto de flechas etiquetado Información de estado del vecino representa nueva información del vecino, contenida en una DRCPDU entrante o suministrada mediante valores administrativos por defecto, que son suministrados a cada máquina de estado por la máquina de recepción de la DRCPDU. El conjunto de flechas etiquetado Información de estado propio representa el flujo de información de estado propio actualizada entre las máquinas de estado. La transmisión de las DRCPDU se produce ya sea como resultado de que la máquina periódica determine la necesidad de transmitir una DRCPDU periódica, o como resultado de cambios a la información de estado propio que precisa ser comunicada a los vecinos. La necesidad de transmitir una DRCPDU es señalada a la máquina de transmisión afirmando NTTDRCPDU. Las flechas restantes representan variables compartidas en la descripción de las máquinas de estado que permiten que una máquina de estado provoque que ocurran acontecimientos en otra máquina de estado.

La máquina de recepción genera una NTTDRCPDU, ejecuta una operación de cambio de puerto, una actualización de conversación de pasarela y una actualización de conversación de puerto.

La máquina periódica 704 recibe la información de estado del vecino y devuelve información de estado propio. La máquina periódica genera una NTTDRCPDU (bloque 704).

La máquina de sistema de portal (bloque 706) es responsable de actualizar el estado operativo de todas las pasarelas y todos los puertos de agregación en el portal en función de información local y de las DRCPDU recibidas por los IPP del sistema de portal propio. Esta máquina de estado es por cada sistema de portal.

Las máquinas (708) de DRNI de pasarela y de agregador son responsables de configurar los ID de conversación de pasarela a los que se permite atravesar la pasarela de esta función de DR y los ID de conversación de puerto a los que se permite ser distribuidos a través del agregador de esta función de DR. Estas máquinas de estado son por cada sistema de portal.

Las máquinas de IPP de DRNI (710) son responsables de configurar los ID de conversación de pasarela y los ID de conversación de puerto a los que se permite atravesar los IPP de esta función de DR.

La máquina (712) de transmisión gestiona la transmisión de las DRCPDU, tanto a petición de otras máquinas de estado como de manera periódica.

5

10

15

20

25

30

35

40

45

50

55

Máquina de recepción de DRCPDU

La máquina de recepción puede implementar la función especificada en la Figura 8 con sus parámetros asociados, según se ha expuesto anteriormente en la presente memoria. El procedimiento puede ser inicializado en el bloque 802 cuando se habilita la funcionalidad y se ejecuta la función recordDefaultDRCPDU() y cuando el campo DRF_Neighbor_Oper_DRCP_State.IPP_Activitiy es falso. Entonces se introduce un estado expirado (bloque 804) y, a la recepción de una DRCPDU, la máquina de estado introduce el estado PORTAL_CHECK (bloque 808). La función recordPortalValues comprueba si la DRCPDU está asociada con este portal. Si no, se comunica el evento al sistema de gestión y ninguna de las máquinas de estado de este portal realiza procesamiento adicional alguno de la DRCPDU. Si la función recordPortalValues identifica la DRCPDU recibida, el sistema entrará en el estado COMPATIBILITY_CHECK (bloque 809) para que sea objeto de comprobación por medio de la función recordPortalConfValues. Esto compara los valores configurados administrativamente que están asociados con este portal con la información recibida y, si difieren, el sistema entrará en el estado REPORT_TO_MANAGEMENT (bloque 810) y la DRCPDU indebidamente configurada será comunicada al sistema de gestión. La máquina de recepción sale del estado REPORT_TO_MANAGEMENT cuando se recibe una nueva DRCPDU (o se inhabilita el IPP).

Si la DRCPDU recibida está configurada según los valores previstos para este portal, la máquina de recepción entrará en el estado CURRENT (bloque 812).

Así, las realizaciones pueden comprender las etapas de: recibir una DRCPDU; comprobar si la DRCPDU recibida está asociada con el portal; comparar los valores configurados asociados con el portal con los valores de la DRCPDU recibida; y enviar un informe en caso de que los valores comparados difieran.

En una realización, a la recepción de una DRCPDU, la máquina de estado entra en el estado PORTAL_CHECK. La función recordPortalValues comprueba si la DRCPDU está asociada con este portal. Si no, la máquina de estado entrará en el estado REPORT_To_MANAGEMENT y la DRCPDU recibida será comunicada al sistema de gestión. Mientras está en el estado REPORT_TO_MANAGEMENT, el sistema saldrá al estado PORTAL_CHECK si se recibe una nueva DRCPDU o al estado EXPIRED si expira el temporizador DRCP_current_while_timer. Si la función recordPortalValues identifica a la DRCPDU recibida como asociada con este portal, entrará en el estado COMPATIBILITY_CHECK para que sea objeto de comprobación por la función recordPortalConfValues. Esta compara los valores configurados administrativamente que están asociados con este portal con la información recibida y, si difieren, el sistema entrará en el estado REPORT_TO_MANAGEMENT y la DRCPDU indebidamente configurada será comunicada al sistema de gestión. Si el sistema de portal sigue recibiendo DRCPDU que no coinciden con las expectativas configuradas administrativamente durante un periodo mayor de dos veces el tiempo de espera corto, la máquina de estado pasará al estado DEFAULTED y los parámetros operativos actuales para el sistema o los sistemas de portal en este IPP serán sobrescritos con valores configurados administrativamente y se desencadenará una actualización del sistema de portal.

Si la DRCPDU recibida está configurada según los valores esperados para este portal, la máquina de recepción de la DRCPDU entra en el estado CURRENT.

La función recordNeighborState registra la información de estado de portal del vecino contenida en la DRCPDU en las variables operativas de estado de portal del vecino y actualiza su propia variable de estado del portal propio. Si difieren, se establecen activadores para notificar al vecino, pero también se configuran variables de eventos locales para desencadenar actualizaciones en la máquina local del sistema de portal (PS: véase la Figura 10), en la máquina de DRNI de pasarela y de agregador (DGA: véase la Figura 11) y en la máquina de IPP de DRNI (IPP: véase la Figura 12).

En el procedimiento de ejecución de las funciones recordPortalValues, recordPortalConfValues y recordNeighborState, una máquina de recepción que se atenga a esta memoria puede no validar los campos Version_Number, TLV_type o Reserved en las DRCPDU recibidas. Son emprenden las mismas acciones con independencia de los valores recibidos en estos campos. Una máquina de recepción puede valor los campos Portal_Information_Length, Portal_Configuration_Information_Length, DRCP_State_Length o Terminator_Length. Estos comportamientos, junto con la restricción en las mejoras futuras de protocolos, según se ha expuesto anteriormente en la presente memoria.

Las reglas anteriormente expresadas permiten que los dispositivos de la versión 1 sean compatibles con las revisiones futuras del protocolo.

La función updateNTT es usada para determinar si se requieren más transmisiones de protocolo; NTTDRCPU es puesta a TRUE si la visión del vecino de la variable de estado de portal operativo propio no está actualizada. A continuación, se pone en marcha el temporizador current_while_timer. El valor usado para poner en marcha el temporizador es bien Short_Timeout_Time o bien Long_Timeout_Time, dependiendo del valor de tiempo de espera operativo del actor.

Si no se recibe ninguna DRCPDU antes de que expire el temporizador current_while_timer, la máquina de estado pasa al estado EXPIRED. El campo DRF_Neighbor_Oper_DRCP_State.IPP_Activity se pone a FALSE, el valor

5

10

15

20

25

30

35

40

45

50

55

operativo actual de la variable de tiempo de espera del vecino se pone a tiempo de espera corto, y el temporizador current_while_timer es puesto en marcha con un valor de Short_Timeout_Time. Este es un estado transitorio; las configuraciones del tiempo de espera permiten que el sistema de portal propio transmita las DRCPDU rápidamente en un intento por restablecer la comunicación con el vecino.

Si no se recibe ninguna DRCPDU antes de que vuelva a expirar el temporizador current_while_timer, la máquina de estado pasa al estado DEFAULTED. La función recordDefaultDRCPDU sobrescribe los parámetros operativos actuales para los sistemas de portal del vecino con valores configurados administrativamente y desencadena una actualización del sistema de portal y la condición es comunicada al sistema de gestión.

Si el IPP se vuelve inoperable, la máquina de estado entra en el estado INITIALIZE. El campo DRF_Neighbor_Oper_DRCP_State.IPP_Activity es puesto a FALSE la función recordDefaultDRCPDU hace que los valores administrativos de los parámetros del socio sean usados como valores operativos actuales. Estas acciones obligan a la máquina de PS a desconectar los sistemas de portal vecinos del portal y la pasarela y a recalcular los filtros de los ID de conversación de puerto.

La máquina de recepción también puede implementar la función especificada en la Figura 16 con sus parámetros asociados. La máquina de recepción de la Figura 16 sigue algunos recorridos de flujo diferentes de los de la Figura 8. Los términos y las funciones de la máquina alternativa de recepción de la Figura 16 son análogos a los de la Figura 8. Una persona experta en la técnica entendería que son posibles otras implementaciones coherentes con los principios y las estructuras de las máquinas de recepción ilustradas.

La Figura 33 ilustra un método para la sincronización con un vecino en un nodo de un grupo de agregación de enlaces DRNI según una realización de la invención. El método 3300 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C. Obsérvese que las etapas opcionales están denotadas como una caja a trazos discontinuos, según se ilustra en la Figura 33.

En la referencia 3302, el nodo es inicializado para operar el DRCP en un IPP acoplado a un nodo vecino usando un IPL. El nodo y el nodo vecino están incluidos en un portal, que puede contener un nodo vecino adicional en una realización. El nodo está acoplado al nodo vecino mediante el IPP usando el IPL. En una realización, la inicialización comprende establecer valores de parámetros por defecto para el nodo vecino en el IPP para que sean los parámetros operativos actuales del nodo vecino proporcionados por un administrador del portal. Los parámetros incluyen un algoritmo de puerto vecino, tal como DRF_Neighbor_Port_Algorithm (para ser configurado para que sea DRF_Neighbor_Admin_Port_Algorithm), un algoritmo de pasarela de puerto vecino, tal como el DRF_Neighbor_Gateway_Algorithm (para ser configurado para que sea

DRF_Neighbor_Admin_Gateway_Algorithm), y otros presentados anteriormente en la presente memoria relativos a la función recordDefaultDRCPDU. En una realización, la inicialización incluye, además, configurar la actividad del IPP del nodo vecino para que esté inactivo poniendo la configuración de DRF_Neigbhor_Oper_DRCP_State.IPP_Activity a falso.

En la referencia 3304, el nodo determina que el DRCP está habilitado en el IPP. La comprobación incluye determinar una variable (por ejemplo, IPP_port_enabled) que indica que el IPP está operando el DRCP. En una realización, la determinación se realiza mediante la comprobación de dos variables para el IPP. Una es una variable que indica que el IPP está operando el DRCP (por ejemplo, mediante la variable DRCP_enabled presentada anteriormente en la presente memoria), y la otra es la variable que indica que el IPL ha sido establecido y que el IPP es operable (por ejemplo, mediante la variable IPP_port_enabled presentada anteriormente en la presente memoria).

En la referencia 3306, el nodo entra en un estado expirado. En el estado expirado, el nodo lleva a cabo lo que sigue en una realización: Pone el parámetro de estado del DRCP del nodo a expirado (por ejemplo, poniendo a verdadero el campo DRF_Home_Oper_DRCP_State.Expired presentada anteriormente en la presente memoria), también configura la actividad del IPP del nodo vecino para que esté inactivo, haciendo que el campo DRF_Neigbhor_Oper_DRCP_State.IPP_Activity sea falso. Si no se recibe ninguna DRCPDU, configura un temporizador para que expire. En una realización, la configuración del temporizador se lleva a cabo con la configuración DRF_Neighbor_Oper_DRCP_State.DRCP_Timeout = tiempo de espera corto y la puesta en marcha del temporizador DRCP_current_while_timer (tiempo de espera corto).

Una vez que expira el temporizador, el flujo va a la referencia 3352, en la que el nodo va a un estado por defecto. En una realización, en el estado por defecto, el nodo configura los valores de parámetros por defecto para el nodo vecino en el IPP para que sean los parámetros operativos actuales del nodo vecino proporcionados por un administrador del portal mediante una función tal como recordDefaultDRCPDU presentada anteriormente en la presente memoria. Además, el estado por defecto incluye la comunicación del estado a la gestión a través de una función tal como reportToManagement presentada anteriormente en la presente memoria.

En la referencia 3307, el nodo recibe una DRCPDU en la referencia 3307. La DRCPDU contiene la estructura PDU ilustrada en la Figura 5, teniendo la estructura PDU varios TLV, tales como los enumerados en la Tabla 4. La estructura PDU contiene un TLV de información de puertos propios y un TLV de estado de DRCP. En una

5

10

15

20

25

30

35

40

45

50

55

realización, la recepción de la DRCPDU está indicada en un mensaje generado por el analizador/multiplexor de control del DRCP como consecuencia de la recepción de la DRCPDU, tal como DRCPCtrolMuxN:M_UNITDATA.indication(DRCPDU).

A continuación, el nodo determina que la DRCPDU recibida es asociada con el portal en la referencia 3308. En una realización, la determinación incluye la verificación de que una variable (por ejemplo, Differ_Portal, según se ha expuesto anteriormente en la presente memoria) indique que la recepción de la DRCPDU esté asociada o no con el portal. En una realización, la determinación incluye la ejecución de una función (por ejemplo, recordPortalValues) que registra valores de parámetros de portal transportados en la DRCPDU recibida como los correspondientes valores de parámetros operativos actuales para el nodo vecino en el IPP. Los valores de parámetros de portal, según se ha expuesto anteriormente en la presente memoria en la definición de recordPortalValues, incluye la prioridad de agregador (por ejemplo Drni_Aggregator_Prioirty), el ID de agregador (por ejemplo, Drni_Aggregator_ID), la prioridad del portal vecino (Drni_Portal_Priority) y la dirección del portal (por ejemplo, Drni_Portal_Addr) en una realización.

Si la DRCPDU recibida no está asociada con el portal, el nodo puede comunicar opcionalmente el estado a la gestión a través de una función tal como reportToManagement, presentado anteriormente en la presente memoria. Si, después, el nodo recibe otra DRCPDU, el flujo vuelve a la referencia 3308 para volver a determinar la asociación. De modo similar, cuando el nodo se encuentra en el estado por defecto en la referencia 3352 y recibe una DRCPDU, el flujo va a la referencia 3308 para determinar la asociación.

Después de determinar que la DRCPDU recibida está asociada con el portal, el flujo va a la referencia 3310, en la que el nodo determina que la DRCPDU recibida es compatible con el nodo. La determinación incluye que determinar valores configurados administrativamente asociados con el portal es coherente con los valores recibidos de la DRCPDU. La verificación incluye la ejecución de una función (por ejemplo, recordPortalConfValues) que registra los valores de parámetros configurados del nodo vecino transportados en la DRCPDU recibida como los correspondientes valores parámetros operativos actuales para el nodo vecino en el IPP en una realización. Obsérvese que los valores parámetros configurados en una función tal como recordPortalConfValue son diferentes de los valores de parámetro de portal tales como recordPortalValue, y la diferencia ha sido expuesta anteriormente en la presente memoria en las definiciones de recordPortalConfValues y recordPortalValues.

Si la DRCPDU recibida no es compatible con el nodo, el nodo puede comunicar opcionalmente el estado a gestión a través de una función tal como reportToManagement, presentada anteriormente en la presente memoria. Si, posteriormente, el nodo recibe otra DRCPDU, el flujo vuelve a la referencia 3308 para volver a determinar la asociación. Mientras ejecuta una función tal como reportToManagement, el nodo configura otro temporizador para que expire si no se recibe ninguna DRCPDU y pone en marcha el temporizador. Una vez que expira el temporizador, el flujo vuelve a la referencia 3306.

Después de determinar que la DRCPDU recibida es compatible con el nodo, el nodo registra la información de estado del nodo vecino contenido en la DRCPDU recibida como variables operativas del estado del nodo vecino en la referencia 3312. En una realización, una función (por ejemplo, recordNeighborState) registra los valores de parámetros tales como el estado del sistema de portal (por ejemplo, Drni_Portal_System_State) y el estado del DRCP de la operación del nodo propio (por ejemplo, DRF_Home_Oper_DRCP_State) transportados en la DRCPDU recibida como las correspondientes variables operativas del nodo vecino, tal como Drni_Neigbhor_State y DRF_Neighbor_Oper_DRCP_State.

Opcionalmente, cuando las variables operativas registradas del estado del nodo vecino difieren de las variables operativas del estado del nodo, el nodo configura uno o más activadores para notificar al nodo vecino en la referencia 3314. En una realización, una función (por ejemplo, updateNTT) es usada para determinar si se requiere una transmisión adicional de protocolo, según se ha expuesto anteriormente en la presente memoria.

El método expuesto en la presente memoria proporciona una manera eficiente para que un nodo de DRCP procese información embebida en una DRCPDU recibida de un nodo de DRCP vecino. La información es procesada en etapas y se determina que la DRCPDU recibida está asociada con el portal del nodo de DRCP y que es compatible con el nodo antes de registrar la información del estado del nodo vecino. Además, se inserta un temporizador para evitar que el nodo quede estancado en un estado de espera.

Máquina de transmisión periódica de DRCP

La máquina de transmisión periódica de DRCP puede implementar la función especificada en la Figura 9 con sus parámetros asociados, presentados anteriormente en la presente memoria.

La máquina de transmisión periódica de DRCP establece el deseo de los sistemas de portal propio y vecino de intercambiar DRCPDU periódicas en un IPP para mantener un portal, y establece la frecuencia a la que esas transmisiones periódicas deberían ocurrir. Tendrán lugar transmisiones periódicas si cualquiera de los dos participantes así lo desea. Las transmisiones se producen a una frecuencia determinada por el sistema de portal vecino; esta frecuencia está ligada a la velocidad a la que el sistema de portal vecino hará que caduque la información recibida.

5

10

15

20

25

30

35

40

45

50

55

La máquina de estado tiene cuatro estados. Son los siguientes:

NO_PERIODIC (bloque 902). Mientras se encuentre en este estado, las transmisiones periódicas están inhabilitadas y se ejecuta la función de detención de temporizador periodic_timer. FAST_PERIODIC (bloque 904). Mientras se encuentre en este estado, las transmisiones periódicas están habilitadas a una velocidad de transmisión elevada. Se entra en este estado desde el estado NO_Periodic (bloque 902) en respuesta a una transición incondicional (UCT). El estado Fast_Periodic puede pasar a la transmisión periódica (bloque 910) y a los estados slow_periodic (bloque 905). Se puede entrar en un estado SLOW_PERIoDiC 906 desde el estado FAST_PERIODIC 904 cuando se determina el tiempo de espera largo. Mientras se encuentre en este estado, las transmisiones periódicas están habilitadas a una velocidad de transmisión lenta. Si el temporizador periódico expira, entonces el estado pasa al estado PERIODIC_TX (bloque 910). PERIODIC_TX. Este es un estado transitorio en el que se entra a la expiración del periodic_timer que afirma NTT y luego sale a to FAST_PERIODIC o SLOW_PERIODIC, dependiendo de la configuración del campo DRCP_Timeout del vecino.

Si están habilitadas las transmisiones periódicas, la velocidad a la que tienen lugar es determinada por el valor de la variable DRF_Neighbor_Oper_DRCP_State.Timeout. Si esta variable está configurada a un tiempo de espera lento, entonces se usa el valor fast_periodic_time para determinar el intervalo de tiempo entre transmisiones periódicas. Si no, se usa slow_periodic_time para determinar el intervalo de tiempo.

Así, las realizaciones proporcionan un procedimiento que comprende las etapas de inicializarse en un estado no periódico en el que las transmisiones están inhabilitadas, pasar a un estado periódico rápido, poner en marcha un temporizador para el tiempo periódico rápido, pasar a un estado periódico lento o un estado de transmisión periódica en respuesta a un tiempo de espera largo o a que un vecino tenga la configuración de tiempo de espera periódico largo, respectivamente, pasar de un tiempo de espera periódico lento a un estado de transmisión periódica en respuesta a una configuración de tiempo de espera corta en el vecino o la expiración de un temporizador, y pasar del estado de transmisión periódica bien al estado periódico rápido o bien al periódico corto en respuesta al cambio de la configuración del tiempo de espera del vecino a una configuración de tiempo de espera corto o de tiempo de espera largo, respectivamente.

La máquina de transmisión periódica de DRCP también pueden implementar la función especificada en la Figura 17 con sus parámetros asociados. La Figura 17 contiene diferentes términos (por ejemplo, DRCP_periodic_timer y NTTDRCPDU, no periodic_timer y NTT, respectivamente, como en la Figura 9), pero, por lo demás, los flujos son iguales. Los términos y las funciones de la máquina de transmisión alternativa de la Figura 17 son análogos a los de la Figura 9. Una persona experta en la técnica entendería que son posibles otras implementaciones coherentes con los principios y las estructuras de las máquinas de transmisión ilustradas.

Máquina de sistema de portal

La máquina del sistema de portal puede implementar la función especificada en la Figura 10 con sus parámetros asociados, presentados anteriormente en la presente memoria. Este procedimiento puede inicializarse en un estado de inicialización del sistema de portal (bloque 1002). Se ejecutan las funciones setDefaultPortalSystemParameters y updateKey. En caso de que bien el campo ChangePortal o bien el campo ChangeDRFPorts sean verdaderos, el procedimiento pasa al estado de actualización del sistema de portal (bloque 1004). En el estado de actualización del sistema de portal, el campo ChangePortal es puesto a falso, el campo changeDRFPorts es puesto a falso y se ejecutan las funciones updateDRFHomeState y updateKey. La siguiente actualización se desencadena cuando bien el campo ChangePortal o bien el campo ChangeDRFPorts es actualizado a verdadero.

Así, las realizaciones proporcionan un procedimiento que comprende las etapas de inicializarse en un estado de inicialización de portal en el que se crean parámetros de sistema de portal por defecto y se actualiza una clave, pasar a un estado de actualización del sistema de portal en respuesta a que se haga verdad booleana una variable ChangePortal o ChangeDRFPorts, poner en un estado de actualización del sistema de portal la variable ChangePortal a falso, la variable changeDRFPorts a falso, ejecutar una función updateDRFHomeState, y actualizar la clave, y volver a entrar en el estado de actualización del sistema de portal tras detectar que es verdad una variable ChangePortal o una variable ChangeDRFPorts.

A su inicialización, las variables del sistema de portal son puestas a sus valores por defecto para este portal, según son configuradas por sus configuraciones administrativas. En particular, los estados operativos por defecto de todas las pasarelas, todos los puertos de agregación y todos los IPP en el portal son puestos a FALSE. Además, en función de esos valores por defecto, la clave operativa que ha de ser usada por el agregador asociado es calculada para que sea el valor de la clave administrativa asignado a este sistema de portal.

Cualquier cambio local en el estado operativo de la pasarela del sistema de portal en el en estado de distribución de cualquiera de los puertos de agregación conectados documentados por el agregador asociado, o cualquier cambio en el estado operativo de los sistemas de portal vecinos, documentados por la máquina de estado de RX, desencadena una transición al estado PORTAL_SYSTEM_UPDATE. Esto hace que la función updateDRFHomeState reevalúe la variable que proporciona el propio estado del sistema de portal (DRF_Home_State) en función de la información local actualizada sobre el estado operativo de la pasarela y todos

5

10

15

20

25

30

35

40

45

50

55

los puertos de agregación en el agregador del sistema de portal. Cualquier cambio en el estado operativo de la pasarela del sistema de portal se ve reflejado en la función GatewayConversationUpdate, que es usada para desencadenar transiciones de estado en las máquinas de estado de los puertos y el IPP. De modo similar, cualquier cambio en el estado operativo de los puertos de agregación asociados con el puerto agregador de este sistema de portal se ve reflejado en la función PortConversationUpdate, que es usada para desencadenar transiciones de estado en las mismas máquinas de estado. Por último, la función updateKey actualiza la clave operativa que ha de ser usada por el agregador del sistema de portal, seleccionando el menor valor numérico distinto de cero del conjunto que comprende los valores de las claves administrativas de todos los sistemas de portal activos en el portal.

La máquina de estado vuelve al estado PORTAL_SYSTEM_UPDATE siempre que cambia el estado operativo de cualquiera de los puertos de la función de DR.

La máquina del sistema de portal también puede implementar la función especificada en la Figura 18 con sus parámetros asociados. La Figura 18 es similar a la Figura 10, salvo en que el sistema ejecuta la actualización de estado del portal usando la función UpdatePortalState de la Figura 18. Los términos y las funciones de la máquina alternativa del sistema de portal de la Figura 18 son análogos a los de la Figura 10. Una persona experta en la técnica entendería que son posibles otras implementaciones coherentes con los principios y las estructuras de las máquinas de sistema de portal ilustradas.

La Figura 34 ilustra un método de actualización de los estados operativos de un nodo en una interconexión de redes resilientes distribuidas (DRNI) según una realización de la invención. El método 3400 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C. Obsérvese que las etapas opcionales están denotadas como una caja a trazos discontinuos, según se ilustra en la Figura 34.

En la referencia 3402, el nodo se inicializa para la agregación de enlaces. La inicialización incluye configurar las variables del nodo para el portal al que pertenece según está configurado por las configuraciones administrativas. La inicialización se lleva a cabo ejecutando una función (por ejemplo, setDefaultPortalSystemParameters en la Figura 10) en una realización. La función configura la variable del nodo en valores establecidos administrativamente enumerados en la definición de la función setDefaultPortalSystemParameters, presentada anteriormente en la presente memoria, que incluye una prioridad de sistema del agregador del nodo (por ejemplo, Drni_Aggregator_Priority), un identificador de sistema del agregador del nodo (por ejemplo, Drni_AggregatorJD), una prioridad de sistema del portal (por ejemplo, Drni_Portal_Priority), un identificador para el nodo en el portal (por ejemplo, DRF_Portal_System_Number), un valor de clave de agregador administrativo asociado con el agregador (por ejemplo, DRF_Home_Admin_Aggregator_Key), un algoritmo de puerto usado por una función de DR del nodo para asignar tramas a los ID de conversación de puerto (por ejemplo, DRF_Home_Port_Algorithm), un algoritmo de pasarela usado por la función de DR del nodo para asignar tramas a los ID de conversación de pasarela (por ejemplo, DRF_Home_Gateway_Algorithm), etc.

En la referencia 3404, el nodo determina que ha cambiado un estado operativo asociado con el portal. El cambio de estado operativo puede ser indicado por una variable booleana que es puesta a verdadero cuando un valor operativo de la visión por parte del dispositivo de red del valor de la actividad del IPP del dispositivo de red vecino es activo. En una realización, una variable tal como ChangePortal, presentada anteriormente en la presente memoria, es tal variable booleana. El cambio de estado operativo también puede ser indicado por una variable booleana que está puesta a verdadero cuando cambia un estado operativo de la pasarela del nodo. El cambio de estado operativo también puede ser indicado por una variable booleana que es puesta a verdadero cuando cambia uno de los estados operativos de puertos de agregación del nodo asociado con el primer portal. En una realización, una variable tal como ChangeDRFPorts, presentada anteriormente en la presente memoria, es tal variable booleana para los cambios de los estados operativos tanto de la pasarela como de los puertos de agregación.

En la referencia 3406, el nodo puede configurar una o más variables que indiquen que no hay ningún cambio del estado operativo asociado con el portal. En una realización, eso se lleva a cabo haciendo que variables tales como ChangePortal y ChangeDRFPorts sean FALSE, según se ilustra en la Figura 10. La configuración permite que cambios adicionales de estado operativo desencadenen la actualización de ChangePortal y ChangeDRFPorts para que el nodo pueda detectar el cambio.

En la referencia 3408, el nodo actualiza un conjunto de estados operativos del nodo para la agregación de enlaces en respuesta al cambio en el estado operativo, incluyendo el conjunto de estados operativos un estado operativo de la pasarela para el nodo. En una realización, la actualización se lleva a cabo mediante la ejecución de una función tal como updateDRFHomeState, presentada anteriormente en la presente memoria. En una realización, la actualización también crea una lista de puertos de agregación operativos incluyendo únicamente aquellos identificadores (ID) de puertos de agregación que son operables (por ejemplo, el agregador conectado comunica que tienen Actor_Oper_Port_State.Distributing == TRUE (condición que excluye los casos en los que los puertos de agregación asociados son no operables o se encuentran en un estado expirado, o no están en el grupo de agregación de enlaces)).

5

10

15

20

25

30

35

40

45

50

55

El método proporciona una manera eficaz de sincronizar estados operativos del nodo de DRCP con el nodo de DRCP vecino en función de cambios del portal al que pertenece el nodo de DRCP.

Máquina de DRNI de pasarela y de agregador

La máquina de DRNI de pasarela y de agregador puede implementar la función especificada en la Figura 11 con sus parámetros asociados, presentados anteriormente en la presente memoria. En un sistema de portal hay dos máquinas de DRNI de pasarela y de agregador. Cada una está asociada con un tipo de ID de conversación: hay una para los ID de conversación de pasarela y una para los ID de conversación de puerto. La Figura 11A es el procedimiento de pasarela de DRNi que inicializa en la pasarela de DRNI el estado de inicialización (bloque 1102). En este estado se ejecuta la función InitializeDRNIGatewayConversation y el campo GatewayCoversationUpdate es puesto a FALSE y, cuando se produce GatewayCoversationUpdate, el procedimiento pasa al estado de actualización de la pasarela de DRNI (bloque 1104). En el estado de estado de actualización de la pasarela de DRNI (bloque 1104), el procedimiento pone el campo GatewayConversationUpdate a falso, se ejecutan la función updatePortalState, la operación setGatewayConversation y la función setIPPGatewayUpdate y se ejecuta una función updatePortalSystemGatewayConversation. La actualización de la pasarela de DrNi es desencadenada en cada incidencia de GatewayConversationUpdate.

Las realizaciones del procedimiento comprenden las etapas de inicializar a un estado de inicialización la pasarela de DRNI, inicializar una conversación de pasarela de DRNI y el campo GatewayCoversationUpdate a FALSe, pasar a un estado de actualización de la pasarela de DRNI tras detectar que una variable de actualización de la conversación de pasarela es verdadera, configurar updatePortalState, establecer los activadores de la actualización de la pasarela del IPP, poner la variable de actualización de la conversación de pasarela a falso, configurar la conversación de pasarela, actualizar una conversación de pasarela del sistema de portal y volver a entrar en el estado de actualización de la pasarela de DRNI después de poner la variable de actualización de conversación de la pasarela a verdad.

La Figura 11B es el procedimiento de actualización de puertos de DRNI. En este procedimiento, el proceso de actualización del puerto de DRNI comienza en el estado de inicialización del puerto de DRNI (bloque 1112). Se ejecuta la función initializeDRNIPortConversation y el campo PortCoversationUpdate es puesto a FALSE, y el proceso continúa en respuesta a una incidencia de PortConversationUpdate, que pasa el estado a DRNIPortUpdate (bloque 1114). En el estado de actualización del puerto de DRNI, el procedimiento pone el campo PortConversationUpdate a falso, se ejecutan las operaciones updatePortalState, setPortConversation, setIPPPortUpdate y la operación updatePortalSystemPortConversation. La actualización del puerto de DRNI se desencadena cuando hay un cambio en al valor de PortConversationUpdate.

Las realizaciones del procedimiento comprenden las etapas de inicializar a un estado de inicialización de puerto de DRNI, inicializar una conversación de puerto de DRNI y el campo PortCoversationUpdate a FALSE, pasar a un estado de actualización de puerto de DRNI tras la detección de que la variable PortConversationUpdate sea verdadera, configurar los activadores de activación de puerto de IPP, poner la variable PortConversationUpdate a falso, configurar la conversación del puerto, actualizar la conversación del puerto del sistema de portal y volver a entrar en el estado de actualización del puerto de DRNI en respuesta a la detección de que la variable PortConversationUpdate es verdadera.

Estas máquinas de estado son responsables de configurar los ID de conversación de pasarela y los ID de conversación de puerto a los que se permite atravesar la pasarela y el agregador de esta función de DR en función de las reglas acordadas de prioridad y la operación del DRCP.

En un activador procedente de la máquina de estado de PS (Figura 10) o la máquina de estado de DRX (Figura 8), que declara que el estado operativo de una pasarela ha cambiado, la máquina de estado entra en el estado DRNI_GATEWAY_UPDATE. Esto hace que el parámetro de desencadenamiento (GatewayConversationUpdate) se reinicie a FALSE. Entonces la función updatePortalState actualizará la variable que proporciona los estados de todos los sistemas de portal (Drni_Portal_System_State[]) combinando el campo DRF_Home_State actualizado con información procedente del estado operativo de los puertos de otros sistemas de portal documentado por las DRCPDU recibidas por los IPP del sistema de portal y registradas por la máquina de estado de DRX (Figura 8) y pone IppGatewayUpdate a verdadero en cada IPP en el sistema de portal para desencadenar actualizaciones adicionales en las máquinas de estado de IPP (Figura 12). Subsiguientemente, se invoca la función setGatewayConversation para identificar el sistema de portal que es responsable de cada ID de conversación de pasarela en función de las prioridades de selección acordadas y el estado operativo de las pasarelas conocido por este sistema de portal (en función del estado operativo de la pasarela local y el estado operativo declarado de los sistemas de portal vecinos de sus propias pasarelas transportados por la última DRCPDU recibida de esos sistemas de portal vecinos). Por último, se calculará el vector booleano indexado del ID de conversación de pasarela en función del acuerdo entre la visión del sistema de portal de los ID de conversación de pasarela a los que se permite atravesar la pasarela del sistema de portal y la visión de todos los vecinos de los ID de conversación de pasarela a los que se permite atravesar la pasarela de este sistema de portal [declarados mediante sus DRCPDU y registrados por la máquina de estado de DRX (Figura 8) de este sistema de portal]. Esto garantiza que no se permite que

5

10

15

20

25

30

35

40

45

50

55

ninguna ID de conversación de pasarela atraviese la pasarela de este sistema de portal, a no ser que se alcance un acuerdo entre todos los sistemas de portal.

La máquina de estado es inicializada haciendo que se descarten todos los ID de conversación de pasarela y pasa al estado DRNI_GATEWAY_UPDATE siempre que se establece el activador GatewayConversationUpdate.

El vector booleano indexado del ID de conversación de puerto se establece a través de una operación similar de máquina de estado, siendo la única diferencia que las reglas de selección de prioridad se basan en los ID de conversación de puerto acordados y el algoritmo de puerto en vez de en los ID de conversación de pasarela acordados y el algoritmo de pasarela.

La Figura 35 ilustra un método de configuración de un conjunto de ID de conversación para agregador o pasarela en un dispositivo de red en una interconexión de redes resilientes distribuidas (DRNI) según una realización de la invención. El método 3500 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C. Obsérvese que las etapas opcionales están denotadas como una caja a trazos discontinuos, según se ilustra en la Figura 35.

En la referencia 3502, el nodo inicializa un conjunto de ID de conversación y la inicialización incluye establecer anotaciones de un vector booleano asociadas con el conjunto de ID de conversación para que sean una secuencia de ceros. Los ID de conversación son ID de conversación de pasarela o ID de conversación de puerto. El vector booleano incluye valores que indican el procesamiento del conjunto de ID de conversación a través de una pasarela o un agregador del nodo, que lo pone a ceros (sin procesamiento) mediante la inicialización. Obsérvese que un nodo de DRCP contiene una única pasarela y un único agregador.

La inicialización la puede llevar a cabo una función tal como InitializeDRNIGatewayConversation e InitializeDRNIPortConversation, presentadas anteriormente en la presente memoria. El vector booleano puede ser Drni_Portal_System_Gateway_Conversation o Drni_Portal_System_Port_Conversation para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente. En una realización, un indicador de un ID de conversación es el valor booleano de la anotación (verdadero significando, por ejemplo, atravesar la pasarela o ser distribuido mediante el agregador). La inicialización hace que todos los valores sean ceros, haciendo así que no pasen.

En la referencia 3504, el nodo determina que la distribución del conjunto de ID de conversación precisa ser actualizada. En una realización, realizar la determinación incluye verificar una variable booleana (por ejemplo, variables tales como GatewayConversationUpdate y PortConversationUpdate, presentadas anteriormente en la presente memoria para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente).

En la referencia 3506, el nodo configura valores de un vector operativo indexado por los ID de conversación, enumerando el vector operativo qué nodo del portal procesa cada uno de los ID del conjunto de ID de conversación. En una realización, el vector operativo es Drni_Gateway_Conversation y Drni_Port_Conversation para los ID de conversación de pasarela y los ID de conversación de puerto respectivamente. Para los ID de conversación de pasarela, el vector operativo enumera qué nodo del portal deja pasar cada ID de conversación de pasarela. Para los ID de conversación de puerto, el vector operativo enumera qué nodo del portal deja pasar cada ID de conversación de puerto.

En la referencia 3508, el nodo establece los valores del vector booleano indexada por los ID de conversación, enumerando el vector booleano si la única pasarela o el único agregador del dispositivo de red está asociado con cada uno de los ID de conversación. El vector operativo booleano puede ser

Drni_Portal_System_Gateway_Conversation o Drni_Portal_System_Port_Conversation para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente. Para los ID de conversación de pasarela, cada anotación del vector booleano indica si se permite que un ID de conversación de pasarela atraviese la pasarela única del nodo. Para los ID de conversación de puerto, cada anotación del vector booleano indica si se permite que un ID de conversación de puerto sea distribuido mediante el agregador único del nodo.

A continuación, opcionalmente, en la referencia 3510, el nodo actualiza estados operativos de todos los nodos del portal. En una realización, la actualización la lleva a cabo una función tal como updatePortalState, presentada anteriormente en la presente memoria.

También opcionalmente, en la referencia 3512, el nodo establece una variable que indica que la distribución del conjunto de ID de conversación precisa ser actualizada. En una realización, la variable es setIPPGatewayUpdate and setIPPPortupdate (presentadas anteriormente en la presente memoria) para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente.

Así, las realizaciones de la invención proporcionan maneras eficaces de configurar los ID de conversación para que las conversaciones asociadas puedan ser transmitidas debidamente en una DRNI que contiene un grupo de agregación de enlaces.

5

10

15

20

25

30

35

40

45

50

55

60

Máquina de IPP de DRNI

La máquina de IPP de DRNI puede implementar la función especificada en las Figuras 12A-B con sus parámetros asociados, presentados anteriormente en la presente memoria. La Figura 12A ilustra una máquina de estado para actualizar una conversación de pasarela de IPP según una realización de la invención. El procedimiento se inicia en el bloque 1202, en el que se inicializa una pasarela de IPP. En esta realización, la inicialización de la pasarela de IPP se consigue mediante dos funciones de inicialización. Mediante IPPGatewayUpdate = FALSE, el dispositivo de red pone los activadores de actualización de la pasarela de IPP a FALSE. Mediante la función InitializeIPPPortConversation(), el dispositivo de red establece pases de conversación (tales como Ipp_Gateway_Conversation_Direction) en una secuencia de ceros, indexada nuevamente por ID de conversación de pasarela.

Después de la inicialización, la máquina de estado va al bloque 1204, en el que se actualiza la pasarela de IPP. La transmisión es desencadenada por un cambio en la variable. La variable, IppGatewayUpdate, indica que es preciso actualizar distribuciones de ID de conversación de pasarela por cada IPP. En una realización, IppGatewayUpdate es un valor booleano y, una vez que el valor booleano se vuelve TRUE, la máquina de estado va al bloque 1204. En el bloque 1204, configura la conversación de pasarela mediante la función setGatewayConversation. Según se ha expuesto anteriormente en la presente memoria, la función configura el valor de la conversación de pasarela de DRNI a los valores calculados a partir de del valor administrativo actual de la lista de prioridad de selección de pasarela para el retransmisor distribuido (mediante una variable tal como aDrniConvAdminGateway[]) y el estado actual del sistema de puerto de DRNI (leyendo el vector Drni_Portal_System_State[] en una realización). También en el bloque 1204, el dispositivo de red configura la conversación de pasarela de IPP mediante la función setIPPGatewayConversation(). Además, el dispositivo de red actualiza la dirección de la conversación de pasarela de IPP mediante la función updateIPPGatewayConversationDirection() y, por último, el dispositivo de red reinicializa el campo IppGatewayUpdate a FALSE. El bloque 1204 se repite siempre que se precise una actualización de una conversación de pasarela.

Así, las realizaciones del procedimiento comprenden las etapas de inicializar al estado de inicialización de pasarela de un IPP, inicializar el activador de actualización de pasarela del IPP a FALSE, inicializar la conversación de pasarela de IPP, pasar a un estado de actualización de pasarela de IPP tras detectar que una variable IppGatewayUpdate es verdadera, configurar la conversación de pasarela, configurar una conversación de pasarela de IPP, actualizar la dirección de la conversación de pasarela de IPP, poner la variable IppGatewayUpdate a falso y volver a entrar en el estado de actualización de la pasarela de IPP en respuesta a la detección de que la variable GatewayConversationUpdate es verdadera.

La Figura 12B ilustra una máquina de estado para actualizar una conversación de puerto de IPP según una realización de la invención. El procedimiento para actualizar el puerto de IPP es análogo al procedimiento para actualizar una conversación de pasarela, por lo que el procedimiento de la Figura 12B es similar al de la Figura 12A, siendo utilizadas las funciones y las variables para los puertos de IPP para la actualización de la conversación del puerto de IPP.

Las realizaciones de este procedimiento comprenden las etapas de inicializar al estado de inicialización de puerto de un IPP, inicializar el activador de actualización de puerto del IPP a FALSE, inicializar la conversación de puerto de IPP, pasar a un estado de actualización de puerto de IPP en respuesta a la detección de que una variable IppPortUpdate es verdadera, configurar la conversación de puerto, configurar una conversación de IPP, actualizar un pase de conversación de puerto de IPP configurando la variable IppPortUpdate a falso y volver a entrar en el estado de actualización de puerto de IPP en respuesta a la detección de que la variable PortConversationUpdate es verdadera.

En una realización, estas máquinas de estado son responsables de configurar los ID de conversación de pasarela y los ID de conversación de puerto a los que se permite atravesar los IPP de este sistema de portal vecino según las reglas de prioridad acordada y la operación del DRCP.

En un activador procedente de la máquina de estado de DRX (Figura 8), que declara que IppGatewayUpdate está puesto a TRUE, la máquina de estado entra en el estado IPP_GATEWAy_UPDATE. Esto hace que se invoque la función setGatewayConversation. Esto identificará el sistema de portal que es responsable de cada ID de conversación de pasarela basado en las prioridades de selección acordadas y el estado operativo de las pasarelas, conocido por este sistema de portal (en función del estado operativo de la pasarela local y del estado operativo de sus propias pasarelas declarado de los vecinos transportado por la última DRCPDU recibida de esos vecinos). A continuación, la función setIPPGatewayConversation identificará el sistema de portal que es responsable de cada ID de conversación de pasarela en función de las prioridades acordadas de selección y los estados operativos de las pasarelas declarados por el sistema de portal vecino en este IPP (en función del estado operativo de la pasarela del sistema de portal vecino y del estado operativo declarado del sistema de portal vecino sobre su visión por otras pasarelas del portal, transportados por la última DRCPDU recibida de esos sistemas de portal vecino en este IPP). Subsiguientemente, se calculará el vector booleano indexado del ID de conversación de pasarela en función del acuerdo entre la visión del sistema de portal de los ID de conversación de pasarela a los que se permite atravesar el IPP del sistema de portal y la visión del sistema de portal vecino del IPP de los ID de conversación de pasarela a los

5

10

15

20

25

30

35

40

45

50

55

que se permite atravesar el mismo IPP [declarados mediante sus DRCPDU y registrados por la máquina de estado de DRX (Figura 8) de este sistema de portal]. Esto garantiza que no se permite que ninguna ID de conversación de pasarela atraviese este IPP, a no ser que se alcance un acuerdo entre este sistema de portal y su sistema de portal vecino. Por último, el campo IppGatewayUpdate es reinicializado a FALSE.

La máquina de estado es inicializada haciendo que se descarten todos los ID de conversación de pasarela y pasa al estado IPP_GATEWAY_UPDATE siempre que se establece el activador GatewayConversationUpdate.

La Figura 36 ilustra un método de configuración de un conjunto de ID de conversación para IPP en un nodo de DRCP en una interconexión de redes resilientes distribuidas (DRNI) según una realización de la invención. El método 3600 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C.

En la referencia 3602, el nodo inicializa un conjunto de ID de conversación y la inicialización incluye establecer anotaciones de un vector booleano asociadas con el conjunto de ID de conversación para que sean una secuencia de ceros. Los ID de conversación son ID de conversación de pasarela o ID de conversación de puerto. El vector booleano incluye valores que indican el procesamiento del conjunto de ID de conversación a través de un IPP del nodo.

La inicialización la puede llevar a cabo una función tal como InitializeIPPGatewayConversation e InitializeIPPPortConversation, presentadas anteriormente en la presente memoria. El vector booleano puede ser Ipp_Gateway_Conversation_Direction o Ipp_Port_Conversation_Passes para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente. En una realización, un valor para un ID de conversación es el valor booleano de la anotación. Por ejemplo, un valor de TRUE para un ID de conversación de pasarela indica que alguna pasarela es alcanzable por medio de este IPP. La inicialización hace que todos los valores sean ceros, haciendo así que no pasen.

En la referencia 3604, el nodo determina que la distribución del conjunto de ID de conversación precisa ser actualizada. En una realización, realizar la determinación incluye verificar una variable booleana. En una realización, las variables booleanas son IppGatewayUpdate e IppPortUpdate para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente. En otra realización, las variables booleanas son

GatewayConversationUpdate y PortConversationUpdate para los ID de conversación de pasarela y los ID de conversación de puerto, respectivamente.

En la referencia 3606, el nodo establece valores de un primer vector operativo indexado por los ID de conversación, enumerando el vector operativo qué nodo del portal procesa cada uno de los ID de conversación asignados por el nodo. En una realización, el nodo establece los valores mediante funciones tales como setGatewayConversation y setPortConversation para configurar el primer vector operativo tal como Drni_Gateway_Conversation y Drni_Port_Conversation, respectivamente. Para los ID de conversación de pasarela, Drni_Gateway_Conversation enumera qué pasarela de nodo (si la hay) deja pasar cada ID de conversación de pasarela. Para los ID de conversación de puerto, Drni_Port_Conversation enumera qué nodo deja pasar cada uno de los ID de conversación de puerto.

En la referencia 3608, el nodo establece valores de un segundo vector operativo indexado por los ID de conversación, enumerando el vector operativo qué nodo del portal procesa cada uno de los ID de conversación asignados por el nodo vecino. En una realización, el nodo establece los valores mediante funciones tales como setIPPGatewayConversation y setIPPPortConversation para configurar el segundo vector operativo tal como Ipp_Other_Gateway_Conversation y Ipp_Other_Port_Conversation_Portal_System, respectivamente. Según se ha expuesto anteriormente en la presente memoria, para los ID de conversación de pasarela,

Ipp_Other_Gateway_Conversation enumera qué nodo (es decir, sistema de portal) (si lo hay) deja pasar cada ID de conversación de pasarela asignada por el nodo vecino en este IPP, siendo el nodo vecino el nodo vecino inmediato cuando el portal contiene más de dos nodos. De modo similar, para los ID de conversación de puerto, Ipp_Other_Port_Conversation_Portal_System enumera qué nodo deja pasar cada ID de conversación de puerto asignado por el nodo vecino inmediato en este IPP.

En la referencia 3610, el nodo establece valores del vector booleano indexado por los ID de conversación, enumerando el vector booleano si el IPP del nodo está asociado con cada uno de los ID de conversación. En una realización, el vector booleano es Ipp_Gateway_Conversation_Direction para los ID de conversación de pasarela e Ipp_Port_Conversation_Passes para los ID de conversación de puerto, según se ha expuesto anteriormente en la presente memoria.

5

10

15

20

25

30

35

40

45

Así, de forma similar al método 3500, las realizaciones de la invención proporcionan aquí maneras eficaces de configurar los ID de conversación para que las conversaciones asociadas puedan ser debidamente transmitidas en una DRNI que contiene un grupo de agregación de enlaces.

Máquina de transmisión

Cuando la máquina de transmisión (no ilustrada) crea una DRCPDU para transmisión, puede cumplimentar los campos siguientes con los correspondientes valores operativos para este IPP según una realización de la invención:

ID de agregador y prioridad.

ID de portal y prioridad.

Número de sistema de portal.

Estado de la topología.

Clave de agregador operativo.

Algoritmo de puerto.

Algoritmo de pasarela.

Compendio de puertos.

Compendio de pasarelas.

Estado de DRCP.

Los puertos de agregación operativos, la clave de agregador administrativo y la clave de agregador de socio operativo del sistema de portal propio y cualquier otro sistema de portal cuya capacidad para formar un portal haya sido verificada.

Cuando la máquina periódica se encuentra en el estado NO_PERIODIC, la máquina de transmisión:

• No debería transmitir ninguna DRCPDU, y

• Debería poner el valor de NTTDRCPDU a FALSE.

Cuando la variable DRCP_Enabled es TRUE y la variable NTTDRCPDU es TRUE, la máquina de transmisión puede garantizar que se transmite una DRCPDU debidamente formateada [es decir, emitir una primitiva de servicio de DRCPCtrlMuxN:M_UNITDATA.Request (DRCPDU)], sujeta a la restricción de que en cualquier intervalo de Fast_Periodic_Time no pueda transmitirse más que un número específico de LACPDU. El número específico puede variar, dependiendo de la implementación (por ejemplo, diez o veinte). Si NTTDRCPDU está puesto a TRUE cuando este límite está en vigor, la transmisión puede ser demorada hasta el momento en que la restricción ya no esté en vigor. La variable NTTDRCPDU puede ser puesta a FALSE cuando la máquina de transmisión ha transmitido una DRCPDU.

Si la transmisión de una DRCPDU se demora debido a la anterior restricción, la información enviada en la DRCPDU corresponde a los valores operativos para el IPP en el momento de la transmisión, no en el momento en que NTTDRCPDU fue puesta por vez primera a TRUE. En otras palabras, el modelo de transmisión de la DRCPDU se basa en la transmisión de información de estado que es actual en el momento en que se produce una ocasión de transmitir, en contraposición con introducir en una cola los mensajes para su transmisión.

Cuando la variable DRCP_Enabled es FALSE, la máquina de transmisión puede no transmitir ninguna DRCPDU y puede poner el valor de NTTDRCPDU a FALSE.

Máquina de compartición de red/IPL

La máquina de compartición de red/IPL puede implementar las funciones especificadas en la Figura 30 con sus parámetros asociados. Hay une máquina de compartición de red/IPL por cada IPP en un sistema de portal para el método soportado de compartición de red/IPL. Solo se requiere esta máquina cuando se implementan los métodos de compartición de red/IPL: la compartición de red/IPL por tiempo, la compartición de red/IPL por etiqueta, o la compartición de red/IPL por encapsulación.

La máquina de compartición de red/IPL, que corresponde al método 3100 de la Figura 31 expuesta posteriormente en la presente memoria, permite la transmisión y la manipulación de las tramas enviadas por el enlace de red/IPL compartido solo si las DRCPDU recibidas por el mismo puerto comunican la misma configuración de compartición de

5

10

15

20

25

30

35

40

45

50

55

red/IPL por parte del sistema de portal vecino, resultando por ello en que múltiples IPL y enlaces de red compartan un mismo enlace físico o una misma agregación de enlaces.

La máquina de estado tiene tres estados. Son los siguientes:

NO_MANIPULATED_FRAMES_SENT. Mientras se encuentra en este estado, el IPL solo puede estar soportado por un enlace físico o de agregación.

TIME_SHARED_METHOD. Mientras se encuentra en este estado, están habilitados los métodos de compartición de red/IPL por tiempo especificado anteriormente en la presente memoria.

MANIPULATED_FRAMES_SENT. Mientras se encuentra en este estado, están habilitados los métodos de manipulación de etiquetas de compartición de red/IPL por etiqueta o compartición de red/IPL por encapsulación, según dicte el método de compartición de red/IPL seleccionado por aDrniEncapsulationMethod.

El sistema se inicializa en el estado NO_MANIPULATED_FRAMES_SENT y se envían tramas IPL por el enlace físico dedicado. Si el sistema de portal propio está configurado para la compartición de red/IPL mediante el modo de operación por tiempo, indicado por un valor de 1 en aDrniEncapsulationMethod, el sistema pasará a TIME_SHARED_METHOD si la máquina de estado de DRX (DRX: Figura 8) pone CC_Time_Shared a TRUE (indicando que el sistema de portal vecino en este IPP también ha sido configurado para el modo de operación de compartición de red/IPL por tiempo). El sistema permanece en el estado TIME_SHARED_METHOD hasta que una DRCPDU recibida pone CC_Time_Shared a FALSE, lo que desencadena una transición de estado al estado NO_MANIPULATED_FRAMES_SENT y se envían tramas IPL por el enlace físico dedicado.

De modo similar, si el sistema de portal propio está configurado para la compartición de red/IPL por etiqueta o para la compartición de red/IPL por el modo de operación por encapsulación, según indique el valor de aDrniEncapsulationMethod, el sistema pasará al estado MANIPULATED_FRAMES_SENT si la máquina de estado de DRX (DRX: Figura 8) pone CC_EncTag_Shared a TRUE (indicando que el sistema de portal vecino en este IPP también ha sido configurado para la compartición de red/IPL por etiqueta o la compartición de red/IPL por el modo de operación por encapsulación, respectivamente). El sistema permanece en el estado MANIPULATED_FRAMES_SENT hasta que una DRCPDU recibida ponga CC_EncTag_Shared a FALSE, lo que desencadena una transición de estado al estado NO_MANIPULATED_FRAMES_SENT y se envían tramas IPL por el enlace físico dedicado.

La Figura 31 ilustra un método para la compartición de red/IPL en un nodo según una realización de la invención. El método 3100 puede ser implementado en un nodo de DRCP (también denominado sistema de portal de un portal, por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI, tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C. Obsérvese que la etapa opcional está denotada como una caja a trazos discontinuos, según se ilustra en la Figura 31.

En la referencia 3102 un nodo de DRCP (un sistema local de portal) se encuentra en un estado normal de operación y las tramas IPL son transmitidas por un enlace físico dedicado o un enlace de agregación hacia un nodo vecino de DRCP (un sistema de portal vecino). En la referencia 3104 se determina si el nodo está configurado en coherencia con el nodo vecino. Por ejemplo, esto puede realizarse usando una función de registro de parámetros, tal como recordNeighborState, que al menos registre el valor del parámetro transportado en un TLV usado para la compartición de red/IPL desde el nodo vecino, por ejemplo el campo DRF_Home_Network/IPL_sharing_method en la Tabla 6. El valor del parámetro registrado puede entonces compararse con el valor actual del correspondiente parámetro usado por el nodo. En caso de que esté implementada la compartición de red/IPL en el nodo y en caso de que los valores de parámetros estén configurados coherentemente en los nodos, el método prosigue a la referencia 3106, en la que se transmiten tramas desde el nodo hasta el nodo vecino usando la compartición de red/IPL.

Opcionalmente, el nodo sigue usando el método coherente de compartición de red/IPL hasta que detecta un cambio de compartición de red/IPL en el nodo vecino en la referencia 3108. Por ejemplo, un campo CC_Time_Shared o CC_Enctag_Shared indica si los nodos propios/vecinos usan métodos de compartición coherentes. Cuando los dos nodos no usan métodos de compartición coherentes, el flujo vuelve a la referencia 3102, en el que se usa el enlace dedicado o el enlace de agregación.

Las realizaciones de la invención proporcionan una manera eficaz de soportar la compartición de red y del enlace entre puertos en un grupo de agregación de enlaces para que un enlace entre puertos pueda compartir un enlace físico con otros enlaces entre puertos o enlaces de red.

Coordinación entre estados de DRCP y LACP: Primer conjunto de realizaciones

En un sistema de portal de DRNI, según se ilustra en las Figuras 1B-1C, el estado de DRCP y LACP debería ser coherente para que el sistema funcione debidamente. En la Figura 1C, es más fácil de mantener la coherencia. Con referencia a la Figura 1C, el enlace entre el dispositivo 130 de red y el dispositivo 134 de red es el enlace operativo (enlace 172) y el enlace entre el dispositivo 130 de red y el dispositivo 132 de red es el enlace de protección (enlace 174) para un servicio. Un enlace de IPL (no mostrado) entre los dispositivos 134 y 132 de red mantiene su estado de

5

10

15

20

25

30

35

40

45

50

55

60

DRCP en sincronización. Desde el punto de vista del dispositivo 130 de red (el portal 142 con un solo nodo), se conecta a un único sistema (el portal 144) y no se comunica explícitamente información alguna relativa a los dispositivos 132 o 134 de red individualmente al dispositivo 130 de red.

Cuando el enlace de IPL entre los dispositivos 132 y 134 de red se desconecta, tanto el dispositivo 134 de red (nodo actualmente operativo) como el 132 (nodo actualmente de protección) intentan ocupar el lugar de nodo transmisor de tráfico —desde su perspectiva respectiva, quien no opera debidamente es el nodo vecino— . El dispositivo 132 de red, como nodo de protección, actualizará su identificador (ID) de LAG para evitar tener la situación en la que tanto los enlaces 130-132 como los 130-134 (los enlaces 172 y 174, respectivamente) transportan tráfico duplicado. En el portal 142, la determinación de qué enlace ha de permanecer en un grupo de agregación de enlaces (es decir, un enlace operativo) se basa en una decisión por parte del dispositivo 130 de red, que aplica operaciones normales de agregación de enlaces para tomar la decisión. En particular, el dispositivo 130 de red pone el enlace 130-132 en espera para comprobar si el enlace 130-134 está aún en el grupo de agregación de enlaces (es decir, como enlace operativo que transporta tráfico). Si el enlace 130-134 no está en el grupo de agregación de enlaces, habilita el tráfico en el enlace 130-132. Cuando el enlace de IPL entre los dispositivos 134 y 132 de red vuelve a estar operativo, se actualiza el estado de DRCP y el enlace 130-132 permanece bloqueado, y el estado de LACP mantiene el enlace 130-134 para que sea el enlace operativo en todo el proceso (así, sin corte alguno de tráfico).

Para un sistema de DRCP en el que cada portal contiene más de un dispositivo de red, mantener la coherencia entre el estado de DRCP y el de LACP requiere más esfuerzo. Es preciso intercambiar más información entre portales y nodos para mantener los portales sincronizados. En particular, pueden introducirse al menos dos claves de operación (una para cada sistema de portal socio operativo) para coordinar la sincronización. Una es una clave agregadora de socio de operación. La clave agregadora de socio de operación está asociada con el identificador del grupo de agregación de enlaces de agregación de un nodo (ID LAG) (siendo el nodo un nodo socio). La clave agregadora de socio de operación es transmitida en las DRCPDU. En una realización, la clave agregadora de socio de operación es almacenada en una variable denominada DRF_Home_Oper_Partner_Aggregator_Key, que está definida como una clave agregadora de socio de operación asociada con el ID LAG de un dispositivo de red (nodo de un portal) presentado anteriormente en la presente memoria. La otra es una clave de operación para cada uno de los sistemas de portal socios en el portal socio. Las claves de portal del vecino de la operación también están asociadas con el ID LAG de un nodo (siendo el nodo un nodo vecino). Las claves de portal de los vecinos (vecinos inmediatos o remotos) de operación son transmitidas en una DRCPDU. En una realización, la clave agregadora de vecino de operación está almacenada en una variable denominada DRF_Neigbhor_Oper_Partner_Aggregator_Key (DRF_Other_Neigbhor_Oper_Partner_Aggregator_Key en el caso de un tercer sistema de portal), que está definida como el valor de la clave agregadora de socio de operación recibida por última vez de un nodo vecino (o de otro vecino en el caso de un tercer sistema de portal) en su puerto intraportal (IPP) asociado.

Para que se intercambien las claves agregadoras, la DRCPDU puede añadir un nuevo campo para que contenga una clave de operación de socio, de modo que el campo pueda ser usado para contener el valor DRF_Home_Oper_Partner_Aggregator_Key de un nodo en la DRCPDU. También puede actualizarse una función para registrar el valor de parámetro configurado del nodo vecino transportado en una DRCPDU recibida de un IPP. Tal función, tal como recordNeighborState, presentada anteriormente en la presente memoria, puede ser usada para configurar la clave agregadora recibida de socio de operación para que sea la última clave agregadora de vecino de operación conocida (haciendo, por ejemplo, DRF_Neigbhor_Oper_Partner_Aggregator_Key igual al campo DRF_Home_Oper_Partner_Aggregator_Key recibido). Obsérvese que cuando un portal contiene más de dos nodos, hay múltiples campos DRF_Neigbhor_Oper_Partner_Aggregator_Key o potencialmente DRF_Other_Neigbhor_Oper_Partner_Aggregator_Key guardados, uno para cada nodo vecino.

Con referencia a la Figura 1B, el enlace K-M es el enlace operativo y el enlace L-O es el enlace de protección. Existe un enlace de IPL entre los nodos K y L, y M y O para mantener su estado de DRCP en sincronización.

Cuando el enlace de IPL entre los nodos M y O se desconecta, tanto el nodo M (nodo actualmente operativo) como el O (nodo actualmente de protección) para un servicio intentan ocupar el lugar de nodo transmisor de tráfico — desde su perspectiva respectiva, quien no funciona es el nodo vecino—. El nodo O, como nodo de protección, actualizará su identificador (ID) de LAG para evitar tener la situación en la que tanto los enlaces K-M como los L-O transportan tráfico duplicado. En el portal 112, es preciso que los nodos K y L adopten independientemente decisiones de si descartar o permitir el tráfico por los enlaces K-M y L-O. La decisión puede adoptarse intercambiando las DRCPDU entre nodos vecinos en una realización. Además, la lógica de selección aplicada por cada nodo puede ser modificada para tener en cuenta la información intercambiada. Los nodos K y L pueden ser actualizados para permitir que el tráfico atraviese sus enlaces K-M y L-O asociados, respectivamente, únicamente cuando su clave agregadora de socio de operación es el valor menor de un conjunto de valores, incluyendo su clave agregadora de socio de operación y su clave o sus claves de portal vecino de operación. Para que la sección funcione, el nodo O, como un nodo de protección, puede actualizar su valor de clave de operación (en una realización, el valor de clave de operación se actualiza usando una función de actualización tal como la función updateKey presentada anteriormente en la presente memoria) cuando actualiza su ID LAG.

La Figura 19 ilustra las operaciones de un nodo de DRCP tras perder la comunicación con su nodo vecino según una realización de la invención. El método puede ser implementado en cualquier nodo de DRCP acoplado con uno o

5

10

15

20

25

30

35

40

45

50

55

60

más nodos vecinos. En 1902, el nodo de DRCP determina que ya no está en comunicación con su nodo o sus nodos vecinos. La pérdida de comunicación puede ser debida a que el IPP esté inhabilitado o funcione indebidamente, o a que el nodo vecino esté inhabilitado o funcione indebidamente. En 1904, el nodo de DRCP determina entonces que es un nodo que actualmente no transporta tráfico. Obsérvese que un nodo de DRCP puede actuar como nodo operativo o de protección de un portal para un servicio. Si el nodo de DRCP es un nodo operativo, no se requiere ninguna acción adicional: seguirá transportando tráfico activo. Si el nodo de DRCP es un nodo de protección, el método continúa hasta 1906, donde el nodo de DRCP actualiza su clave de operación y transporta el tráfico activo. La clave de operación actualizada es configurada al menor valor numérico distinto de cero del conjunto que comprende los valores de una clave de este nodo (por ejemplo, el campo Admin_Aggregator_Key de este nodo), una clave del nodo vecino (por ejemplo, el campo Admin_Aggregator_Key del nodo vecino), y una clave del otro nodo vecino (por ejemplo, el campo Admin_Aggregator_Key del otro nodo vecino) (cuando el portal contiene 3 sistemas de portal), en cada IPP. La clave de operación actualizada es enviada a su nodo socio.

Según las realizaciones, se proporciona así un método ejecutado por un dispositivo de red en un portal que comprende varios dispositivos de red, es decir estando el dispositivo de red acoplado con al menos un dispositivo de red vecino. El método comprende determinar que el dispositivo de red ha perdido comunicación con uno o más dispositivos de red vecinos. El dispositivo de red determina entonces que no está transportando tráfico por un grupo de agregación de enlaces a un dispositivo asociado de red, es decir, que está actuando como un nodo de protección. Después de determinar que el dispositivo de red es un nodo de protección, el dispositivo de red actualiza su clave de operación y empieza a transportar tráfico por el grupo de agregación de enlaces.

La Figura 20 ilustra la operación de un nodo de DRCP en coordinación con su nodo vecino tras recibir múltiples flujos de tráfico según una realización de la invención. El método puede ser implementado en cualquier nodo de DRCP acoplado a uno o más nodos vecinos. En 2002, el nodo de DRCP determina que recibe tráfico de su socio. El socio puede ser un portal que contiene múltiples nodos o un solo nodo. El nodo de DRCP puede ser un único nodo del portal, en cuyo caso el nodo de DRCP aplica operaciones normales de agregación de enlaces para hacer la elección de seleccionar qué tráfico dejar pasar si recibe tráfico múltiple de su socio (por ejemplo, permitiendo que pase tráfico por el enlace operativo actual después de determinar que el enlace y el correspondiente puerto de agregación sigue en el grupo de agregación de enlaces mientras se habilita el tráfico por el enlace de protección actual después de determinar que el enlace operativo ya no está en el grupo de agregación de enlaces). Por otra parte, en 2004, el nodo de DRCp determina que está acoplado con al menos un nodo vecino. Cuando el nodo de DRCP está acoplado con al menos un nodo vecino, el nodo de DRCP permite que pase tráfico desde su nodo socio únicamente cuando la clave recibida de operación de socio es la menor de las claves de operación de socio de todos los nodos vecinos del portal. En una realización, eso supone determinar que el campo DRF_Home_Oper_Partner_Aggregator_Key del nodo es menor que todos los campos DRF_Neighbor_Oper_Partner_Aggregator_Keys del portal.

Según las realizaciones, se proporciona así un método ejecutado por un dispositivo de red. El método comprende determinar que el dispositivo de red recibe tráfico de un dispositivo asociado de red por un grupo de agregación de enlaces. El método comprende, además, determinar que el dispositivo de red está acoplado con al menos un dispositivo de red vecino, formando el dispositivo de red y el al menos un dispositivo de red vecino parte de un portal. El método comprende, además, recibir una clave de operación del dispositivo asociado de red y determinar si procede permitir tráfico procedente del dispositivo asociado de red en función de una comparación de la clave de operación del dispositivo asociado de red y las claves de operación de los dispositivos de red del portal. Esto puede llevarse a cabo determinando que la clave de operación del dispositivo asociado de red es menor que las claves de operación de los dispositivos de red del portal.

La Figura 27 ilustra la operación de un nodo de DRCP en coordinación con su nodo vecino tras una condición de fallo en las comunicaciones según una realización de la invención. El método 2800 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C, estando acoplado el nodo a uno o más nodos vecinos. En 2702, el nodo de DRCP determina que recibe tráfico de su socio. El socio puede ser un portal que contiene múltiples nodos o un único nodo. El nodo de DRCP puede ser un único nodo del portal, en cuyo caso el nodo de DRCP aplica operaciones normales de agregación de enlaces para tomar la decisión de seleccionar qué tráfico dejar pasar si recibe tráfico múltiple de su socio (por ejemplo, dejar pasar tráfico por el enlace operativo actual después de determinar que el enlace y el correspondiente puerto de agregación siguen en el grupo de agregación de enlaces mientras se permite el tráfico por el enlace de protección actual después de determinar que el enlace operativo ya no está en el grupo de agregación de enlaces). Por otro lado, en 2704, el nodo de DRCP determina que está acoplado con al menos un nodo vecino.

En 2706, el nodo de DRCP determina si la clave de operación recibida ha sido actualizada. En una realización, la actualización es debida a un IPL averiado/que funciona indebidamente. El nodo de DRCP puede determinar que el sistema socio está experimentando el IPL averiado/que funciona indebidamente si los dos bits más significativos del campo Partner_Oper_Key recibido son iguales al valor 2 o 3 y los dos bits menos significativos del campo Partner_Oper_Port_Priority del puerto de agregación son iguales al valor 2 o 3.

5

10

15

20

25

30

35

40

45

50

55

En 2708, el nodo de DRCP determina si está o no aislado de su nodo o sus nodos vecinos del mismo portal. El nodo de DRCP puede estar aislado de su nodo o sus nodos vecinos debido a un IPL averiado/que funciona indebidamente. En ese caso, el nodo de DRCP determina que las comunicaciones de IPL en portales locales y remotos han fallado ambas.

En 2710, el nodo de DRCP determina si está dentro del sistema de portal de mayor prioridad y actúa evitando el tráfico duplicado si lo está. En una realización, el nodo de DRCP determina si tiene el identificador de sistema de portal de mayor prioridad que su portal socio (por ejemplo, en la Figura 1B, el portal 112 puede ser un portal de mayor prioridad que el portal 114, en cuyo caso ejecuta 2710), y corta el tráfico recibido si tiene el mayor identificador del sistema de portal.

Según realizaciones, se proporciona así un método ejecutado por un dispositivo de red. El método comprende determinar que el dispositivo de red recibe tráfico de un dispositivo asociado de red por un grupo de agregación de enlaces. El método comprende, además, determinar que el dispositivo de red está acoplado con al menos un dispositivo de red vecino, formando el dispositivo de red y el al menos un dispositivo de red vecino parte de un portal acoplado con al menos un nodo vecino. El método comprende, además, que el dispositivo de red determine si la clave recibida de operación ha sido actualizada, y determina si está o no aislado del nodo o los nodos vecinos del mismo portal. El método comprende, además, que el dispositivo de red corte el tráfico recibido si tiene un identificador del sistema de portal mayor que el de su portal socio. Las realizaciones de la invención proporcionan, así, una manera eficaz de coordinar estados de los nodos vecinos y los nodos socios para que ningún tráfico duplicado altere la recepción de tráfico en el grupo de agregación de enlaces que implementa el DRCP.

Coordinación entre estados de DRCP y LACP: Segundo conjunto de realizaciones

Para coordinar entre estados de DRCP y LACP, una manera alternativa es actualizar algunas de las funciones/variables existentes y actuar de forma diferente si los nodos de DRCP tanto local como socio pueden comunicar el estado de su IPL.

La Figura 26A ilustra un TLV de una máscara de conversación para un puerto de agregación según una realización de la invención. Obsérvese que el TLV de una máscara de conversación es igual que lo ilustrado en la Figura 4A de la solicitud de patente estadounidense n° 14/135.556, que se incorpora por referencia en su integridad a la presente memoria según se presenta. La Figura 26B ilustra un campo de estado de una máscara de conversación dentro de un TLV de una máscara de conversación de un puerto de agregación según una realización de la invención. La Figura 26B es distinta de la Figura 4B de la solicitud de patente estadounidense n° 14/135.556 porque un campo, PSI (estado de portal aislado) en la referencia 2611 sustituye a un bit reservado. Esta bandera es aplicable únicamente para sistemas de portal y es usada para indicar si el sistema de portal está aislado de otros sistemas de portal dentro del portal. PSI es puesto a TRUE (cifrado como 1) si DRF_Neighbor_Oper_DRCP_State.IPP_Activity == FALSE en todos los IPP en este sistema de portal. Si no, su valor es FALSE (cifrado como 0).

Además, la función ReceivedConversationMaskTLV dada a conocer en la solicitud de patente estadounidense n° 14/135.556 puede ser actualizada con la siguiente operación adicional: también registra el valor del parámetro para el PSI transportado en máscara de conversación de puerto recibida como los valores actuales de parámetros operativos para el Partner_PSI.

Además, la función upddateConversationMaskTLV dada a conocer en la solicitud de patente estadounidense n° 14/135.556 puede ser actualizada con la siguiente operación adicional: Si esta función es implementada por un sistema de portal de DRCP, con su valor DRF_Portal_System_Number puesto a un valor que sea diferente de 1, su identificador de sistema del portal puesto a un valor que es numéricamente menor que el identificador de sistema del socio y PSI == Partner_PSI == TRUE, entonces el campo Comp_Oper_Conversation_Mask es puesto a NULL.

Por ejemplo, con referencia a la Figura 1B, cuando fallan los IPL tanto en K/L como en M/O, todos los nodos transmitirían tráfico: los nodos activos K y M transmiten tráfico porque son nodos activos, y los nodos de protección L y M también transmiten tráfico, ya que están aislados de los nodos activos y ahora ellos mismos se consideran que están activos. Cuando el PSI está soportado en ambos portales 112 y 114, el PSI y el PSI socio recibido serían TRUE. Suponiendo que el portal 112 sea un portal de mayor prioridad (por ejemplo, que el identificador de sistema del portal 112 sea menor que el del portal 114, siendo así mayor su prioridad), y entonces el nodo L determina que su número de sistema de portal (suponiendo que sea 2, ya que es un portal de dos nodos, y el nodo operativo K tiene 1 como número de sistema de portal) no es el menor, actualizará su máscara de conversación de operación a nulo, y no transmite ni recibe tráfico.

La Figura 28 ilustra la operación de un nodo de DRCP tras un fallo en las comunicaciones según una realización de la invención. El método 2800 puede ser implementado en un nodo de DRCP (por ejemplo, un dispositivo de red) de un portal de DRCP (denominado portal local) como parte de una DRNI tal como los nodos K-O de la Figura 1B y los dispositivos 132 y 134 de red de la Figura 1C. En 2802, el nodo de DRCP determina que ya no está en comunicación con el nodo o los nodos vecinos. La pérdida de comunicación puede ser debida a que el IPP esté inhabilitado o funcione indebidamente, o a que el nodo vecino esté inhabilitado o funcione indebidamente. La pérdida

5

10

15

20

25

30

35

40

45

50

55

de comunicación puede estar indicada por que el bit de PSI se puesto a TRUE (el cual es enviado a través de un TLV en una LACPDU, presentada anteriormente en la presente memoria) en una realización.

En 2804, el nodo determina que su nodo socio ya no está en comunicación con el nodo vecino del socio. El nodo socio puede enviar su estado de PSI mediante su LACPDU, y el PSI será registrado por la función recordReceivedConversationMaskTLV del socio. Cuando el nodo socio ya no está en comunicación con su nodo vecino, el estado del PSI recibido se pondrá a TRUE, en cuyo caso PSI == Partner_PSI == TRUE.

En 2806, el nodo determina que su portal es un portal de mayor prioridad que el de su nodo socio. Que el portal sea un portal de mayor prioridad puede ser determinado en función de los identificadores de sistema del portal del nodo and el nodo socio en una realización.

En 2808, el nodo determina que no es el nodo de prioridad mayor de su portal. La prioridad del nodo dentro de su portal puede ser determinada por su número de sistema de portal, que está entre 1 y 3 en una realización (para un portal de hasta 3 nodos). En una realización, el nodo determina que no es el nodo de mayor prioridad de su portal si su número de sistema de portal no es 1.

En 2810, el nodo deja de transmitir y recibir tráfico del grupo de agregación de enlaces. En una realización, el nodo configura su campo Comp_Oper_Conversation_Mask, que es el valor operativo de la máscara de conversación de operación del nodo calculado por una función de actualización de máscara de conversación (por ejemplo, updateConversationMask).

Según las realizaciones, se proporciona así un método ejecutado por un dispositivo de red en un portal que comprende varios dispositivos de red, es decir estando acoplado el dispositivo de red con al menos un dispositivo de red vecino. El método comprende determinar que su nodo socio ya no está en comunicación con el nodo vecino del socio. El dispositivo de red determina entonces que su portal es un portal de mayor prioridad que la de su nodo socio. El dispositivo de red determina entonces que no es el nodo de mayor prioridad de su portal, y deja de transmitir y de recibir tráfico tras la determinación. Las realizaciones de la invención proporcionan, así, una manera eficaz de coordinar los estados de los nodos vecinos y de los nodos socios para que ningún tráfico duplicado altere la recepción de tráfico en el grupo de agregación de enlaces que contiene el DRCP.

Realización de dispositivos de red

La Figura 13 es un diagrama de una realización ejemplar de un dispositivo de red para ejecutar la funcionalidad de DRNI descrita en la presente memoria. El dispositivo 1380 de red puede ser un dispositivo de encaminamiento o un dispositivo similar que implemente una subcapa 1370 de agregación de enlaces, según se ha descrito anteriormente en la presente memoria en relación con la Figura 2 y soporta las funciones de agregación de enlaces descritas anteriormente en la presente memoria. El dispositivo 1380 de red puede incluir un procesador 1300 de red, un conjunto de puertos 1340, un dispositivo 1350 de almacenamiento y componentes de dispositivos de red similares. Los componentes del dispositivo de red son proporcionados a título de ejemplo y no de limitación. El dispositivo 1380 de red puede implementar las funciones de agregación y la subcapa 1370 de agregación de enlaces usando cualquier número o tipo de procesadores y con cualquier configuración. En otras realizaciones, las funciones de agregación y la subcapa de agregación de enlaces y componentes afines son distribuidas en un conjunto de procesadores de red, un conjunto de tarjetas de línea y su procesador constituyente de uso general y específico a aplicaciones o similar implementado en una arquitectura de dispositivos de red.

Los puertos 1340 pueden conectar el dispositivo de red a través de un medio físico tal como Ethernet, fibra óptica o un medio similar con un número cualquiera de dispositivos adicionales de red. En el dispositivo 1380 de red puede haber presente un número cualquiera de puertos diversos. Cualquier combinación o subconjunto de los puertos 1340 puede ser organizada y gestionada como un grupo de agregación de enlaces o un portal de DRNI en el que el dispositivo de red funciona como un sistema de agregación. Así, los puertos pueden ser puertos de agregación para uno o más grupos de agregación de enlaces.

Un conjunto de dispositivos 1350 de almacenamiento dentro del dispositivo 1380 de red puede ser cualquier tipo de dispositivos de memoria, antememorias, registros o dispositivos de almacenamiento similares para ser usados como memoria de trabajo y/o almacenamiento persistente. Puede utilizarse un número cualquiera de dispositivos diversos 1350 de almacenamiento para almacenar los datos del dispositivo de red, incluyendo datos programados y tráfico de datos recibido, para que sean procesados por el dispositivo 1380 de red. En una realización, en tal estructura de datos pueden almacenarse estructuras de datos de DRNI o una organización similar del compendio de correlación de servicios de conversación, máscaras de conversaciones y estructuras similares de datos descritas anteriormente en la presente memoria. Otras estructuras de datos almacenadas en el dispositivo 1350 de almacenamiento pueden incluir las descritas anteriormente en la presente memoria. En otras realizaciones, puede concebirse que estas estructuras de datos son independientes y pueden ser distribuidas por un número cualquiera de dispositivos 1350 de almacenamiento separados dentro del dispositivo 1380 de red.

Un conjunto de procesadores 1300 de red puede implementar las funciones de agregación y de DRNI y la subcapa 1370 de agregación de enlaces descritas anteriormente en la presente memoria. Las funciones de agregación pueden incluir uno o varios clientes agregadores 1372 y la subcapa 1370 de agregación de enlaces, que puede

controlar en analizador/multiplexor 1302, el controlador 1306 de agregación, el colector 1325 de tramas, el distribuidor 1320 de tramas y la DRNI 1313.

El controlador 1306 de agregación, según se ha descrito de forma adicional anteriormente en la presente memoria, puede implementar un control de agregación de enlaces y funciones de protocolo de control de agregación de 5 enlaces. Estas funciones gestionan la configuración y la asignación de grupos de agregación de enlaces, el portal de DRNI y aspectos similares. El analizador y multiplexor 1302 de control identifica y remite las LACPDU procedentes de otro tráfico de datos recibido por los puertos de agregación y envía las LACPDU al controlador 1306 de agregación y otro tráfico de datos dentro de la subcapa 1370 de agregación de enlaces.

La subcapa 1370 de agregación de enlaces, según se ha descrito de forma adicional anteriormente en la presente 10 memoria, gestiona la recogida y la distribución de las tramas según el algoritmo de distribución. Dentro de la subcapa 1370 de agregación de enlaces, el colector 1325 de tramas recibe las tramas y las organiza según el algoritmo de distribución compartido con el sistema socio a través del grupo de agregación de enlaces. Un distribuidor 1320 de tramas prepara y selecciona las tramas salientes para su transmisión a través de un conjunto de puertos de agregación según el algoritmo de distribución. Una interfaz de cliente recibe y transmite tramas hacia y 15 desde el o los clientes agregadores 1372. Las tramas entrantes pasan del colector 1325 de tramas al cliente o a los clientes agregadores 1372, y las tramas salientes pasan del distribuidor 1320 de tramas al cliente o a los clientes agregadores 1372. Las funciones 1311 de DRNI descritas anteriormente en la presente memoria son ejecutadas por el procesador 1311 de red.

Aunque la invención ha sido descrita en términos de varias realizaciones ejemplares, los expertos en la técnica 20 reconocerán que la invención no está limitada a las realizaciones descritas y puede ser puesta en práctica con modificación y alteración dentro del alcance de las reivindicaciones adjuntas. Así, ha de considerarse la descripción como ilustrativa, no como limitante.

Claims

5

10

15

20

25

30

35

40

45

50

1- Un método que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces en un dispositivo de red, en el que el dispositivo de red y un dispositivo vecino de red están incluidos en un primer portal del grupo de agregación de enlaces, en el que el primer portal está acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que incluye uno o más dispositivos de red remotos, y en el que el dispositivo de red está acoplado comunicativamente al dispositivo vecino de red mediante un puerto intraportal (IPP), usando un enlace intraportal (IPL), comprendiendo el método:

inicializar (3302) el dispositivo de red para operar el protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo vecino de red usando el IPL, incluyendo la inicialización configurar valores de parámetros por defecto para el dispositivo vecino de red en el iPp para que sean parámetros operativos del dispositivo de red proporcionados por un administrador del primer portal;

comprobar (3304) que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP;

introducir (3306) un estado expirado en el dispositivo de red, en el que el dispositivo de red lleva a cabo:

la configuración de un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado;

la configuración de la actividad del IPP del dispositivo vecino de red para que esté inactivo, y la configuración de un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU) tras recibir (3307) una DRCPDU antes de que expire el temporizador, incluyendo la DRCPDU información de estado del dispositivo vecino de red;

determinar (3308) que la DRCPDU recibida está asociada con el primer portal;

determinar (3310), si se determinó que la DRCPDU recibida está asociada con el primer portal, que la DRCPDU recibida es compatible con el dispositivo de red, comprendiendo la determinación determinar que los valores configurados administrativamente asociados con el primer portal son coherentes con el de la DRCPDU recibida; y

registrar (3312), si se determinó que la DRCPDU recibida es compatible con el dispositivo de red, información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, incluyendo la información de estado del dispositivo vecino de red variables de DRCP para el IPP.
2. - El método de la reivindicación 1 que, además, comprende:

después de que el temporizador expire sin recibir la DRCPDU, que el dispositivo de red entre en un estado por defecto, en el que, en el estado por defecto, el dispositivo de red configura valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos actuales del dispositivo vecino de red proporcionados por el administrador del primer portal, y el dispositivo de red comunica un estado del estado por defecto a un sistema de gestión del primer portal.
3. - El método de la reivindicación 1 o 2 en el que la determinación de que la DRCPDU recibida está asociada con el primer portal incluye registrar valores de parámetros del portal transportados en la DRCPDU recibida como los correspondientes valores de parámetros operativos para el dispositivo vecino de red en el IPP.
4. - El método de la reivindicación 1 o 2 que, además, comprende:

tras determinar que una DRCPDU recibida no está asociada con el portal local, comunicar un estado de no asociación a un sistema de gestión del primer portal.
5. - El método de la reivindicación 1 en el que la determinación de que la DRCPDU recibida es compatible con el dispositivo de red incluye registrar valores de parámetros configurados del dispositivo vecino de red transportados en la DRCPDU recibida como los correspondientes valores de parámetros operativos para el dispositivo vecino de red en el IPP.
6. - El método de la reivindicación 1 o 2 que, además, comprende:

tras determinar que una DRCPDU recibida es incompatible con el dispositivo de red, comunicar un estado de incompatibilidad a un sistema de gestión del primer portal.
7. - El método de la reivindicación 1 o 2 que, además, comprende:

configurar uno o más activadores para notificar al dispositivo vecino de red tras determinar que las variables operativas de estado del dispositivo vecino de red registradas difieren de las variables operativas de estado del dispositivo de red.
8. - Un dispositivo de red que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces, en el que el dispositivo de red y un dispositivo vecino de red están incluidos en un primer

10

15

20

25

30

35

40

45

50

portal del grupo de agregación de enlaces, en el que el primer portal está acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que incluye dos o más dispositivos de red remotos, y en el que el dispositivo de red está acoplado comunicativamente al dispositivo vecino de red mediante un puerto intraportal (IPP), usando un enlace intraportal (IPL), comprendiendo el dispositivo de red:

puertos (1340) acoplados al enlace físico o de agregación del grupo de agregación de enlaces; y un procesador (1300) de red acoplado a los puertos, ejecutando el procesador de red una función (1313) de DRNI, siendo la función de DRNI operativa para inicializar el dispositivo de red para operar el protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo vecino de red usando el IPL, incluyendo la inicialización la configuración de valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos del dispositivo vecino de red proporcionados por un administrador del primer portal; operativa, además, para comprobar que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP; operativa, además, para introducir un estado expirado en el dispositivo de red, en el que la función de DRNI es operativa para configurar un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado, para configurar la actividad del IPP del dispositivo vecino de red para que esté inactivo, y para configurar un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU); operativa, además, para recibir una DRCPDU antes de que expire el temporizador, incluyendo la DRCPDU información de estado del dispositivo vecino de red; operativa, además, para determinar que la DRCPDU recibida está asociada con el primer portal, determinar, si se determinó que la DRCPDU recibida está asociada con el primer portal, que la DRCPDU recibida es compatible con el dispositivo de red, siendo la determinación, además, para determinar que los valores configurados administrativamente asociados con el primer portal son coherentes con el de la DRCPDU recibida; y siendo operativa, además, para registrar, si se determinó que la DRCPDU recibida es compatible con el dispositivo de red, información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, siendo la información de estado del dispositivo vecino de red para incluir variables de DRCP para el IPP.
9. - El dispositivo de red de la reivindicación 8 en el que la introducción del estado expirado en el dispositivo de red es, además, para:

configurar un temporizador como expirado si no se recibe ninguna DRCPDU, siendo el dispositivo de red para introducir un estado por defecto, en el que, en el estado por defecto, el dispositivo de red configura valores de parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos actuales del dispositivo vecino de red proporcionados por el administrador del primer portal, y el dispositivo de red comunica un estado del estado por defecto a un sistema de gestión del primer portal.
10. - El dispositivo de red de la reivindicación 8 o 9 en el que la determinación de que la DRCPDU recibida está asociada con el primer portal incluye registrar valores de parámetros del portal transportados en la DRCPDU recibida como los correspondientes valores de parámetros operativos para el dispositivo vecino de red en el IPP.
11. - El dispositivo de red de la reivindicación 8 o 9, siendo la función de DRNI operativa, además, para:

tras determinar que una DRCPDU recibida no está asociada con el portal local, comunicar un estado de no asociación a un sistema de gestión del primer portal.
12. - El dispositivo de red de la reivindicación 8 en el que la determinación de que la DRCPDU recibida es compatible con el dispositivo de red incluye registrar valores de parámetros configurados del dispositivo vecino de red transportados en la DRCPDU recibida como los correspondientes valores de parámetros operativos para el dispositivo vecino de red en el IPP.
13. - El dispositivo de red de la reivindicación 8 o 9, siendo la función de DRNI operativa, además, para:

tras determinar que una DRCPDU recibida es incompatible con el dispositivo de red, comunicar un estado de incompatibilidad a un sistema de gestión del primer portal.
14. - Un soporte de almacenamiento no transitorio legible por máquina que tiene instrucciones almacenadas en el mismo que, cuando son ejecutadas por un procesador, hacen que el procesador efectúe operaciones en un dispositivo de red para soportar una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces, en el que el dispositivo de red y un dispositivo vecino de red están incluidos en un primer portal del grupo de agregación de enlaces, en el que el primer portal está acoplado mediante enlaces del grupo de agregación de enlaces con un segundo portal que incluye dos o más dispositivos de red remotos, y en el que el dispositivo de red está acoplado comunicativamente al dispositivo vecino de red mediante un puerto intraportal (IPP), usando un enlace intraportal (IPL), comprendiendo las operaciones:

inicializar (3302) el dispositivo de red para operar el protocolo de control resiliente distribuido (DRCP) en el IPP acoplado al dispositivo vecino de red usando el IPL, incluyendo la inicialización configurar valores de

5

10

15

20

25

parámetros por defecto para el dispositivo vecino de red en el IPP para que sean parámetros operativos del dispositivo de red proporcionados por un administrador del primer portal;

comprobar (3304) que el DRCP está habilitado en el IPP, incluyendo la comprobación la determinación de una variable que indica que el IPP está operando el DRCP;

introducir (3306) un estado expirado en el dispositivo de red, en el que el dispositivo de red lleva a cabo:

la configuración de un parámetro de estado del protocolo de control de retransmisiones distribuidas (DRCP) del dispositivo de red como expirado;

la configuración de la actividad del IPP del dispositivo vecino de red para que esté inactivo, y la configuración de un temporizador para recibir una unidad de datos del protocolo de control de retransmisiones distribuidas (DRCPDU) tras recibir (3307) una DRCPDU antes de que expire el temporizador, incluyendo la DRCPDU información de estado del dispositivo vecino de red;

determinar (3308) que la DRCPDU recibida está asociada con el primer portal;

determinar (3310), si se determinó que la DRCPDU recibida está asociada con el primer portal, que la DRCPDU recibida es compatible con el dispositivo de red, comprendiendo la determinación determinar que los valores configurados administrativamente asociados con el primer portal son coherentes con el de la DRCPDU recibida; y

registrar (3312), si se determinó que la DRCPDU recibida es compatible con el dispositivo de red, información de estado del dispositivo vecino de red incluida en la DRCPDU recibida como variables operativas de estado del dispositivo vecino de red en el dispositivo de red, incluyendo la información de estado del dispositivo vecino de red variables de DRCP para el IPP.
15.- Un programa informático que soporta una interconexión de redes resilientes distribuidas (DRNI) en un grupo de agregación de enlaces en un dispositivo de red, que comprende instrucciones que, cuando son ejecutadas en al menos un procesador, hacen que el al menos un procesador lleve a cabo el método según una cualquiera de las reivindicaciones 1 a 7.