RFC 1863 (rfc1863) - Page 2 of 16

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

Alternative Format: Original Text Document


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

Web Standards & Support: