ES2812478T3 - Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales - Google Patents

Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales Download PDF

Info

Publication number
ES2812478T3
ES2812478T3 ES19154446T ES19154446T ES2812478T3 ES 2812478 T3 ES2812478 T3 ES 2812478T3 ES 19154446 T ES19154446 T ES 19154446T ES 19154446 T ES19154446 T ES 19154446T ES 2812478 T3 ES2812478 T3 ES 2812478T3
Authority
ES
Spain
Prior art keywords
network
message
controller
domain
virtual
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.)
Active
Application number
ES19154446T
Other languages
English (en)
Inventor
Young Lee
Dhruv Dhody
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2812478T3 publication Critical patent/ES2812478T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4641Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051Service on demand, e.g. definition and deployment of services in real time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5077Network service management, e.g. ensuring proper service fulfilment according to agreements wherein the managed service relates to simple transport services, i.e. providing only network infrastructure

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método (1000) para establecer un túnel de extremo a extremo que se extiende a través de múltiples dominios utilizando un elemento de red, que comprende: asociar (1004) una red virtual (VN) con los recursos disponibles en base a las limitaciones de la red, en donde la VN está asociada con el túnel de extremo a extremo; y transmitir (1006) un mensaje a un controlador de red que gestiona un dominio de los múltiples dominios, en donde el dominio incluye una ruta de red que forma una parte del túnel de extremo a extremo, y el mensaje incluye un objeto de asociación que contiene un identificador de red virtual que vincula la ruta de red a la VN.

Description

DESCRIPCIÓN
Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales
Antecedentes
Un Elemento de Cálculo de Ruta (PCE) es un componente de red, aplicación, u nodo de red capaz de calcular rutas sofisticadas a través de una red aplicando limitaciones computacionales en tiempo real. Tradicionalmente, las rutas de red se calculan y gestionan fuera de línea como parte de la ingeniería de tráfico de una red. En dicho escenario, cuando un nuevo cliente se conecta, los requisitos de tráfico del cliente se evalúan y superponen en la topología de la red actual. La arquitectura PCE está definida por el documento 4655 de la Solicitud de Comentario (RFC) del Grupo de Trabajo de Ingeniería de Internet (IETF) titulado, “A Path Computation Element (PCE)-Based Architecture”, publicado en Agosto del 2006.
El PCE tiene una imagen completa de los flujos y rutas en la red en el momento preciso derivada de otros programas de Software de Soporte Operativo (OSS). Como tal, el PCE puede calcular en tiempo real la ruta óptima a través de la red. La ruta se utiliza para actualizar automáticamente las configuraciones del router y la base de datos de ingeniería de tráfico. El PCE recibe y responde a las solicitudes de cálculo de ruta recibidas de un Cliente de Cálculo de Ruta (PCC) utilizando un Protocolo de Comunicación de Elementos de Cálculo de Ruta (PCEP). El PCEP está definido por el documento 5440 de RFC del IETF titulado, “Path Computation Element (PCE) Communication Protocol (PCEP)”, publicado en Marzo del 2009, que se incorpora en la presente memoria.
El documento CN101883048A se refiere a un método de enrutamiento de descubrimiento de enrutamiento, mantenimiento de enrutamiento, construcción de red, y similares en una red multidimensional operada en un módulo de red multidimensional. En el descubrimiento de enrutamiento, cuando se transmiten datos, un nodo fuente emite un mensaje de solicitud de ruta a un nodo vecino; después de recibir el mensaje de solicitud de ruta emitido, un nodo de retransmisión coincide con la entrada de ruta del mismo, y actualiza la entrada de ruta y transfiere el mensaje de solicitud de ruta al nodo vecino si no está disponible la entrada de ruta necesaria o la ruta existente no es una nueva ruta; si está disponible una nueva ruta, el nodo de retransmisión devuelve un mensaje de respuesta de solicitud de ruta al nodo fuente; los nodos pasados en el camino de retorno del mensaje de respuesta de solicitud de ruta establecen una ruta a un nodo de destino según el mensaje de respuesta de solicitud de ruta; y después de recibir el mensaje de respuesta de solicitud de ruta, el nodo fuente establece una ruta al nodo de destino según el mensaje de solicitud de ruta y transmite datos según la ruta.
El documento CN103916302B se refiere a una red (SDN) para proporcionar software para definir un método y un aparato de rutas de flujo virtual WLAN. El método que comprende: cuando un usuario WLAN asociado con una estación virtual que utiliza un operador de red virtual (VNO) WLAN adquiere información vinculante entre el identificador de usuario de las estaciones WLAN y el identificador virtual WLAN; la información de marcado de la suscripción de servicio del usuario relacionada con la ruta de flujo, en donde dicha información de suscripción del usuario comprende un identificador de servicio de las estaciones WLAN, el, al menos uno, identificador de VNO WLAN virtual y el identificador del servidor de aplicación; que produce cada unidad en la entrada de flujo SDN de la ruta de flujo hacia delante SDN, incluyendo cada entrada un identificador de las estaciones WLAN, identificador del servidor de aplicación VNO, y la ruta de flujo de operación para marcar un flujo SDN de secuencia de paquetes entre las estaciones WLAN y un VNO del servidor de aplicación; indicando, respectivamente, la ruta de flujo de cada unidad de reenvío configurada SDN de entrada de flujo generada por dicho paso de generación.
El documento US2014/036675A1 describe un método y un dispositivo de red (p. ej., un conmutador) para asignar enlaces Ethernet virtuales. El método puede comprender el acceso del dispositivo de red para obtener información relacionada con el hardware (p. ej., hardware de conmutación) del dispositivo de red. Después, un enlace del enlace ascendente de una pluralidad de enlaces ascendentes físicos se selecciona en base a la información. Un interfaz de red virtual de una máquina virtual se mapea entonces al enlace del enlace ascendente seleccionado.
El documento “Path Computation Element (PCE) Protocol Extension for stateful PCE usage for Point-to-Multipoint T raffic Engineering Label Switched Paths, draft-palle-pce-stateful-pce-p2mp-06” describe que el PCE se ha identificado como una tecnología apropiada para la determinación de las rutas de los LSPs TE punto a multipunto (P2MP). Este documento proporciona las extensiones requeridas para PCEP para permitir el uso de una capacidad PCE con estado en el soporte de LSPs TE punto a multipunto (P2MP).
Compendio
Se proporcionan en las reivindicaciones un método, un elemento de red y un controlador de red para establecer un túnel de extremo a extremo que se extiende a través de múltiples dominios según la presente invención.
Cuando una red virtual (VN) es creada por un cliente sobre redes de ingeniería de tráfico (TE) de dominio múltiple y multicapa, estableciendo una relación entre la VN y un conjunto de rutas de red, como las rutas de etiquetas conmutadas (LSPs), es importante para gestionar y organizar el servicio asociado con la VN. Los sistemas y métodos descritos en la presente memoria establecen una relación entre una VN y LSPs de red. En otras palabras, la VN está vinculada a una o más LSPs. Cuando las redes virtuales (VNs) están vinculadas a LSPs, los clientes pueden organizar la VN que crean desde una perspectiva de servicio. Además, los operadores pueden organizar las LSPs asociadas con la VN del cliente sin problemas y de manera eficiente sobre redes de dominio múltiple desde una perspectiva de red. En un ejemplo, el PCEP se extiende entre un coordinador de servicio de dominio múltiple (MDSC) y un controlador de red física (PNC) para facilitar la asociación vinculante en la arquitectura PCEP. En otro ejemplo, el protocolo propuesto en el documento del IETF titulado, “RESTCONF Protocol”, publicado el 20 de Septiembre del 2016, está creado para permitir la asociación vinculante. A este respecto, un modelo de datos consistente con el lenguaje de modelado de datos propuesto en el documento 6020 de RFC del IETF titulado, “YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)”, publicado en Octubre del 2010, que se incorpora en la presente memoria por remisión como si se reprodujera en su totalidad, puede ser utilizado. Dicho modelo de datos puede denominarse “modelo de datos Yang”.
En una realización, la descripción incluye un método para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios utilizando un elemento de red que incluye recibir una solicitud de un controlador de cliente para implementar una red virtual (VN) creada por el controlador de cliente, en donde la VN identifica los túneles de extremo a extremo que se extienden a través de múltiples dominios, para mapear la VN a los recursos disponibles en base a las limitaciones de la red en respuesta a la solicitud, y para transmitir, después de que se haya mapeado la VN, un mensaje a un controlador de red que gestiona uno de los dominios que incluye una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo, en donde el mensaje incluye un objeto de asociación que tiene un campo de Valor de Longitud Tipo (TLV) que contiene un identificador de red virtual que vincula la ruta de red a la VN.
En una realización, el elemento de red es un Coordinador de Servicio de Dominio Múltiple (MDSC) y el controlador de red es un Controlador de Red de Proveedor (PNC). En una realización, el elemento de red es un Elemento de Cálculo de Ruta Padre (P-PCE) y el controlador de red es un PCE Hijo. En una realización, el controlador de cliente es un Controlador de Red de Cliente (CNC). En una realización, el objeto de asociación es un objeto del Grupo de Asociación de Red Virtual (VNAG). En una realización, la ruta de red son unas rutas de etiquetas conmutadas (LSPs). En una realización, el identificador de red virtual es uno de un nombre de VN y de una identificación de túnel (ID). En una realización, las limitaciones de la red comprenden, al menos una, de calidad de servicio (QoS) y de ancho de banda. En una realización, el mensaje es un mensaje PCInitiate que se ajusta a un Protocolo del Elemento de Cálculo de Ruta (PCEP). En una realización, el mensaje se establece utilizando un modelo de datos. En una realización, uno de los mensajes se transmite a uno de los controladores de red para cada una de las rutas de red que pueden utilizarse para formar túneles de extremo a extremo. En una realización, el método comprende además recibir, de cada uno de los controladores de red, un mensaje de reporte que indica un estado de las rutas de red gestionadas por los controladores de red. En una realización, el método comprende además el envío, a uno o más de los controladores de red, de un mensaje de actualización después de que se haya transmitido el mensaje, en donde el mensaje de actualización indica cualquier cambio realizado a la VN por el controlador de cliente.
En una realización, la descripción incluye un método para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios implementado por un controlador de red que gestiona un dominio que incluye recibir un mensaje de un primer elemento de red que fue dado instrucciones por un controlador de cliente para implementar una red virtual (VN) que incluye los túneles de extremo a extremo, en donde el mensaje incluye un objeto de asociación que tiene un campo de Valor de Longitud Tipo (TLV) que contiene un identificador de red virtual que vincula una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo a la VN, y para dar instrucciones a un router de frontera que gestiona el dominio para establecer la ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo.
En una realización, el método comprende además recibir una indicación del router de frontera de que la ruta de red ha sido establecida. En una realización, el método comprende además recibir un segundo mensaje del primer elemento de red, en donde el segundo mensaje incluye el objeto de asociación que tiene el campo de TLV que contiene el identificador de red virtual que vincula una segunda ruta de red utilizada para formar otra parte de uno de los túneles de extremo a extremo a la VN.
En una realización, la descripción incluye un elemento de red configurado para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios que incluyen un receptor configurado para recibir una solicitud de un controlador de cliente para implementar una red virtual (VN) creada por el controlador de cliente, en donde la VN identifica los túneles de extremo a extremo, un procesador acoplado al receptor y configurado para mapear la VN a los recursos disponibles en base a las limitaciones de la red, y un transmisor acoplado al procesador y configurado para transmitir un mensaje a un controlador de red que gestiona uno de los dominios, que incluye una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo, en donde el mensaje incluye un identificador de red virtual que vincula la ruta de red a la VN.
En una realización, el identificador de red virtual en el mensaje es identificado dentro de un modelo de datos. En una realización, el identificador de red virtual es uno de un nombre de red virtual y de una identificación de túnel (ID). En una realización, el mensaje es un Mensaje PCInitiate que se ajusta a un Protocolo del Elemento de Cálculo de Ruta (PCEP).
Para mayor claridad, cualquiera de las realizaciones anteriores puede combinarse con una o más de las otras realizaciones anteriores para crear una nueva realización dentro del alcance de la presente descripción.
Estas y otras características se entenderán más claramente a partir de la siguiente descripción detallada tomada junto con los dibujos y las reivindicaciones adjuntas.
Breve descripción de los dibujos
Para una comprensión más completa de esta descripción, se hace referencia ahora a la siguiente descripción breve, tomada en conexión con los dibujos adjuntos y la descripción detallada, en donde los números de referencia similares representan partes similares.
La FIG. 1 es un diagrama de una perspectiva general de una arquitectura PCEP utilizada para crear una ruta de extremo a extremo a través de múltiples dominios.
La FIG. 2 es un diagrama de un esquema de mensajes utilizado para crear túneles de extremo a extremo a través de múltiples dominios.
La FIG. 3 es un diagrama que ilustra varias configuraciones para una VN.
La FIG. 4 es un diagrama que ilustra la relación de VN vista por diferentes entidades en la arquitectura PCEP.
La FIG. 5 es un diagrama que representa una realización de un procedimiento PCInitiate que vincula las VNs a las rutas de red para cada dominio cuando se crea la ruta de extremo a extremo.
La FIG. 6 es una realización de un nuevo formato de Objeto del Grupo de Asociación Virtual (VNAG) para su uso con el esquema de extensión PCEP de la FIG. 5.
La FIG. 7 es un diagrama esquemático de un procedimiento de Mensaje PCRcpt que sigue al procedimiento PCInitiate de la FIG. 5.
La FIG. 8 es un diagrama esquemático de un procedimiento de Mensaje PCUpd que sigue al procedimiento PCRcpt de la FIG. 7.
La FIG. 9 es un modelo de datos consistente con el lenguaje de modelado de datos propuesto en el documento 6020 de RFC del IETF.
La FIG. 10 es un método para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios utilizando un elemento de red.
La FIG. 11 es un método para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios implementado por un controlador de red que gestiona uno de los dominios.
La FIG. 12 es un diagrama esquemático de una realización de un sistema informático de propósito general.
La FIG. 13 es un aparato configurado para implementar uno o más de los métodos descritos en la presente memoria. La FIG. 14 es un aparato configurado para implementar uno o más de los métodos descritos en la presente memoria.
Descripción detallada
Debe entenderse desde el principio que, aunque se proporciona a continuación una implementación ilustrativa de una o más realizaciones, los sistemas y/o métodos descritos pueden implementarse utilizando cualquier número de técnicas, ya sean actualmente conocidas o en existencia. La descripción, de ninguna manera, debe limitarse a las implementaciones ilustrativas, dibujos, y técnicas ilustradas a continuación, que incluyen los diseños e implementaciones ejemplares ilustrados, y descritos, en la presente memoria, pero pueden modificarse dentro del alcance de las reivindicaciones adjuntas junto con su alcance completo de equivalentes.
El PCEP proporciona mecanismos para los Elementos de Cálculo de Ruta (PCEs) para realizar cálculos de ruta en respuesta a solicitudes de los Clientes de Cálculo de Ruta (PCCs). El borrador del IETF titulado, “Applicability of a Stateful Path Computation Element (PCE)”, por X. Zhang, et al., publicado el 19 de Octubre del 2015, describe consideraciones generales para un despliegue PCE con estado y examina su aplicabilidad y beneficios, así como sus desafíos y limitaciones a través de un número de casos de uso. Este borrador del IETF también describe un conjunto de extensiones para PCEP para proporcionar control con estado. Un PCE con estado tiene acceso no solo a la información transportada por un Protocolo de Pasarela Interior (IGP) de la red, sino también al conjunto de rutas activas y sus recursos reservados para sus cálculos. El estado adicional permite al PCE calcular rutas restringidas mientras que considera las LSPs individuales y sus interacciones.
El borrador del IETF titulado, “PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model”, por E. Crabbe, et al., publicado el 19 de Octubre del 2015, describe la configuración, el mantenimiento y el desmontaje de las LSPs iniciadas por el PCE bajo el modelo PCE con estado. Dentro de la arquitectura PCE jerárquica, un PCE se utiliza para iniciar o eliminar LSPs para un PCC. El borrador del IETF titulado, “PCEP Extensions for Establishing Relationships Between Sets of LSPs”, por I. Minei, et al., publicado el 26 de Noviembre del 2015, que se incorpora por la presente por remisión como si se reprodujera en su totalidad, describe un mecanismo genérico para crear una agrupación de LSPs. Como se usa en la presente memoria, el IETF titulado, “PCEP Extensions for Establishing Relationships Between Sets of LSPs”, es referido como el “ IETF del Grupo de Asociación”. La agrupación puede utilizarse para definir la asociación entre conjuntos de LSPs o entre un conjunto de LSPs y un conjunto de atributos. El borrador del IETF titulado, “Requirements for Abstraction and Control of TE Networks”, por Y. Lee, et al., publicado el 1 de Octubre del 2015, que se incorpora por la presente por remisión como si se reprodujera en su totalidad, describe varias operaciones de VN iniciados por un cliente/aplicación. En este contexto, un conjunto de LSPs está asociado con una “construcción” de VN para facilitar las operaciones de VN en la arquitectura PCE. Este documento del IETF, que puede denominarse ACTN-REQ, especifica una extensión PCEP para asociar un conjunto de LSPs en base a una VN o cliente.
En referencia a la FIG. 1, se ilustra una perspectiva general de una arquitectura PCEP 100 que puede ser adecuada para crear un túnel de extremo a extremo 102 a través de múltiples dominios 104. Como se muestra, la arquitectura PCEP 100 incluye uno o más Controladores de Red de Cliente (CNCs) 106, un MDSC 108 (en el contexto de Abstracción y Control de Redes de Ingeniería de Tráfico (ACTN)), un, al menos uno, Controlador de Red Física 110 para cada uno de los dominios 104 a través de los cuales pasa la ruta de extremo a extremo 102. Como se muestra, el túnel de extremo a extremo 102 se extiende desde un extremo 118 (p. ej., una fuente) hasta otro extremo 118 (p. ej., un destino).
Los CNCs 106 interactúan con el MDSC 108 sobre una interfaz CNC/MDSC (CMI) 112, el MDSC 108 interactúa con los PNCs 110 sobre una interfaz MDSC/PNC (MPI) 114, y los PNCs 110 interactúan con los dominios 104 sobre una interfaz descendente (SBI) 116. Debe reconocerse que la arquitectura PCEP 100 puede incluir otros elementos o componentes de red y puede tener otras configuraciones adecuadas en aplicaciones prácticas como apreciaría un experto en la técnica al revisar esta descripción.
La FIG. 2 es un diagrama que ilustra un esquema de mensajes utilizado dentro de una arquitectura PCEP 200 para crear los túneles de extremo a extremo a través de múltiples dominios. La arquitectura PCEP 200 en la FIG. 2 puede ser similar a la arquitectura PCEP 100 de la FIG. 1. La arquitectura PCEP 200 de la FIG. 2 incluye, por ejemplo, un CNC 206, un MDSc 208 (también denominado en la presente memoria como PCE Padre (P-PCE) en el contexto PCEP), y al menos un PNC 210 (también denominado en la presente memoria como PCE Hijo (C-PCE) en el contexto PCEP) para cada uno de los dominios 204 a través de los cuales pasa el túnel de extremo a extremo 202. El CNC 206, el MDSC 208, el PNC 210, los dominios 204, y el túnel de extremo a extremo 202 son similares al CNC 106, al MDSC 108, al PNC 110, a los dominios 104, y al túnel de extremo a extremo 102 de la FIG. 1. Como se muestra, varios túneles de extremo a extremo 202 se extienden entre diferentes extremos 218 en los diversos dominios 204. Los extremos 218 de la FIG. 2, que también pueden denominarse miembros (p. ej., Miembro 1, Miembro 2, Miembro 3, etc.), son similares a los extremos 118 de la FIG. 1. Como se muestra, uno o más routers de frontera 270 pueden estar dispuestos entre los extremos 218 y ser incluidos en uno o más túneles de extremo a extremo 202.
Para comenzar, el CNC 206 crea una VN 250. La VN 250 puede comprender un conjunto de túneles de extremo a extremo 252 desde un punto de vista del cliente. Estos túneles de extremo a extremo 252 conectan los extremos 218 (p. ej., un borde del cliente de origen (CE), un CE de destino, etc.) entre sí. Los túneles de extremo a extremo 252 corresponden a los túneles de extremo a extremo 102, 202 de las FIGs , 1 -2. La VN 250 de la FIG. 2 puede comprender un número de nodos virtuales y de enlaces virtuales. En otras palabras, la VN 250 puede ser más que un túnel.
La FIG. 3 ilustra varias configuraciones de ejemplo para una VN 350 que tiene túneles y enlaces virtuales. La VN 350 de la FIG. 3 puede ser similar a la VN 250 de la FIG. 2. Cada una de las VNs 350 en la FIG. 3 incluye nodos virtuales 360 conectados juntos por enlaces virtuales 362. Como es bien conocido por los expertos en la técnica, los nodos virtuales 360 y los enlaces virtuales 362 representan los elementos y conexiones de red físicas subyacentes que se abstraen para crear las representaciones virtuales.
La FIG. 4 es un diagrama 400 que ilustra una relación de VN desde la perspectiva de diferentes entidades en la arquitectura PCEP 100, 200 de las FIGS. 1 -2. La VN 450 en la FIG. 4 es similar a la VN 250, 350 en las FIGS. 2-3. La Vista del CNC en la FIG. 4 representa la vista desde la perspectiva del CNC 106, 206 de las FIGS. 1 -2. Desde la Vista del CNC, el CNC visualiza la VN 450 como una colección de miembros de la VN 460 (p. ej., los extremos 118, 218 de las FIGS 1-2). La Vista del MDSC en la FIG. 4 representa la vista desde la perspectiva del MDSC 108, 208 de las FIGS. 1-2. Desde la Vista del MDSC, el MDSC visualiza la VN 450 como una colección de túneles de extremo a extremo 470 (p. ej., los túneles de extremo a extremo 102, 202 de las FIGS. 1-2). La Vista del PNC en la FIG. 4 representa la vista desde la perspectiva del PNC 110, 210 de las FIGS. 1 -2. Desde la Vista del PNC, el PNC visualiza la VN 450 como una colección de rutas de red 480 (p. ej., LSPs) utilizadas para formar, de manera colectiva, los túneles de extremo a extremo.
En referencia de nuevo a la FIG. 2, después de que el CNC 206 haya creado la VN 250, el CNC 206 envía un mensaje de instancia de VN (según lo representado por las flechas) al MDSC 208. El mensaje de instancia de VN es una solicitud del CNC 206 para que el MDSC 208 implemente la VN 250. Una vez que la solicitud es recibida, el MDSC 208 mapea la VN 250 a los recursos disponibles en base a las restricciones de la red como, por ejemplo, Calidad de Servicio (QoS), ancho de banda, y así. Después de que la VN 250 se haya mapeado a los recursos disponibles en base a las limitaciones de la red, el MDSC 208 envía un mensaje (según lo representado por las flechas) a los PNCs 210 que da instrucciones a los PNCs 210 que gestionan los dominios 204 para configurar las diversas rutas de red necesarias para formar los túneles de extremo a extremo 202 correspondientes a la VN 250. Los PNCs 210 realizan esta operación comunicándose con los extremos 218 y/o routers de frontera 270 dispuestos en los dominios 204. Una vez que se han establecido los túneles de extremo a extremo 202, los extremos 218 y/o los routers de frontera 270 envían un mensaje a los PNCs 210 (según lo representado por las flechas) para indicar que se han establecido los túneles de extremo a extremo 202. De manera similar, los PNCs 210 envían un mensaje al MDSC 208 y el MDSC 208 envía un mensaje al CNC 206 para reportar que se han establecido los túneles de extremo a extremo 202 de una manera correspondiente a la VN 250 creada por el CNC 206.
Desafortunadamente, en el proceso representado por la FIG. 2, las rutas de red (p. ej., LSPs) utilizadas para formar los túneles de extremo a extremo 202 no están asociadas o vinculadas a la VN 250. En otras palabras, no existe relación entre la VN 250 y las rutas de red utilizadas para formar, de forma colectiva, los túneles de extremo a extremo 202.
Se describe en la presente memoria un método, y un aparato, que establecen una relación entre una VN y conjuntos de LSPs cuando se establecen los túneles de extremo a extremo que se extienden a través de múltiples dominios. En otras palabras, la VN está vinculada o asociada con una o más LSPs que forman una parte de los túneles de extremo a extremo. La relación vinculante puede lograrse utilizando Extensiones PCEP o un modelo de datos (p. ej., el modelo de datos Yang). Cuando las VNs están vinculadas a LSPs, los clientes pueden organizar la VN que crean desde una perspectiva de servicio. Además, los operadores pueden organizar las LSPs asociadas con la VN del cliente sin problemas y de manera eficiente sobre redes de dominio múltiple desde una perspectiva de red.
La FIG. 5 es un diagrama que representa una realización de un procedimiento PCInitiate utilizado dentro del contexto de una arquitectura PCEP 500 para vincular las VNs a las rutas de red para cada dominio cuando está creada la ruta de extremo a extremo. La arquitectura PCEP 500 de la FIG. 5 es similar a la arquitectura PCEP 100, 200 de las FIGS.
1-2. La arquitectura PCEP 500 de la FIG. 5 incluye por ejemplo, un CNC 506, un P-PCE 508, y al menos un C-PCE 510 para cada uno de los dominios 504 (Dominio1, Dominio2, y Dominio3 individualmente etiquetados) a través de los cuales pasa el túnel de extremo a extremo 502. El CNC 506, el P-PCE 508, los C-PCEs 510, los dominios 504, y el túnel de extremo a extremo 502 son similares al CNC 106, 206, al MDSC 108, 208, al PNC 110, 210, a los dominios 104, 204, y al túnel de extremo a extremo 102, 202 de las FIGS. 1-2. Como se muestra, varios túneles de extremo a extremo 502 (Túnel1, Túnel2, y Túnel3 individualmente etiquetados) se extienden entre diferentes extremos 518 en los diversos dominios 504. Los extremos 518 de la FIG. 5 son similares a los extremos 118, 218 de las FIGS. 1-2. Como se muestra, uno o más routers de frontera 570 pueden estar dispuestos entre los extremos 518 y ser incluidos en uno o más de los túneles de extremo a extremo 502. Para facilitar la descripción, los routers de frontera 570 y los extremos 518 en la FIG. 5 han sido etiquetados individualmente como 1.A, 1.B, 1.C, 2.A, 2.B, 2.C, y 3.A, 3.B, 3.C.
Después de que el CNC 506 haya creado la VN 550 (etiquetada como VN1), el CNC 506 envía un mensaje PCInitiate (según lo representado por las flechas) al P-PCE 508. El mensaje PCInitiate es una solicitud del CNC 506 para que el P-PCE 508 implemente la VN 550. Una vez que la solicitud es recibida, el P-PCE 508 mapea la VN 550 a los recursos disponibles en base a las restricciones de la red como, por ejemplo, Calidad de Servicio (QoS), ancho de banda, y así. Después de que la VN 550 se haya mapeado a los recursos disponibles en base a las limitaciones de la red, el P-PCE 508 envía un mensaje (según lo representado por las flechas) a los C-PCEs 510 que da instrucciones a los C-PCEs 510 que gestionan los dominios 504 para configurar las diversas rutas de red necesarias para formar los túneles de extremo a extremo 502 correspondientes a la VN 550. Los C-PCEs 510 realizan esta operación comunicándose con los extremos 518 y/o routers de frontera 570 dispuestos en los dominios 504. Una vez que se han establecido los túneles de extremo a extremo 502, los extremos 518 y/o los routers de frontera 570 envían un mensaje a los C-PCEs 510 (según lo representado por las flechas) para indicar que se han establecido los túneles de extremo a extremo 502. De manera similar, los C-PCEs 510 envían un mensaje al P-PCE 508 y el P-PCE 208 envía un mensaje al CNC 506 para reportar que se han establecido los túneles de extremo a extremo 502 de una manera correspondiente a la VN 550 creada por el CNC 506.
A diferencia del procedimiento utilizado en la FIG. 2, el procedimiento de la FIG. 5 vincula cada una de las rutas de red en los dominios 504 a la VN 550. Por ejemplo, un mensaje (o mensajes) PCInitiate se utiliza para vincular LSP1 (1.A-2.A) a VN1 y LSP2 (1.A-2.B) a VN1 para el Dominio1. Del mismo modo, un mensaje (o mensajes) PCInitiate se utiliza para vincular LSP1 (2.A-3.A) a VN1, LSP2 (2.B-2.D) a VN1, y LSP3 (2.D-3.C) a VN1 para el Dominio2. Además, un mensaje (o mensajes) PCInitiate se utiliza para vincular LSP1 (3.A-3.B) a VN1 y LSP3 (3.C-3.B) a VN1 para el Dominio3. De manera colectiva, se utilizan una o más de las LSPs vinculadas a, o asociadas con, la VN1 para formar los túneles de extremo a extremo 502.
Debido a la relación que se establece entre VN1 y cada una de las LSPs, los clientes son capaces de organizar su VN eficientemente desde una perspectiva de servicio, mientras que los operadores pueden organizar sin problemas y de manera eficiente las LSPs asociadas con la VN desde una perspectiva de red.
Para facilitar la relación vinculante señalada anteriormente, se define un nuevo tipo de objeto de asociación opcional en base al objeto de asociación genérico denominado en la presente memoria como el VNAG. Además, también se define un nuevo tipo de asociación denominada “Tipo de Asociación de VN” que tiene un valor predeterminado. El alcance y el manejo del identificador del VNAG son similares al del identificador de asociación genérico definido en el IETF del Grupo de Asociación. La FIG. 6 ilustra un objeto del VNAG 600 para la versión 4 del Protocolo de Internet (IPv4) y otro para la versión 6 del Protocolo de Internet (IPv6). Cada uno de los objetos del VNAG 600, 602 incluye un campo Tipo de Asociación 604 que transporta un valor a determinar (TBD). Mientras que el valor se representa en la FIG. 6 como TBD1, debe reconocerse que el valor puede ser cualquier valor predeterminado. En una realización, el valor puede ser asignado por la Autoridad de Asignación de Números de Internet (IANA) u otra autoridad.
La inclusión del valor de TBD1 (que puede ser cualquier valor predeterminado) dentro del campo Tipo de Asociación 604 señala o indica que el campo Opcional valores de longitud tipo (TLVs) 606 contiene un nuevo TLV 608 que incluye un identificador de red virtual 610. En una realización, el identificador de red virtual 608 es un Nombre de Red Virtual, un ID de Red Virtual, o algún otro identificador adecuado. El identificador de red virtual 608 se utiliza dentro del nuevo TLV 608, por ejemplo, para vincular una VN y una ruta de red utilizada para generar un túnel. Por ejemplo, el identificador de red virtual 608 se utiliza para vincular la VN1 como se muestra en la FIG. 5 a LSP1 (1.A-2.A) etcétera como se describió anteriormente.
La definición para los otros campos en los formatos de objeto del VNAG de la FIG. 6 se proporciona en el IETF del Grupo de Asociación. En una realización, las limitaciones de la red como QoS, ancho de banda, y similares, pueden incluirse en los otros campos del objeto del VNAG 600. El campo de longitud puede ser variable en longitud.
El documento RFC6805 del RFC titulado, “Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS”, por D. King, et al., publicado en Noviembre del 2012, describe una arquitectura PCE Jerárquica (H-PCE) utilizada para calcular rutas de extremo a extremo (E2E o e2e) para TE de Conmutación de Etiquetas Multiprotocolo (MPLS) entre dominios y LSPs de Conmutación de Etiquetas Multiprotocolo Generalizada (GMPLS). Dentro de la arquitectura H-PCE, el PCE padre se utiliza para calcular una ruta de dominio múltiple en base a la información de conectividad del dominio. Un PCE hijo puede ser responsable de un solo dominio o de múltiples dominios, y se utiliza para calcular la ruta dentro del dominio en base a su información de topología del dominio.
El borrador del IETF titulado, “Hierarchical Stateful Path Computation Element (PCE)”, por D. Dhody, et al., publicado en Febrero del 2016, describe consideraciones generales para PCE(s) con estado en una arquitectura H-PCE. En particular, los cambios de comportamiento y las incorporaciones a los mecanismos de PCE con estado existentes en el contexto de una arquitectura H-PCE.
En la arquitectura H-PCE con Estado, el P-PCE recibe una solicitud de creación de red virtual de su cliente sobre su Interfaz de Programación de Aplicación (API) Ascendente. Esta VN se identifica de forma única por un ID de Asociación en el VNAG así como por el nombre de RED-VIRTUAL. Esta VN puede comprender múltiples LSPs en la red en un solo dominio o a través de múltiples dominios.
Siempre que ocurran cambios con la LSP instanciada en una red de dominio, el PCE hijo del dominio o el PNC reporta los cambios utilizando un Mensaje PCRpt 702 según lo representado por el proceso 700 en la FIG. 7. La arquitectura en la FIG. 7 es similar a la arquitectura en las FIGS. 1, 2, y 5, por lo tanto, en aras de la brevedad no se repetirá. El Mensaje PCRpt 702 incluye el Objeto del VNAG 600, 602 de la FIG. 6 para indicar la relación entre las LSPs y la VN.
Siempre que ocurra una actualización (p. ej., el ancho de banda (B/W o BW) se incrementa para los tres túneles) con las VNs en el P-PCE o en el MDSC (a través de una solicitud del cliente), el P-PCE o el MDSC envía un Mensaje PCUpd 802 según lo representado por el proceso 800 en la FIG. 8. El Mensaje PCUpd 802 se utiliza para informar a cada uno de los PCE hijo o PNC afectados por los cambios. El Mensaje PCUpd incluye el Objeto del VNAG 600, 602 de la FIG. 6. El Mensaje PCUpd 802 se denomina actualización porque se envía después de que los túneles de extremo a extremo se hayan establecido utilizando el procedimiento PCInitiate descrito anteriormente.
Si un interlocutor del PCEP recibe el objeto del VNAG 600, 602 sin el identificador de VN (p. ej., un TLV de RED VIRTUAL), un mensaje PCErr con Tipo de Error = 6 (falta el objeto obligatorio) y Valor de Error = TBD3 (falta el TLV de RED VIRTUAL) se envía y se termina la sesión.
La FIG. 9 es un modelo de datos 900 consistente con el lenguaje de modelado de datos propuesto en el documento 6020 de RFC del IETF. En una realización, el proceso de vinculación descrito en la presente memoria puede implementarse utilizando el modelo de datos 900 de la FIG. 9. En dicha realización, un mensaje que contiene la información descrita en el modelo de datos 900 se transmite y/o se recibe en lugar de transmitir y/o recibir el mensaje PCInitiate como se describió anteriormente. En otras palabras, cada segmento de la ruta de red utilizado para crear los túneles de extremo a extremo puede vincularse a la VN transmitiendo un mensaje que contiene la información descrita en el modelo de datos 900. En una realización, el modelo de datos 900 incluye una definición de punto de acceso 902, una definición de VN 904, una Asociación del Miembro de VN con puntos de Acceso 906, Características del Servicio de VN 908, una Preferencia de Servicio/Política de VN 910, y Datos de Rendimiento del Miembro de VN 912. También puede incluirse otra información en el modelo de datos.
La FIG. 10 es un método 1000 para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios utilizando un elemento de red. El método 1000 puede ser realizado cuando se van a establecer los túneles de extremo a extremo correspondientes a una VN creada por un cliente. En una realización, el método 1000 puede ser realizado por un Controlador Definido por Software (SDN), por un MDSC, o por un P-PCE (p. ej., el P-PCE 508 de la FIG. 5). En el paso 1002, se recibe una solicitud de un controlador de cliente para implementar una VN creada por el controlador de cliente. La VN identifica los túneles de extremo a extremo. En el paso 1004, la VN se mapea a los recursos disponibles en base a las limitaciones de la red en respuesta a la solicitud. En el paso 1006, se transmite un Mensaje PCInitiate a un controlador de red que gestiona uno de los dominios. El dominio incluye una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo. El Mensaje PCInitiate incluye un objeto de asociación que tiene un campo de TLV que contiene un identificador de red virtual que vincula la ruta de red a la VN.
La FIG. 11 es un método 1100 para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios implementado por un controlador de red que gestiona uno de los dominios. El método 1100 puede ser realizado cuando se van a establecer los túneles de extremo a extremo correspondientes a una VN creada por un cliente. En una realización, el método 1100 puede ser realizado por un PNC o por un C-PCE (p. ej., el C-PCE 510 de la FIG. 5). En el paso 1102, se recibe un Mensaje PCInitiate de un primer elemento de red (p. ej., un MDSC o un P-PCE) que fue dado instrucciones por un controlador de cliente (p. ej., un CNC) para implementar una VN que incluye los túneles de extremo a extremo. El mensaje PCInitiate incluye un objeto de asociación que tiene un campo de t Lv que contiene un identificador de red virtual que vincula una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo a la VN. En el paso 1104, un router de frontera que gestiona el dominio se da instrucciones para establecer la ruta de red utilizada para formar la parte de uno de los túneles de extremo a extremo.
Los componentes de red descritos anteriormente pueden implementarse en cualquier componente de red de propósito general, como un ordenador o un componente de red con suficiente potencia de procesamiento, recursos de memoria, y capacidad de rendimiento de red para manejar la carga de trabajo necesario que se le asigna. La FIG. 12 es un diagrama esquemático de un dispositivo de red 1200 según una realización de la descripción. El dispositivo 1200 es adecuado para implementar las realizaciones descritas como se describe en la presente memoria. El dispositivo 1200 comprende puertos de entrada 1210 y unidades receptoras (Rx) 1220 para recibir datos; un procesador, unidad lógica, o unidad de procesamiento central (CPU) 1230 para procesar los datos; unidades transmisoras (Tx) 1240 y puertos de salida 1250 para transmitir los datos; y una memoria 1260 para almacenar los datos. El dispositivo 1200 puede también comprender componentes de óptico a eléctrico (OE) y componentes de eléctrico a óptico (EO) acoplados a los puertos de entrada 1210, a las unidades receptoras 1220, a las unidades transmisoras 1240, y a los puertos de salida 1250 para la salida o entrada de señales ópticas o eléctricas.
El procesador 1230 es implementado por hardware y software. El procesador 1230 puede ser implementado como uno o más chips de CPUs, núcleos (p. ej., como un procesador de múltiples núcleos), matrices de puertas programables de campo (FPGAs), circuitos integrados de aplicación específica (ASICs), y procesadores de señal digital (DSPs). El procesador 1230 está en comunicación con los puertos de entrada 1210, con las unidades receptoras 1220, con las unidades transmisoras 1240, con los puertos de salida 1250, y con la memoria 1260. El procesador 1230 comprende un módulo vinculante 1270. El módulo vinculante 1270 implementa las realizaciones descritas como se describe anteriormente. Por ejemplo, el módulo vinculante 1270 genera o facilita la transmisión de los mensajes que transportan el mensaje PCInitiate, o el modelo de datos que tiene el identificador de red virtual que vincula las rutas de red a la VN. Por lo tanto, la inclusión del módulo vinculante 1270 proporciona una mejora sustancial a la funcionalidad del dispositivo 1200 y efectúa una transformación del dispositivo 1200 a un estado diferente. Alternativamente, el módulo vinculante 1270 se implementa como instrucciones almacenadas en la memoria 1260 y ejecutadas por el procesador 1230.
La memoria 1260 comprende uno o más discos, unidades de cinta, y unidades de estado sólido y puede ser utilizada como un dispositivo de almacenamiento de datos de desbordamiento, para almacenar programas cuando dichos programas son seleccionados para su ejecución, y para almacenar instrucciones y datos que son leídos durante la ejecución del programa. La memoria 1260 puede ser volátil y no volátil y puede ser memoria de solo lectura (ROM), memoria de acceso aleatorio (RAM), memoria ternaria de contenido direccionable (TCAM), y memoria estática de acceso aleatorio (SRAM).
La FIG. 13 ilustra un aparato 1300 configurado para implementar uno o más de los métodos descritos en la presente memoria, como por ejemplo, el método 1000 de la FIG. 10. El aparato 1300 comprende medios 1302 para recibir una solicitud de un controlador de cliente para implementar una red virtual (VN) creada por el controlador de cliente, donde la VN identifica los túneles de extremo a extremo que se extienden a través de múltiples dominios, medios para mapear 1304 la VN a los recursos disponibles en base a las limitaciones de la red en respuesta a la solicitud, y medios para transmitir 1306, después de que la VN se haya mapeado, un mensaje a un controlador de red que gestiona uno de los dominios que incluye una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo, donde el mensaje incluye un objeto de asociación que tiene un campo de Valor de Longitud Tipo (TLV) que contiene un identificador de red virtual que vincula la ruta de red a la VN.
La FIG. 14 ilustra un aparato 1400 configurado para implementar uno o más de los métodos descritos en la presente memoria, como por ejemplo, el método de la FIG. 11. El aparato 1400 comprende medios para recibir 1402 un mensaje de un primer elemento de red que fue dado instrucciones por un controlador de cliente para implementar una red virtual (VN) que incluye los túneles de extremo a extremo, donde el mensaje incluye un objeto de asociación que tiene un campo de Valor de Longitud Tipo (TLV), que contiene un identificador de red virtual que vincula una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo a la VN, y medios para dar instrucciones 1404 a un router de frontera que gestiona el dominio para establecer la ruta de red utilizada para formar la parte de uno de los túneles de extremo a extremo.
Se describe en la presente memoria un elemento de red configurado para establecer túneles de extremo a extremo que se extienden a través de múltiples dominios. El elemento de red incluye medios para recibir una solicitud de un controlador de cliente para implementar una red virtual (VN) creada por el controlador de cliente, en donde la VN identifica los túneles de extremo a extremo, medios para mapear la VN a los recursos disponibles en base a las limitaciones de la red, y medios para transmitir un mensaje a un controlador de red que gestiona uno de los dominios que incluye una ruta de red utilizada para formar una parte de uno de los túneles de extremo a extremo, en donde el mensaje incluye un identificador de red virtual que vincula la ruta de red a la VN.
Si bien se han proporcionado varias realizaciones en la presente descripción, debe entenderse que los sistemas y métodos descritos podrían ser incorporados en muchas otras formas específicas sin apartarse del alcance de la presente descripción. Los presentes ejemplos deben considerarse como ilustrativos y no restrictivos, y la intención no debe limitarse a los detalles proporcionados en la presente memoria. Por ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o ciertas características pueden omitirse, o no implementarse.
Además, las técnicas, sistemas, sub-sistemas, y métodos descritos e ilustrados en las diversas realizaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas, o métodos sin apartarse del alcance de la presente descripción. Otros elementos mostrados o comentados como acoplados, o directamente acoplados o que se comunican entre sí, pueden ser acoplados indirectamente o comunicarse a través de alguna interfaz, dispositivo, o componente intermedio, ya se eléctricamente, mecánicamente, o de otra manera. Otros ejemplos de cambios, sustituciones, y alteraciones pueden ser determinados por expertos en la técnica y podrían hacerse sin apartarse del alcance definido en las reivindicaciones.

Claims (15)

REIVINDICACIONES
1. Un método (1000) para establecer un túnel de extremo a extremo que se extiende a través de múltiples dominios utilizando un elemento de red, que comprende:
asociar (1004) una red virtual (VN) con los recursos disponibles en base a las limitaciones de la red, en donde la VN está asociada con el túnel de extremo a extremo; y
transmitir (1006) un mensaje a un controlador de red que gestiona un dominio de los múltiples dominios, en donde el dominio incluye una ruta de red que forma una parte del túnel de extremo a extremo, y
el mensaje incluye un objeto de asociación que contiene un identificador de red virtual que vincula la ruta de red a la VN.
2. El método de la reivindicación 1, en donde antes de la asociación de la VN con los recursos disponibles en base a las limitaciones de la red, que comprende además:
recibir (1002), una solicitud de un controlador de cliente para implementar la VN.
3. El método de cualquiera de las reivindicaciones 1 ó 2, en donde las limitaciones de la red comprenden una de calidad de servicio (QoS) y de ancho de banda.
4. El método de una cualquiera de las reivindicaciones 1 a 3, que comprende además recibir, desde el controlador de red, un mensaje de reporte que indica un estado de la ruta de red gestionada por el controlador de red.
5. Un método (1100) para establecer un túnel de extremo a extremo que se extiende a través de múltiples dominios implementado por un controlador de red que gestiona un dominio de los múltiples dominios, que comprende: recibir (1102) un mensaje de un primer elemento de red, en donde:
el dominio incluye una ruta de red que forma una parte del túnel de extremo a extremo, y
el mensaje incluye un objeto de asociación que contiene un identificador de red virtual que vincula la ruta de red a una red virtual, VN;
dar instrucciones (1104) a un dispositivo que gestiona el dominio para establecer la ruta de red que forma la parte del túnel de extremo a extremo.
6. El método de la reivindicación 5, que comprende además recibir una indicación del dispositivo de que se ha establecido la ruta de red.
7. El método de la reivindicación 5 ó 6, que comprende además recibir un segundo mensaje del primer elemento de red, en donde el segundo mensaje incluye el objeto de asociación que contiene el identificador de red virtual que vincula una segunda ruta de red que forma otra parte del túnel de extremo a extremo a la VN.
8. Un elemento de red (108, 208, 508) configurado para establecer un túnel de extremo a extremo (102, 202, 502) que se extiende a través de múltiples dominios (104, 204, 504), que comprende:
una memoria que comprende instrucciones; y
un procesador en comunicación con la memoria, en donde el procesador se configura para ejecutar las instrucciones para:
asociar una red virtual, VN (250, 350, 450, 550), con los recursos disponibles en base a las limitaciones de la red, en donde la VN está asociada con el túnel de extremo a extremo; y
transmitir un mensaje a un controlador de red que gestiona un dominio de los múltiples dominios, en donde: el dominio incluye una ruta de red que forma una parte del túnel de extremo a extremo, y
el mensaje incluye un objeto de asociación que contiene un identificador de red virtual que vincula la ruta de red a la VN.
9. El elemento de red de la reivindicación 8 en donde el procesador se configura además para ejecutar las instrucciones para:
recibir, antes de que el procesador asocie la VN con los recursos disponibles en base a las limitaciones de la red, una solicitud de un controlador de cliente (106, 206, 506) para implementar la VN.
10. El elemento de red de la reivindicación 8 ó 9, en donde
el elemento de red es un Coordinador de Servicio de Dominio Múltiple (MDSC) y el controlador de red es un Controlador de Red de Proveedor (PNC); o
el elemento de red es un Elemento de Cálculo de Ruta Padre (P-PCE) y el controlador de red es un PCE Hijo; o el elemento de red es un controlador de Red Definido por Software (SDN).
11. El elemento de red de una cualquiera de las reivindicaciones 8 a 10, en donde el mensaje es un Mensaje PCInitiate.
12. El elemento de red de una cualquiera de las reivindicaciones 8 a 11, en donde el objeto de asociación es un objeto del Grupo de Asociación de Red Virtual (VNAG).
13. Un controlador de red (110, 210, 510) configurado para establecer un túnel de extremo a extremo (102, 202, 502) que se extiende a través de múltiples dominios (104, 204, 504), en donde el controlador de red gestiona un dominio de los múltiples dominios, que comprende:
una memoria que comprende instrucciones; y
un procesador en comunicación con la memoria, en donde el procesador se configura para ejecutar las instrucciones para:
recibir un mensaje de un primer elemento de red, en donde:
el dominio incluye una ruta de red que forma una parte del túnel de extremo a extremo, y
el mensaje incluye un objeto de asociación que contiene un identificador de red virtual que vincula la ruta de red a una red virtual, VN (250, 350, 450, 550), en donde la VN está asociada con el túnel de extremo a extremo;
dar instrucciones a un dispositivo que gestiona el dominio para establecer la ruta de red que forma la parte del túnel de extremo a extremo.
14. El controlador de red de la reivindicación 13, en donde
el primer elemento de red es un Coordinador de Servicio de Dominio Múltiple (MDSC) y el controlador de red es un Controlador de Red de Proveedor (PNC); o
el primer elemento de red es un Elemento de Cálculo de Ruta Padre (P-PCE) y el controlador de red es un PCE Hijo; o
el primer elemento de red es un controlador de Red Definido por Software (SDN).
15. El controlador de red de la reivindicación 13 ó 14, en donde el objeto de asociación es un objeto del Grupo de Asociación de Red Virtual (VNAG).
ES19154446T 2016-01-11 2016-12-30 Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales Active ES2812478T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662277389P 2016-01-11 2016-01-11
US15/346,423 US10200253B2 (en) 2016-01-11 2016-11-08 Method of establishing relationships between sets of label switched paths and virtual networks

Publications (1)

Publication Number Publication Date
ES2812478T3 true ES2812478T3 (es) 2021-03-17

Family

ID=59310757

Family Applications (1)

Application Number Title Priority Date Filing Date
ES19154446T Active ES2812478T3 (es) 2016-01-11 2016-12-30 Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales

Country Status (6)

Country Link
US (3) US10200253B2 (es)
EP (3) EP3731467B1 (es)
JP (3) JP6513880B2 (es)
CN (1) CN107710693B (es)
ES (1) ES2812478T3 (es)
WO (1) WO2017121247A1 (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11962486B2 (en) 2016-06-06 2024-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Determining a path in a communication network

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10200253B2 (en) * 2016-01-11 2019-02-05 Futurewei Technologies, Inc. Method of establishing relationships between sets of label switched paths and virtual networks
US10771285B2 (en) * 2016-07-05 2020-09-08 Cisco Technology, Inc. Method and apparatus for mapping network data models
US10411964B2 (en) * 2016-09-09 2019-09-10 Huawei Technologies Co., Ltd. Method and apparatus for network slicing
WO2018210433A1 (en) * 2017-05-19 2018-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for path computation in a telecommunications network
EP3636038B1 (en) 2017-06-06 2021-08-25 Telefonaktiebolaget LM Ericsson (publ) Methods for establishing a connection between a neutral host network and one or more virtual radio access networks and corresponding devices
US10374831B2 (en) * 2017-08-29 2019-08-06 Futurewei Technologies, Inc. Stitching multi-domain LSPs in hierarchical SDN architecture
US10616106B2 (en) * 2017-12-06 2020-04-07 Futurewei Technologies, Inc. Establishing virtual network routes in a computer network
CN114401219A (zh) 2017-12-13 2022-04-26 华为技术有限公司 共享网络资源的通信方法、装置及系统
EP3725044B1 (en) * 2017-12-13 2022-04-06 Telefonaktiebolaget LM Ericsson (publ) Actn virtual network augmentation for resource sharing
US10771312B2 (en) * 2018-02-28 2020-09-08 Zte Corporation Failure detection in a data network
CN110958168B (zh) * 2018-09-26 2022-03-08 中兴通讯股份有限公司 跨域双向隧道创建方法、通信方法及装置、存储介质
CN113228592B (zh) * 2019-03-22 2022-07-22 华为技术有限公司 提供传输上下文和路径上元数据以支持启用5g的网络的方法和装置
CN114553707B (zh) * 2020-11-26 2023-09-15 腾讯科技(深圳)有限公司 网络的拓扑信息的生成和网络故障的定界方法、装置
CN114650250A (zh) * 2020-12-18 2022-06-21 中国移动通信有限公司研究院 双向段路由隧道的处理方法、装置、管控系统及网络设备

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7586841B2 (en) * 2005-05-31 2009-09-08 Cisco Technology, Inc. System and method for protecting against failure of a TE-LSP tail-end node
US7710872B2 (en) * 2005-12-14 2010-05-04 Cisco Technology, Inc. Technique for enabling traffic engineering on CE-CE paths across a provider network
US8072879B2 (en) * 2006-02-03 2011-12-06 Cisco Technology, Inc. Technique for determining whether to reestablish fast rerouted primary tunnels based on backup tunnel path quality feedback
US8208372B2 (en) * 2006-06-02 2012-06-26 Cisco Technology, Inc. Technique for fast activation of a secondary head-end node TE-LSP upon failure of a primary head-end node TE-LSP
JP4602950B2 (ja) * 2006-08-08 2010-12-22 日本電信電話株式会社 Vpnサービス管理方法
US8355315B2 (en) * 2006-11-27 2013-01-15 Cisco Technology, Inc. Failure protection for P2MP tunnel tail-end node
US7701940B2 (en) * 2007-03-09 2010-04-20 Cisco Technology, Inc. Inter-domain point-to-multipoint path computation in a computer network
EP2274879A1 (en) 2008-03-28 2011-01-19 Telefonaktiebolaget LM Ericsson (publ) End-to-end inter-domain routing
CN101631072B (zh) * 2008-07-17 2012-04-04 华为技术有限公司 一种伪线建立方法、装置和系统
JP5083168B2 (ja) 2008-10-17 2012-11-28 富士通株式会社 擬似ワイヤの設定方法及び装置
US8848712B2 (en) * 2009-08-10 2014-09-30 Infinera Corporation Distributed RSVP-TE in a multi-chassis node architecture
CN101997765B (zh) * 2009-08-13 2015-01-28 中兴通讯股份有限公司 多层网络中转发邻接的属性继承方法及相应的多层网络
CN102170392A (zh) * 2010-02-26 2011-08-31 中兴通讯股份有限公司 关联的双向标签交换路径的创建方法及系统
CN101883048B (zh) 2010-06-25 2012-10-10 陶洋 多维网络的路由方法
US9184983B2 (en) * 2010-08-26 2015-11-10 Futurewei Technologies, Inc. Cross-stratum optimization protocol
US9019865B2 (en) * 2011-03-04 2015-04-28 Juniper Networks, Inc. Advertising traffic engineering information with the border gateway protocol
US8817591B2 (en) * 2012-06-15 2014-08-26 Cisco Technology, Inc. Inter-domain signaling to update remote path computation elements after a call set-up failure
US9300564B2 (en) * 2012-06-15 2016-03-29 Cisco Technology, Inc. Ordered flooding requests for path computation elements
US9065750B2 (en) * 2012-06-15 2015-06-23 Cisco Technology, Inc. Congestion-based notification during fast reroute operations in stateful path computation element environments
US8750310B2 (en) * 2012-07-03 2014-06-10 Cisco Technology, Inc. Signaling co-routed and non co-routed LSPs of a bidirectional packet TE tunnel
US8891375B2 (en) 2012-08-02 2014-11-18 Cisco Technology, Inc. System and method for virtual Ethernet interface binding
US9369371B2 (en) * 2012-10-05 2016-06-14 Cisco Technologies, Inc. Method and system for path monitoring using segment routing
US8693374B1 (en) * 2012-12-18 2014-04-08 Juniper Networks, Inc. Centralized control of an aggregation network with a reduced control plane
US9100285B1 (en) * 2012-12-18 2015-08-04 Juniper Networks, Inc. Dynamic control channel establishment for software-defined networks having centralized control
CN103916302B (zh) 2013-01-04 2017-03-15 上海贝尔股份有限公司 向虚拟wlan提供sdn流路径的方法和设备
CN103051565B (zh) 2013-01-04 2018-01-05 中兴通讯股份有限公司 一种等级软件定义网络控制器的架构系统及实现方法
US9537769B2 (en) * 2013-03-15 2017-01-03 Cisco Technology, Inc. Opportunistic compression of routing segment identifier stacks
US9276833B2 (en) * 2013-07-24 2016-03-01 Cisco Technology, Inc. Path-ping and ECMP-traceroute for IPv6 overlay virtualized networks
US9210075B2 (en) * 2013-10-08 2015-12-08 Ciena Corporation Method and apparatus for managing end-to-end consistency of bi-directional MPLS-TP tunnels via in-band communication channel (G-ACH) protocol
WO2015051839A1 (en) * 2013-10-09 2015-04-16 Telefonaktiebolaget L M Ericsson (Publ) Routing of point-to-multipoint services in a multi-domain network
US9450864B2 (en) * 2013-10-11 2016-09-20 Futurewei Technologies, Inc. Using PCE as SDN controller
US9197569B2 (en) 2013-12-06 2015-11-24 Algoblu Holdings Limited Hierarchical control in software-defined network (SDN)
US10020961B2 (en) 2013-12-27 2018-07-10 Electronics And Telecommunications Research Institute Method and apparatus for network virtualization
KR102236195B1 (ko) 2013-12-27 2021-04-07 한국전자통신연구원 네트워크 가상화 방법 및 장치
US20160006614A1 (en) * 2014-07-03 2016-01-07 Futurewei Technologies, Inc. Source Routing Using Path Computation Elements
CN108141411B (zh) * 2015-10-14 2021-06-25 瑞典爱立信有限公司 多层通信网络的控制
US10200253B2 (en) * 2016-01-11 2019-02-05 Futurewei Technologies, Inc. Method of establishing relationships between sets of label switched paths and virtual networks
US10797966B2 (en) 2017-10-29 2020-10-06 Nicira, Inc. Service operation chaining

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11962486B2 (en) 2016-06-06 2024-04-16 Telefonaktiebolaget Lm Ericsson (Publ) Determining a path in a communication network

Also Published As

Publication number Publication date
JP2018526934A (ja) 2018-09-13
EP3503478A1 (en) 2019-06-26
US11271817B2 (en) 2022-03-08
EP3731467A1 (en) 2020-10-28
CN107710693B (zh) 2020-02-21
US20180316566A9 (en) 2018-11-01
JP6999000B2 (ja) 2022-02-10
JP2019135870A (ja) 2019-08-15
JP2020188512A (ja) 2020-11-19
US20190123971A1 (en) 2019-04-25
EP3295614A4 (en) 2018-03-28
US20180131570A1 (en) 2018-05-10
EP3295614B1 (en) 2019-04-03
EP3503478B1 (en) 2020-06-03
CN107710693A (zh) 2018-02-16
WO2017121247A1 (en) 2017-07-20
JP6513880B2 (ja) 2019-05-15
JP6748258B2 (ja) 2020-08-26
US10812340B2 (en) 2020-10-20
US20210036931A1 (en) 2021-02-04
EP3731467B1 (en) 2022-02-02
US10200253B2 (en) 2019-02-05
EP3295614A1 (en) 2018-03-21

Similar Documents

Publication Publication Date Title
ES2812478T3 (es) Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales
ES2830182T3 (es) Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red
USRE47260E1 (en) System and method for point to multipoint inter-domain MPLS traffic engineering path calculation
US20160006614A1 (en) Source Routing Using Path Computation Elements
US10374831B2 (en) Stitching multi-domain LSPs in hierarchical SDN architecture
Xu Designing and implementing IP/MPLS-based Ethernet layer 2 VPN services: An advanced guide for VPLS and VLL
US11303549B2 (en) Segmented traceroute for segment routing traffic engineering
Farrel et al. An architecture for use of PCE and the PCE communication protocol (PCEP) in a network with central control
Sgambelluri et al. Experimental demonstration of multi-domain segment routing
Filsfils Network programming with srv6
Ajiardiawan et al. Performance analysis of segment routing on MPLS L3VPN using PNETLAB
Aung Implementation of traffic engineering with segment routing and opendaylight controller on emulated virtual environment next generation (EVE-NG)
Bahnasy et al. Software-defined DWDM optical networks: OpenFlow and GMPLS experimental study
Li et al. RFC 8283: An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
Garg et al. A study of performance analysis of signaling protocols in MPLS
Chaitou Enhancing the scalability of traffic engineering label switched paths
Kimani Protection Methods in Traffic Engineering MPLS Networks
Madur Analysis of GMPLS implementation
Appelman et al. Architecture of dynamic VPNs in OpenFlow