ES2374375T3 - Encapsulación de tramas ethernet grandes. - Google Patents

Encapsulación de tramas ethernet grandes. Download PDF

Info

Publication number
ES2374375T3
ES2374375T3 ES09730303T ES09730303T ES2374375T3 ES 2374375 T3 ES2374375 T3 ES 2374375T3 ES 09730303 T ES09730303 T ES 09730303T ES 09730303 T ES09730303 T ES 09730303T ES 2374375 T3 ES2374375 T3 ES 2374375T3
Authority
ES
Spain
Prior art keywords
cfm
message
frame
data
cfm message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES09730303T
Other languages
English (en)
Inventor
Robert Sultan
Linda Dunbar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Application granted granted Critical
Publication of ES2374375T3 publication Critical patent/ES2374375T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Special Wing (AREA)
  • Small-Scale Networks (AREA)

Abstract

Un método que comprende: recibir una trama de datos; caracterizado porque: si la trama de datos recibida hace que un mensaje de gestión de defecto de conectividad, CFM, exceda de un tamaño de unidad de datos de se 5 rvicio máxima, MSDUS, y si se establece que una banderola de truncación es verdadera, truncar la trama de datos y encapsular las porciones restantes en un mensaje de gestión de defecto de conectividad, CFM; en caso contrario, dividir la trama de datos en dos tramas más pequeñas y encapsular esas dos tramas más pequeñas por medio de dos mensajes CFM separados.

Description

Encapsulación de tramas Ethernet grandes.
CAMPO DE LA INVENCIÓN
La presente invención se refiere al campo de las telecomunicaciones y, en particular, a un método, un componente de red y un puente para encapsular tramas Ethernet grandes.
ANTECEDENTES
Las modernas redes de comunicaciones y datos, tales como las basadas en las tecnologías de puenteo Ethernet, están constituidas por nodos que reenvían tramas de datos a través de la red. Para transferir las tramas a través de la red se utilizan una pluralidad de estándares de red. Por ejemplo, el estándar (IEEE) 802.1Qaw del Instituto de Ingenieros Eléctricos y Electrónicos para gestión de defectos de conectividad dependientes de datos e inducidos por datos (DDCFM) está siendo desarrollada para diagnosticar problemas que son sensibles al contenido de los datos transferidos. Tales problemas son difíciles de reproducir con procedimientos tales como Loopback que se basan en el intercambio de mensajes de control y no en datos de usuario.
SEAMAN M: “Diagnosing data dependent and data driven connectivity faults”, INTERNET CITATION, 15 de Marzo de 2006 (), página 1, con No. XP003023899, revela una extensión de las capacidades básicas de CFM para soportar detección, diagnóstico y aislamiento de defectos de conectividad que afectan a tramas que contienen datos o patrones de datos particulares.
El documento US 2006/018315 A1 (INT BUSINESS MACHINES CORP), 26 de Enero de 2006 (), se refiere a un método y un aparato para proporcionar fragmentación a un nivel de transporte a lo largo de una ruta de transmisión. El método comprende recibir un paquete de datos de un primer dispositivo remoto para su transmisión a un segundo dispositivo remoto, en donde el paquete de datos incluye un paquete de protocolo de nivel de transporte encapsulado en un paquete de protocolo de nivel de red, y determinar si un tamaño del paquete de datos recibido es mayor que un valor de unidad de transmisión máxima (MTU). El método comprende, además, ejecutar una fragmentación del paquete de datos en un protocolo de nivel de transporte en dos o más fragmentos en respuesta a la determinación de que el tamaño del paquete de datos recibido es mayor que el valor MTU, y transmitir uno o más de los fragmentos al segundo dispositivo remoto.
“IEEE P802.1Qaw, Draft Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 10: Virtual Bridged Local Area Networks, Management of Data Driven and Data Dependent Connectivity Fault Management”, INTERNET CITATION, 27 de Abril de 2007 (), páginas 1-62, XP003023898, revela que el procedimiento básico para conseguir el aislamiento de un DDF consiste en dividir la red en múltiples segmentos y verificar si las tramas de datos sospechosas pueden atravesar cada segmento según lo esperado. Cuando un segmento de red es identificado como responsable, se divide adicionalmente el segmento en segmentos más pequeños hasta que un puente, un puerto o un punto de mantenimiento CFM (Cláusula 20) es identificado como responsable de la falta de paso por las instancias de servicio o de las tramas de datos sospechosas con calidad esperada. DDF puede no ser evidente en ausencia de tráfico vivo (es decir, cuando se utilizan datos de ensayos). Por tanto, se tiene que realizar un diagnóstico mientras la red está realmente funcionando, y las propias herramientas de diagnóstico no tienen que introducir más defectos dependientes de datos. DDCFM es una herramienta para que los operadores detecten, aíslen y verifiquen defectos dependientes de datos e inducidos por datos. Hay dos tipos de ensayos DDE: el ensayo de ruta de ida (FifE) y el ensayo de ruta de retorno (RPT).
ANONYMOUS ED - ANONYMOUS: IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management: IEEE Std 802.1ag 2007 (Enmienda de IEEE Std 802.1Q-2005, tal como fue enmendado por IEEE Std 802.1ad-2005 e IEEE Std 802.1ak-2007)”, 1 de Enero de 2007 (), IEEE STANDARD; [IEEE STANDARD] IEEE. PISCATAWAY, NJ, USA, PAGINA(S) 1-260, XP017601 839, especifica protocolos y entidades de protocolo dentro de la arquitectura de puentes conscientes de VLAN que proporcionan capacidades para detectar, verificar y aislar fallos de conectividad en redes de área local puenteadas virtuales. Estas capacidades pueden utilizarse en redes operadas por múltiples organizaciones independientes, cada una con un acceso de gestión restringido a cada equipo de las demás.
SUMARIO
La invención incluye un método que comprende recibir una trama de datos; si la trama de datos recibida hace que el mensaje CFM exceda de un tamaño de unidad de datos de servicio máxima, MSDUS, y si se establece que una banderola de truncación es verdadera, truncar la trama de datos y encapsular las porciones restantes en un mensaje de gestión de defecto de conectividad, CFM; en caso contrario, dividir la trama de datos en dos tramas más pequeñas y encapsular esas dos tramas más pequeñas por medio de dos mensajes CFM separados.
La invención incluye también un componente de red que comprende un procesador configurado para implementar un método de utilizar CFM para soportar un diagnóstico de defecto de conectividad, comprendiendo el método:
recibir una trama de datos;
caracterizado porque:
si la trama de datos recibida hace que el mensaje CFM exceda de un tamaño de unidad de datos de servicio máxima, MSDUS, y
si se establece que una banderola de truncación es verdadera, truncar la trama de datos y encapsular las porciones restantes en un mensaje de gestión de defecto de conectividad, CFM, contenido en una trama de mensaje CFM; en caso contrario, dividir la trama de datos en dos tramas más pequeñas y encapsular esas dos tramas más pequeñas por medio de dos mensajes CFM separados.
Estas y otras características se entenderán más fácilmente a partir de la descripción detallada siguiente tomada en unión de los dibujos y reivindicaciones que se acompañan.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
Para una mejor compresión de este descubrimiento se hace ahora referencia a la breve descripción siguiente, tomada en unión de los dibujos y la descripción detallada que se acompañan, en donde números de referencia iguales representan partes iguales.
La figura 1 es un diagrama esquemático de una realización de un sistema DDCFM.
La figura 2 es un diagrama esquemático de otra realización de un sistema DDCFM.
La figura 3 es un diagrama de flujo de una realización de un método de encapsulación de mensajes CFM.
La figura 4 es una ilustración de una realización de una máquina de estado de encapsulación de mensajes CFM.
La figura 5 es un diagrama de flujo de una realización de un método de desencapsulación de mensajes CFM.
La figura 6 es una ilustración de una realización de una trama de mensaje CFM.
La figura 7 es un diagrama esquemático de una realización de un sistema de ordenador de uso general.
DESCRIPCIÓN DETALLADA
Deberá entenderse al comienzo que, aunque se proporciona más abajo una implementación ilustrativa de una o más realizaciones, los sistemas y/o métodos revelados pueden implementarse utilizando cualquier número de técnicas, sean corrientemente conocidas o estén en existencia. El descubrimiento no deberá limitarse en modo alguno a las implementaciones, dibujos y técnicas ilustrativos mostrados más abajo, incluyendo los diseños e implementaciones a modo de ejemplos ilustrados y descritos en este documento, sino que puede modificarse dentro del alcance de las reivindicaciones adjuntas.
Los defectos en redes puenteadas, tales como redes de área local virtuales (VLANs) puenteadas, pueden comprender defectos independientes de los datos, que pueden resultar de pérdida o mala dirección repetitiva de tramas, por ejemplo debido al fallo de un enlace o puente. Como alternativa, los defectos pueden comprender defectos dependientes de los datos y/o defectos inducidos por los datos, de modo que el contenido de tramas de datos particulares es la causa de los defectos. Los defectos dependientes de los datos y los defectos inducidos por los datos (DDFs) pueden diagnosticarse aislándolos en un componente de red particular, tal como un enlace o un puente, o un segmento de la red, que comprenda una secuencia de tales componentes de red. El DDF puede aislarse dividiendo la red en una pluralidad de segmentos y verificando si una pluralidad de tramas puede atravesar cada segmento según lo esperado. Cuando se identifica un segmento de red como defectuoso, el segmento puede ser dividido adicionalmente en una pluralidad de segmentos más pequeños hasta que se identifique un componente defectuoso específico.
Se revelan aquí sistemas y métodos para reenviar tramas que pueden utilizarse para DDCFM. Las tramas pueden ser transportadas desde un nodo de origen hasta un nodo de destino a través de un nodo intermedio. El nodo intermedio puede configurarse para procesar una pluralidad de mensajes CFM, tales como mensajes de trama reflejada (RFMs) o mensajes de envío de trama (SFMs). En un esquema de ensayo de ruta de ida (FPT) el nodo de origen puede ser un originador FPT, que puede enviar una pluralidad de tramas al nodo intermedio. El nodo intermedio puede recibir y reenviar las tramas al nodo de destino. El nodo intermedio puede ser un respondedor de reflexión (RR) que recibe y encapsula las tramas en una pluralidad de RFMs, que pueden ser enviados a un nodo diana. El nodo diana puede ser un receptor RFM que puede recibir y desencapsular los RFMs para obtener el contenido de la trama original. Como alternativa, en un esquema de ensayo de ruta de retorno (RPT) el nodo de origen puede ser un originador SFM que encapsula una pluralidad de tramas en una pluralidad de SFMs y envía los SFMs al nodo intermedio. El nodo intermedio puede ser un respondedor desencapsulador (DR) que puede recibir y desencapsular los SFMs para obtener el contenido de la trama original. El nodo intermedio puede reenviar después las tramas desencapsuladas al nodo de destino, que puede ser un receptor RPT. Cuando el tamaño de un RFM a enviar por un RR excede del tamaño máximo tolerado para un solo RFM o cuando el tamaño de un SFM a enviar por un originador SFM excede del tamaño máximo tolerado para un solo SFM, la trama puede ser partida y encapsulada en al menos un primer mensaje CFM y un segundo mensaje CFM, cada uno de los cuales tiene un tamaño menor o igual que el tamaño máximo tolerado. El primer mensaje CFM y el segundo mensaje CFM pueden ser reenviados después al receptor RFM apropiado o al DR apropiado, en donde dichos mensajes pueden ser desencapsulados para obtener el contenido de las tramas originales. Además, se pueden combinar y encapsular una pluralidad de tramas en el RR o el originador SFM y se pueden reenviar éstas al receptor RFM o al DR para su desencapsulación con el fin de restaurar el contenido de las tramas antes de la encapsulación.
La figura 1 ilustra una realización de un sistema DDCFM 100 que puede utilizarse para diagnosticar DDFs, por ejemplo en una LAN puenteada. El sistema DDCFM 100 puede utilizar un FPT para detectar los DDFs y puede comprender un originador FPT 110, un RR 120 y un receptor RFM 130. El originador FPT 110, el RR 120 y el receptor RFM 130 pueden ser dispositivos de cualquier clase que transporten tramas a través del sistema DDCFM
100. Por ejemplo, el originador FPT 110, el RR 120 y el receptor RFM 130 pueden comprender una pluralidad de puertos de ingreso para recibir tramas de otros nodos, circuitos lógicos para determinar a qué nodos se deben enviar las tramas, y una pluralidad de puertos de egreso para transmitir tramas a los otros nodos. El originador FPT 110, el RR 120 y el receptor RFM 130 pueden ser puentes y pueden hacer las determinaciones necesarias para transportar las tramas a través de la red en la capa 2 de la interconexión de sistemas abiertos (OSI).
En una realización el originador FPT 110, el RR 120 y el receptor RFM 130 pueden comprender puentes y pueden estar situados en una red, tal como una red basada en Ethernet, que puede incluir una VLAN. Además, el originador FPT 110 puede estar configurado para generar una pluralidad de tramas de datos. Las tramas de datos pueden asociarse con una instancia de servicio, una dirección de destino, una VLAN, etc. El RR 120 pueden configurarse para establecer comunicaciones con el originador FPT 110 y el receptor RFM 130, además de con otro nodo de destino en la red (no mostrado), que pueden configurarse de manera sustancialmente similar al originador FPT 110. Por ejemplo, el RR 120 puede establecer una VLAN puenteada entre el originador FPT 110 y el otro nodo de destino en la red y puede reenviar una pluralidad de tramas de datos del originador FPT 110 a ese nodo de destino. Además, el RR 120 puede establecer comunicaciones con el receptor RFM 130 y puede estar configurado para encapsular las tramas de datos generadas por el originador FPT 110. Las tramas de datos pueden encapsularse en una pluralidad de mensajes CFM, tales como RFMs, por ejemplo añadiendo cabeceras RFM a las tramas. El RR 120 puede reenviar después los RFMs al receptor RFM 130. El receptor RFM 130 puede estar configurado para recibir y procesar los RFMs a fin de detectar cualesquiera DDFs que puedan estar presentes. Por ejemplo, el receptor RFM 130 puede comparar los RFMs recibidos con las tramas originalmente generadas para detectar defectos o fallos de cualquier clase.
La figura 2 ilustra una realización de otro sistema DDCFM 200 que puede utilizarse para diagnosticar DDFs. Específicamente, el sistema DDCFM 200 puede utilizar un RPT para detectar los DDFs y puede comprender un originador SFM 210, un DR 220 y un receptor RPT 230. El originador SFM 210, el DR 220 y el receptor RPT 230 pueden ser dispositivos de cualquier clase que transporten tramas a través del sistema DDCFM 200 en una red, tal como una VLAN. El originador SFM 210, el DR 220 y el receptor RPT 230 pueden comprender una pluralidad de puertos de ingreso para recibir tramas de otros nodos, circuitos lógicos para determinar a qué nodos se deben enviar las tramas, y una pluralidad de puertos de egreso para transmitir tramas a los otros nodos. El originador SFM 210, el DR 220 y el receptor RPT 230 pueden ser puentes.
En una realización el originador SFM 210 puede estar configurado para generar mensajes CFM, tales como SFMs. Los SFMs pueden comprender dos tramas de datos que pueden estar asociadas con una instancia de servicio, una VLAN, etc., y pueden utilizarse para DDCFM. Además, los SFMs pueden comprender una dirección de destino asociada con el receptor RPT 230. El DR 220 puede estar configurado para establecer comunicaciones con el originador SFM 210 y el receptor RPT 230. El DR 220 puede estar configurado para desencapsular los SFMs recibidos del originador SFM 210, por ejemplo retirando las cabeceras SFM, y reenviar las tramas desencapsuladas resultantes al receptor RPT 230 sobre la base de la dirección de destino. Además, el DR 220 puede sustituir la dirección de origen o la dirección de control de acceso de medios (MAC) correspondiente al originador SFM 210 por la dirección MAC del DR 220. Por tanto, el receptor RPT 230 puede recibir las tramas y procesar las tramas recibidas para detectar cualesquiera DDFs que puedan estar presentes.
La figura 3 ilustra una realización de un método 300 de encapsulación de mensajes CFM que puede utilizarse para encapsular tramas de datos en mensajes CFM. Por ejemplo, el método 300 de encapsulación de mensajes CFM puede ser utilizado por el RR 120 para encapsular las tramas en RMFs o por el originador SFM 210 para encapsular las tramas en SFMs. Las tramas pueden tener cualquier tamaño, que puede exceder o no de un tamaño de valor máximo (MVS) de un campo de valor en el valor de longitud de tipo (TLV) del mensaje CFM, y pueden encapsularse sin truncación ni supresión de una porción del contenido de las tramas. En una realización el método 300 de encapsulación de mensajes CFM puede utilizarse para encapsular unidades de datos de protocolo MAC (MPDUs) que pueden tener un tamaño mayor que el MVS.
En el bloque 310 el método 300 de encapsulación de mensajes CFM puede obtener la siguiente trama para encapsulación, por ejemplo de una cola o una memoria intermedia. En el bloque 320 el método 300 de encapsulación de mensajes CFM puede determinar si el tamaño de la trama es mayor que el MVS, el cual puede ser igual a aproximadamente 1500 bytes. Si el tamaño de la trama es menor o igual que el MVS, el método 300 de encapsulación de mensajes CFM puede pasar al bloque 330. En caso contrario, el método 300 de encapsulación de mensajes CFM puede pasar al bloque 335.
En el bloque 330 el método 300 de encapsulación de mensajes CFM puede encapsular el contenido de la trama en un mensaje CFM. En una realización el método 300 de encapsulación de mensajes CFM puede ajustar el valor de un campo de tipo en el TLV del mensaje CFM haciéndolo igual a, por ejemplo, tres para indicar que la trama está completamente encapsulada en el mensaje CFM sin truncación ni partición en mensajes CFM adicionales. El mensaje CFM puede ser enviado entonces a su destino, por ejemplo utilizando una trama de mensaje CFM, tal como se describe con mayor detalle más abajo, y el método 300 de encapsulación de mensajes CFM puede retornar al bloque 310. Como alternativa, en el bloque 335 el método 300 de encapsulación de mensajes CFM puede determinar si la truncación de la trama es una opción seleccionada. La trama puede ser truncada para reducir su tamaño a un valor inferior o igual al MVS suprimiendo o retirando parte del contenido de la trama. Si la truncación de la trama es una opción seleccionada, por ejemplo decidida por el administrador o el proveedor de servicios, el método 300 de encapsulación de mensajes CFM puede pasar al bloque 340. En caso contrario, el método 300 de encapsulación de mensajes CFM puede pasar al bloque 345.
En el bloque 340 el método 300 de encapsulación de mensajes CFM puede encapsular una porción truncada de la trama en un mensaje CFM. La porción truncada puede tener un tamaño menor o igual que el MVS. En una realización el método 300 de encapsulación de mensajes CFM puede ajustar el valor del campo de tipo en el TLV del mensaje CFM haciéndolo igual a, por ejemplo, nueve para indicar que una porción truncada de la trama está encapsulada en el mensaje CFM. El mensaje CFM puede ser enviado después a su destino, por ejemplo utilizando una trama de mensaje CFM, y el método 300 de encapsulación de mensajes CFM puede retornar al bloque 310. Como alternativa, en el bloque 345 el método 300 de encapsulación de mensajes CFM puede encapsular una primera porción de la trama en un primer mensaje CFM, que puede tener un tamaño menor o igual que el MVS. En el bloque 350 el método 300 de encapsulación de mensajes CFM puede encapsular una segunda porción de la trama en un segundo mensaje CFM, que puede ter también un tamaño menor o igual que el MVS. En una realización el primer mensaje CFM y el segundo mensaje CFM combinados pueden comprender el contenido completo de la trama sin truncación ni porciones ausentes.
Además, el valor del campo de tipo puede ajustarse haciéndolo igual a, por ejemplo, diez en el primer mensaje CFM para indicar que el primer mensaje CFM comprende la primera porción de la trama, e igual a, por ejemplo, once en el segundo mensaje CFM para indicar que el segundo mensaje CFM comprende la segunda porción de la trama. Adicionalmente, se puede ajustar un campo de identificador de transacción (TID) en el primer mensaje CFM para indicar que el mensaje es el primer mensaje CFM en una secuencia de dos o más mensajes CFM, y en el segundo mensaje CFM para indicar que el mensaje es el segundo mensaje CFM en la secuencia de mensajes. Por ejemplo, los valores de los campos TID en el primer mensaje CFM y en el segundo mensaje CFM pueden ser iguales (por ejemplo, ambos ajustados a N, en donde N es un número entero), o el valor del campo TID en el segundo mensaje CFM puede ser mayor en uno (por ejemplo, N+1) que el valor del campo TID en el primer mensaje CFM (por ejemplo, N). El primer mensaje CFM y el segundo mensaje CFM pueden ser enviados a su destino, por ejemplo utilizando tramas de mensajes CFM, y el método 300 de encapsulación de mensajes CFM puede retornar al bloque
310.
La figura 4 muestra una realización de una máquina de estado 400 de encapsulación de mensajes CFM que puede ser utilizada por el RR 120 o el originador SFM 210 para encapsular las tramas en RFMs. La máquina de estado 400 de encapsulación de mensajes CFM puede comprender una pluralidad de estados similares a los estados descritos en el estándar IEEE 802.1Qaw. Específicamente, si la trama de datos recibida hace que la trama encapsulada RFM exceda del tamaño de la unidad de datos de servicio máxima, se tiene que la trama de datos está truncada o bien la trama de datos está dividida en dos tramas más pequeñas y esas dos tramas más pequeñas están encapsuladas por dos tramas RFM separadas. La máquina de estado 400 de encapsulación de mensajes CFM puede detectar también una banderola de truncación. Si se establece que la banderola de truncación es verdadera, la trama de datos deberá ser truncada y encapsulada en una trama RFM.
La máquina de estado 400 de encapsulación de mensajes CFM puede ser iniciada en un estado 410 de encapsulación RR desactivada (RR_ENCAP_DES). Durante el estado RR_ENCAP_DES 410 se puede inicializar un parámetro ListanTramasfiltradas, por ejemplo se le puede ajustar a un valor igual aproximadamente cero. El parámetro ListanTramasfiltradas puede ser una variable que sigue la pista del número de tramas de datos filtradas a encapsular o reflejar por el RR. Esta variable es incrementada por un filtro RR y decrementada por la máquina de estado 400 de encapsulación de mensajes CFM. Cuando la variable ListanTramasfiltradas no es cero, la máquina de estado 400 de encapsulación de mensajes CFM puede pasar a un estado 420 pendiente de encapsulación RR (RR_ENCAP_ESPERA), por ejemplo utilizando un procedimiento de transferencia incondicional (UCT). Durante el estado RR_ENCAP_ESPERA 420 se puede obtener la siguiente trama de datos y la máquina de estado 400 de encapsulación de mensajes CFM puede pasar entonces a un estado de encapsulación RR (RR_ENCAP) 430.
Durante el estado RR_ENCAP 430 se puede implementar un procedimiento procesRRencap(). Específicamente, el procesRRencap() puede ser reclamado cuando se activa RR y no está vacía la ListaTramasfiltradas. Puede haber dos variables locales en este procedimiento: TramaDatos_1 y TramaDatos_2, que pueden utilizarse cuando la trama filtrada ha de ser truncada o dividida en dos tramas que deben ser reflejadas. En una realización procesRRencap() procesa la trama de datos entrante del filtro RR como sigue:
a) Ajustar la LongitudDatosreflejada a la longitud de la TramaFiltradasiguiente;
b) Si el valor de LongitudDatosreflejada es mayor que el TamañovalorTLVDatosmax del puente descrito con mayor detalle más abajo, se reclama entonces la TramaFiltradadividida (TramaFiltradasiguiente, TramaDatos_1, TramaDatos_2) y se ejecutan luego los dos pasos siguientes:
1) Si está ajustada una bandera de truncación, se reclama construirRFM (tipoTLVDatosTruncados, TamañovalorTLVDatosmax, TramaDatos_1), en donde el tipoTLVDatosTruncados se ajusta al valor de tipo “TLV de Datos Truncados” definido por la Tabla 1;
2) Si no se ajusta la banderola de truncación, se ejecutan los dos pasos siguientes:
-
ConstruirRFM (tipoTLVParte1Datos, TamañovalorTLVDatosmax, TramaDatos_1), en donde el tipoTLVParte1Datos se ajusta al valor de tipo “TLV Parte 1 de Datos” definido por la Tabla 1;
-
ConstruirRFM (tipoTLVParte2Datos, LongitudDatosreflejada - TamañovalorTLVDatosmax, TramaDatos_2), en donde el TipoTLVParte2Datos se ajusta al valor de tipo “TLV Parte 2 de Datos” definido por la Tabla 1;
c) En caso contrario, se reclama construirRFM (TipoTLVDatos, LongitudDatosreflejada, TramaFiltradasiguiente), en donde TipoTLVDatos se ajusta al valor de tipo “TLV de Datos” definido por la Tabla 1.
El procedimiento TramaFiltradadividida es reclamado cuando la TramaFiltradasiguiente hace que la longitud del tamaño de la unidad de datos de servicio del RFM sea mayor que el tamaño de la unidad de datos de servicio máxima. Hay tres parámetros para este procedimiento:
a) TramaFiltradasiguiente, que es una entrada al procedimiento;
b) TramaDatos_1, que contiene el primer número de bytes TamañovalorTLVDatosmax proveniente de la TramaFiltradasiguiente;
c) TramaDatos_2, que contiene los bytes restantes de la TramaFiltradasiguiente.
El procedimiento de TramaFiltradadividida() ejecuta los pasos siguientes:
a) Copiar el número de bytes TamañovalorTLVDatosmax proveniente de la TramaFiltradasiguiente en TramaDatos_1; y
b) Copiar los bytes restantes de la TramaFiltradasiguiente en TramaDatos_2.
Después de implementar el procedimiento procesRRencap() se puede decrementar en aproximadamente uno la ListanTramasFiltradas.
La máquina de estado 400 de encapsulación de mensajes CFM puede reiniciar el estado RR_ENCAP 430 si la ListanTramasFiltradas no es igual a aproximadamente cero. En caso contrario, la máquina de estado 400 de encapsulación de mensajes CFM puede retornar al estado RR_ENCAP_DES 410.
La figura 5 ilustra una realización de un método 500 de desencapsulación de mensajes CFM que puede utilizarse para desencapsular el contenido de las tramas de datos originalmente encapsuladas proveniente de los mensajes CFM recibidos. Por ejemplo, el método 500 de desencapsulación de mensajes CFM puede ser utilizado por el receptor RFM 130 para desencapsular los RFMs o por el DR 220 para desencapsular los SFMs. En una realización los datos desencapsulados pueden corresponder a un contenido de unidades de datos de protocolo MAC (NPDUs) encapsulado en los mensajes CFM. En otra realización de un esquema FPT el TLV de datos reflejados en RFM es un TLV de datos que contiene la trama de datos reflejada. Por tanto, el campo de longitud son los octetos totales de la trama de datos reflejada. El campo de tipo del TLV de datos reflejados podría ser uno de los cuatro valores de la Tabla 1:
Tipo
Valor
TLV de Datos
3
TLV de Datos Truncados
9
Tipo TLV Parte 1 de Datos
10
Tipo TLV Parte 2 de Datos
11
Tabla 1
En el bloque 510 el método 500 de desencapsulación de mensajes CFM puede obtener el siguiente mensaje CFM para desencapsulación, por ejemplo de una cola o una memoria intermedia. En el bloque 520 el método 500 de 5 desencapsulación de mensajes CFM puede determinar si el mensaje CFM comprende una trama completa o una trama truncada. Por ejemplo, el método 500 de desencapsulación de mensajes CFM puede determinar si el valor del campo de tipo en el TLV del mensaje CFM es igual a tres o nueve. Si se encuentra que el mensaje CFM comprende una trama completa o una trama truncada, el método 500 de desencapsulación de mensajes CFM puede pasar al bloque 525; en caso contrario, el método 500 de desencapsulación de mensajes CFM puede pasar al bloque 540. 10 En el bloque 525 el método 500 de desencapsulación de mensajes CFM puede desencapsular la porción truncada de la trama del mensaje CFM. Además, el método 500 de desencapsulación de mensajes CFM puede descartar cualquier mensaje CFM previamente puesto en cola, tal como una primera parte de dos mensajes CFM asociados, que pueda ser previamente recibido. Por ejemplo, el contenido de la trama truncada puede obtenerse en el campo de valor del TLV de los mensajes CFM. El método 500 de desencapsulación de mensajes CFM puede retornar
15 después al bloque 510.
En el bloque 540 el método 500 de desencapsulación de mensajes CFM puede determinar si el mensaje CFM es un primer mensaje CFM en una secuencia de dos mensajes CFM; un primer mensaje CFM y un segundo mensaje CFM, cada uno de los cuales contiene una porción del contenido de la trama original. El primer mensaje CFM y el segundo mensaje CFM pueden comprender el contenido completo de una trama original, que puede tener un
20 tamaño mayor que el MVS. Por ejemplo, el método 500 de desencapsulación de mensajes CFM puede determinar si el valor del campo de tipo en el mensaje CFM es igual a, por ejemplo, diez, lo que puede indicar un mensaje de tipo PARTE 1. Si se encuentra que el mensaje CFM comprende la primera porción de la trama, por ejemplo si el mensaje CFM es un primer mensaje CFM, el método 500 de desencapsulación de mensajes CFM puede pasar al bloque 545; en caso contrario, el método 500 de desencapsulación de mensajes CFM puede pasar al bloque 550.
25 En el bloque 545 el método 500 de desencapsulación de mensajes CFM puede añadir el primer mensaje CFM a una cola. Además, el método 500 de desencapsulación de mensajes CFM puede descartar cualquier primer mensaje CFM previamente puesto en cola que pueda ser recibido previamente. El método 500 de desencapsulación de mensajes CFM puede retornar entonces al bloque 510. Como alternativa, en el bloque 550 el método 500 de desencapsulación de mensajes CFM puede determinar si el primer mensaje CFM previamente recibido está en cola
30 y si el mensaje CFM es un segundo mensaje CFM asociado con el primer mensaje CFM. Por ejemplo, el mensaje CFM puede ser un segundo mensaje CFM si el campo de tipo del mensaje CFM es igual a, por ejemplo, once, lo que puede indicar un mensaje de tipo PARTE 2. Además, el segundo mensaje CFM puede asociarse con un primer mensaje CFM puesto en cola si el campo TID del segundo mensaje CFM es mayor que el campo TID del primer mensaje CFM en aproximadamente uno. Si el segundo mensaje CFM está asociado con un primer mensaje CFM en
35 cola, el método 500 de desencapsulación de mensajes CFM puede pasar al bloque 560; en caso contrario, el método 500 de desencapsulación de mensajes CFM puede pasar al bloque 570.
En el bloque 560 el método 500 de desencapsulación de mensajes CFM puede desencapsular y combinar las tramas del primer mensaje CFM en cola y del segundo mensaje CFM, las cuales pueden comprender porciones de la misma trama original. Por tanto, se puede obtener el contenido completo o al menos parte del contenido de la
40 trama original. El método 500 de desencapsulación de mensajes CFM puede retornar después al bloque 510. Como alternativa, en el bloque 570 el método 500 de desencapsulación de mensajes CFM puede descartar el mensaje CFM y cualquier primer mensaje CFM en cola, y puede retornar después al bloque 510.
En algunas realizaciones el contenido de la trama original puede tener un tamaño mayor que el MVS y puede no encajar enteramente en dos mensajes CFM que tengan un tamaño menor o igual que aproximadamente el MVS. Por 45 consiguiente, se puede partir la trama utilizando más de dos mensajes CFM. Por ejemplo, en lugar de solamente un primer mensaje, por ejemplo un mensaje de tipo PARTE 1, y un segundo mensaje CFM, por ejemplo un mensaje de tipo PARTE 2, se puede encapsular la trama utilizando una pluralidad de mensajes de tipo PRIMERO_O_MEDIO y un mensaje de tipo ÚLTIMO. Específicamente, el campo de tipo del mensaje CFM puede ser utilizado para indicar el tipo de mensaje. Además, los mensajes CFM pueden asociarse uno con otro, por ejemplo utilizando una secuencia 50 de valores TID consecutivos, tal como una secuencia consecutiva de números enteros que especifiquen el orden de
los mensajes CFM. Como alternativa, los mensajes CFM pueden asociarse uno con otro utilizando el mismo valor TID y una pluralidad de valores de tipo que especifiquen el orden de los mensajes CFM. Además, en algunos casos se puede limitar la cantidad de mensajes CFM que pueden utilizarse para partir una sola trama. Por tanto, se puede partir al menos alguna porción de la trama y se puede truncar la porción restante. En algunas realizaciones una pluralidad de tramas o porciones de trama, que pueden tener un tamaño combinado inferior al MVS, pueden combinarse y encapsularse utilizando un solo mensaje CFM para mejorar la utilización del ancho de banda en esquemas DDCFM. Se puede desencapsular después el mensaje CFM en el lado del receptor para obtener el contenido de las tramas individuales.
La figura 6 ilustra una realización de una trama de mensaje CFM 600 que puede utilizarse para reenviar un mensaje CFM, tal como un RFM o un SFM, por ejemplo en el sistema DDCFM 100 o en el sistema DDCFM 200. Por ejemplo, la trama de mensaje CFM 600 puede comprender un RFM que puede ser encapsulado por el RR en el nodo intermedio 120, o un SFM que puede ser encapsulado por el originador SFM en el nodo de origen 210. Específicamente, la trama de mensaje CFM 600 puede comprender una dirección de destino (DA) 610, una dirección de origen (SA) 620, un campo de etiqueta 630, un campo de tipo CFM 640, un mensaje CFM 650 y un campo de suma de verificación de trama (FCS) 670.
La DA 610 puede comprender la dirección de la red o la dirección MAC del nodo de destino, por ejemplo el nodo diana 130 o el nodo de destino 230. La SA 620 puede comprender la dirección de la red o la dirección MAC del nodo que genera la trama original, por ejemplo el nodo de origen 110 o el nodo de origen 210. En algunas realizaciones la dirección de los nodos de origen puede ser sustituida por la dirección de los nodos de encapsulación, por ejemplo el nodo intermedio 120 o el nodo intermedio 220. El campo de etiqueta 630 puede comprender un identificador de protocolo de etiqueta (TPID) 632 que puede utilizarse para identificar el tipo de protocolo utilizado para transportar la trama de mensaje CFM 600, y una prioridad (PRI)/VLAN ID (VID) 634 que puede utilizarse para indicar el nivel de prioridad y/o la VLAN asociados con la trama de mensaje CFM 600. El campo de tipo CFM 640 puede indicar la presencia de un mensaje CFM en la trama de mensaje CFM 600. Por ejemplo, el campo de tipo CFM 640 puede ser igual a aproximadamente 8102 según el estándar IEEE 802.1Qaw, el cual se incorpora aquí por referencia en su totalidad. El campo FCS 670 puede utilizarse para detectar errores de bits en la trama de mensaje CFM 600. En una realización cada una de la DA 610 y SA 620 puede tener un tamaño igual a aproximadamente seis bytes, cada uno de TPID 632, PRI/VID 634 y el campo de tipo CFM 640 puede tener un tamaño igual a aproximadamente 2 bytes y el campo FCS 670 puede tener un tamaño igual a aproximadamente cuatro bytes.
El mensaje CFM 650 puede comprender una cabecera CFM 652, un TID 654, un TLV de datos 656 y, opcionalmente, al menos un TLV adicional 664. La cabecera CFM 652 puede indicar si el mensaje CFM es un RFM
o un SFM. Por ejemplo, la cabecera CFM 652 puede comprender un código de operación (códigoop) igual a, por ejemplo, seis para indicar un RFM o a, por ejemplo, siete para indicar un SFM. El TID 654 puede indicar la secuencia del mensaje CFM en una pluralidad de mensajes CFM transmitidos. El TLV de datos 656 puede comprender un campo de tipo 658 que puede indicar si el contenido de datos CFM está enteramente incluido, truncado o partido, un campo de longitud 660 que puede indicar la longitud del TLV de datos 656 o del mensaje CFM 650, y un campo de valor 662 que puede comprender el contenido de datos CFM. En una realización la cabecera CFM 652 puede tener un tamaño igual a aproximadamente cinco bytes, el TID 654 puede tener un tamaño igual a aproximadamente cuatro bytes, el campo de tipo 658 puede tener un tamaño igual a aproximadamente un byte y el campo de longitud 660 puede tener un tamaño igual a aproximadamente dos bytes.
En una realización el mensaje CFM puede ser una trama Ethernet que puede ser generada en la capa MAC, por ejemplo en el nodo intermedio 120 o en el nodo de origen 210, tal como una unidad de datos de servicio MAC (MSDU). Por tanto, el tamaño máximo del mensaje CFM puede ser limitado por un tamaño de unidad de transmisión máxima (MTU) de la MSDU. Por ejemplo, el tamaño MTU puede ser igual a aproximadamente 1500 bytes basándose en el estándar IEEE 802.3. En otras realizaciones algunos nodos, tales como puentes o conmutadores, pueden soportar tamaños de trama que pueden ser mayores que aproximadamente 1500 bytes, por ejemplo las tramas Jumbo pueden ser de hasta 9000 bytes. Además, el tamaño del mensaje CFM puede ser igual al tamaño total de sus campos, por ejemplo la cabecera CFM 652, el TID 654, el TLV de datos 656 y cualesquiera TLVs adicionales 664. Por tanto, el tamaño del mensaje CFM puede ser igual a aproximadamente 12 bytes, además del tamaño del campo de valor 662 y el tamaño de los TLVs adicionales 664. Dado que el tamaño del mensaje CFM puede ser limitado por la MTU, el tamaño del campo de valor 662 puede ser limitado también por un MVS. Por tanto, el MVS puede ser igual al tamaño MTU menos aproximadamente 12 bytes y el tamaño de los TLVs adicionales 664, que se denomina aquí A, en donde A es un número entero. Por ejemplo, en el caso en el que el tamaño MTU es igual a aproximadamente 1500 bytes, el MVS para TLV de datos puede ser igual a aproximadamente 1500 - (12 + A) bytes o aproximadamente 1488 - A bytes para tramas Ethernet normales y aproximadamente 8988 - A bytes para tramas Ethernet Jumbo.
En una realización el MVS puede ser un TamañovalorTLVDatosmax, como se describe en IEEE 802.1Qaw. El TamañovalorTLVDatosmax es el número máximo de bytes que se permite que sea copiado en el campo de valor del TLV de datos reflejados con el fin de impedir que el tamaño de la unidad de datos de servicio del RFM exceda de su tamaño MSDU (MSDUS). Por tanto, la unidad de datos de protocolo (PDU) de RFM consta de una cabecera CFM de cinco bytes comunes (4 bytes para la cabecera CFM + 1 byte para TLV(0) final), un identificador de transacción de 4 bytes, un campo de tipo/longitud de TLV de datos reflejados de 3 bytes, y un número real de bytes de la trama de datos reflejada. Si no hay otro TLV opcional para la trama de datos RFM, se tiene entonces que el TamañovalorTLVDatosmax = MSDUS - (5 (longitud de cabecera común CFM) + 4 (identificador de transacción) + 3 (tipo/longitud de TLV de trama de datos reflejada)).
En una realización la trama de mensaje CFM 600 puede utilizarse para encapsular una trama, tal como una MPDU, que puede tener un tamaño mayor o igual que aproximadamente 64 bytes. El tamaño de la MPDU puede variar, por ejemplo debido a la presencia o la ausencia de campos de etiqueta que pueden ser conocidos para la capa de transporte MAC. Además, si está completamente ocupada la porción de datos de la MPDU, el tamaño MPDU puede ser mayor o igual que aproximadamente 1518 bytes. Por tanto, el tamaño de la MPDU puede exceder del MVS (por ejemplo, aproximadamente 1488 - A bytes) del campo de valor 662. Por consiguiente, se puede troncar la porción de datos de la MPDU para encapsular las porciones restantes en la trama de mensaje CFM 600, por ejemplo como se describe en el estándar IEEE 802.Qaw. Sin embargo, la utilización de las tramas truncadas para DDCFM puede ser difícil o puede no ser adecuada.
Los componentes de red descritos anteriormente pueden implementarse en cualquier componente de red de uso general, tal como un ordenador o un componente de red con suficiente potencia de procesamiento, recursos de memoria y capacidad de rendimiento de red para manipular la carga de trabajo necesaria impuesta sobre él. La figura 7 ilustra un componente de red típico 700 de uso general adecuado para implementar una o más realizaciones de los componentes descritos en esta memoria. El componente de red 700 incluye un procesador 702 (que puede denominarse unidad procesadora central o CPU) que está en comunicación con dispositivos de memoria que incluyen una memoria secundaria 704, una memoria de solo lectura (ROM) 706, una memoria de acceso aleatorio (RAM) 708, dispositivos de entrada/salida (I/O) 710 y dispositivos de conectividad de red 712. El procesador 702 puede implementarse como uno o más chips CPU o puede ser parte de uno o más circuitos integrados de aplicaciones específicas (ASICs).
La memoria secundaria 704 está compuesta típicamente de una o más unidades de disco o unidades de cinta y se utiliza para el almacenamiento no volátil de datos y como dispositivo de almacenamiento de datos por desbordamiento si la RAM 708 no es lo bastante grande como para contener todos los datos de trabajo. La memoria secundaria 704 puede utilizarse para almacenar programas que se cargan en la RAM 708 cuando se seleccionan tales programas para su ejecución. La ROM 706 se utiliza para almacenar instrucciones y quizás datos que se leen durante la ejecución de un programa. La ROM 706 es un dispositivo de memoria no volátil que tiene típicamente una pequeña capacidad de almacenamiento con relación a la mayor capacidad de almacenamiento de la memoria secundaria 704. La RAM 708 se utiliza para almacenar datos volátiles y quizás para almacenar instrucciones. El acceso a la ROM 706 y a la RAM 708 es en ambos casos típicamente más rápido que el acceso a la memoria secundaria 704.
Se ha descrito al menos una realización, y las variaciones, combinaciones y/o modificaciones de la realización o realizaciones y/o las características de la realización o realizaciones hechas por una persona dotada de conocimientos ordinarios en la materia caen dentro del alcance de la descripción. Realizaciones alternativas que resultan de combinar, integrar y/u omitir características de la realización o realizaciones caen también dentro del alcance de la descripción. Aunque se indican expresamente rangos o limitaciones numéricos, tales rangos o limitaciones expresos deberán entenderse como incluyendo rangos o limitaciones iterativos de igual magnitud que caigan dentro de los rangos o limitaciones expresamente indicados (por ejemplo, de aproximadamente 1 a aproximadamente 10 incluye 2, 3, 4, etc.; mayor que 0,10 incluye 0,11, 0,12, 0,13, etc.). Por ejemplo, siempre que se revele un rango numérico con un límite inferior, Ri, y un límite superior, Ru, se revela específicamente cualquier número que caiga dentro del rango. En particular, se revelan específicamente los números siguientes dentro del rango: R = Ri + k * (Ru-Ri), en donde k es una variable que va de 1 por ciento a 100 por ciento con un incremento de 1 por ciento, es decir, k es 1 por ciento, 2 por ciento, 3 por ciento, 4 por ciento, 5 por ciento, …, 50 por ciento, 51 por ciento, 52 por ciento, …, 95 por ciento, 96 por ciento, 97 por ciento, 98 por ciento, 99 por ciento o 100 por ciento. Además se revela específicamente también cualquier rango numérico definido por dos números R según se han definido en lo que antecede. El uso del término “opcionalmente” con respecto a cualquier elemento de una reivindicación significa que se requiere el elemento o, alternativamente, que no se requiere el elemento, estando ambas alternativas dentro del alcance de la reivindicación. El uso de términos más amplios tales como comprende, incluye o que tiene deberá entenderse que proporciona soporte a términos más estrechos tales como consistente en, consistente esencialmente en y compuesto sustancialmente de. Por consiguiente, el alcance de protección no queda limitado por la descripción expuesta anteriormente, sino que es definido por las reivindicaciones que siguen, incluyendo ese alcance todos los equivalentes de la materia objeto de las reivindicaciones. Todas y cada una de las reivindicaciones se incorporan como descripción adicional en la memoria y las reivindicaciones son una realización o realizaciones de la presente descripción. La discusión de una referencia en la descripción no es una admisión de que es técnica anterior, especialmente cualquier referencia que tenga una fecha de publicación posterior a la fecha de prioridad de esta solicitud. La descripción de todas las patentes, solicitudes de patente y publicaciones citadas en la descripción se incorpora aquí por referencia en la medida en que estas proporcionan detalles de ejemplos, procedimientos y otros detalles suplementarios de la descripción.
Aunque se han proporcionado varias realizaciones en la presente descripción, deberá entenderse que los sistemas y métodos revelados podrían materializarse en muchas otras formas específicas sin apartarse del alcance de la presente descripción. Los presentes ejemplos han de considerarse como ilustrativos y no restrictivos, y la invención
5 no ha de limitarse a los detalles que se han dado en esta memoria. Por ejemplo, los diversos elementos o componentes pueden combinarse o integrarse en otros sistemas o bien pueden omitirse o no implementarse ciertas características.
Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como discretos o separados pueden combinarse o integrarse con otros sistemas, módulos, técnicas o métodos sin
10 apartarse del alcance de la presente descripción. Otros elementos mostrados o discutidos como acoplados o directamente acoplados o comunicándose uno con otro pueden acoplarse o comunicarse indirectamente a través de alguna interfaz, dispositivo o componente intermedio, sea por vía eléctrica, mecánica u otra. Otros ejemplos de cambios, sustituciones y alteraciones pueden ser averiguados por un experto en la materia y podrían realizarse sin apartarse del alcance revelado en esta memoria.

Claims (8)

  1. REIVINDICACIONES
    1. Un método que comprende:
    recibir una trama de datos;
    caracterizado porque:
    si la trama de datos recibida hace que un mensaje de gestión de defecto de conectividad, CFM, exceda de un tamaño de unidad de datos de servicio máxima, MSDUS, y
    si se establece que una banderola de truncación es verdadera, truncar la trama de datos y encapsular las porciones restantes en un mensaje de gestión de defecto de conectividad, CFM; en caso contrario, dividir la trama de datos en dos tramas más pequeñas y encapsular esas dos tramas más pequeñas por medio de dos mensajes CFM separados.
  2. 2.
    El método según la reivindicación 1, que comprende además:
    si la trama de datos recibida no hace que el mensaje CFM exceda de un tamaño de unidad de datos de servicio máxima, encapsular toda la trama de datos en un mensaje CFM.
  3. 3.
    El método según la reivindicación 1, que comprende además:
    obtener el mensaje CFM que encapsula las porciones truncadas de la trama, o los dos mensajes CFM separados;
    determinar si el mensaje CFM recibido comprende una trama truncada; y
    desencapsular la porción truncada de la trama del mensaje CFM y descartar cualquier mensaje CFM previamente en cola si se encuentra que el mensaje CFM comprende una trama truncada.
  4. 4.
    El método según la reivindicación 1, en el que el mensaje CFM (650) está contenido en una trama de mensaje CFM (600), y el mensaje CFM comprende una cabecera CFM (652), un identificador de transacción TID (654) y un valor de longitud de tipo de datos, TLV, (656); en el que la cabecera CFM (652) indica si el mensaje CFM es un mensaje de trama reflejada, RFM, o un mensaje de envío de trama, SFM;
    en el que el TLV de datos (656) comprende un campo de tipo (658) que indica si el contenido de datos CFM está enteramente incluido, truncado o partido, un campo de longitud (660) que indica la longitud del TLV de datos (656) o del mensaje CFM (650), y un campo de valor (662) que comprende el contenido de datos CFM.
  5. 5.
    El método según la reivindicación 4, en el que, si la trama de datos es una trama de datos reflejada, el mensaje CFM que encapsuló la trama de datos es un mensaje RFM, y el método comprende además:
    determinar un número máximo de bytes que se permite que sea copiado en un campo de valor del TLV de datos reflejados a fin de impedir que el tamaño de la unidad de datos de servicio del mensaje de trama reflejada (RFM) exceda de su tamaño de unidad de datos de servicio máxima (MSDUS),
    en el que, si no hay otro TLV opcional para una trama de datos RFM, entonces un tamaño de valor de TLV de datos máximo (TamañovalorTLVDatosmax) es igual a MSDUS menos una longitud de cabecera común CFM más una longitud de identificador de transacción más una longitud de campo de tipo/longitud de TLV de trama de datos reflejada.
  6. 6. Un componente de red (700) que comprende un procesador (702) configurado para implementar un método de utilización de gestión de defectos de conectividad, CFM, para soportar el diagnóstico de un defecto de conectividad, comprendiendo el método:
    recibir una trama de datos;
    caracterizado porque:
    si la trama de datos recibida hace que el mensaje CFM exceda de un tamaño de unidad de datos de servicio máxima, MSDUS, y
    si se establece que una banderola de truncación es verdadera, truncar la trama de datos y encapsular las porciones restantes en un mensaje de gestión de defecto de conectividad, CFM, contenido en una trama de mensaje CFM; en caso contrario, dividir la trama de datos en dos tramas más pequeñas y encapsular esas dos tramas más pequeñas por medio de dos mensajes CFM separados.
  7. 7.
    El componente de red (700) según la reivindicación 6, que comprende además:
    si la trama de datos recibida no hace que el mensaje CFM exceda de un tamaño de unidad de datos de servicio máxima, encapsular toda la trama de datos en un mensaje CFM.
  8. 8.
    El componente de red (700) según la reivindicación 6, que comprende además: obtener el mensaje CFM que encapsuló las porciones truncadas de la trama, o los dos mensajes CFM separados; determinar si el mensaje CFM recibido comprende una trama truncada; y desencapsular la porción truncada de la trama del mensaje CFM y descartar cualquier mensaje CFM previamente en
    cola si se encuentra que el mensaje CFM comprende una trama truncada.
ES09730303T 2008-04-08 2009-04-08 Encapsulación de tramas ethernet grandes. Active ES2374375T3 (es)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US415735 1995-04-03
US4315708P 2008-04-08 2008-04-08
US43157P 2008-04-08
US12/415,735 US8005113B2 (en) 2008-04-08 2009-03-31 Encapsulating large Ethernet frames
PCT/CN2009/071190 WO2009124500A1 (en) 2008-04-08 2009-04-08 Encapsulating large ethernet frames

Publications (1)

Publication Number Publication Date
ES2374375T3 true ES2374375T3 (es) 2012-02-16

Family

ID=41133231

Family Applications (1)

Application Number Title Priority Date Filing Date
ES09730303T Active ES2374375T3 (es) 2008-04-08 2009-04-08 Encapsulación de tramas ethernet grandes.

Country Status (7)

Country Link
US (2) US8005113B2 (es)
EP (2) EP2232780B1 (es)
CN (1) CN102037687B (es)
AT (1) ATE532294T1 (es)
DK (1) DK2232780T3 (es)
ES (1) ES2374375T3 (es)
WO (1) WO2009124500A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8005113B2 (en) * 2008-04-08 2011-08-23 Futurewei Technologies, Inc. Encapsulating large Ethernet frames
CN102843345B (zh) * 2011-06-24 2015-07-22 中磊电子（苏州）有限公司 远程沟通方法及其计算机程序产品
CN102595495A (zh) * 2012-02-07 2012-07-18 北京新岸线无线技术有限公司 一种数据发送、接收方法和装置
US9438502B2 (en) 2012-02-17 2016-09-06 Viavi Solutions Inc. Controlling generation of filtered result packets
CN103378985B (zh) * 2012-04-26 2017-12-29 中兴通讯股份有限公司 数据驱动的故障检测方法、反射应答器和反射目的地设备
EP3075134B1 (en) * 2013-11-26 2019-01-09 Telefonaktiebolaget LM Ericsson (publ) A method and system of supporting service chaining in a data network
US10222454B2 (en) * 2014-08-19 2019-03-05 Navico Holding As Combining Reflected Signals
US11201780B2 (en) * 2016-01-29 2021-12-14 Qualcomm Incorporated Configurations associated with segmentation of one or more packets for wireless communication

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7130303B2 (en) * 2001-03-15 2006-10-31 Lucent Technologies Inc. Ethernet packet encapsulation for metropolitan area ethernet networks
US6717950B2 (en) * 2002-01-20 2004-04-06 General Instrument Corporation Method and apparatus for priority-based load balancing for use in an extended local area network
JP2003309595A (ja) * 2002-04-12 2003-10-31 Fujitsu Ltd ネットワークにおけるルーチング装置およびルーチング方法
US20050220091A1 (en) * 2004-03-31 2005-10-06 Lavigne Bruce E Secure remote mirroring
US7474619B2 (en) 2004-07-22 2009-01-06 International Business Machines Corporation Method and apparatus for providing fragmentation at a transport level along a transmission path
KR100918435B1 (ko) 2005-01-31 2009-09-24 삼성전자주식회사 무선 통신 시스템에서 데이터 트래픽 제어 시스템 및 방법
US20070268918A1 (en) * 2006-05-22 2007-11-22 Marvell International Ltd. Packet tunneling for wireless clients using maximum transmission unit reduction
US7768928B2 (en) * 2006-07-11 2010-08-03 Corrigent Systems Ltd. Connectivity fault management (CFM) in networks with link aggregation group connections
CN101179479A (zh) * 2006-11-09 2008-05-14 华为技术有限公司 一种以太网的操作管理和维护报文的传输方法、系统和节点
JP4790591B2 (ja) * 2006-12-27 2011-10-12 富士通株式会社 リングノード装置
US20080159150A1 (en) * 2006-12-28 2008-07-03 Furquan Ahmed Ansari Method and Apparatus for Preventing IP Datagram Fragmentation and Reassembly
JP4881791B2 (ja) * 2007-02-26 2012-02-22 京セラ株式会社 通信方法、通信システム、通信端末装置及び基地局装置
US8089967B2 (en) * 2007-04-06 2012-01-03 International Business Machines Corporation Modification of a switching table of an internet protocol switch
US9071666B2 (en) * 2007-04-26 2015-06-30 Alcatel Lucent Edge router and method for dynamic learning of an end device MAC address
US8310941B2 (en) * 2007-05-21 2012-11-13 Telefonaktiebolaget L M Ericsson (Publ) Data driven connection fault management (DDCFM) in CFM maintenance points
US8005113B2 (en) * 2008-04-08 2011-08-23 Futurewei Technologies, Inc. Encapsulating large Ethernet frames

Also Published As

Publication number Publication date
US20090252179A1 (en) 2009-10-08
DK2232780T3 (da) 2012-01-23
EP2232780A1 (en) 2010-09-29
EP2403190B1 (en) 2015-02-18
EP2232780A4 (en) 2011-01-19
EP2232780B1 (en) 2011-11-02
CN102037687B (zh) 2014-05-21
WO2009124500A1 (en) 2009-10-15
EP2403190A2 (en) 2012-01-04
ATE532294T1 (de) 2011-11-15
US8547999B2 (en) 2013-10-01
CN102037687A (zh) 2011-04-27
EP2403190A3 (en) 2012-04-18
US8005113B2 (en) 2011-08-23
US20110268124A1 (en) 2011-11-03

Similar Documents

Publication Publication Date Title
ES2374375T3 (es) Encapsulación de tramas ethernet grandes.
JP4567367B2 (ja) Ｏａｍ機能を可能にするアドレスの挿入
US7599303B2 (en) System and methods for sending trace messages
US8320374B2 (en) Method and apparatus for improved multicast routing
TWI521922B (zh) 擴展網橋之系統及其方法
CA2709467C (en) Interworking an ethernet ring network with a spanning tree controlled ethernet network
US8520540B1 (en) Remote traffic monitoring through a network
US20160352538A1 (en) Network Service Insertion
US20040003094A1 (en) Method and apparatus for mirroring traffic over a network
US20060146832A1 (en) Method and system for transporting data using pseudowire circuits over a bridged network
US20120224471A1 (en) Method and system for ring protection switching
CA2667681A1 (en) Ethernet oam at intermediate nodes in a pbt network
ES2511691T3 (es) Gestión de fallos de conexión accionados por datos (DDCFM) en puntos de mantenimiento de CFM
JP7252265B2 (ja) ネットワーク通信方法及び装置
US20120236866A1 (en) Communication system and communication device
WO2020103530A1 (zh) 通信方法和装置
US8111634B2 (en) System and method for integrating ring-protocol-compatible devices into network configurations that also include non-ring-protocol compatible devices
US20220158947A1 (en) Method and Apparatus for Processing Service Flow in Packet Network
JP2019117972A (ja) ネットワーク管理装置、ネットワークシステム、方法、及びプログラム
US11184256B2 (en) Method and device for filtering packets
WO2020119474A1 (zh) 通信方法和装置