Espanhol (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
uBio 
Permalink
Introducción
En el mundo de las comunicaciones, los requerimientos de los usuarios finales y clientes empresariales son cada vez más exigentes en cuanto a concentración de servicios, velocidad de transmisión y QoS (del inglés Quatlity of Service) en los distintos tipos de tráfico [1]. Varios avances tecnológicos a nivel de red de acceso y core se han desarrollado, siendo uno de los más importantes las redes VPN-MPLS (del inglés Virtual Private Network Multi Protocol Label Switching). Estas redes permiten garantizar la información entre diferentes sitios remotos de una organización, a través de una red pública como internet, con una mayor flexibilidad, eficiencia, seguridad y bajo costo, sin la necesidad de utilizar comunicaciones dedicadas punto a punto [1]. Adicionalmente, uno de los principales requerimientos en las redes corporativas actuales es proveer QoS mediante diferentes mecanismos. Sin embargo, para redes de gran extensión como internet, es recomendable utilizar DiffServ (del inglés Differentiated Services) que permite resolver el problema de escalabilidad no soportado por otros mecanismos como IntServ (del inglés Integrated Services) [2].
Los nuevos requerimientos y desarrollos tecnológicos han creado una tendencia a nivel mundial en migrar las antiguas tecnologías como ATM (del inglés Asynchronous Transfer Mode) y Frame Relay hacia redes de nueva generación VPN-MPLS con QoS [3]. Sin embargo, el costo de implementar una red con estas características resulta muy significativo para las pequeñas y medianas organizaciones, quienes previo a adquirir el equipamiento necesario, deben realizar una emulación de la misma y determinar las ventajas que obtendrían con la implementación de la nueva infraestructura. Estas emulaciones han sido abordadas a través de herramientas de software licenciado que también implican un costo. Sin embargo, hasta el momento no se han emulado en un entorno completo de software libre que implique cero costo y facilidad de experimentación [4].
El impacto de QoS en redes VPN-MPLS ha sido analizado en otros trabajos relacionados en los que se han utilizado equipos reales en entornos de laboratorio o emulaciones con herramientas de software licenciado. Es así, que en [5] se muestra una propuesta de arquitectura MPLS/DiffServ para proveer mecanismos de QoS en el transporte de la telefonía IP (del inglés Internet Protocol), en la que se calculan las rutas menos congestionadas a través de una subred, donde el tráfico de voz es separado del de datos para resolver el problema de flujo multiproducto de los paquetes que transportan la voz. La provisión de QoS mediante la integración de MPLS y Diffserv fue propuesta en [6] y en [7], en los cuáles se realizó una evaluación de QoS en redes Wimax basadas en IP/MPLS; se utilizó el mecanismo DiffServ y se compara el envío de flujo de datos susceptibles a retardos en las tecnologías MPLS, MPLS-TP (del inglés Multiprotocol Label Switching - Transport Profile) y GMPLS (del inglés Generalized Multi-Protocol Label Switching). Finalmente, en [8] se aplicó la arquitectura Diffserv sobre redes MPLS para la provisión de QoS punto a punto en la transmisión de tráfico en tiempo real.
En la presente investigación se evaluaron los parámetros de QoS para tres escenarios: IP, MPLS y MPSL con Diffserv, determinándose que la red MPLS con Diffserv resultó ser la más adecuada.
En la literatura no se ha encontrado hasta el momento emulaciones de este tipo de redes bajo un entorno virtual de software libre, es así, que el objetivo de delay este trabajo fue evaluar los parámetros de QoS jitter (variación del retardo), (retardo) y packet loss (pérdida de paquetes) en una red VPN-MPLS con y sin DiffServ, emulada bajo un entorno completamente virtual, con la utilización de herramientas de software libre para configurar, manipular y analizar los diferentes tipos de tráfico. El reto radica en el diseño de la red VPN-MPLS, la selección de las herramientas adecuadas de software libre, la configuración de la red, la evaluación de los parámetros de QoS con y sin el mecanismo de Diffserv.
El presente artículo está organizado de tal manera que, en la sección 2 se presenta el marco conceptual relacionado al presente trabajo; en la sección 3 se detalla el diseño y emulación de la red VPN-MPLS en el entorno virtual; en la sección 4 se presenta la evaluación de los parámetros de QoS y los resultados obtenidos en comparación con los estándares de la UIT- T G.1010, Y.1541, IEEE 8021.1p resumidos en [8].
Finalmente, en la sección 5 se presentan las conclusiones de la investigación.
Marco Conceptual
Arquitectura VPN-MPLS
Las Redes VPN-MPLS son redes eficientes, fiables y escalables, utilizadas para la interconexión de las distintas redes de una empresa espaciada geográficamente. El resultado es una plataforma WAN (del inglés Wide Area Network) completamente gestionada y con un bajo costo [9].
Calidad de Servicio (QoS)
Al hablar de QoS, se puede abordar desde dos puntos de vista: En primer lugar, para el usuario, QoS es la percepción de que el servicio funciona adecuadamente, por ejemplo, en una conversación telefónica la comunicación no debe entrecortarse. En segundo lugar, para el personal responsable de la red, QoS es la posibilidad de maximizar el ancho de banda sin degradar las aplicaciones que se encuentran en ejecución. Para este propósito se debe considerar parámetros que no degraden una transmisión en tiempo real, como el control del delay, jitter y packet loss [10].
Mecanismo DiffServ
El mecanismo DiffServ consiste en clasificar el tráfico para ofrecer distintos niveles de QoS de acuerdo a las necesidades de los clientes facilitando estabilidad y despliegue en las redes [11].
Parámetros de QoS
Delay: También llamado latencia o retardo, es la demora o tiempo que tarda un paquete en ser transferido de un origen a un destino [8].
Jitter: Debido al retardo que se produce en los flujos de datos se genera un problema llamado jitter que aparece por congestión en la red, especialmente por una incorrecta sincronización de bits entre sus elementos [8].
Packet Loss: Es el descarte de paquetes que no llegan a tiempo al receptor [8].
Diseño de la red
La red VPN-MPLS diseñada en el presente trabajo está constituida por una red matriz y una red sucursal interconectadas mediante una red MPLS como se muestra en la Figura. 1. Se utilizan diferentes protocolos de enrutamiento en las distintas redes. En la red MPLS se utiliza el protocolo OSPF (del inglés Open Shortest Path First) para mejorar su rendimiento, en la red matriz se emplea el protocolo EIGRP (del inglés Enhanced Interior Gateway Routing Protocol) para acelerar la convergencia en la red e intercambiar información, y en la red sucursal se utiliza el protocolo OSPF para permitir escalabilidad y estabilidad en la red. Para enlazar EIGRP de la red matriz con OSPF de la red sucursal se utiliza el protocolo BGP (del inglés Border Gateway Protocol) que permite la redistribución de rutas. Adicionalmente, se crean redes privadas virtuales para proveer seguridad con VRF (del inglés Virtual routing and forwarding) que actúa como un router lógico que permite definir caminos virtuales para diferentes clientes.
Para el diseño de la red se contemplan las siguientes etapas:
Requerimientos
Selección de la topología de la red
Asignación de direccionamiento y equipo
Emulación de la red
Calidad de Servicio en la red
Requerimientos
Se definieron dos tipos de requerimientos: de usuario y de servicio. Dentro de los requerimientos de usuario se toma en cuenta el tiempo de respuesta, confiabilidad, adaptabilidad y políticas de seguridad de los equipos. Dentro de los requerimientos de servicio se consideran los servicios de videoconferencia, navegación Web, correo electrónico y servicio de voz.
De los requerimientos indicados anteriormente, en el presente trabajo se emplean los siguientes tipos de tráfico: voz, datos críticos, datos de administración, datos generales y Best Effort (Mecanismo de mejor esfuerzo).
Selección de la Topología de la Red
Topología de la Backbone
Una vez analizados los requerimientos, se define utilizar la topología de red Full Mesh (Malla completa) que conecta cada nodo con el resto de nodos para crear redundancia y resistencia a fallas. Esta topología es la más adecuada por conectividad de redundancia que es característica de las VPN-MPLS. Adicionalmente, se busca que cada ruta en el núcleo tenga el next-hop (Próximo salto) más cercano hacia el destino, para tener alta disponibilidad, caminos redundantes y tolerancia a las fallas entre los equipos.
Topología de la red Matriz y de la red Sucursal
La topología que se utiliza tanto en la red matriz como en la red sucursal es la configuración estrella debido a que es escalable, fácil de configurar y de mantenimiento económico.
Asignación de direccionamiento y equipo
Se trabajó con direccionamiento privado y subneteo con máscara /30 para el backbone de la MPLS, los ruteadores de frontera del cliente CE (del inglés Customer Edge router), los routers del cliente de la red matriz y de la red sucursal, lo cual permite la optimización del espacio de direccionamiento. Para los host de los ruteadores cliente se trabajó con un direccionamiento privado clase B para un mayor crecimiento de usuarios tanto para la red matriz como para la red sucursal.
En lo que respecta a los equipos simulados para el backbone se utiliza el ruteador Cisco 3745 con IOS versión mínima 12.4 T, que tiene características VPN- MPLS, el mismo que se encarga de recibir todo el tráfico que le llega y transferirlo a los dispositivos PE (del inglés Provider Edge) (Cisco 3745) donde se concentra toda la información para enviarse a la red matriz y a la red sucursal.
Emulación de la Red
La emulación del proyecto se la realizó con el software especializado GNS3 [12], una herramienta en tiempo real para realizar topologías complejas de red. Adicionalmente, permite la virtualización de sistemas operativos mediante herramientas como VirtualBox
[13] y el software D-ITG (del inglés Distributed Internet Traffic Generator) [14]; para inyectar tráfico y analizar los parámetros de QoS. A través de D-ITG se emplea una técnica intrusiva de inyección de tráfico que permite evaluar los parámetros de QoS de manera diferente a la que se realiza empleando equipos reales.
Tipos de tráfico
Para este trabajo se utilizan los tipos de tráfico recomendados por Cisco Press [15], para un entorno empresarial: voz, datos críticos empresariales (datos transaccionales), datos de administración (administración de la red como IP routing), datos generales (ping, traceroute, entre otros) y Best effort (Scavenger).
Asignación de Ancho de Banda
En la red de prueba se considera un ancho de banda total de 64 Kbps, a cada tipo de tráfico se le asigna un porcentaje del ancho de banda total en función de las recomendaciones dadas por Cisco Press [15]. En la Tabla 1 se detalla la asignación para los diferentes tipos de tráfico. Se asigna el 15 % para voz para evitar que se degrade la conversación; el 20 % para datos críticos empresariales para asegurar el envío correcto de la información; el 10 % para datos de administración para protocolos de enrutamiento; el 10 % para datos generales de la red (ping); y el 5 % para Best Effort donde están los scavenger, que son un tipo de tráfico que perjudica a la empresa; por ejemplo, videos, video juegos, redes sociales, entre otros.
Mecanismo de calidad de servicio Diffserv
Para utilizar el mecanismo DiffServ se debe clasificar el servicio y posteriormente el marcaje de acuerdo al tipo de tráfico.
Marcaje de los paquetes
Se realizó la programación de las clases con los valores de IP Precedence y DSCP (del inglés Differentiated Services Code Point) para realizar el marcaje de los paquetes. Con IP Precedence se puede tener 8 diferentes marcaciones, mientras que con DSCP se logra mayor granularidad, pues se obtienen 64 marcaciones. En el presente trabajo se usa la combinación de DSCP e IP Precedence, mostrado en la Tabla 2. Como se puede observar, el tráfico de voz tiene la mayor prioridad, marcándolo como DSCP EF (código de marcaje) que está asignada en la RFC 2598/3246 [16], [17] para que el usuario final pueda recibir adecuadamente la transmisión y no se degrade la conversación.
Para la marcación con IP Precedence se tiene: Precedence 4 para datos críticos , Precedence 3 para datos de administración donde están los protocolos de enrutamiento, Precedence 2 para datos generales como ping, y Precedence 1 para Scavenger también llamado Best Effort.
Ubicación del marcaje en la red
Existen dos posibles escenarios para ubicar el marcaje, ya sea en el lado del cliente o en el del proveedor. Si el cliente impone su marca, el ancho de banda contratado no permitirá pérdida de paquetes y no habrá reenvió de los mismos; por lo tanto, el costo para el cliente es alto. Por otro lado, si el proveedor impone su marca, no hay aseguramiento de la calidad de servicio al cien por ciento para el cliente, porque el proveedor tiene el control del tráfico que ingresa a la red VPN-MPLS; por lo tanto, el servicio que cobra es más barato. Sin embargo, cuando se excede el tráfico contratado se descartan los paquetes, se incrementa el delay y también los reenvíos de paquetes en la red convirtiéndose en un grave problema para el cliente.
Debido a que es preferible reducir al mínimo la pérdida de paquetes, la marcación del tráfico debe hacerse lo más cerca posible al cliente, debido a que ciertos tipos de tráfico como voz y video deben ser remarcados antes de pasar al proveedor de servicios. Adicionalmente, los servicios que ofrecen los proveedores evolucionan o se expanden a través del tiempo y una manera fácil de ajustarse a estos cambios es el remarcado en el borde del Customer Edge (CE). Por lo tanto, en el presente trabajo, el marcaje se realiza en el borde de salida del CE y no dentro de la red matriz.
Evaluación de la Calidad de Servicio
En esta sección se analizan los parámetros de calidad de servicio: delay, jitter y packet loss. En primer lugar se revisan las recomendaciones de la UIT-T G.1010, Y 1541 y la IEEE 8021.1p y posteriormente se comparan con los valores obtenidos mediante la utilización del mecanismo QoS DiffServ.
4.1. Parámetros de Acuerdo a los Estándares
Los valores establecidos en las recomendaciones de la UIT-T G.1010, Y 1541 y la IEEE 8021.1p se sintetizan y clasifican cualitativamente en [8] como se indican a continuación:
4.1.1. Delay
Como se muestra en la Tabla 3 [8], el delay máximo permitido para VoIP es de 150ms con el fin de que no se solape la conversación, 300 ms para Datos para que exista una adecuada transmisión, y 250 ms para streaming para que evitar la degradación del video.
4.2. Instrumentos de Análisis de Tráfico
Se utilizan los siguientes instrumentos de medición para poder evaluar los parámetros de QoS en la red de análisis: Wireshark y D-ITG [18].
Wireshark es un sniffer que permite capturar, filtrar y analizar tráfico de la red. Permite analizar detalladamente los paquetes y mostrar los resultados en un entorno gráfico [18].
D-ITG es un software para inyectar tráfico y analizar los parámetros de calidad de servicio como delay, jitter y packet loss. En el presente trabajo se inyecta tráfico real de datos, Streamming y VoIP con los códec G.711, G.729 y G.723.1 [14]. Se utilizan dos máquinas virtuales, la una en la red matriz y la otra en la red sucursal. En cada máquina virtual se instala Ubuntu como sistema operativo y el inyector de tráfico D-ITG en un host como transmisor y en el otro host como receptor.
4.3. Mediciones y resultados
Los parámetros de calidad de servicio como delay, jitter y packet loss fueron medidos con los instrumentos indicados en la sección anterior. Para el tráfico de Voz y Streaming se consideró el protocolo UDP (del inglés User Datagram Protocol) y para el tráfico de datos se consideró el protocolo TCP (del inglés, Transmission Control Protocol ) para que los datos lleguen completos. Las mediciones se realizaron sin configurar QoS y luego con QoS mediante DiffServ.
4.3.1. Delay
Los valores de delay medidos se muestran en la Figura 2. Como se puede observar, existe una gran diferencia entre los valores obtenidos sin DiffServ y con DiffServ. Por ejemplo, para el tráfico de VoIP con códec G.711 el delay promedio cambió de 719 ms sin DiffServ a 23 ms con DiffServ, es decir que la reducción fue del 96.80 %; por otro lado, para Streaming la reducción fue del 66.83 %. Los porcentajes de reducción en delay de todos los tipos de tráfico pueden observarse en la Tabla 6. Adicionalmente, al realizarse la valoración cualitativa de delay utilizando la Tabla 3, se puede observar que sin utilizar DiffServ no se obtienen valores adecuados para la correcta operación de la red VPN-MPLS, mientras que al utilizar DiffServ los valores se encuentran en el rango recomendado por los estándares para proporcionar QoS. La valoración cualitativa de delay para todos los tipos de tráfico se observa en la Tabla 6.
4.3.2. Jitter
Los valores de jitter medidos se muestran en la Figura 3, Tabla 7. Como se puede observar, los valores de jitter sin DiffServ y con DiffServ también presentan diferencias considerables como ocurre con de la y. Por ejemplo, para el tráfico de VoIP con códec G.711 el jitter promedio disminuyó de 1 ms a 0.68 ms, es decir que la reducción fue del 32 %. Sin embargo, para Streaming mas bien existió un incremento del 7.53 %. En realidad los valores medidos de jitter sin DiffServ están dentro de los rangos de operación recomendados por los estándares de acuerdo al Tabla 4; sin embargo, se obtienen mejoras al aplicar QoS con el mecanismo DiffServ como se observa en la Tabla 8.
Conclusiones
Se diseñó y emuló una red VPN-MPLS con y sin QoS a través de DiffServ en un entorno virtual únicamente con la utilización de herramientas de software libre. Los resultados obtenidos pueden ser replicados por cualquier organización, sin que le represente costo alguno, para evaluar el desempeño que tendrían en sus redes, previo a la adquisición de equipos.
Con los resultados de delay cuantitativa y cualitativamente, se observa que al utilizar DiffServ se logra una reducción promedio del 96.78 % en voz, 39.21 % en datos y 66.83 % en Streaming, lo cual muestra que DiffServ es capaz de ofrecer un excelente delay en todos los tipos de tráfico.
Los resultados de jitter cuantitativa y cualitativamente demostraron mejoras significativas al emplear DiffServ. Se logró una reducción promedio del
27.88 % en voz, 41.09 % en datos y -7.53% en Streaming, demostrando que DiffServ puede ofrecer un excelente jitter en todos los tipos de tráfico. A pesar de que DiffServ incrementó el jitter en Streaming, se pueden hablar de valores excelentes para una red VPN- MPLS.
Para ejecutar la emulación presentada en este trabajo, se debe disponer de máquinas con capacidad de procesamiento y memoria suficientes para usar las herramientas GNS3 y D-ITG (mínimo 4GB de memoria RAM y 4GHz de velocidad de procesamiento de la PC) que permitan simular plataformas robustas como Cisco y analizar el tráfico de la red. Además se debe configurar adecuadamente el protocolo de la capa de transporte TCP o UDP, ya que de estas configuraciones dependen los resultados de la evaluación de la calidad de servicio.
