RFCs in HTML Format


RFC 1629

           Guidelines for OSI NSAP Allocation in the Internet














Colella, Callon, Gardner & Rekhter                              [Page 1]

RFC 1629 NSAP Guidelines May 1994 Table of Contents Section 1. Introduction ............................... 4 Section 2. Scope ...................................... 5 Section 3. Background ................................. 7 Section 3.1 OSI Routing Standards ..................... 7 Section 3.2 Overview of IS-IS (ISO/IEC 10589) ......... 8 Section 3.3 Overview of IDRP (ISO/IEC 10747) .......... 12 Section 3.3.1 Scaling Mechanisms in IDRP .............. 14 Section 3.4 Requirements of IS-IS and IDRP on NSAPs ... 15 Section 4. NSAPs and Routing .......................... 16 Section 4.1 Routing Data Abstraction .................. 16 Section 4.2 NSAP Administration and Efficiency ........ 19 Section 5. NSAP Administration and Routing in the In- ternet ........................................... 21 Section 5.1 Administration at the Area ................ 23 Section 5.2 Administration at the Subscriber Routing Domain ........................................... 24 Section 5.3 Administration at the Provider Routing Domain ........................................... 24 Section 5.3.1 Direct Service Providers ................ 25 Section 5.3.2 Indirect Providers ...................... 26 Section 5.4 Multi-homed Routing Domains ............... 26 Section 5.5 Private Links ............................. 31 Section 5.6 Zero-Homed Routing Domains ................ 33 Section 5.7 Address Transition Issues ................. 33 Section 6. Recommendations ............................ 36 Section 6.1 Recommendations Specific to U.S. Parts of the Internet ..................................... 37 Section 6.2 Recommendations Specific to European Parts of the Internet .................................. 39 Section 6.2.1 General NSAP Structure .................. 40 Section 6.2.2 Structure of the Country Domain Part .... 40 Section 6.2.3 Structure of the Country Domain Specific Part .................................... 41 Section 6.3 Recommendations Specific to Other Parts of the Internet ..................................... 41 Section 6.4 Recommendations for Multi-Homed Routing Domains .......................................... 41 Section 6.5 Recommendations for RDI and RDCI assign- ment ............................................. 42 Section 7. Security Considerations .................... 42 Section 8. Authors' Addresses ......................... 43 Section 9. Acknowledgments ............................ 43 Section 10. References ................................ 44 Section A. Administration of NSAPs .................... 46 Section A.1 GOSIP Version 2 NSAPs .................... 47 Section A.1.1 Application for Administrative Authority Colella, Callon, Gardner & Rekhter [Page 2]
RFC 1629 NSAP Guidelines May 1994 Identifiers ...................................... 48 Section A.1.2 Guidelines for NSAP Assignment ......... 50 Section A.2 Data Country Code NSAPs .................. 50 Section A.2.1 Application for Numeric Organization Name ............................................. 51 Section A.3 Summary of Administrative Requirements .. 52 Colella, Callon, Gardner & Rekhter [Page 3]
RFC 1629 NSAP Guidelines May 1994 1. Introduction The Internet is moving towards a multi-protocol environment that includes CLNP. To support CLNP in the Internet, an OSI lower layers infrastructure is required. This infrastructure comprises the connectionless network protocol (CLNP) [9] 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 NSAP addresses in the Internet (the terms NSAP and NSAP address are used interchangeably throughout this paper in referring to NSAP addresses). The guidelines presented in this document are quite similar to the guidelines that are proposed in the Internet for IP address allocation with CIDR (RFC 1519 [19]). The major difference between the two is the size of the addresses (4 octets for CIDR vs 20 octets for CLNP). The larger NSAP addresses allows considerably greater flexibility and scalability. 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 NSAP addresses. Section 4 addresses the specific relationship between NSAP addresses 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 address allocation in the Internet. This includes recommendations for the U.S. and European parts of the Internet, as well as more general recommendations for any part of the Internet. The Appendix 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. This document obsoletes RFC 1237. The changes from RFC 1237 are minor, and primarily editorial in nature. The descriptions of OSI routing standards contained in Section 3 have been updated to reflect the current status of the relevant standards, and a description of the OSI Interdomain Routing Protocol (IDRP) has been added. Recommendations specific to the European part of the Internet have Colella, Callon, Gardner & Rekhter [Page 4]
RFC 1629 NSAP Guidelines May 1994 been added in Section 6, along with recommendations for Routing Domain Identifiers and Routing Domain Confederation Identifiers needed for operation of IDRP. 2. Scope Control over the collection of hosts and the transmission and switching facilities that compose the networking resources of the global Internet is not homogeneous, but is distributed among multiple administrative authorities. For the purposes of this paper, the term network service provider (or just provider) is defined to be an organization that is in the business of providing datagram switching services to customers. Organizations that are *only* customers (i.e., that do not provide datagram services to other organizations) are called network service subscribers (or simply subscribers). In the current Internet, subscribers (e.g., campus and corporate site networks) attach to providers (e.g., regionals, commercial providers, and government backbones) in only one or a small number of carefully controlled access points. For discussion of OSI NSAP allocation in this paper, providers are treated as composing a mesh having no fixed hierarchy. Addressing solutions which require substantial changes or constraints on the current topology are not considered in this paper. There are two aspects of interest when discussing OSI NSAP allocation within the Internet. The first is the set of administrative requirements for obtaining and allocating NSAP addresses; 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 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 end-system to intermediate system routing protocol (ES-IS) [10], intra-domain IS-IS protocol [14], and inter-domain routing protocol (IDRP) [16]. It is expected that in the future the OSI routing architecture will be enhanced to include support for multicast, resource reservation, and other advanced services. The requirements for addressing for these future services is outside of the scope of this document. The guidelines provided in this paper have been the basis for initial deployment of CLNP in the Internet, and have proven very valuable both as an aid to scaling of CLNP routing, and to address administration. Colella, Callon, Gardner & Rekhter [Page 5]
RFC 1629 NSAP Guidelines May 1994 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 IS-IS routing protocol; * Benefits of some topological information in NSAPs to reduce routing protocol overhead, and specifically the overhead on inter-domain routing (IDRP); * The anticipated need for additional levels of hierarchy in Internet addressing to support network growth and use of the Routing Domain Confederation mechanism of IDRP to provide support for additional levels of hierarchy; * The recommended mapping between Internet topological entities (i.e., service providers and service subscribers) and OSI addressing and routing components, such as areas, domains and confederations; * The recommended division of NSAP address assignment authority among service providers and service subscribers; * Background information on administrative procedures for registration 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 subscriber routing domains that are connected to more than one service provider. 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 portion of the NSAP address space has been allocated); Colella, Callon, Gardner & Rekhter [Page 6]
RFC 1629 NSAP Guidelines May 1994 * 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. A method for assignment of System IDs is presented in [18]. 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 and inter-domain protocols in sufficient detail to understand the issues involved in NSAP allocation. Finally, the specific constraints that the routing protocols place on NSAPs are listed. 3.1. OSI Routing Standards OSI partitions the routing problem into three parts: * routing exchanges between hosts (a.k.a., end systems or ESs) and routers (a.k.a., intermediate systems or ISs) (ES-IS); * routing exchanges between routers in the same routing domain (intra-domain IS-IS); and, * routing among routing domains (inter-domain IS-IS). ES-IS (international standard ISO 9542) advanced to international standard (IS) status within ISO in 1987. Intra-domain IS-IS advanced to IS status within ISO in 1992. Inter-Domain Routing Protocol (IDRP) advanced to IS status within ISO in October 1993. CLNP, ES- IS, and IS-IS are all widely available in vendor products, and have been deployed in the Internet for several years. IDRP is currently being implemented in vendor products. 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, Callon, Gardner & Rekhter [Page 7]
RFC 1629 NSAP Guidelines May 1994 3.2. Overview of ISIS (ISO/IEC 10589) The IS-IS intra-domain routing protocol, ISO/IEC 10589, provides routing for OSI environments. In particular, IS-IS is designed to work in conjunction with CLNP, ES-IS, and IDRP. This section briefly describes the manner in which IS-IS operates. In IS-IS, 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 administration (throughout this paper, "domain" and "routing domain" are used interchangeably). Typically, a routing domain may consist of a corporate network, a university campus network, a regional network, a backbone, or a similar contiguous 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 intra-domain IS-IS routing messages are sent on that link. IS-IS routing makes use of two-level hierarchical routing. A routing domain is subdivided into areas (also known as level 1 subdomains). Level 1 routers know the topology in their area, including all routers and hosts. However, level 1 routers do not know the identity of routers or destinations outside of their area. Level 1 routers forward all traffic for destinations outside of their area to a level 2 router within their area. Similarly, level 2 routers know the level 2 topology and know which addresses are reachable via each level 2 router. The set of all level 2 routers 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 routers do not need to know the topology within any level 1 area, except to the extent that a level 2 router may also be a level 1 router within a single area. Only level 2 routers can exchange data packets or routing information directly with routers located outside of their routing domain. NSAP addresses provide a flexible, variable length addressing format, which allows for multi-level hierarchical address assignment. These addresses provide the flexibility needed to solve two critical problems simultaneously: (i) How to administer a worldwide address space; and (ii) How to assign addresses in a manner which makes routing scale well in a worldwide Internet. As illustrated in Figure 1, ISO addresses are subdivided into the Initial Domain Part (IDP) and the Domain Specific Part (DSP). The IDP is the part which is standardized by ISO, and specifies the format and authority responsible for assigning the rest of the Colella, Callon, Gardner & Rekhter [Page 8]
RFC 1629 NSAP Guidelines May 1994 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). It is expected that the authority specified by the IDP may further sub-divide the DSP, and may assign sub-authorities responsible for parts of the DSP. For routing purposes, ISO addresses are subdivided by IS-IS into the area address, the system identifier (ID), and the NSAP selector (SEL). The area address identifies both the routing domain and the area within the routing domain. Generally, the area address corresponds to the IDP plus a high-order part of the DSP (HO-DSP). <----IDP---> <----------------------DSP----------------------------> <-----------HO-DSP------------> +-----+-----+-------------------------------+--------------+-------+ | AFI | IDI |Contents assigned by authority identified in IDI field| +-----+-----+-------------------------------+--------------+-------+ <----------------Area Address--------------> <-----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). It is therefore not necessary for the area address to have any particular length -- the length of the area address could vary between different area addresses in a given routing domain. 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, Callon, Gardner & Rekhter [Page 9]
RFC 1629 NSAP Guidelines May 1994 * It might be desirable to change the address of an area. The most graceful way of changing an area address from A to 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 nodes 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 nodes (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 routers to identify packets going to destinations outside of their area, which need to be forwarded to level 2 routers. Thus, in IS-IS routers perform as follows: * Level 1 intermediate systems route within an area based on the ID portion of the ISO address. Level 1 routers 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 router. * Level 2 intermediate systems 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 routers on the routing domain boundary that have advertised external address prefixes into the level 2 subdomain. A level 2 router may also be operating as a level 1 router in one area. A level 1 router will have the area portion of its address manually configured. It will refuse to become a neighbor with a router whose area addresses do not overlap its own area addresses. However, if a level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then the level 1 IS will accept the other IS as a level 1 neighbor. A level 2 router will accept another level 2 router as a neighbor, regardless of area address. However, if the area addresses do not overlap, the link would be considered by both routers to be level 2 Colella, Callon, Gardner & Rekhter [Page 10]
RFC 1629 NSAP Guidelines May 1994 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 routers in different routing domains. IS-IS provides an optional partition repair function. If a level 1 area becomes partitioned, this function, if implemented, allows the partition to be repaired via use of level 2 routes. IS-IS requires that the set of level 2 routers 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. Occasionally a single level 2 router may lose connectivity to the level 2 backbone. In this case the level 2 router will indicate in its level 1 routing packets that it is not "attached", thereby allowing level 1 routers in the area to route traffic for outside of the area to a different level 2 router. Level 1 routers therefore route traffic to destinations outside of their area only to level 2 routers which indicate in their level 1 routing packets that they are "attached". A host may autoconfigure the area portion of its address by extracting the area portion of a neighboring router's address. If this is the case, then a host will always accept a router as a neighbor. Since the standard does not specify that the host *must* autoconfigure its area address, a host may be pre-configured with an area address. Special treatment is necessary for broadcast subnetworks, such as LANs. This solves two sets of issues: (i) In the absence of special treatment, each router on the subnetwork would announce a link to every other router on the subnetwork, resulting in O(n-squared) links reported; (ii) Again, in the absence of special treatment, each router on the LAN would report the same identical list of end systems on the LAN, resulting in substantial duplication. These problems are avoided by use of a "pseudonode", which represents the LAN. Each router on the LAN reports that it has a link to the pseudonode (rather than reporting a link to every other router on the LAN). One of the routers on the LAN is elected "designated router". The designated router then sends out a Link State Packet (LSP) on behalf of the pseudonode, reporting links to all of the routers on the LAN. This reduces the potential n-squared links to n links. In addition, only the pseudonode LSP includes the list of end systems on the LAN, thereby eliminating the potential duplication. Colella, Callon, Gardner & Rekhter [Page 11]
RFC 1629 NSAP Guidelines May 1994 The IS-IS provides for optional Quality of Service (QOS) routing, based on throughput (the default metric), delay, expense, or residual error probability. IS-IS has a provision for authentication information to be carried in all IS-IS PDUs. Currently the only form of authentication which is defined is a simple password. A password may be associated with each link, each area, and with the level 2 subdomain. A router not in possession of the appropriate password(s) is prohibited from participating in the corresponding function (i.e., may not initialize a link, be a member of the area, or a member of the level 2 subdomain, respectively). Procedures are provided to allow graceful migration of passwords without disrupting operation of the routing protocol. The authentication functions are extensible so that a stronger, cryptographically-based security scheme may be added in an upwardly compatible fashion at a future date. 3.3. Overview of IDRP (ISO/IEC 10747) The Inter-Domain Routing Protocol (IDRP, ISO/IEC 10747), developed in ISO, provides routing for OSI environments. In particular, IDRP is designed to work in conjuction with CLNP, ES-IS, and IS-IS. This section briefly describes the manner in which IDRP operates. Consistent with the OSI Routing Framework [13], in IDRP the internetwork is partitioned into routing domains. IDRP places no restrictions on the inter-domain topology. A router that participates in IDRP is called a Boundary Intermediate System (BIS). Routing domains that participate in IDRP are not allowed to overlap - a BIS may belong to only one domain. A pair of BISs are called external neighbors if these BISs belong to different domains but share a common subnetwork (i.e., a BIS can reach its external neighbor in a single network layer hop). Two domains are said to be adjacent if they have BISs that are external neighbors of each other. A pair of BISs are called internal neighbors if these BISs belong to the same domain. In contrast with external neighbors, internal neighbors don't have to share a common subnetwork -- IDRP assumes that a BIS should be able to exchange Network Protocol Date Units (NPDUs) with any of its internal neighbors by relying solely on intra-domain routing procedures. IDRP governs the exchange of routing information between a pair of neighbors, either external or internal. IDRP is self-contained with respect to the exchange of information between external neighbors. Exchange of information between internal neighbors relies on Colella, Callon, Gardner & Rekhter [Page 12]
RFC 1629 NSAP Guidelines May 1994 additional support provided by intra-domain routing (unless internal neighbors share a common subnetwork). To facilitate routing information aggregation/abstraction, IDRP allows grouping of a set of connected domains into a Routing Domain Confederation (RDC). A given domain may belong to more than one RDC. There are no restrictions on how many RDCs a given domain may simultaneously belong to, and no preconditions on how RDCs should be formed -- RDCs may be either nested, or disjoint, or may overlap. One RDC is nested within another RDC if all members (RDs) of the former are also members of the latter, but not vice versa. Two RDCs overlap if they have members in common and also each has members that are not in the other. Two RDCs are disjoint if they have no members in common. Each domain participating in IDRP is assigned a unique Routing Domain Identifier (RDI). Syntactically an RDI is represented as an OSI network layer address. Each RDC is assigned a unique Routing Domain Confederation Identifier (RDCI). RDCIs are assigned out of the address space allocated for RDIs -- RDCIs and RDIs are syntactically indistinguishable. Procedures for assigning and managing RDIs and RDCIs are outside the scope of the protocol. However, since RDIs are syntactically nothing more than network layer addresses, and RDCIs are syntactically nothing more than RDIs, it is expected that RDI and RDCI assignment and management would be part of the network layer assignment and management procedures. Recommendations for RDI and RDCI assignment are provided in Section 6.5. IDRP requires a BIS to be preconfigured with the RDI of the domain to which the BIS belongs. If a BIS belongs to a domain that is a member of one or more RDCs, then the BIS has to be preconfigured with RDCIs of all the RDCs the domain is in, and the information about relations between the RDCs - nested or overlapped. IDRP doesn't assume or require any particular internal structure for the addresses. The protocol provides correct routing as long as the following guidelines are met: * End systems and intermediate systems may use any NSAP address or Network Entity Title (NET -- i.e., an NSAP address without the selector) that has been assigned under ISO 8348 [11] guidelines; * An NSAP prefix carried in the Network Layer Reachability Information (NLRI) field for a route originated by a BIS in a given routing domain should be associated with only that routing domain; that is, no system identified by the prefix should reside in a different routing domain; ambiguous routing may result if several routing domains originate routes whose Colella, Callon, Gardner & Rekhter [Page 13]
RFC 1629 NSAP Guidelines May 1994 NLRI field contain identical NSAP address prefixes, since this would imply that the same system(s) is simultaneously located in several routing domains; * Several different NSAP prefixes may be associated with a single routing domain which contains a mix of systems which use NSAP addresses assigned by several different addressing authorities. IDRP assumes that the above guidelines have been satisfied, but it contains no means to verify that this is so. Therefore, such verification is assumed to be the responsibility of the administrators of routing domains. IDRP provides mandatory support for data integrity and optional support for data origin authentication for all of its messages. Each message carries a 16-octet digital signature that is computed by applying the MD-4 algorithm (RFC 1320) to the context of the message itself. This signature provides support for data integrity. To support data origin authentication a BIS, when computing a digital signature of a message, may prepend and append additional information to the message. This information is not passed as part of the message but is known to the receiver. 3.3.1. Scaling Mechanisms in IDRP The ability to group domains in RDCs provides a simple, yet powerful mechanism for routing information aggregation and abstraction. It allows reduction of topological information by replacing a sequence of RDIs carried by the RD_PATH attribute with a single RDCI. It also allows reduction of the amount of information related to transit policies, since the policies can be expressed in terms of aggregates (RDCs), rather than individual components (RDs). It also allows simplification of route selection policies, since these policies can be expressed in terms of aggregates (RDCs) rather than individual components (RDs). Aggregation and abstraction of Network Layer Reachability Information (NLRI) is supported by the "route aggregation" mechanism of IDRP. This mechanism is complementary to the Routing Domain Confederations mechanism. Both mechanisms are intended to provide scalable routing via information reduction/abstraction. However, the two mechanisms are used for different purposes: route aggregation for aggregation and abstraction of routes (i.e., Network Layer Reachability Information), Routing Domain Confederations for aggregation and abstraction of topology and/or policy information. To provide maximum benefits, both mechanisms can be used together. This implies that address assignment that will facilitate route aggregation does not conflict with the ability to form RDCs, and vice versa; formation Colella, Callon, Gardner & Rekhter [Page 14]
RFC 1629 NSAP Guidelines May 1994 of RDCs should be done in a manner consistent with the address assignment needed for route aggregation. 3.4. Requirements of IS-IS and IDRP on NSAPs The preferred NSAP format for IS-IS is shown in Figure 1. A number of points should be noted from IS-IS: * The IDP is as specified in ISO 8348, the OSI network layer service specification [11]; * The high-order portion of the DSP (HO-DSP) is that portion of the DSP whose assignment, structure, and meaning are not constrained by IS-IS; * The area address (i.e., the concatenation of the IDP and the HO-DSP) must be globally unique. If the area address of an NSAP matches one of the area addresses of a router, it is in the router'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 method presented in RFC 1526 [18] may optionally be used to assure globally unique IDs; * 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. However, within a routing domain that conforms to IS-IS, 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 IS-IS 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 Colella, Callon, Gardner & Rekhter [Page 15]
RFC 1629 NSAP Guidelines May 1994 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 an appropriate "border" router, from which they will exit the domain). 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. 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 external destinations can be minimized. Efficient routing with IDRP similarly also requires minimization of the number of address prefixes needed to describe specific destinations. In other words, addresses need to be assigned with topological significance. This requirement is described in more detail in the following sections. 4. NSAPs and Routing 4.1. Routing Data Abstraction 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 processing time, memory requirements, and transmission bandwidth consumed in support of routing. This implies that address assignment must serve the needs of routing, in order for routing to scale to very large networks. While the notion of routing data abstraction may be applied to various types of routing information, this and the following sections primarily emphasize one particular type, namely reachability information. Reachability information describes the set of reachable destinations. Abstraction of reachability information 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. A balance between these two needs is necessary. Colella, Callon, Gardner & Rekhter [Page 16]
RFC 1629 NSAP Guidelines May 1994 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 [13] and routing protocols, the lowest boundary at which this can occur is the boundary between an area and the level 2 subdomain within a IS-IS routing domain. Data abstraction is designed into IS-IS at this boundary, since level 1 ISs are constrained to reporting only area addresses. Level 2 routing is based upon address prefixes. Level 2 routers (ISs) distribute, 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 routers 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 with other routing domains via IDRP. 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. Even larger numbers of routing domains are possible when each home, or each small company, becomes its own routing domain. This requires a greater degree of data abstraction beyond that which can be achieved at the "routing domain" level. Colella, Callon, Gardner & Rekhter [Page 17]
RFC 1629 NSAP Guidelines May 1994
RFC 1629 NSAP Guidelines May 1994 6.2.1. General NSAP Structure The general structure of a Network Address defined in ISO 8348 is further divided into: +-----------+-----------------------------------------+ | IDP | DSP | +-----+-----+-----------+-----------------------------+ | AFI | IDI | CDP | CDSP | +-----+-----+-----+-----+----------------+------+-----+ | AFI | IDI | CFI | CDI | RDAA | ID | SEL | +-----+-----+-----+-----+----------------+------+-----+ octets | 1 | 2 | 2..4 | 0..13 | 1..8 | 1 | +-----+-----+-----------+----------------+------+-----+ IDP Initial Domain Part AFI Authority and Format Identifier, two-decimal-digit, 38 for decimal abstract syntax of the DSP or 39 for binary abstract syntax of the DSP IDI Initial Domain Identifier, a three-decimal-digit country code, as defined in ISO 3166 DSP Domain Specific Part CDP Country Domain Part, 2..4 octets CFI Country Format Identifier, one digit CDI Country Domain Identifier, 3 to 7 digits, fills CDP to an octet boundary CDSP Country Domain Specific Part RDAA Routing Domain and Area Address ID System Identifier (1..8 octet) SEL NSAP Selector The total length of an NSAP can vary from 7 to 20 octets. 6.2.2. Structure of the Country Domain Part The CDP identifies an organization within a country and the CDSP is then available to that organization for further internal structuring as it wishes. Non-ambiguity of addresses is ensured by there being the NSO a single national body that allocates the CDPs. The CDP is further divided into CFI and CDI, where the CFI identifies the format of the CDI. The importance of this is that it enables several types of CDI to be assigned in parallel, corresponding to organizations with different requirements and giving different amounts of the total address space to them, and that it conveniently enables a substantial amount of address space to be reserved for future allocation. Colella, Callon, Gardner & Rekhter [Page 40]
RFC 1629 NSAP Guidelines May 1994 The possible structures of the CDP are as follows: CFI = /0 reserved CFI = /1 CDI = /aaa very large organizations or trade associations CFI = /2 CDI = /aaaaa organizations of intermediate size CFI = /3 CDI = /aaaaaaa small organizations and single users CFI = /4../F reserved Note: this uses the hexadecimal reference publication format defined in ISO 8348 of a solidus "/" followed by a string of hexadecimal digits. Each "a" represents a hexadecimal digit. Organizations are classified into large, medium and small for the purpose of address allocation, and one CFI is made available for each category of organization. This recommendation for CDP leaves space for the U.S. GOSIP Version 2 NSAP model (Appendix A.1) by the reserved CFI /8, nevertheless it is not recommended for use in the European Internet. 6.2.3. Structure of the Country Domain Specific Part The CDSP must have a structure (within the decimal digit or binary octet syntax selected by the AFI value 38 or 39) satisfying both the routing requirements (IS-IS) and the logical requirements of the organization identified (CFI + CDI). 6.3. Recommendations Specific to Other Parts of the Internet For the part of the Internet which is outside of the U.S. and Europe, it is recommended that the DSP format be structured hierarchically similarly to that specified within the U.S. and Europe 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.4. Recommendations for Multi-Homed Routing Domains Some routing domains will be attached to multiple providers within the same country, or to providers within multiple countries. We refer to these as "multi-homed" routing domains. Clearly the strict hierarchical model discussed above does not neatly handle such routing domains. Colella, Callon, Gardner & Rekhter [Page 41]
RFC 1629 NSAP Guidelines May 1994 There are several possible ways that these multi-homed routing domains may be handled. Each of these methods vary with respect to the amount of information that must be maintained for inter-domain routing and also with respect to the inter-domain routes. In addition, the organization that will bear the brunt of this cost varies with the possible solutions. For example, the solutions vary with respect to: * resources used within routers within the providers; * administrative cost on provider personnel; and, * difficulty of configuration of policy-based inter-domain routing information within subscriber routing domains. Also, the solution used may affect the actual routes which packets follow, and may effect the availability of backup routes when the primary route fails. For these reasons it is not possible to mandate a single solution for all situations. Rather, economic considerations will require a variety of solutions for different subscriber routing domains and providers. 6.5. Recommendations for RDI and RDCI assignment While RDIs and RDCIs need not be related to the set of addresses within the domains (confederations) they depict, for the sake of simplicity we recommend that RDIs and RDCIs be assigned based on the NSAP prefixes assigned to domains and confederations. A subscriber RD should use the NSAP prefix assigned to it as its RDI. A multihomed RD should use one of the NSAP prefixes assigned to it as its RDI. If a service provider forms a Routing Domain Confederation with some of its subscribers and the subscribers take their addresses out of the provider, then the NSAP prefix assigned to the provider should be used as the RDCI of the confederation. In this case the provider may use a longer NSAP prefix for its own RDIs. In all other cases a provider should use the address prefix that it uses for assigning addresses to systems within the provider as its RDI. 7. Security Considerations Security issues are not discussed in this memo (except for the discussion of IS-IS authentication in Section 3.2). Colella, Callon, Gardner & Rekhter [Page 42]
RFC 1629 NSAP Guidelines May 1994 8. Authors' Addresses Richard P. Colella National Institute of Standards & Technology Building 225/Room B217 Gaithersburg, MD 20899 Phone: (301) 975-3627 EMail: colella@nist.gov Ross Callon c/o Wellfleet Communications, Inc 2 Federal Street Billerica, MA 01821 Phone: (508) 436-3936 EMail: callon@wellfleet.com Ella P. Gardner The MITRE Corporation 7525 Colshire Drive McLean, VA 22102-3481 Phone: (703) 883-5826 EMail: epg@gateway.mitre.org Yakov Rekhter T.J. Watson Research Center, IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: (914) 945-3896 EMail: yakov@watson.ibm.com 9. Acknowledgments The authors would like to thank the members of the IETF OSI-NSAP Working Group and of RARE WG4 for the helpful suggestions made during the writing of this paper. We would also like to thank Radia Perlman of Novell, Marcel Wiget of SWITCH, and Cathy Wittbrodt of BARRnet for their ideas and help. Colella, Callon, Gardner & Rekhter [Page 43]
RFC 1629 NSAP Guidelines May 1994 10. References [1] ANSI, "American National Standard for the Structure and Semantics of the Domain-Specific Part (DSP) of the OSI Network Service Access Point (NSAP) Address", American National Standard X3.216- 1992 [2] Boland, T., "Government Open Systems Interconnection Profile Users' Guide Version 2 [DRAFT]", NIST Special Publication, National Institute of Standards and Technology, Computer Systems Laboratory, Gaithersburg, MD, June 1991. [3] GOSIP Advanced Requirements Group, "Government Open Systems Interconnection Profile (GOSIP) Version 2", Federal Information Processing Standard 146-1, U.S. Department of Commerce, National Institute of Standards and Technology, Gaithersburg, MD, April 1991 [4] Hemrick, C., "The OSI Network Layer Addressing Scheme, Its Implications, and Considerations for Implementation", NTIA Report 85186, U.S. Department of Commerce, National Telecommunications and Information Administration, 1985. [5] ISO, "Addendum to the Network Service Definition Covering Network Layer Addressing," RFC 941, ISO, April 1985. [6] ISO/IEC, "Codes for the Representation of Names of Countries", International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984. [7] ISO/IEC, "Data Interchange - Structures for the Identification of Organization", International Standard 6523, ISO/IEC JTC 1, Switzerland, 1984. [8] ISO/IEC, "Information Processing Systems - Open Systems Interconnection -- Basic Reference Model", International Standard 7498, ISO/IEC JTC 1, Switzerland, 1984. [9] ISO/IEC, "Protocol for Providing the Connectionless-mode Network Service", International Standard 8473, ISO/IEC JTC 1, Switzerland, 1986. [10] ISO/IEC, "End System to Intermediate System Routing Exchange Protocol for use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service", International Standard 9542, ISO/IEC JTC 1, Switzerland, 1987. Colella, Callon, Gardner & Rekhter [Page 44]
RFC 1629 NSAP Guidelines May 1994 [11] ISO/IEC, "Information Processing Systems -- Data Communications -- Network Service Definition", International Standard 8348, 1992 [12] ISO/IEC, "Information Processing Systems - OSI Reference Model - Part3: Naming and Addressing", Draft International Standard 7498-3, ISO/IEC JTC 1, Switzerland, March 1989. [13] ISO/IEC, "Information Technology - Telecommunications and Information Exchange Between Systems - OSI Routeing Framework", Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989. [14] ISO/IEC, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service (ISO 8473)", International Standard ISO/IEC 10589, 1992. [15] Loughheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)" RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991. [16] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to support Forwarding of ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1, Switzerland 1993. [17] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992. [18] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP Hosts", RFC 1526, Bellcore, September 1993. [19] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco, OARnet, September 1993. [20] ISO/IEC JTC1/SC6, "Addendum to ISO 9542 Covering Address Administration", N6273, March 1991. Colella, Callon, Gardner & Rekhter [Page 45]
RFC 1629 NSAP Guidelines May 1994 A. Administration of NSAPs NSAPs represent the endpoints of communication through the Network Layer and must be globally unique [4]. ISO 8348 defines the semantics of the NSAP and the abstract syntaxes in which the semantics of the Network address can be expressed [11]. The NSAP consists of the initial domain part (IDP) and the domain specific part (DSP). The initial domain part of the NSAP consists of an authority and format identifier (AFI) and an initial domain identifier (IDI). The AFI specifies the format of the IDI, the network addressing authority responsible for allocating values of the IDI, and the abstract syntax of the DSP. The IDI specifies the addressing subdomain from which values of the DSP are allocated and the network addressing authority responsible for allocating values of the DSP from that domain. The structure and semantics of the DSP are determined by the authority identified by the IDI. Figure 3 shows the NSAP address structure. +-----------+ | IDP | +-----+-----+-------------------------------------------------+ | AFI | IDI |<--------------------DSP------------------------>| +-----+-----+-------------------------------------------------+ IDP Initial Domain Part AFI Authority and Format Identifier IDI Initial Domain Identifier DSP Domain Specific Part Figure 3: NSAP address structure. The global network addressing domain consists of all the NSAP addresses in the OSI environment. Within that environment, seven second-level addressing domains and corresponding IDI formats are described in ISO 8348: * X.121 for public data networks * F.69 for telex * E.163 for the public switched telephone network numbers * E.164 for ISDN numbers * ISO Data Country Code (DCC), allocated according to ISO 3166 [6] Colella, Callon, Gardner & Rekhter [Page 46]
RFC 1629 NSAP Guidelines May 1994 * ISO International Code Designator (ICD), allocated according to ISO 6523 [7] * Local to accommodate the coexistence of OSI and non-OSI network addressing schemes. For OSI networks in the U.S., portions of the ICD subdomain are available for use through the U.S. Government, and the DCC subdomain is available for use through The American National Standards Institute (ANSI). The British Standards Institute is the registration authority for the ICD subdomain, and has registered four IDIs for the U.S. Government: those used for GOSIP, DoD, OSINET, and the OSI Implementors Workshop. ANSI, as the U.S. ISO Member Body, is the registration authority for the DCC domain in the United States. A.1 GOSIP Version 2 NSAPs GOSIP Version 2 makes available for government use an NSAP addressing subdomain with a corresponding address format as illustrated in Figure 2 in Section 4.2. The "47" signifies that it is based on the ICD format and uses a binary syntax for the DSP. The 0005 is an IDI value which has been assigned to the U.S. Government. Although GOSIP Version 2 NSAPs are intended primarily for U.S. Government use, requests from non-government and non-U.S. organizations will be considered on a case-by-case basis. The format for the DSP under ICD=0005 has been established by the National Institute of Standards and Technology (NIST), the authority for the ICD=0005 domain, in GOSIP Version 2 [3] (see Figure 2, Section 4.2). NIST has delegated the authority to register AA identifiers for GOSIP Version 2 NSAPs to the General Services Administration (GSA). ISO 8348 allows a maximum length of 20 octets for the NSAP address. The AFI of 47 occupies one octet, and the IDI of 0005 occupies two octets. The DSP is encoded as binary as indicated by the AFI of 47. One octet is allocated for a DSP Format Identifier, three octets for an Administrative Authority identifier, two octets for Routing Domain, two octets for Area, six octets for the System Identifier, and one octet for the NSAP selector. Note that two octets have been reserved to accommodate future growth and to provide additional flexibility for inter-domain routing. The last seven octets of the GOSIP NSAP format are structured in accordance with IS-IS [14], the intra-domain IS-IS routing protocol. The DSP Format Identifier (DFI) identifies the format of the remaining DSP structure and may be used in the future to identify additional DSP formats; the value 80h in the DFI identifies the GOSIP Version 2 NSAP structure. Colella, Callon, Gardner & Rekhter [Page 47]
RFC 1629 NSAP Guidelines May 1994 The Administrative Authority identifier names the administrative authority which is responsible for registration within its domain. The administrative authority may delegate the responsibilityfor registering areas to the routing domains, and the routing domains may delegate the authority to register System Identifiers to the areas. The main responsibility of a registration authority at any level of the addressing hierarchy is to assure that names of entities are unambiguous, i.e., no two entities have the same name. The registration authority is also responsible for advertising the names. A routing domain is a set of end systems and intermediate systems which operate according to the same routing procedures and is wholly contained within a single administrative domain. An area uniquely identifies a subdomain of the routing domain. The system identifier names a unique system within an area. The value of the system field may be a physical address (SNPA) or a logical value. Address resolution between the NSAP and the SNPA may be accomplished by an ES-IS protocol [10], locally administered tables, or mapping functions. The NSAP selector field identifies the end user of the network layer service, i.e., a transport layer entity. A.1.1 Application for Administrative Authority Identifiers The steps required for an agency to acquire an NSAP Administrative Authority identifier under ICD=0005 from GSA will be provided in the updated GOSIP users' guide for Version 2 [2] and are given below. Requests from non-government and non-U.S. organizations should originate from a senior official, such as a vice-president or chief operating officer. * Identify all end systems, intermediate systems, subnetworks, and their topological and administrative relationships. * Designate one individual (usually the agency head) within an agency to authorize all registration requests from that agency (NOTE: All agency requests must pass through this individual). * Send a letter on agency letterhead and signed by the agency head to GSA: Colella, Callon, Gardner & Rekhter [Page 48]
RFC 1629 NSAP Guidelines May 1994 Telecommunications Customer Requirements Office U.S. General Services Administration Information Resource Management Service Office of Telecommunications Services 18th and F Streets, N.W. Washington, DC 20405 Fax +1 202 208-5555 The letter should contain the following information: - Requestor's Name and Title, - Organization, - Postal Address, - Telephone and Fax Numbers, - Electronic Mail Address(es), and, - Reason Needed (one or two paragraphs explaining the intended use). * If accepted, GSA will send a return letter to the agency head indicating the NSAP Administrative Authority identifier as- signed,effective date of registration, and any other pertinent information. * If rejected, GSA will send a letter to the agency head explaining the reason for rejection. * Each Authority will administer its own subaddress space in accordance with the procedures set forth by the GSA in Section A.1.2. * The GSA will maintain, publicize, and disseminate the assigned values of Administrative Authority identifiers unless specifically requested by an agency not to do so. Colella, Callon, Gardner & Rekhter [Page 49]
RFC 1629 NSAP Guidelines May 1994 A.1.2 Guidelines for NSAP Assignment Recommendations which should be followed by an administrative authority in making NSAP assignments are given below. * The authority should determine the degree of structure of the DSP under its control. Further delegation of address assignment authority (resulting in additional levels of hierarchy in the NSAP) may be desired. * The authority should make sure that portions of NSAPs that it specifies are unique, current, and accurate. * The authority should ensure that procedures exist for disseminating NSAPs to routing domains and to areas within each routing domain. * The systems administrator must determine whether a logical or a physical address should be used in the System Identifier field (Figure 2, Section 4.2). An example of a physical address is a 48-bit MAC address; a logical address is merely a number that meets the uniqueness requirements for the System Identifier field, but bears no relationship to an address on a physical subnetwork. We recommend that IDs should be assigned to be globally unique, as made possible by the method described in [18]. * The network address itself contains information that may be used to aid routing, but does not contain a source route [12]. Information that enables next-hop determination based on NSAPs is gathered and maintained by each intermediate system through routing protocol exchanges. * GOSIP end systems and intermediate systems in federal agencies must be capable of routing information correctly to and from any subdomain defined by ISO 8348. * An agency may request the assignment of more than one Administrative Authority identifier. The particular use of each should be specified. A.2 Data Country Code NSAPs NSAPs from the Data Country Code (DCC) subdomain will also be common in the international Internet. ANS X3.216-1992 specifies the DSP structure under DCC=840 [1]. In the ANS, the DSP structure is identical to that specified in GOSIP Version 2, with the Colella, Callon, Gardner & Rekhter [Page 50]
RFC 1629 NSAP Guidelines May 1994 Administrative Authority identifier replaced by the numeric form of the ANSI-registered organization name, as shown in Figure 4. Referring to Figure 4, when the value of the AFI is 39, the IDI denotes an ISO DCC and the abstract syntax of the DSP is binary octets. The value of the IDI for the U.S. is 840, the three-digit numeric code for the United States under ISO 3166 [6]. The numeric form of organization name is analogous to the Administrative Authority identifier in the GOSIP Version 2 NSAP. <----IDP---> +-----+-----+----------------------------------------+ | AFI | IDI |<----------------------DSP------------->| +-----+-----+----------------------------------------+ | 39 | 840 | DFI |ORG | Rsvd | RD | Area | ID | SEL | +-----+-----+----------------------------------------+ octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | +-----+-----+----------------------------------------+ IDP Initial Domain Part AFI Authority and Format Identifier IDI Initial Domain Identifier DSP Domain Specific Part DFI DSP Format Identifier ORG Organization Name (numeric form) Rsvd Reserved RD Routing Domain Identifier Area Area Identifier ID System Identifier SEL NSAP Selector Figure 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3. A.2.1 Application for Numeric Organization Name The procedures for registration of numeric organization names in the U.S. have been defined and are operational. To register a numeric organization name, the applicant must submit a request for registration and the $1,000 (U.S.) fee to the registration authority, the American National Standards Institute (ANSI). ANSI will register a numeric value, along with the information supplied for registration, in the registration database. The registration information will be sent to the applicant within ten working days. The values for numeric organization names are assigned beginning at 113527 Colella, Callon, Gardner & Rekhter [Page 51]
RFC 1629 NSAP Guidelines May 1994 The application form for registering a numeric organization name may be obtained from the ANSI Registration Coordinator at the following address: Registration Coordinator American National Standards Institute 11 West 42nd Street New York, NY 10036 +1 212 642 4884 (tel) +1 212 398 0023 (fax) RFC822: mmaas@attmail.com X.400: G=michelle; S=maas; A=attmail; C=us Once an organization has registered with ANSI, it becomes a registration authority itself. In turn, it may delegate registration authority to routing domains, and these may make further delegations, for instance, from routing domains to areas. Again, the responsibilities of each Registration Authority are to assure that NSAPs within the domain are unambiguous and to advertise them as applicable. A.3 Summary of Administrative Requirements NSAPs must be globally unique, and an organization may assure this uniqueness for OSI addresses in two ways. The organization may apply to GSA for an Administrative Authority identifier. Although registration of Administrative Authority identifiers by GSA primarily serves U.S. Government agencies, requests for non-government and non-U.S. organizations will be considered on a case-by-case basis. Alternatively, the organization may apply to ANSI for a numeric organization name. In either case, the organization becomes the registration authority for its domain and can register NSAPs or delegate the authority to do so. In the case of GOSIP Version 2 NSAPs, the complete DSP structure is given in GOSIP Version 2. For ANSI DCC-based NSAPs, the DSP structure is specified in ANS X3.216-1992. The DSP structure is identical to that specified in GOSIP Version 2.



Back to RFC index

 

Associates:

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""