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:
Se utiliza este término para un modelo de servicio Internet que incluya el servicio best-effort, el servicio en tiempo real, y la compartición controlada del enlace. En este modelo, la tradicional entrega best-effort de los paquetes coexistirá con unas opciones mejoradas de entrega de los mismos basadas en las especificaciones de ciertas clases de QoS [RFC1633].
Este modelo permite asignar diferentes niveles de servicio a diferentes usuarios de Internet. En general, en el uso en Internet se entiende este término como cualquier mecanismo que no dependa completamente de la reserva de recursos hecha para cada flujo de datos, y que trate a los distintos usuarios de forma diferente. No obstante, el rango de esta definición está todavía bajo debate [DiffServ].
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:
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:
Algunas características o aspectos fundamentales en el RSVP son:
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:
Este servicio proporciona un nivel de ancho de banda y un límite en el retardo, garantizando la no existencia de pérdidas en colas. Está pensado para aplicaciones con requerimientos en tiempo real, tales como ciertas aplicaciones de audio y vídeo. Cada router caracteriza el SG para un flujo específico asignando un ancho de banda y un espacio en buffer
A diferencia del SG este servicio no ofrece garantías en la entrega de los paquetes. Así, será adecuado para aquellas aplicaciones que toleren una cierta cantidad de pérdidas y un retardo mantenidos en un nivel razonable. Los routers que implementen este servicio deben verificar que el tráfico recibido siga las especificaciones dadas por el Tspec, y cualquier tráfico que no las cumpla será reenviado por la red, como tráfico best-effort.
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í:
COMP. |
CISCO |
DEC |
FORE |
HP |
IBM |
INTEL |
MS |
SUN |
PLATAF. |
Router |
Host |
Router, host, Toolkit |
Host |
Router |
Router, Host |
Host |
Host, toolkit |
S.O |
IOS |
Digital Unix |
---------- |
HP-UX |
IBM |
W95, WNT |
W95, W98, WNT |
Solaris |
TECNO. DE RED |
ATM,
FRL,Eth, T.Ring, FDDI |
Eth, T.Ring, FDDI |
---------- |
Eth |
ATM,
FRL,Eth,
T.Ring, FDDI |
------- |
ATM, Eth, T.Ring, FDDI |
--------- |
DISPONB. |
Venta |
Público y gratis |
Uso interno |
Gratis empresas |
Productos IBM |
Venta |
Con W98 y WNT |
Venta |
QoS |
CL |
CL |
CL, GS |
CL |
CL |
CL |
CL, GS |
CL |
APLICAC. |
Telefonía, Videocon |
TelefoniaVideocon |
Uso router |
-------- |
VDN/VPN |
------- |
Telefonía, videocon. |
--------- |
NO SOPORT. |
Ipv6, IPESEC |
UDP
encap., IPSEC |
Tunel, diagnost. |
GS,
IPSEC,
MIB |
Blockade state,
MIB |
--------- |
------- |
Confirm, MIB |
INTEROP. |
ISI, Intel, MS |
Sun Solaris, MS, WNT |
--------- |
Cisco Router |
Intel W95 |
Cisco, Sun Solaris |
Cisco, Intel, Sun host |
--------- |
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.
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:
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.
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]:
Hay tres problemas fundamentales que afectan al funcionamiento del protocolo RSVP, la escalabilidad, el routing y el no poder trabajar sobre redes no RSVP.
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.
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