ES2335019T3 - Extension del protocolo rsvp para soportar configuracion oam. - Google Patents
Extension del protocolo rsvp para soportar configuracion oam. Download PDFInfo
- Publication number
- ES2335019T3 ES2335019T3 ES05291106T ES05291106T ES2335019T3 ES 2335019 T3 ES2335019 T3 ES 2335019T3 ES 05291106 T ES05291106 T ES 05291106T ES 05291106 T ES05291106 T ES 05291106T ES 2335019 T3 ES2335019 T3 ES 2335019T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- control plane
- oam
- network element
- 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
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/825—Involving tunnels, e.g. MPLS
-
- 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
-
- 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
-
- 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/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- 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/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
-
- 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
- H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
- H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
Método para comprobar si se soporta una función en los elementos de red de una red de telecomunicación, incluyendo la red: - un elemento de red de fuente (NE1), un elemento de red de destino (NE3) y al menos un elemento de red intermedio (NE2); - un elemento de plano de control de fuente (CPE1), un elemento de plano de control de destino (CPE3) y al menos un elemento de plano de control intermedio (CPE2) interconectados mediante mensajes de un protocolo de señalización, para controlar el elemento de red de fuente, el elemento de red de destino y el al menos un elemento de red intermedio respectivamente para configurar una conexión desde el elemento de red de fuente al elemento de red de destino pasando por el elemento de red intermedio; incluyendo el método, en el caso de que la conexión no esté configurada, las siguientes etapas: - transmitir un primer mensaje (de Path) desde el elemento de plano de control de fuente al elemento de plano de control de destino pasando por el al menos un elemento de plano de control intermedio para indicar una petición de la configuración de la conexión; - recibir en el elemento de plano de control de fuente un segundo mensaje (de Resv) transmitido desde el elemento de plano de control de destino para indicar una respuesta a la petición; caracterizado porque - el primer mensaje incluye un primer campo (PATH MSG, OAM_check=1) para indicar una petición de comprobación de si se soporta una función de OAM de operación, administración y gestión de la conexión por cada elemento de red de la conexión; - el segundo mensaje incluye el primer campo (RESV MSG, OAM_check=1) para indicar si la función de OAM es soportada por cada elemento de red de la conexión.
Description
Extensión del protocolo RSVP para soportar
configuración OAM.
La presente invención se refiere al campo de la
telecomunicación y más en particular al Resource Reservation
Protocol - Traffic Engineering (RSVP-TE - Protocolo
de Reserva de Recursos - Ingeniería del Tráfico). De nuevo más en
particular, la invención se refiere a un método para comprobar que
se soporta una función en los elementos de red de una conexión.
Las nuevas arquitecturas de red se basan en la
Automatically Switched Optical Network (ASON - Red Óptica Conmutada
Automáticamente) definida en ITU-T G.8080/Y.1304
(11/2001), en la que control plane elements (CPEs -
Elementos del Plano de Control) están interconectados entre sí y se comunican de acuerdo con un protocolo de señalización. Cada CPE controla uno o más elementos de red (NE - Elemento de Red), también definidos como Transport Plane Elements (TPE - Elemento de Plano de Transporte), para la configuración del inicio de las conexiones desde el elemento de red controlado (también definido como elemento de red de fuente), con el fin de proporcionar una rápida detección de un fallo, una rápida y eficiente configuración de nuevas conexiones dentro del Plano de Transporte, modificar las conexiones previamente establecidas y llevar a cabo una función de restauración más rápida que proporcione conexiones de seguridad para proteger las conexiones afectadas por un fallo. Varios protocolos de señalización pueden adaptarse a la arquitectura de ASON, como el Resource Reservation Protocol (RSVP - Protocolo de Reserva de Recursos) definido en las normas RFC2205, RFC2209 y RFC2750, el Resource Reservation Protocol - Traffic Engineering (RSVP-TE - Ingeniería del Tráfico-Protocolo de Reserva de Recursos) definido en las normas RFC3209 y ITU-T G.7713.2, el Label Distribution Protocol (LDP - Protocolo de Distribución de Etiquetas) definido en la norma RFC3036, el Constraint Based - Label Distribution Protocol (CR-LDP - Protocolo de Distribución de Etiquetas - Basado en Restricciones) definido en las normas ITU-T G.7713.3 y RFC3472, la Private Network to Network Interface (PNNI - Interfaz de Red a Red Privada) definida en la norma ITU-T G.7713.1.
Elementos del Plano de Control) están interconectados entre sí y se comunican de acuerdo con un protocolo de señalización. Cada CPE controla uno o más elementos de red (NE - Elemento de Red), también definidos como Transport Plane Elements (TPE - Elemento de Plano de Transporte), para la configuración del inicio de las conexiones desde el elemento de red controlado (también definido como elemento de red de fuente), con el fin de proporcionar una rápida detección de un fallo, una rápida y eficiente configuración de nuevas conexiones dentro del Plano de Transporte, modificar las conexiones previamente establecidas y llevar a cabo una función de restauración más rápida que proporcione conexiones de seguridad para proteger las conexiones afectadas por un fallo. Varios protocolos de señalización pueden adaptarse a la arquitectura de ASON, como el Resource Reservation Protocol (RSVP - Protocolo de Reserva de Recursos) definido en las normas RFC2205, RFC2209 y RFC2750, el Resource Reservation Protocol - Traffic Engineering (RSVP-TE - Ingeniería del Tráfico-Protocolo de Reserva de Recursos) definido en las normas RFC3209 y ITU-T G.7713.2, el Label Distribution Protocol (LDP - Protocolo de Distribución de Etiquetas) definido en la norma RFC3036, el Constraint Based - Label Distribution Protocol (CR-LDP - Protocolo de Distribución de Etiquetas - Basado en Restricciones) definido en las normas ITU-T G.7713.3 y RFC3472, la Private Network to Network Interface (PNNI - Interfaz de Red a Red Privada) definida en la norma ITU-T G.7713.1.
En referencia al protocolo RSVP, la
especificación de base fue diseñada para permitir que los elementos
de red (encaminadores) decidan con antelación, es decir antes del
aprovisionamiento de la conexión, si la red puede cumplir los
requisitos de una Quality de Service (QoS - Calidad de Servicio)
definidos para la conexión. La configuración de una nueva conexión
se lleva a cabo transmitiendo un mensaje de Path y recibiendo, en
caso de una configuración de la conexión con éxito, un mensaje de
Resv en la dirección contraria del mensaje de Path o bien
recibiendo un mensaje de PathErr en caso de una configuración sin
éxito (por ejemplo por falta de recursos de red). Cada mensaje de
RSVP (Path, Resv, PathErr, ResvErr, PathTear, ResvTear, ResvConf)
está compuesto por una cabecera común seguida de un cuerpo
que consiste en un número variable (de longitud variable) de objetos. La cabecera común está compuesta por 8 bytes:
que consiste en un número variable (de longitud variable) de objetos. La cabecera común está compuesta por 8 bytes:
Incluye el campo "Msg Type" (Tipo de
Mensaje) (1 byte) para identificar de manera única el tipo de
mensaje e incluye el campo "RSVP Length" (Longitud de RSVP) (2
bytes) para indicar la longitud total (en bytes) del mensaje
correspondiente, incluyendo la cabecera común y los objetos de
longitud variable que siguen. Cada objeto está compuesto por una
cabecera (4 bytes) seguida por el contenido del objeto:
La cabecera del objeto incluye el campo
"Length" (Longitud) (2 bytes) para indicar la longitud total
(en bytes) del objeto correspondiente e incluye el campo
"Class-Num" (Número de Clase) (1 byte) para
identificar de manera única el objeto.
\vskip1.000000\baselineskip
El mensaje de ruta, como cualquier mensaje de
RSVP, incluye la cabecera común seguida por los siguientes
objetos:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
en los cuales los corchetes, es
decir [ ], indican un objeto opcional. El objeto <SESSION>
incluye la dirección de destino de IP y el objeto
<TIME_VALUES> incluye el valor del periodo de refresco. El
<sender descriptor> incluye los siguientes
objetos:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
El objeto <SENDER_TEMPLATE> incluye la
dirección de IP del que envía y el objeto <SENDER_TSPEC>
define las características del tráfico del flujo de datos del que
envía. El mensaje de Resv incluye la cabecera común seguida por los
siguientes objetos:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
siendo <flow descriptor list> ::= <FF
flow descriptor list> <SE flow descriptor list>;
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
y siendo
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
SE han añadido varias extensiones para soportar
el aprovisionamiento y mantenimiento de conexiones encaminadas
explícitamente (LSP definido= rutas conmutadas con etiquetas).
Finalmente, el RSVP-TE permite la agregación de
conexiones, túneles de LSP definida, que comparten una ruta común y
un conjunto común de recursos de red compartidos, reduciendo la
cantidad de información transportada en la red.
\vskip1.000000\baselineskip
La Multi-Protocol Label
Switching (indicada con MPLS - Conmutación con Etiquetas de
Protocolo Múltiple), que está básicamente definida en RFC3031
(Enero, 2001) representa un esfuerzo en la evolución continuada de
la conmutación de multi-capa, consiguiendo
eficiencia en el envío de datos, la QoS y la gestión de la
ingeniería del tráfico. En una red sin conexión tradicional (por
ejemplo red de IP), cada elemento de red (encaminador) ejecuta un
algoritmo de encaminamiento de capa-3 para
determinar la ruta de los paquetes de datos a través de la red;
cada elemento de red toma una decisión de envío independiente,
usando la información incluida en la cabecera del paquete (por
ejemplo, la dirección de IP de destino) y la información obtenida
del algoritmo de encaminamiento. Éste es un proceso lento,
especialmente cuando la base de datos de envío incluye muchos
parámetros de entradas y de QoS. Por el contrario, en una red de
MPLS la ruta óptima a través de la red es calculada con antelación
y se asigna una etiqueta a la parte frontal del paquete de datos;
esta etiqueta acompaña al paquete de datos a medida que atraviesa
la red y los elementos de red a través de la ruta utilizan esta
etiqueta para determinar el siguiente elemento de red de hope. Cada
elemento de red mantiene una base de datos de envío que mapea una
etiqueta/interfaz entrante con una etiqueta/interfaz saliente; esta
conmutación puede ser aplicada a diferentes tecnologías
(IP=Internet Protocol - Protocolo de Internet, ATM=Asynchronous
Transfer Mode - Modo de Transferencia Asíncrono, FR=Frame Relay).
La ruta tomada por los paquetes etiquetados se llama Label Switched
Path (LSP - Ruta Conmutada con Etiqueta). La ventaja es que tiene
lugar un análisis intensivo mediante un procesador sólo en el
elemento de red de fuente, mientras que los elementos de red
subsiguientes a lo largo de la ruta manipulan esta etiqueta a nivel
de hardware y así pueden llevar a cabo una conmutación rápida,
porque las decisiones siguientes están basadas en (pocas) etiquetas
en lugar de en la dirección de IP de destino.
\vskip1.000000\baselineskip
Las funciones de operación, administración y
gestión (indicadas con OAM) están definidas para monitorizar el
tráfico transportado sobre una conexión, desde una fuente a un
elemento de red de destino. Las funciones de OAM incluyen por
ejemplo:
- \bullet
- localización de un fallo que afecta a una conexión;
- \bullet
- comprobar la integridad de una conexión: por ejemplo un elemento de red de fuente genera continuamente un mensaje dedicado y un elemento de red receptor comprueba continuamente para recibir este mensaje;
- \bullet
- indicación de un fallo que afecta a un segmento de una conexión a los elementos de red de flujo descendente y de flujo ascendente de la conexión: la indicación de flujo descendente se indica habitualmente con Alarm Indication.
\vskip1.000000\baselineskip
Signal (AIS - Señal de Indicación de Alarma),
mientras que la de flujo ascendente se indica con Remote Defect
Indication (RDI - Indicación de Defecto Remoto).
\vskip1.000000\baselineskip
Las funciones de OAM están definidas para muchos
protocolos conocidos, como SDH/SONET, ATM y Ethernet.
Específicamente, las funciones de OAM para SDH están definidas en
ITU-T G.806 y ITU-T G.783. La trama
de SDH incluye bytes para llevar a cabo las funciones de OAM de las
diferentes capas, que son las capas de regenerador, sección, ruta
de orden superior y ruta de orden inferior. La trama de SDH incluye
la RSOH que incluye los bytes (B1, J0) para monitorizar la capa
regeneradora, la MSOH que incluye los bytes (B2, K1, K2) para
monitorizar la capa de sección, la POH de nivel superior que
incluye los bytes (J1, B3, C2, G1, H4, N1) para monitorizar la capa
de ruta de nivel superior y la POH de nivel inferior que incluye los
bytes (V5, B3, J2, N2) para monitorizar la capa de ruta de nivel
inferior. Las funciones de OAM para ATM están definidas en la norma
ITU-T 1.610. Las celdas de OAM dedicadas están
definidas para monitorizar una Virtual Path (VP - Ruta Virtual) o
bien un Virtual Channel (VC - Canal Virtual), bien sea a nivel de
segmento o bien sea a nivel de extremo a extremo; cada celda
incluye un campo de tipo (gestión de fallo, gestión de rendimiento,
protocolo de APS, activación/desactivación) y un campo de función
correspondiente (por ejemplo AIS/ RDI/ Comprobación de Continuidad
para gestión de fallos). La activación de funciones de OAM para un
VP/VC puede ser llevada a cabo de acuerdo con dos soluciones
diferentes. En la primera solución el gestor de ATM controla
directamente tanto la fuente como el elemento de red de destino
para la activación de las funciones de OAM de acuerdo con las
siguientes etapas:
- \bullet
- el VP/VC está establecido previamente;
- \bullet
- el gestor de ATM envía al elemento de red de fuente del correspondiente VP/VC un mensaje para indicar la activación de una función de OAM particular en el elemento de red de fuente, por ejemplo el elemento de red de fuente empieza a transmitir celdas de Continuity Check (CC - Comprobación de Continuidad);
- \bullet
- el gestor de ATM envía al elemento de red de destino del mismo VPNC correspondiente un mensaje para indicar la activación de la función de OAM en el elemento de red de destino, es decir, el elemento de red de destino empieza a comprobar para recibir las celdas de CC.
\vskip1.000000\baselineskip
En la segunda solución el gestor de ATM controla
directamente sólo el elemento de red de fuente para la activación
de las funciones de OAM de acuerdo con las siguientes etapas:
- \bullet
- el VP/VC está establecido previamente;
- \bullet
- el gestor de ATM envía al elemento de red de fuente del VP/VC correspondiente un mensaje para indicar una petición de activación de una función de OAM particular en el elemento de red de fuente, por ejemplo celdas de transmisión de CC;
- \bullet
- tras recibir la petición, el elemento de red de fuente transmite al elemento de red de destino celdas de activación de OAM para indicar una petición de activación de la función de OAM en el elemento de red de destino, es decir, para comprobar para recibir las celdas de CC;
- \bullet
- tras recibir la petición, el elemento de red de destino transmite al elemento de red de fuente una confirmación a la petición;
- \bullet
- cuando el elemento de red de fuente recibe la confirmación a la petición, el elemento de red de fuente empieza a transmitir las celdas de OAM de CC al elemento de red de destino.
\vskip1.000000\baselineskip
Por lo tanto el ATM requiere que el VP/VC sea
establecido previamente y después son activadas las funciones de
OAM. Además, la petición de activación es enviada sólo a la fuente y
los elementos de red de destino y no a los elementos de red
intermedios; esto es posible porque las funciones de OAM en los
elementos de red intermedios están soportadas por defecto,
significando que es mandatorio para un elemento de red que cumple
el protocolo de ATM proporcionar funciones de OAM y sólo se requiere
activar estas funciones, mediante la transmisión de un mensaje de
activación desde el gestor central a la fuente y a elementos de red
de destino (primera solución) o bien alternativamente mediante la
transmisión de una petición de activación desde el gestor central
al elemento de red de fuente y mediante la transmisión de las celdas
de activación desde la fuente al elemento de red de destino pasando
por los elementos de red intermedios.
El Link Management Protocol (LMP - Protocolo de
Gestión de Enlaces), definido por Internet draft
draft-ietf-ccamp-Imp-10.txt
(Oct., 2003) emitido por IETF y actualizado periódicamente,
especifica un protocolo que se ejecuta entre dos elementos de red
adyacentes (enlace definido) y se usa para gestionar enlaces de TE,
para mantener la conectividad del canal de control, verificar la
conectividad física de los enlaces de datos, correlacionar la
información de las propiedades del enlace, suprimir alarmas
descendentes y localizar fallos del enlace con fines de
protección/restauración. El LMP especifica también en el párrafo
6.4 que un mensaje de ChannelStatus puede usarse para notificar a
un vecino que el enlace de datos debe ser activamente monitorizado y
que el vecino debe transmitir un ChannelStatusAck a la recepción
del mensaje de ChannelStatus. Así el LMP puede usarse sólo para la
activación de la monitorización del enlace de datos entre dos
elementos de red adyacentes y no para la activación de la
monitorización en todos los elementos de red de una conexión, que
puede incluir muchos enlaces.
Las funciones de OAM para la MPLS están
definidas en ITU-T Y.1711 (2/2004). Paquetes de OAM
dedicados, identificados a partir del tráfico de usuario por un
valor reservado (14) de una etiqueta, están definidos para
monitorizar una ruta de MPLS; Cada paquete de OAM de MPLS incluye
un campo de función para indicar Connectivity Verification (CV -
Verificación de Conectividad), Fast Failure Detection (FFD -
Detección de Fallo Rápida), Forward Defect Indicator (FDI -
Indicador de Defecto Siguiente), Backward Defect Indicator (BDI -
Indicador de Defecto Anterior). Los paquetes de OAM de MPLS son
transmitidos periódicamente desde la fuente al elemento de red de
destino de la LSP. Cada paquete de OAM de MPLS incluye también en
los dos últimos bytes un BIP16 para detectar errores del paquete.
Este estándar define que los elementos de red intermedios envían de
manera transparente los paquetes de OAM de MPLS recibidos al
elemento de red de destino y define que un elemento de red de
destino que no soporta la funcionalidad de OAM de MPLS borrará los
paquetes de OAM de MPLS recibidos; esto tiene la desventaja de que,
en caso de que un elemento de red intermedio soporte y active la
transmisión de paquetes de OAM de MPLS, el elemento de red de
destino (que no soporta la funcionalidad de OAM de MPLS)
continuamente recibe y descarta los paquetes de OAM de MPLS,
aumentando así el tráfico de gestión. Además, este estándar define
que el tratamiento de un CV o de un paquete de FFD debe ser
activado después de que la LSP se ha establecido, con el fin de
asegurar que las alarmas están correctamente permitidas.
Por lo tanto las funciones de OAM para MPLS
pueden ser soportadas o no soportadas por un elemento de red y
aparece el problema de comprobar si las funciones de OAM están
soportadas por cada elemento de red de una conexión. Esta
comprobación se requiere también no sólo para MPLS, sino también
para cualquier otro protocolo, por ejemplo en el caso de que los
elementos de red de una conexión pertenezcan a diferentes
suministradores o a diferentes dominios de red, cada uno de ellos
controlado por un gestor de red central diferente. En realidad, en
el primer caso una función de OAM podría ser soportada sólo por los
elementos de red de un primer suministrador y no por un segundo,
mientras que en el segundo caso cada gestor puede comprobar sólo si
las funciones de OAM están soportadas por los elementos de red del
dominio controlado y no por cada elemento de red de la conexión
completa. En referencia por ejemplo al protocolo de SDH, la función
de Tandem Connection Monitoring (TCM - Monitorización de Conexión
en Tándem) no está soportada por defecto por todos los
suministradores, o bien está soportada de acuerdo con diferentes
soluciones; por lo tanto se requiere conocer si la TCM está
soportada por cada elemento de red de la conexión o bien si cada
elemento de red cumple una versión de TCM especificada.
\vskip1.000000\baselineskip
Las funciones de OAM para Ethernet están
definidas esquemáticamente en ITU-T Y.1730 (1/2004)
e incluyen:
- \bullet
- comprobación continua de la conectividad;
- \bullet
- funciones de propagación de fallo/supresión de alarma;
- \bullet
- bucle de retorno intrusivo y no-intrusivo;
- \bullet
- aislamiento del fallo (traceroute);
- \bullet
- descubrimiento;
- \bullet
- monitorización del funcionamiento.
- \bullet
- funciones de capacidad de supervivencia (por ejemplo, conmutación de protección, restauración).
\vskip1.000000\baselineskip
La solicitud de US que tiene el número de
publicación 2003/0110276-A1 describe que el mensaje
PATH del protocolo RSVP incluye un campo para indicar una capacidad
de túnel deseada.
La solicitud de US que tiene el número de
publicación 2005/0105905-A1 describe una mejora del
protocol RSVP-TE con el fin de comprobar la
disponibilidad de recursos de red (enlaces, nodos) antes de la
confirmación de la reserva del recurso.
El documento "Generalized MPLS (GMPLS)
RSVP-TE signalling in support of Automatically
Switched Optical Network (ASON)", emitido por IETF en Febr.
2005, describe una mejora del protocolo GMPLS
RSVP-TE con el fin de establecer conexiones
permanentes blandas, para soportar separación de llamada/conexión y
otros requisitos de la arquitectura de ASON.
\vskip1.000000\baselineskip
Finalmente, el problema para comprobar si las
funciones de OAM están soportadas por cada elemento de red de una
conexión puede generalizarse al problema de comprobar si una función
genérica esta soportada por cada elemento de red de una conexión,
como por ejemplo:
- \bullet
- si cada elemento de red está ejecutando una versión de software especificada;
- \bullet
- si cada elemento de red puede soportar la funcionalidad de monitorización de funcionamiento y las funciones de monitorización de funcionamiento.
\vskip1.000000\baselineskip
Una solución simple al problema de comprobar si
las funciones de OAM están soportadas por cada elemento de red de
una conexión podría ser usar un gestor de red central, que controle
todos los elementos de red de la conexión. El gestor comprueba si
las funciones de OAM están soportadas por cada elemento de red de la
conexión transmitiendo un primer mensaje a cada elemento de red de
la conexión para indicar una petición de comprobación de si las
funciones de OAM están soportadas y recibiendo desde cada elemento
de red un segundo mensaje para indicar si las funciones de OAM
están soportadas en el elemento de red correspondiente. Esta
solución tiene los siguientes inconvenientes:
- \bullet
- requiere un tiempo elevado porque la conexión normalmente incluye muchos elementos de red y porque el ancho de banda disponible para la comunicación entre el gestor y cada elemento de red está limitada (por ejemplo DCC= Data Communications Channels para SDH);
- \bullet
- aumenta el tráfico de gestión comparado con el tráfico de datos de usuario en la red, porque el gestor debe comunicarse con cada elemento de red;
- \bullet
- los elementos de red podrían pertenecer a diferentes dominios de red controlados por diferentes gestores de red y en este caso se requiere una cooperación entre los gestores para comunicase con todos los elementos de red de la conexión.
\vskip1.000000\baselineskip
El problema de comprobar si una función está
soportada por cada elemento de red de una conexión no es resuelto
por el RSVP, que es un protocolo definido especialmente para
comprobar si una calidad de servicio predefinida para una conexión
se cumple y para la configuración de esta conexión.
A la vista de los inconvenientes de las
soluciones conocidas, el principal objeto de la presente invención
es proporcionar un método para comprobar en una red de
telecomunicación si se soporta una función en los elementos de red
de una conexión. Este objeto es alcanzado por un método de acuerdo
con las reivindicaciones 1 ó 2, por un mensaje de un protocolo de
señalización de acuerdo con la reivindicación 13, por un elemento de
plano de control de acuerdo con las reivindicaciones 15, 17 ó 19 y
por un nodo de red de acuerdo con las reivindicaciones 16, 18 ó 20.
La idea básica es extender los mensajes de un protocolo de
señalización (por ejemplo RSVP) incluyendo objetos para la
configuración de una conexión con el fin de incluir también un nuevo
objeto para comprobar si una función es soportada en cada elemento
de red de la conexión. Las ventajas son:
- \bullet
- requerir un tiempo corto para la comprobación también en el caso de que la conexión incluya muchos elementos de red, porque se requiere una comunicación sólo entre el gestor central y el elemento de red de fuente y no entre el gestor central y cada elemento de red;
- \bullet
- requerir un tiempo corto también porque el ancho de banda disponible para el canal de control es mayor (y más fiable) que el ancho de banda disponible entre el gestor y cada elemento de red;
- \bullet
- no aumentar el tráfico de gestión de la red, porque los mismos mensajes usados para la configuración de las conexiones se usan también para la comprobación y porque el tráfico de gestión es transmitido sólo si todos los elementos de red de la conexión soportan la función;
- \bullet
- los elementos de red pueden también pertenecer a diferentes suministradores o bien a diferentes dominios de red, porque el protocolo de señalización (como el RSVP) está definido por un estándar y los elementos de red de diferentes suministradores pueden comunicarse entre sí si cumplen la norma.
\vskip1.000000\baselineskip
Otro objeto más de la invención es, en caso de
que la función sea soportada en cada elemento de red de la
conexión, extender el nuevo objeto del protocolo de señalización que
incluye también campos para comprobar que se soporta un valor del
parámetro de configuración de una función específica. Esto es
logrado por un método de acuerdo con la reivindicación 5, por un
mensaje de acuerdo con la reivindicación 14, por un elemento de
plano de control de acuerdo con la reivindicación 15 y por un nodo
de red de acuerdo con la reivindicación 16.
\vskip1.000000\baselineskip
La Fig.1 muestra esquemáticamente los campos de
un nuevo objeto transportados por los mensajes intercambiados entre
tres elementos de plano de control que controlan tres elementos de
red correspondientes de una conexión para comprobar si se soportan
las funciones de OAM de una conexión.
La Fig.2 muestra esquemáticamente los campos del
nuevo objeto transportados por los mensajes intercambiados entre
tres elementos de plano de control que controlan tres elementos de
red correspondientes de una conexión para comprobar que se soporta
la configuración de un período de generación de paquetes de MPLS FFD
igual a 20 milisegundos (ms).
\vskip1.000000\baselineskip
El método se describe específicamente para el
protocolo RSVP y para comprobar que se soportan las funciones de
OAM de MPLS. Con el fin de llevar a cabo la invención, se añade un
nuevo objeto opcional en los mensajes de Path y Resv después del
objeto <RECORD_ROUTE> y este objeto se define como
<LSP_ADDINFO>, en el que el LSP se presenta como "Label
Switched Path", ADDINFO se presenta como "Additional
Information"; este nuevo objeto se identifica por un nuevo valor
del campo Class-Num (por ejemplo valor=160, en
decimal) de la cabecera del objeto. Así el nuevo formato del
<sender descriptor> del mensaje de Path es el siguiente:
\vskip1.000000\baselineskip
\vskip1.000000\baselineskip
Este nuevo objeto opcional es añadido también al
mensaje de Resv tras el objeto <RECORD_ROUTE> de la <FF
flow descriptor list> o bien del <FF flow descriptor> o
bien de la <SE filter spec>.
\vskip1.000000\baselineskip
El objeto LSP_ADDINFO transportado por los
mensajes de Path y Resv incluye la cabecera común y un cuerpo de
objeto. El cuerpo de objeto incluye campos específicos para llevar a
cabo la invención y en particular:
- \bullet
- al menos un bit indicado con OAM_check;
- \bullet
- al menos un bit indicado con OAM_activation_Path;
en el que se requiere el sufijo "_Path"
para indicar que el campo de OAM_activation_Path es significativo
sólo cuando lo lleva el mensaje de ruta. El primer campo OAM_check
(un bit en este ejemplo) se requiere para comprobar si las
funciones de OAM están soportadas en cada elemento de red de una
conexión desde una fuente a un elemento de red de destino, pasando
por al menos un elemento de red intermedio; el segundo campo
OAM_activation_Path (un bit en este ejemplo) se requiere, en caso
de soportar las funciones de OAM, para solicitar la activación de
las funciones en cada elemento de red de la conexión. La Fig.1
muestra esquemáticamente las etapas requeridas para llevar a cabo
la comprobación, en el que un elemento de plano de control de fuente
(indicado con CPE1) controla el elemento de red de fuente (indicado
con NE1), un elemento de plano de control intermedio (indicado con
CPE2) controla el elemento de red intermedio de red (indicado con
NE2) y un elemento de plano de control de destino (indicado con
CPE3) controla el elemento de red de destino (indicado con NE3). La
Fig.1 muestra sólo un elemento de red intermedio, pero la conexión
puede incluir más de un elemento de red intermedio. La Fig.1
también muestra los bits OAM_check y OAM_activation_Path del nuevo
objeto LSP_ADDINFO del mensaje de Path y el bit OAM_check del nuevo
objeto LSP_ADDINFO del mensaje de Resv, los correspondientes valores
requeridos para llevar a cabo la comprobación y para solicitar la
activación y la evolución del tiempo.
\vskip1.000000\baselineskip
La activación de una función de OAM de MPLS es
llevada a cabo de acuerdo con un procedimiento de dos etapas. La
primera etapa empieza en el tiempo= t0, cuando la conexión (a LSP en
caso de una red de MPLS) del NE1 al NE3 pasando por el NE2 no está
todavía establecida; así en el tiempo= t0 el CPE1 transmite un
mensaje de Path al CPE3 para solicitar la configuración de la
conexión de acuerdo con una calidad de servicio definida, asignando
uno o más bits de acuerdo con técnicas conocidas. En referencia al
RSVP, esto se lleva a cabo mediante el objeto <SENDER_TSPEC>.
En el mismo tiempo=t0 al bit OAM_check del mensaje de Path se le
asigna el valor "1" para indicar una petición de comprobar si
las funciones de OAM están soportadas en cada elemento de red de la
conexión. El mensaje de Path pasa por cada CPE intermedio de la
conexión; Específicamente, es recibido por el CPE2 en el tiempo=t1
y, en caso de soportar las funciones de OAM de MPLS el NE2, el
mensaje de Path es transmitido manteniendo el OAM_check="1" al
elemento de plano de control adyacente (CPE3 de destino en este
ejemplo) controlando el subsiguiente elemento de red de la conexión
para indicar que las funciones de OAM de MPLS están soportadas en
cada elemento de red de la conexión comprendidas entre el NE de
fuente y el NE intermedio. Por el contrario, en caso de que un CPE
intermedio no soporte las funciones de OAM de MPLS en el NE
intermedio controlado, al bit OAM_check del mensaje de Path
transmitido se le asigna el valor "0" para indicar que las
funciones de OAM de MPLS no están soportadas en el NE intermedio
controlado; en este caso, cada CPE intermedio subsiguiente recibe
el mensaje de Path incluyendo OAM_check="0" indicando que al
menos un NE intermedio previo no soporta las funciones de OAM de
MPLS y después este mensaje de Path es transmitido al CPE adyacente
hacia el CPE de destino manteniendo OAM_check="0". Así cada CPE
intermedio que recibe el mensaje de Path que incluye
OAM_check="1" transmite, en caso de soportar las funciones de
OAM de MPLS en el NE intermedio controlado, el mensaje de Path que
incluye OAM_check="1" al CPE subsiguiente hacia el CPE de
destino. Si el mensaje de Path que incluye OAM_check="1" es
recibido en el CPE3 de destino en tiempo=t2, el CPE3 transmite, en
caso de soportar funciones de OAM de MPLS en el NE3 de destino, un
mensaje de Resv en la dirección contraria hacia el CPE1, asignando
OAM_check="1": Esta es la indicación de que las funciones de
OAM de MPLS están soportadas en cada NE de la conexión, porque el
mensaje de Path ha pasado por los CPEs controlando cada NE de la
conexión y cada CPE ha comprobado con éxito si se soportan las
funciones de OAM de MPLS en el NE controlado. Por el contrario, en
el caso de que CPE3 reciba el mensaje de Path que incluye
OAM_check="1" pero el CPE de destino no soporte las funciones
de OAM de MPLS en el NE de destino, al bit OAM_check del mensaje de
Resv se le asigna el valor "0" para indicar que las funciones
de OAM de MPLS no están soportadas en al menos un elemento de red
de la conexión (en este caso sólo en el NE3) y también en el caso de
que el CPE3 reciba el mensaje de Path que incluye
OAM_check="0" (porque al menos un NE previo de la conexión no
soporta las funciones de OAM de MPLS), al bit OAM_check bit del
mensaje de Resv se le asigna el valor "0" para indicar que las
funciones de OAM de MPLS no están soportadas en al menos un elemento
de red de la conexión (que puede ser el NE1, el NE2 o bien el NE3).
El CPE2 recibe en tiempo=t3 el mensaje de Resv (que incluye
OAM_check ="1" o bien="0") y transmite el mensaje de Resv
al CPE1 manteniendo OAM_check sin cambios. Si el CPE1 recibe en
tiempo=t4 el mensaje de Resv que incluye OAM_check ="1", esto
indica que las funciones de OAM de MPLS están soportadas en cada
elemento de red (NE1, NE2, NE3 en este ejemplo) de la conexión y
este es el fin de la primera etapa. Por el contrario, si el CPE1
recibe en tiempo=t4 el mensaje de Resv que incluye
OAM_check="0", esto indica que las funciones de OAM de MPLS no
están soportadas en al menos un elemento de red de la conexión
(NE1, NE2 o bien NE3 en este ejemplo). En caso de no soportar las
funciones de OAM de MPLS, el método puede ser mejorado incluyendo
uno o más campos nuevos del objeto LSP_ADDINFO de los mensajes de
Path y Resv, con el fin de marcar (durante la transmisión del
mensaje de Path) los NEs que no soportan las funciones de OAM de
MPLS y con el fin de notificar esta información al CPE de fuente
(mediante la transmisión del mensaje de Resv). CPE1 puede
alternativamente detectar que las funciones de OAM de MPLS no están
soportadas no sólo asignando OAM_check="1" , en el mensaje de
Path y recibiendo OAM_check="0" en el mensaje de Resv, sino
también asignando OAM_check="1" en el mensaje de Path y
recibiendo el mensaje de Resv que no incluye el objeto LSP_ADDINFO
opcional. Por ejemplo, un CPE intermedio que no reconoce el objeto
LSP_ADDINFO del mensaje de Path recibido puede borrar este objeto
del mensaje de Path transmitido hacia el CPE de destino; de acuerdo
con esto, el CPE de destino que no reconoce el objeto LSP_ADDINFO
del mensaje de Path recibido puede borrar este objeto del mensaje de
Resv transmitido hacia el CPE de fuente. Finalmente, el CPE de
fuente, que previamente ha transmitido el mensaje de Path que
incluye el objeto LSP_ADDINFO (y OAM_check= "1"), recibe un
mensaje de Resv que no incluye el objeto LSP_ADDINFO y puede
detectar que las funciones de OAM de MPLS no están soportadas.
La segunda etapa empieza en tiempo=t4 tras
recibir el mensaje de Resv que incluye OAM_check ="1": el CPE1
de fuente transmite un mensaje de Path que incluye
OAM_activation_Path="1" para solicitar la activación de las
funciones de OAM de MPLS en cada elemento de red de la conexión y
después las funciones de OAM de MPLS son activadas en el NE1 de
fuente, es decir, el NE1 empieza a transmitir los paquetes de OAM al
NE2. En tiempo=t5 el CPE2 intermedio recibe el mensaje de Path que
incluye OAM_activation_Path="1", y a continuación transmite el
mensaje de Path al CPE3 manteniendo OAM_activation_Path="1" sin
cambios y después las funciones de OAM de MPLS son activadas en el
NE2 intermedio, es decir, el NE2 empieza a transmitir paquetes de
OAM al NE3. Finalmente, en tiempo=t6 el CPE3 de destino recibe el
mensaje de Path que incluye OAM_activation_Path="1" y después
las funciones de OAM de MPLS son activadas en el NE3 de destino, es
decir, los paquetes de OAM son tratados en el NE3 para monitorizar
la conexión del NE1 al NE3 pasando por el NE2 y éste es el fin de la
segunda etapa.
El procedimiento anterior tiene también la
ventaja, en caso de activación de las funciones de OAM de MPLS de
una red de MPLS, de asegurar el tiempo activación correcto de tratar
un CV o un paquete de FFD, porque el elemento de red de destino
recibe el primer paquete de OAM de MPLS inmediatamente después de
que el elemento de red de destino ha activado el tratamiento del
paquete de OAM de MPLS.
\vskip1.000000\baselineskip
En caso de soportar las funciones de OAM de MPLS
en cada elemento de red de la conexión, la invención puede ser
usada ventajosamente también para comprobar que se soporta un valor
del parámetro de configuración de una función específica; Por
ejemplo, la función de Fast Failure Detection (FFD) se usa para
detectar la monitorización de la conexión a una escala de tiempos
menor comparada con la funcionalidad de Connectivity Verificación
(CV -
Verificación de la Conectividad). En caso de soportar y activar la función de FFD, el período de generación por defecto es 50 ms (ms=milisegundos), pero de acuerdo con ITU-T Y.1711 este parámetro puede estar comprendido entre 10 ms y 500 ms. Por lo tanto los mensajes de Path y Resv pueden ser extendidos para comprobar también si un valor del parámetro de configuración (por ejemplo un menor valor de 20 ms) de una función específica (la función de FFD) puede ser soportado en cada elemento de red de la conexión. Esto se logra también añadiendo en el objeto LSP_ADDINFO de los mensajes de Path y de Resv los campos siguientes:
Verificación de la Conectividad). En caso de soportar y activar la función de FFD, el período de generación por defecto es 50 ms (ms=milisegundos), pero de acuerdo con ITU-T Y.1711 este parámetro puede estar comprendido entre 10 ms y 500 ms. Por lo tanto los mensajes de Path y Resv pueden ser extendidos para comprobar también si un valor del parámetro de configuración (por ejemplo un menor valor de 20 ms) de una función específica (la función de FFD) puede ser soportado en cada elemento de red de la conexión. Esto se logra también añadiendo en el objeto LSP_ADDINFO de los mensajes de Path y de Resv los campos siguientes:
- \bullet
- al menos un bit indicado con FFD_check;
- \bullet
- al menos un bit indicado con FFD_timer.
\vskip1.000000\baselineskip
La Fig.2 muestra esquemáticamente los dos campos
anteriores, las etapas requeridas para comprobar si cada elemento
de red de la conexión soporta un período de generación de los
paquetes de FFD de MPLS igual a 20 ms y los correspondientes
valores de los campos. En este ejemplo el FFD_check está compuesto
por un bit, el FFD_timer está compuesto por tres bits (se requieren
tres bits porque la norma ITU-T Y.1711 indica 6
posibles valores del período de generación de los paquetes de FFD:
10 ms, 20 ms, 50 ms, 100 ms, 200 ms, 500 ms). La evolución en el
tiempo de FFD_check de los mensajes de Path y de Resv es equivalente
a OAM_check de los mensajes de Path y de Resv respectivamente,
mientras que el valor de FFD_timer indica el período de generación
de los paquetes de OAM de MPLS requerido (por ejemplo "000"=
10 ms, "001"= 20 ms, "010"= 50 ms, "011"= 100 ms,
"100"= 200 ms, "101 "= 500 ms); Más en general, se
proporciona un campo en el mensaje de Path para indicar el valor
del parámetro de configuración. En referencia a la Fig.2, en
tiempo=t0 el CPE1 transmite un mensaje de Path al CPE3 para
solicitar la configuración de la conexión y para preguntar si las
funciones de OAM de MPLS están soportadas, de acuerdo con la
evolución con el tiempo de OAM_check y de OAM_activation_Path del
mensaje de Path y de OAM_check del mensaje de Resv, como se ha
explicado previamente. En el mismo tiempo=t0 al bit FFD_check del
mensaje de Path se le asigna el valor "1" para indicar una
petición de comprobar si la función FFD está soportada en cada
elemento de red de la conexión (y, más en general, a un campo se le
asigna solicitar si se soporta un parámetro de configuración de una
función). Además, en tiempo=t0 a los bits de FFD_timer se les
asigna "001" (y, más en general, a este campo se le asigna el
valor del parámetro de configuración de la función específica)
correspondiente al valor=20 ms: FFD_check en combinación con
FFD_timer del mensaje de Path indica la petición de comprobar que
se soporta la función de OAM de MPLS (FFD) y del correspondiente
valor del parámetro de configuración (20 ms). El mensaje de Path es
recibido en tiempo=t1 por CPE2, en el que, en el caso de que se
soporten las funciones de OAM de MPLS, los campos de FFD_check y
FFD_timer del mensaje de Path son despreciados, es decir, que son
transmitidos al CPE3 sin cambios. El CPE3 recibe en tiempo=t3 este
mensaje de Path que incluye FFD_check ="1" y FFD_timer=
"001" y, en caso de que soporte FFD period= 20 ms en el NE3,
transmite el mensaje de Resv en dirección contraria hacia el CPE1,
asignando FFD_check ="1"; Por el contrario, en caso de que no
se soporte FFD period=20 ms, transmite el mensaje de Resv asignando
FFD_check= "0" para indicar que FFD period= 20 ms no está
soportado (de manera que se mantiene el FFD period= 50 ms por
defecto). El CPE2 recibe en tiempo=t3 el mensaje de Resv y lo
transmite al CPE1 manteniendo FFD_check sin cambios. Finalmente, si
el CPE1 recibe en tiempo=t4 el mensaje de Resv que incluye FFD_check
="1", esto indica que soporta un período de generación de FFD=
20 ms para la correspondiente conexión. Tras recibir el mensaje de
Resv que incluye OAM_check ="1" y FFD_check ="1", el CPE1
de fuente transmite un mensaje de Path que incluye
OAM_activation_Path="1" para indicar la activación de las
funciones de OAM de MPLS en cada elemento de red de la conexión y
después empieza a transmitir paquetes de FFD al NE2 de acuerdo con
un período de tiempo= 20 ms. En el tiempo=t5 el CPE2 intermedio
recibe el mensaje de Path que incluye OAM_activation_Path="1",
y a continuación transmite el mensaje de Path al CPE3 manteniendo
OAM_activation_Path="1", y después empieza a transmitir
paquetes de FFD al NE3 de acuerdo con un período de tiempo= 20 ms.
Finalmente, el CPE3 de destino recibe el mensaje de Path que
incluye OAM_activation_Path="1" y después empieza a comprobar
si los paquetes de FFD son recibidos en el NE3 de acuerdo con el
período de tiempo= 20 ms, de manera que la monitorización de la
conexión del NE1 al NE3 pasando por el NE2 se activa.
La invención puede ventajosamente usarse también
para la configuración automática de un parámetro de conexión. Por
ejemplo en una red de MPLS se proporciona un Trail Termination
Source Identifier (TTSI - Identificador de Fuente de Finalización
de Rastro) para identificar de manera única una LSP; Este
identificador puede ser configurado en el CPE de fuente y ser
después transmitido al CPE de destino mediante un nuevo campo de un
nuevo objeto del mensaje de Path, de manera que el CPE de destino
puede comprobar periódicamente si el TTSI esperado es recibido
correctamente desde el CPE de fuente.
La Fig.2 muestra una primera realización en la
que la función específica y el valor del parámetro de configuración
correspondiente son comparados durante el establecimiento de la
conexión y durante la comprobación de si se soporta una función
genérica, pero es posible una segunda realización, en la que se
comprueba previamente si se soportan las funciones de OAM genéricas
(usando el OAM_check de los mensajes de Path y de Resv) y después,
en caso de que se soporten las funciones de OAM genéricas, se
comprueba si se soporta la función de OAM específica (usando el
FFD_check de los mensajes de Path y de Resv).
\vskip1.000000\baselineskip
La solución descrita requiere la definición de
sólo un nuevo objeto (LSP_ADDINFO), transportado por los mensajes
tanto de Path como de Resv, que incluye los campos de OAM_check,
OAM_activation_Path, FFD_check y FFD_timer transportados por los
dos mensajes, pero en el que los campos de OAM_activation_Path y
FFD_timer sólo son significativos cuando son transportados por el
mensaje de Path; esto significa que los campos de
OAM_activation_
Path y FFD_timer son también transportados por el mensaje de Resv pero no son significativos. Una segunda solución alternativa podría ser la definición de dos objetos diferentes, cada uno de ellos identificado por un valor de Class-Num diferente:
Path y FFD_timer son también transportados por el mensaje de Resv pero no son significativos. Una segunda solución alternativa podría ser la definición de dos objetos diferentes, cada uno de ellos identificado por un valor de Class-Num diferente:
- \bullet
- un primer objeto, transportado por el mensaje de Path e indicado por ejemplo con LSP_ADDINFO_Path, que incluye sólo los campos de OAM_check, OAM_activation_Path y FFD_timer;
- \bullet
- un segundo objeto, transportado por el mensaje de Resv e indicado por ejemplo con LSP_ADDINFO_Resv, que incluye sólo los campos de OAM_check y FFD_check.
Esta segunda solución tiene la ventaja de
minimizar el número de campos transportados por los mensajes de
Path y de Resv requeridos para llevar a cabo la invención, pero
tiene la desventaja de ser más compleja porque requiere la
definición de dos objetos diferentes.
El procedimiento de dos etapas es requerido sólo
en el caso de que la conexión no se haya establecido previamente;
por el contrario, en el caso de que la conexión en tiempo=t0 se haya
establecido ya, la comprobación de si se soportan las funciones de
OAM se lleva a cabo mediante el primer mensaje de Path transmitido
periódicamente desde la fuente al CPE de destino para refrescar la
configuración de la conexión, transmitiendo desde el CPE de fuente
el mensaje de Path que incluye un campo (OAM_check) que indica una
petición de comprobación (es decir, asignar OAM_check="1" en
el mensaje de Path) y activar la función de OAM (es decir,
transmisión de paquetes de OAM) inmediatamente después de la
transmisión de la petición. De acuerdo con esto, cada CPE intermedio
que soporta las funciones de OAM recibe la petición, la transmite
sin cambios al CPE subsiguiente hacia el CPE de destino e
inmediatamente después de la transmisión de la petición activa las
funciones de OAM. El CPE de destino, que soporta las funciones de
OAM, recibe la petición, transmite en la dirección contraria un
mensaje de Resv que incluye un campo (OAM_check) que indica que la
petición es soportada (es decir, que asigna OAM_check="1" en
el mensaje de Resv) e inmediatamente después de la transmisión de la
petición activa las funciones de OAM. Finalmente, el CPE de fuente
recibe la indicación de que las funciones de OAM están soportadas en
cada elemento de red de la conexión, que es un mensaje de Resv que
incluye OAM_check="1". Por el contrario, en el caso de que la
función de OAM no sea soportada en un elemento de red intermedio, el
paquete de OAM recibido es borrado y el mensaje de Path es
transmitido al elemento de red subsiguiente que incluye OAM_check =
"0", mientras que en el caso de que la función de OAM no sea
soportada en un elemento de red de destino, el paquete de OAM
recibido es borrado y el mensaje de Resv es transmitido en la
dirección contraria que incluye OAM_check= "0".
El método puede ventajosamente usarse no sólo
para la activación de una función, sino también para la
desactivación. En referencia específicamente al ejemplo de la Fig.1
de funciones de OAM previamente activadas mediante el protocolo
RSVP, la desactivación se lleva a cabo transmitiendo desde el CPE de
fuente al CPE de destino el objeto LSP_ADDINFO del mensaje de Path
que incluye los campos OAM_check= "0" y OAM_activation_Path=
"0": Cuando un CPE intermedio o de destino detecta un cambio
tanto del OAM_check como del OAM_activation_Path del mensaje de
Path de "0" a "1", las funciones de OAM son desactivadas.
La desactivación de las funciones de OAM puede ser llevada a cabo
alternativamente borrando el objeto LSP_ADDINFO del mensaje de Path
transmitido desde el CPE de fuente al CPE de destino: cuando un CPE
intermedio o un CPE de destino detecta un cambio de un mensaje de
Path que incluye el objeto LSP_ADDINFO a un mensaje de Path que no
incluye el objeto LSP_ADDINFO, las funciones de OAM son
desactivadas.
El método de la invención puede ser llevado a
cabo mediante un programa de software; el lenguaje de programación
del programa de software puede ser por ejemplo C o C++. El método de
la invención puede también ser llevado a cabo (mediante el programa
de software) en un CPE de una red de ASON. El CPE incluye hardware
para llevar a cabo el método como por ejemplo un microprocesador
externo o bien incorporado en un ASIC (Application Specific
Integrated Circuit - Circuito Integrado Específico para una
Aplicación) o bien en una FPGA (Field Programmable Gate Array -
Matriz de Puerta Programable para un Campo). El microprocesador de
un CPE de fuente está adaptado para transmitir mediante el
protocolo de señalización el mensaje de Path al CPE de destino y
para recibir mediante el protocolo de señalización el mensaje de
Resv desde el CPE de destino. El microprocesador de un CPE
intermedio está adaptado para recibir el mensaje de Path desde el
CPE de fuente o bien desde un CPE intermedio adyacente hacia el CPE
de fuente, para transmitir el primer mensaje al CPE de destino o
bien al CPE intermedio adyacente hacia el CPE de destino, para
recibir el segundo mensaje desde el CPE de destino o bien desde el
CPE intermedio adyacente hacia el CPE de destino y para transmitir
el segundo mensaje al CPE de fuente o bien al CPE intermedio
adyacente hacia el CPE de fuente. El microprocesador de un CPE de
destino está adaptado para recibir el mensaje de Path desde un CPE
adyacente y para transmitir el mensaje de Resv al CPE adyacente.
Los dibujos muestran dos dispositivos de red
diferentes, que son el CPE (por ejemplo el CPE1) y el NE controlado
(NE1), pero los dos dispositivos pueden también estar incluidos en
un dispositivo, definido por ejemplo red node (NN -
Nodo de Red). Por lo tanto un nodo de red de fuente (indicado con NN1) incluye el CPE1 y el NE1 (controlado por el CPE1), un nodo de red de destino (NN3) incluye el CPE3 y el NE3 (controlado por el CPE3) y un nodo de red intermedio (NN2) incluye el CPE2 y el NE2 (controlado por el CPE2).
Nodo de Red). Por lo tanto un nodo de red de fuente (indicado con NN1) incluye el CPE1 y el NE1 (controlado por el CPE1), un nodo de red de destino (NN3) incluye el CPE3 y el NE3 (controlado por el CPE3) y un nodo de red intermedio (NN2) incluye el CPE2 y el NE2 (controlado por el CPE2).
Claims (21)
1. Método para comprobar si se soporta una
función en los elementos de red de una red de telecomunicación,
incluyendo la red:
\bullet un elemento de red de fuente (NE1), un
elemento de red de destino (NE3) y al menos un elemento de red
intermedio (NE2);
\bullet un elemento de plano de control de
fuente (CPE1), un elemento de plano de control de destino (CPE3) y
al menos un elemento de plano de control intermedio (CPE2)
interconectados mediante mensajes de un protocolo de señalización,
para controlar el elemento de red de fuente, el elemento de red de
destino y el al menos un elemento de red intermedio respectivamente
para configurar una conexión desde el elemento de red de fuente al
elemento de red de destino pasando por el elemento de red
intermedio;
incluyendo el método, en el caso de que la
conexión no esté configurada, las siguientes etapas:
- transmitir un primer mensaje (de Path) desde
el elemento de plano de control de fuente al elemento de plano de
control de destino pasando por el al menos un elemento de plano de
control intermedio para indicar una petición de la configuración de
la conexión;
- recibir en el elemento de plano de control de
fuente un segundo mensaje (de Resv) transmitido desde el elemento
de plano de control de destino para indicar una respuesta a la
petición;
caracterizado porque
- el primer mensaje incluye un primer campo
(PATH MSG, OAM_check="1") para indicar una petición de
comprobación de si se soporta una función de OAM de operación,
administración y gestión de la conexión por cada elemento de red de
la conexión;
- el segundo mensaje incluye el primer campo
(RESV MSG, OAM_check="1") para indicar si la función de OAM es
soportada por cada elemento de red de la conexión.
\vskip1.000000\baselineskip
2. Método para comprobar si se soporta una
función en los elementos de red de una red de telecomunicación,
incluyendo la red:
\bullet un elemento de red de fuente, un
elemento de red de destino y al menos un elemento de red
intermedio;
\bullet un elemento de plano de control de
fuente CPE1, un elemento de plano de control de destino CPE3 y al
menos un elemento de plano de control intermedio CPE2
interconectados mediante mensajes de un protocolo de señalización,
para controlar el elemento de red de fuente, el elemento de red de
destino y el al menos un elemento de red intermedio respectivamente
para configurar una conexión desde el elemento de red de fuente al
elemento de red de destino pasando por el elemento de red
intermedio;
estando el método caracterizado porque
incluye, en el caso de que la conexión esté previamente configurada,
las siguientes etapas:
- transmitir un primer mensaje desde el elemento
de plano de control de fuente al elemento de plano de control de
destino pasando por el al menos un elemento de plano de control
intermedio, incluyendo el primer mensaje un primer campo (PATH MSG,
OAM_check="1") para indicar una petición de comprobación de si
se soporta una función de OAM de operación, administración y
gestión de la conexión por cada elemento de red de la conexión;
- llevar a cabo la activación de la función de
OAM en el elemento de red de fuente;
- recibir un segundo mensaje que incluye el
primer campo (RESV MSG, OAM_check="1") para indicar si la
función de OAM es soportada por cada elemento de red de la
conexión.
\vskip1.000000\baselineskip
3. Método de acuerdo con la reivindicación 1,
que incluye también, si recibe el segundo mensaje que indica que la
función de OAM es soportada por cada elemento de red, la siguiente
etapa:
- transmitir el primer mensaje desde el elemento
de plano de control de fuente al elemento de plano de control de
destino pasando por el al menos un elemento de plano de control
intermedio, incluyendo también el primer mensaje un segundo campo
(PATH MSG, OAM_activation_Path="1") para pedir la activación de
la función de OAM en cada elemento de red de la conexión.
\vskip1.000000\baselineskip
4. Método de acuerdo con la reivindicación 3,
que también lleva a cabo la activación de la función de OAM en el
elemento de red de fuente tras la transmisión del primer mensaje que
incluye el segundo campo.
\vskip1.000000\baselineskip
5. Método de acuerdo con cualquiera de las
reivindicaciones 1 a 4, caracterizado por:
- transmitir primer mensaje que incluye además
un tercer campo (PATH MSG, FFD_check="1") que indica una
petición de comprobar si se soporta una función de OAM específica
para la conexión y un cuarto campo (PATH MSG, FFD_timer= 20 ms) que
indica un valor del parámetro de configuración de la función de OAM
específica;
- recibir el segundo mensaje que incluye también
el tercer campo (RESV MSG, FFD_check="1") que indica si el
valor del parámetro de configuración es soportado.
\vskip1.000000\baselineskip
6. Método de acuerdo con las reivindicaciones 1
ó 2, que incluye también, tras la transmisión del primer mensaje,
las siguientes etapas:
- recibir en un elemento de plano de control
intermedio el primer mensaje desde el elemento de plano de control
de fuente o desde un elemento de plano de control intermedio
adyacente hacia el elemento de plano de control de fuente y
transmitir el primer mensaje al elemento de plano de control de
destino o a un elemento de plano de control adyacente hacia el
elemento de plano de control de destino, en el que:
\bullet en el caso de que cada elemento de red
comprendido entre el elemento de red de fuente y el elemento de red
intermedio soporten la función de OAM, transmitir el primer mensaje
que incluye el primer campo (PATH MSG, OAM_check="1") sin
cambios;
\bullet en el caso de que no se soporte la
función de OAM en al menos un elemento de red comprendido entre el
elemento de red de fuente y el elemento de red intermedio,
transmitir el primer mensaje que incluye el primer campo que indica
que la función de OAM no está soportada;
- recibir en el elemento de plano de control
intermedio el segundo mensaje desde el elemento de plano de control
de destino o desde el elemento de plano de control adyacente hacia
el elemento de plano de control de destino y transmitir a elemento
de plano de control de fuente o al elemento de plano de control
adyacente hacia el elemento de plano de control de fuente el
segundo mensaje que incluye el primer campo sin cambios.
\vskip1.000000\baselineskip
7. Método de acuerdo con la reivindicación 3,
que incluye también recibir en un elemento de plano de control
intermedio el primer mensaje que incluye el segundo campo (PATH MSG,
OAM_activation_Path="1") y transmitir al elemento de plano de
control adyacente hacia el elemento de plano de control de destino
el primer mensaje que incluye el segundo campo sin cambios.
8. Método de acuerdo con la reivindicación 7,
que lleva a cabo también la activación de la función de OAM en cada
elemento de red intermedio tras la transmisión del primer
mensaje.
\vskip1.000000\baselineskip
9. Método de acuerdo con las reivindicaciones 1,
2 ó 6, que incluye también las siguientes etapas tras la
transmisión del primer mensaje desde el elemento de plano de control
de fuente o desde un elemento de plano de control intermedio:
- recibir el primer mensaje en el elemento de
plano de control de destino y transmitir el segundo mensaje al
elemento de plano de control adyacente hacia el elemento de plano de
control de fuente, en el que:
\bullet en el caso de que se soporte la
función de OAM, transmitir el segundo mensaje ( de Resv) que incluye
el primer campo (RESV MSG, OAM_check="1") que indica que la
función de OAM es soportada por cada elemento de red;
\bullet en el caso de que no se soporte la
función de OAM, transmitir el segundo mensaje (de Resv) que incluye
el primer campo que indica que la función de OAM no está soportada
por cada elemento de red.
\vskip1.000000\baselineskip
10. Método de acuerdo con cualquiera de las
reivindicaciones 1 a 9, caracterizado porque el primer
mensaje y el segundo mensaje incluyen un quinto campo para indicar
los elementos de red de la conexión que no soporta la función de
OAM.
11. Método de acuerdo con cualquiera de las
reivindicaciones 1 a 10, en el que la red incluye una capa que
cumple la Multi-Protocol Label Switching.
12. Método de acuerdo con cualquiera de las
reivindicaciones 1 a 10, en el que la red incluye una capa que
cumple el protocolo de Ethernet.
13. Mensaje (RESV MSG) de un protocolo de
señalización que interconecta un elemento de plano de control de
fuente (CPE1), un elemento de plano de control de destino (CPE3) y
al menos un elemento de plano de control intermedio (CPE2) para
controlar un elemento de red de fuente (NE1), un elemento de red de
destino (NE3) y al menos un elemento de red intermedio (NE2)
respectivamente para configurar una conexión desde el elemento de
red de fuente al elemento de red de destino pasando por los
elementos de red intermedios,
caracterizado porque el mensaje es
transmitido desde el elemento de plano de control de destino al
elemento de plano de control de fuente e incluye un primer campo
(RESV MSG, OAM_check="1") que indica si una función de OAM de
operación, administración y gestión es soportada por cada elemento
de red de la conexión.
14. Mensaje de acuerdo con la reivindicación 13,
caracterizado porque el mensaje incluye también un tercer
campo (RESV MSG, FFD_check="1") que indica si una función de
OAM específica para la conexión y si un valor del parámetro de
configuración de la función de OAM específica están soportados por
cada elemento de red de la conexión.
15. Mensaje de acuerdo con las reivindicaciones
13 ó14, caracterizado porque el mensaje incluye también un
quinto campo para indicar los elementos de red de la conexión que no
soportan la función de OAM.
16. Elemento de plano de control de fuente
(CPE1) que incluye medios de hardware adaptados para llevar a cabo
el método de acuerdo con la reivindicación 1 ó 2, incluyendo el
elemento de plano de control de fuente medios de tratamiento
adaptados para transmitir mediante el protocolo de señalización el
primer mensaje al elemento de plano de control de destino (CPE3)
para indicar la petición de comprobar si se soporta la función de
OAM de la conexión en cada elemento de red de la conexión y
adaptados para recibir mediante el protocolo de señalización el
segundo mensaje desde el elemento de plano de control de destino
para indicar si la función de OAM es soportada por cada elemento de
red de la conexión.
17. Nodo de red de fuente que incluye un
elemento de plano de control de fuente (CPE1) de acuerdo con la
reivindicación 16 y que incluye un elemento de red de fuente (NE1)
controlado por el elemento de plano de control de fuente.
\vskip1.000000\baselineskip
18. Elemento de plano de control intermedio
(CPE2) que controla un elemento de red intermedio (NE2) de una red
de telecomunicación para la configuración de una conexión que pasa
por el elemento de red intermedio:
- incluyendo el elemento de plano de control
intermedio medios de tratamiento adaptados para recibir un primer
mensaje (PATH MSG) que indica una petición de la configuración de la
conexión, incluyendo el primer mensaje un primer campo (PATH MSG,
OAM_check="1") para indicar una petición de comprobar si se
soporta una función de OAM de operación, administración y gestión
en cada elemento de red de la conexión;
- tras recibir el primer mensaje, estando los
medios de tratamiento adaptados también para transmitir el primer
mensaje que incluye el primer campo para indicar si la función de
OAM es soportada por cada elemento de red de la conexión;
- tras la transmisión del primer mensaje,
estando los medios de tratamiento adaptados también para recibir un
segundo mensaje (de Resv) que indica una respuesta a la petición,
incluyendo el segundo mensaje el primer campo (RESV MSG,
OAM_check="1") para indicar si la función de OAM es soportada
por cada elemento de red de la conexión;
- tras recibir el segundo mensaje, estando los
medios de tratamiento adaptados también para transmitir el segundo
mensaje que incluye el primer campo sin cambios.
\vskip1.000000\baselineskip
19. Nodo de red intermedio que incluye un
elemento de plano de control intermedio (CPE2) de acuerdo con la
reivindicación 18 y que incluye el elemento de red intermedio (NE2)
controlado por el elemento de plano de control intermedio.
\vskip1.000000\baselineskip
20. Elemento de plano de control de destino
(CPE3) que controla un elemento de red de destino (NE3) de una red
de telecomunicación para la configuración de una conexión al
elemento de red de destino:
- incluyendo el elemento de plano de control de
destino medios de tratamiento adaptados para recibir un primer
mensaje (PATH MSG) que indica una petición de la configuración de la
conexión, incluyendo el primer mensaje un primer campo (PATH MSG,
OAM_check="1") para indicar una petición de comprobar si se
soporta una función de OAM de operación, administración y gestión
por cada elemento de red de la conexión;
- tras recibir el primer mensaje, estando los
medios de tratamiento adaptados también para transmitir un segundo
mensaje (de Resv) que indica una respuesta a la petición, incluyendo
el segundo mensaje el primer campo (RESV MSG, OAM_check="1")
para indicar si la función de OAM es soportada por cada elemento de
red de la conexión.
\vskip1.000000\baselineskip
21. Nodo de red de destino que incluye un
elemento de plano de control de destino (CPE3) de acuerdo con la
reivindicación 20 y que incluye el elemento de red de destino (NE3)
controlado por el elemento de plano de control de destino.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP05291106A EP1727316B1 (en) | 2005-05-23 | 2005-05-23 | Extension to RSVP protocol for supporting OAM configuration |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2335019T3 true ES2335019T3 (es) | 2010-03-18 |
Family
ID=34993129
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES05291106T Active ES2335019T3 (es) | 2005-05-23 | 2005-05-23 | Extension del protocolo rsvp para soportar configuracion oam. |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US8270300B2 (es) |
| EP (1) | EP1727316B1 (es) |
| CN (1) | CN1870504A (es) |
| AT (1) | ATE445950T1 (es) |
| DE (1) | DE602005017125D1 (es) |
| ES (1) | ES2335019T3 (es) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2372541T3 (es) * | 2006-12-01 | 2012-01-23 | Zte Corporation | Procedimiento de consulta de enrutado jerárquico para red óptica de conmutación automática. |
| PL1947803T3 (pl) | 2007-01-22 | 2018-01-31 | Nokia Solutions & Networks Gmbh & Co Kg | Obsługa jednostek sieciowych w systemie komunikacyjnym |
| US8472325B2 (en) * | 2007-05-10 | 2013-06-25 | Futurewei Technologies, Inc. | Network availability enhancement technique for packet transport networks |
| WO2009012812A1 (en) * | 2007-07-23 | 2009-01-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for stream adaption in a packet switched network |
| CN101355441B (zh) | 2007-07-27 | 2012-04-04 | 华为技术有限公司 | 一种配置操作管理维护属性的方法、系统及设备 |
| PL2595350T3 (pl) * | 2007-08-01 | 2019-04-30 | Ericsson Telefon Ab L M | Zapewnianie OAM opartych na GMPLS |
| CN100589416C (zh) * | 2007-10-30 | 2010-02-10 | 中兴通讯股份有限公司 | 一种自动交换光网络系统中业务产生告警时的维护方法 |
| US8199750B1 (en) * | 2007-12-18 | 2012-06-12 | World Wide Packets, Inc. | Communicating with a control plane using a forwarding information format and control plane processing of packets devoid of a virtual switch identifier |
| CN101471813B (zh) * | 2007-12-29 | 2012-06-27 | 华为技术有限公司 | 一种实现跨域维护管理的配置方法、系统及设备 |
| US8477600B2 (en) * | 2008-01-18 | 2013-07-02 | Futurewei Technologies, Inc. | Composite transport functions |
| CN101494552B (zh) | 2008-01-23 | 2011-05-18 | 华为技术有限公司 | 一种建立业务连接的方法、系统和装置 |
| US20100014531A1 (en) * | 2008-07-18 | 2010-01-21 | Alcatel Lucent | Establishing pseudowires in packet switching networks |
| CN101826989B (zh) | 2009-03-02 | 2013-11-06 | 华为技术有限公司 | 一种故障处理方法和装置 |
| CN101515827B (zh) | 2009-03-31 | 2011-12-07 | 中兴通讯股份有限公司 | 一种自动交换光网络业务错联阻错的方法及系统 |
| CN101877892B (zh) * | 2009-04-29 | 2012-11-07 | 华为技术有限公司 | 节点关联通道能力的协商方法及节点设备 |
| US8149730B1 (en) | 2009-05-12 | 2012-04-03 | Juniper Networks, Inc. | Methods and apparatus related to packet generation and analysis |
| US8174991B1 (en) | 2009-06-29 | 2012-05-08 | Juniper Networks, Inc. | Methods and apparatus related to analysis of test packets |
| US8423827B2 (en) * | 2009-12-28 | 2013-04-16 | International Business Machines Corporation | Topology based correlation of threshold crossing alarms |
| US8780896B2 (en) | 2010-12-29 | 2014-07-15 | Juniper Networks, Inc. | Methods and apparatus for validation of equal cost multi path (ECMP) paths in a switch fabric system |
| US8798077B2 (en) | 2010-12-29 | 2014-08-05 | Juniper Networks, Inc. | Methods and apparatus for standard protocol validation mechanisms deployed over a switch fabric system |
| EP2666260A1 (en) * | 2011-01-21 | 2013-11-27 | Telefonaktiebolaget LM Ericsson (PUBL) | Timer value negotiation for path configuration based on rsvp-te |
| US9065723B2 (en) | 2011-04-04 | 2015-06-23 | Jds Uniphase Corporation | Unaddressed device communication from within an MPLS network |
| US9042402B1 (en) | 2011-05-10 | 2015-05-26 | Juniper Networks, Inc. | Methods and apparatus for control protocol validation of a switch fabric system |
| US10715353B2 (en) * | 2017-05-15 | 2020-07-14 | Ciena Corporation | Virtual local area network identifiers for service function chaining fault detection and isolation |
| US11101882B1 (en) * | 2020-06-17 | 2021-08-24 | Ciena Corporation | Low order regenerator with high order traffic conditioning in optical transport network |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5940400A (en) * | 1996-11-06 | 1999-08-17 | Motorola, Inc. | Method, device, wireless transceiver and computer for providing collision detection in wireless carrier sense multiple access systems |
| US6295284B1 (en) * | 1998-12-23 | 2001-09-25 | Qualcomm. Inc. | Method and apparatus for providing fair access in a group communication system |
| IT1312034B1 (it) * | 1999-03-29 | 2002-04-04 | Servizi Fiduciari Sefi S P A | Procedimento per la invalidazione di documenti in genere e dibanconote in particolare, particolarmente per trasporto valori. |
| US6560654B1 (en) * | 1999-10-12 | 2003-05-06 | Nortel Networks Limited | Apparatus and method of maintaining timely topology data within a link state routing network |
| GB0005363D0 (en) * | 2000-03-06 | 2000-04-26 | Nokia Networks Oy | Interworking in a communication system |
| US20020087699A1 (en) * | 2000-07-31 | 2002-07-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Dynamic QoS management in differentiated services using bandwidth brokers, RSVP aggregation and load control protocols |
| MXPA03010157A (es) * | 2001-05-09 | 2004-03-10 | Nokia Corp | Metodo para indicar a un equipo de usuario que debe registrarse. |
| FI112140B (fi) * | 2001-05-23 | 2003-10-31 | Nokia Corp | Informaation kommunikointi |
| US7483411B2 (en) * | 2001-06-04 | 2009-01-27 | Nec Corporation | Apparatus for public access mobility LAN and method of operation thereof |
| US7013342B2 (en) * | 2001-12-10 | 2006-03-14 | Packeteer, Inc. | Dynamic tunnel probing in a communications network |
| US7092361B2 (en) * | 2001-12-17 | 2006-08-15 | Alcatel Canada Inc. | System and method for transmission of operations, administration and maintenance packets between ATM and switching networks upon failures |
| US7177295B1 (en) * | 2002-03-08 | 2007-02-13 | Scientific Research Corporation | Wireless routing protocol for ad-hoc networks |
| US7068600B2 (en) * | 2002-04-29 | 2006-06-27 | Harris Corporation | Traffic policing in a mobile ad hoc network |
| US7453851B2 (en) * | 2002-06-20 | 2008-11-18 | Spyder Navigations L.L.C. | QoS signaling for mobile IP |
| EP1529391A1 (en) * | 2002-08-14 | 2005-05-11 | Nokia Corporation | Layered compression architecture for multi-hop header compression |
| KR100640328B1 (ko) * | 2002-09-19 | 2006-10-30 | 삼성전자주식회사 | 이더넷 수동형광가입자망에서 오에이엠 기능 디스커버리방법 |
| US7428383B2 (en) * | 2003-02-28 | 2008-09-23 | Intel Corporation | Architecture, method and system of WDM-based photonic burst switched networks |
| KR100987230B1 (ko) * | 2003-04-10 | 2010-10-12 | 삼성전자주식회사 | 무선 통신 시스템에서 방송/다중 서비스 방법 및 시스템 |
| US7626947B2 (en) * | 2003-08-27 | 2009-12-01 | Telefonaktiebolaget L M Ericsson (Publ) | Dynamic OAM for signaled connections (DOSC) |
| US7340169B2 (en) * | 2003-11-13 | 2008-03-04 | Intel Corporation | Dynamic route discovery for optical switched networks using peer routing |
| TWI240518B (en) * | 2003-11-24 | 2005-09-21 | Ind Tech Res Inst | System using label switching techniques to support QoS for mobile ad-hoc networks and its label distributing and switching method |
| US7639674B2 (en) * | 2004-10-25 | 2009-12-29 | Alcatel Lucent | Internal load balancing in a data switch using distributed network processing |
| US7558199B1 (en) * | 2004-10-26 | 2009-07-07 | Juniper Networks, Inc. | RSVP-passive interfaces for traffic engineering peering links in MPLS networks |
-
2005
- 2005-05-23 AT AT05291106T patent/ATE445950T1/de not_active IP Right Cessation
- 2005-05-23 ES ES05291106T patent/ES2335019T3/es active Active
- 2005-05-23 EP EP05291106A patent/EP1727316B1/en not_active Not-in-force
- 2005-05-23 DE DE602005017125T patent/DE602005017125D1/de active Active
-
2006
- 2006-05-16 CN CNA2006100825014A patent/CN1870504A/zh active Pending
- 2006-05-18 US US11/435,829 patent/US8270300B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP1727316A1 (en) | 2006-11-29 |
| DE602005017125D1 (de) | 2009-11-26 |
| CN1870504A (zh) | 2006-11-29 |
| US20060262728A1 (en) | 2006-11-23 |
| ATE445950T1 (de) | 2009-10-15 |
| US8270300B2 (en) | 2012-09-18 |
| EP1727316B1 (en) | 2009-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2335019T3 (es) | Extension del protocolo rsvp para soportar configuracion oam. | |
| US8531976B2 (en) | Locating tunnel failure based on next-next hop connectivity in a computer network | |
| EP2319209B1 (en) | Methods for establishing a traffic connection and an associated monitoring connection | |
| US9774523B2 (en) | Technique for determining whether to reestablish fast rerouted primary tunnels based on backup tunnel path quality feedback | |
| US7765306B2 (en) | Technique for enabling bidirectional forwarding detection between edge devices in a computer network | |
| EP1748599B1 (en) | A ring carrying network and the method for implementing the service carry | |
| US7197008B1 (en) | End-to-end notification of local protection using OAM protocol | |
| WO2021185208A1 (zh) | 报文处理方法、装置、设备及存储介质 | |
| US8160055B1 (en) | System and methods for identifying network path performance | |
| EP1662717A1 (en) | Improved restoration in a telecommunication network | |
| ES2395939T3 (es) | Método para realizar una asociación en una red óptica de conmutación automática | |
| US8681637B2 (en) | Methods for establishing a traffic connection and an associated monitoring connection | |
| ES2844098T3 (es) | Método de establecimiento de trayectos de servicio, dispositivo de nodo y sistema | |
| ES2383380T3 (es) | Un método para transmitir un mensaje de control en una red MPLS en anillo | |
| Petersson | MPLS based recovery mechanisms | |
| Suhaimy et al. | Analysis of MPLS-TP network for different applications | |
| Rozycki et al. | Failure detection and notification in GMPLS control plane | |
| Wang | Optical Ethernet: Making Ethernet carrier class for professional services | |
| Autenrieth et al. | Components of MPLS recovery supporting differentiated resilience requirements | |
| Sripad et al. | Signaling communications network architectures for Service Intelligent™ optical transport networks | |
| Liu | Ethernet transmisson solution for SONET/SDH system | |
| Zubairi | An Overview of Optical Network Bandwidth and Fault Management |