Network Time Protocol (NTP) over the OSI Remote Operations Service
RFC 1165
|
Document |
Type |
|
RFC - Experimental
(June 1990; No errata)
|
|
Authors |
|
Julian Onions
,
Jon Crowcroft
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1165 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group J. Crowcroft
Request for Comments: 1165 UCL
J. Onions
Nottingham University
June 1990
Network Time Protocol (NTP) over the OSI
Remote Operations Service
Status of this Memo
This memo suggests an Experimental Protocol for the OSI and Internet
communities. Hosts in either community, and in particular those on
both are encouraged to experiment with this mechanism. 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.
Table of Contents
1. Introduction........................................... 1
1.1 Motivation............................................ 1
2. Protocol Overview...................................... 2
3. Operation of the Protocol.............................. 3
4. Network Considerations................................. 4
5. Implementation Model................................... 4
6. Constructing NTP Data Fields........................... 4
7. Discussion............................................. 4
8. Prototype Experience................................... 5
9. References............................................. 5
10. Acknowledgements...................................... 6
Appendix A. NTP Remote Operations Service Specification... 6
11. Security Considerations............................... 9
12. Authors' Addresses.................................... 9
1. Introduction
This document describes the Remote Operations and Abstract Syntax for
the operation of the Network Time Protocol (NTP) over an ISO OSI
stack.
NTP itself is documented in great detail in RFC 1119.
1.1 Motivation
The motivation behind the implementation of a Remote Operations
Crowcroft & Onions [Page 1]
RFC 1165 NTP over OSI June 1990
Service implementation of NTP is fourfold.
1. The inclusion of a useful service to an OSI
environment.
2. The feasibility of automatically checking a ROS/ASN.1
specification, and automatically generating code to
implement the protocol.
3. The feasibility of running NTP on connection oriented
network services (CONS or X.25), and consequentially,
the ability to use connection success or failure to
optimise reachability discovery.
4. The generalisation of the last point: the use of ROS
makes NTP independent of the underlying communications
architecture.
The need for time synchronisation is clear, and RFC 1119 indicates a
few of the necessary uses of this service. However, it is becoming
clear that OSI applications are very much in need of this service
too. Not just in the local context but across the wide area. For
example much of the strong authentication outlined in X.511 is based
on encrypted packets with time stamps to indicate how long the packet
is valid for. If two hosts have clocks that are not closely
synchronised, the host with the faster clock will be more prone to
cryptographic attacks from the slower, and the slower host will
possibly find it is unauthentable.
A similar problem occurs with the X.500 directory and the service
control limiting the time allowed for the search.
Authentication between NTP peers and between clients and servers is
not addressed here, as the choice of mechanism is still the subject
of some debate.
2. Protocol Overview
The NTP application functions exactly as in RFC 1119. The use of
remote operations and the underlying Application support means that
for NTP daemons to peer with one another, they send an A-
ASSOCIATE.REQUEST, and receive an A-ASSOCIATE.INDICATION.
On successful association, they subsequently periodically invoke the
appropriate Remote Operation with the appropriate parameters at the
appropriate frequency.
On failure, they mark the peer as unreachable.
Crowcroft & Onions [Page 2]
RFC 1165 NTP over OSI June 1990
The states that an ntp daemon records for each peer are enhanced from
RFC 1119 to include:
Connected: this indicates the host is connected with its peer and
synchronisation data is being exchanged.
Connecting: this state indicates that a connection is in progress.
Hosts at large distances may take several seconds to connect, and
such blocking can perturb the exchange of data with other hosts.
Show full document text