RSVP Resource Reservation Protocol Seminario de Redes de

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

Introducción l Qo. S en Internet l 2 Enfoques: ¡ ¡ l Servicios Diferenciados: ¡ l Servicios Diferenciados. Servicios Integrados. 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.

Introducción l Principio: l 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. l

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

Introducción RSVP • RSVP fue 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. • RSVP pretende proporcionar Qo. S 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.

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.

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 Qo. S de los paquetes envíados de acuerdo con el encaminamiento.

Características del RSVP l Es un protocolo símplex: petición de recursos sólo en una dirección, diferencia entre emisor y receptor. Ø l • 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. l Permite diferentes tipos de reservas. l Protocolo transparente para los routers no RSVP.

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

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

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

Mecanismo de Funcionamiento

Conceptos RSVP l 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: ¡ ¡ ¡ l Descriptor de flujo: se llama así a una petición de reserva realizada por un sistema final. Está compuesto de: ¡ l Dirección IP destino: dirección IP destino de los paquetes (unicast o multicast) Identificador del protocolo IP transporte. Puerto destino (opcional). Flowspec: especifica la calidad de servicio deseada. Incluye: l 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): Define los paquetes de datos que reciben la Qo. S especificada en el flowspecs.

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

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

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

Funcionamiento RSVP l 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. l Una petición de reserva se propaga por la red hasta que encuentra un punto en el que existe una reserva igual o superior. l En este punto la petición se concentra con la existente, no propagándose más.

Funcionamiento RSVP l SOFTSTATE: l El “estado de la reserva” (soft state) se crea y periódicamente se refresca por mensajes Path y Resv. l El estado se elimina si antes de un timeout no se recibe un mensaje de refresco. También puede eliminarse por un mensaje “Teardown”. l 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. l El estado del RSVP es dinámico, permitiendo cambiar en cualquier momento la Qo. S deseada.

Funcionamiento RSVP l TEARDOWN: Estos mensajes eliminan el estado path o el estado de reserva inmediatamente. l Dos tipos: l ¡ ¡ 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

Funcionamiento RSVP l Los puede generar: ¡ ¡ l l 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.

Estilos de Reserva l 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: l l ¡ 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: l l 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).

Estilos de Reserva l Determinan como los Routers intermedios deben agrupar las solicitudes de reserva de los receptores en el mismo grupo multicast. l 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.

Errores en RSVP Dos mensajes de error: Resv. Err : • • se genera cuando existe un error al solicitar la reserva en un nodo. se envía hacia al receptor(es) router Resv receptor Resv. Err Path. Err: • • 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 emisor Path. Err router

Confirmación de Reserva l 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. l Si se acepta la petición se envía un mensaje Resv. Conf inmediatamente l En este caso Resv. Conf es una confirmación extremo a extremo.

Redes No RSVP l RSVP tiene que suministrar funcionamiento correcto para dos nodos que están interconectados por una red arbitraria o por routers no RSVP. l Una red intermedia no RSVP no puede realizar la reserva de recursos. l 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.

Redes No RSVP

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

Resumen l RSVP es un protocolo de control de red que le permite a las aplicaciones de Internet obtener diferentes calidades de servicio (Qo. S) para sus flujos de datos. l RSVP no es un protocolo de enrutamiento, trabaja en conjunto con ellos. l 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. l Protocolo transparente para los routers no RSVP.

Bibliografía l RFC 2205: 2205 Resource Reser. Vation Protocol -- Funtional Specification. l RFC 2210: 2210 The Use os RSVP with IETF Integrated Services. l RFC 2211: 2211 Specification of the Controlled-Load Network Element Service. l RFC 2212: Specification of Guaranteed Quality of Service. l l l RFC 2215: 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