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

Procedimiento de optimizacion de una red.

Info

Publication number
ES2217150T3
ES2217150T3 ES01933808T ES01933808T ES2217150T3 ES 2217150 T3 ES2217150 T3 ES 2217150T3 ES 01933808 T ES01933808 T ES 01933808T ES 01933808 T ES01933808 T ES 01933808T ES 2217150 T3 ES2217150 T3 ES 2217150T3
Authority
ES
Spain
Prior art keywords
domain
network
broker
bandwidth
domains
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
ES01933808T
Other languages
English (en)
Inventor
Emil Svanberg
Joachim Johansson
Anders Torger
Joakim Norrgard
Anders Larsson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Operax AB
Original Assignee
Operax AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=22727631&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2217150(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Operax AB filed Critical Operax AB
Application granted granted Critical
Publication of ES2217150T3 publication Critical patent/ES2217150T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
    • H04L41/0897—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities by horizontal or vertical scaling of resources, or by migrating entities, e.g. virtual resources or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/308—Route determination based on user's profile, e.g. premium users
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/15—Flow control; Congestion control in relation to multipoint traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/22—Traffic shaping
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/829—Topology based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5061—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the interaction between service providers and their network customers, e.g. customer relationship management
    • H04L41/5067—Customer-centric QoS measurements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Steroid Compounds (AREA)
  • Compounds Of Unknown Constitution (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

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.
ES01933808T 2000-04-13 2001-04-06 Procedimiento de optimizacion de una red. Expired - Lifetime ES2217150T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US19700600P 2000-04-13 2000-04-13
US197006P 2000-04-13

Publications (1)

Publication Number Publication Date
ES2217150T3 true ES2217150T3 (es) 2004-11-01

Family

ID=22727631

Family Applications (1)

Application Number Title Priority Date Filing Date
ES01933808T Expired - Lifetime ES2217150T3 (es) 2000-04-13 2001-04-06 Procedimiento de optimizacion de una red.

Country Status (10)

Country Link
US (1) US7190698B2 (es)
EP (1) EP1275226B1 (es)
JP (1) JP2003531519A (es)
KR (1) KR100696003B1 (es)
CN (1) CN1183724C (es)
AT (1) ATE262244T1 (es)
AU (1) AU2001260190A1 (es)
DE (1) DE60102367T2 (es)
ES (1) ES2217150T3 (es)
WO (1) WO2001080485A2 (es)

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7529856B2 (en) * 1997-03-05 2009-05-05 At Home Corporation Delivering multimedia services
US6370571B1 (en) 1997-03-05 2002-04-09 At Home Corporation System and method for delivering high-performance online multimedia services
US6985963B1 (en) * 2000-08-23 2006-01-10 At Home Corporation Sharing IP network resources
US7225271B1 (en) * 2001-06-29 2007-05-29 Cisco Technology, Inc. System and method for recognizing application-specific flows and assigning them to queues
US7272651B1 (en) * 2001-08-28 2007-09-18 Cisco Technology, Inc. RSVP transmitter proxy
FR2832890B1 (fr) * 2001-11-29 2004-02-27 Cit Alcatel Controle multi-domaine d'admission de flux de donnees associes a des criteres de qualite de service
US7480283B1 (en) 2002-03-26 2009-01-20 Nortel Networks Limited Virtual trunking over packet networks
US20050125517A1 (en) * 2002-04-04 2005-06-09 Joakim Norrgard Method for creating a map of available resources within an ip network
US7327675B1 (en) * 2002-08-01 2008-02-05 At&T Corp. Fairness of capacity allocation for an MPLS-based VPN
EP1398907B1 (de) * 2002-09-10 2010-12-08 Siemens Aktiengesellschaft Verfahren zur Kontrolle von Übertragungsressourcen eines paketorientierten Kommunikationsnetzes bei Topologieänderungen
KR100542401B1 (ko) * 2002-10-23 2006-01-11 한국전자통신연구원 인터넷 차별 서비스 망에서의 연결 수락 제어방법
KR100510820B1 (ko) * 2002-12-13 2005-08-31 주식회사 케이티 차등화 서비스 망에서 패스 및 링크 레벨 정보데이터베이스를이용한 수락제어 방법
US20060050636A1 (en) * 2003-01-20 2006-03-09 Michael Menth Traffic restriction in packet-oriented networks by means of link-dependent limiting values for traffic passing the network boundaries
DE60302865T2 (de) * 2003-02-03 2006-09-14 Alcatel Bandbreitenmakler für ein Telekommunikationssystem
US7082336B2 (en) * 2003-06-04 2006-07-25 Synecor, Llc Implantable intravascular device for defibrillation and/or pacing
DE602004027390D1 (de) * 2003-09-02 2010-07-08 Huawei Tech Co Ltd Verfahren zur auswahl eines übertragungspfades für echtzeit-verkehrsdaten
CN100455035C (zh) * 2003-09-02 2009-01-21 华为技术有限公司 一种正向约束逆向选路的路由方法
CN100396050C (zh) * 2003-12-24 2008-06-18 华为技术有限公司 一种跨独立运营网络的路由选路方法
CN100391154C (zh) * 2003-09-18 2008-05-28 华为技术有限公司 一种资源管理器中路由的选路方法
KR100563656B1 (ko) * 2003-10-17 2006-03-23 한국전자통신연구원 인터넷 차별 서비스 망에서 입력 호 상태를 반영한 적응적연결 수락 제어방법
US8312145B2 (en) * 2003-12-22 2012-11-13 Rockstar Consortium US L.P. Traffic engineering and bandwidth management of bundled links
CN100384172C (zh) * 2004-01-20 2008-04-23 华为技术有限公司 基于网络的虚拟专用网中保证服务质量的系统及其方法
CN100505746C (zh) * 2004-02-07 2009-06-24 华为技术有限公司 实现虚拟租用线的方法
CN100372337C (zh) * 2004-05-31 2008-02-27 华为技术有限公司 一种实现跨域约束路由的选路方法
US7606235B1 (en) 2004-06-03 2009-10-20 Juniper Networks, Inc. Constraint-based label switched path selection within a computer network
US7567512B1 (en) 2004-08-27 2009-07-28 Juniper Networks, Inc. Traffic engineering using extended bandwidth accounting information
CN100389581C (zh) * 2004-09-29 2008-05-21 华为技术有限公司 一种保障端到端业务质量的方法
CN1756186B (zh) * 2004-09-30 2010-04-28 华为技术有限公司 一种资源管理的实现方法
FR2876524A1 (fr) * 2004-10-08 2006-04-14 France Telecom Procede et dispositif de transfert de flux d'informations dans un reseau de telecommunication a permutation d'etiquettes
US7558199B1 (en) 2004-10-26 2009-07-07 Juniper Networks, Inc. RSVP-passive interfaces for traffic engineering peering links in MPLS networks
US20080004027A1 (en) * 2004-11-23 2008-01-03 Zte Corporation Method and System for Delaminatly Ensuring the Network Service Quality
CN100456691C (zh) * 2004-12-02 2009-01-28 华为技术有限公司 一种对承载网资源进行分配的方法
KR100705564B1 (ko) * 2004-12-10 2007-04-10 삼성전자주식회사 네트워크에서의 자원 관리 장치 및 방법
KR100739489B1 (ko) * 2004-12-13 2007-07-13 한국전자통신연구원 서버와 클라이언트의 사이의 네트워크 경로에 속하는라우터에 접속하는 대역폭 브로커 및 차등화 서비스 제공방법
TWI275284B (en) * 2005-04-01 2007-03-01 Compal Electronics Inc Method for classifying network connections and method for transmitting multimedia data
JP4606249B2 (ja) * 2005-05-18 2011-01-05 富士通株式会社 情報処理方法及びルータ
US7599302B2 (en) * 2005-07-19 2009-10-06 Cisco Technology, Inc. Dynamic enforcement of MPLS-TE inter-domain policy and QoS
US7983158B2 (en) * 2005-11-30 2011-07-19 Motorola Solutions, Inc. Routing topology bandwidth management methods and system
FR2894746B1 (fr) * 2005-12-09 2008-06-13 Ipanema Technologies Sa Procede et dispositif de controle a distance de la congestion de flux mailles dans un reseau de telecommunication en mode paquet
JP4571080B2 (ja) * 2006-02-15 2010-10-27 富士通株式会社 マルチドメインネットワークにおけるＱｏＳ保証システム及び，これに適用するＱｏＳサーバ
JP4682068B2 (ja) * 2006-03-17 2011-05-11 富士通株式会社 品質保証サービス情報通知方法、通信装置及びドメイン間情報伝達装置
DE102006021595A1 (de) * 2006-05-09 2007-11-15 Siemens Ag Verfahren, Netzagent und Bandbreitenbroker zum Verwalten der verfügbaren Bandbreite für Verbindungen zwischen Endgeräten eines paketorientierten Kommunikationsnetzes
US7924715B2 (en) * 2008-05-12 2011-04-12 Nortel Networks Limited Method and apparatus for discovering, negotiating, and provisioning end-to-end SLAs between multiple service provider domains
CN101272395B (zh) * 2008-05-20 2012-07-11 北京交通大学 一种通信网络的层次接入控制方法
JP5111256B2 (ja) * 2008-06-23 2013-01-09 株式会社日立製作所 通信システムおよびサーバ装置
US7916636B2 (en) * 2009-01-05 2011-03-29 Corrigent Systems Ltd. Ring network aggregate rates
US8972596B2 (en) * 2009-04-28 2015-03-03 The Boeing Company System and method for effecting communications among devices in different domains employing different operating protocols
JP5152265B2 (ja) * 2010-07-16 2013-02-27 富士通株式会社 情報処理方法及びルータ
US8885463B1 (en) 2011-10-17 2014-11-11 Juniper Networks, Inc. Path computation element communication protocol (PCEP) extensions for stateful label switched path management
US8824274B1 (en) 2011-12-29 2014-09-02 Juniper Networks, Inc. Scheduled network layer programming within a multi-topology computer network
US8787154B1 (en) 2011-12-29 2014-07-22 Juniper Networks, Inc. Multi-topology resource scheduling within a computer network
US20150117194A1 (en) * 2012-04-16 2015-04-30 Nec Corporation Network Control Method and Device
US9071541B2 (en) 2012-04-25 2015-06-30 Juniper Networks, Inc. Path weighted equal-cost multipath
US8787400B1 (en) 2012-04-25 2014-07-22 Juniper Networks, Inc. Weighted equal-cost multipath
US9300570B2 (en) * 2012-05-22 2016-03-29 Harris Corporation Multi-tunnel virtual private network
US10031782B2 (en) 2012-06-26 2018-07-24 Juniper Networks, Inc. Distributed processing of network device tasks
FR2998748B1 (fr) * 2012-11-23 2015-04-10 Commissariat Energie Atomique Dispositif et procede de retransmission de donnees dans un commutateur reseau
US9450817B1 (en) 2013-03-15 2016-09-20 Juniper Networks, Inc. Software defined network controller
CN104168197A (zh) * 2013-05-16 2014-11-26 宇宙互联有限公司 传输管理装置、系统及方法
CN104168198A (zh) * 2013-05-16 2014-11-26 宇宙互联有限公司 传输管理装置、系统及方法
US9577925B1 (en) 2013-07-11 2017-02-21 Juniper Networks, Inc. Automated path re-optimization
CN104579893A (zh) * 2013-10-18 2015-04-29 宇宙互联有限公司 传输路径控制系统
CN104579967A (zh) * 2013-10-18 2015-04-29 宇宙互联有限公司 传输路径控制设备
CN104579891A (zh) * 2013-10-18 2015-04-29 宇宙互联有限公司 可提高连接性能的网络系统
CN104579943A (zh) * 2013-10-18 2015-04-29 宇宙互联有限公司 传输路径管理系统及方法
CN104579892A (zh) * 2013-10-18 2015-04-29 宇宙互联有限公司 传输路径按需提供系统及方法
US10193801B2 (en) 2013-11-25 2019-01-29 Juniper Networks, Inc. Automatic traffic mapping for multi-protocol label switching networks
CN108880999B (zh) * 2013-12-30 2021-06-01 华为技术有限公司 一种业务路由的方法、设备及系统
US9553803B2 (en) * 2014-06-30 2017-01-24 Nicira, Inc. Periodical generation of network measurement data
US10039112B2 (en) 2014-10-10 2018-07-31 Huawei Technologies Co., Ltd Methods and systems for provisioning a virtual network in software defined networks
US9578149B2 (en) 2015-02-06 2017-02-21 Samsung Electronics Co., Ltd. Electronic device including display with bent area
EP3890286B1 (en) 2015-02-06 2023-08-16 Samsung Electronics Co., Ltd. Portable electronic device
US10051096B2 (en) * 2015-02-06 2018-08-14 Samsung Electronics Co., Ltd. Battery pack mounting structure and electronic device having the same
US10056204B2 (en) 2015-02-06 2018-08-21 Samsung Electronics Co., Ltd. Key button assembly and electronic device having the same
US10491525B2 (en) 2015-03-10 2019-11-26 Huawei Technologies Co., Ltd. Traffic engineering feeder for packet switched networks
US10111163B2 (en) 2015-06-01 2018-10-23 Huawei Technologies Co., Ltd. System and method for virtualized functions in control and data planes
EP3257320B1 (en) 2015-06-01 2020-04-08 Huawei Technologies Co., Ltd. System and method for virtualized functions in control and data planes
US10313887B2 (en) * 2015-06-01 2019-06-04 Huawei Technologies Co., Ltd. System and method for provision and distribution of spectrum resources
US10212589B2 (en) 2015-06-02 2019-02-19 Huawei Technologies Co., Ltd. Method and apparatus to use infra-structure or network connectivity services provided by 3rd parties
US10700936B2 (en) * 2015-06-02 2020-06-30 Huawei Technologies Co., Ltd. System and methods for virtual infrastructure management between operator networks
US10862818B2 (en) 2015-09-23 2020-12-08 Huawei Technologies Co., Ltd. Systems and methods for distributing network resources to network service providers
US10212097B2 (en) 2015-10-09 2019-02-19 Huawei Technologies Co., Ltd. Method and apparatus for admission control of virtual networks in a backhaul-limited communication network
US10470000B2 (en) * 2016-02-12 2019-11-05 Samsung Electronics Co., Ltd. Methods and apparatus for enhanced MBMS content provisioning and content ingestion
US10484253B2 (en) * 2017-01-30 2019-11-19 Hewlett Packard Enterprise Development Lp Topology map update with service quality indicators
JP7434110B2 (ja) 2020-08-20 2024-02-20 株式会社日立製作所 ネットワーク管理システム及び方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5953338A (en) 1996-12-13 1999-09-14 Northern Telecom Limited Dynamic control processes and systems for asynchronous transfer mode networks
JP2000069030A (ja) * 1998-08-21 2000-03-03 Nippon Telegr & Teleph Corp <Ntt> マルチキャリアネットワーク管理方法
US6487170B1 (en) * 1998-11-18 2002-11-26 Nortel Networks Limited Providing admission control and network quality of service with a distributed bandwidth broker
US6538416B1 (en) * 1999-03-09 2003-03-25 Lucent Technologies Inc. Border gateway reservation protocol for tree-based aggregation of inter-domain reservations
JP3636948B2 (ja) * 1999-10-05 2005-04-06 株式会社日立製作所 ネットワークシステム
US7054938B2 (en) * 2000-02-10 2006-05-30 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for network service reservations over wireless access networks

Also Published As

Publication number Publication date
US20030103510A1 (en) 2003-06-05
WO2001080485A3 (en) 2002-06-13
EP1275226A2 (en) 2003-01-15
KR100696003B1 (ko) 2007-03-15
DE60102367D1 (de) 2004-04-22
DE60102367T2 (de) 2005-02-17
CN1423878A (zh) 2003-06-11
JP2003531519A (ja) 2003-10-21
EP1275226B1 (en) 2004-03-17
US7190698B2 (en) 2007-03-13
KR20030017497A (ko) 2003-03-03
WO2001080485A2 (en) 2001-10-25
AU2001260190A1 (en) 2001-10-30
ATE262244T1 (de) 2004-04-15
CN1183724C (zh) 2005-01-05

Similar Documents

Publication Publication Date Title
ES2217150T3 (es) Procedimiento de optimizacion de una red.
ES2290327T3 (es) Metodo y disposicion en una red ip.
US8451846B1 (en) LSP hierarchy for MPLS networks
CN111585780A (zh) 通过底层网络拓扑支持多个虚拟网络
Xiao Providing quality of service in the Internet
Fang et al. Interprovider IP-MPLS services: requirements, implementations, and challenges
Akyildiz et al. A new traffic engineering manager for DiffServ/MPLS networks: design and implementation on an IP QoS testbed
Dasarathy et al. Network qos assurance in a multi-layer adaptive resource management scheme for mission-critical applications using the corba middleware framework
Farrel Overview and principles of Internet traffic engineering
Aimoto et al. Overview of DiffServ technology: Its mechanism and implementation
Zhang et al. Building MPLS VPNs with QoS Routing Capability
Elmasry et al. Network management challenges for joint forces interoperability
Dasarathy et al. Adaptive network QoS in layer-3/layer-2 networks as a middleware service for mission-critical applications
Gomes et al. A similarity model for virtual networks negotiation
Parsaei et al. A new architecture to improve multimedia QoS over software defined networks
US20220247674A1 (en) Service routing function for flexible packet path for secured traffic
Prabavathi et al. Quality of Service Enhancement of a Carrier Supporting Carrier Network using MQCQOS
Patil et al. Optimizing MPLS Tunnel Creation Performance by Using SDN
KR100794363B1 (ko) 웹 서비스를 이용한 인터-도메인 간의 서비스품질 보장형 연결설정 방법 및 시스템
Chen et al. Using policy-based MPLS management architecture to improve QoS on IP network
US20050125517A1 (en) Method for creating a map of available resources within an ip network
Ceccarelli et al. TEAS Working Group T. Saad Internet-Draft V. Beeram Intended status: Standards Track Juniper Networks Expires: 20 May 2022 B. Wen Comcast
de Oliveira New techniques for end-to-end quality of service provisioning in DiffServ/MPLS networks
Gomes et al. A transsignaling strategy for QoS support in heterogeneous networks
Sabri QoS in MPLS and IP Networks