Tema 1 Calidad de Servicio en Redes IP

Aplicaciones Telemáticas Avanzadas II. Pág. 1

Ingeniería de Telecomunicación. E. P. S. de Linares. Universidad de Jaén

Tema 1 1Calidad de servicio en redes IP

Dpto. de Ingeniería de Telecomunicación Área de Ingeniería Telemática

VERSIÓN 1.0 Universidad de JaénE. P. S. de Linares

Contenido.

1.1 Introducción a la QoS y flujos multimedia.Introducción.Requisitos de los flujos multimedia.

1.2 Internet de Servicios Integrados Tipos de servicios: garantizado y carga controlada Protocolos de Reserva: RSVP

1.3 Internet de Servicios Diferenciados. Servicios Integrados vs. Diferenciados Modelo de Gestión de Recursos. Funciones básicas: clasificación, marcado, etcServicios definidos: Expedited y Assured Forwarding.

1.4 Modelos de QoS mixtos: IntServ/DiffServ

Índice

Tema 1: Calidad de servicio en redes IP.




BibliografíaRef

Comer, Douglas E. "Internetworking with TCP/IP Principles, Protocols, andArchitectures" 4ª Edición vol. 1, 2000, Prentice Hall.

Grenville Armitage. “Quality of Service in IP Networks”. MacMillan Technical Plublishing, 2000.

Stallings, William. “Redes e Internet de Alta Velocidad Rendimiento y Calidad de Servicio”, 2ª Edición. Prentice Hall, 2004.

Bibliografía básica






Bibliografía en Internet

Request for Comments (http://www.ietf.org/rfc.html)

Ref

Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, December 1998.

Postel, J., Editor, “Internet Protocol”, STD 5, RFC 791, September 1981.

Otros documentosSimple Differential Services: IP TOS and Precedence, Delay Indication, and Drop

Preferencehttp://www3.ietf.org/proceedings/97dec/slides/intserv-ferguson/sld001.htm




Introducción a la QoS y flujos multimedia.

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)

1.1

Introducción.




Dpto. de Ingeniería de TelecomunicaciónÁrea de Ingeniería Telemática

Tema 1 Calidad de servicio en redes IP


Las crecientes aplicaciones de tiempo real (“real-time” applications) comenzaban a requerir un cambio en el esquema de fucionamiento:

Voz/Telefonía sobre IP (VoIP).Streaming. Radio, TV y video bajo demanda.Telecontrol y acceso remoto a terminales con entornos gráficos.Juegos online.

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.

En definitiva comenzaron a aparecer aplicaciones “in-elásticas” en cuanto a su comportamiento sobre IP.

1.1 Introducción a la QoS y flujos multimedia.




Aplicaciones elásticas.Pueden funcionar dentro de un amplio rango de tasas de trasferencia y retardos, aunque mientras más rápido mejor.Ejemplo: Apliaciones SMTP/POP3, HTTP y FTP.

Aplicaciones de Transmisión multimedia continua.También llamadas “tiempo real tolerante” porque pueden adaptarse al funcionamiento de la red. Ejemplo: Streaming de video con cambio de frame rate.

Aplicaciones de Tiempo realRequieren te tiempos de respuesta acotados y transmisión acotados.Ejemplo: Aplicaciones de control, Voz/Telefonía sobre IP, etc.

1.1

Tipos de aplicaciones. i








Ante la creciente problemática aparece una cuestión muy importante:

¿Se deben modificar estas aplicaciones para que sean más adaptativas, o se debe modificar Internet para soportar estos

comportamientos no elásticos?

La respuesta a esta pregunta no es fácil, y en concreto no se ha optado claramente por una u otra, si no que se ha trabajado por diversos grupos, investigadores y empresas en ambas posibilidades.

Para más información ver los Grupos del IETF: www.ietf.org/html.charters/wg-dir.html






Diferentes entornos y soluciones adoptadas para ofrecer calidad de servicio en Internet.

Los protocolos y aplicaciones se han hecho adaptativos en lo posible. Por ejemplo: TCP, end-to-end congenstion control, IP TOS.

Se han desarrollado nuevas tecnologías que ha permitido ofrecer calidad de servicio bajo IP (ATM, MPLS)

Se ha intentado controlar el funcionamiento de IP añadiendo dos esquemas diferentes de QoS: Internet de Servicios Integrados (IntServ) o Internet de Servicios Diferenciados (DiffServ), o esquemas mixtos entre ambos.







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.

1.1

Requisitos de los flujos multimedia.






Algunos de los requisitos que los flujos multimedia y que un servicio de QoS podría proporcionar son:

Reserva o garantía de uso de un determinado ancho de banda. Detección y control del retardo y su variación (jitter) de los paquetes en la red.Detección y control de la congestión en la red.Uso de políticas de planificación para organizar tráfico de diferentes prioridades o

requerimientos (voz, audio, video, control,…).


Se necesitan mecanismos, políticas, protocolos que puedan conseguir esto.

Se necesita ofrecer Calidad de Servicio (QoS)






En el contexto de Internet, y de los diferentes métodos, protocolos y arquitecturas que se va a mostrar en este tema, la Calidad de Servicio (QoS) se refiere al servicio de envío de paquetes provisto por Internet, caracterizado por una serie de parámetros tales como ancho de banda conseguido, retardo de paquete y porcentaje de paquetes perdidos.

Servicio de Control de la QoS: Conjunto de capacidades coordinadas provistas por un elemento de la red, incluyendo la especificación de las funciones que deben ser realizadas por el elemento de la red, la información requerida por el elemento para poder realizar esas funciones, así como la información generada por el elemento para los demás elementos del sistema. Un servicio está conceptualmente implementado dentro de un “módulo de servicio” contenido en el elemento de la red.

1.1

i¿Que es la Calidad de Servicio (QoS)?






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)

Proporcionar protección y aislamiento a unas clases de QoS con respecto a otras.

Usar los recursos de la forma más eficiente posible.

Control sobre el acceso a la red y diferenciar entre usuarios con diferentes prioridades o calidades de servicio.







Servicio Garantizado (Guaranteed service):Control estricto del desempeño de la red y del retardo.Control de admisión.

Servicio de Carga controlada (Controlled-Load service):Intenta mantener un servicio en el que parezca que la red está descargada.Controla la admisión.

Servicio del Mejor esfuerzo. (Best-Effort service):Sin compromisos de ningún tipo de desempeño, retardo o confirmación de entrega.Sin control de admisión.

1.1

iClases de Servicio.





Internet de Servicios Integrados.

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.

Debe ser proporcionada una manera de comunicar los requerimientos de las aplicaciones a los elementos de la red, así como una manera de enviar información de gestión de la QoS entre los elementos de la red y la aplicación.

1.2

Introducción.








Dentro del marco de IntServ, la primera función se consigue gracias a los servicios de Control de QoS tales como:

Carga Controlada (Controlled-Load, RFC 2211)

Servicio Garantizado (Guaranteed Quality of Service, RFC 2212).

La segunda función puede ser proporcionada de diferentes maneras, pero frecuentemente es a través de un protocolo de configuración y reserva tal como RSVP(Resource ReServation Protocol, RFC 2205)

Información adicional:RFC 2216 Shenker, S., and J. Wroclawski. "Network Element Service SpecificationTemplate", September 1997.

1.2






El desarrollo e implantación de IntServ tiene numerosos aspectos que contemplar, tales como:

Complejidad: El uso así como la necesidades el software y del hardware no deben de ser excesivamente complejas para permitir una robusta implantación asícomo su uso y mantenimiento.

Escalabilidad: El sistema de QoS debe soportar ampliaciones y cambios en la arquitectura sin cambios en los mecanismos.

Modelo de negocio: Debe mantener y asegurar los servicios ofrecidos actualmente y facilitar la implantación de otros nuevos, sin generar costes desproporcionados o cambios sustanciales en los actuales.

Sobrecarga: La implantación y uso no debe suponer una sobrecarga a la actual red, que pueda llevar en el peor de los casos a desestimar las mejoras.

1.2







Elemento de Red (Network Element): Es cualquier componente de una red que puede manejar directamente paquetes de datos y así potencialmente capaz de ejercer un control de las QoS sobre el flujo de datos que lo atraviesa. Los elementos de red incluyen routers, subredes y los sistemas operativos de los nodos finales.

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.

1.2

iDefiniciones (RFC 2216).





Especificación de Tráfico (Traffic Specification, TSpec): Es una descripción de los patrones de tráfico que va a ser requerido para el servicio. En general, las TSpec forman uno de los lados del “contrato” entra el flujo de datos y el servicio.

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.

El comportamiento de un servicio cuando el tráfico acutal de un flujo de datos no respeta la especificación de tráfico esperado, debe ser definido en dicho servicio mediante una política de actiuación.

1.2








Especificación de Petición de Servicio (Service Request Specification, RSpec): Una Especificación de Petición de Servicio, o RSpec, es una especificación de la QoS que desea solicita un flujo de un elemento de la red. El contenido de dicha especificación está altamente detallado para cada servicio en particular.

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.

1.2






Con este servicio se pretende conseguir tanto un compromiso de ancho de banda y retardo en Internet.

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.

1.2

Servicio Garantizado.








Este servicio se apoya en estos tres aspectos:

Es necesario un método de establecer la configuración y comunicar la información entre los elementos de servicio, aunque no se define en este servicio ni este método ni la forma de hacerlo, ya sea con RSVP, manualmente, con SNMP, etc.

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.

1.2






Debido a que los elementos de servicio no reciben un límite de retardo, si no que devuelven uno, se asume normalmente que las aplicaciones no pueden controlar el retardo. Realmente, el Servicio Garantizado da un amplio margen de maniobra sobre su retardo.

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 tokenbucket (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.

1.2







El comportamiento extremo a extremo proporcionado por los elementos de red que conforman una ruta, aseguran un determinado ancho de banda, el cual cuando es usado por un flujo controlado, produce un servicio con retardo-acotado, sin pérdidas en colas de espera para todos los datagramas conformados (asumiendo que no hay fallos en la red o cambios en el enrutado durante la vida del flujo de datos).

El Servicio Garantizado no controla el retardo mínimo o medio de los datagramas, simplemente el máximo retardo de cola.

El servicio está sujeto a un control de admisión.

1.2

Servicio Garantizado. Comportamiento Extremo a Extremo





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

Por ejemplo aplicaciones de “play-back” de audio y video son intolerantes a la llegada de datagramas despues de su tiempo de “play-back”. Aplicaciones que tienen estrictos requerimienos de tiempo real también requieren este tipo de servicio.

1.2

Servicio Garantizado. Motivación







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.

Debido a la ambigüedad de la definición de este servicio, para su mayor concreción se definen los eventos o circunstancias que deberían ser poco probables que sucedieran en un flujo de datos que reciba una QoS de Carga Controlada.

1.2

Servicio de Carga Controlada.





Internet de Servicios Integrados.1.2

Pequeños o ningún retardo de cola sobre todos los plazos de tiempo significativamente mayores que el “tiempo de ráfaga”.

Pequeña o ninguna pérdida por congestión en todos los plazos significativamente mayores que el “tiempo de ráfaga”. En este contexto, estas pérdidas incluyen las pérdidas de paquetes debido a la escasez de recursos en cualquier elemento de proceso, tales como espacio en buffers o ancho de banda de un enlace. A pesar de todo una pérdida ocasional pueden ocurrir, pero una pérdida continuada y sustancial representa un fallo en el algoritmo de control de admisión.

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.





i



El servicio de carga controlada usa la especificación de tráfico TOKEN_BUCKET_TSPEC definida en la RFC 2215, el cual describe un filtro simple Token Bucket.

TOKEN_BUCKET_TSPEC– r : Velocidad sostenida de datos– p : Velocidad pico de datos– b : Tamaño de ráfaga– M: Tamaño máximo de paquete– m : Unidad mínima procesada.

+

r

b

p

Token Bucket






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”.

La recepción de tráfico no conformado no se puede suponer como una fallo o mal funcionamiento de la red, y debe ser asumido como algo posible y habitual.








Aplicaciones del servicio de carga controlada.

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.

El servicio de carga controlada no es isócrono por lo que la temporización y control de entrega debe ser realizado por protocolos de aplicación, como por ejemplo RTP.

También, las aplicaciones dependientes de la carga (load-sensitive), que normalmente usan un esquema “best effort”, pueden aprovecharse en momentos del servicio de carga controlada cuando no consiguen un funcionamiento adecuado con “best effort” o si por ejemplo el uso de QoS supone un coste al servicio.





¿Qué es lo más característico del Protocolo RSVP? (1/3)

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.

El funcionamiento de RSVP es simplex, ya que la reserva se hace para flujos unidireccionales de datos.

RSVP es un protocolo de señalización orientado al receptor, ya que es este el que inicia y mantiene la reserva de recursos para un flujo de datos al que se ha conectado.

1.2

RSVP. Introducción.









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 no es un protocolo de enrutamiento pero depende de los protocolos de enrutamiento presentes y futuros.

RSVP transporta y mantiene parámetros de control de tráfico y de políticas, pero lo hace de forma transparente a estos.

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.

1.2







RSVP proporciona diversos modelos de reserva o “Estilos” para ajustarse a varios tipos de aplicaciones.

RSVP provee una operación transparente a través de los routers que no lo soportan.

1.2








Mecanismos del Control de Tráfico de RSVP.

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.

Clasificador de tráfico: Determina la clase de QoS, y posiblemente la ruta para cada paquete.

Control de admisión.

Planificador de paquetes: Para cada interfaz de salida el planificador, u otro mecanismo de nivel de enlace, que intenta conseguir la QoS requerida.

1.2






Durante la reserva, una petición de QoS RSVP se pasa a dos módulos de decisión locales.

Control de Admisión: Determina si en el nodo que recibe la petición tiene los suficientes recursos para proporcionar la QoS requerida.

Control de Política: Determina si el usuario que hace la petición tiene los suficientes permisos administrativos para hacer tal reserva.

Si ambas pruebas son superadas se establecen los parámetros en el clasificador de tráfico y en el planificador de paquetes para obtener la QoS deseada.

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.

1.2








Aplicación Proceso

RSVP Controlde

políticas

ClasificadorOrganizador

de paquetes

Controlde admisión

DATOS

Procesode

enrutado

Proceso

RSVP

ClasificadorOrganizador

de paquetes

Controlde admisión

DATOS DATOS

HOST ROUTER

Con

trol

de

Tráf

ico

Controlde

políticas





[RFC 2205] Resource ReSerVation Protocol (RSVP) -- Version 1 FunctionalSpecificationR. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. JaminSeptember 1997Updated by RFC2750, RFC3936, RFC4495PROPOSED STANDARD

[RFC 2211] Specification of the Controlled-Load Network Element ServiceJ. WroclawskiSeptember 1997PROPOSED STANDARD

[RFC 2212] Specification of Guaranteed Quality of ServiceS. Shenker, C. Partridge, R. GuerinSeptember 1997PROPOSED STANDARD

1.2







Differentiated Services (Diffserv)

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).

1.3

Introducción





1. Ante estados de congestión de la red, pueden haber bloqueos de flujos con prioridades bajas (por ejemplo de un servicio “bronze” frente a un “gold”).

2. Es necesario establecer contratos de “peering” entre proveedores para asegurar una QoS en el servicio cuando se transita por más de una red.

3. El mantenimiento de las configuraciones en los nodos agrega complejidad a la gestión.

4. Los clientes tienden a sobreestimar sus necesidades de tráfico, por lo que el proveedor termina realizando un “overprovisioning” de su red para soportar los servicios vendidos.

1.3

Limitaciones







En principio DiffServ nace con la idea de solventar algunas de las dificultades de IntServ y RSVP, tales como:

Escalabilidad: Mantener los estados de funcionamiento en los routers de redes de alta velocidad es difícil debido al gran número de flujos de datos.

Modelos de Servicio Flexibles: IntServ tiene sólo dos clases, por lo que se piensa en aportar nuevas clases de servicio cualitativamente diferentes, y clases de servicio relativas (usuarios plata, oro, platino,…)

Señalización simple: En vez del uso de RSVP, muchas aplicaciones y usuariospueden querer sólo especificar una manera más cualitativa de QoS.

1.3

Justificación





Poder realizar un esfuerzo de grado fino solamente desde el borde de la red. Normalmente lo enlaces más lentos están en los bordes. Ejemplo: La ordenación del correo en una oficina de correos.

Marcar los paquetes con un campo de QoS.Ejemplo: El sello de urgente en el servicio de correos.

El núcleo de la red usa sólo este campo de tipo de QoS para la gestión del servicioUn 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.

1.3

Motivación







Clasificación: Marca los paquetes de acuerdo con las reglas de clasificación especificadas.

Medición: Comprueba cuando el tráfico se ajusta al perfil negociado.

Marcado: Marca el tráfico que se ajusta al perfil.

Acondicionado: Retarda y luego envía, descarta o remarca otros tráficos.

1.3

Funciones de los routers de frontera/hosts





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á.

Los otros 2 bits están actualmente reservados para un futuro uso.

1.3

Clasificación y Acondicionado







Envío: De acuerdo con el “Per-Hop-Behavior” o PHB especificado para una clase de QoS de un paquete en particular, tal PHB está basado estrictamente en la clase marcada en el paquete, ningún otro campo de la cabecera es necesario o puede influenciar el PHB.

GRAN VENTAJA:

No es necesaria mantener una información de estado en los routers.

1.3

Funciones del núcleo de la red





El PHB genera diferentes y observables (mesurables) comportamientos en el funcionamiento del envío.

El PHB no especifica que mecanismos serán necesarios usar para asegurar el correspondiente comportamiento definido para cada PHB.

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.

1.3

Envío (Forwarding). PHB







Expedited Forwarding (EF):

Garantiza cierto un mínimo ratio de envío para el tráfico EF.

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.

EL tráfico no conformado es descartado o re-ajustado (shaped).

Posibilidad de servicio: Proveer un cable virtual.

1.3






Assured Forwarding (AF):

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 relativameneuno 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.

1.3








AF y EF no son un estándar aún.La clave del funcionamiento de Diffserv es el control del ancho de banda en el núcleo

de la red. Es sencillo para servicios simples como el canal virtual, pero mucho más

desafiante para diferentes niveles de acuerdo para complejos servicios. Se desprende la necesidad de un “bandwidth broker” que manejara el ancho de

banda de la red..Definición extremo a extremo para servicios a lo largo de redes con diferentes

comportamientos de envío.Los paquetes pueden ser tratados de forma distinta en routers diferentes. Algunos routers no soportan DiffServ.

1.3

Aspectos importantes de DiffServ





[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", June1999.

[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the DifferentiatedServices 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, "AnArchitecture 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.

Ref








[RFC 3086] Nichols K. and B. Carpenter, "Definition of Differentiated Services Per DomainBehaviors 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, "AnExpedited 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 ForwardingPer-Hop Behavior)", March 2002.

Ref





Differentiated Services (Diffserv)1.4

Interfuncionamiento con IntServ

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.






Modelos de QoS mixtos: IntServ/DiffServ

IntServ, RSVP y DiffServ, pueden ser vistas como tecnología complementarias en la persecución de la QoS extremo a extremo. Juntos, estos mecanismos pueden facilitar eldespliegue de aplicación como Telefonía-IP, video bajo demanda y otros muchos tipos de aplicaciones no multimedia con críticos requisitos de funcionamiento.

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.

DiffServ posibilita la escalabilidad a través de grandes redes.

1.4






Modelos de QoS mixtos: IntServ/DiffServ1.4


classifier

Rx

TxRegión Diffserv

marker

meter

Shaper/dropper

A los nodos interiores

PHBIntServ/RSVPIntServ/RSVP








Ejemplo de correspondencia de tráfico IntServ sobre DiffServ usando una política de mapeado sobre PHB






En este esquema, la QoS extremo a extremo se provee aplicando un modelo IntServextremo a extremo a lo largo de una red que contiene una o varias regiones DiffServ.

Las regiones DiffServ pueden o no participar en la señalización extremo a extremo de RSVP con el propósito de optimizar la reserva de recursos y el soporte al control de admisión.

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", June1999.

[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the DifferentiatedServices 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, "AnArchitecture 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.

Ref






[RFC 3086] Nichols K. and B. Carpenter, "Definition of Differentiated Services Per DomainBehaviors 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, "AnExpedited 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 ForwardingPer-Hop Behavior)", March 2002.

Ref


Tema 1 Calidad de Servicio en Redes IP

Documents

Transcript of Tema 1 Calidad de Servicio en Redes IP