As per Relevance of the word reference, we have this rfc below:
Network Working Group D.
Request for Comments: 1361 University of
August 1992
Simple Network Time Protocol (SNTP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memorandum describes the Simple Network Time Protocol (SNTP),
which is an adaptation of the Network Time Protocol (NTP) used
synchronize computer clocks in the Internet. SNTP can be used
the ultimate performance of the full NTP implementation described
RFC-1305 is not needed or justified. It involves no change to
current or previous NTP specification versions or
implementations, but rather a clarification of certain
features of NTP which allow operation in a simple, stateless RPC
with accuracy and reliability expectations similar to the UDP/
protocol described in RFC-868.
This memorandum does not obsolete or update any RFC. A
knowledge of RFC-1305 is not required for an implementation of SNTP
1.
The Network Time Protocol (NTP) specified in RFC-1305 [MIL92] is
to synchronize computer clocks in the global Internet. It
comprehensive mechanisms to access national time and
dissemination services, organize the time-synchronization subnet
adjust the local clock in each participating subnet peer. In
places of the Internet of today, NTP provides accuracies of 1-50 ms
depending on the jitter characteristics of the synchronization
and network paths
RFC-1305 specifies the NTP protocol machine in terms of events
states, transition functions and actions and, in addition,
algorithms to improve the timekeeping quality and mitigate
several, possibly faulty, synchronization sources. To
accuracies in the low milliseconds over paths spanning major
of the Internet of today, these intricate algorithms, or
functional equivalents, are necessary. However, in many
accuracies of this order are not required and something less,
Mills [Page 1]
RFC 1361 SNTP August 1992
in the order of one second, is sufficient. In such cases
protocols such as the Time Protocol [POS83], have been used for
purpose. These protocols usually involve a remote-procedure
(RPC) exchange where the client requests the time of day and
server returns it in seconds past some known reference epoch
NTP is designed for use by clients and servers with a wide range
capabilities and over a wide range of network delays and
characteristics. Most members of the Internet NTP
subnet of today use software packages including the full suite of
options and algorithms, which are relatively complex, real-
applications. While the software has been ported to a wide variety
hardware platforms ranging from supercomputers to personal computers
its sheer size and complexity is not appropriate for
applications. Accordingly, it is useful to explore alternative
strategies using far simpler software appropriate for
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
NTP as now specified and deployed in the Internet. There are
changes to the protocol or implementations now running or likely
be implemented in the near future. The access paradigm is
to the UDP/Time Protocol and, in fact, it should be easily
to adapt a UDP/Time client implementation, say for a
computer, to operate using SNTP. Moreover, SNTP is also designed
operate in a dedicated server configuration including an
radio clock. With careful design and control of the various
in the system, which is practical in a dedicated design, it
possible to deliver time accurate to the order of microseconds
It is strongly recommended that SNTP be used only at the
of the synchronization subnet. SNTP clients should operate only
the leaves (highest stratum) of the subnet and in
where no SNTP client is dependent on another SNTP client
synchronization. SNTP servers should operate only at the
(stratum 1) of the subnet and then only in configurations where
other source of synchronization other than a reliable radio clock
available. The full degree of reliability ordinarily expected
primary servers is possible only using the redundant sources,
subnet paths and crafted algorithms of a full NTP implementation
This extends to the primary source of synchronization itself in
form of multiple radio clocks and backup paths to other
servers should the radio clock fail or become faulty. Therefore,
use of SNTP rather than NTP in primary servers should be
considered
Mills [Page 2]
RFC 1361 SNTP August 1992
2. NTP Timestamp
SNTP uses the standard NTP timestamp format described in RFC-1305
previous versions of that document. In conformance with
Internet practice, NTP data are specified as integer or fixed-
quantities, with bits numbered in big-endian fashion from
starting at the left, or high-order, position. Unless
otherwise, all quantities are unsigned and may occupy the full
width with an implied zero preceding bit zero
Since NTP timestamps are cherished data and, in fact, represent
main product of the protocol, a special timestamp format has
established. NTP timestamps are represented as a 64-bit
fixed-point number, in seconds relative to 0h on 1 January 1900.
integer part is in the first 32 bits and the fraction part in
last 32 bits. This format allows convenient multiple-
arithmetic and conversion to Time Protocol representation (seconds),
but does complicate the conversion to ICMP Timestamp
representation (milliseconds). The precision of this
is about 200 picoseconds, which should be adequate for even the
exotic requirements
Note that since some time in 1968 the most significant bit (bit 0
the integer part) has been set and that the 64-bit field
overflow some time in 2036. Should NTP or SNTP be in use in 2036,
some external means will be necessary to qualify time relative
1900 and time relative to 2036 (and other multiples of 136 years).
Timestamped data requiring such qualification will be so
that appropriate means should be readily available. There will
a 200-picosecond interval, henceforth ignored, every 136 years
the 64-bit field will be zero, which by convention is interpreted
an invalid timestamp
3. NTP Message
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
relevant specification documents and will not be described further
this memorandum. Following is a description of the SNTP
format, which follows the IP and UDP headers. The SNTP message
is identical to the NTP format described in RFC-1305, with
exception that some of the data fields are "canned," that is
initialized to prespecified values. The format of the NTP
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
initialized with prespecified data. For completeness, the function
each field is briefly summarized below
Leap Indicator (LI): This is a two-bit code warning of an
leap second to be inserted/deleted in the last minute of the
day, with bit 0 and bit 1, respectively, coded as follows
LI Value
-------------------------------------------------------
00 0 no
01 1 last minute has 61
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
version number, currently 3.
Mode: This is a three-bit integer indicating the mode, with
defined as follows
Mode
------------------------------------
0
1 symmetric
2 symmetric
3
4
5
6 reserved for NTP control
7 reserved for private
The use of this field will be discussed in the next section
Stratum: This is a eight-bit integer indicating the stratum level
the local clock, with values defined as follows
Stratum
----------------------------------------------
0 unspecified or
1 primary reference (e.g., radio clock
2-15 secondary reference (via NTP or SNTP
16-255
Poll Interval: This is an eight-bit signed integer indicating
maximum interval between successive messages, in seconds to
nearest power of two. The values that normally appear in this
range from 6 to 10, inclusive
Precision: This is an eight-bit signed integer indicating
precision of the local clock, in seconds to the nearest power of two
The values that normally appear in this field range from -6
mains-frequency clocks to -18 for microsecond clocks found in
workstations
Root Delay: This is a 32-bit signed fixed-point number indicating
total roundtrip delay to the primary reference source, in
with fraction point between bits 15 and 16. Note that this
can take on both positive and negative values, depending on
relative time and frequency errors. The values that normally
in this field range from negative values of a few milliseconds
positive values of several hundred milliseconds
Mills [Page 5]
RFC 1361 SNTP August 1992
Root Dispersion: This is a 32-bit unsigned fixed-point
indicating the maximum error relative to the primary
source, in seconds with fraction point between bits 15 and 16.
values that normally appear in this field range from zero to
hundred milliseconds
Reference Clock Identifier: This is a 32-bit code identifying
particular reference clock. In the case of stratum 0 (unspecified)
stratum 1 (primary reference), this is a four-octet, left-justified
zero-padded ASCII string. While not enumerated as part of the
specification, the following are representative ASCII identifiers
Stratum Code
------------------------------------------------------------
0 ascii generic time service other than NTP, such as
(Automated Computer Time Service), TIME (UDP/
Protocol), TSP (TSP Unix time protocol),
(Digital Time Synchronization Service), etc
1 ATOM calibrated atomic
1 VLF VLF radio (OMEGA, etc.)
1 callsign Generic
1 LORC LORAN-C radionavigation
1 GOES Geostationary Operational Environmental
1 GPS Global Positioning
2 address secondary reference (four-octet Internet address
the NTP server
Reference Timestamp: This is the local time at which the local
was last set or corrected, in 64-bit timestamp format
Originate Timestamp: This is the local time at which the
departed the client for the server, in 64-bit timestamp format
Receive Timestamp: This is the local time at which the
arrived at the server, in 64-bit timestamp format
Transmit Timestamp: This is the local time at which the
departed the server for the client, in 64-bit timestamp format
Authenticator (optional): When the NTP authentication mechanism
implemented, this contains the authenticator information defined
Appendix C of RFC-1305. In SNTP this field is ignored for
messages and is not generated for outgoing messages
Mills [Page 6]
RFC 1361 SNTP August 1992
4. SNTP Client
The model for an SNTP client operating with either an NTP or
server is a RPC client with no persistent state. The
initializes the SNTP message header, sends the message to the
and strips the time of day from the reply. For this purpose all
the message-header fields shown above are set to zero, except
first octet. In this octet the Leap Indicator is set to zero (
warning) and the Mode to 3 (client). The Version Number must
with the software version of the NTP or SNTP server; however,
Version 3 (RFC-1305) servers will also accept Version 2 (RFC-1119)
and Version 1 (RFC-1059) messages, while NTP Version 2 servers
also accept NTP Version 1 messages. Version 0 (original NTP
in RFC-959) messages are no longer supported. Since there are
servers of all three versions operating in the Internet of today,
is recommended that the Version Number field be set to one
The server reply includes all the fields described above; however,
SNTP only the Transmit Timestamp has explicit meaning. The
part of this field contains the server time of day in the same
as the Time Protocol. While the fraction part of this field
usually be valid, the accuracy achieved with the SNTP mode of
probably does not justify its use
The following table is a summary of the SNTP client operations.
are three recommended error checks shown in the table. In all
versions, if the Leap Indicator field is 3 or the Transmit
is zero (unsynchronized), the server has never synchronized or
synchronized to a valid timing source within the last 24 hours.
the Stratum field is 0 (unspecified or unavailable), the server
never synchronized, has lost reachability with all timing sources
is synchronized by some protocol other than NTP. Whether to
the transmit timestamp or not in this case is at the discretion
the client implementation
Mills [Page 7]
RFC 1361 SNTP August 1992
Field Name Request
-------------------------------------------------------------
Leap Indicator (LI) 0 if 3 (unsynchronized),
Version Number (VN) (see text)
Mode 3 (client)
Stratum 0 if 0 (unspecified),
Poll 0
Precision 0
Root Delay 0
Root Dispersion 0
Reference Identifier 0
Reference Timestamp 0
Originate Timestamp 0
Receive Timestamp 0
Transmit Timestamp 0 time of day (seconds only);
if 0 (unsynchronized),
Authenticator (not used)
5. SNTP Server
The model for an SNTP server operating with either an NTP or
client is an RPC server with no persistent state. The SNTP
ignores all header fields except the first octet, modifies
fields and returns the message to the sender. Since an SNTP
ordinarily does not implement the full set of NTP algorithms
to support the highest quality service, it is recommended that
SNTP server be operated only in conjunction with a source of
synchronization, such as a radio clock. In this case the
always operates at stratum 1.
The first octet is interpreted as follows. The Leap Indicator
Version Number fields are ignored. Optionally, messages with
numbers other than 1, 2, or 3 can be discarded. For primary
connected to a functioning radio clock, the Leap Indicator field
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
case the Version Number and Poll fields are copied intact to
reply message header. If The Mode field is set to 3 (client), it
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
local clock. For all practical cases it is computed as the
of the number of significant bits to the right of the decimal
in the NTP timestamp format. The Root Delay and Root
Mills [Page 8]
RFC 1361 SNTP August 1992
fields are set to zero for a primary server; optionally, the
Dispersion can be set to a value corresponding to the
(constant) maximum expected error of the primary reference source
The Reference Identifier is set to designate the primary
source, as indicated in the table above. If this information
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
of day at the server. The Originate Timestamp field is
unchanged from the request. The following table summarizes
actions
Field Name Request
----------------------------------------------------------
Leap Indicator (LI) ignore 0 (normal), 3
(unsynchronized
Version Number (VN) ignore copied from
Mode (see text) (see text
Stratum ignore server stratum (1)
Poll ignore copied from
Precision ignore server
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
Receive Timestamp ignore time of day or 0
Transmit Timestamp ignore time of day or 0
Authenticator ignore (not used
6.
[DAR81] Postel, J., "Internet Protocol - DARPA Internet
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
Security issues are not discussed in this memo
Author's
David L.
Electrical Engineering
University of
Newark, DE 19716
Phone: (302) 831-8247
EMail: mills@udel.
Mills [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
