TRILL: La revolución de Spanning Tree Protocol
Cuando hablamos de redes, es interesante tener en cuenta que algunos de los protocolos que operan en las redes actuales se basan en estándares aprovados hace casi 30 años. En el caso que nos ocupa hoy, Spanning Tree Protocol, casi cumple esos 30 años. Concretamente, Spanning Tree Protocol (STP) se inventó en 1985 por Radia Perlman. Aunque se han sucedido algunas mejoras a lo largo de los años para adaptarlo a las redes actuales (que distan bastante de las de antaño), la idea de STP es simple: evitar bucles eliminando enlaces redundantes. Esta idea, aunque correcta, nos obliga a no utilizar la máxima capacidad de nuestra red, y lo más preocupante, a tener enlaces instalados (con el coste que ello comporta) cuya única función es la de backup. Sin embargo, parece que esta situación está a punto de finalizar. El culpable de esto es un nuevo protocolo, también diseñado por Radia Perlman en el marco de la Internet Engineering Task Force (IETF). Este nuevo protocolo se llama TRILL, abreviación de TRansparent Interconnection of Lots of Links y permite manejar los bucles de una red de manera diferente a como lo hace Spanning Tree. TRILL maximiza el uso de todos los enlaces y nos permite usar características propias de los algoritmos de routing, por ejemplo, el balanceo de carga. Aunque existe relación entre la meta de los dos protocolos, es importante señalar que una gran diferencia entre ellos es que STP no permite de ninguna manera los bucles dentro de la red, sin embargo, TRILL sí que puede llegar a permitir temporalmente la existencia de bucles dentro de la red, aunque para evitar su efecto negativo en la red de comunicaciones añade un campo de Hop count, cuya misión es la de evitar que un paquete permanezca en la red TRILL de manera indefinida en caso de que un bucle se forme.
Como ya hemos comentado, el punto fuerte de TRILL es que mezcla las caraterísticas de los niveles 2 y 3 del modelo de referencia de la Torre OSI, ofreciendo lo mejor de los dos mundos. TRILL usa Intermediate System-Intermediate System (IS-IS) como protocolo de routing. Recordemos que este es un algoritmo Link State, cosa que implica que todos los equipos dentro del dominio TRILL tienen una visión lógica de toda la red, permitiendo otorgar un coste a cada uno de los caminos disponibles entre una pareja origen-destino. Cada uno de los equipos que se encuentra dentro de la red TRILL recibe el nombre de RBridge, Routing Bridge y el mismo protocolo permite incluir enlaces de diferentes niveles físicos dentro de TRILL tales como Ethernet (óptico, coaxial, o de par trenzado), Wireless Ethernet o Power Line Communications (PLC), haciéndolos transparentes a los dispositivos externos a TRILL.
Dentro del marco del proyecto INTEGRIS, realizado en parte en La Salle R&D, nuestra propuesta ha sido la de aplicar dicho protocolo a la red de comunicaciones y monitorización de la red eléctrica, a causa de los estrictos requitos en cuanto a alta disponibilidad y bajo retardo que tiene dicha red. La experiencia ha sido satisfactoria aunque todavía será necesario seguir optimizando nuestro código, así como aumentar el grado de experiencia con este nuevo protocolo que se propone como el estándar presente para las redes de alta capacidad y de alta disponibilidad, como así lo confirma el hecho de que muchos fabricantes ya dispongan de su propia tecnología Fabric implementada siguiendo los estándares que marca TRILL. Algunos ejemplos de estos fabricantes son Cisco FabricPath y Juniper QFabric.
Comentarios
Enviado por Z (no verificado) el Vie, 04/19/2013 - 13:34 Enlace permanente
En el proyecto INTEGIRS hemos llegado más allá de lo que el propio estándar propone (el del IETF o incluso el del IEEE).
Aquí tenéis más información sobre las mejoras de funcionamiento propuestas para reducir la latencia:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=64594...
Enviado por ramonmdp (no verificado) el Vie, 04/19/2013 - 17:39 Enlace permanente
Muy interesante Xavi. Gracias a tu análisis por fin entiendo (o eso creo) las ventajas y finalidades de TRILL! Según extraigo de lo escrito, y corrígeme si me equivoco, TRILL es un protocolo de nivel 2 (capa de enlace), situado por encima de Ethernet (o wifi ethernet, plc, etc.) pero con capacidades de enrutamiento más propias de nivel 3 y que permite mantener todos los enlaces de N2 activos evitando bucles. De esta manera aumentas la capacidad total de la red, (por ejemplo manteniendo todos los caminos activos entre bridges mallados mesh). Y además, ofreces alta disponibilidad entre extremos, ya que el tiempo de convergencia en caso de caer uno de los bridges, tiene que ser muy reducido (ya que los otros caminos están ya activos).
Como me has picado la curiosidad, he echado un ojo por la red, y he encontrado este artículo que me parece interesante para los que quieran profundizar más en el tema: http://lamejournal.com/2011/05/16/layer-2-routing-sort-of-and-trill/ . Hay algunos gráficos extra muy claros de la encapsulación y su funcionamiento.
Enviado por Xavier Ramón (no verificado) el Vie, 04/19/2013 - 23:00 Enlace permanente
Lo has entendido perfectamente Ramón! Al ser un protocolo con trazas de nivel 2 y de nivel 3, se suele decir que TRILL forma parte de los protocolos de nivel 2.5 (dos y medio).
He revisado el link que has puesto y es muy interesante, incluye los famosos poemas de Radia que explican en pocas líneas el funcionamiento de los protocolos y además incluye ejemplos de configuración de los Nexus 7000 con FabricPath, gracias por el aporte!
Enviado por Alan Briones Delgado (no verificado) el Dom, 04/21/2013 - 11:58 Enlace permanente
Gracias por este post! De cara a mi proyecto sobre Service Composition: Alta Redundancia y Disponibilidad, es muy fructífero ver el estudio del funcionamiento de este protocolo y los beneficios que aportan.
Es interesante como puede llegar a utilizar bucles y "contradiciendo" un poco esa mentalidad antibucle. También destacar que funciona con diferentes tecnologías de nivel físico, lo cual lo hace implementable en muchos aspectos.
Mi duda es, ¿Qué escalabilidad tiene? Es decir, su buen funcionamiento depende del número de nodos, cúantos son recomendables y qué tiempo de recuperación en caso de caída?
Enviado por mavila (no verificado) el Lun, 04/22/2013 - 12:13 Enlace permanente
La verdad es que parece mentira que hoy en día se siga usando algo tan obsoleto como es Spanning-tree. Habrá que ver si se impone TRILL o Shortest Path Bridging, que según tengo entendido es un protocolo similar. Quizá solo haya lugar para uno de los dos, como con VHS vs. Beta o BD vs. HD-DVD.
Aquí los comparan: http://www.avaya.com/uk/resource/assets/whitepapers/SPB-TRILL_Compare_Co...
Enviado por Xavier Ramón (no verificado) el Lun, 04/22/2013 - 12:17 Enlace permanente
Hola Ala. Me alegro de que el post te resulte útil para tu proyecto.
Sobre tus dudas debo comentar que al ser una tecnología relativamente nueva, se han realizado pocas implementaciones, por lo qu ela información disponible en internet es bastante escasa.
De todas maneras debo comentarte que cisco muestra en sus white papers implementaciones de 250 Tbps: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_...
Enviado por ramonmdp (no verificado) el Lun, 04/22/2013 - 12:44 Enlace permanente
Respecto a BD vs. HD-DVD, se da el caso que, en mi opinión, no hay lugar para ninguno y que su lucha ha sido el principio del fin del almacenamiento en discos ópticos. En este caso, es seguro que necesitaremos una tecnología de enlace que se encargue de mantener el estado de los caminos físicos. Alguno de los dos, o alguna variante de ellos lo veremos implantado globalmente algún día.
Enviado por ayza (no verificado) el Mar, 04/23/2013 - 13:36 Enlace permanente
En la práctica siempre es complicado substituir algún protocolo que ya funciona, como pasa con IPv6. Está claro que la eficiencia de la red con TRILL es mayor que con STP y aporta muchas mejoras. Sin embargo, ¿los switch que implementen TRILL deberán tener más CPU y ser más potentes que los actuales? Y podría esto ser una limitación para el despliegue de TRILL?.
Enviado por Julia Sánchez (no verificado) el Lun, 05/06/2013 - 20:35 Enlace permanente
Gracias a la asignatura Gestión y Planificación de Redes impartida en 4º del Grado de Telemática de la Salle, en los últimos meses he podido asistir a diversas charlas realizadas por ponentes de empresa relacionados con el mundo de los Data Centers. Todos ellos comentaron que uno de los mayores inconvenientes en los Data Centers era Spanning-Tree por las desventajas que expones. Como comentas, parece que diversos fabricantes disponen de soluciones basadas en la idea de TRILL pero que son propietarias y corrígeme si voy mal encaminada, tanto Cisco FabricPath como Juniper QFabric, ¿no son soluciones más de Data Center? ¿O se utilizan en otros ámbitos? Lo comento porque según he visto parece que en temas de Data Center si que se está evitando la implementación de STP, pero ¿se está intentando adoptar/integrar TRILL o soluciones equivalentes en otro tipo de redes/topologías?
Añadir nuevo comentario