Evaluación de provisión de Calidad de Servicios mediante

Servicios Diferenciados
Marcos Chait B.
José Gallardo A.
Carlos Pon S.
Departamento de Ingeniería de Sistemas y Computación,
Facultad de Ingeniería. Universidad Católica del Norte.
Av. Angamos 0610. Antofagasta - Chile.
e-mail: jgallardo@.ucn.cl

Resumen . En la actualidad, la mayor parte de la infraestructura de la red Internet soporta solamente el

servicio de Best Effort, mediante el cual los paquetes generados por las diversas aplicaciones se
envían a sus destinatarios, sin ninguna garantía de que estos sean recibidos en su totalidad o que
estos lleguen sin atrasos. Hasta hace algunos años, cuando la información sólo consistía en datos esto
no representaba grandes problemas, sin embargo, actualmente surgen nuevos tipos de tráfico tales
como por ejemplo audio y vídeo, los cuales requieren mayores anchos de banda e involucran
elevadas restricciones temporales. Frente a esta problemática, se han planteado diversas soluciones,
desde ampliar los anchos de banda (fast y giga ethernet) hasta introducir nuevos protocolos tales como
Servicios Integrados, Servicios Diferenciados o MPLS (Multiprotocol Label Switching).
En el presente documento, se presentan los resultados obtenidos de la aplicación de la arquitectura de
Servicios Diferenciados. Las pruebas se realizaron mediante ensayos de simulación sobre diversas
arquitecturas típicas de red y con diferentes alternativas de tráfico. El simulador de red utilizado, fue el
Network Simulator NS2.
Los resultados alcanzados, se confrontan con los obtenidos mediante la aplicación del servicio de Best
Effort, lográndose identificar las mejoras alcanzadas con la aplicación de Servicios Diferenciados.
Palabras Clave: Redes de Computadores, Internet, Best Effort, Servicios Diferenciados, Simulación,
Network Simulator.

1. Introducción
La conectividad en Internet ha estado basada desde sus inicios en el servicio de mejor esfuerzo
(best effort), en el que a todo tráfico por la red se le da un trato igualitario, no ofreciéndose ningún tipo de
garantía de calidad de servicio (QoS, Quality of Service). Sin embargo en los últimos años se han
desarrollado varios protocolos y mecanismos que permiten proveer la calidad de servicio necesaria a
aplicaciones con requerimientos temporales o de fiabilidad muy estrictos.1

El otorgamiento de calidad de servicio, indudablemente incide en un mayor costo de operación,

afectando el precio de operación por los servicios al usuario final. Al mismo tiempo ese costo contiene un
factor correctivo de la demanda.

Los requerimientos de QoS que involucran reserva de recursos (ancho de banda), dependen del
tipo de aplicación que un usuario solicita. De esta manera habrá aplicaciones que necesitan enviar toda
la información garantizando una determinada QoS, por lo que deberán reservar recursos siempre. Otras
no necesitarán garantías de servicio y el servicio best effort será suficiente. La Tabla Nº 1 muestra los
requerimientos de QoS para aplicaciones típicas.
 Aplicación Fiabilidad Retardo Jitter Ancho de banda
Correo Alta (*) Alto Alto Bajo
electrónico
Transferencia Alta (*) Alto Alto Medio
de archivos
Acceso Web Alta (*) Medio Alto Medio
Login Remoto Alta (*) Medio Medio Bajo
Audio bajo Media Alto Medio Medio
Demanda
Video bajo Media Alto Medio Alto
Demanda
Telefonía Media Bajo Bajo Bajo
VideoConferencia Media Bajo Bajo Alto

(*) La fiabilidad alta en estas aplicaciones se consigue automáticamente al utilizar TCP

Tabla Nº 1 Requerimientos QoS de aplicaciones típica

2. Calidad de Servicio (QoS)

Para dar QoS con congestión es preciso tener mecanismos que permitan dar un trato distinto al
tráfico preferente y cumplir con un determinado nivel de servicio SLA (Service Level Agreement),
establecido sobre los parámetros de calidad de servicio habituales tales como disponibilidad (fracción de
tiempo que el operador asegura que la red esté en funcionamiento), ancho de banda o jitter (Fluctuación
que puede producirse en el retardo de ida y vuelta promedio).

EL SLA (Service Level Agreement) o Acuerdo de Nivel de Servicio es un contrato que se

establece entre el cliente y el proveedor de servicios Internet ISP o entre proveedores de servicios que se
interconectan2. El SLA tiene dos componentes principales: SLS (Service Level Specification) y TCA
(Traffic Conditioning Agreement).

SLS contiene especificaciones sobre el nivel de servicio, que incluyen la capacidad básica del
enlace, confiabilidad, tiempo de respuesta en caso de fallo, aspectos legales y seguridad incluida en el
servicio. TCA define la estructura del perfil de tráfico, en términos de la clasificación de tráfico, las
características de las ráfagas y las prioridades de los distintos servicios.

El SLA en su condición de contrato legal tiende a ser estático, con actualizaciones esporádicas.
En la actualidad se está investigando en la dinamización del contrato SLA, para optimizar la
disponibilidad de recursos y los costos3.

3. Calidad de servicio en redes IP

La congestión y la falta de QoS es el principal problema de Internet actualmente. TCP/IP fue
diseñado para dar un servicio ‘best effort’, por lo que existen aplicaciones que no pueden funcionar en
una red congestionada con ‘best effort’, tales como videoconferencia, VoIP (Voice Over IP), etc. Se han
hecho modificaciones a IP para que pueda funcionar como una red con QoS y se han desarrollado y
estandarizado los dos mecanismos de QoS, basados en la reserva y la prioridad:

• IntServ (Integrated Services) y protocolo RSVP. El usuario solicita de antemano los recursos que
necesita; cada router del trayecto ha de tomar nota y efectuar la reserva solicitada.

• DiffServ (Differentiated Services). El usuario marca los paquetes con un determinado nivel de
prioridad; los routers van agregando las demandas de los usuarios y propagándolas por el
trayecto. Esto le da al usuario una confianza razonable de conseguir la QoS solicitada. Ambos
son compatibles y pueden coexistir.
 En redes modernas es común soportar la plataforma de QoS mediante enrutamiento eficiente
provisto por MPLS (Multi Protocol Label Switching). A continuación se describen los mecanismos de
calidad de servicio incorporados en Servicios diferenciados, por ser la aplicación central en el presente
trabajo.

4. Servicios diferenciados DiffServ

4.1 Arquitectura Diffserv

En este trabajo se dará especial énfasis a la implementación de QoS basada en DiffServ, sobre el
cual se usarán los modelos de simulación y la comparación sobre Best Effort.

La arquitectura de servicios diferenciados Diffserv está basada en un modelo simple donde el

tráfico entrante a una red es clasificado y posiblemente acondicionado en la frontera de la red y asignado
a uno de los posibles “agregados de comportamiento” (behaviour aggregates BA’s). Cada BA está
identificado por un único DiffServ Code Point (DSCP). En el núcleo de la red, los paquetes son enrutados
de acuerdo a un comportamiento salto a salto (PHB) que está asociado a cada DSCP. La unidad básica
de DiffServ es el Dominio DiffServ, donde los servicios son asegurados por principios idénticos. Un
dominio consiste de dos tipos de nodos: Routers de frontera y routers de núcleo. Los routers de núcleo
no participan en señalización o clasificación. Esta arquitectura logra escalabilidad al concentrar funciones
clasificación y acondicionamiento sólo en los nodos de frontera. Los nodos de núcleo no manipulan
información acerca de flujos individuales 4.

DiffServ utiliza el campo DS, en el encabezamiento de los paquetes IP que contiene suficiente
información para los mecanismos de encolamiento, planificación y eliminación de paquetes, denominados
los PHB (Per Hop Behaviour).

Aunque son los PHB los que determinan la efectividad de los parámetros QoS, los clientes sólo
están interesados en servicios extremo a extremo. De esta manera, clientes y proveedores de servicio
deben negociar acuerdos respecto a los servicios provistos. Estos contratos se denominan “Acuerdo de
Nivel de Servicio” (Service Level Agreement SLA). Los SLA, junto con la especificación técnica del
servicio SLS (Service Level Specification) contienen aspectos adicionales como condiciones de pago,
duración de contrato, etc. Desde el punto de vista técnico, el aspecto más importante de SLS es la
especificación de acondicionamiento del tráfico TCS (Traffic Conditioning Specification), que incorpora en
forma detallada los parámetros de calidad de servicio, tales como rendimiento esperado, tasa de pérdida
o retardo y elementos del perfil de tráfico, para lo cual el servicio requerido puede ser provisto.

Para poder proporcionar servicio extremo a extremo, los dominios DiffServ individuales deben
cooperar, es decir, el primer dominio debe negociar con el cliente mientras que los dominios consecutivos
deben negociar entre ellos, a nombre del cliente.

4.2 Identificación de Diffserv

Los servicios diferenciados (DiffServ) son una arquitectura propuesta por el IETF basada en una
serie de mejoras del protocolo IP, que permiten una discriminación de servicio en redes IP, de forma
escalable, sin la necesidad de mantener estados de flujo (como en RSVP) ni señalización en cada salto
del camino. DiffServ proporciona nuevas interpretaciones para el campo ToS (1 byte) del
encabezamiento de los paquetes IP y señala recomendaciones de uso.

El campo Precedence del byte ToS consiste en tres bits que clasifican los flujos desde 111 =
Control de la Red (el más importante) hasta 000 (por defecto). Los siguientes campos son: D (Delay)
Retardo, T (Throughput), productividad, R (Reliability) confiabilidad, y C (Cost) Costo.

En DiffServ el campo ToS se modifica por un campo de 6 bits DSCP (DiffServ Code Point),
compatible con el campo de precedencia de ToS pero no con los bits DTRC. Los otros dos bits restantes
son el actual campo CU (Currently Unused), es decir no utilizado en la actualidad, pero propuesto para
utilizarse en contención de flujo.
 Todo el tráfico con el mismo DSCP se junta y se supone parte del mismo grupo o BA (Behaviour
Aggregate). La circulación de los BA por la red está regida por los PHB (Per Hop Behaviour).

Los PHB estandarizados son EF (Expedited Forwarding) Reenvío acelerado y AF (Assured

Forwarding) reenvío Asegurado.

EF (DSCP=101110) proporciona el mayor nivel de QoS al tráfico agregado. Garantiza el ancho

de banda como una línea dedicada virtual, de modo que cualquier tráfico que exceda el perfil definido es
descartado. Se utiliza para servicios de tiempo real con un throughput determinado.

AF define cuatro clases de tráfico para asignarlo a las colas de un router y tres prioridades de
descarte de paquetes en cada clase (un total de doce DSCP’s), utilizadas normalmente con disciplina
WRED (Weighed Random Early Drop). Se realiza un perfilamiento de tráfico, aumentando la probabilidad
de descarte del tráfico fuera de perfil.

4.3 Tipos de routers en redes DiffServ

First Hop Router: es el router más próximo al host emisor de paquetes. Los flujos de paquetes son
clasificados y marcados acorde a la etiqueta SLA (Service Level Agreement). Es responsable de que el
tráfico esté acorde con el ancho de banda del perfil.

Router de frontera Ingres Router: Se sitúan en los puntos de entrada al backbone Diff-Serv (dominio
DS), efectuando la clasificación de los paquetes en base al campo DS o en base a múltiples campos de
la cabecera de éstos. Son responsables de la creación de los BA configurando y perfilando el tráfico de
acuerdo a las definiciones de DSCP, según los acuerdos SLA definidos con el cliente del servicio.

Egress Router: Se ubican en los puntos de salida de redes Diff-Serv (dominio DS), controlando el tráfico.
Efectúan la clasificación de paquetes en base solo al campo DS de las cabeceras.

Interior (core) Router: Tienen la misión de «sumar» flujos, realizar la clasificación DS y reenvío de
paquetes. Se sitúan dentro del backbone DS (dominio DS).

5. El simulador de redes NS-2

NS-2 (Network Simulator 2)5 es un simulador de eventos discretos de redes de computadores,
orientado a objetos, escrito en C++ y OTcl. Su propósito es implementar:

• Protocolos de red (TCP, UDP, etc).

• Generadores de tráfico (FTP, Telnet, WEB, CBR, VBR).
• Mecanismos de administración de colas en routers (droptail, RED, etc.)
• Algoritmos de ruteo
• Protocolos de multicast
• Protocolos de nivel MAC

NS está construido sobre un interprete OTcl (Object Oriented Tool Command Language), que
tiene un programador de eventos de simulación, una biblioteca de objetos componentes de redes y
bibliotecas de interconexión de objetos de red.

Una red a simular es un programa (libreto del intérprete) en OTcl. El programa define una
secuencia de eventos, define la topología de la red y define el comportamiento de las fuentes de tráfico,
programando su inicio y término de transmisión de paquetes.

Todos los eventos se asocian a los paquetes transmitidos en su recorrido por la topología de la
red. Cada paquete tiene una identidad (ID) única con tiempo de activación y un puntero al objeto que
maneja el evento.
 El programador de eventos (scheduler) lleva el registro del tiempo de simulación y activa todos
los eventos en la cola de simulación programados en un determinado tiempo mediante la activación del
objeto de red apropiado, permitiéndoles realizar la acción adecuada con el paquete apuntado por el
evento.

Las componentes de red se interconectan intercambiando paquetes. Todas las componentes que
requieren utilizar tiempo de simulación (experimentar un retardo) usan el programador de eventos
definiendo un evento de espera para el paquete, esperando que se active automáticamente después de
transcurrido el tiempo de retardo previsto.

5.1 Diseño de NS
Por razones de eficiencia, NS está desarrollado en OTcl y en C++, separando la lógica de la
trayectoria de datos de las estructuras de control y ejecución de la simulación. El programador de eventos
y los objetos componentes de red están escritos en C++, con el objeto de reducir los tiempos de
procesamiento.

Los objetos compilados quedan disponibles para el intérprete OTcl a través de un ligado dinámico
que crea una correspondencia OTcl para cada objeto C++ y hace que las funciones y variables invocadas
sobre el objeto OTcl, actúen realmente sobre el objeto C++.

5.2 Obtención de los resultados de la simulación

Al terminar la simulación, NS produce un archivo de salida basada en texto con los datos de
simulación, según la especificación de salida incluida en el libreto OTcl.

Los datos generados pueden utilizarse directamente para análisis de la simulación o bien servir
de entrada para la herramienta de despliegue gráfico de la simulación NAM (Network Animador).

La conducción de la simulación se realiza a partir e un generador de eventos discretos que

recibe los parámetros de simulación 6 (configuración de nodos, tráficos, largo de paquetes, etc.).

La topología de la red se simula a través de la construcción de nodos, enlaces, agentes de tráfico

y flujo de tráfico de aplicaciones. Un enlace contiene las disciplinas de encolamiento y descarte de
paquetes requeridos por los modelos. Los agentes de transporte definen la estructura de tráfico
disponible para implementar las diferentes aplicaciones, tráfico TCP y UDP desde origen a destino.
Finalmente, la programación de aplicaciones sobre la topología de la red, produce el flujo de paquetes
que permite apreciar en forma gráfica el resultado de la simulación. Alternativamente, el resultado de la
simulación puede analizarse a partir del listado de simulación, tomando como base las estructuras de
datos definidos para los paquetes y eventos.

5.3 Diffserv en NS
El diseño e implementación de la arquitectura Diffserv en NS requiere de la adición de cuatro
módulos a la jerarquía de clases de NS 7: el primero para la funcionalidad básica de routers con Diffserv
(dsRED), el siguiente para la definición de los routers de núcleo, otro para los routers de frontera y el
último para la administración de la política. Técnicamente, cada módulo define una nueva clase en NS.

5.3.1 Módulo dsRED

dsRED es el modulo base para la implementación de Diffserv. Su propósito es implementar toda
la funcionalidad y declara todos los parámetros comunes a los routers de frontera y de núcleo. En la
jerarquía de NS, extiende la clase cola (Queue).

dsREDQueue forma una estructura de colas consistente en cuatro colas físicas, cada una de las
cuales contiene tres colas RED virtuales, que corresponden a los niveles de precedencia. Cada cola
física corresponde a un tipo de tráfico y cada combinación de cola y precedencia se asocia a un Code
Point.
 Los paquetes se encolan en una determinada cola y número de precedencia de acuerdo a su
marca de Code Point. Su tratamiento se realiza a los parámetros correspondientes a esa cola y número
de precedencia. De esta manera el Code Point especifica el nivel de servicio.

La elección de cuatro colas físicas se realiza según la recomendación RFC 2597 8 y corresponde
a las clases de servicio definidas para AF (Assured Forwarding). No todas las colas físicas y virtuales
requieren ser usadas. El usuario puede configurar una instancia dsRED con menos colas físicas o
virtuales, sin embargo el valor no puede ser excedido sin modificar el código y recompilando NS.

5.3.1.1 Tabla de PHB

Una instancia de dsREDQueue contiene una estructura de datos conocida como la Tabla PHB.
Los dispositivos de frontera manejan el marcado de paquetes según code points y los dispositivos de
núcleo simplemente responden a los code points existentes. Sin embargo, ambos dispositivos necesitan
determinar como mapear un code point a una cola determinada y un nivel de precedencia.

La tabla PHB maneja este mapeo a través de un arreglo de tres campos que debe ser asignado
en la programación del simulador.
• Code point
• Clase (Cola física)
• Precedence (Cola virtual)

5.3.2 Módulo de frontera

El modulo de frontera implementa el router de frontera Diffserv. Define la clase edgeQueue que
modela el router respectivo. La clase edgeQueue deriva de la clase dsREDQueue y es responsable por
mantener y procesar múltiples colas físicas y virtualers de acuerdo a sus parámetros, además de marcar
los paquetes con los code point y aplicar la política sobre los agregados de tráfico.

5.3.3 Módulo de política

El módulo o clase de política es utilizado por la clase edgeQueue para sostener la funcionalidad
de la política en Diffserv. La clase de política administra la creación, manipulación y aplicación de las
políticas de router de frontera. Una política determina el tratamiento que un agregado de tráfico recibirá
en el dispositivo de frontera. Los dispositivos de frontera usan información y política para determinar con
que code point deben marcar los paquetes.

Una política se establece entre un nodo de origen y uno de destino. Todos los flujos con el mismo
par origen destino son tratados como un agregado de tráfico único. Cada política define un tipo de
aplicador de política (policer), una tasa de traspaso objetivo y otros parámetros dependientes de la
política específica. Como mínimo, una política define dos valores de Code Point y la elección depende de
la comparación entre la tasa objetivo del agregado y la tasa de envío actual (bits/seg).

Cada agregado de tráfico tiene asociado un aplicador de política, un medidor y un code point
inicial. El tipo de medidor especifica el método para medir las variables de estado requeridas por el
aplicador de política, por ejemplo el medidor TSW tagger mide la tasa de tráfico promedio a través de una
ventana de tiempo específica.

Tras la llegada de los paquetes al dispositivo de frontera, son examinados para determinar a que
agregado de tráfico pertenecen. Se invoca un medidor específico para ese agregado para actualizar
todas sus variables de estado. Se utiliza ya sea el code point inicial u otro degradado respecto del
primero y el paquete es encolado correspondientemente.

5.3.3.1 Tabla de políticas

La clase políticas, es una tabla de políticas para almacenar las políticas de cada agregado de
tráfico. Esta tabla es un arreglo que incluye campos para los nodos de origen y destino, tipo de aplicador
de política, tipo de medidor y code point inicial.
 Para la aplicación de políticas, NS ha implementado seis tipos distintos, entre las que se destaca
Token Bucket que utiliza CIR (Commited Information Rate) tasa de traspaso media comprometida, CBS
(Commited Burst Size) tamaño comprometido de ráfaga y dos niveles de precedencia para descarte. Un
paquete arribando es marcado con baja precedencia si es mayor (en bits) que el token bucket.

5.3.4 Módulo de núcleo

Esta clase emula los routers de núcleo (core) en la arquitectura Diffserv. De esta manera se
conecta con los routers de frontera y reenvía los paquetes de acuerdo a la marca definida por el router de
frontera. Paquetes con code point de baja prioridad, son eliminadas a tasas considerablemente más altas
que los paquetes marcados con code point de alta prioridad.

Los elementos de la estructura de NS presentada, serán utilizados en los ejemplos de

programación incluidos en el siguiente punto.

5.4 Simulación de la arquitectura DiffServ

En el presente punto se dan a conocer a modo de ejemplo los ensayos de simulación de una
determinada configuración de red, trabajando bajo condiciones de best effort y utilizando la arquitectura
de DiffServ. La topología de red analizada se muestra en la figura Nº 1.

d i gi t a l

iMac

iMa c

Figura Nº 1 Topología de red para análisis

En esta topología se pueden identificar tres nodos de origen y tres de destino. El nodo origen 1 se
comunica con el nodo destino 1, el nodo origen 2 con el nodo destino 2 y finalmente el nodo origen 3 con
el nodo destino 3.

Las condiciones de operación bajo las cuales se efectuaron los ensayos de simulación con el
servicio de Best Effort son las siguientes:
• Los enlaces entre los nodos de origen y el router frontera y entre el router frontera y nodos
destino son de 1 Mb/s.
• Los enlaces entre router frontera de entrada, router núcleo y router frontera de salida son de 2.9
Mb/s.
• Los flujos desde los nodos de origen son UDP, CBR
• Los tipos de cola en los nodos de origen son DropTail
• Las colas entre nodos frontera y nodo núcleo DropTail

Luego de implementar la topología de red seleccionada, se procede a la ejecución del archivo

con extensión ns generándose un archivo con extensión nam. El siguiente paso y final es proceder a la
ejecución de este archivo, cuyos resultados gráficos pueden observarse en la pantalla de un computador.
En esta pantalla, se puede detener en cualquier momento el proceso y monitorear el estado de cada
paquete, en su viaje desde el nodo de origen hasta el nodo de destino.
 A continuación se tomó una estadística del comportamiento de las colas entre los nodos frontera
de entrada y salida y el nodo núcleo. El tiempo de simulación considerado es de 5 segundos. La
información procesada, se extrae del archivo con extensión nam que tiene un tamaño de 27 Mbytes para
la cantidad de tiempo de simulación considerada. La Tabla Nº 2, muestra un cuadro resumen del tráfico
total y el porcentaje de perdida de paquetes.

Total de Paquetes 36.340

Total de Paquetes 894
Perdidos
% de Perdida 2,46%

Tabla Nº 2 Cuadro resumen de tráfico (Best Effort)

En el caso de aplicación de la arquitectura de servicios diferenciados, las condiciones de

operación son las siguientes:

• Los enlaces entre los nodos de origen y el router frontera y router frontera y nodos destino son
de 1 Mb/s.
• Los enlaces entre router frontera de entrada_1, router núcleo y router frontera_2 de salida son de
2.9 Mb/s.
• Los flujos desde los nodos de origen son UDP, CBR
• Los tipos de cola en los nodos de origen son DropTail
• Las colas entre nodos frontera y nodo core dsRed
• Tres colas físicas y dos colas virtuales por cada cola física.
• Tiempo de simulación: 10 segundos
• Tipo de política y parámetros: TokenBucket, y diferentes CIR y CBS por cada cola física.

Figura Nº 2 Cuadro de estadísticas generadas por el sistema (Servicios Diferenciados)

 Bajo las condiciones de operación ya señaladas, la Tabla Nº 3 muestra un cuadro resumen del
tráfico total y el porcentaje de perdida de paquetes aplicando la arquitectura de servicios diferenciados.
Los resultados son extraídos del archivo nam generado el cual tiene un tamaño de 55 Mbytes.

Total de Paquetes 72904

Total de Paquetes 609
Perdidos
% de Perdida 0,84%

Tabla Nº 3 Cuadro resumen de tráfico (Servicios Diferenciados)

En forma adicional en la figura Nº 2, se muestra las estadísticas generadas para cada code point
asociado a las diferentes colas. El despliegue se ejecuta cada dos segundos, de acuerdo a las líneas de
código incorporadas en el programa.

En lo referido a los resultados del comportamiento temporal de la red propuesta, bajo las
arquitecturas de best effort y servicios diferenciados, se muestran a modo de ejemplo en las figuras 3 y 4
los resultados obtenidos para los flujos: UDP, CBR entre los nodos origen1 y destino 1.

Nodo Router Router Router Nodo

Origen 1 Edge Core Edge Destino1

Media 842 us
Varianza 0,00000

Media 828 us
Varianza 0,0114

Media 857 us
Varianza 0,0196

Media 857 us
Varianza 0,0101

Figura Nº 3 Flujo entre nodo origen 1 y nodo destino 1 (Best Effort)

Finalmente, en las Tablas Nº 4 y Nº 5 se consigna un resumen de los resultados finales obtenidos

en cuanto a perdida de paquetes y comportamiento temporal con y sin la aplicación de la arquitectura de
servicios diferenciados en la topología en estudio.

Nodo Router Router Router Nodo

Origen 1 Edge Core Edge Destino1

Media 842 us
Varianza 0,0000

Media 828 us
Varianza 0,0156

Media 828 us
Varianza 0,0156

Media 827 us
Varianza 0,0102

Figura Nº 4 Flujo entre nodo origen 1 y nodo destino 1 (Servicios Diferenciados)

 Jitter Nodo Terminales (µs)
Tiempo Medio Tiempo Varianza
Nodo SIN DS CON DS SIN DS CON DS
Final
1 857 > 827 0,0101 < 0,0102
2 800 = 800 0,0200 > 0,0110
3 800 = 800 0,0240 > 0,0150

Tabla Nº 4 Cuadro resumen de Jitter en nodos terminales

Porcentaje de pérdida de paquetes

SIN DS CON DS
2,46 > 0,84

Tabla Nº 5 Cuadro resumen de porcentaje de pérdida de paquetes

6. Conclusiones
El trabajo consignado en el presente informe, ha considerado una evaluación a nivel de ensayos
de simulación del comportamiento de la arquitectura de servicios diferenciados, frente a la provisión
tradicional de servicios del protocolo IP de Internet, el cual se basa en el servicio de best effort. El
software utilizado para este propósito es el Simulador de Redes Network Simulador NS2. Este software
ha sido ampliamente utilizado en diversos trabajos de investigación7 y posee una extensión que hace
posible la implementación de Servicios Diferenciados,

Del análisis de los resultados obtenidos de la simulación se puede apreciar lo siguiente:

• No existen diferencias sustanciales en cuanto a la cantidad total de paquetes perdidos (para los
mismos tiempos de simulación) entre los servicios de best effort y de servicios diferenciados. Las
diferencias sustanciales se aprecian fundamentalmente, en que la cantidad de paquetes perdidos
en la arquitectura de servicios diferenciados depende de los code point con que fueron marcados
los diferentes paquetes. Éstos son diferentes entre las diferentes colas físicas y diferentes entre
colas virtuales, en general los paquetes marcados con menores code point, ya sea en colas
físicas o virtuales, presentan menores perdidas, por lo que los paquetes de mayor prioridad se
ven menos afectados por la saturación de los anchos de banda del canal. Para el caso de los
servicios de best effort, esto no ocurre y la cantidad de paquetes que se pierden es
estadísticamente igual independientemente del nodo del cual provienen considerando que los
tres nodos tienen similares flujos (CBR).
• En cuanto al comportamiento temporal se observa de los resultados obtenidos, que la
arquitectura de servicios diferenciados en general logra disminuir los retardos medios de tráfico
entre nodos de origen y destino disminuyendo adicionalmente (sin eliminarlo) el Jitter producido.

Estos dos parámetros que miden la calidad de los servicios y que presentan ventajas favorables
con la aplicación de servicios diferenciados, justifican ampliamente su aplicación. Sin embargo es
importante destacar, que la calidad de los servicios puede ser ampliamente mejorada aplicando una
combinación de arquitecturas de servicios diferenciados en los nodos frontera y MPLS o servicios
integrados dentro del dominio, el cual está considerado como trabajo futuro en las nuevas simulaciones.

Referencias
1. García, J, Raya, J., Rodrigo, V., “Alta Velocidad y Calidad de Servicio en redes IP”, Alfaomega, 2002.
2. Incera, J., “Métricas de desempeño en redes IP”, Presentación, Encuentro LAFMI Empresa, 2003.
3. Zhao, L, “Service Level Agreement Inmplementation”, Imperial Collage, D. of Computing, 2003.
4. Einsiedler J., “Quality of Service for the Internet: Solutions and Implementations”
5. Fall, K (Editor), “The ns Manual”, 2003.
6. Huang, P., “Intermediate NS”, Presentación Power Point.
7. Pieda J., “A Network Simulator Differenciated Services Implementation”, Nortel Networks, 2000.
8. Heinamen, J et al,” RFC 2597, Network Working Group”, 1999