ES2337220B1 - 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. - Google Patents
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. Download PDFInfo
- Publication number
- ES2337220B1 ES2337220B1 ES200702358A ES200702358A ES2337220B1 ES 2337220 B1 ES2337220 B1 ES 2337220B1 ES 200702358 A ES200702358 A ES 200702358A ES 200702358 A ES200702358 A ES 200702358A ES 2337220 B1 ES2337220 B1 ES 2337220B1
- Authority
- ES
- Spain
- Prior art keywords
- network
- hierarchical
- bridge
- mac address
- route
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
-
- H04L12/5689—
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Abstract
Procedimiento de gestión de enlaces en el nivel
de enlace de datos para redes de comunicaciones, procedimiento de
encaminamiento de tramas de datos, dispositivo de interconexión de
redes y red que combina ambos procedimientos.
Esta gestión de enlaces en el nivel de enlace de
datos (capa 2 de OSI) comprende un procedimiento para construir un
árbol de expansión jerárquico a partir de un puente de red (bridge)
elegido como raíz, del que cuelga al menos un puente de red
conectado a dicha raíz a través de un puerto designado y al que se
asigna una dirección MAC local jerárquica (HLMAC) correspondiente al
identificador del puerto designado. Las tramas con dirección de
destino HLMAC se encaminan mediante un procedimiento que usa el
árbol de expansión jerárquico. Todos los puentes (aquí se bautizan
como puentes combinados) a los que se asigna dirección MAC local
jerárquica también pueden procesar tramas con direcciones MAC
universales asignadas a los terminales destino. Este árbol
jerárquico se construye junto con el árbol estándar (802.1D),
formando un árbol de expansión mixto que comprende tanto puentes
combinados como los convencionales que operan bajo 802.1D.
Description
Procedimiento de gestión de enlaces en el nivel
de enlace de datos para redes de comunicaciones, procedimiento de
encaminamiento de tramas de datos, dispositivo de interconexión de
redes y red que combina ambos procedimientos.
\global\parskip0.930000\baselineskip
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, vídeo) en una única
infraestructura IP ("Internet Protocol"), soportando distancias
de transmisión que pueden ir hasta rangos idénticos a los de redes
de área amplia (WAN).
Las prestaciones y economía de Gigabit Ethernet
y 10 GE empujan hacia cambios importantes tanto en las redes LAN
como MAN, provocados por los drásticos incrementos en ancho de banda
y escalabilidad así como por la facilidad de gestión y el bajo coste
respecto a los conmutadores ATM y a los equipos SDH.
A tales avances hay que sumar la creciente
demanda de ancho de banda por las aplicaciones multimedia (formación
multimedia on-line, videoconferencia,
telecongresos, etc.), las nuevas aplicaciones asociadas a la
investigación y la industria (computación distribuida, visión
artificial, etc.) que exigen mayor capacidad y menor retardo en las
comunicaciones y el creciente número de equipos conectados a las
redes campus. De todo ello deriva la necesidad de disponer de redes
campus Ethernet autoconfigurables, de altas prestaciones, escalables
a grandes tamaños de red y de coste reducido.
Dada la previsible proliferación de dispositivos
de todo tipo en las redes campus, los tamaños de redes que se
contemplan son de hasta 100.000 dispositivos (terminales de la red)
de los cuales aproximadamente 20.000 pueden ser ordenadores
convencionales, siendo el resto dispositivos de diversos tipos:
sensores, paneles, asistentes personales (PDA), etc. El numero de
puentes de red ("bridges", en inglés) típico para una red de
este tipo puede ser de alrededor de 500.
El encaminamiento de las tramas en los puentes
de red que se usan actualmente se deriva del definido en el estándar
IEEE 802.1D. Pero para la implantación de redes de tamaño medio o
grande el uso de puentes 802.1D tiene los siguientes
inconvenientes:
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.
Hay que asignar y gestionar las direcciones IP,
y la dirección IP cambia al cambiar el usuario de lugar de
conexión.
Se infrautiliza mucha infraestructura costosa
debido a los enlaces bloqueados por el protocolo de Árbol de
Expansión (STP: "Spanning Tree Protocol", en inglés).
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.
Existen diversas propuestas para definir una
arquitectura de redes Ethernet escalable y autoconfigurable, la
mayoría basadas en encapsulados adicionales: 802.1ah, UETS/EFR
("Universal Ethernet Telecommunications Service/Ethernet Fabric
Routing"),... Estas propuestas presentan encapsulados apilados y
complejos, lo que supone una escalabilidad de granularidad gruesa
debida a la ausencia de verdadera jerarquía en las propuestas, dado
que se mantiene el direccionamiento plano del Control de Acceso al
Medio (MAC) Ethernet.
A continuación, se exponen algunas de las
deficiencias que presentan las soluciones usadas para redes Ethernet
hasta la fecha:
- Conmutadores de Capa Tres o Multicapa [por
ejemplo, ver Cisco LAN Switching de Kennedy Clark, Kevin Hamilton,
CCIE Professional Development series, ISBN:
1-57870-094-9, Cisco
Press, 2001]: Aunque no poseen capacidad de encaminamiento WAN como
los encaminadores, son más simples de configurar que éstos (las
desventajas de los encaminadores se resumen en: complejidad por la
necesidad de administrar las direcciones IP, menores prestaciones y
mayor coste para iguales prestaciones por el mayor procesado de los
paquetes IP respecto a las tramas Ethernet). Sin embargo, para el
encaminamiento LAN aún siguen precisando definir segmentos IP.
\global\parskip1.000000\baselineskip
- Conmutadores con encaminamiento en origen:
Aunque el encaminamiento en origen (o basado en fuente)
puede considerarse obsoleto en redes fijas, es objeto de estandarización en las redes ad-hoc como es el caso del protocolo DSR ["The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", disponible en
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt]. Cuando se emplea encaminamiento en origen en redes de capa dos, como las Token Ring, un primer inconveniente es la necesidad, a diferencia de la autoconfiguración de los puentes Ethernet, de asignar la identidad de todos los Puentes y Redes Locales para mantener la transparencia, ya que deben ser siempre los puentes de red los que realicen el encaminamiento en origen, nunca los equipos terminales de la red. Un segundo gran inconveniente es la gran sobrecarga de mensajes producida por el descubrimiento de rutas; de hecho, el ancho de banda requerido crece exponencialmente con el número de puentes por LAN y el número de puertos por puentes. La trama asimismo se alarga al extenderla con la ruta explícita, la cual contiene todas las direcciones de puentes y LANs a atravesar.
puede considerarse obsoleto en redes fijas, es objeto de estandarización en las redes ad-hoc como es el caso del protocolo DSR ["The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)", disponible en
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt]. Cuando se emplea encaminamiento en origen en redes de capa dos, como las Token Ring, un primer inconveniente es la necesidad, a diferencia de la autoconfiguración de los puentes Ethernet, de asignar la identidad de todos los Puentes y Redes Locales para mantener la transparencia, ya que deben ser siempre los puentes de red los que realicen el encaminamiento en origen, nunca los equipos terminales de la red. Un segundo gran inconveniente es la gran sobrecarga de mensajes producida por el descubrimiento de rutas; de hecho, el ancho de banda requerido crece exponencialmente con el número de puentes por LAN y el número de puertos por puentes. La trama asimismo se alarga al extenderla con la ruta explícita, la cual contiene todas las direcciones de puentes y LANs a atravesar.
- Conmutadores con encaminamiento centralizado:
Aparecen como uno de los primeros antecedentes de red local
autoconfigurable ["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].
Un inconveniente considerable de "Autonet" radica en que la
compatibilidad entre los modos de trabajo Ethernet y Autonet se
implementa en los ordenadores conectados como terminales,
requiriendo la modificación de los mismos mediante la incorporación
de un módulo ("Localnet") situado por encima de los
controladores software ("drivers") de Ethernet y Autonet.
Además, los enlaces deben ser punto a punto, con un solo terminal
conectado en cada segmento de LAN.
- Conmutadores con encaminamiento distribuido
("Smartbridges", "Rbridges" y LSOM): A diferencia de
"Autonet", los "Smartbridges" no precisan comunicación
punto a punto ["SmartBridge: A scalable bridge architecture" de
T. L. Rodeheffer et al., Proceedings of ACM SIGCOMM 2000,
2000], pero no son compatibles con los puentes 802.1D, no permiten
incluir la velocidad del enlace como criterio de elección de caminos
y precisan reinicialización global en caso de reconfiguración por
cambio de topología. Los "Rbridges" ("Routing Bridges")
[ver http://www.postel.org/pipermail/RBridge/] no resultan
escalables a escenarios de redes campus muy grandes, porque el
encaminamiento basado en direcciones MAC produce tablas bastante
grandes al ser direcciones planas que no permiten agregar rutas en
el encaminamiento, por lo que exigen excesiva memoria y ralentiza
la búsqueda en los puentes para tamaños grandes de red. RBridges
modifican la trama en cada salto entre RBridges cambiando entre
otros, el campo de RBridge de siguiente salto, lo que complica el
procesamiento de tramas. El encaminamiento LSOM ["LSOM: A Link
State Protocol Over MAC Addresses for Metropolitan Backbones Using
Optical Ethernet Switches" por J. Duato et al.,
Proceedings Second IEEE NCA'03, 2003] utiliza caminos óptimos,
distribuye el tráfico en la red y utiliza bien la infraestructura,
pero tampoco resuelve el problema de la proliferación de direcciones
MAC.
- Otros Conmutadores con encaminamiento son los
bautizados como "Brouters" [definición en
http://en.wikipedia.org/wiki/Brouter]: Son dispositivos híbridos entre un puente de red y un encaminador, pero no son compatibles con los puentes 802.1D y sufren una sobrecarga importante en el proceso para obtener las tablas de retardos por puerto.
http://en.wikipedia.org/wiki/Brouter]: Son dispositivos híbridos entre un puente de red y un encaminador, pero no son compatibles con los puentes 802.1D y sufren una sobrecarga importante en el proceso para obtener las tablas de retardos por puerto.
Por otra parte, la tecnología de Árboles
Múltiples De Expansión ("MSTP: Multiple 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.
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. Un problema del
encaminamiento arriba/abajo es que no garantiza rutas óptimas y
resulta menos eficiente a medida que la red se hace más compleja.
Otro severo inconveniente es que su rendimiento depende mucho de la
elección del puente raíz.
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 propuesta posterior es el basado en árbol o TBTP
("Tree-Based Turn Prohibition Protocol", en
inglés) [ver "Scalable cycle-breaking algorithms
for gigabit Ethernet backbones" de F. D. Pellegrini et
al., Proceedings of IEEE Infocom 2004, 2004], que referencia
los giros prohibidos o no con relación al propio árbol de
expansión. Este protocolo se ejecuta de forma centralizada, con los
inconvenientes de indisponibilidad derivados en caso de
reconfiguración de la red por caída de enlaces o puentes. La
complejidad del algoritmo TBTP es de O(N^{2}d^{2})
siendo N el número de nodos y d el grado máximo del grafo de la red.
El rendimiento de la red con TBPT (tráfico máximo cursado) es menor
que con TP.
Existe una versión distribuida de este
protocolo, dTBTP ("Distributed Tree-Based Turn
Prohibition Protocol", en inglés [ver "Scalable, Distributed
cycle-breaking algorithms for gigabit Ethernet
backbones" de F. D. Pellegrini et al., Journal of Optical
Networking Feb. 2006, Vol. 5. No. 2., 2006] que prohíbe hasta la
mitad de los giros posibles en la red. El rendimiento de dTBTP es
muy inferior a TBTP si no se preordenan las identidades de puente
previamente según distancia al puente raíz, lo cual se realiza
asignando una identidad compuesta uniendo el coste al raíz con el
identificador MAC del puente para evitar igualdad de identidades en
caso de empates de coste al raíz. La convergencia es lenta
requiriéndose un número alto de iteraciones del algoritmo de
prohibición de giros superior a 15 y creciente con el tamaño de la
red hasta cerca de 45. A ello debe unirse el protocolo de
encaminamiento, basado en algoritmo de Bellman-Ford,
para el cálculo de las rutas.
La aplicación directa de la prohibición de giros
en los algoritmos de encaminamiento como el de Djikstra no es
posible de forma simple (eliminando los caminos que contienen giros
prohibidos de la tabla de encaminamiento) porque entonces los
caminos no son mínimos debido a que Djikstra descubre y elige rutas
mínimas de forma escalonada al ir explorando la red desde los nodos
incorporados sucesivamente al descubrir la red. Algunas de las rutas
mínimas descubiertas tendrán giros prohibidos y otras no. Otros
métodos ["Routing in Turn-Prohibition Based
Feed-Forward Networks" de M. Fiddler et
al., NETWORKING 2004, Lecture Notes in Computer Science, LNCS
3042, p.1168-1179, 2004] aplican restricciones de
prohibición de giros, pero la complejidad crece desde
O(N^{2}) a O(E^{2}), siendo N y E respectivamente
el número de nodos y de enlaces.
Otra solución alternativa para hacer Ethernet
más escalable es la del 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 la trama Ethernet, por lo que se realiza un encapsulado adicional de la trama en el que se incluye el campo dirección RSTAA ("Rapid Spanning Tree Based Address Assignment"). RSTAA propone direcciones asignables de longitud variable implementadas como un número variable de campos sucesivos de longitud fija, que por su longitud variable solo pueden transportarse con 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.
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 la trama Ethernet, por lo que se realiza un encapsulado adicional de la trama en el que se incluye el campo dirección RSTAA ("Rapid Spanning Tree Based Address Assignment"). RSTAA propone direcciones asignables de longitud variable implementadas como un número variable de campos sucesivos de longitud fija, que por su longitud variable solo pueden transportarse con 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.
Una última propuesta más 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). La
única reconfiguración de enlaces posible es para los enlaces
transversales, los cuales no son parte de la red jerárquica, es
decir, toda la topología se supone activa, jerárquica y estable.
Las direcciones UETS deben ser estables, porque el dominio de
direccionamiento UETS puede ser de ámbito mundial, por tanto, no
pueden depender del árbol de expansión, que al reconfigurarse
modificaría las direcciones. UETS está orientado a conmutadores de
tipo Banyan para máximo rendimiento que no utilizan difusión,
mecanismo base del árbol de expansión. Aunque los conmutadores
Banyan son muy efectivos para alto tráfico si éste está distribuido
entre los puertos, el tráfico de las redes es muy centralizado por
el predominio del tráfico cliente-servidor y el
posicionamiento de los servidores en puntos de la red bien
conectados. Para tener alta eficiencia mediante la conmutación
hardware, la topología de la red debe corresponderse con la del
árbol jerárquico de direcciones de puertos finales.
En resumen, la problemática que sigue sin
resolverse hoy en día 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 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.
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 red del
nivel de enlace de datos (segunda capa OSI) que constituye un árbol
jerárquico combinado (CHT: "combined hierarchical tree", en
inglés) capaz de interoperar con puentes de red convencionales
(éstos son los puentes que emplean un árbol de expansión estándar:
STP o RSTP) y que configura una topología de red en forma de árbol
de expansión mixto, donde los puentes de red que soportan dicho
protocolo CHT forman una red sin discontinuidad y conectan en su
periferia a los puentes convencionales como subárboles.
El protocolo de red del nivel de enlace de datos
que se propone, aquí llamado protocolo CHT y así denominado en
adelante, comprende a su vez dos protocolos:
- Un protocolo de creación (o
establecimiento/construcción) y mantenimiento (configuración y
reconfiguración) de un árbol de expansión mixto (o combinado) que
se forma, de acuerdo a ciertos criterios que se definen más
adelante, tanto con puentes convencionales (que operan sólo según el
estándar: STP o RSTP) como con puentes de red que operan según este
protocolo CHT (y que así pues se denominan aquí puentes combinados).
Además, este protocolo incluye la ejecución, de un proceso de
asignación de direcciones MAC locales de manera jerárquica (aquí
llamadas direcciones HLMAC).
- Un protocolo de encaminamiento y reenvío
jerárquico arriba-abajo que realiza los procesos de
difusión de rutas a los puentes de red vecinos (los que están
conectados directamente por un enlace) y encaminamiento de las
tramas cuyo destino son las direcciones MAC locales asignadas de
manera jerárquica, complementando el encaminamiento estándar
(802.1D), mediante diversos esquemas (encaminamiento vertical,
transversal y con mecanismos de prohibición de giros) que se
explican más adelante.
El protocolo de creación y mantenimiento del
árbol de expansión mixto (que a partir de aquí y para abreviar, se
designa con las siglas CSTP: "Combined Spanning Tree Protocol")
consiste en una extensión del protocolo de árbol de expansión
estándar (RSTP o STP), gracias a la cual es posible interoperar con
dos niveles de red (uno dado por direcciones MAC universales planas
y otro determinado por direcciones MAC locales jerárquicas), sin
necesitar encapsulado adicional (de las tramas con direccionamiento
jerárquico dentro de las tramas de direcciones MAC planas,
universales o también llamadas globales).
Dicho protocolo CSTP opera así en enlaces punto
a punto, no compartidos. Si el enlace no es punto a punto, es
decir, el puente combinado está conectado por algún puerto a al
menos un puente convencional o a segmentos LAN compartidos por
varios terminales, dicho puente combinado opera en dicho puerto
según el protocolo de árbol de expansión estándar (RSTP o STP) y
encamina las tramas del mismo modo que un puente convencional.
La máquina de estados de CSTP es análoga a la
del RSTP pero la información intercambiada es distinta. Los puentes
de red que operan según CSTP envían, tomando como dirección MAC de
origen una única dirección MAC de su puerto y como MAC de destino
una dirección de multidifusión, y periódicamente (por defecto, cada
2 segundos) información sobre este protocolo en una trama especial
(BPDU: "Bridge Protocol Data Unit"). Los campos distintos de la
trama BPDU que usa CSTP respecto a la del RSTP son:
- el campo "Protocol Version Identifier",
constituido por el tercer octeto de la BPDU estándar y utilizado en
802.1D para diferenciar STP de RSTP, aquí para distinguir CSTP de
ellos; y
- un campo de seis octetos que se añade tras el
último octeto de la BPDU estándar y que contiene un prefijo que es
la dirección asignada al puerto raíz del puente de red destinatario
de la BPDU; este campo, al que aquí se le da el nombre de
coordenada RSTCA ("Rapid Spanning Tree Compact Address"), es
usado por el puente de red origen que opera según CSTP para indicar
a cada puente vecino suyo la dirección jerárquica RSTCA que se le
asigna; la coordenada RSTCA se forma añadiendo al prefijo (la
dirección del puerto raíz del puente) la identidad del puerto
designado correspondiente, para cada puerto designado del puente por
el que se conecta a cada vecino.
En este contexto, el puerto raíz de un puente es
el que ofrece un camino de menor coste hacia el puente raíz y el
puerto designado es el que conecta el puente con otro o con un
segmento de red. El puente raíz es aquél a partir del que se
establece el camino de menor coste para todas las redes conectadas
al mismo; y entre todos los puentes que conectan un mismo segmento
de red, un puente designado es el que se elige para transmitir las
tramas hacia el puente raíz con el menor coste (en caso de mismo
coste en dos puentes del mismo segmento, el de menor identificador
es el elegido como puente designado).
Los puentes de red que utilizan este protocolo
CSTP (puentes combinados) intercambian con los puentes de red
convencionales tramas BPDU estándar (según las BPDU definidas para
RSTP o STP).
Adicionalmente, el protocolo CSTP incluye la
función de direccionamiento jerárquico o asignación de coordenadas
RSTCA. Alternativamente, la asignación de coordenadas jerárquicas
puede realizarse asimismo de forma separada del protocolo CSTP
cuando este protocolo en cada puente deja accesible a otros
programas la información necesaria de los roles, estados e
identidades de los puertos para que el programa externo a CSTP
construya con ellos las dirección jerárquicas equivalentes. En
cualquier caso, solamente se asignan coordenadas jerárquicas a los
puentes combinados (no a los puentes convencionales).
Los puentes combinados utilizan para el
intercambio de datos el formato de trama estándar 802.1D (trama
Ethernet) y, por tanto, no requieren encapsulado de tramas,
logrando una mayor compatibilidad y simplicidad que otras
soluciones antecedentes (UETS, etc.). Lo único diferente que la
presente solución introduce en dicha trama de datos estándar es la
asignación de direcciones MAC locales de forma jerárquica. A
diferencia de las direcciones RSTAA de longitud variable, las
coordenadas RSTCA son direcciones compactadas en el formato estándar
de direcciones MAC de 6 octetos, que hacen posible prescindir del
encapsulado adicional de RSJ. Y a diferencia de las direcciones
UETS, no requieren identificación explícita de la máscara aplicable
en cada conmutador de la red.
Las coordenadas RSTCA consisten en direcciones
MAC de longitud variable encapsuladas en el campo estándar de
dirección MAC de la trama de datos estándar, el cual tiene una
longitud fija de seis octetos. Una opción de realización para que
esta dirección de longitud variable quede embebida en el campo
estándar de dirección MAC es rellenar con ceros hasta completar los
seis octetos, indicando implícitamente la longitud del prefijo de
la subred. Otra opción es usar un esquema de máscaras de longitud
fija, que determina la longitud en octetos de la coordenada RSTCA,
es decir, indica explícitamente el número de niveles de la subred.
Por ejemplo, usando 8 bits de máscara en todos los niveles de la
subred a partir del segundo, permite la operación simplificada y
compatible con puentes de hasta 254 puertos en los niveles 2 a 6 y
de hasta 62 en el primer nivel. Además, se contempla un mecanismo
adicional preventivo de unión indebida al primer nivel de un puente
con mayor número de puertos activos.
El mecanismo de asignación de direcciones
jerárquicas que aplica CSTP utiliza los mecanismos de construcción
del árbol de expansión de RSTP (o STP). El protocolo CSTP establece
el árbol de expansión de manera estándar solamente entre los
puentes que operan según el mismo CSTP (los puentes de tipo
combinado se llaman aquí) y relega a subárboles a los puentes de
otro tipo (puentes convencionales). Una vez creado dicho árbol de
expansión, cada puente combinado designado (el término puente
designado se emplea en el mismo sentido que en el estándar 802.1D:
es el puente que encamina el tráfico de una LAN determinada de modo
que el puente designado de un segmento LAN es el designado para
todos los terminales de esa LAN) emite en su BPDU (en el campo de
coordenada RSCTA) la dirección jerárquica HLMAC que asigna a su
puerto designado el puente vecino conectado (que recibe dicha
BPDU). La asignación de direcciones jerárquicas también puede
efectuarse de manera simultánea, en vez de sucesiva, al protocolo de
árbol de expansión estándar usado (RSTP o STP).
El uso de este mecanismo de asignación de
direcciones da lugar a la construcción de dos árboles:
- un árbol jerárquico de puentes combinados que
sirve para encaminar tramas destinadas a direcciones jerárquicas MAC
(HLMAC: "Hierarchical Local MAC");
- el árbol de expansión estándar (construido
según el protocolo STP o RSTP) creado para encaminar las tramas
destinadas a direcciones MAC globales (UMAC: "Universal
MAC").
En conjunto, se forma así sin discontinuidad el
árbol de expansión mixto, donde operan entre sí los puentes
combinados y los convencionales, estando los puentes convencionales
conectados como ramas al árbol jerárquico de puentes combinados, en
forma de subárboles en la periferia del árbol de expansión
mixto.
Las direcciones HLMAC son asignadas
automáticamente mediante este mecanismo de asignación de direcciones
que parte del puente raíz del árbol y llega hasta los nodos unidos
a equipos terminales (puentes hoja), asignando bits y máscaras a
los puentes de cada nivel (puentes intermedios y hojas) de acuerdo
al siguiente criterio:
Los puertos de los puentes intermedios y de los
puentes hoja siempre tienen asignados direcciones HLMAC y, por otro
lado, los puertos de los equipos terminales tienen direcciones UMAC,
asignadas de fábrica en sus tarjetas de red o NIC ("Network
Interface Controller" o Controlador de Interfaz de Red, en
español).
Este esquema de direcciones puede integrarse en
un esquema general de direcciones si el puente de red que además
actúa como pasarela a otras redes conmutadas tiene también una
dirección jerárquica en su puerto o puertos de conexión a dichas
redes, la cual sirve como prefijo base de las direcciones en la red
de la que es raíz.
Como coinciden el árbol jerárquico con el
estándar usado para la difusión de tramas con direcciones UMAC, las
reconfiguraciones del árbol de expansión debidas a cambios de
topología pueden acarrear modificaciones en algunas de las
direcciones jerárquicas asignadas. En caso de reconfiguración del
árbol de expansión, la información se transmite de la forma
estándar por todo el árbol y en todas direcciones mediante BPDUs del
tipo conocido como TCN ("Topology Change Notification") así
como en el quinto octeto (campo de banderas o "flags") de esas
BPDUs. Las direcciones jerárquicas HLMAC asignadas son borradas en
todos los puertos o solamente en los puertos afectados por la
reconfiguración. Hasta que los puertos designados no están en rol
designado, no envían las direcciones jerárquicas válidas. Por otro
lado, los procesos de reenvío del protocolo de encaminamiento se
interrumpen de inmediato hasta la estabilidad del nuevo árbol de
expansión y las coordenadas HLMAC. La ventaja del uso de RSTP para
la asignación de direcciones HLMAC y la rapidez de la
reconfiguración del árbol con RSTP es que la obtención de las
direcciones actualizadas resulta muy veloz y el árbol queda
reconfigurado muy rápidamente en un tiempo prácticamente igual al
del tiempo de reconfiguración de RSTP.
Las direcciones globales UMAC aprendidas por un
puerto en un puente combinado se borran de la forma estándar 802.1D
(mediante "MAC flushing").
En todos los puertos del puente combinado se
aceptan y procesan tramas con direcciones UMAC, con objeto de ser
compatibles con los puentes convencionales. Los puentes combinados
participan en el protocolo del árbol de expansión estándar (STP o
RSTP) de dichos puentes convencionales, intentando ser raíz del
mismo. Si no pueden serlo, se convierten en puentes hoja conectados
en el extremo de la red, nunca como nodos intermedios. Esto se
consigue porque los puentes combinados solamente operan con su
información de puerto, no con la información 802.1D recibida por
otros puertos, por lo que nunca actúan como nodo intermedio
difundiendo en sus BPDUs caminos hacia el puente raíz anunciados por
nodos vecinos.
Otra de las ventajas diferenciales de la
propuesta consiste en la compatibilidad completa con los mecanismos
802.1D de difusión y resolución de direcciones. El protocolo
estándar ARP se continúa utilizando para la resolución de la
dirección IP a la dirección MAC, sea ésta global (UMAC) o local
(HLMAC). Las tramas con direcciones UMAC no son modificadas en los
puentes combinados: todos encaminan tales tramas de forma estándar,
salvo los puentes hoja; cada puente hoja conectado mediante enlace
dedicado a un equipo terminal reemplaza la UMAC del terminal al que
está conectado por la HLMAC asignada al puerto donde se conecta. Las
tramas con direcciones HLMAC se envían inalteradas mediante un
encaminamiento jerárquico. Cada puerto de un puente combinado
aprende un par de direcciones HLMAC-UMAC.
En definitiva, los puentes combinados se
comportan de la forma estándar 802.1D en cuanto al aprendizaje de
direcciones MAC origen de las tramas que reciben, con la diferencia
de que solamente se procesan de esta forma estándar las direcciones
MAC globales (UMAC), de grupo de difusión amplia ("broadcast")
y multidifusión ("multicast"), mientras que las direcciones
MAC locales jerárquicas (HLMAC) que se usan en el envío de datos
desde un único emisor a un único receptor ("unicast") son
procesadas por el protocolo de encaminamiento que seguidamente se
describe.
El protocolo de encaminamiento y reenvío
jerárquico arriba-abajo (que a partir de aquí y para
abreviar, se designa con las siglas HURP: "Hierarchical Up/down
Routing Protocol") intercambia/difunde información para
encaminar tramas "unicast" con direcciones destino locales
jerárquicas (HLMAC). Tal información se transporta en unas tramas
BPDU especiales para este protocolo HURP, cuya cabecera contiene la
versión de protocolo que designa el protocolo HURP y el tipo de
mensaje que se está intercambiando, contemplándose los siguientes
tipos de mensajes HURP:
- Mensajes de Petición: enviado por algún
enrutador recientemente iniciado que solicita información de los
enrutadores vecinos.
- Mensajes de Respuesta: mensajes con la
actualización de las tablas de enrutamiento y que, a su vez, pueden
ser de tres tipos:
- Mensajes ordinarios: Se envían cada
1-30 segundos, según la configuración del
administrador de red, para indicar que el enlace y la ruta siguen
activos.
- Mensajes enviados como respuesta a mensajes de
petición.
- Mensajes enviados cuando cambia algún coste de
una ruta y que sólo se envían a través de las rutas en las que ha
cambiado, marcándose en una tabla de encaminamiento las rutas que
han cambiado recientemente.
\vskip1.000000\baselineskip
Cada entrada a la tabla de encaminamiento que
usa el protocolo HURP incluye:
\bullet Distancias conocidas a los puentes
combinados del área, refiriéndose por área al conjunto o dominio de
los puentes combinados (con soporte del protocolo CSTP)
interconectados sin discontinuidad mediante el árbol principal
(CST: "Combined Spanning Tree") que constituye un árbol de
expansión mixto (de puentes combinados y puentes
convencionales).
\bullet Puerto de salida hacia puentes
destino.
\bullet Dirección RSTCA del puente combinado
de siguiente salto hacia destino.
\bullet Coordenada RSTAA del puente
destino.
Con la misma periodicidad que se intercambian
las BPDUs según el protocolo estándar, los puentes combinados
envían periódicamente, aparte de las BPDUs CSTP, BPDUs con el valor
correspondiente al protocolo HURP en el campo tipo de la trama
Ethernet (en vez del valor 0x42 h correspondiente al protocolo de
árbol de expansión estándar) y conteniendo las rutas que el puente
difunde a cada uno de sus vecinos. Solamente los puentes combinados
vecinos inmediatos las procesan. Los puentes convencionales (que
siguen el estándar 802.1D ejecutando STP o RSTP) descartan este
tipo de tramas BPDUs HURP. Transcurrido un tiempo sin escuchar
tramas HURP, el puerto de un puente HURP no conectado a ningún otro
puente HURP, deja de transmitirlas.
El descubrimiento de los vecinos HURP
complementa el conocimiento de direcciones jerárquicas que cada
puente combinado tiene por formar parte del árbol de expansión
creado por el protocolo CSTP. Este conocimiento debido a CSTP se
limita a su puente designado (antecesor en el árbol) y a sus puentes
dependientes.
La reconfiguración en una red con HURP puede
producirse por una caída de un enlace de árbol. En este caso se
produce reconfiguración del árbol y debe elegirse nuevo puerto
designado y raíz. 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 o
"flags" de la BPDU de CSTP, de manera similar a RSTP, produce
el borrado de las direcciones HLMAC y de las tablas de
encaminamiento en todos los puentes. El borrado tanto de
direcciones como de tablas puede ser total o parcial. Si el borrado
de direcciones HLMAC y de rutas es solamente parcial, es preciso
comunicar a todos los puentes la dirección HLMAC del puente que
conectaba al enlace fallido al árbol. Al recibir cada puente la
notificación de cambio de topología, borra las rutas y direcciones
HLMAC y bloquea el envío de tramas de usuario hasta que se habilite
al menos el árbol de expansión. Inicialmente se recomienda el
borrado total de rutas y direcciones al recibir la BPDU con el
cambio de topología. Por otro lado, también es posible la
reconfiguración de la red provocada por la caída de un puente y, 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.
A diferencia del conocido protocolo RIP
(Protocolo de Información de Encaminamiento: es un protocolo de
puerta de enlace interna o IGP utilizado por los enrutadores para
intercambiar información acerca de redes IP), el protocolo HURP
opera sobre direcciones locales jerárquicas (HLMAC), que son de capa
dos de OSI, en vez de sobre direcciones del nivel de red
(direcciones IP: capa tres).
Otra diferencia con respecto al protocolo RIP es
que el protocolo HURP usa una métrica de costes de tipo puente, tal
como la recomendada por IEEE 802.1D. La métrica de un destino se
calcula como la métrica comunicada por un vecino más la distancia en
alcanzar a ese vecino.
El protocolo HURP admite diversas opciones del
algoritmo de encaminamiento configurables que permiten ajustar el
funcionamiento de forma óptima a la red o requisitos del
administrador de la red.
Una opción de configuración del protocolo HURP
consiste en la difusión completa de los vectores distancia
incluyendo los nodos jerárquicamente superiores e inferiores. De
esta forma los costes de las rutas a todos los nodos vía árbol de
expansión son conocidos y comparados con los de los de las rutas que
usan enlaces cruzados o transversales.
Una opción para reducir el número de mensajes
consiste en que el protocolo HURP anuncia una ruta solamente si la
métrica anunciada es menor que el doble de la distancia al puente
raíz del puente que la anuncia. Las rutas pueden tener un tiempo de
vida de 10 segundos. Si pasado este tiempo, no se han recibido
mensajes que confirmen que esa ruta está activa, se borra.
Otra opción se deriva de que el anuncio de
direcciones HLMAC, de tipo prefijo, permite asimismo la reducción
opcional de mensajes por anunciar implícitamente rutas agregadas en
forma de subárboles completos y sus subárboles alcanzables, si bien
la distancia anunciada no coincidirá exactamente con la del terminal
destino, por lo que son necesarios criterios y parámetros
opcionales a configurar o asumir por defecto para la estimación de
la distancia restante hasta el destino final en función de la
diferencia de niveles jerárquicos entre el destino final y la ruta
anunciada. Esta opción tiene importancia dado que en las redes
Ethernet actuales, dada su alta velocidad, la métrica o distancia
relativa entre ruta vía árbol de expansión o alternativa puede ser
secundaria frente a la ventaja principal de una mayor utilización de
la infraestructura de red.
Una diferencia más del protocolo HURP comparado
con RIP es que HURP aplica por defecto un encaminamiento a través
del árbol jerárquico construido por CSTP (el árbol formado por todos
los puentes combinados, con las direcciones HLMAC asignadas) y
aprovecha así el direccionamiento jerárquico para disponer siempre
de ruta por defecto en caso de reconfiguración o fallos de
encaminamiento. Asimismo permite opcionalmente reducir el número de
rutas intercambiadas. Es decir, HURP encamina por las ramas
transversales de manera complementaria al árbol jerárquico, sólo
cuando las rutas transversales son ventajosas (su coste calculado es
menor o igual que la ruta por defecto a través del árbol jerárquico
o de una estimación de dicho coste). Por lo tanto, el anuncio de
rutas transversales por el protocolo HURP está condicionado a la
probabilidad de que la ruta anunciada sea ventajosa o al menos
equivalente a la ruta por el árbol jerárquico.
Las rutas difundidas a cada vecino pueden
diferir para satisfacer las siguientes condiciones:
- Condición de Horizonte Dividido: No difundir
al vecino las rutas aprendidas de él.
- Condición de Giros prohibidos: No difundir al
vecino rutas que supongan un giro prohibido en la red al ser
utilizadas por dicho vecino.
Son posibles diferentes esquemas en cuanto a la
difusión que puede hacer el protocolo HURP de rutas alternativas a
las intercambiadas del árbol de expansión. Una alternativa de
realización de la difusión de rutas consiste en que cada nodo,
antes de difundir la ruta a un vecino, al igual que con el horizonte
dividido, suprime del anuncio las rutas cuyo siguiente salto supone
un giro prohibido desde el nodo receptor de la ruta (yendo a través
del nodo que anuncia la ruta). Esto elimina las rutas posibles a
algunos nodos, pero resulta en un mejor compromiso, preferible a
anunciar todas las rutas y que, llegada la trama al nodo, encuentre
el giro de su siguiente salto como prohibido y tenga que ascender
por el árbol, utilizando en la práctica una ruta más larga. Este
mecanismo de ascenso por el árbol en ausencia de ruta es importante
para la robustez del encaminamiento.
Las similitudes de HURP con el protocolo RIP son
los tipos de mensaje definidos (mensaje de petición y los distintos
tipos diferenciados de mensaje de respuesta) y que las rutas a
subredes se difunden a cada vecino (como se hace actualmente en la
versión RIPv2). En el caso de HURP, las rutas vienen representadas
por los subárboles que se agregan jerárquicamente con arreglo a las
coordenadas RSTAA y tienen significado topológico.
Puesto que el protocolo HURP se basa
principalmente en el algoritmo de vector de distancias usado por el
protocolo RIP, esto lo diferencia del protocolo RSJ usado en UETS y
que está inspirado en el protocolo STAR citado en los
antecedentes.
Las propiedades de jerarquización de HURP
mejoran la escalabilidad y su algoritmo de vectores distancia
favorece la simplicidad y robustez. Otras ventajas de este
protocolo son que permite utilizar enlaces entre puentes combinados
que no forman parte del árbol de expansión (i.e., enlaces
transversales), cuando su coste es inferior al coste exacto o
estimado del camino por el árbol de expansión, permitiendo la
utilización completa de la infraestructura de red. Además, los
enlaces redundantes entre puentes de un nivel y los del inmediato
superior e inferior, que normalmente son desactivados por el
protocolo de árbol de expansión, pueden ser utilizados por HURP
aumentando el rendimiento y utilización de la red. Otro beneficio es
que HURP usa una tabla jerarquizada en vez de una tabla de
distancias plana, lo que permite disponer de rutas alternativas de
forma simple.
El protocolo HURP puede operar aplicando
diversos mecanismos de encaminamiento: vertical, transversal a
puente vecino y transversal distante, que se definen como sigue.
El encaminamiento vertical que realiza HURP por
defecto utiliza el árbol jerárquico de direcciones creado: la trama
se encamina desde el terminal origen hacia arriba hasta alcanzar, si
es posible, un puente cuya dirección es el prefijo común a las
direcciones HLMAC origen y destino. La dirección del puente
combinado donde el protocolo HURP debe realizar el giro de arriba
hacia abajo se obtiene extrayendo el prefijo común entre las
direcciones HLMAC origen y destino. Si no existe este último
prefijo común, la trama asciende hasta el puente raíz del árbol
(que siempre es un puente combinado) y desciende por la rama
correspondiente hasta su destino. Este encaminamiento vertical
sigue pues las pautas del protocolo estándar STP, pero sin necesitar
difusión de las tramas ni aprendizaje de las direcciones MAC
empleadas (jerárquicas).
El encaminamiento transversal a puente vecino
se produce cuando existe un enlace entre dos puentes que no
pertenece al árbol de expansión, es decir, si hay un enlace
transversal que une un puente con uno vecino, HURP puede encaminar
la trama de usuario recibida, al llegar a uno de estos puentes, a
través del enlace transversal con el vecino. Este enlace o camino
transversal se usa sólo en caso de que la distancia calculada para
esa ruta transversal sea menor o igual que la distancia a través
del puente raíz (esta última es la distancia de la ruta que se usa
por defecto, según el encaminamiento vertical).
También es posible otra forma de encaminamiento
transversal de una trama, que se denomina encaminamiento transversal
distante, cuando hay puentes intermedios que unen mediante enlaces
transversales el origen y destino de la trama. La utilización de
vectores distancia permite calcular las rutas óptimas a los puentes
y determinar si son vía árbol o por enlaces transversales.
Adicionalmente, el protocolo HURP utiliza
mecanismos de prohibición de giros para evitar los bucles de tramas
debidos a inconsistencia temporal de las tablas de encaminamiento
creadas en los puentes combinados. La utilización de las
coordenadas jerárquicas RSTCA para el control de los giros evita la
necesidad de ejecutar un algoritmo en la red que determine los
giros permitidos y prohibidos, realizándolo cada nodo de forma
independiente a partir de su dirección RSTCA, los nodos anterior y
siguiente de la ruta y las direcciones origen y destino de la trama
en algún caso. Los puentes impiden ejecutar los giros prohibidos a
las tramas de usuario aunque la ruta que tienen en tabla sea
óptima.
Puesto que el protocolo HURP asigna las
identidades de nodo mediante el protocolo estándar de árbol de
expansión, la identidad del nodo/puente raíz es siempre la menor, lo
que garantiza una efectividad alta en la prohibición de giros.
El direccionamiento jerarquizado del protocolo
HURP le confiere, frente al encaminamiento arriba/abajo clásico,
mayor capacidad de discernir entre los tipos de giros, introduciendo
el concepto de enlace horizontal, permitiendo algunos giros que el
encaminamiento arriba-abajo up/down prohíbe, como
son los giros horizontal-arriba (estos últimos
serían considerados abajo-arriba y, por tanto, giros
prohibidos si no se utilizaran direcciones jerárquicas para
identificar los puentes combinados). Se entiende por enlace
horizontal (o transversal), el que va de un nodo a otro del mismo
nivel en el mismo árbol de expansión.
Gracias a esto es posible reducir los giros
prohibidos a giros abajo-arriba estrictos y
horizontal-horizontal permitiendo los giros
horizontal-arriba. De esta manera, mientras que en
HURP cuando el primer enlace es transversal se permite el giro, en
el encaminamiento arriba/abajo clásico, donde el giro solamente
puede ser arriba-abajo o
abajo-arriba, el giro resulta estar prohibido en la
mitad de los casos. Por otro lado, HURP permite establecer
mecanismos de encaminamiento arriba/abajo más complejos que en el
clásico, tales como encaminar hacia la rama del árbol de expansión
destino en vez de al nodo destino estrictamente, lo que aumenta su
flexibilidad y robustez de encaminamiento.
Las principales diferencias del protocolo HURP
con respecto al encaminamiento "jerárquico" que existe en UETS
son:
- El protocolo "jerárquico" de UETS es el
conocido como "micro-routing" (encaminamiento
clásico basado en tablas entre puertos unidos por enlaces que no
pertenecen a la topología jerárquica). En UETS se usa en
conmutadores aplicables a diversas topologías arbitrarias de red
mediante la combinación de la conmutación Banyan (con arquitectura
multietapa "self-routing") y el denominado
"micro-routing" utilizado en las líneas de
conexión transversales de la red.
- En UETS se contempla un conmutador único en
los casos más simples, que opera de una forma combinada, pero entre
redes disjuntas: una red formada por los puentes especiales de UETS
y otra red de puentes convencionales 802.1D.
- En el aquí llamado árbol jerárquico combinado
(CHT) el encaminamiento por las ramas jerárquicas utiliza tanto el
árbol de expansión (STP ó RSTP), para tramas con MAC destino global
(UMAC), como el protocolo jerárquico (HURP), para tramas con MAC
destino local jerárquica (HLMAC).
El problema de interoperabilidad de entre los
dos dominios de direcciones Ethernet (Ethernet estándar y UETS) se
resuelve aquí mediante un escenario totalmente compatible donde
co-existen puentes de red que utilizan la pila de
protocolos TCP/IP/Ethernet estándar en redes mixtas 802.1D con
puentes combinados de funcionalidad simultánea 802.1D y Ethernet
jerárquica. El protocolo CHT construye un árbol con los puentes
combinados al que se conectan árboles de expansión estándar 802.1D,
formando por tanto un árbol de expansión estándar extendido.
Solamente cada puente raíz de un árbol de puentes convencionales
puede unirse a un árbol jerárquico como el que existe en UETS, por
lo que se unen completamente como subárboles, de 1 a N puentes cada
subárbol. Se utiliza el árbol de expansión en el dominio UETS, no
empleado en el modo nativo UETS, combinando regiones UETS y 802.1D
libremente mezcladas, siempre que el árbol UETS no se fragmente, en
cuyo caso se toman tantas regiones como número de subárboles UETS.
Los "árboles gruesos" Ethernet de agregación de tráfico ("fat
tree", en inglés), con tasas de transmisión de 10 Mbps, 100
Mbps, 1 Gbps y 10 Gbps son más efectivos que las redes en malla
convencionales para tráfico de agregación, por lo que esta
topología de árbol presenta alta eficacia.
Los dos protocolos descritos, CSTP y HURP,
pueden implementarse como uno solo o bien de forma separada. En el
caso de implementarse como uno solo, las funciones de creación y
mantenimiento del árbol de puentes combinados, asignación y
reasignación de direcciones HLMAC y encaminamiento se integran
funcionalmente entre sí, lo que permite variantes de funcionamiento
y encaminamiento más integrado.
Otro aspecto de la invención se refiere a un
dispositivo de interconexión de subredes (el aquí llamado puente
combinado) que opera en el nivel de enlace de datos (capa 2) según
el protocolo de red que crea el árbol de expansión mixto descrito
anteriormente. 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 HURP. Opcionalmente, puede añadirse un tercer
modo de funcionamiento que incluye encaminamiento del Protocolo de
Internet (IP). Este dispositivo de puente de red es pues
interoperable con funcionalidad extendida de: conmutador Ethernet
transparente, de conmutador/enrutador basado en direcciones
jerárquicas locales Ethernet y enrutador basado en direcciones
IP.
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 combinados 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.
Resumidamente, las ventajas de la invención
sobre el estado de la técnica anterior son:
- -
- Frente a UETS, MSTP y la propuesta de IEEE en el año 2005 bajo el nombre "Shortest Path Bridging" (http://www.ieee802.org/802_tutorials/july05/nfinn-shortest-path-bridging.pdf): el protocolo CHT y, por tanto, el puente combinado que se propone es autoconfigurable.
- -
- Frente a MSTP, "Shortest Path Bridging" y enrutadores: el puente combinado tiene una estructura simple y su construcción resulta económica, pues usa hardware estándar y es migrable vía software.
- -
- Frente a 802.1D: los puentes combinados hacen una completa utilización de la red sin enlaces deshabilitados, mediante el uso de los enlaces transversales en el encaminamiento transversal jerárquico.
- -
- Frente al encaminamiento arriba-abajo clásico: el direccionamiento jerárquico que usa la invención permite un encaminamiento más preciso y evita bucles de una forma más simple, prohibiendo los giros abajo-arriba y permitiendo saltos de un puente a otro con un prefijo menor.
- -
- Alta escalabilidad sin uso de encapsulado adicional de tramas.
\global\parskip0.930000\baselineskip
- -
- Mantenimiento de los mecanismos estándar de difusión ("broadcast") y multidifusión ("multicast") 802.1D en capa dos de OSI.
- -
- Compatibilidad con el protocolo ARP estándar para la resolución de direcciones IP a jerárquicas UMAC; frente a UETS que precisa servidores de nombres eDNS ("Enhanced Domain Naming System").
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 una representación
esquemática de un ejemplo de 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 2.- Muestra una representación
esquemática del árbol de expansión CST que, partiendo de la red de
la figura anterior, se crea según una realización preferida de la
invención.
La figura 3.- Muestra el formato de una trama
BPDU usada por el protocolo de creación y mantenimiento de un árbol
de expansión, tal como el de la figura anterior, de acuerdo a una
realización preferida de la invención.
La figura 4.- Muestra un ejemplo de asignación
jerárquica de direcciones en el árbol de expansión creado según una
realización preferida de la invención.
La figura 5.- Muestra un ejemplo de resolución
de direcciones mediante el protocolo ARP en el árbol de expansión
jerárquico creado según una realización preferida de la
invención.
La figura 6.- Muestra el formato de una trama
BPDU, conteniendo información de rutas, usada por el protocolo de
creación y mantenimiento de un árbol de expansión, tal como el de la
figura anterior, de acuerdo a una realización preferida de la
invención.
La figura 7.- Muestra un diagrama de bloques del
proceso de reenvío de tramas que se ejecuta en un puente combinado
según una realización preferida de la invención.
La figura 8.- Muestra un ejemplo de
encaminamiento de tramas en el árbol de expansión, creado según una
realización preferida de la invención, usando los enlaces
(verticales) establecidos por defecto en dicho árbol.
La figura 9.- Muestra un ejemplo de
encaminamiento de tramas en el árbol de expansión, creado según una
realización preferida de la invención, usando los enlaces
(transversales) que no pertenecen a dicho árbol entre nodos
vecinos.
La figura 10.- Muestra un ejemplo de
encaminamiento de tramas en el árbol de expansión, creado según una
realización preferida de la invención, usando los enlaces
(transversales) que no pertenecen dicho árbol entre nodos
intermedios vecinos.
La figura 11.- Muestra un ejemplo de
encaminamiento de tramas en el árbol de expansión, creado según una
realización preferida de la invención, usando prohibición de
giros.
Puede describirse una realización preferida de
la invención como un protocolo de red del nivel de enlace de datos
o capa dos, aplicable a una red de telecomunicaciones, como puede
ser una red campus, representada en la Figura 1 mediante un árbol o
grafo, donde los nodos en blanco corresponden a puentes de red
convencionales, configurados bajo el estándar 802.1D, mientras que
los nodos en gris son puentes de red que operan mediante el
protocolo que aquí se propone y denominados para su distinción
respecto a los convencionales como puentes combinados. Este
protocolo de capa dos, designado para abreviar por las siglas CHT
antes explicadas, a su vez, comprende dos protocolos:
- Protocolo CSTP: protocolo de creación y
mantenimiento de un árbol de expansión mixto compuesto por puentes
convencionales y puentes combinados.
- Protocolo HURP: protocolo de encaminamiento y
reenvío jerárquico arriba-abajo.
Conceptualmente, un puente combinado puede verse
como un encaminador de tramas con direcciones Ethernet locales
jerárquicas que incorpora la funcionalidad estándar de un puente
convencional.
\global\parskip1.000000\baselineskip
En la red ejemplo de la Figura 1, se muestran
una serie de puentes combinados (R, B1, B2, B3, B4,...) de la que
es elegido un puente raíz (R) suponiendo que, por configuración de
la prioridad de los puentes, convencionales y combinados, 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,
y
- el árbol de expansión de los puentes
combinados, formado por los nodos en gris conectados por enlaces
representados con línea gruesa.
Los enlaces entre nodos representados en la
Figura 2 con línea discontinua corresponden a caminos bloqueados
por el protocolo estándar 802.1D, mientras que los representados con
línea punteada son enlaces que sirven como caminos útiles para el
protocolo de encaminamiento de los puentes combinados. En este árbol
de expansión mixto formado, los puentes combinados pueden emplear
todos los enlaces que les interconectan para encaminar tramas,
además de los caminos del árbol jerárquico construido exclusivamente
con dichos puentes combinados. En las hojas del árbol de expansión
mixto sólo hay nodos que operan en modo estándar, ya sean puentes
convencionales o ya puentes combinados funcionando según el
protocolo 802.1D, dibujados estos últimos en la Figura 2 como nodos
grises con un círculo interior en blanco, por ejemplo, es el caso
del puente combinado B4.
Los puentes combinados 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, según se ilustra con un ejemplo en la
siguiente tabla:
En el primer octeto, número 0, de la dirección
MAC, el estándar 802.1D estable que el primer bit transmitido en la
red indica:
si el valor es cero, que se trata de una
dirección individual o "unicast";
si el valor es uno, que se trata de una
dirección de grupo o "multicast".
En el primer octeto, número 0, de la dirección
MAC, el estándar 802.1D estable que el segundo bit transmitido en la
red indica:
si el valor es cero, que se trata de una
dirección universal o global;
si el valor es uno, que se trata de una
dirección local.
Dentro de la trama Ethernet estándar, el
protocolo CHT hace una asignación de las direcciones MAC origen y
destino locales de forma jerárquica según una de las siguientes dos
alternativas:
a) Sin longitud explícita de prefijo: El primer
bit transmitido en la red contiene el valor estándar para
direcciones individuales y el segundo bit contiene el valor estándar
para direcciones MAC locales. Se usa la identidad de puerto cero
para indicar la terminación de la dirección jerárquica dentro de los
48 bits de la dirección MAC, por lo que empezando por la derecha en
la siguiente tabla los octetos a cero indican que la dirección es
más corta que los 6 octetos disponibles para niveles de
direccionamiento; son pues octetos cuyo valor no tiene significado
de dirección:
\newpage
En la tabla anterior se representa la dirección
MAC de valor 5.140.51.195.60, que corresponde a un direccionamiento
de cinco niveles, por lo que el último octeto, correspondiente a un
nivel 6 se pone todo a cero. El primer octeto tiene los dos
primeros bits asignados con los valores estándar comentados y los
restantes bits se usan para un nivel 1 de la dirección MAC. Esta
alternativa ofrece mayor sencillez de direccionamiento y mayor
rango, aunque modifica la equivalencia de las identidades de puerto
del protocolo 802.1D, rango que comienza en cero. Por ello, se
aumenta en uno para obtener la identidad de puerto equivalente en el
protocolo CHT y se reduce una unidad el número de puertos máximo
por puente de red a 255 puertos, es decir, se usa el rango
1-255 en vez de 0-255.
b) Longitud explícita: En el primer octeto, tras
el primero y el segundo bits transmitidos indicando que se trata de
una dirección individual y dirección MAC local respectivamente, se
utiliza los 3 siguientes bits de dicho primer octeto para indicar
el número de niveles o longitud en campos de la dirección
jerárquica, proveyendo de 0 a 7 niveles disponibles. El resto de
bits, bit cuarto a octavo, del primer octeto se usan como nivel 1
de la dirección MAC local. En este caso el número máximo de puertos
en los conmutadores se limita a 256, en el rango de 0 a 255, de
forma general y, de forma particular, a 8 puertos en el primer nivel
o nivel 1. La ventaja es que el número de niveles es fácilmente
configurable. Un ejemplo de esta alternativa se da en la siguiente
tabla:
\vskip1.000000\baselineskip
En la tabla anterior se representa la dirección
MAC de valor 5.140.51.195.60, con cinco niveles, por lo que en el
primer octeto se especifica que la longitud es 5 en un campo
longitud de dirección formado por los bits subrayados en la
tabla.
El mecanismo de asignación jerárquica de
direcciones aprovecha la construcción del árbol de expansión
estándar, de forma que el protocolo de árbol de expansión STP/RSTP
se extiende incorporando tras el último octeto de una BPDU estándar
6 octetos más, que contienen el prefijo o dirección del puerto raíz
del puente destinatario de la BPDU. La Figura 3 ilustra la trama
que constituye esta BPDU, indicando a la derecha el número de
octeto. Los octetos 36-41 contienen la dirección
MAC local correspondiente a un puerto designado para conectar un
puente combinado dado con un vecino, que se construye siguiendo el
formato explicado anteriormente, bien según la alternativa de
longitud explícita o bien sin longitud explícita de prefijo. El
puente combinado dado transmite a todos sus vecinos una BPDU
correspondiente a cada puerto designado. Los vecinos reemplazan los
6 últimos octetos de la BPDU con el valor de la dirección MAC local
que corresponde a cada uno de sus respectivos puertos designados y
así, sucesivamente, se van intercambiando este tipo de BPDUs,
durante la operación del protocolo CSTP y una vez formado el
STP/RSTP, para formar el árbol jerárquico.
La Figura 4 ilustra cómo resulta la asignación
jerárquica de direcciones, 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 4 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, 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, 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
combinado están conectados a un solo equipo terminal, el puerto
terminal designado realiza la sustitución de la dirección MAC global
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. En las tramas de vuelta hacia el
equipo terminal se realiza la sustitución inversa, reinsertando la
dirección MAC global 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 global o
local jerárquica. En la Figura 5 se muestra un ARP de un equipo
terminal (e2) para resolver la dirección MAC de otro equipo
terminal (e1) y cómo el equipo e2 obtiene la dirección MAC local
jerárquica de e1 para poder utilizar después el encaminamiento
jerárquico HURP.
El proceso detallado de resolución de
direcciones mediante ARP, realizado para obtener las direcciones MAC
locales jerárquicas a partir de la dirección IP destino, se
representa en la Figura 5 señalando mediante unas flechas (m1, m2,
m3) la secuencia de mensajes intercambiados en este mecanismo. En un
primer intercambio (m1), el equipo terminal e2 envía un mensaje
estándar del protocolo ARP y de tipo "ARP query" con dirección
MAC destino, que constituye la dirección de difusión y dirección
origen, igual al valor de la dirección MAC asignada al equipo
terminal, que en este ejemplo es una dirección MAC global. El
mensaje "ARP query" se transporta en una trama que contiene la
dirección IP destino a resolver, la del equipo e1, junto con la
dirección IP origen, la del equipo e2, difundiéndose esta trama a
lo largo del árbol de expansión por toda la red conmutada de
puentes hasta alcanzar el equipo (e1) destino sin ser modificada.
Este equipo (e1) destino procesa de forma estándar el mensaje
"ARP query" e inicia un segundo intercambio (m2) respondiendo
con un mensaje estándar de tipo "ARP reply" que contiene la
dirección MAC global de este equipo (e1). El puente H1 conectado por
un puerto terminal al equipo e1 recibe la trama con el mensaje
"ARP reply" y reemplaza la dirección MAC global por la
jerárquica local correspondiente a ese puerto terminal designado,
además de recalcular el CRC de la trama para que sea correcto. La
trama tiene como dirección destino la MAC del equipo e2, que puede
ser global o local, y que se supone global en este ejemplo. La
trama se reenvía por el árbol de expansión hasta el equipo e2, que
la guarda en su caché ARP, con lo que e2 dispone de la dirección
jerárquica MAC del equipo e1 para el envío de cualquier trama. Por
último, como tercer intercambio (m3), el equipo e2 envía tramas
"unicast" al equipo e1 con la dirección MAC destino
obtenida.
El protocolo HURP de encaminamiento jerárquico
opera solamente sobre las tramas con direcciones destino MAC
locales. A continuación se describe un seudocódigo simplificado del
reenvío de tales tramas que realiza HURP, donde se analiza la
dirección MAC local jerárquica destino:
\vskip1.000000\baselineskip
El formato de las tramas BPDUs que maneja el
protocolo HURP es el mostrado en la Figura 6, que tiene una cabecera
que incluye los campos, en este orden, para: el identificador
correspondiente al protocolo HURP, la versión del protocolo HURP y
el tipo de mensaje o comando. Tras la cabecera, esta BPDU contiene
un máximo de 20 entradas de 18 octetos cada una que definen las
posibles rutas con los siguientes campos, en este orden:
- -
- "dirección RSTCA_{i}" de cada puerto designado (i= 1, 2...) que indica la dirección MAC local jerárquica destino, con el formato de 6 octetos y con o sin su longitud de prefijo explícita;
- -
- "longitud de prefijo" que indica, en 1 octeto, la longitud en bits de la parte más significativa, i.e., el prefijo, de la dirección MAC local jerárquica indicada;
- -
- "etiqueta de ruta" que permite identificar, en 1 octeto, orígenes diferentes de las rutas;
- -
- "siguiente salto" contiene la dirección RSTCA del puente siguiente en la ruta;
- -
- "métrica", utilizando la misma métrica el protocolo HURP que el estándar 802.1D para poder elegir caminos ventajosos alternativos al árbol de expansión e indicando la dirección propia como una ruta más con distancia nula.
El protocolo HURP extiende el protocolo RIP con
las direcciones asignadas jerárquicamente y usa una métrica de
costes de tipo puente estándar IEEE 802.1D, donde el vector de
distancia de un enlace es inverso a la velocidad de transmisión en
dicho enlace. La ruta o el camino más corto hacia la red de destino
es establecida por el protocolo HURP usando por defecto el mismo
algoritmo del vector de distancias que para los puentes
convencionales, calculando la distancia como una constante dividida
por la capacidad del enlace en bits por segundo. La siguiente tabla
reproduce los costes de enlace recomendados por el estándar IEEE
802.1D:
El reenvío de las tramas con direcciones MAC
locales destino "unicast" que hace el protocolo HURP se muestra
en la Figura 7, según los siguientes pasos:
Tras la recepción de las tramas (S1), el
protocolo HURP determina las tramas para el encaminamiento
jerárquico (S) teniendo en cuenta la información de rutas extraída
de la base de datos de encaminamiento (DB1) definida en el puente.
Simultáneamente, 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 la
base de datos de filtrado (DB2) configurada en el puente. Tanto las
tramas filtradas en (S3) como las del encaminamiento jerárquico (S)
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) para luego establecer un mapeo de las prioridades
(S6). Antes de efectuar la transmisión de esas tramas (S8), se hace
una comprobación de dichas tramas para detectar errores (S7),
recalculando el campo FCS: "Frame Check Sequence".
El protocolo HURP sigue por defecto un esquema
de encaminamiento vertical que utiliza el árbol jerárquico de
direcciones creado: la trama se encamina desde el origen hacia
arriba a lo largo del árbol jerárquico hasta alcanzar, si es
posible, un puente combinado cuya dirección es el prefijo común a
las direcciones HLMAC origen y destino. Para obtener ese prefijo
común a ambas y, por tanto, la dirección del puente donde realizar
un giro de arriba hacia abajo, se realiza una operación lógica AND
entre las direcciones MAC origen y destino locales; en el ejemplo
del árbol jerárquico mostrado en la Figura 8:
- (32.7.6.5.1) AND (32.7.1.6) = 32.7
La Figura 8 muestra la ruta, representada por
una flecha discontinua, que sigue una trama que parte de un equipo
terminal origen (O), cuya dirección MAC local jerárquica es
32.7.6.5.1, hasta llegar a un equipo terminal destino (F), siendo
en el ejemplo 32.7.1.6 la dirección MAC local destino. El árbol
jerárquico de la Figura 8 tiene un puente raíz (R) y tres puentes
hoja (H1, H2, H3), donde el puente raíz (R) se supone tiene un
prefijo con valor igual a 32. En este ejemplo el equipo terminal
origen (O) está conectado al primer puente hoja (H1). La dirección
MAC local jerárquica del puente combinado H1 es 32.7.6.5 y su puerto
designado para conectarse al equipo terminal O tiene un
identificador cuyo valor es 1, i.e., 0001 en binario. Por
consiguiente, la dirección MAC local origen, asignada al equipo
terminal O y que reemplaza su dirección MAC universal en el
encaminamiento, es 32.7.6.5.1. Siguiendo la misma asignación
jerárquica y resolución de direcciones, la dirección MAC local
jerárquica del equipo terminal destino (F) es 32.7.1.6, pues está
conectado por un puerto designado con identificador de valor
binario 0110 al segundo puente hoja (H2) que, a su vez, se conecta
por el puerto designado de identificador 0001 de un puente
intermedio (BR1) de dirección MAC local 32.7. Este puente BR1 es el
puente combinado común entre los puentes hoja H1 y H2, donde el
protocolo de encaminamiento realiza el giro de
arriba-abajo.
Adicionalmente, el protocolo HURP puede realizar
un encaminamiento transversal usando los enlaces que quedan fuera
del árbol jerárquico establecido. Este encaminamiento transversal
puede producirse entre puentes vecinos directos, como se ilustra en
la Figura 9, o bien a través enlaces transversales entre puentes
intermedios, como se ilustra en la Figura 10.
La Figura 9 muestra la ruta, representada por
una flecha discontinua, que sigue una trama que parte de un equipo
terminal origen (O'), cuya dirección MAC local jerárquica es
32.7.6.5.1, hasta llegar a un equipo terminal destino (F'), siendo
en el ejemplo 32.7.1.5.0.0 la dirección MAC local destino. La trama
enviada por el equipo terminal origen (O') conectado al puerto
32.7.6.5.1, al entrar en el primer puente hoja (H1) con dirección
MAC local 32.7.6.5, sustituyéndose entonces en la trama la dirección
MAC origen global por la jerárquica 32.7.6.5.1. Este puente hoja
(H1) conoce que existe un enlace transversal (A1) que lo conecta a
un puente vecino (BR2) de dirección MAC jerárquica igual a
32.1.5.0. Puesto que la distancia a dicho puente vecino (BR2), en el
ejemplo, es k veces inferior, siendo k configurable, con un valor
típico entre 1 y 3, a la distancia al puente raíz (R), encamina la
trama por el enlace transversal (A1), que llega al puente vecino
(BR2) y de ahí hasta el puerto destino correspondiente,
reemplazando la dirección MAC local en la trama con la dirección MAC
global del equipo terminal destino (F').
Aparte del encaminamiento transversal a un
puente vecino, como en el caso anterior, también puede hacerse un
encaminamiento transversal distante usando puentes intermedios, como
es el caso mostrado en la Figura 10. La Figura 10 muestra la ruta,
representada por una flecha discontinua, que sigue una trama que
parte de un equipo terminal origen (O''), cuya dirección MAC local
jerárquica es 32.7.6.5.1, hasta llegar a un equipo terminal destino
(F''), siendo en el ejemplo 32.7.1.5.0.0 la dirección MAC local
destino. El primer puente hoja (H1) conoce que hay un puente
intermedio (BR3) que permite una ruta ventajosa, encaminando la
trama por el enlace transversal (A2) existente entre dichos puentes
H1 y BR3, para continuar el camino por otro enlace transversal A3
que conecta dicho puente intermedio (BR3) hasta alcanzar el puente
BR2 conectado al equipo terminal destino (F'').
La Figura 11 representa una red con nodos
escalonados jerárquicamente según sus coordenadas RSTCA,
representadas encima de cada nodo junto a la letra de referencia
usada. El puente raíz (R) es el origen de coordenadas del que parte
el protocolo HURP para determinar una serie de giros permitidos y
prohibidos.
En el protocolo HURP, al igual que en otros
protocolos de prohibición de giros, la prohibición sirve para
evitar los bucles de las tramas de usuario durante la convergencia
del protocolo. El protocolo del árbol de expansión estándar, STP o
RSTP, garantiza de por sí la ausencia de bucles durante la
convergencia del mismo mediante el bloqueo de los puertos de los
puentes de red que pueden crear bucles, incluyendo todos los puertos
designados, que se bloquean, y los que se bloquean por el propio
protocolo. Pero el protocolo de vector distancias complementario
utiliza los enlaces transversales y puede presentar, durante la
operación normal del protocolo de árbol de expansión estándar,
bucles transitorios durante su convergencia, por lo que la
prohibición de giros es necesaria porque permite evitar los bucles
transitorios de las tramas de usuario.
Existen diversas alternativas en cuanto a reglas
e implementación de la prohibición de giros que, según las
implementaciones del protocolo HURP, pueden ser configurables o bien
producir variantes del protocolo adecuadas a determinadas redes en
función de su topología y de los requisitos del administrador de
red. Aquí se describen las alternativas de prohibición de giros
como estándar, estricta, laxa y encaminamiento hasta la rama
destino.
En la alternativa estándar, el protocolo HURP
utiliza el criterio estándar de TP para determinar si un giro es
arriba o abajo, comparando los identificadores de los tres nodos del
giro, de forma que el giro es prohibido si es
abajo-arriba, por ejemplo el giro formado por los
tres nodos (i,c,d), esto es: si c > i y c > d. Como HURP
emplea los identificadores jerárquicos HLMAC, la comparación de los
mismos consiste en comparar primero las longitudes de prefijos,
resultando mayor en la comparación el nodo de mayor longitud de
prefijo. En caso de igual longitud de prefijo se comparan de modo
iterativo las magnitudes del prefijo empezando por el campo más
significativo, esto es empezando por la izquierda. En caso de empate
se comparan las magnitudes del siguiente campo HLMAC y así
sucesivamente. En la figura 11, según este criterio resultan, por
ejemplo, los identificadores de nodo c < e y f > i.
Además de la alternativa estándar, el protocolo
HURP, por la utilización de los identificadores jerárquicos HLMAC,
introduce un tipo alternativo de enlace en los protocolos de
prohibición de giro: el enlace horizontal (el que une puentes con
igual longitud de prefijo). El enlace de tipo horizontal, al
combinarse con enlaces de tipo arriba, horizontal y abajo, hace
posible distinguir giros prohibidos de tipos adicionales.
Mientras que en el clásico encaminamiento
arriba-abajo los giros posibles son solamente de
tipo arriba-abajo y abajo-arriba,
porque los identificadores carecen de nivel jerárquico, estando pues
prohibidos los abajo-arriba, en HURP los giros
prohibidos básicos son: abajo-arriba, por la misma
norma del encaminamiento arriba-abajo;
abajo-horizontal, porque seguido de un
horizontal-arriba resultaría en un giro equivalente
abajo-arriba; y
horizontal-horizontal porque pueden crearse bucles
horizontales. Todos los demás giros son permitidos, incluido el
abajo-abajo y el arriba-abajo fuera
del árbol. Ejemplos de giros permitidos en todos los casos en el
árbol jerárquico de la Figura 11 son los que se dan a continuación,
indicando en la columna de la izquierda las referencias dadas a los
nodos del árbol dibujados en la Figura 11:
- a-b-f
- permitido por ser ascendente
- h1-a-b
- permitido por ser ascendente
- a-b-c
- permitido por ser horizontal-arriba
- h1-a-j
- permitido por ser horizontal-arriba
- b-c-d
- permitido por ser horizontal-arriba
- c-e-h
- permitido por ser horizontal-abajo
- e-h-h2
- permitido por ser horizontal-abajo
- e-g-h
- permitido por ser horizontal-abajo
- a-j-c
- permitido por ser horizontal-arriba
- b-c-i
- permitido por ser horizontal-arriba
- h1-j-h2
- permitido por ser arriba-abajo
\vskip1.000000\baselineskip
Se puede pues realizar en HURP una prohibición
de giros estricta que permite simplificar la ejecución de la
prohibición de giros al no ser preciso analizar campos de cada trama
de usuario como la dirección destino. Pero también es posible con
HURP realizar una prohibición de giros laxa con la que se persigue
minimizar el número mínimo de giros prohibidos para, por tanto,
maximizar las posibilidades de la trama de alcanzar el destino en
situaciones de inestabilidad de rutas.
Otra posible variante en la versión del
protocolo HURP con prohibición de giros que aquí es denominada
encaminamiento a la rama destino tiene por objetivo maximizar las
posibilidades de alcanzar el destino aún en caso de inestabilidad
de rutas en los nodos. Para ello se intenta maximizar las
posibilidades de alcanzar la rama destino. Se entiende por rama
destino la rama del árbol jerárquico constituida por los superiores
jerárquicos del nodo destino, es decir, los puentes cuyo
identificador HLMAC es un prefijo del identificador HLMAC del puente
destino. Por ello solamente se permite el descenso cuando se ha
alcanzado la rama destino o el giro termina llegando a la misma. No
se permiten los giros arriba-abajo fuera del árbol
para no bajar, sin estar seguros de alcanzar el destino, dado que no
se puede subir en la red una vez que se empieza a bajar.
Ejemplos de giros permitidos y prohibidos en
esta variante de encaminamiento a rama destino son los siguientes
referidos a la Figura 11:
- r-i-c
- abajo-abajo, prohibido por no ser el nodo c de rama destino
- f-i-e
- horizontal-abajo, prohibido por no ser j de rama destino
\vskip1.000000\baselineskip
Ejemplos de giros permitidos y prohibidos en el
árbol de la Figura 11 y sus razones según una versión estricta de
prohibición de giros, con giros prohibidos sin excepciones por
destino, implementada en HURP son los siguientes:
- b-c-e
- prohibido por ser horizontal-horizontal
- c-e-g
- prohibido por ser horizontal-horizontal
- c-e-h
- permitido por ser horizontal-abajo
- r-d-c
- prohibido por ser el nodo d de rama destino (el encaminamiento una vez alcanzada la rama destino debe ir por dicha rama)
- i-c-e
- prohibido por ser abajo-horizontal
- c-j-e
- prohibido por ser abajo-arriba
\vskip1.000000\baselineskip
En la versión del protocolo HURP con prohibición
de giros laxa la prioridad es minimizar el número total de giros
prohibidos, por lo que se hacen excepciones si en el giro se alcanza
la rama destino. Ejemplos referidos a la Figura 11 son:
- d-g-h
- descendente permitido por ser rama destino
- g-h-h2
- descendente, permitido por ser rama destino
- f-r-i
- permitido por ser rama destino
- c-i-e
- arriba-abajo permitido por ser el nodo r de rama destino
- r-i-d
- abajo-horizontal, permitido por ser el nodo d de rama destino
\vskip1.000000\baselineskip
Se entiende por plano de control en los
protocolos de encaminamiento a los mensajes de control del protocolo
intercambiados entre nodos, tales como información de rutas. El
plano de usuario se refiere a las tramas enviadas por los usuarios y
encaminadas por los nodos.
La prohibición de giros se ejercita sobre las
tramas de usuario, evitando que se realicen giros prohibidos en el
plano de usuario. De esta forma se evita que existan tramas
circulando indefinidamente o tormentas de tramas. Por otro lado, la
prohibición de giros, en el plano de control, afecta a las tablas de
encaminamiento: la ruta más corta en cada nodo debe suponer un giro
permitido, por lo que la ruta permitida en un nodo hacia un
determinado destino puede no ser la mínima sino la mínima legal para
ese nodo. Si solamente se difunden entre vecinos rutas legales, con
giros permitidos, en las tablas de encaminamiento todas las rutas
que aparecen son ya legales, aunque pueden no ser mínimas
absolutas.
absolutas.
Para una máxima robustez del encaminamiento, la
ruta por defecto es a través del puerto raíz hacia el puente raíz.
En el plano de usuario se implementa necesariamente el control de
giros prohibidos y opcionalmente se puede implementar también el
control de giros teniendo en cuenta la dirección destino HLMAC de la
trama además de las HLMAC de los tres puentes implicados en el
giro: previo, actual y siguiente salto. Esto posibilita permitir
los giros prohibidos siempre que terminen en la rama destino del
árbol independientemente de la dirección que llevan esos giros.
\newpage
Ejemplos de giros permitidos y prohibidos en el
árbol de la Figura 11 y sus razones según una versión laxa de
prohibición de giros implementada en HURP son los siguientes:
- b-c-e
- prohibido por ser horizontal-horizontal y el nodo e no es rama destino
- c-e-g
- permitido por ser horizontal-horizontal y el nodo c no es rama origen
- c-j-e
- prohibido por ser abajo-arriba
- i-c-e
- prohibido por ser abajo-horizontal
\vskip1.000000\baselineskip
Los giros que terminan o comienzan en los
equipos terminales o "hosts" en inglés, h1 y h2 en la figura
11, son siempre permitidos. Esto se debe a que la dirección la
reciben del correspondiente puente al que están conectados, por lo
que siempre es un enlace ascendente o descendente, que no forma
parte de los giros prohibidos.
Los "hosts" pueden disponer de tantas
direcciones HLMAC distintas como interfaces de red conectadas a
distintos puentes combinados tengan. En el caso de varios enlaces
paralelos entre un equipo terminal y un puente, el protocolo de
agregación de enlaces opera de forma estándar y se comporta como un
solo enlace desde el punto de vista de los protocolos CSTP y
HURP.
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 (31)
1. Procedimiento de gestión de enlaces en el
nivel de enlace de datos para redes de telecomunicaciones, las
cuales comprenden una pluralidad de puentes de red configurados para
intercambiar tramas BPDU a través de enlaces que conectan dichos
puentes de red, donde se establece al menos un árbol de expansión
según un protocolo estándar que se forma a partir de un puente de
red raíz (R) del que cuelga al menos un puente de red convencional
que opera según el protocolo 802.1D y teniendo dicho árbol de
expansión al menos un puente de red hoja conectado a un equipo
terminal, caracterizado porque comprende:
- crear un árbol de expansión jerárquico que se
forma a partir del puente de red raíz (R) colgando al menos un
puente de red que está conectado mediante un enlace punto a punto a
dicho puente de red raíz (R) a través de un puerto designado y que
tiene una dirección MAC local jerárquica asignada añadiendo un campo
de seis octetos al final de una trama BPDU estándar, que indica un
número, que es variable, de niveles del árbol de expansión
jerárquico y contiene:
- -
- un identificador de puerto del puerto designado, correspondiente a un nivel del árbol de expansión jerárquico en el que se establece el puente de red que tiene dicho puerto designado, y
- -
- un prefijo que es el identificador de puerto del puerto raíz, al que se añade el identificador de puerto del puerto designado;
- reconfigurar el árbol de expansión jerárquico
enviando al menos una trama BPDU del tipo TCN y borrando la
dirección MAC asignada al puerto con el estándar 802.1D;
- usar el protocolo ARP para resolver las
direcciones MAC con direcciones IP.
\vskip1.000000\baselineskip
2. Procedimiento de gestión de enlaces según
reivindicación 1, caracterizado porque el árbol de expansión
se crea mediante el protocolo estándar STP.
3. Procedimiento de gestión de enlaces según
reivindicación 1, caracterizado porque el árbol de expansión
se crea mediante el protocolo estándar RSTP.
4. Procedimiento de gestión de enlaces según
cualquiera de las reivindicaciones anteriores, caracterizado
porque el árbol de expansión jerárquico se une al, al menos un,
árbol de expansión creado mediante el protocolo estándar y formado
por puentes de red convencionales que se conectan en la periferia
del árbol de expansión mixto formando subárboles, para formar un
árbol de expansión mixto.
5. Procedimiento de gestión de enlaces según
cualquiera de las reivindicaciones anteriores, caracterizado
porque el número de niveles del árbol de expansión jerárquico se
indica de forma explícita en un primer octeto de dicho campo de seis
octetos.
6. Procedimiento de gestión de enlaces según
cualquiera de las reivindicaciones 1 a 4, caracterizado
porque el número de niveles del árbol de expansión jerárquico se
indica de forma implícita rellenando con ceros desde un último
octeto de dicho campo de seis octetos hasta un octeto que contiene
el identificador de puerto del puerto designado.
7. Procedimiento de gestión de enlaces según
cualquiera de las reivindicaciones anteriores, caracterizado
porque adicionalmente comprende enviar periódicamente la trama BPDU
con el campo de seis octetos añadido al final y con una dirección
MAC de origen que es única y una dirección MAC de destino que es una
dirección de multidifusión.
8. Procedimiento de encaminamiento de tramas de
datos, que opera en el nivel de enlace de datos y que comprendiendo
el envió y reenvió de tramas de datos con una dirección MAC de
destino a través de un puerto designado de un puente de red, se
caracteriza porque simultáneamente:
- encamina tramas de datos con la dirección MAC
de destino igual a una dirección MAC universal usando el estándar
802.1D, y
- encamina, a lo largo de una ruta, al menos una
trama de datos con una dirección MAC de origen y con la dirección
MAC de destino igual a una dirección MAC local asignada de forma
jerárquica en un campo de seis octetos de una trama BPDU que tiene
al menos una entrada de al menos dieciocho octetos, donde:
- -
- el campo de seis octetos indica un número, que es variable, de niveles del árbol de expansión jerárquico y contiene:
- -
- un identificador de puerto del puerto designado correspondiente a un nivel del árbol de expansión jerárquico en el que se establece el puente de red que tiene dicho puerto designado,
\newpage
- -
- un prefijo al que está añadido el identificador de puerto del puerto designado, siendo el prefijo un identificador de puerto asignado a un puerto raíz que establece un camino de coste mínimo al puente de red raíz (R), determinado el coste por una métrica definida en el estándar 802.1D;
- -
- la entrada de al menos dieciocho octetos contiene:
- -
- el campo de seis octetos con la dirección MAC local jerárquica asignada,
- -
- una longitud de prefijo que indica en un campo de un octeto la longitud en bits del prefijo contenido en la dirección MAC local jerárquica asignada,
- -
- una etiqueta de ruta que identifica en otro campo de un octeto una dirección de origen de una ruta, y
- -
- otro campo de seis octetos que indica un siguiente salto y a su vez contiene la dirección MAC local jerárquica asignada a un puente elegido para ser siguiente en la ruta
y porque periódicamente envía, por un puente de
red designado, la trama BPDU con la, al menos una, entrada, al
puente elegido para ser siguiente en la ruta.
\vskip1.000000\baselineskip
9. Procedimiento de encaminamiento de tramas de
datos según reivindicación 8, caracterizado porque el número
de niveles del árbol de expansión jerárquico está indicado dentro
del campo de seis octetos de forma explícita en un primer octeto de
dicho campo de seis octetos.
10. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 9,
caracterizado porque al encaminar la trama de datos con la
dirección MAC de destino igual a una dirección MAC local asignada de
forma jerárquica, hace un giro en un puente de red cuya dirección es
el prefijo común a las direcciones MAC origen y destino de la
trama.
11. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 10,
caracterizado porque con el envió periódico de la trama BPDU
se anuncia una ruta completa que incluye los puentes de red
establecidos, dentro del árbol de expansión jerárquico, en el nivel
jerárquicamente inferior y el nivel jerárquicamente superior con
respecto al puente de red designado.
12. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 10,
caracterizado porque con el envió periódico de la trama BPDU
se anuncia una ruta sólo si el coste de la ruta es menor que el
doble del coste de otra ruta establecida desde el puente de red
designado al puente de red raíz (R).
13. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 10,
caracterizado porque con el envió periódico de la trama BPDU
se anuncia una ruta agregada que determina un subárbol completo.
14. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 13,
caracterizado porque la ruta pertenece enteramente al árbol
de expansión jerárquico.
15. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 13,
caracterizado porque la ruta incluye al menos un enlace
transversal a un puente de red vecino del puente de red designado
con respecto al árbol de expansión jerárquico sólo si el coste de
dicha ruta es menor o igual que un coste estimado de una ruta que
pertenece enteramente al árbol de expansión jerárquico.
16. Procedimiento de encaminamiento de tramas de
datos según reivindicación 15, caracterizado porque el puente
de red vecino se selecciona entre un puente de red intermedio y un
puente de red hoja conectado a un equipo terminal.
17. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 16,
caracterizado porque al encaminar la trama de datos
adicionalmente comprende realizar una prohibición de giros en el
árbol de expansión jerárquico, estableciendo unos giros prohibidos
que están constituidos por enlaces de un tipo que se selecciona
entre abajo-arriba, abajo-horizontal
y horizontal-horizontal, respecto a dicho árbol de
expansión jerárquico.
18. Procedimiento de encaminamiento de tramas de
datos según reivindicación 17, caracterizado porque la
prohibición de giros adicionalmente comprende establecer otros giros
prohibidos que están constituidos por enlaces
arriba-abajo que comprenden al menos un puente de
red que pertenece a una rama del árbol de expansión jerárquico
formada por los puentes cuya dirección MAC local jerárquica contiene
un prefijo igual al prefijo de la dirección MAC de destino.
19. Procedimiento de encaminamiento de tramas de
datos según reivindicación 17, caracterizado porque la
prohibición de giros adicionalmente comprende establecer para un
destino de la trama de datos una ruta que es de mínimo coste y
contiene un número mínimo de giros prohibidos.
\newpage
20. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 19,
caracterizado porque la dirección MAC universal es de grupo
de difusión amplia.
21. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 19,
caracterizado porque la dirección MAC universal es de
multidifusión.
22. Procedimiento de encaminamiento de tramas de
datos según cualquiera de las reivindicaciones 8 a 19,
caracterizado porque la dirección MAC de destino es
única.
23. Dispositivo de interconexión de redes que
opera en el nivel de enlace de datos caracterizado porque
comprende al menos un puerto a través del que está conectado a al
menos un segmento de red mediante un enlace punto a punto y
comprende medios de procesamiento configurados para operar de
acuerdo con el procedimiento de gestión de enlaces definido según
cualquiera de las reivindicaciones 1 a 7.
24. Dispositivo de interconexión de redes según
reivindicación 23, caracterizado porque los medios de
procesamiento están configurados para operar de acuerdo con el
procedimiento de encaminamiento de tramas de datos definido según
cualquiera de las reivindicaciones 8 a 22.
25. Dispositivo de interconexión de redes según
reivindicación 24, caracterizado porque tiene el, al menos
un, puerto configurado en al menos dos modos de operación:
un modo estándar para encaminar mediante el
protocolo estándar 802.1D las tramas de datos con una dirección MAC
de destino igual a una dirección MAC universal asignada, y
un modo jerárquico para encaminar las tramas de
datos con una dirección MAC de destino igual a una dirección MAC
local asignada en un árbol de expansión jerárquico.
26. Dispositivo de interconexión de redes según
reivindicación 25, caracterizado porque el, al menos un,
puerto opera simultáneamente en los dos modos estándar y
jerárquico.
27. Dispositivo de interconexión de redes según
reivindicación 25, caracterizado porque el, al menos un,
puerto opera alternativamente entre el modo estándar y el modo
jerárquico.
28. Dispositivo de interconexión de redes según
cualquiera de las reivindicaciones 25 a 27, caracterizado
porque el, al menos un, puerto está configurado en un tercer modo de
operación para encaminar las tramas de datos usando una dirección de
destino igual a una dirección IP.
29. Dispositivo de interconexión de redes según
cualquiera de las reivindicaciones 23 a 28, caracterizado
porque adicionalmente comprende al menos un puerto a través del que
está conectado a al menos un segmento de red mediante un enlace no
punto a punto y porque dicho puerto está configurado en un modo
estándar para encaminar mediante el protocolo estándar 802.1D las
tramas de datos con una dirección MAC de destino igual a una
dirección MAC universal asignada.
30. Red de telecomunicaciones conmutada
caracterizada porque comprende al menos un dispositivo de
interconexión de redes definido según cualquiera de las
reivindicaciones 23 a 29.
31. Red de telecomunicaciones conmutada según
reivindicación 30, caracterizada porque adicionalmente
comprende al menos un puente de red que opera exclusivamente según
el protocolo estándar 802.1D y que está conectado a dicho
dispositivo de interconexión de redes.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200702358A ES2337220B1 (es) | 2007-08-30 | 2007-08-30 | 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. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES200702358A ES2337220B1 (es) | 2007-08-30 | 2007-08-30 | 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. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| ES2337220A1 ES2337220A1 (es) | 2010-04-21 |
| ES2337220B1 true ES2337220B1 (es) | 2011-05-23 |
Family
ID=42077479
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES200702358A Active ES2337220B1 (es) | 2007-08-30 | 2007-08-30 | 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. |
Country Status (1)
| Country | Link |
|---|---|
| ES (1) | ES2337220B1 (es) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109726016A (zh) * | 2017-10-30 | 2019-05-07 | 阿里巴巴集团控股有限公司 | 一种用于分布式系统的链路追踪方法、装置和系统 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7801125B2 (en) * | 2004-10-22 | 2010-09-21 | Cisco Technology, Inc. | Forwarding table reduction and multipath network forwarding |
| US7760720B2 (en) * | 2004-11-09 | 2010-07-20 | Cisco Technology, Inc. | Translating native medium access control (MAC) addresses to hierarchical MAC addresses and their use |
-
2007
- 2007-08-30 ES ES200702358A patent/ES2337220B1/es active Active
Non-Patent Citations (2)
| Title |
|---|
| "{}IEEE Standard for Local and metropolitan area networks. Media Access Control (MAC) Bridges"{}. IEEE Std 802.1D-2004 (Revision de IEEE Std 802.1D-1998). 9-Junio-2004. URL: http://standards.ieee.org/getieee802/download/ 802.1D-2004.pdf Capítulos 7.9, 9.3, 17.1-17.15. * |
| AZCORRA et al. "{}Application of rapid spanning tree protocol for automatic hierarchical address assignment to bridges"{} Telecommunications Network Strategy and Planning Symposium. NETWORKS 2004, 11th International, páginas 435-440, 13-16 Junio 2004. Todo el documento. * |
Also Published As
| Publication number | Publication date |
|---|---|
| ES2337220A1 (es) | 2010-04-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2361545B1 (es) | Procedimiento de encaminamiento de tramas de datos y puente de red. | |
| US8995444B2 (en) | Method and system for extending routing domain to non-routing end stations | |
| US8102775B2 (en) | Joining tree-based networks into an autonomous system using peer connections between the tree-based networks | |
| US10454877B2 (en) | Interoperability between data plane learning endpoints and control plane learning endpoints in overlay networks | |
| Touch et al. | Transparent interconnection of lots of links (TRILL): Problem and applicability statement | |
| US9912614B2 (en) | Interconnection of switches based on hierarchical overlay tunneling | |
| US8441958B2 (en) | Directed acyclic graph discovery and network prefix information distribution relative to a clusterhead in an ad hoc mobile network | |
| CN107948041B (zh) | 构建vxlan集中式多活网关的方法和设备 | |
| US20120163164A1 (en) | Method and system for remote load balancing in high-availability networks | |
| CN102546351A (zh) | openflow网络和现有IP网络互联的系统和方法 | |
| CN1440159A (zh) | 层次式交换网络节点域的一种控制方法 | |
| JP2006524974A5 (es) | ||
| CN104378297A (zh) | 一种报文转发方法及设备 | |
| CN104936168A (zh) | 一种高效的无线mesh组网方法 | |
| WO2024016869A1 (zh) | 一种组播配置方法及装置 | |
| Lee et al. | InterMR: Inter-MANET routing in heterogeneous MANETs | |
| CN101491011B (zh) | 用于为路由发现过程生成扩展的路由请求消息和扩展的路由应答消息的方法 | |
| CN100440870C (zh) | 覆盖路由网络中数据转发的方法 | |
| Bhangwar et al. | On routing protocols for high performance | |
| 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. | |
| Hemagowri et al. | A study on proactive routing protocol in ad-hoc network | |
| US20050254473A1 (en) | Routing within a mobile communication network | |
| ES2363083T3 (es) | Procedimiento de conmutación automática de protección. | |
| Ibáñez et al. | HURP/HURBA: Zero-configuration hierarchical Up/Down routing and bridging architecture for Ethernet backbones and campus networks | |
| Singh | Routing protocol for WMNs |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EC2A | Search report published |
Date of ref document: 20100421 Kind code of ref document: A1 |
|
| FG2A | Definitive protection |
Ref document number: 2337220 Country of ref document: ES Kind code of ref document: B1 Effective date: 20110523 |