ES2361545A1 - Procedimiento de encaminamiento de tramas de datos y puente de red. - Google Patents
Procedimiento de encaminamiento de tramas de datos y puente de red. Download PDFInfo
- Publication number
- ES2361545A1 ES2361545A1 ES200900508A ES200900508A ES2361545A1 ES 2361545 A1 ES2361545 A1 ES 2361545A1 ES 200900508 A ES200900508 A ES 200900508A ES 200900508 A ES200900508 A ES 200900508A ES 2361545 A1 ES2361545 A1 ES 2361545A1
- Authority
- ES
- Spain
- Prior art keywords
- bridge
- mac address
- address
- frame
- port
- 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.)
- Granted
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/18—Loop-free operations
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
-
- H04L12/24—
-
- 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/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/48—Routing tree calculation
- H04L45/484—Routing tree calculation using multiple routing trees
-
- 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/66—Layer 2 routing, e.g. in Ethernet based MAN's
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Small-Scale Networks (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Este procedimiento opera en el nivel de enlace de datos. Cada puente asocia, durante un tiempo de guarda, el puerto por donde es primero recibida una trama con una dirección MAC origen hasta que una trama unicast de respuesta confirma el camino bidireccional coincidente entre direcciones origen y destino. Cualquier trama del mismo origen recibida por otro puerto distinto es descartada. Cada puente reenvía por el resto de puertos, salvo los que supongan giros prohibidos (abajo-arriba), las tramas broadcast recibidas y desvía por el árbol de expansión (u opcionalmente devuelve) las tramas unicast con dirección de destino desconocida o caducada.El protocolo puede funcionar con encapsulado en los puentes frontera o sin encapsulado, utilizando en este caso reemplazamiento de direcciones universales MAC en los puentes frontera por direcciones locales MAC. Opcionalmente, el establecimiento y control de caminos puede realizarse proactivamente por los puentes frontera, especialmente los puentes conectados a servidores.
Description
Procedimiento de encaminamiento de tramas de
datos y puente de red.
La presente invención se encuadra en el marco de
las tecnologías de la información y las comunicaciones en general,
aplicándose más particularmente para las redes de área local (LAN) y
metropolitanas (MAN), como por ejemplo las redes campus
Ethernet.
En la actualidad, las redes campus implantadas
para la conexión de centros de enseñanza e investigación son redes
troncales de alta velocidad (Gigabit Ethernet,...), integrando
diferentes entornos y servicios (voz, datos, video) en una única
infraestructura IP ("Internet Protocol"), soportando distancias
de transmisión que pueden ir desde ámbito local hasta rangos
idénticos a los de redes de área amplia (WAN).
El encaminamiento de las tramas en los puentes
de red ("bridges", en inglés) para interconectar este tipo de
redes que actualmente se usa es derivado del definido en el estándar
IEEE 802.1D. Pero el uso de los actuales protocolos estándar de
Árbol de Expansión (STP: "Spanning Tree Protocol", en inglés)
en los puentes 802.1D tiene, para la implantación de redes de tamaño
medio o grande, las siguientes carencias:
- Se infrautiliza mucha infraestructura costosa
debido a los enlaces bloqueados por el Árbol de Expansión (STP) y se
produce congestión en los enlaces activos.
- Hay que asignar y gestionar las direcciones
IP, y la dirección IP cambia al cambiar el usuario de lugar de
conexión.
- Deben fragmentarse los dominios de conmutación
para limitar la propagación de problemas tales como tormentas de
tramas. Para ello, se requiere emplear encaminadores o enrutadores
de nivel de red ("routers", en inglés), o bien utilizar
Conmutadores Multicapa para fragmentar en subredes más pequeñas.
- Cuando se emplean redes LAN virtuales (VLANs),
estandarizadas según IEEE 802.1Q, para separar el tráfico y los
dominios de difusión dentro del dominio conmutado, es posible
utilizar de forma eficiente la infraestructura, pero es necesario
configurar y administrar las VLANs, así como diseñar y configurar
los Árboles de Expansión según el estándar 802.1Q, para luego
asignar las VLAN a los mismos.
- Por otra parte, la tecnología de Árboles
Múltiples De Expansión (MSTP: "Múltiple Spanning Tree
Protocol") es un terreno escasamente explorado en la práctica
fuera del estándar (IEEE 802.1s y 802.1Q-2003) y
susceptible de optimización. El MSTP es una extensión del Árbol De
Expansión Rápida (RSTP) que, a su vez, es una evolución de la
primera especificación del estándar 802.1D donde se define el STP:
RSTP se define en la norma 802.1w, que pasó a ser la edición del año
2004 (802.1D-2004) de la 802.1D.
\vskip1.000000\baselineskip
También son conocidos los conmutadores con
encaminamiento centralizado que se usan en Autonet ["Autonet: A
High-Speed, Self-Configuring Local
Area Network Using Point-to-Point
Links" de M. Shoreder et al., IEEE Journal on Selected
Areas in Communications, Vol. 9, No. 8, p.
1318-1335, 1991]. El mecanismo de encaminamiento que
utiliza Autonet se denomina encaminamiento arriba/abajo ("Up/Down
routing", en inglés) y se basa en asignar un sentido a todos los
enlaces de la red según la posición del vértice del enlace en el
árbol de distribución: arriba, si está mas cercano al Puente Raíz
(el nodo del árbol que no tiene padre); hacia abajo, si es al
contrario. Para ello, se asignan identificadores crecientes a los
puentes partiendo del puente raíz y descendiendo nivel a nivel hasta
los Puentes Hoja (los que no tienen hijos; un nodo A es padre de B
si existe un enlace de A al nodo B). Los enlaces entre nodos a la
misma altura reciben la orientación según la identidad del puente
sea mayor o menor. Una ruta legal es la que nunca usa/atraviesa un
enlace en la dirección hacia arriba después de haber usado uno hacia
abajo, es decir, se evitan los bucles prohibiendo los giros
abajo-arriba.
Una evolución del encaminamiento arriba/abajo la
constituyen los algoritmos basados en Prohibición de Giros (TP:
"Turn-Prohibition", en inglés) [por ejemplo,
"Application of Network Calculus to General Topologies using
Turn-Prohibition" de L. Starobinski et
al., IEEE INFOCOM 2002 p. 1151-1159, 2002]. Los
algoritmos de Prohibición de Giros operan normalmente en dos fases:
en la primera se define el conjunto de giros prohibidos y
posteriormente se construyen las tablas de encaminamiento. La
definición de los giros prohibidos consta a su vez de tres fases:
construcción del árbol de expansión, etiquetado de nodos según el
árbol de expansión y algoritmo de definición del conjunto de giros
prohibidos.
Otra solución existente es el encaminamiento
jerárquico RSJ (Protocolo RSTAA-STAR Jerárquico) que
se propone en la Tesis Doctoral de G. Ibáñez ["Contribución al
diseño de redes campus Ethernet autoconfigurables", Universidad
Carlos III de Madrid, 2005; disponible también en
http://enjambre.it.uc3m.es/\simgibanez/tesisgif69.pdf]. No
obstante, las direcciones en RSJ son de longitud variable, no
utilizables dentro de los campos estándar de una trama Ethernet, por
lo que se requiere un encapsulado adicional de la trama. El RSJ es
una extensión del protocolo STAR ("Spanning Tree Alternate Routing
Protocol") y no resuelve los bucles por caminos transversales en
el árbol.
Otra solución, denominada HURP ["Hierarchical
Up/Down routing architecture for ethernet backbones and campus
networks", Ibáñez, G. A., et al., IEEE Conference on
Computer Communications Workshops, INFOCOM, p.p.
1-6, 13-18 April 2008] es una
arquitectura de encaminamiento de nivel dos que se basa en la
asignación a cada nodo de un identificador jerárquico mediante un
mecanismo asociado al protocolo RSTP ("Rapid Spanning Tree
Protocol"). Utiliza una versión mejorada del protocolo
arriba/abajo (U/D) para prohibir determinados giros en determinados
nodos en lugar de inhabilitar enlaces (tal como hace RSTP) para
garantizar caminos sin bucles. Este protocolo tiene un rendimiento
similar o mejor que otros también basados en prohibición de giros y
además presenta una menor complejidad O(Nd) y mejor
escalabilidad. HURP mejora el rendimiento de U/D gracias al
conocimiento que sobre la topología de la red le proporcionan las
direcciones MAC locales jerárquicas (HLMAC: "Hierarchical Local
MAC"). Así, están permitidos los giros que alcanzan bien el nodo
destino bien la rama del árbol que contiene al destino, aunque
constituyan giros prohibidos para un reenvío cualquiera, gracias a
que una vez la trama alcanza la rama destino del árbol ya es
reenviada sobre ella sin necesidad de nuevas decisiones de
encaminamiento. Cada puente debe comprobar si alguno de sus vecinos
es un prefijo o contiene la dirección HLMAC del destino, para
proceder al reenvío independientemente del algoritmo de prohibición
de giros. Esta solución emplea encaminamiento por los enlaces
transversales implementado en el plano de control (intercambio de
tablas entre puentes).
Antecedentes en la utilización de enlaces
transversales más rápidos en las redes de puentes son:
- DLS (Distributed Load Sharing) que se propone
en US 4811337, donde dos puentes pueden acordar encaminar el tráfico
entre ellos por enlaces no pertenecientes al árbol de expansión
(enlaces transversales) si dicho enlace cumple ciertas condiciones:
(i) los dos puentes en los extremos del enlace seleccionado
implementan DLS, (ii) los dos puentes de los extremos no pueden ser
uno antecesor del otro en el árbol de expansión y (iii) la longitud
del camino asociada con el enlace seleccionado debe ser menor que la
suma de las longitudes de dichos puentes al puente raíz. Pero DLS
puede sobreestimar la longitud real del camino por el árbol de
expansión, por lo que puede elegir enlaces de camino más largo. DLS
es compatible con el protocolo estándar 802.1D por lo que los
puentes DLS pueden desplegarse en una red de puentes 802.1D.
- GDLS (Generalized DLS) que se propone en US
5150360 es una extensión y simplificación de la propuesta anterior
para evitar algunos inconvenientes de DLS, eliminando las
condiciones establecidas en DLS para el uso de enlaces transversales
(no perteneciente al árbol) al permitir que cada enlace transversal
sea elegible para reenvió de tramas. GDLS no compara la longitud del
enlace transversal con la del camino vía árbol, sino que estima la
velocidad de transmisión entre árboles midiendo el retardo mediante
una trama de datos específica del protocolo (BPDU: Bridge Protocol
Data Units) intercambiada entre los puentes GDLS de los extremos.
Mediante esta trama se comparan el retardo vía árbol con el retardo
por el enlace transversal y se selecciona el enlace de menor
retardo. GDLS es compatible hacia atrás con el protocolo IEEE
802.1D.
- OSR (Optimal-Suboptimal
Routing) ["Extended bridge algorithms for large networks"
Sincoskie, W. D.; Cotton, C.J.; IEEE Network, Vol. 2, Issue 1, p.p.
16-24, 1988) es un protocolo de puentes con
aprendizaje de forma que se pueden identificar rutas óptimas o
subóptimas entre puentes. Los puentes situados en el extremo,
puentes hoja ("leaf bridges") aprenden las direcciones MAC de
los equipos terminales ("hosts") conectados y las difunden
distribuyéndolas jerárquicamente hacia arriba en el árbol de forma
iterativa. Los puentes escuchan las tramas recibidas para localizar
estaciones en las LAN a las que están conectadas. Luego transmiten
este conocimiento a los puentes situados más arriba en el árbol y
así hasta alcanzar el puente raíz mediante mensajes de localización
OSR. Estos mensajes de localización son transmitidos por todos los
puertos de cada puente, incluso los bloqueados. Cada puente calcula
la ruta para conocer qué enlace utilizar para alcanzar por un camino
mínimo cada estación destino. Si hay más de una ruta óptima se
distribuye el tráfico entre ellas. Los puentes OSR encapsulan las
tramas con una cabecera con dirección destino de mul-
tidifusión ("multicast") especial para todos los puentes OSR. El protocolo es compatible hacia atrás con IEEE 802.1D.
tidifusión ("multicast") especial para todos los puentes OSR. El protocolo es compatible hacia atrás con IEEE 802.1D.
\vskip1.000000\baselineskip
Entre las soluciones existentes para la elección
del camino más rápido también merece especial atención la propuesta
de Bertsekas ["Data Networks", Bertsekas, Dimitri P.; Gallager,
Robert G.; ISBN-10: 0132009161, capítulo 5,
"Routing in Data Networks", página 370, 1992] como antecedente.
Bertsekas propone la difusión de paquetes mediante un árbol
enraizado en un nodo origen de difusión (nodo A). Cada nodo conoce a
su predecesor o padre en el árbol, pero no precisa conocer a sus
sucesores o hijo. El árbol puede utilizarse para encaminar paquetes
desde otros nodos al nodo A utilizando los caminos del árbol en
dirección opuesta. Asimismo puede usarse para inundar paquetes desde
el nodo A. La regla de inundación es la siguiente: un paquete
recibido del padre es reenviado a todos los vecinos excepto al
padre, todos los demás paquetes son ignorados. Un nodo reenvía
solamente los paquetes recibidos de su nodo padre, los demás
paquetes son ignorados. No se precisan números de secuencia en los
paquetes para detectar duplicados, porque
los paquetes solo se difunden por el árbol en la dirección de alejamiento del puente raíz, por lo que no hay bucles.
los paquetes solo se difunden por el árbol en la dirección de alejamiento del puente raíz, por lo que no hay bucles.
La inundación de paquetes propuesta por
Bertsekas puede usarse para construir un árbol enraizado en un nodo
A como el mencionado. El nodo A comienza el proceso enviando un
paquete a todos sus vecinos y éstos lo reenvían a sus vecinos y así
sucesivamente. Cada nodo marca al nodo transmisor del primer paquete
que recibe como su padre o antecesor en el árbol. Los nodos deben
reenviar el paquete a sus vecinos solamente una vez (tras recibir el
paquete de su padre), todos los paquetes sucesivos deben ser
ignorados.
La técnica de enrutamiento de Bertsekas presenta
ciertas deficiencias:
- No resuelve el problema de establecer un
camino bidireccional unidestino (unicast) simétrico, es decir que
pase por los mismos nodos en ambos sentidos, aspecto imprescindible
para que funcione el aprendizaje de direcciones MAC y pueda ser
aplicado en puentes transparentes con aprendizaje, aplicación no
contemplada por Bertsekas.
- No emplea el aprendizaje de direcciones de
nodos origen sino la construcción de un árbol mediante el
aprendizaje del nodo padre (antecesor inmediato), no del nodo raíz
del árbol, ni del equipo terminal emisor de la trama.
- No resuelve el encaminamiento unidestino entre
un nodo A y un nodo D cuando se utiliza aprendizaje hacia atrás
("backward learning"). Bertsekas contempla la difusión desde el
origen A al destino D y un encaminamiento unidestino desde D hasta
A, pero no con aprendizaje hacia atrás entre A y D porque, ante una
posible variabilidad de los retardos en cada enlace en ambos
sentidos de propagación, puede resultar seleccionado como camino más
corto en un sentido un camino distinto al de sentido contrario.
- No resuelve el problema del encaminamiento
entre equipos terminales ("hosts") y no menciona ningún
mecanismo arriba-abajo para prevenir bucles
transitorios que pueden producirse accidentalmente o durante los
transitorios de construcción del árbol.
- No resuelve el problema de la reconfiguración
del árbol en caso de fallo de un enlace o nodo y sus transitorios.
No explica cómo se detecta un fallo de un enlace o nodo ni cómo se
modifica el árbol tras un fallo.
\vskip1.000000\baselineskip
Una última propuesta reciente es el conmutador
del Servicio Universal de Telecomunicaciones Ethernet (UETS)
descrito en ES 2246702. Los conmutadores UETS también presentan
ciertas restricciones de compatibilidad con las redes Ethernet MAC
universales e IP. Los puentes estándar (802.1D) no pueden coexistir
de manera compatible dentro de un dominio UETS. Los dominios UETS y
Ethernet son disjuntos y las tramas a la entrada se clasifican y
envían hacia uno u otro dominio. Los conmutadores UETS requieren de
asignación de direcciones de capa dos OSI jerárquicas y de máscaras
de longitud configurable según la topología física de la red, siendo
asignadas mediante gestión, lo cual supone un sistema de
configuración complejo. Para obtener las direcciones Ethernet
locales de los dispositivos en un dominio UETS es preciso resolver
el identificador de domino o la dirección en IP en un servidor UETS
Ethernet DNS. No puede utilizarse el mecanismo ARP [definido en RFC
826 "An Ethernet Address Resolution Protocol", 1982] para
obtener dichas direcciones. Los conmutadores UETS no contemplan la
utilización de difusión amplia y multidifusión ("broadcast" y
"multicast", en inglés). UETS está orientado a conmutadores de
tipo Banyan para máximo rendimiento que no utilizan difusión,
mecanismo base del árbol de expansión.
En resumen, la problemática que sigue sin
resolverse completamente y es un fin al que la presente invención
trata de dar solución, definiendo conmutadores Ethernet de
funcionalidad añadida y sus protocolos de funcionamiento que
permiten conservar las ventajas de los puentes de red conocidos a la
vez que eliminan sus inconvenientes, es implementar redes Ethernet
de alta utilización y alta capacidad lo más autoconfigurables
posible. Asimismo, son objetivos de la invención que se describe
seguidamente maximizar el uso de la infraestructura de
comunicaciones, mediante el empleo de protocolos sencillos y con
coste de equipos reducido, así como simplificar los procesos de
configuración y mantenimiento de la red, evitando la administración
de direcciones IP en redes campus y su dependencia del lugar de
conexión del terminal.
La presente invención viene a resolver la
problemática anteriormente expuesta, en todos y cada uno de los
diferentes aspectos comentados, concibiendo un protocolo de
encaminamiento que opera en el plano de usuario (encaminando tramas
de datos), dentro del nivel de enlace de datos (segunda capa
OSI).
En este contexto, el de los protocolos de
encaminamiento aquí referidos, se entiende por:
- -
- plano de control, el relativo a los mensajes de control del protocolo intercambiados entre nodos, tales como unidades de datos de protocolo de puentes (BPDU: "Bridge Protocol Data Units", definidas en el estándar 802.1D).
- -
- plano de usuario, se refiere a las tramas enviadas por los usuarios y encaminadas por los nodos.
\vskip1.000000\baselineskip
El protocolo de encaminamiento de tramas de
datos que se propone, aquí llamado protocolo FastpathUD y así
denominado en adelante, comprende a su vez:
- Un protocolo de creación (o
establecimiento/construcción) y mantenimiento (configuración y
reconfiguración) de un árbol de expansión, que asigna a los puentes
de red direcciones consecutivas de forma ordenada según su distancia
o coste creciente al puente raíz del árbol.
\newpage
- Un protocolo de encaminamiento y reenvió
transparente, por ejemplo usando encaminamiento
arriba-abajo utilizando difusión amplia por toda la
red de las tramas de datos utilizadas para establecer un camino. El
protocolo efectúa una difusión total (reemplazando la difusión
limitada a través del árbol de expansión) sólo restringida por los
giros prohibidos en la topología para evitar bucles. Además, este
protocolo de encaminamiento y reenvió utiliza aprendizaje hacia
atrás restringido, el cual opera registrando o asociando el puerto
de cada puente multipuerto (conmutador) por el que se ha recibido
primero una trama a la dirección MAC origen de la trama. Este
aprendizaje hacia atrás es aplicable a direcciones MAC tanto
universales (UMAC: "Universal MAC") como locales (HLMAC:
"Hierarchical Local MAC").
\vskip1.000000\baselineskip
El protocolo de creación y mantenimiento del
árbol de expansión asigna direcciones (identidades) a los nodos
(puentes de red) del árbol según distancia creciente al nodo
(puente) raíz. Una opción de realización es asignar a los puentes
direcciones MAC locales de manera jerárquica mediante el protocolo
HURP ["Hierarchical Up/Down routing architecture for ethernet
backbones and campus networks", Ibáñez, G. A., et al.,
IEEE Conference on Computer Communications Workshops, INFOCOM, p.p.
1-6, 13-18 April 2008]. En este caso
a los puertos de cada puente también se les asigna una dirección MAC
local jerárquica (HLMAC). El equipo terminal conectado a un puerto
recibe la dirección asignada al puerto que conecta el terminal al
puente.
El protocolo de encaminamiento y reenvío de las
tramas hace la asociación o aprendizaje para cada puente de la
dirección MAC origen de una trama con el puerto por el que primero
se recibe, generando una tupla o entrada (por ejemplo, en una
memoria interna del puente) que comprende al menos:
- -
- los (48) bits de la dirección MAC origen,
- -
- la dirección (identidad) de puerto asignada por el protocolo de creación y mantenimiento del árbol de expansión,
- -
- un indicador de captura de la dirección que indica que la entrada (la posición de memoria correspondiente) está bloqueada para el proceso de aprendizaje (enganchada al puerto asociado)
- -
- un indicador de retención o caducidad ("aging") de la dirección aprendida.
\vskip1.000000\baselineskip
Los indicadores de captura y de caducidad actúan
como temporizadores. El indicador de captura tiene asociado un
intervalo de tiempo (tiempo de captura, guarda o bloqueo),
dimensionado de forma que se evita que la recepción retrasada de
alguna trama con el mismo origen y que la que activó el aprendizaje
por otro puerto del puente causen el reaprendizaje de dicha
dirección origen pero asociándola a otro puerto. Cuando, durante el
intervalo de captura, se recibe una trama unicast en sentido
contrario y con dirección destino la dirección aprendida, el
aprendizaje de la dirección en ese puerto queda confirmado y a la
vez se asocia la dirección unicast origen al puerto por el que se
recibió. En este puente ha quedado establecida la conexión
bidireccional entre dichas direcciones unicast. El puente puede
utilizar esa información para el reenvió de tramas. De no recibirse
la trama unicast de respuesta en el intervalo del temporizador de
captura, se borra la entrada en la caché correspondiente a la
dirección cuyo intervalo de retención ha expirado. El intervalo de
captura se dimensiona en función del máximo retardo esperable de
respuesta de la red a un paquete ARP.
El indicador de caducidad o retención opera
igual que en un puente estándar: es el intervalo durante el que se
mantiene aprendida la dirección sin ser refrescada. De este modo, si
ha transcurrido un intervalo superior al de caducidad de las
entradas sin haber sido renovado el temporizador, por no haberse
recibido ninguna trama con dicha dirección origen, el indicador de
caducidad se pone a cero para indicar que la asociación dirección
MAC origen-puerto del puente está caducada. El
tiempo de caducidad o validez de la trama se marca a partir del
tiempo de llegada de la trama por el puerto, que también puede
registrase en la entrada (tupla).
La asociación entre dirección MAC
origen-puerto de entrada puede realizarse mediante
una tabla o memoria caché, opcionalmente de tipo direccionable por
contenido Content Addressable Memory (CAM), que se accede por el
contenido de los 48 bits de dirección MAC. El protocolo de
encaminamiento y reenvío crea una entrada en la CAM que contiene la
identidad de puerto asociada y los indicadores de retención de la
dirección y de caducidad. El indicador de retención impide que la
posición de memoria pueda actualizarse con otro puerto durante el
tiempo de guarda (esa posición queda bloqueada en ese tiempo) y
tampoco permite la escritura de la dirección de entrada (MAC origen)
en otra parte de la memoria.
La anotación en la tabla de una entrada (tupla)
activa el temporizador programable de captura que bloquea dicha
entrada e impide su actualización, en particular el valor de la
identidad de puerto por donde fue recibida (aprendida) la trama. Al
ser anotada (aprendida) una dirección MAC origen asociada al puerto
de entrada en la tabla caché, dicha asociación dirección
origen-puerto de entrada es bloqueada, es decir, no
puede modificarse durante el tiempo de bloqueo/guarda ni pueden
crearse nuevas asociaciones de dicha dirección MAC a otros puertos
del mismo puente.
Desde cada puente se reenvían las tramas
recibidas con dirección de destino de difusión (broadcast), no
solamente por los puertos habilitados por el protocolo de árbol de
expansión sino que son reenviadas por todos los puertos del puente,
excepto el puerto por el que primero se recibió la trama en el
puente y por los por puertos que impliquen realizar a la trama un
giro prohibido (giro abajo-arriba).
En cada puente que se recibe una trama,
solamente se anota una entrada en la caché (tabla u otro tipo de
registro en el puente) con la dirección origen de la trama, cuando
no existe previamente una entrada con la misma dirección origen y en
tal caso, se registra la identidad del puerto de entrada de la trama
y el instante de su llegada. Opcionalmente, puede asignarse un
identificador de trama, resultado de una operación lógica con
algunos o todos los valores de los campos de la trama recibida (por
ejemplo, el campo de la dirección destino), para usarse en el acceso
a la entrada.
En cada puente que se recibe una trama, se
descartan todas las tramas idénticas (con el mismo contenido) que
son recibidas, durante el intervalo de bloqueo (período de guarda),
por puertos distintos al que causó el registro de la (misma)
dirección MAC origen en la tabla caché. También, son descartadas las
tramas semejantes (las que dan resultado coincidente al realizar una
operación lógica sobre las mismas, tal como el chequeo de misma
dirección origen).
Las tramas recibidas tienen una dirección MAC
destino, que puede ser de difusión ("broadcast") o unidestino
("unicast", dirección que corresponde a un único "host"),
entre otras posibles direcciones destino.
Los puentes que soportan el protocolo propuesto
(puentes FastPathUD) ofrecen dos alternativas para el reenvió de las
tramas unidestino que no conocen.
En la primera alternativa, a diferencia de los
puentes estándar 802.1D, los puentes FastPathUD no reenvían la trama
recibida por todos los puertos restantes (cuando la dirección MAC
destino no existe asociada a ningún puerto en la caché o ha
caducado), sino que modifican y devuelven la trama por el puerto
recibido hacia el puente frontera que la emitió, intercambiando sus
direcciones origen y destino y modificando un campo que indica ruta
caducada. Este procedimiento de desaprendizaje de rutas mediante
tramas devueltas se detalla más adelante.
Se entiende por puente frontera destino (también
denominado como puente designado) el puente conectado directamente
al terminal ("host") destino y que se encarga de enviar y
recibir sus tramas. El puente frontera destino de dicha trama
realiza un nuevo establecimiento de ruta mediante una trama de
difusión con dirección origen la de dicho puente. Opcionalmente,
cada puente receptor de una trama de difusión responde a dicha trama
por el puerto donde primero fue recibida con una nueva trama de
establecimiento parcial de camino, cuya dirección origen es la de
dicho puente y su dirección destino la del puente frontera origen,
el puente conectado al terminal origen de la trama recibida. Este
mecanismo opcional permite consolidar los caminos entre puentes
intermedios y el puente frontera origen para su uso por otras
tramas.
En la segunda alternativa, los puentes
FastPathUD que reciben una trama con dirección unicast destino
desconocida la etiquetan con una identificación de VLAN (que puede
ser la VLAN ID por defecto) y la reenvían por el árbol de expansión
de la forma estándar 802.1D, no realizándose establecimiento de
camino FastpathUD en el resto del trayecto. Las tramas desviadas del
trayecto por el árbol recorren el árbol de expansión mediante
mecanismo de difusión con o sin (según opción de configuración o
implementación) aprendizaje hacia atrás estándar de la dirección
origen. Si se emplea aprendizaje hacia atrás en el árbol de
expansión, las tramas de respuesta recorren en sentido inverso el
mismo camino que las tramas recibidas, la primera parte por el árbol
de expansión a través de los enlaces donde fue aprendida la
dirección y, una vez alcanzado el puente FastpathUD que realizó el
desvío al árbol de expansión, recorren el camino FastpathUD hasta el
terminal origen. Si no se emplea aprendizaje hacia atrás, las tramas
son difundidas por todo el árbol de expansión hasta alcanzar el
terminal destino.
Adicionalmente, el protocolo de encaminamiento y
reenvió de las tramas de datos en un puente frontera puede
encapsularlas con una cabecera cuyos campos origen y destino son una
dirección MAC local jerárquica (HLMAC), que está contenida como
prefijo de las direcciones de los puentes y estaciones conectados al
puente frontera. En este caso, el puente frontera elige destino
entre sus rutas disponibles, seleccionando aquel puente cuyo prefijo
compartido con la dirección del terminal destino es más largo y
tiene ruta activa.
El protocolo de creación y mantenimiento de
caminos FastPathUD permite asimismo la configuración y
reconfiguración de caminos simétricos en la red de puentes, mediante
el envió periódico de tramas entre puentes frontera que mantienen
aprendidos los caminos entre ellos con mecanismos adicionales de
comprobación de estabilidad y simetría del camino entre los puentes
en ambos sentidos. Los puentes envían opcionalmente unos paquetes o
tramas trazadores, periódicamente en secuencias predeterminadas y
conocidas por todos los puentes, lo que permite a los puentes
receptores verificar la disponibilidad, estabilidad y optimización
de la ruta rápida al comparar los resultados de la recepción del
mismo paquete trazador por diversos puertos. Los paquetes trazadores
tienen como dirección origen cada uno de los puentes FastPathUD
frontera y pueden tener como dirección de destino la correspondiente
a un único puente frontera destino ("unicast") para mantener un
camino establecido entre puentes, o bien, una dirección de difusión
("broadcast").
Adicionalmente, el protocolo FastpathUD utiliza
mecanismos de prohibición de giros para evitar los bucles en la
difusión de tramas. La utilización para el control de los giros de
las direcciones asignadas en orden por la distancia de cada
nodos/puente al nodo raíz evita la necesidad de ejecutar un
algoritmo centralizado en la red que determine los giros permitidos
y prohibidos. El procedimiento para evitar los bucles por
prohibición de giros se ejecuta en cada nodo de forma independiente
a partir de: su dirección asignada (por ejemplo, HLMAC), las de los
nodos anterior y siguiente en la ruta y, opcionalmente, para
optimización, las direcciones origen y destino de la trama. Los
puentes impiden ejecutar los giros prohibidos a las tramas de
usuario aunque ello suponga no utilizar un camino mínimo.
Puesto que el protocolo FastPathUD asigna las
identidades según distancia creciente al puente raíz, la dirección
(identidad) del nodo/puente raíz es siempre la menor y crece al ir
bajando por el árbol, lo que garantiza una efectividad alta en la
prohibición de giros y el que la red no quede desconectada. De esta
forma, siempre es posible alcanzar cualquier nodo de la red a través
de caminos formados por combinaciones arbitrarias de giros
arriba/abajo, arriba/arriba y abajo/abajo, pero sin giro alguno
abajo/arriba, asegurando esto último la inexistencia de bucles.
Asimismo, el protocolo de encaminamiento que se
describe también incluye:
- Un proceso opcional de desaprendizaje
(borrado) de rutas aprendidas, mediante tramas devueltas hacia la
dirección MAC origen por el puente que las recibe, modificando la
trama a retornar (en un campo tal como la identidad de VLAN o bit)
con direcciones MAC universales o locales HLMAC.
\vskip1.000000\baselineskip
El proceso de desaprendizaje interviene
opcionalmente en la reconfiguración de la red. El proceso de
desaprendizaje (borrado) mediante devolución de las tramas con
direcciones afectadas por una reconfiguración puede ser provocado
por una calda de puente de red, enlace (perteneciente o no al árbol
de expansión) y opcionalmente por caducidad de las direcciones si no
se utiliza el reenvió por el árbol de expansión de las tramas con
dirección unicast desconocidas por el puente.
El protocolo FastPathUD permite la
reconfiguración de la red debida a una calda de un enlace, que
pertenece o no al árbol de expansión. En todos los casos, el
mecanismo estándar de borrado de direcciones MAC aprendidas es
aplicado tanto para el borrado de direcciones MAC universales o
locales aprendidas en los puertos (función estándar de los puentes
802.1D) como de las direcciones locales (o locales jerárquicas:
HLMAC) asignadas a los puentes con ayuda del protocolo RSTP. Durante
la reconfiguración del árbol de expansión, el reenvío de tramas por
los puertos se bloquea de acuerdo a dicho protocolo. El control de
giros arriba/abajo va ligado igualmente a la reconfiguración del
protocolo RSTP, dado que las direcciones locales/HLMAC se asignan de
acuerdo a dicho protocolo. Cuando se habilita el puerto raíz de un
puente por el protocolo RSTP es cuando el puente adquiere una
dirección local válida a efectos de control de giros
arriba/abajo.
En el caso de que la reconfiguración de red se
produzca por la caída de un enlace, se hace necesario el borrado de
las direcciones aprendidas en los dos puertos del enlace. Cuando se
detecta la caída del enlace, de forma local o a través del protocolo
RSTP, los puentes de sus extremos actúan borrando todas las
direcciones aprendidas mediante FastPathUD en el puerto conectado a
dicho enlace en fallo. Cuando se reciba una trama unicast con
destino según una de las dos posibles variantes de implementación
que se describen del mecanismo de desaprendizaje:
i) Implementación del desaprendizaje preferida
cuando se emplean direcciones UMAC: Usando una BPDU del protocolo
FastPathUD, dentro del tipo Ethernet correspondiente a los
protocolos estándar 802. Esta BPDU usa como dirección destino la
dirección de grupo multicast de todos los puentes FastPathUD y
utiliza el mismo encapsulado LLC (encabezado IEEE 802.2 LLC:
"Logical Link Control") que las BPDUs de árbol de expansión. La
BPDU del protocolo FastPathUD también incluye, en la carga de datos
("data payload"), la dirección destino del paquete de borrado y
la o las direcciones no alcanzables. Cada puente que recibe dicha
BPDU la procesa, borrando dichas direcciones de la caché de su
puerto donde aún eran válidas, y la reenvía inmediatamente al
siguiente puente en el camino de vuelta de la trama a su origen.
ii) La otra variante de implementación, posible
cuando se emplean direcciones HLMAC que disponen de bits libres en
su parte menos significativa, consiste en usar tramas de datos con
el bit menos significativo de la dirección origen (bit situado en el
extremo derecho de la dirección local o HLMAC, separado de la
dirección válida HLMAC por uno o más bits a cero) activado a
"1". Este valor de dicho bit es interpretado por los puentes
FastPath atravesados como desaprendizaje de dirección. Cuando un
puente recibe por un puerto una trama dirigida a una dirección que
fue aprendida en dicho puerto, la devuelve por el puerto donde se
recibió pero convertida (poniendo el bit menos significativo de la
dirección origen a "1") en trama de borrado de camino
(desaprendizaje de direcciones). Para devolver la trama, el puente
además la modifica poniendo como dirección destino la dirección MAC
origen que contenía (la dirección del puente de entrada si se
utiliza encapsulado en el puente FastPathUD de entrada) y el puente
pone su propia dirección (HLMAC o identificador local secuencial
asignado con RSTP) para reemplazar la dirección origen de la trama.
El puente envía la trama de borrado por el puerto por el que se
recibió, recorriendo el camino inverso y borrando su dirección
origen de las cachés de los puertos de entrada de los puentes
atravesados. El puente frontera de entrada, al verificar que la
trama de borrado va dirigida a él, establece mediante ARP un nuevo
camino al destino mediante difusión, reconvierte la trama a su
formato original y la reenvía al terminal destino por el nuevo
camino encontrado. En esta implementación, la dirección de destino
de la trama es la del puente frontera, si existe encapsulado, o la
dirección HLMAC del terminal destino, si no existe encapsulado. El
puente frontera, al detectar el bit de desaprendizaje y su dirección
coincidente en prefijo con el terminal destino, intercepta la trama,
la procesa borrando la o las direcciones aprendidas, activa un nuevo
proceso de creación de camino bidireccional al terminal destino y
descarta la trama.
En el protocolo RSTP, en un enlace que pertenece
al árbol de expansión RSTP, el puerto conectado al puente padre
(superior en el árbol de expansión) tiene el rol de designado y el
puerto al puente hijo el rol de puerto raíz. En el caso particular
de que la reconfiguración se produzca por una caída de un enlace que
pertenece al árbol de expansión, deben elegirse nuevo puerto
designado y raíz en los puentes afectados. Se bloquean los puertos
correspondientes, los cuales se habilitan una vez que se ha
completado el acuerdo entre los dos puentes implicados: puerto
designado del puente jerárquicamente superior y puerto raíz del
puente jerárquicamente inferior conectado, dentro del árbol de
expansión jerárquico. Las ramas implicadas borran las UMAC
aprendidas. La reconfiguración, que se difunde a través de la red
por los bits indicadores ("flags") de la BPDU (en los bits
"flags" que indican notificación de cambio de topología:
"Topology Change"), de manera similar a RSTP, produce el
borrado de las direcciones locales en todos los puentes y de sus
cachés de puerto. El borrado de direcciones (mediante "MAC
flush") puede ser total o parcial. Al recibir cada puente la
notificación de cambio de topología, borra las direcciones locales y
bloquea el envió de tramas de usuario hasta que se habilite el árbol
de expansión.
También es posible la reconfiguración de la red
provocada por la calda de un puente con el protocolo FastPathUD. En
este caso, si el puente no es puente hoja, el árbol de expansión lo
atraviesa, por lo que se produce una reconfiguración similar a la
descrita anteriormente, pero afectando a todos los enlaces del
puente.
Adicionalmente, la devolución de las tramas para
el desaprendizaje puede incluir encapsulado en los puentes
frontera.
La reconfiguración de la red está controlada de
forma indirecta por el protocolo de árbol rápido de expansión RSTP
[IEEE 802.1D 2004]. Este protocolo se emplea en los puentes
FastPathUD como protocolo auxiliar como base para la asignación de
direcciones locales HLMAC, el instante de validez de las mismas y la
reconfiguración de roles y estados de los puertos. Un puente tiene
una dirección HLMAC válida en el momento en que su puerto raíz
establece el acuerdo de paso a estado de reenvió con el puerto
designado del puente padre. El resto de puertos del puente tendrá el
rol de designado, alternate o back-up. Los puertos
designados repiten a su vez el proceso estándar 802.1D de propuesta
y acuerdo con los puertos raíz de los puentes hijos en el árbol. Así
pues, los puertos raíz y designado de cada puente utilizan el
mecanismo de RSTP para pasar a estado de reenvío.
Los puertos con rol de alternate o
back-up son los que corresponden a los enlaces
redundantes, también llamados enlaces cruzados (que unen ramas
distintas del árbol de expansión o nodos de una misma rama) y son
los normalmente bloqueados por el protocolo de árbol de expansión,
pero que el protocolo FastPathUD permite utilizar respetando las
restricciones de giros arriba/abajo para evitar bucles. Estos
puertos pasan a estado de reenvío (forwarding) mediante un proceso
similar al de RSTP, de propuesta y acuerdo con el puerto conectado
al otro extremo del enlace mediante los bits de propuesta y
asentimiento de la BPDU de RSTP. Pero para que el acuerdo de paso de
estado a reenvío se establezca, ambos puentes deben tener una
dirección HLMAC válida y haber completado su reconfiguración, es
decir, deben haber alcanzado el estado de reenvío todos sus puertos
designados y además haber expirado un temporizador configurable del
puente, arrancado al completar todos los puertos designados su paso
a reenvío. Esta temporización asegura la estabilidad de las
direcciones HLMAC en toda la red cuando los puertos de los enlaces
cruzados (con roles Alternate y Back-UP) se
habilitan.
En caso de fallo de un enlace perteneciente al
árbol de expansión, el puerto raíz del puente hijo pierde su rol de
raíz y dicho puente selecciona como nuevo puerto raíz el puerto que
recibe una mejor BPDU de todos ellos. El paso a reenvío de dicho
puerto raíz valida la asignación de la nueva HLMAC al puente hijo
recién conectado al nuevo puente padre. Los puertos designados
transmiten su nueva dirección HLMAC hacia abajo. Toda la rama del
árbol dependiente del puente hijo modifica su dirección HLMAC con
arreglo al nuevo prefijo HLMAC del puente hijo.
En caso de fallo de un enlace no perteneciente
al árbol de expansión (enlace cruzado), los dos puertos conectados a
dicho enlace pasan todas las conexiones y direcciones aprendidas a
estado de dirección inalcanzable y los respectivos puentes, cuando
reciben paquetes destinados a esas direcciones inalcanzables,
devuelven en forma de paquete de desaprendizaje NACK(destino)
cada paquete recibido con destino un terminal o puente anteriormente
aprendido como alcanzable a través de el puerto en fallo. Cuando
llega al puente una trama de datos unidestino ("unicast") con
origen S y destino D con una dirección inalcanble, el puente
responde enviando hacia atrás un paquete NACK(D) dirigido al
nodo frontera (o terminal origen caso de no usarse encapsulado)
indicando al puente precedente la indisponibilidad de camino hacia
el destino D. Este puente al recibir el paquete NACK(D) pone
en inalcanzable la dirección D y reenvía hacia atrás el paquete
NACK(D) hasta llegar al puente frontera origen, el cual
establece un nuevo camino al destino D mediante un paquete "ARP
Request".
El protocolo aquí descrito permite extender y
modificar el protocolo estándar 802.1D aumentando su rendimiento
hasta acercarlo al de un protocolo de caminos mínimos. Además,
FastPathUD continúa utilizando el protocolo estándar ARP para la
resolución de la dirección IP a la dirección MAC, sea ésta universal
(UMAC), local o local y jerárquica (HLMAC).
Según el uso de las direcciones para establecer
los caminos por el protocolo FastPathUD, existen diversos modos de
operación alternativos que se describen a continuación.
En este modo de operación las tramas Ethernet
enviadas por los terminales con direcciones UMAC no son modificadas
por los puentes frontera.
La estación o el terminal ("host") origen S
envía un paquete ARP (u otro de funcionalidad similar conteniendo la
IP destino) con dirección de difusión de capa dos (FF:
FF:FF:FF:FF:FF).
El puente frontera designado del terminal
(puente de entrada a la red FastPathUD) recibe el paquete "ARP
Request" y lo retransmite por todos los puertos excepto el de
entrada. El puente aprende la dirección UMAC origen (del "host"
emisor) y la asocia al puerto por el que se recibió, abriendo
también una conexión provisional ligada al par
IPorigen-IPdestino contenidos en el paquete "ARP
Request". Esa conexión IPorigen-IPdestino se
confirma cuando el puente recibe un paquete "ARP Reply" de
contestación del terminal destino por el camino de regreso.
A fin de asegurar la simetría de caminos y
prevenir el casual establecimiento simultáneo de dos caminos, cuando
un puente frontera emite un paquete "ARP Request" por sus
puertos, activa un temporizador durante el cual lo retiene y si
recibe algún paquete "ARP Request" en sentido inverso (es decir
con el mismo par de direcciones IP pero en posiciones contrarias
IPorigen-IPdestino respecto al paquete ARP emitido
por el puente frontera origen, no contesta a fin de evitar el
establecimiento de un camino no simétrico, no coincidente en ambas
direcciones entre origen y destino).
Los puentes intermedios (los que no son puentes
frontera) operan de la misma forma y adicionalmente, si estando la
conexión en estado provisional en un puente intermedio, se recibe un
paquete "ARP Request" que contiene el mismo par de direcciones
como IPorigen-IPdestino (independientemente de que
aparezcan como origen o destino), por igual o distinto puerto, este
paquete se ignora en cuanto a establecer una nueva conexión
provisional.
Entonces, el paquete "ARP Request" se
reenvía por todos los puertos permitidos por la prohibición de giros
arriba/abajo hasta alcanzar los terminales. La conexión provisional
se mantiene un tiempo suficiente para recibir el paquete "ARP
Request" del destino, tiempo que debe ser superior al tiempo de
ida y vuelta esperable de la red en condiciones de alta carga. Al
recibir por uno de sus puertos el paquete unidestino "ARP
Reply" con destino la dirección UMAC origen del "ARP
Request" y correspondiente al par
IP_origen-IP_destino de la conexión provisional, el
puente hace fija la conexión asociando a las tablas de los
respectivos puertos las direcciones UMAC origen y destino, y
borrando la conexión provisional creada.
Si el terminal no envía paquete ARP (por tener
el destino en su tabla ARP (tabla donde el terminal almacena las
identidades, direcciones IP y direcciones MAC de los terminales
destino utilizados recientemente o preconfigurados) o por otra
razón, y el puente frontera no tiene camino conocido al destino, el
puente retiene el paquete unicast, genera y envía un paquete ARP
Request para establecer el camino y, una vez respondido, procede al
reenvío del paquete unicast por el camino creado. Opcionalmente, el
puente puede enviar el paquete por el árbol de expansión de forma
convencional, etiquetándolo con la VLAN correspondiente.
En esta implementación, el terminal origen
utiliza igualmente direcciones MAC universales, pero las tramas no
son encapsuladas en el puente frontera sino que éste realiza un
reemplazamiento de la MAC universal origen por la HLMAC del puerto
que conecta el terminal al puente frontera. El carácter jerárquico
de las direcciones HLMAC, por el que la dirección HLMAC del puente
de entrada es un prefijo de las direcciones de los terminales
conectados a él, hace posible en este caso el establecimiento y
control de caminos entre los puentes y la agregación de diversas
rutas entre terminales por dichos caminos.
El funcionamiento del establecimiento de camino
mediante tramas o paquetes ARP es el siguiente:
El terminal envía una trama ARP (u otra de
funcionalidad similar conteniendo IP destino) con dirección de
difusión (FF:FF:FF:FF:FF:FF). El puente frontera o designado (puente
de entrada a la red FastPathUD) recibe el paquete ARP, reemplaza la
UMAC del campo origen en la trama Ethernet por la dirección HLMAC
del terminal (que simplemente es igual a la dirección HLMAC del
puente frontera extendida con el numero de puerto que une el puente
al terminal), recalcula el código de comprobación y lo retransmite
por todos los puertos excepto el de entrada. El puente aprende la
dirección UMAC y la asocia al puerto por el que se recibió y por
tanto a la HLMAC asignada al terminal. El puente crea una conexión
(unión de dos terminales origen y destino) provisional identificada
por el par IPorigen-IPdestino contenidos en el
paquete ARP, conexión que se confirma al recibir el paquete "ARP
Reply" de contestación del terminal destino por el camino de
regreso, el cual debe utilizar exactamente los mismos enlaces que el
camino de ida, de origen a destino. Dicha conexión solamente se crea
si no estuviera creada antes, como se indica más abajo.
El puente reenvía el paquete de difusión ARP,
modificado con la dirección UMAC del terminal origen sustituida por
la dirección HLMAC, por todos sus puertos excepto el de entrada y
los que implican un giro prohibido. Cada puente que recibe el
paquete ARP abre igualmente una conexión provisional ligada al par
IPorigen-IPdestino. Si estando la conexión en estado
provisional se recibe un ARP con par
IPorigen-IPdestino idéntico o inverso (origen y
destino IP intercambiados), por el mismo o distinto puerto que la
conexión existente, este paquete se ignora en cuanto a establecer
una nueva conexión provisional y se reenvía, si no es un paquete
detectado como duplicado, por todos los puertos permitidos por la
prohibición de giros arriba/abajo. La conexión provisional se
mantiene un tiempo suficiente para que se reciba en operación normal
de la red el paquete "ARP Reply" del destino, tiempo superior a
dos veces el tiempo de ida y vuelta máximo de caso peor. Al recibir
por uno de los puertos el paquete ARP Reply unidestino conteniendo
como dirección destino la dirección MAC origen del ARP Request y
correspondiente al par IPorigen-IPdestino de la
conexión provisional establecida, el puente hace fija la conexión
asociando a las tablas de los respectivos puertos las direcciones
MAC origen y MAC destino, y borrando la conexión provisional creada.
Esta conexión bidireccional requiere ser renovada periódicamente en
cada sentido por el tráfico con origen y destino ambos terminales de
la. conexión. La renovación puede operar como en los puentes 802.1D
en que la dirección MAC origen renueva la caché de direcciones del
puerto donde se recibe, o de forma bidireccional, en la que la
dirección destino de los paquetes de datos unicast también actúan
renovando los temporizadores de las cachés correspondientes a los
puertos origen (lo que se denomina renovación hacia delante).
Si el terminal no envía ningún paquete ARP (por
tener el destino en su tabla ARP o por otra razón), el puente
frontera recibe un paquete para cuya MAC destino no dispone de
puerto de salida (ruta) conocido. En este caso el puente frontera
construye y envía un paquete de petición de establecimiento previo
para establecer el camino.
Cada puente frontera puede establecer caminos
con todos los demás puentes al inicializarse o solamente cuando
tiene algún terminal activo conectado. El procedimiento de
establecimiento de caminos por defecto es el descrito más arriba que
está basado en los paquetes ARP enviados por el terminal.
El puente puede alternativamente y de forma
autónoma enviar un paquete de establecimiento de camino con
dirección origen su dirección HLMAC y con dirección de destino la
dirección multidestino o "multicast" que engloba todos los
puentes FastPathUD.
El tipo de paquete puede ser el de "petición
de establecimiento total de caminos". Cada puente FastPathUD que
recibe dicho paquete establece una conexión provisional con dicho
puente frontera vinculada al puerto por donde primero recibió dicho
paquete de establecimiento de camino. El puente aprende la dirección
HLMAC origen de la trama recibida (la del puente frontera origen) y
la asocia al puerto por el que se recibió. El puente crea una
conexión (unión de dos puentes frontera origen y destino)
provisional unidireccional identificada por la HLMAC del puente
frontera origen del paquete de petición de establecimiento de
conexión (COMPLETE_CONNECT_REQUEST), conexión que confirma cada
puente frontera destino de forma individual: cada puente que recibe
dicho paquete de petición de conexión genera un paquete de
confirmación de camino parcial (PARTIAL_CONNECT_CONFIRM) con
dirección origen la HLMAC del puente intermedio alcanzado y con
dirección destino la HLMAC del puente frontera origen. Este paquete
(PARTIAL_CONNECT_CONFIRM) indica al puente frontera origen la
progresión del establecimiento de la conexión provisional y confirma
el camino en sentido contrario salto a salto asociando la dirección
HLMAC del puente alcanzado al puerto de cada puente atravesado por
el paquete de confirmación hacia el puente frontera origen. Al
llegar la petición de conexión a cada uno de los puentes frontera de
la red, cada uno de ellos genera un paquete de confirmación de
conexión (CONNECT_CONFIRM) con dirección origen su dirección HLMAC y
dirección destino la del puente frontera origen del paquete de
petición recibido, y lo envía por el mismo puerto asociado al
paquete de petición recibido. Al recibir este paquete hacia atrás,
se aprende en los puentes la dirección HLMAC del puente frontera
destino, confirmándose la conexión provisional establecida en todos
puentes.
En cualquiera de las posibles implementaciones,
para que el aprendizaje de direcciones MAC funcione es preciso que
los caminos FastPathUD establecidos entre puentes frontera en la red
sean exactamente simétricos y atraviesen los mismos enlaces en
sentido de ida y de vuelta. El mecanismo opcional de establecimiento
confirmado paso a paso descrito más arriba contribuye a dicho fin.
Los puentes frontera utilizan mecanismos adicionales para el control
de la simetría de los caminos establecidos. Al recibir un paquete
CONNECTION_CONFIRM por un puerto, asocian de forma permanente dicho
puerto al puente frontera destino. Para confirmar la disponibilidad
del camino, cada puente frontera envía periódicamente paquetes de
refresco y verificación PATH_REFRESH con destino cada uno de los
puentes frontera destino. Estos paquetes mantienen activos los
caminos y permiten la comprobación de su disponibilidad a los
puentes. Cada puente frontera emisor espera recibir paquetes de
REFRESH_CONFIRM de cada puente destino marcando y confirmando en
cada puente atravesado el camino contrario. El puente frontera
emisor verifica que el puerto receptor del paquete de confirmación
REFRESH_CONFIRM es el mismo puerto por el que se envió el paquete
PATH_REFRESH. Cada puente atravesado verifica igualmente que los
puertos receptor y transmisor para esos destinos concuerdan con los
del camino establecido. Si difieren, la conexión se borra y se
devuelve un paquete de REFRESH_REJECT hacia el origen para notificar
la invalidez y el borrado de la conexión y provocar el
establecimiento de una nueva conexión.
Cuando se emplea la confirmación opcional del
camino en cada puente, al establecer un camino a un puente frontera
se establecen los caminos a los puentes intermedios. Cada puente
anota dichos caminos de forma que no es preciso establecerlo de
nuevo.
Las principales diferencias del protocolo de
encaminamiento FastPathUD con respecto al encaminamiento
"jerárquico" que existe en UETS son:
- El encaminamiento en UETS se basa en la
decodificación progresiva de las direcciones jerárquicas locales
Ethernet asignadas con arreglo a la topología de la red. En
FastPathUD, el direccionamiento está basado en árbol y no en la
topología, la cual solamente se emplea para la prohibición de giros
en la prevención de bucles.
- Las direcciones en UETS están biunívocamente
ligadas al encaminamiento etapa a etapa y el encaminamiento es
determinado por el direccionamiento asignado. En FastPathUD, el
encaminamiento se basa en el aprendizaje por los puentes (en el
plano de datos) de los caminos mínimos dentro de los permitidos,
establecidos mediante inundación restringida por prohibición de
giros Up/Down.
\vskip1.000000\baselineskip
A continuación se resumen características,
ventajas e inconvenientes de las distintas variantes de la invención
descritas anteriormente, usando o no encapsulado en el
encaminamiento de las tramas. En todos los casos se supone desvío de
las tramas con dirección unidestino ("unicast") desconocida por
el árbol de expansión y que las tramas llevan la etiqueta VLAN T
("VLAN Tree") correspondiente al árbol.
a) Encaminamiento sin encapsulado y empleando
UMACs en los terminales: El encaminamiento de direcciones unicast
desconocidas por el árbol de expansión utiliza difusión sin
aprendizaje. Los puentes usan HLMACs para aplicar control de giros
arriba/abajo, pero no es posible encaminar mediante la HLMAC porque
la trama solo lleva la UMAC.
b) Encaminamiento con encapsulado HLMAC y
empleando UMACs en los terminales: En esta variante si es posible el
encaminamiento por el árbol vía HLMACs. Las principales ventajas
son: menor número de direcciones MACs a aprender en cada puente
(factor 10-100), es posible un encaminamiento
proactivo realizado por los puentes más controlado y robusto, y
evita la difusión innecesaria de tramas por el árbol.
c) Encaminamiento con encapsulado ULMAC y
empleando UMACs en los terminales: Requiere mecanismo de direcciones
Up/Down y un proceso adicional de reconfiguración.
d) Encaminamiento con sustitución de direcciones
MAC por direcciones HLMAC (proceso "NAT", en inglés) y
empleando UMACs en los terminales: La HLMAC contiene dirección de
puente (prefijo) y de terminal (sufijo, número del puerto). Es
posible el encaminamiento por el árbol sin difusión usando la HLMAC.
Es un encaminamiento proactivo establecido por los puentes. Las
ventajas son que precisa menor número de direcciones MAC a aprender
y sólo requiere aprender el prefijo del puente en vez de los de los
terminales. Son necesarios mecanismos de control de consistencia de
las cachés ARP en los terminales.
Resumidamente, otras ventajas de la invención
sobre el estado de la técnica anterior son:
- Frente a los protocolos que encaminan tramas,
permite agregar rutas entre los puentes frontera mediante el
direccionamiento jerárquico.
- Frente a los protocolos operan en el plano de
control como LSOM ("Link State Over MAC") y otros como HURP que
asignan direcciones locales jerárquicas (HLMAC), no requiere
intercambio periódico de rutas entre puentes, operando de forma
transparente mediante aprendizaje hacia atrás sobre las tramas de
datos.
- Frente a los protocolos no compatibles con el
formato de trama Ethernet, el protocolo es compatible.
- Frente a los protocolos que utilizan
encapsulado adicional de la trama para el reenvío, el encapsulado
(tunnelling) de la trama no es imprescindible realizarlo para la
difusión en una red campus de conmutadores.
- Frente al estándar 802.1D, permite el uso de
toda la infraestructura de red sin bloquear enlaces transversales
redundantes, limitando solamente algunos giros en los
conmutadores.
- Frente a MSTP y la propuesta IEEE en el 2005
denominada "Shortest Path Bridging"
(http://www.ieee802.org/
802_tutorials/july05/nfinn-shortest-path-bridging.pdf), el protocolo no requiere procedimiento alguno en el plano de control para los caminos transversales aparte de la asignación de direcciones, ni requiere la construcción de árboles múltiples de expansión, ni intercambio de rutas entre conmutadores.
802_tutorials/july05/nfinn-shortest-path-bridging.pdf), el protocolo no requiere procedimiento alguno en el plano de control para los caminos transversales aparte de la asignación de direcciones, ni requiere la construcción de árboles múltiples de expansión, ni intercambio de rutas entre conmutadores.
- Al igual que en el encaminamiento
arriba-abajo, los caminos son cercanos en promedio
al retardo mínimo obtenido por encaminadores de camino mínimo,
porque la fracción de giros prohibidos respecto al total de giros
posibles en la topología es pequeña.
- Alta escalabilidad sin obligatoriedad de
encapsulado adicional.
- Mantenimiento de los mecanismos estándar de
difusión ("broadcast") y multidifusión ("multicast")
802.1D en capa dos de OSI.
- Compatibilidad con los protocolos estándar ARP
y DHCP y con los equipos terminales (PC) y servidores actuales
(Windows en todas sus versiones y Linux) sin necesidad de cambios
software ni hardware.
\vskip1.000000\baselineskip
Otro aspecto de la invención se refiere a un
dispositivo de interconexión de subredes, más concretamente, un
puente de red ("bridge"), aquí bautizado como puente
FastPathUD, que opera en el nivel de enlace de datos (capa 2) según
el protocolo de red que crea el árbol de expansión utilizado para
asignar a los puentes direcciones ordenadas. Este dispositivo
constituye un puente de red que es autoconfigurable y se basa en el
funcionamiento de sus puertos en al menos dos modos, simultánea o
alternativamente: en modo estándar como puente convencional (802.1D)
y en modo jerárquico operando mediante el protocolo FastPath.
\newpage
Un aspecto más de la invención se refiere a una
red conmutada con uno o más dispositivos de interconexión de
subredes que constituyen los puentes de red FastPathUD propuestos y
a la que se puede añadir al menos un puente de red convencional que
opera exclusivamente según el protocolo estándar 802.1D.
Para complementar la descripción que se está
realizando y con objeto de ayudar a una mejor comprensión de las
características del invento, de acuerdo con un ejemplo preferente de
realización práctica del mismo, se acompaña como parte integrante de
esta descripción, un juego de dibujos en donde con carácter
ilustrativo y no limitativo, se ha representado lo siguiente:
La figura 1.- Muestra un diagrama de bloques con
los procesos principales del procedimiento de encaminamiento, según
una realización preferida de la invención.
La figura 2.- Muestra una representación
esquemática en árbol de una red de telecomunicaciones, donde los
nodos del árbol representan puentes de red y los enlaces de conexión
entre nodos representan los posibles caminos establecidos.
La figura 3.- Muestra el formato de una trama
BPDU del protocolo de árbol de expansión rápido, conocido en el
estado de la técnica.
La figura 4.- Muestra el formato de una trama
BPDU usada por el protocolo de creación y mantenimiento del árbol de
expansión, según una posible realización.
La figura 5.- Muestra un ejemplo de asignación
de direcciones en el árbol de expansión creado según una realización
preferida de la invención usando direcciones locales
jerárquicas.
La figura 6.- Muestra una representación
esquemática de una red de puentes y del encaminamiento de tramas, de
acuerdo al objeto de la invención, para obtener los caminos entre
estaciones terminales.
La figura 7.- Muestra un diagrama de bloques del
proceso de reenvió de tramas implementado por un puente de red según
una realización preferida de la invención.
La figura 8.- Muestra el proceso para el
establecimiento de camino bidireccional que usa encapsulado con
direcciones locales jerárquicas, según una posible realización de
la invención.
La figura 9.- Muestra el proceso para el
establecimiento de camino bidireccional sin utilizar encapsulado y
que sustituye en los puentes frontera direcciones universales por
locales, según otra posible realización de la invención.
La figura 10.- Muestra el proceso para el
establecimiento de camino bidireccional sin utilizar encapsulado y
usando direcciones universales, según otra posible realización de la
invención.
La figura 11.- Muestra el proceso de
desaprendizaje de direcciones.
La figura 12.- Muestra el proceso de desvío y
difusión por el árbol de expansión estándar, de tramas con dirección
destino desconocida en un puente intermedio, según una posible
realización de la invención.
La figura 13.- Muestra el proceso de
encaminamiento de tramas con dirección destino caducada en los
puentes intermedios, usando reenvío por el árbol en los respectivos
sentidos de ida y vuelta del camino bidireccional y decodificando
direcciones HLMAC, según una posible realización de la
invención.
La figura 14.- Muestra el proceso de
encaminamiento de tramas con dirección destino caducada en los
puentes intermedios, usando reenvío por el árbol en el sentido de
vuelta del camino bidireccional y sin aprendizaje en los puentes
intermedios, según otra posible realización de la invención.
Puede describirse una realización preferida de
la invención como un protocolo de red del nivel de enlace de datos o
capa dos, que se ejecuta dentro de una red de telecomunicaciones,
como puede ser una red campus, en cada uno de los puentes de red y
que lleva a cabo los procesos indicados en la Figura 1:
- (1)
- proceso o protocolo de construcción y mantenimiento del árbol de expansión;
- (2)
- protocolo de asignación de direcciones a puentes según distancia a puente raíz, descubrimiento de vecinos y obtención de giros prohibidos;
- (3)
- procesos de establecimiento de caminos y de reenvío de tramas.
\vskip1.000000\baselineskip
Dentro de los procesos de establecimiento de
caminos, se distinguen los caminos por árbol de expansión y caminos
FastpathUD -caminos más rápidos que los anteriores-.
Todos estos procesos (1, 2, 3) se ejecutan para
realizar el encaminamiento de tramas según el procedimiento objeto
de la invención, que aquí se ha llamado FastPathUD, denominando a
los puentes de red donde se ejecutan los procesos de este
procedimiento puentes FastPathUD.
FastPathUD es aplicable a una red de
telecomunicaciones, que puede representarse mediante un árbol o
grafo, como el ejemplo mostrado en la Figura 2, donde todos los
nodos, dibujados como círculos, corresponden a puentes de red
FastPathUD. Al final del árbol se dibujan terminales o "hosts"
conectados a respectivos puentes frontera. Junto a los nodos
aparecen las direcciones locales jerárquicas HLMAC, como ejemplo,
asignadas a los puentes. En la Figura 2 se representan con trazo
grueso los enlaces del árbol de expansión obtenidos mediante la
ejecución del protocolo de creación y mantenimiento del árbol (1),
de acuerdo a una posible realización de la invención. Junto a los
trazos que representan enlaces de un nodo, se indican también como
ejemplo, usando números en cursiva, algunos identificadores de
puertos designados en el nodo.
La interconexión compatible de los puentes
FastPathUD con los puentes 802.1D puede realizarse como se describe
en ["Abridges: Scalable, self-configuring Ethernet
campus networks", Ibáñez, G. A., Computer Networks, vol. 52,
issue 3, pp. 630-649, 2008]. Así, en la conexión
entre los diferentes tipos de puentes se emplean mecanismos de
autoconfiguración que construyen un núcleo de puentes FAstPathUD a
cuyos extremos se conectan árboles de expansión estándar formados
por los puentes 802.1D, unidos a los puentes FastPathUD frontera que
actúan como puentes raíz de los árboles de expansión
respectivos.
Según una posible opción de realización, el
protocolo de encaminamiento FastPathUD hace uso del encaminamiento
arriba-abajo basándose en las direcciones HLMAC
asignadas a los puentes de red. En este caso, conceptualmente, un
puente FastpathUD puede verse como un encaminador de tramas con
direcciones Ethernet locales jerárquicas que además puede incorporar
la funcionalidad estándar de un puente convencional.
En la red ejemplo de la Figura 2, se muestran
una serie de puentes FastpathUD de la que es elegido un puente raíz
R suponiendo que, por configuración de la prioridad de los puentes,
el puente R es el que posee un menor prefijo o número de identidad
del puente de toda la serie.
A partir de dicho puente raíz R se construyen,
según se muestra en la Figura 2:
- el árbol de expansión estándar 802.1D, formado
por los nodos conectados por enlaces representados con línea
fina;
- el árbol de expansión creado mediante el
protocolo (1), con los enlaces en trazo grueso, donde se ejecuta el
proceso de asignación de direcciones a puentes (2) asignando a los
nodos direcciones locales por orden en base a la distancia al puente
raíz R; en el ejemplo de la Figura 2, las direcciones locales son
jerárquicas HLMAC.
\vskip1.000000\baselineskip
El mecanismo de asignación jerárquica de
direcciones aprovecha la construcción del árbol de expansión
estándar por STP ó RSTP. La Figura 3 ilustra el formato de una BPDU
estándar del protocolo de árbol de expansión RSTP. La Figura 4
ilustra su extensión, incorporando tras el último octeto de la BPDU
estándar seis octetos más, octetos 36-41, para
incluir la dirección local HLMAC del nodo que lo identifica en su
conexión con un nodo vecino a través de un puerto designado.
Las BPDUs usadas por el protocolo FastPathUD son
enviadas por cada puente FastPathUD a uno o varios de sus puentes
vecinos. Tienen una dirección destino multicast específica que
identifica a los puentes FastPathUD. Dichas BPDUs son procesadas por
cada puente FastPathUD y reenviadas. Dentro de la BPDU del protocolo
FastPathUD puede incluirse la dirección del puente de destino final
de la misma BPDU, en cuyo caso cada puente protocolo FastPathUD
inspecciona la trama, ejecutando la acción que proceda, como borrar
las conexiones afectadas por un fallo, y a continuación la reenvía
al puente vecino por el puerto por donde ha sido aprendido el puente
de destino final.
En esta red, los puentes FastPAthUD pueden
emplear todos los enlaces que les interconectan para encaminar
tramas, siempre que el giro correspondiente no sea prohibido.
Los puentes FastpathUD manejan el formato de
trama Ethernet estándar, sin necesitar encapsulado, dentro de la
cual los campos de dirección MAC destino y dirección MAC origen son
conforme al estándar 802.1D, estando definido cada campo por 48 bits
agrupados en 6 octetos.
La Figura 5 ilustra un ejemplo de asignación de
direcciones HLMAC a los puentes FastpathUD, utilizando una
configuración por defecto de 8 bits de máscara por cada nivel del
árbol de expansión a partir del segundo nivel y asumiendo que el
puente raíz R del árbol de expansión tiene dos puertos designados a
dos respectivos vecinos (C1, D1) cuyos identificadores/prefijos son
respectivamente 5 y 32, por ejemplo. Los identificadores de los
puertos de cada puente se representan en la Figura 5 en binario con
4 bits. El puente vecino D2 conectado al puente D1 por el puerto
0111 recibe una BPDU con dirección MAC local de valor 32.7 y
conteniendo además toda la información del protocolo STP/RSTP. Con
esta información asigna la dirección a sus puertos designados
respectivos, el puerto 0110 al puente D3 a través del que envía una
BPDU con dirección 32.7.6 y el puerto 0001 al puente D5 a través del
que envía una BPDU con dirección 32.7.1, habiendo añadido al final
en las respectivas BPDUs la identidad del puerto designado. La
anchura de la máscara en bits puede depender del nivel del puente en
el árbol de expansión. Los puentes D4 y D5 están conectados por sus
respectivos puertos, con identificadores 0001 y 0110 en el ejemplo,
a unos equipos terminales, T1 y T2, los cuales a su vez reciben
finalmente las BPDUS con direcciones 32.7.6.5.1 y 32.7.1.6
respectivamente. El puente C1 es un puente hoja que se conecta
directamente a dos equipos terminales, T3 y T4, a través de los
puertos designados, en el ejemplo, 0110 y 0001. El equipo terminal
T3 recibe una BPDU con dirección local 5.6 y el equipo terminal T4
recibe otra BPDU con dirección local 5.1, en correspondencia con los
prefijos de dichos puertos designados.
Cuando los puertos terminales de un puente
FastpathUD están conectados a un solo equipo terminal, el puerto
terminal designado puede realizar opcionalmente la sustitución de la
dirección MAC universal origen en las tramas entrantes, tramas de
datos que puede enviar el equipo terminal al puente, por la
dirección MAC local jerárquica del puerto designado o de entrada.
Este proceso de sustitución de direcciones MAC se denomina de forma
abreviada en inglés "NAT" de MACs. En las tramas de vuelta
hacia el equipo terminal se realiza la sustitución inversa,
reinsertando la dirección MAC universal asignada universalmente al
equipo terminal. El protocolo ARP se utiliza para la resolución de
la dirección IP a la dirección MAC de forma totalmente compatible,
sea ésta universal o local jerárquica.
Los puentes frontera pueden utilizar direcciones
MAC universales, UMAC, en lugar de direcciones MAC locales o HLMAC.
El proceso de establecimiento de caminos es idéntico al descrito
para las direcciones HLMAC, excepto en que se utiliza un mecanismo
de asignación secuencial de identificadores a los puentes según su
distancia creciente al puente raíz R en el árbol de expansión y de
reasignación de direcciones en caso de reconfiguración del árbol de
expansión. Estos identificadores se utilizan por cada nodo para
determinar los giros prohibidos y permitidos a través de él mediante
el encaminamiento arriba/abajo.
La Figura 6 muestra un ejemplo de red de puentes
transparentes FastpathUD y el encaminamiento de tramas usando los
caminos FastpathUD de la red entre estaciones. Los enlaces
transversales se representan con línea fina y los pertenecientes al
árbol de expansión que asigna las direcciones locales se representan
con línea gruesa, los giros prohibidos en la difusión de tramas
están indicados mediante un arco punteado entre enlaces, los
símbolos de flecha y cruz indican las tramas descartadas por llegar
duplicadas al puente -caminos menos rápidos-, las flechas doble
indican las tramas que recorren los caminos obtenidos por el
protocolo FastPathUD -caminos más rápidos-, y cada círculo negro
muestra un puerto aprendido capturado mediante el proceso de
aprendizaje de los puertos asociados a la dirección de la estación
origen de las tramas.
En el ejemplo de la Figura 6, la estación
terminal S de dirección jerárquica 1.18.43.67.110.0 asignada según
distancia al puente raíz, envía una trama ARP de difusión a toda la
red. El puente 1.18.43.67.0 la recibe, anota la dirección y la
asocia a la identidad del puerto de entrada y bloquea el registro
que los vincula, arrancando un temporizador de bloqueo y un
temporizador de caducidad de la dirección aprendida. Reenvía la
trama a los puentes conectados a él. La Figura 6 representa que el
puente 2.15.9.0.0.0 recibe la trama desde 1.18.43.67 antes que desde
2.15.0.0.0.0 por lo que la dirección de la estación se asocia al
puerto marcado con un círculo negro en la figura y se bloquea la
actualización de dicha entrada durante un intervalo de guarda. El
puente 2.15.9.0.0.0 entrega la trama a la estación D. Otros puentes,
como el 2.34.0.0.0., entregan la trama a otros terminales como el N
y M, que igualmente la procesan comprobando si va destinada a ellos.
Solamente el terminal D envía una trama de respuesta, ARP reply, con
dirección MAC destino la de el terminal S. El puente 2.15.9.0.0.0
recibe la trama y registra la asociación de la dirección de D al
puerto de entrada, indicado por un circulo blanco Por otra parte,
tiene aprendida la dirección como asociada al puerto marcado con el
círculo negro y lo reenvía por dicho puerto, estableciendo el camino
simétrico de vuelta por donde se aprendió la dirección en el camino
de ida.
La Figura 7 muestra un diagrama de bloques del
proceso de reenvío de tramas que ejecuta el puente FastpahtUD y
sigue estos pasos:
Simultáneamente a la recepción S1 de las tramas,
se consulta el estado del puerto origen P1 y el del puerto destino
P2 para ejecutar la topología activa S2, y a continuación se realiza
un filtrado de tramas S3 de acuerdo a los datos de la caché DB2 que
implementa el bloqueo del aprendizaje de la dirección origen de
trama. Tras el filtrado de tramas S3, éstas pasan a distintas colas,
en un paso de encolado de tramas S4 que tiene en cuenta el estado
del puerto origen P1 y el del puerto destino P2. De las colas de
tramas se seleccionan las tramas a transmitir S5. El bloque S6 se
ocupa del control de giros prohibidos impidiendo el reenvío por
enlaces que supongan giros prohibidos. Antes de efectuar la
transmisión S8 de esas tramas, se hace una comprobación de dichas
tramas para detectar errores S7, recalculando el campo FCS: "Frame
Check Sequence".
Las tramas que se envían por el árbol de
expansión mediante RSTP para el reenvío llevan una etiqueta "VLAN
T" como identificación de VLAN, mientras que las tramas que usan
los caminos FastpathUD van etiquetadas mediante una identificación
de VLAN "VLAN F". También puede haber tramas sin etiqueta
VLAN.
Las Figuras 8 (a) a (h) ilustran los sucesivos
pasos del proceso de establecimiento de camino bidireccional o
simétrico con un ejemplo que usa direcciones HLMAC.
En la Figura 8 (a), una estación terminal origen
S envía una trama Ethernet, que no requiere encapsulado, con una
dirección MAC origen la dirección MAC universal de la estación S y
con una dirección MAC destino la dirección MAC de difusión; en el
ejemplo, la dirección UMAC origen de la estación S es
00:07:e9:24:cb:c8 y la de la estación D destino es
00:09:12:21:a1:b3. El puente frontera origen, con la HLMAC
1.18.43.67.110.0 no conoce la UMAC de la estación S hasta que no
llega la trama t1, que recibe sin encapsulado, como se representa en
la Figura 8 (a) con la flecha de línea fina. La trama t1 contiene la
dirección de difusión de capa dos FF:FF:FF:FF:FF:FF.
Una vez recibida la trama anterior en el puente
frontera origen 1.18.43.67.110.0 por el puerto 110, el puente
frontera la encapsula en una trama t2 con dirección origen
1.18.43.67.0.0 y aprende la UMAC 00:07:e9:24:cb:c8 de la estación S
en el puerto 110 designado. La trama t2 con el encapsulado HLMAC se
envía, como se representa en la Figura 8 (b) con la flecha de línea
doble, por los caminos establecidos; en el ejemplo un único enlace
del árbol de expansión al siguiente puente 1.18.43.67.0.0.
En las Figuras 8 (c) y (d), se representa con la
flecha de línea doble la transmisión de la trama encapsulada t2
hasta alcanzar, por los caminos rápidos, la estación D destino,
mientras que la flecha de línea punteada indica el envío de las
tramas de establecimiento del camino inverso simétrico y la flecha
con el aspa corresponde al descarte de tramas en los caminos menos
rápidos.
Con ello en la Figura 8 (e) quedan establecidos
los caminos simétricos entre puentes vecinos (enlaces dibujados con
doble línea), así como el camino simétrico hasta el puente frontera
origen (enlaces dibujados con doble línea gruesa).
La estación D manda su trama Ethernet de
respuesta sin encapsular t3, como ilustra la Figura 8 (e), que es
encapsulada por el puente frontera destino con su HLMAC
2.15.9.0.0.0. La trama Ethernet con el encapsulado HLMAC t4 es
enviada a la dirección HLMAC origen 1.18.43.67.0.0 y de ahí, se
envía la trama t5, a través del camino simétrico hasta el puente
frontera origen, según ilustran las Figuras 8 (f) y (g). Finalmente,
la Figura 8 (h) ilustra la trama de respuesta t3 de la estación D,
correspondiente a una trama "ARP reply", que llega a la
estación S.
El procedimiento mostrado en las Figuras 8 (a) y
(h), con respuesta de cada puente atravesado, es opcional -costosos
en mensajes-, aunque especialmente adecuado para establecer caminos
entre todos los puentes.
Otra posible implementación del establecimiento
de caminos es sin utilizar encapsulado y empleando sustitución de
direcciones MAC universales por locales en los puentes frontera,
según muestran los sucesivos pasos ilustrados en las Figuras 9 (a) a
(h). En esta implementación, la estación origen S comienza el envío
de la trama t1 utilizando su UMAC, 00:07:e9:24:cb:c8 en el ejemplo
de la Figura 9 (a), la cual es sustituida en el puente frontera
origen por la HLMAC, 1.18.43.67.110.0 en la Figura 9 (b), que lleva
la trama t6 hasta la estación destino D, siguiendo el mismo camino
mostrado en las Figuras 9 (c) y (d). Las flechas discontinuas
muestran el asentimiento opcional de caminos de los puentes
intermedios. La estación destino D usa igualmente su UMAC,
00:09:12:21:a1:b3 en la Figura 9 (e), para la trama de respuesta t7,
que tampoco es encapsulada en su puente frontera, como muestra las
Figura 9 (f), sino que se envía como una trama de respuesta t8,
reemplazando la UMAC por la HLMAC del puerto que conecta la estación
D al puente frontera destino. La trama t8 sigue el camino inverso,
como muestran las Figuras 9 (g) y (h), hasta la estación S, que
recibe la respuesta tal cual, sin encapsulado y con las direcciones
HLMAC.
Las Figuras 10 (a) a (i) ilustran otra posible
implementación del establecimiento de caminos también sin utilizar
encapsulado y empleando las direcciones MAC universales. La estación
origen S en la Figura 10 (a) envía una trama t1 con dirección UMAC
origen 00:07:e9:24:cb:c8 y dirección UMAC destino la
00:09:12:21:a1:b3 de la estación destino D. El puente frontera
1.18.43.67 no conocía la dirección UMAC 00:07:e9:24:cb:c8 de la
estación origen S conectada a él, luego es un puente con conexión
FastpathUD sin confirmar. Los puentes con conexión FastpathUD
provisional están representados en las Figuras 10 (a)-(i) como
círculos simples, mientras que los puentes con conexión FastpathUD
confirmada se representan con círculos dobles.
En la Figura 10 (b) el puente 1.18.43.67.110
recibe la trama t1 y aprende la dirección UMAC de la estación origen
S en el puerto 110, a la vez que inicia el temporizador de captura
de esa dirección UMAC origen y reenvía la trama t1 mediante difusión
FastpathUD por todos los enlaces que no suponen giro prohibido. El
puente siguiente en el árbol hace lo mismo que el anterior, como
indica la Figura 10 (c): se inicia temporizador de captura de la
dirección UMAC origen en el puerto del puente por el que se ha
recibido y se reenvía a todos los puentes con giro permitido,
repitiéndose el proceso en cada puente del camino hasta llegar a la
estación destino D. En la Figura 10 (d) la trama t1 de la estación
origen S alcanza la destino D.
La estación destino D responde a la trama t1 con
un ARP Reply que es una trama unicast t3, con dirección destino la
UMAC de la estación S. Como muestra la Figura 10 (e), la trama t3
llega al puente 2.15.9.0.0.0, que aprende la dirección UMAC de la
estación D y confirma la captura de la dirección UMAC de S pendiente
-conexión Fastpath confirmada-. En la Figura 10 (f), el puente
2.15.9.0.0.0 con la conexión confirmada reenvía la trama t3 por el
puerto aprendido o asociado a la dirección UMAC de la estación S
hacia el puente 1.18.43.67.0.0, que al recibirla confirma también su
captura de la dirección de la estación S, aprende el camino
establecido y lo confirma a la estación D. Los mismos procesos se
repiten en el siguiente puente 1.18.43.67.110, que ya es el
conectado a la estación S, como muestra la Figura 10 (g). La trama
t3 recibida en 1.18.43.67 es desetiquetada de la "VLAN F" y
reenviada a la estación S, según se muestra en la Figura 10 (h). Por
último, los temporizadores de captura de los puentes que no han
recibido la contestación unicast vencen -puentes representados en la
Figura 10 (i) como círculos simples y en gris- y, por tanto, las
conexiones FastpathUD provisionales hacia la estación S se borran.
Los círculos dobles indican aquí conexión confirmada -por unicast de
vuelta-.
La Figura 11 muestra la reconfiguración de la
red en caso de fallo de un enlace, por ejemplo, un enlace trasversal
o cruzado, no perteneciente al árbol de expansión, como es el caso
de la Figura 10. La caída del enlace entre los puentes 2.15.9.0.0.0
y 3.35.0.0.0.0 es detectada por ambos, que ponen como inalcanzables
las direcciones aprendidas por los puertos conectados al enlace. La
trama de datos DATA (D, S) "unicast" con origen la estación S y
destino D, al llegar por el puerto anteriormente aprendido al puente
2.15.9.0.0.0, encuentra que el puerto de ese puente conectado al
enlace caldo tiene su direcciones aprendida en estado de
"dirección inalcanzable". El puente 2.15.9.0.0.0, al recibir la
trama destinada a una dirección ahora inalcanzable, devuelve una
trama de desaprendizaje NACK(D) indicando el destino D hasta
el origen S, que envía una nueva trama ARP para reconfigurar el
camino a la estación destino D y conectarla a un puerto alcanzable,
por ejemplo el del puente 3.35.0.0.0.
En cualquiera de las implementaciones descritas,
el establecimiento de caminos por los puentes frontera presenta la
ventaja de agregación de rutas (por un factor del orden de hasta
100, según el número de puertos provistos en los puentes frontera) y
un sencillo control de la simetría de caminos.
Las Figuras 12 a 14 ilustran diversas
posibilidades de reenvío de tramas unicast con dirección destino
desconocida por el puente debido a caducidad de la dirección o a
reconfiguración de la red. El nodo pintado con el interior a rayas
representa el puente al que llega una trama unicast con dirección
unidestino desconocida.
En la Figura 12 se ilustra un caso general,
cuando un puente FastpathUD recibe una trama unicast FastpathUD t9
identificada por su VLAN FastpathUD, i.e, con etiqueta "VLAN
F", pero el puente no tiene ningún puerto asociado a esa
dirección, es decir, no hay una conexión o camino FastpathUD
confirmado. La trama pues es reidentificada con la VLAN del árbol de
expansión, i.e., con la etiqueta "VLAN T" y reencaminada por el
árbol de expansión estándar RSTP, como se representa en la Figura 12
mediante flecha doble. La trama se desetiqueta para entregarla a la
estación destino D.
Las tramas sin etiqueta VLAN están representadas
en las Figuras 12 a 14 como flechas punteadas.
El encaminamiento por el árbol de expansión
puede variar según la trama lleve una dirección HLMAC o UMAC.
Cuando se emplean direcciones HLMAC, como en el
ejemplo de las Figuras 13 (a) y 13 (b) que representan el
encaminamiento de la trama en sentido de ida y de vuelta
respectivamente, decodificando las direcciones HLMAC a través del
árbol. La trama t9 puede encaminarse sin necesidad de difusión,
ascendiendo primero por el árbol directamente hasta el puente raíz
R, vía el puerto raíz en todos los puentes, para luego descender por
la rama correspondiente al terminal destino D, como muestra la
Figura 13 (a), simplemente eligiendo en cada puente del tramo
descendente el puerto indicado por la dirección HLMAC. El puente
2.15.1.0.0, que desconoce la dirección HLMAC 2.15.9.12.0.0, por
caducidad de la dirección o por desaprendizaje del puerto asociado a
la misma por reconfiguración, encapsula la trama t9 con etiqueta
"VLAN T" y reenvía por el árbol de expansión.
Si el terminal destino se encuentra en la misma
rama del árbol de expansión que el puente, no es necesario ascender
hasta el puente raíz R; basta recorrer la rama en sentido ascendente
o descendente decodificando la dirección HLMAC destino salto a
salto.
Para el camino de vuelta, mostrado en la Figura
13 (b), el puente frontera 2.15.9.0.0.0 recibe la trama de respuesta
t10 de la estación D dirigida a la estación S y etiqueta la trama
con "VLAN T" antes de enviarla al puente frontera conectado a
la estación S con dirección HLMAC 1.18.43.67.110.0. Como esa
dirección destino no tiene prefijo común con su dirección de puente,
la trama t10 asciende por el árbol, vía los puertos raíz, hasta el
puente raíz R. En el puente raíz R, la dirección HLMAC es
decodificada en cada etapa, eligiendo el primer puerto del sufijo no
coincidente entre dirección HLMAC de puente y dirección HLMAC
destino.
Cuando se emplean direcciones UMAC, se realiza
difusión de las tramas de la forma estándar 802.1D por los puertos
activos del árbol de expansión. Esta difusión se realiza sin
aprendizaje de la dirección MAC origen. La trama de respuesta o de
vuelta desde el terminal destino utiliza el árbol de expansión de
forma estándar difundiendo la trama de vuelta por todo el árbol
hasta alcanzar el terminal destino. Cada puente frontera que recibe
una trama unicast por árbol de expansión cancela cualquier
asociación a puerto que tenga en ese puente asociado a la dirección
origen o destino, borrando así las rutas Fastpath asociadas. El
puente frontera de destino hace lo mismo, con lo que sucesivas
tramas unicast de ida recorrerán el árbol de expansión hasta que se
establece una nueva conexión FastpathUD entre origen y destino.
La Figura 14 ilustra un caso en que el camino de
vuelta de la trama t10 se hace sin aprendizaje de la dirección MAC
origen. El puente frontera 2.15.9.0.0.0 recibe la trama t10 dirigida
a 1.18.43.67.110.0, que tiene asociada la etiqueta "VLAN T" del
árbol de expansión y, con esa etiqueta, reenvía la trama t10 por
todos los puertos activos en cada puente del árbol, hasta alcanzar
el puente raíz R y de ahí es difundida hacia abajo por todo el
árbol.
\newpage
En este texto, la palabra "comprende" y sus
variantes (como "comprendiendo", etc.) no deben interpretarse
de forma excluyente, es decir, no excluyen la posibilidad de que lo
descrito incluya otros elementos, pasos etc.
Por otra parte, la invención no está limitada a
las realizaciones concretas aquí descritas sino que abarca también
las variantes que pueden ser realizadas por el experto medio en la
materia (por ejemplo, en cuanto a criterios de configuración y
tamaño de las redes de telecomunicaciones, tamaño de las estructuras
de datos, etc.), sin salir del ámbito de la invención que se
desprende de las reivindicaciones incluidas seguidamente.
Claims (27)
1. Procedimiento de encaminamiento de tramas de
datos a través de una pluralidad de puentes de red multipuerto
conectados mediante enlaces punto a punto que soportan dos sentidos
de propagación, formando un árbol de expansión a partir de un puente
de red raíz (R) con respecto al que cada puente de red tiene una
distancia, que comprende:
- asignar a cada puente de red del árbol de
expansión una dirección en correspondencia con la distancia al
puente de red raíz (R),
caracterizado porque adicionalmente
comprende:
- recibir en un puente de red una trama, que
contiene una dirección MAC origen, a través de un puerto del puente
que tiene una identidad de puerto asignada,
- asociar en el puente la identidad del puerto
que primero recibe la trama con la dirección MAC origen de la trama,
con un indicador de caducidad de la dirección MAC origen y con un
tiempo de guarda durante el que se mantiene inmodificable la
asociación dirección MAC origen-identidad del
puerto,
- descartar por el puente de red todas las
tramas con la misma dirección MAC origen recibidas a través de un
puerto del puente con una identidad de puerto distinta a la de la
asociación dirección MAC origen-identidad del
puerto.
\vskip1.000000\baselineskip
2. Procedimiento según la reivindicación 1,
caracterizado porque, si la trama recibida contiene una
dirección MAC de destino de difusión, adicionalmente comprende
enviar la trama a través de todos los puertos del puente que tienen
una identidad de puerto distinta a la de la asociación identidad del
puerto-dirección MAC origen de la
trama.
trama.
3. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, si la
trama recibida contiene una dirección MAC unidestino diferente a la
dirección MAC origen de la asociación dirección MAC
origen-identidad del puerto de todos y cada uno de
los puertos del puente que recibe la trama, adicionalmente comprende
modificar la trama recibida sustituyendo la dirección MAC unidestino
por la dirección MAC origen de la trama recibida y enviar la trama
modificada a través del puerto del puente por el que se ha
recibido.
4. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, si la
trama recibida contiene una dirección MAC unidestino igual a la
dirección MAC origen de la asociación dirección MAC
origen-identidad del puerto y el indicador de
caducidad indica que la dirección está caducada, adicionalmente
comprende modificar la trama recibida sustituyendo la dirección MAC
unidestino por la dirección MAC origen de la trama recibida y enviar
la trama modificada a través del puerto del puente por el que se ha
recibido.
5. Procedimiento según cualquiera de las
reivindicaciones 3 y 4, caracterizado porque adicionalmente
comprende:
- recibir la trama modificada en un puente
frontera conectado a un equipo terminal que tiene la dirección de
destino contenida en la trama modificada,
- enviar desde el puente frontera una trama con
dirección MAC de destino de difusión y dirección MAC origen igual a
la dirección del puente frontera,
- recibir la trama con dirección MAC de destino
de difusión en un puente de red a través de un puerto y modificar la
trama sustituyendo la dirección MAC origen por la dirección del
puente de red y la dirección MAC de destino de difusión por la
dirección del puente frontera,
- enviar desde el puente la trama con dirección
MAC origen igualada a la dirección del puente a través del puerto
cuya identidad de puerto es la de la asociación dirección MAC
origen-identidad del puerto en el puente.
\vskip1.000000\baselineskip
6. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque
adicionalmente comprende enviar periódicamente unas tramas
trazadoras entre dos puentes frontera, un puente frontera origen que
envía y un puente frontera destino que recibe, a través de un enlace
en los dos sentidos de propagación, las tramas trazadoras
conteniendo una dirección origen igual a la dirección del puente
frontera que envía.
7. Procedimiento según la reivindicación 6,
caracterizado porque las tramas trazadoras contienen una
dirección destino que es igual a la dirección del puente frontera
que recibe.
8. Procedimiento según la reivindicación 6,
caracterizado porque las tramas trazadoras contienen una
dirección destino que es de difusión.
\newpage
9. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque la
dirección MAC origen de la trama recibida en un puente se selecciona
entre una dirección MAC universal, dirección MAC local y dirección
MAC local y jerárquica.
10. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque la
dirección asignada a cada puente de red del árbol de expansión es
una dirección MAC local.
11. Procedimiento según la reivindicación 10,
caracterizado porque la dirección asignada a cada puente de
red del árbol de expansión es una dirección MAC local y
jerárquica.
12. Procedimiento según cualquiera de las
reivindicaciones 1 a 9, caracterizado porque la dirección
asignada a cada puente frontera conectado a un equipo terminal está
formada por una dirección MAC universal y un identificador en
correspondencia a la distancia del puente frontera al puente de red
raíz (R).
13. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, cuando se
recibe la trama en un puente frontera conectado a un equipo
terminal, adicionalmente comprende encapsular la trama con una
cabecera que contiene una dirección origen y una dirección destino
que son direcciones MAC locales y jerárquicas.
14. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, cuando se
recibe la trama en un puente frontera conectado a un equipo terminal
a través de un puerto designado con una dirección MAC local y
jerárquica y la trama contiene una dirección origen que es una
dirección MAC universal, el puente frontera sustituye en la
dirección origen la dirección MAC universal por la dirección MAC
local y jerárquica del puerto designado.
15. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque usa el
protocolo de resolución de direcciones ARP.
16. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque usa
prohibición de giros aplicables a encaminamiento arriba/abajo.
17. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, si la
trama recibida contiene una dirección MAC origen que es una
dirección MAC universal y una dirección MAC unidestino que tiene
asociado en el puente que la recibe un indicador de caducidad
indicando que la dirección está caducada, adicionalmente
comprende:
- borrar del puente la asociación con la
dirección MAC unidestino,
- modificar la trama recibida sustituyendo la
dirección MAC unidestino por una dirección MAC de multidifusión,
- enviar la trama modificada a la dirección MAC
origen.
\vskip1.000000\baselineskip
18. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, si la
trama recibida contiene una dirección MAC origen que es una
dirección MAC local y jerárquica y una dirección MAC unidestino que
tiene asociado en el puente que la recibe un indicador de caducidad
indicando que la dirección está caducada, adicionalmente
comprende:
- borrar del puente la asociación con la
dirección MAC unidestino,
- modificar la trama recibida sustituyendo la
dirección MAC unidestino por la dirección MAC local y jerárquica
contenida en la dirección MAC origen de la trama recibida, y
sustituyendo la dirección MAC origen de la trama por una dirección
MAC local y jerárquica asignada al puente que la recibe;
- enviar la trama modificada a la dirección MAC
local y jerárquica contenida en la dirección MAC origen de la trama
recibida.
\vskip1.000000\baselineskip
19. Procedimiento según la reivindicación 18,
caracterizado porque la dirección MAC local y jerárquica
contenida en la dirección MAC origen de la trama recibida
corresponde a un equipo terminal.
20. Procedimiento según la reivindicación 18,
caracterizado porque la dirección MAC local y jerárquica
contenida en la dirección MAC origen de la trama recibida
corresponde a un puente frontera conectado a un equipo terminal.
21. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, si la
trama recibida contiene una dirección MAC origen que es una
dirección MAC universal y una dirección MAC unidestino que
corresponde a un puente que está caído o está conectado al puente
receptor de la trama mediante un enlace en el que se ha detectado
una caída, adicionalmente comprende:
- borrar del puente receptor de la asociación
con la dirección MAC unidestino,
- modificar la trama recibida sustituyendo la
dirección MAC unidestino por una dirección MAC multidifusión,
- enviar la trama modificada a la dirección MAC
origen.
\vskip1.000000\baselineskip
22. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque, si la
trama recibida contiene una dirección MAC origen que es una
dirección MAC local y jerárquica y una dirección MAC unidestino que
corresponde a un puente que está caído o está conectado al puente
receptor de la trama mediante un enlace en el que se ha detectado
una calda, adicionalmente comprende:
- borrar del puente receptor de la trama la
asociación con la dirección MAC unidestino,
- modificar la trama recibida sustituyendo la
dirección MAC unidestino por la dirección MAC local y jerárquica
contenida en la dirección MAC origen de la trama recibida, y
sustituyendo la dirección MAC origen de la trama por una dirección
MAC local y jerárquica asignada al puente receptor de la trama;
- enviar la trama modificada a la dirección MAC
local y jerárquica contenida en la dirección MAC origen de la trama
recibida.
\vskip1.000000\baselineskip
23. Procedimiento según la reivindicación 22,
caracterizado porque la dirección MAC local y jerárquica
contenida en la dirección MAC origen de la trama recibida
corresponde a un equipo terminal.
24. Procedimiento según la reivindicación 22,
caracterizado porque la dirección MAC local y jerárquica
contenida en la dirección MAC origen de la trama recibida
corresponde a un puente frontera conectado a un equipo terminal.
25. Procedimiento según cualquiera de las
reivindicaciones anteriores, caracterizado porque
adicionalmente comprende etiquetar en el puente la trama recibida
con una etiqueta VLAN que se selecciona entre etiqueta de la VLAN
del árbol de expansión y etiqueta VLAN de la red de puentes que
operan según la reivindicación 1.
26. Puente de red multipuerto
caracterizado porque comprende medios de procesamiento
configurados para encaminar tramas en el nivel de enlace de datos y
en el plano de usuario de acuerdo con el procedimiento de
encaminamiento de tramas de datos definido según cualquiera de las
reivindicaciones 1 a 25.
27. Red de telecomunicaciones conmutada
caracterizada porque comprende al menos un puente de red
definido según la reivindicación 26 conectado a un puente de red
raíz (R) en un árbol de expansión.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200900508A ES2361545B1 (es) | 2009-02-24 | 2009-02-24 | Procedimiento de encaminamiento de tramas de datos y puente de red. |
| US13/203,152 US20120044837A1 (en) | 2009-02-24 | 2010-02-23 | Data frame routing method and network bridge |
| PCT/ES2010/000075 WO2010097489A1 (es) | 2009-02-24 | 2010-02-23 | Procedimiento de encaminamiento de tramas de datos y puente de red |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200900508A ES2361545B1 (es) | 2009-02-24 | 2009-02-24 | Procedimiento de encaminamiento de tramas de datos y puente de red. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2361545A1 true ES2361545A1 (es) | 2011-06-20 |
| ES2361545B1 ES2361545B1 (es) | 2012-05-08 |
Family
ID=42665037
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200900508A Active ES2361545B1 (es) | 2009-02-24 | 2009-02-24 | Procedimiento de encaminamiento de tramas de datos y puente de red. |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20120044837A1 (es) |
| ES (1) | ES2361545B1 (es) |
| WO (1) | WO2010097489A1 (es) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9473424B2 (en) * | 2011-09-19 | 2016-10-18 | Fujitsu Limited | Address table flushing in distributed switching systems |
| US9571387B1 (en) * | 2012-03-12 | 2017-02-14 | Juniper Networks, Inc. | Forwarding using maximally redundant trees |
| US8693478B2 (en) * | 2012-03-16 | 2014-04-08 | Cisco Technology, Inc. | Multiple shortest-path tree protocol |
| US9379971B2 (en) * | 2012-05-11 | 2016-06-28 | Simula Inovation AS | Method and apparatus for determining paths between source/destination pairs |
| US9160564B2 (en) * | 2012-06-25 | 2015-10-13 | Qualcomm Incorporated | Spanning tree protocol for hybrid networks |
| US9608900B2 (en) * | 2012-08-08 | 2017-03-28 | Cisco Technology, Inc. | Techniques for flooding optimization for link state protocols in a network topology |
| GB2508891A (en) * | 2012-12-14 | 2014-06-18 | Ibm | Deadlock-free routing of data packets in fat tree networks |
| US9178799B2 (en) | 2013-02-01 | 2015-11-03 | TELEFONAKTIEBOLAGET L M ERRICSSON (publ) | Method and system of shortest path bridging (SPB) enhanced resilience with loop mitigation |
| US9197553B2 (en) | 2013-03-29 | 2015-11-24 | Cisco Technology, Inc. | Using a virtual internet protocol address to represent dually connected hosts in an internet protocol overlay network |
| US9722861B2 (en) * | 2013-07-07 | 2017-08-01 | Alcatel Lucent | Fault-resilient broadcast, multicast, and unicast services |
| US9237025B2 (en) * | 2013-08-15 | 2016-01-12 | Verizon Patent And Licensing Inc. | Source routing in multicast transmissions |
| JP6197674B2 (ja) * | 2014-01-31 | 2017-09-20 | 富士通株式会社 | 通信方法、中継装置、および、通信プログラム |
| US9294385B2 (en) * | 2014-03-03 | 2016-03-22 | International Business Machines Corporation | Deadlock-free routing in fat tree networks |
| US9647925B2 (en) * | 2014-11-05 | 2017-05-09 | Huawei Technologies Co., Ltd. | System and method for data path validation and verification |
| TWI575922B (zh) * | 2015-08-27 | 2017-03-21 | 瑞昱半導體股份有限公司 | 能應用於堆疊通訊系統之通訊裝置與方法 |
| US10187218B2 (en) * | 2015-09-15 | 2019-01-22 | Google Llc | Systems and methods for processing packets in a computer network |
| US10719341B2 (en) | 2015-12-02 | 2020-07-21 | Nicira, Inc. | Learning of tunnel endpoint selections |
| US10164885B2 (en) | 2015-12-02 | 2018-12-25 | Nicira, Inc. | Load balancing over multiple tunnel endpoints |
| US10069646B2 (en) | 2015-12-02 | 2018-09-04 | Nicira, Inc. | Distribution of tunnel endpoint mapping information |
| US9912616B2 (en) * | 2015-12-02 | 2018-03-06 | Nicira, Inc. | Grouping tunnel endpoints of a bridge cluster |
| US9948520B2 (en) * | 2016-04-13 | 2018-04-17 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Efficiently determining network topology |
| CN108574637B (zh) * | 2017-03-07 | 2022-09-27 | 中兴通讯股份有限公司 | 一种地址自学习的方法、装置及交换机 |
| US10554425B2 (en) | 2017-07-28 | 2020-02-04 | Juniper Networks, Inc. | Maximally redundant trees to redundant multicast source nodes for multicast protection |
| SE1950056A1 (en) * | 2019-01-17 | 2020-07-18 | Telia Co Ab | Methods and apparatuses for switching frames in a network topology |
| US11689455B2 (en) * | 2020-05-28 | 2023-06-27 | Oracle International Corporation | Loop prevention in virtual layer 2 networks |
| JP2023535149A (ja) | 2020-07-14 | 2023-08-16 | オラクル・インターナショナル・コーポレイション | Ｖｌａｎスイッチングおよびルーティングサービスのためのシステムおよび方法 |
| US11652743B2 (en) | 2020-12-30 | 2023-05-16 | Oracle International Corporation | Internet group management protocol (IGMP) of a layer-2 network in a virtualized cloud environment |
| US11671355B2 (en) | 2021-02-05 | 2023-06-06 | Oracle International Corporation | Packet flow control in a header of a packet |
| US11777897B2 (en) | 2021-02-13 | 2023-10-03 | Oracle International Corporation | Cloud infrastructure resources for connecting a service provider private network to a customer private network |
| CN113572691B (zh) * | 2021-09-22 | 2021-12-07 | 天津七一二通信广播股份有限公司 | 一种基于时间脉冲源的混合路由协议的实现方法 |
| US11743191B1 (en) | 2022-07-25 | 2023-08-29 | Vmware, Inc. | Load balancing over tunnel endpoint groups |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4399531A (en) * | 1980-09-29 | 1983-08-16 | Rockwell International Corporation | Distributed digital data communications network |
| US6963575B1 (en) * | 2000-06-07 | 2005-11-08 | Yipes Enterprise Services, Inc. | Enhanced data switching/routing for multi-regional IP over fiber network |
| EP1853003A1 (en) * | 2006-05-02 | 2007-11-07 | Acterna France | System and method for monitoring a data network segment |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8179808B2 (en) * | 2003-10-31 | 2012-05-15 | Brocade Communication Systems, Inc. | Network path tracing method |
| US7483370B1 (en) * | 2003-12-22 | 2009-01-27 | Extreme Networks, Inc. | Methods and systems for hitless switch management module failover and upgrade |
| EP1952584A1 (de) * | 2005-11-16 | 2008-08-06 | Nokia Siemens Networks Gmbh & Co. Kg | Verfahren zum ermitteln einer schleifenfreien baumstruktur in einem datenübertragungsnetz und zugehöriges netzelement |
| JP3920305B1 (ja) * | 2005-12-12 | 2007-05-30 | 株式会社日立コミュニケーションテクノロジー | パケット転送装置 |
| DE102007015226A1 (de) * | 2006-09-28 | 2008-04-03 | Siemens Ag | Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks |
| JP4863090B2 (ja) * | 2007-08-23 | 2012-01-25 | 日本電気株式会社 | 通信ネットワークの品質劣化箇所推定装置、方法、及びプログラム、並びに通信ネットワークシステム |
| JP5088162B2 (ja) * | 2008-02-15 | 2012-12-05 | 富士通株式会社 | フレーム伝送装置およびループ判定方法 |
| US8509228B2 (en) * | 2008-06-03 | 2013-08-13 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for prioritizing source MAC address miss processing |
-
2009
- 2009-02-24 ES ES200900508A patent/ES2361545B1/es active Active
-
2010
- 2010-02-23 US US13/203,152 patent/US20120044837A1/en not_active Abandoned
- 2010-02-23 WO PCT/ES2010/000075 patent/WO2010097489A1/es active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4399531A (en) * | 1980-09-29 | 1983-08-16 | Rockwell International Corporation | Distributed digital data communications network |
| US6963575B1 (en) * | 2000-06-07 | 2005-11-08 | Yipes Enterprise Services, Inc. | Enhanced data switching/routing for multi-regional IP over fiber network |
| EP1853003A1 (en) * | 2006-05-02 | 2007-11-07 | Acterna France | System and method for monitoring a data network segment |
Non-Patent Citations (2)
| Title |
|---|
| AZCORRA A; IBAÑEZ G 'Application of rapid spanning tree protocol for automatic 'hierarchical address assignment to bridges' Telecommunications Network Strategy and Planning Symposium. NETWORKS 2004, 11th International Vienna, Austria. Junio 13.06.2004, Pags: 435-440. ISBN 978-3-8007-2840-4; ISBN 3-8007-2840-0. * |
| Hierarchical Up/Down routing architecture for ethernet backbones and campus networks'IBAÑEZ G A; GARCIA-MARTINEZ A; CARRAL J A; GONZALEZ P A Computer Communications Workshops, 2008. 13.04.2008. Págs: 1-6. ISBN 978-1-4244-2219-7; ISBN 1-4244-2219-1. * |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2361545B1 (es) | 2012-05-08 |
| WO2010097489A1 (es) | 2010-09-02 |
| US20120044837A1 (en) | 2012-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2361545B1 (es) | Procedimiento de encaminamiento de tramas de datos y puente de red. | |
| Touch et al. | Transparent interconnection of lots of links (TRILL): Problem and applicability statement | |
| US8102775B2 (en) | Joining tree-based networks into an autonomous system using peer connections between the tree-based networks | |
| US8995444B2 (en) | Method and system for extending routing domain to non-routing end stations | |
| US7697556B2 (en) | MAC (media access control) tunneling and control and method | |
| US8717934B2 (en) | Multicast source move detection for layer-2 interconnect solutions | |
| ES2339782T3 (es) | Protocolo hibrido de encaminamiento para una red con topologia de malla. | |
| US20130259050A1 (en) | Systems and methods for multi-level switching of data frames | |
| ES2306337T3 (es) | Procedimiento y sistema para implementar el protocolo de redundancia de encaminador virtual sobre un anillo de paquete resiliente. | |
| Perlman | Challenges and Opportunities in the Design of TRILL: a Routed layer 2 Technology | |
| US10841211B2 (en) | End point mapping service to assist transport segment routing | |
| US6868086B1 (en) | Data packet routing | |
| EP1927222B1 (en) | Low latency working vpls | |
| Malhotra | IP routing | |
| WO2012078523A1 (en) | Systems and methods for pseudo-link creation | |
| ES2228266B1 (es) | Procedimiento de conmutacion de paquetes en un medio de transmision con multiples estaciones conectadas mediante distintos enlaces. | |
| Ibáñez et al. | Fast Path Ethernet Switching: On-demand, efficient transparent bridges for data center and campus networks | |
| ES2363083T5 (es) | Procedimiento de conmutación automática de protección | |
| ES2337220B1 (es) | Procedimiento de gestion de enlaces en el nivel de enlace de datos para redes de comunicaciones, procedimiento de encaminamiento de tramas de datos, dispositivo de interconexion de redes y red que combina ambos procedimientos. | |
| Ibáñez et al. | HURP/HURBA: Zero-configuration hierarchical Up/Down routing and bridging architecture for Ethernet backbones and campus networks | |
| WO2012152969A1 (es) | Procedimiento de reparación de caminos de tramas de datos y puente de red | |
| ES2283228B2 (es) | Procedimiento de encaminamiento. | |
| EP2023544A1 (en) | Method and device for distributing address information and communication system comprising such device | |
| Seo et al. | Extensible Multiple Spanning Tree Protocol for Virtual eXtensible LAN | |
| Ibáñez et al. | Hierarchical up/down routing architecture for Ethernet backbones and campus networks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG2A | Definitive protection |
Ref document number: 2361545 Country of ref document: ES Kind code of ref document: B1 Effective date: 20120508 |