RSVP ( Resource Reservation Protocol)

1. RSVP (Resource Reservation Protocol) Seminario de Redes de Alta Velocidad Junio 2006 Tomás Urra Baumgartner

2. Introducción • QoS en Internet • 2 Enfoques: • Servicios Diferenciados. • Servicios Integrados. • Servicios Diferenciados: • Diferenciar cada paquete para dar mejor trato. • Servicios Integrados: • Disponer de una sola red que transporte tráfico “best effort” y flujos con requisitos de Qos. • Basado en la reserva de recursos para flujos de datos individuales.

3. Introducción • Principio: • Establecer circuito virtual de principio a fin, con garantía de recursos establecidas. • Existe una fase inicial, donde se establece el circuito virtual, y se reservan los recursos.

4. Introducción • Componentes de los Servicios Integrados: • Caracterización de tráfico y estimación de recursos requeridos. • Protocolo de control de admisión para encontrar ruta que satisfaga los requerimientos de recursos. • Una correcta clasificación de paquetes y planificación para cumplir con las reservas especificadas. • Conformación de tráfico y policiamiento para que no se sobrepasen las reservas efectuadas. • Protocolo de Reserva (RSVP) para establecer efectivamente las reservas sobre las rutas seleccionadas.

5. Introducción RSVP • RSVPfue diseñado para ser el protocolo de señalización que activa la reserva de recursos de los Servicios Integrados en los routers y hosts. • RSVPpretende proporcionar QoS estableciendo una reserva de recursos para un flujo determinado. • Es un diálogo entre emisor, receptor y elementos de red con el fín de reservar recursos para una aplicación.

6. Objetivos RSVP • Que los receptores puedan realizar reservas específicas según sus necesidades. • Especificar los recursos requeridos para cada flujo de datos. • Tratar los cambios en las rutas entre un emisor y un receptor de manera independiente al protocolo de encaminamiento.

7. Características del RSVP • Permite la reserva de recursos para mensajes Unicast y Multicast. • No es un protocolo de encaminamiento, sino que está pensado para trabajar conjuntamente con éstos. • Los protocolos de encaminamiento determinan dónde se envían los paquetes mientras que RSVP se preocupa por la QoS de los paquetes envíados de acuerdo con el encaminamiento.

8. Características del RSVP • Es un protocolo símplex: petición de recursos sólo en una dirección, diferencia entre emisor y receptor. • El intercambio entre dos sistemas finales requiere de reservas diferenciadas en ambas direcciones. • La reserva es orientada al receptor. • Se crean estados de reserva de recursos (soft state) en cado nodo por donde transitan los flujos de datos. El mantenimiento del “estado de la reserva” se realiza periódicamente por los usuarios finales. • Permite diferentes tipos de reservas. • Protocolo transparente para los routers no RSVP.

9. MIME BGP FTP TELNET HTTP SMTP SNMP UDP TCP ICMP OSPF RSVP IP Características del RSVP

10. ¿Quién utiliza RSVP? • Un Host (extremo): para solicitar la QoS a una red para un flujo de datos o una aplicación particular. • Un Router: para repartir peticiones de QoS a todos los routers vecinos del camino por donde pasa el flujo de datos. Router • Una petición de recursos implicará generalmente una reserva de éstos en todos los nodos del camino del flujo de datos.

11. Mecanismo de Funcionamiento • Mensajes dePath (generados por el emisor): • Describe carácteristicas del tráfico del usuario. • Indica rutas por donde se debe solicitar reservas de recursos. • Mensajes deResv (generados por el receptor): • Solicitan las de reserva de recursos. • Crean el “estado de la reserva” (soft state)en los routers.

12. Mecanismo de Funcionamiento

13. Conceptos RSVP • Sesión RSVP: es un flujo de datos para el que se ha requerido reserva de recursos, identificado por su destino y por un protocolo de transporte particular. Sus componentes son: • Dirección IP destino: dirección IP destino de los paquetes (unicast o multicast) • Identificador del protocolo IP transporte. • Puerto destino (opcional). • Descriptor de flujo:se llama así a una petición de reserva realizada por un sistema final. Está compuesto de: • Flowspec: especifica la calidad de servicio deseada. Incluye: • Dos parámetros numéricos: Rspec, que define espicifaciones de reserva requerida(Reserve) y Tspec, que describe el flujo de datos del emisor (Traffic) • Especificación de filtro(filter spec): Definelos paquetes de datos que reciben la QoS especificada en el flowspecs.

14. Control deTráfico Encaminador: Se encarga de las labores de encaminamiento, decide cuál es el siguiente salto para cada uno de las direcciones destino y cada flujo en particular. Control de tráfico:Mecanismos que implementan la QoS para un flujo determinado. Control de Admisión: Se encarga de decidir si existen recursos disponibles para un flujo, teniendo en cuenta la QoS que este solicita. Emisor RSVP Clasificador: Estructura en clases de servicio los paquetes entrantes.Una clase puede ser un solo flujo o un conjunto de flujos con los mismos requerimientos de QoS. Policy Control Admision Control Planificador: Gestiona una o más colas de servicio para cada puerto de salida, determinando el orden en que los paquetes son distribuidos por las mismas y el orden en que serán transmitidos. También se encarga de seleccionar los paquetes a descartar en caso de que sea necesario. Policiamiento: Se encarga de comprobar los permisos administrativos de los usuarios cuando realizan las reservas. Gestiona las políticas de control. Packet Classifier Packet Scheduler Receptor

15. Establecimiento de Conexión La solicitud es aceptada. Los paquetes son enviados al clasificador de paquetes para obtener las especificaciones de reservación de recursos y QoS requerida Emisor PATH PATH RESV OK Router PATH RESV OK Router RESV OK Receptor

16. RED NODO EMISOR RECEPTOR Aplicación 1 Aplicación Función Control Reserva 3 API API RSVP RSVP Flowspec Tspec Adspec 4 5 2 Path Path 6 Tspec Tspec Adspec Adspec Flowspec Flowspec Resv Resv Funcionamieno RSVP El Nodo evalúa el mensaje PATH: ADSPEC: Si el nodo no implementa el servicio QoS  Break bit=1. SENDER_TSPEC: parámetros flujo de datos del emisor Se asigna a PATH_MTU  min(MTU) del nodo La aplicación solicita una sesión RSVP. Mensaje Path en receptor. Se interpretan los parámetros de ADSPEC y SENDER_TSPEC La aplicación entrega a RSVP el Rspec (define la QoS deseada, Reserve) y se ajusta el parámetro Tspec(M) (describe el flujo de datos, Traffic) con el tamaño mínimo de paquete aceptado en los routers a lo largo del camino min(PATH_MTU). SENDER_TSPEC. Es un objeto RSVP que se genera haciendo uso del parámetro Tspec. Contiene los parámetros del flujo de datos del emisor. ADSPEC. Es un objeto RSVP que contiene información de control de tráfico. El parámetro PATH_MTU. Este parámetro se utiliza para determinar el tamaño máximo del paquete a manejar. Mensaje Resv al emisor. Incluye el objeto RSVP denominado FLOWSPEC(QoS) que se estructura a partir de la información del flowspec, el SENDER_TSPEC y el ADSPEC.

17. Funcionamiento RSVP • Cuando un receptor origina una petición de reserva también puede solicitar un mensaje de confirmación, para indicar que su petición de reserva, probablemente se habrá instalado a la red. • Una petición de reserva se propaga por la red hasta que encuentra un punto en el que existe una reserva igual o superior. • En este punto la petición se concentra con la existente, no propagándose más.

18. Funcionamiento RSVP • SOFTSTATE: • El “estado de la reserva” (soft state) se crea y periódicamente se refresca por mensajes Path y Resv. • El estado se elimina si antes de un timeout no se recibe un mensaje de refresco. También puede eliminarse por un mensaje “Teardown”. • Cuando una ruta varía, el siguiente mensaje Path, incluirá esta variación en la ruta, y el próximo mensaje Resv, establecerá el nuevo estado de reserva. • El estado del RSVP es dinámico, permitiendo cambiar en cualquier momento la QoS deseada.

19. Funcionamiento RSVP • TEARDOWN: • Estos mensajes eliminan el estado path o el estado de reserva inmediatamente. • Dos tipos: • Path Tear: va hacia todos los receptores desde el punto de inicio eliminando el estado del path • Resv Tear: va hacia los emisores desde el punto de inicio eliminando el estado de reserva

20. Funcionamiento RSVP • Los puede generar: • una aplicación en un extremo al finalizar. • un nodo (router) como resultado de un timeout. • Una vez iniciado se ha de propagar por los nodos paso a paso. • Si un nodo no recibe un mensaje teardown porque lo ha perdido, después de un timeout iniciará un nuevo mensaje teardown.

21. Estilos de Reserva • Estilo de reserva:es un conjunto de opciones que incluyen una petición de reserva. Las opciones son: • Relativa al tratamiento de reservas para diferentes emisores en la misma sesión: • Distinc : establece una reserva diferente para cada emisor • Shared: hace una única reserva compartida para todos los paquetes de los emisores seleccionados • Relativa a la selección de los emisores: • Explicit: puede ser una lista explícita de todos los emisores seleccionados (en este caso, cada filter spec se apareja con un emisor) • Wildcard o comodin: puede ser una wildcard que seleccione todos los emisores de una sesión (no se necesita filter spec).

22. Estilos de Reserva • Determinan como los Routers intermedios deben agrupar las solicitudes de reserva de los receptores en el mismo grupo multicast. • Hay 3 estilos de Reservas: • 1. Wildcard: Todos los receptores comparten una reserva,cuyo tamaño es el mayor de las solicitudes de recursos de los receptores. Todos los emisores peden usar recursos reservados. • 2. Fixed-Filter: Sólo el emisor o emisores especificados en este tipo de reserva, pueden usar los recursos reservados. • 3. Shared Explicit: Se crea una reserva única compartida por los emisores seleccionados.

23. Resv router receptor ResvErr Path emisor router PathErr Errores en RSVP Dos mensajes de error: ResvErr : • se genera cuando existe un error al solicitar la reserva en un nodo. • se envía hacia al receptor(es) PathErr: • se genera cuando existe un error en la creación de un Path • se envía hacia al emisor del Path, indicando: • tipo de error • IP del nodo que ha detectado el error

24. Confirmación de Reserva • Para solicitar una confirmación de la petición de reserva el receptor incluye en el mensaje Resv un objeto con su dirección IP. • Si se acepta la petición se envía un mensaje ResvConfinmediatamente • En este caso ResvConf es una confirmación extremo a extremo.

25. Redes No RSVP • RSVP tiene que suministrar funcionamiento correcto para dos nodos que están interconectados por una red arbitraria o por routers no RSVP. • Una red intermedia no RSVP no puede realizar la reserva de recursos. • Cuando un mensaje Path pasa por una red no RSVP lleva hacia al siguiente nodo RSVP la dirección IP del último nodo RSVP antes de cruzar la zona no RSVP.

26. Redes No RSVP

27. Msg_Type: tipo de mensaje • 1:Path • 2:Resv • 3:Path_Err • 4:Resv_Err • 5:PathTear • 6:ResvTear • 7:RescConf Formatos de los mensajes Vers: versión del protocolo Suma de verificacion, si 0...0 no existe checksum Flags: no definido tipo de objeto valor definido desde que el mensaje fue enviado Formato de la cabecera RSVP length: longitud total del mensaje incluyendo cabecera común y objetos Identifica la clase del objeto Flowspec: define la QoS deseada en un Resv. Adspec: trae datos OPWA en un Path. Resv_Conf: lleva la dirección IP del receptor que solicita una confirmación. En ResvConf o Resv longitud total del objeto en bytes Formato de los objetos

28. Resumen • RSVP es un protocolo de control de red que le permite a las aplicaciones de Internet obtener diferentes calidades de servicio (QoS) para sus flujos de datos. • RSVP no es un protocolo de enrutamiento, trabaja en conjunto con ellos. • Es un protocolo símplex: petición de recursos sólo en una dirección, diferencia entre emisor y receptor. El intercambio entre dos sistemas finales requiere de reservas diferenciadas en ambas direcciones. • Protocolo transparente para los routers no RSVP.

29. Bibliografía • RFC 2205: Resource ReserVation Protocol -- Funtional Specification. • RFC 2210: The Use os RSVP with IETF Integrated Services. • RFC 2211: Specification of the Controlled-Load Network Element Service. • RFC 2212: Specification of Guaranteed Quality of Service. • RFC 2215: General Characterization Parameters for Integrated Service Network Elements • http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/rsvp.htm • Presentación Christian Bravo, Servicios Integrados y RSVP