Protocolo

de Reservación de Recursos: RSVP

Mejor transporte, por favor

El concepto de “aldea global” al que Internet iba a dar sustento, se ha

quedado como otro objetivo romántico más y ha sido rápidamente
modificado por la idea de “bazar global”. Esta transformación de La Red
en una infraestructura comercial es la que deja al descubierto que
Internet no está diseñada para ser lo que es hoy y, menos aún, para lo
que pueda llegar a ser en el mañana.

Las carencias de Internet son una realidad patente a medida que su uso se incrementa y
se trata de exprimir todas sus posibilidades. Una evidencia que sufren en mayor medida
los responsables de red y proveedores de servicio que se las ven y se las desean para
que sus sistemas puedan asumir un tráfico cada vez más intenso y complejo que generan
unos usuarios insaciables de recursos.

En los comienzos de Internet, se primó en su diseño la funcionalidad y conectividad frente

a cualquier otra consideración. Importaba y se buscaba lograr conectar. Nadie, a principio
de los años setenta, podía imaginar el escenario actual de La Red sin que le tomaran por
un visionario desquiciado. Si esta premisa de conexión a toda costa provocó que Internet
haya crecido y siga creciendo, a ritmo vertiginoso, también ha traído consigo otros
problemas y limitaciones que lastran profundamente su actual e inevitable evolución y
frente a ellos, la industria trata de dar la respuesta oportuna para poder implementar una
verdadera red global sin cortapisas en seguridad, direccionamiento, rendimiento y
capacidad.

“El tráfico de paquetes que hoy viaja por Internet se basa en ser procesado en cuanto
sea posible, según las circunstancias de la red, sin ninguna garantía sobre el propio
proceso, ni cuando tendrá lugar ese tratamiento.”

En cuanto a rendimiento y capacidad, las empresas que mantienen líneas de negocio en

Internet necesitan disponer de un soporte de red que responda con un servicio siempre
en condiciones fiables que garantice a sus clientes disponibilidad, comodidad y variedad
de servicios. Otro tanto les ocurrirá a aquellas otras organizaciones, en las que las
facilidades de conexión de Internet pueden hacer muy atractivos el teletrabajo o el trabajo
en equipo con miembros muy dispersos geográficamente, pero siempre y cuando tengan
resuelta la necesaria operatividad de los recursos necesarios.

Estos escenarios y servicios, tomados a modo de ejemplo, no resultan ya de ciencia-

ficción y la presión de su demanda choca frontalmente con la tecnología actualmente
desplegada en La Red que no es capaz de asumirla en óptimas condiciones. El tráfico de
paquetes que hoy viaja por Internet se basa en ser procesado en cuanto sea posible,
según las circunstancias de la red, sin ninguna garantía sobre el propio proceso, ni
cuando tendrá lugar ese tratamiento. La tecnología que gira en torno a Ipv4, por diseño,
no es capaz de asimilar ni responder a las expectativas que hoy por hoy se han generado
en la red de redes.

16/04/2006 | Valor añadido Danysoft | 902 123146 | www.danysoft.com | Página 1.8

La clave: Calidad de servicio

Ante la perspectiva de obligada remodelación de la infraestructura de Internet, el IETF,

Internet Engineering Task Force, como responsable de la dinámica de La Red, ha
propuesto y está definiendo el modelo de servicio que se utilizará en el futuro inmediato,
entendiendo como servicio el conjunto de características que influyen en la transmisión
de los datos, como pueden ser retardos, pérdidas, rendimiento, tasa de transferencia, y
otros. Estos aspectos de la transmisión son los que condicionan la conexión y son los que
determinan la calidad de la comunicación resultante que obtiene el usuario. De esta idea
surge el concepto de QoS, Quality of Service, base en la que se apoya la tecnología
emergente con la que se pretende responder a la evolución que se demanda de Internet.

Para que se de la calidad de servicio que exigen las aplicaciones que se ejecutan en
tiempo real dentro de Internet y otros programas sensibles a las condiciones de la
transmisión, el reto más perentorio hoy en La Red, es imprescindible que se establezcan
los mecanismos necesarios para controlar el retardo de los paquetes entre los extremos
implicados en la comunicación y, a la vez, que no obligue a la utilización de todo el ancho
de banda disponible, que sea factible su adecuado reparto para que puedan coexistir con
el resto de aplicaciones que no presentan una influencia tan crítica en las condiciones del
flujo de datos. De otro modo, los operadores de la infraestructura no podrán ofrecer todos
los servicios a precios asequibles manteniendo la rentabilidad. Es decir, se hace
ineludible poder diferenciar el tipo de tráfico para que en función de su clasificación se le
pueda asignar los recursos disponibles necesarios.

En este sentido, el IETF ha establecido dos tipos de servicios susceptibles de

implementarse en Internet. Por una parte los Servicios Integrados que define un modelo
que incluye los servicios de mejor esfuerzo, tiempo real y compartición controlada de los
enlaces. Por otra parte los Servicios Diferenciados con los que se podrá personalizar los
servicios que obtienen los usuarios basándose en la asignación de diferentes niveles de
servicio según el usuario. Este último modelo se encuentra aún en fase de discusión por
parte de la comunidad Internet, mientras que los Servicios Integrados ya están en fase de
desarrollo.

Tipos de tráfico:
Los programas al ejecutarse en cualquier red e Internet no es una excepción generan un tráfico que
puede clasificarse según las necesidades de proceso que lleva a cabo el programa en cuestión.

Tráfico de mejor esfuerzo es el flujo de datos habitual en IP, en donde los paquetes circulan por el
mejor camino posible en cada momento. El correo electrónico sería un ejemplo de aplicaciones de este
tipo de tráfico.

Tráfico sensible a la tasa es el provocado por aplicaciones que están dispuestas a sacrificar el retardo
entre los extremos a cambio de tener garantizada la tasa de transmisión. El típico ejemplo de
aplicaciones de este tipo es la videoconferencia H.323, que si bien fue diseñada para utilizar ATM o
RDSI puede introducirse en Internet. La codificación H.323 requiere de una tasa de transporte
constante para su correcto funcionamiento.

Tráfico sensible al retardo es el provocado por las aplicaciones en donde la puntualidad en la entrega
de los paquetes es fundamental para su correcto funcionamiento. El referente inmediato de programa
de esta categoría es el video MPEG-II, en donde los cambios entre las tramas utilizadas para las
imágenes varían poco en lo que se refiere a las tasas de transmisión utilizadas, pero si requieren que
lleguen en un tiempo preciso si se quiere que el Codec funcione correctamente. Para estos servicios
sensibles al retardo, hay que distinguir los que no son en tiempo real, servicios de retardo controlado y
lo que si son en tiempo real, servicios predictivos.

RSVP soporta estos tres tipos de tráfico que se pueden generar en la red informática.

Para que en el modelo de Servicios Integrados los programas puedan escoger entre
distintos niveles de entrega de sus paquetes, es necesario que existan a lo largo del
camino los mecanismos necesarios que proporcionen y gestionen QoS y un
procedimiento estándar que permita la obtención de la Calidad de Servicio a lo largo de
toda la conexión.

RSVP la implementación

Así surge RSVP (ReSerVation Protocol), protocolo de reservación de recursos, un

protocolo de control de la red que permite que los programas que van a trabajar en
Internet puedan obtener la calidad de servicio que sus flujos de datos puedan requerir. Se
trata de un protocolo totalmente emergente que se encuentra aún en fase de
normalización por parte del IETF, que está desarrollando su estandarización partiendo de
los trabajos iniciales que se realizaron en la Universidad del Sur de California con la
participación de Xerox, en donde fue concebido.

Este protocolo no es, en contra de lo que pudiera parecer, un protocolo de enrutamiento.

Es un protocolo que se inscribe dentro de la capa de Transporte del modelo de
conectividad OSI y se apoya en las tablas de rutas dinámicas que manejan los protocolos
de enrutado clásicos para establecer una conexión a modo de circuito virtual entre emisor
y receptor o receptores implicados.

Para RSVP el flujo de datos es simplemente una secuencia de paquetes que tienen un
mismo origen, uno o varios destinos, según sea la difusión, unicast o multicast, y una
calidad de servicio, todo ello caracterizado mediante sesiones. Una sesión RSVP es cada
torrente de datos que el protocolo maneja de forma independiente.

Las especificaciones de operación de este protocolo se materializan en un programa, en

un demonio, RSVP estructurado en módulos, cada uno de ellos con unas funciones
específicas. Por una parte están el módulo de Control de Admisión y el módulo de Control
de Política. El primero se encarga de determinar si el nodo tiene los recursos solicitados
disponibles para soportar la calidad de Servicio pedida. El Control de Política determina si
el solicitante tiene los permisos necesarios para poder disponer de los recursos que
solicita. En otro lado se encuentra el motor de la reserva, el módulo de Clasificación,
encargado de recepcionar los paquetes para determinar su ruta y QoS necesaria y el
módulo Esquemático, al que se le encomienda la transmisión de los paquetes.

“Este protocolo no es, en contra de lo que pudiera parecer, un protocolo de

enrutamiento. Es un protocolo que se inscribe dentro de la capa de Transporte del
modelo de conectividad OSI y se apoya en las tablas de rutas dinámicas que manejan
los protocolos de enrutado clásicos para establecer una conexión a modo de circuito
virtual entre emisor y receptor o receptores implicados”.

El host, en donde se ejecuta la aplicación que genera el tráfico en la red, inicia una sesión
con el router con capacidad RSVP, especificando la dirección de destino, el identificador
de protocolo y puerto a utilizar. Si recibe respuesta, obtiene un identificador de sesión que
marcará el camino que seguirán los paquetes que genere el programa. Cuando se activa
la sesión, cuando los paquetes son enviados, el router recibirá, junto a ellos, mensajes
RSVP en donde se especifican la reserva de recursos que ha de realizar a lo largo de
toda la trayectoria.

El demonio RSVP recepciona los paquetes y los clasifica, encolándolos según criterios
temporales. Se les asigna ruta, Calidad de Servicio y en función del temporizador se
colocan en el interface del router adecuado. Si la capa de enlace del puerto seleccionado
tiene su propia gestión de QoS, el programa del protocolo de reservación, negociará con
él la obtención de la Calidad de Servicio requerida. Si no dispone de esta capacidad, es
el propio programa quien puede encargarse de reservar la capacidad necesaria para la
transmisión, pudiéndose ocupar no sólo de los parámetros. que afecten a la línea de
comunicación, si no que puede abarcar CPU y almacenamiento.

El inicio del proceso de reservación de este protocolo comienza realmente cuando el

programa consulta a los protocolos de enrutado local las rutas que ha de utilizar. En cada
salto, en cada nodo del camino, el programa RSVP local tiene que aplicar el mismo
procedimiento, es decir, calcular si puede ofrecer la Calidad de Servicio que le han
solicitado. Si este Control de Admisión y Control de Política es satisfactorio, el nodo local
clasifica y encola los paquetes para darles la QoS que requieren. Si no le es posible
proporcionar los recursos que le han sido pedidos, la aplicación que originó el flujo de
datos recibirá una indicación de error.

En el contexto de operación de RSVP, la distribución de datos puede hacerse por difusión

en unicast en donde sólo hay un emisor y un receptor o por multicast, en cuyo caso hay
un emisor y varios receptores. El flujo de datos que se maneja en una sesión de este
protocolo siempre tiene un solo emisor y los paquetes de cada sesión en particular irán
dirigidos a la misma dirección IP y a un puerto. Si hay difusión multicast, la dirección IP
será la dirección del grupo. Si para este protocolo cada emisor y receptor debe
corresponderse con un host único, no hay inconveniente para que un mismo host pueda
contener varios emisores o receptores lógicos que se identifiquen por los puertos.

En lo que respecta a QoS , los requerimientos que pueda necesitar la aplicación se

definen mediante la especificación del flujo de datos, que es la estructura de datos
utilizada por los hosts para solicitar servicios especiales a la red. Mediante un atributo
que va incorporado en los mensajes con los que se relacionan RSVP y los programas, se
determina de que forma han de intercambiar datos los actores de la transmisión. Así, el
host utiliza su parte RSVP para solicitar el nivel de Calidad de Servicio que necesita para
cada ráfaga de datos. El router utiliza su parte de protocolo para propagar esas
necesidades a los otros encaminadores de la ruta a seguir.

Para que los programas puedan interactuar con este protocolo están definidas las RAPI,
RSVP Aplication Programming Interface, que proporciona a las aplicaciones los
mecanismos que pueden necesitar para comunicar con el demonio RSVP y obtener la
reserva de recursos que vayan a necesitar a lo largo de toda la trayectoria de la conexión.
Esta herramienta permite que las aplicaciones no tengan que ser nuevamente diseñadas
ni reescritas para integrarse en este modo de trabajo.

Aunque el diseño del protocolo está orientado a la multidifusión, no desmerece las

reservas que puede realizar para aplicaciones de unidifusión, pero es en el primer tipo de
transmisión en donde se saca mejor partido al protocolo. El mayor potencial que ofrece
es la forma con la puede asumir los grupos de difusión ya que al estar determinada la
reserva de los recursos por el receptor, no es necesario que éste tenga que acudir al
origen para obtenerla, basta con que acuda a la rama que le corresponda. Esto se debe a
que el flujo del tráfico de red depende inicialmente de que el emisor pueda conectar con
el receptor para que pueda establecerse el circuito virtual y a partir de ahí, el tráfico se va
ramificando en cada nodo para que los paquetes puedan llegar a sus destinatarios. A
modo de árbol invertido, el emisor se corresponde con la raíz, los nodos en las ramas y
los host destinatarios en las hojas. El tráfico fluye de arriba hacia abajo.
Control de la reserva

La labor de gestión de recursos la realiza este protocolo mediante el intercambio de

mensajes que se incorporan en los paquetes RSVP, que le permiten gestionar ese
circuito virtual que se llega a establecer entre emisor y receptores. Y hay cuatro tipos de
mensajes.

El primer tipo de mensajes que ha de manejarse es el de solicitud de reservación,

mensaje que tiene que generar el receptor. Es decir, el host de destino ha de enviar un
mensaje que recorra la ruta de llegada a la inversa para que el host emisor pueda
determinar qué control de flujo es necesario para que pueda iniciarse el tráfico desde el
primer salto. El protocolo no mantiene informado al emisor sobre el éxito del
establecimiento de la conexión con el receptor.

Para que esos mensajes de solicitud de reservación se produzcan, el emisor tiene que
lanzar un mensaje de trayectoria que trace la ruta según la información que le
proporcionan los protocolos de enrutamiento y que cada nodo del camino ha de conocer
para mantenerla. Sobre la viabilidad de la ruta, sobre la reservación de recursos y su
estado, el protocolo maneja mensajes de error y confirmación. Se producirán mensajes
de error en la reservación si la solicitud de reserva no se puede realizar por alguna
circunstancia de la red, como puede ser la no disponibilidad del ancho de banda
necesario, que el servicio solicitado no esté disponible o algún nodo no sea capaz de
admitirlo en las condiciones requeridas. Asimismo, si el trazado de la ruta no tiene éxito,
el emisor recibirá un mensaje de error en la trayectoria. Los mensajes de confirmación se
dan cuando se exige en el mensaje de solicitud de reservación que ésta sea confirmada y
viaja hacia el receptor de la comunicación.

La validez de las reservas realizadas y sus trayectorias se administran mediante

mensajes de “limpieza”, de revocación, que se encargan de eliminar los estados de estos
dos aspectos de la transmisión, trayectoria y reserva, sin tener que esperar a que expire
su tiempo de vida. Pueden ser generados por cualquiera de los elementos implicados, el
emisor, el receptor o el router como resultado de alguna variación de las condiciones del
estado de cualquiera de ellos. Un mensaje de eliminación de trayectoria, implica,
lógicamente, la eliminación del estado de reservación.

Así, el formato de los paquetes de este protocolo consta de dos partes, un encabezado
de mensajes y objeto RSVP. La primera parte lleva la información de control que el
protocolo requiere para manipular correctamente el paquete, como puede ser versión de
protocolo, tiempo de vida del IP con el que se envió el mensaje, tamaño del paquete
completo, identificador del mensaje y otros. La parte de objeto lleva información
especifica de la función de reservación de recursos, como puede ser la dirección IP y
puerto de destino, la dirección IP del nodo RSVP que envía el mensaje, el estilo de la
reservación, la especificación de QoS, y otros más.

“Aunque el diseño del protocolo está orientado a la

multidifusión, no desmerece las reservas que puede realizar
para aplicaciones de unidifusión, pero es en el primer tipo de
transmisión en donde se saca mejor partido al protocolo.”
Por otro lado, estos mensajes también sirven para que RSVP pueda mantener la reserva
de recursos sobre las circunstancias cambiantes de la red, que irremediablemente se han
de producir. En el ámbito de este protocolo, se habla de estado suave o soft, cuando se
refiere el estado de los routers y nodos terminales implicados en la transmisión. Mediante
el intercambio frecuente de mensajes, los encaminadores que tienen que mantener los
recursos pueden adaptarse a cambios de ruta sin necesidad de tener que contar con los
extremos terminales. Los mecanismos de RSVP proporcionan un escenario en el que se
puede construir y conservar una reserva de recursos distribuida en una malla de rutas,
tanto para la multidifusión como para la unidifusión. Esta característica mejora
ostensiblemente los resultados que se obtienen en la conmutación de circuitos, en donde
si la conexión entre los terminales falla en algún punto, hay que generar una nueva
llamada.

El protocolo de reservación de recursos almacena el estado de los nodos enrutadores y

de los equipos terminales regenerando periódicamente la información mediante los
mensajes de trayectoria y solicitud de reservación. El estado se elimina cuando no llegan
los mensajes oportunos de regeneración dentro del tiempo de validez que se marca, o
cuando llegan mensajes explícitos de revocación. Cuando hay modificaciones respecto a
una ruta, el mensaje de trayectoria que se produce a continuación inicializa un nuevo
camino y los mensajes de solicitud de reservación establecen la reserva, expirando la
senda que no se utiliza. Con RSVP, los cambios de las rutas tienen un mínimo retardo,
porque si los mensajes que informan sobre el estado difieren sobre el almacenado, se
actualizan inmediatamente y se propagan las actualizaciones al resto de las etapas.

Estilo de reserva

Para llevar a cabo su función RSVP, utiliza una serie de controles determinados por los
parámetros que soporta para especificar como se van a reservar los recursos para los
elementos que los solicitan. La reserva de recursos que este protocolo maneja puede ser
compartida cuando se da el caso que la sesión es compartida por varios emisores
simultáneamente sin que interfieran entre ellos, o bien será una reservación de recursos
en exclusiva cuando se establece una sesión independiente para cada uno de los
emisores. Esta característica define el estilo de la reserva de recursos que hace el
protocolo.

Se puede plantear el flujo de datos que maneja este protocolo, la sesión, como una
tubería por la que fluye la información y que su torrente puede llegar a uno o varios
recipientes. La cañería que se tiende desde la fuente a los recipientes, puede
contemplarse, siguiendo con la analogía, en función del material con el que está echa,
flexible o rígido, que permitiría acomodar sobre la marcha más caudal o no. Así, en el
estilo de reservación RSVP se contempla que en el estilo, exclusivo o compartido, de la
reservación se puede utilizar como una tubería rígida, filtro fijo, en donde se define un
determinado canal, una determinada reservación que será utilizada por una sola fuente
emisora o una lista de ellas, pero sin oportunidad de variar. La tubería flexible, el filtro
comodín, se entiende cuando los recursos reservados son comunes a todos los emisores
y el canal tiene una “anchura” que será la del que mayor requerimientos tenga, la
necesiten o no. La reservación de filtro fijo es como un canal de televisión, todos los
televidentes verán lo que esa cadena emita según lo emita. La reservación de filtro
comodín es como la videoconferencia, los recursos se reservan para todos los que
asisten, participen o no en ella, los recursos son para el grupo con independencia de cual
sea el emisor.

El estilo de reserva no permite mezclar aquellas que son compartidas con las exclusivas
y cada una de ellas será apropiada para las aplicaciones en función de las características
que requiera el flujo de datos que vayan a utilizar. El estilo de reserva de filtro fijo,
reservación en exclusiva y con una “anchura” determinada, es muy adecuado para video,
en donde es más que probable que sólo haya un emisor, mientras que las reservas
compartidas ya sean de filtro variable o determinado se adaptan mejor a las
características de la videoconferencia, en donde puede haber más de un emisor.

Si, pero…

RSVP no es una tecnología definitivamente estandarizada y mucho menos aún

totalmente desplegada en el universo Internet. El protocolo puede trabajar con IP tanto en
la versión 4 como en la versión 6, esta última mejor dotada para la reserva de recursos.
Por las características de operación de este protocolo, no se puede realizar una
reservación de recursos de extremo a extremo de la comunicación si existen dispositivos
intermedios que no soportan este modo de trabajo. Para soslayar este inconveniente que
pone en peligro su despliegue, RSVP está preparado para hacer túneles que atraviesen
las redes intermedias que no soporten este protocolo y lo hace de forma automática. Para
que la tunelación sea posible es necesario que los enrutadores, tanto RSVP como los
que no lo son, envíen mensajes de trayectoria hacia la dirección de destino usando las
tablas de ruta locales y cuando los mensajes de trayectoria atraviesan una red que no
soporta RSVP, haya copias de los mensajes que transporten la dirección del último router
con capacidad para la reservación de recursos.

Esta facultad de volverse transparente para las zonas que no sean RSVP hacen que el
protocolo pueda ir introduciéndose gradualmente en Internet con lo que su implantación
no requiere una revolución radical de las infraestructuras. Además, esta característica
puede hacer que el protocolo sea más eficiente para sortear tramos RSVP altamente
saturados.

A las ventajas innegables que representa en su planteamiento la reservación de recursos,

se oponen otros inconvenientes que en unos casos ya han sido en parte resueltos, como
la integración de mundos RSVP con aquellos que no lo son. En otros tendrán que
ofrecerse soluciones para que este protocolo pueda desplegar toda su potencialidad. Uno
de estos inconvenientes más inmediatos que puede presentarse en el futuro de este
protocolo es el incremento desmesurado de la señalización que utiliza para su
funcionamiento, que previsiblemente traerá consigo su paulatina implantación, el
aumento de rutas disponibles y el imparable incremento de usuarios que acceden a La
Red más veces y por más tiempo. Otra circunstancia adversa que tendrá que sortear es
su convivencia con los algoritmos de enrutado, que puede provocar que la selección de
una determinada ruta no sea la más adecuada, porque los protocolos de encaminamiento
no tienen en cuenta, por desconocimiento, cuales serán las condiciones de reserva de
recurso que el receptor necesitará. Esto puede restarle eficacia y probablemente le
obligará a trabajar más estrechamente con los protocolos de conmutación de etiquetas.

Hay opiniones que plantean que la evolución lógica de las redes traerá, por si misma, una
oferta abundante de ancho de banda que haga innecesario recurrir a estas tecnología
que ahora se están desarrollando. Sin embargo mientras esas tecnologías de futuro
llegan y tardarán en llegar, el modelo de Servicios Integrados que ha definido el IETF se
plantea como la única alternativa que a medio y largo plazo será capaz de soportar la
calidad de servicio que Internet reclama. Los desarrollos de los fabricantes, el diseño de
redes y la utilización de las aplicaciones futuras pasan forzosamente por estos nuevos
protocolos, lo que obligará al distribuidor a seguir de cerca su evolución para adaptarse a
los cambios que el mercado va a sufrir.

A la hora de plantear está tecnología, hoy por hoy, los fabricantes pueden tenerla
disponible en sus catálogos tanto de forma gratuita, incluida junto con los productos que
la utilizan, como en venta. Lo que realmente interesa conocer al evaluar productos para
esta tecnología, no son las capacidades del protocolo que cada fabricante implementa, si
no, precisamente, aquellas otras que no lo están, porque esas carencias son las que van
a marcar realmente la continuidad del producto que se considere. La falta de una
determinada capacidad RSVP hoy puede no ser importante habida cuenta del grado de
desarrollo e implantación de esta tecnología en la actualidad, pero no pasado mucho
tiempo puede provocar que, incluso, el producto no sea operativo.

Publicaciones sobre QoS del IETF

El Internet Engineering Task Force como brazo armado del IAB, Consejo de Actividades sobre Internet,
máximo organismo rector de La Red, se encarga de identificar la problemática que se pueda plantear y
definir las soluciones que se han de aplicar, que se hacen públicas mediante la correspondiente RFC,
Resquest For Comments. Sobre la calidad de servicio y protocolos relacionados existen actualmente
varias normas publicadas:

- RFC 1633 “Integrated Services in the Internet architecture: An overview”

- RFC 2205 “Resource Reservation Protocol (RSVP). V.1, Functional Specification”
- RFC 2206 “RSVP Management Information Base using SMI v2”
- RFC 2207 “RSVP Extension for IPSEC Data Flow”
- RFC 2208 “RSVP v 1. Applicability Statement Some Guidelines on Deployment”
- RFC 2209 “ Resource Reservation Protocol (RSVP). V.1, Message Processing Rules”
- RFC 2210 “General characterization parameters for integrated service network elements”
- RFC 2211 “Specification of controlled-load network element service”
- RFC 2212 “Specification of guaranteed quality of service”
- RFC 2745 “RSVP Diagnostic Messages”
- RFC 2746 “RSVP Operation Over IP Tunnels”
- RFC 2747 “RSVP Cryptographic Authentication”

Para más información.

Contacte con los servicios profesionales Danysoft en el 902 123146, o en

info@danysoft.com