ES2434261T3 - Proporcionar información de retorno a un elemento de cálculo de ruta - Google Patents

Proporcionar información de retorno a un elemento de cálculo de ruta Download PDF

Info

Publication number
ES2434261T3
ES2434261T3 ES10701636T ES10701636T ES2434261T3 ES 2434261 T3 ES2434261 T3 ES 2434261T3 ES 10701636 T ES10701636 T ES 10701636T ES 10701636 T ES10701636 T ES 10701636T ES 2434261 T3 ES2434261 T3 ES 2434261T3
Authority
ES
Spain
Prior art keywords
route
route calculation
connection
attempt
result
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
ES10701636T
Other languages
English (en)
Inventor
Dávid JOCHA
András Kern
András CSÁSZÁR
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2434261T3 publication Critical patent/ES2434261T3/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
    • H04L45/00—Routing or path finding of packets in data switching 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/02—Topology update or discovery
    • H04L45/10—Routing in connection-oriented networks, e.g. X.25 or ATM
    • 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
    • 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/62—Wavelength based

Landscapes

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

Abstract

Un método para su uso en un Cliente de Cálculo de Ruta (24) de un nodo en una red, comprendiendo el método:enviar un mensaje de solicitud (52) a un Elemento de Cálculo de Ruta (28) de la red para el cálculo de unaruta; Recibir un mensaje de respuesta (54) desde el Elemento de Cálculo de Ruta que comprende informaciónidentificativa de una ruta calculada; e Intentar (58) el establecimiento de una conexión basándose en la ruta calculada; caracterizado porque el método comprende también: recibir desde el Elemento de Cálculo de Ruta una solicitud de información de retorno acerca de un resultadodel intento de establecimiento de la conexión; y reportar (64) al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión.

Description

Proporcionar información de retorno a un elemento de cálculo de ruta
CAMPO TÉCNICO La presente invención se refiere al cálculo de una ruta a través de una red, y en particular a la comunicación entre un cliente de cálculo de ruta y un elemento de cálculo de ruta, con el fin de permitir un cálculo de ruta mejorado.
ANTECEDENTES La Conmutación de Etiquetas de Multiprotocolo Generalizado (GMPLS – Generalized Multiprotocol Label Switching, en inglés) proporciona un marco de plano de control para gestionar tecnologías de red de paquetes o de circuitos conmutados orientadas a una conexión arbitraria. Dos funciones de protocolo importantes de la GMPLS son la sincronización de información de Ingeniería del Tráfico (TE – Traffic Engineering y la gestión de la conexión. La primera función sincroniza las bases de datos de información de TE del nodo en la red y es implementada con Ingeniería del Tráfico de primera Ruta Más Corta Abierta (OSPF-TE – Open Shortest Path First Traffic Engineering, en inglés) o Sistema Intermedio para Ingeniería del Tráfico de Sistema Intermedio (ISIS-TE - Intermediate System to Intermediate System Traffic Engineering, en inglés). La segunda función, que gestiona la conexión, está implementada mediante Ingeniería del Tráfico de Protocolo de Reserva de Recurso (RSVP-TE – Resource ReSerVation Protocol-Traffic Engineering, en inglés).
El Protocolo de Reserva de Recurso (RSVP – Resource ReSerVation Protocol, en inglés) se describe en el documento RFC 2205 de IETF, y su extensión para soportar aprovisionamiento de túneles conducido mediante Ingeniería del Tráfico (RSVP-TE) se describe en el documento RFC 3209 de IETF.
Basándose en la información de TE, la GMPLS soporta esquemas de cálculo de ruta de salto a salto, ingreso y centralizado. En el cálculo de ruta de salto a salto, cada nodo determina sólo el siguiente salto, de acuerdo con su mejor conocimiento. En el caso del esquema de cálculo de ruta de ingreso, el nodo de ingreso, que es el nodo que solicita la conexión, especifica también la ruta.
Finalmente, en el esquema de cálculo de ruta centralizado, una función del nodo que solicita una conexión, denominada Cliente de Cálculo de Ruta (PCC – Path Computation Client, en inglés), solicita un elemento especial, denominado Elemento de Cálculo de Ruta (PCE – Path Computation Element, en inglés) para llevar cabo los cálculos de ruta, como se describe en el documento RFC 4655 de IETF: “A Path Computation Element (PCE)-Based Architecture”. En este esquema, la comunicación entre el Cliente de Cálculo de Ruta y el Elemento de Cálculo de Ruta puede estar de acuerdo con el Protocolo de Comunicación de Cálculo de Ruta (PCEP – Path Computation Communication Protocol, en inglés), descrito en el documento RFC 5440 de IETF.
Cuando un PCC se inicia o requiere el cálculo de un conjunto de rutas, el PCC selecciona primero uno o más PCEs. Una vez que el PCC ha seleccionado un PCE, establece una sesión al PCE. Cuando recibe una solicitud de conexión, el PCC envía una solicitud de cálculo de ruta al PCE (mensaje PCReq -Solicitud de PC) que contiene una variedad de objetos que especifican el conjunto de restricciones y atributos para que la ruta sea calculada. Cada solicitud está identificada de manera única por un par de número de id de solicitud (Request-ID-number, en inglés) y la dirección de PCC-PCE.
Cuando recibe una solicitud de cálculo de ruta desde un PCC, el PCE calcula rutas para la solicitud. Si consigue calcular rutas que satisfagan las restricciones dadas, el PCE envía una respuesta al PCC en la cual enumera la ruta
o rutas calculada o calculadas. Si no se encuentra ninguna ruta adecuada, el PCE responde al PCC e indica que no se ha encontrado ninguna ruta para la solicitud. En PCEP, el mensaje PCRep (PC Response, en inglés) implementa la respuesta del PCE.
Hay varias circunstancias en las cuales un PCE puede desear notificar a un PCC un evento específico. Por ejemplo, supóngase que el PCE repentinamente se sobrecarga, lo que conduce potencialmente a tiempos de respuesta inaceptables. El PCE puede desear notificar a uno o más PCCs que algunas de sus solicitudes (listadas en la notificación) no serán satisfechas o pueden experimentar retardos inaceptables. El mensaje PCNtf (PC Notification, en inglés) se utiliza en algunos casos. El mensaje de Error de PCEP (también llamado mensaje PCErr) es enviado para indicar situaciones de error de protocolo, en las cuales se cumple una condición de error de protocolo o cuando la solicitud no cumple la especificación de PCEP.
El documento de RFC 5521 de IETF, “Extension to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions” define extensiones al PCEP para excluir recursos particulares del cálculo de ruta. Permite una exclusión mandatoria y deseada por el PCC de cualquier recurso, tal como interfaces, nodos y dominios. Por ejemplo, si el PCC sabe de un fallo de recurso, puede especificarlo como un Objeto de Excluir Ruta (XEO – Exclude Route Object, en inglés), para indicar al PCE que lo evite para este cálculo de ruta específico.
Un borrador del grupo de trabajo sugiere la extensión del PCEP con capacidad de cálculo de ruta sincronizada. Esto permite que el PCC solicite múltiples cálculos de ruta en paralelo, por ejemplo una ruta protegida con las correspondientes rutas de protección. El documento RFC 5557 de IETF, “Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization”, proporciona capacidad de optimización de ruta global con solicitudes de cálculo de ruta concurrentes.
Otros documentos individuales y de grupo de trabajo tratan el desarrollo de la descripción de la solicitud del cálculo de ruta con el soporte de tecnología detallada específica así como restricciones de multi-tecnología, sin hacer cambios al esquema de comunicación de PCE global.
El PCE, con el fin de poder proporcionar rutas, tiene que tener una visión de la red y de los recursos libres. En GMPLS, los nodos del plano de control participantes sincronizan su visión de la red. Esto es, anuncian la información de TE de sus recursos locales y recogen el anuncio de otros nodos. Con este propósito utilizan una versión extendida de la Ingeniería del Tráfico de los protocolos de encaminamiento, tal como OSPF-TE, como se describe en el documento RFC 3630 de IETF: “Traffic Engineering (TE) extensions to OSPF version 2”, o ISIS-TE, como se describe en el documento RFC 3784 de IETF: “Intermediate System to Intermediate System (ISIS) Extensions for Traffic Engineering (TE)”.
El PCE participa en el procedimiento de anuncio de recurso y así recoge la información de TE, de la misma manera que los otros nodos. El PCE también puede anunciar sus capacidades a los PCCs utilizando OSPF-TE, como se describe en el documento RFC 5088 de IETF: “OSPF Protocol Extensions for Path Computation Element (PCE) Discovery”, o ISIS-TE como se describe en el documento RFC 5089 de IETF: “IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery”.
El documento de borrador individual de IETF “draft-lee-pce-ted-alternatives-02.txt” proporciona un método alternativo en el que el PCE recoge la información de TE directamente de los nodos.
El protocolo Protocolo de Reserva de Recurso (RSVP – Resource ReSerVation Protocol, en inglés) descrito anteriormente definía un simple pero efectivo método para que cualquier nodo intermedio reporte fallos relativos al flujo, a saber el objeto ERROR_SPEC. Este objeto codifica el nodo que reporta el problema, así como la naturaleza del error, con una ayuda de un código de error importante y un valor de error detallado. A medida que el RSVP-TE se desarrolla, se especifican nuevos códigos de error y nuevos valores. El par de código de error y de valor de error es por lo tanto adecuado para especificar la causa del fallo de la conexión.
Al mismo tiempo, el objeto ERROR_SPEC no es capaz de describir de manera precisa qué recurso provocó el fallo, dado que sólo define al nodo que está reportando. El documento RFC 3473 de IETF define un nuevo tipo de objeto ERROR_SPEC que no sólo codifica al nodo que está reportando, sino que también proporciona un contenedor para transportar Tipo-Longitud-Valores (TLVs – Type-Length-Values, en inglés) para identificar la interfaz de plano de datos problemática. El documento RFC 4920 de IETF, “Crankback Signalling Extensions for MPLS and GMPLS RDVP-TE” permite el uso de otros TLVs para describir otros detalles del problema. Con esta extensión, el RSVP-TE podría proporcionar una información más precisa acerca de la ubicación y del contexto del fallo al nodo de ingreso que solicitó la conexión.
Si un establecimiento de LSP falla, el nodo de inicio es informado a través de mecanismos de señalización de error del RSVP-TE, y el nodo de inicio puede solicitar del PCE una nueva ruta al mismo destino. Este nuevo mensaje PCReq puede contener información adicional para excluir el recurso que provoca el error específico, tal como el nodo, la interfaz, el número de Sistema Autónomo (AS – Autonomous System, en inglés), el ID del Grupo de Enlace de Riesgo Compartido (SRLG – Shared Risk Link Group, en inglés), la etiqueta o el tipo de conmutación, listándolos como sub-objetos del XRO. Esto podría proporcionar algunas pistas al PCE acerca de la situación del error, pero no siempre es posible señalar de manera precisa la ubicación o la causa exacta. Un XRO puede ser añadido a una solicitud de ruta en muchas situaciones, y así, la presencia de un XRO no necesariamente significa que un error ocurrió durante el establecimiento de ruta, y así utilizar el XRO como un indicador de error no resulta adecuado.
Además, este mecanismo que proporciona información del error requiere una subsiguiente solicitud de cálculo de ruta. Cuando el nodo que solicita la conexión cancela la señalización como resultado del establecimiento fallido, el PCE no será explícitamente informado acerca del fallo o del éxito del establecimiento de la conexión.
Aunque el PCE puede inferir el éxito del establecimiento de la conexión cuando recibe actualizaciones a los recursos de red disponibles, este método implícito no asegura un mapeo de uno a uno fiable entre las rutas calculadas y los cambios notificados a los recursos. Además, la ausencia de cambios de recurso no necesariamente significa que el establecimiento de la conexión ha fallado.
Las carencias de la técnica anterior significan que el PCE puede obtener sólo información limitada o inapropiada acerca de la factibilidad de las rutas calculadas. Así, puede aplicar sólo conjuntos de políticas limitados que impactan en el rendimiento de la red. Por ejemplo, podría inferir un fallo y decidir evitar un recurso particular cuando
establece una conexión futura, incluso aunque el fallo fuese uno transitorio. Alternativamente, el PCE podría tener insuficiente información para inferir el fallo de un recurso, y tendría en cuenta entonces el recurso fallido cuando establece una conexión futura. En cualquier caso, esto podría provocar tiempos de establecimiento de conexión largos y más cabecera de señalización provocada por mensajes de señalización sin éxito y por ello superfluos.
El documento EP 2.009.848 describe un método para el cálculo de ruta en una red de etiquetas conmutadas.
COMPENDIO El objeto de la presente invención es permitir que el PCE obtenga información útil del PCC, que el PCE podrá utilizar cuando establezca futuras conexiones.
De acuerdo con un primer aspecto de la presente invención, se proporciona un método para su uso en un Cliente de Cálculo de Ruta de un nodo en una red. El método comprende: enviar un mensaje de solicitud a un Elemento de Cálculo de Ruta de la red para el cálculo de una ruta; recibir un mensaje de respuesta del Elemento de Cálculo de Ruta que comprende información que identifica una ruta calculada; e intentar establecer una conexión basándose en la ruta calculada. El método comprende también: recibir desde el Elemento de Cálculo de Ruta una solicitud de información de retorno acerca de un resultado del intento de establecer la conexión; y reportar al Elemento de Cálculo de Ruta el resultado del intento de establecer la conexión.
Esto permite que el PCE refine su visión acerca de la red y proporcione mejores respuestas a futuras solicitudes de cálculo de ruta.
El método puede comprender reportar el resultado del intento de establecer la conexión en un mensaje de protocolo de Elemento de Cálculo de Ruta, por ejemplo por medio de un objeto de protocolo de Elemento de Cálculo de Ruta,
o por medio de un Tipo-Longitud-Valor de un objeto de Protocolo de Elemento de Cálculo de Ruta.
Reportando al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión puede comprender: reportar si el intento tuvo éxito o no; y si el intento fue fallido, proporcionando información adicional acerca del fallo. Por ejemplo, el reporte puede proporcionar información adicional acerca de una causa del fallo y/o de una situación del fallo.
En algunas realizaciones, la solicitud de información de retorno acerca del resultado del intento de establecimiento de la conexión está incluida en el mensaje de respuesta del Elemento de Cálculo de Ruta que comprende información que identifica la ruta calculada. En ese caso, el mensaje de respuesta del Elemento de Cálculo de Ruta que comprende información identificativa de la ruta calculada puede incluir un objeto que identifica el mensaje de solicitud; y el método puede comprender también incluir el objeto que identifica el mensaje de solicitud cuando reporta al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión.
El método puede comprender reportar al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión como parte de un mensaje de solicitud subsiguiente al Elemento de Cálculo de Ruta para el cálculo de una ruta.
El método puede comprender también anunciar que el Cliente de Cálculo de Ruta es capaz de proporcionar tales reportes al Elemento de Cálculo de Ruta.
De acuerdo con un segundo aspecto de la invención, se proporciona un método, para su uso en un Elemento de Cálculo de Ruta de una red, que comprende: recibir desde el Cliente de Cálculo de Ruta de un nodo de la red una solicitud para el cálculo de una ruta; calcular una ruta basándose en la solicitud; y enviar un mensaje de respuesta al Cliente de Cálculo de Ruta que contiene información identificativa de la ruta calculada. El método comprende también: enviar al Cliente de Cálculo de Ruta una solicitud de información de retorno acerca de un resultado del intento de establecimiento de la conexión; y recibir desde el Cliente de Cálculo de Ruta un reporte acerca del resultado del intento de establecimiento de la conexión.
El reporte acerca del resultado del intento de establecimiento de la conexión puede ser entonces utilizado en futuros cálculos de ruta.
El reporte acerca del resultado del intento de establecimiento de la conexión puede ser recibido en un mensaje de protocolo de Elemento de Cálculo de Ruta, por ejemplo por medio de un objeto de protocolo de Elemento de Cálculo de Ruta, o por medio de un Tipo-Longitud-Valor de un objeto de protocolo de Elemento de Cálculo de Ruta.
La etapa de recibir el reporte del Cliente de Cálculo de Ruta puede comprender: recibir un reporte acerca de si el intento tuvo éxito o no; y si el intento fue fallido, proporcionar información adicional acerca del fallo. Por ejemplo, el reporte puede proporcionar información adicional acerca de una causa del fallo y/o de una situación del fallo.
El Elemento de Cálculo de Ruta puede incluir la solicitud de información de retorno acerca del resultado del intento de establecimiento de la conexión en el mensaje de respuesta al Cliente de Cálculo de Ruta. En ese caso, un objeto que identifica la solicitud puede estar incluido en el mensaje de respuesta al Cliente de Cálculo de Ruta y el método puede comprender también recibir el objeto que identifica el mensaje de solicitud cuando recibe el reporte acerca del
5 resultado del intento de establecimiento de la conexión.
En algunas realizaciones, el método comprende también: recibir del Cliente de Cálculo de Ruta el resultado del intento de establecimiento de la conexión como parte de un subsiguiente mensaje de solicitud desde el Cliente de Cálculo de Ruta para el cálculo de una ruta.
10 El método puede comprender enviar la solicitud de información de retorno habiendo recibido sólo notificación de que el Cliente de Cálculo de Ruta es capaz de proporcionar tales reportes al Elemento de Cálculo de Ruta.
De acuerdo con otros aspectos de la invención, se proporciona un Cliente de Cálculo de Ruta y un Elemento de 15 Cálculo de Ruta configurados para llevar a cabo tales métodos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama que ilustra una parte de una red que opera de acuerdo con aspectos de la invención.
20 La Figura 2 es un primer diagrama de señalización, que ilustra métodos de acuerdo con la invención. La Figura 3 es un segundo diagrama de señalización, que ilustra métodos de acuerdo con la invención. La figura 4 ilustra una forma de un primer objeto de reporte utilizado de acuerdo con un aspecto de la invención. La Figura 5 ilustra una forma de un segundo objeto de reporte utilizado de acuerdo con un aspecto de la
25 invención.
DESCRIPCIÓN DETALLADA La Figura 1 muestra una red 10 basada en Conmutación de Etiquetas de Multiprotocolo Generalizado (GMPLS -Generalized Multiprotocol Label Switching, en inglés), que tiene múltiples nodos 12, 14, 16, 18, 20. Resultará
30 evidente que, en la práctica, es probable que una red contenga muchos más nodos de los que se muestran en esta memoria, pero este número es suficiente para una comprensión de la presente invención. Los nodos 12, 14, 16, 18, 20 están interconectados, como se muestra mediante flechas en la Figura 1. El nodo 12 tiene una interfaz 22, para controlar sus interacciones con otros nodos, y un Cliente de Cálculo de Ruta (PCC – Path Computation Client, en inglés) 24, cuya acción se describirá con más detalle en lo que sigue, ejecutándose en un procesador 26. Resultará
35 evidente que el nodo 12 tiene varias otras características convencionales, pero esta descripción es suficiente para una comprensión de la presente invención. Los otros nodos 14, 16, 18, 20 pueden ser esencialmente similares al nodo 12, pero una comprensión de la operación del nodo 12 es suficiente para una comprensión de la presente invención.
40 El nodo 12 tiene una conexión a un Elemento de Cálculo de Ruta (PCE – Path Computation Element, en inglés) 28, como hacen otros nodos de la red 10. El Elemento de Cálculo de Ruta 28 tiene una interfaz 30, para conectarse con los clientes de cálculo de ruta de otros nodos, y un procesador 32 para controlar su operación.
Como se describirá con más detalle en lo que sigue, un aspecto de la presente invención es que, mediante la
45 solicitud por parte del PCE, el PCC en el nodo de ingreso de la conexión informará al PCE de si el establecimiento de la conexión basándose en la ruta calculada tuvo éxito o bien ocurrió un error.
Con el fin de permitir que esto tenga lugar, es preferible que cada PCC señale o anuncie su capacidad para enviar tales reportes de establecimiento de conexión. Por ejemplo, esta capacidad podría ser comunicada al PCE durante
50 el establecimiento de comunicación PCC-PCE, es decir, cuando las dos entidades establecen la conexión. El objeto OPEN puede ser extendido con un Tipo-Longitud-Valor (TLV – Type-Length-Value, en inglés) que describe esta capacidad del nodo, o puede utilizarse una marca de no asignado del objeto OPEN. Alternativamente, la capacidad del PCC puede ser anunciada utilizando una Ingeniería del Tráfico de primera Ruta Más Corta Abierta (OSPF-TE – Open Shortest Path First Traffic Engineering, en inglés) o el Sistema Intermedio a Sistema Intermedio de Ingeniería
55 del Tráfico (ISIS-TE – Intermediate System to Intermediate Traffic Engineering, en inglés) para anunciar las capacidades del nodo, como se describe en el documento RFC 5073. Una implementación podría utilizar uno de los bits no asignados hasta ahora de la Capacidad del Nodo (sub) TLV. Una tercera alternativa es señalar la capacidad en el mensaje que solicita el cálculo de ruta, esto es, por solicitud. De nuevo un bit no utilizado en el mensaje podría ser utilizado como una marca con este propósito.
60 Utilizar los mensajes de establecimiento de sesión de PCEP con este propósito tiene la ventaja de que el objeto OPEN está definido para contener varias características de sesión. Señalar esta capacidad por solicitud resulta beneficioso si el PCC desea limitar el número de reportes de establecimiento de conexión que tuvo que enviar.
Cualquiera de estas alternativas permite que el PCE conozca que el PCC tiene la capacidad extra descrita en esta memoria, y así el PCE puede pedir al PCC que reporte el resultado del establecimiento de la conexión.
La Figura 2 es un diagrama de flujo de señal, que ilustra un flujo de mensajes para un procedimiento de establecimiento de Ruta de Etiquetas Conmutadas (LSP – Label Switched Path, en inglés) típico en el caso en el que se utilice un esquema de cálculo de ruta centralizado. Específicamente, se asume en esta memoria que el nodo 12 es el nodo de ingreso, es decir, el nodo en el que los datos 50 entran en la red 10 y solicitan una conexión, y que el nodo 12 desea establecer un LSP a un nodo de salida, por ejemplo el nodo 18.
Con el fin de establecer la ruta, el PCC 24 del nodo 12 selecciona primero un PCE, en este caso el PCE 28. Una vez que el PCC 24 ha seleccionado el PCE 28, establece una sesión al PCE (si la sesión no ha sido ya establecida) y envía un mensaje de solicitud de cálculo de ruta 52 al PCE, en forma de un mensaje PCReq, como se define en el Protocolo de comunicación de cálculo de ruta (PCEP – Path Computation Communication Protocol, en inglés). El mensaje PCReq puede contener objetos que especifiquen el conjunto de restricciones y atributos para que la ruta sea calculada. El mensaje PCReq contiene el objeto Parámetros de Solicitud (RP – Request Parameters, en inglés), que contiene el número de ID de Solicitud (y algunas marcas y datos adicionales). Cada solicitud es identificada de manera única por el par del número ID de solicitud y la dirección del PCC-PCE.
Cuando recibe una solicitud de cálculo de ruta desde el PCC 24, el PCE 28 intenta calcular una ruta (es decir, un conjunto de nodos intermedios desde el nodo de ingreso 12 al nodo de salida 18) para la solicitud. Como se ha definido en el Protocolo de Comunicación de Cálculo de Ruta (PCEP – Path Computation Communication Protocol, en inglés), un mensaje PCRep (Respuesta de PC - PC Response, en inglés) implementa la respuesta del PCE. Si el PCE 28 consigue calcular una ruta que satisfaga las restricciones dadas, envía una respuesta 54 al PCC 24 en la cual enumera la ruta o rutas calculada o calculadas por medio de un Objeto de Ruta Explícita (ERO – Explicit Route Object, en inglés). El mensaje de respuesta 54 también incluye el objeto RP que contiene el número ID de solicitud, de manera que el mensaje de respuesta 54 pueda ser correctamente asociado con el mensaje de solicitud 52.
Si no pueden encontrarse rutas adecuadas, el PCE responde al PCC con un mensaje PCRep con un objeto “ninguna ruta”. Entonces el Nodo 12 puede cancelar el establecimiento de ruta y enviar un error a la función de solicitud o puede cambiar las restricciones y reintentar el cálculo de ruta.
Como se ha explicado anteriormente, el PCE 28 habrá sido informado de que el PCC 24 en el nodo de ingreso 12 acepta mensajes PCRep en los que el PCE solicita un reporte de resultado de establecimiento de la conexión. Así, una respuesta 54 al PCC 24 enumerando una ruta calculada puede tener un conjunto de marcas, con el fin de indicar que se ha solicitado un reporte del establecimiento de la conexión. Si se solicita el reporte acerca del resultado del establecimiento de la conexión, el PCE 28 puede tomar otras etapas necesarias para preparar la recepción del reporte. Por ejemplo, el PCE 28 puede almacenar temporalmente la solicitud original completa, o puede retardar otras solicitudes de cálculo.
Así, en este ejemplo, el PCE solicita información de retorno acerca del resultado del intento de establecimiento de la conexión, estableciendo una marca en el mensaje que identifica la ruta calculada. No obstante, es igualmente posible que el PCE pueda enviar un mensaje solicitando información de retorno acerca del resultado del intento de establecimiento de la conexión, separadamente del mensaje que identifica la ruta calculada. En ese caso, el mensaje solicitando información de retorno podría ser enviado antes, o después del mensaje que identifica la ruta calculada.
Si la marca es establecida en el mensaje de respuesta 54, el PCC 24 almacena (en 56) el ID de la solicitud que identifica de manera única esta solicitud (obtenida del objeto RP), de manera que pueda referirse de nuevo a él cuando envía el reporte del establecimiento.
Tras recibir una respuesta positiva, en forma de un mensaje PCRep que contiene una ruta, el nodo de ingreso 12 intenta establecer la ruta de datos utilizando señalización de protocolo de ReSerVa de Recurso (RSVP – Resource ReSerVation Protocol, en inglés) 58. Más pronto o más tarde, el nodo de ingreso 12 recibirá en el mensaje 60 un mensaje Resv (indicando un establecimiento de ruta con éxito y reserva de recurso) o un mensaje PathErr indicando fallo durante el establecimiento. Cualquier mensaje de PathErr especifica objetos de error. Por ejemplo, incluye el objeto ErrorSpec que detalla la situación y causa del fallo.
Habiendo recibido el mensaje Resv o el mensaje PathErr, el PCC 24 llama (en 62) al objeto RP almacenado que contiene el número de ID de solicitud de PCEP para la sesión de RSVP. El PCC 24 envía a continuación un mensaje 64 al PCE 28 conteniendo el objeto RP que incluye este número de ID de solicitud, y conteniendo también un reporte que señala el éxito o fallo del establecimiento. En el caso de que el intento de establecimiento de ruta tuviese éxito, el mensaje 64 también puede contener información del objeto ErrorSpec, detallando la causa y la situación del fallo. La forma del mensaje PERep 64 se describe con más detalle en lo que sigue.
El procedimiento mostrado en la Figura 2 espera un comportamiento dinámico del PCE 28, en el sentido de que no borra los detalles de la solicitud inmediatamente después de responder a ella. En algunas realizaciones de la invención, los PCEs pueden ser incapaces de almacenar tal información, o ésta puede ser considerada no deseable.
La Figura 3 muestra un procedimiento que puede ser utilizado en el caso en el que el comportamiento del PCE 28 no sea dinámico. El procedimiento mostrado en la Figura 3 es de alguna manera similar al mostrado en la Figura 2, y las etapas que son las mismas se nombran mediante los mismos números de referencia, y no se describen de nuevo.
En este caso, cuando el PCC 24 recibe la respuesta 54 enumerando la ruta calculada, que tiene una marca establecida, indicando que se ha solicitado un reporte de resultado de establecimiento de conexión, el PCC 24 almacena (en 70) no sólo el ID de la solicitud, sino también su solicitud original y el ERO contenido en la respuesta
54.
A continuación, habiendo recibido el mensaje Rev o el mensaje PathErr en 60, el PCC 24 llama (en 72) no sólo al ID de solicitud de PCEP almacenado para la sesión de RSVP, sino también a su solicitud original y al ERO contenido en la respuesta 54, como el almacenado en 70.
En su mensaje de respuesta PERep 74, el PCC 24 también envía entonces esta información adicional al PCE 28.
Por ello, incluso en este caso, reportar el resultado del cálculo de ruta es significativo, puesto que el PCE 28 puede incorporar esta información en esta base de datos de TE. Aunque proporcionar una referencia de nuevo a la solicitud original no sería significativo, esto es superado porque el PCC extiende el reporte con los detalles de la función original y la respuesta del PCE.
Así, mediante solicitud por parte del PCE, el PCC en el nodo de ingreso a la conexión informa al PCE acerca de si el establecimiento de la conexión basándose en la ruta calculada tuvo éxito, o de si ocurrió un error. En caso de un fallo, el PCC puede proporcionar información detallada acerca de la situación del fallo así como información acerca de la causa del fallo. Mediante un establecimiento de conexión con éxito, el PCC puede proporcionar varios atributos recogidos durante la señalización al PCE. Esto permite al PCE refinar su visión acerca de la red y proporcionar mejores respuestas a futuras solicitudes de cálculo de ruta.
La estructura del reporte en una realización de la invención se describirá ahora con más detalle.
En esta realización, el reporte se proporciona por medio de una extensión al PCEP, actualizando el esquema de comunicación del PCC-PCE estándar. La etapa de reporte puede ser implementada como un mensaje independiente o puede ser incluida en un subsiguiente mensaje de solicitud de cálculo de ruta de la misma solicitud de conexión.
En términos generales, la estructura del reporte de resultado de establecimiento contendrá: una indicación acerca de si el establecimiento de LSP tuvo éxito o no; y, si ocurrió un fallo: una codificación de la causa del fallo; un identificador del nodo en el que el establecimiento de conexión falló; y un identificador de la interfaz del plano de datos en la que el establecimiento de la conexión falló. El mensaje de reporte puede contener: información detallada del recurso que provocó el fallo; y la ruta proporcionada por el PCE (en el caso de un fallo) o la ruta grabada durante el establecimiento de conexión si ése tuvo éxito.
La Figura 4 muestra una posible forma del reporte, en el caso de que la estructura del resultado del establecimiento fuese un objeto de PCEP 90 independiente, y está incluido en el mensaje de PCEP.
La Figura 5 muestra una forma alternativa del reporte, en la que se define como un TLV 92, con el fin de que esté incluido en otros objetos de PCEP.
En cualquier caso, una indicación de si el intento de establecimiento de la ruta tuvo éxito o fue un fallo, junto con la causa del fallo, está codificada con un par de atributo de Código de Error 94 y Valor de Error 96. Ajustar el valor del campo de Código de Error a 0 indica que la conexión ha sido establecida con éxito, y en este caso el contenido del campo del Valor de Error es irrelevante. Un valor distinto de cero para el campo de Código de Error indica un fallo, y junto con el Valor de Error proporciona la causa del error. Los pares de código de error y de valor de error definidos para su uso en RSVP-SE TE aplican también en esta memoria.
El nodo en el que el establecimiento de conexión falló se identifica utilizando su ID de Encaminador de IPv4 o IPv6, también contenido en uno de los objetos de especificación de error de RSVP-TE (ERROR_SPEC). La estructura del resultado del establecimiento lleva este atributo en el campo “ID del Encaminador del nodo de reporte” 98.
La interfaz de plano de usuario que provoca un fallo se identifica como un TLV específico del objeto IF_ID ERROR_SPEC de RSVP-TE. El RSVP-TE puede proporcionar otros TLVs que codifican otros detalles acerca de recursos provocados por fallos como un conjunto de TLVs, tal como los definidos en el documento RFC 4920 de IETF. Esta interfaz de plano de datos identificada y cualquier otro detalle se obtienen del objeto IF_ID ERROR_SPEC de RSVP-TE, y están incluidos en sub-TLVs en el espacio de TLV 100 reservado de la estructura del resultado de establecimiento 90, 92.
5 Como se ha explicado anteriormente, el PCEP es el protocolo utilizado para las solicitudes de ruta y las respuestas entre el PCC y el PCE, estando los formatos y codificaciones del mensaje definidos en el documento RFC 5440 de IETF. La extensión descrita en esta memoria hace posible que el PCC comunique al PCE el resultado de un establecimiento de LSP, incluyendo detalles acerca de la causa de un fallo.
10 La transmisión de la construcción del mensaje PERep 64 ó 74 que incluye el SETUP_RESULT, tal como se describe con referencia a la Figura 4 ó 5, puede conseguirse, por ejemplo, proporcionando extensiones al PCEP, aunque son posibles otros métodos.
15 Una posibilidad es una opción de notificación general, que hace uso del objeto del mensaje de Notificación existente. Define un nuevo tipo de notificación (NT = 3) para indicar que la notificación actual codifica el resultado de un establecimiento de conexión. Cualquier notificación de este tipo siempre debe referirse exactamente a una solicitud de cálculo: esto significa que la notificación del reporte del resultado del establecimiento debe seguir a un solo objetoRP. Si tal objeto NOTIFICACIÓN se refiere a cero o a más de una solicitudes (objetos RP) se debe dar lugar a un
20 mensaje PCErr de objeto no válido. Entre las marcas de control el bit R debe ser 0, mientras que todas las demás marcas están configuradas como son.
El Valor de Notificación (NV – Notification Value, en inglés) codifica el resultado del establecimiento de la conexión. Se definen los siguientes valores:
25 NV = 0: La conexión fue establecida sin crankback (el Código de Error y el Valor de Error del SETUP_RESULT (Resultado del Establecimiento) deben ser puestos a 0). NV = 1: La conexión fue establecida pero con crankback (el Código de Error y el Valor de Error del SETUP_RESULT (Resultado del Establecimiento) deben ser puestos a 0).
30 NV = 2: El establecimiento de la conexión ha fallado (el Código de Error y el Valor del Error del SETUP_RESULT (Resultado del Establecimiento) detallan la causa del fallo).
Para añadir contenido a la notificación, un TLV SETUP_RESULT (Resultado del Establecimiento) puede ser incrustado en el objeto NOTIFICACIÓN. Este TLV lleva varios o todos los atributos obtenidos durante el 35 establecimiento de a conexión.
La ruta calculada por el PCE puede ser proporcionada como un objeto ERO y puede ser incluida en el mensajePCntf justo después del objeto NOTIFICACIÓN.
40 Una alternativa es una opción de mensaje explícito, que define un nuevo mensaje de PCEP completo, denominado Resultado de Cálculo de Ruta de PCE (PCRes – Path Computation Result, en inglés). El formato de ese mensaje se representa a continuación:
Un solo mensaje de PCRes puede contener reportes de resultado de establecimiento de una o más solicitudes de cálculo previas. Cada reporte consiste en un objeto de RP que codifica el identificador de solicitud de cálculo de ruta, 50 un objeto SETUP_RESULT (Resultado del Establecimiento) para codificar el resultado. Opcionalmente, puede llevar la especificación de la solicitud original así como la ruta reportada del PCE (ERO).
Otra alternativa es una opción de lista ordenada, basada en extender el objeto de solicitud de cálculo de ruta existente. Esto sólo puede ser utilizado en el caso de un resultado de establecimiento de LSP negativo, cuando se solicita una nueva ruta al mismo destino.
El formato del mensaje de PCReq actualizado es:
10 El objeto SETUP_RESULT (Resultado del Establecimiento) codifica el resultado del intento de establecimiento de conexión previo. Por lo tanto, como puede asumirse que este intento previo no tuvo éxito, el CÓDIGO DE ERROR no debería ser puesto a 0. La estructura old_req_desc define detalles del intento de establecimiento de conexión fallido y contiene el descriptor de solicitud (OLD_RP) (RP ANTIGUO) así como la ruta calculada, con más detalles de
15 la solicitud original (estructura de solicitud original). El objeto OLD_RP (RP ANTIGUO) puede ser implementado como un nuevo objeto o como una variante del objeto RP. En este último caso, el “tipo de objeto” se utiliza para diferenciar entre la solicitud subsiguiente (transportada en el objeto RP de dirección de la solicitud) y la solicitud fallida (utilizada por la solicitud previa y llevada a cabo en el objeto OLD_RP (RP ANTIGUO)).
20 Así, se han descrito anteriormente métodos mediante los cuales el PCC puede proporcionar información de retorno al PCE acerca del éxito de intentos para establecer una ruta. Cuando el PCE recibe una indicación de error de establecimiento de LSP desde el PCC, el PCE puede incorporar esta información a su base de datos, con el fin de utilizar la información para formular políticas temporales para posteriores solicitudes de cálculo de ruta, ayudando a proporcionar mejores cálculos de ruta en el futuro. De manera similar, cuando recibe información detallada del
25 establecimiento de ruta, el PCE puede incorporar esa información a su base de datos. Esto puede proporcionar información adicional (tal como la longitud de onda seleccionada, y degradaciones ópticas estimadas), el anuncio de la cual por parte de la Ingeniería--- (IGP-TE – Gateway Protocol Traffic Engineering, en inglés) no sería posible, debido a consideraciones de escalabilidad.
30 Por ejemplo, en el caso de Redes ópticas de Longitud de Onda Conmutada (WSONs – Wavelength Switched Optical Networks, en inglés), se espera que el modelo de información de la estructura interna de los nodos ópticos proporcione descriptores de TE muy complejos de estos nodos. Por lo tanto, debido a razones de escalabilidad, los operadores pueden decidir no anunciar la descripción completa con el protocolo de encaminamiento de estado del enlace. Así, el PCE podría no tener información precisa del protocolo de encaminamiento acerca de qué longitudes de onda pueden ser encaminadas a través de la red desde un extremo al otro extremo. No obstante, la extensión
5 propuesta en esta memoria permite que el PCE recoja información de disponibilidad de longitud de onda, incluso si la asignación de longitud de onda es distribuida. Específicamente, el nodo de ingreso de conexión podría reportar en el resultado del establecimiento de la conexión la longitud de onda asignada que fue eventualmente reservada.
Se describe así un sistema en el cual un Cliente de Cálculo de Ruta puede proporcionar información de retorno a un
10 Elemento de Cálculo de Ruta en una red de Etiquetas Conmutadas de Multiprotocolo Generalizado, de manera que el Elemento de Cálculo de Ruta puede utilizar esta información en otras decisiones de cálculo de ruta.

Claims (13)

  1. REIVINDICACIONES
    1. Un método para su uso en un Cliente de Cálculo de Ruta (24) de un nodo en una red, comprendiendo el método:
    5 enviar un mensaje de solicitud (52) a un Elemento de Cálculo de Ruta (28) de la red para el cálculo de una ruta; Recibir un mensaje de respuesta (54) desde el Elemento de Cálculo de Ruta que comprende información identificativa de una ruta calculada; e Intentar (58) el establecimiento de una conexión basándose en la ruta calculada;
    10 caracterizado porque el método comprende también:
    recibir desde el Elemento de Cálculo de Ruta una solicitud de información de retorno acerca de un resultado del intento de establecimiento de la conexión; y 15 reportar (64) al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión.
  2. 2. El método de acuerdo con la reivindicación 1, que comprende:
    reportar el resultado del intento de establecimiento de la conexión en un mensaje de Protocolo del Elemento 20 de Cálculo de Ruta.
  3. 3. El método de acuerdo con la reivindicación 1 ó 2, en el que la etapa de reportar al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión comprende:
    25 reportar si el intento tuvo éxito o no; y si el intento fue un fallo, proporcionar información adicional acerca del fallo.
  4. 4. El método de acuerdo con la reivindicación 1, 2 ó 3, en el que la solicitud de información de retorno acerca del
    resultado del intento de establecimiento de la conexión se incluye en el mensaje de respuesta del Elemento de 30 Cálculo de Ruta que comprende información identificativa de la ruta calculada.
  5. 5. El método de acuerdo con la reivindicación 4, en el que el mensaje de respuesta del Elemento de Cálculo de Ruta que comprende información identificativa de la ruta calculada incluye un objeto que identifica el mensaje de solicitud; y en el que el método comprende también:
    35 incluir el objeto identificativo del mensaje de solicitud cuando reporta al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión.
  6. 6. El método de la reivindicación 1, que comprende:
    40 reportar (64) al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión como parte de un subsiguiente mensaje de solicitud al Elemento de Cálculo de Ruta para el cálculo de una ruta.
  7. 7. Un Cliente de Cálculo de Ruta (24) de un nodo en una red, en el que el Cliente de Cálculo de Ruta está 45 configurado para:
    enviar un mensaje de solicitud (52) a un Elemento de Cálculo de Ruta (28) de la red para el cálculo de una ruta; recibir un mensaje de respuesta (54) del Elemento de Cálculo de Ruta que comprende información
    50 identificativa de una ruta calculada; e intentar (58) establecer una conexión basándose en la ruta calculada;
    caracterizado porque el Cliente de Cálculo de Ruta está también configurado para:
    55 recibir del Elemento de Cálculo de Ruta una solicitud de información de retorno acerca de un resultado del intento de establecimiento de la conexión; y reportar (64) al Elemento de Cálculo de Ruta el resultado del intento de establecimiento de la conexión.
  8. 8. Un método para su uso en un Elemento de Cálculo de Ruta (28) de una red, comprendiendo el método:
    60 recibir de un Cliente de cálculo de Ruta (24) de un nodo de la red un mensaje de solicitud (52) para el cálculo de una ruta; calcular una ruta basándose en el mensaje de solicitud; y enviar un mensaje de respuesta (54) al Cliente de Cálculo de Ruta que contiene información identificativa de
    65 la ruta calculada; caracterizado porque el método comprende también:
    enviar al Cliente de Cálculo de Ruta una solicitud de información de retorno acerca de un resultado del intento
    5 de establecimiento de la conexión; y recibir del Cliente de Cálculo de Ruta un reporte (64) acerca del resultado del intento de establecimiento de la conexión.
  9. 9. El método de acuerdo con la reivindicación 8, que comprende también:
    10 utilizar el reporte acerca del resultado del intento de establecimiento de la conexión en futuros mensajes.
  10. 10. El método de acuerdo con la reivindicación 8 ó 9, que comprende:
    15 recibir el reporte acerca del resultado del intento de establecimiento de la conexión en un mensaje de protocolo del Elemento de Cálculo de Ruta.
  11. 11. El método de acuerdo con la reivindicación 8, 9 ó 10, en el que la etapa de recibir el reporte del Cliente de Cálculo de Ruta comprende:
    20 recibir un reporte acerca de si el intento tuvo éxito o no; y si el intento fue un fallo, proporcionar información adicional acerca del fallo.
  12. 12. El método de acuerdo con la reivindicación 8, 9, 10 u 11, que comprende incluir la solicitud de información de
    25 retorno acerca del resultado del intento de establecimiento de la conexión en el mensaje de respuesta al Cliente de Cálculo de Ruta.
  13. 13. El método de acuerdo con la reivindicación 12, que comprende también:
    30 incluir en el mensaje de respuesta al Cliente de Cálculo de Ruta un objeto identificativo de la solicitud; y donde el método comprende también: recibir el objeto identificativo del mensaje de solicitud cuando recibe el reporte acerca del resultado del intento de establecimiento de la conexión.
    35 14. El método de la reivindicación 8, que comprende también:
    recibir del Cliente de Cálculo de Ruta el resultado del intento de establecimiento de la conexión como parte de un subsiguiente mensaje de solicitud del Cliente de Cálculo de Ruta para el cálculo de una ruta.
    40 15. Un Elemento de Cálculo de Ruta para una red, en el que el Elemento de Cálculo de Ruta está configurado para:
    recibir de un Cliente de Cálculo de Ruta de un nodo en la red un mensaje de solicitud para el cálculo de una ruta; calcular una ruta basándose en el mensaje de solicitud; y
    45 enviar un mensaje de respuesta al Cliente de Cálculo de Ruta que contiene información identificativa de la ruta calculada;
    caracterizado porque el Elemento de Cálculo de Ruta está también configurado para:
    50 enviar al Cliente de Cálculo de Ruta una solicitud de información de retorno acerca del resultado del intento de establecimiento de la conexión; y recibir del Cliente de Cálculo de Ruta un reporte acerca del resultado del intento de establecimiento de la conexión.
ES10701636T 2010-01-04 2010-01-04 Proporcionar información de retorno a un elemento de cálculo de ruta Active ES2434261T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2010/050006 WO2011079962A1 (en) 2010-01-04 2010-01-04 Providing feedback to path computation element

Publications (1)

Publication Number Publication Date
ES2434261T3 true ES2434261T3 (es) 2013-12-16

Family

ID=42712548

Family Applications (1)

Application Number Title Priority Date Filing Date
ES10701636T Active ES2434261T3 (es) 2010-01-04 2010-01-04 Proporcionar información de retorno a un elemento de cálculo de ruta

Country Status (5)

Country Link
US (1) US9667525B2 (es)
EP (1) EP2522104B1 (es)
CN (1) CN102714621A (es)
ES (1) ES2434261T3 (es)
WO (1) WO2011079962A1 (es)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8374502B2 (en) 2009-02-27 2013-02-12 Futurewei Technologies, Inc. Open shortest path first extensions in support of wavelength switched optical networks
US8346079B2 (en) * 2009-02-27 2013-01-01 Futurewei Technologies, Inc. Path computation element protocol (PCEP) operations to support wavelength switched optical network routing, wavelength assignment, and impairment validation
CN102469009B (zh) * 2010-11-09 2015-06-03 中兴通讯股份有限公司 有状态路径计算单元的处理方法及有状态路径计算单元
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
ES2411755B1 (es) * 2011-04-19 2014-05-13 Telefónica, S.A. Método para la asignación de recursos de red en arquitecturas de servicios basadas en tispan
JP5935805B2 (ja) * 2011-09-14 2016-06-15 日本電気株式会社 ネットワークシステム
US8885463B1 (en) * 2011-10-17 2014-11-11 Juniper Networks, Inc. Path computation element communication protocol (PCEP) extensions for stateful label switched path management
US8787154B1 (en) 2011-12-29 2014-07-22 Juniper Networks, Inc. Multi-topology resource scheduling within a computer network
US8824274B1 (en) 2011-12-29 2014-09-02 Juniper Networks, Inc. Scheduled network layer programming within a multi-topology computer network
US10031782B2 (en) 2012-06-26 2018-07-24 Juniper Networks, Inc. Distributed processing of network device tasks
US9450817B1 (en) 2013-03-15 2016-09-20 Juniper Networks, Inc. Software defined network controller
CN104333511B (zh) * 2013-07-22 2019-01-08 华为技术有限公司 确定业务传输路径的方法、装置及系统
US10193801B2 (en) 2013-11-25 2019-01-29 Juniper Networks, Inc. Automatic traffic mapping for multi-protocol label switching networks
US9537753B2 (en) 2014-03-03 2017-01-03 Cisco Technology, Inc. Opaque profile identifiers for path computation element protocol
CN105099908B (zh) 2014-05-08 2019-02-05 华为技术有限公司 路径计算的方法、消息响应的方法以及相关设备
CN105634951B (zh) * 2014-11-05 2020-08-04 南京中兴软件有限责任公司 一种标签交换路径lsp的平滑重启gr的恢复方法及装置
EP3254409B1 (en) 2015-02-03 2020-01-01 Telefonaktiebolaget LM Ericsson (publ) Time aware path computation
CN106161243B (zh) * 2015-04-10 2020-11-24 中兴通讯股份有限公司 一种状态上报控制方法和装置
US10110479B1 (en) * 2015-09-29 2018-10-23 Juniper Networks, Inc. Computing paths with ordered abstract hops
EP3440807B1 (en) * 2016-05-03 2020-06-24 Huawei Technologies Co., Ltd. Label database synchronization in a packet switched communication network
CN108023810A (zh) * 2016-10-31 2018-05-11 中兴通讯股份有限公司 连接能力的通告方法及装置
CN113162854B (zh) 2017-01-27 2022-11-15 华为技术有限公司 路径计算方法和装置
KR102315401B1 (ko) * 2017-07-14 2021-10-19 후아웨이 테크놀러지 컴퍼니 리미티드 Ipv6 터널에 대한 세그먼트 라우팅을 구축하기 위한 방법
US10447587B2 (en) 2017-09-22 2019-10-15 Keysight Technologies Singapore (Sales) Pte. Ltd. Computing label-switched data communication paths
CN112054958B (zh) * 2019-06-06 2023-07-14 中兴通讯股份有限公司 路径计算方法及存储介质、电子装置
CN114301832B (zh) * 2020-09-21 2026-03-24 华为技术有限公司 一种业务处理方法及网络设备
CN114697262A (zh) * 2020-12-28 2022-07-01 中兴通讯股份有限公司 路径计算方法、算路服务器及通信系统
CN113193988B (zh) * 2021-04-09 2022-08-12 烽火通信科技股份有限公司 一种多pce的路径计算交互方法和系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020087699A1 (en) * 2000-07-31 2002-07-04 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic QoS management in differentiated services using bandwidth brokers, RSVP aggregation and load control protocols
US6922501B2 (en) * 2002-04-11 2005-07-26 Nortel Networks Limited Fast optical switch
US7623461B2 (en) * 2005-02-09 2009-11-24 Cisco Technology, Inc. Trigger for packing path computation requests
CN100454830C (zh) * 2005-05-20 2009-01-21 华为技术有限公司 网络域中实现路径计算的方法
CN100512209C (zh) 2005-05-24 2009-07-08 华为技术有限公司 分布式路径计算中解决资源冲突的方法
US7522603B2 (en) * 2006-03-14 2009-04-21 Cisco Technology, Inc. Technique for efficiently routing IP traffic on CE-CE paths across a provider network
EP2009848B1 (en) * 2007-06-29 2009-11-11 Alcatel Lucent Computing a path in a label switched network
US8059960B2 (en) * 2007-10-26 2011-11-15 Futurewei Technologies, Inc. Path computation element method to support routing and wavelength assignment in wavelength switched optical networks
US8064447B2 (en) * 2008-03-27 2011-11-22 Futurewei Technologies, Inc. Computing point-to-multipoint paths
US8358662B2 (en) * 2008-08-30 2013-01-22 Futurewei Technologies, Inc. Creating and maintaining traffic engineered database for path computation element
US20120210005A1 (en) * 2009-10-12 2012-08-16 Nokia Siemens Networks Oy Method and device for processing data in a network domain

Also Published As

Publication number Publication date
EP2522104B1 (en) 2013-08-14
WO2011079962A1 (en) 2011-07-07
EP2522104A1 (en) 2012-11-14
CN102714621A (zh) 2012-10-03
US20130007266A1 (en) 2013-01-03
US9667525B2 (en) 2017-05-30

Similar Documents

Publication Publication Date Title
ES2434261T3 (es) Proporcionar información de retorno a un elemento de cálculo de ruta
ES2449367T3 (es) Método para implementar una protección de malla compartida, un equipo y un sistema de red óptica
ES2535740T3 (es) Método de cálculo de rutas, dispositivo nodal y elemento de cálculo de rutas
US10554537B2 (en) Segment routing in a multi-domain network
JP6087433B2 (ja) 電気通信ネットワークにおいてリンク多様なトラフィック経路を確立するための方法および関連装置
US20160373317A1 (en) Bandwidth on-demand services in multiple layer networks
EP2720420B1 (en) Method for exchanging information for establishing a path between two nodes of a communication network
US10020984B1 (en) RSVP local protection signaling reduction
CN104426766A (zh) 跨多个网络层的动态端到端网络路径建立
JP2013541290A (ja) 複数の領域及び複数の自律システムのためのリレーされるｃｓｐｆ
JP2009539156A (ja) 複数ドメインルート計算の方法とシステム
CN101237399A (zh) 获取标签交换路径的方法、系统和设备
ES2338814T3 (es) Metodo y aparato para gestionar y transmitir servicios de granularidad fina.
EP2009848B1 (en) Computing a path in a label switched network
US20120042077A1 (en) Handling failure of request message during set up of label switched path
CN106027394B (zh) 基于rsvp先接后断标签重用的方法、系统和路由器
WO2019006704A1 (zh) 一种路径计算的方法、装置和系统
US12218857B2 (en) Method and device for establishing service path, electronic apparatus and readable storage medium
EP2063585A1 (en) Method and apparatus for computing a path in a network
CN101374104A (zh) 生成路由的方法、网络控制器和系统
EP2328307B1 (en) Barrier boundary node and method for establishing connection between barrier bound ary nodes
CN103491002B (zh) 一种获取ip链路的链路开销值的方法及系统
ES2844098T3 (es) Método de establecimiento de trayectos de servicio, dispositivo de nodo y sistema
CN109644122B (zh) 资源共享方法、网络节点及相关设备
ES2634240T3 (es) Procedimiento y sistema para el procesamiento de la señalización RSVP-TE