TRILL

TRILL (Transparent Interconnection of Lots of Links, interconexión transparente de múltiples enlaces en español) es un protocolo estándar usado para técnicas de enrutamiento. Se considera que está situado entre la capa 2 y 3 del modelo OSI (o capa 2 1/2), puesto que implementa funcionalidades de ambas capas. TRILL combina técnicas de bridging y enrutamiento, y utiliza el enrutamiento de estado-enlace para hacer aparecer un conjunto de enlaces IP como un único enlace IP (subnet) al que poder dirigirse desde otros nodos IP. De esta forma, permite el uso de técnicas propias de la capa 3 OSI (enrutamiento por caminos más cortos, uso de caminos múltiples...) para interactuar con una red configurada en la capa 2 OSI, con direcciones planas, en las que los dispositivos pueden desplazarse libremente sin necesidad de cambiar su dirección IP. Los RBridges son compatibles con anteriores bridges IEEE 802.1, y pueden reemplazarlos de forma gradual. También son compatibles con routers y hosts IPv4 e IPv6. Son invisibles para los actuales routers IP y, como éstos, son puntos de terminación de los bridges de STP.

TRILL es un protocolo evolutivo, es decir, que en cualquier red Ethernet ya implementada, tan sólo hay que cambiar un subconjunto de Bridges o Switches por RBridges (Routing Bridges) necesarios para implementar el protocolo TRILL. Para entender por qué TRILL es necesario hay que entender el funcionamiento de Ethernet e IP. Es necesario conocer que los protocolos de red se establecen en capas, el sistema más conocido es el Modelo OSI, que está formado por 7 capas. Cada capa es independiente de la superior y la inferior, pero se entregan un servicio entre sí. Por lo tanto trabajan como un conjunto organizado. Para el protocolo TRILL solo es necesario conocer 3 capas.

• Capa 1, Capa Física: Es la que se encarga de la topología de la red y de las conexiones globales de la computadora hacia la red, tanto en lo que se refiere al medio físico como a la forma en la que se transmite la información.

• Capa 2, Capa de Enlace: Esta capa se ocupa del direccionamiento físico, del acceso al medio, de la detección de errores, de la distribución ordenada de tramas y del control del flujo.

• Capa 3, Capa de Red: Se encarga de identificar el enrutamiento existente entre una o más redes. Las unidades de información se denominan paquetes, y se pueden clasificar en protocolos enrutables y protocolos de enrutamiento

Como veremos a continuación, TRILL es un protocolo que actúa entremedias de la capa 2 y 3 ya que enruta de forma muy parecida a los routers de capa 3.

En un principio casi todas las conexiones eran punto a punto entre nodos vecinos, y los protocolos de capa 2, “enmarcaban” los paquetes entre un destino y otro. Con este protocolo se realizaba comunicación perfectamente sin necesidad de implementar nada más.

Aparecieron las redes LAN y la expansión de Ethernet en particular, con la interconexión de cientos de nodos en un mismo enlace. Ethernet está basado en CSMA/CD que es un protocolo de acceso múltiple, con escucha y detección de colisiones.

El problema que surgió es que las empresas compraban bloques de direcciones, y en muchas ocasiones se necesitaba un número muy elevado de ips, y no hay suficientes ips para identificar todos los elementos de todas las redes distribuidas por el mundo. Por este motivo surgieron los protocolos de enrutamiento de capa 2, que se basaban en las direcciones MAC de los dispositivos en lugar de sus ips.

TRILL es un protocolo definido en la RFC5556 de mayo de 2009. Es un estándar propuesto por la IETF que utiliza protocolo de enrutamiento IS-IS, ya que este se basa en OSI y no en TCP/IP. Este protocolo contiene las capacidades del algoritmo SPF (Short Path First) creado por Dijkstra. Permite manejar los bucles de una red de manera diferente a como lo hace STP.

STP (Spanning Tree) es un protocolo que tiene casi 30 años, Spanning Tree se inventó en 1985 por Radia Perlman, y se basa en eliminar bucles en la red eliminando enlaces redundantes. Esta idea nos obliga a hacer un uso máximo de la capacidad de la red, y tener enlaces de backup.

STP es ineficiente, ya que no utiliza todas las rutas posibles entre switches, y los caminos que elige tampoco son los más cortos ni los más rápidos. Por este motivo, es un protocolo lento.

TRILL utiliza routing de estado de enlace, se puede mapear toda la red, descubrirla y calcular los caminos más cortos y eficientes dentro de nuestra red. Permite un routing de múltiples saltos y por la ruta más corta, esto facilita la construcción de redes empresariales más grandes.

STP no permite los bucles de ninguna manera dentro de la Red, sin embargo TRILL si permite en ocasiones tener bucles dentro de la red, si fuese necesario, pero para evitar el efecto negativo hay un campo llamado "Hop Count" que evita que un paquete este de manera indefinida en una red TRILL.

Gracias a TRILL cada equipo sabe de antemano por qué interfaz de salida debe enviar el paquete ya que lo tiene todo en su tabla de enrutamiento. De la misma manera que en los protocolos de enrutamiento de nivel 3. Un paquete de un cliente, conectado a un switch es enrutado internamente y de manera transparente, pudiendo utilizar múltiples caminos y manejando los fallos que puedan surgir.

TRILL no bloquea los enlaces, para utilizar los caminos más cortos, como hacen otros protocolos, sino que hay una base de datos con la topología de la red, que evita los bucles dejando todos los enlaces activos, y por consiguiente el aprovechamiento de la red es mucho mayor. Disminuyendo el tráfico, evitando congestiones…

Hoy en día casi todas las aplicaciones trabajan a nivel IP, entonces, ¿Por qué no cambiar todos los dispositivos de capa 2, por routers de capa 3?

La respuesta es sencilla, los dispositivos de capa 3 tienen que tener una ip asignada a cada una de las interfaces en las que hay conectado un equipo físico, ya sea un dispositivo final o un nodo interno de la red. Como hemos comentado anteriormente, el número de ips es limitado, hasta el punto de que las direcciones IPv4 están llegando al límite, y por ello se está empezando a utilizar IPv6 que nos permite un rango de direcciones muchísimo mayor que con IPv4.

Para evitar esta sobrecarga de utilización de direcciones IP, se utilizan equipos de Capa 2 para montar las redes, de manera que el encaminamiento interno se realiza en capa 2, y no se utilizan las ips.

Los RBridges ejecutan un protocolo de enrutamiento de estado de enlace, cada uno de ellos tiene información de la topología, sabiendo todos los RBridges que componen la red. Gracias a esto pueden calcular las rutas más cortas y pueden generar árboles para generar tráfico multicast.

Para poner un ejemplo. Imaginemos una red en la que tenemos un host Destino (D), host Fuente (S) y dos RBridges RB1 y RB2. Si RB1 recibe el paquete de D hacia S , encapsula la trama con una cabecera TRILL, dirigiéndolo hacia el RB2. Esta cabecera contiene un campo “RBridge entrada” (RB1) un campo “RBridge salida” (RB2) y un número de saltos. Cuando RB2 recibe el paquete de RB1, elimina la cabecera TRILL y se lo entrega al destino.

Los principales campos de la cabecera TRILL son:

- Versión (2 bits)

- Reservado (2 bits)

- Multidestino (1bit)

- Longitud de la cabecera (5 bits)

- Hop Count (6bits)

- Nickname del RBridge de entrada (16 bits)

- Nickname del RBridge de salida (16 bits)

A continuación podemos ver la distribución de los distintos campos en la cabecera.

¿Cómo sabe RB1 a que RB debe entregarlo?. Para ello los RBridges deben llenar sus tablas de correspondencia. Cuando RB1 recibe la trama con destino D, busca en su tabla si tiene el camino hasta el destino. Si no lo tiene, encapsula el paquete con una cabecera TRILL con el campo multidestino activado, y envía la trama a todos los RB’s que tenga conectados. Cuando RB2 recibe la trama, la desencapsula y realiza el mismo procedimiento que RB1, pero en este caso, D está conectado a RB2 directamente por lo que lo entregaría al destino. En este proceso RB1 ha “aprendido” por dónde tiene que enviar todo lo que vaya hacia D.

El protocolo de estado de enlace es un protocolo de enrutamiento en el que cada Router establece cual es su vecino, y todos los Routers entre sí, se envían información del tipo “Soy R1 y mis vecinos son R2 (con coste x), R3 (con coste y) y R4 (con coste z)” Los protocolos de estado de enlace más extendidos son IS-IS y OSPF. Trill utiliza IS-IS ya que es utilizado por muchos ISP (proveedores de servicios de internet). IS-IS permite incluir campos adicionales, y se ejecuta directamente en capa 2, mientras que OSPF se ejecute sobre IP y requiere que todos los nodos tengan asignadas direcciones IP’s.

Como podemos ver en la imagen que hay a continuación los Routers almacenan en su tabla sus vecinos y los costes para llegar a ellos.

Con el protocolo TRILL, los RBridges necesitan un “apodo” único, para poder identificarse dentro de la red. Si dos RBridges eligen el mismo “apodo” tiene lugar un juego de desempate basándose en su prioridad. El RBridge con menor prioridad, deberá elegir otro apodo. También es posible elegir el apodo manualmente, en ese caso, tendrá más prioridad el apodo manual que el elegido de forma aleatoria.

Gracias al protocolo TRILL, los Bridges pueden ser sustituidos por RBridges, e incluso pueden usarse simultáneamente sin necesidad de cambiar todos. En este caso los RBridges encaminaran los paquetes y los Bridges se limitan a hacer su trabajo, reenviar el tráfico. De esta manera se puede conseguir una topolgia particionando el árbol de expansión en topologías de árbol más pequeños.

A continuación mostramos un ejemplo de una red configurada con RBridges.

Además de la cabecera TRILL explicada con anterioridad, este protocolo incluye información del tipo de enlace que une dos RBridges adyacentes. Pueden ser unidos por enlaces de diferentes tipos de protocolos como por ejemplo un enlace Point to Point (P2P), un túnel IPSec, Ethernet o MPLS. Este tipo de información se incluye en los mensajes para que los RBridges no interfieran en la comunicación y puedan encaminar los mensajes de manera transparente.

El campo Hop de la cabecera sirve para evitar bucles no controlados dentro de la topología. TRILL puede permitir bucles dentro de un árbol si fuese necesario, aunque no es muy común.

Una VLAN (virtual LAN o red de área local virtual) es un método para crear redes lógicas independientes dentro de una misma red física.

Con este método se pueden crear varias redes virtuales dentro de una misma red. Esto supone que para comunicarse entre las VLANs, hace falta un router que encamine los mensajes desde una VLAN hasta otra.

Las VLANs son muy utilizadas en redes de gran tamaño, ya que permite estructurar las redes internas por grupos, departamentos de empresas, etc. Los Bridges pueden tener configuradas diferentes puertos en distintas VLANs. Estos puentes utilizan la etiqueta VLAN de los paquetes para saber donde tienen que enviar el paquete.

Hay un problema con las VLANs y los posibles bucles no controlados que se pueden generar con el protocolo TRILL. Si hay dos RBridges en el mismo enlace, es muy importante que solo uno de ellos pueda encapsular el paquete con la cabecera TRILL, ya que ambos RBridges entregarían el mismo paquete al host final por duplicado.

Esto no es un problema tan grave, pero si el paquete recibido por los RBridges es multicast, habría un problema. El motivo es que ambos RBridges desencapsularían los paquetes y los reenviarían sin encapsular. En la imagen que viene a continuación, podemos ver como R1 mandaría a R2 el paquete sin encapsular, y R2 se lo enviaría a R1. Al no llevar la cabecera TRILL, el capo HOP no está contenido en los paquetes.

En la siguiente imagen tenemos un ejemplo de un bucle que podría producirse, de tal forma que el campo Hop Count no tendría efecto.

En este punto entra el concepto de RBridge designado, este es el que se encarga de encapsular/desencapsular tráfico para un conjunto de VLANs.

El encargado de realizar la tarea de designar el designado es el protocolo IS-IS nombrado anteriormente. Este RBridge designado puede delegar tareas a otros RBridges para que realicen el mismo trabajo y hacer un reparto de carga si fuese necesario.

De esta manera, si R1 fuese el designado, R2 sabría que el no tiene que encapsular el paquete, sin embargo R1 si, y el paquete llegaría con el campo HOP a R2 y al llegar a cero R1 o R2 lo desecharían evitando así el bucle.

TRILL trata a las VLANs como una manera de dividir dos nodos finales. Esto es un problema ya que entonces 2 RBridges conectados en un mismo enlace Ethernet, solo podrían enviar tráfico de la VLAN a la que ellos pertenezcan. Para solucionar esto, se utiliza el RBridge Designado. Él puede encapsular tráfico para todas las VLANs. Otro trabajo de este DRBridge, es crear una VLAN para todos los RBridges, así todos los RBridges recibirán tramas destinadas a sus VLANS y ellos lo único que tienen que hacer es mirar la VLAN (interna) a la que pertenece ese paquete, y entregarlo al destino correcto.

Es un mensaje “hello” que se intercambian los Ruters. Este mensaje es utilizado por el protocolo IS-IS y contiene información de los vecinos de los routers, y de los vecinos de otros. Un ruter R2 no se considerará un vecino de R1 sino recibe sus “hello”. El problema es que en el momento en el que hay un RBridge designado , R2 ignorará todas las conexiones con otros routers para que las conectividades entre ellos no sean bidireccionales.

IS-IS tuvo que cambiar ligeramente su protocolo para adaptarse a TRILL. Los mensajes de hello eran rellenados hasta un tamaño máximo. Esto era porque era posible que hubiese entremedias de R1 y R2 otro hardware capaz de procesar y reenviar paquetes de tamaños pequeños, y para evitar eso se mandaban con el tamaño máximo. El paquete solo puede ser fragmentdo por R1, su creador, y de esta manera solo lo podrán recibir y procesar los Routers vecinos. El resto de elementos de la red se limitarán a reeniviarlo.

Esto tuvo que cambiar, porque como en TRILL solamente un RBridge es establecido como designado, y es el único que puede encapsular y desencapsular tramas de todos los tipos de VLAN. El problema es que, si se recibe un mensaje hello, que tiene el tamaño máximo del tamaño de Ethernet, cuando el RBridge le introduce la cabecera de la VLAN, el tamaño de la trama excede el máximo, y no puede ser fragmentado porque como hemos dicho anteriormente solo el router que genera el mensaje “hello” puede fragmentarlo. Por lo que R2 nunca recibirá el mensaje y no podrá ser configurado como vecino de R1.

Los cambios que IS-IS tuvo que introducir fueron:

- Limitar el tamaño de los “hello”, sin rellenarlos al máximo tamaño Ethernet.

- Elegir al RBridge Designado solamente en la prioridad, y no en la conectividad.

- Enviar los paquetes de sondeo en diferentes tamaños, con esto resuelve el problema de tener más de un RBridge designado y también permite localizar los enlaces que permiten “jumbogram”.

Jumbogram es una opción que permite que la longitud máxima de los datos transportados por IPv6 (16 bits, 65.535 bytes), se extienda hasta 64 bits. También tienen la peculiaridad de que estos paquetes no pueden ser fragmentados.

Hubo bastante confusión por parte de IS-IS por tener que adaptar su protocolo para TRILL ya que IS-IS lleva décadas funcionando sin necesidad de cambiarse. Pero finalmente se cambió en la RFC de manera oficial.

TRILL en sus principios estaba pensado para manejar un único árbol dentro de la topología, y de esta manera las tramas multicast se enviarían por la totalidad del árbol. Esa idea se cambió y se realizaron múltiples árboles dentro de la misma topología.

El RBridge designado es la raíz de cada uno de los árboles y él se encarga de informar a cada árbol que árboles hay configurados. El Rbridge se auto asignará un apodo diferente para cada árbol al que pertenezca. Todos los árboles se diseñarán con las rutas más cortas y de menor coste.

Las tramas multidestino lo único que tienen que llevar es información del árbol que tiene que ser utilizado para su difusión.

TRILL ofrece un filtrado de capa 2 basado en direcciones MAC. Para ello los Bridges anuncian el conjunto de direcciones MAC que desea recibir.

Gracias a este filtrado, las tramas multidestino se procesan de diferentes maneras:

- Si el puerto en el que R recibe el paquete no está incluido en el árbol de R2, se descarta el paquete.

- Si el puerto en el que R recibe el paquete está en el árbol de R2, pero R1 no aparece en la lista RPF para ese puerto, se descarta el paquete.

- Sin embargo si el puerto en el que se recibe, está incluido en el árbol, y a parque esta en la lista RPF, el paquete se reenviará correctamente.

CISCO está lanzando Fabric Path, una tecnología basada en TRILL pero con capacidades adicionales. Es de esperar que más fabricantes incorporen la funcionalidad de este protocolo, como es el caso de Brocade que basa su arquitectura BrocadeOne en el protocolo TRILL. Versiones no son implementaciones interoperables y de propiedad.^[1]​^[2]​^[3]​

Éstos son sólo dos posibles mejoras para las que TRILL debería ser considerado:

Los centros de datos requieren más VLAN de las que se pueden configurar con los 12 bits de una única etiqueta VLAN. Una extensión de TRILL incluye la capacidad de codificar 24 bits en una trama. Por lo tanto la cantidad de VLAN que se pueden configurar en una sola trama es muchísimo mayor.

En redes campus con TRILL. La lista LSP será más pequeña, sus cálculos para encontrar los caminos más cortos serán mucho más rápidos y se tendrán que realizar con menos frecuencia. Esto hará que la capacidad de la red mejore.

• Portal:Informática. Contenido relacionado con Informática.
• Shortest Path Bridging - (IEEE 802.1aq)
• Multidifusión