Issuu on Google+

Arquitectura GMPLS, Generalized Multiprotocol Label Switching WDM

Se帽alizaci贸n IP (RSVP-TE, CR-LDP)


Copyright (c) 2002 by テ]gela 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 principalmente 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 sobrepasaba al tráfico de voz y continuará aumentando en los próximos años. Al mismo tiempo se aumenta 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 transportar 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 proporcionar la capacidad. La escalabilidad de esta arquitectura es muy lenta para volúmenes de tráfico 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 sugiera 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 extendido 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 evolución de redes ópticas abiertas e interoperables. En primer lugar, un plano de control común simplifica 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 espacial. 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 (frontera). 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 reciben 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-ISTE. 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 agrupació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 ATMLSRs y enlaces entre ATM-LSRs). GMPLS amplía esto al incluir enlaces donde la etiqueta 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 seleccionado 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 mecanismo 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 notificació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 protocolos 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 tradicional 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 protocolo 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 direcciones 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 cualquier 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 combinar. 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 "normal". 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 anunciado 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 llaman "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 numerados 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 requiere la extensión de los protocolos RSVP-TE y CR_LDP. La señalización MPLS-TE no proporciona 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 extensiones IGP TE requiere nuevos sub-TLVs para el TLV de alcanzabilidad extendido de IS definido 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 Remoto (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 componentes (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 informació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 componentes 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 caracterí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 componentes. 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 ISIS/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 adyacentes. 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 establecer 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 opcionales. 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. Actualmente 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 aislamiento 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 intercambiar, 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 particular 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 cantidad 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 manuales 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 conexión. En los OLSs típicamente se terminan los canales eléctricamente y se regeneran ópticamente, 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ñalizació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 verificació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 propiedades 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 indicació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 normalmente 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ñalizació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 longitudes de onda contiguas que pueden ser conmutadas conjuntamente a una nueva banda. Por motivos de optimización podría ser aconsejable conmutar múltiples longitudes de onda como una unidad 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 sugerencia 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 comunique 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 etiquetas. 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 pertenezca 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 refiere 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ñalizació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 utilizando un único conjunto de mensajes de señalización. Esto reduce la latencia de establecimiento básicamente 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 enlace. “ Tráfico extra (Extra traffic): indica que el LSP debería utilizar enlaces que están destinados 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ándolo 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 inteligente 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, diafoní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, permitiendo 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 recursos 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 utilizando 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 primarios, 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 primarios. “ 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 RSVPTE 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 conmutació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 (etiqueta) 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 estos 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 conmutació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 restaurado puede reutilizar nodos del camino original y/o incluir nodos intermedios adicionales. Los recursos 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 BGP CR-LDP CSPF DWDM FA FSC GMPLS IGP IS-IS

Autonomous System Border Gateway Protocol Constraint-based Routing LDP Constraint-based Shortest Path First Dense Wavelength Division Multiplexing Forwarding Adjacency Fiber Switched Channel Generalized Multi-Protocol Label Switching Interior Gateway Protocol Intermediate System to Intermediate System

- 26 -


Arquitectura GMPLS LDP LMP LSA LSC LSR LSP MPLS NMS OSPF OXC PXC RSVP SDH SPF TDM TE

Label Distribution Protocol Link Management Protocol Link State Advertisment Lambda Switched Channel Label Switched Router Label Switched Path Multi-Protocol Label Switching Network Management System Open Shortest Path First Optical Cross-Connect Photonic Cross-Connect ReSource reserVation Protocol Synchronous Digital Hierarchy Shortest Path First Time-Division Multiplexing 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 (LMPWDM)

[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 -


GMPLS