El proceso de reserva RSVP

El proceso de reserva RSVP

Las comunicaciones de voz o vídeo por Internet requieren utilizar lo que se conoce como técnicas de calidad de servicio o QoS. El protocolo RSVP es el protocolo de calidad de servicio más utilizado. En un artículo anterior hemos descrito el formato de los mensajes RSVP. Aquí veremos cómo se lleva a cabo el proceso de reserva RSVP. Esto es, los mensajes que se intercambian los terminales para reservar los recursos necesario que garanticen la calidad de la comunicación.

La comunicación multimedia se realiza entre un terminal emisor (que inicia la comunicación) y uno o varios terminales receptores (que reciben la llamada). El proceso de reserva de los recursos necesarios para el establecimiento de una comunicación multimedia comienza por definir la ruta de los nodos por los que se establecerá la comunicación entre el terminal emisor y el receptor. Una vez definida esta ruta, los paquetes RSVP (y, posteriormente, los de voz) se retransmitirán de nodo a nodo siguiendo siempre la misma ruta. Este circuito virtual queda definido mediante los registros correspondientes en cada nodo (router) que forma la ruta.

En la idea de que los recursos no se queden reservados de forma indefinida, este circuito (los registros correspondientes) tiene un tiempo de expiración que se va renovando periódicamente. La renovación se realiza cada vez que se recibe un mensaje Path o Resv. En el caso de que se dejen de recibir estos mensajes, los nodos intermedios eliminan los registros de la ruta. Por tanto, el emisor y el receptor están continuamente enviando mensajes Path y Resv durante todo el tiempo que dura la comunicación.

Recordemos que el mensaje Path es el que utiliza el emisor para marcar la ruta a utilizar durante la sesión. Por su parte, el mensaje Resv es el que utiliza el receptor para confirmar la reserva de los recursos de red necesarios. El mensaje Resv lo envía el receptor como respuesta a un mensaje Path.

Definir la ruta con el mensaje Path

El emisor envía un paquete Path al receptor (o receptores) de la comunicación. En este mensaje incluye los parámetros que identifican la sesión (objeto Session, que incluye la dirección del receptor), la identificación del emisor (objeto Sender_Template), las características del tráfico (objeto Sender_TSpec) y el valor del tiempo de refresco (Time_Values). El paquete va recorriendo la ruta hacia el receptor comprobando que todos los nodos intermedios (todos los routers) son compatibles con RSVP (objeto AdSpec). Cada uno de estos nodos guarda un registro de la sesión (conocido como registro de estado de la ruta o path state) donde incluye: la identificación de la sesión, las características del tráfico y la dirección IP del nodo precedente. Cada nodo sustituye esta dirección IP (objeto Resv_Hop) por la suya propia antes de pasar el paquete al nodo siguiente.

El objeto AdSpec incluido en el mensaje Path va recogiendo distinta información de la ruta por la que va pasando (retardo, ancho de banda estimado, número de saltos, etc.) para que el receptor pueda conocer las características de la ruta.

Proceso de reserva de recursos con RSVP
Proceso de reserva de recursos con RSVP

Reservar los recursos con el mensaje Resv

Cuando el mensaje Path llega al receptor, éste tiene que decidir qué tipo de reserva va a solicitar. Para ello cuenta con las características del tráfico definidas por el emisor (objeto Sender_TSpec) y con la información sobre la ruta (objeto AdSpec). A continuación genera un mensaje Resv que envía de vuelta recorriendo la ruta anterior en sentido inverso. Este mensaje va reservando los recursos necesarios para la comunicación. Para ello, el mensaje Resv incluye la identificación de la sesión (objeto Session), el estilo de la reserva (objeto Style), los parámetros que definen la calidad de servicio deseada (objeto FlowSpec) y la identificación del emisor (objeto Filter_Spec). Esta información la van guardando los nodos intermedios en un registro conocido como estado de la reserva o resv state.

A los objetos FlowSpec y Filter_Spec se los conoce como descriptores de flujo (Flow descriptor). La forma cómo se incluyen estos objetos en el mensaje Resv depende del estilo de la reserva:

  • WF (identificación y reserva conjunta). Cuando se realiza una única reserva y se cuenta con una única identificación de emisor, el descriptor de flujo será un objeto FlowSpec.
  • FF (identificación y reserva independiente). Cuando se tiene una reserva independiente para cada emisor, se enviarán distintos mensajes de reserva incluyendo en cada uno de ellos un objeto FlowSpec seguido de Filter_Spec.
  • SE (identificación independiente y reserva compartida). Se utiliza una única reserva, aunque se identifican los emisores de forma independiente. En este caso, el descriptor de flujo incluirá un objeto FlowSpec seguido de un objeto Filter_Spec por cada emisor.

Por otro lado, si la comunicación se realiza con más de un receptor, llega un momento en que un mismo nodo se encuentra con más de un mensaje Resv correspondiente a una misma sesión y a un mismo emisor. En este caso, el nodo junta todos estos mensajes de reserva y le asigna la solicitud de recursos más elevada.

Reserva de recursos con RSVP
Reserva de recursos con RSVP

Establecer la comunicación multimedia RSVP

Una vez que el mensaje Resv llega al emisor sin que haya habido ningún mensaje de error significará que han sido reservados todos los recursos necesarios a lo largo de la ruta, por lo que podrá comenzar el intercambio de información multimedia.

Hay que tener en cuenta que los paquetes RSVP incluyen las direcciones IP de origen y destino como cualquier otro paquete IP, por lo que si un nodo no es compatible con RSVP, simplemente lo retransmitirá como si se tratase de un paquete de datos.

En caso de error en el proceso de reserva RSVP

Si alguno de los nodos no puede realizar la reserva solicitada, le envía al receptor un mensaje de error (mensaje Resv_Error). Igualmente, si el mensaje Path produjera algún error, el router correspondiente le enviaría un mensaje de error al emisor (mensaje Path_Error).

Es importante tener en cuenta que, en el caso de comunicaciones con más de un receptor, el fallo en la reserva de un receptor no debe influir en los otros. Por ejemplo, si llegan a un nodo dos peticiones de reserva realizadas por dos receptores, si el nodo rechaza una de ellas por solicitar un ancho de banda excesivo, la solicitud del otro receptor no tendría que fallar si su petición de ancho de banda es inferior y puede ser aceptada por el nodo.

Tanto el emisor como el receptor incluyen en los mensajes Path y Resv el objeto Time_Values. Este objeto contiene el periodo de refresco (R) para mantener la reserva activa. Cada nodo tiene un contador, y, si no recibe un nuevo mensaje Path o Resv antes de que se cumpla este periodo de refresco, se eliminará la reserva. Por este motivo, tanto el emisor como el receptor envían mensaje Path y Resv de forma periódica.

Hay que tener en cuenta que, aunque el tiempo de refresco es R, los nodos tienen configurado un tiempo de espera mayor que R para contemplar la posibilidad de que se pierdan uno o más mensajes Path o Resv (dado que UDP no tiene garantía de entrega).

Terminar la reserva RSVP

Cuando se da por terminada la comunicación, el emisor o el receptor envían un mensaje de cancelación de la reserva (PathTear y ResvTear respectivamente). Estos mensajes recorren toda la ruta cancelando los recursos reservados para dicho emisor o receptor. En el caso de contarse con más de un receptor, el mensaje ResvTear llegaría hasta el nodo de encuentro con otra reserva. Esto evita que desde un receptor se pueda cancelar la reserva de otro.

Más información sobre el proceso de reserva RSVP

REF: VOIP PG213

2 comentario en “El proceso de reserva RSVP

  1. Super!!! dure navegando mucho tratando de encontrar un ejemplo valido y encontré esto, mil gracias por la información

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *