SNTP.docx

1、SNTPNetwork Working Group D. MillsRequest for Comments: 2030 University of DelawareObsoletes: 1769 October 1996Category: Informational Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSIStatus of this Memo This memo provides information for the Internet community. This memo does not

2、 specify an Internet standard of any kind. Distribution of this memo is unlimited.Abstract This memorandum describes the Simple Network Time Protocol (SNTP) Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when

3、 the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain desig

4、n features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868. The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modifie

5、d header interpretation to accommodate Internet Protocol Version 6 (IPv6) DEE96 and OSI COL94 addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast

6、modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional. This memorandum obs

7、oletes RFC-1769, which describes SNTP Version 3. Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 and OSI), which are also used for SNTP. A working knowle

8、dge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.Mills Informational Page 1RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 19961. Introduction The Network Time Protocol (NTP) Version 3 specified in RFC-1305 MIL92 is widely used to synchronize computer cloc

9、ks 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-

10、50 ms, depending on the characteristics of the synchronization source and network paths. RFC-1305 specifies the NTP Version 3 protocol machine in terms of events, states, transition functions and actions and, in addition, engineered algorithms to improve the timekeeping quality and mitigate among se

11、veral synchronization sources, some of which may be faulty. 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 in the order of signifi

12、cant fractions of a second are acceptable. In such cases, simpler protocols such as the Time Protocol POS83, have been used for this purpose. These protocols usually involve an RPC exchange where the client requests the time of day and the server returns it in seconds past some known reference epoch

13、. 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 users of the Internet NTP synchronization subnet of today use a software package including the full suite of NTP options and algorithms, which a

14、re relatively complex, real-time applications (see http:/www.eecis.udel.edu/ntp). While the software has been ported to a wide variety of hardware platforms ranging from personal computers to supercomputers, its sheer size and complexity is not appropriate for many applications. Accordingly, it is u

15、seful to explore alternative access strategies using simpler software appropriate for less stringent accuracy expectations. This document describes the Simple Network Time Protocol (SNTP) Version 4, which is a simplified access strategy for servers and clients using NTP Version 3 as now specified an

16、d deployed in the Internet, as well as NTP Version 4 now under development. 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 desig

17、ned 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 theMills Informational Page 2RFC 2030 SNTPv4 for IPv4,

18、IPv6 and OSI October 1996 order of microseconds. SNTP Version 4 is designed to coexist with existing NTP and SNTP Version 3 clients and servers, as well as proposed Version 4 clients and servers. When operating with current and previous versions of NTP and SNTP, SNTP Version 4 requires no changes to

19、 the protocol or implementations now running or likely to be implemented specifically for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and SNTP clients are undistinguishable; to a NTP or SNTP client, NTP and SNTP servers are undistinguishable. Like NTP servers operating in non- symmetric mode

20、s, SNTP servers are stateless and can support large numbers of clients; however, unlike most NTP clients, SNTP clients normally operate with only a single server. NTP and SNTP Version 3 servers can operate in unicast and multicast modes. In addition, SNTP Version 4 clients and servers can implement

21、extensions to operate in anycast mode. 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 NTP or SNTP client is dependent on another SNTP cli

22、ent 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 or modem time service is available. The full degree of reliability ordinarily expected of primary serve

23、rs 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 or modem sources and backup paths to other primary servers should all sources fail or

24、the majority deliver incorrect time. Therefore, the use of SNTP rather than NTP in primary servers should be carefully considered. An important provision in this document is the reinterpretation of certain NTP Versino 4 header fields which provide for IPv6 and OSI addressing and optional anycast ext

25、ensions designed specifically for multicast service. These additions are in conjunction with the proposed NTP Version 4 specification, which will appear as a separate document. The only difference between the current NTP Version 3 and proposed NTP Version 4 header formats is the interpretation of th

26、e four-octet Reference Identifier field, which is used primarily to detect and avoid synchronization loops. In Version 3 and Version 4 primary (stratum-1) servers, this field contains the four-character ASCII reference identifier defined later in this document. In Version 3 secondary servers and cli

27、ents, it contains the 32-bit IPv4 address of the synchronization source. In Version 4 secondary servers and clients, it contains the low order 32 bits of the last transmit timestamp received from the synchronization source.Mills Informational Page 3RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

28、 In the case of OSI, the Connectionless Transport Service (CLTS) is used ISO86. Each SNTP packet is transmitted as tht TS-Userdata parameter of a T-UNITDATA Request primitive. Alternately, the header can be encapsulated in a TPDU which itself is transported using UDP DOB91. It is not advised that NT

29、P be operated at the upper layers of the OSI stack, such as might be inferred from FUR94, as this could seriously degrade accuracy. With the header formats defined in this document, it is in principle possible to interwork between servers and clients of one protocol family and another, although the

30、practical difficulties may make this inadvisable. In the following, indented paragraphs such as this one contain information not required by the formal protocol specification, but considered good practice in protocol implementations.2. Operating Modes and Addressing SNTP Version 4 can operate in eit

31、her unicast (point to point), multicast (point to multipoint) or anycast (multipoint to point) modes. A unicast client sends a request to a designated server at its unicast address and expects a reply from which it can determine the time and, optionally, the roundtrip delay and local clock offset re

32、lative to the server. A multicast server periodically sends a unsolicited message to a designated IPv4 or IPv6 local broadcast address or multicast group address and ordinarily expects no requests from clients. A multicast client listens on this address and ordinarily sends no requests. An anycast client sends a request to a designated IPv4 or IPv6 local b