MX2012000332A - Metodos y dispositivos en una red de telecomunicaciones de mpls - tp para funciones de oam. - Google Patents

Abstract

Se describen extensiones a un procedimiento de envío de trama de Intercambio de Etiqueta de Múltiples protocolos (MPLS) en un nodo de MPLS. Un descriptor de contexto se define para cada trama recibida en una conexión terminada en dicho nodo y en donde este descriptor de contexto se provee junto con la trama a una función correspondiente (v.gr., operaciones, Administración y Mantenimiento, OAM) si es necesario. El descriptor del contexto se construye con base en atributos clave que caracterizan la conexión terminada sobre la cual se recibe la trama y dirige un punto final de función particular (MEP) Puente de Selector de un caso de protección, etc.) de una función correspondiente (OAN, protección, etc.). En una modalidad, un nodo de Intercambio de Etiqueta de múltiples Protocolos (MPLS) se dirige para revisar no solo la primera sino la segunda etiqueta y no tira la primera etiqueta (y el espacio de etiqueta si es relevante) cuando la segunda etiqueta es la Etiqueta de Canal de Asociación Genérica (GAL). De esta manera, el contexto original del paquete se mantiene (es decir, la información que se refiere a la conexión sobre la cual se recibió el paquete) y puede usarse para desmultiplexar MEP correspondiente. Luego los identificadores dentro de la carga útil de OAM se pueden usar para verificar la conectividad. Otras modalidades describen soluciones alternativas.

Description

MÉTODOS Y DISPOSICIÓN EN UNA RED DE TELECOMUNICACIONES DE MPLS-TP PARA FUNCIONES DE OAM Campo Técnico La presente invención se refiere a redes de telecomunicaciones y particularmente, pero no exclusivamente, a un método y disposición para dirigir puntos de mantenimiento en un nodo de una red de transporte con cambio de paquetes.

Antecedentes El intercambio de Etiquetas de Múltiples Protocolos (MPLS, por sus siglas en inglés) es un mecanismo en redes de telecomunicación que dirige y lleva paquetes de datos de un nodo a otros nodos . Cada paquete de datos comprende una etiqueta adherible, sobre la cual se toman decisiones de envío sin la necesidad de consultar la parte restante del paquete .

Con base en el plano de envío de MPLS existente, el Plano de Transporte de Intercambio de Etiquetas de Múltiples Protocolos (MPLS-TP) ayuda a proveer una trama para cumplir con los requerimientos de redes de transporte. Un área clave es tener un conjunto de funciones de Operaciones, Administración y Mantenimiento (OAM) bien definidos. Esto conjunto de funciones de OAM está bajo estandarización en la Fuerza de Tareas de Ingeniería en Internet (IETF, por sus siglas en inglés). La trama y requerimientos de OAM definen varias funciones (Revisión de Continuidad (CC) , Verificación de Conectividad (CV) , Señales de Manejo, etc.) que deberán soportarse por la solución de OAM desarrollada.

La operación de OAM para MPLS-TP es que los atributos de OAM necesarios (identificadores, cronómetros, contadores, etc.) se codifican en dichas tramas de OAM así llamadas que se multiplexan en el flujo de datos. De esta forma se asegura el destino de marcos de OAM y flujo de datos, es decir, las tramas de OAM y flujo de datos experimentan el mismo proceso al ser enviados de un nodo a otro. Las tramas de OAM se generan y reciben por Puntos Finales de Mantenimiento (MEP, por sus siglas en inglés) que residen en los puntos finales de una conexión.

Actualmente, la arquitectura de MPLS-TP consiste de tres capas: Pseudocables (W, por sus siglas en inglés), Tunes (conexión ) de Trayectoria con Intercambio de Etiquetas (LSP, por sus siglas en inglés) y capas de Secciones (enlace de datos) . El OAM de MPLS-TP se supone que soporta las tres capas .

Actualmente, varias soluciones competidoras para codificar los parámetros de OAM son propuestas. Sin embargo, estas soluciones se basan en el mismo método para multiplexar las tramas de OAM en los flujos de datos. El método define un canal asociado para portar las tramas de OAM y otras tramas de control/manejo. En el caso de P , estos canales se identifican y desmultiplexan usando solo el Encabezado de Canal Asociado Genérico (G-ACH) . En el caso de túneles de LSP y secciones, una etiqueta adicional se define para indicar los canales asociados. Esta eiqueta se denomina como la Etiqueta de Canal de Asociación Genérica (GAL) . El lado de salida (es decir, el lado de destino) detecta y desmultiplexa las tramas de oAM con base en estas etiquetas.

Sin embargo, estas soluciones que se basan en la transmisión de tramas de OAM . dentro de G-ACH tienen el siguiente problema en MPLS y MPLS-TP: en el caos de capas de Túnel y Sección de LSP, el mecanismo de envío de datos MPLS estándar no proveen suficiente método para dirigir MEP del plano de datos usando identificadores que se usan para envío de plano de datos también.

El comportamiento de envío de MPLS estándar en un nodo particular es como sigue. Con base en la primera etiqueta en la pila (etiqueta de túnel) el nodo busca un Siguiente Salto de Entrada de Envío de Etiquetas (NHLFE, por sus siglas en inglés) . Esta entrada instruye el nodo, lo cual hace con la pila de etiquetas (resalta la primera etiquete, cambia el lugar de la primera etiqueta, empuja una nueva etiqueta en la parte superior de la pila, etc.) y en donde para enviar el paquete (salto al siguiente nodo) .

Si el nodo es un nodo de salida que termina una conexión, se codifica NHLFE para instruir el nodo para remover, es decir, saltar, la etiqueta de túnel de la pila y llevar a cabo una búsqueda en el paquete restante. Si existe cualquier etiqueta adicional en la pila, se lleva a cabo una segunda búsqueda independiente para la siguiente etiqueta en la pila. Esta segunda etiqueta puede ser una GAL, por ejemplo, lo que significa que el paquete deberá pasar a la función de control del nodo local y el GAL deberá removerse de la trama. Luego, la función de control de dicho nodo puede procesar la trama y enviar el paquete de OAM al MEP apropiado .

La Figura 1 muestra una trama de paquete de MPLS que se puede usar en el mecanismo de envío descrito antes. Una pila de etiquetas comprende, por ejemplo, una etiqueta externa que es una etiqueta de túnel de LSP. Esta puede tener la forma de una etiqueta que identifica explícitamente un nodo de salida, o la forma de una etiqueta de Tiempo de Vida (TTL, por sus siglas en inglés) que determina el nodo de salida basado en el número de saltos. Un encabezado de canal asociado contiene información que se procesa por un proceso de desmultiplexión de G-ACH, mientras que la carga útil de mensaje de G-ACH contiene la carga útil del paquete, por ejemplo, una carga útil de OEM para enviarse a un MEP.

Por lo tanto se apreciará que el plano de datos de MPLS no permite que un MEP particular sea dirigido usando atributos de plano de datos (por ejemplo etiquetas en el plano de datos) . En su lugar, un MEP solo puede dirigirse por la desraultiplexión de la carga útil de OAM y usando identificadores (es decir, enrutando información) dentro de la carga útil de OAM para dirigir el MEP apropiado.

Después de multiplexar el MEP correspondiente, la conectividad correcta deberá verificarse por el uso de identificadores contenidos en la carga útil de OAM. Aunque estos identificadores son únicos en cualquier nodo o el nivel de red, la conexión sobre la cual se recibe el paquete no puede identificarse, es decir, la conexión entrante no se puede identificar si existen conexiones paralelas múltiples entre el nodo de ingreso y el de egreso. Además, como se describió antes ninguna etiqueta de túnel (primera etiquete) ni la interfaz entrante están disponibles después de que se ha desmultiplexado la carga útil de OAM. Esto significa que no es posible verificar la conectividad correcta, es decir, no es posible llevar a cabo una operación de Verificación de Conectividad (CV) completa.

Una solución conocida propuesta por verificación de conectividad de OAM de MPLS-TP es un método basado en trazas de enlace. Además, esta solución o implica el proceso complejo, no solo en los puntos finales de una conexión sino en todos los nodos intermedios que envían una conexión debido a que el método se diseñó originalmente para una función diferente. Esto tiene la desventaja de consumir una cantidad indeseable de recursos de proceso. El método basado en trazas de enlace también tiene la desventaja de no ser fácilmente aumentable .

Sumario Los propósitos de la invención se extienden al procedimiento de envió de la trama de Intercambio de Etiqueta de protocolo Múltiple (MPLS) existente en un nodo de MPLS, en donde un descriptor de contexto se define para cada trama recibida en una conexión terminada en dicho nodo y en donde este descriptor de contexto de proveerse junto con la trama a una función correspondiente (v.gr., operaciones, Administración y Mantenimiento, IAM) si es necesario. El descriptor del contexto se construye con base en atributos clave que caracterizan la conexión terminada, sobre la cual se recibe la trama y dirige un punto final de función particular (Puntos Finales de Mantenimiento (MEP) , Pete Selector de un caso de protección etc.) de una función correspondiente (OAM, protección, etc.). Como tal, un descriptor de contexto contendrá algún atributo clave que caracteriza (es decir, identifica) la conexión terminada, por ejemplo, la conexión sobre la cual se recibe una trama.

En una modalidad, un nodo de Intercambio de Etiqueta de Múltiples Protocolos (MPLS) se dirige para revisar no solo la primera sino la segunda etiqueta y no tirar la primera etiqueta (y el espacio de la etiqueta si es relevante) Cuando la segunda etiqueta es la Etiqueta de Canal de Asociación Genérica (GAL) . De esta forma, el contexto original del paquete se mantiene (es decir, la información que se refiere a la conexión sobre la cual se recibe el paquete) y se puede usar para desmultiplexar el MEP correspondiente. Luego los identificadores dentro de la carga útil de OAM se pueden usar para verificación de la conectividad.

Por ejemplo, en una modalidad de la invención provee un método en un nodo de una red de telecomunicaciones de Intercambio de etiqueta de protocolo (MPLS). El método comprende los pasos de recibir una trama de MPLS, la trama de MPLS teniendo una pila de etiquetas que comprende una o más etiquetas y que determina si la trama ha alcanzado su nodo de terminación. Si la trama ha alcanzado su nodo de terminación, una segunda etiqueta en la pila de etiqueta se revisa para determinar si la segunda etiqueta se refiere a una Etiqueta de Canal Asociado Genérico (GAL) . Si es asi, el descriptor del contexto se adquiere para usarse durante proceso adicional de la trama y la trama se dirige al proceso de Encabezado de Canal Asociado Genérico (G-ACH) .

En otra modalidad, la expiración de valor de Tiempo de Vida (TTL) se utiliza. En la presente la distancia del salto de MEP de destino se conoce por el MEP de fuente ya sea por configuración o medición. El valor de TTL de las tramas consecuentes que contienen los mensajes de OAM serán establecidas consecuentemente. Por lo tanto, estas tramas sufrirán expiración de TTL en el nodo de destino que resulta del envió de las tramas completa que contienen los paquetes de OAM a la función de control del nodo de destino. Luego, el contexto completo de la trama, incluyendo las etiquetas está presente y se puede usar para dirigir el MEP correspondiente. En aún otra modalidad los espacios de etiquetas dedicados se especifican por conexiones monitoreadas y los espacios de las etiquetas se usan para dirigir MEP.

De acuerdo con otra modalidad de la invención, se provee un nodo de una red de telecomunicaciones de Cambio de Etiquetas de Múltiples Protocolos (MPLS) . El nodo comprende medios de recepción para recibir una trama de MPLS, la trama de MPLS teniendo una pila de etiquetas que comprende una o más etiquetas. El nodo se configura para determinar si la trama ha alcanzado su nodo de terminación y si es asi, revisa una segunda etiqueta en la pila de etiquetas para determinar si la segunda etiqueta se refiere a una Etiqueta de Canal Asociado Genérico (GAL) . Si es asi, el nodo se configura para adquirir un descriptor de contexto para usarse durante el proceso adicional de la trama y enrutar la trama para proceso de Encabezado de Canal Asociado Genérico (G-ACH) .

Breve Descripción de los Dibujos Para un mejor entendimiento de la presente invención y muestran más claramente cómo puede ser lelvardo a cabo, se hará referencia ahora, a menara de jemplo, a los siguientes dibujos, en los cuales: La Figura 1 muestra una trama de paquetes de MPLS; La Figura 2 ilustra parte de una red de intercambio de paquetes; La Figura 3 es una gráfica de flujo que describe los pasos de un método de acuerdo con una modalidad de la invención; La Figura 4 es una gráfica de flujo que describe los pasos de un método de acuerdo con otra modalidad de la invención; La Figura 5 es una gráfica de flujo que describe los pasos de un método de acuerdo con otra modalidad de la invención ; La Figura 6 es una gráfica de flujo que describe los pasos de un método de acuerdo con otra modalidad de la invención; La Figura 7 es una gráfica de flujo que describe los pasos de un método de acuerdo con otra modalidad de la invención; y La Figura 8 es un diagrama esquemático de un nodo de acuerdo con las modalidades de la invención.

Descripción Detallada . Las siguientes modalidades serán descritas en el contexto de llevar a cabo las funciones de Operaciones, Administración y Mantenimiento (OAM) en un nodo y el uso de identificadores en la carga útil de OAM para permitir una verificación de conexión que será lelvado a cabo. Sin embargo, se nota que la invención se puede aplcir más generalmente que solo llevando a cabo funciones de OAM y tamén más generalmente pueden solo verificar la conexión sobre la cual se recibe una trama.

La Figura 2 ilustra parte de una red de cambio de paquetes 10.

Un nodo de ingreso capaz de MPLS 12, que actúa como un Enrutador de Orilla de Etiqueta ( "LSR" ) , envía un flujo de cambio de etiquetas de un tráfico de paquetes, v.gr., tráfico de Protocolo de Internet (IP), a través de nodos intermedios 14, 16, cada acción que tiene un enrutador de cambio de etiquetas ("LSR") a un nodo de egreso 18.

Cada flujo de tráfico entre los nodos sucesivos 12, 14, 16, 18 se etiqueta, o marcan, con una etiqueta única que identifica cada flujo entre dos nodos adyacentes como un miembro de una "clase de equivalencia de avance" ("FEC") particular diriqida a un LST particular, sucesivo "corriente abajo". La etiqueta forma parte de una "pila de etiquetas", que puede tener una o más etiquetas. Cada LSR corriente abajo recibe el tráfico y lee la primera etiqueta en la pila de etiquetas. Luego hace coincidir la etiqueta con una entrada en su tabla de Mapa de Etiquetas Entrantes (ILM, por sus siglas en inglés) que indican cual NHLFE será aplicado y lee la entrada referida de la tablea de Entrada de Envío de Etiquetas de Siguiente Salto (NHLFFE) y sigue las siguientes direcciones asociadas en la tabla con dicha entrada. La tabla NHLFE por lo tanto describe cómo tratar la trama (por ejemplo, avanzar, remover la etiqueta externa, enviar al nodo Y, etc.) y para un nodo LSR intermedio 14, 16 comprenderán por lo menos el siguiente salto del paquete y una operación que será llevada a cabo en la pila de etiquetas.

Los nodos 12, 14, 16, 18 pueden definir un túnel de Trayectoria de Cabios de Etiquetas (LSP) . En dicho escenario, la primera etiqueta en cada paquete enviada entre el nodo de ingreso 12 y el nodo de egreso 18 es una etiqueta de túnel que identifica la trayectoria del túnel 12 ? 14 ? 16 ? 18. En el nodo de egreso 18, de acuerdo con la técnica anterior, la etiqueta del túnel salta desde la pila de etiquetas (es decir, removerse de la pila de etiquetas) y el paquete se envía al siguiente nodo de destino con base en la segunda etiqueta o basada en el contenido de un paquete si no existe dicha etiqueta secundaria en la pila de etiquetas. En el caos en donde la segunda etiqueta es una Etiqueta de Canal de Asociación Genérica (GAL) , el paquete puede enviarse a una función de proceso de Encabezado de Canal Asociado Genérico (G-ACH) del nodo 18 y en el ejemplo de una función de OAM desde ahí a un Punto Extremo de Mantenimiento (MEP) . Sin embargo, se pierde la etiqueta del túnel.

De acuerdo con la invención el procedimiento de envío de trama de Cambio de Etiqueta de Múltiples Protocolos (MPLS) se extiende en un nodo de MPPLS, por lo que se define un conecto para cada trama recibida en una conexión terminada en dicho nodo y en donde este contexto se provee junto con la trama a una función o correspondiente (v.gr., OAM) si es necesario. El contexto se construye con base en los atributos clave que caracterizan la conexión terminada, sobre la cual se recibe la trama y dirige un punto final de función particular (por ejemplo, los Puntos finales de Mantenimiento (MEP), Puente de Selector de un caso de protección, etc.) de una función correspondiente (OAM, protección, etc.).

En una primera modalidad, un nodo de MPLS se dirige para revisar no solo la primera sino también la segunda etiqueta y no deja caer la primera etiqueta (y la separación de etiqueta si es relevante) cuando la segunda etiqueta es la Etiqueta de Canal de Asociación Genérica (GAL) . De esta manera, el contexto original del paquete se mantiene (es decir, la información que se refiere a la conexión sobre la cual se recibe el paquete) y se puede usar para desmultiplexar el MEP correspondiente. Luego los identificadores dentro de la carga útil de OAM pueden usarse para verificación de la conectividad . Se observa que la separación de la etiqueta se considera relevante u se usan espacios específicos de etiquetas o por espacios de etiquetas de interfaces, en cuyo caso el valor de la etiqueta solo no puede identificar completamente la conexión.

La Figura 3 muestra los pasos realizados por la invención de acuerdo con una modalidad de la invención. En el paso 201 un nodo recibe una trama de MPLS . La trama luego se revisa en el paso 203 para determinar si el nodo es el punto final del túnel de LSP, es decir, el nodo de ingreso. Por ejemplo, en una modalidad (descrita en mayor detalle en la Figura 4 siguiente) , la primera etiqueta de la trama MPLS se revisa en el paso 203, la primera etiqueta indica que el nodo es el punto final del túnel de LSP. De acuerdo con otra modalidad (descrita en mayor detalle en la siguiente Figura 5) , la información de Tiempo de Vida (TTL) recibida en la trama de MPLS se usa para determinar si el nodo es el punto final del túnel de LSP.

Si se determina en el paso 203 que el nodo no es el punto final del túnel de LSP, entonces el proceso de la trama continua en la forma normal en el paso 211, por ejemplo, revisando el siguiente salto y enviando consecuentemente la trama .

Si se determina en el paso 203 que el nodo es el punto final del túnel de LSP, entonces la segunda etiqueta de la trama de MPLS también se revisa, paso 205. Se determina si la segunda etiqueta es un GAL, paso 207.

Si se determina en el paso 207 que la segunda etiqueta no es un GAL, entonces la trama MPLS se maneja en una forma convencional, por lo que salta la primera etiqueta, paso 209 y el proceso de la trama continua en la forma normal en el paso 211, por ejemplo, revisando el siguiente salto y enviando consecuentemente la trama.

Sin embarco, si se determina en el paso 207 que la segunda etiqueta es un GAL, entonces en el paso 213, un descriptor de contexto se adquiere con base en los atributos del proceso de envió. Por ejemplo, el descriptor de contexto puede formarse usando la etiqueta del tune (es decir, la primera etiqueta) y el espacio de la etiqueta, o el uso del valor clave de NHLFE. Una vez que se ha adquirido el descriptor del contexto la trama de MPLS puede procesarse entonces en una forma convencional, enviando la trama a una capa superior en el paso 215, por ejemplo, enviando la trama a una operación de desmultiplexión de G-ACH junto con el descriptor del contexto adquirido en el paso 213. El descriptor del contexto adquirido en el paso 213 se retiene y puede usarse para el proceso futuro, tal como Verificación de Conexión (CV) , Revisión de Continuidad (CC) u otras funciones en donde la identidad del origen de la trama puede requerirse .

Como se mencionó antes, un método pa adquirir un descriptor de contexto es guardar una primera etiqueta que de alguna manera deberá perderse durante una operación de salto llevada a cabo en la primer etiqueta. La Figura 4 muestra los pasos realizados en dicha modalidad de la invención. En el paso 301 un nodo recibe una trama de MPLS. La primera etiqueta de la trama de MPLS luego se revisa, paso 203. En el paso 304, se determina si la primera etiqueta indica que el nodo es un punto final, por ejemplo, determinado que se lleva a cabo una operación de POP. Si se determina en el paso 304 que el nodo no es un punto final en el túnel de LSP, el proceso de la trama de MPLS continua en una forma convencional en el paso 313, por ejemplo, revisando el siguiente salto y enviando consecuentemente la trama .

Si la primera etiqueta indica que el nodo es un punto final, luego de acuerdo con esta modalidad la primera etiqueta se guarda, paso 305. La segunda etiqueta de la trama de MPLS se revisa luego, paso 307, y se determina si la segunda etiqueta es un GAL, paso 309.

Si se determina en el paso 309 que la segunda etiqueta no es un GAL, entonces en el paso 311 salta en la primera etiqueta, lo cual da como resultado en la primera etiqueta que se retira. El proceso de la trama de MPLS continua en una forma convencional en el paso 313, por ejemplo, revisando' que el siguiente salto y enviando consecuentemente la trama.

Sin embargo, si se determina en el paso 309 que la siguiente etiqueta es un GAL, la trama de MPLS puede procesarse entonces en una forma convencional, por ejemplo, desmultiplexando GAL y G-ACH, paso 317 y luego enviando la trama MPLS a una capa superior, paso 319, pero sin tirar la primera etiqueta que se guardó previamente en el paso 305. Por lo tanto, se apreciará que al guardar la primera etiqueta en el paso 305 habilita el contexto de la trama entrante que será adquirida y retenida para el proceso futuro, tal como verificando una conexión o revisión de continuidad. La primera etiqueta puede guardarse al almacenar una copia del valor de la etiqueta en una memoria especifica que es diferente de la pila de etiquetas. Alternativamente, la primera etiqueta puede guardarse en una memoria que se provee para guardar una historia de la pila de etiquetas, de manera que la historia por lo tanto provee el contexto deseado. Se deberá observar que es suficiente guardar solo la última etiqueta procesada en la historia para este fin.

Aunque la modalidad de la figura 4 muestra la primera etiqueta que se guarda antes de la segunda etiqueta que se revisa, se observa que la primera etiqueta puede guardarse en otras instancias, o en otra forma, siempre que se guarde antes de que salte la primera etiqueta y siempre que sea retenida después de que ha saltado la primera etiqueta .

En un ejemplo de una aplicación, las modalidades descritas en las figuras 3 y 4 pueden implicar la desmultiplexión de una carga útil de OAM y luego dirigir la trama a un MEP deseado. Sin embargo se apreciará que la invención también puede aplicarse a otras aplicaciones en donde el contexto de la trama entrante se requiere, el contexto estando basado en atributos clave que caracterizan la conexión terminada sobre la cual se recibe la trama.

La Figura 5 es una gráfica de flujo que muestra una aplicación más detallada de la invención en un nodo de egreso 18 de acuerdo con una modalidad de la invención. La modalidad muestra como una operación de plano de datos de MPLS genérica (por ejemplo, RFC de Fuerza de Tarea de Ingeniería de internet (IETF) 3031) puede extenderse.

En el paso 401 se recibe una trama de MPLS. La modalidad se muestra teniendo un mecanismo de Tiempo de Vida (TTL) que opera junto con la invención. El mecanismo TTL se provee en un sistema MPLS para indicar cuantos saltos deberá realizar una trama antes de alcanzar su destino deseado. Se puede usar, por ejemplo, para asegurar que un bucle mal configurado (v.gr., LSP conforma de anillo) no da como resultado una trama que se envía siempre. Como tal, en el paso 403 se determina primero si un valor trama de Tiempo de Vid a ha expirado. Si es así, la trama se envía a un módulo de expiración de TTL, paso 405, y se manea en una forma convencional para dichas tramas expiradas. Se observa que el uso de un mecanismo de TTL no es esencial para la modalidad de la Figura 5.

Suponiendo que la trama recibida no ha expirado, el espacio de la etiqueta se identifica en el paso 407. Este paso puede incluir identificar la tabla del Mapa de Etiqueta entrante (ILM) apropiado para manejar dicha trama particular. Una tabla de ILM se define por espacio de etiqueta. Con base en la configuración de nodos un valor de espacio de etiqueta se asigna a cada trama recibida, lo cual permite que se seleccione una tabla de ILM. Por ejemplo, un espacio de etiqueta particular puede definirse para una interfaz particular un segundo espacio de etiqueta para un grupo de otras interfaces, dando asi dos tablas de ILM.

En seguida, en el paso 409 el valor de etiqueta de la primera etiqueta en la pila de etiquetas se revisa. Si la primera etiqueta no es un GAL (por ejemplo debido a que GAL es la segunda etiqueta en la pila de etiquetas) entonces el proceso se mueva al paso 411. En el paso 411 la clave NHLFE se encuentra que usa la primera etiqueta, es decir, la etiqueta más externa. La clave NHFLE identifica un NHFLE especifico en la tabla NHLFE. La clave NHFLE puede ser, por ejemplo, un número de hileras. En el paso 413 el código de operación POP, el código de operación (por ejemplo un intercambiador, empuja una nueva etiqueta, etc.) luego el proceso se mueve al paso 415. El siguiente salto se revisa, paso 417. Si el siguiente salto se indica por ser al mismo nodo, entonces el proceso regresa al paso 403 en donde el procedimiento empieza de nuevo. Si se determina en el paso 417 que el siguiente salto se indica que está en otro nodo, entonces la trama se maneja de acuerdo con la operación de avance del paquete RFC 3031, paso 418, y la trama se envía consecuentemente, paso 421.

Si se determina en el paso 413 que el código de operación NHFLE es un código de operación POP, entonces en el paso 423 se determina si se establece un bit de estado de CONEXIÓN MONITOREADA (CON_ ON) y la segunda etiqueta en la pila de etiquetas es un GAL. Se observa que el bit (CON_MON) es una característica opcional que se puede proveer para indicar que una revisión de conectividad puede requerirse en el mismo punto durante el proceso subsiguiente de la trama, de manera que el contexto (v.gr., primera etiqueta) necesita ser guardada) . Por o tanto el bit de MON_CON actúa como una indicación para "elegir" la segunda etiqueta para determinar si la segunda etiqueta es un GAL. El bit de estado de CON_MON se localiza en NHLFE (y puede ser considerado como un atributo de una entrada en la tabla de MHLFE) .

Si se determina en el paso 423 que el bit CON_MON no se establece o la segunda etiqueta no es un GAL, entonces el proceso pasa al paso 425, en donde la primera etiqueta salta (por ejemplo como por RFC 3031) y entonces el proceso se mueve al paso 417 en donde se revisa el siguiente salto. Se observa que en un sistema convencional del proceso simplemente puede moverse al paso 417 en donde el proceso inicia de nuevo. Si se determina en el paso 417 que el siguiente salto se indica por estar en el otro nodo, entonces la trama se maneja de acuerdo con el paquete RFC 3031 que avanza la operación, paso 419, y la trama luego se envía consecuentemente, paso 421.

Regresando al paso 423, si se determina que el bit CON_MON se establece y la segunda etiqueta es un GAL, entonces el proceso se mueve al paso 427 en donde GAL y G-ACH se desmultiplexan (por ejemplo, de acuerdo con RFC 5586) y la trama luego se envía a una capa superior 429. Como tal, la primera etiqueta no se resalta, lo cual significa que la primera etiqueta aún estará disponible para el sistema para uso futuro, por ejemplo, verificando una conexión, revisando continuamente, etc. La primera etiqueta puede retenerse en la memoria en donde está guardada mientras espera a ser resaltada en el paso 425, o guardada en otra parte para proceso futuro. Si se nota que la modalidad descrita antes evita una búsqueda adicional para identificar el GAL como una etiqueta superior de la pila, lo cual normalmente puede ser requerido .

Cuando se usa en una aplicación que se refiere a cargas útiles de OA , la desmultiplexión y envío de pasos 427, 429 pueden comprender desmultiplexar una carga útil de OAM y enviar una trama a un MEP.

Por lo tanto se apreciará a partir de lo anterior que, si la primera etiqueta y el espacio de la etiqueta están disponibles en el paso 423, la primera etiqueta y el espacio de la etiqueta pueden pasar como parte del descriptor del contexto a la función de proceso de G-ACH del paso 427. Por lo tanto puede haber situaciones en las cuales la primera etiqueta o el espacio de la etiqueta pueden perderse por el tiempo en que el proceso llega al paso 423. Sin embargo, si la primera etiqueta o el espacio de la etiqueta ya se han perdido, NHLFE aún puede proveer el contexto, pero en este último caso el NHLFE deberá ser dedicado para las conexiones, es decir, un NHLFE no deberá codificar el comportamiento de envío de más de un punto final de conexión. Dichas restricciones están disponibles en MPLS-TP para otros fines.

Aunque no se describe explícitamente en la Figura 5, el método también puede comprender el paso de revisar una etiqueta entrante para determinar si la primera etiqueta no está en la parte inferior de la pila de etiquetas. Esto puede proveerse como una revisión inicial, ahorrando así el proceso innecesario .

Se apreciará que la modalidad descrita en la figura 4 lleva a cabo una forma de "revisión de etiqueta doble", es decir, revisión de la primera etiqueta y luego revisión de la segunda etiqueta. De acuerdo con una opción de realización específica de implementación, en lugar de la revisión de etiqueta doble el método puede comprender los pasos de mantener el comportamiento de MPLS original y guardar la primera etiqueta removida y el espacio de la etiqueta, incorporando así un método similar al de la figura 4. En otras palabras, la primera etiqueta se guarda hasta el momento en que se ha revisado la segunda etiqueta luego se tira la primera etiqueta si no es necesario, pero mantiene la primera etiqueta si se necesita para proceso futuro. Por ejemplo, este contexto guardado puede dejarse caer después de la segunda etiqueta y remover la segunda etiqueta (GAL) a menos que se encuentre un OAM CV G-ACH. Una solución alternativa a esto de tirar la etiqueta es revisar no solo la primera y segunda etiqueta, sino también OAM G-ACH posibles y mantener la primera etiqueta y contexto solo si se ha encontrado .

De esta manera, el contexto original del paquete está disponible para la función del proceso de ACH y puede usarse para dirigir el MEP correspondiente. Los identificadores dentro de la carga útil de OAM entonces se pueden usar para verificar la conectividad o revista la continuidad .

Como se puede observar de lo anterior, la modalidad de la Figura 5 puede tener una característica opcional adicional, por lo que una etiqueta adicional en la forma de una etiqueta de "CONEXIÓN_MO ITOREADA" se provee en NHLFE correspondiente, lo cual indica que una revisión de la segunda etiqueta es necesaria. Dicha indicación explícita tiene la ventaja de incrementar el desempeño del sistema dado que lleva a cabo la revisión de la etiqueta secundaria solo si es necesario, en lugar de para cada caso.

Se observa que durante un procedimiento de establecimiento la etiqueta puede comunicarse explícitamente de la fuente al nodo de destino (v.gr., un TLV opcional o un nuevo bit puede usarse en el mensaje de RSVP-Trayectoria cuando se establece el LSP) o puede establecerse con base en las deducciones de los otros parámetros recibidos (v.gr., la configuración de OAM) .

Se apreciará que la invención como se describió en la modalidad de la figura 5 tiene la ventaja de mantener la primera etiquete, es decir, descriptor del contexto, disponible para procesos futuros, por ejemplo, para llevar a cabo una verificación de conexión o revisión de continuidad.

La Figura 6 es una gráfica de flujo que muestra un método en el nodo de egreso 18 de acuerdo con una modalidad adicional de la invención. Como con la Figura 5, esta modalidad muestra la forma en que una operación de plano de datos de MPLS genérico (r ejemplo, RFC de Fuerza de Tareas de Ingeniería de Internet (IETF) 3031) puede ser extendido. La modalidad de la Figura 6 provee un nuevo mecanismo para identificar un canal asociado reusando los mecanismos de expiración de TTL definidos para MPLS .

En el paso 501 se recibe una trama de MPLS. Como con la figura 5 la modalidad de la figura 6 se muestra teniendo una operación de mecanismos de Tiempo de Vida (TTL) . El mecanismo TTL se provee en un sistema MPLS para indicar la forma en que se deben llevar a cabo muchos saltos de una trama antes de alcanzar su destino deseado. Suponiendo que un MEP de fuente conoce la distancia del salto al MEP de destino, el nodo de fuente establece el campo de TTL en la etiqueta que identifica LSP de manera que el contenido de saltos para cualquier trama que contiene mensajes de G-ACH. En el nodo de destino ocurrirá la expiración de TTL y todo el contexto está disponible para la función de proceso. Esto se describe en detalle más adelante.

En el paso 503 primero se determina si un valor de Tiempo de Vida (TTL) ha alcanzado un valor predeterminado, para el ejemplo 1, indicando que la trama ha expirado. Si es asi, el proceso de mueve al paso 525, en donde se determina si el GAL es la siguiente etiqueta (segunda) . Si GAL no es la siguiente (segunda) etiqueta, el proceso se mueve al paso 527., por lo que la trama luego se envía a un módulo de expiración TTL y se maneja en una forma convencional para dichas tramas estiradas.

Si se determina en el paso 525 que GAL es la siguiente etiqueta (segunda) , entonces el proceso se mueve al paso 521, por lo que GAL y G-ACH se desmultiplexan (por ejemplo, de acuerdo con RFC 5586) y la trama luego se envía a una capa superior, paso 523. En la función de proceso de ACH del nodo de destino el contexto completo del paquete, incluyendo las etiquetas están presentes y se pueden usar para dirigir el MEP correspondiente. Esto se debe a que GAL y G-ACH se desmultiplexan sin una operación de POP que se lleva a cabo en la etiqueta más externa, lo cual puede dar como resultado que se pierda el contexto. Luego los identificadores contenidos dentro de la carga útil de OAM pueden usarse, por ejemplo, para verificación de la conectividad do revisión continua.

Si se determina en el paso 503 que la trama recibid ano ha expirado, indicando que el nodo no es el nodo de egreso, entonces el mecanismo de MPLS opera en una forma convencional, por lo que el espacio de la etiqueta se identifica en el paso 505. Este paso puede incluir identificar la tabla de Mapa de Etiqueta Entrante (ILM) apropiada para manejar la trama particular.

En seguida, en el paso 507 se revisa el primer valor de la etiqueta. Si la primera etiqueta no es un GAL (por ejemplo debido a que GAL es la siguiente (segunda) etiqueta en la pila de etiquetas) entonces el proceso de mueve al paso 509. En el paso 509 la clave de NHLFE se encuentra usando la etiqueta externa. La clave de NHFLE identifica un NHFLE especifico en la tabla de NHLFE. La clave de NHFLE puede ser por ejemplo, un número de hilera. En el paso 511 el código de operación de NHLFE (es decir, recuperado por la clave NHFLE en el paso 509) se revisa para determinar la naturaleza del código de operación de NHFLE.

Si se determina en el paso 511 que el código de operación de NHFLE es cualquier otro que un código de operación de POP, código de operación (por ejemplo, un intercambio de empuje de la nueva etiqueta, etc.) luego el proceso se cambia al paso 513. El siguiente salto se revisa luego, paso 515. Si se indica que el siguiente salto está en el mismo modo, el proceso regresa al paso 503 en donde el procedimiento empieza de nuevo. Si se determina en el paso 515 que el siguiente salto se indica que está en otro nodo, entonces se maneja la trama., por ejemplo, de acuerdo con el paquete de RFC 3031 que avanza la operación, paso 517, y la trama luego se envía consecuentemente, paso 519.

Si se determina en el paso 511 que el código de operaciones de NHFLE es un código de operaciones de POP, entonces el proceso pasa la paso 522 en donde salta la primera etiqueta (por ejemplo para RFC 3031) y el proceso se mueve al paso 515 en donde el siguiente salto se revisa. Se observa que el paso 522 puede incorporarse como parte del paso 513.

El proceso del paso 515 procede como se describió antes. Es decir, si se determina en el paso 515 que el siguiente salto se indica que está en el mismo nodo, el proceso regresa al paso 503 en donde el procedimiento empieza de nuevo. Si se determina en el paso 515 que el siguiente salto se indica que está en otro nodo, entonces la trama se maneja de acuerdo con el paquete RFC 3031 que avanza la operación, paso 517, y la trama luego se envía consecuentemente, paso 519.

Por lo tanto, se apreciará a partir de lo anterior que la función del proceso de expiración de TTL se extiende proporcionando funciones adicionales. Primero, revisa la segunda etiqueta en la pila si hay alguna y si la segunda etiqueta es GAL la trama pasa a la función de proceso de ACH con el contexto completo.

También se puede observar a partir de la figura 6 que, si no hay explicación de TTL, entonces la primera etiqueta se remueve y continua el avance con base en la segunda etiqueta. Esta segunda etiqueta puede ser v.gr., GAL, lo cual significa que el nodo local deberá procesar el paquete. Luego después de remover la segunda etiqueta, un G-ACH se encuentra con una carga útil de GA . Sin embargo, en este paso la primera etiqueta y el contenido original se pierden y no se pueden usar para verificación de conexión. Sin embargo, para revisar continuamente esta operación de legalidad aún puede usarse) .

Hay varias alternativas que se pueden usar para determinar el conteo de saltos entre el EP de fuente y destino .

De acuerdo con una modalidad el procedimiento de establecimiento de conexión puede determinar el conteo de saltos y proveer información a los nodos de fuente y destino. La implementación depende de si se realiza el establecimiento de conexión en formas centralizada (plano de manejo de paso) o distribuida (a través del plano de control).

En el establecimiento de conexión centralizado la entidad que controla el proceso de establecimiento tiene una vista completa de la conexión que será establecida. Por lo tanto, puede calcular la distancia de salto basada en el conocimiento local y enviada junto con otros parámetros de configuración al punto final MEP.

En el establecimiento de conexión distribuida el protocolo el plano de control deberá proveer un método para determinar el conteo de saltos. Si se usa GMPLS como un plano de control para MPLS-TP el protocolo de provisión de conexión de GMPLS (RSVP-TE) deberá calcular la distancia del salto. Una opción es aplicar la capacidad de registro de ruta de RSVP-TE. Una segunda opción es agregar un nuevo contador de saltos a los mensajes de señalamiento de RSVP-TE que calculan el número de satos físicos o la conexión de MPLS-TP.

Después de establecer la conexión (pero antes de verificación de conectividad) el MEP de fuente envía una trama de medición en donde TTL de este mensaje se envía a un valor bien conocido, v.gr., 250. El nodo de destino puede calcular su distancia de salto del nodo de fuente por la extracción del valor de TTL real en el mensaje de OAM del valor bien conocido. Luego el MEP de destino puede notificar el MEP de fuente sobre el resultado.

Las tramas de CC ya existentes pueden usarse para este fin. Usando estas tramas el MEP de destino conoce su distancia desde el MEP de fuente. Sin embargo, también se puede usar un nuevo Mensaje de Medición de Distancia; en este caso este mensaje indica una medición y se genera un mensaje de contestación en respuesta al mismo desde el MEP de destino. Se pueden usar métodos alternativos enviando este valor de nuevo al MEP de fuente. Una opción es extender el mensaje de CC que se responde por el MEP de destino al MEP de fuente con un campo opcional que tiene este valor. De acuerdo con otra opción, el valor se envía de nuevo vía un mensaje de Respuesta de medición de Distancia.

Se observa que, en el caso de usar mensajes de CC en lugar de un Mensaje de Medición de Distancia, el MEP de destino deberá informarse acerca de cuándo enviar la distancia de nuevo a la fuente. Esto puede lograrse usando una de las siguientes opciones. Una opción es enviar de nuevo solo una vez, después de recibir el primer mensaje de CC . La segunda opción es enviar la distancia medida de nuevo continuamente a menos que se notifique de la fuente que pare, esta notificación puede ser el primer mensaje de CV o un bit adicional en el mensaje de CC. Se apreciará que las opciones mencionadas antes para medir la distancia de salto asumen que la trayectoria es correcta o estética hasta el momento en que se haya completado la medición.

La Figura 7 es una gráfica de flujo que muestra un método en el nodo de egreso 18 de acuerdo con otra modalidad de la invención. Como con las Figuras 5 y 6, esta modalidad muestra cómo se puede extender una operación de plano de datos de MPLS genérico (por ejemplo, RFC 3031 de Fuerza de Tarea de Ingeniería de Internet (IETF)). La modalidad de la figura 7 especifica los espacios de etiquetas dedicaos por conexiones monitoreadas y los espacios de la etiqueta se usan para dirigir MEPS. Por lo tanto, de acuerdo con esta modalidad el espacio de la etiqueta, al cual pertenece la conexión entrante, identifica el contexto para dirigir MEP. El procedimiento de RFC 3031, por ejemplo, define por plataforma y por interfaz los espacios de la etiqueta, mientras que RFC 5331 se usa para agregar los "espacios de etiqueta específicos de contexto".

Un espacio de etiqueta puede ser imaginado como un identificador numérico que es significativo solo dentro de un nodo. Un identificador de espacio de etiqueta específico se asigna a un valor de etiqueta recibido en una interfaz específica. Esto significa que cada trama, que se recibe en dicha interfaz y tiene la primera etiqueta definida, pertenece al espacio de etiqueta específica para el contexto. Luego, puede recortarse y una búsqueda llevada a cabo en la segunda etiqueta, por ejemplo un GAL. En este paso el identificador de espacio de etiqueta aún estará disponible y puede proveerse a la capa de desmultiplexión de G-ACH junto con la trama. Si el identificador de espacio de etiqueta no está disponible, entonces se puede usar la clave NHLFE con ciertas restricciones.

Esta modalidad define por lo tanto un espacio de etiqueta dedicado para una etiqueta entrante especifica y especifica tablas de mapeo de etiqueta dedicad (ILM) para la etiqueta. Una explicación más detallada se da más adelante.

En el paso 601 se recibe una trama de MPLS. Como con las Figuras 5 y 6 la modalidad de la Figura 7 se muestra teniendo una operación de mecanismo de Tiempo de Vida (TTL) . En el paso 603 se determina si un valor de Tiempo de Vida (TTL) ha alcanzado un valor predeterminado, para ejemplo 1, indicando que la trama ha expirado. Si es asi, el proceso se mueve al paso 627, por lo que la trama se envía luego a un módulo de expiración de TTL y manejado en una forma convencional para dichas tramas expiradas.

Si se determina en el paso 603 que la trama recibid ano ha expirado, se identifica el espacio de la etiqueta en el paso 605. Este paso puede incluir identificar la tabla de Mapa de Etiqueta Entrante (ILM) apropiada para manejar la trama particular. Un espacio de etiqueta define el alcance de un valor de etiqueta, es decir, la singularidad de los valores de etiqueta se aseguran solo en un espacio de etiqueta. En teoría el espacio de la etiqueta y el valor de la etiqueta juntos definen la operación que será llevada a cabo en la trama recibida. Un espacio de etiqueta puede unirse a un nodo, a una interfaz del nodo, o a un punto final el túnel (es decir, con el valor de etiqueta que identifica el túnel ) .

En la primera etiqueta en la pila define el espacio de la etiqueta, en seguida, en el paso 607 el valor de la siguiente (segunda) etiqueta se revisa. En otras palabas, en lugar de revisar el valor de la etiqueta de la primera etiqueta lo cual podría tomar lugar normalmente en esta etapa de la operación de MPLS, el valor de la etiqueta de la siguiente etiqueta (es decir, la segunda etiqueta) se revisa en su lugar. Si la siguiente (segunda) etiqueta no es un GAL luego el proceso se mueve al paso 609. En el paso 609 la clave de NHLFE se encuentra usando esta siguiente etiqueta (segunda) . La tecla NHFLE identifica un NHFLE específica en la tabla NHLFE. La tecla NHFLE puede ser, por ejemplo, un número de hilera. En el paso 611 el código de operación NHLFE (es decir, recuperado por la tecla NHFLE en el paso 609) se revisa para determinar la naturaleza del código de operación NHFLE .

Si se determina en el paso 611 que el código de operaciones NHFLE es cualquiera otro que un código de operaciones POP, el código de operaciones (por ejemplo una nueva etiqueta de empuje de intercambio etc.), entonces el proceso se mueve al paso 613. El siguiente salto se revisa luego, paso 615 si el siguiente salto se indica por estar en el mismo nodo, es decir, el nodo actual, luego el proceso regresa al paso 603 en donde el procedimiento inicia de nuevo. Si se determina en el paso 615 que el siguiente salto está indicado por estar en otro nodo, luego la trama se maneja de acuerdo con RFC 3031 la operación de envió de paquetes, paso 617, y la trama luego se envía consecuentemente, paso 619.

Se determina en el paso 611 que el código de operaciones NHFLE es un código de operaciones POP luego el proceso pasa al paso 621, en donde la primera etiqueta salta (por ejemplo como para RFC 3031) y el proceso luego se mueve al paso 615 en donde el siguiente salto se revisa. Se observa que el paso 621 puede incorporarse como parte del paso 613.

El proceso del paso 615 luego procede como se describió antes. Es decir, si se determina en el paso 615 que el siguiente salto se indica por estar en el mismo nodo, luego el proceso regresa al paso 603 en donde inicia de nuevo el proceso. Si se determina en el paso 615 que el siguiente salto se indica por estar en otro nodo, luego la trama se maneja de acuerdo con la operación de envío de paquetes RFC 3031, paso 617, y la trama luego se envía consecuentemente, paso 619.

En la modalidad de a Figura 7, aunque el valor exacto de la primera etiqueta se pierde, la primera etiqueta define la separación de la etiqueta y el espacio de la etiqueta identifica inambiguamente la propia conexión. Como tal, el espacio de la etiqueta puede usarse para definir el descriptor de contextos. En otras palabras, la primera etiqueta describe el contexto y este contexto de usa para dirigir MEP. Por lo tanto, la primera etiqueta dirige MEP y la segunda etiqueta solo es un GAL y la segunda etiqueta indica que la trama se puede enviar a GAL y desmultiplexar G-ACH.

A partir de lo anterior se apreciará que la modalidad de la Figura 7 resulta el procedimiento de RFC 5331, por ejemplo, (derivado de RFC 3031) para proveer un espacio de etiqueta dedicado (y una tabla de ILM separada) para ser asignada para la conexión monitoreada. El nodo de egreso puede determinar cuál espacio de etiqueta usar con base en los criterios listados más adelante. Si El caos del espacio de etiqueta se une a un nodo este espacio de etiqueta por "omisión" será asignada cualquier trama recibida. Si la distancia de espacio de etiqueta se une a una interfaz (puerto) , entonces el nodo asignará este espacio de etiqueta a cualquier trama que se recibe en la interfaz/puerto . Si la distancia del espacio de la etiqueta se une a un punto final del túnel, el nodo asignara este espacio de etiqueta a cualquier trama recibida en el túnel. Las tres clases de espacio de etiqueta pueden asignarse como por nodo, por interfaz y por espacios de etiquetas específicas de contexto.

Una tabla de ILM dedicada de conexión puede contener : •Entradas de etiquetas que se refieren a conexiones de clientes que se tunelizan a través de la conexión monitoreada y se desmultiplexan en el nodo.

• Las entradas de etiquetas refiriéndose a flujos de Pseudo-Cables encapsulados .

• Entrada de etiqueta que se refiere a GAL (valor de etiqueta 13) si un canal asociado se definen para la conexión monitoreada.

• Entrada de etiquetas que se refiere a la etiqueta Nula Explícita (valor 0) para definir el tratamiento para el flujo de cliente no encapsulado.

Se observa que la entrada en ILM puede denominarse como NHLFE. Luego, un NHLFE dirigido por la entrada de etiquetas para GAL de dicho espacio de etiqueta de contexto puede codificar información del contexto. De esta manera, la conexión sobre la cual se recibe la trama puede identificarse y puede usarse para dirigir MEP. La información de conexión puede también usarse para llevar a cabo operaciones subsiguientes, de manera que lleva cabo una verificación de conexión .

La Figura 8 muestra un nodo 100 de una red emparedada con paquetes de acuerdo con las modalidades de la invención. El nodo 100 es adecuado para la operación como el nodo de egreso 18 descrito con respecto a la Figura 2.

El nodo 100 comprende la recepción de circuiteria 102 para recibir paquetes de tráfico de datos de los nodos conectados. Los paquetes recibidos se pasan para procesar circuiteria 104, que procesa los paquetes, por ejemplo, de acuerdo con cualquiera de los métodos descritos con respecto a las Figuras 3 a 7. Si se determinan que el paquete recibido tiene una etiqueta GAL, el paquete pasa a GAL desmultiplexando la circuiteria 108, lo cual determina la operación apropiada para llevarse a cabo en el paquete. Por ejemplo, la circuiteria de desmultiplexión de GAL 108 puede enviar el paquete a un MEP a través de una interfaz 110 si el paquete se identifica como un paquete de OAM. Si el paquete recibido no tiene una etiqueta GAL, la circuiteria de proceso 104 puede enviar el paquete a otro nodo al cual se conecta, a través de la circuiteria de interfaz 106. Por lo tanto, vía la circuiteria de interfaz 110' el OAM, funciones de protección, etc., que proveen funcionalidad adicional para LSP y las capas de sección pueden conectarse. Via la circuiteria de interfaz 106 se pueden conectar otros nodos de MPLS-TP o equipo del cliente, por ejemplo.

Se apreciará que las diferentes modalidades descritas antes pueden permitir que funcione una conexión de verificación basada en IETF BFD, basada en ITU-T Y.1731 o una similar capaz de cumplir con los requerimientos contra Verificación de Conectividad de MPLS-TP (CV) en el caso de Túnel de LSP y capas en Sección. Por ejemplo, la conectividad no esperada entre dos ME (por ejemplo mala fusión y malla conexión) , en donde MEP de cada SE ME localizan en el mismo nodo se detectan cuando uno de los propósitos descritos en las modalidades anteriores se usan. Sin estas extensiones las funciones mencionadas no pueden detectar el error.

Se observa que todas las modalidades descritas antes se pueden aplicar para resolver el problema en el caso de una capa de Túnel de LSP. Las modalidades de las figuras 6 y 7 se pueden aplicar para resolver el problema en el caso de una Capa de Sección.

Se deberá observar que las modalidades mencionadas ante ilustran en lugar de limitar la invención, y que los expertos en la materia podrán designar muchas modalidades alternativas sin alejarse del alcance de las reivindicaciones anexas. La palabra (comprendiendo" no excluye la presencia de elementos o pasos diferentes a los listados en una reivindicación, "un" o "uno" no excluye una pluralidad y un solo procesador u otra unidad pueden cumplir con las funciones de varias unidades recitadas en las reivindicaciones. Cualquier referencia señalada en reivindicaciones no se deberá interpretar como limitante su alcance.

Claims (17)

REIVINDICACIÓN

1.- Un método en un nodo de una red de telecomunicaciones de Intercambio de Etiqueta de Múltiples Protocolos (MPLS) , el método comprendiendo los pasos de: recibir una trama de MPLS, la trama de MPLS teniendo una pila de etiquetas que comprende una primera etiqueta y una segunda etiqueta; caracterizada por los paso de: determinar si la trama ha alcanzado su nodo de terminación y, si es asi; revisar la segunda etiqueta en la pila de etiqueta para determinar si la segunda etiqueta se refiere a una Etiqueta de Canal Asociada Genérica (GAL) , si es asi, guardar un descriptor de contextos con base en atributos clave que caracterizan la conexión termina sobre la cual se ha recibido la trama, para usarse por una función de operación, administración y mantenimiento (OAM) durante el proceso subsiguiente de la trama cuando se requiere llevar a cabo verificación de conexión (CV) , revisar continuidad (CC) u otra funciones en donde la identidad del origen de la trama se requiere; y enrutar la trama de proceso de Encabezado de Canal Asociado Genérico (G-ACH) .

2. - El método de acuerdo con la reivindicación 1, en donde el paso de determinar si la trama ha alcanzado su punto final comprende el paso de revisar la primera etiqueta en la pila de etiquetas.

3. - El método de acuerdo con la reivindicación 2, en donde el paso de revisar la primera etiqueta en la pila de etiquetas comprende el paso de revisar si la primera etiqueta se asocia con una operación de resalte.

4. - El método de acuerdo con la reivindicación 1, en donde el paso de determinar si la trama ha alcanzado su punto final comprende el paso de revisar la información de tiempo de vida (TTL) recibido con la trama.

5. - El método de acuerdo con cualquiera de las reivindicaciones precedentes, en donde el paso de guardar el descriptor de contexto comprende los pasos de guardar la primera etiqueta para proceso futuro por las funciones de operación, administración y mantenimiento.

6. - El método de acuerdo con la reivindicación 5, en donde el paso de guardar el descriptor del contexto además comprende el paso de guardar información de espacio de etiqueta .

7. - El método de acuerdo con la reivindicación 6, en donde el paso de almacenamiento . comprende el paso de guardar la primera etiqueta y la información de espacio de etiqueta antes de que se revise la segunda etiqueta; y retener la primera etiqueta y la información del espacio de la etiqueta si la segunda etiqueta es un GAL; y, dejar caer la primera etiqueta y la información del espacio de la etiqueta si en la segunda etiqueta no es GAL.

8. - El método de acuerdo con la reivindicación 6, en donde el paso de almacenamiento comprende el paso de guardar la primera etiqueta y la información de espacio de etiquetas después de que el paso de revisión ha determinado que la segunda etiqueta es GAL.

9.- El método de acuerdo con cualquiera de las reivindicaciones 5 a 7, en donde laso de almacenamiento comprende el paso de guardar la última etiqueta procesada en una memoria para guardar una historia de pilas de etiqueta.

10. - El método de acuerdo con cualquiera de las reivindicaciones precedentes, en donde el paso de revisar la segunda etiqueta se lleva a cabo en respuesta a un bit de estado que se establece en la trama recibida, el bit de estado indicando que la conexión es una conexión monitoreada.

11. - El método de acuerdo con la reivindicación 1, en donde el descriptor del contexto se guarda de la información provista en un espacio de etiqueta de la trama de MPLS recibida, en donde un espacio de etiqueta se asigna a cada conexión monitoreada.

12. - El método de acuerdo con la reivindicación 11, en donde una tabla de mapa de etiqueta entrante separada (ILM) se provee para cada espacio de etiqueta.

13. - El método de las reivindicaciones 11 ó 12, en donde un espacio de etiqueta para una conexión monitoreada se usa para dirigir un Punto Final de Mantenimiento (MEP) .

14. - El método de acuerdo con cualquiera de las reivindicaciones anteriores, en donde el descriptor del contexto se guarda usando una siguiente clave de entrada de avance de etiqueta de salto (NHFLE) .

15. - El método de acuerdo con cualquiera de las reivindicaciones anteriores, comprendiendo además los pasos de: desmultiplexr la trama recibida para obtener datos que se refiere a funciones de operación, administración y mantenimiento (OAM) ; enrutar la trama a un Punto Final de Mantenimiento (MEP) basado en la información de enrutamiento contenida en los datos desmultiplexados ; y llevar a cabo una revisión de conectividad usando el descriptor de concepto guardado.

16. - Un nodo de una red de telecomunicaciones de Interruptor de Etiqueta de Múltiples Protocolos (MPLS) , el nodo comprendiendo: recibir medios para recibir una trama de MPLS, la trama de MPLS teniendo una pila de etiquetas que comprende una primera etiqueta y una segunda etiqueta; caracterizada por que el nodo se configura para: determinar si la trama ha alcanzado su nodo de terminación y si es asi; revistar la segunda etiqueta en la pila de etiquetas para determinar si la segunda etiqueta se refiere a una Etiqueta de Canal Asociada Genérica (GAL) y, si es asi, guardar un descriptor de contexto construido basado en atributos clave que caracterizan la conexión terminada sobre la cual se ha recibido la trama para usarse por una función de operación, administración y mantenimiento (OAM) durante proceso subsiguiente de la trama cuando se lleva a cabo verificación de conexión (CV) , revisión de continuidad (CC) u otras funciones en donde la identidad del origen de la trama se requiere; y enrutar la trama del proceso de Encabezado de Canal Asociado Genérico (G-ACH) .

17.- El nodo de la reivindicación 16, en donde el nodo se configura además para llevar a cabo el método como se definió por cualquiera de las reivindicaciones 2 a 15. RESUMEN Se describen extensiones a un procedimiento de envío de trama de Intercambio de Etiqueta de Múltiples protocolos (MPLS) en un nodo de MPLS . Un descriptor de contexto se define para cada trama recibida en una conexión terminada en dicho nodo y en donde este descriptor de contexto se provee junto con la trama a una función correspondiente (v.gr., operaciones, Administración y Mantenimiento, OAM) si es necesario. El descriptor del contexto se construye con base en atributos clave que caracterizan la conexión terminada sobre la cual se recibe la trama y dirige un punto final de función particular (MEP) Puente de Selector de un caso de protección, etc.) de una función correspondiente (OAM, protección, etc.). En una modalidad, un nodo de Intercambio de Etiqueta de múltiples Protocolos (MPLS) se dirige para revisar no solo la primera sino la segunda etiqueta y no tira la primera etiqueta (y el espacio de etiqueta si es relevante) cuando la segunda etiqueta es la Etiqueta de Canal de Asociación Genérica (GAL) . De esta manera, el contexto original del paquete se mantiene (es decir, la información que se refiere a la conexión sobre la cual se recibió el paquete) y puede usarse para desmult iplexar MEP correspondiente. Luego los identificadores dentro de la carga útil de OAM se pueden usar para verificar la conectividad . Otras modalidades describen soluciones alternativas. RESUMEN Se describen extensiones a un procedimiento de envío de trama de Intercambio de Etiqueta de Múltiples protocolos (MPLS) en un nodo de MPLS . Un descriptor de contexto se define para cada trama recibida en una conexión terminada en dicho nodo y en donde este descriptor de contexto se provee junto con la trama a una función correspondiente (v.gr., operaciones, Administración y Mantenimiento, OAM) si es necesario. El descriptor del contexto se construye con base en atributos clave que caracterizan la conexión terminada sobre la cual se recibe la trama y dirige un punto final de función particular (MEP) Puente de Selector de un caso de protección, etc.) de una función correspondiente (OAM, protección, etc.). En una modalidad, un nodo de Intercambio de Etiqueta de múltiples Protocolos (MPLS) se dirige para revisar no solo la primera sino la segunda etiqueta y no tira la primera etiqueta (y el espacio de etiqueta si es relevante) cuando la segunda etiqueta es la Etiqueta de Canal de Asociación Genérica (GAL) . De esta manera, el contexto original del paquete se mantiene (es decir, la información que se refiere a la conexión sobre la cual se recibió el paquete) y puede usarse para desmultiplexar MEP correspondiente. Luego los identificadores dentro de la carga útil de OAM se pueden usar para verificar la conectividad. Otras modalidades describen soluciones alternativas.