Realizado por Héctor Cabrejas Fernández y Manuel González

Realizado por Héctor Cabrejas Fernández y Manuel González Tejerina. Grupo 14J
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 (1997 – 2005)
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
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).
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
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
El modelo COPS
Las características principales del protocolo COPS son las siguientes:
-
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).
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.
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.
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.
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.
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
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 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.
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,...)
http://www.it.uc3m.es/cgarcia/articulos/cita2002_diffserv.pdf
Servicios Diferenciados (DiffServ) [Presentación]
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 [Información 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