IEEE1588 - Collision avoidance for Delay_Req messages in broadcast media

1,239 views

Published on

This presentation has been given during ISPCS in 2009. The full paper is available form http://eprints.adm.unipi.it/.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,239
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

IEEE1588 - Collision avoidance for Delay_Req messages in broadcast media

  1. 1. Collision avoidance for Delay_Req messages in broadcast media Augusto Ciuffoletti [email_address] Università degli Studi di Pisa Dipartimento di Informatica
  2. 2. Outline of the presentation <ul><li>Motivation and problem description
  3. 3. The algorithm
  4. 4. Implementation issues
  5. 5. Validation by analytical model and simulation </li></ul>10/09/09
  6. 6. System model <ul><li>The system is composed by a (large) number of slave clocks
  7. 7. There is one master clock in charge of maintaining clock synchronized
  8. 8. Network is a broadcast medium with unique collision domain
  9. 9. Slaves require to be adjusted with Delay_Req/Delay_Resp with bounded periodicity </li></ul>Idea: Exploit broadcast to avoid collision 10/09/09
  10. 10. Collision events <ul><li>Two Delay_Req msgs sent at approx the same time
  11. 11. The (broadcast) network transports them in different times
  12. 12. They are serviced with some delay
  13. 13. Asymmetry and jitter are introduced </li></ul>Master Slaves Jitter Delay_Req collision 10/09/09
  14. 14. How frequently this event occurs? <ul><li>R: It depends on the distribution of Delay_Req events
  15. 15. We assume that all slaves want to refresh their clock with the same frequency.
  16. 16. IEEE1588 avoids clustering of Delay_Req messages using random delays (clause 9.5.11.2)
  17. 17. This has the effect of keeping the density of Delay_Req events constant in time </li></ul>10/09/09
  18. 18. Probability of collision <ul><li>We introduce two system constants:
  19. 19. n : the number of slaves
  20. 20. δ : the period between successive Delay_Req on one slave
  21. 21. Expected number of Delay_Req per time unit
  22. 22. λ=n/δ
  23. 23. To evaluate the probability of collision, we need to introduce the duration of the event τ </li></ul>1-(1+r)e -r with r=λτ 10/09/09
  24. 24. Probability of collision τ =10 μsec N=1000 δ =1 sec p=5 10 -5 1 collision every 2000 secs 10/09/09
  25. 25. Requirements for a collision avoidance algorithm <ul><li>Bounded timing of Delay_Req (from slave perspective);
  26. 26. Lower probability of collision events with respect to random scheduling
  27. 27. Low traffic overhead
  28. 28. Embedded into existing protocol </li></ul>10/09/09
  29. 29. The basic idea: token scheduling <ul><li>A token is circulated: the slave holding the token sends the Delay_Req
  30. 30. however
  31. 31. Additional control to implement the overlay ring
  32. 32. Additional bandwidth to implement token exchange
  33. 33. Uncertain roundtrip time
  34. 34. Compensated by (apparent) deterministic collision avoidance </li></ul>10/09/09
  35. 35. Introducing random walks <ul><li>Randomized control of the overlay network (token destination selected at random in a random set of neighbors)
  36. 36. Token carried by the same Delay_Req/Delay_Resp pair
  37. 37. Global view to enforce bounded return time </li></ul>10/09/09
  38. 38. Token circulation algorithm slave part <ul><li>Maintain a dynamic, random list of neighbors observing the traffic on the broadcast medium
  39. 39. Wait to receive a token
  40. 40. Send the Delay_Req upon receiving a token
  41. 41. Deliver the token to a neighbor at random </li></ul>OK, but what about bounded return time? 10/09/09
  42. 42. Token circulation algorithm master part <ul><li>The master maintains the timeouts of all slaves
  43. 43. When one of the slaves is about to exceed the return time bound </li></ul>the master reroutes the token <ul>to feed the starving slave <li>The data structure needed for the task is not discussed in the paper </li></ul>How does an IP device de-route a token... ...and what is a token, after all 10/09/09
  44. 44. What is a token, anyway? <ul><li>There is no token in fact: it is just an abstraction
  45. 45. “ Holding the token” is a flag in the state of the slave
  46. 46. The slave “holding the token” indicates, in the Delay_Req packet, the MAC of the next holder
  47. 47. The master may reroute the token by indicating a different token holder
  48. 48. Remember that we are in a broadcast network: everybody sees every packet </li></ul>10/09/09
  49. 49. Implementation issues <ul><li>Not enough room in a Delay_Req Delay_Req (5 octets + 4 bits available) frame to hold a MAC address (6 octets)
  50. 50. Unless MAC are locally administered
  51. 51. Our solution: </li><ul><li>Use 3 octets in both Delay_Req and Delay_Resp
  52. 52. In case of ambiguity, the master disambiguates completing the MAC
  53. 53. In case of rerouting and ambiguity, two “Delay_Resp” are required (extra network load) </li></ul></ul>10/09/09
  54. 54. Evaluating the solution <ul><li>Residual collision event: two timeout are generated at the same time
  55. 55. The master selects one of them to receive the token </li></ul><ul><li>A probabilistic model has been studied
  56. 56. The figure compares native random scheduling with token scheduling
  57. 57. The model considers a full mesh overlay
  58. 58. Colliding events are discarded </li></ul>10/09/09
  59. 59. Evaluating the solution <ul><li>To evaluate the impact of the two approximations, we used simulation. </li></ul>Explanation (r=0.2) <ul><li>The right spike is motivated by the slaves that receive the token as a consequence of a timeout
  60. 60. The deviation is due to bounded degree approximation of the network </li></ul>10/09/09
  61. 61. Conclusions <ul><li>In a broadcast network with many slaves Delay_Req messages may collide, and deteriorate synchronization
  62. 62. We use the power of broadcast (the reason of the problem) to reduce the risk of collision
  63. 63. Timing of Delay_Req is bounded (as required)
  64. 64. No network overhead (as required)
  65. 65. No change in message format (as required) </li></ul>10/09/09

×