rfc1863.txt

xorp源码hg

Network Working Group                                          D. Haskin
Request For Comments: 1863                                   Intel Corp.
Category: Experimental                                      October 1995


       A BGP/IDRP Route Server alternative to a full mesh routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document describes the use and detailed design of Route Servers
   for dissemination of routing information among BGP/IDRP speaking
   routers.

   The intention of the proposed technique is to reduce overhead and
   management complexity of maintaining numerous direct BGP/IDRP
   sessions which otherwise might be required or desired among routers
   within a single routing domain as well as among routers in different
   domains that are connected to a common switched fabric (e.g. an ATM
   cloud).

1. Overview

   Current deployments of Exterior Routing protocols, such as the Border
   Gateway Protocol [BGP4] and the adaptation of the ISO Inter-Domain
   Routing Protocol [IDRP], require that all BGP/IDRP routers, which
   participate in inter-domain routing (border routers) and belong to
   the same routing domain, establish a full mesh connectivity with each
   other for purpose of exchanging routing information acquired from
   other routing domains. In large routing domains the number of intra-
   domain connections that needs to be maintained by each border route
   can be significant.

   In addition, it may be desired for a border router to establish
   routing sessions with all border routers in other domains which are
   reachable via a shared communication media. We refer to routers that
   are directly reachable via a shared media as adjacent routers.  Such
   direct peering allows a router to acquire "first hand" information
   about destinations which are directly reachable through adjacent
   routers and select the optimum direct paths to these destinations.
   Establishment of BGP/IDRP sessions among all adjacent border routers
   would result in a full mesh routing connectivity.  Unfortunately for



Haskin                        Experimental                      [Page 1]

RFC 1863                A BGP/IDRP Route Server             October 1995


   a switched media as ATM, SMDS or Frame Relay network which may
   inter-connect a large number of routers,  due to the number of
   connections that would be needed to maintain a full mesh direct
   peering between the routers,  makes this approach impractical.

   In order to alleviate the "full mesh" problem, this paper proposes to
   use IDRP/BGP Route Servers which would relay external routes with all
   of their attributes between client routers. The clients would
   maintain IDRP/BGP sessions only with the assigned route servers
   (sessions with more than one server would be needed if redundancy is
   desired).  All routes that are received from a client router would be
   propagated to other clients by the Route Server.  Since all external
   routes and their attributes are relayed unmodified between the client
   routers, the client routers would acquire the same routing
   information as they would via direct peering.  We refer to such
   arrangement as virtual peering.  Virtual peering allows client
   routers independently apply selection criteria to the acquired
   external routes according to their local policies as they would if a
   direct peering were established.

   The routing approach described in this paper assumes that border
   routers possess a mechanism to resolve the media access address of
   the next hop router for any route acquired from a virtual peer.

   It is fair to note that the approach presented in this paper only
   reduces the number of routing connection each border router needs to
   maintain. It does not reduce the volume of routing information that
   needs to maintained at each border router.

   Besides addressing the "full mesh" problems,  the proposal attempts
   to achieve the following goals:

   - to minimize BGP/IDRP changes that need to be implemented in client
     routers in order to inter-operate with route servers;

   - to provide for redundancy of distribution of routing information to
     route server clients;

   - to minimize the amount of routing updates that have to be sent to
     route server clients;

   - to provide load distribution between route servers;

   - to avoid an excessive complexity of the interactions between Route
     Servers themselves.






Haskin                        Experimental                      [Page 2]

RFC 1863                A BGP/IDRP Route Server             October 1995


2. Terms And Acronyms

   The following terms and acronyms are used in this paper:

  Routing Domain     -  a collection of routers with the same set of
                        routing policies.  For IPv4 it can be identified
                        with an Autonomous System Number, for IPv6
                        it can be identified with a Routing Domain
                        Identifier.

  Border Router (BR) -  a router that acquires external routes, i.e.
                        routes to internet points outside its routing
                        domain.

  Route Server (RS)  -  a process that collects routing information
                        from border routers and distributes this
                        information to 'client routers'.

  RS Client (RC)     -  a router than peers with an RS in order to
                        acquire routing information.  A server's client
                        can be a router or another route server.

  RS Cluster (RSC)   -  two or more of route servers that share the same
                        subset of clients.  A RS Cluster provides
                        redundancy of routing information to its
                        clients,  i.e. routing information is provided
                        to all RS Cluster clients as long as there is
                        at least one functional route server in the RS
                        Cluster.

  RCID             -    Cluster ID

3. RS Model

   In the proposed scheme a Route Server (RS) does not apply any
   selection criteria to the routes received from border routers for the
   purpose of distributing these routes to its clients.  All routes
   acquired from border routers or other Route Servers are relayed to
   the client border routers.

   There can be two classes of Route Servers: Route Servers that relay
   external routes between routers in a single routing domain and Route
   Servers that relay external routes between border routers in
   different routing domains.  The former are Intra-Domain Route Servers
   and the latter are Inter-Domain Route Servers.

   In the RS model proposed in this document there is no routing
   exchange between Intra-Domain Route Servers and Inter-Domain Route



Haskin                        Experimental                      [Page 3]

RFC 1863                A BGP/IDRP Route Server             October 1995


   Servers.  Routes that cross a domain boundary must always pass
   through a border router of such a domain which may apply
   administrative filters to such routes.

   Operations of Intra-Domain Route Servers and Inter-Domain Route
   Servers are identical.

   One or more Route Servers form an RS Cluster (RSC).  For redundancy's
   sake two or more RSs can be configured to operate in an RS Cluster.
   All route servers in an RSC share the same clients,  i.e. cluster
   clients establish connections to all route servers in such an RSC for
   the purpose of exchanging routing information. Each cluster is
   assigned an unique RSC Identifier (RCID) represented by a 2-octet
   unsigned integer.

   Clusters which provide virtual connectivity between their clients
   would be normally exchanging routing information among themselves so
   that all external routes are propagated to all participating clients.

   Though a Route Server Client (RC) can be associated with multiple
   RSC, it seems that there is no real advantage of doing so except for
   a short transition period to provide a graceful re-assignment from
   one RSC to another or, if for some reason, there are multiple RS
   groups that don't exchange routing information with each other.

   The inter-cluster route exchange can be accomplished by forming a
   full mesh routing adjacency between clusters.  In this approach,
   illustrated in the diagram below,  each RS in each RSC would maintain
   a routing connection with every RS in other RS clusters.  Only routes
   that are acquired from border routers are propagated to RSs in other
   RS clusters.

         BR11   BR12   BR1n     BR21  BR22  BR2n
           |     |  ... |        |     | ...  |
          -----------------     ------------------
          !  RS11  RS12   ! --- !  RS21    RS22  !
          -----------------     ------------------
               <RSC#1>  \           /    <RSC#2>
                         \         /
                       -----------------
                       !  RS31  RS32   !   <RSC#3>
                       -----------------
                         |     | ... |
                        BR31  BR32  BR3n

   Another way to propagate routing information between clusters would
   be to form a cluster hierarchy in which an RS in one cluster
   maintains sessions only with RSs in designated clusters.  In this



Haskin                        Experimental                      [Page 4]

RFC 1863                A BGP/IDRP Route Server             October 1995


   approach an RS must advertise all acquired routes to an RS in another
   cluster except the routes that are acquired from that cluster.
   Nevertheless,  it allows for minimizing the number of routing
   sessions which can be highly desirable in some network.  It is
   important for the hierarchical scheme that the inter-cluster route
   exchange links form a tree, i.e. there is only one route propagation
   path between any two clusters, otherwise routing loops may result.
   For detection and pruning of routing loops in a hierarchical cluster
   topology, it is advisable to include the "RCID Path" attribute (see
   4.3.4) in all routing updates sent between route servers. This
   attribute lists IDs of all clusters in the route propagation path.
   When a duplicate ID is detected in this attribute an offending route
   needs to be discarded.

   The diagram below which illustrates the hierarchical approach is
   created from the diagram above by removing the route exchange link
   between clusters 2 and 3.

         BR11   BR12   BR1n     BR21  BR22  BR2n
           |     |  ... |        |     | ...  |
          -----------------     ------------------
          !  RS11  RS12   ! --- !  RS21    RS22  !
          -----------------     ------------------
               <RSC#1>  \                <RSC#2>
                         \
                       -----------------
                       !  RS31  RS32   !   <RSC#3>
                       -----------------
                         |     | ... |
                        BR31  BR32  BR3n

   It seems that the only disadvantage of the hierarchical model, is the
   management headache of avoiding routing loops and redundant
   information flow by insuring that inter-cluster links always form a
   tree.  But more study is needed to fully evaluate the comparative
   merits of the full-mesh and hierarchical models.

   Since RSs in the same cluster maintain routing sessions with the same
   set of clients, it may seem that there is no need to exchange routing
   information between RSs in the same cluster. Nevertheless, such a
   route exchange may help to maintain identical routing databases in
   the servers during client acquisition periods and when a partial
   failure may affect some routing sessions.

   Route servers in the same RS cluster exchange control messages in
   attempt to subdivide the responsibilities of providing routing
   information to their clients.  In order to simplify the RS design,
   the RS messaging is implemented on top of exterior protocol which is



Haskin                        Experimental                      [Page 5]

RFC 1863                A BGP/IDRP Route Server             October 1995


   used by route servers for the routing information exchange.

4. Operation

4.1 ADVERTISER Path Attribute

   Route servers act as concentrators for routes acquired by border
   routers so that the border routers need to maintain routing
   connections with only one or two designated route servers.  Route
   Servers distribute routing information that is provided to them by
   the border routers to all their client.

   If routing information were relayed to RS clients in UPDATE messages
   with only those path attribute that are currently defined in the