Método y aparato para soportar detección de desacuerdo.

Un método para la gestión de instancias de servicios en un primer nodo de red (2,

3, 22, 70, 80) de una red de comunicación (1), comprendiendo el método

monitorizar una pluralidad de rutas de red (7, 8, 26, 27, 28) bidireccionales y distintas para transportar un número de instancias de servicios (10a, 10b, 10c, 24, 25, 41, 42) desde el primer nodo de red a un segundo nodo de red (2, 3, 22, 70, 80), donde un número de las citadas rutas de red forman un grupo de protección asociado con una respectiva instancia de servicio o grupo de instancias de servicios, incluyendo la citada monitorización:

enviar (56) continua y periódicamente Mensajes de Comprobación de Continuidad, CCMs (Continuity Check Messages, en inglés) (11), en una ruta de red (7, 8, 26, 27, 28) monitorizada hacia el segundo nodo de red (2, 3, 22, 70, 80);

en respuesta a la ocurrencia de un evento predeterminado, incluir (53) un bit de indicación en los CCMs (11), que son enviados en la citada ruta de red monitorizada durante un periodo de tiempo predeterminado tras la ocurrencia del citado evento predeterminado, donde el bit de indicación indica la presencia de un elemento de información de desacuerdo (13a - d, 44a – d) en el CCM que incluye el bit de indicación, donde el elemento de instancia de desacuerdo incluye información que especifica, para cada grupo de protección que la citada ruta de red monitorizada es un miembro de, estado del tráfico de una ruta de red de trabajo y de una ruta de red de protección del grupo de protección.

Método y aparato para soportar detección de desacuerdo

Campo técnico

La presente invención se refiere a las redes de comunicación, y en particular a métodos y disposiciones para la gestión de instancias de servicios que proporcionan soporte para detección de desacuerdo.

Antecedentes La Gestión de Fallos de Conectividad (CFM – Connectivity Fault Management, en inglés) , tal como se describe en el estándar IEEE Std 802.1ag – 2007, es un componente de operación, administración y mantenimiento clave para la Ethernet portadora. El estándar IEEE 802.1ag especifica protocolos, procedimientos y objetos gestionados para la detección, verificación y aislamiento de fallos de extremo a extremo. El estándar IEEE 802.1ag establece que los objetos gestionados, denominados Asociaciones de Mantenimiento (MAs – Maintenance Associations, en inglés) verifiquen la integridad de una única instancia de servicio intercambiando mensajes de CFM. El alcance de una MA es determinado por su Dominio de Gestión (MD – Management Domain, en inglés) , que describe una región de red en la cual son gestionados la conectividad y el rendimiento. Cada MA asocia dos o más Puntos de Extremo de Asociación de Mantenimiento (MEPs – Maintenance Association Endpoints, en inglés) y permite que los Puntos Intermedios de Asociación de Mantenimiento (MIPs – Maintenance Association Intermediate Points, en inglés) soporten detección y aislamiento de fallos.

Se utiliza un protocolo de comprobación de continuidad para la detección de fallos. Cada MEP transmite periódicamente Mensajes de Comprobación de Continuidad (CCMs – Continuity Check Messages, en inglés) y rastrea los CCMs recibidos desde otros MEPSs en la misma asociación de mantenimiento.

Puentes de Red Troncal de Proveedor – Ingeniería del Tráfico (PBB-TE – Provider Backbone Bridging – Traffic Engineering, en inglés) , tal como se describe en el estándar IEEE Std 802.1Qay – 2009, fue diseñada para proporcionar ingeniería del tráfico completa de las rutas en una red con puentes. La PBB-TE elimina la necesidad de que los dispositivos de red troncal lleven a cabo aprendizaje e inundación. En lugar de utilizar el Protocolo de Árbolde Expansión Múltiple / Protocolo de Árbol de Expansión Rápida (MSTP/RSTP – Multiple Spanning Tree Protocol / Rapid Spanning Tree Protocol, en inglés) para evitar bucles, la PBB-TE utiliza un plano de gestión o un plano de control externo para crear entradas de tabla de filtrado estático en los puentes de componente.

La PBB-TE es una tecnología de Ethernet orientada a la conexión que utiliza una tupla estadísticamente configurada que consiste en la Dirección de Destino de ESP (ESP-DA – ESP Destination Address, en inglés) , Dirección de Fuente de ESP (ESP-SA – ESP Source Address, en inglés) e ID de VLAN de ESP (ESP-VID – ESP VLAN ID, en inglés) para crear una ruta de PBB-TE. La ruta provista se denomina una Ruta Conmutada de Ethernet (ESP – Ethernet Switched Path, en inglés) . Dos ESPs de punto a punto con la misma ruta con las mismas direcciones de MAC de Puerto de Red Troncal de Abonado (CBP – Customer Backbone Port, en inglés) forman un servicio de MAC bidireccional, que se denomina una Instancia de Servicio de Ingeniería del Tráfico (TESI – Traffic Engineering Service Instance, en inglés) de punto a punto.

La PBB-TE soporta conmutación de protección de ruta bidireccional de 1:1. Dos TESIs de punto a punto son proporcionadas como un grupo de protección de TE (TEPG – TE Protection Group, en inglés) . Una TESI está configurada como una TESI “de trabajo” y la otra como una TESI “de protección”. En condiciones normales, el tráfico es transmitido sobre la TESI de trabajo. En el caso de un fallo de la TESI de trabajo o una solicitud administrativa específica, el tráfico es conmutado a la TESI de protección.

Opcionalmente, las rutas protegidas de 1:1 de PBB-TE pueden estar configuradas para permitir compartición de carga. En el modo de compartición de carga, las TESIs que están asignadas a un grupo de protección de TE pueden ser reutilizadas en un número de grupos de protección de TE, permitiendo que una lista de diferentes instancias de servicios de red troncal sean distribuidas entre un conjunto de grupos de protección de TE independientes. En otras palabras, en el modo de compartición de carga, una TESI puede ser una TESI de protección en un grupo de protección de TE y ser una TESI de protección o de trabajo en otro grupo de protección.

Cada TESI es monitorizada por una MA independiente, y cada MA tiene dos MEPs. Uno está situado en un CBP de extremo cercano; el otro está situado en un CBP del extremo lejano. Cuando el MEP de extremo cercano detecta la pérdida de CCMs, lo notifica al MEP de extremo lejano enviando un CCM con una marca de Indicador de Defecto Remoto (RDI – Remote Defect Indicator, en inglés) . Los dos extremos conocen el fallo (bien por pérdida de CCMs o recibiendo el CCM con la marca del RDI) , de manera que la conmutación de protección a la TESI es llevada a cabo en ambos extremos. Cuando un fallo es eliminado, el tráfico puede ser conmutado de nuevo a la TESI de trabajo o puede permanecer en la TESI de protección de acuerdo con el modo configurado (reversible o no reversible) .

Bajo ciertas condiciones de mal funcionamiento y/o configuración errónea del equipo, puede producirse un desacuerdo entre el mapeo de las instancias de servicio de red troncal a las TESIs apropiadas en el CBP de

finalización. Para mantener la adecuada operación de la red, este desacuerdo debe ser detectado y reportado al operador de la red. Entonces el operador de la red puede eliminar el defecto. Existen dos tipos de desacuerdo en la conmutación de protección bidireccional de 1:1:

! Desacuerdo incompleto de conmutación de protección; y

! Desacuerdo de configuración de Trabajo / de protección.

El desacuerdo incompleto de la conmutación de protección puede producirse, por ejemplo, si el extremo cercano, debido a un mal funcionamiento del hardware, falla al conmutar, pero envía un RDI al extremo lejano. El extremo lejano conmuta a la TESI de protección mientras que el extremo cercano está todavía en la TESI de trabajo. De manera similar, puede producirse también un desacuerdo cuando el extremo cercano conmuta a la TESI de protección, pero el extremo lejano falla en conmutar cuando recibe el RDI.

Un desacuerdo puede producirse también debido a una configuración errónea. Por ejemplo, un extremo puede ser configurado para enviar tráfico en la TESI de trabajo mientras que el otro extremo está configurado para enviar tráfico en la TESI de protección. De manera similar, un extremo puede estar configurado en el modo reversible mientras que el otro extremo está configurado en el modo no reversible. En este caso, el desacuerdo se produce cuando se elimina un fallo.

La PBB-TE soporta la protección de un grupo de TESIs atravesando una secuencia común de Puertos de Red de Proveedor (PNP – Provider Network Ports, en inglés) . Tal secuencia de PNPs, junto con los repetidores y LANs de Puente que intervienen se denomina segmento de infraestructura o en ocasiones simplemente segmento. El grupo de TESIs está protegido de que se produzca un fallo de conectividad en algún sitio a lo largo del segmento de infraestructura, incluidos los PNPs del punto final. El método de protección no afecta a las porciones de las TESIs que se encuentran fuera del segmento; esto es, el alcance de la protección está limitado al segmento especificado. Este tipo de protección se denomina Protección de Segmento de Infraestructura, lo que se especifica en el estándar IEEE P802.1Qbf/D0.0.

Existen dos tipos de Conmutación de Protección de Infraestructura (IPS – Infrastructure Protection Switching, en inglés) : IPS de 1:1 e IPS de M:1. En la IPS de 1:1 un segmento de trabajo y un segmento de protección asociado se dice que forman un grupo de protección de infraestructura (IPG – Infrastructure Protection Group, en inglés) . En IPS de M:1 se proporcionan segmentos de protección adicionales. Cada uno de tales segmentos de protección adicionales se denomina segmento de protección alternativo. Un segmento de protección alternativo puede asumir la función del segmento de protección si se ha detectado un fallo de conectividad del segmento de protección. La IPS de M:1 requiere que todos los segmentos asociados con el IPG sean disjuntos entre sí. A cada Segmento de Protección Alternativo se le asigna una prioridad de selección única dentro del IPG. Cuando se detecta un fallo asociado con el segmento de protección,... [Seguir leyendo]

1. Un método para la gestión de instancias de servicios en un primer nodo de red (2, 3, 22, 70, 80) de una red de comunicación (1) , comprendiendo el método monitorizar una pluralidad de rutas de red (7, 8, 26, 27, 28) bidireccionales y distintas para transportar un número de instancias de servicios (10a, 10b, 10c, 24, 25, 41, 42) desde el primer nodo de red a un segundo nodo de red (2, 3, 22, 70, 80) , donde un número de las citadas rutas de red forman un grupo de protección asociado con una respectiva instancia de servicio o grupo de instancias de servicios, incluyendo la citada monitorización:

enviar (56) continua y periódicamente Mensajes de Comprobación de Continuidad, CCMs (Continuity Check Messages, en inglés) (11) , en una ruta de red (7, 8, 26, 27, 28) monitorizada hacia el segundo nodo de red (2, 3, 22, 70, 80) ;

en respuesta a la ocurrencia de un evento predeterminado, incluir (53) un bit de indicación en los CCMs (11) , que son enviados en la citada ruta de red monitorizada durante un periodo de tiempo predeterminado tras la ocurrencia del citado evento predeterminado, donde el bit de indicación indica la presencia de un elemento de información de desacuerdo (13a - d, 44a – d) en el CCM que incluye el bit de indicación, donde el elemento de instancia de desacuerdo incluye información que especifica, para cada grupo de protección que la citada ruta de red monitorizada es un miembro de, estado del tráfico de una ruta de red de trabajo y de una ruta de red de protección del grupo de protección.

2. El método de acuerdo con la reivindicación 1, en el que el citado número de instancias de servicios son servicios de red troncal (10a, 10b, 10c) y la citada pluralidad de rutas de red son Instancias de Servicios de Ingeniería del Tráfico, TESIs (Traffic Engineering Service Instances, en inglés) (7, 8) .

3. El método de acuerdo con la reivindicación 1, en el que el citado número de instancias de servicios son las TESIs (24, 25, 41, 42) y la citada pluralidad de rutas de red son los Segmentos de Infraestructura (26, 27, 28, 29) .

4. El método de acuerdo con cualquiera de las reivindicaciones 1 – 3, en el que el citado evento predeterminado es una transición de estado en una máquina de estados para controlar el estado del tráfico de la citada pluralidad de rutas de red.

5. El método de acuerdo con cualquiera de las reivindicaciones 1 – 4, en el que cada elemento de información de desacuerdo (13a – d, 44a – d) es un elemento de tipo – longitud - valor, TLV, que comprende, para cada grupo de protección el que la citada ruta de red monitorizada es un miembro de, una identidad del grupo de protección, un bit que indica el estado del tráfico para la citada ruta de red de trabajo del grupo de protección y un bit que indica el estado del tráfico para la citada ruta de red del citado grupo de protección.

6. El método de acuerdo con cualquiera de las reivindicaciones 1 – 5, en el que el citado primer nodo es un puente o una central de conmutación de una red de Ethernet.

7. El método de acuerdo con cualquiera de las reivindicaciones 1 – 6, que comprende también

detectar (54) un desacuerdo si al menos uno de los citados elementos de información de desacuerdo (13a – d, 44a – d) , que están incluidos en un CCM enviado, especifica estados del tráfico en conflicto de la ruta de red de trabajo y de la ruta de red de protección de al menos un grupo de protección;

y

notificar (55) a un Sistema de Gestión de Red, NMS (Network Management System, en inglés) (12) , o un operador del desacuerdo detectado.

8. El método de acuerdo con cualquiera de las reivindicaciones 1 – 7, que comprende también recibir (61) un número de CCMs (11) desde el segundo nodo de red;

para cada CCM (11) recibido: leer (63) un elemento de información de desacuerdo desde el CCM recibido, si el CCM recibido incluye un bit de indicación que indica la presencia del elemento de información de desacuerdo en el CCM recibido y comparar (63) el elemento de información de desacuerdo del CCM recibido con el elemento de información de desacuerdo incluido en un CCM enviado;

detectar (64) un desacuerdo si los elementos de información de desacuerdo comparados difieren durante un segundo periodo de tiempo predeterminado, y

notificarlo (65) a un Sistema de Gestión de Red, NMS (Network Management System, en inglés) (12) , o a un operador el desacuerdo detectado.

9. Un nodo de red (2, 3, 22, 70, 80) para su uso en una red de comunicación (1) , comprendiendo el nodo de red un número de entidades de Operación, Administración y Gestión, OAM (Operation, Administración and Management, en inglés) (9a – d, 43a – d, 73) configuradas para monitorizar una pluralidad de rutas de red (7, 8, 26, 28) bidireccionales y distintas para transportar un número de instancias de servicios (10a, 10b, 10c, 24, 25, 41, 42) desde el nodo de red a otro nodo de red, donde un número de las citadas rutas forma un grupo de protección asociado con una respectiva instancia de servicio o grupo de instancias de servicios, donde el citado número de entidades de OAM están también configuradas para continua y periódicamente enviar Mensajes de Comprobación de Continuidad, CCMs (Continuity Check Messages, en inglés) (11) , en una ruta de red monitorizada al otro nodo de red;

en respuesta a la ocurrencia de un evento predeterminado, incluir un bit de indicación en los CCMs (11) , que son enviados en la citada ruta de red monitorizada durante un primer periodo de tiempo predeterminado tras la ocurrencia del citado evento predeterminado, donde el bit de indicación indica la presencia de un elemento de información de desacuerdo (13a – d, 44a – d) en el CCM que incluye el bit de indicación, donde el elemento de información de desacuerdo incluye información que especifica, para cada grupo de protección que la citada ruta de red monitorizada es un miembro de, estado del tráfico de una ruta de red de trabajo y de una ruta de red de protección del grupo de protección.

10. El nodo de red (2, 3, 70, 80) de acuerdo con la reivindicación 9, donde el citado número de instancias de servicios (10a, 10b, 10c) son servicios de red troncal y la citada pluralidad de rutas de red son Instancias de Servicios de Ingeniería del Tráfico, TESIs (Traffic Engineering Service Instances, en inglés) (7, 8) .

11. El nodo de red (22, 70, 80) de acuerdo con la reivindicación 9, en donde el citado número de instancias de servicios son TESIs (24, 25, 41, 42) y la citada pluralidad de rutas de red son Segmentos de Infraestructura (26, 27, 28, 29) .

12. El nodo de red de acuerdo con cualquiera de las reivindicaciones 9 – 11, donde el citado evento predeterminado es una transición de estado en una máquina de estados para controlar el estado del tráfico de la citada pluralidad de rutas de red.

13. El nodo de red (2, 3, 22, 70, 80) de acuerdo con cualquiera de las reivindicaciones 9 – 12, donde el citado elemento de información de desacuerdo (13a – d, 44a – d) es un elemento tipo-longitud-valor, TLV, que comprende, para cada grupo de protección del cual es un miembro la citada ruta de red monitorizada, una identidad del grupo de protección, indicando un bit el estado del tráfico para la citada ruta de red de trabajo del grupo de protección y un bit indicando el estado del tráfico para la citada ruta de red de protección del grupo de protección.

14. El nodo de red (2, 3, 22, 70, 80) de acuerdo con cualquiera de las reivindicaciones 9 – 13, en el que el citado nodo de red es un puente o una central de conmutación de una red de Ethernet.

15. El nodo de red (2, 3, 22, 70, 80) de acuerdo con cualquiera de las reivindicaciones 9 – 14, donde el citado número de entidades de OAM están también configuradas para

detectar un desacuerdo si al menos uno de los citados elementos de información de desacuerdo (13a – d, 44a – d) , que está incluido en un CCM enviado, especifica un estado del tráfico de la ruta de red de trabajo y de la ruta de red de protección de al menos un grupo de protección en conflicto; y notificarlo a un Sistema de Gestión de Red, NMS (Network Management System, en inglés) (12) , o a un operador del desacuerdo detectado.

16. El nodo de red (2, 3, 22, 70, 80) de acuerdo con cualquiera de las reivindicaciones 9 – 15, donde el citado número de entidades de OAM (9a – d, 43a – d, 73) están también configuradas para

recibir un número de CCMs (11) del otro nodo de red;

para cada CCM recibido: leer un elemento de información de desacuerdo (13a – d, 11a – d) del CCM recibido, si el CCM recibido incluye un bit de indicación que indica la presencia del elemento de información de desacuerdo en el CCM recibido y comparar el elemento de información de desacuerdo del CCM recibido con el elemento de información de desacuerdo incluido en un CCM enviado;

detectar un desacuerdo si los elementos de información de desacuerdo comparados difieren durante un segundo periodo de tiempo predeterminado, y

notificar a un Sistema de Gestión de Red, NMS (Network Management System, en inglés) (12) , o a un operador el desacuerdo detectado.