Download presentation
Presentation is loading. Please wait.
Published byRaegan Whitebread Modified over 10 years ago
1
NEIGHBORHOOD WATCH PROTOCOL An Address Resolution Protocol for the HID Principal in XIA Cody Doucette Michel Machado John W. Byers
2
eXpressive Internet Architecture (XIA) Joint venture between BU, CMU, UW-Madison; part of Future Internet Architectures initiative (FIA) Broad goal is to reform the network stack at narrow waist– IP The Internet needs trustworthiness and evolvability! BU Network Reading Group, September 17, 2012 2
3
eXpressive Internet Architecture (XIA) IP problem: Focusing on one communication type hinders others XIA approach: Modularize communication types so that one architecture can support many (future) paradigms IP problem: Using new communication types may require all legacy routers to be updated XIA approach: Require backwards-compatibility using widely-accepted types IP problem: Numerous security issues: IP address spoofing, IP fragment attacks, … XIA approach: Introduce intrinsic security individually for each communication type BU Network Reading Group, September 17, 2012 3
4
Three Pillars of XIA BU Network Reading Group, September 17, 2012 Principal types: autonomous domains, hosts, services, content, and future types Fallbacks: new types that may not be globally known must include backwards-compatible address 4
5
New network layer protocol; uses a DAG with principal types to specify multiple paths to destination eXpressive Internet Protocol (XIP) BU Network Reading Group, September 17, 2012 5
6
Express intent when using principal types; this provides for heterogeneity and intrinsic security: eXpressive Internet Protocol (XIP) BU Network Reading Group, September 17, 2012 6
7
Host-to-Host Communication in XIA Host-to-host communication especially important– required as a fallback edge Hosts need a way of: Discovering other hosts in the LAN Mapping network layer addresses (HIDs) into link layer addresses How can hosts in XIA accomplish this? BU Network Reading Group, September 17, 2012 7
8
Motivation Why not extend ARP? Four edges at every hop in XIP Using ARP to lookup each edge would slow routing HIDs do not support network masks ARP responses would flood all interfaces XIP values secure link layer addressing ARP does not guarantee security; ARP spoofing BU Network Reading Group, September 17, 2012 8
9
Enter: Neighborhood Watch Protocol Defining Characteristics: Neighborhood assumption: operates under assumption that all hosts that support HIDs in a LAN know of each other Routing never stops: utilizes RCU for interruption-free lookups Supports evolution: works in conjunction with HID principal only, not a companion to XIP BU Network Reading Group, September 17, 2012 9
10
Enter: Neighborhood Watch Protocol Defining Characteristics: Efficiency: begets low network overhead compared to using ARP Robustness: prevents data inconsistencies due to node failure and network partitioning Scalability: constructs an eventually consistent LAN of arbitrary size BU Network Reading Group, September 17, 2012 10
11
Functionality What can NWP do? Address resolution Failure detection Efficient table synchronization (WIP) Link-layer addressing security (WIP) BU Network Reading Group, September 17, 2012 11
12
Functionality What can NWP do? Address resolution Failure detection Efficient table synchronization (WIP) Link-layer addressing security (WIP) BU Network Reading Group, September 17, 2012 12
13
Address Resolution: Neighborhood View Neighbor list contains hosts connected via a common LAN interface Neighbors here: A E, B E, C E A W, C W BU Network Reading Group, September 17, 2012 13
14
Address Resolution: Announcing Hosts can broadcast announcements to learn about neighbors Bit Offset 0 – 78 – 15 0VersionType 16 Number of HIDsHardware Addr. Len. 32 Hardware Address of Announcing Host** 48 64 80HID 1 …… …HID N Announcement contains all HIDs that correspond to a single hardware address NWP Announcement Packet Header ** Assuming a 48-bit MAC address. BU Network Reading Group, September 17, 2012 14
15
Address Resolution: Responding Neighbor lists are sent in response to an announcement Bit Offset 0 – 78 – 15 0VersionType 16 Number of HIDsHardware Addr. Len. 32 HID 1 Num 1 HA 11 … HA 1Num 1 … … … HID N Num N HA N1 … HA NNum N List tells receiver about neighbors and associated hardware addresses NWP Neighbor List Packet Header BU Network Reading Group, September 17, 2012 15
16
Functionality What can NWP do? Address resolution Failure detection Efficient table synchronization (WIP) Link-layer addressing security (WIP) BU Network Reading Group, September 17, 2012 16
17
Failure Detection Neighbors should be monitored to observe failure or disconnection Goals of the NWP failure detector: Completeness Accuracy Speed Scalability Distribution BU Network Reading Group, September 17, 2012 17
18
Failure Detection: Distribution Consider: Two nodes cannot communicate due to temporary packet loss. These nodes should retain neighbor status. If two neighbors cannot connect, the source uses a set K of other neighbors to investigate This distributes the decision of failure across |K|+1 nodes Distributed failure detector based on previous work by Gupta et al., PODC 01 http://cdn.dailyclipart.net/wp-content/uploads/medium/clipart0252.jpg BU Network Reading Group, September 17, 2012 18
19
Failure Detection: Two Nodes Source pings random neighbors at set intervals; destination sends an ack upon receipt Senders include lower 32 bits of their clock to synchronize Bit Offset 0 – 78 – 15 0VersionType 16 Hardware Addr. Len.Reserved 32 Senders Clock (lower 32 bits) 48 64Source Host Hardware Address …Destination Host Hardware Address NWP Ping/Ack Packet Header BU Network Reading Group, September 17, 2012 19
20
Failure Detection: Three Nodes Bit Offset 0 – 78 – 15 0VersionType 16 Hardware Addr. Len.Reserved 32 Senders Clock (lower 32 bits) 48 64Source Host Hardware Address …Destination Host Hardware Address …Investigative Host Hardware Address NWP Request/Investigative Ping Packet Header If no ack is received, source uses other neighbors to investigate potentially failed destination If no response is heard after a set time, destination is marked as inactive BU Network Reading Group, September 17, 2012 20
21
Failure Detection: Packet Types BU Network Reading Group, September 17, 2012 NiNi NjNj NxNx NWP Ping Request NWP Request Ack NiNi NjNj NxNx NWP Investigative Ping NiNi NjNj NxNx NiNi NjNj NWP Ping NiNi NjNj NWP Ack 21
22
Failure Detection: Algorithm BU Network Reading Group, September 17, 2012 Similar diagram found in Gupta et al., 2001 22
23
Failure Detection: Conflict Resolution Question: How does the NWP failure detector reconcile conflicting reports about the status of a neighbor? Answer: Neighbor tables hold local/remote times at which neighbors status was recorded If a neighbor fails, we make an inference about what time it failed We resolve conflicts by taking most up-to-date information Node A Neighbor TableNode C Neighbor Table StatusNodeMy ClockRemote Clock UpB500530 DownB538568 StatusNodeMy ClockRemote Clock UpB480565 BU Network Reading Group, September 17, 2012 23
24
Failure Detection: Mass Failure Question: All neighborhood tables are equal before a network partition takes place. How will a node remove all entries from its table that are no longer accessible? Answer: In most cases, a mass disconnection is handled in the same way that an individual disconnection is handled: gradually The detection scheme promises only eventual consistency http://drtom.schank.ch/talks/2010/12/NoSQL/CAP/NetworkPartition03.svg BU Network Reading Group, September 17, 2012 24
25
However, there is a mechanism for detecting when a mass failure might have occurred. Consider the case where D tries to monitor E: If DE communication fails, A, B, and C are of no help here since they are in a separate partition However, D should recognize that it received no response from A, B, and C Failure Detection: Mass Failure, Continued BU Network Reading Group, September 17, 2012 25
26
Failure Detection Neighbors should be monitored to observe failure or disconnection Goals of the NWP failure detector: Completeness: Accuracy: Speed: Distribution: Scalability: BU Network Reading Group, September 17, 2012 26
27
Failure Detection BU Network Reading Group, September 17, 2012 27
28
Functionality What can NWP do? Address resolution Failure detection Efficient table synchronization (WIP) Link-layer addressing security (WIP) More to come! BU Network Reading Group, September 17, 2012 28
29
References XIA: An Architecture for an Evolvable and Trustworthy Internet by Hyeontaek Lim. In The 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI12) (San Jose, CA), April 25-27, 2012 On Scalable and Efficient Distributed Failure Detectors by Indranil Gupta, Tushar D. Chandra, and Germán S. Goldszmidt. In Proceedings of the Twentieth Annual ACM Symposium on Principles of Distributed Computing, 2001. XIA: Efficient Support for Evolvable Internetworking by Dongsu Han, Ashok Anand, Fahad Dogar, Boyan Li, Hyeontaek Lim, Michel Machado, Arvind Mukundan, Wenfei Wu, Aditya Akella, David G. Andersen, John W. Byers, Srinivasan Seshan, and Peter Steenkiste. In Proc. 9th USENIX NSDI, (San Jose, CA), Apr. 2012. BU Network Reading Group, September 17, 2012 29
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.