1 / 15

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

This document proposes the formation of a new working group, TICTOC, to address the need for accurate time and frequency transfer in new applications and network designs. It highlights the requirement for high-quality time accuracy in various industries and discusses existing solutions and their limitations.

terrelly
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related