rfc1322.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,376 行 · 第 1/5 页

Estrin, Rekhter & Hotz                                          [Page 5]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


2.1.2 Computational Overhead

   The NR component will rely primarily on precomputation of routes.  If
   inter-domain routing is ubiquitous, then the precomputed routes
   include all reachable destinations.  Even if policy constraints make
   fully ubiquitous routing impossible, the precomputed routes are
   likely to cover a very large percentage of all reachable
   destinations.  Therefore the complexity of this computation must be
   as small as possible.  Specifically, it is highly desirable that the
   architecture would employ some form of partial computation, where
   changes in topology would require less than complete recomputation.
   Even if complete recomputation is necessary, its complexity should be
   less than linear with the total number of domains.

   The SDR component will use on-demand computation and caching.
   Therefore the complexity of this computation can be somewhat higher.
   Another reason for relaxed complexity requirements for SDR is that
   SDR is expected to compute routes to a smaller number of destinations
   than is NR (although SDR route computation may be invoked more
   frequently).

   Under no circumstances is computational complexity allowed to become
   exponential (for either the NR or SDR component).

2.1.3 Bandwidth Overhead

   The bandwidth consumed by routing information distribution should be
   limited.  However, the possible use of data compression techniques
   and the increasing speed of network links make this less important
   than route computation and storage overhead.  Bandwidth overhead may
   be further contained by using incremental (rather than complete)
   exchange of routing information.

   While storage and bandwidth overhead may be interrelated, if
   incremental updates are used then bandwidth overhead is negligible in
   the steady state (no changes in topology), and is independent of the
   storage overhead.  In other words, use of incremental updates
   constrains the bandwidth overhead to the dynamics of the internet.
   Therefore, improvements in stability of the physical links, combined
   with techniques to dampen the effect of topological instabilities,
   will make the bandwidth overhead even less important.

2.2 Aggregation

   Aggregation and abstraction of routing and forwarding information
   provides a very powerful mechanism for satisfying storage,
   computational, and bandwidth constraints.  The ability to aggregate,
   and subsequently abstract, routing and forwarding information is



Estrin, Rekhter & Hotz                                          [Page 6]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


   essential to the scaling of the architecture [Footnote: While we can
   not prove that there are no other ways to achieve scaling, we are not
   aware of any mechanism other than clustering that allows information
   aggregation/abstraction.  Therefore, the rest of the paper assumes
   that clustering is used for information aggregation/abstraction.].
   This is especially true with respect to the NR component, since the
   NR component must be capable of providing routes to all or almost all
   reachable destinations.

   At the same time, since preserving each domain's independence and
   autonomy is one of the crucial requirements of inter-domain routing,
   the architecture must strive for the maximum flexibility of its
   aggregation scheme, i.e., impose as few preconditions, and as little
   global coordination, as possible on the participating domains.

   The Routing Information Base (RIB) carries three types of
   information: (1) topology (i.e., the interconnections between domains
   or groups of domains), (2) network layer reachability, and (3)
   transit constraint.  Aggregation of routing information should
   provide a reduction of all three components.  Aggregation of
   forwarding information will follow from reachability information
   aggregation.

   Clustering (by forming routing domain confederations) serves the
   following aggregation functions: (1) to hide parts of the actual
   physical topology, thus abstracting topological information, (2) to
   combine a set of reachable destination entities into a single entity
   and reduce storage overhead, and (3) to express transit constraints
   in terms of clusters, rather than individual domains.

   As argued in [Breslau-Estrin91], the architecture must allow
   confederations to be formed and changed without extensive
   configuration and coordination; in particular, forming a
   confederation should not require global coordination (such as that
   required in ECMA ([ECMA89]).  In addition, aggregation should not
   require explicit designation of the relative placement of each domain
   relative to another; i.e., domains or confederations of domains
   should not be required to agree on a partial ordering (i.e., who is
   above whom, etc.).












Estrin, Rekhter & Hotz                                          [Page 7]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


   The architecture should allow different domains to use different
   methods of aggregation and abstraction.  For example, a research
   collaborator at IBM might route to USC as a domain-level entity in
   order to take advantage of some special TOS connectivity to, or even
   through, USC.  Whereas, someone else at Digital Equipment Corporation
   might see information at the level of the California Educational
   Institutions Confederation, and know only that USC is a member.
   Alternatively, USC might see part of the internal structure within
   the IBM Confederation (at the domain's level), whereas UCLA may route
   based on the confederation of IBM domains as a whole.

   Support for confederations should be flexible.  Specifically, the
   architecture should allow confederations to overlap without being
   nested, i.e., a single domain, or a group of domains may be part of
   more than one confederation.  For example, USC may be part of the
   California Educational Institutions Confederation and part of the US
   R&D Institutions Confederation; one is not a subset of the other.
   Another example: T.J.  Watson Research Center might be part of
   NYSERNET Confederation and part of IBM-R&D-US Confederation.  While
   the above examples describe cases where overlap consists of a single
   domain, there may be other cases where multiple domains overlap.  As
   an example consider the set of domains that form the IBM
   Confederation, and another set of domains that form the DEC
   Confederation.  Within IBM there is a domain IBM-Research, and
   similarly within DEC there is a domain DEC-Research.  Both of these
   domains could be involved in some collaborative effort, and thus have
   established direct links.  The architecture should allow restricted
   use of these direct links, so that other domains within the IBM
   Confederation would not be able to use it to talk to other domains
   within the DEC Confederation.  A similar example exists when a
   multinational corporation forms a confederation, and the individual
   branches within each country also belong to their respective country
   confederations.  The corporation may need to protect itself from
   being used as an inter-country transit domain (due to internal, or
   international, policy).  All of the above examples illustrate a
   situation where confederations overlap, and it is necessary to
   control the traffic traversing the overlapping resources.

   While flexible aggregation should be accommodated in any inter-domain
   architecture, the extent to which this feature is exploited will have
   direct a effect on the scalability associated with aggregation.  At
   the same time, the exploitation of this feature depends on the way
   addresses are assigned.  Specifically, scaling associated with
   forwarding information depends heavily on the assumption that there
   will be general correspondence between the hierarchy of address
   registration authorities, and the way routing domains and routing
   domain confederations are organized (see Section 2.6).




Estrin, Rekhter & Hotz                                          [Page 8]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


2.3 Routing Policies

   Routing policies that the architecture must support may be broadly
   classified into transit policies and route selection policies
   [Breslau-Estrin 91, Estrin89].

   Restrictions imposed via transit policies may be based on a variety
   of factors.  The architecture should be able to support restrictions
   based on the source, destination, type of services (TOS), user class
   identification (UCI), charging, and path [Estrin89 , Little89].  The
   architecture must allow expression of transit policies on all routes,
   both NR and SDR.  Even if NR routes are widely used and have fewer
   source or destination restrictions, NR routes may have some transit
   qualifiers (e.g., TOS, charging, or user-class restriction).  If the
   most widely-usable route to a destination has policy qualifiers, it
   should be advertiseable by NR and the transit constraints should be
   explicit.

   Route selection policies enable each domain to select a particular
   route among multiple routes to the same destination.  To maintain
   maximum autonomy and independence between domains, the architecture
   must support heterogeneous route selection policies, where each
   domain can establish its own criteria for selecting routes.  This
   argument was made earlier with respect to source route selection
   ([IDPR90, Clark90, Breslau-Estrin91]).  In addition, each
   intermediate transit domain must have the flexibility to apply its
   own selection criteria to the routes made available to it by its
   neighbors.  This is really just a corollary to the above; i.e., if we
   allow route selection policy to be expressed for NR routes, we can
   not assume all domains will apply the same policy.  The support for
   dissimilar route selection policies is one of the key factors that
   distinguish inter-domain routing from intra-domain routing ([ECMA89,
   Estrin89]).  However, it is a non-goal of the architecture to support
   all possible route selection policies.  For more on unsupported route
   selection policies see Section 2.3.2 below.

2.3.1 Routing Information Hiding

   The architecture should not require all domains within an internet to
   reveal their connectivity and transit constraints to each other.
   Domains should be able to enforce their transit policies while
   limiting the advertisement of their policy and connectivity
   information as much as possible; such advertisement will be driven by
   a "need to know" criteria.  Moreover, advertising a transit policy to
   domains that can not use this policy will increase the amount of
   routing information that must be stored, processed, and propagated.
   Not only may it be impractical for a router to maintain full inter-
   domain topology and policy information, it may not be permitted to



Estrin, Rekhter & Hotz                                          [Page 9]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


   obtain this information.

2.3.2 Policies Not Supported

   In this and previous papers we have argued that a global inter-domain
   routing architecture should support a wide range of policies.  In
   this section we identify several types of policy that we explicitly
   do not propose to support.  In general our reasoning is pragmatic; we
   think such policy types are either very expensive in terms of
   overhead, or may lead to routing instabilities.

   1. Route selection policies contingent on external behavior.
      The route selection process may be modeled by a function that
      assigns a non-negative integer to a route, denoting the degree
      of preference.  Route selection applies this function to all
      feasible routes to a given destination, and selects the route
      with the highest value.  To provide a stable environment, the
      preference function should not use as an input the status and
      attributes of other routes (either to the same or to a
      different destination).

   2. Transit policies contingent on external behavior.
      To provide a stable environment, the domain's transit policies
      can not be automatically affected by any information external
      to the domain.  Specifically, these policies can not be modified,
      automatically, in response to information about other domains'
      transit policies, or routes selected by local or other domains.
      Similarly, transit policies can not be automatically modified
      in response to information about performance characteristics of
      either local or external domains.

   3. Policies contingent on external state (e.g., load).
      It is a non-goal of the architecture to support load-sensitive
      routing for generic routes.  However, it is possible that some
      types of service may employ load information to select among
      alternate SDR routes.

   4. Very large number of simultaneous SDR routes.
      It is a non-goal of the architecture to support a very large
      number of simultaneous SDR routes through any single router.
      Specifically, the FIB storage overhead associated with SDR
      routes must be comparable with that of NR routes, and should