ES2351586T3

ES2351586T3 - Manejo del flujo de prioridad en dominios sin estado.

Info

Publication number: ES2351586T3
Application number: ES07729600T
Authority: ES
Inventors: Attila Bader; Andras Csaszar
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-05-29
Filing date: 2007-05-29
Publication date: 2011-02-08
Anticipated expiration: 2027-05-29
Also published as: PL2153590T3; EP2153590B1; ATE479256T1; JP4921589B2; AU2007353984A1; US8780710B2; US20100177633A1; BRPI0721805A2; JP2010528542A; WO2008145178A1; AU2007353984B2; EP2153590A1; DE602007008772D1

Abstract

Un método de gestionar la calidad de servicio en una red IP que transmite flujos de datos que tienen al menos dos niveles de prioridad, el método que comprende: identificar, en un nodo de borde de salida (303, 304) de la red, que la congestión está presente en uno o más encaminadores (306) dentro de la red; seleccionar los flujos de datos para la terminación para eliminar la congestión; enviar una notificación de terminación del flujo inicial desde el nodo de borde de salida a un nodo de borde de entrada (301, 302) de la red, la notificación de terminación del flujo inicial que identifica los flujos de datos seleccionados; y terminar los flujos de baja prioridad a partir de los flujos de datos seleccionados en el nodo de borde de entrada cuando la notificación de terminación del flujo inicial se recibe; y caracterizado por: en el nodo de borde de salida, después de los periodos de medición predeterminados, identificar si la congestión todavía está presente y, si lo está, seleccionar los flujos de datos adicionales para la terminación y enviar las notificaciones de terminación de flujo consecutivo al nodo de borde de entrada, las notificaciones de terminación de flujo adicionales que identifican los flujos de datos adicionales; y terminar los flujos de alta prioridad a partir de los flujos de datos seleccionados en el nodo de borde de entrada solamente si: al menos uno de los mensajes de notificación de terminación consecutivos se recibe por el nodo de borde de entrada después de que ha transcurrido un periodo de retardo predeterminado desde la recepción de la notificación de terminación del flujo inicial; y el al menos un mensaje de notificación de terminación consecutivo recibido después del periodo de retardo predeterminado incluye los mismos flujos de alta prioridad en los flujos de datos adicionales seleccionados para la terminación.

Description

Campo de la invención

La presente invención se refiere al manejo del flujo de prioridad en dominios de red IP sin estado. En particular, la invención se refiere a un sistema para mantener los flujos de alta prioridad cuando hay congestión en las redes.

Antecedentes de la invención

La prestación de servicios de emergencia es cada vez más importante en las redes de telecomunicaciones. Los flujos de datos o las llamadas de emergencia normalmente deben tener prioridad sobre otras llamadas o flujos de datos en la red. La Recomendación Y.1541 del ITU-T, “Objetivos del Rendimiento de la Red para Servicios basados en IP”, mayo de 2002, especifica distintos tipos de prioridad para las redes IP.

En las redes IP, los protocolos de gestión de recursos en el trayecto de datos ha sido investigado en años recientes para asegurar la calidad de servicio (QoS). Tales protocolos son responsables de asegurar que las necesidades de recursos se cumplen para los flujos de datos que llegan al borde de un dominio de red o sistema autónomo, y para asegurar que los nodos interiores del dominio se proporcionan con información con respecto al trayecto futuro del flujo. Esto habilita los nodos de interior para tomar una decisión de control de entrada local. Un flujo se admite normalmente en un dominio de red solamente si todos los nodos interiores en el trayecto lo han admitido. Un flujo se admite extremo a extremo solamente si todos los dominios intermedios han tomado una decisión de entrada positiva. La entrada de un flujo requiere también la reserva de recursos en todos los nodos interiores (excepto para el control de entrada basado en pura medición).

Los Servicios Integrados (IntServ) es una arquitectura adoptada para asegurar la QoS para tráfico en tiempo real y no en tiempo real en Internet. La organización de estandarización Grupo de Trabajo de Ingeniería de Internet (IETF) ha especificado el Protocolo de ReSerVa de Recursos (RSVP) para reservar recursos en encaminadores IP, como se especifica en la RFC 2205. Cada encaminador a lo largo del trayecto de datos almacena los estados de reserva “por flujo”. Los estados de reserva son estados “suaves”, que tienen que ser refrescados enviando mensajes de refresco periódicos. Si un estado reservado no se refresca, el estado y los recursos correspondientes se eliminan después de un periodo de tiempo de espera. Las reservas también se pueden eliminar mediante mensajes explícitos de desmontaje. Los mensajes RSVP siempre siguen el trayecto de datos, y así el RSVP puede funcionar junto a los protocolos de encaminamiento estándar. Si el tráfico se reencamina, los mensajes de refresco hacen las reservas en el nuevo trayecto de datos.

En grandes redes el número de flujos, y por lo tanto el número de estados de reserva, es alto. Esto puede conducir a los problemas de almacenar y mantener los estados por flujo en cada encaminador. Otra arquitectura, Servicios Diferenciados (DiffServ), se ha propuesto por lo tanto para proporcionar la QoS en redes a gran escala, y esto se describe en la RFC 2475. En la arquitectura DiffServ, se ofrecen los servicios en una base agregada, más que por flujo, para permitir escalar hasta grandes redes. En tanto en cuanto el estado por flujo sea posible se fuerza a los límites de la red, y se ofrecen distintos servicios para estos agregados en los encaminadores. Esto proporciona escalabilidad de la arquitectura DiffServ.

La diferenciación del servicio se logra usando el campo de Servicios Diferenciados (DS) en la cabecera IP. Los paquetes se clasifican en grupos de Comportamiento Por Salto (PHB) en los nodos de borde de la red DiffServ. Los paquetes se manejan en encaminadores DiffServ de acuerdo con el PHB indicado en el campo DS en la cabecera del mensaje. La arquitectura DiffServ no proporciona ningún medio para los dispositivos fuera del dominio para reservar dinámicamente recursos o recibir indicaciones de la disponibilidad de los recursos de la red. En la práctica, los proveedores de servicios dependen de los Acuerdos de Nivel de Servicio (SLA) del tiempo de suscripción que definen estadísticamente los parámetros del tráfico que se aceptará desde un cliente.

El Grupo de Trabajo de Siguientes Pasos En Señalización (NSIS) del IETF actualmente está trabajando en un protocolo para cumplir los requerimientos de nueva señalización de las redes IP de hoy en día, según se define en la RFC 3726. El protocolo de aplicación de la señalización de QoS de los NSIS es fundamentalmente similar al RVSP, pero tiene varios nuevos rasgos, uno de los cuales es el soporte de distintos Modelos de QoS. Uno de los modelos QoS bajo especificación es la Gestión de Recursos en DiffServ (RMD). La RMD define los métodos de control de entrada escalables para redes DiffServ, de manera que los nodos interiores dentro de un dominio posean información de los estados agregados más que del estado por flujo. Por ejemplo, los nodos interiores pueden conocer el ancho de banda agregado reservado, más que cada reserva individual de flujo. La RMD también usa estados suaves (como con RSVP), y también es posible la liberación explícita de los recursos. La RMD también incluye una función de “derecho de uso preferente”, que es capaz de terminar una serie de flujos de paquetes requeridos cuando la congestión ocurre para mantener la QoS requerida para los restantes flujos. Esto se describe en la WO 2006/052174.

Un reciente Borrador de Internet (“Extensiones RSVP para Servicios de Emergencia”, F. Le Faucheur, y otros, draft-lefaucheur-emergency-rsvp-02.txt) especifica una extensión de RSVP para soportar los servicios de emergencia. Define un elemento de política de prioridad para RSVP y describe ejemplos del modelo de asignación de ancho de banda para la prioridad de entrada.

Cuando se usan los métodos por flujo (IntServ con señalización RSVP o QoS-NSLP), el manejo de los flujos de alta prioridad no es un problema, dado que cada nodo mantiene los estados por flujo. Donde se debe tomar una decisión para admitir o dar derecho de uso preferente a un flujo, se puede tener en cuenta la prioridad del flujo en cada encaminador. En los dominios “sin estado”, tales como la agregación RSVP o RMD, los nodos interiores no mantienen la información del estado por flujo, solamente los estados agregados (por ejemplo, por clase). Por lo tanto, no pueden asociar los paquetes de datos con la información de prioridad. En los métodos sin estado los nodos de borde son responsables de la admisión y derecho de uso preferente de los flujos, y también tienen que tomar las decisiones de prioridad.

En los métodos descritos en el Borrador de Internet “Extensiones RSVP para Servicios de Emergencia”, (F. Le Faucheur, y otros, draft-lefaucheur-emergency-rsvp02.txt) se tiene en cuenta la prioridad de entrada. Esto supone que estos métodos garantizan que se pueden admitir los flujos de mayor prioridad para la red con preferencia a los flujos de menor prioridad. No obstante, estas soluciones suponen un entrono que cambia lentamente (es decir, un incremento de llamadas relativamente lento y sin cambios de topología). El soporte de QoS, o manejo de prioridad en caso de fallo del enlace o del nodo, se basa en los estados por flujo, el cual no está disponible con protocolos sin estado tales como la RMD.

La RMD describe un método, conocido como un algoritmo de congestión grave, para asegurar la QoS en un dominio DiffServ sin estado cuando tiene lugar el reencaminamiento (debido, por ejemplo, al fallo del enlace o del nodo). Si un encaminador está gravemente congestionado (es decir están cayendo un gran número de paquetes), los nodos de borde de la RMD terminan algunos de los flujos para mantener la QoS para los flujos restantes. La prioridad de los flujos se puede tener en cuenta mediante los flujos de baja prioridad que caen preferentemente. Este planteamiento se describe, por ejemplo, en Stokkink: “Evaluación del Rendimiento de las Soluciones de Manejo de la Congestión Grave para Servicio Multinivel en Dominios RMD”, 4ª Conferencia de Estudiantes de Twente en IT, http://referaat.ewi.utwente.nl/documents/2006 04 A-Broadband for All/2006 04 A Stokkink, W.G.J.Performance_Evaluation_of_Severe_Congestion_Handling_Solutions_for_Multilevel_S ervice_in_RMD_domains.pdf. No obstante, el problema no está completamente resuelto.

Esto se puede entender considerando la situación ilustrada en la Figura 1. La Figura 1 es un diagrama esquemático de los nodos seleccionados en un dominio sin estado. El diagrama muestra un borde de entrada 101, el encaminador interior 102 y el borde de salida 103. Supongamos que hay congestión en el encaminador interior 102. De acuerdo con el algoritmo de congestión grave de RMD, los paquetes de datos se marcan por el encaminador interior para notificar a los nodos de borde sobre la congestión. El número de bytes marcados indica el tráfico en exceso. En cada nodo de borde de salida 103, se mide el número de bytes marcados, y se toma una decisión de terminar un número de flujos correspondiente. Esto se logra por el borde de salida 103 enviando un mensaje al borde de entrada 101 para terminar los flujos requeridos. La prioridad se tiene en cuenta seleccionando y terminando los flujos de baja prioridad.

No obstante, puede ser que terminando todos los flujos de baja prioridad aún no sea suficiente para superar la congestión, en cuyo caso los flujos de alta prioridad se terminarán también. Por ejemplo, supongamos la composición del tráfico 104 en el nodo de borde de salida 103 es tal que el 90% de los flujos son llamadas de alta prioridad 105. Esto puede surgir, por ejemplo, porque este nodo dirige el tráfico a un centro de emergencias. Si el 40% de todo el tráfico tiene que ser terminado, entonces todas las llamadas de baja prioridad 106 (10% del total) se terminarán, pero la congestión todavía estará presente. La congestión solamente se puede superar terminando aproximadamente el 30% del tráfico de alta prioridad además de todo el tráfico de baja prioridad.

No obstante, supongamos que hay muchas de las llamadas de baja prioridad pasando el encaminador congestionado 102, pero que dejan la red a través de otros nodos de salida. Esta situación se ilustra en la Figura 2, que muestra los nodos en un dominio similar al que se muestra en la Figura 1. Esta vez el dominio tiene dos nodos de salida distintos 103, 203 que tienen distintas composiciones 104, 204 de tráfico de baja y alta prioridad. En este ejemplo el primer nodo de borde de entrada 103 tiene el 10% de tráfico de baja prioridad 106 y el 90% de tráfico de alta prioridad 105, como antes. El segundo nodo de entrada 203 tiene el 80% de tráfico de baja prioridad 206 y el 20% de tráfico de alta prioridad 205. Esta vez, si hay un 40% de sobrecarga del encaminador 102, ambos nodos de salida terminarían el 40% del tráfico. El segundo nodo de borde de salida 203 sería capaz de terminar solamente los flujos de baja prioridad, pero el primer nodo de borde de entrada 103 terminaría aún el 30% de su tráfico de alta prioridad (como antes). Esto no es deseable, porque el segundo nodo de borde de salida 203 aún tiene flujos de baja prioridad 206 que se podrían terminar en preferencia a los flujos de alta prioridad en el primer nodo de salida 103. Si fueran terminados más flujos de baja prioridad 206 por el segundo nodo de salida 203, no habría necesidad para el primer nodo de salida 103 de terminar los flujos de alta prioridad 105.

Como consideración adicional está que, en situaciones de emergencia (es decir cuando hay muchos flujos de alta prioridad), los fallos del enlace o del nodo ocurren con mayor probabilidad que bajo condiciones normales, conduciendo a la congestión. De esta manera hay una posibilidad significativa que ocurran muchos flujos de alta prioridad y alta congestión al mismo tiempo. Es por lo tanto importante que las redes debieran manejar este problema adecuadamente.

Exposición de la invención

La invención describe un método de control de entrada y un método de derecho de uso preferente en dominios de red sin estado para manejar tráfico de prioridad. El algoritmo de control de entrada asegura tanto la QoS como la prioridad en condiciones normales de funcionamiento. Los algoritmos de derecho de uso preferente manejan las situaciones inesperadas que no se resuelven por el control de entrada.

De acuerdo con un aspecto de la presente invención allí se suministra un método para gestionar la calidad de servicio en una red IP que transmite los flujos de datos que tienen al menos dos niveles de prioridad, el método que comprende:

identificar, en un nodo de borde de salida de la red, que la congestión está presente en uno o más encaminadores dentro de la red;

seleccionar los flujos de datos para la terminación para eliminar la congestión;

enviar una notificación de terminación del flujo inicial desde el nodo de borde de salida a un nodo de borde de entrada de la red, la notificación de terminación del flujo inicial que identifica los flujos de datos seleccionados;

terminar los flujos de baja prioridad de los flujos de datos seleccionados en el nodo de borde de entrada cuando se recibe la notificación de terminación de flujo inicial;

en el nodo de borde de salida, después de los periodos de medición predeterminados, identificar si la congestión todavía está presente y, si lo está, seleccionar los flujos de datos adicionales para la terminación y enviar las notificaciones de terminación de flujo consecutivas al nodo de borde de entrada, las notificaciones de terminación de flujo adicionales que identifican los flujos de datos adicionales; y

terminar los flujos de alta prioridad a partir de los flujos de datos seleccionados en el nodo de borde de entrada solamente si:

al menos uno de los mensajes de notificación de terminación consecutivos se recibe por el nodo de borde de entrada después de que un ha transcurrido periodo de retardo predeterminado desde la recepción de la notificación de terminación del flujo inicial; y

el al menos un mensaje de notificación de terminación consecutivo recibido después del periodo de retardo predeterminado incluye los mismos flujos de alta prioridad en los flujos de datos adicionales seleccionados para la terminación.

De esta manera cuando se identifica inicialmente la congestión, los flujos de baja prioridad se terminan inmediatamente, pero hay un retardo antes de que los flujos de alta prioridad se terminen. Esto permite a los flujos de baja prioridad pasar a través de otros nodos de borde de salida que van a ser terminados, asegurando que los flujos de alta prioridad no se terminan a menos que no haya alternativa. Si la congestión todavía está presente después del retardo, entonces no hay opción sino iniciar también la terminación de los flujos de alta prioridad.

Si la solución de QoS se basa en un gestor de ancho de banda (BB), el retardo se puede introducir por el BB. El nodo de borde de salida preferentemente identifica que la congestión está presente en la red como resultado de que los encaminadores en la red que marcan las cabeceras de los paquetes de datos que pasan a través de allí con una bandera de congestión, para indicar que los paquetes han pasado a través de un encaminador congestionado. La(s) notificación(es) de terminación de flujos es(son) preferentemente un mensaje de protocolo QoS-NSLP.

Para asegurar que la red tiene suficientes recursos para los flujos de alta prioridad, el nodo de borde de entrada admite los flujos de baja prioridad en la red solamente si los recursos en la red están por encima de un umbral. Este umbral puede corresponder a un número dado de flujos de alta prioridad.

El umbral puede ser una cifra estática para el nodo de borde de entrada, pero se determina preferentemente dinámicamente en base de uno o más del número de reservas de recursos activas para los flujos de alta prioridad, el número de reservas de recursos activas para los flujos de baja prioridad, la tasa de las peticiones de recursos para los flujos de alta prioridad y la tasa de las peticiones de recursos para los flujos de baja prioridad. La tasa de las peticiones de recursos para los flujos de datos de alta prioridad es particularmente importante: si ésta aumenta, los recursos reservados para los flujos de alta prioridad (cuando se está tomando una decisión en cuanto a si se admiten los flujos de baja prioridad) se pueden incrementar. En una realización, el umbral se calcula como función lineal de la tasa de las peticiones de los recursos para flujos de alta prioridad.

Los flujos de alta prioridad entonces se pueden admitir en la red automáticamente, o al menos en base a una política única. Esto asegura que los flujos de alta prioridad introducen en la red un retardo tan pequeño como sea posible. Si la congestión ocurre, el proceso de derecho de uso preferente descrito anteriormente identificará la congestión, y los flujos de baja prioridad empezarán a ser terminados. Preferentemente el nodo de borde de entrada envía un mensaje de reserva a través de la red al nodo de borde de salida, el mensaje de reserva que contiene un objeto de reserva de recursos para reservar los recursos a lo largo del trayecto de datos y un objeto de disponibilidad de recursos para reunir la información sobre los recursos disponibles a lo largo del trayecto de datos. El nodo de borde de salida puede enviar una respuesta al nodo de borde de entrada, la respuesta que indica si la reserva de recursos fue exitosa e indicando los recursos disponibles a lo largo del trayecto de datos.

La invención también proporciona una red IP configurada para llevar a cabo cualquiera de los métodos descritos anteriormente.

De acuerdo con un aspecto adicional de la presente invención se proporciona allí un nodo de borde de entrada de una red IP, configurado para:

reservar los estados en la red;

enviar los flujos de datos en la red en base a los estados reservados, de manera que los flujos de baja prioridad se envían en la red solamente si los recursos disponibles en la red son mayores que un umbral que asegura suficientes recursos para un mínimo número de flujos de alta prioridad, el umbral determinado en base a al menos la tasa de reservas de recursos para los flujos de alta prioridad;

recibir una notificación de terminación del flujo inicial desde un nodo de borde de salida de la red, la notificación de terminación del flujo inicial que identifica los flujos de datos seleccionados para la terminación;

terminar los flujos de baja prioridad a partir de los flujos de datos seleccionados;

esperar durante un periodo de retardo determinado; y

terminar los flujos de alta prioridad a partir de los flujos de datos seleccionados solamente si se recibe una notificación de terminación de flujo consecutiva desde el nodo de borde de salida después del periodo de retardo predeterminado, la notificación de terminación de flujo consecutiva que incluye los flujos de datos adicionales seleccionados para la terminación que incluye los flujos de alta prioridad incluidos en la notificación de terminación inicial.

Breve Descripción de los Dibujos

La Figura 1 es una representación esquemática de los elementos de un dominio DiffServ IP que sufre la congestión;

La Figura 2 es una representación esquemática de un dominio DiffServ IP similar a aquél de la Figura 1;

La Figura 3 es una representación esquemática de un dominio DiffServ IP que ilustra un proceso de control de entrada; y

La Figura 4 es una representación esquemática de un dominio DiffServ IP que ilustra un proceso de control de congestión.

Descripción Detallada de las Realizaciones Preferentes

Un dominio DiffServ IP típico, tal como por ejemplo el mostrado en la Figura 1, comprende los nodos de borde de entrada y de borde de salida y los encaminadores de interior. El dominio DiffServ entrega flujos de datos de baja y alta prioridad. La prioridad es un descriptor del “nivel de la llamada”, que supone que la prioridad de “enviar” puede ser distinta que la prioridad de “entrada” o “derecho de uso preferente”. El tráfico de baja prioridad puede tener los mismos requerimientos de QoS de nivel de paquetes que el tráfico de alta prioridad. Un ejemplo de esto es el caso de las llamadas de voz. Una llamada de telefonía vocal normal tiene los mismos requerimientos de retardo/fluctuación, en el nivel de paquetes, que una llamada telefónica de emergencia. No obstante, cuando hay congestión, las llamadas de emergencia se deberían mantener en preferencia a las llamadas de telefonía de voz normal. Las cabeceras de paquetes incluyen un campo de clasificación, conocido como un Punto de Código de Servicio Diferenciado (DSCP), y es posible usar distintos DSCP para los flujos de alta y baja prioridad. Esto supone que se pueden asignar distintos PHB en DiffServ.

No obstante, si se usa el mismo DSCP para los flujos de alta y baja prioridad, los paquetes de ambas prioridades pueden funcionar bajo el mismo comportamiento de envío. Adicionalmente, el número de DSCP disponibles es limitado. Esto se relaciona con un problema general de DiffServ, que es que el espacio del punto de código disponible es muy limitado. Por lo tanto es deseable no distinguir entre los flujos de alta y baja prioridad usando distintos DSCP. En el sistema descrito más tarde, los flujos de alta y baja prioridad se distinguen en el nivel de llamada. En el nivel de paquete se comportan de la misma manera, es decir pueden usar el mismo DSCP.

Para asegurar la QoS y la asignación de prioridad correcta tanto bajo las condiciones normales como inesperadas, se puede usar un proceso de control de entrada y un proceso de derecho de uso preferente.

El proceso de control de entrada se usa antes de que se admita un flujo a la red. Cuando una petición llega para un nuevo flujo de baja prioridad a un nodo de borde de entrada de un dominio sin estado, el nodo de borde de entrada intenta reservar los recursos para ese flujo enviando un mensaje de reserva a través del dominio sin estado. Además de la reserva, se comprueba la disponibilidad de los recursos para las llamadas de alta prioridad. Los recursos disponibles se pueden reunir en el trayecto de datos usando el objeto AdSpec en RSVP o usando la QoS Disponible en QoS-NSLP. Las llamadas de baja prioridad se admiten solamente si los recursos disponibles son mayores que un valor umbral. El valor umbral es una función del número de llamadas de prioridad esperadas en el borde de entrada y la frecuencia de las nuevas peticiones de recursos. En este sentido el repentino aumento de peticiones de recursos se puede tener en cuenta cuando se admiten llamadas de baja prioridad. Dado que la disponibilidad de recursos de los recursos para los flujos de alta prioridad se comprueba cuando se admiten los flujos de baja prioridad, no es necesaria la reserva de recursos adicionales en el dominio sin estado para los flujos de alta prioridad. El control de entrada de los flujos de alta prioridad se puede basar en una decisión de política única en el borde de entrada. Esto asegura la rápida entrada de llamadas de prioridad, dado que no necesitan ser realizadas las reservas para los flujos de alta prioridad dentro de los dominios sin estado.

Este proceso se puede entender con relación a la Figura 3, que es una ilustración esquemática de un dominio IP DiffServ 300 que tiene dos nodos de borde de entrada 301, 302, dos nodos de borde de salida 303, 304, y tres encaminadores interiores 305, 306, 307. Antes de que se admita una llamada o flujo de datos al dominio DiffServ 300, llega una petición de señalización a un borde de entrada 301, que indica los recursos requeridos y la prioridad del flujo. El borde de entrada 301 comprueba la prioridad del flujo solicitado. Si es de alta prioridad, el flujo se admite. Se pueden aplicar políticas adicionales, tales como por ejemplo limitar los flujos de prioridad comprobando para ver si se han alcanzado un número máximo de flujos de prioridad admitidos, o una máxima cantidad de recursos reservados para los flujos de prioridad. Esto se puede hacer de una manera por nodo de entrada (modelo manguera) o de una manera por pareja entrada-salida (modelo troncal).

Si la petición pertenece a un flujo de baja prioridad, se envía un mensaje de señalización a través del dominio, solicitando los recursos dentro del dominio, y comprobando la disponibilidad de recursos adicionales dentro del dominio. El flujo de baja prioridad se admite si:

(1): la reserva dentro del dominio es exitosa, y

(2): los recursos disponibles son mayores que un valor umbral, designado por

A.

A puede ser una constante, configurada por el borde de entrada 301. Alternativamente puede ser una función del número de reservas de recursos activos y la frecuencia de las peticiones de recursos de los flujos de baja y alta prioridad, designados por nlow, rlow, nhigh, rhigh respectivamente.

A = F(nlow, rlow, nhigh, rhigh) Como un simple ejemplo, A puede ser una función lineal de la tasa de la frecuencia de peticiones de llamada de alta prioridad:

A = a+b* rhigh

Aquí a indica un recurso restringido reservado para los flujos de alta prioridad. El término b* rhigh permite un aumento significativo de los flujos que se pueden tener en cuenta. Por ejemplo, si el número de llamadas de emergencia aumenta considerablemente debido a una situación de emergencia, rhigh aumenta y se reservan más recursos por lo tanto para las llamadas de alta prioridad (el número de las cuales también se espera que aumente considerablemente).

Están disponibles dos opciones para comprobar los recursos disponibles y hacer una reserva del ancho de banda para los flujos de baja prioridad. En una opción, el umbral A se configura en el nodo de entrada 301. En la otra opción A se determina en cada nodo.

Si A es un parámetro por entrada (configurado en el borde de entrada 301), usando entonces el protocolo NSIS, se describen distintos procesos para las reservas de recursos en la Plantilla de QoS-NSLP y QSpec. Un proceso posible de reserva iniciado por el remitente es como sigue: El nodo del borde de entrada 301 envía, a un nodo del borde de salida 303, un mensaje RESERVA que incluye los objetos “QoS Deseada” y “QoS Disponible”. El “QoS Deseada” se usa para reservar los recursos requeridos a lo largo del trayecto. El “QoS Disponible” reúne los recursos disponibles. En respuesta, el nodo del borde de salida 303 envía un mensaje RESPUESTA, que indica si la reserva fue exitosa o no. También indica al nodo de borde de entrada 301 los recursos disponibles a lo largo del trayecto de datos. El nodo de borde de entrada 301 admite el flujo de baja prioridad solamente si los recursos disponibles son mayores que A. Si esta condición no se cumple, los recursos (que acaban de ser reservados) se eliminan.

En la otra opción, A se configura en cada salto. En este caso, como el mensaje de RESERVA viaja desde la entrada 301 a la salida 303, afronta una doble condición de entrada en cada salto. Cada nodo maneja la condición basada en la reserva normal, así como la comparación de la capacidad libre del enlace local con A. Si la reserva se completa y todos los enlaces locales tienen recursos suficientes comparado con su parámetro de recurso local, el flujo es admitido.

El proceso de control de entrada proporciona la QoS para los flujos admitidos bajo condiciones de funcionamiento normal. Para manejar las condiciones extremas, tales como un gran aumento de la tasa de llamadas, y/o fallos del enlace o nodo (que puede provocar una gran ráfaga inesperada de flujos de alta prioridad), se puede requerir también un algoritmo de derecho de uso preferente. El algoritmo de derecho de uso preferente se usa para terminar algunos flujos para mantener la QoS para los otros flujos. El algoritmo de derecho de uso preferente descrito asegura que los flujos de baja prioridad se terminan y los flujos de alta prioridad se preservan.

Se apreciará que, si no hay bastantes flujos de tráfico de baja prioridad que se puedan terminar, las llamadas de mayor prioridad se terminarán también. El algoritmo de derecho de uso preferente asegura que los flujos de alta prioridad se terminan solamente si no hay flujos de baja prioridad que puedan ser terminados. El algoritmo de derecho de uso preferente también es responsable de terminar las llamadas de baja prioridad en caso de congestión grave después de reencaminar, por ejemplo debido al fallo del enlace o del nodo.

En condiciones inesperadas, el tráfico puede ser mayor que la capacidad de los encaminadores, o enlaces. Un ejemplo se muestra en la Figura 4, el cual ilustra el dominio 300 mostrado en la Figura 3. En la situación mostrada en la Figura 4, un enlace 408 en un trayecto de datos falla entre los encaminadores interiores 307, 308.

Después de detectar el fallo del enlace, el protocolo de encaminamiento reencamina el tráfico a un trayecto de datos alternativo a través de los enlaces 409, 410 y los encaminadores 305, 306. En esta situación no hay control de entrada antes de reencaminar, de manera que puede ocurrir que el tráfico sea mayor que la capacidad de uno o más de los encaminadores 305, 306 o los enlaces 409, 410 en el nuevo trayecto. El encaminador congestionado 305 tira los paquetes que no pueden ser manejados.

La RMD define una función de manejo de la congestión grave para prevenir que los paquetes simplemente se tiren. En la RMD, cada encaminador 305, 306, 307 mide periódicamente el número de bytes tirados, y vuelve a marcar los paquetes que pasan al encaminador o encaminadores congestionados. Los paquetes se marcan en el campo del DSCP. El número de bytes vueltos a marcar indica el tráfico en exceso. El funcionamiento de los encaminadores interiores es casi idéntico a aquél descrito en el borrador del IETF [A. Bader, y otros, “RMD-QOSM: Un Modelo de Política de Señalización QoS NSIS para Redes que Usan la Gestión de Recursos en DiffServ (RMD),” trabajo en curso] y en la WO 2006/052174.

Los nodos de borde de salida 303, 304 tienen una función dedicada para manejar la congestión grave dentro del dominio. Cada nodo de borde de salida 303, 304 monitoriza si hay paquetes vueltos a marcar y, si los paquetes vueltos a marcar se detectan, periódicamente mide el número de bytes marcados. También identifica los flujos afectados y determina cuántos, y qué, flujos se deberían terminar para aliviar la congestión. Los flujos que van a ser terminados se seleccionan de acuerdo con su prioridad. Los flujos de menor prioridad se seleccionan primero. Si no hay bastantes flujos de baja prioridad que se puedan terminar, se seleccionan también los flujos de mayor prioridad. Los nodos de borde de salida 304, 305 envían un mensaje de notificación 411, para cada flujo seleccionado, para el correspondiente nodo de borde de entrada 301 (en el cual se origina el flujo), para terminar los flujos seleccionados.

Cuando se recibe este mensaje de notificación 411, el nodo de borde de entrada 301 comprueba la prioridad del flujo correspondiente, y desde qué nodo de borde de salida 303 ha llegado el mensaje de terminación. Si la prioridad es baja, el flujo se termina inmediatamente.

Si el mensaje de notificación corresponde a un flujo de alta prioridad, el flujo no se termina inmediatamente. En su lugar, la decisión en cuanto a si el flujo se debería terminar se suspende durante un periodo de tiempo Tdelay que es típicamente de 2-3 periodos de medición de duración. Los flujos de alta prioridad seleccionados se terminan solamente si los mensajes de terminación desde el mismo Borde de Salida aún están siendo recibidos después de Tdelay. Si no hay mensajes de notificación adicionales para los flujos de alta prioridad, los flujos de alta prioridad seleccionados no se terminan. Este algoritmo asegura que, si todavía hay flujos de baja prioridad pasando el nodo congestionado 305 pero dejando el dominio 300 a través de distintos nodos de borde de salida 304, estos flujos de baja prioridad se terminarán en lugar de los flujos de alta prioridad. La terminación de los flujos de alta prioridad se evita por lo tanto.

El algoritmo se puede refinar además si se conoce el régimen binario de los flujos seleccionados para la terminación en el nodo de borde de entrada 301 (por ejemplo mediante medición, o a partir del tipo de tráfico). En este caso el nodo de borde de entrada 301 puede monitorizar la cantidad del tráfico de los flujos de alta prioridad seleccionados y, después del tiempo de retardo, terminar solamente aquellos flujos que corresponden a la sobrecarga real.

En una realización alternativa, el retardo se puede introducir y monitorizar mediante un Gestor de Ancho de Banda (BB) que da instrucciones al nodo de borde de entrada de si el flujo debería ser terminado o no dependiendo de su prioridad.

En una realización alternativa, los nodos de borde de salida 303, 304 retienen los mensajes de notificación de terminación 411 para los flujos de alta prioridad cuando reciben primero los paquetes marcados que indican la congestión. Los mensajes de notificación de terminación 411 para los flujos de alta prioridad se envían solamente si los paquetes marcados que indican los flujos de alta prioridad congestionados aún se están recibiendo después del intervalo de tiempo de retardo Tdelay. En esta realización el nodo de borde de entrada 301 se comporta de la misma manera para flujos de alta y baja prioridad: se terminan inmediatamente después de que se recibe el mensaje de notificación 411.

El algoritmo de derecho de uso preferente también es responsable de mantener la QoS para el tráfico de alta prioridad cuando los recursos para los flujos de alta prioridad requeridos en el nodo de borde de entrada 301 es mayor que A. En este caso, el proceso de control de entrada aún admite los flujos de alta prioridad automáticamente (a menos que se evite por otra política). Si éste conduce a la congestión entonces los flujos de baja prioridad en el mismo trayecto de datos se terminarán por el algoritmo de derecho de uso preferente, como se acaba de describir.

El proceso descrito maneja dinámicamente de esta manera el tráfico de baja prioridad y de alta prioridad. El proceso de control de entrada asegura que habrá recursos para los flujos de alta prioridad, y para los flujos de baja prioridad si son admitidos. No obstante, no hay necesidad de reservar ancho de banda para los flujos de alta prioridad. Los recursos se usan por lo tanto más eficientemente.

La admisión de flujos de alta prioridad es rápida, dado que no hay reserva de 5 recursos dentro del dominio DiffServ para estos flujos.

Los procesos de control de entrada y de derechos de uso preferentes juntos proporcionan un soporte de QoS robusto. Los cambios lentos en la red se manejan por el control de entrada. Cuando los volúmenes de tráfico cambian rápidamente, el algoritmo de derechos de uso preferentes puede reaccionar a los cambios y restaurar

10 la QoS para la mayoría o todas las llamadas que implican flujos de alta prioridad. De esta manera los procesos descritos pueden manejar eficientemente grandes aumentos de peticiones de reserva para flujos de alta prioridad. Los procesos se basan en estados por clase, de manera que son aplicables con protocolos sin estado tales como la RMD. Incluso sin estados por flujo, los procesos descritos

15 resuelven la congestión grave debida al reencaminamiento. El control de entrada es más eficiente en ancho de banda. La terminación del tráfico de menor prioridad en lugar del tráfico de alta prioridad se puede evitar en ciertas situaciones.

Se apreciará que las variaciones a partir de las realizaciones descritas anteriormente pueden caer dentro del alcance de la invención según se revela en las 20 reivindicaciones adjuntas.

Claims

1. Un método de gestionar la calidad de servicio en una red IP que transmite flujos de datos que tienen al menos dos niveles de prioridad, el método que comprende:

identificar, en un nodo de borde de salida (303, 304) de la red, que la congestión está presente en uno o más encaminadores (306) dentro de la red;

enviar una notificación de terminación del flujo inicial desde el nodo de borde de salida a un nodo de borde de entrada (301, 302) de la red, la notificación de terminación del flujo inicial que identifica los flujos de datos seleccionados; y

terminar los flujos de baja prioridad a partir de los flujos de datos seleccionados en el nodo de borde de entrada cuando la notificación de terminación del flujo inicial se recibe; y caracterizado por:

en el nodo de borde de salida, después de los periodos de medición predeterminados, identificar si la congestión todavía está presente y, si lo está, seleccionar los flujos de datos adicionales para la terminación y enviar las notificaciones de terminación de flujo consecutivo al nodo de borde de entrada, las notificaciones de terminación de flujo adicionales que identifican los flujos de datos adicionales; y

al menos uno de los mensajes de notificación de terminación consecutivos se recibe por el nodo de borde de entrada después de que ha transcurrido un periodo de retardo predeterminado desde la recepción de la notificación de terminación del flujo inicial; y

2.: El método de la reivindicación 1, en donde se conoce el régimen binario de los flujos de alta prioridad seleccionados por el nodo de borde de entrada (301), y no se termina ningún flujo de alta prioridad más que los requeridos para reducir la congestión.

3.: El método de la reivindicación 1, en donde se introduce el periodo de retardo predeterminado por un gestor de ancho de banda.

4.: El método de la reivindicación 3, en donde el gestor de ancho de banda da instrucciones al nodo de borde de entrada para terminar los flujos de baja prioridad a partir de los flujos de datos seleccionados cuando se recibe la notificación de terminación inicial, y para terminar los flujos de alta prioridad a partir de los flujos de datos seleccionados se terminan solamente si:

al menos uno de los mensajes de notificación de terminación consecutivos se reciben por el nodo de borde de entrada después del periodo de retardo predeterminado; y

5.: El método de cualquiera de las reivindicaciones precedentes, en donde el uno o más encaminadores (306) marcan las cabeceras de los paquetes de datos que pasan a través del uno o más encaminadores con una bandera de congestión para indicar que tales paquetes han pasado a través de un encaminador congestionado.

6.: El método de cualquiera de las reivindicaciones precedentes, en donde la notificación de terminación del flujo es un mensaje de protocolo QoS-NSLP.

7.: El método de cualquiera de las reivindicaciones precedentes, en donde, si el nodo de borde de entrada (301) recibe una petición para un flujo de datos de baja prioridad, el flujo de datos de baja prioridad se admite en la red solamente si los recursos disponibles en la red son mayores que un umbral.

8.: El método de las reivindicación 7, en donde el umbral se determina para asegurar que están disponibles los recursos suficientes para un número dado de flujos de alta prioridad.

9.: El método de la reivindicación 7 u 8, en donde el umbral se determina en base a uno o más del número de reservas de recursos activas para los flujos de alta prioridad, el número de reservas de recursos activas para los flujos de baja prioridad, la tasa de peticiones de recursos para los flujos de alta prioridad y la tasa de peticiones de recursos para los flujos de baja prioridad.

10.: El método de la reivindicación 9, en donde el umbral es una función lineal de la tasa de peticiones de recursos para los flujos de alta prioridad.

11.: El método de cualquiera de las reivindicaciones 7 a 10, en donde el flujo de datos de baja prioridad solamente se admite en la red si se reserva un trayecto de datos a través de la red.

12.: El método de la reivindicación 11, en donde, cuando el nodo de borde de entrada (301) recibe la petición para el flujo de datos de baja prioridad, se envía un mensaje de reserva al nodo de borde de salida (303), el mensaje de reserva que contiene un objeto de reserva de recursos para reservar los recursos a lo largo del trayecto de datos y un objeto de disponibilidad de recursos para reunir información sobre los recursos disponibles a lo largo del trayecto de datos.

13. El método de la reivindicación 12, en donde el nodo de borde de salida

(303) responde a la recepción del mensaje de reserva enviando una respuesta al nodo de borde de entrada (301), la respuesta que indica si la reserva de recursos fue exitosa y que indica los recursos disponibles a lo largo del trayecto de datos.

14.: El método de cualquiera de las reivindicaciones 7 a 13, en donde, si el nodo de borde de entrada (301) recibe una petición para un flujo de datos de alta prioridad, el flujo de datos de alta prioridad se admite en la red en base a una decisión de política única.

15.: El método de cualquiera de las reivindicaciones 7 a 13, en donde, si el nodo de borde de entrada (301) recibe una petición para un flujo de datos de alta prioridad, el flujo de datos de alta prioridad se admite en la red automáticamente.

16.: El método de cualquiera de las precedentes reivindicaciones, en donde la red IP se construye usando la Arquitectura de Servicios Diferenciados.

17.: Una red IP configurada para llevar a cabo el método de cualquier reivindicación precedente.

18. Un nodo de borde de entrada (301) de una red IP, configurada para: reservar estados en la red; enviar flujos de datos en la red en base a los estados reservados, tal que los

flujos de baja prioridad se envían en la red solamente si los recursos disponibles en la red son mayores que un umbral que asegura los recursos suficientes para un mínimo número de flujos de alta prioridad, el umbral determinado en base a al menos la tasa de reservas de recursos para los flujos de alta prioridad;

recibir una notificación de terminación de flujo inicial desde un nodo de borde de salida (303, 304) de la red, la notificación de terminación del flujo inicial que identifica los flujos de datos seleccionados para la terminación; y

terminar los flujos de baja prioridad a partir de los flujos de datos seleccionados; esperar durante un periodo de retardo predeterminado; y

terminar los flujos de alta prioridad a partir de los flujos de datos seleccionados solamente si se recibe una notificación de terminación de flujo consecutiva desde el nodo de borde de salida después del periodo de retardo predeterminado, la notificación de terminación de flujo consecutiva que incluye flujos de datos adicionales

5 seleccionados para la terminación que incluye los flujos de alta prioridad incluidos en la notificación de la terminación inicial.

19. El nodo de borde de entrada (301) de la reivindicación 18, dispuesto de manera que, si el nodo de borde de entrada recibe una petición para un flujo de datos de alta prioridad, el flujo de datos de alta prioridad es admitido en la red en base a una

10 decisión de política única.