1. Introduction (Einführung)
Dieses Dokument definiert das Network Time Protocol Version 4 (NTPv4), das weit verbreitet verwendet wird, um Systemuhren zwischen einer Gruppe verteilter Zeitserver und Clients zu synchronisieren. Es beschreibt die Kernarchitektur (architecture), das Protokoll (protocol), die Zustandsautomaten (state machines), die Datenstrukturen (data structures) und die Algorithmen (algorithms). NTPv4 führt neue Funktionalität in NTPv3 ein, wie in [RFC1305] beschrieben, und erweiterte Funktionalität aus Simple NTP Version 4 (SNTPv4), wie in [RFC4330] beschrieben (SNTPv4 ist eine Teilmenge von NTPv4). Dieses Dokument macht [RFC1305] und [RFC4330] obsolet. Obwohl bestimmte kleinere Änderungen in einigen Protokoll-Header-Feldern vorgenommen wurden, beeinflussen diese nicht die Interoperabilität zwischen NTPv4 und früheren Versionen von NTP und SNTP.
Das NTP-Subnetzmodell (subnet model) umfasst eine Reihe weit zugänglicher primärer Zeitserver (primary time servers), die über Draht oder Funk mit nationalen Standards synchronisiert sind. Der Zweck des NTP-Protokolls besteht darin, Zeitmessungsinformationen von diesen primären Servern an sekundäre Zeitserver (secondary time servers) und Clients über private Netzwerke und das öffentliche Internet zu übertragen. Präzise abgestimmte Algorithmen mildern Fehler, die aus Netzwerkunterbrechungen, Serverausfällen und möglichen feindlichen Aktionen resultieren können. Server und Clients sind so konfiguriert, dass Werte von den primären Servern an der Wurzel über verzweigte sekundäre Server zu den Clients fließen.
Das NTPv4-Design überwindet erhebliche Mängel im NTPv3-Design, korrigiert bestimmte Fehler und integriert neue Funktionen. Insbesondere ermutigen erweiterte NTP-Zeitstempel-Definitionen (timestamp) zur Verwendung des Gleitkomma-Double-Datentyps (floating double) in der gesamten Implementierung. Infolgedessen ist die Zeitauflösung (time resolution) besser als eine Nanosekunde, und die Frequenzauflösung (frequency resolution) beträgt weniger als eine Nanosekunde pro Sekunde. Weitere Verbesserungen umfassen einen neuen Uhrenkontroll-Algorithmus (clock discipline algorithm), der empfindlicher auf Frequenzschwankungen der Systemuhr-Hardware reagiert. Typische primäre Server mit modernen Maschinen sind auf einige Dutzend Mikrosekunden genau. Typische sekundäre Server und Clients in schnellen LANs liegen innerhalb weniger hundert Mikrosekunden bei Abfrageintervallen (poll intervals) von bis zu 1024 Sekunden, was das Maximum bei NTPv3 war. Mit NTPv4 sind Server und Clients bei Abfrageintervallen von bis zu 36 Stunden auf einige Dutzend Millisekunden genau.
Der Hauptteil dieses Dokuments beschreibt das Kernprotokoll und die Datenstrukturen, die für die Interoperabilität zwischen konformen Implementierungen erforderlich sind. Anhang A enthält ein voll ausgestattetes Beispiel in Form eines Skelett-Programms (skeleton program), einschließlich Datenstrukturen und Codesegmenten für die Kern-Algorithmen sowie die Mitigations-Algorithmen (mitigation algorithms), die zur Verbesserung von Zuverlässigkeit und Genauigkeit verwendet werden. Während das Skelett-Programm und andere Beschreibungen in diesem Dokument auf eine bestimmte Implementierung zutreffen, sind sie nicht als einzige Möglichkeit gedacht, die erforderlichen Funktionen zu implementieren. Der Inhalt von Anhang A ist ein nicht-normatives Beispiel, das zur Veranschaulichung der Protokollabläufe entwickelt wurde und keine Anforderung für eine konforme Implementierung darstellt. Während das NTPv3-Schema zur Authentifizierung mit symmetrischen Schlüsseln (symmetric key authentication scheme), das in diesem Dokument beschrieben wird, von NTPv3 übernommen wurde, wird das für NTPv4 neue Autokey-Schema zur Authentifizierung mit öffentlichen Schlüsseln (public key authentication scheme) in [RFC5906] beschrieben.
Das NTP-Protokoll umfasst Betriebsmodi (modes of operation), die in Abschnitt 2 beschrieben werden, unter Verwendung von Datentypen (data types), die in Abschnitt 6 beschrieben werden, und Datenstrukturen (data structures), die in Abschnitt 7 beschrieben werden. Das in Abschnitt 5 beschriebene Implementierungsmodell (implementation model) basiert auf einer Thread-basierten Multiprozess-Architektur (threaded, multi-process architecture), obwohl auch andere Architekturen verwendet werden könnten. Das in Abschnitt 8 beschriebene On-Wire-Protokoll (on-wire protocol) basiert auf einem rückgabefähigen Zeitdesign (returnable-time), das nur von gemessenen Uhrenversätzen (clock offsets) abhängt, aber keine zuverlässige Nachrichtenübermittlung erfordert. Zuverlässige Nachrichtenübermittlung wie TCP [RFC0793] kann tatsächlich das übermittelte NTP-Paket weniger zuverlässig machen, da Wiederholungsversuche den Verzögerungswert und andere Fehler erhöhen würden. Das Synchronisationssubnetz (synchronization subnet) ist ein selbstorganisierendes, hierarchisches Master-Slave-Netzwerk (hierarchical, master-slave network) mit Synchronisationspfaden, die durch einen kürzesten-Pfad-Spannbaum (shortest-path spanning tree) und eine definierte Metrik (metric) bestimmt werden. Obwohl mehrere Master (primäre Server) existieren können, besteht keine Anforderung für ein Wahlprotokoll (election protocol).
Dieses Dokument enthält Material aus [ref9], das Flussdiagramme und Gleichungen enthält, die für das RFC-Format ungeeignet sind. Es gibt viele zusätzliche Informationen in [ref7], einschließlich einer umfassenden technischen Analyse und Leistungsbewertung des Protokolls und der Algorithmen in diesem Dokument. Die Referenzimplementierung ist unter www.ntp.org verfügbar.
Der Rest dieses Dokuments enthält zahlreiche Variablen und mathematische Ausdrücke. Einige Variablen haben die Form griechischer Zeichen, die durch ihren vollständigen groß- und kleinschreibungsempfindlichen Namen ausgeschrieben werden. Zum Beispiel bezieht sich DELTA auf das griechische Großbuchstaben-Zeichen, während delta sich auf das Kleinbuchstaben-Zeichen bezieht. Darüber hinaus werden Indizes mit '_' gekennzeichnet; zum Beispiel bezieht sich theta_i auf das griechische Kleinbuchstaben-Zeichen Theta mit Index i, oder phonetisch Theta sub i. In diesem Dokument sind alle Zeitwerte in Sekunden (s), und alle Frequenzen werden als fraktionale Frequenzversätze (Fractional Frequency Offsets, FFOs) (reine Zahl) angegeben. Es ist oft zweckmäßig, diese FFOs in Teilen pro Million (parts per million, ppm) auszudrücken.
1.1. Requirements Notation (Anforderungsnotation)
Die Schlüsselwörter "MUST" (muss), "MUST NOT" (darf nicht), "REQUIRED" (erforderlich), "SHALL" (muss), "SHALL NOT" (darf nicht), "SHOULD" (sollte), "SHOULD NOT" (sollte nicht), "RECOMMENDED" (empfohlen), "MAY" (kann), und "OPTIONAL" (optional) in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.