¿Por qué ERPS?
ERPS apareció como un protocolo estándar (ITU-T) y por tanto capaz de ofrecer interoperabilidad y con un tiempo bajo de recuperación bajo que pudiera satisfacer entornos industriales y Carrier Ethernet.Hasta la aparición de este mecanismo teníamos dos familias de protocolos de protección en anillo:
- STP/RSTP/MSTP típicamente en entornos de networking o incluso operador. Su principal problema es el tiempo de recuperación que puede llegar incluso a algunos segundos
- Protocolos propietarios para diferentes fabricantes de switches industriales (Moxa, Hirschman, Kyland, Ruggedcom,...). En estos entornos no podemos permitirnos tiempos de recuperación tan altos y con estos protocolos propietarios conseguimos tiempos inferiores a 50ms.
Los problemas derivados de la anterior situación son claros:
- no podemos interconectar switches industriales de diferentes fabricantes en el mismo anillo con tiempos bajos de recuperación ya que se trata de protocolos propietarios. En este sentido ya han aparecido estándares como DRP pero en la práctica no suelen usarse ya que los técnicos están habituados a la configuración de los protocolos propietarios de cada fabricante.
- no podemos interconectar switches industriales y switches no industriales en un mismo anillo. Este último problema puede parecer inusual pero en multitud de instalaciones (Smart grid, ITS, videovigilancia, ...) podemos tener switches industriales de campo conectados a switches no industriales en el centro de control o caseta de comunicaciones (donde no tenemos requisitos de tipo industrial). No podemos conectarlos en anillo de forma que si queremos algún tipo de redundancia tendremos que conectarlos con mecanismos LACP o similares.
Principios y objetivos
- Usar tramas estándar 802 MAC y OAM a lo largo del anillo
- Mapear el tráfico en una VLAN estándar según 802.1Q deshabilitando xSTP en los switches del anillo
- Los nodos del anillo deberán soportar mecanismos estándar de FDB MAC learning, forwarding, flush behaviour y port blocking/unblocking mechanisms.
- Los bucles se evitan bloqueando uno de los puertos del anillo (o bien un puerto predefinido en caso de anillo cerrado o bien el enlace caído en caso de anillo abierto
- .Monitorización del nivel físico Ethernet para descubrir e identificar un punto de fallo o Signal Failure (SF)
- ƒProtección y recuperación en menos de 50ms para la mayoría de circunstancias
- El tráfico asociado a los mensajes del mecanismo de protección debe usar un porcentaje mínimo del ancho de banda disponible en el anillo
Conceptos ERPS
- Ring Protection Link (RPL) – Link designado por el mecanismo ERPS para estar bloqueado en estado de reposo (anillo cerrado) y evitar así el bucle de tráfico
- RPL Owner – Nodo del anillo conectado al RPL que bloquea el tráfico durante el estado de reposo (anillo cerrado) y lo desbloquea en estado de protección (anillo abierto)
- Link Monitoring – Los enlaces del anillo se monitorizan a través de mensajes OAM (CFM)
- Signal Fail (SF) – Se produce cuando se detecta una caída de la señal Ethernet
- No Request (NR) – Mensaje o situación que se declara en los paquetes del protocolo cuando no hay anomalía detectada en el nodo
- Ring APS (R-APS) Messages – Mensajes del protocolo definidos en Y.1731 y G.8032
- Automatic Protection Switching (APS) Channel - VLAN del anillo que se usa exclusivamente para el intercambio de mensajes OAM incluyendo los mensajes R-APS
Temporizadores ERPS
ERPS define algunos temporizadores de cara a evitar fluctuaciones entre los estados de anillos cerrado y anillo abierto.
- ƒWTR (Wait to Restore) Timer – Usado por el RPL Owner para verificar que el tráfico en el anillo se ha estabilizado antes de bloquear el RPL de nuevo tras la recuperación del mismo
- ƒHold-off Timers – Usados por las capas físicas Ethernet para evitar reportar caídas intermitentes al protocolo ERPS
Ejemplo de configuración
Ahora veamos todo lo anteriormente explicado en el siguiente ejemplo con los comandos de configuración para switches ISCOM del fabricante Raisecom
Tenemos un anillo con tres nodos. Uno hace el panel de owner, otro de neighbour (vecino que nos permite definir el RPL) y otro de transfer. En todo anillo debe haber un owner y un neighbour, el resto de nodos son transfer.
Para cada uno de los nodos debemos definir:
- el ID del anillo (1 en nuestro ejemplo). Debe ser único para cada switch ya que un switch puede pertenecer a varios anillos
- ambos puertos del anillo (east y west en nuestro caso)
- node-type: el tipo de nodo según lo descrito antes. En los tipos owner y neighbour debemos también definir el RPL, lo que hacemos a través de los comandos rpl-east o rpl-.west respectivamente. Este comando define el puerto que bloqueará el tráfico en estado de reposo (anillo cerrado)
- VLAN para el intercambio de mensajes OAM y ERPS en el anillo
- WRT timer (nosotros dejamos el valor por defecto y por tanto no se indica)
owner
- ethernet ring-protection 1 east
port 9 west port 10 node-type rpl-owner
rpl
east protocol-vlan 10
neighbour
-
ethernet
ring-protection 1 east port 9 west port 10 node-type rpl-neighbour
rpl
west protocol-vlan 10
transfer
-
ethernet
ring-protection 1 east port 9 west port 10 node-type transfer
protocol-vlan 10
