rfc1629.txt

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

   routing information that is required) if the number of address
   prefixes required to describe any particular set of external
   destinations can be minimized.  Efficient routing with IDRP similarly
   also requires minimization of the number of address prefixes needed
   to describe specific destinations.  In other words, addresses need to
   be assigned with topological significance.  This requirement is
   described in more detail in the following sections.

4.  NSAPs and Routing

4.1.  Routing Data Abstraction

   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 processing
   time, memory requirements, and transmission bandwidth consumed in
   support of routing.  This implies that address assignment must serve
   the needs of routing, in order for routing to scale to very large
   networks.

   While the notion of routing data abstraction may be applied to
   various types of routing information, this and the following sections
   primarily emphasize one particular type, namely reachability
   information.  Reachability information describes the set of reachable
   destinations.

   Abstraction of reachability information 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.  A balance
   between these two needs is necessary.



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


   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 [13] and routing
   protocols, the lowest boundary at which this can occur is the
   boundary between an area and the level 2 subdomain within a IS-IS
   routing domain.  Data abstraction is designed into IS-IS at this
   boundary, since level 1 ISs are constrained to reporting only area
   addresses.

   Level 2 routing is based upon address prefixes.  Level 2 routers
   (ISs) distribute, 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 routers
   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
   with other routing domains via IDRP.  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.  Even larger numbers of routing domains are possible when
   each home, or each small company, becomes its own routing domain.
   This requires a greater degree of data abstraction beyond that which
   can be achieved at the "routing domain" level.




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


   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 subscribers each to be assigned an address prefix from a shorter
   prefix assigned to their provider.  Each subscriber 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
   subscribers whose routing domains are all attached only to a single
   service provider, and which use that provider for all external
   (inter-domain) traffic.  A short address prefix may be assigned to
   the provider, which then assigns slightly longer prefixes (based on
   the provider's prefix) to each of the subscribers.  This allows the
   provider, when informing other providers 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 flexibility of NSAP addresses facilitates
   this form of hierarchical address assignment and routing.  As one
   example of how NSAPs may be used, the GOSIP Version 2 NSAP structure
   is discussed later in this section.

   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.  As the Internet grows, further levels of
   hierarchy may become necessary.  Again, this requires considerable
   flexibility in the addressing scheme, such as is provided by NSAP
   addresses.







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


4.2.  NSAP Administration and Efficiency

   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 one example of how these two needs might be met.  The AFI,
   IDI, DSP Format Identifier (DFI), and Administrative Authority (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 the Appendix for more information on NSAP structure).

          <----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.

   [Note: We are using U.S. GOSIP version 2 addresses only as an
   example.  It is not necessary 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 being
   used, and work equally well.  For parts of the Internet outside of
   the U.S.  there may in some cases be strong reasons to prefer a
   country- or area-specific format rather than the U.S. 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,



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


   * 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.

   American National Standard X3.216-1992 [1] specifies the structure of
   the DSP for NSAP addresses that use an Authority and Format
   Identifier (AFI) value of (decimal) 39, which identifies the "ISO-
   DCC" (data country code) format, in which the value of the Initial
   Domain Identifier (IDI) is (decimal) 840, which identifies the U.S.
   National Body (ANSI).  This DSP structure is identical to the
   structure that is specified by GOSIP Version 2.  The AA field is
   called "org" for organization identifier in the ANSI standard, and
   the ID field is called "system".  The ANSI format, therefore, differs
   from the GOSIP format illustrated above only in that the AFI and IDI
   specify the "ISO-DCC" format rather than the "ISO 6523-ICD" format
   used by GOSIP, and the "AA" field is administered by an ANSI
   registration authority rather than by the GSA.  Organization
   identifiers may be obtained from ANSI.  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 make use of different NSAP
   formats, the principles of NSAP assignment and use are the same.  The
   NSAP formats recommended by RARE WG4 for use in Europe are discussed
   in Section 6.2.

   In the low-order part of the GOSIP Version 2 NSAP format, two fields
   are defined in addition to those required by IS-IS.  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.





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


   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

   Basic Internet routing components are service providers and service
   subscribers.  A natural mapping from these components to OSI routing
   components is that each provider and subscriber operates as a routing
   domain.

   Alternatively, a subscriber may choose to operate as a part of a
   provider domain; that is, as an area within the provider's routing
   domain.  However, in such a case the discussion in Section 5.1
   applies.

   We assume that most subscribers will prefer to operate a routing
   domain separate from their provider's.  Such subscribers can exchange
   routing information with their provider via interior routing protocol
   route leaking or via IDRP; for the purposes of this discussion, the