1 / 23

LEVER: Leveraging Routing Infrastructure for Routing Scalability, Mobility and Content Networking

LEVER: Leveraging Routing Infrastructure for Routing Scalability, Mobility and Content Networking. IEEE CCW, Oct. 2011 Ted “ Taekyoung ” Kwon Seoul National University. Joint work with Ray at Rutgers, ES Cho at SNU, SC Kim at SNU. Routing scalability. Number of IP prefixes.

naoko
Download Presentation

LEVER: Leveraging Routing Infrastructure for Routing Scalability, Mobility and Content Networking

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. LEVER: Leveraging Routing Infrastructure for Routing Scalability, Mobilityand Content Networking IEEE CCW, Oct. 2011 Ted “Taekyoung” Kwon Seoul National University Joint work with Ray at Rutgers, ES Cho at SNU, SC Kim at SNU

  2. Routing scalability • Number of IP prefixes Source: GeoffHuston@APNIC

  3. Routing scalability • Multi-homing, TE, non-aggregatable prefix assignment • Endpoint identifiers (EIDs) may have to be separated from routing locators (RLOCs) • Locator Identifier Separation Protocol (LISP) and so on • Q1: How to find RLOCs from EIDs?

  4. Mobility • Mobility becomes the norm Data: ITU

  5. Mobility • IP mobility • Many unsuccessful proposals • Different contexts • Identifier and locator • Home address (HoA) and care-of-address (CoA) • Initial address and new address(es) • Q2: how to find CoA for HoA?

  6. Content networking • Content-oriented Internet usage Source: Limelight

  7. Content networking • Two contrasting approaches • Route-by-name • DONA, CCN,… • Scalability problem • Lookup-by-name • P2P, CDN,… • Application-specific, cost • The latter could be almost as efficient as the former • Assume content ID is standardized, like URL • Q3: how to find the location for content ID?

  8. A common mapping infra • FQDN  IP : DNS • EID  RLOC : routing scalability • HoA  CoA : mobility • Content ID  IP : content networking

  9. I. An Evolutionary Approach

  10. FQDN  IP Root (1) • FQDN: www.cs.bu.edu edu. com. (2) (3) bu. mit. Name Client (4) IP cs. LocalMappingServer

  11. EID  RLOC Root (1) • 58.10.46.147.in-addr.arpa(EID: 147.46.10.58) arpa. com. (2) (3) in-addr. ip6. EID Client (4) 147. RLOC LocalMappingServer (5) 46. * Assume the ISP has class B address block: 147.46.0.0/16

  12. HoA CoA Root (1) • 58.10.46.147.in-addr.arpa(HoA: 147.46.10.58) arpa. com. (2) (3) in-addr. ip6. HoA Client (4) 147. CoA LocalMappingServer (5) 46. * Assume the ISP has class B address block: 147.46.0.0/16

  13. Content ID (CID)  IP Root (1) • CID: www.cs.bu.edu/a.mpg edu. com. (2) (3) bu. mit. CID Client (4) cs. IP LocalMappingServer (5) www. * Assume, for each FQDN, a single server maintains mapping for all the URLs starting with the FQDN

  14. Mobility in-depth Correspondent/mobile Node bu.edu Local/home Mapping Server Mobile Node DNS (2) HoA? (3) HMS verizon.com Home Mapping Server (HMS) att.com (4) HoA? (5) CoA (1) HoA? Corres. Node (6) CoA * Mobile node is a Verizon user, moves to BU * the HMS is the leaf in the DNS hierarchy

  15. Mobility w/ caching bu.edu Mobile Node DNS (4) HMS (3) If cache miss verizon.com (5) HoA? att.com HMS (6) CoA A B (2) To find cache D (7) CoA (1) HoA? Corres. Node (8) CoA C * CN is a user of AT&T, which caches mapping * Hashed value of MN’s HoA starts with 0b01

  16. II. A Clean Slate Approach

  17. 2. There will be other mapping schemes, which should be supported in the Future Internet, e.g. RFID 1. So far, we talked about an evolutionary approach 3. DNS may be outdated Verisign undertakes Project Apollo, which will grow capacity 1,000 times today’s level of 4 trillion queries to manage 4 quadrillion queries per day by 2020.

  18. Building a mapping infra: a clean-slate approach • Hierarchical vs. flat • Centralized vs. distributed • Can we leverage the routing structure to realize the mapping infra?

  19. LEVER: Realizing mapping by leveraging routing • Mapping server co-locates with router • E.g. local mapping server = router • For a given ID, how can we find a mapping server who is in charge?

  20. LEVER: how to advertise IDs? • the ID space is divided among ASs • Each AS is in charge of mapping for the IDs in its partition, which is advertised by BGP • BGP router knows which ASs are in charge of which ID partition: AS mapping table • We can extend/leverage BGP • A partition of an AS is divided among its routers • Each router is in charge of mapping for the IDs in its sub-partition, which is advertized • A router knows the IDs maintained by other routers in the same AS: router mapping table • We can leverage intra-domain routing

  21. LEVER: how to find mapping of an ID Router Mapping Table AS 30: FP 010 AS Mapping Table (4) 100.200.20.1 100.200.30.1 (5) (3) AS 20: FP 001 Solicitor (2) Access Router Router (1) BGP Speaker * ID is 0b01010… First prefix (FP) second prefix (SP)

  22. LEVER • Relies on IP routing • Overlay • Incentives • ICANN may enforce the mapping service • E.g. ID partition  assigned address block • ISP can offer registry operator biz

  23. Thank you! tkkwon@snu.ac.kr

More Related