Este documento explica cómo las tramas de Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) utilizan el byte C2 de tara de trayecto (POH) para indicar el contenido de la carga útil de la trama. Asimismo, en el documento se describe cómo las interfaces de Packet over SONET (POS) utilizan el byte C2 para indicar específicamente si la carga útil está cifrada.
No hay requisitos específicos para este documento.
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Antes de una discusión sobre el byte C2, primero debe comprender algunos fundamentos de SONET.
SONET es un protocolo de capa 1 (L1) que utiliza una arquitectura estratificada. La figura 1 muestra las tres capas de SONET, a saber, sección, línea y ruta.
Las tareas generales de sección (SOH) y las tareas generales de línea (LOH) forman las tareas generales de transporte (TOH), mientras que las POH y la carga útil real (denominada capacidad de carga útil en la figura 1) forman el Envolvente de carga útil sincrónica (SPE).
Figura 1: Las tres capas de SONET
Cada capa agrega cierta cantidad de bytes de sobrecarga a la trama SONET. Esta tabla ilustra los bytes de tara de la trama SONET:
Tara de trayecto | ||||
---|---|---|---|---|
Tara de sección | Trama A1 | Trama A2 | Trama A3 | Seguimiento J1 |
B1-BIP-8 | Circuito de transferencia E1 | Usuario E1 | B3-BIP-8 | |
Com de datos D1 | Com de datos D2 | Com de datos D3 | Etiqueta de señal C2 | |
Tara de línea | Puntero H1 | Puntero H2 | Acción Puntero H3 | Estado de la Ruta G1 |
B2-BIP-8 | K1 | K2 | Canal del usuario F2 | |
Com de datos D4 | Com de datos D5 | Com de datos D5 | Indicador H4 | |
Com de datos D7 | Com de datos D8 | Com de datos D9 | Crecimiento Z3 | |
Com de datos D10 | Com de datos D11 | Com de datos D12 | Crecimiento Z4 | |
S1/Z1 Sync Status/Growth | Crecimiento M0 o M1/Z2 REI-L | Circuito de transferencia E2 | Conexión en tandem Z5 |
Nota: La tabla muestra el byte C2 en negrita para el énfasis.
El estándar SONET define el byte C2 como la etiqueta de la señal de trayectoria. El propósito de este byte es comunicar el tipo de carga útil que el SONET Framing OverHead (FOH) encapsula. El byte C2 funciona de forma similar a los campos de encabezado Ethertype y Logical Link Control (LLC)/Subnetwork Access Protocol (SNAP) en una red Ethernet. El byte C2 permite que una sola interfaz transporte varios tipos de carga simultáneamente.
Esta tabla enumera los valores comunes para el byte C2:
Valor hex | Contenidos de SONET de carga útil |
---|---|
00 | No bromeó. |
01 | Equipado: carga útil no específica. |
02 | Tributarios virtuales (VT) dentro (valor predeterminado). |
03 | VTs en modo bloqueado (ya no se admiten). |
04 | Asignación DS3 asíncrona. |
12 | Asignación DS-4NA asíncrona. |
13 | Asignación de celdas de modo de transferencia asíncrona (ATM). |
14 | Asignación de celda de bus dual de cola distribuida (DQDB). |
15 | Asignación de interfaz de datos distribuidos de fibra asíncrona (FDDI). |
16 | IP dentro del protocolo punto a punto (PPP) con codificación. |
CF | IP dentro de PPP sin codificación. |
E1-FC | Indicador de defecto de carga útil (PDI). |
FE | Asignación de señal de prueba (consulte ITU Rec. G.707). |
FF | Señal de indicación de alarma (AIS). |
Con referencia a la tabla, las interfaces POS utilizan un valor de 0x16 o 0xCF en el byte C2 dependiendo de si la codificación estilo ATM está habilitada. RFC 2615 , que define PPP sobre SONET/SDH, exige el uso de estos valores basándose en la configuración de codificación. Así es como RFC define los valores de bytes C2:
"El valor de 22 (16 hexadecimales) se utiliza para indicar PPP con codificación X^43+ 1 [4]. Para la compatibilidad con RFC 1619 (sólo STS-3c-SPE/VC-4), si se ha configurado la codificación para desactivarla, se utiliza el valor 207 (CF hex) para que la etiqueta de la señal de ruta indique PPP sin codificación".
En otras palabras:
Si la codificación está habilitada, las interfaces POS utilizan un valor C2 de 0x16.
Si la codificación está desactivada, las interfaces POS utilizan un valor C2 de 0xCF.
La mayoría de las interfaces POS que utilizan un valor C2 predeterminado de 0x16 (22 decimales) insertan el comando pos flag c2 22 en la configuración, aunque esta línea no aparece en la configuración en ejecución porque 0x16 es el valor predeterminado. Utilice el comando pos flag c2 para cambiar el valor predeterminado.
7507-3a(config-if)#pos flag c2 ? <0-255> byte value
Utilice el comando show running-config para confirmar su modificación. El comando show controller pos da como resultado el valor de recepción. Por lo tanto, un cambio en el valor en el extremo local no cambia el valor en el resultado del comando show controller.
7507-3a#show controller pos 0/0/0 COAPS = 13 PSBF = 3 State: PSBF_state = False Rx(K1/K2): 00/00 Tx(K1/K2): 00/00 S1S0 = 00, C2 = CF
La codificación aleatoriza el patrón de 1s y 0s que se transporta en la trama SONET para evitar cadenas continuas de todos los 1s o de todos los 0s. Este proceso también satisface las necesidades de los protocolos de capa física que dependen de transiciones suficientes entre 1 y 0 para mantener la temporización.
Las interfaces POS admiten dos niveles de codificación, que se explican a continuación:
El estándar GR-253 de la Unión Internacional de Telecomunicaciones (ITU-T) define un algoritmo 1 + x6 + x7 que codifica todo menos la primera fila de SOH. No puede deshabilitar este codificador, que es adecuado cuando las tramas SONET llevan llamadas telefónicas en la carga útil.
El estándar T I.432 de la ITU define qué interfaces POS son denominadas codificación de estilo ATM. Este codificador utiliza un polinomio de 1 + x43 y es un codificador autosíncrono. Esto significa que el remitente no necesita enviar ningún estado al receptor.
Dado que una cadena relativamente simple de 0 puede llevar a un servicio de inestabilidad e interrupción de línea, Cisco recomienda que habilite la codificación de estilo ATM en todas las configuraciones, incluida la fibra oscura. En algunas tarjetas de línea del router de switch Gigabit (GSR), por ejemplo, el OC-192 POS, el comando scrambling se ha eliminado de la interfaz de línea de comandos y debe habilitar este comando. En forma predeterminada, la codificación permanece desactivada en tarjetas de línea POS de menor velocidad para compatibilidad descendente.
La codificación se realiza en hardware y no supone penalización por el rendimiento en el router. La codificación se produce directamente en el circuito integrado específico de la aplicación (ASIC) del marco en las tarjetas de línea más nuevas, como las tarjetas de línea 8/16xOC3 y 4xOC12 del GSR, o en un ASIC adyacente en las tarjetas de línea más antiguas, como el POS 4xOC3 o 1xOC12 del GSR.
La figura 2 muestra el orden de funcionamiento correcto e indica cuándo se realiza la codificación durante la transmisión.
Figura 2: El orden adecuado de funcionamiento
Cuando configura el comando pos scramble-atm, la interfaz POS se configura para utilizar la codificación estilo ATM, y el comando pos flag c2 22 se coloca en la configuración. La ejecución del comando pos flag c2 22 sin el comando pos atm-scramble simplemente configura el byte C2 en el encabezado SONET para alertar a la interfaz receptora de que la carga útil está codificada. En otras palabras, sólo el comando pos scramble-atm activa la codificación.
Si una interfaz POS de Cisco no puede aparecer o funcionar cuando se conecta a un dispositivo de otro proveedor, confirme la codificación y la configuración de la verificación por redundancia cíclica (CRC), así como el valor publicado en el byte C2. En los routers de Juniper Networks, la configuración del modo rfc-2615 establece estos tres parámetros:
Codificación activada
Valor C2 de 0x16
CRC-32
Previamente, cuando la codificación estaba activada, estos dispositivos de terceros seguían utilizando un valor C2 de valor 0xCF, que no reflejaba apropiadamente la carga útil codificada.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
01-Dec-2005 |
Versión inicial |