ES2234524T3

ES2234524T3 - Protocolo de tunel basado en rsvp que proporciona servicios integrados.

Info

Publication number: ES2234524T3
Application number: ES00301168T
Authority: ES
Inventors: Mooi Choo Chuah; Muralidharan Sampath Kodialam; Anlu Yan
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1999-02-26
Filing date: 2000-02-15
Publication date: 2005-07-01
Anticipated expiration: 2020-02-15
Also published as: EP1035688A2; DE60017622T2; DE60017622D1; KR20000076719A; JP2000253071A; EP1035688B1; EP1035688A3; JP3545988B2; US6519254B1

Abstract

Un método para uso en un servidor de paquetes, comprendiendo el método las operaciones de: recibir (205) tráfico de señales basado en RSVP (protocolo de reserva de recursos); y correlacionar (225) una sesión de RSVP extremo a extremo en un túnel (60) entre un punto de fuente de túnel "TSP" (15) y un punto de destino del túnel "TDP" (25); caracterizado porque: dicho servidor de paquetes sirve como dicho TDP; dicho tráfico de señales basado en RSVP contiene parámetros para un túnel RSVP propuesto entre el TSP y el TDP que permitiría que un conjunto de flujos de paquetes individuales agregados se desplazase dentro de una calidad de servicio "QoS" dada a través de dicho túnel RSVP propuesto; dicho método incluye determinar un túnel RSVP real suficiente para satisfacer los parámetros dentro del tráfico de señales de RSVP; y dicha operación de correlación correlaciona la sesión RSVP extremo a extremo para el túnel determinado.

Description

Protocolo de túnel basado en RSVP que proporciona servicios integrados.

Campo del invento

Este invento se refiere en general a las comunicaciones y, más particularmente, a sistemas de comunicaciones por paquetes.

Antecedentes del invento

En el pasado, todo el tráfico de datos que utilizaba Internet se trataba por igual y se transmitía utilizando un mecanismo "lo mejor posible". Sin embargo, con el tiempo, la necesidad de soportar en Internet aplicaciones en tiempo real (por ejemplo, herramientas para audio/vídeo-conferencia, aplicaciones de juegos, etc.), exigió cierta forma de ofrecimiento de servicios diferenciados. En consecuencia, los técnicos están definiendo nuevos protocolos para proporcionar calidad de servicio (QoS) a los usuarios de Internet.

El protocolo de reserva de recursos (RSVP) es uno de tales protocolos. El RSVP es un protocolo activado por el receptor, extremo a extremo, utilizado por anfitriones receptores para señalar la calidad de servicio (QoS) deseada a los elementos de red a lo largo de una vía de flujo de datos. En RSVP, la granularidad de una petición de QoS se determina sobre una base de flujo de paquetes (por ejemplo, véase R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, "Protocolo de reserva de recursos (RSVP) - Versión 1, Especificaciones funcionales", RFC 2205).

Sin embargo, el proporcionar una garantía de QoS sobre una base de flujo de paquetes origina problemas de escalabilidad en los encaminadores troncales (véase, por ejemplo, "Agregando peticiones de QoS basadas en RSVP", de R. Guerin, S. Blake, S. Herzog, draft-guerin-aggreg-rsvp-00.txt, de Noviembre de 1997). Por ejemplo, para cada flujo de paquetes (denominado también en este documento sesión de protocolo de control de transacciones/protocolo de Internet (TCP/IP)) en un encaminador, hay un estado de reserva que comprende, por ejemplo, una fuente TCP/IP, un destino TCP/IP y un número de protocolo TCP/IP. Como tal, la necesidad de un encaminador para seguir cada una de las sesiones TCP/IP individuales ocupa una cantidad significativa de la memoria del encaminador y de los recursos de tratamiento. Además, la naturaleza de extremo a extremo del RSVP le hace inadecuado para ser usado con el fin de reservar conductos virtuales a través de la red.

Una solución al problema anterior consiste en agregar los flujos de paquetes y proporcionar túneles RSVP entre dos encaminadores, como se describe en "Agregando peticiones de QoS basadas en RSVP", de R. Guerin, S. Blake, S. Herzog, draft-guerin-aggreg-rsvp-00.txt, de Noviembre de 1997; y en "Operaciones de RSVP en túneles de IP", de A. Terzis, J. Krawczyk, J. Wroclaski, L. Zhang, draft-ietf-rsvp-tunnel-01.txt, de Agosto de 1998. Ahora, las sesiones de RSVP que pasan por un par de puntos de extremo de túnel pueden proporcionar servicios diferentes (por ejemplo, servicio garantizado (garantiza un retardo en el peor de los casos) o un servicio de carga controlada (garantiza un ancho de banda mínimo)), el mismo servicio con diferentes parámetros (por ejemplo, distinto requisito de retardo en un servicio garantizado) o servicios similares con políticas diferentes. Así, puede existir un número de diferentes túneles entre un par de puntos extremos de un túnel.

Steve Benson, en "IETF December 1998 Proceedings", en el 43º IETF Meeting Report [en línea], del 25 de Noviembre de 1998 (1998-11-25) al 10 de Diciembre de 1998 (1998-12-10), páginas 1-4, XP002237918 Orlando, Florida, EE.UU., recuperado en Internet: /43rd-ietf-98dec-134.html> registra discusiones en las que se planteaba un problema relativo a la unión dinámica de sesiones RSVP extremo a extremo con sesiones RSVP pre-configuradas en un túnel IP en IP. Se indicaba que la semántica de RSVP exige que el extremo receptor sea capaz de tomar esta decisión
de unión dinámicamente. Es decir, la unión debe determinarse sólo cuando llegue el mensaje de reserva del receptor.

Sumario del invento

Un método y un servidor de paquetes de acuerdo con el invento son como se establece en las reivindicaciones independientes. En las reivindicaciones dependientes se establecen formas preferidas.

Aunque la forma modificada, antes mencionada, de RSVP, que agrega peticiones de QoS basadas en RSVP, constituye una solución al problema, dicha forma modificada de RSVP ya no está puramente orientada al receptor. En particular, la información contenida en el mensaje RESV de RSVP extremo a extremo (del receptor al emisor) no es utilizada por el punto fuente del túnel para tomar la decisión sobre la correlación sesión-túnel. Esto no sólo viola el paradigma de orientación al receptor del RSVP sino que, también, tiene como resultado una falta de eficacia en la utilización del ancho de banda.

Por tanto, hemos desarrollado un nuevo protocolo túnel basado en RSVP que establece una sesión RSVP de extremo a extremo por un túnel para paquetes entre un punto fuente de túnel (TSP) y un punto destino del túnel (TDP) en una forma que es consistente con el paradigma de RSVP activado por el receptor. En particular, una sesión de RSVP extremo a extremo se correlaciona utilizando un tipo RSVP de tráfico de señales orientado al receptor tal que el TDP determina la correlación del túnel. Como tal, este nuevo tipo RSVP de protocolo es consistente con la naturaleza de activado por el receptor del RSVP y, por tanto, no requiere cambios en el protocolo RSVP existente.

En una realización del invento, el protocolo RSVP es modificado para soportar la correlación orientada al receptor de sesiones RSVP extremo a extremo para túneles entre un TSP y un TDP. En particular, el TDP utiliza información contenida en el mensaje RESV de RSVP extremo a extremo, para determinar la correlación de sesión a túnel. Esta correlación es transmitida al TSP a través de un objeto TUNNEL_BINDING.

De acuerdo con otras características del invento, cuando se proporciona un servicio garantizado, el TDP configura dinámicamente túneles hacia el TSP y realiza la sintonización de túneles para túneles establecidos. Esta última característica permite adaptar dinámicamente túneles existentes a las condiciones de tráfico, con el fin de mejorar la eficacia del ancho de banda. El procedimiento de sintonización de túneles puede tener como consecuencia la reasignación a túneles de algunas de las sesiones RSVP extremo a extremo admitidas.

Breve descripción de los dibujos

Las Figs. 1-2 ilustran partes de transacciones de mensajes RSVP extremo a extremo de la técnica anterior;

la Fig. 3 muestra una red de acuerdo con los principios del invento;

la Fig. 4 muestra parte de una transacción de mensaje basado en RSVP extremo a extremo, de acuerdo con los principios del invento;

la Fig. 5 representa una gráfica de proceso ilustrativa de acuerdo con los principios del invento;

la Fig. 6 muestra un formato de mensaje PATH (VÍA) RSVP que comprende un TSpec;

las Figs. 7-8 ilustran un objeto RSVP AdSpec para servicio garantizado;

la Fig. 9 muestra un formato de mensaje RESV RSVP que comprende un objeto sesión y un objeto FlowSpec;

la Fig. 10 muestra un objeto TUNNEL_BINDING ilustrativo, de acuerdo con los principios del invento;

la Fig. 11 representa parte de una transacción de mensaje por túnel; y

la Fig. 12 muestra un diagrama de bloques de alto nivel, ilustrativo, de un punto de destino de túnel.

Descripción detallada

La descripción que sigue está dividida en varias partes. La primera de ellas describe un breve antecedente de alto nivel seguido por una visión general del nuevo protocolo de túnel basado en RSVP. A continuación de la sección de visión general, se ofrecen secciones más detalladas que cubren la gestión de túnel, el control de asignación/admisión de túnel activado por el receptor, la configuración de túnel y la sintonización de túnel.

Visión general

Como antecedente, en la Fig. 1 se muestra parte de una transacción de mensaje RSVP de extremo a extremo ilustrativa, para participar en una sesión de RSVP con servicio garantizado. Un emisor envía un mensaje PATH RSVP a un receptor (identificado por una dirección de IP unidifusión o multidifusión, respectiva). Unidos al mensaje PATH RSVP están el objeto Sender TSpec y el objeto ADSPEC. El objeto Sender TSpec especifica las características de flujo que el emisor es capaz de enviar, y el objeto ADSPEC contiene los parámetros sometidos a modificaciones por los encaminadores a lo largo de la vía hasta el receptor. Cuando un receptor realiza una reserva, calcula la cantidad de ancho de banda que necesita de acuerdo con su requisito de retardo y con los parámetros contenidos en el objeto ADSPEC (que, como se ha mencionado, pueden haber sido modificados por los encaminadores antes citados y no mostrados). El receptor envía entonces un mensaje RESV RSVP aguas arriba para reservar el ancho de banda a lo largo de la vía recorrida por el mensaje PATH RSVP. Los detalles de estas operaciones se especifican en el trabajo, antes mencionado, "Especificación de calidad de servicio garantizada", de S. Shenker, C. Partridge y R. Guerin, RFC 2212, y en "El uso de RSVP con servicios IETF integrados", de J. Wroclawski, RFC 2210.

Como se ha hecho notar anteriormente, es posible llevar a cabo una sesión RSVP extremo a extremo por un túnel RSVP. Se trata, justamente de una sesión RSVP en la que el TSP es el emisor y el TDP es el receptor. Cuando una sesión RSVP extremo a extremo pasa entre el TSP y el TDP, el TSP correlaciona la sesión extremo a extremo en uno de los m túneles RSVP entre ellos. El conjunto de m túneles se establece previamente entre el TSP y el TDP, por ejemplo, utilizando un servidor de control o un servidor de autenticación de autorización y cuenta (AAA) (no mostrado), como es sabido en la técnica. Como resultado, en lugar de una sesión RSVP por flujo entre el TSP y el TDP, pueden agregarse múltiples flujos en un único túnel RSVP, por lo que puede reducirse así fuertemente el número de estados mantenidos en los encaminadores intermedios. Cuando los datos para un flujo extremo a extremo llegan a un TSP, son encapsulados de forma que los encaminadores intermedios no distingan entre flujos diferentes que pertenezcan al mismo túnel. Para distinguir túneles RSVP diferentes, se utiliza encapsulación IP en UDP (protocolo de datagrama de usuarios), como se ha descrito en el artículo, antes mencionado, "Operaciones RSVP en túneles IP", de Terzis y otros. En este esquema de encapsulación (para los que se describen en este artículo como túneles tipo 2), los números de las puertas de destino UDP sirven como identificadores de túnel. Tras ser agregado a un túnel, un flujo individual ha de compartir el ancho de banda con otros flujos del mismo túnel. Por tanto, el túnel ha de ser tratado como un elemento de red de retardo puro cuando llega a actualizar el ADSPEC del flujo extremo a extremo, como se ha descrito en el artículo antes mencionado "Agregando peticiones de QoS basadas en RSVP", de Guerin y otros. Parte de una transacción de mensaje de la técnica anterior para establecer una sesión RSVP extremo a extremo en un túnel se muestra en la Fig. 2. Como se ha hecho notar en lo que antecede, la forma modificada de RSVP antes mencionada (e ilustrada en la Fig. 2), no es consistente con el paradigma de RSVP activado por receptor ya que el TSP determina la correlación de túnel y la información de correlación para una sesión de RSVP extremo a extremo sin información alguna acerca del receptor.

Por tanto, hemos desarrollado un nuevo protocolo túnel basado en RSVP que establece una sesión RSVP extremo a extremo en un túnel de paquetes entre un TSP y un TDP de forma consistente con el paradigma de RSVP activado por el receptor. En particular, una sesión RSVP extremo a extremo es correlacionada utilizando un tipo RSVP de señalización orientado al receptor, tal que el TDP determina la correlación del túnel utilizando la información del mensaje RSVP extremo a extremo.

Una red 10 ilustrativa, de acuerdo con los principios del invento, se ilustra en la Fig. 3. A diferencia del concepto del invento, los elementos mostrados en la Fig. 3 son bien conocidos y no se describirán con detalle. Por ejemplo, aunque se muestra como un elemento monobloque, el proveedor 15 de servicios de Internet (ISP) incluye procesadores con control por programas almacenados, memoria y encaminadores/servidores (por ejemplo, encaminador de punto de presencia (POP), servidores de acceso a red (NAS), etc.) (no mostrados). La red 10 incluye una pluralidad de ISP, representados por el ISP 15 y el ISP 25 acoplados vía Internet 50. Esta última es representativa de cualquier infraestructura de red basada en el protocolo de Internet (IP) e incluye otros componentes (no mostrados) tales como encaminadores, etc., para comunicar paquetes IP entre puntos extremos de paquetes. Igualmente, las líneas continuas entre elementos de la red 10 son representativas de instalaciones de comunicaciones bien conocidas entre los puntos extremos respectivos, por ejemplo, la conexión entre ISP 15 e Internet 50, ilustrada mediante la línea 22, está soportada por modo de transferencia asíncrona (ATM) en una red óptica síncrona (SONET), etc. De forma similar, las líneas 11 y 21 son representativas de cualquier número y tipo de instalaciones de comunicaciones, por ejemplo, líneas T1/E1 (para cada dirección), etc., para entrar en la red 10 y salir de ella vía el ISP 15 y el ISP 25, respectivamente. (Los emisores y los receptores para este tráfico no se muestran por sencillez). Además, se supone que el lector está familiarizado con el protocolo RSVP antes mencionado. Aunque el RSVP soporta servicios integrados, por ejemplo, un servicio garantizado o un servicio de carga controlada, la descripción de este documento utiliza, ilustrativamente, el servicio garantizado. Se supone, también, para los fines de esta descripción, que el funcionamiento del ISP 15 y del ISP 25 son complementarios y que el ISP 15 es un TSP y que el ISP 25 es un TDP. Como tal, esta descripción supone que el TSP y el TDP son fijos y tienen uno conocimiento del otro (por ejemplo, cada uno de ellos conoce la dirección del otro). Además, el TSP sabe qué flujos de tráfico han de ser encaminados a través del TDP. En este contexto, y como se describe con más detalle en lo que sigue, el o los túneles RSVP 60 (línea interrumpida) se establecen para conectar el ISP 15 con el ISP 25 y el tráfico que ha de encaminarse a través del o de los túneles RSVP 60 es identificado por la dirección de subred de destino del tráfico correspondiente.

Para el resto de esta descripción, a los mensajes RSVP relacionados con el túnel se les añade un prefijo "TUNNEL_" con el fin de distinguir los mensajes RSVP para el túnel de aquéllos para los flujos extremo a extremo. Además, se supone que cuando los datos para un flujo extremo a extremo llegan a un TSP, se utiliza un túnel tipo 2 con fines de encapsulación, como se ha descrito en el artículo antes mencionado "Operaciones RSVP en túneles IP", de Terzis y otros. Similarmente, cada túnel es tratado como un elemento de red de retardo puro, como se ha descrito en el artículo, antes mencionado, "Agregando peticiones de QoS basadas en RSVP", de Guerin y otros.

Inicialmente, se supone que existe un conjunto de m túneles 60 entre el TSP y el TDP. De acuerdo con el invento, en la Fig. 4 se muestra parte de una transacción de mensaje extremo a extremo RSVP ilustrativa. Puede hacerse referencia, también, a la Fig. 5 que muestra una gráfica de proceso ilustrativa de acuerdo con los principios del invento para uso en el TDP. Se presume que el TDP está programado adecuadamente para llevar a la práctica los métodos descritos en lo que sigue empleando técnicas de programación usuales que, como tales, no se describen en esta memoria. Como el RSVP es un protocolo activado por el receptor, cuando un nuevo mensaje PATH RSVP extremo a extremo llega al TSP, el TSP simplemente encapsula el mensaje PATH RSVP extremo a extremo y lo envía al TDP. (Esto supone que los túneles no están preconfigurados estáticamente a priori). Al recibir el mensaje PATH RSVP extremo a extremo encapsulado (paso 205 de la Fig. 5), el TDP lo desencapsula, actualiza el ADSPEC (paso 210 de la Fig. 5) y lo envía a un receptor correspondiente (no mostrado) de acuerdo con el tráfico de señales RSVP extremo a extremo (paso 215 de la Fig. 5). Una vez que el receptor (no mostrado) recibe el mensaje PATH RSVP, calcula los parámetros necesarios para esta sesión RSVP (como en la técnica anterior) y envía de vuelta el mensaje RESV RSVP extremo a extremo. Cuando el TDP recibe este mensaje RESV RSVP (paso 220 de la Fig. 5), el TDP, de acuerdo con el invento, determina el túnel RSVP apropiado para esta sesión RSVP extremo a extremo ejecutando un procedimiento de control de asignación/admisión de túnel activado por el receptor (paso 225 de la Fig. 5, descrito con mayor detalle en lo que sigue) y, si se le admite (paso 230 de la Fig. 5), forma un objeto TUNNEL_BINDING para notificar al TSP de la sesión a unir en el túnel. (Si no se le admite, la sesión es denegada en el paso 235 de la Fig. 5). El TDP encapsula entonces el mensaje RESV RSVP extremo a extremo (junto con el objeto TUNNEL_BINDING asociado) y lo envía al TSP (paso 240 de la Fig. 5), que lo desencapsula. En respuesta al objeto TUNNEL_BINDING recibido, el TSP utiliza el túnel asignado por el TDP para la sesión RSVP extremo a extremo. El TSP envía la parte restante del mensaje RESV RSVP aguas arriba, al emisor (no mostrado). Como resultado, este tráfico de señales modificado permite que el TDP asigne un túnel a una sesión RSVP extremo a extremo basándose en los parámetros de los túneles y en los mensajes RESV extremo a extremo.

Con respecto a los mensajes antes mencionados, en la Fig. 6 se muestra un formato de mensaje PATH RSVP. En las Figs. 7-8 se muestra un objeto ADSPEC RSVP. En la Fig. 9 se muestra un mensaje RESV RSVP junto con un objeto Session y un objeto FlowSpec. (Debe observarse que, a diferencia del concepto del invento, estos formatos son como se define en RSVP). De acuerdo con el invento, en la Fig. 10 se ilustra un formato ilustrativo para el objeto TUNNEL_BINDING. (Debe observarse que el formato del objeto TUNNEL_BINDING es similar al del objeto sesión descrito en el artículo antes mencionado "Operaciones RSVP en túneles IP", de Terzis y otros).

Cuando el TSP recibe, subsiguientemente, tráfico de datos, encapsula los paquetes con la cabecera IP en UDP apropiada basándose en la unión sesión-a-túnel. El TSP también debe marcar el tráfico de datos desde cada flujo que no se adapte a su TSPEC individual, lo que quiere decir que el TSP necesita tener una función de control para cada flujo, como es conocido en la técnica.

Debe observarse que los túneles no tienen que estar configurados a priori, como se suponía inicialmente. En particular, el TDP puede configurar túneles dinámicamente hacia el TSP (como se describe con detalle más adelante). Este tipo de transacción de mensajes se muestra en la Fig. 11. (Debe observarse que, a diferencia de la posibilidad de configurar dinámicamente túneles en el TDP, este tipo de transacción de flujo de mensajes es igual que en la técnica anterior. En otras palabras, incluso para túneles previamente configurados, se produce este tipo de flujo de mensajes). Con respecto a la Fig. 11, para establecer un túnel RSVP, el TSP actúa como emisor, o fuente de datos, y envía un mensaje TUNNEL_PATH a la dirección unidifusión del TDP. Asociado al mensaje TUNNEL_PATH hay un objeto TUNNEL_ADSPEC. De acuerdo con una característica del invento (descrita más adelante), el TDP toma ahora decisiones acerca de cuántos túneles ha de establecer y de cómo asignar los recursos entre ellos, basándose en los parámetros contenidos en el objeto TUNNEL_ADSPEC recibido. El TDP envía entonces un mensaje TUNNEL_RESV al TSP para establecer el túnel.

Cada túnel establecido como se ha descrito anteriormente puede proporcionar un servicio de carga controlada o un servicio garantizado, como se define en el artículo "Parámetros generales de caracterización para elementos de red de servicios integrados", de S. Shenker y J. Wroclawski, RFC 2215. En las secciones que siguen, se describen algoritmos adicionales para gestionar túneles que proporcionan servicios garantizados.

Gestión de túnel para servicio garantizado

Antes de continuar con una descripción del control de asignación/admisión activado por el receptor, la configuración de túnel y los procedimientos de sintonización de túnel realizados en el TDP, se proporciona la siguiente información sobre túneles.

Diferentes sesiones RSVP extremo a extremo pueden tener distintos requisitos de retardo. Por tanto, resulta ventajoso tener garantías de retardo diferentes asociadas con cada túnel. Supongamos que hay n túneles entre el TSP y el TDP, con garantías de retardo d^{T}_{1} < d^{T}_{2} < ... < d^{T}_{n} para cada túnel, respectivamente. Entonces, una sesión RSVP extremo a extremo que requiera una garantía de retardo d entre el TSP y el TDP, será correlacionada para el túnel i si d^{T}_{1} < d < d^{T}_{i+1} suponiendo que el túnel i tenga capacidad suficiente.

Como tal, un TSpec para el túnel i se representa mediante un vector TS^{T}_{i} = (b^{T}_{i}, r^{T}_{i}, p^{T}_{i}, M^{T}_{i}, m^{T}_{i}), donde b^{T}_{i} es la magnitud del tren de impulsos, r^{T}_{i} es el régimen promedio, p^{T}_{i} es el régimen máximo, M^{T}_{i} es la unidad de transmisión de mensajes del túnel (MTU) y m^{T}_{i} es la unidad de cuenta (por ejemplo, véase el artículo antes mencionado "Parámetros generales de caracterización para elementos de red de servicios integrados", de S. Shenker y otros). En general, los valores C y D (véase el artículo antes mencionado "Especificación de calidad de servicio garantizada", de S. Shenker y otros) asociados con el túnel i, designados por C^{T}_{tot, i} y D^{T}_{tot, i} son funciones de T^{T}_{i} y, por tanto, pueden ser diferentes para cada túnel. (Debe observarse que en el caso de servicio garantizado, D_{tot} es actualizado, pero C_{tot} no).

Sin abandonar la generalidad, consideremos dos túneles que garanticen el retardo d^{T}_{1} y d^{T}_{2}, respectivamente. La garantía de retardo, d, se calcula mediante:

(1)d = \frac{b + C}{R} + D

donde b es la magnitud del tren de impulsos, R es el ancho de banda reservado y C y D son como se define en el artículo antes mencionado "Especificación de calidad de servicio garantizada", de S. Shenker y otros.

Cada túnel requerirá un ancho de banda:

(2)R^{T}_{i} = (b^{T}_{i} + C^{Y}_{tot, i})/(d^{T}_{i} + D^{Y}_{tot, i}),

donde i = 1, 2. Si los dos túneles se agrupan, entonces debe haber un retardo de garantía d^{T}_{1} y el nuevo TSpec es TS^{T}_{g} = (b^{T}_{1} + b^{T}_{2}, + r^{T}_{1} + r^{T}_{2}, p^{T}_{2} + p^{T}_{2}, max {M^{T}_{1}, M^{T}_{2}}, min {m^{T}_{1}, m^{T}_{2}}). De manera correspondiente, este túnel tendrá C^{T}_{tot, g} y D^{T}_{tot, g}, y necesita un ancho de banda:

(3)R^{T}_{g} = (b^{T}_{1} + b^{T}_{2} + C^{T}_{tot, g})/(d^{T}_{1} - D^{T}_{tot, g})

Evidentemente, si R^{T}_{g} \leq R ^{T}_{1} + R^{T}_{2}, entonces es preferible establecer un túnel en vez de dos.

Como cualesquiera encaminadores intermedios actualizan C_{tot} y D_{tot} en TUNNEL_ADSPEC basándose parcialmente en el TUNNEL_TSpec enviado desde el TSP, si el TDP decide utilizar un TUNNEL_TSpec diferente, entonces C^{T}_{tot} = f(TUNNEL_TSpec) y D^{T}_{tot} = h (TUNNEL_TSpec) puede ser, también, diferente, siendo f y h funciones desconocidas para TSP y TDP. Como resultado, el TDP necesita, en general, conocer la función f y h con el fin de calcular R^{T} correctamente.

Para encontrar las funciones f y h, el TSP puede enviar varios mensajes TUNNEL_PATH con diferentes TUNNEL_TSPEC. Al recibir estos TUNNEL_TSPEC junto con los TUNNEL_ADSPEC asociados, el TDP puede estimar, entonces, f y h por interpolación. Los mensajes TUNNEL_PATH no utilizados para la reserva de túnel se perderán.

En realidad, no es probable que f y h sean funciones complicadas. Por ejemplo, si todos los encaminadores intermedios incorporan el algoritmo WFQ (gestión equitativa de los ficheros de espera con ponderación), entonces C^{T}_{tot} = (k – 1)M^{T} y D^{T}_{tot} = \sum^{k}_{j}M^{T}/C_{j}, donde k es el número de saltos en el túnel y C_{j} es la velocidad de enlace de cada salto. En este caso, el TSP envía mensajes TUNNEL_PATH con diferentes valores de M^{T} al tiempo que mantiene todos los otros componentes en TUNNEL_TSPEC fijos. El TDP recoge entonces un conjunto de datos (M^{T}_{j}, C^{T}_{j}, D^{T}_{j}) a partir de los TUNNEL_TSPEC y los TUNNEL_ADSPEC y los ajusta a funciones lineales de M^{T} que son los límites superiores de C^{T}_{j} y D^{T}_{j}, respectivamente.

Cuando existen múltiples vías entre el TSP y el TDP, los valores de C^{T}_{tot} y de D^{T}_{tot} pueden ser muy distintos a lo largo de vías diferentes (por lo demás, no hay necesidad de distinguir estas vías). En tales casos, el TDP puede clasificar primero los datos en grupos y, luego, proceder a la interpolación. Alternativamente, el TDP también puede tener un único límite superior de C^{T} y D^{T} para todos los grupos pero eso puede resultar demasiado conservador.

Para simplificar la gestión de túneles, siempre se utiliza la MTU de túnel como M^{T} para todos los túneles. Se supone, además, que tanto C^{T} como D^{T} son constantes para un M^{T} dado. Esto es consistente con los valores exportados a partir de los encaminadores de WFQ. Evidentemente, el RSVP también supone esto implícitamente para que, aún cuando un receptor pueda especificar un TSpec diferente de aquél que recibe del emisor, el receptor continúe utilizando los mismos valores C y D asociados con el TSpec en el mensaje PATH para calcular la necesidad de ancho de banda. Si esta suposición no se sostiene, puede utilizarse el método de interpolación antes esquematizado y la complejidad del cálculo dependerá de la forma de f y de h.

En la anterior suposición:

(4)R^{T}_{1} + R^{T}_{2} = (b^{T}_{1} + C^{T}_{tot})/(d^{T}_{1} - D^{T}_{tot}) + (b^{T}_{2} + C^{T}_{tot})/(d^{T}_{2} - D^{T}_{tot})

y si los dos túneles se funden en uno el ancho de banda deseado es

(5)R^{T}_{g} = (b^{T}_{1} + b^{T}_{2} + C^{T}_{tot})/(d^{T}_{1} - D^{T}_{tot})

Por tanto

(6)R^{T}_{g} - (R^{T}_{1} + R^{T}_{2}) = \frac{b^{T}_{2}}{d^{T}_{1} - D^{T}_{tot}} - \frac{b^{T}_{2} + C^{T}_{tot}}{d^{T}_{2} - D^{T}_{tot}}

Si b^{T}_{2} es fijo, se trata de una función que crece monótonamente con respecto a d_{2} y, cuando

(7)d^{T}_{2} < d^{T}_{1} + (d^{T}_{1} - D^{T}_{tot})\frac{C^{T}_{tot}}{b^{T}_{2}},

\hskip0,5cm

entonces

(8)R^{T}_{g} < R^{T}_{1} + R^{T}_{2}

Es decir, se economizará ancho de banda fundiendo los dos túneles en uno. Debe observarse que cuando d^{T}_{2} = d^{T}_{1}, R^{T}_{g} - (R^{T}_{1} + R^{T}_{2}) = -C^{T}_{tot}/d^{T}_{1} - D^{T}_{tot} < 0. En otras palabras, esto siempre ahorra ancho de banda reuniendo sesiones con los mismos requisitos de retardo en un túnel. Este caso especial se observó en el trabajo de S. Rampal y R. Guerin, "Agrupamiento de flujo para reducir los requisitos de reserva para un servicio de retardo garantizado", draft-rampal-flow-delay-service-01.txt, de Julio de 1997.

Hagamos d^{T}_{2} \rightarrow \infty en la ecuación (6), entonces:

(9)R^{T}_{g} - (R^{T}_{1} + R^{T}_{2}) = \frac{b^{T}_{2}}{d^{T}_{1} - D^{T}_{tot}} > 0

Este es otro caso extremo que muestra que cuando d^{T}_{2} es bastante grande, será más eficiente, para el ancho de banda, mantener los dos túneles separados.

A partir de la anterior exposición, puede observarse que el retardo puede ser un buen índice a utilizar cuando haya que decidir cómo distribuir los túneles para utilizar el ancho de banda en forma eficiente. Desde luego, éste es el caso.

Supongamos que hay n sesiones de RSVP con el conjunto de parámetros (b_{i},R_{i},d_{i}), i=1,....,n, y supongamos que estas sesiones han sido clasificadas por d_{i}. Si se establece un túnel para garantizar un retardo d^{T}, ninguna sesión con un requisito de retardo menor que d^{T} puede ajustar en este túnel. Por otro lado, no resulta eficiente, desde el punto de vista del ancho de banda, establecer una sesión i con un requisito de retardo mayor que d^{T} en un túnel con un retardo garantizado d^{T}_{i} < d^{T}. Esto es evidente porque el ancho de banda adicional necesario para añadir esta sesión a un túnel con un retardo garantizado d^{T} es \DeltaR = b_{i}/(d^{T} - D^{T}_{tot}), y el ancho de banda para añadir esta sesión a un túnel con un retardo garantizado d^{Ti} es \DeltaR' = b_{i}/(d^{T1} - D^{T}_{tot}) > \DeltaR.

Esto muestra que para un conjunto de sesiones dado, si se establecen túneles para proporcionar varios retardos garantizados d^{T}_{1} < d^{T}_{2} ... < d^{T}_{n}, resulta eficiente en cuanto al ancho de banda, establecer una sesión con un requisito de retardo d^{T}_{j} \leq d^{i} < d^{T}_{j+1} en el túnel j. Por tanto, si los túneles han de configurarse previamente basándose en estadísticas de sesiones de RSVP dadas, las sesiones RSVP deben clasificarse primero por d_{i} (descrito adicionalmente en lo que sigue).

Como el TSP en general no tiene conocimiento de que clase de TSpec pueden soportar los túneles, el TSP simplemente envía lo que conoce como el mayor TSpec posible. Específicamente, el TSP envía b^{T} para que sea su tamaño de memoria intermedia, p^{T} para que sea la suma de la velocidad del enlace entrante (o infinito), r^{T} para que sea la velocidad del enlace saliente, M^{T} para que sea el máximo tamaño de paquete soportado por la interconexión saliente, y m^{T} para que sea la unidad de cuenta más pequeña que soporte el TSP.

El TSP tampoco conoce el número apropiado de túneles a establecer, de forma que durante el período de establecimiento de túneles, el TSP envía al menos tantos mensajes TUNNEL_PATH como número de túneles pueda soportar el TSP. Los mensajes TUNNEL_PATH en exceso pueden ser utilizados para soportar, si fuese necesario, interpolación de parámetros y serán despejados de los encaminadores cuando no se reciban mensajes TUNNEL_RESV correspondientes dentro de un intervalo de temporización.

El número apropiado de túneles y los valores de TUNNEL_SPEC son calculados por el TDP. El TDP envía entonces mensajes TUNNEL_RESV junto con el TUNNEL_TSPEC en el TUNNEL_FLOWSPEC al TSP. El mensaje TUNNEL_RESV debe utilizar un estilo de reserva FF, con la dirección de IP que especifica Filterspec del número de puerto de destino de TSP y UDP.

Asignación de túnel activada por el receptor/Control de admisión

RSVP es un protocolo activado por el receptor. Basándose en el requisito de retardo de la aplicación y en los parámetros recibidos en TSpec y ADSPEC en el mensaje PATH RSVP de extremo a extremo, el receptor calcula el ancho de banda R deseado, el término S de poca actividad y el TSpec deseado, y los envía aguas arriba en el FLOWSPEC.

De acuerdo con el invento, tras recibir el mensaje PATH RSVP encapsulado desde el TSP, el TDP lo desencapsula y modifica el ADSPEC. El TDP siempre anuncia C=0 y D = d^{T}_{1} (el retardo mínimo) para el túnel (incluso si el túnel no tiene más capacidad libre). Cuando el TDP recibe un mensaje RESV de vuelta desde el receptor, el TDP puede utilizar, opcionalmente, parte del término de poca actividad 0 \leq S_{0} \leq S y correlaciona esta sesión a cualquier túnel i que garantice un retardo menor que d^{T}_{1} + S_{0}. El TDP reduce entonces S en d^{T}_{i} - d^{T}_{1}. Si ninguno de los túneles seleccionables posee capacidad suficiente para esta nueva sesión, todavía es posible correlacionar esta sesión en otro túnel sin violar la garantía de retardo. Esto se explicará más adelante.

El anunciar el único valor de retardo posible mínimo d^{T}_{1} para el túnel hace que el protocolo sea sencillo y escalable - el TDP no necesita conocer los diversos requisitos de garantía de retardo del receptor, el TDP simplemente anuncia lo mejor que puede hacer. Ha de observarse que, debido a la naturaleza de activado por el receptor del protocolo RSVP, el TDP tampoco conoce el requisito de retardo de la sesión de RSVP cuando trata la ADSPEC procedente del emisor.

Si el receptor puede tolerar más retardo, entonces una opción es poner el valor excesivo en el término S de poca actividad. En este caso, el TDP puede utilizar el valor excesivo para correlacionar la sesión en un túnel que tenga una garantía de retardo menos estricta, como antes se ha mencionado. La otra opción del receptor es, simplemente, reservar una menor cantidad de ancho de banda. Si la mayoría de los receptores elige la segunda opción, entonces el túnel que ofrece el retardo mínimo necesitará que se comparta mejor el ancho de banda. Esta cuestión se trata con más detalle en lo que sigue.

A partir de la descripción que antecede, puede verse que aunque los túneles se establecen antes de las peticiones de sesión de RSVP, el TDP intenta hacer el mejor uso de los túneles (es decir, correlaciona sesiones en túneles) empleando los mensajes TSpec y RESV procedentes del receptor.

Para cada túnel RSVP, el TDP mantiene un conjunto de parámetros (b^{T},R^{T},d^{T},p^{T},M^{T}). Los TDP admiten una nueva sesión de RSVP en un túnel (pasos 225 y 230 de la Fig. 5), si todas las condiciones siguientes mantienen el valor de "verdadero":

(10)\sum _{i} b_{i} \leq b^{T},

(11)\sum _{i} r_{i} \leq R^{T},

(12)\sum _{i} p_{i} \leq p^{T},

(13)max _{i} \ M_{i} \ \leq \ M^{T}, \ \ y

(14)\frac{\sum _{i} b_{1} + C^{T}_{tot}}{d^{T} - D^{T}_{tot}} \leq R^{T}

Obsérvese que como se establece que p^{T} ha de ser la suma de la velocidad del enlace entrante del túnel, y se establece que M^{T} ha de ser la MTU del túnel, las condiciones representadas por las ecuaciones (12) y (13) siempre deben ser ciertas.

Configuración de túnel

Supongamos que antes de establecer cualquier túnel, existen estadísticas para sesiones de RSVP que tienen lugar a través del TSP y del TDP. Específicamente, para cada sesión se ha registrado i = 1,...,N,(b_{i}, R_{i}, S_{i}), siendo b_{i} el tamaño máximo de impulso, R_{i} el ancho de banda reservado y S_{i} el término de poca actividad. Suponiendo que tales estadísticas representen un diseño de tráfico típico, es deseable encontrar un modo de configurar los túneles para utilizar en forma eficiente el ancho de banda. Supuesto esto, se decide cuál de S_{i}, S^{0}_{i} ha de ser utilizado por el túnel. El algoritmo de configuración del túnel basado en el perfil del tráfico (Tunnel_Config (b, R, S^{0}, N)) es:

1.: Hagamos

d_{i} = \frac{b_{i} + C^{T}_{tot}}{R_{i}} + D^{T}_{tot}

2.: Clasifiquemos los vectores (R_{i}, b_{i}, d_{i} + S^{0}_{i}) utilizando d_{i} + S^{0}_{i} como clave, siendo i = 1,..., N.

3.: Para cada n = 1,..., N, se calcula:

R^{g}_{1, n} = \frac{\sum ^{N}_{i=1} b_{i} + C^{T}_{tot}}{d_{1} + S^{0}_{1} - D^{T}_{tot}}

y

R^{g}_{2, n} = \frac{\sum ^{N}_{i=n+1} b_{i} + C^{T}_{tot}}{d_{n+1} + S^{0}_{n+1} - D^{T}_{tot}}

4.: Se halla n_{0} = arg min {R^{g}_{1,n_{0}} + R^{g}_{2,n_{0}}}

5.: Si n_{0} = 1, se configura un túnel con d^{T} = d_{1} + S^{0}_{1}, b^{T} = \sum^{N}_{1} b_{i}, y R^{T} = (b^{T} + C^{T}_{tot})/(d^{T} + D^{T}_{tot}) y se detiene Tunnel_Config.

6.: Si n_{0} > 1, se ejecuta

: Tunnel_Config((b_{1},..., b_{n_{0}-1}), (R_{1},..., R_{n_{0}-1}), (S^{0}_{1}, ..., S^{0}_{n_{0}-1}), n_{0}-1) y

: Tunnel_Config((b_{n_{0}},...,b_{N}),(R_{n_{0}},...,R_{N}), (S^{0}_{n_{0}},...,S^{0}_{N}), N-n_{0}-1).

El procedimiento de configuración de túnel se inicia calculando d_{i} en el paso 1, que es el retardo que experimentaría la sesión i si se crease un túnel para esta sesión solamente. Luego, en el paso 2, se clasifica el vector (R_{i}, b_{i}, d_{i} + S^{0}_{1}) utilizando d_{i} + S^{0}_{1} como clave. Se dividen luego las sesiones en dos grupos y, en el paso 3, se calcula el ancho de banda para cada grupo. Se fija entonces la división que resulta en la cantidad menor de ancho de banda total, y se ejecuta el procedimiento en forma repetitiva para cada parte de la división en los pasos 4, 5 y 6. Cuando la realización de una división adicional, no reduce más el requisito de ancho de banda, se detiene la repetición.

Sintonización del túnel

La presencia de túneles en la vía de sesiones de RSVP es transparente tanto para los emisores como para los receptores. Como se ha descrito anteriormente, el TDP siempre anuncia la garantía de retardo más restrictiva que puede proporcionar. En consecuencia, lo que ve un receptor es el valor más pequeño de D_{tot} a lo largo de la vía. En casos en que la aplicación en el receptor pueda tolerar mayor retardo, le corresponde al receptor decidir si incluir un término de poca actividad o, simplemente, pedir un menor ancho de banda en el mensaje de reserva.

Como se ha mencionado anteriormente, si el TDP ve un término S>0 de poca actividad, el TDP puede, opcionalmente, utilizar parte del mismo. Por otro lado, si S=0, el TDP puede optar por no hacer nada y poner la sesión de RSVP en el túnel con la garantía de retardo más estricta. En consecuencia, es probable que este túnel se complete mucho más rápidamente que los otros. En general, como los túneles se dividen con anterioridad, no es probable que el diseño de tráfico case con los parámetros sobre los que se ha basado la división de los túneles. En tales casos, los parámetros de túnel pueden ajustarse dinámicamente para adaptarse a los diseños de tráfico.

La garantía de retardo proporcionada por un túnel es función de la magnitud b^{T} del tren de impulsos y del ancho de banda R^{T}, como se muestra en el antes mencionado artículo "Agregando peticiones de QoS basadas en RSVP", de Guerin y otros. Obsérvese que si una sesión necesita una garantía de retardo d, sólo cuando se hayan completado todos los túneles con garantía de retardo menor que d, es necesario emplear un túnel j, con d^{T}_{j} > d. En otras palabras, debe ajustarse d^{T}_{j} de manera que d^{T}_{j, nueva} < d^{T}_{j, antigua}. Esto supone que ha de incrementarse el ancho de banda para un túnel existente o que ha de reducirse la magnitud del tren de impulsos permitido en un túnel, con d^{T}> d. En cualquier caso, se envía una TUNNEL_FLOWSPEC desde el TDP al TSP para anunciar el cambio de parámetro del túnel.

Si bien la petición de aumentar el ancho de banda R^{T}_{j} del túnel puede fallar dependiendo del ancho de banda disponible, la petición de reducir la magnitud b^{T}_{j} del tren de impulsos no debe hacerlo. Por tanto, la reducción de la magnitud del tren de impulsos es un modo preferible de ajustar dinámicamente el túnel.

Para que un túnel proporcione una nueva garantía de retardo d^{T}_{nueva}, la nueva magnitud del tren de impulsos disponible es

(15)b^{T}_{nueva} = (d^{T}_{nueva} - D^{T}_{tot}) * R^{T} - C^{T}_{tot}

Antes de tomar la decisión de solicitar una reducción de la magnitud del tren de impulsos, el TDP debe, primero, verificar que los criterios de admisión (descritos en lo que antecede) seguirían vigentes para el nuevo túnel.

También puede llevarse a cabo un ajuste del túnel en forma temporal. A saber, una vez que han terminado las sesiones con necesidades de retardo pequeño, un túnel puede cambiarse devolviéndolo a sus parámetros originales mediante el envío de un TUNNEL_FLOWSPEC desde el TDP al TSP.

Aunque un ajuste dinámico del túnel ayuda a cambiar los parámetros del túnel para adaptarse a la necesidad del tráfico corriente, también puede tener como consecuencia que los túneles tengan garantías de retardo similares. Como se ha descrito en lo que antecede, en tales casos puede ser más eficaz, desde el punto de vista del ancho de banda, agrupar estos túneles. En general, el diseño de tráfico puede no casar con el inicialmente utilizado para dividir el túnel, por lo que, con el tiempo, puede ser necesario tener que cambiar la división del túnel para utilizar eficientemente el ancho de banda disponible. Como tal, el procedimiento de sintonización del túnel puede dar como resultado la reasignación al túnel de algunas de las sesiones de RSVP extremo a extremo admitidas.

El perfil del tráfico se describe, todavía, mediante un conjunto de vectores (b_{i}, R_{i}, S_{i}), que es registrado por el TDP. Sin embargo, a diferencia del ejemplo descrito anteriormente, el valor de la garantía de retardo se calcula de distinta manera.

Como el túnel ha anunciado un valor de retardo d^{T}, para cada sesión i, debe garantizar un retardo d^{T} + S^{T}_{i}, donde 0 \leq S^{0}_{i} \leq S_{i} es el valor de poca actividad que decidió utilizar el túnel. El algoritmo de sintonización del túnel es similar al algoritmo de configuración del túnel (mostrado en lo que antecede) excepto por el modo en que se calcula el retardo. El algoritmo de sintonización del túnel (Tunnel_Tunning (b, R, S^{0}, N)) es:

1.: Supongamos

d_{i} = d^{T};

2.: Clasifiquemos los vectores (R_{i}, b_{i}, d_{i} + S^{0}_{i}) utilizando d_{i} + S^{0}_{i} como clave, cuando i = 1,..., N.

3.: Para cada n = 1,..., N, se calcula:

y

4.: Se halla n_{0} = arg min {R^{g}_{1,n_{0}} + R^{g}_{2,n_{0}}}

5.: Si n_{0} = 1 se configura un túnel con d^{T} = d_{1} + S^{0}_{1}, b^{T} = \sum^{n}_{1}b_{i}, y

: R^{T} = (b^{T} + C^{T}_{tot})/(d^{T} - D^{T}_{tot}) y se detiene Tunnel_Tuning.

6.: Si n_{0} > 1, se ejecuta

: Tunnel_Tuning((b_{1},...,b_{n_{0}-1}), (R_{1},...,R_{n_{0}-1}), (S^{0}_{1},...,S^{0}_{n_{0}-1}),n_{0}-1) y

: Tunnel_Tuning((b_{n_{0}},...,b_{N}), (R_{n_{0}},...,R_{N}), (S^{0}_{n_{0}},...,S^{0}_{N}), N-n_{0}+1).

Otro factor significativo que afecta al comportamiento del protocolo es el valor de retardo de túnel anunciado (el menor de entre todos los túneles). Si este valor es demasiado grande, entonces algunos receptores pueden encontrar el retardo intolerable de forma que la sesión de RSVP fallará. Por otro lado, si este valor es demasiado pequeño y los receptores no proporcionan términos de poca actividad (o son utilizados por los encaminadores entre el TDP y los receptores), entonces la consecuencia de esto puede ser una demanda excesiva del ancho de banda del túnel.

Para encontrar el valor de retardo anunciado apropiado, el TDP comienza con un pequeño valor anunciado y lo incrementa gradualmente (también en una escala de tiempo mucho mayor que el ajuste dinámico) hasta que exista un incremento significativo en las sesiones de RSVP que fallan.

Como puede verse a partir de lo que antecede, se ha descrito un nuevo protocolo de túnel basado en RSVP que posee las siguientes características distintivas.

-: El TDP toma las decisiones acerca de qué sesión de extremo a extremo se asigna a qué túnel basándose en los parámetros de los túneles y en los mensajes de RESV de extremo a extremo procedentes de los receptores,

-: EL TDP anuncia un único valor de retardo para todos los túneles entre el TSP y el TDP. Esto hace que el protocolo sea sencillo y escalable.

-: Basándose en el perfil del tráfico, el TDP divide los túneles para utilizar eficazmente el ancho de banda.

-: El TDP ajusta los túneles en respuesta a la dinámica del tráfico.

-: El TDP sintoniza el túnel en una escala de tiempo mayor para mejorar el comportamiento del protocolo.

-: Si C y D son funciones desconocidas de algunos parámetros en TSPEC, pueden enviarse múltiples mensajes TSPEC con diferentes valores de parámetros y las funciones pueden estimarse por interpolación.

La primera característica hace que el protocolo sea consistente con la naturaleza de activado por el receptor de RSVP, y los restantes elementos hacen que el protocolo sea simple, escalable, flexible y, sin embargo, haga un uso eficiente del ancho de banda del túnel.

Volviendo brevemente a la Fig. 12, en ella se muestra un diagrama de bloques de alto nivel de un TDP representativo de acuerdo con los principios del invento. Un TDP es una arquitectura de procesador basada en un control por programa almacenado e incluye un procesador 650, una memoria 660 (para guardar datos e instrucciones de programa, por ejemplo, para comunicaciones de acuerdo con el nuevo protocolo de túnel basado en RSVP antes mencionado, etc.) y una o más interconexiones 665 de comunicaciones para acoplamiento con una o más instalaciones de comunicaciones, como se ha representado mediante la vía 666.

Lo que antecede simplemente ilustra los principios del invento y los expertos en la técnica apreciarán que será posible desarrollar numerosas disposiciones alternativas que, aunque no se han descrito explícitamente en este documento, incorporan el invento. Por ejemplo, el invento puede ser utilizado para proporcionar una garantía de QoS en la parte superior de los servicios IP para móviles. En este caso, se establece un túnel de IP entre el agente local y el agente externo, y dicho túnel utiliza RSVP para señalar el requisito de QoS para el tráfico agregado de manera que se satisfaga la necesidad de QoS para cada flujo individual.

Claims

1. Un método para uso en un servidor de paquetes, comprendiendo el método las operaciones de:

recibir (205) tráfico de señales basado en RSVP (protocolo de reserva de recursos); y

correlacionar (225) una sesión de RSVP extremo a extremo en un túnel (60) entre un punto de fuente de túnel "TSP" (15) y un punto de destino del túnel "TDP" (25);

caracterizado porque:

dicho servidor de paquetes sirve como dicho TDP;

dicho tráfico de señales basado en RSVP contiene parámetros para un túnel RSVP propuesto entre el TSP y el TDP que permitiría que un conjunto de flujos de paquetes individuales agregados se desplazase dentro de una calidad de servicio "QoS" dada a través de dicho túnel RSVP propuesto;

dicho método incluye determinar un túnel RSVP real suficiente para satisfacer los parámetros dentro del tráfico de señales de RSVP; y

dicha operación de correlación correlaciona la sesión RSVP extremo a extremo para el túnel determinado.

2. El método de la reivindicación 1, en el que el tráfico de señales basado en RSVP es un mensaje RESV RSVP transmitido por un receptor de la sesión RSVP extremo a extremo.

3. El método de la reivindicación 2, en el que la operación de correlación utiliza información contenida en el mensaje RESV RSVP para determinar la correlación entre sesión y túnel.

4. El método de la reivindicación 1, que comprende además la operación de enviar una forma encapsulada de un mensaje RESV RSVP al punto fuente del túnel, en el que la forma encapsulada del mensaje RESV RSVP incluye correlacionar información para el túnel y la sesión RSVP extremo a extremo correlacionada.

5. El método de la reivindicación 4, en el que la información de correlación, es transmitida mediante un objeto TUNNEL_BINDING unido al mensaje RESV RSVP encapsulado.

6. El método de la reivindiación 1, en el que la operación de correlación asigna la sesión RSVP extremo a extremo al túnel en función de un valor de tiempo de poca actividad extraído del tráfico de señales basado en el RSVP recibido y un valor mínimo de retardo del túnel.

7. El método de la reivindicación 1, que comprende además la operación de anunciar un único valor de retardo en un objeto AdSpec transmitido a un receptor, en el que la operación de anuncio ocurre con anterioridad a la operación de recepción.

8. El método de la reivindicación 1, que comprende además la operación de sintonizar el túnel real o un túnel pre-existente ajustando al menos un parámetro de túnel.

9. El método como se ha reivindicado en la reivindicación 8, en el que el parámetro de túnel es la magnitud de un tren de impulsos.

10. El método de la reivindicación 1, que comprende además la operación de sintonizar el túnel real o un túnel pre-existente reconfigurando, al menos parcialmente, el túnel real o el túnel pre-existente.

11. El método como se ha reivindicado en la reivindicación 10, que comprende además la operación de reasignar sesiones de RSVP extremo a extremo para conseguir un uso eficiente del ancho de banda disponible.

12. Un servidor de paquetes destinado a:

recibir (205) tráfico de señales basado en "RSVP" protocolo de reserva de recursos; y

correlacionar (225) una sesión de RSVP extremo a extremo en un túnel entre un punto de fuente del túnel "TSP" (15) y un punto de destino del túnel "TDP" (25);

caracterizado porque:

dicho servidor de paquetes está destinado a servir como dicho TDP;

dicho tráfico de señales basado en RSVP contiene parámetros para un túnel RSVP propuesto entre el TSP y el TDP que permitirían que un conjunto de flujos de paquetes individuales agregados viajasen dentro de una calidad de servicio "QoS" dada a través de dicho túnel RSVP propuesto;

dicho servidor de paquetes está destinado a determinar un túnel RSVP real suficiente para satisfacer los parámetros dentro del tráfico de señales RSVP; y

dicha correlación correlaciona la sesión de RSVP extremo a extremo en el túnel predeterminado.

13. El servidor de paquetes de la reivindicación 12, en el que el tráfico de señales recibido basado en el RSVP es un mensaje RESV de RSVP transmitido por un receptor de la sesión de RSVP extremo a extremo.

14. El servidor de paquetes de la reivindicación 13, destinado a utilizar información contenida en el mensaje RESV de RSVP para determinar la correlación entre sesión y túnel.

15. El servidor de paquetes de la reivindicación 12, destinado a enviar una forma encapsulada de un mensaje RESV RSVP al punto fuente del túnel, en el que la forma encapsulada del mensaje RESV RSVP incluye información de correlación para el túnel y la sesión de RSVP extremo a extremo correlacionada.

16. El servidor de paquetes de la reivindicación 15, en el que la información de correlación es transmitida por medio de un objeto TUNNEL_BINDING unido al mensaje RESV RSVP encapsulado.

17. El servidor de paquetes de la reivindicación 12, destinado a correlacionar la sesión de RSVP extremo a extremo en el túnel en función de un valor de tiempo con poca actividad extraído del tráfico de señales recibido basado en el RSVP y un valor mínimo de retardo del túnel.

18. El servidor de paquetes de la reivindicación 12, destinado a anunciar un valor de retardo único en un objeto AdSpec transmitido a un receptor, en el que el anunció ocurre con anterioridad a la recepción, por el servidor de paquetes, del tráfico de señales basado en el RSVP.

19. El servidor de paquetes de la reivindicación 12, destinado a sintonizar el túnel real o un túnel pre-existente ajustando al menos un parámetro del túnel.

20. El servidor de paquetes como se reivindica en la reivindicación 19, en el que el parámetro del túnel es la magnitud de un tren de impulsos.

21. El servidor de paquetes de la reivindicación 12, destinado a sintonizar el túnel real o un túnel pre-existente reconfigurando, al menos parcialmente, el túnel real o el túnel pre-existente.

22. El aparato como se reivindica en la reivindicación 21, en el que el servidor de paquetes reasigna, además, sesiones de RSVP extremo a extremo para hacer un uso eficiente del ancho de banda disponible.