Transcript tictoc-2 - Internet Engineering Task Force

IETF TICTOC
Considerations about
IEEE1588 version 2
for Telecom usage
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).
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.
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
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).
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)
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. Don’t use Delay_Resp message to carry the Residence Times of the TCs on the Slaveto-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.
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?
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.