Un mensaje RSVP consta de un encabezado común, donde se especifican la versión del

protocolo y el tipo de mensaje.

El mensaje PATH sigue la ruta proporcionada por el protocolo de enrutamiento, utilizando la

misma ruta que el flujo de datos. Cada mensaje PATH almacena un estado de ruta en todos los
nodos intermedios a lo largo del camino por lo que es usado para señalizar y solicitar los
enlaces de etiquetas necesarios para establecer los LSP y viaja en el sentido DOWNSTREAM.

El mensaje RESV se envía exactamente en la ruta inversa utilizada por el mensaje PATH. Si el
mensaje PATH se envía utilizando la misma dirección de origen y destino que los datos, el
mensaje RESV se envía salto a salto utilizando la información del estado del camino
almacenada en los nodos intermedios. El mensaje RESV es creado por el router final el cual
confirma la solicitud de reserva, este mensaje realiza la función de asignación de etiquetas y
viaja en el sentido UPSTREAM.

Los mensajes PATH y RESV se utilizan para CREAR, pero también para ACTUALIZAR, la reserva y
el estado de la ruta en los nodos. De esta manera, si una ruta cambia, debido a actualizaciones
de enrutamiento o falla del nodo, el nuevo mensaje de ruta creará un nuevo estado de ruta en
los nodos de la nueva ruta y el mensaje RESV establecerá el estado de reserva en estos nodos
para la nueva ruta.

El mensaje PATH-TEAR viaja en sentido descendente hacia el (los) receptor (es) y elimina los
estados de la ruta y los estados de reserva dependientes en todos los nodos intermedios para
esa reserva.

NOTA: El estado de la ruta se elimina haciendo coincidir los objetos SESSION, SENDER
TEMPLATE y RSVP HOP del mensaje PATH-TEAR con los valores almacenados en el estado de la
ruta del nodo.

El mensaje RESV-TEAR puede verse como el mensaje de ruta de sentido inverso y se encarga
de eliminar los estados de reserva a medida que viaja hacia el (los) remitente (s).

El mensaje PATH-ERR simplemente viaja en sentido ascendente hacia el remitente que creó el
error y no cambia ningún estado de ruta en el camino.

El mensaje RESV-ERR tiene un comportamiento mucho más complejo, ya que una solicitud
fallida puede ser causada por la fusión de varias solicitudes diferentes, lo que a su vez significa
que el error de reserva debe informarse a todos los receptores involucrados.

El mensaje RESVCONF se envía como respuesta al recibir un mensaje RESV que tiene integrado
un objeto RESV CONFIRM. El mensaje se transmite a la dirección obtenida del objeto RESV
CONFIRM en una base salto por salto para acomodar el mecanismo de verificación de
integridad salto por salto.

Cada OBJETO consta de un múltiplo de palabras de 32 bits, comenzando de nuevo con un

encabezado común que especifica:

la longitud en bytes del objeto.

Class-Num se utiliza para identificar de forma única una clase de objetos, se especificaron
15 valores de Class-Num.

el campo C-Type identifica un tipo de objeto preciso.

El objeto SESSION: Lleva la dirección IP del nodo de destino, el número de protocolo IP y el
puerto de destino.

El objeto SENDER TEMPLATE para identificar la dirección IP y el puerto de origen del remitente

El objeto SENDER TSPEC es para definir las características de tráfico del flujo de datos del
remitente.

El objeto ADSPEC se utiliza para la información publicitaria (OPWA) del flujo de datos.

El estado de la ruta se identifica mediante la tupla compuesta por objetos SESSION y SENDER
TEMPLATE.

El objeto RSVP HOP se utiliza para transmitir la dirección IP del nodo con capacidad IP anterior
junto con el identificador de interfaz de salida lógica (LIH). El mensaje RESV viaja salto a salto
desde un nodo con capacidad RSVP a otro, utilizando la información que se almacena en el
estado de la ruta en cada enrutador intermedio para determinar el siguiente salto.

El objeto INTEGRITY se utiliza para transportar datos criptográficos con el fin de autenticar el
nodo de origen y proporcionar integridad de un extremo a otro.

El objeto POLICY DATA (fue estandarizado posteriormente por RFC 2750) Este objeto se utiliza
para el control de admisión basado en políticas genéricas.

El objeto STYLE: indicación de qué estilo está en uso.

Hay tres tipos de estilos (STYLE) de reserva disponibles para usar con RSVP:

FILTRO FIJO (FF) se utiliza cuando la reserva es distinta y la selección del remitente es explícita.
Esto significa que se crea una reserva distinta para los paquetes de datos de un remitente en
particular. La reserva, en este caso, no se comparte con otros remitentes.

FLOWSPEC especifica la QoS deseada que utilizan los nodos para establecer los
parámetros del programador de paquetes.

El FILTER-SPEC se usa junto con la especificación de sesión para definir el conjunto de

paquetes de datos (o el flujo) que recibirán la QoS definida por FLOWSPEC,
especificando los parámetros necesarios para el clasificador de paquetes del nodo.

SHARED EXPLICIT (SE) y WILDCARD FILTER (WF), crean reservas compartidas.

Shared Explicit (SE): el receptor puede especificar explícitamente el conjunto de remitentes

que se incluirán. La selección del remitente se basa en hacer coincidir el objeto FILTER SPEC
con el objeto SENDER TEMPLATE del estado de ruta existente almacenado en los nodos
intermedios.

Wildcard Filter (WF): la reserva se extiende automáticamente a los nuevos remitentes a

medida que aparecen.

Las reservas compartidas WF y SE son apropiadas para aplicaciones de multidifusión donde es

poco probable que múltiples fuentes transmitan simultáneamente.

El objeto ERROR SPEC se utiliza solo para transportar la dirección del nodo que originó el
mensaje.
El objeto ADSPEC transporta hacia los receptores información que es generada o modificada
por los elementos de la red con respecto a los parámetros específicos de los servicios de
control de QoS (es decir: servicios disponibles, retardo, estimación del ancho de banda).
ADSPEC representa un resumen de estos parámetros calculados o modificados en cada nodo
de la ruta. Los valores de los parámetros describen las propiedades de la ruta sin tener en
cuenta cuál es la QoS solicitada.

RSVP se amplió para comportarse como un protocolo de distribución de etiquetas y para

implementar características de ingeniería de tráfico.

se ocupa de la optimización del rendimiento de las redes operativas, teniendo como objetivo
principal facilitar operaciones de red eficientes y fiables, optimizando simultáneamente la
utilización de los recursos de la red y el rendimiento del tráfico

Se definieron nuevos objetos RSVP SESSION, SENDER TEMPLATE y FILTER SPEC a través de
nuevos tipos C (LSP Tunnel IPv4 y LSP Tunnel IPv6). Además de estos, se introdujeron otros
cinco objetos nuevos: LABEL REQUEST, LABEL, EXPLICIT ROUTE, RECORD ROUTE y el objeto
SESSION ATTRIBUTE

Los objetos SESSION y SENDER TEMPLATE parecen ser idénticos a los utilizados por las
especificaciones originales de RSVP, estos objetos tienen un nuevo formato definido bajo el
mismo Class-Num pero con nuevos valores de C-Type.

El objeto LABEL REQUEST indica que se solicita un enlace de etiqueta, pero también
proporciona información sobre el protocolo de capa de red utilizado en rutas específicas.

El objeto LABEL transmite la etiqueta asociada con el tráfico saliente para un túnel LSP
específico y contiene solo una etiqueta codificada en 4 octetos

NOTA: los objetos LABEL REQUEST y LABEL son obligatorios para RSVP-TE

El objeto EXPLICIT ROUTE lleva la ruta que debe seguir un LSP como una secuencia de nodos.

El objeto RECORD ROUTE se utiliza para informar al nodo remitente sobre la ruta real que
atraviesa un túnel LSP. Este objeto está destinado a utilizarse únicamente para flujos de tráfico
de unidifusión. La ruta explícita es especificada por los subobjetos incluidos en el objeto
EXPLICIT ROUTE.

Cada subobjeto indica la dirección IP de un nodo que debe incluirse en la ruta, o el número de
Sistema Autónomo (AS) al que debe pertenecer ese nodo. Además, cada subobjeto debe
indicar si representa un salto estricto o suelto en la ruta explícita. El proceso que utiliza el LSR
para evaluar y manejar el objeto RECORD ROUTE se compone de los siguientes seis pasos:

El objeto SESSION ATTRIBUTE se utiliza para ayudar en la identificación y el diagnóstico de

sesiones, además se usa para proporcionar un control adicional como la configuración y
mantener las prioridades. Este objeto se definió con dos tipos C: el túnel LSP y el túnel LSP RA
(con afinidades de recursos).

Para crear un túnel LSP, el primer nodo en la red MPLS genera un mensaje RSVP PATH con el
nuevo objeto SESSION definido y el objeto LABEL REQUEST incluidos. Si este nodo tiene
información sobre qué ruta cumplirá con los requisitos de QoS del túnel o si satisface algunos
criterios de política, también se introduce un objeto EXPLICIT ROUTE en el mensaje Ruta. Este
objeto se puede cambiar si posteriormente se encuentra una ruta mejor, creando de esta
forma la posibilidad de desviar la sesión de forma dinámica. Además, un objeto RECORD
ROUTE y SESSION ATTRIBUTE se pueden insertar opcionalmente en el mensaje PATH.

El nodo de destino responde al objeto LABEL REQUEST, incluyendo en el mensaje RSVP RESV
un objeto LABEL. Como en el caso normal de RSVP, el mensaje RESV se envía de regreso en
sentido ascendente siguiendo el estado de ruta creado por el mensaje de ruta. Cada nodo a lo
largo de la ruta que recibe un mensaje RESV que contiene un objeto LABEL usará esa etiqueta
para el tráfico saliente asociado con ese túnel LSP. Si el nodo receptor del mensaje RESV no es
el remitente, se asigna una nueva etiqueta y se coloca en el objeto LABEL del mensaje RESV
que se envía en sentido ascendente [51]. Esta nueva etiqueta se utiliza para identificar el
tráfico entrante asociado con ese LSP.

En el mensaje RESV cada objeto LABEL y RECORD ROUTE están acoplados a un objeto FILTER
SPEC que los precede en la lista de descriptores de flujo. Solo pueden existir un LABEL y un
RECORD ROUTE para un objeto FILTER SPEC.

Si una etiqueta no está disponible, el nodo envía un mensaje PATH-ERR indicando un fallo en
la asignación de etiquetas. Cuando se asigna la etiqueta, se crea un nuevo objeto LABEL y se
reenvía al nodo ascendente en un mensaje RESV. El objeto LABEL se almacena en el bloque de
estado de reserva y el nodo debe estar preparado para reenviar paquetes que lleven la
etiqueta asignada.

El nodo ascendente usa la etiqueta del objeto LABEL como etiqueta asociada con la interfaz de
salida para ese remitente. Además, se asigna una nueva etiqueta en el mismo nodo y se
vincula a la interfaz entrante para esta sesión / remitente. La interfaz es la misma que se utiliza
para reenviar mensajes RESV a saltos anteriores.

El objeto LABEL REQUEST se definió en el contexto de tres tipos C posibles. El primer tipo se
denomina Solicitud de etiqueta sin rango de etiqueta y se emplea para indicar el protocolo de
capa 3 que usa la ruta. Los otros dos tipos son específicos para las tecnologías de modo de
transferencia asincrónica (ATM) y Frame Relay.

El objeto LABEL REQUEST se almacena en cada nodo a lo largo de la ruta en el Bloque de

estado de ruta. Cada nodo que acepta un objeto LABEL REQUEST debe incluir una LABEL en el
mensaje RESV que responde a ese mensaje PATH. Cada nodo que envía un objeto LABEL
REQUEST debe estar listo para recibir y manejar el objeto LABEL en el mensaje RESV
resultante.

Si un enrutador sabe que tiene un vecino que no es compatible con RSVP, entonces el objeto
LABEL REQUEST no debe anunciarse al enviar el mensaje que pasa a través de nodos que no
son RSVP. El enrutador también debe enviar un mensaje PATH-ERR con el valor de error MPLS
que se está negociando, pero un nodo no capacitado para RSVP se encuentra en la ruta.