Capítulo 4. Nuevos Modelos de Internet. Servicios Integrados: Protocolos RSVP

1. Capítulo 4.Nuevos Modelos de Internet.Servicios Integrados:Protocolos RSVP

2. Integrated services (1994): Se utiliza este término para un modelo de servicio Internet que incluye el servicio best-effort, y la reserva de recursos para los servicios en tiempo real [RFC1633]. El usuario solicita de antemano los recursos que necesita; cada router del trayecto ha de tomar nota y efectuar la reserva solicitada. Differentiated services (1997): Este modelo permite asignar diferentes niveles de servicio a diferentes usuarios de Internet. 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 Nuevos Modelos de Internet De verdad lo necesitamos?

3. Nuevos Modelos de Internet.Servicios Integrados:Protocolos RSVP

4. IntServ fue introducido por el IETF en 1994. RFC 1633 Sugiere que la arquitectura actual (más algunas extensiones) es suficiente para proporcionar calidad de servicio. Intento de mezclar lo mejor de los dos paradigmas opuestos: Redes Datagrama: Flexibilidad, multipunto, multiplexación.... Redes Conmutada: Canal garantizado Integrated services

5. Elementos principales Reserva de Recursos Control de Admisión Arquitectura Básica IntServ

6. Para permitir estas funcionalidades se requiere: Especificación del flujo : Una especificación del flujo definiendo el tipo del tráfico, los requerimientos del receptor y la calidad de servicio que se va a proporcionar al flujo. Encaminamiento : La red debe decidir como transportar los paquetes desde la fuente al destino. Por ello se requiere un protocolo de encaminamiento que soporte calidad de servicio y rutas unicast y multicast, Reserva de recursos : Para mantener un flujo con una calidad de servicio se requiere un protocolo de reserva para crear y mantener las reservas de recursos, como el ancho de banda o número de buffers. Control de admisión : Un algoritmo de control de admisión para mantener la carga de la red a un determinado nivel, La comprobación se puede realizar consultando una base de datos mediante el protocolo COPS (Common Open Policy Service) Planificador de paquetes : Un algoritmo de servicio de paquetes para planificar la transmisión de los paquetes con el objetivo de mantener el servicio garantizado para cada flujo. Integrated services (II)

7. El grupo de trabajo Integrated Services del IETF ha considerado la existencia de 3 clases de QoS: Servicios Garantizados (Guaranteed Service) Servicios Controlados (Controlled-Load Service) Best-Effort Integrated services (III)

8. Recogido en la especificación RFC2211 Definición Este servicio proporciona un nivel de ancho de banda y un límite en el retardo, garantizando la no existencia de pérdidas en colas. Está pensado para aplicaciones con requerimientos en tiempo real, tales como ciertas aplicaciones de audio y vídeo. Cada router caracteriza el SG para un flujo específico asignando un ancho de banda y un espacio en buffer Delay. Guaranteed Service

9. Recogido en la especificación RFC2212 Definición A diferencia del SG, este servicio no ofrece garantías en la entrega de los paquetes. Este servicio permite ofrecer QoS a un flujo si la red no está sobrecargada. QoS garantizada de forma estadística. No permite poner límites al delay. Los routers que implementen este servicio deben verificar que el tráfico recibido siga las especificaciones dadas por el Tspec, y cualquier tráfico que no las cumpla será reenviado por la red, como tráfico best-effort. Será adecuado para aquellas aplicaciones que toleren una cierta cantidad de pérdidas y un retardo mantenidos en un nivel razonable. Controlled Load Service

10. Flujos rígidos (tiempo real) Flujos adaptativos (tiempo real) Flujos elásticos (datos) Aplicaciones

11. Aplicaciones de tiempo Real Aplicaciones interactivas que son sensibles al retardo (telefonía) Aplicaciones no interactivas que, debido a su configuración, permiten una mayor flexibilidad a un amplio rango de retardo (audio, vídeo Broadcast) Aplicaciones en las que es necesario garantizar el máximo retardo (ej. juegos en red) Requerimientos de QoS Gráfico de llegada Captura de Audio El buffer deberá ser pequeño para evitar retrasos Punto de audición

12. Aplicaciones Elásticas Transferencias de ficheros (e.g. HTTP, FTP) Sensible a retardo, pero no a la pérdida de datos Transferencias de datos (e.g. mail y news) Insensible a retrasos Best effort trabaja bien Requerimientos de QoS Los documentos son útiles si están completamente recivido. Por tanto el valor medio será lo importante Document Document

13. RSVP (ReSerVation Protocol) El protocolo paradigma de Intserv Protocolo de señalización genérica, transporta los distintos objetos de descripción de QoS 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. Dos mensajes RSVP fundamentales, Resv y Path La calidad se realiza a petición del cliente y por flujo. Si no se pueden asegurar las condiciones pedidas se rechaza la llamada (control de admisión) RSVP

14. Paquetes equivalentes para alguna clasificación RSVP: define los paquetes que van a atravesar los distintos elementos de la red y que van a ser cubiertos por una determinada QoS El clasificador de paquetes de cada elemento de red determina qué paquetes son de cada tipo de flujo. 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. ¿Qué es un flujo?

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

16. 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. Identificación de flujos

17. 2 PATH PATH 1 3 PATH PATH 1. Una aplicación en Host A genera una sesión con 128.32.32.69/4078, communicándoselo a el demonio de RSVP en Host A. 3. El mensaje PATH continua hasta el destino pasando por los nodos R5 y R4 hasta alcanzar el Host B. Cada router genera un estado de sesión con los parámetros de reservas. 2. El dominio RSVP del Host A envía un mensaje PATH al siguiente salto en el camino RSVP router, R1, en la dirección de la sesión destino, 128.32.32.69. RSVP Reserva UDP (1) R2 R3 R4 R1 Host B 128.32.32.69 Host A 24.1.70.210 R5

18. 4 RESV 5 RESV RESV 6 RESV 4. La aplicación en el Host B se comunica con el demonio RSVP y pide la reserva de recursos para la sesión 128.32.32.69/4078. El demonio chequea si existe ya un estado de reserva existente. 6. El mensaje RESV continua el camino generado antriormente a través de R5 y R1 hasta alcanzar Host A. Cada router en el path realiza la reserva de recursos. 5. El demonio RSVP del Host B envía un mensaje RESV que es enviadohasta el siguiente RSVP router, R4, en la dirección de de origen, 24.1.70.210. RSVP Reserva UDP (2) R2 R3 R4 PATH R1 PATH Host B 128.32.32.69 PATH PATH Host A 24.1.70.210 R5

19. RSVP Reserva Multicast (1) Sender R1 R2 R3 R4 R5 R6 R7 Receiver

20. PATH PATH PATH PATH PATH PATH PATH PATH PATH RSVP Reserva Multicast (2) Sender R1 R2 R3 R4 R5 R6 R7 Receiver

21. 2 tipos de mensajes: PATH y RESV Mensaje PATH (downstream) Distribuye la información del origen Recolecta información del camino (PATH) Instala el estando en cada uno de los elementos de red Mensaje RESV (upstream) Sigue el camino reservado por el mensaje PATH Especifica los requerimientos del origen Realiza el acto efectivo de reserva. Permite la reserva mediante fusión de flujos (Merging) Tanto el origen como el destino están notificados de los cambios en el path Modo de funcionamiento

22. Son mandados en elementos como datagramas IP (protocolo Id 46) Puede ser también enviado encapsulado en UDP (normalmente se usa en los sistemas finales) Son tratados como paquetes de control Existen paquetes constantes de refresco Mensajes RSVP

23. Phop, La dirección del último nodo RSVP con objetivo de enviarle a la vuelta el mensaje resv . Esta dirección es actualizada en cada salto. Sender Template, un filtro que identifica la dirección IP origen, este objeto contiene opcionalmente la dirección del puerto origen (en IPv6 la etiqueta de flujo puede ser usada en vez del puerto de origen). Sender Tspec define las características del tráfico que se está enviando. Adspec (Opcional) contiene OPWA (One Pass with Advertising) es actualizado por cada router RSVP del path. Este objeto posee información sobre los parámetros del camino generado para permitir a los routers ajustar correctamente la reserva de recurso de red. Además informa si existe algún nodo de la red no tiene soporte de RSVP. Mensajes RSVP (PATH)

24. Servicios Garantizados TSpec: Descripción del Tráfico (Cubo) Rspec: Especificación del Servicio Parámetros de Tráfico

25. Estilo de Reserva Flow spec and filter Spec (descriptor de flujo) Flowspec define los parámetros de traffico Parámetros de Tráfico: Mínimo Ancho de Banda Delay (retardo): peor caso admisible Delay Jitter: Diferencia entre el mayor y menor delay esperado Se usa el modelo de Token Bucket Service Class RSpec TSpec Filterspec identifica los paquetes de cada flujo Simplest filter: dirección Origen y Destino/pareja de puertos Data filter: classifica los datos por el contenido Mensajes RSVP (RESV)

26. RSVP Flowspecs Sender TSpec, Controlled Load Flowspec . . . Token Bucket Rate [r] Token Bucket Size [b] Peak Data Rate [p] Minimum Policed Unit [m] Maximum Policed Unit [M] Guaranteed Flowspec . . . Token Bucket Rate [r] Token Bucket Size [b] Peak Data Rate [p] Minimum Policed Unit [m] Maximum Policed Unit [M] Rate [R] Slack Term [S]

27. Wildcard Filter (WF) Comparte la reserva entre todos los emisores Se reserva el máximo de los recursos pedido Apropiada por el audio Shared Explicit (SE) Comparte la reserva entre un grupo determinado de emisores Apropiada por el audio Fixed Filter (FF) Estricta reserva para cada uno de los emisores Apropiada para el vídeo Estilos de Reserva

28. RSVPD Routing Process Application Policy Control Policy Control Admissions Control Admissions Control Packet Classifier Packet Scheduler Packet Classifier Packet Scheduler RSVP Diagrama Funcional Host Router RSVPD D A T A DATA DATA

29. RSVP produjo una euforia inicial (1996-1997) que luego dio 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. Problemas de IntServ/RSVP

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

31. El routing se encuentra de forma separada del control de admisión. Si una ruta cambia, la reserva debe de realizarse por la nueva ruta. La nueva reserva necesita tiempo para generarse La nueva reserva puede fallar La vieja ruta puede estar bien y manteniendo la reserva La ruta se mantiene con fuerza Siempre usa la ruta donde se ha realizado la reserva. Fallo en la primera ruta no existe alternativa. ATM y MPLS poseen la integración del Control de admisión y el routing RSVP Problemas de Routing

32. 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 Problemas de IntServ/RSVP

33. Cisco router tiene soporte de RSVP. RSVP daemon disponible USC ISI Solaris, BSD Net, linux Windows 2000 y superiores Implementaciones actuales de RSVP

34. Algunas características o aspectos fundamentales en el RSVP son: Merging: En los diferentes nodos que se van atravesando en la red por el camino de datos, se va realizando un proceso de concentración de los diferentes mensajes de petición de reservas Estado de reserva en cada nodo: El estado soft RSVP se crea y refresca periódicamente por mensajes Path y Resv. Estilos de reserva: Una petición de reserva incluye un conjunto de opciones que se conocen como el estilo de reserva. Las distintas combinaciones de estas opciones conforman los tres estilos de reserva en uso, Wildcar-Filter (WF), Fixed-Filter (FF) y Shared-Explicit (SE). Aspectos fundamentales

35. El problema de la escalabilidad existe, dada la gran cantidad de señalización que aparecerá conforme la red vaya aumentando de tamaño, tanto en cuanto a rutas como en cuanto a usuarios. El routing conlleva un problema, dado que el proceso de encaminamiento se realiza en el instante de establecer la sesión y enviar el mensaje Path. En este punto, los algoritmos de encaminamiento utilizados no tienen en cuenta cuáles van a ser las características de reserva solicitadas por el receptor, con lo cual puede que la decisión adoptada para establecer la ruta, no sea la más adecuada teniendo en cuenta sólo los parámetros de caracterización del tipo de QoS elegido. La certeza de que la ruta establecida podrá contener dispositivos intermedios que no implementen el protocolo RSVP, hará que la reserva extremo a extremo esté condicionada por dichos sistemas. Conclusiones

36. 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 RFCs sobre IntServ/RSVP