summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1165.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1165.txt')
-rw-r--r--doc/rfc/rfc1165.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1165.txt b/doc/rfc/rfc1165.txt
new file mode 100644
index 0000000..e91292c
--- /dev/null
+++ b/doc/rfc/rfc1165.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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.
+ Therefore, the connection is made asynchronously.
+
+ Accepting: this state indicates that a connection is being
+ accepted from another host, but the necessary negotiation of
+ transport session etc has not been fulfilled yet. This is another
+ asynchronous part.
+
+ Disconnected: this state is reached if the remote host cannot be
+ contacted.
+
+3. Operation of the Protocol
+
+ The use of a connection oriented service means that the operation of
+ the NTP algorithm is slightly different. This stems firstly from
+ some necessary adjustments made to the protocol and secondly from
+ some optimisations that are possible through the use of connections.
+
+ Firstly, the reachability of the host can be directly determined.
+ The NTP protocol maintains a shift register to determine if it is
+ likely that a peer is still responding and exchanging data. This
+ works by recording over the last eight transfers how many responses
+ have been received. If there have been no responses to the last
+ eight packets, then the host is deemed unreachable.
+
+ Naturally, with a connection to the remote host, the reachability is
+ immediately determinable. Either a connection is established or the
+ connection is broken or not yet made. For this reason it is not
+ necessary to rely on the shift register to determine reachability.
+
+ Secondly, there are a large number of optimisations that can be made
+ by use of the connection oriented mode. The NTP packet format can be
+ broken into several categories.
+
+ a) Synchronisation data
+
+ b) Authentication data
+
+ c) Protocol data
+
+
+
+
+Crowcroft & Onions [Page 3]
+
+RFC 1165 NTP over OSI June 1990
+
+
+ Of these classes of data, only the first (a) is necessary to maintain
+ the synchronisation between hosts. Information such as protocol
+ version and the precision of the local clock are not likely to vary
+ over the lifetime of the connection. Likewise the authentication if
+ in use need only be done at connection establishment and is not
+ necessarily required for every packet.
+
+ For these reason, the NTP protocol can be simplified slightly to
+ remove this information. This can be seen in the specification for
+ the Packet in Appendix A.
+
+4. Network Considerations
+
+ Although on first inspection it might be thought that a high speed
+ network is necessary for accurate synchronisation, this is not the
+ case. What is more important is the dispersion of the packet
+ traversal times. It is normally the case that a low speed network
+ with little variance in packet transit times will give better results
+ than a high speed network with large differences in individual packet
+ transit times. This would lead us to think that connection oriented
+ networks with resource allocation done at connection time might lead
+ to higher accuracies than connectionless networks which can suffer
+ large swings in packet transit time under high loading. (This is
+ heresy!)
+
+5. Implementation Model
+
+ Ideally, the implementor will provide interoperability between the
+ existing UDP based NTP service, and a ROS based service.
+
+ To this end, the internal records that hold NTP state information,
+ can be kept the same as existing implementations, and for
+ optimisation reasons, the internal representations of NTP packets can
+ be the same. Translation between these and appropriate ROS/ASN
+ concrete encodings can be provided by automatic translators such as
+ Rosy [ISODE].
+
+6. Constructing NTP Data Fields
+
+ The way in which the data fields in the Packet described in Appendix
+ A is unchanged from RFC 1119. This simplifies implementations based
+ on existing ones, and encourages interworking.
+
+7. Discussion
+
+ From the limited testing of this model so far done, the results would
+ seem to indicate that the ROS based model running over an X.25
+ service is of similar reliability as the UDP model. Until further
+
+
+
+Crowcroft & Onions [Page 4]
+
+RFC 1165 NTP over OSI June 1990
+
+
+ experimentation can be performed, specific data can not be given.
+
+ However, in the UK where the most common method of time
+ synchronisation is the system administrators watch and typing in the
+ time to the nearest minute, this method is clearly far superior.
+
+ Connection management is transparent to NTP since it is implemented
+ beneath the Remote Operations Service. However, an NTP
+ implementation must have access to the status of connections, and
+ uses this not only for reachability information but also to find the
+ information gleaned at connect time and no longer exchanged in NTP
+ operations.
+
+8. Prototype Experience
+
+ There are a number of UK sites running NTP over ROS over X.25 with an
+ earlier ROS specification, with at least one site peering both over
+ ROS with UK sites on X.25, and over UDP with US Internet sites.
+
+ Initial experience is promising. The table below shows the
+ reachabilities, delays, offsets and dispersions for the central UK
+ site peering with 2 JANET sites (IP addresses not meaningful, but
+ shown as 126.0.0.1), and three US sites.
+
+ Address Strat Poll Reach Delay Offset Disp
+ =============================================================
+ +126.0.0.1 3 64 377 718.0 0.0 3.0
+ +umd1.umd.edu 1 1024 177 535.0 13.0 13.0
+ *128.4.0.5 1 64 167 545.0 10.0 524.0
+
+9. References
+
+ 1. Mills, D., "Network Time Protocol (Version 2) Specification and
+ Implementation", RFC-1119, UDEL, September 1989.
+
+ 2. Mills, D., "Algorithms for Synchronizing Network Clocks", RFC-
+ 956, M/A-COM Linkabit, September 1985.
+
+ 3. Postel, J. "User Datagram Protocol", RFC-768, USC Information
+ Sciences Institute, August 1980.
+
+ 4. ISO TC97, "Specification of Abstract Syntax Notation One
+ (ASN.1)", Draft International Standard ISO/DIS 8824, 6 June 1985.
+
+ 5. CCITT, "Remote Operations: Model, Notation and Service
+ Definition", CCITT X.ros0 or ISO/DP 9072/1, Geneva, October 1986.
+
+ 6. Mills, D., "Internet Time Synchronization: The Network Time
+
+
+
+Crowcroft & Onions [Page 5]
+
+RFC 1165 NTP over OSI June 1990
+
+
+ Protocol (NTP)", RFC 1129, UDEL, October 1989.
+
+ 7. Mills, D., "Measured Performance of the Network Time Protocol in
+ the Internet System", RFC 1128, October 1989.
+
+ 8. Rose M., et al, "The ISO Development Environment: User's Manual".
+
+10. Acknowledgements
+
+ The Authors would like to thank Dave Mills for his valuable
+ comments on an earlier version of this document.
+
+Appendix A. ROS "Header" Format
+
+ -- NTP definitions for ROS specification
+ --
+ -- Julian Onions, Nottingham University, UK.
+ --
+ -- Mon Jun 5 10:07:07 1989
+ --
+
+ NTP DEFINITIONS ::=
+
+ BEGIN
+
+ update OPERATION
+ ARGUMENT Packet
+ ::= 0
+
+ query OPERATION
+ ARGUMENT NULL
+ RESULT ClockInfoList
+ ::= 1
+
+ -- Data Structures
+
+ BindArgument ::=
+ fullbind SEQUENCE {
+ psap[0] IA5String OPTIONAL,
+ version[1] BITSTRING {
+ version-0(0),
+ version-1(1),
+ version-2(2)
+ } DEFAULT version-2,
+ authentication[2] Authentication OPTIONAL,
+ mode[3] BindMode
+ }
+
+
+
+
+Crowcroft & Onions [Page 6]
+
+RFC 1165 NTP over OSI June 1990
+
+
+ Authentication ::= ANY
+
+ BindMode ::= ENUMERATED {
+ normal(0), -- standard NTP
+ query(1) -- queries only
+ }
+
+ BindResult ::=
+ SEQUENCE {
+ version[1] INTEGER DEFAULT 2,
+ authentication[2] Authentication OPTIONAL,
+ mode[3] BindMode
+ }
+
+ BindError ::=
+ SEQUENCE {
+ reason[0] INTEGER {
+ refused(0),
+ validation(1),
+ version(2), -- version not supported
+ badarg(3), -- bad bind argument
+ congested(4) -- catch all!
+ },
+ supplementary[1] IA5String OPTIONAL
+ }
+
+
+ -- basic exchange packet
+
+ Packet ::= SEQUENCE {
+ leap Leap,
+ mode Mode,
+ stratum[1] INTEGER,
+ pollInterval[2] INTEGER,
+ precision[3] INTEGER,
+ synchDistance SmallFixed,
+ synchDispersion SmallFixed,
+ referenceClockIdentifier ClockIdentifier,
+ referenceTimestamp TimeStamp,
+ originateTimestamp TimeStamp,
+ receiveTimestamp TimeStamp,
+ transmitTimestamp TimeStamp
+ }
+
+ ClockInfoList ::= SET OF ClockInfo
+
+ ClockInfo ::= SEQUENCE {
+ remoteAddress Address,
+
+
+
+Crowcroft & Onions [Page 7]
+
+RFC 1165 NTP over OSI June 1990
+
+
+ localAddress Address,
+ flags[0] BIT STRING {
+ configured(0),
+ authentable(1),
+ sane(2),
+ candidate(3),
+ sync(4),
+ broadcast(5),
+ referenceClock(6),
+ selected(7),
+ inactive(8)
+ },
+ packetsSent[1] INTEGER,
+ packetsReceived[2] INTEGER,
+ packetsDropped[3] INTEGER,
+ timer[4] INTEGER,
+ leap Leap,
+ stratum[5] INTEGER,
+ ppoll[6] INTEGER,
+ hpoll[7] INTEGER,
+ precision[8] INTEGER,
+ reachability[9] INTEGER,
+ estdisp[10] INTEGER,
+ estdelay[11] INTEGER,
+ estoffset[12] INTEGER,
+ reference[13] ClockIdentifier OPTIONAL,
+ reftime TimeStamp,
+ filters SEQUENCE OF Filter
+ }
+
+ Leap ::= [APPLICATION 0] ENUMERATED {
+ nowarning(0),
+ plussecond(1),
+ minussecond(2),
+ alarm(3)
+ }
+
+ SmallFixed ::= [APPLICATION 1] IMPLICIT SEQUENCE {
+ integer INTEGER,
+ fraction INTEGER
+ }
+
+ ClockIdentifier ::= CHOICE {
+ referenceClock[0] PrintableString,
+ inetaddr[1] OCTET STRING,
+ psapaddr[2] OCTET STRING
+ }
+
+
+
+
+Crowcroft & Onions [Page 8]
+
+RFC 1165 NTP over OSI June 1990
+
+
+ TimeStamp ::= [APPLICATION 2] IMPLICIT SEQUENCE {
+ integer INTEGER,
+ fraction INTEGER
+ }
+
+ KeyId ::= [APPLICATION 4] INTEGER
+
+ Mode ::= [APPLICATION 4] ENUMERATED {
+ unspecified (0),
+ symmetricActive (1),
+ symmetricPassive (2),
+ client (3),
+ server (4),
+ broadcast (5),
+ reservered (6),
+ private (7)
+ }
+
+ Filter ::= SEQUENCE {
+ offset INTEGER,
+ delay INTEGER
+ }
+
+ Address ::= OCTET STRING -- for now
+ END
+
+11. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+12. Authors' Addresses
+
+ Jon Crowcroft
+ Computer Science Department
+ University College London
+ Gower Street
+ London WC1E 6BT UK
+
+ EMail: JON@CS.UCL.AC.UK
+
+
+ Julian P. Onions
+ Computer Science Department
+ Nottingham University
+ University Park
+ Nottingham, NG7 2RD UK
+
+ EMail: JPO@CS.NOTT.AC.UK
+
+
+
+Crowcroft & Onions [Page 9]
+
+RFC 1165 NTP over OSI June 1990
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crowcroft & Onions [Page 10]
+ \ No newline at end of file