Realizado por Hctor Cabrejas Fernndez y Manuel Gonzlez Tejerina.

Grupo 14J

INTRODUCCIN

En la actualidad los sistemas informticos se basan en una red de datos, a su vez basada mayoritariamente en el Protocolo de Internet (IP), la cual debe ser capaz de soportar una cada ms amplia gama de aplicaciones. 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 transmision de informacin. El objetivo es simple. Evitar que la congestin en determinados nodos de la red afecte a algunas aplicaciones que requieran un determinado ancho de banda (Video Conferencia, VoIP,...) , o un mnimo retardo, sin la necesidad de ocupar excesivo ancho de banda (Juegos OnLine). El trfico producido por dichas aplicaciones ha aumentado exponencialmente en los ltimos aos, tal y como podemos apreciar en esta grfica, gracias al constante desarrollo y mejora de las redes de datos.

Trfico Global VoIP por regiones (1997 2005)

Para evitar dicha congestin, existen dos tendencias bien distintas. Una implica sobredimensionar adecuadamente la red de transporte. Este mtodo se basa en el abaratamiento de los sistemas de conmutacin y transporte, si bien provoca una gestin ineficiente por definicion de los recursos disponibles. La otra tendencia es la que nosotros vamos a investigar. Se trata de gestionar de forma inteligente los recursos disponibles, compartindolos de manera desigual entre los diferentes flujos de trfico. Sin embargo, hoy en da, dichas redes de datos no saben distinguir ente las diferentes aplicaciones que transportan, por lo que necesitaremos que, de alguna manera, las funciones de Calidad de Servicio (QoS) nos permitan catalogar las diferentes aplicaciones para reservarles unos determinados recursos de red. En el mbito actual de las redes de datos, se pueden discernir dos tipos de tecnologas que proporcionan una determinada Calidad de Servicio (QoS): MODELO INTSERV Basado en la utilizacin de algn protocolo de reserva (RSVP, ReSerVation Protocol), nos permite realizar una reserva de recursos en todos los routers implicados en la comunicacin. El principal inconveniente que se nos presenta ante esta tecnologa, radica en la necesidad de mantener informacin sobre cada flujo en todos los routers de la red, lo cual conduce a problemas de escabilidad.

Modelo IntServ

MODELO DIFFSERV Este modelo, a diferencia del anterior, se basa en la divisin del trfico en diferentes clases, y en la asignacin de prioridades a estos agregados.

Divisin de trfico en diferentes clases, con diferentes prioridades

Para ello, se cuenta con una diferente cabecera en los paquetes. Se trata de la cabecera DSCP (DiffServ Code Point), til para distinguir, clasificar los paquetes y conocer el tratamiento que debe recibir el tratamiento en los nodos de la red DiffServ. Esta cabecera es compatible tanto con IPv4, como IPv6.

ANALISIS DE SISTEMAS

Los servicios diferenciados (DiffServ), como ya hemos comentado, nos 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. Todos los paquetes que pertenecen a una determinada clase se marcan con un cdigo especfico DSCP. La diferenciacin de servicios se consigue mediante la definicin de comportamientos especficos para cada clase de trfico entre dispositivos de interconexin, hecho conocido como PHB (Per Hop Behavoir).

En la arquitectura definida por Diffserv, que podemos ver en la figura, aparecen nodos externos 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 de salto (PHB Per Hop Behavior) que determinarn el tratamiento de los paquetes en la red.

Arquitectura DiffServ

Vamos a analizar las caractersticas necesarias de los diferentes nodos. Ms adelante, presentaremos el tipo de polticas que se suele utilizar en la implementacin de estos sistemas.

NODOS EXTERNOS DS (Ingress / Egress Nodes): Se hace imprescindible realizar diferentes funciones como el acondicionamiento de trfico entre los dominios DiffServ interconectados. Para ello, se deben clasificar y establecer las condiciones de ingreso de los flujos de trfico, denominado TCB (Traffic Conditioner Block) en funcin de un clasificador conocido como MF (Multi-Field Classifeier), que consta de: Direccin IP Puerto (Origen y Destino) Protocolo de transporte DSCP

Adems, los nodos DS de entrada (Ingress DS Nodes) sern los responsables de asegurar que el trfico de entrada cumple los requisitos de algn TCA (Traffic Conditioning Agreement), derivado de SLA (Service Level Agreement), entre los dominios interconectados. De forma anloga, los nodos DS de salida (Egress DS Nodes) debern realizar las funciones de acondicionamiento de trfico o TC (Traffic Conformation) sobre el trfico transferido al otro dominio DS conectado.

NODOS INTERNOS DS Podr realizar limitadas funciones de TC (Traffic Conformation), tales como remarcado de DSCP. Los nodos DS internos solo se conectan a otros nodos internes, o a nodos externos de su propio dominio. A diferencia de los nodos externos, para la seleccin del PHB (Per Hop Behavoir) solo se tendr en cuenta el campo DSCP, conocido como clasificador BA (Behavoir Aggregate Classifier).

PROTOCOLO DE GESTIN DE POLTICAS: COPS Dentro de este escenario que define DiffServ, necesitamos un protocolo o modo de comunicacin que nos garantice la distribucin de las polticas de calidad de servicio entre los elementos de red que as lo necesiten. Adems, se hace indispensable el uso de un modelo extensible y sencillo. Dicho protocolo, denominado COPS (Common Open Policy Service), nos realizar esta tarea, y cumplir dichas expectativas. 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. 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).

Mensaje COPS

El modelo COPS

Las caractersticas principales del protocolo COPS son las siguientes:

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. COPS proporciona seguridad a nivel de mensaje mediante autenticacin, proteccin frente al reenvo (replay) e integridad del mensaje. Permite adems reutilizar otros protocolos de seguridad existentes para proporcionar autenticacin y proteger el canal entre el PEP y el PDP. Dentro del nodo de red puede existir un LPDP (Local PDP) que puede ser utilizado para tomar decisiones locales en ausencia de un PDP, aunque el PDP sigue manteniendo la autoridad en cuanto a las decisiones.

IMPLEMENTACIN En la implementacin de un entorno de marcado DiffServ tpico, como puede ser una comunicacin de Voz sobre IP, 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 (PDP), centralizando la asignacin de cdigos de marcado a los flujos que salen de la red. El Router Frontera (Egress DS Node) ser el encargado de aplicar el marcado a los paquetes salientes. Por ltimo, el Gatekeeper de Voz sobre IP (PEP) ralizar las peticiones al Bandwidth Broker (PDP) para que determinadas conexiones de voz reciban Calidad de Servicio (QoS).

El cuarto elemento necesario para la implementacin de dicho entorno es el protocolo de comunicacin entre los nodos DS, COPS. 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 pueden cambiar, la asignacin de cdigos DiffServ ser dinmica para cada comunicacin de voz. Por el contrario, es lgico utilizar una asignacin esttica para trficos de datos que vayan dirigidos a un puerto TCP fijo.

Entorno DiffServ

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. Cuando la llamada va a establecerse, el Gatekeeper avisa al Bandwidth Broker y le pasa toda la informacin relacionada con la llamada. Una vez reciba la peticin, ste 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 detecte un nuevo flujo de datos hacia el ISP (Internet Service Provider), consulta al Bandwidth Broker como marcar esos paquetes que entran en la red. Se comprobar entonces si esa conexin est instalada en la tabla, y si debe recibir un tratamiento DiffServ. Dependiendo de ese tipo de trfico, a esa conexin se le asignar un cdigo DSCP u otro, y se le enviar al Router Frontera para que marque los paquetes relativos a ese flujo de datos. Por su parte, el Router Frontera, en un primer momento y hasta que el Bandwidth Broker le conteste, marcar los paquetes con el cdigo por defecto, de forma que esos paquetes reciban un tratamiento best effort en la red del proveedor. De esta forma no se retienen los paquetes en el router y se evitan problemas. Los filtros correctamente instalados, disponen de un tiempo de vida. Cuando ese tiempo se agota, el Router Frontera hace una nueva peticin para saber si es 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.

VISIN DE NEGOCIO

Una vez aclarado como DiffServ puede implementarse para alcanzar la tan deseada calidad de servicio en comunicaciones dentro de Internet, debemos comentar la existencia de ciertas limitaciones que presenta el modelo DiffServ, las cuales impiden en cierta manera la implementacin de este sistema de forma genrica, reduciendo la penetracin en el mercado. Como se ha explicado anteriormente, el modelo DiffServ divide el trfico en diferentes clases formando agregados y asigna diferentes prioridades a dichos agregados, los cuales recibirn el tratamiento correspondiente en los nodos de la red. El punto ms atractivo de este mtodo es la gran escalabilidad que se obtiene en la red, en cambio por este mismo motivo no podemos asegurar que de manera determinista que los flujos de trfico consigan determinados parmetros QoS, como pueda hacer ATM a travs de circuitos. DiffServ solo puede proporcionar cierta probabilidad de Calidad de Servicio (QoS) para cada grupo de agregados. En la actualidad el trfico de paquetes por Internet viene caracterizado en que para llegar al destino deseado tiene que atravesar diferentes ISPs para alcanzarlo. El problema que esto sugiere para el modelo DiffServ es que cada ISP intermedio tenga una poltica de trfico y contrato SLA diferente al nuestro. Como consecuencia de esto, los paquetes al pasar por dichos ISPs, sern tratados segn sus respectivas polticas, pudiendo variar el valor del byte DS en donde se especificarn las prioridades de los paquetes para cada caso. 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. Cabe destacar que 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.

Viendo las dificultades que se presenta para encauzar el trafico, en 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. Siempre hablamos de la QoS extremo a extremo en DiffServ tpicamente se hace referencia a QoS entre los routers extremos entre origen y destino (que es donde se hace la diferenciacin de paquetes). 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. Como hemos planteado anteriormente el mayor beneficiario del modelo DiffServ es el destino, ya que la reserva de QoS es unidireccional. En muchos casos esto no plantear ningn problema, pero en los casos en que se establezca una comunicacin bidireccional podran aparecer problemas. Por ejemplo consideremos el establecimiento de una conexin TCP. Si la reserva es unidireccional los paquetes ACK que viajen en sentido contrario tendrn el tratamiento normal 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, en el modelo DiffServ se plantean varias posibilidades a la hora de decidir quien es el encargando de de marcar la QoS en los paquetes. En un primer momento parecera que esa decisin la tendra que tener el usuario, siendo l el que eligiera el tratamiento deseado, marcando la QoS en los paquetes. Si esto fuera as, 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. Sin embargo, an teniendo las limitaciones que acabamos de ver, puede ser muy til para ciertas aplicaciones/servicios descritas a continuacin. Hemos caracterizado que en el modelo DiffServ el mayor beneficiario es el destino. Esto puede ser muy productivo en servicios basados en suscripciones, donde el usuario fija las caractersticas de la transmisin que va a recibir. En 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 estos casos 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, dicha seleccin depender de lo solicitado por los usuarios. 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 (Virtual Private Networks) donde el origen y el destino pertenecen a la misma organizacin, de manera que comparten los mismos criterios sobre QoS, los ISPs intermedios no cambiarn las prioridades de los paquetes al compartir la misma poltica. De esta manera, el desarrollo de DiffServ podra presentar un especial inters de cara a la creacin de VPNs sobre una red IP. 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), un sistema de enrutamiento de conversaciones de voz mediante paquetes basados en IP por la red de internet.

Escenario VoIP

Las ventajas de este sistema es que el servicio de telefona va VoIP es gratuito o cuesta muchsimo menos que el servicio equivalente tradicional y similar a la alternativa que los proveedores del servicio de la Red Pblica Telefnica Conmutada (PSTN) ofrecen. Algunos ahorros en el costo son debidos a utilizar una misma red para llevar voz y datos, especialmente cuando los usuarios tienen sin utilizar toda la capacidad de una red ya existente la cual pueden usar para VoIP sin un costo adicional. Las llamadas de VoIP a VoIP entre cualquier proveedor son generalmente gratis, en contraste con las llamadas de VoIP a PSTN que generalmente cuestan al usuario de VoIP.

El principal problema que presenta hoy en da la penetracion de VoIP es garantizar la calidad de servicio sobre una red IP, en base a retardos y ancho de banda, actualmente no es posible, es por eso que se presentan diversos problemas en cuanto a garantizar la calidad del servicio. La voz ha de codificarse para poder ser transmitida por la red IP. Para ello se hace uso de Cdecs que garanticen la codificacin y compresin del audio y/o del video para su posterior decodificacin y descompresin antes de poder generar un sonido o imagen utilizable. Segn el Cdec utilizado en la transmisin, se utilizar ms o menos ancho de banda. La cantidad de ancho de banda suele ser directamente proporcional a la calidad de los datos transmitidos. Una vez establecidos los retardos de procesado, retardos de trnsito y el retardo de procesado la conversacin se considera aceptable por debajo de los 150 ms.

La calidad de servicio se est logrando en base a los siguientes criterios: La supresin de silencios, otorga ms eficiencia a la hora de realizar una transmisin de voz, ya que se aprovecha mejor el ancho de banda al transmitir menos informacin Compresin de cabeceras aplicando los estndares RTP/RTCP. Priorizacin de los paquetes que requieran menor latencia. Las tendencias actuales son: CQ (Custom Queuing) .Asigna un porcentaje del ancho de banda disponible.PQ (Priority Queuing). Establece prioridad en las colas.WFQ (Weight Fair Queuing) . Se asigna la prioridad al trfico de menos carga.Evita tablas de encaminados intermedios y establece decisiones de rutas por paquete. La implantacin de IPv6 que proporciona direccionamiento y la posibilidad de tunneling. mayor espacio de

El desarrollo de este tipo de comunicaciones no ha tenido xito hasta la fecha por la falta de algn tipo de provisin de QoS que cumpliera los requisitos nombrados anteriormente, 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, por lo que la prioridad debe ser alta. La existencia de una gran plataforma de videojuegos est supeditada a la provisin de QoS.

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.

BIBLIOGRAFA

Diffserv como solucin a la provisin de QoS en Internet (Jorge Escribano,...) http://www.it.uc3m.es/cgarcia/articulos/cita2002_diffserv.pdf Servicios Diferenciados (DiffServ) [Presentacin] http://telematica.cicese.mx/i2/presentaciones/Primavera_2k1_CUDI_parte_2_files/fra me.htm Differenciated Services (Wikipedia) http://en.wikipedia.org/wiki/Differentiated_services Red Iris [Informacin e ilustraciones] http://www.rediris.es/ DiffServ -- The Scalable End-to-End QoS Model http://www.cisco.com/en/US/products/ps6610/products_white_paper09186a00800a3e2f .shtml Voz sobre IP (Wikipedia) http://es.wikipedia.org/wiki/Voz_sobre_IP Voz sobre IP (ADSL Zone) http://www.adslzone.net/voz_ip.html Calidad VoIP (Luis Borges Chamorro) http://www.regulatel.org/eventos/cursos/INTERNET/PONENCIAS/Luis%20Borges%20 Chamorro-%20Espana/08-%20CalidadVoIP.ppt