1 / 93

Tema 3 Calidad de Servicio (QoS)

Tema 3 Calidad de Servicio (QoS). Rogelio Montañana Departamento de Informática Universidad de Valencia rogelio.montanana@uv.es http://www.uv.es/~montanan/. Sumario. Concepto de Calidad de Servicio Calidad de servicio en LANs Calidad de Servicio en Internet

deanna-mcbride
Download Presentation

Tema 3 Calidad de Servicio (QoS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tema 3Calidad de Servicio (QoS) Rogelio Montañana Departamento de Informática Universidad de Valencia rogelio.montanana@uv.es http://www.uv.es/~montanan/

  2. Sumario • Concepto de Calidad de Servicio • Calidad de servicio en LANs • Calidad de Servicio en Internet • Modelo IntServ y protocolo RSVP • Modelo DiffServ • Control de congestión en Internet • MPLS

  3. Requerimientos de Calidad de Servicio de las aplicaciones (*) La fiabilidad alta en estas aplicaciones se consigue automáticamente al utilizar el protocolo de transporte TCP

  4. Congestión y Calidad de Servicio • Sería muy fácil dar Calidad de Servicio si las redes nunca se congestionaran. Para ello habría que sobredimensionar todos los enlaces, cosa no siempre posible o deseable. • Para dar QoS con congestión es preciso tener mecanismos que permitan dar un trato distinto al tráfico preferente y cumplir el SLA (Service Level Agreement).

  5. Efectos de la congestión en el tiempo de servicio y el rendimiento Sin Congestión Congestión Moderada Congestión Fuerte Sin Congestión Congestión Moderada Congestión Fuerte Tiempo de Servicio Rendimiento Carga Carga QoS inútil QoS útil y viable QoS inviable QoS inútil QoS útil y viable QoS inviable

  6. Calidad de Servicio (QoS) • Decimos que una red o un proveedor ofrece ‘Calidad de Servicio’ o QoS (Quality of Service) cuando se garantiza el valor de uno o varios de los parámetros que definen la calidad de servicio que ofrece la red. Si el proveedor no se compromete en ningún parámetro decimos que lo que ofrece un servicio ‘best effort’. • El contrato que especifica los parámetros de QoS acordados entre el proveedor y el usuario (cliente) se denomina SLA (Service Level Agreement)

  7. Parámetros típicos de los SLAs

  8. Fluctuación del retardo—“Jitter” Emisor Receptor Red B C A Emisor Transmite t A B C Receptor Recibe t 50 ms 50 ms 90 ms Red vacía Congestión Retardo: 70 ms  20 ms (retardo: 70 ms, jitter: 40 ms)

  9. Relación entre la probabilidad de llegada de los datagramas y los parámetros del SLA Probabilidad El tiempo mínimo de propagación depende de las características físicas de la red Retardomínimo Tiempo Jitter Retardomedio Datagramas considerados perdidos por haberse entregado demasiado tarde

  10. Reducción del Jitter • La principal causa de jitter es la congestión • Se puede reducir el jitter añadiendo un retardo adicional en el lado del receptor. Por ejemplo con un retardo de 70  20 msse puede asegurar jitter 0 si se añade un retardo de 40 ms (90  0 ms). • Para el retardo adicional el receptor ha de tener un buffer suficientemente grande. • En algunas aplicaciones no es posible añadir mucho retardo pues esto reduce la interactividad. Ej.: videoconferencia, telefonía por Internet

  11. Calidad de Servicio: ¿Reserva o Prioridad? • Existen dos posibles estrategias para dar trato preferente a un usuario en una red: • Carril BUS: reservar capacidad para su uso exclusivo. A veces se denomina ‘QoS hard’. Ej.: VCs ATM con categoría de servicio CBR • Ambulancia: darle mayor prioridad que a otros usuarios. A veces se denomina ‘QoS soft’. Ejemplo: Token Ring • Cada una tiene ventajas e inconvenientes.

  12. ¿Reserva o Prioridad?

  13. Sumario • Concepto de Calidad de Servicio • Calidad de servicio en LANs • Calidad de Servicio en Internet • Modelo IntServ y protocolo RSVP • Modelo DiffServ • Control de congestión en Internet • MPLS

  14. QoS en LANs • Desarrollos en 802.1p y 802.1Q • Campo prioridad de tres bits. Hasta ocho niveles posibles. Similar al campo prioridad de Token Ring, pero incompatible. • No se ha extendido su uso. Dudosa utilidad dada la posibilidad de sobredimensionar a bajo costo • Necesidad de acompañarlo de políticas de uso (sistema de contabilidad/facturación).

  15. Etiquetado de tramas según 802.1Q Trama 802.3 Trama 802.1Q El Ethertype X’8100’ indica ‘protocolo’ VLAN Bits 3 1 12 Pri: Prioridad (8 niveles posibles) CFI: Canonical Format Indicator (indica formato de direcciones MAC) VLAN Ident.: Identificador VLAN (máximo 4096 en una misma red)

  16. Sumario • Concepto de Calidad de Servicio • Calidad de servicio en LANs • Calidad de Servicio en Internet • Modelo IntServ y protocolo RSVP • Modelo DiffServ • Control de congestión en Internet • MPLS

  17. Calidad de Servicio en Internet • La congestión y la falta de QoS es el principal problema de Internet actualmente. • TCP/IP fue diseñado para dar un servicio ‘best effort’. • Existen aplicaciones que no pueden funcionar en una red congestionada con ‘best effort’. Ej.: videoconferencia, VoIP (Voice Over IP), etc. • Se han hecho modificaciones a IP para que pueda funcionar como una red con QoS

  18. Calidad de Servicio en Internet “El Santo Grial de las redes de computadores es diseñar una red que tenga la flexibilidad y el bajo costo de la Internet, pero que ofrezca las garantías de calidad de servicio extremo a extremo de la red telefónica.” S. Keshav: 'An Engineering Approach to ComputerNetworking‘, 1997

  19. Calidad de servicio en Internet • Se han desarrollado y estandarizado los dos mecanismos de QoS, reserva y prioridad: • IntServ (Integrated Services) y protocolo RSVP. El usuario solicita de antemano los recursos que necesita; cada router del trayecto ha de tomar nota y efectuar la reserva solicitada. • DiffServ (Differentiated Services). El usuario marca los paquetes con un determinado nivel de prioridad; los routers van agregando las demandas de los usuarios y propagándolas por el trayecto. Esto le da al usuario una confianza razonable de conseguir la QoS solicitada. • Ambos son compatibles y pueden coexistir

  20. Sumario • Concepto de Calidad de Servicio • Calidad de servicio en LANs • Calidad de Servicio en Internet • Modelo IntServ y protocolo RSVP • Modelo DiffServ • Control de congestión en Internet • MPLS

  21. Clasificación de las aplicaciones en IntServ (Integrated Services)

  22. Tipos de servicio en IntServ

  23. Reparto de recursos en IntServ Best Effort Caudal  Carga controlada Garantizado Tiempo 

  24. IntServ y RSVP • Para ofrecer QoS IntServ se basa en la reserva previa de recursos en todo el trayecto • Para esa reserva se emplea el protocolo RSVP (Resource ReserVation Protocol) muy relacionado con el modelo IntServ • Se supone que la reserva permitirá asegurar la QoS solicitada (siempre y cuando la red tenga aún recursos suficientes) • Normalmente la reserva se realiza para una secuencia de datagramas relacionados entre sí, que es lo que llamamos un flujo.

  25. Concepto de flujo • Un flujo es una secuencia de datagramas que se produce como resultado de una acción del usuario y requiere la misma QoS • Un flujo es simplex (unidireccional) • Un flujo es la entidad más pequeña a la que los routers pueden aplicar una determinada QoS • Ejemplo: una videoconferencia estaría formada por cuatro flujos, dos en cada sentido, uno para el audio y otro para el vídeo. • Los flujos pueden agruparse en clases; todos los flujos dentro de una misma clase reciben la misma QoS.

  26. Flujos en una videoconferencia A 147.156.135.22 B 158.42.35.13 Flujo vídeo A->B: 147.156.135.22:2056 -> 158.42.35.13:4065 Flujo audio A->B: 147.156.135.22:3567 -> 158.42.35.13:2843 Flujo vídeo B->A: 158.42.35.13:1734 -> 147.156.135.22:6846 Flujo vídeo B->A: 158.42.35.13:2492 -> 147.156.135.22:5387

  27. Agrupación de flujos Flujo ‘rojo’ (128 Kb/s): 147.156.21.20.2038158.26.112.76.2127 Reserva total flujos de vídeo: en sentido X Y: 384 Kb/s Vídeo 128 Kb/s IP: 147.156.21.20 Puerto UDP: 2038 IP: 158.26.112.76 Puerto UDP: 2127 X Y Flujo ‘verde’ (256 Kb/s): 147.156.47.12.3124158.26.36.97.5753 IP: 158.26.36.97 Puerto UDP: 5753 Vídeo 256 Kb/s IP: 147.156. 47.12 Puerto UDP: 3124

  28. Identificación de flujos • En IPv4 se hace por: • Dirección IP de origen • Puerto de origen • Dirección IP de destino • Puerto de destino • Protocolo de transporte utilizado (TCP o UDP) • En IPv6 la identificación puede hacerse como en IPv4 o alternativamente usando el campo ‘etiqueta de flujo’ en vez de los números de puertos. Aún no hay ninguna implementación de RSVP que utilice la etiqueta de flujo.

  29. ¿Que es RSVP? • Reserva la capacidad solicitada por un flujo en todos los routers del camino. • Es un protocolo de señalización (como el utilizado para establecer SVCs en ATM). • Requiere guardar información de estado en todos los routers del trayecto. Es un servicio orientado a conexión. • Está pensado principalmente para tráfico multicast • No es un protocolo de routing (de eso se ocupará OSPF, IS-IS, PIM-SM, etc.

  30. Componentes de RSVP • Para implementar RSVP los routers han de incorporar cuatro elementos: • Admission Control: comprueba si la red tiene los recursos suficientes para satisfacer la petición. Equivalente al CAC (Connection Admission Control) de ATM. • Policy Control: determina si el usuario tiene los permisos adecuados para la petición realizada (por ejemplo si tiene crédito disponible). La comprobación se puede realizar consultando una base de datos mediante el protocolo COPS (Common Open Policy Service) • Packet Classifier: clasifica los paquetes en categorías de acuerdo con la QoS a la que pertenecen. Cada categoría tendrá una cola y un espacio propio para buffers en el router. • Packet Scheduler: organiza el envío de los paquetes dentro de cada categoría (cada cola).

  31. RSVP (Cont.) • RSVP reserva la capacidad solicitada en todos los routers del camino. • Cada router ha de mantener el detalle de todas las conexiones activas que pasan por él, y los recursos que cada una ha reservado. El router mantiene información de estado sobre cada flujo que pasa por él. • Si no se pueden asegurar las condiciones pedidas se rechaza la llamada (control de admisión)

  32. Problemas de IntServ/RSVP • RSVP produjo una euforia inicial (1996-1997) que luego dió paso a la decepción. • La razón principal fueron problemas de escalabilidad debidos a la necesidad de mantener información de estado en cada router. Esto hace inviable usar RSVP en grandes redes, por ejemplo en el ‘core’ de Internet.

  33. Problema de escalabilidad de RSVP Estos routers han de mantener información sobre muchos flujos y por tanto mucha información de estado ‘Core’ de Internet

  34. Problemas de IntServ/RSVP • Los fabricantes de routers no han desarrollado implementaciones eficientes de RSVP, debido al elevado costo que tiene implementar en hardware las funciones de mantenimiento de la información de estado. • A pesar de todo RSVP/IntServ puede desempeñar un papel en la red de acceso, donde los enlaces son de baja capacidad y los routers soportan pocos flujos. • Recientemente ha resurgido el interés por RSVP por su aplicación en MPLS y funciones de ingeniería de tráfico. En estos casos el número de flujos no suele ser muy grande

  35. Funcionamiento de RSVP en Multicast Emisor (flujo de 1,5 Mb/s) 1,5 Mb/s • Las reservas se agregan a medida que ascienden en el árbol multicast. • Así se optimiza el uso de la red (solo se reserva una vez en cada tramo). 1,5 Mb/s 1,5 Mb/s 1,5 Mb/s 1,5 Mb/s Receptor Receptor Receptor

  36. Problemas de RSVP en Multicast • La combinación de Multicast y RSVP plantea algunos problemas no resueltos, por ejemplo: • ¿Por cuenta de que receptor se efectúa el Policy Control en la parte común del árbol? Si se concede la reserva al primer solicitante, ¿que pasa cuando ese se borra del grupo y quedan otros suscritos? Si no se le concede al primero, ¿que pasa si luego se le concede a otro solicitante? • Suponiendo que se cobre por el servicio ¿A quién se le factura el uso de la parte común? ¿se prorratea entre todos los usuarios activos en ese momento? Eso significa que el precio cambiará con el uso.

  37. RFCs sobre IntServ/RSVP • RFC 1633 (6/1994): Integrated Services in the Internet Architecture: an Overview • RFC 2205 (9/1997): RSVP Version 1 Functional Specification • RFC 2206 (9/1997): RSVP MIB using SMIv2 • RFC 2207 (9/1997): RSVP Extensions for IPSEC Data Flows • RFC 2208 (9/1997): RSVP Version 1 Applicability Statement Some Guidelines on Deployment • RFC 2209 (9/1997): RSVP Version 1 Message Processing Rules • RFC 2210 (9/1997): The Use of RSVP with IETF Integrated Services • RFC 2211 (9/1997): Servicio de carga controlada • RFC 2212 (9/1997): Servicio Garantizado • RFC 2213 (9/1997): Integrated Services Management Information Base Using SMIv2 • RFC 2214 (9/1997): Integrated Services MIB Guaranteed Service Extensions using SMIv2 • RFC 2215 (9/1997): General Characterization Parameters for Integrated Services • RFC 2379 (8/1998): RSVP over ATM Implementation Guidelines • RFC 2380 (8/1998): RSVP over ATM Implementation Requirements • RFC 2382 (8/1998): A Framework for Integrated Services and RSVP over ATM • RFC 2490 (1/1999): A Simulation Model for IP Multicast with RSVP • RFC 2688 (9/1997): Integrated Services Mappings for Low Speed Networks • RFC 2689 (9/1999): Providing Integrated Services over Low-bitrate Links • RFC 2745 (1/2000): RSVP Diagnostic Messages • RFC 2746 (1/2000): RSVP Operation over IP Tunnels • RFC 2747 (1/2000): RSVP Cryptographic Authentication • RFC 2748 (1/2000): The COPS (Common Open Policy Service) Protocol • RFC 2749 (1/2000): COPS usage for RSVP • RFC 2750 (1/2000): RSVP Extensions for Policy Control • RFC 2752 (1/2000): Identity Representation for RSVP • RFC 2814 (5/2000): Subnet Bandwidth Manager (para RSVP Admis. Ctrl) • RFC 2815 (5/2000): Integrated Service Mappings on IEEE 802 Networks • RFC 2816 (5/2000): A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies • RFC 2872 (6/2000): Appl. and Sub Appl. Ident. Policy Elem. for RSVP • RFC 2961 (4/2001): RSVP Refresh Overhead Reduction Extensions • RFC 2996 (11/2000): Format of the RSVP DCLASS Object • RFC 2998 (11/2000): A Framework for Integarted Services Operation over Diffserv Networks • RFC 3006 (11/2000): Integrated Services in the Presence of Compressible Flows • RFC 3097 (4/2001): RSVP Cryptographic Authentication • RFC 3175 (9/2001): Aggregation of RSVP for IPv4 and IPv6 Reservations • RFC 3182 (10/2001): Identity Representation for RSVP • RFC 3209 (12/2001): RSVP-TE: Extensions to RSVP for LSP Tunnels • RFC 3210 (12/2001): Applicability Statement for Extensions to RSVP for LSP-Tunnels

  38. Sumario • Concepto de Calidad de Servicio • Calidad de servicio en LANs • Calidad de Servicio en Internet • Modelo IntServ y protocolo RSVP • Modelo DiffServ • Control de congestión en Internet • MPLS

  39. Modelo DiffServ (Differentiated Services) • Intenta evitar los problemas de escalabilidad que plantea IntServ/RSVP. • Se basa en el marcado de paquetes únicamente. No hay reserva de recursos por flujo, no hay protocolo de señalización, no hay información de estado en los routers. • Las garantías de calidad de servicio no son tan severas como en IntServ pero en muchos casos se consideran suficientes.

  40. DiffServ • En vez de distinguir flujos individuales clasifica los paquetes en categorías (según el tipo de servicio solicitado). • A cada categoría le corresponde un SLA (Service Level Agreement). Los usuarios pueden contratar o solicitar un determinado caudal en la categoría que deseen. • Los routers tratan cada paquete según su categoría (que viene marcada en la cabecera del paquete). El Policy Control/Admission Control sólo se ha de efectuar en los routers de entrada a la red del proveedor y en los que atraviesan fronteras entre proveedores diferentes (normalmente en las fronteras entre sistemas autónomos).

  41. DiffServ • La información se puede sumarizar fácilmente ya que todos los flujos quedan clasificados en alguna de las categorías existentes. • El número de categorías posibles es limitado e independiente del número de flujos o usuarios; por tanto la complejidad es constante, no proporcional al número de usuarios (decimos que la arquitectura es ‘escalable’, o que ‘escala bien’). • La información de QoS no está en los routers sino que cabalga ‘montada’ en los datagramas.

  42. Cabecera IPv4 antes de DiffServ Cabecera IPv4 con DiffServ (RFC2474, 12/1998)

  43. Campo TOS (obsoleto) Campo TOS X Precedencia D T R C • Precedencia: prioridad (ocho niveles) • D,T,R,C: flags para indicar la ruta que se quiere utilizar: • D: Delay (mínimo retardo) • T: Throughput (máximo rendimiento) • R: Reliability (máxima fiabilidad) • C: Cost (mínimo costo) • X: bit reservado

  44. Campo DS (RFC 2474) DSCP CU • DSCP: Differentiated Services CodePoint. Seis bits que indican el tratamiento que debe recibir este paquete en los routers • CU: Currently Unused (reservado). Este campo se utiliza actualmente para control de congestión Campo DS

  45. Campo DS en IPv6 • El campo DS, con igual longitud y formato que en IPv4, se coloca en IPv6 sustituyendo al campo prioridad (de 4 bits) y a los cuatro primeros bits del campo ‘etiqueta de flujo’ que se reduce de 24 a 20 bits. • Los cambios no produjeron problemas ya que ninguno de los dos campos (prioridad ni etiqueta de flujo) se había utilizado.

  46. Cabecera IPv6 antes de DiffServ (RFC 1883) Cabecera IPv6 con DiffServ (RFC2474, 12/1998)

  47. X Precedencia D T R C DSCP CU Prioridad Etiq. de Flujo (1-4) Aparición del campo DS en IPv4 e IPv6 IPv4 Antes IPv4 e IPv6 Ahora IPv6 Antes Los tres primeros bits se interpretan como prioridad en todos los casos

  48. Campo DS • 6 bits = 64 ‘codepoints’ (categorías de tráfico) diferentes. • De momento se han dividido en 3 grupos: En el grupo estándar los tres primeros bits (xxx) indican la clase

  49. Tipos de Servicio en DiffServ

  50. Reparto de recursos en DiffServ Best Effort sin prioridad Best Effort con prioridad Caudal  Assured Forwarding Expedited Forwarding o Premium Tiempo 

More Related