PTP in ambiente Broadcast
Utilizzo di PTP in ambiente Broadcast
1. Introduzione
Questo articolo oltre a fornire una panoramica generale del trasferimento di tempo estremamente accurato su reti Ethernet mediante PTP, il protocollo di timing per l'industria broadcast, spiega lo scambio di messaggi e i processi di elezione dei un grandmaster PTP. Descriveremo il processo di selezione di un PTP GM in modo dettagliato, concentrandoci sui diversi stati che un dispositivo PTP o, per essere più precisi, una porta PTP può assumere. Dopo aver brevemente descritto il concetto di interfacce PTP, stati PTP e le rispettive transizioni, saranno spiegate in dettaglio le diverse classi di dispositivi PTP. Per concludere, il confronto degli apparati di rete PTP aware e infine la descrizione dei componenti di base di uno stack PTP software.
2 Porte PTP vs. Porte Fisiche
IEEE1588 è stato specificato come protocollo di trasferimento temporale da implementare su architetture di rete che supportano almeno un po' di messaggistica multicast, cioè in grado di consentire ai messaggi di essere indirizzati a più di un destinatario. Pertanto, IEEE 1588 può essere mappato su reti diverse utilizzando vari protocolli di trasporto. Nel rigoroso contesto di IEEE1588, una porta PTP è considerata un'entità in grado di elaborare i messaggi PTP. Si presume che abbia due interfacce distinte, una per l'elaborazione dei messaggi PTP generali e l'altra per la gestione dei messaggi di eventi PTP "Event Messages", ad esempio messaggi contenenti informazioni sul tempo. Ogni porta PTP esegue una singola istanza dello stack del protocollo PTP utilizzando un protocollo di trasporto specifico. È importante notare che più di una porta PTP può essere mappata su una singola porta fisica, nel nostro caso una porta Ethernet. Il vantaggio di questa distinzione tra porta fisica e porta PTP diventa evidente quando consideriamo un dispositivo PTP multiporta come un Boundary Clock. Ogni porta PTP può essere configurata individualmente rispetto a tutti i parametri PTP come velocità dei messaggi, domini PTP o dati relativi al trasporto. Un Boundary Clock, quindi, può collegare tra loro diverse sottoreti PTP. Inoltre, questo concetto facilita l'implementazione di PTP su più VLAN (reti locali virtuali) senza alcuna restrizione. Una tipica configurazione di Boundary Clock che mostra diverse assegnazioni di porte PTP a porte fisiche è mostrata in Figura 1. In generale, i dispositivi terminali noti come Ordinary Clock funzionerebbero usando una singola porta PTP. Tuttavia, se si considera la ridondanza estesa, il concetto di diverse porte PTP è utile anche per i dispositivi PTP Slave.
3 BMCA Best Master Clock Algorithm
A differenza di altri protocolli di trasferimento di tempo comuni come NTP, tutti i dispositivi (porte PTP) all'interno di una rete PTP assumono i rispettivi ruoli senza alcuna interazione dell'utente durante il normale funzionamento. La rete seleziona autonomamente un dispositivo per diventare il suo PTP Gran Master (GM). È importante notare che solo un dispositivo PTP alla volta può diventare PTP Grandmaster, mentre più di una porta PTP può assumere il ruolo PTP Master (nel caso di un PTP Boundary Clock). Il processo di selezione è regolato da una serie di parametri PTP che descrivono la qualità del clock. Questi dati vengono comunicati continuamente tramite i messaggi di Announce. Ogni slave PTP, ad esempio, sa se il GM sta ricavando le sue informazioni temporali da un riferimento temporale tracciabile esterno tramite un collegamento GNSS (Global Navigation Satellite System) come GPS, Galileo o GLONASS. Se tutte le porte PTP ricevono i messaggi di announce alla velocità prevista senza alcuna modifica dei parametri contenuti in questi messaggi, rimangono nei rispettivi stati. Tuttavia, il BMCA viene eseguito ogni volta che viene ricevuto un messaggio di announce. Il suo contenuto viene confrontato con i dati locali e se questi due set di dati corrispondono al 100%, non vengono intraprese ulteriori azioni. A meno che una porta PTP non funzioni come un master PTP, il suo stato può cambiare solo in due condizioni: in entrambi i casi, se i dati del messaggio di announce più recente differiscono dal messaggio precedente o se non è stato ricevuto alcun messaggio di announce per un periodo di tempo predefinito . Quest'ultimo parametro è definito tramite il numero di messaggi di announce consecutivi mancanti. Insieme alla frequenza dei messaggi di announce che deve essere specificata dall'utente per ogni porta PTP, lo stack del protocollo PTP è in grado di calcolare il periodo di timeout. Il BMCA definisce esattamente come devono essere confrontati due set di dati. Questi potrebbero essere il set di dati locale rispetto a un messaggio di announce in arrivo o il contenuto di due messaggi di announce inviati da diversi PTP master durante il processo di elezione effettivo. I set di dati vengono confrontati valore per valore. Ciò garantisce che tutte le porte PTP raggiungano la stessa conclusione, ovvero scelgano uniformemente lo stesso Best Master PTP. Sebbene un Master PTP invierà messaggi di announce, deve comunque ascoltare ed elaborare i messaggi di announce in arrivo nello stesso modo descritto sopra. Se per esempio si accorge che il Master PTP che ha inviato quel messaggio di announce ha un orologio migliore del proprio, lui dovrà arretrare. A seconda della sua configurazione, diventerebbe uno slave PTP o passerà allo stato Passive Master. Questa funzione assicura che il Best Master subentri sempre indipendentemente da quando è stato collegato alla rete. In generale, ogni nodo all'interno di una rete PTP può diventare GM. Ciò è particolarmente utile per le applicazioni in cui una nozione comune di tempo è molto più importante da mantenere rispetto al collegamento a un riferimento temporale esterno. Se, d'altra parte, la rete deve fare affidamento su un tempo assoluto preciso, la rete dovrebbe avere diversi GM, ciascuno collegato a una o più fonti temporali GNSS. Questi sarebbero configurati in modo tale che uno diventi GM mentre gli altri passano allo stato Passive. Se il GM attivo fallisce, i GM rimanenti parteciperanno attivamente al BMCA e uno dei dispositivi assumerà il ruolo di GM. Tali configurazioni implicano che tutti gli altri nodi non saranno in grado di assumere il ruolo di PTP Master. Ciò può essere realizzato configurando i rispettivi parametri nei messaggi di announce. Nel nostro esempio sarebbe il parametro PTP Clock Class. I Boundary Clock devono combinare i dati raccolti da ciascuna delle rispettive porte durante ogni round BMCA per raggiungere una conclusione comune su quale porta dovrebbe passare allo stato PTP Slave in base alle informazioni sul tempo ricevute, mentre tutte le altre porte passeranno a Master fornendo informazioni sull'ora . Prima di elaborare i diagrammi di stato per diverse classi di dispositivi PTP, viene brevemente spiegato il concetto di dominio PTP.
4 Domini PTP
Dispositivi PTP comunicano utilizzando un dominio PTP comune. Questo è un parametro configurabile dall'utente che fa parte dell'intestazione di ogni messaggio PTP. Lo standard IEEE1588 afferma esplicitamente che una porta PTP può funzionare in un solo dominio PTP alla volta. Di conseguenza, lo stack del protocollo PTP in esecuzione su una porta PTP deve verificare il numero di dominio di ogni messaggio PTP e scarterà tutti i messaggi PTP con il numero di dominio errato (diverso da quello su cui è configurata la porta PTP) senza elaborarne il contenuto ulteriormente.
5 Transizioni degli stati PTP di uno slave
La Figura 2 mostra il diagramma di stato di un dispositivo Slave PTP, ovvero una porta PTP che non assumerà mai il ruolo PTP Master, partecipando così passivamente al BMCA. Ciò può essere ottenuto impostando di conseguenza i parametri per i messaggii di announce, ad esempio impostando il parametro Clock Class sul valore più basso, ovvero su 255. Dopo aver inizializzato tutti i parametri PTP con i loro valori predefiniti o preconfigurati, la porta entra nello stato di Listening pronta a ricevere i messaggi di announce. Rimarrà in quello stato indefinitamente, se non si ricevono messaggi di announce. Ciò può essere dovuto a diversi motivi: nella rete non è presente alcun master PTP, poiché tutti i dispositivi (porte) compatibili con il master sono offline, disabilitati o non raggiungibili. Se ciò può essere escluso, è necessario verificare le impostazioni del dominio PTP. Non appena il dispositivo seleziona un Master PTP passerà allo stato Uncalibrated iniziando a valutare i dati dei messaggi di sincronizzazione mentre inizia a inviare messaggi Delay_Request. Se riceve la risposta corretta dal Master tramite i corrispondenti messaggi Delay_Response, passa infine allo stato Slave PTP, perché ora è in grado di calcolare con precisione l'offset e il ritardo di trasmissione, consentendogli di sincronizzare il suo clock locale con il Master. Sebbene considerato uno stato transitorio, una porta PTP può rimanere "Uncalibrated". Ciò indica che il trasferimento temporale a valle non funziona correttamente. Ciò può significare che i messaggi Delay_Request non vengono inoltrati correttamente al Master o non elaborati da esso. Un altro motivo potrebbe essere che i messaggi Delay_Response non vengono trasmessi dal Master o viene utilizzato un protocollo di trasporto errato.
6 Transizioni di stato PTP di un Grandmaster PTP
La Figura 3 mostra il diagramma di stato di una porta PTP che funge da Grandmaster PTP. In genere, questi sono direttamente collegati a un riferimento GNSS. O assumono il ruolo di PTP Master o diventano Passivi piuttosto che passare allo stato Slave nel caso in cui un Master migliore entri nella rete. Nella maggior parte delle implementazioni PTP, più dispositivi PTP GM sono distribuiti, tuttavia, dal punto di vista del protocollo PTP, solo uno può essere attivo mentre gli altri sono dispositivi hot-standby. Poiché sono tutti collegati a sorgenti GNSS, annunciano la stessa qualità di clock. Come tiebreaker, il BMCA confronta l'indirizzo mac del proprio clock (un numero univoco assegnato a ciascun dispositivo). Se una porta PTP è in stato passivo, non trasmetterà messaggi e non risponderà a quelli ricevuti. Tuttavia, elaborerà tutti i messaggi di announce in arrivo in base alle regole del BMCA.
7 Transizioni di stato PTP di una porta PTP generale
Infine, il diagramma di stato di una porta PTP generale è mostrato nella Figura 4. Tale porta può assumere sia il ruolo Master PTP che Slave PTP. Nel caso in cui il PTP Master migliore non sia disponibile, il Master passerà da listening a master. Se un Master migliore torna nella rete, tornerà allo stato Slave.
8 Osservazioni finali sugli Stati PTP
Nelle figure 3 e 4, rispettivamente, viene mostrato uno stato di transizione denominato Pre-Master. Questo stato è stato aggiunto nel protocollo per evitare loop BMCA che potrebbero verificarsi in determinate condizioni durante i cambiamenti Master nelle reti con Boundary Clocks. Questo stato viene sia inserito che lasciato incondizionatamente, ritardando efficacemente il passaggio allo stato Master. Viene monitorato lo stato corrente di tutti i dispositivi (porte) in una rete PTP. In caso contrario, i diagrammi di stato possono fungere da punto di partenza per un'analisi approfondita. Infine, tutti e tre i diagrammi di stato mostrano due stati aggiuntivi: Disabled e Faulty. La prima indica che una porta PTP è stata disabilitata dall'utente mentre la seconda indica che si è verificata una condizione di errore. Le porte PTP in uno di questi stati cessano di elaborare i messaggi PTP diversi dai messaggi di gestione PTP. Quindi, il loro stato e la configurazione possono ancora essere monitorati e il relativo set di parametri aggiornato esternamente.
9 Blocchi costitutivi di uno stack software PTP
A parte i moduli hardware da aggiungere a ogni porta Ethernet per applicare timestamp sufficientemente precisi, uno stack di protocollo PTP deve essere eseguito per ogni porta PTP. I suoi compiti principali sono, ovviamente, l'elaborazione di tutti i messaggi PTP in arrivo, l'esecuzione del BMCA e la trasmissione tempestiva dei messaggi. Fortunatamente, quest'ultimo requisito lascia un po 'di spazio per l'implementatore, perché secondo IEEE1588 deve essere soddisfatta solo la velocità media dei messaggi, piuttosto che richiedere una velocità molto costante con tempi di invio rigorosi. Pertanto, un sistema operativo real time non è obbligatorio per il funzionamento di PTP. Per soddisfare i requisiti di un profilo specifico, uno stack PTP deve essere in grado di stabilire una comunicazione PTP con il rispettivo protocollo di trasporto. Per SMPTE ST 2059-2 ciò comporta la comunicazione di livello 3 tramite IPv4 o IPv6. Inoltre, specifici tipi di messaggi devono essere inviati tramite multicast (Announce, Sync) mentre altri devono esserlo trasmessi come multicast o unicast (Delay_Request / Response) e infine alcuni sono solo unicast (Management Messages). Parallelamente, lo stack PTP deve continuamente ri-regolare il clock locale per mantenere il suo offset il più basso possibile o almeno entro i limiti richiesti del profilo PTP. Per SMTPE ST 2059-2 questo significa sempre rimanere al di sotto di 1µs rispetto al Master. A tal fine, deve eseguire un loop di controllo dedicato che modifica la frequenza del proprio clock invece che aggiornare soltanto periodicamente il valore del tempo assoluto. Quest'ultimo approccio comporterebbe un tempo non monotonico verso gli Slave con frequenti salti all'indietro nel tempo. Per far fronte a problemi di rete che comportano variazioni del ritardo dei pacchetti, il circuito di controllo deve essere integrato con una serie di fasi del filtro di ingresso. Oltre a smorzare il rumore indotto dalla rete, dovrebbero anche rilevare ed eliminare i pacchetti che hanno dovuto affrontare ritardi di trasmissione eccessivi. Questa tecnica combina filtri lineari e non lineari (quest'ultimo basato sull'analisi dei dati statistici), che ha dimostrato di essere molto superiore ai filtri lineari anche complessi quando si tratta di PDV arbitrari, che purtroppo non sono né distribuiti uniformemente né seguono una curva gaussiana. Questo è il caso specifico se una rete con più switch in cascata viene sovraccaricata in modo transitorio. Anche nelle reti con un supporto PTP parziale, questo approccio ha i suoi meriti rispetto alle implementazioni di base. Infine, uno stack PTP professionale dovrebbe fornire mezzi efficienti per il monitoraggio di importanti parametri PTP come i rate dei messaggi, il numero di messaggi PTP persi, i cambiamenti di stato e, naturalmente, l'offset dal Master, per citarne solo alcuni.
10 Migliorare la precisione: Transparent Clock e Boundary Clock
Per raggiungere in modo coerente e affidabile precisioni ben al di sotto di 1 µs senza imporre alcun vincolo al carico di rete e alla topologia, è necessario prendere in considerazione l'utilizzo di dispositivi di rete PTP aware. IEEE1588 definisce due diverse soluzioni per far fronte ai PDV: Transparent Clock e Boundary Clock. La funzione principale di entrambi è stata descritta nella parte 1; qui vogliamo confrontarli dal punto di vista dell'utente finale. Va sottolineato che, per quanto riguarda la precisione, entrambi i dispositivi producono risultati identici, se i rispettivi moduli hardware (unità di scansione dei pacchetti e timestamp) hanno le stesse prestazioni. I Transparent Clock inoltrano i messaggi PTP seguendo le stesse regole di livello 2 e di livello 3 che si applicherebbero a qualsiasi altro traffico. Misurando il tempo di permanenza di ogni messaggio di evento PTP e inserendo queste informazioni nel messaggio, consentono agli Slave PTP di tenere conto di qualsiasi variazione in modo molto efficace. Non partecipano al BMCA. I Boundary Clock, d'altra parte, possono essere considerati dispositivi PTP attivi. Elaborano tutto il traffico PTP in entrata in base al protocollo PTP anziché inoltrarlo in base alle rispettive regole IP e partecipano al BMCA. Rigenerando le informazioni temporali fornite dal Best Master e ridistribuendole a tutti gli slave ptp ad essi collegati, possono essere visti come un mezzo per costruire un'architettura gerarchica di trasferimento temporale. Di conseguenza, il traffico PTP complessivo (a livello di rete) è notevolmente ridotto, poiché i messaggi PTP vengono scambiati solo tra due dispositivi adiacenti anziché essere trasmessi attraverso la rete completa, come nel caso di Transparent Clock. Vi sono, tuttavia, alcune avvertenze da considerare quando si scelgono BoundaryClock rispetto a TransparentClock. Essendo i BC PTP dispositivi PTP attivi con più porte PTP che eseguono tutte il BMCA, devono essere monitorati molto più da vicino rispetto agli TC PTP, per i quali la supervisione è abbastanza semplice da realizzare. Inoltre, il comportamento e le prestazioni dei circuiti di controllo implementati nei Boundary Clocks dovrebbero essere attentamente valutati durante il loro dispiegamento, specialmente quando vengono commissionate reti di grandi dimensioni, dove devono essere messi in cascata numerosi BC. Di particolare interesse in tali casi è il loro comportamento durante un fail del Grandmaster.
