Para reservar flujo, el cliente y el servidor deben tener recursos asignados de cada elemento del hardware de red que participe en la transmisión. Para iniciar el proceso de reserva, el cliente envía un mensaje PATH al receptor. Estos mensajes son encaminados siguiendo las tablas de enrutamiento normales hacia los receptores. Los mensajes PATH contienen información sobre las características de tráfico que tendrán los datos enviados por el emisor y las características de recursos que tiene el camino de datos hasta cada uno de los receptores
A medida que cada dispositivo de red(routers/switches) recibe el mensaje PATH se agrega a sí mismo a la lista y reenvía el mensaje. Esta lista permite que los paquetes posteriores de la misma sesión sigan la misma ruta. cualquier elemento de hardware que no entienda RSVP reenviará el mensaje como cualquier otro paquete, sin agregarse a la lista de hardware(o lista de dispositivos de red).
El nodo receptor envía luego una respuesta al mensaje PATH que se denomina mensaje RESV( o de reserva). Este mensaje usa la misma ruta que el mensaje PATH(en orden inverso, por supuesto), puesto que cada salto de la ruta de acceso esta enumerado en el mensaje(cada salto se conoce como el previous hop en la literatura de RSVP). Cuando cada uno de los nodos intermedios recibe un mensaje RESV; guarda la información necesaria para mantener esa reserva y la pasa al nodo anterior(básicamente, comprueba que dispone del ancho de banda solicitado por la reserva y efectúa la reserva en ese momento).
El proceso completo de reserva se ilustra en la figura 18(tomada del libro Introducción
a Microsoft Windows 2000 Server, capitulo 6: Introducción a la infraestructura de red,
publicado por Microsoft Press)
Figura 19. Reserva de recursos mediante los mensajes PATH y RESV
Si alguno de los dispositivos de red no puede reservar los recursos, el problema se indica mediante un mensaje de error. El jitter que puede producirse por utilizar diferentes rutas de acceso se reduce, porque todos los paquetes de esa sesión pasarán exactamente a través de los mismos enrutadores.
El emisor reenvía automáticamente un mensaje PATH de forma periódica para adaptarse a los estados cambiantes de la red. De manera predeterminada, este envío del mensaje PATH se produce cada 30 segundos. Si el dispositivo de red que tiene recursos reservados no recibe ningún mensaje PATH en un intervalo determinado de tiempo (que de forma predeterminada es 90 segundos), se eliminará la reserva. Así se evita que un error en la conexión comprometa recursos innecesariamente y las reservas de recursos permanezcan por siempre. Una vez finalizada la sesión, la estación que interrumpe la conexión enviará un mensaje PATH especial que indica al dispositivo de red que libere los recursos. Este se denomina mensaje PATH TEAR.
2.2.1.1. Ejemplos
Los siguientes ejemplos(tomados del documento : Simulador del protocolo de reserva de recursos, Daniel Burguillos y Juan José López capitulo 3, pagina 48) ilustran la operación del protocolo RSVP.
Supongamos que hay un emisor multic ast que transmite el vídeo de un evento deportivo, y que el protocolo subyacente en la red ha determinado que el camino que debe seguir el flujo de datos es el mostrado en la figura 18( los números que acompañan a cada receptor es la velocidad a la que desea recibir datos). Y supongamos también que la señal de video está dividida en capas para acomodarla de forma correcta a la heterogeneidad de los receptores.
ORIGEN Router A Router B Router C Router D R3 3 Mbps R4 3 Mbps Figura 20. Ejemplo de RSVP
El emisor envía mensajes Path que establece las rutas a seguir por los flujos de datos. Cada receptor, a su vez, envía un mensaje de reserva hacia el emisor el cual incluye la velocidad a la que desea recibir los datos. Cuando un mensaje de reserva alcanza un router, este ajusta su planific ador de paquetes para acomodarlo a la nueva reserva. El ancho de banda que un router envía hacia el siguiente dependerá de los anchos de banda que se han reservado por debajo de él. En la figura anterior los receptores R1, R2, R3 y R4 reservan respectivamente 20 kbps, 120 Kbps, 3 Mbps, 3 Mbps y 3 Mbps. La máxima petición que ha recibido el router D es de 3 Mbps, por lo que envía , para esta transmisión una reserva al router B de 3 Mbps ( nótese que no se reserva 6 Mbps, esto es porque R3 y R4 están viendo el mismo evento deportivo; por este motivo las reservas se han fusionado). La máxima petición que ha recibido el router C es de 100 Kbps, por lo que envía esta reserva al router B ( la codificación por capas
de la señal de video asegura que la señal de 20 Kbps que necesita R1 está incluida en la de 100 Kbps de R2 ). De la misma manera el router B fusiona las reservas de C y D enviando una única reserva de 3 Mbps hacia el router A, la cual llega al nodo origen de los datos.
Tomemos ahora un nuevo escenario en el que cuatro personas están participando de una videoconferencia, tal y como se muestra en la figura 19. Cada una de estas personas tiene tres ventanas abiertas con la imagen de los otros tres participantes. Supongamos que el protocolo de enrutamiento multicast ha definido el árbol de distribución multicast como se muestra en la figura. Finalmente, supongamos que cada persona desea recibir los vídeos con una calidad de 3 Mbps.
En este caso en cada uno de los enlaces de este árbol multicast deberán reservarse 9 Mbps en una dirección y 3 Mbps en la otra ( nótese que en este caso no se fusionan las reservas, dado que cada persona desea recibir 3 flujos de datos diferentes ).
Figura 21. Videoconferencia con RSVP
2.2.1.2. Estructura de una implementación RSVP
una implementación RSVP según el RFC 2205 define la estructura de bloques mostrada en la figura 22.
El protocolo debe estar soportado en los hosts extremos(emisores y receptores) y en los enrutadores por los que deberán pasar el flujo de datos. Como es imposible introducir un protocolo nuevo en toda la red al mismo tiempo, RSVP contempla la posibilidad de que en la ruta existan zonas sin soporte del protocolo(RSVP tunneling o zonas no RSVP). Al igual que otros protocolos de control como ICMP o IGMP, RSVP se ejecuta en “background” y no en el camino de datos; por tanto los paquetes que deben beneficiarse de la reserva de recursos iniciada por RSVP no serán diferentes de aquellos que no pertenezcan al flujo reservado.
Figura 22. Servidor y enrutador bajo el protocolo RSVP
Todos los mensajes de RSVP se encapsulan dentro de datagramas IP( como raw data) al igual, por ejemplo, que los mensajes del protocolo de control ICMP. Si un nodo de la red no dispone de la capacidad para encapsular raw data dentro de datagramas IP, se ha previsto que se encapsule el mensaje RSVP dentro de un mensaje UDP(este tema se especifica en el apéndice C del RFC 2205). La siguiente figura ilustra la posición del protocolo dentro del modelo de capas de internet.