As per Relevance of the word organization, we have this rfc below:

---

Network Working Group R.
Request for Comments: 1629
Obsoletes: 1237 R.
Category: Standards Track
E.

Y.
T.J. Watson Research Center, IBM Corp
May 1994


Guidelines for OSI NSAP Allocation in the

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited



CLNP is currently being deployed in the Internet. This is useful
support OSI and DECnet(tm) traffic. In addition, CLNP has
proposed as a possible IPng candidate, to provide a long-
solution to IP address exhaustion. Required as part of the
infrastructure are guidelines for network service access point (NSAP
address assignment. This paper provides guidelines for
NSAP addresses in the Internet

The guidelines provided in this paper have been the basis for
deployment of CLNP in the Internet, and have proven very
both as an aid to scaling of CLNP routing, and for
administration
















Colella, Callon, Gardner & Rekhter [Page 1]

RFC 1629 NSAP Guidelines May 1994


Table of

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
Domain ........................................... 24
Section 5.3 Administration at the Provider
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
the Internet ..................................... 37
Section 6.2 Recommendations Specific to European
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
Specific Part .................................... 41
Section 6.3 Recommendations Specific to Other Parts
the Internet ..................................... 41
Section 6.4 Recommendations for Multi-Homed
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



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
Name ............................................. 51
Section A.3 Summary of Administrative Requirements .. 52













































Colella, Callon, Gardner & Rekhter [Page 3]

RFC 1629 NSAP Guidelines May 1994


1.

The Internet is moving towards a multi-protocol environment
includes CLNP. To support CLNP in the Internet, an OSI lower
infrastructure is required. This infrastructure comprises
connectionless network protocol (CLNP) [9] and supporting
protocols. Also required as part of this infrastructure
guidelines for network service access point (NSAP)
assignment. This paper provides guidelines for allocating
addresses in the Internet (the terms NSAP and NSAP address are
interchangeably throughout this paper in referring to
addresses).

The guidelines presented in this document are quite similar to
guidelines that are proposed in the Internet for IP
allocation with CIDR (RFC 1519 [19]). The major difference
the two is the size of the addresses (4 octets for CIDR vs 20
for CLNP). The larger NSAP addresses allows considerably
flexibility and scalability

The remainder of this paper is organized into five major sections
an appendix. Section 2 defines the boundaries of the
addressed in this paper and Section 3 provides background
on OSI routing and the implications for NSAP addresses

Section 4 addresses the specific relationship between NSAP
and routing, especially with regard to hierarchical routing and
abstraction. This is followed in Section 5 with an application
these concepts to the Internet environment. Section 6
recommended guidelines for NSAP address allocation in the Internet
This includes recommendations for the U.S. and European parts of
Internet, as well as more general recommendations for any part of
Internet

The Appendix contains a compendium of useful information
NSAP structure and allocation authorities. The GOSIP Version 2
structure is discussed in detail and the structure for U.S.-based
(Data Country Code) NSAPs is described. Contact information for
registration authorities for GOSIP and DCC-based NSAPs in the U.S.,
the General Services Administration (GSA) and the American
Standards Institute (ANSI), respectively, is provided

This document obsoletes RFC 1237. The changes from RFC 1237
minor, and primarily editorial in nature. The descriptions of
routing standards contained in Section 3 have been updated to
the current status of the relevant standards, and a description
the OSI Interdomain Routing Protocol (IDRP) has been added
Recommendations specific to the European part of the Internet



Colella, Callon, Gardner & Rekhter [Page 4]

RFC 1629 NSAP Guidelines May 1994


been added in Section 6, along with recommendations for
Domain Identifiers and Routing Domain Confederation
needed for operation of IDRP

2.

Control over the collection of hosts and the transmission
switching facilities that compose the networking resources of
global Internet is not homogeneous, but is distributed among
administrative authorities. For the purposes of this paper, the
network service provider (or just provider) is defined to be
organization that is in the business of providing datagram
services to customers. Organizations that are *only*
(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
networks) attach to providers (e.g., regionals, commercial providers
and government backbones) in only one or a small number of
controlled access points. For discussion of OSI NSAP allocation
this paper, providers are treated as composing a mesh having no
hierarchy. Addressing solutions which require substantial changes
constraints on the current topology are not considered in this paper

There are two aspects of interest when discussing OSI NSAP
within the Internet. The first is the set of
requirements for obtaining and allocating NSAP addresses; the
is the technical aspect of such assignments, having largely to
with routing, both within a routing domain (intra-domain routing)
between routing domains (inter-domain routing). This paper
on the technical issues

The technical issues in NSAP allocation are mainly related
routing. This paper assumes that CLNP will be widely deployed in
Internet, and that the routing of CLNP traffic will normally be
on the OSI end-system to intermediate system routing protocol (ES-IS
[10], intra-domain IS-IS protocol [14], and inter-domain
protocol (IDRP) [16]. It is expected that in the future the
routing architecture will be enhanced to include support
multicast, resource reservation, and other advanced services.
requirements for addressing for these future services is outside
the scope of this document

The guidelines provided in this paper have been the basis for
deployment of CLNP in the Internet, and have proven very
both as an aid to scaling of CLNP routing, and to
administration




Colella, Callon, Gardner & Rekhter [Page 5]

RFC 1629 NSAP Guidelines May 1994


The guidelines in this paper are oriented primarily toward
large-scale division of NSAP address allocation in the Internet
Topics covered include

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

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

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

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

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

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

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

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

* Identification of specific administrative domains in
Internet

* Policy or mechanisms for making registered information
to third parties (such as the entity to which a specific
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
internal topology of areas or allocate portions of its
address space; the relationship between topology and
is discussed, but the method of deciding on a particular
or internal addressing plan is not; and

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

3.

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

3.1. OSI Routing

OSI partitions the routing problem into three parts

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

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

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

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

This paper examines the technical implications of NSAP
under the assumption that ES-IS, intra-domain IS-IS, and IDRP
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,
routing for OSI environments. In particular, IS-IS is designed
work in conjunction with CLNP, ES-IS, and IDRP. This section
describes the manner in which IS-IS operates

In IS-IS, the internetwork is partitioned into routing domains.
routing domain is a collection of ESs and ISs that operate
routing protocols and are under the control of a
administration (throughout this paper, "domain" and "routing domain
are used interchangeably). Typically, a routing domain may
of a corporate network, a university campus network, a
network, a backbone, or a similar contiguous network under control
a single administrative organization. The boundaries of
domains are defined by network management by setting some links to
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
domain is subdivided into areas (also known as level 1 subdomains).
Level 1 routers know the topology in their area, including
routers and hosts. However, level 1 routers do not know the
of routers or destinations outside of their area. Level 1
forward all traffic for destinations outside of their area to a
2 router within their area

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

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

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



Colella, Callon, Gardner & Rekhter [Page 8]

RFC 1629 NSAP Guidelines May 1994


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

For routing purposes, ISO addresses are subdivided by IS-IS into
area address, the system identifier (ID), and the NSAP
(SEL). The area address identifies both the routing domain and
area within the routing domain. Generally, the area
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
AFI Authority and Format
IDI Initial Domain
DSP Domain Specific
HO-DSP High-order
ID System
SEL NSAP


Figure 1: OSI Hierarchical Address Structure

The ID field may be from one to eight octets in length, but must
a single known length in any particular routing domain. Each
is configured to know what length is used in its domain. The
field is always one octet in length. Each router is therefore
to identify the ID and SEL fields as a known number of
octets of the NSAP address. The area address can be identified
the remainder of the address (after truncation of the ID and
fields). It is therefore not necessary for the area address to
any particular length -- the length of the area address could
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
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
graceful way of changing an area address from A to B is to
allow it to have both addresses A and B, and then after all
in the area have been modified to recognize both addresses, one
one the nodes can be modified to forget address A

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

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

Since the addressing explicitly identifies the area, it is very
for level 1 routers to identify packets going to destinations
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
portion of the ISO address. Level 1 routers recognize, based on
destination address in a packet, whether the destination is
the area. If so, they route towards the destination. If not,
route to the nearest level 2 router

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

A level 1 router will have the area portion of its address
configured. It will refuse to become a neighbor with a router
area addresses do not overlap its own area addresses. However, if
level 1 router has area addresses A, B, and C, and a neighbor
area addresses B and D, then the level 1 IS will accept the other
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
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
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
partition to be repaired via use of level 2 routes

IS-IS requires that the set of level 2 routers be connected.
the level 2 backbone become partitioned, there is no provision
use of level 1 links to repair a level 2 partition

Occasionally a single level 2 router may lose connectivity to
level 2 backbone. In this case the level 2 router will indicate
its level 1 routing packets that it is not "attached",
allowing level 1 routers in the area to route traffic for outside
the area to a different level 2 router. Level 1 routers
route traffic to destinations outside of their area only to level 2
routers which indicate in their level 1 routing packets that they
"attached".

A host may autoconfigure the area portion of its address
extracting the area portion of a neighboring router's address.
this is the case, then a host will always accept a router as
neighbor. Since the standard does not specify that the host *must
autoconfigure its area address, a host may be pre-configured with
area address

Special treatment is necessary for broadcast subnetworks, such
LANs. This solves two sets of issues: (i) In the absence of
treatment, each router on the subnetwork would announce a link
every other router on the subnetwork, resulting in O(n-squared)
reported; (ii) Again, in the absence of special treatment,
router on the LAN would report the same identical list of end
on the LAN, resulting in substantial duplication

These problems are avoided by use of a "pseudonode", which
the LAN. Each router on the LAN reports that it has a link to
pseudonode (rather than reporting a link to every other router on
LAN). One of the routers on the LAN is elected "designated router".
The designated router then sends out a Link State Packet (LSP)
behalf of the pseudonode, reporting links to all of the routers
the LAN. This reduces the potential n-squared links to n links.
addition, only the pseudonode LSP includes the list of end systems
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
error probability

IS-IS has a provision for authentication information to be carried
all IS-IS PDUs. Currently the only form of authentication which
defined is a simple password. A password may be associated with
link, each area, and with the level 2 subdomain. A router not
possession of the appropriate password(s) is prohibited
participating in the corresponding function (i.e., may not
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
without disrupting operation of the routing protocol.
authentication functions are extensible so that a stronger
cryptographically-based security scheme may be added in an
compatible fashion at a future date

3.3. Overview of IDRP (ISO/IEC 10747)

The Inter-Domain Routing Protocol (IDRP, ISO/IEC 10747), developed
ISO, provides routing for OSI environments. In particular, IDRP
designed to work in conjuction with CLNP, ES-IS, and IS-IS.
section briefly describes the manner in which IDRP operates

Consistent with the OSI Routing Framework [13], in IDRP
internetwork is partitioned into routing domains. IDRP places
restrictions on the inter-domain topology. A router
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
different domains but share a common subnetwork (i.e., a BIS
reach its external neighbor in a single network layer hop).
domains are said to be adjacent if they have BISs that are
neighbors of each other. A pair of BISs are called
neighbors if these BISs belong to the same domain. In contrast
external neighbors, internal neighbors don't have to share a
subnetwork -- IDRP assumes that a BIS should be able to
Network Protocol Date Units (NPDUs) with any of its
neighbors by relying solely on intra-domain routing procedures

IDRP governs the exchange of routing information between a pair
neighbors, either external or internal. IDRP is self-contained
respect to the exchange of information between external neighbors
Exchange of information between internal neighbors relies



Colella, Callon, Gardner & Rekhter [Page 12]

RFC 1629 NSAP Guidelines May 1994


additional support provided by intra-domain routing (unless
neighbors share a common subnetwork).

To facilitate routing information aggregation/abstraction,
allows grouping of a set of connected domains into a Routing
Confederation (RDC). A given domain may belong to more than one RDC
There are no restrictions on how many RDCs a given domain
simultaneously belong to, and no preconditions on how RDCs should
formed -- RDCs may be either nested, or disjoint, or may overlap
One RDC is nested within another RDC if all members (RDs) of
former are also members of the latter, but not vice versa. Two
overlap if they have members in common and also each has members
are not in the other. Two RDCs are disjoint if they have no
in common

Each domain participating in IDRP is assigned a unique Routing
Identifier (RDI). Syntactically an RDI is represented as an
network layer address. Each RDC is assigned a unique Routing
Confederation Identifier (RDCI). RDCIs are assigned out of
address space allocated for RDIs -- RDCIs and RDIs are
indistinguishable. Procedures for assigning and managing RDIs
RDCIs are outside the scope of the protocol. However, since RDIs
syntactically nothing more than network layer addresses, and
are syntactically nothing more than RDIs, it is expected that RDI
RDCI assignment and management would be part of the network
assignment and management procedures. Recommendations for RDI
RDCI assignment are provided in Section 6.5.

IDRP requires a BIS to be preconfigured with the RDI of the domain
which the BIS belongs. If a BIS belongs to a domain that is a
of one or more RDCs, then the BIS has to be preconfigured with
of all the RDCs the domain is in, and the information about
between the RDCs - nested or overlapped

IDRP doesn't assume or require any particular internal structure
the addresses. The protocol provides correct routing as long as
following guidelines are met

* End systems and intermediate systems may use any NSAP address
Network Entity Title (NET -- i.e., an NSAP address without
selector) that has been assigned under ISO 8348 [11] guidelines

* An NSAP prefix carried in the Network Layer
Information (NLRI) field for a route originated by a BIS in
given routing domain should be associated with only
routing domain; that is, no system identified by the
should reside in a different routing domain; ambiguous
may result if several routing domains originate routes



Colella, Callon, Gardner & Rekhter [Page 13]

RFC 1629 NSAP Guidelines May 1994


NLRI field contain identical NSAP address prefixes, since
would imply that the same system(s) is simultaneously
in several routing domains

* Several different NSAP prefixes may be associated with a
routing domain which contains a mix of systems which use
addresses assigned by several different addressing authorities

IDRP assumes that the above guidelines have been satisfied, but
contains no means to verify that this is so. Therefore,
verification is assumed to be the responsibility of
administrators of routing domains

IDRP provides mandatory support for data integrity and
support for data origin authentication for all of its messages.
message carries a 16-octet digital signature that is computed
applying the MD-4 algorithm (RFC 1320) to the context of the
itself. This signature provides support for data integrity.
support data origin authentication a BIS, when computing a
signature of a message, may prepend and append additional
to the message. This information is not passed as part of
message but is known to the receiver

3.3.1. Scaling Mechanisms in

The ability to group domains in RDCs provides a simple, yet
mechanism for routing information aggregation and abstraction.
allows reduction of topological information by replacing a
of RDIs carried by the RD_PATH attribute with a single RDCI. It
allows reduction of the amount of information related to
policies, since the policies can be expressed in terms of
(RDCs), rather than individual components (RDs). It also
simplification of route selection policies, since these policies
be expressed in terms of aggregates (RDCs) rather than
components (RDs).

Aggregation and abstraction of Network Layer Reachability
(NLRI) is supported by the "route aggregation" mechanism of IDRP
This mechanism is complementary to the Routing Domain
mechanism. Both mechanisms are intended to provide scalable
via information reduction/abstraction. However, the two
are used for different purposes: route aggregation for
and abstraction of routes (i.e., Network Layer
Information), Routing Domain Confederations for aggregation
abstraction of topology and/or policy information. To
maximum benefits, both mechanisms can be used together. This
that address assignment that will facilitate route aggregation
not conflict with the ability to form RDCs, and vice versa;



Colella, Callon, Gardner & Rekhter [Page 14]

RFC 1629 NSAP Guidelines May 1994


of RDCs should be done in a manner consistent with the
assignment needed for route aggregation

3.4. Requirements of IS-IS and IDRP on

The preferred NSAP format for IS-IS is shown in Figure 1. A
of points should be noted from IS-IS

* The IDP is as specified in ISO 8348, the OSI network layer
specification [11];

* The high-order portion of the DSP (HO-DSP) is that portion of
DSP whose assignment, structure, and meaning are not constrained
IS-IS

* The area address (i.e., the concatenation of the IDP and
HO-DSP) must be globally unique. If the area address of an
matches one of the area addresses of a router, it is in
router's area and is routed to by level 1 routing

* Level 2 routing acts on address prefixes, using the longest
prefix that matches the destination address

* Level 1 routing acts on the ID field. The ID field must be
within an area for ESs and level 1 ISs, and unique within
routing domain for level 2 ISs. The ID field is assumed to
flat. The method presented in RFC 1526 [18] may optionally
used to assure globally unique IDs

* The one-octet NSAP Selector, SEL, determines the entity to
the CLNP packet within the system identified by the rest of
NSAP (i.e., a transport entity) and is always the last octet of
NSAP; and

* A system shall be able to generate and forward data
containing addresses in any of the formats specified
ISO 8348. However, within a routing domain that conforms to IS-IS
the lower-order octets of the NSAP should be structured as the
and SEL fields shown in Figure 1 to take full advantage of IS-
routing. End systems with addresses which do not conform
require additional manual configuration and be subject to
routing performance

For purposes of efficient operation of the IS-IS routing protocol
several observations may be made. First, although the IS-IS
specifies an algorithm for routing within a single routing domain
the routing algorithm must efficiently route both: (i) Packets
final destination is in the domain (these must, of course, be



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
be routed to an appropriate "border" router, from which they
exit the domain).

For those destinations which are in the domain, level 2
treats the entire area address (i.e., all of the NSAP address
the ID and SEL fields) as if it were a flat field. Thus,
efficiency of level 2 routing to destinations within the domain
affected only by the number of areas in the domain, and the number
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
considerable potential advantage (in terms of reducing the amount
routing information that is required) if the number of
prefixes required to describe any particular set of
destinations can be minimized. Efficient routing with IDRP
also requires minimization of the number of address prefixes
to describe specific destinations. In other words, addresses need
be assigned with topological significance. This requirement
described in more detail in the following sections

4. NSAPs and

4.1. Routing Data

When determining an administrative policy for NSAP assignment, it
important to understand the technical consequences. The
behind the use of hierarchical routing is to achieve some level
routing data abstraction, or summarization, to reduce the
time, memory requirements, and transmission bandwidth consumed
support of routing. This implies that address assignment must
the needs of routing, in order for routing to scale to very
networks

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

Abstraction of reachability information dictates that NSAPs
assigned according to topological routing structures. However
administrative assignment falls along organizational or
boundaries. These may not be congruent to topological boundaries
and therefore the requirements of the two may collide. A
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
hierarchically arranged topological routing structures. An
lower in the hierarchy reports summary routing information to
parent(s). Within the current OSI routing framework [13] and
protocols, the lowest boundary at which this can occur is
boundary between an area and the level 2 subdomain within a IS-
routing domain. Data abstraction is designed into IS-IS at
boundary, since level 1 ISs are constrained to reporting only
addresses

Level 2 routing is based upon address prefixes. Level 2
(ISs) distribute, throughout the level 2 subdomain, the
addresses of the level 1 areas to which they are attached (and
manually configured reachable address prefixes). Level 2
compute next-hop forwarding information to all advertised
prefixes. Level 2 routing is determined by the longest
address prefix that matches the destination address

At routing domain boundaries, address prefix information is
with other routing domains via IDRP. If area addresses within
routing domain are all drawn from distinct NSAP
authorities (allowing no abstraction), then the boundary
information consists of an enumerated list of all area addresses

Alternatively, should the routing domain "own" an address prefix
assign area addresses based upon it, boundary routing information
be summarized into the single prefix. This can allow
data reduction and, therefore, will allow much better scaling (
compared to the uncoordinated area addresses discussed in
previous paragraph).

If routing domains are interconnected in a more-or-less random (non
hierarchical) scheme, it is quite likely that no further
of routing data can occur. Since routing domains would have
defined hierarchical relationship, administrators would not be
to assign area addresses out of some common prefix for the purpose
data abstraction. The result would be flat inter-domain routing;
routing domains would need explicit knowledge of all other
domains that they route to. This can work well in small- and medium
sized internets, up to a size somewhat larger than the current
Internet. However, this does not scale to very large internets.
example, we expect growth in the future to an international
which has tens or hundreds of thousands of routing domains in
U.S. alone. Even larger numbers of routing domains are possible
each home, or each small company, becomes its own routing domain
This requires a greater degree of data abstraction beyond that
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
existing hierarchical routing structure interconnections,
discussed in Section 5. Thus, there is the opportunity for a
of subscribers each to be assigned an address prefix from a
prefix assigned to their provider. Each subscriber now "owns"
(somewhat longer) prefix, from which it assigns its area addresses

The most straightforward case of this occurs when there is a set
subscribers whose routing domains are all attached only to a
service provider, and which use that provider for all
(inter-domain) traffic. A short address prefix may be assigned
the provider, which then assigns slightly longer prefixes (based
the provider's prefix) to each of the subscribers. This allows
provider, when informing other providers of the addresses that it
reach, to abbreviate the reachability information for a large
of routing domains as a single prefix. This approach therefore
allow a great deal of hierarchical abbreviation of
information, and thereby can greatly improve the scalability
inter-domain routing

Clearly, this approach is recursive and can be carried
several iterations. Routing domains at any "level" in the
may use their prefix as the basis for subsequent suballocations
assuming that the NSAP addresses remain within the overall length
structure constraints. The flexibility of NSAP addresses
this form of hierarchical address assignment and routing. As
example of how NSAPs may be used, the GOSIP Version 2 NSAP
is discussed later in this section

At this point, we observe that the number of nodes at each
level of a hierarchy tends to grow exponentially. Thus the
gains in data abstraction occur at the leaves and the gains
significantly at each higher level. Therefore, the law
diminishing returns suggests that at some point data
ceases to produce significant benefits. Determination of the
at which data abstraction ceases to be of benefit requires a
consideration of the number of routing domains that are expected
occur at each level of the hierarchy (over a given period of time),
compared to the number of routing domains and address prefixes
can conveniently and efficiently be handled via dynamic inter-
routing protocols. As the Internet grows, further levels
hierarchy may become necessary. Again, this requires
flexibility in the addressing scheme, such as is provided by
addresses







Colella, Callon, Gardner & Rekhter [Page 18]

RFC 1629 NSAP Guidelines May 1994


4.2. NSAP Administration and

There is a balance that must be sought between the requirements
NSAPs for efficient routing and the need for decentralized
administration. The NSAP structure from Version 2 of GOSIP (
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
of values 47.0005 identify the U.S. Government as the
responsible for defining the DSP structure and allocating
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
AFI Authority and Format
IDI Initial Domain
DSP Domain Specific
DFI DSP Format
AA Administrative
Rsvd
RD Routing Domain
Area Area
ID System
SEL NSAP

Figure 2: GOSIP Version 2 NSAP structure

[Note: We are using U.S. GOSIP version 2 addresses only as
example. It is not necessary that NSAPs be allocated from the
Version 2 authority under 47.0005. The ANSI format under the
Country Code for the U.S. (DCC=840) and formats assigned to
countries and ISO members or liaison organizations are also
used, and work equally well. For parts of the Internet outside
the U.S. there may in some cases be strong reasons to prefer
country- or area-specific format rather than the U.S. GOSIP format
However, GOSIP addresses are used in most cases in the examples
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
values under the GOSIP address space has already been established
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
unique address prefix assigned to an administration

American National Standard X3.216-1992 [1] specifies the structure
the DSP for NSAP addresses that use an Authority and
Identifier (AFI) value of (decimal) 39, which identifies the "ISO
DCC" (data country code) format, in which the value of the
Domain Identifier (IDI) is (decimal) 840, which identifies the U.S
National Body (ANSI). This DSP structure is identical to
structure that is specified by GOSIP Version 2. The AA field
called "org" for organization identifier in the ANSI standard,
the ID field is called "system". The ANSI format, therefore,
from the GOSIP format illustrated above only in that the AFI and
specify the "ISO-DCC" format rather than the "ISO 6523-ICD"
used by GOSIP, and the "AA" field is administered by an
registration authority rather than by the GSA.
identifiers may be obtained from ANSI. The technical
applicable to NSAP administration are independent of whether a
Version 2 or an ANSI value is used for the NSAP assignment

Similarly, although other countries make use of different
formats, the principles of NSAP assignment and use are the same.
NSAP formats recommended by RARE WG4 for use in Europe are
in Section 6.2.

In the low-order part of the GOSIP Version 2 NSAP format, two
are defined in addition to those required by IS-IS. These fields,
and Area, are defined to allow allocation of NSAPs along
boundaries in support of increased data abstraction.
assign RD identifiers underneath their unique address prefix (
reserved field is left to accommodate future growth and to
additional flexibility for inter-domain routing). Routing
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
routing domain into one prefix. If the AA identifier is
topological significance (in addition to
significance), an additional level of data abstraction can
obtained, as is discussed in the next section

5. NSAP Administration and Routing in the

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

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

We assume that most subscribers will prefer to operate a
domain separate from their provider's. Such subscribers can
routing information with their provider via interior routing
route leaking or via IDRP; for the purposes of this discussion,
choice is not significant. The subscriber is still allocated
prefix from the provider's address space, and the provider
its own prefix into inter-domain routing

Given such a mapping, where should address administration
allocation be performed to satisfy both
decentralization and data abstraction? Three possibilities
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
primary purpose is to provide intra-domain routing services.
routing domains are deployed to carry transit (i.e., inter-domain
traffic

The greatest burden in transmitting and operating on
information is at the top of the routing hierarchy, where
information tends to accumulate. In the Internet, for example,
provider must manage the set of network numbers for all
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
based on inter-domain routing information obtained from
providers or, in some cases, to a default provider

In general, higher levels of the routing hierarchy will benefit
most from the abstraction of routing information at a lower level
the routing hierarchy. There is relatively little direct benefit
the administration that performs the abstraction, since it
maintain routing information individually on each
topological routing structure

For example, suppose that a given subscriber is trying to
whether to obtain an NSAP address prefix based on an AA value
GSA (implying that the first four octets of the address would
those assigned out of the GOSIP space), or based on an RD value
its provider (implying that the first seven octets of the address
those obtained by that provider). If considering only their
self-interest, the subscriber and its local provider have
reason to choose one approach or the other. The subscriber must
one prefix or another; the source of the prefix has little effect
routing efficiency within the subscriber's routing domain.
provider must maintain information about each attached subscriber
order to route, regardless of any commonality in the prefixes of
subscribers

However, there is a difference when the local provider
routing information to other providers. In the first case,
provider cannot aggregate the subscriber's address into its
prefix; the address must be explicitly listed in routing exchanges
resulting in an additional burden to other providers which
exchange and maintain this information

In the second case, each other provider sees a single address
for the local provider which encompasses the new subscriber.
avoids the exchange of additional routing information to identify
new subscriber's address prefix. Thus, the advantages
benefit other providers which maintain routing information about
provider (and its subscribers).

Clearly, a symmetric application of these principles is in
interest of all providers, enabling them to more efficiently
CLNP routing to their customers. The guidelines discussed
describe reasonable ways of managing the OSI address space
benefit the entire community







Colella, Callon, Gardner & Rekhter [Page 22]

RFC 1629 NSAP Guidelines May 1994


5.1. Administration at the

If areas take their area addresses from a myriad of unrelated
allocation authorities, there will be effectively no data
beyond what is built into IS-IS. For example, assume that within
routing domain three areas take their area addresses, respectively
out of

* the GOSIP Version 2 authority assigned to the
of Commerce, with an AA of nnn

AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;

* the GOSIP Version 2 authority assigned to the
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
routing domain, there is no harm in having the different areas in
routing domain use addresses obtained from a wide variety
administrations. For routing within the domain, the area
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
this domain. There is no common prefix that can be used to
these NSAPs and therefore no summarization can take place at
routing domain boundary. When addresses are advertised by
routing domain to other routing domains, an enumerated list must
used consisting of the three area addresses

This situation is roughly analogous to the dissemination of
information in the TCP/IP Internet prior to the introduction of CIDR
Areas correspond roughly to networks and area addresses to
numbers. The result of allowing areas within a routing domain
take their NSAPs from unrelated authorities is flat routing at
area address level. The number of address prefixes that
routing domains would advertise is on the order of the number
attached areas; the number of prefixes a provider routing
would advertise is approximately the number of areas attached to



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
would be on the order of the number of area addresses globally.
the CLNP internet grows this would quickly become intractable.
greater degree of hierarchical information reduction is necessary
allow greater growth

5.2. Administration at the Subscriber Routing

As mentioned previously, the greatest degree of data
comes at the lowest levels of the hierarchy. Providing
subscriber routing domain (that is, site) with a unique
results in the biggest single increase in abstraction, with
subscriber domain assigning area addresses from its prefix.
outside the subscriber routing domain, the set of all
reachable in the domain can then be represented by a single prefix

As an example, assume a government agency has been assigned the
value of zzz under ICD=0005. The agency then assigns a
domain identifier to a routing domain under its
authority identifier, rrr. The resulting prefix for the
domain is

AFI=47, IDI=0005, DFI=80h, AA=zzz, (Rsvd=0), RD=rrr

All areas within this routing domain would have area
comprising this prefix followed by an Area identifier. The
represents the summary of reachable addresses within the
domain

There is a close relationship between areas and routing
implicit in the fact that they operate a common routing protocol
are under the control of a single administration. The routing
administration subdivides the domain into areas and structures
level 2 subdomain (i.e., a level 2 backbone) which
connectivity among the areas. The routing domain represents the
path between an area and the rest of the internetwork. It
reasonable that this relationship also extend to include a
NSAP addressing authority. Thus, the areas within the subscriber
should take their NSAPs from the prefix assigned to the
RD

5.3. Administration at the Provider Routing

Two kinds of provider routing domains are considered,
providers and indirect providers. Most of the subscribers of
direct provider are domains that act solely as service
(i.e., they carry no transit traffic). Most of the "subscribers"



Colella, Callon, Gardner & Rekhter [Page 24]

RFC 1629 NSAP Guidelines May 1994


an indirect provider are, themselves, service providers. In
terminology a backbone is an indirect provider, while a regional is
direct provider. Each case is discussed separately below

5.3.1. Direct Service

It is interesting to consider whether direct service providers
routing domains should be the common authority for assigning
from a unique prefix to the subscriber routing domains that
serve. In the long term the number of routing domains in
Internet will grow to the point that it will be infeasible to
on the basis of a flat field of routing domains. It will
be essential to provide a greater degree of information abstraction

Direct providers may assign prefixes to subscriber domains, based
a single (shorter length) address prefix assigned to the provider
For example, given the GOSIP Version 2 address structure, an AA
may be assigned to each direct provider, and routing domain
may be assigned by the provider to each attached subscriber
domain. A similar hierarchical address assignment based on a
assigned to each provider may be used for other NSAP formats.
results in direct providers advertising to other providers (
direct and indirect) a small fraction of the number of
prefixes that would be necessary if they enumerated the
prefixes of the subscriber routing domains. This represents
significant savings given the expected scale of
internetworking

Are subscriber routing domains willing to accept prefixes
from the direct providers? In the supplier/consumer model, the
provider is offering connectivity as the service, priced according
its costs of operation. This includes the "price" of
service from one or more indirect providers and exchanging
information with other direct providers. In general, providers
want to handle as few address prefixes as possible to keep costs low
In the Internet environment, subscriber routing domains must
sensitive to the resource constraints of the providers (both
and indirect). The efficiencies gained in routing clearly
the adoption of NSAP administration by the direct providers

The mechanics of this scenario are straightforward. Each
provider is assigned a unique prefix, from which it
slightly longer routing domain prefixes for its attached
routing domains. For GOSIP NSAPs, this means that a direct
would be assigned an AA identifier. Attached subscriber
domains would be assigned RD identifiers under the direct provider'
unique prefix. For example, assume that NIST is a subscriber
domain whose sole inter-domain link is via SURANet. If SURANet



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=

and a unique prefix for NIST

AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj

A similar scheme can be established using NSAPs allocated
DCC=840. In this case, a direct provider applies for an
identifier from ANSI, which serves the same purpose as the
identifier in GOSIP

5.3.2. Indirect

There does not appear to be a strong case for direct
providers to take their address spaces from the NSAP space of
indirect provider (e.g. backbone in today's terms). The benefit
routing data abstraction is relatively small. The number of
providers today is in the tens and an order of magnitude
would not cause an undue burden on the indirect providers. Also,
may be expected that as time goes by there will be increased
inter-connection of the direct providers, subscriber routing
directly attached to the "indirect" providers, and
links directly attached to the providers. Under these circumstances
the distinction between direct and indirect providers would
blurred

An additional factor that discourages allocation of NSAPs from
indirect provider's prefix is that the indirect providers and
attached direct providers are perceived as being independent.
providers may take their indirect