draft-ietf-ntp-ntpv4-proto-07.txt   draft-ietf-ntp-ntpv4-proto-08.txt 
NTP WG J. Burbank, Ed. NTP WG J. Burbank, Ed.
Internet-Draft W. Kasch, Ed. Internet-Draft W. Kasch, Ed.
Obsoletes: RFC 4330, RFC 1305 JHU/APL Obsoletes: RFC 4330, RFC 1305 JHU/APL
(if approved) J. Martin, Ed. (if approved) J. Martin, Ed.
Intended status: Standards Track Daedelus Intended status: Standards Track Daedelus
Expires: November 2, 2007 D. Mills Expires: May 19, 2008 D. Mills
U. Delaware U. Delaware
November 16, 2007
Network Time Protocol Version 4 Protocol And Algorithms Specification Network Time Protocol Version 4 Protocol And Algorithms Specification
draft-ietf-ntp-ntpv4-proto-07 draft-ietf-ntp-ntpv4-proto-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 2, 2007. This Internet-Draft will expire on May 19, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Network Time Protocol (NTP) is widely used to synchronize The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP Version computer clocks in the Internet. This document describes NTP Version
4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3) 4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3. Protocol Modes . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 7 3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10 5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10
6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 16 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 16 7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 16
7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 16 7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 16
7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 17 7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 17
7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 23 7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 23
7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 24 7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 25
8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 25 8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 25
9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 30 9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 30
9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 32 9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 32
10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 36 10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 36
11. System Process . . . . . . . . . . . . . . . . . . . . . . . 38 11. System Process . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. System Process Variables . . . . . . . . . . . . . . . . 38 11.1. System Process Variables . . . . . . . . . . . . . . . . 38
11.2. System Process Operations . . . . . . . . . . . . . . . . 39 11.2. System Process Operations . . . . . . . . . . . . . . . . 39
11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 42 11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 42
11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 43 11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 43
skipping to change at page 6, line 12 skipping to change at page 6, line 12
or client. A primary server is synchronized to a reference clock or client. A primary server is synchronized to a reference clock
directly traceable to UTC (eg, GPS, Galileo, etc). A client directly traceable to UTC (eg, GPS, Galileo, etc). A client
synchronizes to one or more upstream servers, but does not provide synchronizes to one or more upstream servers, but does not provide
synchronization to dependent clients. A secondary server has one or synchronization to dependent clients. A secondary server has one or
more upstream servers and one or more downstream servers or clients. more upstream servers and one or more downstream servers or clients.
All servers and clients who are fully NTPv4 compliant MUST implement All servers and clients who are fully NTPv4 compliant MUST implement
the entire suite of algorithms described in this document. In order the entire suite of algorithms described in this document. In order
to maintain stability in large NTP subnets, secondary servers SHOULD to maintain stability in large NTP subnets, secondary servers SHOULD
be fully NTPv4 compliant. Alternative algorithms MAY be used, but be fully NTPv4 compliant. Alternative algorithms MAY be used, but
their output MUST be identical to the algorithms described in this their output MUST be identical to the algorithms described in this
specification, or they MUST be used exclusively in a private network. specification.
3. Protocol Modes 3. Protocol Modes
There are three NTP protocol variants, symmetric, client/server and There are three NTP protocol variants, symmetric, client/server and
broadcast. Each is associated with an association mode as shown in broadcast. Each is associated with an association mode as shown in
Figure 1. In addition, persistent associations are mobilized upon Figure 1. In addition, persistent associations are mobilized upon
startup and are never demobilized. Ephemeral associations are startup and are never demobilized. Ephemeral associations are
mobilized upon the arrival of a packet and are demobilized upon error mobilized upon the arrival of a packet and are demobilized upon error
or timeout. or timeout.
skipping to change at page 22, line 15 skipping to change at page 22, line 15
Root Dispersion (rootdisp): Total dispersion to the reference clock, Root Dispersion (rootdisp): Total dispersion to the reference clock,
in NTP short format. in NTP short format.
Reference ID (refid): 32-bit code identifying the particular server Reference ID (refid): 32-bit code identifying the particular server
or reference clock. The interpretation depends on the value in the or reference clock. The interpretation depends on the value in the
stratum field. For packet stratum 0 (unspecified or invalid) this is stratum field. For packet stratum 0 (unspecified or invalid) this is
a four-character ASCII[15] string, called the kiss code, used for a four-character ASCII[15] string, called the kiss code, used for
debugging and monitoring purposes. For stratum 1 (reference clock) debugging and monitoring purposes. For stratum 1 (reference clock)
this is a four-octet, left-justified, zero-padded ASCII string this is a four-octet, left-justified, zero-padded ASCII string
assigned to the reference clock. While not specifically enumerated assigned to the reference clock. The authoritative list of Reference
in this document, the identifiers in Figure 12 have been used as Identifiers is maintained by IANA, however any string begining with
ASCII identifiers: the ASCII character "X" is reserved for unregistered experimentation
and developent.The identifiers in Figure 12 have been used as ASCII
identifiers:
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| ID | Clock Source | | ID | Clock Source |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite | | GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System | | GPS | Global Position System |
| GAL | Galileo Positioning System | | GAL | Galileo Positioning System |
| PPS | Generic pulse-per-second | | PPS | Generic pulse-per-second |
| IRIG | Inter-Range Instrumentation Group | | IRIG | Inter-Range Instrumentation Group |
| WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz | | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz |
skipping to change at page 24, line 16 skipping to change at page 24, line 18
actions: actions:
a. For kiss codes: DENY, RSTR the client MUST demobilize any a. For kiss codes: DENY, RSTR the client MUST demobilize any
associations to that server and stop sending packets to that associations to that server and stop sending packets to that
server; server;
b. For kiss code: RATE the client MUST immediately reduce its b. For kiss code: RATE the client MUST immediately reduce its
polling interval to that server and continue to reduce it each polling interval to that server and continue to reduce it each
time it receives a RATE kiss code. time it receives a RATE kiss code.
c. Other than the above conditions, KoD packets have no protocol c. Kiss codes begining with the ASCII character "X" are for
unregistered experimentation and development and MUST be ignored
if not recognized.
d. Other than the above conditions, KoD packets have no protocol
significance and are discarded after inspection. significance and are discarded after inspection.
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server | | ACST | The association belongs to a unicast server |
| AUTH | Server authentication failed | | AUTH | Server authentication failed |
| AUTO | Autokey sequence failed | | AUTO | Autokey sequence failed |
| BCST | The association belongs to a broadcast server | | BCST | The association belongs to a broadcast server |
| CRYP | Cryptographic authentication or identification failed | | CRYP | Cryptographic authentication or identification failed |
skipping to change at page 55, line 32 skipping to change at page 55, line 32
the IPv6 multicast address ending :101 for NTP. This document the IPv6 multicast address ending :101 for NTP. This document
introduces NTP extension fields allowing for the development of introduces NTP extension fields allowing for the development of
future extensions to the protocol, where a particular extension is to future extensions to the protocol, where a particular extension is to
be identified by the Field Type sub-field within the extension field. be identified by the Field Type sub-field within the extension field.
IANA is requested to establish and maintain a registry for Extension IANA is requested to establish and maintain a registry for Extension
Field Types associated with this protocol, populating this registry Field Types associated with this protocol, populating this registry
with no initial entries. As future needs arise, new Extension Field with no initial entries. As future needs arise, new Extension Field
Types may be defined. Following the policies outlined in [10], new Types may be defined. Following the policies outlined in [10], new
values are to be defined by IETF consensus. values are to be defined by IETF consensus.
The IANA is requested to create a new registry for NTP Reference
Identifier codes. This should include the current codes defined in
Section 7.3, and may be extended on a FCFS basis. The format of the
registry is:
+------+----------------------------------------------------------+
| ID | Clock Source |
+------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System |
| ... | ... |
+------+----------------------------------------------------------+
Figure 35: Reference Identifier Codes
The IANA is requested to create a new registry for NTP Kiss-o'-Death The IANA is requested to create a new registry for NTP Kiss-o'-Death
codes. This should include the current codes defined in Section 7.4, codes. This should include the current codes defined in Section 7.4,
and may be extended on a FCFS basis. The format of the registry is: and may be extended on a FCFS basis. The format of the registry is:
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server | | ACST | The association belongs to a unicast server |
| AUTH | Server authentication failed | | AUTH | Server authentication failed |
| ... | ... | | ... | ... |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Figure 35: Kiss Codes Figure 36: Kiss Codes
For both Reference Identifiers and Kiss-o'-Death codes, IANA is
requested to never assign a code begining with the character "X", as
this is reserved for experimentation and development.
17. Acknowledgements 17. Acknowledgements
The editors would like to thank Karen O'Donoghue, Brian Haberman, The editors would like to thank Karen O'Donoghue, Brian Haberman,
Greg Dowd, Mark Elliot, and Harlan Stenn for technical reviews of Greg Dowd, Mark Elliot, and Harlan Stenn for technical reviews of
this document. this document.
18. References 18. References
18.1. Informative References 18.1. Informative References
 End of changes. 10 change blocks. 
10 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/