Diffserv como solucin a la provisin de QoS en Internet

Jorge Escribano Salazar, Carlos Garca Garca, Celia Seldas Alarcn, Jos Ignacio Moreno Novella Departamento de Ingeniera Telemtica Universidad Carlos III de Madrid Avenida de la Universidad, 30 28911 Legans (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 trfico. 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 navegacin web de caractersticas 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. INTRODUCCIN II. CALIDAD DE SERVICIO En la actualidad los sistemas informticos se basan en una red de datos, la cual debe ser capaz de soportar una cada vez ms amplia gama de aplicaciones. El protocolo de Internet (IP), que ha sido utilizado en estas redes durante las tres ltimas dcadas para el intercambio de informacin entre los diferentes ordenadores, ha terminado imponindose como el protocolo ms usado. Actualmente el desarrollo de estas redes de datos se est enfocando hacia la provisin de Calidad de Servicio (QoS), la cual se requiere para permitir asegurar determinadas caractersticas de calidad en la transmisin de informacin. El objetivo es evitar que la congestin 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 conmutacin as como el ancho de banda disponible en los canales. Este mtodo se basa en el abaratamiento de los sistemas de conmutacin y transporte, si bien provoca una gestin ineficiente por definicin de los recursos disponibles. Gestionar de forma inteligente los recursos disponibles, compartindolo de manera desigual entre los diferentes La calidad de servicio consiste en la capacidad de la red para reservar algunos de los recursos disponibles para un trfico concreto con la intencin de proporcionar un determinado servicio. Debemos tener en cuenta que en la red se pueden utilizar diferentes tecnologas de transporte (como pueden ser Frame Relay, X.25, SDH, ATM, etc) de manera que la gestin de QoS implica la interaccin con estas tecnologas y con los equipos de conmutacin, que son los que finalmente determinarn el nivel de QoS alcanzado. En este momento existen principalmente dos tipos de tecnologas que proporcionan calidad de servicio. La primera se basa en la reserva, y asigna recursos basndose en flujos de trfico. Alternativamente, un segundo tipo de calidad de servicio se caracteriza por la priorizacin de determinado tipo de trfico. Veremos ms adelante que los flujos de datos individuales se van agrupando en grandes agregados de trfico de acuerdo a la clase de servicio a la que pertenezcan, y dependiendo de esa clase de servicio recibirn 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 utilizacin de algn

protocolo de reserva (RSVP, ReSerVation Protocol) que permite la reserva de recursos a lo largo de los routers implicados en la comunicacin. El principal problema de este modelo es la necesidad de mantener informacin 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]. Modelo Diffserv: se basa en la divisin del trfico en diferentes clases [6],[7] y en la asignacin de prioridades a estos agregados. Utiliza diferente informacin 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 trfico en los nodos de la red Diffserv.

Figura 1. Arquitectura Diffserv Debemos tener en cuenta que un dominio Diffserv puede estar formado por ms 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 continuacin las diferentes funciones que deben realizar los nodos DS: o Nodos extremos DS: ser necesario realizar diferentes funciones como el acondicionamiento de trfico entre los dominios Diffserv interconectados. De esta manera debe clasificar y establecer las condiciones de ingreso de los flujos de trfico en funcin de: direccin 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 debern seleccionar el PHB definido para cada flujo de datos. Los nodos DS de entrada sern responsables de asegurar que el trfico de entrada cumple los requisitos de algn TCA (Traffic Conditioning Agreement), que es un derivado del SLA, entre los dominios interconectados. Por otro lado los nodos DS de salida debern realizar funciones de acondicionamiento de trfico o TC (Traffic Conformation) sobre el trfico 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 seleccin del PHB solo ser tendr en cuenta el campo DSCP, conocido como clasificador BA (Behavior Aggregate Classifier).

Calidad de servicio: Diffserv Los servicios diferenciados (Diffserv) proporcionan mecanismos de calidad de servicio para reducir la carga en dispositivos de la red a travs de un mapeo entre flujos de trfico y niveles de servicio. Los paquetes que pertenecen a una determinada clase se marcan con un cdigo especfico (DSCP Diffserv CodePoint). Este cdigo es todo lo que necesitamos para identificar una clase de trfico. La diferenciacin de servicios se logra mediante la definicin de comportamientos especficos para cada clase de trfico entre dispositivos de interconexin, hecho conocido como PHB (Per Hop Behavior). De esta manera a travs de Diffserv planteamos asignar prioridades a los diferentes paquetes que son enviados a la red. Los nodos intermedios (routers) tendrn que analizar estos paquetes y tratarlos segn sus necesidades. Esta es la razn principal por la que Diffserv ofrece mejores caractersticas 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 especificarn 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 polticas y grupos de comportamiento por salto (PHB - Per Hop Behavior) que determinarn el tratamiento de los paquetes en la red.

III. PROTOCOLO DE GESTIN DE POLTICAS: COPS Dentro de este escenario que define Diffserv necesitamos algn modo de comunicacin para distribuir las polticas 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 comunicacin. El protocolo COPS (Common Open Policy Service) especificado en [3], define un modelo sencillo de clienteservidor que proporciona control de polticas para protocolos con sealizacin de calidad de servicio. El modelo descrito no hace ninguna suposicin acerca de los procedimientos utilizados en el servidor de polticas, sino que se basa en un servidor que devuelve decisiones a las peticiones realizadas por los clientes. La definicin 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 peticin y respuesta utilizados para intercambiar informacin acerca de polticas de trfico entre un servidor de polticas (PDP, Policy Decision Point) y distintos tipos de clientes (PEPs, Policy Enforcement Points). Un ejemplo de cliente COPS podra ser un router RSVP o Diffserv que deba realizar funciones de control de admisin en base a determinada poltica. Por otro lado, el modelo supone que existe al menos un servidor de polticas en cada dominio administrativo. Uno de los objetivos principales del protocolo es proporcionar un modelo sencillo pero fcilmente extensible. Las caractersticas principales del protocolo COPS son las siguientes: o El protocolo emplea un modelo cliente/servidor en el que el PEP enva peticiones y actualizaciones al PDP, y el PDP responde con las decisiones tomadas. El protocolo utiliza TCP como protocolo de transporte para asegurar as fiabilidad en el intercambio de mensajes entre los clientes y el servidor. El protocolo es extensible en el sentido de que est diseado para permitir el uso de objetos autoidentificativos y soporta distintos tipos de informacin especfica de clientes, sin tener que realizar ningn tipo de modificacin sobre el protocolo. COPS se cre para la administracin general, configuracin y aplicacin de polticas en una red. COPS proporciona seguridad a nivel de mensaje mediante autenticacin, proteccin frente al reenvo (replay) e integridad de mensaje. COPS permite adems reutilizar otros protocolos de seguridad existentes para proporcionar autenticacin y proteger el canal entre el PEP y el PDP.

Figura 2. El modelo COPS La figura anterior muestra la disposicin de diferentes componentes en un ejemplo COPS tpico. En este modelo, el protocolo COPS se utiliza para comunicar la informacin sobre las polticas de la red entre los puntos de aplicacin de polticas (PEPs) y un servidor de polticas 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 tambin la capacidad de tomar decisiones de poltica localmente, a travs de su LPDP (Local Policy Decision Point), aunque el PDP sigue manteniendo la autoridad en cuanto a las decisiones. Esto quiere decir que cualquier decisin local relevante debe enviarse al PDP. Asimismo, el PDP debe tener acceso a toda la informacin para poder tomar una decisin final. Para ello, el PEP debe enviar las decisiones locales al PDP a travs de un objeto LPDP Decision, y posteriormente atenerse a la decisin que tome el PDP. IV. IMPLEMENTACIN A continuacin se analizar el escenario desarrollado en el Departamento de Telemtica de la Universidad Carlos III de Madrid indicado en [1]. A travs de este trabajo se pretende crear la red de acceso de un escenario Diffserv, es decir, construir las funciones de marcado y clasificacin en un router frontera. Y de igual forma ofrecer una posible solucin para la comunicacin de polticas de calidad de servicio a travs del protocolo COPS. Como aplicacin de prueba se eligi la comunicacin de Voz sobre IP mediante el protocolo H.323. En la implementacin 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 polticas, centralizando la asignacin de cdigos 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 comunicacin 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 informacin entre los equipos. Por ltimo, para poder utilizar con comodidad el protocolo COPS se ha implementado una librera COPS que ofrece funciones y estructuras de datos que facilitan el envo 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 gestin de polticas. La aplicacin de estas polticas consistir en la asignacin a cada flujo de datos del cdigo Diffserv correspondiente, y por tanto, del tratamiento que recibir dentro de la red del ISP. En nuestro caso, el cdigo que se asignar a cada flujo de datos va a depender principalmente del tipo de trfico del que se trate. Esta aplicacin de polticas podr ser dinmica o esttica, dependiendo del tipo de aplicacin que genere ese trfico. Para el caso de trfico de voz IP, en el que tanto el origen como el destino del flujo de datos pueden cambiar, la asignacin de cdigos Diffserv ser dinmica para cada comunicacin de voz. Por el contrario hemos decidido utilizar la asignacin esttica para trficos de datos que vayan dirigidos a un puerto TCP fijo (como por ejemplo el trfico 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 implementacin del bandwidth broker es abierta, y est preparada para trabajar con distintos tipos de clientes COPS, y con diferentes tipos de trfico. En la implementacin de nuestro entorno hemos utilizado un gatekeeper de voz, pero como veremos ms adelante, eso no implica que nuestro servidor de polticas slo trabaje con trfico de voz, sino que se pueden definir tantas polticas de trfico como queramos. El funcionamiento del sistema es el siguiente. Cuando un cliente de voz desea iniciar una llamada, se comunica con el gatekeeper para obtener la direccin IP de la persona a la que desea llamar (para que pueda producirse una llamada, los dos clientes de voz deben haberse registrado previamente en el gatekeeper indicando un alias). Cuando la llamada va a establecerse, el gatekeeper avisa al bandwidth broker y le pasa toda la informacin relacionada con la llamada (direcciones origen y destino, puertos origen y destino, protocolo de transporte y tipo de trfico voz). Esta comunicacin se hace a travs del protocolo COPS.

Figura 3. Entorno Diffserv implementado El escenario en el que se engloba el trabajo realizado es el de una red corporativa conectada a un proveedor de servicios de Internet con capacidad Diffserv. El objetivo es implementar un entorno Diffserv en el que el marcado se realice en el nodo de salida de nuestra red hacia el proveedor de servicios. El marcado se puede hacer dependiendo de varios parmetros como por ejemplo la mquina origen o el puerto destino, aunque lo ms lgico es que el flujo de datos se marque dependiendo del tipo de trfico al que pertenezca. As podremos controlar la aplicacin de polticas dentro de nuestra red decidiendo el marcado que se va a asignar a cada tipo de trfico. De esta forma, el trfico entrante al ISP ya va correctamente marcado y recibir el tratamiento acordado en el contrato firmado con el proveedor. Adicionalmente, el nodo de entrada al proveedor de servicios debera realizar funciones de vigilancia y polica sobre el trfico entrante para comprobar que el trfico proveniente de nuestra red se ajusta a los acuerdos de servicio firmados. En el caso de que el trfico generado por nuestra red exceda los lmites acordados, los paquetes podran ser desechados, o retenidos en el nodo hasta que cumplan el perfil contratado. El tratamiento que reciban estos paquetes depender de la propia poltica 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 perfil contratado quedan fuera del mbito de este artculo.

Figura 4. Comunicacin entre cliente-GK y GK-BB

Cuando reciba la peticin, el bandwidth broker aadir esa conexin a una tabla interna con todas las conexiones activas junto con el tipo de trfico 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 cmo 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, adems de los puertos origen y destino y el protocolo de transporte (TCP o UDP). Esto se hace a travs de la conexin COPS establecida entre el router y el bandwidth broker.

Sistema de marcado El sistema de marcado de paquetes Diffserv se lleva a cabo en el Edge Router segn hemos comentado. En el escenario desarrollado estas funciones las llevaba a cabo un ordenador con sistema operativo Linux (basado en distribucin RedHat 7.1), sobre el kernel 2.4.2. Para facilitar el acceso al control de trfico en Linux utilizamos la herramienta TC (traffic controller) desarrollada por Alexey Kutnetsov segn [4]. Esta herramienta nos ofrece la posibilidad de seleccionar nuestras polticas de marcado, si bien, no ofrece un interfaz de programacin (API) adecuado para integrarlo en el escenario. Para mejorar el acceso al control de trfico desarrollamos un API para TC, con las funciones bsicas necesarias para la gestin del marcado de paquetes en un entorno Diffserv. Las funciones proporcionadas por este API permiten: creacin de disciplinas de cola, asociacin entre clases de trfico y disciplinas, creacin y eliminacin de filtros para la identificacin de trfico. Estas funciones presentan soporte para IPv6.

Figura 5. Deteccin de trfico en RF y comunicacin con BB El bandwidth broker comprobar entonces si esa conexin est instalada en la tabla, y si debe recibir un tratamiento Diffserv. Si la conexin est instalada en esa tabla, el bandwidth broker mira el tipo de trfico al que pertenece. Dependiendo de ese tipo de trfico, a esa conexin se le asignar un cdigo Diffserv u otro. Una vez que el bandwidth broker haya decidido el cdigo de marcado Diffserv, se lo enva al router frontera para que aada un filtro en el interfaz de salida que marque los paquetes pertenecientes a ese flujo de datos. La respuesta tambin es un mensaje COPS.

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 implementacin 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 continuacin analizaremos los problemas de implantacin 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 trfico consigan determinados parmetros QoS, como pueda hacer ATM a travs de circuitos. Diffserv permite la creacin de agregaciones de trfico, 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 podra 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 ingeniera de red as como un dimensionamiento adecuado para alcanzar determinados parmetros QoS como puede ser un caudal o retardo asegurados.

Figura 6. Respuesta del BB y marcado de trfico 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 cdigo 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 generara muchos problemas. Los filtros correctamente instalados, disponen de un tiempo de vida. Cuando ese tiempo se agota, el router hace una nueva peticin para saber si ese flujo de datos debe seguir siendo marcado con el mismo cdigo, con otro cdigo distinto o con el cdigo por defecto. De esta forma la asignacin de calidad de servicio a los flujos de datos puede actualizarse cada cierto tiempo.

Resulta interesante estudiar la situacin 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 segn las polticas de trfico y diferentes contratos SLA tengan entre estos ISPs. De esta forma, una calidad extremo a extremo slo ser alcanzable cuando todos los elementos involucrados en la cadena (dominios Diffserv) acten segn las mismas polticas. 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 trfico. De esta forma surgen conflictos por ejemplo en la descarga de audio-streaming, donde el que pagara sera el servidor en lugar del usuario receptor. Analizando el modelo Diffserv parece lgico que alcanzar un destino ms lejano resulte ms caro que otro ms cercano donde se necesiten atravesar menos ISPs. En consecuencia el coste de enviar un paquete ser diferente en funcin del camino que deba atravesar. Esto puede suponer una complicacin a la hora de ofrecer el servicio y tarificarlo. Sin embargo, este mismo problema apareca en el nacimiento de Internet, donde tambin resultaba ms caro enviar un paquete cuantos ms 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 lgico entonces pensar que de alguna manera nuestro proveedor de acceso a Internet nos tarificar adecuadamente teniendo en cuenta que los mensajes debern ser tratados adecuadamente en los diferentes ISPs (con los costes que ello suponga). 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 tpicamente se hace referencia a QoS entre los routers extremos entre origen y destino. No obstante, la solucin 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. Otra de las consecuencias del modelo Diffserv es que la reserva de QoS es unidireccional. En muchos casos esto no plantear ningn problema. Sin embargo consideremos el establecimiento de una conexin TCP. Si la reserva es unidireccional los paquetes ACK que viajen en sentido contrario tendrn el tratamiento normal (best-effort) de paquetes, lo que podra llevar a que la QoS final conseguida se limitase a la de los paquetes ACK (que limitan el manejo de la ventana de transmisin). 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 sera necesario modificar de alguna forma las aplicaciones y/o la pila de protocolos. Considerando poco deseable esta opcin, ya que limitara el acceso a esta tecnologa, otra posibilidad consiste en crear algn sistema de comunicacin con nuestro proveedor de acceso que nos permita indicar nuestros gustos de QoS en funcin del servicio. A partir del estudio de estas limitaciones que presenta el modelo Diffserv podemos distinguir algunas aplicaciones/servicios como las ms interesantes para este modelo. o En primer lugar los servicios basados en suscripcin 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 televisin, etc.. podran aparecer en el modelo de negocio de redes Diffserv. En este caso el proveedor de contenidos recibira cierto ingreso por cada evento distribuido. Y sera el mismo el encargado de seleccionar la calidad de servicio que recibiran 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 desaparecera en el caso de VPNs (redes virtuales privadas) donde el origen y el destino pertenecen a la misma organizacin, de manera que comparten los mismos criterios sobre QoS. De esta manera, el desarrollo de Diffserv podra presentar un especial inters de cara a la creacin de VPNs sobre una red IP. o Por otro lado, existen una serie de aplicaciones con determinados requisitos de QoS donde el desarrollo e implementacin de alguna tecnologa de QoS en la actual Internet podra suponer su despegue. A continuacin podemos ver algunos ejemplos: Resulta de especial inters en las videoconferencias, donde incluimos cualquier tipo de escenario VoIP (Voice over IP). Este servicio podra 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 algn tipo de provisin de QoS, pero la llegada de Diffserv podra suponer el despegue definitivo de estos servicios.

Otro caso interesante podran 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 provisin de QoS.

VI. CONCLUSIONES El desarrollo de la tecnologa Diffserv se encuentra en una fase lo suficientemente madura como para plantearnos su posible implantacin 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 travs de este artculo hemos presentado un escenario desarrollado en el Departamento de Telemtica de la Universidad Carlos III de Madrid, en el que se ofrecen los mecanismos bsicos para adoptar diferentes polticas de calidad de servicio en funcin de las necesidades de la red. Se demuestra la viabilidad de la utilizacin de un elemento servidor de polticas como el Bandwidth Broker, as como la posibilidad de comunicar los diferentes elementos del escenario mediante un protocolo diseado para el intercambio de polticas (COPS). De igual forma se han planteado las limitaciones asociadas al modelo Diffserv y se han identificado servicios que aprovecharn los beneficios de esta tecnologa.

AGRADECIMIENTOS Este trabajo ha sido financiado parcialmente por la comisin Europea a travs del proyecto "Mobydick - Mobility and Differenciated Services in a Future IP Network".

REFERENCIAS
[1] [2] Jorge Escribano Salazar. Diseo e implementacin de un entorno Diffserv, Proyecto fin de carrera, Diciembre 2001. 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. Durham D, Boyle J, Cohen R, Herzog S, Rajan R, Sastry A. The COPS (Common Open Policy Service) Protocol, RFC 2748, January 2000. Differenciated Services in Linux - http://Diffserv.sourceforge.net/ IETF Diffserv Working Group http://www.ietf.org/html.charters/diffserv-charter.html J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. Assured Forwarding PHB Group, RFC 2597, June 1999. V. Jacobson, K. Nichols, K. Poduri. An expedited forwarding PHB, RFC 2598, June 1999 IETF Intserv Working Group http://www.ietf.org/html.charters/intserv-charter.html

[3] [4] [5] [6] [7] [8]