Questo documento spiega come i frame Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) utilizzano il byte C2 nel POH (Path OverHead) per indicare il contenuto del payload all'interno del frame. Questo documento spiega anche come le interfacce Packet over SONET (POS) utilizzano il byte C2 per indicare specificamente, se il payload è scramblato o meno.
Nessun requisito specifico previsto per questo documento.
Il documento può essere consultato per tutte le versioni software o hardware.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Prima di una discussione sul byte C2, è necessario comprendere alcuni concetti fondamentali di SONET.
SONET è un protocollo di layer 1 (L1) che utilizza un'architettura a più livelli. La Figura 1 mostra i tre livelli di SONET, ovvero sezione, linea e tracciato.
La Section OverHead (SOH) e la Line OverHead (LOH) formano il Transport OverHead (TOH), mentre il POH e il payload effettivo (indicato come Capacità di payload nella Figura 1) formano la Synchronous Payload Envelope (SPE).
Figura 1 - I tre livelli di SONET
Ogni livello aggiunge un certo numero di byte di sovraccarico al fotogramma SONET. Nella tabella seguente vengono illustrati i byte di sovraccarico del frame SONET:
Sovraccarico percorso | ||||
---|---|---|---|---|
Sovraccarico sezione | Frame A1 | Frame A2 | Frame A3 | Traccia J1 |
B1 BIP-8 | E1 Orderwire | Utente E1 | B3 BIP-8 | |
Com dati D1 | Com dati D2 | Com dati D3 | Etichetta segnale C2 | |
Costi comuni linea | Puntatore H1 | Puntatore H2 | Azione puntatore H3 | Stato percorso G1 |
B2 BIP-8 | K1 | K2 | F2 - Canale utente | |
Com dati D4 | Com dati D5 | Com dati D5 | Indicatore H4 | |
Com dati D7 | Com dati D8 | Com dati D9 | Crescita Z3 | |
Com dati D10 | D11 Data Com | Com dati D12 | Crescita Z4 | |
Sincronizzazione stato/crescita S1/Z1 | Crescita M0 o M1/Z2 REI-L | E2 Orderwire | Connessione tandem Z5 |
Nota: la tabella visualizza il byte C2 in grassetto per enfatizzare il testo.
Lo standard SONET definisce il byte C2 come etichetta del segnale di percorso. Lo scopo di questo byte è comunicare il tipo di payload incapsulato dal SONET Framing OverHead (FOH). Il byte C2 funziona in modo simile ai campi di intestazione Ethertype e LLC (Logical Link Control)/SNAP (Subnetwork Access Protocol) su una rete Ethernet. Il byte C2 consente a una singola interfaccia di trasportare più tipi di payload contemporaneamente.
Nella tabella seguente vengono elencati i valori comuni per il byte C2:
Valore esadecimale | Contenuto del payload SONET |
---|---|
00 | Non attrezzato. |
01 | Equipaggiato - payload non specifico. |
02 | Tributari virtuali (VT) all'interno (impostazione predefinita). |
03 | VT in modalità bloccata (non più supportata). |
04 | Mapping DS3 asincrono. |
12 | Mapping DS-4NA asincrono. |
13 | Mapping di celle ATM (Asynchronous Transfer Mode). |
14 | Mapping di celle DQDB (Distributed Queue Dual Bus). |
15 | Mapping FDDI (Asynchronous Fiber Distributed Data Interface). |
16 | Protocollo PPP (Point-to-Point Protocol) con scrambling. |
CF | IP all'interno di PPP senza scrambling. |
E1-FC | PDI (Payload Defect Indicator). |
FE | Test della mappatura del segnale (vedere ITU Rec. G.707). |
FF | Segnale di indicazione allarme (AIS). |
Con riferimento alla tabella, le interfacce POS utilizzano un valore di 0x16 o 0xCF nel byte C2 a seconda che lo scrambling ATM sia abilitato. La RFC 2615 , che definisce il protocollo PPP su SONET/SDH, impone l'uso di questi valori in base all'impostazione di scrambling. In questo modo l'RFC definisce i valori dei byte C2:
"Il valore di 22 (16 esadecimali) viene utilizzato per indicare PPP con scramblatura X^43+ 1 [4]. Per la compatibilità con la RFC 1619 (solo STS-3c-SPE/VC-4), se lo scrambling è stato configurato per essere disattivato, il valore 207 (CF hex) viene utilizzato per l'etichetta del segnale di percorso per indicare che il PPP non è scramblato."
In altre parole:
Se la codifica è attivata, le interfacce POS utilizzano un valore C2 di 0x16.
Se lo scrambling è disabilitato, le interfacce POS usano un valore C2 di 0xCF.
La maggior parte delle interfacce POS che utilizzano un valore C2 predefinito di 0x16 (22 decimali) inserisce il comando pos flag c2 22 nella configurazione, anche se questa riga non viene visualizzata nella configurazione in esecuzione perché 0x16 è il valore predefinito. Per modificare il valore predefinito, usare il comando pos flag c2.
7507-3a(config-if)#pos flag c2 ? <0-255> byte value
Utilizzare il comando show running-config per confermare la modifica. Il comando show controller pos restituisce il valore ricevuto. Pertanto, una modifica del valore sull'estremità locale non modifica il valore nell'output 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
Scrambling rende casuale il modello di 1s e 0s trasportato nel fotogramma di SONET in modo da prevenire stringhe continue di tutti 1s o tutti 0s. Questo processo soddisfa anche le esigenze dei protocolli di livello fisico che si basano su transizioni sufficienti tra 1 e 0 per mantenere la temporizzazione.
Le interfacce POS supportano due livelli di scrambling, descritti di seguito:
Lo standard ITU-T GR-253 definisce un algoritmo 1 + x6 + x7 che codifica tutte le righe del SOH ad eccezione della prima. Non è possibile disattivare questo scrambler, che è adeguato quando i frame SONET contengono chiamate telefoniche nel payload.
Lo standard ITU-T I.432 definisce ciò a cui le interfacce POS si riferiscono come scrambling stile ATM. Questo scrambler usa un polinomio di 1 + x43 ed è uno scrambler auto-sincrono. Ciò significa che il mittente non deve inviare alcuno stato al destinatario.
Poiché una stringa relativamente semplice di 0 può portare a un line flap e a un servizio di interrupt, Cisco consiglia di abilitare lo scrambling stile ATM in tutte le configurazioni, compresa la fibra scura. Su alcune schede di linea del GSR (Gigabit Switch Router), ad esempio OC-192 POS, il comando scrambling è stato rimosso dall'interfaccia della riga di comando ed è necessario abilitarlo. Per impostazione predefinita, lo scrambling rimane OFF sulle schede di linea POS a velocità inferiore per la compatibilità con le versioni precedenti.
Lo scrambling viene eseguito nell'hardware e non pone problemi di prestazioni sul router. Lo scrambling avviene direttamente nel framer Application-Specific Integrated Circuit (ASIC) su schede di linea più recenti, come OC3 8/16x e OC12 4x del GSR, o in un ASIC adiacente su schede di linea precedenti come il POS 4xOC3 o 1xOC12 del GSR.
La Figura 2 mostra l'ordine corretto di funzionamento e indica quando viene eseguito lo scrambling durante la trasmissione.
Figura 2 - L'ordine corretto di funzionamento
Quando si configura il comando pos scramble-atm, l'interfaccia POS è configurata in modo da utilizzare lo scrambling stile ATM e il comando pos flag c2 22 viene inserito nella configurazione. L'esecuzione del comando pos flag c2 22 senza il comando pos atm-scramble si limita a configurare il byte C2 nell'intestazione SONET per avvisare l'interfaccia ricevente che il payload è scramblato. In altre parole, solo il comando pos scramble-atm attiva effettivamente lo scrambling.
Se un'interfaccia Cisco POS non si accende/si accende quando connessa a un dispositivo di terze parti, verificare le impostazioni di scrambling, Cyclic Redundancy Check (CRC) e il valore annunciato nel byte C2. Sui router delle reti Juniper, la configurazione della modalità rfc-2615 imposta questi tre parametri:
Scrambling abilitato
Valore C2 di 0x16
CRC-32
In precedenza, quando lo scrambling era abilitato, questi dispositivi di terze parti continuavano a utilizzare un valore C2 di 0xCF, che non rifletteva correttamente il payload scrambled.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
01-Dec-2005 |
Versione iniziale |