As per Relevance of the word approach, we have this rfc below:
Network Working Group T.
Request for Comments: 2260 Cisco
Category: Informational Y.
Cisco
January 1998
Scalable Support for Multi-homed Multi-provider
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
2.
This document describes addressing and routing strategies for multi
homed enterprises attached to multiple Internet Service
(ISPs) that are intended to reduce the routing overhead due to
enterprises in the global Internet routing system
3.
An enterprise may acquire its Internet connectivity from more
one Internet Service Provider (ISP) for some of the
reasons. Maintaining connectivity via more than one ISP could
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
preserve its connectivity to the Internet. In addition to
more reliable connectivity, maintaining connectivity via more
one ISP could also allow the enterprise to distribute load
multiple connections. For enterprises that span wide
area this could also enable better (more optimal) routing
The above considerations, combined with the decreasing prices for
Internet connectivity, motivate more and more enterprises to
multi-homed to multiple ISPs. At the same time, the routing
that such enterprises impose on the Internet routing system
more and more significant. Scaling the Internet, and being able
support a growing number of such enterprises demands mechanism(s)
contain this overhead. This document assumes that an approach
routers in the "default-free" zone of the Internet would be
Bates & Rekhter Informational [Page 1]
RFC 2260 Multihoming January 1998
to maintain a route for every multi-homed enterprise that
connected to multiple ISPs does not provide an adequate scaling
Moreover, given the nature of the Internet, this document
that any approach to handle routing for such enterprises
minimize the amount of coordination among ISPs, and especially
ISPs that are not directly connected to these enterprises
There is a difference of opinions on whether the driving
behind multi-homing to multiple ISPs could be adequately addressed
multi-homing just to a single ISP, which would in turn eliminate
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
strategies that could reduce the routing overhead due to multi-
enterprises connected to multiple ISPs in the Internet
system
The strategies described in this document are equally applicable
both IPv4 and IPv6.
4. Address allocation and
A multi-homed enterprise connected to a set of ISPs would
allocated a block of addresses (address prefix) by each of these
(an enterprise connected to N ISPs would get N different blocks).
The address allocation from the ISPs to the enterprise would be
on the "address-lending" policy [RFC2008]. The allocated
then would be used for address assignment within the enterprise
One possible address assignment plan that the enterprise could
is to use the topological proximity of a node (host) to a
ISP (to the interconnect between the enterprise and the ISP) as
criteria for selecting which of the address prefixes to use
address assignment to the node. A particular node (host) may
assigned address(es) out of a single prefix, or may have
from different prefixes
5. Routing information
The issue of routing information exchange between an enterprise
its ISPs is decomposed into the following components
a) reachability information that an enterprise border
advertises to a border router within an
b) reachability information that a border router within an
advertises to an enterprise border
Bates & Rekhter Informational [Page 2]
RFC 2260 Multihoming January 1998
The primary focus of this document is on (a); (b) is covered only
needed by this document
5.1. Advertising reachability information by enterprise border
When an enterprise border router connected to a particular
determines that the connectivity between the enterprise and
Internet is up through all of its ISPs, the router advertises (to
border router of that ISP) reachability to only the address
that the ISP allocated to the enterprise. This way in a steady
routes injected by the enterprise into its ISPs are aggregated
these ISPs, and are not propagated into the "default-free" zone
the Internet
When an enterprise border router connected to a particular
detemrines that the connectivity between the enterprise and
Internet through one or more of its other ISPs is down, the
starts advertising reachability to the address prefixes that
allocated by these ISPs to the enterprise. This would result
injecting additional routing information into the "default-free"
of the Internet. However, one could observe that the probability
all multi-homed enterprises in the Internet concurrently
connectivity to the Internet through one or more of their ISPs
fairly small. Thus on average the number of additional routes in
"default-free" zone of the Internet due to multi-homed enterprises
expected to be a small fraction of the total number of
enterprises
The approach described above is predicated on the assumption that
enterprise border router has a mechanism(s) by which it
determine (a) whether the connectivity to the Internet through
other border router of that enterprise is up or down, and (b)
address prefix that was allocated to the enterprise by the
connected to the other border router. One such possible
could be provided by BGP [RFC1771]. In this case border
within the enterprise would have an IBGP peering with each other
Whenever one border router determines that the intersection
the set of reachable destinations it receives via its EBGP (from
directly connected ISP) peerings and the set of
destinations it receives from another border router (in the
enterprise) via IBGP is empty, the border router would
advertising to its external peer reachability to the address
that was allocated to the enterprise by the ISP connected to
other border router. The other border router would advertise (
IBGP) the address prefix that was allocated to the enterprise by
ISP connected to that router. This approach is known as "auto
injection".
Bates & Rekhter Informational [Page 3]
RFC 2260 Multihoming January 1998
As an illustration consider an enterprise connected to two ISPs
ISP-A and ISP-B. Denote the enterprise border router that
the enterprise to ISP-A as BR-A; denote the enterprise border
that connects the enterprise to ISP-B as BR-B. Denote the
prefix that ISP-A allocated to the enterprise as Pref-A; denote
address prefix that ISP-B allocated to the enterprise as Pref-B
When the set of routes BR-A receives from ISP-A (via EBGP) has
non-empty intersection with the set of routes BR-A receives from BR-
(via IBGP), BR-A advertises to ISP-A only the reachability to Pref-A
When the intersection becomes empty, BR-A would advertise to ISP-
reachability to both Pref-A and Pref-B. This would continue for
long as the intersection remains empty. Once the intersection
non-empty, BR-A would stop advertising reachability to Pref-B
ISP-A (but would still continue to advertise reachability to Pref-
to ISP-A). Figure 1 below describes this method graphically
+-------+ +-------+ +-------+ +-------+
( ) ( ) ( ) ( )
( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B )
( ) ( ) ( ) ( )
+-------+ +-------+ +-------+ +-------+
| /\ | /\ | /\ |
| || | || | Pref-A (
| Pref-A | Pref-B | Pref-B broken
| || | || | || |
+-----+ +-----+ +-----+ +-----+
| BR-A|------|BR-B | | BR-A|------|BR-B |
+-----+ IBGP +-----+ +-----+ IBGP +-----+
non-empty intersection empty
Figure 1: Reachability information
Although strictly an implementation detail, calculating
intersection could potentially be a costly operation for a large
of routes. An alternate solution to this is to make use of a
single (or more) address prefix received from an ISP (the ISP'
backbone route for example) and configure the enterprise
router to perform auto route injection if the selected prefix is
present via IBGP. Let's suppose ISP-B has a well known
prefix, ISP-Pref-B for its backbone. ISP-B advertises this to BR-
and BR-B in turn advertises this via IBGP to BR-A. If BR-A sees
withdraw for ISP-Pref-B it advertises Pref-B to ISP-A
Bates & Rekhter Informational [Page 4]
RFC 2260 Multihoming January 1998
The approach described in this section may produce less than the
Internet-wide connectivity in the presence of ISPs that filter
routes based on the length of their address prefixes. One
observe however, that this would be a problem regardless of how
enterprise would set up its routing and addressing
5.2. Further
The approach described in the previous section allows
significantly reduce the routing overhead in the "default-free"
of the Internet due to multi-homed enterprises. The
described in this section allows to completely eliminate
overhead
An enterprise border router would maintain EBGP peering not just
the directly connected border router of an ISP, but with the
router(s) in one or more ISPs that have their border routers
connected to the other border routers within the enterprise.
refer to such peering as "non-direct" EBGP
An ISP that maintains both direct and non-direct EBGP peering with
particular enterprise would advertise the same set of routes
both of these peerings. An enterprise border router that
either direct or non-direct peering with an ISP advertises to
ISP reachability to the address prefix that was allocated by that
to the enterprise. Within the ISP routes received over
peering should be preferred over routes received over non-
peering. Likewise, within the enterprise routes received over
peering should be preferred over routes received over non-
peering
Forwarding along a route received over non-direct peering should
accomplished via encapsulation [RFC1773].
As an illustration consider an enterprise connected to two ISPs
ISP-A and ISP-B. Denote the enterprise border router that
the enterprise to ISP-A as E-BR-A, and the ISP-A border router
is connected to E-BR-A as ISP-BR-A; denote the enterprise
router that connects the enterprise to ISP-B as E-BR-B, and the ISP-
border router that is connected to E-BR-B as ISP-BR-B. Denote
address prefix that ISP-A allocated to the enterprise as Pref-A
denote the address prefix that ISP-B allocated to the enterprise
Pref-B. E-BR-A maintains direct EBGP peering with ISP-BR-A
advertises reachability to Pref-A over that peering. E-BR-A
maintain a non-direct EBGP peering with ISP-BR-B and
reachability to Pref-B over that peering. E-BR-B maintains
EBGP peering with ISP-BR-B, and advertises reachability to Pref-
over that peering. E-BR-B also maintains a non-direct EBGP
Bates & Rekhter Informational [Page 5]
RFC 2260 Multihoming January 1998
with ISP-BR-A, and advertises reachability to Pref-A over
peering
When connectivity between the enterprise and both of its ISPs (ISP-
and ISP-B is up, traffic destined to hosts whose addresses
assigned out of Pref-A would flow through ISP-A to ISP-BR-A to E-BR
A, and then into the enterprise. Likewise, traffic destined to
whose addresses were assigned out of Pref-B would flow through ISP-
to ISP-BR-B to E-BR-B, and then into the enterprise. Now
what would happen when connectivity between ISP-BR-B and E-BR-B
down. In this case traffic to hosts whose addresses were
out of Pref-A would be handled as before. But traffic to hosts
addresses were assigned out of Pref-B would flow through ISP-B
ISP-BR-B, ISP-BR-B would encapsulate this traffic and send it to E
BR-A, where the traffic will get decapsulated and then be sent
the enterprise. Figure 2 below describes this approach graphically
+---------+ +---------+
( ) ( )
( ISP-A ) ( ISP-B )
( ) ( )
+---------+ +---------+
| |
+--------+ +--------+
|ISP-BR-A| |ISP-BR-B
+--------+ +--------+
| /+/ |
/\ | Pref-B /+/ |
|| | /+/ \./
Pref-A| /+/ non- /.\
|| | /+/ direct |
| /+/ EBGP |
+------+ +-------+
|E-BR-A|-----------|E-BR-B |
+------+ IBGP +-------+
Figure 2: Reachability information advertised via non-direct
Observe that with this scheme there is no additional
information due to multi-homed enterprises that has to be carried
the "default-free" zone of the Internet. In addition this
doesn't degrade in the presence of ISPs that filter out routes
on the length of their address prefixes
Note that the set of routers within an ISP that maintain non-
peering with the border routers within an enterprise doesn't have
be restricted to the ISP's border routers that have direct
Bates & Rekhter Informational [Page 6]
RFC 2260 Multihoming January 1998
with the enterprise's border routers. The non-direct peering could
maintained with any router within the ISP. Doing this could
the overall robustness in the presence of failures within the ISP
5.3. Combining the
One could observe that while the approach described in Section 5.2
allows to completely eliminate the routing overhead due to multi
homed enterprises in the "default-free" zone of the Internet, it
result in a suboptimal routing in the presence of link failures.
sub-optimality could be reduced by combining the approach
in Section 5.2 with a slightly modified version of the
described in Section 5.1. The modification consists of
the scope of propagation of additional routes that are advertised
an enterprise border router when the router detects problems with
Internet connectivity through its other border routers. A way
constrain the scope is by using the BGP Community
[RFC1997].
5.4. Better (more optimal) routing in steady
The approach described in this document assumes that in a
state an enterprise border router would advertise to a
connected ISP border router only the reachability to the
prefix that this ISP allocated to the enterprise. As a result
traffic originated by other enterprises connected to that ISP
destined to the parts of the enterprise numbered out of other
prefixes would not enter the enterprise at this border router
resulting in potentially suboptimal paths. To improve the
the border router may (in steady state) advertise reachability
only to the address prefix that was allocated by the ISP that
router is directly connected to, but to the address
allocated by some other ISPs (directly connected to some other
routers within the enterprise). Distribution of such
should be carefully constrained, or otherwise this may result
significant additional routing information that would need to
maintained in the "default-free" part of the Internet. A way
constrain the distribution of such advertisements is by using the
Community attribute [RFC1997].
6. Comparison with other
CIDR [RFC1518] proposes several possible address
strategies for multi-homed enterprises that are connected to
ISPs. The following briefly reviews the alternatives being
today, and compares them with the approaches described above
Bates & Rekhter Informational [Page 7]
RFC 2260 Multihoming January 1998
6.1. Solution 1
One possible solution suggested in [RFC1518] is for each multi-
enterprise to obtain its IP address space independently from the
to which it is attached. This allows each multi-homed enterprise
base its IP assignments on a single prefix, and to thereby
the set of all IP addresses reachable within that enterprise via
single prefix. The disadvantage of this approach is that since
IP address for that enterprise has no relationship to the
of any particular ISPs, the reachability information advertised
the enterprise is not aggregatable with any, but default route
results in the routing overhead in the "default-free" zone of
Internet of O(N), where N is the total number of multi-
enterprises across the whole Internet that are connected to
ISPs
As a result, this approach can't be viewed as a viable
for all, but the enterprises that provide high enough degree
addressing information aggregation. Since by definition the number
such enterprises is likely to be fairly small, this approach isn'
viable for most of the multi-homed enterprises connected to
ISPs
6.2. Solution 2
Another possible solution suggested in [RFC1518] is to assign
multi-homed enterprise a single address prefix, based on one of
connections to one of its ISPs. Other ISPs to which the multi-
enterprise is attached maintain a routing table entry for
organization, but are extremely selective in terms of which
ISPs are told of this route and would need to perform "proxy
aggregation. Most of the complexity associated with this approach
due to the need to perform "proxy" aggregation, which in
requires t addiional inter-ISP coordination and more complex
configuration
7.
The approach described in this document assumes that addresses
an enterprise would use are allocated based on the "address lending
policy. Consequently, whenever an enterprise changes its ISP,
enterprise would need to renumber part of its network that
numbered out of the address block that the ISP allocated to
enterprise. However, these issues are not specific to
and should be considered accepted practice in todays internet.
approach described in this document effectively eliminates
distinction between single-home and multi-homed enterprise
respect to the impact of changing ISPs on renumbering
Bates & Rekhter Informational [Page 8]
RFC 2260 Multihoming January 1998
The approach described in this document also requires careful
assignment within an enterprise, as address assignment
traffic distribution among multiple connections between an
and its ISPs
Both the issue of address assignment and renumbering could
addressed by the appropriate use of network address
(NAT). The use of NAT for multi-homed enterprises is the beyond
scope of this document
Use of auto route injection (as described in Section 5.1)
the number of routers in the default-free zone of the Internet
could be affected by changes in the connectivity of multi-
enterprises, as compared to the use of provider-independed
(as described in Section 6.1). Specifically, with auto
injection when a multi-homed enterprise loses its
through one of its ISPs, the auto injected route has to be
to all the routers in the default-free zone of the Internet.
contrast, when an enterprise uses provider-independent addresses
only some (but not all) of the routers in the default-free zone
see changes in routing when the enterprise loses its
through one of its ISPs
To supress excessive routing load due to link flapping the
injected route has to be advertised until the connectivity via
other connection (that was previously down and that triggered
route injection) becomes stable
Use of the non-direct EBGP approach (as described in Section 5.2)
allows to eliminate route flapping due to multi-homed enterprises
the default-free zone of the Internet. That is the non-direct
approach has better properties with respect to routing stability
the use of provider-independent addresses (as described in
6.1).
8. Applications to multi-homed
The approach described in this document could be applicable to
small to medium size ISP that is connected to several upstream ISPs
The ISP would acquire blocks of addresses (address prefixes) from
upstream ISPs, and would use these addresses for allocations to
customers. Either auto route injection, or the non-direct
approach, or a combination of both could be used by the ISP
peering with its upstream ISPs. Doing this would provide
for the customers of such ISP, without advertsely affecting
overall scalability of the Internet routing system
Bates & Rekhter Informational [Page 9]
RFC 2260 Multihoming January 1998
9. Security
Since the non-direct EBGP approach (as described in Section 5.2)
requires EBGP sessions between routers that are more than one IP
from each other, routers that maintain these sessions should use
appropriate authentication mechanism(s) for BGP peer authentication
Security issues related to the IBGP peering, as well as the
peering between routers that are one IP hop from each other
outside the scope of this document
10.
The authors of this document do not make any claims on
originality of the ideas described in this document. Anyone
thought about these ideas before should be given all due credit
11.
[RFC1518]
Rekhter, Y., and T. Li, "An Architecture for IP
Allocation with CIDR", RFC 1518, September 1993.
[RFC1771]
Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[RFC1773]
Hanks, S., Li, T., Farinacci, T., and P. Traina, "
Routing Encapsulation over IPv4 networks", RFC 1773,
1994.
[RFC1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J.,
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC1997]
Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute",
RFC 1997, August 1996.
[RFC2008]
Rekhter, Y., and T. Li, "Implications of Various
Allocation Policies for Internet Routing", BCP 7, RFC 2008,
October 1996.
Bates & Rekhter Informational [Page 10]
RFC 2260 Multihoming January 1998
12. Authors'
Tony
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134
EMail: tbates@cisco.
Yakov
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134
EMail: yakov@cisco.
Bates & Rekhter Informational [Page 11]
RFC 2260 Multihoming January 1998
13. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Bates & Rekhter Informational [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
