Internet DRAFT - draft-levine-nist-acts

draft-levine-nist-acts





      Network Working Group                                       Glasey.Todd
      Internet Draft                                                    GMTsw
      Document: <draft-levine-nist-acts-00.txt>                   27-Mar-1999
      Category: Informational


                    ACTS Protocol and Timesetting Services


      Status of this Memo

         This document is an Internet-Draft and is NOT offered in
         accordance with Section 10 of RFC2026, and the author does not
         provide the IETF with any rights other than to publish as an
         Internet-Draft.

         Internet-Drafts are working documents of the Internet
         Engineering Task Force (IETF), its areas, and its working
         groups. Note that other groups may also distribute working
         documents as Internet-Drafts. Internet-Drafts are draft
         documents valid for a maximum of six months and may be
         updated, replaced, or obsoleted by other documents at any
         time. It is inappropriate to use Internet- Drafts as reference
         material or to cite them other than as "work in progress."

         The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
         The list of Internet-Draft Shadow Directories can be accessed
         at http://www.ietf.org/shadow.html.



      1.   Abstract

         The Automated Computer Time Service [ACTS] has been provided
         since 1988 for public users who need to synchronize computer
         clocks to the correct time to a Federally Provided timesource
         for security, audit, or just general synchronization purposes.

         In the current evolving EC aware landscape, the source of time
         used in best computing practices is more and more important to
         the overall dependability of the trust model. This document
         then, is filed for historical purposes on the already widely
         used, publicly available ACTS time service protocol. [AWTT]



      2.   Conventions used in this document
         The ACTS protocol uses an OOB timesetting model over a MODEM
         borne connection model. Because of this, the character format
         is stated as ASCII rather than UTF-8.

         As such, all values are represented as ASCII characters rather
         than binary or decimal values.


      Glassey        Informational 	 Expires Sep 1999         1

      <Draft-IETF-ACTS-00.txt>                         March, 99





      3.   ACTS
         The United States Government, in an effort to create better
         public technologies [AWTT], has been offering a wealth of
         technically credible time sources for public use for many
         years now [sp432].

         This suite of systems, as technology have evolved in stages to
         today include the internet and commercial timebase services.
         This draft then addresses the NIST Developed ACTS [ACTS]
         protocol and its use as the largest trusted timesetting
         protocol used to day.



      3.1 ACTS History
         The ACTS system was initially implemented by a collective of
         NIST Time and Frequency Staff members with the predominant
         codes bodies being written by Judah Levine [ACTS][AWTT]
         [SP432].

         ACTS represents a private circuit protocol for resetting a
         client timebase. It has the distinct advantage that it occurs
         over an out of band connection model and as such has different
         security issues to address than if it was sent over an open
         networking model, like NTP, one of its cousins.

         Using ACTS requires only a computer, a modem, and some simple
         software. When a computer connects to ACTS by telephone, it
         receives datagram represented as an ASCII time code token. The
         information in the time code token is extracted by the local
         client application and is then used to set the computer's
         clock.



      3.2 ACTS Today
         The current NIST ACTS system is deployed over a dialup network
         model and supports access at speeds up to 9600 baud with 8
         data bits, 1 stop bit, and no parity. The public telephone
         numbers for ACTS are (808) 335-4721 {Hawaii server} and (303)
         494-4774 {Colorado server}. ACTS is a very popular source of
         time.

         Because of latency in modems and the amount of data that can
         be sent in a timeframe relative to the baud rate, to receive
         the full time code token, you must connect at a speed of at
         least 1200 baud. The full time code is transmitted every
         second and contains more information than the 300 baud time
         code, which is transmitted every 2 seconds. The service, at



      Glassey        Informational 	 Expires September, 1999              2

      <Draft-IETF-ACTS-00.txt>                         March, 99


         the time of this writing, has 12 phone lines and receives
         about 10,000 telephone calls per day.



      4.   The ACTS Token and its Processing
         The ACTS Protocol is based primarily in the push-style
         exchange of an ACSII encoded, space delimited token. The token
         represents an exact instant in time, and provides offset and
         control information to the timesetting process as well.


      4.1 Current Operations Models
         Current ACTS implementations work in two process modes


      4.1.1 Fixed Delay Mode
         Fixed Delay Mode-In this mode, the user receives the time code
         and an on-time marker character. The marker character has been
         advanced in time by a fixed amount to compensate for typical
         modem and telephone line delays. Unless the connection is
         routed through a satellite, the accuracy in this mode should
         be better than 0.1 s.


      4.1.2 measured Delay Mode
         Measured Delay Mode-In this mode, the user's computer echoes
         all characters back to NIST where the round trip line delay is
         measured. The on-time marker character is then advanced to
         compensate for the line delay. The accuracy in this mode
         should be less than 10 ms using a 1200-Baud modem, or about 1
         ms using a 300-Baud modem. Accuracy at 1200 Baud is limited by
         the internal delays in 1200-Baud modems. Repeatability at both
         300 and 1200 Baud is about 1 ms.


      4.2 Token Structure
         The full ASCII time code token is structured as follows:

         <JJJJJ><sp><YRMODA><sp><HH:MM:SS><sp><TT><sp><L><sp><DUT1><sp>
         msADV><sp><UTC(NIST)><sp><OTM>

         where:

         <sp> is the ASCII Space Character used as the inter-field
         delimiter in the token body.


      4.2.1 Julian Date
         <JJJJJ> is the Modified Julian Date (MJD). MJD is represented
         as the last five digits of the Julian Date, which is the
         number of days since January 1, 4713 B.C. To derive the Julian
         Date from MJD, add 2.4 million to the MJD value.


      Glassey        Informational 	 Expires September, 1999              3

      <Draft-IETF-ACTS-00.txt>                         March, 99




      4.2.2 Actual Date Field
         <YRMODA> is the actual date field. It shows the last two
         digits of the year, the month, and the current day of month.
         There is no year 2000 issue with ACTS to address since ACTS
         servers retain no records of who called or when. Thus, the 2
         digit date field  representation is totally adequate.


      4.2.3 Current Projected Time Field
         <HH:MM:SS> is the current projected time in hours, minutes,
         and seconds. The time is always sent as Coordinated Universal
         Time (UTC). An offset  is always applied in the client
         application to UTC to obtain local time. For example, Mountain
         Time in the U. S. is 7 hours behind UTC during Standard Time,
         and 6 hours behind UTC during Daylight Saving Time.


      4.2.4 DST Selector Field
         <TT> is a two digit code (00 to 99) that is used to indicate
         whether the server is on Standard Time (ST) or Daylight Saving
         Time (DST) as per the United States Day/Year Model. It also
         indicates when ST or DST is approaching. This code is "00"
         when ST is in effect, or to "50" when DST is in effect.

         During the month in which the time change actually occurs,
         this number decrements every day until the change occurs. For
         example, during the month of October, the U.S. changes from
         DST to ST. On October 1, the number changes from 50 to the
         actual number of days until the time change. It will decrement
         by 1 every day, and reach 0 the day the change occurs.


      4.2.5 Leap Second Selection Field
         <L> is a one-digit code that is used to indicate whether a
         leap second will be added or subtracted at midnight on the
         last day of the current month. If the code is 0, no leap
         second will occur this month. If the code is 1, a positive
         leap second will be added at the end of the month. This means
         that the last minute of the month will contain 61 seconds
         instead of 60. If the code is 2, a second will be deleted on
         the last day of the month. Leap seconds occur at a rate of
         about one per year. They are used to correct for irregularity
         in the earth's rotation.


      4.2.6 Correction Factors
         <DUT1> is a correction factor used for converting UTC. It is
         always a number ranging from -0.8 to +0.8 seconds. This
         parameter is added to UTC to derive UT1. This parametric value
         is needed when converting to the older time representation


      Glassey        Informational 	 Expires September, 1999              4

      <Draft-IETF-ACTS-00.txt>                         March, 99


         forms and so is kept in the token to support legacy mode
         representation.




      4.2.7 Millisecond Offset Advance
         <msADV> is a five-digit code that displays the number of
         milliseconds that NIST advances the time code. <msADV> is
         initialized to 45.0 milliseconds but is reset to the actual
         delay of the circuit by returning the on-time marker (OTM)
         three consecutive times.


      4.2.8 Source Name Label
         The label UTC(NIST) indicates that you are receiving
         Coordinated Universal Time (UTC) from the National Institute
         of Standards and Technology (NIST).


      4.2.9 On Time Marker
         <OTM> (On-Time Marker) is the ASCII asterisk (*) character.
         The time value encapsulated in the token refers to the arrival
         time of the OTM. In other words, if the time code says it is
         12:45:45, this means it is 12:45:45 when the OTM event occurs.

         Since the <OTM> is delayed as it travels from NIST to your
         computer, the ACTS server sends it out 45 milliseconds early.
         This is intended to set the baseline offset latency over the
         Modem Channel connection model.


      4.2.9.1 Circuit Latency Processing
         The ACTS server has the ability to sense acknowledgement for
         use in steering the synch process. Better results are possible
         if the user's software returns the OTM to ACTS after it is
         received. Each time the <OTM> is returned, the ACTS Server
         measures the event latency and is divided by 2 to get the one-
         way path delay.

         The  ACTS Server then advances the <OTM> by the one-way path
         delay and the OTM changes from an asterisk to a pound sign
         (#). When the # sign appears, the time code is synchronized
         within a few milliseconds of UTC(NIST), depending on the
         client platform OS and facility.


      5.   Security Considerations

         NIST’s ACTS System offers computer operators an out of band
         mechanism from which to set their local timebase from that is
         represented by the US Federal Government as correct to the
         master civilian timebase.

      Glassey        Informational  Expires September, 1999              5

      <Draft-IETF-ACTS-00.txt>                         March, 99



         This facility, because it is OOB eliminates many of the
         pitfalls and security risks with open networking time data
         deployment and clock synchronization. As such, it offers a
         strong Best Computing Practices (BCP) timebase
         resynchronization method.



      6.   References

         [ACTS] ACTS Description Page on NIST's Time and frequency
         Website at http://www.boulder.nist.gov/timefreq/service/acts.htm                                                              
                                                             m

         [SP432] NIST Time and frequency Services on the NIST Website
         at http://www.boulder.nist.gov/timefreq/pubs/sp432/s_acts.html                                                                     
                                                                     m

         [AWTT] A Walk Through Time; A survey of NIST Time and
         frequency Services at http://physics.nist.gov/GenInt/boulder.html                                                  
                                                   l



      7.   Acknowledgments

         The initial version and the currently available servers for
         the ACTS facility all belong to NIST. The original protocol
         was written by Dr. Judah Levine (jlevine@boulder.nist.gov)                                           levine@boulder.nist.go
                                                                  
                                                                 v) and
         is mostly due to his efforts.  Michael Lombardi of NIST
         Boulder(lombardi@boulder.nist.gov) is also is a prime
         collaborator and produced the PCTime Clients.

         There are also many shareware and freeware ACTS clients available
	 today, see the ACTS info sites listed above or the NTP Home
         page at http://www.eecis.udel/edu/~ntp

         Dr Levine and his team at NIST Time and Frequency in Boulder
         are the holders of any IP rights that would come into question
         by the filing of this draft and any user of this technology
         should check with NIST for licensing issues.



      8.   Maintainers’ Address

         Again, this draft is filed for historical purposes only. The
         maintainer is not the originator of this technology and has no
         IP rights to it as such except as conveyed under the original
         use licenses form NIST.

         Todd Glassey
         GMTsw, Inc.

      Glassey        Informational 	 Expires September, 1999              6

      <Draft-IETF-ACTS-00.txt>                         March, 99


         PO Box 66301,
         Scotts Valley,
         Ca., 95067
         Phone: (831) 438-7811
         Email: Todd.Glassey@GMTsw.com



      9.   Full Copyright Statement

         "Copyright (C) The Internet Society Mar-99. All Rights
         Reserved. This document and translations of it may be copied
         and furnished to others, and derivative works that comment on
         or otherwise explain it or assist in its implementation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works. However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into"
_































      Glassey        Informational 	 Expires September, 1999              7