Arquitectura GMPLS,

Generalized Multiprotocol Label

Switching
WDM

Señalización IP
(RSVP-TE, CR-LDP)
Copyright (c) 2002 by Ángela Belda.
This material may be distributed only subject to the terms and conditions set forth
in the Open Publication License, v1.0 or later (the latest version is presently
available at http://www.opencontent.org/openpub/). Distribution of the work or
derivative of the work in any standard (paper) book form is prohibited unless prior
permission is obtained from the copyright holder.
September, 2002
 Arquitectura GMPLS

Índice

1. Introducción .............................................................................................................................. 5
1.1. Tipos de conmutación y jerarquía de enrutamiento ................................................. 6
1.2. Extensiones del plano de control de MPLS................................................................ 8
1.3. Extensiones de GMPLS sobre MPLS-TE .................................................................. 8
2. Modelo de enrutado y direccionamiento .............................................................................. 10
2.1. Direccionamiento de capas PSC y no PSC ............................................................... 10
2.2. Mejoras de escalabilidad en GMPLS ....................................................................... 10
2.3. Extensiones TE para los protocolos de enrutamiento IP. ....................................... 11
3. Enlaces no numerados. ........................................................................................................... 12
3.1. Adyacencias de Enrutamiento no numeradas. ........................................................ 12
4. Agrupación de enlaces. ........................................................................................................... 13
4.1. Restricciones en la agrupación .................................................................................. 13
4.2. Consideraciones de enrutamiento para la agrupación ........................................... 14
4.3. Consideraciones de señalización ............................................................................... 14
4.4. Enlace agrupado no numerado ................................................................................. 14
4.5. Creación de enlaces agrupados ................................................................................. 15
5. Gestión de enlaces ................................................................................................................... 15
5.1. Canal de control y gestión del canal de control ....................................................... 15
5.2. Correlación de propiedad del enlace ........................................................................ 16
5.3. Verificación de la conectividad de un enlace ........................................................... 16
5.4. Gestión de fallos ......................................................................................................... 17
5.5. LMP para sistemas de línea óptica (OLSs) DWDM ............................................... 17
6. Señalización generalizada ...................................................................................................... 18
6.1. Conmutación por bandas de longitudes de onda .................................................... 19
6.2. Sugerencia de etiqueta ............................................................................................... 19
6.3. Restricción de etiquetas por el canal de subida ....................................................... 20
6.4. LSPs bidireccionales .................................................................................................. 20
6.5. Notificación rápida de fallos ...................................................................................... 21
6.5.1. Conjunto de etiquetas aceptables para la notificación de un error de etiqueta .. 21
6.5.2. Mensajes de notificación ...................................................................................... 21
6.6. Protección del enlace .................................................................................................. 22

-3-
 Arquitectura GMPLS

7. Adyacencias de enrutamiento (FA) ....................................................................................... 22

8. Técnicas de protección y restauración en GMPLS .............................................................. 23
8.1. Mecanismos de protección ......................................................................................... 24
8.1.1. Protección Span .................................................................................................... 25
8.1.2. Protección de camino ........................................................................................... 25
8.2. Mecanismos de restauración ..................................................................................... 25
8.2.1. Restauración de línea ........................................................................................... 26
8.2.2. Restauración de camino ....................................................................................... 26
9. Acrónimos ................................................................................................................................ 26
10. Referencias y bibliografía .................................................................................................... 27

-4-
 Arquitectura GMPLS

1. Introducción

Desde 1995 se ha producido un aumento dramático en el tráfico de datos, debido principal-

mente al crecimiento explosivo de Internet así como a la proliferación de redes privadas virtuales
(VPNs). Poco antes de finalizar el milenio, el volumen de tráfico de datos a nivel mundial sobrepa-
saba al tráfico de voz y continuará aumentando en los próximos años. Al mismo tiempo se aumen-
ta la demanda por parte de los clientes de mantener bajo el coste de acceso. Estos factores dan lugar
a una situación en la que los proveedores de servicio necesitan soluciones que les permitan trans-
portar un gran volumen de tráfico de la manera más eficiente posible en cuanto al coste.
Las redes de datos actuales se componen normalmente de cuatro capas: IP para el transporte
de aplicaciones y servicios, ATM (Asynchronous Transfer Mode) para la ingeniería de tráfico (TE),
SONET/SDH para el transporte y DWDM (Dense Wavelength-Division Multiplexing) para pro-
porcionar la capacidad. La escalabilidad de esta arquitectura es muy lenta para volúmenes de tráfi-
co muy grandes, además de ser ineficiente en coste.
El transporte efectivo debería optimizar el coste de la multiplexación de datos así como de la
conmutación de datos sobre un amplio rango de volúmenes de tráfico. DWDM es una técnica de
multiplexado eficiente que ofrece ventajas técnicas significativas. DWDM aumenta la capacidad
de transporte de ancho de banda de una única fibra óptica al crear de manera efectiva múltiples
fibras virtuales, cada una de las cuales puede transportar varios gigabits de tráfico por segundo.
Esto proporciona un gran aumento en la cantidad de ancho de banda disponible conservando la
infraestructura de fibra existente. Análogamente se espera que los OXCs (optical cross-connects)
se conviertan en la opción preferida para la conmutación de flujos de datos de gigabits o incluso
terabits, ya que evita el procesamiento electrónico por paquete.
El tráfico predominante transportado sobre las redes de datos estará basado en IP. Esto sugie-
ra que será necesario el desarrollo de tecnologías de router rápidas para agregar flujos más lentos
de datos sobre flujos adecuados para los OXCs. Igualmente es muy probable que el multiplexado
estadístico basado en paquetes IP sea la tecnología de multiplexado predominante para flujos de
datos más pequeños que los adecuados para DWDM.
Mientras las capacidades de los routers y OXCs aumentan rápidamente, las altas tasas de
datos del transporte óptico sugieren la posibilidad de eliminar las capas SONET/SDH y ATM. Para
llegar a este punto los routers, OXCs y DWDMs deben implementar las funciones necesarias de
dichas capas.
Como resultado final obtendremos una red más sencilla y eficiente en coste que transportará
un amplio rango de flujos de datos y volúmenes de tráfico muy elevados.

-5-
 Arquitectura GMPLS

Figura 1.- Evolución hacia redes fotónicas

En los últimos años el enrutamiento IP ha evolucionado para incluir nuevas funcionalidades

desarrolladas en la arquitectura MPLS (multiprotocol label switching). Recientemente se ha exten-
dido MPLS como un plano de control que puede utilizarse con nuevos dispositivos como los OXCs.
Esta generalización proporciona el plano de control común estandarizado necesario en la evolu-
ción de redes ópticas abiertas e interoperables. En primer lugar, un plano de control común simpli-
fica las operaciones y la gestión, lo que reduce el coste de las operaciones. En segundo lugar, un
plano de control común proporciona un amplio rango de escenarios de desarrollo.
Este documento describe la arquitectura de GMPLS (Generalized MPLS). GMPLS extiende
MPLS para incluir nuevos tipos de conmutación: división en el tiempo, longitud de onda y espa-
cial. El principal foco de GMPLS es el plano de control de estas diversas capas de conmutación, ya
que cada una de ellas puede utilizar físicamente distintos planos de datos o de envío.

1.1. Tipos de conmutación y jerarquía de enrutamiento

GMPLS soporta múltiples tipos de conmutación: conmutación TDM, lambda y por fibra
(puerto). Para incluir estos tipos adicionales de conmutación se han extendido ciertas funciones
base de MPLS. Estos cambios y añadidos afectan a las propiedades básicas de los LSP, a cómo se
solicitan y comunican las etiquetas, a la naturaleza unidireccional de los LSPs, a cómo se propagan
los errores y a la información proporcionada para sincronizar los LSR de entrada y salida (fronte-
ra).
La arquitectura original de MPLS se ha extendido para incluir un nuevo conjunto de interfaces
en los LSR. Estas interfaces se clasifican en:
1. Interfaces PSC: Packet Switch Capable.
Estas interfaces reconocen los límites de paquetes y pueden enviar datos basándose en el
contenido de la cabecera de paquete.
2. Interfaces L2SC: Layer-2 Switch Capable.
Estas interfaces reconocen los límites de tramas/celdas y pueden enviar datos basándose
en el contenido de la cabecera de las tramas/celdas.
3. Interfaces TDM: Time-Division Multiplex Capable.
Estas interfaces enrutan los datos basándose en la ranura temporal de los datos dentro de
un ciclo de repetición.
4. Interfaces LSC: Lambda Switch Capable.

-6-
 Arquitectura GMPLS

Estas interfaces enrutan los datos basándose en la longitud de onda sobre la que se reci-
ben los datos.
5. Interfaces FSC: Fiber-Switch Capable.
Estas interfaces enrutan los datos basándose en la posición en que se reciben éstos en el
espacio físico (puerto).

Un circuito sólo puede ser establecido entre interfaces del mismo tipo. Genéricamente todos
los distintos tipos de circuitos que se pueden establecer entre dos interfaces del mismo tipo reciben
el nombre de LSPs (Label Switched Path).
Un LSP puede anidarse dentro de otro creándose una jerarquía de LSPs. Para hacer esto se
considera el LSP como un enlace en la base de datos «link-state» de OSPF o IS-IS.

Figura 2.- Jerarquía de LSPs

En lo alto de la jerarquía se encuentran las interfaces FSC, seguidas de las interfaces LSC, a
continuación se encuentran las interfaces TDM seguidas por las interfaces L2SC y por último se
encuentran las interfaces PSC.
Los LSPs que entran y abandonan el dominio del transporte óptico en el mismo nodo pueden
agregarse y ser encapsulados en un único LSP. Esta agregación permite conservar el número de
lamdas que se utilizan en el dominio MPLS.
La jerarquía de LSPs también ayuda a tratar con la naturaleza discreta del ancho de banda
óptico. Cuando se establece un LSP, éste obtiene un ancho de banda discreto (pongamos 2.488 Gb/
s). Sin embargo, cuando este LSP óptico se trata como un enlace su ancho de banda no tiene porqué

-7-
 Arquitectura GMPLS

ser discreto. Un LSP de 100 Mb/s que atraviesa el dominio de transporte óptico puede ser encapsulado
en un LSP óptico, quedando 2.388 Gb/s para otros LSPs.

1.2. Extensiones del plano de control de MPLS

GMPLS extiende los planos de control originales de MPLS y/o MPLS-TE para soportar cada
una de las cinco interfaces definidas anteriormente.
El plano de control de GMPLS se compone de protocolos de señalización y enrutamiento
conocidos que han sido modificados para soportar GMPLS. Estos protocolos utilizan direcciones
IPv4 y/o IPv6. Sólo se necesita un protocolo especializado para soportar las operaciones de GMPLS:
un protocolo para la gestión de enlaces, Link Management Protocol (LMP).
LMP proporciona mecanismos para mantener la conectividad del canal de control, verificar
la conectividad física de los enlaces de datos, correlar la información de propiedad del enlace y
gestionar los fallos en los enlaces.
LMP está definido en el contexto de GMPLS, pero está especificado independientemente de
la señalización GMPLS, por lo que puede utilizarse en otros contextos y con otros protocolos de
señalización.
Los protocolos de señalización y enrutamiento de MPLS requieren al menos un canal de
control bidireccional para comunicar incluso si dos nodos adyacentes están conectados mediante
enlaces unidireccionales. LMP puede establecer, mantener y gestionar estos canales de control.
Los canales de control pueden transportarse «en banda» o «fuera de banda».
La mayoría de tecnologías que se pueden utilizar por debajo del nivel PSC requieren cierto
nivel de ingeniería de tráfico. El establecimiento de LSPs a estos niveles tienen que tener en cuenta
ciertas restricciones que no permiten utilizar el algoritmo SPF. En su lugar se utiliza enrutamiento
SPF basado en restricciones. Los nodos que establecen los LSPs necesitan más información sobre
los enlaces que la proporcionada por los protocolos estándar intra-dominio. Estos atributos TE son
distribuidos utilizando los mecanismos ya existentes en los protocolos IGP.
GMPLS extiende dos protocolos «link-state» intra-dominio tradicionales OSPF-TE e IS-IS-
TE. Esto es necesario para codificar y transportar uniformemente la información de un enlace TE.
Un enlace TE, por definición, es una representación en los anuncios de estados de los enlaces de los
protocolos OSPF e IS-IS y en la base de datos de estados de los enlaces de ciertos recursos físicos
y sus propiedades entre dos nodos GMPLS.
GMPLS amplía los protocolos de señalización RSVP-TE y CR-LDP aunque no especifica
cuál de ellos debe ser utilizado. La nueva señalización deberá soportar la creación de rutas especí-
ficas (source routing), transportar los parámetros requeridos del LSP (ancho de banda, tipo de
señal, protección y/o restauración deseada, posición en un determinado multiplex, etc.) para los
nuevos tipos de interfaces.
GMPLS introduce mejoras en la escalabilidad como la creación de LSPs jerárquicos, la agru-
pación de enlaces y los enlaces no numerados.

1.3. Extensiones de GMPLS sobre MPLS-TE

A continuación se enumeran una serie de extensiones que incorpora GMPLS sobre MPLS-

-8-
 Arquitectura GMPLS

TE. Algunas de las extensiones que se van a enumerar son mejoras clave para el control de las
capas TDM, LSC y FSC.

„ En MPLS-TE los enlaces que atraviesa un LSP pueden incluir una mezcla de enlaces con
codificaciones de etiquetas heterogéneas (p.ej. enlaces entre routers, routers y ATM-
LSRs y enlaces entre ATM-LSRs). GMPLS amplía esto al incluir enlaces donde la eti-
queta se codifica como una ranura temporal (time slot), una longitud de onda o una
posición en el espacio físico del mundo real.
„ En MPLS-TE un SLP que transporta IP debe empezar y terminar en un router. GMPLS
extiende esto al requerir que un LSP comience y termine en un tipo similar de LSR.
„ El tipo de carga que puede ser transportada en GMPLS por un LSP se extiende para
permitir cargas tales como SONET/SDH, G.709, 1 ó 10 GbEthernet, etc.
„ El uso de las adyacencias de enrutamiento (FA) proporciona un mecanismo que puede
mejorar la utilización del ancho de banda, cuando dicho ancho de banda sólo puede ser
asignado en unidades discretas, así como un mecanismo para agregar el estado de envío,
permitiendo así reducir el número de etiquetas requeridas.
„ GMPLS permite a un nodo sugerir una etiqueta en la solicitud de establecimiento de un
LSP para reducir el tiempo de latencia. Esta sugerencia puede ser ignorada por el nodo de
bajada, lo que provocaría, en algunos casos, una mayor latencia en el establecimiento del
LSP.
„ GMPLS amplía el concepto de restricción del rango de etiquetas que puede ser seleccio-
nado por el nodo de bajada. En GMPLS un nodo de subida puede restringir las etiquetas
de un LSP a través de un único salto o a través de todo el camino del LSP. Este mecanis-
mo es útil en redes fotónicas donde la conversión de longitud de onda puede no estar
disponible.
„ GMPLS soporta el establecimiento de LSPs bidireccionales.
„ GMPLS permite que un LSP termine en un puerto específico de salida: selección del
puerto de destino.
„ GMPLS con RSVP-TE soporta un mecanismo específico de RSVP para la rápida notifi-
cación de fallos.
Otras diferencias importantes entre GMPLS y MPLS-TE son:

„ En las interfaces TDM, LSC y FSC la asignación de ancho de banda para un LSP sólo
puede realizarse en unidades discretas.
„ Es de esperar tener (muchas) menos etiquetas en los enlaces TDM, LSC o FSC que en los
enlaces PSC o L2SC, porque las primeras son etiquetas físicas en lugar de etiquetas
lógicas.

-9-
 Arquitectura GMPLS

2. Modelo de enrutado y direccionamiento

GMPLS se basa en los modelos de enrutado y direccionamiento IP. Esto implica que las
direcciones IPv4 e IPv6 se utilizan para identificar las interfaces y que los protocolos de enrutamiento
distribuidos tradicionales también se utilizan. El descubrimiento de la topología y el estado de los
recursos de todos los enlaces en un dominio de enrutado se consigue a través de estos protocolos.
Dado que el plano de control y el de datos están desacoplados en GMPLS, un vecino del
plano de control no tiene porqué serlo del plano de datos, por ello se requieren mecanismos como
el LMP para asociar los enlaces TE con los nodos vecinos.
Las direcciones IP no se utilizan únicamente para identificar interfaces en hosts IP y routers.
De manera más general, identifican cualquier interfaz PSC y no PSC. De igual manera, los proto-
colos de enrutamiento IP se utilizan para encontrar rutas para los datagramas IP con un algoritmo
SPF y también para encontrar rutas para circuitos no PSC utilizando un algoritmo CSPF.
En un modelo superpuesto, cada capa no PSC particular se puede ver como un conjunto de
sistema autónomos (AS) interconectados de manera arbitraria. Análogamente al enrutado tradicio-
nal IP, cada AS es gestionado por un única autoridad administrativa.
El intercambio de la información de enrutado entre ASs puede realizarse a través de un pro-
tocolo de enrutamiento entre dominios como BGP-4. Cada AS puede estar subdividido en distintos
dominios de enrutamiento y cada uno puede ejecutar un protocolo de enrutamiento intra-dominio.
Cada dominio de enrutamiento puede estar dividido en áreas. Un RD (routing domain) se
compone de nodos habilitados para GMPLS. Estos nodos pueden ser nodos de frontera (edge) o
LSRs internos.
GMPLS define extensiones a los protocolos de enrutamiento intra-dominio OSPF e IS-IS.
Estas extensiones son necesarias para diseminar características estáticas y dinámicas relacionadas
con los nodos y los enlaces.

2.1. Direccionamiento de capas PSC y no PSC

Al utilizar direcciones IPv4 y/o IPv6 no tenemos que situarlas en el mismo espacio de
direccionamiento que las direcciones públicas utilizadas en Internet. Se pueden utilizar las direc-
ciones IP privadas si no tienen que ser intercambiadas con ningún otro operador. En caso contrario
se requieren direcciones IP públicas. Si se utiliza un modelo integrado, dos capas pueden utilizar el
mismo espacio de direccionamiento.
Los espacios de direccionamiento de IPv4/IPv6 son más que suficientes para acomodar cual-
quier capa no PSC. Podemos esperar, de manera razonable, tener muchos menos dispositivos no
PSC que hosts y routers hoy en día.

2.2. Mejoras de escalabilidad en GMPLS

En las capas TDM, LSC y FSC podemos tener varios cientos de enlaces físicos paralelos que
conectan dos nodos. Esto introduce nuevas restricciones en los modelos de direccionamiento y
enrutado IP.
Los nuevos sistemas DWDM permitirán varios cientos de longitudes de onda por fibra.

- 10 -
 Arquitectura GMPLS

Se hace impracticable asociar una dirección IP a cada extremo de cada enlace físico para
representar cada enlace como una adyacencia de enrutamiento distinta y para anunciar y mantener
estados de enlaces para cada uno de estos enlaces. Con este propósito GMPLS amplía los modelos
de enrutado y direccionamiento, para aumentar su escalabilidad.
Se pueden utilizar dos mecanismos para aumentar la escalabilidad del direccionamiento y
enrutado: enlaces no numerados y agrupamiento de enlaces. Estos mecanismos se pueden combi-
nar. Para implementarlos se necesitan extensiones en los protocolos de señalización (RSVP-TE y
CR-LDP) y enrutamiento (OSPF-TE e IS-IS-TE)

2.3. Extensiones TE para los protocolos de enrutamiento IP.

Tradicionalmente, un enlace TE es anunciado como adjunto a un enlace OSPF o IS-IS "nor-
mal". En el anuncio de un enlace se incluyen las propiedades del enlace (métrica SPF básicamente)
y las propiedades TE del enlace.
GMPLS cambia esta noción de tres maneras:
“ Primero, los enlaces que no son PSC pueden tener propiedades TE; sin embargo no se
puede establecer una adyacencia OSPF directamente en dichos enlaces.
“ Segundo, un LSP puede ser publicado como un enlace TE punto a punto en el protocolo
de enrutamiento como una adyacencia de enrutamiento (FA); así, un enlace TE anuncia-
do no tiene que estar entre dos vecinos OSPF directos.
“ Tercero, se puede anunciar una cantidad indeterminada de enlaces como un único enlace
TE (para mejorar la escalabilidad, p.e.), por lo que de nuevo no hay una relación uno a
uno entre una adyacencia regular y un enlace TE.
De esta manera tenemos una noción más general de un enlace TE. Un enlace TE es un enlace
lógico con propiedades TE, algunos de los cuales pueden ser configurados en los LSR anunciantes,
otros pueden obtenerse de otros LSRs mediante algún protocolo y otros pueden deducirse del/de
los componente/s del enlace TE.
Una propiedad importante de un enlace TE está relacionada con el ancho de banda disponible
en dicho enlace. GMPLS definirá diferentes reglas de gestión de la disponibilidad para las distintas
capas no PSC. Los atributos genéricos del ancho de banda están definidos por las extensiones de
enrutamiento TE y por GMPLS, como el ancho de banda no reservado, el máximo ancho de banda
reservable, el máximo ancho de banda del LSP.
En un entorno dinámico se espera tener cambios frecuentes en la información de distribución
del ancho de banda. Se puede implementar una política flexible para generar actualizaciones del
estado de los enlaces basadas en umbrales de ancho de banda y mecanismos de link-dampening.
Las propiedades TE asociadas a un enlace deberían incluir características relacionadas con la
protección y restauración. Por ejemplo, la protección compartida podría combinarse de manera
elegante con las agrupaciones. Los mecanismos de protección y restauración son aplicables a MPLS.
Se espera que sean desarrollados en primer lugar para MPLS y a continuación generalizados para
GMPLS.
Un enlace TE entre una pareja de LSRs no implica la existencia de una adyacencia IGP entre

- 11 -
 Arquitectura GMPLS

dichos LSRs. Un enlace TE también debe tener medios para que el LSR anunciante pueda saber de
su existencia (por ejemplo, utilizando hellos LMP). Cuando un LSR sabe que un enlace TE está en
funcionamiento y es capaz de determinar las propiedades TE del enlace Te, el LSR puede anunciar
dicho enlace a sus vecinos OSPF o IS-IS (ampliados por GMPLS) utilizando los objetos TE /
TLVs. Los interfaces sobre los que se establecen las adyacencias OSPF o IS-IS ampliados se lla-
man "canales de control".

3. Enlaces no numerados.
Los enlaces o interfaces no numerados son enlaces o interfaces que no tienen una dirección
IP. Utilizar estos enlaces implica dos necesidades: la necesidad de especificar enlaces no numera-
dos en la señalización MPLS TE y la necesidad de transportar información (TE) sobre los enlaces
no numerados en las extensiones IGP TE de ISIS-TE y OSPF-TE.
A. La necesidad de especificar los enlaces no numerados en la señalización MPLS TE re-
quiere la extensión de los protocolos RSVP-TE y CR_LDP. La señalización MPLS-TE no propor-
ciona soporte para los enlaces no numerados. GMPLS define extensiones simples para marcar un
enlace no numerado utilizando dos objetos/TLVs: Explicit Route Object y Record Route Object.
Los enlaces no numerados necesitan algún tipo de identificador en cada extremo, local para
el LSR al que pertenece el enlace, para los propósitos de MPLS-TE. Los LSRs situados en los
extremos de un enlace no numerado intercambian los identificadores que ellos mismos asignan al
enlace. El intercambio de identificadores puede llevarse a cabo por configuración, utilizando un
protocolo como LMP ([LMP]), por medio de los protocolos RSVP o CR-LDP (especialmente en el
caso de que un enlace sea una adyacencia de enrutamiento (FA)), o por medio de las extensiones
IS-IS o OSPF ([ISIS-GMPLS], [OSPF-GMPLS]).
En un enlace no numerado entre los LSRs A y B, cada LSR elige un identificador para dicho
enlace. Desde el punto de vista de A, el identificador que él ha asignado al enlace es el "identificador
local", mientras que el identificador que B ha asignado al enlace es el "identificador remoto".
El nuevo sub-objeto/sub-TLV Unnumbered Interface ID del objeto/TLV ER contiene el Router
ID del LSR del extremo del canal de subida del enlace no numerado y el identificador de la interfaz
de salida o identificador local del enlace con respecto a dicho LSR de subida.
El nuevo sub-objeto Unnumbered Interface ID del objeto RR contiene el identificador de la
interfaz de salida con respecto al LSR que la añade en el objeto RR.
B. La necesidad de transportar información (TE) sobre los enlaces no numerados en las ex-
tensiones IGP TE requiere nuevos sub-TLVs para el TLV de alcanzabilidad extendido de IS defini-
do en ISIS-TE y para el TE LSA (LSA opaco) definido en OSPF-TE. Se definen un sub-TLV
Identificador de Enlace Local (Link Local Identifier) y un sub-TLV Indentificador de Enlace Re-
moto (Link Remote Identifier).

3.1. Adyacencias de Enrutamiento no numeradas.

Si un LSR que origina un LSP anuncia que este LSP es una FA no numerada en IS-IS o OSPF,
o el LSR utiliza esta FA como un enlace no numerado que forma parte de un enlace agrupado, el

- 12 -
 Arquitectura GMPLS

LSR debe asignar un identificador de interfaz (Interface ID) a dicha FA. Si el LSP es bidireccional,
el otro extremo hace lo mismo y asigna un identificador de interfaz a la FA inversa.
Se ha modificado la señalización para transportar el identificador de interfaz de una FA en el
nuevo objeto/TLV LSP Tunnel Interface. Este objeto/TLV contiene el Router ID y el Interface ID
(identificador de interfaz) del LSR que lo genera. Se le llama Forward Interface ID cuando aparece
en un mensaje Path/REQUEST y Reverse Interface ID cuando aparece en el mensaje Resv/
MAPPING.

4. Agrupación de enlaces.
El concepto de agrupación de enlaces es fundamental en ciertas redes que emplean el plano
de control de GMPLS tal como viene definido en [BUNDLE]. Si consideramos una red óptica
mallada donde los OXCs (optical cross-connects, LSRs) adyacentes están conectados por varios
cientos de longitudes de onda paralelas, se debería anunciar por separado cada longitud de onda
que pueda ser utilizada si empleamos los protocolos de enrutamiento "link-state", como OSPF o
IS-IS, con las adecuadas extensiones para el descubrimiento de recursos.
Cuando se conectan una par de LSPs mediante múltiples enlaces, es posible publicar varios
(o todos) estos enlaces como un único enlace en OSPF y/o IS-IS. A este proceso se le denomina
agrupación de enlaces (Link Bundling) o simplemente agrupación (bundling). Al enlace lógico
resultante se le denomina enlace agrupado (bundled link) y sus enlaces físicos son enlaces compo-
nentes (component links), identificados por los índices de la interfaz.
Una combinación de los tres identificadores (identificador de enlace (agrupado), identificador
de enlace componente y etiqueta) es suficiente para identificar el recurso apropiado utilizado por
un LSP sin ambigüedad.
El propósito de la agrupación de enlaces es mejorar la escalabilidad del enrutamiento al
reducir la cantidad de información que tienen que manejar los protocolos OSPF o IS-IS. Esto se
consigue mediante la agregación/abstracción de la información, perdiendo con ello algo de la in-
formación.. Para limitar la cantidad de pérdidas es necesario restringir el tipo de información que
puede ser agregada/abstraída.

4.1. Restricciones en la agrupación

Para agrupar enlaces se necesitan las siguientes restricciones. Todos los enlaces componen-
tes en una agrupación deben empezar y terminar en el mismo par de LSRs y compartir algunas
características comunes o propiedades definidas en OSPF-TE] y ISIS-TE]. Dentro de estas carac-
terísticas comunes se encuentran:
-Tipo de enlace (p.ej. punto a punto o multi-acceso).
-Métrica TE (p.ej. un coste administrativo)
-Conjunto de Clases de Recursos en cada extremo de los enlaces.
Un FA también puede ser un enlace componente. De hecho, una agrupación puede consistir
en una mezcla de enlaces punto a punto y FAs, pero todos compartiendo algunas propiedades

- 13 -
 Arquitectura GMPLS

comunes.

4.2. Consideraciones de enrutamiento para la agrupación

Un enlace agrupado es otra clase de enlace TE. El tiempo de vida de un enlace agrupado
viene determinado por el tiempo de vida de cada uno de sus enlaces componentes. Un enlace
agrupado se mantiene con vida mientras al menos uno de sus enlaces componentes siga vivo. La
vida de un enlace componente puede ser determinada de distintas maneras: hellos de OSPF o IS-IS
sobre el enlace componente, un Hello de RSVP (hop local), hellos LMP (enlace local) o a partir de
indicaciones de las capas 1 ó 2.
Una vez se ha determinado que un enlace agrupado está vivo, puede ser anunciado como un
enlace TE y la información TE puede ser difundida (flooding). Si los hellos de IS-IS/OSPF se
ejecutan sobre los enlaces componentes, la inundación se puede restringir a sólo uno de los compo-
nentes.
Crear un enlace agrupado consiste en agregar los parámetros TE idénticos de cada enlace
componente individual para producir parámetros TE agregados. Algunos parámetros pueden ser
sumas de características de los componentes, como el ancho de banda no reservado y el máximo
ancho de banda reservable.
Un nodo GMPLS con enlaces agrupados debe aplicar el control de admisión en base a cada
uno de sus enlaces componentes.

4.3. Consideraciones de señalización

En una ruta explícita de un LSP se elige el enlace agrupado que deberá utilizar el LSP, pero
no el/los enlace/s componente/s, ya que la información de dichos enlaces no es difundida.
La elección del enlace componente a utilizar la realiza el nodo de subida. Si el LSP es
bidireccional, el nodo de subida elige un enlace componente en cada dirección.
Existen tres mecanismos para comunicar esta elección al nodo de bajada:
-Indicación implícita. Este mecanismo requiere que cada enlace componente tenga un canal
de señalización dedicado. El nodo de subida le dice al receptor qué enlace componente utilizar al
enviar el mensaje sobre el canal de señalización dedicado de dicho enlace componente.
-Indicación explícita por ID de interfaz numerado. Este mecanismo requiere que el enlace
componente tenga una única dirección IP remota.
-Indicación explícita por ID de interfaz no numerado. En este mecanismo se asigna un
identificador de interfaz único (valor de 32 bits) a cada enlace componente no numerado.
Los dos últimos mecanismos no requieren que cada enlace componente tenga su propio canal
de control. De hecho, ni siquiera es necesario que el enlace completo tenga su propio canal de
control.

4.4. Enlace agrupado no numerado

Un enlace agrupado puede estar numerado o no numerado independientemente de si los
enlaces componente están numerados o no. Esto afecta a cómo se publica el enlace agrupado en IS-
IS/OSPF y al formato de los objetos ER del LSP que atraviesan el enlace agrupado.

- 14 -
 Arquitectura GMPLS

Los Identificadores de Interfaz no numerados de todos los enlaces de salida no numerados de

un determinado LSR (ya sean enlaces componentes, FAs o enlaces agrupados) deben ser únicos en
el contexto de dicho LSR.

4.5. Creación de enlaces agrupados

La regla genérica para agrupar enlaces componentes es situar los enlaces que estén correlados
de alguna manera en la misma agrupación. Si los enlaces pueden estar correlados según múltiples
propiedades, la agrupación puede aplicarse secuencialmente basándose en estas propiedades. La
agrupación de enlaces puede realizarse automáticamente o por configuración.
Este tipo de subdivisión secuencial puede generar varias agrupaciones entre 2 nodos adya-
centes. En la práctica, sin embargo, las propiedades de los enlaces no sería muy heterogéneas entre
dos nodos adyacentes. Así pues, el número de agrupaciones no sería muy elevado.

5. Gestión de enlaces
En GMPLS un par de nodos pueden estar conectados por decenas de fibras. Cada fibra puede
transmitir centenares de longitudes de onda (DWDM). Se pueden combinar múltiples fibras y/o
longitudes de onda en uno a más enlaces agrupados con finalidades de enrutado. Para posibilitar la
comunicación entre nodos para enrutamiento, señalización y gestión de enlaces se deben estable-
cer canales de control entre una pareja de nodos.
La gestión de enlaces se compone de una serie de procedimientos entre nodos adyacentes
que proporcionan servicios locales como la gestión del canal de control, verificación de conectividad
del enlace, correlación de la propiedad del enlace y gestión de fallos. El LMP (Link Management
Protocol) se ha definido para realizar estas operaciones. LMP se inició en el contexto de GMPLS
pero se compone de un conjunto de herramientas genéricas que pueden ser utilizadas en otros
contextos.
La gestión del canal de control y correlación de propiedad del enlace son procedimientos
obligatorios de LMP, mientras que la verificación de conectividad y gestión de fallos son opciona-
les.

5.1. Canal de control y gestión del canal de control

La gestión del canal de control de LMP se utiliza para establecer y mantener canales de
control entre nodos. Los canales de control existen independientemente de los enlaces TE y pueden
utilizarse para intercambiar información del plano de control de MPLS como la señalización,
enrutamiento e información de gestión del enlace.
Una adyacencia LMP se crea entre dos nodos que proporcionan las mismas capacidades
LMP. Varios canales de control pueden estar activos simultáneamente en cada adyacencia. Actual-
mente LMP asume que los canales de control están configurados explícitamente mientras que la
configuración de las posibilidades del canal de control pueden ser negociadas dinámicamente. El/
los canal/es de control entre dos nodos adyacentes no tienen porqué utilizar el mismo medio físico
que los canales de datos entre dichos nodos. Como consecuencia la salud de un canal de control no
se correla necesariamente con la salud de los enlaces de datos y viceversa. En LMP se han desarro-

- 15 -
 Arquitectura GMPLS

llado mecanismos para gestionar los enlaces orientados al aprovisionamiento de enlaces y al aisla-
miento de fallos.
LMP no especifica el mecanismo de transporte de la señalización que se utiliza en el canal de
control, sin embargo señala que los mensajes que viajan por el canal de control tienen que ser
codificados según IP.
Cada canal de control negocia sus parámetros individualmente y mantiene la conectividad
utilizando un protocolo Hello rápido. Esto último es necesario si no se proporcionan mecanismos
para la detección de fallos de enlaces a más bajo nivel.
El protocolo Hello consiste en dos fases: una fase de negociación y una fase «keep-alive». La
fase de negociación permite la negociación de algunos parámetros básicos del protocolo Hello,
como la frecuencia Hello. La fase de «keep-alive» consiste en el intercambio rápido de mensajes
Hello bidireccionales.

5.2. Correlación de propiedad del enlace

Este procedimiento permite añadir enlaces componentes a un enlace agrupado, cambiar el
mecanismo de protección de un enlace, cambiar los identificadores de puerto o cambiar los
identificadores de componentes en una agrupación.
Se define un intercambio de correlación de propiedad del enlace como parte de LMP. Este
intercambio se utiliza para agregar múltiples enlaces de datos en un enlace agrupado y para inter-
cambiar, correlar o cambiar los parámetros de un enlace TE.

5.3. Verificación de la conectividad de un enlace

La verificación de la conectividad de un enlace es un procedimiento opcional que puede
utilizarse tanto para verificar la conectividad física de los enlaces de datos como para intercambiar
los identificadores de enlace que se utilizan en la señalización GMPLS.
Se negocia el uso de este procedimiento en la fase de negociación del protocolo Hello. Este
procedimiento se debe llevar a cabo inicialmente, cuando se establece un enlace de datos y, a
continuación, periódicamente para todos los enlaces de datos libres.
El procedimiento de verificación consiste en enviar mensajes de Test «en banda» sobre los
enlaces de datos. Esto requiere que los enlaces no asignados deben ser opacos. El mensaje de Test
es el único mensaje de LMP que se transmite por el enlace, mientras que los mensajes Hello se
intercambian sobre el canal de control durante el proceso de verificación del enlace.
Para iniciar el procedimiento de verificación del enlace, un nodo debe notificar antes a los
nodos adyacentes que va a empezar a transmitir mensajes Test sobre un enlace de datos en particu-
lar o sobre los enlaces componente de un determinado enlace agrupado. El nodo también debe
indicar el número de enlaces de datos que van a ser verificados, el intervalo al que se enviarán los
mensajes de testeo, el esquema de codificación, los mecanismos de control soportados, tasa de
datos de los mensajes Test y la longitud de onda sobre la que se transmitirán los mensajes Test en el
caso de que los enlaces sean fibras. Además, los identificadores locales y remotos de los enlaces
agrupados se transmiten durante este proceso para realizar la asociación de enlaces componente
con los identificadores del enlace agrupado.

- 16 -
 Arquitectura GMPLS

5.4. Gestión de fallos

En la gestión de fallos se suele incluir la detección, localización y notificación de fallos.
La localización de fallos puede utilizarse para soportar algún mecanismo local específico de
protección/restauración.
En las nuevas tecnologías de conmutación fotónica transparente no se ha definido todavía un
método para la localización de un fallo. La información del fallo se envía fuera de banda (a través
del plano de control).
LMP proporciona un procedimiento para la localización de fallos, notificando un fallo hacia
el nodo de subida de dicho fallo (p.ej. utilizando un procedimiento de notificación de fallos).
Un vecino LMP de bajada que detecta fallos en un enlace de datos enviará un mensaje LMP
a su vecino de subida, notificándole el fallo. Cuando un nodo de subida recibe esta notificación
puede correlar el fallo con los distintos puertos de entrada para determinar si se encuentra entre los
dos nodos. Una vez se ha detectado el fallo se pueden utilizar los protocolos de señalización para
iniciar procedimientos de protección/restauración del enlace o camino.

5.5. LMP para sistemas de línea óptica (OLSs) DWDM

En un entorno totalmente óptico, LMP se centra en las comunicaciones al mismo nivel (p.ej.
OXC-a-OXC). El OLS (Optical Line System o WDM Terminal Multiplexer) tiene una gran canti-
dad de información sobre un enlace entre dos OXCs. Se puede mejorar la utilización de la red
trasladando esta información al plano de control, consiguiendo reducir las configuraciones manua-
les requeridas y ampliando en gran medida la detección y recuperación ante fallos.
La detección de fallos es un elemento clave cuando se utilizan conmutadores PXC. Una vez
la conexión ha sido establecida, los PXCs tienen visibilidad limitada sobre la salud de dicha co-
nexión. En los OLSs típicamente se terminan los canales eléctricamente y se regeneran ópticamen-
te, lo que presenta una oportunidad para monitorizar la salud de un canal entre PXCs. La extensión
de LMP para WDM (LMP-WDM) puede ser utilizada en estos casos por el OLS para proporcionar
esta información al PXC. LMP-WDM define extensiones a LMP para su utilización entre un OXC
y un OLS.
LMP-WDM también soporta el envío de información conocida por el OXC al OLS. Esta
información puede ser útil para la gestión de alarmas y monitorización del enlace. En la gestión de
alarmas esta información es importante ya que el OXC conoce el estado administrativo de una
conexión (esta información puede haberla adquirido a través del objeto Admin Status de la señali-
zación GMPLS). Este estado puede ser utilizado para suprimir alarmas espúreas. El OXC puede
inhibir la notificación de alarma del OLS cuando una conexión está inactiva («down»), en prueba
(«testing») o está siendo eliminada.
Existen muchas similitudes entre una sesión LMP OXC-OXC y una sesión LMP OXC-OLS,
particularmente para la gestión del control y verificación del enlace. Sin embargo también existen
algunas diferencias atribuidas generalmente a la naturaleza del enlace OXC-OLS y al propósito de
las sesiones LMP OXC-OLS. Los enlaces OXC-OXC pueden utilizarse para proporcionar las ba-

- 17 -
 Arquitectura GMPLS

ses para la señalización y enrutamiento GMPLS en la capa óptica. La información intercambiada

en las sesiones LMP-WDM se utiliza para aumentar el conocimiento sobre los enlaces entre OXCs.
Un OXC puede relacionarse con uno o más OLSs al igual que un OLS puede comunicarse con uno
o más OXCs.
Para que la información intercambiada en las sesiones LMP OXC-OLS pueda utilizarse en
una sesión OXC-OXC, el OXC debe coordinar dicha información. Sin embargo, las sesiones LMP
OXC-OXC y OXC-OLS se ejecutan independientemente y deben ser mantenidas por separado. Un
requerimiento crítico cuando se ejecuta una sesión LMP OXC-OLS es la capacidad del OLS para
hacer el enlace de datos transparente cuando no se está realizando el procedimiento de verifica-
ción. Esto se debe a que el mismo enlace de datos puede ser verificado entre OXC-OLS y entre
OXC-OXC. El procedimiento de verificación de LMP se utiliza para coordinar el procedimiento de
Test (y de ahí la transparencia/opacidad de los enlaces de datos). Para mantener la independencia
entre las sesiones debe ser posible establecerlas en cualquier orden.

6. Señalización generalizada
La señalización GMPLS extiende ciertas funciones básicas de los protocolos de señalización
RSVP-TE y CR-LDP y en algunos casos añade funcionalidades. Estos cambios afectan a las pro-
piedades básicas de los LSPs, a cómo se solicitan y comunican las etiquetas, a la naturaleza
unidireccional de los LSPs, a cómo se propagan los errores y a la información proporcionada para
sincronizar el ingreso y la salida.
La especificación de la señalización GMPLS se compone de tres partes:
1. Una descripción de la funcionalidad de la señalización.
2. Extensiones RSVP-TE.
3. Extensiones CR_LDP.
La señalización GMPLS define sobre MPLS-TE los siguientes bloques constructivos:
1. Un nuevo formato de solicitud de etiqueta genérico.
2. Etiquetas para las interfaces TDM, LSC y FSC llamada Etiqueta Generalizada.
3. Soporte para la conmutación de una banda de longitudes de onda.
4. Sugerencia de etiqueta por el canal de subida con propósitos de optimización.
5. Restricción de etiquetas por el canal de subida para soportar restricciones ópticas.
6. Establecimiento de LSPs bidireccionales con resolución de contiendas.
7. Extensiones para la notificación de fallos rápida.
8. Información de protección centrándose actualmente en la protección del enlace más in-
dicación de LSP primario y secundario.
9. Enrutamiento explícito con control explícito de etiquetas para un grado de control fino.
10. Parámetros específicos de tráfico por tecnología.
11. Manejo del estado administrativo del enlace.
GMPLS es una arquitectura genérica con muchas opciones. Sólo los bloques constructivos 1,
2 y 10 son obligatorios y sólo dentro del formato específico requerido. Los bloques 6 y 9 normal-
mente deberían ser implementados. Los bloque constructivos 3, 4, 5, 7, 8 y 11 son opcionales.

- 18 -
 Arquitectura GMPLS

Una red por conmutación de longitud de onda típica implementaría los bloques constructivos
1, 2 (el formato genérico), 4, 5, 6, 9 10 y 11. El bloque 3 sólo sería necesario en la conmutación por
bandas de longitudes de onda (waveband switching).
A continuación veremos las mejoras que GMPLS ha introducido en los protocolos de señali-
zación RSVP-TE y CR-LDP.

6.1. Conmutación por bandas de longitudes de onda

Un caso especial de conmutación por longitudes de onda es la conmutación por bandas de
longitudes de onda. Una banda de longitudes de onda (waveband) representa un conjunto de longi-
tudes de onda contiguas que pueden ser conmutadas conjuntamente a una nueva banda. Por moti-
vos de optimización podría ser aconsejable conmutar múltiples longitudes de onda como una uni-
dad para un PXC. Esto podría reducir la distorsión de las longitudes de onda individuales y permitir
una separación más estrecha de las mismas. Se define una etiqueta de banda de longitudes de onda
para soportar este caso especial.

6.2. Sugerencia de etiqueta

La señalización GMPLS permite que un nodo de subida sugiera una etiqueta. Esta sugeren-
cia es una optimización que podría ser ignorada por un nodo de bajada a costa de un mayor tiempo
de establecimiento del LSP y quizá con una distribución sub-óptima de los recursos de red. La
etiqueta sugerida es particularmente importante cuando se quiere establecer un LSP bidireccional
en el mismo puerto físico (p.ej. una pareja Tx/Rx de transpondedores WDM) o para establecer un
LSP que atraviese cierta clase de equipos en los que hay una latencia asociada a la configuración
del conmutador (switching fabric). La etiqueta sugerida también es útil en subredes ópticas con
capacidad limitada de conversión de longitudes de onda donde la asignación de la longitud de onda
puede realizarse en el nodo que origina el LSP óptico para minimizar la probabilidad de bloqueo.

Figura 3.- R0 genera una petición de camino (Path) y la envía a R1. En R1 (nodo frontera) se genera la petición de
un nuevo LSP (LSP2) desde R1 hasta R9. Estas peticiones dinámicas de creación de LSPs son generadas hasta que
se crea el camino 4 en O3. A continuación del establecimiento del LSP4 el mensaje de Path 3 se encapsula en el

- 19 -
 Arquitectura GMPLS
LSP4. Este proceso de creación de LSPs y de petición de establecimiento de un LSP de nivel inferior encapsulada
en el LSP de nivel superior ya creado continúa hasta que el LSP inicial (LSP1) se crea satisfactoriamente.

El concepto de etiqueta sugerida permite que un nodo de subida del camino de servicio
empiece a configurar su hardware con la etiqueta sugerida antes de que el nodo de bajada le comu-
nique una etiqueta. En el caso de un conmutador MEM se tienen que posicionar los micro-espejos.
Este movimiento puede consumir algo de tiempo. La configuración temprana ofrecida por una
etiqueta sugerida puede reducir la latencia de establecimiento. También puede ser importante para
propósitos de restauración, cuando se necesita que se establezcan LSPs alternativos rápidamente.
Sin embargo, si un nodo de bajada rechaza la etiqueta sugerida y envía una distinta, el nodo de
subida debe aceptar dicha etiqueta manteniéndose el control de bajada para la asignación de etique-
tas. En esa situación se configura el conmutador en la dirección contraria (la normal), y puede ser
necesario retardar la propagación del mensaje Resv/Mapping en la dirección de subida durante la
operación de asignación de la etiqueta para establecer un camino de envío utilizable.

6.3. Restricción de etiquetas por el canal de subida

Un nodo de subida puede opcionalmente restringir (limitar) la selección de una etiqueta por
el nodo de bajada a un conjunto de etiquetas aceptables. Se pueden proporcionar listas y/o rangos
inclusivos o exclusivos de etiquetas en un objeto Label Set. Si no se utiliza este mecanismo, todas
las etiquetas del rango válido pueden ser utilizadas. Existen al menos cuatro casos en los que la
restricción de etiquetas puede ser útil en el dominio óptico:
1. Cuando el equipo del extremo sólo es capaz de transmitir y recibir un pequeño conjunto de
bandas/longitudes de onda.
2. Cuando hay una secuencia de interfaces que no soportan la conversión de longitud de onda
y requieren utilizar la misma extremo a extremo a lo largo de una secuencia de saltos o
incluso del camino entero.
3. Cuando se desea limitar la cantidad de conversiones de longitud de onda para reducir la
distorsión de las señales ópticas.
4. Cuando los dos extremos de un enlace soportan conjuntos distintos de longitudes de onda.
El receptor de un objeto Label Set debe restringir su selección de etiquetas a una que perte-
nezca a dicho Label Set. Un Label Set puede estar presente a lo largo de múltiples saltos. En este
caso, cada nodo genera su propio Label Set de salida basado probablemente en el Label Set de
entrada y en las capacidades hardware del nodo.

6.4. LSPs bidireccionales

GMPLS permite el establecimiento de LSPs bidireccionales simétricos. Un LSP simétrico
bidireccional tiene los mismos requerimientos TE en cada dirección. El termino iniciador se refie-
re al nodo que empieza el establecimiento de un LSP y terminador se utiliza para referirse al nodo
destino del LSP. En un LSP bidireccional sólo hay un iniciador y un terminador.
En la arquitectura MPLS básica los LSPs son unidireccionales, así que para establecer un
LSP bidireccional se tienen que establecer dos LSPs unidireccionales en direcciones opuestas in-

- 20 -
 Arquitectura GMPLS

dependientemente. Esta solución tiene las siguientes desventajas:

“ La latencia para establecer el LSP bidireccional es igual a un «round-trip time» de seña-
lización más un retardo de tránsito de señalización iniciador-terminador. Esto aumenta la
latencia de establecimiento del LSP y aumenta la latencia del peor caso para descubrir un
LSP fallido. Estos retardos son especialmente significativos cuando se necesita restaurar
un LSPs ante un fallo de la red.
“ El «overhead» de control es dos veces el de un LSP unidireccional ya que se generan
mensajes de control separados para cada segmento del LSP bidireccional.
“ La selección de la ruta puede ser bastante complicada ya que los recursos se establecen
en segmentos distintos. Podrían haber condiciones de carrera (race conditions) lo que
reduce la probabilidad de éxito al establecer la conexión bidireccional.
“ Muchos proveedores de servicio de redes ópticas ven los LSPs ópticos bidireccionales (o
lightpaths) como un requerimiento.
Con los LSPs bidireccionales los caminos de datos de subida y bajada se establecen utilizan-
do un único conjunto de mensajes de señalización. Esto reduce la latencia de establecimiento bási-
camente a un «round-trip time» de iniciador a terminador más el tiempo de procesamiento y limita
el «overhead» de control al mismo número de mensajes que en los LSPs unidireccionales.

6.5. Notificación rápida de fallos

GMPLS define varias extensiones de señalización que permiten la notificación explícita de
fallos y otros eventos a los nodos responsables de la restauración de los LSPs y el manejo de
errores.

6.5.1. Conjunto de etiquetas aceptables para la notificación de un error de etiqueta

Un mensaje de error típico corresponde a un valor de etiqueta no aceptable («Unacceptable
label value»). Cuando ésto ocurre, puede ser útil que el nodo que genera el mensaje de error incluya
un conjunto de etiquetas aceptable mediante el objeto «Acceptable Label Set».

6.5.2. Mensajes de notificación

Un requerimiento clave para proporcionar fiabilidad es que la reacción ante los fallos de red
sea rápida y que se puedan tomar decisiones de manera inteligente. Como parte de la notificación
de fallos, un nodo con conexiones de tránsito debería poder notificar a los nodos responsables de la
restauración de las conexiones, cuándo ocurre un fallo, sin que los nodos intermedios procesen
estos mensajes ni modifique el estado de las conexiones afectadas. El procesamiento innecesario
de los mensajes en los nodos intermedios podría retrasar la notificación e incluso alterar el estado
de la conexión en los mismos.
Se ha añadido el mensaje Notify al protocolo de señalización RSVP-TE para poder informar
a los nodos no adyacentes de los fallos relacionados con el LSP. No se ha definido un mecanismo
similar en el protocolo CR-LDP. El mensaje Notify no reemplaza a los mensajes de error existentes
en RSVP, sin embargo se diferencia de estos en que puede ser destinado a cualquier otro nodo a
parte del vecino de subida o bajada inmediato.

- 21 -
 Arquitectura GMPLS

Una aplicación importante del mensaje Notify es la de notificar cuándo falla el plano de
control pero el plano de datos todavía funciona. En este caso, al enlace se le denomina enlace
degradado. La importancia de este mecanismo radica en el hecho de que en GMPLS los planos de
control y de datos pueden encontrarse físicamente separados y fallar independientemente.
En muchos casos es inaceptable eliminar un LSP simplemente porque haya fallado el plano
de control. Sin embargo, los fallos en el plano de control limitan las características de gestión
proporcionadas por un LSP. Como parte del procedimiento de notificación, en el mensaje Notify se
identifica el LSP afectado y el recurso que ha fallado.

6.6. Protección del enlace

La información de protección se transporta en un nuevo objeto/TLV opcional Protection
Information. Este objeto indica la protección del enlace deseada. Si se solicita un tipo particular de
protección (1+1, 1:N, ...) sólo se procesa la petición de conexión si se puede garantizar dicha
protección. GMPLS anuncia las posibilidades de protección de un enlace en los protocolos de
enrutamiento. El algoritmo de cálculo del camino puede utilizar esta información en el cálculo de
los caminos para establecer un LSP.
La información de protección también indica si el LSP es primario o secundario. Un LSP
secundario es un backup para el LSP primario.
Actualmente hay seis tipos de protección de enlace definidos como indicadores individuales
y se pueden combinar: mejorado, dedicado 1+1, dedicado 1:1, compartido, no protegido, tráfico
extra.
“ Mejorado (enhanced): indica que se debe utilizar un esquema de protección más fiable
que el esquema dedicado 1+1.
“ Dedicado 1+1: indica que se debe utilizar un esquema de protección del enlace dedicado
1+1 para soportar el LSP.
“ Dedicado 1:1: indica que se debe utilizar un esquema de protección del enlace dedicado
1:1 para soportar el LSP.
“ Compartido: indica que se debe utilizar un esquema de protección del enlace compartido
para soportar el LSP.
“ No protegido: indica que el LSP no debe utilizar ningún esquema de protección del enla-
ce.
“ Tráfico extra (Extra traffic): indica que el LSP debería utilizar enlaces que están destina-
dos a proteger a otros enlaces (enlaces secundarios).

7. Adyacencias de enrutamiento (FA)

Para mejorar la escalabilidad puede ser útil agregar varios LSPs en un LSP más grande. Los
nodos intermedios sólo verían el LSP externo, no necesitan mantener estados de envío para cada
LSP interno, se necesita intercambiar menos mensajes de señalización y el LSP externo se puede
proteger en lugar (o además) de los LSPs internos.
Para crear un agregado se siguen los siguientes pasos:

- 22 -
 Arquitectura GMPLS

(a) Un LSR crea un LSP TE.

(b) El LSR conforma una adyacencia de enrutamiento (FA) a partir de dicho LSP (publicán-
dolo como un enlace TE en IS-IS/OSPF).
(c) Se permite a otros LSRs utilizar las FAs para el cálculo de sus caminos.
(d) Se anidan los LSPs originados por otros LSRs en el primer LSP.
Un LSR puede anunciar un LSP como un enlace TE en IS-IS/OSPF. En ese el LSP caso
recibe el nombre de FA-LSP. El enlace publicado que define la ruta tomada por el LSP es la
adyacencia de enrutamiento o FA.
IS-IS/OSPF difunde la información de los FAs de la misma manera que la información del
resto de enlaces. Como consecuencia, en la base de datos de estado de los enlaces de un LSR
aparecen enlaces convencionales y FAs.
Cuando un LSR realiza el cálculo del camino utiliza enlaces convencionales y FAs. Cuando
se ha completado el cálculo, el LSR utiliza RSVP-TE/CR-LDP para marcar las etiquetas a lo largo
del camino.

8. Técnicas de protección y restauración en GMPLS

Un requerimiento clave para el desarrollo de un plano de control común tanto para redes
ópticas como electrónicas es la necesitad de mecanismos que permitan una gestión de fallos inteli-
gente en los protocolos de señalización, enrutamiento y gestión de enlaces. A nivel de conexión la
gestión de fallos consiste en cuatro pasos primarios:
“ Detección
“ Localización
“ Notificación
“ Mitigación
La detección de fallos debería realizarse en la capa más cercana al fallo. En redes ópticas ésta
es la capa física (óptica). Una medida de detección de fallos en la capa física es la detección de
pérdida de luz (LOL, loss of light). Se están desarrollando otras técnicas basadas en la relación
señal a ruido óptica (OSNR), la tasa de error de bit (BER) medida ópticamente, dispersión, diafo-
nía y atenuación.
La localización de fallos requiere la comunicación entre los nodos para determinar dónde ha
ocurrido el fallo. Una consecuencia interesante de utilizar LOL para la detección de fallos es que
dicha LOL se propaga en el sentido de bajada a lo largo de todo el camino de la conexión, permi-
tiendo a todos los nodos de bajada detectar el fallo.
El protocolo LMP incluye un procedimiento de localización de fallos diseñado para localizar
fallos tanto en redes transparentes (all-optical) y opacas (opto-electrónicas). Este mecanismo se
basa en el envío de mensajes «ChannelFail» de LMP entre nodos adyacentes sobre el canal de
control, separado de los canales de datos. Esta separación del plano de control y de datos permite
que se utilice un único conjunto de mensajes para la localización de fallos, independientemente del
esquema de codificación del plano de datos.
Una vez se ha detectado y localizado el fallo se utiliza la protección y restauración para

- 23 -
 Arquitectura GMPLS

mitigarlo. La diferencia entre protección y restauración se centra en las distintas escalas temporales
en las que operan cada una. La protección requiere recursos preasignados y está diseñada para
reaccionar rápidamente ante fallos (menos de un par de centenas de milisegundos). Por ejemplo, la
conmutación de protección automática de SONET (APS) está diseñada para conmutar el tráfico de
un camino primario a uno secundario en menos de 50 ms. Esto requiere la transmisión simultánea
a lo largo de ambos caminos (llamada protección 1+1) con un selector en el nodo de recepción
decidiendo qué camino utilizar. Esta solución requiere el doble de recursos que un camino con una
protección no APS. Por otra parte, la restauración se basa en el establecimiento dinámico de recur-
sos y puede llevar un tiempo un orden de magnitud mayor que la conmutación de protección. La
restauración también conlleva el cálculo dinámico de rutas, que puede ser computacionalmente
caro si los caminos de backup no están precalculados o si los recursos precalculados ya no están
disponibles.
La protección y la restauración se han abordado tradicionalmente utilizando dos técnicas:
conmutación de camino y conmutación de línea. En la conmutación de camino el fallo es tratado en
los extremos del camino (nodos inicial y final) mientras que en la conmutación de línea el fallos se
trata en el nodo de tránsito en el que se detecta el fallo. La conmutación de camino se puede
subdividir en protección de camino, donde se preasignan caminos secundarios de protección y en
restauración de camino, donde las conexiones son re-enrutadas, bien dinámicamente o bien utili-
zando caminos precalculados (pero no preasignados). La conmutación de línea se puede dividir en
protección span, donde se conmuta el tráfico aun canal paralelo alternativo y restauración de línea,
donde el tráfico se conmuta a una ruta alternativa entre los dos nodos (esto implica atravesar nodos
intermedios adicionales)
Para utilizar la protección deben existir mecanismos que permitan:
“ Distribuir las propiedades relevantes del enlace, como el ancho de banda de protección y
las capacidades de protección.
“ Establecer caminos secundarios a través de la red.
“ Señalizar un switch del camino primario al secundario y al revés.

8.1. Mecanismos de protección

La nomenclatura de los mecanismos de protección es la siguiente:
“ Protección 1+1: los datos de carga se transmiten simultáneamente sobre dos caminos
separados y se utiliza un selector en el nodo de recepción para elegir la mejor señal.
“ Protección M:N: se comparten M caminos de backup preasignados entre N caminos pri-
marios, sin embargo, los datos no se replican en el camino de backup, sino que son
asignados y transmitidos por él sólo cuando falla el camino primario.
“ Protección 1:N: se comparte un camino de backup preasignado entre N caminos prima-
rios.
“ Protección 1:1: se preasigna un camino de backup dedicado para un camino primario.
Las protecciones 1:N y 1:1 son casos especiales de la protección M:N.

- 24 -
 Arquitectura GMPLS

8.1.1. Protección Span

La protección span se lleva a cabo entre dos nodos adyacentes y se basa en la conmutación a
un canal o enlace de backup cuando ocurre un fallo. Como parte de las extensiones de enrutamiento
GMPLS, el tipo de protección del enlace se anuncia para que se pueda utilizar la protección span en
el cálculo de la ruta. Una vez se ha seleccionado la ruta, se señaliza la conexión utilizando RSVP-
TE o CR-LDP, incluyendo un vector de bits de protección que indique qué LPTs (link protection
type) son aceptables para dicha conexión.
Cada nodo que proporciona una protección span dedicada 1+1 debe replicar los datos en dos
canales separados. Esto requiere utilizar el doble de ancho de banda de la conexión entre el par de
nodos y la capacidad de replicar los datos en ambos canales. Cuando se detecta un fallo en el nodo
de recepción, éste debe conmutar del canal de trabajo al canal de protección.
En la protección span compartida M:N se tienen que detectar los fallos antes de realizar la
conmutación ya que los datos no se encuentran replicados en los canales primario y de backup.
Cuando se localiza un fallo, el nodo de subida puede iniciar una protección span local enviando un
mensaje de refresco RSVP Path. Los mensajes de refresco del camino son elementos de RSVP que
permiten a los nodos intermedios actualizar el estado de un LSP. Esto permite realizar la conmuta-
ción del canal primario al de reserva. El intercambio previo de la configuración de protección
compartida utilizando LMP minimiza la posibilidad de un conflicto en el canal de backup (etique-
ta) cuando se realiza la conmutación de protección. Cuando el nodo de bajada recibe el mensaje
Path con los nuevos objetos, verifica los parámetros, actualiza el estado de señalización y, o bien
responde con un mensajes Resv con la nueva etiqueta, o bien genera un mensaje de error.

8.1.2. Protección de camino

La protección de camino se realiza en los nodos finales (iniciador y terminador) y requiere la
conmutación a un camino alternativo cuando se produce el fallo.
Una vez se han calculado los dos caminos, la fuente genera dos conexiones enrutadas explí-
citamente con los bits «dedicado 1+1» y «no protegido» activos, respectivamente, en el vector de
bits de protección del correspondiente mensaje de señalización. El establecimiento indica que es-
tos dos caminos desean reservas compartidas. Para la protección de camino 1+1, la conexión se
transmite simultáneamente sobre los dos caminos separados y se utiliza un selector en el nodo
terminador para elegir la mejor señal. En cada nodo en el que los dos caminos se ramifican se debe
replicar los datos en ambas ramas. En los nodos en los que se unen los caminos se debe elegir los
datos de un camino basándose en la integridad de la señal.
En la protección de camino M:N, se pre-establecen M caminos distintos para la protección
compartida de los N caminos principales. Estos caminos secundarios se utilizan para la conmuta-
ción rápida cuando el camino principal falla. Aunque los recursos para estos caminos de backup
están preasignados, el tráfico de baja prioridad puede utilizar estos recursos teniendo en cuenta que
dicho tráfico será bloqueado si se produce un fallo en el camino primario.

8.2. Mecanismos de restauración

La restauración se ha diseñado para reaccionar rápidamente ante fallos, utilizando el ancho

- 25 -
 Arquitectura GMPLS

de banda eficientemente, pero normalmente requiere el establecimiento de recursos y el cálculo de

rutas dinámicamente y por ello le lleva más tiempo conmutar a un camino alternativo que las
técnicas de protección. La restauración se puede implementar en la fuente o en un nodo intermedio
una vez que el nodo responsable haya sido notificado mediante los mecanismos de notificación
mencionados anteriormente o utilizando mensajes de error estándar.

8.2.1. Restauración de línea

Para soportar la restauración de línea se selecciona un nuevo camino en un nodo intermedio.
Esto conlleva que el tráfico atraviese nodos adicionales de tránsito. La restauración de línea puede
ser beneficiosa para las conexiones que atraviesan múltiples saltos y/o largas distancias ya que la
latencia en la notificación del fallo puede verse considerablemente reducida. En este caso sólo se
re-enrutan segmentos de la conexión en lugar del camino entero. La restauración de línea puede
romper los requerimientos TE si hay definida una ruta explícita para la conexión. Las restricciones
utilizadas para enrutar la conexión pueden ser enviadas para que un nodo intermedio que realice la
restauración de línea pueda calcular una ruta alternativa apropiada. Este problema es similar al
problema de establecimiento/mantenimiento de requerimientos TE que atraviesan múltiples áreas.

8.2.2. Restauración de camino

La restauración de camino conmuta el tráfico a una ruta alternativa alrededor del fallo, donde
el nuevo camino se selecciona en el nodo fuente. Se puede optimizar el proceso de restauración,
por ejemplo, precalculando rutas alternativas y guardándolas para uso futuro. Un camino restaura-
do puede reutilizar nodos del camino original y/o incluir nodos intermedios adicionales. Los recur-
sos de los nodos de bajada son reutilizados (compartidos) siempre que sea posible y los recursos de
los nodos intermedios que ya no se necesitan son liberados. Esta compartición de recursos aumenta
las probabilidades de la conexión para conseguir los recursos requeridos cuando el re-enrutado está
en progreso. Si se calculan y preasignan los recursos el reenrutamiento es más rápido ya que dichos
recursos están garantizados a no ser que fallen o que sean reclamados por conexiones de mayor
prioridad.

9. Acrónimos
AS Autonomous System
BGP Border Gateway Protocol
CR-LDP Constraint-based Routing LDP
CSPF Constraint-based Shortest Path First
DWDM Dense Wavelength Division Multiplexing
FA Forwarding Adjacency
FSC Fiber Switched Channel
GMPLS Generalized Multi-Protocol Label Switching
IGP Interior Gateway Protocol
IS-IS Intermediate System to Intermediate System

- 26 -
 Arquitectura GMPLS

LDP Label Distribution Protocol

LMP Link Management Protocol
LSA Link State Advertisment
LSC Lambda Switched Channel
LSR Label Switched Router
LSP Label Switched Path
MPLS Multi-Protocol Label Switching
NMS Network Management System
OSPF Open Shortest Path First
OXC Optical Cross-Connect
PXC Photonic Cross-Connect
RSVP ReSource reserVation Protocol
SDH Synchronous Digital Hierarchy
SPF Shortest Path First
TDM Time-Division Multiplexing
TE Traffic Engineering

10. Referencias y bibliografía

[1] draft-ietf-mpls-generalized-signaling-07.txt, Generalized MPLS - Signaling
Functional Description

[2] draft-ietf-mpls-generalized-rsvp-te-06.txt, Generalized MPLS Signaling - RSVP-TE

Extensions

[3] draft-ietf-mpls-generalized-cr-ldp-05.txt, Generalized MPLS Signaling - CR-LDP

Extensions

[4] draft-ietf-mpls-lmp-02.txt, Link Management Protocol (LMP)

[5] draft-ietf-ccamp-lmp-wdm-00.txt, LMP for WDM Optical Line Systems (LMP-

WDM)

[6] draft-ietf-ccamp-gmpls-routing-02.txt, Routing Extensions in Support of Generalized

MPLS

[7] draft-ietf-ccamp-ospf-gmpls-extensions-04.txt, OSPF Extensions in Support of

Generalized MPLS

[8] draft-ietf-isis-gmpls-extensions-08.txt, IS-IS Extensions in Support of Generalized

MPLS

- 27 -