rfc1105.txt

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

   If one of the Direction fields in the AS route list is not defined, a
   BGP NOTIFICATION message is with subcode 2 (invalid direction code).

   If one of the AS Number fields in the AS route list is incorrect, a
   BGP NOTIFICATION message is sent with subcode 3 (invalid autonomous
   system).

   If either a EGP_LINK or a INCOMPLETE_LINK link type occurs at other
   than the end of the AS path, a BGP NOTIFICATION message is sent with
   subcode 4 (EGP_LINK or INCOMPLETE_LINK link type at other than the
   end of the AS path list).

   If none of the above tests failed, the full AS route is checked for
   AS loops.

   AS loop detection is done by scanning the full AS route and checking
   that each AS in this route occurs only once.  If an AS loop is
   detected, a BGP NOTIFICATION message is sent with subcode 5 (routing
   loop).

   If any of the above errors are detected, no further processing is
   done.  Otherwise, the complete AS path is correct and the rest of the
   UPDATE message is processed.

   If the Net Count field is incorrect, a BGP NOTIFICATION message is
   sent with subcode 7 (invalid Net Count field).

   Each network and metric pair listed in the BGP UPDATE message is
   checked for a valid network number.  If the Network field is
   incorrect, a BGP Notification message is sent with subcode 8 (invalid
   network field).  No checking is done on the metric field.  It is up



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


   to a particular implementation to decide whether to continue
   processing or terminate it upon the first incorrect network.

   If the network, its complete AS path, and the gateway are correct,
   then the route is compared with other routes to the same network.  If
   the new route is better than the current one, then it is flooded to
   other BGP peers as follows:

    - If the BGP UPDATE was received over the INTERNAL link, it is not
      propagated over any other INTERNAL link.  This restriction is
      due to the fact that all BGP gateways within a single AS
      form a completely connected graph (see above).

    - Before sending a BGP UPDATE message over the non-INTERNAL links,
      check the AS path to insure that doing so would not cause a
      routing loop.  The BGP UPDATE message is then propagated (subject
      to the local policy restrictions) over any of the non-INTERNAL
      link of a routing loop would not result.

    - If the BGP UPDATE message is propagated over a non-INTERNAL link,
      then the current AS number and link type of the link over which
      it is going to be propagated is prepended to the full AS path
      and the AS count field is incremented by 1.  If the BGP UPDATE
      message is propagated over an INTERNAL link, then the full AS
      path passed unmodified and the AS count stays the same.  The
      Gateway field is replaced with the sender's own address.

6. Acknowledgements

   We would like to express our thanks to Len Bosack (cisco Systems),
   Jeff Honig (Cornell University) and all members of the IWG task force
   for their contributions to this document.



















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


                                Appendix 1

BGP FSM State Transitions and Actions.

   This Appendix discusses the transitions between states in the BGP FSM
   in response to BGP events.  The following is the list of these states
   and events.

       BGP States:

            1 - BGP_Idle
            2 - BGP_Active
            3 - BGP_OpenSent
            4 - BGP_OpenConfirm
            5 - BGP_Established

       BGP Events:

            1 - BGP Start
            2 - BGP Transport connection open
            3 - BGP Transport connection closed
            4 - BGP Transport connection open failed
            5 - Receive OPEN message
            6 - Receive OPEN CONFIRM message
            7 - Receive KEEPALIVE message
            8 - Receive UPDATE messages
            9 - Receive NOTIFICATION message
           10 - Holdtime timer expired
           11 - KeepAlive timer expired
           12 - Receive CEASE message
           13 - BGP Stop

   The following table describes the state transitions of the BGP FSM
   and the actions triggered by these transitions.

















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


   Event                Actions               Message Sent   Next State
   --------------------------------------------------------------------
   BGP_Idle (1)
     1            Initialize resources           none             2
   BGP_Active (2)
     2           Initialize resources            OPEN             3
     4                   none                    none             2
    13           Release resources               none             1

   BGP_OpenSent(3)
    3                    none                    none             1
    5            Process OPEN is OK            OPEN CONFIRM       4
                 Process OPEN Message failed   NOTIFICATION       1
   11            Restart KeepAlive timer       KEEPALIVE          3
   13            Release resources               none             1

   BGP_OpenConfirm (4)
    6            Complete initialization         none             5
    3                   none                     none             1
   10            Close transport connection      none             1
   11            Restart KeepAlive timer       KEEPALIVE          4
   13            Release resources               none             1

   BGP_Established (5)
    7            Process KEEPALIVE               none             5
    8            Process UPDATE is OK          UPDATE             5
                 Process UPDATE failed         NOTIFICATION       5
    9            Process NOTIFICATION            none             5
   10            Close transport connection      none             1
   11            Restart KeepAlive timer       KEEPALIVE          5
   12            Close transport connection    NOTIFICATION       1
   13            Release resources               none             1
   --------------------------------------------------------------------

   All other state-event combinations are considered fatal errors and
   cause the termination of the BGP transport connection (if necessary)
   and a transition to the BGP_Idle state.














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


   The following is a condensed version of the above state transition
   table.

   Events|BGP_Idle BGP_Active BGP_OpenSent BGP_OpenConfirm BGP_Estab
         |  (1)   |    (2)   |     (3)    |      (4)      |      (5)
         |-------------------------------------------------------------
    1    |   2    |          |            |               |
         |        |          |            |               |
    2    |        |     3    |            |               |
         |        |          |            |               |
    3    |        |          |      1     |       1       |
         |        |          |            |               |
    4    |        |     2    |            |               |
         |        |          |            |               |
    5    |        |          |    4 or 1  |               |
         |        |          |            |               |
    6    |        |          |            |       5       |
         |        |          |            |               |
    7    |        |          |            |               |       5
         |        |          |            |               |
    8    |        |          |            |               |       5
         |        |          |            |               |
    9    |        |          |            |               |       5
         |        |          |            |               |
   10    |        |          |            |       1       |       1
         |        |          |            |               |
   11    |        |          |      3     |       4       |       5
         |        |          |            |               |
   12    |        |          |            |               |       1
         |        |          |            |               |
   13    |        |     1    |      1     |       1       |       1
         |        |          |            |               |
         --------------------------------------------------------------


















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


References

  [1]  Mills, D., "Exterior Gateway Protocol Formal Specification", RFC
       904, BBN, April 1984.

  [2]  Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
       Backbone", RFC 1092, T. J. Watson Research Center, February 1989.

  [3]  Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
       MERIT/NSFNET Project, February 1989.

  [4]  Postel, J., "Transmission Control Protocol - DARPA Internet
       Program Protocol Specification", RFC 793, DARPA, September 1981.

  [5]  Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC
       1045, Stanford University, February 1988.

Authors' Addresses

   Kirk Lougheed
   cisco Systems, Inc.
   1360 Willow Road, Suite 201
   Menlo Park, CA 94025

   Phone: [phone]

   Email: [e-mail]


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

   Phone: [phone]

   Email: [e-mail]













Lougheed & Rekhter                                             [Page 17]