1. Introduction
Ce document définit le protocole de temps réseau version 4 (Network Time Protocol version 4, NTPv4), qui est largement utilisé pour synchroniser les horloges système parmi un ensemble de serveurs de temps et de clients distribués. Il décrit l'architecture de base (architecture), le protocole (protocol), les machines à états (state machines), les structures de données (data structures) et les algorithmes (algorithms). NTPv4 introduit de nouvelles fonctionnalités dans NTPv3, comme décrit dans [RFC1305], et des fonctionnalités étendues à partir du protocole NTP simple version 4 (Simple NTP version 4, SNTPv4) comme décrit dans [RFC4330] (SNTPv4 est un sous-ensemble de NTPv4). Ce document rend obsolètes [RFC1305] et [RFC4330]. Bien que certaines modifications mineures aient été apportées à certains champs d'en-tête de protocole, celles-ci n'affectent pas l'interopérabilité entre NTPv4 et les versions précédentes de NTP et SNTP.
Le modèle de sous-réseau NTP (subnet model) comprend un certain nombre de serveurs de temps primaires (primary time servers) largement accessibles, synchronisés par fil ou radio aux normes nationales. L'objectif du protocole NTP est de transmettre les informations de chronométrage de ces serveurs primaires aux serveurs de temps secondaires (secondary time servers) et aux clients via des réseaux privés et l'Internet public. Des algorithmes précisément ajustés atténuent les erreurs qui peuvent résulter d'interruptions réseau, de pannes de serveurs et d'actions hostiles possibles. Les serveurs et les clients sont configurés de telle sorte que les valeurs circulent vers les clients à partir des serveurs primaires à la racine via des serveurs secondaires en branches.
La conception NTPv4 surmonte d'importantes lacunes dans la conception NTPv3, corrige certains bogues et intègre de nouvelles fonctionnalités. En particulier, les définitions d'horodatage NTP (timestamp) étendues encouragent l'utilisation du type de données double flottant (floating double) dans toute l'implémentation. En conséquence, la résolution temporelle (time resolution) est meilleure qu'une nanoseconde, et la résolution en fréquence (frequency resolution) est inférieure à une nanoseconde par seconde. Les améliorations supplémentaires incluent un nouvel algorithme de discipline d'horloge (clock discipline algorithm) qui répond mieux aux fluctuations de fréquence du matériel d'horloge système. Les serveurs primaires typiques utilisant des machines modernes sont précis à quelques dizaines de microsecondes. Les serveurs secondaires et les clients typiques sur des réseaux locaux rapides se situent à quelques centaines de microsecondes avec des intervalles de sondage (poll intervals) allant jusqu'à 1024 secondes, ce qui était le maximum avec NTPv3. Avec NTPv4, les serveurs et les clients sont précis à quelques dizaines de millisecondes avec des intervalles de sondage allant jusqu'à 36 heures.
Le corps principal de ce document décrit le protocole de base et les structures de données nécessaires pour interopérer entre des implémentations conformes. L'annexe A contient un exemple complet sous la forme d'un programme squelette (skeleton program), comprenant des structures de données et des segments de code pour les algorithmes de base ainsi que les algorithmes d'atténuation (mitigation algorithms) utilisés pour améliorer la fiabilité et la précision. Bien que le programme squelette et d'autres descriptions de ce document s'appliquent à une implémentation particulière, ils ne sont pas destinés à être la seule façon d'implémenter les fonctions requises. Le contenu de l'annexe A est un exemple non normatif conçu pour illustrer le fonctionnement du protocole et n'est pas une exigence pour une implémentation conforme. Bien que le schéma d'authentification par clé symétrique (symmetric key authentication scheme) NTPv3 décrit dans ce document ait été repris de NTPv3, le schéma d'authentification par clé publique (public key authentication scheme) Autokey nouveau dans NTPv4 est décrit dans [RFC5906].
Le protocole NTP inclut les modes d'opération (modes of operation) décrits dans la section 2 en utilisant les types de données (data types) décrits dans la section 6 et les structures de données (data structures) décrites dans la section 7. Le modèle d'implémentation (implementation model) décrit dans la section 5 est basé sur une architecture multithread et multiprocessus (threaded, multi-process architecture), bien que d'autres architectures puissent également être utilisées. Le protocole sur le fil (on-wire protocol) décrit dans la section 8 est basé sur une conception de temps retournable (returnable-time) qui dépend uniquement des décalages d'horloge (clock offsets) mesurés, mais ne nécessite pas de livraison de messages fiable. La livraison de messages fiable telle que TCP [RFC0793] peut en fait rendre le paquet NTP livré moins fiable car les nouvelles tentatives augmenteraient la valeur du délai et d'autres erreurs. Le sous-réseau de synchronisation (synchronization subnet) est un réseau hiérarchique maître-esclave auto-organisé (hierarchical, master-slave network) avec des chemins de synchronisation déterminés par un arbre couvrant de chemin le plus court (shortest-path spanning tree) et une métrique définie. Bien que plusieurs maîtres (serveurs primaires) puissent exister, il n'y a pas d'exigence pour un protocole d'élection (election protocol).
Ce document comprend du matériel de [ref9], qui contient des organigrammes et des équations inadaptés au format RFC. Il y a beaucoup d'informations supplémentaires dans [ref7], y compris une analyse technique approfondie et une évaluation des performances du protocole et des algorithmes de ce document. L'implémentation de référence est disponible sur www.ntp.org.
Le reste de ce document contient de nombreuses variables et expressions mathématiques. Certaines variables prennent la forme de caractères grecs, qui sont épelés par leur nom complet sensible à la casse. Par exemple, DELTA fait référence au caractère grec majuscule, tandis que delta fait référence au caractère minuscule. De plus, les indices sont notés avec '_' ; par exemple, theta_i fait référence au caractère grec minuscule thêta avec l'indice i, ou phonétiquement thêta sub i. Dans ce document, toutes les valeurs de temps sont en secondes (s), et toutes les fréquences seront spécifiées comme des décalages de fréquence fractionnaires (Fractional Frequency Offsets, FFO) (nombre pur). Il est souvent pratique d'exprimer ces FFO en parties par million (parts per million, ppm).
1.1. Requirements Notation (Notation des exigences)
Les mots-clés "MUST" (doit), "MUST NOT" (ne doit pas), "REQUIRED" (requis), "SHALL" (doit), "SHALL NOT" (ne doit pas), "SHOULD" (devrait), "SHOULD NOT" (ne devrait pas), "RECOMMENDED" (recommandé), "MAY" (peut), et "OPTIONAL" (optionnel) dans ce document doivent être interprétés comme décrit dans [RFC2119].