Protocolo RSVP: Evolución y experiencias

1.- Introducción

Originalmente Internet, tal y como fue concebida, ofrecía sólo una simple QoS, basada en la entrega best-effort de datos punto a punto. En la actualidad, aplicaciones en tiempo real, como vídeo remoto, conferencias multimedia o realidad virtual, no funcionan bien bajo esta definición de red, debido a los retardos variables en colas y las pérdidas por congestión. Antes de que estas aplicaciones sean ampliamente utilizadas, la infraestructura de red debe ser modificada para soportar calidad de servicio en tiempo real, la cual permita algún control sobre los retardos de paquetes extremo-extremo. Además los operadores de red, solicitan disponer de la capacidad para controlar la repartición del ancho de banda de un enlace entre diferentes clases de tráfico, lo cual conlleva la necesidad de dividir el tráfico total en varias clases y asignar a cada una de éstas un mínimo porcentaje del ancho de banda total bajo condiciones de sobrecarga (compartición del enlace). Estas distintas clases pueden representar distintos grupos de usuarios o distintos protocolos.

A todas estas características sobre la transmisión de datos por una red, retardos, jitter, pérdidas, throughput, se las define como servicio. Así se refieren dos tipos de servicios:

• Integrated services:

• Differentiated services:

2.- Integrated Services

Cualquier servicio de INTERNET debe permitir a las aplicaciones, escoger entre varios niveles de servicio de entrega de los paquetes que generan. Para permitir estas funcionalidades se requiere:

• Los elementos a lo largo del camino (nodos y subredes) han de disponer de mecanismos para controlar la QoS. Tales mecanismos los proporcionan los servicios de control de QoS como Controlled-Load y Guaranteed Services
• Debe existir un procedimiento para solicitar, desde la aplicación hacia las subredes, los requerimientos a lo largo del camino. Este procedimiento viene dado por un protocolo de establecimiento de reservas como por ejemplo el RSVP [RFC2205], el cual es compatible con los requerimientos del modelo Integrated Services de Internet

Hay dos mensajes RSVP fundamentales, Resv y Path. Una aplicación solicita participar en una sesión RSVP como emisor, enviando un mensaje Path en el mismo sentido que el flujo de datos, por las rutas uni/multicast proporcionadas por el protocolo de routing. A la recepción de este mensaje, el receptor transmite un mensaje Resv, dirigido hacia el emisor de los datos, siguiendo exactamente el camino inverso al de los mismos, en el cual se especifica el tipo de reserva a realizar en todo el camino.

En general, sin especificar tipos de QoS un mensaje Path, contiene:

• Sender Template: Parámetro por el cual se describe el formato de los paquetes que el emisor generará
• Sender Tspec: Describe el tráfico que la aplicación estima que generará.
• Adspec: Información sobre la QoS y propiedades de la aplicación
• Dirección del PHOP: Necesaria para poder encaminar los mensajes Resv.

Algunas características o aspectos fundamentales en el RSVP son:

• Merging: En los diferentes nodos que se van atravesando en la red por el camino de datos, se va realizando un proceso de concentración de los diferentes mensajes de petición de reservas
• Estado de reserva en cada nodo: El estado soft RSVP se crea y refresca periódicamente por mensajes Path y Resv.
• Estilos de reserva: Una petición de reserva incluye un conjunto de opciones que se conocen como el estilo de reserva. Las distintas combinaciones de estas opciones conforman los tres estilos de reserva en uso, Wildcar-Filter (WF), Fixed-Filter (FF) y Shared-Explicit (SE).

3.- Mecanismos de reserva de recursos

Dado que cualquier protocolo de establecimiento de las reservas ha de ser capaz de trabajar con cualquier servicio de QoS, éstos no definirán los objetos propios y necesarios para definir la misma. Para la gestión de la QoS el protocolo RSVP, define tres objetos propios, como son el FLOWSPEC, ADSPEC y SENDER_TSPEC.

En cada elemento de red, el ADSPEC se pasará al módulo de control de tráfico, el cual determinará si el servicio QoS especificado está implementado en el nodo. Por defecto se generará un objeto que soportará todos los servicios QoS que admite el emisor. Cuando el mensaje Path llega a un receptor, los datos del SENDER_TSPEC y ADSPEC se pasan a través de la API (Aplication Programming Interface) a la aplicación, la cual interpretará estos datos, y los utilizará para seleccionar parámetros de reserva de recursos.

Todo elemento en una red, utiliza un conjunto de parámetros de caracterización (usados para caracterizar el camino) y de control (usados para dar información a la red sobre las peticiones de QoS) denominados generales (definición común, pero significado compartido por todos los servicios de QoS) para describir las propiedades del camino [RFC2210]. En general a estos valores se les asigna un valor por defecto, y si en algún nodo algún parámetro contiene

un valor distinto, se deberá definir un valor de servicio específico para este parámetro. Además, las especificaciones de los distintos servicios QoS pueden implementar estas definiciones de parámetros, así como definir parámetros específicos adicionales, y todos ellos vendrán identificados por un ID, basado en 2 parámetros, el service_number que identifica el servicio asociado con el parámetro, y el parameter_number que identifica al propio parámetro.

El grupo de trabajo Integrated Services del IETF ha considerado la existencia de varias clases de QoS, si bien actualmente sólo dos de éstas han sido formalmente especificadas para ser utilizadas con RSVP:

• Guaranteed Service (service_number 2)[RFC2211]:

• Controlled-Load Service (service_number 5)[RFC2212]:

4.- Implementaciones RSVP/QoS

A partir de las especificaciones publicadas en los diferentes RFCs, más de 30 empresas del mundo de la informática y las telecomunicaciones han decidido realizar diferentes implementaciones del protocolo, tanto en su comportamiento como router como en el de host, junto con la realización de diferentes herramientas de aplicación [Gen98].

Vamos a analizar el estado actual de dichas implementaciones para aquellas empresas más destacadas del sector, teniendo en cuenta el sistema operativo utilizado, la tecnología de red, la capacidad de QoS, las aplicaciones, qué características no son soportadas, la interoperabilidad y la disponibilidad del producto [Tabla 1]. Así:

• Los sistemas operativos utilizados están en función del sistema que cada compañía utiliza en sus equipos, siendo los sistemas más utilizados: Solaris, Linux, Windows 95 y Free-BSD, cada uno de ellos en sus versiones actuales.
• La tecnología de red utilizada es prácticamente común en casi todas ellas: ATM, Frame Relay, Ethernet shared, Ethernet switched, Token Ring y FDDI.
• Respecto a la capacidad de QoS, todos los productos cumplen con las especificaciones de RSVP y de Integrated Services ofreciendo servicio Controlled Load. El Guaranteed Service sólo está disponible en una decena de implementaciones. La opción Differentiated Services es minoritaria encontrándose en proceso de implantación en algún caso.
• Los productos realizados se ofrecen para aplicaciones de telefonía y videoconferencia esencialmente, y en algún caso se proponen para ser utilizados en asignación de ancho de banda para usuarios preferentes y Virtual Dedicated Network/VPN.
• La disponibilidad está dividida entre productos en venta y productos gratuitos disponibles al público. El resto son de uso interno, gratis sólo para organizaciones o bien se encuentran incluidos en otros productos del mismo fabricante.

Es interesante conocer cuales son las características del protocolo que todavía no están implementadas y que cada fabricante, en función del grado de desarrollo que tenga su producto, indica como futuras realizaciones. Así, la compatibilidad con el protocolo IPv6, el servicio Guaranteed y el IPSEC son las referencias de no implementación más señaladas. Además, algunos productos no contemplan encapsulación UDP, realización de túneles para el paso por redes no-RSVP, mensajes de diagnóstico y autentificación.

Por último, algunos fabricantes han comprobado la interoperabilidad con otras plataformas aunque no indican el grado de efectividad conseguido. Así, 26 de los 39 productos han sido testeados con otras implementaciones, de entre las que destacan Cisco router, Windows 95 y Solaris.

5.- RAPI

La RSVP Aplication Programming Interface proporciona a la aplicación los mecanismos necesarios para comunicarse con el RSVP daemon de tal forma que se pueda realizar la reserva oportuna en todo el camino de datos [Figura 1] [Bra98].

Un proceso RSVP se inicia a partir de la llamada SESSION definida por la dirección destino, el identificador de protocolo y un puerto destino. Si la llamada tiene éxito, retorna un identificador de sesión. Cuando una aplicación desea iniciar el envío de un flujo de datos, activa la llamada SENDER que define los atributos de dicho flujo, a partir de los siguientes parámetros:

• Source_Address: dirección del interface desde el cual se enviarán los datos. Este parámetro sólo en necesario en hosts multihomed.
• Source_Port: puerto UDP/TCP .
• Sender_Tspec: describe el flujo de datos que se desea enviar.
• Adspec: informa sobre el estado de la red para poder iniciar el cálculo de las propiedades de QoS que se establecerán en el camino.

Los parámetros Data_TTL, Policy_data y Sender_Template son opcionales en las versiones actuales de RAPI (rel4.2a3 de ISI [ISI98]).

Una vez activada la llamada SENDER para la sesión registrada con el identificador session_id, RSVP empieza a enviar mensajes Path hacia el receptor a través de la red. Cuando un mensaje Path llega al receptor se activa la función PATH_EVENT que entrega la información recibida a la aplicación para que realice los cálculos de la QoS necesaria.

El receptor activa la llamada RESERVE y el RSVP daemon empieza a enviar mensajes Resv que contienen los objetos necesarios (Flowspec, Filterspec,...) para establecer la reserva a través del camino de datos.

Tanto los mensajes Path como los mensajes Resv se van generando periódicamente para refrescar el estado del camino, hasta que la sesión finaliza.

Una vez realizada la transmisión de los datos, se activa la llamada RELEASE que generará mensajes Teardown (PATH_TEAR y RESV_TEAR) para que cese el envío de mensajes de refresco finalizando, de esta forma, el estado RSVP para la actual sesión.

6.- Experiencias

Las pruebas realizadas para comprobar el funcionamiento del protocolo RSVP se han hecho sobre diferentes plataformas pertenecientes a la infraestructura del CCABA (Centre de Comunicacions Avançades de banda Ampla) y enmarcadas en el proyecto SABA (Servicios para la red Académica de Banda Ancha). A tal efecto se ha utilizado la versión RSVP Release 4.2a3, generada por el Computer Science Department de la Columbia University para la versión Linux, y la generada por el USC Information Sciences Institute para la versión de Solaris, basada en un RSVP daemon o RSVPD y un RTAP, para la realización de pruebas entre el daemon RSVP y la RAPI.

Las pruebas han sido las siguientes[Figura 2]:

• sesión unicast entre dos equipos de la misma LAN bajo los mismos sistemas operativos (SUN,SOLARIS). Los resultados obtenidos son, correcto envío y recepción de mensajes Path y Resv.
• sesión unicast entre dos equipos de la misma LAN bajos sistemas operativos diferentes (LINUX[@IP:193.146.185.122] - SOLARIS[@IP:193.146.185.121]). Los resultados obtenidos son: correcto envío y recepción de mensajes Path y Resv de LINUX a SOLARIS.
• sesión unicast entre dos equipos de la misma LAN con un router en medio.
• sesión unicast entre Windows95 y SOLARIS con un router en medio. Entre PC y router existe una Ethernet, y entre router y SUN, LANE. Los resultados obtenidos son la visualización de mensajes Path.

7.- Conclusiones

Hay tres problemas fundamentales que afectan al funcionamiento del protocolo RSVP, la escalabilidad, el routing y el no poder trabajar sobre redes no RSVP.

• El problema de la escalabilidad existe, dada la gran cantidad de señalización que aparecerá conforme la red vaya aumentando de tamaño, tanto en cuanto a rutas como en cuanto a usuarios.
• El routing conlleva un problema, dado que el proceso de encaminamiento se realiza en el instante de establecer la sesión y enviar el mensaje Path. En este punto, los algoritmos de encaminamiento utilizados no tienen en cuenta cuales van a ser las características de reserva solicitadas por el receptor, con lo cual puede que la decisión adoptada para establecer la ruta, no sea la más adecuada teniendo en cuenta sólo los parámetros de caracterización del tipo de QoS elegido.
• La certeza de que la ruta establecida podrá contener dispositivos intermedios que no implementen el protocolo RSVP, hará que la reserva extremo a extremo esté condicionada por dichos sistemas.

Respecto a las experiencias realizadas, es preciso comentar que es necesario conseguir una interoperabilidad completa entre los diferentes sistemas tanto para sesiones unicast como para sesiones multicast junto con la obtención de reservas correctas en los diferentes nodos en presencia de tráfico interferente.

Referencias

Sergi Sánchez,
 sergio [at] ac [dot] upc.es
Xavi Masip
 xmasip [at] ac [dot] upc.es
Jordi Domingo
 jordi [dot] domingo [at] ac.upc.es
Departamento de Arquitectura de Computadores
UPC