[Federal Register Volume 79, Number 58 (Wednesday, March 26, 2014)]
[Notices]
[Pages 16772-16774]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2014-06683]


-----------------------------------------------------------------------

DEPARTMENT OF COMMERCE

National Institute of Standards and Technology

[Docket No.: 140305197-4197-01]


National Institute of Standards and Technology Internet Time 
Services

AGENCY: National Institute of Standards and Technology (NIST), 
Department of Commerce.

ACTION: Request for information.

-----------------------------------------------------------------------

SUMMARY: The National Institute of Standards and Technology (NIST) 
seeks information from the public on NIST's potential transition of 
time services from a NIST-only service to private sector operation of 
an ensemble of time servers that will provide NIST-traceable time 
information in a number of different formats over the public Internet.

DATES: Comments are due on or before 11:59 p.m. Eastern Time on May 27, 
2014.

ADDRESSES: Comments will be accepted by email only. Comments must be 
sent to [email protected] with the subject line ``Internet Time 
Service Comments.''
    Comments submitted after the due date may not be considered.
    All comments will be made publicly available on http://tf.nist.gov 
as submitted. Accordingly, proprietary or confidential information 
should not be included in any comments, as they will be posted without 
change.

FOR FURTHER INFORMATION CONTACT: Thomas O'Brian; 303-497-4570; 
[email protected].

SUPPLEMENTARY INFORMATION: 
    Pursuant to 15 U.S.C. 261(b), the Secretary of Commerce, in 
coordination with the Secretary of the Navy, is responsible for 
maintaining and interpreting Coordinated Universal Time (UTC) as 
official time for the United States. UTC is the time scale

[[Page 16773]]

maintained through the General Conference on Weights and Measures. The 
Secretary of Commerce has delegated authority for maintaining and 
interpreting UTC to the Director of the NIST. The NIST version of UTC 
is designated as UTC(NIST).
    To facilitate broad access to UTC(NIST), the Time and Frequency 
Division of the NIST Physical Measurement Laboratory currently operates 
an ensemble of time servers, which are located at a number of sites in 
the continental U.S. (A list of the current locations is on the 
Internet Time Service page at http://tf.nist.gov/tf-cgi/servers.cgi.) 
The servers are connected to the public Internet and respond to 
requests for time in three formats: Network Time Protocol (NTP), the 
DAYTIME format and the TIME format.
    The generally accepted voluntary standards, containing detailed 
descriptions, for these three time formats is set forth in a series of 
Request for Comment (RFC) documents from the Internet Engineering Task 
Force (IETF). These RFCs can be accessed through the IETF Web site: 
http://www.rfc-editor.org/rfc-index.html:
    NTP format: RFC 1305 http://www.rfc-editor.org/rfc/rfc1305.txt.
    DAYTIME format: RFC 867 http://www.rfc-editor.org/rfc/rfc867.txt.
    TIME format: RFC 868 http://www.rfc-editor.org/rfc/rfc868.txt.
    Higher level summaries of these time formats are available at the 
NIST Internet Time Service Web site: http://www.nist.gov/pml/div688/grp40/its.cfm.
    The servers are synchronized to UTC as maintained by an ensemble of 
atomic clocks at the NIST Boulder Laboratories. This time is generally 
referred to as UTC(NIST) to distinguish it from UTC, a paper time scale 
computed periodically by the International Bureau of Weights and 
Measures (the BIPM). The UTC(NIST) time scale is steered towards UTC 
using occasional adjustments in frequency, and the difference is 
typically on the order of a few nanoseconds.
    The ensemble also includes three time servers that are synchronized 
to UTC(NIST) and that support only the authenticated version of NTP 
using the symmetric-key method and the Message Digest 5 (MD5) hash 
algorithm. The authenticated service is limited to users who register 
with NIST and receive a unique key that is linked to their network 
address. The key is used to authenticate the time packets from NIST by 
means of the MD5 hash method as described in the RFC documents 
referenced above.
    The servers also support anonymous read-only connections that use 
the File Transfer Protocol (FTP), which allow users to download example 
software, ``read me'' files and similar documents. The FTP service also 
allows users to download a list of leap seconds, including future leap 
seconds that have been announced but have not yet occurred.
    The ensemble of servers receives approximately 6.5 billion time 
requests per day, or about 75,000 requests per second. Approximately 
85% of these requests are for time in the NTP format, and the balance 
are about equally divided between the DAYTIME and TIME formats. The 
number of simultaneous FTP connections is not closely monitored, but, 
based on occasional random sampling, there are approximately 1000 
simultaneous FTP connections at any time.
    NIST is considering transitioning the provision of its time 
services from a NIST-only service to private sector operation of an 
ensemble of time servers that will provide NIST-traceable time 
information to improve provision of these services, and hereby requests 
information on how best to realize this transition so as to assure the 
continued integrity, availability, and accuracy of the time messages. 
NIST views the transition as a means of broadening the availability of 
the NIST time-scale data and fostering the creation of new time 
services and layered products that could make use of that data. At the 
same time, NIST seeks to ensure that the time messages provided by the 
servers are as accurate as possible, consistent with the technical 
limitations of the public Internet. This requirement is especially 
important for current (and prospective) financial and commercial users 
of the service, many of whom are legally required to ensure that the 
time stamps that they use in their data centers are traceable to the 
national standard time as maintained at NIST. NIST will work with 
private sector operator(s) to ensure that these legal traceability 
requirements are satisfied.
    The goals of the time service are:
    a. Respond to requests for time in a number of network-standard 
formats. The accuracy of the time at the server should be significantly 
better than 0.01 millisecond (0.00001 s), to support both current 
applications and enable near-term future enhancements. A number of 
existing users of the NIST services have already expressed the need for 
time data with an accuracy approaching 1 microsecond, and the system 
should be designed to provide this level of service in the future 
without significant modification. The accuracy received by a user 
depends on the stability of the network delay and is usually not under 
the control of the server. However, improvements in the stability of 
the network delays are already available in principle, and it is likely 
that these improvements will enable support for greater accuracy of the 
time service in the not too distant future, possibly using formats that 
are not currently supported by the NIST service.
    b. Provide geographical diversity in the location of the time 
servers. This goal seeks to minimize the impact of a single network 
failure or the failure of the hardware at any site. In addition, 
geographical diversity generally provides better accuracy by reducing 
the network delay for a larger number of users.
    c. Provide a local reference time scale at each server that can 
support the full accuracy of the time service for a minimum of 180 
days, even if the link to the NIST time scale is lost. The local 
reference scale should have redundant components and be designed with 
no single point of failure. This ``hold-over'' capability is 
particularly important if the links between the servers and NIST are 
realized by means of signals from satellites such as the signals from 
the Global Positioning System, even if the signals are used in common-
view. (The common-view method, in which several stations receive the 
signals from the same satellite at the same time, reduces, but does not 
eliminate the sensitivity of the synchronization process to errors in 
the data and time signals transmitted by the satellites.) The signals 
from navigation satellites are increasingly degraded by jamming and 
spoofing, and these problems are becoming more common, so that a simple 
reliance on these signals (without a local very stable reference clock) 
is not adequately robust for a national time service.
    d. Provide links between each server location and the NIST atomic 
clock ensemble that supports the accuracy of the time service as 
outlined in paragraph a., and is as robust as possible. The accuracy of 
the link and the accuracy of the local time reference discussed in the 
previous paragraph will probably be designed together, with the result 
that the combination is more robust than either component alone would 
be.
    e. Provide network bandwidth and connectivity that can support the 
current number of requests with a significant margin for future growth. 
The messages used to exchange timing information are small--100 octets 
or less--but there are a large number of them, so that the load on the 
network elements, which typically must process every request 
independent of its size, is larger than a simple estimate based on

[[Page 16774]]

the number of octets in each request multiplied by the number of 
requests. In addition, the accuracy and stability of the time service 
depends on (and is usually limited by) the stability of the network 
delay, and this delay tends to become less stable and predictable once 
the message traffic becomes a significant fraction of the bandwidth of 
the hardware.
    f. Provide adequate physical security, environmental controls, 
backup power, and related service consistent with the critical 
contribution of the time servers to the national infrastructure.
    g. The time servers do not contain or transmit any confidential 
information. There is no Personally Identifiable Information (PII) 
associated with the services, and both the time messages themselves and 
the files that are provided for download are freely available and are 
based on principles and practices that have been widely disseminated. 
The requirements of paragraph f. are intended only to prevent 
alteration or destruction of the data.
    h. The system should provide adequate internal and external 
monitoring to ensure the integrity of the time messages. Both the NTP 
and the DAYTIME format should include bits that specify the health of 
the server, and these bits should be used to indicate that the time 
transmitted in the message was transmitted from a server whose time 
accuracy was known to be incorrect or when the accuracy could not be 
established. These bits should be set if an internal or external 
monitoring program detects a problem and not reset until the normal 
state is restored. Conversely, when the bits of the message are not 
set, this shall indicate that the server is operating normally based on 
a combination of internal and external checks. (Some implementations of 
the NTP do not use this capability and push the detection of a failed 
server into the application software running on the client system. This 
method is not adequate and is not acceptable for a service traceable to 
a national timing laboratory.) The NTP and DAYTIME formats also have 
parameters in the message that can be used to indicate that the server 
is operating at reduced accuracy. Depending on these parameters as the 
sole means for indicating the health of the service is discouraged, 
since they are usually based on statistical estimators that may or may 
not be an accurate description of the true state of affairs. The terms 
of service between NIST and any future service provider shall clearly 
specify that any implication of accuracy or traceability to national 
standards is suspended when any of these indicators is set. The TIME 
format does not have any way of transmitting the health of the server, 
and the server shall not respond to a request for time in this format 
if it is known or suspected of being unhealthy.
    i. The time servers shall transmit time signals based on UTC(NIST) 
and shall support insertion of leap seconds as defined and implemented 
by the International Telecommunications Union (ITU), the International 
Earth Rotation Service (IERS), and the International Bureau of Weights 
and Measures (BIPM).
    j. In addition to implementing leap seconds in the time messages as 
described in paragraph i., the servers shall provide advance notice of 
leap seconds as specified in the documentation for the NTP and DAYTIME 
formats.
    k. The time service is currently used by many users who are not 
expert in time and frequency principles or in the design of the network 
services that are used to communicate between the server and the 
hardware of the end-user. Therefore, the operator(s) should support a 
``help desk'' facility to assist users who are having difficulty in 
using the services.
    Request For Information: The objective of this request for 
information is to assist NIST in determining the best ways to structure 
possible private sector provision of Internet Time Service. Based on 
the information provided, NIST may or may not issue a request for 
proposals or other announcement of an opportunity for such private 
sector provision of Internet Time Service. In this connection, the 
questions below are intended to assist in the formulation of comments 
and should not be construed as a limitation on the number of comments 
that interested persons may submit or as a limitation on the issues 
that may be addressed in such comments. Comments containing references, 
studies, research, and other empirical data that are not widely 
published should include copies of the referenced materials. Again, 
note that all comments will be made publicly available as submitted; 
therefore proprietary or confidential information should not be 
included. NIST is specifically interested in receiving input pertaining 
to one or more of the following questions:
    1. What diversity of the geographical locations of the servers will 
provide the best balance between cost and accuracy consistent with the 
requirements outlined above?
    2. How should the sites be configured to provide the integrity, 
reliability, and accuracy that are required as part of a time service 
that must support the national infrastructure?
    3. How should the monitoring and supervisory functions be 
configured to ensure that the time signals are accurate and that any 
failure be detected? In addition, how should logging functions be 
implemented so that the log files can be used in the case that the 
accuracy of the time signals become involved in a legal proceeding?
    4. How should the link to the NIST atomic time scale be realized? 
What is the appropriate relationship between NIST and time service 
provider(s)? How should this relationship be designed to preserve the 
requirements of legal and technical traceability of the time stamps to 
national time standards?
    5. What are ways in which the relationship between the private 
operator(s) and NIST can best be realized? A formal agreement will be 
established between NIST and each private operator, and NIST seeks 
input on what type of agreement would best support the program.
    6. Should NIST hold a competition to select a private sector 
organization(s) to operate an ensemble of time servers to provide NIST-
traceable time information, or should NIST make the opportunity 
available to all eligible parties?
    7. What are advantages and disadvantages of NIST's potential 
transition of time services from a NIST-only service to private sector 
operation of an ensemble of time servers that will provide NIST-
traceable time information via the Internet? Note that NIST would 
continue to provide oversight of the accuracy and integrity of the 
Internet-based time services, and that the transition would not affect 
the traceability of the distributed time signals to national and 
international standards.
    8. What other considerations should be important in the design of 
the time services?

    Dated: March 20, 2014.
Willie E. May,
Associate Director for Laboratory Programs.
[FR Doc. 2014-06683 Filed 3-25-14; 8:45 am]
BILLING CODE 3510-13-P