Network Working Group
`Request for Comments: 1305
`Obsoletes: RFC-1119, RFC-1059, RFC-958
`
`David L. Mills
`University of Delaware
`March 1992
`
`Network Time Protocol (Version 3)
`Specification, Implementation and Analysis
`
`Abstract
`
`This document describes the Network Time Protocol (NTP), specifies its formal structure and
`summarizes information useful for its implementation. NTP provides the mechanisms to synchro-
`nize time and coordinate time distribution in a large, diverse internet operating at rates from mundane
`to lightwave. It uses a returnable-time design in which a distributed subnet of time servers operating
`in a self-organizing, hierarchical-master-slave configuration synchronizes local clocks within the
`subnet and to national time standards via wire or radio. The servers can also redistribute reference
`time via local routing algorithms and time daemons.
`
`Status of this Memo
`
`This RFC specifies an IAB standards track protocol for the Internet community and requests
`discussion and suggestions for improvements. Please refer to the current edition of the “IAB Official
`Protocol Standards” for the standardization state and status of this protocol. Distribution of this
`memo is unlimited.
`
`Keywords: network clock synchronization, standard time distribution, fault-tolerant architecture,
`maximum-likelihood estimation, disciplined oscillator, internet protocol, high-speed networks,
`formal specification.
`
`
`PAGE 1 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`Preface
`
`This document describes Version 3 of the Network Time Protocol (NTP). It supersedes Version 2
`of the protocol described in RFC-1119 dated September 1989. However, it neither changes the
`protocol in any significant way nor obsoletes previous versions or existing implementations. The
`main motivation for the new version is to refine the analysis and implementation models for new
`applications at much higher network speeds to the gigabit-per-second regime and to provide for the
`enhanced stability, accuracy and precision required at such speeds. In particular, the sources of time
`and frequency errors have been rigorously examined and error bounds established in order to
`improve performance, provide a model for correctness assertions and indicate timekeeping quality
`to the user. The revision also incorporates two new optional features, (1) an algorithm to combine
`the offsets of a number of peer time servers in order to enhance accuracy and (2) improved
`local-clock algorithms which allow the poll intervals on all synchronization paths to be substantially
`increased in order to reduce network overhead. An overview of the changes, which are described
`in detail in Appendix D, follows:
`
`1.
`
`2.
`
`In Version 3 The local-clock algorithm has been overhauled to improve stability and accuracy.
`Appendix G presents a detailed mathematical model and design example which has been refined
`with the aid of feedback-control analysis and extensive simulation using data collected over
`ordinary Internet paths. Section 5 of RFC-1119 on the NTP local clock has been completely
`rewritten to describe the new algorithm. Since the new algorithm can result in message rates far
`below the old ones, it is highly recommended that they be used in new implementations. Note
`that use of the new algorithm does not affect interoperability with previous versions or existing
`implementations.
`
`In Version 3 a new algorithm to combine the offsets of a number of peer time servers is presented
`in Appendix F. This algorithm is modelled on those used by national standards laboratories to
`combine the weighted offsets from a number of standard clocks to construct a synthetic
`laboratory timescale more accurate than that of any clock separately. It can be used in an NTP
`implementation to improve accuracy and stability and reduce errors due to asymmetric paths in
`the Internet. The new algorithm has been simulated using data collected over ordinary Internet
`paths and, along with the new local-clock algorithm, implemented and tested in the Fuzzball
`time servers now running in the Internet. Note that use of the new algorithm does not affect
`interoperability with previous versions or existing implementations.
`
`3. Several inconsistencies and minor errors in previous versions have been corrected in Version
`3. The description of the procedures has been rewritten in pseudo-code augmented by English
`commentary for clarity and to avoid ambiguity. Appendix I has been added to illustrate
`C-language implementations of the various filtering and selection algorithms suggested for NTP.
`Additional information is included in Section 5 and in Appendix E, which includes the tutorial
`material formerly included in Section 2 of RFC-1119, as well as much new material clarifying
`the interpretation of timescales and leap seconds.
`
`4. Minor changes have been made in the Version-3 local-clock algorithms to avoid problems
`observed when leap seconds are introduced in the UTC timescale and also to support an auxiliary
`
`Mills
`
`Page ii
`
`
`PAGE 2 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`precision oscillator, such as a cesium clock or timing receiver, as a precision timebase. In
`addition, changes were made to some procedures described in Section 3 and in the clock-filter
`and clock-selection procedures described in Section 4. While these changes were made to correct
`minor bugs found as the result of experience and are recommended for new implementations,
`they do not affect interoperability with previous versions or existing implementations in other
`than minor ways (at least until the next leap second).
`
`5.
`
`In Version 3 changes were made to the way delay, offset and dispersion are defined, calculated
`and processed in order to reliably bound the errors inherent in the time-transfer procedures. In
`particular, the error accumulations were moved from the delay computation to the dispersion
`computation and both included in the clock filter and selection procedures. The clock-selection
`procedure was modified to remove the first of the two sorting/discarding steps and replace with
`an algorithm first proposed by Marzullo and later incorporated in the Digital Time Service.
`These changes do not significantly affect the ordinary operation of or compatibility with various
`versions of NTP, but they do provide the basis for formal statements of correctness as described
`in Appendix H.
`
`Mills
`
`Page iii
`
`
`PAGE 3 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`Table of Contents
`
`1.
`1.1.
`2.
`2.1.
`2.2.
`3.
`3.1.
`3.2.
`3.2.1.
`3.2.2.
`3.2.3.
`3.2.4.
`3.2.5.
`3.2.6.
`3.2.7.
`3.3.
`3.4.
`3.4.1.
`3.4.2.
`3.4.3.
`3.4.4.
`3.4.5.
`3.4.6.
`3.4.7.
`3.4.7.1.
`3.4.7.2.
`3.4.7.3.
`3.4.7.4.
`3.4.8.
`3.4.9.
`3.5.
`3.6.
`4.
`4.1.
`4.2.
`4.2.1.
`5.
`5.1.
`5.2.
`5.3.
`5.4.
`
` Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
` Related Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
` System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
` Implementation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
` Network Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
` Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
` Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
` State Variables and Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
` Common Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
` System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
` Peer Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
` Packet Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
` Clock-Filter Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
` Authentication Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
` Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
` Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
` Event Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
` Notation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
` Transmit Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
` Receive Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
` Packet Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
` Clock-Update Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
` Primary-Clock Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
` Initialization Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
` Initialization Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
` Initialization-Instantiation Procedure . . . . . . . . . . . . . . . . . . . . . . 29
` Receive-Instantiation Procedure . . . . . . . . . . . . . . . . . . . . . . . . 30
` Primary Clock-Instantiation Procedure . . . . . . . . . . . . . . . . . . . . . 31
` Clear Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
` Poll-Update Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
` Synchronization Distance Procedure . . . . . . . . . . . . . . . . . . . . . . . . 32
` Access Control Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
` Filtering and Selection Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
` Clock-Filter Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
` Clock-Selection Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
` Intersection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
` Local Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
` Fuzzball Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
` Gradual Phase Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
` Step Phase Adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
` Implementation Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
`
`Mills
`
`Page iv
`
`
`PAGE 4 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`6.
`7.
`A.
`B.
`B.1.
`B.2.
`B.2.1.
`B.2.2.
`B.2.3.
`B.2.4.
`B.3.
`C.
`C.1.
`C.2.
`C.2.1.
`4.2.2.
`C.2.2.
`C.2.3.
`D.
`E.
`E.1.
`E.2.
`E.3.
`E.4.
`E.5.
`E.6.
`E.7.
`E.8.
`F.
`F.1.
`F.2.
`F.3.
`F.4.
`F.5.
`F.6.
`G.
`G.1.
`G.1.1.
`G.1.2.
`G.2.
`G.3.
`G.4.
`
`Mills
`
` Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
` References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
` Appendix A. NTP Data Format - Version 3 . . . . . . . . . . . . . . . . . . . . . . 50
` Appendix B. NTP Control Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 53
` NTP Control Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
` Status Words . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
` System Status Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
` Peer Status Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
` Clock Status Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
` Error Status Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
` Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
` Appendix C. Authentication Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
` NTP Authentication Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
` NTP Authentication Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
` Encrypt Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
` Clustering Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
` Decrypt Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
` Control-Message Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
` Appendix D. Differences from Previous Versions. . . . . . . . . . . . . . . . . . . . 66
` Appendix E. The NTP Timescale and its Chronometry . . . . . . . . . . . . . . . . 70
` Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
` Primary Frequency and Time Standards . . . . . . . . . . . . . . . . . . . . . . . 70
` Time and Frequency Dissemination . . . . . . . . . . . . . . . . . . . . . . . . . 72
` Calendar Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
` The Modified Julian Day System . . . . . . . . . . . . . . . . . . . . . . . . . . 75
` Determination of Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
` Determination of Time and Leap Seconds . . . . . . . . . . . . . . . . . . . . . . 76
` The NTP Timescale and Reckoning with UTC . . . . . . . . . . . . . . . . . . . 78
` Appendix F. The NTP Clock-Combining Algorithm . . . . . . . . . . . . . . . . . 80
` Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
` Determining Time and Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . 80
` Clock Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
` Development of a Composite Timescale . . . . . . . . . . . . . . . . . . . . . . 81
` Application to NTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
` Clock-Combining Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
` Appendix G. Computer Clock Modelling and Analysis . . . . . . . . . . . . . . . . 86
` Computer Clock Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
` The Fuzzball Clock Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
` The Unix Clock Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
` Mathematical Model of the NTP Logical Clock . . . . . . . . . . . . . . . . . . . 91
` Parameter Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
` Adjusting VCO Gain (a )
` . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
`
`Page v
`
`
`PAGE 5 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`G.5.
`G.6.
`H.
`H.1.
`H.2.
`H.3.
`H.4.
`H.5.
`H.6.
`I.
`I.1.
`I.2.
`I.3.
`I.4.
`I.5.
`I.6.
`
` Adjusting PLL Bandwidth (t ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
` The NTP Clock Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
` Appendix H. Analysis of Errors and Correctness Principles . . . . . . . . . . . . . . 98
` Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
` Timestamp Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
` Measurement Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
` Network Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
` Inherited Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
` Correctness Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
` Appendix I. Selected C-Language Program Listings . . . . . . . . . . . . . . . . . . 107
` Common Definitions and Variables . . . . . . . . . . . . . . . . . . . . . . . . . 107
` Clock–Filter Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
` Interval Intersection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
` Clock–Selection Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
` Clock–Combining Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
` Subroutine to Compute Synchronization Distance . . . . . . . . . . . . . . . . . 112
`
`List of Figures
`
`Figure 1. Implementation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
`Figure 2. Calculating Delay and Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
`Figure 3. Clock Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
`Figure 4. NTP Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
`Figure 5. NTP Control Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
`Figure 6. Status Word Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
`Figure 7. Authenticator Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
`Figure 8. Comparison of UTC and NTP Timescales at Leap . . . . . . . . . . . . . . . . . . 79
`Figure 9. Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
`Figure 10. Hardware Clock Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
`Figure 11. Clock Adjustment Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
`Figure 12. NTP Phase-Lock Loop (PLL) Model . . . . . . . . . . . . . . . . . . . . . . . . 91
`Figure 13. Timing Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
`Figure 14. Measuring Delay and Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
`Figure 15. Error Accumulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
`Figure 16. Confidence Intervals and Intersections . . . . . . . . . . . . . . . . . . . . . . . 105
`
`List of Tables
`
`Table 1. System Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
`Table 2. Peer Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`Table 3. Packet Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
`Table 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
`Table 5. Modes and Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
`Table 6. Clock Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
`
`Mills
`
`Page vi
`
`
`PAGE 6 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`Table 7. Characteristics of Standard Oscillators . . . . . . . . . . . . . . . . . . . . . . . . 71
`Table 8. Table of Leap-Second Insertions . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
`Table 9. Notation Used in PLL Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
`Table 10. PLL Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
`Table 11. Notation Used in PLL Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
`Table 12. Notation Used in Error Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
`
`Mills
`
`Page vii
`
`
`PAGE 7 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`1. Introduction
`
`This document constitutes a formal specification of the Network Time Protocol (NTP) Version 3,
`which is used to synchronize timekeeping among a set of distributed time servers and clients. It
`defines the architectures, algorithms, entities and protocols used by NTP and is intended primarily
`for implementors. A companion document [MIL91a] summarizes the requirements, analytical
`models, algorithmic analysis and performance under typical Internet conditions. Another document
`[MIL91b] describes the NTP timescale and its relationship to other standard timescales now in use.
`NTP was first described in RFC-958 [MIL85c], but has since evolved in significant ways,
`culminating in the most recent NTP Version 2 described in RFC-1119 [MIL89]. It is built on the
`Internet Protocol (IP) [DAR81a] and User Datagram Protocol (UDP) [POS80], which provide a
`connectionless transport mechanism; however, it is readily adaptable to other protocol suites. NTP
`is evolved from the Time Protocol [POS83b] and the ICMP Timestamp message [DAR81b], but is
`specifically designed to maintain accuracy and robustness, even when used over typical Internet
`paths involving multiple gateways, highly dispersive delays and unreliable nets.
`
`The service environment consists of the implementation model and service model described in
`Section 2. The implementation model is based on a multiple-process operating system architecture,
`although other architectures could be used as well. The service model is based on a returnable-time
`design which depends only on measured clock offsets, but does not require reliable message
`delivery. The synchronization subnet uses a self-organizing, hierarchical-master-slave configura-
`tion, with synchronization paths determined by a minimum-weight spanning tree. While multiple
`masters (primary servers) may exist, there is no requirement for an election protocol.
`
`NTP itself is described in Section 3. It provides the protocol mechanisms to synchronize time in
`principle to precisions in the order of nanoseconds while preserving a non-ambiguous date well into
`the next century. The protocol includes provisions to specify the characteristics and estimate the
`error of the local clock and the time server to which it may be synchronized. It also includes
`provisions for operation with a number of mutually suspicious, hierarchically distributed primary
`reference sources such as radio-synchronized clocks.
`
`Section 4 describes algorithms useful for deglitching and smoothing clock-offset samples collected
`on a continuous basis. These algorithms evolved from those suggested in [MIL85a], were refined
`as the results of experiments described in [MIL85b] and further evolved under typical operating
`conditions over the last three years. In addition, as the result of experience in operating multiple-
`server subnets including radio clocks at several sites in the U.S. and with clients in the U.S. and
`Europe, reliable algorithms for selecting good clocks from a population possibly including broken
`ones have been developed [DEC89], [MIL91a] and are described in Section 4.
`
`The accuracies achievable by NTP depend strongly on the precision of the local-clock hardware
`and stringent control of device and process latencies. Provisions must be included to adjust the
`software logical-clock time and frequency in response to corrections produced by NTP. Section 5
`describes a local-clock design evolved from the Fuzzball implementation described in [MIL83b]
`and [MIL88b]. This design includes offset-slewing, frequency compensation and deglitching
`
`Mills
`
`Page 1
`
`
`PAGE 8 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`mechanisms capable of accuracies in the order of a millisecond, even after extended periods when
`synchronization to primary reference sources has been lost.
`
`Details specific to NTP packet formats used with the Internet Protocol (IP) and User Datagram
`Protocol (UDP) are presented in Appendix A, while details of a suggested auxiliary NTP Control
`Message, which may be used when comprehensive network-monitoring facilities are not available,
`are presented in Appendix B. Appendix C contains specification and implementation details of an
`optional authentication mechanism which can be used to control access and prevent unauthorized
`data modification, while Appendix D contains a listing of differences between Version 3 of NTP
`and previous versions. Appendix E expands on issues involved with precision timescales and
`calendar dating peculiar to computer networks and NTP. Appendix F describes an optional
`algorithm to improve accuracy by combining the time offsets of a number of clocks. Appendix G
`presents a detailed mathematical model and analysis of the NTP local-clock algorithms. Appendix
`H analyzes the sources and propagation of errors and presents correctness principles relating to the
`time-transfer service. Appendix I illustrates C-language code segments for the clock-filter, clock-
`selection and related algorithms described in Section 4.
`
`1.1. Related Technology
`
`Other mechanisms have been specified in the Internet protocol suite to record and transmit the time
`at which an event takes place, including the Daytime protocol [POS83a], Time Protocol [POS83b],
`ICMP Timestamp message [DAR81b] and IP Timestamp option [SU81]. Experimental results on
`measured clock offsets and roundtrip delays in the Internet are discussed in [MIL83a], [MIL85b],
`[COL88] and [MIL88a]. Other synchronization algorithms are discussed in [LAM78], [GUS84],
`[HAL84], [LUN84], [LAM85], [MAR85], [MIL85a], [MIL85b], [MIL85c], [GUS85b], [SCH86],
`[TRI86], [RIC88], [MIL88a], [DEC89] and [MIL91a], while protocols based on them are described
`in [MIL81a], [MIL81b], [MIL83b], [GUS85a], [MIL85c], [TRI86], [MIL88a], [DEC89] and
`[MIL91a]. NTP uses techniques evolved from them and both linear-systems and agreement
`methodologies. Linear methods for digital telephone network synchronization are summarized in
`[LIN80], while agreement methods for clock synchronization are summarized in [LAM85].
`
`The Digital Time Service (DTS) [DEC89] has many of the same service objectives as NTP. The
`DTS design places heavy emphasis on configuration management and correctness principles when
`operated in a managed LAN or LAN-cluster environment, while NTP places heavy emphasis on
`the accuracy and stability of the service operated in an unmanaged, global-internet environment. In
`DTS a synchronization subnet consists of clerks, servers, couriers and time providers. With respect
`to the NTP nomenclature, a time provider is a primary reference source, a courier is a secondary
`server intended to import time from one or more distant primary servers for local redistribution and
`a server is intended to provide time for possibly many end nodes or clerks. Unlike NTP, DTS does
`not need or use mode or stratum information in clock selection and does not include provisions to
`filter timing noise, select the most accurate from a set of presumed correct clocks or compensate
`for inherent frequency errors.
`
`In fact, the latest revisions in NTP have adopted certain features of DTS in order to support
`correctness principles. These include mechanisms to bound the maximum errors inherent in the
`
`Mills
`
`Page 2
`
`
`PAGE 9 OF 120
`
`SONOS EXHIBIT 1011
`IPR of U.S. Pat. No. 8,942,252
`
`

`

`RFC-1305
`
`Network Time Protocol (Version 3)
`
`March 1992
`
`time-transfer procedures and the use of a provably correct (subject to stated assumptions) mecha-
`nism to reject inappropriate peers in the clock-selection procedures. These features are described in
`Section 4 and Appendix H of this document.
`
`The Fuzzball routing protocol [MIL83b], sometimes called Hellospeak, incorporates time synchro-
`nization directly into the routing-protocol design. One or more processes synchronize to an external
`reference source, such as a radio clock or NTP daemon, and the routing algorithm constructs a
`minimum-weight spanning tree rooted on these processes. The clock offsets are then distributed
`along the arcs of the spanning tree to all processes in the system and the various process clocks
`corrected using the procedure described in Section 5 of this document. While it can be seen that the
`design of Hellospeak strongly influenced the design of NTP, Hellospeak itself is not an Internet
`protocol and is unsuited for use outside its local-net environment.
`
`The Unix 4.3bsd time daemon timed [GUS85a] uses a single master-time daemon to measure offsets
`of a number of slave hosts and send periodic corrections to them. In this model the master is
`determined using an election algorithm [GUS85b] designed to avoid situations where either no
`master is elected or more than one master is elected. The election process requires a broadcast
`capability, which is not a ubiquitous feature of the Internet. While this model has been extended to
`support hierarchical configurations in which a slave on one network serves as a master on the other
`[TRI86], the model requires handcrafted configuration tables in order to establish the hierarchy and
`avoid loops. In addition to the burdensome, but presumably infrequent, overheads of the election
`process, the offset measurement/correction process requires twice as many messages as NTP per
`update.
`
`A scheme with features similar to NTP is described in [KOP87]. This scheme is intended for
`multi-server LANs where each of a set of possibly many time servers determines its local-time offset
`relative to each of the other servers in the set using periodic timestamped messages, then determines
`the local-clock correctio