ES2372541T3 - Procedimiento de consulta de enrutado jerárquico para red óptica de conmutación automática. - Google Patents

Procedimiento de consulta de enrutado jerárquico para red óptica de conmutación automática. Download PDF

Info

Publication number
ES2372541T3
ES2372541T3 ES06828220T ES06828220T ES2372541T3 ES 2372541 T3 ES2372541 T3 ES 2372541T3 ES 06828220 T ES06828220 T ES 06828220T ES 06828220 T ES06828220 T ES 06828220T ES 2372541 T3 ES2372541 T3 ES 2372541T3
Authority
ES
Spain
Prior art keywords
route
domain
request
child
returned
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
ES06828220T
Other languages
English (en)
Inventor
Desheng Sun
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.)
ZTE Corp
Original Assignee
ZTE Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=39588103&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=ES2372541(T3) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by ZTE Corp filed Critical ZTE Corp
Application granted granted Critical
Publication of ES2372541T3 publication Critical patent/ES2372541T3/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
    • H04B—TRANSMISSION
    • H04B10/00—Transmission systems employing electromagnetic waves other than radio-waves, e.g. infrared, visible or ultraviolet light, or employing corpuscular radiation, e.g. quantum communication
    • H04B10/25—Arrangements specific to fibre transmission
    • 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/56—Routing software
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0073—Provisions for forwarding or routing, e.g. lookup tables
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0079—Operation or maintenance aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/0001—Selecting arrangements for multiplex systems using optical switching
    • H04Q11/0062—Network aspects
    • H04Q2011/0088—Signalling aspects

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Optical Communication System (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un procedimiento de consulta jerárquica de ruta en una Red Óptica de Conmutación Automática (ASON) usada en una red que comprende dominios de ruta en múltiples capas, caracterizado porque cuando un Controlador de Ruta (RC) de un dominio hijo recibe una Solicitud de Ruta, el RC del dominio hijo envía la Solicitud de Ruta al RC de un dominio padre si no se puede calcular una ruta completa; y el RC del dominio padre interactúa adicionalmente con otros dominios hijo si el RC del dominio padre no puede calcular la ruta completa, en el que si se obtiene la ruta completa, entonces se devuelve la Respuesta de Ruta al solicitante.

Description

Procedimiento de consulta del enrutado jerárquico para red óptica de conmutación automática
Campo técnico
La presente invención se refiere al campo de las redes ópticas y, más específicamente, a un procedimiento jerárquico de consulta de ruta en una red óptica de conmutación automática.
Técnica antecedente
Las redes ópticas, tal como OTN (Red de transmisión óptica), WDN (Multiplexado por división de longitud de onda), SDH (Jerarquía digital síncrona) o SONET (Red óptica síncrona), se han aplicado ampliamente en el campo de la telecomunicación.
Recientemente, la red óptica de conmutación automática (ASON) es uno de los temas candentes de investigación en el campo de las redes ópticas. El concepto de ASON es ofrecido por la ITU-T G.8080, en la que la función de ASON se consigue mediante el ajuste de un plano de control (CP) específico. La ITU-T G.7713 especifica el marco para implementar las llamadas y conexiones distribuidas en ASON para ofrecer el criterio de implementación para establecer, modificar y borrar automáticamente las llamadas y conexiones. Las normas tales como la ITU-T G. 7715 ofrecen el modelo de implementación del procedimiento para la consulta de la ruta de conexión (la consulta de ruta descrita a continuación se refiere a la consulta de la ruta de conexión, a menos que se declare otra cosa específicamente).
Sin embargo, tanto la publicación ITU-T G.7715 como la ITU-T G.7715.1 aplican el modelo mostrado en la FIG. 1. En este modelo de ruta, cuando un elemento de la red (NE en abreviatura) ASON necesita consultar la ruta de la conexión, el Control de la Conexión (CC) responsable del control de la conexión (incluyendo el establecimiento, eliminación, modificación y otros similares) envía la solicitud de consulta de ruta (Solicitud de Ruta en breve) al Controlador de Ruta (RC) responsable de la consulta y cálculo de la ruta y entonces el RC llama al algoritmo de enrutado (un algoritmo de enrutado típico es el Primer Recorrido Más Corto Restringido, brevemente CSPF) de acuerdo con la solicitud de ruta y calcula la ruta en base a la Base de Datos de Rutas (RDB) del nodo actual y devuelve el resultado de la consulta de ruta (Respuesta de Ruta en breve) al CC.
Sin embargo, la RDB de un nodo en general es difícil que contenga la información completa de rutas de la totalidad de la ASON, especialmente cuando la ASON tiene varios dominios de rutas. La RDB de un nodo tiene siempre solamente la información del dominio de rutas locales. La FIG. 2 muestra la situación en la que una ASON tiene varios dominios de rutas, lo que indica que cuando se debería establecer una conexión entre A en un dominio de rutas 1 y K en un dominio de rutas 4, como se muestra por la línea de puntos, el modelo mostrado en la FIG. 1 no puede satisfacer el requisito de la consulta de ruta y cálculo de la conexión.
El borrador de ITU-T Recomendación G.7715/Y.1706: “Architecture and requirements for routing in the automatically switched optical network” especifica los requisitos y la arquitectura para las funciones de enrutado usadas para el establecimiento de conexiones conmutadas (SC) y conexiones permanentes de software (SPC) dentro del marco dela Red Óptica de Conmutación Automática (ASON).
El documento US 2006/245413 A1 desvela un procedimiento y un sistema para el cambio de la extensión de los recursos en el plano de datos controlada por un plano de control para una conexión de red que se extiende a conjuntos de nodos contiguos controlados mediante la existencia de recursos de control de la red.
El documento “PNNI-based control plane for automatically switched optical networks” (Journal of Lightwave Technology, Vol. 21, Nº 11, noviembre de 2003) proporciona un procedimiento para la adaptación de modo apropiado del modo de transferencia asíncrono en un protocolo PNNI óptico (O-PNNI) que se puede usar como el plano de control de las ASON.
El documento EP 1727316 A1 desvela un procedimiento para la comprobación del soporte de una función en los elementos de red de una red de telecomunicación, como una función de operación y gestión.
El documento EP 1724972 A1 desvela un procedimiento para la activación del re-enrutado del servicio, que incluye la determinación de si ocurre una interrupción o mala conexión en un servicio de acuerdo con el cambio de lainformación de la topología de red guardada en los nodos en una Red Óptica de Conmutación Automática (ASON), ysi el resultado de la evaluación es SÍ, la activación del re-enrutado del servicio.
El documento EP 0841824 A2 desvela un sistema de restauración de un fallo que comprende una sección de enrutado jerárquico distribuido que se adapta para establecer una trayectoria principal y, antes del establecimiento de la trayectoria principal, determinar una trayectoria alternativa a la trayectoria principal en una red, en la que en el sistema, se adapta una sección de selección de trayectoria alternativa para tener una información de ruta de origen completa para la trayectoria principal cuando se intenta establecer la trayectoria principal.
El documento EP 1489784 A1 desvela un procedimiento para la restauración del tráfico después de que haya ocurrido un fallo en una red de transmisión controlada GMPLS, incluyendo el procedimiento las etapas de asignación de una categoría a cada elemento de la red afectado en base a la información disponible localmente y el envío de solicitudes de restauración entre los elementos de la red en el orden de dichas categorías.
El documento CN 1561048 A desvela un procedimiento para la implementación del enrutado del usuario de dominio mediante los servidores de enrutado, aplicado en un sistema de enrutado de red jerárquico compuesto de servidores de enrutado, en el que la información de ruta de un usuario de dominio se almacena en un servidor de enrutado de dominio local en una capa inferior y cuando se registra un usuario de dominio, su agente de llamada actual informa, a través de su agente de llamada de dominio local, a su servidor de enrutado de dominio local para actualizar la información de ruta del usuario de dominio.
El documento EP 1460808 A2 desvela un procedimiento y sistema para la implementación de una técnica del primer trayecto más corto basada en restricciones (“IrD-CSPF”) para soporte de enrutado jerárquico en las OTN multi dominio interconectadas.
El documento CN 1529429 A desvela un procedimiento para la determinación de un atributo de enlace de unatopología abstracta en un enrutado jerárquico de una Red Óptica de Conmutación Automática.
Sumario de la invención
El problema técnico a ser resuelto por la presente invención es ofrecer un procedimiento de consulta de ruta jerárquico, que incluye el cálculo de una ruta completa, en una ASON para resolver el problema de la consulta de ruta en una conexión de cruce de dominios.
Para resolver el problema técnico anterior la presente invención ofrece un procedimiento de consulta de ruta jerárquico en ASON, que se aplica a la red que comprende dominios de ruta de capa múltiple. En el procedimiento, cuando el RC de un dominio hijo recibe la Solicitud de Ruta, envía la solicitud de ruta al RC del dominio padre si no puede calcular una ruta completa y el RC del dominio padre interactúa adicionalmente con otros dominios hijos para obtener la ruta completa si no puede calcular una ruta completa y a continuación envía la Respuesta de Ruta al solicitante.
Adicionalmente, el procedimiento anterior puede tener también la siguiente característica: el procedimiento comprende además las siguientes etapas:
(a1) Después de que el RC de un NE en ASON detecte la Solicitud de Ruta desde el solicitante, envía la Solicitud de Ruta al RC del dominio padre si la Solicitud es una Solicitud de Ruta de cruce de dominios;
(a2) el RC del dominio padre calcula la ruta entre todos sus dominios hijo y envía una Solicitud de Ruta en el dominio al RC de cada dominio hijo en la ruta, el RC de cada dominio hijo calcula la ruta en su propio dominio y devuelve la Respuesta de Ruta al RC del dominio padre que, después de recibir la Respuesta de Ruta, devuelve la ruta al solicitante a través del RC que lanzó la Solicitud de Ruta si se puede obtener una ruta completa a través de la combinación, en caso contrario se devuelve un mensaje de fallo.
Adicionalmente, el procedimiento puede tener las siguientes características: la etapa (a2) comprende además las siguientes etapas:
(a21) El RC del dominio padre calcula la ruta entre sus dominios hijo, determina el nodo de límite de cada dominio hijo en la ruta y a continuación genera y emite la Solicitud de Ruta en el dominio que incluye la información del nodo límite del correspondiente dominio hijo;
(a22) Después de que el dominio hijo reciba la Solicitud de Ruta en el dominio, calcula la ruta de su dominio y devuelve la Respuesta de Ruta de su propio dominio al RC del dominio padre;
(a23) Después de que el RC del dominio padre reciba las Respuestas de Ruta desde los dominios hijo, determina si todos los resultados tienen éxito, si es así, prosigue entonces con la siguiente etapa; en caso contrario, se devuelve un mensaje de fallo al solicitante a través del RC que lanza la solicitud, finalizando;
(a24) El RC del dominio padre combina la ruta de cruce de dominios y la ruta dentro el dominio de cada dominio hijo para generar la ruta completa entre el inicio y la finalización y devuelve el enrutado completo al solicitante a través del RC que lanza la Solicitud, finalizando.
Adicionalmente, el procedimiento anterior puede tener también las siguientes características: si el dominio padre falla en el cálculo de la ruta de cruce de dominios en la etapa (a2), entonces se devuelve un mensaje de fallo al solicitante a través del RC que lanza la Solicitud, finalizando.
Adicionalmente, el procedimiento anterior puede tener también la siguiente característica: el procedimiento comprende además las siguientes etapas:
(b1) Después de que el RC del NE en ASON detecte la Solicitud de Ruta enviada por el solicitante, calcula la ruta en base a la RDB del nodo actual y devuelve la Respuesta de Ruta al solicitante si se obtiene una ruta completa, finalizando; en caso contrario, envía la Solicitud al RC del dominio padre;
(b2) El RC del dominio padre calcula la ruta en base a la RDB del nodo actual de acuerdo con la Solicitud y si se obtiene la ruta completa, se devuelve al solicitante a través del RC que lanza la Solicitud, finalizando; en caso contrario, se prosigue con la etapa siguiente;
(b3) El RC del dominio padre envía la solicitud de ruta al RC de sus otros dominios hijo y después de que reciba las Respuestas de Ruta desde los RC de estos dominios hijo, devuelve la ruta al solicitante a través del RC que lanza la Solicitud si pudo obtener la ruta completa, en caso contrario, se devuelve un mensaje de fallo al solicitante a través del RC que lanza la Solicitud, finalizando.
Adicionalmente, el procedimiento anterior puede tener también la siguiente característica: la etapa (b3) comprende además las siguientes etapas:
(b31) El RC del dominio padre envía la Solicitud de Ruta al RC de uno de sus otros dominios hijo distintos al RC que lanza la Solicitud;
(b32) Después de que el RC del otro dominio hijo recibe la Solicitud de Ruta, calcula la ruta en base a la RDB del nodo actual y devuelve la Respuesta de Ruta al RC del dominio padre;
(b33) El RC del dominio padre determina si la Respuesta de Ruta devuelta desde el RC del dominio hijo es la ruta completa, si es así, la ruta se devuelve al solicitante a través del RC que lanza la Solicitud, finalizando; en caso contrario, se prosigue con la siguiente etapa;
(b34) El RC del dominio padre determina si hay un RC de otro dominio hijo que no haya sido consultado, si es así, se envía adicionalmente la Solicitud de Ruta al RC del otro dominio hijo, y se vuelve a la etapa (b32); en caso contrario, se devuelve un mensaje de fallo al solicitante a través del RC que lanza la Solicitud, finalizando.
Adicionalmente, el procedimiento anterior puede tener también la siguiente característica: la etapa (b3) comprende además las siguientes etapas:
(b31) El RC del dominio padre emite la Solicitud de Ruta a los RC de todos los dominios hijo salvo al que lanza la Solicitud;
(b32) después de que los RC de todos los otros dominios hijos reciban la Solicitud de Ruta, calculan la ruta en base a la RDB de sus nodos actuales y devuelven las Respuestas de Ruta al RC del dominio padre;
(b33) el RC del dominio padre determina si hay una ruta completa en las Respuestas de Ruta devueltas desde los RC de los dominios hijo, si es así, se devuelve la ruta al Solicitante a través del RC que lanza la Solicitud, finalizando.
Adicionalmente, el procedimiento anterior puede tener también la siguiente característica: cuando el RC del dominio padre envía la Solicitud de Ruta al RC del dominio hijo, la Solicitud de Ruta se envía al RC del NE representativo que representa el dominio hijo para interactuar con el dominio de ruta de la capa superior.
En base al modelo de ruta jerárquica sugerido por el ITU-T G.8080, el procedimiento de la presente invención realiza la consulta de ruta, que no puede ser llevada a cabo por el NE en el dominio de ruta local, a través de la interacción de los RC de los diferentes dominios de ruta jerárquicos, fácil y fiablemente.
Breve descripción de los dibujos
La FIG. 1 es una ilustración de la consulta de ruta mediante un único NE:
La FIG. 2 es una ilustración de una ASON que tiene varios dominios de ruta;
La FIG. 3 muestra un modelo de la interacción de RC de acuerdo con el procedimiento de dominio de ruta jerárquico aplicado en la presente invención;
La FIG. 4 es una ilustración del proceso de la interacción de RC de acuerdo con la primera realización de la presente invención;
La FIG. 5 es una ilustración del proceso de la interacción de RC de acuerdo con la segunda realización de la presente invención;
La FIG. 6 es una ilustración del proceso de la interacción de RC de acuerdo con la tercera realización de la presente invención;
La FIG. 7 es una ilustración de la Respuesta de Ruta final de acuerdo con la presente invención, en base a la red mostrada en la FIG. 2;
La FIG. 8 es una ilustración del RC del dominio padre que calcula la ruta de cruce de dominios de acuerdo con la tercera realización de la presente invención, en base a la red mostrada en la FIG. 2;
La FIG. 9 es una ilustración del RC relacionado del dominio hijo 1 que calcula la ruta en el dominio de acuerdo con la tercera realización de la presente invención, en base a la red mostrada en la FIG. 2;
La FIG. 10 es una ilustración del RC relacionado del dominio hijo 2 que calcula la ruta en el dominio de acuerdo con la tercera realización de la presente invención, en base a la red mostrada en la FIG. 2;
La FIG. 11 es una ilustración del RC relacionado del dominio hijo 4 que calcula la ruta en el dominio de acuerdo con la tercera realización de la presente invención, en base a la red mostrada en la FIG. 2;
Descripción de las realizaciones preferidas
En base a la técnica anterior, la presente invención ofrece una estrategia de implementación para resolver el problema de la consulta de ruta que no se puede realizar mediante el RC de los NE en el dominio de ruta simple.
La clave de la presente invención es implementar la consulta de ruta a través de la interacción entre las RC de los NE relacionados de ASON en el dominio padre relacionado y los dominios hijo en base al modelo de ruta jerárquica. En la presente invención, de acuerdo con la configuración manual u otros procedimientos, el RC de cada dominio de ruta puede obtener la información sobre el RC del dominio de la capa superior (el dominio padre en resumen. Con respecto al dominio padre, los otros dominios de ruta se denominan dominios hijo).
Un procedimiento es: el RC de cada dominio hijo es responsable del cálculo de la ruta en su dominio y la ruta de un cruce de dominios se puede calcular mediante el envío de la Solicitud de Ruta al RC que trabaja en el dominio padre y el RC del dominio padre puede usar adicionalmente la Solicitud de Ruta para solicitar la ruta a través de los otros dominios hijo.
Otro procedimiento es: cuando se debe realizar la consulta de ruta, el RC del dominio de ruta local llama al algoritmo de enrutado de acuerdo con la Solicitud para calcular la ruta en base a la RDB del nodo actual. Si falla el cálculo, el RC envía la Solicitud al RC del dominio de la capa superior y la consulta de ruta se realiza por el RC del dominio padre o mediante la interacción entre el RC del dominio padre y los RC de los otros dominios hijo.
La presente invención no define la consulta de ruta en el dominio. A continuación, se describirá la presente invención con más detalle con referencia a las figuras adjuntas en tres realizaciones.
La primera realización
El procedimiento de consulta de ruta jerárquica de acuerdo con la presente realización incluye las siguientes etapas:
Etapa 1: el RC del NE en el dominio de ruta local detecta y recibe una Solicitud de Ruta, entonces prosigue con la siguiente etapa;
La solicitud de ruta incluye la información del nodo de inicio y del nodo de finalización.
Etapa 2: de acuerdo con la Solicitud de Ruta, el RC llama al algoritmo de enrutado, tal como el CSPF, para calcular la ruta en base a la RDB del nodo actual, y si se obtiene la ruta completa, se devuelve la ruta calculada al solicitante (como el CC), finalizando; en caso contrario, se envía la Solicitud de Ruta al RC del dominio padre y se prosigue con la siguiente etapa;
Etapa 3: de acuerdo con la Solicitud de Ruta, el RC del dominio padre llama al algoritmo de enrutado para calcular la ruta en base a la RDB del nodo actual y, si se obtiene la ruta completa, se devuelve la ruta al solicitante, finalizando; en caso contrario, la Solicitud de Ruta se envía al RC de uno de sus otros dominios hijo distintos al RC que lanza la solicitud y se prosigue con la siguiente etapa;
Generalmente, el RC del dominio padre envía la Solicitud al RC del NE representativo en otros dominios hijo y el NE representativo se denomina siempre como SPEAKER en las normas y representa al dominio hijo para interactuar con el dominio de ruta de la capa superior y el RC del NE representativo tiene la información del dominio de ruta de la capa superior. Todos los NE representativos constituyen el dominio de ruta de la capa superior.
Etapa 4: de acuerdo con la Solicitud de Ruta recibida, el RC del otro dominio hijo llama al algoritmo de enrutado para calcular la ruta en base a la RDB del nodo actual y devuelve la Respuesta de Ruta al RC del dominio padre;
Etapa 5: el RC del dominio padre determina si la Respuesta de Ruta devuelta desde el RC de los dominios hijo es la ruta completa, si es así, se devuelve la ruta completa al solicitante que lanza la Solicitud de Ruta, finalizando; en caso contrario se prosigue con la siguiente etapa;
Etapa 6: el RC del dominio padre determina si hay aún un RC de otros dominios hijo que no hayan sido consultados, si es así, la Solicitud de Ruta se envía al RC de uno de los otros dominios hijo y se vuelve a la Etapa 4; si los RC de todos los dominios hijo han realizado la consulta de ruta y no hay un resultado apropiado, se devuelve un mensaje de fallo al solicitante que lanza la Solicitud, finalizando.
La realización 1 se describirá a continuación en detalle mediante la combinación de la FIG. 1, FIG. 2, FIG. 3, FIG. 4 y FIG. 7, considerando que se necesita consultar la ruta mostrada con la línea de puntos en la FIG. 2, como un ejemplo. El NE A de ASON en el dominio de ruta sólo tiene la información del dominio de ruta 1, el NE B de ASON es el NE representativo para el dominio de ruta 1, mientras que el NE G de ASON es para el dominio de ruta 2, el NE I DE ASON para dominio el de ruta 3, el NE M de ASON para el dominio de ruta 4.
Las etapas específicas son las siguientes:
Etapa 1: el RC de cada NE de ASON en los dominios de ruta 1, 2, 3 y 4 comprueba la Solicitud de Ruta. El RC del NE A en el dominio de ruta 1 recibe la Solicitud de Ruta y el nodo de inicio es A y el nodo de finalización es K y prosigue con la siguiente etapa;
Etapa 2, el RC del NE A llama al algoritmo de enrutado de acuerdo con la Solicitud de Ruta para calcular la ruta en base a la RDB del nodo actual y si no se puede obtener la ruta completa dado que la información en la RDB del NE A no es suficiente, el RC dirigirá la Solicitud de Ruta al RC del dominio padre, esto es al RC del NE B, y prosigue con la siguiente etapa;
Etapa 3: el RC del NE B llama al algoritmo de enrutado de acuerdo con la Solicitud de Ruta para calcular la ruta en base a la RDB del nodo actual y si se obtiene la ruta completa, se devuelve la Respuesta de Ruta al RC del NE A, finalizando. En caso contrario, la Solicitud de Ruta se envía al RC del NE G en el dominio de ruta 2;
Etapa 4: el RC del NE G llama al algoritmo de ruta de acuerdo con la Solicitud de Ruta recibida para calcular la ruta en base a la RDB del nodo actual y si se obtiene la ruta completa, se devuelve la Respuesta de Ruta al RC del NE B, finalizando. En caso contrario, se devuelve un mensaje de fallo al RC del NE B;
Etapa 5, de acuerdo con el resultado devuelto desde el RC del NE G, el RC de B devuelve el resultado al RC de A si la ruta está completa, finalizando; en caso contrario, la Solicitud se envía al RC del NE I en el dominio de ruta 3 y se repite la etapa 4 y la etapa 5. Si se han consultado todos los dominios hijo, incluyendo los dominios de ruta 2, 3 y 4, y aun no hay un resultado apropiado, entonces el RC de B devuelve un mensaje de fallo al RC de A, finalizando.
Si la consulta tiene éxito, la ruta se debería mostrar como en la FIG. 7.
La segunda realización
La implementación de la segunda realización se puede obtener mediante la modificación parcial de las etapas relacionadas de la primera realización y la segunda realización incluye las siguientes etapas:
Etapa 1: después de que el RC del NE de ASON relacionado en el dominio de ruta local detecte y reciba una Solicitud de Ruta, se prosigue con la siguiente etapa;
Etapa 2: de acuerdo con la Solicitud de Ruta, el RC llama al algoritmo de enrutado para calcular la ruta en base a la RDB del nodo actual, y si se obtiene la ruta completa, se devuelve la ruta al solicitante, finalizando; en caso contrario, se envía la Solicitud de Ruta al RC del dominio padre y se prosigue con la siguiente etapa;
Etapa 3: de acuerdo con la Solicitud de Ruta, el RC del dominio padre llama al algoritmo de enrutado para calcular la ruta en base a la RDB del NE y, si se obtiene la ruta completa, se devuelve la ruta al solicitante a través del RC que lanza la solicitud, finalizando; en caso contrario, la Solicitud de Ruta se emite a los RC de todos los otros dominios hijo (típicamente los RC de los NE representativos) excepto al que lanza la solicitud y se prosigue con la siguiente etapa;
Etapa 4: de acuerdo con la Solicitud de Ruta recibida, los RC de todos los otros dominios hijo llaman al algoritmo de enrutado para calcular la ruta en base a las RDB de sus nodos actuales y devuelven las Respuestas de Ruta al RC del dominio padre;
Etapa 5: si el RC del dominio padre recibe la ruta completa devuelta desde el RC de uno o más dominios hijo, el RC del dominio padre selecciona una (si sólo un RC devuelve la ruta completa, no hay necesidad de una selección) y la devuelve al solicitante que lanza la solicitud, finalizando; en caso contrario, se devuelve un mensaje de fallo al solicitante, finalizando.
La segunda realización se describirá a continuación en detalle mediante la combinación de la FIG. 1, FIG. 2, FIG. 3, FIG. 5 y FIG. 7, considerando que se necesita consultar la ruta mostrada con la línea de puntos en la FIG. 2, como un ejemplo. La segunda realización se basa en la misma red de la primera realización.
Las etapas específicas son las siguientes:
Etapa 1: el RC de cada NE en los dominios de ruta 1, 2, 3 y 4 detecta la Solicitud de Ruta. El RC del NE A de ASON en el dominio de ruta 1 recibe la Solicitud de Ruta, el nodo de inicio es A y el nodo de finalización es K y prosigue con la siguiente etapa;
Etapa 2, el RC del NE A llama al algoritmo de enrutado de acuerdo con la Solicitud de Ruta para calcular la ruta en base a la RDB del nodo actual y si no se puede obtener la ruta completa dado que la información en la RDB del NE A no es suficiente, el RC dirigirá la Solicitud de Ruta al RC del dominio padre, esto es, al RC del NE B, y prosigue con la siguiente etapa;
Etapa 3: el RC del NE B llama al algoritmo de enrutado de acuerdo con la Solicitud de Ruta y calcula la ruta en base a la RDB del nodo actual y si se obtiene la ruta completa, se devuelve la Respuesta de Ruta al RC del NE A, finalizando. En caso contrario, la Solicitud de Ruta se emite al RC del NE G en el dominio de ruta 2, al RC del NE I en el dominio de ruta 3 y al RC del NE M en el dominio de ruta 4;
Etapa 4: el RC del NE B recibe la ruta completa desde el RC de uno o más dominios hijo, el RC de B selecciona una de ellas (si sólo hay una, entonces no es necesaria la selección) y la devuelve al RC que lanza la solicitud. Si no hay una ruta completa devuelta desde los dominios de rutas 2, 3, 4 se devuelve un mensaje de fallo al RC de A, finalizando.
Comparado con el ejemplo de la primera realización, en la segunda realización, el RC del dominio padre aplica el mecanismo paralelo en la etapa 4, esto es, la Solicitud de Ruta se envía simultáneamente al RC de cada dominio hijo. La ruta consultada con éxito en esta realización se muestra como la FIG. 7.
La tercera realización
El procedimiento jerárquico de consulta de ruta de la presente realización es una consulta por segmentos que incluye las siguientes etapas:
Etapa 1: el RC del NE de ASON relacionado en el dominio de ruta local detecta y recibe una Solicitud de Ruta, prosiguiendo con la siguiente etapa;
Etapa 2: el RC determina si es una solicitud de consulta de cruce de dominios, si no es así, de acuerdo con la Solicitud, el RC llama al algoritmo de enrutado para calcular la ruta en base a la RDB del nodo actual y se devuelve la ruta completa al solicitante, finalizando; en caso contrario, la Solicitud de Ruta se envía al RC del dominio padre y se prosigue con la siguiente etapa;
Etapa 3: de acuerdo con la Solicitud, el RC del dominio padre llama al algoritmo de enrutado para calcular la ruta en base a la RDB del nodo actual y, si se obtiene la ruta completa, entonces se determinan los nodos límite de cada dominio hijo en la ruta (esto es, la información del nodo de inicio y nodo de finalización de la consulta de ruta en el dominio) para generar la Solicitud de Ruta en el dominio de los dominios hijo incluyendo la información del nodo de inicio y el nodo de finalización de los dominios hijo correspondientes y envía la Solicitud al RC de estos dominios hijo, que son siempre los RC de los NE representativos y se prosigue con la siguiente etapa; en caso contrario, se devuelve un mensaje de fallo al solicitante a través del RC que lanza a la solicitud, finalizando;
El RC del dominio padre se configura en general con la información de ruta entre cada dominio hijo, esto es, cada dominio hijo se trata como un elemento de red para el cálculo.
Etapa 4: después de que cada dominio hijo reciba la Solicitud de Ruta, llama al algoritmo de enrutado para calcular la ruta en base a la RDB del nodo actual y devuelve la Respuesta de Ruta al RC del dominio padre;
Etapa 5: si el RC del dominio padre recibe la Respuesta de Ruta desde los dominios hijo y el cálculo de ruta de cada dominio hijo tiene éxito, entonces el RC del dominio padre combina las rutas calculadas localmente entre los dominios hijo para generar una ruta completa desde el nodo de inicio al nodo de finalización y se devuelve la ruta al solicitante a través del RC que lanza la solicitud, finalizando; si el cálculo de ruta de cualquier dominio hijo falla, se devuelve un mensaje de fallo al solicitante a través del RC que lanza la solicitud, finalizando.
La tercera realización se describirá a continuación con más detalle mediante la combinación de la FIG. 1, FIG. 2, FIG. 3, FIG. 6, FIG. 7, FIG. 8, FIG. 9, FIG. 10 y FIG. 11, considerando que se necesita consultar la ruta mostrada con la línea de puntos en la FIG. 2, como un ejemplo. La tercera realización se basa en la misma red de las dos realizaciones anteriores.
Las etapas específicas son las siguientes:
Etapa 1: el RC de cada NE de ASON en los dominios de ruta 1, 2, 3 y 4 comprueba la Solicitud de Ruta. El RC del NE A en el dominio de ruta 1 recibe la Solicitud de Ruta y el nodo de inicio es A y el nodo de
finalización es K y prosigue con la siguiente etapa;
Etapa 2, el RC del NE A determina que la Solicitud es una Solicitud de Ruta de cruce de dominios y dirige la Solicitud de Ruta al RC del dominio padre, esto es, el RC del NE B y prosigue con la siguiente etapa;
Etapa 3: el RC del NE B llama al algoritmo de enrutado de acuerdo con la Solicitud de Ruta para calcular la
5 ruta entre los dominios de ruta 1, 2, 4 en base al RDB del nodo actual y la ruta resultante se muestra como en la FIG. 8, que determina los límites para los dominios hijo 1, 2 y 4 y a continuación el RC de B genera la Solicitud de Ruta en el dominio de los dominios hijo 1, 2 y 4 y emite la solicitud al NE A en el dominio hijo 1, al NE G en el dominio hijo 2 y al NE M en el dominio hijo 4;
Etapa 4: los RC del NE A en el dominio hijo 1, NE G en el dominio hijo 2 y NE M en el dominio hijo 4 llaman al
10 algoritmo de enrutado de acuerdo con la Solicitud de Ruta para calcular la ruta en base a la RDB de sus nodos actuales y los resultados de ruta se muestran respectivamente como las FIGS. 9, 10 y 11 y el resultado se devuelve al RC del NE B.
Etapa 5: el RC de B recibe los resultados de ruta desde cada dominio hijo 1, 2 y 4 como se muestra en las FIGS. 9, 10 y 11. Si el cálculo de ruta por parte de los dominios hijo 1, 2 y 4 tiene éxito, entonces mediante la
15 combinación del resultado mostrado en la FIG. 8 calculado mediante la etapa 3, el RC de B genera la ruta completa mostrada como en la FIG. 7 y devuelve el resultado al RC de A que lanza la Solicitud, finalizando.
Naturalmente, la presente invención puede tener muchas otras realizaciones.
Aplicabilidad industrial
En base al modelo de ruta jerárquica sugerido por la ITU-T G.8080, la presente invención realiza la consulta de ruta,
20 especialmente una consulta de ruta de cruce de dominios mediante la interacción entre el RC del dominio padre y los RC de los NE relacionados en cada dominio hijo, fácil y fiablemente.

Claims (8)

  1. REIVINDICACIONES
    1. Un procedimiento de consulta jerárquica de ruta en una Red Óptica de Conmutación Automática (ASON) usada en una red que comprende dominios de ruta en múltiples capas, caracterizado porque
    cuando un Controlador de Ruta (RC) de un dominio hijo recibe una Solicitud de Ruta, el RC del dominio hijo envía la Solicitud de Ruta al RC de un dominio padre si no se puede calcular una ruta completa; y
    el RC del dominio padre interactúa adicionalmente con otros dominios hijo si el RC del dominio padre no puede calcular la ruta completa, en el que si se obtiene la ruta completa, entonces se devuelve la Respuesta de Ruta al solicitante.
  2. 2. Un procedimiento de acuerdo con la reivindicación 1, en el que el procedimiento comprende además las siguientes etapas:
    (a1) el RC de un elemento de red (NE) en ASON detecta la Solicitud de Ruta lanzada por el solicitante y entonces envía la Solicitud de Ruta al RC del dominio padre si la Solicitud es una Solicitud de Ruta de cruce de dominios; y
    (a2) el RC del dominio padre calcula la ruta entre todos sus dominios hijo y envía una Solicitud de Ruta en el dominio al RC de cada dominio hijo en la ruta, el RC de cada dominio hijo calcula la ruta en su dominio y devuelve la Respuesta de Ruta al RC del dominio padre, después de recibir la Respuesta de Ruta el RC del dominio padre devuelve la ruta al solicitante a través del RC que lanzó la Solicitud de Ruta si se puede obtener la ruta completa, en caso contrario se devuelve un mensaje de fallo.
  3. 3. Un procedimiento de acuerdo con la reivindicación 2, en el que la etapa (a2) comprende además las siguientes etapas:
    (a21) el RC del dominio padre calcula la ruta entre sus dominios hijo, determina un nodo de límite de cada dominio hijo en la ruta y a continuación genera y emite la Solicitud de Ruta en el dominio que incluye información del nodo límite que corresponde a cada dominio de los dominios hijo;
    (a22) después de que el dominio hijo reciba la Solicitud de Ruta en el dominio, calcula la ruta de su dominio y devuelve la Respuesta de Ruta al RC del dominio padre;
    (a23) después de que el RC del dominio padre reciba las respuestas de ruta desde los dominios hijo, determina si todas las Respuestas de Ruta tienen éxito, si es así el procedimiento prosigue con la etapa (a24), en caso contrario se devuelve un mensaje de fallo al solicitante a través del RC que lanzó la solicitud; y
    (a24) el RC del dominio padre combina la ruta de cruce de dominios y la ruta en el dominio de cada dominio hijo para generar la ruta completa entre el nodo de inicio y el nodo de finalización y devuelve la ruta completa al solicitante a través del RC que lanzó la Solicitud.
  4. 4.
    Un procedimiento de acuerdo con la reivindicación 2, en el que si el dominio padre falla en el cálculo de la ruta de cruce de dominios en la etapa (a2), se devuelve el mensaje de fallo al solicitante a través del RC que lanzó la Solicitud.
  5. 5.
    Un procedimiento de acuerdo con la reivindicación 1, en el que el procedimiento comprende además las siguientes etapas:
    (b1) el RC del NE en ASON detecta la Solicitud de Ruta enviada por el solicitante y entonces el RC del NE en ASON calcula la ruta en base a la Base de Datos de Ruta (RDB) de un nodo actual y devuelve la Respuesta de Ruta al solicitante si se obtiene la ruta completa; en caso contrario, se envía la Solicitud al RC del dominio padre;
    (b2) el RC del dominio padre calcula la ruta en base a la RDB del nodo actual de acuerdo con la Solicitud y si se obtiene la ruta completa, se devuelve al solicitante a través del el RC que lanzó la Solicitud; en caso contrario el procedimiento prosigue con la etapa (b3) y
    (b3) El RC del dominio padre envía la Solicitud de Ruta a los RC de sus otros dominios hijo y recibe las Respuestas de Ruta devueltas desde los RC de estos dominios hijo, si se puede obtener una ruta completa, se devuelve la ruta completa al solicitante a través del RC que lanzó la Solicitud; en caso contrario, se devuelve el mensaje de fallo al solicitante a través del RC que lanzó la Solicitud.
  6. 6. Un procedimiento de acuerdo con la reivindicación 5, en el que la etapa (b3) comprende además las siguientes etapas:
    (b31) El RC del dominio padre envía la Solicitud de Ruta al RC de un dominio hijo excepto para el que lanzó la Solicitud;
    (b32) después de que el RC del otro dominio hijo recibe la Solicitud de Ruta, calcula la ruta en base a la RDB del nodo actual y devuelve la Respuesta de Ruta al RC del dominio padre;
    (b33) el RC del dominio padre determina si la Respuesta de Ruta devuelta desde el RC del dominio hijo es la ruta completa, si es así, la ruta se devuelve al solicitante a través del RC que lanzó la Solicitud, en caso 5 contrario el procedimiento prosigue con la etapa (b34); y
    (b34) el RC del dominio padre determina si hay un RC de otro dominio hijo que no haya sido consultado, si es así, se envía la Solicitud de Ruta al RC de este dominio hijo, y el procedimiento prosigue en la etapa (b32), en caso contrario, se devuelve el mensaje de fallo al solicitante a través del RC en lanzó la Solicitud.
  7. 7. El procedimiento de acuerdo con la reivindicación 5, en el que la etapa (b3) comprende además las siguientes 10 etapas:
    (b31) El RC del dominio padre emite la Solicitud de Ruta a los RC de todos los otros dominios hijo excepto al que lanzó la Solicitud;
    (b32) después de que los RC de todos los otros dominios hijos reciban la Solicitud de Ruta, calculan la ruta en base a la RDB de los nodos actuales y devuelven las Respuestas de Ruta al RC del dominio padre; y
    15 (b33) el RC del dominio padre determina si hay una ruta completa en las Respuestas de Ruta devueltas desde los RC de los dominios hijo, si es así, se devuelve la ruta al Solicitante a través del RC que lanzó la Solicitud, en caso contrario se devuelve el mensaje de fallo al solicitante a través del RC que lanzó la Solicitud.
  8. 8. Un procedimiento de acuerdo con la reivindicación 2 ó 5, en el que cuando el RC del dominio padre envía la
    20 Solicitud de Ruta al RC del dominio hijo, la Solicitud de Ruta se envía al RC de un NE representativo que representa el dominio hijo para interactuar con el dominio de ruta de la capa superior.
ES06828220T 2006-12-01 2006-12-01 Procedimiento de consulta de enrutado jerárquico para red óptica de conmutación automática. Active ES2372541T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2006/003250 WO2008080251A1 (en) 2006-12-01 2006-12-01 A hierarchical routing query method of automatic switched optical network

Publications (1)

Publication Number Publication Date
ES2372541T3 true ES2372541T3 (es) 2012-01-23

Family

ID=39588103

Family Applications (1)

Application Number Title Priority Date Filing Date
ES06828220T Active ES2372541T3 (es) 2006-12-01 2006-12-01 Procedimiento de consulta de enrutado jerárquico para red óptica de conmutación automática.

Country Status (11)

Country Link
US (1) US8139938B2 (es)
EP (1) EP2096802B1 (es)
KR (1) KR101050776B1 (es)
CN (1) CN101361330B (es)
AT (1) ATE527822T1 (es)
DK (1) DK2096802T3 (es)
ES (1) ES2372541T3 (es)
PL (1) PL2096802T3 (es)
PT (1) PT2096802E (es)
SI (1) SI2096802T1 (es)
WO (1) WO2008080251A1 (es)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008064518A1 (en) * 2006-11-28 2008-06-05 Zte Corporation A united route query method in the automatic switched optical network
US9118495B1 (en) * 2012-07-06 2015-08-25 Pertino, Inc. Communication between broadcast domains
US10560343B1 (en) 2012-07-06 2020-02-11 Cradlepoint, Inc. People centric management of cloud networks via GUI
US10110417B1 (en) 2012-07-06 2018-10-23 Cradlepoint, Inc. Private networks overlaid on cloud infrastructure
US10177957B1 (en) 2012-07-06 2019-01-08 Cradlepoint, Inc. Connecting a cloud network to the internet
US10880162B1 (en) 2012-07-06 2020-12-29 Cradlepoint, Inc. Linking logical broadcast domains
US10135677B1 (en) 2012-07-06 2018-11-20 Cradlepoint, Inc. Deployment of network-related features over cloud network
US10601653B2 (en) 2012-07-06 2020-03-24 Cradlepoint, Inc. Implicit traffic engineering
US9992062B1 (en) 2012-07-06 2018-06-05 Cradlepoint, Inc. Implicit traffic engineering
CN104885408B (zh) * 2013-04-16 2018-02-02 华为技术有限公司 一种保护倒换的方法、网络及系统
US10855584B2 (en) * 2018-12-28 2020-12-01 Alibaba Group Holding Limited Client-equipment-peering virtual route controller

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2985940B2 (ja) 1996-11-08 1999-12-06 日本電気株式会社 障害回復装置
US7215644B2 (en) 2003-03-19 2007-05-08 Alcatel Lucent Inter-domain constraint-based shortest path first technique for supporting hierarchical routing in interconnected multi-domain optical transport networks
EP1489784A1 (en) 2003-06-16 2004-12-22 Alcatel Restoration in an automatically switched optical transport network
CN1272924C (zh) 2003-09-30 2006-08-30 烽火通信科技股份有限公司 确定光网络层次式路由的抽象拓扑链路属性的方法
US7599349B2 (en) * 2004-01-29 2009-10-06 Cisco Technology, Inc. Computing inter-autonomous system MPLS traffic engineering LSP paths
CN1282345C (zh) * 2004-03-02 2006-10-25 中兴通讯股份有限公司 一种通过路由服务器实现域用户路由的方法
CN100531092C (zh) 2005-01-25 2009-08-19 华为技术有限公司 智能光网络的业务重路由触发方法
US8320255B2 (en) * 2005-02-02 2012-11-27 Cisco Technology, Inc. Inter-domain path computation technique
US7814227B2 (en) * 2005-03-04 2010-10-12 Cisco Technology, Inc. Computation of a shortest inter-domain TE-LSP across a set of autonomous systems
US8125925B2 (en) * 2005-04-29 2012-02-28 Ciena Corporation Method and apparatus for non-disruptive call modification
ATE445950T1 (de) * 2005-05-23 2009-10-15 Alcatel Lucent Rsvp-protokollerweiterung zur unterstützung von oam-funktionen

Also Published As

Publication number Publication date
EP2096802A4 (en) 2010-08-04
CN101361330A (zh) 2009-02-04
ATE527822T1 (de) 2011-10-15
WO2008080251A1 (en) 2008-07-10
DK2096802T3 (da) 2012-01-02
SI2096802T1 (sl) 2012-02-29
KR101050776B1 (ko) 2011-07-20
KR20090095595A (ko) 2009-09-09
PL2096802T3 (pl) 2012-03-30
PT2096802E (pt) 2011-12-16
US20100061724A1 (en) 2010-03-11
US8139938B2 (en) 2012-03-20
EP2096802B1 (en) 2011-10-05
EP2096802A1 (en) 2009-09-02
CN101361330B (zh) 2012-06-27

Similar Documents

Publication Publication Date Title
ES2372541T3 (es) Procedimiento de consulta de enrutado jerárquico para red óptica de conmutación automática.
US7852863B2 (en) System and methods for connections using automatically switched optical network control planes
US7995569B2 (en) Virtual routers for GMPLS networks
EP1395003B1 (en) Constraint-based shortest path first method for dynamically switched optical transport networks
Mohan et al. Efficient algorithms for routing dependable connections in WDM optical networks
US6850486B2 (en) Method of reducing traffic during path restoration
CN100454837C (zh) 一种实现跨域路由分离的方法
CN101192883A (zh) Wdm光网络中组播保护方法
Shang et al. A hierarchical path computation element (PCE)-based k-random-paths routing algorithm in multi-domain WDM networks
US8121039B2 (en) United route query method in the automatic switched optical network
ES2402778T3 (es) Método de consulta de ruta en una red ASON
US8213340B1 (en) System and method for managing a node split across multiple network elements
Naser et al. A multilayer differentiated protection services architecture
KR100231714B1 (ko) 다중 서비스 품질의 경로 계산방법
Bandyopadhyay et al. A virtual wavelength translation scheme for routing in all-optical networks
CN116132293A (zh) 基于用户需求和网络配置映射规则的业务开通方法与装置
Wilson et al. Fast, secure call setup in CORONET multiple carrier domain networks
Zhang et al. Research and simulation of ASON survivability testbed
Lim Implementation of a Network Provisioning System with User-driven and Trusty Protection Management
EP1665826A1 (en) Method for activation of preplanned circuits in telecommunications networks and network in accordance with said method
Wu Modeling and analysis of GMPLS-based automatically switched optical network
IL147422A (en) Technique of determining connectivity solutions for network elements