diff options
Diffstat (limited to 'doc/rfc/rfc1237.txt')
| -rw-r--r-- | doc/rfc/rfc1237.txt | 2973 |
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] + + |