1 / 14

RADAR

RADAR. Ring-based Adaptive Discovery of Active neighbour Routers. A Neighbourhood discovery protocol for ANTS platform. Introduction. Introduction. Why do we neighbourhood info ? Extending ANTS ... The topology isn’t homogenous: active node among ordinary IP nodes (overlay).

stash
Download Presentation

RADAR

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. RADAR Ring-based Adaptive Discovery of Active neighbour Routers A Neighbourhood discovery protocol for ANTS platform

  2. Introduction Introduction Why do we neighbourhood info ? Extending ANTS ... • The topology isn’t homogenous: active node among ordinary IP nodes (overlay). • A capsule passed to a non-active node will be lost. • We need a list of “next active hops” at each active node: • Even a flooding-based routing requires a knowledge of the neighbourhood • Building a routing table requires a neighbourhood relationship

  3. Introduction Neighbourhood Definition • Full Mesh?: • Every AN can virtually reach any other AN node through IP routing • most applications don’t want such a mesh • Must be Directly Reachable: • if A is a neighbour of B, no other active node must see capsules B sends to A. • Cost Limit: • The neighbours must be “close enough” (maximum hops count, TTL, bounded RTT …)

  4. Introduction Existing Discovery Techniques … • Hello/Reply : (classic IP routing) • Simple and efficient • Requires a broadcast feature on the link. • DNS-based : (Protean, ALAN, …) • Registering at a centralized component (DNS) • No information about component proximity • Clusters: (TAO) • Too coarse level (full mesh within a cluster) • Still based on a DNS service. … doesn’t provide what we wish: a plug’n’play decentralized discovery

  5. Framework Overview AYA? « Are You Active ? » Capsules • sort of active “ICMP ECHO” • capsules sent to a target node, only active nodes will reply. • Plain IP nodes just drop them IP AB ANEP Type =ANTS AYA (target = B) A A ??? Radar Radar B ANTS ANTS IP IP IP IP If nothing done, how to guarantee direct reachability of discovered neighbours ?

  6. Framework Overview AYA? Capsules Grabbing: • packet filter on every active node • Capsules with ANEP/IP will be intercepted • and processed by active nodes on the path. IP AB Proto =ANEP ANEP Type =ANTS AYA (target = B) A Radar Radar B ! ANTS ANTS IP IP IP IP Capsules that can’t be routed by ANTS are made grabbable and sent through IP to their destination.

  7. Framework : when to send AYA? Table-driven: Get a copy of IP routing table at start up Probe the addresses found (both “IP next hop” and destinations) complete discovery of the local domain Do not cross domain bounds Traffic-based: Just watch the capsules that cross the node Probe unknown previous active nodes Discovery across domain bounds Needs some bootstrap to have some traffic generated  Better results when used together

  8. RADAR : a Ring Search using AYA capsules AYA AYA AYA AYA AYA AYA AYA • Sorting IP routing table by node cost (rings) • Grouping targets based on the output interface • Independent instance of search process on each interface • Send AYA capsules ring after ring … • Stop searching when we found enough neighbours 3 2 1 0

  9. RADAR: Semi-persistent Search What about stopping at first discovered neighbour ? • Results in inefficient routes • In this case, 40% overhead if SY must cross X • Can be avoided with good routing if Y appears as a neighbour of S. • Might exclude some nodes • If X reach S and Y with the same interface, Y will be out of the scope for both nodes • Leads to partitionned network Y X S  Need to look a bit further

  10. RADAR: Implementing Semi-persistent search • If ring > thrsh • Stop search Inactive node  thrsh ++ Active node  thrsh/=2 When to stop the search ? • Stopping at first neighbour often results in inefficient routing tables. • Threshold telling how far we search • Search progress dynamically modify the threshold. • Threshold must adapt to the topology • Should not restrict the distance between active neighbours a priori • Learn the average active nodes density through A.I.M.D. algorithm • Stops earlier if the first neighbour is closer • Stops earlier if a neighbours « covers » more nodes

  11. RADAR: First Results Initial topology (darker nodes are actives) Using RADAR’s adaptive threshold using static threshold (not RADAR) A slight modification of the max_ttl limit introduces important topology changes Important modification of the divisor only involves a few additionnal links.

  12. RADAR: Using Traffic-based Discovery ping AYA Domain A Domain B A2 unknown  probe A1 B2 unknown  Grabable B1 Internet A2 B2 • Local table-driven discovery • A1 sends data to B2 • Traffic-based in action … • Finally interconnected

  13. Conclusions & Future Work • We provided a neighbourhood discovery for ANTS which works on local domain and inter-domain • Adaptive threshold algorithm allows plug’n’play behaviour (no topology-specific settings) • Can handle topology changes while running, but would require changes to handle hyper-dynamic topologies (mobile nodes, etc) • Threshold evolution when nodes appear/ disappear still needs investigations Thank you for your attention …

  14. Questions ?

More Related