TICTOC Problem Statement <draft-bryant-tictoc-probstat-00.txt >

1. TICTOC Problem Statement<draft-bryant-tictoc-probstat-00.txt > TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com)

2. The Need for Time and Frequency • New applications and new network designs require accurate time and/or frequency • Accurate = ~50ppb frequency and 1-10us Time. • Transmitting time and/or frequency at these accuracies over a PSN • is a hard (but solvable) problem • is not addressed by any of the existing IETF WGs • We therefore propose the formation of a new working group to be called Timing(*) over IP Connections and Transfer of Clock (TICTOC). (*) Timing is "Telco speak" for the high quality frequency needed to make TDM networks function correctly

3. Applications • Need better time accuracy than commonly available from commonly available NTP (~10ms) • Range of industries: telecommunications, financial, test and measurement, government, industrial • High quality frequency requirement led by needs of mobile phone industry • Time needed by many industries – Networking, Test and Measurement, Industrial, Power etc • High accuracy time enables new applications • Distributed systems design would significantly benefit from the wide-scale availability of high quality time

4. Applications requirements (examples)

5. Infrastructure • Note that all of these applications are infrastructure applications. • The requirements are more strict than for most end user applications. • BUT there is greater flexibility in way that infrastructure can provide service to itself • Packet Rate • QoS • Client server pairings • Path selection • On-path operations • Algorithm choice are all factors that can be modified to enhance the quality of the time/frequency transfer.

6. Time and Frequency Transfer • Physical Layer – SONET/SDH and Synchronous Ethernet • Dedicated Network • Radio • Packet Networks Note that a high quality time source can be used to generate high quality frequency, and that whilst a frequency source cannot transfer time, a high quality frequency source cannot transfer time by itself, it can significantly enhance the quality of the time transferred by another means.

7. Synchronous Ethernet • Synchronous Ethernet – SDH frequency lock technology applied to the Ethernet physical layer • Replace 100ppm Ethernet clock with Stratum1 clock • Requires a contiguous SyncE path from clock source to client • NOTE – packet scheduling is NOT synchronous • Only transfers frequency – no time transfer protocol • But - high quality local frequency source provides a major improvement in time transfer • Next generation time transfer mechanism should therefore be designed to take advantage of SyncE if it is available.

8. DTI • Docsys Timing Interface designed to support the MAC interface in Docsys cable standard • Transfers time • Range approx 200’ over dedicated network • Capable of 5ns accuracy

9. Radio Time Transfer • GNSS (GPS) • Loran / eLORAN • High accuracy • Require antennas – but work underway on use with internal antennas • Coverage is limited • Reliability concerns • Failure rate • Subject to interference and jamming • Political issues with GPS (will be solved by Galileo) • Often need to supplement with local timing distribution

10. The Packet Network Environment • Packet delay variation, propagation asymmetry, and maximum permissible packet rate have a significant bearing on accuracy • PDV may be mitigated by TE • SP network better time service than arbitrary Internet hosts • Midbox techniques (IEEE 1588 type on-the-fly packet timestamp correction, or follow-up message mechanisms) correct/report the packet delays may improve quality • BUT require contiguous path support • AND have usual midbox issues • Packet rate influences quality of the time transfer - at a higher rate there is a better chance of extracting "good“ packets • In a controlled environment it is possible to ensure that • There is adequate bandwidth • The server is not overload • In such an environment the onus moves from protecting the server from overload, to ensuring that the server can satisfy the needs of all of the clients.

11. Existing Solutions • NTP • Existing NTP implementations do not meet the requirements for new applications • Update rate can not be scaled up sufficiently without a change to the protocol • Does not take advantage of hardware support • IEEE 1588v2 protocol • Largely designed around a well-controlled LAN environment • Needs hardware support to go get best performance • Some modes do not scale well • Needs a profile to support an IETF environment. • Synchronous Ethernet • Needs end to end contiguous path • Only transfers frequency • Not a time delivery solution, but may enhance one

12. Other Forums • NTP WG • PWE3 WG • IEEE 1588 task force • IEEE 802.1AS • ITU-T SG15 Question 13 Each forum has a different expertise set IETF has unique skills • distributed protocol design • security that complement those of the other organizations

13. Security • Time and frequency services are a significant element of network infrastructure - critical for emerging applications • Time and frequency transfer services MUST be protected from being compromised • The most significant threat is a false time or frequency server being accepted instead of a true one • Protection mechanism must be designed in such a way that it does not degrade the quality of the time transfer • Lightweight mechanism desirable, because: • client restrictions often dictate a low processing memory footprint • the server may have extensive fan-out

14. Congestion • Timing distribution is sensitive to packet delay and loss • Timing transfer packets should always be sent using the highest class of service, and when possible should be sent over a traffic engineered path • Depending on the quality of the client's clock and the required quality after disciplining, relatively high packet rates may be required • Under congestion conditions client may need to go into "holdover" mode (holdover requires expensive oscillators) • When the network goes into congestion special handling of time distribution packets may be required • Work performed by the IETF PWE3 WG on congestion may be applicable

15. Conclusion • This is an important problem area that the IETF needs to address. • Experimental evidence indicates that the solution is tractable (i.e. it is not research) • The IETF has a unique set of skills that are applicable to the problem space. • The IETF should form a WG with a goal of addessing the elements of the TICTOC solution in which it is uniquely skilled, and working with other SDOs in areas where they have core expertise.