ES2830182T3 - Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red - Google Patents

Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red Download PDF

Info

Publication number
ES2830182T3
ES2830182T3 ES16820808T ES16820808T ES2830182T3 ES 2830182 T3 ES2830182 T3 ES 2830182T3 ES 16820808 T ES16820808 T ES 16820808T ES 16820808 T ES16820808 T ES 16820808T ES 2830182 T3 ES2830182 T3 ES 2830182T3
Authority
ES
Spain
Prior art keywords
service
route
tag
node
label
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
ES16820808T
Other languages
English (en)
Inventor
Qianglin Quintin Zhao
Renwei Li
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 ES2830182T3 publication Critical patent/ES2830182T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • 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]
    • H04L45/505—Cell based
    • 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/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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
    • H04L45/04—Interdomain routing, e.g. hierarchical routing
    • 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/38—Flow based routing
    • 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
    • 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]
    • H04L45/507—Label distribution
    • 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/54—Organization of routing tables
    • 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/64—Routing or path finding of packets in data switching networks using an overlay routing layer
    • 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/68—Pseudowire emulation, e.g. IETF WG PWE3
    • 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/74—Address processing for routing
    • 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/74—Address processing for routing
    • H04L45/741—Routing in networks with a plurality of addressing schemes, e.g. with both IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272—Virtual private networks
    • 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/42—Centralised routing

Landscapes

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

Abstract

Un método que comprende: recibir (910), por un controlador centralizado de elementos de cálculo de rutas, PCECC (360, 460, 560, 710), una solicitud de servicio desde un orquestador de servicios de transporte para provisionar un servicio de un primer nodo de borde a un segundo nodo de borde en una red; calcular (920), por el PCECC (360, 460, 560, 710), una ruta para una ruta conmutada por etiquetas, LSP, del primer nodo de borde al segundo nodo de borde en respuesta a la solicitud de servicio; reservar (930), por el PCECC (360, 460, 560, 710), información de etiqueta para reenviar tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de la pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio; y enviar (940), por el PCECC (360, 460, 560, 710), un mensaje de actualización de etiqueta a un tercer nodo en la ruta para facilitar el reenvío del tráfico del servicio en la ruta, en donde el mensaje de actualización de etiqueta comprende la información de etiqueta, y el mensaje de actualización de etiqueta es un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUpd.

Description

DESCRIPCIÓN
Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red
Antecedentes
Las redes de conmutación de etiquetas multiprotocolo (MPLS) están ampliamente desplegadas en redes de proveedores de servicios. Las redes de MPLS actuales son difíciles de operar y mantener debido a su uso del protocolo de distribución de etiquetas (LDP) y los protocolos de señalización MPLS de la ingeniería de tráfico (TE) del protocolo de reserva de recursos (RSVP), (RSVP-TE). Además, cada dispositivo de red en una red de MPLS necesita mantener una gran cantidad de estados para rutas conmutadas por etiquetas (LSP) establecidas. Además, nuevos servicios pueden no ser fácilmente añadidos a redes de MPLS.
Las redes definidas por software (SDN) es una arquitectura de red que desacopla el plano de control del plano de datos. El desacoplamiento permite la centralización del control de la red, permite una administración de políticas efectiva y gestión flexible. La centralización del control de la red facilita varias funcionalidades de red tales como mediciones de red, ingeniería de tráfico, calidad de servicios mejorada, y control de acceso mejorado. Además, nuevos servicios pueden ser fácilmente añadidos a las redes basadas en SDN. Así, los proveedores de servicios pueden beneficiarse de la arquitectura de SDN.
Un ejemplo de red SDN es una red OpenFlow. OpenFlow proporciona un protocolo de comunicación entre controladores de SDN y nodos de red. El protocolo OpenFlow describe mensajes intercambiados entre un controlador OpenFlow y conmutadores OpenFlow, donde el controlador OpenFlow programa los conmutadores OpenFlow con entradas de reenvío de flujo para reenvío de datos.
El documento US2015/0103844A1 se refiere a sistemas y métodos para hacer la transición de un sistema desde una red tradicional a una red habilitada para Red Definida por Software (SDN). En algunas realizaciones, los sistemas y métodos pueden comprender el uso de un Elemento de Cálculo de Rutas (PCE) como un controlador central. La transición suave entre la red tradicional y la nueva red habilitada para SDN, especialmente desde una perspectiva de evaluación de impacto de costes, puede ser lograda mediante el uso de componentes PCE existentes desde la red actual para funcionar como el controlador central de la red SDN es una opción, que no solo logra la meta de tener un controlador centralizado para proporcionar las funcionalidades necesarias para el controlador central, sino que también hace uso de los componentes de red PCE existentes.
El documento “PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs”, borrador de la Fuerza de Trabajo de Ingeniería de Internet (IETF), 2 de marzo del 2015 (“Zhao”) especifica los procedimientos y extensiones del protocolo PCEP para usar el PCE como el controlador central y casos de usuario donde las LSP se calculan/configuran/inician y las entradas de reenvío de etiquetas son descargadas a través de la extensión de las arquitecturas de PCE y PCEP existentes.
Compendio
Aunque las redes OpenFlow pueden permitir mayor flexibilidad y eficiencia, el despliegue de redes OpenFlow puede no ser práctico. Por ejemplo, para migrar una red existente a una red SDN OpenFlow, se requiere reemplazar o actualizar todos los dispositivos de red en la red a dispositivos programables de software que soportan las funcionalidades de SDN. Un enfoque para proporcionar una red basada en SDN práctica con buen rendimiento y servicios orientados a aplicación es emplear enrutamiento de segmento basada en enrutamiento origen (SR). Sin embargo, el enfoque del enrutamiento de segmento basado en SR puede estar limitado a proporcionar servicios parciales. Otro enfoque es emplear una combinación de un elemento de cálculo de rutas (PCE) con estado y una arquitectura de MPLS distribuida. Sin embargo, la complejidad del despliegue y mantenimiento de la MPLS permanece. Para resolver estos y otros problemas, como será explicado más en detalle en este documento, un controlador central de elementos de cálculo de rutas (PCECC) es usado para calcular rutas y reservar o asignar etiquetas para servicios según las solicitudes de usuarios, clientes, y aplicaciones. El PCECC descarga instrucciones de reenvío a todos los nodos de red en una red. Así, no se requiere que los nodos de red empleen los protocolos de señalización LDP y MPLS RSVP-TE, mantengan los estados de las LSP, o intercambien etiquetas del protocolo de puerta de enlace interior (IGP) y etiquetes del protocolo de puerta de enlace de frontera interior (IBGP).
En una realización, la descripción incluye un método implementado por un controlador centralizado de elementos de cálculo de rutas (PCECC), el método que comprende: recibir una solicitud de servicio desde un orquestador de servicios de transporte para provisionar un servicio de un primer nodo de borde y un segundo nodo de borde en una red; calcular una ruta para una ruta conmutada por etiquetas (LSP) del primer nodo de borde al segundo nodo de borde en respuesta a la solicitud de servicio; reservar información de etiqueta para reenviar tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio que identifica el servicio; y enviar el mensaje de actualización de etiqueta a un tercer nodo en la ruta para facilitar el reenvío del tráfico del servicio en la ruta, en donde el mensaje de actualización de etiqueta comprende la información de etiqueta. En algunas realizaciones, el servicio es un servicio de red privada virtual (VPN), y en donde la etiqueta de servicio comprende una etiqueta de VPN para identificar el servicio de VPN en la red; la etiqueta de VPN comprende un número de VPN, un nombre de VPN, o tanto un número de VPN como un nombre de VPN; el servicio es un servicio de borde a borde de emulación de pseudocable (PWE3), y en donde la etiqueta de servicio comprende una etiqueta identificador de conexión de capa de enlace de datos (DLCI) para identificar el servicio PWE3 en la red; la etiqueta de DLCI comprende un número de DLCI, un nombre de DLCI, o tanto el número de DLCI como el nombre de DLCI; el servicio es un servicio de túneles del Protocolo de Internet versión 6 (IPv6), y en donde la etiqueta de servicio comprende un tipo-longitud-valor (TLV) de dirección IPv6 que indica una dirección IPv6 asociada con el nodo de siguiente salto del tercer nodo en la ruta y una etiqueta saliente para reenviar el tráfico del servicio al nodo de siguiente salto; el servicio es un servicio de túneles del Protocolo de Internet versión 6 (IPv6), y en donde la etiqueta de servicio comprende un tipo-longitud-valor (TLV) de dirección IPv6 que indica una dirección IPv6 asociada con una interfaz entrante del tercer nodo y una etiqueta entrante asociada con la interfaz entrante; reservar la información de etiqueta comprende reservar una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN de la ruta de la LSP para facilitar el reenvío del tráfico del servicio, y en donde el tercer nodo es uno de los nodos habilitados con SDN; el método además comprende: recibir, desde un nodo no habilitado con SDN en la ruta, un mensaje de solicitud de reserva de rango de etiquetas que solicita un rango de valores de etiquetas de rutas; reservar el rango para el nodo no habilitado con SDN; y enviar, al nodo no habilitado con SDN, un mensaje de respuesta de reserva de rango de etiquetas que india el rango de valores de etiquetas de rutas reservado; el mensaje de actualización de etiqueta es un mensaje de actualización de etiqueta del protocolo de comunicación, de la comunicación de elemento de cálculo de ruta (PCE), (PCEP), (PCLabelUp).
El mensaje PCLabelUP comprende un objeto del servicio que comprende un valor o un nombre que identifica el servicio como la etiqueta de servicio.
En otra realización, la descripción incluye un controlador centralizado de elementos de cálculo de rutas (PCECC) que comprende: un receptor configurado para recibir una solicitud desde un orquestador de servicios de transporte para crear un servicio de un primer nodo de borde a un segundo nodo de borde en una red; un procesador acoplado al receptor y configurado para: calcular una ruta para una ruta conmutada por etiquetas (LSP) del primer nodo de borde al segundo nodo de borde en respuesta a la solicitud; y reservar información de etiqueta para reenviar el tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio que identifica el servicio; y un transmisor acoplado al procesador y configurado para enviar un mensaje de actualización de etiqueta a un tercer nodo en la ruta para facilitar el reenvío del tráfico del servicio en la ruta, en donde el mensaje de actualización de etiqueta comprende la información de etiqueta. En algunas realizaciones, el servicio es un servicio de red privada virtual (VPN), y en donde la etiqueta de servicio comprende una etiqueta de VPN para identificar el servicio de VPN en la red; el servicio es un servicio de borde a borde de emulación de pseudocable (PWE3), y en donde la etiqueta de servicio comprende una etiqueta identificador de conexión de capa de enlace de datos (DLCI) para identificar el servicio PWE3 en la red; el servicio es un servicio de túneles del Protocolo de Internet versión 6 (IPv6), y en donde la etiqueta de actualización del mensaje además comprende una dirección IPv6 de un nodo de salida de la LSP; el PCECC además comprende una memoria acoplada al procesador y configurada para almacenar una base de datos de ingeniería del tráfico (TEDB) que comprende información de la topología de la red, en donde el procesador está además configurado para calcular la ruta según la información de la topología en la TEDB; el PCECC además comprende una memoria acoplada al procesador y configurada para almacenar una base de datos de etiquetas (LDB) que comprende etiquetas de servicio para identificar servicios en la red, en donde le procesador está además configurado para reservar la información de etiqueta desde la LDB; el PCECC además comprende una memoria acoplada al procesador y configurada para almacenar una base de datos de LSP (LSPDB), en donde el procesador está además configurado para almacenar información de ruta asociada con la LSP en la LSPDB, y en donde la información de ruta comprende la información de etiqueta.
En aun otras realizaciones, la descripción incluye un elemento de red, NE (600), que comprende: un receptor configurado para: recibir, desde un controlador centralizado de elementos de cálculo de rutas, PCECC, un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUp, que comprende información de etiquetas para reenviar tráfico para un servicio, en donde la información de etiquetas comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en una ruta en una red excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio en la red; y recibe un paquete de datos asociado con el tráfico; un procesador acoplado al receptor y configurado para adjuntar la información de etiqueta al paquete de datos; y un transmisor (640) acoplado al procesador y configurado para reenviar el paquete de datos a un nodo de siguiente salto en la ruta según la información de etiqueta.
En aun otra realización, la descripción incluye un elemento de red (NE) que comprende: un receptor configurado para: recibir, desde un controlador centralizado de elementos de cálculo de rutas (PCECC) una instrucción de reenvío para reenviar tráfico de un servicio en una ruta conmutada por etiquetas (LSP) en una red, en donde la instrucción de reenvío indica una primera etiqueta que identifica el servicio en la red; y recibe un paquete de datos asociado con el tráfico; un procesador acoplado al receptor y configurado para adjuntar la primera etiqueta al paquete de datos; y un transmisor acoplado al procesador y configurado para reenviar el paquete de datos a un nodo de siguiente salto en una ruta de la LSP según la información de reenvío. En algunas realizaciones, el servicio es un servicio de red privada virtual (VPN), un servicio de borde a borde de emulación de pseudocable (PWE3), o un servicio de túneles del Protocolo de Internet versión 6 (IPv6); el NE es independiente de cualquier señalización de protocolo de distribución de etiquetas (LDP) o señalización de conmutación de etiquetas de multiprotocolo (MPLS) de ingeniería de protocolo de tráfico de reserva de recursos (RSVP-TE).
En aun otra realización, la descripción incluye un sistema que comprende: un controlador centralizado de elementos de cálculo de rutas (PCECC) configurado para: calcular una ruta para una ruta conmutada por etiquetas (LSP) de un primer nodo de borde a un segundo nodo de borde; reservar información de etiqueta para reenviar tráfico de un servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio que identifica el servicio; transmite un mensaje de actualización de etiqueta que comprende la información de etiqueta; un elemento de red (NE) ubicado en la ruta y configurado para: recibir el mensaje de actualización de etiqueta desde el PCECC; recibir un paquete de datos asociado con el tráfico; adjuntar la información de etiqueta al paquete de datos; y transmitir el paquete de datos a un nodo de siguiente salto en la ruta según el mensaje de actualización de ruta.
El controlador centralizado de elementos de cálculo de rutas, PCECC, está configurado para: recibir una solicitud de servicio desde un orquestador de servicios de transporte para provisionar un servicio de un primer nodo de borde a un segundo nodo de borde en una red; calcular una ruta para una ruta conmutada por etiquetas, LSP, del primer nodo de borde al segundo nodo de borde; reservar información de etiqueta para reenviar tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio; transmitir un mensaje de actualización de etiqueta que comprende la información de etiqueta, en donde el mensaje de actualización de etiqueta es un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUp; un elemento de red, NE (600), ubicado en la ruta y configurado para: recibir el mensaje de actualización de etiqueta desde el PCECC; recibir un paquete de datos asociado con el tráfico; adjuntar la información de etiqueta al paquete de datos; y transmitir el paquete de datos a un nodo de siguiente salto en la ruta según el mensaje de actualización de etiqueta.
El mensaje PCLabelUpd comprende un objeto del servicio que comprende un valor o un nombre que identifica el servicio como la etiqueta de servicio.
Cualquiera de las realizaciones anteriores puede ser combinada con cualquiera o más de las otras realizaciones anteriores para crear una nueva realización dentro del alcance de la descripción.
Estas y otras características se comprenderán más claramente a partir de la siguiente descripción detallada tomada junto con los dibujos que acompañan y reivindicaciones. La invención se expone en las reivindicaciones anexas.
Breve descripción de los dibujos
Para una comprensión más completa de esta descripción, se hace ahora referencia a la siguiente descripción breve, tomada junto con los dibujos que acompañan y descripción detallada, en donde números de referencia iguales representan partes iguales.
La FIG. 1 es un diagrama esquemático de una red de MPLS.
La FIG. 2 es un diagrama esquemático de una red borde a borde de emulación de pseudocable (PWE3) basada en MPLS.
La FIG. 3 es un diagrama esquemático de una red de MPLS que emplea un PCECC para proporcionar servicios de red privada virtual (VPN) según una realización de la descripción.
La FIG. 4 es un diagrama esquemático de una red de MPLS que emplea un PCECC para proporcionar servicios de túneles del Protocolo de Internet versión 6 (IP6v6) según una realización de la descripción.
La FIG. 5 es un diagrama esquemático de una red PWE3 basada en MPLS que emplea un PCECC para proporcionar servicios de PWE3 según una realización de la descripción.
La FIG. 6 es un diagrama esquemático de un elemento de red (NE) según una realización de la descripción.
La FIG. 7 es un diagrama esquemático de una red que comprende nodos heredados y nodos habilitados con SDN según una realización de la descripción.
La FIG. 8 es un diagrama del protocolo de un método para provisionar un servicio según una realización de la descripción.
La FIG. 9 es un diagrama de flujo de un método para provisionar un servicio según una realización de la descripción.
La FIG. 10 es un diagrama de flujo de un método para provisionar un servicio según una realización de la descripción.
La FIG. 11 es un diagrama de flujo de un método para realizar reenvío de datos en una red según una realización de la descripción.
La FIG. 12 es un diagrama esquemático de un tipo-longitud-valor (TLV) de dirección IPv6 según una realización de la descripción.
La FIG. 13 es un diagrama esquemático de un objeto de clase de equivalencia de reenvío (FEC) según una realización de la descripción.
La FIG. 14 es un diagrama esquemático de un objeto de FEC según otra realización de la descripción.
Descripción detallada
Se debería comprender al principio que, aunque se proporcionan a continuación implementaciones ilustrativas de una o más realizaciones, los sistemas y/o métodos descritos puede ser implementados mediante el uso de cualquier número de técnicas, ya sean actualmente conocidas o existentes. La descripción no debería de cualquier forma estar limitada a las implementaciones ilustrativas, dibujos, y técnicas ilustradas a continuación, que incluye los diseños ejemplares e implementaciones ilustradas y descritas en este documento, pero pueden ser modificadas dentro del alcance de las reivindicaciones anexas junto con el alcance completo de equivalentes.
La FIG. 1 es un diagrama esquemático de una red 100 de MPLS. La red 100 comprende una pluralidad de nodos 120 interconectados por una pluralidad de enlaces 130. Los nodos 120 se muestran como borde de proveedor (PE)1, proveedor (P)1, P2, enrutador de frontera de área (ABR)1, ABR2, P3, P4, ABR3, ABR4, P5, P6, y PE2. La infraestructura subyacente de la red 100 puede ser de cualquier tipo de red tal como una red eléctrica, una red óptica, o combinaciones de ellas. Los enlaces 130 pueden comprender enlaces físicos tales como enlaces de fibra óptica, enlaces eléctricos, enlaces inalámbricos, y enlaces lógicos usados para transportar datos en la red 100. La red 100 emplea una capa de transporte de protocolo de Internet (IP) y un plano de reenvío de datos MPLS. Las rutas de reenvío en la red 100 son referidas como rutas conmutadas por etiquetas (LSP). Durante el reenvío, los paquetes de datos son dirigidos a lo largo de una LSP basado en etiquetas de rutas o etiquetas de segmentos adjuntas a los paquetes de datos, como se describe más completamente a continuación. La red 100 puede ser una red de proveedor de servicios. Diferentes partes de la red 100 operan bajo diferentes dominios 110. Los dominios 110 se muestran como dominio A, dominio B, y dominio C. Cada dominio 110 puede ser operado por una autoridad administrativa diferente y puede emplear una política diferente para acceder y seguridad.
Los nodos 120 son cualquier dispositivo o componente tal como enrutadores y conmutadores configurados para realizar tanto señalización de MPLS tal como LDP o RSVP-TE para establecer LSP en la red 100 como reenvío de datos a lo largo de las LSP establecidas. Los nodos PE1 y PE2 120 ubicados en bordes de la red 100 son referidos como nodos de borde o bordes de proveedor. Un nodo de borde puede conectarse a uno o más nodos fuera de la red. Como se muestra, el nodo PE1 120 está conectado a un borde de cliente (CE) 141, y el nodo PE2120 está conectado a otro CE 142. Los CE 141 y 142 son dispositivos de red ubicados en sitios de cliente externos a la red 100. Los CE 141 y 142 puede originar y/o terminar tráfico de cliente. Un nodo de borde que recibe tráfico desde un CE es referido como un nodo de entrada. Un nodo de borde que envía tráfico a un CE es referido como un nodo de salida. Los nodos P1, P2, P3, P4, P5 y P6 120 ubicados internamente dentro los dominios 110 correspondientes son referidos como nodos internos. Cada uno de los nodos P1, P2, P3, P4, P5, y P6 120 reenvían tráfico dentro de un dominio 110 correspondiente. Los nodos ABR1, ABR2, ABR3, y ABR4 120 ubicados entre fronteras de múltiples dominios 110 son referidos como enrutadores de frontera de área (ABR). Los nodos ABR1 y ABR2 120 interconectan los dominios A y B 110. Los nodos ABR3 y ABR4 120 interconectan los dominios B y C 110. Los nodos ABR1, ABR2, ABR3, y ABR4 120 reenvían tráfico sobre los dominios 120 correspondientes.
La red 100 proporciona una VPN 151 para llevar tráfico desde el CE 141 al CE 142. Para crear la VPN 151, el nodo PE1 120 actúa como un nodo de entrada para calcular una ruta para una LSP desde el nodo PE1 120 al nodo PE2 120 que conecta al CE 141. La VPN 151 está superpuesta sobre la LSP y mostrada por la línea sólida gruesa. El nodo PE1 120 reserva una etiqueta de VPN para la VPN 151. La etiqueta de VPN es una etiqueta de servicio que enlaza o asocia tráfico a una VPN correspondiente. El nodo PE1 120 inicia el establecimiento de la LSP para la VPN 151 a lo lago de la ruta de la LSP mediante el intercambio de etiquetas del IBGP y el empleo de señalización RSVP-TE. Por ejemplo, cada nodo 120 a lo largo de la LSP de la VPN 151 asigna una etiqueta de ruta local desde un grupo de etiquetas locales para reenviar tráfico de la LSP y notifica al nodo de salto siguiente en una dirección hacia arriba de la etiqueta de ruta local. Hacia arriba se refiere a la dirección desde un destino a un origen. Los nodos 120 a lo largo de la ruta de la LSP entre el nodo PE1 120 de entrada y el nodo PE2 120 de salida de la LSP son referidos como nodos de tránsito. Las etiquetas de rutas dirigen el tráfico a lo largo de la LSP. Cada nodo 120 a lo largo de la ruta de la LSP recibe una etiqueta de ruta desde un nodo hacia abajo a lo largo de la ruta y establece una lista de correspondencia de etiquetas para reenviar datos. Hacia abajo se refiera a la dirección desde un origen hacia un destino .
En la operación, cuando el nodo PE1 120 recibe un paquete de datos desde el CE 141, el nodo PE1 120 analiza el paquete de datos, por ejemplo, basándose en la cabecera del paquete de datos, para determinar una FEC o una clase de tráfico para el paquete de datos. Cuando el nodo PE1 120 determina que el paquete de datos está asociado con la VPN 151, el nodo PE1 120 adjunta la etiqueta de la VPN reservada al paquete de datos para enlazar el paquete de datos a la VPN 151. Además, el nodo PE1 120 adjunta la etiqueta de ruta de un nodo de salto siguiente a lo largo de la LSP, que es el nodo P2 120, al paquete de datos para dirigir el paquete de datos a lo largo de la LSP y reenvía el paquete de datos al nodo P2 120. Por ejemplo, la etiqueta de la VPN puede ser llevada en una cabecera interior del paquete de datos, y la etiqueta de ruta puede ser llevada en una cabecera exterior del paquete de datos. Así, se refiere a la etiqueta de la VPN como una etiqueta interior y se refiere a la etiqueta de ruta como una etiqueta exterior del paquete de datos.
Cuando el nodo P2 120 recibe el paquete de datos, el nodo P2 120 reemplaza la etiqueta de ruta exterior con la etiqueta de ruta de un nodo de siguiente salto a lo largo de la LSP, que es el nodo ABR2 120, y reenvía el paquete de datos al nodo ABR2 120. Se refiere a la etiqueta de ruta en una cabecera de un paquete entrante como etiqueta entrante. Se refiere a la etiqueta de ruta en una cabecera de un paquete saliente como una etiqueta saliente. Este proceso de reenvío es repetido en cada nodo 120 a lo largo de la ruta de la LSP.
Cuando el nodo de salida de la LSP, que es el nodo PE2120, recibe el paquete de datos, el nodo PE2 120 introduce o elimina la etiqueta de ruta exterior y la etiqueta de la VNP interior y reenvía el paquete de datos al CE 142. La red 100 puede proporcionar cualquier número de VPN mediante el uso de mecanismos similares. Por ejemplo, la red 100 está además configurada para proporcionar una VPN 152 similar a la VPN 151 como se muestra por la línea discontinua gruesa. Las VPN 151 y 152 son referidas como VPN de MPLS o VPN de capa 3 (L3) (L3VPN) de interconexión de sistemas abiertos (OSI).
La FIG. 2 es un diagrama esquemático de una red 200 PWE3 basada en MPLS. La red 200 comprende una primera red 210, una red 220 de MPLS, y una segunda red 230. La primera red 210 y la segunda red 230 son redes de capa 2 (L2) OSI o redes de capa de enlace de datos tal como redes de retrasmisión de tramas orientadas a conexión que proporcionan servicios nativos. La primera red 210 comprende una pluralidad de nodos 211 interconectados mediante enlaces (no mostrados), que son similares a los enlaces 130. La segunda red 230 comprende una pluralidad de nodos 231 interconectados por enlaces (no mostrados) similares a los enlaces 130. Los nodos 211 y 231 son cualquier dispositivo o componente tal como conmutadores de retransmisión de tramas configurados para proporcionar circuitos virtuales (VC) 251 y 252 dedicados en una configuración punto a punto (P2P) para transporte de datos. El VC 251 se muestra mediante la línea discontinua gruesa. El VC 252 se muestra mediante la línea punteada gruesa. Los nodos 211 establecen partes de los VC 251 y 252 localmente en la primera red 210 y los nodos 231 establecen partes de los VC 251 y 252 en la segunda red 230. Los VC son identificados mediante identificadores de conexión de capa de enlace de datos (DLCI) 201,202. Por ejemplo, los paquetes de datos son divididos en tramas, y un DLCI se adjunta a cada trama para enlazar o asociar la trama a un VC asignado para reenvío.
La red 220 de MPLS es similar a la red 100. La red 220 de MPLS comprende una pluralidad de nodos 221 de borde y nodos 222 internos similares a los nodos 120 interconectados por enlaces (no mostrados) similares a los enlaces 130. El nodo PE1 221 de borde está conectado a la primera red 210. El nodo PE2221 de borde está conectado a la segunda red 230. La red 220 de MPLS puede además comprender nodos de borde y nodos internos adicionales y puede operar bajo uno o más dominios similares a los dominios 110. La red 220 MPLS está configurada para funcionar como pseudocables 223 y 224 para conectar los VC 251 y 252 desde la primera red 210 a la segunda red 230, respectivamente. El pseudocable 223 se muestra mediante la línea sólida gruesa. El pseudocable 224 se muestra mediante la línea discontinua punteada gruesa. Los pseudocables 223 y 224 son túneles o LSP. Los nodos 221 de borde realizan el auto descubrimiento del protocolo de puerta de enlace frontera (BGP) para descubrir otros nodos de borde en el mismo dominio MPLS.
Los VC 251 y 252 pueden funcionar como VPN para llevar tráfico desde el CE 241 a los CE 242 y 243 remotos, respectivamente. Los CE 241, 242, y 243 son similares a los CE 141 y 142. Para crear un pseudocable 223 para el VC 251, el nodo PE1 221 actúa como un nodo de entrada para calcular una ruta para una LSP desde el nodo PE1 221 al nodo PE2222 y reserva una etiqueta de DLCI para el VC 251. Los nodos 221 de borde y los nodos 222 internos a lo largo de la ruta de la LSP establecen la LSP mediante el uso de señalización LDP similar a los mecanismos descritos en la red 100.
En la operación, cuando el nodo 211 recibe un paquete de datos desde el CE 241, el nodo 211 reenvía el paquete de datos a la red 220 de MPLS a través del VC 251 en la primera red 210. Cuando el nodo PE1 221 recibe un paquete de datos desde la primera red 210, el nodo PE1 221 analiza el paquete de datos, por ejemplo, un campo DLCI en la cabecera del paquete de datos, para determinar una clase de reenvío o clase de tráfico para el paquete de datos. Cuando el nodo PE1 221 determina que el paquete de datos está asociado con el VC 251, el nodo PE1 221 adjunta la etiqueta de DLCI reservada al paquete de datos. Además, el nodo PE1 221 adjunta una etiqueta de ruta de un nodo de siguiente salto a lo largo de la LSP y reenvía el paquete de datos al nodo de siguiente salto. La etiqueta de DLCI puede ser una etiqueta interna, y la etiqueta de ruta puede ser una etiqueta externa del paquete de datos. Los nodos en la ruta de la LSP subsecuentemente reenvían el paquete de datos a lo largo de la LSP mediante el uso de mecanismos similares a los descritos en la red 100. Cuando el nodo PE2221 recibe el paquete de datos, el nodo PE2 221 elimina la etiqueta de ruta y la etiqueta de DLCI y reenvía el paquete de datos a la segunda red 230. Los nodos en el VC 251 de la segunda red 230 subsecuentemente reenvían el paquete de datos a lo largo del VC 251. Cuando el nodo B1 231 recibe el paquete de datos, el nodo B1 231 reenvía el paquete de datos al CE 242. El establecimiento y reenvío de datos en el VC 252 es similar al VC 251. Las VPN proporcionadas por los VC 251 y 252 son referidas como VPN de capa 2 (L2) (L2VPN) OSI.
Aunque los servicios de VPN y PWE3 pueden ser implementados a través de MPLS, el despliegue y mantenimiento de MPLS es complejo como se describió anteriormente. Un modelo de red centralizada como se describe en la solicitud de patente de Estados Unidos número 14/511.591 archivada el 10 de octubre del 2014, por Zhao, et al., y titulada “Using PCE as SDN Controller,” (“591 Application”) y Zhao, et al., “PCEP Procedures and Protocol Extensions for Using PCE as Central Controller (PCECC) of LSP”, borrador de Fuerza de Trabajo de Ingeniería de Internet (IETF), 16 de marzo del 2016 (Zhao) pueden ser beneficiosos para proporcionar servicios de VPN y PWE3 sobre MPLS. Sin embargo, la solicitud ‘591 y Zhao pueden que no soporten servicios de VPN y PWE3 sobre MPLS.
Descritas en este documento hay varias realizaciones para proporcionar servicios de red basados en túneles LSP MPLS tal como L3VPN, L2VPN, PWE3, y túneles IPv6 mediante el uso de un PCECC para negociar y distribuir asignaciones de etiquetas de servicio en redes de MPLS. Las realizaciones descritas extienden el modelo de red centralizada descrito en la solicitud ‘591 y Zhao para soportar los servicios basados en túneles como se describen en Zhao, “The Use Cases for Using PCE as the Central Controller (PCECC) of LSPs”, borrador de IETF, 17 de marzo del 2016.
El PCECC realiza cálculos de ruta y negociaciones y asignaciones de etiquetas de servicio, al eliminar la compleja gestión y distribución de etiquetas en los nodos de red. El PCECC construye y mantiene objetos de reenvío de la LSP que comprenden instrucciones de reenvío para nodos de red a lo largo de LSP calculadas. El PCECC descarga los objetos de reenvío de la LSP a los nodos de red. Los nodos de red funcionan como dispositivos de reenvío sin implementar las funciones del plano de control tal como BGP, IBGP, IGP, y señalización LDP y RSVP-TE MPLS. Las realizaciones descritas introducen mecanismos de señalización entre el PCECC y los clientes de cálculo de rutas (PCC) para reserva de recursos, asignación de etiquetas de servicio, y reenvío de distribución de entradas. Las etiquetas de servicio pueden ser etiquetas de VPN, etiquetas de PWE3 o DLCI, o etiquetas de IPv6. Las realizaciones descritas son adecuadas para usar en varios tipos de redes tal como centros de datos, redes de entrega de contenido, redes centrales, redes de transición SDN, y redes de transporte. Las realizaciones descritas pueden ser aplicadas a varias tecnologías como reenvío basado en enrutamiento de origen, virtualización de red (NV) multi topología, cálculo de rutas, monitorización de LSP, elemento de cálculo de rutas (PCE) de red óptica, resiliencia de red, y TE de tráfico inteligente consciente de la aplicación. Las realizaciones descritas permiten provisionar servicios de VPN y PWE sobre varios dominios y túneles, que incluye tanto dominios de IPv4 e IPv6 como túneles.
La FIG. 3 es un diagrama esquemático de una red 300 de MPLS que emplea un PCECC para proporcionar servicios de VPN según una realización de la descripción. La red 300 desacopla la señalización MPLS del reenvío de datos similar al desacoplamiento del plano de control y el plano de reenvío en las redes SDN. La red 300 comprende al menos un PCECC 360 y una pluralidad de nodos 320 interconectados por una pluralidad de enlaces 330. La red 300 opera bajo múltiples dominios 310 similares a los dominios 110. Por ejemplo, los dominios 310 son dominios IP versión 4 (IPv4). Los enlaces 330 son similares a los enlaces 130. El PCECC 360 está en comunicación de datos directa con cada nodo 320 a través de una pluralidad de canales 370 de comunicación. Los canales 370 de comunicación pueden ser implementados a través de un protocolo de comunicación de elemento de cálculo de rutas (PCEP), un protocolo de puerta de enlace interior (IGP), o cualquier protocolo de comunicación adecuado. Además, el PCECC 360 está en comunicación de datos con un orquestador 380 de servicios de transporte.
El PCECC 360 puede ser una máquina virtual (VM), un hipervisor, o cualquier otro dispositivo configurado para gestionar y configurar los nodos 320 para proporcionar servicios de VPN. El PCECC 360 directamente recibe desde cada nodo 320 información tal como información de ruta, información de estado de red, información de etiqueta, información de la topología, e información de restricciones. El PCECC 360 mantiene y sigue la información de la topología, o la información de etiqueta, y la información de ruta de todos los nodos 320. El PCECC 360 calcula rutas de reenvío para cada nodo 320 según la información de la topología y la información de restricciones. El PCECC 360 puede recibir información de tráfico desde un analizador controlador de tráfico y puede calcular las rutas de reenvío según la información de tráfico. La información de tráfico puede incluir estadísticas del tráfico a lo largo de los enlaces 330 tal como un número de paquetes enviados, un número de paquetes tirados, y latencia. El PCECC 360 reserva etiquetas de rutas para cada nodo 320 para reenviar tráfico a lo largo de las rutas calculadas. El PCECC 360 reserva etiquetas de VPN para crear VPN en la red 300 y distribuye las etiquetas de VPN a los nodos 320 de borde correspondientes. El PCECC 360 construye objetos de reenvío para los nodos 320. Un objeto de reenvío puede incluir información de clasificación de tráfico, información de interfaz o puerto de tráfico entrante, información de interfaz o puerto de tráfico saliente, etiquetas de rutas, y etiquetas de VPN. El PCECC 360 envía los objetos de reenvío a nodos 320 correspondientes en la red 300.
Los nodos 320 son cualquier dispositivo programable de software configurado para realizar funciones de reenvío en la red 300 según las instrucciones de reenvío u objetos de reenvío recibidos desde el PCECC 360. Los nodos 320 pueden ser referidos como nodos compatibles con SDN o habilitados con SDN dado que los nodos 320 funcionan como dispositivos de reenvío en la red 300 sin implementar un plano de control. A diferencia de las redes 100 y 200, los nodos 320 ubicados en los bordes de la red 300 no calculan rutas o reservan etiquetas de VPN para crear VPN. Además, todos los nodos 320 en la red 300 no necesitan implementar el LDP, el protocolo RSVP-TE, o señalización de establecimiento similar a lo largo de rutas calculadas. Así, la complejidad de la red y la señalización de control en la red 300 es muy reducida cuando se compara con las redes 100 y 200.
La red 300 puede proporcionar VPN 351 y 352. Las VPN 351 y 352 son mostradas por la línea sólida gruesa y la línea punteada gruesa, respectivamente. Por ejemplo, el PCECC 360 recibe una solicitud de creación de VPN desde el orquestador 380 de servicios de transporte para crear una VPN 351. El orquestador 380 de servicios de transporte puede ser una VM, un servidor, o cualquier dispositivo configurado para comunicarse con clientes, usuarios, y aplicaciones de cliente. La solicitud de creación de VPN puede indicar los CE 341 y 342 y restricciones tal como anchos de banda de enlaces. El PCECC 360 calcula una ruta para una LSP desde el CE 341 al CE 342. La LSP es usada para reservar la VPN 351 solicitada por el orquestador 380 de servicios de transporte. El PCECC 360 asigna etiquetas de rutas en los nodos 320 a lo largo de la ruta de la LSP. El PCECC 360 asigna una etiqueta de VPN para la VPN 351. El PCECC 360 construye objetos de reenvío según la ruta calculada, las etiquetas de rutas reservadas, y la etiqueta de VPN reserva para cada nodo 320 a lo largo de la ruta de la LSP. Por ejemplo, los objetos de reenvío para un nodo de entrada tal como el nodo PE1 320 y un nodo de salida tal como el nodo PE2320 incluye la etiqueta de VPN reservada mientes que los objetos de reenvío para los nodos de tránsito pueden excluir la etiqueta de VPN reservada. El PCECC 360 descarga los objetos de reenvío a los nodos 320 a lo largo de la ruta de la LSP. Subsecuentemente, los nodos 320 a lo largo de la ruta de la LSP para la VPN reenvían tráfico de la VPN según los objetos de reenvío recibos desde el PCECC 360. Los objetos de reenvío pueden instruir los nodos 320 para realizar operaciones de reenvío similares a las descritas en la red 100. El PCECC 360 puede crear cualquier número de VPN sobre cualquier número de dominios mediante el uso de mecanismos similares. Además, la red 300 puede ser soportada mediante la extensión del PCEP, como se describe completamente a continuación.
La FIG. 4 es un diagrama esquemático de una red 400 de MPLS que emplea un PCECC para proporcionar servicios de túneles de IPv6 según una realización de la descripción. La red 400 es similar a la red 300, pero comprende una capa de transporte de IPv6 en vez de una capa de transporte de IPv4. La red 400 comprende un PCECC 460 y una pluralidad de nodos 420 interconectados por una pluralidad de enlaces 430. La red 400 opera bajo una pluralidad de dominios 410 de IPv6. Los nodos 420 son similares a los nodos 120, 221,222, y 320, pero soportan IPv6. Los enlaces 430 son similares a los enlaces 130 y 330. El PCECC 460 está en comunicación directa con cada nodo 420 a través de una pluralidad de canales 470 de comunicación. El PCECC 460 es similar al PCECC 360. El PCECC 460 puede recibir solicitudes del servicio de túneles IPv6 desde un orquestador 480 de servicios de transporte similar al orquestador 380 de servicios de transporte. En respuesta a las solicitudes, el PCECC 460 crea túneles 451 y 452 IPv6 en la red 400 mediante el empleo de mecanismos de creación de LSP similares como el PCECC 360. Los túneles 451 y 452 IPv6 son mostrados por la línea sólida gruesa y la línea punteada gruesa, respectivamente. Los túneles 451 y 452 IPv6 son configurados para llevar tráfico IPv6. El PCECC 460 genera objetos de reenvío que incluyen etiquetas de rutas con información de dirección IPv6. El PCECC 460 descarga objetos de reenvío a los nodos 420 a través de los canales 470 de comunicación similar a los canales 370 de comunicación. El PCECC 460 puede crear cualquier número de túneles IPv6 a través de cualquier número de dominios mediante el uso de mecanismos similares. Además, las VPN tales como las VPN 151, 152, 351, y 352 pueden ser superpuestas encima de túneles IPv6 similares a los túneles 451 y 452 IPv6. Además, la red 400 puede ser soportada mediante la extensión del PCEP, como se describe completamente a continuación.
La FIG. 5 es un diagrama esquemático de una red 500 de PWE3 basada en MPLS que emplea un PCECC para proporcionar servicios de PWE3 según una realización de la descripción. La red 500 es similar a la red 200, pero emplea mecanismos similares a los de las redes 300 y 400 para desacoplar señalización MPLS del reenvío de datos. La red 500 comprende un PCECC 560, una primera red 510, una red 520 de MPLS, y una segunda red 530. El PCECC 560 es similar a los PCECC 360 y 460. La primera red 510 y la segunda red 530 son similares a la primera red 210 y la segunda red 230, respectivamente.
Similar a la red 220 de MPLS, la red 520 de MPLS proporciona pseudocables 523 y 524 para conectar las partes de VC 551 y 552 en la red 510 para las partes correspondientes de los VC 551 y 552 en la segunda red 530, respectivamente. Los pseudocables 523 y 524 son similares a los pseudocables 223 y 224. Sin embargo, el PCECC 560 crea los pseudocables 523 y 524. El PCECC 560 recibe solicitudes de servicio de PWE3 desde un orquestador 580 de servicios de transporte similar a los orquestadores 380 y 480 de servicios de transporte El PCECC 560 realiza mecanismos de creación de LSP similares a los PCECC 360 y 460. Así, la red 520 no emplea señalización BGP de auto descubrimiento y LDP.
Por ejemplo, el PCECC 560 calcula rutas, reserva etiquetas de rutas, y descarga objetos de reenvío a cada nodo 521 similar a los nodos 320 y 420 en la red 520 a través de los canales 570 de comunicación similar a los canales 370 y 470 de comunicación. Además, el PCECC 560 negocia y reserva etiquetas de DLCI o etiquetas PWE3 con los nodos 521 de borde para identificar los pseudocables 523 y 524 en la red 520 y distribuye las etiquetas de DLCI a los nodos 521 de borde correspondientes en la red 520 MPLS. Subsecuentemente, los nodos 521 en las rutas de los pseudocables 523 y 524 reenvían tráfico de los VC 551 y 552 según los objetos o instrucciones de reenvío recibidas desde el PCECC 560. El PCECC 560 puede crear cualquier número de servicios PWE3 sobre cualquier número de dominios mediante el uso de mecanismos similares. Además, los servicios PWE3 pueden ser superpuestos encima de túneles IPv6 similares a los túneles 451 y 452 IPv6. Además, la red 500 puede ser soportada mediante la extensión del PCEP, como se describe completamente a continuación.
La FIG. 6 es un diagrama esquemático de un NE 600 según una realización de la descripción. El NE 600 es adecuado para implementar las realizaciones descritas. El NE 600 comprende puertos 610 de entrada y unidades (Rx) 620 receptoras para recibir datos; un procesador, unidad lógica, o unidad de procesamiento central (CPU) 630 para procesar los datos; unidades (Tx) 640 transmisoras y puertos 650 de salida para transmitir los datos; y una memoria 660 para almacenar los datos. El dispositivo 600 puede también comprender componentes óptico a eléctrico (OE) y componentes eléctrico a óptico (EO) acoplados a los puertos 610 de entrada, las unidades 620 receptoras, las unidades 640 transmisoras, y los puertos 650 de salida para entrada o salida de señales ópticas o eléctricas.
El procesador 630 está implementado por cualquier combinación adecuada de hardware, middleware, firmware, y software. El procesador 630 puede ser implementado como uno o más chips de CPU, núcleos (por ejemplo un procesador de múltiples núcleos), matrices de puertas programables de campo (FPGA), circuitos integrados específicos de aplicación (ASIC), o procesadores de señal digital (DSP). El procesador 630 está en comunicación con los puertos 610 de entrada, unidades 620 receptoras, unidades 640 transmisoras, puertos 650 de salida, y memoria 660. El procesador 630 comprende un componente 670 de provisión de servicios. El componente 670 de provisión de servicios implementa las realizaciones descritas, por ejemplo los métodos 800, 900, 1000, y 1100, como se describe completamente a continuación. La inclusión del componente 670 de provisión de servicios por lo tanto proporciona una mejora sustancial a la funcionalidad del NE 600 y efectúa una transformación del NE 600 a un estado diferente. De manera alternativa, el componente 670 de provisión de servicios se implementa como instrucciones almacenadas en la memoria 660 y ejecutadas por el procesador 630. El procesador 630, la memoria 660, o ambos pueden almacenar los métodos 800, 900, 1000, y 1100 de forma que el NE 600 puede implementar los métodos 800, 900, 1000, y 1100. Además, en la realización alternativa, el NE 600 puede comprender cualquier otro medio para implementar los métodos 800, 900, 1000, y 1100.
La memoria 660 comprende uno o más discos, unidades de cinta, o unidades de estado sólido y puede ser usada como un dispositivo de almacenamiento de datos de desbordamiento, para almacenar programas cuando tales programas son seleccionados para su ejecución, para almacenar instrucciones y datos que son leídos durante la ejecución del programa. La memoria 660 puede ser volátil o no volátil y puede ser memoria de solo lectura (ROM), memoria de acceso aleatorio (RAM), memoria de contenido direccionable ternario (TCAM), o memoria de acceso aleatorio estática (SRAM).
La FIG. 7 es un diagrama esquemático de una red 700 que comprende nodos heredados y nodos habilitados con SDN según una realización de la descripción. La red 700 es similar a las redes 300, 400, y 520, pero comprende un PCECC 710 en comunicación de datos con una combinación del nodo 720 heredado y nodos 730 habilitados con SDN. El PCECC 710 es similar a los PCECC 360, 460, y 560, pero proporciona una vista más detallada de sus componentes internos. El nodo 720 heredado es similar a los nodos 120, 221, y 222 y realiza tanto funciones del plano de control como del plano de datos. El nodo 720 heredado es también referido como un nodo no compatible con SDN o un nodo no habilitado con SDN. Los nodos 730 habilitados con SDN son similares a los nodos 320, 420, y 521 y funcionan como dispositivos de reenvío. El PCECC 710 se comunica tanto con el nodo 720 heredado como con los nodos 730 habilitados con SDN a través del PCEP para la negociación de rango de etiquetas, delegación de recursos de etiquetas, y procesamiento del protocolo RSVP-TE/LDP. El PCECC 710 puede configurar el nodo 720 heredado y los nodos 730 habilitados con SDN para crear servicios de VPN tales como las VPN 351 y 352, servicios de túneles IPv6 tales como los túneles 451 y 452 IPv6, y servicios de PWE3 tales como los pseudocables 523 y 524. El nodo 720 heredado y los nodos 730 habilitados con SDN se comunican entre sí a través del IGP.
El PCECC 710 comprende un componente 712 RSVP-TE/LDP, un componente 713 PCEP, un componente 716 primero la ruta más corta restringida (CSPF), un gestor 715 de LSP, una pluralidad de bases de datos de etiquetas (LDB) 711, una pluralidad de bases de datos de ingeniería de tráfico (TEDB) 714, y una pluralidad de bases de datos de LSP (LSPDB) 717. Las TEDB 714 comprenden información de la topología, información de enlaces, información de nodos, y otra información relacionada con el rendimiento y la optimización de la red 700. La información de la topología incluye la disposición de los nodos tal como el nodo 720 heredado y los nodos 730 habilitados con SDN y enlaces tales como los enlaces 130, 330, y 430. Múltiples topologías pueden ser superpuestas sobre los nodos y enlaces en la red. La información de enlaces puede incluir anchos de banda de enlaces no reservados, anchos de banda de enlaces máximos, y estados de enlaces. La información de nodos puede incluir direcciones y estados de los nodos. Un dispositivo de memoria tal como la memoria 660 en el PCECC 710 o externa al PCECC 710 puede almacenar las TEDB 714. Por ejemplo, las TEDB 714 pueden almacenar información de diferentes topologías en TEDB 714 separadas como se muestra o en cualquier otra configuración adecuada.
El componente 716 CSPF está configurado para calcular rutas de enrutamiento a través de una red tal como las redes 300, 500, y 500 para cumplir ciertas restricciones. El componente 716 CSPF puede emplear un algoritmo CSPF. Por ejemplo, el componente 716 CSPF consulta con la TEDB 714 cuando realiza cálculos de rutas.
Las LDB 711 comprenden información de recursos de etiquetas, que puede incluir una lista de etiquetas de rutas y etiquetas de servicios en el nodo 720 heredado y los nodos 730 habilitados con SDN. Las etiquetas de rutas y las etiquetas de servicio pueden tener espacios de etiquetas separados de forma que no se solapen. Por ejemplo, cada LDB 711 puede almacenar etiquetas en un nodo particular. El componente 712 RSVP-TE/LDP está configurado para asignar y delegar etiquetas de rutas a los nodos 730 habilitados con SDN, negociar rangos de etiquetas con el nodo 720 heredado, y establecer LSP en la red 700, como se describe más completamente a continuación. Las LDB 711 pueden comprender espacios de etiquetas separados para las LSP, un servicio de VPN, un servicio de PWE3, y un servicio de IPv6. El componente 712 RSVP-TE/LDP puede almacenar y seguir etiquetas asignadas a los nodos 730 habilitados con SDN en las LDB 711. El componente 712 RSVP-TE/LCP puede también almacenar y seguir etiquetas usadas por el nodo 720 heredado.
El componente 713 PCEP está configurado para comunicarse con el nodo 720 heredado y nodos 730 habilitados con SDN. El componente 713 PCEP puede implementar las funciones PCE PCEP con extensiones. El componente 713 PCEP envía instrucciones de reenvío a los nodos 730 habilitados con SDN para facilitar el reenvío de datos a lo largo de las LSP en la red 700. Además, el componente 713 PCEP intercambia mensajes PCEP con el nodo 720 heredado para iniciar el establecimiento de las LSP en la red 700.
Las LSPDB 717 comprenden información de ruta, información de reenvío, estados, y cualquier otra información relacionada con las LSP en la red 700. La información de ruta puede incluir una secuencia de nodos atravesados por una LSP. Por ejemplo, la LSP para la VPN 351 puede estar almacenada en la forma de {P E 2^P 6 ^A B R 4 ^P 4^A B R 2^P 2 ^P E 1 } para representar la secuencia de nodos que la LSP atraviesa. La información de reenvío puede incluir un objeto de reenvío que comprende instrucciones de reenvío para cada nodo a lo largo de la ruta de una LSP. Un objeto de reenvío para un nodo de entrada de una LSP puede incluir una instrucción para adjuntar una etiqueta de servicio tal como una etiqueta de VPN o una etiqueta de DLCI y una etiqueta de ruta saliente. Un objeto de reenvío para un nodo de tránsito a lo largo de una LSP puede incluir una instrucción para intercambiar una etiqueta de ruta entrante con una etiqueta de ruta saliente. Un objeto de reenvío para un nodo de salida de una LSP puede incluir una instrucción para eliminar una etiqueta de ruta entrante y una etiqueta de servicio. Las LSPDB 717 pueden comprender subbases de datos separadas para LSP de IPv4 y LSP de IPv6. El gestor 715 de LSP está configurado para coordinarse con el componente 716 CSPF, el componente 712 RSVP-TE/LDP, y el componente 713 PCEP para crear, borrar, modificar, y mantener las LSP para provisionar servicios tales como las VPN 351 y 352, los túneles 451 y 452 IPv6, y los PWE3 o pseudocables 223 y 224.
Cada uno de los nodos 720 heredados y los nodos 730 habilitados con SDN comprende un componente 741 PCEP y un gestor 742 de LSP. El nodo 720 heredado además comprende un componente 743 RSVP-TE/LDP. El componente 741 PCEP está configurado para implementar funciones de PCC PCEP y comunicarse con el componente 713 PCEP del PCECC 710. En cada nodo 730 habilitado con SDN, el componente 741 PCEP recibe objetos o instrucciones de reenvío y delegación de recursos de etiquetas desde el componente 713 PCEP y el gestor 742 de LSP facilita el reenvío de datos sobre las LSP según los objetos de reenvío recibidos desde el PCECC 710. Por ejemplo, cada nodo 730 habilitado con SDN comprende una base de información de reenvío (FIB) y un motor de reenvío. El gestor 742 de LSP puede almacenar los objetos de reenvío recibidos en la FIB y configurar el motor de reenvío según la FIB durante el reenvío de datos.
En el nodo 720 heredado, el componente 743 RSVP-TE/LDP negocia los rangos de etiquetas de rutas con el PCECC 710 a través del componente 741 PCEP. Por ejemplo, el nodo 720 heredado negocia con el PCECC 710 para un rango particular de valores de etiquetas de rutas y gestiona las etiquetas de rutas de manera local. Por ejemplo, el componente 743 RSVP-TE/LDP selecciona un valor de etiqueta de ruta para una LSP particular de las etiquetas de rutas negociadas y notifica al PCECC 710 de la etiqueta de ruta asignada. El PCECC 710 puede almacenar etiquetas de rutas del nodo 720 heredado en una LDB 711 correspondiente. El PCECC 710 puede también almacenar información de LSP asociada con el nodo 720 heredado en una LSPDB 717 correspondiente. El gestor 742 de LSP establece, borra, modifica, y mantiene LSP como instruido por el PCECC 710.
En la operación, el PCECC 710 recibe una solicitud para crear una VPN en la red 700, por ejemplo, desde un orquestador de servicios de transporte tal como el orquestador 380 de servicios de transporte. El gestor 715 de LSP solicita al componente 716 CSPF calcular una ruta para una LSP para servir la VPN. El gestor 715 de LSP solicita al componente 712 RSVP-TE/LDP reservar etiquetas de rutas para los nodos a lo lago de la ruta de la LSP. El gestor 715 de LSP reserva una etiqueta de VPN de la LDB 711 para la VPN. La etiqueta de VPN es específica para cada LDB 711, así que cada LDB 711 conoce la relación correspondiente entre la etiqueta de la VPN y el servicio de VPN. El gestor 715 de LSP construye objetos de reenvío según la ruta calculada, la etiqueta de VPN reservada, y las etiquetas de rutas reservadas. El gestor 715 de LSP almacena los objetos de reenvío y cualquier otra información asociada con la LSP en las LSPDB 717. El gestor 715 de LSP puede almacenar objetos de reenvío de cada nodo en una LSPDB 717 separada como se muestra o en otra configuración adecuada. El gestor 715 de LSP coordina con el componente 713 PCEP para descargar los objetos de reenvío a los nodos 730 habilitados con SDN a lo largo de la ruta de la LSP. Cuando el nodo 720 heredado está a lo largo de la ruta de la LSP, el gestor 715 de LSP se coordina con el componente 712 RSVP-TE/LDP y el componente 713 PCEP para negociar etiquetas de rutas con el nodo 720 heredado. Al permitir que el PCECC 710 establezca una LSP con tanto los nodos heredados como los nodos habilitados con SDN que usan diferentes protocolos, el PCECC 760 es adecuado para usar durante la migración de SDN desde redes existentes.
La FIG. 8 es un diagrama de protocolo de un método 800 de provisión de un servicio según una realización de la descripción. Un PCECC similar al PCECC 360, 460, 560, y 710, una entrada de PCC, un tránsito de PCC, y una salida de PCC a los nodos 320, 420, 521, y 730, y el NE 600 pueden implementar el método 800. El método 800 es implementado después de que el PCECC calcule una ruta para una LSP para servir el servicio, por ejemplo, que usa un componente CSPF tal como el componente 716 CSPF. La ruta atraviesa desde el nodo de entrada al nodo de salida a través del nodo de tránsito.
En el paso 810, el PCECC envía un mensaje de solicitud de inicio de LSP cálculo de ruta (PCInitiate) a un nodo de entrada de PCC para iniciar la instanciación de la LSP. El mensaje PCInitiate se describe en Crabbe, et al., “PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model”, borrador del IETF, 19 de octubre del 2015 (“Crabbe”). El mensaje PCInitiate comprende un identificador específico de PCE para la LSP (PLSP-ID), una bandera P, y una bandera D. El PLSP-ID se establece a un valor de 0 cuando se inicia la instanciación. La bandera P se establece a un valor de 1 para indicar que el PCECC crea la LSP asociada. La bandera D se establece a 1 para indicar que el PCECC delega el control de la LSP al nodo de entrada de PCC.
En el paso 820, la entrada de PCC envía un mensaje de reporte de estado de cálculo de ruta (PCRpt) al PCECC. El mensaje PCRpt es descrito en Crabbe. El mensaje PCRpt comprende un PLSP-ID, una bandera P, una bandera D, y una bandera C. El PLSP-ID se establece a un valor de 2 para identificar la LSP. La bandera P y la bandera D se establecen a los mismos valores que en el mensaje PCInitiate recibido. La bandera C se establece a un valor de 1 para indicar que el mensaje PCInitiate inicia la creación de la LSP.
En el paso 830, tras recibir el mensaje PCRpt, el PCECC establece un identificador de la LSP (LSP-ID) a 2 para la LSP según el PLSP-ID recibido en el mensaje PCRpt. En el paso 840, el PCECC envía un primer mensaje de actualización del cálculo de ruta (PCLabelUpd) al PCC de salida. En el paso 850, el PCECC envía un segundo mensaje PCLabelUpd al tránsito de PCC. En el paso 860, el PCECC envía un tercer PCLabelUpd a la entrada de PCC. El primero, segundo, y tercer mensaje PCLabelUpd son similares al mensaje PCLabelUpd descrito en Zhao, pero con extensiones, como se describe más completamente a continuación. El primero, segundo, y tercer mensaje PCLabelUpd informan a la salida de PCC, al tránsito de PCC, y a la entrada de PCC, respectivamente, de información de etiquetas necesaria para enrutar el paquete de datos a lo largo de la LSP, como se describe más completamente a continuación.
En el paso 870, el PCECC envía un mensaje de actualización de cálculo de rutas (PCUpd) a la entrada de PCC para informar a la entrada de PCC de que se ha completado el establecimiento de la LSP. El mensaje PCUpd es descrito en Zhao como PCEP. Como se ilustra, el PCECC se comunica directamente con cada entrada de PCC, tránsito de PCC, y salida de PCC a lo largo de la ruta de la LSP.
El mensaje PCLabelUpd puede comprender una cabecera común PCEP y un objeto de lista de actualización de etiquetas del PCE. El objeto de lista de actualización de etiquetas del PCE comprende una lista de objetos de actualización de etiquetas del PCE. Cada objeto de actualización de etiquetas del PCE comprende un objeto de descarga de etiquetas del PCE o una correspondencia de etiquetas del PCE. La cabecera común del PCEP es descrita en Vasseur, et al., “Path Computation Element (PCE) Communication Protocol (PCEP)”, RFC 5440 del IETF, marzo del 2009. El objeto de lista de actualización de etiquetas del PCE, el objeto de actualización de etiquetas del PCE, y el objeto de descarga de etiquetas del PCE son descritos en el PCEP de Zhao. El objeto de correspondencia de etiquetas del PCE se extiende para provisionar servicios tales como las VPN 351 y 352, los túneles 451 y 451 IPv6, y el PWE3 o pseudocables 523 y 524, como se describe más completamente a continuación. El mensaje PCLabelUpd comprende una lista de objetos de mensaje tales como:
<PCLabelUpd Mensaje> ::= <Cabecera Común>
<lista-actualización-etiqueta-pce>
<lista-actualización-etiqueta-pce> ::= <actualización-etiqueta-pce>
[<lista-actualización-etiqueta-pce>]
<actualización-etiqueta-pce> ::= (<descarga-etiqueta-pce> o <correspondencia-etiqueta-pce>).
El objeto de correspondencia de etiqueta del PCE comprende un objeto parámetro de solicitud con estado (SRP), un objeto de etiqueta, y un objeto de servicio. El objeto SRP es descrito en Crabbe, et al., “PCEP Extensions for Stateful PCE”, borrador del IETF, 20 de marzo del 2016. El objeto SRP es usado para correlacionar entre solicitudes de actualización enviadas por un PCE y errores y estados enviados por un PCC. El objeto de etiqueta es similar al objeto de etiqueta descrito en Zhao. Sin embargo, el objeto de etiqueta se extiende para incluir TLV de direcciones IPv6 cuando opera en un dominio IPv6 tal como los dominios 410, como se describe más completamente a continuación. El objeto de servicio comprende un valor o un nombre que identifica un servicio. Cuando el servicio es un servicio de VPN, el objeto de servicio comprende un valor de VPN y/o un nombre de VPN. Cuando el servicio es un servicio de PWE3, el objeto del servicio comprende un valor de DLCI y/o un nombre de DLCI. El formato de un objeto de correspondencia de etiqueta del PCE para la VPN es como sigue:
<correspondencia-etiqueta-pce> ::= <SRP>
<etiqueta>
<Número VPN>[<Nombre VPN>].
El formato de un objeto de correspondencia de etiqueta del PCE para PWE3 es como sigue:
<correspondencia-etiqueta-pce> ::= <SRP>
<etiqueta>
<Número DLCI>[<Nombre DLCI>].
La FIG. 9 es un diagrama de flujo de un método 900 para provisionar un servicio según una realización de la descripción. Un PCECC similar a los PCECC 360, 460, 560, y 710, una entrada de PCC, un tránsito de PCC, y una salida de PCC similares a los nodos 320, 420, 521, y 730, y el NE 600 pueden implementar el método 900. El método 900 emplea mecanismos similares a los descritos en las redes 300, 400, 500, y 700 y el método 800. El método 900 es implementado cuando el PCECC crea un servicio en una red tal como las redes 300, 400, 500, y 700. En el paso 910, una solicitud de servicio para provisionar un servicio de un primer nodo de borde a un segundo nodo de borde en una red es recibida, por ejemplo, desde un orquestador de servicios de transporte tal como los orquestadores 380, 480, y 580 de servicios de transporte. El servicio puede ser un servicio de VPN tal como las VPN 351 y 352, un servicio de PWE3 tal como los pseudocables 523 y 524, o un servicio de túneles IPv6 tal como los túneles 451 y 452 IPv6. Por ejemplo, para la VPN 351, el primer nodo de borde es el nodo PE1 320, y el segundo nodo de borde es el nodo PE2 320. En el paso 920, en respuesta a la solicitud de servicio, una ruta es calculada para una LSP del primer nodo de borde al segundo nodo de borde, por ejemplo, que usa un componente de CSPF tal como el componente 716 de CSPF. La ruta puede ser calculada según la información de topología de la red, por ejemplo, almacenada en una TEDB tal como la TEDB 714, a través de un algoritmo de CSPF.
En el paso 930, la información de etiqueta es reservada para renviar tráfico del servicio de transporte en la LSP, por ejemplo, desde una o más LDB tal como las LDB 711. La información de etiqueta puede incluir una etiqueta de ruta para cada nodo en la ruta de la LSP excepto para la entrada de la LSP y una etiqueta de servicio para identificar el servicio. Cuando el servicio es un servicio de VPN, la etiqueta de servicio es una etiqueta de VPN, que puede incluir un número de VPN o un nombre de VPN como se describió anteriormente. Cuando el servicio es un servicio de PWE3, la etiqueta de servicio es una etiqueta de DLCI, que puede incluir un número de DLCI o un nombre de DLCI como se describió anteriormente. Cuando el servicio es un servicio de túneles IPv6, la información de etiquetas puede incluir direcciones de IPv6 en un objeto de FEC para identificar el servicio como se describió anteriormente.
En el paso 940, un mensaje de actualización de etiquetas es enviado a un tercer nodo en la ruta de la LSP para facilitar el reenvío del tráfico del servicio de transporte en la ruta de la LSP. El mensaje de actualización de etiqueta comprende la información de etiqueta. En una realización el mensaje de actualización de etiqueta es un mensaje PCLabelUpd del PCEP que comprende una correspondencia de etiqueta del PCEP. La correspondencia de la etiqueta del PCE puede incluir una etiqueta de VPN, una etiqueta de DLCI, o un objeto de FEC de IPv6 dependiendo del tipo de servicio.
La FIG. 10 es un diagrama de flujo de un método 1000 para provisionar un servicio según otra realización de la descripción. Un PCECC tal como los PCECC 360, 460, 560, 710 o el NE 600 pueden implementar el método 1000. El método 1000 emplea mecanismos similares a los descritos en las redes 300, 400, 500, y 700 y los métodos 800 y 900. El método 1000 es implementado cuando se provisiona un servicio tal como las VPN 351 y 352, los PWE3551 y 552, y los servicios de túneles 451 y 452 IPv6 en una red tal como la red 700 que comprende tanto nodos habilitados con SDN tal como los nodos 320, 420, 521, y 730 como nodos heredados tal como los nodos 120, 221, 222, y 720. El método 1000 es implementado después de que el PCECC calcule una ruta para una LSP para servir el servicio. En el paso 1010, una etiqueta de servicio es reservada para identificar un servicio, por ejemplo, desde una LDB tal como las LDB 711. En el paso 1020, una etiqueta de ruta es reservada para cada nodo habilitado con SDN en la ruta de la LSP para facilitar el reenvío del tráfico del servicio.
En el paso 1030, un objeto de reenvío es generado para cada nodo habilitado con SDN según una etiqueta de ruta correspondiente y una etiqueta de servicio. Por ejemplo, un objeto de reenvío para una entrada de la LSP puede incluir una instrucción para adjuntar la etiqueta de servicio y la etiqueta de ruta de un nodo de siguiente salto en la ruta. Un objeto de reenvío para un nodo de tránsito de la LSP puede incluir una instrucción para intercambiar una etiqueta de ruta entrante con una etiqueta de ruta saliente, que es la etiqueta de ruta de un nodo de siguiente salto en la ruta. Un objeto de reenvío para una salida de la LSP puede incluir una instrucción para eliminar una etiqueta de servicio y una etiqueta de ruta entrante antes de reenviar. En el paso 1040, un objeto de reenvío correspondiente es descargado a cada nodo habilitado con SDN, por ejemplo, que usa un componente PCEP tal como el componente 713 PCEP.
En el paso 1050, un mensaje de solicitud de reserva de rango de etiquetas es recibido desde un nodo no habilitado con SDN en la ruta que solicita un rango de valores de etiquetas de rutas. En el paso 1060, el rango de valores de etiquetas de rutas es reservado para el nodo no habilitado con SDN. El PCECC puede reservar un subconjunto de los valores de etiquetas de rutas para el nodo no habilitado con SDN.
En el paso 1070, un mensaje de respuesta de reserva de rango de etiquetas es enviado al nodo no habilitado con SDN que indica el rango de valores de etiquetas de rutas reservado. El PCECC puede almacenar los valores de etiquetas de rutas reservadas para el nodo no habilitado con SDN en una LDB tal como las LDB 711. Los pasos 1050­ 1070 pueden ser repetidos para negociar otro rango de valores de etiquetas de rutas o para otros nodos no habilitados con SDN en la ruta. El método 1000 puede implementar los pasos en el orden como se muestra o en cualquier otro orden adecuado para lograr funcionalidades similares.
La FIG. 11 es un diagrama de flujo de un método 1100 para realizar reenvío de datos en una red tal como las redes 300, 400, 500, y 700 según una realización de la descripción. Un nodo habilitado con SDN tal como los nodos 320, 420, 521, y 730 o el NE 600 pueden implementar el método 1100. El método 1100 comienza cuando el nodo habilitado con SDN recibe instrucciones de reenvío.
En el paso 1110, una instrucción de reenvío que reenvía tráfico de un servicio en una LSP en una red es recibida desde un PCECC tal como los PCECC 360, 460, 560, y 710. La instrucción de reenvío indica una primera etiqueta que identifica un servicio en la red. En el paso 1120, un paquete de datos asociado con el tráfico del servicio es recibido.
En el paso 1130, la primera etiqueta indicada en la instrucción de reenvío es adjuntada al paquete de datos. En el paso 1140, el paquete de datos adjuntado con la primera etiqueta es reenviado a un nodo de siguiente salto en una ruta de la LSP según la instrucción de reenvío. El nodo habilitado con SDN puede almacenar la instrucción de reenvío recibida en una FIB y puede buscar la instrucción de reenvío en la FIB cuando recibe el paquete de datos.
La FIG. 12 es un diagrama esquemático de una TLV 1200 de dirección IPv6 según una realización de la descripción. Un PCECC tal como los PCECC 360, 460, 560, y 710 emplea el TLV 1200 para asociar información de siguiente salto con una etiqueta saliente o asociar una interfaz entrante con una etiqueta entrante. Por ejemplo, un mensaje PCLabelUpd del PCEP, que es descrito en la sección 6.1.1 de Zhao, puede incluir un objeto de etiqueta con un TLV 1200. El TLV 1200 comprende un campo 1210 de tipo, un campo 1220 de longitud, y un campo 1230 de dirección IPv6. El campo 1210 de tipo es alrededor de dos octetos de largo e indica que el TLV 1200 es un TLV de dirección IPv6. El campo 1220 de longitud es alrededor dos octetos de largo e indica una longitud del campo 1230 de dirección IPv6. El campo 1230 de dirección IPv6 es alrededor de 16 bytes de largo e indica una dirección IPv6 de un nodo de siguiente salto asociado con una etiqueta saliente. De manera alternativa, el campo 1230 de dirección IPv6 indica una dirección IPv6 de una interfaz entrante asociada con una etiqueta entrante.
La FIG. 13 es un diagrama esquemático de un objeto 1300 de FEC según una realización de la descripción. Un PCECC tal como los PCECC 360, 460, 560, y 710 emplea el objeto 1300 de FEC para proporcionar información de FEC. Por ejemplo, un mensaje PCLabelUpd del PCEP puede incluir el objeto 1300 de FEC. El objeto 1300 de FEC comprende un campo 1310 de dirección de ID de nodo. El campo 1310 de dirección de ID de nodo es alrededor de 16 bytes de largo e indica una dirección IPv6 asociada con una FEC.
La FIG. 14 es un diagrama esquemático de un objeto 1400 de FEC según otra realización de la descripción. Un PCECC tal como los PCECC 360, 460, 560, y 710 emplea el objeto 1400 de FEC para proporcionar información de FEC. Por ejemplo, un mensaje PCLabelUpd del PCEP puede incluir el objeto 1400 de FEC. El objeto 1400 de FEC comprende un campo 1410 de dirección IPv6 local y un campo 1420 de dirección IPv6 remota para adyacencia o un nodo vecino. El campo 1410 de dirección IPv6 local y el campo 1420 de dirección IPv6 remota son cada uno sobre 16 bytes de largo y cada uno indica una dirección IPv6 para la adyacencia.
En una realización ejemplar, un controlador centralizado de elementos de cálculo de rutas (PCECC) comprende: un elemento receptor configurado para recibir una solicitud para crear un servicio de un primer nodo de borde a un segundo nodo de borde en una red; un elemento de procesamiento acoplado al elemento receptor y configurado para: calcular una ruta para una ruta conmutada por etiquetas (LSP) del primer nodo de borde al segundo nodo de borde en respuesta a la solicitud; y reservar información de etiqueta para reenviar tráfico del servicio en la LSP; y un elemento transmisor acoplado al elemento de procesamiento y configurado para enviar un mensaje de actualización de etiqueta a un tercer nodo en la ruta para facilitar el reenvío del tráfico del servicio en la ruta, en donde el mensaje de actualización de etiqueta comprende la información de etiqueta.
Mientras varias realizaciones han sido proporcionadas en la presente descripción, se debería comprender que los sistemas y métodos descritos podrían ser realizados en muchas otras formas específicas sin salirse del alcance de la presente descripción. Los presentes ejemplos han de considerarse como ilustrativos y no restrictivos, y la intención es no limitarse a los detalles dados en este documento. Por ejemplo, los varios elementos o componentes pueden ser combinados o integrados en otro sistema o ciertas características pueden ser omitidas, o no implementadas.
Además, técnicas, sistemas, subsistemas, y métodos descritos e ilustrados en las varias realizaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas, o métodos sin salirse del alcance de la presente descripción. Otros elementos mostrados o discutidos como acoplados o directamente acoplados o en comunicación entre ellos pueden estar indirectamente acoplados o en comunicación a través de alguna interfaz, dispositivos, o componentes intermedios ya sean eléctricamente, mecánicamente, o de otro modo. Otros ejemplos de cambios, sustituciones, y alteraciones son comprobables por alguien experto en la técnica y podrían hacerse sin salirse del alcance descrito en este documento.

Claims (19)

REIVINDICACIONES
1. Un método que comprende:
recibir (910), por un controlador centralizado de elementos de cálculo de rutas, PCECC (360, 460, 560, 710), una solicitud de servicio desde un orquestador de servicios de transporte para provisionar un servicio de un primer nodo de borde a un segundo nodo de borde en una red;
calcular (920), por el PCECC (360, 460, 560, 710), una ruta para una ruta conmutada por etiquetas, LSP, del primer nodo de borde al segundo nodo de borde en respuesta a la solicitud de servicio;
reservar (930), por el PCECC (360, 460, 560, 710), información de etiqueta para reenviar tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de la pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio; y
enviar (940), por el PCECC (360, 460, 560, 710), un mensaje de actualización de etiqueta a un tercer nodo en la ruta para facilitar el reenvío del tráfico del servicio en la ruta, en donde el mensaje de actualización de etiqueta comprende la información de etiqueta, y el mensaje de actualización de etiqueta es un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUpd.
2. El método de la reivindicación 1, en donde el servicio es un servicio de red privada virtual, VPN (351, 352), y en donde la etiqueta de servicio es una etiqueta de VPN para identificar el servicio de VPN en la red.
3. El método de la reivindicación 2, en donde la etiqueta de VPN comprende un número de VPN, un nombre de VPN, o tanto el número de VPN como el nombre de VPN.
4. El método de la reivindicación 1, en donde el servicio es un servicio de borde a borde de emulación de pseudocable, PWE3 (523, 524), y en donde la etiqueta de servicio es una etiqueta de identificador de conexión de capa de enlace de datos, DLCI, para identificar el servicio de PWE3 en la red.
5. El método de la reivindicación 4, en donde la etiqueta de DLCI comprende un número de DLCI, un nombre de DLCI, o tanto el número de DLCI como el nombre de DLCI.
6. El método de la reivindicación 1, en donde el servicio es un servicio de túneles (451,452) del Protocolo de Internet versión 6, IPv6, y en donde la información de etiqueta comprende un tipo-longitud-valor, TLV, de dirección IPv6 que indica una dirección IPv6 asociada con un nodo de siguiente salto del tercer nodo en la ruta y una etiqueta saliente para reenviar el tráfico del servicio al nodo de siguiente salto.
7. El método de la reivindicación 1, en donde el servicio es un servicio de túneles (451,452) del Protocolo de Internet versión 6, IPv6, y en donde la información de etiqueta comprende un tipo-longitud-valor, TLV, de dirección IPv6 que indica una dirección IPv6 asociada con una interfaz entrante del tercer nodo y una etiqueta entrante asociada con la interfaz entrante.
8. El método de una cualquiera de las reivindicaciones 1 a 7, que además comprende:
recibir (1050), desde un nodo no habilitado con SDN en la ruta, un mensaje de solicitud de reserva de rango de etiquetas que solicita un rango de valores de etiquetas de rutas;
reservar (1060) el rango para el nodo no habilitado con SDN; y
enviar (1070), al nodo no habilitado con SDN, un mensaje de respuesta de reserva de rango de etiquetas que indica el rango de valores de etiquetas de rutas reservado.
9. El método de una cualquiera de las reivindicaciones 1 a 8, en donde el mensaje PCLabelUpd comprende un objeto de servicio que comprende un valor o un nombre que identifica el servicio como la etiqueta de servicio.
10. Un controlador centralizado de elementos de cálculo de rutas, PCECC (360, 460, 560, 710), que comprende: un receptor configurado para recibir una solicitud de servicio desde un orquestador de servicios de transporte para crear un servicio de un primer nodo de borde a un segundo nodo de borde en una red;
un procesador acoplado al receptor y configurado para:
calcular una ruta para una ruta conmutada por etiquetas, LSP, del primer nodo de borde al segundo nodo de borde en respuesta a la solicitud; y
reservar información de etiqueta para reenviar tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de la pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio; y
un transmisor acoplado al procesador y configurado para enviar un mensaje de actualización de etiqueta que comprende la información de etiqueta a un tercer nodo en la ruta para facilitar el reenvío del tráfico del servicio en la ruta, en donde el mensaje de actualización de etiqueta es un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUpd.
11. El PCECC de la reivindicación 10, en donde el servicio es un servicio de red privada virtual, VPN, y en donde la etiqueta de servicio es una etiqueta de VPN para identificar el servicio de VPN en la red; o
el servicio es un servicio de borde a borde de emulación de pseudocable, PWE3, y en donde la etiqueta de servicio es una etiqueta de identificador de conexión de capa de enlace de datos, DLCI, para identificar el servicio de PWE3 en la red; o
el servicio es un servicio de túneles del Protocolo de Internet versión 6, IPv6, y en donde el mensaje de actualización de etiqueta además comprende una dirección IPv6 de un nodo de salida de la LSP.
12. El PCECC de la reivindicación 10 u 11, que además comprende una memoria acoplada al procesador y configurada para almacenar una base de datos de etiquetas, LDB, que comprende etiquetas de servicio para identificar servicios en la red, en donde el procesador está además configurado para reservar la información de etiqueta de la LDB.
13. El PCECC de la reivindicación 10 u 11, que además comprende una memoria acoplada al procesador y configurada para almacenar una base de datos de LSP, LSPDB, en donde el procesador está además configurado para almacenar información de ruta asociada con la LSP en la LSPDB, y en donde la información de ruta comprende la información de etiqueta.
14. el PCEEE de una cualquiera de las reivindicaciones 10 a 13, en donde el mensaje PCLabelUpd comprende un objeto de servicio que comprende un valor o un nombre que identifica el servicio como la etiqueta de servicio.
15. Un elemento de red, NE (600), que comprende:
un receptor (620) configurado para:
recibir, desde el controlador centralizado de elementos de cálculo de rutas, PCECC (360, 460, 560, 710), un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUp, que comprende información de etiqueta para reenviar tráfico para un servicio, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en una ruta en una red excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio en la red; y
recibir un paquete de datos asociado con el tráfico;
un procesador (630) acoplado al receptor y configurado para adjuntar la información de etiqueta al paquete de datos; y
un transmisor (640) acoplado al procesador y configurado para reenviar el paquete de datos a un nodo de siguiente salto en la ruta según la información de etiqueta.
16. El NE (600) de la reivindicación 15, en donde el servicio es un servicio de red privada virtual, VPN (351,352), un servicio de borde a borde de emulación de pseudocable, PWE3 (523, 524), o un servicio de túneles (451, 452) del Protocolo de Internet versión 6, IPv6.
17. El NE (600) de una cualquiera de las reivindicaciones 15 o 16, en donde el mensaje PCLabelUpd comprende un objeto de servicio que comprende un valor o un nombre que identifica el servicio como la etiqueta de servicio.
18. Un sistema que comprende:
un controlador centralizado de elementos de cálculo de rutas, PCECC (360, 460, 560, 710), configurado para: recibir una solicitud de servicio desde un orquestador de servicios de transporte para provisionar un servicio de un primer nodo de borde a un segundo nodo de borde en una red;
calcular una ruta para una ruta conmutada por etiquetas, LSP, del primer nodo de borde al segundo nodo de borde; reservar información de etiqueta para reenviar tráfico del servicio en la LSP, en donde la información de etiqueta comprende una etiqueta de ruta para cada uno de una pluralidad de nodos habilitados con SDN en la ruta excepto para un nodo de entrada y comprende una etiqueta de servicio para identificar el servicio;
transmitir un mensaje de actualización de etiqueta que comprende la información de etiqueta, en donde el mensaje de actualización de etiqueta es un mensaje de actualización de etiqueta del protocolo de comunicación del elemento de cálculo de rutas, PCLabelUp;
un elemento de red, NE (600), ubicado en la ruta y configurado para:
recibir el mensaje de actualización de etiqueta desde el PCECC;
recibir un paquete de datos asociado con el tráfico:
adjuntar la información de etiqueta al paquete de datos; y
transmitir el paquete de datos a un nodo de siguiente salto en la ruta según el mensaje de actualización de etiqueta.
19. El sistema de la reivindicación 18, en donde el mensaje PCLabelUpd comprende un objeto de servicio que comprende un valor o un nombre que identifica el servicio como la etiqueta de servicio.
ES16820808T 2015-07-06 2016-07-04 Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red Active ES2830182T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562188929P 2015-07-06 2015-07-06
US201562188920P 2015-07-06 2015-07-06
US201562188933P 2015-07-06 2015-07-06
US15/201,195 US10412019B2 (en) 2015-07-06 2016-07-01 Path computation element central controllers (PCECCs) for network services
PCT/CN2016/088389 WO2017005157A1 (en) 2015-07-06 2016-07-04 Path computation element central controllers (pceccs) for network services

Publications (1)

Publication Number Publication Date
ES2830182T3 true ES2830182T3 (es) 2021-06-03

Family

ID=57685005

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16820808T Active ES2830182T3 (es) 2015-07-06 2016-07-04 Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red

Country Status (7)

Country Link
US (1) US10412019B2 (es)
EP (2) EP3295622B1 (es)
JP (1) JP6966419B2 (es)
KR (1) KR102057980B1 (es)
CN (2) CN107637031B (es)
ES (1) ES2830182T3 (es)
WO (1) WO2017005157A1 (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 (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9444675B2 (en) * 2013-06-07 2016-09-13 Cisco Technology, Inc. Determining the operations performed along a service path/service chain
CN107005462B (zh) * 2014-12-17 2020-03-20 华为技术有限公司 软件定义网络中数据转发的方法、设备和系统
WO2017020236A1 (en) * 2015-08-04 2017-02-09 Nokia Technologies Oy Interconnection of overlay networks
US10171338B2 (en) * 2016-02-08 2019-01-01 Cisco Technology, Inc. On-demand next-hop resolution
CN108702321B (zh) * 2016-02-27 2021-05-07 华为技术有限公司 实现快速重路由(frr)的系统、方法和装置
US10814893B2 (en) 2016-03-21 2020-10-27 Ge Global Sourcing Llc Vehicle control system
US11072356B2 (en) 2016-06-30 2021-07-27 Transportation Ip Holdings, Llc Vehicle control system
US10447606B2 (en) * 2017-04-12 2019-10-15 General Electric Company Time-sensitive networking differentiation of traffic based upon content
US9992105B2 (en) * 2016-03-30 2018-06-05 Juniper Networks, Inc. Label switched path reporting
EP3440807B1 (en) * 2016-05-03 2020-06-24 Huawei Technologies Co., Ltd. Label database synchronization in a packet switched communication network
CN107770073B (zh) * 2016-08-19 2020-06-02 华为技术有限公司 一种信息同步的方法，装置及系统
US10516550B2 (en) * 2017-02-27 2019-12-24 Futurewei Technologies, Inc. Traffic engineering service mapping
CN108989204B (zh) 2017-05-31 2021-08-20 华为技术有限公司 一种链路状态确定方法及设备
US10506083B2 (en) 2017-06-27 2019-12-10 Cisco Technology, Inc. Segment routing gateway storing segment routing encapsulating header used in encapsulating and forwarding of returned native packet
US10432516B2 (en) 2017-10-19 2019-10-01 Futurewei Technologies, Inc. Pseudowire servicing across multiple administrative systems using border gateway protocol-link state
EP3711263B1 (en) 2017-12-13 2025-05-21 Huawei Technologies Co., Ltd. Communication methods, apparatuses and system for sharing network resources
CN111837368B (zh) 2018-02-23 2022-01-14 华为技术有限公司 使用内部网关协议通告和编程优选路径路由
WO2019190699A1 (en) 2018-03-28 2019-10-03 Futurewei Technologies, Inc. Method and apparatus for preferred path route information distribution and maintenance
CN108494684B (zh) * 2018-03-30 2021-01-26 新华三技术有限公司 创建隧道的方法及装置
US10587937B2 (en) * 2018-04-09 2020-03-10 Futurewei Technologies, Inc. Packet and optical integration
WO2019209480A1 (en) 2018-04-26 2019-10-31 Futurewei Technologies, Inc. Resource reservation and maintenance for preferred path routes in a network
US10454715B1 (en) 2018-05-03 2019-10-22 At&T Intellectual Property I, L.P. Virtual private wire service interworking
WO2019212678A1 (en) 2018-05-04 2019-11-07 Futurewei Technologies, Inc. Explicit backups and fast re-route mechanisms for preferred path routes in a network
CN112154628B (zh) * 2018-05-17 2022-10-14 瑞典爱立信有限公司 拆除经过通信网络的标签交换路径
WO2019236221A1 (en) 2018-06-04 2019-12-12 Futurewei Technologies, Inc. Preferred path route graphs in a network
US10630581B2 (en) * 2018-06-19 2020-04-21 Juniper Networks, Inc. Dynamic tunnel report for path computation and traffic engineering within a computer network
EP3588857B1 (en) 2018-06-25 2023-06-07 Juniper Networks, Inc. Using multiple ethernet virtual private network (evpn) routes for corresponding service interfaces of a subscriber interface
US10693679B2 (en) 2018-06-25 2020-06-23 Juniper Networks, Inc. Using multiple ethernet virtual private network (EVPN) routes for corresponding service interfaces of a subscriber interface
CN108809797B (zh) * 2018-07-26 2020-09-08 哈尔滨工业大学（威海） 一种vpn控制装置，软件定义vpn实现系统及方法
CN110830352B (zh) 2018-08-07 2022-09-23 中兴通讯股份有限公司 一种vpn跨域的实现方法、装置和边界节点
EP4333392A3 (en) * 2018-10-19 2024-05-29 Huawei Technologies Co., Ltd. Secure sd-wan port information distribution
WO2020097760A1 (en) * 2018-11-12 2020-05-22 Telefonaktiebolaget Lm Ericsson (Publ) Methods, network element and computer readable media for monitoring lsp health in a sr enabled network
CN111355657B (zh) * 2018-12-24 2022-06-24 中兴通讯股份有限公司 一种流量工程路径建立方法及装置和系统
CN112217651B (zh) * 2019-07-09 2023-07-07 中兴通讯股份有限公司 融合网络的路径标签确定方法及装置
CN112217724B (zh) * 2019-07-11 2024-06-18 中兴通讯股份有限公司 路径管理方法、装置、网络设备和可读存储介质
CN112511436B (zh) * 2020-03-03 2024-02-02 中兴通讯股份有限公司 Bier网络的信令配置方法、装置和存储介质
US11502946B2 (en) * 2020-03-10 2022-11-15 Juniper Networks, Inc. Distributed label assignment for labeled routing protocol routes
US11444869B2 (en) * 2020-03-10 2022-09-13 Cisco Technology, Inc. Enhanced segment routing
CN115211088B (zh) * 2020-03-12 2023-11-28 华为技术有限公司 用于恢复网络中标签交换路径的装置和方法
US11233733B2 (en) 2020-03-26 2022-01-25 Verizon Patent And Licensing Inc. Systems and methods for SR-MPLS to SRv6 interworking
EP3937502A1 (en) * 2020-05-28 2022-01-12 Wangsu Science & Technology Co., Ltd. Method, apparatus and device for pushing video stream, and storage medium
CN112087387B (zh) * 2020-08-14 2022-04-19 烽火通信科技股份有限公司 一种网络处理器和数据包转发方法
CN114079634B (zh) * 2020-08-21 2024-03-12 深圳市中兴微电子技术有限公司 一种报文转发方法、装置及计算机可读存储介质
CN112532520B (zh) * 2020-10-28 2022-04-05 中盈优创资讯科技有限公司 基于pce的te-lsp的实现方法及装置
CN112398967B (zh) * 2020-11-13 2023-03-14 中盈优创资讯科技有限公司 一种基于sr的集中式流量调度方法及装置
US11463916B2 (en) * 2021-01-08 2022-10-04 Cisco Technology, Inc. Reliable and available wireless forwarding information base (FIB) optimization
CN116112540B (zh) * 2021-11-10 2025-06-13 华为技术有限公司 业务部署方法、装置及系统
CN115942416A (zh) * 2022-12-14 2023-04-07 中盈优创资讯科技有限公司 一种解耦的控制集中化的装置
CN118474825A (zh) * 2023-02-08 2024-08-09 中兴通讯股份有限公司 卫星网络通信方法、装置、设备及介质

Family Cites Families (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6374303B1 (en) * 1997-11-17 2002-04-16 Lucent Technologies, Inc. Explicit route and multicast tree setup using label distribution
US20030088699A1 (en) * 1999-11-04 2003-05-08 James V. Luciani System, device, and method for supporting virtual private networks in a label switched communication network
JP2003032280A (ja) * 2001-07-16 2003-01-31 Fujitsu Ltd コネクション型通信ネットワークにおけるリンク識別子の割当システム
US8289964B2 (en) * 2004-06-28 2012-10-16 Rockstar Bidco, L.P. Layer-2 to MPLS service mediation architecture
JP2006129359A (ja) 2004-11-01 2006-05-18 Ntt Communications Kk マルチキャスト回線の確立方法、その方法を用いた通信システム、通信装置、通信装置の制御方法、およびプログラム
KR100693059B1 (ko) 2005-01-24 2007-03-12 삼성전자주식회사 Ｍｐｌｓ 기반의 ｖｐｎ 제공 장치 및 방법
CN100525227C (zh) * 2005-03-10 2009-08-05 华为技术有限公司 接入网实现综合业务接入的方法
US7599302B2 (en) * 2005-07-19 2009-10-06 Cisco Technology, Inc. Dynamic enforcement of MPLS-TE inter-domain policy and QoS
US7710872B2 (en) 2005-12-14 2010-05-04 Cisco Technology, Inc. Technique for enabling traffic engineering on CE-CE paths across a provider network
CN101286892B (zh) * 2007-04-12 2012-09-05 华为技术有限公司 进行业务恢复的装置和方法
JP5020896B2 (ja) * 2008-06-17 2012-09-05 株式会社日立製作所 ノード及び通信システム
US7953097B2 (en) 2009-01-09 2011-05-31 Alcatel Lucent Neighbour discovery protocol mediation
US8351418B2 (en) 2009-02-19 2013-01-08 Futurewei Technologies, Inc. System and method for point to multipoint inter-domain multiprotocol label switching traffic engineering path calculation
US8468258B2 (en) 2010-07-26 2013-06-18 Alcatel Lucent IPv6 generation to trigger a virtual leased line service
US9231851B2 (en) 2011-01-31 2016-01-05 Futurewei Technologies, Inc. System and method for computing point-to-point label switched path crossing multiple domains
HUE024948T2 (en) * 2011-02-19 2016-01-28 Deutsche Telekom Ag Looping MPLS-UTAK to MPLS Networks with no connection level
US8964732B2 (en) * 2011-03-25 2015-02-24 Futurewei Technologies, Inc. System and method for topology transparent zoning in network communications
US9054951B2 (en) * 2011-05-02 2015-06-09 Cisco Technology, Inc. Detecting and avoiding routing loops with BGP route server extensions
EP2697944A4 (en) 2011-09-20 2014-03-19 Huawei Tech Co Ltd SYSTEM AND METHOD FOR CALCULATING A SHORTEST INTER-DOMAIN CONSTRAINT PATH IN A COMPUTER NETWORK
KR101576412B1 (ko) 2012-04-04 2015-12-09 알까뗄 루슨트 레이블 스위치 라우터(lsr) 과부하 보호를 구현하기 위한 시스템 및 방법
CN104365072B (zh) * 2012-04-05 2018-11-06 瑞典爱立信有限公司 计算通过包括多个网络域的网络的端到端路径的装置和方法
US8953500B1 (en) * 2013-03-29 2015-02-10 Juniper Networks, Inc. Branch node-initiated point to multi-point label switched path signaling with centralized path computation
US9178809B1 (en) * 2013-07-01 2015-11-03 Juniper Networks, Inc. End-to-end traffic engineering label switched paths in seamless MPLS
US10397107B2 (en) 2013-09-30 2019-08-27 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus of adapting an association of physical resources with a summarized resource
US9450864B2 (en) 2013-10-11 2016-09-20 Futurewei Technologies, Inc. Using PCE as SDN controller
US9680740B2 (en) * 2013-11-08 2017-06-13 Avago Technologies General Ip (Singapore) Pte. Ltd. Service multiplexing and demultiplexing using a single pseudowire service/label switched path label in a multiprotocol label switching network

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
CN107637031B (zh) 2020-07-14
US20170012895A1 (en) 2017-01-12
US10412019B2 (en) 2019-09-10
CN107637031A (zh) 2018-01-26
EP3731474B1 (en) 2022-11-30
JP6966419B2 (ja) 2021-11-17
EP3295622B1 (en) 2020-09-09
WO2017005157A1 (en) 2017-01-12
EP3295622A4 (en) 2018-05-30
KR102057980B1 (ko) 2019-12-20
KR20180014096A (ko) 2018-02-07
CN111865796A (zh) 2020-10-30
JP2018519763A (ja) 2018-07-19
EP3731474A1 (en) 2020-10-28
CN111865796B (zh) 2024-02-02
EP3295622A1 (en) 2018-03-21

Similar Documents

Publication Publication Date Title
ES2830182T3 (es) Controladores centrales de elementos de cálculo de rutas (PCECC) para servicios de red
US10785148B2 (en) OSPF extensions for flexible path stitchng and selection for traffic transiting segment routing and MPLS networks
US8488491B2 (en) Compressed virtual routing and forwarding in a communications network
US7733883B2 (en) Method for implementing a virtual leased line
US10003531B2 (en) Method for establishing tunnel, method for allocating label, device and network system
US9306855B2 (en) System and method for using label distribution protocol (LDP) in IPv6 networks
EP3417578B1 (en) Is-is extensions for flexible path stitching and selection for traffic transiting segment routing and mpls networks
US8385341B2 (en) Ethernet frame broadcast emulation
US20120287818A1 (en) Multipoint-to-multipoint service for a communications network
US20160006614A1 (en) Source Routing Using Path Computation Elements
EP3886378B1 (en) Seamless end-to-end segment routing across metropolitan area networks
EP3890262B1 (en) Routing distributing method, device and system
WO2017168219A1 (en) Method and apparatus for pseudo-wire setup and maintenance using intermediate system to intermediate system (is-is)
WO2006002598A1 (en) A vpn system of a hybrid-site hybrid backbone network and an implementing method thereof
CN114205187B (zh) 一种适用于OptionC跨域的MPLS-VPN的端到端路径计算方法及装置
CN101557334A (zh) Mpls vpn、其vpn多实例用户边缘设备及其实现方法
Smith Introduction to MPLS
Mehmeti MPLS AND ITS APPLICATION