rfc1629.txt

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

   large-scale division of NSAP address allocation in the Internet.
   Topics covered include:

   * Arrangement of parts of the NSAP for efficient operation of
     the IS-IS routing protocol;

   * Benefits of some topological information in NSAPs to reduce
     routing protocol overhead, and specifically the overhead on
     inter-domain routing (IDRP);

   * The anticipated need for additional levels of hierarchy in
     Internet addressing to support network growth and use of
     the Routing Domain Confederation mechanism of IDRP to provide
     support for additional levels of hierarchy;

   * The recommended mapping between Internet topological entities
     (i.e., service providers and service subscribers) and OSI
     addressing and routing components, such as areas, domains and
     confederations;

   * The recommended division of NSAP address assignment authority
     among service providers and service subscribers;

   * Background information on administrative procedures for
     registration of administrative authorities immediately
     below the national level (GOSIP administrative authorities
     and ANSI organization identifiers); and,

   * Choice of the high-order portion of the NSAP in subscriber
     routing domains that are connected to more than one service
     provider.

   It is noted that there are other aspects of NSAP allocation, both
   technical and administrative, that are not covered in this paper.
   Topics not covered or mentioned only superficially include:

   * Identification of specific administrative domains in the
     Internet;

   * Policy or mechanisms for making registered information known
     to third parties (such as the entity to which a specific NSAP
     or a portion of the NSAP address space has been allocated);








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


   * How a routing domain (especially a site) should organize its
     internal topology of areas or allocate portions of its NSAP
     address space; the relationship between topology and addresses
     is discussed, but the method of deciding on a particular topology
     or internal addressing plan is not; and,

   * Procedures for assigning the System Identifier (ID) portion of
     the NSAP.  A method for assignment of System IDs is presented
     in [18].

3.  Background

   Some background information is provided in this section that is
   helpful in understanding the issues involved in NSAP allocation.  A
   brief discussion of OSI routing is provided, followed by a review of
   the intra-domain and inter-domain protocols in sufficient detail to
   understand the issues involved in NSAP allocation.  Finally, the
   specific constraints that the routing protocols place on NSAPs are
   listed.

3.1.  OSI Routing Standards

   OSI partitions the routing problem into three parts:

   * routing exchanges between hosts (a.k.a., end systems or ESs) and
     routers (a.k.a., intermediate systems or ISs) (ES-IS);

   * routing exchanges between routers in the same routing domain
     (intra-domain IS-IS); and,

   * routing among routing domains (inter-domain IS-IS).

   ES-IS (international standard ISO 9542) advanced to international
   standard (IS) status within ISO in 1987.  Intra-domain IS-IS advanced
   to IS status within ISO in 1992.  Inter-Domain Routing Protocol
   (IDRP) advanced to IS status within ISO in October 1993.  CLNP, ES-
   IS, and IS-IS are all widely available in vendor products, and have
   been deployed in the Internet for several years.  IDRP is currently
   being implemented in vendor products.

   This paper examines the technical implications of NSAP assignment
   under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing
   are deployed to support CLNP.








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


3.2.  Overview of ISIS (ISO/IEC 10589)

   The IS-IS intra-domain routing protocol, ISO/IEC 10589, provides
   routing for OSI environments.  In particular, IS-IS is designed to
   work in conjunction with CLNP, ES-IS, and IDRP.  This section briefly
   describes the manner in which IS-IS operates.

   In IS-IS, the internetwork is partitioned into routing domains.  A
   routing domain is a collection of ESs and ISs that operate common
   routing protocols and are under the control of a single
   administration (throughout this paper, "domain" and "routing domain"
   are used interchangeably).  Typically, a routing domain may consist
   of a corporate network, a university campus network, a regional
   network, a backbone, or a similar contiguous network under control of
   a single administrative organization.  The boundaries of routing
   domains are defined by network management by setting some links to be
   exterior, or inter-domain, links.  If a link is marked as exterior,
   no intra-domain IS-IS routing messages are sent on that link.

   IS-IS routing makes use of two-level hierarchical routing.  A routing
   domain is subdivided into areas (also known as level 1 subdomains).
   Level 1 routers know the topology in their area, including all
   routers and hosts.  However, level 1 routers do not know the identity
   of routers or destinations outside of their area.  Level 1 routers
   forward all traffic for destinations outside of their area to a level
   2 router within their area.

   Similarly, level 2 routers know the level 2 topology and know which
   addresses are reachable via each level 2 router.  The set of all
   level 2 routers in a routing domain are known as the level 2
   subdomain, which can be thought of as a backbone for interconnecting
   the areas.  Level 2 routers do not need to know the topology within
   any level 1 area, except to the extent that a level 2 router may also
   be a level 1 router within a single area. Only level 2 routers can
   exchange data packets or routing information directly with routers
   located outside of their routing domain.

   NSAP addresses provide a flexible, variable length addressing format,
   which allows for multi-level hierarchical address assignment.  These
   addresses provide the flexibility needed to solve two critical
   problems simultaneously: (i) How to administer a worldwide address
   space; and (ii) How to assign addresses in a manner which makes
   routing scale well in a worldwide Internet.

   As illustrated in Figure 1, ISO addresses are subdivided into the
   Initial Domain Part (IDP) and the Domain Specific Part (DSP).  The
   IDP is the part which is standardized by ISO, and specifies the
   format and authority responsible for assigning the rest of the



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


   address.  The DSP is assigned by whatever addressing authority is
   specified by the IDP (see Appendix A for more discussion on the top
   level NSAP addressing authorities).  It is expected that the
   authority specified by the IDP may further sub-divide the DSP, and
   may assign sub-authorities responsible for parts of the DSP.

   For routing purposes, ISO addresses are subdivided by IS-IS into the
   area address, the system identifier (ID), and the NSAP selector
   (SEL).  The area address identifies both the routing domain and the
   area within the routing domain.  Generally, the area address
   corresponds to the IDP plus a high-order part of the DSP (HO-DSP).

   <----IDP---> <----------------------DSP---------------------------->
                <-----------HO-DSP------------>
   +-----+-----+-------------------------------+--------------+-------+
   | AFI | IDI |Contents assigned by authority identified in IDI field|
   +-----+-----+-------------------------------+--------------+-------+
   <----------------Area Address--------------> <-----ID-----> <-SEL->

                    IDP     Initial Domain Part
                    AFI     Authority and Format Identifier
                    IDI     Initial Domain Identifier
                    DSP     Domain Specific Part
                    HO-DSP  High-order DSP
                    ID      System Identifier
                    SEL     NSAP Selector


                 Figure 1: OSI Hierarchical Address Structure.

   The ID field may be from one to eight octets in length, but must have
   a single known length in any particular routing domain.  Each router
   is configured to know what length is used in its domain.  The SEL
   field is always one octet in length.  Each router is therefore able
   to identify the ID and SEL fields as a known number of trailing
   octets of the NSAP address.  The area address can be identified as
   the remainder of the address (after truncation of the ID and SEL
   fields).  It is therefore not necessary for the area address to have
   any particular length -- the length of the area address could vary
   between different area addresses in a given routing domain.

   Usually, all nodes in an area have the same area address.  However,
   sometimes an area might have multiple addresses.  Motivations for
   allowing this are several:







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


   * It might be desirable to change the address of an area.  The most
     graceful way of changing an area address from A to B is to first
     allow it to have both addresses A and B, and then after all nodes
     in the area have been modified to recognize both addresses, one by
     one the nodes can be modified to forget address A.

   * It might be desirable to merge areas A and B into one area.  The
     method for accomplishing this is to, one by one, add knowledge of
     address B into the A partition, and similarly add knowledge of
     address A into the B partition.

   * It might be desirable to partition an area C into two areas, A and
     B (where A might equal C, in which case this example becomes one
     of removing a portion of an area).  This would be accomplished by
     first introducing knowledge of address A into the appropriate
     nodes (those destined to become area A), and knowledge of address
     B into the appropriate nodes, and then one by one removing
     knowledge of address C.

   Since the addressing explicitly identifies the area, it is very easy
   for level 1 routers to identify packets going to destinations outside
   of their area, which need to be forwarded to level 2 routers.  Thus,
   in IS-IS routers perform as follows:

   * Level 1 intermediate systems route within an area based on the ID
     portion of the ISO address.  Level 1 routers recognize, based on the
     destination address in a packet, whether the destination is within
     the area.  If so, they route towards the destination.  If not, they
     route to the nearest level 2 router.

   * Level 2 intermediate systems route based on address prefixes,
     preferring the longest matching prefix, and preferring internal
     routes over external routes.  They route towards areas, without
     regard to the internal structure of an area; or towards level 2
     routers on the routing domain boundary that have advertised external
     address prefixes into the level 2 subdomain.  A level 2 router may
     also be operating as a level 1 router in one area.

   A level 1 router will have the area portion of its address manually
   configured.  It will refuse to become a neighbor with a router whose
   area addresses do not overlap its own area addresses.  However, if a
   level 1 router has area addresses A, B, and C, and a neighbor has
   area addresses B and D, then the level 1 IS will accept the other IS
   as a level 1 neighbor.

   A level 2 router will accept another level 2 router as a neighbor,
   regardless of area address.  However, if the area addresses do not
   overlap, the link would be considered by both routers to be level 2



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


   only, and only level 2 routing packets would flow on the link.
   External links (i.e., to other routing domains) must be between level
   2 routers in different routing domains.

   IS-IS provides an optional partition repair function.  If a level 1
   area becomes partitioned, this function, if implemented, allows the
   partition to be repaired via use of level 2 routes.