ES2313196T3 - Protocolo de arbol de expansion con control de rafagas de datos. - Google Patents
Protocolo de arbol de expansion con control de rafagas de datos. Download PDFInfo
- Publication number
- ES2313196T3 ES2313196T3 ES05028428T ES05028428T ES2313196T3 ES 2313196 T3 ES2313196 T3 ES 2313196T3 ES 05028428 T ES05028428 T ES 05028428T ES 05028428 T ES05028428 T ES 05028428T ES 2313196 T3 ES2313196 T3 ES 2313196T3
- Authority
- ES
- Spain
- Prior art keywords
- port
- bridge
- bpdu
- protocol
- switching device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
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/28—Routing or path finding of packets in data switching networks using route fault recovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
-
- 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/02—Topology update or discovery
-
- 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/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Selective Calling Equipment (AREA)
Abstract
Un dispositivo conmutador preparado para llevar a cabo el control de ráfagas en una red de comunicaciones de datos que comprende una pluralidad de puentes (101, ..., 120), comprendiendo el dispositivo conmutador: un primer puerto (119B) habilitado con un protocolo de gestión de enlaces; y medios preparados para recibir, en el primer puerto (119B), una primera unidad de datos del protocolo entre puentes (BPDU) (904) procedente de un primer puente (120) de una pluralidad de puentes; caracterizado por una máquina de estados de control de ráfagas preparada para retardar una transmisión de una segunda BPDU (926) desde el primer puerto (119B) durante un periodo de tiempo predeterminado a partir del momento en que se recibe la primera BPDU (904) si se cumplen un conjunto de condiciones; en el que el conjunto de condiciones comprende: la variable "port role" del primer puerto (119B) tiene el valor "Root"; el papel del puerto del primer puerto (119B) pasa de raíz a designado en base a la primera BPDU (904); y el primer puerto (119B) está es un estado de "Forwarding".
Description
Protocolo de árbol de expansión con control de
ráfagas de datos.
La presente invención se refiere en términos
generales a un puente o dispositivo similar preparado para evitar
ráfagas de unidades de datos del protocolo entre puentes (BPDU;
bridge protocol data unit) en una red de comunicaciones de datos.
En concreto, la invención se refiere a un dispositivo conmutador de
acuerdo con el preámbulo de la reivindicación 1 y a un método de
acuerdo con el preámbulo de la reivindicación 10.
Tales dispositivo y método se conocen por la
publicación: "IEEE Std 802.1w Media Access Control (MAC) Bridges
Amendment 2: Rapid Reconfiguration" 25 de octubre de 2001; IEEE
COMPUTER SOCIETY, XP002367326.
En la figura 1 se muestra una red 100 de
comunicaciones de datos que incluye una pluralidad de puentes
101-120 conectados operativamente en forma de un
anillo mediante enlaces de red 130. La topología de la red 100 es
útil para entender los inconvenientes atribuibles al estado de la
técnica, así como las ventajas de la presente invención comentadas
con más detalle más adelante. Cada uno de los puentes
101-120 incluye una pluralidad de puertos de red
habilitados con un protocolo de gestión de enlaces para resolver los
bucles de transmisión en la red 100 que pueden dar lugar a
tormentas de tráfico de difusión (broadcast). El protocolo de
gestión de enlaces puede seleccionarse, por ejemplo, del grupo que
comprende el protocolo STP (Spanning Tree Protocol; protocolo de
árbol de expansión), normalizado en el estándar 802.1D 2004 del IEEE
(International Electrical and Electronics Engineers); el protocolo
RSTP (Rapid Spanning Tree Protocol; protocolo rápido de árbol de
expansión) definido en el estándar 802.1w del IEEE, y el estándar
802.1Q 2003 que trata del uso de árboles de expansión múltiples en
puentes VLAN (virtual local area network; red de área local virtual)
de acuerdo con el protocolo MSPT (Multiple Spanning Tree Protocol;
protocolo de árbol múltiple de expansión) definido en el estándar
802.1s del IEEE, cada uno de los cuales se incorpora por la presente
cita en esta memoria por referencia.
De acuerdo con el protocolo RSTP, los puentes
101-120 están preparados para intercambiar mensajes
de unidades de datos del protocolo entre puentes (BPDU) con el fin
de determinar cuál de la pluralidad de puentes va a servir como
puente raíz entre ellos, así como el papel de cada puerto de cada
puente. Para determinar el puente raíz y los papeles de los puertos
aplicables, los puentes intercambian mensajes BPDU con información
de prioridad que reciben el nombre de MPV (message priority vector;
vector de prioridad del mensaje). Un puente, generalmente,
transmite mensajes BPDU con un intervalo regular dado por el valor
del temporizador del "Hello time" del puente, es decir un
"Hello time" definido en el estándar RSTP, o envía el mensaje
cuando se inicia un cambio en la topología de árbol de expansión.
Un MPV tiene la estructura siguiente: <Root_Id, Root_Path_Cost,
Designated_Bridge_ID, Designated_Port_ID, Port_ID>, siendo bien
conocidos por los expertos en la materia cada uno de los componentes
del vector. Tras la recepción de una BPDU, un puerto del puente
compara el MPV recibido con su propio vector de prioridad que
denominaremos PPV (port priority vector, vector de prioridad del
puerto). Si el MPV recibido es "superior" al PPV, es decir
numéricamente inferior, la máquina de estados del puerto calcula el
papel de cada puerto de cada puente, que puede confirmar la
topología de árbol de expansión existente o, si es necesario,
iniciar un cambio de topología de árbol de expansión.
El puente raíz en el árbol expandido es
normalmente el puente con la mínima BID (bridge ID; identificación
del puente), es decir la dirección MAC más baja, y se encuentra en
la cabecera del árbol expandido. Aunque cada puente se considera
inicialmente a sí mismo como puente raíz, cada puente aprende la
identidad del puente con la BID mínima mediante el intercambio de
BPDU. En la determinación del papel de los puertos de la pluralidad
de puentes cada uno de los puertos se clasifica como puerto raíz,
puerto designado, puerto de respaldo (backup) o puerto alternativo.
Con la excepción del puente raíz, cada puente tiene un puerto raíz,
es decir el puerto del puente que proporciona el camino de coste
mínimo al puente raíz. Un puerto designado es una interfaz utilizada
para enviar y recibir tramas sobre un segmento específico de red.
Aunque el puerto designado puede ser uno cualquiera de una
pluralidad de puertos accesibles al segmento específico de red, el
puerto designado se determina en base al coste mínimo al puente
raíz. Los puertos alternativo y de respaldo proporcionan
conectividad si fallan otros componentes de la red. Un puerto
alternativo ofrece un camino adicional al puente raíz además del
camino proporcionado por un puerto raíz del propio puente. Un puerto
de respaldo ofrece un camino adicional hacia las "hojas" del
árbol expandido además del camino proporcionado por el puerto
designado para el segmento de red.
Los puertos de un puente pueden caracterizarse
también por uno o más de una pluralidad de estados, en concreto un
estado de "Forwarding" (envío), un estado de "Discarding"
(descarte) y un estado de Learning (aprendizaje), cada uno de los
cuales se define en el estándar 802.1D 2004. En el estado de
aprendizaje, el puerto aprende temporalmente las identidades de los
nodos alcanzables a través del puerto pero no envía tramas. En el
estado de envío, que normalmente sigue al estado de aprendizaje, el
puente envía tramas de acuerdo con una base de datos de filtrado.
En el estado de "descarte" se bloquea todo el tráfico con la
excepción del tráfico de control de la Capa 2 del modelo de
referencia OSI (Open Systems Interconnection).
\newpage
En la figura 2 se muestra un diagrama de
mensajes que representa una ráfaga de tráfico de BPDU en la red de
comunicaciones 100 de la figura 1 como resultado del fallo de un
enlace. El término "ráfaga de tráfico" tal como se usa aquí se
refiere a situaciones en las que un puente habilitado con el
protocolo RSTP transmite simultáneamente una pluralidad de BPDU por
uno o más de sus puertos al mismo tiempo tras la recepción de una
BPDU con "superior information" en cualquier puerto. El
concepto de "superior information" tal y como se usa aquí está
definido en el párrafo 17.6 del estándar 802.1D 2004 titulado
"Priority vector calculations". La ráfaga de tráfico de BPDU
de la figura 1 representa un escenario del caso peor que podría
suceder baja las circunstancias indicadas más adelante. Como
consecuencia de una ráfaga de tráfico de BPDU puede retardarse la
convergencia del árbol de expansión.
Para los propósitos de este ejemplo, el puente
111 tiene la dirección MAC más baja del conjunto de puentes
111-120 del lado izquierdo de la red 100, los
puentes 112-119 tienen direcciones MAC
consecutivamente mayores comenzando a partir del puente 112, y el
puente 119 tiene la dirección MAC más alta. Las direcciones MAC de
los puentes 102-120 del lado derecho de la red 100
no son relevantes para la discusión que sigue. Suponiendo que los
enlaces de comunicaciones -incluyendo el enlace 130A- están activos,
el primer puerto 111A del puente 111 puede servir como un puerto
raíz mientras que el segundo puerto 111B puede servir como un puerto
alternativo 111B. Además, los puentes 101-120 están
configurados con los valores por defecto del protocolo RSTP
incluyendo un tiempo de migración de 3 segundos, un "Hello
time" del puente de 2 segundos, un tiempo máximo de validez de
la configuración del puente de 20 segundos, un retardo de envío del
puente de 15 segundos y un "transmit hold count" de 6
segundos. El puente 112 incluye un puerto designado 112A para
transmitir tramas al segmento adyacente de la LAN (local area
network) mientras que el puente 111 incluye un puerto alternativo
111 que proporciona un camino alternativo desde el segmento
intermedio de la LAN con el puente raíz.
Para los propósitos del ejemplo siguiente se
supone que el puente 101 es el puente raíz, que el puente 102 es el
puente designado con respecto a los puentes 103-111,
y que el puente 120 es el puente designado con respecto a los
puentes 112-119. Si el enlace de comunicaciones 130A
entre el puente 120 y el puente raíz 101 falla y se termina el
intercambio de datos 202, los puentes intercambian BPDU para
reestablecer el camino de propagación adecuado de acuerdo con el
protocolo RSTP. Tras el fallo del enlace 130A y la reestructuración
del árbol de expansión, todas las tramas transmitidas a la
pluralidad de puentes 102-120 se transmitirán a
través del puente 102.
Tras la detección del fallo del enlace, el
puerto 120B del puente 120 se reclasifica desde un puerto raíz a un
puerto inhabilitado y se elimina toda la información de puerto raíz.
En ausencia del conocimiento del puente raíz 101 o del camino al
mismo, el puente 120 cree que es el puente raíz y envía una BPDU 204
al puente 119 anunciando que el puente 120 es el nuevo puente raíz.
Tras la recepción de la BPDU 204 procedente del puente 120, el
puente 119 descarta su información de puerto raíz y el puerto 119B
del puente compara el MPV recibido con su propio vector PPV. Cuando
el puente 119 determina que tiene un vector mejor, el puente 119
transmite inmediatamente BPDU 206 por cada uno de sus puertos
anunciando que el puente 119 es el nuevo puente raíz. Aunque el
puerto 120A del puente 120 cambia al estado de puerto designado, el
puente 118 compara, 207, el MPV recibido del puente 119 con su
propio vector PPV. Cuando el puente 118 determina que tiene un
vector con prioridad superior, el puente 118 transmite
inmediatamente una BPDU 208 a sus vecinos anunciando que el puente
118 es el nuevo puente raíz. El puerto 119A del puente 119 cambia al
estado de puerto designado y la BPDU 208 es enviada al puente
120.
El modelo descrito anteriormente se repite
muchas veces con cada puente desde el puente 117 al puente 111
recibiendo una BDPU que anuncia que el puente que transmite es el
puente raíz. Cada vez, el puente debe comparar,
209-215, el vector de prioridad recibido con el PPV
local y responder inmediatamente con una nueva BDPU identificándose
a sí mismo como el puente raíz. En cada paso, las BPDU se transmiten
a los puentes subsiguientes hasta el puente 120, dando lugar con
ello a una importante ráfaga de tráfico de BPDU. La ráfaga de
tráfico únicamente disminuye cuando el puerto alternativo 111B del
puente 111 transmite una BPDU 210, identificando al puente 101 como
el verdadero puente raíz. Esta BPDU que identifica el apropiado
puente raíz se propaga a cada uno de los puentes
112-120 y cada puente actualiza su información de
puerto raíz. Como comprenderán los expertos en la materia, BPDU de
propuesta/acuerdo (no mostradas) pueden continuar propagándose por
la red 100 de acuerdo con el protocolo RSTP. Como puede verse, el
puente 120 adyacente al enlace que falló 130A recibe diez BPDU en
la ráfaga de tráfico de BPDU. En general, el tamaño mínimo de ráfaga
experimentado por un puente es igual al número de puentes entre el
puente raíz 101 y el puente alternativo 111 en la dirección del
fallo.
La primera versión del árbol de expansión en el
legado del estándar 802.1D 1998, introdujo un limitador de ráfagas
para inhibir ráfagas de tráfico de BPDU como la descrita
anteriormente. Un puerto que cumple con el estándar RSTP lleva
cuenta del número de BPDU enviadas con una variable estándar que
denominaremos "txCount", que se incrementa cada vez que se
transmite una BPDU. No se transmite una BPDU si la variable
"txcount" alcanza un valor máximo dado llamado txHoldCount. El
número txCount se decrementa también automáticamente cada segundo,
permitiendo con ello que las transmisiones de BPDU se reanuden en un
momento posterior. De esta manera se permite que un puerto emita
ráfagas tan rápidamente como sea capaz hasta que se alcance el
txHoldCount, y después transmita como máximo una BPDU por segundo
mientras txCount permanezca menor o igual que txHoldCount.
Actualmente, se permite que el valor txHoldCount
varíe entre uno y diez, con un valor por defecto fijado en seis.
Puesto que el número de BPDU que pueden transmitirse está
correlacionado con el número de nodos en la red, una red
relativamente mayor aumenta las probabilidades de que uno o más
puentes alcancen dicho valor umbral. Como resultado, el tiempo
necesario para la convergencia puede retardarse entre uno y varios
segundos en función de la frecuencia con la que se active el
limitador de ráfagas.
Por consiguiente existe la necesidad de un
sistema y de un método para restringir el número de BPDU
transmitidas mientras que se permite que la red converja tan
rápidamente como sea posible sin retardos indebidos que resulten del
limitador de ráfagas del protocolo RSTP.
La invención resuelve estos y otros objetivos
mediante el dispositivo conmutador de la reivindicación 1 y mediante
el método de la reivindicación 10.
La invención en la realización preferida ofrece
un sistema y un método para controlar ráfagas de unidades de datos
del protocolo entre puentes en una red de comunicaciones de datos
que comprende una pluralidad de puentes o dispositivos similares.
El dispositivo conmutador comprende, preferiblemente, un primer
puerto habilitado con un protocolo de gestión de enlaces así como
una máquina de estados de control de ráfagas. La máquina de estados
de control de ráfagas está preparada para recibir una primera BPDU
procedente de un puente alcanzable a través del puerto y, bajo
ciertas condiciones, retardar la transmisión de una segunda BPDU
anunciando que el dispositivo conmutador es el nuevo puente raíz
cuando, de hecho, no lo es. El retardo es, preferentemente, lo
suficiente largo como para permitir a otro puente, ya sea el puente
raíz o el puente designado, que transmita la identidad del
verdadero puente raíz. El retardo, por ejemplo un retardo del
control de la ráfaga, es preferiblemente igual o menor que un valor
del temporizador del "Hello time" generalmente fijado en 2
segundos en el estándar RSTP. En la realización preferida, las
condiciones incluyen las siguientes: el primer puerto es un puerto
raíz en el estado de"Forwarding"; el primer puerto pasa de ser
un puerto raíz a ser un puerto designado en respuesta a la primera
BPDU. Las condiciones pueden incluir además las siguientes: la
información de envío asociada con el primer puerto es actual, es
decir "infoIs" = RECEIVED; y un indicador de cambio de
topología recibido con la primera BPDU es falso, es decir
"proposing" = FALSE.
La presente invención se muestra a título de
ejemplo y no como limitación en las figuras de los dibujos adjuntos,
y en los que:
- la figura 1 es una red de comunicaciones de
datos que incluye una pluralidad de puentes habilitados con el
protocolo STP (spanning tree protocol);
- la figura 2 es un intercambio de mensajes de
acuerdo con el protocolo RSTP entre los puentes de la red de
comunicaciones de datos, de acuerdo con el estado de la técnica;
- la figura 3 es un conmutador BC (burst
control; con control de ráfagas) preparado para realizar el control
de ráfagas de la gestión del enlace, de acuerdo con la realización
preferida de la presente invención;
- la figura 4 es la máquina de información de
estados de los puertos de un puente según el estado de la técnica
habilitado con el protocolo RSTP;
- la figura 5 es la máquina de estados del
control de ráfagas del conmutador BC de acuerdo con la realización
preferida de la presente invención;
- la figura 6 es el estado "UPDATE" de la
máquina de información de estados de los puertos según el estado de
la técnica;
- la figura 7 es un estado
"UPDATE_BURST_AVOID" implementado en la máquina de estados de
los puertos con control de ráfagas, de acuerdo con la realización
preferida de la presente invención;
- la figura 8 es una máquina de estados de la
selección del papel de los puertos implementada en la máquina de
estados de los puertos con control de ráfagas, de acuerdo con la
realización preferida de la presente invención; y
- la figura 9 es un intercambio de mensajes de
acuerdo con el protocolo RSTP entre los puentes BC de la red de
comunicaciones de datos de la figura 1, de acuerdo con la
realización preferida de la presente invención.
En la figura 3 se muestra un dispositivo
conmutador preparado para llevar a cabo el control de ráfagas en la
gestión del enlace de acuerdo con la realización preferida. En la
realización preferida, el dispositivo conmutador es un puente 300,
aunque la invención es igualmente aplicable a enrutadores y
conmutadores multicapa preparados para proporcionar operaciones de
encaminamiento y reenvío a las capas 2 y 3 del modelo de referencia
OSI (Open Systems Interconnection). El conmutador 300 en la
realización preferida incluye una pluralidad de interfaces de la
capa 2 representados por entidades MAC 302, una entidad "MAC
Relay" 306 y entidades de capa superior 308. Cada una de las
entidades MAC 302 incluye un receptor de tramas 310 y un transmisor
de tramas 312 conectados de forma operativa a una LAN (local area
network; red de área local) 304A-304B a través de un
puerto externo 300A-300B, respectivamente.
La entidad MAC 302 maneja todas las funciones
dependientes del método de acceso al medio (protocolo y
procedimientos MAC) de acuerdo con el estándar RSTP incluyendo la
inspección de todas las tramas recibidas en la LAN y la transmisión
de las tramas recibidas de la entidad "MAC Relay" 306 y de
entidades de capa superior 308. La entidad "MAC Relay" 306
interconecta la pluralidad de puertos 304A-304B y
maneja las funciones independientes del método de acceso al medio
de retransmisión de tramas entre puertos de puentes incluyendo el
filtrado de las tramas y el aprendizaje de las fuentes. La entidad
"MAC Relay" 306 incluye una base de datos de filtrado 314 y
una pluralidad de tablas PSI (port state information; información
del estado del puerto) 316. La base de datos de filtrado 314
retiene información de filtrado que incluye direcciones de envío
conocidas y puertos aplicables 304A-304B a los que
pueden enviarse las tramas recibidas. La tabla PSI 316 asociada con
un puerto incluye un registro de los estados de envío y de
aprendizaje del puerto, es decir si el puerto está en ese momento
en el estado de reenvío, de aprendizaje, de escucha, de bloqueo o
deshabilitado. En la realización preferida, la tabla PSI 316
mantiene también un registro de la BCI (burst control information;
información de control de ráfagas) 318 que incluye los parámetros
"burstAvoidanceControl" y "burstAvoid" que se describen
con más detalle después.
Las entidades de capa superior 308 incluyen
entidades LLC (logical link control; control del enlace lógico) 320
y una entidad de protocolo del puente 322. Las entidades LLC 320
abarcan tanto las capacidades de la capa de enlace -que incluyen la
demultiplexación, por ejemplo- proporcionada por la LLC tal como se
especifica en el estándar 8802-2 de ISO
(International Standard Organization) y del IEC (International
Electrotechnical Commission), como la interpretación del
"Type" del campo "Lenght/Type" especificado en el estándar
802.3 del IEEE. La entidad de protocolo del puente 322 mantiene una
pluralidad de máquinas de estado del protocolo RSTP incluyendo una
PISM (Port Information State Machine; máquina de información de
estados de los puertos) adaptada para ejecutar el protocolo de
evitación de ráfagas, y mantiene los parámetros y los temporizadores
de configuración del protocolo RSTP. La PISM está definida en el
estándar RSTP para contestar a las BPDU de configuración y
responder a las BPDU que transmiten TCN (Topology Change
Notification; notificación de cambio de topología). En la
realización preferida, la PISM mejorada incluye una BCSM (Burst
Control State Machine; máquina de estados de control de ráfagas)
324 que modifica los instantes de las BPDU de notificación de
cambios de topologías para prevenir ráfagas de tráfico de BPDU
potencialmente perjudiciales.
En la realización preferida, la BCSM 324 es una
mejora sobre la PISM definida en el estándar RSTP que se incorpora
por la presente cita en esta memoria por referencia. En concreto, la
BCSM 324 hace que el dispositivo conmutador 300 pruebe diversas
condiciones tras la recepción de una BPDU con TCN en un puerto
designado y, si se cumplen estas condiciones, el dispositivo 300
induce un retardo en la transmisión de las BPDU de configuración
desde el mismo puerto designado. El retardo inducido, al que
denominaremos burstAvoidDelay, evita que el dispositivo de
conmutación concreto transmita una BPDU de configuración
identificando su propio vector de prioridad superior desde el
dispositivo conmutador antes de que se reciba una BPDU de
configuración del puente raíz o de un puerto alternativo. De esta
manera, el dispositivo conmutador suprime la transmisión de una o
más BPDU identificándose a sí mismas como raíz antes de que la
identidad del verdadero puente raíz sea comunicada por el puente
raíz o por el puerto alternativo. Dependiendo de la topología de la
red y de las direcciones MAC de los puentes en la red, la
realización preferida puede reducir significativamente el número de
BPDU transmitidas y, por consiguiente, reduce potencialmente el
tiempo requerido para determinar la topología de árbol en expansión
apropiada.
Cada uno de los puertos del puente del módulo
conmutador 300 está preparado para invocar el proceso de evitación
de ráfagas en respuesta a la recepción de una BPDU bajo las
condiciones apropiadas. En la realización preferida, el proceso de
evitación de ráfagas puede ser invocado por un puerto tras la
recepción de una BPDU si: (a) el puerto receptor es un puerto raíz
en el estado de "Forwarding" que está cambiando al papel de
designado como parte de un cambio de topología, y (b) el puerto ha
recibido información actual (no vieja) del puente designado, es
decir, la variable "infoIs" tiene el valor "RECEIVED". Sin
embargo, el proceso de evitación de ráfagas no puede invocarse
mientras cualquier puerto de un puente esté intentando propagar una
notificación de cambio de topología a través de la red, es decir,
la variable "tcProp" no debería activarse; y no puede
invocarse si el puerto desde el que se recibe la BPDU está
intentando convertirse en un puente designado, es decir, no debe
activarse la etiqueta "proposal" de la BPDU recibida. En las
condiciones precedentes, el conmutador 300 de la realización
preferida está preparado para retardar el instante en que transmitir
una BPDU en la dirección del fallo de enlace al suprimir el
instante en que se activa la variable "newInfo". Es decir,
"newInfo", que es una variable booliana utilizada para
señalizar cuando debe transmitirse una BPDU con información de
topología cambiada, no se pone a TRUE de acuerdo con la PSIM del
estado de la técnica. En su lugar, el conmutador 300 pone la
variable "newInfo" a TRUE después de un periodo de tiempo que
no exceda burstAvoidDelay, no excediendo burstAvoidDelay del valor
del intervalo de tiempo "Hello time". Suponiendo que el valor
por defecto del "Hello time" se fija en 2 segundos, el
conmutador BC 300 puede retardar la transmisión de la BPDU en dos
segundos como máximo.
En algunas realizaciones, el proceso de control
de ráfagas de la realización preferida se implementa como una
mejora a la PISM (Port Information State Machine), mostrada en la
figura 4, en especial la funcionalidad asociada con el estado
UPDATE 402, así como las condiciones asociadas a la transición desde
el estado CURRENT 404 al estado UPDATE 402. A la PISM mejorada se
la denomina en esta memoria BCSM (Burst Control State Machine) 500,
que se muestra en la figura 5.
LA BCSM 500 en la realización preferida incluye
dos estados de actualización para variables de estados asociadas
con la transmisión de las BPDU desde el conmutador BC 300, en
concreto un estado UPDATE 402 consistente con el estándar RSTP, así
como un estado UPDATE_BURST_AVOIDANCE 502. Los estados
UPDATE_BURST_
AVOIDANCE 502 y UPDATE 402 representan estados alternativos, es decir, solamente uno de los dos se implementa en un instante dado. Cuál de los dos estados se implementa viene dictado por un parámetro burstAvoid cuyo valor se determina en función de las condiciones del control de ráfagas discutido anteriormente. El BCSM 500 en la realización preferida incluye además los siguientes estados: estado DISABLED 506, estado AGED 508, estado SUPERIOR_DESIGNATED 510, estado REPEATED_DESIGNATED 512, estado INFERIOR_DESIGNATED 514, estado NOT_DESIGNATED 516, estado OTHER 518, estado CURRENT 520 y estado RECEIVE 522. Los estados 506, 508, 510, 512, 514, 516, 518, 520 y 522 están definidos en el estándar RSTP y son bien conocidos por los expertos en la materia.
AVOIDANCE 502 y UPDATE 402 representan estados alternativos, es decir, solamente uno de los dos se implementa en un instante dado. Cuál de los dos estados se implementa viene dictado por un parámetro burstAvoid cuyo valor se determina en función de las condiciones del control de ráfagas discutido anteriormente. El BCSM 500 en la realización preferida incluye además los siguientes estados: estado DISABLED 506, estado AGED 508, estado SUPERIOR_DESIGNATED 510, estado REPEATED_DESIGNATED 512, estado INFERIOR_DESIGNATED 514, estado NOT_DESIGNATED 516, estado OTHER 518, estado CURRENT 520 y estado RECEIVE 522. Los estados 506, 508, 510, 512, 514, 516, 518, 520 y 522 están definidos en el estándar RSTP y son bien conocidos por los expertos en la materia.
El estado UPDATE 402, mostrado en la figura 6,
empleado en la presente invención (ver figura 5) es sustancialmente
el mismo que el estado UPDATE del PISM del estado de la técnica (ver
figura 4). En particular, el BCSM 500 en el estado UPDATE 402 está
preparado para definir o redefinir los siguientes parámetros del
sistema explicados en el estándar RSTP: proposing = proposed =
FALSE; agreed = agreed && betterorsameInfo (), donde
betterorsameInfo () es TRUE ó FALSE dependiendo del valor del
argumento de la función, el valor de la variable "infoIs", y
si el MPV es mejor o igual que el PPV; synced = synced &&
agreed; PortPriority = DesignatedPriority; PortTimes =
DesignatedTimes; updtInfo = FALSE; infoIs = Mine; y newInfo = TRUE;
estando definidos en el estándar RSTP cada uno de estos parámetros y
funciones del sistema.
En contraste con el estado de la técnica, el
BCSM 500 está preparado para pasar del estado CURRENT 520 al estado
UPDATE 402 si selected && uptdInfo && burstAvoid
adquiere el valor TRUE. Mientras que selected && uptdInfo
están definidos en el estado de la técnica, burstAvoid es un nuevo
parámetro introducido para regular cuál de los dos estados de
actualización debe ejecutarse. En la realización preferida,
burstAvoid es falso salvo que se satisfagan las condiciones de
control de ráfagas discutidas a continuación, es decir:
en donde burstAvoidanceControl es
un parámetro definido por el usuario con valor TRUE para configurar
control de ráfagas en la realización preferida, o con valor FALSE
si se quiere deshabilitar el control de ráfagas. El valor por
defecto de burstAvoidanceControl es TRUE en la realización
preferida, y el valor por defecto de burstAvoidanceControl es FALSE
significando que el protocolo inmediato no se ha activado por
defecto.
En la alternativa al estado UPDATE 402 del
estado de la técnica, la realización preferida es capaz de invocar
el estado UPDATE_BURST_AVOIDANCE 502 si selected && uptdInfo
&& burstAvoid adquiere el valor TRUE. Como se muestra en la
figura 7, el estado UPDATE_BURST_AVOIDANCE 502 está preparado para
definir o redefinir los siguientes parámetros del sistema
explicados en el estándar RSTP: proposing = proposed = FALSE; agreed
= agreed && betterorsameInfo (), donde betterorsameInfo ()
es TRUE ó FALSE dependiendo del valor del argumento de la función,
el valor de la variable "infoIs", y si el MPV es mejor o igual
que el PPV; synced = synced && agreed; PortPriority =
DesignatedPriority; PortTimes = DesignatedTimes; updtInfo = FALSE; e
infoIs = Mine. En contraste con el estado UPDATE 402 del estado de
la técnica, el BCSM 500 no pone "newInfo" = TRUE, evitando con
ello que el BCSM 500 transmita inmediatamente una BPDU en la
dirección del fallo del enlace. Como consecuencia, cualquier BPDU
transmitida desde el puerto asociado se retarda un máximo de dos
segundos de acuerdo con el "Hello time".
Como comprenderá cualquier experto en la
materia, burstAvoid es un parámetro de puerto, definido con respecto
a cada puerto conmutador, que autoriza que se active el protocolo
de evitación de ráfagas en el puerto asociado. El parámetro
burstAvoid puede ponerse inicialmente a FALSE en el estado DISABLED
506 del BCSM 500 que es por lo demás idéntico a la PISM mostrada en
la figura 4. El valor de burstAvoid puede ponerse a TRUE, si es
aplicable, en una función que denominaremos "burstAvoidFunc()"
invocada en el estado RECEIVE 802 de la máquina de estados de
selección del papel del puerto definida en el estándar RSTP. Como se
ilustra en la máquina de estados de selección del papel de los
puertos 800 de la figura 8, la función "burstAvoidFunc()" se
ejecuta, preferiblemente, de forma concurrente con las funciones
"clearReselectTree()", "updtRolesTree()" y
"setSelectedTree()". El parámetro burstAvoid puede ponerse de
nuevo a FALSE , si es aplicable, en una función que denominaremos
aquí "clearBurstAvoidFunc()" tras la terminación del estado
RECEIVE 802. Como se ha mencionado anteriormente, el procedimiento
de la variable "burstAvoidFunc()" se lleva a cabo sobre el
puerto que recibe la BPDU entrante si la BPDU recibida contiene
activada la etiqueta TC o una etiqueta de "proposal"
(propuesta), mientras que el procedimiento de la variable
"clearBurstAvoidFunc()" limpia todos los parámetros
burstAvoid en cada uno de la pluralidad de puertos del conmutador BC
300.
Cuando se activa el protocolo de evitación de
ráfagas de la realización preferida, el hecho de que el parámetro
newInfo no se establezca inmediatamente significa que la BPDU se
retarda hasta un máximo de dos segundos de acuerdo con el "Hello
time". El hecho de que en el puerto que ha recibido la BPDU no se
active "proposing" significa también que el protocolo sólo se
aplica si no existe un puerto alternativo en dicho puente. Un puerto
alternativo, que se convertirá en puerto raíz, activa REROOT, lo
que implica que cualquier puerto raíz reciente pasa al estado
DISCARDING y necesita enviar inmediatamente una "proposal" para
pasar de nuevo a ser DESIGNATED FORWARDING. También, si se activa
la variable "tcProp" en el puerto que recibe la BPDU, deben
enviarse BPDU de TC desde el puerto y no se activa el procedimiento
de evitación de ráfagas.
En la realización preferida, no se induce un
retardo de dos segundos en el cálculo del árbol de expansión
completo. El retardo real, que denominaremos burstAvoidDelay, es,
preferiblemente, el retardo asociado con el tiempo transcurrido
necesario para que la BPDU TC se propague hasta el puente
alternativo 111 y para que el puente alternativo envíe una BPDU de
retorno al puente que inicialmente detectó el fallo y se creyó que
era el nuevo puente raíz.
Cualquier experto en la materia comprenderá que
el BSCM 500 de la realización preferida es compatible hacia atrás,
es decir, el protocolo de evitación de ráfagas se aplica sobre un
puerto con protocolo RSTP incluso si dicho puerto RSTP está enfrente
de un puerto STP (spanning tree protocol) convencional.
En la figura 9 se ilustra un intercambio de
mensajes RSTP entre puentes BC de una red de comunicaciones de
datos. Por conveniencia, el intercambio de mensajes RSTP
representado corresponde a una red de comunicaciones de datos 100
que tiene la topología en anillo mostrada en la figura 1, en la que
cada uno de los puentes 101-120 es un conmutador con
control de ráfagas preparado para ejecutar el protocolo de evitación
de ráfagas de la realización preferida. Al igual que con el ejemplo
previo descrito anteriormente, el fallo de cualquiera de los
enlaces de comunicación con el puente raíz 101 rompe un camino de
transmisión activo en el árbol de expansión. Si y cuando el enlace
de comunicación 130A falla - indicado por la línea de puntos 902- el
puente BC 120 pierde su puente raíz e inicia un cambio de topología
para reestablecer un árbol de expansión dentro de los puentes BC
101-120. El puente BC 120 envía inmediatamente por
el puerto 120A una BPDU 904 declarando que es el nuevo puente
raíz.
Tras la recepción de la BPDU, 904 el puente BC
119 compara, 905, el MPV con su propio PPV y determina que tiene un
vector de mayor prioridad que el puente BC 120. El puerto 119B del
puente BC 119 pasa inmediatamente del estado de puerto "Root
Forwarding" al estado de puerto "Designated Forwarding".
Aunque el puente BC 119 procede a transmitir por el puerto 119A una
BPDU 906, declarando que el puente 119 es el nuevo puente raíz, el
puente 119 se abstiene de transmitir una BPDU desde el puerto 119B
si se cumplen las condiciones de control de ráfagas comentadas
anteriormente. Es decir, el puerto 119B retiene la transmisión de la
BPDU 206 enviada en el estado de la técnica (ver figura 2)
suponiendo que: (a) el puerto 119B era un puerto raíz en el estado
de "Forwarding" antes del fallo del enlace de comunicación
130A; (b) el puerto 119B pasaría al papel de "Designated"
después de que converja la topología del árbol de expansión; (c) la
información de reenvío en el puerto 119B no ha envejecido, es decir
la variable "indoIs" es igual a "received"; (d) no se ha
activado la etiqueta de la variable "tcProp" de la BPDU
recibida; (e) no se ha activado la etiqueta "proposal" de la
BPDU recibida; y (f) el usuario ha habilitado el protocolo de
evitación de ráfagas estableciendo la variable
"burstAvoidanceControl" igual a TRUE.
Aunque el escenario que acabamos de describir da
lugar a una situación temporal en la que existen cara a cara dos
puertos en estado "Designated Forwarding", en concreto el
puerto 120A del puente BC 120 y el puerto 119B del puente BC 119,
los expertos en la materia apreciarán que no existe impacto
perjudicial sobre las operaciones de reenvío ya que estos dos
puertos ya estaban antes en el estado de "Forwarding".
Tras la recepción de la BPDU 906, el puente BC
118 compara, 907, el MPV recibido con su propio PPV, determina que
tiene un vector con mejor prioridad que el puente BC 119, pasa de un
puerto "Root Forwarding" a un puerto "Designated
Forwarding", transmite una BPDU 908 declarando que el puente 118
es el nuevo puente raíz, y aplaza la transmisión de una BPDU al
puente BC 119 advirtiéndole de que es el nuevo puente raíz. De forma
similar, cada uno de los puentes BC 117-112 realiza
la comparación del vector de prioridad, 907, 909, 911, 913, 915,
917 tras la recepción de una BPDU en la interfaz en la dirección del
enlace con fallo 902, determina que tiene un vector de prioridad
superior y envía una BPDU advirtiendo que es el nuevo puente raíz.
La secuencia de BPDU transmitidas a partir del enlace con fallo
continúa hasta que una BPDU 913 procedente del puente BC 112 es
recibida por el puerto alternativo 111B del puente BC 111.
Tras el reconocimiento, 919, de su vector con
prioridad superior, el puerto 111B del puente BC 111 intenta el
pase a un papel de Designated y a un estado de "Forwarding", es
decir a un puerto "Designated Forwarding". Como tal, el puente
BC 111 transmite una BPDU "proposal" 910 al puente BC 112. El
puerto 112A del puente BC 112 -que es actualmente un puerto
"Designated Forwarding"- asume inmediatamente un papel de
puerto raíz y un estado de "Forwarding", es decir pasa a ser
un puerto "Root Forwarding". De acuerdo con el estándar RSTP,
el puente BC 112 envía una BPDU "proposal" 912 al puente BC
113, y cada uno de los sucesivos puentes BC 113-119
envía una BPDU "proposal" 914, 916, 918, 920, 922, 924, 926
hasta que la BPDU "proposal" es recibida por el último puente
BC 120. El puerto receptor de cada uno de los puentes BC
113-120 pasa de puerto "Designated Forwarding"
a puerto "Root Forwarding". Los expertos en la materia
comprenderán que los puentes BC 112-120 normalmente
responden a las BPDU "proposal" con otras BPDU "agreement"
(no mostradas) de acuerdo con el estándar RSTP.
\newpage
El árbol de expansión ha convergido tras la
recepción de la BPDU "proposal" 926 por el puente BC 120 y la
transmisión de la BPDU "agreement" asociada por el puente BC
120. Como cualquier experto en la materia comprenderá, se alcanza
la topología del árbol de expansión final sin el excesivo número de
BPDU intercambiadas en la situación del ejemplo mostrado en la
figura 2. Por ejemplo, el número de BPDU transmitidas al puerto 120B
del puente BC 120 es una, en contraste con las once BPDU
transmitidas al puerto 120B del puente 120 del estado de la técnica
expuestas en referencia a la figura 2 anterior. Además de las
menores exigencias de anchura de banda, la realización preferida de
la presente invención reduce también significativamente la
probabilidad de que algún puente alcance el límite de ráfagas, es
decir tcHoldCount, reduciendo con ello el retardo necesario para que
el árbol de expansión converja en un escenario con un único fallo
como el analizado anteriormente.
Las siguientes características, solas o en
cualquier combinación, pueden constituir también realizaciones
ventajosas de la invención descrita o reivindicada:
- El dispositivo conmutador descrito y/o
reivindicado, en el que la máquina de estados de control de ráfagas
está además preparada, si se satisfacen el conjunto de condiciones,
para transmitir automáticamente la segunda BPDU desde el primer
puerto después de que se recibe la primera BPDU, y para transmitir
la segunda BPDU desde el primer puerto el periodo de tiempo
predeterminado después de que se reciba la primera BPDU en base a
una variable de control de evitación de ráfagas;
- el dispositivo conmutador reivindicado y/o
descrito, en el que la variable de control de la evitación de
ráfagas es un valor definido por el usuario;
- el método reivindicado y/o descrito, en el que
el periodo de tiempo predeterminado es un retardo de evitación de
ráfagas igual o menor a dos segundos;
- el método reivindicado y/o descrito, en el que
el periodo de tiempo predeterminado es igual o menor que un "Hello
time" de acuerdo con el protocolo de gestión de enlaces.
Aunque la descripción anterior contiene muchas
especificaciones, éstas no deberían interpretarse como limitaciones
del alcance de la invención, sino solamente como ilustraciones de
algunas de las realizaciones de esta invención actualmente
preferidas.
Por consiguiente, la invención se ha descrito a
título de ejemplo y no de limitación, y debe hacerse referencia a
las siguientes reivindicaciones para determinar el alcance de la
presente invención.
Claims (10)
1. Un dispositivo conmutador preparado para
llevar a cabo el control de ráfagas en una red de comunicaciones de
datos que comprende una pluralidad de puentes (101, ..., 120),
comprendiendo el dispositivo conmutador:
un primer puerto (119B) habilitado con un
protocolo de gestión de enlaces;
y medios preparados para
recibir, en el primer puerto (119B), una primera
unidad de datos del protocolo entre puentes (BPDU) (904) procedente
de un primer puente (120) de una pluralidad de puentes;
caracterizado por una máquina de estados
de control de ráfagas preparada para
retardar una transmisión de una segunda BPDU
(926) desde el primer puerto (119B) durante un periodo de tiempo
predeterminado a partir del momento en que se recibe la primera BPDU
(904) si se cumplen un conjunto de condiciones;
en el que el conjunto de condiciones
comprende:
la variable "port role" del primer puerto
(119B) tiene el valor "Root";
el papel del puerto del primer puerto (119B)
pasa de raíz a designado en base a la primera BPDU (904); y
el primer puerto (119B) está es un estado de
"Forwarding".
2. El dispositivo conmutador de la
reivindicación1, en el que el periodo de tiempo predeterminado es un
retardo de evitación de ráfagas menor que o igual a dos
segundos.
3. El dispositivo conmutador de la
reivindicación 1, en el que el periodo de tiempo predeterminado es
menor que o igual a un "Hello time" de acuerdo con el protocolo
de gestión de enlaces.
4. El dispositivo conmutador de la
reivindicación 1, en el que el conjunto de condiciones comprende
además:
la información de envío asociada con el primer
puerto (119B) es actual; y
un indicador de cambio de topología es
falso.
5. El dispositivo conmutador de la
reivindicación 4, en el que el conjunto de condiciones comprende
además:
el primer puente (120) no está intentando
convertirse en un puente designado.
6. El dispositivo conmutador de la
reivindicación 1, en el que el papel del puerto del primer puerto
(119B) pasa de raíz a designado si la variable "selected Role"
tiene el valor DESIGNATED.
7. El dispositivo conmutador de la
reivindicación 4, en el que la información de envío asociada con el
primer puerto (119B) es actual si la variable "infoIs" tiene el
valor RECEIVED, y el indicador de cambio de topología es falso si la
variable "tcProp" tiene el valor FALSE.
8. El dispositivo conmutador de la
reivindicación 4, en el que el primer puente (120) no está
intentando convertirse en un puente designado si la variable
"proposing" tiene el valor FALSE.
9. El dispositivo conmutador de la
reivindicación 1, en el que el protocolo de gestión de enlaces se
selecciona del grupo formado por:
Spanning Tree Protocol, estándar 802.1D 2004 del
IEEE (International Electrical and Electronics Engineers); Rapid
Spanning Tree Protocol, estándar 802.1w del IEEE; Multiple Spanning
Tree Protocol, estándar 802.1Q 2003 del IEEE y estándar 802.1s del
IEEE.
10. Un método para controlar ráfagas de unidades
de datos del protocolo entre puentes (BPDU) en un dispositivo
conmutador en una red de comunicaciones de datos que comprende una
pluralidad de puentes (101, ..., 120), comprendiendo el método:
recepción, en un primer puerto (119B) habilitado
con un protocolo de gestión de enlaces, de una primera unidad de
datos del protocolo entre puentes (BPDU) (904) desde un primer
puente (120) de la pluralidad de puentes;
y caracterizado por:
retardar una transmisión de una segunda BPDU
(926) desde el primer puerto (119B) durante un periodo de tiempo
predeterminado a partir del momento en que se recibe la primera BPDU
(904) si se cumplen un conjunto de condiciones;
en el que el conjunto de condiciones
comprende:
la variable "port role" del primer puerto
(119B) tiene el valor "Root";
el papel del puerto del primer puerto (119B)
pasa de raíz a designado en base a la primera BPDU (904); y
el primer puerto (119B) está es un estado de
"Forwarding".
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/028,355 US7916668B2 (en) | 2004-12-30 | 2004-12-30 | Spanning tree protocol with burst avoidance |
| US28355 | 2004-12-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2313196T3 true ES2313196T3 (es) | 2009-03-01 |
Family
ID=35717738
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05028428T Active ES2313196T3 (es) | 2004-12-30 | 2005-12-23 | Protocolo de arbol de expansion con control de rafagas de datos. |
Country Status (7)
| Country | Link |
|---|---|
| US (2) | US7916668B2 (es) |
| EP (1) | EP1677469B1 (es) |
| CN (1) | CN100546303C (es) |
| AT (1) | ATE405075T1 (es) |
| DE (1) | DE602005008883D1 (es) |
| ES (1) | ES2313196T3 (es) |
| WO (1) | WO2006073721A2 (es) |
Families Citing this family (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006065795A2 (en) * | 2004-12-14 | 2006-06-22 | Alcatel Lucent | Ring rapid spanning tree protocol |
| US8325629B2 (en) | 2005-07-15 | 2012-12-04 | Cisco Technology, Inc. | System and method for assuring the operation of network devices in bridged networks |
| US8248920B2 (en) * | 2006-07-25 | 2012-08-21 | Cisco Technology, Inc. | Alternate spanning tree for faster indirect link failure recovery |
| CN100459526C (zh) * | 2006-08-10 | 2009-02-04 | 杭州华三通信技术有限公司 | 一种确定端口角色的方法 |
| DE102007015539B4 (de) * | 2007-03-30 | 2012-01-05 | Siemens Ag | Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks |
| CN101060485B (zh) * | 2007-05-11 | 2011-08-10 | 杭州华三通信技术有限公司 | 拓扑改变报文的处理方法和处理装置 |
| 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 |
| US8787217B2 (en) * | 2011-01-17 | 2014-07-22 | Telefonaktiebolaget L M Ericsson (Publ) | Method, apparatus and computer program product for fast retransmission of proposal messages |
| CN102111341B (zh) * | 2011-03-31 | 2013-11-06 | 杭州华三通信技术有限公司 | 构造交换网络生成树的方法和装置 |
| CN102255758B (zh) * | 2011-08-11 | 2014-09-10 | 神州数码网络(北京)有限公司 | 一种提高快速生成树协议收敛速度的方法 |
| US8798055B1 (en) * | 2011-08-11 | 2014-08-05 | Juniper Networks, Inc. | Forming a multi-device layer 2 switched fabric using internet protocol (IP)-routed / switched networks |
| US9160564B2 (en) * | 2012-06-25 | 2015-10-13 | Qualcomm Incorporated | Spanning tree protocol for hybrid networks |
| CN102761451A (zh) * | 2012-08-09 | 2012-10-31 | 武汉迈威实达软件有限公司 | 一种基于rstp改进型单环路冗余备份的实现 |
| CN104641603A (zh) * | 2012-09-19 | 2015-05-20 | 罗伯特·博世有限公司 | 用于运行计算机网络的方法 |
| GB2524749B (en) * | 2014-03-31 | 2018-12-19 | Metaswitch Networks Ltd | Spanning tree protocol |
| GB2524750B (en) * | 2014-03-31 | 2021-04-21 | Metaswitch Networks Ltd | Spanning tree protocol |
| CN105306294B (zh) * | 2015-10-20 | 2018-04-27 | 上海斐讯数据通信技术有限公司 | 一种交换机的测试用例生成系统及方法 |
| US11025537B2 (en) * | 2017-12-04 | 2021-06-01 | Is5 Communications, Inc. | Multiple RSTP domain separation |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6032194A (en) * | 1997-12-24 | 2000-02-29 | Cisco Technology, Inc. | Method and apparatus for rapidly reconfiguring computer networks |
| US6976088B1 (en) * | 1997-12-24 | 2005-12-13 | Cisco Technology, Inc. | Method and apparatus for rapidly reconfiguring bridged networks using a spanning tree algorithm |
| US6202114B1 (en) * | 1997-12-31 | 2001-03-13 | Cisco Technology, Inc. | Spanning tree with fast link-failure convergence |
| US6330229B1 (en) * | 1998-11-09 | 2001-12-11 | 3Com Corporation | Spanning tree with rapid forwarding database updates |
| US6898189B1 (en) * | 2000-08-23 | 2005-05-24 | Cisco Technology, Inc. | Restartable spanning tree for high availability network systems |
| US6535490B1 (en) * | 1999-03-04 | 2003-03-18 | 3Com Corporation | High availability spanning tree with rapid reconfiguration with alternate port selection |
| JP3715501B2 (ja) * | 2000-03-10 | 2005-11-09 | アンリツ株式会社 | スパニングツリー用ブリッジ及びそれを用いた経路変更方法 |
| JP3494167B2 (ja) * | 2001-05-30 | 2004-02-03 | 日本電気株式会社 | 通信装置及び通信システム並びに通信制御方法 |
| US7177946B1 (en) * | 2001-12-06 | 2007-02-13 | Cisco Technology, Inc. | Optimal sync for rapid spanning tree protocol |
| US7061875B1 (en) * | 2001-12-07 | 2006-06-13 | Cisco Technology, Inc. | Spanning tree loop guard |
| US20040105455A1 (en) * | 2002-08-29 | 2004-06-03 | Seaman Michael John | Automatic edge port and one way connectivity detection with rapid reconfiguration for shared media in spanning tree configured bridged Local Area Networks |
| JP3799010B2 (ja) * | 2002-12-19 | 2006-07-19 | アンリツ株式会社 | メッシュ型ネットワーク用ブリッジ |
| US7379429B1 (en) * | 2002-12-20 | 2008-05-27 | Foundry Networks, Inc. | Optimizations and enhancements to the IEEE RSTP 802.1w implementation |
| US7324461B2 (en) * | 2003-08-26 | 2008-01-29 | Alcatel Lucent | Selective transmission rate limiter for rapid spanning tree protocol |
| JP2005318086A (ja) * | 2004-04-27 | 2005-11-10 | Fujitsu Ltd | 伝送装置 |
| US7564779B2 (en) * | 2005-07-07 | 2009-07-21 | Alcatel Lucent | Ring rapid spanning tree protocol |
| US7729296B1 (en) * | 2007-09-07 | 2010-06-01 | Force 10 Networks, Inc. | Distributed BPDU processing for spanning tree protocols |
-
2004
- 2004-12-30 US US11/028,355 patent/US7916668B2/en not_active Expired - Fee Related
-
2005
- 2005-12-15 WO PCT/US2005/045402 patent/WO2006073721A2/en active Application Filing
- 2005-12-23 DE DE602005008883T patent/DE602005008883D1/de active Active
- 2005-12-23 EP EP05028428A patent/EP1677469B1/en not_active Not-in-force
- 2005-12-23 ES ES05028428T patent/ES2313196T3/es active Active
- 2005-12-23 AT AT05028428T patent/ATE405075T1/de not_active IP Right Cessation
- 2005-12-30 CN CNB2005101339964A patent/CN100546303C/zh not_active Expired - Fee Related
-
2011
- 2011-03-04 US US13/040,323 patent/US9621454B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| EP1677469A1 (en) | 2006-07-05 |
| EP1677469B1 (en) | 2008-08-13 |
| US20110149738A1 (en) | 2011-06-23 |
| US7916668B2 (en) | 2011-03-29 |
| CN1798155A (zh) | 2006-07-05 |
| ATE405075T1 (de) | 2008-08-15 |
| WO2006073721A2 (en) | 2006-07-13 |
| WO2006073721A3 (en) | 2007-03-01 |
| DE602005008883D1 (de) | 2008-09-25 |
| US20060146845A1 (en) | 2006-07-06 |
| CN100546303C (zh) | 2009-09-30 |
| US9621454B2 (en) | 2017-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2313196T3 (es) | Protocolo de arbol de expansion con control de rafagas de datos. | |
| US7929427B2 (en) | Ring rapid spanning tree protocol | |
| US7983150B2 (en) | VPLS failure protection in ring networks | |
| US7903586B2 (en) | Ring rapid multiple spanning tree protocol system and method | |
| US8817666B2 (en) | System and method for multiple spanning tree protocol domains in a virtual local area network | |
| US8462668B2 (en) | System and method for implementation of layer 2 redundancy protocols across multiple networks | |
| US8811168B2 (en) | Transient loop prevention in a hybrid layer-2 network | |
| US7551571B2 (en) | Technology for improving STP protocols in ethernet networks supporting VLANs | |
| EP1672847B1 (en) | Ring rapid spanning tree protocol | |
| US9264314B2 (en) | Method, system, and switch for making bridge in MSTP join region | |
| JP4467500B2 (ja) | ネットワーク中継装置 | |
| US6781953B1 (en) | Broadcast protocol for local area networks | |
| JP2002354001A (ja) | 通信装置及び通信システム並びに通信制御方法 | |
| US8228823B2 (en) | Avoiding high-speed network partitions in favor of low-speed links | |
| US8223671B2 (en) | Network system supporting spanning tree protocol, relay apparatus thereof, and method of creating spanning tree topology thereof | |
| WO2005015855A1 (es) | Procedimiento de conmutación de paquetes en un medio de transmisión con múltiples estaciones conectadas mediante distintos enlaces | |
| JP2009147653A (ja) | 通信システムおよびリングノード装置 | |
| Cisco | Configuring Spanning Tree | |
| Cisco | Configuring Spanning Tree | |
| Cisco | Configuring Spanning Tree | |
| Cisco | Configuring Spanningtree | |
| Cisco | Configuring Spanning Tree | |
| Cisco | Configuring Spanning Tree | |
| JP5427665B2 (ja) | スパニングツリーの再構成方法および通信装置 | |
| Kasu et al. | Spanning Tree Protocol |