Protocolo de reservación de recursos, un protocolo de control de la red que permite que los programas que van a trabajar en Internet puedan obtener la calidad de servicio que sus flujos de datos puedan requerir. Se encuentra aún en fase de normalización por parte del IETF, que está desarrollando su estandarización partiendo de los trabajos iniciales que se realizaron en la Universidad del Sur de California con la participación de Xerox, en donde fue concebido.
Características de RSVP:
a) RSVP fue diseñado para ser un protocolo agregado a la arquitectura de protocolos TCP/IP.
b) Su diseño fue influenciado por los requerimientos de aplicaciones video-conferencia multicast.
c) Principios del Diseño: Reservación simplex orientado al receptor, independencia del enrutamiento, independencia de las políticas, adaptabilidad a los cambios en la red soft-state, varios estilos de reserva.
Objetivos de RSVP
Se trata de diferenciar cada paquete y darle un trato dependiendo del servicio que necesite. Los paquetes se marcan y clasifican para recibir un tratamiento específico por salto en la ruta. Esta política de clasificación sólo se implementa en las fronteras de la red y no en los nodos intermedios.
Divide los paquetes en distintas clases que requerirán distintos servicios. Los 4 básicos son:
1. PHB por defecto: Es el menos riguroso y equivale a enviar si se puede y si no, descartar.
2. PHB selector de clase: Si no hay congestión, se asegura el envío y si la hay, no.
3. PHB de reenvío explícito: Se garantiza un ancho de banda, se asegura que no hay pérdidas, poca latencia y variación de retardo (para videoconferencia, etc.).
4. PHB de reenvío asegurado: Se garantiza que no hay pérdida de paquetes.
Operación General de RSVP (Diseño)
Objetivos del Diseño
Reservación Simplex:
-RSVP: Se utiliza para establecer reserva de recursos entre un TX y un RX.
-La reserva se hace en un solo flujo de dirección (flujo simplex)
-En una aplicación bidireccional el TX se diferencia lógicamente del RX, por tanto se requerirá una reserva para cada trasmisión.
Orientado al Receptor:
-RSVP: Soporta comunicaciones multicast (grandes grupos, membrecía dinámica, requerimientos del RX heterogéneos.
-Los receptores son los responsables de decidir que recursos serán los reservados y deberán iniciar la reserva.
Independencia del Enrutamiento:
-RSVP está diseñado para operar con protocolos enrutamiento unicast y multicast actuales y futuros.
- La decisión de seleccionar un camino para un flujo es hecha por el protocolo de enrutamiento.
-RSVP Simplemente consulta al tabla de enrutamiento y envía los mensajes RSVP de acuerdo a ella.
Independencia de las Políticas:
-El control de los parámetros que son transportados por RSVP es realizado por otros módulos de control int-serv.
-El control de admisión examinara los parámetros de la reserva y decidirá si hay suficientes recursos para una nueva reserva.
Adaptabilidad a Cambios en la Red:
-RSVP se adapta a los cambios en el árbol multicast
-El método usado utiliza:
Un estado en la reserva en la red (información en cada router)
Un temporizador del estado de la reserva cuando expira el temporizador, el estado de la reserva es borrado.
-Se hace un refresco periódico del estado de la reserva para mantenerlo a lo largo del camino.
-Esta característica permite a RSVP a adaptarse a cambios en los miembros del árbol multicast y a cambios en al topología en la red.
Estilos de Reserva:
-RSVP tiene varios tipos de reservas que son tratadas diferentes en int-serv
-Estos tipos de reserva permiten compartir una reserva para flujos de tráfico de múltiples transmisores o seleccionar un transmisor particular en el que está interesado un receptor.
Flujo de Datos
La base del funcionamiento de RSVP la forman tres conceptos relacionados con los flujos de datos: sesión, especificación de flujo y especificación de filtro.
Sesión:
Es un flujo de datos identificado por su destino. Una vez que se ha hecho la reserva en un dispositivo de encaminamiento por un destino en particular, el dispositivo considera esto como una sesión y asigna recursos en una sesión se define:
· Dest addres: Dirección IP, destino de los paquetes (unicast o multicast)
· Protocol ID: Es el identificador ID del protocolo IP.
· Dstport (opc): Es un punto de demux en la capa de transporte
Especificación del Flujo:
Es una solicitud de reserva emitida por un sistema final destino y consta de un especificación de flujo (flowspec) y un filtro de flujo (fitrspec). La especificación de flujo indica una calidad de servicio deseada y se utiliza para establecer parámetros en el gestor de salida de paquetes de un nodo. El dispositivo de encaminamiento transmitirá los paquetes con un conjunto dado de preferencias basándose en la especificación de flujo actual.
Especificación del Filtro:
Define un conjunto de paquetes para los que se solicita la reserva. Así, la especificación de filtro y la sesión define un conjunto de paquetes para los que se solicita la reserva, el conjunto de paquetes, o flujo, que van a recibir la Qos deseada. Cualquier otro paquete que va dirigido al mismo destino se trata como tráfico del mejor esfuerzo. La especificación de flujo contiene una clase de servicio, una Rspec (especificación de reserva) y una Tspec (especificación de tráfico). La clase de servicio es un identificador de un tipo de servicio que se está solicitando. Los otros dos parámetros son conjuntos de valores numéricos. El parámetro Rspec define la calidad de servicio deseada y el parámetro Tspec describe el flujo de datos.
Flujo de Datos
Funcionamiento de RSVP
a) Mensajes de establecimiento de ruta
a) Mensajes de establecimiento de ruta
La siguiente figura muestra un ejemplo de una sesión multicast que involucra un emisor, S1, y tres receptores; RCV1-RCV3.
Los mensajes primarios usados por RSVP son el mensaje Path, que tiene su origen en el emisor, y el mensaje Resv que tiene su origen en el receptor:
-Mensaje Path : Su objetivo es primero instalar un estado del encaminamiento inverso a través de la ruta, y segundo proporcionar a los receptores información sobre las características del tráfico a enviar y de la ruta para que se puedan hacer las peticiones de reserva adecuadas.
· Mensaje Resv : Realizan las peticiones de reserva a los routers a lo largo del árbol de distribución entre receptores y emisores. Cada mensaje Path incluye la siguiente información:
b) Proceso y Propagación de los Mensajes Path
Cada router del árbol de distribución intercepta los mensajes Path y chequea su validez. Si se detecta un error el router enviará un mensaje PathErr para informar router hace lo siguiente:
-Actualiza el estado de la entrada de la ruta para el emisor identificado en el Sender Template. Si no existe la ruta la crea. El estado de la ruta incluye Sender Tspec, dirección, Phop del anterior router y opcionalmente el Adspec. La dirección Phop es necesaria para encaminar los mensajes Resv en el sentido contrario.
a) Actualiza los contadores de limpieza de rutas a su valor inicial.
RSVP incorpora un protocolo de mensajes con refresco periódico para mantener una estado de los routers intermedios para proporcionar fiabilidad y seguridad. Para ello, cada entrada en el router tiene un contador asociado que cuando llega a cero se elimina la conexión. Para que esto no ocurra las rutas activas tienen que recibir un refresco por medio del mensaje Path a intervalos regulares. Este periodo debe ser bastante menor que el tiempo de los contadores de limpieza para que no produzcan desconexiones innecesarias.
Aparte de la eliminación de las rutas de forma automática, RSVP incluye el mensaje PathTear para eliminar la ruta de forma activa
Objeto ADSPEC
Objeto ADSPEC
El objeto Adspec se puede incluir en los mensajes Path para enviar a los receptores las características de la ruta de comunicación establecida. Este objeto consiste en una cabecera de mensaje, un fragmento con los parámetros generales por defecto (Default General Parameters), y al menos uno de los dos fragmentos del Servicio Garantizado o Servicio de carga controlado:
Este paquete no puede ser nunca fragmentado, por lo tanto el valor de M de una petición de reserva no puede ser mayor que PathMTU. Toda esta información será actualizada por cada router RSVP a lo largo de la ruta.
Haciendo Reservas usando OPWA
OPWA se refiere al modelo de reserva en el caso en que el emisor incluya en el mensaje Path información Adspec. Si el emisor omite esta información el modelo de
reserva se llama de “Una pasada” (One pass) y en este caso no hay forma sencilla por
parte del receptor de determinar el tipo de servicio obtenido. Cuando el receptor recibe un mensaje Path extrae los siguientes parámetros del Sender Tspec: r, b, p, m. Además también extrae del objeto Adspec los siguientes parámetros: latencia mínima de la ruta, Ctot, Dtot, PathMTU y ancho de banda de la ruta.
El límite requerido para el retraso de cola, Qdelreq se calcula restando la latencia
mínima de la ruta, del valor del retraso de emisor a receptor requerido por la aplicación
receptora. El receptor realizará un chequeo inicial evaluando la ecuación 2 para R igual
a la tasa pico p. Si el resultado es mayor o igual que Qdelreq se utilizará esta formula
para calcular el mínimo valor de R necesario para satisfacer Qdelreq; sino se utilizará la
ecuación 1 para este propósito. Este mínimo valor de R se obtiene insertando Qdelreq
en la ecuación 1 o 2 con los valores determinados de Ctot, Dtot ,r, b, p, M. Si el valor R
excede el ancho de banda obtenido del Adspec recibido se reducirá. El receptor entonces puede crear una especificación de la reserva, Rspec, que contiene el valor R de ancho de banda que se reservará en cada router y un término slack que será inicialmente cero. Rspec forma parte del mensaje Resv cuyos parámetros son los siguientes:
Este mensaje se envía de vuelta por la ruta que ha recorrido. Por cada router que pasa de vuelta, los mensajes se pueden fusionar con otros mensajes Resv con el mismo interfaz, de acuerdo a una serie de reglas que dependen del estilo de reserva, obteniendo un nuevo Flowspec y FilterSpec. Cada router realiza además las siguientes acciones :
·El Flowspec se pasa al módulo de control del tráfico que aplica el control de admisión para determinar si la reserva se acepta.
-Si la reserva es denegada, se envía un mensaje ResvErr.
-Si la reserva es aceptada, el estado de las reservas se actualiza de acuerdo con los parámetros FilterSpec y FlowSpec. La reserva puede ser mezclada con otras reservas de acuerdo con el estilo de reserva, y con esto se creará un nuevo mensaje Resv.
Término slack
Cuando el receptor genera un Rspec en el mensaje Rserv se incluye un término slack, S(ms) que inicialmente es cero. S representa la cantidad por la que el límite del retraso estará por debajo del retraso requerido por la aplicación, asumiendo que cada router de la ruta reserva un ancho de banda R. Este término permite una mayor flexibilidad a los router al hacer sus reservas locales. Cualquier router que use el termino S para reducir su nivel de reserva debe seguir las reglas en la ecuación 3 para asegurar que el límite del retraso de emisor a receptor se satisface.
Donde Ctot i es la suma acumulativa de los términos de error, C para todos los routers
hasta el emisor e incluyendo el actual elemento i . (Rin, Sin) es la petición de reserva
recibida por el router, i. (Rout, Sout) es la petición de reserva modificada unicast del
anterior router en dirección al emisor. En otras palabras este elemento consume Sin- Sout del término slack y puede
usarla para reducir su nivel de reserva asegurando que se cumple la ecuación 3.
Tipos de Encaminamiento RSVP
Aunque se ha visto que RSVP no es un protocolo de encaminamiento si hay cuatro problemas que se deben tratar con el protocolo de encaminamiento:
a) Encontrar una ruta que soporte la reserva de recursos.
b) Encontrar una ruta que tenga la suficiente capacidad disponible para un nuevo flujo. Se puede optar por dos formas diferentes de encontrar esta ruta. Una podría ser la de modificar los protocolos de encaminamiento y gestionarlos de acuerdo a un mecanismo de control del tráfico. Alternativamente, el protocolo de encaminamiento podría ser rediseñado para proporcionar múltiples rutas alternativas, y en la reserva podría intentarlo en cada una de las rutas.
c) Adaptarse a un fallo de ruta. Cuando un nodo falla, el encaminamiento adaptativo encontrará una ruta alternativa. El refresco periódico de RSVP automáticamente hará una reserva en la nueva ruta. Pero, la nueva reserva puede fallar porque no haya suficiente capacidad disponible en la nueva ruta. Esto es un problema de dimensionamiento y calidad de la red, que nop puede ser solucionado por los protocolos de encaminamiento o reserva.
d) Adaptarse a un cambio de ruta (sin fallo) . Los cambios de ruta pueden ocurrir sin que se produzcan fallos. Aunque RSVP podría usar las mismas técnicas de reparación que las descritas en el punto 3, esta solución podría producir una merma en la calidad de servicio. Podría ocurrir que si el control de admisión fallo en la nueva ruta, el usuario verá una degradación del servicio innecesaria y caprichosa, ya que la ruta original está todavía funcional. Para evitar este problema, se sugiere un mecanismo de fijado de rutas (route pinning) en el que las rutas se mantienen fijas mientras sean viables.
Conclusiones
RSVP es un protocolo de reserva de recursos. Soluciona de forma eficiente la mayoría de la problemática presentada. Con la introducción de los flowspec descritos y el control de admisión en los routers se puede convertir en una solución completa para transmisión multimedia si se utiliza como nivel de red IPv6.
