RFC 941
Addendum to the network service definition covering network layer addressing
Part 1 of 7 💖 more parts are coming, so hold on to your seat bestie ✨
RFC 941 🎀 The Title Block Tea
- Title: Addendum to the Network Service Definition Covering Network Layer Addressing
- Series: Network Working Group
- Also known as:
ISO/DP8348/DAD2(alsoTC 97/SC 6/N 3444) - Date: April 1985
- Author: Alex McKenzie, BBN Laboratories
- Issued by: ISO
- Category: Information. It's distributed for information only and does not specify a standard for the ARPA-Internet 📚
- Obsoletes / Updates: none listed in the original
Status of This RFC 🌸
okay so this doc is shared for information only 💅 It doesn't set a standard for the ARPA-Internet, and anyone is allowed to distribute it, no limits 🦋
Note: this doc was made by retyping the text of ISO/DP8348/DAD2 from October 1984, which is also numbered SC 6/N 3444. That ISO text was in a voting round as a Draft Proposed Addendum to the Network Service Definition. The RFC version was checked after typing and is believed to be mostly correct, but typos that aren't in the ISO original might have slipped through 🙈
Authors: Alex McKenzie, BBN Laboratories 🧚
ISO Statement on the Status of this Document 💜
At its meeting in Zurich, April 2-11, 1984, SC 6/WG 2 made document SC 6 N 3134. Following Resolution 49 from the SC 6 meeting in Tianjin (September 19-30, 1983), they sent it to the SC 6 Secretariat for registration and ballot as a first Draft Proposed Addendum to the Network Service Definition (ISO DP 8348/DAD2) ✨
The letter ballot on SC 6/N 3134 closed on August 20, 1984. The results were 10-4-0-3 [approve-disapprove-abstain-no vote]. The voting summary is in document SC 6/N 3229, and the late votes are in documents SC 6/N 3333 and SC 6/N 3360. These ballot results were reviewed at the SC 6/WG 2 meeting in Washington, October 15-25, 1984. Taking as many of the ballot comments into account as possible, they produced document SC 6/N 3444 as a progression of SC 6/N 3134. The Editor's report, in document SC 6/N 3445, describes how the member body comments on the DP 8348/DAD2 letter ballot were handled 🔥
A resolution from the SC 6 meeting in Washington, October 22-26, 1984, tells the SC 6 Secretariat to register SC 6/N 3444 as a second Draft Proposed Addendum to ISO 8348, and to circulate it for a two-month letter ballot 👑
Introduction ✨
This Addendum to the Network Service Definition Standard, ISO 8348, defines the abstract syntax and semantics of the Network Address (Network Service Access Point Address). The Network Address in this Addendum is the address that shows up in the primitives of the connection-mode Network Service as the calling address, called address, and responding address parameters. It also shows up in the primitives of the connectionless-mode Network Service as the source address and destination address parameters. It's giving main character energy 💖
Scope and Field of Application 🦋
The scope of this Addendum is defining the abstract syntax and semantics of the Network Address. It does not cover how the semantics of the NSAP address get encoded in Network Layer protocols. The field of application is the same one described in Clause 1 of the Network Service Definition (ISO 8348) 💅
2. References 📚
these are the docs this Addendum leans on, bestie. Keep them exact:
ISO 7498 Information Processing Systems - Open Systems
Interconnection - Basic Reference Model [Note: See also
CCITT Recommendation X.200]
DP 7498/DAD1 Information Processing Systems - Open Systems
Interconnection - Addendum to the Basic Reference Model
Covering Connectionless Data Transmission
DP 8509 Information Processing Systems - Open Systems
Interconnection - Service Conventions
ISO 8348 Information Processing Systems - Data Communications -
Network Service Definition [Note: See also CCITT
Recommendation X.213]
DIS 8348/DAD1 Information Processing Systems - Data Communications -
Addendum to the Network Service Definition Covering
Connectionless Data Transmission
DP 8648 Information Processing Systems - Data Communications -
Internal Organization of the Network Layer
ISO 6523 Data Interchange - Structure for the Identification of
Organizations
ISO 646 7-bit Coded Character Set for Information Processing
Interchange
ISO 2375 Procedure for the Registration of Escape Sequences
CCITT X.121 International Numbering Plan for Public Data Networks
CCITT E.163 Numbering Plan for the International Telephone Service
CCITT E.164 The Numbering Plan for the ISDN Era
CCITT F.69 Plan for Telex Destination CodesTemporary Note: the list of References in the published Addendum will contain only approved ISO Standards and CCITT Recommendations. Items may need to be subtracted from, or added to, the current list. (this is the "not final yet" warning, iykyk 🙈)
SECTION ONE - General 🌈
3. Definitions 🧚
3.1. Reference Model Definitions
This Addendum uses these terms from ISO 7498:
- a) Network layer
- b) Network service
- c) Network service access point
- d) Network service access point address
- e) Network entity
- f) Routing
- g) Network address
- h) Network protocol control information
- i) Network protocol data unit
3.2. Service Conventions Definitions
This Addendum uses these terms from ISO 8509:
- j) Service user
- k) Service provider
3.3. Network Layer Architecture Definitions
This Addendum uses these terms from ISO 8648 (Internal Organization of the Network Layer):
- l) Subnetwork
- m) Real subnetwork
- n) Subnetwork service
- o) Real end system
- p) Interworking unit
- q) Intermediate system
3.4. Network Addressing Definitions
This Addendum also uses these terms, defined right here 🦋
- r) DTE address: info used to identify a point of attachment to a public data network 📡
- s) Subnetwork point of attachment: this is a point where a real end system, interworking unit, or real subnetwork gets attached to a real subnetwork. It's also a conceptual point where a subnetwork service is offered inside an end or intermediate system 🫶
- t) Subnetwork address (Subnetwork point of attachment address): info used, in the context of one particular real subnetwork, to identify a subnetwork point of attachment. It's also info used, in the context of one particular subnetwork, to identify the point where the subnetwork service is offered inside an end or intermediate system 🌸
- u) Network protocol address information: info encoded in a network protocol data unit to carry the semantics of an NSAP address. (This is known as an "address signal" or as the "coding of an address signal" in the Public Data Network environment.) 💜
- v) Domain (of the OSI environment): a subset of the OSI environment where identifiers for OSI environment entities of the same type are unambiguous ✨
- w) Global network addressing domain: the set of all Network Service Access Point addresses in the OSI environment 🌍
- x) Network addressing subdomain: a subset of the global network addressing domain 🎀
- y) Authority (for a domain or subdomain): whatever makes sure identifiers inside the matching domain or subdomain are unambiguous 👑
4. Abbreviations 💅
This Addendum uses these abbreviations:
- a)
NSAP- Network Service Access Point - b)
NPAI- Network Protocol Addressing Information - c)
DCC- Data Country Code - d)
CC- Country Code - e)
ICD- International Code Designator - f)
PSTN- Public Switched Telephone Network - g)
ISDN- Integrated Services Digital Network - h)
IDP- Initial Domain Part - i)
AFI- Authority and Format Identifier - j)
IDI- Initial Domain Identifier - k)
DSP- Domain Specific Part - l)
NPDU- Network Protocol Data Unit - m)
SNPA- Subnetwork Point of Attachment
5. Conventions 🍓
No particular standard conventions are invoked by this Addendum. Nothing extra to juggle here, bestie 🫶
SECTION TWO - Network Layer Addressing 💖
6. Concepts and Terminology for Network Layer Addressing 🔥
6.1 Network Addresses ✨
Okay so "network address" is lowkey one of those phrases that means different things depending on who's talking 💅 This Addendum defines the Network Service Access Point (NSAP) address, and since people use "network address" for a bunch of different stuff, we're gonna get super specific below 🫶
6.1.1 Subnetwork Address 🌸
In one context, "network address" can mean the point where a real end system, real subnetwork, or interworking unit attaches to a real subnetwork, or the point where the subnetwork service is offered inside an end or intermediate system. When it's attached to a public data network, that point is called a DTE/DCE interface, and people say "DTE address" when they mean it 🦋
The specific term "subnetwork address" (or "subnetwork point of attachment address") is what we use here, and Figure 6-1 shows it:
subnetwork point of
attachment identified
________ by SNPA
________________ | | /\
| | |______|/ \_______
| Real End | ____________ Layer | * <-/ |\-> * | Layer
| system, real | | | 3 |______| |______| 3
|subnetwork, or|____| Real | | | | |
| interworking | |Subnetwork| | | | |
| unit | ^ |__________| |______| |______|
|______________| |
|
subnetwork point of End Intermediate
attachment identified System System
by subnetwork addressFigure 6-1 - Subnetwork Address
The subnetwork address is the info a real subnetwork needs in order to identify a particular real end system, another real subnetwork, or interworking unit that's attached to it 🧚
In the public network environment, the subnetwork address is what the public network operates on 💜
Note: The point identified by a subnetwork address is a point of interconnection between a real end system or interworking unit and a real subnetwork (in particular, in a public data network environment, a DTE/DCE interface), and is not an OSI Service Access Point. 🙈
6.1.2 NSAP address 🎀
In another context, "network address" refers to the Network Service Access Point (NSAP) where the OSI Network Service gets made available to a Network Service user by the Network Service provider 👑
The specific term "NSAP address" is used here, as Figure 6-2 shows:
Network Service User
layer 4
______________________________ 0 _____________________________
\
layer 3 \____NSAP identified
by NSAP address
Network Service ProviderFigure 6-2 - NSAP Address
The NSAP address is the info the OSI Network Service provider needs to identify a particular Network Service Access Point 🔥 The values of the called address, calling address, and responding address parameters in the N-CONNECT primitive, the responding address parameter in the N_DISCONNECT primitive, and the source address and destination address parameters in the N-UNIDATA primitive are all NSAP addresses. Iconic 😭
Quick thing: the Network Service primitives are conceptual, so the Network Service Definition doesn't specify any particular encoding of the NSAP address 🌈
In both CCITT and ISO usage, "Network Address" (with the N and the A in capitals) and "global network address" are synonyms for "NSAP address". Using "NSAP address" is preferred when it's essential to avoid confusion, especially in spoken references where you can't do capitalization 🫶
6.1.3 Network Protocol Address Information 🦋
In a third context, "network address" refers to an address carried as network protocol control information in a network protocol data unit (NPDU) ✨
The specific term "network protocol address information" (NPAI) is what we use in this case 💅
In the public network environment, NPAI is also called an "address signal" or the "coding of an address signal" 🌸
Here's the connection: the NSAP address that shows up in Network Service primitives and the NPAI that shows up in a Network Layer protocol are related, because the semantics of the NSAP address are preserved by the NPAI. The syntax and encoding of NPAI are defined by Network layer Protocol standards, and those standards also specify how the NSAP address relates to the NPAI encoding the protocol uses 🧚💜
6.2 Domains 🌈
A domain is a subset of the Open Systems Interconnection environment where identifiers for OSI environment entities of the same type are unambiguous 👑
6.2.1 Global Network Addressing Domain ⭐
The global network addressing domain is defined as the set of all Network Service Access Point addresses in the OSI environment 🍓
6.2.2 Network Addressing Subdomain 🎀
A network addressing subdomain is a set of Network Service access Point addresses. It's a subset of the global network addressing domain 💖
The relationship between 6.2.1 and 6.2.2 is shown in Figure 6-3:
**************
***** *****
*** ***
*** ***
** ** ** ** <-- Global
** * * .** network
** ** ** . ** addressing
* * * . * domain
* * * . . *
* * * .. . *
* * * .. + *
* * * .. <-----------\
** * * .. + ** |
* + * * ..+ * |
* + * <------------------------------\|
* + * * ... + * |
* + * * ... + * |
* + * * .... + * |
* + * * + * |
* + ************************************ * |
* ********* + + ********* * |
** + + ** |
* + + * |
** + + ** |
* + + <-------------\|
* + + * |
* + + * |
* + + * |
* + + * |
** + + ** |
** + <--\ + ** |
** + \ + ** |
*** + \ + *** |
*** \ *** |
***** \**** |
***************\ Network
\------------- addressing
subdomainsFigure 6-3 - Domains and Subdomains 🔥
6.3 Authorities 💅
The uniqueness of identifiers within a domain or subdomain is ensured by an authority tied to that domain. "Authority" doesn't have to mean an organization or administration, lol. It's meant to refer to whatever it is (in an abstract sense) that keeps identifiers unique in the associated domain 🫶
Domains are characterized by the authority that runs them and by the rules that authority sets for specifying identifiers and identifying subdomains. The authority in charge of each subdomain decides how identifiers get assigned and interpreted in that subdomain, and how any further subdomains get created 🦋
An authority operates independently of other authorities on the same level of the hierarchy. The only thing that limits it is any common rules imposed by the parent authority 🌸
6.4 Network Address Allocation 💖
An addressing authority shall either allocate complete NSAP addresses, or shall authorize one or more other authorities to allocate address. Each address allocated by an addressing authority shall include a domain identifier that identifies the allocating authority. An address shall not be allocated to identify a domain or NSAP if the address has previously been allocated to some other domain or NSAP, unless the authority can ensure that all use of the previous allocation has ceased 🙈
The authority shall ensure that allocations are made so that efficient use is made of the address space 🧚
7 PRINCIPLES FOR CREATING THE OSI NETWORK ADDRESSING SCHEME 🌈
7.1 Hierarchical Structure of NSAP Addresses ✨
okay so NSAP addresses are built on hierarchical addressing domains (we went over those in Clause 6 🌸), and each domain can be split up even more into subdomains. So NSAP addresses have a hierarchical structure, and it's giving layers 💅
Here's the vibe: at any level of the hierarchy, the first part of the address uniquely points to a subdomain. Then the management of that subdomain fills in the rest, so it uniquely points to either a lower-level subdomain or an NSAP inside it. Which part counts as "the subdomain bit" depends on what level you're looking at the address from 🦋
Note: This conceptual structure should not be considered as implying any detailed administration of NSAP addresses. (It's a concept, not a rulebook for how anybody has to run things 🙈)
You can draw this hierarchy as an inverted tree diagram, like Figure 7-1 (a), or as a domain diagram, like Figure 7-1 (b) 🌈
O
|
|
-------------------------------
| | | |
| | | |
----- ----- ----- -----
| W | | X | | Y | | Z |
----- ----- ----- -----
| | |
| | |
--------------- @ --------
| | | | |
| | | | |
----- ----- ----- ----- -----
| a | | b | | c | | a | | b |
----- ----- ----- ----- -----
|
|
----------------------
| | | |
| | | |
----- ----- ----- -----
| p | | q | | r | | s |
----- ----- ----- -----Figure 7-1 (a) - Hierarchical Structure of NSAP Addresses Inverted Tree Diagram
**************
***** *****
*** ***
*** Z ***
** **
* *
*** ** ** ***
** ** * * ** **
** * ** ** * .**
** ** * * ** r . **
* * * * * . *
X * * * * * . ------------>* Y
* * * * * /. . s +*
* * * * * / .. + *
* * * * * / .. + *
** * * * * b .. + **
* + * * * * | ..+ *
* + * * * * | q + *
* + * ** * ..| + *
* + * * |... + a *
* + * * | p .... + *
* + * * V + *
* + ************************************ *
* ********* ********* *
** **
************************************
********* + + *********
** + + **
* + + *
** + + **
* + + c *
* a + + *
* + + *
* + b + *
* + + *
** + + **
** + + **
** + + **
*** + + ***
*** ***
***** *****
**************
WFigure 7-1 (b) - Hierarchical Structure of NSAP Addresses Domain Diagram
7.2 Global Identification of any NSAP 🌍
In the context of Open Systems Interconnection, it's possible to identify any NSAP within the global network addressing domain (see Clause 6.2.1). That means:
- a) At any Network Service Access Point, it's possible to identify any other Network Service Access Point, within any OSI end system;
- b) a global Network Address can therefore be defined to unambiguously identify any Network Service Access Point;
- c) the OSI protocols established between correspondent Network entities convey the complete information contained in a Network Address (see Clause 6.1.4);
- d) an NSAP address identifies the same NSAP regardless of which NS-user enunciated the address; and
- e) an NS-user, when given an NSAP address of the NS-provider in a primitive Indication, may subsequently use that NSAP address in another instance of communication with the corresponding NSAP.
Some restrictions may be placed on communications in the context of OSI, on the basis of technical feasibility of an interconnection, security, charging, etc. ngl those considerations aren't related to Network Layer addressing, so this Addendum doesn't discuss them 🙃
Note: The global identification of NSAPs should not be taken to imply the universal availability of directory functions required to enable communication among all NSAPs to which NSAP addresses have been allocated. (Global naming ≠ everyone can find everyone, bestie 💀)
7.3 Route Independence 🧭
Network Service users cannot derive routing information from an NSAP address. They can't influence the Network Service provider's choice of route using the source and destination NSAP addresses, and they also can't work out from those addresses which route was used by the Network Service provider. 🙅♀️
This isn't meant to rule out the idea that an OSI end system might need to influence the route it gets for a particular communication with another OSI end system. (Especially, it may need to influence which intermediate systems get used, and the paths to take between them.) The way that influence gets exerted is, however, not the NSAP address. Elements of Network Layer protocol may be required to control routing within intermediate systems, and those elements are distinct from the network protocol address information (NPAI) 🎀
Even with the limits on what a Network Service user can do with an NSAP address, NSAP addresses should still be constructed so that routing through interconnected subnetworks is facilitated. The Network Service provider, and relay-entities in particular, may take advantage of the address structure to process routing aspects economically ✨
7.4 Service Type Independence 💜
Network Service users may need to tell apart Network Layer services of different types, like point-to-point versus multipoint services, and connection-mode versus connectionless-mode services. The nature of those service types isn't explicitly contained in the semantics of the NSAP address. Same goes for Network Layer quality of service characteristics (like throughput, transit delay, etc.): they aren't explicitly specified by the NSAP address either 🫶
8 NETWORK ADDRESS DEFINITION 📖
The intent of this document is best served by keeping three concepts clearly distinct. 🌸 First, there are the abstract semantics of the NSAP address. Second, there's the abstract syntax, which this document uses to define those semantics and which addressing authorities use to allocate and assign addresses. Third, there's the concrete syntax, where the NSAP address semantics are encoded as NPAI in Network Layer protocols. Figure 8-1 shows how they all connect:
NSAP Address Semantics------->Allocation by------->Abstract Syntax
|
|
|-->Representation in--->External
| Humanly-readable Reference
| Directories Syntax
|
|-->Encoding in--------->Concrete Syntax
ProtocolsFigure 8-1 - Relationship of NSAP Address Semantics and Syntax
This Addendum does not specify the way in which the semantics of the NSAP address are encoded in Network Layer protocols. That's up to the Network Layer protocol specifications, which define the way the NSAP address is encoded as NPAI (see clause 6.1.4) 🦋
8.1 Network Address Semantics ✨
okay so the NSAP address is made of two basic semantic parts 💅 The first is the Initial Domain Part (IDP) and the second is the Domain Specific Part (DSP). Figure 8-2 shows the whole vibe 🦋
Remember the conceptual structure from Clause 7.1? The IDP is a subdomain identifier 🌸 It says which subdomain of the global network addressing domain (see Figure 7-1) we're in, and it names the authorities in charge of assigning addresses in each subdomain that gets created. The DSP is the matching subdomain address 💜 Whether the DSP gets its own further substructure is up to the authority the IDP points to. They can choose yes or no 🙈
8.1.1 The IDP
the IDP is itself split into two parts 🎀 The first is the Authority and Format Identifier (AFI) and the second is the Initial Domain Identifier (IDI). Figure 8-2 lays it out:
<----------------------NSAP ADDRESS------------------------->
___________________________________________________________
| | |
| IDP | DSP |
|___________|_______________________________________________|
:
:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
:
___________________________________________________________:
| | |
| AFI | IDI |
|___________|_______________________________________________|
Figure 8-2 - NSAP Address Structure8.1.1.1 The AFI
the AFI is the bit that does a lot of heavy lifting 🧚 It specifies:
- a) the format of the IDI (see clause 8.2.1.2);
- b) the authority responsible for allocating values of the IDI (see clause 8.2.1.2) and
- c) the abstract syntax of the DSP (see clauses 8.2 and 8.2.3).
8.1.1.2 The IDI
the IDI is giving address book energy 📒 It specifies:
- a) the Network Addressing subdomain from which values of the DSP are allocated; and
- b) the authority responsible for allocating values of the DSP from that subdomain.
8.1.2 The DSP
the DSP's meaning is decided by the authority identified by the IDI (see clause 8.1.1.2). So if you want to know what the DSP means, go ask the IDI's authority 💖 That's the whole main character moment 👑
8.2. Network Address Abstract Syntax ✨
The Network Address is defined in this Addendum using an abstract syntax that spells out its semantics 💅. Using that abstract syntax as a descriptive tool lets the Addendum give a complete written definition of the Network Address without locking it to one specific encoding of NPAI 🎀. It also names two alternative preferred concrete syntaxes of the Network Address, so Network Layer protocol specification standards can point to them and unambiguously define how the Network Address gets encoded as NPAI 🦋.
8.2.1. Abstract Syntax and Allocation of the IDP 🌸
This clause defines the abstract syntax of the AFI, the AFI values that are currently allocated, and the IDI formats that go with those allocated AFI values. Some of the currently allocated AFI values are reserved for assignment to new IDI formats that may be identified by ISO or CCITT. Assigning any of these AFI values to a new IDI format, whether ISO or CCITT is doing it, must be accompanied by an appropriate modification of this Addendum, following the rules ISO has set for revising International Standards. Allocating new AFI values is done by joint agreement between ISO and CCITT, and it will require an appropriate modification of this Addendum too 💖.
The abstract syntax of the IDP is decimal digits. Because of how the AFI is allocated (see Clause 8.1.1), the first decimal digit of the IDP can never be zero. That's an escape mechanism built in for protocols that hold incomplete NSAP addresses in a field that normally carries a complete one 🙈. When the NSAP address is represented as binary octets, the representation of the IDP is as defined in Clause 8.3.1.
The length of the IDP depends on the IDI format specified by the value of the AFI. The IDP length associated with each IDI format is given in clause 8.2.1.2.
8.2.1.1. Abstract Syntax and Allocation of the AFI 💜
The AFI is an integer with a value between 0 and 99, and its abstract syntax is two decimal digits. The values of the AFI are allocated or reserved as shown in Table 8-1:
Table 8-1: AFI ALLOCATIONS
00-09 Reserved - will not be allocated
10-35 Reserved for future allocation by joint agreement
of ISO and CCITT
36-51 Allocated and assigned to the IDI formats defined
in clause 8.2.1.2
52-59 Reserved for future allocation by joint agreement
of ISO and CCITT
60-69 Allocated for assignment to new IDI formats by
ISO
70-79 Allocated for assignment to new IDI formats by
CCITT
80-99 Reserved for future allocation by joint agreement
of ISO and CCITT8.2.1.2. Format and Allocation of the IDI 🧚
A specific combination of IDI format and DSP abstract syntax is associated with each allocated AFI value, as summarized in Table 8-2:
___________________
| DSP Syntax |
|___________________|
| | |
__________| Decimal | Binary |
|IDI format| | |
|__________|_________|_________|
| X.121 36 37 |
|______________________________|
| ISO DCC 38 39 |
|______________________________|
| F.69 40 41 |
|______________________________|
| E.163 42 43 |
|______________________________|
| E.164 44 45 |_____________________
|______________________________|Character | National |
|ISO 6523-ICD 46 47 |(ISO 646) |Character |
|______________________________|__________|__________|
| Local 48 49 50 51 |
|____________________________________________________|The IDI formats are defined as follows:
a) X.121 📮 The IDI is a sequence of up to 14 digits allocated according to CCITT Recommendation X.121. That X.121 number identifies an authority responsible for allocating and assigning values of the DSP. IDP length: Up to 16 digits.
b) ISO DCC 🌍 The IDI is a three-digit Data Country Code (DCC). ISO DCC values are allocated by ISO and assigned to ISO member countries or appropriately sponsored non-member countries or authorities. The ISO DCC values are a subset of the DCC values that CCITT allocated in Recommendation X.121 to countries or geographical areas. The DSP is allocated and assigned by the organization representing the country identified by the DCC. IDP length: 5 digits.
c) F.69 📠 The IDI is a telex number of up to 8 digits, allocated according to CCITT Recommendation F.69, starting with a 2- or 3-digit destination code. The telex number identifies an authority responsible for allocating and assigning values of the DSP. IDP length: Up to 10 digits.
d) E.163 ☎️ The IDI is a public switched telephone network (PSTN) number of up to 12 digits allocated according to CCITT Recommendation E.163, starting with the PSTN country code. The PSTN number identifies an authority responsible for allocating and assigning values of the DSP. IDP length: Up to 14 digits.
e) E.164 📱 The IDI is an ISDN number of up to 15 digits allocated according to CCITT Recommendation E.164, starting with the ISDN country code. The ISDN number identifies an authority responsible for allocating and assigning values of the DSP. IDP length: Up to 17 digits.
f) ISO 6523-ICD 🏢 The IDI is a 4-digit International Code Designator (ICD) allocated according to ISO 6523. The ICD identifies an organizational authority responsible for allocating and assigning values of the DSP. The "structure of the code" required by ISO 6523, clause 6.3(d), shall be registered as "According to ISO 8348 Addendum 2". IDP length: 6 digits.
g) LOCAL 🏠 The IDI is null. IDP length: 2 digits.
Note 1: In cases (a), (c), (d), and (e) above, when the IDP is followed by a decimal-syntax DSP, this Addendum doesn't identify any discernible boundary between the IDP digits and the DSP digits.
Note 2: A figure illustrating how the global network addressing domain is divided according to these formats is contained in Annex B 🗺️.
Note 3: Using a particular IDI format as the basis for allocating an NSAP address doesn't force routing to that NSAP to go through any particular subnetwork. For example, using the E.163 IDI format to allocate an NSAP address doesn't mean that access to the NSAP necessarily involves the telephony subnetwork (see clause 7.3) 📞🙅♀️.
Note 4: Formats a, c, d, and e are based on specific CCITT numbering plans, so they may be affected by any changes to those plans. In identifying and describing these formats, this Addendum observes the current status of CCITT work on numbering plans. It doesn't establish any preference or position whatsoever about how CCITT may choose to modify the plans, or their relationships with one another, in the future. Changes to this may be necessary to take any such further work by CCITT into account. For example, the CCITT numbering plans in some cases may provide escape mechanisms (such as a zero, 8, or 9 prefix) from one numbering plan to another. This creates a possible choice about which of formats a, c, d, and e should be used to allocate NSAP addresses, and it may also lead to suggestions that it's not necessary to include all of formats a, c, d, and e in this Addendum. Such choices, however, are made within the context and responsibility of CCITT, and no preference for one choice or another is made or implied by this Addendum 🫶.
8.2.2. Abstract Syntax and Allocation of the DSP 🎀
Values of the DSP are allocated by the authority identified by the IDI, in the syntax identified by the AFI (see clauses 8.1.1.2 and 8.2.1.2).
The allocating authority specifies the format and semantics of the DSP. If the authority identified by the IDI authorizes one or more authorities to allocate semantic parts of the DSP, then all of those authorities must allocate using the same abstract syntax that the parent authority used.
An authority may choose to allocate NSAP addresses with the DSP in a decimal or binary abstract syntax for all IDI formats. It may also choose to allocate NSAP addresses with the DSP in a character (ISO 646) or National Character abstract syntax when the IDI format is "Local" (see Table 8-2). Clause 9 describes the latter case in detail 🌈.
8.2.3. Abstract Syntax of the DSP 💅
The DSP may be allocated by the responsible authority in one of four syntaxes, depending on the value of the AFI:
- a) Binary: The DSP consists of zero or more binary octets, up to the maximum specified in Table 8-3.
- b) Decimal: The DSP consists of zero or more decimal digits, up to the maximum specified in Table 8-3.
- c) Character: The DSP consists of zero or more of those graphic characters with no national variant, plus the space character, from ISO 646, up to the maximum specified in Table 8-3.
- d) National Character: The DSP consists of zero or more characters from a character set determined by the allocating authority, up to the maximum specified in Table 8-3.
Table 8-3 gives the maximum length of the DSP in its abstract syntax for each of the IDI formats defined in clause 8.2.1.2. The corresponding total NSAP address lengths are given in clause 8.4 ✨
8.3. Network Address Concrete Syntax ✨
okay so, like we said in Clause 8.1, the NSAP address semantics are made of three fields, in this exact order 💅
- a) the AFI, with an abstract syntax of two decimal digits;
- b) the IDI, with an abstract syntax of a variable number of decimal digits; and
Here's Table 8-3, the maximum DSP lengths 🎀
___________________
| DSP Syntax |
|___________________|
| | |
__________| Decimal | Binary |
|IDI format| | |
|__________|_________|_________|
| X.121 24 9 |
|______________________________|
| ISO DCC 35 14 |
|______________________________|
| F.69 30 12 |
|______________________________|
| E.163 26 10 |
|______________________________|
| E.164 23 9 |_____________________
|______________________________|Character | National |
|ISO 6523-ICD 34 13 |(ISO 646) |Character |
|______________________________|__________|__________|
| Local 38 15 19 7 |
|____________________________________________________|- c) the DSP, with an abstract syntax of a variable number of one and only one of the following types: binary octets, decimal digits, characters, or national characters.
This Addendum does not specify how the semantics of an NSAP address get encoded in Network Layer protocols with a concrete syntax in NPAI (see the Note after this clause). Those encodings are specified in Network Layer protocol standards 🦋
Note: Encoding implies more than a concrete syntax. It also covers things like the order of bit transmission, representation as tones or other signals, and so on.
Nevertheless, this Addendum identifies two alternative concrete syntaxes (see clauses 8.3.1 and 8.3.2) for the Network Address 💜 Network Layer protocol specification standards can refer to these. The concrete syntax used to encode the Network Address as NPAI in a Network Layer protocol may happen to be identical to one of these, but it is not required that this be the case (see clause 9).
The entire NSAP address, taken as a whole, may be represented explicitly as a string of either decimal digits (decimal concrete syntax) or binary octets (binary concrete syntax), as defined below. Network Layer protocol specifications that reference this Addendum shall specify how either the decimal concrete syntax or the binary concrete syntax of the NSAP address (or both) is encoded as NPAI (see clause 6.1.3) 🫶
8.3.1. Binary Concrete Syntax
The binary concrete syntax is generated by:
- a) using two semi-octets to represent the two digits of the AFI, giving each semi-octet a value in the range 0000-1001;
- b) padding the IDI with leading zero digits if necessary to reach the maximum IDI length (specified for each IDI format in clause 8.2.1.2), then using a semi-octet to represent the value of each decimal digit (including any leading padding digits), giving a value in the range 0000-1001; and, if the DSP syntax is not decimal digits, using the semi-octet value 1111 as a pad after the final semi-octet (if necessary) to get an integral number of octets;
- c) representing a decimal syntax DSP using the technique described in (b);
- d) representing a binary syntax DSP directly as binary octets;
- e) when the IDI format is "Local", representing an ISO 646 character syntax DSP by converting each character to a number in the range 32-127 using the ISO 646 encoding (with zero parity and the parity bit in the most significant position), reducing the value by 32 to get a number in the range 0-95, encoding this result as a pair of decimal digits, and applying the technique described in (b); and
- f) when the IDI format is "Local", representing a National Character syntax DSP by converting each national character to either one or two octets, according to the rules specified by the authority responsible for allocating NSAP addresses, including national character DSP syntaxes.
8.3.2. Decimal Concrete Syntax
The decimal concrete syntax is generated by:
- a) representing the two digits of the AFI directly as two decimal digits;
- b) padding the IDI with leading zero digits if necessary to reach the maximum IDI length (specified for each IDI format in Clause 8.2.1.2), then representing the result directly as decimal digits;
- c) representing a decimal syntax DSP directly as decimal digits;
- d) representing a binary syntax DSP as follows:
Taking the octets in pairs, convert each octet of the pair to a number in the range 0-255. This generates six decimal digits, abcdef, of which digits a and d may take on only the values 0, 1, or 2. The pair of octets is represented by the sequence of five digits gbcef, where the value of digit g is given in Table 8-4 (shown below).
Table 8-4: Values of g.
_____________________________
| \ a | | | |
| d \ | 0 | 1 | 2 |
|____\___|______|______|______|
| 0 0 1 2 |
|_____________________________|
| 1 3 4 5 |
|_____________________________|
| 2 6 7 8 |
|_____________________________|If the original binary field contained an odd number of octets, the final octet is converted to a number in the range 0-255 and represented as three decimal digits (000-255).
- e) when the IDI format is "Local", representing an ISO 646 character syntax DSP using the technique described in Clause 8.3.1 (e); and
- f) when the IDI format is "Local", representing a National Character syntax DSP using the technique described in Clause 8.3.1 (f).
8.4. Maximum Network Address Length 📏
The maximum length of the NSAP address for each combination of IDI abstract syntax is given in Table 8-5, for both the decimal concrete syntax and the binary concrete syntax.
Table 8-5: Maximum NSAP Address Lengths
________________________________________________________________
| | DSP Abstract | Binary DSP | Decimal DSP |
| IDI Format | syntax | concrete syntax concrete syntax|
|_____________|_______________|_________________|______________|
| | Decimal | 20 octets | 40 digits |
| X.121 | Binary | 17 octets | 39 digits |
| | | | |
| | Decimal | 20 octets | 40 digits |
| ISO DCC | Binary | 17 octets | 40 digits |
| | | | |
| | Decimal | 20 octets | 40 digits |
| F.69 | Binary | 17 octets | 40 digits |
| | | | |
| | Decimal | 20 octets | 40 digits |
| E.163 | Binary | 17 octets | 39 digits |
| | | | |
| | Decimal | 20 octets | 40 digits |
| E.164 | Binary | 18 octets | 40 digits |
| | | | |
| | Decimal | 20 octets | 40 digits |
| ISO 6523-ICD| Binary | 16 octets | 39 digits |
| | | | |
| | Decimal | 20 octets | 40 digits |
| LOCAL | Binary | 16 octets | 40 digits |
| | Character | 20 octets | 40 digits |
| |National Char. | 15 octets | 37 digits |
|_____________|_______________|_________________|______________|Note: These values assume a National Character representation of one character as two binary octets (see clause 8.2.3).
From this table, it is clear that:
- a) the maximum length of an NSAP address in its binary concrete syntax is 20 octets; and
- b) the maximum length of an NSAP address in its decimal concrete syntax is 40 digits.
A Network Layer protocol that is capable of conveying a variable-length string with a maximum length of either 20 binary octets or 40 decimal digits is capable of encoding the full semantic content of any Network Address 🌸
9. CHARACTER BASED DSP ALLOCATION 🌈
An authority may choose to allocate NSAP addresses with the DSP in a National Character syntax. In such cases, the allocating authority must define and publish the mapping of the National Character syntax to either a binary abstract syntax or a decimal abstract syntax.
Note: It is recommended that this mapping be done by reference to the ISO Register of Character Sets, which is maintained by the European Computer Manufacturers Association (ECMA) acting as a registration authority according to ISO 2375, "Procedure for the Registration of Escape Sequences".
In the case where the authority defines and publishes the mapping of the National Character set to a binary abstract syntax, the result must be representable in either one or two octets per National Character. In this case, the resulting DSP is considered to be based on the Binary abstract syntax. AFI values from Table 8-2, and the mapping to binary and decimal concrete syntaxes, are based on the binary abstract syntax.
In the case where the authority defines and publishes the mapping of the National Character set to a decimal abstract syntax, the result must be representable in up to five decimal digits per National Character. In this case, the resulting DSP is considered to be based on the decimal abstract syntax. AFI values from Table 8-2, and the mapping to binary and decimal concrete syntaxes, are based on the decimal abstract syntax.
Note: Being able to base DSP allocation on National Character sets lets DSP allocation be based on international character sets. This may simplify address assignment in some cases, and may facilitate representing NSAP addresses in a humanly readable form. Nevertheless, NSAP addresses should not be confused with Application Layer entity titles. NSAP addresses are not intended to offer the same degree of human-readable, user-friendly naming and addressing capabilities that you might expect from Application Layer entity titles 🙈
10. REFERENCE PUBLICATION FORMATS 📝
Reference publication formats are defined to allow unambiguous representation of NSAP addresses in both written and oral communication.
10.1. Decimal Reference Publication Format
The Decimal reference publication form (DRPF) consists of a string of up to 40 decimal digits. The DRPF is the written inscription of the decimal concrete syntax defined in clause 8.3.2 🍓
10.2. Hexadecimal Reference Publication Format
The Hexadecimal reference publication format (HRPF) consists of the symbol "/" (solidus) followed by a string of up to 40 hexadecimal digits. The HRPF is the written inscription of the binary concrete syntax defined in clause 8.3.1, using two hexadecimal digits ranging from 00 through FF to represent each binary octet 🦄
ANNEX A - NETWORK ENTITY TITLES 👑
This Annex is an integral part of the Addendum, so it's not optional, bestie 🎀
To do routing and share Network Layer management info about routing between Network entities, we need to be able to unambiguously identify Network entities in end systems and intermediate systems 🦋 The Reference Model (ISO 7498) defines the concept of an (N)-entity title, which can be used to permanently and unambiguously identify a Network entity in an end system or intermediate system ✨
Any authority that allocates addresses to NSAPs may also choose to allocate Network entity titles 💅 One way to do that is to use the principles and mechanisms defined in this Addendum for allocating Network addresses. When you go that route, a Network entity title has the same abstract syntax as an NSAP address. A value may be allocated as a Network entity title only if it has not already been allocated as an NSAP address 🙈
ANNEX B - NSAP ADDRESS ALLOCATION 🗺️
This Annex is not an integral part of the Addendum.
The split of the global Network addressing domain by the IDI formats described in clause 8.2.1.2 can be pictured with the following figure. The numbers next to each line in the figure are AFI values, as defined in Table 8-2 of clause 8.2.1.2.
Figure B-1 - NSAP Address Allocation on attached page.
Here's the breakdown of the AFI ranges 💖
00-09 Reserved - will not be allocated
10-35 Reserved for future allocation by joint agreement of ISO
and CCITT
36-37 X.121
38-39 ISO DCC
40-41 F.69
42-43 E.163
44-45 E.164
46-47 ISO ICD
48-51 Local
52-59 Reserved for future allocation by joint agreement of ISO
and CCITT
60-69 Allocated for assignment by ISO
70-79 Allocated for assignment by CCITT
80-99 Reserved for future allocation by joint agreement of ISO
and CCITTANNEX C - RATIONALES 📚
This annex contains tutorial and explanatory material, and is not an integral part of the Addendum. It's the "here's why we did it" section, so it's giving lore 🧚
C.1 IDI FORMATS (Clause 8.2.1.2)
The reason for the specific IDI formats in Clause 8.2.1.2 is to let NSAP addresses be allocated and assigned based on existing, well-established network numbering plans and organization-identification standards 🌸
The CCITT numbering plans are included so that the organization a number is assigned to can act as an authority for assigning NSAP addresses. If that organization decides not to define any further sub-addressing beyond that number, then the number itself is an NSAP address when used in the OSI environment. This flexibility means a number allocated from any of the four CCITT numbering plans identified in Clause 8.2.1.2 can be used directly as an NSAP address, with nothing added except the initial AFI digits that identify the plan 💅
The ISO DCC format is included so that, where national regulations permit, the organization that represents a country in ISO (or an appropriately sponsored organization) can be designated as an authority for assigning geographically based NSAP addresses 🌈 How addresses are allocated and assigned in the ISO DCC format is up to that designated organization, which might, for example, be the national standards body that represents a country in ISO.
The ISO 6523-ICD format is included so that, where national regulations permit, an organization can be designated as an authority for assigning NSAP addresses. That organization may or may not be tied to a particular country, and it follows the hierarchy appropriate for it (which may not be based on geographical or national boundaries) 🌍 How addresses are allocated and assigned in the ISO 6523-ICD format is up to the designated organization, which might, for example, be the United Nations World Health Organization.
The Local format is included so that proprietary or other non-standard network addressing schemes can coexist with the standard OSI network addressing scheme 🧩 Using the Local format for these non-standard addresses makes sure they can't be confused with standard OSI network addresses. This will be handy as existing networks evolve to OSI, and for fitting non-OSI addressing schemes that may be used in proprietary network architectures or for testing and other interim purposes. It's important to stress that the Local format is not meant to give non-OSI schemes a permanent place in OSI. It's there so the OSI network addressing scheme can be used wherever possible without risk of conflict with other schemes, which can be safely encapsulated under the Local format 🫶
C.2 RESERVATION OF AFI VALUES 00-09 (Table 8-2)
Reserving AFI values that begin with the digit 0 is meant to allow an initial 0 to handle special cases, such as:
- a) as an escape to some other addressing scheme;
- b) as a technique for optimizing NSAP address encoding in Network Layer protocols, when the different parts of the NSAP address semantics are encoded in different fields of the protocol header;
- c) as a way to indicate, in a protocol header, that a field that ordinarily contains a full NSAP address actually contains something less than a full address (for example, a shorthand form that leaves out the higher-order domains, which might be used for communication within a particular subdomain environment).
There may be other cases where an initial 0 digit turns out to be useful 👀 This Addendum only reserves the AFI values 00-09, and it doesn't specify how they might be used. All such uses are outside the scope of this Addendum.
C.3 DERIVATION OF THE CONCRETE SYNTAXES (Clause 8.3)
When describing the two "preferred" concrete syntaxes of the NSAP address, Clauses 8.3.1 and 8.3.2 introduce two types of padding: padding with zero digits at the beginning of an IDI, and padding with a semi-octet with the value 1111 at the end of the binary encoding of an IDI that has an odd number of decimal digits 🧁
The first type of padding is needed because some IDI formats allow the IDI to consist of a variable number of digits. There's no explicit syntactic marker between the IDI and the DSP, so the only way to find where the IDI ends is to know how long it is. The AFI tells you which IDI format is used, but it only lets you determine the maximum length of that IDI. Rather than add a specific syntactic marker or a new field holding the length of the IDI (either of which would have made encoding and parsing NSAP addresses a whole lot more complicated), the Addendum specifies that the IDI must first be padded out to its maximum length for encoding purposes. Note that this does not apply to the DSP; only to the IDI 💅
The second type of padding is needed to make sure that the binary encoding of the IDI consists of a whole number of binary octets 🎀
📦 where this page comes from
- ietf: rfc941 1985-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms