RFC 1629
Guidelines for OSI NSAP Allocation in the Internet
Guidelines for OSI NSAP Allocation in the Internet 🎀
Part 1 of 13 💖
Okay bestie, this is RFC 1629, and it's basically the guide for handing out NSAP addresses on the Internet 💅 It's from the Network Working Group and dated May 1994. It's a Standards Track doc, so it's official, and it's giving "we're shaping how CLNP lives on the Internet" energy ✨
The authors are a whole squad 🫶 R. Colella (NIST), R. Callon (Wellfleet), E. Gardner (Mitre), and Y. Rekhter (T.J. Watson Research Center, IBM Corp.). It obsoletes RFC 1237, and there's no Updates line in the header, so it doesn't update anything else 🌸
Status of this Memo 🌈
This is an Internet standards track protocol for the whole Internet community, and they're literally asking you to discuss it and send suggestions for making it better 💬
For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚
And distribution of this memo is unlimited, so share away 🦋
Abstract 💜
CLNP is actively being deployed on the Internet right now 🚀 It's super useful for carrying OSI and DECnet(tm) traffic 🍓 On top of that, CLNP got proposed as a possible IPng candidate, which could be a long-term fix for IP address exhaustion 😭
Also required as part of the CLNP setup are guidelines for network service access point (NSAP) address assignment. And this paper is where those guidelines live 💖
These guidelines were the foundation for the first deployment of CLNP on the Internet, and they've proven seriously valuable for helping CLNP routing scale AND for address administration 👑
Table of Contents 🧚
Here's the full map so you know where we're headed 🗺️
Section 1. Introduction ............................... 4
Section 2. Scope ...................................... 5
Section 3. Background ................................. 7
Section 3.1 OSI Routing Standards ..................... 7
Section 3.2 Overview of IS-IS (ISO/IEC 10589) ......... 8
Section 3.3 Overview of IDRP (ISO/IEC 10747) .......... 12
Section 3.3.1 Scaling Mechanisms in IDRP .............. 14
Section 3.4 Requirements of IS-IS and IDRP on NSAPs ... 15
Section 4. NSAPs and Routing .......................... 16
Section 4.1 Routing Data Abstraction .................. 16
Section 4.2 NSAP Administration and Efficiency ........ 19
Section 5. NSAP Administration and Routing in the In-
ternet ........................................... 21
Section 5.1 Administration at the Area ................ 23
Section 5.2 Administration at the Subscriber Routing
Domain ........................................... 24
Section 5.3 Administration at the Provider Routing
Domain ........................................... 24
Section 5.3.1 Direct Service Providers ................ 25
Section 5.3.2 Indirect Providers ...................... 26
Section 5.4 Multi-homed Routing Domains ............... 26
Section 5.5 Private Links ............................. 31
Section 5.6 Zero-Homed Routing Domains ................ 33
Section 5.7 Address Transition Issues ................. 33
Section 6. Recommendations ............................ 36
Section 6.1 Recommendations Specific to U.S. Parts of
the Internet ..................................... 37
Section 6.2 Recommendations Specific to European Parts
of the Internet .................................. 39
Section 6.2.1 General NSAP Structure .................. 40
Section 6.2.2 Structure of the Country Domain Part .... 40
Section 6.2.3 Structure of the Country Domain
Specific Part .................................... 41
Section 6.3 Recommendations Specific to Other Parts of
the Internet ..................................... 41
Section 6.4 Recommendations for Multi-Homed Routing
Domains .......................................... 41
Section 6.5 Recommendations for RDI and RDCI assign-
ment ............................................. 42
Section 7. Security Considerations .................... 42
Section 8. Authors' Addresses ......................... 43
Section 9. Acknowledgments ............................ 43
Section 10. References ................................ 44
Section A. Administration of NSAPs .................... 46
Section A.1 GOSIP Version 2 NSAPs .................... 47
Section A.1.1 Application for Administrative Authority
Identifiers ...................................... 48
Section A.1.2 Guidelines for NSAP Assignment ......... 50
Section A.2 Data Country Code NSAPs .................. 50
Section A.2.1 Application for Numeric Organization
Name ............................................. 51
Section A.3 Summary of Administrative Requirements .. 521. Introduction ✨
So the Internet is moving toward being multi-protocol, and CLNP is one of the protocols joining the party 🎉 To support CLNP on the Internet, you need an OSI lower layers infrastructure. That infrastructure is made of the connectionless network protocol (CLNP) [9] plus supporting routing protocols. You also need guidelines for NSAP address assignment (network service access point, you know the drill), and this paper is those guidelines 💅
Quick note: NSAP and NSAP address get used interchangeably all the way through, so don't panic when you see both 🙈
The guidelines here are pretty similar to the ones proposed for IP address allocation with CIDR (RFC 1519 [19]) 👯 The big difference is address size. CIDR uses 4 octets and CLNP uses 20 octets. Those bigger NSAP addresses give way more flexibility and scalability 🦋
The rest of the paper is split into five major sections plus an appendix 📚 Section 2 draws the boundaries of the problem, and Section 3 is the background on OSI routing and what it means for NSAP addresses.
Section 4 gets into how NSAP addresses and routing relate, especially hierarchical routing and data abstraction 🧠 Section 5 takes all of that and applies it to the Internet. Section 6 holds the recommended guidelines for NSAP allocation on the Internet, including ones for the U.S. and European parts, plus general recommendations for any part of the Internet 🌍
The Appendix is basically a handy cheat sheet of NSAP structure and who's in charge of allocating them 📝 It digs into the GOSIP Version 2 NSAP structure and describes the structure for U.S.-based DCC (Data Country Code) NSAPs. It also gives contact info for the registration authorities in the U.S.: the General Services Administration (GSA) for GOSIP and the American National Standards Institute (ANSI) for DCC-based NSAPs, respectively 💼
Quick tea on the older version: this one obsoletes RFC 1237 🫖 The changes are minor and mostly editorial, babe. The OSI routing standards descriptions in Section 3 got updated to match where those standards are now, and there's a brand new description of the OSI Interdomain Routing Protocol (IDRP) 🆕 Section 6 also picked up European recommendations, plus recommendations for Routing Domain Identifiers and Routing Domain Confederation Identifiers, which IDRP needs to operate 🌸
2. Scope ✨
okay so bestie, who's in charge of the hosts and the transmission and switching gear that make up the global Internet? Not one single boss 💅 It's split across a bunch of different administrative authorities, which is giving group project energy 🫶. For this doc, a network service provider (or just provider) is an org that's in the business of selling datagram switching services to customers 🎀. Orgs that are only customers, meaning they don't provide datagram services to other orgs, are called network service subscribers (or simply subscribers) 🌸.
In today's Internet, subscribers (like campus and corporate site networks) hook up to providers (like regionals, commercial providers, and government backbones) at only one or a small number of carefully controlled access points 🦋. For the OSI NSAP allocation stuff in this paper, providers are treated as a mesh with no fixed hierarchy 🕸️ main character energy 👑. Addressing solutions that need big changes to, or constraints on, the current topology are not considered in this paper 🙈.
There are two aspects to care about when talking about OSI NSAP allocation in the Internet 💖. First, the admin requirements for getting and handing out NSAP addresses. Second, the technical side, which is mostly about routing, both inside a routing domain (intra-domain routing) and between routing domains (inter-domain routing) 🔥. This paper focuses on the technical issues 💜.
Those technical issues are mainly about routing 🧚. This paper assumes CLNP will be widely deployed in the Internet, and that routing of CLNP traffic will normally be based on the OSI end-system to intermediate system routing protocol (ES-IS) [10], the intra-domain IS-IS protocol [14], and the inter-domain routing protocol (IDRP) [16] ✨. Down the line, the OSI routing architecture is expected to get upgrades for multicast, resource reservation, and other advanced services 🚀. The addressing requirements for those future services are outside the scope of this document 💅.
The guidelines here have been the basis for the initial deployment of CLNP in the Internet, and they've proven very valuable both for scaling CLNP routing and for address administration 😭🔥.
The guidelines in this paper are mostly aimed at the large-scale division of NSAP address allocation in the Internet 🍓. Topics covered:
- Arranging parts of the NSAP so the IS-IS routing protocol works efficiently 🎀;
- Benefits of some topological information in NSAPs for cutting routing protocol overhead, especially overhead on inter-domain routing (IDRP) 💜;
- The expected need for extra levels of hierarchy in Internet addressing to support network growth and use, plus using the Routing Domain Confederation mechanism of IDRP to support those extra levels 🌈;
- The recommended mapping between Internet topological entities (service providers and service subscribers) and OSI addressing and routing components like areas, domains and confederations 🗺️;
- The recommended division of NSAP address assignment authority between service providers and service subscribers 👑;
- Background on admin procedures for registering admin authorities just below the national level (GOSIP administrative authorities and ANSI organization identifiers) 📚; and,
- Choosing the high-order portion of the NSAP in subscriber routing domains that connect to more than one service provider 💖.
Heads up 🙈: 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:
- Identifying specific administrative domains in the Internet 🗺️;
- Policy or mechanisms for making registered information known to third parties (like the entity an NSAP or a portion of the NSAP address space was allocated to) 🤫;
- 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 for deciding on a particular topology or internal addressing plan is not 🙃; and,
- Procedures for assigning the System Identifier (ID) portion of the NSAP. A method for assignment of System IDs is presented in [18] 📖.
3. Background 📚
Some background info is included in this section, and it's super helpful for understanding the issues in NSAP allocation 🧠. There's a brief discussion of OSI routing, followed by a review of the intra-domain and inter-domain protocols in enough detail to understand the issues involved in NSAP allocation. Finally, the specific constraints that the routing protocols place on NSAPs are listed 📝.
3.1. OSI Routing Standards 🔥
OSI splits the routing problem into three parts ✂️:
- routing exchanges between hosts (aka end systems or ESs) and routers (aka intermediate systems or ISs) (ES-IS);
- routing exchanges between routers in the same routing domain (intra-domain IS-IS); and,
- routing among routing domains (inter-domain IS-IS).
ES-IS (international standard ISO 9542) reached international standard (IS) status within ISO in 1987 📅. Intra-domain IS-IS hit IS status within ISO in 1992 🙌. The Inter-Domain Routing Protocol (IDRP) reached IS status within ISO in October 1993 🎉. CLNP, ES-IS, and IS-IS are all widely available in vendor products and have been deployed in the Internet for several years 💅. IDRP is currently being implemented in vendor products ⭐.
This paper examines the technical implications of NSAP assignment under the assumption that ES-IS, intra-domain IS-IS, and IDRP routing are deployed to support CLNP 💖.
3.2. Overview of ISIS (ISO/IEC 10589) 🦋
Okay bestie, let's talk about the IS-IS intra-domain routing protocol, ISO/IEC 10589 💅. It's the one that handles routing for OSI environments, and it's built to work together with CLNP, ES-IS, and IDRP 🫶. This section is a quick vibe check on how IS-IS actually operates ✨.
So in IS-IS, the internetwork gets split up into routing domains 🌸. A routing domain is a collection of ESs and ISs that run common routing protocols and sit under the control of one single administration. (Throughout this paper, "domain" and "routing domain" are used interchangeably, so don't get confused 🙈.) Typically, a routing domain MAY consist of a corporate network, a university campus network, a regional network, a backbone, or a similar contiguous network under control of a single administrative organization 🎓. The edges of these domains get drawn by network management, who mark some links as exterior, or inter-domain, links 👑. If a link is marked as exterior, no intra-domain IS-IS routing messages are sent on that link 🚫.
IS-IS routing makes use of two-level hierarchical routing 💜. A routing domain gets subdivided into areas (also known as level 1 subdomains). Level 1 routers know the topology in their area, including all routers and hosts. However, level 1 routers do not know the identity of routers or destinations outside of their area. Level 1 routers forward all traffic for destinations outside of their area to a level 2 router within their area 🧚.
Similarly, level 2 routers know the level 2 topology and know which addresses are reachable via each level 2 router. The set of all level 2 routers in a routing domain are known as the level 2 subdomain, which can be thought of as a backbone for interconnecting the areas 🌈. Level 2 routers do not need to know the topology within any level 1 area, except to the extent that a level 2 router MAY also be a level 1 router within a single area. Only level 2 routers can exchange data packets or routing information directly with routers located outside of their routing domain 🔥.
NSAP addresses are flexible, variable length addresses that allow for multi-level hierarchical address assignment 🌸. That flexibility is what lets them tackle two huge problems at the same time 😭: (i) how to administer a worldwide address space; and (ii) how to assign addresses in a way that makes routing scale well in a worldwide Internet 👑.
As illustrated in Figure 1, ISO addresses are subdivided into the Initial Domain Part (IDP) and the Domain Specific Part (DSP). The IDP is the part which is standardized by ISO, and it 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). It is expected that the authority specified by the IDP MAY further sub-divide the DSP, and MAY assign sub-authorities responsible for parts of the DSP 🧁.
<----IDP---> <----------------------DSP---------------------------->
<-----------HO-DSP------------>
+-----+-----+-------------------------------+--------------+-------+
| AFI | IDI |Contents assigned by authority identified in IDI field|
+-----+-----+-------------------------------+--------------+-------+
<----------------Area Address--------------> <-----ID-----> <-SEL->
IDP Initial Domain Part
AFI Authority and Format Identifier
IDI Initial Domain Identifier
DSP Domain Specific Part
HO-DSP High-order DSP
ID System Identifier
SEL NSAP Selector
Figure 1: OSI Hierarchical Address Structure.For routing purposes, IS-IS splits ISO addresses into the area address, the system identifier (ID), and the NSAP selector (SEL) 🧩. The area address identifies both the routing domain and the area within that routing domain. Generally, the area address corresponds to the IDP plus a high-order part of the DSP (HO-DSP).
The ID field MAY be from one to eight octets in length, but it 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. So each router can identify the ID and SEL fields as a known number of trailing octets of the NSAP address 🙌. The area address is then just the remainder of the address (after truncation of the ID and SEL fields). It is therefore not necessary for the area address to have any particular length -- the length of the area address could vary between different area addresses in a given routing domain 🦋.
Usually, all nodes in an area have the same area address. However, sometimes an area might have multiple addresses. There are several reasons why that might be allowed 💅:
- It might be desirable to change the address of an area. The most graceful way to change an area address from A to B is to first allow it to have both addresses A and B, and then, after all nodes in the area have been modified to recognize both addresses, modify the nodes one by one so they forget address A 🌷.
- It might be desirable to merge areas A and B into one area. The method for accomplishing this is to, one by one, add knowledge of address B into the A partition, and similarly add knowledge of address A into the B partition 🤝.
- It might be desirable to partition an area C into two areas, A and B (where A might equal C, in which case this example becomes one of removing a portion of an area). This would be accomplished by first introducing knowledge of address A into the appropriate nodes (those destined to become area A), and knowledge of address B into the appropriate nodes, and then one by one removing knowledge of address C ✂️.
Since the addressing explicitly identifies the area, it is very easy for level 1 routers to spot packets going to destinations outside of their area, which need to be forwarded to level 2 routers. So, in IS-IS, routers perform as follows 👀:
- Level 1 intermediate systems route within an area based on the ID portion of the ISO address. Level 1 routers recognize, based on the destination address in a packet, whether the destination is within the area. If so, they route towards the destination. If not, they route to the nearest level 2 router 🎯.
- Level 2 intermediate systems route based on address prefixes, preferring the longest matching prefix, and preferring internal routes over external routes. They route towards areas, without regard to the internal structure of an area; or towards level 2 routers on the routing domain boundary that have advertised external address prefixes into the level 2 subdomain. A level 2 router MAY also be operating as a level 1 router in one area 💖.
A level 1 router will have the area portion of its address manually configured. It will refuse to become a neighbor with a router whose area addresses do not overlap its own area addresses. However, if a level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, then the level 1 IS will accept the other IS as a level 1 neighbor 🫶.
A level 2 router will accept another level 2 router as a neighbor, regardless of area address. However, if the area addresses do not overlap, the link would be considered by both routers to be level 2 only, and only level 2 routing packets would flow on the link. External links (i.e., to other routing domains) MUST be between level 2 routers in different routing domains 🚧.
IS-IS provides an OPTIONAL partition repair function. If a level 1 area becomes partitioned, this function, if implemented, allows the partition to be repaired via use of level 2 routes 🩹.
IS-IS requires that the set of level 2 routers be connected. Should the level 2 backbone become partitioned, there is no provision for using level 1 links to repair a level 2 partition 💀.
Occasionally, a single level 2 router MAY lose connectivity to the level 2 backbone. In this case, the level 2 router will indicate in its level 1 routing packets that it is not "attached", which lets level 1 routers in the area route traffic for destinations outside the area to a different level 2 router 🔁. So level 1 routers only send traffic for destinations outside their area to level 2 routers that indicate, in their level 1 routing packets, that they are "attached" 🌈.
A host MAY autoconfigure the area portion of its address by extracting the area portion of a neighboring router's address. If this is the case, then a host will always accept a router as a neighbor. Since the standard does not specify that the host MUST autoconfigure its area address, a host MAY be pre-configured with an area address 🎀.
Special treatment is necessary for broadcast subnetworks, such as LANs. This solves two sets of issues: (i) without special treatment, each router on the subnetwork would announce a link to every other router on the subnetwork, resulting in O(n-squared) links reported; (ii) again, without special treatment, each router on the LAN would report the same identical list of end systems on the LAN, resulting in substantial duplication 😩.
These problems are avoided by using a "pseudonode", which represents the LAN 🫧. Each router on the LAN reports that it has a link to the pseudonode (rather than reporting a link to every other router on the LAN). One of the routers on the LAN is elected "designated router". The designated router then sends out a Link State Packet (LSP) on behalf of the pseudonode, reporting links to all of the routers on the LAN. This reduces the potential n-squared links to n links. In addition, only the pseudonode LSP includes the list of end systems on the LAN, which eliminates the potential duplication 🧠.
The IS-IS provides for OPTIONAL Quality of Service (QOS) routing, based on throughput (the default metric), delay, expense, or residual error probability ⭐.
IS-IS has a provision for authentication information to be carried in all IS-IS PDUs. Currently, the only form of authentication which is defined is a simple password. A password MAY be associated with each link, each area, and with the level 2 subdomain. A router not in possession of the appropriate password(s) is prohibited from participating in the corresponding function (i.e., may not initialize a link, be a member of the area, or be a member of the level 2 subdomain, respectively). That's a hard no without the right password 🔐.
Procedures are provided to allow graceful migration of passwords without disrupting operation of the routing protocol 🦋. The authentication functions are extensible, so a stronger, cryptographically-based security scheme MAY be added in an upwardly compatible fashion at a future date 🌸.
3.3. Overview of IDRP (ISO/IEC 10747) 💅
Okay so the Inter-Domain Routing Protocol (IDRP, ISO/IEC 10747) came out of ISO and handles routing for OSI environments 🌐 It's built to work together with CLNP, ES-IS, and IS-IS, bestie. This section gives you a quick tour of how IDRP runs ✨
Following the OSI Routing Framework [13], IDRP splits the internetwork into routing domains 🍓 IDRP places no restrictions on the inter-domain topology, so it's giving total freedom 🦋 A router that takes part in IDRP is called a Boundary Intermediate System (BIS). Routing domains that use IDRP are not allowed to overlap, which means a BIS can belong to only one domain. No sharing allowed 🙈
Two BISs are external neighbors if they're in different domains but share a common subnetwork, meaning a BIS can reach its external neighbor in a single network layer hop. Two domains are adjacent if they have BISs that are external neighbors of each other 🌸 Two BISs are internal neighbors if they're in the same domain. Here's the twist: internal neighbors don't have to share a common subnetwork! IDRP assumes a BIS should be able to exchange Network Protocol Data Units (NPDUs) with any of its internal neighbors by relying only on intra-domain routing procedures. Main character energy from the intra-domain side 👑
IDRP handles the exchange of routing information between a pair of neighbors, whether they're external or internal 💜 For external neighbors it's fully self-contained. For internal neighbors, the exchange depends on extra help from intra-domain routing, unless the two neighbors happen to share a common subnetwork 🫶
Now for aggregation. IDRP lets you group a set of connected domains into a Routing Domain Confederation (RDC) ✨ A given domain can belong to more than one RDC, and there's no limit on how many. There are also no preconditions on how RDCs get formed, so they can be nested, disjoint, or overlapping 🌈 One RDC is nested within another if all of the former's members (RDs) are also members of the latter, but not the other way around. Two RDCs overlap if they share some members and each also has members the other doesn't. Two RDCs are disjoint if they have no members in common 🎀
Every domain running IDRP gets a unique Routing Domain Identifier (RDI) 🧚 Syntactically, an RDI is written as an OSI network layer address. Each RDC gets its own unique Routing Domain Confederation Identifier (RDCI). RDCIs come out of the address space allocated for RDIs, so RDCIs and RDIs look exactly the same syntactically 🔥 How you assign and manage RDIs and RDCIs is outside the scope of the protocol. But since RDIs are just network layer addresses, and RDCIs are just RDIs, it's expected that RDI and RDCI assignment would be part of the network layer assignment and management procedures. Recommendations for RDI and RDCI assignment are in Section 6.5 📖
A BIS needs to be preconfigured with the RDI of the domain it belongs to. If that domain is a member of one or more RDCs, the BIS also has to be preconfigured with the RDCIs of all those RDCs, plus the information about how the RDCs relate to each other, whether nested or overlapped 💖
IDRP doesn't assume or require any particular internal structure for addresses 🙌 The protocol gives correct routing as long as the following guidelines are met:
- End systems and intermediate systems may use any NSAP address or Network Entity Title (NET -- i.e., an NSAP address without the selector) that has been assigned under ISO 8348 [11] guidelines;
- An NSAP prefix carried in the Network Layer Reachability Information (NLRI) field for a route originated by a BIS in a given routing domain should be associated with only that routing domain; that is, no system identified by the prefix should reside in a different routing domain. Ambiguous routing may result if several routing domains originate routes whose NLRI fields contain identical NSAP address prefixes, since this would imply that the same system(s) is simultaneously located in several routing domains 🚨
- Several different NSAP prefixes may be associated with a single routing domain, which contains a mix of systems using NSAP addresses assigned by several different addressing authorities 🌷
IDRP assumes these guidelines have been satisfied, but it has no way to verify that this is so 🙈 So verifying them is the responsibility of the administrators of the routing domains. Their job, not IDRP's 💅
IDRP gives mandatory support for data integrity and optional support for data origin authentication for all of its messages 🔐 Each message carries a 16-octet digital signature, computed by applying the MD-4 algorithm (RFC 1320) to the message itself. That signature is what supports data integrity. To support data origin authentication, a BIS may prepend and append additional information to the message when it computes a digital signature. That information isn't passed as part of the message, but the receiver already knows it 🤫
3.3.1. Scaling Mechanisms in IDRP 🦋
Grouping domains into RDCs is a simple yet powerful way to aggregate and abstract routing information, and it's honestly iconic 😭 It reduces topological information by replacing a sequence of RDIs carried by the RD_PATH attribute with a single RDCI. It also reduces the amount of information related to transit policies, because policies can be expressed in terms of aggregates (RDCs) instead of individual components (RDs). And it simplifies route selection policies for the same reason: they can be expressed in terms of RDCs rather than RDs ✨
Aggregation and abstraction of Network Layer Reachability Information (NLRI) is handled by the "route aggregation" mechanism of IDRP 💜 This mechanism is complementary to Routing Domain Confederations. Both are meant to give scalable routing through information reduction and abstraction. They just serve different purposes, though. Route aggregation works on routes (the NLRI), while RDCs work on topology and/or policy information. For maximum benefit, you can use both together 🎀 That means address assignment that makes route aggregation easy shouldn't conflict with the ability to form RDCs, and the other way around. Forming RDCs should be done in a way that's consistent with the address assignment that route aggregation needs. Thinking ahead, periodt 🧚
3.4. Requirements of IS-IS and IDRP on NSAPs 🌈
The preferred NSAP format for IS-IS is shown in Figure 1. Here are some things to note from IS-IS:
- The IDP is as specified in ISO 8348, the OSI network layer service specification [11];
- The high-order portion of the DSP (HO-DSP) is the part of the DSP whose assignment, structure, and meaning are not constrained by IS-IS;
- The area address (i.e., the concatenation of the IDP and the HO-DSP) must be globally unique. If the area address of an NSAP matches one of the area addresses of a router, it's in that router's area and gets routed to by level 1 routing;
- Level 2 routing acts on address prefixes, using the longest address prefix that matches the destination address;
- Level 1 routing acts on the ID field. The ID field must be unique within an area for ESs and level 1 ISs, and unique within the routing domain for level 2 ISs. The ID field is assumed to be flat. The method presented in RFC 1526 [18] may optionally be used to ensure globally unique IDs;
- The one-octet NSAP Selector, SEL, determines the entity that receives the CLNP packet within the system identified by the rest of the NSAP (i.e., a transport entity). It's always the last octet of the NSAP; and,
- A system shall be able to generate and forward data packets containing addresses in any of the formats specified by ISO 8348. However, within a routing domain that conforms to IS-IS, the lower-order octets of the NSAP should be structured as the ID and SEL fields shown in Figure 1 to get the full benefit of IS-IS routing. End systems with addresses that don't conform may require additional manual configuration and may be subject to inferior routing performance 😬
For efficient operation of the IS-IS routing protocol, a few observations can be made. First, although IS-IS specifies an algorithm for routing within a single routing domain, that 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 the domain (these must be routed to an appropriate "border" router, from which they will exit the domain) 🚪
For destinations inside 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. So the efficiency of level 2 routing to destinations within the domain depends only on the number of areas in the domain and the number of area addresses assigned to each area 🍓
For destinations outside the domain, level 2 routing routes according to address prefixes. Here there's a big potential advantage, in terms of reducing the amount of routing information required, if the number of address prefixes needed to describe any particular set of external destinations can be minimized 💅 Efficient routing with IDRP similarly requires minimizing the number of address prefixes needed to describe specific destinations. In other words, addresses need to be assigned with topological significance. This requirement is described in more detail in the following sections 💖
4. NSAPs and Routing ✨
4.1. Routing Data Abstraction ✨
okay bestie, so when someone is deciding how NSAPs get handed out, they NEED to understand the technical fallout 💅 the whole point of hierarchical routing is routing data abstraction (aka summarization) 🦋 which shrinks the processing time, memory, and bandwidth that routing eats up. and that means address assignment has to actually serve routing, or routing just can't scale to huge networks 😭
we're mostly talking about one flavor of routing info here: reachability information, which is basically the set of destinations you can reach 🌸 ngl it's giving main character energy.
here's the tea 🫖 abstraction wants NSAPs assigned by topology, but admin assignment follows org or political lines. those two don't always line up, so the needs can clash. finding a balance between them is kinda essential 💖
abstraction happens at the border between hierarchical topology layers. a lower element reports summary routing info up to its parent(s) 🎀 in the current OSI routing framework [13] and protocols, the lowest spot this can happen is the border between an area and the level 2 subdomain inside an IS-IS routing domain. IS-IS builds this in at that border, since level 1 ISs can only report area addresses 🍓
level 2 routing runs on address prefixes ✨ level 2 routers (ISs) spread the area addresses of their attached level 1 areas through the whole level 2 subdomain (plus any manually configured reachable address prefixes) 🧚 they then work out next-hop forwarding info for every advertised prefix. and the winner for level 2 routing is the longest advertised address prefix that matches the destination address 👑
at routing domain boundaries, prefix info gets swapped with other routing domains via IDRP 🦋 if area addresses in a routing domain all come from totally separate NSAP assignment authorities (so no abstraction at all), then the boundary info is just a full enumerated list of every area address 💀
BUT if the routing domain owns an address prefix and assigns its area addresses out of it, the boundary info can be squished into that single prefix 🌈 that's a massive data reduction, so it scales WAY better than the uncoordinated area addresses from the last bit 😭🔥
now, if routing domains are kinda randomly connected (non-hierarchical), not much more abstraction is likely 🙈 with no defined hierarchy, admins can't assign area addresses from a shared prefix for abstraction. the result is flat inter-domain routing, where every routing domain needs explicit knowledge of every other domain it routes to 💀 this works fine for small and medium internets, up to somewhat bigger than the current IP Internet ✨ but it does NOT scale to very large internets 😭 we expect an international Internet with tens or hundreds of thousands of routing domains in the U.S. alone 🌍 and it gets even bigger when every home or small company is its own routing domain 🏠 that needs more abstraction than the "routing domain" level can give 💅
in the Internet though, we can totally exploit the existing hierarchical routing structure interconnections (see Section 5) 🫶 so a group of subscribers can each get an address prefix carved from a shorter prefix assigned to their provider 🎀 each subscriber then "owns" its (slightly longer) prefix and assigns its area addresses from it 💖
the simplest version: a bunch of subscribers whose routing domains all hook up to just one service provider, and use that provider for all external (inter-domain) traffic 🌸 a short prefix goes to the provider, who gives slightly longer prefixes (based on theirs) to each subscriber 🧚 then the provider can tell other providers about all the addresses it reaches as ONE prefix instead of a huge list 🦋 this is a huge hierarchical abbreviation of routing info and seriously boosts inter-domain scalability 👑
and yes, this is recursive 🌈 it can go through several iterations, with routing domains at any "level" using their prefix as the basis for further suballocations, as long as the NSAP addresses stay within the overall length and structure constraints 💅 NSAP flexibility makes this hierarchical assignment and routing possible ✨ the GOSIP Version 2 NSAP structure is discussed later in this section as one example of NSAP use 🎀
last thing 🫶 the number of nodes at each lower level of a hierarchy tends to grow exponentially, so the biggest abstraction gains happen at the leaves and drop off a lot at each higher level 😭 the law of diminishing returns says there's a point where abstraction stops being worth it 💀 finding that point means carefully considering how many routing domains are expected at each level over a given time, versus how many routing domains and address prefixes dynamic inter-domain routing protocols can handle conveniently and efficiently 🔥 and as the Internet grows, more hierarchy levels may be needed, which is why NSAP addresses' flexibility is so iconic 👑✨
4.2. NSAP Administration and Efficiency ✨
okay so there's a balance that must be sought 💅 between what NSAPs need for efficient routing and the need for decentralized NSAP administration 🫶. The NSAP structure from Version 2 of GOSIP (Figure 2) is one example of how both needs can get met 🦋. The AFI, IDI, DSP Format Identifier (DFI), and Administrative Authority (AA) fields are what make administrative decentralization possible 👑. 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 the Appendix for more information on NSAP structure) 🇺🇸.
<----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 SelectorFigure 2: GOSIP Version 2 NSAP structure.
[Note: we're using U.S. GOSIP version 2 addresses only as an example 🌸. It is not necessary that NSAPs be allocated from the GOSIP Version 2 authority under47.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 being used, and they work equally well 🌈. For parts of the Internet outside of the U.S. there may in some cases be strong reasons to prefer a country- or area-specific format rather than the U.S. 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 💖. So the fields from the AFI to the AA, inclusive, together make up a unique address prefix assigned to an administration ✨.
American National Standard X3.216-1992 [1] specifies the structure of the DSP for NSAP addresses that use an Authority and Format Identifier (AFI) value of (decimal) 39, which identifies the "ISO-DCC" (data country code) format 🍓. In that format the Initial Domain Identifier (IDI) is (decimal) 840, which identifies the U.S. National Body (ANSI). This DSP structure is identical to the one specified by GOSIP Version 2 🎀. The AA field is called "org" (organization identifier) in the ANSI standard, and the ID field is called "system". The ANSI format therefore differs from the GOSIP format illustrated above only in that the AFI and IDI specify the "ISO-DCC" format rather than the "ISO 6523-ICD" format used by GOSIP, and the AA field is administered by an ANSI registration authority rather than by the GSA 🧚. Organization identifiers may be obtained from ANSI. 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 make use of different NSAP formats, the principles of NSAP assignment and use are the same 🌍. The NSAP formats recommended by RARE WG4 for use in Europe are discussed in Section 6.2.
In the low-order part of the GOSIP Version 2 NSAP format, two fields are defined in addition to those required by IS-IS 🦋. 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 ✨
basic Internet routing components are service providers and service subscribers 🌐. A natural mapping from these components to OSI routing components is that each provider and subscriber operates as a routing domain 💅.
Alternatively, a subscriber may choose to operate as a part of a provider domain, that is, as an area within the provider's routing domain 🦋. However, in such a case the discussion in Section 5.1 applies 🙈.
We assume that most subscribers will prefer to operate a routing domain separate from their provider's 💖. Such subscribers can exchange routing information with their provider via interior routing protocol route leaking or via IDRP. For the purposes of this discussion, the choice is not significant 🫶. The subscriber is still allocated a prefix from the provider's address space, and the provider advertises its own prefix into inter-domain routing 👑.
Given such a mapping, where should address administration and allocation be performed to satisfy both administrative decentralization and data abstraction? Three possibilities are considered:
- at the area,
- at the subscriber routing domain, and,
- at the provider routing domain.
Subscriber routing domains correspond to end-user sites, where the primary purpose is to provide intra-domain routing services 🏠. Provider routing domains are deployed to carry transit (i.e., inter-domain) traffic 🚀.
The greatest burden in transmitting and operating on routing information is at the top of the routing hierarchy, where routing information tends to accumulate 😭. In the Internet, for example, each provider must manage the set of network numbers for all networks reachable through the provider 🌈.
For traffic destined for other networks, the provider will route based on inter-domain routing information obtained from other providers or, in some cases, to a default provider 🧭.
In general, higher levels of the routing hierarchy will benefit the most from the abstraction of routing information at a lower level of the routing 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 subscriber 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 provider (implying that the first seven octets of the address are those obtained by that provider) 🤔. If considering only their own self-interest, the subscriber and its local provider have little reason to choose one approach or the other 💁. The subscriber must use one prefix or another, and the source of the prefix has little effect on routing efficiency within the subscriber's routing domain. The provider must maintain information about each attached subscriber in order to route, regardless of any commonality in the prefixes of its subscribers 🫠.
However, there is a difference when the local provider distributes routing information to other providers ⭐. In the first case, the provider cannot aggregate the subscriber's address into its own prefix. The address must be explicitly listed in routing exchanges, resulting in an additional burden to other providers, which must exchange and maintain this information 😩.
In the second case, each other provider sees a single address prefix for the local provider, which encompasses the new subscriber 🌸. This avoids the exchange of additional routing information to identify the new subscriber's address prefix. Thus, the advantages primarily benefit other providers which maintain routing information about this provider (and its subscribers) 🎀.
Clearly, a symmetric application of these principles is in the interest of all providers, enabling them to more efficiently support CLNP routing to their customers 🫶. The guidelines discussed below describe reasonable ways of managing the OSI address space that benefit the entire community 🌈✨.
5.1. Administration at the Area
Okay bestie, so if areas grab their area addresses from a whole myriad of unrelated NSAP allocation authorities 🌈, there's basically no data abstraction beyond what IS-IS already does built in 😭. Let's say that inside one routing domain, three areas take their area addresses, respectively, 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 POV of any one routing domain, there's no harm in having the different areas use addresses from a wide variety of administrations ✨. For routing within the domain, the area addresses get treated as a flat field, so it's all good 💅.
However, this does have a negative effect on inter-domain routing 🥲, especially for those other domains that need to keep 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 must be used consisting of the three area addresses. Not it. 🙈
This situation is roughly analogous to how routing info got shared on the TCP/IP Internet before CIDR showed up 🦋. Areas correspond roughly to networks, and area addresses correspond roughly to network numbers. So letting areas in a routing domain take their NSAPs from unrelated authorities ends up as flat routing at the area address level. The number of address prefixes that subscriber routing domains would advertise is on the order of the number of attached areas, and the number of prefixes a provider routing domain would advertise is roughly the number of areas attached to all its subscriber routing domains. For "default-less" providers (i.e., those that don't use default routes), the size of the routing tables would be on the order of the number of area addresses globally. As the CLNP internet grows, this would quickly become intractable 💀. A greater degree of hierarchical information reduction is necessary to allow greater growth 🌸.
5.2. Administration at the Subscriber Routing Domain
As mentioned previously, the greatest degree of data abstraction comes at the lowest levels of the hierarchy 👑. Giving each subscriber routing domain (that is, site) a unique prefix is the biggest single increase in abstraction, with each subscriber domain assigning area addresses from its prefix. From outside the subscriber routing domain, all the addresses reachable in the domain can then be represented by a single prefix 🎀.
As an example, say a government agency has been assigned the AA value of zzz under ICD=0005. The agency 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 within this routing domain would have area addresses made up of this prefix followed by an Area identifier. The prefix is the summary of reachable addresses within the routing domain, so it's giving organized 🧚.
There's a close relationship between areas and routing domains, and it's kind of implicit: they run a common routing protocol and are under the control of a single administration 🫶. The routing domain administration subdivides the domain into areas and sets up a level 2 subdomain (i.e., a level 2 backbone) that provides connectivity among the areas. The routing domain is 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, so the areas within the subscriber RD should take their NSAPs from the prefix assigned to the subscriber RD. Main character energy for the RD 👑💅.
5.3. Administration at the Provider Routing Domain
Two kinds of provider routing domains are considered: direct providers and indirect providers 🌈. Most of the subscribers of a direct provider are domains that act solely as service subscribers (i.e., they carry no transit traffic). Most of the "subscribers" of an indirect provider are, themselves, service providers. In present terminology, a backbone is an indirect provider, while a regional is a direct provider. Each case is discussed separately below 💖.
5.3.1. Direct Service Providers
It's interesting to consider whether direct service providers' routing domains should be the common authority for assigning NSAPs from a unique prefix to the subscriber routing domains they serve 🤔. In the long term, the number of routing domains in the Internet will grow to the point where routing on a flat field of routing domains is infeasible. So it'll be essential to provide a greater degree of information abstraction 😤.
Direct providers may assign prefixes to subscriber domains, based on a single (shorter length) address prefix assigned to the provider. For example, with the GOSIP Version 2 address structure, an AA value may be assigned to each direct provider, and routing domain values may be assigned by the provider to each attached subscriber routing domain. A similar hierarchical address assignment based on a prefix assigned to each provider may be used for other NSAP formats. This means direct providers advertise to other providers (both direct and indirect) a small fraction of the number of address prefixes they'd need if they listed the individual prefixes of the subscriber routing domains. That's a significant savings given the expected scale of global internetworking 🧠✨.
Are subscriber routing domains willing to accept prefixes derived from the direct providers? In the supplier/consumer model, the direct provider is offering connectivity as the service, priced according to its costs of operation. That includes the "price" of getting service from one or more indirect providers and exchanging routing information with other direct providers. In general, providers want to handle as few address prefixes as possible to keep costs low 💸. In the Internet environment, subscriber routing domains must be sensitive to the resource constraints of the providers (both direct and indirect). The efficiencies gained in routing clearly warrant the adoption of NSAP administration by the direct providers 🔥.
The mechanics of this scenario are straightforward 🎀. Each direct provider is assigned a unique prefix, from which it allocates slightly longer routing domain prefixes for its attached subscriber routing domains. For GOSIP NSAPs, this means a direct provider would be assigned an AA identifier, and attached subscriber routing domains would be assigned RD identifiers under the direct provider's unique prefix. For example, say NIST is a subscriber 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.A similar scheme can be set up using NSAPs allocated under DCC=840. In this case, a direct provider applies for an ORG identifier from ANSI, which serves the same purpose as the AA identifier in GOSIP 🦋.
5.3.2. Indirect Providers
There doesn't really seem to be a strong case for direct service providers to take their address spaces from the NSAP space of an indirect provider (e.g. a backbone in today's terms) 🙅♀️. The benefit in routing data abstraction is relatively small. The number of direct providers today is in the tens, and an order of magnitude increase wouldn't cause an undue burden on the indirect providers. It's also expected that, as time goes by, there will be more direct interconnection of the direct providers, subscriber routing domains directly attached to the "indirect" providers, and international links directly attached to the providers. Under these circumstances, the distinction between direct and indirect providers would get blurry 🌫️.
Another factor that discourages allocating NSAPs from an indirect provider's prefix is that the indirect providers and their attached direct providers are seen as independent 🤷♀️. Direct providers may take their indirect provider service from one or more providers, or may switch indirect providers should a more cost-effective service be available elsewhere. Basically, indirect providers can be thought of the same way as long-distance telephone carriers 📞. Having NSAPs derived from the indirect providers is inconsistent with the nature of that relationship 💅.
5.4. Multi-homed Routing Domains
The discussions in Section 5.3 suggest methods for allocating NSAP addresses based on service provider connectivity 🧩. This allows a great deal of information reduction for routing domains attached to a single provider. In particular, such routing domains may select their NSAP addresses from a space allocated to them by their direct service provider. That way, when the provider announces the addresses it can reach to other providers, it can use a single address prefix to describe a large number of NSAP addresses corresponding to multiple routing domains 🌈.
However, there are extra considerations for routing domains attached to multiple providers 🌀. Such "multi-homed" routing domains may, for example, be single-site campuses and companies attached to multiple providers, large organizations attached to different providers at different locations in the same country, or multi-national organizations attached to providers 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 providers it's attached to 🦋. This lets each multi-homed organization base its NSAP assignments on a single prefix, and so summarize the whole set of NSAPs reachable within that organization via one prefix. The downside is that since the NSAP address for that organization has no relationship to the addresses of any particular provider, the providers it's attached to will need to advertise that organization's prefix to other providers. Other providers (potentially worldwide) will need to keep an explicit entry for that organization in their routing tables. If other providers don't maintain a separate route for this organization, then packets destined to this organization will be lost 💀😭.
okay so picture this, bestie 🎀 "Mega Big International Incorporated" (MBII) is a super huge US-wide company with a fully interconnected internal network, and it got a single AA value under the U.S. GOSIP Version 2 address space 💼✨. Outside the U.S., one entry in the routing tables is probably enough to cover every U.S. GOSIP address 🌍. Inside the U.S., though, every "default-less" provider has to keep its own separate address entry for MBII 😭. And if MBII is actually international, then every "default-less" provider worldwide might need a separate entry for it, including the providers MBII isn't even attached to 💀. Obviously this could be fine if there are only a few multi-homed routing domains like this, but if every organization picked this kind of address assignment, it would put an unacceptable load on routers inside providers 🙅. This solution probably won't scale to internets with many hundreds of thousands of multi-homed organizations 📉.
A second approach is for multi-homed organizations to get a separate NSAP space for each connection to a provider, and then give each area inside their routing domain(s) a single address prefix based on the closest interconnection point 🦋. Say MBII had two providers in the U.S. (one east coast and one west coast), plus three connections to national providers in Europe and one in the far east. Then MBII could use six different address prefixes 🌸. Each area inside MBII gets one address prefix based on its nearest connection 🗺️.
For external routing of traffic coming from outside MBII to a destination inside MBII, this approach works kind of like treating MBII as six separate organizations 👯♀️. For internal routing, or for routing traffic from inside MBII to a destination outside it, the approach works the same as the first solution 🔁.
If we assume that incoming traffic (coming from outside MBII, with a destination within MBII) always enters via the nearest point to the destination, then each provider that has a connection to MBII needs to tell the other providers that it can reach only those parts of MBII whose address comes from its own address space 📣. So no extra routing info has to be swapped between providers, which means a smaller load on the inter-domain routing tables providers maintain compared to the first solution 📊. That's why this solution scales better to extremely large internets with very large numbers of multi-homed organizations 🚀✨.
One problem with the second solution is that backup routes to multi-homed organizations aren't maintained automatically 🙈. With the first solution, each provider announcing that it can reach MBII says it can reach all of the NSAPs within MBII. With the second, each provider announces that it can reach all of the NSAPs based on its own address prefix, which only covers some of the NSAPs within MBII 🧩. If the connection between MBII and one particular provider got severed, the NSAPs within MBII with addresses based on that provider would become unreachable via inter-domain routing 😱. You can lessen the impact a bit by keeping extra information in the routing tables, but that cuts into the scaling advantage of the second approach 💔.
The second solution also requires that when external connectivity changes, internal addresses change too 🔄.
Also, note that this approach and the previous one will tend to make packets take different routes 🛣️. With the first approach, packets from outside MBII destined for inside MBII tend to enter via the point closest to the source, which tends to maximize the load on the networks internal to MBII 🏋️. With the second solution, packets from outside destined for inside MBII tend to enter via the point closest to the destination, which tends to minimize the load on the networks within MBII and maximize the load on the providers 💅.
These solutions also have different effects on policies 📜. Suppose country "X" has a law that traffic from a source within country X to a destination within country X must always stay entirely within the country 🇽. With the first solution, you can't tell from the destination address whether the destination is inside the country 🤷. With the second solution, a separate address can be assigned to the NSAPs within country X, so routing policies can be followed 💜. Now say "Little Small Company" (LSC) has a policy that its packets may never be sent to a destination within MBII 🙅. With either solution, LSC's routers can be configured to discard any traffic with a destination in MBII's address space 🗑️. But with the first solution that takes one entry, while with the second it takes many entries and may be impossible in practice 😵.
There are other possible solutions too ✨. A third approach is to give each multi-homed organization a single address prefix based on one of its connections to a provider 🎀. The other providers that the multi-homed organization is attached to keep a routing table entry for it, but they are extremely selective about which indirect providers get told about this route 🤫. This gives a single "default" routing entry that every provider can use to reach the organization (since presumably all providers maintain routes to each other), while still allowing more direct routing in cases where providers agree to keep additional routing information 🧭.
There's at least one situation where this third approach is especially appropriate 🌟. Suppose a special interest group of organizations has deployed its own backbone. Let's say the U.S. National Widget Manufacturers and Researchers set up a U.S.-wide backbone, used by corporations that make 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 providers, since most of them are involved in other activities too 💁. So many or most of the organizations in the widget group are probably 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 keep a routing table with one entry per organization, but that they're spread throughout a larger internet with many millions of (mostly not widget-associated) routing domains 🌐.
With the third approach, each multi-homed organization in the widget group uses an address assignment based on its other attachment(s) to providers (the ones not associated with the widget group) 🏷️. The widget backbone needs to keep routes to the routing domains of the various member organizations 🦴. Similarly, every member of the widget group needs a table of routes to the other members via the widget backbone 📚. But since the widget backbone doesn't tell other general world-wide providers which addresses it can reach (the backbone isn't meant for use by other outside organizations), that relatively large set of routing prefixes only needs to be kept in a limited number of places 🤐. The addresses assigned to the members of the widget group provide a "default route" via each member's other provider attachments, while letting communications within the widget group use the preferred path 🛤️💖.
A fourth solution involves assigning a particular address prefix to routing domains that are attached to two or more specific cooperative public service providers 🤝. For example, suppose there are two providers, "SouthNorthNet" and "NorthSouthNet," that have a very large number of customers in common (meaning lots of routing domains are attached to both) 🥰. Instead of getting two address prefixes (such as two AA values assigned under the GOSIP address space), these organizations could get three prefixes 🎁. Routing domains attached to NorthSouthNet but not to SouthNorthNet get an address assignment based on one of the prefixes. Routing domains attached to SouthNorthNet but not to NorthSouthNet get an address based on the second prefix. And routing domains multi-homed to both networks get an address based on the third prefix 🧁. Each of these two providers would then advertise two prefixes to other providers: one for the subscriber routing domains attached only to it, and one for the subscriber routing domains attached to both 📢.
This fourth solution could become important once use of public data networks gets more common 📡. It's likely that at some point in the future a substantial percentage of all routing domains will be attached to public data networks 🌏. In that case, nearly all government-sponsored networks (like some regional networks that receive NSF funding, as well as government-sponsored backbones) may have a set of customers that overlaps substantially 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 of these solutions has very different advantages and disadvantages 🥇. Each one places a different real (meaning financial) cost on the multi-homed organizations, and on the providers, including the providers the multi-homed organizations aren't attached to 💸.
Most of the solutions described also highlight the need for each provider to develop a policy on whether, and under what conditions, to accept customers with addresses that aren't based on its own address prefix, and on how those non-local addresses will be treated 📝. For example, a somewhat conservative policy might be that an attached subscriber RD can use any NSAP address prefix, but addresses not based on the provider's own prefix might not get advertised to other providers 🙊. A less conservative policy could have a provider accept customers using those non-local prefixes and agree to exchange them in routing information with a defined set of other providers 🤙. That set could be an a priori group of providers that have something in common, like geographic location, or it could be the result of an agreement specific to the requesting subscriber 🫶. Various policies involve real costs to providers, and those costs may be reflected in the policies themselves 💅💰.
5.5. Private Links ✨
Okay so bestie, up to this point we've been talking about how NSAP addresses and routing work between routing domains over transit routing domains. Those are the big in-between networks that hook up a huge number of routing domains and offer a more-or-less public service. 💅
But here's the tea: there can also be a whole bunch of private point-to-point links connecting two private routing domains. 🔒 Most of the time, these private links are only allowed to forward packets directly between those two private routing domains. No detours, no side quests. 🌸
Let's say XYZ corporation does a lot of business with MBII. They might team up with a carrier to set up a private link between the two companies. This link may only carry packets whose source is inside one of the two corporations and whose destination is inside the other one. Now imagine the link runs between a single router (router X) inside XYZ and a single router (router M) inside MBII. That means router X has to be configured to know which addresses can be reached over this link, which is every address reachable in MBII. 🧠 Router M needs the same kind of info, so it has to know every address reachable in XYZ Corporation.
The big observation here is that private links like this can be ignored for NSAP allocation, and they don't cause a problem for routing. Why? The routing information tied to a private link never gets spread around the whole internet, so it doesn't need to be squished down into a provider's prefix. ✨
Keep going with the example. XYZ has one connection to a service provider, so it got its address allocation from that provider's space. MBII is an international corporation with connections to six different providers, so it went with the second solution from Section 5.4 and got six different address allocations. That means every address reachable in XYZ Corporation can be described by a single address prefix. Router M only needs one prefix configured to represent the addresses reachable over this point-to-point link. 🎀 Every address reachable in MBII, though, can be described by six address prefixes, so router X needs six prefixes configured for the link. Not too bad, right? 💖
Sometimes these private links are allowed to forward traffic for a small number of other routing domains, like closely affiliated organizations. That does bump up the configuration requirements a little. But as long as the number of organizations using the link is relatively small, it still isn't a significant problem. 🫶
Here's the important context: the relationship between routing and NSAP addressing in the other sections of this document is about scaling problems. Those problems come from large, essentially public transit routing domains that interconnect a huge number of routing domains. For NSAP allocation, though, private point-to-point links that only connect a small number of private routing domains are no problem at all and can be ignored. For example, a single subscriber routing domain with one connection to a "public" provider, plus a bunch of private point-to-point links to other subscriber routing domains, can be treated as if it were single-homed to the provider for NSAP address allocation. Main character energy for that subscriber routing domain! 👑
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 might still have a number of private point-to-point links they use to talk with other organizations. They don't participate in global routing, and they're totally satisfied with being able to reach the organizations they've set up private links with. These are called zero-homed routing domains. 🌈
Zero-homed routing domains can be considered the degenerate case of routing domains with private links, which we just covered in the last section. They don't pose a problem for inter-domain routing. Same as before, 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. 💜
But, and this part is important, periodt 🚨: zero-homed routing domains still need to use valid, globally unique NSAP addresses. Picture this. A 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., ISO 8348). That RD has to be able to tell the difference between the zero-homed routing domain's NSAPs and any other NSAPs it might need to route to. The only way to guarantee that is if the zero-homed routing domain uses globally unique NSAPs. No shortcuts, bestie. 🙈
5.7. Address Transition Issues 🦋
okay so, handing out NSAP addresses based on who you're connected to (your providers) is lowkey essential for scaling inter-domain routing to an internet with millions of routing domains 😭 BUT that also means if your topology changes, your address might have to change too 💀
this need to change addresses is literally a natural, inevitable consequence of any method of routing data abstraction 🫶 the basic idea 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, sometimes the address has to change. if you could change the connectivity between routing domains WITHOUT changing addresses, then you'd have to keep track of where that routing domain is on an individual basis, and nobody wants that 🙈
the internet is growing super fast and getting more commercial, so the topology could be pretty volatile 🌪️ which means planning for address transition is VERY important 💅 good news: there are a bunch of steps that can help ease the effort. a full description of address transition issues is outside the scope of this paper, but this section has a quick outline of some transition issues ✨
also, since a topology change might force an address change, it is valuable to anticipate future topology changes before you finalize an address allocation plan 🧚 like, if a routing domain is single-homed at first but expects to become multi-homed later, it may be advantageous to assign NSAP addresses based on the anticipated future topology 🔥
realistically, you can't flip the switch on a routing domain's addresses at midnight 🌙 instead you need a gradual transition where both the old and new addresses stay valid for a limited period of time. during that transition period, the 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 🎀
good news, IS-IS already has transition provisions built in! 🌸 as described in Section 3, IS-IS lets you assign multiple addresses to each area, specifically to make transition easier 💜
OSI also has provisions for autoconfiguration of area addresses 🤖 OSI end systems can find out their area addresses automatically, either by passively observing the ES-IS IS-Hello packets transmitted by routers, or by actively querying the routers for their NSAP address. if the ID portion of the address is assigned in a manner which allows for globally unique IDs [18], then an end system can reconfigure its entire NSAP address automatically with no manual intervention. however, routers will still require manual address reconfiguration 👀
during the transition period, it is important that packets using the old address be forwarded correctly, even when the topology has changed 🦋 this is facilitated by the use of "best match" inter-domain routing ✨
okay, example time 🍓 say XYZ Corporation was previously connected only to the NorthSouthNet provider. so XYZ went to the NorthSouthNet administration and got a routing domain assignment based on the AA value NorthSouthNet obtained under the GOSIP address space. but then, for a variety of reasons, XYZ Corporation decided to terminate its association with the North-SouthNet and connect directly to the NewCommercialNet public data network instead 💅 thus the XYZ Corporation now has a new address assignment under the ANSI address assigned to NewCommercialNet. the old address would seem to imply that traffic for XYZ Corporation should be routed to NorthSouthNet, which no longer has any direct connection with XYZ Corporation 😬
if the old provider (NorthSouthNet) and the new provider (NewCommercialNet) are adjacent and cooperative, then this transition is easy to pull off 🫶 in this case, packets routed to XYZ Corporation using the old address assignment could be routed to NorthSouthNet, which would directly forward them to NewCommercialNet, which would in turn forward them to XYZ Corporation. 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 provider and the new provider are NOT adjacent, it gets a bit more complex, but there are still several possible ways to forward traffic correctly 🧩
if the old and new providers are themselves connected by other cooperative providers, then those intermediate domains may agree to forward traffic for XYZ correctly. for example, say 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 traffic to XYZ using the old address allocation gets forwarded via NewCommercialNet. other routing domains wouldn't need to know about XYZ Corporation's new location 🌈
if the old provider and the new provider are separated by a non-cooperative routing domain, or by a long path of routing domains, then the old provider could encapsulate traffic to XYZ Corporation in order to deliver those packets to the correct backbone 📦
also, locations that do a lot of business with XYZ Corporation could add a specific entry to their routing tables to make sure packets to XYZ are routed optimally 💼 for example, suppose another commercial backbone "OldCommercialNet" has a large number of customers who exchange traffic with XYZ Corporation, and this third provider 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 additional (more specific) entry so packets sent to XYZ Corporation's old address are routed correctly ⭐
whichever method is used to ease the transition, the goal is that the knowledge relating XYZ to its old address, which is held throughout the global internet, would eventually be replaced with the new information 🫧 it's reasonable to expect this to take weeks or months, and it will be accomplished through the distributed directory system. 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 continuation of the rapid internationalization of the Internet 🌍 the ability of routing to scale depends on data abstraction based on hierarchical NSAP addresses. so as CLNP use increases in the Internet, it is therefore essential to assign 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. for NSAP allocation, this again means that routing data abstraction must be encouraged 💅
for data abstraction to be possible, NSAP addresses must be assigned in a manner which is consistent with the actual physical topology of the Internet. for example, in cases where organizational and administrative boundaries are not related to the actual network topology, address assignment based on those organization boundaries is not recommended 🙅♀️
the intra-domain IS-IS routing protocol lets you keep information abstraction at two levels: systems are grouped into areas, and areas are interconnected to form a routing domain 🧸 the inter-domain IDRP routing protocol keeps information abstraction at multiple levels by grouping routing domains into Routing Domain Confederations and using route aggregation capabilities 🪆
for zero-homed and single-homed routing domains (which are expected to stay 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 means the set of all NSAP addresses reachable within a single domain can be fully described via a single prefix ✨ we recommend that single-homed routing domains use an address prefix based on their connectivity to a public service provider 🌸 and we recommend that zero-homed routing domains use globally unique addresses 🌍
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 📈 to provide the data abstraction we need, we recommend using Routing Domain Confederations and the route aggregation capabilities of IDRP 👑
the general technical requirements for NSAP address guidelines don't vary from country to country. however, details of address administration may vary between countries 🗺️ also, in most cases, network topology has a close relationship with 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 🔍 moreover, that suggests national boundaries may be used to group domains into Routing Domain Confederations 🧁
each of the country-specific or continent-specific recommendations presented below is consistent with the technical requirements for scaling of addressing and routing presented in this RFC 💜
6.1. Recommendations Specific to U.S. Parts of the Internet 🇺🇸
okay so the U.S. part of the internet is gonna be running mostly on two address prefixes: ICD=0005, the format used by The U.S. Government, and DCC=840, the format defined by ANSI. 💅
we expect public interconnectivity between private routing domains in the U.S. to come from a super diverse crew of providers, including (but not necessarily limited to) regional providers and commercial Public Data Networks 🌐
these networks are not expected to connect in a strictly hierarchical way, bestie. like, the regional providers might be directly connected instead of relying on an indirect provider, and all three of these types of networks may have direct international connections. it's giving messy-but-make-it-work 🙈
BUT (and this is a big but) the total number of these providers is expected to stay small enough, for the foreseeable future, to address the whole set with a flat address space ✨ and these providers will be the ones connecting a wide variety of routing domains. each of those could be a single corporation, part of a corporation, a university campus, a government agency, or some other organizational unit 🎓
some private corporations may also make use of dedicated private providers for communication within their own corporations 🏢
we anticipate that the great majority of routing domains will be attached to only one of the providers. this will permit hierarchical address abbreviation based on provider, so we therefore strongly recommend that addresses be assigned hierarchically, based on address prefixes assigned to individual providers 🦋
for the GOSIP address format, this implies that Administrative Authority (AA) identifiers should be obtained by all providers (explicitly including the NSFNET backbone, the NSFNET regionals, and other major government backbones). for those subscriber routing domains connected to a single provider, they should be assigned a Routing Domain (RD) value from the space assigned to that provider 🎀
to provide routing information aggregation/abstraction, we recommend that each provider together with all of its subscriber domains form a Routing Domain Confederation. that, combined with hierarchical address assignment, would provide a significant reduction in the volume of routing information that needs to be handled by IDRP. ngl this is so smart. also, the presence of multihomed subscriber domains would imply that such Confederations will overlap, which is explicitly supported by IDRP 🧚
we recommend that all providers explicitly be involved in the task of address administration for those subscriber routing domains which are single-homed to them. this offers a valuable service to their customers, and also greatly reduces the resources (including human and network resources) necessary for that provider to take part in inter-domain routing. win-win 💖
each provider should develop policy on whether and under what conditions to accept customers using addresses that are not based on the provider's own address prefix, and how such non-local addresses will be treated. policies should reflect the issue of 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 publicly-available provider, no urgent need for hierarchical address abbreviation exists. so we don't make any additional recommendations for these "isolated" routing domains, except to note that there is no technical reason to stop GOSIP AA identifier values or ANSI organization identifiers from being assigned to them 🙌
where such domains are connected to other domains by private point-to-point links, and where those links are used solely for routing between the two domains they interconnect, no additional technical problems relating to address abbreviation are caused by the link, and no specific additional recommendations are necessary 🫶
6.2. Recommendations Specific to European Parts of the Internet 🌍
this section has extra RARE recommendations for allocating NSAP addresses within each national domain, run by a National Standardization Organization (NSO) and national research network organizations 🧠
NSAP addresses are expected to be based on the ISO DCC scheme. organizations that aren't tied to a particular country, and that have reasons not to use a national prefix based on ISO DCC, should follow the recommendations in chapters 6.3 and 6.4 📖
ISO DCC addresses aren't tied to any specific subnetwork type or service provider, so they're independent of the type or ownership of the underlying technology. that's the vibe ✨
6.2.1. General NSAP Structure 🧩
the general structure of a Network Address defined in ISO 8348 is further divided up like this:
+-----------+-----------------------------------------+
| IDP | DSP |
+-----+-----+-----------+-----------------------------+
| AFI | IDI | CDP | CDSP |
+-----+-----+-----+-----+----------------+------+-----+
| AFI | IDI | CFI | CDI | RDAA | ID | SEL |
+-----+-----+-----+-----+----------------+------+-----+
octets | 1 | 2 | 2..4 | 0..13 | 1..8 | 1 |
+-----+-----+-----------+----------------+------+-----+here's the cheat sheet for all those pieces:
IDP Initial Domain Part
AFI Authority and Format Identifier, two-decimal-digit,
38 for decimal abstract syntax of the DSP or
39 for binary abstract syntax of the DSP
IDI Initial Domain Identifier, a three-decimal-digit
country code, as defined in ISO 3166
DSP Domain Specific Part
CDP Country Domain Part, 2..4 octets
CFI Country Format Identifier, one digit
CDI Country Domain Identifier, 3 to 7 digits, fills
CDP to an octet boundary
CDSP Country Domain Specific Part
RDAA Routing Domain and Area Address
ID System Identifier (1..8 octet)
SEL NSAP Selectorthe total length of an NSAP can vary from 7 to 20 octets 📏
6.2.2. Structure of the Country Domain Part 🏳️
the CDP identifies an organization within a country, and the CDSP is then available to that organization for further internal structuring however it wants 💅 non-ambiguity of addresses is ensured by there being the NSO, a single national body that allocates the CDPs 🔒
the CDP is further divided into CFI and CDI, where the CFI identifies the format of the CDI. this is the lowkey genius part: it lets several types of CDI get assigned in parallel, for organizations with different requirements who get different amounts of the total address space. it also conveniently leaves a substantial amount of address space reserved for future allocation 🌈
the possible structures of the CDP are as follows:
CFI = /0 reserved
CFI = /1 CDI = /aaa very large organizations or
trade associations
CFI = /2 CDI = /aaaaa organizations of intermediate size
CFI = /3 CDI = /aaaaaaa small organizations and single users
CFI = /4../F reservedNote: this uses the hexadecimal reference publication format defined in ISO 8348, which is a solidus "/" followed by a string of hexadecimal digits. each "a" stands for one hexadecimal digit. 🔍
organizations are sorted into large, medium and small for the purpose of address allocation, and one CFI is made available for each category of organization 🍓
this recommendation for CDP leaves space for the U.S. GOSIP Version 2 NSAP model (Appendix A.1) by the reserved CFI /8, but it is not recommended for use in the European Internet 🙅♀️
6.2.3. Structure of the Country Domain Specific Part 🛠️
the CDSP must have a structure (within the decimal digit or binary octet syntax selected by the AFI value 38 or 39) that satisfies both the routing requirements (IS-IS) and the logical requirements of the organization identified (CFI + CDI). the balance has to be perfect 👑
6.3. Recommendations Specific to Other Parts of the Internet 🌏
for the part of the internet that's outside of the U.S. and Europe, it is recommended that the DSP format be structured hierarchically, similarly to what's specified for the U.S. and Europe, no matter whether the addresses are based on DCC or ICD format 🌺
also, to allow aggregation of NSAPs at national boundaries into as few prefixes as possible, we further recommend that NSAPs allocated to routing domains be assigned based on each routing domain's connectivity to a national Internet backbone 🗺️
6.4. Recommendations for Multi-Homed Routing Domains 🔀
some routing domains will be attached to multiple providers within the same country, or to providers within multiple countries. we call these "multi-homed" routing domains. clearly, the strict hierarchical model discussed above doesn't neatly handle them 😭
there are several possible ways these multi-homed routing domains can be handled. each method varies with respect to the amount of information that must be maintained for inter-domain routing, and also with respect to the inter-domain routes. on top of that, the organization that bears the brunt of the cost changes with each possible solution. for example, the solutions vary with respect to:
- resources used within routers within the providers;
- administrative cost on provider personnel; and,
- difficulty of configuration of policy-based inter-domain routing information within subscriber routing domains.
also, the solution used may affect the actual routes that packets follow, and may effect the availability of backup routes when the primary route fails. 😬
for these reasons, it is not possible to mandate a single solution for all situations. instead, economic considerations will require a variety of solutions for different subscriber routing domains and providers 💸
6.5. Recommendations for RDI and RDCI assignment 🏷️
RDIs and RDCIs don't need to be related to the set of addresses within the domains (confederations) they depict. still, for the sake of simplicity, we recommend that RDIs and RDCIs be assigned based on the NSAP prefixes assigned to domains and confederations 🧃
a subscriber RD should use the NSAP prefix assigned to it as its RDI. a multihomed RD should use one of the NSAP prefixes assigned to it as its RDI. if a service provider forms a Routing Domain Confederation with some of its subscribers, and the subscribers take their addresses out of the provider, then the NSAP prefix assigned to the provider should be used as the RDCI of the confederation. in this case, the provider may use a longer NSAP prefix for its own RDIs. in all other cases, a provider should use the address prefix that it uses for assigning addresses to systems within the provider as its RDI ✨
7. Security Considerations 🔐
security issues are not discussed in this memo (except for the discussion of IS-IS authentication in Section 3.2). 😱
8. Authors' Addresses 💖
okay so here's the squad that wrote this, plus how to reach each of them 🫶
Richard P. Colella
National Institute of Standards & Technology
Building 225/Room B217
Gaithersburg, MD 20899
Phone: (301) 975-3627
EMail: colella@nist.gov
Ross Callon
c/o Wellfleet Communications, Inc
2 Federal Street
Billerica, MA 01821
Phone: (508) 436-3936
EMail: callon@wellfleet.com
Ella P. Gardner
The MITRE Corporation
7525 Colshire Drive
McLean, VA 22102-3481
Phone: (703) 883-5826
EMail: epg@gateway.mitre.org
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.com9. Acknowledgments 🫶
the authors wanted to give a big shoutout to the members of the IETF OSI-NSAP Working Group and of RARE WG4 for the helpful suggestions they dropped while this was being written 💅 they also thanked Radia Perlman of Novell, Marcel Wiget of SWITCH, and Cathy Wittbrodt of BARRnet for their ideas and help. so iconic, no cap ✨
10. References 📚
here's the whole reading list, every single entry, bestie 🍓
[1] ANSI, "American National Standard for the Structure and Semantics
of the Domain-Specific Part (DSP) of the OSI Network Service
Access Point (NSAP) Address", American National Standard X3.216-
1992.
[2] Boland, T., "Government Open Systems Interconnection Profile
Users' Guide Version 2 [DRAFT]", NIST Special Publication,
National Institute of Standards and Technology, Computer Systems
Laboratory, Gaithersburg, MD, June 1991.
[3] GOSIP Advanced Requirements Group, "Government Open Systems
Interconnection Profile (GOSIP) Version 2", Federal Information
Processing Standard 146-1, U.S. Department of Commerce, National
Institute of Standards and Technology, Gaithersburg, MD, April
1991.
[4] Hemrick, C., "The OSI Network Layer Addressing Scheme, Its
Implications, and Considerations for Implementation", NTIA Report
85186, U.S. Department of Commerce, National Telecommunications
and Information Administration, 1985.
[5] ISO, "Addendum to the Network Service Definition Covering Network
Layer Addressing," RFC 941, ISO, April 1985.
[6] ISO/IEC, "Codes for the Representation of Names of Countries",
International Standard 3166, ISO/IEC JTC 1, Switzerland, 1984.
[7] ISO/IEC, "Data Interchange - Structures for the Identification of
Organization", International Standard 6523, ISO/IEC JTC 1,
Switzerland, 1984.
[8] ISO/IEC, "Information Processing Systems - Open Systems
Interconnection -- Basic Reference Model", International Standard
7498, ISO/IEC JTC 1, Switzerland, 1984.
[9] ISO/IEC, "Protocol for Providing the Connectionless-mode Network
Service", International Standard 8473, ISO/IEC JTC 1,
Switzerland, 1986.
[10] ISO/IEC, "End System to Intermediate System Routing Exchange
Protocol for use in Conjunction with the Protocol for the
Provision of the Connectionless-mode Network Service",
International Standard 9542, ISO/IEC JTC 1, Switzerland, 1987.
[11] ISO/IEC, "Information Processing Systems -- Data Communications
-- Network Service Definition", International Standard 8348,
1992.
[12] ISO/IEC, "Information Processing Systems - OSI Reference Model -
Part3: Naming and Addressing", Draft International Standard
7498-3, ISO/IEC JTC 1, Switzerland, March 1989.
[13] ISO/IEC, "Information Technology - Telecommunications and
Information Exchange Between Systems - OSI Routeing Framework",
Technical Report 9575, ISO/IEC JTC 1, Switzerland, 1989.
[14] ISO/IEC, "Intermediate System to Intermediate System Intra-Domain
Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-Mode Network Service
(ISO 8473)", International Standard ISO/IEC 10589, 1992.
[15] Loughheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3)" RFC 1267, cisco Systems, T.J. Watson Research Center,
IBM Corp., October 1991.
[16] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
Information among Intermediate Systems to support Forwarding of
ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1,
Switzerland 1993.
[17] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple
Proposal for Internet Addressing and Routing", RFC 1347, DEC,
June 1992.
[18] Piscitello, D., "Assignment of System Identifiers for TUBA/CLNP
Hosts", RFC 1526, Bellcore, September 1993.
[19] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC 1519, BARRNet, cisco, OARnet, September 1993.
[20] ISO/IEC JTC1/SC6, "Addendum to ISO 9542 Covering Address
Administration", N6273, March 1991.A. Administration of NSAPs 🌸
okay so NSAPs are the endpoints of communication through the Network Layer, and they must be globally unique [4]. ISO 8348 is where the semantics of the NSAP are defined, along with the abstract syntaxes you can use to express the semantics of the Network address [11]. ✨
an NSAP is split into the initial domain part (IDP) and the domain specific part (DSP). the IDP is made up of an authority and format identifier (AFI) and an initial domain identifier (IDI). the AFI tells you the format of the IDI, which network addressing authority is responsible for allocating IDI values, and the abstract syntax of the DSP. the IDI tells you which addressing subdomain the DSP values get allocated from, plus the network addressing authority in charge of allocating DSP values from that domain. whatever the structure and semantics of the DSP are, they're decided by the authority the IDI identifies. check out Figure 3 for the whole NSAP picture 🎀
+-----------+
| 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 is every NSAP address in the OSI environment 🌍. inside that, ISO 8348 describes seven second-level addressing domains and their corresponding IDI formats:
- X.121 for public data networks
- F.69 for telex
- E.163 for the public switched telephone network numbers
- E.164 for ISDN numbers
- ISO Data Country Code (DCC), allocated according to ISO 3166 [6]
- ISO International Code Designator (ICD), allocated according to ISO 6523 [7]
- Local to accommodate the coexistence of OSI and non-OSI network addressing schemes.
for OSI networks in the U.S., portions of the ICD subdomain are available through the U.S. Government, and the DCC subdomain is available through The American National Standards Institute (ANSI). the British Standards Institute is the registration authority for the ICD subdomain, and it has registered four IDIs for the U.S. Government: the ones used for GOSIP, DoD, OSINET, and the OSI Implementors Workshop. ANSI, as the U.S. ISO Member Body, is the registration authority for the DCC domain in the United States. 🇺🇸
A.1. GOSIP Version 2 NSAPs 🎀
GOSIP Version 2 makes an NSAP addressing subdomain available for government use, with a corresponding address format illustrated in Figure 2 in Section 4.2. the "47" signifies that it's based on the ICD format and uses a binary syntax for the DSP. the 0005 is an IDI value that's been assigned to the U.S. Government. even though GOSIP Version 2 NSAPs are mainly meant 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 was established by the National Institute of Standards and Technology (NIST), the authority for the ICD=0005 domain, in GOSIP Version 2 [3] (see Figure 2, Section 4.2). NIST has delegated the authority to register AA identifiers for GOSIP Version 2 NSAPs to the General Services Administration (GSA). 🦋
ISO 8348 allows a maximum length of 20 octets for the NSAP address. the AFI of 47 takes up one octet, and the IDI of 0005 takes up two. the DSP is encoded as binary, as the AFI of 47 indicates. the breakdown goes like this:
- one octet for the 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
- one octet for the NSAP selector
two octets have been reserved for future growth and to give extra flexibility for inter-domain routing. the last seven octets of the GOSIP NSAP format are structured in accordance with IS-IS [14], the intra-domain IS-IS routing protocol. the DSP Format Identifier (DFI) identifies the format of the rest of the 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. that's the whole vibe of the DFI ✨
the Administrative Authority identifier names the administrative authority responsible for registration within its domain. that administrative authority can delegate the job of registering areas to the routing domains, and the routing domains can delegate the job of registering System Identifiers to the areas. the main responsibility of a registration authority at any level of the addressing hierarchy is making sure entity names 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 that operate according to the same routing procedures, and it's 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, and its value may be a physical address (SNPA) or a logical value. address resolution between the NSAP and the SNPA may be accomplished by an ES-IS protocol [10], locally administered tables, or mapping functions. last but not least, the NSAP selector field identifies the end user of the network layer service, i.e., a transport layer entity. main character energy for the selector field 👑
A.1.1 Application for Administrative Authority Identifiers 🎟️
okay so, the steps for an agency to grab an NSAP Administrative Authority identifier under ICD=0005 from GSA are going to be in the updated GOSIP users' guide for Version 2 [2] 📖, but here's the tea in the meantime 💅. Requests from non-government and non-U.S. organizations should come from a senior official, like 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) to authorize all registration requests from that agency 🫅. NOTE: all agency requests must pass through this individual 🚪.
- Send a letter on agency letterhead, 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 +1 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, the 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 an agency specifically requests that it not do so 📢.
A.1.2 Guidelines for NSAP Assignment 🧭
these are the recommendations an administrative authority should follow when making NSAP assignments, and they're lowkey the most important part of this whole section 🫶.
- The authority should determine the degree of structure of the DSP under its control. Further delegation of address assignment authority (resulting in additional levels of hierarchy in the NSAP) may be desired 🌳.
- The authority should make sure that portions of NSAPs that it specifies are unique, current, and accurate ✅.
- The authority should ensure that procedures exist for disseminating NSAPs to routing domains and to areas within each routing domain 📬.
- The systems administrator must determine whether a logical or a physical address should be used in the System Identifier field (Figure 2, Section 4.2). An example of a physical address is a 48-bit MAC address. A logical address is merely a number that meets the uniqueness requirements for the System Identifier field, but bears no relationship to an address on a physical subnetwork 🤓. We recommend that IDs should be assigned to be globally unique, as made possible by the method described in [18] 💖.
- The network address itself contains information that may be used to aid routing, but it does not contain a source route [12]. Information that enables next-hop determination based on NSAPs is gathered and maintained by each intermediate system through routing protocol exchanges 🛰️.
- GOSIP end systems and intermediate systems in federal agencies must be capable of routing information correctly to and from any subdomain defined by ISO 8348 🏛️.
- An agency may request the assignment of more than one Administrative Authority identifier. The particular use of each should be specified 🍓.
A.2 Data Country Code NSAPs 🌍
NSAPs from the Data Country Code (DCC) subdomain are also going to be common on the international Internet, bestie 🌏. ANS X3.216-1992 specifies the DSP structure under DCC=840 [1]. In the ANS, the DSP structure is identical to the one specified in GOSIP Version 2, except the Administrative Authority identifier is replaced by the numeric form of the ANSI-registered organization name, as shown in Figure 4 🎀.
Referring to Figure 4: when the value of the AFI is 39, the IDI denotes an ISO DCC, and the abstract syntax of the DSP is binary octets 🧠. The value of the IDI for the U.S. is 840, the three-digit numeric code for the United States under ISO 3166 [6]. The numeric form of the 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 procedures for registering numeric organization names in the U.S. are defined and fully operational ✨. To register one, the applicant has to submit a request for registration and the $1,000 (U.S.) fee to the registration authority, which is 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 can be obtained from the ANSI Registration Coordinator at the following address 📮:
Registration Coordinator
American National Standards Institute
11 West 42nd Street
New York, NY 10036
+1 212 642 4884 (tel)
+1 212 398 0023 (fax)
RFC822: mmaas@attmail.com
X.400: G=michelle; S=maas; A=attmail; C=usOnce an organization has registered with ANSI, it becomes a registration authority itself 👑. In turn, it may delegate registration authority to routing domains, and those may make further delegations, for instance from routing domains to areas 🌿. Again, the responsibilities of each Registration Authority are to make sure that NSAPs within the domain are unambiguous, and to advertise them as applicable 📣.
A.3 Summary of Administrative Requirements ✅
okay, the big picture 🦄: NSAPs must be globally unique, and an organization can make sure of this uniqueness for OSI addresses in two ways. The organization may apply to GSA for an Administrative Authority identifier. Although GSA's registration of Administrative Authority identifiers primarily serves U.S. Government agencies, requests from non-government and non-U.S. organizations will be considered on a case-by-case basis 🌐. Alternatively, the organization may apply to ANSI for a numeric organization name. Either way, the organization becomes the registration authority for its domain and can register NSAPs or delegate the authority to do so 💜.
In the case of GOSIP Version 2 NSAPs, the complete DSP structure is given in GOSIP Version 2. For ANSI DCC-based NSAPs, the DSP structure is specified in ANS X3.216-1992. The DSP structure is identical to the one specified in GOSIP Version 2 🫶✨.
📦 where this page comes from
- ietf: rfc1629 1994-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms