2. Architettura del Sistema

Nel modello NTP, un certo numero di fonti di riferimento primarie (primary reference sources), sincronizzate via cavo o radio con gli standard nazionali, sono connesse a risorse ampiamente accessibili, come gateway backbone, e gestite come server di tempo primari. Lo scopo di NTP è trasmettere informazioni di cronometraggio da questi server ad altri server di tempo via Internet e anche verificare gli orologi e mitigare gli errori dovuti a guasti di attrezzature o propagazione. Un certo numero di host di rete locale o gateway, che agiscono come server di tempo secondari, eseguono NTP con uno o più dei server primari. Al fine di ridurre il sovraccarico del protocollo, i server secondari distribuiscono il tempo via NTP agli host di rete locale rimanenti. Nell'interesse dell'affidabilità, gli host selezionati possono essere dotati di orologi radio meno accurati ma meno costosi e utilizzati per il backup in caso di guasto dei server primari e/o secondari o dei percorsi di comunicazione tra di essi.

In tutto questo documento è stata adottata una nomenclatura standard: la stabilità (stability) di un orologio è quanto bene può mantenere una frequenza costante, l'accuratezza (accuracy) è quanto bene la sua frequenza e il suo tempo si confrontano con gli standard nazionali e la precisione (precision) è quanto precisamente queste quantità possono essere mantenute all'interno di un particolare sistema di cronometraggio. Salvo diversa indicazione, l'offset (offset) di due orologi è la differenza di tempo tra di essi, mentre lo skew (skew) è la differenza di frequenza (derivata prima dell'offset rispetto al tempo) tra di essi. Gli orologi reali mostrano una certa variazione nello skew (derivata seconda dell'offset rispetto al tempo), che è chiamata deriva (drift); tuttavia, in questa versione della specifica si presume che la deriva sia zero.

NTP è progettato per produrre tre prodotti: offset dell'orologio (clock offset), ritardo di andata e ritorno (roundtrip delay) e dispersione (dispersion), tutti relativi a un orologio di riferimento selezionato. L'offset dell'orologio rappresenta la quantità per regolare l'orologio locale per portarlo in corrispondenza con l'orologio di riferimento. Il ritardo di andata e ritorno fornisce la capacità di lanciare un messaggio per arrivare all'orologio di riferimento in un momento specificato. La dispersione rappresenta l'errore massimo dell'orologio locale rispetto all'orologio di riferimento. Poiché la maggior parte dei server di tempo host si sincronizzerà tramite un altro server di tempo peer, ci sono due componenti in ciascuno di questi tre prodotti: quelli determinati dal peer rispetto alla fonte di riferimento primaria del tempo standard e quelli misurati dall'host rispetto al peer. Ciascuno di questi componenti è mantenuto separatamente nel protocollo al fine di facilitare il controllo degli errori e la gestione della sottorete stessa. Forniscono non solo misurazioni precise di offset e ritardo, ma anche limiti di errore massimo definitivi, in modo che l'interfaccia utente possa determinare non solo il tempo, ma anche la qualità del tempo.

Non c'è alcuna disposizione per la scoperta dei peer (peer discovery) o la gestione del circuito virtuale (virtual-circuit management) in NTP. L'integrità dei dati è fornita dai checksum IP e UDP. Non sono fornite o necessarie strutture di controllo del flusso o ritrasmissione. Il rilevamento dei duplicati (duplicate detection) è inerente agli algoritmi di elaborazione. Il servizio può operare in modalità simmetrica (symmetric mode), in cui server e client sono indistinguibili, ma mantengono una piccola quantità di informazioni di stato, o in modalità client/server (client/server mode), in cui i server non hanno bisogno di mantenere alcuno stato diverso da quello contenuto nella richiesta del client. Una capacità di gestione delle associazioni (association-management) leggera, che include meccanismi di raggiungibilità dinamica (dynamic reachability) e tasso di polling variabile (variable poll-rate), è inclusa solo per gestire le informazioni di stato e ridurre i requisiti di risorse. Poiché viene utilizzato un solo formato di messaggio NTP, il protocollo è facilmente implementato e può essere utilizzato in una varietà di meccanismi di polling sollecitato o non sollecitato.

Dovrebbe essere riconosciuto che la sincronizzazione dell'orologio richiede per sua natura lunghi periodi e confronti multipli al fine di mantenere un cronometraggio accurato. Mentre solo poche misurazioni sono generalmente adeguate per determinare in modo affidabile il tempo locale entro un secondo circa, periodi di molte ore e dozzine di misurazioni sono necessari per risolvere lo skew dell'oscillatore e mantenere il tempo locale all'ordine di un millisecondo. Pertanto, l'accuratezza raggiunta dipende direttamente dal tempo impiegato per raggiungerla. Fortunatamente, la frequenza delle misurazioni può essere abbastanza bassa e quasi sempre non intrusiva per le normali operazioni di rete.

2.1. Modello di Implementazione

In quello che può essere il modello client/server più comune, un client invia un messaggio NTP a uno o più server e elabora le risposte man mano che vengono ricevute. Il server scambia indirizzi e porte, sovrascrive determinati campi nel messaggio, ricalcola il checksum e restituisce il messaggio immediatamente. Le informazioni incluse nel messaggio NTP consentono al client di determinare il tempo del server rispetto al tempo locale e regolare l'orologio locale di conseguenza. Inoltre, il messaggio include informazioni per calcolare l'accuratezza e l'affidabilità del cronometraggio attese, nonché per selezionare il migliore tra diversi server possibili.

Mentre il modello client/server può essere sufficiente per l'uso su reti locali che coinvolgono un server pubblico e forse molti client di workstation, la generalità completa di NTP richiede la partecipazione distribuita di un certo numero di client/server o peer disposti in una configurazione gerarchicamente distribuita e dinamicamente riconfigurabile. Richiede anche algoritmi sofisticati per la gestione delle associazioni, la manipolazione dei dati e il controllo dell'orologio locale. Nel resto di questo documento, il termine host (host) si riferisce a un'istanziazione del protocollo su un processore locale, mentre il termine peer (peer) si riferisce all'istanziazione del protocollo su un processore remoto connesso tramite un percorso di rete.

La Figura 1 mostra un modello di implementazione per un host che include tre processi che condividono un database partizionato, con una partizione dedicata a ciascun peer, e interconnessi da un sistema di passaggio di messaggi. Il processo di trasmissione (transmit process), guidato da timer indipendenti per ciascun peer, raccoglie informazioni nel database e invia messaggi NTP ai peer. Ogni messaggio contiene il timestamp locale (local timestamp) quando il messaggio viene inviato, insieme a timestamp precedentemente ricevuti e altre informazioni necessarie per determinare la gerarchia e gestire l'associazione. Il tasso di trasmissione dei messaggi è determinato dall'accuratezza richiesta dell'orologio locale, nonché dalle accuratezze dei suoi peer.

Il processo di ricezione (receive process) riceve messaggi NTP e forse messaggi in altri protocolli, nonché informazioni da orologi radio direttamente connessi. Quando viene ricevuto un messaggio NTP, l'offset tra l'orologio del peer e l'orologio locale viene calcolato e incorporato nel database insieme ad altre informazioni utili per la determinazione degli errori e la selezione dei peer. Un algoritmo di filtraggio descritto nella Sezione 4 migliora l'accuratezza scartando dati inferiori.

La procedura di aggiornamento (update procedure) viene avviata al ricevimento di un messaggio e in altri momenti. Elabora i dati di offset da ciascun peer e seleziona il migliore utilizzando gli algoritmi della Sezione 4. Ciò può comportare molte osservazioni di pochi peer o poche osservazioni di molti peer, a seconda delle accuratezze richieste.

Il processo dell'orologio locale (local-clock process) opera sui dati di offset prodotti dalla procedura di aggiornamento e regola la fase e la frequenza dell'orologio locale utilizzando i meccanismi descritti nella Sezione 5. Ciò può risultare in un cambiamento a passi o in un aggiustamento di fase graduale dell'orologio locale per ridurre l'offset a zero. L'orologio locale fornisce una fonte stabile di informazioni sul tempo ad altri utenti del sistema e per riferimento successivo da parte di NTP stesso.

2.2. Configurazioni di Rete

La sottorete di sincronizzazione è una rete connessa di server di tempo primari e secondari, client e percorsi di trasmissione di interconnessione. Un server di tempo primario è direttamente sincronizzato con una fonte di riferimento primaria, solitamente un orologio radio. Un server di tempo secondario deriva la sincronizzazione, possibilmente tramite altri server secondari, da un server primario su percorsi di rete possibilmente condivisi con altri servizi. In circostanze normali, è previsto che la sottorete di sincronizzazione di server primari e secondari assuma una configurazione gerarchica master-slave con i server primari alla radice e server secondari di accuratezza decrescente a livelli successivi verso le foglie.

Seguendo le convenzioni stabilite dall'industria telefonica [BEL86], l'accuratezza di ciascun server è definita da un numero chiamato strato (stratum), con il livello più alto (server primari) assegnato come uno e ciascun livello verso il basso (server secondari) nella gerarchia assegnato come uno in più rispetto al livello precedente. Con la tecnologia attuale e gli orologi radio disponibili, accuratezze di campione singolo dell'ordine di un millisecondo possono essere raggiunte all'interfaccia di rete di un server primario. Accuratezze di questo ordine richiedono cura speciale nella progettazione e implementazione del sistema operativo e del meccanismo dell'orologio locale, come descritto nella Sezione 5.

Man mano che lo strato aumenta da uno, le accuratezze di campione singolo realizzabili si degraderanno a seconda dei percorsi di rete e delle stabilità dell'orologio locale. Al fine di evitare i calcoli tediosi [BRA80] necessari per stimare gli errori in ogni configurazione specifica, è utile assumere che gli errori di misurazione medi si accumulino approssimativamente in proporzione al ritardo misurato e alla dispersione rispetto alla radice della sottorete di sincronizzazione. L'Appendice H contiene un'analisi degli errori, inclusa una derivazione dell'errore massimo come funzione del ritardo e della dispersione, dove quest'ultima quantità dipende dalla precisione del sistema di cronometraggio, dalla tolleranza di frequenza dell'orologio locale e vari residui. Supponendo che i server primari siano sincronizzati al tempo standard entro accuratezze note, questo fornisce una specifica affidabile e deterministica sulle accuratezze di cronometraggio in tutta la sottorete di sincronizzazione.

Ancora una volta attingendo dall'esperienza dell'industria telefonica, che ha imparato tali lezioni a costi considerevoli [ABA89], la topologia della sottorete di sincronizzazione dovrebbe essere organizzata per produrre la massima accuratezza, ma non deve mai essere consentito di formare un loop. Un fattore aggiuntivo è che ogni incremento dello strato coinvolge un server di tempo potenzialmente inaffidabile che introduce errori di misurazione aggiuntivi. L'algoritmo di selezione utilizzato in NTP utilizza una variante dell'algoritmo di routing distribuito di Bellman-Ford per calcolare gli alberi di copertura a peso minimo radicati sui server primari. La metrica di distanza utilizzata dall'algoritmo consiste nello strato (scalato) più la distanza di sincronizzazione, che a sua volta consiste nella dispersione più metà del ritardo assoluto. Pertanto, il percorso di sincronizzazione prenderà sempre il numero minimo di server alla radice, con i pareggi risolti sulla base dell'errore massimo.

Come risultato di questo design, la sottorete si riconfigura automaticamente in una configurazione gerarchica master-slave per produrre il tempo più accurato e affidabile, anche quando uno o più server primari o secondari o i percorsi di rete tra di essi falliscono. Questo include il caso in cui tutti i server primari normali (ad es., orologio radio WWVB altamente accurato che opera alle distanze di sincronizzazione più basse) su una sottorete possibilmente partizionata falliscono, ma uno o più server primari di backup (ad es., orologio radio WWV meno accurato che opera a distanze di sincronizzazione più elevate) continuano a funzionare. Tuttavia, se tutti i server primari in tutta la sottorete falliscono, i server secondari rimanenti si sincronizzeranno tra loro mentre le distanze aumentano a scatti verso un massimo preselezionato "infinito" a causa delle proprietà ben note dell'algoritmo di Bellman-Ford. Al raggiungimento del massimo su tutti i percorsi, un server si staccherà dalla sottorete e funzionerà liberamente utilizzando il suo ultimo tempo e frequenza determinati. Poiché questi calcoli sono previsti essere molto precisi, specialmente in frequenza, anche periodi di interruzione prolungati possono risultare in errori di cronometraggio non superiori a pochi millisecondi al giorno con oscillatori adeguatamente stabilizzati (vedere Sezione 5).

Nel caso di più server primari, il calcolo dell'albero di copertura selezionerà generalmente il server alla distanza di sincronizzazione minima. Tuttavia, quando questi server sono a circa la stessa distanza, il calcolo può risultare in selezioni casuali tra di essi come risultato di ritardi dispersivi normali. Ordinariamente, questo non degrada l'accuratezza finché qualsiasi discrepanza tra i server primari è piccola rispetto alla distanza di sincronizzazione. In caso contrario, gli algoritmi di filtro e selezione selezioneranno il migliore dei server disponibili e elimineranno i valori anomali come previsto.