Transcript PPT Version

Introduction on the Architecture
of End to End Multihoming
<draft-ohta-e2e-multihoming-05.txt>
Masataka Ohta
Tokyo Institute of Technology
[email protected]
1
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
2
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
3
Why IPv6?
• No NAT
• Routing table is small
– will hopefully be small forever
• Address long enough to separate locator and
ID (8+8)
4
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
5
End
End
User
Application
Transport
Internetworking
Datalink
Physical
H
Internetworking
Datalink
Physical
R
End
System
(Host)
User
Application
Transport
Internetworking
Datalink
Physical
R
The Internet
H
End
System
(Host)
Layering Structure of the Internet and “the END”
6
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
7
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
8
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
9
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)
10
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
11
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
12
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
13
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
14
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)
15