home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1163 < prev    next >
Text File  |  1993-11-03  |  20KB  |  458 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        K. Lougheed
  8. Request for Comments: 1163                                 cisco Systems
  9. Obsoletes: RFC 1105                                           Y. Rekhter
  10.                                    T.J. Watson Research Center, IBM Corp
  11.                                                                June 1990
  12.  
  13.  
  14.                     A Border Gateway Protocol (BGP)
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC, together with its companion RFC-1164, "Application of the
  19.    Border Gateway Protocol in the Internet", define a Proposed Standard
  20.    for an inter-autonomous system routing protocol for the Internet.
  21.  
  22.    This protocol, like any other at this initial stage, may undergo
  23.    modifications before reaching full Internet Standard status as a
  24.    result of deployment experience.  Implementers are encouraged to
  25.    track the progress of this or any protocol as it moves through the
  26.    standardization process, and to report their own experience with the
  27.    protocol.
  28.  
  29.    This protocol is being considered by the Interconnectivity Working
  30.    Group (IWG) of the Internet Engineering Task Force (IETF).
  31.    Information about the progress of BGP can be monitored and/or
  32.    reported on the IWG mailing list (IWG@nri.reston.va.us).
  33.  
  34.    Please refer to the latest edition of the "IAB Official Protocol
  35.    Standards" RFC for current information on the state and status of
  36.    standard Internet protocols.
  37.  
  38.    Distribution of this memo is unlimited.
  39.  
  40. Table of Contents
  41.  
  42.       1.  Acknowledgements......................................    2
  43.       2.  Introduction..........................................    2
  44.       3.  Summary of Operation..................................    4
  45.       4.  Message Formats.......................................    5
  46.       4.1 Message Header Format.................................    5
  47.       4.2 OPEN Message Format...................................    6
  48.       4.3 UPDATE Message Format.................................    8
  49.       4.4 KEEPALIVE Message Format..............................   10
  50.       4.5 NOTIFICATION Message Format...........................   10
  51.       5.  Path Attributes.......................................   12
  52.       6.  BGP Error Handling....................................   14
  53.       6.1 Message Header error handling.........................   14
  54.       6.2 OPEN message error handling...........................   15
  55.  
  56.  
  57.  
  58. Lougheed & Rekhter                                              [Page 1]
  59.  
  60. RFC 1163                          BGP                          June 1990
  61.  
  62.  
  63.       6.3 UPDATE message error handling.........................   16
  64.       6.4 NOTIFICATION message error handling...................   17
  65.       6.5 Hold Timer Expired error handling.....................   17
  66.       6.6 Finite State Machine error handling...................   18
  67.       6.7 Cease.................................................   18
  68.       7.  BGP Version Negotiation...............................   18
  69.       8.  BGP Finite State machine..............................   18
  70.       9.  UPDATE Message Handling...............................   22
  71.       10. Detection of Inter-AS Policy Contradictions...........   23
  72.       Appendix 1.  BGP FSM State Transitions and Actions........   25
  73.       Appendix 2.  Comparison with RFC 1105.....................   28
  74.       Appendix 3.  TCP options that may be used with BGP........   28
  75.       References................................................   29
  76.       Security Considerations...................................   29
  77.       Authors' Addresses........................................   29
  78.  
  79. 1.  Acknowledgements
  80.  
  81.    We would like to express our thanks to Guy Almes (Rice University),
  82.    Len Bosack (cisco Systems), Jeffrey C. Honig (Cornell Theory Center)
  83.    and all members of the Interconnectivity Working Group of the
  84.    Internet Engineering Task Force, chaired by Guy Almes, for their
  85.    contributions to this document.
  86.  
  87.    We would also like to thank Bob Hinden, Director for Routing of the
  88.    Internet Engineering Steering Group, and the team of reviewers he
  89.    assembled to review earlier versions of this document.  This team,
  90.    consisting of Deborah Estrin, Milo Medin, John Moy, Radia Perlman,
  91.    Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted with a
  92.    strong combination of toughness, professionalism, and courtesy.
  93.  
  94. 2.  Introduction
  95.  
  96.    The Border Gateway Protocol (BGP) is an inter-Autonomous System
  97.    routing protocol.  It is built on experience gained with EGP as
  98.    defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
  99.    described in RFC 1092 [2] and RFC 1093 [3].
  100.  
  101.    The primary function of a BGP speaking system is to exchange network
  102.    reachability information with other BGP systems.  This network
  103.    reachability information includes information on the full path of
  104.    Autonomous Systems (ASs) that traffic must transit to reach these
  105.    networks.  This information is sufficient to construct a graph of AS
  106.    connectivity from which routing loops may be pruned and some policy
  107.    decisions at the AS level may be enforced.
  108.  
  109.    To characterize the set of policy decisions that can be enforced
  110.    using BGP, one must focus on the rule that an AS advertize to its
  111.  
  112.  
  113.  
  114. Lougheed & Rekhter                                              [Page 2]
  115.  
  116. RFC 1163                          BGP                          June 1990
  117.  
  118.  
  119.    neighbor ASs only those routes that it itself uses.  This rule
  120.    reflects the "hop-by-hop" routing paradigm generally used throughout
  121.    the current Internet.  Note that some policies cannot be supported by
  122.    the "hop-by-hop" routing paradigm and thus require techniques such as
  123.    source routing to enforce.  For example, BGP does not enable one AS
  124.    to send traffic to a neighbor AS intending that that traffic take a
  125.    different route from that taken by traffic originating in the
  126.    neighbor AS.  On the other hand, BGP can support any policy
  127.    conforming to the "hop-by-hop" routing paradigm.  Since the current
  128.    Internet uses only the "hop-by-hop" routing paradigm and since BGP
  129.    can support any policy that conforms to that paradigm, BGP is highly
  130.    applicable as an inter-AS routing protocol for the current Internet.
  131.  
  132.    A more complete discussion of what policies can and cannot be
  133.    enforced with BGP is outside the scope of this document (but refer to
  134.    the companion document discussing BGP usage [5]).
  135.  
  136.    BGP runs over a reliable transport protocol.  This eliminates the
  137.    need to implement explicit update fragmentation, retransmission,
  138.    acknowledgement, and sequencing.  Any authentication scheme used by
  139.    the transport protocol may be used in addition to BGP's own
  140.    authentication mechanisms.  The error notification mechanism used in
  141.    BGP assumes that the transport protocol supports a "graceful" close,
  142.    i.e., that all outstanding data will be delivered before the
  143.    connection is closed.
  144.  
  145.    BGP uses TCP [4] as its transport protocol.  TCP meets BGP's
  146.    transport requirements and is present in virtually all commercial
  147.    routers and hosts.  In the following descriptions the phrase
  148.    "transport protocol connection" can be understood to refer to a TCP
  149.    connection.  BGP uses TCP port 179 for establishing its connections.
  150.  
  151.    This memo uses the term `Autonomous System' (AS) throughout.  The
  152.    classic definition of an Autonomous System is a set of routers under
  153.    a single technical administration, using an interior gateway protocol
  154.    and common metrics to route packets within the AS, and using an
  155.    exterior gateway protocol to route packets to other ASs.  Since this
  156.    classic definition was developed, it has become common for a single
  157.    AS to use several interior gateway protocols and sometimes several
  158.    sets of metrics within an AS.  The use of the term Autonomous System
  159.    here stresses the fact that, even when multiple IGPs and metrics are
  160.    used, the administration of an AS appears to other ASs to have a
  161.    single coherent interior routing plan and presents a consistent
  162.    picture of what networks are reachable through it.  From the
  163.    standpoint of exterior routing, an AS can be viewed as monolithic:
  164.    reachability to networks directly connected to the AS must be
  165.    equivalent from all border gateways of the AS.
  166.  
  167.  
  168.  
  169.  
  170. Lougheed & Rekhter                                              [Page 3]
  171.  
  172. RFC 1163                          BGP                          June 1990
  173.  
  174.  
  175.    The planned use of BGP in the Internet environment, including such
  176.    issues as topology, the interaction between BGP and IGPs, and the
  177.    enforcement of routing policy rules is presented in a companion
  178.    document [5].  This document is the first of a series of documents
  179.    planned to explore various aspects of BGP application.
  180.  
  181. 3.  Summary of Operation
  182.  
  183.    Two systems form a transport protocol connection between one another.
  184.    They exchange messages to open and confirm the connection parameters.
  185.    The initial data flow is the entire BGP routing table.  Incremental
  186.    updates are sent as the routing tables change.  BGP does not require
  187.    periodic refresh of the entire BGP routing table.  Therefore, a BGP
  188.    speaker must retain the current version of the entire BGP routing
  189.    tables of all of its peers for the duration of the connection.
  190.    KeepAlive messages are sent periodically to ensure the liveness of
  191.    the connection.  Notification messages are sent in response to errors
  192.    or special conditions.  If a connection encounters an error
  193.    condition, a notification message is sent and the connection is
  194.    closed.
  195.  
  196.    The hosts executing the Border Gateway Protocol need not be routers.
  197.    A non-routing host could exchange routing information with routers
  198.    via EGP or even an interior routing protocol.  That non-routing host
  199.    could then use BGP to exchange routing information with a border
  200.    router in another Autonomous System.  The implications and
  201.    applications of this architecture are for further study.
  202.  
  203.    If a particular AS has multiple BGP speakers and is providing transit
  204.    service for other ASs, then care must be taken to ensure a consistent
  205.    view of routing within the AS.  A consistent view of the interior
  206.    routes of the AS is provided by the interior routing protocol.  A
  207.    consistent view of the routes exterior to the AS can be provided by
  208.    having all BGP speakers within the AS maintain direct BGP connections
  209.    with each other.  Using a common set of policies, the BGP speakers
  210.    arrive at an agreement as to which border routers will serve as
  211.    exit/entry points for particular networks outside the AS.  This
  212.    information is communicated to the AS's internal routers, possibly
  213.    via the interior routing protocol.  Care must be taken to ensure that
  214.    the interior routers have all been updated with transit information
  215.    before the BGP speakers announce to other ASs that transit service is
  216.    being provided.
  217.  
  218.    Connections between BGP speakers of different ASs are referred to as
  219.    "external" links.  BGP connections between BGP speakers within the
  220.    same AS are referred to as "internal" links.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Lougheed & Rekhter                                              [Page 4]
  227.  
  228. RFC 1163                          BGP                          June 1990
  229.  
  230.  
  231. 4.  Message Formats
  232.  
  233.    This section describes message formats used by BGP.
  234.  
  235.    Messages are sent over a reliable transport protocol connection.  A
  236.    message is processed only after it is entirely received.  The maximum
  237.    message size is 4096 octets.  All implementations are required to
  238.    support this maximum message size.  The smallest message that may be
  239.    sent consists of a BGP header without a data portion, or 19 octets.
  240.  
  241. 4.1 Message Header Format
  242.  
  243.    Each message has a fixed-size header.  There may or may not be a data
  244.    portion following the header, depending on the message type.  The
  245.    layout of these fields is shown below:
  246.  
  247.     0                   1                   2                   3
  248.     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
  249.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  250.    |                                                               |
  251.    +                                                               +
  252.    |                                                               |
  253.    +                                                               +
  254.    |                           Marker                              |
  255.    +                                                               +
  256.    |                                                               |
  257.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  258.    |          Length               |      Type     |
  259.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  260.  
  261.    Marker:
  262.  
  263.       This 16-octet field contains a value that the receiver of the
  264.       message can predict.  If the Type of the message is OPEN, or if
  265.       the Authentication Code used in the OPEN message of the connection
  266.       is zero, then the Marker must be all ones.  Otherwise, the value
  267.       of the marker can be predicted by some a computation specified as
  268.       part of the authentication mechanism used.  The Marker can be used
  269.       to detect loss of synchronization between a pair of BGP peers, and
  270.       to authenticate incoming BGP messages.
  271.  
  272.    Length:
  273.  
  274.       This 2-octet unsigned integer indicates the total length of the
  275.       message, including the header, in octets.  Thus, e.g., it allows
  276.       one to locate in the transport-level stream the (Marker field of
  277.       the) next message.  The value of the Length field must always be
  278.       at least 19 and no greater than 4096, and may be further
  279.  
  280.  
  281.  
  282. Lougheed & Rekhter                                              [Page 5]
  283.  
  284. RFC 1163                          BGP                          June 1990
  285.  
  286.  
  287.       constrained, depending on the message type.  No "padding" of extra
  288.       data after the message is allowed, so the Length field must have
  289.       the smallest value required given the rest of the message.
  290.  
  291.    Type:
  292.  
  293.       This 1-octet unsigned integer indicates the type code of the
  294.       message.  The following type codes are defined:
  295.  
  296.                            1 - OPEN
  297.                            2 - UPDATE
  298.                            3 - NOTIFICATION
  299.                            4 - KEEPALIVE
  300.  
  301. 4.2 OPEN Message Format
  302.  
  303.    After a transport protocol connection is established, the first
  304.    message sent by each side is an OPEN message.  If the OPEN message is
  305.    acceptable, a KEEPALIVE message confirming the OPEN is sent back.
  306.    Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION
  307.    messages may be exchanged.
  308.  
  309.    In addition to the fixed-size BGP header, the OPEN message contains
  310.    the following fields:
  311.  
  312.      0                   1                   2                   3
  313.      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
  314.     +-+-+-+-+-+-+-+-+
  315.     |    Version    |
  316.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  317.     |     My Autonomous System      |
  318.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  319.     |           Hold Time           |
  320.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  321.     |  Auth. Code   |
  322.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  323.     |                                                               |
  324.     |                       Authentication Data                     |
  325.     |                                                               |
  326.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  327.  
  328.    Version:
  329.  
  330.       This 1-octet unsigned integer indicates the protocol version
  331.       number of the message.  The current BGP version number is 2.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Lougheed & Rekhter                                              [Page 6]
  339.  
  340. RFC 1163                          BGP                          June 1990
  341.  
  342.  
  343.    My Autonomous System:
  344.  
  345.       This 2-octet unsigned integer indicates the Autonomous System
  346.       number of the sender.
  347.  
  348.    Hold Time:
  349.  
  350.       This 2-octet unsigned integer indicates the maximum number of
  351.       seconds that may elapse between the receipt of successive
  352.       KEEPALIVE and/or UPDATE and/or NOTIFICATION messages.
  353.  
  354.    Authentication Code:
  355.  
  356.       This 1-octet unsigned integer indicates the authentication
  357.       mechanism being used.  Whenever an authentication mechanism is
  358.       specified for use within BGP, three things must be included in the
  359.       specification:
  360.          - the value of the Authentication Code which indicates use of
  361.          the mechanism,
  362.          - the form and meaning of the Authentication Data, and
  363.          - the algorithm for computing values of Marker fields.
  364.       Only one authentication mechanism is specified as part of this
  365.       memo:
  366.          - its Authentication Code is zero,
  367.          - its Authentication Data must be empty (of zero length), and
  368.          - the Marker fields of all messages must be all ones.
  369.       The semantics of non-zero Authentication Codes lies outside the
  370.       scope of this memo.
  371.  
  372.       Note that a separate authentication mechanism may be used in
  373.       establishing the transport level connection.
  374.  
  375.    Authentication Data:
  376.  
  377.       The form and meaning of this field is a variable-length field
  378.       depend on the Authentication Code.  If the value of Authentication
  379.       Code field is zero, the Authentication Data field must have zero
  380.       length.  The semantics of the non-zero length Authentication Data
  381.       field is outside the scope of this memo.
  382.  
  383.       Note that the length of the Authentication Data field can be
  384.       determined from the message Length field by the formula:
  385.  
  386.          Message Length = 25 + Authentication Data Length
  387.  
  388.       The minimum length of the OPEN message is 25 octets (including
  389.       message header).
  390.  
  391.  
  392.  
  393.  
  394. Lougheed & Rekhter                                              [Page 7]
  395.  
  396. RFC 1163                          BGP                          June 1990
  397.  
  398.  
  399. 4.3 UPDATE Message Format
  400.  
  401.    UPDATE messages are used to transfer routing information between BGP
  402.    peers.  The information in the UPDATE packet can be used to construct
  403.    a graph describing the relationships of the various Autonomous
  404.    Systems.  By applying rules to be discussed, routing information
  405.    loops and some other anomalies may be detected and removed from
  406.    inter-AS routing.
  407.  
  408.    In addition to the fixed-size BGP header, the UPDATE message contains
  409.    the following fields (note that all fields may have arbitrary
  410.    alignment):
  411.  
  412.      0                   1                   2                   3
  413.      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
  414.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  415.     |  Total Path Attributes Length |
  416.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  417.     |                                                               |
  418.     /                      Path Attributes                          /
  419.     /                                                               /
  420.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.     |                       Network 1                               |
  422.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  423.     /                                                               /
  424.     /                                                               /
  425.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  426.     |                       Network n                               |
  427.     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  428.  
  429.    Total Path Attribute Length:
  430.  
  431.       This 2-octet unsigned integer indicates the total length of the
  432.       Path Attributes field in octets.  Its value must allow the (non-
  433.       negative integer) number of Network fields to be determined as
  434.       specified below.
  435.  
  436.    Path Attributes:
  437.  
  438.       A variable length sequence of path attributes is present in every
  439.       UPDATE.  Each path attribute is a triple <attribute type,
  440.       attribute length, attribute value> of variable length.
  441.  
  442.       Attribute Type is a two-octet field that consists of the Attribute
  443.       Flags octet followed by the Attribute Type Code octet.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Lougheed & Rekhter                                              [Page 8]
  451.  
  452. RFC 1163                          BGP                          June 1990
  453.  
  454.  
  455.        0                   1
  456.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  457.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.       |  Attr