1. IETF TICTOC Considerations about IEEE1588 version 2 for Telecom usage

2. About IEEE1588v2 Telecom Profiles Interest in IEEE1588v2 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 v2 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 IEEE1588v2 Profile would not be sufficient. Some PTPv2 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 PTPv2 (or NTPv4).

3. 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 (E2E or P2P) Measure Residence Time (i.e. delay of Event messages passing through the TC equipment). P2P TC also measures round-trip time of its IEEE1588-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 Unicast addressing is an option in PTPv2 – 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.

4. 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. IEEE1588-capable equipments may have to support more complex encapsulations than just IP over Ethernet (or MPLS over Ethernet). Ethernet PW, IEEE802.1ah, MPLS VPN/TE/FRR, GMPLS… High-speed HW timestamping Need to consider 10G links and above Software, driver or hardware timestamping http://www.eecis.udel.edu/~mills/stamp.html Also about non reciprocal rates and paths

5. 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 IEEE1588 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 3rd party network provide a high quality time synchronization service. Or the 3rd party network provides TC function but what about non reciprocal rates and paths (and syntonization).

6. 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. 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)

7. Transparent clocks – 2/3 Two-step TC measures Slave-Master RT from Delay_Req event message and modifies the correctionField 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.Dont 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 IEEE1588-capable equipments running either GM, TC, or BC function; but this forces every intermediate equipment to be IEEE1588-capable.

8. 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 correctionField in Follow_Up message. IEEE1588-capable equipment must intercept, read and modify the PTP packet (i.e. not just switch it). E.g. with RFC 1812 if IPv4 router. Utilization in multi-entity design? Domains? Syntonization? Delay_Req/Resp paths? Scalability? Guarantee of the RT measurement? Security? Management?

9. Summary IEEE1588 version 2 introduces a set of functions that can be useful for high quality time transfer. Specific utilizations of PTPv2 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 IEEE1588 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.