Browse Prior Art Database

Network Time Protocol (NTP) (RFC0958)

IP.com Disclosure Number: IPCOM000004954D
Original Publication Date: 1985-Sep-01
Included in the Prior Art Database: 2001-Jul-12
Document File: 15 page(s) / 31K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.L. Mills: AUTHOR

Abstract

2. Service Model 3. Protocol Overview 4. State Variables and Formats 5. Protocol Operation 5.1. Protocol Modes 5.2. Message Processing 5.3. Network Considerations 5.4. Leap Seconds 6. References Appendix A. UDP Header Format Appendix B. NTP Data Format

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 12% of the total text.

Network Working Group D.L. Mills Request for Comments: 958 M/A-COM Linkabit

September 1985

Network Time Protocol (NTP)

Status of this Memo

This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Table of Contents

1. Introduction 2. Service Model 3. Protocol Overview 4. State Variables and Formats 5. Protocol Operation 5.1. Protocol Modes 5.2. Message Processing 5.3. Network Considerations 5.4. Leap Seconds 6. References Appendix A. UDP Header Format Appendix B. NTP Data Format

1. Introduction

This document describes the Network Time Protocol (NTP), a protocol for synchronizing a set of network clocks using a set of distributed clients and servers. NTP is built on the User Datagram Protocol (UDP) [13], which provides a connectionless transport mechanism. It is evolved from the Time Protocol [7] and the ICMP Timestamp message [6] and is a suitable replacement for both.

NTP provides the protocol mechanisms to synchronize time in principle to precisions in the order of nanoseconds while preserving a non-ambiguous date, at least for this century. The protocol includes provisions to specify the precision and estimated error of the local clock and the characteristics of the reference clock to which it may be synchronized. However, the protocol itself specifies only the data representation and message formats and does not specify the synchronizing algorithms or filtering mechanisms.

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 [8] and IP Timestamp option [9]. The NTP is not meant to displace either of these mechanisms. Additional information on network time synchronization can be found in the

Mills [Page 1]

RFC 958 September Network Time Protocol

References at the end of this document. An earlier synchronization protocol is discussed in [3] and synchronization algorithms in [2], [5], [10] and [12]. Experimental results on measured roundtrip delays and clock offsets in the Internet are discussed in [4] and [11]. A comprehensive mathematical treatment of clock synchronization can be found in [1].

2. Service Model

The intent of the service for which this protocol is designed is to connect a few primary reference clocks, synchronized by wire or radio to national standards, to centrally accessable resources such as gateways. These gateways would use NTP between them to cross-check the primary clocks and mitigate errors due to equipment or propagation failures. Some number of local-net hosts, serving as secondary reference clocks, would run NTP with one or more of these gateways. In order to reduce the protocol overhead, these hosts would redistribute time to the remaining local-net hosts. In the interest of reliability selected hosts might be equipped with less accurate but less expensive radio clocks and used for backup in case of failure of the p...