rfc2030.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,012 行 · 第 1/4 页

Network Working Group                                           D. Mills
Request for Comments: 2030                        University of Delaware
Obsoletes: 1769                                             October 1996
Category: Informational


             Simple Network Time Protocol (SNTP) Version 4
                         for IPv4, IPv6 and OSI

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not 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 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 design 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 modified 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 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 obsoletes 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 knowledge of the NTP
   Version 3 specification RFC-1305 is not required for an
   implementation of SNTP.



Mills                        Informational                      [Page 1]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


1. Introduction

   The Network Time Protocol (NTP) Version 3 specified in RFC-1305
   [MIL92] is widely 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 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 several 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 significant 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.

   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 are 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 useful
   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 and 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 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



Mills                        Informational                      [Page 2]

RFC 2030             SNTPv4 for IPv4, 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 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 modes, 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 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 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 or modem
   time service 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 or modem sources and backup
   paths to other primary servers should all sources fail or 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 extensions 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 the
   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 clients, 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 3]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   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 NTP 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
   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 either 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
   relative 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 broadcast address or multicast group
   address. One or more anycast servers reply with their individual
   unicast addresses. The client binds to the first one received, then
   continues operation in unicast mode.

      Multicast servers should respond to client unicast requests, as
      well as send unsolicited multicast messages. Multicast clients may
      send unicast requests in order to determine the network
      propagation delay between the server and client and then continue
      operation in multicast mode.

   In unicast mode, the client and server end-system addresses are
   assigned following the usual IPv4, IPv6 or OSI conventions. In
   multicast mode, the server uses a designated local broadcast address
   or multicast group address. An IP local broadcast address has scope
   limited to a single IP subnet, since routers do not propagate IP
   broadcast datagrams. On the other hand, an IP multicast group address
   has scope extending to potentially the entire Internet. The scoping,
   routing and group membership procedures are determined by
   considerations beyond the scope of this document. For IPv4, the IANA
   has assigned the multicast group address 224.0.1.1 for NTP, which is



Mills                        Informational                      [Page 4]

RFC 2030             SNTPv4 for IPv4, IPv6 and OSI          October 1996


   used both by multicast servers and anycast clients. NTP multicast
   addresses for IPv6 and OSI have yet to be determined.

   Multicast clients listen on the designated local broadcast address or
   multicast group address. In the case of local broadcast addresses, no
   further provisions are necessary. In the case of IP multicast
   addresses, the multicast client and anycast server must implement the
   Internet Group Management Protocol (IGMP) [DEE89], in order that the
   local router joins the multicast group and relays messages to the
   IPv4 or IPv6 multicast group addresses assigned by the IANA. Other
   than the IP addressing conventions and IGMP, there is no difference
   in server or client operations with either the local broadcast
   address or multicast group address.

      It is important to adjust the time-to-live (TTL) field in the IP
      header of multicast messages to a reasonable value, in order to
      limit the network resources used by this (and any other) multicast
      service. Only multicast clients in scope will receive multicast
      server messages. Only cooperating anycast servers in scope will
      reply to a client request. The engineering principles which
      determine the proper value to be used are beyond the scope of this
      document.