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]