ES2437995T3 - Mecanismo de indicación y supresión de alarmas (AIS) en una red OAM Ethernet - Google Patents

Mecanismo de indicación y supresión de alarmas (AIS) en una red OAM Ethernet Download PDF

Info

Publication number
ES2437995T3
ES2437995T3 ES05745576.8T ES05745576T ES2437995T3 ES 2437995 T3 ES2437995 T3 ES 2437995T3 ES 05745576 T ES05745576 T ES 05745576T ES 2437995 T3 ES2437995 T3 ES 2437995T3
Authority
ES
Spain
Prior art keywords
oam
ais
domain
level
ethernet
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.)
Expired - Lifetime
Application number
ES05745576.8T
Other languages
English (en)
Inventor
David Elie-Dit-Cosaque
Kamakshi Sridhar
Maarten Petrus Joseph Vissers
Tony Van Kerckhove
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Application granted granted Critical
Publication of ES2437995T3 publication Critical patent/ES2437995T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • 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/0681—Configuration of triggering conditions
    • 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
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • 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/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss

Landscapes

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

Abstract

Un procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples nivelesjerárquicos designados de dominios de Operaciones, Administración y Mantenimiento, OAM, en el que cadadominio OAM está limitado por nodos de Punto Extremo de Mantenimiento, MEP, que limitan una pluralidad denodos de Punto Intermedio de Mantenimiento, MIP, que comprende: transmitir una primera trama de Indicación ySupresión de Alarmas, AIS, de Ethernet, por medio de al menos un nodo MIP dispuesto en un primer dominioOAM de nivel jerárquico inferior en la red Ethernet (100), tras detectar un fallo en dicho primer dominio OAM denivel jerárquico inferior, para su recepción por al menos un nodo MEP que limita dicho primer dominio OAM; trasrecibir dicha primera trama Ethernet AIS, generar mediante dicho al menos un nodo MEP que limita dicho primerdominio una segunda trama Ethernet AIS para su transmisión a un segundo nodo MEP dispuesto en un segundodominio OAM de nivel jerárquico superior, incluyendo dicha segunda trama Ethernet AIS una indicación de nivelque indica que se ha detectado un fallo en dicho primer dominio OAM de nivel jerárquico inferior; determinar unfallo en dicho segundo dominio OAM de nivel jerárquico superior en la red Ethernet (100) por medio de dichosegundo nodo MEP y, en respuesta a dicha segunda trama Ethernet AIS que incluye la indicación de nivel queindica que se ha detectado un fallo en dicho primer dominio OAM de nivel jerárquico inferior, suprimir la generaciónen dicho segundo dominio OAM, por medio de dicho segundo nodo MEP dispuesto en el segundo nivel jerárquicosuperior, de una alarma debida al fallo determinado en dicho segundo dominio OAM de nivel jerárquico superior.

Description

Mecanismo de indicación y supresión de alarmas (AIS) en una red OAM Ethernet
Reivindicación de Prioridad
La presente solicitud reivindica prioridad en base a las siguientes solicitudes de patente Estadounidenses anteriores: (i) “ETHERNET ALARM INDICATION SIGNAL (EthAIS)”, Solicitud Provisional Nº 60/569.722, presentada el 10 de Mayo de 2004, a nombre de David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten Petrus JoseFIG Vissers and Tony Van Kerckhove; (ii) “ENHANCEMENTS TO ETHERNET AIS”, Solicitud Provisional Nº 60/586.254, presentada el 8 de Julio de 2004, a nombre de David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten Petrus JoseFIG Vissers and Tony Van Kerckhove; y (iii) “MECANISMO DEthAIS INDICACIÓN Y SUPRESION DEthAIS ALARMAS (AIS) EN UNA RED OAM ETHERNET”, Solicitud de Utilidad Nº 11/023.784, presentada el 28 de Diciembre de 2004, a nombre de David Elie-Dit-Cosaque, Kamakshi Sridhar, Maarten Petrus JoseFIG Vissers and Tony Van Kerckhove.
Antecedentes
Campo Técnico de la invención
La presente invención se refiere, en general, a redes OAM Ethernet. Más particularmente, y no a modo de limitación alguna, la presente invención está dirigida a un sistema y procedimiento de propagación de información de fallos y la supresión de la señalización de indicación de alarmas en una red OAM Ethernet.
Descripción de la Técnica Relacionada
El enlace entre el usuario final y la red pública, clave esencial para el envío de aplicaciones de banda ancha a subscriptores particulares o empresariales, se conoce por varios nombres, por ejemplo, primera milla, última milla, bucle local, acceso metro, red de acceso de abonado, etc., y se implementa usando una variedad de diferentes tecnologías y protocolos de transporte sobre diversas conexiones físicas. Por ejemplo, hoy en día la mayoría de los usuarios se conectan a la red pública con Línea de Subscriptor Digital (DSL), Red Digital de Servicios Integrados (ISDN), TV por cable, líneas T1/E1 o T3/E3, usando Red Óptica Síncrona y su compañera Jerarquía Digital Síncrona (SON-ET/SDH), Conmutación de Tramas (Frame Relay) y Modo de Transferencia Asíncrona (ATM). Con independencia de la nomenclatura o la implementación real, todas las redes de acceso requieren unas características de soporte de operaciones, administración y mantenimiento (OAM) para asegurar la mantenibilidad y disponibilidad requeridas para proporcionar servicios de banda ancha.
Las actuales soluciones de primera/última milla tienen unas limitaciones significativas desde la perspectiva del cliente, que van desde cuellos de botella en el rendimiento, suministro de un ancho de banda fijo, escalabilidad limitada, falta de flexibilidad y complejidad en la provisión de una calidad de servicio (QoS) de punta a punta, así como una estructura de coste elevado. El uso de la tecnología Ethernet, simple y robusta, en la primera milla promete revolucionar la red de acceso, como lo hizo la red empresarial. Ethernet es una tecnología de transporte por red de área local (LAN) que se usa tanto en el hogar como en la empresa para comunicar entre ordenadores y redes. Como tecnología de acceso, Ethernet ofrece tres ventajas significativas sobre las tecnologías de primera milla tradicionales: (i) transporte, perdurable en el futuro, para aplicaciones de datos, video y voz; (ii) infraestructura de coste rentable para servicios de datos; y (iii) estándar simple y globalmente aceptado que asegurará la interoperabilidad.
Para adaptar la tecnología Ethernet en un entorno de servicio de grado carrier, se han desarrollado diversos estándares que pretenden proporcionar capacidades OAM avanzadas (también denominadas Conectividad y Manejo de Fallos en Ethernet, o Ethernet CFM) a través de la totalidad de la red desde una punta hasta la otra punta. Dado que el entorno de red con servicio de punta a punta está compuesto típicamente por una acumulación de diversas redes componentes (por ejemplo, redes de acceso metro y redes centrales que utilizan una variedad de tecnologías) que pueden pertenecer a diferentes organizaciones, operadores de red y proveedores de servicio, el plano Ethernet OAM se contempla como un espacio de dominio jerárquicamente estratificado en el que están definidos unos dominios OAM específicos que corresponden a la infraestructura y provisión de las redes constituyentes. En particular, dos estándares, IEEE 802.1ag e ITU-T (Question 3, Study Group 13), incorporadas por referencia en el presente documento, que están específicamente relacionadas con Ethernet OAM de punta a punta, definen un dominio a nivel de cliente, en el nivel más alto de la jerarquía que comprende uno o más dominios de proveedor (ocupando un nivel intermedio), cada uno de los cuales incluye a su vez uno o más dominios de operador a un nivel jerárquico inferior. A modo de estandarización, el espacio de dominio OAM puede ser dividido en un número de niveles, por ejemplo hasta 8 niveles, correspondiendo cada dominio a un nivel particular, en donde un dominio está definido en términos de lo que se denomina puntos de flujo. En el contexto del conjunto de especificaciones IEEE 802, los puntos de flujo son nuevas entidades contenidas en “interfaces” y “puertos” de Control de Acceso de Medios (MAC) según se define en la documentación de estándares relacionada. Un punto de flujo en el borde de un dominio OAM se denomina “Punto Extremo de Mantenimiento” o MEP. Un punto de flujo dentro de un dominio y visible para un MEP se denomina “Punto Intermedio de Mantenimiento” o MIP. Mientras que los nodos MEP son usados por los administradores del sistema para iniciar y monitorizar la actividad OAM (emitiendo tramas OAM apropiadas), los nodos MIP reciben y responden pasivamente a los flujos OAM iniciados por los nodos MEP. Un dominio OAM que tenga uno o más nodos MIP está limitado por dos o más nodos MEP, definiendo una “Entidad de Mantenimiento” (ME) que incluye un conjunto de nodos MIP dispuestos entre un nodo MEP y otro nodo MEP. Por tanto es posible tener más de un ME en un dominio OAM particular.
Aunque la arquitectura Ethernet OAM, tal como está actualmente estandarizada, proporciona una infraestructura impresionante para abordar de principio a fin la Conectividad y Manejo de Fallos en Ethernet a cualquier nivel de la jerarquía OAM, quedan por resolver diversas cuestiones tal como se establecerá con detalle a continuación.
El documento US 6.052.722 da a conocer un sistema y un procedimiento para gestionar recursos de red usando inteligencia distribuida y gestión de estados.
El documento “Parte II del informe de WP 3/13 (Redes y mecanismos multiprotocolo) R48” da a conocer una recomendación para el desarrollo del trabajo en todos los aspectos de la Gestión MPLS de ITU-T STUDY GROUP
13.
Sumario de la Invención
En una realización, se da a conocer un procedimiento, de acuerdo con la reivindicación 1 de propagación de información de fallos en una red Ethernet OAM que tiene múltiples niveles de dominios OAM.
En otra realización, se da a conocer un sistema de acuerdo con la reivindicación 14.
Breve Descripción de los Dibujos
Los dibujos adjuntos están incorporados a la memoria técnica y forman parte de la misma para ilustrar una o más realizaciones ejemplares, actualmente preferidas, de la presente invención. Se comprenderán las diversas ventajas y características de la invención a partir de la siguiente Descripción Detallada tomada conjuntamente con las reivindicaciones adjuntas y con referencia a las figuras de los dibujos adjuntos, en los cuales:
La FIG 1 representa una realización de una realización de una red Ethernet OAM de punta a punta que tiene una pluralidad de dominios OAM;
La FIG 2 representa un esquema de las capas jerárquicas OAM operables con respecto a una red Ethernet punta a punta;
La FIG 3 representa una realización ejemplar de un dominio OAM limitado por un par de nodos MEP;
La FIG 4A representa una trama de Indicación y Supresión de Alarmas en Ethernet (EthAIS o AIS) que tiene unos campos de información de indicación de fallos de acuerdo con una realización de la presente invención;
Las FIG 4B y 4C representan detalles adicionales de la trama EthAIS que se muestra en la FIG 4A;
La FIG 5 representa un esquema generalizado de propagación de tramas EthAIS en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención;
La FIG 6 es un diagrama de flujo de un procedimiento de propagación de tramas EthAIS operable en una red Ethernet OAM de acuerdo con una realización de la presente invención;
La FIG 7 representa una realización de propagación de tramas EthAIS en una jerarquía Ethernet OAM en respuesta a un fallo de enlace;
La FIG 8 representa una realización de propagación de tramas EthAIS en una jerarquía Ethernet OAM en respuesta a una pérdida de Comprobación de Continuidad (CC);
La FIG 9 representa una realización de propagación de tramas EthAIS en una jerarquía Ethernet OAM para indicar el borrado de un fallo;
La FIG 10A representa una realización de una jerarquía Ethernet OAM que ejemplifica la generación de múltiples tramas EthAIS;
La FIG 10B representa un esquema para optimizar flujos de múltiples tramas EthAIS desde un solo nivel en una
jerarquía Ethernet OAM de acuerdo con una realización de la presente invención;
La FIG 11 es un diagrama de flujo de un procedimiento de propagación de tramas AIS de acuerdo con una realización de la presente invención;
La FIG 12A representa una realización de una jerarquía de Ethernet OAM en la cual se ejemplifica la supresión no discriminatoria de alarmas;
La FIG 12 B representa un esquema generalizado para efectuar la supresión inteligente de alarmas en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención;
La FIG 12 C representa una realización de una fase de aprendizaje al efectuar la supresión inteligente de alarmas en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención;
La FIG 12 D representa una realización de una fase de generación de tramas al efectuar la supresión inteligente de alarmas en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención; y
La FIG 13 es un diagrama de flujo de un procedimiento para la supresión inteligente de alarmas en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención.
Descripción Detallada de los Dibujos
A continuación se describirán realizaciones de la invención con referencia a diversos ejemplos de cómo puede fabricarse y usarse mejor la invención. Se utilizan números similares a todo lo largo de la descripción y de las varias vistas de los dibujos para indicar las partes similares o correspondientes. En los dibujos, los diversos elementos no están representados necesariamente a escala. Con referencia a los dibujos, y más particularmente a la FIG 1, se representa en la misma una realización de una red Ethernet OAM 100 de punta a punta, con una pluralidad de dominios OAM, en la cual puede proveerse un esquema de generación y propagación de tramas Ethernet AIS de acuerdo con un aspecto de la presente invención. Según se ilustra, la red Ethernet OAM 100 está compuesta por un entorno de red jerárquicamente estratificado que incluye una primera red local de cliente 102A y una segunda red local de cliente 102B, que forman las porciones terminales del mismo, las cuales están a su vez conectadas por medio de unas respectivas redes de acceso 106A y 106B a una red central de transporte 108. Mientras que un único proveedor de servicio puede administrar la provisión del servicio punta a punta entre los dos clientes, de hecho uno o más operadores pueden estar implicados en la provisión y mantenimiento de la infraestructura de red subyacente. En consecuencia, las redes de acceso y la principal pueden comprender varias y diversas tecnologías y protocolos de red y de transporte para efectuar un servicio Ethernet punta a punta de grado carrier entre las redes de cliente terminales 102A y 102B. Por ejemplo, estas tecnologías surtidas pueden incluir Ehernet sobre SONET/SDH, Ethernet sobre ATM, Ethernet sobre Anillo de Paquete Resiliente (RPR), Ethernet sobre Conmutación de Etiquetas Multiprotocolo (MPLS), Ethernet sobre Protocolo Internet (IP), etcétera.
Las diversas porciones de red de la red Ethernet OAM 100 y sus segmentos constituyentes se interconectan mediante entidades de envío tales como puentes y conmutadores. A modo de ilustración, las entidades 111, 110 y 120, 121 son ejemplares del equipo de cliente dispuesto en las respectivas redes de cliente 102A y 102B. De igual modo, las entidades 112 y 118 de las redes de acceso 106A y 106B sirven de interfaz con los respectivos equipos de cliente 110 y 120. La interfaz entre las redes de acceso 106A y 106B y la red central 108 se efectúa por medio de las entidades 114 y 116 respectivamente. Además de las entidades de interfaz, una red particular puede incluir un número de entidades adicionales dentro de esa red. Por ejemplo, las entidades 115, 117 y 119 son un equipo ejemplar dentro de la red central 108, en la cual pueden efectuarse operaciones punto a multipunto.
Tal como se aludía en la sección Antecedentes de la presente solicitud de patente, la arquitectura Ethernet OAM de una red de servicio Ethernet de grado carrier, punta a punta, jerárquicamente estratificada, tal como la red Ethernet 100, está segmentada lógicamente en un número de dominios OAM que tienen unos niveles de dominio designados jerárquicamente. Con respecto a la red Ethernet OAM 100 de la FIG 1, se ejemplifican un dominio de cliente 103, un dominio de proveedor 105 y uno o más dominios de operador 107A -107C, cada uno de los cuales está limitado por múltiples nodos MEP e incluye uno o más nodos MIP dispuestos entre aquellos. Mientras que los nodos MEP sirven para iniciar diversos comandos OAM y las tramas asociadas, por ejemplo, Comprobación de Continuidad (CC), TraceRoute, Ping, etcétera, los nodos MIP reciben y responden pasivamente a las tramas OAM entrantes en base a la compatibilidad dominio-nivel.
Los expertos en la técnica apreciarán que, en virtud de la provisión de MEPs y MIPs, se efectúa una partición estática de la red Ethernet OAM por la cual los nodos MEP demarcan los límites de los dominios Ethernet no intersecantes, por lo que se restringe la fuga de tramas OAM desde uno a otro dominio. Esto es, se requiere que las tramas OAM previstas para un dominio permanezcan dentro de ese dominio para su procesamiento, a la vez que se filtran todas las demás tramas OAM. Adicionalmente, pueden proveerse nodos MEP y MIP dentro de una
red Ethernet OAM de tal modo que sea posible definir un número de dominios de Entidad de Mantenimiento (ME), fácilmente gestionables, dependiendo de los modelos de negocio y servicio y de los escenarios desplegados. Debido a la disposición jerárquica de los dominios OAM, los dominios de nivel de cliente están dispuestos a un nivel jerárquico más alto que los dominios de proveedor de servicio, que a su vez están dispuestos a un nivel más alto que los dominios de nivel de operador. En consecuencia, en términos de visibilidad y conocimiento, los dominios de nivel de operador tienen una visibilidad de OAM más alta que los dominios de nivel de proveedor de servicio, que a su vez tienen una visibilidad más alta que los dominios de nivel de cliente. Así pues, mientras que un dominio OAM de operador tiene conocimiento de ambos dominios de proveedor de servicio y de cliente, lo contrario no es cierto. De igual modo, un dominio de proveedor de servicio tiene conocimiento de los dominios de cliente, pero no a la inversa.
Según se establece en la documentación de la memoria técnica IEEE 802.1ag referenciada anteriormente, diversas reglas gobiernan el tratamiento de los paquetes/tramas Ethernet según se desplazan desde un nivel de dominio a otro. Los nodos MEP sirven para enviar tramas OAM a todos los otros nodos MEP a través de nivel / dominios OAM, mientras que un nodo MIP solo puede interactuar con los nodos MEP de su dominio. Cada nodo MIP de un nivel de dominio superior también sirve como nodo MEP para la siguiente capa jerárquica inferior. Así, un único elemento de un equipo de entidad de envío puede poseer nodos tanto MIP como MEP de niveles diferentes. Debido a la limitación de los flujos OAM, las tramas a un nivel i determinado, i = 1,2,…,N, permanecen a ese nivel. Los niveles de las tramas OAM son codificados en las mismas dependiendo de los niveles de dominio asignados a los nodos EMP que originan las tramas OAM. Adicionalmente, las tramas OAM son ya sea procesadas o descartadas por los nodos MIP/MEP del mismo nivel en función de las siguientes condiciones: (i) una trama OAM es descartada cuando está originada fuera del dominio OAM en consideración, y (ii) una trama OAM es procesada cuando está originada dentro del dominio OAM en consideración. Debido a la naturaleza jerárquica de la visibilidad OAM, las tramas procedentes de niveles inferiores de dominio de mantenimiento (por ejemplo, de operador) son conmutados transparentemente por los nodos MEP/MIP dispuestos en niveles de dominio superiores (por ejemplo, de cliente). Por otra parte, las tramas OAM de dominios superiores (por ejemplo, originadas por nodos MEP de nivel de cliente) son siempre procesados por nodos MEP/MIP de nivel inferior (por ejemplo, nodos de nivel de operador).
La FIG 2 representa un esquema OAM estratificado jerárquico 200 ejemplar operable con respecto a una red Ethernet punta a punta tal como, por ejemplo, la red 100 que se muestra en la FIG 1, en la cual una pluralidad de puentes Ethernet es ilustrativa de entidades de envío con nodos MIP/MEP a diferentes niveles de dominio. Los números de referencia 202-1 y 202-9 se refieren al equipo de puente de cliente dispuesto en los dos extremos de la red. Dos redes de operador, Operador-A y Operador-B están desplegadas entre los equipos de cliente 202-1 y 2029, comprendiendo la red Operador-A los puentes 202-2 a 202-4 y comprendiendo la red Operador-B los puentes 202-5 a 202-8. Al nivel de cliente, el dominio OAM está limitado por unos nodos MEP 204-1 y 204-2 efectuados en los equipos de puente de cliente 202-1 y 202-9, respectivamente, que incluyen dos nodos MIP 206-1 y 206-2 que son efectuados en el puente de Operador-A 202-2 y el puente de Operador-B 202-8, respectivamente. Por debajo de los nodos MIP de nivel de cliente 206-1 y 206-2 están dispuestos dos nodos MEP 208-1 y 208-2, también efectuados en el puente de Operador-A 202-2 y el puente de Operador-B 202-8, respectivamente, que limitan el dominio OAM de nivel de proveedor de servicio. Dentro de este dominio, un nodo MIP 210-1 efectuado en el puente de Operador-A 202-4 forma interfaz con otro nodo MIP 210-2 efectuado en el puente de Operador-B 202-5. Se definen dos dominios de nivel de operador que corresponden a las dos redes de operador, en los cuales los nodos MEP de nivel de operador 212-1 (efectuado en el puente de Operador-A 202-2) y 212-2 (efectuado en el puente de Operador-A 202-4) limitan un dominio de operador y los nodos MEP de nivel de operador 216-1 (efectuado en el puente de Operador-B 202-5) y 216-2 (efectuado en el puente de Operador-B 202-8) limitan el otro dominio de operador. Adicionalmente, unos nodos MIP 214-1 a 214-4 están dispuestos en el dominio de nivel de operador definido por los nodos MEP 212-1 y 212-2, en el cual el puente 202-2 efectúa el nodo MIP 214-1, el puente 202-3 efectúa los nodos MIP 214-2 y 214-3, y el puente 202-4 efectúa el nodo 214-4. Del mismo modo, unos nodos MIP 218-1 a 218-6 están dispuestos en el dominio de nivel de operador definido por los nodos MEP 216-1 y 216-2, en el cual el puente 202-5 efectúa el nodo MIP 218-1, el puente 202-6 efectúa los nodos MIP 218-2 y 218-3, el puente 202-7 efectúa los nodos MIP 218-4 y 218-5 y, finalmente, el puente 202-8 efectúa el nodo 218-6.
En base a la anterior discusión, se hará aparente que una única entidad de red puede servir para efectuar uno o más nodos MIP/MEP a diferentes niveles, dependiendo de su despliegue y de la provisión de servicio OAM. A modo de ilustración, puede observarse que la entidad de puente 202-2 efectúa el procesamiento y la lógica de los nodos MIP de nivel de cliente 206-1, MEP de nivel de proveedor de servicio 208-1, MEP de nivel de operador 212-1 así como MIP de nivel de operador 214-1. En consecuencia, el equipo físico de una red Ethernet representa una capa plana, “verticalmente comprimida”, que es lógicamente expansible en un número de niveles jerárquicos de los cuales, a un nivel cualquiera, puede abstraerse un dominio OAM como concatenación de una pluralidad de nodos MIP limitados por múltiples nodos MEP. En esencia, la FIG 3 representa dicha realización ejemplar de un dominio OAM 300, que incluye unos nodos 304-1 a 304-N limitados por un par de nodos MEP 302-1 y 302-2, que
representa un caso particular de operación punto a punto. Se comprenderá que en el caso de punto a multipunto, se proveen más de dos MEPs para limitar un dominio OAM (según se aprecia, por ejemplo, en la parte de red central 108 de la FIG 1).
Según se aludió anteriormente, los nodos MEP sirven para originar diversas tramas OAM que pueden usarse para efectuar funciones de servicio OAM tales como descubrimiento, verificación de conectividad, mediciones de latencia/pérdida, mediciones de variación de retardos, etcétera, dentro de una red Ethernet punta a punta. En general, las tramas OAM son emitidas sobre una base de Conexión Virtual per-Ethernet (perEVC) y tienen el aspecto de tramas de datos de usuario, pero se diferencian por (i) ciertas direcciones de multidifusión predeterminadas para el descubrimiento OAM y (ii) ciertos EtherTypes predeterminados para OAM. También porque al tener Ethernet, como tecnología de transporte sin conexión, la propiedad de que puedan enviarse paquetes a diferentes entidades dentro de la red que no los necesitan o no deberían recibirlos (por ejemplo, cuando no se conoce la dirección MAC, también se codifican en los mismos barreras o filtros OAM basados en dominios.
La FIG 4A representa una trama de Indicación y Supresión de Alarmas en Ethernet (EthAIS o AIS) 400 que tiene unos campos de información de indicación de fallo de acuerdo con una realización de la presente invención. Se provee un número de campos tales como direcciones Destino y Fuente de MAC 402 y 404, Ethertype de Virtual LAN (VLAN) 406, etiqueta de VLAN 408, EtherType de OAM 410 y campo de nivel OAM 412, junto con los campos Versión 414 y Reservado 416. Adicionalmente, aunque no se muestra en la FIG 4A, también pueden incluirse en la trama AIS 400 campos tales como Preámbulo, Postámbulo, Comprobación de Redundancia Cíclica (CRC), etcétera. Para proporcionar información de fallos se incluyen en la trama AIS 400 un opcode 418 y un número de campos opcionales Tipo-Longitud-Valor (TLV) 420 de opcodes específicos. Según se verá con mayor detalle a continuación, proporcionar en las tramas AIS los tipos de localización y causa de fallos facilita un esquema innovador para distinguir los fallos entre un nivel OAM y otro nivel OAM según se propagan las tramas a través de los dominios OAM en una jerarquía Ethernet.
Según se ilustra, el campo TLV opcional 420 puede estar compuesto por un número de subcampos, campos Fijos AIS 422, Banderas AIS 424, TLV de ID de Puerto 426, TLV de ID de Chasis 428, y un subcampo para TLVs opcionales adicionales 430. Así pues, se identifica una “localización de fallo” por medio del contenido de TLV de ID de Puerto 426 y TLV de ID de Chasis 428, que se muestran con mayor detalle en las FIG 4B y 4C, respectivamente. En una implementación, estos campos están poblados con el TLV del Punto de Acceso de Servicio MAC (MSAP) según IEEE 801.1ab, que incluye la ID de puerto y la ID de chasis. Como parte del mecanismo de propagación AIS de la presente invención, los MEPs receptores sustituyen el MSAP de las tramas AIS entrantes con su propio MSAP.
Una diferenciación adicional de los campos Fijos de AIS 422 y las Banderas de AIS 424 da lugar al campo Número de Secuencia 432, campo Conteo de Tiempo de AIS 434, campo Conteo de Tiempo de AIS Borrado 436, campo ID de Operador 438, campo Tipo de Causa de Fallo 440, campo Indicación de Nivel AIS 442 y campo Tiempo de Reparación 444. El contenido del campo Número de Secuencia 432 identifica unívocamente una trama AIS que se transmite debido a una determinada localización de fallo. El Tipo de Causa de Fallo 440 proporciona un mecanismo para codificar diferentes tipos de fallos, por ejemplo, indicación de fallo de enlace, indicación de congestión, pérdida de trama de CC, fallo borrado, etc. La ID de Operador 438 sirve para indicar qué entidad de operador es responsable para manejar el fallo causado. La Indicación de Nivel AIS 442 proporciona un mecanismo para identificar si las tramas AIS son del dominio OAM actual o no, lo cual se usa para determinar si se suprimen las alarmas (si la trama AIS es de un nivel de dominio OAM más bajo) o no (si la trama AIS es del nivel del dominio OAM actual).
Para asegurar la fiabilidad de las trama AIS, se proporciona una información adicional por medio de campos tales como el campo Conteo de Tiempo de AIS 434, campo Conteo de Tiempo de AIS Borrado 436, y campo Tiempo de Reparación 444. El contenido del campo Conteo de Tiempo de AIS 434 indica cuanto ha estado presente un fallo (es decir, el tiempo transcurrido desde la detección del fallo). En una implementación, para un número de secuencia, este campo se incrementa en uno cada vez que se genera una trama AIS. El campo Conteo de Tiempo de AIS Borrado 436 sirve para indicar el tiempo transcurrido desde que se borró un fallo particular. Para un número de secuencia, este campo se incrementa en uno cada vez que se genera una trama Fallo de AIS Borrado. En consecuencia, incluso si algunas tramas AIS se pierden en tránsito mientras se propagan a través de una jerarquía Ethernet OAM, el campo Conteo de Tiempo de AIS 434 y el campo Conteo de Tiempo de AIS Borrado 436 indicarán respectivamente el preciso instante del pasado en que se produjo o se borró un fallo. Por ejemplo, un valor de 100 en el Conteo de Tiempo de AIS indica que hace 100 segundos se detectó un fallo al nivel inferior (en base a la generación periódica de una trama AIS por segundo).
Durante operación general, las tramas Ethernet AIS son generadas periódicamente por los nodos MIP adyacentes a los fallos de enlace y propagadas a los niveles superiores (es decir, más altos) de una red Ethernet OAM. Un nodo MEP que reciba una trama AIS desde los niveles inferiores puede reconocer si el fallo está en los dominios
inferiores simplemente examinando la información indicadora de nivel en la trama AIS. A continuación, el nodo MEP puede suprimir las alarmas en su Sistema de Manejo de Red (NMS), en el nivel actual, que se hubieran generado debido a una pérdida de trama CC (a ese nivel) causada por el fallo en el nivel inferior. Deberá observarse, sin embargo, que los fallos de enlace identificados en el nivel OAM actual también son indicados mediante las tramas AIS (con la indicación del nivel actual), y las alarmas debidas a tales fallos de enlace no son suprimidas y se envían al NMS.
La FIG 5 representa un esquema generalizado 500 de propagación de tramas EthAIS en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención. Una jerarquía de tres niveles incluye un dominio OAM 502 en el Nivel-(i-1), un dominio OAM 504 en el Nivel-(i) y un dominio 506 en el Nivel-(i+1). Asociado a cada dominio OAM hay una correspondiente entidad NMS que sirve para responder a cualquier alarma generada por el dominio. En consecuencia, los números de referencia 508 (i-1), 508 (i) y 508 (i+1) se refieren a las entidades NMS asociadas a los dominios OAM 502, 504 y 506, respectivamente. En operación normal, cada dominio OAM está monitorizado por tramas CC, específicas para cada nivel, transmitidas por los nodos MEP del mismo. Si hay un fallo en un nivel por debajo de la jerarquía de tres niveles, el flujo de tramas CC en cada dominio OAM se interrumpe, creando así un fallo por pérdida de CC en el mismo, del cual es normalmente informado el NMS correspondiente aunque el fallo se haya producido en cualquier otro sitio. Sin embargo, debido a las tramas AIS que incluyen la información de localización del fallo y de nivel, y que se propagan a través de la jerarquía, cada dominio OAM sabe que el fallo está en algún otro sitio. En consecuencia, en los respectivos dominios OAM se suprimen las alarmas debidas a la pérdida de CC.
A modo de ilustración, el dominio OAM 502 recibe un AIS 510 desde un nivel inferior. Como resultado, se suprime la señalización de alarma 514 (i-1) al NMS 508 (i-1) debida a la pérdida de trama CC 512 (i-1) en el dominio 502 (desde sus MEPs). Adicionalmente, la información de localización del fallo y de nivel es propagada por uno o más nodos MEP del dominio OAM 502 hasta su dominio de nivel superior, es decir, el dominio OAM 504, por medio de una nueva trama. Al recibir la AIS (i-1) 516, el dominio OAM 504 determina que no debe informar de su pérdida de CC 512 (i) al correspondiente NMS 508 (i). En consecuencia se suprime la señalización de alarma 514 (i) en el mismo. Adicionalmente, substancialmente similar al comportamiento del dominio OAM 502, se propaga una nueva AIS (i) 518 al siguiente nivel superior, es decir, el Nivel-(i+1). En respuesta al contenido de la AIS (i) 518, el dominio OAM 506 determina también que no tiene que informar de su pérdida de CC 512 (i+1) al correspondiente NMS 508 (i+1)., tras lo cual se suprime la señalización de alarma 514 (i+1).
Los expertos en la técnica reconocerán la disponibilidad de un tratamiento similar en el que un fallo sea detectado primero al nivel de servidor de una red EO, excepto que la indicación inicial del fallo se propaga a través de mensajes, de tecnología específica, en el nivel de servidor, y no mediante generación de tramas AIS, hasta su dominio de nivel superior, por ejemplo, el dominio de nivel de operador. A continuación, los nodos MIP del dominio de nivel de operador generan tramas Ethernet AIS en consecuencia, las cuales son propagadas hacia arriba a través de la jerarquía de la red Ethernet OAM según se ha descrito anteriormente.
Con referencia a la FIG 6, se muestra en la misma un diagrama de flujo de un procedimiento de propagación de tramas EthAIS que sirve para una red Ethernet OAM de acuerdo con una realización de la presente invención. Al detectar un fallo, un nodo MIP dispuesto en un dominio OAM de nivel inferior, es decir, un primer dominio OAM (bloque 602), genera una trama Ethernet AIS que tiene un primer número de secuencia. En una implementación, uno o más MIPs, que están adyacentes a la localización del fallo, sirven para generar tal trama y transmitirla independientemente a través del dominio. Preferiblemente, los nodos MIP multidifunden la trama AIS generada, con el primer número de secuencia, a los nodos MEP del dominio (bloque 604). Tras la recepción de la trama AIS por uno o más nodos MEP del primer dominio OAM, los nodos MEP receptores generan otra trama Ethernet AIS que tiene un segundo número de secuencia, cuya segunda trama Ethernet AIS incluye una indicación de que se ha producido un fallo en el dominio OAM del nivel inferior (bloque 606). La segunda trama Ethernet AIS es transmitida entonces a un segundo dominio OAM que está dispuesto en un nivel jerárquico inmediatamente superior al primer dominio OAM (bloque 608). Adicionalmente, los nodos MEP receptores suprimen el envío a una entidad NMS, asociada con el segundo dominio OAM, de una señal de alarma que habría sido provocada por una pérdida de tramas CC en el mismo debida al fallo detectado en el nivel inferior.
La FIG 7 representa una realización de un esquema de propagación de tramas EthAIS 700 en una jerarquía de Ethernet OAM en respuesta a un fallo de enlace, en el cual se ejemplifica la pluralidad de puentes 202-1 a 202-9 descrita anteriormente con referencia a la FIG 2. Un fallo de enlace localizado en el nivel de servidor, entre los nodos de servidor adyacentes 702 y 704, es detectado por los nodos de servidor, tras lo cual cada nodo de servidor transmite respectivamente un mensaje de fallo 706, 708, específico para el nivel de servidor, a su correspondiente nodo MIP 214-1, 214-2 dispuesto en el siguiente dominio de nivel superior, es decir, el dominio de nivel de operador. Debido al fallo, el enlace de servidor efectuado entre los puentes 202-2 y 202-3 ya no está operativo, y los dominios OAM experimentan consecuentemente una brecha vertical que separa los dominios en dos lados. Según se ilustra, los nodos MIP de nivel de operador 214-1 y 214-2 pertenecen a lados diferentes de la
brecha, con lo cual cada uno sirve para generar una trama AIS 710, 712 con la información del fallo para transmitir a los respectivos lados del dominio de nivel de operador. En una implementación, las tramas AIS 710 y 712 son multidifundidas periódicamente por los MIPs durante la condición de fallo (por ejemplo, una trama por segundo). Al recibir las tramas AIS 710 y 712, los nodos MEP 212-1 y 212-2 del dominio de nivel de operador generan, respectivamente, una nueva trama AIS que tiene un número de secuencia diferente del número de secuencia de las tramas AIS recibidas. En una realización ejemplar, los nodos MEP 212-1 y 212-2 generan las nuevas tramas AIS tras agrupar todas las tramas AIS recibidas desde el nivel actual (es decir, el dominio del nivel de operador). La agrupación de las tramas AIS puede ser preferible porque un dominio de nivel superior (por ejemplo, el dominio del nivel de cliente) solo necesita saber que el fallo está en el nivel inferior (por ejemplo, el nivel de proveedor), pero no necesita saber cuantos fallos hay en el nivel inferior, o qué puentes del nivel inferior están en fallo. Por lo tanto, a un dominio OAM de nivel superior le basta con recibir una única indicación de fallo de AIS desde el dominio OAM de nivel inferior, independientemente del número de fallos del nivel inferior. En consecuencia, deberá apreciarse que la agrupación de las tramas AIS evita inundar el dominio OAM con tramas innecesarias.
Los MEPs de nivel de operador 212-1 y 212-2 propagan las nuevas tramas AIS hacia el dominio del nivel de proveedor, en el cual son similarmente multidifundidas hacia las porciones restantes del dominio. El número de referencia 714 se refiere a una trama AIS recibida por el MIP de nivel de proveedor 210-1 desde el MEP de nivel de operador 212-2, la cual es transmitida al MEP de nivel de proveedor 208-2, que agrupa las tramas AIS recibidas por el mismo y propaga otra nueva trama AIS hacia el dominio de nivel de cliente. Según se ilustra, el nodo MIP de nivel de cliente 206-2 sirve para recibir la nueva trama AIS desde el dominio de nivel de proveedor, la cual es luego multidifundida a los nodos MEP de nivel de cliente (por ejemplo, MEP 204-2). Como resultado de la propagación de AIS a través de la jerarquía OAM, los nodos MEP de cada nivel sirven para determinar si la condición de fallo en la red es debida a un fallo de enlace en el nivel de servidor y, en consecuencia, suprimir la señalización de alarma (debida a la pérdida de tramas CC en ese nivel) a la entidad NMS asociada con cada nivel.
La FIG 8 representa una realización de un esquema de propagación de tramas EthAIS 800 en una jerarquía Ethernet OAM en respuesta a una pérdida de CC. Similar al escenario representado en la FIG 7, se ejemplifica la pluralidad de puentes 202-1 a 202-9, habiéndose producido una condición de congestión o de fallo de tejido en la ME de nivel de operador definida por los MEP 212-1 y MEP 212-2. Sin embargo, el enlace subyacente no experimenta ninguna condición de fallo. El fallo de tejido o la congestión impiden que las tramas CC pasen por la ME del nivel de operador, lo cual es detectado únicamente por los puntos extremos de las MEs, los MEP 212-1 y 212-2. Sin embargo, los nodos MIP adyacentes al fallo de tejido no pueden detectarlo. Ante la detección de la condición de pérdida de tramas CC, los nodos MEP 212-1 y 212-2 propagan respectivamente tramas Ethernet AIS a sus correspondientes nodos en el dominio de nivel superior (por ejemplo, el dominio de nivel de proveedor). Un nodo MIP receptor, por ejemplo el MIP 210-1, en el dominio de nivel de proveedor, multidifunde la trama 714 a los MEPs del mismo para efectuar la supresión de alarma (a ese nivel) y la propagación de AIS al siguiente nivel (es decir, el nivel de cliente).
La FIG 9 representa una realización de un esquema de propagación de tramas EthAIS 900 en una jerarquía Ethernet OAM para indicar el borrado de un fallo. Tras la reparación de una condición de fallo en el nivel de servidor entre los puentes 202-2 y 202-3, los nodos de servidor proporcionan unas señales adecuadas 902, 904 a los nodos MIP 214-1 y 214-2 en el dominio de nivel de operador. De manera similar a la generación de tramas AIS en el caso de un fallo de enlace, los MIPs adyacentes al enlace que ha sido reparado generan unas tramas AIS Borrado 906, 908 que son propagadas a sus respectivos nodos MEP 212-1, 212-2. A continuación, los nodos MEP 212-1, 212-2 generan nuevas tramas AIS Borrado (por ejemplo, AIS Borrado 912 y AIS Borrado 910) para su propagación a través de la jerarquía OAM. Los expertos en la técnica reconocerán, tras hacer referencia a este documento, que sin un esquema de indicación del borrado de un fallo por medio de las tramas AIS Borrado, un nodo MIP o MEP en un nivel determinado tendría que esperar un número arbitrario de periodos de tiempo AIS durante los cuales no se recibe ninguna indicación AIS para indicar o considerar que el fallo se ha borrado. Implementando tramas AIS Borrado, puede proveerse a través de toda la jerarquía OAM una confirmación positiva de que un fallo está efectivamente borrado.
En base a la anterior discusión, se hará aparente que la generación y propagación de tramas AIS proporciona un ventajoso esquema para transmitir información de fallos en una jerarquía Ethernet OAM multinivel, mediante el cual pueden diferenciarse los fallos en dominios de diversos niveles. Además, se suprimen en un nivel particular las alarmas debidas a fallos en niveles inferiores (es decir, no se informa a la entidad NMS asociada con el nivel particular) porque esos fallos se arreglarán en el nivel inferior. Adicionalmente, con Ethernet AIS un dominio OAM particular (por ejemplo, un dominio de nivel de cliente) puede aplicar penalidades a un dominio de nivel inferior (por ejemplo, un dominio de proveedor) cuando se produzca una indisponibilidad del servicio debida a fallos procedentes del dominio OAM de nivel inferior. En consecuencia, los clientes pueden obtener un reembolso en base una indisponibilidad del servicio achacable a los dominios de nivel inferior.
Surgen, sin embargo, ciertos problemas técnicos al implementar el esquema AIS en una red Ethernet OAM ejemplar. En primer lugar, fallos simultáneos en los dominios Ethernet OAM desencadenan una cascada de múltiples tramas AIS hacia los dominios superiores, que resultará en un tráfico de alarmas excesivo e innecesario en los niveles superiores. Adicionalmente, con Ethernet AIS a veces pueden suprimirse equivocadamente alarmas debidas a fallos en un nivel particular de las que debería informarse al NMS de ese nivel. Por ejemplo, tal
5 escenario puede surgir cuando desde un dominio de nivel inferior se propagan unas tramas AIS, debidas a fallos en ese nivel inferior, que causan la supresión no discriminatoria de la señalización de alarma en los niveles superiores. El resto de la divulgación de la presente patente planteará realizaciones de diversos esquemas enfocados específicamente a estos problemas.
La FIG 10A representa una realización de una red Ethernet OAM1000 que ejemplifica la generación de múltiples
10 tramas EthAIS, en el cual un dominio de proveedor 1002 está acoplado a unas porciones de dominio de cliente 1004A y 1004 B. Un equipo de puentes de proveedor P1 1034, P2 1018 y P3 1020 forma una porción interior del dominio de proveedor, que forma interfaz con el dominio de cliente mediante una pluralidad de puentes de Borde de Proveedor (PE). A modo de ilustración, se proveen los puentes PE1 1014, PE2 1016, PE3 1022 y PE 1020. Las porciones de dominio de cliente 1004A y 1004B están igualmente compuestas por una pluralidad de puentes de
15 cliente que incluyen puentes de Borde de Cliente (CE). Según se ejemplifica, C1 1012 y C2 1010 están acoplados a CE1 1006, que a su vez forma interfaz con PE1 1014. Similarmente, CE2 1008, CE3 1028 y CE4 1026 forman interfaz con PE2 1016, PE3 1022 y PE4 1024, respectivamente. Adicionalmente, cada uno de los diversos puentes de la red 1000 está representado con cuatro puertos, a título de ejemplo.
Siguiendo la referencia a la FIG 10A, se ejemplifican dos fallos simultáneos 1030 y 1034 dentro del dominio de
20 proveedor, de los cuales el fallo 1030 se produce entre P1 1034 y P2 1018 y el fallo 1032 se produce entre P3 1020 y PE4 1024. Según se describió con detalle anteriormente, cada fallo independientemente da lugar a una trama Ethernet AIS en el dominio de proveedor. En consecuencia, se reciben dos tramas AIS separadas en el dominio de cliente, significando múltiples fallos en el nivel inferior (es decir, el dominio de proveedor). A medida que aumenta el número de fallos en el nivel de proveedor, el número de tramas AIS en el nivel de cliente aumentará
25 correspondientemente, resultando en un tráfico excesivo. Sin embargo, la recepción de tales tramas AIS múltiples no proporciona ninguna información útil adicional, puesto que cada una de las tramas AIS procedentes del nivel inferior actuará para suprimir la señalización de alarma en el nivel superior.
La FIG 10B representa un esquema para optimizar flujos de múltiples tramas EthAIS procedentes de un único nivel en la red Ethernet OAM1000 de acuerdo con una realización de la presente invención. Esencialmente, la solución 30 implica la generación de tramas Ethernet AIS hacia un dominio de nivel superior solo tras la detección de una pérdida de tramas CC en el nivel actual. Según se indicó anteriormente, los fallos 1030 y 1032 dan lugar a dos tramas AIS independientes que se propagan hacia el dominio de cliente. En primer lugar, en una ME ejemplar que implica a PE1, unos correspondientes flujos AIS 1056, 1058 llegan a PE1 1014, en donde un MEP 1054 (efectuado en el puerto 3 de PE1) termina los flujos. En paralelo, el MEP 1054 también monitoriza continuamente la recepción 35 de las tramas CC desde los otros MEPs del dominio de proveedor. Si le faltan una o más tramas CC, dispara una alarma de falta de CC que indica que los MEPs remotos del dominio de proveedor no están enviando tramas CC y por lo tanto son inalcanzables. En el ejemplo mostrado en la FIG 10B, los fallos 1030 y 1032 impiden que el nodo MEP 1054 reciba tramas CC desde otros nodos MEP del dominio de proveedor, disparando así la generación de alarmas de pérdida de CC. Así se regenera una única trama AIS 1060 y se transmite hacia el dominio de cliente
40 por medio del MIP 1052, que luego multidifunde la trama 1060 en el dominio de cliente.
El anterior esquema de procedimiento de propagación de tramas AIS está planteado como un diagrama de flujo en la FIG 11 de acuerdo con una realización de la presente invención. Según se indica en el bloque 1102, un nodo MEP dispuesto en un dominio OAM de un nivel particular recibe una primera trama Ethernet AIS, cuya trama Ethernet AIS se ha propagado debido a una primera condición de fallo. El Nodo MEP del dominio OAM del nivel 45 particular recibe una segunda trama Ethernet AIS, siendo propagada la segunda trama AIS en respuesta a una segunda condición de fallo (bloque 1104). La lógica de la que está provisto el nodo MEP determina que existe una pérdida de tramas CC en el dominio del nivel actual, es decir, el dominio del nivel particular, debida al menos a una de las condiciones de fallo primera y segunda. En respuesta a la determinación, el nodo MEP termina la primera y segunda tramas AIS y genera una nueva trama Ethernet AIS única para su propagación hacia un
50 siguiente dominio OAM de nivel superior (bloque 1106).
La FIG 12A representa una realización de una red Ethernet OAM 1200 en la cual se ejemplifica la supresión no discriminatoria de alarmas. De manera similar a la red Ethernet OAM 1000 descrita anteriormente, una pluralidad de puentes está organizada en un dominio de proveedor 1201 y en unas porciones de dominio de cliente 1203A, 1203B. Tal como se ilustra, PE1 1206, PE1 1208, PE3 1210, y PE4 1212 están dispuestos en el dominio de 55 proveedor 1201. De la misma manera, las porciones de dominio de cliente 1203A y 1203B comprenden respectivamente C2 1202 y CE1 1204, y CE3 1214, CE4 1216 y C1 1218. A modo de ejemplo, en el dominio de cliente se proporcionan dos sistemas ME: ME{MEP5, MEP4}, en el cual MEP5 está configurado en el puerto 3 de C2 1202, MEP1 está configurado en el puerto 2 de CE3 1214, y MEP4 está configurado en el puerto 4 de C1. Por
consiguiente, las tramas CC del nivel de cliente se pasan a través de cada uno de los sistemas ME provistos en la arquitectura OAM. Los expertos en la técnica reconocerán que durante el funcionamiento normal, un conjunto de tramas CC atravesará los puentes C2 1202, CE1 1204, PE1 1206, P1 1208, PE3 1210, CE3 1214 como parte del sistema ME{MEP5, MEP1}, y otro conjunto de tramas CC atravesará los puentes C2 1202, CE1 1204, PE1 1206, P1 1208, PE4 1212, CE4 1216, C1 1218 como parte del sistema ME{MEP5, MEP4}.
En el dominio de proveedor 1201 se ejemplifica un fallo de enlace 1209 entre P1 1208 y PE3 1210,, que da lugar a la generación de una trama Ethernet AIS y a su propagación hacia el dominio de nivel superior, es decir, el dominio de cliente. Sin embargo, como resultado del fallo de enlace, se pierden las tramas CC que implican a la ME{MEP5, MEP1}. Tal como se ha descrito en mayor detalle anteriormente, las tramas AIS causadas por el fallo de enlace 1209 en el dominio de proveedor eventualmente alcanzan los nodos MEP limítrofes del dominio de cliente, momento en el cual se suprime la señal de alarma debida a la pérdida de tramas CC de cliente (causadas por el fallo de enlace). Por otro lado, puesto que el mecanismo Ethernet AIS actualmente efectúa la supresión no discriminatoria de todas las alarmas en un nivel particular, si hay fallos que son específicos de dicho nivel (de los cuales hay que informar, también se suprimen las pérdidas CC debidas a tales fallos. Tal como se ejemplifica en la FIG 12A, un fallo de tejido 1211 en CE4 1216 (en el dominio de cliente), que crea la pérdida de tramas CC que implican ME{MEP5, MEP4}, se suprime erróneamente en el dominio de cliente.
La FIG 12B representa un esquema generalizado 1250 para efectuar una supresión inteligente de alarmas en una jerarquía Ethernet OAM de acuerdo con una realización de la presente invención. Se ejemplifican tres niveles de dominios OAM, Nivel-(i-1), Nivel-(i) y Nivel-(i+1), presentando cada dominio su propia circulación de trama CC. En el Nivel-(i+1), el dominio OAM incluye MEP 1252 y MEP 1254, con una pluralidad de nodos MIP 1256-1 a 1256-N entre los mismos. De la misma manera, el dominio OAM incluye el MEP 1260 y el MEP 1262, con una pluralidad de nodos MIP 1266-1 a 1266-M entre los mismos, y en el Nivel-(i-1) el dominio OAM incluye el MEP 1268 y el MEP 1270, con una pluralidad de nodos MIP 1272-1 a 1272-L entre los mismos.
En una fase de aprendizaje, un nodo MEP de nivel inferior obtiene información sobre la topología MEP de nivel superior mediante la monitorización de las tramas CC de nivel superior que pasan a través del mismo puente que efectúa tanto el MEP de nivel inferior como el correspondiente MIP de nivel superior. Tal como se ilustra en la FIG 12B, el MEP 1260 del Nivel-(i) y el MIP 1256-1 del Nivel-(i+1) se efectúan en el mismo equipo de puentes. MIP 1256-1 sirve para rastrear las tramas CC del Nivel-(i+1) que pasan a través del mismo, y mediante el examen de los contenidos de las mismas, el MIP 1256-1 puede determinar que los MEPs 1252 y 1254 residen en el dominio del Nivel-(i+1). La información de los MEP de nivel superior puede almacenarse en una base de datos de CC 1258, que esencialmente identifica todos los MEPs alcanzables del dominio de nivel superior. Puesto que el MEP de nivel inferior, es decir el MEP 1260, tiene acceso a la base de datos de CC 1258, puede proporcionarse la información de la topología MEP de nivel superior a los restantes nodos MEP de ese nivel, es decir el Nivel-(i), a través de las tramas CC del Nivel-(i). Aunque en el Nivel-(i) sólo se muestra un único MEP remoto (p. ej., el MEP 1262), resultará aparente que el mismo podrá estar provisto de múltiples MEPs remotos, recibiendo cada uno de los mismos las tramas CC con la información de MEP de nivel superior. Son posibles diversos modos de transmisión con respecto a la distribución de la información de MEP de nivel superior. En una implementación, sólo los cambios en la base de datos 1258 podrán transmitirse a través de las tramas CC cuando sea aplicable. Aunque esta aplicación es escalable, la sincronización resulta más difícil. En otra implementación, puede transmitirse la base de datos de CC 1258 completa en cada trama CC, lo que ofrece una solución fiable, aunque menos escalable. En otra implementación adicional, se proporciona un mecanismo híbrido que implica los dos acercamientos anteriores.
Los nodos MEP remotos que reciben una trama CC etiquetada con la información adicional de la topología MEP de nivel superior sirven para construir una correspondiente base de datos AIS que incluya nodos MEP de nivel superior alcanzables (y a la inversa, inalcanzables). A modo de ilustración, el MEP remoto 1262 de Nivel-(i) construye una base de datos AIS 1264 en base a la información recibida a través de las tramas CC de Nivel-(i) a partir del MEP 1260. Como ejemplo, las entradas de la base de datos AIS 1264 puede leerse tal como sigue: ”MEP 1, …. de Nivel-(i+1) reside detrás de MEP2 de Nivel-(i) que ha proporcionado esta información de la topología a través de sus tramas CC”.
De manera similar a la construcción de la base de datos AIS 1264 del Nivel-(i), cada nivel de una jerarquía de Ethernet OAM particular puede construir su propia base de datos de la topología MEP de nivel superior. En otras palabras, puede construirse una base de datos AIS mediante un nodo MEP de un Nivel-(i-1) que incluya información de la topología MEP alcanzable/inalcanzable aprendida mediante el examen de las tramas CC de Nivel-(i). Una vez que las bases de datos AIS están construidas apropiadamente en la red, pueden utilizarse los contenidos de las mismas para generar tramas Ethernet AIS con información de MEP de nivel superior apropiada, que se utilizarán para suprimir ciertos tipos de alarmas (debidas a fallos en los niveles inferiores) al tiempo que permitan las restantes alarmas (debidas a fallos en el nivel actual), tal como se expondrá a continuación.
La FIG 12C representa una realización de una fase de aprendizaje para efectuar una supresión inteligente de alarmas en la red Ethernet OAM 1200 anteriormente descrita. Durante la fase de aprendizaje, cada MIP de cliente situado en el borde del dominio de proveedor rastrea las tramas CC de cliente que pasan a través del mismo. Dado que estos MIPs de cliente se efectúan sobre puentes que pertenecen a la red de proveedor, el proveedor puede utilizarlos efectivamente para rastrear las tramas CC de cliente.
Tal como se ilustra en la FIG 12C, el MIP2 (en PE3 1210 en el puerto 2) aprende mediante el examen de las tramas CC del MEP1 del dominio de cliente, almacenando después esta información en una base de datos CC asociada con el mismo. El MEP2 de proveedor (por debajo del MIP2 de cliente) multidifunde las tramas CC de proveedor hacia el resto de MEPs de la red de proveedor. Tal como se ha explicado anteriormente, el MEP2 tiene acceso a la misma base de datos CC que el MIP2, puesto que reside en el mismo puerto que el MIP2. La información recogida por la base de datos CC es transmitida a través de la red de proveedor hacia los restantes MEPs de proveedor, a través de las tramas CC que incluyan campos TLV apropiados. Por consiguiente, el MEP3 del PE1 1206 recibirá las tramas CC de proveedor y las terminará. Luego extraerá la información de la base de datos CC, es decir la información de MEP de cliente basado en TLV, que se almacena en una nueva base de datos de Ethernet AIS que se clasifica mediante el envío de MEPs.
La FIG 12D representa una realización de una fase de generación de tramas para efectuar una supresión inteligente de alarmas en la red Ethernet OAM 1200. Al igual que antes, el fallo de enlace 1209 entre P1 1208 y PE3 1210 genera una pérdida de tramas CC entre MEP3 (puerto 3 en PE1 1206) y MEP2 (puerto 2 en PE3 1210) en el dominio de proveedor. Esta pérdida indica que el MEP2 es inalcanzable. PE1 1206 cuestiona a su base de datos de Ethernet AIS y determina que el MEP1 en el nivel de cliente reside detrás del MEP2, y por lo tanto también es inalcanzable. El MEP3 genera una trama Ethernet AIS hacia el dominio de cliente en respuesta a esta pérdida de CC. El MEP3 añade en esta trama AIS la información de la topología MEP de nivel superior adquirida durante la fase de aprendizaje con respecto al MEP1 inalcanzable en el nivel de cliente. En una implementación, el identificador del MEP1 se inserta dentro de la trama AIS a modo de campo de TLV. A continuación, se multidifunde la trama AIS hacia el dominio de cliente.
Al recibir la trama AIS con el campo de TLV adicional que contiene el identificador del MEP1, el MEP5 (puerto 3 en C2 1202) determina que la pérdida de tramas CC con respecto a la ME{MEP5, MEP1} se debe a un fallo en el dominio de proveedor y que debido a esto el MEP1 se ha vuelto inalcanzable. Por lo tanto, el MEP5 puede suprimir con seguridad la pérdida de CC en la ME{MEP5, MEP1}. Por otro lado, no se suprimen otras pérdidas de CC, p. ej., pérdidas de CC en la ME{MEP5, MEP4}. Esto es, dichas pérdidas de CC restantes que pertenezcan a un fallo en el nivel actual (p. ej., fallos de tejido en el dominio de cliente, tal como el fallo de tejido 1211 en CE4 1216) serán reportadas a su NMS.
La FIG 13 es un diagrama de flujo de un procedimiento de supresión inteligente de alarmas en una jerarquía de red Ethernet OAM de acuerdo con una realización de la presente invención. Tal como se presenta en el bloque 1302, un nodo MEP dispuesto en un dominio OAM de nivel inferior aprende la topología MEP de un dominio OAM de nivel superior adyacente mediante la monitorización de las tramas CC que pasan a través del dominio OAM del nivel superior adyacente. El MEP del nivel inferior propaga la información de la topología MEP del nivel superior hasta los nodos MEP del nivel inferior restantes (es decir, los MEPs remotos) a través de tramas CC del nivel inferior (bloque 1304). Se construye una base de datos AIS en uno o más MEPs remotos del dominio OAM del nivel inferior, en el cual la base de datos incluye información referente a qué MEPs del nivel superior son inalcanzables (es decir, identificando los MEPs del nivel superior que residen detrás de cada MEP del nivel inferior particular) (bloque 1306). Al detectar una pérdida de tramas CC en el dominio OAM del nivel inferior, se genera una trama Ethernet AIS y se propaga hasta el nivel superior adyacente, en el cual la trama Ethernet AIS está poblada con identidades de MEPs del nivel superior inalcanzables según lo determinado en base a la información de la base de datos AIS (bloque 1308). Tras recibir el dominio OAM del nivel superior la trama Ethernet AIS, los MEPs del mismo determinan cuáles de las pérdidas CC del nivel superior se deben a fallos procedentes de abajo (en base a la información de la base de datos AIS que indica qué MEPs del nivel superior están detrás de los MEPs del nivel inferior inalcanzables). En respuesta a esto, se suprimen (bloque 1310) las alarmas referentes a la pérdida de tramas CC del dominio OAM del nivel superior que están ideadas para pasar en bucle a través de un MEP del nivel superior inalcanzable. Tal como se ha mencionado anteriormente, las alarmas referentes a las restantes pérdidas de trama CC no se suprimen, y se reportan convenientemente a una entidad NMS asociada con el dominio OAM del nivel superior.
En base a la Descripción Detallada anterior, debe observarse que la presente invención proporciona ventajosamente un mecanismo de indicación y supresión de alarmas para una jerarquía de Ethernet OAM. Aunque se ha descrito la invención con referencia a determinadas realizaciones ejemplares, debe comprenderse que las formas de la invención mostradas y descritas deben tratarse únicamente a modo de ejemplos. Por consiguiente, pueden realizarse diversos cambios, sustituciones y modificaciones sin alejarse del alcance de la invención según lo definido en las reivindicaciones adjuntas.

Claims (5)

  1. REIVINDICACIONES
    1.-Un procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples niveles jerárquicos designados de dominios de Operaciones, Administración y Mantenimiento, OAM, en el que cada dominio OAM está limitado por nodos de Punto Extremo de Mantenimiento, MEP, que limitan una pluralidad de nodos de Punto Intermedio de Mantenimiento, MIP, que comprende: transmitir una primera trama de Indicación y 10 Supresión de Alarmas, AIS, de Ethernet, por medio de al menos un nodo MIP dispuesto en un primer dominio OAM de nivel jerárquico inferior en la red Ethernet (100), tras detectar un fallo en dicho primer dominio OAM de nivel jerárquico inferior, para su recepción por al menos un nodo MEP que limita dicho primer dominio OAM; tras recibir dicha primera trama Ethernet AIS, generar mediante dicho al menos un nodo MEP que limita dicho primer dominio una segunda trama Ethernet AIS para su transmisión a un segundo nodo MEP dispuesto en un segundo 15 dominio OAM de nivel jerárquico superior, incluyendo dicha segunda trama Ethernet AIS una indicación de nivel que indica que se ha detectado un fallo en dicho primer dominio OAM de nivel jerárquico inferior; determinar un fallo en dicho segundo dominio OAM de nivel jerárquico superior en la red Ethernet (100) por medio de dicho segundo nodo MEP y, en respuesta a dicha segunda trama Ethernet AIS que incluye la indicación de nivel que indica que se ha detectado un fallo en dicho primer dominio OAM de nivel jerárquico inferior, suprimir la generación
    20 en dicho segundo dominio OAM, por medio de dicho segundo nodo MEP dispuesto en el segundo nivel jerárquico superior, de una alarma debida al fallo determinado en dicho segundo dominio OAM de nivel jerárquico superior.
  2. 2.-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual dichos primer y segundo dominios OAM comprenden unos dominios OAM de nivel de operador y de nivel de proveedor, respectivamente.
    25 3.-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual dichos primer y segundo dominios OAM comprenden unos dominios OAM de nivel de proveedor y de nivel de cliente, respectivamente
    4-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual dichas primera y segunda tramas AIS son
    30 generadas con diferentes números de secuencia de la trama.
    5-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual dicha primera trama AIS es generada en respuesta a la detección de un fallo en un enlace asociado con dicho al menos un MIP.
    6-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples
    35 dominios OAM según se relata en la reivindicación 1, en el cual dicha primera trama AIS es generada por dicho al menos un MIP en respuesta a la detección de una condición de congestión en un enlace asociado con el mismo.
    7-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual dicho al menos un nodo MIP está dispuesto cerca de la localización de dicho fallo.
    40 8-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual dicha primera trama AIS es multidifundida por dicho al menos un nodo MIP dentro de dicho primer dominio OAM.
    9-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, el cual, en respuesta a dicha segunda trama Ethernet AIS
    45 recibida en dicho segundo dominio OAM, suprime la generación en dicho segundo dominio OAM de una alarma causada por una pérdida de tramas de Comprobación de Continuidad, CC, debida al fallo en dicho primer dominio OAM.
    10-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, que comprende adicionalmente: generar tramas AIS 50 adicionales, por medio de al menos una parte de los otros nodos MIP dispuestos en dicho primer dominio OAM, en respuesta a la detección de más fallos en el mismo; transmitir dichas tramas AIS adicionales a dicho al menos un
    nodo MEP que limita dicho primer dominio OAM; y agrupar dichas tramas AIS adicionales y dicha primera trama AIS por medio de dicho al menos un nodo MEP para generar una única segunda señal de trama AIS para su transmisión a dicho segundo dominio OAM.
    11-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 1, en el cual al menos una de dichas primera y segunda tramas AIS incluye un campo seleccionado del grupo que consiste en: campo de número de secuencia, campo de localización de fallo, campo de tipo de causa de fallo, y campo de indicación de nivel de AIS.
    12-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 11, en el cual al menos una de dichas primera y segunda tramas AIS incluye adicionalmente un campo de Tiempo de Conteo de AIS que sirve para indicar una cantidad de tiempo durante el cual ha estado presente un fallo particular.
    13-El procedimiento de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 11, en el cual al menos una de dichas primera y segunda tramas AIS incluye adicionalmente un campo de Tiempo de Conteo de AIS Borrado que sirve para indicar una cantidad de tiempo transcurrido desde que un fallo particular ha sido borrado.
  3. 14.-Un sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples niveles jerárquicos designados de dominios de Operaciones, Administración y Mantenimiento, OAM, en la cual cada dominio OAM está limitado por nodos de Punto Extremo de Mantenimiento, MEP, que limitan una pluralidad de nodos de Punto Intermedio de Mantenimiento, MIP, que comprende: medios para generar una primera trama de Indicación y Supresión de Alarma, AIS, de Ethernet, mediante al menos un nodo MIP dispuesto en un primer dominio OAM, tras detectar un fallo en dicho primer dominio OAM, para su transmisión a al menos un nodo MEP que limita dicho primer dominio OAM; medios que, tras recibir dicha primera trama Ethernet AIS, sirven para generar mediante dicho al menos un nodo MEP una segunda trama Ethernet AIS para su transmisión a un segundo dominio OAM, incluyendo dicha segunda trama Ethernet AIS una indicación de nivel que indica que se ha detectado un fallo en dicho primer dominio OAM; en el cual dicho segundo dominio OAM está dispuesto a un nivel jerárquico superior respecto a dicho primer dominio OAM; y medios que responden a dicha segunda trama Ethernet AIS, recibida en dicho segundo dominio OAM, para suprimir la generación en dicho segundo dominio OAM, en respuesta a un fallo detectado en dicho segundo dominio OAM, de una alarma causada por el fallo en dicho primer dominio OAM.
  4. 15.-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dichos primer y segundo dominios OAM comprenden unos dominios OAM de nivel de operador y de nivel de proveedor, respectivamente.
  5. 16.-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dichos primer y segundo dominios OAM comprenden unos dominios OAM de nivel de proveedor y de nivel de cliente, respectivamente
    17-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dichas primera y segunda tramas AIS son generadas con diferentes números de secuencia de la trama.
    18-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dicha primera trama AIS es generada en respuesta a la detección de un fallo en un enlace asociado con dicho al menos un MIP.
    19-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dicha primera trama AIS es generada por dicho al menos un MIP en respuesta a la detección de una condición de congestión en un enlace asociado con el mismo.
    20-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dicho al menos un nodo MIP está dispuesto cerca de la localización de dicho fallo.
    21-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual dicha primera trama AIS es multidifundida por dicho al menos un nodo MIP dentro de dicho primer dominio OAM.
    22-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual los medios, en respuesta a dicha segunda trama Ethernet AIS recibida en dicho segundo dominio OAM, para suprimir la generación en dicho segundo dominio OAM de una alarma, incluye medios, en respuesta a dicha segunda trama Ethernet AIS, recibida en dicho segundo dominio OAM, para suprimir la generación de una alarma causada por una pérdida de tramas de Comprobación de Continuidad, CC, en dicho segundo dominio OAM, debida al fallo en dicho primer dominio OAM.
    5 23-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, que comprende adicionalmente: medios asociados con al menos una parte de otros nodos MIP para generar tramas AIS adicionales en respuesta a la detección de fallos adicionales en dicho primer dominio OAM; medios para transmitir dichas tramas AIS adicionales a dicho al menos un nodo MEP que limita dicho primer dominio OAM; y medios para agrupar dichas tramas AIS adicionales y dicha primera trama
    10 AIS por medio de dicho al menos un nodo MEP para generar una única segunda señal de trama AIS para su transmisión a dicho segundo dominio OAM.
    24-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 14, en el cual al menos una de dichas primera y segunda tramas AIS incluye un campo seleccionado del grupo que consiste en: campo de número de secuencia, campo de localización
    15 de fallo, campo de tipo de causa de fallo, y campo de indicación de nivel de AIS.
    25-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 24, en el cual al menos una de dichas primera y segunda tramas AIS incluye adicionalmente un campo de Tiempo de Conteo AIS que sirve para indicar una cantidad de tiempo durante el cual ha estado presente un fallo particular.
    20 26-El sistema de propagación de información de fallos en una red Ethernet (100) que tiene múltiples dominios OAM según se relata en la reivindicación 24, en el cual al menos una de dichas primera y segunda tramas AIS incluye adicionalmente un campo de Tiempo de Conteo AIS Borrado que sirve para indicar una cantidad de tiempo transcurrido desde que un fallo particular ha sido borrado.
ES05745576.8T 2004-05-10 2005-05-03 Mecanismo de indicación y supresión de alarmas (AIS) en una red OAM Ethernet Expired - Lifetime ES2437995T3 (es)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US56972204P 2004-05-10 2004-05-10
US569722P 2004-05-10
US58625404P 2004-07-08 2004-07-08
US586254P 2004-07-08
US11/023,784 US7855968B2 (en) 2004-05-10 2004-12-28 Alarm indication and suppression (AIS) mechanism in an ethernet OAM network
US23784 2004-12-28
PCT/US2005/015171 WO2005112326A2 (en) 2004-05-10 2005-05-03 Alarm indication and suppression (ais) mechanism in an ethernet oam network

Publications (1)

Publication Number Publication Date
ES2437995T3 true ES2437995T3 (es) 2014-01-15

Family

ID=35239337

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05745576.8T Expired - Lifetime ES2437995T3 (es) 2004-05-10 2005-05-03 Mecanismo de indicación y supresión de alarmas (AIS) en una red OAM Ethernet

Country Status (8)

Country Link
US (3) US7855968B2 (es)
EP (1) EP1745577B1 (es)
JP (1) JP4764420B2 (es)
CN (1) CN101015157B (es)
ES (1) ES2437995T3 (es)
MX (1) MXPA06013033A (es)
RU (1) RU2390947C2 (es)
WO (1) WO2005112326A2 (es)

Families Citing this family (95)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7653526B1 (en) * 2002-08-16 2010-01-26 Cisco Technology, Inc. Method and system for emulating an ethernet link over a sonet path
CA2560982C (en) * 2004-05-25 2014-11-18 Nortel Networks Limited Connectivity fault notification
US7436774B2 (en) * 2004-05-27 2008-10-14 Alcatel Lucent Communication network connection rerouting methods and systems
JP4523444B2 (ja) * 2005-02-10 2010-08-11 富士通株式会社 通信ネットワークにおける障害の原因を特定する障害管理装置および方法
CN100403687C (zh) * 2005-03-29 2008-07-16 华为技术有限公司 在多协议标签交换网络中实现分域管理和保护的方法
US7843838B1 (en) * 2005-03-31 2010-11-30 Sprint Communications Company L.P. Communication network route tracing
CN100502303C (zh) * 2005-04-15 2009-06-17 华为技术有限公司 以太网与多协议标签交换网络互通的故障管理方法
US8085670B2 (en) * 2005-12-21 2011-12-27 Nortel Networks Limited Method and system for originating connectivity fault management (CFM) frames on non-CFM aware switches
US20110174307A1 (en) * 2006-01-04 2011-07-21 Lessi Stephane Device for Supplying Oxygen to the Occupants of an Aircraft and Pressure Regulator for Such a Device
US7710864B2 (en) * 2006-01-16 2010-05-04 Cisco Technology, Inc. Recovery mechanism for 10 GE optical transport network wavelength division multiplexing ring
CN100446470C (zh) * 2006-01-19 2008-12-24 华为技术有限公司 宽带以太网操作与维护实现方法
JP4583312B2 (ja) * 2006-01-30 2010-11-17 富士通株式会社 通信状況判定方法、通信状況判定システム及び判定装置
US8289965B2 (en) 2006-10-19 2012-10-16 Embarq Holdings Company, Llc System and method for establishing a communications session with an end-user based on the state of a network connection
US8488447B2 (en) 2006-06-30 2013-07-16 Centurylink Intellectual Property Llc System and method for adjusting code speed in a transmission path during call set-up due to reduced transmission performance
US9094257B2 (en) 2006-06-30 2015-07-28 Centurylink Intellectual Property Llc System and method for selecting a content delivery network
US8477614B2 (en) 2006-06-30 2013-07-02 Centurylink Intellectual Property Llc System and method for routing calls if potential call paths are impaired or congested
US8194643B2 (en) 2006-10-19 2012-06-05 Embarq Holdings Company, Llc System and method for monitoring the connection of an end-user to a remote network
US8717911B2 (en) 2006-06-30 2014-05-06 Centurylink Intellectual Property Llc System and method for collecting network performance information
US8224255B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for managing radio frequency windows
US8238253B2 (en) 2006-08-22 2012-08-07 Embarq Holdings Company, Llc System and method for monitoring interlayer devices and optimizing network performance
US9479341B2 (en) 2006-08-22 2016-10-25 Centurylink Intellectual Property Llc System and method for initiating diagnostics on a packet network node
US8750158B2 (en) 2006-08-22 2014-06-10 Centurylink Intellectual Property Llc System and method for differentiated billing
US8015294B2 (en) 2006-08-22 2011-09-06 Embarq Holdings Company, LP Pin-hole firewall for communicating data packets on a packet network
US7843831B2 (en) 2006-08-22 2010-11-30 Embarq Holdings Company Llc System and method for routing data on a packet network
US8274905B2 (en) 2006-08-22 2012-09-25 Embarq Holdings Company, Llc System and method for displaying a graph representative of network performance over a time period
US8537695B2 (en) 2006-08-22 2013-09-17 Centurylink Intellectual Property Llc System and method for establishing a call being received by a trunk on a packet network
US7684332B2 (en) 2006-08-22 2010-03-23 Embarq Holdings Company, Llc System and method for adjusting the window size of a TCP packet through network elements
US8223655B2 (en) 2006-08-22 2012-07-17 Embarq Holdings Company, Llc System and method for provisioning resources of a packet network based on collected network performance information
US8576722B2 (en) 2006-08-22 2013-11-05 Centurylink Intellectual Property Llc System and method for modifying connectivity fault management packets
US8407765B2 (en) 2006-08-22 2013-03-26 Centurylink Intellectual Property Llc System and method for restricting access to network performance information tables
US8307065B2 (en) 2006-08-22 2012-11-06 Centurylink Intellectual Property Llc System and method for remotely controlling network operators
US8531954B2 (en) * 2006-08-22 2013-09-10 Centurylink Intellectual Property Llc System and method for handling reservation requests with a connection admission control engine
US8743703B2 (en) 2006-08-22 2014-06-03 Centurylink Intellectual Property Llc System and method for tracking application resource usage
US8064391B2 (en) 2006-08-22 2011-11-22 Embarq Holdings Company, Llc System and method for monitoring and optimizing network performance to a wireless device
US8619600B2 (en) 2006-08-22 2013-12-31 Centurylink Intellectual Property Llc System and method for establishing calls over a call path having best path metrics
US8189468B2 (en) 2006-10-25 2012-05-29 Embarq Holdings, Company, LLC System and method for regulating messages between networks
US8130793B2 (en) 2006-08-22 2012-03-06 Embarq Holdings Company, Llc System and method for enabling reciprocal billing for different types of communications over a packet network
US8144587B2 (en) 2006-08-22 2012-03-27 Embarq Holdings Company, Llc System and method for load balancing network resources using a connection admission control engine
US8199653B2 (en) 2006-08-22 2012-06-12 Embarq Holdings Company, Llc System and method for communicating network performance information over a packet network
CN100550785C (zh) * 2006-08-30 2009-10-14 华为技术有限公司 一种以太网设备链路故障检测的方法及其系统
CN1968144B (zh) * 2006-09-01 2014-04-02 华为技术有限公司 操作、管理、与维护的处理方法及设备
JP4744429B2 (ja) * 2006-12-29 2011-08-10 Ｋｄｄｉ株式会社 拡張された保守ドメインレベル管理方法、通信装置、プログラム及びデータ構造
US8310941B2 (en) * 2007-05-21 2012-11-13 Telefonaktiebolaget L M Ericsson (Publ) Data driven connection fault management (DDCFM) in CFM maintenance points
US8279752B1 (en) * 2007-06-27 2012-10-02 World Wide Packets, Inc. Activating tunnels using control packets
US8284678B2 (en) * 2007-10-30 2012-10-09 Ericsson Ab Scalable connectivity fault management in a bridged/virtual private LAN service environment
CN101447975B (zh) * 2007-11-26 2013-12-04 华为技术有限公司 一种处理以太网物理层oam开销的方法及装置
ATE505876T1 (de) 2007-12-21 2011-04-15 Alcatel Lucent Verfahren zur sicherheitsverwaltung mindestens eines vlan eines ethernet-netzes
WO2009100765A1 (en) * 2008-02-15 2009-08-20 Telefonaktiebolaget Lm Ericsson (Publ) Loss link forwarding
US8068425B2 (en) 2008-04-09 2011-11-29 Embarq Holdings Company, Llc System and method for using network performance information to determine improved measures of path states
US8752131B2 (en) * 2008-04-30 2014-06-10 Fujitsu Limited Facilitating protection of a maintenance entity group
US7957299B2 (en) * 2008-07-18 2011-06-07 Embarq Holdings Company, Llc System and method for tracking alarms in a packet network
US8018863B2 (en) * 2008-09-09 2011-09-13 Telefonaktiebolaget L M Ericsson Reducing CC message transmission in a provider network
US8259906B2 (en) * 2008-09-22 2012-09-04 Centurylink Intellectual Property Llc System and method for testing a DSL and POTS connection
JP5151927B2 (ja) * 2008-11-21 2013-02-27 富士通株式会社 伝送装置、警報制御方法、警報制御プログラムおよびメッセージ送受信プログラム
CN101753521B (zh) * 2008-11-28 2013-01-16 中兴通讯股份有限公司 维护实体组层次的处理方法及装置
JP5146377B2 (ja) * 2009-03-18 2013-02-20 富士通株式会社 通信装置および監視パケット転送方法
EP2254276B1 (en) * 2009-05-20 2014-04-09 Alcatel Lucent Method for signalling of data transmission path properties to a non-OAM observent client
US8458322B2 (en) 2009-07-24 2013-06-04 Cisco Technology, Inc. Dynamic management of maintenance association membership in a computer network
US8572435B2 (en) * 2009-08-05 2013-10-29 International Business Machines Corporation System and method for correlating carrier ethernet connectivity fault management events
US8457138B1 (en) 2009-12-18 2013-06-04 Adtran, Inc. Systems and methods for propagating frame relay congestion notifications through a packet network
US8547832B2 (en) * 2010-02-05 2013-10-01 Cisco Technology, Inc. Distributing ethernet alarm indication signal information to multiple virtual local area networks
US8675498B2 (en) * 2010-02-10 2014-03-18 Cisco Technology, Inc. System and method to provide aggregated alarm indication signals
US8593973B2 (en) 2010-03-09 2013-11-26 Juniper Networks, Inc. Communicating network path and status information in multi-homed networks
JP5534006B2 (ja) 2010-04-15 2014-06-25 日本電気株式会社 伝送装置、伝送方法及びコンピュータプログラム
US8526313B1 (en) 2010-04-20 2013-09-03 Adtran, Inc. System and method for extending connectivity tests through a packet network
US8416679B2 (en) * 2010-05-11 2013-04-09 Fujitsu Limited Systems and methods for transmission of alarm indication suppression messages in connection with failure of network element equipment
US8724454B2 (en) * 2010-05-12 2014-05-13 Cisco Technology, Inc. System and method for summarizing alarm indications in a network environment
US8630186B2 (en) * 2010-05-17 2014-01-14 Fujitsu Limited Systems and methods for transmission of trigger-based alarm indication suppression messages
JP2011250128A (ja) * 2010-05-26 2011-12-08 Fujitsu Ltd 中継装置、制御情報生成方法及び制御情報生成プログラム
CN102263654B (zh) * 2010-05-26 2013-11-06 杭州华三通信技术有限公司 实现维护域内多层跨级别告警抑制的方法、系统和装置
US9185602B2 (en) 2010-05-28 2015-11-10 Nec Corporation Transmission device, bandwidth control method and computer program
US8195989B1 (en) * 2010-08-20 2012-06-05 Juniper Networks, Inc. Detection of ethernet link failure
JP5527616B2 (ja) * 2010-12-03 2014-06-18 日立金属株式会社 ネットワークシステム
CN102143005B (zh) * 2011-04-14 2015-01-28 中兴通讯股份有限公司 一种基于oam协议确定故障消除的方法及装置
CN102185711B (zh) * 2011-04-26 2014-12-10 中兴通讯股份有限公司 一种检测混合网络中链路故障的方法及设备
CN102790702B (zh) * 2011-05-19 2017-09-08 中兴通讯股份有限公司 分组路径信号劣化的检测方法、装置及系统
CN102843249B (zh) * 2011-06-21 2018-09-18 南京中兴新软件有限责任公司 一种分组传送网络中维护管理状态传递的方法和设备
WO2013046496A1 (ja) 2011-09-27 2013-04-04 日本電気株式会社 通信システム、送信装置、通信装置、障害通知方法、及びプログラムが格納された非一時的なコンピュータ可読媒体
US9461886B2 (en) * 2012-02-22 2016-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Self-organizing network function interaction
US9438486B2 (en) 2012-06-14 2016-09-06 At&T Intellectual Property I, L.P. Intelligent network diagnosis and evaluation via operations, administration, and maintenance (OAM) transport
CN102769673B (zh) * 2012-07-25 2015-03-25 深圳市中博科创信息技术有限公司 一种适应于大规模存储集群的失效检测方法
US9270564B2 (en) 2012-09-11 2016-02-23 Alcatel Lucent System and method for congestion notification in an ethernet OAM network
JP2014064252A (ja) * 2012-09-24 2014-04-10 Hitachi Ltd ネットワークシステム、伝送装置、及び障害情報通知方法
EP2981025B1 (en) * 2013-04-16 2018-07-11 Huawei Technologies Co., Ltd. Method, network and system for protection switching
ES2762075T3 (es) 2013-06-29 2020-05-22 Huawei Tech Co Ltd Método y sistema de protección para una red multidominio y nodo
CN105591775B (zh) * 2014-10-23 2019-10-25 华为技术有限公司 一种网络的操作管理维护oam方法、装置和系统
CN107431655B (zh) 2016-02-12 2020-06-26 华为技术有限公司 分段保护中的故障传播的方法和设备
US9913116B2 (en) 2016-02-24 2018-03-06 Robert D. Pedersen Multicast expert system information dissemination system and method
JP2017228914A (ja) * 2016-06-22 2017-12-28 富士通株式会社 伝送装置、警報転送方法および警報転送システム
CN108924004B (zh) * 2018-06-29 2021-01-19 中国科学院深圳先进技术研究院 商用酒店厨房物联网数据的异常检测分析方法及相关产品
RU2738460C1 (ru) * 2020-02-26 2020-12-14 Общество с ограниченной ответственностью "Сайберлимфа" Способ выявления аномалий в работе сети автоматизированной системы
CN113709777B (zh) * 2020-05-21 2025-12-16 华为技术有限公司 一种故障处理方法、装置及系统
US11356756B1 (en) * 2021-04-05 2022-06-07 Commonwealth Edison Company Passive optical network for utility infrastructure resiliency
US20250202830A1 (en) * 2022-03-17 2025-06-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for detecting and reordering disorder packets
CN115866458B (zh) * 2022-11-29 2025-08-29 中国联合网络通信集团有限公司 故障信息的发送方法、装置、设备及存储介质

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3011130B2 (ja) * 1996-10-11 2000-02-21 日本電気株式会社 Ａｔｍ信号切替装置
AP9901547A0 (en) * 1996-11-18 1999-06-30 Mci Worldwide Inc A communication system architecture.
US6052722A (en) 1997-03-07 2000-04-18 Mci Communications Corporation System and method for managing network resources using distributed intelligence and state management
US6411598B1 (en) 1997-03-12 2002-06-25 Mci Communications Corporation Signal conversion for fault isolation
US20030133417A1 (en) 1997-03-12 2003-07-17 Sig H. Badt Method and message therefor of monitoring the spare capacity of a dra network
JPH11266265A (ja) * 1998-03-18 1999-09-28 Toshiba Corp Ｏａｍ装置
EP1043855B1 (en) * 1999-04-07 2006-11-08 Lucent Technologies Inc. Secondary alarm filtering
US7054265B1 (en) * 1999-06-09 2006-05-30 Hitachi, Ltd. Communication apparatus and communication system
JP3482996B2 (ja) * 1999-12-03 2004-01-06 日本電気株式会社 Ａｔｍスイッチ
US7012887B2 (en) * 2001-05-08 2006-03-14 Sycamore Networks, Inc. Method for restoring diversely routed circuits
JP3695375B2 (ja) * 2001-09-26 2005-09-14 日本電気株式会社 警報転送方式及び方法
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
JP3972664B2 (ja) * 2002-01-23 2007-09-05 日本電気株式会社 パス障害回復方式及び障害復旧後の切戻方式並びにそれらを用いるノード
US20040160895A1 (en) * 2003-02-14 2004-08-19 At&T Corp. Failure notification method and system in an ethernet domain
JP4096183B2 (ja) * 2003-02-27 2008-06-04 日本電気株式会社 警報転送方法及び広域イーサネット網
US20040184407A1 (en) * 2003-03-21 2004-09-23 Sbc Knowledge Ventures, L.P. Operations, administration, and maintenance data packet and related testing methods
US20050099949A1 (en) * 2003-11-10 2005-05-12 Nortel Networks Limited Ethernet OAM domains and ethernet OAM frame format
US20050099954A1 (en) * 2003-11-10 2005-05-12 Nortel Networks Limited Ethernet OAM network topography discovery
US20050099955A1 (en) * 2003-11-10 2005-05-12 Nortel Networks Limited Ethernet OAM fault isolation
US7924725B2 (en) * 2003-11-10 2011-04-12 Nortel Networks Limited Ethernet OAM performance management
US8045475B2 (en) * 2003-11-10 2011-10-25 Nortel Networks Limited Method and apparatus for providing availability metrics for measurement and management of ethernet services
CA2560982C (en) * 2004-05-25 2014-11-18 Nortel Networks Limited Connectivity fault notification

Also Published As

Publication number Publication date
WO2005112326A2 (en) 2005-11-24
US7855968B2 (en) 2010-12-21
US8699353B2 (en) 2014-04-15
EP1745577A4 (en) 2009-11-04
WO2005112326A3 (en) 2006-11-30
US9774490B2 (en) 2017-09-26
JP2007536878A (ja) 2007-12-13
MXPA06013033A (es) 2006-12-20
CN101015157B (zh) 2012-05-30
RU2006143638A (ru) 2008-06-20
EP1745577A2 (en) 2007-01-24
CN101015157A (zh) 2007-08-08
JP4764420B2 (ja) 2011-09-07
RU2390947C2 (ru) 2010-05-27
US20050249119A1 (en) 2005-11-10
US20110116363A1 (en) 2011-05-19
US20140219106A1 (en) 2014-08-07
EP1745577B1 (en) 2013-10-09

Similar Documents

Publication Publication Date Title
ES2437995T3 (es) Mecanismo de indicación y supresión de alarmas (AIS) en una red OAM Ethernet
EP1766865B1 (en) Connectivity fault notification
US8406143B2 (en) Method and system for transmitting connectivity fault management messages in ethernet, and a node device
CN1697401B (zh) 远程接入链路故障指示方法和网络
US9270564B2 (en) System and method for congestion notification in an ethernet OAM network
US10015066B2 (en) Propagation of frame loss information by receiver to sender in an ethernet network
US20070268817A1 (en) Method and system for protecting a sub-domain within a broadcast domain
US20100287405A1 (en) Method and apparatus for internetworking networks
US20060133286A1 (en) System and method for detecting loops in a customer-provider bridge domain
CN105281931A (zh) Potn的误码检测方法、装置及系统
CN114844817B (zh) 一种在段路由sr网络中进行保护倒换方法及装置
McFarland et al. Ethernet OAM: key enabler for carrier class metro ethernet services
US7957299B2 (en) System and method for tracking alarms in a packet network
US20100246412A1 (en) Ethernet oam fault propagation using y.1731/802.1ag protocol
CN101729201B (zh) 用于检测信号劣化缺陷的方法
CN112995024A (zh) 信号劣化告警方法、系统、终端设备及存储介质
CN1947375A (zh) 连通性故障通知
Ohta Standardization status on carrier class Ethernet OAM