rfc2260.txt

中、英文RFC文档大全打包下载完全版 .

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 as
   needed by this document.

5.1. Advertising reachability information by enterprise border routers

   When an enterprise border router connected to a particular ISP
   determines that the connectivity between the enterprise and the
   Internet is up through all of its ISPs, the router advertises (to the
   border router of that ISP) reachability to only the address prefix
   that the ISP allocated to the enterprise. This way in a steady state
   routes injected by the enterprise into its ISPs are aggregated by
   these ISPs, and are not propagated into the "default-free" zone of
   the Internet.

   When an enterprise border router connected to a particular ISP
   detemrines that the connectivity between the enterprise and the
   Internet through one or more of its other ISPs is down, the router
   starts advertising reachability to the address prefixes that was
   allocated by these ISPs to the enterprise. This would result in
   injecting additional routing information into the "default-free" zone
   of the Internet. However, one could observe that the probability of
   all multi-homed enterprises in the Internet concurrently losing
   connectivity to the Internet through one or more of their ISPs is
   fairly small.  Thus on average the number of additional routes in the
   "default-free" zone of the Internet due to multi-homed enterprises is
   expected to be a small fraction of the total number of such
   enterprises.

   The approach described above is predicated on the assumption that an
   enterprise border router has a mechanism(s) by which it could
   determine (a) whether the connectivity to the Internet through some
   other border router of that enterprise is up or down, and (b) the
   address prefix that was allocated to the enterprise by the ISP
   connected to the other border router. One such possible mechanism
   could be provided by BGP [RFC1771]. In this case border routers
   within the enterprise would have an IBGP peering with each other.
   Whenever one border router determines that the intersection between
   the set of reachable destinations it receives via its EBGP (from its
   directly connected ISP) peerings and the set of reachable
   destinations it receives from another border router (in the same
   enterprise) via IBGP is empty, the border router would start
   advertising to its external peer reachability to the address prefix
   that was allocated to the enterprise by the ISP connected to the
   other border router. The other border router would advertise (via
   IBGP) the address prefix that was allocated to the enterprise by the
   ISP connected to that router. This approach is known as "auto route
   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 connects
   the enterprise to ISP-A as BR-A; denote the enterprise border router
   that connects the enterprise to ISP-B as BR-B. Denote the address
   prefix that ISP-A allocated to the enterprise as Pref-A; denote the
   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 a
   non-empty intersection with the set of routes BR-A receives from BR-B
   (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-A
   reachability to both Pref-A and Pref-B. This would continue for as
   long as the intersection remains empty. Once the intersection becomes
   non-empty, BR-A would stop advertising reachability to Pref-B to
   ISP-A (but would still continue to advertise reachability to Pref-A
   to ISP-A). Figure 1 below describes this method graphically.

        +-------+    +-------+         +-------+    +-------+
        (       )    (       )         (       )    (       )
        ( ISP-A )    ( ISP-B )         ( ISP-A )    ( ISP-B )
        (       )    (       )         (       )    (       )
        +-------+    +-------+         +-------+    +-------+
            |   /\       |   /\            |   /\       |
            |   ||       |   ||            | Pref-A  (connection
            | Pref-A     | Pref-B          | Pref-B    broken)
            |   ||       |   ||            |   ||       |
         +-----+      +-----+           +-----+      +-----+
         | BR-A|------|BR-B |           | BR-A|------|BR-B |
         +-----+ IBGP +-----+           +-----+ IBGP +-----+

          non-empty intersection         empty intersection


             Figure 1: Reachability information advertised

   Although strictly an implementation detail, calculating the
   intersection could potentially be a costly operation for a large set
   of routes. An alternate solution to this is to make use of a selected
   single (or more) address prefix received from an ISP (the ISP's
   backbone route for example) and configure the enterprise border
   router to perform auto route injection if the selected prefix is not
   present via IBGP. Let's suppose ISP-B has a well known address
   prefix, ISP-Pref-B for its backbone. ISP-B advertises this to BR-B
   and BR-B in turn advertises this via IBGP to BR-A. If BR-A sees a
   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 full
   Internet-wide connectivity in the presence of ISPs that filter out
   routes based on the length of their address prefixes. One could
   observe however, that this would be a problem regardless of how the
   enterprise would set up its routing and addressing.

5.2. Further improvements

   The approach described in the previous section allows to
   significantly reduce the routing overhead in the "default-free" zone
   of the Internet due to multi-homed enterprises. The approach
   described in this section allows to completely eliminate this
   overhead.

   An enterprise border router would maintain EBGP peering not just with
   the directly connected border router of an ISP, but with the border
   router(s) in one or more ISPs that have their border routers directly
   connected to the other border routers within the enterprise.  We
   refer to such peering as "non-direct" EBGP.

   An ISP that maintains both direct and non-direct EBGP peering with a
   particular enterprise would advertise the same set of routes over
   both of these peerings. An enterprise border router that maintains
   either direct or non-direct peering with an ISP advertises to that
   ISP reachability to the address prefix that was allocated by that ISP
   to the enterprise.  Within the ISP routes received over direct
   peering should be preferred over routes received over non-direct
   peering.  Likewise, within the enterprise routes received over direct
   peering should be preferred over routes received over non-direct
   peering.

   Forwarding along a route received over non-direct peering should be
   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 connects
   the enterprise to ISP-A as E-BR-A, and the ISP-A border router that
   is connected to E-BR-A as ISP-BR-A; denote the enterprise border
   router that connects the enterprise to ISP-B as E-BR-B, and the ISP-B
   border router that is connected to E-BR-B as ISP-BR-B. Denote the
   address prefix that ISP-A allocated to the enterprise as Pref-A;
   denote the address prefix that ISP-B allocated to the enterprise as
   Pref-B.  E-BR-A maintains direct EBGP peering with ISP-BR-A and
   advertises reachability to Pref-A over that peering. E-BR-A also
   maintain a non-direct EBGP peering with ISP-BR-B and advertises
   reachability to Pref-B over that peering. E-BR-B maintains direct
   EBGP peering with ISP-BR-B, and advertises reachability to Pref-B
   over that peering.  E-BR-B also maintains a non-direct EBGP peering



Bates & Rekhter              Informational                      [Page 5]

RFC 2260                      Multihoming                   January 1998


   with ISP-BR-A, and advertises reachability to Pref-A over that
   peering.

   When connectivity between the enterprise and both of its ISPs (ISP-A
   and ISP-B is up, traffic destined to hosts whose addresses were
   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 hosts
   whose addresses were assigned out of Pref-B would flow through ISP-B
   to ISP-BR-B to E-BR-B, and then into the enterprise. Now consider
   what would happen when connectivity between ISP-BR-B and E-BR-B goes
   down.  In this case traffic to hosts whose addresses were assigned
   out of Pref-A would be handled as before. But traffic to hosts whose
   addresses were assigned out of Pref-B would flow through ISP-B to
   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 into
   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 EBGP

   Observe that with this scheme there is no additional routing
   information due to multi-homed enterprises that has to be carried in
   the "default-free" zone of the Internet. In addition this scheme
   doesn't degrade in the presence of ISPs that filter out routes based
   on the length of their address prefixes.

   Note that the set of routers within an ISP that maintain non-direct
   peering with the border routers within an enterprise doesn't have to
   be restricted to the ISP's border routers that have direct peering



Bates & Rekhter              Informational                      [Page 6]