home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1165.txt < prev    next >
Text File  |  1990-06-24  |  18KB  |  563 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       J. Crowcroft
  8. Request for Comments:  1165                                          UCL
  9.                                                                J. Onions
  10.                                                    Nottingham University
  11.                                                                June 1990
  12.  
  13.  
  14.  
  15.                 Network Time Protocol (NTP) over the OSI
  16.                        Remote Operations Service
  17.  
  18. Status of this Memo
  19.  
  20.    This memo suggests an Experimental Protocol for the OSI and Internet
  21.    communities.  Hosts in either community, and in particular those on
  22.    both are encouraged to experiment with this mechanism.  Please refer
  23.    to the current edition of the "IAB Official Protocol Standards" for
  24.    the standardization state and status of this protocol.  Distribution
  25.    of this memo is unlimited.
  26.  
  27. Table of Contents
  28.  
  29.    1. Introduction...........................................    1
  30.    1.1 Motivation............................................    1
  31.    2. Protocol Overview......................................    2
  32.    3. Operation of the Protocol..............................    3
  33.    4. Network Considerations.................................    4
  34.    5. Implementation Model...................................    4
  35.    6. Constructing NTP Data Fields...........................    4
  36.    7. Discussion.............................................    4
  37.    8. Prototype Experience...................................    5
  38.    9. References.............................................    5
  39.    10. Acknowledgements......................................    6
  40.    Appendix A. NTP Remote Operations Service Specification...    6
  41.    11. Security Considerations...............................    9
  42.    12. Authors' Addresses....................................    9
  43.  
  44. 1.  Introduction
  45.  
  46.    This document describes the Remote Operations and Abstract Syntax for
  47.    the operation of the Network Time Protocol (NTP) over an ISO OSI
  48.    stack.
  49.  
  50.    NTP itself is documented in great detail in RFC 1119.
  51.  
  52. 1.1  Motivation
  53.  
  54.    The motivation behind the implementation of a Remote Operations
  55.  
  56.  
  57.  
  58. Crowcroft & Onions                                              [Page 1]
  59.  
  60. RFC 1165                      NTP over OSI                     June 1990
  61.  
  62.  
  63.    Service implementation of NTP is fourfold.
  64.  
  65.       1.  The inclusion of a useful service to an OSI
  66.           environment.
  67.  
  68.       2.  The feasibility of automatically checking a ROS/ASN.1
  69.           specification, and automatically generating code to
  70.           implement the protocol.
  71.  
  72.       3.  The feasibility of running NTP on connection oriented
  73.           network services (CONS or X.25), and consequentially,
  74.           the ability to use connection success or failure to
  75.           optimise reachability discovery.
  76.  
  77.       4.  The generalisation of the last point: the use of ROS
  78.           makes NTP independent of the underlying communications
  79.           architecture.
  80.  
  81.    The need for time synchronisation is clear, and RFC 1119 indicates a
  82.    few of the necessary uses of this service.  However, it is becoming
  83.    clear that OSI applications are very much in need of this service
  84.    too.  Not just in the local context but across the wide area.  For
  85.    example much of the strong authentication outlined in X.511 is based
  86.    on encrypted packets with time stamps to indicate how long the packet
  87.    is valid for.  If two hosts have clocks that are not closely
  88.    synchronised, the host with the faster clock will be more prone to
  89.    cryptographic attacks from the slower, and the slower host will
  90.    possibly find it is unauthentable.
  91.  
  92.    A similar problem occurs with the X.500 directory and the service
  93.    control limiting the time allowed for the search.
  94.  
  95.    Authentication between NTP peers and between clients and servers is
  96.    not addressed here, as the choice of mechanism is still the subject
  97.    of some debate.
  98.  
  99. 2.  Protocol Overview
  100.  
  101.    The NTP application functions exactly as in RFC 1119.  The use of
  102.    remote operations and the underlying Application support means that
  103.    for NTP daemons to peer with one another, they send an A-
  104.    ASSOCIATE.REQUEST, and receive an A-ASSOCIATE.INDICATION.
  105.  
  106.    On successful association, they subsequently periodically invoke the
  107.    appropriate Remote Operation with the appropriate parameters at the
  108.    appropriate frequency.
  109.  
  110.    On failure, they mark the peer as unreachable.
  111.  
  112.  
  113.  
  114. Crowcroft & Onions                                              [Page 2]
  115.  
  116. RFC 1165                      NTP over OSI                     June 1990
  117.  
  118.  
  119.    The states that an ntp daemon records for each peer are enhanced from
  120.    RFC 1119 to include:
  121.  
  122.       Connected: this indicates the host is connected with its peer and
  123.       synchronisation data is being exchanged.
  124.  
  125.       Connecting: this state indicates that a connection is in progress.
  126.       Hosts at large distances may take several seconds to connect, and
  127.       such blocking can perturb the exchange of data with other hosts.
  128.       Therefore, the connection is made asynchronously.
  129.  
  130.       Accepting: this state indicates that a connection is being
  131.       accepted from another host, but the necessary negotiation of
  132.       transport session etc has not been fulfilled yet.  This is another
  133.       asynchronous part.
  134.  
  135.       Disconnected: this state is reached if the remote host cannot be
  136.       contacted.
  137.  
  138. 3.  Operation of the Protocol
  139.  
  140.    The use of a connection oriented service means that the operation of
  141.    the NTP algorithm is slightly different.  This stems firstly from
  142.    some necessary adjustments made to the protocol and secondly from
  143.    some optimisations that are possible through the use of connections.
  144.  
  145.    Firstly, the reachability of the host can be directly determined.
  146.    The NTP protocol maintains a shift register to determine if it is
  147.    likely that a peer is still responding and exchanging data.  This
  148.    works by recording over the last eight transfers how many responses
  149.    have been received.  If there have been no responses to the last
  150.    eight packets, then the host is deemed unreachable.
  151.  
  152.    Naturally, with a connection to the remote host, the reachability is
  153.    immediately determinable.  Either a connection is established or the
  154.    connection is broken or not yet made.  For this reason it is not
  155.    necessary to rely on the shift register to determine reachability.
  156.  
  157.    Secondly, there are a large number of optimisations that can be made
  158.    by use of the connection oriented mode.  The NTP packet format can be
  159.    broken into several categories.
  160.  
  161.       a) Synchronisation data
  162.  
  163.       b) Authentication data
  164.  
  165.       c) Protocol data
  166.  
  167.  
  168.  
  169.  
  170. Crowcroft & Onions                                              [Page 3]
  171.  
  172. RFC 1165                      NTP over OSI                     June 1990
  173.  
  174.  
  175.    Of these classes of data, only the first (a) is necessary to maintain
  176.    the synchronisation between hosts.  Information such as protocol
  177.    version and the precision of the local clock are not likely to vary
  178.    over the lifetime of the connection.  Likewise the authentication if
  179.    in use need only be done at connection establishment and is not
  180.    necessarily required for every packet.
  181.  
  182.    For these reason, the NTP protocol can be simplified slightly to
  183.    remove this information.  This can be seen in the specification for
  184.    the Packet in Appendix A.
  185.  
  186. 4.  Network Considerations
  187.  
  188.    Although on first inspection it might be thought that a high speed
  189.    network is necessary for accurate synchronisation, this is not the
  190.    case.  What is more important is the dispersion of the packet
  191.    traversal times.  It is normally the case that a low speed network
  192.    with little variance in packet transit times will give better results
  193.    than a high speed network with large differences in individual packet
  194.    transit times.  This would lead us to think that connection oriented
  195.    networks with resource allocation done at connection time might lead
  196.    to higher accuracies than connectionless networks which can suffer
  197.    large swings in packet transit time under high loading.  (This is
  198.    heresy!)
  199.  
  200. 5.  Implementation Model
  201.  
  202.    Ideally, the implementor will provide interoperability between the
  203.    existing UDP based NTP service, and a ROS based service.
  204.  
  205.    To this end, the internal records that hold NTP state information,
  206.    can be kept the same as existing implementations, and for
  207.    optimisation reasons, the internal representations of NTP packets can
  208.    be the same.  Translation between these and appropriate ROS/ASN
  209.    concrete encodings can be provided by automatic translators such as
  210.    Rosy [ISODE].
  211.  
  212. 6.  Constructing NTP Data Fields
  213.  
  214.    The way in which the data fields in the Packet described in Appendix
  215.    A is unchanged from RFC 1119.  This simplifies implementations based
  216.    on existing ones, and encourages interworking.
  217.  
  218. 7.  Discussion
  219.  
  220.    From the limited testing of this model so far done, the results would
  221.    seem to indicate that the ROS based model running over an X.25
  222.    service is of similar reliability as the UDP model.  Until further
  223.  
  224.  
  225.  
  226. Crowcroft & Onions                                              [Page 4]
  227.  
  228. RFC 1165                      NTP over OSI                     June 1990
  229.  
  230.  
  231.    experimentation can be performed, specific data can not be given.
  232.  
  233.    However, in the UK where the most common method of time
  234.    synchronisation is the system administrators watch and typing in the
  235.    time to the nearest minute, this method is clearly far superior.
  236.  
  237.    Connection management is transparent to NTP since it is implemented
  238.    beneath the Remote Operations Service.  However, an NTP
  239.    implementation must have access to the status of connections, and
  240.    uses this not only for reachability information but also to find the
  241.    information gleaned at connect time and no longer exchanged in NTP
  242.    operations.
  243.  
  244. 8.  Prototype Experience
  245.  
  246.    There are a number of UK sites running NTP over ROS over X.25 with an
  247.    earlier ROS specification, with at least one site peering both over
  248.    ROS with UK sites on X.25, and over UDP with US Internet sites.
  249.  
  250.    Initial experience is promising.  The table below shows the
  251.    reachabilities, delays, offsets and dispersions for the central UK
  252.    site peering with 2 JANET sites (IP addresses not meaningful, but
  253.    shown as 126.0.0.1), and three US sites.
  254.  
  255.       Address            Strat Poll Reach    Delay   Offset    Disp
  256.       =============================================================
  257.       +126.0.0.1            3   64  377     718.0      0.0      3.0
  258.       +umd1.umd.edu         1 1024  177     535.0     13.0     13.0
  259.       *128.4.0.5            1   64  167     545.0     10.0    524.0
  260.  
  261. 9.  References
  262.  
  263.    1.  Mills, D., "Network Time Protocol (Version 2) Specification and
  264.        Implementation", RFC-1119, UDEL, September 1989.
  265.  
  266.    2.  Mills, D., "Algorithms for Synchronizing Network Clocks", RFC-
  267.        956, M/A-COM Linkabit, September 1985.
  268.  
  269.    3.  Postel, J. "User Datagram Protocol", RFC-768, USC Information
  270.        Sciences Institute, August 1980.
  271.  
  272.    4.  ISO TC97, "Specification of Abstract Syntax Notation One
  273.        (ASN.1)", Draft International Standard ISO/DIS 8824, 6 June 1985.
  274.  
  275.    5.  CCITT, "Remote Operations: Model, Notation and Service
  276.        Definition", CCITT X.ros0 or ISO/DP 9072/1, Geneva, October 1986.
  277.  
  278.    6.  Mills, D., "Internet Time Synchronization: The Network Time
  279.  
  280.  
  281.  
  282. Crowcroft & Onions                                              [Page 5]
  283.  
  284. RFC 1165                      NTP over OSI                     June 1990
  285.  
  286.  
  287.        Protocol (NTP)", RFC 1129, UDEL, October 1989.
  288.  
  289.    7.  Mills, D., "Measured Performance of the Network Time Protocol in
  290.        the Internet System", RFC 1128, October 1989.
  291.  
  292.    8.  Rose M., et al, "The ISO Development Environment: User's Manual".
  293.  
  294. 10.  Acknowledgements
  295.  
  296.        The Authors would like to thank Dave Mills for his valuable
  297.        comments on an earlier version of this document.
  298.  
  299. Appendix A.  ROS "Header" Format
  300.  
  301.        -- NTP definitions for ROS specification
  302.        --
  303.        -- Julian Onions, Nottingham University, UK.
  304.        --
  305.        -- Mon Jun  5 10:07:07 1989
  306.        --
  307.  
  308.        NTP DEFINITIONS ::=
  309.  
  310.        BEGIN
  311.  
  312.        update OPERATION
  313.         ARGUMENT Packet
  314.         ::= 0
  315.  
  316.        query OPERATION
  317.         ARGUMENT NULL
  318.         RESULT ClockInfoList
  319.         ::= 1
  320.  
  321.        -- Data Structures
  322.  
  323.        BindArgument ::=
  324.         fullbind SEQUENCE {
  325.                 psap[0] IA5String OPTIONAL,
  326.                 version[1] BITSTRING {
  327.                         version-0(0),
  328.                         version-1(1),
  329.                         version-2(2)
  330.                 } DEFAULT version-2,
  331.                 authentication[2] Authentication OPTIONAL,
  332.                 mode[3] BindMode
  333.         }
  334.  
  335.  
  336.  
  337.  
  338. Crowcroft & Onions                                              [Page 6]
  339.  
  340. RFC 1165                      NTP over OSI                     June 1990
  341.  
  342.  
  343.        Authentication ::= ANY
  344.  
  345.        BindMode ::= ENUMERATED {
  346.                 normal(0),      -- standard NTP
  347.                 query(1)        -- queries only
  348.         }
  349.  
  350.        BindResult ::=
  351.         SEQUENCE {
  352.                 version[1] INTEGER DEFAULT 2,
  353.                 authentication[2] Authentication OPTIONAL,
  354.                 mode[3] BindMode
  355.         }
  356.  
  357.        BindError ::=
  358.         SEQUENCE {
  359.                 reason[0] INTEGER {
  360.                         refused(0),
  361.                         validation(1),
  362.                         version(2),     -- version not supported
  363.                         badarg(3),      -- bad bind argument
  364.                         congested(4)    -- catch all!
  365.                 },
  366.                 supplementary[1] IA5String OPTIONAL
  367.         }
  368.  
  369.  
  370.                                         -- basic exchange packet
  371.  
  372.        Packet ::= SEQUENCE {
  373.         leap                    Leap,
  374.         mode                    Mode,
  375.         stratum[1]              INTEGER,
  376.         pollInterval[2]         INTEGER,
  377.         precision[3]            INTEGER,
  378.         synchDistance           SmallFixed,
  379.         synchDispersion         SmallFixed,
  380.         referenceClockIdentifier ClockIdentifier,
  381.         referenceTimestamp      TimeStamp,
  382.         originateTimestamp      TimeStamp,
  383.         receiveTimestamp        TimeStamp,
  384.         transmitTimestamp       TimeStamp
  385.        }
  386.  
  387.        ClockInfoList ::= SET OF ClockInfo
  388.  
  389.        ClockInfo ::= SEQUENCE {
  390.         remoteAddress           Address,
  391.  
  392.  
  393.  
  394. Crowcroft & Onions                                              [Page 7]
  395.  
  396. RFC 1165                      NTP over OSI                     June 1990
  397.  
  398.  
  399.         localAddress            Address,
  400.         flags[0]                BIT STRING {
  401.                         configured(0),
  402.                         authentable(1),
  403.                         sane(2),
  404.                         candidate(3),
  405.                         sync(4),
  406.                         broadcast(5),
  407.                         referenceClock(6),
  408.                         selected(7),
  409.                         inactive(8)
  410.         },
  411.         packetsSent[1]          INTEGER,
  412.         packetsReceived[2]      INTEGER,
  413.         packetsDropped[3]       INTEGER,
  414.         timer[4]                INTEGER,
  415.         leap                    Leap,
  416.         stratum[5]              INTEGER,
  417.         ppoll[6]                INTEGER,
  418.         hpoll[7]                INTEGER,
  419.         precision[8]            INTEGER,
  420.         reachability[9]         INTEGER,
  421.         estdisp[10]             INTEGER,
  422.         estdelay[11]            INTEGER,
  423.         estoffset[12]           INTEGER,
  424.         reference[13]           ClockIdentifier OPTIONAL,
  425.         reftime                 TimeStamp,
  426.         filters                 SEQUENCE OF Filter
  427.        }
  428.  
  429.        Leap ::= [APPLICATION 0] ENUMERATED {
  430.                 nowarning(0),
  431.                 plussecond(1),
  432.                 minussecond(2),
  433.                 alarm(3)
  434.         }
  435.  
  436.        SmallFixed ::= [APPLICATION 1] IMPLICIT SEQUENCE {
  437.                 integer INTEGER,
  438.                 fraction INTEGER
  439.         }
  440.  
  441.        ClockIdentifier ::= CHOICE {
  442.                         referenceClock[0] PrintableString,
  443.                         inetaddr[1] OCTET STRING,
  444.                         psapaddr[2] OCTET STRING
  445.         }
  446.  
  447.  
  448.  
  449.  
  450. Crowcroft & Onions                                              [Page 8]
  451.  
  452. RFC 1165                      NTP over OSI                     June 1990
  453.  
  454.  
  455.        TimeStamp ::= [APPLICATION 2] IMPLICIT SEQUENCE {
  456.                 integer INTEGER,
  457.                 fraction INTEGER
  458.         }
  459.  
  460.        KeyId ::= [APPLICATION 4] INTEGER
  461.  
  462.        Mode ::= [APPLICATION 4] ENUMERATED {
  463.                 unspecified (0),
  464.                 symmetricActive (1),
  465.                 symmetricPassive (2),
  466.                 client (3),
  467.                 server (4),
  468.                 broadcast (5),
  469.                 reservered (6),
  470.                 private (7)
  471.         }
  472.  
  473.        Filter ::= SEQUENCE {
  474.                 offset INTEGER,
  475.                 delay INTEGER
  476.         }
  477.  
  478.        Address ::= OCTET STRING -- for now
  479.        END
  480.  
  481. 11. Security Considerations
  482.  
  483.    Security issues are not discussed in this memo.
  484.  
  485. 12. Authors' Addresses
  486.  
  487.    Jon Crowcroft
  488.    Computer Science Department
  489.    University College London
  490.    Gower Street
  491.    London WC1E 6BT UK
  492.  
  493.    EMail:  JON@CS.UCL.AC.UK
  494.  
  495.  
  496.    Julian P. Onions
  497.    Computer Science Department
  498.    Nottingham University
  499.    University Park
  500.    Nottingham, NG7 2RD UK
  501.  
  502.    EMail:  JPO@CS.NOTT.AC.UK
  503.  
  504.  
  505.  
  506. Crowcroft & Onions                                              [Page 9]
  507.  
  508. RFC 1165                      NTP over OSI                     June 1990
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Crowcroft & Onions                                             [Page 10]
  563.