ES A2 ESPAÑA 11. Número de publicación: Número de solicitud: H04L 12/00 ( ) - PDF\nES A2 ESPAÑA 11. Número de publicación: Número de solicitud: H04L 12/00 ( )\nDownload "ES 2 427 488 A2 ESPAÑA 11. Número de publicación: 2 427 488. Número de solicitud: 201230634 H04L 12/00 (2006.01) 27.04.2012"\nMario Álvarez Quintero\n1 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA Número de publicación: Número de solicitud: Int. CI.: H04L 12/00 (06.01) 12 SOLICITUD DE PATENTE A2 22 Fecha de presentación: Fecha de publicación de la solicitud: Solicitantes: TELEFONICA, S.A (0.0%) Gran Vía, MADRID (MADRID) ES 72 Inventor/es: GONZALEZ DE DIOS, Oscar y LOPEZ ALVAREZ, Victor 74 Agente/Representante: CARPINTERO LÓPEZ, Mario 4 Título: PROCEDIMIENTO Y SISTEMA PARA EL CÁLCULO MEJORADO DE TRAYECTOS 7 Resumen: Procedimiento y sistema para el cálculo mejorado de trayectos. La presente invención propone un procedimiento y sistema flexible mejorado para calcular los trayectos de encaminamiento a lo largo de múltiples dominios de una red de transporte de comunicación con una arquitectura de elementos de cálculo de trayecto jerárquicos. Con el procedimiento y sistema propuestos, puede implementarse cualquier tipo de algoritmo, añadiendo una gran flexibilidad al operador de red. ES A2\n2 DESCRIPCIÓN Procedimiento y sistema para el cálculo mejorado de trayectos Campo técnico La presente invención se refiere, en general, al cálculo de trayectos y, más específicamente, se refiere al cálculo de rutas óptimas en arquitecturas basadas en elementos de cálculo de trayecto (del inglés Path Computation Element, PCE) jerárquicos. Descripción de la técnica anterior Las redes de transporte actuales (definidas por ITU-T como redes que pueden proporcionar una infraestructura fiable para transportar datos de un punto a otro) habitualmente necesitan organizarse en varios dominios administrativos para permitir un funcionamiento fácil y mejorar el escalabilidad a medida que crece el número de nodos. Un dominio puede definirse como cualquier recopilación de elementos de red dentro de una esfera común de gestión de direcciones o responsabilidad de cálculo de trayectos. Ejemplos de dominios incluyen zonas IGP, sistemas autónomos (AS), múltiples AS dentro de una red de proveedor de servicio, etc. Además, en redes de transporte tales como redes ópticas conmutadas por longitud de onda (WSON), uno de los principales motivos para la separación en dominios es el rendimiento limitado de la interoperabilidad de las tecnologías de transmisión. Por tanto, en tales redes, la comunicación entre nodos de transporte de diferentes proveedores a distancias medias y largas es muy limitada. Por tanto, normalmente, cada dominio de red de transporte está formado por nodos de un único proveedor. Con el fin de tener diferentes proveedores en la red, cada dominio está formado por equipos de un proveedor diferente, y la interoperabilidad está limitada a distancias cortas. En ese caso, el escalabilidad en cuanto al número de nodos puede no ser un problema. Por tanto, las redes de transporte multidominio tendrán diferentes necesidades y requisitos. Una de las principales funciones necesarias en redes multidominio es la capacidad para calcular rutas óptimas para trayectos conmutados por etiquetas (del inglés Label Switched Path, LSP) que implican recursos de varios dominios. Tal cálculo de rutas puede ser una tarea compleja, restringida también por la dificultad de tener un único punto que conoce todos los detalles de los nodos, enlaces e información de ingeniería de tráfico (del inglés Traffic Engineering TE) de la totalidad de la red. Con el fin de resolver este problema, puede lograrse una posible solución adoptando una arquitectura basada en elementos de cálculo de trayecto (PCE) (tal como se define, por ejemplo, en A. Farrel, J.-P. Vasseur y J. Ash, Path Computation Element Architecture, RFC 46, agosto de 06). Según la especificación RFC 46, un elemento de cálculo de trayecto (PCE) es una entidad que puede computar (calcular) una ruta o trayecto de red basándose en un grafo de red, y aplicar restricciones computacionales durante el cálculo. La entidad PCE puede ser una aplicación que puede ubicarse dentro de un componente o nodo de red, en un servidor fuera de la red, etc. El PCE puede almacenar toda la información de TE del dominio al que el PCE da servicio (para facilitar la descripción, la información de TE incluye información de topología de red en el presente documento). Por ejemplo, un PCE podría calcular el trayecto de un LSP de TE considerando el ancho de banda y otras restricciones aplicables a la petición de servicio de LSP de TE. El PCE puede estar ubicado o no en el extremo de cabeza del trayecto. Por ejemplo, una solución intradominio convencional es que se realice un cálculo de trayecto por el LSR (encaminador de conmutación por etiquetas, del inglés Label Switching Router) de extremo de cabeza de un LSP de TE de MPLS (conmutación por etiquetas multiprotocolo, del inglés MultiProtocol Label Switching). Pero también existen soluciones en las que otros nodos en el trayecto deben contribuir al cálculo de trayecto (por ejemplo, saltos libres), haciéndolos PCE por derecho propio. El trayecto calculado por el PCE puede ser un trayecto explícito (es decir, el trayecto explícito completo desde el inicio hasta el destino, constituido por una lista de saltos estrictos) o un trayecto estricto/libre (es decir, una mezcla de saltos estrictos y libres que comprenden al menos un salto libre que representa el destino), en el que un salto puede ser un nodo abstracto tal como un AS. Al mismo tiempo, el cálculo de trayecto puede realizarse por algún otro PCE físicamente distinto del trayecto calculado. El PCE es especialmente útil en situaciones de cálculo de trayecto que consume mucha CPU, para evitar cargar los nodos de red, y escenarios en los que el nodo responsable del cálculo de trayecto tiene visibilidad limitada de la topología de red global. En tales situaciones, varios PCE pueden cooperar para encontrar las rutas óptimas requeridas. Pueden tenerse en cuenta varios enfoques basados en PCE dependiendo de las restricciones y limitaciones impuestas por arquitecturas de red actuales. Por ejemplo, cuando se conoce a priori la secuencia de dominios, pueden emplearse diversas técnicas para derivar un trayecto óptimo. Si los dominios están conectados de manera sencilla, o si también se conocen los puntos preferidos de interconexión, también puede usarse la técnica de cálculo de trayecto por dominio (tal como se describe en JP. Vasseur, A. Ayyangar, R. Zhang, A Per-Domain Path Computation Method for Establishing Inter-Domain TE LSPs, RFC 12, febrero de 08). Cuando existen múltiples conexiones entre dominios y no hay preferencia para la elección de puntos de interconexión, puede usarse el procedimiento de cálculo de trayecto recursivo hacia atrás (BRPC) (tal como se describe en JP. Vasseur, R. Zhang, N. Bitar, JL. Le Roux, A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute shortest 2\n3 Constrained Inter-Domain Traffic Engineering Label Switched Paths, RFC 441, abril del 09) para derivar un trayecto óptimo El cálculo de trayecto por dominio define una técnica para establecer trayectos conmutados por etiquetas (LSP) de TE de MPLS generalizada (GMPLS) interdominio mediante la cual el trayecto se calcula durante el proceso de señalización dominio por dominio por el nodo de frontera de entrada de cada dominio. Esta técnica se aplica cuando el trayecto completo de un LSP de TE interdominio no puede señalizarse a través de las fronteras de domino. Esta técnica de cálculo de trayecto no puede garantizar encontrar el trayecto restringido interdominio óptimo (más corto). Además, no puede usarse de manera eficaz para calcular un conjunto de LSP de TE diversamente encaminados interdominio. El procedimiento BRPC se basa en la comunicación entre PCEs que cooperan entre sí. El PCE en el dominio de destino crea un árbol de potenciales trayectos hacia el destino, el VSTP (árbol de trayecto más corto virtual, del inglés Virtual Shortest Path Tree), y lo devuelve al PCE anterior. Cuando existen múltiples conexiones entre dominios y no hay preferencia para la elección de puntos de interconexión, puede usarse el procedimiento de cálculo de trayecto recursivo hacia atrás (BRPC) para derivar un trayecto óptimo. Ambas técnicas suponen que se conoce bien la secuencia de dominios que deben cruzarse desde la fuente hasta el destino. No se da ninguna explicación de cómo se genera esta secuencia o qué criterios pueden usarse para la selección de trayectos entre dominios teniendo en cuenta que en implantaciones avanzadas (tal como redes ópticas construidas a partir de múltiples subdominios, o entornos de múltiples sistemas autónomos) la elección de dominios en la secuencia de dominios de extremo a extremo puede ser crítica. Existen también otras limitaciones: por ejemplo, el cálculo de trayecto por dominio puede llevar a un trayecto de extremo a extremo subóptimo ya que el trayecto más óptimo en un dominio puede llevar a la elección de un nodo frontera o de límite (del inglés Border Node, BN) de entrada para el siguiente dominio que da como resultado un trayecto muy pobre a través de ese siguiente dominio. Obsérvese también que los PCE en cada dominio pueden tener diferentes capacidades de cálculo, pueden ejecutar diferentes algoritmos de cálculo de trayecto, y aplicar diferentes conjuntos de restricciones y criterios de optimización, etc. Esto puede dar como resultado que el trayecto de extremo a extremo sea inconsistente y subóptimo. Además, el BGRP (protocolo de reserva de pasarela de límite) claramente tiene problemas de escalabilidad significativos. Puede mejorarse mediante la aplicación de políticas y filtrado, pero tales mecanismos no son simples y dejarían todavía problemas de escalabilidad. No obstante, la solución de PCE puede extenderse para permitir seleccionar la secuencia óptima de dominios, y derivar el trayecto de extremo a extremo óptimo mediante el uso de una relación jerárquica entre dominios y puede usarse un PCE con una visibilidad multidominio global que tenga acceso al conjunto completo de información de topología, lo que se ha denominado PCE jerárquico (H-PCE). La arquitectura de elementos de cálculo de trayecto jerárquicos (H-PCE), que está actualmente definiéndose en el IETF (dado a conocer, por ejemplo, en D. King, A. Farrel, The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS & GMPLS, borrador de IETF) comprende escalabilidad y optimización. En la arquitectura de H-PCE, existen 2 elementos funcionales, el PCE hijo, que conoce toda la disponibilidad de recursos dentro de un único dominio, y un PCE padre, que conoce el mapa de topología de dominios y sus interconexiones. Por tanto, hay, al menos, un PCE hijo (denominado también PCE de dominio) por dominio implicado, que puede calcular trayectos a lo largo del dominio. Un PCE hijo sólo conoce la topología del dominio al que da servicio y no conoce la topología de otros dominios hijos. Conoce también la interconexión de su dominio con otros dominios. El PCE padre construye el mapa de topología de dominios o bien a partir de datos de configuración o bien a partir de información recibida desde cada PCE hijo. Sin embargo, no conoce los detalles completos de los dominios por motivos de escalabilidad y para evitar una cantidad excesiva de intercambio de información. Cuando se necesita un trayecto que implica múltiples dominios, los nodos de red solicitan el trayecto al PCE hijo de su dominio usando el protocolo PCEP estándar, que reenvía la petición al PCE padre. La conexión entre PCE hijo y PCE padre usa el protocolo PCEP estándar con las extensiones que están definidas en F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King, Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE). La información de topología puede intercambiarse entre el PCE hijo y el PCE padre usando el IGP (protocolo de pasarela interno) con capacidades de ingeniería de tráfico, tales como OSPF-TE (trayecto más corto abierto primero con ingeniería de tráfico, del inglés Open Shortest Path First with Traffic Engineering), o por cualquier otro medio. En principio, el PCE padre selecciona un conjunto de trayectos de dominio candidatos basándose en la topología de dominios y el estado de los enlaces interdominio. Entonces envía peticiones de cálculo a los PCE hijos responsables de cada uno de los dominios en los trayectos de dominio candidatos. Sin embargo, dependiendo del tipo de red, pueden existir diferentes requisitos y restricciones en cuanto a la información intercambiada y la información disponible en el PCE padre. Por ejemplo, puede enviarse información resumida de los dominios al PCE padre. Además, en casos en los que la motivación de dividir la red en dominios es la división por proveedor y no el tamaño de la red, sería viable reenviar del PCE hijo al PCE padre información ampliada de los dominios. Las soluciones existentes de la técnica anterior se refieren a diferentes aspectos relacionados con encaminamiento y procedimientos de cálculos de trayecto para la implementación del plano de control, centrados principalmente en los procesos de cálculo de trayecto desde la perspectiva de procedimientos de encaminamiento que basan el cálculo 3\n4 de trayecto en métricas o algoritmos únicos individuales que no permiten adaptar el proceso de cálculo a un rango de métricas o funciones objetivo, adaptadas específicamente a cada situación y grafo de topología particularizado. Estas soluciones se asocian a un nivel específico de intercambio de topología, y no permiten la flexibilidad necesaria para un cálculo multidominio. Las nuevas funcionalidades que se han introducido en la presente invención extienden las funcionalidades de H- PCE actuales superando al menos algunos de estos inconvenientes. Sumario La presente invención propone un procedimiento y sistema flexible mejorado para arquitecturas basadas en PCE jerárquicos. La flexibilidad procede de la posibilidad de cargar, activar, desactivar múltiples algoritmos de cálculo de trayecto multidominio y añadir reglas específicas para su selección. Con este fin se presentan reglas novedosas para la selección de algoritmos. Además, el sistema propuesto puede usar varias bases de datos de ingeniería de tráfico, según las características de red específicas (tamaño, tipo de conmutación, capas, capacidades, etc.). Los algoritmos se dividen en dos partes, una en tiempo real y una calculada previamente, lo que permite mantener grafos de topología particularizados y cálculos previos para cada algoritmo. La parte calculada previamente puede alimentarse mediante las actualizaciones de las TEDB (bases de datos de ingeniería de tráfico), y alimenta la parte en tiempo real. De este modo, se reduce la complejidad de los cálculos de trayecto en tiempo real. Con el procedimiento y sistema propuestos puede implementarse cualquier tipo de algoritmo, añadiendo una gran flexibilidad al operador de red. En un primer aspecto, se propone un procedimiento para calcular trayectos de encaminamiento a lo largo de múltiples dominios de una red de transporte de comunicación con una arquitectura de elementos de cálculo de trayecto jerárquicos, incluyendo la red al menos un elemento de cálculo de trayecto, PCE, asociado a cada dominio, denominado PCE de dominio, para calcular trayectos de red entre nodos pertenecientes al mismo dominio y al menos un PCE, denominado PCE padre, para calcular trayectos de red entre nodos pertenecientes a diferentes dominios de un grupo de dominios gestionados por dicho PCE padre, comprendiendo el procedimiento las siguientes etapas: a) cuando el PCE padre recibe información sobre un cambio en los nodos o enlaces de un determinado dominio perteneciente al grupo de dominios gestionados por dicho PCE, el PCE padre calcula información preliminar de trayecto según dichos cambios para cada uno de los algoritmos de cálculo de trayecto establecidos como activos en una lista de algoritmos de cálculo de trayecto disponibles, de modo que para cada algoritmo activo de dicha lista, el PCE padre calcula y almacena determinada información preliminar de trayecto ; b) el PCE padre recibe, desde un PCE de dominio, una petición de cálculo de trayecto, incluyendo la petición de cálculo de trayecto información sobre el nodo de origen del trayecto, el nodo de destino del trayecto y al menos un requisito de rendimiento del trayecto; c) el PCE padre selecciona, de los algoritmos de cálculo de trayecto establecidos como activos en la lista, el algoritmo más adecuado según el al menos un requisito de rendimiento de trayecto; d) el PCE padre obtiene la información preliminar de trayecto para el algoritmo seleccionado; e) el PCE padre calcula el trayecto solicitado desde el nodo de origen del trayecto hasta el nodo de destino del trayecto, teniendo en cuenta al menos dicha información preliminar de trayecto, y aplicando el algoritmo de cálculo de trayecto seleccionado; f) el trayecto seleccionado (calculado) se notifica al PCE de dominio que solicita el cálculo de trayecto, en el que la información recibida por el PCE padre en la etapa a) incluye cualquier cambio en la información interdominio del determinado dominio, es decir, en la información sobre los nodos de límite de dicho dominio y sobre los enlaces entre nodos de dicho dominio y nodos de otros dominios y dicha información se envía por un PCE de dominio asociado a dicho determinado dominio. En otro aspecto, se presenta un sistema para calcular trayectos de encaminamiento a lo largo de múltiples dominios de una red de transporte de comunicación con una arquitectura de elementos de cálculo de trayecto jerárquicos, incluyendo la red al menos un elemento de cálculo de trayecto, PCE, asociado a cada dominio, denominado PCE de dominio, para calcular trayectos de red entre nodos pertenecientes al mismo dominio, incluyendo el sistema al menos un PCE, denominado PCE padre, para calcular trayectos de red entre nodos de diferentes dominios de un grupo de dominios gestionados por dicho PCE padre, comprendiendo el PCE padre: a) medios para, cuando el PCE padre recibe información sobre un cambio en los nodos o enlaces de un determinado dominio perteneciente al grupo de dominios gestionados por dicho PCE, calcular información preliminar de trayecto según dichos cambios para cada uno de los algoritmos de cálculo de trayecto establecidos como activos 4\n5 en una lista de algoritmos de cálculo de trayecto disponibles, de modo que para cada algoritmo activo de dicha lista, el PCE padre calcula y almacena determinada información preliminar de trayecto ; en el que la información recibida incluye información sobre cualquier cambio en información interdominio del determinado dominio y dicha información se envía por un PCE de dominio asociado a dicho determinado dominio; b) medios para recibir, desde un PCE de dominio, una petición de cálculo de trayecto, incluyendo la petición de cálculo de trayecto información sobre el nodo de origen del trayecto, el nodo de destino del trayecto y al menos un requisito de rendimiento de trayecto; c) medios para seleccionar a partir de algoritmos de cálculo de trayecto activos de la lista el algoritmo más adecuado según el requisito de rendimiento de trayecto; d) medios para obtener la información preliminar de trayecto para el algoritmo seleccionado; 1 e) medios para calcular el trayecto solicitado desde el nodo de origen del trayecto hasta el nodo de destino del trayecto, teniendo en cuenta al menos dicha información preliminar de trayecto, y aplicando el algoritmo de cálculo de trayecto seleccionado. Finalmente, se presenta un programa informático que comprende medios de código de programa informático adaptados para realizar el procedimiento descrito anteriormente. Otras realizaciones ejemplares también se dan a conocer en las reivindicaciones dependientes. 2 Para un entendimiento más completo de la invención, sus objetos y ventajas, puede hacerse referencia a la siguiente memoria descriptiva y a los dibujos adjuntos. Breve descripción de los dibujos 3 Para completar la descripción y con el fin de proporcionar un mejor entendimiento de la invención, se proporciona un conjunto de dibujos. Dichos dibujos forman una parte integral de la descripción e ilustran una realización preferida de la invención, que no debe interpretarse como limitativa del alcance de la invención, sino más bien como un ejemplo de cómo puede realizarse la invención. Los dibujos comprenden las siguientes figuras: La figura 1 muestra la arquitectura de un sistema de PCE padre flexible mejorado según una de las realizaciones de la invención. La figura 2 muestra un diagrama esquemático del proceso de cálculo de trayecto en línea de H-PCE para una realización de la presente invención en el escenario mostrado en el ejemplo La figura 3 muestra un diagrama esquemático del flujo de trabajo para el cálculo de trayecto para una realización de la presente invención en el escenario mostrado en el ejemplo 2. Los números y símbolos correspondientes en las diferentes figuras se refieren a partes correspondientes a menos que se indique lo contrario. Descripción detallada de la invención Las realizaciones de la presente invención presentan el diseño de un sistema de PCE padre flexible mejorado que puede trabajar con, por ejemplo, 3 bases de datos de ingeniería de tráfico diferentes, la base de datos multidominio, que contiene sólo información de la interconexión entre dominios, la base de datos de enlaces virtuales, que contiene información resumida de los dominios, y las bases de datos intradominio, que pueden contener información sobre la topología de los dominios. Dependiendo de la red, el nivel de información disponible variará y estará bajo el control del operador. Además, puesto que cada servicio y red presenta diferentes requisitos, el PCE debe permitir la construcción de algoritmos personalizados. La presente invención permite manejar diferentes algoritmos. Divide los algoritmos en dos partes, un cálculo previo o preliminar, que se realiza habitualmente en periodos inactivos y después de actualizaciones en la topología, y un cálculo en tiempo real. Además, esta invención permite al operador implantar el algoritmo particular más adecuado a sus necesidades. Además, facilita el desarrollo de algoritmo por terceras partes. La parte de cálculo previo se suscribe a cambios en las topologías, de modo que puede mejorar la escalabilidad del cálculo en el PCE padre. Con el fin de seleccionar el algoritmo adecuado, se define un conjunto de reglas, de modo que la selección de algoritmos puede configurarse por el operador basándose en diferente información de PCEP. Las nuevas funcionalidades que se han introducido en la presente invención extienden las funcionalidades de H- PCE actuales confiriendo una mayor optimización, fiabilidad y rendimiento de cálculo de trayecto multidominio que\n6 hace uso, por ejemplo, de diferentes grafos de topología, específicos para los parámetros de rendimiento deseados y usa funcionalidades de cálculo fuera de línea más en tiempo real combinadas. Con cálculos en tiempo real nos referimos a cálculos realizados cuando se recibe y procesa la petición de cálculo de trayecto, es decir, se activan mediante la recepción de una petición de cálculo de trayecto y son específicos para la petición de cálculo de trayecto que está procesándose. Con cálculos fuera de línea nos referimos a cálculos llevados a cabo en el arranque del PCE padre y cuando la información de la base de datos de TE (información de topología de los PCE de dominio) cambia. Es decir, dichos cálculos fuera de línea no se activan con la recepción de la petición de cálculo de trayecto, en realidad se realizan habitualmente antes de que se realice la petición de cálculo de trayecto. Los cálculos fuera de línea no son sólo cálculos de trayecto específicos sino pueden ser, por ejemplo, grafos personalizados, cálculo de métricas específicas y, en términos generales, cualquier cálculo que pueda realizarse de antemano (antes de que se reciba la petición de cálculo de trayecto) y que pueda ser necesario para calcular el trayecto solicitado posteriormente, en tiempo real. Algunas de las nuevas características introducidas en las realizaciones de la presente invención son: El gestor de algoritmos permite al operador de PCE coordinar la activación, desactivación y modificación de los algoritmos de cálculo de trayecto en tiempo real por medio de una interfaz dedicada. El módulo de H-PCE hace uso de algoritmos de cálculo de trayecto para proporcionar los detalles de ruta de los LSP solicitados. Elegir el mejor algoritmo para una red y servicio dados no es una cuestión sencilla, por lo que es deseable permitir que se ejecuten diferentes algoritmos, y el ajuste fino de los mismos, de modo que el operador, basándose en la experiencia pueda adecuar los algoritmos y seleccionar aquél que satisfaga mejor los requisitos en cada momento. En este contexto, la funcionalidad de gestor de algoritmos y sus interfaces, conlleva la posibilidad de adaptar las métricas y funciones objetivo usadas para calcular el LSP de E2E óptimo según las preferencias y experiencia del operador. Puede haber tres interfaces definidas, la interfaz AM-O (gestor de algoritmos - operador) que permite al desencadenador de H- PCE (es decir operadores, proveedores, etc.) activar, desactivar o modificar los algoritmos de PCE de una manera dinámica, según las preferencias y/o rendimiento de red del propietario del PCE. En segundo lugar, PCM-AM (módulo de cálculo previo gestor de algoritmos) ofrece un punto de interacción entre el gestor de algoritmos y el módulo de cálculo fuera de línea y finalmente CM-AM (módulo de cálculo) para coordinar el gestor de algoritmos con el proceso de cálculo de trayecto en tiempo real. El PCM (módulo de cálculo previo o preliminar) calcula previamente información (denominada también información preliminar de trayecto) útil para el cálculo de trayecto posterior (por ejemplo, cálculo de métricas, mediciones de parámetros y grafos de topología) para cada activo y según la información de TE asociada recopilada a partir de las TEDB. La información de TE incluye, por ejemplo, información de enlaces entre los diferentes nodos (tal como el ancho de banda de enlace, estado de disponibilidad, ID de enlace, tipo de protección de enlace, conjunto de enlaces de riesgo compartido, capacidad de conmutación de interfaz entre los nodos...). Se realiza un cálculo fuera de línea para cada algoritmo de modo que cuando llega una determinada petición de cálculo de trayecto al CM (módulo de cálculo), el cálculo de trayecto en tiempo real puede obtenerse a partir del módulo CM de manera mucho más rápida y precisa. El CM lleva a cabo un aprendizaje de cálculos de trayecto en tiempo real sobre la información de PCM (114) disponible a través de la interfaz PCM-CM. El CM también interactúa con el módulo de accesibilidad (RM) a través de la interfaz CM-RM para averiguar si puede lograrse o no un trayecto entre los nodos de origen y destino seleccionados. El módulo de accesibilidad es un módulo que recopila información relacionada con la topología a partir de la red de modo que puede garantizar que existe un posible trayecto para una determinada petición de cálculo de trayecto entrante. Este módulo se alimenta a partir de la información suministrada por el procesador de notificaciones. Conectada también al CM se ha definido la denominada cola de tareas de cálculo multidominio (MDCTQ) que se encarga de preparar las peticiones de cálculo de trayecto a las que va a darse servicio: Pueden llegar varias peticiones al despachador de peticiones conjuntamente dentro de la misma consulta y la MDCTQ las separará y administrará con el fin de gestionarlas y reenviarlas de manera adecuada al CM. Estas nuevas características (que se explicarán de manera más detallada a continuación) añadidas al módulo de H- PCE mediante esta invención están en el contexto de arquitecturas multidominio basadas en PCE que permiten a las redes de operador proporcionar a los clientes LSP de E2E de una manera mejorada en cuanto a escalabilidad y rendimiento del plano de control respecto a soluciones basadas en PCE previas. Los módulos de valor añadido y la invención, que se dirigen a optimizar los módulos de H-PCE actuales, mejoran el proceso de cálculo de trayecto mediante la utilización de varios algoritmos disponibles y el conocimiento de potenciales cambios de topología que pueden tener lugar en cuanto a los nodos, enlaces de TE y parámetros de TE en infraestructuras de red de PCE actuales. La figura 1 muestra la arquitectura de un sistema de PCE padre flexible mejorado (1) propuesto según una de las realizaciones de la presente invención, detallando los diferentes módulos e interfaces. No todos los módulos y funciones mostrados son obligatorios para el buen rendimiento del sistema (algunos de estos módulos son opcionales). En otras realizaciones, por ejemplo, las funciones de uno de los módulos pueden realizarse por otros módulos y puede haber varios módulos realizando la misma función. El sistema pueden construirse en una máquina con al menos un procesador y conectividad de red. Se recomiendan múltiples procesadores para un rendimiento superior. Los módulos en líneas discontinuas pueden construirse con tecnología del estado de la técnica. La 6\n7 funcionalidad de cada módulo se resume a continuación: Servidor de sesión de PCE (2): este módulo se encarga de aceptar sesiones de PCEP (protocolo de comunicación de PCEs) estándar desde PCE hijos (denominados también PCE de dominio) (1). Si se acepta una sesión, la comunicación se transfiere a un módulo de sesión PCE-PCE (3) dedicado. Este módulo se construye con tecnología del estado de la técnica. Sesión PCE-PCE (3): este módulo mantiene una sesión de PCEP (ya aceptada por el servidor de sesión de PCE) con un PCE hijo. Existen tantos módulos de sesión PCE-PCE activos como PCE hijos. Cuando la sesión recibe un mensaje de PCReq (petición de PCEP) (un mensaje para solicitar un cálculo de trayecto) desde un PCC (cliente de cálculo de trayecto, es decir cualquier nodo de red que solicita un cálculo de ruta al PCE), lo inserta en el módulo de cola de peticiones de PCEP (4). Cuando la sesión recibe un mensaje de PCResp (respuesta de PCEP) (un mensaje de PCEP enviado por un PCE en respuesta a una petición de cálculo de trayecto parcial) lo envía al módulo 117. Un mensaje de PCRep puede contener o bien un conjunto de trayectos calculados si puede satisfacerse la petición, o si no una respuesta negativa (la respuesta negativa puede indicar la razón de por qué no puede encontrarse ningún trayecto). Cuando la sesión recibe un mensaje de PCNtf (notificación de PCEP) (o bien enviado por un PCC a un PCE o bien enviado por un PCE a un PCC para notificar un evento específico), lo envía al módulo de procesador de notificaciones (116). Estos mensajes de protocolo PCEP y la manera en que el módulo los codifica y decodifica se definen en JP. Vasseur, JL. Le Roux, Path Computation Element Protocol, RFC 4, marzo de 09. Cola de peticiones de PCE (4): Este módulo es una cola FIFO (primero en entrar primero en salir, del inglés First In First Out) que almacena peticiones de PCEP. El módulo despachador de peticiones toma las peticiones de PCEP de este módulo. Despachador de peticiones (): Los mensajes de petición de PCEP pueden contener múltiples peticiones de trayecto, así como cálculos de trayecto sincronizados que requieren información en varios mensajes. El papel del despachador de peticiones es tomar el mensaje de PCReq y derivar a partir del mismo tareas de cálculo de trayecto multidominio (MD) autónomas (denominadas también tareas de cálculo MD). En caso de que necesite información de mensajes de PCReq adicionales, almacena temporalmente la tarea de cálculo de trayecto MD hasta que se complete. Una vez creadas las tareas de cálculo de trayecto autónomas a partir del mensaje (o mensajes) de PCReq, el despachador de peticiones las inserta en una cola de tareas de cálculo MD, a la espera de ejecutarse. Cola de tareas de cálculo MD (6): Este módulo es una cola FIFO que almacena la cola de tareas de cálculo MD. Cuando el módulo de cálculo (8) está libre (ningún cálculo está realizándose), obtiene una tarea de cálculo MD a partir de la cola de tareas de cálculo MD, en espera de que haya una nueva tarea. Obsérvese que pueden activarse varios módulos de cálculo con el fin de procesar tareas de cálculo en paralelo. Despachador de respuestas (7): Una vez que el módulo de cálculo ha calculado el trayecto del LSP multidominio solicitado, el despachador de respuestas lo reenvía hacia el módulo de sesión PCE-PCE apropiado (hay un módulo de sesión PCE-PCE activo por cada PCE hijo). Módulo de cálculo (8): Este módulo se encarga de realizar la tarea de cálculo de trayecto. Obtiene una tarea de cálculo MD a partir de la cola de tareas de cálculo MD. Con los detalles de la tarea de cálculo MD consulta al módulo selector de algoritmos (113) para saber qué algoritmo de cálculo en tiempo real se elige. El módulo de cálculo tiene disponible un conjunto de algoritmos de cálculos en tiempo real, que son algoritmos con diferentes características y rendimiento para su ejecución en tiempo real para encontrar el trayecto adecuado entre un nodo de origen y un nodo de destino (especificado en la tarea de cálculo). Una vez elegido el algoritmo de cálculo en tiempo real apropiado, obtiene su información calculada previamente del módulo de cálculo previo. De este modo, cada algoritmo puede mantener su grafo particular, puede calcular previamente el coste, calcular previamente trayectos, etc., mejorando la escalabilidad y el rendimiento. Por tanto, las tareas complejas fuera de línea pueden realizarse por el módulo de cálculo previo, y se procesan peticiones en tiempo real por medio del cálculo en tiempo real. Módulo de TEDB multidominio (9): Este módulo es una base de datos de ingeniería de tráfico multidominio estándar, que contiene la información sobre los nodos de límite de dominios y enlaces entre nodos pertenecientes a diferentes dominios, en otras palabras, la topología interdominio e información de recursos de los enlaces de TE interdominio. La información pueden enviarse a esta TEDB (y a las otras TEDB) de manera periódica o cuando exista cualquier cambio en la información interdominio de dicho dominio, o bien mediante anuncios de estado de enlace (LSA) incrustados en el mensaje de PCNtf desde los PCE de dominio, recibiendo tal LSA desde el módulo de procesador de notificaciones, o bien externamente por medio de anuncios de estado de enlace de OSPF- TE (121). Cada vez que exista una actualización en la topología, se notifica al módulo de cálculo previo, de modo que pueda proceder a los cálculos previos específicos necesarios para cada algoritmo. Esta TEDB debe llenarse (por cualquiera de los medios anteriores). 7\n8 Módulo de TEDB virtual intradominio (1): Este módulo es una base de datos de ingeniería de tráfico, que contiene una topología resumida de los dominios (naturalmente, de dicho dominios que proporcionan tal información). La información puede enviarse a esta TEDB (de manera periódica o cuando exista cualquier cambio en la información interdominio de dicho dominio). Los enlaces anunciados son enlaces no reales, aunque dan una indicación del coste de ir de un nodo a otro. La cantidad de información enviada dependerá del PCE hijo. Por tanto, el llenado de esta TEDB virtual intradominio es opcional, y puede haber información perteneciente sólo a algunos dominios. Esta TEDB puede estar vacía o no existir (es decir, es opcional). TEDB intradominio (111): Este módulo es una base de datos de ingeniería de tráfico, que contiene información sobre los nodos de dominio y enlaces entre nodos del dominio. Esto es especialmente útil en casos en los que la división en la red en dominios se basa en motivos diferentes del tamaño de la red (por ejemplo, mantener un dominio por proveedor). Por ejemplo, el topología completa de los dominios puede reenviarse desde el PCE hijo al PCE padre. La información puede reenviarse a esta TEDB (de manera periódica o cuando exista cualquier cambio en la información interdominio de dicho dominio). El nivel de información que se reenvía debe controlarse en los PCE hijos para evitar la sobrecarga del PCE padre y permite el ajuste fino de la cantidad de información enviada. El PCE padre no necesita usar toda esta información. Depende del algoritmo específico usarla. En cualquier caso, el módulo de cálculo previo permite un procesamiento previo de esta información para facilitar los cálculos. Esta TEDB puede alimentarse por PCE hijos de dominio o puede estar vacía o no existir (es decir, es opcional). Gestor de algoritmos (112): Este módulo carga, activa y desactiva los algoritmos. Cada algoritmo tiene dos fases: una fase de cálculo de trayecto en tiempo real y una fase de cálculo previo (denominada también fase preliminar en la que se calculan parámetros, métricas y grafos asociados al algoritmo). Cuando se carga el algoritmo se hace disponible en el módulo de cálculo y el módulo de cálculo previo y, en cada uno de estos módulos, un submódulo (122, 123) se encarga de realizar la fase de cálculo en tiempo real y la fase de cálculo previo respectivamente para cada algoritmo cargado. Cuando se activa el algoritmo, indica al módulo de cálculo previo que notifique cualquier cambio de topología al submódulo de cálculo previo específico para el algoritmo activado y se realiza el cálculo previo del algoritmo activado. Este módulo también recibe reglas para seleccionar algoritmos desde el operador y las envía al selector de algoritmos. Selector de algoritmos (113): Este módulo, basándose en el conjunto de reglas configuradas procedentes del gestor de algoritmos y los detalles de la tarea de cálculo MD, decide qué algoritmo debe usarse. Más adelante se explicará cómo pueden definirse y procesarse las reglas. Módulo de cálculo previo (114) PCM: Este módulo se encarga de calcular información útil para el cálculo de trayecto posterior, realizando, por ejemplo, cálculo de métricas fuera de línea, mediciones de parámetros y preparar grafos si se requiere. Es decir, este módulo realiza cálculos que pueden realizarse de antemano y que serán necesarios para que el CM calcule el trayecto solicitado en tiempo real. De este modo, este módulo ayuda, con cálculos fuera de línea previos, al módulo de cálculo para calcular en tiempo real trayectos entre un nodo de origen y de destino. Cada vez que exista un cambio en las TEBD, se notifica al PCM. Esta notificación se reenvía entonces al submódulo de cálculo previo específico (para cada algoritmo activo). Entonces, cada submódulo puede actualizar sus grafos, métricas y parámetros particularizados. Esta información calculada previamente para cada algoritmo (denominada también información preliminar de trayecto ) no consiste en cálculos de trayecto en línea sino en los cálculos que pueden realizarse previamente fuera de línea con el fin de, posteriormente en el CM, calcular trayectos en tiempo real. Módulo gestor de accesibilidad (11): El módulo gestor de accesibilidad se encarga de determinar a qué dominio pertenece un nodo. El módulo de cálculo consulta al módulo gestor de accesibilidad con los puntos de extremo del trayecto, y obtiene sus dominios. La información se obtiene a partir de las notificaciones de PCEP del módulo procesador de notificaciones. Procesador de notificaciones (116): Este módulo interpreta las notificaciones de PCEP enviadas por los PCE hijos. Si la notificación es información de accesibilidad (tal como se define, por ejemplo, en la correspondiente recomendación ITU G-80 o en F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King, Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE). el contenido de la notificación se envía al módulo gestor de accesibilidad. Si la notificación contiene un anuncio de estado de enlace, se envía a la TEDB específica (dependiendo del tipo de LSA). De lo contrario, procesa las notificaciones (tal como se indica en RFC 4). Módulo gestor de peticiones de PCE hijo (117): Este módulo se encarga de enviar peticiones de cálculo de trayecto intradominio en paralelo a los PCE hijos (específicamente a la sesión PCE-PCE de los PCE hijos seleccionados) y asociar las respuestas del PCE hijo a las peticiones enviadas. Una vez que todos los PCE de dominio hayan respondido, envía la lista de respuestas al módulo de cálculo (8). 8\n9 Ahora, se explicarán en más detalle los nuevos módulos principales introducidos en la presente invención y las relaciones principales entre estos módulos: Gestor de algoritmos: este módulo se encarga de la gestión de algoritmos. Carga, activa y desactiva algoritmos de cálculo multidominio. Además, se encarga de establecer las reglas para seleccionar el algoritmo. El gestor de algoritmos (AM) contiene la lista completa de algoritmos disponibles (nombre_algoritmo) correlacionada con sus identificadores internos correspondientes (ID_algoritmo). La relación entre el AM y el resto de los módulos se muestra en la figura 1. Tal como puede observarse en la figura 1, el operador de red se interconecta directamente con el módulo de gestor de algoritmos a través de la interfaz operador-gestor de algoritmos (O-AM-I 1). Mediante las peticiones desde el operador a través de la O-AM-I, activará un determinado algoritmo de modo que estará listo para usarse en caso de que se requiera (e informará de dicha activación al módulo de cálculo previo). De este modo, el sistema no sólo tiene un único algoritmo activo sino que existe la posibilidad de tener más de uno activado. Con el fin de poder usarse, el operador también debe añadir una regla o conjunto de reglas de uso a través de la O-AM-I, que se emplearán para seleccionar el algoritmo que va a usarse dependiendo del escenario específico. Cuando se carga un algoritmo, desde entonces está disponible en el módulo de cálculo y el módulo de cálculo previo. Cuando se activa el algoritmo, indica al módulo de cálculo previo que notifique cualquier cambio de topología al submódulo de cálculo previo específico con el fin de preparar la información preliminar de trayecto (es decir, realizar el cálculo de métricas, mediciones de parámetros, grafos, etc.) de tal algoritmo. Cuando el operador solicita la desactivación de un algoritmo, el módulo reenvía esta acción hacia los módulos CM (8) y PCM (114). Cuando se desactiva un algoritmo, éste no puede seleccionarse por el selector de algoritmos para el cálculo de trayecto en tiempo real. Además, todas las reglas asociadas a ese algoritmo deben eliminarse. Por tanto, el gestor de algoritmos usa las siguientes interfaces: interfaz operador-am (1), para interactuar con el operador; interfaz AS-AM (2), para interactuar con el selector de algoritmos; interfaz AM-PCM (4) que interactúa con el módulo de cálculo previo y la interfaz AM-CM () para interactuar con el módulo de cálculo. A través de la interfaz operador-am, pueden enviarse los siguientes mensajes: 1. Cargar algoritmo (nombre_algoritmo): el operador solicita la carga de un algoritmo. Con esta acción, el AM asigna al algoritmo un ID_algoritmo interno. 2. Activar algoritmo (nombre_algoritmo): el operador solicita la activación de un algoritmo. El AM activa la notificación de cambios de topología al cálculo previo. 3. Desactivar_algoritmo (nombre_algoritmo): el operador solicita la desactivación de un algoritmo. El AM desactiva la notificación de cambios de topología al cálculo previo. 4. Añadir_regla_algoritmo (nombre_algoritmo, definición_regla). El operador solicita la adición de una nueva regla para seleccionar un algoritmo. El AM reenvía la regla al módulo de AS.. Eliminar_regla_algoritmo (nombre_algoritmo, definición_regla). El operador solicita la eliminación de una regla para seleccionar un algoritmo. El AM elimina la regla en el módulo de AS. nombre_algoritmo es una cadena con el nombre del algoritmo. definición_regla es una cadena que contiene la definición XML de la regla. El gestor de algoritmos envía los siguientes mensajes en respuesta a las peticiones anteriores: 1. Carga_algoritmo (éxito, nombre_algoritmo): si el algoritmo se ha cargado satisfactoriamente o no. 2. Activación_algoritmo (éxito, nombre_algoritmo): si el algoritmo se ha activado satisfactoriamente o no. 3. Desactivación_algoritmo (éxito, nombre_algoritmo): si el algoritmo se ha desactivado satisfactoriamente o no. 4. Adición_regla (éxito, nombre_algoritmo, definición_regla): si la regla de selección de algoritmo se ha instalado satisfactoriamente.. Eliminación_regla (éxito, nombre_algoritmo, definición_regla): si la regla de selección de algoritmo se ha eliminado satisfactoriamente. El campo de éxito es verdadero si la acción se realizó correctamente o falso si no se tuvo éxito. A través de la interfaz selector de algoritmos (AS) - gestor de algoritmos (AM), el gestor de algoritmos puede añadir y eliminar reglas de selección de algoritmos de algoritmos activos. El AM puede enviar los siguientes mensajes al AS: 1. Añadir_regla_algoritmo (ID_algoritmo, definición_regla): el AM solicita la adición de una nueva regla para seleccionar un algoritmo. El módulo de AS procesa la definición de regla XML. 2. Eliminar_regla_algoritmo (ID_algoritmo, ID_regla): el AM solicita la eliminación de una nueva regla para seleccionar un algoritmo. 3. Eliminar_todas_reglas (ID_algoritmo): el AM solicita la eliminación de todas las reglas para 9\n10 seleccionar un algoritmo. Se envía cuando se desactiva el algoritmo en el AM. ID_algoritmo es un número que identifica internamente el algoritmo (este número se asignó en el momento de la carga). ID_regla es un número que identifica internamente la regla de selección de algoritmo. Definición_regla es una cadena que contiene la definición XML de la regla. El AS puede enviar las siguientes respuestas al AM: 1 1. Adición_regla_algoritmo (éxito, ID_algoritmo, definición_regla, ID_regla): el módulo de AS ha procesado la definición de regla XML correctamente y pudo instalarla o tuvo problemas al procesar la regla XML y no pudo instalarla. 2. Eliminación_regla_algoritmo (éxito, ID_algoritmo, ID_regla): la regla se eliminó satisfactoriamente o no. 3. Eliminación_todas_reglas (éxito, ID_algoritmo): todas las reglas se eliminaron satisfactoriamente o no. A través de la interfaz módulo de cálculo (CM) - gestor de algoritmos (AM), se envían los siguientes mensajes desde el AM al CM: 2 1. Activar_algoritmo (ID_algoritmo): este mensaje indica al CM (8) que active un algoritmo para su uso para el proceso de cálculo de trayecto. 2. Desactivar_algoritmo (ID_algoritmo): este mensaje indica al CM (8) que desactive un algoritmo para su uso para el proceso de cálculo de trayecto. Los siguientes mensajes se envían en respuesta 1. Acuse de recibo (ID_algoritmo) 2. NACK (ID_algoritmo). 3 A través de la interfaz módulo de cálculo previo (PCM) - gestor de algoritmos (AM), se envían los siguientes mensajes desde el AM al PCM: 1. Activar_algoritmo (ID_algoritmo): este mensaje indica al PCM (8) que active un algoritmo para su uso para el proceso de cálculo de trayecto. 2. Desactivar_algoritmo (ID_algoritmo): este mensaje indica al PCM (8) que desactive un algoritmo para su uso para el proceso de cálculo de trayecto. Los siguientes mensajes se envían en respuesta Acuse de recibo (ID_algoritmo) 2. NACK (ID_algoritmo) Selector de algoritmos (AS): recibe consultas desde el AM (112) para añadir y eliminar las reglas definidas para los algoritmos a través de la interfaz AS-AM (1). Basándose en estas entradas, el AS (113) establece el estado de las reglas de modo que cuando una determinada petición de selección de algoritmo llega a este módulo, el AS selecciona el algoritmo que va a usarse dependiendo de las reglas definidas y según los parámetros incluidos en dicha petición, denominados también requisitos de rendimiento de trayecto. Existen varios parámetros de requisitos de rendimiento de trayecto que pueden incluirse en la petición (son objetos de IETF estándar que se incluyen en el mensaje de petición): Vector de sincronización (SVEC): cuando un PCE calcula conjuntos de peticiones de cálculo de trayecto dependientes simultáneamente, se requiere el uso de la lista Vector de sincronización (SVEC) para la asociación entre los conjuntos de peticiones de cálculo de trayecto dependientes. El objeto SVEC es opcional (se define en I. Nishioka, D. King, Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations, RFC 07, septiembre de ). Función objetivo (OF): es un conjunto de uno o más criterios de optimización, usados por el PCE cuando calcula un trayecto o un conjunto de trayectos con el fin de seleccionar los mejores trayectos candidatos. Se define, por ejemplo, en (JL. Le Roux, JP. Vasseur, Y. Lee, Encoding of Objective Functions in the Computation Element Communication Protocol (PCEP) ). Métricas: aparte de las métricas de TE comunes, puede haber métricas propietarias adicionales que requieren la realización de cálculos adicionales. Parámetro de capa de conmutación: indica la capa en la que el trayecto debe calcularse. En entornos multicapa el algoritmo elegido puede depender de la capa en la que se esté trabajando. Objeto intercapa: indica si el cálculo requiere realizarse en varias capas al mismo tiempo. En estos casos el algoritmo también es específico. Información más detallada sobre este parámetro y el\n11 parámetro de capa de conmutación puede encontrarse en (E.Oki et al Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-LAYER MPLS and GMPLS Traffic Engineering ) Además de estos parámetros pueden definirse parámetros adicionales que pueden incluirse. No obstante, puesto que no son representativos al seleccionar el algoritmo están fuera del alcance de este documento. El AS pasa su decisión a los módulos PCM (114) y CM (8) (a través de las interfaces 2 y 3 respectivamente). El AS informa al AM por medio de la interfaz AS-AM acerca del éxito de la operación. Módulo de cálculo previo (PCM 114): este nuevo módulo se encarga de llevar a cabo los cálculos previos fuera de línea (cálculos previos) que necesitarán posteriormente los algoritmos para calcular el trayecto solicitado. El módulo de cálculo previo recibe notificaciones de cambios de topología directamente desde las diferentes TEDB (9, 1 y 111), de modo que conoce los cambios y puede decidir si se necesitan nuevas acciones/cálculos. Las actualizaciones de topología pueden comprender por ejemplo un grafo de dominio de topología completo o sólo un cambio de enlace sencillo entre nodos. Normalmente, en el arranque, se calculan las métricas y grafos particulares que serán usados posteriormente por el CM. En algunos casos, por ejemplo en aquellos en los que el CM necesita proporcionar una respuesta ultrarrápida, el PCM puede realizar incluso un cálculo de trayecto entre cada par de nodos nodo_origen-nodo_destino posibles y almacenar dichos cálculos en memoria. Sin embargo, esto no es obligatorio. En caso de que se modifique alguna información en una o varias de estas TEDB, se notifica al PCM mediante las TEBD, el módulo PCM (114) actualiza dichos cambios teniéndolos en cuenta en el cálculo previo (por ejemplo, en los cálculos de trayecto de pares nodo_origen-nodo_destino). Estos cambios pueden añadir/eliminar nodos frontera o de límite o variaciones en los parámetros de ingeniería de tráfico (TE) que afectan al par nodo_origen-nodo_destino. El módulo de cálculo previo contiene una lista con cada algoritmo activado. Cada vez que haya una notificación con una actualización de las TEDB, el módulo de cálculo previo pasa por dicha lista de algoritmos y ejecuta el proceso de actualización definido para el algoritmo. El gestor de cálculo previo puede realizar las siguientes funciones a partir de los desencadenadores recibidos desde la MDTEDB (9), la VTEDB (1) y la IDTEDB (111) a través de las correspondientes interfaces (6, 7 y 8 respectivamente). 1. Añadir/eliminar_nodo (ID_nodo, ID_dominio): se añade/elimina un determinado nodo de dominio basándose en el identificador de nodo. 2. Modificar_enlace_TE_existente (ID_enlace_TE, ID_dominio): modifica determinadas características de enlace de TE de dominio basándose en la información recuperada de las TEDB (9, 1 y 111). Módulo de cálculo (CM 8): La principal diferencia entre este módulo y el PCM (114) consiste en lo siguiente: por un lado el PCM realiza cálculos fuera de línea que tienen que ver con cada una de las métricas, parámetros y/o grafos de algoritmo específicos (tal como se definió anteriormente, esto se realiza en el arranque del PCE y también en caso de que la información contenida en las TEDB (9, 1 y/o 111) cambie y estas métricas, parámetros y grafos se vean afectados). Por otro lado, el módulo de cálculo (CM) realiza los cálculos en tiempo real tal como se definió anteriormente, es decir, calcula el trayecto más adecuado entre un determinado par de nodo_origen-nodo_destino (incluido en el mensaje de petición de cálculo de trayecto). Para realizar esto, se tienen en cuenta la información calculada por el PCM fuera de línea previa (métricas, parámetros y grafos) y los parámetros especificados en el mensaje de petición de PCEP. El módulo de cálculo solicita al gestor de accesibilidad (11) los dominios a los que pertenecen el nodo_origen y nodo_destino, de modo que en caso que ambos pertenezcan a los dominios gestionados por el PCE padre (1), elegirá el algoritmo (por el selector de algoritmos) para calcular el mejor trayecto entre estos nodos. De otro modo, desencadenará un mensaje sin_trayecto. El CM también envía al selector de algoritmos las condiciones solicitadas para el trayecto (requisitos de rendimiento de trayecto) de modo que pueda seleccionarse el algoritmo apropiado. Estos requisitos pueden ser, por ejemplo, la función objetivo del trayecto (coste mínimo, distancia mínima, capacidad máxima ). Interfaz MDTEDB PCM (MDTEDB-PCM-I) (6): esta interfaz permite a la MD-TEDB (9) enviar información relacionada con multidominio (es decir, información sobre los nodos de límite de dominios y enlaces entre nodos pertenecientes a diferentes dominios) para cada dominio gestionado por el PCE padre, al módulo de cálculo previo (114) cuando exista cualquier cambio, con el fin de actualizar estos cambios en los grafos de topología (y otra información preliminar de trayecto ) asociados a cada algoritmo que está usándose. La información reenviada se intercambia usando los mensajes de OSPF estándar de actualización_estado_enlace. Siempre que un determinado parámetro o nodo de red o enlace cambie, no sólo se modifica este parámetro sino que, a partir de los mensajes de actualización de estado de enlace, todo puede sobrescribirse nuevamente. Los mensajes intercambiados pueden ser: 11\n12 El proceso es similar para tanto las opciones de añadir como de eliminar : Añadir/eliminar_enlace_interdominio 1. Un determinado D-PCE (PCE de dominio) recibe un mensaje de actualización_estado_enlace de OSPF que informa acerca del estado de determinados enlaces de la LSDB (base de datos de estado de enlace) de dominio del D-PCE. 2. El D-PCE reenvía este mensaje a la MDTEDB (9) de H-PCE, que extrae la información multidominio contenida en el mensaje de estado_enlace. 3. En caso de que se detecte cualquier cambio de enlace multidominio, la MDTEDB (9) actualiza estos cambios: a. Si existe un nuevo enlace interdominio o uno de los enlaces interdominio ya existentes experimenta una variación en cualquiera de sus parámetros, se envía un mensaje de añadir_enlace_interdominio al PCM (114). b. Si un determinado enlace interdominio deja de funcionar y la comunicación a través de éste ya no es posible, se envía un mensaje de eliminar_enlace_interdominio al PCM (114). 4. El PCM (114) envía un mensaje de ACK en caso de que la actualización se haya recibido satisfactoriamente. Añadir/eliminar nodo frontera (también llamado de límite) 1. Un determinado D-PCE recibe un mensaje de actualización_estado_enlace de OSPF que informa acerca de un nodo frontera que se ha añadido/eliminado al dominio. 2. El D-PCE reenvía este mensaje a la MDTEDB (9) de H-PCE, que extrae la información multidominio contenida en el mensaje_estado_enlace. 3. En caso de que se detecte cualquier cambio de nodo frontera multidominio, la MDTEDB (9) actualiza estos cambios: a. Si existe un nuevo nodo frontera se desencadena un mensaje de añadir_nodo_límite al PCM (114). b. Si un determinado nodo interdominio deja de funcionar o se elimina de la topología, se desencadena un mensaje de eliminar_nodo_límite al PCM (114). 4. El PCM (114) envía un mensaje de ACK en caso de que la actualización de nodo de límite se haya recibido satisfactoriamente. Interfaz IDTEDB PCM (IDTEDB-PCM-I) (8): esta interfaz permite a la IDTEDB (111) enviar información relacionada con intradominio (es decir, información sobre los nodos del dominio y enlaces entre nodos pertenecientes al dominio) para cada dominio gestionado por el PCE padre, al módulo de cálculo previo (114) cuando exista cualquier cambio, con el fin de actualizar estos cambios en los grafos de topología asociados al algoritmo que está usándose. La información reenviada se intercambia usando los mensajes de OSPF estándar de actualización_estado_enlace. Siempre que un determinado parámetro intradominio, nodo de red o enlace cambie, no sólo se modifica este parámetro sino que, a partir de los mensajes de actualización de estado de enlace, todo puede sobreescribirse nuevamente. Debe señalarse que las funcionalidades tanto de la IDTEDB (111) como de la IDTEDB-PCM-I (8) son opcionales y sólo pueden tener sentido en caso de que el H-PCE tenga acceso a la información intradominio parcial o total. Los mensajes intercambiados son: El proceso es similar para tanto las opciones de adición como de eliminación : Añadir/eliminar_enlace_intradominio 1. Un determinado D-PCE recibe un mensaje de actualización_estado_enlace de OSPF que informa acerca del estado de determinados enlaces de la LSDB (base de datos de estado de enlace) de dominio del D-PCE. 2. El D-PCE reenvía este mensaje a la IDTEDB (111) de H-PCE, que extrae la información intradominio contenida en el mensaje de estado_enlace. 3. En caso de que se detecte cualquier cambio de enlace multidominio, la IDTEDB (111) actualiza estos cambios: a. Si existe un nuevo enlace intradominio o uno de los enlaces intradominio ya existentes experimenta una variación en cualquiera de sus parámetros, se envía un mensaje de añadir_enlace_intradominio al PCM (114). b. Si un determinado enlace intradominio deja de funcionar y la comunicación a través de éste ya no es posible, se envía un mensaje de eliminar_enlace_intradominio al PCM (114). 4. El PCM (114) envía un mensaje de ACK en caso de que la actualización se haya recibido satisfactoriamente. Añadir/eliminar_nodo 1. Un determinado D-PCE recibe un mensaje de actualización_estado_enlace de OSPF que informa 12\n13 acerca de un nodo que se ha añadido/eliminado en el dominio. 2. El D-PCE reenvía este mensaje a la MDTEDB (9) de H-PCE, que extrae la información intradominio contenida en el mensaje_estado_enlace, en caso de que el H-PCE tenga acceso a la información intradominio parcial o total. 3. En caso que se detecte cualquier cambio de nodo intradominio, la IDTEDB (1) actualiza estos cambios: a. Si existe un nuevo nodo interno se desencadena un mensaje de añadir_nodo al PCM (114). b. Si un determinado nodo intradominio deja de funcionar o se elimina de la topología, se desencadena un mensaje de eliminar_nodo al PCM (114). 4. El PCM (114) envía un mensaje de ACK en caso de que la actualización de nodo de límite se haya recibido satisfactoriamente. Interfaz VTEDB PCM (VTEDB-PCM-I) (7): esta interfaz permite a la VTEDB (1) enviar información relacionada con intradominio virtual (es decir, información sobre los nodos del dominio virtuales y enlaces virtuales entre nodos pertenecientes al dominio) para cada dominio gestionado por el PCE padre, al módulo de cálculo previo (114) con el fin de actualizar estos cambios en los grafos de topología asociados al algoritmo que está usándose. La información reenviada se intercambia usando los mensajes de OSPF estándar de actualización_estado_enlace. Siempre que un determinado enlace virtual experimenta un cambio o se rompe, no sólo se modifica este parámetro sino que, a partir de los mensajes de actualización de estado de enlace, todos los parámetros de enlace virtual pueden sobreescribirse nuevamente. Debe señalarse que tanto la VDTEDB (1) como la VTEDB-PCM-I (7) son funcionalidades opcionales. Los mensajes intercambiados son: El proceso es similar para tanto las opciones de adición como de eliminación : Añadir/eliminar_enlace_virtual 1. Un determinado D-PCE recibe un mensaje de actualización_estado_enlace de OSPF que informa acerca del estado de determinados enlaces virtuales de la LSDB (base de datos de estado de enlace) de dominio del D-PCE. 2. El D-PCE reenvía este mensaje a la MDTEDB (9) de H-PCE, que extrae la información de enlace virtual contenida en los mensaje de estado_enlace. 3. En caso de que se detecte cualquier cambio de enlace virtual, la VTEDB (1) actualiza estos cambios: a. Si existe un nuevo enlace virtual o uno de los ya existentes experimenta una variación en cualquiera de sus parámetros, se envía un mensaje de añadir_enlace_virtual al PCM (114). b. Si un determinado enlace virtual deja de funcionar y la comunicación a través de éste ya no es posible, se envía un mensaje de eliminar_enlace_virtual al PCM (114). 4. El PCM (114) envía un mensaje de ACK en caso de que la actualización se haya recibido satisfactoriamente. Añadir/eliminar_nodo_virtual 1. Un determinado D-PCE recibe un mensaje de actualización_estado_enlace de OSPF que informa acerca de un nodo virtual que se ha añadido/eliminado a la topología de dominio. 2. El D-PCE reenvía este mensaje a la VTEDB (111) de H-PCE, que extrae la información virtual contenida en el mensaje_estado_enlace. 3. En caso de que se detecte cualquier cambio de nodo virtual, la VTEDB (111) actualiza estos cambios: a. Si existe un nuevo nodo de límite se envía un mensaje de añadir_nodo_virtual al PCM (114). b. Si un determinado enlace interdominio deja de funcionar o se elimina de la topología, se envía un mensaje de eliminar_nodo_virtual al PCM (114). 4. El PCM (114) envía un mensaje de ACK en caso de que la actualización de nodo de límite se haya recibido satisfactoriamente. Gestor de accesibilidad (11): este módulo realiza una correlación nodo - dominio, es decir, almacena información sobre a qué dominio pertenece cada nodo. El CM (8) puede enviar una petición (a través de la interfaz 9) que pide los dominios a los que pertenece un determinado nodo_origen-nodo_destino con el fin de proceder al proceso de cálculo de trayecto sólo en caso de que exista un trayecto disponible (habitualmente esto ocurre en caso de que ambos nodos pertenezcan a dominios gestionados por el PCE padre (1)). De lo contrario, desencadenará un mensaje de sin_trayecto. Cola de tareas de cálculo multidominio (MDCTQ - 6): este módulo consiste en un módulo que administra las peticiones de cálculo de trayecto que llegan al sistema. Varias peticiones pueden llegar al despachador de peticiones () conjuntamente dentro de la misma consulta y la MDCTQ (6) las separará y 13\n14 administrará con el fin de gestionarlas y reenviarlas adecuadamente al CM (8) Como ejemplos del funcionamiento de la presente invención, se presentan dos escenarios potenciales en los que la invención propuesta ayuda a los operadores de red a calcular trayectos optimizados (por ejemplo, LSP) en un entorno multidominio y de múltiples proveedores. Ejemplo 1: Se presenta un cálculo de trayecto multidominio con vista de topología extendida y escenario de cálculo previo. En este ejemplo, puede observarse un conjunto de funcionalidades de valor añadido introducidas por la presente invención como: 1) la posibilidad de que los algoritmos usen las tres bases de datos de TE permite que el sistema de H-PCE propuesto realice mejores cálculos de LSP E2E (punto a punto del inglés end to end) ya que permite realizar un seguimiento de un mapa global del estado de los recursos de dominio 2) el módulo de cálculo previo permite a la solución ajustarse a escala y manipular una gran cantidad de información en las bases de datos 3) ayudará a reducir las consultas a PCE hijos. En este primer escenario, existen tres dominios (con PCEs, PCE1, PCE2 y PCE3), cada uno de los mismos gestionado por un proveedor de sistemas ópticos de transporte diferentes. Estos dominios interconectados constituyen una topología de red global que es propiedad de un único operador de red. El hecho de tener un escenario de múltiples proveedores compuesto por varios dominios hace necesario incluir en el H-PCE las funcionalidades: realizar un seguimiento de las sesiones PCE-PCE, mantener un mapa completo de los parámetros y recursos de sesión que están usándose y mantener actualizado el estado de la accesibilidad interdominio. Esto se realiza por medio del conjunto de bases de datos de TE, que permite al módulo de cálculo previo tener un grafo de topología actualizado y un cálculo de trayecto mediante el algoritmo seleccionado deseado y por medio del gestor de accesibilidad (que realiza una correlación nodo - dominio). Tal como se explicó anteriormente, en una primera fase hay un proceso de cálculo previo que permite al sistema mantener un grafo de topología actualizado asociado a los algoritmos activos. La secuencia de etapas para actualizar el conjunto de bases de datos de TE y llevar a cabo el proceso de cálculo previo puede ser la siguiente: 1. Los PCE hijos de dominio están reenviando continuamente hacia el H-PCE (denominado también PCE padre) información relacionada con cambios en la topología interdominio (por ejemplo, nuevo enlace interdominio) y de manera opcional en la intradominios. La MDTEDB (9) y la IDTEDB (111) almacenan estas actualizaciones de dominio respectivamente. Las TEDB reciben tales actualizaciones desde el módulo de procesador de notificaciones (que recibe las actualizaciones desde los PCE de dominio mediante anuncios de estado de enlace) o directamente desde los PCE de dominio mediante anuncios de estado de enlace de OSPF-TE. 2. El PCM (114) hace uso de la información de TEDB y calcula previamente los trayectos de topología y otra información preliminar de trayecto según cada algoritmo activo Siempre que una determinada petición de cálculo de trayecto llega al H-PCE, la información preliminar de trayecto calculada previamente en la etapa 2 para un algoritmo específico (seleccionado por el selector de algoritmos) se reenvía por el PCM (114) al módulo de cálculo (8), que opera en tiempo real proporcionando un trayecto adecuado que se apoya en dicha información calculada previamente del PCM (114). En una segunda fase, suponiendo un estado estático de la red con un algoritmo específico seleccionado y las TEDB y el PCM (114) con información de topología calculada previamente actualizada, el proceso de cálculo de trayecto en línea interdominio de H-PCE para este ejemplo específico se muestra en la figura 2. Las etapas seguidas durante el proceso de cálculo de trayecto son las siguientes: - Determinado PCE, PCE1, solicita al H-PCE (1) un nuevo trayecto entre uno de sus nodos (BN11) y otro nodo ubicado en un dominio remoto (BN32 del dominio 3). El PCE1 determina que el BN32 no está dentro de su propio dominio y envía una petición de cálculo al H-PCE (mensaje de petición de PCEP). - El H-PCE hace uso del módulo gestor de accesibilidad para saber si ambos nodos pertenecen a dominios gestionados por el H-PCE. Suponiendo que éste es el caso, el módulo de cálculo determina los trayectos de dominio probables según la interconectividad de dominios y capacidades de TE entre dominios, el algoritmo de cálculo seleccionado por el selector de algoritmos y la información preliminar de trayecto enviada por el PCM. Según la figura 2, el trayecto puede ser BN12-BN21-intradominio 2-BN22-BN31-intradominio 3-BN32. En este caso, suponemos que el H-PCE conoce las conexiones interdominio pero no tiene información sobre el intradominio. El H- PCE debe, por tanto, enviar peticiones de cálculo de trayecto parciales (entre nodos frontera) al PCE2, responsable del dominio 2, y al PCE3, responsable del dominio 3 (en la figura 2, 2 y 3 respectivamente). Esto se realiza a través del módulo gestor de peticiones de PCE hijo (117). - El PCE2 y el PCE3 envían sus respuestas hacia el H-PCE (4 y respectivamente) que correlaciona ambas respuestas de cálculo conjuntamente con la información calculada previamente, añade la información sobre los enlaces interdominio y aplica cualquier requisito solicitado o configurado localmente. 14\n15 Entonces, en este ejemplo, los grafos de topología calculados previamente por el PCM sólo se usan para los trayectos interdominio, ya que los trayectos intradominio se calculan por los dominios hijos. Finalmente, el H-PCE reenvía el LSP calculado entre el BN11 y el BN32 al PCE1 (6), que fue el PCE original que envío la petición de cálculo de trayecto de LSP. Ejemplo 2: En este ejemplo puede observarse un conjunto de funcionalidades de valor añadido introducidas por la presente invención como el proceso de flexibilidad al calcular trayectos multidominio haciendo uso de varios algoritmos activos y disponibles. Seleccionando un algoritmo apropiado para los requisitos exigidos, el selector de algoritmos (en coordinación con el AM) permite a los módulos CM y el PCM ofrecer diferentes soluciones de trayecto para diferentes peticiones de cálculo de trayecto que exigen diferentes requisitos (por ejemplo, funciones objetivo, condiciones de red, políticas, etc.). La dificultad tiene que ver no sólo con la selección del algoritmo de cálculo de trayecto adecuado sino también con la coordinación entre el algoritmo seleccionado y el proceso de mapeo de topología que se actualiza a partir de la información de TEDB. Este ejemplo muestra los procesos internos que deben llevarse a cabo con el fin de atender peticiones multidominio que exigen un cálculo de trayecto basándose en una métrica específica. Por simplicidad se considera que existe un único módulo CM en el H-PCE. También debe suponerse que las dos peticiones de cálculo de trayecto multidominio han llegado a la MDCTQ cada una de ellas con diferentes funciones que van a maximizarse. El operador por medio del AM ha activado y desactivado determinados algoritmos que pueden usarse para calcular los trayectos. Las etapas seguidas para ambos procesos de cálculo de trayecto (mostradas en la figura 3) son las siguientes: 1. La MDCTQ 6 observa que el CM está disponible para llevar a cabo una nueva petición de cálculo de trayecto denominada CR1 (petición de cálculo 1) y reenvía esta CR1 al CM (1), en el que se procesa la CR1. La CR1 solicita un trayecto entre un nodo_origen y un nodo_destino, cumpliendo dicho trayecto un determinado requisito de rendimiento de trayecto (por ejemplo, una función objetivo tal como trayecto de ancho de banda disponible residual máximo ). 2. Con los detalles de RC1, el CM solicita (2) al AS el algoritmo adecuado que puede ajustarse al requisito de rendimiento de trayecto solicitado. La información sobre el ID de nodo_origen y nodo_destino y el rendimiento solicitado (en este caso la función objetivo), que se necesitan para seleccionar el algoritmo apropiado también se reenvía por el CM al AS en el mismo mensaje de petición (2) o en un mensaje separado (3). 3. El AS pasa a través de su lista de algoritmos (4) (en la que se almacena una lista de algoritmos y sus estados, activo o no activo) y selecciona de los activos, el más adecuado para la CR1 solicitada entre el nodo_origen y nodo_destino. El algoritmo elegido es AL1. Suponiendo que AL1 se ha activado previamente por el AM, el mapa de topología de trayecto calculado previamente y el resto de parámetros y métricas definidos para este algoritmo ya se han calculado. Entonces la información de algoritmo seleccionado se reenvía al CM (), que pide la información preliminar de trayecto al PCM (6). 4. El PCM selecciona un grafo de topología (TG1) particularizado a partir de la lista de grafos de topología (7) calculados previamente para cada algoritmo activo. Por ejemplo, un algoritmo puede tener un grafo por longitud de onda disponible en la red de transporte. Otro algoritmo puede tener aristas excluidas previamente del grafo si no se consideran adecuadas para las características de la petición solicitada (por ejemplo, alto retardo, coste, etc.). El peso de las aristas puede actualizarse en este grafo particular. Un grafo se define mediante un conjunto de enlaces y nodos con propiedades específicas (definidas por el diseñador del algoritmo) por enlace y nodo.. El grafo denominado TG1 y otra información preliminar de trayecto se reenvía hacia el CM (8) y basándose en la dupla (AL1, TG1) proporcionada y puede que en otra información preliminar de trayecto, calcula el trayecto más adecuado para lograr la CR1. Es notable que no necesariamente un AL1 se representa por sólo un TG1. Por ejemplo, el algoritmo AUR/exhaustivo (Ahmed Mokhtar y Murat Azizoglu, Adaptive Wavelength Routing in All-Optical Networks, IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 6, NO. 2, ABRIL DE 1998) hace uso de un grafo para cada lambda, por lo que habrá más de un grafo de topología por algoritmo. De este modo, el cálculo de trayecto en línea se lleva a cabo por el CM basándose en el algoritmo elegido y los grafos calculados previamente fuera de línea, y otra información preliminar de trayecto desde el PCM. 6. Finalmente, la respuesta del trayecto calculado se envía al despachador de respuestas (9), que la reenvía al módulo de sesión PCE-PCE apropiado (el correspondiente al PCE hijo que realizó la petición de cálculo CR1) con el fin de establecer el trayecto calculado. Tal como se explicó anteriormente, las TEDBS mantienen actualizado el PCM (3) (actualizando los estados de enlace, los estados de nodo...) y el gestor de algoritmos mantiene actualizado el selector de algoritmos (311) (cargando los algoritmos, activando y desactivando los algoritmos, actualizando las reglas de selección...). En resumen, las ventajas de la invención propuesta se centran y orientan para aumentar el rendimiento y utilidad de operador del H-PCE. 1\n16 El gestor de algoritmos proporciona al H-PCE una operación dinámica superior debido a su capacidad de activar y desactivar algoritmos a/del H-PCE sin volver a arrancarlo. Esto constituye una propiedad muy interesante, puesto que elimina el periodo de tiempo en el que un H-PCE permanece en un estado de no funcionamiento evitado que la red solicite nuevos trayectos en este estado. El gestor de algoritmos, por tanto, propone un nuevo enfoque de tiempo de ejecución que permite la inclusión, modificación y eliminación de algoritmo durante el proceso de ejecución del H-PCE. Otras ventajas extraídas de la inclusión del módulo de gestor de algoritmos están relacionadas con el control de la versión de sistema operativo del H-PCE. Sin este mecanismo de carga, cualquier modificación de algoritmo puede requerir cambios en el sistema operativo del H-PCE creando múltiples versiones. El contexto requerirá cambios altamente controlados para estar seguros de cuál será el comportamiento del H-PCE y sus algoritmos. Por otro lado, el gestor de algoritmos permite tener sólo un sistema operativo independientemente de los algoritmos cargados en el H-PCE y mostrar al operador cuáles y cómo se cargan, con el fin de predecir los resultados de cálculo del H-PCE. Las ventajas del selector de algoritmos se centran en una utilización y accesibilidad rápida de los algoritmos. Este conjunto permite la selección rápida del algoritmo ordenándolos de manera adecuada y enlazándolos con sus grafos correspondientes mediante la interfaz TDB-PCM. El módulo de cálculo aprovecha la flexibilidad del H-PCE: la disponibilidad de una infraestructura de múltiples algoritmos permite una mejor adaptación a la función objetivo deseada o a otras restricciones requeridas, al calcular el trayecto. El módulo de cálculo previo puede actualizarse cada vez que haya un cambio en las TEDB (9, 1, 111). Obsérvese que estas TEDB pueden actualizarse por dos medios, información IGP (por ejemplo, mensajes de OSPF) o por medio de mensajes de PCEP de notificación procesados por el procesador de notificaciones (116). Esto constituye una ventaja importante al proporcionar al CM un grafo de topología particularizado actualizado y otra información preliminar de trayecto asociada al algoritmo de cálculo elegido, puesto que los datos requeridos en cuanto al estado de los nodos de red o el estado de enlace de TE siempre se actualizan y notifican al PCM, que realiza todas las actualizaciones necesarias de métricas, parámetros y grafos. El sistema de múltiples TEDB es otra característica relevante incluida en las presentes realizaciones de la invención. Dependiendo de las políticas definidas entre dominios, el nivel de información disponible para calcular trayectos en el H-PCE puede variar. Con el fin de adaptarse a cada situación, se han definido tres bases de datos diferentes. Es obligatorio almacenar información interdominio en la base de datos multidominio. En caso de que se permitan mecanismos de abstracción o resumen para proporcionar también al H-PCE información intradominio adicional, será opcional almacenar esta información dentro de la VTEDB y/o la IDTEDB, de modo que puede mejorarse el proceso de cálculo de trayecto. En las reivindicaciones, la expresión que comprende no excluye otros elementos o etapas, y el artículo indefinido un o una no excluyen una pluralidad. Un único procesador u otra unidad puede cumplir las funciones de varios elementos enumerados en las reivindicaciones. El mero hecho de que determinadas medidas se enumeren en reivindicaciones dependientes diferentes entre sí no indica que una combinación de estas medidas no pueda usarse de manera ventajosa. Cualquier símbolo de referencia en las reivindicaciones no debe interpretarse como limitativo del alcance. La descripción y los dibujos ilustran meramente los principios de la invención. Se apreciará, por tanto, que los expertos en la técnica podrán concebir diversas disposiciones que, aunque no se describen o muestran de manera explícita en el presente documento, implementan los principios de la invención y se incluyen dentro de su alcance. Además, todos los ejemplos enumerados en el presente documento están previstos principalmente de manera expresa para que sean sólo con fines pedagógicos para ayudar al lector a entender los principios de la invención y los conceptos con los que el (los) inventor(es) contribuyen a promover la técnica, y deben interpretarse como sin limitación a tales ejemplos y condiciones enumerados específicamente. Además, todos los enunciados en el presente documento que enumeran principios, aspectos y realizaciones de la invención, así como ejemplos específicos de la misma, están previstos para abarcar equivalentes de los mismos. Aunque la presente invención se ha descrito con referencia a realizaciones específicas, los expertos en la técnica deben entender que los anteriores y otros diversos cambios, omisiones y adiciones en la forma y detalle de la misma pueden realizase en la misma sin apartarse del espíritu y alcance de la invención tal como se define por la siguientes reivindicaciones. 16\n17 REIVINDICACIONES Un procedimiento para calcular trayectos de encaminamiento a lo largo de múltiples dominios de una red de transporte de comunicación con una arquitectura de elementos de cálculo de trayecto jerárquicos, incluyendo la red al menos un elemento de cálculo de trayecto, PCE, asociado a cada dominio, denominado PCE de dominio, para calcular trayectos de red entre nodos pertenecientes al mismo dominio y al menos un PCE, denominado PCE padre, para calcular trayectos de red entre nodos pertenecientes a diferentes dominios de un grupo de dominios gestionados por dicho PCE padre, comprendiendo el procedimiento las siguientes etapas: a) cuando el PCE padre recibe información sobre un cambio en los nodos o enlaces de un determinado dominio perteneciente al grupo de dominios gestionados por dicho PCE, el PCE padre calcula información preliminar de trayecto según dichos cambios para cada uno de los algoritmos de cálculo de trayecto establecidos como activos en una lista de algoritmos de cálculo de trayecto disponibles, de modo que para cada algoritmo activo de dicha lista, el PCE padre calcula y almacena determinada información preliminar de trayecto; b) el PCE padre recibe, desde un PCE de dominio, una petición de cálculo de trayecto, incluyendo la petición de cálculo de trayecto información sobre el nodo de origen del trayecto, el nodo de destino del trayecto y al menos un requisito de rendimiento del trayecto; c) el PCE padre selecciona, de los algoritmos de cálculo de trayecto establecidos como activos en la lista, el algoritmo más adecuado según el al menos un requisito de rendimiento del trayecto; d) el PCE padre obtiene la información preliminar de trayecto para el algoritmo seleccionado; e) el PCE padre calcula el trayecto solicitado desde el nodo de origen del trayecto hasta el nodo de destino del trayecto, teniendo en cuenta al menos dicha información preliminar de trayecto, y aplicando el algoritmo de cálculo de trayecto seleccionado; f) el trayecto calculado se notifica al PCE de dominio que solicita el cálculo del trayecto en el que la información recibida por el PCE padre en la etapa a) incluye cualquier cambio en la información interdominio del determinado dominio, es decir, en la información sobre los nodos frontera de dicho dominio y sobre los enlaces entre nodos de dicho dominio y nodos de otros dominios y dicha información es enviada por un PCE de dominio asociado a dicho determinado dominio. 2. Un procedimiento según la reivindicación 1, en el que el PCE padre incluye una base de datos de ingeniería de tráfico, TEDB, denominada TEDB multidominio, que almacena toda la información interdominio recibida y en el que la información interdominio se actualiza en dicha base de datos cuando el PCE padre recibe información sobre un cambio en la información interdominio de un dominio perteneciente al grupo gestionado por el PCE padre. 3. El procedimiento según cualquiera de las reivindicaciones anteriores, en el que la información recibida por el PCE padre en la etapa a) incluye también cambios en la información intradominio del determinado dominio, es decir, en la información sobre los nodos pertenecientes al dominio y sobre los enlaces entre dichos nodos y dicha información es enviada por un PCE de dominio asociado al dominio. 4. El procedimiento según la reivindicación 3, en el que el PCE padre incluye una base de datos de ingeniería de tráfico, TEDB, denominada TEDB intradominio que almacena toda la información intradominio recibida y en el que la información intradominio se actualiza cuando el PCE padre recibe información sobre un cambio en la información intradominio de un dominio perteneciente al grupo gestionado por el PCE padre.. El procedimiento según cualquiera de las reivindicaciones anteriores, en el que la información recibida por el PCE padre en la etapa a) incluye también cambios en información intradominio virtual del determinado dominio, es decir, en información sobre los nodos virtuales pertenecientes al dominio y sobre los enlaces virtuales entre dichos nodos y dicha información de cambio intradominio virtual es enviada por un PCE de dominio asociado a dicho dominio. 6. El procedimiento según la reivindicación, en el que PCE padre incluye una base de datos de ingeniería de tráfico, TEDB, denominada TEDB intradominio virtual que almacena toda la información intradominio virtual recibida y en el que la información intradominio virtual se actualiza cuando el PCE padre recibe información sobre un cambio en la información intradominio virtual de un dominio perteneciente al grupo gestionado por el PCE padre. 7. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la etapa e) de cálculo del trayecto solicitado incluye: - calcular un conjunto de posibles trayectos entre el nodo de origen y el nodo de destino aplicando el algoritmo seleccionado y determinando qué partes de los posibles trayectos están entre nodos del mismo dominio; - para cada trayecto parcial entre nodos del mismo dominio, si el PCE padre tiene suficiente información para calcular el trayecto parcial, calcular dicho trayecto parcial de la parte y, si no: 17\n18 - enviar una petición de cálculo de trayecto para el trayecto parcial al PCE asociado al dominio al que pertenece el trayecto parcial - recibir desde el PCE el cálculo del trayecto parcial solicitado - teniendo en cuenta al menos dichos cálculos de trayecto parcial, la información preliminar de trayecto y el algoritmo seleccionado, calcular el trayecto solicitado entre el nodo de origen de trayecto y el nodo de destino de trayecto. 8. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la información preliminar de trayecto asociada a cada algoritmo de cálculo de trayecto activo pueden ser grafos de topología, cálculo de métricas, mediciones de parámetros o un conjunto de trayectos calculados previamente. 9. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el trayecto es un trayecto conmutado por etiquetas, LSB Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la petición de cálculo de trayecto se recibe en primer lugar por el PCE asociado al dominio al que pertenece el nodo de origen, y dicho PCE envía la petición de cálculo de trayecto al PCE padre tras comprobar que el nodo de destino no pertenece al mismo dominio que el nodo origen. 11. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que, antes de la etapa b), el PCE padre comprueba a qué dominios pertenecen el nodo origen del trayecto y el nodo destino del trayecto y en caso de que uno de ellos pertenezca a un dominio no gestionado por el PCE padre o en caso de que pertenezcan a dominios no conectados, se envía un mensaje sin_trayecto al PCE de dominio y el procedimiento termina. 12. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la información sobre un cambio en los nodos o enlaces es información sobre cambios de parámetros de ingeniería de tráfico y/o la adición de un nodo de red y/o la eliminación de un nodo de red y/o el cambio de características de un enlace y/o la adición de un enlace entre dos nodos de red y/o la eliminación de un enlace entre dos nodos de red. 13. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el operador de red puede enviar instrucciones al PCE padre para añadir nuevos algoritmos de cálculo de trayecto a la lista, eliminar algoritmos de cálculo de trayecto de la lista, establecer como activo un algoritmo de cálculo de trayecto en la lista o establecer como no activo un algoritmo de cálculo de trayecto y para establecer las reglas para seleccionar el algoritmo en la etapa c). 14. Un sistema para calcular trayectos de encaminamiento a lo largo de múltiples dominios de una red de transporte de comunicación con una arquitectura de elementos de cálculo de trayecto jerárquicos, incluyendo la red al menos un elemento de cálculo de trayecto, PCE, asociado a cada dominio, denominado PCE de dominio, para calcular trayectos de red entre nodos pertenecientes al mismo dominio, incluyendo el sistema al menos un PCE, denominado PCE padre, para calcular trayectos de red entre nodos de diferentes dominios de un grupo de dominios gestionados por dicho PCE padre, comprendiendo el PCE padre: a) medios para, cuando el PCE padre recibe información sobre un cambio en los nodos o enlaces de un determinado dominio perteneciente al grupo de dominios gestionados por dicho PCE, calcular información preliminar de trayecto según dichos cambios para cada uno de los algoritmos de cálculo de trayecto establecidos como activos en una lista de algoritmos de cálculo de trayecto disponibles, de modo que para cada algoritmo activo de dicha lista, el PCE padre calcula y almacena determinada información preliminar de trayecto, en el que la información recibida incluye información sobre cualquier cambio en la información interdominio del determinado dominio y dicha información es enviada por un PCE de dominio asociado a dicho determinado dominio; b) medios para recibir, desde un PCE de dominio, una petición de cálculo de trayecto, incluyendo la petición de cálculo de trayecto información sobre el nodo de origen del trayecto, el nodo de destino del trayecto y al menos un requisito de rendimiento de trayecto; c) medios para seleccionar, a partir de algoritmos de cálculo de trayecto activos de la lista, el algoritmo más adecuado según el requisito de rendimiento de trayecto; d) medios para obtener la información preliminar de trayecto para el algoritmo seleccionado; 6 e) medios para calcular el trayecto solicitado desde el nodo de origen del trayecto hasta el nodo de destino 18\n19 del trayecto, teniendo en cuenta al menos dicha información preliminar de trayecto y aplicando el algoritmo de cálculo de trayecto seleccionado. 1. Un programa informático que comprende medios de código de programa informático adaptados para realizar el procedimiento según cualquiera de las reivindicaciones 1 a 13 cuando dicho programa se ejecuta en un ordenador, un procesador de señal digital, una disposición de puertas programables en campo, un circuito integrado de aplicación específica, un microprocesador, un microcontrolador o cualquier otra forma de hardware programable. 19


Saturno Visto Desde Un Telescopio - Top 3 modelos bajo el microscopio.\nSaturno Visto Desde Un Telescopio recomendacion - La mejor Saturno Visto Desde Un Telescopio comparada.\nLo que usted, como comprador, debe prestar atención al comprar los Saturno Visto Desde Un Telescopio.\nAdemás, nuestro equipo de probador también ha escrito una pequeña lista de verificación para la compra - para que pueda elegir entre todos los Saturno Visto Desde Un Telescopio el Telescopio Un Desde Visto Saturno los se ajuste al 100 por ciento a su persona!.\n¿Cuál es tu intención con los Saturno Visto Desde Un Telescopio\nCómo es el precio alto los Saturno Visto Desde Un Telescopio\n¿Por qué quieres ganar el Saturno Visto Desde Un Telescopio\n¿los Saturno Visto Desde Un Telescopio el nivel de calidad que puede esperar como comprador en esta categoría de precio?\nCómo los Saturno Visto Desde Un Telescopio más probable\nSaturno Visto Desde Un Telescopio - Elija nuestro ganador de la prueba.\nComo operador del sitio, le damos la bienvenida en casa a nuestra prueba. Nuestros editores nos han hecho posible comprobar las variantes de productos de todo tipo para que los consumidores puedan adquirir el Saturno Visto Desde Un Telescopio de un vistazo el usted es ideal. Con el fin de permanecer lo más neutral posible, una amplia gama de criterios de prueba se incorporan a nuestras comparaciones de productos. Para obtener más información relacionada con este tema, consulte la subpágina creada especialmente, que se vinculó en el menú.\nLa cantidad de apuesta de elección en nuestro ranking es definitivamente muy extensa. Dado que, por supuesto, cada consumidor tiene expectativas individuales de la inversión, probablemente no el 100% de nuestros visitantes están incondicionalmente de acuerdo con nuestro resultado. Como probadores honestos, somos incondicionales que nuestro ranking se organiza de acuerdo con la relación precio-rendimiento en la clasificación adecuada. Con el objetivo de que usted como comprador esté completamente satisfecho con los Saturno Visto Desde Un Telescopio después de la compra, también hemos seleccionado los productos malos de antemano y no los hemos incluido en la lista en absoluto. Como cliente, solo puede ver la lista de productos que han cumplido con nuestros criterios de comparación definidos. .