rfc1163.txt

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

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


                    A Border Gateway Protocol (BGP)

Status of this Memo

   This RFC, together with its companion RFC-1164, "Application of the
   Border Gateway Protocol in the Internet", define a Proposed Standard
   for an inter-autonomous system routing protocol for the Internet.

   This protocol, like any other at this initial stage, may undergo
   modifications before reaching full Internet Standard status as a
   result of deployment experience.  Implementers are encouraged to
   track the progress of this or any protocol as it moves through the
   standardization process, and to report their own experience with the
   protocol.

   This protocol is being considered by the Interconnectivity Working
   Group (IWG) of the Internet Engineering Task Force (IETF).
   Information about the progress of BGP can be monitored and/or
   reported on the IWG mailing list ([e-mail]).

   Please refer to the latest edition of the "IAB Official Protocol
   Standards" RFC for current information on the state and status of
   standard Internet protocols.

   Distribution of this memo is unlimited.

Table of Contents

      1.  Acknowledgements......................................    2
      2.  Introduction..........................................    2
      3.  Summary of Operation..................................    4
      4.  Message Formats.......................................    5
      4.1 Message Header Format.................................    5
      4.2 OPEN Message Format...................................    6
      4.3 UPDATE Message Format.................................    8
      4.4 KEEPALIVE Message Format..............................   10
      4.5 NOTIFICATION Message Format...........................   10
      5.  Path Attributes.......................................   12
      6.  BGP Error Handling....................................   14
      6.1 Message Header error handling.........................   14
      6.2 OPEN message error handling...........................   15



Lougheed & Rekhter                                              [Page 1]

RFC 1163                          BGP                          June 1990


      6.3 UPDATE message error handling.........................   16
      6.4 NOTIFICATION message error handling...................   17
      6.5 Hold Timer Expired error handling.....................   17
      6.6 Finite State Machine error handling...................   18
      6.7 Cease.................................................   18
      7.  BGP Version Negotiation...............................   18
      8.  BGP Finite State machine..............................   18
      9.  UPDATE Message Handling...............................   22
      10. Detection of Inter-AS Policy Contradictions...........   23
      Appendix 1.  BGP FSM State Transitions and Actions........   25
      Appendix 2.  Comparison with RFC 1105.....................   28
      Appendix 3.  TCP options that may be used with BGP........   28
      References................................................   29
      Security Considerations...................................   29
      Authors' Addresses........................................   29

1.  Acknowledgements

   We would like to express our thanks to Guy Almes (Rice University),
   Len Bosack (cisco Systems), Jeffrey C. Honig (Cornell Theory Center)
   and all members of the Interconnectivity Working Group of the
   Internet Engineering Task Force, chaired by Guy Almes, for their
   contributions to this document.

   We would also like to thank Bob Hinden, Director for Routing of the
   Internet Engineering Steering Group, and the team of reviewers he
   assembled to review earlier versions of this document.  This team,
   consisting of Deborah Estrin, Milo Medin, John Moy, Radia Perlman,
   Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted with a
   strong combination of toughness, professionalism, and courtesy.

2.  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 full path of
   Autonomous Systems (ASs) 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 some policy
   decisions at the AS level may be enforced.

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that an AS advertize to its



Lougheed & Rekhter                                              [Page 2]

RFC 1163                          BGP                          June 1990


   neighbor ASs only those routes that it itself uses.  This rule
   reflects the "hop-by-hop" routing paradigm generally used throughout
   the current Internet.  Note that some policies cannot be supported by
   the "hop-by-hop" routing paradigm and thus require techniques such as
   source routing to enforce.  For example, BGP does not enable one AS
   to send traffic to a neighbor AS intending that that traffic take a
   different route from that taken by traffic originating in the
   neighbor AS.  On the other hand, BGP can support any policy
   conforming to the "hop-by-hop" routing paradigm.  Since the current
   Internet uses only the "hop-by-hop" routing paradigm and since BGP
   can support any policy that conforms to that paradigm, BGP is highly
   applicable as an inter-AS routing protocol for the current Internet.

   A more complete discussion of what policies can and cannot be
   enforced with BGP is outside the scope of this document (but refer to
   the companion document discussing BGP usage [5]).

   BGP runs over a reliable transport 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 error notification mechanism used in
   BGP assumes that the transport protocol supports a "graceful" close,
   i.e., that all outstanding data will be delivered before the
   connection is closed.

   BGP uses TCP [4] as its transport protocol.  TCP meets BGP's
   transport requirements and 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.

   This memo uses the term `Autonomous System' (AS) throughout.  The
   classic definition of an Autonomous System is a set of routers under
   a single technical administration, using an interior gateway protocol
   and common metrics to route packets within the AS, and using an
   exterior gateway protocol to route packets to other ASs.  Since this
   classic definition was developed, it has become common for a single
   AS to use several interior gateway protocols and sometimes several
   sets of metrics within an AS.  The use of the term Autonomous System
   here stresses the fact that, even when multiple IGPs and metrics are
   used, the administration of an AS appears to other ASs to have a
   single coherent interior routing plan and presents a consistent
   picture of what networks are reachable through it.  From the
   standpoint of exterior routing, an AS can be viewed as monolithic:
   reachability to networks directly connected to the AS must be
   equivalent from all border gateways of the AS.




Lougheed & Rekhter                                              [Page 3]

RFC 1163                          BGP                          June 1990


   The planned use of BGP in the Internet environment, including such
   issues as topology, the interaction between BGP and IGPs, and the
   enforcement of routing policy rules is presented in a companion
   document [5].  This document is the first of a series of documents
   planned to explore various aspects of BGP application.

3.  Summary of Operation

   Two systems 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.  BGP does not require
   periodic refresh of the entire BGP routing table.  Therefore, a BGP
   speaker must retain the current version of the entire BGP routing
   tables of all of its peers for the duration of the connection.
   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
   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
   router in another Autonomous System.  The implications and
   applications of this architecture are for further study.

   If a particular AS has multiple BGP speakers and is providing transit
   service for other ASs, then care must be taken to ensure a consistent
   view of routing within the AS.  A consistent view of the interior
   routes of the AS is provided by the interior routing protocol.  A
   consistent view of the routes exterior to the AS can be provided by
   having all BGP speakers within the AS maintain direct BGP connections
   with each other.  Using a common set of policies, the BGP speakers
   arrive at an agreement as to which border routers will serve as
   exit/entry points for particular networks outside the AS.  This
   information is communicated to the AS's internal routers, possibly
   via the interior routing protocol.  Care must be taken to ensure that
   the interior routers have all been updated with transit information
   before the BGP speakers announce to other ASs that transit service is
   being provided.

   Connections between BGP speakers of different ASs are referred to as
   "external" links.  BGP connections between BGP speakers within the
   same AS are referred to as "internal" links.





Lougheed & Rekhter                                              [Page 4]

RFC 1163                          BGP                          June 1990


4.  Message Formats

   This section describes message formats used by BGP.

   Messages are sent over a reliable transport protocol connection.  A
   message is processed only after it is entirely received.  The maximum
   message size is 4096 octets.  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 19 octets.

4.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               |      Type     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Marker:

      This 16-octet field contains a value that the receiver of the
      message can predict.  If the Type of the message is OPEN, or if
      the Authentication Code used in the OPEN message of the connection
      is zero, then the Marker must be all ones.  Otherwise, the value
      of the marker can be predicted by some a computation specified as
      part of the authentication mechanism used.  The Marker can be used
      to detect loss of synchronization between a pair of BGP peers, and
      to authenticate incoming BGP messages.

   Length:

      This 2-octet unsigned integer indicates the total length of the
      message, including the header, in octets.  Thus, e.g., it allows
      one to locate in the transport-level stream the (Marker field of
      the) next message.  The value of the Length field must always be
      at least 19 and no greater than 4096, and may be further



Lougheed & Rekhter                                              [Page 5]

RFC 1163                          BGP                          June 1990


      constrained, depending on the message type.  No "padding" of extra
      data after the message is allowed, so the Length field must have
      the smallest value required given the rest of the message.

   Type:

      This 1-octet unsigned integer indicates the type code of the
      message.  The following type codes are defined:

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

4.2 OPEN Message Format

   After a transport protocol connection is established, the first
   message sent by each side is an OPEN message.  If the OPEN message is
   acceptable, a KEEPALIVE 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