GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1629

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:
  1. Requestor's Name and Title,
  1. Organization,
  1. Postal Address,
  1. Telephone and Fax Numbers,
  1. Electronic Mail Address(es), and,
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1629.txt · Last modified: 1994/05/18 01:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki