Sommario

Introduzione

Premesse

Importanza della sincronizzazione di fase/frequenza

Sincronizzazione orologio di rete

Sincronizzazione della frequenza

Sincronizzazione fase

Sincronizzazione ora

SyncE

Principio di base di SyncE

Canale di messaggistica sincronizzazione Ethernet

SyncE con LAG

PTPv2/1588v2

Principio operativo di base della PTP

Funzionamento di PTP

Domini PTP

Modello di scambio messaggi

Vari tipi di pacchetto

Tipi di dispositivo PTP

Definizione della gerarchia MasterClock-SlaveClock

Profili

8275.1

8275.2

Servo Algorithm

Esempio di configurazione per 8275.1/8275.2 su NCS 540 (Cisco IOS XR)

Risoluzione dei problemi relativi a PTP

Esempi di acquisizioni di pacchetti di messaggi Sync, Announce, Delay_Req e Delay_Resp

Informazioni correlate

Introduzione

Questo documento descrive il funzionamento di Precision Time Protocol (PTP) e Synchronous Ethernet (SyncE) con configurazioni di esempio, esempi e comandi di risoluzione dei problemi per i dispositivi Cisco IOS® XR nei profili delle telecomunicazioni 8275.1 e 8275.2.

Premesse

Un orologio per noi è un orologio da parete o da polso, ma per i dispositivi di rete, è un segnale periodico di 0 e 1 alternativi che viene usato per campionare i bit di dati. Proprio come una lancetta di secondi nell'orologio ha un movimento angolare per rappresentare un secondo, una coppia di 0 e 1 rappresenta T (periodo di tempo [T=1/frequenza]). Per generare questo orologio, i dispositivi di rete utilizzano un oscillatore a cristallo che ha un errore di ±100 ppm (parti per milione. ad esempio, un orologio con la frequenza di 250 MHz e 100 ppm avrà una gamma di frequenza da 249.975 MHz a 250.025 MHz (in inglese) nella generazione del segnale di clock. Quindi, idealmente, l'orologio non è completamente periodico ma è sufficiente per il requisito di campionamento dei segnali di dati fuori dalle interfacce.

Le reti di telecomunicazione (3G/4G/5G) utilizzano un orologio di altissima qualità (strato) e tutte le stazioni base (NodeB/eNodeB e così via) devono essere sincronizzate con questo orologio con il minor errore/ritardo possibile (circa 1µ).

- Un'opzione è installare un GPS in tutte le stazioni di base, il che è abbastanza costoso e meno sicuro come il GPS funziona sui sistemi satellitari.

- La seconda opzione consiste nell'utilizzare l'apparecchiatura di rete esistente (NE) per trasferire le informazioni sull'orologio insieme al segnale dati. Questa opzione è molto conveniente in quanto i dati sono già trasferiti dagli operatori di rete e l'uso di tali operatori per il trasferimento del segnale di clock lo renderà più economico e sicuro. Tuttavia, la qualità dell'orologio potrebbe non essere così buona rispetto all'opzione GPS precedente e varierà in base al profilo/protocollo utilizzato negli NE, nonché alla congestione della rete.

Importanza della sincronizzazione di fase/frequenza

Un segnale di messaggio (ad esempio, un segnale vocale) modulato con un'onda ad alta frequenza (segnale vettore) all'estremità del trasmettitore deve essere demodulato all'estremità del ricevitore con lo stesso segnale vettore utilizzato all'estremità del trasmettitore. Se si verificano cambiamenti/scostamenti nella frequenza o nella fase dell'onda portante sul ricevitore, il segnale del messaggio sarà danneggiato. Tuttavia, è sempre previsto un piccolo offset tra l'onda portante Rx e l'onda portante Tx.

Un'analogia consiste nell'utilizzare una cassetta di sicurezza per inviare un messaggio e bloccarlo con una chiave. Se si desidera leggere il messaggio nella cassetta di sicurezza, è necessario utilizzare la stessa chiave per sbloccare la cassetta all'estremità del ricevitore. Se la chiave di replica presenta distorsioni o sfigurazioni, il messaggio non può essere letto.

Le compensazioni accettabili per vari servizi di telecomunicazione sono:

Sincronizzazione orologio di rete

La sincronizzazione è l'allineamento degli orologi alla stessa ora/fase e frequenza.

La sincronizzazione per la temporizzazione può essere classificata in sincronizzazioni di frequenza (ottenendo = / = dove = chiamato anche come stessa velocità), sincronizzazioni di fase (alla stessa ora) e sincronizzazioni di ora (ora del giorno).

Sincronizzazione della frequenza

Tutte le NE devono far corrispondere la frequenza del loro orologio a un orologio sorgente (derivato da un MasterClock).

La sincronizzazione della frequenza per NE può essere eseguita con SyncE o PTPv2, che verranno illustrati più avanti in questa sezione.

SyncE deriva la frequenza dai pacchetti dati ricevuti sull'interfaccia (funziona sul livello fisico) insieme ai pacchetti ESMC ricevuti (un pacchetto al secondo circa) sull'interfaccia che descrive la qualità dell'orologio. Pertanto, non aggiunge alcun pacchetto di controllo e non è interessato dalla congestione del traffico che è l'aspetto migliore di SyncE.

PTP viene eseguito sui pacchetti, quindi ci sarà un flusso di controllo dei pacchetti e i pacchetti saranno interessati dalla congestione che si aggiunge al ritardo.

Sincronizzazione fase

La sincronizzazione di fase riguarda l'allineamento di questi segnali di clock. Possiamo vedere che i segnali sincronizzati di frequenza sopra riportati non sono ancora allineati, quindi hanno un offset di fase.

PTPv2 viene utilizzato per trasportare le informazioni di fase attraverso la rete.

Sincronizzazione ora

La sincronizzazione dell'ora, detta anche ora del giorno, ha semplicemente la stessa ora in tutte le NE. Cioè t_1=t2.

NTP e PTP vengono utilizzati per trasferire informazioni temporali nella rete. Mentre NTP fornisce una precisione di millisecondi, PTP può fornire una precisione fino a sotto-microsecondi.

La sincronizzazione dell'ora e la sincronizzazione della fase vengono spesso utilizzate sinonimamente nella rete, in quanto la funzionalità PTP utilizzata per la sincronizzazione della fase consente di ottenere la sincronizzazione dell'ora.

NTP non farà parte della nostra discussione in questo momento.

SyncE

Principio di base di SyncE

SyncE opera sul principio di base dell'estrazione della frequenza di clock dai dati ricevuti su una porta.

Un semplice esempio è illustrato qui. Il segnale dati viene elaborato con l'oscillatore locale e i dati di output vengono inviati fuori dalla porta Tx. Si può osservare che la frequenza di clock è presente nel segnale Data trasmesso sulla porta. SyncE opera sul principio dell'elaborazione inversa del segnale ricevuto sulla porta Rx e ottiene le informazioni sulla frequenza dell'orologio trasmesso.

SyncE è una raccomandazione di ITU-T su come fornire una frequenza in una rete. In base alla raccomandazione, la frequenza verrà recuperata dal bitstream nello strato fisico come indicato in precedenza. L'orologio che verrà distribuito nella catena è denominato orologio di riferimento primario (PRC) e tutti gli orologi nella rete saranno tracciabili su tale orologio. Per ottenere un orologio tracciabile, tutti i nodi in una catena tra MasterClock e il dispositivo terminale devono essere implementati con un orologio sincrona Ethernet Equipment Clock (EEC) secondo le raccomandazioni SyncE. Le prestazioni dell'orologio ripristinato non dipenderanno dal carico della rete, in quanto non viene sincronizzato con alcun pacchetto specifico.

MasterClock NE accetta i riferimenti temporali dell'ingresso esterno provenienti dall'orologio di rete (SSU o BITS). Questi riferimenti vengono quindi utilizzati come input per l'orologio CEE, in genere situato sulla scheda di sincronizzazione centrale della NE. Il riferimento temporale di output EEC viene quindi utilizzato per campionare i dati e inviare il traffico sulla porta SyncE enable Tx.

A SlaveClock NE, l'orologio viene recuperato all'interno del CDR (Transceiver clock Data Recovery). In alcuni casi in cui l'orologio RX non è disponibile sul ricetrasmettitore, potrebbe essere necessario utilizzare un CDR esterno per recuperare l'orologio. L'orologio viene quindi inviato attraverso il backplane per raggiungere la scheda di sincronizzazione centrale di SlaveClock. Questo riferimento temporale diventa quindi un riferimento all'EEC (noto anche come riferimento di tempo linea). Come mostrato in SlaveClock NE, un EEC può accettare riferimenti di linea ed esterni, così come l'input di un oscillatore locale di ±4.6 ppm (utilizzato in situazioni in cui non ci sono linee o riferimenti esterni disponibili). Da questo punto in poi, SlaveClock NE diventa MasterClock NE per il successivo downstream NE, e la sincronizzazione viene trasportata da nodo a nodo, dove ogni nodo partecipa al ripristino e alla distribuzione.

Canale di messaggistica sincronizzazione Ethernet

Il canale ESMC (Ethernet Synchronization Messaging Channel) è un protocollo Ethernet slow protocol definito da ITU-T (i messaggi vengono inviati all'indirizzo di destinazione multicast Ethernet 01-80-C2-00-00-02 e usano Ether Type 88-09) per impedire che i messaggi fuoriescano da un collegamento sincronizzato a un altro collegamento.

Trasporta le informazioni SSM (Synchronization Status Message), ovvero il livello di qualità (QL) dell'orologio trasmittente. Ad esempio: Se il dispositivo upstream è sincronizzato con un orologio PRC, il valore QL ricevuto è QL-PRC e il valore SSM corrispondente è 0010.

Le PDU informative ESMC vengono inviate periodicamente alla velocità di una PDU al secondo. La mancata ricezione di una PDU ESMC entro un periodo di cinque secondi determina SSF=true (QL=QL-FAILED). Il valore predefinito (iniziale) per QL è DNU (SSM=1111) e deve essere modificato solo quando si riceve un TLV QL valido.

È necessario notare che se un dispositivo è dual-homed e la fonte del segnale per entrambi i dispositivi upstream è PRC, allora il QL ricevuto sul dispositivo da entrambi i collegamenti è QL-PRC. È quindi necessario assegnare una priorità ai collegamenti in modo da scegliere il dispositivo upstream più adatto in relazione agli hop, ai collegamenti e così via.

La sincronizzazione MasterClock-SlaveClock su più NE con più possibili input di sincronizzazione per la protezione della sincronizzazione potrebbe portare a cicli di sincronizzazione tra NE. Per evitare cicli temporali, una NE dovrebbe inserire un valore SSM di DNU nella direzione della NE, che viene utilizzata come origine della sincronizzazione effettiva per l'orologio NE.

SyncE con LAG

SyncE funziona sul layer fisico e i pacchetti ESMC sono trasportati anche dal protocollo Ethernet slow. LAG è un'altra funzione che utilizza protocolli lenti e LAG opera sopra ESMC. L'elaborazione dei messaggi ESMC è quindi necessaria su ogni collegamento sincrono abilitato per Ethernet nel gruppo LAG.

È inoltre importante notare che l'uso di collegamenti paralleli, come nel caso dei LAG, deve essere attentamente considerato, data la possibilità di creare loop temporali.

Idealmente, è sufficiente eseguirlo sul collegamento con un solo membro del bundle ma, in caso contrario, è lasciato agli operatori il compito di configurare diverse porte sincrone abilitate Ethernet.

PTPv2/1588v2

IEEE 1588 è definito dall'Institute of Electrical and Electronics Engineers (IEEE) nel 2002 come protocollo PTP (Precision Clock Synchronization Protocol) per i sistemi di misurazione e controllo in rete. Si chiama Protocollo PTP (Precision Time Protocol) in breve.

IEEE 1588v1 si applica all'automazione industriale e ai campi di test e misurazione. Con lo sviluppo delle reti IP e la diffusione delle reti 3G, la domanda di sincronizzazione dell'ora sulle reti di telecomunicazione è aumentata. Per soddisfare questa esigenza, IEEE ha redatto IEEE 1588v2 basato su IEEE 1588v1 nel giugno 2006, ha rivisto IEEE 1588v2 nel 2007 e ha rilasciato IEEE 1588v2 alla fine del 2008.

1588v2 è un protocollo di sincronizzazione dell'ora che consente una sincronizzazione dell'ora estremamente precisa tra i dispositivi. Viene inoltre utilizzato per implementare la sincronizzazione della frequenza tra i dispositivi.

Questo meccanismo di sincronizzazione basato su pacchetti combina la sincronizzazione di frequenza e di fase a livelli di sub-microsecondi, con le funzionalità di distribuzione ToD attraverso un efficiente meccanismo di scambio dei pacchetti

La principale debolezza di PTP è dovuta anche alla natura dei pacchetti, in quanto i pacchetti di sincronizzazione utilizzati da PTP vengono inoltrati nella rete tra MasterClock e gli host, che sono soggetti a tutti gli eventi di rete, come il ritardo (latenza), la variazione del ritardo dei frame (jitter) e la perdita di frame. Anche se è buona norma applicare l'alta priorità ai flussi di sincronizzazione, questi pacchetti di sincronizzazione continueranno a sperimentare congestione e possibili problemi di routing e inoltro, come i flap fuori sequenza e dei percorsi.

Principio operativo di base della PTP

Inviamo l'ora (hh:mm:ss) in un pacchetto e utilizziamo il tempo di andata e ritorno del flusso per trovare il ritardo nella trasmissione di un pacchetto e correggere l'ora dell'orologio regolando con la metà del ritardo di andata e ritorno.

Funzionamento di PTP

PTP utilizza un'architettura gerarchica MasterClock-SlaveClock per la distribuzione dell'orologio.

Specifica la modalità di sincronizzazione tra gli orologi in tempo reale del sistema. Questi orologi sono organizzati in una gerarchia di sincronizzazione MasterClock-SlaveClock con l'orologio nella parte superiore della gerarchia che determina l'ora di riferimento per l'intero sistema. La sincronizzazione viene eseguita scambiando messaggi di temporizzazione PTP, con SlaveClocks che utilizza le informazioni di temporizzazione per regolare i propri orologi in base all'ora del MasterClock nella gerarchia.

PTP è stato progettato utilizzando un modello di comunicazione multicast. PTP supporta inoltre un modello di comunicazione unicast a condizione che venga mantenuto il comportamento del protocollo. PTP presume che i messaggi di annuncio vengano inviati periodicamente da una porta e recapitati a tutte le altre porte dell'orologio ordinario o di confine all'interno di un percorso di comunicazione. Se il percorso di comunicazione è costituito da più di due porte, si presuppone che i messaggi di annuncio vengano inviati in modalità multicast oppure che le informazioni di annuncio vengano replicate in tutte le porte del percorso di comunicazione utilizzando messaggi unicast. Le porte PTP individuano altre porte all'interno di un percorso di comunicazione mediante la ricezione di messaggi di annuncio multicast.

Il protocollo viene eseguito all'interno di un ambito logico denominato dominio. Tutti i messaggi PTP, i set di dati, i computer di stato e tutte le altre entità PTP sono sempre associati a un particolare ID di dominio

Il protocollo definisce l'evento e i messaggi PTP generali. I messaggi di evento sono messaggi temporizzati, ossia un timestamp accurato (il tempo registrato sul dispositivo al punto di ingresso/uscita, ma non è necessario che il messaggio trasporti il tempo t) che viene generato sia alla trasmissione che alla ricezione. I messaggi generali non richiedono l'indicazione precisa dell'ora.

Domini PTP

Un dominio è costituito da un raggruppamento logico di orologi che comunicano tra loro utilizzando il protocollo PTP.

I domini PTP vengono utilizzati per partizionare una rete all'interno di un'entità amministrativa. I messaggi e i set di dati PTP sono associati a un dominio e pertanto il protocollo PTP è indipendente per i diversi domini.

Modello di scambio messaggi

1. MasterClock invia un messaggio Sync a SlaveClock e nota l'ora di invio.

2. SlaveClock riceve il messaggio Sync e rileva l'ora di ricezione.

3. MasterClock comunica a SlaveClock il timestamp:

- Incorporamento del timestamp nel messaggio Sync. Ciò richiede una sorta di elaborazione hardware per la massima precisione e accuratezza.

- Incorporamento del timestamp in un messaggio di completamento.

4. SlaveClock invia un messaggio Delay_Req a MasterClock e nota l'ora di invio.

5. MasterClock riceve il messaggio Delay_Req e rileva l'ora di ricezione.

6. MasterClock comunica a SlaveClock il timestamp incorporandolo in un messaggio Delay_Resp.

L'accuratezza del tempo PTP viene ridotta dall'asimmetria nei percorsi utilizzati dai messaggi di evento. In particolare, l'errore di scostamento temporale è 1/2 dell'asimmetria.

L'asimmetria non è rilevabile da PTP. Tuttavia, se noto, PTP corregge l'asimmetria. L'asimmetria può essere introdotta a livello fisico, ad esempio tramite l'asimmetria dei supporti di trasmissione, da bridge e router, e in sistemi di grandi dimensioni dai percorsi di inoltro e inverso attraversati da messaggi di eventi che seguono percorsi diversi attraverso la rete. È necessario configurare i sistemi e selezionare i componenti per ridurre al minimo questi effetti in base alla precisione di temporizzazione richiesta. Nei sistemi a subnet singola con distanze di pochi metri, l'asimmetria non è in genere un problema per le precisioni temporali al di sopra di alcune decine di ns.

Vari tipi di pacchetto

Il set di messaggi di evento è costituito da:

1. Sync: utilizzato per la sincronizzazione dell'ora tra MasterClock e SlaveClock. In due passaggi, i messaggi Sync non trasportano tempo ma l'ora verrà indicata nel MasterClock e sarà trasportata nel messaggio Follow_Up. In un unico passaggio il messaggio Sync trasporterà tempo. Vecchi dispositivi/hardware non erano in grado di supportare la misurazione e il trasporto del punto tempo di uscita quando un messaggio veniva recapitato attraverso una porta, quindi in due passaggi ciò era dovuto a limitazioni hardware. Al giorno d'oggi, l'hardware può registrare il punto di uscita e inviarlo all'interno del messaggio Sync. Un solo passaggio è compatibile con due passaggi precedenti.

2. Delay_Req - Un messaggio Delay_Req è una richiesta proveniente dal nodo ricevente/SlaveClock di restituire l'ora in cui il messaggio Delay_Req è stato ricevuto, utilizzando un messaggio Delay_Resp. Verrà utilizzato per calcolare il tempo di transito tra SlaveClock e MasterClock. Questo messaggio viene contrassegnato con l'ora in SlaveClock.

3. Pdelay_Req - Un messaggio Pdelay_Req viene trasmesso da una porta PTP a un'altra porta PTP come parte della misurazione del tempo di propagazione tra porte per determinare il ritardo sul collegamento tra di esse. Viene utilizzato dall'orologio trasparente P2P per calcolare il ritardo del collegamento per hop.

4. Pdelay_Resp - Un messaggio Pdelay_Resp viene trasmesso da una porta PTP in risposta alla ricezione di un messaggio Pdelay_Req.

L'insieme dei messaggi generali comprende:

- Annuncio - Questo messaggio viene utilizzato dal Best MasterClock Algorithm (BMCA) per generare la topologia MasterClock-SlaveClock. Viene utilizzato per selezionare il migliore MasterClock e mantenerlo in posizione.

- Follow_Up - Questo tipo di messaggio viene utilizzato nella modalità in due passaggi. Trasporta il tempo. (Ora di uscita sincronizzazione sul nodo MasterClock) nel relativo messaggio.

- Delay_Resp - Viene utilizzato per calcolare il tempo di transito da MasterClock a SlaveClock. Trasporta l'ora (ora di uscita del messaggio Delay_Resp) nel messaggio.

- Pdelay_Resp_Follow_Up - È simile al messaggio Follow_Up, ma viene generato da un orologio P2P trasparente.

- Gestione: Non fa parte della nostra discussione.

- Segnalazione - Per la comunicazione tra orologi per tutti gli altri scopi. È ad esempio possibile utilizzare i messaggi di segnalazione per la negoziazione della frequenza dei messaggi unicast tra un MasterClock e i relativi SlaveClock.

I messaggi Sync, Delay_Req, Follow_Up e Delay_Resp vengono utilizzati per generare e comunicare le informazioni di temporizzazione necessarie per sincronizzare gli orologi ordinari e di confine utilizzando il meccanismo di richiesta-risposta di ritardo.

I messaggi Pdelay_Req, Pdelay_Resp e Pdelay_Resp_Follow_Up vengono utilizzati per misurare il ritardo del collegamento tra due porte di clock che implementano il meccanismo di ritardo del peer. Il ritardo del collegamento viene utilizzato per correggere le informazioni sugli intervalli nei messaggi Sync e Follow_Up nei sistemi composti da orologi trasparenti peer-to-peer.

Gli orologi ordinari e di confine che implementano il meccanismo di ritardo peer possono sincronizzarsi utilizzando i ritardi di collegamento misurati e le informazioni nei messaggi Sync e Follow_Up. Il messaggio Annuncio viene utilizzato per stabilire la gerarchia di sincronizzazione. I messaggi di gestione vengono utilizzati per eseguire query e aggiornare i set di dati PTP gestiti dagli orologi. Questi messaggi vengono utilizzati anche per personalizzare un sistema PTP e per l'inizializzazione e la gestione degli errori. I messaggi di gestione vengono utilizzati tra i nodi di gestione e gli orologi (non saranno parte della nostra discussione).

I messaggi di segnalazione vengono utilizzati per la comunicazione tra gli orologi per tutti gli altri scopi. È ad esempio possibile utilizzare i messaggi di segnalazione per la negoziazione della frequenza dei messaggi unicast tra un MasterClock e i relativi SlaveClock.

Tipi di dispositivo PTP

Esistono cinque tipi di dispositivi PTP di base, come indicato di seguito:

1. Orologio normale - Può essere solo un Grand MasterClock (GM) o solo un SlaveClock.

2. Orologio di confine - Può essere sia SlaveClock che GM

3. Orologio trasparente end-to-end: l'orologio trasparente end-to-end inoltra tutti i messaggi come un normale bridge, router o ripetitore. Tuttavia, per i messaggi di evento PTP, il ponte temporale di residenza, mostrato nella Figura seguente, misura il tempo di residenza (il tempo impiegato dal messaggio per attraversare l'orologio trasparente) dei messaggi di evento PTP. Questi tempi di permanenza vengono accumulati in un campo speciale, il campo di correzione, del messaggio di evento PTP o del messaggio di completamento associato. Questa correzione si basa sulla differenza nel timestamp generato quando il messaggio di evento entra ed esce dall'orologio trasparente.

4. Orologio trasparente peer-to-peer: aggiunge il tempo di residenza e il tempo di ritardo di transito dei collegamenti ai messaggi PTP utilizzando il meccanismo di ritardo peer (genera i propri pacchetti delay-req-resp per calcolare il ritardo del collegamento peer).

5. Nodo di gestione (non incluso nella discussione).

Definizione della gerarchia MasterClock-SlaveClock

All'interno di un dominio, ogni porta di un orologio ordinario e di confine esegue una copia indipendente della macchina a stati del protocollo. Per gli "eventi di decisione sullo stato", ogni porta esamina il contenuto di tutti i messaggi di annuncio ricevuti sulla porta. Utilizzando il migliore algoritmo MasterClock, il contenuto del messaggio di annuncio e il contenuto dei set di dati associati all'orologio ordinario o di confine vengono analizzati per determinare lo stato di ciascuna porta dell'orologio.

Macchina a stati PTP

Ogni porta di un orologio ordinario e di confine mantiene una copia separata della macchina a stati PTP. Questa macchina a stati definisce gli stati consentiti della porta e le regole di transizione tra stati. Gli "eventi di decisione sullo stato" principali che determinano la gerarchia MasterClock-SlaveClock sono la ricezione di un messaggio di annuncio e la fine di un intervallo di annuncio (l'intervallo tra i messaggi di annuncio). Gli stati della porta che determinano la gerarchia MasterClock-SlaveClock sono i seguenti:

- INIT - La porta non è ancora pronta per partecipare a PTP.

- LISTENING - Primo stato quando una porta è pronta a partecipare a PTP: porta in ascolto di MasterClock PTP per un periodo di tempo (configurabile)

- PRE-MasterClock: la porta sta per entrare nello stato MasterClock.

- MasterClock: la porta fornisce l'indicatore orario per qualsiasi SlaveClock/clock limite in ascolto.

- UNCALIBRATED - La porta riceve i timestamp da un MasterClock, ma l'orologio del router non è ancora sincronizzato con il MasterClock

- SLAVE: la porta riceve timestamp da un MasterClock e l'orologio del router è sincronizzato con il MasterClock

- PASSIVE - La porta è a conoscenza di un orologio migliore di quello che avrebbe pubblicizzato se fosse stato nello stato di MasterClock, ma non sta svuotando l'orologio

Miglior algoritmo MasterClock

Il miglior algoritmo MasterClock confronta i dati che descrivono due orologi per determinare quali dati descrivono l'orologio migliore. Questo algoritmo viene utilizzato per determinare quale degli orologi descritti in diversi messaggi di annuncio ricevuti da una porta orologio locale è l'orologio migliore. Viene anche utilizzato per determinare se un orologio appena scoperto, un MasterClock esterno, è migliore dell'orologio locale stesso. I dati che descrivono un MasterClock esterno sono contenuti nei campi grandMasterClock di un messaggio di annuncio.

L'algoritmo di confronto dei set di dati si basa su confronti a coppie di attributi con la seguente precedenza:

1. priority1 - Designazione configurabile dall'utente che indica che un orologio appartiene a un set ordinato di orologi da cui è selezionato un MasterClock

2. clockClass: attributo che definisce la tracciabilità TAI di un orologio

3. clockAccuracy - Attributo che definisce la precisione di un orologio

4. offsetScaledLogVariance: attributo che definisce la stabilità di un orologio

5. priority2 - Designazione configurabile dall'utente che fornisce un ordinamento più dettagliato tra gli orologi altrimenti equivalenti

6. clockIdentity - Interruzione del tempo basata su identificatori univoci

Oltre a questo ordine di precedenza, la "distanza" misurata dal numero di orologi limite tra l'orologio locale e l'orologio master esterno viene utilizzata quando due messaggi di annuncio riflettono lo stesso MasterClock esterno. La distanza è indicata nel campo stepRemoved dei messaggi di annuncio. Questa condizione può verificarsi nei sistemi PTP con percorsi ciclici non rimossi da un protocollo esterno a PTP. L'algoritmo di confronto del set di dati seleziona senza ambiguità uno dei due orologi come "migliore" o "topologicamente migliore".

Profili

Lo scopo di un profilo PTP è quello di consentire alle organizzazioni di specificare selezioni specifiche di valori di attributo e funzionalità facoltative di PTP che, quando utilizzano lo stesso protocollo di trasporto, si interagiscono e raggiungono prestazioni che soddisfano i requisiti di una particolare applicazione.

Un profilo PTP deve definire:

- Opzioni dell'algoritmo Best MasterClock

- Opzioni di gestione della configurazione

- Meccanismi di ritardo del percorso (peer-delay o delay request-response)

- L'intervallo e i valori predefiniti di tutti gli attributi e i membri del set di dati configurabili PTP

- I meccanismi di trasporto richiesti, ammessi o vietati

- Tipi di nodo richiesti, consentiti o non consentiti

- Le opzioni richieste, consentite o non consentite

Di seguito sono riportati i vari profili definiti per la rete di pacchetti con PTP:

I profili 8265.x vengono utilizzati per ottenere la sincronizzazione della frequenza con PTP.

Lo standard 8275.x viene utilizzato per la sincronizzazione dell'ora del giorno/fase tramite PTP. NCS5xx/55xx supporta attualmente 8265.1, 8275.1, 8275.2 e 8273.2.

8265.1 è stato usato in precedenza per la sincronizzazione dell'orologio 3G/4G, mentre 8275.x è usato ora per il 5G a causa dell'aumento della domanda di precisione con le reti 5G.

8275.1

Il presente allegato contiene il profilo PTP per la telecom per la distribuzione fase/tempo con il pieno supporto temporale dalla rete.

Modello di sincronizzazione:

Il profilo G.8275.1 adotta il modello di sincronizzazione hop-by-hop. Ogni dispositivo di rete nel percorso dall'orologio del server a quello del client sincronizza l'orologio locale con i dispositivi upstream e fornisce la sincronizzazione con i dispositivi downstream

Tipi di nodo:

In questo profilo, i tipi di nodi consentiti sono gli orologi ordinari, gli orologi dei limiti e gli orologi trasparenti end-to-end.

In questo profilo, i tipi di nodi vietati sono gli orologi trasparenti peer-to-peer.

Domini:

È possibile utilizzare ID di dominio da 24 a 43. L'ID dominio predefinito è 24

Modalità orologio:

Sono consentiti sia orologi a un passaggio che a due passaggi. Un orologio deve essere in grado di ricevere e gestire i messaggi trasmessi da orologi a una fase e a due fasi. Non è necessario disporre di un orologio per supportare le modalità una e due fasi per la trasmissione dei messaggi.

Meccanismi di trasporto richiesti, ammessi o vietati

In questo profilo, i meccanismi di trasporto consentiti sono:

- IEEE 802.3/Ethernet e

- OTN

Occorre sostenere almeno uno dei due meccanismi di trasporto. Per il trasporto su IEEE 802.3/Ethernet, per la conformità con questo profilo sono richiesti sia l'indirizzo multicast non inoltrabile, 01-80-C2-00-00-0E, che l'indirizzo multicast inoltrabile, 01-1B-19-00-00-00

Messaggi unicast/multicast:

Tutti i messaggi vengono inviati in modalità multicast, utilizzando uno dei due indirizzi multicast (01-80-C2-00-00-0E/01-1B-19-00-00-00). Modalità unicast non consentita in questa versione del profilo.

Opzioni migliori algoritmo MasterClock:

Questo profilo utilizza il BMCA alternativo.

I seguenti parametri di clock vengono confrontati (in ordine) da ciascun nodo disponibile per selezionare il migliore MasterClock:

Tabella 1. Gerarchia BMCA del profilo Telcom

Parametro

Descrizione

Priorità 1

NON utilizzato nei profili delle telecomunicazioni

Clock-class

Misura della tracciabilità dell'orologio.

Se la frequenza/ora del MasterClock è tracciabile su un riferimento GNSS (A, B migliore di C)

Precisione dell'orologio

Quanto è accurata l'uscita dell'orologio GM sul riferimento primario?

ad esempio: con una precisione di 25 ns.

Offset OSLV (Scaled Log Variance)

Misura della precisione dell'orologio. Misura in cui l'output dell'orologio varia quando non viene sincronizzato con un'altra origine.

Priorità 2

Priorità definita dall'utente nel nodo MasterClock se tutti i parametri sopra indicati corrispondono

Priorità porta locale

Priorità definita dall'utente per porta su DUT

Identità orologio GM

ID orologio di GrandMasterClock utilizzato come interruttore

Passi rimossi

Percorso più breve scelto se grandMasterClock è raggiungibile tramite più porte (A migliore di B)

Opzione di misurazione ritardo percorso (richiesta ritardo/risposta ritardo):

In questo profilo viene utilizzato il meccanismo di richiesta ritardo/risposta ritardo. Il meccanismo di ritardo del peer non deve essere utilizzato in questo profilo, è necessario utilizzare il metodo delay_req—response.

Questo profilo PTP telecom definisce un BMCA alternativo che consente di utilizzare due approcci principali per impostare la topologia della rete di sincronizzazione fase/tempo:

Definizione automatica della topologia:

Quando si configurano gli attributi localPriority definiti in questa raccomandazione sul valore predefinito, la topologia PTP viene stabilita automaticamente dalla BMCA alternativa in base ai messaggi di annuncio scambiati dagli orologi PTP. Dopo questa operazione viene creato un albero di sincronizzazione con i percorsi più brevi ai T-GM. In questa modalità, durante gli eventi di errore e la riconfigurazione della topologia, il BMCA alternativo verrà eseguito di nuovo e risulterà in una nuova struttura di sincronizzazione. Questa operazione BMCA alternativa garantisce che non verrà creato alcun loop di temporizzazione senza richiedere l'intervento manuale o l'analisi preliminare della rete. Il tempo di convergenza per la nuova topologia PTP dipende dalle dimensioni della rete e dalla configurazione specifica dei parametri PTP.

Pianificazione manuale della rete: L'utilizzo degli attributi localPriority definiti in questa raccomandazione con valori diversi rispetto al valore predefinito consente di creare manualmente la topologia di rete di sincronizzazione, in modo simile alle reti SDH (Synchronous Digital Hierarchy), che in genere vengono gestite in base al messaggio di stato della sincronizzazione (SSM). Questa opzione consente il controllo completo delle azioni durante gli eventi di errore e la riconfigurazione della topologia, in base alle priorità locali configurate del sistema. Tuttavia, prima dell'installazione è necessaria un'attenta pianificazione della rete per evitare cicli temporali.

Considerazioni sull'uso della priorità 2:

In questo profilo è possibile configurare l'attributo PTP priority2. In alcune circostanze speciali, l'utilizzo dell'attributo priority2 può semplificare la gestione della rete. In questa sezione vengono descritti due casi di utilizzo: altri casi possibili sono per ulteriori studi.

- Caso 1.

Gli operatori possono configurare l'attributo priority2 di PTP in modo che tutto l'orologio di confine della telecom (T-BC) sia tracciabile su un Telecom Grand MasterClock (T-GM) o tracciabile su due T-GM diversi allo stesso tempo.

Ad esempio, in questa immagine, se tutti gli altri attributi PTP dei due T-GM sono uguali e i due T-GM sono configurati con lo stesso valore di priorità2, ogni T-BC selezionerà il T-GM con il percorso più breve. Se i due T-GM sono configurati con valori di priorità2 diversi, tutti i T-BC verranno sincronizzati con il T-GM con il valore di priorità2 più piccolo.

- Caso 2.

Gli operatori possono configurare l'attributo PTP priority2 per impedire la sincronizzazione dei T-BC di una rete a monte con i T-BC di una rete a valle quando T-GM è in errore.

Ad esempio, nella Figura, se tutti gli altri attributi PTP di tutti i T-BC sono uguali e l'attributo PTP priorità2 di tutti i T-BC è configurato con lo stesso valore, quando il T-GM è in errore, i T-BC nella rete a monte possono sincronizzarsi con i T-BC nella rete a valle, a seconda dei valori clockIdentity di tutti i T-BC. Se i T-BC nella rete a monte sono configurati con un valore di priorità2 inferiore rispetto ai T-BC nella rete a valle, quando il T-GM è in errore, i T-BC nella rete a valle si sincronizzeranno con i T-BC nella rete a monte.

Operazioni su aggregazione link:

Quando due dispositivi che incorporano orologi PTP conformi a questo profilo sono connessi tramite un'aggregazione di collegamenti (LAG), è necessario accedere direttamente a ciascun collegamento fisico per trasmettere i messaggi PTP, evitando il LAG. Questo metodo previene potenziali asimmetrie che possono essere presenti quando i percorsi avanti e indietro vengono trasmessi su collegamenti diversi appartenenti al LAG.

Considerazioni sulla scelta dell'indirizzo di destinazione multicast Ethernet PTP:

Questo profilo PTP supporta sia l'indirizzo multicast non inoltrabile 01-80-C2-00-00-0E che l'indirizzo multicast inoltrabile 01-1B-19-00-00-00 quando viene utilizzata la mappatura PTP.

L'indirizzo multicast Ethernet da utilizzare dipende dalla policy dell'operatore; ulteriori considerazioni sono fornite di seguito.

la funzione di bridging di layer 2 associata alla porta PTP di un T-BC o T-TC non deve inoltrare alcun frame con indirizzo MAC di destinazione 01-1B-19-00-00-00; a tale scopo, è possibile eseguire il provisioning corretto di questo indirizzo multicast nel database di filtro.

- Opzione 1 - Uso dell'indirizzo multicast non inoltrabile 01-80-C2-00-00-0E.

Alcuni operatori di rete ritengono che i messaggi PTP non debbano mai essere inoltrati attraverso apparecchiature di rete non compatibili con PTP.

L'utilizzo dell'indirizzo multicast non inoltrabile 01-80-C2-00-00-0E garantisce questa proprietà per la maggior parte del tempo (esistono eccezioni per alcune apparecchiature Ethernet meno recenti).

Pertanto, in caso di configurazione errata delle apparecchiature di rete (ad esempio, se le funzioni PTP non sono attivate nelle apparecchiature di rete compatibili con PTP), l'uso di questo indirizzo multicast impedisce la distribuzione errata della sincronizzazione, poiché i messaggi PTP verranno bloccati dalle apparecchiature di rete non compatibili con PTP.

- Opzione 2 - Uso dell'indirizzo multicast inoltrabile 01-1B-19-00-00-00.

Alcuni operatori di rete ritengono che l'utilizzo di un indirizzo multicast inoltrabile sia più flessibile e che sia preferibile inoltrare i messaggi PTP per mantenere attivo il collegamento di sincronizzazione nel caso in cui alcune apparecchiature non siano configurate correttamente come nodi non PTP, anche se vi sono potenziali rischi di riduzione delle prestazioni. Il sistema di gestione della rete (NMS) troverà facilmente la configurazione errata e invierà degli allarmi.

Tuttavia, è possibile bloccare i messaggi PTP eseguendo correttamente il provisioning di questo indirizzo multicast nel database di filtraggio di ciascuna apparecchiatura Ethernet.

8275.2

Questa raccomandazione definisce un altro profilo PTP per consentire la distribuzione di fase e tempo con il supporto per temporizzazione parziale (PTS) dalla rete (ossia, non è necessario che ogni dispositivo esegua il PTP nella rete). La differenza principale tra 8275.2 e 8275.1 è che viene eseguito su unicast IPv4 e non tutti i nodi della rete devono eseguire PTP.

Meccanismi di trasporto:

In questo profilo, il meccanismo di trasporto richiesto è UDP/IPv4.

Messaggi unicast:

Tutti i messaggi vengono inviati in formato unicast.

In questo profilo per le telecomunicazioni, la negoziazione unicast è abilitata per impostazione predefinita.

SlaveClock avvierà la sessione seguendo la procedura di negoziazione dei messaggi unicast.

Domini:

È possibile utilizzare ID di dominio da 44 a 63. L'ID di dominio predefinito è 44.

Opzioni migliori algoritmo MasterClock:

Questo profilo utilizza il BMCA alternativo.

Proprietà LPath delay measure option (delay request/delay response), Automatic topology setting and Considerations on the use of priority2 sono le stesse del profilo telecom 8275.1

Considerazioni sul trasporto PTP over IP nelle topologie ad anello:

Quando si utilizzano i messaggi PTP su un layer di trasporto IP, è necessario considerare alcuni aspetti del protocollo di layer 3. Il livello PTP invia i messaggi al livello IP con un indirizzo IP di destinazione. Il livello IP assicura quindi che il messaggio venga recapitato alla destinazione purché vi sia un percorso attraverso la rete di trasporto IP dal nodo di origine all'indirizzo di destinazione. Il livello IP include protocolli di routing dinamico in grado di adattare il percorso attraverso la rete in base ai collegamenti disponibili tra i router IP. È possibile che il percorso utilizzato dal livello di trasporto IP non sia il percorso 'previsto' dal planner di sincronizzazione. L'applicazione di alcune restrizioni nel livello di trasporto IP per controllare i percorsi non ottimali per i messaggi PTP può essere utile. È probabile che ciò si verifichi nelle topologie ad anello.

Prendendo come esempio la topologia mostrata nella Figura seguente, SlaveClock è configurato per richiedere il servizio unicast sia da BC3 che da BC4. Dopo aver ricevuto i messaggi di annuncio da BC3 e BC4, SlaveClock eseguirà BMCA e selezionerà BC4 come orologio padre in base al fatto che il valore step- remove di BC4 è 1, rispetto al valore step-remove di 3 per BC3. SlaveClock richiederebbe quindi i messaggi Sync da BC4.

Se la connessione tra BC4 e R6 si interrompe (vedere la Figura seguente), BC4 non viene raggiunto attraverso il percorso previsto. Tuttavia, è ancora possibile raggiungere questa destinazione perché i protocolli di routing conservano la connessione instradando i pacchetti IP attorno all'anello. Il BC4 viene mantenuto come orologio padre perché è ancora considerato migliore dal BMCA.

È molto probabile che l'operazione desiderata preveda che SlaveClock passi a BC3 per prestazioni migliori.

Ci sono alcune tecniche che possono essere impiegate per garantire che nello scenario di errore sopra identificato, SlaveClock selezionerà BC3 come il suo orologio padre. Si basano sul blocco dei messaggi IP PTP da BC4 a SlaveClock se questi messaggi stanno transitando in senso orario intorno al ring. La soluzione si basa sul blocco dei soli messaggi PTP e non del messaggio di altri protocolli che potrebbero utilizzare gli stessi indirizzi IP.

Opzione 1. Indirizzi IP univoci e route statiche:

In alcuni modelli di distribuzione potrebbe essere possibile allocare indirizzi IP univoci per l'utilizzo esclusivo di PTP. In questo modo è possibile utilizzare le route statiche per controllare la direzione dei flussi PTP tra i nodi. BC4 sarebbe configurato in modo tale che l'unico percorso da utilizzare per raggiungere 11.x.x.141 (SlaveClock) sarebbe il collegamento tra BC4 e R6. Inoltre, R6 potrebbe essere configurato in modo tale che l'unico percorso da utilizzare per raggiungere 11.y.y.104(BC4) sia il collegamento tra R6 e BC4. Se il collegamento tra R6 e BC4 non riesce, non c'è alcuna route disponibile per ottenere i pacchetti IP tra 11.x.x.141 e 11.y.y.104, quindi SlaveClock non ricevere annunci da BC4 e BMCA selezionerà BC3 come orologio padre. Fare riferimento a questa immagine.

Opzione 2. Filtri IP

Tutti i router supportano un determinato livello di filtro IP. I filtri possono essere utilizzati per proteggere il control plane del router dai messaggi indesiderati. In questo caso, possono essere utilizzati per controllare l'accettazione dei messaggi PTP su un sottoinsieme delle interfacce di routing.

In questo caso, R6 sarebbe configurato in modo da proteggere SlaveClock dai messaggi PTP che prendono la direzione sbagliata. Sull'interfaccia R6 rivolta verso BC3, è possibile applicare un filtro per consentire i messaggi solo alla porta UDP 319 o 320 se l'indirizzo di origine corrisponde a quello del processo PTP su BC3. Tutti i messaggi provenienti da BC4 ricevuti su tale interfaccia verranno eliminati. Fare riferimento a questa immagine.

Opzione 3. Elaborazione BC di tutti i messaggi PTP

Una BC può terminare tutti i messaggi PTP ricevuti in una qualsiasi delle sue porte per qualsiasi dominio utilizzato dalla BC. I messaggi PTP possono quindi essere eliminati o inoltrati in base alle decisioni prese all'interno del processo PTP stesso. È possibile scegliere di eliminare il messaggio se l'indirizzo di destinazione del messaggio PTP non è di proprietà della BC o di consegnarlo al motore di inoltro per essere inviato alla destinazione. Quest'ultimo caso può essere utilizzato se il messaggio PTP è destinato a un dominio diverso da quello del BC. Anche in quest'ultimo caso, l'elemento di rete contenente il BC potrebbe anche aggiornare il campo di correzione di qualsiasi messaggio di evento inoltrato per compensare l'estrazione e l'elaborazione del messaggio PTP, cioè supportare la funzione di clock trasparente per questi messaggi. L'estrazione dei messaggi dal piano IP può essere effettuata se il router supporta il routing basato su policy dei pacchetti IP.

Questo esempio è mostrato nell'immagine.

Opzione 4. Uso del meccanismo TTL (Time to Live) dal trasporto IP:

Un nodo PTP potrebbe inviare pacchetti PTP con l'intestazione IP/Transport con un campo TTL impostato sul numero minimo di hop di routing necessari per raggiungere la porta PTP peer con cui ha un contratto PTP. In una tipica rete non compatibile con PTP con router non riconosciuti tra MasterClock e SlaveClock, se il numero di router non compatibili con PTP è maggiore del valore TTL del messaggio PTP, il messaggio PTP verrà scartato da uno dei router non compatibili con PTP. Questa opzione può essere utilizzata per limitare il numero di hop IP attraversati dai pacchetti PTP tra router adiacenti ed evitare la comunicazione attraverso percorsi più lunghi indesiderati.

Questo comportamento può essere per porta PTP o per orologio PTP ed è specifico dell'implementazione. Si presume che in una topologia a anello, il routing IP assicuri che un percorso più breve verso MasterClock PTP sia considerato una route migliore rispetto al percorso più lungo attorno all'anello.

Ad esempio, se uno SlaveClock ha un MasterClock connesso direttamente che può essere raggiunto anche attraverso un percorso più lungo, può usare il valore TTL di 1 per essere certi che i pacchetti PTP raggiungano il MasterClock solo attraverso il percorso connesso direttamente anziché attraverso il percorso più lungo intorno all'anello.

Servo Algorithm

Descrizione delle modalità:

- Modalità Free-Run:

L'orologio PTP non è mai stato sincronizzato con un'origine ora e non è in corso di sincronizzazione con un'origine ora.

- Modalità di acquisizione:

Sincronizzazione dell'orologio PTP con un'origine ora in corso. La durata e la funzionalità di questa modalità sono specifiche dell'implementazione. Questa modalità non è richiesta nell'implementazione.

- Modalità blocco freq/fase:

Blocco fase (Phase Lock) - L'orologio PTP è sincronizzato in fase con una sorgente di tempo e rientra in una precisione accettabile interna.

Frequency Lock-L'orologio è sincronizzato in frequenza con una sorgente temporale ed è entro una certa precisione interna accettabile.

In relazione allo stato della porta PTP definito in [IEEE 1588], un orologio è in modalità Bloccato se è presente una porta PTP in stato SLAVE.

- Modalità Holdover:

L'orologio PTP non è più sincronizzato con una sorgente di tempo e utilizza le informazioni ottenute mentre era sincronizzato in precedenza o altre fonti di informazioni ancora disponibili, per mantenere le prestazioni entro la specifica desiderata o non sono in grado di mantenere le prestazioni entro la specifica desiderata. Il nodo può fare affidamento esclusivamente sulle proprie strutture per la conservazione o può utilizzare qualcosa come un input di frequenza dalla rete per ottenere una riduzione di tempo e/o fase.

Esempio di configurazione per 8275.1/8275.2 su NCS 540 (Cisco IOS XR)

Il router consente di selezionare fonti separate per la frequenza e l'ora del giorno (ToD). La selezione della frequenza può essere effettuata tra qualsiasi sorgente di frequenza disponibile per il router, ad esempio BITS, GPS, SyncE o IEEE 1588 PTP. La selezione ToD è tra la sorgente selezionata per la frequenza e PTP, se disponibile (la selezione ToD è da GPS, DTI o PTP). Questa modalità è nota come modalità ibrida, in cui una sorgente di frequenza fisica (BITS o SyncE) viene utilizzata per fornire la sincronizzazione della frequenza, mentre PTP viene utilizzato per fornire la sincronizzazione ToD.

SyncE (per il trasferimento di frequenza) e ptp (trasferimento di fase/ora del giorno) possono essere utilizzati insieme nella rete, implementando 8275.1 per ottenere una maggiore accuratezza (chiamata modalità ibrida ed è l'unica modalità supportata per NCS dalla versione 7.3.x)

L'attributo di priorità locale non viene trasmesso nei messaggi di annuncio. Questo attributo è utilizzato come punto di interruzione nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati confrontati siano uguali

8275.1:

Orologio

Configurazione

Spiegazione

ptp

ptp

Orologio

dominio 24

profilo g.8275.1 tipo orologio T-BC

Il profilo 8275.1 viene utilizzato con il ruolo orologio per essere l'orologio di confine T-BC

!

profilo T-BC-MasterClock

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ethernet

il trasporto ethernet è in uso

stato porta solo MasterClock

lo stato della porta da utilizzare è solo MasterClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

profilo T-BC-SLAVE

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ethernet

il trasporto ethernet è in uso

stato porta solo SlaveClock

lo stato della porta da utilizzare è solo SlaveClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

!

interfaccia TenGigE0/0/0/18

Interfaccia MasterClock. Porta collegata a SlaveClock downstream

ptp

ptp abilitato per questa porta

profilo T-BC-MasterClock

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 120

l'attributo localPriority utilizzato come interrompente nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati da confrontare siano uguali

!

!

interfaccia TenGigE0/0/0/19

Interfaccia SlaveClock. Porta connessa a MasterClock upstream

ptp

ptp abilitato per questa porta

profilo T-BC-SLAVE

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 130

!

!

SyncE

sincronizzazione della frequenza

Abilitazione globale

opzione itu-t di qualità 1

Il QL dell'orologio ricevuto è indicato dall'opzione 1

modifiche selezione registro

!

interfaccia TenGigE0/0/0/19

Interfaccia SlaveClock. Porta connessa a MasterClock upstream

sincronizzazione della frequenza

Abilita syncE sull'interfaccia

ingresso selezione

Interfaccia nello stato SlaveClock per SyncE

priorità 15

significativo a livello locale.

gestire la selezione dell'orologio modificando la priorità delle origini dell'orologio

attesa del ripristino 0

Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrona appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi

!

interfaccia TenGigE0/0/0/18

Interfaccia MasterClock. Porta collegata a SlaveClock downstream

sincronizzazione della frequenza

Abilita syncE sull'interfaccia

attesa del ripristino 0

Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrona appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi

OrologioMaster

Configurazione

Spiegazione

ptp

ptp

Abilitazione globale del ptp

orologio

dominio 24

profilo g.8275.1 tipo orologio T-GM

Il profilo 8275.1 viene utilizzato con il ruolo orologio per essere T-GM telecom grand MasterClock

!

profilo T-MasterClock

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ethernet

il trasporto ethernet è in uso

stato porta solo MasterClock

lo stato della porta da utilizzare è solo MasterClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

!

interfaccia TenGigE0/0/0/18

Interfaccia MasterClock. Porta collegata a SlaveClock downstream

ptp

ptp abilitato per questa porta

profilo T-MasterClock

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 120

l'attributo localPriority utilizzato come interrompente nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati da confrontare siano uguali

!

!

!

SyncE

sincronizzazione della frequenza

Abilitazione globale

opzione itu-t di qualità 1

Per configurare le opzioni del livello di qualità ITU-T (QL). Anche l'opzione ITU-T 1 è quella predefinita

modifiche selezione registro

abilitare la registrazione

!

interfaccia TenGigE0/0/0/18

Interfaccia MasterClock. Porta collegata a SlaveClock downstream

sincronizzazione della frequenza

Abilita syncE sull'interfaccia

attesa del ripristino 0

Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrona appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi

SlaveClock

Configurazione

Spiegazione

ptp

ptp

Abilitazione globale del ptp

orologio

dominio 24

profilo g.8275.1 tipo orologio T-TSC

Il profilo 8275.1 viene utilizzato con il ruolo orologio per essere T-TSC telecom SlaveClock

!

profilo T-SLAVE

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ethernet

il trasporto ethernet è in uso

stato porta solo SlaveClock

lo stato della porta da utilizzare è solo SlaveClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

!

interfaccia TenGigE0/0/0/19

Interfaccia SlaveClock. Porta connessa a MasterClock upstream

ptp

ptp abilitato per questa porta

profilo T-SLAVE

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 120

l'attributo localPriority utilizzato come interrompente nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati da confrontare siano uguali

!

!

!

SyncE

sincronizzazione della frequenza

Abilitazione globale

opzione itu-t di qualità 1

Per configurare le opzioni del livello di qualità ITU-T (QL). Anche l'opzione ITU-T 1 è quella predefinita

modifiche selezione registro

abilitare la registrazione

!

interfaccia TenGigE0/0/0/19

Interfaccia SlaveClock. Porta connessa a MasterClock upstream

sincronizzazione della frequenza

Abilita syncE sull'interfaccia

ingresso selezione

Interfaccia nello stato SlaveClock per SyncE

priorità 15

significativo a livello locale.

gestire la selezione dell'orologio modificando la priorità delle origini dell'orologio

attesa del ripristino 0

Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrona appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi

!

8275.2:

Orologio

Configurazione

Spiegazione

ptp

ptp

orologio

dominio 44

profilo g.8275.2 tipo orologio T-BC

Il profilo 8275.2 viene utilizzato con il ruolo orologio per essere l'orologio di confine T-BC

!

profilo T-BC-MasterClock

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ipv4

il trasporto ethernet è in uso

stato porta solo MasterClock

lo stato della porta da utilizzare è solo MasterClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

profilo T-BC-SLAVE

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ipv4

il trasporto ethernet è in uso

stato porta solo SlaveClock

lo stato della porta da utilizzare è solo SlaveClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

!

interfaccia TenGigE0/0/0/18

Interfaccia MasterClock. Porta collegata a SlaveClock downstream

ptp

ptp abilitato per questa porta

profilo T-BC-MasterClock

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 120

l'attributo localPriority utilizzato come interrompente nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati da confrontare siano uguali

!

!

interfaccia TenGigE0/0/0/19

Interfaccia SlaveClock. Porta connessa a MasterClock upstream

indirizzo ip 10.0.0.1 255.255.255.252

ptp

ptp abilitato per questa porta

profilo T-BC-SLAVE

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 130

MasterClock ipv4 10.0.0.2 255.255.255.252

Citare in modo esplicito l'indirizzo IP MasterClock

!

OrologioMaster

Configurazione

Spiegazione

ptp

ptp

Abilitazione globale del ptp

orologio

dominio 44

profilo g.8275.2 tipo orologio T-GM

Il profilo 8275.1 viene utilizzato con il ruolo orologio per essere T-GM telecom grand MasterClock

!

profilo T-MasterClock

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ipv4

il trasporto ethernet è in uso

stato porta solo MasterClock

lo stato della porta da utilizzare è solo MasterClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

!

interfaccia TenGigE0/0/0/18

Interfaccia MasterClock. Porta collegata a SlaveClock downstream

ptp

ptp abilitato per questa porta

profilo T-MasterClock

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 120

l'attributo localPriority utilizzato come interrompente nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati da confrontare siano uguali

!

!

!

SlaveClock

Configurazione

Spiegazione

ptp

ptp

Abilitazione globale del ptp

orologio

dominio 44

profilo g.8275.2 tipo orologio T-TSC

Il profilo 8275.1 viene utilizzato con il ruolo orologio per essere T-TSC telecom SlaveClock

!

profilo T-SLAVE

Definire un ruolo per la porta ptp.

indirizzo-destinazione multicast ethernet 01-80-C2-00-00-0E

È in uso un indirizzo multicast non inoltrabile (facoltativo)

transport ipv4

il trasporto ethernet è in uso

stato porta solo SlaveClock

lo stato della porta da utilizzare è solo SlaveClock

frequenza di sincronizzazione 16

I pacchetti sincronizzati verranno inviati con una frequenza di pacchetti al secondo

frequenza annuncio 8

I pacchetti di annuncio verranno inviati con una frequenza di pacchetti al secondo

frequenza delay-request 16

I pacchetti Delay_Req verranno inviati con una frequenza di pacchetti al secondo

!

!

interfaccia TenGigE0/0/0/19

Interfaccia SlaveClock. Porta connessa a MasterClock upstream

indirizzo ip 10.0.0.1 255.255.255.252

ptp

ptp abilitato per questa porta

profilo T-SLAVE

Il ruolo definito dall'utente viene chiamato in questa porta PTP

local-priority 120

l'attributo localPriority utilizzato come interrompente nell'algoritmo di confronto dei set di dati, nel caso in cui tutti gli altri attributi precedenti dei set di dati da confrontare siano uguali

MasterClock ipv4 10.0.0.2 255.255.255.252

menzionare in modo esplicito l'indirizzo IP MasterClock

!

!

!

Se non si ricevono pacchetti ESMC sull'interfaccia o se SyncE non è configurato alla fine della porta, ma si desidera comunque abilitare syncE. A tale scopo, è possibile definire in modo statico il valore QL sull'interfaccia e disattivare SSM.

SyncE

sincronizzazione della frequenza

opzione itu-t di qualità 1

modifiche selezione registro

!

interfaccia TenGigE0/0/0/19

sincronizzazione della frequenza

ssm disable

qualità ricezione esatta opzione itu-t 1 PRC

ingresso selezione

priorità 15

attesa del ripristino 0

!

Per usare la modalità ibrida con 8275.2, usare la ‘frequenza-strato-fisico’ sotto l'interfaccia. Ciò abilita SyncE per frequenza e ptp per fase.

Per abilitare la modalità ibrida con 8275.2, è necessario configurare la ‘frequenza-livello fisico’ in ptp globale.

ptp

orologio

dominio 44

profilo g.8275.2 tipo orologio T-BC

!

profilo 82752

transport ipv4

frequenza di sincronizzazione 16

frequenza annuncio 8

frequenza delay-request 16

!

frequenza livello fisico

registro

eventi servo

!

!

Topologia di esempio 8275.1:

Periferica A:

ptp

clock

domain 24

profile g.8275.1 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state SlaveClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

frequency synchronization

quality itu-t option 1

log selection changes

!

interface TenGigE0/0/0/23

description ***to PTP GM***

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

priority 10

wait-to-restore 0

!

!

interface TenGigE0/0/0/19

ptp

profile T-BC-MasterClock

!

frequency synchronization

wait-to-restore 0

!

!

Periferica B:

ptp

clock

domain 24

profile g.8275.1 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state SlaveClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ethernet

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

interface TenGigE0/0/0/23

ptp

profile T-BC-MasterClock

!

!

interface TenGigE0/0/0/19

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

!

!

Topologia di esempio 8275.2:

Periferica A:

ptp

clock

domain 44

profile g.8275.2 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state SlaveClock-only

sync frequency 16

clock operation one-step

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

frequency synchronization

quality itu-t option 1

log selection changes

!

interface TenGigE0/0/0/23

description ***to PTP GM***

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

priority 10

wait-to-restore 0

!

!

interface TenGigE0/0/0/19

ip address 10.0.0.1 255.255.255.252

ptp

profile T-BC-MasterClock

MasterClock ipv4 10.0.0.2 255.255.255.252

!

frequency synchronization

wait-to-restore 0

!

!

Periferica B:

ptp

clock

domain 44

profile g.8275.2 clock-type T-BC

!

profile T-BC-SLAVE

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state SlaveClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

profile T-BC-MasterClock

multicast target-address ethernet 01-80-C2-00-00-0E

transport ipv4

port state MasterClock-only

sync frequency 16

announce frequency 8

delay-request frequency 16

!

!

interface TenGigE0/0/0/19

mtu 9216

ptp

profile T-BC-SLAVE

!

frequency synchronization

selection input

!

!

Risoluzione dei problemi relativi a PTP

Alcuni comandi show e descrivono i relativi output.

1. Lo stato del servo alla fine dell'algoritmo del servo deve essere Phase_Locked. È possibile visualizzare il per il flusso di stato del servo. Se la modalità servo è ibrida, è necessario gestire anche il flusso SyncE poiché il blocco fase si verifica solo dopo Freq_Lock. Se il dispositivo PTP in esecuzione è un MasterClock ordinario, l'output precedente potrebbe non essere valido in quanto l'algoritmo Servo non verrà eseguito e non sarà necessario sincronizzare fase/frequenza da un'altra origine MasterClock.

Lo stato del dispositivo non passa a LOCK a meno che l'offset non rientri in un intervallo accettabile. Controllare anche l'opzione ‘Offset from MasterClock’.

Stato dispositivo:

FREE-RUN/HOLDOVER:  Non bloccato a nessuna origine dell'orologio.

FREQ_LOCKED: Frequenza sincronizzata con MasterClock

FASE_BLOCCATA: Frequenza e fase sincronizzate con MasterClock

Modalità servo:

Ibrido: Utilizzare SyncE per la sincronizzazione della frequenza. PTP viene utilizzato solo per la sincronizzazione di fase.

Predefinito: Utilizzare PTP per sincronizzare frequenza e fase

Differenza di tempo osservata dall'algoritmo servo in bianco e nero SlaveClock e MasterClock.

Contatori per i timestamp estratti dai pacchetti PTP. Dovrebbe continuare a crescere.

Ultimi timestamp T1/T2/T3/T4 (sec.nanosec) estratti dai pacchetti PTP. Devono essere vicini e aumentarsi uniformemente.

T1/T4: Inviato da MasterClock, T2/T3: Calcolato in SlaveClock

Offset Viene calcolato in base ai timestamp PTP.

Regolazioni grossolane (setTime, stepTime) e fini (adjustFreq) eseguite da un servo per allinearsi al MasterClock.

3. show ptp interfaces brief: visualizza lo stato della porta di output. Lo stato deve essere MasterClock/SlaveClock.

4. Il pacchetto che cade dal ptp deve essere significativamente basso.

5. Controllare il motivo del rilascio del pacchetto:

6. I pacchetti non raggiungono il protocollo PTP.

I pacchetti raggiungono la NPU?

NCS (DNX) platforms: show controllers npu stats traps-all instance all location 0/0/CPU0  | inc 1588

RxTrap1588                                    0    71   0x47        32040   7148566              0

ASR9000 platform: show controller np counters <np> location 0/0/cpu0 | inc PTP

Check for PTP_ETHERNET / PTP_IPV4 counters

Packet drops at NPU (not specific to PTP)

NCS (DNX) platforms: show controllers fia diagshell <np> "diag counters g" location 0/0/cpu0

Shows Rx/TX path statistics along with any drops happening in the NPU

ASR9000 platform: show drops all location <LC>

Controllare le cadute all'SPP:

show spp node-counters location 0/0/cpu0

# Check for any drop-counters incrementing

NCS (DNX) platforms: show spp trace platform common error last 20 location 0/0/cpu0

Dec 10 02:29:38.322 spp/fretta/err 0/0/CPU0 t2902 FRETTA SPP classify RX:

Failed in dpa_punt_mapper; ssp: 0x1e, inlif: 0x2000, rif: 0x11;

trap_code:FLP_IEEE_1588_PREFIX punt_reason:PTP-PKT pkt_type:L2_LOCALSWITCH rc:

'ixdb' detected the 'fatal' condition 'Not found in database': No such file or directory

ASR9000 platforms:

SPP punt path is simpler in ASR9000 with no risk of a lookup failure.

Drops not expected during packet classification.

7. show ptp packet-counters <id-interfaccia> mostra il flusso del pacchetto. Assicurarsi che syncàDelay_RequestDelay_Resp sia seguito (e Follow_Up se è un clock a due passi).

8. Controllare il flag (S) per l'interfaccia selezionata.

9. Controllare il QL ricevuto. Sull'interfaccia selezionata, QLsnd sarà DNU per impedire loop. Per modificare le preferenze dell'interfaccia, è possibile modificare l'attributo di priorità che per impostazione predefinita è 100.

10. Assicurarsi che l'uscita guidata da sia l'interfaccia SyncE selezionata.

11. show ptp foreign-MasterClocks brief output è l'elenco dei dispositivi ptp che partecipano al BMCA e che diventano MasterClock. Controllare i flag corrispondenti per visualizzare il MasterClock selezionato. è possibile visualizzare i messaggi di annuncio ricevuti da queste porte tramite show ptp packet-counters <id-interfaccia>. Il dispositivo con gli attributi migliori vincerà il BMCA. Se più porte hanno gli stessi attributi, local-priority sarà l'ultimo time-breaker. Tuttavia, la definizione automatica della topologia è possibile anche con il ptp senza utilizzare la priorità locale.

12. Ptp non seleziona il MasterClock (BMCA) desiderato.

Controllare l'orologio annunciato dal nodo remoto:

show ptp foreign-MasterClocks

Interface TenGigE0/9/0/2 (PTP port number 1)

IPv4, Address X.X.X.X, Unicast

Configured priority: None (128)

Configured clock class: None

Configured delay asymmetry: None

Announce granted:   every 16 seconds,  1000 seconds

Sync granted:       every 16 seconds,  1000 seconds

Delay-resp granted: 64 per-second,     1000 seconds

Qualified for 4 hours, 50 minutes, 6 seconds

Clock ID: 1

Received clock properties:

Domain: 44, Priority1: 128, Priority2: 128, Class: 6

Accuracy: 0x21, Offset scaled log variance: 0x4e5d

Steps-removed: 1, Time source: Atomic, Timescale: PTP

Frequency-traceable, Time-traceable

Current UTC offset: 38 seconds (valid)

Parent properties:

Clock ID: 1

Port number: 1

Elenco di MasterClock qualificati e selezionati:

show ptp foreign-MasterClocks brief

M=Multicast,X=Mixed-mode,Q=Qualified,D=QL-DNU,

GM=GrandMasterClock,LA=PTSF_lossAnnounce,LS=PTSF_lossSync

Interface         Transport Address                   Cfg-Pri  Pri1   State

----------------------------------------------------------------------------

Te0/0/0/12        Ethernet  008a.9691.3830            None     128    M,Q,GM

Controllare l'orologio annunciato al MasterClock:

show ptp advertised-clock

Clock ID: 8a96fffe9138d8

Clock properties:

Domain: 24, Priority1: 128, Priority2: 128, Class: 6

Accuracy: 0xfe, Offset scaled log variance: 0xffff

Time Source: Internal (configured, overrides Internal)

Timescale: PTP (configured, overrides PTP)

No frequency or time traceability

Current UTC offset: 0 seconds

13. Ptp non in sincronizzazione con MasterClock:

•Intended PTP MasterClock selected.

•PTP session established

•But not able to synchronize with the MasterClock

show ptp interface brief

Intf                    Port              Port            Line

Name              Number       State          Encap       State         Mechanism

--------------------------------------------------------------------------------

Te0/0/0/12        1            Uncalibrated Ethernet   up            1-step DRRM

OR occasional PTP flap in the field

Jul 31 09:29:43.114 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state PHASE_LOCKED to state HOLDOVER

Jul 31 09:30:23.116 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state HOLDOVER to state FREQ_LOCKED

ul 31 09:35:28.134 UTC: ptp_ctrlr[1086]: %PLATFORM-PTP-6-SERVO_EVENTS : PTP Servo state transition from state FREQ_LOCKED to state PHASE_LOCKED

14. Verificare se il protocollo PTP è sceso a causa della perdita di pacchetti:

show ptp trace last 100 location 0/rp0/cpu0

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Updated checkpoint record for clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0): Checkpoint ID 0x40002f60

Aug  1 02:35:01.616 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Inserted clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) into BMC list at position 0

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Comms] Received BMC message from node 0/0/CPU0. Comms is active

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Removed clock 0x8a96fffe9138d8 (Ethernet 008a.9691.3830) from node 0/0/CPU0(0x0) from BMC list

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] GrandMasterClock removed, local clock better than foreign MasterClock(s)

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Leap Seconds] GrandMasterClock lost

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Stopping servo

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] BMC servo stopped, BMC servo not synced

Aug  1 02:35:46.035 ptp/ctrlr/det 0/RP0/CPU0 t18625 [Comms] Started grandMasterClock message damping timer

Aug  1 02:35:46.035 ptp/ctrlr/sum 0/RP0/CPU0 t18625 [Platform] Sending SlaveClock update to platform. No grandMasterClock available

Aug  1 02:35:46.059 ptp/ctrlr/det 0/RP0/CPU0 t18625 [BMC] Received clock update from the platform. Clock active, not using PTP for frequency, using PTP for time. Current local clock is not a primary ref, sync state is 'Sync' and QL is 'Opt-I/PRC'

15. Controllare l'output di show ptp configuration-errors per eventuali errori di configurazione.

Esempi di acquisizioni di pacchetti di messaggi Sync, Announce, Delay_Req e Delay_Resp

L'acquisizione del messaggio di annuncio (8275.1) mostra le caratteristiche dell'orologio trasmesso:

L'acquisizione del messaggio Sync mostra la generazione del timestamp (in un unico passaggio).

Informazioni correlate

- https://www.itu.int/rec/T-REC-G.8275.1/en

- https://www.itu.int/rec/T-REC-G.8275.2/en

- Standard IEEE per 1588v2

- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/sysman/configuration/guide/b-sysman-cg-53xasr9k/b-sysman-cg-53xasr9k_chapter_01100.html

- Documentazione e supporto tecnico – Cisco Systems