MPLS y ATM como tecnologías backbone para la transferencia de videoconferencia

MPLS and ATM as backbone technologies to carry videoconferencing

Danilo López Sarmiento¹, Luis F. Pedraza² Cesar Hernández³

¹ Ingeniero Electrónico, magíster en Teleinformática. Docente e investigador de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. Contacto: dalopezs@udistrital.edu.co
² Ingeniero Electrónico, magíster en Ciencias de la Información y las Comunicaciones, estudiante de doctorado en Ingeniería de Sistemas y Computación de la Universidad Nacional de Colombia. Docente e investigador de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. Contacto: lfpedrazam@udistrital.edu.co
³ Ingeniero Electrónico, magister en Ciencias de la Información y las Comunicaciones, estudiante de doctorado en Ingeniería de Sistemas y Computación de la Universidad Nacional de Colombia. Docente e investigador de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. Contacto: cahernandezs@udistrital.edu.co

Fecha de recepción: 14 de Noviembre de 2011 Fecha de aceptación: 17 de abril de 2012

Resumen

El artículo presenta los resultados obtenidos al modelar el rendimiento y desempeño de un Core IP/ATM frente a uno CR-LDP/IP/MPLS y frente a uno RSVP-TE/IP/MPLS aplicado a la transferencia de tráfico sensible al retardo (video conferencia) con garantías mínimas de reserva de recursos e interacción óptima entre usuarios y aplicaciones. Para el desarrollo de la investigación se utilizó el software de simulación OPNET MODELER (versión educativa), permitiendo generar nuevas características y apreciaciones que refuerzan el comportamiento acerca de qué tecnología es la más óptima como solución a los problemas actuales que poseen las networking por el gran volumen de información a transmitir y la baja QoS ofrecida al usuario promedio.

Palabras Clave: ATM, CR-LDP, ISP, MPLS, QoS, RSVP-TE.

Abstract

This article presents the results obtained by modeling the performance of a core IP/ATM network compared to a CRLDP/IP/MPLS network when carrying delay sensitive traffic (videoconferencing) with minimum resource reservation guarantees and optimal interaction between user and applications. In order conduct the experiments, OPNET-modeler simulation software (educational version) was used, which encouraged alternative implementation features that help decide which of the two technologies represents a suitable solution for current networking problems, where large volumes of information need to be transmitted and the QoS offered to average users is pretty poor.

Key words: ATM, CR-LDP, ISP, MPLS, QoS, RSVP-TE.

1. Introducción

En la actualidad existen múltiples tecnologías llamadas a ser candidatas para ofrecer transporte de datos eficiente para aplicaciones interactivas; no obstante, los ISPs en muchos casos no tienen claro cuál, o cuáles, son las arquitecturas lógicas más robustas a fin de mejorar las prestaciones al usuario final y qué comportamiento tendrían desde la perspectiva de funcionamiento y rendimiento bajo ciertas circunstancias. Dentro de las estructuras más representativas se encuentran: el Modo de Transferencia Asíncrona (ATM) y la Conmutación de Etiquetas Multiprotocolo (MPLS) que podría permitir la integración con el Protocolo de Distribución de Etiquetas con Enrutamiento Restringido (CR-LDP) o con el Protocolo de Reservación de Recursos incluyendo Ingeniería de Tráfico (RSVP-TE). Este artículo incluye la recopilación y análisis de los resultados obtenidos a partir de la simulación de varios escenarios tipo backbone, cuando las múltiples aplicaciones (flujo interactivo y masivo) deben competir por los recursos disponibles en la red, garantizando reserva de recursos para aplicaciones sensibles al retardo, se generan eventos inesperados en la networking (Cuellos de botella, re-routing y problemas en los enlaces).

Desde éste punto de vista, surge la hipótesis: ¿qué ventajas o desventajas posee cada técnica y cuál es la de mayor rendimiento para el soporte eficiente de video conferencia?.

2. MARCO TEÓRICO

MPLS. MPLS es un protocolo diseñado para dar solución a la gran demanda de recursos y calidad de servicio que tienen las nuevas aplicaciones [1], éste funciona sobre diferentes tecnologías como ATM, Ethernet, Frame Relay, PPP. Ya que MPLS puede existir con estas tecnologías, no busca reemplazarlas sino mejorar el trasporte de datos a través de ellas.

Los nodos en una nube MPLS no toman decisiones de enrutamiento; esto hace que sea más eficiente en relación al procesamiento que debe hacer cada LSR para conmutar un paquete gracias a la división existente entre el plano de control y el plano de conmutación.

Otro punto importante de MPLS es que, mediante la integración de procesos de señalización, es posible el establecimiento más eficiente de LSPs y acorde con las características exigidas por la aplicación. Estos LSPs son el camino virtual por el que viajará el flujo de información perteneciente a una misma FEC, todo a través del intercambio de etiquetas en donde la asignación de estos Labels es realizado generalmente desde el LER de salida hacia el de entrada o, en otras palabras, en sentido Downstream.

Dependiendo del tipo de señalización soportada en la nube IP/MPLS se pueden reservar rutas restringidas y aplicar ingeniería de tráfico en caso de fallas en los enlaces primarios. Esto se logra mediante una negociación iniciada por el LER de entrada, que envía un mensaje Upstream de petición. Esta es respondida por el LER de salida mediante un mensaje Downstream con la etiqueta asignada a la FEC en la que cada LSR actualiza la tabla LIB [2].

Cuando todos los dispositivos intermedios que hacen parte del circuito saben qué etiqueta representa la FEC, el tráfico asociado a ésta puede ser trasportado. Cabe decir que, entre dos pares de LSR, existe una etiqueta que identifica a la FEC y es muy probable que en el siguiente par de LSR esta etiqueta sea diferente [3].

Al llegar un paquete a un LER de ingreso, éste analiza la cabecera del paquete, para determinar a qué FEC pertenece, con el conocimiento de ésta, el LER encapsula los datos ubicando un encabezado MPLS, donde el campo "label" es el utilizado para la conmutación a través de la red.

RSVP-TE es una extensión de RSVP, descrita en la RFC3209 [4], usada para el establecimiento de caminos enrutados explícitamente, con o sin reserva de recursos, el enrutamiento explícito puede llevar a que un LSP se establezca lejos de nodos que tengan fallas, enlaces fallidos o cuellos de botella [2].

El mensaje RSVP Path contiene varios objetos para el cumplimiento de sus funciones, de los cuales se pueden destacar dos: Label_Request y Explicit_Route, donde el primero contiene la petición para la asignación de etiquetas a una FEC en particular, y el segundo contiene un encapsulado con la concatenación de saltos que forman el camino para establecer un LSP, estos se pueden configurar con parámetros de reservación de ancho de banda y políticas de rendimiento de la red [5].

Para establecer una LSP, el primer nodo de la red MPLS, transmite un mensaje a través del camino, que lleva el objeto Label_Request , este contiene una petición de etiquetas para el LSP e información del protocolo de red que va hacer enviado, si el LER de ingreso conoce una ruta con alta probabilidad de garantías de QoS, éste toma la decisión de usarla, para ello adiciona el objeto Explicit_Route en el mensaje [5], que es donde se encuentran todos los nodos especificados de la ruta escogida.

La respuesta a RSVP Path es un mensaje RSVP Resv, que lleva consigo un objeto llamado Label, donde está la información de la etiqueta de salida que fue asignada a una FEC específica, este mensaje es enviado en sentido contrario por cada uno de los nodos por los que pasó el mensaje RSVP Path; si este mensaje llega a un LSR, que no es el nodo de ingreso, se establece una nueva etiqueta y envía el mensaje a su nodo downstream, este proceso se repite hasta llegar al LER de ingreso para que el LSP haya sido establecido. En cada nodo es actualizada la información de la tabla LIB, para incluir cada etiqueta de salida. Este protocolo utiliza UDP, lo que indica el envío de actualizaciones cada cierto tiempo para mantener el circuito activo [6].

CR-LDP es una extensión de LDP con herramientas para el establecimiento de un LSP enrutado explícitamente, donde los nodos límite, usualmente en el LER de salida, son los encargados de esta tarea con ayuda del protocolo de enrutamiento [8].

Tal como LDP usa el protocolo TCP, CR-LDP hereda el uso de éste para la confiabilidad de la publicación de sus etiquetas, por lo tanto no necesita renovación periódica de los vínculos etiqueta-FEC la diferencia radica en que ya no solo se publican etiquetas entre routers, sino también se incluyen campos, llamados TLV (tipo/longitud/valor), mediante los cuales se configuran opciones adicionales para generar rutas con restricciones, con el fin de reservar recursos, como el ancho de banda, retardos máximos en los enlaces, costos, en todo el LSP y dar QoS a la FEC que se está trasportando. Dentro de las opciones que tiene CR-LPD está la de soporte para re-enrutamiento, que se activa cuando ocurre la caída de una de ruta explicita, la Fig. 2 muestra el proceso de etiquetado.

ATM, Asynchronous Transfer Mode o Modo de Transferencia Asíncrona, se desarrolla para ofrecer una solución a la creciente demanda de ancho de banda para la transmisión de información, aplicaciones y servicios. Los sistemas de transporte usados, en búsqueda de una eficiencia mayor, basan su funcionamiento en la conmutación de celdas (paquetes cortos de longitud constante) enrutadas cada una en circuitos virtuales.

ATM basa su funcionamiento en la conmutación de celdas, esto hace necesario la definición de ciertos términos que permiten el establecimiento de una conexión entre dos terminales y la conmutación de estas hacia su destino:

• TP, Transmision Paths.

Nombre dado a la conexión física entre dos sistemas.

• VP, Virtual Paths.

Conexión entre dos conmutadores.

• VC, Virtual Channel.

Conexión encargada de transportar datos entre usuarios.

• VPI, Virtual Path Identifier.

Encargado de definir el camino virtual ofreciendo un grupo de conexiones entre dos conmutadores.

• VCI, Virtual Channel Identifier.

Define un VC dentro de un VP

• Celdas.

Definida como unas pequeñas unidades de datos de tamaño fijo que son transmitidas de forma uniforme y pueden ser completamente predecibles. Consta de 53 bytes, 48 bytes para la carga y el restante para la cabecera. La carga son los datos del usuario y la cabecera contiene los valores de VPI y VCI definiendo la conexión virtual desde dos puntos [9].

La estandarización de ATM fue definida en tres niveles. Con una jerarquización de los sistemas en donde los finales utilizan los tres niveles y los conmutadores los dos niveles inferiores:

• Nivel físico.

Este espacio define las características físicas que deben implementarse en los medios de transmisión, aunque la mayoría de las especificaciones se han dejado a elección de los implementadores.

Su objetivo es de dar control a señales eléctricas u ópticas para proporcionarle una adaptación al medio de transmisión y el método de codificación usado sobre el medio. Los medios físicos usados son: par trenzado, cable coaxial o fibra óptica con una transmisión de bits que va de 155 Mbps a 622 Mbps.

• Nivel ATM.

Se encarga de procesar el tráfico recibido del nivel superior, agregando una cabecera de 5 octetos al segmento de 48 bytes para completar el tamaño de una celda, también tiene la responsabilidad de la multiplexación y ruteo de estas a través de los VP y VC, la detección de errores y control de flujo datos.

• Nivel de adaptación de la aplicación.

Esta capa brinda la oportunidad de que las demás tecnologías existentes puedan conectarse a ATM y así interpretar de forma correcta los datos recibidos de niveles superiores para ser transformados en celdas ATM, este proceso realizado por los sistemas terminales [10].

Calidad de servicio: se refiere a la capacidad que tiene una red de suministrar un servicio mejorado mientras transporta un determinado flujo de tráfico sobre las diferentes tecnologías (Frame Relay, ATM, SONET, Ethernet). El trabajo de QoS es ofrecer prioridad y garantías sobre una red con respecto a valores legibles como el retardo, ancho de banda, pérdida de paquetes y jitter en aplicaciones que son sensibles a estos, como las de tiempo real (transmisión de video, voz) y trafico interactivo [11].

Los principales problemas que suscitaron la aparición de diferenciación de servicios son:

• Perdida de paquetes.

• Errores durante la transmisión.

• Retardos.

• Jitter

• Desorden en los paquetes. [11]

3. METODOLOGIA Y RESULTADOS

En esta sección se describen las networking que se utilizaron para evaluar el comportamiento de la tecnología ATM frente a MPLS (esta última utilizando CR-LDP y RSVP-TE), además de los eventos suscitados y evaluación de resultados obtenidos.

Escenario 1: Cuello de botella.

En esta topología se pretende valorar la administración del ancho banda y el retardo cuando este recurso es competido por varios tipos de tráfico en un solo nodo; para esto se plantea un escenario en cuello de botella entre el Router_Core 1 y Router_core2 (Fig.3). Cuenta con 9 routers. Los enlaces entre dispositivos fueron tomados de tal forma que no influyeran en la capacidad de transporte del flujo de datos, las cinco redes LAN contienen los dispositivos finales (servidores y Pc's) donde se encuentran las aplicaciones, estas redes son comunes para todas las simulaciones.

Todos los enlaces de esta topología son enlaces OC3 con anchos de banda de 148.61Mbps. El tipo de procesamiento de colas usado en los nodos es Priority Queuing / DSCP based.

Los dispositivos de capa 3 de ingreso a la red (LER) son los Router1, Router2 y Router3, estos a su vez tienen conectadas las redes LAN Red1, Red2 y Red3. Router4 y Router5 son nodos de salida de la nube a los cuales se encuentran conectadas las otras dos LAN.

A cada router de ingreso entra un tipo de trafico diferente, logrando que la congestión se encuentre en el primer router del CORE, además, éste solo tiene una interfaz de salida para todo el tráfico que enruta. Las redes LAN conectadas a los router de entrada y salida de la red tienen enlaces Fast Ethernet 100BaseT con un ancho de banda de 100Mbps. La Red1, es donde se genera todo el tráfico Best Effort, por medio de dos PC que están actuando como cliente FTP y cliente Email, los equipos que hacen de servidores a estos PC se encuentran en la Red4 y Red5.

La "Red2" genera el flujo de video conferencia y el nodo destino de está es el "PC_video2" en la "Red4".

En la "Red3" se está generando el tráfico de Voz IP, el nodo donde se encuentra la aplicación destino de este, se ubica en la "Red5".

En la "Red4" se ubican los nodos de destino de las Redes 1 y 2 (hay un PC que es la terminal de destino de video conferencia y un servidor que atiende los servicios de FTP a uno de los PCs que se encuentran en la "Red1").

En la "Red5" está la terminal de destino de la aplicación de Voz IP y el servidor Email que atiende al PC conectado en la Red1. A manera de visualización, para ubicar al lector se incluyen las Fig.4 y Fig.5:

Particularmente, la topología ATM contiene en su CORE elementos que aplican QoS de acuerdo al tipo de tráfico, CBR para tráficos en tiempo real y UBR para aplicaciones best effort, y en los extremos se complementa con tecnología Ethernet.

En el caso de MPLS, el CORE está formado por la inclusión de un protocolo de señalización que en un caso es CR-LDP y en el otro RSVP-TE. La Tabla 1 muestra la configuración que se aplica a cada fuente de tráfico.

La configuración hecha a ATM permite proveer prioridad al tráfico sensible al retardo, por medio de la clasificación otorgada por esta tecnología. En el caso de UBR, la solución que brinda este tipo de clase de servicio se orienta hacia aplicaciones tipo Best Effort [12], mientras que CBR aporta la garantía de ofrecer un mínimo de retardo para el video y la voz. El ancho de banda subscrito para cada aplicación fue de un 100% para cada clase, con un mínimo en momentos de congestión de un 20%. Las exigencias solicitadas por las aplicaciones (ver Tabla 2) son:

El primer parámetro utilizado para comenzar a evaluar las dos tecnologías (ATM vs MPLS) es la Variación del retardo (DV), este muestra la variación en el tiempo de los paquetes entre dos puntos de referencia y su magnitud se da en segundos. En la Fig.6 se muestra la variación del retardo para video-conferencia con cada protocolo y en la Tabla 3 se comparan los resultados obtenidos en cuanto a paquetes recibidos, perdidos y variación del retardo para ATM y MPLS cuando transmiten flujos interactivos.

Analizando los resultados mostrados anteriormente, se puede concluir que ATM tiene una variación del retardo máxima de 9.00x10^-9 seg, con una tendencia al descenso, este valor máximo es casi 100 veces mayor al que presenta MPLS, sin importar qué señalización esté utilizando (esta diferencia hace que no se pueda apreciar apropiadamente), esto se traduce en que la conmutación de etiquetas multiprotocolo asociado con RSVP-TE o CR-LDP ofrecen una mayor calidad de servicio a las aplicación de video conferencia. Este mejor rendimiento se debe a la mayor eficiencia en la reserva de ancho de banda por parte de los procesos de señalización en MPLS y, además, al bajo consumo de procesamiento en cada nodo en comparación a ATM.

La segunda variable evaluada se relaciona con la cantidad de paquetes perdidos; ATM tiene un menor valor promedio de perdida (0.003 paquetes/seg) que corresponde al 0.015%, si se compara con MPLS (donde con CR-LDP es del 0.006 paquetes/seg (0,032%) y con RSVP-TE 0.007 paquetes/seg (0,038%)). Tal apreciación indica que, aunque ATM tiene un menor porcentaje de pérdida de paquetes, las dos tecnologías se encuentran dentro las recomendaciones de la ITU-T en [9], indicando que las perdidas no son significativas en ambos casos.

Con el fin de profundizar en el análisis del rendimiento de los protocolos de señalización manejados con MPLS se genera la Fig.7 (descartando ATM).

RSVP-TE, descrito por la línea roja, muestra que su establecimiento a través del tiempo permanece en un valor de 5.01x10^-12 seg, variable que es superior al de CR-LDP por 2.23x10^-12 seg. De otro lado, RSVP-TE obtiene una estabilización más rápida.

Los valores menores que presenta CR-LDP en el delay variation se debe a que no necesita una actualización constante del estado del enlace, como sí lo hace RSVP-TE, esto conlleva a una menor carga y procesamiento en los nodos de la red, y se ve reflejado en el mejor manejo de la aplicación de video y, como consecuencia, en una mejor calidad de servicio. Finalmente, RSVP-TE reacciona mejor ante cambios en la cantidad de tráfico que atraviesa la red, como se ve en la Fig.7 , no obstante, CR-LDP tiene la ventaja de generar menor carga, lo que se traduce en mayor disponibilidad de ancho de banda y menor procesamiento en los nodos.

Como conclusión de esta topología, se muestra una superioridad de MPLS en cuanto a la variación del delay reflejado en una mejor QoS hacia el usuario final en aplicaciones sensibles al retardo. Por otro lado, ATM tiene un mejor comportamiento en relación a los paquetes descartados de aplicaciones que toleran errores, pero con un sacrificio en el retardo.

Desde el punto de vista de los protocolos de señalización en MPLS, se puede concluir que existe un mejor comportamiento de CR-LDP en redes con alta demanda de ancho de banda y que no varíen de forma significativa a través del tiempo; en cambio, RSVP-TE es mucho más eficiente en entornos que tengan tráfico variante ya que su estabilización es bastante óptima.

Escenario 2: Re-enrutamiento.

En este caso (Fig.8 ) se analizará qué ocurre cuando uno de los enlaces del CORE no posee la capacidad suficiente para el tráfico que debe a través de él, con esto se busca investigar cómo las dos tecnologías establecen rutas diferentes que tengan enlaces con la capacidad apropiada para garantizar la calidad de servicio ofrecida

El enlace que no ofrece la capacidad suficiente se encuentra entre Router_Core1 y Router_core2 (que hace las veces de LSRs), este enlace es un E1, con capacidad de 2.048 Mbps, los demás enlaces entre routers son OC3 de 148.61Mbps. Las conexiones Fast Ethernet son iguales a las del escenario de cuello de botella. Para este escenario todas las aplicaciones están funcionando al tiempo, logrando que el enlace E1 se sature y se deban buscar nuevas rutas para transportar el tráfico sin generar perdidas en la información. El enlace que lleva al "Router_Core3" tiene capacidad suficiente para garantizar el reenvio de dicho flujo, con ello se podrá observar y valorar cómo las tecnologías reservan recursos y si poseen la capacidad de re-enrutar el tráfico para no saturar el enlace y así garantizar la calidad de servicio.

El segundo evento mide la capacidad de re-enrutamiento de cada tecnología, cuando ocurre una situación inesperada, como es la caída de un enlace. Los tipos de procesamiento de colas y políticas de congestión son las mismas del escenario "cuello de botella".

El re-enrutamiento de ATM, en este escenario, es generado gracias al protocolo de encaminamiento utilizado (OSPF), ya que el modelo planteado no ofrece otra manera de asegurar, en caso de un enlace congestionado o con falta de recursos, la manera de enrutar de manera más eficiente y adecuada el tráfico con prioridad; esto se debe a que ATM, en su estructura, no soporta una solución propia que permita establecer rutas más óptimas para el re-enrutamiento de la información.

El re-routing en MPLS se genera a través de Router_Core2 o Router_Core3, la decisión es tomada por el protocolo de señalización y de routing OSPF, donde, si el enlace no cumple las condiciones para la reserva de ancho de banda, el tráfico de la aplicación no es enviada, por ello en la Fig.9 se ve que el LSP de video conferencia se estableció a través del enlace de mayor capacidad.

La primera impresión es que las tecnologías, al utilizar el mismo protocolo de enrutamiento basado en el estado del enlace (OSPF), encaminan explícitamente el LSP por las interfaces con mayor capacidad de ancho de banda, por esta razón, inicialmente, se tenía la expectativa de un comportamiento muy similar entre RSVP-TE y CR-LDP, sin embargo no fue así (Fig.10):

Aunque la variación del retardo en ambas tecnologías está dentro de los parámetros recomendados por la ITU-T; se observa que CR-LDP y RSVP-TE toma valores máximos de 1.22x10^-09 y 3.82x10^-11 respectivamente, mostrando menos del 1% del máximo establecido por la recomendación. Al comienzo, CR-LDP tiene un aumento significativo con relación a RSVP-TE, causando una mayor variación del retardo y, como consecuencia, una menor QoS.

Seguidamente, se observa (Fig.11 y Fig.12) el tráfico enviado y recibido donde se concluye que la comunicación no se interrumpe nunca debido a que, con los dos protocolos de señalización, está reservado el ancho de banda adecuado:

En cuanto al tráfico Best Effort fue re-enrutado explícitamente (Fig.13 y Fig.14) para ese caso. No obstante, con CR-LDP existe una situación fuera de lo esperado, ya que el tráfico enviado por éste toma una ruta diferente (Router_Core1-Router_Core6-Router_Core1- Router _Core2) con relación a RSVP-TE (Router_Core1-Router_Core6-Router_Core2). Este evento genera una desventaja, pues al ver que tiene reservados recursos para el tráfico de Video y Voz IP, en el enlace de mayor capacidad, decide enrutar explícitamente el trafico con menor requerimiento de QoS por el enlace de menor capacidad y que no está en uso, pero no lo hace adecuadamente, ya que genera un bucle entre el Router_core1 y Router_core6, haciendo mayor la variación del retardo para video (Fig.15), la razón de esto es que tiene más paquetes compitiendo en los buffer de encolamiento [11], generando mayor consumo de los recursos de ancho de banda y de procesamiento en los nodos involucrados. Si no generara ese bucle muy posiblemente tendría mejor rendimiento que RSVP-TE, pues así tenga el enlace menor capacidad, este tiene suficiente ancho de banda para trasportar tráfico de Email y FTP, que no tienen un consumo tan alto como el generado por la aplicación de Video conferencia.

La Tabla 4 detalla los resultados arrojados en la simulación para el presente escenario aplicados a la transferencia de video.

Profundizando en los resultados encontrados anteriormente, se tiene que la mayor variación del retardo la tiene MPLS con CR-LPD, este resultado se da por el bucle que se genera con el tráfico Best Effort.

Por otro lado, la grafica muestra que MPLS se estabiliza para valores menores a los de ATM con una diferencia de 7,7x10^-11 para CR-LDP y de 1,13x10^-10 RSVP-TE, mostrando una superioridad de MPLS con este ultimo protocolo de señalización. La razón de este comportamiento se basa en que el tráfico enviado por las aplicaciones Best effort disminuyen en el tiempo, razón por la cual ya no afecta el rendimiento de CR-LPD.

La menor pérdida de paquetes la presentó ATM con 0.003 paquetes/seg, a comparación de MPLS que tiene 0.006 y 0.007 paquetes/seg con sus dos protocolos de señalización. Como estos valores están por debajo del 1% de las perdidas, se concluye que están dentro de la recomendación de la ITU-T y que el mayor descarte de MPLS está soportado en su mejor desempeño en el retardo y en la DV.

Finalmente, esta topología presenta un reto para MPLS, ya que cada uno mostró una debilidad en el momento de re-enrutar el tráfico, pues la decisión tomada por CR-LDP, de enviar todos los datos Best Effort por un camino diferente de las aplicaciones sensible al retardo, es buena, pero al hacerlo genera un bucle que afectó el rendimiento de la red. Por otro lado, RSVP-TE decidió enrutar todo el flujo de información por la mejor ruta, al igual que ATM, aunque incrementando la pérdida de datos para poder mejorar el parámetro de variación del retardo en video conferencia.

Escenario 3: Fallo del enlace.

Finalmente, se presenta una variación de la topología anterior, para analizar el desempeño cuando se simula un fallo del enlace entre Router_Core1 y Router_Core2. Dicho evento sucede 125 segundos después de iniciada la simulación, a los 155 segundos se restablece el mismo

En la Fig.16 se puede observar que, inicialmente, comienza la transmisión y transcurridos 125 segundos la ruta denota ausencia. Entre los 125 segundos y 155 segundos, no existe ningún tráfico. Una vez restaurado se reencamina por el camino calculado inicialmente. MPLS ofrece una retransmisión inmediata, aproximadamente a los 156 segundos, a diferencia de ATM, donde su recuperación es muy lenta (1 minuto después).

La diferencia radica en la ventaja de MPLS al aplicar el establecimiento de los LSP's explícitos, que proporcionan un rápido encaminamiento de la información a partir de los parámetros que se hallan configurados, asegurando siempre la ruta que permita mayor confiabilidad y seguridad, a diferencia de ATM, que sólo se vale del protocolo de enrutamiento para asignar las rutas. La Fig.17 presenta el enlace por el que se redirigen los datos:

La Tabla 5 y la Fig.18 presentan los valores en segundos del retardo generado por el cambio de ruta del flujo de datos a través de los enlaces.

Era de esperarse, debido a la conducta vista en las figuras de troughput, que el retardo superior iba ser presentado por ATM con respecto a MPLS, 10 veces mayor en su valor más alto, como resultado en la demora de re-enrutamiento. Por otro lado, RSVP-TE tiene un menor retardo frente a CR-LDP, aproximadamente un 28% menor, aunque no es muy notable si mantiene su ventaja cuando hay que tomar decisiones en momentos de caídas de enlace.

4. Conclusión

En la búsqueda de ofrecer calidad de servicio a las aplicaciones de última generación, que son muy sensibles al retardo por su alto contenido multimedia, es muy importante desviar tráficos por nodos que tengan poco uso, con ello, los nodos principales no se saturan y la red puede dar mayor calidad de servicio, esto es cierto siempre y cuando no se generen bucles en el establecimiento de LSP's.

Debido a la rápida estabilización de MPLS configurado con el protocolo de enrutamiento RSVP-TE, éste es más efectivo en redes que tengan grandes variaciones en el tráfico que trasportan, en cambio MPLS configurado con CR-LDP tiene un mejor comportamiento en redes de alta demanda de tráfico constante.

La baja necesidad de procesamiento de los LSRs de Core en MPLS, se ve reflejada en una disminución de la variación del retardo, comparada con ATM, esto influye en ambas topologías simuladas, donde las mayor diferencia se encuentra al trasportar una aplicación en tiempo real con una gran necesidad de ancho de banda, debido a que es video-conferencia con una resolución alta, la cual necesitaba una ancho de banda un poco mayor a 2Mbps.

En el momento de toma de decisiones, donde se ve comprometido el tráfico transportado por los enlaces, las dos tecnologías hacen bien su trabajo cada uno con sus métodos específicos, aunque con una ligera ventaja de MPLS por la ayuda encontrada en los protocolos de señalización utilizados.

Siempre y cuando no existan deficiencias en el enrutamiento para el establecimiento de un LSP, MPLS será superior a ATM, dando mayor posibilidad de dar calidad de servicio a las aplicaciones que son sensibles a los retardos.

En cuanto a entornos en los cuales es más óptimo aplicar MPLS o ATM, las aplicaciones que requieren tiempo real para su buen desempeño y se tiene una estructura de red compleja y robusta, la mejor opción es MPLS. Cuando la fiabilidad de los datos no es tan estricta y se tiene un flujo donde la latencia de estos no va a afectar la interactividad en dispositivos terminales, ATM cumple con los requerimientos necesarios para ofrecer una comunicación segura con el sacrificio en tiempos de retardo que introducen los mecanismo que tiene para realizar el envío, recepción, re-enrutamiento y conocimiento de nuevas rutas para los diferentes tráficos circundantes en la red.

Referencias

[1] RFC-3031, (December 2009), Multiprotocol Label Switching Architecture. Available: http://www.ietf.org/rfc/rfc3031.txt.         [ Links ]

[2] I. Minei, J. Lucek, MPLS-Enabled Applications: Emerging Developments and New Technologies, Editorial Wiley, 2005, pp: 37-48.         [ Links ]

[3] N. Tan, MPLS for Metropolitan Area Networks, Editorial Auerbach, 2004, pp: 17-22.         [ Links ]

[4] RFC 3209 RSVP-TE, (March, 2009) "Extencions to RSVP for LSP Tunnels." Available: http://www.ietf.org/rfc/rfc3209.txt.         [ Links ]

[5] R. Gallaher's, MPLS Training Guide: Building Multi Protocol Label Switching Networks. Editorial Syngress, 2003, pp: 36-45, 50-75.         [ Links ]

[6] RFC-3209 RSVP-TE, (January - April de 2010). Extensions to RSVP for LSP Tunnels. Available: http://www.ietf.org/rfc/rfc3209.txt.         [ Links ]

[7] T. Sthephen, IP Switching and Routing Essentials: Understanding RIP, OSPF, BGP, MPLS, CR-LDP, and RSVP-TE. Editorial Wiley, 2002, pp: 229-322, 257-265.         [ Links ]

[8] RFC-3212, (October 2009 - April 2010), Constraint-Based LSP Setup using LDP. Available: http://tools.ietf.org/html/rfc3212specification. http://tools.ietf.org/html/rfc3036.         [ Links ]

[9] M. Hassan and M. Aticuzzaman, Performance of TCP/IP Over ATM Networks, 2000, 27-37, 43-50.         [ Links ]

[10] ITU-T. Y.1541, (Abril 2010), Infraestructura mundial de la información, aspectos del protocolo internet y redes de la próxima generación. Disponible: http://www.itu.int/rec/T-REC-Y.1540-200711-I/es.         [ Links ]

[11] W. Evans William and C. Filsfils, Deploying IP and MPLS QoS for Multiservice. Networks: Theory & Practice, Editorial Morgan Kauffman, 2007, pp: 24, 38-59, 87-99.         [ Links ]

[12] ITU-T, (April, 2010). QoS on Best- Effort IP Networks. Available: http://www.itu.int/itudoc/itu-t/com13/ipexpert/ipmedia/71265-es.html.         [ Links ]