mecanismos de protección y recuperación en redes de tiempo real

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 Comunicaciones
Administrador de Infraestructuras
Universidad Politécnica de
Universidad Politécnica de
Universidad Politécnica de
Ferroviarias (ADIF)
Valencia
Valencia
Valencia
[email protected]
[email protected]
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
[email protected]
[email protected]
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.
II. PROTECCIÓN Y RECUPERACIÓN ANTE FALLOS
Fig. 2. Anillos nacionales y regionales SDH
Anillo de acceso
Ethernet (vMAN)
Anillo de Acceso
Ethernet
(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
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.
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.
-
-
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.
SOLUCION RPR EN ESTACIONES PRINCIPALES Y SECUNDARIAS
ESTACION PRINCIPAL 2
ESTACION PRINCIPAL 3
ESTACION PRINCIPAL 4
(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.
ANILLO RPR VC4
V. CONCLUSIONES
Anillo RPR VC-4
Anillo RPR VC-4
Anillo RPR VC-4
Anillo RPR VC-4
Puerto Llano
Venta de
Ines
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
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]
[2]
[3]
[4]
[5]
[6]
[7]
Resilient Packet Ring Alliance:
http://www.rpralliance.org/
IEEE 802.17 Resilient Packet Ring Working Group:
http://www.ieee802.org/17/
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_submiss
ion.pdf
Nortel Networks Positioning Paper.
“Implementing Ethernet VPNs using Resilient Packet Ring”. 2003.
http://www.nortel.com/solutions/optical/collateral/56046.25-041403.pdf
Extreme Networks White Paper. “Building Carrier Class Metro
Ethernet Networks”. 2004.
RFC3619 “Ethernet Automatic Protection Switching”:
http://www.faqs.org/rfcs/rfc3619.html
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