ES2365300T3 - Extensión de indicación de tráfico para gestión de fallos de conectividad. - Google Patents

Extensión de indicación de tráfico para gestión de fallos de conectividad. Download PDF

Info

Publication number
ES2365300T3
ES2365300T3 ES09157877T ES09157877T ES2365300T3 ES 2365300 T3 ES2365300 T3 ES 2365300T3 ES 09157877 T ES09157877 T ES 09157877T ES 09157877 T ES09157877 T ES 09157877T ES 2365300 T3 ES2365300 T3 ES 2365300T3
Authority
ES
Spain
Prior art keywords
traffic
ccm
tesi
field
network port
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
ES09157877T
Other languages
English (en)
Inventor
Panagiotis Saltsidis
Zhemin Ding
Kevin Nolish
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2365300T3 publication Critical patent/ES2365300T3/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)
  • Maintenance And Management Of Digital Transmission (AREA)

Abstract

Método de detección de una desadaptación entre un primer Puerto de Red Dorsal de Cliente y un segundo Puerto de Red Dorsal de Cliente, en el que los Puertos de Red Dorsal de Cliente se conectan mediante una Instancia de Servicio de Ingeniería de Tráfico, TESI, (21) de trabajo, y una TESI (22) de protección, caracterizado porque dicho método comprende las etapas de: fijar un campo (41) de Tráfico en un primer Mensaje de Comprobación de Continuidad, CCM, enviado desde el primer Puerto de Red Dorsal de Cliente al segundo Puerto de Red Dorsal de Cliente en la TESI de trabajo o protección, indicando dicho campo de Tráfico una TESI actual que está siendo utilizada para transportar el tráfico desde el primer Puerto de Red Dorsal de Cliente; recibir por parte del primer Puerto de Red Dorsal de Cliente, un segundo CCM enviado desde el segundo Puerto de Red Dorsal de Cliente, en donde el segundo Puerto de Red Dorsal de Cliente indica en el segundo CCM, qué TESI se está utilizando para transportar el tráfico desde el segundo Puerto de Red Dorsal de Cliente; determinar si el campo de Tráfico en el segundo CCM coincide con el campo de Tráfico en el primer CCM; y detectar una desadaptación cuando el campo de Tráfico en el segundo CCM no coincide con el campo de Tráfico en el primer CCM.

Description

Campo técnico
La presente invención se refiere a redes de comunicación. Más específicamente, y sin limitaciones, la invención trata sobre un indicador de campo de Tráfico para ser usado en mensajes de Gestión de Fallos de Conectividad (CFM) con el fin de proporcionar un control mejorado de Trayectos Conmutados de Ethernet (ESPs).
Antecedentes
La Gestión de Fallos de Conectividad (CFM), tal como se describe en IEEE 802.1ag, es un componente clave del funcionamiento, la administración, y el mantenimiento para Ethernet como operador. La IEEE 802.1ag especifica protocolos, procedimientos, y objetos gestionados para la detección, la verificación, y el aislamiento de fallos de extremo-a-extremo. La IEEE 802.1ag establece objetos gestionados, denominados Asociaciones de Mantenimiento (MAs), para verificar la integridad de una instancia de servicio individual intercambiando mensajes de CFM. El alcance de una MA queda determinado por su Dominio de Gestión (MD), que describe una región de red en la que se gestiona la conectividad y el rendimiento. Cada MA asocia dos o más Puntos Extremos de Asociación de Mantenimiento (MEPs) y permite que los Puntos Intermedios de Asociación de Mantenimiento (MIPs) soporten la detección y el aislamiento de fallos.
Para la detección de fallos se usa un protocolo de comprobación de continuidad. Cada MEP transmite periódicamente Mensajes de Comprobación de Conectividad (CCMs) y realiza un seguimiento de CCMs recibidos desde otros MEPs en la misma asociación de mantenimiento.
La FIG. 1 ilustra el formato de una Unidad de Datos de Protocolo (PDU) 10 de CFM, actual. Un Encabezamiento de CFM común consta de un campo 11 de nivel de Dominio de Gestión (MD), un campo Versión 12, un campo CódigoOperación 13, un campo Banderas 14, y un campo 15 de Desviación con respecto al Primer Tiempo, Longitud, y Valor (TLV). El campo Banderas 14 del Encabezamiento de CFM Común se divide actualmente en tres partes:
1.
Campo RDI (un bit, el bit más significativo);
2.
Campo Reservado (4 bits), y
3.
Campo Intervalo de CCM (los tres bits menos significativos).
El planteamiento de Puentes entre Redes Dorsales de Proveedores – Ingeniería de Tráfico (PBB-TE), tal como se describe en la IEEE 802.1Qay, se diseñó para proporcionar una ingeniería completa de tráfico de trayectos en una red con puentes. El PBB-TE elimina la necesidad de la realización de operaciones de aprendizaje e inundación por parte de dispositivos de red dorsal. En lugar de usar el Protocolo de Árbol de Expansión Múltiple/Protocolo de Árbol de Expansión Rápido (MSTP/RSTP) para evitar bucles, el PBB-TE usa un plano de gestión o un plano de control externo para crear entradas de tabla estáticas de filtrado en los puentes de los componentes.
El PBB-TE es una tecnología de Ethernet orientada a conexión, que usa una tupla configurada estáticamente que consta de la Dirección de Destino de Red Dorsal (B-DA), Dirección de Origen de Red Dorsal (B-SA), y el ID de VLAN de Red Dorsal (B-VID) para crear un trayecto PBB-TE. Al trayecto proporcionado se le denomina Trayecto Conmutado de Ethernet (ESP). Dos ESPs de punto-a-punto co-encaminados con las mismas direcciones MAC de Puerto de Red Dorsal de Cliente (CBP) forman un servicio MAC bidireccional, que se denomina Instancia de Servicio de Ingeniería de Tráfico (TESI) de punto-a-punto.
El PBB-TE soporta la conmutación bidireccional de protección por trayectos 1:1. Se proporcionan dos TESIs de punto-a-punto. Una TESI se configura como TESI “de trabajo” y la otra como TESI “de protección”. En condiciones normales, el tráfico se transmite a través de la TESI de trabajo. En el caso de o bien una avería de la TESI de trabajo o bien una solicitud administrativa específica, el tráfico se conmuta a la TESI de protección. Opcionalmente, se pueden configurar trayectos protegidos 1:1 por PBB-TE para permitir compartir la carga. En este caso, en ambas TESIs en un grupo de protección puede haber presentes servicios de cliente indicados mediante un flujo de tramas con Etiqueta I (I-TAGed).
La FIG. 2 ilustra un grupo 20 de protección de PBB-TE convencional. El grupo de protección incluye una TESI 21 de trabajo, una TESI 22 de protección, un extremo cercano (Componente B Este) 23, y un extremo lejano (Componente B Oeste) 24. El extremo cercano (Componente B Este) incluye Puertos de Redes de Proveedores (PNPs) 25a y 25b y un Puerto de Red Dorsal de Cliente (CBP) 26. El extremo lejano (Componente B Oeste) incluye PNPs 27a y 27b y el CBP 28. Cada TESI es monitorizada por una MA independiente, y cada MA tiene dos MEPs. Uno está situado en el CBP 26 del extremo cercano; el otro está situado en el CBP 28 del extremo lejano. Cuando el MEP del extremo cercano detecta la pérdida de CCMs, se lo notifica al MEP del extremo lejano enviando un CCM con una bandera de Indicador de Defecto Distante (RDI). Ambos extremos tienen conocimiento del fallo (o bien por pérdida de CCMs o
5
15
25
35
45
bien recibiendo el CCM con la bandera RDI), de manera que en los dos extremos se ejecuta la conmutación de protección hacia la TESI de protección. Cuando se resuelve el fallo, el tráfico se puede conmutar de nuevo a la TESI 21 de trabajo o puede permanecer en la TESI 22 de protección según el modo configurado (reversible o no reversible).
La ITU-T G.8031 define el protocolo de Conmutación de Protección Automática (APS) y mecanismos de conmutación de protección lineal para conexiones de Subredes de Ethernet basadas en VLAN, en redes de transporte de Ethernet. Se soportan las arquitecturas de conmutación de protección 1:1 y 1+1 lineal con conmutación unidireccional y bidireccional.
La versión actual del PBB-TE (2.0) soporta la conmutación bidireccional de protección por trayectos 1:1 basada en el modelo de la ITU-T G.8031. Las diferencias entre la funcionalidad de protección del PBB-TE y la funcionalidad de protección de la ITU-T G.8031 son:
•
ITU-T G-8031 define el protocolo APS como la Unidad de Datos de Protocolo (PDU) de señalización mientras que el PBB-TE reutiliza/extiende la PDU de CCM para evitar la complejidad innecesaria de una PDU de señalización adicional.
•
En el PBB-TE, se considera que un sistema de gestión “fuera-de-banda” coordina los dos extremos del servicio protegido pertenecientes a un único dominio.
•
En el PBB-TE, un flujo protegido se identifica mediante una TESI mientras que en la G.8031 el flujo protegido se identifica mediante un ID de VLAN (VID).
En una publicación relacionada de Siemens, “Metro Ethernet Deployment with Siemens PBB-TE, SURPASS, hiD 6600”, con fecha de 13 de marzo de 2007, se describe la detección de fallos en un grupo de protección de PBB-TE que comprende una TESI de trabajo y una TESI de protección. Se envían CCMs entre puntos extremos para monitorizar el estado de la TESI de trabajo. El grupo conmuta a la TESI de protección si se detecta un fallo. No obstante, la publicación de Siemens no aborda las desadaptaciones entre los puntos extremos.
De modo similar, la Publicación de Solicitud de Patente U.S. n.º 2007/0268817 describe la detección de fallos en sub-dominios principales y auxiliares dentro de un dominio de difusión general. Se monitorizan asociaciones de mantenimiento principales y auxiliares, y cuando se detecta un fallo dentro de la asociación de mantenimiento de un subdominio principal, se produce una conmutación a la asociación de mantenimiento de un subdominio auxiliar. No obstante, igual que con la publicación de Siemens, la solicitud no aborda las desadaptaciones entre los puntos extremos.
Adicionalmente, la patente U.S. n.º 7.093.027 da a conocer un mecanismo de protección rápido para conexiones solamente de VLAN y para conexiones que se basan parcialmente en la tecnología VLAN y parcialmente en la tecnología MPLS. El mecanismo prevé un cambio de una VLAN principal a una VLAN alternativa en caso de un fallo de enlace. Una vez más, la patente no aborda las desadaptaciones entre los puntos extremos.
En la conmutación de protección bidireccional 1:1, puede producirse una desadaptación entre las posiciones del puente/selector del extremo cercano 23 y el extremo lejano 24. Para mantener el funcionamiento correcto de la red, esta desadaptación debería ser detectada y comunicada al operador de la red. A continuación, el operador de la red puede resolver el defecto. Existen dos tipos de desadaptación en la conmutación de protección bidireccional 1:1:
•
Desadaptación incompleta de la conmutación de protección; y
•
Desadaptación de la configuración de trabajo/protección.
Todavía en referencia a la FIG. 2, se representa gráficamente un escenario en el que se produce una desadaptación incompleta de la conmutación de protección. En este ejemplo, debido a un funcionamiento defectuoso del hardware, el extremo cercano (Componente B Este) 23 no consigue realizar el cambio, pero envía un RDI al extremo lejano (Componente B Oeste) 24. El extremo lejano conmuta a la TESI 22 de protección mientras que el extremo cercano sigue todavía en la TESI 21 de trabajo. De manera similar, también puede producirse una desadaptación cuando el extremo cercano conmuta a la TESI de protección, pero el extremo lejano no consigue realizar la conmutación cuando recibe el RDI.
También puede producirse una desadaptación debido a una configuración errónea. Por ejemplo, un extremo puede estar configurado para enviar tráfico sobre la TESI 21 de trabajo mientras que el otro extremo está configurado para enviar tráfico sobre la TESI 22 de protección. De manera similar, un extremo puede estar configurado en el modo reversible mientras que el otro extremo está configurado en el modo no reversible. En este caso, la desadaptación se produce cuando se resuelve un fallo.
Basándose en los mecanismos existentes, existen dos formas de abordar el problema de la desadaptación, aunque ninguno de ellos es deseable en un entorno PBB-TE.
En primer lugar, se puede utilizar el protocolo APS para detectar la desadaptación (como en la G.8031), pero este planteamiento es demasiado complicado. En la G.8031, el protocolo APS está diseñado para arquitecturas de conmutación de protección 1:1 y 1+1 Lineal con conmutación unidireccional y bidireccional. Puesto que el PBB-TE se centra únicamente en la conmutación de protección bidireccional 1:1, y el PBB-TE ya considera un sistema de gestión “fuera-de-banda” para coordinar ambos extremos en un único dominio, el protocolo APS conlleva muchísimas funcionalidades duplicadas innecesarias. Adicionalmente, la adición del protocolo APS a un puente crea cambios importantes en la arquitectura.
La FIG. 3 ilustra un ejemplo de cómo se puede detectar una desadaptación en la conmutación de protección bidireccional 1:1 por medio de un Sistema de Soporte de Operaciones/Sistema de Gestión de Red (OSS/NMS) “fuera-de-banda” 31. Aunque la desadaptación se puede detectar usando el protocolo APS, sin el APS se puede utilizar el OSS/NMS. En la etapa 32, el OSS/NMS solicita la posición del selector/puente tanto del extremo cercano (Componente B Este) 23 como del extremo lejano (Componente B Oeste) 24. En la etapa 33, el extremo cercano y el extremo lejano comunican sus posiciones de selector/puente al OSS/NMS. En la etapa 34, el OSS/NMS compara las posiciones comunicadas para detectar una desadaptación. Para el entorno PBB-TE, este proceso es demasiado lento, y presenta la desventaja adicional de tener que ser iniciado proactivamente por un operador.
Sumario
Es deseable disponer de un mecanismo sencillo basado en la arquitectura de puentes existente para monitorizar constantemente las entidades de trabajo/protección y comunicar de forma inmediata y automática a un operador la aparición de una desadaptación. La presente invención proporciona una mejora de CCM basada en la arquitectura de puentes existente para resolver el problema de la desadaptación. La misma se ajusta completamente a la normativa existente. Adicionalmente, la presente invención se puede usar para ajustar el intervalo de CCM con el fin de ahorrar ancho de banda. En ciertos escenarios, también es posible usar la invención para proporcionar soporte de señalización dentro de la banda para solicitudes de operadores.
En una realización, la presente invención utiliza uno de los cuatro bits reservados en el campo Banderas de un CCM para indicar el estado del tráfico. Por ejemplo, el bit puede indicar si el tráfico se transmite en la TESI monitorizada por estos CCMs. A este bit se le hace referencia en el presente documento como “campo de Tráfico”.
La desadaptación es detectada por el MEP correspondiente cuando el campo de Tráfico de CCMs transmitidos y CCMs recibidos no coincide durante un periodo de tiempo predefinido (por ejemplo, 50 ms o más). El defecto de desadaptación se resuelve cuando el MEP correspondiente recibe el primer CCM que indica el mismo campo de Tráfico que sus CCMs transmitidos.
De este modo, en una realización, la presente invención trata sobre un método de control del tráfico entre un primer elemento de red y un segundo elemento de red conectados mediante un trayecto de red de trabajo y un trayecto de red de protección. El método incluye las etapas de fijar un campo de Tráfico en un mensaje de configuración enviado entre el primer y el segundo elementos de red, indicando el campo de Tráfico qué trayecto de red se está utilizando para transportar el tráfico; recibir el mensaje de configuración en uno de los elementos de red; y emprender acciones para controlar el tráfico basándose en un valor del campo de Tráfico en el mensaje de configuración recibido. La etapa de emprender acciones puede incluir comparar el valor del campo de Tráfico en el mensaje de configuración recibido con un valor de un campo de Tráfico en mensajes de configuración enviados desde el elemento de red receptor, y cuando el valor del campo de Tráfico en el mensaje de configuración recibido no coincide con el valor del campo de Tráfico en mensajes de configuración enviados desde el elemento de red receptor, trasladar el tráfico de su trayecto actual al otro trayecto de red. En una realización, el tráfico se traslada únicamente cuando el valor del campo de Tráfico en el mensaje de configuración recibido no ha coincidido con el valor del campo de Tráfico en mensajes de configuración enviados desde el elemento de red receptor durante un periodo de tiempo predefinido.
En una realización particular, el trayecto de red de trabajo y el trayecto de red de protección son Instancias de Servicio de Ingeniería de Tráfico (TESIs) bidireccionales de punto-a-punto, y la etapa de fijar un campo de Tráfico en un mensaje de configuración incluye fijar un campo de Tráfico en un Mensaje de Comprobación de Conectividad (CCM) utilizando un bit reservado dentro de un campo Banderas como campo de Tráfico.
Utilizando el campo de Tráfico en los CCMs, un MEP puede determinar la carga de tráfico en las diferentes TESIs. Cuando no hay tráfico en una TESI determinada, el MEP como respuesta puede incrementar un intervalo de CCM en la TESI determinada. De modo similar, si el campo de Tráfico indica posteriormente que el tráfico se ha conmutado a la TESI determinada, el MEP como respuesta puede reducir dinámicamente el intervalo de CCM en la TESI determinada. El MEP también puede responder a cambios del valor del campo de Tráfico en CCMs recibidos para trasladar tráfico desde una TESI a la otra con el fin de equilibrar el tráfico entre las TESIs. De modo similar, el MEP puede fijar el campo de Tráfico en respuesta a la solicitud de un operador de trasladar el tráfico de una TESI a otra.
En otra realización, la presente invención trata sobre un MEP asociado a un primer Puerto de Red Dorsal de Cliente para controlar tráfico entre el primer Puerto de Red Dorsal de Cliente y un segundo Puerto de Red Dorsal de Cliente, en donde los Puertos de Red Dorsal de Cliente están conectados mediante una TESI de trabajo y una TESI de protección. El MEP incluye medios para fijar un campo de Tráfico en un primer CCM enviado desde el primer Puerto de Red Dorsal de Cliente al segundo Puerto de Red Dorsal de Cliente, indicando el campo de Tráfico qué TESI se está utilizando para transportar el tráfico. El MEP incluye también medios para recibir un segundo CCM enviado desde el segundo Puerto de Red Dorsal de Cliente; medios para determinar si el campo de Tráfico en el segundo CCM coincide con el campo de Tráfico en el primer CCM; y medios para emprender acciones con el fin de controlar el tráfico basándose en un resultado obtenido a partir de los medios de determinación. Las acciones emprendidas pueden incluir trasladar tráfico de una TESI a otra cuando los campos de Tráfico no coincidan. Esto se puede realizar para equilibrar la carga de tráfico o como respuesta a una solicitud de un operador. El MEP también puede incrementar o reducir dinámicamente el intervalo de CCM en la TESI determinada, como respuesta a la carga de tráfico.
Breve descripción de los dibujos
A continuación, se describirán detalladamente las características esenciales de la invención mostrando realizaciones preferidas, en referencia a las figuras adjuntas, en las cuales:
la FIG. 1 (Técnica Anterior) ilustra el formato de una Unidad de Datos de Protocolo (PDU) de CFM existente;
la FIG. 2 (Técnica Anterior) ilustra un grupo de protección de PBB-TE existente;
la FIG. 3 (Técnica Anterior) ilustra un ejemplo de cómo se puede detectar una desadaptación en la conmutación de protección bidireccional 1:1 por medio de un Sistema de Soporte de Operaciones/Sistema de Gestión de Red (OSS/NMS) “fuera-de-banda”;
la FIG. 4 ilustra el formato de un campo Banderas modificado de acuerdo con una realización de la presente invención;
la FIG. 5 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención cuando el MEP envía CCMs;
la FIG. 6 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención cuando el MEP recibe CCMs;
la FIG. 7 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención para proporcionar un intervalo de CCM adaptativo;
la FIG. 8 (Técnica Anterior) ilustra un escenario existente en el que una solicitud de un operador se puede enviar únicamente al NE/EMS en un extremo de una instancia de servicio de PBB-TE protegida; y
la FIG. 9 ilustra una realización del método de la presente invención para proporcionar soporte de señalización dentro de la banda, para una orden administrativa;
la FIG. 10 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención para soportar la compartición de carga; y
la FIG. 11 es un diagrama de bloques simplificado de un MEP en una realización de la presente invención.
Descripción detallada
La FIG. 4 ilustra el formato de un campo Banderas 14’ modificado de acuerdo con una realización de la presente invención. En esta realización, uno de los bits reservados se utiliza para indicar el estado del tráfico del trayecto monitorizado. A este bit se le hace referencia en el presente documento como “campo de Tráfico” 41.
La FIG. 5 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención cuando el MEP envía CCMs. En la etapa 51, el MEP compara su propia dirección de destino y el ID de VLAN de Red Dorsal (B-VID) con respecto a las entradas de la Dirección de Destino de Red Dorsal (B-DA) y del B-VID en la tabla de instancias de servicio de red dorsal. En la etapa 52, se determina si la dirección de destino y el B-VID del MEP están en la tabla de instancias de servicio de red dorsal. En caso negativo, el método se traslada a la etapa 53 en donde el MEP fija el campo de Tráfico de CCMs salientes a “0”. No obstante, si la dirección de destino y el B-VID del MEP están en la tabla de instancias de servicio de red dorsal, el método se traslada en cambio a la etapa 54 en donde el MEP fija el campo de Tráfico de CCMs salientes a “1”.
La FIG. 6 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención cuando el MEP recibe CCMs. En la etapa 61, el MEP inspecciona el campo 41 de Tráfico de los CCMs recibidos. En la etapa 62, se determina si el campo de Tráfico recibido es diferente del campo de Tráfico de CCMs enviados por este MEP durante por lo menos un periodo de tiempo predefinido (por ejemplo, 50 ms). En caso negativo, el método se traslada a la etapa 63 donde no se detecta ninguna desadaptación. No obstante, si el campo de Tráfico recibido es diferente del campo de Tráfico de CCMs enviados por este MEP durante por lo menos el periodo de tiempo predefinido, el método se traslada en cambio a la etapa 64 donde se anuncia un defecto de desadaptación.
Existen aplicaciones adicionales del campo 41 de Tráfico en la mensajería de CCM. Por ejemplo, el campo de Tráfico se puede utilizar para proporcionar un intervalo de CCM adaptativo. El OAM de Ethernet proporciona un mecanismo para comprobar la conectividad en una red de un proveedor mediante la transmisión de tramas de CCM con un intervalo especificado. Un intervalo menor reduce el tiempo para detectar un fallo de conectividad pero lo hace a costa de una fracción mayor de tráfico de CCM suplementario. Usando el nuevo campo 41 de Tráfico, se mantiene informados sobre el estado del tráfico a los MEPs o bien en la TESI 21 de trabajo o bien en la TESI 22 de protección.
La FIG. 7 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención para proporcionar un intervalo de CCM adaptativo. En la etapa 71, no hay tráfico en la TESI monitorizada mediante los CCMs. Por lo tanto, en la etapa 72, se incrementa el intervalo de CCM para ahorrar ancho de banda. En la etapa 73, el tráfico se conmuta a la TESI monitorizada. En la etapa 74, se informa a los MEPs correspondientes sobre el cambio de tráfico por medio del campo 41 de Tráfico. En la etapa 75, los MEPs reducen dinámicamente el intervalo de CCM.
El campo 41 de Tráfico también se puede usar para la señalización dentro de la banda, de órdenes administrativas. El mecanismo de conmutación de protección debe permitir un accionamiento manual por parte del operador de red con independencia del estado de la red. De forma similar a la detección de las desadaptaciones, existen dos opciones para difundir órdenes administrativas desde operadores de red. En primer lugar, se puede usar el protocolo APS, pero tal como se ha descrito anteriormente, el APS es complicado y redundante para el PBB-TE. En segundo lugar, se puede utilizar un sistema de gestión (por ejemplo, OMS/NMS) para notificar a ambos extremos sobre una instancia de servicio de PBB-TE. En ciertos escenarios, sin embargo, se pueden originar solicitudes de operadores desde un único extremo tal como un Elemento de Red (NE) o Sistema de Gestión de Elementos (EMS). La presente invención proporciona una forma adecuada para propagar solicitudes de operadores hacia el otro extremo.
La FIG. 8 ilustra un escenario existente en el que una solicitud de un operador únicamente se puede enviar al NE/EMS en un extremo de una instancia de servicio de PBB-TE protegida. Un NMS 81 controla el EMS 82 en la red 1 de acceso, el EMS 83 en la red central, y el EMS 84 en la red 2 de acceso. Se puede recibir una solicitud 85 de operador en el EMS 82 de la red 1 de acceso. El EMS 82 controla el NE 86 para reenviar la solicitud de operador hacia los NEs centrales 87 y 88. Con el fin de coordinar la conmutación del otro extremo, la solicitud del operador se debe comunicar dentro de la banda, a través de la instancia de servicio de PBB-TE, reduciendo de este modo el ancho de banda disponible.
La FIG. 9 ilustra una realización del método de la presente invención para proporcionar un soporte de señalización dentro de la banda, para una orden administrativa. En esta realización, se utiliza el nuevo campo 41 de Tráfico para la señalización dentro de la banda, de la solicitud del operador a través del grupo de protección de PBB-TE. En este ejemplo, la orden está destinada a la conmutación manual desde la TESI de trabajo a la TESI de protección.
En la etapa 91, se envía una solicitud de operador denominada “conmutación manual de trabajo a protección” hacia el extremo lejano de la instancia de servicio de PBB-TE protegida (Componente B Oeste) 24. En la etapa 92, el Componente B Oeste del extremo lejano conmuta el tráfico desde la TESI 21 de trabajo a la TESI 22 de protección y cambia el campo 41 de Tráfico. En la etapa 93, el extremo lejano comunica su estado al NMS. En la etapa 94, el extremo cercano (Componente B Este) 23 detecta una desadaptación en el campo 41 de Tráfico de CCMs recibidos. En la etapa 95, el extremo cercano (Componente B Este) comunica el defecto de la desadaptación al NMS y, en la etapa 96, el NMS notifica al extremo cercano (Componente B Este) 23 su estado. A continuación, el extremo cercano conmuta el tráfico desde la TESI 21 de trabajo a la TESI 22 de protección. Obsérvese en este ejemplo que el extremo cercano no puede decir si la desadaptación fue debida a una solicitud de una conmutación manual de un operador, a una conmutación forzada, o a un defecto de desadaptación. Por lo tanto, el extremo cercano debe obtener su información de estado a partir del NMS.
La FIG. 10 es un diagrama de flujo que ilustra las etapas de una realización del método de la presente invención para soportar la compartición de carga. En la etapa 101, se fija el bit 41 de campo de Tráfico en cada TESI de CCM que está transportando tráfico de cliente. En la etapa 102, un operador determina que debería sacarse tráfico de una TESI determinada. En la etapa 103, el operador traslada el tráfico fuera de la TESI determinada simplemente desactivando el bit de campo de Tráfico.
La FIG. 11 es un diagrama de bloques simplificado de un MEP 110 en una realización de la presente invención. El MEP está asociado a un Puerto de Red Dorsal de Cliente (CBP) tal como el CBP 26 ó el CBP 28 en la FIG. 1. El MEP monitoriza el tráfico entre CBP asociado y otro CBP conectado mediante una TESI 21 de trabajo y una TESI 22 de protección. El MEP incluye un fijador 111 de campos de Tráfico para fijar el campo de Tráfico en CCMs a enviar por un transmisor 112 de CCM. El campo de Tráfico se puede fijar fijando el bit reservado 41 (FIG. 4) en el campo Banderas del CCM. Un receptor 113 de CCM recibe CCMs enviados desde el otro CBP, y una unidad 114 de comparación de campos de Tráfico compara el campo de Tráfico en CCMs enviados con el campo de Tráfico en CCMs recibidos para determinar si los campos de Tráfico coinciden.
Cuando el campo de Tráfico en CCMs recibidos coincide con el campo de Tráfico en CCMs enviados, el MEP continúa enviando el tráfico sobre su TESI actual. Cuando el campo de Tráfico en CCMs recibidos no coincide con el campo de Tráfico en CCMs enviados, el MEP puede anunciar un defecto de desadaptación y trasladar de forma correspondiente el tráfico. En una realización, el MEP incluye un temporizador 115, y el tráfico se traslada únicamente cuando el temporizador indica que el campo de Tráfico en CCMs recibidos no ha coincido con el valor del campo de Tráfico en CCMs enviados durante un periodo de tiempo predefinido.
El MEP también puede incluir una unidad 116 de determinación de carga para determinar la carga de tráfico en cada TESI 21 y 22. Si una TESI determinada no tiene tráfico, un controlador 117 de intervalos de CCM puede incrementar el intervalo de CCM como respuesta en la TESI determinada. Posteriormente, la unidad de determinación de carga puede detectar, a partir del campo de Tráfico en CCMs recibidos, que el tráfico se ha conmutado a la TESI determinada. Como respuesta, el controlador de intervalos de CCM puede reducir dinámicamente el intervalo de CCM en la TESI determinada.
En otra realización, la unidad 116 de determinación de carga puede comunicar la carga de tráfico en cada TESI 21 y 22 a un equilibrador 118 de carga de TESI. El equilibrador de carga de TESI traslada el tráfico de una TESI a la otra con el fin de equilibrar el tráfico entre las TESIs.
El MEP 110 también puede recibir solicitudes de operadores para controlar el tráfico. Las solicitudes se envían al fijador 111 de campos de Tráfico, que cambia el campo de Tráfico en CCMs salientes a un valor correspondiente a la solicitud del operador. El otro CBP recibe los CCMs y responde al campo de Tráfico.
Obsérvese también que el bit 41 del campo de Tráfico se puede usar en mensajes de CCM en el nivel de la ID de Servicio (I-SID) para permitir una comprobación cruzada y una conmutación a un nivel de servicio por cada cliente.
Las operaciones del MEP pueden ser controladas por un procesador 119 que ejecute instrucciones de programa de ordenador almacenadas en una memoria 120.
Aunque en los dibujos adjuntos se han ilustrado realizaciones preferidas de la presente invención y las mismas se han descrito en la Descripción Detallada anterior, se entiende que la invención no se limita a las realizaciones dadas a conocer, sino que tiene la capacidad de experimentar numerosos reordenamientos, modificaciones, y sustituciones sin desviarse con respecto al alcance de la invención tal como se define por medio de las reivindicaciones siguientes.

Claims (16)

  1. REIVINDICACIONES
    1. Método de detección de una desadaptación entre un primer Puerto de Red Dorsal de Cliente y un segundo Puerto de Red Dorsal de Cliente, en el que los Puertos de Red Dorsal de Cliente se conectan mediante una Instancia de Servicio de Ingeniería de Tráfico, TESI, (21) de trabajo, y una TESI (22) de protección, caracterizado porque dicho método comprende las etapas de:
    fijar un campo (41) de Tráfico en un primer Mensaje de Comprobación de Continuidad, CCM, enviado desde el primer Puerto de Red Dorsal de Cliente al segundo Puerto de Red Dorsal de Cliente en la TESI de trabajo o protección, indicando dicho campo de Tráfico una TESI actual que está siendo utilizada para transportar el tráfico desde el primer Puerto de Red Dorsal de Cliente;
    recibir por parte del primer Puerto de Red Dorsal de Cliente, un segundo CCM enviado desde el segundo Puerto de Red Dorsal de Cliente, en donde el segundo Puerto de Red Dorsal de Cliente indica en el segundo CCM, qué TESI se está utilizando para transportar el tráfico desde el segundo Puerto de Red Dorsal de Cliente;
    determinar si el campo de Tráfico en el segundo CCM coincide con el campo de Tráfico en el primer CCM; y
    detectar una desadaptación cuando el campo de Tráfico en el segundo CCM no coincide con el campo de Tráfico en el primer CCM.
  2. 2. Método según la reivindicación 1, que comprende además las etapas de:
    cuando el campo de Tráfico en el segundo CCM coincide con el campo de Tráfico en el primer CCM, continuar enviando el tráfico desde el primer Puerto de Red Dorsal de Cliente en la TESI actual; y
    cuando el campo de Tráfico en el segundo CCM no coincide con el campo de Tráfico en el primer CCM, trasladar el tráfico por parte del primer Puerto de Red Dorsal de Cliente desde la TESI actual a la otra TESI.
  3. 3.
    Método según la reivindicación 2, en el que la etapa de trasladar el tráfico a la otra TESI incluye trasladar el tráfico únicamente cuando el valor del campo de Tráfico en el segundo CCM no ha coincidido con el valor del campo de Tráfico en una pluralidad de CCMs enviados desde el primer Puerto de Red Dorsal de Cliente durante un periodo de tiempo predefinido.
  4. 4.
    Método según la reivindicación 1, en el que la etapa de fijar el campo de Tráfico en el primer CCM incluye utilizar un bit reservado dentro de un campo Banderas como campo de Tráfico.
  5. 5.
    Método según la reivindicación 1, que comprende además las etapas de:
    determinar, a partir de la desadaptación, que no hay tráfico en una identificada de las TESIs; e
    incrementar un intervalo de CCM en la TESI identificada, en donde el intervalo de CCM es un intervalo especificado para la transmisión periódica de CCMs.
  6. 6. Método según la reivindicación 5, que comprende además las etapas de:
    detectar posteriormente, a partir del campo de Tráfico, que se ha conmutado posteriormente tráfico a la TESI identificada; y
    reducir dinámicamente el intervalo de CCM en la TESI identificada en respuesta a la detección de que se ha conmutado tráfico a la TESI identificada.
  7. 7.
    Método según la reivindicación 4, que comprende además responder a cambios del valor del campo de Tráfico en CCMs recibidos para trasladar tráfico desde una TESI a la otra con el fin de equilibrar el tráfico entre las TESIs.
  8. 8.
    Método según la reivindicación 1, en el que la etapa de fijar el campo de Tráfico incluye fijar el campo de Tráfico en respuesta a la recepción de una solicitud de un operador en el primer o el segundo Puertos de Red Dorsal de Cliente.
  9. 9.
    Punto Extremo de Asociación de Mantenimiento, MEP, (110) asociado a un primer Puerto de Red Dorsal de Cliente para detectar una desadaptación entre el primer Puerto de Red Dorsal de Cliente y un segundo Puerto de Red Dorsal de Cliente, en el que los Puertos de Red Dorsal de Cliente se conectan mediante una Instancia de Servicio de Ingeniería de Tráfico, TESI, (21) de trabajo, y una TESI (22) de protección, caracterizado porque dicho MEP comprende:
    medios (111) para fijar un campo (41) de Tráfico en un primer Mensaje de Comprobación de Continuidad, CCM, enviado desde el primer Puerto de Red Dorsal de Cliente al segundo Puerto de Red Dorsal de Cliente en la TESI de trabajo o protección, indicando dicho campo de Tráfico una TESI actual que está siendo utilizada para transportar el tráfico desde el primer Puerto de Red Dorsal de Cliente;
    medios (113) para recibir por parte del primer Puerto de Red Dorsal de Cliente, un segundo CCM enviado desde el segundo Puerto de Red Dorsal de Cliente, en donde el segundo Puerto de Red Dorsal de Cliente indica en el segundo CCM, qué TESI se está utilizando para transportar el tráfico desde el segundo Puerto de Red Dorsal de Cliente;
    medios (114) para determinar si el campo de Tráfico en el segundo CCM coincide con el campo de Tráfico en el primer CCM; y
    medios (118) para detectar una desadaptación cuando el campo de Tráfico en el segundo CCM no coincide con el campo de Tráfico en el primer CCM.
  10. 10. MEP según la reivindicación 9, que comprende además:
    medios para continuar enviando el tráfico desde el primer Puerto de Red Dorsal de Cliente en la TESI actual cuando el campo de Tráfico en el segundo CCM coincide con el campo de Tráfico en el primer CCM; y
    medios para trasladar el tráfico por parte del primer Puerto de Red Dorsal de Cliente desde la TESI actual a la otra TESI cuando el campo de Tráfico en el segundo CCM no coincide con el campo de Tráfico en el primer CCM.
  11. 11.
    MEP según la reivindicación 10, que comprende además un temporizador, en donde los medios para trasladar el tráfico trasladan el tráfico únicamente cuando el temporizador indica que el campo de Tráfico no ha coincidido con el valor del campo de Tráfico en una pluralidad de CCMs enviados, durante un periodo de tiempo predefinido.
  12. 12.
    MEP según la reivindicación 9, en el que los medios para fijar un campo de Tráfico en el primer CCM están adaptados para utilizar un bit reservado dentro de un campo Banderas como campo de Tráfico.
  13. 13.
    MEP según la reivindicación 9, que comprende además: medios para determinar, a partir de la desadaptación, que no hay tráfico en una identificada de las TESIs; y medios para incrementar un intervalo de CCM en la TESI identificada, en donde el intervalo de CCM es un
    intervalo especificado para la transmisión periódica de CCMs.
  14. 14.
    MEP según la reivindicación 13, que comprende además:
    medios para detectar posteriormente, a partir del campo de Tráfico en el segundo CCM, que se ha conmutado posteriormente tráfico a la TESI identificada; y
    medios para reducir dinámicamente el intervalo de CCM en la TESI identificada en respuesta a la detección de que se ha conmutado tráfico a la TESI identificada.
  15. 15.
    MEP según la reivindicación 9, que comprende además medios sensibles a cambios del campo de Tráfico en el segundo CCM para trasladar tráfico desde una TESI a la otra con el fin de equilibrar el tráfico entre las TESIs.
  16. 16.
    MEP según la reivindicación 9, que comprende además: medios para recibir una solicitud de un operador para controlar el tráfico; y medios para cambiar el campo de Tráfico en el primer mensaje de CCM a un valor correspondiente a la solicitud
    del operador.
ES09157877T 2008-04-16 2009-04-14 Extensión de indicación de tráfico para gestión de fallos de conectividad. Active ES2365300T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US4530208P 2008-04-16 2008-04-16
US45302P 2008-04-16

Publications (1)

Publication Number Publication Date
ES2365300T3 true ES2365300T3 (es) 2011-09-28

Family

ID=40806746

Family Applications (2)

Application Number Title Priority Date Filing Date
ES11150807T Active ES2402806T3 (es) 2008-04-16 2009-04-14 Extensión de indicación del tráfico de gestión de fallos de conectividad
ES09157877T Active ES2365300T3 (es) 2008-04-16 2009-04-14 Extensión de indicación de tráfico para gestión de fallos de conectividad.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES11150807T Active ES2402806T3 (es) 2008-04-16 2009-04-14 Extensión de indicación del tráfico de gestión de fallos de conectividad

Country Status (15)

Country Link
US (2) US8169896B2 (es)
EP (2) EP2372952B1 (es)
JP (1) JP5350461B2 (es)
CN (1) CN102007729B (es)
AR (1) AR071371A1 (es)
AT (1) ATE512519T1 (es)
AU (1) AU2009237405B2 (es)
BR (1) BRPI0910949B1 (es)
CA (1) CA2722247C (es)
CL (1) CL2009000922A1 (es)
DK (1) DK2110987T3 (es)
ES (2) ES2402806T3 (es)
PL (2) PL2110987T3 (es)
WO (1) WO2009127931A1 (es)
ZA (1) ZA201006935B (es)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250047553A1 (en) * 2023-08-04 2025-02-06 Ciena Corporation Enhanced fault isolation in connectivity fault management (CFM)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
WO2005089241A2 (en) 2004-03-13 2005-09-29 Cluster Resources, Inc. System and method for providing object triggers
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
CA2586763C (en) 2004-11-08 2013-12-17 Cluster Resources, Inc. System and method of providing system jobs within a compute environment
US8782231B2 (en) 2005-03-16 2014-07-15 Adaptive Computing Enterprises, Inc. Simple integration of on-demand compute environment
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
WO2006108187A2 (en) 2005-04-07 2006-10-12 Cluster Resources, Inc. On-demand access to compute resources
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
CA2722247C (en) 2008-04-16 2016-12-06 Telefonaktiebolaget L M Ericsson (Publ) Connectivity fault management traffic indication extension
US8018863B2 (en) * 2008-09-09 2011-09-13 Telefonaktiebolaget L M Ericsson Reducing CC message transmission in a provider network
US9106524B2 (en) * 2008-09-11 2015-08-11 Rpx Clearinghouse Llc Protection for provider backbone bridge traffic engineering
US8218433B2 (en) * 2009-01-07 2012-07-10 Alcatel Lucent Monitoring connectivity in ring networks
CN101908983B (zh) * 2009-06-08 2014-09-10 中兴通讯股份有限公司 以太网局部段保护的联合检测方法及系统
WO2011024187A2 (en) * 2009-07-08 2011-03-03 Tejas Networks Limited A protection switching method and system
US8458322B2 (en) 2009-07-24 2013-06-04 Cisco Technology, Inc. Dynamic management of maintenance association membership in a computer network
US20130107444A1 (en) 2011-10-28 2013-05-02 Calxeda, Inc. System and method for flexible storage and networking provisioning in large scalable processor installations
US8599863B2 (en) 2009-10-30 2013-12-03 Calxeda, Inc. System and method for using a multi-protocol fabric module across a distributed server interconnect fabric
US9465771B2 (en) 2009-09-24 2016-10-11 Iii Holdings 2, Llc Server on a chip and node cards comprising one or more of same
US20110103391A1 (en) * 2009-10-30 2011-05-05 Smooth-Stone, Inc. C/O Barry Evans System and method for high-performance, low-power data center interconnect fabric
US9876735B2 (en) 2009-10-30 2018-01-23 Iii Holdings 2, Llc Performance and power optimized computer system architectures and methods leveraging power optimized tree fabric interconnect
US9054990B2 (en) 2009-10-30 2015-06-09 Iii Holdings 2, Llc System and method for data center security enhancements leveraging server SOCs or server fabrics
US9077654B2 (en) 2009-10-30 2015-07-07 Iii Holdings 2, Llc System and method for data center security enhancements leveraging managed server SOCs
US9648102B1 (en) 2012-12-27 2017-05-09 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US9311269B2 (en) 2009-10-30 2016-04-12 Iii Holdings 2, Llc Network proxy for high-performance, low-power data center interconnect fabric
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US9680770B2 (en) 2009-10-30 2017-06-13 Iii Holdings 2, Llc System and method for using a multi-protocol fabric module across a distributed server interconnect fabric
NZ599908A (en) * 2009-11-30 2014-01-31 Ericsson Telefon Ab L M Method and apparatus for supporting mismatch detection
JP2011135259A (ja) * 2009-12-24 2011-07-07 Nec Access Technica Ltd 暗号化システム、通信装置、暗号化方法及び暗号化プログラム
CN102291245B (zh) * 2010-06-21 2015-08-12 中兴通讯股份有限公司 一种检测错配故障的方法及维护终端点
JP5480189B2 (ja) * 2011-03-28 2014-04-23 エヌ・ティ・ティ・コミュニケーションズ株式会社 ネットワーク監視装置、ネットワーク試験方法、パス情報管理方法、及びプログラム
US20130003528A1 (en) * 2011-07-01 2013-01-03 Fujitsu Network Communications, Inc. Joint near-end and far-end state machine for service protection networks
US9092594B2 (en) 2011-10-31 2015-07-28 Iii Holdings 2, Llc Node card management in a modular and large scalable server system
JP5891945B2 (ja) * 2012-05-23 2016-03-23 富士通株式会社 通信制御装置、及び通信制御方法
WO2014009963A1 (en) * 2012-07-10 2014-01-16 Indian Institute Of Technology, Bombay Method and apparatus for optimizing and scaling control plane traffic in carrier ethernet transport networks
JP6107269B2 (ja) * 2013-03-19 2017-04-05 富士通株式会社 トランスポンダ及び光伝送装置
EP2858302B1 (en) * 2013-08-09 2016-10-12 Huawei Technologies Co., Ltd. Connectivity check method of service stream link, related apparatus and system
JP2015046783A (ja) * 2013-08-28 2015-03-12 富士通株式会社 伝送装置、伝送方法及び伝送プログラム
JP6743494B2 (ja) * 2016-06-03 2020-08-19 富士通株式会社 伝送システム、通信装置及びパス切替方法
CN106656449B (zh) * 2016-11-02 2019-11-22 华为技术有限公司 一种协商周期的方法、设备和系统
EP3847782B1 (en) * 2018-09-06 2025-08-13 Nokia Technologies Oy Automated roaming service level agreements between network operators via security edge protection proxies in a communication system environment
CN110247797A (zh) * 2019-06-04 2019-09-17 深圳市中航比特通讯技术有限公司 一种在多点eth连通时精确远端错误指示系统
US12244486B2 (en) * 2021-03-23 2025-03-04 Adtran, Inc. Communication resilience in a network
CN113438112B (zh) * 2021-06-25 2022-12-20 瑞斯康达科技发展股份有限公司 一种故障检测的方法、装置、和设备及介质
CN115001944B (zh) * 2022-05-26 2025-01-21 苏州盛科通信股份有限公司 Ccm检测周期的修改方法、装置、电子设备及存储介质
WO2025041239A1 (ja) * 2023-08-21 2025-02-27 日本電信電話株式会社 通信制御装置

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5689244A (en) * 1994-06-24 1997-11-18 Sony Corporation Communication system and electronic apparatus
US6463475B1 (en) * 1997-09-26 2002-10-08 3Com Corporation Method and device for tunnel switching
JP2000022650A (ja) * 1998-07-03 2000-01-21 Fujitsu Ltd 冗長系切換モード設定方式
US6657970B1 (en) * 1999-02-26 2003-12-02 Cisco Technology, Inc. Method and apparatus for link state determination in voice over frame-relay networks
JP2000269939A (ja) * 1999-03-17 2000-09-29 Nec Corp 伝送路切替系異常監視方法及び装置
JP2002152135A (ja) * 2000-09-04 2002-05-24 Mitsubishi Electric Corp 光多分岐通信システム
GB2372670B (en) * 2001-02-27 2003-01-08 3Com Corp Optimisation of network configuration
US7093027B1 (en) * 2002-07-23 2006-08-15 Atrica Israel Ltd. Fast connection protection in a virtual local area network based stack environment
JP4035820B2 (ja) * 2003-01-27 2008-01-23 富士通アクセス株式会社 回線切替装置及びデータ伝送システム及び回線切替方法
JP2004266560A (ja) * 2003-02-28 2004-09-24 Hitachi Information Technology Co Ltd ネットワーク装置および通信回線監視方法
JP2005269507A (ja) * 2004-03-22 2005-09-29 Nec Corp 監視制御情報転送方法／プログラム／プログラム記録媒体／システム、ネットワーク装置
US20070268817A1 (en) * 2006-05-22 2007-11-22 Nortel Networks Limited Method and system for protecting a sub-domain within a broadcast domain
US20070274239A1 (en) * 2006-05-26 2007-11-29 Dell Products L.P. System and method for automatic detection of network port configuration mismatch
CN101179479A (zh) * 2006-11-09 2008-05-14 华为技术有限公司 一种以太网的操作管理和维护报文的传输方法、系统和节点
US8400912B2 (en) * 2007-06-27 2013-03-19 World Wide Packets, Inc. Activating a tunnel upon receiving a control packet
US7839795B2 (en) * 2007-12-17 2010-11-23 Ciena Corporation Carrier Ethernet with fault notification
CA2722247C (en) 2008-04-16 2016-12-06 Telefonaktiebolaget L M Ericsson (Publ) Connectivity fault management traffic indication extension

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250047553A1 (en) * 2023-08-04 2025-02-06 Ciena Corporation Enhanced fault isolation in connectivity fault management (CFM)
US12587437B2 (en) * 2023-08-04 2026-03-24 Ciena Corporation Enhanced fault isolation in connectivity fault management (CFM)

Also Published As

Publication number Publication date
EP2372952B1 (en) 2013-01-09
JP2011518512A (ja) 2011-06-23
EP2110987B1 (en) 2011-06-08
US20110026397A1 (en) 2011-02-03
PL2372952T3 (pl) 2013-06-28
ATE512519T1 (de) 2011-06-15
DK2110987T3 (da) 2011-09-26
EP2110987A1 (en) 2009-10-21
CA2722247A1 (en) 2009-10-22
AU2009237405A1 (en) 2009-10-22
AU2009237405B2 (en) 2013-09-26
EP2372952A1 (en) 2011-10-05
JP5350461B2 (ja) 2013-11-27
CN102007729B (zh) 2013-11-06
ES2402806T3 (es) 2013-05-09
AR071371A1 (es) 2010-06-16
CL2009000922A1 (es) 2011-01-07
US8593945B2 (en) 2013-11-26
ZA201006935B (en) 2011-12-28
US20120195191A1 (en) 2012-08-02
BRPI0910949B1 (pt) 2020-09-15
BRPI0910949A2 (pt) 2016-01-05
CN102007729A (zh) 2011-04-06
PL2110987T3 (pl) 2011-10-31
WO2009127931A1 (en) 2009-10-22
US8169896B2 (en) 2012-05-01
CA2722247C (en) 2016-12-06

Similar Documents

Publication Publication Date Title
ES2365300T3 (es) Extensión de indicación de tráfico para gestión de fallos de conectividad.
ES2396313T3 (es) Un sistema y un método de conmutación de protección de red Ethernet en un dominio de puente de red troncal de proveedor-ingeniería de tráfico
ES2705798T3 (es) Provisión de OAM basada en GMPLS
US8259590B2 (en) Systems and methods for scalable and rapid Ethernet fault detection
US9521055B2 (en) Network connectivity management
US9755957B2 (en) Pseudowire control channel for signaling events
US20180091445A1 (en) Evpn designated forwarder state propagation to customer edge devices using connectivity fault management
US9088438B2 (en) Using Ethernet ring protection switching with computer networks
US9185025B2 (en) Internetworking and failure recovery in unified MPLS and IP networks
US8929203B2 (en) Method and apparatus for supporting mismatch detection
BR112012022549B1 (pt) Método e sistema para realizar acessibilidade da rota de destino no anel de acesso da rede de transporte de pacotes
WO2012068996A1 (zh) 链路状态检测方法和装置
EP2553870B1 (en) An operations, administrations and management proxy and a method for handling operations, administrations and management messages
JP2009516463A (ja) Ｖｐｌｓリモート故障表示
EP2573977A1 (en) Subnet protection method and device for transport multi-protocol label switching (tmpls) network
CN103716238B (zh) 双宿以太网的保护切换方法以及实施该方法的分布式网元
JP2007312091A (ja) ルーチング装置および障害復旧方法
CN105871716A (zh) 基于vrrp的链路监测方法及系统
US20210036954A1 (en) Common carrier network device, network system, and program