Diffserv como solución a la provisión de QoS

en Internet
Jorge Escribano Salazar, Carlos García García, Celia Seldas Alarcón, José Ignacio Moreno Novella

Departamento de Ingeniería Telemática

Universidad Carlos III de Madrid
Avenida de la Universidad, 30
28911 Leganés (MADRID)

E-mail: {jescriba, cgarcia, cseldas, jmoreno}@it.uc3m.es

Abstract. IETF has developed two architectures for the
Internet which should enable QoS manage of data flows in IP
networks, Integrated Services (IntServ) and Differentiated
Services (Diffserv). This paper presents a solution to provide
Diffserv QoS support over a VoIP scenario. In addition to this
paper different Diffserv limitations are studied and some
solutions are proposed.
Index Terms— QoS, Diffserv, Bandwidth Broker.
flujos de tráfico. Sin embargo, las actuales redes de datos
no distinguen entre las diferentes aplicaciones que
transportan: no pueden diferenciar entre una
videoconferencia con determinados requisitos de ancho de
banda y la navegación web de características
completamente diferentes. Esto requiere que de alguna
manera las funciones de calidad de servicio sean capaces
de reconocer las aplicaciones para reservarles unos
determinados recursos en la red.

I. INTRODUCCIÓN
En la actualidad los sistemas informáticos se basan en una
red de datos, la cual debe ser capaz de soportar una cada vez
más amplia gama de aplicaciones. El protocolo de Internet
(IP), que ha sido utilizado en estas redes durante las tres
últimas décadas para el intercambio de información entre los
diferentes ordenadores, ha terminado imponiéndose como el
protocolo más usado. Actualmente el desarrollo de estas redes
de datos se está enfocando hacia la provisión de Calidad de
Servicio (QoS), la cual se requiere para permitir asegurar
determinadas características de calidad en la transmisión de
información. El objetivo es evitar que la congestión de
determinados nodos de la red afecte a algunas aplicaciones que
requieran un especial caudal o retardo, como pueden ser
aplicaciones de videoconferencia. Para solucionar este
problema existen dos tendencias bien distintas:
o Sobredimensionar adecuadamente la red de transporte, lo
que implica aumentar cuando resulte necesario los
equipos de conmutación así como el ancho de banda
disponible en los canales. Este método se basa en el
abaratamiento de los sistemas de conmutación y
transporte, si bien provoca una gestión ineficiente por
definición de los recursos disponibles.
o Gestionar de forma inteligente los recursos disponibles,
compartiéndolo de manera desigual entre los diferentes
II. CALIDAD DE SERVICIO
La calidad de servicio consiste en la capacidad de la red
para reservar algunos de los recursos disponibles para un
tráfico concreto con la intención de proporcionar un
determinado servicio. Debemos tener en cuenta que en la red
se pueden utilizar diferentes tecnologías de transporte (como
pueden ser Frame Relay, X.25, SDH, ATM, etc) de manera
que la gestión de QoS implica la interacción con estas
tecnologías y con los equipos de conmutación, que son los que
finalmente determinarán el nivel de QoS alcanzado.
En este momento existen principalmente dos tipos de
tecnologías que proporcionan calidad de servicio. La primera
se basa en la reserva, y asigna recursos basándose en flujos de
tráfico. Alternativamente, un segundo tipo de calidad de
servicio se caracteriza por la priorización de determinado tipo
de tráfico. Veremos más adelante que los flujos de datos
individuales se van agrupando en grandes agregados de tráfico
de acuerdo a la “clase de servicio” a la que pertenezcan, y
dependiendo de esa clase de servicio recibirán un distinto trato
en los diferentes elementos de la red.
En comunicaciones IP se traduce en dos modelos de trabajo:
o Modelo Intserv: basado en la utilización de algún
 protocolo de reserva (RSVP, ReSerVation Protocol) que
permite la reserva de recursos a lo largo de los routers
implicados en la comunicación. El principal problema de
este modelo es la necesidad de mantener información
sobre cada flujo en todos los routers de la red, lo cual
lleva a problemas de escalabilidad. Existe un grupo de
trabajo del IETF encargado de su seguimiento [8].
o Modelo Diffserv: se basa en la división del tráfico en
diferentes clases [6],[7] y en la asignación de prioridades
a estos agregados. Utiliza diferente información de la
cabecera de los paquetes (por ejemplo, DSCP – Diffserv
Code Point) para distinguir clasificar los paquetes y
conocer el tratamiento que debe recibir el tráfico en los
nodos de la red Diffserv.
Calidad de servicio: Diffserv
Los servicios diferenciados (Diffserv) proporcionan
mecanismos de calidad de servicio para reducir la carga en
dispositivos de la red a través de un mapeo entre flujos de
tráfico y niveles de servicio. Los paquetes que pertenecen a
una determinada clase se marcan con un código específico
(DSCP – Diffserv CodePoint). Este código es todo lo que
necesitamos para identificar una clase de tráfico. La
diferenciación de servicios se logra mediante la definición de
comportamientos específicos para cada clase de tráfico entre
dispositivos de interconexión, hecho conocido como PHB (Per
Hop Behavior).
De esta manera a través de Diffserv planteamos asignar
prioridades a los diferentes paquetes que son enviados a la red.
Los nodos intermedios (routers) tendrán que analizar estos
paquetes y tratarlos según sus necesidades. Esta es la razón
principal por la que Diffserv ofrece mejores características de
escalabilidad que Intserv. Dentro del grupo de trabajo de
Diffserv de la IETF [5], se define en [2] el campo DS
(Differentiated Services) donde se especificarán las
prioridades de los paquetes. En el subcampo DSCP
(Differentiated Setvice CodePoint) se especifica la prioridad
de cada paquete. Estos campos son validos tanto para IPv4
como IPv6.
En la arquitectura definida por Diffserv, que podemos ver
en la figura 1, aparecen nodos extremos DS de entrada y
salida, así como nodos DS internos. Este conjunto de nodos
definen el dominio Diffserv y presenta un tipo de políticas y
grupos de comportamiento por salto (PHB - Per Hop
Behavior) que determinarán el tratamiento de los paquetes en
la red.
Figura 1. Arquitectura Diffserv
Debemos tener en cuenta que un dominio Diffserv puede
estar formado por más de una red, de manera que el
administrador será responsable de repartir adecuadamente los
recursos de acuerdo con el contrato de servicio (SLA – Service
Level Agreement) entre el cliente y el proveedor del servicio.
Veamos a continuación las diferentes funciones que deben
realizar los nodos DS:
o Nodos extremos DS: será necesario realizar diferentes
funciones como el acondicionamiento de tráfico entre los
dominios Diffserv interconectados. De esta manera debe
clasificar y establecer las condiciones de ingreso de los
flujos de tráfico en función de: dirección IP y puerto
(origen y destino), protocolo de transporte y DSCP, este
clasificador se conoce como MF (Multi-Field Classifier).
Una vez que los paquetes han sido marcados
adecuadamente, los nodos internos deberán seleccionar el
PHB definido para cada flujo de datos.
Los nodos DS de entrada serán responsables de asegurar
que el tráfico de entrada cumple los requisitos de algún
TCA (Traffic Conditioning Agreement), que es un
derivado del SLA, entre los dominios interconectados.
Por otro lado los nodos DS de salida deberán realizar
funciones de acondicionamiento de tráfico o TC (Traffic
Conformation) sobre el tráfico transferido al otro dominio
DS conectado.
o Nodos internos DS: podrá realizar limitadas funciones de
TC, tales como remarcado de DSCP. Los nodos DS
internos solo se conectan a nodos internos o a nodos
externos de su propio dominio. A diferencia de los nodos
externos para la selección del PHB solo ser tendrá en
cuenta el campo DSCP, conocido como clasificador BA
(Behavior Aggregate Classifier).
III. PROTOCOLO DE GESTIÓN DE POLÍTICAS: COPS
Dentro de este escenario que define Diffserv necesitamos
algún modo de comunicación para distribuir las políticas de
calidad de servicio entre los elementos de red que las
necesiten. Existe un protocolo creado para tal efecto que nos
permitirá resolver este problema de comunicación.
El protocolo COPS (Common Open Policy Service)
especificado en [3], define un modelo sencillo de cliente-
servidor que proporciona control de políticas para protocolos
con señalización de calidad de servicio. El modelo descrito no
hace ninguna suposición acerca de los procedimientos
utilizados en el servidor de políticas, sino que se basa en un
servidor que devuelve decisiones a las peticiones realizadas
por los clientes. La definición del protocolo es bastante abierta
para que sea extensible y poder soportar los distintos tipos de
clientes que pudieran aparecer en el futuro.
El protocolo COPS se basa en sencillos mensajes de
petición y respuesta utilizados para intercambiar información
acerca de políticas de tráfico entre un servidor de políticas
(PDP, Policy Decision Point) y distintos tipos de clientes
(PEPs, Policy Enforcement Points). Un ejemplo de cliente
COPS podría ser un router RSVP o Diffserv que deba realizar
funciones de control de admisión en base a determinada
política. Por otro lado, el modelo supone que existe al menos
un servidor de políticas en cada dominio administrativo.
Uno de los objetivos principales del protocolo es
proporcionar un modelo sencillo pero fácilmente extensible.
Las características principales del protocolo COPS son las
siguientes:
o El protocolo emplea un modelo cliente/servidor en el que
el PEP envía peticiones y actualizaciones al PDP, y el
PDP responde con las decisiones tomadas.
o El protocolo utiliza TCP como protocolo de transporte
para asegurar así fiabilidad en el intercambio de mensajes
entre los clientes y el servidor.
o El protocolo es extensible en el sentido de que está
diseñado para permitir el uso de objetos auto-
identificativos y soporta distintos tipos de información
específica de clientes, sin tener que realizar ningún tipo de
modificación sobre el protocolo. COPS se creó para la
administración general, configuración y aplicación de
políticas en una red.
o COPS proporciona seguridad a nivel de mensaje mediante
autenticación, protección frente al reenvío (replay) e
integridad de mensaje. COPS permite además reutilizar
otros protocolos de seguridad existentes para proporcionar
autenticación y proteger el canal entre el PEP y el PDP.
Figura 2. El modelo COPS
La figura anterior muestra la disposición de diferentes
componentes en un ejemplo COPS típico. En este modelo, el
protocolo COPS se utiliza para comunicar la información
sobre las políticas de la red entre los puntos de aplicación de
políticas (PEPs) y un servidor de políticas remoto (PDP).
Dentro del nodo de red puede existir un PDP local que puede
ser utilizado para tomar decisiones locales en ausencia de un
PDP.
El PEP puede tener también la capacidad de tomar
decisiones de política localmente, a través de su LPDP (Local
Policy Decision Point), aunque el PDP sigue manteniendo la
autoridad en cuanto a las decisiones. Esto quiere decir que
cualquier decisión local relevante debe enviarse al PDP.
Asimismo, el PDP debe tener acceso a toda la información
para poder tomar una decisión final. Para ello, el PEP debe
enviar las decisiones locales al PDP a través de un objeto
LPDP Decision, y posteriormente atenerse a la decisión que
tome el PDP.
IV. IMPLEMENTACIÓN
A continuación se analizará el escenario desarrollado en el
Departamento de Telemática de la Universidad Carlos III de
Madrid indicado en [1]. A través de este trabajo se pretende
crear la red de acceso de un escenario Diffserv, es decir,
construir las funciones de marcado y clasificación en un router
frontera. Y de igual forma ofrecer una posible solución para la
comunicación de políticas de calidad de servicio a través del
protocolo COPS. Como aplicación de prueba se eligió la
comunicación de Voz sobre IP mediante el protocolo H.323.
En la implementación de este entorno de marcado Diffserv
hay cuatro elementos fundamentales a tener en cuenta. Los tres
primeros son los tres nodos principales que hay que
implementar para que el sistema de marcado funcione: el
bandwidth broker, el router frontera y el gatekeeper de voz
sobre IP. El bandwidth broker actuará como servidor de
políticas, centralizando la asignación de códigos de marcado a
los flujos que salen de la red. El router frontera será el
encargado de aplicar el marcado a los paquetes salientes. Y en
tercer lugar, el gatekeeper de voz realizará las peticiones al
bandwidth broker para que determinadas conexiones de voz
reciban calidad de servicio.
 El cuarto elemento a tener en cuenta es el protocolo de
comunicación entre los nodos del entorno Diffserv. Ya hemos
comentado que se utilizará el protocolo COPS, pero ha sido
necesario definir algunas estructuras de datos nuevas para
intercambiar información entre los equipos.
Por último, para poder utilizar con comodidad el protocolo
COPS se ha implementado una librería COPS que ofrece
funciones y estructuras de datos que facilitan el envío de
mensajes COPS tanto en el bandwidth broker como en los
clientes. De esta forma disminuye la complejidad de los
clientes y del propio servidor.
Escenario Diffserv
El entorno Diffserv que se ha implementado en el proyecto
es el que se muestra en la figura 3:
El bandwidth broker es el elemento que controla en cierto
modo la red Diffserv y que se encarga de centralizar la gestión
de políticas. La aplicación de estas políticas consistirá en la
asignación a cada flujo de datos del código Diffserv
correspondiente, y por tanto, del tratamiento que recibirá
dentro de la red del ISP. En nuestro caso, el código que se
asignará a cada flujo de datos va a depender principalmente
del tipo de tráfico del que se trate.
Esta aplicación de políticas podrá ser dinámica o estática,
dependiendo del tipo de aplicación que genere ese tráfico.
Para el caso de tráfico de voz IP, en el que tanto el origen
como el destino del flujo de datos pueden cambiar, la
asignación de códigos Diffserv será dinámica para cada
comunicación de voz. Por el contrario hemos decidido utilizar
la asignación estática para tráficos de datos que vayan
dirigidos a un puerto TCP fijo (como por ejemplo el tráfico
web al puerto TCP 80).

El bandwidth broker, actuando como servidor COPS,

responderá a las peticiones que realicen el gatekeeper y el
router de salida hacia el ISP. Naturalmente, el formato de las
peticiones dependerá del tipo de cliente.

Es importante destacar que la implementación del

bandwidth broker es abierta, y está preparada para trabajar con
distintos tipos de clientes COPS, y con diferentes tipos de
Figura 3. Entorno Diffserv implementado
tráfico. En la implementación de nuestro entorno hemos
utilizado un gatekeeper de voz, pero como veremos más
El escenario en el que se engloba el trabajo realizado es el
adelante, eso no implica que nuestro servidor de políticas sólo
de una red corporativa conectada a un proveedor de servicios
trabaje con tráfico de voz, sino que se pueden definir tantas
de Internet con capacidad Diffserv. El objetivo es implementar
políticas de tráfico como queramos.
un entorno Diffserv en el que el marcado se realice en el nodo
de salida de nuestra red hacia el proveedor de servicios. El
El funcionamiento del sistema es el siguiente. Cuando un
marcado se puede hacer dependiendo de varios parámetros
cliente de voz desea iniciar una llamada, se comunica con el
como por ejemplo la máquina origen o el puerto destino,
gatekeeper para obtener la dirección IP de la persona a la que
aunque lo más lógico es que el flujo de datos se marque
desea llamar (para que pueda producirse una llamada, los dos
dependiendo del tipo de tráfico al que pertenezca. Así
clientes de voz deben haberse registrado previamente en el
podremos controlar la aplicación de políticas dentro de nuestra
gatekeeper indicando un alias). Cuando la llamada va a
red decidiendo el marcado que se va a asignar a cada tipo de
establecerse, el gatekeeper avisa al bandwidth broker y le pasa
tráfico. De esta forma, el tráfico entrante al ISP ya va
toda la información relacionada con la llamada (direcciones
correctamente marcado y recibirá el tratamiento acordado en
origen y destino, puertos origen y destino, protocolo de
el contrato firmado con el proveedor.
transporte y tipo de tráfico “voz”). Esta comunicación se hace
a través del protocolo COPS.
Adicionalmente, el nodo de entrada al proveedor de
servicios debería realizar funciones de vigilancia y policía
sobre el tráfico entrante para comprobar que el tráfico
proveniente de nuestra red se ajusta a los acuerdos de servicio
firmados. En el caso de que el tráfico generado por nuestra red
exceda los límites acordados, los paquetes podrían ser
desechados, o retenidos en el nodo hasta que cumplan el perfil
contratado. El tratamiento que reciban estos paquetes
dependerá de la propia política del proveedor de servicios y de
los contratos firmados, pero tanto la vigilancia a realizar a la
entrada del ISP como el tratamiento de los paquetes fuera del
Figura 4. Comunicación entre cliente-GK y GK-BB
perfil contratado quedan fuera del ámbito de este artículo.
 Cuando reciba la petición, el bandwidth broker añadirá esa
conexión a una tabla interna con todas las conexiones activas
junto con el tipo de tráfico al que pertenecen. Por otro lado,
cuando el router frontera de nuestra red detecta un nuevo flujo
de datos hacia el ISP, consulta al bandwidth broker cómo tiene
que marcar esos paquetes que entran en la red Diffserv. El
router le indica al bandwidth broker las direcciones origen y
destino de ese flujo de datos detectado, además de los puertos
origen y destino y el protocolo de transporte (TCP o UDP).
Esto se hace a través de la conexión COPS establecida entre el
router y el bandwidth broker.
Figura 5. Detección de tráfico en RF y comunicación con BB
El bandwidth broker comprobará entonces si esa conexión
está instalada en la tabla, y si debe recibir un tratamiento
Diffserv. Si la conexión está instalada en esa tabla, el
bandwidth broker mira el tipo de tráfico al que pertenece.
Dependiendo de ese tipo de tráfico, a esa conexión se le
asignará un código Diffserv u otro. Una vez que el bandwidth
broker haya decidido el código de marcado Diffserv, se lo
envía al router frontera para que añada un filtro en el interfaz
de salida que marque los paquetes pertenecientes a ese flujo de
datos. La respuesta también es un mensaje COPS.
Figura 6. Respuesta del BB y marcado de tráfico en el RF
Por su parte, el router de salida, en un primer momento y
hasta que el bandwidth broker le conteste, marcará los
paquetes con el código Diffserv ‘por defecto’, de forma que
esos paquetes reciban un tratamiento “best-effort” en la red del
proveedor. De esta forma se evita tener que retener los
paquetes en el router lo que generaría muchos problemas. Los
filtros correctamente instalados, disponen de un tiempo de
vida. Cuando ese tiempo se agota, el router hace una nueva
petición para saber si ese flujo de datos debe seguir siendo
marcado con el mismo código, con otro código distinto o con
el código por defecto. De esta forma la asignación de calidad
de servicio a los flujos de datos puede actualizarse cada cierto
tiempo.
Sistema de marcado
El sistema de marcado de paquetes Diffserv se lleva a cabo
en el Edge Router según hemos comentado. En el escenario
desarrollado estas funciones las llevaba a cabo un ordenador
con sistema operativo Linux (basado en distribución RedHat
7.1), sobre el kernel 2.4.2.
Para facilitar el acceso al control de tráfico en Linux
utilizamos la herramienta TC (traffic controller) desarrollada
por Alexey Kutnetsov según [4]. Esta herramienta nos ofrece
la posibilidad de seleccionar nuestras políticas de marcado, si
bien, no ofrece un interfaz de programación (API) adecuado
para integrarlo en el escenario.
Para mejorar el acceso al control de tráfico desarrollamos
un API para TC, con las funciones básicas necesarias para la
gestión del marcado de paquetes en un entorno Diffserv. Las
funciones proporcionadas por este API permiten: creación de
disciplinas de cola, asociación entre clases de tráfico y
disciplinas, creación y eliminación de filtros para la
identificación de tráfico. Estas funciones presentan soporte
para IPv6.
V. MODELO DE NEGOCIO / LIMITACIONES
Tras haber comprobado como Diffserv puede
implementarse para alcanzar la tan deseada calidad de servicio
en comunicaciones dentro de Internet, debemos comentar la
existencia de ciertas limitaciones inherentes al modelo
Diffserv, las cuales impiden en cierta manera la
implementación a gran escala de este sistema. Directamente
relacionado con este tema se encuentra el estudio del modelo
de negocio que presenta Diffserv en la actualidad.
A continuación analizaremos los problemas de implantación
de Diffserv gracias a un estudio del modelo de negocio:
o Dentro del modelo Diffserv es necesario indicar que este
no asegura de manera determinista que los flujos de
tráfico consigan determinados parámetros QoS, como
pueda hacer ATM a través de circuitos. Diffserv permite
la creación de agregaciones de tráfico, lo que nos ofrece
“cierta probabilidad de QoS”, de manera que un
proveedor puede integrar las conexiones pertenecientes a
diferentes VPNs dentro de un mismo agregado, recibiendo
todas ellas las mismas prestaciones a nivel de red. De esta
manera el tratamiento que recibieran podría ser diferente
del que consiguen usuarios con acceso gratuito a Internet.
Sin embargo conseguir que el modelo Diffserv se ponga
en funcionamiento requerirá un gran trabajo de ingeniería
de red así como un dimensionamiento adecuado para
alcanzar determinados parámetros QoS como puede ser un
caudal o retardo asegurados.
o Resulta interesante estudiar la situación en que se
encuentra actualmente Internet, donde debemos atravesar
diferentes ISPs para alcanzar nuestro destino. En este caso
el valor del byte DS puede ser modificado en cualquier
equipo intermedio según las políticas de tráfico y
diferentes contratos SLA tengan entre estos ISPs. De esta
forma, una calidad extremo a extremo sólo será alcanzable
cuando todos los elementos involucrados en la cadena
(dominios Diffserv) actúen según las mismas políticas.
o Resulta especialmente curioso que en Diffserv el principal
beneficiario de la reserva de QoS será el destino, siendo el
origen el que debe pagar por conseguir ese trato
diferenciado de su tráfico. De esta forma surgen conflictos
por ejemplo en la descarga de audio-streaming, donde el
que pagaría sería el servidor en lugar del usuario receptor.
o Analizando el modelo Diffserv parece lógico que alcanzar
un destino más lejano resulte más caro que otro más
cercano donde se necesiten atravesar menos ISPs. En
consecuencia el coste de enviar un paquete será diferente
en función del camino que deba atravesar. Esto puede
suponer una complicación a la hora de ofrecer el servicio
y tarificarlo. Sin embargo, este mismo problema aparecía
en el nacimiento de Internet, donde también resultaba más
caro enviar un paquete cuantos más ISPs tuviese que
atravesar, y sin embargo, por el momento los proveedores
de acceso han decidido ofrecer una tarifa fija
independientemente del destino de los paquetes. Parece
lógico entonces pensar que de alguna manera nuestro
proveedor de acceso a Internet nos tarificará
adecuadamente teniendo en cuenta que los mensajes
deberán ser tratados adecuadamente en los diferentes ISPs
(con los costes que ello suponga).
o Por otro lado, el modelo Diffserv no permite lograr QoS
en la red de acceso. Cuando se habla de QoS extremo a
extremo en Diffserv típicamente se hace referencia a QoS
entre los routers extremos entre origen y destino. No
obstante, la solución no presenta muchas dificultades ya
que se supone que el usuario tiene mayor control sobre la
red de acceso, quedando un dimensionamiento adecuado
en manos del usuario final.
o Otra de las consecuencias del modelo Diffserv es que la
reserva de QoS es unidireccional. En muchos casos esto
no planteará ningún problema. Sin embargo consideremos
el establecimiento de una conexión TCP. Si la reserva es
unidireccional los paquetes ACK que viajen en sentido
contrario tendrán el tratamiento normal (best-effort) de
paquetes, lo que podría llevar a que la QoS final
conseguida se limitase a la de los paquetes ACK (que
limitan el manejo de la ventana de transmisión).
o Finalmente, el modelo Diffserv plantea ciertos problemas
a la hora de decidir quien es el encargado de marcar la
QoS en los paquetes. Si se desease que el usuario pudiese
elegir personalmente el tratamiento deseado, entonces
sería necesario modificar de alguna forma las aplicaciones
y/o la pila de protocolos. Considerando poco deseable
esta opción, ya que limitaría el acceso a esta tecnología,
otra posibilidad consiste en crear algún sistema de
comunicación con nuestro proveedor de acceso que nos
permita indicar nuestros gustos de QoS en función del
servicio.
A partir del estudio de estas limitaciones que presenta el
modelo Diffserv podemos distinguir algunas
aplicaciones/servicios como las más interesantes para este
modelo.
o En primer lugar los servicios basados en suscripción
cobran especial importancia. Debido al hecho de ser el
origen el encargado de realizar la reserva, servicios como
Pay Per View (Video On Demand), canales de radio,
canales de televisión, etc.. podrían aparecer en el modelo
de negocio de redes Diffserv.
En este caso el proveedor de contenidos recibiría cierto
ingreso por cada evento distribuido. Y sería el mismo el
encargado de seleccionar la calidad de servicio que
recibirían los usuarios.
o Siguiendo el mismo razonamiento, vemos que el principal
problema es poner de acuerdo a origen y destino para
alcanzar un acuerdo en la QoS deseada. Este problema
desaparecería en el caso de VPNs (redes virtuales
privadas) donde el origen y el destino pertenecen a la
misma organización, de manera que comparten los
mismos criterios sobre QoS.
De esta manera, el desarrollo de Diffserv podría presentar
un especial interés de cara a la creación de VPNs sobre
una red IP.
o Por otro lado, existen una serie de aplicaciones con
determinados requisitos de QoS donde el desarrollo e
implementación de alguna tecnología de QoS en la actual
Internet podría suponer su despegue. A continuación
podemos ver algunos ejemplos:
? Resulta de especial interés en las videoconferencias,
donde incluimos cualquier tipo de escenario VoIP (Voice
over IP). Este servicio podría representar una buena
fuente de ingresos en el modelo Diffserv. El desarrollo de
este tipo de comunicaciones no ha tenido éxito hasta la
fecha por la falta de algún tipo de provisión de QoS, pero
la llegada de Diffserv podría suponer el despegue
definitivo de estos servicios.
? Otro caso interesante podrían ser los juegos online. Suele
tratarse de aplicaciones que no requieren un gran ancho de
banda, pero si importantes requisitos de retardo. La
existencia de una gran plataforma de videojuegos está
supeditada a la provisión de QoS.

VI. CONCLUSIONES
El desarrollo de la tecnología Diffserv se encuentra en una
fase lo suficientemente madura como para plantearnos su
posible implantación a gran escala. La funcionalidad que nos
aporta este modelo puede permitir el despegue definitivo de
determinados servicios con ciertos requisitos de calidad de
servicio.
A través de este artículo hemos presentado un escenario
desarrollado en el Departamento de Telemática de la
Universidad Carlos III de Madrid, en el que se ofrecen los
mecanismos básicos para adoptar diferentes políticas de
calidad de servicio en función de las necesidades de la red. Se
demuestra la viabilidad de la utilización de un elemento
servidor de políticas como el Bandwidth Broker, así como la
posibilidad de comunicar los diferentes elementos del
escenario mediante un protocolo diseñado para el intercambio
de políticas (COPS).
De igual forma se han planteado las limitaciones asociadas
al modelo Diffserv y se han identificado servicios que
aprovecharán los beneficios de esta tecnología.

AGRADECIMIENTOS
Este trabajo ha sido financiado parcialmente por la
comisión Europea a través del proyecto "Mobydick - Mobility
and Differenciated Services in a Future IP Network".

REFERENCIAS

[1] Jorge Escribano Salazar. “Diseño e implementación de un entorno

Diffserv”, Proyecto fin de carrera, Diciembre 2001.
[2] K. Nichols, S. Blake, F. Baker, D. Black. “Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”,
RFC 2474, December 1998.
[3] Durham D, Boyle J, Cohen R, Herzog S, Rajan R, Sastry A. “The COPS
(Common Open Policy Service) Protocol”, RFC 2748, January 2000.
[4] Differenciated Services in Linux - http://Diffserv.sourceforge.net/
[5] IETF Diffserv Working Group -
http://www.ietf.org/html.charters/diffserv-charter.html
[6] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. “Assured Forwarding
PHB Group”, RFC 2597, June 1999.
[7] V. Jacobson, K. Nichols, K. Poduri. “An expedited forwarding PHB”,
RFC 2598, June 1999
[8] IETF Intserv Working Group -
http://www.ietf.org/html.charters/intserv-charter.html