Request for Comments: 1237 Ella Gardner (Mitre)
Ross Callon (DEC)
July 1991
Guidelines for OSI NSAP Allocation in the Internet
Status of This Memo
This RFCspecifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the ``IAB Official Protocol
Standards'' for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI in the Internet, an OSI lower layers
infrastructure is required. This infrastructure comprises the
connectionless network protocol (CLNP) and supporting routing
protocols. Also required as part of this infrastructure are guidelines
for network service access point (NSAP) address assignment. This paper
provides guidelines for allocating NSAPs in the Internet.
This document provides our current best judgment for the allocation
of NSAP addresses in the Internet. This is intended to guide initial
deployment of OSI 8473 (Connectionless Network Layer Protocol) in
the Internet, as well as to solicit comments. It is expected that
these guidelines may be further refined and this document updated as a
result of experience gained during this initial deployment.
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
Contents
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]
RFC1237 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]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
1 Introduction
The Internet is moving towards a multi-protocol environment that
includes OSI. To support OSI in the Internet, an OSI lower layers
infrastructure is required. This infrastructure comprises the
connectionless network protocol (CLNP) [12] (see also RFC994 [8])
and supporting routing protocols. Also required as part of this
infrastructure are guidelines for network service access point (NSAP)
address assignment. This paper provides guidelines for allocating
NSAPs in the Internet (NSAP and NSAP address are used interchangeably
throughout this paper in referring to NSAP addresses).
The remainder of this paper is organized into five major sections and
an appendix. Section 2 defines the boundaries of the problem addressed
in this paper and Section 3 provides background information on OSI
routing and the implications for NSAPs.
Section 4 addresses the specific relationship between NSAPs and
routing, especially with regard to hierarchical routing and data
abstraction. This is followed in Section 5 with an application of
these concepts to the Internet environment. Section 6 provides
recommended guidelines for NSAP allocation in the Internet.
Appendix A contains a compendium of useful information concerning
NSAP structure and allocation authorities. The GOSIP Version 2 NSAP
structure is discussed in detail and the structure for U.S.-based DCC
(Data Country Code) NSAPs is described. Contact information for the
registration authorities for GOSIP and DCC-based NSAPs in the U.S.,
the General Services Administration (GSA) and the American National
Standards Institute (ANSI), respectively, is provided.
2 Scope
There are two aspects of interest when discussing OSI NSAP allocation
within the Internet. The first is the set of administrative require-
ments for obtaining and allocating NSAPs; the second is the technical
aspect of such assignments, having largely to do with routing, both
within a routing domain (intra-domain routing) and between routing
Colella, Gardner, & Callon [Page 4]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
domains (inter-domain routing). This paper focuses on the technical
issues.
The technical issues in NSAP allocation are mainly related to routing.
This paper assumes that CLNP will be widely deployed in the Internet,
and that the routing of CLNP traffic will normally be based on the OSI
ES-IS (end-system to intermediate system) routing protocol applicable
for point-to-point links and LANs [13] (see also RFC995 [7]) and
the emerging intra-domain IS-IS protocol [17]. Also expected is the
deployment of an inter-domain routing protocol similar to Border
Gateway Protocol (BGP) [18].
The guidelines provided in this paper are intended for immediate
deployment as CLNP is made available in the Internet. This paper
specifically does not address long-term research issues, such as
complex policy-based routing requirements.
In the current Internet many routing domains (such as corporate and
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 constraints
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. Topics
covered include:
* Arrangement of parts of the NSAP for efficient operation of the
DIS10589IS-IS routing protocol;
* Benefits of some topological information in NSAPs to reduce
routing protocol overhead;
* The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
* The recommended mapping between Internet topological entities
(i.e., backbone networks, regional networks, and site networks)
and OSI addressing and routing components;
* The recommended division of NSAP address assignment authority
among backbones, regionals (also called mid-levels), and sites;
Colella, Gardner, & Callon [Page 5]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* Background information on administrative procedures for registra-
tion of administrative authorities immediately below the national
level (GOSIP administrative authorities and ANSI organization
identifiers); and,
* Choice of the high-order portion of the NSAP in leaf routing
domains that are connected to more than one regional or backbone.
It is noted that there are other aspects of NSAP allocation, both
technical and administrative, that are not covered in this paper.
Topics not covered or mentioned only superficially include:
* Identification of specific administrative domains in the Internet;
* Policy or mechanisms for making registered information known to
third parties (such as the entity to which a specific NSAP or a
potion of the NSAP address space has been allocated);
* How a routing domain (especially a site) should organize its
internal topology of areas or allocate portions of its NSAP
address space; the relationship between topology and addresses is
discussed, but the method of deciding on a particular topology or
internal addressing plan is not; and,
* Procedures for assigning the System Identifier (ID) portion of the
NSAP.
3 Background
Some background information is provided in this section that is
helpful in understanding the issues involved in NSAP allocation. A
brief discussion of OSI routing is provided, followed by a review
of the intra-domain protocol in sufficient detail to understand the
issues involved in NSAP allocation. Finally, the specific constraints
that the intra-domain protocol places on NSAPs are listed.
Colella, Gardner, & Callon [Page 6]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
3.1 OSI Routing Standards
OSI partitions the routing problem into three parts:
* routing exchanges between end systems and intermediate systems
(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, is
available in vendor products and is planned for the next release of
Berkeley UNIX (UNIX is a trademark of AT&T). It is also cited in GOSIP
Version 2 [4], which became effective in April 1991 for all applicable
federal procurements, and mandatory beginning eighteen months later in
1992.
Intra-domain IS-IS advanced to draft international standard (DIS)
status within ISO in November, 1990 as DIS10589 [17]. It is reasonable
to expect that final text for the intra-domain IS-IS standard will be
available by mid-1991.
There are two candidate proposals which address OSI inter-domain
routing, ECMA TR/50 [3] and Border Router Protocol (BRP) [19], a
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 Model
[11 ].X3S3.3, the ANSI counterpart to WG2, has incorporated features
of TR/50 into BRP and submitted this as alternate base text at the
WG2 meeting in October, 1990. Currently, it is out for ISO Member
Body comment. The proposed protocol is referred to as the Inter-domain
Routing Protocol (IDRP) [20].
This paper examines the technical implications of NSAP assignment
under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing
are deployed to support CLNP.
Colella, Gardner, & Callon [Page 7]
RFC1237 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 is
designed to work in conjunction with CLNP and ES-IS. This section
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 common
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. The
boundaries of routing domains are defined by network management by
setting some links to be exterior, or inter-domain, links. If a link
is marked as exterior, no DIS10589 routing messages are sent on that
link.
Currently, ISO does not have a standard for inter-domain routing
(i.e., for routing between separate autonomous routing domains). In
the interim, DIS10589 uses manual configuration. An inter-domain link
is statically configured with the set of address prefixes reachable
via that link, and with the method by which they can be reached (such
as the DTE address to be dialed to reach that address, or the fact
that the DTE address should be extracted from the OSI NSAP address).
DIS10589 routing makes use of two-level hierarchical routing. A
routing domain is subdivided into areas (also known as level 1
subdomains). Level 1 ISs know the topology in their area, including
all ISs and ESs in their area. However, level 1 ISs do not know the
identity of ISs or destinations outside of their area. Level 1 ISs
forward all traffic for destinations outside of their area to a level
2 IS within their area.
Similarly, level 2 ISs know the level 2 topology and know which
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 can
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, except
to the extent that a level 2 IS may also be a level 1 IS within a
single area. Only level 2 ISs can exchange data packets or routing
information directly with external ISs located outside of their
Colella, Gardner, & Callon [Page 8]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
routing domain.
As illustrated in Figure 1, ISO addresses are subdivided into the
Initial Domain Part (IDP) and the Domain Specific Part (DSP), as spec-
ified in ISO8348/Addendum 2, the OSI network layer addressing standard
[14 ](also RFC941 [6]). The IDP is the part which is standardized by
ISO, and specifies the format and authority responsible for assigning
the rest of the address. The DSP is assigned by whatever addressing
authority is specified by the IDP (see Appendix A for more discussion
on the top level NSAP addressing authorities). The DSP is further
subdivided, by DIS10589, into a High Order Part of DSP (HO-DSP), a
system identifier (ID), and an NSAP selector (SEL). The HO-DSP may
use any format desired by the authority which is identified by the
IDP. Together, the combination of [IDP,HO-DSP] identify an area within
a routing domain and, implicitly, the routing domain containing the
area. The combination of [IDP,HO-DSP] is therefore referred to as the
area address.
_______________________________________________
!____IDP_____!_______________DSP______________!
!__AFI_!_IDI_!_____HO-DSP______!___ID___!_SEL_!
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
HO-DSP High-order DSP
ID System Identifier
SEL NSAP Selector
Figure 1: OSI Hierarchical Address Structure.
The ID field may be from one to eight octets in length, but must have
a single known length in any particular routing domain. Each router is
configured to know what length is used in its domain. The SEL field is
always one octet in length. Each router is therefore able to identify
the ID and SEL fields as a known number of trailing octets of the NSAP
address. The area address can be identified as the remainder of the
address (after truncation of the ID and SEL fields).
Usually, all nodes in an area have the same area address. However,
sometimes an area might have multiple addresses. Motivations for
allowing this are several:
Colella, Gardner, & Callon [Page 9]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* It might be desirable to change the address of an area. The most
graceful way of changing an area from having address A to having
address B is to first allow it to have both addresses A and B, and
then after all nodes in the area have been modified to recognize
both addresses, one by one the ESs can be modified to forget
address A.
* It might be desirable to merge areas A and B into one area. The
method for accomplishing this is to, one by one, add knowledge of
address B into the A partition, and similarly add knowledge of
address A into the B partition.
* It might be desirable to partition an area C into two areas, A and
B (where A might equal C, in which case this example becomes one
of removing a portion of an area). This would be accomplished by
first introducing knowledge of address A into the appropriate ESs
(those destined to become area A), and knowledge of address B into
the appropriate nodes, and then one by one removing knowledge of
address C.
Since the addressing explicitly identifies the area, it is very easy
for level 1 ISs to identify packets going to destinations outside
of their area, which need to be forwarded to level 2 ISs. Thus, in
DIS10589 the two types of ISs route as follows:
* Level 1 intermediate systems -- these nodes route based on the ID
portion of the ISO address. They route within an area. Level 1 ISs
recognize, based on the destination address in a packet, whether
the destination is within the area. If so, they route towards the
destination. If not, they route to the nearest level 2 IS.
* Level 2 intermediate systems -- these nodes route based on address
prefixes, preferring the longest matching prefix, and preferring
internal routes over external routes. They route towards areas,
without regard to the internal structure of an area; or towards
level 2 ISs on the routing domain boundary that have advertised
external address prefixes into the level 2 subdomain. A level 2 IS
may also be operating as a level 1 IS in one area.
A level 1 IS will have the area portion of its address manually
configured. It will refuse to become a neighbor with an IS whose area
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 addresses
Colella, Gardner, & Callon [Page 10]
RFC1237 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, regardless
of area address. However, if the area addresses do not overlap, the
link would be considered by both ISs to be level 2 only, and only
level 2 routing packets would flow on the link. External links (i.e.,
to other routing domains) must be between level 2 ISs in different
routing domains.
DIS10589 provides an optional partition repair function. In the
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 the
level 2 backbone become partitioned, there is no provision for use of
level 1 links to repair a level 2 partition.
In unusual cases, a single level 2 IS may lose connectivity to the
level 2 backbone. In this case the level 2 IS will indicate in its
level 1 routing packets that it is not attached, thereby allowing
level 1 ISs in the area to route traffic for outside of the area
to a different level 2 IS. Level 1 ISs therefore route traffic to
destinations outside of their area only to level 2 ISs which indicate
in their level 1 routing packets that they are attached.
An ES may autoconfigure the area portion of its address by extracting
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 standard
does not specify that the end system must autoconfigure its area
address, an end system may be pre-configured with an area address. In
this case the end system would ignore IS neighbors with non-matching
area addresses.
3.3 Requirements of DIS10589 on NSAPs
The preferred NSAP format for DIS10589 is shown in Figure 1. A number
of points should be noted from DIS10589:
Colella, Gardner, & Callon [Page 11]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* The IDP is as specified in ISO 8348/Addendum 2, the OSI network
layer addressing standard [14];
* The high-order portion of the DSP (HO-DSP) is that portion of the
DSP whose assignment, structure, and meaning are not constrained
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 matches
one of the area addresses of a system, it is in the system's area
and is routed to by level 1 routing);
* Level 2 routing acts on address prefixes, using the longest
address prefix that matches the destination address;
* Level 1 routing acts on the ID field. The ID field must be unique
within an area for ESs and level 1 ISs, and unique within the
routing domain for level 2 ISs. The ID field is assumed to be
flat;
* The one-octet NSAP Selector, SEL, determines the entity to receive
the CLNP packet within the system identified by the rest of the
NSAP (i.e., a transport entity) and is always the last octet of
the NSAP; and,
* A system shall be able to generate and forward data packets
containing addresses in any of the formats specified by ISO
8348/Addendum 2. However, within a routing domain that conforms to
DIS10589, the lower-order octets of the NSAP should be structured
as the ID and SEL fields shown in Figure 1 to take full advantage
of DIS10589 routing. End systems with addresses which do not
conform may require additional manual configuration and be subject
to inferior routing performance.
For purposes of efficient operation of the IS-IS routing protocol,
several observations may be made. First, although the IS-IS protocol
specifies an algorithm for routing within a single routing domain, the
routing algorithm must efficiently route both: (i) Packets whose final
destination is in the domain (these must, of course, be routed to the
correct destination end system in the domain); and (ii) Packets whose
final destination is outside of the domain (these must be routed to a
correct ``border'' router, from which they will exit the domain).
Colella, Gardner, & Callon [Page 12]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
For those destinations which are in the domain, level 2 routing treats
the entire area address (i.e., all of the NSAP address except the ID
and SEL fields) as if it were a flat field. Thus, the efficiency of
level 2 routing to destinations within the domain is affected only by
the number of areas in the domain, and the number of area addresses
assigned to each area (which can range from one up to a maximum of
three).
For those destinations which are outside of the domain, level 2
routing routes according to address prefixes. In this case, there
is considerable potential advantage (in terms of reducing the amount
of routing information that is required) if the number of address
prefixes required to describe any particular set of destinations can
be minimized.
4 NSAPs and Routing
When determining an administrative policy for NSAP assignment, it
is important to understand the technical consequences. The objective
behind the use of hierarchical routing is to achieve some level
of routing data abstraction, or summarization, to reduce the cpu,
memory, and transmission bandwidth consumed in support of routing.
This dictates that NSAPs be assigned according to topological
routing structures. However, administrative assignment falls along
organizational or political boundaries. These may not be congruent to
topological boundaries and therefore the requirements of the two may
collide. It is necessary to find a balance between these two needs.
Routing data abstraction occurs at the boundary between hierarchically
arranged topological routing structures. An element lower in the
hierarchy reports summary routing information to its parent(s). Within
the current OSI routing framework [16] and routing protocols, the
lowest boundary at which this can occur is the boundary between an
area and the level 2 subdomain within a DIS10589 routing domain. Data
abstraction is designed into DIS10589 at this boundary, since level 1
ISs are constrained to reporting only area addresses, and a maximum
number of three area addresses are allowed in one area (This is an
architectural constant in DIS10589. See [17], Clause 7.2.11 and Table
2 of Clause 7.5.1).
Colella, Gardner, & Callon [Page 13]
RFC1237 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 the
level 1 areas to which they are attached (and any manually configured
reachable address prefixes). Level 2 ISs compute next-hop forwarding
information to all advertised address prefixes. Level 2 routing is
determined by the longest advertised address prefix that matches the
destination address.
At routing domain boundaries, address prefix information is exchanged
(statically or dynamically) with other routing domains. If area
addresses within a routing domain are all drawn from distinct NSAP
assignment authorities (allowing no abstraction), then the boundary
prefix information consists of an enumerated list of all area
addresses.
Alternatively, should the routing domain ``own'' an address prefix
and assign area addresses based upon it, boundary routing information
can be summarized into the single prefix. This can allow substantial
data reduction and, therefore, will allow much better scaling (as
compared to the uncoordinated area addresses discussed in the previous
paragraph).
If routing domains are interconnected in a more-or-less random (non-
hierarchical) scheme, it is quite likely that no further abstraction
of routing data can occur. Since routing domains would have no defined
hierarchical relationship, administrators would not be able to assign
area addresses out of some common prefix for the purpose of data
abstraction. The result would be flat inter-domain routing; all
routing domains would need explicit knowledge of all other routing
domains that they route to. This can work well in small- and medium-
sized internets, up to a size somewhat larger than the current IP
Internet. However, this does not scale to very large internets. For
example, we expect growth in the future to an international Internet
which has tens or hundreds of thousands of routing domains in the U.S.
alone. This requires a greater degree of data abstraction beyond that
which can be achieved at the ``routing domain'' level.
In the Internet, however, it should be possible to exploit the
existing hierarchical routing structure interconnections, as discussed
in Section 5. Thus, there is the opportunity for a group of routing
domains each to be assigned an address prefix from a shorter prefix
assigned to another routing domain whose function is to interconnect
the group of routing domains. Each member of the group of routing
Colella, Gardner, & Callon [Page 14]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
domains now ``owns'' its (somewhat longer) prefix, from which it
assigns its area addresses.
The most straightforward case of this occurs when there is a set
of routing domains which are all attached only to a single regional
(or backbone) domain, and which use that regional for all external
(inter-domain) traffic. A small address prefix may be assigned to
the regional, which then assigns slightly longer prefixes (based
on the regional's prefix) to each of the routing domains that it
interconnects. This allows the regional, when informing other
routing domains of the addresses that it can reach, to abbreviate
the reachability information for a large number of routing domains
as a single prefix. This approach therefore can allow a great deal
of hierarchical abbreviation of routing information, and thereby can
greatly improve the scalability of inter-domain routing.
Clearly, this approach is recursive and can be carried through several
iterations. Routing domains at any ``level'' in the hierarchy may
use their prefix as the basis for subsequent suballocations, assuming
that the NSAP addresses remain within the overall length and structure
constraints. The GOSIP Version 2 NSAP structure, discussed later in
this section, allows for multiple levels of routing hierarchy.
At this point, we observe that the number of nodes at each lower
level of a hierarchy tends to grow exponentially. Thus the greatest
gains in data abstraction occur at the leaves and the gains drop
significantly at each higher level. Therefore, the law of diminishing
returns suggests that at some point data abstraction ceases to
produce significant benefits. Determination of the point at which data
abstraction ceases to be of benefit requires a careful consideration
of the number of routing domains that are expected to occur at each
level of the hierarchy (over a given period of time), compared to the
number of routing domains and address prefixes that can conveniently
and efficiently be handled via dynamic inter-domain routing protocols.
There is a balance that must be sought between the requirements
on NSAPs for efficient routing and the need for decentralized NSAP
administration. The NSAP structure from Version 2 of GOSIP (Figure 2)
offers 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. government
as the authority responsible for defining the DSP structure and
allocating values within it (see Appendix A for more information on
NSAP structure).
Colella, Gardner, & Callon [Page 15]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
[Note: It is not important that NSAPs be allocated from the
GOSIP Version 2 authority under 47/0005. The ANSI format under
the Data Country Code for the U.S. (DCC=840) and formats
assigned to other countries and ISO members or liaison
organizations are also expected to be used, and will work
equally well. For parts of the Internet outside of the U.S.
there may in some cases be strong reasons to prefer a local
format rather than the GOSIP format. However, GOSIP addresses
are used in most cases in the examples in this paper because:
* The DSP format has been defined and allows hierarchical
allocation; and,
* An operational registration authority for suballocation of
AA values under the GOSIP address space has already been
established at GSA.]
GOSIP Version 2 defines the DSP structure as shown (under DFI=80h) and
provides for the allocation of AA values to administrations. Thus, the
fields from the AFI to the AA, inclusive, represent a unique address
prefix assigned to an administration.
_______________
!<--__IDP_-->_!___________________________________
!AFI_!__IDI___!___________<--_DSP_-->____________!
!_47_!__0005__!DFI_!AA_!Rsvd_!_RD_!Area_!ID_!Sel_!
octets !_1__!___2____!_1__!_3_!__2__!_2__!_2___!_6_!_1__!
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
AA Administrative Authority
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 2: GOSIP Version 2 NSAP structure.
Currently, a proposal is being progressed in ANSI for an American
National Standard (ANS) for the DSP of the NSAP address space
Colella, Gardner, & Callon [Page 16]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
administered by ANSI. This will provide an identical DSP structure
to that provided by GOSIP Version 2. The ANSI format, therefore,
differs from that illustrated above only in that the IDP is based
on an ISO DCC assignment, and in that the AA will be administered
by a different organization (ANSI secretariat instead of GSA).
The technical considerations applicable to NSAP administration are
independent of whether a GOSIP Version 2 or an ANSI value is used for
the NSAP assignment.
Similarly, although other countries may make use of slightly different
NSAP formats, the principles of NSAP assignment and use are the same.
In the low-order part of the GOSIP Version 2 NSAP format, two
fields are defined in addition to those required by DIS10589. These
fields, RD and Area, are defined to allow allocation of NSAPs along
topological boundaries in support of increased data abstraction.
Administrations assign RD identifiers underneath their unique address
prefix (the reserved field is left to accommodate future growth and
to provide additional flexibility for inter-domain routing). Routing
domains allocate Area identifiers from their unique prefix. The result
is:
* AFI+IDI+DFI+AA = administration prefix,
* administration prefix(+Rsvd)+RD = routing domain prefix, and,
* routing domain prefix+Area = area address.
This provides for summarization of all area addresses within a routing
domain into one prefix. If the AA identifier is accorded topological
significance (in addition to administrative significance), an
additional level of data abstraction can be obtained, as is discussed
in the next section.
5 NSAP Administration and Routing in the Internet
Internet routing components---backbones, regionals, and sites
or campuses---are arranged hierarchically for the most part. A
natural mapping from these components to OSI routing components
is that backbones, regionals, and sites act as routing domains.
Colella, Gardner, & Callon [Page 17]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
(Alternatively, a site may choose to operate as an area within a
regional. However, in such a case the area is part of the regional's
routing domain and the discussion in Section 5.1 applies. We assume
that some, if not most, sites will prefer to operate as routing
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 and
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 is
to provide intra-domain routing services. Transit routing domains are
deployed to carry transit (i.e., inter-domain) traffic; backbones and
regionals are TRDs.
The greatest burden in transmitting and operating on routing informa-
tion is at the top of the routing hierarchy, where routing information
tends to accumulate. In the Internet, for example, regionals must man-
age the set of network numbers for all networks reachable through the
regional. Traffic destined for other networks is generally routed to
the backbone. The backbones, however, must be cognizant of the network
numbers for all attached regionals and their associated networks.
In general, the advantage of abstracting routing information at a
given level of the routing hierarchy is greater at the higher levels
of the hierarchy. There is relatively little direct benefit to the
administration that performs the abstraction, since it must maintain
routing information individually on each attached topological routing
structure.
For example, suppose that a given site is trying to decide whether
to obtain an NSAP address prefix based on an AA value from GSA
(implying that the first four octets of the address would be those
assigned out of the GOSIP space), or based on an RD value from its
regional (implying that the first seven octets of the address are
those assigned to that regional). If considering only their own
Colella, Gardner, & Callon [Page 18]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
self-interest, the site itself, and the attached regional, have
little reason to choose one approach or the other. The site must use
one prefix or another; the source of the prefix has little effect
on routing efficiency within the site. The regional must maintain
information about each attached site in order to route, regardless of
any commonality in the prefixes of the sites.
However, there is a difference when the regional distributes routing
information to backbones and other regionals. In the first case, the
regional cannot aggregate the site's address into its own prefix;
the address must be explicitly listed in routing exchanges, resulting
in an additional burden to backbones and other regionals which must
exchange and maintain this information.
In the second case, each other regional and backbone sees a single
address prefix for the regional, which encompasses the new site. This
avoids the exchange of additional routing information to identify the
new site's address prefix. Thus, the advantages primarily accrue to
other regionals and backbones which maintain routing information about
this site and regional.
One might apply a supplier/consumer model to this problem: the higher
level (e.g., a backbone) is a supplier of routing services, while
the lower level (e.g., an attached regional) is the consumer of these
services. The price charged for services is based upon the cost of
providing them. The overhead of managing a large table of addresses
for routing to an attached topological entity contributes to this
cost.
The Internet, however, is not a market economy. Rather, efficient
operation is based on cooperation. The guidelines discussed below
describe reasonable ways of managing the OSI address space that
benefit the entire community.
5.1 Administration at the Area
If areas take their area addresses from a myriad of unrelated NSAP
allocation authorities, there will be effectively no data abstraction
beyond what is built into DIS10589. For example, assume that within a
routing domain three areas take their area addresses, respectively,
out of:
Colella, Gardner, & Callon [Page 19]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
* the GOSIP Version 2 authority assigned to the Department of
Commerce, with an AA of nnn:
AFI=47, IDI=0005, DFI=80h, AA=nnn, ... ;
* the GOSIP Version 2 authority assigned to the Department of the
Interior, with an AA of mmm:
AFI=47, IDI=0005, DFI=80h, AA=mmm, ... ; and,
* the ANSI authority under the U.S. Data Country Code (DCC) (Section
A.2) for organization XYZ with ORG identifier = xxx:
AFI=39, IDI=840, DFI=dd, ORG=xxx, ....
As described in Section 3.3, from the point of view of any particular
routing domain, there is no harm in having the different areas in
the routing domain use addresses obtained from a wide variety of
administrations. For routing within the domain, the area addresses are
treated as a flat field.
However, this does have a negative effect on inter-domain routing,
particularly on those other domains which need to maintain routes to
this domain. There is no common prefix that can be used to represent
these NSAPs and therefore no summarization can take place at the
routing domain boundary. When addresses are advertised by this routing
domain to other routing domains, an enumerated list must be used
consisting of the three area addresses.
This situation is roughly analogous to the dissemination of routing
information in the TCP/IP Internet. Areas correspond roughly to
networks and area addresses to network numbers. The result of allowing
areas within a routing domain to take their NSAPs from unrelated
authorities is flat routing at the area address level. The number
of address prefixes that leaf routing domains would advertise is on
the order of the number of attached areas; the number of prefixes a
regional routing domain would advertise is approximately the number of
areas attached to the client leaf routing domains; and for a backbone
this would be summed across all attached regionals. Although this
situation is just barely acceptable in the current Internet, as the
Internet grows this will quickly become intractable. A greater degree
of hierarchical information reduction is necessary to allow continued
growth in the Internet.
Colella, Gardner, & Callon [Page 20]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
5.2 Administration at the Leaf Routing Domain
As mentioned previously, the greatest degree of data abstraction comes
at the lowest levels of the hierarchy. Providing each leaf routing
domain (that is, site) with a unique prefix results in the biggest
single increase in abstraction, with each leaf domain assigning area
addresses from its prefix. From outside the leaf routing domain, the
set of all addresses reachable in the domain can then be represented
by a single prefix.
As an example, assume NSF has been assigned the AA value of zzz
under ICD=0005. NSF then assigns a routing domain identifier to a
routing domain under its administrative authority identifier, rrr. The
resulting prefix for the routing domain is:
AFI=47, IDI=0005, DFI=80h, AA=zzz, Rsvd=0, RD=rrr.
All areas attached to this routing domain would have area addresses
comprising this prefix followed by an Area identifier. The prefix
represents the summary of reachable addresses within the routing
domain.
There is a close relationship between areas and routing domains
implicit in the fact that they operate a common routing protocol and
are under the control of a single administration. The routing domain
administration subdivides the domain into areas and structures a level
2 subdomain (i.e., a level 2 backbone) which provides connectivity
among the areas. The routing domain represents the only path between
an area and the rest of the internetwork. It is reasonable that
this relationship also extend to include a common NSAP addressing
authority. Thus, the areas within the leaf RD should take their NSAPs
from the prefix assigned to the leaf RD.
5.3 Administration at the Transit Routing Domain
Two kinds of transit routing domains are considered, backbones and
regionals. Each is discussed separately below.
Colella, Gardner, & Callon [Page 21]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
5.3.1 Regionals
It is interesting to consider whether regional routing domains should
be the common authority for assigning NSAPs from a unique prefix to
the leaf routing domains that they serve. The benefits derived from
data abstraction are less than in the case of leaf routing domains,
and the additional degree of data abstraction provided by this is
not necessary in the short term. However, in the long term the number
of routing domains in the Internet will grow to the point that it
will be infeasible to route on the basis of a flat field of routing
domains. It will therefore be essential to provide a greater degree of
information abstraction.
Regionals may assign prefixes to leaf domains, based on a single
(shorter length) address prefix assigned to the regional. For example,
given the GOSIP Version 2 address structure, an AA value may be
assigned to each regional, and routing domain values may be assigned
by the regional to each attached leaf routing domain. A similar
hierarchical address assignment based on a prefix assigned to each
regional may be used for other NSAP formats. This results in regionals
advertising to backbones a small fraction of the number of address
prefixes that would be necessary if they enumerated the individual
prefixes of the leaf routing domains. This represents a significant
savings given the expected scale of global internetworking.
Are leaf routing domains willing to accept prefixes derived from
the regional's? In the supplier/consumer model, the regional is
offering connectivity as the service, priced according to its costs
of operation. This includes the ``price'' of obtaining service from
one or more backbones. In general, backbones will want to handle as
few address prefixes as possible to keep costs low. In the Internet
environment, which does not operate as a typical marketplace, leaf
routing domains must be sensitive to the resource constraints of the
regionals and backbones. The efficiencies gained in routing clearly
warrant the adoption of NSAP administration by the regionals.
The mechanics of this scenario are straightforward. Each regional
is assigned a unique prefix, from which it allocates slightly longer
routing domain prefixes for its attached leaf routing domains.
For GOSIP NSAPs, this means that a regional would be assigned an
AA identifier. Attached leaf routing domains would be assigned RD
identifiers under the regional's unique prefix. For example, assume
Colella, Gardner, & Callon [Page 22]
RFC1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
NIST is a leaf routing domain whose sole inter-domain link is via
SURANet. If SURANet is assigned an AA identifier kkk, NIST could be
assigned an RD of jjj, resulting in a unique prefix for SURANet of:
AFI=47, IDI=0005, DFI=80h, AA=kkk
and a unique prefix for NIST of
AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj.
A similar scheme can be established using NSAPs allocated under
DCC=840. In this case, a regional applies for an ORG identifier from
ANSI, which serves the same purpose as the AA identifier in GOSIP.
The current direction in ANSI is to standardize on an NSAP structure
identical to GOSIP Version 2 (see Section A.2).
5.3.2 Backbones
There does not appear to be a strong case for regionals to take their
address spaces from the the NSAP space of a backbone. The benefit in
routing data abstraction is relatively small. The number of regionals
today is in the tens and an order of magnitude increase would not
cause an undue burden on the backbones. Also, it may be expected that
as time goes by there will be increased direct interconnection of the