Nozioni di base sugli standard PTP e SyncE nelle configurazioni Cisco IOS XR

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 cristalli 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.) 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 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 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₁=t_2^.

NTP e PTP vengono utilizzati per trasferire le 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.

Di seguito è riportato un semplice esempio. 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 di 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. Pertanto, è necessario assegnare una priorità ai collegamenti in modo da scegliere il dispositivo upstream appropriato per quanto riguarda gli hop, i 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 temporizzazione 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, dato il potenziale di creazione di 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 eventi 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 nei modi seguenti:
   • 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

L'insieme 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 all'esterno di una porta, quindi in due passaggi ciò era dovuto a limitazioni hardware. Al giorno d'oggi, l'hardware può registrare il punto tempo 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 le 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 è costituito da:

• 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 ordinario - 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 gli 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 in cui una porta è pronta a partecipare a PTP: la porta resta 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 collegamento 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 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 obbligatorie, 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 di 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 e 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

Deve essere sostenuto 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 del GM sul riferimento primario? ad esempio: tempo preciso entro 25 ns.
Scostamento log scalato offset (OSLV, Offset 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 questo Suggerimento 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, mentre altri possibili casi sono destinati a 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 che i T-BC di una rete a monte si sincronizzino con i T-BC di una rete a valle quando il 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 sull'aggregazione dei collegamenti:

Quando due dispositivi che incorporano orologi PTP conformi a questo profilo sono connessi tramite un'aggregazione di collegamenti (LAG, link aggregation), è 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. Di seguito vengono fornite ulteriori considerazioni.

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 appropriato di questo indirizzo multicast nel database di filtraggio.

• 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 consiste nel fatto 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à la BMCA e selezionerà BC4 come proprio orologio padre in base al fatto che i passi - il valore rimosso di BC4 è 1, rispetto a un valore rimosso dai passi 3 per BC3. SlaveClock avrebbe quindi richiesto 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 ottenere 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 può essere configurato in modo 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 ha esito negativo, non sarà disponibile alcun percorso per ottenere i pacchetti IP compresi tra 11.x.x.141 e 11.y.y.104, quindi SlaveClock non riceverà 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 di 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 che vengono ricevuti su quell'interfaccia verranno scartati. 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à Freq/Phase Locked:

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 di tempo 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 di simile a 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 limite
	Configurazione	Spiegazione
ptp	ptp
	Clock
	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-only	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 connessa 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	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	QL dell'orologio ricevuto è indicato dall'opzione 1 itu-t
	modifiche alla selezione del registro
	!
	interfaccia TenGigE0/0/0/19	SlaveClock. Porta connessa a MasterClock upstream
	sincronizzazione della frequenza	Abilita syncE sull'interfaccia
	input di 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
	wait-to-restore 0	Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrono appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi
	!
	interfaccia TenGigE0/0/0/18	Interfaccia MasterClock. Porta connessa a SlaveClock downstream
	sincronizzazione della frequenza	Abilita syncE sull'interfaccia
	wait-to-restore 0	Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrono appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi
	OrologioMaster
	Configurazione	Spiegazione
ptp	ptp	Attivazione globale del protocollo ptp
	clock
	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-only	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 connessa 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 ITU-T quality level (QL). Anche l'opzione ITU-T 1 è quella predefinita
	modifiche alla selezione del registro	abilitare la registrazione
	!
	interfaccia TenGigE0/0/0/18	Interfaccia MasterClock. Porta connessa a SlaveClock downstream
	sincronizzazione della frequenza	Abilita syncE sull'interfaccia
	wait-to-restore 0	Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrono appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi
	SlaveClock
	Configurazione	Spiegazione
ptp	ptp	Attivazione globale del protocollo ptp
	clock
	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	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 ITU-T quality level (QL). Anche l'opzione ITU-T 1 è quella predefinita
	modifiche alla selezione del registro	abilitare la registrazione
	!
	interfaccia TenGigE0/0/0/19	SlaveClock. Porta connessa a MasterClock upstream
	sincronizzazione della frequenza	Abilita syncE sull'interfaccia
	input di 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
	wait-to-restore 0	Il tempo di attesa del router prima di includere una sorgente dell'orologio Ethernet sincrono appena attiva nella selezione dell'orologio. Il valore predefinito è 300 secondi
	!

8275.2:

	Orologio limite
	Configurazione	Spiegazione
ptp	ptp
	clock
	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-only	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 connessa 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	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	Attivazione globale del protocollo ptp
	clock
	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-only	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 connessa 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	Attivazione globale del protocollo ptp
	clock
	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	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 esplicitamente 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 disabilitare SSM.

SyncE	sincronizzazione della frequenza
	opzione itu-t di qualità 1
	modifiche alla selezione del registro
	!
	interfaccia TenGigE0/0/0/19
	sincronizzazione della frequenza
	ssm disable
	qualità ricezione esatta opzione itu-t 1 PRC
	input di selezione
	priorità 15
	wait-to-restore 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

clock

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 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’ (Offset da MasterClock).

Stato dispositivo:

FREE-RUN/HOLDOVER: non bloccato ad alcuna sorgente di clock. 
FREQ_LOCKED: frequenza sincronizzata con MasterClock

PHASE_LOCKED: 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 la sincronizzazione di 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 con 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 mostra lo stato della porta di output. Lo stato deve essere MasterClock/SlaveClock.

4. Il pacchetto che viene scartato dal ptp deve essere significativamente basso.

5. Controllare il motivo del rilascio del pacchetto:

6. I pacchetti non raggiungono 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 gocce 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 l'utilizzo di local-priority.

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 è stato interrotto 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