rfc1133.txt

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


RFC 1133         Routing between the NSFNET and the DDN    November 1989


   low metric to create a primary path (e.g., metric "1") and via the
   second Mailbridge as a secondary path (e.g., metric "3").  For
   networks that have their own DDN connection and wish to use the
   NSFNET as a backup connection to DDN, the NSFNET will announce those
   networks via the two Mailbridges at higher metrics.

   The mid-level networks need to make a specific request if they want
   client networks to be announced to the DDN via the NSFNET. Those
   requests need to state whether this would be a primary connection for
   the specific networks.  If the request is for a fallback connection,
   it needs to state the existing metrics in use for announcements of
   the network to the DDN.

4.  Shortcomings of the current NSFNET/DDN interconnection routing

   The current setup makes full use of the two Mailbridges that connect
   to the NSFNET directly, with regard to redundancy and load sharing.
   However, with regard to performance optimization, such as packet
   propagation delay between source/destination pairs located on
   disjoint peer networks, there are some shortcomings.  These
   shortcomings are not easy to overcome because of the limitations of
   the current architecture.  However, it is a worthwhile topic for
   discussion to aid future improvements.

   To make the discussion easier, the following assumptions and
   terminology will be used:

      The NSFNET is viewed as a cloud and so is the DDN.  The two have
      two connections, one at east coast and one at west coast.

      mb-east -- the Mailbridge at Mitre

      mb-west -- the Mailbridge at Ames

      NSS-east -- the NSS egp peer with mb-east

      NSS-west -- the NSS egp peer with mb-west

      DDN.east-net -- networks connected to DDN and physically closer to
                      mb-east

      DDN.west-net -- networks connected to DDN and physically closer to
                      mb-west

      NSF.east-net -- networks connected to NSFNET and physically closer
                      to NSS-east

      NSF.west-net -- networks connected to NSFNET and physically closer



Yu & Braun                                                      [Page 6]

RFC 1133         Routing between the NSFNET and the DDN    November 1989


                      to NSS-west

   The traffic between NSFNET<->DDN will fall into the following
   patterns:

      a) NSF.east-net <-> DDN.east-net or
         NSF.west-net <-> DDN.west-net

      b) NSF.east-net <-> DDN.west-net or
         NSF.west-net <-> DDN.east-net

   The ideal traffic path for a) and b) should be as follows:

   For traffic pattern a)

        NSF.east-net<-->NSS.east<-->mb-east<-->DDN.east-net

   or

        NSF.west-net<-->NSS.west<-->mb-west<-->DDN.west-net

   For traffic pattern b)

        NSF.east-net-*->NSS.west-->mb-west-->DDN.west-net-**->mb-east
                                                                    |
                                              NSF.east-net<--NSS-east

   or

        NSF.west-net-*->NSS.east-->mb-east-->DDN.east-net-**->mb-west
                                                                    |
                                              NSF.west-net<--NSS-west


   Note:

        -*-> is used to indicate traffic transcontinentally traversing
        the NSFNET backbone

        -**-> is used to indicate traffic transcontinentally traversing
        the DDN backbone

        The traffic for a) will transcontinentally traverse NEITHER the
        NSFNET backbone, NOR the DDN backbone.

        The traffic for b) will transcontinentally traverse NSFNET once
        and DDN once and only once for each.




Yu & Braun                                                      [Page 7]

RFC 1133         Routing between the NSFNET and the DDN    November 1989


   For the current set up,

   The traffic path for pattern a) would have chances to
   transcontinentally traverse both NSFNET and DDN.

   The traffic path for pattern b) would have chances to
   transcontinentally traverse the DDN in both directions.

   To achieve the ideal traffic path it requires the NSFNET to implement
   (3) as stated above, i.e., to treat the DDN like other NSFNET peer or
   mid-level networks.  As mentioned before, discussions between NSFNET
   and DDN people are underway and the DDN is considering providing the
   NSFNET with the required information to accomplish the outlined goals
   in the near future.

   At such time as this is accomplished, it will reduce the likelihood
   of packet traffic unnecessarily traversing national backbones.

   One of the best ways to optimize the traffic between two peer
   networks, not necessary limited to the NSFNET and the DDN, is to try
   to avoid letting traffic traverse a backbone with a comparatively
   slower speed and/or a backbone with a significantly larger diameter
   network.  For example, in the case of traffic between the NSFNET and
   the DDN, the NSFNET has a T1 backbone and a maximum diameter of three
   hops, while the DDN is a relatively slow network running largely at
   56Kbps.  In this case the overall performance would be better if
   traffic would traverse the DDN as little as possible, i.e., whenever
   the traffic has to reach a destination network outside of the DDN, it
   should find the closest Mailbridge to exit the DDN.

   The current architecture employed for DDN routing is not able to
   accomplish this.  Firstly, the technology is designed based on a core
   model.  It does not expect a single network to be announced by
   multiple places.  An example for multiple announcements could be two
   NSSs announcing a single network number to the two Mailbridges at
   their different locations.  Secondly, the way all the existing
   Mailbridges exchange routing information among themselves is done via
   a protocol similar to EGP, and the information is then distributed
   via EGP to the DDN-external networks.  In this case the physical
   distance information and locations of network numbers is lost and
   neither the Mailbridges nor the external gateways will be able to do
   path optimization based on physical distance and/or propagation
   delay.  This is not easy to change, as in the DDN the link level
   routing information is decoupled from the IP level routing, i.e., the
   IP level routing has no information about topology of the physical
   infrastructure.  Thus, even if an external gateway to a DDN network
   were to learn a particular network route from two Mailbridges, it
   would not be able to favor one over the other DDN exit point based on



Yu & Braun                                                      [Page 8]

RFC 1133         Routing between the NSFNET and the DDN    November 1989


   the distance to the respective Mailbridge.

5.  Conclusions

   While recent changes in the interconnection architecture between the
   NSFNET and DDN peer networks have resulted in significant performance
   and reliability improvements, there are still possibilities for
   further improvements and rationalization of this inter-peer network
   routing.  However, to accomplish this it would most likely require
   significant architectural changes within the DDN.

6.  References

  [1]  Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
       Backbone", RFC 1092, IBM Research, February 1989.

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

  [3]  Collins, M., and R. Nitzan, "ESNET Routing", DRAFT Version 1.0,
       LLNL, May 1989.

  [4]  Braun, H-W., "Models of Policy Based Routing," RFC 1104,
       Merit/NSFNET Project, February 1989.

Security Considerations

   Security issues are not addressed in this memo.

Authors' Addresses

   Jessica (Jie Yun) Yu
   Merit Computer Network
   1075 Beal Avenue
   Ann Arbor, Michigan 48109

   Telephone:      [phone]
   Fax:            313 747-3745
   EMail:          [e-mail]

   Hans-Werner Braun
   Merit Computer Network
   1075 Beal Avenue
   Ann Arbor, Michigan 48109

   Telephone:      [phone]
   Fax:            313 747-3745
   EMail:          [e-mail]



Yu & Braun                                                      [Page 9]

RFC 1133         Routing between the NSFNET and the DDN    November 1989





















































Yu & Braun                                                     [Page 10]