15
TICTOC Problem Statement <draft-bryant-tictoc-probstat- 00.txt > TICTOC BOF IETF68 Stewart Bryant ([email protected]) Yaakov (J) Stein ([email protected])

TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant ([email protected]) Yaakov (J) Stein ([email protected] )

Embed Size (px)

Citation preview

Page 1: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

TICTOC BOF IETF68

Stewart Bryant ([email protected])

Yaakov (J) Stein ([email protected])

Page 2: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 3: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 4: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

Applications requirements (examples)Synchronization service

Application Expected 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 purposeEx: legacy PBX, local time source, AVB master…

System specific time (phase)

802.16(D/)E Depends on: mode, modulation, application, implementation and option usedStrongest 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 SFN TBD

3GPP MBMS/LTE

Cell synchronization accuracy better than or equal to 3µs for SFN supportDifferent options under study; one is to get precise time from network

Global time (Time-of-Day)

3GPP MBMS/LTE

MBMS Content synchronization - TBD

IP SLAOne-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. ~ 10-100µs)

Power distribution

Correlation of output of disperse synchrophasors Measurement requires a source of UTC time accurate to 1 µs

Page 5: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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.

Page 6: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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.

Page 7: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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.

Page 8: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 9: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 10: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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.

Page 11: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 12: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 13: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 14: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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

Page 15: TICTOC Problem Statement TICTOC BOF IETF68 Stewart Bryant (stbryant@cisco.com) Yaakov (J) Stein (yaakov_s@rad.com )

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.