Realizado por Héctor Cabrejas Fernández y Manuel González Tejerina. Grupo 14J

Transcripción

1 Realizado por Héctor Cabrejas Fernández y Manuel González Tejerina. Grupo 14J

2 INTRODUCCIÓN En la actualidad los sistemas informáticos 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 más amplia gama de aplicaciones. 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 transmision de información. El objetivo es simple. Evitar que la congestión en determinados nodos de la red afecte a algunas aplicaciones que requieran un determinado ancho de banda (Video Conferencia, VoIP,...), o un mínimo retardo, sin la necesidad de ocupar excesivo ancho de banda (Juegos OnLine). El tráfico producido por dichas aplicaciones ha aumentado exponencialmente en los últimos años, tal y como podemos apreciar en esta gráfica, gracias al constante desarrollo y mejora de las redes de datos. Tráfico Global VoIP por regiones ( )

3 Para evitar dicha congestión, existen dos tendencias bien distintas. Una implica sobredimensionar adecuadamente la red de transporte. Este método se basa en el abaratamiento de los sistemas de conmutación y transporte, si bien provoca una gestión 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, compartiéndolos de manera desigual entre los diferentes flujos de tráfico. Sin embargo, hoy en día, 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 tecnologías que proporcionan una determinada Calidad de Servicio (QoS): MODELO INTSERV Basado en la utilización de algún protocolo de reserva (RSVP, ReSerVation Protocol), nos permite realizar una reserva de recursos en todos los routers implicados en la comunicación. El principal inconveniente que se nos presenta ante esta tecnología, radica en la necesidad de mantener información sobre cada flujo en todos los routers de la red, lo cual conduce a problemas de escabilidad. Modelo IntServ

4 MODELO DIFFSERV Este modelo, a diferencia del anterior, se basa en la división del tráfico en diferentes clases, y en la asignación de prioridades a estos agregados. División de tráfico 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 través de un mapeo entre flujos de tráfico y niveles de servicio. Todos los paquetes que pertenecen a una determinada clase se marcan con un código específico DSCP. La diferenciación de servicios se consigue 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 Behavoir).

5 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 políticas y grupos de comportamiento de salto (PHB Per Hop Behavior) que determinarán el tratamiento de los paquetes en la red. Arquitectura DiffServ Vamos a analizar las características necesarias de los diferentes nodos. Más adelante, presentaremos el tipo de políticas que se suele utilizar en la implementación de estos sistemas. NODOS EXTERNOS DS (Ingress / Egress Nodes): Se hace imprescindible realizar diferentes funciones como el acondicionamiento de tráfico entre los dominios DiffServ interconectados. Para ello, se deben clasificar y establecer las condiciones de ingreso de los flujos de tráfico, denominado TCB (Traffic Conditioner Block) en función de un clasificador conocido como MF (Multi-Field Classifeier), que consta de: - Dirección IP - Puerto (Origen y Destino) - Protocolo de transporte - DSCP

6 Además, los nodos DS de entrada (Ingress DS Nodes) serán los responsables de asegurar que el tráfico de entrada cumple los requisitos de algún TCA (Traffic Conditioning Agreement), derivado de SLA (Service Level Agreement), entre los dominios interconectados. De forma análoga, los nodos DS de salida (Egress DS Nodes) deberán realizar las funciones de acondicionamiento de tráfico o TC (Traffic Conformation) sobre el tráfico 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 selección del PHB (Per Hop Behavoir) solo se tendrá en cuenta el campo DSCP, conocido como clasificador BA (Behavoir Aggregate Classifier). PROTOCOLO DE GESTIÓN DE POLÍTICAS: COPS Dentro de este escenario que define DiffServ, necesitamos un protocolo o modo de comunicación que nos garantice la distribución de las políticas de calidad de servicio entre los elementos de red que así lo necesiten. Además, 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 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. 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). Mensaje COPS

7 Las características principales del protocolo COPS son las siguientes: El modelo COPS - 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. - 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 autenticación, protección frente al reenvío (replay) e integridad del mensaje. Permite además reutilizar otros protocolos de seguridad existentes para proporcionar autenticación 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. IMPLEMENTACIÓN En la implementación de un entorno de marcado DiffServ típico, como puede ser una comunicación 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 Políticas (PDP), centralizando la asignación de códigos 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).

8 El cuarto elemento necesario para la implementación de dicho entorno es el protocolo de comunicación entre los nodos DS, COPS. 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 pueden cambiar, la asignación de códigos DiffServ será dinámica para cada comunicación de voz. Por el contrario, es lógico utilizar una asignación estática para tráficos 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 dirección 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 información relacionada con la llamada. Una vez reciba la petición, éste 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 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 conexión está instalada en la tabla, y si debe recibir un tratamiento DiffServ. Dependiendo de ese tipo de tráfico, a esa conexión se le asignará un código 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 código 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 petición para saber si es 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.

9 VISIÓN 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 implementación de este sistema de forma genérica, reduciendo la penetración en el mercado. Como se ha explicado anteriormente, el modelo DiffServ divide el tráfico en diferentes clases formando agregados y asigna diferentes prioridades a dichos agregados, los cuales recibirán el tratamiento correspondiente en los nodos de la red. El punto más atractivo de este método 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 tráfico consigan determinados parámetros QoS, como pueda hacer ATM a través de circuitos. DiffServ solo puede proporcionar cierta probabilidad de Calidad de Servicio (QoS) para cada grupo de agregados. En la actualidad el tráfico 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 política de tráfico y contrato SLA diferente al nuestro. Como consecuencia de esto, los paquetes al pasar por dichos ISPs, serán tratados según sus respectivas políticas, pudiendo variar el valor del byte DS en donde se especificarán las prioridades de los paquetes para cada caso. 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. 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 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.

10 Viendo las dificultades que se presenta para encauzar el trafico, en 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). 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 típicamente se hace referencia a QoS entre los routers extremos entre origen y destino (que es donde se hace la diferenciación de paquetes). 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. 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á ningún problema, pero en los casos en que se establezca una comunicación bidireccional podrían aparecer problemas. Por ejemplo 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 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). 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 parecería que esa decisión la tendría que tener el usuario, siendo él el que eligiera el tratamiento deseado, marcando la QoS en los paquetes. Si esto fuera así, 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. Sin embargo, aún teniendo las limitaciones que acabamos de ver, puede ser muy útil para ciertas aplicaciones/servicios descritas a continuación. 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 características de la transmisión que va a recibir. En 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.

11 En estos casos 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, dicha selección 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 desaparecería en el caso de VPNs (Virtual Private Networks) donde el origen y el destino pertenecen a la misma organización, de manera que comparten los mismos criterios sobre QoS, los ISPs intermedios no cambiarán las prioridades de los paquetes al compartir la misma política. 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. 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), 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 telefonía vía VoIP es gratuito o cuesta muchísimo menos que el servicio equivalente tradicional y similar a la alternativa que los proveedores del servicio de la Red Pública Telefónica 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.

12 El principal problema que presenta hoy en día 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 Códecs que garanticen la codificación y compresión del audio y/o del video para su posterior decodificación y descompresión antes de poder generar un sonido o imagen utilizable. Según el Códec utilizado en la transmisión, se utilizará más 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 tránsito y el retardo de procesado la conversación se considera aceptable por debajo de los 150 ms. La calidad de servicio se está logrando en base a los siguientes criterios: - La supresión de silencios, otorga más eficiencia a la hora de realizar una transmisión de voz, ya que se aprovecha mejor el ancho de banda al transmitir menos información - Compresión de cabeceras aplicando los estándares RTP/RTCP. - Priorización 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 tráfico de menos carga.evita tablas de encaminados intermedios y establece decisiones de rutas por paquete. - La implantación de IPv6 que proporciona mayor espacio de direccionamiento y la posibilidad de tunneling. 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 que cumpliera los requisitos nombrados anteriormente, 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, por lo que la prioridad debe ser alta. La existencia de una gran plataforma de videojuegos está supeditada a la provisión de QoS.

13 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. BIBLIOGRAFÍA Diffserv como solución a la provisión de QoS en Internet (Jorge Escribano,...) Servicios Diferenciados (DiffServ) [Presentación] me.htm Differenciated Services (Wikipedia) Red Iris [Información e ilustraciones] DiffServ -- The Scalable End-to-End QoS Model Voz sobre IP (Wikipedia) Voz sobre IP (ADSL Zone) Calidad VoIP (Luis Borges Chamorro) Chamorro-%20Espana/08-%20CalidadVoIP.ppt