Las comunicaciones de voz o vídeo por Internet requieren utilizar lo que se conoce como técnicas de calidad de servicio o QoS. Estas técnicas se implementan en los nodos de Internet (los routers) formando lo que se conoce como arquitectura de calidad de servicio. Básicamente, existen dos tipos de técnicas: la de servicios diferenciados o DiffServ y la de reserva de recursos o IntServ. El protocolo RSVP es el protocolo de calidad de servicio más utilizado.
Aunque se han desarrollado distintas soluciones que utilizan la técnica IntServ de reserva de recursos, el protocolo más utilizado y que, de hecho, se ha convertido en el estándar para este tipo de servicio es RSVP. Este acrónimo, que significa ReSource reserVation Protocol o protocolo para la reserva de recursos. Curiosamente, también coincide con el acrónimo francés RSVP que puede encontrarse a la entrada de muchos restaurantes y que significa Réserve, S’il Vous Plaît, (Reserve, por favor).
En este artículo describiremos el protocolo más utilizado para la reserva de recursos. Es el conocido como protocolo RSVP.
Cómo funciona el protocolo RSVP
La técnica RSVP está descrita en el documento RFC2205 del IETF, publicado en septiembre de 1997. Mediante este protocolo es posible reservar los recursos necesarios de la red IP (Internet) antes de que comience el intercambio de información de voz o vídeo entre los participantes. Para que esto sea posible, todos los nodos utilizados en la ruta, extremo a extremo, deben ser compatibles con RSVP.
El protocolo de señalización RSVP hace posible que se pueda ofrecer en Internet una calidad de servicio similar a la que se obtiene en las redes telefónicas tradicionales.
El protocolo RSVP basa su funcionamiento en el intercambio de mensajes entre el emisor (la parte que genera la información multimedia de voz o vídeo) y el receptor (la parte que recibe dicha información). Estos mensajes establecen una ruta de nodos intermedios entre uno y otro extremo de la comunicación que se conservan hasta el final de la misma.
La reserva de recursos comienza con el envío de un mensaje Path desde el terminal emisor hasta el receptor. Este mensaje va dejando una marca en los nodos por los que va pasando, dejando así establecida la ruta. Al llegar al destino, se genera una respuesta con un mensaje Resv que recorre en sentido inverso el mismo camino, reservando los recursos necesarios en cada nodo. Si se confirma la reserva de todos los tramos, se establece la comunicación, en caso contrario, el nodo afectado le enviará un mensaje de error al receptor.
RSVP realiza la reserva de recursos de forma unidireccional. Esto quiere decir que, si el intercambio de información es bidireccional, se necesitará realizar una reserva de recursos para cada sentido. El hecho que la reserva se haga unidireccionalmente hace posible que se pueda utilizar este protocolo para las retransmisiones, por ejemplo, de radio o televisión.
El protocolo RSVP tiene en cuenta que una comunicación puede contar con más de un receptor (por ejemplo, en multicast). En este caso se realiza una reserva por cada receptor. Como la información transmitida es la misma en los tramos de la ruta que comparten varios receptores, en estos tramos se realiza una única reserva de recursos. El hecho de que la reserva se realice desde el receptor hacia el emisor favorece esta labor.
Los nodos intermedios mantienen un registro de estado (soft state) de cada una de las comunicaciones, donde guardan la identificación de la sesión y los recursos reservados a la misma. Los registros de estado tienen un tiempo de expiración. Esto obliga a los emisores y receptores a enviar de forma periódica sus mensajes de mantenimiento de la reserva. Si un registro de estado cumple el tiempo de expiración, se elimina la reserva del nodo y se envía un mensaje de error a los participantes de la sesión.
Mensajes de control de RSVP
Cada mensaje RSVP se compone de una serie de objetos. Cada objeto contiene un tipo distinto de información. Por ejemplo, un objeto identifica la sesión, otro identifica al emisor, otro contiene los parámetros de calidad, etc. Dependiendo de la finalidad del mensaje se incluyen unos objetos u otros.
Los mensajes principales son Path, que lo utiliza el emisor para marcar la ruta, y Resv, utilizado por el receptor para solicitar la reserva de recursos. El resto de mensajes tienen que ver con la comunicación de errores y la eliminación de la reserva.
Parámetros para la reserva de recursos
El protocolo RSVP tiene una forma particular de reservar recursos en un nodo, utiliza un sistema conocido como cubo de testigos (token bucket). Esto quiere decir que el nodo dispone de un registro (al que llama cubo) que almacena testigos. El cubo tiene una capacidad máxima de almacenamiento de testigos (b). Por otro lado, el cubo se va llenando automáticamente de testigos a una velocidad r (testigos por segundos).
Para regular el tráfico en una ruta determinada a su paso por el nodo, cada vez que se le da paso a un paquete se disminuye la capacidad del cubo en tantas unidades, tantos testigos, como bytes tenga el paquete. Quiere esto decir que si se dispone de un tráfico de entrada P (bytes por segundos), menor que la velocidad r de recarga del cubo, dicho tráfico de entrada saldrá del router sin ningún retardo. El cubo se irá llenando poco a poco de testigos hasta alcanzar el valor b. Por el contrario, si P es mayor que r, el cubo se irá vaciando de testigos hasta que el número de testigos disponibles sea menor que el tamaño del paquete. En este caso, el paquete se desechará directamente o se pondrá en cola hasta que el cubo acumule el número de testigos suficientes.
Con este sistema, no sólo se garantiza un ancho de banda r, sino que se asumen ciertos picos a velocidades mayores durante un cierto tiempo. El tamaño y duración de los picos se regula por la capacidad del cubo (b). El resultado es que la velocidad media no será nunca superior a r, aunque puedan existir picos superiores que serán compensados con sus valles correspondientes.
Aunque se utiliza el símil del cubo, en realidad, el sistema de cubo de testigos consiste en un registro numérico que incrementa su valor a la velocidad r hasta un valor máximo b. De la misma forma, se decrementa en una unidad por cada byte que deja pasar el router. Adicionalmente, los parámetros de definición de la calidad de servicio ofrecida con el sistema de cubo de testigos se complementan con la definición de los tamaños máximo (M) y mínimo (m) de los paquetes (en bytes), así como la velocidad máxima del tráfico de entrada (p). Por cierto, si algún paquete sobrepasa el tamaño M, el nodo no lo trata con la QoS solicitada, sino que lo enruta como el resto del tráfico de datos. Si, por el contrario, tuviera un tamaño menor que m, se le trataría como si el tamaño fuese m.
El conjunto de parámetros que definen las características del cubo de testigos se conoce como TSpec (Traffic Specification, ‘Especificación del tráfico’) y están recogidos en la RFC2215.
Otro parámetro que se utiliza en el control de la calidad de servicio es el conocido como RSpec (Request Specification, ‘Especificación de la solicitud’), el cual está formado por los valores R (Rate, ‘Velocidad’, en bytes por segundos) y S (Slack, ‘Holgura’, en microsegundos). El primero de ellos indica un ancho de banda solicitado. Este ancho de banda debe ser igual o mayor que r. Al ser mayor se está solicitando un ancho de banda extra, lo que mejora la calidad ofertada, disminuyendo las colas. El valor S indica la diferencia entre el retardo deseado y el retardo que se conseguiría si se utilizase el ancho de banda R.
Niveles de servicio
Utilizando los parámetros TSpec y RSpec, los nodos compatibles con RSVP pueden ofrecer dos niveles de servicio:
- Carga controlada (Controlled load). Utiliza mecanismos de control de admisión para garantizar recursos incluso cuando los nodos de red están sobrecargados. El resultado es un bajo retardo, aunque no existe una garantía total. El objetivo es que se ofrezca una calidad de servicio similar al que ofrecería la red cuando no está sobrecargada. Este tipo de calidad de servicio se conoce como Soft QoS y está recogido en RFC2211.
- Garantizado (Guaranteed service). En este caso, el protocolo garantiza la QoS en términos de ancho de banda, retardo extremo a extremo, fluctuaciones de retardo, etc. Este servicio está recogido en RFC2212 y requiere que todos los nodos de la red IP por los que pasa el flujo lo soporten.
Para implementar el servicio de carga controlada sólo es necesario definir los parámetros TSpec. Por otro lado, para el servicio garantizado es necesario definir los parámetros TSpec y RSpec.
Más información
Aquí se ha expuesto de forma resumida cómo funcionan el protocolo RSVP de reserva de recursos. Con suerte, habré sido capaz de generar dudas y crear curiosidad sobre este tema. En este blog se dispone de muchos otros contenidos relacionados. Por favor, utilice el buscador de contenidos que tenemos en la cabecera de este blog.
Estos son algunos otros artículos que pueden ser de interés:
- Cómo funciona la telefonía IP o VoIP
- El proceso de reserva RSVP
- Protocolos de señalización para VoIP
- RTP. Protocolo de transporte en tiempo real
REF: VOIP PG200