VISIÓN INVESTIGADORA

Visión Electrónica, 2012-12-01 Volumen:6, Año:2 pág: 5–14

RENDIMIENTO DE TECNOLOGÍAS BACKBONE EN EL TRANSPORTE DE VOZ

BACKBONE-NETWORK PERFORMANCE WHEN CARRYING VOICE

Danilo A. López S.

MSc. en Ingeniería Electrónica. Docente de la Universidad Distrital Francisco José de Caldas. Correo electrónico: dalopezs@udistrital. edu.co

Edwin Rivas T.

PhD. en Ingeniería Eléctrica, Electrónica y Automática. MsC en Sistemas de Generación de Energía Eléctrica y MsC en Ingeniería Eléctrica, Electrónica y Automática. Ingeniero Eléctrico. Docente de la Universidad Distrital Francisco José de Caldas. Correo electrónico: eriivas@ udistrital.edu.co

Diego F. Rocha

MSc (c) en Ciencias de la Información y las Comunicaciones. Ingeniero Electrónico de la Universidad Distrital Francisco José de Caldas. Correo electrónico: dfrochaa@correo.udistrital. edu.co

RESUMEN

Este artículo presenta los resultados obtenidos en el estudio de la calidad de servicio sobre redes IP en tráficos sensibles al retardo, como la VoIP sobre la tecnología ATM y MPLS. Se analizarán también diferentes topologías con características propias que permitirán evaluar valores, tales como el retardo y el ancho de banda.

ATM, CR-LDP, MPLS, RSVP-TE, LSP, FEC.

Abstract

This article presents the results of the study of quality of service in IP networks delay-sensitive traffic such as VoIP over ATM technology and MPLS. Was to examine various topologies with characteristics that allow examination of values such as delay and bandwidth.

ATM, CR-LDP, MPLS, RSVP-TE, LSP, FEC.

1. Introducción

La convergencia de servicios en la red Internet implica un aumento importante en el tráfico circundante; esto hace que la networking deba contar con diferentes estructuras lógicas que le permitan soportar múltiples flujos de información (susceptibles y no susceptibles a los retardos). Dentro de las aplicaciones que más exigencias demanda, está la voz que requiere de la reserva de ciertos parámetros para que el cliente tenga una experiencia placentera con el servicio prestado por el proveedor de productos de Internet. Todo ello se traduce en la utilización de una plataforma hardware y software adecuada que no solo soporte el tráfico de voz, sino también otros tipos de transmisiones como multimedia. Esto ha hecho que Frame Relay haya dejado de ser llamativa, y se ha tenido que utilizar otra clase de estándares que soporten varios flujos donde los requerimientos difieren drásticamente. A partir de este análisis surge la necesidad de establecer si MPLS o ATM son las más adecuadas para soportar el envió y retransmisión de voz.

2. Marco teórico

Acerca de V/IP no se escuchó hablar sino hasta la década de los años noventa, cuando un pequeño grupo de investigación en Israel comenzó a trabajar en un nuevo concepto de comunicación entre PC directamente. Con el paso de los años se fue fortaleciendo el concepto de la transferencia de la señal de voz en paquetes que se lograran transmitir a través de la súper-autopista de las comunicaciones. Los grandes fabricantes vieron un potencial en esta tecnología y comenzaron a ofertar las primeras plataformas para VozIP y ATA /gateways [1], y así se aumentó el tráfico en la red. .

A comienzos del nuevo siglo, se creó Asterisk [2], una central telefónica/conmutador basada en Linux, que podía ser instalada en una PC y prestar el servicio de VoIP a partir de un código abierto ofreciendo un potencial de crecimiento para hogares o pequeñas empresas que quisieran implementar esta tecnología. Tres años después se elaboró el softphone gratuito más popular para PC, llamado Skype [3], cuya característica fundamental es permitir la comunicación a través de todos los firewalls y routers de las redes, aspecto que lo convierte en el referente para las aplicaciones VozIP. Hoy en día este tipo de servicios se ha convertido en una exigencia por parte de los usuarios, lo que se traduce para los ISP en la búsqueda y evaluación de tecnologías de redes que permitan establecer conexiones uniformes que proporcionen conversaciones legibles de extremo a extremo. .

Por ser una aplicación sensible al retardo, se debe asegurar una mínima latencia para que haya una buena fluidez en la conversación; se considera aceptable un valor por debajo de los 150 ms. Además, existen otras variables que deben ser tenidas en cuenta, tales como (ver tabla 1): .

1. Priorización de paquetes para reducir latencia.
2. Supresión de silencios.
3. Compresión de cabeceras.
4. Soporte de IPv6.

Tabla 1. Calidad de funcionamiento de diversas aplicaciones

Fuente: [5].

El cumplimiento de las especificaciones estandarizadas por la ITU-T, y visualizadas en la tabla anterior, se logran siempre y cuando la networking cuente con algoritmos que converjan rápidamente y se adapten a los cambios, para así reservar recursos necesarios exigidos por la aplicación específica.

Dentro de los protocolos más robustos para el soporte eficiente de voz sobre IP, está el Modo de Transmisión Asíncrona (ATM) y la Conmutación de Etiquetas Multiprotocolo (MPLS). No obstante, es importante para los ISP tener un referente que determine cuál es el más robusto y adecuado en el transporte de voz. Por tal motivo, a continuación se presenta una serie de simulaciones que muestran los resultados encontrados al evaluar cada tecnología, cuando dentro de la estructura existe un cuello de botella y además aparecen eventos inesperados como la necesidad de reencaminar los datos por caminos alternativos.

3. Simulación y análisis de eventos

Para el desarrollo de la investigación se trabajó sobre las topologías mostradas en las figuras 1 y 3. El software utilizado para ejecutar y analizar las estructuras propuestas fue Opnet (versión Académica) [6]. Aquí es importante destacar que el consumo de recursos de la máquina y el tiempo de simulación de la red es alto; por tal motivo, los eventos se generaron para espacios de tiempo relativamente cortos (en promedio siete minutos).

Topología “cuello de botella”

En la figura 1 se observa el esquema utilizado para el primer caso, en el cual es evidente el cuello de botella en el nodo Router_Core1.

Figura 1. Topología cuello de botella

Fuente: elaboración propia.

Figura 2. Variación del retardo de ATM, MPLS CR-LDP y MPLS RSVP-TE

Fuente: elaboración propia.

Todos los enlaces son OC3 y poseen un ancho de banda de 148.61Mbps. Cada encaminador (Router1, Router2, Router3, Router4, Router_ Core1_ Router_Core2, Router_Core3, Router_Core4) soporta ATM o MPLS (este último asociado con CR-LDP o RSVP-TE), dependiendo de la estructura sobre la que se esté trabajando. Los nodos que aparecen bautizados como “ Red1, Red2, Red3” hacen las veces de servidores y son generadores de tráfico del tipo FTP, E-mail, video-streming y Voz, mientras que “Red4 y Red5” son PC convencionales que hacen las funciones de sumideros o receptores del flujo. Estos dispositivos finales tienen implementado Ethernet de 100Mbps.

La configuración de parámetros de clases de servicio en ATM (UBR o CBR) se implementó de acuerdo con el tipo de tráfico que circula por el nodo de ingreso a la nube ATM (Router1 o Router2 o router3), para el caso de MPLS según la FEC. La política de encolamiento utilizada fue Priority Queuing basada en DSCP.

Como se puede ver en la figura anterior, el recurso por el que se va a competir es el ancho de banda existente entre “Router_Core1” y “Router_Core2” y lo que se pretende obtener es la variación del retardo generado por cada técnica, a fin de poder establecer cuál es la más eficiente.

Tabla 2. Valores obtenidos con ATM y MPLS

Fuente: elaboración propia.

La figura 2 y la tabla 2 condensan la variación del retardo encontrado para la voz.

Concretamente, se encuentra que ATM tiene un menor desempeño que MPLS asociado con los protocolos de señalización CR-LDP y RSVP-TE (el cual corresponde a un 40 % en sus valores máximos). Esto es debido al tratamiento que tiene ATM de los diferentes flujos de tráfico en su nivel de aplicación, donde existe un mayor gasto de procesamiento para el envío de cualquier tipo de datos en los nodos, ya que cada uno de estos debe hacer un proceso de lectura de encabezado IP y decidir el siguiente salto. Lo anterior no ocurre en MPLS, pues este tiene un gasto mínimo de procesamiento en los LSR (Router_Core1 y Router Core2) al tener que analizar únicamente una etiqueta.

La mejor calidad de servicio prestada por MPLS es producida gracias a la reserva de recursos establecida por los protocolos RSVP- TE y CR-LDP. Adicionalmente, se puede concluir que no existe una diferencia muy marcada en cuanto a la variación del retardo generado por estos tipos de señalización; hecho que se traduce en un comportamiento muy similar.

En cuanto a la perdida de paquetes, ATM muestra un excelente comportamiento debido a que todos los paquetes enviados fueron recibidos. Por otro lado, MPLS sí presenta un descarte de paquetes que, aunque es alto, al verlo desde los valores de ATM no supera el estándar del 3 % presentado en la tabla 1, que indica el nivel de tolerancia soportado por aplicaciones como la voz.

Topología “de reenrutamiento”

La figura 3 muestra que la topología de trabajo parte de la utilizada en el análisis anterior, a la que se le incluye el nodo adicional “Router_ Core5” para crear una ruta redundante a la inicialmente establecida; adicionalmente, se reduce el ancho de banda disponible entre el Router_Core1 y el Router_Core2 a un E1 y de esta forma es puesta a prueba la eficiencia de ATM y MPLS para aplicar reencaminamiento por la ruta: Router_Core1, Router_Core5, Router_Core2, la cual posee el ancho de banda necesario (OC3) para soportar el flujo de voz.

Figura 3. Topología reenrutamiento

Fuente: elaboración propia.

Figura 4. Flujo de voz IP enviado y recibido por ATM

Fuente: elaboración propia.

Los resultados encontrados para el caso ATM (utilizando como protocolo de routing OSPF) se plasman en las figuras 4 y 5. Se observa que, a pesar de la necesidad de buscar rutas alternas, la capacidad de entrega no se vio alterada; en cambio, el retardo aumentó considerablemente (unas cuatro veces en comparación con la topología 1 trabajada anteriormente), debido al esfuerzo que debe hacer ATM para decidir por dónde debe redireccionar los paquetes.

Figura 5. Jitter generado para la voz en ATM

Fuente: elaboración propia.

Figura 6. Tráfico de voz con CR-LDP

Fuente: elaboración propia.

El comportamiento obtenido con MPLS+ RSVP-TE y MPLS+CR-LDP aparece en las figuras 6 y 7. De allí se deduce que la información de envío y que la recepción en cada caso es casi idéntica, lo que demuestra la garantía de ancho de banda.

Figura 7. Tráfico de voz con RSVP-TE

Fuente: elaboración propia.

Figura 8. Jitter en MPL

Fuente: elaboración propia.

En cuanto al jitter (figura 8), resulta evidente que posee diferentes conductas, pues CRLDP se comporta mejor en toda la simulación, ya que llega a un máximo de 9,82x10-10 en comparación con RSVP-TE con 1,03x10-9, que es un 4,6 % más.

Figura 9. Tiempo de retardo de voz para las tres tecnologías

Fuente: elaboración propia.

Tabla 3. Comparación entre ATM y MPLS para voz

Fuente: elaboración propia.

Finalmente, como comparación de los tres métodos se muestran dentro de un mismo par de ejes los resultados encontrados en cada caso (figura 9).

En la figura se ve que el mejor desempeño lo tiene MPLS, soportado en sus dos protocolos de señalizaciones en comparación con ATM, donde CR-LDP tiene una diferencia de 0,18x10-10 s, con relación a ATM, y de 0,05x10-10 s con respecto a RSVP-TE. De este resultado se infiere que CR-LDP le está dando mayor prioridad al tráfico de Voz IP.

Al analizar las estadísticas de pérdida de paquetes se puede ver que ATM tiene un mejor comportamiento, ya que presenta el 0,006 % de pérdidas, en contraste con MPLS que en esta topología tiene el 4,1 %, si se asocia con RSVP-TE, y 8,7 % si se combina con CR-LDP (tabla 3).

4. Conclusiones

El mejor comportamiento para transferencias de voz sobre la red de datos lo presenta MPLS, si se compara con ATM, debido a su mayor rapidez de procesamiento y velocidad en conmutación.

En topologías con cuellos de botella, MPLS es superior en cuanto a la variación del retardo, el cual se va a ver reflejado en una mejor QoS hacia el usuario final, en particular para paquetes de voz. Por otro lado, ATM tiene un mejor comportamiento con relación a los paquetes descartados de aplicaciones que toleran errores, pero con un sacrificio en el retardo.

Finalmente, la superioridad de MPLS mostrada en esta investigación frente a ATM confirma el buen trabajo realizado por los diseñadores para resolver los inconvenientes que se presentan en las actuales redes. Esto también se puede soportar en los diversos estudios que se encuentran publicados y que de alguna u otra forma ayudan a un mejor entendimiento de la filosofía inmersa en la conmutación de etiquetas multiprotocolo.

Referencias

1. Cisco, “Gateways de voz y adaptadores ATA Cisco Small Business,” Cisco. [En línea]. Disponible en http://www.cisco.com/ web/solutions/smb/espanol/productos/ voz_conferencias/gateways_ata_voz_ pequenas_empresas.html.
2. Asterisk, “Open source communications,” Asterisk. [En línea]. Disponible en http:// www.asterisk.org/
3. Skype, [En línea]. Disponible en http:// www.skype.com/intl/es/features/
4. ITU-T G.113, “Transmission systems and media, digital systems and networks,” ITU. [En línea]. Disponible en http://www. itu.int/rec/T-REC-G.113-200711-I.
5. ITU-T. G1010, “Sistemas y medios de transmisión, sistemas y redes digitales,” ITU. [En línea]. Disponible en http://www. itu.int/rec/T-REC-G.1010-200111-I/es.
6. OPNET, “Application and network performance,” [En línea]. Disponible en www.opnet.com.
7. J. W. Evans y C. Filsfils, Deploying IP and MPLS QoS for Multiservice Networks: Theory & Practice, San Francisco, Editorial Morgan Kauffman, 2007.
8. I. Minei, J. Lucek, MPLS-Enabled Applications: Emerging Developments and New Technologies. Chichester, Editorial Wiley, 2005.