doc: Add RFC documents

1 files changed, 2915 insertions, 0 deletions

diff --git a/doc/rfc/rfc1629.txt b/doc/rfc/rfc1629.txt
new file mode 100644
index 0000000..cb987c7
--- /dev/null
+++ b/doc/rfc/rfc1629.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Network Working Group                                          R. Colella
+Request for Comments: 1629                                           NIST
+Obsoletes: 1237                                                 R. Callon
+Category: Standards Track                                       Wellfleet
+                                                               E. Gardner
+                                                                    Mitre
+                                                               Y. Rekhter
+                                   T.J. Watson Research Center, IBM Corp.
+                                                                 May 1994
+
+
+           Guidelines for OSI NSAP Allocation in the Internet
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   CLNP is currently being deployed in the Internet.  This is useful to
+   support OSI and DECnet(tm) traffic.  In addition, CLNP has been
+   proposed as a possible IPng candidate, to provide a long-term
+   solution to IP address exhaustion.  Required as part of the CLNP
+   infrastructure are guidelines for network service access point (NSAP)
+   address assignment.  This paper provides guidelines for allocating
+   NSAP addresses in the Internet.
+
+   The guidelines provided in this paper have been the basis for initial
+   deployment of CLNP in the Internet, and have proven very valuable
+   both as an aid to scaling of CLNP routing, and for address
+   administration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                              [Page 1]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+Table of Contents
+
+   Section 1. Introduction ...............................    4
+   Section 2. Scope ......................................    5
+   Section 3. Background .................................    7
+   Section 3.1 OSI Routing Standards .....................    7
+   Section 3.2 Overview of IS-IS (ISO/IEC 10589) .........    8
+   Section 3.3 Overview of IDRP (ISO/IEC 10747) ..........   12
+   Section 3.3.1 Scaling Mechanisms in IDRP ..............   14
+   Section 3.4 Requirements of IS-IS and IDRP on NSAPs ...   15
+   Section 4. NSAPs and Routing ..........................   16
+   Section 4.1 Routing Data Abstraction ..................   16
+   Section 4.2 NSAP Administration and Efficiency ........   19
+   Section 5. NSAP Administration and Routing in the In-
+        ternet ...........................................   21
+   Section 5.1 Administration at the Area ................   23
+   Section 5.2 Administration at the Subscriber Routing
+        Domain ...........................................   24
+   Section 5.3 Administration at the  Provider  Routing
+        Domain ...........................................   24
+   Section 5.3.1 Direct Service Providers ................   25
+   Section 5.3.2 Indirect Providers ......................   26
+   Section 5.4 Multi-homed Routing Domains ...............   26
+   Section 5.5 Private Links .............................   31
+   Section 5.6 Zero-Homed Routing Domains ................   33
+   Section 5.7 Address Transition Issues .................   33
+   Section 6. Recommendations ............................   36
+   Section 6.1 Recommendations Specific to U.S. Parts of
+        the Internet .....................................   37
+   Section 6.2  Recommendations Specific to European Parts
+        of the Internet ..................................   39
+   Section 6.2.1 General NSAP Structure ..................   40
+   Section 6.2.2 Structure of the Country Domain Part ....   40
+   Section  6.2.3  Structure of the Country Domain
+        Specific Part ....................................   41
+   Section 6.3 Recommendations Specific to Other Parts of
+        the Internet .....................................   41
+   Section 6.4 Recommendations for Multi-Homed Routing
+        Domains ..........................................   41
+   Section 6.5 Recommendations for RDI and RDCI assign-
+        ment .............................................   42
+   Section 7. Security Considerations ....................   42
+   Section 8. Authors' Addresses .........................   43
+   Section 9. Acknowledgments ............................   43
+   Section 10. References ................................   44
+   Section A. Administration of NSAPs ....................   46
+   Section A.1  GOSIP Version 2 NSAPs ....................   47
+   Section A.1.1  Application for Administrative Authority
+
+
+
+Colella, Callon, Gardner & Rekhter                              [Page 2]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+        Identifiers ......................................   48
+   Section A.1.2  Guidelines for NSAP Assignment .........   50
+   Section A.2  Data Country Code NSAPs ..................   50
+   Section A.2.1  Application for Numeric Organization
+        Name .............................................   51
+   Section A.3  Summary of Administrative  Requirements ..   52
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                              [Page 3]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+1.  Introduction
+
+   The Internet is moving towards a multi-protocol environment that
+   includes CLNP.  To support CLNP in the Internet, an OSI lower layers
+   infrastructure is required.  This infrastructure comprises the
+   connectionless network protocol (CLNP) [9] and supporting routing
+   protocols.  Also required as part of this infrastructure are
+   guidelines for network service access point (NSAP) address
+   assignment.  This paper provides guidelines for allocating NSAP
+   addresses in the Internet (the terms NSAP and NSAP address are used
+   interchangeably throughout this paper in referring to NSAP
+   addresses).
+
+   The guidelines presented in this document are quite similar to the
+   guidelines that are proposed in the Internet for IP address
+   allocation with CIDR (RFC 1519 [19]).  The major difference between
+   the two is the size of the addresses (4 octets for CIDR vs 20 octets
+   for CLNP).  The larger NSAP addresses allows considerably greater
+   flexibility and scalability.
+
+   The remainder of this paper is organized into five major sections and
+   an appendix.  Section 2 defines the boundaries of the problem
+   addressed in this paper and Section 3 provides background information
+   on OSI routing and the implications for NSAP addresses.
+
+   Section 4 addresses the specific relationship between NSAP addresses
+   and routing, especially with regard to hierarchical routing and data
+   abstraction.  This is followed in Section 5 with an application of
+   these concepts to the Internet environment.  Section 6 provides
+   recommended guidelines for NSAP address allocation in the Internet.
+   This includes recommendations for the U.S. and European parts of the
+   Internet, as well as more general recommendations for any part of the
+   Internet.
+
+   The Appendix contains a compendium of useful information concerning
+   NSAP structure and allocation authorities.  The GOSIP Version 2 NSAP
+   structure is discussed in detail and the structure for U.S.-based DCC
+   (Data Country Code) NSAPs is described.  Contact information for the
+   registration authorities for GOSIP and DCC-based NSAPs in the U.S.,
+   the General Services Administration (GSA) and the American National
+   Standards Institute (ANSI), respectively, is provided.
+
+   This document obsoletes RFC 1237.  The changes from RFC 1237 are
+   minor, and primarily editorial in nature.  The descriptions of OSI
+   routing standards contained in Section 3 have been updated to reflect
+   the current status of the relevant standards, and a description of
+   the OSI Interdomain Routing Protocol (IDRP) has been added.
+   Recommendations specific to the European part of the Internet have
+
+
+
+Colella, Callon, Gardner & Rekhter                              [Page 4]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   been added in Section 6, along with recommendations for Routing
+   Domain Identifiers and Routing Domain Confederation Identifiers
+   needed for operation of IDRP.
+
+2.  Scope
+
+   Control over the collection of hosts and the transmission and
+   switching facilities that compose the networking resources of the
+   global Internet is not homogeneous, but is distributed among multiple
+   administrative authorities.  For the purposes of this paper, the term
+   network service provider (or just provider) is defined to be an
+   organization that is in the business of providing datagram switching
+   services to customers.  Organizations that are *only* customers
+   (i.e., that do not provide datagram services to other organizations)
+   are called network service subscribers (or simply subscribers).
+
+   In the current Internet, subscribers (e.g., campus and corporate site
+   networks) attach to providers (e.g., regionals, commercial providers,
+   and government backbones) in only one or a small number of carefully
+   controlled access points.  For discussion of OSI NSAP allocation in
+   this paper, providers are treated as composing a mesh having no fixed
+   hierarchy.  Addressing solutions which require substantial changes or
+   constraints on the current topology are not considered in this paper.
+
+   There are two aspects of interest when discussing OSI NSAP allocation
+   within the Internet.  The first is the set of administrative
+   requirements for obtaining and allocating NSAP addresses; the second
+   is the technical aspect of such assignments, having largely to do
+   with routing, both within a routing domain (intra-domain routing) and
+   between routing domains (inter-domain routing).  This paper focuses
+   on the technical issues.
+
+   The technical issues in NSAP allocation are mainly related to
+   routing.  This paper assumes that CLNP will be widely deployed in the
+   Internet, and that the routing of CLNP traffic will normally be based
+   on the OSI end-system to intermediate system routing protocol (ES-IS)
+   [10], intra-domain IS-IS protocol [14], and inter-domain routing
+   protocol (IDRP) [16].  It is expected that in the future the OSI
+   routing architecture will be enhanced to include support for
+   multicast, resource reservation, and other advanced services.  The
+   requirements for addressing for these future services is outside of
+   the scope of this document.
+
+   The guidelines provided in this paper have been the basis for initial
+   deployment of CLNP in the Internet, and have proven very valuable
+   both as an aid to scaling of CLNP routing, and to address
+   administration.
+
+
+
+
+Colella, Callon, Gardner & Rekhter                              [Page 5]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   The guidelines in this paper are oriented primarily toward the
+   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.
+
+   IS-IS requires that the set of level 2 routers be connected.  Should
+   the level 2 backbone become partitioned, there is no provision for
+   use of level 1 links to repair a level 2 partition.
+
+   Occasionally a single level 2 router may lose connectivity to the
+   level 2 backbone.  In this case the level 2 router will indicate in
+   its level 1 routing packets that it is not "attached", thereby
+   allowing level 1 routers in the area to route traffic for outside of
+   the area to a different level 2 router.  Level 1 routers therefore
+   route traffic to destinations outside of their area only to level 2
+   routers which indicate in their level 1 routing packets that they are
+   "attached".
+
+   A host may autoconfigure the area portion of its address by
+   extracting the area portion of a neighboring router's address. If
+   this is the case, then a host will always accept a router as a
+   neighbor.  Since the standard does not specify that the host *must*
+   autoconfigure its area address, a host may be pre-configured with an
+   area address.
+
+   Special treatment is necessary for broadcast subnetworks, such as
+   LANs.  This solves two sets of issues: (i) In the absence of special
+   treatment, each router on the subnetwork would announce a link to
+   every other router on the subnetwork, resulting in O(n-squared) links
+   reported; (ii) Again, in the absence of special treatment, each
+   router on the LAN would report the same identical list of end systems
+   on the LAN, resulting in substantial duplication.
+
+   These problems are avoided by use of a "pseudonode", which represents
+   the LAN.  Each router on the LAN reports that it has a link to the
+   pseudonode (rather than reporting a link to every other router on the
+   LAN).  One of the routers on the LAN is elected "designated router".
+   The designated router then sends out a Link State Packet (LSP) on
+   behalf of the pseudonode, reporting links to all of the routers on
+   the LAN.  This reduces the potential n-squared links to n links.  In
+   addition, only the pseudonode LSP includes the list of end systems on
+   the LAN, thereby eliminating the potential duplication.
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 11]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   The IS-IS provides for optional Quality of Service (QOS) routing,
+   based on throughput (the default metric), delay, expense, or residual
+   error probability.
+
+   IS-IS has a provision for authentication information to be carried in
+   all IS-IS PDUs.  Currently the only form of authentication which is
+   defined is a simple password.  A password may be associated with each
+   link, each area, and with the level 2 subdomain.  A router not in
+   possession of the appropriate password(s) is prohibited from
+   participating in the corresponding function (i.e., may not initialize
+   a link, be a member of the area, or a member of the level 2
+   subdomain, respectively).
+
+   Procedures are provided to allow graceful migration of passwords
+   without disrupting operation of the routing protocol.  The
+   authentication functions are extensible so that a stronger,
+   cryptographically-based security scheme may be added in an upwardly
+   compatible fashion at a future date.
+
+3.3.  Overview of IDRP (ISO/IEC 10747)
+
+   The Inter-Domain Routing Protocol (IDRP, ISO/IEC 10747), developed in
+   ISO, provides routing for OSI environments.  In particular, IDRP is
+   designed to work in conjuction with CLNP, ES-IS, and IS-IS.  This
+   section briefly describes the manner in which IDRP operates.
+
+   Consistent with the OSI Routing Framework [13], in IDRP the
+   internetwork is partitioned into routing domains.  IDRP places no
+   restrictions on the inter-domain topology.  A router that
+   participates in IDRP is called a Boundary Intermediate System (BIS).
+   Routing domains that participate in IDRP are not allowed to overlap -
+   a BIS may belong to only one domain.
+
+   A pair of BISs are called external neighbors if these BISs belong to
+   different domains but share a common subnetwork (i.e., a BIS can
+   reach its external neighbor in a single network layer hop).  Two
+   domains are said to be adjacent if they have BISs that are external
+   neighbors of each other.  A pair of BISs are called internal
+   neighbors if these BISs belong to the same domain.  In contrast with
+   external neighbors, internal neighbors don't have to share a common
+   subnetwork -- IDRP assumes that a BIS should be able to exchange
+   Network Protocol Date Units (NPDUs) with any of its internal
+   neighbors by relying solely on intra-domain routing procedures.
+
+   IDRP governs the exchange of routing information between a pair of
+   neighbors, either external or internal.  IDRP is self-contained with
+   respect to the exchange of information between external neighbors.
+   Exchange of information between internal neighbors relies on
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 12]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   additional support provided by intra-domain routing (unless internal
+   neighbors share a common subnetwork).
+
+   To facilitate routing information aggregation/abstraction, IDRP
+   allows grouping of a set of connected domains into a Routing Domain
+   Confederation (RDC).  A given domain may belong to more than one RDC.
+   There are no restrictions on how many RDCs a given domain may
+   simultaneously belong to, and no preconditions on how RDCs should be
+   formed --  RDCs may be either nested, or disjoint, or may overlap.
+   One RDC is nested within another RDC if all members (RDs) of the
+   former are also members of the latter, but not vice versa.  Two RDCs
+   overlap if they have members in common and also each has members that
+   are not in the other.  Two RDCs are disjoint if they have no members
+   in common.
+
+   Each domain participating in IDRP is assigned a unique Routing Domain
+   Identifier (RDI).  Syntactically an RDI is represented as an OSI
+   network layer address.  Each RDC is assigned a unique Routing Domain
+   Confederation Identifier (RDCI).  RDCIs are assigned out of the
+   address space allocated for RDIs -- RDCIs and RDIs are syntactically
+   indistinguishable.  Procedures for assigning and managing RDIs and
+   RDCIs are outside the scope of the protocol.  However, since RDIs are
+   syntactically nothing more than network layer addresses, and RDCIs
+   are syntactically nothing more than RDIs, it is expected that RDI and
+   RDCI assignment and management would be part of the network layer
+   assignment and management procedures.  Recommendations for RDI and
+   RDCI assignment are provided in Section 6.5.
+
+   IDRP requires a BIS to be preconfigured with the RDI of the domain to
+   which the BIS belongs.  If a BIS belongs to a domain that is a member
+   of one or more RDCs, then the BIS has to be preconfigured with RDCIs
+   of all the RDCs the domain is in, and the information about relations
+   between the RDCs - nested or overlapped.
+
+   IDRP doesn't assume or require any particular internal structure for
+   the addresses.  The protocol provides correct routing as long as the
+   following guidelines are met:
+
+   * End systems and intermediate systems may use any NSAP address or
+     Network Entity Title (NET -- i.e., an NSAP address without the
+     selector) that has been assigned under ISO 8348 [11] guidelines;
+
+   * An NSAP prefix carried in the Network Layer Reachability
+     Information (NLRI) field for a route originated by a BIS in a
+     given routing domain should be associated with only that
+     routing domain; that is, no system identified by the prefix
+     should reside in a different routing domain; ambiguous routing
+     may result if several routing domains originate routes whose
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 13]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+     NLRI field contain identical NSAP address prefixes, since this
+     would imply that the same system(s) is simultaneously located
+     in several routing domains;
+
+   * Several different NSAP prefixes may be associated with a single
+     routing domain which contains a mix of systems which use NSAP
+     addresses assigned by several different addressing authorities.
+
+   IDRP assumes that the above guidelines have been satisfied,  but it
+   contains no means to verify that this is so.  Therefore, such
+   verification is assumed to be the responsibility of the
+   administrators of routing domains.
+
+   IDRP provides mandatory support for data integrity and optional
+   support for data origin authentication for all of its messages.  Each
+   message carries a 16-octet digital signature that is computed by
+   applying the MD-4 algorithm (RFC 1320) to the context of the message
+   itself.  This signature provides support for data integrity.  To
+   support data origin authentication a BIS, when computing a digital
+   signature of a message, may prepend and append additional information
+   to the message.  This information is not passed as part of the
+   message but is known to the receiver.
+
+3.3.1.  Scaling Mechanisms in IDRP
+
+   The ability to group domains in RDCs provides a simple, yet powerful
+   mechanism for routing information aggregation and abstraction.  It
+   allows reduction of topological information by replacing a sequence
+   of RDIs carried by the RD_PATH attribute with a single RDCI.  It also
+   allows reduction of the amount of information related to transit
+   policies, since the policies can be expressed in terms of aggregates
+   (RDCs), rather than individual components (RDs).  It also allows
+   simplification of route selection policies, since these policies can
+   be expressed in terms of aggregates (RDCs) rather than individual
+   components (RDs).
+
+   Aggregation and abstraction of Network Layer Reachability Information
+   (NLRI) is supported by the "route aggregation" mechanism of IDRP.
+   This mechanism is complementary to the Routing Domain Confederations
+   mechanism.  Both mechanisms are intended to provide scalable routing
+   via information reduction/abstraction.  However, the two mechanisms
+   are used for different purposes: route aggregation for aggregation
+   and abstraction of routes (i.e., Network Layer Reachability
+   Information), Routing Domain Confederations for aggregation and
+   abstraction of topology and/or policy information.  To provide
+   maximum benefits, both mechanisms can be used together.  This implies
+   that address assignment that will facilitate route aggregation does
+   not conflict with the ability to form RDCs, and vice versa; formation
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 14]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   of RDCs should be done in a manner consistent with the address
+   assignment needed for route aggregation.
+
+3.4.  Requirements of IS-IS and IDRP on NSAPs
+
+   The preferred NSAP format for IS-IS is shown in Figure 1.  A number
+   of points should be noted from IS-IS:
+
+   * The IDP is as specified in ISO 8348, the OSI network layer service
+     specification [11];
+
+   * The high-order portion of the DSP (HO-DSP) is that portion of the
+     DSP whose assignment, structure, and meaning are not constrained by
+     IS-IS;
+
+   * The area address (i.e., the concatenation of the IDP and the
+     HO-DSP) must be globally unique.  If the area address of an NSAP
+     matches one of the area addresses of a router, it is in the
+     router'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 method presented in RFC 1526 [18] may optionally be
+     used to assure globally unique IDs;
+
+   * 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.  However, within a routing domain that conforms to IS-IS,
+     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 IS-IS
+     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
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 15]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   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 an appropriate "border" router, from which they will
+   exit the domain).
+
+   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.
+
+   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 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
+   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 indirect providers would become
+   blurred.
+
+   An additional factor that discourages allocation of NSAPs from an
+   indirect provider's prefix is that the indirect providers and their
+   attached direct providers are perceived as being independent.  Direct
+   providers may take their indirect provider service from one or more
+   providers, or may switch indirect providers should a more cost-
+   effective service be available elsewhere (essentially, indirect
+   providers can be thought of the same way as long-distance telephone
+   carriers).  Having NSAPs derived from the indirect providers is
+   inconsistent with the nature of the relationship.
+
+5.4.  Multi-homed Routing Domains
+
+   The discussions in Section 5.3 suggest methods for allocating NSAP
+   addresses based on service provider connectivity.  This allows a
+   great deal of information reduction to be achieved for those routing
+   domains which are attached to a single provider.  In particular, such
+   routing domains may select their NSAP addresses from a space
+   allocated to them by their direct service provider.  This allows the
+   provider, when announcing the addresses that it can reach to other
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 26]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   providers, to use a single address prefix to describe a large number
+   of NSAP addresses corresponding to multiple routing domains.
+
+   However, there are additional considerations for routing domains
+   which are attached to multiple providers.  Such "multi-homed" routing
+   domains may, for example, consist of single-site campuses and
+   companies which are attached to multiple providers, large
+   organizations which are attached to different providers at different
+   locations in the same country, or multi-national organizations which
+   are attached to providers in a variety of countries worldwide.  There
+   are a number of possible ways to deal with these multi-homed routing
+   domains.
+
+   One possible solution is to assign addresses to each multi-homed
+   organization independently from the providers to which it is
+   attached.  This allows each multi-homed organization to base its NSAP
+   assignments on a single prefix, and to thereby summarize the set of
+   all NSAPs reachable within that organization via a single prefix.
+   The disadvantage of this approach is that since the NSAP address for
+   that organization has no relationship to the addresses of any
+   particular provider, the providers to which this organization is
+   attached will need to advertise the prefix for this organization to
+   other providers.  Other providers (potentially worldwide) will need
+   to maintain an explicit entry for that organization in their routing
+   tables.  If other providers do not maintain a separate route for this
+   organization, then packets destined to this organization will be
+   lost.
+
+   For example, suppose that a very large U.S.-wide company "Mega Big
+   International Incorporated" (MBII) has a fully interconnected
+   internal network and is assigned a single AA value under the U.S.
+   GOSIP Version 2 address space.  It is likely that outside of the
+   U.S., a single entry may be maintained in routing tables for all U.S.
+   GOSIP addresses.  However, within the U.S., every "default-less"
+   provider will need to maintain a separate address entry for MBII.  If
+   MBII is in fact an international corporation, then it may be
+   necessary for every "default-less" provider worldwide to maintain a
+   separate entry for MBII (including providers to which MBII is not
+   attached).  Clearly this may be acceptable if there are a small
+   number of such multihomed routing domains, but would place an
+   unacceptable load on routers within providers if all organizations
+   were to choose such address assignments.  This solution may not scale
+   to internets where there are many hundreds of thousands of multi-
+   homed organizations.
+
+   A second possible approach would be for multi-homed organizations to
+   be assigned a separate NSAP space for each connection to a provider,
+   and to assign a single address prefix to each area within its routing
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 27]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   domain(s) based on the closest interconnection point.  For example,
+   if MBII had connections to two providers in the U.S. (one east coast,
+   and one west coast), as well as three connections to national
+   providers in Europe, and one in the far east, then MBII may make use
+   of six different address prefixes.  Each area within MBII would be
+   assigned a single address prefix based on the nearest connection.
+
+   For purposes of external routing of traffic from outside MBII to a
+   destination inside of MBII, this approach works similarly to treating
+   MBII as six separate organizations.  For purposes of internal
+   routing, or for routing traffic from inside of MBII to a destination
+   outside of MBII, this approach works the same as the first solution.
+
+   If we assume that incoming traffic (coming from outside of MBII, with
+   a destination within MBII) is always to enter via the nearest point
+   to the destination, then each provider which has a connection to MBII
+   needs to announce to other providers the ability to reach only those
+   parts of MBII whose address is taken from its own address space.
+   This implies that no additional routing information needs to be
+   exchanged between providers, resulting in a smaller load on the
+   inter-domain routing tables maintained by providers when compared to
+   the first solution.  This solution therefore scales better to
+   extremely large internets containing very large numbers of multi-
+   homed organizations.
+
+   One problem with the second solution is that backup routes to multi-
+   homed organizations are not automatically maintained.  With the first
+   solution, each provider, in announcing the ability to reach MBII,
+   specifies that it is able to reach all of the NSAPs within MBII.
+   With the second solution, each provider announces that it can reach
+   all of the NSAPs based on its own address prefix, which only includes
+   some of the NSAPs within MBII.  If the connection between MBII and
+   one particular provider were severed, then the NSAPs within MBII with
+   addresses based on that provider would become unreachable via inter-
+   domain routing.  The impact of this problem can be reduced somewhat
+   by maintenance of additional information within routing tables, but
+   this reduces the scaling advantage of the second approach.
+
+   The second solution also requires that when external connectivity
+   changes, internal addresses also change.
+
+   Also note that this and the previous approach will tend to cause
+   packets to take different routes.  With the first approach, packets
+   from outside of MBII destined for within MBII will tend to enter via
+   the point which is closest to the source (which will therefore tend
+   to maximize the load on the networks internal to MBII).  With the
+   second solution, packets from outside destined for within MBII will
+   tend to enter via the point which is closest to the destination
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 28]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   (which will tend to minimize the load on the networks within MBII,
+   and maximize the load on the providers).
+
+   These solutions also have different effects on policies.  For
+   example, suppose that country "X" has a law that traffic from a
+   source within country X to a destination within country X must at all
+   times stay entirely within the country.  With the first solution, it
+   is not possible to determine from the destination address whether or
+   not the destination is within the country.  With the second solution,
+   a separate address may be assigned to those NSAPs which are within
+   country X, thereby allowing routing policies to be followed.
+   Similarly, suppose that "Little Small Company" (LSC) has a policy
+   that its packets may never be sent to a destination that is within
+   MBII.  With either solution, the routers within LSC may be configured
+   to discard any traffic that has a destination within MBII's address
+   space.  However, with the first solution this requires one entry;
+   with the second it requires many entries and may be impossible as a
+   practical matter.
+
+   There are other possible solutions as well.  A third approach is to
+   assign each multi-homed organization a single address prefix, based
+   on one of its connections to a provider.  Other providers to which
+   the multi-homed organization are attached maintain a routing table
+   entry for the organization, but are extremely selective in terms of
+   which indirect providers are told of this route.  This approach will
+   produce a single "default" routing entry which all providers will
+   know how to reach the organization (since presumably all providers
+   will maintain routes to each other), while providing more direct
+   routing in those cases where providers agree to maintain additional
+   routing information.
+
+   There is at least one situation in which this third approach is
+   particularly appropriate.  Suppose that a special interest group of
+   organizations have deployed their own backbone.  For example, lets
+   suppose that the U.S. National Widget Manufacturers and Researchers
+   have set up a U.S.-wide backbone, which is used by corporations who
+   manufacture widgets, and certain universities which are known for
+   their widget research efforts.  We can expect that the various
+   organizations which are in the widget group will run their internal
+   networks as separate routing domains, and most of them will also be
+   attached to other providers (since most of the organizations involved
+   in widget manufacture and research will also be involved in other
+   activities).  We can therefore expect that many or most of the
+   organizations in the widget group are dual-homed, with one attachment
+   for widget-associated communications and the other attachment for
+   other types of communications.  Let's also assume that the total
+   number of organizations involved in the widget group is small enough
+   that it is reasonable to maintain a routing table containing one
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 29]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   entry per organization, but that they are distributed throughout a
+   larger internet with many millions of (mostly not widget-associated)
+   routing domains.
+
+   With the third approach, each multi-homed organization in the widget
+   group would make use of an address assignment based on its other
+   attachment(s) to providers (the attachments not associated with the
+   widget group).  The widget backbone would need to maintain routes to
+   the routing domains associated with the various member organizations.
+   Similarly, all members of the widget group would need to maintain a
+   table of routes to the other members via the widget backbone.
+   However, since the widget backbone does not inform other general
+   world-wide providers of what addresses it can reach (since the
+   backbone is not intended for use by other outside organizations), the
+   relatively large set of routing prefixes needs to be maintained only
+   in a limited number of places.  The addresses assigned to the various
+   organizations which are members of the widget group would provide a
+   "default route" via each members other attachments to providers,
+   while allowing communications within the widget group to use the
+   preferred path.
+
+   A fourth solution involves assignment of a particular address prefix
+   for routing domains which are attached to two or more specific
+   cooperative public service providers.  For example, suppose that
+   there are two providers "SouthNorthNet" and "NorthSouthNet" which
+   have a very large number of customers in common (i.e., there are a
+   large number of routing domains which are attached to both).  Rather
+   than getting two address prefixes (such as two AA values assigned
+   under the GOSIP address space) these organizations could obtain three
+   prefixes.  Those routing domains which are attached to NorthSouthNet
+   but not attached to SouthNorthNet obtain an address assignment based
+   on one of the prefixes.  Those routing domains which are attached to
+   SouthNorthNet but not to NorthSouthNet would obtain an address based
+   on the second prefix.  Finally, those routing domains which are
+   multi-homed to both of these networks would obtain an address based
+   on the third prefix.  Each of these two providers would then
+   advertise two prefixes to other providers, one prefix for subscriber
+   routing domains attached to it only, and one prefix for subscriber
+   routing domains attached to both.
+
+   This fourth solution could become important when use of public data
+   networks becomes more common.  In particular, it is likely that at
+   some point in the future a substantial percentage of all routing
+   domains will be attached to public data networks.  In this case,
+   nearly all government-sponsored networks (such as some regional
+   networks which receive funding from NSF, as well as government
+   sponsored backbones) may have a set of customers which overlaps
+   substantially with the public networks.
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 30]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   There are therefore a number of possible solutions to the problem of
+   assigning NSAP addresses to multi-homed routing domains.  Each of
+   these solutions has very different advantages and disadvantages.
+   Each solution places a different real (i.e., financial) cost on the
+   multi-homed organizations, and on the providers (including those to
+   which the multi-homed organizations are not attached).
+
+   In addition, most of the solutions described also highlight the need
+   for each provider to develop policy on whether and under what
+   conditions to accept customers with addresses that are not based on
+   its own address prefix, and how such non-local addresses will be
+   treated.  For example, a somewhat conservative policy might be that
+   an attached subscriber RD may use any NSAP address prefix, but that
+   addresses which are not based on the providers own prefix might not
+   be advertised to other providers.  In a less conservative policy, a
+   provider might accept customers using such non-local prefixes and
+   agree to exchange them in routing information with a defined set of
+   other providers (this set could be an a priori group of providers
+   that have something in common such as geographical location, or the
+   result of an agreement specific to the requesting subscriber).
+   Various policies involve real costs to providers, which may be
+   reflected in those policies.
+
+5.5.  Private Links
+
+   The discussion up to this point concentrates on the relationship
+   between NSAP addresses and routing between various routing domains
+   over transit routing domains, where each transit routing domain
+   interconnects a large number of routing domains and offers a more-
+   or-less public service.
+
+   However, there may also exist a large number of private point-to-
+   point links which interconnect two private routing domains.  In many
+   cases such private point-to-point links may be limited to forwarding
+   packets directly between the two private routing domains.
+
+   For example, let's suppose that the XYZ corporation does a lot of
+   business with MBII.  In this case, XYZ and MBII may contract with a
+   carrier to provide a private link between the two corporations, where
+   this link may only be used for packets whose source is within one of
+   the two corporations, and whose destination is within the other of
+   the two corporations.  Finally, suppose that the point-to-point link
+   is connected between a single router (router X) within XYZ
+   corporation and a single router (router M) within MBII.  It is
+   therefore necessary to configure router X to know which addresses can
+   be reached over this link (specifically, all addresses reachable in
+   MBII).  Similarly, it is necessary to configure router M to know
+   which addresses can be reached over this link (specifically, all
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 31]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   addresses reachable in XYZ Corporation).
+
+   The important observation to be made here is that such private links
+   may be ignored for the purpose of NSAP allocation, and do not pose a
+   problem for routing.  This is because the routing information
+   associated with private links is not propagated throughout the
+   internet, and therefore does not need to be collapsed into a
+   provider's prefix.
+
+   In our example, lets suppose that the XYZ corporation has a single
+   connection to a service provider, and has therefore received an
+   address allocation from the space administered by that provider.
+   Similarly, let's suppose that MBII, as an international corporation
+   with connections to six different providers, has chosen the second
+   solution from Section 5.4, and therefore has obtained six different
+   address allocations.  In this case, all addresses reachable in the
+   XYZ Corporation can be described by a single address prefix (implying
+   that router M only needs to be configured with a single address
+   prefix to represent the addresses reachable over this point-to-point
+   link).  All addresses reachable in MBII can be described by six
+   address prefixes (implying that router X needs to be configured with
+   six address prefixes to represent the addresses reachable over the
+   point-to-point link).
+
+   In some cases, such private point-to-point links may be permitted to
+   forward traffic for a small number of other routing domains, such as
+   closely affiliated organizations.  This will increase the
+   configuration requirements slightly.  However, provided that the
+   number of organizations using the link is relatively small, then this
+   still does not represent a significant problem.
+
+   Note that the relationship between routing and NSAP addressing
+   described in other sections of this paper is concerned with problems
+   in scaling caused by large, essentially public transit routing
+   domains which interconnect a large number of routing domains.
+   However, for the purpose of NSAP allocation, private point-to-point
+   links which interconnect only a small number of private routing
+   domains do not pose a problem, and may be ignored.  For example, this
+   implies that a single subscriber routing domain which has a single
+   connection to a "public" provider, plus a number of private point-
+   to-point links to other subscriber routing domains, can be treated as
+   if it were single-homed to the provider for the purpose of NSAP
+   address allocation.
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 32]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+5.6.  Zero-Homed Routing Domains
+
+   Currently, a very large number of organizations have internal
+   communications networks which are not connected to any external
+   network.  Such organizations may, however, have a number of private
+   point-to-point links that they use for communications with other
+   organizations.  Such organizations do not participate in global
+   routing, but are satisfied with reachability to those organizations
+   with which they have established private links.  These are referred
+   to as zero-homed routing domains.
+
+   Zero-homed routing domains can be considered as the degenerate case
+   of routing domains with private links, as discussed in the previous
+   section, and do not pose a problem for inter-domain routing.  As
+   above, the routing information exchanged across the private links
+   sees very limited distribution, usually only to the RD at the other
+   end of the link.  Thus, there are no address abstraction requirements
+   beyond those inherent in the address prefixes exchanged across the
+   private link.
+
+   However, it is important that zero-homed routing domains use valid
+   globally unique NSAP addresses.  Suppose that the zero-homed routing
+   domain is connected through a private link to an RD.  Further, this
+   RD participates in an internet that subscribes to the global OSI
+   addressing plan (i.e., ISO 8348).  This RD must be able to
+   distinguish between the zero-homed routing domain's NSAPs and any
+   other NSAPs that it may need to route to.  The only way this can be
+   guaranteed is if the zero-homed routing domain uses globally unique
+   NSAPs.
+
+5.7.  Address Transition Issues
+
+   Allocation of NSAP addresses based on connectivity to providers is
+   important to allow scaling of inter-domain routing to an internet
+   containing millions of routing domains.  However, such address
+   allocation based on topology also implies that a change in topology
+   may result in a change of address.
+
+   This need to allow for change in addresses is a natural, inevitable
+   consequence of any method for routing data abstraction.  The basic
+   notion of routing data abstraction is that there is some
+   correspondence between the address and where a system (i.e., a
+   routing domain, area, or end system) is located.  Thus if the system
+   moves, in some cases the address will have to change.  If it were
+   possible to change the connectivity between routing domains without
+   changing the addresses, then it would clearly be necessary to keep
+   track of the location of that routing domain on an individual basis.
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 33]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   Because of the rapid growth and increased commercialization of the
+   Internet, it is possible that the topology may be relatively
+   volatile.  This implies that planning for address transition is very
+   important.  Fortunately, there are a number of steps which can be
+   taken to help ease the effort required for address transition.  A
+   complete description of address transition issues is outside of the
+   scope of this paper.  However, a very brief outline of some
+   transition issues is contained in this section.
+
+   Also note that the possible requirement to transition addresses based
+   on changes in topology imply that it is valuable to anticipate the
+   future topology changes before finalizing a plan for address
+   allocation.  For example, in the case of a routing domain which is
+   initially single-homed, but which is expecting to become multi-homed
+   in the future, it may be advantageous to assign NSAP addresses based
+   on the anticipated future topology.
+
+   In general, it will not be practical to transition the NSAP addresses
+   assigned to a routing domain in an instantaneous "change the address
+   at midnight" manner.  Instead, a gradual transition is required in
+   which both the old and the new addresses will remain valid for a
+   limited period of time.  During the transition period, both the old
+   and new addresses are accepted by the end systems in the routing
+   domain, and both old and new addresses must result in correct routing
+   of packets to the destination.
+
+   Provision for transition has already been built into IS-IS.  As
+   described in Section 3, IS-IS allows multiple addresses to be
+   assigned to each area specifically for the purpose of easing
+   transition.
+
+   Similarly, there are provisions in OSI for the autoconfiguration of
+   area addresses.  This allows OSI end systems to find out their area
+   addresses automatically, either by passively observing the ES-IS IS-
+   Hello packets transmitted by routers, or by actively querying the
+   routers for their NSAP address.  If the ID portion of the address is
+   assigned in a manner which allows for globally unique IDs [18], then
+   an end system can reconfigure its entire NSAP address automatically
+   without the need for manual intervention.  However, routers will
+   still require manual address reconfiguration.
+
+   During the transition period, it is important that packets using the
+   old address be forwarded correctly, even when the topology has
+   changed.  This is facilitated by the use of "best match" inter-domain
+   routing.
+
+   For example, suppose that the XYZ Corporation was previously
+   connected only to the NorthSouthNet provider.  The XYZ Corporation
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 34]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   therefore went off to the NorthSouthNet administration and got a
+   routing domain assignment based on the AA value obtained by the
+   NorthSouthNet under the GOSIP address space.  However, for a variety
+   of reasons, the XYZ Corporation decided to terminate its association
+   with the North-SouthNet, and instead connect directly to the
+   NewCommercialNet public data network.  Thus the XYZ Corporation now
+   has a new address assignment under the ANSI address assigned to the
+   NewCommercialNet.  The old address for the XYZ Corporation would seem
+   to imply that traffic for the XYZ Corporation should be routed to the
+   NorthSouthNet, which no longer has any direct connection with XYZ
+   Corporation.
+
+   If the old provider (NorthSouthNet) and the new provider
+   (NewCommercialNet) are adjacent and cooperative, then this transition
+   is easy to accomplish.  In this case, packets routed to the XYZ
+   Corporation using the old address assignment could be routed to the
+   NorthSouthNet, which would directly forward them to the
+   NewCommercialNet, which would in turn forward them to XYZ
+   Corporation.  In this case only NorthSouthNet and NewCommercialNet
+   need be aware of the fact that the old address refers to a
+   destination which is no longer directly attached to NorthSouthNet.
+
+   If the old provider and the new provider are not adjacent, then the
+   situation is a bit more complex, but there are still several possible
+   ways to forward traffic correctly.
+
+   If the old provider and the new provider are themselves connected by
+   other cooperative providers, then these intermediate domains may
+   agree to forward traffic for XYZ correctly.  For example, suppose
+   that NorthSouthNet and NewCommercialNet are not directly connected,
+   but that they are both directly connected to the NSFNET backbone.  In
+   this case, all three of NorthSouthNet, NewCommercialNet, and the
+   NSFNET backbone would need to maintain a special entry for XYZ
+   corporation so that traffic to XYZ using the old address allocation
+   would be forwarded via NewCommercialNet.  However, other routing
+   domains would not need to be aware of the new location for XYZ
+   Corporation.
+
+   Suppose that the old provider and the new provider are separated by a
+   non-cooperative routing domain, or by a long path of routing domains.
+   In this case, the old provider could encapsulate traffic to XYZ
+   Corporation in order to deliver such packets to the correct backbone.
+
+   Also, those locations which do a significant amount of business with
+   XYZ Corporation could have a specific entry in their routing tables
+   added to ensure optimal routing of packets to XYZ.  For example,
+   suppose that another commercial backbone "OldCommercialNet" has a
+   large number of customers which exchange traffic with XYZ
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 35]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   Corporation, and that this third provider is directly connected to
+   both NorthSouthNet and NewCommercialNet.  In this case
+   OldCommercialNet will continue to have a single entry in its routing
+   tables for other traffic destined for NorthSouthNet, but may choose
+   to add one additional (more specific) entry to ensure that packets
+   sent to XYZ Corporation's old address are routed correctly.
+
+   Whichever method is used to ease address transition, the goal is that
+   knowledge relating XYZ to its old address that is held throughout the
+   global internet would eventually be replaced with the new
+   information.  It is reasonable to expect this to take weeks or months
+   and will be accomplished through the distributed directory system.
+   Discussion of the directory, along with other address transition
+   techniques such as automatically informing the source of a changed
+   address, are outside the scope of this paper.
+
+6.  Recommendations
+
+   We anticipate that the current exponential growth of the Internet
+   will continue or accelerate for the foreseeable future.  In addition,
+   we anticipate a continuation of the rapid internationalization of the
+   Internet.  The ability of routing to scale is dependent upon the use
+   of data abstraction based on hierarchical NSAP addresses.  As CLNP
+   use increases in the Internet, it is therefore essential to assign
+   NSAP addresses with great care.
+
+   It is in the best interests of the internetworking community that the
+   cost of operations be kept to a minimum where possible.  In the case
+   of NSAP allocation, this again means that routing data abstraction
+   must be encouraged.
+
+   In order for data abstraction to be possible, the assignment of NSAP
+   addresses must be accomplished in a manner which is consistent with
+   the actual physical topology of the Internet.  For example, in those
+   cases where organizational and administrative boundaries are not
+   related to actual network topology, address assignment based on such
+   organization boundaries is not recommended.
+
+   The intra-domain IS-IS routing protocol allows for information
+   abstraction to be maintained at two levels: systems are grouped into
+   areas, and areas are interconnected to form a routing domain.  The
+   inter-domain IDRP routing protocol allows for information abstraction
+   to be maintained at multiple levels by grouping routing domains into
+   Routing Domain Confederations and using route aggregation
+   capabilities.
+
+   For zero-homed and single-homed routing domains (which are expected
+   to remain zero-homed or single-homed), we recommend that the NSAP
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 36]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   addresses assigned for OSI use within a single routing domain use a
+   single address prefix assigned to that domain.  Specifically, this
+   allows the set of all NSAP addresses reachable within a single domain
+   to be fully described via a single prefix.  We recommend that
+   single-homed routing domains use an address prefix based on its
+   connectivity to a public service provider.  We recommend that zero-
+   homed routing domains use globally unique addresses.
+
+   We anticipate that the total number of routing domains existing on a
+   worldwide OSI Internet to be great enough that additional levels of
+   hierarchical data abstraction beyond the routing domain level will be
+   necessary.  To provide the needed data abstraction we recommend to
+   use Routing Domain Confederations and route aggregation capabilities
+   of IDRP.
+
+   The general technical requirements for NSAP address guidelines do not
+   vary from country to country.  However, details of address
+   administration may vary between countries.  Also, in most cases,
+   network topology will have a close relationship with national
+   boundaries.  For example, the degree of network connectivity will
+   often be greater within a single country than between countries.  It
+   is therefore appropriate to make specific recommendations based on
+   national boundaries, with the understanding that there may be
+   specific situations where these general recommendations need to be
+   modified.  Moreover, that suggests that national boundaries may be
+   used to group domains into Routing Domain Confederations.
+
+   Each of the country-specific or continent-specific recommendations
+   presented below are consistent with the technical requirements for
+   scaling of addressing and routing presented in this RFC.
+
+6.1.  Recommendations Specific to U.S. Parts of the Internet
+
+   NSAP addresses for use within the U.S. portion of the Internet are
+   expected to be based primarily on two address prefixes: the ICD=0005
+   format used by The U.S. Government, and the DCC=840 format defined by
+   ANSI.
+
+   We anticipate that, in the U.S., public interconnectivity between
+   private routing domains will be provided by a diverse set of
+   providers, including (but not necessarily limited to) regional
+   providers and commercial Public Data Networks.
+
+   These networks are not expected to be interconnected in a strictly
+   hierarchical manner.  For example, the regional providers may be
+   directly connected rather than rely on an indirect provider, and all
+   three of these types of networks may have direct international
+   connections.
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 37]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   However, the total number of such providers is expected to remain
+   (for the foreseeable future) small enough to allow addressing of this
+   set of providers via a flat address space.  These providers will be
+   used to interconnect a wide variety of routing domains, each of which
+   may comprise a single corporation, part of a corporation, a
+   university campus, a government agency, or other organizational unit.
+
+   In addition, some private corporations may be expected to make use of
+   dedicated private providers for communication within their own
+   corporations.
+
+   We anticipate that the great majority of routing domains will be
+   attached to only one of the providers.  This will permit hierarchical
+   address abbreviation based on provider.  We therefore strongly
+   recommend that addresses be assigned hierarchically, based on address
+   prefixes assigned to individual providers.
+
+   For the GOSIP address format, this implies that Administrative
+   Authority (AA) identifiers should be obtained by all providers
+   (explicitly including the NSFNET backbone, the NSFNET regionals, and
+   other major government backbones).  For those subscriber routing
+   domains which are connected to a single provider, they should be
+   assigned a Routing Domain (RD) value from the space assigned to that
+   provider.
+
+   To provide routing information aggregation/abstraction we recommend
+   that each provider together with all of its subscriber domains form a
+   Routing Domain Confederation.  That, combined with  hierarchical
+   address assignment, would provide significant reduction in the volume
+   of routing information that needs to be handled by IDRP.  Note that
+   the presence of multihomed subscriber domains would imply that such
+   Confederations will overlap, which is explicitly supported by IDRP.
+
+   We recommend that all providers explicitly be involved in the task of
+   address administration for those subscriber routing domains which are
+   single-homed to them.  This offers a valuable service to their
+   customers, and also greatly reduces the resources (including human
+   and network resources) necessary for that provider to take part in
+   inter-domain routing.
+
+   Each provider should develop policy on whether and under what
+   conditions to accept customers using addresses that are not based on
+   the provider's own address prefix, and how such non-local addresses
+   will be treated.  Policies should reflect the issue of cost
+   associated with implementing such policies.
+
+   We recommend that a similar hierarchical model be used for NSAP
+   addresses using the DCC-based address format.  The structure for
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 38]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   DCC=840-based NSAPs is provided in Section A.2.
+
+   For routing domains which are not attached to any publically-
+   available provider, no urgent need for hierarchical address
+   abbreviation exists.  We do not, therefore, make any additional
+   recommendations for such "isolated" routing domains, except to note
+   that there is no technical reason to preclude assignment of GOSIP AA
+   identifier values or ANSI organization identifiers to such domains.
+   Where such domains are connected to other domains by private point-
+   to-point links, and where such links are used solely for routing
+   between the two domains that they interconnect, no additional
+   technical problems relating to address abbreviation is caused by such
+   a link, and no specific additional recommendations are necessary.
+
+6.2.  Recommendations Specific to European Parts of the Internet
+
+   This section contains additional RARE recommendations for allocating
+   NSAP addresses within each national domain, administered by a
+   National Standardization Organization (NSO) and national research
+   network organizations.
+
+   NSAP addresses are expected to be based on the ISO DCC scheme.
+   Organizations which are not associated with a particular country and
+   which have reasons not to use a national prefix based on ISO DCC
+   should follow the recommendations covered in chapters 6.3 and 6.4.
+
+   ISO DCC addresses are not associated with any specific subnetwork
+   type and service provider and are thus independent of the type or
+   ownership of the underlying technology.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 39]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+6.2.1.  General NSAP Structure
+
+   The general structure of a Network Address defined in ISO 8348 is
+   further divided into:
+
+          +-----------+-----------------------------------------+
+          |    IDP    |                 DSP                     |
+          +-----+-----+-----------+-----------------------------+
+          | AFI | IDI |    CDP    |             CDSP            |
+          +-----+-----+-----+-----+----------------+------+-----+
+          | AFI | IDI | CFI | CDI |      RDAA      |  ID  | SEL |
+          +-----+-----+-----+-----+----------------+------+-----+
+   octets |  1  |  2  |   2..4    |     0..13      | 1..8 |  1  |
+          +-----+-----+-----------+----------------+------+-----+
+
+   IDP    Initial Domain Part
+   AFI    Authority and Format Identifier, two-decimal-digit,
+          38 for decimal abstract syntax of the DSP or
+          39 for binary abstract syntax of the DSP
+   IDI    Initial Domain Identifier, a three-decimal-digit
+          country code, as defined in ISO 3166
+   DSP    Domain Specific Part
+   CDP    Country Domain Part, 2..4 octets
+   CFI    Country Format Identifier, one digit
+   CDI    Country Domain Identifier, 3 to 7 digits, fills
+          CDP to an octet boundary
+   CDSP   Country Domain Specific Part
+   RDAA   Routing Domain and Area Address
+   ID     System Identifier (1..8 octet)
+   SEL    NSAP Selector
+
+   The total length of an NSAP can vary from 7 to 20 octets.
+
+6.2.2.  Structure of the Country Domain Part
+
+   The CDP identifies an organization within a country and the  CDSP  is
+   then available to that organization for further internal structuring
+   as it wishes.  Non-ambiguity of addresses is ensured by there being
+   the NSO a single national body that allocates the CDPs.
+
+   The CDP is further divided into CFI and CDI, where the CFI identifies
+   the format of the CDI.  The importance of this is that it enables
+   several types of CDI to be assigned in parallel, corresponding to
+   organizations  with different requirements and giving different
+   amounts of the total address space to them, and that it conveniently
+   enables a substantial amount of address space to be reserved for
+   future allocation.
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 40]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   The possible structures of the CDP are as follows:
+
+   CFI = /0                    reserved
+   CFI = /1 CDI = /aaa         very large organizations or
+                               trade associations
+   CFI = /2 CDI = /aaaaa       organizations of intermediate size
+   CFI = /3 CDI = /aaaaaaa     small organizations and single users
+   CFI = /4../F                reserved
+
+   Note: this uses the hexadecimal reference publication format defined
+   in ISO 8348 of a solidus "/" followed by a string of hexadecimal
+   digits.  Each "a" represents a hexadecimal digit.
+
+   Organizations are classified into large, medium and small for the
+   purpose of address allocation, and one CFI is made available for each
+   category of organization.
+
+   This recommendation for CDP leaves space for the U.S. GOSIP Version 2
+   NSAP model (Appendix A.1) by the reserved CFI /8, nevertheless it is
+   not recommended for use in the European Internet.
+
+6.2.3.  Structure of the Country Domain Specific Part
+
+   The CDSP must have a structure (within the decimal digit or binary
+   octet syntax selected by the AFI value 38 or 39) satisfying both the
+   routing requirements (IS-IS) and the logical requirements of the
+   organization identified (CFI + CDI).
+
+6.3.  Recommendations Specific to Other Parts of the Internet
+
+   For the part of the Internet which is outside of the U.S. and Europe,
+   it is recommended that the DSP format be structured hierarchically
+   similarly to that specified within the U.S. and Europe no matter
+   whether the addresses are based on DCC or ICD format.
+
+   Further, in order to allow aggregation of NSAPs at national
+   boundaries into as few prefixes as possible, we further recommend
+   that NSAPs allocated to routing domains should be assigned based on
+   each routing domain's connectivity to a national Internet backbone.
+
+6.4.  Recommendations for Multi-Homed Routing Domains
+
+   Some routing domains will be attached to multiple providers within
+   the same country, or to providers within multiple countries.  We
+   refer to these as "multi-homed" routing domains.  Clearly the strict
+   hierarchical model discussed above does not neatly handle such
+   routing domains.
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 41]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   There are several possible ways that these multi-homed routing
+   domains may be handled.  Each of these methods vary with respect to
+   the amount of information that must be maintained for inter-domain
+   routing and also with respect to the inter-domain routes.  In
+   addition, the organization that will bear the brunt of this cost
+   varies with the possible solutions.  For example, the solutions vary
+   with respect to:
+
+   * resources used within routers within the providers;
+
+   * administrative cost on provider personnel; and,
+
+   * difficulty of configuration of policy-based inter-domain
+     routing information within subscriber routing domains.
+
+   Also, the solution used may affect the actual routes which packets
+   follow, and may effect the availability of backup routes when the
+   primary route fails.
+
+   For these reasons it is not possible to mandate a single solution for
+   all situations.  Rather, economic considerations will require a
+   variety of solutions for different subscriber routing domains and
+   providers.
+
+6.5.  Recommendations for RDI and RDCI assignment
+
+   While RDIs and RDCIs need not be related to the set of addresses
+   within the domains (confederations) they depict, for the sake of
+   simplicity we recommend that RDIs and RDCIs be assigned based on the
+   NSAP prefixes assigned to domains and confederations.
+
+   A subscriber RD should use the NSAP prefix assigned to it as its RDI.
+   A multihomed RD should use one of the NSAP prefixes assigned to it as
+   its RDI.  If a service provider forms a Routing Domain Confederation
+   with some of its subscribers and the subscribers take their addresses
+   out of the provider, then the NSAP prefix assigned to the provider
+   should be used as the RDCI of the confederation.  In this case the
+   provider may use a longer NSAP prefix for its own RDIs.  In all other
+   cases a provider should use the address prefix that it uses for
+   assigning addresses to systems within the provider as its RDI.
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo (except for the
+   discussion of IS-IS authentication in Section 3.2).
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 42]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+8.  Authors' Addresses
+
+   Richard P. Colella
+   National Institute of Standards & Technology
+   Building 225/Room B217
+   Gaithersburg, MD 20899
+
+   Phone: (301) 975-3627
+   EMail:  colella@nist.gov
+
+
+   Ross Callon
+   c/o Wellfleet Communications, Inc
+   2 Federal Street
+   Billerica, MA 01821
+
+   Phone: (508) 436-3936
+   EMail:  callon@wellfleet.com
+
+
+   Ella P. Gardner
+   The MITRE Corporation
+   7525 Colshire Drive
+   McLean, VA 22102-3481
+
+   Phone: (703) 883-5826
+   EMail:  epg@gateway.mitre.org
+
+
+   Yakov Rekhter
+   T.J. Watson Research Center, IBM Corporation
+   P.O. Box 218
+   Yorktown Heights, NY 10598
+
+   Phone: (914) 945-3896
+   EMail: yakov@watson.ibm.com
+
+9.  Acknowledgments
+
+   The authors would like to thank the members of the IETF OSI-NSAP
+   Working Group and of RARE WG4 for the helpful suggestions made during
+   the writing of this paper.  We would also like to thank Radia Perlman
+   of Novell, Marcel Wiget of SWITCH, and Cathy Wittbrodt of BARRnet for
+   their ideas and help.
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 43]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+10.  References
+
+   [1] ANSI, "American National Standard for the Structure and Semantics
+       of the Domain-Specific Part (DSP) of the OSI Network Service
+       Access Point (NSAP) Address", American National Standard X3.216-
+       1992.
+
+   [2] Boland, T., "Government Open Systems Interconnection Profile
+       Users' Guide Version 2 [DRAFT]", NIST Special Publication,
+       National Institute of Standards and Technology, Computer Systems
+       Laboratory, Gaithersburg, MD, June 1991.
+
+   [3] GOSIP Advanced Requirements Group, "Government Open Systems
+       Interconnection Profile (GOSIP) Version 2", Federal Information
+       Processing Standard 146-1, U.S. Department of Commerce, National
+       Institute of Standards and Technology, Gaithersburg, MD, April
+       1991.
+
+   [4] Hemrick, C., "The OSI Network Layer Addressing Scheme, Its
+       Implications, and Considerations for Implementation", NTIA Report
+       85186, U.S. Department of Commerce, National Telecommunications
+       and Information Administration, 1985.
+
+   [5] ISO, "Addendum to the Network Service Definition Covering Network
+       Layer Addressing," RFC 941, ISO, April 1985.
+
+   [6] ISO/IEC, "Codes for the Representation of Names of Countries",
+       International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
+
+   [7] ISO/IEC, "Data Interchange - Structures for the Identification of
+       Organization", International Standard 6523, ISO/IEC JTC 1,
+       Switzerland, 1984.
+
+   [8] ISO/IEC, "Information Processing Systems - Open Systems
+       Interconnection -- Basic Reference Model", International Standard
+       7498, ISO/IEC JTC 1, Switzerland, 1984.
+
+   [9] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
+       Service", International Standard 8473, ISO/IEC JTC 1,
+       Switzerland, 1986.
+
+  [10] ISO/IEC, "End System to Intermediate System Routing Exchange
+       Protocol for use in Conjunction with the Protocol for the
+       Provision of the Connectionless-mode Network Service",
+       International Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 44]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+  [11] ISO/IEC, "Information Processing Systems -- Data Communications
+       -- Network Service Definition", International Standard 8348,
+       1992.
+
+  [12] ISO/IEC, "Information Processing Systems - OSI Reference Model -
+       Part3: Naming and Addressing", Draft International Standard
+       7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
+
+  [13] ISO/IEC, "Information Technology - Telecommunications and
+       Information Exchange Between Systems - OSI Routeing Framework",
+       Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
+
+  [14] ISO/IEC, "Intermediate System to Intermediate System Intra-Domain
+       Routeing Exchange Protocol for use in Conjunction with the
+       Protocol for Providing the Connectionless-Mode Network Service
+       (ISO 8473)", International Standard ISO/IEC 10589, 1992.
+
+  [15] Loughheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
+       (BGP-3)"  RFC 1267, cisco Systems, T.J. Watson Research Center,
+       IBM Corp., October 1991.
+
+  [16] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
+       Information among Intermediate Systems to support Forwarding of
+       ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1,
+       Switzerland 1993.
+
+  [17] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
+       Proposal for Internet Addressing and Routing", RFC 1347, DEC,
+       June 1992.
+
+  [18] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
+       Hosts", RFC 1526, Bellcore, September 1993.
+
+  [19] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
+       Domain Routing (CIDR): an Address Assignment and Aggregation
+       Strategy", RFC 1519, BARRNet, cisco, OARnet, September 1993.
+
+  [20] ISO/IEC JTC1/SC6, "Addendum to ISO 9542 Covering Address
+       Administration", N6273, March 1991.
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 45]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+A.  Administration of NSAPs
+
+   NSAPs represent the endpoints of communication through the Network
+   Layer and must be globally unique [4].  ISO 8348 defines the
+   semantics of the NSAP and the abstract syntaxes in which the
+   semantics of the Network address can be expressed [11].
+
+   The NSAP consists of the initial domain part (IDP) and the domain
+   specific part (DSP).  The initial domain part of the NSAP consists of
+   an authority and format identifier (AFI) and an initial domain
+   identifier (IDI).  The AFI specifies the format of the IDI, the
+   network addressing authority responsible for allocating values of the
+   IDI, and the abstract syntax of the DSP.  The IDI specifies the
+   addressing subdomain from which values of the DSP are allocated and
+   the network addressing authority responsible for allocating values of
+   the DSP from that domain.  The structure and semantics of the DSP are
+   determined by the authority identified by the IDI.  Figure 3 shows
+   the NSAP address structure.
+
+     +-----------+
+     |   IDP     |
+     +-----+-----+-------------------------------------------------+
+     | AFI | IDI |<--------------------DSP------------------------>|
+     +-----+-----+-------------------------------------------------+
+
+              IDP  Initial Domain Part
+              AFI  Authority and Format Identifier
+              IDI  Initial Domain Identifier
+              DSP  Domain Specific Part
+
+              Figure 3: NSAP address structure.
+
+   The global network addressing domain consists of all the NSAP
+   addresses in the OSI environment.  Within that environment, seven
+   second-level addressing domains and corresponding IDI formats are
+   described in ISO 8348:
+
+      * X.121 for public data networks
+
+      * F.69 for telex
+
+      * E.163 for the public switched telephone network numbers
+
+      * E.164 for ISDN numbers
+
+      * ISO Data Country Code (DCC), allocated according to ISO 3166 [6]
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 46]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+      * ISO International Code Designator (ICD), allocated according to
+        ISO 6523 [7]
+
+      * Local to accommodate the coexistence of OSI and non-OSI network
+        addressing schemes.
+
+   For OSI networks in the U.S., portions of the ICD subdomain are
+   available for use through the U.S. Government, and the DCC subdomain
+   is available for use through The American National Standards
+   Institute (ANSI).  The British Standards Institute is the
+   registration authority for the ICD subdomain, and has registered four
+   IDIs for the U.S. Government: those used for GOSIP, DoD, OSINET, and
+   the OSI Implementors Workshop.  ANSI, as the U.S. ISO Member Body, is
+   the registration authority for the DCC domain in the United States.
+
+A.1  GOSIP Version 2 NSAPs
+
+   GOSIP Version 2 makes available for government use an NSAP addressing
+   subdomain with a corresponding address format as illustrated in
+   Figure 2 in Section 4.2.  The "47" signifies that it is based on the
+   ICD format and uses a binary syntax for the DSP.  The 0005 is an IDI
+   value which has been assigned to the U.S. Government.  Although GOSIP
+   Version 2 NSAPs are intended primarily for U.S. Government use,
+   requests from non-government and non-U.S. organizations will be
+   considered on a case-by-case basis.
+
+   The format for the DSP under ICD=0005 has been established by the
+   National Institute of Standards and Technology (NIST), the authority
+   for the ICD=0005 domain, in GOSIP Version 2 [3] (see Figure 2,
+   Section 4.2).  NIST has delegated the authority to register AA
+   identifiers for GOSIP Version 2 NSAPs to the General Services
+   Administration (GSA).
+
+   ISO 8348 allows a maximum length of 20 octets for the NSAP address.
+   The AFI of 47 occupies one octet, and the IDI of 0005 occupies two
+   octets.  The DSP is encoded as binary as indicated by the AFI of 47.
+   One octet is allocated for a DSP Format Identifier, three octets for
+   an Administrative Authority identifier, two octets for Routing
+   Domain, two octets for Area, six octets for the System Identifier,
+   and one octet for the NSAP selector.  Note that two octets have been
+   reserved to accommodate future growth and to provide additional
+   flexibility for inter-domain routing.  The last seven octets of the
+   GOSIP NSAP format are structured in accordance with IS-IS [14], the
+   intra-domain IS-IS routing protocol.  The DSP Format Identifier (DFI)
+   identifies the format of the remaining DSP structure and may be used
+   in the future to identify additional DSP formats; the value 80h in
+   the DFI identifies the GOSIP Version 2 NSAP structure.
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 47]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   The Administrative Authority identifier names the administrative
+   authority which is responsible for registration within its domain.
+   The administrative authority may delegate the responsibilityfor
+   registering areas to the routing domains, and the routing domains may
+   delegate the authority to register System Identifiers to the areas.
+   The main responsibility of a registration authority at any level of
+   the addressing hierarchy is to assure that names of entities are
+   unambiguous, i.e., no two entities have the same name.  The
+   registration authority is also responsible for advertising the names.
+
+   A routing domain is a set of end systems and intermediate systems
+   which operate according to the same routing procedures and is wholly
+   contained within a single administrative domain.  An area uniquely
+   identifies a subdomain of the routing domain.  The system identifier
+   names a unique system within an area.  The value of the system field
+   may be a physical address (SNPA) or a logical value.  Address
+   resolution between the NSAP and the SNPA may be accomplished by an
+   ES-IS protocol [10],  locally administered tables, or mapping
+   functions.  The NSAP selector field identifies the end user of the
+   network layer service, i.e., a transport layer entity.
+
+A.1.1  Application for Administrative Authority Identifiers
+
+   The steps required for an agency to acquire an NSAP Administrative
+   Authority identifier under ICD=0005 from GSA will be provided in the
+   updated GOSIP users' guide for Version 2 [2] and are given below.
+   Requests from non-government and non-U.S. organizations should
+   originate from a senior official, such as a vice-president or chief
+   operating officer.
+
+      * Identify all end systems, intermediate systems, subnetworks, and
+        their topological and administrative relationships.
+
+      * Designate one individual (usually the agency head) within an
+        agency to authorize all registration requests from that agency
+        (NOTE: All agency requests must pass through this individual).
+
+      * Send a letter on agency letterhead and signed by the agency head
+        to GSA:
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 48]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+               Telecommunications Customer Requirements Office
+               U.S. General Services Administration
+               Information Resource Management Service
+               Office of Telecommunications Services
+               18th and F Streets, N.W.
+               Washington, DC 20405
+               Fax +1 202 208-5555
+
+        The letter should contain the following information:
+
+          - Requestor's Name and Title,
+
+          - Organization,
+
+          - Postal Address,
+
+          - Telephone and Fax Numbers,
+
+          - Electronic Mail Address(es), and,
+
+          - Reason Needed (one or two paragraphs explaining the intended
+            use).
+
+      * If accepted, GSA will send a return letter to the agency head
+        indicating the NSAP Administrative Authority identifier as-
+        signed,effective date of registration, and any other pertinent
+        information.
+
+      * If rejected, GSA will send a letter to the agency head
+        explaining the reason for rejection.
+
+      * Each Authority will administer its own subaddress space in
+        accordance with the procedures set forth by the GSA in Section
+        A.1.2.
+
+      * The GSA will maintain, publicize, and disseminate the assigned
+        values of Administrative Authority identifiers unless
+        specifically requested by an agency not to do so.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 49]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+A.1.2 Guidelines for NSAP Assignment
+
+   Recommendations which should be followed by an administrative
+   authority in making NSAP assignments are given below.
+
+
+      * The authority should determine the degree of structure of the
+        DSP under its control.  Further delegation of address assignment
+        authority (resulting in additional levels of hierarchy in the
+        NSAP) may be desired.
+
+      * The authority should make sure that portions of NSAPs that it
+        specifies are unique, current, and accurate.
+
+      * The authority should ensure that procedures exist for
+        disseminating NSAPs to routing domains and to areas within
+        each routing domain.
+
+      * The systems administrator must determine whether a logical or a
+        physical address should be used in the System Identifier field
+        (Figure 2, Section 4.2).  An example of a physical address is a
+        48-bit MAC address; a logical address is merely a number that
+        meets the uniqueness requirements for the System Identifier
+        field, but bears no relationship to an address on a physical
+        subnetwork.  We recommend that IDs should be assigned to be
+        globally unique, as made possible by the method described in
+        [18].
+
+      * The network address itself contains information that may be
+        used to aid routing, but does not contain a source route [12].
+        Information that enables next-hop determination based on NSAPs
+        is gathered and maintained by each intermediate system through
+        routing protocol exchanges.
+
+      * GOSIP end systems and intermediate systems in federal agencies
+        must be capable of routing information correctly to and from any
+        subdomain defined by ISO 8348.
+
+      * An agency may request the assignment of more than one
+        Administrative Authority identifier.  The particular use of each
+        should be specified.
+
+A.2  Data Country Code NSAPs
+
+   NSAPs from the Data Country Code (DCC) subdomain will also be common
+   in the international Internet.  ANS X3.216-1992 specifies the DSP
+   structure under DCC=840 [1].  In the ANS, the DSP structure is
+   identical to that specified in GOSIP Version 2, with the
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 50]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   Administrative Authority identifier replaced by the numeric form of
+   the ANSI-registered organization name, as shown in Figure 4.
+
+   Referring to Figure 4, when the value of the AFI is 39, the IDI
+   denotes an ISO DCC and the abstract syntax of the DSP is binary
+   octets.  The value of the IDI for the U.S. is 840, the three-digit
+   numeric code for the United States under ISO 3166 [6].  The numeric
+   form of organization name is analogous to the Administrative
+   Authority identifier in the GOSIP Version 2 NSAP.
+
+          <----IDP--->
+          +-----+-----+----------------------------------------+
+          | AFI | IDI |<----------------------DSP------------->|
+          +-----+-----+----------------------------------------+
+          | 39  | 840 | DFI |ORG | 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
+              ORG   Organization Name (numeric form)
+              Rsvd  Reserved
+              RD    Routing Domain Identifier
+              Area  Area Identifier
+              ID    System Identifier
+              SEL   NSAP Selector
+
+        Figure 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3.
+
+A.2.1  Application for Numeric Organization Name
+
+   The procedures for registration of numeric organization names in the
+   U.S. have been defined and are operational.  To register a numeric
+   organization name, the applicant must submit a request for
+   registration and the $1,000 (U.S.) fee to the registration authority,
+   the American National Standards Institute (ANSI).  ANSI will register
+   a numeric value, along with the information supplied for
+   registration, in the registration database.  The registration
+   information will be sent to the applicant within ten working days.
+   The values for numeric organization names are assigned beginning at
+   113527.
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 51]
+
+RFC 1629                    NSAP Guidelines                     May 1994
+
+
+   The application form for registering a numeric organization name may
+   be obtained from the ANSI Registration Coordinator at the following
+   address:
+
+              Registration Coordinator
+              American National Standards Institute
+              11 West 42nd Street
+              New York, NY 10036
+              +1 212 642 4884 (tel)
+              +1 212 398 0023 (fax)
+              RFC822: mmaas@attmail.com
+              X.400: G=michelle; S=maas; A=attmail; C=us
+
+   Once an organization has registered with ANSI, it becomes a
+   registration authority itself. In turn, it may delegate registration
+   authority to routing domains, and these may make further delegations,
+   for instance,  from routing domains to areas.  Again, the
+   responsibilities of each Registration Authority are to assure that
+   NSAPs within the domain are unambiguous and to advertise them as
+   applicable.
+
+A.3  Summary of Administrative Requirements
+
+   NSAPs must be globally unique, and an organization may assure this
+   uniqueness for OSI addresses in two ways.  The organization may apply
+   to GSA for an Administrative Authority identifier.  Although
+   registration of Administrative Authority identifiers by GSA primarily
+   serves U.S. Government agencies, requests for non-government and
+   non-U.S.  organizations will be considered on a case-by-case basis.
+   Alternatively, the organization may apply to ANSI for a numeric
+   organization name.  In either case, the organization becomes the
+   registration authority for its domain and can register NSAPs or
+   delegate the authority to do so.
+
+   In the case of GOSIP Version 2 NSAPs, the complete DSP structure is
+   given in GOSIP Version 2.  For ANSI DCC-based NSAPs, the DSP
+   structure is specified in ANS X3.216-1992.  The DSP structure is
+   identical to that specified in GOSIP Version 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Colella, Callon, Gardner & Rekhter                             [Page 52]
+