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 mediante el modelo de servicios integrados . RSVP opera sobre IPv4 o IPv6 y proporciona la configuración, iniciada por el receptor, de reservas de recursos para flujos de datos multicast o unicast . 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 Gestión de Grupos de Internet (IGMP). RSVP se describe en la RFC 2205 y se le asigna el número de protocolo IP 46. 

RSVP puede ser utilizado por hosts y enrutadores para solicitar o proporcionar 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 liberar los recursos reservados una vez que ya no los necesiten. Las operaciones RSVP generalmente resultan en 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 los protocolos de enrutamiento actuales y futuros.

En 2003, el desarrollo de la ingeniería de teletrafico se trasladó de RSVP a RSVP-TE . Next Steps in Signaling (NSIS) fue una propuesta para reemplazar a RSVP.

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 ]}
2. RSVP no es un protocolo de enrutamiento, pero funciona con los protocolos de enrutamiento actuales y futuros.
3. RSVP está orientado al receptor, ya que el receptor de un flujo de datos inicia y mantiene la reserva de recursos para dicho flujo.
4. RSVP mantiene un estado flexible (la reserva en cada nodo necesita una actualización periódica) de las reservas de recursos del host y los enrutadores, lo que permite una adaptación automática y dinámica a los cambios de la red.
5. RSVP ofrece varios estilos de reserva (un conjunto de opciones de reserva) y permite añadir estilos futuros en revisiones del protocolo para adaptarlos a diversas aplicaciones.
6. RSVP transporta y mantiene parámetros de control de tráfico y políticas que son opacos para RSVP.

Los conceptos básicos de RSVP fueron propuestos originalmente en 1993. ^{[ 3 ]}

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 el RFC 2205 (septiembre de 1997) por la 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. Posteriormente, el RFC 2750 amplió la compatibilidad con el control de admisión. 
• RFC 2210 define el uso de RSVP con los servicios de control de QoS de carga controlada RFC 2211 y de garantía RFC 2212. Para más detalles, consulte Servicios integrados . También define el uso y el formato de datos de los objetos de datos (que contienen información de reserva de recursos) definidos por RSVP en RFC 2205. 
• El RFC 2211 especifica el comportamiento de los elementos de red necesarios para ofrecer servicios de carga controlada. 
• El RFC 2212 especifica el comportamiento de los elementos de red necesarios para ofrecer servicios de QoS garantizados. 
• El RFC 2750 describe una extensión propuesta para admitir el control de admisión genérico basado en políticas en RSVP. La extensión incluía una especificación de objetos de política y una descripción del 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 ingeniería de tráfico de reserva de recursos de señalización de conmutación de etiquetas multiprotocolo generalizada (GMPLS) (RSVP-TE)" (enero de 2003). 
• El 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. 
• El 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) Hello: Declaración aclaratoria" (junio de 2006). 

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

Existen 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 misma.

El estado de la ruta incluye la dirección IP del nodo anterior y algunos objetos de datos:

1. Plantilla del remitente para describir el formato de los datos del remitente en forma de Filterspec ^{[ 4 ]}
2. Especificación del remitente para describir las características del tráfico del flujo de datos.
3. Especificación publicitaria que contiene 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 través de la ruta de datos inversa. En cada nodo, la dirección IP de destino del mensaje resv cambia 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 en los mensajes RSVP se pueden transmitir en cualquier orden. Para obtener la lista completa de mensajes RSVP y objetos de datos, consulte la RFC 2205.

Un host RSVP que necesite enviar un flujo de datos con una calidad de servicio (QoS) específica transmitirá un mensaje de ruta RSVP cada 30 segundos, el cual viajará a través de las rutas unicast o multicast preestablecidas por el protocolo de enrutamiento en funcionamiento. Si el mensaje de ruta llega a un enrutador que no entiende RSVP, este lo reenviará sin interpretar su contenido y no reservará recursos para el flujo.

Quienes deseen escucharlos envían un mensaje resv (abreviatura de reserve ) correspondiente, que luego rastrea la ruta hasta el remitente. El mensaje resv contiene una especificación de flujo (flowspec ). El mensaje resv también tiene un objeto filterspec ; este define los paquetes que recibirán la QoS solicitada definida en la especificación de flujo. 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, hará lo siguiente:

1. Realice una reserva en función de los parámetros de la solicitud. El control de admisión procesa dichos parámetros y puede indicar al clasificador de paquetes que gestione correctamente el subconjunto de paquetes de datos seleccionado o negociar con la capa superior cómo debe realizarse el procesamiento de los paquetes. Si no se pueden admitir, se envía un mensaje de rechazo para informar al receptor.
2. Reenvía la solicitud en sentido ascendente (en dirección al remitente). En cada nodo, un nodo de reenvío puede modificar la especificación de flujo en el mensaje de reserva (por ejemplo, en el caso de una reserva de flujo multicast, las solicitudes de reserva se pueden fusionar).
3. Los enrutadores almacenan entonces la naturaleza del flujo y, opcionalmente, configuran el control de tráfico de acuerdo con la especificación del flujo correspondiente.

Si no se recibe ninguna señal durante un tiempo determinado, la reserva caducará y se cancelará. Esto resuelve el problema si el emisor o el receptor fallan o se apagan sin haber cancelado previamente la reserva.

Integridad

Los mensajes RSVP incluyen un resumen del mensaje creado mediante la combinación del contenido del mensaje y una clave compartida utilizando un algoritmo de resumen de mensajes (generalmente MD5 ). La clave se puede distribuir y confirmar mediante dos tipos de mensajes: solicitud de desafío de integridad y respuesta al desafío de integridad .

Notificación de errores

Cuando un nodo detecta un error, se genera un mensaje de error con un código de error que se propaga en sentido inverso hasta el remitente.

Información sobre el proceso de confirmación de asistencia

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

Centro de diagnóstico

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

• Protocolo de reserva de recursos . Cisco. Archivado del 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 del 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 del original el 27 de abril de 2017.