Protocolo de reserva de recursos (RSVP)

El Protocolo de reserva de recursos o RSVP (Resource Reservation Protocol) es un protocolo de capa de transporte diseñado para reservar recursos a través de una red utilizando el modelo de servicios integrados. RSVP opera sobre IPv4 o IPv6 y proporciona una configuración iniciada por el receptor de reservas de recursos para flujos de datos de multidifusión o unidifusión. No transporta datos de aplicaciones, pero es similar a un protocolo de control, como el Protocolo de mensajes de control de Internet (ICMP) o el Protocolo de administración de grupos de Internet (IGMP). RSVP se describe en RFC 2205.

RSVP puede ser utilizado por hosts y enrutadores para solicitar o entregar niveles específicos de calidad de servicio (QoS) para flujos de datos de aplicaciones. RSVP define cómo las aplicaciones hacen reservas y cómo pueden renunciar a los recursos reservados una vez que ya no se necesitan. Las operaciones de RSVP generalmente darán como resultado que se reserven recursos en cada nodo a lo largo de una ruta. RSVP no es un protocolo de enrutamiento, pero se diseñó para interactuar con los protocolos de enrutamiento actuales y futuros.

RSVP por sí solo rara vez se implementa en redes de telecomunicaciones. En 2003, el esfuerzo de desarrollo pasó de RSVP a RSVP-TE para la ingeniería de teletráfico. Next Steps in Signaling (NSIS) fue un reemplazo propuesto para RSVP.

Atributos principales

1. RSVP solicita recursos para flujos símplex: un flujo de tráfico en una sola dirección desde el remitente a uno o más receptores.
2. RSVP no es un protocolo de enrutamiento, pero funciona con protocolos de enrutamiento actuales y futuros.
3. RSVP está orientado al receptor en el sentido de que el receptor de un flujo de datos inicia y mantiene la reserva de recursos para ese flujo.
4. RSVP mantiene el estado suave (la reserva en cada nodo necesita una actualización periódica) de las reservas de recursos del host y los enrutadores, por lo que admite la adaptación automática dinámica a los cambios de la red.
5. RSVP proporciona varios estilos de reserva (un conjunto de opciones de reserva) y permite que se agreguen estilos futuros en revisiones de protocolo para adaptarse a diversas aplicaciones.
6. RSVP transporta y mantiene parámetros de control de políticas y tráfico que son opacos para RSVP.

Historia y estándares relacionados

Los conceptos básicos de RSVP se propusieron originalmente en 1993.

RSVP se describe en una serie de documentos RFC del IETF:

• RFC 2205: La especificación funcional de la versión 1 fue descrita en RFC 2205 (septiembre de 1997) por IETF. La versión 1 describe la interfaz para el control de admisión (tráfico) que se basa "únicamente" en la disponibilidad de recursos. Más tarde, RFC2750 amplió el soporte de control de admisión.
• RFC 2210 define el uso de RSVP con RFC 2211 de carga controlada y servicios de control QoS RFC 2212 garantizados. Más detalles en Servicios Integrados. También define el uso y el formato de datos de los objetos de datos (que llevan información de reserva de recursos) definidos por RSVP en RFC 2205.
• RFC 2211 especifica el comportamiento del elemento de red requerido para brindar servicios de carga controlada.
• RFC 2212 especifica el comportamiento del elemento de red requerido para brindar servicios QoS garantizados.
• RFC 2750 describe una extensión propuesta para admitir el control de admisión basado en políticas genéricas en RSVP. La extensión incluía una especificación de objetos de política y una descripción sobre el manejo de eventos de política. (enero de 2000).
• RFC 3209, "RSVP-TE: Extensiones de RSVP para túneles LSP" (diciembre de 2001).
• RFC 3473, "Extensiones del Protocolo de reserva de recursos de señalización - Ingeniería de tráfico (RSVP-TE) de conmutación de etiquetas multiprotocolo generalizado (GMPLS)" (enero de 2003).
• RFC 3936 , "Procedimientos para modificar el protocolo de reserva de recursos (RSVP)" (octubre de 2004), describe las mejores prácticas actuales y especifica los procedimientos para modificar RSVP.
• RFC 4495, "Extensión del protocolo de reserva de recursos (RSVP) para la reducción del ancho de banda de un flujo de reserva" (mayo de 2006), amplía RSVP para permitir que se reduzca el ancho de banda de una reserva existente en lugar de eliminar la reserva.
• RFC 4558, "Protocolo de reserva de recursos basado en ID de nodo (RSVP) Hola: una declaración de aclaración" (junio de 2006).

Conceptos clave

Los dos conceptos clave del modelo de reserva RSVP son flowspec y filterspec.

Especificaciones de flujo

RSVP reserva recursos para un flujo. Un flujo se identifica por la dirección de destino, el identificador de protocolo y, opcionalmente, el puerto de destino. En la conmutación de etiquetas multiprotocolo (MPLS), un flujo se define como una ruta de conmutación de etiquetas (LSP). Para cada flujo, RSVP también identifica la calidad de servicio (QoS) particular requerida por el flujo. Esta información de QoS se denomina especificación de flujo y RSVP pasa la especificación de flujo desde la aplicación a los hosts y enrutadores a lo largo de la ruta. Esos sistemas luego analizan el flowspec para aceptar y reservar los recursos. Una especificación de flujo consta de:

1. clase de servicio
2. Especificación de reserva: define la QoS
3. Especificaciones de tráfico: describe el flujo de datos

Especificación de filtro

La especificación de filtro define el conjunto de paquetes que se verán afectados por una especificación de flujo (es decir, los paquetes de datos para recibir la QoS definida por la especificación de flujo). Una especificación de filtro normalmente selecciona un subconjunto de todos los paquetes procesados ​​por un nodo. La selección puede depender de cualquier atributo de un paquete (por ejemplo, la dirección IP y el puerto del remitente).

Los estilos de reserva de RSVP definidos actualmente son:

1. Filtro fijo: reserva recursos para un flujo específico.
2. Compartido explícito: reserva recursos para varios flujos y todos comparten los recursos
3. Filtro comodín: reserva recursos para un tipo general de flujo sin especificar el flujo; todos los flujos comparten los recursos

Una solicitud de reserva de RSVP consta de una especificación de flujo y una especificación de filtro, y el par se denomina descriptor de flujo. El flowspec establece los parámetros del planificador de paquetes en un nodo y el filterspec establece los parámetros en el clasificador de paquetes.

Mensajes

Hay dos tipos principales de mensajes:

• Mensajes de ruta (ruta)

El mensaje de la ruta se envía desde el host del remitente a lo largo de la ruta de datos y almacena el estado de la ruta en cada nodo a lo largo de la ruta.El estado de la ruta incluye la dirección IP del nodo anterior y algunos objetos de datos:

1. plantilla de remitente para describir el formato de los datos del remitente en forma de Filterspec
2. sender tspec para describir las características de tráfico del flujo de datos
3. adspec que transporta datos publicitarios (consulte RFC 2210 para obtener más detalles).

• Mensajes de reserva (resv)

El mensaje resv se envía desde el receptor al host emisor a lo largo de la ruta de datos inversa. En cada nodo, la dirección IP de destino del mensaje resv cambiará a la dirección del siguiente nodo en el camino inverso y la dirección IP de origen a la dirección del nodo anterior en el camino inverso.El mensaje resv incluye el objeto de datos flowspec que identifica los recursos que necesita el flujo.

Los objetos de datos en los mensajes RSVP se pueden transmitir en cualquier orden. Para obtener la lista completa de mensajes RSVP y objetos de datos, consulte RFC 2205.

Operación

Un host RSVP que necesita enviar un flujo de datos con QoS específico transmitirá un mensaje de ruta RSVP cada 30 segundos que viajará a lo largo de las rutas de unidifusión o multidifusión preestablecidas por el protocolo de enrutamiento de trabajo. Si el mensaje de ruta llega a un enrutador que no comprende RSVP, ese enrutador reenvía el mensaje sin interpretar el contenido del mensaje y no reservará recursos para el flujo.

Aquellos que quieren escucharlos envían un mensaje resv (abreviatura de reserva) correspondiente que luego rastrea el camino de regreso al remitente. El mensaje resv contiene un flowspec. El mensaje resv también tiene un objeto filterspec; define los paquetes que recibirán la QoS solicitada definida en el flowspec. Una especificación de filtro simple podría ser solo la dirección IP del remitente y, opcionalmente, su puerto UDP o TCP. Cuando un enrutador recibe el mensaje RSVP resv:

1. Realiza una reserva en base a los parámetros de la solicitud. El control de admisión procesa los parámetros de la solicitud y puede instruir al clasificador de paquetes para que maneje correctamente el subconjunto seleccionado de paquetes de datos o negociar con la capa superior cómo se debe realizar el manejo de paquetes. Si no se admite, se envía un mensaje de rechazo para informar al oyente.
2. Reenviar la solicitud aguas arriba (en la dirección del remitente). En cada nodo, la especificación de flujo en el mensaje resv puede modificarse mediante un nodo de reenvío (por ejemplo, en el caso de una reserva de flujo de multidifusión, las solicitudes de reserva pueden fusionarse).
3. Luego, los enrutadores almacenan la naturaleza del flujo y, opcionalmente, configuran la vigilancia de acuerdo con la especificación de flujo para él.

Si no se escucha nada durante un cierto período de tiempo, la reserva expirará y se cancelará. Esto resuelve el problema si el remitente o el receptor fallan o se apagan sin cancelar primero la reserva.

Otras características

IntegridadLos mensajes de RSVP se adjuntan con un resumen de mensaje creado al combinar el contenido del mensaje y una clave compartida usando un algoritmo de resumen de mensaje (comúnmente MD5). La clave se puede distribuir y confirmar mediante dos tipos de mensajes: solicitud de desafío de integridad y respuesta de desafío de integridad.Error al reportarCuando un nodo detecta un error, se genera un mensaje de error con un código de error y se propaga aguas arriba en la ruta inversa al remitente.Información sobre el flujo de RSVPDos tipos de mensajes de diagnóstico permiten que un operador de red solicite la información de estado de RSVP en un flujo específico.Instalación de diagnósticoUna extensión del estándar que permite a un usuario recopilar información sobre el estado de RSVP a lo largo de una ruta.

RFC

• RFC 2205
• RFC 2210
• RFC 2211
• RFC 2212