TICTOC K. Lindqvist Internet-Draft Netnod Intended status: Standards Track P. Lothberg Expires: September 11, 2008 STUPI March 10, 2008 Requirements for a next generation Internet Time Protocol draft-kurtis-tictoc-itp-req-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 11, 2008. Abstract Providing timing services over an IP network, known as wall-clock, has traditionally been done with the Network Time Protocol, NTP. The current version of NTP, version 4, has been in existence for a long time, but only recently been adopted as an IETF Standard. In the mean time however, the requirements for higher precision of wall- clock services over IP networks has grown. This document outlines some of the requirements of wall-clock services that is not provided by NTPv4, and is intended to serve as a gap analysis. Lindqvist & Lothberg Expires September 11, 2008 [Page 1] Internet-Draft Internet Time Protocol Requirements March 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Backward compatibility . . . . . . . . . . . . . . . . . . . . 3 4. New Packet format . . . . . . . . . . . . . . . . . . . . . . 3 5. Network topology dependencies . . . . . . . . . . . . . . . . 3 6. Resource management . . . . . . . . . . . . . . . . . . . . . 4 7. Secure identification of time source . . . . . . . . . . . . . 4 8. Size of time errors . . . . . . . . . . . . . . . . . . . . . 4 9. Time scale . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9.1. Concerns for picking a time scale . . . . . . . . . . . . 5 10. Event Flag (Leap seconds) . . . . . . . . . . . . . . . . . . 6 11. External data dependencies . . . . . . . . . . . . . . . . . . 6 12. ITP host API . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.1. ITP to OS . . . . . . . . . . . . . . . . . . . . . . . . 7 12.2. OS to application . . . . . . . . . . . . . . . . . . . . 7 13. Wire protocol and algorithms . . . . . . . . . . . . . . . . . 8 14. Resolution requirements . . . . . . . . . . . . . . . . . . . 8 15. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 16. Security considerations . . . . . . . . . . . . . . . . . . . 8 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 18. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Lindqvist & Lothberg Expires September 11, 2008 [Page 2] Internet-Draft Internet Time Protocol Requirements March 2008 1. Introduction As the requirements on providing a high precision wall-clock service has grown, there has been increased talk about a next generation wall-clock protocol. The IETF decided early on not to modify NTPv4, but to document what was in existence. Instead the IETF has focused new efforts for time and frequency distribution over IP networks to a new working-group, TICTOC. This document does not try and preempt the outcome of the TICTOC discussions, and therefor refer to a new timing protocol simply as the "Internet Time Protocol", ITP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]RFC2119. 3. Backward compatibility In a future ITP it is important that the client MUST be able to always ask for the correct time from a server. This even if it does not understand all additions made in ITP. I.e, an ITP capable server MUST reply with a NTPv4 reply to a NTPv4 query. 4. New Packet format In an ITP protocol, the packet format MUST be structured around an TLV encoding in order to remain extensible. 5. Network topology dependencies Provide the best possible time transfer over arbitrary networks between clients and servers. (Target: average better than 1ms) ITP MUST work over the Internet in general, and MUST work with the same precision over general IP networks. I.e that is over all link layers that have a defined "IP over FooBar" encapsulation format defined. Work on ITP should as required and if possible be done on mappings for time and frequency over lower-layers than IP. Lindqvist & Lothberg Expires September 11, 2008 [Page 3] Internet-Draft Internet Time Protocol Requirements March 2008 Future work items would be to describe mapping of ITP packets into hardware supported transport. ITP SHOULD be designed in such a way that when appropriate HW support is available, the protocol should be capable of picosecond or better time transfers. ITP MUST also be based on the assumption that there is a differentiation between the packet format and the algorithm used. One could then further assume that ITP will have a default algorithm for the protocol and that should be designed to meet the low packet rate. Other (perhaps future) algorithms may use other packet rates. ITP should work towards as high precision as possible with as few packets as possible. However, higher accuracy could be achieved with higher packets rates. 6. Resource management The ITP server must be able to provide guidelines to the client on how to achieve the highest precision. In other words, if bandwidth is starved all clients would benefit from a back-off to free up resources and get a reply. A heavily loaded server SHOULD be able to communicate to the clients that they will get higher precision of they back of their query rate. 7. Secure identification of time source ITP MUST be able to support secure identification of a time source, such as a UTC(k). The ITP protocol must also be able to authenticate the reference time. The authentication certificate will be sent upon client request or by the server to client. Secure transfer client-server-client without (too much) server state. 8. Size of time errors The ITP protocol MUST identify the size of time errors between UTC(k) and server. Precision on the time transfer. Upon request from the client. Lindqvist & Lothberg Expires September 11, 2008 [Page 4] Internet-Draft Internet Time Protocol Requirements March 2008 9. Time scale ITP uses a single timescale but should support a local timescale by signaling in the response to the client that there is additional information used. The reasoning behind this construct is that a client should be able to retrieve actual time in a single packet exchange with the server. The server however, needs a mechanism to tell the client that additional information would be needed in order for the client to process the data correctly (if that is indeed the case). The additional information could also be "additional" information, i.e information that the server is aware of, but that won't affect the interpretation of the timescale in question. The server will need a mechanism to distinguish between these two types of additional available information. This data for any specific application can for example be a offset and rate of change of the offset. The client will request for the additional data upon receipt of the flagged answer. The ITP timescale will either be UTC with correct handling of leap seconds or a timescale that do not have leap seconds GNSS-time or TAI. If a timescale other than UTC is chosen, the ITP server has to be capable of providing the offset to UTC. 9.1. Concerns for picking a time scale At the time of writing, there are really only hree time scales of importance for ITP, TAI, UTC and GPS time. GPS time is of course really a realization of TAI but with the 19 second UTC offset present when the GPS scale was started. As for TAI, since 1972, UTC and TAI have just differed by integer steps. It's worth observing that most users of precise time really want syntonization, not synchronization, so they don't really care about leap seconds, except as a nuisance that must be dealt with from time to time. (GPS time is an excellent example; they care very much about being on Atomic Time, but not at all about the 19 seconds.) So it seems there are really only 4 choices when it comes to which time scale to base ITP on 1. Ignore time scales. We will make the clients follow whatever the master says. Effectively, this would mean that the clocks would be mostly set to UTC, but large offsets (seconds, hours, even days) would be possible. Time transfers on an isolated network Lindqvist & Lothberg Expires September 11, 2008 [Page 5] Internet-Draft Internet Time Protocol Requirements March 2008 would be no trouble with this choice, but if the master clock had a leap second, time interpolation may have problems. 2. Adopt TAI. This seems attractive, but really most clocks don't keep TAI, so it would mean either that every time transfer would have to have a leap second conversion or we would have to set up a world wide set of NTP like servers with TAI. It also might cause difficulties if you want to do time transfers on an isolated network. (The same is true for GPS time, which really has no reason to recommend it.) 3. Adopt UTC. This is the NTP solution, but with a flag to allow for good interpolation / smoothing over leap seconds. 4. Adopt the full catastrophe. Display UTC, use TAI for any interpolation / smoothing. Realistically this means you need tiers or classes of service. Class 1 would be with leap seconds, i.e., with outside information, Class 2 would be for isolated networks, and would thus mean that you are close to UTC at the start, but may have second level offsets over time. The optimal choice will depend on the likely users. Metrology people tend to view ITP as something they provide, not something they use, so they don't care too much that it doesn't provide TAI. If you think that TICTOC can get to the sub-microsecond level where the metrology people would use it, the best picks seems to be either choice # 4. As the TICTOC WG should strive for an agnostic use approach, as well as high-quality this is the recommended pick. 10. Event Flag (Leap seconds) In the ITP protocol, the server MUST be capable of setting a flag telling the client that there is more information for the client about an event. The client will then start an exchange to follow up what the event is. This mechanism could be used to signal for example leap seconds. All the special events MUST have a TTL to reduce traffic. 11. External data dependencies ITP should require no external data (other sources of information) to determine the correct time and date in ITP format other than making one or more queries to a single ITP server. (No wrap-around problems.) Lindqvist & Lothberg Expires September 11, 2008 [Page 6] Internet-Draft Internet Time Protocol Requirements March 2008 This would make the client capable of telling time in the ITP timescale and UTC (if they are not the same). If "local time" (offset from UTC) is needed, this has to be provided by the client. (This might be a DHCP thing?) 12. ITP host API 12.1. ITP to OS ITP MUST include a standardized API for ITP and time of day sources to the OS. Functions that are required are : o Frequency steering of local clock o Phase offset for local clock o Time Step/Set of local clock o Handling of Leap Seconds o ITP to UTC offset (if applicable) o Clock source quality parameters 12.2. OS to application Similar to above, an ITP API should also include a standardized API for time of day functions. Required functions are o Time of day o Offset rate of change o 2:nd derivata of change o Administrative offset from UTC for geographic timezone and daylight savings o Clock quality Lindqvist & Lothberg Expires September 11, 2008 [Page 7] Internet-Draft Internet Time Protocol Requirements March 2008 13. Wire protocol and algorithms In ITP, the wire protocol and algorithms MUST be separated. One algorithm for basic time of day transfer MUST be available in all implementations. 14. Resolution requirements ITP wire format to support 0.1 pico second resolution in the packet format. 15. IANA considerations This document does not "yet" have any IANA considerations. 16. Security considerations There are several issues with security and distribution of time over the Internet. Some of these are described above and can be expected to be fleshed out over time and the life of this document. 17. Acknowledgements The authors would like to thank Marshall Eubanks for contributing to this document. 18. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Lindqvist & Lothberg Expires September 11, 2008 [Page 8] Internet-Draft Internet Time Protocol Requirements March 2008 Authors' Addresses Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 Stockholm S-118 47 Sweden Phone: +46 708 30 60 01 Email: kurtis@kurtis.pp.se URI: http://www.kurtis.pp.se Peter Lothberg STUPI Stockholm Sweden Phone: Email: roll@stupi.se URI: http://www.stupi.se Lindqvist & Lothberg Expires September 11, 2008 [Page 9] Internet-Draft Internet Time Protocol Requirements March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Lindqvist & Lothberg Expires September 11, 2008 [Page 10]