Ingeniería, 2007-00-00 vol:12 nro:2 pág:62-67

Optimizando la transmisión de datos IP mediante la conmutación de etiquetas multiprotocolo

Danilo Alfonso López Sarmiento
Docente Universidad Manuela Beltrán, pertenece al Grupo de Investigación Sistemas de Telecomunicaciones.
Julio Barón Velandia
Pertenece al grupo de Investigación Internet Inteligente y TRHISCUD.
Francisco Javier Puente Pérez
Pertenece al grupo de Investigación Internet Inteligente.

Resumen

El presente artículo muestra los resultados del estudio de transmisión de datos con diferente caracterización (mejor esfuerzo, mejor esfuerzo con alta prioridad así como dos tipos de trafico de tiempo real) mediante el protocolo de conmutación de etiquetas multi-protocolo en redes IP, comparado con la transmisión de datos IP utilizando el Modo de Transferencia Asincrónico, el estudio ilustra el mejor rendimiento que presenta MPLS en condiciones de congestión de la red. Como herramienta de experimentación se utilizo el simulador de eventos discretos NS_2 sobre sistema operativo Linux.

Palabras clave:
ATM, CR-LDP, IP, LER, LSR, LSP, MPLS, NS, Nodo.

Abstract

This document shows the data transmission study results with different characterization (better effort, better effort with high priority, as well as two types of real time traffic), made through the use of label commutation multiprotocol in IP nets, compared to the IP data transmission using Asynchronous Transfer Mode, the study illustrates the best performance that the MPLS presents in network congestion states. The discret events simulator NS_2, was used as the experimentation tool running on Linux operative system.

Key words:
ATM, CR-LDP, IP, LER, LSR, LSP, MPLS, NS, Node.

1. Introducción

Actualmente los enrutadores direccionan los paquetes que llegan a sus puertos apoyados en la tablas de enrutamiento las cuales son construidas estática o dinámicamente, cada paquete cuenta con un campo dirección fuente y dirección destino, este ultimo es analizado por el enrutador para determinar el puerto de salida, esta tarea se repite en todos los nodos de la red por donde pasa el paquete hasta que este llegue a su destino [1],[2]. Este sobreprocesamiento en cada uno de los nodos de la red ocasiona: demoras en el direccionamiento de paquetes, congestión, reducción de la calidad servicio [3]. Entre las soluciones propuestas se encuentran: la asignación dinámica de recursos de red y la integración del enrutamiento (Nivel 3 de OSI) con la velocidad de la conmutación (Nivel 2 de OSI). La primera propuesta se implementa mediante el protocolo de reservación de recursos RSVP (Resource ReSerVation Protocol), sin embargo esta no es una solución para redes escalables, la segunda propuesta presenta básicamente dos opciones: integración de IP (Internet Protocol)sobre redes conmutadas entre las que se destaca ATM (Asynchronous Transfer Mode) y el protocolo de conmutación de etiquetas multi-protocolo MPLS (Multiprotocol Label Switching) [4], este último busca integrar la conmutación llevada a cabo en la capa dos con el enrutamiento de la capa tres, mediante el intercambio de etiquetas, mejorando así la relación precio/rendimiento[3], gracias a la escalabilidad y flexibilidad de la capa de red, permitiendo extender la prestación de nuevos servicios[4].

En el presente artículo se estudian dos escenarios: el primero compara la asignación de ancho de banda para tráfico con prioridad en condiciones de congestión, en una configuración IP/ATM contra una configuración IP/ MPLS, en el segundo escenario se evalúa la capacidad de MPLS para reconfigurar rutas cuando se presentan caídas en los enlaces.

El desarrollo de esta práctica implica costosos equipos de enrutamiento que soporten funcionalidades ATM y MPLS, sin embargo la universidad no cuenta con ésta infraestructura,el problema se resolvió utilizando la herramienta de software libre NS-2(Network Simulator) ­Versión 2, este simulador de eventos discretos orientado a objetos, desarrollado en C++ y OTcl por la Universidad Berkeley permite: simular estructuras y protocolos de redes de todo tipo ( WAN, LAN, Unicast, Multicast, Alámbricas e Inalámbricas), desarrollar nuevos protocolos y algoritmos y comprobar su funcionamiento, así como comparar distintos protocolos en cuanto a prestaciones[5],[6].

2. Integración de enrutamiento y conmutación

El objetivo es poder aprovechar la flexibilidad proporcionada por el enrutamiento, y la alta velocidad lograda con tecnologías de conmutación, proporcionando respuesta a las necesidades de las nuevas aplicaciones, en los siguientes apartados se presentan las dos propuestas más relevantes en la industria.

2.1. Integración IP sobre ATM

Entre las soluciones propuestas más importantes están: IP Switching, IP y ARP sobre ATM, Cell Switching Routing(CSR), LAN Emulation , Multiprotocol Over ATM (MPOA), Next Host Resolution Protocol (NHRP), Agrégate Route ­ Based IP Switching(ARIS).

IP y ARP sobre ATM, descrito en las RFC 1577 y 2225, busca hacer posible la transmisión tanto de paquetes como de tramas ATMARP sobre la capa de adaptación AAL5 de ATM [7].

IP Switching, al igual que Tag Switching y CSR basa su funcionamiento en el intercambio de etiquetas, al ser visible la topología en la capa de red reduce la complejidad y elimina la duplicación de funcionalidad, sin embargo el gran numero de conexiones virtuales requeridas no lo hacen viable para redes de gran tamaño[8]-[10].

MPOA, utiliza el concepto de enrutador virtual identificando los distintos tipos de flujos de datos y asociándolos a los canales virtuales de ATM, se complementa con LANE y NHRP [11].

2.2. Conmutación de etiquetas Multiprotocolo (MPLS)

Este protocolo realiza enrutamiento explicito, basa su funcionamiento en etiquetar los paquetes, agilizando el tratamiento de cada paquete en cada nodo dentro del dominio MPLS. Este mecanismo que permite hacer enrutamiento explícito, está compuesto por enrutadores de frontera LER (Label Edge Routers) y enrutadores para la conmutación de etiquetas LSR(Label Switch Router) [12] los cuales están formados por un plano de control y un plano de datos [13], este ultimo tipo de enrutador además de encargarse de la construcción de las tablas de enrutamiento, el intercambio de etiquetas y la señalización de datos, tiene la capacidad de aplicar enrutamiento flexible basado en la asignación de flujos en rutas extremo a extremo dentro de un dominio autónomo[14], [15].

Para establecer una sesión entre un par de LSR y así establecer una nueva ruta de envío LSP(Label Switch Path), el CR-LDP envía mensajes del tipo LABEL REQUEST y LABEL MAPPING mediante el protocolo TCP [16], [17].

La combinación del enrutamiento basado en restricciones CR-LDP (Constraint-based Routing using Label Distribution Protocol)[18], y MPLS permite la implementación de calidad de servicio, a través de la elección de caminos restringidos basado en las características del enlace, la cantidad de saltos, el retardo máximo, entre otros [17], [18].

3. Simulación y análisis de los eventos

Aplicaciones de audio y video en tiempo real demandan de la red retardos máximos de transmisión permitidos, los cuales no pueden ser cumplidos en gran parte por los retardos de procesamiento de paquetes el cual debe ser realizado en todos los nodos del camino, produciendo congestión y generado cuellos de botella en nodos críticos de la red. Una posible solución es la reserva de recursos (como el ancho de banda, el retardo, perdida de paquetes, etc) disponibles dentro de la red, sin embargo esta no es una buena solución para redes escalables [4]; otra solución consiste en buscar rutas alternas descongestionadas para el tráfico con prioridad que garanticen ciertos requerimientos.

El resto del artículo describe dos escenarios y sus respectivas configuraciones de simulación realizados: en el primero se compara la capacidad de garantizar el ancho de banda de una configuración IP/MPLS frente a una IP/ATM, en el segundo se estudia la capacidad de IP/ MPLS para reencaminar tráfico en condiciones de falla de los enlaces ya establecidos. En ambos escenarios se presentan los resultados obtenidos, y apartes del código requerido para la configuración de la herramienta de simulación NS_2 [5].

3.1. Transmisión de tráfico con diferentes prioridades en condiciones de congestión

La Figura 1 muestra un posible escenario (compuesto por cuatro Emisores de tráfico, 5 LSR y un Receptor), en el que puede existir congestión en el enrutador LSR4 debido a que hay cuatro fuentes distintas de tráfico entrante: tráfico simple de mejor esfuerzo (SBT), tráfico de mejor esfuerzo con alta prioridad (HBT), y dos fuentes de tráfico de tiempo real (RT), una de las cuales es susceptible al retardo.

El ancho de banda de cada uno de los enlaces es de 1 Mbps; El «emisor0» transmite a una rata de bits constante de 100 Kbps, el «emisor1» a 150 Kbps, el «emisor2» a 200 Kbps y el «emisor3» a 250 Kbps, lo que indica que el ancho de banda se garantiza para los distintos flujos debido a que la suma total del tráfico no supera el ancho de banda establecido en los enlaces. Gráficamente la demostración se muestra en la Figura 2.

Es importante notar cómo en la Figura 1 se puede apreciar el establecimiento de caminos LSP a través de los mensajes Label Request (nodos 4-6) y Label Mapping (nodos 4-5) en el backbone MPLS.

El siguiente código ilustra aspectos importantes de configuración del nodo para la simulación, entre ellos: el establecimiento de la ruta para el envío y el tráfico emitido por cada fuente.

La Figura 3 presenta el comportamiento del tráfico, sobre una red IP/ATM, de iguales características, mientras que en la figura 4 se realiza una comparación de los volúmenes de tráfico recibido, en ambas configuraciones.

Al igual que IP/MPLS, la red IP/ATM garantiza el flujo de tráfico, ya que éste es menor que la capacidad total de los enlaces.

La Figura 5 muestra la eficiencia DE MPLS-CRL_DP en cuanto a la reserva de ancho de banda garantizado para uno de los tipos de tráfico en tiempo real (RT2) entrante a la red presentada en la figura 1, para éste caso se ha supuesto que existe congestión en el nodo LSR4 creando la necesidad de dar prioridad al tráfico sensible al retardo.

Para éste caso los parámetros y prioridades de los diferentes flujos son:

De la gráfica se puede concluir que hasta los 11 segundos el tráfico de mejor esfuerzo (SBT), de mejor esfuerzo con alta prioridad (HBT) y de tiempo real 1 (RT1) tienen garantizado su ancho de banda debido a que la capacidad del enlace es más grande que la suma de los flujos; entre los 11 y 30 segundos quien tiene garantizado el ancho de banda es el tráfico de tiempo real 2 (RT2) debido a la prioridad establecida en el CR-LDP, mientras que los demás tráficos se reparten el ancho de banda restante de acuerdo a sus prioridades. A partir de los 32 segundos y hasta los 40 segundos se restablece el ancho de banda para los que tenían menos prioridad debido a que RT2 deja de transmitir. En la figura se muestra el comportamiento de los flujos para una red IP/ATM.

Al igual que en la nube MPLS se garantiza el ancho de banda para los tráficos circundantes en la red durante los primeros 11 segundos. Entre los 11 y 19 segundos se le garantiza el ancho de banda al tráfico en tiempo real (RT2), mientras que al RT1 solo se le garantiza 200 Kbps. Los paquetes del tráfico de mejor esfuerzo HBT transmitidos entre los 13 y 30 segundos son descartados.

Entre los 19 y 30 segundos sólo se le garantiza 600 de los 700 K a RT2, reduciendo la reserva de ancho de banda en un 14.28%. La Figura 7 presenta la cantidad de tráfico que llega al destino en cada configuración de red.

A continuación se muestra la Tabla III de enrutamiento generada en el LR4 para el establecimiento de los caminos y etiquetas que permiten priorizar el tráfico:

De acuerdo con los resultados obtenidos se evidencia la ventaja de IP/MPLS sobre IP/ ATM cuando se debe garantizar características de ancho de banda a un flujo de información en condiciones de congestión de la red.

3.2. Capacidad de reconfiguración de red en condiciones de falla de enlaces ya establecidos

La Figura 8 muestra la estructura de la próxima red a estudiar, formada por un emisor que transmite dos tipos de tráfico distintos (audio y video), 6 enrutadores LSR y dos destinos, cada uno de los cuales recibe un tráfico distinto, el ancho de banda de cada enlace es de 2 Mbps.

El flujo de audio genera tráfico a una rata de 640 Kbps, mientras que el de video es de 800 Kbps, aunque es importante aclarar que en un entorno MPLS da igual hacer una distinción entre los flujos de audio y video ya que los paquetes son etiquetados y la conmutación se lleva a cabo de acuerdo con éste parámetro.

El ancho de banda que ocupan los enlaces es suficiente para soportar los tipos de flujo a transmitir. La Figura 9 muestra el comportamiento en cuanto a la utilización del ancho de banda entre los nodos 1, 2 y 6.

De acuerdo con la gráfico, se observa que cada uno de los flujos cuenta con el ancho de banda suficiente, terminando el segundo 3 de la simulación los enlaces LSR2-LSR4, LSR1-LSR3 Y LSR1-LSR4 dejan de funcionar, y tanto el tráfico de video como el de audio se ven negativamente afectados como se muestra en la figura 9, ya que no existe otra ruta por donde transmitir.

En t = 3.5 segundos el enlace LSR1-LSR4 se restablece ya que MPLS siempre está buscando caminos alternativos para la transmisión en caso de fallas, hecho que permite reiniciar la transmisión entre emisor y receptor quedando evidenciada la capacidad de MPLS para buscar caminos alternativos.

La Figura 10 muestra la reconfiguración de rutas que realiza MPLS cuando algunos enlaces dejan de funcionar (caminos LSR1-LSR3 y LSR2-LSR6), superando la eficacia del direccionamiento IP convencional.

En la Figura 11 se aprecia el comportamiento que tiene la transmisión para el caso de la Figura 10.

Se observa que a pesar de que dos de los enlaces han dejado de funcionar el tráfico continúa circulando por la ruta LSR1_LSR4_LSR5_LSR6 la cual se ha creado con anterioridad, aunque hay que evidenciar que hay cierto porcentaje de perdida de paquetes.

Parte del código implementado para la simulación de algunos de los eventos se visualiza a continuación:

4. Conclusiones

Mientras que en ATM es necesario establecer una correspondencia entre la información de enrutamiento y las tablas de conmutación, asignando etiquetas a los VPI/VCI (Virtual Path Identifier/ Virtual Chanel Identifier), en MPLS no es necesario ya que el LDP utiliza direcciones IP y los mismos protocolos de enrutamiento que los de redes IP.

MPLS junto con CR-LDP se constituye en una solución escalable en la transmisión de tráfico con prioridad a bajo costo, ya que permiten tanto la asignación específica de recursos como la búsqueda de rutas alternativas.

La facilidad de integración de MPLS con protocolos de señalización como CR-LDP, hacen factible la implementación de enrutamiento explicito, permitiendo a la red garantizar la transmisión de tráfico sensible al retardo (como el requerido por las aplicaciones de audio y el video en tiempo real).

La eficacia en la configuración de rutas alternas que ofrece MPLS, garantizan la continuidad en la transmisión, cuando se presenta fallas en enlaces específicos de la red.

Aunque el modelo IP/ATM, es una solución que ofrece grandes ventajas sobre otros protocolos, es claro que ya ha sido superado por el crecimiento exponencial de la demanda por mejores servicios de red. MPLS aparece como una excelente opción capaz de suplir las necesidades existentes ya que es capaz de ofrecer mayor estabilidad en lo que respecta al ancho de banda, mayor confiabilidad para la entrega de información de alta prioridad, excelentes mecanismos de señalización, capacidad de adecuación a las necesidades del usuario como consecuencia de la aplicación de Ingeniería de tráfico, cuando MPLS es acompañado por el protocolo de señalización CR_LDP.

Otra ventaja de MPLS sobre ATM es su bajo costo de implementación ya que con MPLS puede seguir siendo válida la estructura de la red que se vaya a actualizar, en muchos casos sería suficiente con la actualización del software de los enrutadores.

Referencias bibliográficas

[1] Green James Harry, «The Irwin Handbook of the Telecomunications», Quinta edición, McGraw Hill Profesional, 2006.

[2] Comer Douglas, «Internet Working with TCP/IP», Pearson Prentice Hall, 2006.

[3] Alvarez Santiago, «QoS for IP/MPLS NetWorks», Cisco Press, 2006

[4] Hersent Oliver, Petit Jean-Pierre, Gurle Dvid, «Beyond VoIP Protocols: Understanding Voice Tecnology and Networking», Wiley 2005

[5] «NS-2, «The Network Simulator», http://www.isi.edu/nsnam/ns/

[6] «MNS version 2, Manual», http://flower.ce.cnu.ac.kr/~fog1/mns/mns2.0/manual.htm

[7] Laubach M, «Classical IP and ARP over ATM «, Enero 1994

[8] Newman Peter, Minshall Greg, Lyon Thomas, «IP Switching ­ ATM Under IP», IEEE/ACM Transactions on networking, Vol 6 nº 2. Abril 1998.

[9] Bray Andy, «IP over ATM: a switch for the better? «,Octubre 1.998, http://www.telecomsmag.com/issues/199810/tci/bray.html

[10] Patrick Paul, «ATM switching and IP routing integration: the next stage in Internet Evolution? «, IEEE Communications Magazine Vol 36 n°4. Abril 1998

[11] «MPOA Baseline», The ATM Forum. RFC 1932, Julio 1997

[12] Rosen E, Viswanathan A, Callon R, «Multiprotocol Label Switching Architecture», RFC 3031, Enero 2001.

[13] Pepelnjak I, Guichard J, «MPLS and VPN Architectures, Cisco Systems», Vol 1, 2001.

[14] Farrel Adrian, Bryskin Igor, «GMPLS : Architecture and applications», Academic Press, 2006

[15] Behrouz A, «Transmisión de datos y redes de comunicaciones», MC Graw Hill, segunda edición.

[16] Stephen A. Thomas, «IP Switching and Routing Essentials: Understanding RIP, OSPF, BGP, MPLS, CR-LDP and RSVP-TC», Wiley, 2001.

[17] Black Uyless, «MPLS and Label Switching Networks», Segunda edición,Prentice Hall, 2002.

[18] Ash J, Lee Y, Ashwood-Smith P, Jamoussi B, Fedyk D, Skalecki D, «LSP Modification Using CR-LDP», RFC 3214, Enero 2002.

Danilo Alfonso López Sarmiento
Ingeniero electrónico, Universidad de Pamplona. Magíster en teleinformática, Universidad Distrital. Ha desarrollado proyectos enfocados al desarrollo de las telecomunicaciones en el departamento de investigación de la Universidad Manuela Beltran. Actualmente es profesor de la Universidad Manuela Beltrán ingeniero24@hotmail.com

Julio Barón Velandia
Ingeniero de Sistemas y especialista en Ingeniería de Software y magíster en teleinformática de la Universidad Distrital Francisco José de Caldas. Investigador de los grupos de investigación Internet Inteligente y TRHISCUD. juliobaron@gmail.com

Francisco Javier Puente Pérez
Estudiante de ingeniería de sistemas, Universidad Distrital. Actualmente pertenece al grupo de investigación Internet Inteligente y desarrolla como proyecto de grado una investigación conjunta entre el Centro Control de Contaminación del Pacifico, bajo la dirección del grupo de investigación Oceanografia Operacional y la Universidad Distrital. fjpuente2000@gmail.com