rfc1105.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        K. Lougheed
Request for Comments:  1105                                cisco Systems
                                                              Y. Rekhter
                                  T.J. Watson Research Center, IBM Corp.
                                                               June 1989

                    A Border Gateway Protocol (BGP)

Status of this Memo

   This RFC outlines a specific approach for the exchange of network
   reachability information between Autonomous Systems.

   At the time of this writing, the Border Gateway Protocol
   implementations exist for cisco routers as well as for the NSFNET
   Nodal Switching Systems.  A public domain version for "gated" is
   currently being implemented.

   Distribution of this memo is unlimited.

1. Introduction

   The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol.  It is built on experience gained with EGP as
   defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
   described in RFC 1092 [2] and RFC 1093 [3].

   The primary function of a BGP speaking system is to exchange network
   reachability information with other BGP systems.  This network
   reachability information includes information on the autonomous
   systems (AS's) that traffic must transit to reach these networks.
   This information is sufficient to construct a graph of AS
   connectivity from which routing loops may be pruned and policy
   decisions at an AS level may be enforced.

   BGP runs over a reliable transport level protocol.  This eliminates
   the need to implement explicit update fragmentation, retransmission,
   acknowledgement, and sequencing.  Any authentication scheme used by
   the transport protocol may be used in addition to BGP's own
   authentication mechanisms.

   The initial BGP implementation is based on TCP [4], however any
   reliable transport may be used.  A message passing protocol such as
   VMTP [5] might be more natural for BGP.  TCP will be used, however,
   since it is present in virtually all commercial routers and hosts.
   In the following descriptions the phrase "transport protocol
   connection" can be understood to refer to a TCP connection.  BGP uses
   TCP port 179 for establishing its connections.



Lougheed & Rekhter                                              [Page 1]

RFC 1105                          BGP                          June 1989


2. Summary of Operation

   Two hosts form a transport protocol connection between one another.
   They exchange messages to open and confirm the connection parameters.
   The initial data flow is the entire BGP routing table.  Incremental
   updates are sent as the routing tables change.  Keepalive messages
   are sent periodically to ensure the liveness of the connection.
   Notification messages are sent in response to errors or special
   conditions.  If a connection encounters an error condition, a
   notification message is sent and the connection is optionally closed.

   The hosts executing the Border Gateway Protocol need not be routers.
   A non-routing host could exchange routing information with routers
   via EGP or even an interior routing protocol.  That non-routing host
   could then use BGP to exchange routing information with a border
   gateway in another autonomous system.  The implications and
   applications of this architecture are for further study.

   If a particular AS has more than one BGP gateway, then all these
   gateways should have a consistent view of routing.  A consistent view
   of the interior routes of the autonomous system is provided by the
   intra-AS routing protocol.  A consistent view of the routes exterior
   to the AS may be provided in a variety of ways.  One way is to use
   the BGP protocol to exchange routing information between the BGP
   gateways within a single AS.  In this case, in order to maintain
   consist routing information, these gateways MUST have direct BGP
   sessions with each other (the BGP sessions should form a complete
   graph).  Note that this requirement does not imply that all BGP
   gateways within a single AS must have direct links to each other;
   other methods may be used to ensure consistent routing information.

3. Message Formats

   This section describes message formats and actions to be taken when
   errors are detected while processing these messages.

   Messages are sent over a reliable transport protocol connection.  A
   message is processed after it is entirely received.  The maximum
   message size is 1024 bytes.  All implementations are required to
   support this maximum message size.  The smallest message that may be
   sent consists of a BGP header without a data portion, or 8 bytes.

   The phrase "the BGP connection is closed" means that the transport
   protocol connection has been closed and that all resources for that
   BGP connection have been deallocated.  Routing table entries
   associated with the remote peer are marked as invalid.  This
   information is passed to other BGP peers before being deleted from
   the system.



Lougheed & Rekhter                                              [Page 2]

RFC 1105                          BGP                          June 1989


3.1 Message Header Format

   Each message has a fixed size header.  There may or may not be a data
   portion following the header, depending on the message type.  The
   layout of these fields is shown below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Marker                |          Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version   |     Type      |        Hold Time               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Marker: 16 bits

      The Marker field is 16 bits of all ones.  This field is used to
      mark the start of a message.  If the first two bytes of a message
      are not all ones then we have a synchronization error and the BGP
      connection should be closed after sending a notification message
      with opcode 5 (connection not synchronized).  No notification data
      is sent.

   Length: 16 bits

      The Length field is 16 bits.  It is the total length of the
      message, incluluding header, in bytes.  If an illegal length is
      encountered (more than 1024 bytes or less than 8 bytes), a
      notification message with opcode 6 (bad message length) and two
      data bytes of the bad length should be sent and the BGP connection
      closed.

   Version: 8 bits

      The Version field is 8 bits of protocol version number.  The
      current BGP version number is 1.  If a bad version number is
      found, a notification message with opcode 8 (bad version number)
      should be sent and the BGP connection closed.  The bad version
      number should be included in one byte of notification data.

   Type: 8 bits

      The Type field is 8 bits of message type code.  The following type
      codes are defined:







Lougheed & Rekhter                                              [Page 3]

RFC 1105                          BGP                          June 1989


                    1 - OPEN
                    2 - UPDATE
                    3 - NOTIFICATION
                    4 - KEEPALIVE
                    5 - OPEN CONFIRM

      If an unrecognized type value is found, a notification message
      with opcode 7 (bad type code) and data consisting of the byte of
      type field in question should be sent and the BGP connection
      closed.

   Hold Timer: 16 bits.

      This field contains the number of seconds that may elapse since
      receiving a BGP KEEPALIVE or BGP UPDATE message from our BGP peer
      before we declare an error and close the BGP connection.

3.2  OPEN Message Format

   After a transport protocol connection is established, the first
   message sent by either side is an OPEN message.  If the OPEN message
   is acceptable, an OPEN CONFIRM message confirming the OPEN is sent
   back.  Once the OPEN is confirmed, UPDATE, KEEPALIVE, and
   NOTIFICATION messages may be exchanged.

   In addition to the fixed size BGP header, the OPEN message contains
   the following fields.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    My Autonomous System      |   Link Type   |  Auth. Code    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                 Authentication Data                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   My Autonomous System: 16 bits

      This field is our 16 bit autonomous system number.  If there is a
      problem with this field, a notification message with opcode 9
      (invalid AS field) should be sent and the BGP connection closed.
      No notification data is sent.

   Link Type: 8 bits

      The Link Type field is a single octet containing one of the



Lougheed & Rekhter                                              [Page 4]

RFC 1105                          BGP                          June 1989


      following codes defining our position in the AS graph relative to
      our peer.

                       0  - INTERNAL
                       1  - UP
                       2  - DOWN
                       3  - H-LINK

      UP indicates the peer is higher in the AS hierarchy, DOWN
      indicates lower, and H-LINK indicates at the same level.  INTERNAL
      indicates that the peer is another BGP speaking host in our
      autonomous system.  INTERNAL links are used to keep AS routing
      information consistent with an AS with multiple border gateways.
      If the Link Type field is unacceptable, a notification message
      with opcode 1 (link type error in open) and data consisting of the
      expected link type should be sent and the BGP connection closed.
      The acceptable values for the Link Type fields of two BGP peers
      are discussed below.

   Authentication Code: 8 bits

      The Authentication Code field is an octet whose value describes
      the authentication mechanism being used.  A value of zero
      indicates no BGP authentication.  Note that a separate
      authentication mechanism may be used in establishing the transport
      level connection.  If the authentication code is not recognized, a
      notification message with opcode 2 (unknown authentication code)
      and no data is sent and the BGP connection is closed.

   Authentication Data: variable length

      The Authentication Data field is a variable length field
      containing authentication data.  If the value of Authentication
      Code field is zero, the Authentication Data field has zero length.
      If authentication fails, a notification message with opcode 3
      (authentication failure) and no data is sent and the BGP
      connection is closed.

3.3 OPEN CONFIRM Message Format

   An OPEN CONFIRM message is sent after receiving an OPEN message.
   This completes the BGP connection setup.  UPDATE, NOTIFICATION, and
   KEEPALIVE messages may now be exchanged.

   An OPEN CONFIRM message consists of a BGP header with an OPEN CONFIRM
   type code.  There is no data in an OPEN CONFIRM message.





Lougheed & Rekhter                                              [Page 5]

RFC 1105                          BGP                          June 1989


3.4 UPDATE Message Format

   UPDATE messages are used to transfer routing information between BGP
   peers.  The information in the UPDATE packet can be used to construct
   a graph describing the relationships of the various autonomous
   systems.  By applying rules to be discussed, routing information
   loops and some other anomalies may be detected and removed from the
   inter-AS routing.

   Whenever an error in a UPDATE message is detected, a notification
   message is sent with opcode 4 (bad update), a two byte subcode
   describing the nature of the problem, and a data field consisting of
   as much of the UPDATE message data portion as possible.  UPDATE
   messages have the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Gateway                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AS count    | Direction     |         AS Number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     repeat (Direction, AS Number) pairs AS count times        |
   /                                                               /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Net Count                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Network                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Metric                   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +