rfc1863.txt

xorp源码hg

    o   transmits a LIST message to an RS in the local cluster as soon
        as an BGP/IDRP session with the RS is established and then
        whenever the local "informed client" list changes;

    o   receives and process BGP/IDRP updates;

    o   receives and processes "informed client" lists as described
        below:

        a) If a LIST message is received from the route server in
           another RS cluster, it should be silently ignored.





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


        b) If a LIST message is received from a route server that
           belongs to the same RS Cluster,  the differences between
           the old and the new list are determined and the old "informed
           client" list for that RS is replaced by the list from the new
           message.  For each client that was in the old list but not in
           the new list it is checked whether the server has
           an established BGP/IDRP connection to that client and
           the client is not in any of the other "informed client"
           lists.  If both conditions are met,  the processing described
           for a new client takes place (see 4.3.3.3).

    o   for each new BGP/IDRP client (including connections established
        in Initiation state),  decides if that client should become an
        "informed client", i.e. whether routing updates are to be sent
        to the client or that client has been already taken care by
        another RS in the local cluster.  The decision process is
        described in the next section.

4.3.3.3 New Client Processing

   Whenever an RS acquires a new BGP/IDRP peer it scans through all
   "informed client" lists in order to determine if this peer has
   already been receiving routing updates from another RS in the local
   RS cluster.  If the identifying address of the peer is found in one
   of the list,  no routing updates are sent to that peer.

   If the peer's Router Id is not found,  the route server initiates a
   'DelayTimer' timer for that peer and the decision is postponed until
   that timer expires.  The delay value is calculated as followed:

      the RS determines the relative position of its own "informed
      client" list in the linked list of all "informed client" lists.
      If such position is expressed with a number, say N,  in the 1 to
      "maximum number of lists" range, then the delay value is set to
      (N-1)*<DelayGranularity>.

   Upon expiration of the DelayTimer,  the "informed client" lists are
   scanned once again to see if the corresponding peer has already been
   receiving routing updates from another RS in the local RS cluster.
   If the Router Id of the peer is found in one of the lists as a result
   of receiving a new LIST message, no routing updates are sent to that
   peer.  Otherwise,  the peer's Router ID is entered in the "informed
   client" list that belongs to the RS,  the transmission of the updated
   LIST message is immediately scheduled, and routing updates are sent
   to the client.

   The rational for the delay is to minimize races in the decision as
   which RS among route servers in the same RSC is going to provide



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


   routing information to a given client.  The RS with least number of
   "informed clients" would have a shortest delay and is the most
   probable to win the race.  This helps to equalize the number of
   "informed clients" between RSc in a cluster.

   After an BGP/IDRP peer is placed in the "informed client" list, it is
   only removed from the list when the BGP/IDRP connection to this peer
   is lost.  While an RS client is in the list it is accurately updated
   with all routing changes.

4.3.3.5 Inter-RS Connection Failure

   If a route server loses a routing session with a route server in the
   same cluster,  it must consider taking the responsibilities of route
   advertisement to the clients that are in the "informed client" list
   of the remote route server of the failed session.

   For each such client it is checked whether the server has an
   established BGP/IDRP connection to that client and the client is not
   in any of the "informed client" lists of active RS.  If both
   conditions are true,  the processing described for a new client takes
   place (see 4.3.3.3).

   After advertisement responsibilities are reconciled the "informed
   client" list associated with the failed session should be discarded.

4.3.4 RCID_PATH Attribute

   The RCID_PATH is an optional non-transitive attribute that is
   composed of a sequence of RS Cluster Identifiers (RCID) that
   identifies the RS Cluster through which routing information carried
   in the UPDATE message has passed.  Type Code of the RCID_PATH
   attribute is 254.  The attribute value field contains one or more RS
   Cluster Identifiers, each encoded as a 2-octets long field.

   When a route server propagates a route which has been learned from
   nother Route Server's UPDATE message, the following is performed with
   respect to the the RCID_PATH attribute:

  -     if the destination of the route is not a route server, the
        RCID_PATH Attribute is excluded from the UPDATE message sent to
        that client.

  -     if the destination of the route is another route server that is
        located in the advertising server's own RS cluster,  the
        RCID_PATH attribute is sent unmodified.





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


  -     if the destination of the route is a route server in a different
        RS cluster,  the advertising route server shall verify that the
        RCID of the destination speaker's cluster is not present in
        the RCID_PATH attribute associated with route.  If it does,
        the route shall not be advertised and an event indicating
        that a route loop was detected should be logged, otherwise
        the advertising router shall prepend its own RCID to the RCID
        sequence in the RCID_PATH attribute (put it in the leftmost
        position).

   When a route server propagates a route which has been learned from a
   border router to another route server then:

  -     if the destination of the route is a route server that is
        located in the advertising router's own RS cluster,  an empty
        RCID_PATH attribute shall be included in the UPDATE message
        (an empty RCID_PATH attribute is one whose length field contains
        the value zero).

  -     if the destination of the route is a route server in a different
        RS cluster,  the advertising route server shall include its own
        RCID in the RCID_PATH attribute.  In this case, the RCID of
        advertising route server will be the only entry in the RCID_PATH
        attribute.

4.3.5 NOTIFICATION Error Codes

   In addition to the error codes defined in the BGP-4/IDRP
   specification, the following error can be indicated in a NOTIFICATION
   message that is sent by a route server:

     255  LIST Message Error

   The following error subcodes can be associated with the LIST Message
   Error:

     1  - Bad Address.  This subcode indicates that a Client Identifying
          Address in the received LIST message does not represent
          a valid network layer address of a router interface.

   The following additional UPDATE error subcodes are also defined:

     255 - Invalid ADVERTISER Attribute.  This subcode indicates that
           a value of the ADVERTISER Attribute does not represent
           a valid network layer address of a router interface.






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


4.3.7 Timers

   The InitiationTimer value of 5 minutes is suggested.

   In order to avoid route flaps during an RS switch-over, a value of
   DelayGranularity should be such so the maximum possible value of the
   DelayTimer (see 4.3.3.3) combined with the Hold Time of inter-RS
   connections would be shorter than two-third of the smallest Hold Time
   interval of all BGP/IDRP connections between the route servers and
   their clients (including RSs in other clusters).  So in a cluster
   with three RSs and the respective Hold Times of 30 and 90 seconds the
   DelayGranularity of 15 seconds would be a recommended value.

   For the same reason it is recommended that the Hold Time of BGP/IDRP
   connections between route servers in the same cluster is set to one-
   third of the smallest Hold Time of all BGP/IDRP connections between
   the route servers and their clients (including RSs in other
   clusters).  So, if the smallest Hold Time of BGP/IDRP sessions with
   clients is 90 seconds,  the recommended  value of the Hold Time of
   BGP/IDRP connections between route servers in that cluster would be
   30 seconds.

5. Route Server Discovery

   This document does not propose any mechanism for the dynamic RS
   discovery by RS clients or/and by other route servers.  It is assumed
   that at minimum a manual configuration will be provided in
   participating routers to achieve the needed connectivity.

7. Security Considerations

   Security issues are not discussed in this document.

8. Acknowledgment

   Some design concepts presented in this paper benefited from
   discussions with Tony Li (cisco Systems).

   Author likes to thank John Krawczyk (Bay Networks) and Susan Harris
   (Merit) for their review and valuable comments.

   Also, author would like to thank Yakov Rekhter (IBM) for the review
   of the earlier version of this document and constructive comments.

   Special thanks to Ray Chang (Bay Networks) whose experience in
   implementing the concepts presented in this document helped to refine
   the route server design.




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


9. References

   [BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
          (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp.,
          cisco Systems, March 1995.

   [IDRP] Rekhter, Y., and P. Traina, "IDRP for IPv6", Work In Progress.

10. Author's Address

   Dimitry Haskin
   Bay Networks, Inc.
   2 Federal Street
   Billerica, MA 01821

   EMail: [e-mail]



































Haskin                        Experimental                     [Page 16]