Your SlideShare is downloading. ×
Collision avoidance using a wandering token in the PTP protocol
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Collision avoidance using a wandering token in the PTP protocol

845
views

Published on

Slides presented during the 2010 WIGOWIN Workshop at the Department of Computer Science in Pisa - May 26. …

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

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
845
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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”