From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1165.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc1165.txt (limited to 'doc/rfc/rfc1165.txt') 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 -- cgit v1.2.3