Migración de redes de voz IPv4 a IPv6

From voice over IPv4 to voice over IPv6 networking migration

Octavio Salcedo¹, Danilo López², Fausto Alexánder Gamboa Quiroga³

¹ Ingeniero en Sistemas, magíster en Ciencias de la Información y las Comunicaciones, estudiante de Doctorado en Informática. Docente de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. ojsalcedop@udistrital.edu.co
² Ingeniero electrónico, magíster en Teleinformática. Docente e investigador de la Universidad Distrital Francisco José de Caldas. Bogotá, Colombia. dalopezs@udistrital.edu.co
³ Ingeniero de Sistemas. Ingeniero de Calidad de Software de la Secretaría Distrital de Salud. Bogotá, Colombia. fagamboaq@correo.udistrital.edu.co

Fecha de recepción: 26 de Agosto de 2011 Fecha de aceptación: 28 de Noviembre de 2011

Resumen

El presente artículo expone el estado actual de las redes de voz y su funcionamiento sobre las redes IP versión 6, así como las diferentes arquitecturas en las que se pueden implementar. Los resultados analizan las ventajas de las redes de voz sobre IP versión 6 con respecto a la versión 4 y su influencia en la calidad del servicio, a partir de la medición y evaluación del desempeño de los parámetros retardo, jitter y pérdida de paquetes.

Abstract

This article discusses the current state of voice networks and IP networks running on version 6, and the different architectures that can be implemented. The results analyze the benefits of voice over IP networks with version 6 over version 4 and its influence on the quality of service, from measuring and evaluating outstanding parameters delay, jitter and packet loss.

Keywords: Quality of service, H.323, IPv6, SIP, VoIP.

1. Introducción

Los esquemas tradicionales de transmisión de voz han sido replanteados, dada la necesidad de proveedores y usuarios de servicios de telecomunicaciones, de migrar todos ellos hacia una red donde estos converjan. La convergencia natural de estos se ha dado hacia internet, ya que en esta red puede coexistir la transmisión de cualquier tipo de información, ya sea video, audio o datos, ver Fig. 1. Por esta razón para transmitir voz es necesario estudiar el protocolo IP, base de la transmisión de datos en Internet.

En la actualidad se está dando la migración de la versión 4 de IP a la versión 6, ya que el creciente número de máquinas conectadas al Internet, en conjunto con la deficiente manera en que las direcciones IP son asignadas, han provocado una pronta escasez en el espacio de direcciones disponibles del protocolo de red actual (IPv4) [1] esto ha crecido por la tendencia de llevar el Internet a diferentes electrodomésticos. Además, se tienen mejoras en seguridad y mecanismos para disminuir la complejidad en la administración de las redes. Por naturaleza, las señales analógicas de voz se perciben como una secuencia de vibraciones de sonido. Debido a que las vibraciones no pueden ser representadas directamente en formato digital, las telecomunicaciones modernas deben reproducir las señales de voz de la toma de muestras de sonido humano. Después estas muestras son codificadas en dígitos para su transmisión como datos.

Las redes telefónicas tradicionales asignan circuitos dedicados para comunicaciones de voz. Esto ocurre cada vez que alguien levanta el teléfono y marca a un receptor. Debido a que los circuitos están dedicados al usuario, la calidad de las señales de voz se puede garantizar, pero esto implica que se desperdicia ancho de banda cada vez que hay períodos de silencio durante la comunicación.

Este documento muestra los requerimientos para implementar el servicio de voz sobre una red IPv6, también muestra los elementos que afectan la calidad de servicio (QoS), las especificaciones para realizar una migración de voz sobre IPv4 a IPv6, y muestra las oportunidades actuales y a futuro de implementar esta tecnología.

Para transportar voz sobre IP, la señal analógica de la voz se muestrea, se cuantifica y se codifica, para convertirla en paquetes de datos formando un datagrama IP, en el nodo destino se realiza el procedimiento inverso.

Para voz sobre IP, uno de los primeros protocolos en ser usados es el estándar de la ITU H323, que cubre la mayor parte de los mecanismos necesarios para la integración de la voz, estos se pueden ver en la Fig. 2. El VoIP/H323 [2] tiene como objetivo primordial facilitar y asegurar la interoperabilidad entre equipos de diversos fabricantes, establece los aspectos como supresión de silencios, compresión, direccionamiento y establecimiento de elementos que permiten la interconectividad con la red telefónica conmutada (RTC) tradicional. La pila de protocolos de H.323 es la siguiente:

RTP (Protocolo de Transporte en Tiempo Real) y RTCP (Protocolo de Control en Tiempo Real) son los encargados del transporte multimedia en tiempo real y su control. RSVP (Protocolo de Reservación) se encarga de dividir los paquetes de datos grandes y dar prioridad a los paquetes de voz cuando hay una congestión en un nodo. Los códecs (G.711, G.723.1, etc.) son los estándares para la compresión de la voz. H.225 Call Control es usado para conectar dos participantes, después del establecimiento; H.225 RAS Control (Registro, Admisión y Estado) es un protocolo de comunicaciones que permite a una estación H323 localizar a otra estación H323 a través de una entidad llamada Gatekeeper.

3. Ip Versión 6

El encabezado de la versión 6 es una versión mejorada de la versión 4, consta de 40 octetos distribuidos en los siguientes campos, que se pueden observar en la Fig. 3: [4] - [6]

• Versión (4 bits): es el número de versión de IP, es decir, 6.
• Clase de tráfico (8 bits): especifica la clase de tráfico.
• Etiqueta del flujo (20 bits): se define un flujo como una secuencia de paquetes enviados desde un origen específico a un destino específico.
]]> Longitud del paquete (16 bits): especifica el tamaño total del paquete, incluyendo cabecera y datos, en bytes.
• Siguiente cabecera (8 bits): indica el tipo de cabecera que sigue a la cabecera fija de IPv6.
• Límite de saltos (8 bits). es el número de sal tos máximo que le queda al paquete. Es el equivalente al TTL de versión 4.
• Dirección origen (128 bits). es la dirección del origen del paquete.
• Dirección destino (128 bits). es la dirección del destino del paquete.

Para el soporte de servicios de voz, los campos más importantes de la cabecera, que aseguran la calidad del servicio, son: Clase de tráfico y Etiqueta de flujo.

Clase de tráfico está disponible para usarse por nodos origen y/o enrutadores de reenvío para identificar y distinguir entre las diferentes clases o prioridades de paquetes IPv6. Este funciona como una clase de "servicio diferenciado.

Los siguientes requisitos generales se aplican al campo Clase de tráfico:

]]>

La interface de servicio para el servicio IPv6 dentro de un nodo debe proporcionar un medio para que un protocolo de capa superior provea el valor de los bits Clase de tráfico en los paquetes originados por ese protocolo de capa superior. El valor por defecto debe ser cero para todos los 8 bits.

• Los nodos que soportan un uso (experimental o estándar eventual) específico de algunos o todos los bits Clase de Tráfico se les permite cambiar el valor de esos bits en los paquetes que ellos originan, reenvían, o reciben, como sea requerido para ese uso específico. Los nodos deben ignorar y dejar sin alterar a cualquiera de los bits del campo Clase de tráfico para los cuales no dan soporte a un uso específico.

• Un protocolo de capa superior no debe asumir que el valor de los bits Clase de tráfico en un paquete recibido son los mismos que el valor enviado por el origen del paquete [4].

El campo Etiqueta de flujo puede ser usado por un origen para etiquetar secuencias de paquetes para los cuales solicita un manejo especial por los enrutadores IPv6, como la calidad del servicio no es estándar, resulta muy útil para asegurar la calidad del servicio de la transmisión de voz.

Un flujo en transmisión de voz es una secuencia de paquetes enviada desde un origen determinado hacia un destino (unicast o multicast), para el cual el origen desea un tratamiento especial por los enrutadores intermedios. Deben enviarse todos los paquetes que pertenecen a la misma conversación con la misma dirección origen, dirección destino, y etiqueta de flujo. Si alguno de esos paquetes incluye una cabecera Opciones de Salto a Salto, entonces todos ellos deben originarse con los mismos contenidos de cabecera Opciones de Salto a Salto. En síntesis, todos los paquetes de la conversación deben llevar los mismos valores que aseguran la calidad del servicio, para así ser tratados de la misma forma por los nodos intermedios.

4. Migración De Voz A Ip Versión 6

El protocolo SIP, cuya pila de componentes se puede observar en la Fig. 4, se concentra en el establecimiento, modificación y terminación de las sesiones, y se complementa entre otros con el SDP (Protocolo de Descripción de Sesión), que describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecs se usarán durante la comunicación. También se complementa con el RTP (Real-time Transport Protocol). RTP es el verdadero portador para el contenido de voz y video que intercambian los participantes en una sesión establecida por SIP [7].

SIP fue diseñado de acuerdo con el modelo de Internet, por el grupo de trabajo MMUSIC (Multiparty Multimedia Session Control) del IETF (Internet Engineering Task Force), con el fin de estandarizar sesiones interactivas de usuario, con elementos multimedia; es un protocolo de señalización extremo a extremo que implica que toda la lógica es almacenada en los dispositivos finales (salvo el enrutado de los mensajes SIP). El estado de la conexión es también almacenado en los dispositivos finales.

El precio a pagar por esta capacidad de distribución y su gran escalabilidad es una sobrecarga en la cabecera de los mensajes producto de tener que mandar toda la información entre los dispositivos finales. La cabecera del protocolo consta de los siguientes campos:

• Via: indica el transporte usado para el envío e identifica la ruta del request.
• From: indica la dirección del origen de la petición.
• To: indica la dirección del destinatario de la petición.
• Call-Id: identificador único para cada llamada y contiene la dirección del host.
• Cseq: se inicia con un número aleatorio e identifica de forma secuencial cada petición.
]]> Contact: contiene una (o más) direcciones que pueden ser usadas para contactar con el usuario.
• User Agent: contiene el cliente agente que realiza la comunicación.

Para que la transición hacia IPv6, mediante el protocolo SIP, sea una solución completa tiene que manejar tanto la capa de señalización y la capa de sesión. Aunque SIP no extendido puede manejar redes heterogéneas IPv6/IPv4 en la capa de señalización siempre que los servidores proxy y el Sistema de Nombres de Dominio (DNS) se configuren correctamente, los agentes de usuario con diferentes redes y la dirección que usen diferentes redes y espacios de direcciones deben implementar las extensiones para el intercambio de voz entre ellos [8].

4.1. Calidad de servicio QOS

El principal problema que presenta actualmente la penetración tanto de VoIP como de todas las aplicaciones de IP es garantizar la calidad de servicio, debido a retardos y ancho de banda. Las diferentes fuentes de retardo en transmisión de VoIP se pueden observar el la Fig. 5.

Los principales problemas en cuanto a la calidad del servicio (QoS) de una red de VoIP, son la Latencia, el Jitter la pérdida de paquetes y el Eco. En VoIP estos problemas pueden ser resueltos mediante diversas técnicas que se explican más adelante.

Los problemas de la calidad del servicio en VoIP vienen derivados de dos factores principalmente:

• Internet es un sistema basado en conmutación de paquetes y por tanto la información no viaja siempre por el mismo camino. Esto produce efectos como la pérdida de paquetes o el jitter.
]]> Las comunicaciones VoIP son en tiempo real lo que produce que efectos como el eco, la pérdida de paquetes y el retardo o latencia sean muy molestos y perjudiciales y deban ser evitados.

Cuando las tramas son transmitidas a través de una red IP, la cantidad de retardo experimentado por cada trama puede diferir. Esto es causado por la cantidad de retardo de encolamiento y tiempo de procesamiento que puede variar dependiendo del tráfico cargado en la red. Sin embargo, el gateway fuente genera tramas de voz a intervalos regulares (es decir, cada 20 ms), el gateway destino típicamente no recibirá tramas de voz en intervalos regulares debido al problema del jitter.

El jitter entre el punto inicial y final de la comunicación debiera ser inferior a 100 ms. Si el valor es menor a 100 ms el jitter, puede ser compensado de manera apropiada, en caso contrario debe ser minimizado.

La latencia se define técnicamente en VoIP como el tiempo que tarda un paquete en llegar desde la fuente al destino. Las comunicaciones en tiempo real (como VoIP) son sensibles a este efecto. Es el problema de "pisarnos". Al igual que el jitter, es un problema frecuente en enlaces lentos o congestionados. La latencia o retardo entre el punto inicial y final de la comunicación debiera ser inferior a 150 ms. El oído humano es capaz de detectar latencias de unos 250 ms, 200 ms en el caso de personas bastante sensibles. Si se supera ese umbral la comunicación se vuelve molesta.

El eco es una reflexión retardada de la señal acústica original, este produce un retorno de la señal en los altavoces. Este problema se agudiza cuanto mayor sea el retardo y mayor su intensidad. La medida tolerable es que llegue a 65ms y una atenuación de 25 a 30 dB [9]. La pérdida de paquetes es el porcentaje de paquetes descartados en la red, pueden producirse por una alta tasa de error en los medios de enlace. En el caso del tráfico de datos los paquetes perdidos pueden retransmitirse pero en telefonía IP que es en tiempo real causa distorsión vocal por lo que este no debe ser superior al 1%.

La calidad de servicio se está logrando basándose en los siguientes criterios:

• La supresión de silencios, otorga más eficiencia a la hora de realizar una transmisión de voz, ya que se aprovecha mejor el ancho de banda al transmitir menos información.
• Compresión de cabeceras aplicando los estándares RTP/RTCP.
]]> Priorización de los paquetes que requieran menor latencia. Las tendencias actuales son:

-CQ (Custom Queuing): asigna un porcentaje del ancho de banda disponible.
-PQ (Priority Queuing): establece prioridad en las colas.
-WFQ (Weight Fair Queuing): se asigna la prioridad al tráfico de menos carga.

4.2. Desempeño IPV6 frente a IPV4

Dado que las redes IP fueron concebidas para dar el "mayor esfuerzo", sin mayor compromiso por parámetros de tiempo real que son críticos para la transmisión de voz; para garantizar la calidad del servicio en IPv4, con el paso del tiempo, se utiliza el campo ToS dentro de la cabecera, con el inconveniente que este no se da de extremo a extremo, es muy limitado y muy pocos dispositivos lo implementan.

Debido a los campos Clase de tráfico y Etiqueta de flujo de IPv6, donde la función del primero es especificar parámetros de prioridad, retardo, rendimiento y fiabilidad, la voz se puede manejar con nivel de servicio diferenciado dentro de la red.

Por otro, lado el campo Etiqueta de Flujo [10] permite etiquetar todos los paquetes de la trasmisión de voz como pertenecientes al mismo flujo de tráfico, lo cual permite al origen solicitar un manejo especial por parte de los enrutadores.

Si se configuran adecuadamente estos dos campos, se logra reducir el retardo de la trasmisión de la voz, generando una mayor calidad de audio, por tanto un aumento en la calidad del servicio.

En la siguiente tabla se muestran los beneficios que tiene IPv6 sobre IPv4:

4.3. Arquitectura de integración

Para lograr integración entre los servicios de voz proporcionados por las redes análogas, la RTPBC (Red Telefónica Pública Básica Conmutada), las redes bajo IPv4 y las redes que operan bajo IPv6, es necesario definir una arquitectura donde se puedan tener diferentes esquemas de direccionamiento y afrontar el cambio de versión del protocolo IP. Para solucionar esto se deben implementar puertas de enlace distribuidas, una pila doble que permita las dos versiones del protocolo y entidades de transición, además de un árbol con los pasos para la estrategia de transición. Una propuesta de arquitectura se presenta en la Fig. 7.

En la anterior figura se observa que hasta el gateway de señalización, la transferencia multimedia y la señalización se realiza a través de MTP, ISUP y DSS1, protocolos y elementos propios de la RTPBC. Cuando hace la transición hacia redes IP, se empieza a manejar en la capa inferior IP, en cualquiera de las versiones, 4 ó 6. En la capa superior se maneja SIP.

En este punto hacen su aparición los nodos MGC (Media Gateway Control) y MG (Media Gateway), el primero se encarga de la adaptación de señalización, interfaz a la capa superior, gestión de políticas etc. El segundo realiza la adaptación multimedia en los límites de la RTPBC y la red IP. De aquí en adelante se realiza el enrutamiento y la interoperabilidad de IP entre versiones 4 y 6 de manera normal, en el caso específico de la Fig. 7 se emplea NAT como traductor.

5. Metodología

5.1. Medición del retardo

5.2. Jitter

Para realizar la comparación del Jitter, se hace captura de tráfico con Wireshark en la máquina receptora, de estas capturas se observa un Jitter promedio.

5.3. Generación de tráfico

Adicional a esto, se hicieron pruebas, para medir desempeño con MGEN (Multigenerator), el cual es un generador de tráfico. Se usaron dos clientes de VoIP, el número 1 en Linux y el 2 en Windows usando Linphone. La topología de la red se puede observar en la Fig. 8. La captura de tráfico se realizó mediante Wireshark, corriendo sobre Linux, mientras que el generador de tráfico MGEN se ejecutó sobre Windows XP.

Se aumentó el tráfico de los MGEN, desde 0-200 Mbps, ya que de aquí en adelante, la tasa de pérdida de paquetes genera calidad de voz pobre al calcular valores MOS (Mean Opinion Score) [14], [15].

En las pruebas realizadas no se hizo uso de los campos de IPv6 para mejorar la QoS: Clase de tráfico y Etiqueta de flujo, por lo tanto los valores observados aquí para esta versión del protocolo se pueden mejorar y obtener una mayor calidad de las llamadas.

El Jitter se calcula de acuerdo con Wireshark,

La comparación del Jitter máximo, entre los dos sistemas operativos se muestra en la Fig. 9. En esta imagen se puede observar que en Windows XP, el jitter máximo permanece casi constante en 20 milisegundos, solo hay un incremento en la versión 6 de IP, cuando se tiene tráfico de fondo generado en 200 Mbps, alcanzando 28 milisegundos.

De otro lado, en Linux el jitter máximo va ascendiendo de acuerdo con el incremento del tráfico de fondo generado. Los valores van desde los 10 milisegundos sin tráfico de fondo hasta 20 milisegundos con 200 Mbps en IPv6 y 13 Mbps en IPv4.

6. Resultados

Para la medición del retardo se tomaron como muestra diez llamadas y se realizaron diferentes capturas mediante Wireshark, donde se tomaron los paquetes recibidos y los tiempos de duración, los datos obtenidos se observan en la Tabla 2 [13].

Estos tiempos se grafican en forma de barras para observar la mejora sustancial en el tiempo del retardo, que se da cuando se emplea IPv6, Fig. 10.

Para calcular el retardo se utiliza la Ec. 1.

Así se calcula el retardo para los tiempos de la muestra y se obtiene la Tabla 3.

Con estos valores del retardo se grafica para observar esta vez la disminución del retardo en las redes IPv6, la disminución del retardo se da entre un 35% y un 50%, Fig. 11.

Los resultados del Jitter promedio se relacionan en la Tabla 4.

De esta forma se puede determinar que el Jitter disminuye en la versión 6, si se realiza una regla de 3, para observar en porcentaje la mejora del Jitter se obtiene lo siguiente:

Esto significa que hemos reducido el Jitter en un 33.5475% al usar la versión 6 de IP.

El jitter promedio, que se puede observar en la Fig. 12, muestra un comportamiento diferente en los dos sistemas operativos, mientras en Windows XP este valor decrece a medida que se incrementa el tráfico generado, en Linux el valor va aumentando.

Cuando se mide el porcentaje de pérdida de paquetes, se genera la Fig. 13, donde se confronta el porcentaje de paquetes perdidos contra el tráfico de fondo generado por el MGEN.

En la gráfica se observa que la pérdida de paquetes en los dos sistemas operativos, en la versión 4 del protocolo se inicia cuando se tiene tráfico de fondo generado de 150 Mbps, antes de esto no se presenta, llegando en Windows XP a un máximo de 17% con 200 Mbps en las dos versiones del protocolo. En este sistema operativo la diferencia entre protocolos se presenta principalmente cuando hay tráfico de 100 Mbps, mientras en la versión 4 no hay, en versión 6 hay un 4% de pérdida. Con tráfico de fondo de 150 Mbps, la diferencia entre los protocolos es mínima.

En Linux, se tiene un máximo de pérdida con IPv6 y 200 Mbps de tráfico, que llega al 24%, mientras con este tráfico en versión 4 se llega al 18%. Con tráfico de fondo de 150 Mbps, se tienen pérdidas de 11% y 13% en versión 4 y 6 respectivamente y con 100 Mbps el porcentaje de pérdidas es de 0% y 3% en versión 4 y 6 respectivamente.

Para analizar el MOS (Mean Opinion Score), que es un método para expresar numéricamente la calidad de comunicaciones de tipo multimedia como voz y video, se tiene una escala de 1 a 5, donde 1 representa la imposibilidad de comunicación y 5 una comunicación perfecta que es como tener una comunicación frente a frente. Los valores de estas mediciones se observan en la Fig. 14.

En Windows XP se tienen valores por encima de 4, que está definido como justo, donde se pueden percibir imperfecciones pero el sonido es claro, este es el rango supuesto para comunicaciones de voz. Por encima de este valor de tráfico generado, se observa detrimento en la comunicación, al llegar a un valor de 2.5, que se encuentra en mitad de la catalogación entre muy molesto y molesto, lo cual indica que está cerca a la imposibilidad para la comunicación.

En Linux se presenta un comportamiento similar, decayendo después de que el tráfico pasa de 100 Mbps hasta llegar a valores de 2.4 y 2.7 para versión 4 y 6 respectivamente.

Al comparar la Fig. 13 con la Fig. 14, se puede deducir que la pérdida de paquetes es el principal factor que degrada la calidad de la comunicación. Mientras la pérdida de paquetes se mantuvo en 0, el MOS, fue de 4.5, y a medida que aumentó la pérdida, fue disminuyendo el valor de MOS.

Los valores esperados de rendimiento para voz con IPv4 e IPv6 son, respectivamente, 87,2 y 95,2 Kbps (en caso de que se ignore CRC como Wireshark lo hace, los valores son 85,6 y 93,6 Kbps, respectivamente, y la relación de rendimiento es 0.915). Sin embargo, los factores que afectan el rendimiento, tales como diferencias entre las pilas de IPv6 e IPv4, el procesamiento de datos superiores, y los retrasos no se reflejan en los valores teóricos [15], [17]. Los resultados prácticos pueden verse en la Fig. 15.