Further, in order to allow aggregation of NSAPs at national
boundaries into as few prefixes as possible, we further recommend
that NSAPs allocated to routing domains should be assigned based on
each routing domain's connectivity to a national Internet backbone.
6.4. Recommendations for Multi-Homed Routing Domains
Some routing domains will be attached to multiple providers within
the same country, or to providers within multiple countries. We
refer to these as "multi-homed" routing domains. Clearly the strict
hierarchical model discussed above does not neatly handle such
routing domains.
There are several possible ways that these multi-homed routing
domains may be handled. Each of these methods vary with respect to
the amount of information that must be maintained for inter-domain
routing and also with respect to the inter-domain routes. In
addition, the organization that will bear the brunt of this cost
varies with the possible solutions. For example, the solutions vary
with respect to:
* resources used within routers within the providers;
* administrative cost on provider personnel; and,
* difficulty of configuration of policy-based inter-domain
routing information within subscriber routing domains.
Also, the solution used may affect the actual routes which packets
follow, and may effect the availability of backup routes when the
primary route fails.
For these reasons it is not possible to mandate a single solution for
all situations. Rather, economic considerations will require a
variety of solutions for different subscriber routing domains and
providers.
6.5. Recommendations for RDI and RDCI assignment
While RDIs and RDCIs need not be related to the set of addresses
within the domains (confederations) they depict, for the sake of
simplicity we recommend that RDIs and RDCIs be assigned based on the
NSAP prefixes assigned to domains and confederations.
A subscriber RD should use the NSAP prefix assigned to it as its RDI.
A multihomed RD should use one of the NSAP prefixes assigned to it as
its RDI. If a service provider forms a Routing Domain Confederation
with some of its subscribers and the subscribers take their addresses
out of the provider, then the NSAP prefix assigned to the provider
should be used as the RDCI of the confederation. In this case the
provider may use a longer NSAP prefix for its own RDIs. In all other
cases a provider should use the address prefix that it uses for
assigning addresses to systems within the provider as its RDI.
7. Security Considerations
Security issues are not discussed in this memo (except for the
discussion of IS-IS authentication in Section 3.2).
8. Authors' Addresses
Richard P. Colella
National Institute of Standards & Technology
Building 225/Room B217
Gaithersburg, MD 20899
Phone: (301) 975-3627
EMail: colella@nist.gov
Ross Callon
c/o Wellfleet Communications, Inc
2 Federal Street
Billerica, MA 01821
Phone: (508) 436-3936
EMail: callon@wellfleet.com
Ella P. Gardner
The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102-3481
Phone: (703) 883-5826
EMail: epg@gateway.mitre.org
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.com
9. Acknowledgments
The authors would like to thank the members of the IETF OSI-NSAP
Working Group and of RARE WG4 for the helpful suggestions made during
the writing of this paper. We would also like to thank Radia Perlman
of Novell, Marcel Wiget of SWITCH, and Cathy Wittbrodt of BARRnet for
their ideas and help.
10. References
[1] ANSI, "American National Standard for the Structure and Semantics
of the Domain-Specific Part (DSP) of the OSI Network Service
Access Point (NSAP) Address", American National Standard X3.216-
1992.
[2] Boland, T., "Government Open Systems Interconnection Profile
Users' Guide Version 2 [DRAFT]", NIST Special Publication,
National Institute of Standards and Technology, Computer Systems
Laboratory, Gaithersburg, MD, June 1991.
[3] GOSIP Advanced Requirements Group, "Government Open Systems
Interconnection Profile (GOSIP) Version 2", Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[4] Hemrick, C., "The OSI Network Layer Addressing Scheme, Its
Implications, and Considerations for Implementation", NTIA Report
85186, U.S. Department of Commerce, National Telecommunications
and Information Administration, 1985.
[5] ISO, "Addendum to the Network Service Definition Covering Network
Layer Addressing," RFC941, ISO, April 1985.
[6] ISO/IEC, "Codes for the Representation of Names of Countries",
International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
[7] ISO/IEC, "Data Interchange - Structures for the Identification of
Organization", International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[8] ISO/IEC, "Information Processing Systems - Open Systems
Interconnection -- Basic Reference Model", International Standard
7498, ISO/IEC JTC 1, Switzerland, 1984.
[9] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
Service", International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[10] ISO/IEC, "End System to Intermediate System Routing Exchange
Protocol for use in Conjunction with the Protocol for the
Provision of the Connectionless-mode Network Service",
International Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
[11] ISO/IEC, "Information Processing Systems -- Data Communications
-- Network Service Definition", International Standard 8348,
1992.
[12] ISO/IEC, "Information Processing Systems - OSI Reference Model -
Part3: Naming and Addressing", Draft International Standard
7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
[13] ISO/IEC, "Information Technology - Telecommunications and
Information Exchange Between Systems - OSI Routeing Framework",
Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
[14] ISO/IEC, "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-Mode Network Service
(ISO 8473)", International Standard ISO/IEC 10589, 1992.
[15] Loughheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)" RFC1267, cisco Systems, T.J. Watson Research Center,
IBM Corp., October 1991.
[16] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
Information among Intermediate Systems to support Forwarding of
ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1,
Switzerland 1993.
[17] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
Proposal for Internet Addressing and Routing", RFC1347, DEC,
June 1992.
[18] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
Hosts", RFC1526, Bellcore, September 1993.
[19] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, BARRNet, cisco, OARnet, September 1993.
[20] ISO/IEC JTC1/SC6, "Addendum to ISO 9542 Covering Address
Administration", N6273, March 1991.
A. Administration of NSAPs
NSAPs represent the endpoints of communication through the Network
Layer and must be globally unique [4]. ISO 8348 defines the
semantics of the NSAP and the abstract syntaxes in which the
semantics of the Network address can be expressed [11].
The NSAP consists of the initial domain part (IDP) and the domain
specific part (DSP). The initial domain part of the NSAP consists of
an authority and format identifier (AFI) and an initial domain
identifier (IDI). The AFI specifies the format of the IDI, the
network addressing authority responsible for allocating values of the
IDI, and the abstract syntax of the DSP. The IDI specifies the
addressing subdomain from which values of the DSP are allocated and
the network addressing authority responsible for allocating values of
the DSP from that domain. The structure and semantics of the DSP are
determined by the authority identified by the IDI. Figure 3 shows
the NSAP address structure.
+-----------+
| IDP |
+-----+-----+-------------------------------------------------+
| AFI | IDI |<--------------------DSP------------------------>|
+-----+-----+-------------------------------------------------+
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
Figure 3: NSAP address structure.
The global network addressing domain consists of all the NSAP
addresses in the OSI environment. Within that environment, seven
second-level addressing domains and corresponding IDI formats are
described in ISO 8348:
* X.121 for public data networks
* F.69 for telex
* E.163 for the public switched telephone network numbers
* E.164 for ISDN numbers
* ISO Data Country Code (DCC), allocated according to ISO 3166 [6]
* ISO International Code Designator (ICD), allocated according to
ISO 6523 [7]
* Local to accommodate the coexistence of OSI and non-OSI network
addressing schemes.
For OSI networks in the U.S., portions of the ICD subdomain are
available for use through the U.S. Government, and the DCC subdomain
is available for use through The American National Standards
Institute (ANSI). The British Standards Institute is the
registration authority for the ICD subdomain, and has registered four
IDIs for the U.S. Government: those used for GOSIP, DoD, OSINET, and
the OSI Implementors Workshop. ANSI, as the U.S. ISO Member Body, is
the registration authority for the DCC domain in the United States.
A.1 GOSIP Version 2 NSAPs
GOSIP Version 2 makes available for government use an NSAP addressing
subdomain with a corresponding address format as illustrated in
Figure 2 in Section 4.2. The "47" signifies that it is based on the
ICD format and uses a binary syntax for the DSP. The 0005 is an IDI
value which has been assigned to the U.S. Government. Although GOSIP
Version 2 NSAPs are intended primarily for U.S. Government use,
requests from non-government and non-U.S. organizations will be
considered on a case-by-case basis.
The format for the DSP under ICD=0005 has been established by the
National Institute of Standards and Technology (NIST), the authority
for the ICD=0005 domain, in GOSIP Version 2 [3] (see Figure 2,
Section 4.2). NIST has delegated the authority to register AA
identifiers for GOSIP Version 2 NSAPs to the General Services
Administration (GSA).
ISO 8348 allows a maximum length of 20 octets for the NSAP address.
The AFI of 47 occupies one octet, and the IDI of 0005 occupies two
octets. The DSP is encoded as binary as indicated by the AFI of 47.
One octet is allocated for a DSP Format Identifier, three octets for
an Administrative Authority identifier, two octets for Routing
Domain, two octets for Area, six octets for the System Identifier,
and one octet for the NSAP selector. Note that two octets have been
reserved to accommodate future growth and to provide additional
flexibility for inter-domain routing. The last seven octets of the
GOSIP NSAP format are structured in accordance with IS-IS [14], the
intra-domain IS-IS routing protocol. The DSP Format Identifier (DFI)
identifies the format of the remaining DSP structure and may be used
in the future to identify additional DSP formats; the value 80h in
the DFI identifies the GOSIP Version 2 NSAP structure.
The Administrative Authority identifier names the administrative
authority which is responsible for registration within its domain.
The administrative authority may delegate the responsibilityfor
registering areas to the routing domains, and the routing domains may
delegate the authority to register System Identifiers to the areas.
The main responsibility of a registration authority at any level of
the addressing hierarchy is to assure that names of entities are
unambiguous, i.e., no two entities have the same name. The
registration authority is also responsible for advertising the names.
A routing domain is a set of end systems and intermediate systems
which operate according to the same routing procedures and is wholly
contained within a single administrative domain. An area uniquely
identifies a subdomain of the routing domain. The system identifier
names a unique system within an area. The value of the system field
may be a physical address (SNPA) or a logical value. Address
resolution between the NSAP and the SNPA may be accomplished by an
ES-IS protocol [10], locally administered tables, or mapping
functions. The NSAP selector field identifies the end user of the
network layer service, i.e., a transport layer entity.
A.1.1 Application for Administrative Authority Identifiers
The steps required for an agency to acquire an NSAP Administrative
Authority identifier under ICD=0005 from GSA will be provided in the
updated GOSIP users' guide for Version 2 [2] and are given below.
Requests from non-government and non-U.S. organizations should
originate from a senior official, such as a vice-president or chief
operating officer.
* Identify all end systems, intermediate systems, subnetworks, and
their topological and administrative relationships.
* Designate one individual (usually the agency head) within an
agency to authorize all registration requests from that agency
(NOTE: All agency requests must pass through this individual).
* Send a letter on agency letterhead and signed by the agency head
to GSA:
Telecommunications Customer Requirements Office
U.S. General Services Administration
Information Resource Management Service
Office of Telecommunications Services
18th and F Streets, N.W.
Washington, DC 20405
Fax +1 202 208-5555
The letter should contain the following information:
- Requestor's Name and Title,
- Organization,
- Postal Address,
- Telephone and Fax Numbers,
- Electronic Mail Address(es), and,
- Reason Needed (one or two paragraphs explaining the intended
use).
* If accepted, GSA will send a return letter to the agency head
indicating the NSAP Administrative Authority identifier as-
signed,effective date of registration, and any other pertinent
information.
* If rejected, GSA will send a letter to the agency head
explaining the reason for rejection.
* Each Authority will administer its own subaddress space in
accordance with the procedures set forth by the GSA in Section
A.1.2.
* The GSA will maintain, publicize, and disseminate the assigned
values of Administrative Authority identifiers unless
specifically requested by an agency not to do so.
A.1.2 Guidelines for NSAP Assignment
Recommendations which should be followed by an administrative
authority in making NSAP assignments are given below.
* The authority should determine the degree of structure of the
DSP under its control. Further delegation of address assignment
authority (resulting in additional levels of hierarchy in the
NSAP) may be desired.
* The authority should make sure that portions of NSAPs that it
specifies are unique, current, and accurate.
* The authority should ensure that procedures exist for
disseminating NSAPs to routing domains and to areas within
each routing domain.
* The systems administrator must determine whether a logical or a
physical address should be used in the System Identifier field
(Figure 2, Section 4.2). An example of a physical address is a
48-bit MAC address; a logical address is merely a number that
meets the uniqueness requirements for the System Identifier
field, but bears no relationship to an address on a physical
subnetwork. We recommend that IDs should be assigned to be
globally unique, as made possible by the method described in
[18].
* The network address itself contains information that may be
used to aid routing, but does not contain a source route [12].
Information that enables next-hop determination based on NSAPs
is gathered and maintained by each intermediate system through
routing protocol exchanges.
* GOSIP end systems and intermediate systems in federal agencies
must be capable of routing information correctly to and from any
subdomain defined by ISO 8348.
* An agency may request the assignment of more than one
Administrative Authority identifier. The particular use of each
should be specified.
A.2 Data Country Code NSAPs
NSAPs from the Data Country Code (DCC) subdomain will also be common
in the international Internet. ANS X3.216-1992 specifies the DSP
structure under DCC=840 [1]. In the ANS, the DSP structure is
identical to that specified in GOSIP Version 2, with the
Administrative Authority identifier replaced by the numeric form of
the ANSI-registered organization name, as shown in Figure 4.
Referring to Figure 4, when the value of the AFI is 39, the IDI
denotes an ISO DCC and the abstract syntax of the DSP is binary
octets. The value of the IDI for the U.S. is 840, the three-digit
numeric code for the United States under ISO 3166 [6]. The numeric
form of organization name is analogous to the Administrative
Authority identifier in the GOSIP Version 2 NSAP.
<----IDP--->
+-----+-----+----------------------------------------+
| AFI | IDI |<----------------------DSP------------->|
+-----+-----+----------------------------------------+
| 39 | 840 | DFI |ORG | Rsvd | RD | Area | ID | SEL |
+-----+-----+----------------------------------------+
octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 |
+-----+-----+----------------------------------------+
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
DFI DSP Format Identifier
ORG Organization Name (numeric form)
Rsvd Reserved
RD Routing Domain Identifier
Area Area Identifier
ID System Identifier
SEL NSAP Selector
Figure 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3.
A.2.1 Application for Numeric Organization Name
The procedures for registration of numeric organization names in the
U.S. have been defined and are operational. To register a numeric
organization name, the applicant must submit a request for
registration and the $1,000 (U.S.) fee to the registration authority,
the American National Standards Institute (ANSI). ANSI will register
a numeric value, along with the information supplied for
registration, in the registration database. The registration
information will be sent to the applicant within ten working days.
The values for numeric organization names are assigned beginning at
113527.
The application form for registering a numeric organization name may
be obtained from the ANSI Registration Coordinator at the following
address:
Registration Coordinator
American National Standards Institute
11 West 42nd Street
New York, NY 10036
+1 212 642 4884 (tel)
+1 212 398 0023 (fax)
RFC822: mmaas@attmail.com
X.400: G=michelle; S=maas; A=attmail; C=us
Once an organization has registered with ANSI, it becomes a
registration authority itself. In turn, it may delegate registration
authority to routing domains, and these may make further delegations,
for instance, from routing domains to areas. Again, the
responsibilities of each Registration Authority are to assure that
NSAPs within the domain are unambiguous and to advertise them as
applicable.
A.3 Summary of Administrative Requirements
NSAPs must be globally unique, and an organization may assure this
uniqueness for OSI addresses in two ways. The organization may apply
to GSA for an Administrative Authority identifier. Although
registration of Administrative Authority identifiers by GSA primarily
serves U.S. Government agencies, requests for non-government and
non-U.S. organizations will be considered on a case-by-case basis.
Alternatively, the organization may apply to ANSI for a numeric
organization name. In either case, the organization becomes the
registration authority for its domain and can register NSAPs or
delegate the authority to do so.
In the case of GOSIP Version 2 NSAPs, the complete DSP structure is
given in GOSIP Version 2. For ANSI DCC-based NSAPs, the DSP
structure is specified in ANS X3.216-1992. The DSP structure is
identical to that specified in GOSIP Version 2.