summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1361.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1361.txt')
-rw-r--r--doc/rfc/rfc1361.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1361.txt b/doc/rfc/rfc1361.txt
new file mode 100644
index 0000000..ac938ea
--- /dev/null
+++ b/doc/rfc/rfc1361.txt
@@ -0,0 +1,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: mills@udel.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mills [Page 10]
+ \ No newline at end of file