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

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.

Tipo: Patente Internacional (Tratado de Cooperación de Patentes). Resumen de patente/invención. Número de Solicitud: PCT/EP2010/050006.

Solicitante: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL).

Nacionalidad solicitante: Suecia.

Dirección: 164 83 STOCKHOLM SUECIA.

Inventor/es: CSASZAR,ANDRAS, JOCHA,DÁVID, KERN,ANDRÁS.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • H04L12/56

PDF original: ES-2434261_T3.pdf

 

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

Fragmento de la descripción:

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) Discover y ”, o ISIS-TE como se describe en el documento RFC 5089 de IETF: “IS-IS Protocol Extensions for Path Computation Element (PCE) Discover y ”.

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... [Seguir leyendo]

 


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:

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;

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. 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. 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:

reportar si el intento tuvo éxito o no; y si el intento fue un fallo, proporcionar información adicional acerca del fallo.

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. 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:

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. El método de la reivindicación 1, que comprende:

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. 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:

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. Un método para su uso en un Elemento de Cálculo de Ruta (28) de una red, comprendiendo el método:

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 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. El método de acuerdo con la reivindicación 8, que comprende también:

utilizar el reporte acerca del resultado del intento de establecimiento de la conexión en futuros mensajes.

10. El método de acuerdo con la reivindicación 8 ó 9, que comprende:

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. 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:

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. El método de acuerdo con la reivindicación 8, 9, 10 u 11, que comprende 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.

13. El método de acuerdo con la reivindicación 12, que comprende también:

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.

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.

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

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:

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.


 

Patentes similares o relacionadas:

Dispositivo inalámbrico y procedimiento para visualizar un mensaje, del 25 de Marzo de 2020, de QUALCOMM INCORPORATED: Un dispositivo inalámbrico para visualizar un mensaje, comprendiendo el dispositivo inalámbrico: un visualizador gráfico ; una unidad de comunicaciones inalámbricas […]

Método de indicación de disponibilidad de servicio para terminales de radiofrecuencia de corto alcance, con visualización de icono de servicio, del 26 de Febrero de 2020, de Nokia Technologies OY: Un método que comprende: recibir, en un dispositivo , información de icono de un dispositivo de origen en conexión con descubrimiento de dispositivo […]

Procedimiento y aparato para la transmisión de entramado con integridad en un sistema de comunicación inalámbrica, del 6 de Noviembre de 2019, de QUALCOMM INCORPORATED: Un procedimiento para el entramado de paquetes en un sistema de transmisión inalámbrico que admite transmisiones de radiodifusión, el procedimiento que comprende: […]

Aparato y procedimiento para usar en la realización de peticiones de repetición automática en sistemas de comunicaciones de acceso múltiple inalámbricas, del 6 de Noviembre de 2019, de QUALCOMM INCORPORATED: Un procedimiento para usar en un sistema de comunicaciones inalámbricas que comprende al menos una estación base y al menos dos terminales inalámbricos […]

Imagen de 'Procedimiento y aparato para sistemas inalámbricos de activación'Procedimiento y aparato para sistemas inalámbricos de activación, del 31 de Octubre de 2019, de QUALCOMM INCORPORATED: Un procedimiento para controlar de forma inalámbrica una tarjeta de interfaz de red NIC (108 A-N) usando una red inalámbrica , con la NIC (108 A-N) […]

Método y sistema para visualizar un nivel de confianza de las operaciones de comunicación de red y la conexión de servidores, del 16 de Octubre de 2019, de Nokia Technologies OY: Un método que comprende: recibir, en un servidor , una primera solicitud para un análisis de una primera operación de comunicación desde […]

Un protocolo de red agile para comunicaciones seguras con disponibilidad asegurada de sistema, del 11 de Septiembre de 2019, de VirnetX Inc: Un método para un primer nodo para establecer una sesión con un segundo nodo , el método se realiza en el primer nodo , en el que […]

Dispositivo de nodo para una red de sensores inalámbricos, del 10 de Julio de 2019, de Wirepas Oy: Un dispositivo de nodo para una red de sensores inalámbricos, comprendiendo el dispositivo de nodo: - un transceptor […]

Utilizamos cookies para mejorar nuestros servicios y mostrarle publicidad relevante. Si continua navegando, consideramos que acepta su uso. Puede obtener más información aquí. .