forked from OS2World/APP-INTERNET-DayTime
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathrfc1361
563 lines (382 loc) · 23.3 KB
/
rfc1361
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
Network Working Group D. Mills
Request for Comments: 1361 University of Delaware
August 1992
Simple Network Time Protocol (SNTP)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
Abstract
This memorandum describes the Simple Network Time Protocol (SNTP),
which is an adaptation of the Network Time Protocol (NTP) used to
synchronize computer clocks in the Internet. SNTP can be used when
the ultimate performance of the full NTP implementation described in
RFC-1305 is not needed or justified. It involves no change to the
current or previous NTP specification versions or known
implementations, but rather a clarification of certain design
features of NTP which allow operation in a simple, stateless RPC mode
with accuracy and reliability expectations similar to the UDP/TIME
protocol described in RFC-868.
This memorandum does not obsolete or update any RFC. A working
knowledge of RFC-1305 is not required for an implementation of SNTP.
1. Introduction
The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is used
to synchronize computer clocks in the global Internet. It provides
comprehensive mechanisms to access national time and frequency
dissemination services, organize the time-synchronization subnet and
adjust the local clock in each participating subnet peer. In most
places of the Internet of today, NTP provides accuracies of 1-50 ms,
depending on the jitter characteristics of the synchronization source
and network paths.
RFC-1305 specifies the NTP protocol machine in terms of events,
states, transition functions and actions and, in addition, optional
algorithms to improve the timekeeping quality and mitigate among
several, possibly faulty, synchronization sources. To achieve
accuracies in the low milliseconds over paths spanning major portions
of the Internet of today, these intricate algorithms, or their
functional equivalents, are necessary. However, in many cases
accuracies of this order are not required and something less, perhaps
Mills [Page 1]
RFC 1361 SNTP August 1992
in the order of one second, is sufficient. In such cases simpler
protocols such as the Time Protocol [POS83], have been used for this
purpose. These protocols usually involve a remote-procedure call
(RPC) exchange where the client requests the time of day and the
server returns it in seconds past some known reference epoch.
NTP is designed for use by clients and servers with a wide range of
capabilities and over a wide range of network delays and jitter
characteristics. Most members of the Internet NTP synchronization
subnet of today use software packages including the full suite of NTP
options and algorithms, which are relatively complex, real-time
applications. While the software has been ported to a wide variety of
hardware platforms ranging from supercomputers to personal computers,
its sheer size and complexity is not appropriate for many
applications. Accordingly, it is useful to explore alternative access
strategies using far simpler software appropriate for accuracy
expectations in the order of a second.
This memorandum describes the Simple Network Time Protocol (SNTP),
which is a simplified access strategy for servers and clients using
NTP as now specified and deployed in the Internet. There are no
changes to the protocol or implementations now running or likely to
be implemented in the near future. The access paradigm is identical
to the UDP/Time Protocol and, in fact, it should be easily possible
to adapt a UDP/Time client implementation, say for a personal
computer, to operate using SNTP. Moreover, SNTP is also designed to
operate in a dedicated server configuration including an integrated
radio clock. With careful design and control of the various latencies
in the system, which is practical in a dedicated design, it is
possible to deliver time accurate to the order of microseconds.
It is strongly recommended that SNTP be used only at the extremities
of the synchronization subnet. SNTP clients should operate only at
the leaves (highest stratum) of the subnet and in configurations
where no SNTP client is dependent on another SNTP client for
synchronization. SNTP servers should operate only at the root
(stratum 1) of the subnet and then only in configurations where no
other source of synchronization other than a reliable radio clock is
available. The full degree of reliability ordinarily expected of
primary servers is possible only using the redundant sources, diverse
subnet paths and crafted algorithms of a full NTP implementation.
This extends to the primary source of synchronization itself in the
form of multiple radio clocks and backup paths to other primary
servers should the radio clock fail or become faulty. Therefore, the
use of SNTP rather than NTP in primary servers should be carefully
considered.
Mills [Page 2]
RFC 1361 SNTP August 1992
2. NTP Timestamp Format
SNTP uses the standard NTP timestamp format described in RFC-1305 and
previous versions of that document. In conformance with standard
Internet practice, NTP data are specified as integer or fixed-point
quantities, with bits numbered in big-endian fashion from zero
starting at the left, or high-order, position. Unless specified
otherwise, all quantities are unsigned and may occupy the full field
width with an implied zero preceding bit zero.
Since NTP timestamps are cherished data and, in fact, represent the
main product of the protocol, a special timestamp format has been
established. NTP timestamps are represented as a 64-bit unsigned
fixed-point number, in seconds relative to 0h on 1 January 1900. The
integer part is in the first 32 bits and the fraction part in the
last 32 bits. This format allows convenient multiple-precision
arithmetic and conversion to Time Protocol representation (seconds),
but does complicate the conversion to ICMP Timestamp message
representation (milliseconds). The precision of this representation
is about 200 picoseconds, which should be adequate for even the most
exotic requirements.
Note that since some time in 1968 the most significant bit (bit 0 of
the integer part) has been set and that the 64-bit field will
overflow some time in 2036. Should NTP or SNTP be in use in 2036,
some external means will be necessary to qualify time relative to
1900 and time relative to 2036 (and other multiples of 136 years).
Timestamped data requiring such qualification will be so precious
that appropriate means should be readily available. There will exist
a 200-picosecond interval, henceforth ignored, every 136 years when
the 64-bit field will be zero, which by convention is interpreted as
an invalid timestamp.
3. NTP Message Format
Both NTP and SNTP are clients of the User Datagram Protocol (UDP)
[POS83], which itself is a client of the Internet Protocol (IP)
[DAR81]. The structure of the IP and UDP headers is described in the
relevant specification documents and will not be described further in
this memorandum. Following is a description of the SNTP message
format, which follows the IP and UDP headers. The SNTP message format
is identical to the NTP format described in RFC-1305, with the
exception that some of the data fields are "canned," that is,
initialized to prespecified values. The format of the NTP message
data area, which immediately follows the UDP header, is shown below.
Mills [Page 3]
RFC 1361 SNTP August 1992
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authenticator (optional) (96) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As described in the next section, in SNTP most of these fields are
initialized with prespecified data. For completeness, the function of
each field is briefly summarized below.
Leap Indicator (LI): This is a two-bit code warning of an impending
leap second to be inserted/deleted in the last minute of the current
day, with bit 0 and bit 1, respectively, coded as follows:
LI Value Meaning
-------------------------------------------------------
00 0 no warning
01 1 last minute has 61 seconds
10 2 last minute has 59 seconds)
11 3 alarm condition (clock not synchronized)
Mills [Page 4]
RFC 1361 SNTP August 1992
Version Number (VN): This is a three-bit integer indicating the NTP
version number, currently 3.
Mode: This is a three-bit integer indicating the mode, with values
defined as follows:
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private use
The use of this field will be discussed in the next section.
Stratum: This is a eight-bit integer indicating the stratum level of
the local clock, with values defined as follows:
Stratum Meaning
----------------------------------------------
0 unspecified or unavailable
1 primary reference (e.g., radio clock)
2-15 secondary reference (via NTP or SNTP)
16-255 reserved
Poll Interval: This is an eight-bit signed integer indicating the
maximum interval between successive messages, in seconds to the
nearest power of two. The values that normally appear in this field
range from 6 to 10, inclusive.
Precision: This is an eight-bit signed integer indicating the
precision of the local clock, in seconds to the nearest power of two.
The values that normally appear in this field range from -6 for
mains-frequency clocks to -18 for microsecond clocks found in some
workstations.
Root Delay: This is a 32-bit signed fixed-point number indicating the
total roundtrip delay to the primary reference source, in seconds
with fraction point between bits 15 and 16. Note that this variable
can take on both positive and negative values, depending on the
relative time and frequency errors. The values that normally appear
in this field range from negative values of a few milliseconds to
positive values of several hundred milliseconds.
Mills [Page 5]
RFC 1361 SNTP August 1992
Root Dispersion: This is a 32-bit unsigned fixed-point number
indicating the maximum error relative to the primary reference
source, in seconds with fraction point between bits 15 and 16. The
values that normally appear in this field range from zero to several
hundred milliseconds.
Reference Clock Identifier: This is a 32-bit code identifying the
particular reference clock. In the case of stratum 0 (unspecified) or
stratum 1 (primary reference), this is a four-octet, left-justified,
zero-padded ASCII string. While not enumerated as part of the NTP
specification, the following are representative ASCII identifiers:
Stratum Code Meaning
------------------------------------------------------------
0 ascii generic time service other than NTP, such as ACTS
(Automated Computer Time Service), TIME (UDP/Time
Protocol), TSP (TSP Unix time protocol), DTSS
(Digital Time Synchronization Service), etc.
1 ATOM calibrated atomic clock
1 VLF VLF radio (OMEGA, etc.)
1 callsign Generic radio
1 LORC LORAN-C radionavigation system
1 GOES Geostationary Operational Environmental Satellite
1 GPS Global Positioning Service
2 address secondary reference (four-octet Internet address of
the NTP server)
Reference Timestamp: This is the local time at which the local clock
was last set or corrected, in 64-bit timestamp format.
Originate Timestamp: This is the local time at which the request
departed the client for the server, in 64-bit timestamp format.
Receive Timestamp: This is the local time at which the request
arrived at the server, in 64-bit timestamp format.
Transmit Timestamp: This is the local time at which the reply
departed the server for the client, in 64-bit timestamp format.
Authenticator (optional): When the NTP authentication mechanism is
implemented, this contains the authenticator information defined in
Appendix C of RFC-1305. In SNTP this field is ignored for incoming
messages and is not generated for outgoing messages.
Mills [Page 6]
RFC 1361 SNTP August 1992
4. SNTP Client Operations
The model for an SNTP client operating with either an NTP or SNTP
server is a RPC client with no persistent state. The client
initializes the SNTP message header, sends the message to the server
and strips the time of day from the reply. For this purpose all of
the message-header fields shown above are set to zero, except the
first octet. In this octet the Leap Indicator is set to zero (no
warning) and the Mode to 3 (client). The Version Number must agree
with the software version of the NTP or SNTP server; however, NTP
Version 3 (RFC-1305) servers will also accept Version 2 (RFC-1119)
and Version 1 (RFC-1059) messages, while NTP Version 2 servers will
also accept NTP Version 1 messages. Version 0 (original NTP described
in RFC-959) messages are no longer supported. Since there are NTP
servers of all three versions operating in the Internet of today, it
is recommended that the Version Number field be set to one.
The server reply includes all the fields described above; however, in
SNTP only the Transmit Timestamp has explicit meaning. The integer
part of this field contains the server time of day in the same format
as the Time Protocol. While the fraction part of this field will
usually be valid, the accuracy achieved with the SNTP mode of access
probably does not justify its use.
The following table is a summary of the SNTP client operations. There
are three recommended error checks shown in the table. In all NTP
versions, if the Leap Indicator field is 3 or the Transmit Timestamp
is zero (unsynchronized), the server has never synchronized or not
synchronized to a valid timing source within the last 24 hours. If
the Stratum field is 0 (unspecified or unavailable), the server has
never synchronized, has lost reachability with all timing sources or
is synchronized by some protocol other than NTP. Whether to believe
the transmit timestamp or not in this case is at the discretion of
the client implementation.
Mills [Page 7]
RFC 1361 SNTP August 1992
Field Name Request Reply
-------------------------------------------------------------
Leap Indicator (LI) 0 if 3 (unsynchronized),
disregard
Version Number (VN) (see text) ignore
Mode 3 (client) ignore
Stratum 0 if 0 (unspecified),
disregard
Poll 0 ignore
Precision 0 ignore
Root Delay 0 ignore
Root Dispersion 0 ignore
Reference Identifier 0 ignore
Reference Timestamp 0 ignore
Originate Timestamp 0 ignore
Receive Timestamp 0 ignore
Transmit Timestamp 0 time of day (seconds only);
if 0 (unsynchronized),
disregard
Authenticator (not used) ignore
5. SNTP Server Operations
The model for an SNTP server operating with either an NTP or SNTP
client is an RPC server with no persistent state. The SNTP server
ignores all header fields except the first octet, modifies certain
fields and returns the message to the sender. Since an SNTP server
ordinarily does not implement the full set of NTP algorithms intended
to support the highest quality service, it is recommended that an
SNTP server be operated only in conjunction with a source of outside
synchronization, such as a radio clock. In this case the server
always operates at stratum 1.
The first octet is interpreted as follows. The Leap Indicator and
Version Number fields are ignored. Optionally, messages with version
numbers other than 1, 2, or 3 can be discarded. For primary servers
connected to a functioning radio clock, the Leap Indicator field is
set to zero and the Stratum field is set to one in the reply.
otherwise, these fields are set to 3 and zero, respectively. In any
case the Version Number and Poll fields are copied intact to the
reply message header. If The Mode field is set to 3 (client), it is
changed to 4 (server) in the reply; otherwise, this field is set to 2
(symmetric passive).
The Stratum field is set to reflect the maximum reading error of the
local clock. For all practical cases it is computed as the negative
of the number of significant bits to the right of the decimal point
in the NTP timestamp format. The Root Delay and Root Dispersion
Mills [Page 8]
RFC 1361 SNTP August 1992
fields are set to zero for a primary server; optionally, the Root
Dispersion can be set to a value corresponding to the expected
(constant) maximum expected error of the primary reference source.
The Reference Identifier is set to designate the primary reference
source, as indicated in the table above. If this information is
unspecified or unavailable, the field is set to zero.
The timestamp fields are set as follows. The Reference Timestamp,
Receive Timestamp and Transmit Timestamp fields are set to the time
of day at the server. The Originate Timestamp field is copied
unchanged from the request. The following table summarizes these
actions.
Field Name Request Reply
----------------------------------------------------------
Leap Indicator (LI) ignore 0 (normal), 3
(unsynchronized)
Version Number (VN) ignore copied from request
Mode (see text) (see text)
Stratum ignore server stratum (1)
Poll ignore copied from request
Precision ignore server precision
Root Delay ignore 0
Root Dispersion ignore 0 (see text)
Reference Identifier ignore source identifier or 0
Reference Timestamp ignore time of day or 0
Originate Timestamp ignore copied from request
Receive Timestamp ignore time of day or 0
Transmit Timestamp ignore time of day or 0
Authenticator ignore (not used)
6. References
[DAR81] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, DARPA, September 1981.
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation and Analysis", RFC 1305, University of Delaware,
March 1992.
[POS80] Postel, J., "User Datagram Protocol", RFC 768,
USC/Information Sciences Institute, August 1980.
[POS83] Postel, J., and K. Harrenstien, "Time Protocol", RFC 868,
USC/Information Sciences Institute, SRI, May 1983.
Mills [Page 9]
RFC 1361 SNTP August 1992
Security Considerations
Security issues are not discussed in this memo.
Author's Address
David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247
EMail: [email protected]
Mills [Page 10]