Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Introduction on the Architecture of End to End Multihoming Masataka Ohta Tokyo Institute of Technology

Similar presentations


Presentation on theme: "1 Introduction on the Architecture of End to End Multihoming Masataka Ohta Tokyo Institute of Technology"— Presentation transcript:

1 1 Introduction on the Architecture of End to End Multihoming Masataka Ohta Tokyo Institute of Technology mohta@necom830.hpcl.titech.ac.jp

2 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 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 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 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 6 HHRR Physical Datalink Internetworking Transport Application End System (Host) End System (Host) The Internet Physical Datalink Internetworking Transport Application Physical Datalink Internetworking End Layering Structure of the Internet and “the END” User End

7 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 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 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 10 E2EMH has been Running on 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 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 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 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 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 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)


Download ppt "1 Introduction on the Architecture of End to End Multihoming Masataka Ohta Tokyo Institute of Technology"

Similar presentations


Ads by Google