1 / 15

Understanding End-to-End Multihoming Architecture

Dive into the architecture of end-to-end multihoming for scalable internet connectivity. Learn about the relationship between multihoming and IP mobility, implementation frameworks, and the significance of TCP versus IP.

najeraa
Download Presentation

Understanding End-to-End Multihoming Architecture

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. Introduction on the Architecture of End to End Multihoming<draft-ohta-e2e-multihoming-05.txt> Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

  2. What is the Internet? • The Internet is not the Web • just as the Internet was not e-mail 10 years ago • The Internet is an Information Infrastructure • e-mail and web are applications on the Internet and other networks • e-mail and web on the Internet are running over TCP • TCP, of course, is not IP, the Internet Protocol

  3. Applications on the Internet • Web has been a killer application for these years • Free internet telephony is becoming a killer application • over UDP, not TCP • All the network applications, including mission critical ones over SONET, will run on the Internet

  4. Why IPv6? • No NAT • Routing table is small • will hopefully be small forever • Address long enough to separate locator and ID (8+8)

  5. End to End Multihoming • Don’t rely on network intelligence of routing to find the best from multiple routes • Let end systems (hosts) have multiple addresses, each aggregated • let its peer (the other end) select the best • Only the end has enough information for selection • Network should supply hosts network information

  6. End End User User Application Application Transport Transport Internetworking Internetworking Internetworking Datalink Datalink Datalink Physical Physical Physical H R R H End System (Host) End System (Host) The Internet Layering Structure of the Internet and “the END”

  7. When a Host Should Try Alternative Addresses? • Current one is detected to be unreachable by • ICMP • Routing protocol • On timeout (or, in extreme case, always) • IP and UDP have no idea on timeout period • TCP has (defact standard) default timeout • TCP is not IP, the Internet Protocol • Timeout period is application dependent, though TCP may have a default

  8. Mission Critical Applications • Today, hosts running mission critical applications over SONET • have physically isolated multiple routes • SONET layer takes care of rerouting on failure within several tens of milliseconds • short enough for voice communication, however... • In extreme case, the host always use alternative addresses and send multiple copies of data • No bit is lost by failure, no time is lost by rerouting

  9. Relationships between E2E Multihoming and IP Mobility • Both E2E MH and IP mobility handles multiple addresses • IP mobility has its own timing at IP Layer • proper timeout period can be derived from moving speed of mobile hosts • IPv4 home agent is an end system • provided by end users, just as WWW servers • Foreign agent is intelligence in the network

  10. E2EMH has been Runningon NetBSD with LIN6(since March 2002, funded by TAO, an agency of Japanese government) • Several hundreds of lines of patch • Modifications on NetBSD • IP Layer • Reception of packets by ID • Transport Layer (TCP, UDP, …) • Identification of connections by a pair of IDs • New API • LIN6 Daemon • for mobility support (modified a little for security)

  11. Design Framework of Our Implementation (1) • Make everything optional • that lacking some makes hosts behave as if they are singly homed • Use locator ID separation (8+8) • to make implementation extremely simple • packet reception and connection identification by ID • legacy hosts are identified by ID (g/l bits) • dual stack of legacy and E2EMH is working

  12. Design Framework of Our Implementation (2) • Location agents (LAs) maintain locators of mobile hosts • peer inquires (with cookie) LA current locators • LA forward (rewrite locator) packets to hosts • multiple LAs are supported (robustness!) • strong security between a host and its LAs • The peer is notified on locator changes • cookie based weak security is provided • An immobile host may be its own LA

  13. Design Framework of Our Implementation (3) • Multiple addresses of peer is supplied • by reverse query on ID, followed by forward • in TCP header (not yet implemented) • in DNS query (not yet implemented) • if reverse query is not available, non-TCP non-DNS applications must behave as if they are singly homed

  14. Design Framework of Our Implementation (4) • New API is provided to let applications • pass multiple addresses to lower layers • tell lower layers the current one is not working • Original IPv6 style (LIN6 style) APIs are also available • Routing table and metric is configured by hand

  15. Conclusion • End to end approach is the scalable architecture for site and other multihoming • Transport and Application layers must be involved for multihoming support • TCP is not IP • Multihoming and IP mobility are related • E2EMH with LIN6 mobility is running with simple modification (thanks to 8+8)

More Related