rfc1164.txt

RFC 的详细文档！

   desynchronization described earlier does not occur at all, since BGP
   information propagates within the AS synchronously with the IGP, and
   the IGP converges more or less simultaneously with the arrival of the
   new routing information.  Note that the IGP only carries BGP
   information and should not interpret or process this information.

5.2.2 Tagged Interior Gateway Protocol

   Certain IGPs can tag routes exterior to an AS with the identity of
   their exit points while propagating them within the AS.  Each border
   gateway should use identical tags for announcing exterior routing
   information (received via BGP) both into the IGP and into Internal
   BGP when propagating this information to other border gateways within
   the same AS.  Tags generated by a border gateway must uniquely
   identify that particular border gateway--different border gateways
   must use different tags.

   All Border Gateways within a single AS must observe the following two
   rules:

   1. Information received via Internal BGP by a border gateway A
      declaring a network to be unreachable must immediately be
      propagated to all of the External BGP neighbors of A.

   2. Information received via Internal BGP by a border gateway A about
      a reachable network X cannot be propagated to any of the External
      BGP neighbors of A unless/until A has an IGP route to X and both
      the IGP and the BGP routing information have identical tags.

   These rules guarantee that no routing information is announced
   externally unless the IGP is capable of correctly supporting it.  It
   also avoids some causes of "black holes".

   One possible method for tagging BGP and IGP routes within an AS is to
   use the IP address of the exit border gateway announcing the exterior
   route into the AS.  In this case the "gateway" field in the BGP
   UPDATE message is used as the tag.



Interconnectivity Working Group                                [Page 18]

RFC 1164                   BGP - Application                   June 1990


5.2.3 Encapsulation

   Encapsulation provides the simplest (in terms of the interaction
   between the IGP and BGP) mechanism for carrying transit traffic
   across the AS.  In this approach, transit traffic is encapsulated
   within an IP datagram addressed to the exit gateway.  The only
   requirement imposed on the IGP by this approach is that it should be
   capable of supporting routing between border gateways within the same
   AS.

   The address of the exit gateway A for some exterior network X is
   specified in the "gateway" field of the BGP UPDATE message received
   from gateway A via Internal BGP by all other border gateways within
   the same AS.  In order to route traffic to network X, each border
   gateway within the AS encapsulates it in datagrams addressed to
   gateway A.  Gateway A then performs decapsulation and forwards the
   original packet to the proper gateway in another AS.

   Since encapsulation does not rely on the IGP to carry exterior
   routing information, no synchronization between BGP and the IGP is
   required.

   Some means of identifying datagrams containing encapsulated IP, such
   as an IP protocol type code, must be defined if this method is to be
   used.

   Note, that if a packet to be encapsulated has length that is very
   close to the MTU, that packet would be fragmented at the gateway that
   performs encapsulation.

5.2.4 Other Cases

   There may be ASs with IGPs which can neither carry BGP information
   nor tag exterior routes (e.g., RIP).  In addition, encapsulation may
   be either infeasible or undesirable.  In such situations, the
   following two rules must be observed:

   1. Information received via Internal BGP by a border gateway A
      declaring a network to be unreachable must immediately be
      propagated to all of the External BGP neighbors of A.

   2. Information received via Internal BGP by a border gateway A about
      a reachable network X cannot be propagated to any of the External
      BGP neighbors of A unless A has an IGP route to X and sufficient
      time (holddown) has passed for the IGP routes to have converged.

   The above rules present necessary (but not sufficient) conditions for
   propagating BGP routing information to other ASs.  In contrast to



Interconnectivity Working Group                                [Page 19]

RFC 1164                   BGP - Application                   June 1990


   tagged IGPs, these rules cannot ensure that interior routes to the
   proper exit gateways are in place before propagating the routes to
   other ASs.

   If the convergence time of an IGP is less than some small value X,
   then the time window during which the IGP and BGP are unsynchronized
   is less than X as well, and the whole issue can be ignored at the
   cost of transient periods (of less than length X) of routing
   instability.  A reasonable value for X is a matter for further study,
   but X should probably be less than one second.

   If the convergence time of an IGP cannot be ignored, a different
   approach is needed.  Mechanisms and techniques which might be
   appropriate in this situation are subjects for further study.

6. Implementation Recommendations

6.1 Multiple Networks Per Message

   The BGP protocol allows for multiple networks with the same AS path
   and next-hop gateway to be specified in one message.  Making use of
   this capability is highly recommended.  With one network per message
   there is a substantial increase in overhead in the receiver.  Not
   only does the system overhead increase due to the reception of
   multiple messages, but the overhead of scanning the routing table for
   flash updates to BGP peers and other routing protocols (and sending
   the associated messages) is incurred multiple times as well.  One
   method of building messages containing many networks per AS path and
   gateway from a routing table that is not organized per AS path is to
   build many messages as the routing table is scanned.  As each network
   is processed, a message for the associated AS path and gateway is
   allocated, if it does not exist, and the new network is added to it.
   If such a message exists, the new network is just appended to it.  If
   the message lacks the space to hold the new network, it is
   transmitted, a new message is allocated, and the new network is
   inserted into the new message.  When the entire routing table has
   been scanned, all allocated messages are sent and their resources
   released.  Maximum compression is achieved when all networks share a
   gateway and common path attributes, making it possible to send many
   networks in one 4096-byte message.

6.2 Preventing Excessive Resource Utilization

   When peering with a BGP implementation that does not compress
   multiple networks into one message, it may be necessary to take steps
   to reduce the overhead from the flood of data received when a peer is
   acquired or a significant network topology change occurs.  One method
   of doing this is to rate limit flash updates.  This will eliminate



Interconnectivity Working Group                                [Page 20]

RFC 1164                   BGP - Application                   June 1990


   the redundant scanning of the routing table to provide flash updates
   for BGP peers and other routing protocols.  A disadvantage of this
   approach is that it increases the propagation latency of routing
   information.  By choosing a minimum flash update interval that is not
   much greater than the time it takes to process the multiple messages,
   this latency should be minimized.

6.3 Processing Messages on a Stream Protocol

   Due to the stream nature of TCP, all the data for received messages
   does not necessarily arrive at the same time, due to the nature of
   TCP.  This can make it difficult to process the data as messages,
   especially on systems such as BSD Unix where it is not possible to
   determine how much data has been received but not yet processed.  One
   method that can be used in this situation is to first try to read
   just the message header.  For the KeepAlive message type, this is a
   complete message; for other message types, the header should first be
   verified, in particular the total length.  If all checks are
   successful, the specified length, minus the size of the message
   header is the amount of data left to read.  An implementation that
   would "hang" the routing information process while trying to read
   from a peer could set up a message buffer (1024 bytes) per peer and
   fill it with data as available until a complete message has been
   received.

6.4 Processing Update Messages

   In BGP, all Update messages are incremental.  Once a particular
   network is listed in an Update message as being reachable through an
   AS path and gateway, that piece of information is expected to be
   retained indefinitely.  In order for a route to a network to be
   removed, it must be explicitly listed in an Update message as being
   unreachable or with new routing information to replace the old.  Note
   that a BGP peer will only advertise one route to a given network, so
   any announcement of that network by a particular peer replaces any
   previous information about that network received from the same peer.

   This approach has the obvious advantage of low overhead; if all
   routes are stable, only KeepAlive messages will be sent.  There is no
   periodic flood of route information.

   However, this means that a consistent view of routing information
   between BGP peers is only possible over the course of a single
   transport connection, since there is no mechanism for a complete
   update.  This requirement is accommodated by specifying that BGP
   peers must transition to the Idle state upon the failure of a
   transport connection.




Interconnectivity Working Group                                [Page 21]

RFC 1164                   BGP - Application                   June 1990


7. Conclusion

   The BGP protocol provides a high degree of control and flexibility
   for doing interdomain routing while enforcing policy and performance
   constraints and avoiding routing loops.  It is hoped that the
   guidelines presented here will provide a starting point for more
   sophisticated and manageable routing in the Internet as it grows.

References

   [1]  Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol", RFC
        1163, cisco Systems and IBM Watson Research Center, June 1990.

   [2]  Braun, H-W., "Models of Policy Based Routing", RFC 1104,
        Merit/NSFNET, June 1989.

   [3]  Clark, D., "Policy Routing in Internet Protocols", RFC 1102,
        M.I.T., May 1989.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Jeffrey C. Honig
   Theory Center
   265 Olin Hall
   Cornell University
   Ithaca, NY  14853-5201

   Phone:  [phone]

   Email:  [e-mail]


   Dave Katz
   Merit/NSFNET
   1075 Beal Ave.
   Ann Arbor, MI  48109

   Phone:  [phone]

   Email:  [e-mail]







Interconnectivity Working Group                                [Page 22]

RFC 1164                   BGP - Application                   June 1990


   Matt Mathis
   Pittsburgh Supercomputing Center
   4400 Fifth Ave.
   Pittsburgh, PA  15213

   Phone:  [phone]

   Email:  [e-mail]


   Yakov Rekhter
   T.J. Watson Research Center
   IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY  10598

   Phone:  [phone]

   Email:  [e-mail]


   Jie Yun (Jessica) Yu
   Merit/NSFNET
   1075 Beal Ave.
   Ann Arbor, MI  48109

   Phone:  [phone]

   Email:  [e-mail]






















Interconnectivity Working Group                                [Page 23]