Slides presented during the 2010 WIGOWIN Workshop at the Department of Computer Science in Pisa - May 26. Full paper available at http://eprints.adm.unipi.it

1. WIGOWIN 2010
Collision avoidance using a wandering
token in the PTP protocol
_____________________________
Augusto Ciuffoletti

2. PTP?
● PTP stands for Precision Time Protocol
● The nickname for IEEE1588-2008
● It addresses clock synchronization in packet
networks
● Substantially improves the Network Time Protocol
(IETF NTP)
● Addresses converging users (telecom, industrial
plant control)

3. Clock Synchronization - Why?
● Control of industrial plants requires sub
microsecond coordination.
● Telecom networks need precise synchronization to
manage media playback applications.
● Network monitoring applications need
synchronization preciser than packet delay.
● TDM (Time Division Multiplexing) over IP is a
solution for many problems, but needs synchronized
clocks.

4. Synchronization over Packet - Why?
● Link level synchronization solutions exist (SONET,
SyncE …)
● Packet based solutions have many advantages:
– Scalability
– Adaptability
– Maintainability
– Interoperability
● Packet based solutions have one (big) problem:
– Sensitive to packet delay variations

5. The PTP solution
● Messages can travel across layers (UDP/IP, Eth,
DeviceNet)
● One master, many slaves
● The master periodically sends a syntonization
message (Sync)
● Each slave responds after a delay with a Delay_Req
message
● The master replies with a Delay_Resp

6. PTP - Syntonization
● Sync-Sync protocol:
– Invariant: (t1
-t0
) = (t3
-t2
)
– The slave tunes clock frequency
● Assumption: M-S packet delay is constant (!)
Master
Slave
Sync(t0
) Sync Sync Sync Sync
t0
t1
t2
t3

7. PTP - Synchronization
● Delay_Req – Delay_Resp protocol
– Invariant: PacketDelay =[(t1
-t0
) – (t3
-t2
)]/2
– The slave compensates time of the day offset
● Assumption: M-S packet delay is symmetric (!)
Master
Slave
Sync(t0
)
Delay_Req(t3
)
Delay_Resp(t1
)
t0
t1
t2
t3

8. Delay_Req – Delay_Resp
● Delay_Req timing is critical (Delay_Resp is not)
● Delay_Req/Delay_Resp traffic grows with system
size (Sync traffic does not)
● The PTP protocol arranges Delay_Req to be
distributed uniformly on time, but uncoordinated
● Clock synchronization is allocated a small, protected
(virtual) channel
● Packet collisions may occur that disrupt protocol
consistency

9. Coordinate Delay_Req to avoid
collisions
● PRO:
– Protocol overall more reliable (no collisions)
– Improved network utilization
● Beware of:
– Extra complexity, extra problems (KISS)
– Fault tolerance
– Footprint (traffic, processing)
– Standard boundaries

10. One token to rule them all
● Token circulation to control the production of a
Delay_Req
● Randomized token circulation from slave to slave to
avoid complex and slow ring maintenance
● Each slave maintains a limited number of neighbors
to choose from
● But:
– How to limit the token return time?
– How to effectively maintain a neighborhood?
– Do we need additional messages to carry the token?

11. Limit return time
● Introduce some global knowledge in the master
(already a single point of failure) to avoid starvation
● Accumulate global knowledge passively observing
the system (no footprint)
● Activate only when needed (minimize impact of
inconsistencies of global knowledge)

12. Token passing operation
● Token “bounces”
on the master
● Master learns
slaves timeouts
passively
● Token de-routed
to starving slave
● Master usually
transparent
Source
Selected
destinationStarving
slave

13. A dynamic neighborhood
● Neighborhood
initially just legal
● Token source
observes token
routing
● Selected destination
swapped with real
destination
Token de-routed
to D
A – B – C
Selected address
is B
A – D – C
Random
neighborhood
of token source
After
token passing

14. Token passing operation
● The token travels
embedded within
PTP messages
● Delay_Req carries
selected dest
● Delay_Resp
carries final dest
● All slaves observe
Delay_Resp msgs
Source
Final
destination
Delay_req
(unicast)
Delay_resp
(multicast)
Token path PTP messages

15. Future work
● Implementation using the UDP open source PTP
(sourceforge) (thesis)
● Application to wireless ad-hoc networks
(simulation, experiments with low cost devices)
● Use of the PTP in virtual networking environments
(IEEE803.1Q)
● ...and more...
These slides available at “http://www.slideshare.net/AugustoCiuffoletti”