rfc1787.txt

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


RFC 1787          Routing in a multi-provider Internet        April 1995


   Scaling implies that the Internet routing system needs to have
   powerful mechanisms to provide routing information
   aggregation/abstraction.

   In the absence of Internet-wide coordination and in the presence of
   competition among the providers, the aggregation/abstraction
   mechanisms should minimize preconditions as well as limit the amount
   of required inter-provider coordination. Ideally the routing system
   should allow a provider to control the amount of its local resources
   needed to deal with the routing overhead based on considerations that
   are purely local to the provider.

   One of the side effects of the routing information
   aggregation/abstraction is that some of the routing information is
   going to be lost. This may impact route optimality and even the
   ability to find an existing route. The need for routing information
   aggregation/abstraction also implies certain homogeneity of the
   information to be aggregated/abstracted. This needs to be counter-
   balanced against the potential diversity of routing requirements.

   As a way to deal with the routing information loss due to
   aggregation/abstraction, we need to explore mechanisms that allow
   routing that is based on the on-demand acquisition of subsets of
   unaggregated information.

   The overhead associated with supporting specific routing requirements
   has a direct impact on the overall scalability of the Internet
   routing system. We need to get a better understanding of how various
   routing requirements impact scalability. When the impact is
   significant, and the requirements have practical importance we need
   to develop mechanisms that allow the impact to be reduced.

6. Hierarchical Routing

   Classless Inter-Domain Routing (CIDR) (RFC1518, RFC1519) that is used
   today for scalable Internet-wide routing is based on the technique of
   hierarchical routing. Essential to this technique is the assumption
   that Network layer addresses assigned to individual entities (e.g.,
   hosts, routers) reflect the position of these entities within the
   network topology -- addresses are said to be "topologically
   significant". With CIDR addresses assigned to most of the individual
   sites are expected to reflect providers the sites are connected to --
   CIDR uses "provider-based" addresses.

   One of the fundamental consequences of using hierarchical routing is
   that in order to preserve topological significance of network
   addresses, changes in the network topology may need to be accompanied
   by the corresponding changes in the addresses. Presence of multiple



Rekhter                                                         [Page 5]

RFC 1787          Routing in a multi-provider Internet        April 1995


   providers serving the same geographical area implies that a
   subscriber should be able to switch from one provider to another.
   Since such a switch implies changes in the Internet topology, it
   follows that to retain topological significance of the (provider-
   based) addresses within the subscriber, the subscriber has to change
   the addresses of all of its entities -- the process known as
   "renumbering". There are already tools to facilitate this process --
   Dynamic Host Configuration Protocol (DHCP).  However, DHCP is not yet
   widely deployed. Further work is needed to improve these tools, get
   them widely deployed, and to integrate them with Domain Name System
   (DNS).

   Multi-level hierarchical routing allows for recapturing additional
   routing information (routing entropy) due to the mismatch between
   addresses and topology at a particular level in the routing hierarchy
   at some higher level in the hierarchy (e.g., at an exchange point
   among providers).  This enables the routing system to contain the
   scope of entities impacted by the mismatch. Containing the scope of
   entities could be an important factor to facilitate graceful
   renumbering.  Further work is needed to develop appropriate
   deployment strategies to put these capabilities in place.

   It is important to emphasize that the requirement to maintain
   topologically significant addresses doesn't need to be applied
   indiscriminately to all the organizations connected to the Internet
   -- hierarchical routing requires that most, but not all addresses be
   topologically significant.  For a large organization it could be
   sufficient if the set of destinations within the organization can be
   represented within the Internet routing system as a small number of
   address prefixes, even if these address prefixes are independent of
   the providers that the organization uses to connect to the Internet
   ("provider-independent" addresses). The volume of routing information
   that a large organization would inject into the Internet routing
   system would be comparable to the (aggregated) routing information
   associated with a large number of small organizations.

   Existence of multiple providers allows a subscriber to be
   simultaneously connected to more than one provider (multi-homed
   subscribers). CIDR offers several alternatives for handling such
   cases. We need to gain more operational experience as well as better
   understand tradeoffs associated with the proposed alternatives.

   An alternative to CIDR address assignment is to assign addresses
   based purely on the geographical location. However, address
   assignment that reflects geographical location of an entity implies
   that either (a) the Internet topology needs to be made sufficiently
   congruent to the geography, or (b) addresses aren't going to be
   topologically significant. In the former case we need to understand



Rekhter                                                         [Page 6]

RFC 1787          Routing in a multi-provider Internet        April 1995


   the driving forces that would make the topology congruent to the
   geography. In the latter case techniques other than hierarchical
   routing need to be developed.

7. Routing Information Sharing

   While ensuring Internet-wide coordination may be more and more
   difficult, as the Internet continues to grow, stability and
   consistency of the Internet-wide routing could significantly benefit
   if the information about routing requirements of various
   organizations could be shared across organizational boundaries. Such
   information could be used in a wide variety of situations ranging
   from troubleshooting to detecting and eliminating conflicting routing
   requirements. The scale of the Internet implies that the information
   should be distributed. Work is currently underway to establish
   depositories of this information (Routing Registries), as well as to
   develop tools that analyze, as well as utilize this information.

8. Summary

   In this section we enumerate some of the issues that the IAB thinks
   should be brought to the attention of the Internet community.

   The following two tasks require the most immediate attention:

      - further work is needed to develop technologies that facilitate
        renumbering

      - further work is needed to investigate feasibility of routing
        information aggregation above the direct (immediate) provider
        level

   The following tasks are viewed as medium term:

      - further work is needed to get a better understanding on the
        relative practical importance of various routing requirements

      - further work is needed to understand of how various routing
        requirements impact scalability of the routing system

      - further work is needed to investigate alternatives to
        hierarchical routing

   Finally, the following tasks are viewed as long term:

      - further work is needed to understand and utilize the benefits of
        routing information sharing




Rekhter                                                         [Page 7]

RFC 1787          Routing in a multi-provider Internet        April 1995


      - further work is needed to understand the implications of virtual
        overlays created via encapsulation

      - further work is needed to understand how different price
        structures influence routing requirements

      - further work is needed to understand how to balance the
        providers' goals and objectives against the public interest of
        Internet-wide connectivity and subscribers' choices.

9. Conclusions

   This document presents some of the issues related to routing in a
   multi-provider Internet. There are no doubt routing-related areas
   that are not covered in this document. For instance, such areas as
   multicast routing, or routing in the presence of mobile hosts, or
   routing in the presence of a large shared media (e.g., ATM) aren't
   discussed here. Further work is needed to understand the implications
   of a multi-provider Internet on these areas.

   The impact of multi-provider Internet goes well beyond just routing,
   and percolates into such areas as network management,
   troubleshooting, and others. Further work is needed to assess the
   implications of multi-provider environment on these areas, as well as
   to understand the interaction among all these areas from a system-
   wide perspective.

10. Acknowledgments

   Many thanks to all the IAB members, and especially to Brian
   Carpenter, Robert Elz, Christian Huitema, Paul Mockapetris, and Lixia
   Zhang for their contributions to this document.

Security Considerations

   Security issues are not discussed in this memo.

Editor's Address

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 704, Office H3-D40
   Yorktown Heights, NY 10598

   Phone:  [phone]
   EMail:  [e-mail]





Rekhter                                                         [Page 8]