rfc1403.txt

<VC++网络游戏建摸与实现>源代码

         This SHOULD be used for importing routes into OSPF from an IGP.

      4.4.5.  Routes with complete path information, PathLength = 1.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with either
         complete path information, or are known to be complete through
         means other than that carried by the routing protocol.  The
         routing protocol also has additional information about the
         neighbour AS of the route.

         The OSPF tag to BGP attribute mappings for these routes MUST be

         Automatic=1, Completeness=1, PathLength=01, AS=next_hop_AS
                        => ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS>

         This setting SHOULD be used when the administrator explicitly
         associates an AS number with an instance of an IGP.  This
         setting MAY also be used when importing BGP routes whose
         ORIGIN=<IGP> and AS_PATH=<next_hop_AS>;  if the BGP learned
         route has no other transitive attributes, then its propagation
         via BGP to other ASBRs internal to the AS MAY be suppressed.







Varadhan                                                       [Page 12]

RFC 1403                  BGP OSPF Interaction              January 1993


      4.4.6.  Routes with complete path information, PathLength >= 1.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|1|0|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with complete
         path information and carry the AS path information as part of
         the routing information.

         The OSPF tag MUST be set to

         Automatic=1, Completeness=1, PathLength=10, AS=don't care

         These routes MUST not be exported into BGP because these routes
         are already imported from BGP into the OSPF RD.  Hence, it is
         assumed that the BGP speaker will convey this information to
         other BGP speakers within the same AS via BGP.  An ASBR
         learning of such a route MUST wait for the BGP update from its
         internal neighbours before advertising this route to external
         BGP peers.

         Note that an implementation MAY import BGP routes with a path
         length of 1 and no other transitive attributes directly into
         OSPF and not send these routes via BGP to ASBRs within the same
         AS.  In this situation, it MUST use tag settings corresponding
         to 4.4.2, or 4.4.5.

   4.5.  Miscellaneous tag settings

      0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|x|1|1|              Reserved  for  future  use               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The value of PathLength=11 is reserved during automatic tag
      generation.  Routers MUST not generate such a tag when importing
      routes into the OSPF routing domain.  ASBRs MUST ignore tags which
      indicate a PathLength=11.









Varadhan                                                       [Page 13]

RFC 1403                  BGP OSPF Interaction              January 1993


   4.6.  Summary of the tag sub-field setting

      The following table summarises the various combinations of
      automatic tag settings for the Completeness and PathLength sub-
      field of the OSPF tag and the default behaviour permitted for each
      setting.

                  Completeness := 0 | 1
                  PathLength := 00 | 01 | 10 | 11
                  ORIGIN := <INCOMPLETE> | <IGP> | <EGP>
                  AS_PATH := valid AS path settings as defined in BGP

PathLength ==> 00               01                   10            11
Completeness
  ||     +--------------------------------------------------------------
  vv     |
  =  NO  |    <EGP>            <EGP>             never export   reserved
         |  <local_AS>  <local_AS,next_hop_AS>
         |
  = YES  |    <IGP>            <IGP>             out of band    reserved
         |  <local_AS>  <local_AS,next_hop_AS>
         |

      The "out of band" in the table above implies that OSPF will not be
      able to carry everything that BGP needs in its routing
      information.  Therefore, some other means must be found to carry
      this information.  In BGP, this is done by running BGP to other
      ASBRs within the same AS.

5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute

   Forwarding addresses are used to avoid extra hops between multiple
   routers that share a common network and that speak different routing
   protocols with each other.

   Both BGP and OSPF have equivalents of forwarding addresses.  In BGP,
   the NEXT_HOP attribute is a well-known, mandatory attribute.  OSPF
   has a Forwarding address field.  We will discuss how these are to be
   filled in various situations.












Varadhan                                                       [Page 14]

RFC 1403                  BGP OSPF Interaction              January 1993



   Consider the 4 router situation below:

   RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
   RT1 and RT3 are talking BGP with each other.
   RT3 and RT4 are talking OSPF with each other.

            +-----+                 +-----+
            | RT1 |                 | RT2 |
            +-----+                 +-----+
               |                       |            common network
            ---+-----------------------+--------------------------
                 <BGP> |                       |
                    +-----+     <OSPF>      +-----+
                    | RT3 |                 | RT4 |
                    +-----+                 +-----+


     - Importing network X to OSPF:
          Consider an external network X, learnt via BGP from RT1.

          RT3 MUST always fill the OSPF Forwarding Address with the BGP
          NEXT_HOP attribute for the route to network X.

     - Exporting network Y to BGP:
          Consider a network Y, internal to the OSPF routing domain,
          RT3's route to network Y is via RT4, and network Y is to be
          exported via BGP to RT1.

          If network Y is not a subnetted network, RT3 MUST fill the
          NEXT_HOP attribute for network Y with the address of RT4.
          This is to avoid requiring packets to take an extra hop
          through RT3 when traversing the AS boundary.  This is similar
          to the concept of indirect neighbour support in EGP [RFC888,
          RFC827].

6.  Security Considerations

   Security issues are not discussed in this memo.

7.  Acknowledgements

   I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li,
   Dennis Ferguson, and Phil Almquist for their help and suggestions in
   writing this document, without which I could not have written this
   document.  I would also like to thank them for giving me the
   opportunity to write this document, and putting up with my
   muddlements through various phases of this document.



Varadhan                                                       [Page 15]

RFC 1403                  BGP OSPF Interaction              January 1993


   I would also like to thank the countless number of people from the
   OSPF and BGP working groups who have offered numerous suggestions and
   comments on the different stages of this document.

   Thanks also to Bob Braden, who went through the document thoroughly,
   and came back with questions and comments, which were very useful.
   These suggestions have also been carried over into the next version
   of this document for dealing with BGP 4 and OSPF.

8.  Bibliography

   [RFC827]  Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827,
             BBN, October 1982.

   [RFC888]  Seamonson, L., and E. Rosen, "STUB Exterior Gateway
             Protocol", RFC 888, BBN, January 1984.

   [RFC1058]  Hedrick, C., "Routing Information Protocol", STD 34,
              RFC 1058, Rutgers University, June 1988.

   [RFC1388]  Malkin, G., "RIP Version 2 - Carrying Additional
              Information", RFC 1388, Xylogics, Inc., January 1993.

   [RFC1122]  Braden, R., Editor, "Requirements for Internet Hosts -
              Communication Layers, STD 3, RFC 1122,
              USC/Information Sciences Institute, October 1989.

   [RFC1123]  Braden, R., Editor, "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              USC/Information Sciences Institute, October 1989.

   [RFC1267]  Lougheed, K., and Y. Rekhter, "A Border Gateway
              Protocol 3 (BGP-3)", RFC 1267, cisco Systems,
              T.J. Watson Research Center, IBM Corp., October 1991.

   [RFC1268]  Rekhter, Y., and P. Gross, Editors, "Application of the
              Border Gateway Protocol in the Internet", RFC 1268,
              T.J. Watson Research Center, IBM Corp., ANS, October 1991.

   [RFC1247]  Moy, J., "The OSPF Specification - Version 2:", RFC 1247,
              Proteon, January 1991.

   [ROUTE-LEAKING]  Almquist, P., "Ruminations on Route Leaking",
                    Work in Progress.

   [NEXT-HOP]  Almquist, P., "Ruminations on the Next Hop",
               Work in Progress.




Varadhan                                                       [Page 16]

RFC 1403                  BGP OSPF Interaction              January 1993


9.  Author's  Address:

      Kannan Varadhan
      Internet Engineer, OARnet,
      1224, Kinnear Road,
      Columbus, OH 43212-1136.

      Phone: [phone]

      Email: [e-mail]









































Varadhan                                                       [Page 17]