1 / 24

On the Cost of Supporting Multihoming and Mobility

On the Cost of Supporting Multihoming and Mobility. Ibrahim Matta Computer Science Boston University Joint work with Vatche Ishakian, Joseph Akinwumi, John Day. Mobility = Dynamic Multihoming. Hosts / ASes became increasingly multihomed Multihoming is a special case of mobility

denna
Download Presentation

On the Cost of Supporting Multihoming and Mobility

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. On the Cost of Supporting Multihoming and Mobility Ibrahim Matta Computer Science Boston University Joint work with Vatche Ishakian, Joseph Akinwumi, John Day I. Matta

  2. Mobility = Dynamic Multihoming Hosts / ASes became increasingly multihomed Multihoming is a special case of mobility RINA (Recursive InterNetwork Architecture) is a clean-slate design – http://csr.bu.edu/rina RINA routing is based on node addresses Late binding of node address to point-of-attachment Compare to LISP (early binding) and Mobile-IP Average-case communication cost analysis Simulation over Internet-like topologies I. Matta

  3. What’s wrong today? We exposed addresses to applications We named and addressed the wrong things Applications Applications Network Transport Transport Network Network Data Link Data Link Physical Physical Web, email, ftp, … 128.197.15.1 128.10.127.25 DL DL PHY PHY www.cs.bu.edu 128.197.15.10 128.197.0.0 128.10.0.0

  4. RINA offers better scoping E2E (end-to-end principle) is not relevant Each IPC layer provides service / QoS over its scope IPv6 is/was a waste of time! We don’t need too many addresses within an IPC layer Applications Applications Network Transport Transport Network Network Data Link Data Link Physical Physical Web, email, ftp, … IPC TCP, UDP, … IP IPC DL IPC DL PHY PHY

  5. To: B RINA: Good Addressing Bob want to send message to “Bob” “Bob”B A B IPC Layer I2 I1 IPC Layer • Destination application is identified by “name” • App name mapped to node name (address) • Node addresses are private within IPC layer • Need a global namespace, but not address space • Destination application process is assigned a port number dynamically

  6. B, , are IPC processes on same machine To: B RINA: Good Addressing Bob want to send message to “Bob” A B IPC Layer I1 I2 I1 I2 IPC Layer BI2 • Late binding of node name to a PoA address • PoA address is “name” at the lower IPC level • Node subscribes to different IPC layers

  7. RINA: Good Routing source destination • Back to naming-addressing basics [Saltzer ’82] • Service name (location-independent)  node name (location-dependent)  PoA address (path-dependent)  path • We clearly distinguish the last 2 mappings • Route: sequence of node names (addresses) • Map next-hop’s node name to PoA at lower IPC level I. Matta 7

  8. Mobility is Inherent MH CH • Mobile joins new IPC layers and leaves old ones • Local movement results in local routing updates 8

  9. Mobility is Inherent CH • Mobile joins new IPC layers and leaves old ones • Local movement results in local routing updates 9

  10. Mobility is Inherent CH • Mobile joins new IPC layers and leaves old ones • Local movement results in local routing updates 10

  11. Compare to loc/id split (1) RLOC1x RLOC2y EIDx EIDy EIDx -> EIDy EIDx EIDy • Basis of any solution to the multihoming issue • Claim: the IP address semantics are overloaded as both location and identifier • LISP (Location ID Separation Protocol) ‘06 Mapping: EIDy RLOC2y I. Matta

  12. Compare to loc/id split (2) RLOC1x RLOC2y EIDx -> EIDy EIDx EIDy • Ingress Border Router maps ID to loc, which is the location of destination BR • Problem: loc is path-dependent, does not name the ultimate destination Mapping: EIDy RLOC2y

  13. LISP vs. RINA vs. … • Total Cost per loc / interface change = Cost of Loc / Routing Update + • r [Pcons*DeliveryCost + (1-Pcons)*InconsistencyCost] r: expected packets per loc change Pcons: probability of no loc change since last pkt delivery • RINA’s routing modeled over a binary tree of IPC layers: update at top level involves route propagation over the whole network diameter D; update at leaf involves route propagation over D/2h, h is tree height I. Matta

  14. LISP I. Matta

  15. LISP I. Matta

  16. RINA I. Matta

  17. RINA I. Matta

  18. RINA I. Matta

  19. MobileIP I. Matta

  20. LISP vs. RINA vs. … 8x8 Grid Topology RINA uses 5 IPC levels; on average, 3 levels get affected per move LISP RINA I. Matta

  21. Simulation: Packet Delivery Ratio RINA • BRITE generated 2-level topology • Average path length 14 hops • Random walk mobility model • Download BRITE from www.cs.bu.edu/brite LISP I. Matta

  22. Simulation: Packet Delay LISP RINA I. Matta

  23. Bottom Line: RINA is less costly • RINA inherently limits the scope of location update & inconsistency • RINA uses “direct” routing to destination node • More work: prototyping I. Matta

  24. RINA papers @http://csr.bu.edu/rinaThank YouQuestions? I. Matta

More Related