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