ES2746044T3 - Protocolo de optimización de estratos cruzados - Google Patents
Protocolo de optimización de estratos cruzados Download PDFInfo
- Publication number
- ES2746044T3 ES2746044T3 ES11819438T ES11819438T ES2746044T3 ES 2746044 T3 ES2746044 T3 ES 2746044T3 ES 11819438 T ES11819438 T ES 11819438T ES 11819438 T ES11819438 T ES 11819438T ES 2746044 T3 ES2746044 T3 ES 2746044T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- field
- indicate
- csop
- network
- 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
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/20—Arrangements for monitoring or testing data switching networks the monitoring system or the monitored elements being virtualised, abstracted or software-defined entities, e.g. SDN or NFV
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/64—Routing or path finding of packets in data switching networks using an overlay routing layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Environmental & Geological Engineering (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
Un aparato que comprende: una pasarela (ACG) de optimización de estratos cruzados de aplicación, CSO, (314) acoplada a un estrato de aplicación (110, 210, 310, 410) que gestiona una pluralidad de servidores (112, 212, 312); una pasarela CSO de red, NCG, (324) acoplada a un estrato de red (120, 220, 320, 420) que gestiona una pluralidad de nodos de red (122, 222, 322) y está configurada para comunicarse con la ACG (314) utilizando un Protocolo de CSO, CSOP; y una interfaz CSO establecida entre la ACG (314) y la NCG (324); en donde la ACG (314) está configurada para comunicarse con la NCG (324) por intermedio de la interfaz CSO y para proporcionar información de recursos de aplicación y limitaciones de acceso a entidades externas en el estrato de la red (120, 220, 320, 420); en donde la NCG (324) está configurada para comunicarse con la ACG (314) por intermedio de la interfaz CSO, y para proporcionar información de recursos de red y limitaciones de acceso a entidades del estrato de aplicación; en donde se intercambian una pluralidad de mensajes de CSOP por intermedio de la interfaz CSO entre la ACG (314) y la NCG (324) para una asignación, un aprovisionamiento y una optimización comunes de recursos de red de aplicación.
Description
DESCRIPCIÓN
Protocolo de optimización de estratos cruzados
ANTECEDENTES DE LA INVENCIÓN
Las portadoras de red, también referidas, a veces, como operadores de telecomunicaciones o proveedores de servicios de comunicaciones, que ejecutan redes existentes, desean optimizar la utilización de la red para el tráfico de paso, tal como el tráfico del Protocolo Internet (IP), a través de una red física, p.ej., a través de capas de red 1 a 5. El tráfico optimizado puede incluir tráfico para servicios de triple ejecución (p.ej., vídeo, voz y/o datos) y cualquier tipo de datos masivos. En redes existentes, los servicios de extremo a extremo generalmente se configuran mediante Sistemas de Soporte Operativo (OSS) o aplicaciones de servicios de gestión de red específica del proveedor. Los operadores de red han sugerido dos escenarios operativos diferentes para optimizar la utilización y el tráfico de la red: optimizar los servicios de red existentes y habilitar servicios de aplicación de red nuevos/emergentes.
El documento WO 02/11459 A1 describe una pasarela de Parlay que incluye un bus CORBA, una capa interna de APIs de Parlay, una capa externa de la interfaz de servicio de red para controlar los recursos de red, una interfaz de aplicación y unas APIs de Parlay que están situadas en plataformas distantes que, además, alojan aplicaciones que desean acceder a los recursos de la red.
SUMARIO DE LA INVENCIÓN
En una forma de realización, la presente invención incluye un aparato que comprende una pasarela (ACG) de optimización de estratos cruzados de aplicación (CSO) acoplada a una capa de aplicación que gestiona una pluralidad de servidores, una pasarela CSO de red (NCG) acoplada a una capa de red que gestiona una pluralidad de nodos de red y está configurada para comunicarse con la ACG utilizando un protocolo CSO (CSOP), y una interfaz CSO establecida entre la ACG y la NCG; en donde la ACG (314) está configurada para comunicarse con la NCG (324) por intermedio de la interfaz CSO y para proporcionar información de recurso de la aplicación y limitaciones de acceso a entidades externas en la capa de red (120, 220, 320, 420); en donde la NCG (324) está configurada para comunicarse con la ACG (314) por intermedio de la interfaz CSO, y para proporcionar información de recurso de red y limitaciones de acceso a las entidades de capa de aplicación; en donde se intercambia una pluralidad de mensajes CSOP por intermedio de la interfaz CSO entre la ACG y la NCG para la asignación, el aprovisionamiento y la optimización de recursos de la red de aplicación común.
En otra forma de realización, la idea inventiva incluye un componente de red que comprende un receptor configurado para recibir un primer mensaje CSOP por intermedio de una interfaz CSO establecida entre una capa de aplicación y una capa de red, y un controlador de plano configurado para habilitar CSO entre la capa de aplicación y la capa de red mediante el procesamiento del primer mensaje CSOP para asignar, aprovisionar u optimizar el recurso de red de aplicación común, y un transmisor configurado para enviar un segundo mensaje CSOP por intermedio de la interfaz CSO en respuesta al primer mensaje CSOP, o para la finalidad de CSO; en donde el primer mensaje CSOP y el segundo mensaje CSOP proporcionan mecanismos de abstracción y resumen para garantizar el intercambio de información necesaria para conseguir la CSO mientras se evita el intercambio de información privada o segura, que no está autorizada a otras entidades, redes y/o estratos.
Estas y otras características se entenderán más claramente a partir de la siguiente descripción detallada tomada en conjunción con los dibujos y reivindicaciones adjuntos.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para un entendimiento más completo de esta descripción, se hace referencia ahora a la siguiente breve descripción, tomada en relación con los dibujos adjuntos y la descripción detallada, en donde los números de referencia similares representan partes similares.
La Figura 1 es un diagrama esquemático de una forma de realización de una arquitectura CSO.
La Figura 2 es un diagrama esquemático de otra forma de realización de una arquitectura 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 un sistema CSOP.
La Figura 5 es un diagrama esquemático de una forma de realización de una cabecera de mensaje CSOP.
La Figura 6 es un diagrama esquemático de una forma de realización de un objeto de perfil de autenticación.
La Figura 7 es un diagrama esquemático de una forma de realización n objeto de perfil de servicio. La Figura 8 es un diagrama esquemático de una forma de realización n objeto de perfil de rendimiento La Figura 9 es un diagrama esquemático de una forma de realización n objeto de perfil de ancho de b La Figura 10 es un diagrama esquemático de una forma de realización de un objeto de perfil de modo de conectividad.
La Figura 11 es un diagrama esquemático de una forma de realización de un objeto de perfil de localización.
La Figura 12 es un diagrama esquemático de una forma de realización de un Tipo/Longitud/Valor (TLV) opcional.
La Figura 13 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 14 es un diagrama esquemático de una forma de realización de un objeto de perfil de protección.
La Figura 15 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 16 es un diagrama esquemático de una forma de realización de un objeto de ruta.
La Figura 17 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 18 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 19 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 20 es un diagrama esquemático de una forma de realización de un objeto de topología de red virtual (VNT).
La Figura 21 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 22 es un diagrama esquemático de otra forma de realización de un TLV opcional.
La Figura 23 es un diagrama de protocolo de una forma de realización de un intercambio de mensajes CSOP.
La Figura 24 es un diagrama esquemático de una forma de realización de una unidad de red.
La Figura 25 es un diagrama esquemático de una forma de realización de un sistema informático de finalidad general.
DESCRIPCIÓN DETALLADA
Ha de entenderse desde el principio que, aunque a continuación se da a conocer una puesta en práctica ilustrativa de una o más formas de realización, los sistemas y/o métodos descritos se pueden realizar utilizando cualquier número de técnicas, ya sean actualmente conocidas o existentes. La presente invención no debe limitarse, en modo alguno, a las puestas en práctica ilustrativas, dibujos y técnicas ilustradas a continuación, incluidos los diseños y realizaciones que se ilustran y describen aquí a modo de ejemplo, sino que puede modificarse dentro del alcance de las reivindicaciones adjuntas junto con el alcance completo de sus equivalentes.
El suministro y funcionamiento de aplicaciones nuevas/emergentes puede implicar la resolución del problema de selección de servidor (SS) en el estrato de la aplicación, así como el aprovisionamiento de la red en el estrato de red subyacente. El estrato de aplicación puede incluir las aplicaciones y servicios, que se ponen en práctica, o se ejecutan, sobre la aplicación y la capa de red, y el estrato de red puede incluir el transporte, la red, el enlace y las capas físicas o combinaciones de los mismos. La gestión y la coordinación del aprovisionamiento de servicios, tanto en el estrato de aplicación como en el estrato de red, es diferente de la gestión de servicios tradicionales, tales como el aprovisionamiento de red de servicios de telecomunicaciones de extremo a extremo.
La CSO puede habilitar nuevos servicios, p.ej., utilizando la optimización multi-dominio y/o multi-dispositivo. Los nuevos servicios pueden incluir sistemas de distribución de ficheros, servicios de transmisión de vídeo, servicios de vídeoconferencia y servicios informáticos en malla. Estos servicios pueden utilizar tanto dispositivos móviles como dispositivos fijos. Los sistemas y servicios de distribución de ficheros comenzaron acelerando la descarga de páginas web, tales como aquellas que contienen imágenes y, a continuación, se expandieron para incluir la entrega de ficheros de software, audio y vídeo. Los servicios de transmisión pueden separarse en dos tipos, servicios en directo y bajo demanda. Se pueden crear, además, múltiples variantes entre estos dos tipos cuando la funcionalidad de pausa o reproducción se incluye en un servicio de transmisión en directo. La transmisión en directo puede ser el
caso en el que el cliente está dispuesto a recibir la transmisión en su punto de reproducción actual en lugar de en algún punto de inicio previamente existente. Los servicios bajo demanda pueden producir desafíos técnicos adicionales. Es posible que los proveedores de servicios deseen evitar retardos prolongados en el inicio del servicio con el fin de retener a los clientes mientras que, al mismo tiempo, las demandas conjuntas de lotes economizan los costes de servidores. La vídeoconferencia se mueve desde el escenario operativo de distribución de contenido de transmisión en directo de punto a multipunto a una situación de multipunto a multipunto. Además, puede haber una restricción adicional de Calidad de Servicio (QoS) en la latencia. Servicios informáticos en malla pueden tener requisitos para una transferencia considerablemente grande de ficheros con separación reducida y mayores tamaños de ficheros.
Un problema en las interacciones entre el estrato de aplicación y el estrato de red es la falta de una interfaz estándar abierta que permita una señalización proxy entre los estratos de aplicación y red. Esto puede limitar el intercambio de información entre estratos cruzados, el mecanismo de realimentación entre estratos y la asignación y reconfiguración de recursos integrados/sincronizados. Esta falta de coordinación entre los estratos de aplicación y red puede aumentar el potencial de desperdicio de recursos, lo que puede traducirse en un mayor costo tanto para la aplicación como para las operaciones de la red.
En el presente documento se describe un sistema y métodos para proporcionar una especificación de protocolo para el soporte de CSO, al que se hace referencia en este documento como CSOP. La CSO puede implicar la optimización integrada de la aplicación y los recursos de red al proporcionar una interfaz para las interacciones e intercambios entre los dos estratos. La CSO puede incluir, además, la coordinación de la aplicación y los recursos de red. La CSO se puede lograr independientemente de cualquier optimización posible para aplicaciones o servicios existentes que se ejecutan en una red.
Algunos de los términos utilizados y descritos a continuación, con respecto a las características de la CSO, incluyen: ACG, NCG, CSOP y perfil. La ACG puede ser una entidad de CSO en el estrato de aplicación, que es responsable de reunir la carga y la utilización de los recursos de aplicación, tomar decisiones de asignación de recursos e interactuar con la NCG. La NCG puede ser una entidad de CSO en el estrato de red, que es responsable de interactuar con la ACG, con la activación de la función de demanda de servicio para transportar la entidad de red responsable del aprovisionamiento, configuración, estimación/cálculo de ruta y otras funciones de gestión/control de red. El CSOP puede ser un protocolo que se ejecuta en una interfaz entre una ACG y una NCG, tal como se describe más adelante. El perfil puede incluir información que describe el requisito de servicio para una aplicación. El perfil se puede generar por una ACG y comunicarse a una NCG a través del CSOP, tal como aquí se describe.
La Figura 1 ilustra formas de realización de una arquitectura CSO 100. La arquitectura CSO 100 puede comprender un estrato de aplicación 110 y un estrato de red 120. El estrato de aplicación 110 puede implicar comunicaciones entre una pluralidad de servidores 112, que pueden estar configurados para poner en práctica, o ejecutar, aplicaciones para usuarios finales o clientes (no ilustrados). El estrato de red 120 puede implicar comunicaciones entre una pluralidad de nodos de red 122, tales como puentes, enrutadores y/o conmutadores, para el reenvío de datos, por ejemplo, paquetes, asociados con las aplicaciones. Los servidores 112 pueden estar situados en un centro de datos y los nodos de red 122 pueden estar ubicados en una red acoplada al centro de datos. Los servidores 112 se pueden comunicar con los nodos de red 122 para permitir el servicio de aplicaciones del usuario y el reenvío o transporte de los datos asociados. La CSO se puede poner en práctica para optimizar las diferentes operaciones de los servidores 112 y los nodos de red 122. Los servidores 112 pueden estar situados en el mismo centro de datos, o un subconjunto de servidores 112 puede situarse en múltiples centros de datos.
En una forma de realización, los centros de datos utilizados para proporcionar servicios de aplicación, tales como los denominados servicios informáticos en la nube, y otros servicios en la nube, en el estrato de aplicación 110 a los usuarios finales, se pueden distribuir geográficamente alrededor del estrato de red 120. Por lo tanto, numerosas decisiones sobre el control y la gestión de servicios de aplicaciones, tales como dónde realizar la instanciación de otra instancia de servicio, o a qué centro de datos se asigna un nuevo cliente, pueden tener un impacto significativo en el estado de la red. Las capacidades y el estado de la red pueden tener, además, un impacto en el rendimiento de la aplicación.
Actualmente, las decisiones de aplicación se pueden tomar con poca, o ninguna, información referente a la red subyacente que se utiliza para proporcionar dichos servicios. En consecuencia, tales decisiones pueden ser sub óptimas a partir tanto de la aplicación y la utilización de los recursos de red como desde el logro de los objetivos de QoS. La CSO 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 contexto de servicios informáticos en la nube y las redes de centros de datos. A modo de ejemplo, los objetivos de la CSO pueden admitir la consulta del estrato de red 110 desde la aplicación, el aprovisionamiento conjunto entre la aplicación y la red, y/o la reasignación conjunta de recursos, en caso de anomalía, tanto en la aplicación como en la red. Los objetivos de las CSO pueden proporcionar, además, una red con reconocimiento de aplicaciones, aplicación con reconocimiento de red y capacidad de equilibrio de carga global. 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, la topología, el aprovisionamiento, la supervisión de uso, la
supervisión de fallos, o combinaciones de los mismos. Por ejemplo, los objetivos de CSO 100 pueden mejorar el intercambio de una, o ambas, capacidades de red o información de demanda/recurso de aplicación, información relacionada con la topología y/o ingeniería de tráfico entre las capas (virtualización/abstracción), o ambas. Los objetivos de las CSO pueden mejorar, además, el inicio del servicio de instanciación de la aplicación a la red con intercambio de perfil (aprovisionamiento), intercambio de información de congestión/fallo de la red/aplicación (supervisión), o ambos.
La Figura 2 ilustra otra forma de realización de una arquitectura CSO 200 que puede comprender un estrato de aplicación 210 y un estrato de red 220. El estrato de aplicación 210 puede gestionar comunicaciones entre una pluralidad de servidores 212, y el estrato de red 220 puede gestionar comunicaciones entre una pluralidad de nodos de red 222, que pueden ser prácticamente similares a los servidores 112 y los nodos de red 122, respectivamente. La arquitectura CSO 200 puede incluir, además, una interfaz de CSO que permite mejores interacciones y/o comunicaciones entre los servidores 112 y/u otros componentes (no ilustrados) del estrato de aplicación 210, y los nodos de red 122 y/u otros componentes (no ilustrados) del estrato de red 220. La interfaz CSO puede ser una interfaz abierta entre los dos estratos y puede habilitar las características de CSO utilizando el CSOP, tal como se describe a continuación. En el estrato de aplicación 210, la interfaz abierta puede permitir una identificación de cliente/consumidor de algún tipo, p.ej., dirección IP, tipos de servidor e identificación, flujos de datos de aplicación y requisitos de QoS que pueden ser de naturaleza estadística y variar con el tiempo, y/o carga de servidor y condiciones de fallo operativo. En el estrato de red 220, la interfaz abierta puede permitir, además, el intercambio de topología de red, ubicaciones de cliente y servidor dentro de esa topología, capacidades de red y capacidades con respecto a QoS, ancho de banda, información de latencia y/u otras características relacionadas con la red, carga de red y condiciones de fallo operativo, o combinaciones de los mismos.
La Figura 3 ilustra otra forma de realización de una arquitectura CSO 300 que puede incluir un estrato de aplicación 310 y un estrato de red 320. El estrato de aplicación 310 puede incluir interacciones entre una pluralidad de servidores 312, y el estrato de red 320 puede incluir interacciones entre 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 CSO 300 puede comprender, además, una interfaz CSO que puede establecerse entre una ACG 314 en el estrato de aplicación 310, y una NCG 324 en el estrato de red 320.
La ACG 314 se puede configurar para acceder a datos y procesos relacionados con la aplicación en el estrato de aplicación 310, comunicarse con la NCG 324, por intermedio de la interfaz CSO, y proporcionar información de recursos de la aplicación y limitaciones de acceso a entidades externas en las entidades de estrato de red 320. La NCG 324 puede configurarse para acceder a datos relacionados con la red (en el estrato de red 320), comunicarse con la ACG 314 por intermedio de la interfaz CSO, comunicarse con procesos de red tales como control de admisión, reserva de recursos y/o procesamiento de conexión, y proporcionar información de recurso de red y limitaciones de acceso a entidades del estrato de aplicación 310. Además, la ACG 314 y la NCG 324 se pueden comunicar con los servidores 312 y los nodos de red 322, respectivamente. La interfaz CSO entre la ACG 314 y la NCG 324 puede admitir el uso del CSOP para habilitar las diferentes funcionalidades de la ACG 314 y la NCG 324 anteriores, y las comunicaciones relacionadas, p.ej., señalización, mensajería e intercambio de información.
La Figura 4 ilustra una forma de realización de un sistema CSOP 400, que puede ponerse en práctica utilizando la interfaz CSO entre una ACG y una NCG, a modo de ejemplo, en las arquitecturas CSO anteriores. Se puede enviar un perfil de usuario desde un usuario o plano de usuario 401 a un estrato de aplicación 410. El perfil de usuario puede definir características del usuario y puede comprender un identificador de usuario, un identificador de dispositivo de usuario, información de códec de dispositivo de usuario, si es aplicable, preferencia de usuario si está disponible, capacidad de usuario o combinaciones de los mismos. El identificador de usuario puede ser un identificador de usuario único (ID), tal como un ID virtual. El identificador del dispositivo del usuario puede corresponder a la dirección, p.ej., dirección de IP y/o de Control de Acceso al Soporte (MAC), para cada dispositivo de usuario. Puede haber múltiples dispositivos de usuario dependiendo de la localización del usuario. La preferencia del usuario puede conocerse, a priori, tal como una localización preferida del servidor para el usuario. La capacidad del usuario puede incluir el ancho de banda máximo que el dispositivo del usuario puede gestionar, a modo de ejemplo, para enlace ascendente y/o enlace descendente.
El estrato de aplicación 410 puede reenviar, a continuación, el perfil de usuario, p.ej., después del procesamiento, a un estrato de red 420. De forma adicional o como alternativa, el estrato de aplicación 410 puede reenviar un perfil de aplicación a un estrato de red 420. El perfil de aplicación se puede obtener sobre la base del perfil de usuario y puede definir características de la aplicación para el usuario. El perfil de la aplicación puede incluir al menos uno de entre un perfil de seguridad, un perfil de localización, un perfil de QoS, un perfil de conectividad, un perfil de direccionalidad, un perfil de ancho de banda, un perfil de duración del servicio y un perfil de restablecimiento.
El perfil de seguridad puede incluir una red privada virtual de extremo a extremo dedicada (VPN), tal como la asignación de recursos y la asignación de recursos físicos dedicados. El perfil de localización puede indicar ubicaciones tanto de los clientes como de las fuentes. El perfil de QoS puede comprender un límite de tolerancia de retardo, un límite de tolerancia de fluctuación de fase, tolerancia de relación de entrega de paquetes, disponibilidad de red y/u otra información relacionada con QoS. El perfil de conectividad puede indicar una conectividad de punto a
punto (P-P), de punto a multipunto (P-MP), de multipunto a multipunto (MP-MP), y/o cualquier otra conectividad o sistema de transmisión. El perfil de direccionalidad puede indicar una comunicación unidireccional o una comunicación bidireccional. El perfil de ancho de banda puede indicar los requisitos de ancho de banda máximo, medio y/o mínimo para la conectividad, la tasa de ráfaga máxima, la duración máxima de la ráfaga y/u otra información relacionada con el ancho de banda. La duración del perfil de servicio puede indicar un tiempo de servicio de la aplicación, p.ej., una vez que se configura. El perfil de restablecimiento puede indicar que se requiere un redireccionamiento, no es requerido un redireccionamiento y/u otra información relacionada con el restablecimiento de la conectividad.
Dependiendo de la aplicación, su naturaleza y la calidad de servicio relacionada, el estrato de red subyacente 420 puede tener diferentes capacidades. El estrato de red 420 puede reenviar su información de capacidad de red al estrato de aplicación 410, por ejemplo, en respuesta a la recepción de una demanda y/o el perfil de aplicación. La capacidad de red puede incluir capacidades de ancho de banda, QoS y acuerdo de nivel de servicio (SLA), configurabilidad y adaptabilidad. Las capacidades de ancho de banda pueden indicar la capacidad de la red para cumplir con los requisitos del perfil de ancho de banda del servicio de aplicación. La QoS y el SLA pueden indicar la capacidad de la red para realizar la entrega, de conformidad con los requisitos del perfil de QoS y los SLAs correspondientes. La capacidad de configuración puede indicar la capacidad para reconfigurar/volver a optimizar varios aspectos de la red y los momentos en que se pueden producir cambios. La información de adaptabilidad puede indicar la capacidad de adaptar cambios debido a cambios en la demanda del servicio, o la congestión/fallo de la aplicación/red.
Aunque la Figura 4 ilustra un sistema de CSOP 400 en donde se envía un perfil de usuario a un estrato de aplicación, no todas las formas de realización incluyen la etapa de información de perfil de usuario. A modo de ejemplo, puesto que algunas aplicaciones (p.ej., copia de seguridad de almacenamiento) no requieren información de perfil de usuario, el sistema de CSOP para dichas aplicaciones es estrictamente entre un centro de datos a otro (o varios centros de datos, dependiendo del número de copias de seguridad).
Las comunicaciones de CSOP, en cualquiera de las arquitecturas o sistemas anteriores, pueden comprender comunicaciones verticales entre el plano de usuario y el estrato de aplicación, y comunicaciones verticales entre el estrato de aplicación y el estrato de red. La funcionalidad de CSOP puede incluir estimación de ruta, reserva de ruta, consulta de topología de red/topología de máquina virtual (VMT), supervisión/notificación y/u otras funciones que se describen a continuación. El CSOP puede operar a través de un protocolo de control de transmisión (TCP), p.ej., utilizando puertos TCP registrados que pueden tener determinados números de puerto. Sin embargo, el funcionamiento de CSOP no está limitado a TCP, sino que se puede poner en práctica utilizando otros protocolos, tales como, a modo de ejemplo, OpenFlow. En consecuencia, todos los mensajes de CSOP pueden enviarse a través de los puertos TCP registrados. El CSOP puede proporcionar, además, medios para garantizar el intercambio de información necesaria para lograr la CSO al tiempo que evita el intercambio de información privada o segura, que puede no estar autorizada para otras entidades, redes y/o estratos. El CSOP puede proporcionar los mecanismos de abstracción y resumen con el fin de evitar revelar detalles innecesarios (p.ej., entre la capa/estrato de aplicación y la capa/estrato de red) y para proporcionar, además, una escalabilidad mejorada. Los mecanismos de abstracción y resumen se pueden proporcionar utilizando formatos de mensajes CSOP, tal como se describe, en detalle, a continuación.
Los mensajes de CSOP pueden incluir un mensaje de Inicialización, un mensaje de mantenimiento activo (KeepAlive), un mensaje de Demanda, un mensaje de Respuesta, un mensaje de Liberación, un mensaje de Configuración de Liberación (ReleaseConf), un mensaje de Notificación, un mensaje de error de CSOP (CSOPErr), un mensaje de sesión de CSOP (CLOSE) o combinaciones de los mismos. El masaje de Inicialización se puede utilizar para iniciar una sesión de CSOP con un procedimiento de autenticación entre una ACG y una NCG. El mensaje de KeepAlive se puede utilizar para mantener una sesión de CSOP. El mensaje de Demanda se puede utilizar para solicitar una configuración de ruta desde una ACG a una NCG, una estimación de ruta con, o sin, compromiso de reserva/asignación real desde una ACG a una NCG, y una topología de red virtual procedente de una ACG a una NCG. El mensaje de Respuesta se puede utilizar en respuesta a un mensaje de Demanda de una NCG a una ACG. El mensaje de Liberación se puede utilizar para solicitar la liberación de cualquier ruta existente. Se envía desde una ACG a una NCG. El mensaje de configuración de liberación ReleaseConf se puede utilizar en respuesta a un mensaje de liberación Release para confirmar la liberación de cualquier ruta existente. El mensaje ReleaseConf se puede enviar desde una NCG a una ACG. El mensaje de notificación Notify se puede utilizar para notificar cualquier evento específico. El mensaje de notificación se puede enviar por una ACG a una NCG, o enviarse por una NCG a una ACG. Cuando una NCG envía a una ACG, el mensaje de notificación se puede utilizar con una finalidad de supervisión para los servicios de transporte existentes. El mensaje de error de CSOP CSOPErr puede usarse para indicar cualquier condición de error de protocolo asociada con CSOP. El mensaje de sesión de CSOP CLOSE se puede utilizar para terminar una sesión CSOP.
La Figura 5 ilustra una forma de realización de una cabecera de mensaje CSOP 500, que puede incluirse en los mensajes CSOP intercambiados. El mensaje de CSOP puede comprender la cabecera de CSOP 500 seguida de un cuerpo de longitud variable, que puede incluir un conjunto de objetos que pueden ser obligatorios u opcionales, tal como se describe más adelante. La cabecera de mensaje de CSOP 500 puede comprender un campo de versión 502, un campo reservado 504, un campo de tipo de mensaje 506 y un campo de longitud de mensaje 508. El campo
de versión 502 puede incluir, aproximadamente, 3 bits e indicar un número de versión de CSOP. La versión actual puede ser la versión 1. El campo reservado 504 puede comprender aproximadamente 5 bits, que se pueden establecer a cero y no pueden utilizarse, p.ej., reservados para uso futuro. El campo de tipo de mensaje 506 puede incluir, aproximadamente, 8 bits, e indicar uno de los siguientes tipos de mensaje definidos utilizando el valor correspondiente, como sigue:
El campo de longitud de mensaje 508 puede comprender aproximadamente 16 bits e indicar la longitud total del mensaje de CSOP que incluye la cabecera del mensaje de CSOP 500, p.ej., en bytes.
A modo de ejemplo, la cabecera del mensaje de CSOP 500 puede ser parte de un mensaje de Demanda de CSOP enviado desde una ACG a una NCG, y ser parte de un mensaje de Respuesta de CSOP enviado, en respuesta, desde la NCG a la ACG. El mensaje de Demanda puede tener el siguiente formato:
<Mensaje de Demanda>::=<Cabecera común>
<Perfil de autenticación>
<Perfil de servicio>
[<Perfil PerformACG>]
[<Perfil de ancho de banda>]
<Perfil de modo de conectividad>
<Perfil de localización>
[<Perfil de protección>].
El mensaje de Respuesta puede tener el siguiente formato:
<Mensaje de respuesta>::=<Cabecera común>
<Perfil de autenticación>
<Ruta>
<VNT>
El mensaje de respuesta puede incluir cualquiera de <Ruta> o <VNT> dependiendo de la demanda de servicio original en el mensaje de Demanda. Los mensajes de CSOP también pueden incluir, además, un conjunto o perfiles definidos en el marco de CSO, que pueden ser entendidos por las capas/redes de transporte para proporcionar una demanda de servicio pertinente procedente de la ACG. Los objetos CSO en el mensaje de CSOP se pueden utilizar para transmitir información de perfil.
La Figura 6 ilustra una forma de realización de un objeto de perfil de autenticación 612, que puede incluirse en un mensaje de CSOP 600. La información de perfil de autenticación, en el objeto de perfil de autenticación 612, se puede proporcionar para garantizar intercambios de mensajes entre una ACG y una NCG, o entre una NCG y otra NCG (p.ej., en otro dominio). El mensaje de CSOP 600 puede comprender un campo de versión 602, un campo
reservado 604, un campo de tipo de mensaje 606 y un campo de longitud de mensaje 608, p.ej., en una cabecera de mensaje de CSOP, que puede estar configurada de forma prácticamente similar a los correspondientes componentes de la cabecera del mensaje de CSOP 500. El mensaje CSOP 600 puede comprender, además, uno o más objetos distintos 610 además del objeto de perfil de autenticación 612, tal como cualquiera de los objetos descritos más adelante. El objeto de perfil de autenticación 612 puede ser el último objeto en el mensaje de CSOP 600.
El objeto de perfil de autenticación 612 puede incluir un campo de clase de objeto de autenticación 614, un campo de longitud 616, un campo de sub-tipo 618, un campo reservado 620, un campo de Índice de Parámetro de Seguridad (SPI) 622 y un testigo informático denominado token 624. El campo de clase de objeto de autenticación 614 puede comprender un valor definido que indica que el objeto es un objeto de perfil de autenticación. El campo de longitud 616 puede indicar la longitud del objeto de perfil de autenticación 612, p.ej., en bytes. El campo de sub tipo 618 puede identificar el modo de autenticación y la entidad homóloga para la autenticación del mensaje (p.ej., ACG-NCG o NCG-NCG, respectivamente). El campo reservado 620 no puede usarse y todos los bits dentro del campo reservado 620 pueden establecerse a cero. El campo SPI 622 puede ser una cantidad de 4 bytes, por ejemplo, en el rango [0-4294967296], en donde el rango [0-255] puede estar reservado. Más concretamente, el SPI puede seleccionar el algoritmo de autenticación y la clave compartida utilizada para calcular el token 624. Con el fin de garantizar la interoperabilidad, una forma de puesta en práctica puede asociar cualquier valor de SPI con cualquier algoritmo de autenticación. Además, todas las realizaciones pueden poner en práctica un algoritmo de autenticación predeterminado, por ejemplo, el Algoritmo 1 de Hash Seguro (SHA1)-Código de Autenticación de Mensaje basado en Hash (HMAC). Están permitidos otros algoritmos.
El token 624 puede incluir la información para autenticar la entidad homóloga. La asociación de seguridad basada en clave compartida entre ACG y NCG, o entre una NCG y otra NCG, puede comprender un SPI, una clave compartida y un algoritmo de autenticación. La clave compartida puede incluir un valor arbitrario y puede tener aproximadamente 20 octetos (bytes) de longitud. La clave compartida puede configurarse de forma manual o mediante negociación dinámica. A modo de ejemplo, el valor del token se puede generar como sigue: Token = Primero (96, HMAC-SHA1 (Clave compartida, Datos del Mensaje)). Los datos del mensaje se pueden generar de la siguiente manera: Datos del mensaje = dirección IP de origen | dirección IP de destino | Cuerpo del mensaje de CSOP. La forma funcional "Primero(tamaño, entrada)" utilizada para generar el valor del token que indica la truncación de los datos de "entrada" de modo que solamente se sigan utilizando los primeros bits de "tamaño". El cuerpo del mensaje de CSOP utilizado para generar el valor del token puede comenzar desde el campo "Ver" hasta el valor de SPI inclusive del objeto de autenticación.
La ACG puede incluir el objeto de perfil de autenticación 612 en un mensaje de Demanda si la ACG tiene una asociación de seguridad basada en clave compartida con la NCG. La NCG puede incluir el objeto de perfil de autenticación 612 en un mensaje de Respuesta si la NCG recibe el objeto de perfil de autenticación 612 en un mensaje de Demanda correspondiente, y si la NCG tiene una asociación de seguridad basada en clave compartida con la ACG. La ACG o NCG que recibe el objeto de perfil de autenticación 612 puede verificar el valor de token en el campo de token 624 del objeto de perfil de autenticación 612. Si falla la autenticación, la NCG puede enviar un mensaje de Respuesta con el Código de Estado CSOP-AUTH-FAIL. Si la NCG no tiene una asociación de seguridad basada en clave compartida con la ACG, la NCG puede rechazar el mensaje de Demanda. La NCG puede, además, registrar tales eventos.
La Figura 7 ilustra una forma de realización de un objeto de perfil de servicio 700 que puede incluirse en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de perfil de servicio 700 se puede utilizar para indicar una demanda de servicio específico en un mensaje de Demanda. Los siguientes servicios pueden ser definidos por el objeto de perfil de servicio 700:
Reserva de ruta: Esta demanda de servicio puede requerir la reserva de ruta en una red de transporte que garantice el ancho de banda para la conexión.
Modificación de ruta: Esta demanda de servicio se puede utilizar para indicar modificaciones para una ruta existente que se ha reservado.
Estimación de ruta: Esta demanda de servicio se puede utilizar para una estimación de cálculo de ruta en una red de transporte sin compromiso real de reserva/asignación en la red de transporte.
Demanda de VNT: Esta demanda de servicio puede solicitar una topología de red virtual de la red de transporte para un conjunto determinado de orígenes y destinos.
El objeto de perfil de servicio 700 puede comprender un campo de tipo de servicio (S) 702, una pluralidad de indicadores 704, un campo reservado 706 y un número de identificación ID de demanda de servicio 708. El campo S 702 puede comprender, aproximadamente, 8 bits y puede incluir un valor para indicar un tipo de servicio como sigue: 0: Reserva de ruta
1: Modificación de ruta
2: Estimación de ruta
3: Demanda de VNT
4-255: Reservado.
Los indicadores 704 pueden incluir, aproximadamente, 16 bits y pueden definirse para diversos fines. El campo reservado 706 puede comprender aproximadamente 8 bits que se pueden establecer a cero en la transmisión e ignorarse en la recepción. El número de identificación ID de demanda de servicio 708 puede comprender aproximadamente 32 bits y puede incluir un valor que identifica, de forma única, la demanda de servicio. Cada vez que se envía una nueva demanda a una NCG, puede aumentarse el número de ID de demanda de servicio.
La Figura 8 ilustra una forma de realización de un objeto de perfil de rendimiento 800 que puede estar incluido en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de perfil de rendimiento 800 puede indicar el objetivo de rendimiento deseado asociado con una demanda de reserva. El objeto de perfil de rendimiento 800 puede comprender un campo de límite de retardo unidireccional máximo 802, un campo de límite de retardo de ida y vuelta máximo 804, un campo de límite de fluctuación de fase de retardo máximo 806 y un campo de tasa de pérdida de paquetes 808.
El campo de límite de retardo unidireccional máximo 802 puede comprender aproximadamente 32 bits e indicar el límite o contorno de retardo unidireccional máximo demandado, que puede codificarse en 32 bits en el formato de coma flotante del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) y expresarse en milisegundos. El campo de límite de retraso de ida y vuelta máximo 804 puede comprender aproximadamente 32 bits e indica el límite o contorno de retraso de ida y vuelta máximo solicitado, que puede codificarse en 32 bits en el formato de coma flotante del IEEE y expresarse en milisegundos. El campo de límite de fluctuación de fase de retardo máximo 806 puede incluir, aproximadamente, 32 bits e indicar el límite de fluctuación de fase de retardo máximo solicitado, que se puede codificar en 32 bits en el formato de coma flotante de IEEE y expresarse en milisegundos. El campo de tasa de pérdida de paquetes 808 puede comprender, aproximadamente, 32 bits e indicar la tasa de pérdida de paquetes solicitada, que se puede codificar en 32 bits en el formato de coma flotante de IEEE y expresarse en la forma de porcentaje.
La Figura 9 ilustra una forma de realización de un objeto de perfil de ancho de banda 900 que puede incluirse en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de perfil de ancho de banda 900 se puede utilizar para especificar el ancho de banda requerido para una ruta (por ejemplo, una ruta de etiqueta conmutada (LSP)). El objeto de perfil de ancho de banda 900 puede comprender un campo de capa de transporte 902, una pluralidad de indicadores 904, un bit indicador de ancho de banda asimétrico (A) 906, un campo reservado 908, un campo de flujo descendente de ancho de banda bidireccional 910 y un campo de ancho de banda de flujo ascendente 912.
El campo de capa de transporte 902 puede comprender, aproximadamente, 8 bits y puede establecerse en 0 para indicar que la capa de transporte no está especificada por ACG. En caso contrario, este campo se puede codificar en el formato de "Tipo de Codificación de LSP", tal como se define en el Protocolo de Reserva de Recursos (RSVP)-Ingeniería de tráfico (TE), y se puede utilizar por la ACG para especificar en qué capa de transporte establecer la ruta. Los indicadores 904 pueden comprender, aproximadamente, 16 bits y pueden definirse para diversos fines. El bit A 906 puede comprender aproximadamente 1 bit y se puede establecer para indicar que la conexión es bidireccional con ancho de banda asimétrico. El campo reservado 908 no puede usarse y puede establecerse a cero. El campo de flujo descendente de ancho de banda bidireccional 910 puede comprender aproximadamente 32 bits y puede indicar el ancho de banda de flujo descendente solicitado (es decir, desde el origen al destino) en el caso en que se establece el bit A 906 o la conexión es unidireccional, o puede indicar el ancho de banda bidireccional demandado en otros casos. El campo de ancho de banda de flujo ascendente 912 puede comprender, aproximadamente, 32 bits y puede indicar el ancho de banda de flujo ascendente demandado (es decir, desde el destino al origen). El campo de ancho de banda de flujo ascendente 912 puede incluirse, o usarse, solamente cuando se establece el bit A 906. El campo de flujo descendente de ancho de banda bidireccional 910, y el campo de ancho de banda de flujo ascendente 912, se pueden codificarse en 32 bits en el formato de coma flotante de IEEE y expresarse en bytes por segundo.
La Figura 10 ilustra una forma de realización de un objeto de perfil de modo de conectividad 1000 que puede incluirse en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de perfil de modo de conectividad 1000 se puede utilizar para especificar el tipo de conexión que se asocia con la demanda de ruta. Se definen los siguientes tipos de conectividad: P-P, P-MP, MP-MP y Anycast (Multi-destino). El objeto de perfil de modo de conectividad 1000 puede comprender un campo de conectividad (C) 1002, una pluralidad de indicadores 1004, un bit de direccionalidad (D) 1006 y un campo reservado 1008.
El campo C 1002 puede incluir, aproximadamente, 8 bits y puede comprender un valor que indica uno de los tipos de
conectividad de la forma siguiente:
0: P-P (punto a punto)
1: P-MP (punto a multipunto)
2: MP-MP (multipunto a multipunto)
3: Anycast (multidestino)
4-255: Reservado.
Los indicadores 1004 pueden incluir, aproximadamente, 16 bits y pueden definirse para diversos fines. El bit D 1006 puede comprender aproximadamente 1 bit que se puede establecer para indicar que la conexión es unidireccional. El campo reservado 1008 puede comprender, aproximadamente, 8 bits que pueden establecerse en cero en la transmisión e ignorarse en la recepción.
La Figura 11 ilustra una forma de realización de un objeto de perfil de localización 1100 que se puede incluir en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de perfil de localización 1100 se puede utilizar para indicar las direcciones IP de los recursos de capa de aplicación correspondientes (por ejemplo, servidores, almacenamiento, etc.), p.ej., para cada uno de los modos de conectividad definidos en el objeto de perfil de modo de conectividad 1000. Por ejemplo, el objeto de perfil de localización 1100 puede indicar uno de los Orígenes y Destinos para P-P, el Origen y el Conjunto de Destinos para P-MP, el Conjunto de Orígenes y el Destino para MP-P, el Conjunto de Orígenes y el Conjunto de Destinos para MP-MP y el Conjunto de Destinos Candidato para Anycast o Multi-Destino. El objeto de perfil de localización 1100 puede comprender un campo de perfil de localización (L) 1102, un campo de número de fuentes 1104, un campo de número de destinos 1106, una versión del campo de protocolo IP (V) 1108, una pluralidad de indicadores 1110, un campo reservado 1112, y uno de más TLVs opcionales 1114.
El campo L 1102 puede comprender, aproximadamente, 4 bits e indicar un valor basado en el modo, o tipo, de conectividad de la forma siguiente:
0: P-P
1: P-MP
2: MP-P
3: MP-MP
4: Anycast (Multi-destino)
5-15: Reservado.
El campo de número de fuentes 1104 puede comprender, aproximadamente, 8 bits e indicar el número de fuentes. El campo de número de destinos 1106 puede incluir, aproximadamente, 8 bits e indicar el número de destinos. El campo V 1108 puede incluir aproximadamente 2 bits e indicar la versión del protocolo IP. A modo de ejemplo, el campo V 1108 se puede establecer a cero en el caso de IP versión 4 (IPv4) o en 1 en el caso de IP versión 6 (IPv6). Los indicadores 1110 pueden comprender aproximadamente 4 bits y pueden definirse para diversos fines. El campo reservado 1112 puede incluir, aproximadamente, 16 bits que se pueden establecer a cero en la transmisión e ignorarse en la recepción. Los TLVs opcionales 1114 se pueden utilizar para indicar las direcciones IP asociadas con el perfil de localización, tal como se describe con más detalle a continuación.
La Figura 12 ilustra una forma de realización de un TLV opcional 1200 que se puede utilizar en el objeto de perfil de localización 1100, a modo de ejemplo, cuando el campo L 1102 se establece a 0 (p.ej., en el caso de P-P), y el campo V 1108 se establece a 0 (p.ej., en el caso de IPv4). El TLV opcional 1200 puede comprender un campo de dirección IPv4 de origen 1202 que indica la dirección IPv4 del origen, y un campo de dirección IPv4 de destino 1204 que indica la dirección IPv4 del destino. La Figura 13 ilustra una forma de realización de otro TLV opcional 1300 que se puede usar en el objeto de perfil de localización 1100, a modo de ejemplo, cuando el campo L 1102 se establece a 1 (p.ej., en el caso de P-MP), el campo de números de destino 1106 se establece en 4 y el campo V 1108 se establece a 0 (p.ej., en el caso de IPv4). El TLV opcional 1300 puede incluir un campo de dirección IPv4 de origen 1302 que indica la dirección IPv4 del origen, y cuatro campos de dirección IPv4 de destino 1304 que indican, cada uno, la dirección IPv4 de uno de los 4 destinos. De forma similar, otros TLVs opcionales 1114 se pueden utilizar para otros casos. En los casos en donde el campo V 1108 se establece a 1 (p.ej., en el caso de IPv4), cada dirección IPv6 puede incluir, de forma aproximada, 16 byfes.
La Figura 14 ilustra una forma de realización de un objeto de perfil de protección 1400 que puede incluirse en un
mensaje CSO, p.ej., el mensaje CSO 600. El objeto de perfil de protección 1400 se puede utilizar para indicar el nivel de protección requerido para una demanda de reserva de ruta. Los niveles de protección pueden incluir sin protección, protección 1+1 y protección compartida. En el caso de protección 1+1 y protección compartida, el objeto de perfil de protección 1400 puede indicar el diferencial de ruta de protección a partir de la ruta diseñada, tal como en términos de retardo, saltos operativos, distancia, etc. El objeto de perfil de protección 1400 puede comprender un campo de nivel de protección (P) 1402 y una pluralidad de indicadores 1404, que pueden incluir un bit de diversidad (S) de grupo de enlace de lista compartida (SRLG) 1406, un bit de diversidad de nodo (N) 1408, y un bit de diversidad de enlace (L) 1410. El objeto de perfil de protección 1400 puede incluir, además, un campo reservado 1412, y uno o más TLVs opcionales 1414.
El campo P 1402 puede comprender, aproximadamente, 8 bits e indicar un valor asociado con un nivel de protección como sigue:
0: Sin protección
1: 1+1
2: Protección compartida
3-255: Reservado.
Los indicadores 1404 pueden incluir, aproximadamente, 16 bits y se pueden utilizar para diferentes propósitos. Más concretamente, el bit S 1406 puede establecerse cuando se requiere que la ruta de protección sea SRLG diferente a partir de la ruta diseñada para una protección de tipo 1+1 o compartida. El bit N 1408 puede establecerse cuando se requiere que la ruta de protección sea un nodo diferente a partir de la ruta diseñada para una protección de tipo 1+1 o compartida. El bit L 1410 se puede establecer cuando se requiere que la ruta de protección sea un enlace diferente a partir de la ruta diseñada para una protección de tipo 1+1 o compartida. El campo reservado 1412 puede comprender, aproximadamente, 8 bits, que pueden establecerse en cero en la transmisión e ignorarse en la recepción. Los TLVs opcionales 1414 se pueden utilizar para indicar el diferencial de ruta de protección a partir de la ruta diseñada, p.ej., en términos de retardo, conteo de saltos operativos y distancia, tal como se describe a continuación. Los campos TLVs opcionales 1414 pueden llenarse cuando el campo P 1402 se establece para ser 1 o 2.
La Figura 15 ilustra una forma de realización de un TLV opcional 1500 que se puede usar en el objeto de perfil de protección 1400, a modo de ejemplo, cuando el campo P 1402 se establece a 1 o 2. El TLV opcional 1500 puede incluir un campo de diferencial de retardo 1502, un campo de diferencial de conteo de saltos operativos 1504, y un campo de diferencial de distancia 1506. El campo de diferencial de retardo 1502 puede comprender, aproximadamente, 32 bits, y puede codificarse en el formato de coma flotante de IEEE expresado en la forma de porcentaje. El campo de diferencial de retardo 1502 puede indicar el diferencial de retardo de la ruta de protección a partir de la ruta diseñada. Por ejemplo, un valor del 50 % puede indicar que la ruta de protección no puede tener más que el 50 % del retardo de la ruta diseñada. El campo de diferencial de conteo de saltos operativos 1504 puede comprender aproximadamente 32 bits y se puede codificarse en el formato de coma flotante de IEEE expresado en la forma de porcentaje. El campo de diferencial de conteo de saltos operativos 1504 puede indicar el diferencial de conteo de saltos operativos de la ruta de protección a partir de la ruta diseñada. El campo de diferencial de distancia 1506 puede incluir 32 bits aproximadamente, y se puede codificar en el formato de coma flotante de IEEE expresado en porcentaje. El campo de diferencial de distancia 1506 puede indicar el diferencial de distancia de la ruta de protección a partir de la ruta diseñada.
La Figura 16 ilustra una forma de realización de un objeto de ruta 1600 que puede incluirse en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de ruta 1600 se puede utilizar para proporcionar la información de ruta en respuesta a una estimación de ruta original, o una demanda de reserva/modificación de ruta en un mensaje de demanda. El objeto de ruta 1600 puede incluirse en un mensaje de Respuesta. El objeto de ruta 1600 puede comprender un campo de tipo de servicio (S) 1602, una pluralidad de indicadores 1604 que pueden incluir un bit de protección (P) 1606, un campo reservado 1608, un número de ID de demanda de servicio 1610 y al menos un TLV opcional 1612.
El campo S 1602 puede comprender, aproximadamente, 8 bits y tener un valor que indica un tipo de servicio, tal como sigue:
0: Reserva de ruta
1: Modificación de ruta
2: Estimación de ruta.
Los indicadores 1604 pueden incluir, aproximadamente, 16 bits, y se pueden utilizar para diferentes propósitos. Más
concretamente, el bit P 1606 se puede establecer para indicar que la ruta es una ruta de protección. El bit P 1606 se puede utilizar cuando el campo S 1602 se establece a 0 (para indicar un tipo de servicio de reserva de ruta). El campo reservado 1608 puede comprender 8 bits aproximadamente, que se pueden establecer a cero en la transmisión e ignorarse en la recepción. El número de ID de demanda de servicio 1610 puede comprender, aproximadamente, 32 bits e indicar un número de ID de demanda de servicio que se puede proporcionar en el objeto de perfil de servicio 700 en un mensaje de Demanda. El número de ID de demanda de servicio puede identificar la demanda de ruta original. El contenido del TLV opcional 1612 puede variar dependiendo del campo S 1602, tal como se describe a continuación.
La Figura 17 ilustra una forma de realización de un TLV 1700 opcional que se puede usar en el objeto de ruta 1600, para, a modo de ejemplo, cuando el campo S 1602 se establece a 0. El TLV opcional 1700 puede comprender un campo de identificador de ruta 1702, una dirección IPv4 de origen de aplicación 1704, una dirección IPv4 de origen de red 1706, una dirección IPv4 de destino de aplicación 1708, una dirección IPv4 de origen de red 1710 y un ancho de banda reservado 1712. El campo de identificador 1702 puede comprender aproximadamente 32 bits e identificar la ruta reservada en una red de transporte. El campo de identificador 1702 puede ser asignado por la NCG. El ancho de banda reservado 1712 puede indicar un ancho de banda para una ruta reservada.
La Figura 18 ilustra una forma de realización de otro TLV opcional 1800 que se puede utilizar en el objeto de ruta 1600, por ejemplo, cuando el campo S 1602 se establece a 1. El TLV opcional 1800 puede incluir un campo identificador de ruta 1802, una dirección IPv4 de origen de aplicación 1804, una dirección IPv4 de origen de red 1806, una dirección IPv4 de destino de aplicación 1808, una dirección IPv4 de origen de red 1810 y un ancho de banda modificado 1812. El campo de identificador 1802 puede configurarse, de forma prácticamente similar, al campo de identificador 1702. El ancho de banda modificado 1812 puede indicar un ancho de banda para una ruta modificada.
La Figura 19 ilustra una forma de realización de otro TLV opcional 1900 que se puede utilizar en el objeto de ruta 1600, por ejemplo, cuando el campo S 1602 se establece a 2. El TLV opcional 1900 puede incluir un campo de identificador de ruta 1902, una dirección IPv4 de origen de aplicación 1904, una dirección IPv4 de origen de red 1906, una dirección IPv4 de destino de aplicación 1908, una dirección IPv4 de origen de red 1910 y un ancho de banda estimado 1912. El campo de identificador 1902 puede configurarse, de forma prácticamente similar, al campo de identificador 1702. El ancho de banda modificado 1912 puede indicar un ancho de banda para una ruta estimada.
La Figura 20 ilustra una forma de realización de un objeto de VNT 2000 que puede incluirse en un mensaje CSO, p.ej., el mensaje CSO 600. El objeto de VNT 2000 se puede utilizar para proporcionar la abstracción de la topología en respuesta a una demanda de VNT original. La información relativa a la demanda de VNT original se puede transmitir a través del objeto de perfil de localización 1100, y el objeto de perfil de servicio 700, en un mensaje de Demanda. El objeto de VNT 2000 puede proporcionar un ID de demanda de servicio asociado con una demanda original e información de topología de red virtual (p.ej., el ancho de banda disponible) para cada perfil de localización solicitado. El perfil de localización proporcionado en la demanda de VNT original puede incluir direcciones IP de las localizaciones de aplicación. En respuesta a dicha demanda, el objeto de VNT 2000, en un mensaje de respuesta, puede proporcionar el ID de localización de aplicación original y su ID de nodo de red correspondiente (p.ej., direcciones IP) para permitir que la ACG consulte la información proporcionada por la NCG. El VNT se define aquí como el ancho de banda disponible para un par de nodos dado.
El objeto de VNT 2000 puede comprender un campo L 2002, un campo de número de orígenes 2004, un campo de número de destinos 2006, un campo V 2008, una pluralidad de indicadores 2010 y un campo reservado 2012, que puede configurarse, de forma prácticamente similar, al campo L 1102, el campo de número de orígenes 1104, el campo de número de destinos 1106, los indicadores 1110 y el campo reservado 1112, respectivamente. El objeto de VNT 2000 puede comprender, además, un número de ID de demanda de servicio 2014 y uno o más TLVs opcionales 2016. El número de ID de demanda de servicio 2014 puede comprender aproximadamente 32 bits, e indicar el valor del número de ID de demanda de servicio que identifica, de forma exclusiva, la demanda de servicio original que se proporciona en el objeto de perfil de servicio 700 en un mensaje de demanda. Los TLVs opcionales 2016 se pueden utilizar para proporcionar información detallada de VNT, tal como se describe con más detalle a continuación.
La Figura 21 ilustra una forma de realización de un TLV opcional 2100 que se puede utilizar en el objeto VNT 2000, por ejemplo, cuando el campo L 2002 se establece a 0 (p.ej., en el caso de P-P), y el campo V 2008 se establece a 0 (p.ej., en el caso de IPv4). El TLV opcional 2100 puede comprender un campo de dirección IPv4 de origen de aplicación 2102, un campo de dirección de IPv4 de origen de red 2104, un campo de dirección de IPv4 de destino de aplicación 2106, un campo de dirección de IPv4 de origen de red 2108 y un campo de ancho de banda disponible 2110. La Figura 22 ilustra una forma de realización de otro TLV opcional 2200 que se puede utilizar en el objeto de VNT 2000, por ejemplo, cuando el campo L 2002 se establece a 1 (p.ej., en el caso de P-MP), y el campo V 2008 se establece a 0 (p.ej., en el caso de IPv4). El TLV opcional 2200 puede incluir un campo de dirección IPv4 de primer origen de aplicación (n° 1) 2202, un campo de dirección IPv4 de primer origen de red (n° 1) 2204, un campo de dirección IPv4 de primer destino de aplicación (n° 1) 2206, un campo de dirección IPv4 de primer origen de red (n° 1) 2208, y un campo de primer campo de ancho de banda disponible 2210. Además, el TLV opcional 2200 puede
incluir un campo de dirección IPv4 de segundo origen de aplicación (n° 2) 2212, un campo de dirección IPv4 de segundo origen de red (n° 2) 2214, un campo de dirección IPv4 de segundo destino de aplicación (n° 2) 2216, un campo de dirección de IPv4 de segundo origen de red (n° 2) 2218 y un campo de segundo ancho de banda disponible 2220.
La Figura 23 ilustra una forma de realización de un intercambio de mensaje de CSOP 2300 que puede establecerse entre una ACG 2310 y una NCG 2320 usando la interfaz CSO y CSOP. La ACG 2310 puede enviar, en primer lugar, un mensaje de Demanda 2301, que puede incluir al menos algunos de los objetos y TLVs opcionales descritos anteriormente, a la NCG 2320. La NCG 2320 puede recibir y procesar el mensaje de demanda 2301 y a continuación, reenviar un mensaje de Respuesta 2302 a la ACG 2310. El mensaje de respuesta 2302 puede comprender al menos algunos de los objetos y TLVs opcionales, tal como se describió con anterioridad. En otras formas de realización, la ACG 2310 y la NCG 2320 pueden intercambiar otros mensajes de CSO, tales como un mensaje de Inicialización, un mensaje KeepAlive, un mensaje de Liberación, un mensaje de ReleaseConf., Un mensaje de Notificación, un mensaje de CSOPErr, un mensaje de CLOSE, o combinaciones de los mismos. En dichas formas de realización, el intercambio de mensaje de CSOP 2300 se puede iniciar por la ACG 2310 o la NCG 2320.
La Figura 24 ilustra una forma de realización de una unidad de red 2400, que puede ser cualquier dispositivo que transporte y procese datos a través de la red. La unidad de red 2400 puede incluir uno o más puertos o unidades de entrada 2410 acoplados a un receptor (Rx) 2412, con el fin de recibir señales y tramas/datos procedentes de otros componentes de la red. La unidad de red 2400 puede comprender una unidad lógica 2420 para determinar a qué componentes de red enviar datos. La unidad lógica 2420 se puede poner en práctica utilizando hardware, software o ambos. La unidad de red 2400 puede comprender, además, uno o más puertos o unidades de salida 2430 acoplados a un transmisor (Tx) 2432, con el fin de transmitir señales y tramas/datos a los otros componentes de red. El receptor 2412, la unidad lógica 2420 y el transmisor 2432 pueden, además, poner en práctica o soportar el sistema de CSOP 400 y el intercambio de mensaje de CSOP 2300. Los componentes de la unidad de red 2400 pueden estar dispuestos tal como se muestra en la Figura 24.
Los componentes de red descritos anteriormente se pueden poner en práctica en cualquier componente de red de propósito general, tal como un ordenador o componente de red con suficiente potencia de procesamiento, recursos de memoria y capacidad de rendimiento de red para la gestión de la carga de trabajo necesaria puesta sobre él. La Figura 25 ilustra un componente de red típico de uso general 2500 adecuado para realizar una o más formas de realización de los componentes aquí dados a conocer. El componente de red 2500 incluye un procesador 2502 (que puede denominarse como una unidad central de procesador o CPU), que está en comunicación con dispositivos de memoria que incluyen almacenamiento secundario 2504, memoria de solamente lectura (ROM) 2506, memoria RAM 2508, dispositivos de entrada/salida (I/O) 2510 y dispositivos de conectividad de red 2512. El procesador 2502 se puede poner en práctica como uno o más circuitos integrados de CPU, o puede ser parte de uno o más circuitos integrados específicos de la aplicación (ASICs).
El almacenamiento secundario 2504 está compuesto, típicamente, por una o más unidades de disco, o unidades de cinta, y se utiliza para una memorización no volátil de datos y como un dispositivo de almacenamiento de datos de desbordamiento si la memoria RAM 2508 no es lo suficientemente grande como para contener todos los datos de trabajo. El almacenamiento secundario 2504 se puede utilizar para memorizar programas que se cargan en la RAM 2508 cuando dichos programas se seleccionan para su ejecución. La memoria ROM 2506 se utiliza para memorizar instrucciones y tal vez datos que son objeto de lectura durante la ejecución del programa. La memoria ROM 2506 es un dispositivo de memoria no volátil que generalmente tiene una capacidad de memoria pequeña en relación con la mayor capacidad de memoria del almacenamiento secundario 2504. La memoria RAM 2508 se utiliza para memorizar datos volátiles y tal vez para almacenar instrucciones. El acceso tanto a la ROM 2506 como a la RAM 2508 suele ser más rápido que al almacenamiento secundario 2504.
Se da a conocer al menos una forma de realización 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 la técnica están dentro del alcance de la idea inventiva. Las formas de realización alternativas que resultan de combinar, integrar y/u omitir características de las formas de realización también están dentro del alcance de la idea inventiva. Cuando los rangos o limitaciones numéricas se establecen expresamente, dichos rangos o limitaciones expresos deben entenderse que incluyen rangos iterativos o limitaciones de magnitud similar que caen dentro de los rangos o limitaciones expresamente establecidos (p.ej., desde aproximadamente 1 a aproximadamente 10 incluye, 2, 3, 4, etc.; mayor que 0.10 incluye 0.11, 0.12, 0.13, etc.). Por ejemplo, cada vez que se da a conocer un rango numérico con un límite inferior, R1 y un límite superior, Ru, se divulga, específicamente, cualquier número que se encuentre dentro del rango. En particular, se dan a conocer, de forma específica, los siguientes números dentro del rango: R = R1 + k * (Ru - R1), en donde k es una variable que varía de 1 por ciento a 100 por ciento con un incremento de 1 por ciento, es decir, 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 rango numérico definido por dos números R, tal como se define con anterioridad, son también dados a conocer de forma específica. El uso del término "opcionalmente" con respecto a cualquier elemento de una reivindicación significa que el elemento es requerido o, como alternativa, el elemento no es requerido, ambas
alternativas caen dentro del alcance de la reivindicación. El uso de términos más amplios, tales como comprende, incluye y tiene, debe entenderse que proporciona soporte para términos más limitados, tales como que consiste en, que consiste esencialmente en, y que comprende prácticamente. En consecuencia, el alcance de protección no está limitado por la descripción expuesta anteriormente, sino que se define por las siguientes reivindicaciones. Todas y cada una de las reivindicaciones se incorporan como idea inventiva adicional en la especificación y las reivindicaciones son formas de realización de la presente invención. La discusión de una referencia en la idea inventiva no es una admisión de que es una técnica anterior, especialmente cualquier referencia que tenga una fecha de publicación posterior a la fecha de prioridad de esta solicitud.
Los presentes ejemplos deben considerarse como ilustrativos y no restrictivos, y la intención no debe limitarse a los detalles aquí proporcionados. A modo de ejemplo, los diversos elementos o componentes se pueden combinar, o integrarse, en otro sistema, o ciertas características se pueden omitir o no ponerse en práctica.
Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas formas de realización como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos sin desviarse del alcance de la presente invención. Otros elementos ilustrados o descritos como acoplados o directamente acoplados o que se comunican entre sí, pueden estar indirectamente acoplados o comunicarse a través de alguna interfaz, dispositivo o componente intermedio, ya sea de forma eléctrica, mecánica o de otra forma.
Claims (19)
1. Un aparato que comprende:
una pasarela (ACG) de optimización de estratos cruzados de aplicación, CSO, (314) acoplada a un estrato de aplicación (110, 210, 310, 410) que gestiona una pluralidad de servidores (112, 212, 312);
una pasarela CSO de red, NCG, (324) acoplada a un estrato de red (120, 220, 320, 420) que gestiona una pluralidad de nodos de red (122, 222, 322) y está configurada para comunicarse con la ACG (314) utilizando un Protocolo de CSO, CSOP; y
una interfaz CSO establecida entre la ACG (314) y la NCG (324);
en donde la ACG (314) está configurada para comunicarse con la NCG (324) por intermedio de la interfaz CSO y para proporcionar información de recursos de aplicación y limitaciones de acceso a entidades externas en el estrato de la red (120, 220, 320, 420);
en donde la NCG (324) está configurada para comunicarse con la ACG (314) por intermedio de la interfaz CSO, y para proporcionar información de recursos de red y limitaciones de acceso a entidades del estrato de aplicación; en donde se intercambian una pluralidad de mensajes de CSOP por intermedio de la interfaz CSO entre la ACG (314) y la NCG (324) para una asignación, un aprovisionamiento y una optimización comunes de recursos de red de aplicación.
2. El aparato según la reivindicación 1, en donde el CSOP proporciona medios para garantizar el intercambio de información necesaria para lograr la CSO al mismo tiempo que se evita el intercambio de información privada o segura que no está autorizada a otras entidades, redes o capas.
3. El aparato según la reivindicación 1, en donde los mensajes de CSOP comprenden un mensaje de Demanda que se utiliza desde la ACG (314) a la NCG (324) para solicitar una configuración de ruta, una estimación de ruta con o sin compromiso real de reserva/asignación, o una topología de red virtual.
4. El aparato según la reivindicación 3, en donde los mensajes de CSOP comprenden un mensaje de Respuesta que se utiliza desde la NCG (324) a la ACG (314) en respuesta al mensaje de Demanda.
5. El aparato según la reivindicación 1, en donde los mensajes de CSOP comprenden un mensaje de Liberación que se utiliza desde la ACG (314) a la NCG (324) para solicitar la liberación de una ruta existente.
6. El aparato según la reivindicación 5, en donde los mensajes de CSOP comprenden un mensaje de configuración de liberación, ReleaseConf, que se utiliza desde la NCG (324) a la ACG (314) en respuesta al mensaje de liberación para confirmar la liberación de la ruta existente.
7. El aparato según la reivindicación 1, en donde los mensajes de CSOP comprenden un mensaje de Notificación que se utiliza desde la ACG (314) a la NCG (324), o desde la NCG (324) a la ACG (314), para notificar un evento ocurrido; o
un mensaje de Notificación que se utiliza desde la NCG (324) a la ACG (314) para supervisar un servicio de transporte existente.
8. El aparato según la reivindicación 1, en donde los mensajes de CSOP comprenden un mensaje de error de CSOP, CSOPErr, que se utiliza para indicar una condición de error de protocolo que se asocia con CSOP; o los mensajes de CSOP comprenden un mensaje de Inicialización que se utiliza para iniciar una sesión de CSOP con un procedimiento de autenticación entre la ACG (314) y la NCG (324); o
los mensajes de CSOP comprenden un mensaje de mantenimiento activo, KeepAlive, que se utiliza para mantener una sesión de CSOP; o
un mensaje de sesión de CSOP, CLOSE, que se utiliza para finalizar una sesión de CSOP.
9. El aparato según la reivindicación 1, que comprende, además, una pluralidad de ACGs (314) que corresponde, cada una, a un centro de datos respectivo, o un respectivo servicio informático en la nube; o
que comprende una pluralidad de NCGs (324) correspondiendo, cada una, a una respectiva portadora o dominio de red del proveedor de servicios.
10. Un componente de red que comprende:
un receptor configurado para recibir un primer mensaje de protocolo CSOP de optimización de estrato cruzado, CSO, por intermedio de una interfaz CSO establecida entre un estrato de aplicación (110, 210, 310, 410) y un estrato de red (120, 220, 320, 420); y
un controlador de plano configurado para habilitar una CSO entre el estrato de aplicación (110, 210, 310, 410) y el estrato de red (120, 220, 320, 420) procesando el primer mensaje de CSOP para asignar, aprovisionar u optimizar un recurso de red de aplicación común; y
un transmisor configurado para enviar un segundo mensaje de CSOP por intermedio de la interfaz CSO en respuesta al primer mensaje de CSOP, o para la finalidad de CSO;
en donde el primer mensaje de CSOP, y el segundo mensaje de CSOP, proporcionan mecanismos de abstracción y resumen para garantizar el intercambio de información necesaria para lograr una CSO mientras se evitar la utilización compartida de información privada o segura, que no está autorizada a otras entidades, redes y/o estratos.
11. El componente de red según la reivindicación 10, en donde el primer mensaje de CSOP y el segundo mensaje de CSOP comprenden una cabecera de mensaje de CSOP con uno o más objetos, y en donde la cabecera de mensaje de CSOP comprende un campo de versión, un campo de tipo de mensaje y un campo de longitud de mensaje.
12. El componente de red según la reivindicación 11, en donde el campo de tipo de mensaje se establece a 1 para indicar un tipo de mensaje de Inicialización, a 2 para indicar un tipo de mensaje de mantenimiento activo, KeepAlive, 3 para indicar un tipo de mensaje de Demanda, 4 para indicar un tipo de mensaje de Respuesta, 5 para indicar un tipo de mensaje de Liberación, 6 para indicar un mensaje de configuración de liberación, ReleaseConf, 7 para indicar un mensaje de Notificación, 8 para indicar un mensaje de error de CSOP, CSOPErr, o 9 para indicar un mensaje de sesión de CSOP, CLOSE.
13. El componente de red según la reivindicación 11, en donde los objetos comprenden un objeto de perfil de autenticación, en el final de los objetos en el primer o segundo mensaje de CSOP, y en donde el objeto de perfil de autenticación comprende un campo de clase de objeto de autenticación, un campo de longitud, un campo de sub tipo, un campo de Índice de Parámetro de Seguridad, SPI, y un testigo informático denominado token.
14. El componente de red según la reivindicación 11, en donde los objetos comprenden un objeto de perfil de servicio que incluye un campo de tipo de servicio, S, una pluralidad de indicadores y un identificador, ID, de número de demanda de servicio, y en donde el campo S se establece a 0 para indicar una Reserva de ruta, 1 para indicar una Modificación de ruta, 2 para indicar una Estimación de ruta, o 3 para indicar una Demanda de topología de red virtual, VNT.
15. El componente de red según la reivindicación 11, en donde los objetos comprenden un objeto de perfil de rendimiento que comprende un campo de límite de retardo unidireccional máximo, un campo de límite de retardo de ida y vuelta máximo, un campo de límite de fluctuación de fase de retardo máximo y un campo de tasa de pérdida de paquetes; o
en donde los objetos comprenden un objeto de perfil de ancho de banda que comprende un campo de capa de transporte, una pluralidad de indicadores, un bit de indicador de ancho de banda asimétrico, A, un campo de flujo descendente de ancho de banda bidireccional, y un campo de ancho de banda de flujo ascendente; o
en donde los objetos comprenden un objeto de perfil de modo de conectividad que incluye un campo de conectividad, C, una pluralidad de indicadores, y un bit de direccionalidad, D, y en donde el campo C se establece a 0 para indicar una conectividad de punto a punto, P-P, 1 para indicar una conectividad de punto a multipunto, P-MP, 2 para indicar una conectividad de multipunto a multipunto, MP-MP, o 3 para indicar una conectividad ‘any-cast’ para múltiples destinos; o
en donde los objetos comprenden un objeto de perfil de localización que comprende un campo de perfil de localización, L, un campo de numero de orígenes, un campo de número de destinos, un campo de versión, V, del Protocolo Internet, IP, una pluralidad de indicadores, y uno o más Tipo/Longitud/Valores opcionales, TLVs, y en donde el campo L se establece a 0 para indicar una conectividad de punto a punto, P-P, 1 para indicar una conectividad de punto a multipunto, P-MP, 2 para indicar una conectividad de multipunto a punto, MP-P, 3 para indicar una conectividad de multipunto a multipunto, MP-MP, o 4 para indicar una conectividad ‘any-cast’ para múltiples destinos.
16. El componente de red según la reivindicación 11, en donde los objetos comprenden un objeto de perfil de protección que comprende un campo de nivel de protección, P, y una pluralidad de indicadores que incluyen un bit de diversidad S de grupo de enlaces de lista compartida, S, un grupo de enlace de lista compartida, SRLG, un bit de
diversidad de nodo, N, y un bit de diversidad de enlace, L, y uno o más Tipo/Longitud/Valores opcionales, TLVs, y en donde el campo P se establece a 0 para indicar Sin protección, 1 para indicar protección 1+1, o 2 para indicar Protección compartida.
17. El componente de red según la reivindicación 11, en donde los objetos comprenden un objeto de ruta que comprende un campo de tipo de servicio, S, una pluralidad de indicadores que incluyen un bit de protección, P, un número de identificador de demanda de servicio, ID, y al menos un Tipo/Longitud/Valor opcional, TLV, y en donde el campo S se establece a 0 para indicar una Reserva de ruta, 1 para indicar una Modificación de ruta, o 2 para indicar una Estimación de ruta.
18. El componente de red según la reivindicación 17, en donde un TLV opcional comprende un identificador de ruta, una versión 4 de Protocolo Internet de origen de aplicación, IP, dirección IPv4, una dirección IPv4 de origen de aplicación, una dirección IPv4 de origen de red, una dirección IPv4 de destino de aplicación, una dirección IPv4 de origen de red y un ancho de banda reservado; o
en donde un TLV opcional comprende un identificador de ruta, una dirección de versión 4, IPv4, de Protocolo Internet de origen de aplicación, IP, una dirección IPv4 de origen de aplicación, una dirección IPv4 de origen de red, una dirección IPv4 de destino de aplicación, una dirección IPv4 de origen de red y un ancho de banda modificado; o en donde un TLV opcional comprende un identificador de ruta, una dirección de versión 4, IPv4, de Protocolo Internet de origen de aplicación, IP, una dirección IPv4 de origen de aplicación, una dirección IPv4 de origen de red, una dirección IPv4 de destino de aplicación, una dirección IPv4 de origen de red y un ancho de banda estimado.
19. El componente de red según la reivindicación 11, en donde los objetos comprenden un objeto de topología de red virtual, VNT, que comprende un campo de perfil de localización, L, un campo de número de orígenes, un campo de número destinos, una versión, V, de Protocolo Internet, IP, una pluralidad de indicadores, un número de identificador de demanda de servicio, ID, y uno de Tipo/Longitud/Valores opcionales, TLVs, y en donde el campo L se establece a 0 para indicar una conectividad de punto a punto, P-P, 1 para indicar una conectividad de punto a multipunto, P-MP, 2 para indicar una conectividad de multipunto a punto, MP-P, 3 para indicar una conectividad de multipunto a multipunto, MP-MP, o 4 para indicar una conectividad ‘any-cast’ para múltiples destinos.
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US37736110P | 2010-08-26 | 2010-08-26 | |
US37735210P | 2010-08-26 | 2010-08-26 | |
US13/216,808 US9184983B2 (en) | 2010-08-26 | 2011-08-24 | Cross-stratum optimization protocol |
PCT/CN2011/079006 WO2012025063A1 (en) | 2010-08-26 | 2011-08-26 | Cross-stratum optimization protocol |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2746044T3 true ES2746044T3 (es) | 2020-03-04 |
Family
ID=45698612
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES11819436T Active ES2746922T3 (es) | 2010-08-26 | 2011-08-26 | Método y sistema para la optimización de estrato cruzado en redes de transporte-aplicación |
ES11819438T Active ES2746044T3 (es) | 2010-08-26 | 2011-08-26 | Protocolo de optimización de estratos cruzados |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES11819436T Active ES2746922T3 (es) | 2010-08-26 | 2011-08-26 | Método y sistema para la optimización de estrato cruzado en redes de transporte-aplicación |
Country Status (5)
Country | Link |
---|---|
US (4) | US9184983B2 (es) |
EP (3) | EP2569963B1 (es) |
CN (2) | CN103069783B (es) |
ES (2) | ES2746922T3 (es) |
WO (2) | WO2012025061A1 (es) |
Families Citing this family (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9727440B2 (en) * | 2007-06-22 | 2017-08-08 | Red Hat, Inc. | Automatic simulation of virtual machine performance |
US9354960B2 (en) | 2010-12-27 | 2016-05-31 | Red Hat, Inc. | Assigning virtual machines to business application service groups based on ranking of the virtual machines |
US9569330B2 (en) | 2007-06-22 | 2017-02-14 | Red Hat, Inc. | Performing dependency analysis on nodes of a business application service group |
US9477572B2 (en) | 2007-06-22 | 2016-10-25 | Red Hat, Inc. | Performing predictive modeling of virtual machine relationships |
US9678803B2 (en) | 2007-06-22 | 2017-06-13 | Red Hat, Inc. | Migration of network entities to a cloud infrastructure |
US9184983B2 (en) | 2010-08-26 | 2015-11-10 | Futurewei Technologies, Inc. | Cross-stratum optimization protocol |
ES2665571T3 (es) | 2011-06-17 | 2018-04-26 | Huawei Technologies Co., Ltd. | Control de servicio en nube informática y arquitectura de gestión extendida para conectarse al estrato de red |
US9432281B2 (en) * | 2011-08-25 | 2016-08-30 | Telefonaktiebolaget L M Ericsson (Publ) | Apparatus and method for a communication network |
US20130100803A1 (en) * | 2011-10-21 | 2013-04-25 | Qualcomm Incorporated | Application based bandwidth control for communication networks |
US9178715B2 (en) | 2012-10-01 | 2015-11-03 | International Business Machines Corporation | Providing services to virtual overlay network traffic |
US9276838B2 (en) * | 2012-10-05 | 2016-03-01 | Futurewei Technologies, Inc. | Software defined network virtualization utilizing service specific topology abstraction and interface |
US9165006B2 (en) | 2012-10-25 | 2015-10-20 | Blackberry Limited | Method and system for managing data storage and access on a client device |
US8943110B2 (en) * | 2012-10-25 | 2015-01-27 | Blackberry Limited | Method and system for managing data storage and access on a client device |
US9331952B2 (en) | 2013-01-02 | 2016-05-03 | International Business Machines Corporation | Modifying an assignment of nodes to roles in a computing environment |
EP2770431B1 (en) * | 2013-02-25 | 2017-01-04 | Telefonica S.A. | System and method to trigger cross-layer optimizations in a network |
US10536330B2 (en) * | 2013-04-03 | 2020-01-14 | Nokia Solutions And Networks Gmbh & Co. Kg | Highly dynamic authorisation of concurrent usage of separated controllers |
US9444689B2 (en) | 2013-06-03 | 2016-09-13 | Microsoft Technology Licensing, Llc | Dynamically migrating virtual machines and gateways |
US9532266B2 (en) | 2013-06-05 | 2016-12-27 | Huawei Technologies Co., Ltd. | Systems and methods for managing a wireless network |
US10034222B2 (en) | 2013-06-06 | 2018-07-24 | Huawei Technologies Co., Ltd. | System and method for mapping a service-level topology to a service-specific data plane logical topology |
US9307018B2 (en) * | 2013-09-11 | 2016-04-05 | International Business Machines Corporation | Workload deployment with real-time consideration of global network congestion |
EP3043515B1 (en) | 2013-10-18 | 2020-02-26 | Huawei Technologies Co., Ltd. | Method, controller, forwarding device, and network system for forwarding packets |
EP2887621B1 (en) | 2013-12-23 | 2016-06-22 | Telefonica S.A. | Method and apparatus for cross-stratum path computation in a network |
EP3089409A4 (en) * | 2013-12-26 | 2017-11-01 | Telefonica, S.A. | Method and system for restoring qos deteriorations in mpls networks |
US9277002B2 (en) * | 2014-01-09 | 2016-03-01 | International Business Machines Corporation | Physical resource management |
CN103825946B (zh) * | 2014-02-26 | 2017-02-15 | 南京邮电大学 | 一种基于网络感知的虚拟机放置方法 |
EP3425848B1 (en) * | 2014-03-05 | 2021-08-11 | Huawei Technologies Co., Ltd. | System and method for a customized fifth generation (5g) network |
US9363732B2 (en) * | 2014-06-24 | 2016-06-07 | Google Inc. | Mesh network commissioning |
DE102014219472A1 (de) * | 2014-09-25 | 2016-03-31 | Siemens Aktiengesellschaft | Verfahren zum Übertragen von Daten, Netzknoten und Netzwerk |
US20160119189A1 (en) * | 2014-10-28 | 2016-04-28 | Electronics And Telecommunications Research Institute | System for controlling carrier virtual network |
CN104360924B (zh) * | 2014-11-11 | 2017-07-04 | 上海天玑科技股份有限公司 | 一种在云数据中心环境下对虚拟机进行监控等级划分的方法 |
US9503228B2 (en) * | 2014-12-17 | 2016-11-22 | Ciena Corporation | Systems and methods to detect, diagnose, and mitigate issues in multi-layer networks |
WO2016161266A1 (en) | 2015-04-02 | 2016-10-06 | Google Inc. | Efficient network stack for wireless application protocols |
CN106302153B (zh) * | 2015-05-11 | 2020-02-07 | 中兴通讯股份有限公司 | 多域控制器、单域控制器、软件定义光网络***及方法 |
CN106714233B (zh) * | 2015-11-13 | 2020-08-25 | 华为技术有限公司 | 应用驱动网络的通信***、组网方法及控制器 |
US10200253B2 (en) | 2016-01-11 | 2019-02-05 | Futurewei Technologies, Inc. | Method of establishing relationships between sets of label switched paths and virtual networks |
CA3013516C (en) * | 2016-02-02 | 2021-06-29 | Shanghai Jiao Tong University | Information interaction mechanism and network transmission method in multimedia system |
CN111726347B (zh) * | 2016-02-26 | 2022-04-15 | 上海交通大学 | 一种多媒体***中信息交互机制及网络传输方法 |
JP6953738B2 (ja) | 2016-04-29 | 2021-10-27 | 富士通株式会社 | データセンターのネットワークにおいてクエリを実行する、コンピュータにより実施される方法 |
CN107666467B (zh) | 2016-07-29 | 2020-11-06 | 华为技术有限公司 | 资源分配方法、设备和*** |
US10785288B2 (en) * | 2017-02-22 | 2020-09-22 | International Business Machines Corporation | Deferential support of request driven cloud services |
US10630563B2 (en) * | 2017-02-23 | 2020-04-21 | Futurewei Technologies, Inc. | Application-driven cross-stratum resource monitoring |
US10462233B2 (en) * | 2018-01-23 | 2019-10-29 | Charter Communications Operating, Llc | Protocol for anycast based discovery of local resources |
US11329922B2 (en) * | 2019-12-31 | 2022-05-10 | Opanga Networks, Inc. | System and method for real-time mobile networks monitoring |
WO2024073143A1 (en) * | 2022-09-30 | 2024-04-04 | Comcast Cable Communications, Llc | Methods and apparatuses for handling end-to-end encryption |
Family Cites Families (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2332809A (en) * | 1997-12-24 | 1999-06-30 | Northern Telecom Ltd | Least cost routing |
GB2341059A (en) * | 1998-08-28 | 2000-03-01 | Nokia Oy Ab | Internet protocol flow detection |
US7478161B2 (en) | 1999-11-30 | 2009-01-13 | Microsoft Corporation | Network quality of service for qualitative applications |
US7072329B2 (en) | 2000-05-22 | 2006-07-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Combining differing transport technologies in a telecommunications system |
US7269185B2 (en) * | 2000-05-22 | 2007-09-11 | Nortel Networks Limited | Management and control of multi-layer networks |
AU2001291711A1 (en) * | 2000-08-02 | 2002-02-13 | Aepona Limited | Gateway to access network resources |
US20020188736A1 (en) * | 2001-06-11 | 2002-12-12 | Nokia Corporation | System and method for controlling terminal application usage through subscriber-application association |
US20030105799A1 (en) * | 2001-12-03 | 2003-06-05 | Avaz Networks, Inc. | Distributed processing architecture with scalable processing layers |
US20030200336A1 (en) * | 2002-02-15 | 2003-10-23 | Suparna Pal | Apparatus and method for the delivery of multiple sources of media content |
WO2004105354A2 (en) | 2003-05-23 | 2004-12-02 | Xius India Ltd. | System for a wireless intelligent services engine |
US7454489B2 (en) * | 2003-07-01 | 2008-11-18 | International Business Machines Corporation | System and method for accessing clusters of servers from the internet network |
CN1294728C (zh) * | 2004-08-05 | 2007-01-10 | 华为技术有限公司 | 边缘路由器提供服务质量保证的方法及*** |
US20060117020A1 (en) * | 2004-12-01 | 2006-06-01 | John Toebes | Arrangement for selecting a server to provide distributed services from among multiple servers based on a location of a client device |
US7870232B2 (en) | 2005-11-04 | 2011-01-11 | Intermatic Incorporated | Messaging in a home automation data transfer system |
US8184644B1 (en) * | 2006-02-28 | 2012-05-22 | Nortel Networks Limited | WiMAX R6 management protocol |
US7975036B2 (en) | 2006-05-11 | 2011-07-05 | The Mitre Corporation | Adaptive cross-layer cross-node optimization |
CN101163120B (zh) | 2006-10-13 | 2011-12-21 | 华为技术有限公司 | 协调不同业务提供者提供的业务的方法和*** |
WO2008130282A1 (en) * | 2007-04-19 | 2008-10-30 | Telefonaktiebolaget Lm Ericsson (Publ) | A method and arrangement for handling profiles in a multimedia service network |
US8510455B2 (en) * | 2007-04-30 | 2013-08-13 | Futurewei Technologies, Inc. | Method and apparatus for IP mobility management selection |
US8209738B2 (en) | 2007-05-31 | 2012-06-26 | The Board Of Trustees Of The University Of Illinois | Analysis of distributed policy rule-sets for compliance with global policy |
US8315243B2 (en) | 2007-08-14 | 2012-11-20 | Qualcomm Incorporated | Transport of PDCP control PDUs within MAC frames |
US7940655B2 (en) * | 2007-10-31 | 2011-05-10 | Futurewei Technologies, Inc. | Cross-layer optimization of VoIP services in advanced wireless networks |
US20090147684A1 (en) * | 2007-12-10 | 2009-06-11 | Reza Majidi-Ahy | Dynamic, integrated, multi-service network cross-layer optimization |
US8422397B2 (en) | 2007-12-28 | 2013-04-16 | Prodea Systems, Inc. | Method and apparatus for rapid session routing |
US8270952B2 (en) * | 2009-01-28 | 2012-09-18 | Headwater Partners I Llc | Open development system for access service providers |
CN101651658B (zh) | 2008-08-13 | 2012-01-11 | ***通信集团公司 | 无线Mesh网络中跨层联合优化的方法、装置及*** |
US8447881B2 (en) * | 2008-09-02 | 2013-05-21 | Microsoft Corporation | Load balancing for services |
US8306039B2 (en) | 2008-12-15 | 2012-11-06 | Ciena Corporation | Methods and systems for automatic transport path selection for multi-homed entities in stream control transmission protocol |
CN101854268B (zh) | 2009-04-04 | 2013-06-05 | 华为技术有限公司 | Ip网络性能测量、服务质量控制的方法、装置和*** |
JP4935911B2 (ja) | 2010-01-28 | 2012-05-23 | 沖電気工業株式会社 | 通信制御装置 |
US9253015B2 (en) | 2010-07-09 | 2016-02-02 | Attila Technologies, Llc | Transparent proxy architecture for multi-path data connections |
US9184983B2 (en) | 2010-08-26 | 2015-11-10 | Futurewei Technologies, Inc. | Cross-stratum optimization protocol |
EP2533162B1 (en) * | 2010-11-29 | 2022-10-26 | Hughes Network Systems, LLC | Proxy Server Apparatus for pre-fetching content using browser specifics |
-
2011
- 2011-08-24 US US13/216,808 patent/US9184983B2/en active Active
- 2011-08-24 US US13/216,805 patent/US8909786B2/en active Active
- 2011-08-26 CN CN201180040699.9A patent/CN103069783B/zh active Active
- 2011-08-26 WO PCT/CN2011/079001 patent/WO2012025061A1/en active Application Filing
- 2011-08-26 EP EP11819436.4A patent/EP2569963B1/en active Active
- 2011-08-26 EP EP11819438.0A patent/EP2569922B1/en active Active
- 2011-08-26 CN CN201180040637.8A patent/CN103109505B/zh active Active
- 2011-08-26 WO PCT/CN2011/079006 patent/WO2012025063A1/en active Application Filing
- 2011-08-26 ES ES11819436T patent/ES2746922T3/es active Active
- 2011-08-26 EP EP18210990.0A patent/EP3474521B1/en active Active
- 2011-08-26 ES ES11819438T patent/ES2746044T3/es active Active
-
2015
- 2015-10-06 US US14/876,313 patent/US10181977B2/en active Active
-
2018
- 2018-11-30 US US16/206,705 patent/US11316730B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US11316730B2 (en) | 2022-04-26 |
US20190097881A1 (en) | 2019-03-28 |
EP3474521A1 (en) | 2019-04-24 |
US20160028583A1 (en) | 2016-01-28 |
EP2569922B1 (en) | 2019-07-03 |
EP2569963A1 (en) | 2013-03-20 |
CN103109505A (zh) | 2013-05-15 |
CN103069783B (zh) | 2016-04-13 |
US20120054346A1 (en) | 2012-03-01 |
US9184983B2 (en) | 2015-11-10 |
EP2569963B1 (en) | 2019-07-31 |
US10181977B2 (en) | 2019-01-15 |
CN103109505B (zh) | 2015-11-25 |
EP3474521B1 (en) | 2023-03-29 |
EP2569922A4 (en) | 2013-08-07 |
WO2012025063A1 (en) | 2012-03-01 |
EP2569922A1 (en) | 2013-03-20 |
EP2569963A4 (en) | 2013-08-07 |
CN103069783A (zh) | 2013-04-24 |
US8909786B2 (en) | 2014-12-09 |
WO2012025061A1 (en) | 2012-03-01 |
ES2746922T3 (es) | 2020-03-09 |
US20120054347A1 (en) | 2012-03-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2746044T3 (es) | Protocolo de optimización de estratos cruzados | |
US11444872B2 (en) | Method and system of application-aware routing with crowdsourcing | |
US11374904B2 (en) | Method and system of a cloud-based multipath routing protocol | |
US11677720B2 (en) | Method and system of establishing a virtual private network in a cloud service for branch networking | |
US9979595B2 (en) | Subscriber management and network service integration for software-defined networks having centralized control | |
US9350661B2 (en) | Aggregation network with centralized control | |
EP2520052B1 (en) | Multicast traffic distribution on link-aggregate-group | |
US11621907B2 (en) | Enhanced two-way active measurement protocol | |
US9917871B2 (en) | Optimizing media bitrate with explicit network feedback on one client only | |
US7643467B2 (en) | Source-implemented constraint based routing with source routed protocol data units | |
US11483733B2 (en) | Transporting a multi-transport network context-identifier (MTNC- ID) across multiple domains | |
WO2016082516A1 (zh) | 一种链路捆绑方法及*** | |
US9025447B2 (en) | Service admission path control (SAPC) | |
Vanini et al. | A delay-aware num-driven framework with terminal-based mobility support for heterogeneous wireless multi-hop networks | |
Lilius et al. | Planning and Optimizing Mobile Backhaul for LTE |