| orm@doc-tcpip.org | Erstellt: Juni 2001 - Letzte Modifikation: November 2002 |
RFC1305 Network Time Protocol (Version 3) Specification, Implementation
RFC1129 Internet Time Synchronization: The Network Time Protocol
RFC2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC1589 A Kernel Model for Precision Timekeeping
Alle RFC bekommt man vom
RFC-Editor (www.rfc-editor.org)
oder vom RFC Netserver (rfc.net).
Die Seiten von David Mills von der University of Delaware (www.eecis.udel.edu/~ntp), der NTP entwickelt. Hier finden sich auch die Implemetationen (ntpd, xntpd) sowie viele, interessante Information zum Thema. Die NTP-Homepage (www.ntp.org) ist übrigens ein Link auf die erste Seite.
DCF77 Funkuhren gibt es von Meinberg (www.meinberg.de) oder von Hopf (www.hopf-time.com).
Man sollte sich einmal das Prinzip klargemacht haben - dann fällt der Umgang mit dem Protokoll bzw. seinen Implementationen deutlich leichter. Neben NTP gibt es noch den time-Deamon. In diesem Ansatz synchronisieren Maschinen tatsächlich gegeneinander, und aus der Zeit aller wird "demokratisch" eine gemeinsame, gemittelte Zeit berechnet, die dann von allen angestrebt wird.
Das ist beim NTP fundamental anders, und es ist wichtig, das zu begreifen: Das NTP synchronisiert ein System gegen eine externe, exakte Zeitquelle (UTC). Es erfolgt primär kein Abgleich gegen andere Systeme. Das sich Rechner in einem Netz so synchronisieren ist eigentlich ein Nebeneffekt der Bestrebung des einzelnen Rechners, sich UTC möglichst gut anzunähern. Daher ist NTP auch hierarchisch organisiert und völlig auf eine Zeitquelle ausgerichtet. Selbst bei der Angabe von mehreren "Peers" werden diese nur als mehr oder minder zuverlässige Quelle von UTC angesehen und es wird immer nur gegen einen bestimmten abgeglichen - der allerdings wechseln kann.
Das Protokoll sieht keinerlei Möglichkeiten vor, verschiedene Ansichten über die momentante Zeit partnerschaftlich zu klären (wie der Time-Deamon) - es kann nur eine richtige und wahre Zeit geben. Und von der anerkannten Quelle dieser Standard-Zeit sind die Clienten hierarchisch absteigend in Ebenen eingeteilt, das Stratum. Das Stratum ist nichts anders als die Anzahl der Hops zwischen der Quelle und dem Client. Man geht von der Annahme aus, das die Zeitinformation präziser ist, wenn man näher an der Quelle sitzt. Das Stratum 1 hat direkten Zugang zur Quelle, während ein Stratum 2 Client die Information über einen Stratum 1 Server bekommt (gegen den er sich nicht synchronisiert - er bekommt nur die Zeitinformation über ihn). Der Stratum 2 Client kann nun wieder Server für Stratum 3 Clients sein - und so weiter.
Die Synchronisation mit UTC erfolgt über die Mitteilung von aktuellen Zeitmarken (Timestamps). Da der Unterschied (Offset) zwischen Server und Client per se unbekannt ist, muß die Laufzeit der Information bekannt sein. Das geht auf dem Internet nur in einer Näherung. Man nimmt die Rundlaufzeit der Anfrage und hofft, das Hin- und Rücklaufzeit im Mittel gleich sind. Der Client ist bestrebt, einen Server mit möglichst niedrigem Stratum zu wählen und versucht, sich an diese Zeitinformation anzugleichen. Allerdings führt er eine eigene Statistik und vergleicht die empfangene Information mit seiner Statistik über die letzten 8 Pakete - so ist der Client in der Lage, einen "kranken" (insane) Server auszumachen. Schließlich will der Client gegen UTC synchronisieren, und das ist eindeutig. Er wird versuchen, die Zeitinformation eines anderen Servers zu benutzen. Bei dieser Entscheidung hilft der Server mit, da er einmal sein Stratum mitteilt, angibt, für wie präzise er seine Zeitinformation hält und die Rundlaufzeiten meßbar sind.
Diese Verhalten hängt auch vom Typ (Mode) der Verbindung ab. Das NTP erlaubt eine Client/Server Beziehung sowie Broadcast und Multicast Beziehungen. Die beteiligten Maschinen werden als Peers bezeichnet. Die Client/Server Beziehung kann symmetrisch sein, in diesem Fall geben sich die Peers gegeseitig Zeitinformation. Die Broadcast und Clientbeziehungen sind asymmetrisch.
Symmetric Active Mode (1) Heißt, daß der Host seine Zeitinformation weitergibt und auch die Zeitinformation anderer Server empfangen möchte. Das wird bei der Konfiguration mit dem "peer" Statement ausgedrückt.
Symmetric Passive Mode (2) Ist ähnlich, nur das hierbei der Host nicht selbst aktiv einen Server anspricht.
Client Mode (3) Hier fragt der Host einen definierten Server nach der Zeitinformation. Den Rhythmus dieser Anfragen bestimmt der Client nach seinen Bedürfnissen - man spricht vom pollen. (Das gilt auch für die beiden symmetrischen Modi).
Server Mode (4) Entsteht dann, wenn ein Host gewillt ist, eine gezielte Client-Anfrage zu bedienen.
Broadcast Mode (5) Hierbei schickt eine Server-Maschine regelmäßig Pakete mit der Zeitinformation aufs Netz, unabhängig vom Zustand der Clients.
Das ist stark Hardwareabhängig. Mit einer RISC Architektur wird die Präzision von der benutzten Funk-Uhr und dem Interface bestimmt, sollte aber bei einigen Millisekunden liegen. Mit spezieller Hardware kommt man wohl in die Größenordnung von einigen hundert Mikrosekunden - wers so genau braucht.
Die Implementation des NTP ist der nächste Faktor, der die Genauigkeit beeinflußt. Der xntpd z.B. benutzt einen 64-Bittigen Zeitstempel, 32 Bit für die Sekunden und 32 Bit für die Fraktionen. Weiterhin sind die zugrundeliegende Arithmetik wichtig. So rechnen Computer bei Fließkomma Rechungen technisch bedingt falsch.
In einem sicheren Netz ist eine exakte Zeit sehr wichtig, da alle Authentifizierungs-Services mit Zeitfenstern arbeiten. Ein Verbiegen der Zeit ist somit eine Möglichkeit des Angriffes. Die aktuellen Implementationen des NTP erlauben Keywörter, sodaß man unerlauben Zugriff bzw. unerlaubten Service unterbinden kann. Allerdings ist es nicht möglich, den Inhalt zu verschlüßeln. Das ist aber in der neuen NTP Version 4 berücksichtigt. Der wichtigste Punkt ist, daß all diese Algorithmen Zeit kosten, also per se die Genauigkeit der Synchronisation verschlechtern.
Ein ganz anderer Punkt sind Zählerüberläufe. Die Zeitskala des NTP beginnt am 1. Januar 1900 (Null Uhr). Es steht ein 32 Bit-Zähler für Sekunden zur Verfügung, also schlägt der Zähler alle 136 Jahre um. Diese Zeitspanne wird als Era bezeichnet. In diesem Fall ist das Ganze unkritisch, da es Aufgabe des Betriebssystemes ist, aus dem Sekundezähler die Zeit zu ermitteln. Das NTP hat keinerlei Kenntnis von Tagen, Jahren oder Jahrhunderten.
Die weitverbreiteste Implementation des NTP ist xntpd von David Mills (University of Delaware). Sie kommt mit einer Reihe Utilities. Sehr nützlich ist das Kommando xntpdc, da man damit viele Informationen zum Troubleshooten bekommt. Das Kommando ntptrace ist dem traceroute-Kommando ähnlich. Es erlaubt, eine Kette von NTP-Servern bis ins Stratum 1 zurückzuverfolgen. Mit ntpdate kann man Zeit und Datum setzen, ohne xntpd laufen zu lassen. Als letztes Werkzeug wird meist noch ntpq mitinstalliert. Mit diesem Kommando kann man den xntpd unter Benutzung von Mode 6 Control Messages abfragen.
Die NTP Messages werden mit UDP als Transportprotokoll übertragen.
Hier das Format eines NTP-Paketes:
. 0 1 2 3 . 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . |LV |VN |Mode | Stratum | Poll | Precision | . +---------------+---------------+---------------+---------------+ . | Root Dispersion | . +-------------------------------+-------------------------------+ . | Reference Clock Identifier | . +-------------------------------+-------------------------------+ . | Reference Timestamp | . +-------------------------------+-------------------------------+ . | Originate Timestamp | . +-------------------------------+-------------------------------+ . | Receive Timestamp | . +-------------------------------+-------------------------------+ . | Transmit Timestamp | . +-------------------------------+-------------------------------+ . | Authenticator (optional) | . +-------------------------------+-------------------------------+ . | ......... | . +-------------------------------+-------------------------------+ .
LV (Leap Indicator):
Warnt vor einer zu erwartenden Sprung-Sekunde, die am Ende des Tages entweder
eingefügt oder gelöscht werden muß. Das Feld hat 2 Bits ist wie folgt
gesetzt:
00 Es ist nichts gesetzt.
01 Die letzte Minute des Tages wird 61 Sekunden haben.
10 Die letzte Minute des Tages wird 59 Sekunden haben.
11 Alarm. Die Uhr ist nicht synchronisiert.
VN (Version Number: Die Versionsnummer des NTP-Protokolls (aktuell ist NTPv3). Ein 3 Bit Wert.
Stratum: Der Wert des Stratums der lokalen Uhr. Ein 8 Bit Feld mit
folgenden Werten:
0 Nicht spezifiziert
1 Primäre Referenz, also z.B. eine Funkuhr.
2-255 Sekundäre Referenz (via NTP)
Poll (Poll Interval): Gibt den maximalen Intervall zwischen zwei aufeinanderfolgenden Paketen an (immer zum nächsten Exponentialwert von 2). Ein 8 Bit Feld.
Reference Clock Identifier:
Zeigt die Art bzw. den Typ der benutzten Referenz. Ein 32 bit Feld, das
folgende Fälle kennt:
Stratum 0 oder 1:
Ein 4 Oktetts langer ASCII String. Diese Codes haben sich eingebürgert,
sind aber nicht spezifiziert im RFC:
Stratum Code Bedeutung 0 DCN DCN routing protocol 0 NIST NIST public modem 0 TSP TSP time protocol 1 ATOM Atomic clock (calibrated) 1 VLF VLF radio (OMEGA, etc.) 1 callsign Generic radio 1 LORC LORAN-C radio navigation 1 GOES GOES UHF environment satellite 1 GPS GPS UHF satellite positioning
Reference Timestamp: Die lokale Zeit, mit der der Client die lokale Uhr zuletzt nachgeführt hat. Im 64-Bit Timestamp Format.
Originate Timestamp: Die lokale Zeit, zu der das Paket vom Client zur Übertragung gegeben wurde. Im 64-Bit Timestamp Format.
Receive Timestamp: Die lokale Zeit des Servers, als dieser die Anfrage empfangen hat. Im 64-Bit Timestamp Format.
Transmit Timestamp: Die lokale Zeit des Servers, als dieser die Antwort gesendet hat. Im 64-Bit Timestamp Format.
Authenticator (optional): Für Keywörter etc.
Eine interessante Frage ist, wie man den 64-Bit NTP Zeitstempel zu
verstehen hat. Die 64 Bit zerfallen in zwei 32 Bit Werte, wobei die
ersten 32 Bit die Sekunden sind und die zweite Hälfte die
Sekunden-Fraktionen.
0 1 2 3 . 4 5 6 01234567890123456789012345678901.23456789012345678901234567890123 . 1/2 Sek . 1/4 Sek . 1/8 Sek . 1/2048 Sek
reference time: c16fcd61.c117c5ef Sun, Nov 3 2002 17:29:21.754
elbueno:~ # bc scale=64 obase=2 ibase=16 C16FCD61 11000001011011111100110101100001 C117C5EF 11000001000101111100010111101111
elbueno:~ # bc scale=64 ibase=16 C16FCD61 3245329761
elbueno:~ # bc scale=64 ibase=16 3245329761/31536000 102.9087316
elbueno:~ # bc scale=64 31536000*0.9087316 28657759.7376000 28657759/86400 331.68702546296296
Ein genaueres Verständnis des NTP-Algorithmus ist zum erfolgreichen Einsatz, besonders wenn Fehler auftreten, sehr wichtig. Es werden auf die Zeitinformation, die der Client vom Server erhält, eine Reihe aufwändige, statistische Methoden angewandt, um so eine gute Zeitquelle zu finden. Weiterhin wird die erfolgte Syncronisation dauernd überwacht und nachgeregelt. Dabei wird durch ein Auslese-Verfahren verhindert, das sich die Zeit von einem festen Zeitnormal entfernt. Diese Gefahr besteht beim time-Protokoll durchaus, da "demokratisch" über die gemeinsame Zeit entschieden wird.
Aus der Sicht des NTP-Client werden folgende Schritte nach Empfang eines Paketes durchlaufen. Dabei ist zu beachten, das NTP vorraussetzt, daß mehrere Server zur Zeitinformation beitragen. Die Schritte vereinfachen sich natürlich, wenn nur gegen eine Quelle syncronisiert wird - die Qualität der Zeit sinkt dann entsprechend.
Qualitätsprüfung (Sanity Check)
Ist das Paket schon einmal empfangen worden?
Verzögerte Pakete werden so eliminiert.
Hat das Paket den letzten gesendeten Zeitstempel?
Es werden nur Pakete akzeptiert, die eine direkte Reaktion auf eine
Anfrage sind.
Ist der Server erreichbar?
Liegt die Rundlaufzeit und die Dispersion zusammen für den
Server unter 16 Sekunden?
Ein grundsätzliches Kriterium, da mit solchen Werten eine weitere
Verwendung nicht sinnvoll ist.
Kann der Server authentifiziert werden?
Interessanterweise ist das nicht der erste Check. Es können also hier
Pakete eliminiert werden, die schon angefaßt wurden.
Hat sich der Server innerhalb des vergangenen Tages mit einem
Stratum 1 Server sycronisiert?
Ein Server oder konfigurierte Referenz (zumindest die Local Clock)
wird ignoriert.
Hat der Server ein kleines oder das gleich Stratum wie
das eigene?
Verhindert Loops.
Liegt die Gesamt-Rundlaufzeit und die Gesamt Dispersion
unter 16 Sekunden?
Die Werte werden einzeln statistisch aufgearbeitet. Die rohen Werte
sind immer höher als der letztendlich entscheidende Wert.
Filtern der Pakete (Filtering)
Das akzeptierte Paket gelangt nun auf eine für jeden Server/Uhr
eigerichtete Queue. Diese Queue umfaßt 8 Pakete, das jeweils älteste
wird von der Queue genommen.
Auf der Queue müßen sich mindestens 5 Pakete befinden, sonst wird der Server zur Zeitermittlung nicht herangezogen. Davon hängt unter anderem die Geschwindigkeit ab, mit der ein neuer Server von den Clients erkannt wird (mindestens 5 mal der Polling Intervall).
Für jedes der Pakete wird nun wie im Abschnitt Abschätzen der Abweichung (Offset) und des Fehlers (Error) beschrieben, die Abweichung (Offset), die Verzögerung (Delay) und der Fehler (Error) ermittelt. Die Ergebnisse aller Pakete werden zusammen betrachtet und durch den Filter-Algorithmus zusammengefaßt.
Das Ergebnis ist die beste Schätzung der Abweichung (Offset) zu dem betroffenen Server.
Vergleich der verschiedenen Server (Intersection)
In diesem Schritt werden offensichtlich falsch gehende Server
eliminiert. Die bereinigten Werte der einzelnen Server werden
vergliechen und es wird eine Schnittmenge aller Server ermittelt.
Dazu wird der im vorherigen Schritt ermittelte Offset pro Server und der maximal mögliche Fehler (die Dispersion) herangezogen. Nicht überlappende Server gelten als Falsch und werden nicht zur Schätzung des "wahren" Offsets benutzt.
. ** . #######|#|##**### (eliminierte Server) . | **#|### #######|####### . |#|** ####|#### . ##|##**#####|############# . ###||#**# . | ** ### = Disperion . | ** | = Offset der Server . | *** = Schnittmenge . Aktuelle Zeit des Client .Der später benutzte Offset zur aktuellen Zeit des Client wird sich im Bereich der Schnittmenge finden.
Zusammenfassen der verbleibenden Server
(Clustering)
Auch dieser Schritt dient unter anderem zur Elimination fehlerhaft
laufender Server. Alle Server, die zur Schnittmenge beigetragen haben,
werden in diesem Schritt nach verschiedenen Kriterien hierachisch
gegliedert. Die Kriterien sind:
Der Rang der Mitglieder der 10er Gruppe wird weiter verfeinert mit Hilfe einer Statistik über das zeitliche Verhalten von Dispersion und Error dieses Servers. Liegt der aktuell zur Syncronisation benutzte Server jetzt immer noch vorne, so wird der Offset dieser Maschine zugrunde gelegt. Ansonsten übernimmt diese Rolle der jetzt als beseter Server ermittelte.
Nach diesem Prozeß ist jedem Server ein Offset mit einer Abschätzung seiner Qualität zugeordnet.
Kombination des Offset und Fehlers aller Server
(Clustering)
Die Information aller Server in der 10er Gruppe fließt in den
letztendlich zur Syncronisation benutzten Offset ein.
Dazu wird der individuelle Offset jedes Servers gemäß der ermittelten Qualität mit einem Gewichtungsfaktor modifiziert. Der für die Syncronisation angewandte Offset ist das Mittel des Offsets des besten Servers und der gewichteten Offsets der anderen Mitglieder der 10er Gruppe.
Es werden maximal 64 Server in die Berechnung einbezogen, von denen maximal 10 in den Pool der potentiellen Syncronisations-Partner gelangen.
NTP ermöglicht die Syncronisation zu UTC und die Ermittlung eines geschätzten Fehlerbereiches. Dieser Wert ist die Dispersion, der geschätzte, maximale Fehler einer gegebenen Verschiebung (Offset) der Zeit zwischen Client und Server. In die Dispersion fließt die Verzögerung (Delay), die im Netzwerk auftritt, und der Fehler (Error) der Messung.
Der Offset ist die Hälfte der Differenz der Laufzeiten der Pakete Client-Server und Server-Client. Die Rechenzeit wird dabei abgezogen, nur die Netzwerk-Laufzeit zählt. Der Offset ist der Wert in Sekunden, um den sich die Client-Uhr von der Server-Uhr unterscheidet.
Der Delay ist die Rundlaufzeit des Paketes ohne die Rechenzeit, also reine Zeit, die dasPaket auf dem Netzwerk war.
Der Error ist ein Wert in Sekunden, der Frequenzungenauigkeiten und Messfehler berücksichtigt.
Die Dispersion ist die Hälfte des Delays plus dem Error, also die maximale Unsicherheit des Offsets eines Client.
Hier wird es vielleicht deutlicher:
. . (Dispersion) . [+++++++++++++++++] . | | . #####|#############|################## . # In diesem Breich muß die Anpassung # . # der Client-Uhr liegen # . #####|#############|################## . | | . | (Offset zur Serverzeit) . | . (Aktuelle Client Zeit) .
Ermittlung von Offset und Dispersion
Der Client sendet ein Paket an den Server, das er mit einem Zeitstempel
C1 versehen hat. Der Server empfängt dieses Paket und versieht es mit
seinem Eingangs-Zeitstempel S1. Danach bildet der Server das
Antwort-Paket mit der Dispersion seines Root-Servers und versieht es kurz
vor dem Senden mit seinem Ausgangs-Zeitstempel S2. Das eliminiert die
Rechenzeit des Servers. Der Client empfängt das Paket und schreibt
seinen Eingangs-Zeitstempel C2.
Die Berechung sieht daher folgendermaßen aus:
Der Offset ist: ((S1 - C1) - (C2 - S2)) / 2.
Der Delay ist: ((C2 - C1) - (S2 - S1)).
Die Dispersion ist (Delay / 2) + Error.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL