summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1237.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1237.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1237.txt')
-rw-r--r--doc/rfc/rfc1237.txt2973
1 files changed, 2973 insertions, 0 deletions
diff --git a/doc/rfc/rfc1237.txt b/doc/rfc/rfc1237.txt
new file mode 100644
index 0000000..5af39bb
--- /dev/null
+++ b/doc/rfc/rfc1237.txt
@@ -0,0 +1,2973 @@
+
+
+
+
+ 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 Internet
+
+
+
+ Status of This Memo
+
+
+ This RFC specifies 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.
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ 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 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 RFC 994 [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]
+
+
+
+
+
+ RFC 1237 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 RFC 995 [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]
+
+
+
+
+
+ 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 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ 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 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]
+
+
+
+
+
+ RFC 1237 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 RFC 941 [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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+ 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, 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ 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 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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]
+
+
+
+
+
+ RFC 1237 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
+ regionals, leaf routing domains directly attached to the backbones,
+ and international links directly attached to the regionals. Under
+ these circumstances, the distinction between regionals and backbones
+ may become blurred.
+
+
+ An additional factor that discourages allocation of NSAPs from a
+ backbone prefix is that the backbones and their attached regionals are
+ perceived as being independent. Regionals may take their long-haul
+ service from one or more backbones, or may switch backbones should
+ a more cost-effective service be provided elsewhere (essentially,
+ backbones can be thought of the same way as long-distance telephone
+ carriers). Having NSAPs derived from the backbone is inconsistent with
+ 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 Domains
+
+
+
+ The discussions in Section 5.3 suggest methods for allocating NSAP
+ addresses based on regional or backbone connectivity. This allows a
+ great deal of information reduction to be achieved for those routing
+ domains which are attached to a single TRD. In particular, such
+ routing domains may select their NSAP addresses from a space allocated
+ to them by the regional. This allows the regional, when announcing the
+ addresses that it can reach to other regionals and backbones, to use
+ a single address prefix to describe a large number of NSAP addresses
+ corresponding to multiple routing domains.
+
+
+ However, there are additional considerations for routing domains
+ which are attached to multiple regionals and backbones. Such ``multi-
+ homed'' routing domains may, for example, consist of single-site
+ campuses and companies which are attached to multiple backbones, large
+ organizations which are attached to different regionals at different
+ locations in the same country, or multi-national organizations which
+ are attached to backbones in a variety of countries worldwide. There
+ are a number of possible ways to deal with these multi-homed routing
+ domains.
+
+
+ One possible solution is to assign addresses to each multi-homed
+ organization independently from the regionals and backbones to which
+ it is attached. This allows each multi-homed organization to base its
+ NSAP assignments on a single prefix, and to thereby summarize the set
+ of all NSAPs reachable within that organization via a single prefix.
+ The disadvantage of this approach is that since the NSAP address
+ for that organization has no relationship to the addresses of any
+ particular TRD, the TRDs to which this organization is attached will
+ need to advertise the prefix for this organization to other regionals
+ and backbones. Other regionals and backbones (potentially worldwide)
+ will need to maintain an explicit entry for that organization in their
+ routing tables.
+
+
+ For example, suppose that a very large U.S.-wide company ``Mega
+ Big International Incorporated'' (MBII) has a fully interconnected
+ internal network and is assigned a single AA value under the U.S.
+ GOSIP Version 2 address space. It is likely that outside of the U.S.,
+ a single entry may be maintained in routing tables for all U.S. GOSIP
+ addresses. However, within the U.S., every backbone and regional
+ will need to maintain a separate address entry for MBII. If MBII
+
+
+
+
+ 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 necessary
+ for every backbone worldwide to maintain a separate entry for MBII
+ (including backbones to which MBII is not attached). Clearly this
+ may be acceptable if there are a small number of such multi-homed
+ routing domains, but would place an unacceptable load on routers
+ within backbones if all organizations were to choose such address
+ assignments. This solution may not scale to internets where there are
+ many hundreds of thousands of multi-homed organizations.
+
+
+ A second possible approach would be for multi-homed organizations to
+ be assigned a separate NSAP space for each connection to a TRD, and
+ to assign a single address prefix to each area within its routing
+ domain(s) based on the closest interconnection point. For example, if
+ MBII had connections to two regionals in the U.S. (one east coast, and
+ one west coast), as well as three connections to national backbones
+ in Europe, and one in the far east, then MBII may make use of six
+ different address prefixes. Each area within MBII would be assigned a
+ single address prefix based on the nearest connection.
+
+
+ For purposes of external routing of traffic from outside MBII to a
+ destination inside of MBII, this approach works similarly to treating
+ MBII as six separate organizations. For purposes of internal routing,
+ or for routing traffic from inside of MBII to a destination outside of
+ MBII, this approach works the same as the first solution.
+
+
+ If we assume that incoming traffic (coming from outside of MBII, with
+ a destination within MBII) is always to enter via the nearest point to
+ the destination, then each TRD which has a connection to MBII needs
+ to announce to other TRDs the ability to reach only those parts of
+ MBII whose address is taken from its own address space. This implies
+ that no additional routing information needs to be exchanged between
+ TRDs, resulting in a smaller load on the inter-domain routing tables
+ maintained by TRDs when compared to the first solution. This solution
+ therefore scales better to extremely large internets containing very
+ large numbers of multi-homed organizations.
+
+
+ One problem with the second solution is that backup routes to multi-
+ homed organizations are not automatically maintained. With the first
+ solution, each TRD, in announcing the ability to reach MBII, specifies
+ that it is able to reach all of the NSAPs within MBII. With the second
+ solution, each TRD announces that it can reach all of the NSAPs based
+ on its own address prefix, which only includes some of the NSAPs
+ within MBII. If the connection between MBII and one particular TRD
+
+
+
+
+ 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 that
+ TRD would become unreachable via inter-domain routing. The impact
+ of this problem can be reduced somewhat by maintenance of additional
+ information within routing tables, but this reduces the scaling
+ advantage of the second approach.
+
+
+ The second solution also requires that when external connectivity
+ changes, internal addresses also change.
+
+
+ Also note that this and the previous approach will tend to cause
+ packets to take different routes. With the first approach, packets
+ from outside of MBII destined for within MBII will tend to enter via
+ the point which is closest to the source (which will therefore tend to
+ maximize the load on the networks internal to MBII). With the second
+ solution, packets from outside destined for within MBII will tend to
+ enter via the point which is closest to the destination (which will
+ tend to minimize the load on the networks within MBII, and maximize
+ 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 source
+ within country X to a destination within country X must at all
+ times stay entirely within the country. With the first solution, it
+ is not possible to determine from the destination address whether
+ or not the destination is within the country. With the second
+ solution, a separate address may be assigned to those NSAPs which are
+ within country X, thereby allowing routing policies to be followed.
+ Similarly, suppose that ``Little Small Company'' (LSC) has a policy
+ that its packets may never be sent to a destination that is within
+ MBII. With either solution, the routers within LSC may be configured
+ to discard any traffic that has a destination within MBII's address
+ space. However, with the first solution this requires one entry;
+ with the second it requires many entries and may be impossible as a
+ practical matter.
+
+
+ There are other possible solutions as well. A third approach is to
+ assign each multi-homed organization a single address prefix, based on
+ one of its connections to a TRD. Other TRDs to which the multi-homed
+ organization are attached maintain a routing table entry for the
+ organization, but are extremely selective in terms of which other
+ TRDs are told of this route. This approach will produce a single
+ ``default'' routing entry which all TRDs will know how to reach
+
+
+
+
+
+ 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), while
+ providing more direct routing in some cases.
+
+
+ There is at least one situation in which this third approach is
+ particularly appropriate. Suppose that a special interest group of
+ organizations have deployed their own backbone. For example, lets
+ suppose that the U.S. National Widget Manufacturers and Researchers
+ have set up a U.S.-wide backbone, which is used by corporations
+ who manufacture widgets, and certain universities which are known
+ for their widget research efforts. We can expect that the various
+ organizations which are in the widget group will run their internal
+ networks as separate routing domains, and most of them will also
+ be attached to other TRDs (since most of the organizations involved
+ in widget manufacture and research will also be involved in other
+ activities). We can therefore expect that many or most of the
+ organizations in the widget group are dual-homed, with one attachment
+ for widget-associated communications and the other attachment for
+ other types of communications. Let's also assume that the total number
+ of organizations involved in the widget group is small enough that
+ it is reasonable to maintain a routing table containing one entry
+ per organization, but that they are distributed throughout a larger
+ internet with many millions of (mostly not widget-associated) routing
+ domains.
+
+
+ With the third approach, each multi-homed organization in the widget
+ group would make use of an address assignment based on its other
+ attachment(s) to TRDs (the attachments not associated with the widget
+ group). The widget backbone would need to maintain routes to the
+ routing domains associated with the various member organizations.
+ Similarly, all members of the widget group would need to maintain a
+ table of routes to the other members via the widget backbone. However,
+ since the widget backbone does not inform other general worldwide TRDs
+ of what addresses it can reach (since the backbone is not intended
+ for use by other outside organizations), the relatively large set
+ of routing prefixes needs to be maintained only in a limited number
+ of places. The addresses assigned to the various organizations which
+ are members of the widget group would provide a ``default route'' via
+ each members other attachments to TRDs, while allowing communications
+ within the widget group to use the preferred path.
+
+
+ A fourth solution involves assignment of a particular address prefix
+ for routing domains which are attached to precisely two (or more)
+ specific routing domains. For example, suppose that there are two
+ regionals ``SouthNorthNet'' and ``NorthSouthNet'' which have a very
+
+
+
+
+ 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 number
+ of routing domains which are attached to both). Rather than getting
+ two address prefixes (such as two AA values assigned under the GOSIP
+ address space) these organizations could obtain three prefixes. Those
+ routing domains which are attached to NorthSouthNet but not attached
+ to SouthNorthNet obtain an address assignment based on one of the
+ prefixes. Those routing domains which are attached to SouthNorthNet
+ but not to NorthSouthNet would obtain an address based on the second
+ prefix. Finally, those routing domains which are multi-homed to both
+ of these networks would obtain an address based on the third prefix.
+ Each of these two TRDs would then advertise two prefixes to other
+ TRDs, one prefix for leaf routing domains attached to it only, and one
+ prefix for leaf routing domains attached to both.
+
+
+ This fourth solution is likely to be important when use of public data
+ networks becomes more common. In particular, it is likely that at some
+ point in the future a substantial percentage of all routing domains
+ will be attached to public data networks. In this case, nearly all
+ government-sponsored networks (such as some current NSFNET regionals)
+ may have a set of customers which overlaps substantially with the
+ public networks.
+
+
+ There are therefore a number of possible solutions to the problem
+ of assigning NSAP addresses to multi-homed routing domains. Each
+ of these solutions has very different advantages and disadvantages.
+ Each solution places a different real (i.e., financial) cost on the
+ multi-homed organizations, and on the TRDs (including those to which
+ the multi-homed organizations are not attached).
+
+
+ In addition, most of the solutions described also highlight the need
+ for each TRD to develop policy on whether and under what conditions
+ to accept addresses that are not based on its own address prefix, and
+ how such non-local addresses will be treated. For example, a somewhat
+ conservative policy might be that non-local NSAP prefixes will be
+ accepted from any attached leaf RD, but not advertised to other TRDs.
+ In a less conservative policy, a TRD might accept such non-local
+ prefixes and agree to exchange them with a defined set of other TRDs
+ (this set could be an a priori group of TRDs that have something in
+ common such as geographical location, or the result of an agreement
+ specific to the requesting leaf RD). Various policies involve real
+ costs to TRDs, which may be reflected in those policies.
+
+
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 28]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ 5.5 Private Links
+
+
+
+ The discussion up to this point concentrates on the relationship
+ between NSAP addresses and routing between various routing domains
+ over transit routing domains, where each transit routing domain
+ interconnects a large number of routing domains and offers a more-or-
+ less public service.
+
+
+ However, there may also exist a large number of private point-to-point
+ links which interconnect two private routing domains. In many cases
+ such private point-to-point links may be limited to forwarding packets
+ directly between the two private routing domains.
+
+
+ For example, let's suppose that the XYZ corporation does a lot of
+ business with MBII. In this case, XYZ and MBII may contract with a
+ carrier to provide a private link between the two corporations, where
+ this link may only be used for packets whose source is within one of
+ the two corporations, and whose destination is within the other of the
+ two corporations. Finally, suppose that the point-to-point link is
+ connected between a single router (router X) within XYZ corporation
+ and a single router (router M) within MBII. It is therefore necessary
+ to configure router X to know which addresses can be reached over
+ this link (specifically, all addresses reachable in MBII). Similarly,
+ it is necessary to configure router M to know which addresses can be
+ reached over this link (specifically, all addresses reachable in XYZ
+ Corporation).
+
+
+ The important observation to be made here is that such private
+ links may be ignored for the purpose of NSAP allocation, and do not
+ pose a problem for routing. This is because the routing information
+ associated with private links is not propagated throughout the
+ internet, and therefore does not need to be collapsed into a TRD's
+ prefix.
+
+
+ In our example, lets suppose that the XYZ corporation has a single
+ connection to an NSFNET regional, and has therefore received an
+ address allocation from the space administered by that regional.
+ Similarly, let's suppose that MBII, as an international corporation
+ with connections to six different backbones or regionals, has chosen
+ the second solution from Section 5.4, and therefore has obtained six
+ different address allocations. In this case, all addresses reachable
+ in the XYZ Corporation can be described by a single address prefix
+
+
+
+ Colella, Gardner, & Callon [Page 29]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ (implying that router M only needs to be configured with a single
+ address prefix to represent the addresses reachable over this point-
+ to-point link). All addresses reachable in MBII can be described by
+ six address prefixes (implying that router X needs to be configured
+ with six address prefixes to represent the addresses reachable over
+ the point-to-point link).
+
+
+ In some cases, such private point-to-point links may be permitted
+ to forward traffic for a small number of other routing domains,
+ such as closely affiliated organizations. This will increase the
+ configuration requirements slightly. However, provided that the number
+ of organizations using the link is relatively small, then this still
+ does not represent a significant problem.
+
+
+ Note that the relationship between routing and NSAP addressing
+ described in other sections of this paper is concerned with problems
+ in scaling caused by large, essentially public transit routing domains
+ which interconnect a large number of routing domains. However, for
+ the purpose of NSAP allocation, private point-to-point links which
+ interconnect only a small number of private routing domains do not
+ pose a problem, and may be ignored. For example, this implies that
+ a single leaf routing domain which has a single connection to a
+ ``public'' backbone (e.g., the NSFNET), plus a number of private
+ point-to-point links to other leaf routing domains, can be treated
+ as if it were single-homed to the backbone for the purpose of NSAP
+ address allocation.
+
+
+
+ 5.6 Zero-Homed Routing Domains
+
+
+
+ Currently, a very large number of organizations have internal
+ communications networks which are not connected to any external
+ network. Such organizations may, however, have a number of private
+ point-to-point links that they use for communications with other
+ organizations. Such organizations do not participate in global
+ routing, but are satisfied with reachability to those organizations
+ with which they have established private links. These are referred to
+ as zero-homed routing domains.
+
+
+ Zero-homed routing domains can be considered as the degenerate case
+ of routing domains with private links, as discussed in the previous
+ section, and do not pose a problem for inter-domain routing. As above,
+
+
+
+ Colella, Gardner, & Callon [Page 30]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ the routing information exchanged across the private links sees very
+ limited distribution, usually only to the RD at the other end of the
+ link. Thus, there are no address abstraction requirements beyond those
+ inherent in the address prefixes exchanged across the private link.
+
+
+ However, it is important that zero-homed routing domains use valid
+ globally unique NSAP addresses. Suppose that the zero-homed routing
+ domain is connected through a private link to an RD. Further, this
+ RD participates in an internet that subscribes to the global OSI
+ addressing plan (i.e., Addendum 2 to ISO8348). This RD must be able
+ to distinguish between the zero-homed routing domain's NSAPs and any
+ other NSAPs that it may need to route to. The only way this can be
+ guaranteed is if the zero-homed routing domain uses globally unique
+ NSAPs.
+
+
+
+ 5.7 Transition Issues
+
+
+
+ Allocation of NSAP addresses based on connectivity to TRDs is
+ important to allow scaling of inter-domain routing to an internet
+ containing millions of routing domains. However, such address
+ allocation based on topology also implies that a change in topology
+ may result in a change of address.
+
+
+ This need to allow for change in addresses is a natural, inevitable
+ consequence of routing data abstraction. The basic notion of routing
+ data abstraction is that there is some correspondence between the
+ address and where a system (i.e., a routing domain, area, or end
+ system) is located. Thus if the system moves, in some cases the
+ address will have to change. If it were possible to change the
+ connectivity between routing domains without changing the addresses,
+ then it would clearly be necessary to keep track of the location of
+ that routing domain on an individual basis.
+
+
+ In the short term, due to the rapid growth and increased commer-
+ cialization of the Internet, it is possible that the topology may be
+ relatively volatile. This implies that planning for address transition
+ is very important. Fortunately, there are a number of steps which can
+ be taken to help ease the effort required for address transition. A
+ complete description of address transition issues is outside of the
+ scope of this paper. However, a very brief outline of some transition
+ issues is contained in this section.
+
+
+
+ Colella, Gardner, & Callon [Page 31]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ Also note that the possible requirement to transition addresses
+ based on changes in topology imply that it is valuable to anticipate
+ the future topology changes before finalizing a plan for address
+ allocation. For example, in the case of a routing domain which is
+ initially single-homed, but which is expecting to become multi-homed
+ in the future, it may be advantageous to assign NSAP addresses based
+ on the anticipated future topology.
+
+
+ In general, it will not be practical to transition the NSAP addresses
+ assigned to a routing domain in an instantaneous ``change the address
+ at midnight'' manner. Instead, a gradual transition is required in
+ which both the old and the new addresses will remain valid for a
+ limited period of time. During the transition period, both the old and
+ new addresses are accepted by the end systems in the routing domain,
+ and both old and new addresses must result in correct routing of
+ packets to the destination.
+
+
+ Provision for transition has already been built into DIS10589.
+ As described in Section 3, DIS10589 allows multiple addresses to
+ be assigned to each area specifically for the purpose of easing
+ transition.
+
+
+ Similarly, there are provisions in OSI for the autoconfiguration of
+ area addresses. This allows OSI end systems to find out their area
+ addresses automatically by observing the ISO9542 IS-Hello packets
+ transmitted by routers. If the ID portion of the address is assigned
+ by using IEEE style ``stamped in PROM at birth'' identifiers, then
+ an end system can reconfigure its entire NSAP address automatically
+ without the need for manual intervention. However, routers will still
+ need manual address reconfiguration.
+
+
+ During the transition period, it is important that packets using
+ the old address be forwarded correctly, even when the topology has
+ changed. This is facilitated by the use of ``best match'' inter-domain
+ routing.
+
+
+ For example, suppose that the XYZ Corporation was previously connected
+ only to the NorthSouthNet NSFNET regional. The XYZ Corporation
+ therefore went off to the NorthSouthNet administration and got a
+ routing domain assignment based on the AA value assigned to the
+ NorthSouthNet regional under the GOSIP address space. However, for
+ a variety of reasons, the XYZ Corporation decided to terminate its
+ association with the NorthSouthNet, and instead connect directly to
+
+
+
+ Colella, Gardner, & Callon [Page 32]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ the NewCommercialNet public data network. Thus the XYZ Corporation
+ now has a new address assignment under the ANSI address assigned to
+ the NewCommercialNet. The old address for the XYZ Corporation would
+ seem to imply that traffic for the XYZ Corporation should be routed to
+ the NorthSouthNet, which no longer has any direct connection with XYZ
+ Corporation.
+
+
+ If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet) are
+ adjacent and cooperative, then this transition is easy to accomplish.
+ In this case, packets routed to the XYZ Corporation using the old
+ address assignment could be routed to the NorthSouthNet, which would
+ directly forward them to the NewCommercialNet, which would in turn
+ forward them to XYZ Corporation. In this case only NorthSouthNet
+ and NewCommercialNet need be aware of the fact that the old address
+ refers to a destination which is no longer directly attached to
+ NorthSouthNet.
+
+
+ If the old TRD and the new TRD are not adjacent, then the situation
+ is a bit more complex, but there are still several possible ways to
+ forward traffic correctly.
+
+
+ If the old TRD and the new TRD are themselves connected by other
+ cooperative transit routing domains, then these intermediate domains
+ may agree to forward traffic for XYZ correctly. For example, suppose
+ that NorthSouthNet and NewCommercialNet are not directly connected,
+ but that they are both directly connected to the NSFNET backbone.
+ In this case, all three of NorthSouthNet, NewCommercialNet, and
+ the NSFNET backbone would need to maintain a special entry for XYZ
+ corporation so that traffic to XYZ using the old address allocation
+ would be forwarded via NewCommercialNet. However, other routing
+ domains would not need to be aware of the new location for XYZ
+ Corporation.
+
+
+ Suppose that the old TRD and the new TRD are separated by a non-
+ cooperative routing domain, or by a long path of routing domains. In
+ this case, the old TRD could encapsulate traffic to XYZ Corporation in
+ order to deliver such packets to the correct backbone.
+
+
+ Also, those locations which do a significant amount of business with
+ XYZ Corporation could have a specific entry in their routing tables
+ added to ensure optimal routing of packets to XYZ. For example,
+ suppose that another commercial backbone ``OldCommercialNet'' has a
+ large number of customers which exchange traffic with XYZ Corporation,
+
+
+
+ Colella, Gardner, & Callon [Page 33]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ and that this third TRD is directly connected to both NorthSouthNet
+ and NewCommercialNet. In this case OldCommercialNet will continue
+ to have a single entry in its routing tables for other traffic
+ destined for NorthSouthNet, but may choose to add one additional (more
+ specific) entry to ensure that packets sent to XYZ Corporation's old
+ address are routed correctly.
+
+
+ Whichever method is used to ease address transition, the goal is that
+ knowledge relating XYZ to its old address that is held throughout the
+ global internet would eventually be replaced with the new information.
+ It is reasonable to expect this to take weeks or months and will be
+ accomplished through the distributed directory system. Discussion of
+ the directory, along with other address transition techniques such as
+ automatically informing the source of a changed address, are outside
+ the scope of this paper.
+
+
+
+ 6 Recommendations
+
+
+
+ We anticipate that the current exponential growth of the Internet will
+ continue or accelerate for the foreseeable future. In addition, we
+ anticipate a rapid internationalization of the Internet. The ability
+ of routing to scale is dependent upon the use of data abstraction
+ based on hierarchical NSAP addresses. As OSI is introduced in the
+ Internet, it is therefore essential to choose a hierarchical structure
+ for NSAP addresses with great care.
+
+
+ It is in the best interests of the internetworking community that the
+ cost of operations be kept to a minimum where possible. In the case of
+ NSAP allocation, this again means that routing data abstraction must
+ be encouraged.
+
+
+ In order for data abstraction to be possible, the assignment of NSAP
+ addresses must be accomplished in a manner which is consistent with
+ the actual physical topology of the Internet. For example, in those
+ cases where organizational and administrative boundaries are not
+ related to actual network topology, address assignment based on such
+ organization boundaries is not recommended.
+
+
+ The intra-domain IS-IS routing protocol allows for information
+ abstraction to be maintained at two levels: systems are grouped
+
+
+
+ Colella, Gardner, & Callon [Page 34]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ into areas, and areas are interconnected to form a routing domain.
+ For zero-homed and single-homed routing domains (which are expected
+ to remain zero-homed or single-homed), we recommend that the NSAP
+ addresses assigned for OSI use within a single routing domain use
+ a single address prefix assigned to that domain. Specifically, this
+ allows the set of all NSAP addresses reachable within a single domain
+ to be fully described via a single prefix.
+
+
+ We anticipate that the total number of routing domains existing on a
+ worldwide OSI Internet to be great enough that additional levels of
+ hierarchical data abstraction beyond the routing domain level will be
+ necessary.
+
+
+ In most cases, network topology will have a close relationship with
+ national boundaries. For example, the degree of network connectivity
+ will often be greater within a single country than between countries.
+ It is therefore appropriate to make specific recommendations based on
+ national boundaries, with the understanding that there may be specific
+ situations where these general recommendations need to be modified.
+
+
+
+ 6.1 Recommendations Specific to U.S. Parts of the Internet
+
+
+
+ NSAP addresses for use within the U.S. portion of the Internet are
+ expected to be based primarily on two address prefixes: the IDP format
+ used by NIST for GOSIP Version 2, and the DCC=840 format defined by
+ ANSI.
+
+
+ We anticipate that, in the U.S., public interconnectivity between
+ private routing domains will be provided by a diverse set of TRDs,
+ including (but not necessarily limited to):
+
+ * the NSFNET backbone;
+
+ * a number of NSFNET regional networks; and,
+
+ * a number of commercial Public Data Networks.
+
+ It is also expected that these networks will not be interconnected
+ in a strictly hierarchical manner (for example, there is expected
+ to be direct connectivity between NSFNET regionals, and all three of
+ these types of networks may have direct international connections).
+
+
+
+ Colella, Gardner, & Callon [Page 35]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ However, the total number of such TRDs is expected to remain (for the
+ foreseeable future) small enough to allow addressing of this set of
+ TRDs via a flat address space. These TRDs will be used to interconnect
+ a wide variety of routing domains, each of which may comprise a single
+ corporation, part of a corporation, a university campus, a government
+ agency, or other organizational unit.
+
+
+ In addition, some private corporations may be expected to make use of
+ dedicated private TRDs for communication within their own corporation.
+
+
+ We anticipate that the great majority of routing domains will be
+ attached to only one of the TRDs. This will permit hierarchical
+ address abbreviation based on TRD. We therefore strongly recommend
+ that addresses be assigned hierarchically, based on address prefixes
+ assigned to individual TRDs.
+
+
+ For the GOSIP address format, this implies that Administrative
+ Authority (AA) identifiers should be assigned to all TRDs (explicitly
+ including the NSFNET backbone, the NSFNET regionals, and other major
+ government backbones). For those leaf routing domains which are
+ connected to a single TRD, they should be assigned a Routing Domain
+ (RD) value from the space assigned to that TRD.
+
+
+ We recommend that all TRDs explicitly be involved in the task of
+ address administration for those leaf routing domains which are
+ single-homed to them. This will offer a valuable service to their
+ customers, and will also greatly reduce the resources (including
+ human and network resources) necessary for that TRD to take part in
+ inter-domain routing.
+
+
+ Each TRD should develop policy on whether and under what conditions to
+ accept addresses that are not based on its own address prefix, and how
+ such non-local addresses will be treated. Policies should reflect the
+ issue of cost associated with implementing such policies.
+
+
+ We recommend that a similar hierarchical model be used for NSAP
+ addresses using the DCC-based address format. The structure for
+ DCC=840-based NSAPs is provided in Section A.2.
+
+
+ For routing domains which are not attached to any publically-
+ available TRD, there is not the same urgent need for hierarchical
+ address abbreviation. We do not, therefore, make any additional
+ recommendations for such ``isolated'' routing domains, except to
+
+ Colella, Gardner, & Callon [Page 36]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ note that there is no technical reason to preclude assignment of
+ GOSIP AA identifier values or ANSI organization identifiers to such
+ domains. Where such domains are connected to other domains by private
+ point-to-point links, and where such links are used solely for routing
+ between the two domains that they interconnect, again no additional
+ technical problems relating to address abbreviation is caused by such
+ a link, and no specific additional recommendations are necessary.
+
+
+
+ 6.2 Recommendations Specific to Non-U.S. Parts of the Internet
+
+
+
+ For the part of the Internet which is outside of the U.S., it is
+ recommended that the DSP format be structured similarly to that
+ specified within GOSIP Version 2 no matter whether the addresses are
+ based on DCC or ICD format.
+
+
+ Further, in order to allow aggregation of NSAPs at national boundaries
+ into as few prefixes as possible, we further recommend that NSAPs
+ allocated to routing domains should be assigned based on each routing
+ domain's connectivity to a national Internet backbone.
+
+
+
+ 6.3 Recommendations for Multi-Homed Routing Domains
+
+
+
+ Some routing domains will be attached to multiple TRDs within the
+ same country, or to TRDs within multiple different 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 TRDs;
+
+ * administrative cost on TRD personnel; and,
+
+
+
+ Colella, Gardner, & Callon [Page 37]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ * difficulty of configuration of policy-based inter-domain routing
+ information within leaf 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 routing domains, regionals, and backbones.
+
+
+
+ 7 Security Considerations
+
+
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 38]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ 8 Authors' Addresses
+
+
+
+ Richard P. Colella
+ National Institute of Standards & Technology
+ Building 225/Room B217
+ Gaithersburg, MD 20899
+
+
+ Phone: (301) 975-3627
+ EMail: colella@osi3.ncsl.nist.gov
+
+
+
+ EllaP. Gardner
+ The MITRE Corporation
+ 7525 Colshire Drive
+ McLean, VA 22102
+
+
+ Phone: (703) 883-5826
+ EMail: epg@gateway.mitre.org
+
+
+
+ Ross Callon
+ c/o Digital Equipment Corporation, 1-2/A19
+ 550 King Street
+ Littleton, MA 01460-1289
+
+
+ Phone: (508) 486-5009
+ Email: Callon@bigfut.enet.dec.com
+
+
+
+ 9 Acknowledgments
+
+
+
+ The authors would like to thank the members of the IETF OSI-NSAP
+ Working Group for the helpful suggestions made during the writing of
+ this paper.
+
+
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 39]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ A Administration of NSAPs
+
+
+
+ NSAPs represent the endpoints of communication through the Network
+ Layer and must be globally unique [5]. Addendum 2 to ISO8348 defines
+ the semantics of the NSAP and the abstract syntaxes in which the
+ semantics of the Network address can be expressed [14].
+
+
+ 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 ISO8348/Addendum 2:
+
+ * 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 ISO3166 [9]
+
+
+
+ Colella, Gardner, & Callon [Page 40]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ * ISO International Code Designator (ICD), allocated according to
+ ISO6523 [10]
+
+ * 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 subdo-
+ main 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. (The
+ U.S. Government is registered as an organization by ANSI under the
+ DCC, and in turn, will register object identifiers and X.400 names
+ under this authority.)
+
+
+
+ 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 on page 16. 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 [4] (see Figure 2,
+ page 16). NIST has delegated the authority to register AA identifiers
+ for GOSIP Version 2 NSAPs to the General Services Administration
+ (GSA).
+
+
+ Addendum 2 to ISO8348 allows a maximum length of 20 octets for the
+ NSAP. 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
+
+
+
+ Colella, Gardner, & Callon [Page 41]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ 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 DIS10589 [17], 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 responsibility for
+ 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 [13], 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.
+
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 42]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ * 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 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.
+
+
+
+ Colella, Gardner, & Callon [Page 43]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ * 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 dissemi-
+ nating 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
+ (Figure2, page 16). 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.
+
+ * The network address itself contains no routing information [15].
+ 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 ISO8348/Addendum 2.
+
+ * An agency may request the assignment of more than one Administra-
+ tive Authority identifier. The particular use of each should be
+ specified.
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 44]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ A.2 Data Country Code NSAPs
+
+
+
+ NSAPs from the Data Country Code (DCC) subdomain will also be common
+ in the international Internet. Currently, there is a draft proposed
+ American National Standard (dpANS) in the U.S. for the DSP structure
+ under DCC=840 [1]. Subsequent to an upcoming ANSI X3 Committee ballot,
+ the dpANS will be distributed for public comment.
+
+
+ In the dpANS, 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 ISO3166 [9]. 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.
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 45]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ 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 4976 (tel)
+ +1 212 398 0023 (fax)
+
+
+ Once an organization has registered with ANSI, it becomes a registra-
+ tion authority itself. In turn, it may delegate registration authority
+ to routing domains, and these may make further delegations, for in-
+ stance, 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
+
+
+
+ Colella, Gardner, & Callon [Page 46]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ 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, there is a draft
+ proposed American National Standard that specifies the DSP structure
+ under DCC=840. The dpANS specifies a DSP structure that is identical
+ to that specified in GOSIP Version 2.
+
+
+
+ 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. Draft Proposed American National
+ Standard, 1991 (pending final approval by ANSI).
+
+
+ [2] Tim Boland. 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] ECMA. Inter-Domain Routeing. Technical Report 50, ISO/IEC JTC 1,
+ Switzerland, 1989.
+
+
+ [4] 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.
+
+
+ [5] Christine Hemrick. The OSI Network Layer Addressing Scheme, Its
+ Implications, and Considerations for Implementation. NTIA Report
+ 85-186, U.S. Department of Commerce, National Telecommunications
+ and Information Administration, 1985.
+
+
+ [6] ISO. Addendum to the Network Service Definition Covering Network
+ Layer Addressing. RFC 941,Network Working Group, April 1985.
+
+
+
+ Colella, Gardner, & Callon [Page 47]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ [7] ISO. End System to Intermediate System Routing Exchange Protocol
+ for use in conjunction with ISO 8473. RFC 995, Network Working
+ Group, April 1986.
+
+ [8] ISO. Final Text of DIS 8473, Protocol for Providing the
+ Connectionless-mode Network Service. RFC 994, Network Working
+ Group, March 1986.
+
+ [9] ISO/IEC. Codes for the Representation of Names of Countries.
+ International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
+
+ [10] ISO/IEC. Data Interchange - Structures for the Identification
+ of Organization. International Standard 6523, ISO/IEC JTC 1,
+ Switzerland, 1984.
+
+ [11] ISO/IEC. Information Processing Systems - Open Systems Intercon-
+ nection- Basic Reference Model. International Standard 7498,
+ ISO/IEC JTC 1, Switzerland, 1984.
+
+ [12] ISO/IEC. Protocol for Providing the Connectionless-mode Network
+ Service. International Standard 8473, ISO/IEC JTC 1, Switzerland,
+ 1986.
+
+ [13] ISO/IEC. End System to Intermediate System Routing Exchange
+ Protocol for use in Conjunction with the Protocol for the Provi-
+ sion of the Connectionless-mode Network Service. International
+ Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
+
+ [14] ISO/IEC. Information Processing Systems -- Data Communications
+ -- Network Service Definition Addendum 2: Network Layer Address-
+ ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
+ Switzerland, 1988.
+
+ [15] ISO/IEC. Information Processing Systems - OSI Reference Model
+ - Part3: Naming and Addressing. Draft International Standard
+ 7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
+
+ [16] ISO/IEC. Information Technology - Telecommunications and
+ Information Exchange Between Systems - OSI Routeing Framework.
+ Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
+
+ [17] ISO/IEC. Intermediate System to Intermediate System Intra-Domain
+ Routeing Exchange Protocol for use in Conjunction with the
+
+
+
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 48]
+
+
+
+
+
+ RFC 1237 Guidelines for OSI NSAP Allocation in the Internet July 1991
+
+
+
+ Protocol for Providing the Connectionless-mode Network Service
+ (ISO 8473). Draft International Standard 10589, ISO/IEC JTC 1,
+ Switzerland, November 1990.
+
+
+ [18] K. Loughheed and Y. Rekhter. A Border Gateway Protocol (BGP).
+ RFC 1105, Network Working Group, 1989.
+
+
+ [19] K. Loughheed and Y. Rekhter. A Border Router Protocol(BRP).
+ Draft, Network Working Group, February 1990.
+
+
+ [20] ASC X3S3.3. Intermediate System to Intermediate System Inter-
+ Domain Routeing Exchange Protocol. Working Document 90-216, ANSI,
+ New York, July 1990.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Colella, Gardner, & Callon [Page 49]
+
+