ES2318268T3 - Procedimiento y aparato para la reconfiguracion rapida de una topologia de red. - Google Patents
Procedimiento y aparato para la reconfiguracion rapida de una topologia de red. Download PDFInfo
- Publication number
- ES2318268T3 ES2318268T3 ES04708094T ES04708094T ES2318268T3 ES 2318268 T3 ES2318268 T3 ES 2318268T3 ES 04708094 T ES04708094 T ES 04708094T ES 04708094 T ES04708094 T ES 04708094T ES 2318268 T3 ES2318268 T3 ES 2318268T3
- Authority
- ES
- Spain
- Prior art keywords
- topology
- network
- bridge
- change
- event
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/48—Routing tree calculation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/28—Routing or path finding of packets in data switching networks using route fault recovery
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Paper (AREA)
- Logic Circuits (AREA)
Abstract
Procedimiento para controlar un elemento de red con una pluralidad de puertos de comunicación para transmitir y recibir paquetes de datos a y desde otros elementos de red en una red, en el que un modelo de topología de árbol de expansión de la red se almacena en por lo menos una base de datos en el elemento de red, comprendiendo dicho procedimiento las etapas siguientes: (a) detectar un evento que indica un cambio en la topología de la red; (b) actualizar el modelo de topología de árbol de expansión del subconjunto de la red basándose en información obtenida del evento de cambio de topología, incluyendo dicho subconjunto el origen del evento de cambio de topología y los elementos de red que están afectados por el cambio de topología, (c) determinar si el elemento de red funciona como un manejador de topología para el evento detectado, y (d) si el elemento de red funciona como un manejador de topología, llevar a cabo las etapas siguientes: (d1) calcular un nuevo modelo de topología de árbol de expansión, basándose en el modelo resultante de la etapa de actualización (b), y (d2) transmitir una orden de cambio de topología a la red, incluyendo dicha orden información sobre el nuevo modelo de topología de árbol de expansión, caracterizado - porque dicha etapa de detección (a) comprende una de las etapas siguientes: (a1) detectar un evento de cambio de topología local, o (a2) detectar un evento de cambio de topología no local recibiendo un paquete de datos de evento de cambio de topología o un paquete de datos de orden de cambio de topología desde la red, y - porque la etapa de detección (a) va seguida por la etapa de - si el evento detectado es un evento local, transmitir una información de evento de cambio de topología, TCE, y una información de topología de elemento de red, BTI, a la red.
Description
Procedimiento y aparato para la reconfiguración
rápida de una topología de red.
La presente invención se refiere en general a
redes informáticas, y más específicamente a un elemento de red y a
un procedimiento para controlar un elemento de red.
El algoritmo de árbol de expansión (STA,
Spanning Tree Algorithm) implementado según la norma
IEEE802.1D se desarrolla en puentes para evitar bucles en una red.
También se utiliza STA para conseguir redundancia. Los puertos
redundantes son importantes como puertos de respaldo en caso de
fallo en una red. Se hace referencia a tales puertos como puertos
de bloqueo. Se selecciona uno de los puentes en la red como puente
raíz. El puente raíz se convierte en el punto central en la red.
Todas las demás decisiones en la red, tales como qué puertos están
en estado de bloqueo y qué puerto está reenviando paquetes, es
decir, estado de reenvío, se toman desde la perspectiva del puente
raíz. Entre los puentes se intercambia información relacionada con
STA tal como parámetros de coste de ruta e Id de puente. Esta
información se lleva en unidades de datos del protocolo de puente
(BPDU, Bridge Protocol Data Unit). Estos parámetros se
usan para formar el árbol de expansión (ST, Spanning Tree).
Los paquetes de BPDU pueden recibirse en un puerto de bloqueo, pero
no se reenvían otros paquetes en un puerto de bloqueo. Qué puertos
están bloqueando en un ST depende del coste de ruta. Cualquier
puerto habilitado de ST puede estar bloqueando cualquier puente en
la red, incluido el puente raíz. El puerto que recibe la mejor BPDU
en un puente es el puerto raíz. Éste es el puerto que está más
próximo al puente raíz en cuanto a coste de ruta raíz. Por tanto,
cada puerto de puente en la red presenta un coste de ruta raíz
asociado con el mismo. Éste es la suma de los costes de ruta para
cada puerto de puente que recibe tramas reenviadas desde la raíz en
la ruta menos costosa al puente.
Los principios para gestionar un evento de
cambio de topología tal como una pérdida de enlace o error de enlace
en un enlace de puntos de red que es parte de la topología activa
se describen en la norma IEEE802.1D. Un puente puede cambiar la
topología activa de la red con puentes, en la que se recibe un
evento de este tipo. El puente transmitirá una BPDU de notificación
de cambio de topología (TCN, Topology Change Notification)
en la red a la que está unido su puerto raíz. Esta transmisión se
repite hasta que el puente recibe una confirmación de recepción de
cambio de topología (TCA, Topology Change Acknowledgment). La
TCA se lleva en una BPDU de configuración, así finalmente se
confirmará la recepción de la TCN o tendrá lugar una reconfiguración
adicional. El siguiente puente, es decir, el puente designado, en
la ruta hacia el puente raíz pasa la TCN hacia la raíz usando el
mismo procedimiento.
Si la raíz recibe una TCN tal, o cambia la
topología por sí misma, establecerá una bandera de cambio de
topología, bit de TC, en todos los mensajes de configuración
transmitidos durante algún tiempo. Este tiempo es tal que todos los
puentes recibirán uno o más de los mensajes de configuración o
tendrá lugar una reconfiguración adicional. Las entradas de
dirección dinámica caducarán más rápidamente mientras esta bandera
está activa. Esto significa que las entradas que ya no son válidas
debido al cambio de topología se retirarán de una forma
razonablemente rápida de aquellos puertos puente, en los que ya no
están presentes.
La capacidad para detectar cambios de topología
puede habilitarse o deshabilitarse en función del puerto. La
intención de esta prestación de la norma IEEE802.1D es permitir
deshabilitar la detección de cambio de topología en puertos en los
que se sabe que está conectada una única estación final, y en los
que el encendido y apagado de esa estación final provocaría el
disparo del mecanismo de TCN.
El algoritmo de árbol de expansión rápido (RSTA,
Rapid Spanning Tree Algorithm) es una norma nueva, véase
IEEE802.1w para más detalles. Esta norma es una mejora del STA.
La característica más importante del RSTA en
comparación con el STA es un paso rápido de un puerto al estadio de
reenvío. El STA tradicional esperaba pasivamente a que la red
convergiera antes de cambiar un puerto al estado de reenvío.
Una convergencia más rápida se consigue dando
ajuste a los parámetros de STA por defecto conservadores, reduciendo
el número de estados de puerto y aprovechando el hecho de que los
enlaces entre los puentes modernos en la mayor parte de los casos
se basan ahora en conectividad dúplex completa. En RSTP ya sólo
quedan tres estados de puerto, correspondientes a los tres estados
operativos posibles. Es decir, rechazo, aprendizaje y bloqueo. Los
estados de la norma 802.1D: desactivado, bloqueo y escucha se han
fusionado en un único estado de rechazo según la norma 802.1w.
RSTA puede confirmar activamente que un puerto
puede pasar de manera segura a reenvío sin basarse en ninguna
configuración de temporizador.
Otra diferencia entre STA y RSTA es la
transmisión de paquetes de BPDU. Un puente no raíz de STA sólo
genera BPDU cuando reciba un paquete tal en su puerto raíz. Así,
realmente un puente de STA transmite BPDU en vez de generarlas
realmente. Este no es el caso de RSTA. Un puente de RSTA envía una
BPDU con su información actual con un intervalo regular (es decir,
tiempo de saludo de puente: 1 a 10 segundos). El mecanismo de cambio
de topología de RSTA también se cambia en comparación con STA. Un
puente modificará su tabla de direcciones dinámicas si se recibe un
paquete de paquete de BPDU y se activa el bit de TC.
El tiempo necesario para cambiar los estados de
puerto del ST en una red habilitada de RSTA se mejora de manera
significativa en comparación con STA. Sin embargo, un paquete de
BPDU en una red habilitada de RSTA sigue enviándose sólo en un
segmento LAN. Una BPDU no se envía directamente a través de un
puente habilitado de RSTA. Esto significa que cada puente
habilitado de RSTA introducirá cierta latencia en el intervalo de
milisegundos.
El establecimiento de una nueva topología activa
con una tabla de direcciones dinámicas correcta de cada puente para
una red de STA o RSTA en caso de un cambio de topología o cambio de
parámetros de STA o RSTA a través de administración se ve afectada
por el hecho de que la propagación de nuevos parámetros de BPDU por
la red y la propagación de nueva información de cambio de topología
requiere mucho tiempo. El tiempo necesario para establecer una
nueva topología activa es de 30 a 60 segundos en caso de STA y
normalmente de unos pocos segundos para RSTA. Esto es inaceptable
para aplicación de red con requisitos de tiempo real tales como voz
sobre IP, flujo continuo de vídeo (video streaming) o
sistemas de automatización.
La patente US nº 6.262.977 describe un
procedimiento mejorado para el STA para conseguir una
reconfiguración más rápida de una red en caso de un cambio de
topología. Se retiran algunos de los estados de puerto del ST y
puede conseguirse que la transición entre los estados sea más
rápida. Un puente en una red basada en este procedimiento conoce la
identificación del puente raíz y ha clasificado su puerto en
diferentes funciones, es decir, un puerto raíz, uno o más puertos
designados y uno o más puertos alternativos. El paso rápido de
bloqueo a reenvío de un puerto de puerto alternativo a puerto raíz
puede realizarse basándose en este procedimiento.
El documento de patente 0 684 716 da a conocer
una disposición de ST con nodos de red que permiten una
reorganización de ST rápida, establecimiento de nodo propio y
recuperación de ST rápida en caso de fallos de red múltiples.
El tiempo necesario para establecer una nueva
topología activa en un tipo de red Ethernet es un parámetro
crítico. Los protocolos de redundancia de red establecidos tales
como STA y RSTA son a menudo demasiado lentos para muchas
aplicaciones.
Un objetivo principal de esta invención es
añadir nuevas técnicas a estas normas y a normas similares para
conseguir un tiempo de reconfiguración en el intervalo de
milisegundos para topologías de red complejas que impliquen varios
bucles de red.
Los inconvenientes de la solución de la técnica
anterior se superan mediante un procedimiento, un elemento de red y
una red informática tal como se explica en las reivindicaciones
independientes adjuntas.
Objetivos y ventajas adicionales se consiguen
mediante las características explicadas en las reivindicaciones
dependientes.
A continuación, se describirá la invención con
más detalle a título de ejemplos y haciendo referencia a los
dibujos adjuntos, en los que
La figura 1 es un diagrama de bloques
simplificado de un elemento de red administrado por multipuerto
genérico,
la figura 2 es un diagrama de bloques
esquemático de una implementación para reconfiguración rápida de una
topología de red en un elemento de red,
la figura 3 es un gráfico que ilustra una
topología de árbol de expansión.
La figura 4a es un gráfico que ilustra una
topología de árbol de expansión activa, cuando se produce un evento
de cambio de topología,
la figura 4b es un gráfico que ilustra los
estados de puerto tras el evento de cambio de topología,
la figura 4c es un gráfico que ilustra la nueva
topología de árbol de expansión activa tras el evento de cambio de
topología.
La figura 5a es un gráfico que ilustra una
topología de árbol de expansión activa, en la que se usa otro tipo
de evento diferente de cambio de enlace o cambio de parámetro de
coste de ruta como evento de cambio de topología.
\newpage
La figura 5b es un gráfico que ilustra la nueva
topología de árbol de expansión activa tras superar un umbral de
contador de errores en uno de los enlaces.
La figura 6a es un gráfico que ilustra una
topología en la que se selecciona uno de los puentes raíz como el
subraíz para una TCA dada.
La figura 6b es un gráfico que ilustra una
topología en la que se selecciona el puente raíz como el subraíz
para una TCA dada
la figura 7a es un gráfico que ilustra una
topología en la que se ha producido una TCA de "desactivación de
enlace" y en la que los puentes de detección de TCA gestionan la
TCA.
La figura 7b es un gráfico que ilustra la nueva
topología activa después de manejar el TCE de "desactivación de
enlace" en la Figura 7a.
La figura 8a es un gráfico que ilustra una
topología en la que se ha producido una TCA de "desactivación de
enlace" se produjo debido a una pérdida de puente, en el que el
TCE representa un escenario de múltiples TCE.
La figura 8b es un gráfico que ilustra la nueva
topología activa después de gestionar el TCE de "desactivación de
enlace" en la figura 8a.
La figura 9a es un gráfico que ilustra una
topología en la que se ha producido una TCA de "desactivación de
enlace" debida a una pérdida de puente, y en la que los puentes
de detección de TCA gestionan la TCA.
La figura 9b es un gráfico que ilustra la nueva
topología activa después de gestionar el TCE de "desactivación de
enlace" en la figura 9a.
La figura 10a es un conjunto de cuatro
diagramas de flujo de BTI,
la figura 10b es un conjunto de diagramas de
flujo que ilustra un proceso de activación de enlace de puerto, un
proceso de desactivación de enlace de puerto de ST y un proceso de
cambio de parámetro de coste de ruta,
la figura 11 es un diagrama de flujo de
TCE,
la figura 12a incluye un diagrama de flujo de
transmisión de TCC y un diagrama de flujo de temporizador de
TCC,
la figura 12b es un diagrama de flujo de
recepción de TCC,
la figura 13 incluye un diagrama de flujo de
transmisión de TCA y un diagrama de flujo de recepción de TCA,
la figura 14 incluye un diagrama de flujo de
transmisión de MTU y un diagrama de flujo de recepción de MTU,
y
la figura 15 incluye un diagrama de flujo de
recepción de TSC, un diagrama de flujo de transmisión de TSC y un
diagrama de flujo de TDC.
La figura 1 es un diagrama de bloques
simplificado de un elemento de red administrado por multipuerto
genérico según la invención. El elemento de red comprende un núcleo
de conmutación y un módulo de CPU. Entre estos dos módulos se
envían datos por paquetes e información de administración. Por
motivos de simplicidad y legibilidad, el término "elemento de
red" se sustituye por el término "puente" en la siguiente
descripción detallada. La implementación descrita a continuación es
sin embargo relevante para varios tipos de elementos de red, por
ejemplo puentes, conmutadores, encaminadores, pasarelas, etc., y
así, el alcance de la invención se refiere a elementos de red en
general, aunque a modo de ejemplo en la presente memoria se
mencionan específicamente puentes.
La figura 2 es un diagrama de bloques
esquemático de una implementación para reconfiguración rápida de una
topología de red en un puente según la invención.
Un conjunto de paquetes puede transmitirse entre
los puentes en la red para conseguir una reconfiguración rápida
según la invención. El conjunto puede incluir paquetes de los
siguientes tipos:
- Información de topología de puente (BTI)
- Evento de cambio de topología (TCE)
- Orden de cambio de topología (TCC)
- Confirmación de recepción de cambio de
topología (TCA)
- Actualización de tabla de MAC (MTU)
- Orden de guardado de topología (TSC)
- Orden de diferencia de topología (TDC)
Dichos paquetes se envían al hardware local, es
decir, los puertos físicos conectados a la red, y se reciben desde
el hardware local a través del módulo de "Mensajes a y desde otros
puentes en la red" 5 y el módulo de "Acción" 1. El módulo
de "Acción" 1 gestiona la operación para la reconfiguración
rápida de una topología de red. Esto implica la configuración del
hardware local tal como ajustes de estado de puerto a través del
módulo de "Control de hardware local", 11, cálculo de la
topología total y cambios de identificación de topología a través
del "Calculador de topología" 2, basándose en la información
BTI, TCE y/o TCC recibida o un TCE detectado local recibido a
través del módulo de "Lógica de detección de TCE local" 3. El
modelo de árbol de expansión (modelo de ST) almacenado se actualiza
con información obtenida del TCE. El modelo de ST contiene un
subconjunto de la red. El subconjunto contiene todos los puentes o
sólo algunos de los puentes en la red.
El módulo de "Acción" 1 también presenta
una interfaz con el módulo de "Identificar manejador de topología
de puente" 7. El módulo de "Identificar manejador de topología
de puente" 7 tiene la función de verificar si el propio puente
es el manejador de topología de puente (BTH) o no. Si el puente es
un BTH, iniciará un procedimiento de cambio de topología basándose
en el modelo de ST para gestionar el TCE, en el que el subconjunto
en el modelo de ST incluye por lo menos el puente, el origen del TCE
y los puentes a los que afecta el cambio de topología.
A continuación se indican cuatro ejemplos de
conjunto de reglas que se usan por el módulo de identificar
manejador de topología de puente 7 para determinar si el puente es
el BTH para el TCE recibido o no. Un experto en la materia
comprenderá que también pueden aplicarse otros conjuntos de
reglas.
- \quad
- Conjunto de reglas 1. El puente raíz siempre actúa como el BTH,
- \quad
- Conjunto de reglas 2. Un número restringido de puentes subraíz puede actuar como el BTH,
- \quad
- Conjunto de reglas 3. Cualquier puente subraíz puede actuar como el BTH, o
- \quad
- Conjunto de reglas 4. El puente de detección de TCE actúa como el BTH.
El conjunto de reglas aplicado para un puente
también debe aplicarse para otros puentes en la red. Así, la
selección de un conjunto de reglas se lleva a cabo en una fase
inicial del establecimiento de la red, y los datos identificadores
del conjunto de reglas que se aplicará debe transmitirse a cada
puente que se incluye posteriormente para operar en la red.
Según el conjunto de reglas 1, el puente
presenta más o menos la misma funcionalidad que el puente raíz en
una implementación STA o RSTA. El puente raíz en la red es el
manejador de topología de puente para cualquier TCE.
Según el conjunto de reglas 2 y 3, un puente
subraíz como BTH para un TCE dado se identifica basándose en la
ubicación del TCE en el ST. El puente subraíz para un TCE dado puede
definirse como el puente más superior en un subárbol, cuando el
subárbol está definido como la parte del ST afectada por el TCE.
Si se aplica el conjunto de reglas 2, sólo un
número restringido de puentes puede actuar como un BTH. En este
caso, el módulo de identificar manejador de topología de puente
lleva a cabo las etapas siguientes:
en primer lugar, el puente determina si está
habilitado para operar como un BTH. El puente no es el BTH para el
TCE dado, si no está habilitado para operar como un BTH.
Si el puente está habilitado para operar como un
BTH, el puente recuperará de la base de datos que contiene el
modelo de árbol de expansión información que indica si el origen del
TCE está incluido en el subárbol para el que el puente es el
subraíz. En caso contrario, el puente no es el BTH.
Por el contrario, se lleva a cabo una prueba
para decidir si otro subárbol está también implicado en el TCE. Si
no es así, el puente es el BTH para el TCE dado.
Si por otro lado está implicado otro subárbol,
se aplica además una regla de prioridad para determinar si el
puente es el BTH o no.
Si se aplica el conjunto de reglas 3, cualquier
puente puede actuar como el BTH. En este caso, se lleva a cabo una
primera prueba para determinar si el TCE está asociado al puerto
raíz del puente. Si es así, el puente no es el BTH para el TCE.
Si la primera prueba da falso, se lleva a cabo
una segunda prueba para determinar si el TCE implica la introducción
de un bucle en la topología de red. Si esta segunda prueba da
falso, y el TCE es un evento local para el puente, se determina que
el puente es el BTH para el TCE. Si no, si la segunda prueba da
falso y el TCE es no local (es decir, originalmente detectado por
otro puente y detectado por este puente mediante la recepción de un
paquete de datos de TCE), se determina que el puente no es el BTH
para este TCE.
Si la segunda prueba da verdadero, se lleva a
cabo una tercera prueba para determinar si el puente está incluido
en el bucle establecido por el TCE, y también lo más cerca de la
raíz en cuanto a coste de rutas. Si esta prueba da falso, el puente
no es el BTH para este TCE. Si no, si la tercera prueba da
verdadero, el puente es el BTH para el
TCE.
TCE.
Si se aplica el conjunto de reglas 4, el puente
de detección de TCE también es el BTH para el TCE. Todos los
puentes en la red pueden actuar como un BTH si los puentes soportan
el conjunto de reglas 4. Este conjunto de reglas se basa en el
principio de que el puente o puentes de detección de TCE gestionarán
el procedimiento de cambio de topología.
En este caso, el puente simplemente determina si
el TCE es un TCE local. Si es así, el puente es también el BTH. Por
el contrario, el puente no es el BTH.
Las implementaciones basadas en el conjunto de
reglas 2, 3 ó 4 no dependen de una función de puente raíz
tradicional. El puente raíz sólo se usa como un punto central para
el cálculo de la topología de red, y no participa en el
establecimiento de una nueva topología de red a menos que el puente
raíz está afectado por el TCE.
Si la salida desde el módulo "Identificar
manejador de topología de puente" indica que el propio puente es
el manejador de topología de puente para el TCE, se activa el módulo
de Iniciar procedimiento de cambio de topología 8. Si no, se activa
el módulo "Esperar información de TCC o MTU nueva" 6. Otro
puente se establecerá como el BTH para el TCE.
El puente comprende tres bases de datos: la base
de datos DBA 12 contiene topología nueva (en procesamiento), la
base de datos DBB 13 contiene topología activa de la red y la base
de datos DBC 14 contiene topología de instalación (copia guardada
de topología de diseño).
El BTH envía información de TCC y en la mayoría
de los casos de MTU a los demás puentes, y puede solicitar una TCA
de alguno de los demás puentes para verificar que se llevan a cabo
los cambios requeridos. Un puente de detección de TCE envía un
paquete de TCE a la red tanto si el puente es un BTH como si no. Dos
paquetes de TCE producidos por un único TCE pueden recibirse en el
BTH puesto que a menudo dos puentes de detección de TCE detectan el
mismo TCE. El módulo de "Identificar manejador de topología de
puente" 7 comprueba diferencias entre la base de datos DBA 12 y
DBB 13, en las que la base de datos DBA contiene la nueva topología
después de haberse producido uno o más TCE y la DBB contiene la
topología activa antes del TCE o los TCE.
El módulo de "Calculador de topología" 2
está conectado a las bases de datos y está dispuesto para actualizar
el contenido de base de datos de todas las bases de datos basándose
en solicitudes del módulo de "Acción" 1. El calculador de
topología está dispuesto además para obtener los cambios de
topología requeridos en la red en el propio puente y en todos los
demás puentes en la redes afectadas por el TCE. Los cambios
requeridos contienen nuevos estados de puerto e información de MTU
para todos los puentes afectados por el TCE. El módulo de
"Acción" 1 también debe gestionar múltiples TCE, es decir, uno
o más TCE nuevos se reciben a través del módulo de "Lógica de
detección de TCE local" o a través de la recepción de paquetes de
TCC, TCE mientras está en curso un procedimiento de cambio de
topología. Este procedimiento se interrumpe y el puente más superior
en el subárbol que cubre todos los TCE actuará como el BTH si los
puentes soportan la funcionalidad del conjunto de reglas 2, 3 ó 4.
De otro modo, el puente raíz siempre debe actuar como el BTH. El
puente puede recibir paquetes de TSC desde por ejemplo una estación
de administración de red, en la que se ordena al puente que
almacene la topología actual o una topología específica en la base
de datos C 14. Esta topología se considera la topología preferida.
Una topología activa que difiriese de la topología preferida podría
disparar una alarma, es decir, un paquete de TDC.
El primer módulo de comparación 15 está
dispuesto para determinar que hay una diferencia entre el contenido
de la base de datos DBA y la base de datos DBB.
El segundo módulo de comparación 16 está
dispuesto para determinar que hay una diferencia entre el contenido
de la base de datos DBB y la base de datos DBC.
El módulo de "Entrada de administración" 10
también puede influir en la operación del módulo de "Acción" 1.
Los parámetros de coste de ruta pueden cambiarse desde el módulo de
Entrada de administración 10, y la transmisión de paquetes de TSC
puede dispararse desde este módulo 10.
\vskip1.000000\baselineskip
La información de topología total se conocerá
preferentemente en cada puente en la red. Así, cada puente puede
establecer el ST total incluyendo los estados de puerto en cada
puente y dónde esta conectado cada puerto. El ST se calcula
basándose en los mismos principios que se usan para el STA y RSTA o
técnicas similares. Un puente reenviará paquetes BTI a sus puentes
contiguos incluyendo varios registros de BTI, conteniendo cada
uno:
- -
-
\vtcortauna
- -
-
\vtcortauna
- \circ
-
\vtcortauna
- \circ
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
El puente genera un registro de BTI para el
propio puente y para cada puente contiguo y todos los demás puentes
que puedan alcanzarse a través de estos puentes contiguos por
puertos de reenvío, menos el puente contiguo en el que se envía el
paquete de BTI y los puentes que sólo pueden recibirse por este
puente por puertos de reenvío. Un paquete de BTI puede enviarse
desde el CPU de puente tanto en los puertos de reenvío como de
bloqueo y sólo en un segmento de LAN. Es decir, un paquete de BTI
sólo se reenviará a la CPU de un puente contiguo. Esto significa
que la propagación de BTI durante el inicio requerirá un tiempo de
inicio adicional. Sin embargo, se generan nuevos paquetes de BTI
una vez que los paquetes de BTI, TCC o TCA lleguen con nueva
información de topología o se genera un TCE local, mientras que se
envían paquetes de BTI en un intervalo regular cuando la topología
es estática.
Se eliminará un registro de BTI para un puente y
para todos los puentes que sólo pueden recibirse por este puente si
no se recibe ningún paquete de BTI nuevo en un puerto dado durante
un intervalo de tiempo predefinido.
En una topología de red redundante son
importantes tanto la disponibilidad de enlace como la velocidad de
enlace de puntos. El STA utiliza costes de ruta definidos por el
usuario y la velocidad como parámetros de coste de ruta. Sin
embargo, también podrían considerarse otros parámetros como
parámetros de coste de ruta. Pueden utilizarse los siguientes
parámetros adicionales:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
La figura 5a es un gráfico que ilustra una
topología de árbol de expansión activa, en la que se usa otro tipo
de evento diferente de cambio de enlace o cambio de parámetro de
coste de ruta como evento de cambio de topología. Se usa "CRC y
otros contadores de errores" como un criterio para calcular un ST
que difiera de un ST basándose sólo en el cálculo del coste de ruta
de STA.
La figura 5b es un gráfico que ilustra la nueva
topología de árbol de expansión activa tras superar un umbral de
contador de errores en uno de los enlaces.
La figura 10a es un conjunto de cuatro diagramas
de flujo de BTI, identificados por 10A, 10B, 10C y 10D,
respectivamente.
En la figura 10a, 10A hay un diagrama de flujo
para la gestión de una expiración de BTI. La salida marcada como
"TCE de expiración de BTI" enlaza con una entrada marcada de
manera idéntica con el diagrama de flujo de TCE en la figura
11.
Como se describe con referencia a la figura 11,
se actualizan las bases de datos A y B en caso de una expiración de
BTI, se envía nueva información BTI en los puertos de ST (10D) y se
genera un TCE de expiración de BTI local.
En la figura 10a, el diagrama de flujo 10B
muestra cómo se gestiona la recepción de un paquete de BTI desde un
puente contiguo que soporta reconfiguración rápida. La salida
marcada como "TCE de actualización de DB de BTI" enlaza con
una entrada marcada de manera idéntica al diagrama de flujo de TCE
en la figura 11. Como se describe con referencia a la figura 11, se
actualizan las bases de datos A y B si la BTI contiene nueva
información de topología, se envía BTI nueva en los puertos de ST
(10D) y se genera un TCE de actualización de DB de BTI.
\newpage
En la figura 10a, el diagrama de flujo 10C
muestra la operación de BTI periódica en la que información BTI se
envía en un intervalo regular en todos los puertos de ST.
En la figura 10a, el diagrama de flujo 10D
muestra la transmisión asíncrona de un paquete de BTI en caso de un
disparo de evento de BTI provocado por un TCE local.
La figura 10b es un conjunto de diagramas de
flujo que ilustra un proceso de activación de enlace de puerto
(10E), un proceso de desactivación de enlace de puerto de ST (10F) y
un proceso de cambio de parámetro de coste de ruta (10G),
respectivamente.
En la figura 10b, el diagrama de flujo de
activación de enlace de puerto (10E) describe cómo se identifican
los puertos de puente que soportan reconfiguración rápida y el
establecimiento de un puerto no puente en estado de reenvío una vez
que el puerto está identificado como puerto no puente. El puerto se
pone en estado de bloqueo y se inicia un temporizador cuando se
produce un evento de activación de enlace. A continuación se
comprueba si se recibe un paquete de BTI en este puerto o no. El
puerto se considera como un puerto de puente y luego vuelve a
esperar un nuevo evento de activación de enlace si se recibe un
paquete de BTI. Se lleva a cabo una comprobación de una expiración
si no se recibe un paquete de BTI. El puerto se pone en estado de
reenvío inmediatamente si se produce una expiración; de otro modo,
continúa comprobando los paquetes de BTI. Se actualizan las bases
de datos A y B, véase la figura 11, se envía nueva información BTI
en los puertos de ST (10D) y se genera y envía un TCE de activación
de enlace local TCE al diagrama de flujo de TCE si el puerto se
identifica como puerto de ST.
En la figura 10b, el diagrama de flujo de
desactivación de enlace de puerto de ST (10F) configura el puerto
de ST local en caso de un evento de desactivación de enlace de
puerto de ST, actualiza correspondientemente las bases de datos A y
B, véase la figura 11, se envía nueva información BTI en los puertos
de ST (10D) y se genera un TCE de desactivación de enlace
local.
En la figura 10b, el diagrama de flujo de cambio
de parámetro de coste de ruta (10G) configura el puerto de ST local
en caso de un evento de cambio de parámetro de coste de ruta,
actualiza correspondientemente las bases de datos A y B, véase la
figura 11, se envía nueva información BTI en los puertos de ST (10D)
y se genera un TCE de cambio de parámetro de coste de ruta
local.
La transmisión de paquetes de BTI basada en
eventos, disparo de eventos de BTI, también pretende gestionar la
situación en la que difiere la BTI en los puentes. Esto puede
suceder cuando se pierden los paquetes para reconfiguración rápida
de la red, o no se detecta un escenario de TCE múltiple en todos los
puentes en la red.
\vskip1.000000\baselineskip
Los siguientes eventos locales generan un
TCE:
- -
- enlace entre dos puentes con soporte de reconfiguración rápida establecido.
- -
- Enlace entre dos puentes con soporte de reconfiguración rápida perdido.
- -
- Parámetros de coste de ruta cambiados.
- -
- Expiración de BTI.
- -
- Actualización de DB (base de datos) de BTI
\vskip1.000000\baselineskip
El puente de detección de TCE genera un paquete
de TCE. Un paquete de TCE contiene lo siguiente:
- -
- identificador de paquetes de TCE.
- -
- Id de puente de BTH
- -
- Id de puente de puente de detección de TCE
- -
- tipo de TCE.
- -
- Nueva BTI de puente de detección de TCE.
Se envía un paquete de TCE al BTH a través de
todos los puentes entre el puente de detección de TCE y el BTH, sin
retarse por ninguna CPU de puente. Un paquete de TCE puede recibirse
en un puerto de bloqueo, pero entonces sólo se reenviará a la CPU
de puente. Un paquete de TCE recibido en un puerto de reenvío se
reenviará a la CPU de puente y otros puertos de reenvío, pero no en
cualquier puerto de bloqueo. Así, el paquete de TCA no sólo se
recibe por el BTH, sino también por otros puentes en la red. Estos
puentes sabrán al recibir un paquete tal que se ha iniciado un
procedimiento de cambio de topología. Se envía un paquete de TCE
desde el puente de detección de TCE aunque el puente local sea el
BTH.
La propagación del paquete de TCE a través de la
red debería basarse preferentemente en comunicación por
multidifusión o difusión. Sin embargo, también es posible basar la
implementación en comunicación por unidifusión, aunque esto
implicará transmisión de la misma información varias veces.
Un puente que detecta un TCE no cambiará el
estado de ninguno de sus puertos de ST a estado de reenvío, antes
de que el BTH se lo indique. El estado inicial de un puerto se
establecerá primero a bloqueo mediante el puente de detección de
TCE sin ninguna interacción con el BTH o ningún otro puente.
El mismo TCE puede detectarse en dos puentes.
Por ejemplo establecimiento de enlace o pérdida de enlace entre dos
puentes. El BTH debe poder gestionar la situación en la que pueden
enviarse dos paquetes de TCE desde cada uno de los puentes de
detección de TCE al BTH. Esto puede evitarse en caso de un
establecimiento de enlace, si se intercambian paquetes de BTI en el
nuevo enlace entre los dos puentes. La BTI para los dos puentes
puede utilizarse para identificar cuál de los puentes enviará el
paquete de TCE o gestionará el TCE si uno de los puentes es el BTH.
También es conveniente que el puente de detección de "activación
de enlace" que se convierte en el BTH para este TCE espere un
intervalo de tiempo predefinido después de haber enviado BTI nueva y
se envíen los paquetes de TCE antes de continuar el procedimiento
de cambio de topología. El intervalo de tiempo predefinido Tprop,
debería ser más largo que el tiempo máximo necesario para propagar
nueva información de topología a través de la red utilizando
paquetes de BTI. Esto es relevante para detectar un escenario de TCE
múltiple en la red. Esta implementación tiene relevancia particular
en caso de un TCE de "activación de enlace" puesto que este
TCE puede introducir bucles temporales en caso de un escenario de
TCE múltiple.
La figura 11 muestra el diagrama de flujo de
TCE. Se entra en el diagrama de flujo de TCE cuando se detecta un
TCE local o cuando se recibe un paquete de TCC o TCE.
Se actualizan las bases de datos A y B basándose
en el TCE recibido, se envía un paquete de TCE a la red en los
puertos de ST en caso de un TCE detectado local y a continuación se
lleva a cabo una comprobación de un escenario de TCE múltiple. Un
escenario de TCE múltiple no está presente si el puente recibe
varios TCE producidos por el mismo evento. Así, el puente debe
poder verificar si dos TCE recibidos describen el mismo evento o
no. El contenido de las bases de datos de A y B difiere en caso de
que un procedimiento de cambio de topología está en curso. Así,
pueden compararse estas dos bases de datos para verificar si está
presente o no un escenario de TCE múltiple, cuando se recibe un
nuevo TCE. Se interrumpe un procedimiento de cambio de topología en
curso que está desarrollándose en el puente si se identifica un
escenario de TCE múltiple y se actualizan las bases de datos A y B
con los nuevos estados de los puertos locales de ST. El único puerto
de ST en estado de reenvío podría ser por ejemplo el puerto raíz
tal como se define en el STA. A continuación se lleva a cabo una
comprobación para verificar si el puente es un BTH para el o los
TCE actuales en caso de un escenario de TCE múltiple. Se entra en
el diagrama de flujo de transmisión de TCC si el puente se
identifica como el BTH, véase la figura 12a, mientras que se entra
en el diagrama de flujo de recepción de TCC en caso de que el puente
no sea el BTH, y se ha recibido un paquete de TCC.
\vskip1.000000\baselineskip
El BTH genera uno o más paquetes de TCC que se
envían como un paquete de multidifusión o difusión a cada puente en
la red basándose en el paquete de TCE recibido o la detección de TCE
local. El paquete de TCC contiene lo siguiente:
- identificador de paquetes de TCC
- referencia de TCC
- parámetros de ID de puente de BTH
- BTI para toda la red
- Solicitud de confirmación de recepción
- Solicitud de información de MTU
- Información de MTU
También puede utilizarse comunicación por
unidifusión, aunque entonces deben enviarse varios paquetes de TCC
mediante el BTH para cada puente que está afectado por la nueva
topología de ST.
El BTH calcula un nuevo ST basándose en el
paquete de TCE recibido y los registros de BTI de cada puente. El
algoritmo para encontrar el ST óptimo se basa en los mismos
principios que se usan para STA.
El campo "BTI para toda la red" del paquete
de TCC contiene un registro de BTI para cada puente en la red. El
BTH puede seleccionar entrar en un estado intermedio, en el que la
topología de red aísla en cierta medida una parte de la red para
evitar bucles temporales o para poder alcanzar puentes que no pueden
alcanzarse a través de puertos de reenvío antes de establecer la
nueva topología final. Esto puede requerir la transmisión de más de
un paquete de TCC. La entrada en un estado de ST intermedio es
relevante en la mayoría de los casos cuando se produce un escenario
de TCE múltiple.
Ninguna CPU de puente se retardará un paquete de
TCC. Un paquete de TCC puede recibirse en un puerto de bloqueo,
pero entonces se reenviará sólo a la CPU de puente. La propagación
del paquete de TCC a través de la red depende de si se utiliza
comunicación por difusión, multidifusión o unidifusión:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
El campo "Solicitud de confirmación de
recepción" especifica a qué puentes se ordena generar una
confirmación de recepción, es decir, un paquete de TCA.
El campo "Solicitud de confirmación de
recepción" puede usarse para comprobar si un puente todavía está
conectado a la red y el buen estado del puente en caso de por
ejemplo un TCE de expiración de BTI.
El campo "Solicitud de información de MTU"
especifica a qué puentes se ordena añadir información de
actualización de tabla de MAC (MTU) en sus paquetes de TCA. Esta
información se usa por los puentes que necesitan actualizar sus
tablas de MAC después de haber surtido efecto el cambio de
topología.
El BTH puede enviar un paquete de MTU separado o
añadir información de MTU directamente a la TCC en lugar de
utilizar la "Solicitud de información de MTU" en el paquete de
TCC, cuando todos los paquetes de TCA se reciben después de la
transmisión de un paquete de TCC. El envío de un paquete de MTU es
relevante en caso de varios cambios en la topología de red,
mientras que el uso del campo "Solicitud de información de MTU"
o la adición de información de MTU directamente al campo
"Información de MTU" son más relevantes en caso de un cambio
de topología secundario en la red.
La figura 12a incluye un diagrama de flujo de
transmisión de TCC y un diagrama de flujo de temporizador de
TCC.
En la figura 12a, se entra en el diagrama de
flujo de TCC de transmisión del BTH cuando el módulo "Acción"
(véase la figura 2) ha verificado que no hay otro procedimiento de
cambio de topología en curso a menos que se ha identificado un
escenario de TCE múltiple y el puente sea el BTH para todos los TCE
pendientes. Se calcula el nuevo ST basándose en cualquier cambio o
cambios de topología que han disparado la TCC y se copia el nuevo
ST a la nueva base de datos de topología, A, véase la figura 2, y se
implementan los cambios relacionados con el propio puente, en el
puente y se actualiza la base de datos, B, actual con esta
información. El puente comprueba si debería entrarse en un estado
intermedio de ST antes de establecer el nuevo ST para evitar bucles
temporales antes de alcanzar esta nueva topología de ST. La
configuración y el contenido de la base de datos del puente se
cambian correspondientemente si se requiere un estado de ST
intermedio. El puente verifica si se requiere una TCA de uno o más
puentes en la red y si la TCA solicitada debería contener o no
información de MTU. Si no se requieren paquetes de TCA, entonces se
añade información de MTU al paquete de TCC. En este caso, se recibe
una confirmación de recepción a través de la BTI nueva recibida en
un intervalo de tiempo predefinido. Si éste no se recibe en este
periodo de tiempo, entonces se retransmite el paquete de TCC, véase
el diagrama de flujo de temporizador de TCC para más detalles en la
figura 12a.
La figura 12b es un diagrama de flujo de
recepción de TCC, que ilustra el procedimiento de recepción de TCC
según una realización preferida de la invención. El diagrama de
flujo muestra las etapas que se llevan a cabo para manejar una
orden de cambio de topología recibida.
El procedimiento de recepción de TCC comprende
las etapas de actualizar el modelo de topología con información
BTI, determinar si se solicita una confirmación de recepción de
cambio de topología (TCA) en la orden TCC, determinar si se incluye
información de actualización de tabla de MAC (MTU) en la orden TCC,
y si se incluye MTU, llevar a cabo un procedimiento de recepción de
MTU (véase a continuación).
Más específicamente, en el procedimiento de
recepción de TCC, se copia BTI nueva para toda la red en la base de
datos A, véase la figura 2, se copia la BTI relacionada con el
propio puente a la base de datos B y también se implementan los
cambios de puente relacionados con el puente local. El puente
comprueba si el paquete de TCC recibido contiene información de MTU
o no. Se entra en el diagrama de flujo de recepción de información
de MTU si el TCC contiene tal información, véase la figura 14. Se
entra en el diagrama de flujo de transmisión de TCA si se solicita
una TCA, véase la figura 13.
A los puentes a los que el BTH ordena cambiar
sus estados de puerto en uno o más puertos también se les puede
ordenar enviar un paquete de confirmación de recepción de cambio de
topología de vuelta al BTH. Esto se especifica para cada puente en
el campo "Solicitud de confirmación de recepción" del paquete
de TCC.
Un paquete de TCA contiene lo siguiente:
- identificador de paquetes de TCA
- parámetros de Id de puente
- referencia de TCC
- información de MTU.
El paquete de TCA se reenvía hacia el BTH de la
misma manera que para los paquetes de TCE. El paquete de TCA está
previsto en primer lugar para el manejador de topología de puente,
aunque el paquete de TCA también puede contener información de MTU
si el campo "Solicitud de información de MTU" del paquete de
TCC recibido ordena al puente añadir "Información de MTU". La
MTU en los puentes que están afectados por el cambio de topología
puede llevarse a cabo una vez que se genere el último paquete de
TCA. El paquete de TCA debe propagarse no sólo al BTH si se
incluye información de MTU. Así, no puede utilizarse unidifusión si
el paquete de TCA contiene información de MTU.
Un puente que genera un paquete de TCA con
información de MTU debe calcular la información de MTU basándose en
su conocimiento de los cambios en la topología de red, véase la
siguiente sección: "Actualización de tabla de MAC (MTU)".
El BTH genera un nuevo paquete de TCC con la
misma referencia de TCC que el paquete de TCC previo si no se
recibe una TCA de cada uno de los puentes a los que se ordena
generar un paquete de TCA en un intervalo predefinido.
La figura 13 incluye un diagrama de flujo de
transmisión de TCA y un diagrama de flujo de recepción de TCA.
El diagrama de flujo de transmisión de TCA en la
figura 13 ilustra el procedimiento de transmisión de TCA que se
implementa según una realización preferida de la invención.
El procedimiento de transmisión de TCA comprende
la etapa de transmitir un paquete de TCA a la red, incluyendo dicho
paquete información de MTU calculada a partir del modelo de árbol de
expansión si se requiere información de MTU.
Más específicamente, se lleva a cabo una
comprobación para determinar si debería añadirse información de MTU
al paquete de TCA antes de enviar o no el paquete de TCA.
En la figura 13, el diagrama de flujo de TCA de
recepción comprueba que el paquete de TCA recibido es la TCA que ha
solicitado el BTH (el propio puente). El puente comprueba si debe
enviarse un nuevo paquete de TCC. Esto es relevante en caso de
utilizar un estado de ST intermedio. Se entra en el diagrama de
flujo de transmisión de TCC si se requiere otra TCC, véase la
figura 12a, mientras que se comprueba el paquete de TCA respecto a
un campo de MTU si no se requiere un nuevo paquete de TCC.
Se entra en el diagrama de flujo de recepción de
MTU, véase la figura 14, si se encuentra un campo de este tipo, en
caso contrario se entra en el diagrama de flujo de transmisión de
información de MTU, véase la figura 14.
El BTH o un puente al que se ha solicitado un
paquete de TCA con "Información de MTU" genera un paquete tal,
cuando el procedimiento de cambio de topología ha finalizado. La
información de MTU está prevista para aquellos puentes que están
afectados por el cambio de topología.
El algoritmo para encontrar los puentes y sus
puertos de ST que están afectados por el TCE se basa en los mismos
principios que se usan por STA excepto en que todo el ST se calcula
en cada puente en la red. Así, se calcula una nueva topología
activa y se compara con la topología activa anterior. Esos puentes y
aquéllos de sus puertos que difieran se identifican en la MTU.
El paquete de MTU contiene lo siguiente:
- identificador de paquetes de MTU
- Id de puente y puertos en los que se requiere
actualización de MAC.
Un paquete de MTU se propaga a través de la red
de la misma forma que un paquete de TCC. Así, se prefiere la
comunicación por multidifusión o difusión.
La figura 14 incluye un diagrama de flujo de
transmisión de MTU y un diagrama de flujo de recepción de MTU.
Según el diagrama de flujo de transmisión de MTU
mostrado en la figura 14, el BTH envía un paquete de MTU. La
información de MTU se calcula a partir de los datos en las bases de
datos A y B por el "Calculador de topología", véase la figura
2. A continuación se envía un mensaje de MTU a todos los puentes en
la topología y se actualiza la base de datos de topología activa,
la base de datos B en la figura 2.
El procedimiento de recepción de MTU, que se
implementa según una realización preferida de la invención, se
ilustra en el diagrama de flujo de recepción de MTU en la figura 14.
Según este procedimiento, el puente comprueba si el Id de puente
local se encuentra en la MTU tras la recepción de un paquete de MTU.
La MTU se rechazará si el puente ya ha recibido la misma
información de MTU de otro puente que ha detectado el mismo TCE. La
tabla de MAC se actualiza basándose en los puertos específicos y se
actualiza la base de datos de topología activa, la base de datos B
en la figura 2.
Durante el diseño de una red muchos parámetros
diferentes pueden asignarse a los puentes en la red que influirán
en la topología de red. Cuando toda la red está operativa según se
define durante el diseño la primera vez o después de una
reconstrucción o mejora de la red puede enviarse una orden de
guardado de topología (TSC) a todos los puentes en la red. Una TSC
puede generarse y enviarse mediante por ejemplo el puente raíz o por
ejemplo una estación de administración de red (NMS). Tal orden se
inicia normalmente por un usuario. Entonces se guarda una base de
datos duplicada que contiene una copia de la topología y puede no
cambiarse hasta que se recibe una TSC nueva. Esta topología se
considera la topología preferida de red. Puede usarse una diferencia
entre la topología preferida y la topología actual para generar una
alarma que se envía a una NMS predefinida, es decir, una orden de
diferencia de topología (TDC). Esto puede realizarse usando el
protocolo de administración de red simple (SNMP) popular o
protocolos similares. Los paquetes de TDC pueden enviarse en caso de
un TCE o en intervalos fijos mientras que la topología activa
difiera de la topología preferida almacenada en la base de datos
duplicada. Pueden usarse los siguientes principios para minimizar la
comunicación de paquetes de TDC:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
La figura 15 incluye un diagrama de flujo de
recepción de TSC, un diagrama de flujo de transmisión de TSC y un
diagrama de flujo de TDC.
Según una realización preferida, el
procedimiento según la invención comprende las etapas de recibir una
orden de guardado de topología (TSC) de la red, y guardar en una
base de datos el modelo de topología actual tras recibir una
TSC.
El proceso realizado tras la TSC recibida se
ilustra más específicamente mediante el diagrama de flujo de
recepción de TSC en la figura 15. Este proceso espera una orden TSC
recibida a través del módulo de "Acción", véase la figura 2.
Cuando se recibe una TSC se comprueba que se envía desde un puente
dentro de la topología activa, buscando en la base de datos B,
véase la figura 2. La orden se procesa adicionalmente si se
encuentra una coincidencia, si no se rechazará. El diagrama de
flujo de TDC se deshabilita durante el proceso de copia de la base
de datos.
En el proceso ilustrado por el diagrama de flujo
de transmisión de TSC en la figura 15, se realiza en primer lugar
una comprobación que no hay cambios de topología en progreso antes
de que se transmita ningún paquete de TSC cuando se recibe una
orden de transmisión de TSC. La orden se rechaza si hay un cambio de
topología en progreso, si no se enviarán los mensajes de TSC a
todos los demás puentes en la topología.
El proceso ilustrado por el diagrama de flujo de
TDC en la figura 15 enviará paquetes de TDC de forma regular si el
puente está configurado para este servicio y se encuentra una
diferencia entre las bases de datos B y C, véase la figura 2.
Los paquetes de TCE, TCC, TCA, MTU, TSC y TDC
deberían protegerse preferentemente mediante prioridad para reducir
la probabilidad de pérdida de paquetes y para conseguir mínima
latencia de red de estos paquetes.
Todas las figuras 3, 4a-c,
5a-b, 6a-b, 7a-b,
8a-b, 9a-b y 10a-b
ilustran ejemplos de topologías de árbol de expansión de una red,
en la que se incluyen elementos de red (a los que se hace referencia
como puentes por simplicidad). En todas estas figuras, los puentes
se identifican mediante los símbolos de referencia A...I y raíz,
respectivamente. Los números de puerto de un puente se indican
mediante el símbolo de referencia de puente seguido por un número
de puerto, tales como los puertos A5, A8 para el puente A. Los
números de puerto del puente raíz se indican mediante R1 y R2.
\vskip1.000000\baselineskip
La figura 3 es un gráfico que ilustra una
topología inicial de árbol de expansión de una red. Cada puente en
la red es un elemento de red según la invención, y la información de
topología total se conoce en cada puente.
La figura 4a es un gráfico que muestra la misma
topología que la figura 3, pero con un cambio de topología que se
produce en la red. Se establece un enlace entre el puente C y G.
La figura 4b es un gráfico que muestra la misma
topología que la figura 3, tras el evento de cambio de topología.
En la figura 4b, tanto el puerto C3 en el puente C como el puerto G3
en el puente G se ponen en estado de bloqueo. Esto se realiza por
los dos puentes sin ninguna interacción con el puente raíz u otro.
El puente C o G, envía un paquete de evento de cambio de topología
(TCE) de multidifusión al puente raíz. El puente raíz identifica si
el TCE recibido representa un bucle en potencia. Puede verse a
partir de la figura 4b que se establece un bucle entre los puentes
A, C, G, H y D. El puente raíz calcula el ST nuevo basándose en los
nuevos parámetros de coste de ruta del enlace entre los puentes C y
G. El cálculo nuevo muestra que el ST nuevo deberá utilizar este
enlace (C3 y G3 en estado de reenvío), mientras que el enlace entre
el puente G y H deberá ser un enlace de respaldo.
El puente raíz envía un paquete de orden de
cambio de topología (TCC) de multidifusión, en el que el puerto G1
se pone en estado de bloqueo y el puerto G3 en estado de reenvío del
puente G y el puerto C3 del puente C se pone en estado de reenvío,
véase la figura 4c. El paquete de TCC también contiene información
de MTU, en la que se ordena a los puentes A, C, G, H y D con los
puertos A5 y A8, C2 y C3, G3 y G1, H7 y H6 y D1 y D2
respectivamente, que borren las direcciones de MAC asociadas con
estos puertos. El paquete de TCC con información de MTU se envía en
toda la red. El paquete se recibe en todos los puentes en la red, y
todos los puentes llevarán a cabo o bien MTU o bien cambios de
estado de puerto, excepto en los puentes: I, B, E y F que no están
afectados por el cambio de topología. El puente raíz, es decir, el
manejador de topología de puente, no solicitará paquetes de TCA del
puente C y G, pero todos los puentes que incluyan el puente raíz
recibirán paquetes de BTI con información de topología nueva que
indique a los puentes que se ha conseguido la nueva topología
activa. Esto significa que ha finalizado el procedimiento de cambio
de topología. El paquete de TCC volverá a enviarse si no se recibe
tal información nueva en un intervalo de tiempo predefinido en el
puente raíz.
La comunicación de paquetes de TCE, TCC, TCA,
MTU, TSC y TDC entre los puentes de detección de TCE, los puentes
que están afectados por el TCE y el puente raíz puede cambiarse de
tal forma que la propiedad del puente raíz que actúa como el
"maestro" en la red se elimine en mayor o menor medida. El
puente raíz puede ser aún el punto central en la red en cuanto a
cálculo del coste de ruta, pero el puente raíz no participa en el
manejo de un cambio de topología a menos que el puente raíz sea un
puente de detección de TCE, o esté afectado por un TCE en la red.
Un manejo de TCE alternativo puede ser introducir las definiciones
de subraíz, subárbol y puente de manejo de TCE (que se corresponden
con los conjuntos de reglas 2, 3 y 4, respectivamente).
Un puente subraíz, es decir, el manejador de
topología de puente, para un TCE dado se identifica basándose en la
ubicación del TCE en el ST. Un subárbol se define como la parte del
ST a la que afecta el TCE. Pueden utilizarse varios criterios
diferentes para definir qué puente deberá ser el subraíz en un
subárbol dado. Una solución es la siguiente:
el puente o puentes de detección de TCE se
consideran siempre como el/los candidato(s) para ser el
subraíz del TCE. Si dos puentes detectan el mismo TCE, entonces el
puente más cercano al puente raíz en cuanto al coste de ruta a
través de los puertos de reenvío al puente raíz será considerado
además como el candidato. Si el TCE no introduce un bucle en la
red, entonces se seleccionará este puente como el subraíz. Si el TCE
representa un bucle nuevo en la red, entonces los puentes de
detección de TCE deben identificar el puente en el bucle que es el
puente más cercano al puente raíz en cuanto al coste de ruta a
través de los puertos de reenvío al puente raíz. Se seleccionará
este puente como el subraíz. Los paquetes de BTI se intercambiarán
en el nuevo enlace entre los dos puentes en caso de un
establecimiento de enlace entre los dos puentes. Es conveniente que
los dos puentes conozcan la última BTI de toda la red antes de que
se inicie ningún procedimiento de cambio de topología. Esto podría
introducir cierto retardo adicional en caso de que se procese un TCE
de establecimiento de enlace, aunque esto no es crítico en tiempo
real ya que un nuevo enlace representa más y no menos rutas de red.
Obsérvese, sin embargo, que pueden usarse también otros criterios de
selección.
\vskip1.000000\baselineskip
En la figura 6a, el puente A se seleccionará
como el subraíz para el TCE entre los puentes C y G.
En la figura 6b, el puente raíz se selecciona
como el subraíz para el TCE generado entre los puente E e I.
\vskip1.000000\baselineskip
En la figura 7a, el puente C se selecciona como
el subraíz para el TCE generado entre los puente C y G, puesto que
C está más cercano que G al puente raíz en cuanto al coste de ruta a
través de los puertos de reenvío al puente raíz. Ambos puentes
conocen esto. Se permite al puente G cambiar el estado del puerto G1
a reenvío, y también puede actualizar su tabla de MAC antes de la
recepción de una orden TCC del puente C o A. Así, el TCE podría
producirse por una pérdida del puente C de la red. En este caso se
elegirá A como el subraíz.
Se manejarán varios TCE generados de forma más o
menos simultánea en una secuencia por el puente raíz en caso de no
utilizar la implementación de subraíz. El puente raíz podría
modificar un procedimiento de cambio de topología en curso si un
paquete de TCE nuevo con información nueva se recibe durante el
procedimiento de cambio de topología en curso. El puente raíz
podría seleccionar poner parte de o incluso todos los puertos
habilitados de ST en la red en estado de bloqueo en un escenario de
TCE múltiple. El uso de subraíces también puede manejar la
situación en la que varios TCE se generan de forma más o menos
simultánea y los subárboles de los TCE se solapan. El puente más
superior en un subárbol que contiene todos los TCE se selecciona
como el subraíz. Este puente es responsable de manejar el escenario
de TCE múltiple. Los principios del manejo de un escenario de TCE
múltiple, cuando se usan principios de subraíz, son los mismos que
para el puente raíz cuando no se utiliza la implementación de
subraíz.
Una pérdida de conexión completa de un puente
podría considerarse como un escenario de TCE múltiple, en el que es
conveniente poner cada puerto habilitado de ST excepto uno en cada
puente en estado de bloqueo, ya que el establecimiento de una nueva
topología activa podría implicar varios cambios de topología en la
red con un puente nuevo elegido como el puente raíz.
Podría ser necesario que se detuviera un
procedimiento de cambio de topología en curso manejado por un puente
subraíz o un puente de detección de TCE si se recibe una orden TCC
de otro BTH más cercano al puente raíz en cuanto al coste de ruta a
través de los puertos de reenvío.
La introducción de la definición de subraíz
puede desarrollarse adicionalmente permitiendo que cualquier puente
de detección de TCE actúe como el manejador de topología de puente,
es decir, opere según el conjunto de reglas 4. Esto puede reducir
el número de paquetes requeridos y el tiempo necesario para
conseguir una nueva topología activa en caso de un TCE. Así, puede
utilizarse completamente el hecho de que cada puente en la red tiene
un conocimiento completo de la topología de red, y que cada puente
puede calcular y manejar el establecimiento una nueva topología
activa basándose en un TCE. Un cambio en la topología activa es en
la mayoría de los casos relevante en uno o más de los puertos de ST
en un puente de detección de TCE. Esto significa que un puente de
detección de TCE puede realizar algunos o todos estos cambios
requeridos antes de que cualquier TCC e información de MTU se envíe
a otros puentes. Algunos TCE se detectarán por dos puentes, por
ejemplo un TCE de "activación de enlace". Tal TCE debería
manejarse preferentemente por uno de los puentes de detección de
TCE. Cuál puede depender de varios criterios diferentes. Una
solución es que el puente más cercano al puente raíz, es decir, el
punto central, en cuanto al coste de ruta a través de los puertos de
reenvío al puente raíz sea responsable del manejo del TCE. Podría
requerirse comunicación de BTI para que los puentes de detección de
TCE verifiquen qué puente deberá manejar el TCE. Sin embargo, no es
obligatorio que sólo uno de los puentes de detección de TCE maneje
el TCE en caso de un establecimiento de enlace. Un TCE de "pérdida
de enlace" entre dos puentes implicará también dos puentes de
detección de TCE, y a menudo no es posible la comunicación entre
estos dos puentes después de un TCE de "pérdida de enlace".
Ninguno de estos dos puentes sabe si el TCE se produjo por una
pérdida de enlace o porque el puente contiguo está completamente
desconectado de la red. Así, ambos puentes de detección de TCE
inician un procedimiento de cambio de topología que implica cambios
de topología locales y transmisión de información de MTU, TCC y
TCE. Esto significa que se tienen dos manejadores de topología de
puente. Los dos puentes de detección de TCE enviarán la misma
información. Esto significa que los demás puentes en la red
recibirán la misma información dos veces, pero los puentes afectados
por el TCE deberían ejecutar las órdenes recibidas sólo una vez.
Estos puentes pueden verificar que la misma información se recibe
de cada uno de los puentes de detección de TCE comparando los
paquetes de TCE recibidos, la inspección del campo "BTI para toda
la red" de los dos paquetes de TCC recibidos, y el hecho de que
el contenido de los dos paquetes de MTU recibidos (que pueden ser
parte del paquete de TCC) son iguales si esta información se recibe
en un intervalo de tiempo predefinido corto y razonable. Este
procedimiento funciona tanto para una pérdida de enlace como para
en algunos casos una pérdida completa de un puente en la red. Es
conveniente que los puentes que reciben la información de TCC y MTU
envíen paquetes de TCA a ambos de los puentes de detección de TCE
aun cuando las órdenes sólo se ejecuten una vez.
tanto el puente C como el G en la figura 4a
detectan el TCE de "activación de enlace" entre los puentes C
y G. Tanto el puerto C3 en el puente C como el puerto G3 en el
puente G se ponen en estado de bloqueo y ambos puentes envían un
paquete de TCE acerca del TCE y entonces esperan Tprop segundos.
Tanto el puente C como el G pueden calcular, basándose en el TCE y
en el intercambio de BTI entre estos dos puentes, la nueva topología
activa que será relevante y acordar que el puente G deberá ser el
BTH para este TCE, véase la figura 4c. El puente G pone al puerto
G1 en bloquear y el puerto G3 en reenviar, y entonces envía un
paquete de TCC con información de MTU. La parte de TCC está
prevista para el puente C, es decir, pone al puerto C3 de puente C
en estado de reenvío, mientras que la parte de MTU está prevista
para los puentes C, A, D y H.
\vskip1.000000\baselineskip
La figura 7a muestra una topología activa, en la
que un TCE de "desactivación de enlace" se encuentra entre los
puentes C y G. Tanto C como G detectan este TCE, y ambos puentes
inician un procedimiento de manejo de TCE basándose en la
suposición de que el enlace entre estos dos puentes está
desactivado. Ambos puentes enviarán un paquete de TCC que contiene
información de topología de que este enlace está desactivado e
información de MTU que indica a los puentes G, H, D, A y C que
actualicen sus tablas de MAC. Los puentes A, D y H están afectados
también por este TCE. Todos ellos pueden verificar que el TCE está
producido por una pérdida de enlace entre los puentes C y G puesto
que la misma información de topología se recibe desde estos dos
puentes. Así, la nueva topología activa mostrada en la figura 7b se
consigue muy rápido.
Un problema que aparece con la técnica descrita
anteriormente se relaciona con el escenario de TCE múltiple. Es
decir, se generan uno o más TCE nuevos mientras que uno o dos
puentes de detección de TCE ya están manejando un TCE, o el mismo
TCE genera información de MTU y TCC a partir de puentes de detección
de TCE diferentes, donde difiere tanto la parte de TCC como la de
MTU. Esto puede solucionarse utilizando los siguientes
principios:
todos los puentes en el ST pondrán sus puertos
habilitados de ST excepto uno en estado de bloqueo una vez detecten
un escenario de TCE múltiple. Entonces el puente raíz calculará la
nueva topología activa basándose en todos los TCE recibidos, y
propagará la información de topología nueva a través de la red como
se describió anteriormente. Así, el puente raíz actúa como el
manejador de topología de puente.
Una solución alternativa a esto es la
siguiente:
aquellos puentes que pertenecen al subárbol,
donde aparece más de un TCE pondrán todos sus puertos habilitados
de ST excepto uno en estado de bloqueo. El puente, es decir,
subraíz, más cercano al puente raíz en cuanto al coste de ruta a
través de los puertos de reenvío se convertirá en el manejador de
topología de puente. Este puente manejará el establecimiento de una
nueva topología activa basándose en todos los TCE recibidos, y
propagará la información de topología nueva a través de la red
siguiendo los principios como se describió anteriormente.
Puede optimizarse la puesta de todos los puertos
habilitados de ST en todos los puentes en el ST o el subárbol en el
que se produjo el TCE. Así, la raíz o subraíz puede identificar un
subconjunto de los puertos habilitados de ST cuyos puentes deben
ponerse en estado de bloqueo.
\vskip1.000000\baselineskip
la figura 8a muestra una topología activa, en la
que se detecta un TCE de "desactivación de enlace" en los
puentes A, H y I. Estos puentes detectan el mismo TCE. Es decir, el
puente D está desactivado. El puente A supone que se ha perdido el
enlace entre A y D, el puente H supone que se ha perdido el enlace
entre H y D y el puente I supone que se ha perdido el enlace entre
I y D. Estos puentes enviarán un paquete de TCC que contiene
información de topología acerca de que su enlace respectivo hacia el
puente D está desactivado, y los puentes A y H enviarán información
de MTU que indica a los puentes G, H, D, A y C que actualicen sus
tablas de MAC, mientras que el puente I enviará información de MTU
que indica a los puentes H, D e I que actualicen sus tablas de MAC.
Los demás puentes recibirán información de topología y MTU
diferente. Este escenario debería manejarse de este modo como un
escenario de TCE múltiple aun cuando la pérdida del puente D sea un
único punto de fallo. Es también posible que los demás puentes
verifiquen basándose en la información de MTU y TCC entrante desde
los tres puentes de detección de TCE que éste es un único escenario
de TCE que implica una pérdida de puente D, y actúen según
la(s) orden/órdenes recibida(s) que dan como resultado
la nueva topología mostrada en la figura 8b.
la figura 9a muestra una topología activa, en la
que un TCE de "desactivación de enlace" se encuentra en los
puentes A, H e I. Estos puentes detectan el mismo TCE. Es decir, el
puente D está desactivado. El puente A supone que el enlace entre A
y D se ha perdido, el puente H supone que el enlace entre H y D se
ha perdido y el puente I supone que el enlace entre I y D se ha
perdido. Tanto el puente A como el H enviarán un paquete de TCC que
contiene información de topología acerca de que su enlace respectivo
hacia el puente D está desactivado e información de MTU que indica
a los puentes G, H, D, A y C que actualicen sus tablas de MAC,
mientras que el puente I no hará nada, puesto que ya no tiene
conexión a la red. Los demás puentes reciben la misma información
de MTU, mientras que la información de topología sea diferente.
Pueden, sin embargo, verificar que este es un único escenario de
TCE que implica una pérdida del puente D, y actuar según
la(s) orden/órdenes recibida(s) que dan como
resultado la nueva topología mostrada en la figura 9b. Un enfoque
conservador podría ser manejar esto también como un escenario de
TCE múltiple.
La implementación de utilizar el puente raíz
como el único BTH posible en una red no requiere que todos los
demás puentes en la red tengan conocimiento completo de la topología
de red. Sólo se requiere información contigua de puente y local en
un manejador que no sea de topología de puente. Esto incluye la
misma información que se conoce en un puente habilitado de STA
además de a qué puerto de ST está conectado cada puerto de ST en
qué puente contiguo. Esta BTI puede enviarse como se describió
anteriormente. Una alternativa es enviar esta BTI directamente al
puente raíz como datos de unidifusión que se envían en puertos de
reenvío, o puede utilizarse una combinación de estos dos
procedimientos. El puente raíz calculará entonces el ST basándose
en las BTI y TCE recibidos y enviará y recibirá información MTU, TCA
y TCC de la misma forma que se describió anteriormente. Este
principio puede utilizarse también en caso de utilizar la
implementación de subraíz. Los puentes que operan como subraíces
deberían preconfigurarse a través de por ejemplo administración como
subraíces en potencia o puede utilizarse un conjunto de reglas dado
para identificar candidatos a subraíz en potencia. Un puente
subraíz debe conocer toda la topología de red o por lo menos la
información de topología relacionada con el subárbol en el que es
el subraíz, mientras que los puentes en el subárbol no necesitan
conocer más que información contigua de puente y local como se
describió anteriormente. Esta BTI se envía a una o todas las
subraíces disponibles en la red. Es también posible que un puente
tenga conocimiento de sólo una parte de la red. La parte de una
red, en la que un puente deberá contener información de topología
puede configurarse a través de administración.
La memoria descriptiva anterior ha descrito un
elemento de red y un procedimiento para controlar un elemento de
red (o puente por simplicidad). Cuando una red se construye con
puentes según la invención, se consigue para toda la red un
rendimiento de reconfiguración rápido y eficaz. Sin embargo, una
ventaja sustancial se consigue también aun cuando algunos de los
puentes en la red no soporten provisiones de reconfiguración rápida
según la invención. Los siguientes principios son relevantes en este
contexto:
- -
-
\vtcortauna
- -
-
\vtcortauna
- -
-
\vtcortauna
Aunque la invención se ha descrito haciendo
referencia a formas de realización específicas y preferidas y
algunas alternativas y variaciones, el experto en la materia se dará
cuenta de que existen muchas otras modificaciones obvias dentro del
alcance de la invención, como se explica en el siguiente conjunto de
reivindicaciones.
Claims (23)
1. Procedimiento para controlar un elemento de
red con una pluralidad de puertos de comunicación para transmitir y
recibir paquetes de datos a y desde otros elementos de red en una
red, en el que un modelo de topología de árbol de expansión de la
red se almacena en por lo menos una base de datos en el elemento de
red, comprendiendo dicho procedimiento las etapas siguientes:
- (a)
- detectar un evento que indica un cambio en la topología de la red;
- (b)
- actualizar el modelo de topología de árbol de expansión del subconjunto de la red basándose en información obtenida del evento de cambio de topología, incluyendo dicho subconjunto el origen del evento de cambio de topología y los elementos de red que están afectados por el cambio de topología,
- (c)
- determinar si el elemento de red funciona como un manejador de topología para el evento detectado, y
- (d)
- si el elemento de red funciona como un manejador de topología, llevar a cabo las etapas siguientes:
- (d1)
- calcular un nuevo modelo de topología de árbol de expansión, basándose en el modelo resultante de la etapa de actualización (b), y
- (d2)
- transmitir una orden de cambio de topología a la red, incluyendo dicha orden información sobre el nuevo modelo de topología de árbol de expansión,
caracterizado
- -
-
\vtcortauna
- (a1)
- detectar un evento de cambio de topología local, o
- (a2)
- detectar un evento de cambio de topología no local recibiendo un paquete de datos de evento de cambio de topología o un paquete de datos de orden de cambio de topología desde la red, y
- -
-
\vtcortauna
- -
-
\vtcortauna
2. Procedimiento según la reivindicación 1, en
el que dicha información de evento de cambio de topología se
transmite a un elemento de red que funciona como un manejador de
topología a través de por lo menos un elemento de red intermedio,
reenviando dicho elemento de red intermedio dicha información de
evento de cambio de topología sin retardarla mediante su unidad de
procesamiento central.
3. Procedimiento según la reivindicación 1, en
el que dicha orden de cambio de topología se propaga por la red a
través de un elemento de red que reenvía la orden de cambio de
topología sin retardarla mediante su CPU.
4. Procedimiento según la reivindicación 1, que
comprende asimismo la siguiente etapa:
- (e)
- si el elemento de red no funciona como un manejador de topología para el evento detectado, llevar a cabo la siguiente subetapa:
- (e1)
- si el evento detectado es una orden de cambio de topología, llevar a cabo un procedimiento de recepción de orden de cambio de topología, comprendiendo dicho procedimiento de recepción de orden de cambio de topología las etapas de actualizar el modelo de topología con información de topología de elemento de red (BTI), determinar si en la orden TCC se solicita una confirmación de recepción de cambio de topología (TCA),
determinar si en la orden de cambio de topología
está incluida información de actualización de tabla de MAC
y si está incluida información de actualización
de tabla de MAC, llevar a cabo un procedimiento de recepción de
actualización de tabla de MAC.
5. Procedimiento según la reivindicación 4, que
comprende asimismo la etapa de si se solicita una confirmación de
recepción de cambio de topología y no está incluida información de
actualización de tabla de MAC en la orden de cambio de topología,
llevar a cabo un procedimiento de transmisión de confirmación de
recepción de cambio de topología.
\newpage
6. Procedimiento según la reivindicación 5, en
el que el procedimiento de transmisión de confirmación de recepción
de cambio de topología comprende las etapas siguientes:
- transmitir un paquete de confirmación de
recepción de cambio de topología a la red, incluyendo dicho paquete
información de actualización de tabla de MAC calculada a partir del
modelo de árbol de expansión si se requiere información de
actualización de tabla de MAC.
7. Procedimiento según la reivindicación 1, en
el que la etapa de detección (a1) comprende la detección de un
evento de cambio de topología de activación de enlace, un evento de
cambio de topología de desactivación de enlace, un evento de cambio
de topología de cambio de parámetro de coste de ruta, un evento de
cambio de topología de expiración de BTI o un evento de cambio de
topología de actualización de DB de BTI.
8. Procedimiento según la reivindicación 1, en
el que la etapa de actualización (b) va seguida por la etapa de
- (b1)
- determinar si un procedimiento de cambio de topología no está finalizado cuando se detecta el evento de cambio de topología, y si el evento de cambio de topología se detecta cuando un procedimiento de cambio de topología no está finalizado, llevar a cabo las siguiente subetapas:
- (b11)
- interrumpir cualquier procedimiento de cambio de topología en curso, y
- (b12)
- actualizar el modelo de topología de árbol de expansión de la red, basándose en el nuevo evento de cambio de topología detectado.
9. Procedimiento según la reivindicación 1, en
el que dicha etapa de actualización (c) implica información de
topología de red, información BTI, obtenida del evento
detectado.
10. Procedimiento según la reivindicación 1, en
el que dicha etapa de determinación (c) implica la aplicación de un
conjunto de reglas que está preseleccionado para su aplicación
mediante diversos elementos de red en la red.
11. Procedimiento según la reivindicación 10, en
el que dicho conjunto de reglas impone que un elemento de red raíz
siempre actúe como el manejador de topología.
12. Procedimiento según la reivindicación 10, en
el que dicho conjunto de reglas implica el uso de información sobre
el origen del evento detectado en conjunción con información de
topología recuperada del modelo de árbol de expansión para
determinar si el elemento de red es el manejador de topología para
el evento detectado.
13. Procedimiento según la reivindicación 12, en
el que dicho conjunto de reglas impone que un número restringido de
elementos de red subraíz puede actuar como el manejador de
topología.
14. Procedimiento según la reivindicación 12, en
el que dicho conjunto de reglas impone que cualquier elemento de
red subraíz puede actuar como el manejador de topología.
15. Procedimiento según la reivindicación 12, en
el que dicho conjunto de reglas impone que el elemento de red actúe
como el manejador de topología si el evento detectado es un evento
local.
16. Procedimiento según la reivindicación 1, en
el que dicha subetapa de cálculo (d1) comprende el establecimiento
de un modelo de árbol de expansión intermedio.
17. Procedimiento según la reivindicación 1, en
el que la etapa de cálculo (d1) va seguida por la etapa de
si el elemento de red está afectado por el
cambio de topología, configurar los puertos locales del elemento de
red según el modelo de topología de árbol de expansión
actualizado.
18. Procedimiento según la reivindicación 1, que
comprende asimismo la etapa de
- -
- recibir una orden de guardado de topología de la red, y
- -
- registrar en una base de datos el modelo de topología actual tras recibir dicha orden de guardado de topología.
19. Procedimiento según la reivindicación 1, que
comprende asimismo la etapa de transmitir una orden de guardado de
topología a la red.
20. Procedimiento según la reivindicación 1, que
comprende asimismo la etapa de transmitir una orden de diferencia
de topología a la red, indicando dicha orden que existe una
diferencia entre una topología de red preferida y una topología
actual, almacenándose dichas topologías en bases de datos en el
elemento de red.
\newpage
21. Procedimiento según la reivindicación 1, en
el que el modelo de topología de árbol de expansión implica
parámetros de coste de ruta relacionados con por lo menos uno de
entre: disponibilidad de enlace, velocidad de enlace, conectividad
dúplex, tipo de enlace y capacidad de prioridad.
22. Elemento de red, que comprende una
pluralidad de puertos de comunicación para transmitir y recibir
paquetes de datos a y desde otros elementos de red en una red, en
el que un modelo de topología de árbol de expansión de la red se
almacena en por lo menos una base de datos en el elemento de red,
que comprende asimismo unos medios de procesamiento dispuestos para
llevar a cabo un procedimiento según una de las reivindicaciones 1
a 21.
23. Red informática, que comprende una serie de
elementos de red según la reivindicación 22.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| NO20030563A NO318311B1 (no) | 2003-02-04 | 2003-02-04 | Fremgangsmate og apparat for rask rekonfigurering av en nettverkstopologi |
| NO20030563 | 2003-02-04 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2318268T3 true ES2318268T3 (es) | 2009-05-01 |
Family
ID=19914446
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES04708094T Expired - Lifetime ES2318268T3 (es) | 2003-02-04 | 2004-02-04 | Procedimiento y aparato para la reconfiguracion rapida de una topologia de red. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US20060253561A1 (es) |
| EP (1) | EP1593240B1 (es) |
| AT (1) | ATE415036T1 (es) |
| DE (1) | DE602004017836D1 (es) |
| DK (1) | DK1593240T3 (es) |
| ES (1) | ES2318268T3 (es) |
| NO (1) | NO318311B1 (es) |
| WO (1) | WO2004070983A2 (es) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7644161B1 (en) * | 2005-01-28 | 2010-01-05 | Hewlett-Packard Development Company, L.P. | Topology for a hierarchy of control plug-ins used in a control system |
| US8214535B2 (en) * | 2006-03-28 | 2012-07-03 | International Business Machines Corporation | Changing Ethernet MTU size on demand with no data loss |
| US7995499B2 (en) * | 2006-11-23 | 2011-08-09 | Cisco Technology, Inc. | Minimizing spanning-tree protocol event processing and flooding in distribution networks |
| US7779118B1 (en) * | 2006-12-28 | 2010-08-17 | Emc Corporation | Method and apparatus for representing, managing, analyzing and problem reporting in storage networks |
| US8446845B2 (en) * | 2007-03-13 | 2013-05-21 | Alcatel Lucent | Advanced bandwidth management audit functions |
| US7916741B2 (en) * | 2007-04-02 | 2011-03-29 | William Marsh Rice University | System and method for preventing count-to-infinity problems in ethernet networks |
| US8743741B2 (en) * | 2007-08-14 | 2014-06-03 | Telefonaktiebolaget L M Ericsson (Publ) | Network reconfiguration method |
| JP2009105690A (ja) * | 2007-10-24 | 2009-05-14 | Alaxala Networks Corp | レイヤ２冗長プロトコル相互接続装置 |
| US8059668B2 (en) * | 2008-01-25 | 2011-11-15 | Cisco Technology, Inc. | Efficient end-to-end proposal/agreement messaging for spanning tree convergence in a computer network |
| GB2467769B (en) * | 2009-02-13 | 2011-04-13 | Amdocs Software Systems Ltd | Method and system for specifying planned changes to a communications network |
| CA2953802A1 (en) * | 2009-02-13 | 2010-08-19 | Adc Telecommunications, Inc. | Network management systems for use with physical layer information |
| IT1400207B1 (it) * | 2010-04-15 | 2013-05-24 | M 3 S S R L | " metodo per l'accelerazione della riconfigurazione in reti informatiche basate su spanning tree ". |
| WO2012015432A1 (en) * | 2010-07-30 | 2012-02-02 | Hewlett-Packard Development Company, L.P. | Computer system and method for sharing computer memory |
| US9710426B2 (en) * | 2010-07-30 | 2017-07-18 | Hewlett Packard Enterprise Development Lp | Computer system and method for sharing computer memory |
| WO2013052714A1 (en) * | 2011-10-04 | 2013-04-11 | Veedims, Llc | System and method for auto-discovery and mapping of networked modules |
| WO2013086287A1 (en) | 2011-12-07 | 2013-06-13 | Adc Telecommunications, Inc. | Systems and methods for using active optical cable segments |
| IN2014KN02956A (es) | 2012-06-25 | 2015-05-08 | Adc Telecommunications Inc | |
| US9351571B2 (en) | 2012-07-11 | 2016-05-31 | Manitowoc Foodservice Companies, Llc | Connection assembly for a base and a cabinet assembly of an ice maker |
| US9473361B2 (en) | 2012-07-11 | 2016-10-18 | Commscope Technologies Llc | Physical layer management at a wall plate device |
| WO2014049361A1 (en) | 2012-09-27 | 2014-04-03 | Tyco Electronics Uk Ltd. | Mobile application for assisting a technician in carrying out an electronic work order |
| US9407510B2 (en) | 2013-09-04 | 2016-08-02 | Commscope Technologies Llc | Physical layer system with support for multiple active work orders and/or multiple active technicians |
| KR20160118207A (ko) | 2013-09-24 | 2016-10-11 | 콤스코프 테크놀로지스, 엘엘씨 | 시뮬레이션되는 메모리 테이블 및 관리형 연결 지원을 갖는 플러그형 능동 광학 모듈 |
| CN112532410B (zh) * | 2019-09-18 | 2023-10-31 | 无锡江南计算技术研究所 | 大规模互连网络Trap快速响应方法 |
| FR3131158B1 (fr) * | 2021-12-21 | 2025-04-04 | Thales Sa | Système à base de matrice de redondance |
| CN118214625A (zh) * | 2022-12-15 | 2024-06-18 | 霍尼韦尔国际公司 | 用于定位以太网环形网络中的故障的装置和方法 |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4644532A (en) * | 1985-06-10 | 1987-02-17 | International Business Machines Corporation | Automatic update of topology in a hybrid network |
| US4991204A (en) * | 1988-12-05 | 1991-02-05 | Nippon Telegraph And Telephone Corporation | Adaptive routing control method |
| EP0684716B1 (en) * | 1994-05-25 | 2002-02-27 | International Business Machines Corporation | A data communication network and method for operating said network |
| US6081512A (en) * | 1997-06-30 | 2000-06-27 | Sun Microsystems, Inc. | Spanning tree support in a high performance network device |
| US6105057A (en) * | 1998-01-28 | 2000-08-15 | Ericsson Inc. | Method and apparatus for manipulating mutexes on network assets |
| US6262977B1 (en) * | 1998-08-28 | 2001-07-17 | 3Com Corporation | High availability spanning tree with rapid reconfiguration |
| US6330229B1 (en) * | 1998-11-09 | 2001-12-11 | 3Com Corporation | Spanning tree with rapid forwarding database updates |
| US7158989B2 (en) * | 2000-10-27 | 2007-01-02 | Buc International Corporation | Limit engine database management system |
| US7089335B2 (en) * | 2000-10-30 | 2006-08-08 | Microsoft Corporation | Bridging multiple network segments and exposing the multiple network segments as a single network to a higher level networking software on a bridging computing device |
| US6982960B2 (en) * | 2001-03-09 | 2006-01-03 | Motorola, Inc. | Protocol for self-organizing network using a logical spanning tree backbone |
| US20040172412A1 (en) * | 2002-07-19 | 2004-09-02 | Kirby Files | Automated configuration of packet routed networks |
-
2003
- 2003-02-04 NO NO20030563A patent/NO318311B1/no not_active IP Right Cessation
-
2004
- 2004-02-04 DK DK04708094T patent/DK1593240T3/da active
- 2004-02-04 WO PCT/NO2004/000033 patent/WO2004070983A2/en not_active Ceased
- 2004-02-04 US US10/544,347 patent/US20060253561A1/en not_active Abandoned
- 2004-02-04 DE DE602004017836T patent/DE602004017836D1/de not_active Expired - Lifetime
- 2004-02-04 EP EP04708094A patent/EP1593240B1/en not_active Expired - Lifetime
- 2004-02-04 AT AT04708094T patent/ATE415036T1/de active
- 2004-02-04 ES ES04708094T patent/ES2318268T3/es not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1593240B1 (en) | 2008-11-19 |
| NO20030563D0 (no) | 2003-02-04 |
| US20060253561A1 (en) | 2006-11-09 |
| WO2004070983A2 (en) | 2004-08-19 |
| WO2004070983A3 (en) | 2004-11-11 |
| NO318311B1 (no) | 2005-02-28 |
| DK1593240T3 (da) | 2009-03-23 |
| EP1593240A2 (en) | 2005-11-09 |
| DE602004017836D1 (de) | 2009-01-02 |
| ATE415036T1 (de) | 2008-12-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2318268T3 (es) | Procedimiento y aparato para la reconfiguracion rapida de una topologia de red. | |
| US11570036B2 (en) | System and method for resilient wireless packet communications | |
| US7969915B2 (en) | Technical enhancements to STP (IEEE 802.1D) implementation | |
| US8520508B2 (en) | Spanning tree ring protocol | |
| US8804707B2 (en) | Switching fabrics and control protocols for them | |
| US7480258B1 (en) | Cross stack rapid transition protocol | |
| US6628661B1 (en) | Spanning tree recovery in computer networks | |
| US7564779B2 (en) | Ring rapid spanning tree protocol | |
| US7412557B2 (en) | Apparatus and method for preventing loops in a computer network | |
| US8462668B2 (en) | System and method for implementation of layer 2 redundancy protocols across multiple networks | |
| ES2459966T3 (es) | Método, sistema y equipo para gestionar direcciones en una red Ethernet en anillo | |
| CN100479408C (zh) | 一种堆叠系统内部转发表的实现方法 | |
| US8325629B2 (en) | System and method for assuring the operation of network devices in bridged networks | |
| US20150009808A1 (en) | Fault-resilient broadcast, multicast, and unicast services | |
| US7339888B2 (en) | Bridge and route change method of network using the same | |
| KR20080089285A (ko) | 이더넷 링 네트워크에서의 보호 절체 방법 | |
| CN101322355A (zh) | 提供商链路状态桥接 | |
| WO2009014967A1 (en) | Preventing loops in networks operating different protocols to provide loop-free topology | |
| US20080279203A1 (en) | Method of Operating a Node in a Communications Network | |
| JP5191494B2 (ja) | リンク状態アドバタイズメント（ｌｓａ）に基づきスパニングツリーを計算する方法、ブリッジ及びコンピュータ・ネットワーク | |
| CN101268658A (zh) | 产生对称生成树的系统和方法 | |
| JP2013239807A (ja) | 通信装置 | |
| CN100403731C (zh) | 在堆叠设备域中通信传输路径的控制方法 | |
| Willis et al. | A meshed tree protocol for loop avoidance in switched networks | |
| JP4585560B2 (ja) | ネットワーク障害検知方法、データ通信ネットワークシステムおよびノード装置 |