SPECIAL NOTICE
B -- Request for Information Internet Time Service Comments
- Notice Date
- 3/18/2014
- Notice Type
- Special Notice
- NAICS
- 541990
— All Other Professional, Scientific, and Technical Services
- Contracting Office
- Department of Commerce, National Institute of Standards and Technology (NIST), Acquisition Management Division, 100 Bureau Drive, Building 301, Room B130, Gaithersburg, Maryland, 20899-1410, United States
- ZIP Code
- 20899-1410
- Solicitation Number
- RFI_InternetTimeServiceComments
- Archive Date
- 6/2/2014
- Point of Contact
- Thomas O'Brian, Phone: 303-497-4570
- E-Mail Address
-
thomas.obrian@nist.gov
(thomas.obrian@nist.gov)
- Small Business Set-Aside
- N/A
- Description
- SUMMARY: National Institute of Standards and Technology (NIST), Department of Commerce, 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. ADDRESSES: Comments will be accepted by e-mail only. Comments must be sent to thomas.obrian@nist.gov 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; thomas.obrian@nist.gov 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 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 website: 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 website: 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 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?
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/DOC/NIST/AcAsD/RFI_InternetTimeServiceComments/listing.html)
- Record
- SN03313872-W 20140320/140318235229-4f5c8b176af03d89abb1a318624c944b (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |