rfc1237.txt

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

    
    
    administered by ANSI. This will provide an identical DSP structure
    to that provided by GOSIP Version 2. The ANSI format, therefore,
    differs from that illustrated above only in that the IDP is based
    on an ISO DCC assignment, and in that the AA will be administered
    by a different organization (ANSI secretariat instead of GSA).
    The technical considerations applicable to NSAP administration are
    independent of whether a GOSIP Version 2 or an ANSI value is used for
    the NSAP assignment.
    
    
    Similarly, although other countries may make use of slightly different
    NSAP formats, the principles of NSAP assignment and use are the same.
    
    
    In the low-order part of the GOSIP Version 2 NSAP format, two
    fields are defined in addition to those required by DIS10589. These
    fields, RD and Area, are defined to allow allocation of NSAPs along
    topological boundaries in support of increased data abstraction.
    Administrations assign RD identifiers underneath their unique address
    prefix (the reserved field is left to accommodate future growth and
    to provide additional flexibility for inter-domain routing). Routing
    domains allocate Area identifiers from their unique prefix. The result
    is:
    
    
       * AFI+IDI+DFI+AA = administration prefix,
    
       * administration prefix(+Rsvd)+RD = routing domain prefix, and,
    
       * routing domain prefix+Area = area address.
    
    
    
    This provides for summarization of all area addresses within a routing
    domain into one prefix. If the AA identifier is accorded topological
    significance (in addition to administrative significance), an
    additional level of data abstraction can be obtained, as is discussed
    in the next section.
    
    
    
    5   NSAP Administration and Routing in the Internet
    
    
    Internet routing components---backbones, regionals, and sites
    or campuses---are arranged hierarchically for the most part. A
    natural mapping from these components to OSI routing components
    is that backbones, regionals, and sites act as routing domains.
    
    
    
    Colella, Gardner, & Callon                                    [Page 17]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    (Alternatively, a site may choose to operate as an area within a
    regional. However, in such a case the area is part of the regional's
    routing domain and the discussion in Section 5.1 applies. We assume
    that some, if not most, sites will prefer to operate as routing
    domains. By operating as a routing domain, a site operates a level 2
    subdomain as well as one or more level 1 areas.)
    
    
    Given such a mapping, where should address administration and alloca-
    tion be performed to satisfy both administrative decentralization and
    data abstraction? Three possibilities are considered:
    
      1. at the area,
    
      2. at the leaf routing domain, and,
    
      3. at the transit routing domain (TRD).
    
    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
    regionals are TRDs.
    
    
    The greatest burden in transmitting and operating on routing informa-
    tion is at the top of the routing hierarchy, where routing information
    tends to accumulate. In the Internet, for example, regionals must man-
    age the set of network numbers for all networks reachable through the
    regional. Traffic destined for other networks is generally routed to
    the backbone. The backbones, however, must be cognizant of the network
    numbers for all attached regionals 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 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
    regional (implying that the first seven octets of the address are
    those assigned to that regional). If considering only their own
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 18]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    self-interest, the site itself, and the attached regional, 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 regional 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 regional distributes routing
    information to backbones and other regionals. In the first case, the
    regional 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 backbones and other regionals which must
    exchange and maintain this information.
    
    
    In the second case, each other regional and backbone sees a single
    address prefix for the regional, 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 regionals and backbones which maintain routing information about
    this site and regional.
    
    
    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., an attached regional) 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 contributes to this
    cost.
    
    
    The Internet, however, is not a market economy. Rather, efficient
    operation is based on cooperation. The guidelines discussed below
    describe reasonable ways of managing the OSI address space that
    benefit the entire community.
    
    
    
    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 DIS10589. For example, assume that within a
    routing domain three areas take their area addresses, respectively,
    out of:
    
    
    
    Colella, Gardner, & Callon                                    [Page 19]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * 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. 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 leaf routing domains would advertise is on
    the order of the number of attached areas; the number of prefixes a
    regional routing domain would advertise is approximately the number of
    areas attached to the client leaf routing domains; and for a backbone
    this would be summed across all attached regionals. Although this
    situation is just barely acceptable in the current Internet, 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.
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 20]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    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 unique prefix results in the biggest
    single increase in abstraction, with each leaf domain assigning area
    addresses from its prefix. From outside the leaf routing domain, the
    set of all addresses reachable in the domain can then be represented
    by a single prefix.
    
    
    As an example, assume NSF has been assigned the AA value of zzz
    under ICD=0005. NSF 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 attached to 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 leaf RD should take their NSAPs
    from the prefix assigned to the leaf RD.
    
    
    
    5.3   Administration at the Transit Routing Domain
    
    
    
    Two kinds of transit routing domains are considered, backbones and
    regionals. Each is discussed separately below.
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 21]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    5.3.1   Regionals
    
    
    
    It is interesting to consider whether regional routing domains should
    be the common authority for assigning NSAPs from a unique prefix to
    the leaf routing domains that they serve. The benefits derived from
    data abstraction are less than in the case of leaf routing domains,
    and the additional degree of data abstraction provided by this is
    not necessary in the short term. However, 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.