CANAL DE GESTIÓN INCRUSTADO PARA CONECTIVIDAD DE EQUIPO DE TERMINACIÓN DE TRAYECTORIA SONET
Antecedentes Esta divulgación se refiere generalmente a sistemas de telecomunicaciones y, de manera mas particular, a proveer conectividad para comunicaciones de gestión entre entidades de red óptica sincrónica (SONET) sobre redes SONET de proveedores múltiples, portadores múltiples. SONET (y la contraparte Jerarquía Digital Sincrónica (SDH) ) es una tecnología de transporte ampliamente usada en redes de portadores, y el despliegue de equipos de red a base de SONET cuenta por una porción significativa de algunas redes. Conforme el uso de equipos SONET aumenta, el número de proveedores involucrados en diseñar y fabricar equipos SONET también aumenta. Aunque generalmente se supone que proveedores cumplan con estándares SONET para asegurar que su equipo es compatible con aquel de otros proveedores, equipos SONET de diferentes proveedores pueden no presentar tal capacidad de inter-operación. Por ejemplo, canales de comunicaciones de datos (DCCs) SONET pueden usar diferentes apilamientos de protocolo, tales como el estándar de Interconexión de Sistema Abierto (OSI) o el estándar de Protocolo de Control de Transmisión/Protocolo de Internet (TCP/IP) . Mas aun, diferentes proveedores pueden implementar un
apilamiento de protocolo usando mecanismos patentados, y asi las varias implementaciones del mismo apilamiento de protocolo pueden no ser inter-operables . Por razones tales como esta, algunos sistemas SONET son aun implementados con DCCs desactivados. De manera acorde, lo que se necesita es un sistema y método para proporcionar conectividad para comunicaciones de gestión sobre redes SONET de proveedores múltiples, portadores múltiples . Breve Descripción de los Dibujos La figura 1 ilustra una forma de realización de un sistema ejemplar teniendo entidades de red de terminación de trayectoria SONET que pueden comunicar información de canal de gestión incrustado. La figura 2 es un diagrama de flujo de un método ejemplar para encapsular y transmitir información de canal de gestión en banda dentro del sistema de la figura 1. La figura 3 es un diagrama de flujo de un método ejemplar para recibir y extraer información de canal de gestión en banda dentro del sistema de la figura 1. La figura 4 es un diagrama de flujo de un método ejemplar para monitoreo de enlace dentro del sistema de la figura 1. La figura 5 ilustra componentes ejemplares dentro de una de las entidades de red de terminación de trayectoria de la figura 1 que se pueden usar para transmitir y recibir información
de canal de gestión incrustado . La figura 6 ilustra un posicionamiento ejemplar de información de canal de gestión dentro de un marco de control de enlace de datos de alto nivel (HDLC) , tal como se puede usar para transferir datos entre componentes de la entidad de red de la figura 5. La figura 7 es un diagrama de secuencia ilustrando un flujo de datos ejemplar para el establecimiento de un túnel de gestión. Descripción Detallada Esta divulgación se relaciona de manera general con sistemas de telecomunicaciones y, mas particularmente, con proporcionar conectividad para comunicaciones de gestión entre entidades SONET sobre redes SONET de proveedores múltiples, portadores múltiples. Se entiende, sin embargo, que la siguiente divulgación proporciona muchas formas de realización o ejemplos diferentes. Ejemplos específicos de componentes y arreglos se describen mas adelante para simplificar la presente divulgación. Estos son, por supuesto, meramente ejemplos y no pretenden ser limitativos. Además, la presente invención puede repetir números de referencia y/o letras en los varios ejemplos. Esta repetición es para el propósito de simplicidad y claridad y no dicta en si misma una relación entre las varias formas de realización y/o configuraciones discutidas. Para propósitos de ilustrar la presente divulgación,
varios acrónimos pueden usarse, las definiciones de algunos de los cuales se enlistan a continuación: ADM Multiplexor de Añadir y Suprimir CLNS Servicio de Red Sin Conexión DCC Canal de Comunicación de Datos DA Aplicación de Datos DB Base de Datos EMS Sistema de Gestión de Elementos IP Protocolo de Internet MIL Capa de Interfaz de Gestión MNA Aplicación de Red de Gestión MPL Capa de Protocolo de Gestión MPLS Conmutación de Etiquetas Multi-Protocolo NMS Sistema de Gestión de Red NT Transporte de Red NOC Centro de Operación de Red OSPF Abrir Trayectoria Mas Corta Primero SDCC Sección DCC SHIM Administrador de Interfaz de Hardware Simple
SCC Canal de Comunicaciones en Serie STS Señal de Transporte Sincrónica SPE Cubierta de Carga Útil Sincrónica VLAN Red de Área Local Virtual Como será descrito en mayor detalle mas adelante, la siguiente divulgación describe funcionalidad y diseños
hardware y software ejemplares para transferir información de gestión usando entidades de red (NEs) de terminación de trayectoria que se pueden conectar mediante una red intermedia compleja comprendiendo equipo a partir de varios proveedores y sub-redes SONET pertenecientes y administradas por múltiples portadores diferentes. Como será descrito mas adelante en mayor detalle, por medio de incrustar el tráfico de gestión que necesita transferirse entre las dos NEs de terminación de trayectoria en alguna porción de una capa de la trayectoria, las NEs pueden soportar conectividad de gestión. Para propósitos de ejemplo, la metodología usada puede dividirse en dos enfoques: (1) si la trayectoria está portando tráfico de datos, el tráfico de gestión se puede portar por cuadros o paquetes en banda (v.gr., junto con el tráfico de datos) que se pueden segregar del tráfico de cliente mediante un mecanismo de etiquetado (v.gr., usando marbetes VLAN o etiquetas MLPS) ; (2) si la trayectoria no está portando tráfico de datos o es no deseable usar un enfoque en banda, la información de gestión se puede insertar en una porción del encabezado de trayectoria SONET (v.gr., el byte de Canal de Usuario F2 y/o los bytes de crecimiento Z1/Z2 del encabezado de trayectoria SONET) . Se entiende que estos enfoques no necesitan ser exclusivos, pero se separan en la presente divulgación para propósitos de claridad. En una porción de la divulgación, una descripción se
proporciona del uso de túneles de gestión (túneles MGMT) etiquetados (v.gr. , usando VLAN u otro etiquetado) sobre un Canal STS (que normalmente puede portar tráfico de cliente) como la interfaz de gestión. En el presente ejemplo, el túnel MGMT puede ser una solución de conectividad alterna a un DCC (sección y linea) , aunque se entiende que las dos soluciones pueden usarse en conjunto. Un túnel MGMT sobre canales STS puede terminar en una entidad Ethernet sobre SONET designada (v.gr. , una Covaro CC-16000, tal como está disponible de Covaro Networks de Richardson, Texas, Estados Unidos) sirviendo como un eje de gestión. Tal un eje de gestión puede usar, por ejemplo, túneles de IP sobre Ethernet a otras entidades de red en la red sobrepuesta. El túnel MGMT puede servir como una interfaz IP de red y puede correr IP (incluyendo OSPF, CLNS, etc.) . Se entiende que múltiples entidades de Ethernet sobre SONET y/u otras NEs pueden conectarse juntas en muchas maneras diferentes usando tecnología tal como LANs, SDCCs, túneles MGMT, o sus combinaciones. De manera acorde, las entidades de Ethernet sobre SONET pueden enrutar tráfico de una interfaz a otra para proporcionar conectividad IP entre varios nodos . En el presente ejemplo, el túnel MGMT puede soportar dos tipos de encapsulación : IP sobre PPP (protocolo de punto a punto) sobre Ethernet, e IP sobre Ethernet. Para propósitos de ilustración, el IP sobre PPP sobre Ethernet puede usarse entre dos entidades Ethernet sobre SONET (v.gr., dos dispositivos
Covaro 16000) capaces de manejar el procesamiento PPP necesario. Tales entidades pueden también proporcionar monxtoreo de enlace y alarmas usando un protocolo tal como LCP (Protocolo de Control de Enlace) . IP sobre Ethernet puede usarse entre una entidad Ethernet sobre SONET (v.gr., un Covaro 16000) y una entidad NOC, tal como un computador personal (PC) , un enrutador, etc., que no está configurado para procesamiento PPP. Para propósitos de claridad, la siguiente descripción usa el término Ethernet sobre SONET para referirse a una entidad de red que se configura para llevar a cabo procesamiento PPP. Con referencia a la figura 1, una forma de realización de un sistema ejemplar 100 se ilustra. El sistema 100 incluye una primera entidad de red 102 conectada mediante una red SONET 104 a una segunda entidad de red 106. Para propósitos de claridad, el término SONET se usa a través de la presente divulgación para referirse a SONET y/o SDH. De manera acorde, se entiende que referencias a SONET se pueden reemplazar con referencias a SDH, aunque algunos cambios menores pueden necesitarse, como será conocido para los técnicos en la materia. Aunque una entidad de red en la presente divulgación puede ser cualquier componente, dispositivo o sistema (hardware y/o software) , accesible por red, la entidad de red 102 es una entidad Ethernet sobre SONET de terminación de trayectoria configurada para llevar a cabo procesamiento PPP. La entidad de red 106 puede ser ya sea una entidad Ethernet sobre SONET o puede ser una entidad de red que
no se configura para llevar a cabo procesamiento PPP (v.gr., un conmutador capaz de L2 VLAN) . En el presente ejemplo, la entidad de red 106 está en un NOC 108 que también incluye un EMS/NMS 112 conectado a la entidad de red 106 mediante una red de comunicaciones de datos
(DCN) 110. Los usuarios 114a y 116a pueden obtener acceso a la red 104 mediante la entidad de red 102, mientras que los usuarios 114b y 116b pueden obtener acceso a la red 104 mediante la entidad de red 106. Se entiende que usuarios adicionales, entidades de red, redes, y/o sub-redes pueden conectarse a varios elementos de la figura 1. De manera acorde, la figura 1 es para propósitos de ejemplo solamente y se ha simplificado para ilustrar mejor la presente divulgación. Para propósitos de ejemplo, el sistema 100 incluye tres VLA s (no mostradas de manera explícita) . Una primera VLAN
(referida posteriormente en la presente como VLAN 1) proporciona conectividad entre los usuarios 114a y 114b mediante las entidades de red 102, 106 y la red 104. Una segunda VLAN (VLAN 2) proporciona conectividad entre los usuarios 116a y 116b. Una tercera VLAN (VLAN 3) proporciona conectividad de túnel de gestión entre las entidades de red 102, 106. Como será descrito mas adelante en mayor detalle, el presente ejemplo permite que información de túnel de gestión sea enviada en banda (v.gr., junto con datos de usuario) mediante la red 104. Esto se puede lograr usando varios procesos de encapsu-
lado y etiquetado, como se ilustra en las figuras 2-4. Con referencia ahora a la figura 2, un método ejemplar 200 ilustra un proceso para enviar un mensaje MGMT en banda (v.gr., junto con tráfico de datos (no de gestión)) usando el sistema de la figura 1. Se entiende que la divulgación puede usar los términos mensaje, paquete, y cuadro de manera intercambiable para propósitos de conveniencia. En el presente ejemplo, el método 200 se lleva a cabo usando la entidad de Ethernet sobre SONET 102. En el paso 202, un mensaje MGMT que se va a transmitir se encapsula en un paquete IP. En el paso 204, una determinación se puede hacer respecto de cual tipo de interfaz se va a usar para transmitir el mensaje IP. En el presente ejemplo, esta determinación se basa en si la entidad de red 106 es una entidad Ethernet sobre SONET o es una entidad de red que no está configurada para llevar a cabo procesamiento PPP. Si el tipo de interfaz es Ethernet (v.gr., la entidad de red 106 no está configurada para procesamiento PPP) , el método continúa al paso 208, donde el paquete IP se encapsula en un paquete Ethernet. Si el tipo de interfaz es PPP (v.gr., la entidad de red 106 está configurada para procesamiento PPP) , el método continúa al paso 206, donde el procesamiento de paquete puede ocurrir como se define por cualquier parámetro PPP aplicable. El método puede entonces continuar al paso 208, donde el paquete IP se encapsula en un paquete Etherne .
En los pasos 210 y 212, una etiqueta de gestión (v.gr., una etiqueta de gestión VLAN) puede añadirse al cuadro Ethernet y el mensaje se puede transmitir (v.gr., a la entidad de red 106) . La etiqueta de gestión permite que el mensaje sea enrutado dentro del sistema 100 de manera apropiada. Por ejemplo, si el mensaje no es un mensaje MGMT (v.gr., su fuente o destino denota las VLANs 1 o 2) , un identificador de VLAN (v.gr., un VID) puede asignarse designando el destino VLAN (v.gr., VID = 1 o VID = 2) . Sin embargo, si el mensaje incluye información MGMT, el mensaje se puede asignar a una etiqueta de VID = 3 para indicar que la VLAN 3 de gestión se va a usar. Con referencia ahora a la figura 3, un método ejemplar 300 ilustra un proceso para recibir un mensaje en banda y extraer información MGMT del mensaje. En el paso 302, un mensaje etiquetado se recibe. En el paso 304, una determinación se puede hacer respecto de si el mensaje contiene información MGMT. Esta determinación se puede hacer, por ejemplo, por medio de examinar la etiqueta para determinar si el VID es igual a 1 (tráfico de datos, 2 (tráfico de datos) , o 3 (tráfico MGMT) . Si el paquete no contiene información MGMT, se puede pasar para procesamiento de servicio (v.gr., enrutarlo a la VLAN apropiada) en el paso 306. Si el paquete no contiene información MGMT, entonces el método 300 puede continuar a los pasos 308 y 310, donde la etiqueta de gestión y el encapsulado Ethernet pueden removerse. En el paso 312, una determinación puede hacerse
respecto del tipo de carga útil (v.gr., 1P o PPP) del paquete. Si el tipo de carga útil es IP, el método 300 puede continuar al paso 316, donde la información MGMT se puede extraer desde el paquete IP y enviarse a un usuario (v.gr. , el EMS/NMS 112) . Si el tipo de carga útil es PPP, el método continúa al paso 314, donde el procesamiento puede ocurrir como se define por cualquier configuración PPP aplicable. El método 300 puede entonces continuar al paso 316, donde la información MGMT puede extraerse a partir del paquete IP. Como se describe anteriormente con respecto a las figuras 2 y 3 , el proceso de encapsulado y etiquetado permite que información MGMT se envíe en banda con tráfico de datos . La entidad Ethernet sobre SONET 102 puede seleccionar automáticamente IP sobre Ethernet o IP sobre PPP sobre Ethernet, dependiendo de la configuración de la entidad de red 106. Se entiende que determinar si usar PPP puede o no puede ocurrir, y la entidad Ethernet sobre SONET puede configurarse para siempre usar uno o el otro para una entidad o entidades de red particulares. Mas aun, se entiende que el tráfico puede similarmente fluir en la dirección opuesta hacia la entidad Ethernet sobre SONET 102. En algunas formas de realización, el sistema 100 pueden usar encapsulado de provisión PPP o Ethernet. En el ejemplo actual, hay dos túneles por entidad de red con un número de control de acceso de medios (MAC) por túnel (protegido o no protegido) , pero se entiende que mas o menos túneles y/o MACs
pueden usarse . Un caché de protocolo de resolución de dirección (ARP) puede implementarse en la presente forma de realización con un número predefinido de entradas (v.gr., 16 entradas) por interfaz (protegido o no protegido) . Además, envejecimiento de caché ARP se puede implementar. En la presente forma de realización, puede no haber ningún ARP estático y ningún proxy de ARP, pero se entiende que estas características pueden incluirse en algunas implementaciones . El presente ejemplo también usa interfaces IP no numeradas, proporciona asociación de pares con enrutadores NOC usando OSPF, y no proporciona para anunciar OLSA. Un comando TL1 ejemplar para uso en el sistema 100 puede ser como sigue: ENT-MGMTTNL : [<TID>] : <AID> : <CTAG> : : : [BW=<bw>] [,TVID=<tvid>] ,L2PRTCL=<l2prtcl>, [ , IPADDR=<ipaddr>] [, IPMASK=<ipmask>] : [<PST>] . L2PRTCL (protocolo de capa 2) puede ser un atributo de lectura, o puede ser de lectura/escritura y capaz de tomar valores de PPP o Ethernet. Se entiende que incrustar un canal de gestión en la capa de trayectoria puede permitir a un sitio de eje que termine muchas trayectorias, cada una de las cuales puede terminarse en un sitio remoto diferente. El sitio de eje puede entonces tener visibilidad directa de múltiples sitios remotos y actuar como una compuerta de gestión a estos sitios remotos. Mas aun, el uso de un canal de gestión incrustado puede usarse sobre cualquier tipo de transporte que se pueda usar para portar tráfico de datos. Por ejemplo, un canal de
gestión etiquetado VLAN puede incrustarse en una Trayectoria DS3 que está portando tráfico Ethernet codificado X.86. Con referencia ahora a la figura 4, en otra forma de realización, un método ejemplar 400 ilustra un proceso para establecimiento de enlace (monxtoreo y alarmas) que se puede usar por separado o en conjunto con los métodos 200 y 300 descritos anteriormente. En el presente ejemplo, el establecimiento de enlace solamente se habilita si el encapsulado es IP sobre PPP sobre Ethernet (v.gr. , si ambas entidades de red 102, 106 son entidades Ethernet sobre SONET) . Como será descrito, el método 400 inicia un cronómetro y envía mensajes de permanecer vivo periódicos y, si el sistema remoto no responde después de un número predefinido de mensajes de permanecer vivo consecutivos (v.gr., 3) , una alarma de enlace caído se reporta a un usuario y/o software de enrutamiento IP. Esto permite que el software encuentre rutas alternativas para tráfico . Un mensaje de mantener vivo puede recibirse en el bloque PPP 406. Esto dispara un paquete PPP saliente usando LCP que se envía al bloque Ethernet 404 para encapsulado. Un cuadro Ethernet puede enviarse a partir del bloque Ethernet 404 al bloque de transmitir/recibir 402, que envía al mensaje. En algunas formas de realización, una etiqueta de gestión puede añadirse usando el bloque 403 antes de que se envíe el mensaje. Cuando un mensaje (v.gr., una respuesta) se recibe por el bloque de transmitir/recibir 402, se regresa al bloque PPP 406 mediante
el bloque Ethernet 404 (y las porciones Ethernet y PPP son despojadas) . Si un número predefinido de mensajes de mantener vivo consecutivos (v.gr. , 3) no son respondidos por el sistema remoto al cual los mensajes se enviaron, una alarma de enlace caído puede reportarse a un usuario y/o software de enrutamiento de IP. Con referencia ahora a la figura 5, en otra forma de realización, una implementación mas especifica de la entidad Ethernet sobre SONET 102 de la figura 1 se ilustra con cuatro módulos (v.gr., tarjetas), que pueden incluir software y/o hardware. En el presente ejemplo, las cuatro tarjetas incluyen una tarjeta de procesador de control maestro (MCP) 502, una tarjeta de servicio (s) 504, una tarjeta de transporte de red (NT) activo 506, y una tarjeta NT en espera 508. La tarjeta MCP 502 puede usar dos canales de comunicaciones en serie (denotados SCC1 y SCC2) como canales de control de enlace de datos de alto nivel (HDLC) para conectar a/desde las tarjetas NT 506, 508 para enviar y recibir tráfico MGMT. Para transferir el tráfico, los SCCs pueden usarse para encapsular el tráfico MGMT en un cuadro HDLC, como se ilustra en la figura 6. Mas específicamente, un controlador de dispositivo Ethernet (Ethernet DD) en la tarjeta MCP 502 pueden instruir a los SCCs a usar un cuadro HDLC. Se entiende que otros métodos de encapsulado pueden usarse. Mas aun, el encapsulado HDLC en el presente ejemplo sirve solamente para habilitar la transferencia de datos
entre los SCCs del MCP 502 y los HDLCs del NT activo 506 y el NT en espera 508. En el presente ejemplo, los SCCs pueden programarse con una tasa de baudios máxima (v.gr. , 2.8 Mbs) . Cada túnel MGMT puede tener encapsulado de IP sobre Ethernet sobre HWlabel (etiqueta HW) (v.gr., de la tarjeta MCP 502 a un FPGA de Procesamiento de las tarjetas NT 506, 508, y viceversa) que se traza a una SPE utilizando solamente un ancho de banda programado de la capacidad de la SPE. La HWlabel puede representar un valor de etiqueta de una compuerta programada en una tabla de compuerta-etiqueta de hardware y puede anexarse en el propio cuadro con atributos de dirección y cuadro (v.gr., servicio, VLAN, destino, etc.) . El encapsulado se puede llevar a cabo por el Ethernet DD. Una especificación de Ethernet DD ejemplar para esta interfaz como sigue: Formato de encabezado de Soporta Ethernet "SF, DA, SA, L/T, PAYLOAD, FCS" [v.gr., delimitador de cuadro de inicio, dirección de destino, dirección fuente, longitud/tipo, carga útil, secuencia de revisión de cuadro] . Direcciones de control de acceso de medios (MAC) SA y DA pueden ser cero, o una dirección SA puede usarse para todos los túneles MGMT y una DA puede proporcionarse por túnel . Mas aun, cada túnel MGMT puede proporcionarse con una VLAN. El túnel MGMT puede proporcionarse con una VLAN. Ni ARP o RARP se soporta.
Cálculo FCS se soporta. EthStats no se recolectan. Unidad de transferencia máxima (MTU) de 1,500 bytes . La dirección de transmitir usa un índice de interfaz (ifIndex) como un índice dentro de HWlabelTable para recuperar una HWlabel correspondiente, empuja la HWlabel, y después transmite el cuadro en ambos SCCs (v.gr., de las tarjetas NT1 y NT2) . (El ifIndex es una tabla de interfaces que identifica varias interfaces de aplicación, tales como túneles MG T, DCCs, etc . ) . En la dirección de recibir, cuando un cuadro se recibe, el bit PROT_DISCARD se revisa. Si es igual a l, el paquete será dejado dado que el cuadro se envió por la tarjeta de servicios 504. De otra manera, el paquete será aceptado por medio de buscar en HWlabelTable por un equivalente de la HWlabel entrante para encontrar el ifIndex correspondiente. Si un equivalente se encuentra, el ifIndex correspondiente y el paquete IP se envían a la capa IP, de otra manera el paquete es dejado. Cada tarjeta NT 506, 508 puede tener un canal HDLC que se puede usar para conectar a la tarjeta MCP 502 para enviar y recibir tráfico MGMT. En el presente ejemplo, el formato de tráfico MGMT es el mismo como el formato de tráfico de servicios Ethernet (de la tarjeta de servicio 504) para presentar tráfico uniforme a un FPGA de procesamiento de una de las tarjetas NT
506, 508. De manera acorde, cuando una tarjeta NT 506, 508 recibe un cuadro sobre un canal HDLC, el cuadro se puede etiquetar con HWLABEL por la tarjeta MCP 502 (y la HWLABEL puede calcularse en tiempo de provisión) . La HWLABEL puede entonces usarse por las tarjetas NT 506, 508 como un Indice dentro de una tabla de búsqueda para identificar la SPE portadora y otra información relacionada. Cuando el L2 procesando FPGA recibe tráfico a partir del motor de procesamiento SONET, usa los indicadores SPE, TVID, PRI (prioridad) como un índice dentro de la tabla de búsqueda para identificar si el tráfico pertenece a un servicio Ethernet o a un túnel MGM . Si pertenece a un túnel MGMT, el cuadro se envía al MCP etiquetado con la HWLABEL, donde la HWLABEL se utiliza por el MCP para identificar al túnel MGMT recibiendo el tráfico. Los detalles serán capturados por el diseño FPGA de procesamiento . Con referencia ahora a la figura 7, en aun otra forma de realización, un flujo de datos 700 ejemplar entre varios subsistemas manejando los comandos relacionados con túneles MGMT, incluyendo un usuario, una capa de protocolo de gestión (MPL) /capa de interfaz de gestión (MIL) , una aplicación de datos (DA) , un administrador de interfaz de hardware simple (SHIM) , y una aplicación de red de gestión (MA) . Mas específicamente, en el presente ejemplo, la provisión de los túneles MGMT (ENT/ED/RTRT/DLT-MGMT-TNL) puede tener impacto en los subsistemas SW de la MPL/MIL, la DA y la MNA como sigue.
La MPL/MIL puede recibir un comando de túnel MGMT en el paso 702. Cuando la MPL/MIL recibe el comando de túnel MGMT, puede validar al comando con base en el contenido de una base de datos y reglas de provisión predefinidas. Si el comando es inválido, puede regresar el mensaje de error apropiado al usuario. De otra manera, comienza una transacción DB, redirige el comando a la DA en el paso 704, y espera por una respuesta. Si una respuesta positiva se recibe, compromete la transacción a la DB y responde al usuario. De otra manera, aborta la transacción y envía una respuesta al usuario indicando que el comando fue negado . Cuando la DA recibe el comando, valida al comando por medio de revisar uno o mas parámetros de sistema (v.gr. , una parámetro relacionado con STS, BW, TVID de sistema, etc.) . Si el comando es inválido, envía una respuesta de negación a la MIL. De otra manera, interactúa con el SHIM (pasos 706, 708) y crea una etiqueta HW requerida por FPGA con los siguientes formatos : port = x (donde x significa "no importa"); size = bytes correctos en el cuadro incluyendo FCS de Ethernet de etiqueta HW; tag_cmd = x; slot = X; spe = X; red = 0 ; pri = provista;
vid = provista; hwL-parity = paridad impar correcta calculada para
63 bits; encaps = x; y que = x. El SHIM proporciona abstracción de hardware, habilitando implementación de cambios para hacerse mediante solamente cambiando el SHIM. La DA entonces redirige el comando a la MMA (incluyendo la etiqueta HW) en el paso 710 y espera por una respuesta. Nótese, el mensaje de túnel MGMT enviado por la MIL puede tener un sujetador de lugar para la etiqueta HW tal que la DA no tenga que crear un nuevo mensaje cuando redirige el comando a la MNA. Cuando la MNA recibe el comando, puede validar datos tales como la dirección IP. Si el comando es válido, actualiza su almacenamiento local y responde a la DA en el paso 712. De otra manera, niega el comando por medio de enviar una ACK negativa a la DA. La MNA crea una interfaz de Ethernet que liga a la interfaz con la capa IP. Cuando la DA recibe la respuesta de la MNA, revisa la respuesta. Si la respuesta es negativa, la DA borra el túnel MGMT y después redirige la respuesta a la MIL en el paso 714. Si la respuesta es positiva, la DA redirige la respuesta a la MIL y actualiza la tabla de búsqueda en las tarjetas NT 506, 508. La actualización puede incluir:
Escribir a entradas de RAM libre cmd, ene, que, pri, y tvid; Escribir a entradas CAM correspondientes port = X, slot = 30, pri, y vid; Escribir a entrada de RAM libre cmd, ene, que, pri, y tvid; y Escribir a las entradas de memoria de direcciona-miento de contenido (CAM) correspondientes port = X, slot = 31, pri, y vid. En aun otra forma de realización, una trayectoria de red (v.gr. , en el sistema 100 de la figura 1) puede no estar llevando tráfico o puede no ser deseable para uso en proceso en banda como se describe anteriormente. Por ejemplo, usando un proceso en banda para transferir información de gestión puede atar recursos para los cuales un cliente puede estar dispuesto a pagar. De manera acorde, un método alternativo para transferir información entre entidades de red de terminación de trayectoria (v.gr., las entidades de red 102, 106) puede ser deseado. En algunos ejemplos, la información de gestión se puede insertar en varias posiciones en el cuadro o paquete, tal como en el byte F2 de Canal de Usuario y/o los bytes de crecimiento Z1/Z2 de la trayectoria SONET superior. Esto permite que información de gestión se transfiera entre las entidades de red de terminación de trayectoria. Aunque tales formas de realización se pueden implementar con ambas entidades de red 102, 106 como entidades
Ethernet sobre SONET configuradas para usar PPP, otras formas de realización pueden no usar PPP. Aunque la descripción precedente muestra y describe una o mas formas de realización, se entenderá por los técnicos en la materia que varios cambios en forma y detalle se pueden hacer en la misma sin salir del espíritu y alcance de la presente divulgación. Por ejemplo, varias implementaciones especificas han sido descritas para propósitos de ejemplo, pero la presente divulgación no se limita a esas implementaciones . Varios tipos de encapsulado y etiquetado se pueden usar para lograr la conectivi-dad de túnel de gestión entre entidades de red de terminación de trayectoria como se describe en la presente divulgación. De manera similar, diferentes configuraciones de red pueden usarse, como pueden diferentes tipos de entidades de red. Mas aun, instrucciones de software se pueden almacenar y/o ejecutar por varias entidades de red para llevar a cabo varias funciones. Por ejemplo, los métodos de las figuras 2-4 pueden incluir pasos que se representan en instrucciones de software y se ejecutan por varias entidades de red de la figura 1. Por lo tanto, las reivindicaciones deben interpretarse en una manera amplia, consistente con la presente divulgación.