ES A2 ESPAÑA 11. Número de publicación: Número de solicitud: H04L 12/00 ( )

Tamaño: px
Comenzar la demostración a partir de la página:

Download "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"

Transcripción

1 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

2 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

3 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 - 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

19 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

20

ES 2 427 488 R1 ESPAÑA 11. Número de publicación: 2 427 488. Número de solicitud: 201230634 H04L 12/54 (2013.01) 27.04.2012

ES 2 427 488 R1 ESPAÑA 11. Número de publicación: 2 427 488. Número de solicitud: 201230634 H04L 12/54 (2013.01) 27.04.2012 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 21 Número de publicación: 2 427 488 Número de solicitud: 201230634 51 Int. CI.: H04L 12/54 (2013.01) 12 INFORME SOBRE EL ESTADO DE LA TÉCNICA R1 22 Fecha

Más detalles

51 Int. CI.: H04L 12/721 (2013.01) H04L 12/725 (2013.01) H04L 12/723 (2013.01) H04L 12/927 (2013.01) TRADUCCIÓN DE PATENTE EUROPEA

51 Int. CI.: H04L 12/721 (2013.01) H04L 12/725 (2013.01) H04L 12/723 (2013.01) H04L 12/927 (2013.01) TRADUCCIÓN DE PATENTE EUROPEA 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 43 921 1 Int. CI.: H04L 12/721 (13.01) H04L 12/72 (13.01) H04L 12/723 (13.01) H04L 12/927 (13.01) 12 TRADUCCIÓN DE PATENTE EUROPEA

Más detalles

Int. Cl.: 72 Inventor/es: Li, Wanghuawei. 74 Agente: Lehmann Novo, María Isabel

Int. Cl.: 72 Inventor/es: Li, Wanghuawei. 74 Agente: Lehmann Novo, María Isabel 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 39 24 1 Int. Cl.: H04B / (06.01) H04L 12/6 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea: 08084.9

Más detalles

ES 2 411 755 B1. Aviso: ESPAÑA 11. Número de publicación: 2 411 755. Número de solicitud: 201130632 H04L 12/723 (2013.01) 19.04.

ES 2 411 755 B1. Aviso: ESPAÑA 11. Número de publicación: 2 411 755. Número de solicitud: 201130632 H04L 12/723 (2013.01) 19.04. 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 21 Número de publicación: 2 411 7 Número de solicitud: 201130632 1 Int. CI.: H04L 12/72 (2013.01) H04L 12/723 (2013.01) 12 PATENTE DE INVENCIÓN B1 22

Más detalles

PROYECTO FIN DE CARRERA

PROYECTO FIN DE CARRERA UNIVERSIDAD AUTÓNOMA DE MADRID ESCUELA POLITÉCNICA SUPERIOR PROYECTO FIN DE CARRERA Implementación y comparación de soluciones basadas en Path Computation Element (PCE) para entornos multi-dominio Diego

Más detalles

11 Número de publicación: 2 267 850. 51 Int. Cl.: 74 Agente: Curell Suñol, Marcelino

11 Número de publicación: 2 267 850. 51 Int. Cl.: 74 Agente: Curell Suñol, Marcelino 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 267 850 51 Int. Cl.: H04L 12/56 (2006.01) H04L 29/14 (2006.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea:

Más detalles

11 Número de publicación: 2 238 639. 51 Int. Cl. 7 : H04L 12/56. 72 Inventor/es: Couturier, Alban. 74 Agente: Díez de Rivera y Elzaburu, Ignacio

11 Número de publicación: 2 238 639. 51 Int. Cl. 7 : H04L 12/56. 72 Inventor/es: Couturier, Alban. 74 Agente: Díez de Rivera y Elzaburu, Ignacio 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 238 639 1 Int. Cl. 7 : H04L 12/6 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 02803829.7 86 Fecha de presentación:

Más detalles

Protocolos de enrutamiento dinamico RIP, OSPF, BGP

Protocolos de enrutamiento dinamico RIP, OSPF, BGP BGP dinamico,, BGP Facultad de Ciencias Matemáticas - UNMSM EAP. Computación Científica 23 de octubre de 2012 BGP Introduccion Un protocolo de es un software complejo que se ejecuta de manera simultánea

Más detalles

Lab. 7 MultiProtocol Label Switching (MPLS)

Lab. 7 MultiProtocol Label Switching (MPLS) Lab. 7 MultiProtocol Label Switching (MPLS) 7.1 Objetivos de la practica El objetivo de la presente práctica es familiarizarse con la tecnología y los conceptos de MPLS (Multiprotocol Label Switching),

Más detalles

Diseño y configuración de redes IP

Diseño y configuración de redes IP Contenido Tema 8 Diseño y configuración de redes IP Protocolos de encaminamiento Características Sistemas autónomos IGP: RIP y OSPF EGP: BGP Segunda parte 1 Ampliación interconexión de redes: Conmutadores

Más detalles

MPLS. Jhon Jairo Padilla A., PhD.

MPLS. Jhon Jairo Padilla A., PhD. MPLS Jhon Jairo Padilla A., PhD. Introducción MPLS: Multi-Protocol Label Switching Ha surgido como una importante tecnología para transportar paquetes IP (redes WAN) Antecesores: IP Switch, Tag Switching,

Más detalles

11 Número de publicación: 2 214 165. 51 Int. Cl. 7 : H04L 12/58. 72 Inventor/es: Degraeve, Michel. 74 Agente: Curell Suñol, Marcelino

11 Número de publicación: 2 214 165. 51 Int. Cl. 7 : H04L 12/58. 72 Inventor/es: Degraeve, Michel. 74 Agente: Curell Suñol, Marcelino 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 214 16 1 Int. Cl. 7 : H04L 12/8 H04Q 7/22 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 0187007. 86 Fecha

Más detalles

Ingeniería de tráfico Introducción. Jhon Jairo Padilla Aguilar, PhD.

Ingeniería de tráfico Introducción. Jhon Jairo Padilla Aguilar, PhD. Ingeniería de tráfico Introducción Jhon Jairo Padilla Aguilar, PhD. Definición Ingeniería de Tráfico: Es el aspecto de la ingeniería de redes IP que hace frente al problema de optimización de rendimiento

Más detalles

Fibra Óptica Actualidad y futuro de las redes ópticas

Fibra Óptica Actualidad y futuro de las redes ópticas Fibra Óptica Actualidad y futuro de las redes ópticas Francisco Ramos Pascual. Doctor Ingeniero de Telecomunicación. Profesor Titular de Escuela Universitaria. Universidad Politécnica de Valencia Si bien

Más detalles

2.2 Conmutación de circuitos ópticos (OCS)

2.2 Conmutación de circuitos ópticos (OCS) Evaluación de Arquitecturas de Red Híbridas OBS/OCS 23 2.2 Conmutación de circuitos ópticos (OCS) 2.2.1 Redes dinámicas de conmutación de circuitos ópticos Como se ha visto en el apartado 2.1.2 la conmutación

Más detalles

PROYECTO DE TESIS TEMA: DISEÑO DE RED LAN UTILIZANDO EL PROTOCOLO MPLS PARA LA TRANSMISIÓN DE VOZ, VIDEO Y DATOS DE LA EPIS UNA PUNO 2011.

PROYECTO DE TESIS TEMA: DISEÑO DE RED LAN UTILIZANDO EL PROTOCOLO MPLS PARA LA TRANSMISIÓN DE VOZ, VIDEO Y DATOS DE LA EPIS UNA PUNO 2011. FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA ELECTRÓNICA Y SISTEMAS ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS PROYECTO DE TESIS TEMA: DISEÑO DE RED LAN UTILIZANDO EL PROTOCOLO MPLS PARA LA TRANSMISIÓN

Más detalles

51 Int. CI.: H04L 12/24 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA. 96 Número de solicitud europea: 08866694.6. Fecha de presentación: 12.12.

51 Int. CI.: H04L 12/24 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA. 96 Número de solicitud europea: 08866694.6. Fecha de presentación: 12.12. 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 374 96 1 Int. CI.: H04L 12/24 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA 96 Número de solicitud europea: 08866694.6 96 Fecha de

Más detalles

11 Número de publicación: 2 293 257. 51 Int. Cl.: 74 Agente: Ponti Sales, Adelaida

11 Número de publicación: 2 293 257. 51 Int. Cl.: 74 Agente: Ponti Sales, Adelaida 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 293 27 1 Int. Cl.: H04L 29/06 (06.01) H04L 29/12 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea:

Más detalles

Int. Cl.: 74 Agente: Carvajal y Urquijo, Isabel

Int. Cl.: 74 Agente: Carvajal y Urquijo, Isabel 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 328 623 1 Int. Cl.: H04L 29/08 (06.01) H04L 29/06 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea:

Más detalles

Redes LAN y WAN UNIDAD. Redes WAN. Routing. Clase 3 Clase 4 Clase 5 Clase 6

Redes LAN y WAN UNIDAD. Redes WAN. Routing. Clase 3 Clase 4 Clase 5 Clase 6 Redes LAN y WAN UNIDAD 5 Redes WAN. Routing Clase 3 Clase 4 Clase 5 Clase 6 Exposición 2.11. Routing La determinación de la ruta óptima para alcanzar un destino requiere un conocimiento profundo por parte

Más detalles

SWITCH ETHERNET CAPA 2. Justo Ramírez Martínez

SWITCH ETHERNET CAPA 2. Justo Ramírez Martínez SWITCH ETHERNET CAPA 2 Justo Ramírez Martínez ÍNDICE (I) Introducción Ethernet Bridging and Switching Dispositivos de conexión de redes Tipos de dispositivos Dispositivos de conexión de nivel 2 Puentes

Más detalles

11 Número de publicación: 2 291 327. 51 Int. Cl.: 72 Inventor/es: Rodin, Gunnar. 74 Agente: Torner Lasalle, Elisabet

11 Número de publicación: 2 291 327. 51 Int. Cl.: 72 Inventor/es: Rodin, Gunnar. 74 Agente: Torner Lasalle, Elisabet 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 291 327 1 Int. Cl.: H04L 12/64 (2006.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 01947002.0 86 Fecha

Más detalles

Facultad de Ingeniería Redes y Comunicaciones Tercer Parcial Parte Teórica 25%

Facultad de Ingeniería Redes y Comunicaciones Tercer Parcial Parte Teórica 25% NOMBRE: En cada una de las siguientes preguntas de selección múltiple usted podrá seleccionar una o varias respuestas. En el caso de las preguntas que tienen múltiples opciones como respuestas, SOLO será

Más detalles

REDES DE COMPUTADORES Laboratorio

REDES DE COMPUTADORES Laboratorio 1nsloo.cl REDES DE COMPUTADORES Laboratorio Práctica 3: Protocolos de enrutamiento dinámico RIP y OSPF 1. OBJETIVO El objetivo de esta práctica es conocer el modo de operar de los protocolos de enrutamiento

Más detalles

Tecnologías de agregación y núcleo de red

Tecnologías de agregación y núcleo de red Tecnologías de agregación y núcleo de red 0 Situación actual del plano de datos Las tecnologías más comunes son IP/MPLS, Ethernet y NG- SDH, pero aún hay una importante presencia de tecnologías como FR

Más detalles

Basada en Network Brokers

Basada en Network Brokers Provisión Incremental de QoS Basada en Network Brokers Alfonso Gazo Cervero, José Luis González Sánchez [agazo,jlgs]@unex.es Área de Ingeniería Telemática Departamento de Informática Universidad de Extremadura

Más detalles

TRABAJO COLABORATIVO N. 2 LUISA FERNANDA HERNANDEZ BERMUDEZ ROBERT JOSE HERNANDEZ GONZALES VICTOR MANUEL COVANS ACOSTA JHON ALEXANDER MARTÍNEZ MONTAÑA

TRABAJO COLABORATIVO N. 2 LUISA FERNANDA HERNANDEZ BERMUDEZ ROBERT JOSE HERNANDEZ GONZALES VICTOR MANUEL COVANS ACOSTA JHON ALEXANDER MARTÍNEZ MONTAÑA ESCUELA DE CIENCIAS BASICAS TECNOLOGIA E INGENIERIA REDES Y SISTEMAS AVANZADOS DE TELECOMUNICACIONES 2 GRUPO: 208004_5 Actividad 10 TRABAJO COLABORATIVO N. 2 LUISA FERNANDA HERNANDEZ BERMUDEZ ROBERT JOSE

Más detalles

Int. Cl.: 72 Inventor/es: Haumont, Serge y Hurtta, Tuija. 74 Agente: Curell Suñol, Marcelino

Int. Cl.: 72 Inventor/es: Haumont, Serge y Hurtta, Tuija. 74 Agente: Curell Suñol, Marcelino 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 263 6 1 Int. Cl.: H04Q 7/38 (06.01) H04Q 7/24 (06.01) H04Q 7/32 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud

Más detalles

Última modificación: 1 de mayo de 2010. www.coimbraweb.com

Última modificación: 1 de mayo de 2010. www.coimbraweb.com RED DE TRANSPORTE MPLS Contenido 1.- Origen de MPLS. 2.- Concepto de MPLS. 3.- Componentes de una red MPLS. 4.- Conmutación IP de MPLS. 5.- Aplicaciones de MPLS. Última modificación: ió 1 de mayo de 2010

Más detalles

11 Número de publicación: 2 264 980. 51 Int. Cl.: 74 Agente: Elzaburu Márquez, Alberto

11 Número de publicación: 2 264 980. 51 Int. Cl.: 74 Agente: Elzaburu Márquez, Alberto 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 264 980 1 Int. Cl.: H04L 29/06 (06.01) H04L 12/64 (06.01) H04L 12/66 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de

Más detalles

11 Número de publicación: 2 290 327. 51 Int. Cl.: 74 Agente: Elzaburu Márquez, Alberto

11 Número de publicación: 2 290 327. 51 Int. Cl.: 74 Agente: Elzaburu Márquez, Alberto 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 290 327 1 Int. Cl.: H04L 12/6 (06.01) H04L 29/06 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea:

Más detalles

1. PARAMETROS DE CALIDAD DE SERVICIO. -PERDIDAS DE PAQUETES EN LOS ROUTERS: Vía TCP son recuperables, pero las retransmisiones TCP son

1. PARAMETROS DE CALIDAD DE SERVICIO. -PERDIDAS DE PAQUETES EN LOS ROUTERS: Vía TCP son recuperables, pero las retransmisiones TCP son TEMA 6: APLICACIONES MULTIMEDIA EN TIEMPO REAL Internet es una red de computadoras TCP/IP que basa su funcionamiento en la tecnología de conmutación de paquetes mediante un servicio no orientado a conexión.

Más detalles

Int. Cl.: 74 Agente: Fàbrega Sabaté, Xavier

Int. Cl.: 74 Agente: Fàbrega Sabaté, Xavier 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 38 811 1 Int. Cl.: H04L 29/12 (06.01) H04L 12/26 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea:

Más detalles

Carácterísticas del enrutamiento dinámico en Internet Tema 4.- Enrutamiento con IP

Carácterísticas del enrutamiento dinámico en Internet Tema 4.- Enrutamiento con IP Clase 2 Carácterísticas del enrutamiento dinámico en Internet Tema 4.- Enrutamiento con IP Dr. Daniel Morató Redes de Ordenadores Ingeniero Técnico de Telecomunicación Especialidad en Sonido e Imagen,

Más detalles

MPLS vs. Ruteo IP Convencional

MPLS vs. Ruteo IP Convencional MPLS vs. Ruteo IP Convencional Javier Aldo Balladini Rodolfo del Castillo {jballadi,rolo}@uncoma.edu.ar Departamento de Ciencias de la Computación FaEA - Universidad Nacional del Comahue Buenos Aires 400

Más detalles

11 Número de publicación: 2 236 471. 51 Int. Cl. 7 : H04L 29/06

11 Número de publicación: 2 236 471. 51 Int. Cl. 7 : H04L 29/06 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 236 471 1 Int. Cl. 7 : H04L 29/06 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 023161.0 86 Fecha de presentación:

Más detalles

11 Número de publicación: 2 263 981. 51 Int. Cl.: 74 Agente: Durán Moya, Carlos

11 Número de publicación: 2 263 981. 51 Int. Cl.: 74 Agente: Durán Moya, Carlos 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 263 981 1 Int. Cl.: H04L 12/14 (06.01) H04L 29/06 (06.01) H04M /00 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud

Más detalles

Int. Cl.: 74 Agente: Elzaburu Márquez, Alberto

Int. Cl.: 74 Agente: Elzaburu Márquez, Alberto 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 325 378 51 Int. Cl.: H04L 29/06 (2006.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea: 05754544.4 96 Fecha

Más detalles

Redes de comunicación

Redes de comunicación Redes de comunicación Conmutación de circuitos Conmutación de paquetes Dpt. Arquitectura de Computadores 1 Redes conmutadas Conmutación (nodos) de los datos que se reciben de una estación emisora hasta

Más detalles

MECANISMOS DE PROTECCIÓN Y RESTAURACIÓN

MECANISMOS DE PROTECCIÓN Y RESTAURACIÓN MECANISMOS DE PROTECCIÓN Y RESTAURACIÓN Sistemas de Telecomunicación Alumnos: Pablo Núñez López Alberto Garzón Leo INDICE 1. Índice 2. Introducción y objetivos Definiciones Mecanismos de protección y restauración

Más detalles

Concentradores de cableado

Concentradores de cableado Concentradores de cableado Un concentrador es un dispositivo que actúa como punto de conexión central entre los nodos que componen una red. Los equipos conectados al propio concentrador son miembros de

Más detalles

WAN y Enrutamiento WAN

WAN y Enrutamiento WAN WAN y Enrutamiento WAN El asunto clave que separa a las tecnologías WAN de las LAN es la capacidad de crecimiento, no tanto la distancia entre computadoras Para crecer, la WAN consta de dispositivos electrónicos

Más detalles

Enrutamiento Básico Talleres para ISP/IXP

Enrutamiento Básico Talleres para ISP/IXP Enrutamiento Básico Talleres para ISP/IXP 1 Conceptos de Enrutamineto IPv4 Enrutamiento Reenvío Algunas Definiciones Opciones de políticas Protocolos de Enrutamiento 2 IPv4 Internet utiliza IPv4 Direcciones

Más detalles

11 Número de publicación: 2 321 774. 21 Número de solicitud: 200600040. 51 Int. Cl.: 74 Agente: Urízar Anasagasti, Jesús María

11 Número de publicación: 2 321 774. 21 Número de solicitud: 200600040. 51 Int. Cl.: 74 Agente: Urízar Anasagasti, Jesús María 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 321 774 21 Número de solicitud: 200600040 51 Int. Cl.: H04W 88/00 (2009.01) G08B 23/00 (2006.01) 12 SOLICITUD DE PATENTE A1 22

Más detalles

Departamento de Servicios Grupo STG. Programa de Cursos Generales

Departamento de Servicios Grupo STG. Programa de Cursos Generales Departamento de Servicios Grupo STG Programa de Cursos Generales Introducción STG pone a su disposición su Centro de Capacitaciones equipado con el mobiliario e infraestructura tecnológica necesaria para

Más detalles

ROUTERS MÓDULO 2 PARTE 1

ROUTERS MÓDULO 2 PARTE 1 ROUTERS MÓDULO 2 PARTE 1 Interconexión de Redes Bibliografía: Tanenbaum Andrew - Computer Networks 4ta Edición Perlman Radia - Interconnections Bridges and Routers 2da Edición Cisco Networking Academy

Más detalles

Problemas de Redes Ingeniería Informática Hoja de problemas 3

Problemas de Redes Ingeniería Informática Hoja de problemas 3 Problemas de Redes Ingeniería Informática Hoja de problemas B igura : Red para el problema. y siguientes Problema:. Use el algoritmo de Bellman-ord para generar la ruta de menor coste a todos los nodos

Más detalles

Introducción Internet no tiene una estructura real, pero existen varios backbone principales. Estos se construyen a partir de líneas y routers de alta velocidad. Conectados a los backbone hay redes regionales

Más detalles

01/10/2010. 15. Conjunto de protocolos TCP/IP IP. Contenido. Enrutamiento Intradomain y enrutamiento Interdomain routing

01/10/2010. 15. Conjunto de protocolos TCP/IP IP. Contenido. Enrutamiento Intradomain y enrutamiento Interdomain routing 15. Conjunto de protocolos TCP/IP IP Contenido i. Programación de enrutadores Enrutamiento Intradomain y enrutamiento Interdomain routing El enrutamiendo dentro de un sistema autónomo (AS) es referido

Más detalles

Enrutamiento. Emilio Hernández. Carlos Figueira

Enrutamiento. Emilio Hernández. Carlos Figueira Enrutamiento Emilio Hernández Carlos Figueira Introducción Una vez más: cuál es la diferencia entre enrutamiento y reenvío? (routing( vs forwarding) Por qué no podemos configurar las tablas en los enrutadores

Más detalles

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones. Módulo Profesional: Servicios en Red. Código: 0227. Resultados de aprendizaje y criterios de evaluación. 1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

Más detalles

11 Número de publicación: 2 223 053. 51 Int. Cl. 7 : H04Q 3/00. 72 Inventor/es: Suominen, Antti-Jussi. 74 Agente: Carvajal y Urquijo, Isabel

11 Número de publicación: 2 223 053. 51 Int. Cl. 7 : H04Q 3/00. 72 Inventor/es: Suominen, Antti-Jussi. 74 Agente: Carvajal y Urquijo, Isabel 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 223 03 1 Int. Cl. 7 : H04Q 3/00 H04M 3/42 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 9932790.9 86 Fecha

Más detalles

Departamento de Servicios Grupo STG. Programa de Cursos Generales

Departamento de Servicios Grupo STG. Programa de Cursos Generales Departamento de Servicios Grupo STG Programa de Cursos Generales 2 Introducción STG pone a su disposición su Centro de Capacitaciones equipado con el mobiliario e infraestructura tecnológica necesaria

Más detalles

Materia: Telefonía UNEFA 2013 Semestre 11. Prof. Ing. Eduardo Gutierrez. 1

Materia: Telefonía UNEFA 2013 Semestre 11. Prof. Ing. Eduardo Gutierrez. 1 Spanning tree (Spanning Tree Protocol) (SmmTPr o STP) es un protocolo de red de nivel 2 de la capa OSI (nivel de enlace de datos). Está basado en un algoritmo diseñado por Radia Perlman mientras trabajaba

Más detalles

Framework para el desarrollo del encaminamiento interdominio con QoS basado en PCE sobre MPLS

Framework para el desarrollo del encaminamiento interdominio con QoS basado en PCE sobre MPLS Framework para el desarrollo del encaminamiento interdominio con QoS basado en PCE sobre MPLS UNIVERSIDAD DE EXTREMADURA GÍTACA Grupo de investigación de Ingeniería Telemática Aplicada y Comunicaciones

Más detalles

51 Int. CI.: G06F 17/30 (2006.01) H04L 29/08 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA

51 Int. CI.: G06F 17/30 (2006.01) H04L 29/08 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 00 140 1 Int. CI.: G06F 17/30 (06.01) H04L 29/08 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Fecha de presentación y número

Más detalles

REPORTE PRÁCTICA ROUTEADOR ALUMNA: BRIZEIDA DEL CARMEN LEDEZMA OLIVAS N CONTROL: 10040342 MAESTRO: M.C.C. JOSE RAMON VALDEZ GUTIERREZ

REPORTE PRÁCTICA ROUTEADOR ALUMNA: BRIZEIDA DEL CARMEN LEDEZMA OLIVAS N CONTROL: 10040342 MAESTRO: M.C.C. JOSE RAMON VALDEZ GUTIERREZ REPORTE PRÁCTICA ROUTEADOR ALUMNA: BRIZEIDA DEL CARMEN LEDEZMA OLIVAS N CONTROL: 10040342 MAESTRO: M.C.C. JOSE RAMON VALDEZ GUTIERREZ OCTUBRE DEL 2012 Tabla de Contenido Tabla de Contenido... 2 Índice

Más detalles

CCNA EXPLORATION CONCEPTOS Y PROTOCOLOS

CCNA EXPLORATION CONCEPTOS Y PROTOCOLOS CCNA EXPLORATION CONCEPTOS Y PROTOCOLOS DE ENRUTAMIENTO COMPARACIÓN DEL NUEVO PROGRAMA DE ESTUDIOS CON EL PROGRAMA ACTUAL Preparada por Cisco Learning Institute 25 de junio, 2007 Resumen de conceptos y

Más detalles

51 Int. CI.: H04L 12/58 (2006.01) H04M 3/537 (2006.01) H04M 3/533 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA. 72 Inventor/es: 74 Agente/Representante:

51 Int. CI.: H04L 12/58 (2006.01) H04M 3/537 (2006.01) H04M 3/533 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA. 72 Inventor/es: 74 Agente/Representante: 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 488 496 1 Int. CI.: H04L 12/8 (06.01) H04M 3/37 (06.01) H04M 3/33 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Fecha de presentación

Más detalles

51 Int. CI.: G06Q 30/02 (2012.01) G06Q 30/06 (2012.01) TRADUCCIÓN DE PATENTE EUROPEA

51 Int. CI.: G06Q 30/02 (2012.01) G06Q 30/06 (2012.01) TRADUCCIÓN DE PATENTE EUROPEA 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 499 399 1 Int. CI.: G06Q /02 (12.01) G06Q /06 (12.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Fecha de presentación y número de

Más detalles

MultiProtocol Label Switching:MPLS

MultiProtocol Label Switching:MPLS IP de calidad MultiProtocol Label Switching:MPLS Juan Blázquez Martín j.blazquez@danysoft.com El axioma biológico de que la necesidad crea el órgano no es principio que se pueda aplicar totalmente a Internet.

Más detalles

PUERTO DE SALINA CRUZ OAXACA, 16 DE MARZO DEL 2015.

PUERTO DE SALINA CRUZ OAXACA, 16 DE MARZO DEL 2015. INSTITUTO TECNOLÓGICO DE SALINA CRUZ ACTIVIDAD: TRABAJO DE INVESTIGACION SOBRE ENRUTAMIENTO ESTATICO Y DINAMICO. DOCENTE: M.C. SUSANA MÓNICA ROMÁN NÁJERA. MATERIA: REDES DE COMPUTADORAS. NOMBRE DEL ALUMNO:

Más detalles

MX250 Características Técnicas del Sistema MX 250 de Zultys Technologies.

MX250 Características Técnicas del Sistema MX 250 de Zultys Technologies. MX250 Características Técnicas del Sistema MX 250 de Zultys Technologies. Total funcionalidad como Central Telefónica con correo de voz integrado Basado en estándares abiertos: SIP, Linux, Voice XML, TAPI,

Más detalles

ANEXO IV Pliego Técnico. 1. Introducción 2. 2. Topología de la Red Local y Configuración actual de la electrónica 2

ANEXO IV Pliego Técnico. 1. Introducción 2. 2. Topología de la Red Local y Configuración actual de la electrónica 2 Organización Mundial del Turismo Invitación a la Licitación IT/ICT/2011-02 Madrid, 5 de junio de 2011 ANEXO IV Pliego Técnico Tabla de Contenido 1. Introducción 2 2. Topología de la Red Local y Configuración

Más detalles

DISEÑO DE UN ESCENARIO PARA LA REALIZACIÓN DE PRÁCTICAS DE REDES DE CONMUTACIÓN DE ETIQUETAS MULTIPROTOCOLO (MPLS)

DISEÑO DE UN ESCENARIO PARA LA REALIZACIÓN DE PRÁCTICAS DE REDES DE CONMUTACIÓN DE ETIQUETAS MULTIPROTOCOLO (MPLS) DISEÑO DE UN ESCENARIO PARA LA REALIZACIÓN DE PRÁCTICAS DE REDES DE CONMUTACIÓN DE ETIQUETAS MULTIPROTOCOLO (MPLS) R. DE DIEGO 1, A.B. GARCIA 1, C. RAMOS 1, A. REDONDO 1, M. PUÑALES 2 Y J.F. MARTÍNEZ 1

Más detalles

Departamento de Enxeñería Telemática Sistemas de Conmutación MPLS p.2

Departamento de Enxeñería Telemática Sistemas de Conmutación MPLS p.2 Índice 1. Objetivos de MPLS 2. Principios básicos de funcionamiento 3. Distribución de etiquetas: a) LDP (Label Distribution Protocol) b) RSVP (Resource reservation Protocol): Ingeniería de tráfico c)

Más detalles

CCNA 2 Conceptos y Protocolos de Enrutamiento

CCNA 2 Conceptos y Protocolos de Enrutamiento CCNA 2 Conceptos y Protocolos de Enrutamiento 1 Objetivos Desarrollar un conocimiento sobre la manera en que un router aprende sobre las redes remotas Como un router determina la mejor ruta hacia dichas

Más detalles

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC299_2 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Tema 4 Redes de Área Amplia

Tema 4 Redes de Área Amplia Tema 4 Redes de Área Amplia Índice - Introducción - Conmutación de circuitos - Conmutación de paquetes - Comparación de técnicas de conmutación - Encaminamiento - Control de congestión - Las WAN y el modelo

Más detalles

Int. Cl.: 72 Inventor/es: Zhang, Ke. 74 Agente: Lehmann Novo, María Isabel

Int. Cl.: 72 Inventor/es: Zhang, Ke. 74 Agente: Lehmann Novo, María Isabel 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 36 877 1 Int. Cl.: H04L 12/28 (2006.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea: 0781693.9 96 Fecha

Más detalles

11 Número de publicación: 2 206 022. 21 Número de solicitud: 200200919. 51 Int. Cl. 7 : H04L 29/08. 74 Agente: Carpintero López, Francisco

11 Número de publicación: 2 206 022. 21 Número de solicitud: 200200919. 51 Int. Cl. 7 : H04L 29/08. 74 Agente: Carpintero López, Francisco 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 206 022 21 Número de solicitud: 200200919 51 Int. Cl. 7 : H04L 29/08 12 PATENTE DE INVENCIÓN B1 22 Fecha de presentación: 19.04.2002

Más detalles

CAPITULO II PROTOCOLOS, ARQUITECTURA DE REDES Y MODELO OSI/ISO.

CAPITULO II PROTOCOLOS, ARQUITECTURA DE REDES Y MODELO OSI/ISO. CAPITULO II PROTOCOLOS, ARQUITECTURA DE REDES Y MODELO OSI/ISO. Competencias a desarrollar: Conocer la importancia de la estandarización en redes de datos. Identificar los estándares. Saber los tipos de

Más detalles

Capítulo 4: Capa Red - IV

Capítulo 4: Capa Red - IV Capítulo 4: Capa Red - IV ELO322: Redes de Computadores Agustín J. González Este material está basado en: Material de apoyo al texto Computer Networking: A Top Down Approach Featuring the Internet 3rd

Más detalles

Ampliación de Data Centers con Cisco Fabric Path

Ampliación de Data Centers con Cisco Fabric Path Informe técnico Ampliación de Data Centers con Cisco Fabric Path Qué aprenderá Las arquitecturas de redes tradicionales están diseñadas con el fin de ofrecer alta disponibilidad para las aplicaciones estáticas,

Más detalles

11 Número de publicación: 2 244 099. 51 Int. Cl. 7 : H04M 3/50. 74 Agente: Curell Suñol, Marcelino

11 Número de publicación: 2 244 099. 51 Int. Cl. 7 : H04M 3/50. 74 Agente: Curell Suñol, Marcelino 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 244 099 1 Int. Cl. 7 : H04M 3/0 12 TRADUCCIÓN DE PATENTE EUROPEA T3 86 Número de solicitud europea: 9898342.2 86 Fecha de presentación

Más detalles

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES

5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES SISTEMAS DISTRIBUIDOS DE REDES 5. MODELOS DE CLIENTE Y SERVIDOR ORIENTADOS A AGENTES MÓVILES Programación remota: Introducción y generalidades INTRODUCCIÓN Debido a la dificultad de la arquitectura actual

Más detalles

51 Int. CI.: H04L 29/06 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA. Título: Pasarela residencial y procedimiento de configuración de tal pasarela

51 Int. CI.: H04L 29/06 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA. Título: Pasarela residencial y procedimiento de configuración de tal pasarela 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 432 396 1 Int. CI.: H04L 29/06 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Fecha de presentación y número de la solicitud

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

51 Int. CI.: G06F 17/30 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA

51 Int. CI.: G06F 17/30 (2006.01) TRADUCCIÓN DE PATENTE EUROPEA 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 460 021 1 Int. CI.: G06F 17/ (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Fecha de presentación y número de la solicitud europea:

Más detalles

Router Teldat. Policy-Based Routing

Router Teldat. Policy-Based Routing Router Teldat Policy-Based Routing Doc. DM745 Abril, 2007 ÍNDICE Capítulo 1 Tecnología Policy-Based Routing...1 1. Introducción... 2 2. Ventajas del Policy-Based Routing... 3 3. Envío de datos en Policy-Based

Más detalles

2º CURSO INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN TEMA 5 ENTRADA/SALIDA. JOSÉ GARCÍA RODRÍGUEZ JOSÉ ANTONIO SERRA PÉREZ Tema 5.

2º CURSO INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN TEMA 5 ENTRADA/SALIDA. JOSÉ GARCÍA RODRÍGUEZ JOSÉ ANTONIO SERRA PÉREZ Tema 5. ARQUITECTURAS DE COMPUTADORES 2º CURSO INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN TEMA 5 ENTRADA/SALIDA JOSÉ GARCÍA RODRÍGUEZ JOSÉ ANTONIO SERRA PÉREZ Tema 5. Unidad de E/S 1 Unidad de E/S Indice Introducción.

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

Más detalles

Práctica 3: Capa de Red Ruteo

Práctica 3: Capa de Red Ruteo 75.43 Introducción a los Sistemas Distribuidos Práctica 3: Capa de Red Ruteo Resumen En esta práctica ejercitamos los conceptos de subnetting desarrollados en la práctica anterior y comenzamos el estudio

Más detalles

Configuración del Cierre del Puerto Remoto

Configuración del Cierre del Puerto Remoto Descargue este capítulo Descargue el libro completo Guía de configuración de Ethernet del portador, Cisco IOS Release 12.2SR (PDF - 3 MB) Feedback Contenido Circuito Virtual Ethernet Última actualización:

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

RECOMENDACIÓN UIT-R F.1104. (Cuestión UIT-R 125/9) a) que el UIT-T ha realizado estudios y elaborado Recomendaciones sobre la RDSI;

RECOMENDACIÓN UIT-R F.1104. (Cuestión UIT-R 125/9) a) que el UIT-T ha realizado estudios y elaborado Recomendaciones sobre la RDSI; Rec. UIT-R F.1104 1 RECOMENDACIÓN UIT-R F.1104 REQUISITOS PARA LOS SISTEMAS PUNTO A MULTIPUNTO UTILIZADOS EN LA PARTE DE «GRADO LOCAL» DE UNA CONEXIÓN RDSI (Cuestión UIT-R 125/9) Rec. UIT-R F.1104 (1994)

Más detalles

Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas. Capa de Red. Mérida - Venezuela Prof. Gilberto Díaz

Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas. Capa de Red. Mérida - Venezuela Prof. Gilberto Díaz Universisdad de Los Andes Facultad de Ingeniería Escuela de Sistemas Capa de Red Mérida - Venezuela Prof. Gilberto Díaz Capa de Red Gestión de tráfico entre redes Direcciones IP Las direcciones de red

Más detalles

11 Número de publicación: 2 307 647. 51 Int. Cl.: 74 Agente: Carpintero López, Mario

11 Número de publicación: 2 307 647. 51 Int. Cl.: 74 Agente: Carpintero López, Mario 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 7 647 1 Int. Cl.: H04Q 7/24 (06.01) H04L 12/64 (06.01) H04M 7/00 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud

Más detalles

TRANSMISION DE DATOS Intercambio de datos (en forma de ceros y unos) entre dos dispositivos a través de un medio de Tx.

TRANSMISION DE DATOS Intercambio de datos (en forma de ceros y unos) entre dos dispositivos a través de un medio de Tx. ASIGNATURA: REDES DE COMPUTADORE I Lectura 1. TEMAS: REPASO FUNDAMENTOS DE LAS COMUNICACIONES Transmisión de datos Estándares y organizaciones de normalización. FUNDAMENTOS DE LA INTERCONECTIVAD DE REDES.

Más detalles

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 6. Actualización

CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL. Nivel 2. Versión 6. Actualización Página 1 de 17 CUALIFICACIÓN OPERACIÓN DE REDES DEPARTAMENTALES PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC299_2 Versión 6 Situación Contraste externo Actualización

Más detalles

Factura Electrónica. Un proyecto de facturación electrónica que integra empresas y administraciones

Factura Electrónica. Un proyecto de facturación electrónica que integra empresas y administraciones Factura Electrónica. Un proyecto de facturación electrónica que integra empresas y administraciones Resumen de la Comunicación El proyecto de Facturación electrónica forma parte de los planes del Gobierno

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

ACADEMIA LOCAL CISCO UCV-MARACAY CONTENIDO DE CURSO CURRICULUM CCNA. EXPLORATION V4.0 SEMESTRE II. CONCEPTOS Y PROTOCOLOS DE ENRUTAMIENTO

ACADEMIA LOCAL CISCO UCV-MARACAY CONTENIDO DE CURSO CURRICULUM CCNA. EXPLORATION V4.0 SEMESTRE II. CONCEPTOS Y PROTOCOLOS DE ENRUTAMIENTO ACADEMIA LOCAL CISCO UCV-MARACAY CONTENIDO DE CURSO CURRICULUM CCNA. EXPLORATION V4.0 SEMESTRE II. CONCEPTOS Y PROTOCOLOS DE ENRUTAMIENTO Módulo 1: Introducción al enrutamiento y envío de paquetes 1.1

Más detalles

ESPECIFICACIONES DEL SISTEMA DE SEÑALIZACION. POR CANAL COMUN No.7 PARA LA RED DE COSTA RICA PARTE DE TRANSFERENCIA DE MENSAJES

ESPECIFICACIONES DEL SISTEMA DE SEÑALIZACION. POR CANAL COMUN No.7 PARA LA RED DE COSTA RICA PARTE DE TRANSFERENCIA DE MENSAJES ESPECIFICACIONES DEL SISTEMA DE SEÑALIZACION POR CANAL COMUN No.7 PARA LA RED DE COSTA RICA PARTE DE TRANSFERENCIA DE MENSAJES Y PARTE DE USUARIO DE RDSI SAN JOSE, ABRIL DE 1999 2º Edición Especificaciones

Más detalles

Módulo 2 Comunicación

Módulo 2 Comunicación Sistemas Distribuidos Módulo 2 Comunicación Facultad de Ingeniería Departamento de Informática Universidad Nacional de la Patagonia San Juan Bosco Comunicación en Sistemas Distribuidos Modelos de Comunicaciones

Más detalles

Conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre sí, a través de un medio en particular.

Conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre sí, a través de un medio en particular. Que es una red? Conjunto de computadores, equipos de comunicaciones y otros dispositivos que se pueden comunicar entre sí, a través de un medio en particular. Cuantos tipos de redes hay? Red de área personal,

Más detalles

Encaminamiento en Internet 4. BGP

Encaminamiento en Internet 4. BGP Encaminamiento en Internet 4. BGP Redes I Departamento de Sistemas Telemáticos y Computación (GSyC) Octubre de 2010 GSyC - 2010 Encaminamiento en Internet: 4. BGP 1 c 2010 Grupo de Sistemas y Comunicaciones.

Más detalles

PROTOCOLOS DE ENRUTAMIENTO

PROTOCOLOS DE ENRUTAMIENTO PROTOCOLOS DE ENRUTAMIENTO Los protocolos de enrutamiento son el conjunto de reglas utilizadas por un router cuando se comunica con otros router con el fin de compartir información de enrutamiento. Dicha

Más detalles

ES 2 410 366 A2 ESPAÑA 11. Número de publicación: 2 410 366. Número de solicitud: 201130974 H04L 12/46 (2006.01) 10.06.2011

ES 2 410 366 A2 ESPAÑA 11. Número de publicación: 2 410 366. Número de solicitud: 201130974 H04L 12/46 (2006.01) 10.06.2011 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 21 Número de publicación: 2 4 366 Número de solicitud: 11974 1 Int. CI.: H04L 12/46 (06.01) 12 SOLICITUD DE PATENTE A2 22 Fecha de presentación:.06.11

Más detalles