rfc1518.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,251 行 · 第 1/5 页

   may use their prefix as the basis for subsequent suballocations,
   assuming that the IP addresses remain within the overall length and
   structure constraints.

   At this point, we observe that the number of nodes at each lower
   level of a hierarchy tends to grow exponentially. Thus the greatest
   gains in the reachability information abstraction (for the benefit of
   all higher levels of the hierarchy) occur when the reachability
   information aggregation occurs near the leaves of the hierarchy; the
   gains drop significantly at each higher level. Therefore, the law of
   diminishing returns suggests that at some point data abstraction
   ceases to produce significant benefits. Determination of the point at
   which data abstraction ceases to be of benefit requires a careful
   consideration of the number of routing domains that are expected to
   occur at each level of the hierarchy (over a given period of time),
   compared to the number of routing domains and address prefixes that
   can conveniently and efficiently be handled via dynamic inter-domain
   routing protocols.

4.1  Efficiency versus Decentralized Control

   If the Internet plans to support a decentralized address
   administration [4], then there is a balance that must be sought
   between the requirements on IP addresses for efficient routing and
   the need for decentralized address administration. A proposal
   described in [3] offers an example of how these two needs might be
   met.



Rekhter & Li                                                    [Page 5]

RFC 1518          CIDR Address Allocation Architecture    September 1993


   The IP address prefix <198.0.0.0 254.0.0.0> provides for
   administrative decentralization. This prefix identifies part of the
   IP address space allocated for North America. The lower order part of
   that prefix allows allocation of IP addresses along topological
   boundaries in support of increased data abstraction.  Clients within
   North America use parts of the IP address space that is underneath
   the IP address space of their service providers.  Within a routing
   domain addresses for subnetworks and hosts are allocated from the
   unique IP prefix assigned to the domain.

5.  IP Address Administration and Routing in the Internet

   The basic Internet routing components are service providers (e.g.,
   backbones, regional networks), and service subscribers (e.g., sites
   or campuses).  These components are arranged hierarchically for the
   most part.  A natural mapping from these components to IP routing
   components is that providers and subscribers act as routing domains.

   Alternatively, a subscriber (e.g., a site) may choose to operate as a
   part of a domain formed by a service provider. We assume that some,
   if not most, sites will prefer to operate as part of their provider's
   routing domain.  Such sites can exchange routing information with
   their provider via interior routing protocol route leaking or via an
   exterior routing protocol.  For the purposes of this discussion, the
   choice is not significant.  The site is still allocated a prefix from
   the provider's address space, and the provider will advertise its own
   prefix into inter-domain routing.

   Given such a mapping, where should address administration and
   allocation be performed to satisfy both administrative
   decentralization and data abstraction? The following possibilities
   are considered:

      - at some part within a routing domain,

      - at the leaf routing domain,

      - at the transit routing domain (TRD), and

      - at the continental boundaries.

      A point within a routing domain corresponds to a subnetwork. If a
      domain is composed of multiple subnetworks, they are
      interconnected via routers.  Leaf routing domains correspond to
      sites, where the primary purpose is to provide intra-domain
      routing services. Transit routing domains are deployed to carry
      transit (i.e., inter-domain) traffic; backbones and providers are
      TRDs.



Rekhter & Li                                                    [Page 6]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      The greatest burden in transmitting and operating on routing
      information is at the top of the routing hierarchy, where routing
      information tends to accumulate. In the Internet, for example,
      providers must manage the set of network numbers for all networks
      reachable through the provider. Traffic destined for other
      providers is generally routed to the backbones (which act as
      providers as well).  The backbones, however, must be cognizant of
      the network numbers for all attached providers and their
      associated networks.

      In general, the advantage of abstracting routing information at a
      given level of the routing hierarchy is greater at the higher
      levels of the hierarchy. There is relatively little direct benefit
      to the administration that performs the abstraction, since it must
      maintain routing information individually on each attached
      topological routing structure.

      For example, suppose that a given site is trying to decide whether
      to obtain an IP address prefix directly from the IP address space
      allocated for North America, or from the IP address space
      allocated to its service provider. If considering only their own
      self-interest, the site itself and the attached provider have
      little reason to choose one approach or the other. The site must
      use one prefix or another; the source of the prefix has little
      effect on routing efficiency within the site. The provider must
      maintain information about each attached site in order to route,
      regardless of any commonality in the prefixes of the sites.

      However, there is a difference when the provider distributes
      routing information to other providers (e.g., backbones or TRDs).
      In the first case, the provider cannot aggregate the site's
      address into its own prefix; the address must be explicitly listed
      in routing exchanges, resulting in an additional burden to other
      providers which must exchange and maintain this information.

      In the second case, each other provider (e.g., backbone or TRD)
      sees a single address prefix for the provider, which encompasses
      the new site. This avoids the exchange of additional routing
      information to identify the new site's address prefix. Thus, the
      advantages primarily accrue to other providers which maintain
      routing information about this site and provider.

      One might apply a supplier/consumer model to this problem: the
      higher level (e.g., a backbone) is a supplier of routing services,
      while the lower level (e.g., a TRD) is the consumer of these
      services. The price charged for services is based upon the cost of
      providing them.  The overhead of managing a large table of
      addresses for routing to an attached topological entity



Rekhter & Li                                                    [Page 7]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      contributes to this cost.

      The Internet, however, is not a market economy. Rather, efficient
      operation is based on cooperation. The recommendations discussed
      below describe simple and tractable ways of managing the IP
      address space that benefit the entire community.

5.1   Administration of IP addresses within a domain

      If individual subnetworks take their IP addresses from a myriad of
      unrelated IP address spaces, there will be effectively no data
      abstraction beyond what is built into existing intra-domain
      routing protocols.  For example, assume that within a routing
      domain uses three independent prefixes assigned from three
      different IP address spaces associated with three different
      attached providers.

      This has a negative effect on inter-domain routing, particularly
      on those other domains which need to maintain routes to this
      domain.  There is no common prefix that can be used to represent
      these IP addresses and therefore no summarization can take place
      at the routing domain boundary. When addresses are advertised by
      this routing domain to other routing domains, an enumerated list
      of the three individual prefixes must be used.

      This situation is roughly analogous to the present dissemination
      of routing information in the Internet, where each domain may have
      non-contiguous network numbers assigned to it.  The result of
      allowing subnetworks within a routing domain to take their IP
      addresses from unrelated IP address spaces is flat routing at the
      A/B/C class network level.  The number of IP prefixes that leaf
      routing domains would advertise is on the order of the number of
      attached network numbers; the number of prefixes a provider's
      routing domain would advertise is approximately the number of
      network numbers attached to the client leaf routing domains; and
      for a backbone this would be summed across all attached providers.
      This situation is just barely acceptable in the current Internet,
      and as the Internet grows this will quickly become intractable. A
      greater degree of hierarchical information reduction is necessary
      to allow continued growth in the Internet.

5.2   Administration at the Leaf Routing Domain

      As mentioned previously, the greatest degree of data abstraction
      comes at the lowest levels of the hierarchy. Providing each leaf
      routing domain (that is, site) with a prefix from its provider's
      prefix results in the biggest single increase in abstraction. From
      outside the leaf routing domain, the set of all addresses



Rekhter & Li                                                    [Page 8]

RFC 1518          CIDR Address Allocation Architecture    September 1993


      reachable in the domain can then be represented by a single
      prefix.  Further, all destinations reachable within the provider's
      prefix can be represented by a single prefix.

      For example, consider a single campus which is a leaf routing
      domain which would currently require 4 different IP networks.
      Under the new allocation scheme, they might instead be given a
      single prefix which provides the same number of destination
      addresses.  Further, since the prefix is a subset of the
      provider's prefix, they impose no additional burden on the higher
      levels of the routing hierarchy.

      There is a close relationship between subnetworks and routing
      domains implicit in the fact that they operate a common routing
      protocol and are under the control of a single administration. The
      routing domain administration subdivides the domain into
      subnetworks.  The routing domain represents the only path between
      a subnetwork and the rest of the internetwork. It is reasonable
      that this relationship also extend to include a common IP
      addressing space. Thus, the subnetworks within the leaf routing
      domain should take their IP addresses from the prefix assigned to
      the leaf routing domain.

5.3   Administration at the Transit Routing Domain

      Two kinds of transit routing domains are considered, direct
      providers and indirect providers. Most of the subscribers of a
      direct provider are domains that act solely as service subscribers
      (they carry no transit traffic). Most of the subscribers of an
      indirect provider are domains that, themselves, act as service
      providers. In present terminology a backbone is an indirect
      provider, while a TRD is a direct provider. Each case is discussed
      separately below.

5.3.1   Direct Service Providers

      It is interesting to consider whether direct service providers'
      routing domains should use their IP address space for assigning IP
      addresses from a unique prefix to the leaf routing domains that
      they serve. The benefits derived from data abstraction are greater
      than in the case of leaf routing domains, and the additional
      degree of data abstraction provided by this may be necessary in
      the short term.

      As an illustration consider an example of a direct provider that
      serves 100 clients. If each client takes its addresses from 4
      independent address spaces then the total number of entries that
      are needed to handle routing to these clients is 400 (100 clients