rfc1863.txt

xorp源码hg

   BGP-4/IDRP specification, the RS clients would not be able to
   associate external routes they receive with the border routers which
   submitted that routes to route servers. Such an association is
   necessary for making a correct route selection decision. Therefore,
   the new path attribute, ADVERTISER, is defined.

   The ADVERTISER is an optional non-transitive attribute that defines
   the identifying address of the border router which originally
   submitted the route to a router server in order for it to be relayed
   to other RS clients. Type Code of the ADVERTISER attribute is 255.
   This attribute must be included in every UPDATE message that is
   relayed by route servers and must be recognized by RS clients.

4.2 Route Client Operation

   An RS client establishes an BGP/IDRP connection to every route server
   in the RS cluster to which the route client is assigned.

   RS clients must be able to recognize the ADVERTISER path attribute
   that is included in all UPDATE messages received from route servers.
   Routes received in UPDATE messages from route servers are processed
   as if they were received directly from the border routers specified
   in the ADVERTISER attributes of the respective updates.

   If an RS client receives a route from a Intra-Domain Route Server, is
   assumed that the border router identified in the ADVERTISER attribute
   is located in the receiving client's own routing domain.

   If an RS client receives a route from a Inter-Domain Route Server,
   the locality of the border router identified in the ADVERTISER
   attribute can be determined from the BGP's AS_PATH attribute or
   IDRP's RD_PATH attribute respectively.





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


   If no ADVERTISER attribute was included in an UPDATE message from a
   route server it is assumed that the route server itself is the
   advertiser of the corresponding route.

   If the NEXT_HOP path attribute of an UPDATE message lists an address
   of the receiving router itself, the route that is carried in such an
   update message must be declared unreachable.

   In addition, it is highly desirable, albeit not required,  to
   slightly modify the "standard" BGP/IDRP operation when acquiring
   routes from RSs:

    when a route is received from an RS and a route with the completely
    identical attributes has been previously acquired from another RS
    in the same cluster,  the previously acquired route should be
    replaced with the newly acquired route.  Such a route replacement
    should not trigger any route advertisement action on behalf of the
    route.

   RSs are designed to operate in such a way that eliminates the need to
   keep multiple copies of the same route by RS clients and minimizes
   the possibility of a route flap when the BGP/IDRP connection to one
   of the redundant route servers is lost.

   It is attempted to subdivide the route dissemination load between
   route servers such that only one RS provides routing updates to a
   given client.  But since, for avoiding an excessive complexity, the
   reconciliation algorithm does not eliminate completely the
   possibility of races, it is still possible that a client may receive
   updates from more than one route server.  Therefore, the client's
   ability to discard duplicate routes may reduce the need for a bigger
   routing database.

4.3 Route Server Operation

   A Route Server maintains BGP-4/IDRP sessions with its clients
   according to the respective BGP-4/IDRP specification with exception
   of protocol modifications outlined in this document.

   UPDATE messages sent by route servers have the same format and
   semantics as it respective BGP-4/IDRP counterparts but also carry the
   ADVERTISER path attribute which specifies the BGP Identifier of the
   border router that submitted the route advertised in the UPDATE
   message. In addition, if the hierarchical model is deployed to
   interconnect Route Server clusters, it is advisable to include the
   "RCID Path" attribute in all routing updates sent between route
   servers as described in 4.3.4.




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


   When route servers exchange OPEN messages they include the Route
   Server protocol version (current version is 1) as well as Cluster IDs
   of their respective clusters in an Optional Parameter of the OPEN
   message. The value of Parameter Type for this parameter is 255. The
   length of the parameter data is 3 octets. The format of parameter
   data is shown below:

    +-----------------------+------------------------------------+
    | Version = 1 (1 octet) |      Cluster ID (2 octets)         |
    +-----------------------+------------------------------------+

   Also, route servers that belong to the same cluster send to each
   other LIST messages with lists of clients to which they're providing
   routing information.  In the LIST message an RS specifies the Router
   Identifier of each client to which that RS is providing routing
   updates. Since LIST messages are relatively small there is no need to
   add a processing complexity of generating incremental updates when a
   list changes; instead the complete list is sent when RSs need to be
   informed of the changes.  The format of the LIST message is presented
   in 4.3.1.

4.3.1 LIST Message Format

   The LIST message contains the fixed BGP/IDRP header that is followed
   with the fields shown below.  The type code in the fixed header of
   the LIST message is 255.

     +----------+----------+----------+----------+
     |        Client Identifying Address         | Repeated for each
     +-------------------------------------------+ informed client
   The number of Client Identifying Address" fields is not encoded
   explicitly,  but can be calculated as:

     (<LIST message Length> - <Header Length>) / <Address Length>,

   where <LIST message Length> is the value encoded in the fixed
   BGP/IDRP header, <Header Length> is the length of that header, and
   <Address Length> is 4 for IPv4 and 16 for IPv6.

4.3.2 External Route Acquisition And Advertisement

   A route server acquires external routes from RS clients that are also
   border routers.  A RS also may acquire external routes from other
   RSs.  Route servers relay all acquired routes unaltered to their
   clients.  No route selection is performed for purpose of route re-
   advertisement to RS clients.





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


   While route servers receive and store routing data from all their
   client,  Routing Servers in the same cluster coordinate their route
   advertisement in the attempt to ensure that only one RS provides
   routing updates to a given client.  If an RS fails,  other Route
   Servers in the cluster take over the responsibility of providing
   routing updates to the clients that were previously served by the
   failed RS.  A route flap that can result from such switch-over can be
   eliminated by the configuring client's "Hold Time" of their BGP-
   4/IDRP sessions with the route servers to be larger than the switch-
   over time.  The switch-over time is determined by the Hold Time of
   BGP-4/IDRP sessions between the route servers in the cluster and the
   period that is needed for that route servers to reconcile their route
   advertisement responsibilities.  The reconciliation protocol is
   described in 4.3.3.

   The BGP-4/IDRP operations of route servers differs from the
   "standard" operation in the following ways:

   -    when receiving routes from another RS, the RS Client mode of
        operation is assumed, i.e., when a route with completely
        identical attributes has been previously acquired from an RS
        belonging to the same cluster as the RS that advertises the new
        route, the previously acquired route should be discarded and
        the newly acquired route should be accepted.  Such a route
        replacement should not trigger any route advertisement action
        on behalf of the route.

   -    all acquired routes are advertised to a client router except
        routes which were acquired from that client (no route echoing);

   -    if the hierarchical model of inter-cluster route exchange is
        used,  all acquired routes are advertised to an RS in another
        RSC except routes that are acquired from that RSC.  In the
        full-mesh model, only routes which are acquired from border
        routers are advertised to route servers in other clusters;

   -    if route servers in the same RS cluster are configured to
        exchange routing information,  only external routes that are
        acquired from border routers are advertised to route servers in
        the local cluster;

   -    the ADVERTISER path attribute is included in every UPDATE
        messages that is generated by RS.  This attribute must
        specify the identifying address of the border router from which
        information provided in UPDATE has been acquired.  All other
        routing attributes should be relayed to RS's peers unaltered.





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


   -    when a route advertised by to an RS by a client becomes
        unreachable such a route needs to be declared unreachable to
        all other clients.  In order to withdraw a route,  the route
        server sends an UPDATE for that route to each client (except
        the client that this route was originally acquired) with the
        NEXT_HOP path attribute set to the address of the client to
        which this UPDATE is sent to.  The the ADVERTISER path attribute
        with the identifying address of the border router that
        originally advertised the withdrawn route must be also included
        in such an update message.

   -    if the hierarchical model is deployed to interconnect Route
        Server clusters,  it is advisable to include the RCID_PATH
        attribute in all routing updates sent between route servers as
        described in 4.3.4.  The RCID_PATH attribute is never included
        in UPDATE messages sent to border routers.

4.3.3 Intra-Cluster Coordination

   In order to coordinate route advertisement activities,  route servers
   which are members of the same RS cluster establish and maintain
   BGP/IDRP connections between themselves forming a full-mesh
   connectivity.  Normally, there is no need for more than two-three
   route servers in one cluster.

   Route servers belonging to the same cluster send to each other LIST
   messages with lists of clients to which they're providing routing
   information;  let's call such clients "informed clients".

   Each RS maintains a separate "informed client" list for each RS in
   the local cluster including itself.  All such lists are linked in an
   ascending order that is determined by the number of clients in each
   list; the order among the lists with the same number of clients is
   determined by comparing the identifying addresses of the
   corresponding RSs -- an RS in such a "same number of clients" subset
   is positioned after all RSs with the lower address.

   An RS can be in one of two RS coordination states: 'Initiation' and
   'Active'.

4.3.3.1 Initiation State

   This is the initial state of route server that is entered upon RS
   startup.  When the Initiation state is entered the 'InitiationTimer'
   is started.  The Initiation state transits to the Active state upon
   expiration of the 'InitiationTimer' or as soon as all configured
   BGP/IDRP connections to other route servers in the local RS Cluster
   are established and LIST messages from that route servers are



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


   received.

   In the Initiation state an RS:

    o   tries to establish connections with other RSs in the local and
        remote clusters.

    o   accepts BGP/IDRP connections from client routers.

    o   receives and process BGP/IDRP updates but doesn't send any
        routing updates.

    o   stores "informed client" lists received from other RSs in the
        local cluster - a newly received list replaces the existing list
        for the same RS. If a LIST message is received from the route
        server in another RS cluster, it should be silently ignored.

    o   initializes an empty "informed client" list for its own clients.
    o   as soon as a BGP/IDRP connection to an RS in the same RS Cluster
        is established, transmits an empty LIST message to such an RS.

4.3.3.2 Active State

This state is entered upon expiration of the 'InitiationTimer' or as
soon as all configured BGP/IDRP connections to other route servers in
the local RS Cluster are established and LIST messages from that route
servers are received.

In the Active state an RS:

    o   continues attempts to establish connections with other route
        servers in the local and remote clusters;

    o   accepts new BGP/IDRP connections;