Network Working Group Glasey.Todd Internet Draft GMTsw Document: 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 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 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: msADV> where: is the ASCII Space Character used as the inter-field delimiter in the token body. 4.2.1 Julian Date 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 March, 99 4.2.2 Actual Date Field 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 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 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 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 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 March, 99 forms and so is kept in the token to support legacy mode representation. 4.2.7 Millisecond Offset Advance is a five-digit code that displays the number of milliseconds that NIST advances the time code. 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 (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 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 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 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 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 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