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

H HR R

PhysicalDatalink

InternetworkingTransport

Application

EndSystem(Host)

EndSystem(Host)

The Internet

PhysicalDatalink

InternetworkingTransport

Application

PhysicalDatalink

Internetworking

End

Layering Structure of the Internet and “the END”

User UserEnd

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)