SciELO - Scientific Electronic Library Online

 
 número58Software agents based simulation for the assessment of technical indicatorsRobot programming using the paradigm of learning by demonstration índice de autoresíndice de assuntospesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

Links relacionados

  • Em processo de indexaçãoCitado por Google
  • Não possue artigos similaresSimilares em SciELO
  • Em processo de indexaçãoSimilares em Google

Compartilhar


Revista Facultad de Ingeniería Universidad de Antioquia

versão impressa ISSN 0120-6230versão On-line ISSN 2422-2844

Rev.fac.ing.univ. Antioquia  n.58 Medellín abr./jun. 2011

 

CR-LDP como protocolo de señalización en redes de conmutación de etiquetas multiprotocol

CR-LDP as the signaling protocol at networking multiprotocol label switching

Danilo López1, César Hernández*2, Luis Pedraza2

1Universidad Distrital Francisco José de Caldas, Facultad de Ingeniería, Carrera 7 N.° 40 - 53. Bogotá, Colombia

2Universidad Distrital Francisco José de Caldas, Facultad de Tecnología, Transversal 70 B N.° 73 a 35 sur. Bogotá, Colombia



Resumen

En este artículo se reportan los eventos suscitados y resultados obtenidos al utilizar CR-LDP como posible protocolo de señalización en redes MPLS, con miras a la búsqueda de la tan anhelada garantía de QoS para aplicaciones deboradoras de ancho de banda.

Palabras clave: CR-LDP, IP, NS, MPLS, LER, LSR, ER-LSP, QoS, RSVP.


Abstract

This paper reports raised events and results from the use of CR-LDP as a possible protocol of signal point MPLS, in order determine whether QoS warranties the desired quality for intensive bandwidth applications.

Keywords: CR-LDP, IP, NS, MPLS, LER, LSR, ER-LSP, QoS, RSVP.


Introducción

En los últimos años, la exigencia de nuevas y mejores aplicaciones por parte de los usuarios ha producido un incremento descomunal en la cantidad de tráfico que circula en la Red lo que se traduce en incremento de procesamiento en los nodos intermedios a tal punto que desde hace tiempo se viene especulando acerca del posible colapso de la Internet. La Conmutación de Etiquetas Multiprotocolo (MPLS) ha emergido como una tecnología prometedora ya que reduce el nivel de trabajo de los nodos a nivel Backbone, sin embargo para que este protocolo funcione con las característica exigidas debe estar acompañado de otros elementos que le permitan incluir agregados tales como el establecimiento de LSPs de forma más eficiente, el re-routing en caso de congestión en los enlaces, el enrutamiento restringido minimizando al máximo la utilización del Ancho de banda generado por los posibles mensajes que puedan aparecer al incluir todas estas características. El presente artículo tiene como objetivo mostrar las bondades que poseería para una red la combinación entre la Conmutación de Etiquetas Multiprotocolo y el protocolo de señalización CR-LDP en cuanto a la robustez de las redes que pretendan garantizar criterios de calidad de Servicio a nivel de Core.

MPLS

MPLS es un tecnología de envío de paquetes robusta basada en la diferenciación de flujos a través de la utilización de FECs a fin de garantizarles diferentes prioridades extremo- extremo dentro de un único o varios Sistemas Autónomos [1]. Principalmente, esta robustez y a la vez flexibilidad permite que el tráfico entre un origen y destino ser dividido en rutas paralelas para evitar congestionar los enlaces en la red, lo que implica la opción de aplicar balanceo de carga [2]

Dentro de las grandes ventajas de la Conmutación de Etiquetas Multiprotocolo está el hecho de que el procesamiento no se realiza en los nodos intermedios (LSR) si no en los extremos de la nube MPLS (LER) mediante la negociación de los parámetros requeridos por el tráfico a transmitir [3], esto permite una asignación previa de la ruta que seguirán los paquetes por lo que se dice que es una tecnología orientada a la conexión (ver figura 1).

Cada uno de estos LER y LSR`s, están formados por un plano de Control y plano de Datos diferenciables claramente en cuanto a las tareas que deben realizar. El mayor procesamiento es el realizado en los LER, ya que es el encargado del establecimiento de rutas óptimas, la construcción de las tablas de enrutamiento y la señalización, generando retardos adicionales, mientras que en los LSR el trabajo es más simple, puntualmente el módulo de envío es el encargado de la conmutación de paquetes a través del intercambio de etiquetas a muy altas velocidades [4]. Las etiquetas son insertadas por los LER y en cada salto el paquete es enviado dependiendo del valor de la misma con otro label. La rapidez en la conmutación se logra gracias a que las etiquetas son insertadas al principio del paquete y son de longitud fija, dando la opción de que ésta tarea se pueda realizar mediante hardware [5].

CR-LDP

Los labels se distribuyen utilizando diferentes tipos de protocolos de señalización, entre los que se encuentran el TDP (Protocolo de distribución de etiquetas - de Cisco) LDP (Label Distribution Protocol), RSVP-TE (Resource reservation Protocol- Traffic Enginner). Las especificaciones actuales no imponen específicamente ningún protocolo para distribuir las etiquetas entre los LSR, sin embargo es importante añadir que las etiquetas son siempre asignadas en Downstream [3].

Cada uno de estos métodos de señalización posee sus desventajas como la no reservación de recursos para los protocolos TDP y LDP. En el caso de RSVP-TE, si bien permite la negociación y establecimiento de circuitos virtuales punto a punto y punto multipunto (para el caso de aplicaciones multicast) garantizando calidad de servicio, estos enlaces deben refrescarse constantemente para que se mantengan activos generando desperdicios de ancho de banda y mayor procesamiento en los nodos intermedios [6]

Por tal razón tal y como aparece en la figura 2, se propone evaluar el protocolo de enrutamiento explícito CR-LDP (Protocolo de Distribución de etiquetas Basado en Restricciones) como elemento de señalización para la distribución de etiquetas en entornos MPLS.

CR-LDP tiene la propiedad de ser un protocolo de estado duro [7], que no implica constantes análisis del estado de los enlaces, estos sólo se realizan durante el establecimiento de los PVCs

Simulaciones y evaluación del comportamiento MPLS+CR-LDP

El desarrollo de la investigación se realizó con el simulador de redes Network Simulator ejecutándose sobre la plataforma GPL Linux Suse.

Ésta herramienta gratuita de eventos discretos permite evaluar y probar el desempeño de nuevos protocolos, lo cual tomaría mucho tiempo y dinero si se fuera directamente a una implementación, Con la simulación, se pueden hacer pruebas a gran escala y lo suficientemente exactas en sus resultados para validar o desechar algunas opciones de diseño en los protocolos [8], [9].

La red que permitirá evaluar el rendimiento MPLS+CR-LDP es la mostrada en la figura 3. Formada por un nodo Transmisor, uno receptor y una nube que contiene dos LER (1,7) y cinco LSR`s (2,3,4,5,6).

Las características de los enlaces se muestran en la figura 4, en la que se destacan el Ancho de Banda y el tipo de cola en cada nodo.

CR-LDP hace uso del protocolo de la capa de transporte TCP [10] a fi n de establecer una negociación de los recursos necesarios para el envío del tráfi co entre cada par de LSR contiguos, incrementando la fiabilidad del proceso de señalización en la red MPLS, el cual es una de propiedades de las tecnologías Hard State.

El Constraint-Routing Label Distribution Protocol está constituido por varios tipos de mensajes:

Label Request: Realiza una petición para el establecimiento de un nuevo ER- LSP.

Label Mapping: A medida que llega un mensaje de este tipo a cada nodo, éstos realizan el establecimiento del ER-LSP ajustando las tablas de conmutación [11], [12].

Label Notification: Informa de algún evento que haya sucedido en el intercambio de mensajes.

Label Error: Indica la existencia de algún tipo de error en el intercambio de mensajes CR-LDP.

Label Release: Indica la liberación de un LSP establecido [7].

La creación de un ER-LSP entre los nodos 1, 4, 7 de acuerdo a las pruebas implementadas en el NS-2 es el visualizado en las figura 5 y 6 de las cuales se puede establecer que:

1. El LER de Ingreso genera la necesidad de establecer un nuevo LSP hacia el LER de Egreso. Las características del tráfico determinan cual es la ruta más óptima por dónde debe implantarse la ruta, así que el LER1 reserva los recursos que necesita y envía un LABEL_REQUEST con los requerimientos de métricas tales como retardo máximo en los enlaces, procesamiento en las colas, coste de los enlaces, ancho de banda explicito requerido por la sesión hacia el LER7.

2. El LSR4 recibe el mensaje reserva los recursos y determina si es el nodo final para ese ER-LSP, como no lo es reenvía el mensaje LABEL_REQUEST. Es posible que en cada LSR se puedan renegociar los parámetros requeridos si estos están marcados como negociables.

3. Una vez se llega al LER de Egreso, éste realiza la reserva final de los recursos solicitados, asigna una etiqueta al nuevo ER- LSP y la devuelve en forma Downstream en un mensaje LABEL_MAPPING que contiene los parámetros de tráfico específicos solicitados para el LSP.

4. El LSR4, recibe el mensaje, realiza los ajustes finales de acuerdo a los parámetros recibidos desde el LER salida a través del LABEL_MAPPING y los solicitados desde el LER ingreso con el LABEL_REQUEST de acuerdo al identificador ER-LSP, asigna una nueva etiqueta al LSP, actualiza su tabla de envío y la da a conocer al LER1 con un LABEL_MAPPING, quedando establecido el Camino 1-4-7 a través de la red MPLS para el transporte del respectivo flujo de datos, que es el visualizado a continuación (Figura 7), en donde además se aprecia el establecimiento de un nuevo ER-LSP.


Las características de configuración de los mensajes en el NS-2 son, figura 8:

Una ventaja adicional de CR-LDP sobre otros tipos de señalización sobre redes con Calidad de Servicio es la posibilidad de seleccionar rutas explicitas dando lugar a la reservación de recursos con diferentes características (ver formato trama CR-LDP figura 9).

Donde:

Frecuencia: define que tan frecuentemente se puede garantizar el routing explicito

Peso: establece el nivel de prioridad de cada ER-LSP para múltiples tráficos en caso de baja disponibilidad de ancho de banda, congestión, etc.

PDR (velocidad de pico de datos): hace referencia a la máxima rata de transferencia de datos.

PBS (tamaño pico de la ráfaga): Tamaño máximo del mensaje.

CDR (velocidad de datos garantizada): se refiere a la velocidad de transferencia reservada.

CBS (tamaño de ráfaga garantizado): máximo tamaño de la traza [11], [7].

Este enrutamiento explícito presupone que si no se garantizan los requerimientos exigidos en cuanto a ancho de banda (a excepción de aquellos que se marquen como negociables) no se avala el establecimiento del ER-LSP. Esto se deduce del gráfico generado en NS-2 con XGRAPH (Figura 10) en el cual se establecen LSP's para video y audio, sin embargo no se logra ubicar uno que reúna las condiciones para la aplicación web, dando prioridad al flujo susceptible a retardos y garantizando de esta manera parámetros de calidad de servicio.

Las rutas seguidas para el transporte de video (LSPID 1100) y audio (LSPID 1200) además del tiempo de duración en el establecimiento de los LSP se detallan seguidamente, figura 11:

Cabe destacar el hecho de que (como se dijo anteriormente) CR-LDP no pudo establecer condiciones satisfactorias para el LSPID 1300 que corresponde a Web debido a que no se garantizaron las condiciones mínimas de envío.

Seguidamente se muestra el desempeño del protocolo en evaluación, cuando las condiciones de ancho de banda existen para los tres identificadores (Figura 12), de donde se puede ver con claridad la garantía de los recursos para cada flujo de datos.

Otra variable importante en una networking que debe garantizar un protocolo de señalización es el asociado con el comportamiento ante la caída o congestión de los mismos.

CR-LDP asociado con el protocolo de routing utilizado (en éste caso particular de estado de enlace) permite el reenrutamiento del tráfico siempre y cuando previamente se haya establecido un ER-LSP de respaldo mediante el mismo routing restringido. La figura 14 muestra aspectos importantes de la simulación ante congestión en el LER1, la caída del enlace entre el LSR4 y el LER7 y el re-enrutamiento a través del LSR3. La simulación en este caso se realizó solamente con dos fuentes las cuales partían del Nodo 0al Nodo 8 y se ajustó el ancho de banda para que los ER- LSP fueran establecidos inicialmente a través de la ruta LER1-LSR4-LSR7.

Los ER-LSP creados junto con sus tiempos son los que aparecen a continuación, figura 13, del que se desprende que el tiempo de establecimiento de los PVC con los criterios requeridos en cuanto a ancho de banda y procesamiento en las colas para los lspid 1200 y 1300 tuvieron un mayor retardo con respecto al lspid 1100 debido a la mayor cantidad de negociaciones entre el nodo origen y destino, sin embargo los tiempos de establecimientos son muy pequeños lo que se traduce en una excelente desempeño de CR-LDP en redes MPLS.

El LER1 comienza a descartar paquetes ya que el ancho de banda solicitado en el establecimiento de los PVC se específico como parámetro negociable permitiendo la garantía en caso de congestión de 725 Kbps únicamente para cada tipo de información. Es importante destacar que la capacidad de canal soportada por el enlace es de 1,5 Mbps.

 

Figura 14 Eventos de la simulación en NAM ante congestión, y re-routing

En la traza (Figura 15) se aprecia de manera gráfica el comportamiento BW contra tiempo para la nube MPLS+CR-LDP ante los eventos planteados anteriormente. La fuente comienza a funcionar a los 0,1 segundos donde cada tipo de dato requiere 900 Kbps para transmitir de forma eficiente y sin perdidas, sin embargo debido a que se superan los requerimientos garantizados solo se puede ofrecer 725 Kbps para cada uno ocasionando un cuello de botella hasta los más o menos 0,450 segundos al cabo de los cuales el enlace LSR4-LER7 deja de funcionar ocasionando una pérdida de paquetes, lo que se traduce en que la productividad se ve menguada mientras los FEC utilizan el mismo ER-LSP; pero gracias al establecimiento previo de rutas respaldo rápidamente se re-enruta la fuente de video para transitar a través del LER1-LSR3-LSR6-LSR7. A partir de los 0,5 seg se observa un aumento significativo del desempeño en la internetworking.

La fuente de audio deja de transferir a los 0,450 segundos por eso no hay necesidad de re-enrutarla. Es importante recalcar que de haber seguido transmitiendo ambos flujos perfectamente se abría podido retransmitir el otro a través del LER1-LSR2-LSR5-LSR7 creando rutas separadas lo que se traduciría en la posibilidad de dividir el tráfico gracias a las ventajas de QoS ofrecidas en MPLS. En una red netamente IP estas características hubieran sido imposibles de implementar.

Finalmente, se analiza (Figura 16) el resultado de la cantidad de paquetes procesados en el LER1, partiendo de la premisa de que se asignaron diferentes prioridades a cada flujo. En este caso particular se modificó el algoritmo de establecimiento de un ER-LSP con CR-LDP para establecer el comportamiento que tendría la nube MPLS particularmente en el LER de entrada (donde se forma un nivel de congestión bastante importante debido a que los tres tipos de tráfico convergen a éste) cuando se negocia una por parte del protocolo de señalización una alta prioridad de procesamiento en la Cola CBQ para el tráfico interactivo y un mismo nivel de prioridad baja para audio y tráfico masivo.

La respuesta es evidente a tal punto que la cantidad de paquetes procesados es en mayor número para el de mayor prioridad, mientras que el resto de recursos de procesamiento se lo pelean los de baja prioridad.

Conclusiones

La inclusión de CR-LDP en redes MPLS, permite la implementación de enrutamiento basado en restricciones (CBR) permitiendo al administrador la opción de seleccionar determinadas rutas para el envío de tráfico con características muy específicas como garantía máxima en retardos, perdida máxima de paquetes, prioridad en las colas, reserva de Ancho de banda.

CR-LDP+MPLS es una opción interesante para el re-enrutamiento de la información ante eventos que puedan suceder como la congestión o caída en los enlaces, el no funcionamiento de nodos además de permitir la separación y transporte de flujos por diferentes caminos lográndose poder aplicar criterios de de Ingeniería de Tráfico y Balanceo de Carga, aspectos muy deseados por los ISP.

Si se compara RSVP-TE con CR-LDP, el primero es un protocolo soportado sobre sesiones UDP para establecer las comunicaciones a nivel lógico, por tal razón se debe estar evaluando constantemente el estado de los enlaces, lo que supone mayor vulnerabilidad aunque se podría hacer uso de IPSec o algún otro esquema de encriptamiento. Otra desventaja sería que para RSVP-TE, una conexión fallida será detectada solamente cuando no se reciba un mensaje de refresco de la ruta preestablecida y dependiendo de cómo se haya configurado, detectar un fallo puede tardar hasta varios minutos antes de poner en funcionamiento alguna acción de recuperación mediante el re-routing volviendo lento el proceso de convergencia de la internetworking, mientras que CR-LDP es más óptimo ya que funciona sobre TCP evitando un mayor procesamiento entre los LSR y permite la detección de fallos mediante las notificaciones generadas por TCP.

Por otro lado, CR-LDP asociado con MPLS permite una negociación de ciertas variables a fin de garantizar hasta cierto punto por ejemplo un Ancho de banda determinado sin garantizar el requerido para una transmisión con garantías de QoS.

Referencias

1. N. Lin, H. Qi. "A QoS Model of Next Generation Network based on MPLS". IEEE IFIP International Conference on Network and Parallel Computing Workshops. 2007. pp. 915-919.         [ Links ]

2. J. W. Evans, C. Filsfils. Deploying IP and MPLS QoS for Multiservice Networks: Theory & Practice. Ed. Morgan Kaufmann (CA). 2007. pp. 171-175.         [ Links ]

3. A. Sayeed, M. J. Morrow. MPLS and Next-Generation Networks. Ed. Cisco press. Indianapolis (USA). 2006. pp. 126-127.         [ Links ]

4. M. K. Porwal, A. Yadav, S.V. Charhate. "Traffic Analysis of MPLS and Non MPLS Network including MPLS Signaling Protocols and Traffic Distribution in OSPF and MPLS". IEEE First International Conference on Emerging Trends in Engineering and Technology. Vol. 1. 2008. pp. 187-192.         [ Links ]

5. J. I. Agbinya. IP Communications and Services for NGN2. Crc Press. Boca Ratón (USA). 2009. pp. 150-152.         [ Links ]

6. A. Gupta, J. W. Atwood. "Feedback Mechanism for MPLS Path Assignment using RSVP-TE". IEEE Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services. Vol. 2. 2006. pp. 61-62.         [ Links ]

7. B. Jamoussi, L. Anderson, R. Callon, R. Dantu, L. Wu, P. Doolan. "Constraint-Based LSP Setup using LDP". IETF, RFC 3212. 2002. pp. 13-19         [ Links ]

8. NS-2. The Network Simulator. http://www.isi.edu/nsnam/ns/. Consultada el 10 de julio de 2006.         [ Links ]

9. MNS version 2, Manual. http://flower.ce.cnu.ac.kr/~fog1/mns/mns2.0/manual.htm. Consultada el 15 de julio de 2006.         [ Links ]

10. B. Kim, W. Chun, J. Yoo. "Constraint-based LSP Setup by Message Reversing of CR-LDP". IEEE, 15th International Conference on Information Networking, Beppu (Japan). 2001. pp. 875-877.         [ Links ]

11. S. A. Thomas. IP Switching and Routing Essentials: Understanding RIP, OSPF, BGP, MPLS, CR-LDP and RSVP-TC. Ed. Wiley. New York (USA). 2001. pp. 213-215         [ Links ]

12. T. García, J. Raya Cabrera, V. Rodrigo Raya. Alta velocidad y calidad de servicio en redes IP. Ed. Alfaomega. Barcelona (España). 2007. pp. 514-517.
        [ Links ]



(Recibido el 26 de febrero de 2010. Aceptado el 31 de agosto de 2010)

*Autor de correspondencia:teléfono móvil: 311 218 66 35, fax: + 57 + 1 + 731 15 25, correo electrónico: cahernandezs@udistrital.edu.co. (C. Hernández).

Creative Commons License Todo o conteúdo deste periódico, exceto onde está identificado, está licenciado sob uma Licença Creative Commons