RFC relevance of addresses

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

Network Working Group Richard Colella (NIST
Request for Comments: 1237 Ella Gardner (Mitre
Ross Callon (DEC
July 1991

Guidelines for OSI NSAP Allocation in the

Status of This

This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the ``IAB Official
Standards'' for the standardization state and status of this protocol
Distribution of this memo is unlimited

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

This document provides our current best judgment for the
of NSAP addresses in the Internet. This is intended to guide
deployment of OSI 8473 (Connectionless Network Layer Protocol)
the Internet, as well as to solicit comments. It is expected
these guidelines may be further refined and this document updated as
result of experience gained during this initial deployment

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

1 Introduction 4

2 Scope 4

3 Background 6

3.1 OSI Routing Standards . . . . . . . . . . . . 7

3.2 Overview of DIS10589 . . . . . . . . . . . . 8

3.3 Requirements of DIS10589 on NSAPs . . . . . . . . 11

4 NSAP and Routing 13

5 NSAP Administration and Routing in the Internet 17

5.1 Administration at the Area . . . . . . . . . . 19

5.2 Administration at the Leaf Routing Domain . . . . . 21

5.3 Administration at the Transit Routing Domain . . . . 21

5.3.1 Regionals . . . . . . . . . . . . . . 22

5.3.2 Backbones . . . . . . . . . . . . . . 23

5.4 Multi-homed Routing Domains . . . . . . . . . . 24

5.5 Private Links . . . . . . . . . . . . . . . 29

5.6 Zero-Homed Routing Domains . . . . . . . . . . 30

5.7 Transition Issues . . . . . . . . . . . . . 31

6 Recommendations 34

6.1 Recommendations Specific to U.S. Parts of the Internet . 35

Colella, Gardner, & Callon [Page 2]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

6.2 Recommendations Specific to Non-U.S. Parts of the Internet 37

6.3 Recommendations for Multi-Homed Routing Domains . . . 37

7 Security Considerations 38

8 Authors' Addresses 39

9 Acknowledgments 39

A Administration of NSAPs 40

A.1 GOSIP Version 2 NSAPs . . . . . . . . . . . . 41

A.1.1 Application for Administrative Authority Identifiers 42

A.1.2 Guidelines for NSAP Assignment . . . . . . . 44

A.2 Data Country Code NSAPs . . . . . . . . . . . 45

A.2.1 Application for Numeric Organization Name . . . 46

A.3 Summary of Administrative Requirements . . . . . . 46

Colella, Gardner, & Callon [Page 3]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

1

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

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

Section 4 addresses the specific relationship between NSAPs
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 allocation in the Internet

Appendix A 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

2

There are two aspects of interest when discussing OSI NSAP
within the Internet. The first is the set of administrative require
ments for obtaining and allocating NSAPs; the second is the
aspect of such assignments, having largely to do with routing,
within a routing domain (intra-domain routing) and between

Colella, Gardner, & Callon [Page 4]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

domains (inter-domain routing). This paper focuses on the
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
ES-IS (end-system to intermediate system) routing protocol
for point-to-point links and LANs [13] (see also RFC 995 [7])
the emerging intra-domain IS-IS protocol [17]. Also expected is
deployment of an inter-domain routing protocol similar to
Gateway Protocol (BGP) [18].

The guidelines provided in this paper are intended for
deployment as CLNP is made available in the Internet. This
specifically does not address long-term research issues, such
complex policy-based routing requirements

In the current Internet many routing domains (such as corporate
campus networks) attach to transit networks (such as NSFNET regionals
in only one or a small number of carefully controlled access points
Addressing solutions which require substantial changes or
on the current topology are not considered

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

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

* Benefits of some topological information in NSAPs to
routing protocol overhead

* The anticipated need for additional levels of hierarchy
Internet addressing to support network growth

* The recommended mapping between Internet topological
(i.e., backbone networks, regional networks, and site networks
and OSI addressing and routing components

* The recommended division of NSAP address assignment
among backbones, regionals (also called mid-levels), and sites

Colella, Gardner, & Callon [Page 5]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

* Background information on administrative procedures for registra
tion of administrative authorities immediately below the
level (GOSIP administrative authorities and ANSI
identifiers); and

* Choice of the high-order portion of the NSAP in leaf
domains that are connected to more than one regional or backbone

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 the Internet

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

* 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 addresses
discussed, but the method of deciding on a particular topology
internal addressing plan is not; and

* Procedures for assigning the System Identifier (ID) portion of
NSAP

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
of the intra-domain protocol in sufficient detail to understand
issues involved in NSAP allocation. Finally, the specific
that the intra-domain protocol places on NSAPs are listed

Colella, Gardner, & Callon [Page 6]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

3.1 OSI Routing

OSI partitions the routing problem into three parts

* routing exchanges between end systems and intermediate
(ES-IS),

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

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

ES-IS, international standard ISO9542 [13] approved in 1987,
available in vendor products and is planned for the next release
Berkeley UNIX (UNIX is a trademark of AT&T). It is also cited in
Version 2 [4], which became effective in April 1991 for all
federal procurements, and mandatory beginning eighteen months later
1992.

Intra-domain IS-IS advanced to draft international standard (DIS
status within ISO in November, 1990 as DIS10589 [17]. It is
to expect that final text for the intra-domain IS-IS standard will
available by mid-1991.

There are two candidate proposals which address OSI inter-
routing, ECMA TR/50 [3] and Border Router Protocol (BRP) [19],
direct derivative of the IETF Border Gateway Protocol [18]. ECMA TR/50
has been proposed as base text in the ISO/IEC JTC1 SC6/WG2 committee
which is responsible for the Network layer of the ISO Reference
[11 ].X3S3.3, the ANSI counterpart to WG2, has incorporated
of TR/50 into BRP and submitted this as alternate base text at
WG2 meeting in October, 1990. Currently, it is out for ISO
Body comment. The proposed protocol is referred to as the Inter-
Routing Protocol (IDRP) [20].

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, Gardner, & Callon [Page 7]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

3.2 Overview of DIS10589

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

In DIS10589, the internetwork is partitioned into routing domains
A routing domain is a collection of ESs and ISs that operate
routing protocols and are under the control of a single administra
tion. Typically, a routing domain may consist of a corporate network
a university campus network, a regional network, or a similar contigu
ous network under control of a single administrative organization.
boundaries of routing domains are defined by network management
setting some links to be exterior, or inter-domain, links. If a
is marked as exterior, no DIS10589 routing messages are sent on
link

Currently, ISO does not have a standard for inter-domain
(i.e., for routing between separate autonomous routing domains).
the interim, DIS10589 uses manual configuration. An inter-domain
is statically configured with the set of address prefixes
via that link, and with the method by which they can be reached (
as the DTE address to be dialed to reach that address, or the
that the DTE address should be extracted from the OSI NSAP address).

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

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

Colella, Gardner, & Callon [Page 8]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

routing domain

As illustrated in Figure 1, ISO addresses are subdivided into
Initial Domain Part (IDP) and the Domain Specific Part (DSP), as spec
ified in ISO8348/Addendum 2, the OSI network layer addressing
[14 ](also RFC 941 [6]). The IDP is the part which is standardized
ISO, and specifies the format and authority responsible for
the rest of the address. The DSP is assigned by whatever
authority is specified by the IDP (see Appendix A for more
on the top level NSAP addressing authorities). The DSP is
subdivided, by DIS10589, into a High Order Part of DSP (HO-DSP),
system identifier (ID), and an NSAP selector (SEL). The HO-DSP
use any format desired by the authority which is identified by
IDP. Together, the combination of [IDP,HO-DSP] identify an area
a routing domain and, implicitly, the routing domain containing
area. The combination of [IDP,HO-DSP] is therefore referred to as
area address

_______________________________________________
!____IDP_____!_______________DSP______________!
!__AFI_!_IDI_!_____HO-DSP______!___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 router
configured to know what length is used in its domain. The SEL field
always one octet in length. Each router is therefore able to
the ID and SEL fields as a known number of trailing octets of the
address. The area address can be identified as the remainder of
address (after truncation of the ID and SEL fields).

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, Gardner, & Callon [Page 9]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

* It might be desirable to change the address of an area. The
graceful way of changing an area from having address A to
address B is to first allow it to have both addresses A and B,
then after all nodes in the area have been modified to
both addresses, one by one the ESs can be modified to
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 appropriate
(those destined to become area A), and knowledge of address B
the appropriate nodes, and then one by one removing knowledge
address C

Since the addressing explicitly identifies the area, it is very
for level 1 ISs to identify packets going to destinations
of their area, which need to be forwarded to level 2 ISs. Thus,
DIS10589 the two types of ISs route as follows

* Level 1 intermediate systems -- these nodes route based on the
portion of the ISO address. They route within an area. Level 1
recognize, based on the destination address in a packet,
the destination is within the area. If so, they route towards
destination. If not, they route to the nearest level 2 IS

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

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

Colella, Gardner, & Callon [Page 10]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

B and D, then the level 1 IS will accept the other IS as a level 1
neighbor

A level 2 IS will accept another level 2 IS as a neighbor,
of area address. However, if the area addresses do not overlap,
link would be considered by both ISs to be level 2 only, and
level 2 routing packets would flow on the link. External links (i.e.,
to other routing domains) must be between level 2 ISs in
routing domains

DIS10589 provides an optional partition repair function. In
unlikely case that a level 1 area becomes partitioned, this function
if implemented, allows the partition to be repaired via use of level 2
routes

DIS10589 requires that the set of level 2 ISs be connected. Should
level 2 backbone become partitioned, there is no provision for use
level 1 links to repair a level 2 partition

In unusual cases, a single level 2 IS may lose connectivity to
level 2 backbone. In this case the level 2 IS will indicate in
level 1 routing packets that it is not attached, thereby
level 1 ISs in the area to route traffic for outside of the
to a different level 2 IS. Level 1 ISs therefore route traffic
destinations outside of their area only to level 2 ISs which
in their level 1 routing packets that they are attached

An ES may autoconfigure the area portion of its address by
the area portion of a neighboring IS's address. If this is the case
then an ES will always accept an IS as a neighbor. Since the
does not specify that the end system must autoconfigure its
address, an end system may be pre-configured with an area address.
this case the end system would ignore IS neighbors with non-
area addresses

3.3 Requirements of DIS10589 on

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

Colella, Gardner, & Callon [Page 11]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

* The IDP is as specified in ISO 8348/Addendum 2, the OSI
layer addressing standard [14];

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

* The concatenation of the IDP and the HO-DSP, the area address
must be globally unique (if the area address of an NSAP
one of the area addresses of a system, it is in the system's
and is routed to by level 1 routing);

* Level 2 routing acts on address prefixes, using the
address 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 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
the NSAP; and

* A system shall be able to generate and forward data
containing addresses in any of the formats specified by
8348/Addendum 2. However, within a routing domain that conforms
DIS10589, the lower-order octets of the NSAP should be
as the ID and SEL fields shown in Figure 1 to take full
of DIS10589 routing. End systems with addresses which do
conform may require additional manual configuration and be
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
specifies an algorithm for routing within a single routing domain,
routing algorithm must efficiently route both: (i) Packets whose
destination is in the domain (these must, of course, be routed to
correct destination end system in the domain); and (ii) Packets
final destination is outside of the domain (these must be routed to
correct ``border'' router, from which they will exit the domain).

Colella, Gardner, & Callon [Page 12]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

For those destinations which are in the domain, level 2 routing
the entire area address (i.e., all of the NSAP address except the
and SEL fields) as if it were a flat field. Thus, the efficiency
level 2 routing to destinations within the domain is affected only
the number of areas in the domain, and the number of area
assigned to each area (which can range from one up to a maximum
three).

For those destinations which are outside of the domain, level 2
routing routes according to address prefixes. In this case,
is considerable potential advantage (in terms of reducing the
of routing information that is required) if the number of
prefixes required to describe any particular set of destinations
be minimized

4 NSAPs and

When determining an administrative policy for NSAP assignment,
is important to understand the technical consequences. The
behind the use of hierarchical routing is to achieve some
of routing data abstraction, or summarization, to reduce the cpu
memory, and transmission bandwidth consumed in support of routing
This dictates that NSAPs be assigned according to
routing structures. However, administrative assignment falls
organizational or political boundaries. These may not be congruent
topological boundaries and therefore the requirements of the two
collide. It is necessary to find a balance between these two needs

Routing data abstraction occurs at the boundary between
arranged topological routing structures. An element lower in
hierarchy reports summary routing information to its parent(s).
the current OSI routing framework [16] and routing protocols,
lowest boundary at which this can occur is the boundary between
area and the level 2 subdomain within a DIS10589 routing domain.
abstraction is designed into DIS10589 at this boundary, since level 1
ISs are constrained to reporting only area addresses, and a
number of three area addresses are allowed in one area (This is
architectural constant in DIS10589. See [17], Clause 7.2.11 and
2 of Clause 7.5.1).

Colella, Gardner, & Callon [Page 13]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

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

At routing domain boundaries, address prefix information is
(statically or dynamically) with other routing domains. If
addresses within a routing domain are all drawn from distinct
assignment authorities (allowing no abstraction), then the
prefix information consists of an enumerated list of all
addresses

Alternatively, should the routing domain ``own'' an address
and assign area addresses based upon it, boundary routing
can 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 the
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 no
hierarchical relationship, administrators would not be able to
area addresses out of some common prefix for the purpose of
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 the U.S
alone. This requires a greater degree of data abstraction beyond
which can be achieved at the ``routing domain'' level

In the Internet, however, it should be possible to exploit
existing hierarchical routing structure interconnections, as
in Section 5. Thus, there is the opportunity for a group of
domains each to be assigned an address prefix from a shorter
assigned to another routing domain whose function is to
the group of routing domains. Each member of the group of

Colella, Gardner, & Callon [Page 14]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

domains now ``owns'' its (somewhat longer) prefix, from which
assigns its area addresses

The most straightforward case of this occurs when there is a
of routing domains which are all attached only to a single
(or backbone) domain, and which use that regional for all
(inter-domain) traffic. A small address prefix may be assigned
the regional, which then assigns slightly longer prefixes (
on the regional's prefix) to each of the routing domains that
interconnects. This allows the regional, when informing
routing domains of the addresses that it can reach, to
the reachability information for a large number of routing
as a single prefix. This approach therefore can allow a great
of hierarchical abbreviation of routing information, and thereby
greatly improve the scalability of inter-domain routing

Clearly, this approach is recursive and can be carried through
iterations. Routing domains at any ``level'' in the hierarchy
use their prefix as the basis for subsequent suballocations,
that the NSAP addresses remain within the overall length and
constraints. The GOSIP Version 2 NSAP structure, discussed later
this section, allows for multiple levels of routing hierarchy

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 of
returns suggests that at some point data abstraction ceases
produce significant benefits. Determination of the point at which
abstraction ceases to be of benefit requires a careful
of the number of routing domains that are expected to occur at
level of the hierarchy (over a given period of time), compared to
number of routing domains and address prefixes that can
and efficiently be handled via dynamic inter-domain routing protocols

There is a balance that must be sought between the
on NSAPs for efficient routing and the need for decentralized
administration. The NSAP structure from Version 2 of GOSIP (Figure 2)
offers an example of how these two needs might be met. The AFI
IDI, DFI, and AA fields provide for administrative decentralization
The AFI/IDI pair of values 47/0005 identify the U.S.
as the authority responsible for defining the DSP structure
allocating values within it (see Appendix A for more information
NSAP structure).

Colella, Gardner, & Callon [Page 15]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

[Note: It is not important that NSAPs be allocated from
GOSIP Version 2 authority under 47/0005. The ANSI format
the Data Country Code for the U.S. (DCC=840) and
assigned to other countries and ISO members or
organizations are also expected to be used, and will
equally well. For parts of the Internet outside of the U.S
there may in some cases be strong reasons to prefer a
format rather than the GOSIP format. However, GOSIP
are used in most cases in the examples in this paper because

* The DSP format has been defined and allows
allocation; and

* An operational registration authority for suballocation
AA values under the GOSIP address space has already
established at GSA.]

GOSIP Version 2 defines the DSP structure as shown (under DFI=80h)
provides for the allocation of AA values to administrations. Thus,
fields from the AFI to the AA, inclusive, represent a unique
prefix assigned to an administration

_______________
!<--__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

Currently, a proposal is being progressed in ANSI for an
National Standard (ANS) for the DSP of the NSAP address

Colella, Gardner, & Callon [Page 16]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

administered by ANSI. This will provide an identical DSP
to that provided by GOSIP Version 2. The ANSI format, therefore
differs from that illustrated above only in that the IDP is
on an ISO DCC assignment, and in that the AA will be
by a different organization (ANSI secretariat instead of GSA).
The technical considerations applicable to NSAP administration
independent of whether a GOSIP Version 2 or an ANSI value is used
the NSAP assignment

Similarly, although other countries may make use of slightly
NSAP formats, the principles of NSAP assignment and use are the same

In the low-order part of the GOSIP Version 2 NSAP format,
fields are defined in addition to those required by DIS10589.
fields, RD and Area, are defined to allow allocation of NSAPs
topological boundaries in support of increased data abstraction
Administrations assign RD identifiers underneath their unique
prefix (the reserved field is left to accommodate future growth
to provide additional flexibility for inter-domain routing).
domains allocate Area identifiers from their unique prefix. The
is

* AFI+IDI+DFI+AA = administration prefix

* administration prefix(+Rsvd)+RD = routing domain prefix, and

* routing domain prefix+Area = area address

This provides for summarization of all area addresses within a
domain into one prefix. If the AA identifier is accorded
significance (in addition to administrative significance),
additional level of data abstraction can be obtained, as is
in the next section

5 NSAP Administration and Routing in the

Internet routing components---backbones, regionals, and
or campuses---are arranged hierarchically for the most part.
natural mapping from these components to OSI routing
is that backbones, regionals, and sites act as routing domains

Colella, Gardner, & Callon [Page 17]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

(Alternatively, a site may choose to operate as an area within
regional. However, in such a case the area is part of the regional'
routing domain and the discussion in Section 5.1 applies. We
that some, if not most, sites will prefer to operate as
domains. By operating as a routing domain, a site operates a level 2
subdomain as well as one or more level 1 areas.)

Given such a mapping, where should address administration and alloca
tion be performed to satisfy both administrative decentralization
data abstraction? Three possibilities are considered

1. at the area

2. at the leaf routing domain, and

3. at the transit routing domain (TRD).

Leaf routing domains correspond to sites, where the primary purpose
to provide intra-domain routing services. Transit routing domains
deployed to carry transit (i.e., inter-domain) traffic; backbones
regionals are TRDs

The greatest burden in transmitting and operating on routing informa
tion is at the top of the routing hierarchy, where routing
tends to accumulate. In the Internet, for example, regionals must man
age the set of network numbers for all networks reachable through
regional. Traffic destined for other networks is generally routed
the backbone. The backbones, however, must be cognizant of the
numbers for all attached regionals and their associated networks

In general, the advantage of abstracting routing information at
given level of the routing hierarchy is greater at the higher
of the hierarchy. There is relatively little direct benefit to
administration that performs the abstraction, since it must
routing information individually on each attached topological
structure

For example, suppose that a given site is trying to decide
to obtain an NSAP address prefix based on an AA value from
(implying that the first four octets of the address would be
assigned out of the GOSIP space), or based on an RD value from
regional (implying that the first seven octets of the address
those assigned to that regional). If considering only their

Colella, Gardner, & Callon [Page 18]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

self-interest, the site itself, and the attached regional,
little reason to choose one approach or the other. The site must
one prefix or another; the source of the prefix has little
on routing efficiency within the site. The regional must
information about each attached site in order to route, regardless
any commonality in the prefixes of the sites

However, there is a difference when the regional distributes
information to backbones and other regionals. In the first case,
regional cannot aggregate the site's address into its own prefix
the address must be explicitly listed in routing exchanges,
in an additional burden to backbones and other regionals which
exchange and maintain this information

In the second case, each other regional and backbone sees a
address prefix for the regional, which encompasses the new site.
avoids the exchange of additional routing information to identify
new site's address prefix. Thus, the advantages primarily accrue
other regionals and backbones which maintain routing information
this site and regional

One might apply a supplier/consumer model to this problem: the
level (e.g., a backbone) is a supplier of routing services,
the lower level (e.g., an attached regional) is the consumer of
services. The price charged for services is based upon the cost
providing them. The overhead of managing a large table of
for routing to an attached topological entity contributes to
cost

The Internet, however, is not a market economy. Rather,
operation is based on cooperation. The guidelines discussed
describe reasonable ways of managing the OSI address space
benefit the entire community

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 DIS10589. For example, assume that within
routing domain three areas take their area addresses, respectively
out of

Colella, Gardner, & Callon [Page 19]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

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

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

* the GOSIP Version 2 authority assigned to the Department of
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) (
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
the routing domain use addresses obtained from a wide variety
administrations. For routing within the domain, the area addresses
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 this
domain to other routing domains, an enumerated list must be
consisting of the three area addresses

This situation is roughly analogous to the dissemination of
information in the TCP/IP Internet. Areas correspond roughly
networks and area addresses to network numbers. The result of
areas within a routing domain to take their NSAPs from
authorities is flat routing at the area address level. The
of address prefixes that leaf routing domains would advertise is
the order of the number of attached areas; the number of prefixes
regional routing domain would advertise is approximately the number
areas attached to the client leaf routing domains; and for a
this would be summed across all attached regionals. Although
situation is just barely acceptable in the current Internet, as
Internet grows this will quickly become intractable. A greater
of hierarchical information reduction is necessary to allow
growth in the Internet

Colella, Gardner, & Callon [Page 20]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

5.2 Administration at the Leaf Routing

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

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

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

All areas attached to 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 a
2 subdomain (i.e., a level 2 backbone) which provides
among the areas. The routing domain represents the only path
an area and the rest of the internetwork. It is reasonable
this relationship also extend to include a common NSAP
authority. Thus, the areas within the leaf RD should take their
from the prefix assigned to the leaf RD

5.3 Administration at the Transit Routing

Two kinds of transit routing domains are considered, backbones
regionals. Each is discussed separately below

Colella, Gardner, & Callon [Page 21]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

5.3.1

It is interesting to consider whether regional routing domains
be the common authority for assigning NSAPs from a unique prefix
the leaf routing domains that they serve. The benefits derived
data abstraction are less than in the case of leaf routing domains
and the additional degree of data abstraction provided by this
not necessary in the short term. However, in the long term the
of routing domains in the Internet will grow to the point that
will be infeasible to route on the basis of a flat field of
domains. It will therefore be essential to provide a greater degree
information abstraction

Regionals may assign prefixes to leaf domains, based on a
(shorter length) address prefix assigned to the regional. For example
given the GOSIP Version 2 address structure, an AA value may
assigned to each regional, and routing domain values may be
by the regional to each attached leaf routing domain. A
hierarchical address assignment based on a prefix assigned to
regional may be used for other NSAP formats. This results in
advertising to backbones a small fraction of the number of
prefixes that would be necessary if they enumerated the
prefixes of the leaf routing domains. This represents a
savings given the expected scale of global internetworking

Are leaf routing domains willing to accept prefixes derived
the regional's? In the supplier/consumer model, the regional
offering connectivity as the service, priced according to its
of operation. This includes the ``price'' of obtaining service
one or more backbones. In general, backbones will want to handle
few address prefixes as possible to keep costs low. In the
environment, which does not operate as a typical marketplace,
routing domains must be sensitive to the resource constraints of
regionals and backbones. The efficiencies gained in routing
warrant the adoption of NSAP administration by the regionals

The mechanics of this scenario are straightforward. Each
is assigned a unique prefix, from which it allocates slightly
routing domain prefixes for its attached leaf routing domains
For GOSIP NSAPs, this means that a regional would be assigned
AA identifier. Attached leaf routing domains would be assigned
identifiers under the regional's unique prefix. For example,

Colella, Gardner, & Callon [Page 22]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

NIST is a leaf routing domain whose sole inter-domain link is
SURANet. If SURANet is assigned an AA identifier kkk, NIST could
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 regional applies for an ORG identifier
ANSI, which serves the same purpose as the AA identifier in GOSIP
The current direction in ANSI is to standardize on an NSAP
identical to GOSIP Version 2 (see Section A.2).

5.3.2

There does not appear to be a strong case for regionals to take
address spaces from the the NSAP space of a backbone. The benefit
routing data abstraction is relatively small. The number of
today is in the tens and an order of magnitude increase would
cause an undue burden on the backbones. Also, it may be expected
as time goes by there will be increased direct interconnection of
regionals, leaf routing domains directly attached to the backbones
and international links directly attached to the regionals.
these circumstances, the distinction between regionals and
may become blurred

An additional factor that discourages allocation of NSAPs from
backbone prefix is that the backbones and their attached regionals
perceived as being independent. Regionals may take their long-
service from one or more backbones, or may switch backbones
a more cost-effective service be provided elsewhere (essentially
backbones can be thought of the same way as long-distance
carriers). Having NSAPs derived from the backbone is inconsistent
the nature of the relationship

Colella, Gardner, & Callon [Page 23]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

5.4 Multi-homed Routing

The discussions in Section 5.3 suggest methods for allocating
addresses based on regional or backbone connectivity. This allows
great deal of information reduction to be achieved for those
domains which are attached to a single TRD. In particular,
routing domains may select their NSAP addresses from a space
to them by the regional. This allows the regional, when announcing
addresses that it can reach to other regionals and backbones, to
a single address prefix to describe a large number of NSAP
corresponding to multiple routing domains

However, there are additional considerations for routing
which are attached to multiple regionals and backbones. Such ``multi
homed'' routing domains may, for example, consist of single-
campuses and companies which are attached to multiple backbones,
organizations which are attached to different regionals at
locations in the same country, or multi-national organizations
are attached to backbones in a variety of countries worldwide.
are a number of possible ways to deal with these multi-homed
domains

One possible solution is to assign addresses to each multi-
organization independently from the regionals and backbones to
it is attached. This allows each multi-homed organization to base
NSAP assignments on a single prefix, and to thereby summarize the
of all NSAPs reachable within that organization via a single prefix
The disadvantage of this approach is that since the NSAP
for that organization has no relationship to the addresses of
particular TRD, the TRDs to which this organization is attached
need to advertise the prefix for this organization to other
and backbones. Other regionals and backbones (potentially worldwide
will need to maintain an explicit entry for that organization in
routing tables

For example, suppose that a very large U.S.-wide company ``
Big International Incorporated'' (MBII) has a fully
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.
addresses. However, within the U.S., every backbone and
will need to maintain a separate address entry for MBII. If

Colella, Gardner, & Callon [Page 24]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

is in fact an international corporation, then it may be
for every backbone worldwide to maintain a separate entry for
(including backbones to which MBII is not attached). Clearly
may be acceptable if there are a small number of such multi-
routing domains, but would place an unacceptable load on
within backbones if all organizations were to choose such
assignments. This solution may not scale to internets where there
many hundreds of thousands of multi-homed organizations

A second possible approach would be for multi-homed organizations
be assigned a separate NSAP space for each connection to a TRD,
to assign a single address prefix to each area within its
domain(s) based on the closest interconnection point. For example,
MBII had connections to two regionals in the U.S. (one east coast,
one west coast), as well as three connections to national
in Europe, and one in the far east, then MBII may make use of
different address prefixes. Each area within MBII would be assigned
single address prefix based on the nearest connection

For purposes of external routing of traffic from outside MBII to
destination inside of MBII, this approach works similarly to
MBII as six separate organizations. For purposes of internal routing
or for routing traffic from inside of MBII to a destination outside
MBII, this approach works the same as the first solution

If we assume that incoming traffic (coming from outside of MBII,
a destination within MBII) is always to enter via the nearest point
the destination, then each TRD which has a connection to MBII
to announce to other TRDs the ability to reach only those parts
MBII whose address is taken from its own address space. This
that no additional routing information needs to be exchanged
TRDs, resulting in a smaller load on the inter-domain routing
maintained by TRDs when compared to the first solution. This
therefore scales better to extremely large internets containing
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
solution, each TRD, in announcing the ability to reach MBII,
that it is able to reach all of the NSAPs within MBII. With the
solution, each TRD announces that it can reach all of the NSAPs
on its own address prefix, which only includes some of the
within MBII. If the connection between MBII and one particular

Colella, Gardner, & Callon [Page 25]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

were severed, then the NSAPs within MBII with addresses based on
TRD would become unreachable via inter-domain routing. The
of this problem can be reduced somewhat by maintenance of
information within routing tables, but this reduces the
advantage of the second approach

The second solution also requires that when external
changes, internal addresses also change

Also note that this and the previous approach will tend to
packets to take different routes. With the first approach,
from outside of MBII destined for within MBII will tend to enter
the point which is closest to the source (which will therefore tend
maximize the load on the networks internal to MBII). With the
solution, packets from outside destined for within MBII will tend
enter via the point which is closest to the destination (which
tend to minimize the load on the networks within MBII, and
the load on the TRDs).

These solutions also have different effects on policies. For example
suppose that country ``X'' has a law that traffic from a
within country X to a destination within country X must at
times stay entirely within the country. With the first solution,
is not possible to determine from the destination address
or not the destination is within the country. With the
solution, a separate address may be assigned to those NSAPs which
within country X, thereby allowing routing policies to be followed
Similarly, suppose that ``Little Small Company'' (LSC) has a
that its packets may never be sent to a destination that is
MBII. With either solution, the routers within LSC may be
to discard any traffic that has a destination within MBII's
space. However, with the first solution this requires one entry
with the second it requires many entries and may be impossible as
practical matter

There are other possible solutions as well. A third approach is
assign each multi-homed organization a single address prefix, based
one of its connections to a TRD. Other TRDs to which the multi-
organization are attached maintain a routing table entry for
organization, but are extremely selective in terms of which
TRDs are told of this route. This approach will produce a
``default'' routing entry which all TRDs will know how to

Colella, Gardner, & Callon [Page 26]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

(since presumably all TRDs will maintain routes to each other),
providing more direct routing in some cases

There is at least one situation in which this third approach
particularly appropriate. Suppose that a special interest group
organizations have deployed their own backbone. For example,
suppose that the U.S. National Widget Manufacturers and
have set up a U.S.-wide backbone, which is used by
who manufacture widgets, and certain universities which are
for their widget research efforts. We can expect that the
organizations which are in the widget group will run their
networks as separate routing domains, and most of them will
be attached to other TRDs (since most of the organizations
in widget manufacture and research will also be involved in
activities). We can therefore expect that many or most of
organizations in the widget group are dual-homed, with one
for widget-associated communications and the other attachment
other types of communications. Let's also assume that the total
of organizations involved in the widget group is small enough
it is reasonable to maintain a routing table containing one
per organization, but that they are distributed throughout a
internet with many millions of (mostly not widget-associated)
domains

With the third approach, each multi-homed organization in the
group would make use of an address assignment based on its
attachment(s) to TRDs (the attachments not associated with the
group). The widget backbone would need to maintain routes to
routing domains associated with the various member organizations
Similarly, all members of the widget group would need to maintain
table of routes to the other members via the widget backbone. However
since the widget backbone does not inform other general worldwide
of what addresses it can reach (since the backbone is not
for use by other outside organizations), the relatively large
of routing prefixes needs to be maintained only in a limited
of places. The addresses assigned to the various organizations
are members of the widget group would provide a ``default route''
each members other attachments to TRDs, while allowing
within the widget group to use the preferred path

A fourth solution involves assignment of a particular address
for routing domains which are attached to precisely two (or more
specific routing domains. For example, suppose that there are
regionals ``SouthNorthNet'' and ``NorthSouthNet'' which have a

Colella, Gardner, & Callon [Page 27]

RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991

large number of customers in common (i.e., there are a large
of routing domains which are attached to both). Rather than
two address prefixes (such as two AA values assigned under the
address space) these organizations could obtain three prefixes.
routing domains which are attached to NorthSouthNet but not
to SouthNorthNet obtain an address assignment based on one of
prefixes. Those routing domains which are attached to
but not to NorthSouthNet would obtain an address based on the
prefix. Finally, those routing domains which are multi-homed to
of these networks would obtain an address based on the third prefix
Each of these two TRDs would then advertise two prefixes to
TRDs, one prefix for leaf routing domains attached to it only, and
prefix for leaf routing domains attached to both

This fourth solution is likely to be important when use of public
networks becomes more common. In