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

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...

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;

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.

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

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.

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 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.