ES2543921T3 - Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN - Google Patents

Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN Download PDF

Info

Publication number
ES2543921T3
ES2543921T3 ES12717100.7T ES12717100T ES2543921T3 ES 2543921 T3 ES2543921 T3 ES 2543921T3 ES 12717100 T ES12717100 T ES 12717100T ES 2543921 T3 ES2543921 T3 ES 2543921T3
Authority
ES
Spain
Prior art keywords
mpls
network
tunnel
service
packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES12717100.7T
Other languages
English (en)
Inventor
Juan Pedro Fernández-Palacios Giménez
Francisco Javier JIMÉNEZ CHICO
Óscar GONZÁLEZ DE DIOS
Alejandro TOVAR DE DUEÑAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonica SA
Original Assignee
Telefonica SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonica SA filed Critical Telefonica SA
Application granted granted Critical
Publication of ES2543921T3 publication Critical patent/ES2543921T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • 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/302—Route determination based on requested QoS
    • 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/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/62—Wavelength based

Landscapes

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

Abstract

Un procedimiento para mejorar la asignación de recursos de red en una red TISPAN, cuando un usuario de red solicita al menos un servicio de comunicación entre un nodo de acceso IP (22) de la red TISPAN y un nodo de destino, usando la red TISPAN una red de transporte MPLS basada en paquetes, comprendiendo el procedimiento las siguientes etapas: a) el subsistema de control de admisión de recursos, RACS (21, 51), de la red TISPAN genera una petición de conexión de flujo de paquetes por cada servicio de comunicación solicitado por el usuario, incluyendo la petición de conexión el nodo de destino, el ancho de banda necesario, la clase de servicio requerida y los requisitos de QoS, calidad de servicio, a continuación dicha petición de conexión es enviada (52) al nodo de acceso IP (22); b) cuando el nodo de acceso IP (22) recibe la petición, comprueba (53) si hay un túnel MPLS disponible con dicho nodo de destino y que soporte la clase de servicio requerida; c) si hay un túnel MPLS disponible con dicho nodo de destino y que soporte la clase de servicio requerida, el nodo de acceso IP (22) asigna dicha petición de conexión de flujo de paquetes al túnel MPLS disponible, y se establece la comunicación solicitada en la petición de conexión de flujo de paquetes usando dicho túnel MPLS y a continuación se avanza a la etapa g); d) si no hay ningún túnel MPLS disponible con dicho nodo de destino y que soporte la clase de servicio requerida, el nodo de acceso IP (22) envía una petición de túnel (b2; 56) a un nodo de la capa MPLS denominado gestor de cálculo de trayectorias MPLS (23; 57), la petición de túnel incluye el nodo de destino, el ancho de banda necesario, la clase de servicio requerida y los requisitos de QoS; e) el gestor de cálculo MPLS (23; 57), tras recibir la petición de túnel ejecuta un algoritmo de cálculo de trayectorias capaz de determinar el túnel por paquetes MPLS óptimo a través de la red por paquetes MPLS según el ancho de banda, la clase de servicio requerida e información acerca del uso de la red de paquetes; f) una vez calculado el túnel por paquetes MPLS, el gestor de cálculo de trayectorias MPLS (23; 57) informará (b3) al nodo de acceso IP (22) acerca de la trayectoria calculada y el nodo de acceso IP adoptará las acciones necesarias para establecer el nuevo túnel por paquetes MPLS entre el nodo de acceso IP (22) y el nodo de destino a través de la red MPLS (26; 55) y se establece la comunicación solicitada en la petición de conexión de flujo de paquetes usando dicho túnel MPLS; g) las características de tráfico de cada túnel MPLS son monitorizadas mediante un módulo de la red MPLS, denominado sistema de monitorización de tráfico (27; 50), si este nodo detecta que el volumen de tráfico de una clase de servicio dada en un túnel entre dos nodos de red está por encima de un umbral de capacidad predefinido, envía (c3) una alerta al gestor de cálculo de trayectorias MPLS (23; 57). h) tras recibir la alerta, el gestor de cálculo de trayectorias MPLS (23; 57) envía (c4) una petición de conexión de conmutación de circuitos a un módulo de una red de transporte basada en conmutación de circuitos GMPLS denominada gestor de cálculo de trayectorias GMPLS (24; 59), incluyendo la petición nodo fuente y de destino del túnel cuya capacidad se ha excedido, la cantidad de tráfico que el gestor de cálculo de trayectorias por paquetes MPLS (23; 57) quiere encaminar a través de la conexión de conmutación de circuitos, la clase de servicio requerida y los requisitos de QoS; i) cuando el gestor de cálculo de trayectorias GMPLS (24; 59) recibe la petición de conexión de conmutación de circuitos (24; 59), calcula la trayectoria de conmutación de circuitos optima según la cantidad de tráfico que el gestor de cálculo de trayectorias por paquetes MPLS quiere encaminar a través de la conexión de conmutación de circuitos, la clase de servicio e información acerca de la red de conmutación de circuitos GMPLS; j) una vez calculada la trayectoria de conmutación de circuitos, se establece la conexión de circuitos GMPLS entre los dos nodos usando dicha trayectoria de conmutación de circuitos óptima.

Description

5
10
15
20
25
30
35
40
45 E12717100
28-07-2015
DESCRIPCIÓN
Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN
Campo técnico
La presente invención se refiere, en general, a la asignación de recursos en redes de telecomunicaciones y, más particularmente, a un procedimiento para la asignación de recursos de red en actuales arquitecturas de servicio basadas en TISPAN (Telecomunicaciones y convergencia a Internet de Servicios y Protocolos de Redes Avanzadas).
Descripción de la técnica anterior
La invención propuesta pretende minimizar las inversiones de red requeridas para garantizar la QoS en redes convergentes que soportan cualquier clase de servicio. Hay dos requisitos principales para el control de QoS en redes convergentes que soportan cualquier clase de servicio:
•
Reconocimiento de aplicaciones: Las redes con reconocimiento de aplicaciones pueden reconocer el tráfico de diferentes aplicaciones y actuar en consecuencia. Se requiere reconocimiento de aplicaciones para garantizar la QoS adecuada para diferentes aplicaciones. Por ejemplo, P2P (mejor esfuerzo) y videoconferencia (tiempo real) soportados sobre una infraestructura común.
•
Mecanismos de control de QoS ajustables a escala: Los mecanismos de QoS (CAC, monitorización de rendimiento, encaminamiento diferenciado según QoS, etc.) usados en redes convergentes deberían poder gestionar un enorme volumen de tráfico procedente de diferentes usuarios y aplicaciones.
En la actualidad, un enfoque de red con reconocimiento de aplicaciones común se basa en la combinación de tecnologías existentes tales como TISPAN (http://www.etsi.org/tispan/) e IMS (subsistema multimedia IP).
Una NGN (redes de nueva generación) TISPAN es una red basada en paquetes que puede proporcionar servicios de telecomunicaciones y que puede hacer uso de múltiples tecnologías de transporte de banda ancha, con capacidad para QoS, y en la que las funciones relacionadas con los servicios son independientes de las tecnologías relacionadas con el transporte subyacentes. Las redes NGN incluyen una capa de control basada en la norma IMS (subsistema multimedia IP) definida por el proyecto 3GPP. Esta norma iba dirigida inicialmente sólo a redes móviles, pero más tarde se generalizó a otras tecnologías de red de acceso (fija, WLAN, etc.) aunque habitualmente dentro del ámbito de las telecomunicaciones.
El control de QoS de TISPAN se basa en las especificaciones IMS. Según el modelo TISPAN-IMS, el control de QoS se basa en los siguientes principios:
•
Se mantiene una visión centralizada de todos los recursos de red.
•
Las peticiones de recursos de red se aceptan o rechazan de manera individual y bajo demanda.
•
Las peticiones de recursos de red pueden realizarlas usuarios finales y proveedores de servicios de aplicaciones.
•
Los recursos se reservan una vez aceptada una petición y se liberan una vez concluida la sesión.
•
Las peticiones, la aceptación y reserva de recursos de red pueden gestionarse independientemente para los sentidos ascendente y descendente.
Según la definición de TISPAN, el subsistema de control de admisión de recursos, RACS (11), se encarga de garantizar la QoS requerida para cada conexión. En la figura 1 se muestra un diagrama de bloques del subsistema RACS (11) accediendo a una capa de transporte de la red de transporte MPLS (conmutación de etiquetas multiprotocolo) en una red NGN TISPAN actual, incluyendo los nombres de las diferentes interfaces.
•
La función de aplicación, AF (12), se comunica con el RACS para transferir información dinámica de servicios relacionada con la QoS.
•
Una entidad funcional centralizada (denominada SPDF, 13) decide la política apropiada para un servicio solicitado dado (modelo pasivo “push” de elección de políticas).
•
Una pasarela paquete a paquete para tráfico de medios en el plano del usuario (denominada C-BGF, 14) realiza funciones de ejecución de políticas bajo el control de la SPDF.
•
La función de control de recursos y admisión de acceso, A-RACF (15), comprueba si los recursos de QoS solicitados pueden ponerse a disposición para el acceso solicitado en cuestión (control de admisión). También garantiza que la petición de la SPDF corresponda con las políticas de acceso.
E12717100
28-07-2015
• La función de mejora de control de recursos, RCEF (16), realiza funciones de ejecución de políticas haciendo uso de las políticas definidas por el proveedor de acceso. Se supone que el nodo de acceso (17) es un equipo L2 que proporciona conectividad al equipo en las instalaciones del cliente (CPE, 18). La función de terminación de capa 2 (L2TF, 19) es el punto en el que termina la comunicación L2 con el CPE.
5 • El subsistema de acoplamiento a la red (NASS, 10) proporciona de manera dinámica direcciones IP y otros parámetros de configuración de terminales, así como autenticación y autorización (basándose en perfiles de usuario).
En TISPAN, las redes de transporte metropolitanas (también conocidas como redes metro) y las redes de transporte centrales deben soportar tráfico IP. Según este enfoque, las actuales soluciones con reconocimiento de aplicaciones
10 se basan normalmente en el interfuncionamiento entre mecanismos de control de QoS basados en IP y TISPAN. Sin embargo, el modelo actual no se aplica a otros modelos de red metro y núcleo basadas en otras tecnologías de transporte tales como OTN (red de transporte óptica), SDH (jerarquía digital sincrónica), MPLS-TP (protocolo de transporte) o OBS (conmutación de ráfagas ópticas) sobre WSON (redes ópticas de conmutación de longitudes de onda).
15 Las soluciones TISPAN sobre IP existentes presentan problemas de escalabilidad en términos de potencia de procesamiento y costes:
• Potencia de procesamiento: Las actuales redes con reconocimiento de aplicaciones, tales como TISPAN-IMS, realizan diferenciación de QoS por flujo de usuario. Según esto, tanto el C-BGF como el SPDF requieren un alto rendimiento y una alta potencia de procesamiento para la activación de políticas y gestionar un gran número de
20 flujos IP individuales. Este enfoque podría ser factible para volúmenes de tráfico reducidos como los generados por servicios de voz. Sin embargo, pueden aparecer ciertos problemas de escalabilidad para demandas de tráfico mayores generadas por aplicaciones de vídeo tales como videoconferencia, HDTV, UHDT, etc.
• Costes: Las actuales redes con reconocimiento de aplicaciones se basan normalmente en la conexión en red entre mecanismos de control de QoS basados en IP del estado de la técnica y TISPAN. Las redes principales IP 25 actuales se basan a menudo en una jerarquía de encaminadores interconectados a través de WDM (multiplexación por división de longitud de onda) punto a punto de alta velocidad. Esta arquitectura ha demostrado ser muy útil para proporcionar servicios IP para empresas y particulares, debido a la tremenda flexibilidad que proporcionan los encaminadores IP. Sin embargo, dado que el coste de la conmutación electrónica de paquetes depende directamente de la tasa de transmisión, las arquitecturas IP tradicionales
30 pueden presentar problemas de escalabilidad desde el punto de vista económico para demandas de tráfico más elevadas generadas por aplicaciones que consumen mucho ancho de banda tales como vídeo 3D, HDTV o UHDTV.
Szymaski et al, “NOBEL phase 2-Document Odiverable 02.2-“Report ou multilayer trafic engineering mechanisms for NOBEL solutions in medium and lorg term scenaries”, 27-11-2007, XP 60268452, mostraron un procedimiento para
35 mejorar la asignación de recursos de red en una red TISPAN usando una red de transporte basada en MPLS, donde se observa un LSP 10 usado por clase de servicio (CoS) y tráfico en el nivel de LSP con el fin de realizar el desvío o cambiar el ancho de banda del LSP.
Sumario de la invención
La presente invención usa un nuevo procedimiento y sistema que reducirá o eliminará las deficiencias de las 40 herramientas actuales.
La invención propuesta describe un nuevo procedimiento de conexión en red entre una arquitectura de capa de servicios basada en ETSI (Instituto Europeo de Normalización de las Telecomunicaciones) –TISPAN (Telecomunicaciones y convergencia a Internet de Servicios y Protocolos de Redes Avanzadas) y una arquitectura de red IETF (Grupo de Trabajo sobre Ingeniería de Internet)-GMPLS (Conmutación de etiquetas multiprotocolo
45 generalizada) de múltiples capas basada en la combinación de tecnologías de transporte por paquetes basada en MPLS (por ejemplo, IP/MPLS, OBS, MPLS-TP) y tecnologías de conmutación de circuitos basadas en GMPLS (por ejemplo, SDH, OTN WSON).
Particularmente, la invención propuesta define un procedimiento de comunicación entre arquitecturas de capa de servicios TISPAN y arquitecturas GMPLS de red de múltiples capas. Pretende minimizar el consumo total de
50 recursos de red de demandas de tráfico cada vez mayores con diferentes requisitos en cuanto a ancho de banda y QoS.
Los flujos de paquetes generados a partir de peticiones TISPAN aceptadas se asignan a un único túnel MPLS basado en paquetes (por ejemplo, MPLS-TP u OBS) según su destino y requisitos de QoS. Los túneles MPLS se clasifican según diferentes clases de servicio. Las características de tráfico de cada túnel MPLS se monitorizan para 55 garantizar que cumplen con los requisitos de QoS definidos para cada clase de servicio. Cuando el volumen de tráfico de una clase de servicio dada entre dos nodos de red supera un determinado umbral de capacidad, la capa
5
10
15
20
25
30
35
40
45 E12717100
28-07-2015
MPLS basada en paquetes solicita un enlace de conmutación de circuitos directo (por ejemplo, enlace de conmutación de longitudes de onda) entre estos nodos a la capa MPLS basada en circuitos, esta capa MPLS basada en circuitos puede ser, en una realización de la invención, una red óptica.
En un primer aspecto, se presenta un procedimiento según la reivindicación 1.
Finalmente, se presenta un programa informático que comprende medios de código de programa informático adaptados para realizar el procedimiento anteriormente descrito.
Para una comprensión más completa de la invención, sus objetivos y ventajas, puede hacerse referencia a la siguiente memoria descriptiva y a los dibujos adjuntos.
Breve descripción de los dibujos
Para completar la descripción y con el fin de proporcionar una mejor comprensión de la invención, se proporciona un juego de dibujos. Dichos dibujos forman parte integrante de la descripción e ilustran una realización preferente de la invención, que no debería interpretarse como que restringe el ámbito de la invención, sino más bien como un ejemplo de cómo puede realizarse la invención. Los dibujos comprenden las siguientes figuras:
La figura 1 representa un diagrama de bloques del subsistema de control de recursos y admisión en redes TISPAN actuales.
La figura 2 representa un diagrama de bloques de la arquitectura de sistema de una realización de la presente invención.
La figura 3 representa un esquema del procedimiento de provisión de servicios sin túnel MPLS disponible para la clase de servicio y destino dado en una realización de la presente invención.
La figura 4 representa un esquema del procedimiento de provisión de servicios habiéndose excedido el umbral de tráfico para la clase de servicio en una realización de la presente invención.
La figura 5 representa un flujo de trabajo del procedimiento global según una realización de la presente invención.
Los números y símbolos correspondientes en las diferentes figuras se refieren a partes correspondientes a menos que se indique lo contrario.
Descripción detallada de la invención
La invención propuesta define un procedimiento de comunicación entre arquitecturas de capa de servicios TISPAN y arquitecturas GMPLS de red de múltiples capas como WSON o de sublongitudes de onda, por ejemplo.
El procedimiento propuesto se explica a continuación:
1.-El RACS de TISPAN genera peticiones de conectividad de flujos de paquetes por cada servicio de usuario individual (voz, vídeo, datos, etc.) con requisitos de QoS (que dependerán del servicio requerido).
2.-Peticiones de servicio individuales con destino y requisitos de QoS similares se asignan a un único túnel MPLS basado en paquetes (por ejemplo, MPLS-TP u OBS). Los túneles MPLS se clasifican según diferentes clases de servicio.
3.-Las características de tráfico de cada túnel MPLS se monitorizan para garantizar que cumplen con los requisitos de QoS definidos para cada clase de servicio (véase la Tabla 1).
4.-Cuando el volumen de tráfico de una clase de servicio dada entre dos nodos de red (es decir en un determinado túnel MPLS) supera un determinado umbral de capacidad, la capa MPLS basada en paquetes solicita un enlace de conmutación de circuitos directo (por ejemplo, enlace de conmutación de longitudes de onda) entre estos nodos a la capa GMPLS basada en circuitos, para encaminar parte del tráfico para la clase de servicio dada.
5-El cálculo y asignación de trayectorias de circuitos se basa en algoritmos específicos por cada clase de servicio y la información proporcionada por los protocolos de encaminamiento CS GMPLS y las herramientas de monitorización de rendimiento óptico.
6.-Una vez calculada la trayectoria, se establece la conexión de circuitos por medio de protocolos de señalización CS GMPLS y parte del tráfico que se encaminaba a través del túnel de paquetes se encamina usando esta trayectoria CS de modo que no se excede el umbral de tráfico.
5
10
15
20
25
30
35
40
E12717100
28-07-2015
Tabla 1: Clasificación de aplicaciones según QoS
Probabilidad de bloqueo
Disponibilidad de red Tiempo de configuración Retardo máximo Retardo medio Tasa de pérdida de paquetes
Tiempo real
< 0,1% > 99,9% < 1 s < 50 ms * < 5 E-5
Flujo continuo
< 0,1% > 99% < 1 s < 1 s * < 1 E-3
Transacción
< 1% > 99% < 3 s < 1 s < 200 ms < 1 E-2
Mayor esfuerzo
* * * * * *
Para llevar a cabo el procedimiento tal como se describió inicialmente en el apartado anterior, tienen que definirse nuevas interacciones entre capas. Es decir, el procedimiento divulgado anteriormente tendrá lugar en las interfaces de comunicación entre diferentes elementos de los planos de control tanto de servicio como de red, particularmente Ca, Cb y Cc (líneas discontinuas en la figura 2). Los demás elementos de esta arquitectura quedan fuera del ámbito de la invención y pueden basarse en soluciones del estado de la técnica.
La figura 2 representa un diagrama de bloques de la arquitectura de sistema de una realización de la presente invención.
Interfaz Ca:
Al llegar una petición de servicio, el módulo A-RACF de TISPAN del subsistema de control de admisión de recursos RACS (21) comprueba el perfil de QoS del abonado y solicita conexiones de red individuales con requisitos de QoS específicos al nodo de acceso (22) de la red TISPAN (habitualmente un nodo de acceso IP). Las peticiones de la A-RACF de TISPAN se distribuyen a través de la interfaz Ca, que se basa en una extensión de la interfaz Re normalizada definida en ETSI TISPAN. En particular, la extensión propuesta en esta invención se basa en la introducción de una identificación de clase de servicio (CoS) en la petición de conexión de red. Una clase de servicio se definirá según parámetros de QoS específicos. La Tabla 1 muestra un ejemplo de clasificación de CoS (en la Tabla 1, los valores “clase de servicio” serán “tiempo real”, “flujo continuo” “transacción” o “mejor esfuerzo”).
Los mensajes distribuidos a través de la interfaz Ca (es decir, entre el subsistema RACS de TISPAN y el nodo de acceso IP (22)), para implementar el procedimiento divulgado anteriormente, son los siguientes:
oPetición_conexión: Este mensaje se envía, por cada servicio de usuario individual, por la A-RACF de TISPAN al nodo de acceso IP, con el fin de establecer una conexión de red MPLS según los siguientes parámetros (incluidos en el mensaje): nodo de destino, ancho de banda, clase de servicio requerida y requisitos de QoS (es decir, el valor solicitado del parámetro de QoS tal como retardo, fluctuación, probabilidad de bloqueo, disponibilidad de red, etc.).
oRetirada_conexión: Este mensaje se envía por la A-RACF de TISPAN para retirar una conexión por paquetes MPLS dada por cada servicio individual.
Obsérvese que esta funcionalidad del nodo de acceso IP extiende la funcionalidad del módulo RCEF definido por TISPAN con el fin de permitirle establecer e interrumpir de manera dinámica conexiones por paquetes MPLS (por ejemplo, MPLS-TP u OBS).
Interfaz Cb
El nodo de acceso IP asigna peticiones de servicio de usuario individuales con destino y requisitos de QoS similares a un único túnel de paquetes MPLS. Tal como se muestra en la figura 3, si no hay disponible ningún túnel con el destino y las características de QoS requeridas, a continuación el nodo de acceso IP envía una petición de túnel a un nodo de la capa de transporte de paquetes MPLS denominado gestor de cálculo de trayectorias MPLS (23) o nodo de computación de caminos de paquetes MPLS a través de la interfaz Cb. Los mensajes Cb que recibe el gestor de cálculo de trayectorias MPLS son los siguientes:
oPetición_conexión: Este mensaje lo envía el nodo de acceso IP para establecer un nuevo túnel de paquetes MPLS con una clase de servicio según los siguientes parámetros (incluidos en el mensaje): nodo de destino, ancho de banda, clase de servicio requerida y requisitos de QoS. Con esta información, el gestor de cálculo de trayectorias MPLS calculará la mejor trayectoria (túnel) para asignar a la conexión, informará al nodo de acceso IP acerca de la trayectoria calculada y el nodo de acceso IP adoptará las acciones necesarias para establecer el nuevo túnel de paquetes MPLS entre el nodo de acceso y el nodo de destino a través de la red MPLS (26).
oRetirada_conexión: Este mensaje se envía para retirar un túnel de paquetes MPLS dado. 5
5
10
15
20
25
30
35
40
45
50 E12717100
28-07-2015
Interfaz Cc
Cuando el volumen de tráfico de una clase de servicio dada entre dos nodos de red está por encima de un determinado umbral de capacidad, el gestor de cálculo de trayectorias MPLS solicita un enlace de conmutación de circuitos directo entre estos nodos a la capa GMPLS de circuitos a través de la interfaz Cc (entre el gestor de cálculo de trayectorias MPLS y un nodo de la capa GMPLS denominada gestor de cálculo de trayectorias GMPLS o nodo de computación de trayectorias, de conmutación de circuitos, GMPLS(24)). Los mensajes Cc que recibe el gestor de cálculo de trayectorias GMPLS son los siguientes:
oPetición_conexión: Este mensaje lo envía el gestor de cálculo de trayectorias MPLS para establecer una conexión de conmutación de circuitos (por ejemplo, a través de una WSON) según los siguientes parámetros (incluidos en el mensaje): nodo fuente y de destino, clase de servicio requerida, requisitos de QoS y cantidad de tráfico que el gestor de cálculo de trayectorias por paquetes MPLS quiere encaminar a través de la conexión de conmutación de circuitos. Con esta información, el gestor de cálculo de trayectorias GMPLS adoptará las acciones necesarias para establecer la nueva trayectoria CS.
oRetirada_conexión: Este mensaje se envía para retirar una conexión de conmutación de circuitos dada.
Como realización alternativa de la invención, los mensajes de petición de conexión en estas interfaces sólo incluyen la clase de servicio y no los requisitos de QoS. En otra realización alternativa, el mensaje de petición de conexión incluye sólo los requisitos de QoS y no la clase de servicio, y el nodo que recibe la petición de conexión, comprueba en la base de datos la clase de servicio que corresponde a los requisitos de QoS dados.
Dependiendo del estado de la red, pueden darse tres situaciones:
a) Petición de servicio entrante con túnel MPLS disponible con el nodo de destino deseado para la clase de servicio solicitada. Es el caso más simple. Después de que el nodo de acceso haya recibido la petición de conexión del RACS de TISPAN, asigna la conexión de usuario entrante al túnel de paquetes MPLS disponible. El proceso sigue las etapas siguientes:
a1.-El RACS de TISPAN genera peticiones de conexión de flujo de paquetes por cada servicio de usuario individual (voz, vídeo, datos, etc.) y las envía al nodo de acceso IP a través de la interfaz Ca.
a2.-El nodo de acceso comprueba que hay un túnel con destino y requisitos de QoS similares, de modo que la petición de servicio individual entrante se asigna al túnel MPLS basado en paquetes (por ejemplo, MPLS-TP u OBS) e informa al nodo de acceso IP.
b) Petición de servicio entrante sin túnel MPLS disponible con el nodo de destino deseado para la clase de servicio solicitada (véase la figura 3). En este caso, el proceso sigue las etapas siguientes:
b1.-El RCAS de TISPAN genera peticiones de conexión de flujo de paquetes por cada servicio de usuario individual (voz, vídeo, datos, etc.) y las envía al nodo de acceso IP.
b2.-El nodo de acceso IP describe que no hay ningún túnel MPLS disponible con la correspondiente clase de servicio para el destino solicitado, de modo que se solicita uno nuevo al gestor de cálculo de trayectorias MPLS (23). El procedimiento seguido para la petición de túnel de paquetes se describe a continuación:
b21.-Tras recibir la petición de túnel de paquetes MPLS enviada por el nodo de acceso IP a través de Cb, el gestor de cálculo de trayectorias MPLS (23) ejecuta un algoritmo de cálculo de trayectorias que puede determinar la trayectoria óptica sobre la capa de paquetes MPLS según:
•
Los requisitos de cada petición en cuanto a ancho de banda, destino y QoS.
•
La información acerca del uso de red proporcionada por nodos de la red de transporte por paquetes MPLS, tal como:
•
El protocolo de encaminamiento MPLS. Los protocolos de encaminamiento pueden basarse en soluciones ya conocidas del estado de la técnica.
•
El sistema de monitorización de tráfico (27). Las características de tráfico de cada túnel MPLS por el que cruza el plano de datos por paquetes MPLS se monitorizan por medio de un sistema de monitorización de tráfico (TMS). Esta información se envía al gestor de cálculo de trayectorias por paquetes MPLS para garantizar que cumplen los requisitos de QoS definidos para cada clase de servicio. El TMS puede basarse en herramientas de monitorización de tráfico del estado de la técnica.
b3) El gestor de cálculo de trayectorias por paquetes MPLS informa al nodo de acceso IP acerca de la trayectoria calculada y establece el túnel por medio de protocolos de señalización MPLS del estado de la técnica.
5
10
15
20
25
30
35
40
45
50
55 E12717100
28-07-2015
c) Umbral de tráfico excedido para la clase de servicio (véase la figura 4). En este caso, el túnel de paquetes MPLS está disponible para el destino solicitado y la clase de servicio solicitada, pero la asignación de la conexión entrante hace que el volumen de tráfico de la clase de servicio en cuestión entre dos nodos supere un umbral de capacidad predefinido. Debido a esto, el gestor de cálculo de trayectorias MPLS solicita un enlace de conmutación de circuitos directo entre estos nodos a la capa GMPLS de circuitos (que puede ser, por ejemplo, un subsistema WSON) a través de Cc. El proceso sigue las etapas siguientes:
c1.-El RCAS de TISPAN genera peticiones de conexión de flujo de paquetes por cada servicio de usuario individual (voz, vídeo, datos, etc.) y las envía al nodo de acceso IP de MPLS.
c2.-El nodo de acceso IP comprueba que hay un túnel con destino y requisitos de QoS similares, de modo que la petición de servicio individual se asigna al túnel MPLS basado en paquetes (por ejemplo, MPLS-TP u OBS) e informa a la red MPLS (26).
c3.-El TMS (27) informa al gestor de cálculo de trayectorias MPLS (23) que el tráfico del túnel MPLS excede el umbral de tráfico para dicha clase de servicio en el túnel.
c4-El gestor de cálculo de trayectorias MPLS (23) envía peticiones de conexión a un nodo del subsistema CS GMPLS, el gestor de cálculo de trayectorias de conmutación de circuitos (24). Cuando este nodo recibe las peticiones de conexión, calcula la mejor trayectoria de conmutación para las peticiones de conexión. El cálculo de trayectorias de circuitos se basa en algoritmos específicos por cada clase de servicio y en la información proporcionada por los protocolos de encaminamiento GMPLS del estado de la técnica y las herramientas de monitorización de rendimiento (29) (herramientas de monitorización de rendimiento óptico, si la red de transporte CS GMPLS es óptica) de la red de transporte GMPLS (28). Una vez calculada la trayectoria, se informa a la red de transporte GMPLS y ésta establece el circuito por medio de protocolos de señalización GMPLS del estado de la técnica y el tráfico indicado en las peticiones de conexión se transfiere desde el túnel a dicha conexión de circuitos establecida. Las características de tráfico de cada trayectoria de circuitos CS por la que cruza el plano de datos por paquetes CS se monitorizan por medio de las herramientas de monitorización de rendimiento que informan al gestor de cálculo de trayectorias CS.
En resumen, el flujo de trabajo de procedimiento global es el siguiente (figura 5).
El subsistema RACS de TISPAN (51) envía una petición de conexión individual (52) al nodo de acceso IP. La petición incluye el nodo de destino de la conexión, el ancho de banda, la clase de servicio y los parámetros de QoS.
El nodo de acceso IP comprueba si hay alguna conexión disponible con dicho destino y que soporte la clase de servicio solicitada (53).
Si hay un túnel disponible con dicho destino y que soporte la clase de servicio solicitada, se asigna dicho túnel a la conexión y se informa (54) a la red MPLS (55) de modo que se establece la conexión.
En caso contrario, se solicita (56) un nuevo túnel de paquetes MPLS al gestor de cálculo de trayectorias MPLS (57) de la red de transporte MPLS. La petición incluye nodo de destino de la conexión, ancho de banda, clase de servicio y parámetros de QoS. Una vez hallada la trayectoria MPLS, se informa (58) a la red MPLS de modo que se establece el túnel por medio de protocolos de señalización MPLS.
Si se excede el umbral de tráfico para una clase de servicio entre dos nodos, el TMS (50) informa al gestor de cálculo de trayectorias MPLS (57) y éste pide un enlace de conmutación de circuitos directo entre los dos nodos al gestor de cálculo de trayectorias GMPLS (59).
El sistema formado por el gestor de cálculo de trayectorias por paquetes MPLS y el gestor de cálculo de trayectorias CS se denomina gestor de cálculo de trayectorias con reconocimiento de QoS (25).
La invención propuesta pretende cumplir con los requisitos en cuanto a funcionamiento automático, dinamismo y garantía de QoS de una arquitectura de servicios TISPAN-IMS al tiempo que se optimizan los costes de red totales usando y optimizando una combinación de tecnologías de transporte de conmutación de paquetes MPLS (por ejemplo MPLS-TP u OBS) y tecnologías de transporte de conmutación de circuitos (por ejemplo, WSON) en lugar de las soluciones actuales basadas en costosas tecnologías de conmutación basadas en IP. La novedad de la invención reside en la extensión del dinamismo mencionado y la garantía de QoS desde la red de acceso (ya prevista por TISPAN) hasta la red central o núcleo (que no se tenía en cuenta hasta el momento). Las nuevas interfaces propuestas posibilitan el control de extremo a extremo de QoS.
Aunque la presente invención se ha descrito con referencia a realizaciones específicas, los expertos en la técnica deberían entender que pueden realizarse en las mismas los anteriores y otros diversos cambios, omisiones y adiciones en forma y detalle sin alejarse del espíritu y alcance de la invención tal como se define en las siguientes reivindicaciones.

Claims (11)

  1. REIVINDICACIONES
    1. Un procedimiento para mejorar la asignación de recursos de red en una red TISPAN, cuando un usuario de red solicita al menos un servicio de comunicación entre un nodo de acceso IP (22) de la red TISPAN y un nodo de destino, usando la red TISPAN una red de transporte MPLS basada en paquetes, comprendiendo el
    5 procedimiento las siguientes etapas:
    a) el subsistema de control de admisión de recursos, RACS (21, 51), de la red TISPAN genera una petición de conexión de flujo de paquetes por cada servicio de comunicación solicitado por el usuario, incluyendo la petición de conexión el nodo de destino, el ancho de banda necesario, la clase de servicio requerida y los requisitos de QoS, calidad de servicio, a continuación dicha petición de conexión es enviada (52) al nodo de
    10 acceso IP (22);
    b) cuando el nodo de acceso IP (22) recibe la petición, comprueba (53) si hay un túnel MPLS disponible con dicho nodo de destino y que soporte la clase de servicio requerida;
    c) si hay un túnel MPLS disponible con dicho nodo de destino y que soporte la clase de servicio requerida, el nodo de acceso IP (22) asigna dicha petición de conexión de flujo de paquetes al túnel MPLS disponible, y se
    15 establece la comunicación solicitada en la petición de conexión de flujo de paquetes usando dicho túnel MPLS y a continuación se avanza a la etapa g);
    d) si no hay ningún túnel MPLS disponible con dicho nodo de destino y que soporte la clase de servicio requerida, el nodo de acceso IP (22) envía una petición de túnel (b2; 56) a un nodo de la capa MPLS denominado gestor de cálculo de trayectorias MPLS (23; 57), la petición de túnel incluye el nodo de destino,
    20 el ancho de banda necesario, la clase de servicio requerida y los requisitos de QoS;
    e) el gestor de cálculo MPLS (23; 57), tras recibir la petición de túnel ejecuta un algoritmo de cálculo de trayectorias capaz de determinar el túnel por paquetes MPLS óptimo a través de la red por paquetes MPLS según el ancho de banda, la clase de servicio requerida e información acerca del uso de la red de paquetes;
    f) una vez calculado el túnel por paquetes MPLS, el gestor de cálculo de trayectorias MPLS (23; 57) informará
    25 (b3) al nodo de acceso IP (22) acerca de la trayectoria calculada y el nodo de acceso IP adoptará las acciones necesarias para establecer el nuevo túnel por paquetes MPLS entre el nodo de acceso IP (22) y el nodo de destino a través de la red MPLS (26; 55) y se establece la comunicación solicitada en la petición de conexión de flujo de paquetes usando dicho túnel MPLS;
    g) las características de tráfico de cada túnel MPLS son monitorizadas mediante un módulo de la red MPLS,
    30 denominado sistema de monitorización de tráfico (27; 50), si este nodo detecta que el volumen de tráfico de una clase de servicio dada en un túnel entre dos nodos de red está por encima de un umbral de capacidad predefinido, envía (c3) una alerta al gestor de cálculo de trayectorias MPLS (23; 57).
    h) tras recibir la alerta, el gestor de cálculo de trayectorias MPLS (23; 57) envía (c4) una petición de conexión de conmutación de circuitos a un módulo de una red de transporte basada en conmutación de circuitos
    35 GMPLS denominada gestor de cálculo de trayectorias GMPLS (24; 59), incluyendo la petición nodo fuente y de destino del túnel cuya capacidad se ha excedido, la cantidad de tráfico que el gestor de cálculo de trayectorias por paquetes MPLS (23; 57) quiere encaminar a través de la conexión de conmutación de circuitos, la clase de servicio requerida y los requisitos de QoS;
    i) cuando el gestor de cálculo de trayectorias GMPLS (24; 59) recibe la petición de conexión de conmutación
    40 de circuitos (24; 59), calcula la trayectoria de conmutación de circuitos optima según la cantidad de tráfico que el gestor de cálculo de trayectorias por paquetes MPLS quiere encaminar a través de la conexión de conmutación de circuitos, la clase de servicio e información acerca de la red de conmutación de circuitos GMPLS;
    j) una vez calculada la trayectoria de conmutación de circuitos, se establece la conexión de circuitos GMPLS 45 entre los dos nodos usando dicha trayectoria de conmutación de circuitos óptima.
  2. 2.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la red TISPAN es una red TISPAN de nueva generación, NGN.
  3. 3.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que los parámetros de QoS incluidos
    en la petición de conexión son seleccionados del grupo que comprende retardo, fluctuación, probabilidad de 50 bloqueo, disponibilidad de red, tiempo de configuración, retardo medio y tasa de pérdida de paquetes.
  4. 4.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el servicio solicitado es transmisión de datos, de voz o de vídeo.
  5. 5.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la clase de servicio puede ser de
    8
    tiempo real o de flujo continuo o de transacción o de mayor esfuerzo.
  6. 6.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la información acerca del uso de la red por paquetes comprende información acerca del tráfico y el protocolo de encaminamiento de la red MPLS.
  7. 7.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la información acerca de la
    5 información de uso de la red GMPLS comprende información acerca del tráfico y el protocolo de encaminamiento de la red GMPLS proporcionada por nodos de la red de transporte GMPLS.
  8. 8.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que el umbral de capacidad predefinido depende de la clase de servicio de las comunicaciones asignadas al túnel.
  9. 9.
    Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que la red de transporte basada en
    10 conmutación de circuitos GMPLS y/o las tecnologías de transporte basadas en paquetes MPLS son tecnologías de transporte ópticas.
  10. 10. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que las tecnologías de transporte basadas en conmutación de circuitos GMPLS pueden ser tecnologías de redes ópticas de conmutación de longitudes de onda, WSON.
    15 11. Un procedimiento según cualquiera de las reivindicaciones anteriores, en el que las tecnologías de transporte basadas en paquetes MPLS pueden ser tecnologías MPLS-TP o de conmutación de ráfagas ópticas, OBS.
  11. 12. Un programa informático que comprende medios de código de programa informático adaptados para realizar el procedimiento según cualquiera de las reivindicaciones 1 a 10, cuando dicho programa es ejecutado en un ordenador, un procesador de señal digital, una disposición de puertas programables en campo, un circuito
    20 integrado de aplicación específica, un microprocesador, un microcontrolador, o cualquier otra forma de hardware programable.
    9
ES12717100.7T 2011-04-19 2012-04-19 Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN Active ES2543921T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
ES201130632A ES2411755B1 (es) 2011-04-19 2011-04-19 Método para la asignación de recursos de red en arquitecturas de servicios basadas en tispan
ES201130632P 2011-04-19
PCT/EP2012/057173 WO2012143450A1 (en) 2011-04-19 2012-04-19 Method for network resources allocation in tispan based service architectures

Publications (1)

Publication Number Publication Date
ES2543921T3 true ES2543921T3 (es) 2015-08-25

Family

ID=46001232

Family Applications (2)

Application Number Title Priority Date Filing Date
ES201130632A Withdrawn - After Issue ES2411755B1 (es) 2011-04-19 2011-04-19 Método para la asignación de recursos de red en arquitecturas de servicios basadas en tispan
ES12717100.7T Active ES2543921T3 (es) 2011-04-19 2012-04-19 Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES201130632A Withdrawn - After Issue ES2411755B1 (es) 2011-04-19 2011-04-19 Método para la asignación de recursos de red en arquitecturas de servicios basadas en tispan

Country Status (4)

Country Link
US (1) US20140293778A1 (es)
EP (1) EP2700204B1 (es)
ES (2) ES2411755B1 (es)
WO (1) WO2012143450A1 (es)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013161213A1 (ja) * 2012-04-27 2013-10-31 日本電気株式会社 通信システム、及び、通信制御方法
EP2728828A1 (en) * 2012-10-31 2014-05-07 British Telecommunications public limited company Session admission in a communications network
CN103229468B (zh) * 2012-11-19 2016-05-25 华为技术有限公司 分组交换资源分配方法及设备
EP3131334B1 (en) * 2015-08-12 2019-01-02 Vodafone GmbH Method for resource reservation executed by a network element of a mobile communication network for a communication connection between a mobile device and a communication destination
US11108652B2 (en) * 2018-12-18 2021-08-31 At&T Intellectual Property I, L.P. Server assisted network discovery (SAND)
CN112291093A (zh) * 2020-10-29 2021-01-29 迈普通信技术股份有限公司 网络检测方法、装置、网络设备及网络系统

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1601139A1 (en) * 2004-05-27 2005-11-30 Siemens Aktiengesellschaft Method and apparatus for routing traffic through a communications network
FR2876525A1 (fr) * 2004-10-08 2006-04-14 France Telecom Procede et dispositif de creation d'un tunnel dans un reseau de telecommunication a permutation d'etiquettes
EP1662716A1 (en) * 2004-11-30 2006-05-31 Siemens Aktiengesellschaft System, node and method for bandwidth allocation in a communications network
CN100459518C (zh) * 2005-09-02 2009-02-04 华为技术有限公司 资源接纳控制处理方法
CN1859303A (zh) * 2006-01-25 2006-11-08 华为技术有限公司 一种基于端口的动态流量控制方法
US8442030B2 (en) * 2007-03-01 2013-05-14 Extreme Networks, Inc. Software control plane for switches and routers
US20090031394A1 (en) * 2007-07-24 2009-01-29 Telefonaktiebolaget Lm Ericsson (Publ) Methods and systems for inter-resource management service type descriptions
US7636316B2 (en) * 2007-12-24 2009-12-22 Telefon Aktiebolaget Lm Ericsson (Publ) Resource allocation plan in a network
US8374502B2 (en) * 2009-02-27 2013-02-12 Futurewei Technologies, Inc. Open shortest path first extensions in support of wavelength switched optical networks
US8346079B2 (en) * 2009-02-27 2013-01-01 Futurewei Technologies, Inc. Path computation element protocol (PCEP) operations to support wavelength switched optical network routing, wavelength assignment, and impairment validation
US20110010751A1 (en) * 2009-07-08 2011-01-13 Telefonaktiebolaget L M Ericssson (Publ) Systems and Methods for Self-Organizing Networks Using Dynamic Policies and Situation Semantics
WO2011079962A1 (en) * 2010-01-04 2011-07-07 Telefonaktiebolaget L M Ericsson (Publ) Providing feedback to path computation element
WO2011128002A1 (en) * 2010-04-14 2011-10-20 Telefonaktiebolaget L M Ericsson (Publ) Link advertisement for path computation in a communications network
EP2666260A1 (en) * 2011-01-21 2013-11-27 Telefonaktiebolaget LM Ericsson (PUBL) Timer value negotiation for path configuration based on rsvp-te
WO2012116760A1 (en) * 2011-02-28 2012-09-07 Telefonaktiebolaget L M Ericsson (Publ) Path computation of working and recovery paths

Also Published As

Publication number Publication date
ES2411755A2 (es) 2013-07-08
WO2012143450A1 (en) 2012-10-26
EP2700204A1 (en) 2014-02-26
EP2700204B1 (en) 2015-06-03
ES2411755R1 (es) 2013-07-15
ES2411755B1 (es) 2014-05-13
US20140293778A1 (en) 2014-10-02

Similar Documents

Publication Publication Date Title
US8274983B2 (en) Low-impact call connection request denial
US7636781B2 (en) System and method for realizing the resource distribution in the communication network
US8320381B2 (en) Application-aware policy enforcement
US8320380B2 (en) Under-assigning resources to video in triple-play virtual topologies to protect data-class traffic
US8320245B2 (en) Policy enforcement points
EP1989842B1 (en) Method and apparatus for real-time application-driven resource management in next generation networks
ES2543921T3 (es) Procedimiento de asignación de recursos de red en arquitecturas de servicio basadas en TISPAN
US8514850B2 (en) Method for establishing a bidirectional point-to-point connection
US20050135330A1 (en) Source-implemented constraint based routing with source routed protocol data units
WO2012065466A1 (zh) 一种包交换网络中聚合链路带宽的分配方法及装置
CN101557303B (zh) 路径建立请求方法、路径建立方法与系统
Lucrezia et al. A proposal for End-to-end QoS provisioning in software-defined networks
US7463580B2 (en) Resource sharing among network tunnels
Bhumi Reddy et al. Connection provisioning for PCE-based GMPLS optical networks
WO2010000202A1 (zh) 保证差分业务流量工程网络配置参数一致的方法和系统
Raghavan An MPLS-based Quality of Service Architecture for Heterogeneous Networks
JP5051593B2 (ja) 通信装置及び品質・経路制御方法及び品質・経路制御プログラム
CN1881940A (zh) 分组地址交换或标签交换通信网络中连接路径的资源预留
Bodin et al. End-to-End QoS control architectures from a wholesale and retail perspective: benefits and challenges
Li et al. Cheetah virtual label switching router for dynamic provisioning in ip optical networks
Brewka et al. Automatic provisioning of end-to-end QoS into the home
JP2008541554A (ja) データネットワークにおいてリソースのオーバーブッキングを防止するための方法、システムおよび帯域幅マネージャ
Takeda et al. Layer 1 VPN architecture and its evaluation
Kim et al. GLASS (GMPLS Lightwave Agile Switching Simulator)-A Scalable Discrete Event Network Simulator for GMPLS-based Optical Internet
Raza et al. Just-enough-time domain level signaling (JET-DS) for optical burst switching networks