rfc1237.txt

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

    3.3   Requirements of DIS10589 on NSAPs
    
    
    
    The preferred NSAP format for DIS10589 is shown in Figure 1. A number
    of points should be noted from DIS10589:
    
    
    
    Colella, Gardner, & Callon                                    [Page 11]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
       * The IDP is as specified in ISO 8348/Addendum 2, the OSI network
         layer addressing standard [14];
    
    
       * The high-order portion of the DSP (HO-DSP) is that portion of the
         DSP whose assignment, structure, and meaning are not constrained
         by DIS10589;
    
    
       * The concatenation of the IDP and the HO-DSP, the area address,
         must be globally unique (if the area address of an NSAP matches
         one of the area addresses of a system, it is in the system's area
         and is routed to by level 1 routing);
    
    
       * Level 2 routing acts on address prefixes, using the longest
         address prefix that matches the destination address;
    
    
       * Level 1 routing acts on the ID field. The ID field must be unique
         within an area for ESs and level 1 ISs, and unique within the
         routing domain for level 2 ISs. The ID field is assumed to be
         flat;
    
    
       * The one-octet NSAP Selector, SEL, determines the entity to receive
         the CLNP packet within the system identified by the rest of the
         NSAP (i.e., a transport entity) and is always the last octet of
         the NSAP; and,
    
    
       * A system shall be able to generate and forward data packets
         containing addresses in any of the formats specified by ISO
         8348/Addendum 2. However, within a routing domain that conforms to
         DIS10589, the lower-order octets of the NSAP should be structured
         as the ID and SEL fields shown in Figure 1 to take full advantage
         of DIS10589 routing. End systems with addresses which do not
         conform may require additional manual configuration and be subject
         to inferior routing performance.
    
    
    For purposes of efficient operation of the IS-IS routing protocol,
    several observations may be made. First, although the IS-IS protocol
    specifies an algorithm for routing within a single routing domain, the
    routing algorithm must efficiently route both: (i) Packets whose final
    destination is in the domain (these must, of course, be routed to the
    correct destination end system in the domain); and (ii) Packets whose
    final destination is outside of the domain (these must be routed to a
    correct ``border'' router, from which they will exit the domain).
    
    
    Colella, Gardner, & Callon                                    [Page 12]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    For those destinations which are in the domain, level 2 routing treats
    the entire area address (i.e., all of the NSAP address except the ID
    and SEL fields) as if it were a flat field. Thus, the efficiency of
    level 2 routing to destinations within the domain is affected only by
    the number of areas in the domain, and the number of area addresses
    assigned to each area (which can range from one up to a maximum of
    three).
    
    
    For those destinations which are outside of the domain, level 2
    routing routes according to address prefixes. In this case, there
    is considerable potential advantage (in terms of reducing the amount
    of routing information that is required) if the number of address
    prefixes required to describe any particular set of destinations can
    be minimized.
    
    
    
    4   NSAPs and Routing
    
    
    
    When determining an administrative policy for NSAP assignment, it
    is important to understand the technical consequences. The objective
    behind the use of hierarchical routing is to achieve some level
    of routing data abstraction, or summarization, to reduce the cpu,
    memory, and transmission bandwidth consumed in support of routing.
    This dictates that NSAPs be assigned according to topological
    routing structures. However, administrative assignment falls along
    organizational or political boundaries. These may not be congruent to
    topological boundaries and therefore the requirements of the two may
    collide. It is necessary to find a balance between these two needs.
    
    
    Routing data abstraction occurs at the boundary between hierarchically
    arranged topological routing structures. An element lower in the
    hierarchy reports summary routing information to its parent(s). Within
    the current OSI routing framework [16] and routing protocols, the
    lowest boundary at which this can occur is the boundary between an
    area and the level 2 subdomain within a DIS10589 routing domain. Data
    abstraction is designed into DIS10589 at this boundary, since level 1
    ISs are constrained to reporting only area addresses, and a maximum
    number of three area addresses are allowed in one area (This is an
    architectural constant in DIS10589. See [17], Clause 7.2.11 and Table
    2 of Clause 7.5.1).
    
    
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 13]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    Level 2 routing is based upon address prefixes. Level 2 ISs dis-
    tribute, throughout the level 2 subdomain, the area addresses of the
    level 1 areas to which they are attached (and any manually configured
    reachable address prefixes). Level 2 ISs compute next-hop forwarding
    information to all advertised address prefixes. Level 2 routing is
    determined by the longest advertised address prefix that matches the
    destination address.
    
    
    At routing domain boundaries, address prefix information is exchanged
    (statically or dynamically) with other routing domains. If area
    addresses within a routing domain are all drawn from distinct NSAP
    assignment authorities (allowing no abstraction), then the boundary
    prefix information consists of an enumerated list of all area
    addresses.
    
    
    Alternatively, should the routing domain ``own'' an address prefix
    and assign area addresses based upon it, boundary routing information
    can be summarized into the single prefix. This can allow substantial
    data reduction and, therefore, will allow much better scaling (as
    compared to the uncoordinated area addresses discussed in the previous
    paragraph).
    
    
    If routing domains are interconnected in a more-or-less random (non-
    hierarchical) scheme, it is quite likely that no further abstraction
    of routing data can occur. Since routing domains would have no defined
    hierarchical relationship, administrators would not be able to assign
    area addresses out of some common prefix for the purpose of data
    abstraction. The result would be flat inter-domain routing; all
    routing domains would need explicit knowledge of all other routing
    domains that they route to. This can work well in small- and medium-
    sized internets, up to a size somewhat larger than the current IP
    Internet. However, this does not scale to very large internets. For
    example, we expect growth in the future to an international Internet
    which has tens or hundreds of thousands of routing domains in the U.S.
    alone. This requires a greater degree of data abstraction beyond that
    which can be achieved at the ``routing domain'' level.
    
    
    In the Internet, however, it should be possible to exploit the
    existing hierarchical routing structure interconnections, as discussed
    in Section 5. Thus, there is the opportunity for a group of routing
    domains each to be assigned an address prefix from a shorter prefix
    assigned to another routing domain whose function is to interconnect
    the group of routing domains. Each member of the group of routing
    
    
    
    
    Colella, Gardner, & Callon                                    [Page 14]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
    domains now ``owns'' its (somewhat longer) prefix, from which it
    assigns its area addresses.
    
    
    The most straightforward case of this occurs when there is a set
    of routing domains which are all attached only to a single regional
    (or backbone) domain, and which use that regional for all external
    (inter-domain) traffic. A small address prefix may be assigned to
    the regional, which then assigns slightly longer prefixes (based
    on the regional's prefix) to each of the routing domains that it
    interconnects. This allows the regional, when informing other
    routing domains of the addresses that it can reach, to abbreviate
    the reachability information for a large number of routing domains
    as a single prefix. This approach therefore can allow a great deal
    of hierarchical abbreviation of routing information, and thereby can
    greatly improve the scalability of inter-domain routing.
    
    
    Clearly, this approach is recursive and can be carried through several
    iterations. Routing domains at any ``level'' in the hierarchy may
    use their prefix as the basis for subsequent suballocations, assuming
    that the NSAP addresses remain within the overall length and structure
    constraints. The GOSIP Version 2 NSAP structure, discussed later in
    this section, allows for multiple levels of routing hierarchy.
    
    
    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 data abstraction occur at the leaves and 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.
    
    
    There is a balance that must be sought between the requirements
    on NSAPs for efficient routing and the need for decentralized NSAP
    administration. The NSAP structure from Version 2 of GOSIP (Figure 2)
    offers an example of how these two needs might be met. The AFI,
    IDI, DFI, and AA fields provide for administrative decentralization.
    The AFI/IDI pair of values 47/0005 identify the U.S. government
    as the authority responsible for defining the DSP structure and
    allocating values within it (see Appendix A for more information on
    NSAP structure).
    
    
    
    Colella, Gardner, & Callon                                    [Page 15]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991
    
    
    
        [Note: It is not important that NSAPs be allocated from the
        GOSIP Version 2 authority under 47/0005. The ANSI format under
        the Data Country Code for the U.S. (DCC=840) and formats
        assigned to other countries and ISO members or liaison
        organizations are also expected to be used, and will work
        equally well. For parts of the Internet outside of the U.S.
        there may in some cases be strong reasons to prefer a local
        format rather than the GOSIP format. However, GOSIP addresses
        are used in most cases in the examples in this paper because:
    
          * The DSP format has been defined and allows hierarchical
            allocation; and,
    
          * An operational registration authority for suballocation of
            AA values under the GOSIP address space has already been
            established at GSA.]
    
    
    
    GOSIP Version 2 defines the DSP structure as shown (under DFI=80h) and
    provides for the allocation of AA values to administrations. Thus, the
    fields from the AFI to the AA, inclusive, represent a unique address
    prefix assigned to an administration.
    
                    _______________
                    !<--__IDP_-->_!___________________________________
                    !AFI_!__IDI___!___________<--_DSP_-->____________!
                    !_47_!__0005__!DFI_!AA_!Rsvd_!_RD_!Area_!ID_!Sel_!
             octets !_1__!___2____!_1__!_3_!__2__!_2__!_2___!_6_!_1__!
    
    
                      IDP   Initial Domain Part
                      AFI   Authority and Format Identifier
                      IDI   Initial Domain Identifier
                      DSP   Domain Specific Part
                      DFI   DSP Format Identifier
                      AA    Administrative Authority
                      Rsvd  Reserved
                      RD    Routing Domain Identifier
                      Area  Area Identifier
                      ID    System Identifier
                      SEL   NSAP Selector
    
                    Figure 2: GOSIP Version 2 NSAP structure.
    
    
    Currently, a proposal is being progressed in ANSI for an American
    National Standard (ANS) for the DSP of the NSAP address space
    
    
    
    Colella, Gardner, & Callon                                    [Page 16]
    
    
    
    
    
    RFC 1237  Guidelines for OSI NSAP Allocation in the Internet  July 1991