IETF TICTOC Considerations about IEEE 1588 version 2

IETF TICTOC Considerations about IEEE 1588 version 2 for Telecom usage

About IEEE 1588 v 2 Telecom Profiles • • Interest in IEEE 1588 v 2 for telecom is driven by mobile wireless market. Two demands are driven by wireless base stations. Frequency transfer is a first, short term, demand (phase 1). Sub-microsecond time (relative, a. k. a. phase) synchronization is the second. • PTP v 2 is considered for supporting those demands thru profiles. Because current NTP does not provide the same level of expectation. • PTP version 2 enhances version 1 and brings useful new capabilities. Few features have been added for telecom purpose. Note: PTP version 1 should not be considered for telecom. • However defining a “Telecom IEEE 1588 v 2 Profile” would not be sufficient. Some PTPv 2 behaviors may not suit telecom (WAN) requirement for high quality (< µs) time/phase sync. • One needs to review the network time transfer method. Either by narrowing network designs for specific requirements (not an IETF goal), Or by extending features to make it more flexible with risk to break current PTPv 2 (or NTPv 4).

Key protocol aspects • Different types of clocks: GM, BC, TC, OC Between GM and OCs, BC and TC can be mixed to achieve required time performance. Use of BC or TC is not mandatory but impacts network design and performance. • Transparent Clocks (E 2 E or P 2 P) Measure Residence Time (i. e. delay of Event messages passing through the TC equipment). P 2 P TC also measures round-trip time of its IEEE 1588 -enabled links. • Hardware timestamping at the physical interface (ingress and/or egress) Clocks (GM, BC, TC, OC) should implement HW-assisted timestamping for best results. • One-step and two-step clock models Two-step clock model adds Follow_Up message to Sync message. Two-step clock model impacts the way Delay_Req / Delay_Resp messages are handled. • Multicast vs. Unicast addressing is an option in PTPv 2 – this is a “telecom” feature aimed to prevent flooding individual slave Delay_Req. Multicast can be limited to link. • Stateful protocol Master clock (grandmaster or boundary clock) and transparent clock must maintain state for every slave.

General items to consider – 1/2 • Unicast addressing is considered the most efficient transmission method wrt PTP in telecom network. This increases the traffic generation from master (grandmaster or boundary) clocks depending on number of slave clocks (boundary or ordinary) and required message rates. This increases the traffic handled by transparent clocks. • Hardware timestamping scalability with unicast traffic. Master (grandmaster or boundary) clock hardware timestamping must be scalable to support all traffic from/to slave clocks. Transparent Clock hardware timestamping must be scalable to support traffic from all slave clocks. • Hardware timestamping flexibility. IEEE 1588 -capable equipments may have to support more complex encapsulations than just IP over Ethernet (or MPLS over Ethernet). Ethernet PW, IEEE 802. 1 ah, MPLS VPN/TE/FRR, GMPLS… • High-speed HW timestamping Need to consider 10 G links and above • Software, driver or hardware timestamping http: //www. eecis. udel. edu/~mills/stamp. html Also about non reciprocal rates and paths

General items to consider – 2/2 • One-step model violates the network layer model. One-step clock interface modifies the packet payload at PHY/MAC layer. This forces using the two-step model this drives to TC issues. • Use Transparent Clocks and/or Boundary Clocks Chain of BCs will degrade the time transfer quality: need to narrow the degradation. TC should limit degradation but has a set of caveats: cf. next slides. Using both alternately and adequately may overcome their own individual issues. Incomplete on-path support (i. e. non-capable IEEE 1588 equipment) would probably degrade the recovered time quality. • Multiple domains When master and slave are separated by third party network (e. g. wholesale operator) what can/must this network do? Ways to handle this situation: • Either the 3 rd party network provide a high quality time synchronization service. • Or the 3 rd party network provides TC function but what about non reciprocal rates and paths (and syntonization).

Transparent clocks – 1/3 • TCs must keep state for Sync / Follow_Up messages Delay_Req / Delay_Resp messages • Two-step TCs operating at relatively high Sync rates may delay Follow_Up message N for Sync message N may arrive at the slave after message Sync N+d has arrived Several ways to handle this issue: 1. TC waits for the Follow_Up message to arrive before switching the Sync message downstream – increase memory requirement – strict scheduling of Sync + Follow_Up of specific Master-Slave session 2. Small buffer at slave to record the arrival time of the last K sync messages 3. PHY-based syntonization (because high rate Sync message helps improving frequency slave synchronization)

Transparent clocks – 2/3 • Two-step TC measures Slave-Master RT from Delay_Req event message and modifies the correction. Field of the associated Delay_Resp general message. This raises two caveats: 1. TC needs to maintain state for every Delay_Req per slave-master peer Note: this is low rate traffic (per slave). 2. Delay_Req / Delay_Resp paths must be congruent. • TC must be in the path of associated Delay_Req and Delay_Resp messages. Possible ways to handle this issue: 1. Traffic engineer the bi-directional path. 2. Don’t use Delay_Resp message to carry the Residence Times of the TCs on the Slave-to -Master path; but use distinct Delay_Resp per TC. 3. Use link multicast between IEEE 1588 -capable equipments running either GM, TC, or BC function; but this forces every intermediate equipment to be IEEE 1588 -capable.

Transparent clocks – 3/3 • Two-step TC has to modify/generate the Follow_Up message. After measuring the RT, the TC equipment must update the correction. Field in Follow_Up message. IEEE 1588 -capable equipment must intercept, read and modify the PTP packet (i. e. not just switch it). E. g. with RFC 1812 if IPv 4 router. • Utilization in multi-entity design? Domains? Syntonization? Delay_Req/Resp paths? Scalability? Guarantee of the RT measurement? Security? Management?

Summary • • • IEEE 1588 version 2 introduces a set of functions that can be useful for high quality time transfer. Specific utilizations of PTPv 2 in so called “telecom profiles” would limit their scope to specific network designs and implementations. This means this would not help making a protocol more broadly applicable to telecom networks and Internet. Latest threads on NTP mailing list show that NTP can be modified to leverage some of the functions IEEE 1588 introduces. However the NTP discussion focuses on peers leaving out the intermediate network equipments. For tightest time requirements, any time protocol will have to rely on intermediate equipments with hardware assistance and will have to be modified accordingly.