1 / 36

JinHyeock Choi, Syam Madanapalli 2005.08.04 hppt://diffeo/LinkId

DNA Solution: Link Identifier based approach draft-jinchoi-dna-protocol2-01.txt. JinHyeock Choi, Syam Madanapalli 2005.08.04 hppt://www.diffeo.com/LinkId.ppt. Contents. Background Overview Protocol operation Router Operation Host Operation Summary. Background. Background.

jenny
Download Presentation

JinHyeock Choi, Syam Madanapalli 2005.08.04 hppt://diffeo/LinkId

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DNA Solution: Link Identifier based approach draft-jinchoi-dna-protocol2-01.txt JinHyeock Choi, Syam Madanapalli 2005.08.04 hppt://www.diffeo.com/LinkId.ppt

  2. Contents • Background • Overview • Protocol operation • Router Operation • Host Operation • Summary

  3. Background

  4. Background G1 DNA schemes should detect the identity of the currently attached link to ascertain the validity of the existing IP configuration. • This draft provides the scheme which satisfies G1. • Link Identifier based approach • To compare links, it’s natural to assign them unique names and compare them. • We present a new way to assign each link UNIQUE name, “Link Identifier”. By comparing two LinkIDs, host can easily check for link change.

  5. LinkID & Landmark Comparison • LinkID • LinkID is a UNIQUE name assigned to each link. Two different links have two different LinkID. • Assume a host keeps a LinkID, after while • If a host sees a different LinkID, it has moved to a different link. • Landmark • One link can have MULTIPLE landmarks. (Landmark is assigned to a link such that two different links doesn’t have the same landmark.) • Assume a host keeps a landmark, after while • If a host sees a different landmark, it doesn’t mean it has moved to a different link.

  6. LinkID Tasks • Efficient LinkID assignment • How to efficiently assign UNIQUE LinkID to each link. • Graceful LinkID change • How would hosts cope with LinkID change gracefully.

  7. Basic Idea • All routers on a link agrees on one (global) prefix to advertise as the LinkID prefix. • Each router collects all the prefixes on the link and picks the smallest one as the LinkID prefix. • Each router advertises the LinkID prefix with the special LinkID flag (Identifier bit) in every RA message it sends. • Hosts keeps the LinkID Prefix to check for link change. • When it receives the same LinkID prefix, it assumes that it remains at the same link. • When it receives the different LinkID prefix, it assumes that it moves to a different link.

  8. Type Length PrefixLength L A I Res1 ValidLifetime PreferredLifetime Reserved 2 Prefix LinkID Prefix

  9. AR1 AR2 AR3 Link 1 Link 2 AP1 AP2 AP3 LinkID, rough sketch While there are 3 point of attachment, there are only 2 links. Internet

  10. Router Operations • Collecting the prefixes • Selecting the LinkID prefix • Advertising the LinkID prefix • Graceful LinkID prefix change

  11. {A} {B, C, D} {B, C, D} AR1 AR2 AR3 AP3 AP1 AP2 LinkID, rough sketch 1. AR1 advertises Prefix A:: 2. AR2 advertises Prefix B:: Internet 3. AR3 advertises Prefix C::, D:: 4. Each AR generate the set of all the prefixes on the link 5. Each AR picks the smallest prefix of the complete prefix list as LinkID prefix. A:: B:: C::, D::

  12. {A} {B, C, D} {B, C, D} AR1 AR2 AR3 AP3 AP1 AP2 LinkID, rough sketch 1. AR1 advertises Prefix A:: 2. AR2 advertises Prefix B:: Internet 3. AR3 advertises Prefix C::, D:: 4. Each AR generate the set of all the prefixes on the link 5. Each AR picks the smallest prefix of the complete prefix list as LinkID prefix. A:: B:: C::, D:: 6. Each AR puts the LinkID prefix in its RA message.

  13. RA3 RA2 RA1 B:: B:: A:: {A} {B, C, D} {B, C, D} AR1 AR2 AR3 AP2 AP1 AP3 LinkID, rough sketch 1. AR1 advertises Prefix A:: 2. AR2 advertises Prefix B:: Internet 3. AR3 advertises Prefix C::, D:: 4. Each AR generate the set of all the prefixes on the link 5. Each AR picks the smallest prefix of the complete prefix list as LinkID prefix. A:: B:: C::, D:: 6. Each AR puts the LinkID prefix in its RA message.

  14. Host Operations • Managing the LinkidPrefixList • Checking for link change

  15. RA2 RA1 RA3 A:: B:: B:: AR2 AR3 AR1 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet

  16. RA3 RA1 RA2 B:: B:: A:: AR2 AR1 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet

  17. RA2 RA3 RA1 B:: B:: A:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. { A }

  18. RA2 RA3 B:: B:: AR1 AR2 AR3 MN AP3 AP2 AP1 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. { A }

  19. RA3 RA2 B:: B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. { A }

  20. RA3 RA2 B:: B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. 6. MN extracts LinkID prefix B:: from RA2 and compares it with the existing LinkID prefix A::. 7. Because they are different, MN assumes that it has moved to a new link and change its LinkID Prefix to B::. { A } { B }

  21. RA3 RA2 B:: B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. 6. MN extracts LinkID prefix B:: from RA2 and compares it with the existing LinkID prefix A::. 7. Because they are different, MN assumes that it has moved to a new link and change its LinkID Prefix to B::. 8. MN again moves to AP3 and makes a new link-layer connection. { B }

  22. RA3 B:: AR1 AR2 AR3 MN AP3 AP1 AP2 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. 6. MN extracts LinkID prefix B:: from RA2 and compares it with the existing LinkID prefix A::. 7. Because they are different, MN assumes that it has moved to a new link and change its LinkID Prefix to B::. 8. MN again moves to AP3 and makes a new link-layer connection. 9. MN receives RA3 from AR3. { B }

  23. RA3 B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. 6. MN extracts LinkID prefix B:: from RA2 and compares it with the existing LinkID prefix A::. 7. Because they are different, MN assumes that it has moved to a new link and change its LinkID Prefix to B::. 8. MN again moves to AP3 and makes a new link-layer connection. 9. MN receives RA3 from AR3. { B }

  24. RA3 B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 1. MN is attached to AP1. 2. MN receives RA1 from AR1. Internet 3. MN extracts LinkID prefix A:: from RA1 and keeps it. 4. MN moves to AP2 and makes a new link-layer connection. 5. MN receives RA2 from AR2. 6. MN extracts LinkID prefix B:: from RA2 and compares it with the existing LinkID prefix A::. 7. Because they are different, MN assumes that it has moved to a new link and change its LinkID Prefix to B::. 8. MN again moves to AP3 and makes a new link-layer connection. 9. MN receives RA3 from AR3. { B }

  25. RA3 B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 10. MN extracts LinkID prefix B:: from RA3 and compares it with the existing LinkID prefix B::. Internet 11. Because they are the same, MN assumes that it still remains at the same link and keeps its LinkID Prefix B::. { B } { B }

  26. RA3 B:: AR1 AR2 AR3 MN AP1 AP2 AP3 LinkID, rough sketch 10. MN extracts LinkID prefix B:: from RA3 and compares it with the existing LinkID prefix B::. Internet 11. Because they are the same, MN assumes that it still remains at the same link and keeps its LinkID Prefix B::. { B }

  27. New Terms • LinkID advertisement • PIO (Prefix Information Option) • LPIO (Learned Prefix Information Option) • Identifier bit (I-bit) • Graceful LinkID Change • Linkid Prefix list (LinkidPrefixList) • Linkid lifetime • LEAST_VALID_LIFETIME

  28. Open Issues • Issue 001: LPIO format • Issue 002: Advertising old linkid prefix • Issue 003: Flash renumbering and early reassignment • Issue 004: DAD Interaction • Issue 005: MLD Interaction • Issue 006: Sending RA before completing prefix collection • Issue 007: Linkid prefix option for RS message • Issue 008: Linkid Selection Scheme

  29. Summary • This draft present a way for a host to check for link change correctly. • Hosts can even cope with LinkID change gracefully. • The draft is implemented and tested. • Hosts performed just well. • There may be other applications for unique LinkID per a link. • LinkID in L2 beacon • We propose this scheme as a DNA solution for Link Identification.

  30. Appendix Linkid for DNAImplementation & Test Results Subba Reddy

  31. Linkid Implementation • Implemented the linkid code on Linux OS (Kernel 2.4.18) • Router side • We added code to RA Daemon • Samsung ISO implementation based on Linux RADVD version 0.7.2 • No. of lines of code: 390 • Host side • We added code to our own IPv6 stack (SISOv6) • No. of lines of code: 160. • We also developed CLI to add/delete the prefixes on routers at runtime

  32. Link1:- R1:- 3ffc::/64, 3ffd::/64 R2:- 3ffa::/64, 3ffb::/64 R3:- 3ff3::/64, 3ff4::/64 Link2:- R1:- 4ffc::/64, 4ffd::/64 R2:- 4ffa::/64, 4ffb::/64 R3:- 4ff3::/64, 4ff4::/64 Hub 1 Hub 2 Link2 Link1 R2 R1 R3 MN Test Setup …

  33. Test Setup … • We were running Ethereal on MN • The Interfaces are Wired Ethernet • No packet loss • Routers advertise immediately whenever there is a new prefix added or deleted which causes the change in linkid • We made all Routers to advertise whenever there is a linkid change to measure the synchronization time using ethereal.

  34. How we tested … • Initialization • We have configured different prefixes on each of the router interfaces as mentioned in the test setup • After Synchronization, Routers announces the linkid • Host learns the linkid • Adding new Smaller Prefix on a link • Now we added a smaller prefix (3ff0::/64) on R1 to check the Synchronization time for the new linkid and MN behavior • MN did not make wrong decision for link change

  35. How we tested … • Deletion of Existing Prefixes • We decreased the smallest prefix (3ff0::/64) valid life time to 1.5 hours in runtime • All the routers made the prefix as old linkid (3ff0::/64) and selected new linkid (3ff3::/64) • MN did not make wrong decision for link change • After 1.5 hrs the prefix (3ff0::/64) has been removed from the link • Link Change • MN has been moved from link1 to link2 • MN made the link change decision (new linkid: 4ff3::/64) • We repeated the above tests on the link 2 as well

  36. Test Results • Synchronization Time • Whenever there is a change in linkid, all routers synching within ~600 micro seconds • Error Rate • MN has never made any wrong decision in any scenario we have tested in. • MN did not make any wrong decision when we changed the linkid by adding new smaller prefix • MN did not make any wrong decision when we changed the linkid by deleting the existing linkid prefix • MN made correct decision when MN has been moved from link1 to link2, and back to link1

More Related