TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant Yaakov (J) Stein )

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

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

Applications requirements (examples) Synchronization service ApplicationExpected quality Frequency TDM transition & co-existence PRS-traceability (i.e. reference signal from Stratum1 / G.811 in normal situation)  Copying SONET/SDH synchronization architecture 3GPP/2 Base Stations Frequency assignment shall be less than ± 5x10 -8 (± 0.05 ppm)  Specified for air interface not for BS network interface Enterprise, Residential High quality frequency source for internal purpose Ex: legacy PBX, local time source, AVB master… System specific time (phase) (D/)E Depends on: mode, modulation, application, implementation and option used Strongest needs for optimized radio frequency utilization, mobility and HO/Fast BS switching and MBS options 3GPP2 CDMA Base Stations Frequency assignment shall be less than ± 5x10 -8 (like 3GPP) Time alignment error should be less than 3 μs and shall be less than 10 μs DVB-T/H SFNTBD 3GPP MBMS/LTE Cell synchronization accuracy better than or equal to 3µs for SFN support Different options under study; one is to get precise time from network Global time (Time- of-Day) 3GPP MBMS/LTE MBMS Content synchronization - TBD IP SLA One-way delay Improve precision to < 1 ms (within 10 ms class today) Ideally target precision in few orders of magnitude below average delay (i.e. ~ µs) Power distribution Correlation of output of disperse synchrophasors Measurement requires a source of UTC time accurate to 1 µs

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.

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.

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.

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

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

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.

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

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

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

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

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.