8. On-Wire Protocol (Protocole sur le fil)
Le cœur du protocole NTP sur le fil est le mécanisme central (core mechanism) qui échange des valeurs temporelles entre serveurs, pairs et clients. Il est intrinsèquement résistant aux paquets perdus ou dupliqués. L'intégrité des données est fournie par les sommes de contrôle IP et UDP. Aucune installation de contrôle de flux ou de retransmission n'est fournie ou nécessaire. Le protocole utilise des horodatages (timestamps), qui sont soit extraits des en-têtes de paquets, soit obtenus de l'horloge système à l'arrivée ou au départ d'un paquet. Les horodatages sont des données de précision et doivent être réacquis en cas de retransmission au niveau liaison et corrigés pour le temps de calcul d'un MAC lors de la transmission.
Les messages NTP utilisent deux modes de communication différents, un-à-un et un-à-plusieurs (one-to-one and one-to-many), communément appelés unicast et diffusion (broadcast). Pour les besoins de ce document, le terme diffusion est interprété comme tout mécanisme un-à-plusieurs disponible. Pour IPv4, cela équivaut soit à la diffusion IPv4 soit au multicast IPv4. Pour IPv6, cela équivaut au multicast IPv6. À cette fin, l'IANA a alloué l'adresse multicast IPv4 224.0.1.1 et l'adresse multicast IPv6 se terminant par :101, avec le préfixe déterminé par les règles de portée. Toute autre adresse multicast non allouée peut également être utilisée en plus de ces adresses multicast allouées.
Le protocole sur le fil utilise quatre horodatages numérotés de t1 à t4 et trois variables d'état org, rec et xmt, comme le montre la Figure 15. Cette figure montre le cas le plus général où chacun des deux pairs, A et B, mesure indépendamment le décalage et le délai par rapport à l'autre. À des fins d'illustration, les horodatages de paquets sont affichés en minuscules, tandis que les variables d'état sont affichées en majuscules. Les variables d'état sont copiées à partir des horodatages de paquets à l'arrivée ou au départ d'un paquet.
t2 t3 t6 t7
+---------+ +---------+ +---------+ +---------+
| 0 | | t1 | | t3 | | t5 |
+---------+ +---------+ +---------+ +---------+
| 0 | | t2 | | t4 | | t6 | Packet
+---------+ +---------+ +---------+ +---------+ Timestamps
| t1 | |t3=clock | | t5 | |t7=clock |
+---------+ +---------+ +---------+ +---------+
|t2=clock | |t6=clock |
+---------+ +---------+
Pair B
+---------+ +---------+ +---------+ +---------+
org | T1 | | T1 | | t5<>T1? | | T5 |
+---------+ +---------+ +---------+ +---------+ State
rec | T2 | | T2 | | T6 | | T6 | Variables
+---------+ +---------+ +---------+ +---------+
xmt | 0 | | T3 | | t3=T3? | | T7 |
+---------+ +---------+ +---------+ +---------+
t2 t3 t6 t7
---------------------------------------------------------
/\ \ /\ \
/ \ / \
/ \ / \
/ \/ / \/
---------------------------------------------------------
t1 t4 t5 t8
t1 t4 t5 t8
+---------+ +---------+ +---------+ +---------+
| 0 | | t1 | | t3 | | t5 |
+---------+ +---------+ +---------+ +---------+
| 0 | | t2 | | t4 | | t6 | Packet
+---------+ +---------+ +---------+ +---------+ Timestamps
|t1=clock | | t3 | |t5=clock | | t7 |
+---------+ +---------+ +---------+ +---------+
|t4=clock | |t8=clock |
+---------+ +---------+
Pair A
+---------+ +---------+ +---------+ +---------+
org | 0 | | t3<>0? | | T3 | | t7<>T3? |
+---------+ +---------+ +---------+ +---------+ State
rec | 0 | | T4 | | T4 | | T8 | Variables
+---------+ +---------+ +---------+ +---------+
xmt | T1 | | t1=T1? | | T5 | | t5=T5? |
+---------+ +---------+ +---------+ +---------+
Figure 15 : Protocole sur le fil
Dans la figure, le premier paquet transmis par A contient uniquement l'horodatage d'origine (origin timestamp) t1, qui est ensuite copié dans T1. B reçoit le paquet à t2 et copie t1 dans T1 et l'horodatage de réception t2 dans T2. À ce moment ou ultérieurement à t3, B envoie un paquet à A contenant t1 et t2 et l'horodatage de transmission t3. Les trois horodatages sont copiés dans les variables d'état correspondantes. A reçoit le paquet à t4 contenant les trois horodatages t1, t2 et t3 et l'horodatage de destination t4. Ces quatre horodatages sont utilisés pour calculer le décalage et le délai de B par rapport à A, comme décrit ci-dessous.
Avant que les variables d'état xmt et org ne soient mises à jour, deux contrôles de cohérence (sanity checks) sont effectués afin de protéger contre les paquets dupliqués, falsifiés ou rejoués. Dans l'échange ci-dessus, un paquet est dupliqué ou rejoué si l'horodatage de transmission t3 dans le paquet correspond à la variable d'état org T3. Un paquet est falsifié si l'horodatage d'origine t1 dans le paquet ne correspond pas à la variable d'état xmt T1. Dans l'un ou l'autre de ces cas, les variables d'état sont mises à jour, puis le paquet est éliminé. Pour protéger contre la relecture du dernier paquet transmis, la variable d'état xmt est définie sur zéro immédiatement après un contrôle de falsification réussi.
Les quatre horodatages les plus récents, T1 à T4, sont utilisés pour calculer le décalage (offset) de B par rapport à A
theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]
et le délai aller-retour (round-trip delay)
delta = T(ABA) = (T4-T1) - (T3-T2).
Notez que les quantités entre parenthèses sont calculées à partir d'horodatages non signés de 64 bits et aboutissent à des valeurs signées avec 63 bits significatifs plus le signe. Ces valeurs peuvent représenter des dates de 68 ans dans le passé à 68 ans dans le futur. Cependant, le décalage et le délai sont calculés comme des sommes et des différences de ces valeurs, qui contiennent 62 bits significatifs et deux bits de signe, de sorte qu'ils peuvent représenter des valeurs non ambiguës de 34 ans dans le passé à 34 ans dans le futur. En d'autres termes, l'heure du client doit être définie dans les 34 ans du serveur avant le démarrage du service. Il s'agit d'une limitation fondamentale de l'arithmétique entière 64 bits.
Dans les implémentations où l'arithmétique en double flottant (floating double arithmetic) est disponible, les différences de premier ordre peuvent être converties en double flottant et les sommes et différences de second ordre calculées dans cette arithmétique. Étant donné que les termes de second ordre sont généralement très petits par rapport aux magnitudes des horodatages, il n'y a pas de perte de signification, mais la plage non ambiguë est restaurée de 34 ans à 68 ans.
Dans certains scénarios où le décalage de fréquence initial du client est relativement important et le temps de propagation réel petit, il est possible que le calcul du délai devienne négatif. Par exemple, si la différence de fréquence est de 100 ppm et que l'intervalle T4-T1 est de 64 s, le délai apparent est de -6,4 ms. Étant donné que les valeurs négatives sont trompeuses dans les calculs ultérieurs, la valeur de delta doit être limitée à au moins s.rho, où s.rho est la précision du système décrite dans la Section 11.1, exprimée en secondes.
La discussion ci-dessus suppose le cas le plus général où deux pairs symétriques mesurent indépendamment les décalages et les délais entre eux. Dans le cas d'un serveur sans état (stateless server), le protocole peut être simplifié. Un serveur sans état copie T3 et T4 du paquet client vers T1 et T2 du paquet serveur et ajoute l'horodatage de transmission T3 avant de l'envoyer au client. Des détails supplémentaires pour remplir les champs de protocole restants sont donnés dans la Section 9 et les sections suivantes ainsi que dans l'annexe.
Notez que le protocole sur le fil tel que décrit résiste à la relecture d'un paquet de réponse du serveur. Cependant, il ne résiste pas à la relecture du paquet de demande du client, ce qui entraînerait un paquet de réponse du serveur avec de nouvelles valeurs de T2 et T3 et entraînerait un décalage et un délai incorrects. Cette vulnérabilité peut être évitée en définissant la variable d'état xmt sur zéro après avoir calculé le décalage et le délai.