ALGORITMOS PARA ENCRIPTACI?N DE DATOS

2.4.7.4 RSVP (Resource ReSerVation Protocol)

2.4.7.4.1 Introducción

RSVP se ha diseñado para permitir a los emisores, receptores y routers de las sesiones de comunicación (tanto multicast como unicast) comunicarse con el resto para establecer una ruta que pueda soportar la calidad de servicio requerida. RSVP identifica una sesión por medio de una dirección de destino, un tipo de protocolo de transporte y un número de puerto de destino. RSVP no es un protocolo de encaminamiento; se usa meramente para reservar recursos a través de la ruta que se establezca por cualquiera de los protocolos de niveles inferiores.

Hay una extensión de RSVP para su uso en redes compartidas como LAN, que es denominada SBM (Subnet Bandwidth Manager). El problema en este tipo de redes compartidas es que el protocolo RSVP falla. Esto es debido a que sus mensajes deben pasar por varios dispositivos usando el nivel-2 (puentes, etc) que no conocen el protocolo RSVP de nivel 3 y superiores, con lo que no se pueden gestionar los recursos.

Aunque RSVP en principio es sólo un protocolo de reserva de recursos se suele asociar a las especificaciones de flujos definidas por el grupo IntServ, así como su control de admisión.

2.4.7.4.2 Objetivos de diseño

RSVP se ha diseñado con los siguientes objetivos:

1. Proporcionar la posibilidad de que receptores heterogéneos puedan hacer reservas de acuerdo a sus necesidades. No se debe asumir que todos los receptores tienen las mismas capacidades ni que requieran la misma calidad de servicio.

2. Debe adaptarse a las variaciones de miembros en grupos multidifusión. La conexión o desconexión de los miembros de un grupo debe ser dinámica.

3. Permitir a los usuarios especificar sus necesidades a nivel de aplicación para que los recursos reservados para un grupo multidifusión puedan reflejar con precisión los recursos necesitados por el grupo.

4. Permitir a los receptores seleccionar entre varios canales. El receptor debería poder seleccionar entre varias fuentes sin el riesgo de que la petición de este cambio fuera denegada, como podría ocurrir si se estableciese una nueva petición. Esto es posible si los recursos reservados por el receptor son reutilizados para la transmisión de esta fuente.

5. Debe adaptarse a los cambios en los rutas uni y multidifusión. RSVP no es un algoritmo de encaminamiento, utiliza el nivel de red para estos propósitos, pero si debe mantener un estado de las rutas.

6. Controlar la sobrecarga que produce el protocolo en la red para que no crezca linealmente o con el número de participantes.

7. Hacer el diseño modular para acomodar distintas tecnologías.

2.4.7.4.3 Principios de diseño:

Para obtener los objetivos vistos en el punto anterior, el diseño de RSVP se basa en seis principios básicos:

1. Reserva iniciada por el receptor. Los receptores escogen el nivel de servicio requerido y son responsables de iniciar y mantener la reserva activa mientras quieran recibir datos. Esto es así, porque el receptor es quien conoce sus limitaciones y la calidad de servicio que recibe. Además, esto permite la gestión de peticiones heterogéneas.

2. Filtro de paquetes. La reserva de recursos en un router asigna ciertos recursos a la entidad que hace la reserva, pero no determina qué paquetes pueden usar estos recursos. Hay una función separada, llamado filtro de paquetes, que selecciona los paquetes que pueden usar estos recursos. Este filtro puede ser estático o dinámico y permite establecer varios modelos de reserva.

3. Proporcionar varios estilos de reserva. Por medio del filtro de paquetes se pueden definir diferentes modelos de reserva. Actualmente existen tres estilos: libre, filtro fijo y filtro dinámico.

4. Mantener un estado (“soft-state”) de la red. Durante una comunicación larga es posible que nuevos miembros se unan al grupo mientras que otros lo dejen, y las rutas pueden modificarse debido a cambios en la red. Por eso, RSVP debe mantener un estado de la red.

Esta información se mantiene por medio de mensajes que periódicamente se envían para refrescar el estado. RSVP distingue dos clases de información en cada router: el estado de la ruta y el estado de la reserva.

5. Control de sobrecarga del protocolo. La sobrecarga de RSVP se determina por tres factores: el número de mensajes RSVP enviados, el tamaño de estos mensajes y las frecuencias de refresco de los mensajes de ruta y reserva. Para reducir la sobrecarga, RSVP funde los dos mensajes mientras atraviesan la red.

6. Modular. RSVP tiene interfaz con otros tres componentes en la arquitectura: (1) la especificación de flujo (flowspec) que se maneja a nivel de aplicación o sesión; (2) el protocolo de encaminamiento de red, que lleva los mensajes hasta los receptores; (3) el control de admisión en red, que realiza las decisiones basado en el flowspec que está en los mensajes de reserva.

En la Figura 2.9. se muestra como encaja RSVP dentro de los routers, emisores y receptores.

2.4.7.4.4 Clases de calidad de servicio

IETF ha considerado varias clases de calidad de servicio, aunque sólo dos han sido formalmente especificadas para RSVP: Servicio Garantizado (Guaranteed Service) [Schenker96] y Servicio de Carga Controlada (Controlled-Load Service )[Wroclawski96].

2.4.7.4.4.1Servicio garantizado

Esta calidad de servicio está destinada para aplicaciones con requerimientos exigentes de tiempo real. Esta calidad asegura: un ancho de banda, un límite en el retraso y ninguna pérdida en las colas.

Como introducción, un flujo es descrito usando un modelo token bucket y dada esta descripción, cualquier elemento de la red (un router, una subred, etc.) calcula varios parámetros describiendo cómo va a manejar los datos del flujo. Combinando los parámetros de los distintos elementos que recorre el flujo, es posible calcular el retraso máximo que se producirá en el flujo.

Cada router caracteriza el servicio garantizado para un flujo determinado, asignando un ancho de banda R, y un espacio de memoria (buffer space) B, que representa los recursos que el flujo puede consumir. Esto representa que existe un ancho de banda R entre emisor y receptor. Así, para un servicio que siga el modelo de flujo perfecto con un cubo de capacidad b y tasa r, se puede calcular el límite del retraso como b/R siempre que R sea mayor r. Para permitir desviaciones sobre este modelo perfecto se añaden dos términos de error C y D; con lo que el límite del retraso se convierte en b/R +C/R + D.

Estos errores aparecen al trabajar con paquetes. Por ejemplo, cualquier paquete puede experimentar un retraso debido a paquetes de su propia cola o debido a imprecisiones del planificador. El término C es el error dependiente de la tasa y representa el retraso que un paquete en el flujo puede experimentar debido a la tasa reservada. El término de error D es el error independiente de la tasa y representa el peor caso de variación de tiempo de tránsito a través del router.

Sin embargo, con el servicio garantizado se impone una cota superior a la tasa de transmisión que es la tasa pico del flujo p, que reduce los límites del retraso. Además, se tienen que tener en cuenta los efectos de la partición en paquetes en el flujo considerando el tamaño máximo del paquete, M. Esto nos permite disponer de un límite más preciso para el retraso:

Donde Ctot y Dtot representan el sumatorio de los términos de error C y D de cada router de la ruta. Es importante fijarse que la ecuación (9) no depende de los parámetros del flujo, debido a que como la reserva R es mayor que la tasa pico de la carga p no hay posibilidad de que los paquetes se encolen en la red.

Para que este retraso se cumpla se tiene que cumplir que el tráfico entrante esté conforme al algoritmo token bucket, es decir, el tráfico está limitado por la siguiente ecuación min[pt,b+rt].

Cada router necesita ser informado de las características del tráfico, Tspec, y del flujo con las características de las reservas realizadas, Rspec. Además, necesita los términos Csum y Dsum que representan la suma de los términos de error C y D de cada router desde el origen del mensaje. Los parámetros Tspec y Rspec están enumerados en la Tabla 2.7.

Para utilizar este esquema los routers tienen que aproximarse al modelo de flujo. Para ello, se pueden utilizar varios algoritmos de planificación como por ejemplo el visto en líneas anteriores: el WFQ (Weighted Fair Queueing).

Concretamente, con el planificador WFQ, los parámetros Ci y Di pueden ser calculados de la siguiente forma: Di es igual al MTU (Maximum Transmission Unit) del enlace dividido por el ancho de banda del enlace, con la condición de que M debe ser menor que el mínimo MTU del path.

El valor de Ci se asume que es M para considerar la fragmentación en paquetes. Esto es:

Respecto al tamaño del buffer a reservar en los nodos, el tamaño necesario en cada nodo es b+Csum+Dsumr, donde Csum y Dsum son la suma de todos los parámetros Ci y Di anteriores al nodo.