As per Relevance of the word broadcast, we have this rfc below:
Network Working Group D.
Request for Comments: 1769 University of
Obsoletes: 1361 March 1995
Category:
Simple Network Time Protocol (SNTP
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is 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 can operate in both
modes (point to point) and broadcast modes (point to multipoint).
can also operate in IP multicast mode where this service
available. SNTP involves no change to the current or previous
specification versions or known implementations, but rather
clarification of certain design features of NTP which allow
in a simple, stateless remote-procedure call (RPC) mode with
and reliability expectations similar to the UDP/TIME
described in RFC-868.
This memorandum obsoletes RFC-1361 of the same title. Its purpose
to explain the protocol model for operation in broadcast mode,
provide additional clarification in some places and to correct a
typographical errors. A working knowledge of the NTP Version 3
specification RFC-1305 is not required for an implementation of SNTP
Distribution of this memorandum is unlimited
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 characteristics of the synchronization source
network paths
Mills [Page 1]
RFC 1769 SNTP March 1995
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,
in the order of large fractions of the second, is sufficient. In
cases simpler protocols such as the Time Protocol [POS83], have
used for this purpose. These protocols usually involve an
exchange where the client requests the time of day and the
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 users of the Internet NTP
subnet of today use a software package including the full suite
NTP 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 less
accuracy expectations
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 NTP or 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,
Mills [Page 2]
RFC 1769 SNTP March 1995
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 deliver incorrect time
Therefore, the use of SNTP rather than NTP in primary servers
be carefully considered
2. Operating Modes and
Like NTP, SNTP can operate in either unicast (point to point)
broadcast (point to multipoint) modes. A unicast client sends
request to a server and expects a reply from which it can
the time and, optionally, the roundtrip delay and local clock
relative to the server. A broadcast server periodically sends
message to a designated IP broadcast address or IP multicast
address and ordinarily expects no requests from clients, while
broadcast client listens on this address and ordinarily sends
requests to servers. Some broadcast servers may elect to respond
client requests as well as send unsolicited broadcast messages,
some broadcast clients may elect to send requests only in order
determine the network propagation delay between the server
client
In unicast mode the client and server IP addresses are
following the usual conventions. In broadcast mode the server uses
designated IP broadcast address or IP multicast group address
together with a designated media-access broadcast address, and
client listens on these addresses. For this purpose, an IP
address has scope limited to a single IP subnet, since routers do
propagate IP broadcast datagrams. In the case of Ethernets,
example, the Ethernet media-access broadcast address (all ones)
used with an IP address consisting of the IP subnet number in the
field and all ones in the host field
On the other hand, an IP multicast group address has scope
to potentially the entire Internet. The actual scope,
membership and routing are determined by the Internet
Management Protocol (IGMP) [DEE89] and various routing protocols
which are beyond the scope of this document. In the case
Ethernets, for example, the Ethernet media-access broadcast
(all ones) is used with the assigned IP multicast group address
224.0.1.1. Other than the IP addressing conventions and IGMP,
is no difference in server operations with either the IP
address or IP multicast group address
Broadcast clients listen on the designated media-access
address, such as all ones in the case of Ethernets. In the case of
broadcast addresses, no further provisions are necessary. In the
Mills [Page 3]
RFC 1769 SNTP March 1995
of IP multicast group addresses, the host may need to implement
in order that the local router intercepts messages to the 224.0.1.1
multicast group. These considerations are beyond the scope of
document
In the case of SNTP as specified herein, there is a very
vulnerability that SNTP multicast clients can be disrupted
misbehaving or hostile SNTP or NTP multicast servers elsewhere in
Internet, since at present all such servers use the same IP
group address 224.0.1.1. Where necessary, access control based on
server source address can be used to select only those servers
to and trusted by the client. Alternatively, by convention
informal agreement, all NTP multicast servers now include an MD5-
encrypted message digest in every message, so that clients
determine if the message is authentic and not modified in transit.
is in principle possible that SNTP clients could implement
necessary encryption and key-distribution schemes, but this
considered not likely in the simple systems for which SNTP
intended
While not integral to the SNTP specification, it is intended that
broadcast addresses will be used primarily in IP subnets and
segments including a fully functional NTP server with a number
SNTP clients in the same subnet, while IP multicast group
will be used only in special cases engineered for the purpose.
particular, IP multicast group addresses should be used in
servers only if the server implements the NTP authentication
described in RFC-1305, including support for the MD5 message-
algorithm
3. 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 0
at the left, or high-order, position. Unless specified otherwise,
quantities are unsigned and may occupy the full field width with
implied 0 preceding bit 0.
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. In the fraction part, the non-significant low-
bits should be set to 0. This format allows convenient multiple
precision arithmetic and conversion to UDP/TIME
Mills [Page 4]
RFC 1769 SNTP March 1995
(seconds), but does complicate the conversion to ICMP
message representation (milliseconds). The precision of
representation is about 200 picoseconds, which should be adequate
even the most exotic requirements
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 0, which by convention is interpreted as
invalid or unavailable timestamp
4. NTP Message
Both NTP and SNTP are clients of the User Datagram Protocol (UDP
[POS80], which itself is a client of the Internet Protocol (IP
[DAR81]. The structure of the IP and UDP headers is described in
cited specification documents and will not be described further here
The UDP port number assigned to NTP is 123, which should be used
both the Source Port and Destination Port fields in the UDP header
The remaining UDP header fields should be set as described in
specification
Mills [Page 5]
RFC 1769 SNTP March 1995
Following is a description of the SNTP message format, which
the IP and UDP headers. The SNTP message format is identical to
NTP format described in RFC-1305, with the exception that some of
data fields are "canned," that is, initialized to pre-
values. The format of the NTP message is shown below
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 pre-specified data. For completeness, the
of each field is briefly summarized below
Mills [Page 6]
RFC 1769 SNTP March 1995
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
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
In unicast mode the client sets this field to 3 (client) in
request and the server sets it to 4 (server) in the reply.
broadcast mode the server sets this field to 5 (broadcast).
Stratum: This is a eight-bit unsigned integer indicating the
level of 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 can appear in this
presently range from 4 (16 s) to 14 (16284 s); however,
applications use only the sub-range 6 (64 s) to 10 (1024 s).
Mills [Page 7]
RFC 1769 SNTP March 1995
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 -20 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 offsets. The values that normally
in this field range from negative values of a few milliseconds
positive values of several hundred milliseconds
Root Dispersion: This is a 32-bit unsigned fixed-point
indicating the nominal 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 0 to
hundred milliseconds
Reference Clock Identifier: This is a 32-bit code identifying
particular reference source. In the case of stratum 0 (unspecified
or stratum 1 (primary reference), this is a four-octet, left
justified, 0-padded ASCII string. While not enumerated as part of
NTP specification, the following are representative
identifiers
Stratum Code
----------------------------------------------------------------
1 pps precision calibrated source, such as ATOM (
clock), PPS (precision pulse-per-second source),
etc
1 service generic time service other than NTP, such as
(Automated Computer Time Service), TIME (UDP/
Protocol), TSP (Unix Time Service Protocol),
(Digital Time Synchronization Service), etc
1 radio Generic radio service, with callsigns such as CHU
DCF77, MSF, TDF, WWV, WWVB, WWVH, etc
1 nav radionavigation system, such as OMEG (OMEGA),
(LORAN-C), etc
1 satellite generic satellite service, such as
(Geostationary Orbit Environment Satellite,
(Global Positioning Service), etc
2 address secondary reference (four-octet Internet address
the NTP server
Mills [Page 8]
RFC 1769 SNTP March 1995
Reference Timestamp: This is the time at which the local clock
last set or corrected, in 64-bit timestamp format
Originate Timestamp: This is the time at which the request
the client for the server, in 64-bit timestamp format
Receive Timestamp: This is the time at which the request arrived
the server, in 64-bit timestamp format
Transmit Timestamp: This is the time at which the reply departed
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
5. SNTP Client
The model for n SNTP client operating with either a NTP or
server is a RPC client with no persistent state. In unicast mode,
client sends a client request (mode 3) to the server and expects
server reply (mode 4). In broadcast mode, the client sends no
and waits for a broadcast message (mode 5) from one or more servers
depending on configuration. Unicast client and broadcast
messages are normally sent at periods from 64 s to 1024 s,
on the client and server configurations
A unicast client initializes the SNTP message header, sends
message to the server and strips the time of day from the reply.
this purpose all of the message-header fields shown above are set
0, except the first octet. In this octet the LI field is set to 0 (
warning) and the Mode field is set to 3 (client). The VN field
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
will also accept NTP Version 1 messages. Version 0 (RFC-959)
are no longer supported. Since there are NTP servers of all
versions interoperating in the Internet of today, it is
that the VN field be set to 1.
In both unicast and broadcast modes, the unicast server reply
broadcast message includes all the fields described above; however
in SNTP only the Transmit Timestamp has explicit meaning and
only if nonzero. The integer part of this field contains the
time of day in the same format as the UDP/TIME Protocol [POS83].
While the fraction part of this field will usually be valid,
accuracy achieved with SNTP may justify its use only to a
Mills [Page 9]
RFC 1769 SNTP March 1995
fraction of a second. If the Transmit Timestamp field is 0,
message should be disregarded
In broadcast mode, a client has no additional information
calculate the propagation delay between the server and client, as
Transmit Timestamp and Receive Timestamp fields have no meaning
this mode. Even in unicast mode, most clients will probably elect
ignore the Originate Timestamp and Receive Timestamp fields anyway
However, in unicast mode a simple calculation can be used to
the roundtrip delay d and local clock offset t relative to
server, generally to within a few tens of milliseconds. To do this
the client sets the Originate Timestamp in the request to the time
day according to its local clock converted to NTP timestamp format
When the reply is received, the client determines a
Timestamp as the time of arrival according to its local
converted to NTP timestamp format. The following table summarizes
four timestamps
Timestamp Name ID When
------------------------------------------------------------
Originate Timestamp T1 time request sent by
Receive Timestamp T2 time request received at
Transmit Timestamp T3 time reply sent by
Destination Timestamp T4 time reply received at
The roundtrip delay d and local clock offset t are defined
d = (T4 - T1) - (T2 - T3)
t = ((T2 - T1) + (T3 - T4)) / 2.
The following table is a summary of the SNTP client operations.
are two recommended error checks shown in the table. In all
versions, if the LI field is 3, or the Stratum field is not in
range 1-15, or the Transmit Timestamp is 0, the server has
synchronized or not synchronized to a valid timing source within
last 24 hours. At the client discretion, the values of the
fields can be checked as well. Whether to believe the
timestamp or not in case one or more of these fields appears
is at the discretion of the implementation
Mills [Page 10]
RFC 1769 SNTP March 1995
Field Name Request
-------------------------------------------------------------
LI 0 leap indicator; if 3
(unsynchronized),
VN 1 (see text)
Mode 3 (client)
Stratum 0
Poll 0
Precision 0
Root Delay 0
Root Dispersion 0
Reference Identifier 0
Reference Timestamp 0
Originate Timestamp 0 (see text) ignore (see text
Receive Timestamp 0 ignore (see text
Transmit Timestamp 0 time of day; if 0
(unsynchronized),
Authenticator (not used)
6. SNTP Server
The model for a SNTP server operating with either a NTP or
client is an RPC server with no persistent state. Since a SNTP
ordinarily does not implement the full set of NTP algorithms
to support redundant peers and diverse network paths, it
recommended that a SNTP server be operated only in conjunction with
source of external synchronization, such as a reliable radio clock
In this case the server always operates at stratum 1.
A server can operate in unicast mode, broadcast mode or both at
same time. In unicast mode the server receives a request message
modifies certain fields in the NTP or SNTP header, and returns
message to the sender, possibly using the same message buffer as
request. The server may or may not respond if not synchronized to
correctly operating radio clock, but the preferred option is
respond, since this allows reachability to be determined
of synchronization state. In unicast mode, the VN and Poll fields
the request are copied intact to the reply. If the Mode field of
request is 3 (client), it is set to 4 (server) in the reply
otherwise, this field is set to 2 (symmetric passive) in order
conform to the NTP specification
In broadcast mode, the server sends messages only if synchronized
a correctly operating reference clock. In this mode, the VN field
set to 3 (for the current SNTP version), and the Mode field to 5
(broadcast). The Poll field is set to the server poll interval,
Mills [Page 11]
RFC 1769 SNTP March 1995
seconds to the nearest power of two. It is highly desirable that,
a server supports broadcast mode, it also supports unicast mode.
is necessary so a potential broadcast client can calculate
propagation delay using client/server messages prior to
operation using only broadcast messages
The remaining fields are set in the same way in both unicast
broadcast modes. Assuming the server is synchronized to a radio
or other primary reference source and operating correctly,
Stratum field is set to 1 (primary server) and the LI field is set
0; if not, the Stratum field is set to 0 and the LI field is set
3. The Precision field is set to reflect the maximum reading error
the local clock. For all practical cases it is computed as
negative of the number of significant bits to the right of
decimal point in the NTP timestamp format. The Root Delay and
Dispersion fields are set to 0 for a primary server; optionally,
Root Dispersion field can be set to a value corresponding to
maximum expected error of the radio clock itself. The
Identifier is set to designate the primary reference source,
indicated in the table above
The timestamp fields are set as follows. If the server
unsynchronized or first coming up, all timestamp fields are set
zero. If synchronized, the Reference Timestamp is set to the time
last update was received from the radio clock or, if unavailable,
the time of day when the message is sent. The Receive Timestamp
Transmit Timestamp fields are set to the time of day when the
is sent. In unicast mode, the Originate Timestamp field is
unchanged from the Transmit Timestamp field of the request. It
important that this field be copied intact, as a NTP client uses
to check for replays. In broadcast mode, this field is set to
time of day when the message is sent. The following table
these actions
Mills [Page 12]
RFC 1769 SNTP March 1995
Field Name Request
----------------------------------------------------------
LI ignore 0 (normal), 3
(unsynchronized
VN 1, 2 or 3 3 or copied from
Mode 3 (see text) 2, 4 or 5 (see text
Stratum ignore 1 server
Poll ignore copied from
Precision ignore server
Root Delay ignore 0
Root Dispersion ignore 0 (see text
Reference Identifier ignore source
Reference Timestamp ignore 0 or time of
Originate Timestamp ignore 0 or time of day or
from Transmit Timestamp
Receive Timestamp ignore 0 or time of
Transmit Timestamp (see text) 0 or time of
Authenticator ignore (not used
There is some latitude on the part of most clients to forgive
timestamps, such as might occur when first coming up or
periods when the primary reference source is inoperative. The
important indicator of an unhealthy server is the LI field, in
a value of 3 indicates an unsynchronized condition. When this
is displayed, clients should discard the server message,
of the contents of other fields
7.
[DAR81] Postel, J., "Internet Protocol - DARPA Internet
Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
[DEE89] Deering, S., "Host Extensions for IP Multicasting. STD 5,
RFC 1112, Stanford University, August 1989.
[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", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[POS83] Postel, J., and K. Harrenstien, "Time Protocol", STD 26,
RFC 868, USC/Information Sciences Institute, SRI, May 1983.
Mills [Page 13]
RFC 1769 SNTP March 1995
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 14]
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
