ES2217150T3 - Procedimiento de optimizacion de una red. - Google Patents

Abstract

Método en una red de comunicaciones a base de paquetes incluyendo dominios de red, donde al menos un dominio es un dominio de Conmutación de Etiquetas Multiprotocolo MPLS, para establecer una línea arrendada virtual, VLL, entre un origen (SRC) y un destino (DST) en diferentes dominios con el fin de lograr transferencia de paquetes entre el origen y el destino, donde un broker de anchura de banda (BB) está asociado a cada dominio de red y el broker de anchura de red (BB) está adaptado para controlar un dominio de enrutamiento jerárquico, el método incluye los pasos siguientes: i) generar una petición a una entidad de una Línea Arrendada Virtual, VLL, que tiene una Calidad de Servicio predefinida, QoS, desde una red origen (SRC) a una red destino (DST) y aplicar la petición a un Broker de Anchura de Banda (BB) de un dominio A, BBA, asociado a la red origen; ii) BBA establece los diferentes dominios implicados para llegar a la red destino (DST); iii) BBA pasa directa o indirectamente peticiones a todos los Brokers de Anchura de Banda (BB) de los dominios implicados con respecto a una VLL de la QoS predefinida desde la entrada a la salida de cada dominio; iv) cada broker de anchura de banda (BB) implicado realiza control de admisión en su dominio; v) cada broker de anchura de banda (BB) implicado devuelve un resultado del control de admisión a BBA que lo pasa de nuevo a la entidad solicitante, y si la petición se admitió a lo largo de todos dominios entre el origen (SRC) y el destino (DST), se concede una VLL de la QoS predefinida.

Description

Procedimiento de optimización de una red.

Campo de la invención

La presente invención se refiere a un método en una red de comunicaciones a base de paquetes incluyendo dominios de red para establecer una línea arrendada virtual (VLL) entre un origen (SRC) y un destino (DST) en diferentes dominios con el fin de lograr transferencia de paquetes entre el origen y el destino.

Antecedentes de la invención

Dentro de la comunidad de Internet hay varias iniciativas para mejorar diferentes aspectos de Internet. Algunos de los problemas principales son: (1) ampliar el modelo de servicio, (2) la eficiencia y escalabilidad del enrutamiento y envío, y (3) operaciones y gestión.

Todo esto es importante para el crecimiento continuado y el éxito de Internet.

La presente solicitud se refiere a una combinación de dos tecnologías emergentes, Conmutación de Etiquetas MultiProtocolo (MPLS) y Brokers de Anchura de Banda (BB), que tienen gran potencial en el contexto de los tres problemas indicados. El enfoque principal de la presente invención está en la implementación de un servicio garantizado de anchura de banda llamado Línea Arrendada Virtual, o VLL.

La sección siguiente describe brevemente las dos tecnologías MPLS y BB. MPLS está experimentando estandarización en el Internet Engineering Task Force (IETF) mientras que actualmente no hay ningún esfuerzo formal por estandarizar Brokers de Anchura de Banda.

El grupo de trabajo de MPLS del IETF se puso en marcha allá por 1997 en respuesta a la tendencia a la conmutación de etiquetas entre vendedores de enrutadores. En aquel tiempo, existían varias implementaciones propietarias y se identificó la necesidad de estandarización.

MPLS es un método que integra el paradigma de envío de conmutación de etiquetas con enrutamiento de capa de red. En MPLS, se facilita conmutación orientada a conexión en base a protocolos de enrutamiento y control IP.

En resumen, MPLS opera como sigue:

\text{*}

Asociar etiquetas con corrientes específicas de clases de equivalencia de envío(FECs).

\text{*}

Distribuir las etiquetas y sus uniones FEC a través de la red, el dominio MPLS, para establecer un Trayecto Conmutado de Etiquetas (LSP).

\text{*}

Asignar a paquetes una o varias etiquetas (una pila de etiquetas) al entrar en el dominio.

\text{*}

Enviar paquetes a través del dominio en base a las etiquetas.

Los componentes centrales de MPLS son la semántica de etiquetas, los métodos de envío y los métodos de distribución de etiquetas.

La característica de enrutamiento explícito de la conmutación de etiquetas multiprotocolo (MPLS) se introdujo para afrontar los inconvenientes asociados con los esquemas de enrutamiento IP corrientes, que se ven obstaculizados por el requisito de enviar paquetes en base solamente a las direcciones de destino a lo largo de los trayectos más cortos calculados usando métrica de enlace en su mayor parte estática e independiente de la característica del tráfico. Aunque este enrutamiento de trayectos más cortos es suficiente para lograr conectividad, no siempre utiliza bien los recursos de red disponibles y no es satisfactorio desde el punto de vista de la ingeniería del tráfico. Un problema primordial es que algunos enlaces en el trayecto más corto entre algunos pares de entrada-salida pueden estar congestionados, mientras que algunos enlaces en posibles trayectos alternativos permanecen libres. Incluso en el modelo del mejor esfuerzo, esto significa que los recursos de red disponibles no se están utilizando bien, dando lugar a retardos más grandes, y es posible dar una mejor calidad de servicio (QoS) con la misma infraestructura de red.

En redes MPLS, cuando se establecen trayectos conmutados de etiquetas de anchura de banda garantizada (LSPs), el enrutamiento de trayectos más cortos con métrica de enlace fija puede hacer que se rechacen peticiones de establecimiento de LSP, aunque estas peticiones pueden haber sido admisibles utilizando un esquema de enrutamiento diferente. Por lo tanto, se necesitan esquemas de enrutamiento que pueden utilizar mejor la infraestructura de la red. Este mejor uso de la infraestructura de la red, a la vez que mantiene las garantías de QoS, es el objetivo primario de la ingeniería del tráfico. La capacidad de la red MPLS de controlar el trayecto desde el nodo de entrada al nodo de salida para optimizar la utilización de los recursos de red y mejorar el rendimiento se considera como una justificación primaria del uso de MPLS.

En MPLS los paquetes son encapsulados, en los puntos de entrada, con etiquetas que después se utilizan para enviar los paquetes a lo largo de LSPs. Los proveedores de servicio pueden utilizar LSPs de anchura de banda garantizada como componentes de un servicio de red privada virtual (VPN) IP utilizando las garantías de anchura de banda para satisfacer los contratos de nivel de servicio al cliente (SLAs). Estos LSPs se pueden considerar como líneas de tráfico virtual que transportan agregados de flujo generados clasificando en clases de equivalencia de envío (FECs) los paquetes que llegan a los enrutadores de borde o entrada de una red MPLS. La clasificación en FECs se realiza usando filtros de paquete que examinan campos de cabecera, tales como la dirección de origen, la dirección de destino, y los bits de tipo de servicio. Las reglas de filtro que determinan los FECs se pueden establecer de varias formas, tal como descarga de un servidor de política o router, o interacción con protocolos de enrutamiento. La finalidad de clasificar paquetes en FECs es permitir que el proveedor de servicios dirija el tráfico de la red y enrute cada FEC de manera especificada. Esto se realiza aplicando paquetes de llegada pertenecientes a un FEC a uno de los LSPs asociados con el FEC. Antes de aplicar paquetes a un LSP, el LSP se establece, a lo largo de una ruta explícita si está especificada, usando un protocolo de señalización que permite reserva de recurso, tal como el Protocolo de Establecimiento de Reserva de Recursos (RSVP).

La eficiencia en términos de costes de las redes IP se logra parcialmente mediante el modelo de tráfico sin conexión que da lugar a una eficiente compartición de recursos. Sin embargo, este modelo no permite garantías de calidad, sin funcionalidad adicional para diferenciación de servicio en dispositivos de red. En los últimos años tal funcionalidad ha llegado a ser común, y con ella las configuraciones estáticas de Calidad de Servicio (QoS). Introduciendo un Broker de Anchura de Banda (BB) en la red, la gestión de la política de QoS se puede manejar de forma más flexible.

Un broker de anchura de banda es una entidad en un dominio de red que gestiona políticas de los recursos de anchura de banda. Mantener una base de datos de los recursos de dominio proporciona decisiones de control de admisión sobre peticiones de servicio QoS. También es responsable de configurar la red para cumplir las políticas otorgadas. Puede ser capaz de comunicar con brokers de anchura de banda en dominios contiguos, permitiendo que los servicios QoS abarquen varios dominios.

En WO-00/30295 se describe un método para proporcionar control de admisión y Calidad de Servicio (QoS) de red.

En la sección de antecedentes de la solicitud WO se discuten los inconvenientes de las técnicas de la técnica anterior centrándose, entre otros, en las cuestiones de escalabilidad que conducen al desarrollo de la arquitectura de Servicios Diferenciados (DiffServ). DiffServ permite proporcionar niveles distintos de servicio de red a tráfico diferente. Sin embargo, en vez de almacenar información de estado por flujo en cada nodo intermedio en la red entre el emisor y el (los) receptor(es), los enrutadores dentro de una red DiffServ manejen paquetes en diferentes flujos de tráfico aplicando diferentes comportamientos por salto (PHBs) en base al establecimiento de bits en el campo TOS de cada cabecera IP del paquete. De esta manera, se puede agregar muchos flujos de tráfico en un PHB de un pequeño número de PHBs predefinidos, permitiendo por ello una reducción de la cantidad de procesado y almacenamiento asociados con la clasificación y el envío de paquetes. Aunque resuelve los problemas de escalabilidad, DiffServ no proporciona una guía adecuada con respecto a implementación de una política de control de admisión.

Un método de llevar a cabo control de admisión sugerido por la estructura DiffServ implica usar un broker de anchura de banda centralizado. El broker de anchura de banda centralizado tiene control sobre todo el dominio y maneja de forma central las peticiones de asignación de anchura de banda. El ejemplo siguiente describe brevemente el trabajo realizado por un broker de anchura de banda.

Un emisor que desea establecer un nivel particular de servicio para un flujo de datos entre él y un receptor transmite una indicación de sus requisitos a un broker de anchura de banda centralizado. El broker de anchura de banda centralizado valida la petición contra políticas, compara la petición con la asignación corriente de anchura de banda para tráfico aceptado, y configura los dispositivos de borde con información necesaria para marcar y conformar (o supervisar) paquetes entrantes del flujo.

A continuación, cuando los paquetes que son parte del flujo de datos establecido atraviesan la nube de la red DiffServ, dispositivos centrales intermedios aplican un PHB que corresponde al nivel de servicio DiffServ indicado en la cabecera de paquete.

En WO-00/30295 el objeto es lograr una red que gestione los inconvenientes de usar un broker centralizado, por ejemplo, un broker centralizado útil puede ser muy complejo y tiene capacidad limitada de gestionar las peticiones de anchura de banda para sesiones de destinatarios múltiples.

A continuación se describe el estado corriente de la técnica al utilizar MPLS solo y una combinación de Brokers de Anchura de Banda y MPLS. El enfoque principal de esta sección es extender el modelo de servicio (es decir, implementar QoS).

Las normas MPLS cubren mecanismos y protocolos que proporcionan las herramientas básicas para redes MPLS. Dadas las normas corrientes y el equipo disponible, muchas redes MPLs se enrutan manualmente. En tal red, las ventajas principales de usar MPLS son sobreenrutamiento por fallo rápido y una clara separación de enrutamiento entre e intra dominios. Estas propiedades de MPLS no se cualifican realmente como habilitadores de QoS, pero son buenos ejemplos de cómo se utiliza MPLS. Otra aplicación común de MPLS es para establecimiento de VPN por herramientas administrativas (por ejemplo, Orchestream). En estas aplicaciones la principal ventaja es que la red compartida se divide en VPNs privados usando los MPLS LSPs.

Hay un sistema denominado Routing and Traffic Engineering Server (RATES) que se describe como un servidor de ingeniería de tráfico MPLS. El sistema lo describen Aukia, Kodialam, Koppol, Lakshman, Sarin y Suter en: "RATES: A server for MPLS Traffic Engineering", IEEE Network Magazine, mayo 2000. A continuación se denomina [RATES]. El modelo bajo el que opera RATES es que las peticiones de servicio se pasan a un motor que las evalúa e implementa posiblemente el servicio en la red. Una petición de servicio se define por direcciones de origen y destino (o prefijos) y una restricción de anchura de banda. [RATES] define un algoritmo de enrutamiento, que intenta hallar un trayecto que puede acomodar las peticiones. Esto está en contraposición con otros sistemas, que meramente usan las rutas que se puede adquirir del enrutamiento de tres capas (normalmente trayectos más cortos).

Un sistema del Broker de Anchura de Banda (BB_{OLOV}) del estado corriente de la técnica se describe en Olov Schelen, Quality of Service Agents in the Internet, Tesis doctoral, Department of Computer Science and Electrical Engineering, Division of Computer Communication, Lulea University of Technology, Lulea, 1998. A continuación se denomina [OLOV].

BB_{OLOV} tiene muchas semejanzas con RATES. El BB_{OLOV} se describe en el contexto de redes DiffServ mientras que RATES opera en MPLS. Aparte de esa diferencia básica, estos dos sistemas operan bajo el mismo modelo; reciben peticiones de servicio, las evalúan e implementan posiblemente el servicio. Esto se ilustra esquemáticamente en la figura 1. La principal diferencia entre estos dos sistemas es la tecnología de red subyacente.

Una propiedad importante de RATES y BB_{OLOV} es la implementación de control de admisión sensible a trayecto. Ambos sistemas garantizan que todos los enlaces en un trayecto tengan suficientes recursos de envío para mantener el ritmo de la petición de servicio. El control de admisión sensible a trayecto (por una entidad centralizada) requiere conocimiento detallado de la topología de red, o más bien, la topología de enrutamiento. Tanto RATES como BB_{OLOV} usan el método directo de par como un router de estado de enlace, que proporciona una vista dinámica y detallada de la topología de enrutamiento.

Los enrutadores en un dominio de estado de enlace sincronizan continuamente la información de topología entre sí. Todos los enrutadores tienen toda la información necesaria para crear una vista completa de la topología de dominio. Los cambios en una parte de la red se difunden a través de todo el dominio, garantizando que todos los enrutadores tengan información actualizada. Hacer de par como un enrutador de estado de enlace significa simplemente que un host toma parte en el intercambio de información para recibir toda la información dinámicamente. Esto se puede hacer pasivamente, lo que significa que el host no publica ninguna información por sí mismo.

Cada caso RATES se limita a un dominio de estado de enlace plano (por ejemplo, un área Abrir Trayecto Más Corto Primero (OSPF)), mientras que se supone que BB_{OLOV} controla un dominio de enrutamiento completo, que puede utilizar enrutamiento jerárquico. En el caso de enrutamiento jerárquico, BB_{OLOV} se basa en sondas de enrutamiento, que hacen de pares de enrutamiento dentro de dominios de estado de enlace plano para recoger información de enrutamiento.

Utilizando sistemas como estos, que usan los conceptos MPLS y BB en combinación, es posible lograr establecimiento y desmontaje dinámico del servicio QoS en redes DiffServ o MPLS.

El estado de la técnica en MPLS y la combinación de servidores de ingeniería de tráfico MPLS y brokers de anchura de banda tienen algunos inconvenientes, que se explican brevemente a continuación.

Un objeto general de la presente invención se centra en la implementación de un servicio VLL con garantías de anchura de banda, que requiere control de admisión sensible a trayecto. Para que el servicio sea lo más útil que sea posible es importante que el control de servicio sea dinámico y se gestione automáticamente. Las cuestiones de servicio centrales son:

\text{*} Servicios de extremo a extremo.

\text{*} Planificación de recursos en el tiempo.

La cuestión de extremo a extremo es de gran importancia cuando las peticiones de servicio abarcan múltiples dominios de proveedor de red y posiblemente una mezcla de redes DiffServ y MPLS. Es improbable que un servicio que solamente está disponible dentro de un dominio de proveedor tenga éxito en un mundo donde los servicios globales de todos los tipos sean cada vez más importantes.

Planificar recursos en el tiempo es una cuestión importante si los servicios garantizado de anchura de banda en redes por lo demás compartidas ha de ser una alternativa creíble a las soluciones más rígidas, tal como líneas arrendadas o redes de conmutación de circuitos. Los usuarios comerciales requerirán la capacidad de planificar por adelantado lo que se refiere a QoS. Es muy probable que un negocio cuyas aplicaciones críticas de envío fallan debido a no disponibilidad de QoS de red, abandone al proveedor causante del fallo.

Durante el desarrollo del modelo de Broker de Anchura de Banda, el enfoque inicial eran los servicios de extremo a extremo. Un Broker de Anchura de Banda es responsable de los recursos de anchura de banda dentro de su dominio y puede comerciar con la anchura de banda con brokers en dominios contiguos. Estas ideas no acoplan bien con la forma en que se lleva a cabo el control de admisión. Sin embargo, para implementar servicios como la VLL de anchura de banda garantizado, se requiere un método de control de admisión muy específico. El servicio de ingeniería de tráfico MPLS del estado de la técnica antes mencionado, RATES, cubre solamente una zona de estado de enlace que, de hecho, solamente es una parte pequeña de un dominio de proveedor. Esto significa que se necesitan varios sistemas RATES para cubrir un dominio único.

El Broker de Anchura de Banda BB_{OLOV} en la tesis de Olov Schelen identificada anteriormente define un método, que permite planificar un servicio VLL en el tiempo. El control de admisión, que es el centro de la implementación del servicio, se lleva a cabo con el tiempo como un parámetro de entrada.

El sistema [RATES] no considera el tiempo. El control de admisión de peticiones de servicio se realiza al tiempo en que se hace la petición. La incapacidad de planificar en el tiempo requiere un compromiso en la utilización de la red frente a valores del cliente. Por ejemplo, si un cliente confía en la disponibilidad de recursos de anchura de banda para un evento comercial en el plazo de una semana a partir de ahora, necesita hacer la petición tan pronto como sea posible para estar seguro de que su petición será admitida. A la espera del evento, el cliente estará pagando un servicio que no utiliza.

Para redes MPLS, no se conoce actualmente ninguna solución a este problema.

En Schelen O. y colaboradores, "Performance of QoS agents for provisioning network resources", Quality of Service, 1999, IWQOS '99, 1999 Seventh international workshop on London UK 31 May-4 June 1999, Piscataway, NJ, USA, IEEE, US, 31 May 1999, páginas 17-26, ISBN: 0-7803-5671-3, se describe un método para proporcionar reservas de recursos para VLLs entre dominios de red. Las reservas se pueden programar en el tiempo y cada trayecto reservado puede tener una QoS predeterminada. Un agente de QoS (o Broker de Anchura de Banda) realiza control de admisión en su dominio. Sin embargo, este documento no describe un método para realizar reservas de recursos en una red que tenga dominios MPLS heterogéneos.

Así, un primer objeto de la presente invención es lograr un método que implemente servicios de extremo a extremo (del tipo VLL) a través de un conjunto de dominios MPLS heterogéneos.

Un segundo objeto de la presente invención es lograr un método que implemente una planificación de recursos de un servicio VLL en el tiempo.

Resumen de la invención

Los objetos antes indicados se logran con un método según la reivindicación independiente.

Se exponen realizaciones preferidas en las reivindicaciones dependientes.

La presente invención se refiere a un método que utiliza una combinación novedosa de las ideas de [OLOV] y [RATES] que proporciona una solución a ambos problemas relacionados con los objetos primero y segundo indicados anteriormente.

Se han realizado muchos esfuerzos en el área de QoS para redes DiffServ y MPLS. La mayor parte de ellos tratan de mecanismos o algoritmos en el plano de envío. Para lograr servicios gestionables bien definidos se requieren componentes como control de admisión. Esta invención utiliza un concepto de control de admisión para lograr servicios a través de bordes de dominio.

Los méritos clave de la invención son:

\text{*}

Despliegue. Los operadores de redes de todo el mundo están usando diferentes soluciones para sus redes. Para cualquier tipo de servicio global, el soporte para tecnologías de redes heterogéneas es muy importante. Esta invención hace posible desplegar servicios VLL de extremo a extremo de anchura de banda garantizada a través de dos de los modelos QoS más frecuentemente utilizados.

\text{*}

Utilización de red. El uso de control de admisión con anterioridad permite utilizar más eficientemente los recursos de red [OLOV]. Esta invención hace uso previamente desconocido de esta potente herramienta en redes MPLS.

Breve descripción de los dibujos anexos

La figura 1 es una ilustración esquemática de un modelo de servicio en DiffServ o MPLS.

La figura 2 muestra bloques funcionales que ilustran esquemáticamente la presente invención.

La figura 3 muestra la arquitectura general según la presente invención.

La figura 4 proporciona un escenario ejemplar donde se prepara una VLL que abarca dos dominios usando el método según la presente invención.

La figura 5 muestra un diagrama de flujo que describe cómo maneja peticiones un broker de anchura de banda según la presente invención.

La figura 6 muestra bloques funcionales de un broker de anchura de banda según la presente invención.

Descripción detallada de realizaciones preferidas de la invención

La figura 2 muestra bloques funcionales que ilustran esquemáticamente la presente invención.

Obsérvese que la parte de enrutamiento de [RATES] se excluye y que el método según la presente invención se basa totalmente en el enrutamiento existente y no calcula rutas activamente.

La funcionalidad de la presente invención se describe esquemáticamente más adelante con referencia a figura 2:

\text{*}

Gestión de peticiones. Esta interfaz maneja todas las peticiones entrantes. Las peticiones son realizadas por clientes al sistema (dentro del dominio del sistema) o sistemas entre pares en otros dominios. Esta funcionalidad de esta interfaz puede ser la de [RATES] o [OLOV] o ambas.

\text{*}

Control de admisión. Este bloque se implementa, por ejemplo, como se describe en [OLOV], para lograr sensibilidad al trayecto y la capacidad de planificar con anterioridad. Se utiliza la misma funcionalidad para MPLS y DiffServ. Los componentes clave de este bloque son:

\circ

Información de topología, que se utiliza para calcular trayectos para las peticiones (sensibilidad al trayecto).

\circ

Una estructura de datos que mantiene información sobre uso de recursos en el tiempo para cada enlace en la topología (capacidad de planificar con anterioridad).

\text{*}

Implementación de servicio. Aquí es donde se mezcla la funcionalidad de [RATES] y [OLOV] para lograr servicios a través de dominios heterogéneos. Para redes MPLS se utiliza el mecanismo de establecimiento de LSP utilizado en [RATES]. Esto incluye establecer asociaciones FEC en dispositivos de borde MPLS y distribuir etiquetas para establecimiento de LSP en los dispositivos centrales MPLS. Para redes DiffServ todo lo que se requiere es configuración de los denominados Acondicionadores de Tráfico (TC) que están dispuestos en los enrutadores. El acondicionamiento de tráfico puede implicar cualquiera de las funciones de clasificar, dosificar, marcar, conformar y dejar caer paquetes. Los dispositivos de borde DiffServ realizan típicamente acondicionamiento de tráfico para asociar el PHB correcto con corrientes de tráfico (clasificación y marcación) y garantizar que la corriente cumpla su perfil de tráfico (dosificación, conformación y caída). Se deberá notar que hay muchas semejanzas lógicas entre cómo los dispositivos de borde en el MPLS y los TCs en el DiffServ manejan la implementación de servicio.

La arquitectura general según la presente invención se representa en la figura 3. Obsérvese en particular que el BB en el dominio MPLS es responsable de la señalización entre dominios y cómo controla un conjunto de Brokers intradominios (IDBs) dentro de su propio dominio. Dentro del dominio MPLS el BB central es responsable de pasar peticiones de recursos a los brokers intradominios. Cada broker intradominios es responsable del control de admisión y establecimiento de LSP en un área OSPF (u otros dominios de estado de enlace plano equivalentes).

La figura 4 proporciona un escenario ejemplar donde se ha establecido una VLL que abarca dos dominios, A y B. El dominio A incluye un enrutador de entrada 2 y un enrutador de salida 4. El enrutador de salida 4 del dominio A está conectado, o es equivalente, a un enrutador de entrada 6 del dominio B. El dominio B también incluye un enrutador de salida 8. Este ejemplo muestra cómo se resuelve el problema de extremo a extremo. Paso a paso, sucede lo siguiente:

1.

Una petición de una VLL de velocidad R de la red SRC a la red DST es pasada al BB del dominio A y se puede hacer de numerosas formas. Algunos ejemplos son interacción humana con un sistema de peticiones, invocación de función a través de una petición de servicio API de un sistema de gestión, y señalización de aplicación y proxy COPS/RSVP en el enrutador de entrada. La generación de una petición de una Línea Arrendada Virtual (VLL) de velocidad (o anchura de banda) R desde una red origen (SRC) a una red destino (DST) y después aplicar la petición a un Broker de Anchura de Banda del dominio A (BB_{A}).

2.

BB_{A}pasa una petición a un Broker de Anchura de Banda en el dominio B (BB_{B}) con respecto a VLL de velocidad R desde la entrada de dominio en B a DST, a condición de que BB_{A} sea consciente de que se llega a DST a través del dominio B. Hay numerosas formas posibles de tratar este tipo de petición entre dominios. Según este ejemplo, decimos que la petición pasada al BB en el dominio B es para una VLL de velocidad R, desde la entrada de dominio en B a DST.

3.

BB_{A}realiza simultáneamente control de admisión sensible a trayecto según enrutamiento de capa 3 desde el enrutador de entrada SRC al enrutador de salida del dominio B. Esto se consigue consultando el trayecto a través del dominio A y evaluando la disponibilidad de recursos en cada enlace en el trayecto.

4.

Al recibir la petición del dominio A, el BB en el dominio B hace el siguiente:

a.

Dada la entrada de dominio A y el destino DST, el BB halla que la primera zona de salto para la petición es el área 1 y pasa una petición al broker intradominios, que realiza control de admisión (y posiblemente establecimiento de LSP) para su área.

b.

Pasar una petición a uno o muchos brokers intradominios (IDB) implicados en el dominio B, donde cada broker intradominios realiza control de admisión (y posiblemente establecimiento LSP) en su área.

c.

Dadas las respuestas de ambos brokers intradominios implicados, se pasa de nuevo una respuesta al BB en el dominio B.

5.

El BB en el dominio A recibe la respuesta del dominio B y la pasa de nuevo a la parte solicitante. Si la petición fue admitida a lo largo de todas los fragmentos del trayecto, el BB participa en la configuración de Acondicionares de Tráfico (TC) en el enrutador de entrada para SRC.

6.

Dado que todos los pasos tuvieron éxito, hay ahora una VLL de velocidad R de SRC a DST, que es:

\text{*}

vigilada en la entrada para SRC,

\text{*}

enrutada normalmente a través del dominio A,

\text{*}

vigilada de nuevo a la entrada para el dominio A al dominio B,

\text{*}

clasificada como un FEC a la entrada en el dominio B,

\text{*}

conmutada con etiqueta a través del dominio B hasta que llegue al destino DST.

El segundo objeto de la presente invención, relacionado con la planificación de recursos en el tiempo, se logra con una segunda realización preferida de la invención. Según esta realización, se realizan los mismos pasos que antes con la diferencia de que no se toma ninguna acción de configuración hasta que el tiempo de inicio de la petición (la configuración en el paso 5 se lleva a cabo al tiempo de inicio de la petición). El control de admisión de la petición se hace al tiempo de la petición, y si se concede la petición, la configuración de acondicionadores de tráfico y el establecimiento de LSP se programan de manera que tengan lugar al tiempo del inicio de la petición.

En el ejemplo ilustrado con referencia a la figura 4 solamente estaban implicados dos BB. En una implementación más general está implicado un número mucho más alto. Como se indicó anteriormente, un BB está dispuesto para comunicar con BBs en dominios contiguos, lo que permite QoS que abarcan varios dominios. En general un BB comunica con BBs a un salto de dominio solamente (es decir, con contiguos). Esto se refiere a la forma en que se realiza enrutamiento entre dominios en Internet. Para cada destino fuera de un dominio propio BBs, conoce el salto de dominio siguiente en el trayecto cuando los enrutadores de borde conocen el salto de dominio siguiente para cada destino.

Se obtiene información de direccionamiento para BBs contiguos por configuración o algún mecanismo de autodescubrimiento.

Un broker de anchura de banda BB que realiza control de admisión sensible a trayecto maneja peticiones como se describe en el diagrama de flujo de la figura 5. Los pasos en caso de éxito se describen a continuación:

\text{*}

Asegurar opcionalmente que la petición esté dentro de la política del usuario (obsérvese que un usuario puede ser desde un humano a un BB contiguo). Esto puede fallar si, por ejemplo, la petición es de una velocidad más alta que la permitida por la política del usuario.

\text{*}

Calcular el trayecto de la petición. Esto puede fallar si la petición contiene direcciones de origen o destino que están fuera del rango BBs de direcciones conocidas.

\text{*}

Control de admisión de todos enlaces en el trayecto que pertenecen a este dominio BBs. Esto se realiza con respecto a los parámetros de tiempo, si los hay, especificados en la petición de servicio. Este paso puede fallar debido a la falta de recursos a lo largo de cualquiera de los enlaces en el trayecto.

\text{*}

Si esta petición implica otros dominios, hacer control de admisión entre dominios.

Hay varias opciones para este paso:

\circ

Si se utiliza agregado, los BBs contiguos pueden reservar líneas entre sus dominios y permitir reservas dentro de las líneas, lo que significa que no habrá interacción entre dominios por petición. En tal caso, si la línea corriente es suficientemente grande para encajar en la petición corriente, puede ser concedida inmediatamente. En caso negativo, por otra parte, la petición puede ser puesta en cola en espera de recursos en la línea o puede ser incluso denegada, ambos eventos pueden servir como entrada al proceso de reevaluar la línea entre dominios.

\circ

Si no se utiliza agregado, se pasará una petición entre dominios al BB contiguo.

\text{*}

Cuando se ha(n) realizado el (los) paso(s) de control de admisión, es tiempo de implementar el servicio. Este paso puede fallar, por ejemplo, debido a problemas temporales en el equipo de red.

\text{*}

Responder a la parte solicitante que la petición fue concedida o denegada.

Si falla uno de los tres primeros pasos, la petición será denegada inmediatamente. Si falla la implementación de servicio o el control de admisión entre dominios, se debe realizar el paso de devolución de admisión para liberar recursos en el dominio propio del BBs.

La figura 6 muestra bloques funcionales de un broker de anchura de banda según la presente invención. En resumen, los bloques se describen como sigue:

\text{*}

Gestión de peticiones. Un BB maneja peticiones que se originan de varias fuentes que van desde humanos a BBs contiguos.

\text{*}

Almacenamiento persistente. Un BB con la capacidad de hacer control de admisión con el tiempo debe tener almacenamiento persistente, donde guarda registros de todas sus peticiones otorgadas y también datos relacionados con el usuario, tal como políticas o información contable.

\text{*}

Mapa de topografía. Un BB que realiza control de admisión sensible a trayecto debe tener topología correcta e información de enrutamiento para poder consultar los trayectos de peticiones entrantes. La igualización como un enrutador de estado de enlace recupera primariamente esta información. También puede ser recuperada mediante configuración o algún otro mecanismo.

\text{*}

Mapa de recursos. Para poder hacer control de admisión para el servicio VLL, la información de recursos debe ser acoplada a la topología en un mapa de recursos. Esta información se puede recoger automáticamente sondeando la red o se puede configurar estáticamente.

\text{*}

Implementación de servicio. Un BB debe ser capaz de implementar servicios concedidos. Según la presente invención, esto se realiza configurando acondicionadores de tráfico en dispositivos de borde en dominios DiffServ o por establecimiento de LSP en dominios MPLS.

\text{*}

Negociador entre dominios. Siempre que un servicio abarca más de un dominio, un BB debe ser capaz de contactar el BB en el dominio contiguo. Esta función se puede implementar con o sin agregado de peticiones.

En general, los Brokers de Anchura de Banda pueden tratar dos clases diferentes de políticas. El tipo de política más básico, que todos los BBs gestionan, es lo que se denomina frecuentemente política QoS. Este tipo de política está dentro de esta aplicación denominada un servicio. La política para transportar algunos datos con una cierta QoS es de hecho un servicio. El otro tipo de política que un BB gestiona opcionalmente son las políticas de usuario. Este tipo de política controla qué servicios pueden utilizar los usuarios, y posiblemente cuánto y en qué tiempos, etc.

Según una realización preferida de la invención, el parámetro QoS es la velocidad R. Naturalmente, un experto en la técnica es consciente de numerosos parámetros QoS alternativos.

La presente invención no se limita a las realizaciones preferidas antes descritas. Se puede usar varias alternativas, modificaciones y equivalentes. Por lo tanto, las realizaciones anteriores no se deberán considerar limitativas del alcance de la invención, que se define por las reivindicaciones anexas.

Claims (8)

1. Método en una red de comunicaciones a base de paquetes incluyendo dominios de red, donde al menos un dominio es un dominio de Conmutación de Etiquetas Multiprotocolo MPLS, para establecer una línea arrendada virtual, VLL, entre un origen (SRC) y un destino (DST) en diferentes dominios con el fin de lograr transferencia de paquetes entre el origen y el destino, donde un broker de anchura de banda (BB) está asociado a cada dominio de red y el broker de anchura de red (BB) está adaptado para controlar un dominio de enrutamiento jerárquico, el método incluye los pasos siguientes:

i) generar una petición a una entidad de una Línea Arrendada Virtual, VLL, que tiene una Calidad de Servicio predefinida, QoS, desde una red origen (SRC) a una red destino (DST) y aplicar la petición a un Broker de Anchura de Banda (BB) de un dominio A, BB_{A}, asociado a la red origen;

ii) BB_{A}establece los diferentes dominios implicados para llegar a la red destino (DST);

iii) BB_{A}pasa directa o indirectamente peticiones a todos los Brokers de Anchura de Banda (BB) de los dominios implicados con respecto a una VLL de la QoS predefinida desde la entrada a la salida de cada dominio;

iv) cada broker de anchura de banda (BB) implicado realiza control de admisión en su dominio;

v) cada broker de anchura de banda (BB) implicado devuelve un resultado del control de admisión a BB_{A}que lo pasa de nuevo a la entidad solicitante, y si la petición se admitió a lo largo de todos dominios entre el origen (SRC) y el destino (DST), se concede una VLL de la QoS predefinida.

caracterizado porque el paso iv) incluye el paso siguiente:

realizar preparación del Trayecto Conmutado de Etiquetas, LSP, y pasar peticiones de recursos desde el Broker de Anchura de Banda (BB) a al menos un broker intra dominio (IDB), donde cada broker intra dominio (IDB) es responsable del control de admisión y la preparación del Trayecto Conmutado de Etiquetas, LSP.

2. Método según la reivindicación 1, caracterizado porque si dichos dominios incluyen al menos un dominio de Servicios Diferenciados, DiffServ, el método incluye el paso siguiente a realizar después del paso v):

vi) BB_{A}participa en la configuración de Acondicionadores de Tráfico en el router de salida para SRC con el fin de establecer una VLL de la QoS predefinida.

3. Método según la reivindicación 1, caracterizado porque dichos dominios incluyen al menos un dominio de Servicios Diferenciados, DiffServ, y un dominio de Conmutación de Etiquetas Multiprotocolo, MPLS.

4. Método según la reivindicación 1, caracterizado porque dicha QoS predefinida es una velocidad, R.

5. Método según la reivindicación 1, caracterizado porque el broker de anchura de banda (BB) incluye un mapa de topología e información de enrutamiento para poder efectuar control de admisión sensible a trayecto de peticiones entrantes, donde la información se recupera por igualación como un enrutador de estado de enlace.

6. Método según la reivindicación 8, caracterizado porque el broker de anchura de banda (BB) incluye una estructura de datos que mantiene información de utilización de recursos en el tiempo para cada enlace en la topología que permite la capacidad de planificar con antelación.

7. Método según la reivindicación 1, caracterizado porque un broker de anchura de banda (BB) en un dominio específico realiza control de admisión para todos los enlaces en el trayecto que pertenecen a dicho dominio.

8. Método según la reivindicación 1, caracterizado porque un broker de anchura de banda (BB) incluye un almacenamiento, donde guarda registros de todas sus peticiones otorgadas y también datos relacionados con el usuario, tales como políticas o información contable.