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