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). El protocolo RSVP es el protocolo de calidad de servicio más utilizado. Aquí veremos cuál es el formato de los mensajes RSVP que se intercambian los nodos para reservar los recursos necesario que garanticen una comunicación de voz y vídeo de calidad.
RSVP es un acrónimo que significa ReSource reserVation Protocol o protocolo para la reserva de recursos. 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 hacerlo, hay un intercambio de mensajes entre emisor y receptor con los que se define la ruta y se reservan recursos de todos los nodos intermedios. Esta ruta y recursos se conserva hasta el final de la comunicación.
Formato de los mensajes RSVP
Los mensajes RSVP utilizan el protocolo de transporte UDP sobre paquetes IP que tienen el número de protocolo IP 46. Al utilizar UDP no existe retransmisión de los paquetes perdidos o recibidos con error, no obstante, estos mensajes se retransmiten periódicamente, por lo que esto no suele ser un problema.
Los mensajes RSVP consisten en una cabecera común seguida por un cuerpo que está formado por un número variable de objetos. Los objetos contienen los distintos tipos de información que se desea intercambiar.
La cabecera común tiene una longitud fija de 8 bytes y está formada por los siguientes campos:
- Version (versión). Número de la versión de RSVP.
- Flags (indicador). No definido actualmente.
- Message Type (tipo de mensaje). Indica el tipo de mensaje RSVP. Actualmente están definidos los siguientes tipos:
(1) Path, (2) Resv, (3) PathErr, (4) ResvErr, (5) PathTear, (6) ResvTear, (7) ResvConf. - RSVP Checksum (suma de control RSVP). Suma de control del mensaje. Si no se utiliza suma de control se le da el valor 0.
- Send_TTL (TTL del envío). Es el valor TTL (Time To Live, ‘Tiempo de vida’) del mensaje. A este valor se le decrementa en una unidad en cada salto.
- RSVP_Length (longitud RSVP). Longitud total de este mensaje, incluyendo la cabecera común. La longitud de la cabecera es siempre 8 bytes.
En la cabecera de los paquetes IP se incluye el campo TTL que cada nodo va descontando en una unidad. Por otro lado, en la cabecera de los mensajes RSVP se incluye otro campo TTL que los nodos intermedios compatibles con RSVP también van descontando en una unidad. Si todos los nodos intermedios fueran compatibles con RSVP, el valor de ambos campos TTL debiera ser el mismo; en caso contrario, el TTL de la cabecera RSVP será mayor que el de la cabecera IP. Por tanto, el campo Send_TTL puede utilizarse para determinar si existe algún router no compatible con RSVP.
Tipos de mensajes
Aunque los mensajes más utilizados en RSVP son Path y Resv, el protocolo cuenta con los siguientes siete mensajes diferentes:
- Path (ruta). Utilizado por el emisor para iniciar el proceso de reserva de recursos. Con este mensaje se marca la ruta que se utilizará durante toda la sesión. El mensaje Path está formado por la cabecera común, seguido de varios objetos, entre los cuales, los obligatorios son Session, Rsvp_Hop y Time_Value, aunque también se pueden incluir estos otros: Integrity, Policy_Data, Sender_Template, Sender_TSpec o ADSpec.
- Resv (reserva). Lo utiliza el receptor para solicitarles a los nodos intermedios que reserven los recursos solicitados (los necesarios para obtener la calidad de servicio deseada). Este mensaje está formado por la cabecera común seguida por varios objetos, entre los que obligatoriamente deben estar Session, Rsvp_Hop, Time_Value y Style. Otros objetos que suelen incluirse en este mensaje son: Integrity, Policy_Data, Scope, FlowSpec y Filter_Spec.
- Path Teardown (clausura de la ruta). Se utiliza para eliminar los registros de ruta (path state) a lo largo de la ruta. Cada nodo elimina sus registros y le pasa el mensaje al nodo siguiente hasta llegar el receptor. Este mensaje lo puede enviar el emisor o cualquier nodo intermedio en el que haya expirado la reserva. Los objetos obligatorios para este mensaje son Session y Rsvp_Hop.
- Resv Teardown (clausura de la reserva). Utilizado para eliminar los registros de la reserva de los nodos (reservation state) a lo largo de la ruta. Cada nodo elimina sus registros y le pasa el mensaje al nodo siguiente hasta llegar al emisor. Este mensaje lo puede enviar el receptor o cualquier nodo intermedio en el que haya expirado la reserva. Los objetos obligatorios para este mensaje son Session, Rsvp_Hop y Style.
- Path Error (error de ruta). Se le envía al emisor para indicarle que ha habido un error con su mensaje Path. El mensaje Path_Error va pasando de nodo en nodo hasta llegar al emisor. La única finalidad de Path_Error es la de informar al emisor, por lo que no modifica ningún estado en los nodos de la ruta. Los objetos obligatorios que hay que incluir en este mensaje son Session y Error_Spec.
- Resv Error (error en la reserva). Se utiliza para notificarle al receptor de que ha habido un error con el mensaje Resv. El mensaje Resv_Error se va pasando de nodo en nodo hasta llegar al receptor. Los objetos obligatorios que se incluyen en este mensaje son Session, Rsvp_Hop, Style y Error_Spec.
- Confirmation (confirmación). Se utiliza para confirmarle al receptor que la reserva se ha realizado correctamente. Este mensaje incluye obligatoriamente los objetos Session, Style, Resv_Confirm y Error_Spec.
Como puede verse, además de los mensajes Path y Resv utilizados para reservar los recursos, existen mensajes para eliminar la reserva y para comunicar los posibles errores que hayan podido aparecer.
Formato de los objetos
Los objetos están formados por uno o más bloques de 32 bits donde el primero de ellos es la cabecera del objeto y el resto su contenido. La cabecera del objeto está formada por tres campos:
- Length (longitud). Longitud total del objeto en bytes.
- Class-Num (número de la clase). Se trata del número que identifica al objeto. Las clases de objetos son las siguientes:
(1) Session, (3) Rsvp_Hop, (4) Integrity, (5) Time_Value, (6) Error_Spec, (7) Scope, (8) Style, (9) FlowSpec, (10) Filter_Spec, (11) Sender_Template, (12) Sender_TSpec, (13) Adspec, (14) Policy_Data, (15) Resv_Confirm - C_Type (tipo de clase). Este número permite utilizar distintas versiones de un mismo objeto. Generalmente, identifican la versión del protocolo IP utilizado, por ejemplo:
(1) IPv4, (2) IPv6 con número de puerto, (3) IPv6 con etiqu. flujo, (4) IPv4/IPSec, (5) IPv6 con IPSec
Objetos de los mensajes RSVP
En la actualidad existen siete tipos distintos de mensajes RSVP. Cada uno de estos mensajes se compone de una serie de objetos obligatorios y otros optativos.
Los objetos más comunes utilizados por los mensajes RSVP son los siguientes:
- Integrity (Integridad). Contiene los datos criptográficos utilizados para autentificar el nodo que origina el mensaje, así como para verificar su contenido.
- Session (Sesión). Contiene la dirección IP del destinatario (DestAddress), la identificación del protocolo IP (46 para UDP) y el número de puerto del destinatario. Este objeto se utiliza para identificar la sesión a la que pertenece el mensaje y está presente en todos los mensajes RSVP.
- Rsvp_Hop (Salto RSVP). Contiene la dirección IP del nodo compatible RSVP que envió este mensaje, así como la identificación del manejador del interfaz lógico de salida por el que envió el mensaje. Este mensaje puede hacer referencia al nodo anterior de la ruta (PHop o previous hop, salto anterior), o al nodo siguiente de la ruta (NHop o next hop, salto siguiente), dependiendo de si el mensaje va del emisor al receptor o a la inversa. Se entiende que la ruta está definida desde el emisor al receptor. Esta información se guarda en cada nodo de la ruta para asegurarse de que todos los mensajes RSVP siguen la misma ruta que la que estableció el mensaje Path.
- Time_Values (valores de tiempo). Contiene el valor del tiempo de refresco R utilizado por el creador del mensaje. Indica durante cuánto tiempo se considerará válido el mensaje (tiempo de expiración o timeout, en milisegundos). Se utiliza en todos los mensajes Path y Resv.
- Policy_Data (datos de política de uso). Contiene información para que el módulo local de política de uso del nodo pueda decidir si la reserva asociada a este mensaje puede admitirse administrativamente. Este objeto puede aparecer en los mensajes Path, Resv, PathErr o ResvErr.
- Sender_Template (patrón del emisor). Se utiliza para identificar al emisor. Contiene la dirección IP del emisor y, opcionalmente, alguna información adicional de demultiplexación. Es obligatorio en los mensajes Path.
- Sender_TSpec (características del tráfico del emisor). Define las características del tráfico del flujo de datos del emisor. Es obligatorio en los mensajes Path. El tráfico se caracteriza por un algoritmo de cubo de testigos definidos por los parámetros b y r. El parámetro b es el tamaño del cubo y r la velocidad con la que se llena el cubo de testigos. Cuando se envía un paquete de m octetos se retiran m testigos del cubo. Además de los valores b y r, este objeto incluye también los valores p (velocidad máxima de los datos), m (tamaño mínimo del paquete) y M (tamaño máximo del paquete).
- AdSpec (información de la ruta). Este objeto se utiliza para dar a conocer al receptor las características de la ruta. Esto evita que el receptor solicite reservar unos recursos que la red no puede ofrecer. A este modelo se lo conoce como OPWA (One-Pass With Advertisement, una pasada con anuncio). Como este objeto pretende recoger los detalles de la red, sus valores se van actualizando conforme va pasando de nodo en nodo. Cuando llega al receptor le permite conocer las características de la ruta extremo a extremo y, por tanto, podrá determinar la calidad de servicio que puede solicitar razonablemente. Otro detalle interesante que incluye el objeto ADSpec es si algún nodo de la ruta no es compatible con RSVP.
Este objeto incluye tres fragmentos: el de los parámetros generales, el del servicio garantizado y el del servicio de carga controlada.
Los parámetros generales incluidos son: latencia mínima de la ruta (retardo), ancho de banda estimado de la ruta, número total de saltos, MTU (maximum transmission unit) de la ruta, y un bit para indicar si algún nodo de la ruta no soporta RSVP.
El fragmento del servicio garantizado contiene los parámetros que le permiten al receptor calcular el retardo extremo a extremo, un bit para indicar si algún nodo de la ruta no soporta el servicio garantizado, así como algún otro valor opcional.
El fragmento del servicio de carga controlada contiene un bit para indicar si algún nodo no es compatible con este servicio y algún valor opcional. - Scope (alcance). Contiene una lista de los emisores a los que se envía el mensaje. Este objeto aparece en los mensajes Resv, ResvErr, o ResvTear.
- Style (estilo). Si la comunicación cuenta con distintos emisores o receptores, es posible definir distintas formas de hacer la reserva, distintos estilos. Este objeto define el estilo de la reserva (WF, FF o SE), así como alguna otra información adicional que no está presente en los objetos FlowSpec ni Filter_Spec. Este objeto es obligatorio en los mensajes Resv.
- FlowSpec (detalles del flujo). Se utiliza en los mensajes Resv para definir la calidad de servicio deseada. Para ello incluye un valor que indica la clase de servicio deseada (para el servicio garantizado toma el valor 2 y para el de carga controlada el valor 5, si el dato a enviar no está asociado con ningún servicio toma el valor 1) seguido por los parámetros necesarios para dicha clase. Para el servicio de carga controlada, los parámetros incluidos son lo de TSpec (r, b, p, m y M), mientras que para el servicio garantizado se incluyen los parámetros de TSpec y RSpec (R y S).
- Filter_Spec (detalles del filtro). Este objeto contiene la identificación del emisor (IP y puerto, o etiqueta de flujo en el caso de IPv6). Se utiliza en los mensajes Resv para identificar a los paquetes que forman parte del flujo de datos para el que se hace la reserva. Como el mensaje Resv también contiene la identificación del receptor (objeto Session), al añadir la identificación del emisor (el número IP) se está permitiendo que un mismo receptor pueda establecer más de una sesión simultánea con distintos emisores (por ejemplo, en una llamada a tres). El número de puerto del emisor es útil para establecer más de una sesión con un mismo emisor (por ejemplo, en el caso de una videoconferencia la información de audio irá a un puerto y la de vídeo a otro).
- Resv_Confirm (confirmación de receptor). Contiene la dirección IP del receptor que solicitó una confirmación. Este objeto aparece en los mensajes Confirmation.
- Error_Spec (detalles del error). Los mensajes PathErr o ResrvErr lo utilizan para identificar un error (incluye la dirección IP del nodo que detectó el error y el código de error), mientras que los mensajes Confirmation lo utilizan para especificar una confirmación.
Estilo de reserva
El objeto Style (estilo de reserva) se utiliza cuando participa más de un emisor en una sesión. Este objeto se utiliza para detallar el tipo de reserva que se desea realizar desde dos puntos de vista:
- El tratamiento que le dan los emisores a la reserva. Los emisores pueden hacer una única reserva compartida por todos los emisores o pueden realizar reservas independientes
- Cómo se van a identificar estos emisores. Todos los emisores pueden compartir una única identificación (conocida como comodín o wildcard) o cada emisor puede identificarse de forma independiente (utilizando una lista explícita).
La combinación de estas opciones da lugar a tres estilos de reserva:
- Filtro con comodín (WF, Wildcard Filter). En este caso, todos los emisores se identifican de forma compartida (comodín) y utilizan una reserva compartida.
- Filtro explícito compartido (SE, Shared-Explicit Filter). En esta modalidad cada emisor se identifica de forma independiente (explícita), pero utilizando una reserva compartida.
- Filtro independiente (FF, Fixed-Filter). Se utiliza una reserva independiente para cada emisor, identificándose, igualmente, cada uno de ellos de forma independiente.
Los dos primeros estilos de reserva son apropiados para las comunicaciones de voz, mientras que el último estilo, FF, es más apropiado para las comunicaciones de vídeo.
Más información
- Protocolo RSVP de reserva de recursos
- Cómo funciona la telefonía IP o VoIP
- RTP. Protocolo de transporte en tiempo real
REF: VOIP PG204