MECANISMOS DE PROTECCIÓN Y RECUPERACIÓN EN REDES DE TIEMPO REAL PARA EL SOPORTE DE SERVICIOS

DE EXPLOTACIÓN FERROVIARIA Fco. Javier Sánchez Bolumar Jaime Lloret Mauri Juan Ramón Díaz Santos José Miguel Jimenez Herranz

Dirección de Formación Departamento de Comunicaciones Departamento de Comunicaciones Departamento de ComunicacionesAdministrador de Infraestructuras

Ferroviarias (ADIF) Universidad Politécnica de

Valencia Universidad Politécnica de

Valencia Universidad Politécnica de

Valencia jsbolumar@adif.es jlloret@dcom.upv.es juadasan@dcom.upv.es jojiher@masters.upv.es

Abstract- Real-time networks on railway control systems, requires delivering high availability, quality and secures services over Ethernet/IP. To offer redundancy, dual fiber o copper ring topologies are deployed at the equipment edge, and real-time applications are assigned to separate VLANs, that are mapped to MPLS or VPLS VPNs across enterprise MAN/WAN networks. Railway companies, that need high speed restoration and high availability telecommunication services, have been faced with a dilemma: in one hand, the use of ring architectures on expensive MAN networks like SDH/SONET o RPR, especially on high speed railway lines, or, on the other hand, to apply low cost level 2/3 ring Ethernet solutions, commonly on conventional railway lines. Now, we must research for a third option with low cost and fast restoration Ethernet networking technology to support critical and non critical real-time railway control systems.

I. INTRODUCCIÓN

Generalmente, las administraciones ferroviarias cuentan con una infraestructura de comunicaciones de voz y datos propia, basada normalmente en sistemas de transmisión SDH/PDH sobre cables de fibra óptica y de cobre tendidos a lo largo del recorrido. Esta infraestructura sirve de soporte tanto a los servicios informáticos, como a los servicios especializados de explotación y control de tráfico ferroviario, aunque hasta el momento, los medios y tecnologías empleados en los dos casos han sido totalmente diferentes.

Los servicios de explotación ferroviaria, que hasta hace unos años constituían “islas” de control del tráfico y de los sistemas de seguridad, están incorporando tecnologías de redes, con el fin de permitir más fácilmente el crecimiento de las instalaciones y la gestión centralizada de éstas.

Dentro del fenómeno de convergencia hacia IP, se están migrando las antiguas comunicaciones serie vía módem, hacia redes Ethernet conmutadas sobre par trenzado y fibra óptica, con protocolos TCP/IP. Dada la naturaleza crítica de los servicios de control, se emplean normalmente redes Ethernet con topologías físicas en anillo (véase la figura 1), y

Fig. 1. Topología de doble anillo

se habilitan mecanismos de tolerancia a fallos (Resilient Links [1], Fast Spanning Tree, HSRP o VRRP, protocolos de Enrutamiento con soporte de balanceo de carga o rutas redundantes y con rápida convergencia como EIGRP, etc.).

Así mismo, las redes de acceso se conectan a anillos y nodos regionales de diferentes niveles, para poder permitir la gestión centralizada de los sistemas. Aunque el transporte entre anillos regionales está basado en SDH/PDH, lo más habitual es emplear por encima MPLS/VPLS en el núcleo de red para dar soporte a VPNs y calidad de servicio. Por lo tanto, de forma similar a lo que ocurre en una red informática, también se puede hablar de dos entornos: redes de acceso Ethernet con conmutadores que se conectan entre sí mediante fibra oscura o enlaces xDSL sobre cable de cobre, y por otra parte, el núcleo de red basado en MPLS/VPLS sobre SDH/PDH (en estos casos, el empleo de ATM sobre SDH, es cada vez menor). Los anillos nacionales y regionales SDH actuales en la península Ibérica se pueden ver en la Figura 2. En la Figura 3 se puede observar la conexión de acceso a un anillo regional.

El funcionamiento de estas redes se basa en asignar a cada aplicación o tráfico de tiempo real una VLAN independiente, establecer calidad de servicio mediante marcado de nivel 2 y 3, y relacionar cada VLAN con una VPN en la red troncal MPLS/VPLS.

Fig. 2. Anillos nacionales y regionales SDH

Fig. 3. Conexión de anillo de acceso al anillo regional

La introducción de estas tecnologías en el ámbito de los sistemas de control y de seguridad para la explotación ferroviaria es muy reciente, y podemos decir que el Administrador de Infraestructuras Ferroviarias (anteriormente, conocido como Red Nacional de los Ferrocarriles Españoles –RENFE-) está siendo pionero en este sentido, resolviendo problemas funcionales, motivados por el cambio a este nuevo entorno de trabajo.

Las mejoras a introducir deberían buscar tres objetivos principales: conseguir tiempos muy bajos de recuperación ante fallos (se deben minimizar los existentes), suministrar la calidad de servicio totalmente garantizada para las aplicaciones críticas (incluso durante la ocurrencia del fallo), y seguridad integrada en la red, para evitar accesos no autorizados o interferencias en el funcionamiento de las aplicaciones. En este documento, nos centraremos solamente en los mecanismos de protección y recuperación ante fallos.

Las siguientes secciones están estructuradas tal como se indica a continuación. La sección 2 muestra las diferentes soluciones actuales y los mecanismos de protección y recuperación ante fallos que presentan. Las nuevas tendencias, se ven en la sección 3. En la sección 4, se hace una comparativa de todas las tecnologías, indicando las limitaciones y posibles mejoras a introducir. Las conclusiones muestran que las soluciones actuales son deficientes para el soporte de servicios de explotación ferroviaria de tiempo real y abre nuevas vías de investigación.

II. PROTECCIÓN Y RECUPERACIÓN ANTE FALLOS

Como ya se ha comentado anteriormente, es importantísimo minimizar la ocurrencia de fallos y el tiempo de recuperación ante éstos. Para ello, podemos recurrir a métodos de nivel 1 basados en redundancia física (a nivel de componentes, equipos, chasis, subsistemas, etc.), métodos de nivel 2 basados en topologías Ethernet, y por último, métodos de nivel 3 basados en enrutamiento.

Las topologías de las redes tolerantes a fallos se han basado típicamente en anillos dobles de fibra óptica y/o cobre, gracias a su gran capacidad, redundancia y fiabilidad. Sin duda alguna, el grado de protección que ofrecen estas topologías es significativamente superior al de topologías estrella, árbol o ramificadas, más propias de redes informáticas de propósito general.

A continuación vamos a ver las tecnologías principales que en la actualidad utilizan la topología en anillo para servicios de explotación ferroviaria, y cuales son sus limitaciones. Además de la redundancia de elementos físicos, se describirán los mecanismos de protección y recuperación ante fallos habitualmente empleados y las carencias detectadas.

El objetivo final de todas estas soluciones es soportar topologías con doble anillo de fibra o cobre, maximizando el ancho de banda aprovechado en el troncal, y ofreciendo tiempos de restauración ante fallos por debajo de los 50 ms de SDH/SONET.

A. Anillos SDH y SONET

Los anillos SDH/SONET aseguran, sin lugar a dudas, un alto grado de protección, pero el coste de los equipos es mucho mayor que para redes Ethernet, y además requieren elevados anchos de banda. Por otra parte, al ser diseñadas inicialmente para tráfico de voz TDM, estas redes no están optimizadas para tráfico LAN, ya que el ancho de banda empleado es fijo, por lo que no se adapta a los requerimientos de las aplicaciones, y prácticamente la granularidad máxima que se obtiene es de un E1 o un T1, o en el mejor de los casos, un canal de 64 Kbits. Una alternativa para aprovechar los mecanismos de multiplexación estadística, puede ser montar ATM sobre SDH/SONET, pero se trata de una solución de coste económico elevado.

Por otra parte, aunque se consiguen tiempos de restauración de servicio inferiores a 50 ms, pagamos un alto precio, al dejar sin utilizar el 50% del ancho de banda, ya que una de las fibras debe estar libre para entrar en servicio cuando se produzca el fallo y suministrar el respaldo correspondiente.

B. Mecanismos de recuperación de nivel 2 en redes Ethernet nativas

Las redes Ethernet nativas disponen de mecanismos muy limitados de recuperación ante fallos. Veamos los más significantes: - IEEE 801.d: El Spanning Tree Protocol (STP) tradicional,

tiene un tiempo de recuperación muy lento, que hace inviable su utilización en sistemas de tiempo real críticos. Tanto en la versión tradicional como en las mejoras posteriores, el enlace de reserva permanece inactivo. El tiempo de recuperación puede estar del orden de 30 segundos, o incluso más.

Anillo de accesoEthernet (vMAN)

Anillo de AccesoEthernet (vMAN)

WAN Núcleo de Red(VPLS Switched / MPLS IP Routed)

Túneles MPLS/VPLS

Servidores de Gestión Centrales

Anillo de accesoEthernet (vMAN)Anillo de accesoEthernet (vMAN)

Anillo de AccesoEthernet (vMAN)

Anillo de AccesoEthernet (vMAN)

WAN Núcleo de Red(VPLS Switched / MPLS IP Routed)

Túneles MPLS/VPLS

Servidores de Gestión Centrales Arquitectura en anillo

o en malla regional sobre sistemas de transmisión SDH

- IEEE 802.1w: Rapid Spanning Tree Protocol (RSTP). Permite recuperar la topología de red en tiempos en torno a 1 segundo. La distribución de tráfico en los enlaces no permite balanceo de carga y requiere un sobredimensionado excesivo. Debido al tiempo de recuperación, no se puede aplicar a tráficos muy sensibles.

- IEEE 802.3ad (Link Aggregation). Ofrece tiempos de recuperación en torno a decenas de milisegundos, pero sólo protege de caídas de enlace, y no de caídas de nodo.

Estas soluciones comenzaron a emplearse en la fase

inicial de migración de servicios de comunicaciones serie a conexiones por red, pero pronto se comprobaron sus carencias, por lo que es habitual utilizar por encima mecanismos de tolerancia a fallos de nivel 3, que veremos a continuación.

C. Mecanismos de recuperación de nivel 3 en redes Ethernet basados en protocolos de enrutamiento y backup de puertas de enlace

Estos mecanismos de nivel 3 complementan a los nativos Ethernet vistos con anterioridad, y se basan en la utilización de protocolos y algoritmos de enrutamiento con soporte de balanceo de carga a través de múltiples enlaces y con convergencia rápida ante los cambios. Los más utilizados son el protocolo estándar OSPF en una única área para entornos con múltiples fabricantes, y el protocolo EIGRP en entornos Cisco puros (en estos casos no se utiliza E-BGP, ya que es una solución que suele aplicarse sólo para conexión a Internet, pero no en redes privadas). OSPF tiene tiempos de convergencia que pueden oscilar entre 2 y 4 segundos, mientras que EIGRP puede llegar incluso a converger en sólo 1 segundo. Evidentemente, estos tiempos están fuera del rango deseado, pero si utilizamos varias rutas simultáneas con balanceo de carga, conseguimos el objetivo, siempre y cuando partamos de una situación de operación normal con dos o más rutas activas.

Lógicamente, la utilización de estos protocolos implica que los equipos saldrán al resto de la red a través de un router, por lo que si deseamos redundancia, es necesario duplicar los routers y emplear métodos de tolerancia a fallos de la puerta de enlace o gateway por defecto de cara a los equipos. En este caso, se utiliza el estándar VRRP (Virtual Router Redundancy Protocol) u otro método propietario similar como HSRP de Cisco. En la práctica, suele conectarse un router al anillo de fibra oscura y el otro al anillo de cobre xDSL. La configuración se realiza de forma que mientras el router conectado a la fibra tenga activo uno de los enlaces al anillo, será éste el que asuma el papel de “default gateway”, mientras que en el caso de que fallen los dos enlaces, tomará el control el router que se conecta al anillo de cobre. De esta forma, el anillo se encontrará siempre cerrado por fibra, y en caso de fallo combinará los enlaces de fibra operativos, con los de cobre en aquellos tramos con fallo.

D. Ethernet RPR IEEE 802.17

La alternativa conocida como Resilient Packet Ring (RPR) o IEEE 802.17 [2] [3], persigue alcanzar la robustez

de SDH/SONET, sin la penalización del 50% del ancho de banda infrautilizado.

La restauración de servicio en RPR se consigue mediante el tránsito del tráfico en ambas direcciones alrededor del anillo constantemente (ver la figura 4). Si se produce una caída, todo el tráfico se traslada al otro anillo, lo que implica riesgos de congestión y de deterioro del servicio. Para superar esta deficiencia, RPR usa mecanismos de marcado QoS para dar preferencia al tráfico prioritario, pero no se puede hablar de niveles de servicio garantizados. En RPR también se puede implementar VPNs Ethernet sobre RPR, tal como muestra el artículo [4] de Nortel Networks.

III. NUEVAS TENDENCIAS

A. Ethernet Automatic Protection System (EAPS – RFC 3619)

Se trata de una tecnología de protección de anillos Ethernet desarrollada por Extreme Networks [5] que se encuentra ya en la versión 2, aunque en la RFC3619 sólo viene recogida la versión 1 [6]. Cada VLAN que se desea proteger se configura en todos los puertos del anillo para ese dominio EAPS, donde se elegirá un nodo maestro y el resto actuarán como nodos de tránsito. En la versión 2, soporta topologías en anillo complejas, que eliminan la posibilidad de un único punto de fallo (múltiples dominios en un anillo o en un nodo, VLANs pertenecientes a varios dominios, etc.). Desde el punto de vista de la compatibilidad, la ventaja de esta solución es la coexistencia con STP, y que se puede elegir el sentido de circulación del flujo de información por cada VLAN, lo que permite introducir ingeniería de tráfico básica.

B. Ethernet sobre MPLS (EoMPLS)

En cuanto a los mecanismos de protección, MPLS se distingue por: - Recuperación garantizada en tiempos inferiores a 50 ms. mediante Fast-reroute. - Calidad de servicio garantizada durante la transición - Distribución óptima del tráfico después de la caída, con redistribución homogénea de la carga. - Posibilidad de definir servicios con diferentes esquemas o calidad de protección.

IV. COMPARATIVA

La solución SDH/SONET, consigue tiempos de restauración de servicio inferiores a 50 ms, pero además de tratarse de una solución cara, desaprovecha el 50% del ancho de banda, que queda a la espera de ser utilizado en caso de fallo.

Las limitaciones de los mecanismos Ethernet de nivel 2, se centran en dos puntos: el ancho de banda del anillo o camino de reserva sigue sin utilizarse, y los tiempos de recuperación antes fallos no bajan de 0,5 segundos en el mejor de los casos.

Fig. 4. Arquitectura RPR

Los mecanismos de recuperación de nivel 3, constituyen la solución más utilizada actualmente en la red de acceso con topologías de doble anillo en cobre y fibra, en gran parte por su coste moderado, pero resulta poco compacta (hacen falta varios conmutadores y al menos dos routers por LAN, uno para cada anillo) y su efectividad desaparece cuando disponemos de un único anillo activo, ya que en este caso los tiempos de convergencia impactan directamente sobre el funcionamiento de las aplicaciones de tiempo real, provocando bloqueos del sistema.

Por lo tanto, podemos decir que Ethernet supera a SDH/SONET en el uso más eficiente del ancho de banda para tráfico de datos [7], sin embargo, el protocolo no fue originalmente diseñado para ser usado en topologías en anillo o con tráfico de tiempo real. Los mecanismos de recuperación de Ethernet durante un corte de fibra son mucho más lentos (del orden de segundos), y no son apropiados para protección a nivel de camino, que asegura la restauración del servicio según clases. Así mismo, tampoco es muy eficiente en el reparto equitativo del ancho de banda de los anillos.

Por otra parte, RPR tiene problemas de escalabilidad y los costes están muy lejos de las soluciones IP/Ethernet tradicionales, con lo que no es probable que se consume el despliegue total de la tecnología. De hecho, se utiliza casi de forma exclusiva en algunas líneas de alta velocidad.

EAPS se trata de una solución adecuada para redes multiservicio, pero que debido a sus importantes costes de despliegue no ha tenido casi implantación en redes de control.

Con respecto a EoMPLS, un factor diferenciador frente a Ethernet es su capacidad para monitorizar el rendimiento, verificando la conectividad y la calidad de las conexiones, tanto en el plano de control, como en el plano de datos. Mientras que en Ethernet nativa sólo es posible verificar el estado de los equipos y la conectividad en el plano de control. En cuanto a la escalabilidad, EoMPLS permite establecer conexiones siempre por el camino mejor, optimizando el dimensionado de la red y garantizando una mayor escalabilidad. Mientras que en Ethernet nativa, las topologías o caminos calculados por el algoritmo Spanning Tree no son el óptimo, sino tan sólo uno de los caminos posibles, por lo que se requiere un sobredimensionado mucho mayor, que incrementan la inversión en equipos y medios de transmisión (canales SDH o PDH, fibra oscura, etc.). Por lo tanto, las redes EoMPLS permiten transportar diferentes tipos de tráfico, facilitando la convergencia de servicios sobre la red, y evitando la creación y mantenimiento de redes separadas

(red de tiempo real, red multiservicio, etc.). El mayor problema de estas redes es su complejidad de configuración y gestión, el alto coste económico, y carencias importantes de seguridad, que deben ser subsanadas mediante mecanismos complejos de cifrado, autenticación y autorización.

V. CONCLUSIONES

En general, podemos decir que, la estructura y tecnología actual de estas redes responde básicamente a las necesidades del tráfico multimedia, pero sin embargo, no ocurre lo mismo cuando deseamos conectar a la misma red de transporte, los sistemas de tiempo real críticos. De hecho, para evitar los bloqueos ocasionales que pueden producirse en estos sistemas, es habitual crear dos redes paralelas totalmente independientes (una red multiservicio para los sistemas de tiempo real no críticos y otra red para los sistemas de tiempo real críticos), con el consiguiente aumento de la complejidad técnica y de los costes económicos asociados.

Según hemos visto, actualmente no existe una arquitectura de red que dé respuesta a todos los requerimientos de tolerancia a fallos y recuperación, calidad de servicio garantizada y seguridad, que necesitan las aplicaciones de tiempo real para la explotación ferroviaria.

Es necesario abrir nuevas líneas de investigación, que permitan obtener una arquitectura de red, que además de cumplir con estos requisitos, tenga costes de instalación y gestión moderados, y sea fácilmente integrable con los sistemas de tiempo real críticos y no críticos, sin necesidad de realizar cambios drásticos en los equipos y aplicaciones.

AGRADECIMIENTOS

Queremos mostrar nuestro agradecimiento a las Direcciones Técnicas y de Telecomunicaciones del Administrador de Infraestructuras Ferroviarias (ADIF), y a todas las empresas y personas relacionadas con el entorno de los sistemas de control ferroviarios.

REFERENCIAS [1] Resilient Packet Ring Alliance:

http://www.rpralliance.org/ [2] IEEE 802.17 Resilient Packet Ring Working Group:

http://www.ieee802.org/17/ [3] Fredrik Davik, Mete Yilmaz, Stein Gjessing, Necdet Uzun, “IEEE

802.17 Resilient Packet Ring Tutorial”. http://www.ifi.uio.no/forskning/grupper/nd/opnet/rpr_tutorial_submission.pdf

[4] Nortel Networks Positioning Paper. “Implementing Ethernet VPNs using Resilient Packet Ring”. 2003. http://www.nortel.com/solutions/optical/collateral/56046.25-0414-03.pdf

[5] Extreme Networks White Paper. “Building Carrier Class Metro Ethernet Networks”. 2004.

[6] RFC3619 “Ethernet Automatic Protection Switching”: http://www.faqs.org/rfcs/rfc3619.html

[7] Y. F. Wong, C.Y. Wong “Performance Comparison of Resilient Packet Ring (RPR), Packet over SDH/SONET (POS) and Gigabit Ethernt (GE) for network design”. Disponible en: http://www.singaren.net.sg/activity/spects03.pdf

SOLUCION RPR EN ESTACIONES PRINCIPALES Y SECUNDARIAS

Puerto Llano

Anillo RPR VC-4Anillo RPR VC-4

Venta de Ines

ESTACION PRINCIPAL 2 ESTACION PRINCIPAL 3 ESTACION PRINCIPAL 4

ANILLO RPR VC4

Anillo RPR VC-4 Anillo RPR VC-4