Scalable Support for Multi-homed Multi-provider Connectivity
RFC 2260
Document | Type |
RFC - Informational
(January 1998; Errata)
Was draft-rfced-info-bates-multihoming (individual)
|
|
---|---|---|---|
Authors | Tony Bates , Yakov Rekhter | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2260 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group T. Bates Request for Comments: 2260 Cisco Systems Category: Informational Y. Rekhter Cisco Systems January 1998 Scalable Support for Multi-homed Multi-provider Connectivity Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. 2. Abstract This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. 3. Motivations An enterprise may acquire its Internet connectivity from more than one Internet Service Provider (ISP) for some of the following reasons. Maintaining connectivity via more than one ISP could be viewed as a way to make connectivity to the Internet more reliable. This way when connectivity through one of the ISPs fails, connectivity via the other ISP(s) would enable the enterprise to preserve its connectivity to the Internet. In addition to providing more reliable connectivity, maintaining connectivity via more than one ISP could also allow the enterprise to distribute load among multiple connections. For enterprises that span wide geographical area this could also enable better (more optimal) routing. The above considerations, combined with the decreasing prices for the Internet connectivity, motivate more and more enterprises to become multi-homed to multiple ISPs. At the same time, the routing overhead that such enterprises impose on the Internet routing system becomes more and more significant. Scaling the Internet, and being able to support a growing number of such enterprises demands mechanism(s) to contain this overhead. This document assumes that an approach where routers in the "default-free" zone of the Internet would be required Bates & Rekhter Informational [Page 1] RFC 2260 Multihoming January 1998 to maintain a route for every multi-homed enterprise that is connected to multiple ISPs does not provide an adequate scaling. Moreover, given the nature of the Internet, this document assumes that any approach to handle routing for such enterprises should minimize the amount of coordination among ISPs, and especially the ISPs that are not directly connected to these enterprises. There is a difference of opinions on whether the driving factors behind multi-homing to multiple ISPs could be adequately addressed by multi-homing just to a single ISP, which would in turn eliminate the negative impact of multi-homing on the Internet routing system. Discussion of this topic is beyond the scope of this document. The focus of this document is on the routing and addressing strategies that could reduce the routing overhead due to multi-homed enterprises connected to multiple ISPs in the Internet routing system. The strategies described in this document are equally applicable to both IPv4 and IPv6. 4. Address allocation and assignment A multi-homed enterprise connected to a set of ISPs would be allocated a block of addresses (address prefix) by each of these ISPs (an enterprise connected to N ISPs would get N different blocks). The address allocation from the ISPs to the enterprise would be based on the "address-lending" policy [RFC2008]. The allocated addresses then would be used for address assignment within the enterprise. One possible address assignment plan that the enterprise could employ is to use the topological proximity of a node (host) to a particular ISP (to the interconnect between the enterprise and the ISP) as a criteria for selecting which of the address prefixes to use for address assignment to the node. A particular node (host) may be assigned address(es) out of a single prefix, or may have addresses from different prefixes. 5. Routing information exchange The issue of routing information exchange between an enterprise and its ISPs is decomposed into the following components: a) reachability information that an enterprise border router advertises to a border router within an ISP b) reachability information that a border router within an ISP advertises to an enterprise border router Bates & Rekhter Informational [Page 2] RFC 2260 Multihoming January 1998 The primary focus of this document is on (a); (b) is covered only asShow full document text