The Architecture of End to End Multihoming
draft-ohta-e2e-multihoming-05
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Dr. Masataka Ohta | ||
| Last updated | 2003-07-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This memo describes the architecture of end to end multihoming. End to end multihoming does not burden routing system for multihoming. That is, even extensive use of end to end multihoming does not increase the number of entries in a global routing table. Traditionally with IPv4, multihoming capability is offered by an intelligent routing system, which, as is always the case with violating the end to end principle, lacks scalability on a global routing table size and robustness against link failures. On the other hand, with end to end multihoming, multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network and works as long as there is some connectivity between the end systems. Because end to end multihoming is performed in end systems, the architecture needs no routing protocol changes Instead, APIs and applications must be modified to some extent.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)