Protocolo de reserva de recursos

El Protocolo de reserva de recursos ( RSVP ) es un protocolo de capa de transporte ^[1] diseñado para reservar recursos en 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 aplicación, 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.

Los hosts y enrutadores pueden utilizar RSVP para solicitar o entregar niveles específicos de calidad de servicio (QoS) para flujos de datos de aplicaciones . RSVP define cómo las aplicaciones realizan reservas y cómo pueden renunciar a los recursos reservados una vez que ya no son necesarios. Las operaciones RSVP generalmente darán como resultado la reserva de recursos en cada nodo a lo largo de una ruta. RSVP no es un protocolo de enrutamiento , pero fue diseñado para interoperar con protocolos de enrutamiento actuales y futuros.

En 2003, el esfuerzo de desarrollo se trasladó de RSVP a RSVP-TE para la ingeniería de teletráfico . Next Steps in Signaling (NSIS) fue un reemplazo propuesto para RSVP.

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (October 2019) (Learn how and when to remove this message)

1. RSVP solicita recursos para flujos simplex : 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 flexible (la reserva en cada nodo necesita una actualización periódica) de las reservas de recursos del host y de los enrutadores, 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 agregar estilos futuros en revisiones de protocolo para adaptarse a diversas aplicaciones.
6. RSVP transporta y mantiene parámetros de control de tráfico y políticas que son opacos para RSVP. ^{[ se necesita más explicación ]}

Los conceptos básicos de RSVP se propusieron originalmente en 1993. ^[2]

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 "solamente" en la disponibilidad de recursos. Posteriormente, RFC 2750 amplió el soporte de control de admisión.
• RFC 2210 define el uso de RSVP con servicios de control de calidad de servicio (QoS) de carga controlada RFC 2211 y 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 necesario para prestar servicios de carga controlada.
• RFC 2212 especifica el comportamiento de los elementos de red necesario para ofrecer servicios de calidad de servicio garantizados.
• RFC 2750 describe una extensión propuesta para soportar 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íticas y una descripción sobre el manejo de eventos de políticas. (Enero de 2000).
• RFC 3209, "RSVP-TE: Extensiones a RSVP para túneles LSP" (diciembre de 2001).
• RFC 3473, "Extensiones de ingeniería de tráfico (RSVP-TE) del protocolo de reserva de recursos de señalización de conmutación de etiquetas multiprotocolo generalizada (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 el RSVP.
• RFC 4495, "Una 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), extiende 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 aclaratoria" (junio de 2006).

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

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 conmutada por etiquetas (LSP). Para cada flujo, RSVP también identifica la calidad de servicio (QoS) particular que requiere 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. Luego, esos sistemas analizan la especificación de flujo para aceptar y reservar los recursos. Una especificación de flujo consta de:

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

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 que recibirán la calidad de servicio 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 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 RSVP consta de una especificación de flujo y una especificación de filtro , y el par se denomina descriptor de flujo . La especificación de flujo establece los parámetros del programador de paquetes en un nodo y la especificación de filtro establece los parámetros en el clasificador de paquetes.

Hay dos tipos principales de mensajes:

• Mensajes de ruta ( ruta )

El mensaje de ruta se envía desde el host 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 ^[3]
2. tspec del remitente para describir las características del 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 la ruta inversa y la dirección IP de origen a la dirección del nodo anterior en la ruta inversa.

El mensaje resv incluye el objeto de datos flowspec que identifica los recursos que necesita el flujo.

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

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

Aquellos que quieran escucharlos envían un mensaje resv (abreviatura de reserve ) correspondiente que luego rastrea la ruta hasta el 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 simplemente la dirección IP del remitente y, opcionalmente, su puerto UDP o TCP. Cuando un enrutador recibe el mensaje resv RSVP, hará lo siguiente:

1. Realizar una reserva en función de los parámetros de la solicitud. El control de admisión procesa los parámetros de la solicitud y puede indicar al clasificador de paquetes que gestione correctamente el subconjunto seleccionado de paquetes de datos o negociar con la capa superior cómo se debe realizar el manejo de los paquetes. Si no se puede realizar la reserva, se envía un mensaje de rechazo para informar al receptor.
2. Reenviar la solicitud en sentido ascendente (en la dirección del remitente). En cada nodo, el flowspec del mensaje resv puede ser modificado por 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 del flujo.

Si no se escucha nada durante un tiempo determinado, la reserva se agotará y se cancelará. Esto resuelve el problema si el remitente o el receptor fallan o se apagan sin cancelar primero la reserva.

Integridad

Los mensajes RSVP se complementan con un resumen del mensaje creado mediante la combinación del contenido del mensaje y una clave compartida mediante un algoritmo de resumen del mensaje (normalmente 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 .

Informe de errores

Cuando un nodo detecta un error, se genera un mensaje de error con un código de error y se propaga en sentido ascendente por la ruta inversa hasta el remitente.

Información sobre el flujo de RSVP

Dos tipos de mensajes de diagnóstico permiten a un operador de red solicitar información sobre el estado de RSVP en un flujo específico.

Instalación de diagnóstico

Una extensión del estándar que permite a un usuario recopilar información sobre el estado de RSVP a lo largo de una ruta. ^[4]

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

• "Protocolo de reserva de recursos". Cisco. Archivado desde el original el 5 de julio de 2017. Consultado el 16 de febrero de 2011 .
• Naveen Joy (17 de junio de 2002). «RSVP ofrece calidad de servicio». Network World . Archivado desde el original el 29 de junio de 2013. Consultado el 14 de febrero de 2012 .
• "Proyecto RSVP". Instituto de Ciencias de la Información de la USC. Archivado desde el original el 27 de abril de 2017.