ES2665571T3 - Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red - Google Patents

Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red Download PDF

Info

Publication number
ES2665571T3
ES2665571T3 ES12729798.4T ES12729798T ES2665571T3 ES 2665571 T3 ES2665571 T3 ES 2665571T3 ES 12729798 T ES12729798 T ES 12729798T ES 2665571 T3 ES2665571 T3 ES 2665571T3
Authority
ES
Spain
Prior art keywords
network
gateway
cscg
destination
ncg
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12729798.4T
Other languages
English (en)
Inventor
Young Lee
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2665571T3 publication Critical patent/ES2665571T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services

Landscapes

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

Abstract

Un sistema que comprende: una pasarela de control de servicio de la denominada nube informática, CSCG (314, 414), situada en un estrato de aplicación (310, 410), y una pasarela de control de red, NCG (324, 422), situada en un estrato de red (320, 420), en donde la pasarela CSCG (314, 414) está configurada para acoplarse a la pasarela NCG (324, 422), y en donde la pasarela CSCG (314, 414) está configurada para transmitir una dirección de origen, una lista de direcciones de destino y una primera necesidad de recursos de red a la pasarela NCG (324, 422), en donde la pasarela CSCG (314, 414) está configurada además para recibir un mapa de recursos de red desde la pasarela NCG (324, 422), donde el mapa de recursos de red comprende un valor de recursos de red de una ruta de red entre la dirección de origen y una dirección de destino contenida en la lista de direcciones de destino, en donde la pasarela CSCG (314, 414) está configurada además para obtener datos de recursos de aplicación desde una pluralidad de servidores, correspondientes a la lista de direcciones de destino, y en donde la pasarela CSCG (314, 414) está configurada además para seleccionar un servidor de destino para una demanda de aplicación basada en un análisis de los datos de recursos de aplicación y el mapa de recursos de red, mediante lo cual la demanda de aplicación es una demanda para la migración de datos desde la dirección de origen a uno de la pluralidad de servidores y; en donde la lista de direcciones de destino comprende potenciales servidores de destino; en donde si un primer valor de recursos de red de una ruta de red entre una dirección de origen y una dirección de destino satisface la primera necesidad de recursos de red, en ese caso el mapa de recursos de red comprende la dirección de destino correspondiente al servidor de destino seleccionado por la pasarela CSCG; en donde los datos de recursos de aplicación comprenden la utilización de una memoria de acceso aleatorio, RAM, consumo de energía, utilización de unidad central de procesamiento, CPU, de la pluralidad de servidores (312); en donde la pasarela NCG (324, 422) está configurada para recibir una comunicación de la pasarela CSCG (314, 414) que comprende la dirección de origen, la lista de direcciones de destino, que comprende una pluralidad de direcciones de destino, y una necesidad de recursos de red, en donde la pasarela NCG (324, 422) está configurada además para transmitir una demanda de cálculo de ruta a un elemento de cálculo de ruta, PCE, situado en el estrato de red (320, 420), y en donde la demanda de cálculo de ruta comprende la dirección de origen y la pluralidad de direcciones de destino, en donde la pasarela NCG (324, 422) está configurada además para recibir una respuesta de cálculo de ruta desde el elemento PCE, en donde la respuesta de cálculo de ruta comprende una pluralidad de rutas de red, en donde cada ruta de red está entre la dirección de origen y cada una de las direcciones de destino, y en donde la respuesta de cálculo de ruta comprende además un valor de recursos de red para cada ruta de red o un valor de recursos para cada enlace de una topología de la red.

Description

Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red
ANTECEDENTES DE LA INVENCIÓN 5
Los operadores de redes, también a veces referidos como operadores de telecomunicaciones o proveedores de servicios de comunicaciones, que explotan las redes existentes, desean optimizar la utilización de la red para transmitir tráfico, tal como tráfico de Protocolo Internet (IP), a través de la parte física de la red, p.ej., a través de las capas 1 a 5 de red. El tráfico optimizado puede incluir el tráfico para servicios de reproducción triples (p.ej., Vídeo, 10 Voz y/o Datos) y cualquier tipo de datos masivos. En las redes existentes, los servicios de extremo a extremo se suelen establecer por sistemas del tipo Sistemas de Soportes Operativos (OSS) o aplicaciones del servicio de gestión de específicas del proveedor. Los operadores de redes han recomendado dos diferentes escenarios operativos para optimizar la utilización de red el tráfico: optimización de los servicios de redes existentes y permitir nuevos/emergentes servicios de aplicaciones de redes. 15
El documento US 7636764 publicado con fecha da a conocer un método para seleccionar un nodo de red en una nube informática para el almacenamiento de datos.
SUMARIO DE LA INVENCIÓN 20
El alcance de la invención se define por las reivindicaciones adjuntas. La invención se refiere a un sistema según la reivindicación 1.
BREVE DESCRIPCIÓN DE LOS DIBUJOS 25
Para un entendimiento más completo de esta idea inventiva, se hace referencia, a continuación, a la siguiente breve descripción, tomada en relación con los dibujos adjuntos y una descripción detallada, en donde las referencias numéricas similares representan elementos similares
La Figura 1 es un diagrama esquemático de una forma de realización de una arquitectura de Optimización de Estrato Cruzado (CSO).
La Figura 2 es un diagrama esquemático de otra forma de realización de una arquitectura de CSO.
La Figura 3 es un diagrama esquemático de otra forma de realización de una arquitectura CSO.
La Figura 4 es un diagrama esquemático de otra forma de realización de una arquitectura CSO.
La Figura 5 es un diagrama esquemático de otra forma de realización de una arquitectura CSO. 40
La Figura 6 es un diagrama esquemático de una forma de realización de un mapa de topología de red, a modo de ejemplo.
La Figura 7 ilustra una forma de realización de un protocolo de demanda de recursos de pasarela CSCG. 45
La Figura 8 ilustra una forma de realización de un protocolo de reserva de pasarela CSCG.
La Figura 9 es un diagrama de flujo de una forma de realización de un método de demanda de recursos de una pasarela CSCG. 50
La Figura 10 es un diagrama de flujo de una forma de realización de un método de demanda de reserva de una pasarela CSCG.
La Figura 11 es un diagrama esquemático de una forma de realización de una unidad de red. 55
La Figura 12 es un diagrama esquemático de una forma de realización de un sistema informático de uso general.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN
Debe entenderse, desde el principio, que aunque una puesta en práctica ilustrativa de una o más formas de realización se proporcionan a continuación, los sistemas y/o métodos dados a conocer pueden ponerse en práctica utilizando cualquier número de técnicas, sean actualmente conocidas o en existencia. La idea inventiva no debe limitase, en forma alguna, a las puestas en práctica ilustrativas, dibujos y técnicas ilustradas a continuación, incluyendo los diseños a modo de ejemplo y las puestas en práctica ilustradas y aquí descritas, sino que pueden 65 modificarse dentro del alcance de las reivindicaciones adjuntas.
El aprovisionamiento y la operación de aplicaciones nuevas/emergentes, tales como la infraestructura de servicio de la denominada nube informática pueden implicar el aprovisionamiento de recursos de procesamiento y/o espacio de memorización sobre múltiples componentes de red (p.ej., servidores). Sobre la base de las necesidades cambiantes de un usuario, los recursos/datos pueden ser objeto de migración entre servidores. La red puede dividirse en un 5 estrato de aplicación y un estrato de red. El estrato de aplicación puede incluir las aplicaciones y servicios puestos en práctica o utilizados a través de la capa de red, y el estrato de red puede incluir el transporte, la red, el enlace y las capas físicas o sus combinaciones. Los servicios que operan en el estrato de aplicación pueden estar constituidos por recursos de servidores disponibles, pero no pueden referirse a recursos y topología de la red. Los servicios que operan en el estrato de red pueden tratarse de recursos y topología de la red, pero no como recursos 10 de servidores. Los servicios que operan en uno u otro estrato pueden ser incapaces de seleccionar un servidor de destino óptimo para la migración de datos/recursos debido a la carencia de información completa, dando lugar a un problema en la selección del servidor (SS). Habida cuenta de la separación estricta entre los estratos, el aprovisionamiento del servicio de manipulación y coordinación tanto en el estrato de aplicación como en el estrato de red es diferente de los servicios tradicionales de manipulación, tales como aprovisionamiento de red de servicios 15 de telecomunicaciones del tipo extremo a extremo.
La idea inventiva consiste en un sistema y método para proporcionar una Optimización de Estrato Cruzado (CSO) para el problema de servicio de servidor SS. Una Pasarela de Control de Servicio de Nube Informática (CSCG) en el estrato de aplicación puede mantener datos de recursos de aplicaciones para varios servidores, que pueden estar 20 situados en varios centros de datos (DCs). Los datos de recursos de aplicaciones pueden comprender la utilización de una memoria de acceso aleatorio (RAM) de un servidor, consumo de energía, utilización de unidad central de procesamiento (CPU), etc. Un origen puede demandar que la pasarela CSCG realice una migración de datos. La pasarela CSCG puede utilizar los datos de recursos de aplicaciones para generar una lista de servidores que pueden ser destinos adecuados para la migración de datos. La pasarela CSCG puede transmitir la lista de destinos 25 a una pasarela de control de red (NCG) en el estrato de red por intermedio de una interfaz de estrato cruzado. La pasarela CSCG puede transmitir también una o más necesidades de recursos de red a la pasarela NCG para su uso en una optimización adicional. Los requisitos de recursos de red pueden comprender: latencia máxima, ancho de banda mínimo/máximo, etc. La pasarela NCG puede utilizar componentes de red, tales como un elemento de cálculo de ruta (PCE), para calcular rutas de red óptimas entre el origen y cada destino así como datos de recursos de red 30 asociados para cada ruta. La pasarela NCG puede filtrar destinos con rutas o enlaces de rutas con datos de recursos de red que no satisfacen las necesidades de recursos de red desde la pasarela CSCG. La pasarela NCG puede enviar un mapa de recursos de red de destinos a la pasarela CSCG junto con datos de recursos de red de ruta asociados para el servidor SS. Además, el mapa de recursos de red puede incluir todos los enlaces en cada ruta y los datos de recursos de red para cada ruta, cada enlace de cada ruta o la topología de red completa. La 35 pasarela CSCG puede utilizar la información procedente de la pasarela NCG para seleccionar un servidor y/o gestionar la migración de datos desde el origen al servidor seleccionado. En otra forma de realización, la pasarela NCG puede recibir la información procedente de la pasarela CSCG, determinar la ruta óptima, reservar la ruta e informar a la pasarela CSCG de la ruta reservada. La pasarela CSCG puede utilizar la información para gestionar la migración de datos al servidor seleccionado por NGW. 40
Algunos de los términos aquí utilizados y descritos a continuación con respecto a las características de CSO incluyen: recursos de aplicación, servicios de aplicación, pasarela CSCG, recursos de red, una pasarela NCG, un estrato de red y estrato de aplicación. Los recursos de aplicaciones pueden comprender recursos no de red que pueden ser críticos para conseguir la funcionalidad del servicio de aplicación. A modo de ejemplo, los recursos de 45 aplicaciones pueden incluir recursos de cálculo informático y recursos de contenidos tales como memorias caché, espejos, servidores específicos de aplicaciones, máquinas virtuales, memoria, espacio de disco, grandes conjuntos de datos, datos de vídeo, datos de audio, bases de datos y/o otras aplicaciones relacionadas con los recursos. El servicio de aplicación puede ser cualquier aplicación conectada en red ofrecida a una diversidad de clientes. La pasarela CSCG puede ser una entidad de CSO en el estrato de aplicación que es responsable de reunir la carga de 50 recursos de aplicaciones y su utilización, tomar decisiones respecto a la asignación de recursos e interaccionar con la pasarela NCG. La pasarela CSCG puede implantarse en práctica en un procesador de un elemento de red tal como un servidor o una entidad de control de red. La pasarela CSCG puede situarse en un centro de datos y puede ponerse en práctica, o no, en el mismo servidor que una pasarela NCG. Los recursos de red pueden comprender recursos de cualquier capa 3 o capa inferior, tal como ancho de banda, enlaces, rutas, procesamiento de rutas (p.ej., 55 creación, supresión y gestión), bases de datos de redes, cálculo de ruta y los protocolos de enrutamiento y señalización para crear rutas. La pasarela NCG puede ser una entidad de CSO en el estrato de red que es responsable de interaccionar con la pasarela CSCG, iniciar la función de demanda de servicio para la entidad de red de transporte responsable para las funciones de aprovisionamiento, configuración, estimación/cálculo de ruta y otras funciones de gestión/control de redes. La pasarela NCG puede ponerse en práctica en un procesador de un 60 elemento de red tal como un servidor o una entidad de control de red. El estrato de red puede comprender componentes y/o funciones que operan en o bajo la capa de red en el modelo de Interconexión de Sistemas Abiertos (OSI) de siete capas, tal como una función de Conmutación de Niveles Multiprotocolo (MPLS), Jerarquía Digital Síncrona (SDH), Red de Transporte Óptico (OTN), Multiplexación por División de Longitud de Onda (WDM). El estrato de aplicación puede comprender componentes y/o funciones que operan en o por encima de la capa de 65 transporte de modelo OSI de siete capas.
La Figura 1 es un diagrama esquemático de una forma de realización de una arquitectura de CSO 100. La arquitectura de CSO 100 puede comprender un estrato de aplicación 110 y un estrato de red 120. El estrato de red 110 puede comprender una pluralidad de servidores 112, que pueden configurarse para poner en práctica o ejecutar aplicaciones para usuarios finales o clientes (no ilustrados). El estrato de red 120 puede comprender una pluralidad 5 de nodos de red 122, tales como puentes, enrutadores y/o conmutadores, para reenviar datos, p.ej., paquetes asociados con las aplicaciones. Los servidores 112 pueden estar situados en un centro de datos y los nodos de redes 122 pueden estar situados en una red acoplada al centro de datos. Los servidores 112 pueden comunicarse con los nodos de red 122 para permitir el servicio a las aplicaciones de usuarios y el reenvío o transporte de los datos asociados. La arquitectura de CSO 100 puede ponerse en práctica para optimizar las diferentes operaciones 10 de los servidores 112 y los nodos de red 122.
En una forma de realización, los centros de datos utilizados para proporcionar servicios de aplicaciones, tales como cálculo de nube informática y otros servicios de la nube informática, en el estrato de aplicación 110 para los usuarios finales pueden distribuirse geográficamente alrededor del estrato de red 120. De este modo, numerosas decisiones 15 tomadas en el control y gestión de servicios de aplicaciones, tales como dónde instanciar otra instancia de servicio o a qué centro de datos se asigna un nuevo cliente, pueden tener un impacto importante sobre el estado operativo de la red. Las capacidades y el estado de la red pueden tener también un impacto sobre el rendimiento de las aplicaciones.
Actualmente, las decisiones de aplicaciones pueden tomarse con poca o ninguna información respecto a la red subyacente utilizada para prestar dichos servicios. Por consiguiente, dichas decisiones pueden ser sub-óptimas desde la utilización de recursos de redes y aplicaciones y desde el logro de los objetivos de Calidad de Servicio (QoS). Una arquitectura de CSO, tal como la arquitectura de CSO 100 puede proporcionar un método y un sistema para coordinar la asignación de recursos entre el estrato de aplicación 110 y el estrato de red 120, p.ej., en el 25 contexto de cálculo de la nube informática y redes de centro de datos. A modo de ejemplo, la arquitectura de CSO 100 puede soportar la demanda de un estrato de red 110 respecto a aplicación, aprovisionamiento conjunto entre aplicación y red y/o reasignación conjunta de recursos sobre anomalía operativa en la aplicación y la red a la vez. La arquitectura de CSO 100 puede proporcionar también una red orientada a la aplicación y una aplicación orientada a la red y una capacidad de equilibrio de carga global. 30
Algunos de los objetivos para optimizar las operaciones y/o interacciones entre el estrato de aplicación 110 y el estrato de red 120, p.ej., entre los servidores 112 y los nodos de red 122, pueden incluir la mejora de las capacidades de red, topología, aprovisionamiento, control de utilización, control de anomalías o sus combinaciones. A modo de ejemplo, la arquitectura de CSO 100 puede mejorar el intercambio de capacidades de redes o demanda 35 de aplicación/información de recursos, topología y/o información relacionada con la denominada ingeniería de tráfico entre las capas (virtualización/abstracción) o ambas funciones a la vez. La arquitectura de CSO 100 puede mejorar también la iniciación de la instanciación del servicio de aplicación para la red con intercambio de perfiles (aprovisionamiento), intercambio de información de aplicación/congestión de la red/fallos (supervisión) o ambas a la vez. 40
La Figura 2 es un diagrama esquemático de otra forma de realización de una arquitectura de CSO 200. La arquitectura de CSO 200 puede comprender un estrato de aplicación 210 y un estrato de red 220. El estrato de aplicación 210 puede comprender una pluralidad de servidores 212 y el estrato de red 220 puede comprender una pluralidad de nodos de red 222, que pueden ser prácticamente similares a los servidores 112 y los nodos de red 45 122, respectivamente. La arquitectura de CSO 200 puede comprender, además, una interfaz de CSO que permite interacciones y/o comunicaciones entre los servidores 212 y/o otros componentes (no ilustrados) del estrato de aplicación 210 y los nodos de red 222 y/o otros componentes (no ilustrados) del estrato de red 220. La interfaz de CSO puede ser una interfaz abierta entre los dos estratos y puede permitir algunas de las características de CSO descritas a continuación. En el estrato de aplicación 210, la interfaz abierta puede permitir la identificación de 50 cliente/consumidor de algún tipo, p.ej., dirección de Protocolo Internet (IP), tipos de servidores e identificación, flujos de datos de aplicaciones y requisitos de calidad de servicio (QoS) que pueden ser estadísticos por naturaleza y variar en el transcurso del tiempo y/o condiciones de carga y fallos operativos de servidores. En el estrato de red 220, la interfaz abierta puede permitir el intercambio de topología de red, localizaciones de clientes y servidores dentro de esa topología, capacidades de red y capacidades con respecto a la calidad de servicio QoS, ancho de 55 banda, información de latencia y/o otras características relacionadas con la red, condiciones de carga y fallos operativos de la red o sus combinaciones.
La Figura 3 es un diagrama esquemático de otra forma de realización de una arquitectura de CSO 300. La arquitectura de CSO 300 puede comprender un estrato de aplicación 310 y un estrato de red 320. El estrato de 60 aplicación 310 puede comprender una pluralidad de servidores 312 y el estrato de red 320 puede comprender una pluralidad de nodos de red 322, que pueden ser prácticamente similares a los servidores 112 y los nodos de red 122, respectivamente. La arquitectura de CSO 300 puede comprender, además, un interfaz de CSO que puede establecerse entre una pasarela CSCG 314 en el estrato de aplicación 310 y una pasarela NCG 324 en el estrato de red 320. 65
La pasarela CSCG 314 puede configurarse para acceder a procesos y datos relacionados con aplicaciones (en el estrato de aplicación 310), comunicarse con la pasarela NCG 324 (por intermedio de la interfaz de CSO) y proporcionar abstracción/virtualización informativas y limitaciones de acceso a entidades externas (fueras del estrato de aplicación 310) incluyendo las entidades del estrato de red 320. La pasarela NCG 324 puede configurarse para acceder a datos relacionados con la red (en el estrato de red 320), comunicarse con la pasarela CSCG 314 (por 5 intermedio de la interfaz CSO), comunicarse con los procesos de redes tales como control de admisión, reserva de recursos y/o procesamiento de conexiones y proporcionar abstracción/virtualización informativa y limitaciones de acceso a entidades externas (fuera del estrato de red 320) incluyendo las entidades del estrato de aplicación 310. Además, la pasarela CSCG 314 y la pasarela NCG 324 pueden comunicarse con los servidores 312 y los nodos de red 322, respectivamente. 10
La Figura 4 es un diagrama esquemático de otra forma de realización de una arquitectura de CSO 400. La arquitectura de CSO 400 puede comprender un plano de usuario 401, un estrato de aplicación 410 y un estrato de red 420. El estrato de aplicación 410 puede comprender un plano de aplicación 412 (p.ej., en un centro de datos (DC)), y una pasarela CSCG 414, que puede comunicarse con el plano de aplicación 412 por intermedio de una 15 interfaz de plano de aplicación (API). La pasarela CSCG 414 en el estrato de aplicación 410 puede comunicarse también con el plano del usuario 401 por intermedio de una interfaz de aplicación-usuario (UAI). El estrato de red 420 puede comprender un plano de servicio 440, un plano de gestión 450, un plano de control 460 y un plano de transporte 470. El plano de transporte 470 puede soportar la tecnología de transporte de la infraestructura de red correspondiente, tal como para Perfil de Transporte-Conmutación Etiquetas Multiprotocolo (MPLS-TP), Red de 20 Transporte Óptico (ONT) o Red Óptica Conmutada de Longitud de Onda (WSON).
El plano de servicio 440 puede configurarse para permitir las comunicaciones entre el plano de aplicación 412 en el estrato de aplicación 410 y el plano de gestión 450, el plano de control 460, y el plano de transporte 470 en el estrato de red 420, p.ej., en una manera optimizada basada en CSO. El plano de servicio 440 puede comunicarse con el 25 plano de aplicación 412 por intermedio de una interfaz de aplicación-servicio (ASI), el plano de gestión 450 por intermedio de una interfaz de plano de gestión-servicio (SMI) y el plano de control 460 por intermedio de una interfaz de plano de control-servicio (SCI). El plano de transporte 470 puede comunicarse con el plano de gestión 450 y el plano de control 460 y de este modo, el plano de servicio 440 por intermedio de una interfaz de control de conexión (CCI). 30
El plano de servicio 440 puede proporcionarse por una parte o entidad (p.ej., un proveedor) que puede ser independiente del plano del usuario 401, el estrato de aplicación 410 y el estrato de red 420. A modo de ejemplo, el estrato de aplicación 410 y el estrato de red 420 pueden gestionarse por diferentes entidades o proveedores, y el plano de servicio 440 puede gestionarse por una tercera parte. El plano de servicio 440 puede comprender una 35 pasarela NCG 422, y una pluralidad de bases de datos de servicio de red 424, que pueden comprender una Base de Datos de Ingeniería de Tráfico (TED), una Base de Datos (DB) de Enrutamiento de Red (NR), una base de datos Config DB, una Tabla de Enrutamiento Múltiple (MRT), una Base de Información de Gestión (MIB y/o otras bases de datos de conexiones de redes. Las bases de datos de servicio de redes 424 pueden comprender al menos alguna información que puede copiarse a partir de bases de datos similares en los planos de red. La pasarela NCG 422 40 puede comunicarse con la pasarela CSCG 414, y de este modo, el plano de aplicación 412, por intermedio de ASI, el plano de gestión 450 por intermedio de la interfaz SMI y el plano de control 460 por intermedio de la interfaz SCI. La pasarela NCG 422 puede acceder también a la información en las bases de datos de servicio de red 424 cuando sea necesario para permitir el flujo de tráfico y comunicaciones entre los diferentes planos y estratos. Formas de realización adicionales de las arquitecturas de CSO pueden incluirse en la publicación de patente de Estados Unidos 45 2012/0054346 por Y. Lee et al, titulada “Método y Sistema para Optimización de Estratos Cruzados en Redes de Transporte-Aplicaciones”, que se incorpora aquí por referencia.
La Figura 5 ilustra otra forma de realización de una arquitectura de CSO 500. La arquitectura de CSO 500 puede comprender prácticamente los mismos componentes que las arquitecturas de CSO 100-400 en una configuración 50 diferente. La arquitectura de CSO 500 puede comprender una pasarela CSCG 514 en comunicación con servidores 511-513 y la pasarela NCG 524. La pasarela NCG 524 puede estar en comunicación con PCE 530 y un elemento de red (NE) 540. La pasarela CSCG 514 y los servidores 511-513 pueden situarse en el estrato de aplicación y la pasarela NCG 524, el elemento PCE 530 y el elemento NE 540 puede situarse en el estrato de red.
La pasarela CSCG 514 puede obtener datos de recursos de aplicaciones a partir de los servidores 511-513 sobre una base periódica y/o sobre una base según se necesite, y puede mantener dichos datos de recursos de aplicaciones localmente para uso en el servidor SS. La pasarela CSCG 514 puede comunicarse con los servidores 511-513 utilizando el Protocolo de Transferencia de Hipertexto (HTTP). La pasarela CSCG 514 puede enviar demás de estimación y/o reserva de ruta a la pasarela NCG 524 utilizando el protocolo de Optimización de Tráfico de Capa 60 de Aplicación (ALTO) según se establece en el documento de Internet Engineering Task Force (IETF) draft-ietf-ALTO-protocol-11, que se incorpora aquí por referencia. La pasarela NCG 524 puede realizar, a su vez, demandas de cálculo de ruta de PCE 530 utilizando el protocolo de comunicaciones PCE (PCEP), según se describe en el documento de IETF Demanda de Comentario (RFC) 5440, que se incorpora aquí por referencia. Las RFCs 5088 y 5089, que se incorporan aquí ambas por referencia, describen cómo descubrir un PCE adecuado desde la 65 perspectiva de la pasarela NCG 524 específica. El PCE 530 puede proporcionar rutas candidatos que cumplan las
limitaciones de recursos de redes específicas tal como conectividad (p.ej., punto a punto P-P), punto a multipunto (P-MP), etc.) y algunos parámetros de QoS (p.ej., latencia) así como requisitos de ancho de banda para la conectividad. Las rutas calculadas por el PCE 530 pueden ser una estimación de las rutas desde la aplicación basadas en el más reciente enlace de red y datos de tráfico de nodos, que pueden memorizarse por el PCE 530 en una Base de Datos de Ingeniería de Tráfico (TED). El PCE 530 puede responder con las rutas candidatos y datos de recursos de red 5 relacionados. Una vez que se hayan encontrado las rutas, entonces la pasarela NCG 524 puede responder con las rutas resultantes y los datos de recursos de red a la pasarela CSCG 514. Dichas rutas pueden enviarse a la pasarela CSCG 514 en el formato de origen-destino o como una lista de enlaces de ruta. Si la aplicación requiere una reserva de ancho de banda de una ruta calculada, en tal caso, la pasarela NCG 522 puede proseguir, además, con el proceso de aprovisionamiento de rutas bien sea mediante un proceso de configuración de gestión de red, bien 10 sea mediante una funcionalidad del plano de control. El proceso de aprovisionamiento puede iniciarse mediante la comunicación con el NE 540. NE 540 puede ser un conmutador virtual, un enrutador de red, un controlador del plano de control o entidad similar.
Dependiendo de la forma de realización, la pasarela CSCG 514 puede seleccionar y transmitir cualquiera o la 15 totalidad de las direcciones de servidores 511-513 y cualesquiera restricciones de recursos de redes deseadas a la pasarela NCG 524 para el cálculo de rutas y la pasarela NCG 524 puede responder con rutas que cumplan los requisitos de la pasarela CSCG 514, permitiendo a la pasarela CSCG 514 realizar SS. Como alternativa, la pasarela CSCG 514 puede transmitir algunos o la totalidad de los datos de recursos de aplicaciones conocidos para la pasarela CSCG 514, junto con necesidades de recursos de aplicaciones y/o redes, hacia la pasarela NCG 524, lo 20 que permite a NCG 524 realizar SS e informar a la pasarela CSCG 514 de los resultados obtenidos.
La Figura 6 es un diagrama esquemático de una forma de realización de un mapa de topología de red, a modo de ejemplo 600. El mapa de topología de red 600 se presenta simplemente para proporcionar datos ejemplo para uso en el método descrito a continuación. El mapa de topología de red 600 puede comprender un Origen 601 conectado 25 al Destino 621-623 por intermedio de los elementos de red NEs 610-613. Las conexiones entre los componentes del mapa de topología de red 600 pueden ser enlaces de red. El origen 601 puede comprender un servidor y puede requerir una migración de datos a un servidor en los Destinos 621-623. El origen 601 puede conectarse al elemento de red NE 610. El elemento NE 610 puede conectarse a NE 611-613. NE 613 puede conectarse a NE 610-612 y los destinos 622-623, NE 612 puede conectarse a los destinos 621-622. 30
La Figura 7 ilustra una forma de realización de un protocolo de demanda de pasarela CSCG 700. Una pasarela CSGC puede demandar 701 datos de recursos de aplicación a partir de una pluralidad de servidores en el estrato de aplicación. Cada servidor puede responder 702 con los datos de recursos de aplicación locales del servidor. Los datos de recursos de aplicación pueden comprender la utilización de memoria RAM del servidor, consumo de 35 energía, utilización de CPU, etc. La demanda-respuesta 701-702 puede realizarse utilizando funciones de adquisición/registro de HTTP. La pasarela CSGC puede memorizar los datos de recursos de aplicación para su uso posterior. En un momento posterior, un origen (p.ej., Origen 601) puede enviar una demanda de migración de datos 710 a la pasarela CSCG. Como alternativa, la demanda de migración de datos 710 puede enviarse a la pasarela CSCG desde otro componente de red en representación del origen. La pasarela CSCG puede comparar los más 40 recientes datos de recursos de aplicación con una necesidad de recursos de aplicación y determinar los destinos que son capaces de recibir los datos del origen y realizar las tareas relacionadas (p.ej., Destinos 621-623). La pasarela CSCG puede determinar una necesidad de recursos de red para rutas de redes entre el origen los destinos. La pasarela CSCG puede enviar una demanda de recursos de red 711 a la pasarela NCG. La demanda de recursos de red 711 puede comprender la dirección de red del Origen 601, la necesidad de recursos de red y una 45 lista de direcciones de destino que puede comprender destinos potenciales de migración de datos (p.ej., Destinos 621-623). La demanda de recursos de red 711 puede ser de tipo sumario para indicar que la pasarela CSGW desea recibir información de recursos de red sobre cada enlace de cada ruta o del tipo gráfico para indicar que el CSGW desea recibir información de recursos de red sobe cada enlace de cada ruta. La pasarela NCG puede transmitir una demanda de cálculo de ruta 712 a un PCE, demandar una ruta óptima entre cada par de origen-destino e 50 información de recursos de red sobre cada ruta óptima. El PCE puede transmitir una respuesta de PCE 713 con las rutas y la información de recursos de red relacionada. La pasarela NCG puede recibir la respuesta 713 y rechazar cualquier destino con una ruta o enlace de ruta con información de recursos de red que no satisfagan la necesidad de recursos de red de la CSCG. La pasarela NCG puede crear un mapa de recursos de red que comprende el origen, los destinos, rutas de red, y/o los enlaces que se relacionan con la demanda de recursos de la pasarela 55 CSCG 711 y que satisfacen la necesidad de recursos de red de la CSCG. El mapa de recursos de red puede comprender también la información de recursos de red asociada con cada ruta, cada enlace de ruta o la topología de red completa. El mapa de recursos de red puede comprender información de recursos de red en forma no abstracta o abstracta. La forma no abstracta puede comprender información de recursos de red real, mientras que la forma abstracta puede comprender información de recursos de red en una forma lógica/abstracta con datos no esenciales 60 o duplicativos extraídos o combinados para reducir la complejidad. Si la demanda de recursos 711 fuera de tipo sumario, el mapa de recursos de red puede comprender información del nivel de ruta, y si la demanda de recursos 711 fuera de tipo gráfico, el mapa de recursos de red puede comprender información del nivel del enlace. La pasarela NCG puede enviar una respuesta 715 a la pasarela CSCG con el mapa de recursos de red. La CSCG puede seleccionar un servidor de destino a partir del mapa de recursos de red sobre la base de la información de 65 recursos de red incluida. La pasarela CSCG puede enviar entonces una respuesta 716 a la demanda de migración
de datos 710. La respuesta 716 puede comprender el servidor de destino seleccionado. El origen puede transferir 717 datos al servidor de destino según lo necesite.
La Figura 8 ilustra una forma de realización de un protocolo de reserva de pasarela CSCG 800. Una pasarela CSGC puede demandar 801 datos de recursos de aplicación a partir de una pluralidad de servidores en el estrato de 5 aplicación. Los servidores pueden responder 802 con sus datos de recursos de aplicación locales. Un origen o entidad similar puede enviar una demanda de migración de datos 810 a la pasarela CSCG. La pasarela CSCG puede enviar una demanda de reserva 811 a la pasarela NCG. La demanda de reserva 811 puede comprender prácticamente la misma información que la demanda de recursos 711, pero puede incluir datos que indican que la pasarela NCG debe completar la selección del servidor de destino y reservar una ruta de migración de datos 10 adecuada. La pasarela NCG puede enviar una demanda de cálculo de ruta 812 a un PCE y recibir una respuesta de cálculo de ruta 813 en prácticamente la misma manera que 712 y 713 respectivamente. La pasarela NCG puede seleccionar un destino utilizando la información de recursos de ruta procedente de PCE y las necesidades de recursos de red procedentes de la pasarela CSCG. Como alternativa, la demanda de reserva 811 puede comprender, también datos de recursos de aplicación y/o necesidades de recursos de aplicaciones y la pasarela 15 NCG puede seleccionar un destino sobre la base de la información de recursos de aplicación y la información de recursos de red. Una vez que se seleccione una ruta, la pasarela NCG puede enviar una demanda de reserva de ruta 814 a un elemento de red NE capaz de reservar la ruta, a modo de ejemplo, el elemento NE 540 y/o el extremo de cabecera de la ruta o el nodo final. El elemento de red NE puede reservar la ruta y enviar una confirmación 815 a la pasarela NCG. La pasarela NCG puede enviar una confirmación 816 a la pasarela CSCG indicando que ruta y/o la 20 información de recursos de red de las rutas. La pasarela CSCG puede enviar una respuesta 817 al origen indicando el destino y la ruta. El origen puede iniciar la migración de los datos 818 por intermedio del elemento de red NE o por intermedio de un nodo de final de cabeza de ruta. El elemento de red NE puede transferir entonces 819 los datos a lo largo de la ruta hacia el destino.
La Figura 9 es un diagrama de flujo de una forma de realización de un método de demanda de recursos de pasarela CSCG 900, que puede utilizar en el protocolo de demanda de CSCG 700. Según se describió con anterioridad, la pasarela CSCG puede obtener 910 datos de recursos de aplicación a partir de los servidores de centros de datos. Un origen puede iniciar entonces 920 una transferencia de migración de datos mediante la señalización de la CSCG. La pasarela CSCG puede transmitir entonces una demanda de recursos de red 930 a la pasarela NCG con un 30 origen (p.ej., Origen 601), la lista de direcciones de destino que comprende potenciales servidores de destino (p.ej., Destinos 621-623) y las necesidades de recursos de red. La pasarela NCG puede enviar demás de cálculos de ruta 940 a un PCE para cada par de origen-destino. El PCE puede responder 950 a la pasarela NCG con rutas para cada par de origen-destino.
La pasarela NCG puede crear 960 un mapa de recursos de red rechazando cualquier destino con una ruta o enlaces individuales con información de recursos de red que no satisfagan las necesidades de recursos de red de la pasarela CSCG. A modo de ejemplo, la pasarela CSCG puede demandar que cada ruta tenga una latencia máxima de 20 y una disponibilidad de ancho de banda mínima de 5 en unidades adecuadas. Las rutas recibidas 950 desde el PCE pueden asociarse con la información de recursos de red siguiente: 40
Ruta
Ancho de banda Latencia
Origen 601-Destino 621
Origen 601-Destino 622
Origen 601-Destino 623
Sobre la base de los datos precedentes, la pasarela NCG puede rechazar o filtrar para selección, el Destino 622 puesto que la ruta Origen 601-Destino 622 tiene una disponibilidad de ancho de banda de uno, lo que es insuficiente para satisfacer la necesidad de ancho de banda mínima de cinco. La pasarela NCG puede rechazar también el 45 Destino 623 puesto que la ruta Origen 601-Destino 623 tiene una latencia de 30, que excede y no cumple el requisito de latencia máxima de 30. Si la demanda de recursos 930 fue de tipo sumario, la pasarela NCG puede crear 960 un mapa de recursos de red que comprende la información de nivel de ruta que incluye el Origen 601, los destinos originalmente recibidos por la pasarela NCG que no fueron seleccionados, en este caso, el Destino 621 y la información de recursos de red asociada con la ruta o rutas aceptadas, en este caso una disponibilidad de ancho de 50 banda de 10 y una latencia de 20. La pasarela NCG puede filtrar los destinos sobre la base de los recursos acumulativos de la ruta, los recursos de cada enlace en la ruta o ambos a la vez. Si la demanda de recursos 930 era del tipo gráfico, la pasarela NCG puede crear un mapa de recursos de red que comprenda cada enlace de cada ruta que no fue filtrada para selección y la información de recursos de red asociada con cada enlace aceptado. A modo de ejemplo, la ruta óptima entre el Origen 601 y el Destino 621 puede pasar a través de los elementos de red NE 55 610 y NE 612. El enlace de Origen 601-NE 610 puede tener una disponibilidad de ancho de banda de 15 y una latencia de 7, el enlace de NE 610-NE 612 puede tener una disponibilidad de ancho de banda de 10 y una latencia de 8 y el enlace de NE 612-Destino 621 puede tener una disponibilidad de ancho de banda de 14 y una latencia de 5, en cuyo caso la ruta de Origen 601-Destino 621 tiene una disponibilidad de ancho de banda mínima de extremo a extremo de 10 y una latencia de 20. Si la demanda de recursos 930 era del tipo gráfico, la pasarela NCG puede 60
crear 960 un mapa de recursos de red con la información siguiente:
Enlace
Ancho de banda Latencia
Origen 601-NE 610
NE 610-NE 612
NE 612-Destino 621
La pasarela NCG puede enviar una respuesta 970 a la pasarela CSCG que comprende el mapa de recursos de red con la dirección de destino, rutas y/o enlaces de rutas con los datos de recursos de red asociados. La pasarela 5 CSCG puede facilitar entonces 980 una migración de datos entre el Origen 601 y el Destino 621.
La Figura 10 es un diagrama de flujo de una forma de realización de un método de demanda de reserva de CSCG 1000 que puede utilizarse en el protocolo de reserva de CSCG 800. Según se describió con anterioridad, la pasarela CSCG puede obtener 1010 datos de recursos de aplicación a partir de servidores de centros de datos. Un origen 10 puede iniciar entonces 1020 una migración de datos. La pasarela CSCG puede transmitir 1030 una demanda de reserva a la pasarela NCG. La demanda de reserva puede comprender la dirección origen, la lista de direcciones de destino y las necesidades de recursos de red según se describió con anterioridad. La pasarela NCG puede enviar 1040 una demanda de cálculo de ruta a un PCE, y el PCE puede enviar 1050 rutas de origen-destino calculadas e información de recursos de red relacionada a la pasarela NCG. La pasarela NCG puede seleccionar un destino y 15 reservar 1060 la ruta de red asociada mediante su comunicación con un elemento de red NE. A la recepción de la confirmación de que se ha reservado la ruta de red, la pasarela NCG puede enviar una confirmación 1070 a la pasarela CSCG con la ruta reservada.
La Figura 11 ilustra una forma de realización de una unidad de red 1100, que puede ser cualquier dispositivo que 20 transporta y procesa datos a través de la red, y puede comprender un elemento de red NE en las redes 100-600. La unidad de red 1100 puede comprender uno o más puertos de entrada o unidades 1110 acopladas a un receptor (Rx) 1112 para recibir señales y tramas/datos desde otros componentes de la red. La unidad de red 1100 puede comprender una unidad lógica 1120 para determinar a qué componentes de red enviar datos. La unidad lógica 1120 puede ponerse en práctica utilizando hardware, software o ambos a la vez. La unidad de red 1100 puede 25 comprender también uno o más puertos o unidades de salida 1130 que están acopladas a un transmisor (Tx) 1132 para transmitir señales y tramas/datos a los otros componentes de la red. El receptor 1112, la unidad lógica 1120 y el transmisor 1132 pueden poner en práctica o soportar también el protocolo de demanda de recursos 700, el protocolo de reserva 800, el método de demanda de recursos 900 y el método de demanda de reserva 1000. Los componentes de la unidad de red 1100 pueden disponerse según se ilustra en la Figura 11. 30
Los componentes de red anteriormente descritos pueden ponerse en práctica en cualquier componente de red de uso general, tal como un ordenador o componente de red con potencia de procesamiento suficiente, recursos de memoria y capacidad de rendimiento de la red para gestionar la carga de trabajo necesaria que se le aplica. La Figura 12 ilustra un componente de red de uso general típico 1200 adecuado para poner en práctica una o más 35 formas de realización de los componentes aquí dados a conocer. El componente de red 1200 incluye un procesador 1202 (que puede referirse como una unidad central de procesador o CPU) que está en comunicación con dispositivos de memoria incluyendo la memoria secundaria 1204, la memoria de solamente lectura (ROM) 1206, una memoria RAM 1208, dispositivos de entrada/salida (I/O) 1210 y dispositivos de conectividad de red 1212. El procesador 1202 puede ponerse en práctica como uno o más circuitos integrados de CPU o puede ser parte de uno 40 o más circuitos integrados específicos de la aplicación (ASICs).
La memoria secundaria 1204 suele estar constituida por unas o más unidades de disco o unidades de cinta y se utiliza para la memorización no volátil de datos y como un dispositivo de memorización de datos de desbordamiento de capacidad si la memoria RAM 1208 no es suficientemente amplia para mantener todos los datos de trabajo. La 45 memoria secundaria 1204 puede utilizarse para memorizar programas que se cargan en la memoria RAM 1208 cuando dichos programas se seleccionan para su ejecución. La memoria ROM 1206 se utiliza para memorizar instrucciones y quizás datos que sean objeto de lectura durante la ejecución del programa. La memoria ROM 1206 es un dispositivo de memoria no volátil que suele tener una pequeña capacidad de memoria relativa a la mayor capacidad de memoria de la memoria secundaria 1204. La memoria RAM 1208 se utiliza para memorizar datos 50 volátiles y quizás, para memorizar instrucciones. El acceso a ambas memorias ROM 1206 y RAM 1208 suele ser más rápido que a la memoria secundaria 1204. El componente de red de uso general 1200 puede configurarse para poner en práctica o soportar el protocolo de demanda de recursos 700, el protocolo de reserva 800, el método de demanda de recursos 900 y/o el método de demanda de reserva 1000.
Al menos una forma de realización se da a conocer y las variaciones, combinaciones y/o modificaciones de las formas de realización y/o características de las formas de realización realizadas por un experto en esta técnica están dentro del alcance de la idea inventiva. Formas de realización alternativas que resulten de las funciones de combinar, integrar y/o omitir características de las formas de realización están también dentro del alcance de la idea inventiva. En donde se establecen expresamente limitaciones o márgenes numéricos, dichas limitaciones o 60
márgenes expresos deben entenderse que incluyen márgenes iterativos o limitaciones de magnitud similar que caen dentro de las limitaciones o márgenes que se indican expresamente (p.ej., desde aproximadamente 1 aproximadamente 10 incluye 2, 3, 4, etc.; mayor que 0,10 incluye 0,11, 0,12, 0,13, etc.). A modo de ejemplo, siempre que se da a conocer un margen numérico con un límite inferior Rl y un límite superior Ru cualquier número que cae dentro del margen se da a conocer concretamente. En particular, los siguientes números dentro del margen se dan a 5 conocer específicamente: R = RI + k * (Ru – Rl ) en donde k es una variable cuyo margen es desde el 1 por ciento al 100 por ciento con un incremento del 1 por ciento, esto es, k es 1 por ciento, 2 por ciento, 3 por ciento, 4 por ciento, 7 por ciento, …, 70 por ciento, 71 por ciento, 72 por ciento, …, 97 por ciento, 96 por ciento, 97 por ciento, 98 por ciento, 99 por ciento o 100 por ciento. Además, cualquier margen numérico definido por dos números R según se definió con anterioridad se da a conocer también de forma específica. A no ser que se indique de otro modo, el 10 término “aproximadamente” significa + 10 % del número que le sigue. El uso del término “opcionalmente” con respecto a cualquier elemento de una reivindicación significa que el elemento es requerido, o de forma alternativa, el elemento no es requerido, estando ambas alternativas dentro del alcance de la reivindicación. El uso de términos más amplios tales como comprende, incluye y teniendo, debe entenderse que proporcionan apoyo a términos menos amplios tales como constituido por, constituido esencialmente por y comprendido prácticamente por. En 15 consecuencia, el alcance de protección no está limitado por la descripción anteriormente establecida sino que está definido por las reivindicaciones que siguen, incluyendo ese alcance todos los equivalentes del contenido de las reivindicaciones. Todas y cada una de las reivindicaciones se incorpora como elemento adicional dado a conocer en la especificación y las reivindicaciones son formas de realización de la presente invención. El examen de una referencia en la idea inventiva no es una admisión de que se trate de una técnica anterior, en particular, cualquier 20 referencia que tenga una fecha de publicación después de la fecha de prioridad de esta solicitud de patente. La idea inventiva de todas las patentes, solicitudes de patentes y publicaciones citadas en la invención se incorporan aquí por referencia, en la medida en que proporcionan datos a modo de ejemplo, procedimientos y otros detalles que son complementarios para la idea inventiva.
Los presentes ejemplos han de considerarse como ilustrativos y no restrictivos, y la intención no está limitada a los detalles aquí proporcionados. A modo de ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otro sistema o algunas características pueden omitirse o no ponerse en práctica.

Claims (4)

  1. REIVINDICACIONES
    1. Un sistema que comprende:
    una pasarela de control de servicio de la denominada nube informática, CSCG (314, 414), situada en un estrato de 5 aplicación (310, 410), y una pasarela de control de red, NCG (324, 422), situada en un estrato de red (320, 420),
    en donde la pasarela CSCG (314, 414) está configurada para acoplarse a la pasarela NCG (324, 422), y
    en donde la pasarela CSCG (314, 414) está configurada para transmitir una dirección de origen, una lista de direcciones 10 de destino y una primera necesidad de recursos de red a la pasarela NCG (324, 422), en donde la pasarela CSCG (314, 414) está configurada además para recibir un mapa de recursos de red desde la pasarela NCG (324, 422), donde el mapa de recursos de red comprende un valor de recursos de red de una ruta de red entre la dirección de origen y una dirección de destino contenida en la lista de direcciones de destino, en donde la pasarela CSCG (314, 414) está configurada además para obtener datos de recursos de aplicación desde una pluralidad de servidores, correspondientes 15 a la lista de direcciones de destino, y en donde la pasarela CSCG (314, 414) está configurada además para seleccionar un servidor de destino para una demanda de aplicación basada en un análisis de los datos de recursos de aplicación y el mapa de recursos de red, mediante lo cual la demanda de aplicación es una demanda para la migración de datos desde la dirección de origen a uno de la pluralidad de servidores y;
    en donde la lista de direcciones de destino comprende potenciales servidores de destino; en donde si un primer valor de recursos de red de una ruta de red entre una dirección de origen y una dirección de destino satisface la primera necesidad de recursos de red, en ese caso el mapa de recursos de red comprende la dirección de destino correspondiente al servidor de destino seleccionado por la pasarela CSCG;
    en donde los datos de recursos de aplicación comprenden la utilización de una memoria de acceso aleatorio, RAM, consumo de energía, utilización de unidad central de procesamiento, CPU, de la pluralidad de servidores (312);
    en donde la pasarela NCG (324, 422) está configurada para recibir una comunicación de la pasarela CSCG (314, 414) que comprende la dirección de origen, la lista de direcciones de destino, que comprende una pluralidad de direcciones de 30 destino, y una necesidad de recursos de red, en donde la pasarela NCG (324, 422) está configurada además para transmitir una demanda de cálculo de ruta a un elemento de cálculo de ruta, PCE, situado en el estrato de red (320, 420), y en donde la demanda de cálculo de ruta comprende la dirección de origen y la pluralidad de direcciones de destino, en donde la pasarela NCG (324, 422) está configurada además para recibir una respuesta de cálculo de ruta desde el elemento PCE, en donde la respuesta de cálculo de ruta comprende una pluralidad de rutas de red, en donde cada ruta 35 de red está entre la dirección de origen y cada una de las direcciones de destino,
    y en donde la respuesta de cálculo de ruta comprende además un valor de recursos de red para cada ruta de red o un valor de recursos para cada enlace de una topología de la red.
  2. 2. El sistema según la reivindicación 1, en donde la pasarela CSCG (314, 414) está configurada además para obtener los datos de recursos de aplicación desde una pluralidad de servidores, y en donde la pasarela CSCG está configurada además para llenar la lista de direcciones de destino con direcciones de red de servidores (312) con datos de recursos de aplicación que satisfacen una necesidad de recursos de aplicación.
  3. 3. El sistema según la reivindicación 1, en donde la pasarela CSCG (314, 414) está configurada además para transmitir una segunda necesidad de recursos de red, y en donde la segunda necesidad de recursos de red se transmite como parte de una comunicación que comprende la primera necesidad de recursos de red.
  4. 4. El sistema según la reivindicación 1, en donde el mapa de recursos de red comprende un valor de recursos de red 50 de cada enlace en una ruta de red entre una dirección de origen y una dirección de destino contenida en la lista de direcciones de destino.
ES12729798.4T 2011-06-17 2012-06-15 Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red Active ES2665571T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201161498337P 2011-06-17 2011-06-17
US201161498337P 2011-06-17
PCT/US2012/042768 WO2012174444A1 (en) 2011-06-17 2012-06-15 Cloud service control and management architecture expanded to interface the network stratum

Publications (1)

Publication Number Publication Date
ES2665571T3 true ES2665571T3 (es) 2018-04-26

Family

ID=46331739

Family Applications (2)

Application Number Title Priority Date Filing Date
ES12729322.3T Active ES2614863T3 (es) 2011-06-17 2012-06-15 Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red
ES12729798.4T Active ES2665571T3 (es) 2011-06-17 2012-06-15 Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES12729322.3T Active ES2614863T3 (es) 2011-06-17 2012-06-15 Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red

Country Status (6)

Country Link
US (4) US8793380B2 (es)
EP (2) EP2710785B1 (es)
CN (2) CN103477612B (es)
BR (2) BR112013032366B1 (es)
ES (2) ES2614863T3 (es)
WO (2) WO2012174444A1 (es)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2614863T3 (es) * 2011-06-17 2017-06-02 Huawei Technologies Co., Ltd. Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red
US20130191519A1 (en) * 2012-01-20 2013-07-25 Alcatel-Lucent Usa Inc. Component Placement for Application-Level Latency Requirements
US9395960B2 (en) * 2013-02-19 2016-07-19 PLUMgrid, Inc. Method and system for data plane abstraction to enable a dynamic creation of network applications
EP2770431B1 (en) * 2013-02-25 2017-01-04 Telefonica S.A. System and method to trigger cross-layer optimizations in a network
US9454408B2 (en) * 2013-05-16 2016-09-27 International Business Machines Corporation Managing network utility of applications on cloud data centers
US9277002B2 (en) 2014-01-09 2016-03-01 International Business Machines Corporation Physical resource management
US8950710B1 (en) 2014-01-31 2015-02-10 Kitefarms LLC Apparatus for extracting power from fluid flow
US10009246B1 (en) * 2014-03-28 2018-06-26 Amazon Technologies, Inc. Monitoring service
CN106034073B (zh) * 2015-03-20 2019-01-18 网宿科技股份有限公司 一种基于内容分发网络的多路径传输优化的方法
US10387209B2 (en) * 2015-09-28 2019-08-20 International Business Machines Corporation Dynamic transparent provisioning of resources for application specific resources
CN105681125B (zh) * 2015-12-28 2019-08-13 国云科技股份有限公司 一种云平台的虚拟机外网流量统计方法
US10218772B2 (en) * 2016-02-25 2019-02-26 LiveQoS Inc. Efficient file routing system
US10742498B2 (en) * 2016-06-22 2020-08-11 Amazon Technologies, Inc. Application migration system
CN106254263B (zh) * 2016-09-30 2019-09-20 北京邮电大学 底层网络拥塞状态信息的获取方法、装置及***
US11503136B2 (en) 2016-11-30 2022-11-15 Microsoft Technology Licensing, Llc Data migration reservation system and method
EP3603022B1 (en) * 2017-03-31 2021-09-15 Telefonaktiebolaget LM Ericsson (PUBL) Application topology aware user plane selection in nr and 5gc
US11083028B2 (en) 2017-03-31 2021-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Coordinated selection of user plane functions in core and radio access networks
US20190158367A1 (en) * 2017-11-21 2019-05-23 Hewlett Packard Enterprise Development Lp Selection of cloud service providers to host applications
CN108924863B (zh) * 2018-07-18 2021-04-02 武汉虹信科技发展有限责任公司 一种s11接口自动配置方法及***
US10936451B2 (en) * 2018-10-24 2021-03-02 EMC IP Holding Company LLC Concurrent remote IO processing for synchronous replication
US11625230B2 (en) * 2020-09-22 2023-04-11 Cisco Technology, Inc. Identifying execution environments for deploying network functions

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2332809A (en) 1997-12-24 1999-06-30 Northern Telecom Ltd Least cost routing
US6987756B1 (en) 1999-10-07 2006-01-17 Nortel Networks Limited Multi-mode endpoint in a communication network system and methods thereof
US7508753B2 (en) * 2000-01-31 2009-03-24 At&T Intellectual Property, Ii, L.P. Packet redirection and message stream management
US7849130B2 (en) * 2003-04-30 2010-12-07 International Business Machines Corporation Dynamic service-on-demand delivery messaging hub
US20070258455A1 (en) * 2006-05-08 2007-11-08 Futurewei Technologies, Inc. System for distributed architecture for multicast access control
US7831700B2 (en) 2006-10-16 2010-11-09 Futurewei Technologies, Inc. Distributed PCE-based system and architecture in multi-layer network
CN100518378C (zh) * 2007-03-05 2009-07-22 中山大学 一种实现移动节点从IPv6网络切换到IPv4网络的通信方法
US8533327B2 (en) * 2007-04-04 2013-09-10 Zte Corporation System and method of providing services via a peer-to-peer-based next generation network
US8238334B2 (en) * 2007-04-30 2012-08-07 Futurewei Technologies Inc. Optimal path selection for accessing networked applications
US7970903B2 (en) * 2007-08-20 2011-06-28 Hitachi, Ltd. Storage and server provisioning for virtualized and geographically dispersed data centers
US9106452B2 (en) 2008-03-24 2015-08-11 Shoretel, Inc. Cloud VoIP system with bypass for IP media
US9069599B2 (en) * 2008-06-19 2015-06-30 Servicemesh, Inc. System and method for a cloud computing abstraction layer with security zone facilities
CN101668317B (zh) * 2008-09-04 2012-07-11 华为技术有限公司 一种网络资源预留的方法、***和装置
US7636764B1 (en) 2008-09-29 2009-12-22 Gene Fein Cloud resource usage in data forwarding storage
US8285681B2 (en) 2009-06-30 2012-10-09 Commvault Systems, Inc. Data object store and server for a cloud storage environment, including data deduplication and data management across multiple cloud storage sites
US9442810B2 (en) 2009-07-31 2016-09-13 Paypal, Inc. Cloud computing: unified management console for services and resources in a data center
US8214499B2 (en) * 2009-10-26 2012-07-03 Wipro Limited System and method for enabling software applications as a service in a non-intrusive manner
US8250213B2 (en) * 2009-11-16 2012-08-21 At&T Intellectual Property I, L.P. Methods and apparatus to allocate resources associated with a distributive computing network
US20110126168A1 (en) 2009-11-25 2011-05-26 Crowdsource Technologies Ltd. Cloud plarform for managing software as a service (saas) resources
US20110126197A1 (en) * 2009-11-25 2011-05-26 Novell, Inc. System and method for controlling cloud and virtualized data centers in an intelligent workload management system
KR101304793B1 (ko) 2009-12-21 2013-09-05 한국전자통신연구원 Ted 정확성을 보장하는 ted 관리 방법 및 시스템
US20110173108A1 (en) * 2010-01-13 2011-07-14 Oracle International Corporation Gateway for enabling cloud-based service exposure
JP5298055B2 (ja) * 2010-03-24 2013-09-25 Kddi株式会社 資源内に配置された制御対象機器を制御する機器制御装置、プログラム及び方法
US8997196B2 (en) * 2010-06-14 2015-03-31 Microsoft Corporation Flexible end-point compliance and strong authentication for distributed hybrid enterprises
US20120311157A1 (en) 2011-06-03 2012-12-06 Erickson Philip J Integrated information technology service management for cloud resources
US9184983B2 (en) 2010-08-26 2015-11-10 Futurewei Technologies, Inc. Cross-stratum optimization protocol
US8645529B2 (en) 2010-10-06 2014-02-04 Infosys Limited Automated service level management of applications in cloud computing environment
US9584949B2 (en) * 2011-01-27 2017-02-28 Microsoft Technology Licensing, Llc Cloud based master data management architecture
US8988998B2 (en) * 2011-02-25 2015-03-24 International Business Machines Corporation Data processing environment integration control
US8984269B2 (en) 2011-02-28 2015-03-17 Red Hat, Inc. Migrating data among cloud-based storage networks via a data distribution service
ES2614863T3 (es) * 2011-06-17 2017-06-02 Huawei Technologies Co., Ltd. Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red

Also Published As

Publication number Publication date
EP2710785A1 (en) 2014-03-26
US9948696B2 (en) 2018-04-17
BR112013032366A2 (es) 2017-01-03
CN103548325B (zh) 2017-06-27
US20120324083A1 (en) 2012-12-20
WO2012174441A1 (en) 2012-12-20
US10542076B2 (en) 2020-01-21
US8645546B2 (en) 2014-02-04
ES2614863T3 (es) 2017-06-02
EP2712480B1 (en) 2018-01-10
US20120324082A1 (en) 2012-12-20
US8793380B2 (en) 2014-07-29
CN103477612B (zh) 2016-10-05
US20180234488A1 (en) 2018-08-16
WO2012174444A1 (en) 2012-12-20
EP2710785B1 (en) 2016-11-23
CN103548325A (zh) 2014-01-29
US20140297830A1 (en) 2014-10-02
BR112013032366B1 (pt) 2022-11-01
BR112013032368A2 (es) 2017-01-03
EP2712480A1 (en) 2014-04-02
CN103477612A (zh) 2013-12-25
BR112013032368B1 (pt) 2022-11-16

Similar Documents

Publication Publication Date Title
ES2665571T3 (es) Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red
JP7417825B2 (ja) スライスベースルーティング
ES2746922T3 (es) Método y sistema para la optimización de estrato cruzado en redes de transporte-aplicación
ES2951911T3 (es) Sistema y método para interfaces virtual y enrutamiento inteligente avanzado en una red virtual global
US9450874B2 (en) Method for internet traffic management using a central traffic controller
CN111492627B (zh) 为不同应用建立不同隧道的基于控制器的服务策略映射
US10411989B2 (en) Compiler for and method of software defined networking, storage and compute determining physical and virtual resources
CN110535760B (zh) 聚合接口的转发检测
US20040034702A1 (en) Method and apparatus for exchanging intra-domain routing information between VPN sites
US20140280864A1 (en) Methods of Representing Software Defined Networking-Based Multiple Layer Network Topology Views
EP3979565A1 (en) Multi-region virtual overlay wide area network
JP6008801B2 (ja) 伝送システム、送信方法、及び伝送装置
US9847914B2 (en) Method and system for site interconnection over a transport network
US11855893B2 (en) Tag-based cross-region segment management
US20140207967A1 (en) Method and Apparatus for Provisioning a Transport Service in a Multi-Domain Multi-Layer Network
US11799755B2 (en) Metadata-based cross-region segment routing
US11843542B2 (en) Safely engineering egress traffic changes
Hosken Architecting a Hybrid Mobility Strategy with the VMware Cloud Provider™ Program