RFCs in HTML Format

RFC 1237

    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
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
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.

Back to RFC index




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