rfc1629.txt

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

   choice is not significant.  The subscriber is still allocated a
   prefix from the provider's address space, and the provider advertises
   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?  Three possibilities are
   considered:

     1. at the area,

     2. at the subscriber routing domain, and,

     3. at the provider routing domain.

   Subscriber routing domains correspond to end-user sites, where the
   primary purpose is to provide intra-domain routing services. Provider
   routing domains are deployed to carry transit (i.e., inter-domain)
   traffic.

   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, each
   provider must manage the set of network numbers for all networks
   reachable through the provider.




Colella, Callon, Gardner & Rekhter                             [Page 21]

RFC 1629                    NSAP Guidelines                     May 1994


   For traffic destined for other networks, the provider will route
   based on inter-domain routing information obtained from other
   providers or, in some cases, to a default provider.

   In general, higher levels of the routing hierarchy will benefit the
   most from the abstraction of routing information at a lower level of
   the routing 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 subscriber is trying to decide
   whether to obtain an NSAP address prefix based on an AA value from
   GSA (implying that the first four octets of the address would be
   those assigned out of the GOSIP space), or based on an RD value from
   its provider (implying that the first seven octets of the address are
   those obtained by that provider).  If considering only their own
   self-interest, the subscriber and its local provider have little
   reason to choose one approach or the other.  The subscriber must use
   one prefix or another; the source of the prefix has little effect on
   routing efficiency within the subscriber's routing domain.  The
   provider must maintain information about each attached subscriber in
   order to route, regardless of any commonality in the prefixes of its
   subscribers.

   However, there is a difference when the local provider distributes
   routing information to other providers.  In the first case, the
   provider cannot aggregate the subscriber'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 sees a single address prefix
   for the local provider which encompasses the new subscriber.  This
   avoids the exchange of additional routing information to identify the
   new subscriber's address prefix.  Thus, the advantages primarily
   benefit other providers which maintain routing information about this
   provider (and its subscribers).

   Clearly, a symmetric application of these principles is in the
   interest of all providers, enabling them to more efficiently support
   CLNP routing to their customers.  The guidelines discussed below
   describe reasonable ways of managing the OSI address space that
   benefit the entire community.







Colella, Callon, Gardner & Rekhter                             [Page 22]

RFC 1629                    NSAP Guidelines                     May 1994


5.1.  Administration at the Area

   If areas take their area addresses from a myriad of unrelated NSAP
   allocation authorities, there will be effectively no data abstraction
   beyond what is built into IS-IS.  For example, assume that within a
   routing domain three areas take their area addresses, respectively,
   out of:

   * the GOSIP Version 2 authority assigned to the Department
     of Commerce, with an AA of nnn:

               AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;

   * the GOSIP Version 2 authority assigned to the Department
     of the Interior, with an AA of mmm:

                AFI=47, IDI=0005, DFI=80h, AA=mmm, ... ; and,

   * the ANSI authority under the U.S. Data Country Code (DCC)


   (Section A.2) for organization XYZ with ORG identifier = xxx:

                AFI=39, IDI=840, DFI=dd, ORG=xxx, ....

   As described in Section 3.3, from the point of view of any particular
   routing domain, there is no harm in having the different areas in the
   routing domain use addresses obtained from a wide variety of
   administrations.  For routing within the domain,  the area addresses
   are treated as a flat field.

   However, this does have 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 NSAPs 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 must be
   used consisting of the three area addresses.

   This situation is roughly analogous to the dissemination of routing
   information in the TCP/IP Internet prior to the introduction of CIDR.
   Areas correspond roughly to networks and area addresses to network
   numbers.  The result of allowing areas within a routing domain to
   take their NSAPs from unrelated authorities is flat routing at the
   area address level.  The number of address prefixes that subscriber
   routing domains would advertise is on the order of the number of
   attached areas; the number of prefixes a provider routing domain
   would advertise is approximately the number of areas attached to all



Colella, Callon, Gardner & Rekhter                             [Page 23]

RFC 1629                    NSAP Guidelines                     May 1994


   its subscriber routing domains.  For "default-less" providers (i.e.,
   those that don't use default routes) the size of the routing tables
   would be on the order of the number of area addresses globally.  As
   the CLNP internet grows this would quickly become intractable.  A
   greater degree of hierarchical information reduction is necessary to
   allow greater growth.

5.2.  Administration at the Subscriber Routing Domain

   As mentioned previously, the greatest degree of data abstraction
   comes at the lowest levels of the hierarchy.  Providing each
   subscriber routing domain (that is, site) with a unique prefix
   results in the biggest single increase in abstraction, with each
   subscriber domain assigning area addresses from its prefix.  From
   outside the subscriber routing domain, the set of all addresses
   reachable in the domain can then be represented by a single prefix.

   As an example, assume a government agency has been assigned the AA
   value of zzz under ICD=0005.  The agency then assigns a routing
   domain identifier to a routing domain under its administrative
   authority identifier, rrr.  The resulting prefix for the routing
   domain is:

   AFI=47, IDI=0005, DFI=80h, AA=zzz, (Rsvd=0), RD=rrr.

   All areas within this routing domain would have area addresses
   comprising this prefix followed by an Area identifier.  The prefix
   represents the summary of reachable addresses within the routing
   domain.

   There is a close relationship between areas 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 areas and structures a
   level 2 subdomain (i.e., a level 2 backbone) which provides
   connectivity among the areas.  The routing domain represents the only
   path between an area and the rest of the internetwork.  It is
   reasonable that this relationship also extend to include a common
   NSAP addressing authority.  Thus, the areas within the subscriber RD
   should take their NSAPs from the prefix assigned to the subscriber
   RD.

5.3.  Administration at the Provider Routing Domain

   Two kinds of provider 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
   (i.e., they carry no transit traffic).  Most of the "subscribers" of



Colella, Callon, Gardner & Rekhter                             [Page 24]

RFC 1629                    NSAP Guidelines                     May 1994


   an indirect provider are, themselves, service providers.  In present
   terminology a backbone is an indirect provider, while a regional 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 be the common authority for assigning NSAPs
   from a unique prefix to the subscriber routing domains that they
   serve.  In the long term the number of routing domains in the
   Internet will grow to the point that it will be infeasible to route
   on the basis of a flat field of routing domains.  It will therefore
   be essential to provide a greater degree of information abstraction.

   Direct providers may assign prefixes to subscriber domains, based on
   a single (shorter length) address prefix assigned to the provider.
   For example, given the GOSIP Version 2 address structure, an AA value
   may be assigned to each direct provider, and routing domain values
   may be assigned by the provider to each attached subscriber routing
   domain.  A similar hierarchical address assignment based on a prefix
   assigned to each provider may be used for other NSAP formats.  This
   results in direct providers advertising to other providers (both
   direct and indirect) a small fraction of the number of address
   prefixes that would be necessary if they enumerated the individual
   prefixes of the subscriber routing domains.  This represents a
   significant savings given the expected scale of global
   internetworking.

   Are subscriber routing domains willing to accept prefixes derived
   from the direct providers? In the supplier/consumer model, the direct
   provider is offering connectivity as the service, priced according to
   its costs of operation.  This includes the "price" of obtaining
   service from one or more indirect providers and exchanging routing
   information with other direct providers.  In general, providers will
   want to handle as few address prefixes as possible to keep costs low.
   In the Internet environment, subscriber routing domains must be
   sensitive to the resource constraints of the providers (both direct
   and indirect).  The efficiencies gained in routing clearly warrant
   the adoption of NSAP administration by the direct providers.

   The mechanics of this scenario are straightforward.  Each direct
   provider is assigned a unique prefix, from which it allocates
   slightly longer routing domain prefixes for its attached subscriber
   routing domains.  For GOSIP NSAPs, this means that a direct provider
   would be assigned an AA identifier.  Attached subscriber routing
   domains would be assigned RD identifiers under the direct provider's
   unique prefix.  For example, assume that NIST is a subscriber routing
   domain whose sole inter-domain link is via SURANet.  If SURANet is



Colella, Callon, Gardner & Rekhter                             [Page 25]

RFC 1629                    NSAP Guidelines                     May 1994


   assigned an AA identifier kkk, NIST could be assigned an RD of jjj,
   resulting in a unique prefix for SURANet of:

   AFI=47, IDI=0005, DFI=80h, AA=kkk

   and a unique prefix for NIST of

   AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj.

   A similar scheme can be established using NSAPs allocated under
   DCC=840.  In this case, a direct provider applies for an ORG
   identifier from ANSI, which serves the same purpose as the AA
   identifier in GOSIP.

5.3.2.  Indirect Providers

   There does not appear to be a strong case for direct service
   providers to take their address spaces from the NSAP space of an
   indirect provider (e.g. backbone in today's terms).  The benefit in
   routing data abstraction is relatively small.  The number of direct
   providers today is in the tens and an order of magnitude increase
   would not cause an undue burden on the indirect providers.  Also, it
   may be expected that as time goes by there will be increased direct
   inter-connection of the direct providers, subscriber routing domains
   directly attached to the "indirect" providers, and international
   links directly attached to the providers.  Under these circumstances,
   the distinction between direct and indire