RFC 1237
Guidelines for OSI NSAP Allocation in the Internet
RFC 1237 🎀 Guidelines for OSI NSAP Allocation in the Internet
okay bestie, the title block first because it's giving important info 💅
- Network Working Group 🌸
- RFC number: 1237
- Title: Guidelines for OSI NSAP Allocation in the Internet
- Authors: Richard Colella (NIST), Ella Gardner (Mitre), and Ross Callon (DEC)
- Date: July 1991
- Category: IAB standards track protocol 🦋
- Obsoletes / Updates: no obsoletes or updates line up top, so this doc doesn't list any 🙈
Status of This Memo 📜
So this section is the official "what is this doc" bit. This RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 🔍. Distribution of this memo is unlimited ✨.
Abstract ✨
So the Internet is shifting toward a multi-protocol vibe, and OSI is joining the party 🎉. To make OSI work in the Internet, you need an OSI lower layers infrastructure. That infrastructure is made of the connectionless network protocol (CLNP) and supporting routing protocols 🛤️. You also need guidelines for how NSAP (network service access point) addresses get assigned 🏷️. This paper gives those guidelines for allocating NSAPs in the Internet 💅.
This doc is the authors' current best judgment for allocating NSAP addresses in the Internet 🧠. It's meant to guide the early rollout of OSI 8473 (Connectionless Network Layer Protocol) in the Internet, and to collect feedback 💌. The authors expect these guidelines to get refined, and the doc to get updated, based on what they learn during that early deployment 🔄.
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
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 . . . . . . 461 Introduction 🦋
The Internet is moving toward a multi-protocol environment that includes OSI. To support OSI there, you need an OSI lower layers infrastructure. That infrastructure is the connectionless network protocol (CLNP) [12] (see also RFC 994 [8]) plus supporting routing protocols. You also need guidelines for network service access point (NSAP) address assignment, and this paper gives those guidelines for allocating NSAPs in the Internet. NSAP and NSAP address are used interchangeably throughout this paper when referring to NSAP addresses 🏷️.
The rest of this paper is split into five major sections and an appendix 🗺️. Section 2 pins down the boundaries of the problem, and Section 3 gives background on OSI routing and what it means for NSAPs.
Section 4 digs into the specific relationship between NSAPs and routing, especially hierarchical routing and data abstraction 🌳. Section 5 applies those ideas to the Internet environment. Section 6 has the recommended guidelines for NSAP allocation in the Internet 📝.
Appendix A is a compendium of useful info on NSAP structure and allocation authorities 📚. It goes deep on the GOSIP Version 2 NSAP structure, and it describes the structure for U.S.-based DCC (Data Country Code) NSAPs 🇺🇸. It also has contact info 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 📇.
2 Scope 🌈
Okay so there are two aspects when we talk about OSI NSAP allocation in the Internet 👀. The first is the set of administrative requirements for getting and handing out NSAPs. The second is the technical side, which is mostly about 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 stuff is mainly routing 🧭. This paper assumes CLNP will be widely deployed in the Internet, and that CLNP traffic will normally be routed using the OSI ES-IS (end-system to intermediate system) routing protocol for point-to-point links and LANs [13] (see also RFC 995 [7]), plus the emerging intra-domain IS-IS protocol [17]. They also expect an inter-domain routing protocol similar to Border Gateway Protocol (BGP) [18] to show up 🙌.
These guidelines are meant for immediate deployment as CLNP becomes available in the Internet ⏰. This paper specifically doesn't tackle long-term research stuff, like complex policy-based routing requirements 🧪.
Right now, lots of routing domains (like corporate and campus networks) hook up to transit networks (like NSFNET regionals) through only one or a small number of carefully controlled access points 🚪. Addressing solutions that need big changes or constraints on the current topology aren't considered 🙅♀️.
The guidelines are mostly about 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;
- 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 leaf routing domains that are connected to more than one regional or backbone.
There are other aspects of NSAP allocation, both technical and administrative, that this paper doesn't cover 🙃. Topics not covered, or only mentioned 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);
- 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 📚
Here's some background that helps make sense of NSAP allocation 🧠. There's a brief look at OSI routing, then a review of the intra-domain protocol in enough detail to understand why NSAP allocation matters. Finally, the specific constraints that protocol places on NSAPs get listed 📋.
3.1 OSI Routing Standards 🚦
OSI splits 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).
So ES-IS is international standard ISO9542 [13], approved in 1987 🎉. It's available in vendor products and planned for the next release of Berkeley UNIX (UNIX is a trademark of AT&T). It's also cited in GOSIP Version 2 [4], which became effective in April 1991 for all applicable federal procurements, and it becomes mandatory eighteen months later, in 1992 📅.
Intra-domain IS-IS hit draft international standard (DIS) status within ISO in November, 1990, as DIS10589 [17]. It's reasonable to expect final text for the intra-domain IS-IS standard to be available by mid-1991 ⏳.
There are two candidate proposals for OSI inter-domain routing: ECMA TR/50 [3] and Border Router Protocol (BRP) [19], which is 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, the group responsible for the Network layer of the ISO Reference Model [11 ]. X3S3.3 is the ANSI counterpart to WG2, and it folded features of TR/50 into BRP and submitted that as alternate base text at the WG2 meeting in October, 1990 📨. It's currently out for ISO Member Body comment ⏳. The proposed protocol is called the Inter-domain Routing Protocol (IDRP) [20] 💖.
This paper looks at the technical implications of NSAP assignment, assuming ES-IS, intra-domain IS-IS, and IDRP routing are deployed to support CLNP 🌈✨
3.2 Overview of DIS10589 🔍
Okay bestie, so the IS-IS intra-domain routing protocol, DIS10589, was developed in ISO to do routing for OSI environments 🌸 It's built to work hand in hand with CLNP and ES-IS, and this section is a quick tour of how it actually works 🍓
The internetwork gets chopped up into routing domains 💅 A routing domain is a bunch of ESs and ISs that run common routing protocols and are under the control of a single administration. A routing domain may be a corporate network, a university campus network, a regional network, or a similar contiguous network run by one administrative organization 🏫 Network management draws the borders by setting some links to be exterior, aka inter-domain, links 🚧 And here's the tea: if a link is marked exterior, no DIS10589 routing messages get sent on that link at all 🙈
ISO doesn't have a standard for inter-domain routing yet (that's routing between separate autonomous routing domains) 😭 So for now DIS10589 uses manual configuration. An inter-domain link is statically configured with the set of address prefixes reachable over it, plus the method for reaching them. That could be the DTE address to dial, or the fact that the DTE address should be extracted from the OSI NSAP address 📞
Next up is 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 the ISs and ESs in it. They do not know the identity of ISs or destinations outside their area, though. So they forward all traffic for destinations outside their area to a level 2 IS within their area 🧚
Level 2 ISs know the level 2 topology and which addresses are reachable via each level 2 IS 🦋 All the level 2 ISs in a routing domain form the level 2 subdomain, which is basically a backbone for interconnecting the areas. Level 2 ISs don't 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 outside their routing domain 💜
Now the addresses 🎀 As illustrated in Figure 1, ISO addresses are subdivided into the Initial Domain Part (IDP) and the Domain Specific Part (DSP), as specified in ISO8348/Addendum 2, the OSI network layer addressing standard [14] (also RFC 941 [6]). The IDP is the part ISO standardizes. It specifies the format and the authority in charge of assigning the rest of the address. The DSP is assigned by whatever addressing authority the IDP points to (see Appendix A for more on the top-level NSAP addressing authorities). DIS10589 further splits the DSP into a High Order Part of DSP (HO-DSP), a system identifier (ID), and an NSAP selector (SEL). The HO-DSP can use any format the IDP's authority wants 🫶 Together, [IDP,HO-DSP] identifies an area within a routing domain and, implicitly, the routing domain containing the area. That combo is therefore called 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 can be one to eight octets long, but it must have a single known length in any particular routing domain 🍓 Each router is configured to know what length its domain uses. The SEL field is always one octet. So each router can identify the ID and SEL fields as a known number of trailing octets of the NSAP, and the area address is whatever remains after those get truncated 💀
Usually, every node in an area has the same area address. But sometimes an area might have multiple addresses, and there are a few reasons why:
- Changing the address of an area. The most graceful way to move an area from address A to address B is to first let it have both A and B. Once every node in the area has been updated to recognize both, the ESs can be modified one by one to forget address A 🔄
- Merging areas A and B. You add knowledge of address B into the A partition one by one, and similarly add knowledge of address A into the B partition 🤝
- Partitioning area C into two areas, A and B (A might equal C, in which case this turns into removing a portion of an area). You first introduce knowledge of address A into the appropriate ESs (the ones destined to become area A), and knowledge of address B into the appropriate nodes. Then you remove knowledge of address C one by one 🪓
Since the addressing explicitly identifies the area, it's very easy for level 1 ISs to spot packets going to destinations outside their area, which need to go up to level 2 ISs. So in DIS10589, the two types of ISs route like this:
- Level 1 intermediate systems: these route based on the ID portion of the ISO address, and they route within an area. They recognize from the destination address whether the destination is inside the area. If so, they route toward it. If not, they route to the nearest level 2 IS.
- Level 2 intermediate systems: these route based on address prefixes, preferring the longest matching prefix and preferring internal routes over external routes. They route toward areas without regard to the internal structure of an area, or toward 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 its area portion manually configured 🛠️ It will refuse to become a neighbor with an IS whose area addresses don't overlap its own. However, if a level 1 IS has area addresses A, B, and C and a neighbor has area addresses B and D, 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 don't overlap, both ISs consider the link to be level 2 only, and only level 2 routing packets flow on that 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, lets the partition be repaired by using level 2 routes 🩹
DIS10589 requires that the set of level 2 ISs be connected 🔗 If the level 2 backbone becomes partitioned, there's no provision for using level 1 links to repair it 😬
In unusual cases, a single level 2 IS may lose connectivity to the level 2 backbone. When that happens, the level 2 IS indicates in its level 1 routing packets that it is not attached. This lets level 1 ISs in the area route traffic for destinations outside the area to a different level 2 IS. So level 1 ISs only send traffic for destinations outside their area to level 2 ISs that 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 it does, the 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 instead be pre-configured with an area address. In that case, the end system ignores 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 ✨
- 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 the 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 the sake of efficient operation of the IS-IS routing protocol, a few observations can 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) 🚪✨
okay so for destinations inside the domain, level 2 routing treats the whole area address (basically all of the NSAP address except the ID and SEL fields) as one flat field 💅. That means how efficient level 2 routing is inside the domain only depends on how many areas the domain has, and how many area addresses each area gets (anywhere from one up to a maximum of three) 🧚
For destinations outside the domain, level 2 routing goes by address prefixes 🗺️. And bestie, there's a huge win here: if you can keep the number of prefixes needed to describe a set of destinations as small as possible, you cut down the amount of routing info you have to carry 🦋
4. NSAPs and Routing ✨
okay, so before you pick an administrative policy for NSAP assignment, you have to understand the technical consequences 🎀. Hierarchical routing exists to get some level of routing data abstraction (aka summarization), so less CPU, memory, and transmission bandwidth gets eaten up by routing 💖. This basically dictates that NSAPs be assigned according to topological routing structures. But administrative assignment follows organizational or political lines 🏛️, and those lines may not match the topology, so the two needs can clash. Finding a balance between them is the whole game 🫶
Routing data abstraction happens at the boundary between hierarchically arranged topological routing structures 🌸. A lower element reports summary routing info up to its parent(s). In the current OSI routing framework [16] and routing protocols, the lowest boundary where this can happen is the boundary between an area and the level 2 subdomain within a DIS10589 routing domain. DIS10589 builds abstraction in at this boundary, because level 1 ISs are only allowed to report area addresses, and one area is allowed a max of three area addresses (This is an architectural constant in DIS10589. See [17], Clause 7.2.11 and Table 2 of Clause 7.5.1). It's giving structured 💅
Level 2 routing runs on address prefixes 🧁. Level 2 ISs spread the area addresses of the level 1 areas they're attached to (plus any manually configured reachable address prefixes) throughout the level 2 subdomain 📣. They compute next-hop forwarding info for every advertised address prefix, and level 2 routing picks the longest advertised address prefix that matches the destination address 🎯
At routing domain boundaries, prefix info gets exchanged with other routing domains (statically or dynamically) 💌. If the area addresses inside a routing domain all come from distinct NSAP assignment authorities (so no abstraction at all), the boundary prefix info is just an enumerated list of every area address 📋
But if the routing domain "owns" an address prefix and assigns area addresses based on it, boundary routing info can get squished into that single prefix 🫧. That's a massive data reduction, and it scales way better than the uncoordinated area addresses from the paragraph above 📈
If routing domains are hooked up in a more-or-less random (non-hierarchical) way, it's pretty likely that no further abstraction can happen 🙈. Since routing domains wouldn't have a defined hierarchical relationship, admins couldn't assign area addresses out of a common prefix for abstraction. The result is flat inter-domain routing, where every routing domain needs explicit knowledge of every other routing domain it routes to. That works fine for small and medium internets, up to a size somewhat larger than the current IP Internet 👍, but it does not scale to very large internets 💀. We expect growth toward an international Internet with tens or hundreds of thousands of routing domains in the U.S. alone 🇺🇸, which needs more data abstraction than you can get 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 ✨. So there's the chance for a group of routing domains to each be assigned an address prefix out of a shorter prefix given to another routing domain whose job is to interconnect the group 🧚. Each member of the group now "owns" its (somewhat longer) prefix, and assigns its area addresses out of it 💜
The simplest case is a set of routing domains that are all attached to just one regional (or backbone) domain, and that use the regional for all external (inter-domain) traffic 🌈. A small address prefix gets assigned to the regional, which then hands out slightly longer prefixes (based on the regional's prefix) to each routing domain it interconnects. When the regional tells other routing domains what it can reach, it can abbreviate the reachability info for a large number of routing domains as a single prefix 🫶. That's a ton of hierarchical abbreviation, and it can really improve the scalability of inter-domain routing ⭐
Clearly this approach is recursive and can carry on through several iterations 🔁. Routing domains at any "level" of the hierarchy can use their prefix as the basis for later suballocations, as long as the NSAP addresses stay within the overall length and structure constraints. The GOSIP Version 2 NSAP structure (covered later in this section) allows for multiple levels of routing hierarchy 🎀
Here's the plot twist 🥲: the number of nodes at each lower level of a hierarchy tends to grow exponentially 📈. So the greatest gains in data abstraction happen at the leaves, and the gains drop off significantly at each higher level 📉. The law of diminishing returns suggests that at some point, data abstraction stops being beneficial. Figuring out that point takes careful thought about how many routing domains are expected at each level over a given period of time, compared to how many routing domains and address prefixes dynamic inter-domain routing protocols can conveniently and efficiently handle 🧠
There's a balance to strike 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) is 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 identifies 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) 🇺🇸
[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 allocating AA values to administrations 🧁. So the fields from the AFI to the AA, inclusive, make up 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.ANSI is currently working on a proposal for an American National Standard (ANS) for the DSP of the NSAP address space it administers 🇺🇸. It will provide an identical DSP structure to GOSIP Version 2. The ANSI format only differs from the one illustrated above 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 for NSAP administration are independent of whether you use a GOSIP Version 2 or an ANSI value for the NSAP assignment 💖
Similarly, although other countries may use 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 on top of the ones DIS10589 requires: RD and Area 🧩. These exist so NSAPs can be allocated along topological boundaries for more data abstraction. Administrations assign RD identifiers underneath their unique address prefix (the reserved field is left to accommodate future growth and to give extra flexibility for inter-domain routing) 🎀. Routing domains allocate Area identifiers from their unique prefix. So the result is:
AFI+IDI+DFI+AA= administration prefix,administration prefix(+Rsvd)+RD= routing domain prefix, and,routing domain prefix+Area= area address.
This gives summarization of all area addresses within a routing domain into one prefix 🌟. If the AA identifier is also given topological significance (on top of administrative significance), you get an additional level of data abstraction, which the next section digs into 🔍
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 🧚
(Alternatively, a site may choose to operate as an area within a regional 🌸. However, in that 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 runs a level 2 subdomain as well as one or more level 1 areas ✨)
Okay so, given that mapping, where should address administration and allocation happen if we want both administrative decentralization and data abstraction? 🧠 There are three possibilities:
- at the area,
- at the leaf routing domain, and,
- at the transit routing domain (TRD).
Leaf routing domains are basically sites, and their main job is intra-domain routing 🏠. Transit routing domains exist to carry transit (aka inter-domain) traffic, so backbones and regionals are TRDs 🚆.
The biggest burden for transmitting and operating on routing info sits at the top of the hierarchy, where the info piles up 📚💀. On the Internet, for example, regionals have to manage the set of network numbers for every network reachable through them. Traffic for other networks usually just gets routed up to the backbone. The backbones, though, need to know the network numbers for all attached regionals and their networks. It's a lot 😭.
Generally, abstracting routing info at a given level is way more valuable the higher up you go. The admin doing the abstracting gets little direct benefit, since they still have to keep routing info for each attached topological routing structure individually 🤷♀️.
Here's a juicy example. Say a site is deciding whether to get an NSAP address prefix from an AA value issued by GSA (so the first four octets come from the GOSIP space), or from an RD value issued by its regional (so the first seven octets belong to that regional). If the site and the attached regional only think about their own self-interest, neither has much reason to pick one approach over the other 🤔. The site has to use one prefix or another, and where the prefix came from barely changes routing efficiency inside the site. The regional still has to keep info about each attached site in order to route, no matter how much the prefixes have in common 💅.
But there's a difference once the regional starts distributing routing info to backbones and other regionals. In the first case, the regional can't aggregate the site's address into its own prefix. The address has to be explicitly listed in routing exchanges, which is extra work for backbones and other regionals that have to exchange and maintain that info 😩.
In the second case, each other regional and backbone sees one address prefix for the regional, and that prefix covers the new site. No extra routing info is needed to identify the new site's prefix. So the advantages mostly go to other regionals and backbones that keep routing info about this site and regional 🎀.
You could look at this with a supplier/consumer model: the higher level (e.g., a backbone) is the supplier of routing services, and the lower level (e.g., an attached regional) is the consumer. The price for services is based on what it costs to provide them, and the overhead of managing a big table of addresses for routing to an attached topological entity adds to that cost 💸.
BUT the Internet isn't a market economy! 🙅♀️ Efficient operation is based on cooperation 🫶. The guidelines below describe reasonable ways to manage 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's built into DIS10589 💀. For example, say that within a routing domain, three areas take their area addresses out of:
- 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's no harm in having the different areas in that 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, especially on the other domains that need to maintain routes to this domain 😬. There's no common prefix that can represent these NSAPs, so no summarization can happen at the routing domain boundary. When this routing domain advertises addresses to other routing domains, an enumerated list has to be used, made up of the three area addresses.
This situation is roughly analogous to how routing info gets spread around the TCP/IP Internet 🌐. Areas correspond roughly to networks, and area addresses correspond roughly to network numbers. Letting areas within a routing domain take their NSAPs from unrelated authorities leads to 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 its client leaf routing domains, and for a backbone, this gets summed across all attached regionals. Although this situation is just barely acceptable in the current Internet, as the Internet grows it'll quickly become intractable 💔. A greater degree of hierarchical information reduction is necessary to allow continued growth in the Internet 🚀.
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 👑. Giving each leaf routing domain (that is, each site) 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 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 made up of this prefix followed by an Area identifier. The prefix represents the summary of reachable addresses within the routing domain 🧚.
There's 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) that provides connectivity among the areas. The routing domain represents the only path between an area and the rest of the internetwork. It's reasonable for this relationship to also extend to 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 🚆
There are two kinds of transit routing domains to consider, backbones and regionals. Each is discussed separately below.
5.3.1. Regionals 🌸
It's interesting to consider whether regional routing domains should be the common authority for assigning NSAPs from a unique prefix to the leaf routing domains they serve 🤓. The benefits from data abstraction are smaller than in the case of leaf routing domains, and the additional degree of data abstraction this provides isn't necessary in the short term. However, in the long term, the number of routing domains in the Internet will grow to the point that routing on the basis of a flat field of routing domains becomes infeasible. It'll 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 means regionals advertise a small fraction of the number of address prefixes to backbones that they'd need if they enumerated the individual prefixes of the leaf routing domains. That's a huge 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 offers connectivity as the service, priced according to its costs of operation. That includes the "price" of obtaining service from one or more backbones. In general, backbones want to handle as few address prefixes as possible to keep costs low. In the Internet environment, which doesn't 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 regionals adopting NSAP administration 💖.
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 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, say 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=kkkand a unique prefix for NIST of
AFI=47, IDI=0005, DFI=80h, AA=kkk, (Rsvd=0), RD=jjj.Okay so, a similar setup can be built using NSAPs allocated under DCC=840 🇺🇸✨. Here a regional applies to ANSI for an ORG identifier, and that identifier does the same job the AA identifier does in GOSIP 💅. ANSI is currently leaning toward an NSAP structure that's identical to GOSIP Version 2 (see Section A.2 if you want the deets) 🎀.
5.3.2 Backbones ✨
Ngl, there's not a strong case for regionals to grab their address space out of a backbone's NSAP space 🙈. The payoff in routing data abstraction is kinda small. There are tens of regionals today, and an order of magnitude increase wouldn't be a crazy burden on the backbones 📈. Plus, as time goes on, we can expect more direct interconnection: regionals linking straight to each other, leaf routing domains plugged right into backbones, and international links landing directly on regionals 🌏. Once that's happening, the line between regionals and backbones could get super blurry 🌫️.
Another thing that makes backbone-derived NSAPs a no-go is that backbones and their attached regionals are seen as independent 🦋. Regionals can take their long-haul service from one or more backbones, or switch backbones if someone else offers a more cost-effective service (basically how people switch long-distance phone carriers 📞). Deriving NSAPs from the backbone just doesn't match that relationship 💀.
5.4 Multi-homed Routing Domains 🗺️
Section 5.3 covered ways to allocate NSAP addresses based on regional or backbone connectivity. That gets you a ton of information reduction for routing domains attached to a single TRD 🧠. These routing domains can pick their NSAP addresses from a space the regional allocated to them, and then the regional can announce the addresses it can reach to other regionals and backbones using one prefix that covers a huge number of NSAPs across multiple routing domains 🎀.
But it gets messier for routing domains attached to multiple regionals and backbones 😭. These "multi-homed" routing domains could be single-site campuses and companies attached to multiple backbones, big organizations attached to different regionals at different locations in the same country, or multinational organizations attached to backbones in a bunch of countries worldwide 🌍. There are a few possible ways to handle them 🤔.
Solution one: assign addresses to each multi-homed organization independently from the regionals and backbones it's attached to 🧁. Each organization can base its NSAP assignments on a single prefix and summarize every NSAP reachable within it using that one prefix ✨. The downside is that since the organization's NSAP address has no relationship to any particular TRD, the TRDs it's attached to will need to advertise its prefix to other regionals and backbones 📣. Other regionals and backbones (potentially worldwide) will then need to maintain an explicit entry for that organization in their routing tables 📋.
For example 🙌: Mega Big International Incorporated (MBII) is a very large U.S.-wide company with a fully interconnected internal network, and it's assigned a single AA value under the U.S. GOSIP Version 2 address space 🇺🇸. Outside the U.S., a single entry may be maintained in routing tables for all U.S. GOSIP addresses 🌐. Inside the U.S., though, every backbone and regional will need to maintain a separate address entry for MBII 😵. And if MBII is actually an international corporation, it may be necessary for every backbone worldwide to keep a separate entry for MBII, even the backbones MBII isn't attached to 😬. Honestly, that may be acceptable if there are only a few multi-homed routing domains, but it would put an unacceptable load on routers within backbones if all organizations chose address assignments like this 🫠. This solution may not scale to internets with many hundreds of thousands of multi-homed organizations 📉.
Solution two: each multi-homed organization gets a separate NSAP space for each connection to a TRD, and each area within its routing domain(s) gets a single address prefix based on the closest interconnection point 📍. For example, if MBII had connections to two regionals in the U.S. (one east coast, one west coast), plus three connections to national backbones in Europe and one in the far east, then MBII may make use of six different address prefixes 🧩. Each area within MBII would be assigned a single address prefix based on the nearest connection 🗺️.
For external routing of traffic from outside MBII to a destination inside MBII, this approach works similarly to treating MBII as six separate organizations 🎭. For internal routing, or for routing traffic from inside MBII to a destination outside of MBII, this approach works the same as solution one 🔁.
If we assume that incoming traffic (coming from outside MBII, with a destination within MBII) is always going to enter via the nearest point to the destination 📍, then each TRD that has a connection to MBII needs to announce to other TRDs the ability to reach only those parts of MBII whose address is taken from its own address space 📣. This means no additional routing information has to be exchanged between TRDs, so there's a smaller load on the inter-domain routing tables TRDs maintain compared to solution one 🥳. That makes this solution scale better to extremely large internets containing very large numbers of multi-homed organizations 🚀.
One problem with solution two is that backup routes to multi-homed organizations are not automatically maintained 😤. With solution one, each TRD, when announcing the ability to reach MBII, specifies that it can reach all of the NSAPs within MBII 💯. With solution two, each TRD announces that it can reach all the NSAPs based on its own address prefix, which only includes some of the NSAPs within MBII 🧐. If the connection between MBII and one particular TRD were severed, the NSAPs within MBII with addresses based on that TRD would become unreachable via inter-domain routing 💔. The impact can be reduced somewhat by keeping additional information within routing tables, but that reduces the scaling advantage of solution two 📉.
Solution two also requires that when external connectivity changes, internal addresses also change 🔄.
Also, heads up: this approach and the previous one will tend to make packets take different routes 🛣️. With solution one, packets from outside MBII destined for within MBII will tend to enter via the point closest to the source, which will therefore tend to maximize the load on the networks internal to MBII 📶. With solution two, packets from outside destined for within MBII will tend to enter via the point closest to the destination, which will tend to minimize the load on the networks within MBII and maximize the load on the TRDs 💪.
These solutions also have different effects on policies 🎀. Say country "X" has a law that traffic from a source within country X to a destination within country X must at all times stay entirely within the country 🇽. With solution one, it isn't possible to determine from the destination address whether or not the destination is within the country 🫥. With solution two, a separate address may be assigned to those NSAPs that are within country X, so routing policies can be followed 🗺️. Similarly, say "Little Small Company" (LSC) has a policy that its packets may never be sent to a destination within MBII 🚫. With either solution, the routers within LSC may be configured to discard any traffic with a destination in MBII's address space 🗑️. But with solution one this requires one entry, while with solution two it requires many entries and may be impossible as a practical matter 😩.
A third approach is to assign each multi-homed organization a single address prefix, based on one of its connections to a TRD 🎯. Other TRDs to which the multi-homed organization is attached maintain a routing table entry for the organization, but they're extremely selective about which other TRDs are told of this route 🤫. This approach produces a single "default" routing entry that all TRDs know how to reach (since presumably all TRDs maintain routes to each other), while providing more direct routing in some cases 🛤️.
There's at least one situation where this third approach is particularly appropriate 🧶. Suppose a special interest group of organizations has deployed its own backbone. For example, let's suppose the U.S. National Widget Manufacturers and Researchers have set up a U.S.-wide backbone, used by corporations that manufacture widgets and certain universities known for their widget research 🔧. We can expect the organizations in the widget group to run their internal networks as separate routing domains, and most of them will also be attached to other TRDs (since most of the organizations involved in widget manufacture and research are also involved in other activities) 🏭. So many or most of the organizations in the widget group are dual-homed, with one attachment for widget-associated communications and the other for other types of communications 👯. Let's also assume the total number of organizations in the widget group is small enough that it's reasonable to maintain a routing table containing one entry per organization, but that they're spread throughout a larger internet with many millions of (mostly not widget-associated) routing domains 🌌💜
Okay so the third approach is giving "we all look out for each other" 🫶. Each multi-homed org in the widget group would grab an address assignment based on its other attachment(s) to TRDs (the ones NOT tied to the widget group) 🎀. The widget backbone would need to keep routes to the routing domains of all the member orgs, and every member of the widget group would need a table of routes to the other members through the widget backbone 💅. BUT here's the tea: the widget backbone doesn't tell other general worldwide TRDs what addresses it can reach, since it's not meant for outside orgs. So that big pile of routing prefixes only has to live in a limited number of places ✨. The addresses given to the member orgs would hand out a "default route" through each member's other attachments to TRDs, while letting widget-group traffic take the preferred path 🌸.
Now, solution number four 🦋 is all about giving a particular address prefix to routing domains that are attached to precisely two (or more) specific routing domains. Picture this: two regionals, "SouthNorthNet" and "NorthSouthNet", have a ton of customers in common (aka a large number of routing domains are attached to both) 👀. Instead of getting two address prefixes (like two AA values assigned under the GOSIP address space), these organizations could obtain three prefixes 💜. Routing domains attached to NorthSouthNet but not SouthNorthNet get an address assignment based on one prefix. Routing domains attached to SouthNorthNet but not NorthSouthNet get an address based on the second prefix. And the routing domains multi-homed to both of these networks get an address based on the third prefix 🎀. Each of these two TRDs would then advertise two prefixes to other TRDs: one for leaf routing domains attached to it only, and one for leaf routing domains attached to both 🌈.
This fourth solution is likely to be a big deal once use of public data networks becomes more common 😭. In particular, at some point in the future a substantial percentage of all routing domains will probably be attached to public data networks. When that happens, nearly all government-sponsored networks (such as some current NSFNET regionals) may have a set of customers that overlaps a lot with the public networks 🙈.
So there are a number of possible solutions to the problem of assigning NSAP addresses to multi-homed routing domains 💖. Each one comes with very different advantages and disadvantages. Each solution puts a different real (i.e., financial) cost on the multi-homed organizations, and on the TRDs (including the ones the multi-homed organizations aren't attached to) 💸.
Also, most of these solutions highlight the need for each TRD to develop a policy on whether and under what conditions it will accept addresses that are not based on its own address prefix, and how those non-local addresses will be treated 🧚. For example, a somewhat conservative policy might be that non-local NSAP prefixes get accepted from any attached leaf RD, but are not advertised to other TRDs 🫣. A less conservative policy could have a TRD accept those non-local prefixes and agree to exchange them with a defined set of other TRDs. That set could be an a priori group of TRDs that have something in common, like geographical location, or the result of an agreement specific to the requesting leaf RD 🌸. Either way, various policies involve real costs to TRDs, and those costs may be reflected in the policies themselves 💅.
5.5. Private Links ✨
Everything up to this point has been about how NSAP addresses and routing work between routing domains over transit routing domains. Each transit routing domain interconnects a large number of routing domains and offers a more-or-less public service 🌐.
BUT there may also be a large number of private point-to-point links that interconnect two private routing domains 🔐. In many cases, these private point-to-point links may be limited to forwarding packets directly between the two private routing domains 🎀.
Let's say the XYZ corporation does a lot of business with MBII 💼. XYZ and MBII may contract with a carrier to provide a private link between the two corporations. This link may only be used for packets whose source is within one of the two corporations, and whose destination is within the other one 🤝. Now suppose the point-to-point link is connected between a single router (router X) within the XYZ corporation and a single router (router M) within MBII 🦋. That means router X needs to be configured to know which addresses can be reached over this link (specifically, all addresses reachable in MBII). In the same way, router M needs to be configured to know which addresses can be reached over this link (specifically, all addresses reachable in XYZ Corporation) 📝.
The big takeaway here is that private links like this may be ignored for the purpose of NSAP allocation, and they do not pose a problem for routing 💖. Why? Because the routing information associated with private links is not propagated throughout the internet, so it doesn't need to be collapsed into a TRD's prefix 🙌.
Back to our example. Let's suppose the XYZ corporation has a single connection to an NSFNET regional, and has therefore received an address allocation from the space administered by that regional 🏢. Meanwhile, MBII is an international corporation with connections to six different backbones or regionals, and has chosen the second solution from Section 5.4. So MBII has obtained six different address allocations 🌍. In this case, all addresses reachable in the XYZ Corporation can be described by a single address prefix. That means router M only needs to be configured with a single address prefix to represent the addresses reachable over this point-to-point link 🎯. All addresses reachable in MBII can be described by six address prefixes, which means router X needs to be configured with six address prefixes to represent the addresses reachable over the point-to-point link 🧮.
In some cases, these private point-to-point links may be permitted to forward traffic for a small number of other routing domains, like closely affiliated organizations 🫶. This will increase the configuration requirements a little. However, as long as the number of organizations using the link is relatively small, this still does not represent a significant problem 👍.
Note that the relationship between routing and NSAP addressing described in the other sections of this paper is concerned with scaling problems caused by large, essentially public transit routing domains that interconnect a large number of routing domains 📈. For the purpose of NSAP allocation, though, private point-to-point links that interconnect only a small number of private routing domains don't pose a problem, and may be ignored 🙈. For example, a single leaf routing domain with a single connection to a "public" backbone (e.g., the NSFNET), plus a number of private point-to-point links to other leaf routing domains, can be treated as if it were single-homed to the backbone for the purpose of NSAP address allocation 🌸.
5.6. Zero-Homed Routing Domains 🌙
Right now, a very large number of organizations have internal communications networks that aren't connected to any external network 🏠. These organizations may still have a number of private point-to-point links that they use to talk with other organizations 🔗. They don't participate in global routing, but they're totally satisfied with reachability to the organizations they've set up private links with 💅. These are called zero-homed routing domains 🦋.
Zero-homed routing domains can be thought of as the degenerate case of routing domains with private links, which we just covered in the previous section. They don't pose a problem for inter-domain routing 🙌. The routing information exchanged across the private links sees very limited distribution, usually only reaching the RD at the other end of the link. So there are no address abstraction requirements beyond the ones already inherent in the address prefixes exchanged across the private link ✨.
Here's the important part 🚨: zero-homed routing domains need to use valid globally unique NSAP addresses. Picture this: the zero-homed routing domain is connected through a private link to an RD, and that RD participates in an internet that subscribes to the global OSI addressing plan (i.e., Addendum 2 to ISO8348). That RD has to be able to tell apart the zero-homed routing domain's NSAPs from any other NSAPs it may need to route to 😱. The only way to guarantee that is if the zero-homed routing domain uses globally unique NSAPs 💜.
5.7. Transition Issues 🦋
Allocating NSAP addresses based on connectivity to TRDs is super important for scaling inter-domain routing to an internet containing millions of routing domains 🌐. But here's the catch: this kind of topology-based address allocation also means that a change in topology may result in a change of address 😬.
This need to allow for changes in addresses is a natural, inevitable consequence of routing data abstraction 🧠. The basic idea of routing data abstraction is that there's some correspondence between the address and where a system (a routing domain, area, or end system) is located 📍. So if the system moves, in some cases the address will have to change too. If it were possible to change the connectivity between routing domains without changing the addresses, then it would clearly be necessary to keep track of where each of those routing domains is located on an individual basis 🗂️.
In the short term, because of the rapid growth and increased commercialization of the Internet, the topology may be relatively volatile 📈. That means planning for address transition is very important 🫣. Luckily, there are a number of steps that can be taken to ease the effort required for address transition 🎀. A complete description of address transition issues is outside the scope of this paper, so this section just gives a very brief outline of some transition issues 💅.
Also, the possible requirement to transition addresses based on changes in topology means it's valuable to anticipate future topology changes before finalizing an address allocation plan 🔮. For example, a routing domain that is initially single-homed but expects to become multi-homed in the future may find it advantageous to assign NSAP addresses based on the anticipated future topology 👑✨.
Okay so, bestie, in general it's not practical to switch NSAP addresses over in one instant "change the address at midnight" moment 🙈. You need a gradual transition where both the old and the new addresses stay valid for a limited period of time ✨. During that window, end systems in the routing domain accept both old and new addresses, and both old and new addresses must result in correct routing of packets to the destination 💖.
Provision for transition is already built into DIS10589 🎀. As we'll see in Section 3, DIS10589 lets you assign multiple addresses to each area, specifically to make transition easier 🦋.
OSI also has autoconfiguration for area addresses 🧚. OSI end systems can figure out their area addresses automatically by watching the ISO9542 IS-Hello packets that routers transmit 👀. If the ID portion of the address uses IEEE style "stamped in PROM at birth" identifiers, then an end system can reconfigure its entire NSAP address automatically, with no manual intervention needed 🤯. However, routers will still need manual address reconfiguration 😤.
During the transition period, it's important that packets using the old address still get forwarded correctly, even when the topology has changed 🌸. This is made possible by "best match" inter-domain routing 💅.
For example, say the XYZ Corporation was previously connected only to the NorthSouthNet NSFNET regional 🏫. XYZ therefore went to the NorthSouthNet administration and got a routing domain assignment based on the AA value assigned to the NorthSouthNet regional under the GOSIP address space. But then, for a variety of reasons, XYZ decided to end its association with NorthSouthNet and connect directly to the NewCommercialNet public data network instead 🙅♀️. So XYZ now has a new address assignment under the ANSI address assigned to NewCommercialNet. The old address would seem to imply that traffic for XYZ should be routed to NorthSouthNet, which no longer has any direct connection with XYZ Corporation. Awkward! 💀
If the old TRD (NorthSouthNet) and the new TRD (NewCommercialNet) are adjacent and cooperative, then this transition is easy to pull off 🥰. Packets routed to XYZ using the old address assignment could go to NorthSouthNet, which would directly forward them to NewCommercialNet, which would in turn forward them to XYZ Corporation. In this case, only NorthSouthNet and NewCommercialNet need to be aware that the old address refers to a destination which is no longer directly attached to NorthSouthNet.
If the old TRD and the new TRD are not adjacent, the situation gets a bit more complex, but there are still several possible ways to forward traffic correctly 🧩.
If the old TRD and the new TRD are themselves connected by other cooperative transit routing domains, then those intermediate domains may agree to forward traffic for XYZ correctly. For example, suppose NorthSouthNet and NewCommercialNet aren't directly connected, but they're both directly connected to the NSFNET backbone 🌐. In this case, all three of NorthSouthNet, NewCommercialNet, and the NSFNET backbone would need to maintain a special entry for XYZ Corporation, so that traffic to XYZ using the old address allocation gets forwarded via NewCommercialNet. Other routing domains, however, wouldn't need to know about XYZ's new location 🙌.
Suppose the old TRD and the new TRD are separated by a non-cooperative routing domain, or by a long path of routing domains. In this case, the old TRD could encapsulate traffic to XYZ Corporation in order to deliver those packets to the correct backbone 📦.
Also, locations that do a significant amount of business with XYZ could have a specific entry added to their routing tables to make sure routing to XYZ is optimal ✨. For example, suppose another commercial backbone "OldCommercialNet" has a large number of customers who exchange traffic with XYZ Corporation, and that this third TRD is directly connected to both NorthSouthNet and NewCommercialNet. In this case, OldCommercialNet will keep its single entry in its routing tables for other traffic destined for NorthSouthNet, but it may choose to add one more specific entry so packets sent to XYZ Corporation's old address are routed correctly 💜.
Whichever method is used to ease the address transition, the goal is that the knowledge tying XYZ to its old address, which is held throughout the global internet, eventually gets replaced with the new information 🔄. Expect this to take weeks or months, and it will happen through the distributed directory system 🗂️. Discussion of the directory, along with other address transition techniques such as automatically informing the source of a changed address, is outside the scope of this paper.
6 Recommendations ✨
We anticipate that the current exponential growth of the Internet will continue or accelerate for the foreseeable future 📈. We also anticipate a rapid internationalization of the Internet 🌍. Routing's ability to scale depends on data abstraction based on hierarchical NSAP addresses, so as OSI is introduced into the Internet, it's essential to choose a hierarchical structure for NSAP addresses with great care 🧠.
It's in the best interests of the internetworking community to keep the cost of operations as low as possible where it can be done 💸. For NSAP allocation, this again means that routing data abstraction must be encouraged 🫶.
For data abstraction to be possible, NSAP addresses have to be assigned in a way that matches the actual physical topology of the Internet 🗺️. For example, where organizational and administrative boundaries aren't related to the actual network topology, address assignment based on those organizational boundaries is not recommended 🙅♀️.
The intra-domain IS-IS routing protocol keeps information abstraction at two levels: systems are grouped into areas, and areas are interconnected to form a routing domain 🪆. For zero-homed and single-homed routing domains (which are expected to remain zero-homed or single-homed), we recommend that the NSAP addresses assigned for OSI use within a single routing domain use a single address prefix assigned to that domain. Specifically, this lets the set of all NSAP addresses reachable within a single domain be fully described by a single prefix 🎯.
We anticipate that the total number of routing domains on a worldwide OSI Internet will be great enough that additional levels of hierarchical data abstraction beyond the routing domain level will be necessary 📚.
In most cases, network topology is closely related to national boundaries. For example, network connectivity will often be greater within a single country than between countries 🏳️🌈. So it's appropriate to make specific recommendations based on national boundaries, with the understanding that there may be specific situations where these general recommendations need to be modified 💅.
6.1 Recommendations Specific to U.S. Parts of the Internet 🇺🇸
NSAP addresses for use within the U.S. portion of the Internet are expected to be based primarily on two address prefixes: the IDP format used by NIST for GOSIP Version 2, and the DCC=840 format defined by ANSI 📮.
We anticipate that, in the U.S., public interconnectivity between private routing domains will be provided by a diverse set of TRDs, including (but not necessarily limited to):
- the NSFNET backbone;
- a number of NSFNET regional networks; and,
- a number of commercial Public Data Networks.
These networks are also not expected to be interconnected in a strictly hierarchical manner. For example, there is expected to be direct connectivity between NSFNET regionals, and all three of these types of networks may have direct international connections 🌉.
However, the total number of such TRDs is expected to remain small enough (for the foreseeable future) to allow addressing of this set of TRDs via a flat address space 🥞. These TRDs will be used to interconnect a wide variety of routing domains, each of which may comprise a single corporation, part of a corporation, a university campus, a government agency, or another organizational unit 🏢.
In addition, some private corporations may be expected to use dedicated private TRDs for communication within their own corporation 🔐.
We anticipate that the great majority of routing domains will be attached to only one of the TRDs. This will permit hierarchical address abbreviation based on TRD. We therefore strongly recommend that addresses be assigned hierarchically, based on address prefixes assigned to individual TRDs 🌳.
For the GOSIP address format, this implies that Administrative Authority (AA) identifiers should be assigned to all TRDs (explicitly including the NSFNET backbone, the NSFNET regionals, and other major government backbones). Leaf routing domains connected to a single TRD should be assigned a Routing Domain (RD) value from the space assigned to that TRD 🍰.
We recommend that all TRDs explicitly be involved in address administration for those leaf routing domains that are single-homed to them. This offers a valuable service to their customers, and it will also greatly reduce the resources (including human and network resources) needed for that TRD to take part in inter-domain routing 🤝.
Each TRD should develop a policy on whether and under what conditions to accept addresses that are not based on its own address prefix, and on how such non-local addresses will be treated. Policies should reflect the cost associated with implementing them 🧾.
We recommend that a similar hierarchical model be used for NSAP addresses using the DCC-based address format. The structure for DCC=840-based NSAPs is provided in Section A.2 📐.
For routing domains that aren't attached to any publically-available TRD, there isn't the same urgent need for hierarchical address abbreviation. We therefore don't make any additional recommendations for such "isolated" routing domains, except to note that there is no technical reason to rule out assigning GOSIP AA identifier values or ANSI organization identifiers to them 🏝️. Where such domains connect to other domains by private point-to-point links, and those links are used solely for routing between the two domains they interconnect, no additional technical problems for address abbreviation are caused by the link, so no specific additional recommendations are necessary 🔗.
6.2 Recommendations Specific to Non-U.S. Parts of the Internet 🦋
For the part of the Internet outside the U.S., the rec is to structure the DSP similarly to what GOSIP Version 2 does 💅, no matter whether your addresses are DCC or ICD format 🌸
And to keep NSAPs at national boundaries aggregating into as few prefixes as possible 🦋, we also recommend assigning NSAPs to routing domains based on each routing domain's connectivity to a national Internet backbone ✨
6.3. Recommendations for Multi-Homed Routing Domains
Some routing domains are gonna be attached to multiple TRDs in the same country, or to TRDs in multiple different countries 🌍 We call these "multi-homed" routing domains 💜 Real talk, the strict hierarchical model we just talked about doesn't neatly handle them 😭
There are several ways these multi-homed routing domains can be handled 🧚 Each method varies in how much information has to be maintained for inter-domain routing, and also in terms of the inter-domain routes. Plus, the organization that ends up bearing the brunt of the cost changes depending on the solution 💅 For example, the solutions vary with respect to:
- resources used within routers within the TRDs;
- administrative cost on TRD personnel; and,
- difficulty of configuration of policy-based inter-domain routing information within leaf routing domains.
Also, the solution you pick can affect the actual routes packets follow, and it may affect the availability of backup routes when the primary route fails 🙈
For these reasons, it's not possible to mandate a single solution for all situations 🎀 Instead, economic considerations will require a variety of solutions for different routing domains, regionals, and backbones 💖
7. Security Considerations ✨
Okay, the big security drama? Security issues are not discussed in this memo 💀 Totally serious, bestie: this doc doesn't cover them at all, so don't go hunting for a security section here 🔒
8. Authors' Addresses 🎀
Meet the people behind this doc 🫶 First up, Richard P. Colella:
Richard P. Colella
National Institute of Standards & Technology
Building 225/Room B217
Gaithersburg, MD 20899
Phone: (301) 975-3627
EMail: colella@osi3.ncsl.nist.govNext, EllaP. Gardner:
EllaP. Gardner
The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102
Phone: (703) 883-5826
EMail: epg@gateway.mitre.orgAnd last but definitely not least, Ross Callon:
Ross Callon
c/o Digital Equipment Corporation, 1-2/A19
550 King Street
Littleton, MA 01460-1289
Phone: (508) 486-5009
Email: Callon@bigfut.enet.dec.com9. Acknowledgments 🫶
The authors wanna give a huge shoutout to the members of the IETF OSI-NSAP Working Group 💖 for the helpful suggestions they made while this paper was being written ✨
A. Administration of NSAPs 🌈
NSAPs are the endpoints of communication through the Network Layer, and they must be globally unique [5] 🔥 Addendum 2 to ISO8348 defines the semantics of the NSAP and the abstract syntaxes in which the semantics of the Network address can be expressed [14] 🤓
The NSAP consists of the initial domain part (IDP) and the domain specific part (DSP). The initial domain part of the NSAP consists of an authority and format identifier (AFI) and an initial domain identifier (IDI). The AFI specifies the format of the IDI, the network addressing authority responsible for allocating values of the IDI, and the abstract syntax of the DSP. The IDI specifies the addressing subdomain from which values of the DSP are allocated and the network addressing authority responsible for allocating values of the DSP from that domain. The structure and semantics of the DSP are determined by the authority identified by the IDI. Figure 3 shows the NSAP address structure.
_______________
!_____IDP_____!________________________________
!__AFI_!_IDI__!______________DSP______________!
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
Figure 3: NSAP address structure.The global network addressing domain consists of all the NSAP addresses in the OSI environment. Within that environment, seven second-level addressing domains and corresponding IDI formats are described in ISO8348/Addendum 2:
- X.121 for public data networks
- F.69 for telex
- E.163 for the public switched telephone network numbers
- E.164 for ISDN numbers
- ISO Data Country Code (DCC), allocated according to ISO3166 [9]
- 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 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. (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 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.
- 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-5555The 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 assigned, effective date of registration, and any other pertinent information.
- If rejected, GSA will send a letter to the agency head explaining the reason for rejection.
- Each Authority will administer its own subaddress space in accordance with the procedures set forth by the GSA in Section A.1.2.
- The GSA will maintain, publicize, and disseminate the assigned values of Administrative Authority identifiers unless specifically requested by an agency not to do so.
A.1.2. Guidelines for NSAP Assignment 🧚
Recommendations which should be followed by an administrative authority in making NSAP assignments are given below.
- The authority should determine the degree of structure of the DSP under its control. Further delegation of address assignment authority (resulting in additional levels of hierarchy in the NSAP) may be desired.
- bestie, the authority should make sure the portions of NSAPs it specifies are unique, current, and accurate 💅 stale or duplicate data is NOT it 🙈
- the authority should ensure that procedures exist for disseminating NSAPs to routing domains and to areas within each routing domain 📣✨
- the systems administrator must figure out whether a logical or a physical address should go in the System Identifier field (Figure2, page 16) 🧚 an example of a physical address is a 48-bit MAC address. a logical address is just a number that meets the uniqueness requirements for the System Identifier field, but it has no relationship to an address on a physical subnetwork 🎀
- the network address itself contains no routing information [15] 🦋 info that lets next-hop determination be based on NSAPs gets 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 Administrative Authority identifier. the particular use of each should be specified 🌈
A.2 Data Country Code NSAPs
okay so NSAPs from the Data Country Code (DCC) subdomain are gonna be super common on the international Internet 🌍 rn there's a draft proposed American National Standard (dpANS) in the U.S. for the DSP structure under DCC=840 [1]. after an upcoming ANSI X3 Committee ballot, the dpANS will be distributed for public comment 📬
in the dpANS, the DSP structure is identical to the one specified in GOSIP Version 2, except the Administrative Authority identifier gets replaced by the numeric form of the ANSI-registered organization name, as shown in Figure 4 💖
looking at Figure 4, when the AFI is 39, the IDI denotes an ISO DCC and the abstract syntax of the DSP is binary octets. 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 SelectorFigure 4: NSAP format for DCC=840 as proposed in ANSI X3S3.3. ✨
A.2.1 Application for Numeric Organization Name
the registration procedures for numeric organization names in the U.S. are defined and operational 🎉 to register one, the applicant has to submit a request for registration and the $1,000 (U.S.) fee to the registration authority, the American National Standards Institute (ANSI) 💸 ANSI registers a numeric value, along with the info supplied for registration, in the registration database. the registration info gets sent to the applicant within ten working days 📮 numeric organization names are assigned beginning at 113527.
the application form for registering a numeric organization name can be grabbed 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 registers with ANSI, it becomes a registration authority itself 👑 it can then delegate registration authority to routing domains, and those can make further delegations, for instance from routing domains to areas. again, each Registration Authority is responsible for making sure the NSAPs within its domain are unambiguous and for advertising them as applicable 📣
A.3 Summary of Administrative Requirements
NSAPs must be globally unique, and an organization can make that happen for OSI addresses in two ways 🔥 the first is applying to GSA for an Administrative Authority identifier. registration of those by GSA mainly serves U.S. Government agencies, but requests from non-Government and non-U.S. organizations get considered case by case 🧐 the second is applying to ANSI for a numeric organization name. either way, the organization becomes the registration authority for its domain and can register NSAPs or delegate that authority to do so 💜
for GOSIP Version 2 NSAPs, the complete DSP structure is given in GOSIP Version 2. for ANSI DCC-based NSAPs, there's a draft proposed American National Standard that specifies the DSP structure under DCC=840. the dpANS specifies a DSP structure that is identical to the one 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.
[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 Interconnection - 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 Provision 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 Addressing. 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 Protocol for Providing the Connectionless-mode Network Service (ISO 8473). Draft International Standard 10589, ISO/IEC JTC 1, Switzerland, November 1990.
[18] K. Loughheed and Y. Rekhter. A Border Gateway Protocol (BGP). RFC 1105, Network Working Group, 1989.
[19] K. Loughheed and Y. Rekhter. A Border Router Protocol(BRP). Draft, Network Working Group, February 1990.
[20] ASC X3S3.3. Intermediate System to Intermediate System Inter-Domain Routeing Exchange Protocol. Working Document 90-216, ANSI, New York, July 1990. 🦋
📦 where this page comes from
- ietf: rfc1237 1991-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms