Una encuesta sobre la evolución de RSVP

Una encuesta sobre la evolución de RSVP
Resumen: el Protocolo de reserva de recursos (RSVP) representa uno de los protocolos más importantes
utilizados para la reserva de recursos en Internet. Desarrollado inicialmente por el Grupo de Trabajo de
Ingeniería de Internet (IETF) para ser utilizado dentro del mecanismo de Servicios Integrados (IntServ), este
protocolo experimenta con el tiempo varias alteraciones. Estas alteraciones vienen ya sea para responder a
algunos problemas de aplicabilidad y funcionalidad, o para extender el uso de RSVP y para que sea
compatible con otros mecanismos como los Servicios Diferenciados (DiffServ) o el Cambio de Etiquetas
Multiprotocolo (MPLS). Este trabajo presenta una encuesta sobre la evolución de RSVP que ilustra las
diferentes alteraciones introducidas a lo largo del tiempo para este protocolo y explica cómo cada
adaptación afecta a RSVP en términos funcionales.
I. INTRODUCCIÓN
A lo largo de los años, se han realizado varios intentos para definir un protocolo de reserva eficiente o un
método de señalización genérico para Internet. Algunos ejemplos de estos enfoques son el Protocolo de flujo
de Internet 2 (ST2) [1], el Protocolo de reserva de recursos (RSVP) [2], el Protocolo de Internet de sesión de
remitente (YESSIR) [3] o Boomerang [4]. En [5] se puede encontrar una encuesta sobre los mecanismos de
señalización de Internet. Entre todas estas propuestas, RSVP captó la mayor atención de la comunidad de
investigación, lo que lo convirtió en uno de los protocolos más persistentes y alterados.
Históricamente, RSVP fue el sucesor de ST2. Ambos protocolos estaban destinados a soportar
comunicaciones de multidifusión. Este es uno de los requisitos clave para un protocolo de reserva de
recursos, ya que se consideró que la demanda de teleconferencias en tiempo real con capacidad de
multidifusión iba a crecer dramáticamente en Internet [6]. ST2 fue desarrollado para una comunicación de
punto a multipunto iniciada por el remitente. El problema con el protocolo ST2 fue que, dado que se inició
con el remitente, no se escala con el número de receptores en un grupo de multidifusión [6]. Esto, a su vez,
desencadenó el desarrollo de RSVP, que se desarrolló desde el principio como un protocolo de reserva de
recursos basado en el receptor que puede admitir la configuración de reserva multipunto a multipunto. Una
comparación arquitectónica de ST2 y RSVP se puede encontrar en [7].
RSVP está estandarizado por el IETF en [2] y fue diseñado para funcionar bajo el mecanismo IntServ.
Presentado para garantizar un retraso limitado a las aplicaciones intolerantes, RSVP representa un medio a
través del cual los recursos se pueden reservar para un flujo de tráfico en todos los nodos desde el host del
remitente al host del receptor. Entre algunas de las características más importantes de RSVP podemos
enumerar: la reserva de recursos basada en el receptor, el enfoque de estado suave para mantener las
reservas y el uso de una mejora de un modelo de reserva de un solo paso denominado One Pass with
Advertising (OPWA). A su vez, RSVP no escapó a las críticas y fue acusado de ser demasiado complejo al
mismo tiempo que sufría un grave problema de escalabilidad. Sin embargo, el diseño de RSVP no se
abandona y, a lo largo de los años, se han propuesto diferentes extensiones que se basan en la solución RSVP
original. Algunas de estas extensiones proporcionan características que no estaban disponibles en el diseño
original, mientras que otras se concentran en alienar el problema de escalabilidad.
Una de las implementaciones más adoptadas que se basa en el diseño original de RSVP es la extensión RSVP
para ingeniería de tráfico (RSVP-TE). Esta extensión fue ampliamente aceptada para las redes compatibles
con Multiprotocol Label Switching (MPLS). RSVP ha demostrado ser extremadamente importante en el
campo de la Calidad de servicio (QoS). Se han creado extensiones que permiten el acoplamiento de RSVP con
cada uno de los tres mecanismos de QoS desarrollados por IETF (IntServ, DiffServ y MPLS). En [8] - [11] se
presenta una descripción general de la QoS de Internet y el rol de RSVP en este campo.
En este documento, trataremos de inventariar las extensiones de RSVP introducidas por IETF. El objetivo
principal de este documento es presentar de manera sistemática la funcionalidad introducida por los
estándares más importantes que definieron o modificaron el RSVP a través del tiempo. El documento es de
tipo tutorial y presenta un estudio exhaustivo sobre la evolución de RSVP. El resto del artículo está
organizado de la siguiente manera. En la Sección II presentamos el diseño básico de RSVP y el diseño de los
componentes subyacentes. En la Sección III ilustramos el uso de RSVP bajo IntServ. En la Sección IV se
presentan diferentes extensiones del diseño de RSVP, como la autenticación criptográfica o la extensión para
el control de políticas. En la Sección V presentamos diferentes propuestas introducidas para reducir la
sobrecarga de procesamiento: la reducción de actualización, la agregación de reservas RSVP y la agregación
genérica de RSVP. La Sección VI describe las extensiones principales de RSVP para MPLS y MPLS generalizado
(GMPLS). En la Sección VII presentamos las extensiones propuestas de RSVP-TE. En la Sección VIII se presenta
una discusión de otros problemas de investigación relacionados con RSVP que no son abordados
directamente por el IETF. Y finalmente en la Sección IX concluimos nuestro trabajo.
II. DISEÑO ORIGINAL DE RSVP
A. Descripción general de RSVP
Definido en RFC 2205, el Protocolo de reserva de recursos fue diseñado para una Internet IntServ [2]. RSVP
se coloca en la capa de transporte en la pila de protocolos OSI, pudiendo operar sobre IPv4 o IPv6. RSVP no
transporta ningún dato en sí mismo, operando en este sentido como un protocolo de control de Internet
(ICMP o IGMP) o como un protocolo de enrutamiento. Sin embargo, RSVP en sí no es un protocolo de
enrutamiento, pero está diseñado para funcionar con todos los tipos de protocolos de enrutamiento.
El modelo de reserva RSVP es una mejora de un modelo de reserva de One Pass llamado One Pass with
Advertising (OPWA) [12]. En un modelo de reserva de un paso, un receptor envía una solicitud de reserva en
sentido ascendente y cada nodo en la ruta acepta o rechaza la solicitud [2]. En [13] se puede encontrar una
descripción detallada del enfoque OPWA y una discusión de las características de los mecanismos de One
Pass y Two Pass. En el caso de RSVP, los paquetes de control se envían desde el remitente a los hosts del
receptor en la ruta exacta utilizada por el flujo de datos. Los paquetes recopilan información sobre la red,
que luego se utiliza para predecir la calidad de servicio de extremo a extremo. Estos anuncios pueden ser
utilizados por el receptor para construir o ajustar las solicitudes de reserva apropiadas.
RSVP es un protocolo de reserva orientado al receptor, lo que significa que los receptores son los que
originan una solicitud de reserva. Una vez que se genera la solicitud, se reenvía en sentido ascendente hacia
el remitente. El proceso a cargo de la reserva pasa la solicitud a los módulos de control de admisión y control
de políticas. Aquí, la decisión se basa en la disponibilidad de los recursos, en el caso del control de admisión y
en las credenciales y los derechos del usuario en el caso del control de políticas. Si se rechaza la reserva, se
envía un mensaje de error al receptor. Sin embargo, si se concede la reserva, la reserva se propaga en
sentido ascendente a los remitentes correspondientes. Una nota importante aquí es que la reserva
propagada en sentido ascendente puede diferir de la recibida, en el sentido de que las ramas en sentido
descendente de un árbol de multidifusión que se originan en el mismo remitente deben fusionarse a medida
que la reserva se propaga hacia el remitente.
RSVP opera en un nivel por sesión, proporcionando reservas unidireccionales y tratando cada sesión por
separado. Una sesión representa un flujo de datos con un destino particular y un protocolo de capa de
transporte. Las sesiones se identifican por la dirección de destino de IP, el ID de protocolo de IP y un
parámetro opcional que representa el puerto de destino TCP / UDP.
Una reserva de RSVP básica, como se define en RFC 2205, consiste en un descriptor de flujo que se compone
de un FLOWSPEC y un SPEC de FILTRO. FLOWSPEC especifica la QoS deseada que utilizan los nodos para
configurar los parámetros del programador de paquetes. FILEC SPEC se usa junto con la especificación de la
sesión para definir el conjunto de paquetes de datos (o el flujo) que recibirá la QoS definida por el
FLOWSPEC, especificando los parámetros necesarios para el clasificador de paquetes del nodo.
FLOWSPEC incluye dos conjuntos de parámetros: una RSpec que se usa para definir la QoS deseada y una
TSpec que se usa para describir el flujo de datos. El contenido y el formato de estos parámetros se detallarán
en la próxima sección cuando presentaremos el uso de RSVP con los Servicios integrados. Los parámetros
mencionados no son una preocupación directa para RSVP, ya que el protocolo funciona de una manera que
es opaca a estos parámetros.
Hay tres tipos de estilos de reserva disponibles para ser usados con RSVP. El primer tipo llamado Filtro fijo
(FF) se usa cuando la reserva es distinta y la selección del remitente es explícita. Esto significa que se crea
una reserva distinta para los paquetes de datos de un remitente en particular. La reserva, en este caso, no se
comparte con otros remitentes. En contraste, el segundo y tercer tipo, a saber, Shared Explicit (SE) y
respectivamente Wildcard Filter (WF), crean reservas compartidas. La diferencia entre los dos modelos de
reserva compartida es que, en el caso de la SE, el receptor puede especificar explícitamente el conjunto de
remitentes que se incluirán. Por otro lado, cuando se utiliza el estilo WF, la reserva se extiende
automáticamente a los nuevos remitentes a medida que aparecen. Las reservas compartidas WF y SE son
apropiadas para aplicaciones de multidifusión donde es improbable que múltiples fuentes transmitan
simultáneamente.
Con el fin de entregar información de un nodo a otro, RSVP utiliza diferentes tipos de mensajes,
dependiendo de la información que se debe entregar y de las acciones que desencadena cada mensaje. Estos
mensajes están compuestos de diferentes entidades estandarizadas llamadas objetos. En general, cada
objeto lleva información estandarizada específica, como la dirección IP del nodo de destino transportado en
el objeto SESSION.
Se definen dos mensajes RSVP fundamentales, el mensaje Resv, una solicitud de reserva que viaja desde el
receptor al remitente (s), y un mensaje de ruta que viaja en sentido descendente desde el host del remitente
a lo largo de las rutas uni / multi-cast hacia el receptor.
El mensaje de Ruta sigue la ruta provista por el protocolo de enrutamiento, utilizando la misma ruta que el
flujo de datos. Cada mensaje de ruta almacena un estado de ruta en todos los nodos intermedios en el
camino. El estado de la ruta incluye información recuperada del propio mensaje de ruta o de otros procesos
específicos de ese nodo, como veremos más adelante.
El mensaje Resv se envía exactamente en la ruta inversa utilizada por el mensaje Path. Si el mensaje de Ruta
se envía utilizando la misma dirección de origen y destino que los datos, el mensaje de Resv se envía salto
por salto usando la información de estado de ruta almacenada en los nodos intermedios.
RSVP utiliza un enfoque de estado suave para administrar el estado de reserva en los hosts y los nodos
intermedios. Mientras que el estado de ruta representa el estado que se crea cuando se recibe un mensaje
de ruta, en consecuencia, el estado de reserva es el estado creado cuando se recibe un mensaje Resv. Los
mensajes de Ruta y Resv. Se utilizan para crear, pero también para actualizar la reserva y el estado de la ruta
en los nodos. De esta manera, si una ruta cambia, debido a actualizaciones de enrutamiento o falla del nodo,
el nuevo mensaje de Ruta creará un nuevo estado de Ruta en los nodos de la nueva ruta y el mensaje Resv
establecerá el estado de reserva en estos nodos para la nueva ruta. El estado de reserva anterior se eliminará
automáticamente si no llega ningún mensaje de actualización correspondiente antes de que caduque el
intervalo de tiempo de espera de limpieza.
Este tipo de enfoque de estado suave hace que las reservas de RSVP sean dinámicas, donde para cambiar los
parámetros de QoS o para modificar el conjunto de remitentes, es suficiente transmitir los mensajes Resv /
Path actualizados. Las reservas pueden ser eliminadas explícitamente por los hosts finales utilizando
mensajes de desmontaje. Se definen dos tipos de mensajes de desmontaje: PathTear y ResvTear. El mensaje
PathTear viaja en sentido descendente hacia el (los) receptor (es) y elimina los estados de ruta y los estados
de reserva dependientes en todos los nodos intermedios para esa reserva. ResvTear se puede ver como un
mensaje de ruta de sentido inverso y se encarga de eliminar los estados de reserva a medida que viaja hacia
el remitente (s).
De acuerdo con la forma en que los mensajes principales de Resv y Path viajan en el proceso de reserva
RSVP, se definen dos mensajes de error: ResvErr y PathErr. El PathErr simplemente viaja en sentido
ascendente hacia el remitente que creó el error y no cambia ningún estado del Camino en el camino. Solo se
definen algunas causas posibles que pueden desencadenar el envío de un mensaje PathErr, como veremos
más adelante. El mensaje ResvErr por otro lado tiene un comportamiento mucho más complejo. Debido a las
capacidades de fusión del modelo de reserva RSVP, una solicitud fallida puede ser causada por la fusión de
varias solicitudes diferentes, lo que a su vez significa que el error de reserva debe informarse a todos los
receptores involucrados.
La fusión de reservas en RSVP puede crear problemas aún más complicados. Estos problemas se denominan
reservas asesinas, en las que una solicitud puede provocar una denegación de servicio a otra solicitud.
Dos problemas de reserva de asesinos fueron identificados y presentados en [2]. El primero puede suceder
cuando ya existe una reserva (Q0) y un nuevo receptor desea hacer una reserva adicional (Q1). La fusión de
estas reservas podría ser rechazada por los procedimientos de control de admisión en algunos nodos, debido
a la falta de recursos. Este rechazo no debería afectar la reserva ya existente Q0. La solución es que siempre
que una solicitud de reserva sea rechazada por el control de admisión, cualquier reserva existente debe
dejarse en su lugar.
El segundo problema de la reserva de asesinos aparece cuando un receptor que desea hacer una reserva
(Q1) es persistente incluso si el control de admisión rechaza Q1 en algunos nodos. Este tipo de
comportamiento no debe impedir que otro receptor que quiera hacer una reserva (Q2) pueda tener éxito si
no se fusiona con Q1. Con el objetivo de resolver este problema, el mensaje ResvErr crea un estado adicional
denominado estado de bloqueo. Este estado modifica los procedimientos de fusión para omitir el FLOWSPEC
de reserva Q1 ofensivo de la fusión, al tiempo que permite crear reservas más pequeñas.
B. Mensajes y objetos de RSVP
En términos de especificaciones funcionales de RSVP, RSVP está construido de una manera muy flexible.
Como ya hemos visto, RSVP consta de diferentes tipos de mensajes que se encargan de proporcionar
información a los nodos finales y los nodos intermedios.
Un mensaje RSVP consta de un encabezado común, donde se especifican la versión del protocolo y el tipo de
mensaje. El cuerpo del mensaje se compone de un número variable de elementos de longitud variable,
llamados objetos. Cada uno de los tipos de mensajes definidos tiene especificaciones sobre qué tipo de
objetos deben incluirse en el cuerpo del mensaje y en qué orden. Sin embargo, como veremos, otros objetos
e incluso tipos de mensajes se han desarrollado a lo largo de los años para RSVP. Cada extensión de un
objeto o mensaje pretendía mejorar la funcionalidad del protocolo RSVP o ampliar la capacidad de RSVP. El
encabezado común y el formato de objeto general se pueden ver en la Fig. 1.
En total se definieron siete tipos de mensajes en [2]. Estos son Path, Resv, PathErr, ResvErr, PathTear,
ResvTear y ResvConf. Además, se introdujeron 15 clases diferentes de objetos en el mismo RFC. Cada objeto
consiste en un múltiplo de palabras de 32 bits, comenzando de nuevo con un encabezado común que
especifica la longitud en bytes del objeto, un campo Class-Num y un campo C-Type como se muestra en la
Fig.1.
El valor de Class-Num se utiliza para identificar de forma única una clase de objetos. En total, se especificaron
15 valores Class-Num en RFC 2205. Dentro de una clase, el campo Tipo C identifica un tipo de objeto preciso.
Estos tipos y sus valores son únicos dentro de un Class-Num. Las 15 clases de objetos definidas en RFC 2205
se presentan en la Tabla I, que ilustra también la información que se incluye en cada objeto. De estos 15,
cinco clases de objetos no se describieron en esta RFC, pero se definieron más adelante en otras RFC.
Para garantizar la compatibilidad con las futuras clases de objetos definidos para RSVP, los valores de ClassNum se dividen en tres grupos, según lo que se desee de la implementación de RSVP con respecto a un
objeto que pertenece a una clase desconocida. Un número de clase del formulario [0bbb bbbb] hará que el
nodo rechace todo el mensaje y devuelva un error de clase de objeto desconocido. Un Class-Num del
formulario [10bb bbbb] hará que el nodo ignore el objeto sin reenviarlo ni enviar un mensaje de error. Y un
Class-Num que tiene la forma [11bb bbbb] hará que el nodo ignore el objeto, pero lo reenvíe sin ser
examinado y sin modificar.
En la Fig. 2, ilustramos los componentes de los mensajes de Ruta y Resvación usando la Forma Bachus-Naur
(BNF).
El mensaje de Ruta se origina en cada remitente de un flujo de datos y viaja hacia el receptor utilizando la
misma ruta que los paquetes de datos. El mensaje de ruta utiliza la dirección de origen IP del remitente y la
dirección de destino IP de la sesión. Esto garantiza que los mensajes serán enrutados correctamente por
nodos o dominios que no son RSVP. Un nodo que no es RSVP es un nodo que no entiende los mensajes de
RSVP y no puede seguir los procedimientos definidos en RFC [2]. El mensaje incluye el objeto SENDER
TEMPLATE para identificar la dirección IP y el puerto de origen del remitente, y el objeto SENDER TSPEC para
definir las características de tráfico del flujo de datos del remitente. Opcionalmente, se puede incluir un
objeto ADSPEC, que se utiliza para la información publicitaria (OPWA) del flujo de datos, como veremos más
adelante.
Todos los nodos compatibles con RSVP capturan los mensajes de ruta y crean un estado de ruta para el
remitente. El estado de la ruta se identifica por la tupla compuesta de objetos SESSION y SENDER TEMPLATE.
Si un objeto SENDER TEMPLATE se utiliza para identificar al remitente con una dirección IP y un puerto de
origen, el objeto SESSION indica la dirección de destino de IP, el número de protocolo de IP y el puerto de
destino. Además, los DATOS DE POLÍTICA, SENDER TSPEC, ADSPEC y RSVP HOP se guardan en el estado de la
ruta.
El RSVP HOP se utiliza para transmitir la dirección IP del nodo con capacidad de IP anterior junto con el
identificador de la interfaz de salida lógica (LIH). Como veremos más adelante, esta dirección será utilizada
por el mensaje Resv para viajar paso a paso en el camino inverso.
El objeto INTEGRIDAD se utiliza para transportar datos criptográficos con el fin de autenticar el nodo de
origen y proporcionar integridad de extremo a extremo. Sin embargo, este objeto y los procedimientos
asociados se estandarizaron más adelante en [14]. Además, el objeto POLICY DATA se estandarizó
posteriormente mediante RFC 2750 [15]. Este objeto se utiliza para el control de admisión genérico basado
en políticas.
Los mensajes de ruta se envían (y se replican en caso de multidifusión) por cada nodo intermedio utilizando
la información de enrutamiento recibida del proceso de enrutamiento apropiado. Una vez que el mensaje de
ruta llega al nodo receptor, este envía de vuelta un mensaje Resv que usa la misma ruta que el mensaje de
ruta en la dirección inversa, hacia el remitente del mensaje. Los componentes del mensaje Resv se ilustran
en la Fig. 2.
El objeto RSVP HOP contiene en este caso la dirección IP del nodo que envió el mensaje Resv. El mensaje
Resv viaja salto a salto de un nodo con capacidad RSVP a otro, utilizando la información que se almacena en
el estado de la ruta en cada enrutador intermedio para determinar el siguiente salto.
La lista de descriptores de flujo presente en el mensaje Resv depende del estilo, lo que significa que para
cada uno de los tres estilos se espera un formato diferente de la lista de descriptores de flujo. La indicación
de qué estilo está en uso está contenida en el objeto STYLE. En la Fig. 3 presentamos el formato de la lista de
descriptores de flujo para cada uno de los tres estilos.
Cada reserva que utiliza el estilo FF está definida por los pares de objetos FLOWSPEC y FILTER SPEC. Se
pueden empaquetar múltiples solicitudes en una sola lista de descriptores de flujo, donde el objeto
FLOWSPEC que aparece en el descriptor de flujo FF se puede omitir si es idéntico al primer objeto FLOWSPEC
utilizado.
En el estilo SE, la selección del remitente se basa en hacer coincidir el objeto FILTER SPEC con el objeto
SENDER TEMPLATE del estado de ruta existente almacenado en los nodos intermedios. Los mensajes
PathTear son activados explícitamente por los remitentes o son iniciados por nodos cuyo estado de ruta se
agota. El mensaje se enruta como un mensaje de ruta que tiene la dirección de destino IP del objeto SESSION
y como dirección de origen, la dirección de origen IP del remitente del estado de la ruta que se está
arrancando. El estado de la ruta se elimina al hacer coincidir los objetos SESSION, SENDER TEMPLATE y RSVP
HOP del mensaje PathTear con los valores almacenados en el estado de la ruta del nodo. Si no se encuentra
una coincidencia correspondiente, el mensaje se descarta.
La eliminación de un estado de ruta debe mantener la coherencia en el nodo en lo que concierne al estilo del
estado de reserva relacionado. Si, por ejemplo, el estilo es WF, la reserva general debe eliminarse solo si el
remitente que inició el mensaje es el último remitente de esa sesión. El mensaje PathTear utiliza un
componente de descripción del remitente que tiene el mismo significado que el definido en el formato del
mensaje Path.
Usando la misma lógica que para los mensajes de PathTear, los mensajes de ResvTear son iniciados
explícitamente por los receptores o por los nodos intermedios donde el estado de reserva ha expirado. Estos
mensajes se envían de la misma manera que los mensajes de Resv que viajan de un salto a otro hacia los
remitentes y eliminan los estados de reserva correspondientes en cada nodo. La coincidencia en este caso se
basa en los objetos SESSION, STYLE, FILTER SPEC y RSVP HOP. Si no se encuentra ninguna coincidencia, el
mensaje se descarta.
Los mensajes PathErr pueden ser generados por cada nodo a lo largo de una reserva que detectó un error. La
dirección IP del nodo que generó el mensaje se incluye en el objeto ERROR SPEC junto con el código del error
detectado. El mensaje se envía salto por salto hacia el remitente utilizando la información almacenada en el
estado de la ruta. El mensaje no modifica ningún estado en el camino y solo se reporta a la aplicación del
remitente.
Al igual que el mensaje PathErr, el ResvErr puede ser generado por cualquier nodo a lo largo de la ruta que
descubre un error. La dirección del nodo y el código del error se incluyen en el objeto ERROR SPEC. El
mensaje en este caso viaja hopby-hop hacia todos los receptores, notificando a todos los nodos y puntos de
fusión de la reserva en el camino.
El mensaje ResvConf se envía como respuesta a la recepción de un mensaje Resv que ha integrado un objeto
RESV CONFIRM. El mensaje se transmite a la dirección obtenida del objeto RESV CONFIRM sobre una base de
salto por salto para acomodar el mecanismo de verificación de integridad salto por salto [2]. El objeto ERROR
SPEC se usa en este caso solo para llevar la dirección del nodo que originó el mensaje.
En la Fig. 4 presentamos una visión general de un flujo de mensajería RSVP como se ilustra en [2].
A continuación, presentaremos con más detalle cómo se envían los mensajes de RSVP, cuál es el
comportamiento asociado con el estado de bloqueo y las interfaces que están involucradas en el proceso de
RSVP.
La mayoría de los mensajes de RSVP se envían salto por salto entre los enrutadores compatibles con RSVP
como datagramas IP sin procesar con el número de protocolo 46 [2]. Sin embargo, debido a que algunos
sistemas finales pueden no admitir E / S de red sin formato, también se puede usar la encapsulación UDP.
Para los mensajes RSVP que no se envían salto por salto, como los mensajes Path y PathTear, pero también
para el mensaje ResvConf, la opción IP de alerta de enrutador debe estar activada en su encabezado de IP.
Esta opción permitirá a los enrutadores realizar un procesamiento especial para estos datagramas. Para
evitar problemas asociados con la fragmentación de IP, cada mensaje RSVP debe ocupar exactamente un
datagrama de IP.
Los mensajes de RSVP se envían de una manera poco confiable y se basan en mensajes de actualización
periódicos para recuperarse de una posible pérdida de paquetes.
Sin embargo, en condiciones de sobrecarga de la red, el aumento de la pérdida de paquetes de los mensajes
RSVP puede provocar una falla de reserva. Por lo tanto, se recomienda que los enrutadores se configuren
para ofrecer un tratamiento preferido a los mensajes de RSVP para evitar este tipo de comportamiento.
En lo que respecta al uso del estado de bloqueo, cuando se crea un mensaje de actualización de Resv,
normalmente las FLOWSPEC de las solicitudes de reserva se combinan al calcular su límite superior inferior
(LUB). Sin embargo, esta regla se modifica por la existencia de un estado de bloqueo asociado con una de las
reservas a fusionar. Las reservas que no están bloqueadas se combinan al calcular su LUB, mientras que las
reservas bloqueadas se ignoran. Si todas las solicitudes de reserva están bloqueadas, entonces se fusionan al
calcular el límite inferior más grande (GLB).
Se sugiere que el valor predeterminado del período de actualización R sea de 30 segundos. El impacto de
tener un valor más bajo de R significaría una aceleración de la adaptación a los cambios de enrutamiento,
pero al mismo tiempo causará una sobrecarga de enrutamiento cada vez mayor. Un valor más alto dispararía
el efecto inverso. Se recomienda que el valor del período del temporizador de actualización se seleccione
aleatoriamente en el rango [0,5R; 1,5R]. Esta recomendación se debe a la interrupción que una señalización
sincronizada puede hacer a la red.
Además del período de actualización (R) para generar mensajes de actualización, también hay una vida útil
del estado local (L). El valor de L está determinado por el valor R, y ambos pueden variar de un nodo a otro.
El valor L debe satisfacer la condición: L ≥ (K + 0.5) ∗ 1.5 ∗ R. Donde, K simboliza cuántos mensajes de
actualización pueden perderse antes de que se agote el estado. Se sugiere un valor de 3 para K, pero este
valor depende de las características del nodo (si se espera una tasa de pérdida alta, K debería tener un valor
más alto).
C. estados de RSVP
La información que se transmite por RSVP a través de mensajes se almacena en nodos en el camino en lo que
se define como estados. Estos estados se almacenan en nodos utilizando estructuras de datos genéricos
denominados bloques de estado. En total, se definen cuatro bloques de estado para ser utilizados por RSVP:
el bloque de estado de ruta (PSB) que corresponde al estado de ruta, los bloques de estado de reserva (RSB)
correspondientes al estado de reserva, el bloque de estado de bloqueo (BSB) correspondiente al estado de
bloqueo y un Bloque de Estado de Condicionamiento de Tráfico (TCSB) que es responsable de mantener las
especificaciones de diferentes reservas para una interfaz de salida precisa.
En la Tabla II presentamos el contenido que está almacenado en el PSB. La mayor parte de la información del
PSB proviene directamente del mensaje de Ruta que creó ese estado. Además de los objetos RSVP, el PSB
también captura datos del encabezado IP, por ejemplo, el IP TTL restante y del proceso de enrutamiento, por
ejemplo, la lista de interfaces salientes (lista OutInterface) y la interfaz entrante (IncInterface) para este
estado.
El RSB contiene una solicitud de reserva derivada de un mensaje Resv e identificada por SESSION, RSVP HOP
y un objeto virtual llamado lista de especificaciones de filtro. Este objeto depende del estilo y puede ser una
lista de ESPECIFICACIONES DE FILTROS para el estilo SE, una única ESPECIFICACIÓN DE FILTROS para el estilo
FF o vacía para el estilo WF. Presentamos en la Tabla III el contenido almacenado en el RSB. Contrariamente
al caso de PSB, toda la información que se almacena en el RSB proviene de los mensajes de RSVP.
El TCSB contiene información para una interfaz de salida específica. La información TCSB se deriva de la RSB
para esa interfaz saliente [16]. Cada TCSB identifica una reserva única utilizando una tupla compuesta por la
SESIÓN, la Interfaz de salida (OI) y la lista de especificaciones del filtro. El formato del TCSB se ilustra en la
Tabla IV. El TC Flowspec representa el LUB sobre los valores FLOWSPEC en todos los RSB coincidentes. El
valor TC Flowspec se utiliza para realizar la reserva real, que se pasa al control de tráfico [16].
El formato del BSB se presenta en la Tabla V. Dependiendo del estilo utilizado, el BSB puede usar el par
compuesto por SESSION y Previous Hop (PHOP) como identificador o el par compuesto por SESSION y
SENDER TEMPLATE. Otros elementos que componen el BSB son el FLOWSPEC Qb y el Bloqueo del
temporizador Tb, donde el primer parámetro representa el FLOWSPEC de la reserva ofensiva y el segundo el
tiempo que el flujo debe permanecer en el BSB.
III. EL USO DE RSVP BAJO INTSERV
En esta sección vamos a ilustrar la especificación requerida para los dos modelos de prestación de servicios
introducidos por los Servicios Integrados (IntServ): Servicios de Carga Controlada (CLS) y Servicios
Garantizados (GS). Presentamos estas especificaciones distintas del diseño original, ya que representan una
adición al esquema de RSVP y porque IETF las trata como dos partes diferentes introducidas en RFC
separados.
El uso de RSVP en IntServ se especificó en RFC 2210 [17]. Este estándar presenta cómo los Servicios de carga
controlada y los Servicios garantizados propuestos por IntServ se pueden implementar mediante RSVP. Es
importante que exista una modalidad que pueda usarse para comunicar los requisitos de la aplicación a
diferentes nodos en la red.
El RFC 2210 definió la forma en que los objetos relacionados con los servicios de control de QoS deben
usarse y cuál es el formato exacto de estos objetos en RSVP. Se describieron tres de estos objetos:
FLOWSPEC, ADSPEC y SENDER TSPEC.
La información que describe el flujo de tráfico para el que se solicita la reserva (TSPEC del receptor) y los
parámetros necesarios para invocar el servicio (RSPEC del receptor) se incluyen en el objeto FLOWSPEC. Esta
información se transporta desde el receptor a los nodos intermedios y finalmente al remitente. La
información contenida en el objeto FLOWSPEC puede modificarse en su camino hacia el remitente mediante
nodos intermedios. La modificación puede ser causada por la fusión de flujos o por algunos otros factores.
La información generada por cada remitente, que describe el flujo de datos, es transportada por el objeto
SENDER TSPEC. Esta información nunca es modificada por los nodos intermedios de la red. La información
generada o modificada por los elementos de la red con respecto a los parámetros específicos de los servicios
de control de QoS (es decir, servicios disponibles, demora, estimación del ancho de banda) se transfiere a los
receptores en los objetos ADSPEC. ADSPEC representa un resumen de estos parámetros calculados o
modificados en cada nodo en el camino. Los valores de los parámetros describen las propiedades de la ruta
sin tener en cuenta cuál es la QoS solicitada. Los receptores necesitan esta información para determinar las
especificaciones de reserva necesarias.
Los ejemplos de parámetros incluidos en el objeto ADSPEC son la estimación del ancho de banda de ruta
(BW) que proporciona información sobre el ancho de banda estimado disponible a lo largo de la ruta y el
parámetro de latencia de ruta mínima que registra el valor más pequeño absoluto para la latencia. ADSPEC
incluye también uno o más bits de ruptura. Uno de los bits más importantes es el bit de interrupción global
(GBb). Este bit se establece originalmente en 1 'cuando se crea un objeto ADSPEC. Si existe un nodo a lo largo
de la ruta que no admite RSVP, el bit se establece en 0 'por otro elemento de red que ha sido consciente de
la brecha (por ejemplo, comparando el parámetro de cuenta de salto IS con el valor TTL de IP del encabezado
IP) ). El hecho de que se encuentre un nodo no compatible con RSVP indica que todos los demás parámetros
de ADSPEC pueden ser inválidos.
Si el objeto ADSPEC es responsable de descubrir las propiedades de la ruta en términos de QoS disponible,
los objetos SENDER TSPEC y FLOWSPEC se usan para transportar los parámetros del tráfico que fluirá en esa
ruta.
SENDER TSPEC describe la vista del remitente de los parámetros para el tráfico generado en forma de token
bucket. Además de la tasa de cubeta (r) y la profundidad de la cubeta (b), también se especifican en el objeto
SENDER TSPEC una unidad mínima controlada (m) y un tamaño máximo de paquete (M). Esta información
puede ser utilizada posteriormente por el Servicio garantizado o los Servicios de carga controlada para
establecer los parámetros apropiados en el objeto FLOWSPEC.
El objeto FLOWSPEC transporta la información necesaria para la solicitud de reserva. El formato del objeto
FLOWSPEC, como el formato del objeto ADSPEC, depende del tipo de servicio que requiera el receptor. Tanto
en el caso de CLS como en el de GS, los parámetros de tráfico se expresan en especificaciones de token
bucket similares a las del objeto SENDER TSPEC.
La especificación para GS incluye, además del token bucket de TSpec, también presente en el caso de CLS, los
parámetros RSpec. RSpec introduce especificaciones adicionales de QoS en el caso de que se utilice GS. Los
términos incluidos en RSpec son el término R, que indica la velocidad reservada deseada expresada en bytes
por segundo y el término holgado S que se expresa en microsegundos [18]. El término holgura se utiliza para
expresar la diferencia entre el retardo deseado y el retardo obtenido utilizando la tasa R.
Las especificaciones sobre cuál es el comportamiento esperado del elemento de red que soporta CLS se
presentaron en [19]. La QoS recibida bajo CLS se aproxima a la QoS que el flujo recibiría de un elemento de
red descargado. El comportamiento de extremo a extremo que se ofrece a una aplicación sujeta a CLS se
aproximará al servicio recibido por la aplicación en una red de mejor esfuerzo con poca carga.
Para garantizar este tipo de comportamiento, los elementos de la red se proporcionan con una estimación
del tráfico de datos que se generará. Cada salto a lo largo de un flujo de datos que utiliza CLS debe garantizar
que estén disponibles los recursos adecuados de ancho de banda y procesamiento de paquetes, como se
especifican en TSpec, antes de aceptar la solicitud.
La cantidad de datos enviados no debe exceder de rT + b, donde T es la duración del período de tiempo,
mientras que r y b son los parámetros del paquete de fichas. Los paquetes que son más grandes que el
enlace rT + b o que son más grandes que la MTU del enlace saliente se consideran no conformes. Los
paquetes no conformes se reenviarán según el mejor esfuerzo si hay suficientes recursos disponibles. El
parámetro m se utiliza como la unidad de medida mínima para el contenedor de fichas. Incluso si el tamaño
de un datagrama es menor que m, se contará como de tamaño m.
El parámetro del valor p existe solo por razones de compatibilidad. No se definió ningún uso específico del
parámetro de velocidad pico en [19].
El comportamiento del elemento de red requerido para la entrega de servicios garantizados se presenta en
[20]. Dado que GS es empleado por el tráfico que requiere garantías estrictas en el retraso, el límite del
retraso representa una preocupación importante en este caso. Es importante notar aquí que el retraso se
compone de dos partes principales: un retraso fijo y un retraso en la cola. Si bien el retraso fijo es una
propiedad de la ruta elegida, el retraso en la cola está determinado por el tiempo que un paquete debe
permanecer en diferentes colas para obtener el servicio.
El retardo en la cola se expresa principalmente como una función de dos parámetros: un tamaño de cubeta
(b) y una tasa de datos (R). Estos dos valores están bajo el control de la aplicación, y una aplicación puede
estimar a priori cuál es el retraso en la cola que el servicio garantizado podrá asegurar.
El comportamiento de extremo a extremo se ajusta a un retardo de colas entregado que no excede el
retardo del modelo fluido en más de los límites de error especificados. El modelo fluido representa el servicio
que proporcionaría un cable dedicado entre la fuente y el receptor [20].
El límite del retardo de extremo a extremo está determinado por la función: - [(b − M) / R ∗ (p − R) / (p − r)] +
(M + Ctot) / R + Dtot para el caso cuando la tasa de datos (R) es más pequeña que la tasa de datos pico (p)
pero más grande que la tasa de agrupamiento de fichas (r ≤ R <p) - (M + Ctot) / R + Dtot cuando la tasa de
datos (R) es mayor que tanto la velocidad de datos del contenedor de fichas como la velocidad de pico (r ≤ p
≤ R) Donde, b (tamaño del contenedor de fichas), r (velocidad de depósito de fichas), p (velocidad de datos
de pico) y M (tamaño máximo del datagrama) se definen como antes.
Ctot y Dtot son términos de error que representan cómo los elementos de la red se desvían del modelo
fluido. Estos términos se calculan de extremo a extremo a lo largo de todo el camino desde los términos de
errores dependientes de la tasa (C) e independientes de la tasa (D) incorporados en el objeto ADSPEC.
En términos de vigilancia policial, los parámetros de token y tasa máxima son los que se utilizan para
garantizar que la cantidad de datos a enviar sea menor que M + min [pT, rT + b − M]. Si se excede este nivel,
los datagramas se considerarán no conformes y se tratarán como tráfico de mejor esfuerzo.
IV. EXTENSIONES DE RSVP
IETF ha introducido varias extensiones a lo largo del tiempo para proporcionar funciones adicionales al
protocolo. Vamos a ilustrar en esta sección algunas de las adiciones más importantes al protocolo: el
mecanismo de mejora de túneles de IP, la autenticación criptográfica, la extensión introducida para el
control de políticas y las mejoras de las interfaces RSVP. Otras extensiones, como la facilidad de diagnóstico
[21] se omiten en este resumen.
A. RSVP mejora de tunelización IP
Uno de los problemas asociados con RSVP fue que, en el caso de los túneles IP, la señalización de RSVP no
era posible. Esto se debe al hecho de que los paquetes RSVP que ingresan a un túnel se encapsulan con un
encabezado IP externo, donde el número de protocolo no es 46 (4 para IP en la encapsulación de IP) y donde
la opción de alerta de enrutador está desactivada. Este tipo de configuración hace que los paquetes RSVP
sean invisibles para los enrutadores con capacidad RSVP entre los puntos finales del túnel.
Con el propósito de permitir operaciones RSVP a través de túneles IP, se introdujeron dos nuevos objetos en
RFC 2746 [22], el objeto SESSION ASSOC y el objeto NODE CHAR. El primer objeto se introdujo para asociar
una sesión de extremo a extremo con una sesión de túnel, al incluir este objeto en el mensaje de ruta de
extremo a extremo en el punto de entrada del túnel.
El punto de entrada del túnel encapsula y envía mensajes de ruta de extremo a extremo a través del túnel
hasta el punto final del túnel donde el mensaje se desencapsula y se envía en sentido descendente. Al mismo
procedimiento le sigue el punto final del túnel al recibir un mensaje Resv. Teniendo en cuenta la información
presente en la ruta de extremo a extremo, el FLOWSPEC en el Resv de extremo a extremo y las políticas
locales, el punto de entrada del túnel decide cómo asignar la sesión de extremo a extremo a una sesión de
túnel. El punto de entrada del túnel envía un mensaje de ruta para una nueva sesión de túnel que contiene el
objeto SESSION ASSOC que asocia la sesión de extremo a extremo a la sesión de túnel. El punto final del túnel
responde al mensaje de Ruta recibido transmitiendo un mensaje Resv y reservando recursos dentro del
túnel.
El segundo objeto NODE CHAR se introdujo para permitir que el punto final del túnel informe al punto de
entrada del túnel que hay un punto final del túnel que admite las operaciones RSVP sobre los túneles IP.
Básicamente, el mecanismo de tunelización de IP de RSVP permite a RSVP hacer reservas a través de túneles
de IP en IP mediante la aplicación recursiva de RSVP para la parte del túnel de la ruta. En 22 se ofrece un
enfoque más detallado sobre cómo funciona el mecanismo de tunelización IP de RSVP.
B. RSVP autenticación criptográfica
La capacidad de RSVP para ofrecer protección contra la corrupción y la suplantación de identidad fue
presentada más tarde por IETF con la publicación de la autenticación criptográfica RFC 2747 RSVP. Dos
nuevos objetos fueron definidos en [14]: INTEGRIDAD, y DESAFÍO. Incluso si la existencia del objeto
INTEGRITY se mencionó en el RFC original que define RSVP, solo más tarde este objeto se definió junto con
las reglas de asociación de mensajes.
El código de autenticación de mensaje basado en hash (Message-Digest Message Digest-Digest) (HMACMD5) se presentó en [14] como el algoritmo criptográfico preferido utilizado para RSVP. También se pueden
admitir otros algoritmos criptográficos, pero se requiere HMAC-MD5 como una línea de base para que se
incluya universalmente en las implementaciones de RSVP. Una evaluación del desempeño del MD5 y otros
tres algoritmos hash comúnmente usados en el contexto de RSVP se presenta en [23]. Se encontró que,
dependiendo de los parámetros de la clave de autenticación y del algoritmo utilizado, el tiempo de
configuración de la conexión puede fluctuar [23].
La inclusión del objeto INTEGRIDAD en los mensajes de RSVP modifica ligeramente las reglas básicas de
procesamiento de los mensajes, tanto en la creación como en la recepción de un mensaje de RSVP. Esta
adición, solo introduce una forma en la que se puede ofrecer protección contra la falsificación o la
modificación de mensajes. El resto de las operaciones de RSVP, ya que se han presentado de antemano, no
se ven afectadas por este proceso.
El segundo objeto, el objeto DESAFÍO, se introdujo para crear el protocolo de intercambio de integridad, en
el reinicio o la inicialización del receptor. Este objeto se utilizará en el contexto de dos nuevos tipos de
mensajes definidos: el Desafío de integridad y el mensaje de Respuesta de integridad. Estos mensajes se
utilizan en el procedimiento de intercambio para obtener una clave de autenticación en vivo. Cada clave
obtenida tiene una vida útil limitada y no se puede utilizar ninguna clave fuera de su vida útil.
El resumen de mensaje con clave presente en el objeto INTEGRIDAD se calcula utilizando la clave de
autenticación obtenida, junto con el algoritmo de hash con clave HMAC-MD5.
C. Extensiones RSVP para el control de políticas
La capacidad de RSVP para admitir el control de admisión basado en políticas se introdujo conceptualmente
en la primera especificación del protocolo. Sin embargo, RFC 2205 solo establece la existencia del objeto
POLICY DATA que debe utilizarse para el control de políticas. El formato de este objeto y las acciones reales
que deben activarse en los nodos se presentaron más adelante en RFC 2750 [15]. La introducción del
mecanismo de control de políticas se explica en [15] como una característica normal de un protocolo que,
por definición, tiene que discriminar entre usuarios. La información de control de la política es transportada
por el objeto POLICY DATA situado en los mensajes de RSVP.
No todos los nodos son necesarios para admitir la aplicación de políticas. Los nodos que admiten este tipo de
ejecución se denominan puntos de cumplimiento de políticas (PEP) y los que se consideran no confiables
para manejar la información de políticas se denominan Nodos ignorantes de políticas (PIN). Incluso si un PIN
no maneja la información de la política, todavía está permitido procesar mensajes de RSVP. El supuesto
general hecho en RFC 2750 era que las PEP tienen más probabilidades de estar en la frontera entre
diferentes sistemas autónomos [15]. Incluso si los remitentes o los receptores no conocen los objetos de la
política, el PEP puede generar, modificar o eliminar estos objetos. Este tipo de comportamiento admite la
generación de políticas coherentes de extremo a extremo [15].
El formato del objeto POLICY DATA corresponde al formato general asociado con los objetos RSVP. En este
objeto hay dos campos especiales: la lista de opciones y la lista de elementos de política. Ambas listas tienen
longitud variable, dependiendo del número de elementos incluidos en las listas.
Todos los elementos en la lista de opciones son, de hecho, objetos RSVP normales que usan el mismo
formato pero que tienen un significado ligeramente diferente. Por ejemplo, FILTER SPEC, SCOPE y RSVP HOP
se utilizan para indicar a la PEP: los remitentes asociados con el objeto POLICY DATA (en el caso de los
objetos FILTER SPEC o SCOPE), el nodo adyacente que admite las políticas y el nodo de destino ( para el
objeto RSVP HOP). El objeto INTEGRIDAD se usa para crear una conexión directa segura entre PEP,
excluyendo de esta manera los nodos PIN.
La lista de elementos de política se rellena con elementos de política. Estos elementos de política solo los
entienden los PEP y son opacos para RSVP. La Autoridad de Números Asignados de Internet (IANA) es
responsable de asignar y mantener un registro de los puntos de código y el significado asociado de los
elementos de la política.
El control de políticas se aplica solo para cuatro tipos de mensajes: Ruta, Resv, PathErr y ResvErr. En general,
se supone que los mensajes de desmontaje solo se reciben desde los mismos nodos que enviaron la
instalación, según la verificación de integridad.
Como continuación de la especificación presentada en [15], RFC 2752 Identity Representation for RSVP
define la representación de la información de identidad en POLICY DATA [24]. La intención de la
representación de identidad es permitir una identificación segura del propietario y de la aplicación del
proceso de comunicación que solicita recursos de red. Para este propósito se definió un elemento de política
de Datos de Autentificación (DATOS AUTH).
Con la intención de ofrecer una manera por la cual los flujos se admiten en función de su importancia, y no
de la forma en que se recibe, se definió un elemento de política de prioridad en RFC 3181 [25]. Este
elemento utiliza las nociones de prioridad de prioridad y prioridad de defensa para indicar la importancia
relativa de un flujo dentro de un conjunto de flujos que compiten para ser admitidos en la red. El campo de
prioridad de prioridad indica la prioridad del nuevo flujo. Complementariamente, la prioridad de defensa se
utiliza para compararse con la prioridad de prioridad de nuevos flujos para decidir si un flujo existente se
debe o no.
Normalmente, el mecanismo de control de admisión que otorga recursos se basa en la identidad del usuario
o la aplicación. RFC 3520, sin embargo, propuso que puede ser valioso proporcionar la capacidad de control
de admisión por sesión, e introdujo un elemento de política de autorización de sesión que puede incluirse en
los mensajes de RSVP y ser verificado por la red [26]. El objetivo de este Elemento de política de autorización
de sesión (AUTH SESSION) es permitir el intercambio de información entre nodos en la red, a fin de autorizar
el uso de recursos para un servicio y coordinar acciones entre la señalización y los planos de transporte [ 26].
El host debe obtener un elemento AUTH SESSION y encapsularlo en el objeto POLICY DATA dentro del
mensaje de Ruta de RSVP.
Como especificación complementaria del elemento de política de prioridad de prioridad señalada definido en
[25], RFC 6401 introdujo una extensión para RSVP para admitir la prioridad de admisión en el nivel de control
de admisión de capa de red. Se introdujeron dos nuevos elementos de política de RSVP, que permiten
incorporar la prioridad de admisión en los mensajes de señalización de RSVP. Esto garantiza que se pueda
aplicar un control de admisión de ancho de banda selectivo en nodos RSVP según la prioridad de admisión de
sesión [27]. Los nuevos elementos de política introducidos se denominan Elemento de política de prioridad
de recursos de nivel de aplicación (ALRP) y Elemento de política de prioridad de admisión.
El Elemento de política de prioridad de recursos a nivel de aplicación se utiliza para transmitir información a
nivel de aplicación en los mensajes de RSVP. Los elementos de política de ALRP se procesan en un punto de
decisión de política (PDP) local. Un PDP representa un nodo que controla el PEP en la periferia de un área de
política. Después de procesar el elemento de política ALRP, el PDP incluye la información del nivel de
aplicación en el nuevo elemento de política de prioridad de admisión definido.
El Elemento de la Política de Prioridad de Admisión fue diseñado para ser simple, sin estado y ligero. Este
elemento de política se procesa fácilmente en PEP y permite el uso de los modelos de asignación de ancho
de banda introducidos para redes MPLS-TE compatibles con DiffServ. Estos modelos de asignación de ancho
de banda son el Modelo de asignación máxima (MAM) estandarizado en [28], el Modelo de muñecas rusas
(RDM) introducido en [29] y el Modelo de asignación máxima con reserva (MAR) especificado en [30].
También se introduce en [27] un nuevo modelo de asignación de ancho de banda más simple, el Modelo de
Bypass de Prioridad (PrBM). En [31] y [32] se puede encontrar una descripción más detallada sobre cómo
funciona el modelo de asignación de ancho de banda.
La discusión sobre los elementos y mecanismos de control de políticas no representa el enfoque principal de
este documento. Sin embargo, estos se presentaron para ilustrar la capacidad y la modularidad de RSVP en la
aplicación de estos mecanismos de control. Se puede encontrar más información sobre los mecanismos de
control de políticas en el RFC que introduce el Servicio Abierto de Políticas Comunes (COPS), especificaciones
sobre el uso de COPS para RSVP [33] y actualización de RFC como [15] [34] [27] y [35] .