rfc1105.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 955 行 · 第 1/3 页

   |       repeat (Network, Metric) pairs Net Count times          |
   /                                                               /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Gateway: 32 bits.

      The Gateway field is the address of a gateway that has routes to
      the Internet networks listed in the rest of the UPDATE message.
      This gateway MUST belong to the same AS as the BGP peer who
      advertises it.  If there is a problem with the gateway field, a
      notification message with subcode 6 (invalid gateway field) is
      sent.




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


   AS count: 8 bits.

      This field is the count of Direction and AS Number pairs in this
      UPDATE message.  If an incorrect AS count field is detected,
      subcode 1 (invalid AS count) is specified in the notification
      message.

   Direction: 8 bits

      The Direction field is an octet containing the direction taken by
      the routing information when exiting the AS defined by the
      succeeding AS Number field.  The following values are defined.

            1  - UP            (went up a link in the graph)
            2  - DOWN          (went down a link in the graph)
            3  - H_LINK        (horizontal link in the graph)
            4  - EGP_LINK      (EGP derived information)
            5  - INCOMPLETE    (incomplete information)

      There is a special provision to pass exterior learned (non-BGP)
      routes over BGP.  If an EGP learned route is passed over BGP, then
      the Direction field is set to EGP-LINK and the AS Number field is
      set to the AS number of the EGP peer that advertised this route.
      All other exterior-learned routes (non-BGP and non-EGP) may be
      passed by setting AS Number field to zero and Direction field to
      INCOMPLETE.  If the direction code is not recognized, a
      notification message with subcode 2 (invalid direction code) is
      sent.

   AS Number: 16 bits

      This field is the AS number that transmitted the routing
      information.  If there is a problem with this AS number, a
      notification message with subcode 3 (invalid autonomous system) is
      sent.

   Net Count: 16 bits.

      The Net Count field is the number of Metric and Network field
      pairs which follow this field.  If there is a problem with this
      field, a notification with subcode 7 (invalid net count field) is
      sent.

   Network: 32 bits

      The Network field is four bytes of Internet network number.  If
      there is a problem with the network field, a notification message
      with subcode 8 (invalid network field) is sent.



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


   Metric: 16 bits

      The Metric field is 16 bits of an unspecified metric.  BGP metrics
      are comparable ONLY if routes have exactly the same AS path.  A
      metric of all ones indicates the network is unreachable.  In all
      other cases the metric field is MEANINGLESS and MUST BE IGNORED.
      There are no illegal metric values.

3.5  NOTIFICATION Message Format

   NOTIFICATION messages are sent when an error condition is detected.
   The BGP connection is closed shortly after sending the notification
   message.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Opcode               |           Data                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Opcode: 16 bits

      The Opcode field describes the type of NOTIFICATION.  The
      following opcodes have been defined.

            1 (*) - link type error in open.  Data is one byte of proper
                    link type.
            2 (*) - unknown authentication code.  No data.
            3 (*) - authentication failure.  No data.
            4     - update error.  See below for data description.
            5 (*) - connection out of sync.  No data.
            6 (*) - invalid message length.  Data is two bytes of
                    bad length.
            7 (*) - invalid message type.  Data is one byte of bad
                    message type.
            8 (*) - invalid version number.  Data is one byte of
                    bad version.
            9 (*) - invalid AS field in OPEN.  No data.
           10 (*) - BGP Cease.  No data.

      The starred opcodes in the list above are considered fatal errors
      and cause transport connection termination.

      The update error (opcode 4) has as data 16 bits of subcode
      followed by the last UPDATE message in question.  After the
      subcode comes as much of the data portion of the UPDATE in



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


      question as possible.  The following subcodes are defined:

               1 - invalid AS count
               2 - invalid direction code
               3 - invalid autonomous system
               4 - EGP_LINK or INCOMPLETE_LINK link type at other than
                   the end of the AS path list
               5 - routing loop
               6 - invalid gateway field
               7 - invalid Net Count field
               8 - invalid network field

   Data: variable

      The Data field contains zero or more bytes of data to be used in
      diagnosing the reason for the NOTIFICATION.  The contents of the
      Data field depend upon the opcode.  See the opcode descriptions
      above for more details.

3.6 KEEPALIVE Message Format

   BGP does not use any transport protocol based keepalive mechanism to
   determine if peers are reachable.  Instead KEEPALIVE messages are
   exchanged between peers often enough as not to cause the hold time
   (as advertised in the BGP header) to expire.  A reasonable minimum
   frequency of KEEPALIVE exchange would be one third of the Hold Time
   interval.

   As soon as the Hold Time associated with BGP peer has expired, the
   BGP connection is closed and BGP deallocates all resources associated
   with this peer.

   The KEEPALIVE message is a BGP header without any data.

4. BGP Finite State machine.

   This section specifies BGP operation in terms of a Finite State
   Machine (FSM).  Following is a brief summary and overview of BGP
   operations by state as determined by this FSM.  A condensed version
   of the BGP FSM is found in Appendix 1.

   Initially BGP is in the BGP_Idle state.

   BGP_Idle state:

      In this state BGP refuses all incoming BGP connections.  No
      resources are allocated to the BGP neighbor.  In response to the
      Start event (initiated by either system or operator) the local



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


      system initializes all BGP resources and changes its state to
      BGP_Active.

   BGP_Active state:

      In this state BGP is trying to acquire a BGP neighbor by opening a
      transport protocol connection.  If the transport protocol open
      fails (for example, retransmission timeout),  BGP stays in the
      BGP_Active state.

      Otherwise,  the local system sends an OPEN message to its peer,
      and changes its state to BGP_OpenSent.  Since the hold time of the
      peer is still undetermined, the hold time is initialized to some
      large value.

      In response to the Stop event (initiated by either system or
      operator) the local system releases all BGP resources and changes
      its state to BGP_Idle.

   BGP_OpenSent state:

      In this state BGP waits for an OPEN message from its peer.  When
      an OPEN message is received, all fields are checked for
      correctness.  If the initial BGP header checking detects an error,
      BGP deallocates all resources associated with this peer and
      returns to the BGP_Active state.  Otherwise, the Link Type,
      Authentication Code, and Authentication Data fields are checked
      for correctness.

      If the link type is incorrect, a NOTIFICATION message with opcode
      1 (link type error in open) is sent.  The following combination of
      link type fields are correct; all other combinations are invalid.

                      Our view         Peer view
                      UP                DOWN
                      DOWN              UP
                      INTERNAL          INTERNAL
                      H-LINK            H-LINK

      If the link between two peers is INTERNAL, then AS number of both
      peers must be the same.  Otherwise, a NOTIFICATION message with
      opcode 1 (link type error in open) is sent.

      If both peers have the same AS number and the link type between
      these peers is not INTERNAL, then a NOTIFICATION message with
      opcode 1 (link type error in open) is sent.

      If the value of the Authentication Code field is zero, any



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


      information in the Authentication Data field (if present) is
      ignored.  If the Authentication Code field is non-zero it is
      checked for known authentication codes.  If authentication code is
      unknown, then the BGP NOTIFICATION message with opcode 2 (unknown
      authentication code) is sent.

      If the Authentication Code value is non-zero, then the
      corresponding authentication procedure is invoked.  The default
      values are a zero Authentication Code and no Authentication Data.

      If any of the above tests detect an error, the local system closes
      the BGP connection and changes its state to BGP_Idle.

      If there are no errors in the BGP OPEN message, BGP sends an OPEN
      CONFIRM message and goes into the BGP_OpenConfirm state.  At this
      point the hold timer which was originally set to some arbitrary
      large value (see above) is replaced with the value indicated in
      the OPEN message.

      If disconnect notification is received from the underlying
      transport protocol or if the hold time expires, the local system
      closes the BGP connection and changes its state to BGP_Idle.

   BGP_OpenConfirm state:

      In this state BGP waits for an OPEN CONFIRM message.  As soon as
      this message is received, BGP changes its state to
      BGP_Established.  If the hold timer expires before an OPEN CONFIRM
      message is received, the local system closes the BGP connection
      and changes its state to BGP_Idle.

   BGP_Established state:

      In the BGP_Established state BGP can exchange UPDATE,
      NOTIFICATION, and KEEPALIVE messages with its peer.

      If disconnect notification is received from the underlying
      transport protocol or if the hold time expires, the local system
      closes the BGP connection and changes its state to BGP_Idle.

      In response to the Stop event initiated by either the system or
      operator, the local system sends a NOTIFICATION message with
      opcode 10 (BGP Cease), closes the BGP connection, and changes its
      state to BGP_Idle.







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


5. UPDATE Message Handling

   A BGP UPDATE message may be received only in the BGP_Established
   state.  When a BGP UPDATE message is received, each field is checked
   for validity.  When a NOTIFICATION message is sent regarding an
   UPDATE, the opcode is always 4 (update error), the subcode depends on
   the type of error, and the rest of the data field is as much as
   possible of the data portion of the UPDATE that caused the error.

   If the Gateway field is incorrect, a BGP NOTIFICATION message is sent
   with subcode 6 (invalid gateway field).  All information in this
   UPDATE message is discarded.

   If the AS Count field is less than or equal to zero, a BGP
   NOTIFICATION is sent with subcode 1 (invalid AS count).  Otherwise,
   the complete AS path is extracted and checked as described below.