1 / 15

Overview

An Identifier/Locator Split Architecture for Exploring Path Diversity through Site Multi-homing - A Hybrid Host-Network Cooperative Approach. Subharthi Paul, Raj Jain*, Jianli Pan Washington University in Saint Louis Saint Louis, MO 63130 *Presenter: jain@cse.wustl.edu

arsenio-marquez
Download Presentation

Overview

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. An Identifier/Locator Split Architecture for Exploring Path Diversity through Site Multi-homing - A Hybrid Host-Network Cooperative Approach Subharthi Paul, Raj Jain*, Jianli Pan Washington University in Saint LouisSaint Louis, MO 63130*Presenter: jain@cse.wustl.edu These slides are available on-line at: http://www.cse.wustl.edu/~jain/papers/multihom.htm

  2. Overview • Stub-site Multihoming: What and why? • Problems/Weaknesses with current solutions • Our solution • Evaluation of Internet Routing Data

  3. Provider #1 (P1) Provider #2 (P2) Customer (C) What is Stub Site Multi-homing? • Stub Site: Does not provide “Transit Paths” • Stub Sites use multi-homing for: • Backup Paths • Traffic Engineering • Path Diversity

  4. Stub Site Multi-homing Issues • Issue 1: Which address to use? 11.2.248.0/21 11.2.248.0/21 11.2.0.0/16 13.5.0.0/16 Provider #1 (P1) Provider #2 (P2) Provider #1 (P1) Provider #2 (P2) 11.2.0.0/16 13.5.0.0/16 Customer (C) 11.2.248.0/21 Customer (C) 8.3.208.0/24 Use Provider-Independent address Use one Provider-Assigned Address Advertise 8.3.208/24 into the Global routing through P1 and P2 P1 and P2 both Advertise 11.2.248.0 /21 into the Global routing

  5. Multihoming Issues (Cont) • Issue 2: How to control incoming traffic? (Traffic Engineering) • Solution: Border routers over-write source addresses in the outgoing packets. TE-proxy switches flows not packets. Provider #1 (P1) Provider #2 (P2) 60% through P1 40% through P2 Customer (C)

  6. Destination (D) D0 D1 AS5 AS6 AS3 AS4 AS1 AS2 S0 S1 Source (S) Multihoming Issues (Cont) • Issue 3: How to ensure that the two paths are different? • Border routers are not aware of end-to-end path problems • Hosts have “hints” about path problems but no control over “path switching”

  7. ID/Locator Split • Each host is given a 128 bit IPv6-like Identifier (ID) • TCP-like upper layer protocols bind to this ID • IDs are mapped to “Locators” (IPv4 or IPv6) by HID sub layer • In a multi-homed site, each host has multiple locators TCP Layer 128 bit IDs HID Layer Passive Monitoring Decision Process Locator 2 Locator 1 IP Layer

  8. Our Proposed Scheme • Border routers do traffic engineering of flows • At end Hosts: • “shim” snoops reliable transport layer packets to get path hints (Passive Monitoring) • If it detects a “congestion” or “path failure”, it switches its source address • Source “cannot” switch destination address • Destination may switch its “source” address in ACK or return packets • Additional IP options in the packets help hosts communicate with the border routers so that border routers do not override source’s decision in case of path problems

  9. Feasibility Evaluation • Address scalability, diversity, and traffic engineering is useful iff: • A lot of sites are multi-homed • All providers are equally and richly connected • Path diversity is feasible • We analyzed BGP RIB data at “RouteViews” ~11.2 million routes

  10. Multi-Homing in the Internet • Over 1/3rd of the stub sites are dual-homed.

  11. Address Aggregation * Numbers in terms of “Number of AS’s”

  12. Provider/customer AS#1 Provider/customer Peering AS#3 AS#2 Provider/customer Provider/customer AS #4 AS #5 Types of AS Relationships • An AS transports traffic only for those ASs with which it has a provider/customer relationship or peering relationship • Provider connectivity = # of non-stub provider/ customer/ peering links • Higher connectivity is better

  13. Provider Balance • High provider balance Þ Path switching is helpful P1 P2 C

  14. Summary • Multihoming Problems: • Global Routing Scalability • Inbound Traffic Engineering • Leveraging Path diversity • Id/Locator split with PA locators allows scalability • Network traffic engineering through source address re-writing • Allows inbound traffic control • Host switches paths based on passive monitoring of reliable transport layer hints • Co-operative host-network protocol to realize: • Host end-to-end performance requirement • Network traffic engineering goals

  15. References • Subharthi Paul, Raj Jain, Jianli Pan, and Mic Bowman, “A Vision of the Next Generation Internet: A Policy Oriented View,” British Computer Society Conference on Visions of Computer Science, Sep 2008, http://www.cse.wustl.edu/~jain/papers/pona.htm • Jianli Pan, Subharthi Paul, Raj Jain, and Mic Bowman, “MILSA: A Mobility and Multihoming Supporting Identifier-Locator Split Architecture for Naming in the Next Generation Internet,,” Globecom 2008, Nov 2008, http://www.cse.wustl.edu/~jain/papers/milsa.htm • Xiaohu Xu, Dayong Guo, Raj Jain, Jianli Pan, Subharthi Paul, Presented to Routing Research Group (RRG), Internet Research Task Force, Minneapolis, November 21, 2008, http://www.cse.wustl.edu/~jain/irtf/rangi.htm • L. Gao, “On inferring Autonomous System relationships in the Internet,” IEEE/ACM Trans.Networking, vol. 9, no. 6,pp. 733–745, 2001 • L. Subramanian, S. Agarwal, J. Rexford, and R. H. Katz,“Characterizing the Internet hierarchy from multiple vantagepoints,” in Proc. IEEE INFOCOM, June 2002.

More Related