Académique Documents
Professionnel Documents
Culture Documents
Universidad de Jaén
Índice Contenido.
Tema 1: Calidad de servicio en redes IP.
Ref Bibliografía
Bibliografía básica
Postel, J., Editor, “Internet Protocol”, STD 5, RFC 791, September 1981.
Otros documentos
Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop
Preference
http://www3.ietf.org/proceedings/97dec/slides/intserv-ferguson/sld001.htm
El protocolo IP, y por extensión Internet, en su diseño inicial1, no proveía más que una
sola clase de servicio (o visto de otra manera, de ninguna), denominada “best-effort”,
que viene a significar que se haría lo posible porque el paquete llegara a su destino, pero
no se garantizaba su entrega ni la notificación de la misma, así como no se ofrecía la
posibilidad de marcar los paquetes como tráfico preferencial.
Por ese mismo hecho, las aplicaciones desarrolladas usando el protocolo IP a nivel de
red necesitaban cierta elasticidad. Como ejemplo tenemos el correo electrónico, el
servicio web (world wide web), el servicio de transferencia de ficheros.
1.Realmente si existía una forma de marcar paquetes con los bits TOS (Type of service)
Todas estas aplicaciones deben ofrecer sus servicios/datos en un tiempo acotado, ya que
en otro caso el servicio sufriría sensiblemente y conllevaría a una posible caída de la
aplicación o incluso a la inviabilidad del misma.
Sin duda uno de los factores que ha contribuido más tenazmente al desarrollo y
búsqueda de redes con calidad de servicio en la actualidad es la distribución y acceso a
servicios multimedia, ya sea, voz, audio, video o cualquier otro servicio derivado de
estos, como la radio, televisión o juegos online.
Este tipo de servicios tiene una serie de características comunes que chocan con el
enfoque “best-efford” de IP.
Sin embargo debido al gran auge de Internet se han ido adaptando de diferentes formas
al funcionamiento sobre IP, ya sea usando protocolos de transporte como UDP, TCP o
RTP, o protocolos de aplicación (SIP, SDP, RTSP). Alrededor de este tema a numerosos
estudios, siendo hoy en día un punto clave en el desarrollo de Internet.
Algunos de los requisitos que los flujos multimedia y que un servicio de QoS podría
proporcionar son:
Los principios para poder proporcionar QoS a los flujos multimedia se muestran a
continuación:
Diferenciar entre distintos tipos de tráfico según el contenido (voz, audio, video,
datos)
Control sobre el acceso a la red y diferenciar entre usuarios con diferentes prioridades
o calidades de servicio.
Internet de Servicios Integrados provee la capacidad para las aplicaciones de elegir entre
múltiples niveles de control de enviar sus paquetes de datos. Para soportar esta
capacidad, IntServ da un enfoque de orientado a flujo, basado en:
Los elementos individuales de la red (subnets y routers IP) a lo largo del camino
seguido por los paquetes de una aplicación, deben soportar los mecanismos de control de
calidad de servicio (QoS) para esos paquetes.
Dentro del marco de IntServ, la primera función se consigue gracias a los servicios de
Control de QoS tales como:
Información adicional:
RFC 2216 Shenker, S., and J. Wroclawski. "Network Element Service Specification
Template", September 1997.
Flujo de datos (flow): Conjunto de paquetes que atraviesan un elemento de red, todos
los cuales están agrupados por la misma petición de control de la QoS. En un elemento
de red en concreto, un flujo puede consistir en los paquetes provenientes de una sola
sesión de una aplicación, o ser el resultado de combinar el tráfico de diferentes sesiones
de aplicaciones.
Como ejemplo, esta especificación puede ser en forma de un filtro “token bucket”. Se
debe reseñar que la estas especificaciones detalan el patrón de tráfico permitido para un
flujo, no el patrón de tráfico actual.
Como ejemplo, estas especificaciones pueden contener información acerca del ancho de
banda reservado para el flujo de datos, los retardos máximos o los porcentajes de
pérdida de paquetes.
En este servicio los flujos de datos se describen usando token bucket, y para esto los
elementos del servicio (routers, subnet, etc.) deben computar diversos parámetros que
describan como el elemento está manejando el flujo de datos.
Aunando los datos recogidos por los elementos a lo largo de una ruta, es posible
conseguir una medida del máximo retardo que un paquete de datos puede experimentar
al ser transmitido por esa ruta.
Para conseguir ofrecer los límites de retardo y ancho de banda acordados, todos los
elementos de la ruta deber soportar, o al menos imitar, el Servicio Garantizado. Lo que
no significa que sea necesario implementar este servicio en toda Internet para que sea
útil.
El retardo tiene dos partes; una fija (retardos de transmisión) y retardo de cola. Sólo el
retardo de cola es calculado por el Servicio Garantizado, el cual es función del token
bucket (principalmente del tamaño b) y de la velocidad de datos (R) que la aplicación
solicita. Concretamente estos dos valores están bajo el control de la aplicación, por lo
que ésta puede hacer una estimación a priori de su retardo y modificar alguno de sus
parámetros para ajustarse al retardo que puede realmente conseguir.
El Servicio Garantizado asegura que los datagramas llegarán dentro del tiempo de
distribución acordado y que no serán descartados debido a desbordamientos en las colas.
Este servicio está pensado para aplicaciones que necesitan una firme garantía de que un
datagrama llegará no más tarde de un cierto tiempo desde que fue transmitido por la
fuente
Este servicio provee al cliente con un flujo de datos con una QoS cercana a la que
aproximadamente recibiría el mismo flujo de datos en un elemento de la red descargado
con “best efford”. Este servicio utiliza un control de admisión para asegurar que es
posible ofrecerse incluso en momentos en el que un elemento de red esté sobrecargado.
Nota: El echo de que un elemento de red se considere “descargado” implica que “no
está muy cargado o congestionado”, no que no haya ninún otro tráfico a través de él.
Tiempo de ráfaga (burst time): Se define como el tiempo requerido para la ráfaga de
mayor tamaño del flujo de datos para ser transmitida según la velocidad de transmisión
requerida. Tanto el tamaño de ráfaga, como la velocidad de transmisión se definen en
el TSpec del flujo de datos.
Política de servicio.
El TSpec de token bucket requiere que el tráfico obedezca la regla en cualquier intervalo
de tiempo de que la cantidad de datos enviado no exceda rT+b, donde r y b son los
parámetros del token bucket y T es la duración del intervalo de tiempo.
Los paquetes que lleguen al elemento de red y ocasionen una violación de la condición
anterior, o excedan la MTU, serán considerados como tráfico no conformado y tan sólo
se les ofrecerá un servicio “best effort”.
En general el servicio de carga controlada puede ser usado por cualquier aplicación que
funcione bien en un entorno “best effort”, pero se aprovechará mejor en aplicaciones
que puedan caracterizar apropiadamente su tráfico, como las basadas en el transporte
contínuo de contenido mulimedia, como el audio o video digitalizado.
RSVP hace reservas tanto para aplicaciones unicast como multicast, adaptándose
dinámicamente a los cambios de asignación de miembros de grupos así como de rutas.
RSVP debe mantener en cada nodo los requerimientos de reserva, los cuales se
denominan “soft state ”, lo cual provee de un adecuado método para adapterse a los
cambios de pertenecia a grupos, así como adaptación automática a los cambios de ruta.
RSVP se usa encima de IP4 e IP6 para funcionar, al igual que los protocolos de
transporte, pero no transporta ningún dato de la aplicaciones.
RSVP provee una operación transparente a través de los routers que no lo soportan.
La calidad de servicio es implementada para una flujo de datos en particular por una
serie de mecanismos que colectivamente se denominan “Control de Tráfico”, según han
sido definidos por el Integrated Services Working Group.
Control de admisión.
Durante la reserva, una petición de QoS RSVP se pasa a dos módulos de decisión
locales.
Control de Política: Determina si el usuario que hace la petición tiene los suficientes
permisos administrativos para hacer tal reserva.
Si cualquiera de las dos pruebas falla el servicio RSVP devolverá una notificación de
error al proceso de aplicación que originó la petición.
S Control Control
de admisión de admisión
Organizador Organizador
Clasificador de DATOS Clasificador de DATOS
paquetes paquetes
DiffServ fue pensado para proveer QoS en redes grandes como Internet, ya que el
tratamiento no lo hace por flujo si no por grupo de flujos.
Para esto es necesario definir un SLA (Service Level Agreement ) entre el cliente y el
proveedor de servicios donde se especifica, entre otras cosas, el comportamiento del
tráfico que el cliente va a enviar hacia la red y las acciones que el proveedor va a tomar
cuando se cumple o no con el contrato (por ejemplo el conformado o descartado del
tráfico).
El núcleo de la red usa sólo este campo de tipo de QoS para la gestión del servicio
Un número reducido de tipos pero con un comportamiento claro y bien definido.
Pueden ser tratados de una forma más rápida.
Evolución en vez de revolución.
Los paquetes se marcan usando el campo Type of Service (TOS) en IPv4, y usando el
campo Traffic Class en IPv6.
Sólo 6 bits son usados para el Differentiated Service Code Point (DSCP) y determinar
el PHB (Per Hop Behavior) que el paquete recibirá.
GRAN VENTAJA:
Ejemplos:
Clase A: Conseguir que el x% del ancho de banda de salida del enlace sobre
intervalos de tiempo de duración especificada.
Los paquetes de Clase A serán enviados siempre antes que los de Clase B.
Aislamiento: Garantiza que el tráfico EF no debe ser influenciado por otras clases de
tráfico.
Admisión basada en la velocidad de pico.
AF define 4 clases con algún ancho de banda y tamaño en buffers reservado para
ellas.
El objetivo es que sean usadas para implementar servicios que difieran relativamene
uno de otro (por ejemplo, oro, plata, …)
Dentro de cada clase hay tres prioridades de descarte, que afecta a qué paquetes serán
descartados primero en el caso de congestión.
Hay muchos estudios de como estas clases y las prioridades de descarte afectan al
control de flujo de TCP.
El tráfico no conformado es remarcado.
[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", June
1999.
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers",December 1998.
[RFC 2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An
Architecture for Differentiated Services", December 1998.
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2998] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Baden, B. Davie,
J. Wroclawski, and E. Felstaine. “A framework for integrated services operation over diffserv
networks.”, November 2000.
[RFC 3086] Nichols K. and B. Carpenter, "Definition of Differentiated Services Per Domain
Behaviors and Rules for their Specification",April 2001.
[RFC 3246] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", March 2002.
[RFC 3247] Charny, A., Baker, F., Davie, B., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu,
A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis,
"Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding
Per-Hop Behavior)", March 2002.
Los estudios e investigaciones sobre la QoS de servicio sobre IP, como se ha visto, han
derivado en dos diferentes vertientes: La arquitectura de Servicios Integrados (IntServ)
y la de Servicios Diferenciados (DiffServ).
IntServ es una arquitectura de QoS orientada a flujo, que usa RSVP para la reserva de
recursos.
En contraste DiffServ clasifica los paquetes entre un pequeño número de tipos de flujos
o clases, basados en el Diffserv Code Point (DSCP) situado en la cabecera de los
paquetes IP. Siendo en cada router DiffServ donde los paquetes están sometidos al “per-
hop behavior” (PHB), el cual se desprende del DSCP.
IntServ posibilita a los hosts el poder solicitar recursos cuantificables para cada flujo de
datos, a lo largo de rutas de datos extremo a extremo, y a su vez, obtener una respuesta
de la viabilidad de esas peticiones.
IntServ/RSVP PHB
IntServ/RSVP
meter
Rx
Desde la perspectiva de IntServ, las regiones DiffServ de la red son tratadas como
enlaces virtuales conectando routers y hots que implementan IntServ.
Dentro de las regiones DiffServ de la red, los routers implementan PHB específicos. La
cantidad total de tráfico admitido dentro de la región DiffServ que recibirá cierto PHB
puede ser limitado gracias a un control de política en el borde.
[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", June
1999.
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers",December 1998.
[RFC 2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An
Architecture for Differentiated Services", December 1998.
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2998] Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Baden, B. Davie,
J. Wroclawski, and E. Felstaine. “A framework for integrated services operation over diffserv
networks.”, November 2000.
[RFC 3086] Nichols K. and B. Carpenter, "Definition of Differentiated Services Per Domain
Behaviors and Rules for their Specification",April 2001.
[RFC 3246] Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", March 2002.
[RFC 3247] Charny, A., Baker, F., Davie, B., Bennett, J.C.R., Benson, K., Le Boudec, J.Y., Chiu,
A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnan, K.K. and D. Stiliadis,
"Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding
Per-Hop Behavior)", March 2002.