Printer Friendly

Herramienta para el monitoreo de parametros de Calidad de Servicio en redes NGN.

Tools for monitoring Quality of Service parameters in Next Generation Networks

I. Introduccion

La evolucion de las redes de datos convencionales hacia redes de proxima generacion [Next Generation Networks, NGN] ha generado retos que la infraestructura de la red debe estar en capacidad de garantizar. Uno de ellos es utilizar la misma infraestructura para transportar multiples servicios como VoIP, videoconferencia, IPTV, navegacion, datos transaccionales, etc.; otro, ofrecer y garantizar calidad de servicio [QoS] a los servicios que la red NGN transporta, entendiendo como QoS lo definido por Crawley, Nair, Rajagopalan, y Sandick (1998) en el RFC 2386 de la Internet Engineering Task Force [IETF]: es decir, como un conjunto de requisitos de servicio que debe cumplir la red durante el transporte de un flujo.

Con base en esto, al analizar la estructura por capas de la red NGN, como lo plantea Cuellar (2010), se define una capa de calidad de servicio intermedia entre la capa de servicios y la capa de transporte. Esta capa tacita es la encargada de ofrecer QoS a los servicios y aplicaciones, y esta compuesta por tres estratos: contratacion, verificacion e infraestructura, como se aprecia en la Figura 1.

[FIGURA 1 OMITIR]

En el estrato inferior, Infraestructura, se ejecutan los procedimientos para garantizar QoS; estos procedimientos hacen referencia a configuraciones que se realizan en dispositivos de interconectividad, como tambien en configuraciones que se hagan al interior de la red de nucleo, como configuracion de VLANs o configuracion de MPLS.

En el estrato Verificacion se comprueba si se esta garantizando y ofreciendo QoS a los servicios que son transportados por la red NGN. Para esto, el sector de normalizacion de la International Telecommunication Union [ITU-T] definio dos recomendaciones, la Y.1540 (ITU-T, 2011a)--en la cual se definen los parametros de calidad de funcionamiento para transmision de paquetes en redes IP--y la Y.1541 (ITU-T, 2011b)--que define los limites que deben alcanzar dichos parametros para garantizar QoS a los servicios y las aplicaciones--.

Por su parte, en el estrato Contratacion se establecen los acuerdos entre el proveedor del servicio y el usuario, para asi conocer que servicios seran transportados, con el fin de que el proveedor pueda clasificarlos y garantizar la QoS a cada uno de ellos.

Lo anterior destaca la necesidad de medir los parametros de QoS especificados en la recomendacion Y.1541, de tal manera que se pueda de verificar si efectivamente se esta ofreciendo QoS a las aplicaciones. Para lograrlo existen multiples herramientas de uso libre--y otras disenadas por fabricantes--, que le entregan al usuario la medicion de los parametros de QoS. Desafortunadamente no se tiene claridad del procedimiento empleado por la herramienta para obtener dichas medidas, razon por lo que se considera importante el diseno e implementacion de una herramienta que permita obtener estas mediciones, indicando claramente el proceso utilizado para obtener la medicion de estos parametros.

Para indicar como fue el proceso de diseno e implementacion de la herramienta para la medicion de parametros de QoS este articulo esta organizado de la siguiente manera. En la seccion II se describe de manera resumida el contenido de las recomendaciones Y.1540 y Y.1541 de la ITU; en la seccion III se describe el diseno de la herramienta implementada; en la seccion IV se presenta el montaje experimental que se implemento para probar el funcionamiento de la herramienta y los datos comparativos obtenidos con una herramienta de uso libre para la medicion de parametros de QoS; finalmente se presentan las conclusiones, el trabajo futuro y las referencias consultadas.

II. Recomendaciones Y.1540 y Y.1541

En la Recomendacion Y.1540 se definen los parametros para evaluar la calidad de servicio para la transferencia de paquetes en una red IP. Los parametros definidos se aplican al servicio IP de extremo a extremo o punto a punto; define (Cuellar, 2010) principalmente cuatro parametros:

* IPTD [IP Packet Transfer Delay]. Corresponde al tiempo que tarda el paquete en pasar por un componente de la red (host, dispositivo de interconetividad o segmento de red). Este es uno de los parametros principales--y criticos--para todas las aplicaciones que utilicen una red convergente. El calculo se realiza utilizando la ecuacion 1:

IPTD: [[suma].sup.n.sub.i=1] = 1 [x.sub.i]/n (Ecuacion 1)

Donde: [x.sub.i]: retardo del i-esimo paquete.

n: numero de paquetes

* IPDV [IP Packet Delay Variation]. Tambien conocido como jitter, corresponde al tiempo esperado de llegada de cada paquete. Este parametro se calcula utilizando la ecuacion 2.

IPTD: [raiz cuadrada de [[suma].sup.n.sub.i=1][x.sub.i.sup.2] - n * [Retardo.sup.2]/[n - 1] (Ecuacion 2)

* IPLR [IP Packet Loss Ratio]. Rata (tasa) de perdida de paquetes. Su valor se obtiene de la relacion entre el total de paquetes perdidos y el total de paquetes transmitidos en un flujo de datos.

* IPER [IP Packet Error Ratio]. Tasa de paquetes con errores; su valor se obtiene de la relacion entre el total de paquetes con errores y el total de paquetes sin errores transmitidos en un flujo de datos determinado

La recomendacion Y.1541, por su parte, especifica valores de calidad de servicio para cada uno de los parametros definidos en la recomendacion Y.1540; para ello, define un numero de clases de QoS en las que se enmarcan los diferentes servicios y/o aplicaciones. Los valores establecidos para cada clase y cada parametro se pueden apreciar en la Tabla 1.

Las clases tienen tipos de aplicaciones o servicios especificos, asi:

Clase 0-1. Aplicaciones en tiempo real, sensibles al retardo y de interaccion alta (e.g. VoIP, videoconferencia y difusion de audio).

Clase2-3. Aplicaciones de datos transaccionales interactivos (e.g., navegacion y senalizacion).

Clase 4. Aplicaciones que soportan perdidas y no presentan problemas con el retardo (e.g., transmision de video y transferencia de archivos).

III. Diseno de la herramienta

Para definir los requerimientos de la herramienta, se realizo un analisis de varias herramientas disponibles en el mercado; esto, con el fin de observar las funcionalidades que ellas ofrecian y su manera de presentar las mediciones de los parametros de QoS al usuario. Entre las herramientas analizadas estan: Cisco SAA [Service Assurance Agent] (Cisco, 2005), VVQManager (Zoho, 1997) y D-ITG [Distributed Internet Traffic Generator] (DITG, s.f; Botta, Pescape, & Dainotti, 2012; Botta, Dainotti, & Pescape, 2007), TamoSoft Throughput Test (Schumann, Huntgeburth, & Maruschke, 2011) e Iperf (Schroder, 2007).

Despues del analisis se definieron los requisitos que debia cumplir la herramienta a desarrollar, asi:

* estar en capacidad de monitorear y capturar cualquier tipo de trafico que se transporte en la red y, con el trafico capturado, poder realizar el analisis necesario para obtener la medicion de los parametros de QoS;

* no estar ligada a ningun hardware propietario para realizar el monitoreo de los parametros de QoS;

* la interfaz a traves de la cual se suministraran los datos debe ser intuitiva, para facilitar la labor de la persona que esta realizando los analisis; y

* el tiempo de duracion de la captura debe ser ingresado por el usuario.

A la herramienta de analisis disenada se le coloco el nombre de Eagle Network Sniffer [ENS]; funciona capturando el trafico que se genera en la red en modo pasivo y esta compuesta por dos componentes: servidor y cliente, los cuales se describen a continuacion.

A. Componente en el servidor

El componente servidor es una parte fundamental de la herramienta ya que cumple con la funcion de capturar los paquetes en un extremo de la red. Los paquetes capturados son filtrados, dependiendo de configuraciones definidas en la interfaz de usuario. Estos datos son almacenados en un archivo para ser procesados de manera conjunta con los datos capturados en el cliente y asi obtener las medidas de los parametros de QoS. La Figura 2 corresponde al diagrama de flujo este componente.

[FIGURA 2 OMITIR]

El bloque definido como Captura de paquetes tiene la funcion que su nombre indica, capturar los paquetes que circulan en la red; para ello previamente se deben haber configurado algunos parametros como la eleccion de la tarjeta de red y el tiempo de captura y filtros que se requieren para realizar la captura. Una vez definidos estos parametros de configuracion se procede a capturar las marcas de tiempo, el identificador de cada paquete (id) y su longitud durante el tiempo definido. En la Figura 3 se puede apreciar este proceso de manera detallada.

[FIGURA 3 OMITIR]

Los datos capturados en el componente servidor se almacenan en un archivo de texto de nombre Servidor.txt, con el fin de procesarlos posteriormente, cuando se realicen los calculos para obtener la medicion de los parametros de QoS.

En el bloque definido como Calculo de parametros, como se aprecia en la ver Figura 4, se calcula cada uno de los parametros de QoS (siempre y cuando se cuente con los archivos de texto generados en el cliente y el servidor, con las marcas de tiempo, la id y la longitud de cada paquete).

De cada uno de los archivos se obtiene la informacion de los paquetes y se compara su identificacion; si ellas coinciden, el paquete se cuenta como enviado satisfactoriamente y se analizan las marcas de tiempo para calcular el IPTD (IP Packet Transfer Delay) y la IPDV (IP Packet Delay Variation); si por el contrario las identificaciones no coinciden, el paquete se cuenta como perdido y se calcula la IPLR (IP PacketLoss Ratio); al finalizar, se cuenta el numero de paquetes enviados satisfactoriamente y el numero de paquetes perdidos obteniendo el total de los paquetes.

Una vez calculado cada uno de los parametros requeridos se procede a almacenar estos datos en archivo con extension .txt (que para este caso se le identificara con el nombre de Resultado.txt); este archivo podra ser visualizado en cualquier momento y exportado a cualquier tipo de herramienta de analisis.

[FIGURA 4 OMITIR]

Al final, se realiza la lectura del archivo de texto Resultado.txt con el proposito de mostrar los datos de archivos utilizados en el proceso de captura de datos, en una ventana generada en la interfaz de usuario.

B. Componente en el cliente

El cliente complementa la herramienta, ya que cumple con la funcion de capturar los paquetes en el extremo contrario del servidor; se inicia con la sincronizacion con el servidor--necesario porque es imprescindible que manejen la misma marca de tiempo, para evitar problemas en los calculos posteriores--; una vez sincronizados cliente y servidor se procede a definir, en la interfaz de usuario, los paquetes que se deseen filtrar. En la Figura 5 se muestra en detalle los bloques que componen el cliente.

El bloque definido como Sincronizacion se encarga de que, tanto el cliente como el servidor, trabajen con un reloj comun, con el fin de que el calculo de los parametros de QoS no se afecte por medidas erroneas. Eagle Network Sniffer utiliza una sincronizacion master/slave debido a que las medidas deben realizarse con un reloj en comun entre las maquinas.

Una vez que el cliente se sincroniza, se procede a definir el tipo de trafico que se quiere capturar. En la Figura 6 se puede apreciar la pantalla inicial de la herramienta con la descripcion de cada campo para su configuracion. Posteriormente se genera un archivo con el nombre cliente el cual contiene los datos capturados por la tarjeta de red; estos datos se envian al servidor para ser procesados.

[FIGURA 5 OMITIR]

IV. Montaje experimental del laboratorio

Con el fin de analizar los resultados que genera la herramienta Eagle Network Sniffer, se implemento el esquema que se aprecia en la Figura 7, el cual esta conformado por dos enrutadores Cisco con una conexion back-to-back y dos switches Cisco. Como herramienta comparativa se selecciono el D-ITG; se escogio por ser una herramienta de uso libre y por entregar la medicion de los parametros de manera similar a la manera como se desarrollo el ENS.

[FIGURA 6 OMITIR]

Se descarga un archivo de 600KB, el cual se encuentra en el cliente, y se produce una transferencia hacia el servidor. Se toman las medidas utilizando tanto el D-ITG como la herramienta Eagle Network Sniffer, con una velocidad de enlace 64Kbps y 256Kbps, con el fin de que se presenten distintos niveles de congestion en los enlaces.

En la Tabla 2 se pueden apreciar los resultados obtenidos para un ancho de banda en el enlace WAN de 64Kbps. La razon de las diferencias radica en la manera como el D-ITG empieza a colocar los datos en el enlace: no se tiene certeza del momento que empieza y termina la medicion de los parametros, ya que cuando se trabaja con el D-ITG, al terminar el tiempo de envio de datos configurado, pasan alrededor de 5 a 9 segundos para que cierre el flujo y cese el envio de informacion.

[FIGURA 7 OMITIR]

En la Figura 8 se observa el montaje que se utilizo para realizar una prueba de VoIP; se efectua una llamada desde la extension 100 hacia la extension 101, haciendo uso de la central telefonica de 3CX de Windows. Una vez establecida la comunicacion se inicia la captura mediante Eagle Network Sniffer--posteriormente se realiza otra prueba utilizando el D-ITG--en un tiempo de 30 segundos.

En la Tabla 3 se pueden apreciar los datos obtenidos con el D-ITG y el Eagle Network Sniffer para el trafico de VoIP. Existen discrepancias en algunos de los parametros; ello se debe a la manera como el D-ITG coloca los datos en los enlaces: basandose en una distribucion estadistica determinada, mientras que la prueba que se hizo con el Eagle Network Sniffer se realizo sobre una llamada real, en la cual las condiciones pueden ser variadas dependiendo del tono y dialogo de prueba de los interlocutores.

[FIGURA 8 OMITIR]

Conclusiones

Las diferencias entre las mediciones obtenidas por el D-ITG y el Eagle Network Sniffer [ENS] se deben a varios aspectos. Uno de ellos que el ENS realiza las mediciones sobre el trafico real generado por las aplicaciones, mientras que el D-ITG coloca el trafico sobre la red utilizando por defecto las distribuciones estadisticas que mas se ajustan al comportamiento de cada aplicacion. Adicionalmente no se tiene certeza de cuando y como el D-ITG termina el flujo de datos enviado y el proceso de medicion de los parametros.

Al realizar la configuracion de la herramienta Eagle Network Sniffer, extremo a extremo, tanto del servidor como del cliente, se debe ser muy cuidadoso para definir de manera correcta el filtro a utilizar, debido a que el software funciona con las identificaciones de cada paquete, por lo que al cometer un error digitando el filtro, los parametros calculados podrian ser erroneos.

Se recomienda que el tiempo de captura definido por el usuario no exceda de 10 minutos, debido a que el proceso de calculo de los parametros se podria demorar un tiempo similar o superior, por el proceso de analisis de los archivos que contienen los datos para los calculos. Se espera que para la proxima version de la herramienta superar esta dificultad.

Trabajo futuro

Contar con herramientas que midan parametros de QoS es de gran utilidad para los proveedores de los servicios de telecomunicaciones, pues permite monitorear el funcionamiento y desempeno de las aplicaciones y tener asi un punto de comparacion entre las herramientas comerciales que ofrecen los fabricantes de dispositivos de interconectividad.

Como trabajo futuro se plantea modificar la herramienta ENS de tal manera que los calculos de QoS se realicen en linea; esta modificacion traeria consigo la disminucion del procesamiento en la maquina donde se este ejecutando la herramienta (lo que es una limitante de esta primera version).

Adicionalmente, con el fin de obtener datos mas precisos de desempeno del ENS, se podria realizar un mayor numero de pruebas, incluyendo su comparacion con otras herramientas disponibles en el mercado.

Referencias bibliograficas

Botta, A., Pescape. A., & Dainotti, A. (2012). A tool for the generation of realistic network workload for emerging networking scenarios. Computer Networks (Elsevier), 56(15), 3531-3547

Cisco Systems. (2005, oct. 25). Measuring Delay, Jitter, and Packet Loss with Cisco IOS SAA and RTTMON [Document ID: 24121]. Recuperado de http://www.cisco.com/image/gif/paws/24121/saa.pdf

Crawley, E., Nair, R., Rajagopalan, B. & Sandick, H. (1998, agosto). A Framework for QoS-based Routing in the Internet [Request for Comments: 2386. IETF--en linea]. Recuperado de http://tools.ietf.org/html/rfc2386.html

Cuellar J.C. (2010). Analisis de configuraciones en el nucleo de una red NGN para garantizar QoS. Sistemas & Telematica, 8(15), 39-50

Botta, A., Dainotti, A., & Pescape A., (2007). Multi-protocol ans multi-plataform traffic generation and measurementv [ INFOCOM 2007, Demo Session, Anchorage, Alaska, USA, May 2007]. Recuperado de http://wpage.unina. it/a.botta/pub/demoInfocom.pdf

Dipartimento di Informatica e Sistemistica D-ITG, Distributed Internet Traffic Generator [Online]. http://traffic. comics.unina.it/software/ITG/ documentation.php

International Telecommunications Union --Standardization Sector [ITU-T]. (2011a). Internet protocol data communication service--IP packet transfer and availability performance parameters: Ginebra, Suiza: ITU

International Telecommunications Union --Standardization Sector [ITU-T]. (2011b). ITU-T, Recomendation Y.1541 : Network performance objectives for IP-based services. : Ginebra, Suiza: ITU

Schroder, C. (2007, ene 31). Measure Network Performance with Iperf [en linea]. Recuperado de http://www.enterprisenetworkingplanet.com/ netos/article.php/3657236/MeasureNetwork-Performance-with-iperf.htm.

Schumann, S., Huntgeburth, B., & Maruschke, M. (2011). Opensource based prototype for quality of service (QoS) monitoring and quality of experience (QoE) estimation in telecommunication enviroments. En Fifth International Conference on Next Generation Mobile Applications and Services.(pp.161-168). Piscataway, NJ: IEEE

Zoho Corporation. (1996). VQManager [en linea]. Recuperado de http:// www.manageengine.com

Alexander Suarez R.

alex_a321@hotmail.com

Zeida Maria Solarte A. MSc.

zsolarte@uao.edu.co

Universidad Autonoma de Occidente

Cali--Colombia

Juan Carlos Cuellar Q. MSc.

jcuellar@icesi.edu.co

Universidad Icesi

Cali--Colombia

Fecha de recepcion: Agosto 13 de 2013

Fecha de aceptacion: Septiembre 9 de 2013

Alexander Suarez Ramirez.

Ingeniero Electronico y de Telecomunicaciones de la Universidad Autonoma de Occidente (Cali). Investigador afiliado al Grupo de Investigacion en Telematica e Informatica Aplicada [GITI] de la Universidad Autonoma de Occidente.

Zeida Maria Solarte.

Ingeniera electronica, Especialista en Redes y Servicios Telematicos y Magister en Telematica, de la Universidad del Cauca. Docente e investigadora afiliada al Grupo de Investigacion en Telematica e Informatica Aplicada [GITI] de la Universidad Autonoma de Occidente.

Juan Carlos Cuellar Q.

Ingeniero Electricista egresado de la Universidad del Valle, Especialista en Redes y Servicios Telematicos de la Universidad del Cauca, Especialista en Redes y Comunicaciones de la Universidad Icesi. Maestria en Telecomunicaciones en la Universidad Pontificia Bolivariana de Medellin. Actualmente se encuentra desarrollando sus estudios de doctorado en telematica en la Universidad del Cauca. Profesor de tiempo completo en la Universidad Icesi y coordinador del Departamento de Ciencias Fisicas y Tecnologicas y las actividades en el Laboratorio de Redes y Comunicaciones. Sus areas de interes QoS y QoE en Redes de Proxima Generacion (NGN) y configuracion de dispositivos de interconectividad.
Tabla 1. Parametros de calidad de funcionamiento que determinan la
QoS en NGN. Tomado de ITU-T Rec. Y.154 (ITU, 2011b)

Parametro de calidad de             Clases de QoS
funcionamiento de red
                              Clase 0           Clase 1

IPTD                           100ms             400ms
IPDV                           50ms              50ms
IPLR                      1 x [10.sup.-3]   1 x [10.sup.-3]
IPER

Parametro de calidad de             Clases de QoS
funcionamiento de red
                              Clase 2           Clase 3

IPTD                           100ms             400ms
IPDV                             U                 U
IPLR                      1 x [10.sup.-3]   1 x [10.sup.-3]
IPER                      1 x [10.sup.-4]

Parametro de calidad de         Clases de QoS
funcionamiento de red
                              Clase 4       Clase 5 *

IPTD                            1s              U
IPDV                             U              U
IPLR                      1 x [10.sup.-3]       U
IPER                                            U

* Clase no especificada.

"U" significa no especificado o sin limites.

Tabla 2. Resultados obtenidos para la aplicacion de ftp utilizando
Eagle Network Sniffer y D-ITG, con un ancho de banda de 64Kbps

Parametro                         Resultados      Resultados Eagle
                                    D-ITG         Network Sniffer

Total Time (s)                    19.719328         19.68555307
Total packets                        132               132.0
Minimum delay (s)                  0.302434         0.242093086
Maximum delay (s)                 10.133899         10.03705000
Average delay (s)                  7.485182         7.402843213
Average jitter (s)                 0.080542         3.230482505
Delay standard deviation (s)       3.233416              --
Bytes received                      132000               --
Average bitrate                53.551521 Kbit/s          --
Average packet rate             6.693940 pkt/s       6.7054250
Packets dropped                 113 (86.67 %)           115

Tabla 3. Resultados obtenidos para la aplicacion de VoIP utilizando
Eagle Network Sniffer y D-ITG

Parametro                        Resultados     Resultados Eagle
                                   D-ITG        Network Sniffer

Total Time (s)                   31.142867         31.184264
Total packets                       894               1010
Minimum delay (s)                 0.324632         0.3126857
Maximum delay (s)                3.2568546         3.4925467
Average delay (s)                4.1895634         4.3678524
Average jitter (s)               1.2487963             --
Delay standard deviation (s)      2.582364          2.894612
Bytes received                     894000              --
Average bit rate               30.5246 Kbit/s          --
Average packet rate            28.70641pkt/s     32.3881 pkt/s
Packets dropped                 606(60.6 %)           490
COPYRIGHT 2013 Universidad ICESI
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2013 Gale, Cengage Learning. All rights reserved.

 
Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Articulo original
Author:Suarez R., Alexander; Solarte A., Zeida Maria; Cuellar Q., Juan Carlos
Publication:Sistemas & Telematica
Date:Jul 1, 2013
Words:3681
Previous Article:Funciones en contexto. Una experiencia enriquecida en la modelacion y simulacion interactiva.
Next Article:Seleccion de alternativas de redistribucion de planta: un enfoque desde las organizaciones.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters