summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc941.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc941.txt')
-rw-r--r--doc/rfc/rfc941.txt1973
1 files changed, 1973 insertions, 0 deletions
diff --git a/doc/rfc/rfc941.txt b/doc/rfc/rfc941.txt
new file mode 100644
index 0000000..ec66a3e
--- /dev/null
+++ b/doc/rfc/rfc941.txt
@@ -0,0 +1,1973 @@
+Network Working Group ISO
+Request for Comments: 941 April 1985
+
+ Addendum to the Network Service Definition Covering
+ Network Layer Addressing
+
+
+ ISO/DP8348/DAD2
+ (also TC 97/SC 6/N 3444)
+
+Status of this RFC:
+
+ This document is distributed as an RFC for information only. It does
+ not specify a standard for the ARPA-Internet. Distribution of this
+ document is unlimited.
+
+Note:
+
+ This document has been prepared by retyping the text of ISO/DP8348/DAD2
+ of October 1984 (also numbered SC 6/N 3444), which is currently
+ undergoing voting within ISO as a Draft Proposed Addendum to the
+ Network Service Definition. Although this RFC has been reviewed after
+ typing, and is believed to be substantially correct, it is possible
+ that typographic errors not present in the ISO document have been
+ overlooked.
+
+Alex McKenzie
+BBN Laboratories
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 1]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ISO Statement on the Status of this Document.
+
+At its meeting in Zurich, April 2-11, 1984, SC 6/WG 2 produced document
+SC 6 N 3134 and, in accordance with Resolution 49 of the SC 6 meeting in
+Tianjin (September 19-30, 1983), forwarded 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
+of the ballot were 10-4-0-3 [approve-disapprove-abstain-no vote]; the
+summary of voting is contained in document SC 6/N 3229 (late votes are
+contained in documents SC 6/N 3333 and 3360). These ballot results were
+reviewed at the SC 6/WG 2 meeting in Washington, October 15-25, 1984,
+and document SC 6/N 3444 was produced as a progression of SC 6/N 3134,
+taking into account as many of the ballot comments as possible. The
+Editor's report, contained in document SC 6/N 3445, describes the
+disposition of member body comments on the DP 8348/DAD2 letter ballot.
+
+A resolution of the SC 6 meeting in Washington, October 22-26, 1984,
+instructs the SC 6 Secretariat to register document 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 defined in
+this Addendum is the address that appears in the primitives of the
+connection-mode Network Service as the calling address, called address,
+and responding address parameters, and in the primitives of the
+connectionless-mode Network Service as the source address and
+destination address parameters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 2]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ SCOPE AND FIELD OF APPLICATION
+
+The scope of this Addendum is the definition of the abstract syntax and
+semantics of the Network Address. This Addendum does not specify the
+way in which the semantics of the NSAP address are encoded in Network
+Layer protocols. The field of application of this Addendum is the same
+as the field of application described in Clause 1 of the Network Service
+Definition (ISO 8348).
+
+2 REFERENCES
+
+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 Codes
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 3]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+Temporary 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 4]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+SECTION ONE - GENERAL
+---------------------
+
+3 DEFINITIONS
+
+3.1 Reference Model Definitions
+
+ This Addendum makes use of the following terms defined in 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 makes use of the following terms defined in ISO 8509:
+
+ j) Service user
+
+ k) Service provider
+
+3.3 Network Layer Architecture Definitions
+
+ This Addendum makes use of the following terms defined in 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
+
+
+ISO/TC-97/SC-6 [Page 5]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+3.4 Network Addressing Definitions
+
+ This Addendum makes use of the following terms as defined below:
+
+ r) DTE address: information used to identify a point of attachment to
+ a public data network.
+
+ s) Subnetwork point of attachment: a point at which a real end system,
+ interworking unit, or real subnetwork is attached to a real
+ subnetwork, and a conceptual point at which a subnetwork service is
+ offered within an end or intermediate system.
+
+ t) Subnetwork address (Subnetwork point of attachment address):
+ information used in the context of a particular real subnetwork to
+ identify a subnetwork point of attachment, or information used in
+ the context of a particular subnetwork to identify the point at
+ which the subnetwork service is offered within an end or
+ intermediate system.
+
+ u) Network protocol address information: information 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
+ within which 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): that which ensures that
+ identifiers within the corresponding domain or subdomain are
+ unambiguous.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 6]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+4 ABBREVIATIONS
+
+This Addendum makes use of the following 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 7]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+SECTION TWO - NETWORK LAYER ADDRESSING
+--------------------------------------
+
+6 CONCEPTS AND TERMINOLOGY FOR NETWORK LAYER ADDRESSING
+
+6.1 Network Addresses
+
+ This Addendum defines the Network Service Access Point (NSAP)
+ address. Since the term "network address" is commonly used in different
+ contexts to refer to different things a more specific description of
+ this concept is introduced below.
+
+ 6.1.1 Subnetwork Address
+
+ In one context, the term "network address" may be used to refer to the
+ point at which a real end system, real subnetwork, or interworking
+ unit is attached to a real subnetwork, or to the point at which the
+ subnetwork service is offered within an end or intermediate system.
+ In the case of attachment to a public data network, this point is
+ called a DTE/DCE interface, and the term "DTE address" is used in
+ reference to it.
+
+ The specific term "subnetwork address" (or "subnetwork point of
+ attachment address") is used in this case, as illustrated in Figure
+ 6-1:
+
+
+ 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 address
+
+ Figure 6-1 - Subnetwork Address
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 8]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ The subnetwork address is the information that a real subnetwork needs
+ to identify a particular real end system, another real subnetwork, or
+ interworking unit that is attached to that real subnetwork.
+
+ 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, the term "network address" is used to refer to the
+ Network Service Access Point (NSAP) at which the OSI Network Service
+ is made available to a Network Service user by the Network Service
+ provider.
+
+ The specific term "NSAP address" is used in this case, as illustrated
+ in Figure 6-2:
+
+
+ Network Service User
+
+ layer 4
+ ______________________________ 0 _____________________________
+ \
+ layer 3 \____NSAP identified
+ by NSAP address
+
+ Network Service Provider
+
+ Figure 6-2 - NSAP Address
+
+ The NSAP address is the information that 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, of the responding
+ address parameter in the N_DISCONNECT primitive, and of the source
+ address and destination address parameters in the N-UNIDATA primitive,
+ are NSAP addresses.
+
+ Note that since the Network Service primitives are conceptual, no
+ particular encoding of the NSAP address is specified by the Network
+ Service Definition.
+
+ In both CCITT and ISO usage, the terms "Network Address" (with both
+ the N and the A printed in capital letters) and "global network
+ address" are synonymous with the term "NSAP address". Use of the term
+
+
+
+ISO/TC-97/SC-6 [Page 9]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ "NSAP address" is preferred when it is essential to avoid confusion,
+ particularly in spoken references where "capitalization" is not
+ possible.
+
+ 6.1.3 Network Protocol Address Information
+
+ In a third context, the term "network address" is used to refer to an
+ address that is carried as network protocol control information in a
+ network protocol data unit (NPDU).
+
+ The specific term "network protocol address information" (NPAI) is
+ used in this case.
+
+ In the public network environment, NPAI is also known as an "address
+ signal" or as the "coding of an address signal".
+
+ There is a relationship between the NSAP address that appears in
+ Network Service primitives and the NPAI that appears in a Network
+ Layer protocol, in that the semantics of the NSAP address is preserved
+ by the NPAI. The syntax and encoding of NPAI are defined by Network
+ layer Protocol standards, which also specify the relationship between
+ the NSAP address and the NPAI encoding employed by the protocol.
+
+6.2 Domains
+
+ A domain is a subset of the Open Systems Interconnection environment
+ within which 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 is a subset of the global network addressing
+ domain.
+
+ The relationship of the concepts of 6.2.1 and 6.2.2 is illustrated by
+ Figure 6-3:
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 10]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+
+ **************
+ ***** *****
+ *** ***
+ *** ***
+ ** ** ** ** <-- Global
+ ** * * .** network
+ ** ** ** . ** addressing
+ * * * . * domain
+ * * * . . *
+ * * * .. . *
+ * * * .. + *
+ * * * .. <-----------\
+ ** * * .. + ** |
+ * + * * ..+ * |
+ * + * <------------------------------\|
+ * + * * ... + * |
+ * + * * ... + * |
+ * + * * .... + * |
+ * + * * + * |
+ * + ************************************ * |
+ * ********* + + ********* * |
+ ** + + ** |
+ * + + * |
+ ** + + ** |
+ * + + <-------------\|
+ * + + * |
+ * + + * |
+ * + + * |
+ * + + * |
+ ** + + ** |
+ ** + <--\ + ** |
+ ** + \ + ** |
+ *** + \ + *** |
+ *** \ *** |
+ ***** \**** |
+ ***************\ Network
+ \------------- addressing
+ subdomains
+
+ Figure 6-3 - Domains and Subdomains
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 11]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+6.3 Authorities
+
+ The uniqueness of identifiers within a domain or subdomain is ensured
+ by an authority associated with that domain. The term "authority" does
+ not necessarily refer to an organization or administration: it is
+ intended to refer to whatever it is (in an abstract sense) that ensures
+ the uniqueness of identifiers in the associated domain.
+
+ Domains are characterized by the authority that administers the domain
+ and by the rules that are established by that authority for specifying
+ identifiers and identifying subdomains. The authority responsible for
+ each subdomain determines how identifiers will be assigned and
+ interpreted within that subdomain, and how any further subdomains will
+ be created.
+
+ The operation of an authority is independent of that of other
+ authorities on the same level of the hierarchy, subject only to 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 which 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 in such a way 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
+
+ NSAP addresses are based on the concept of hierarchical addressing
+ domains, as explained in Clause 6. Each domain may be further
+ partitioned into subdomains. Accordingly, NSAP addresses have a
+ hierarchical structure.
+
+ The conceptual structure of NSAP addresses follows the principle that,
+ at any level of the hierarchy, an initial part of the address
+ unambiguously identifies a subdomain, and the rest is allocated by the
+ management of the subdomain to unambiguously identify either a lower
+ level subdomain or an NSAP within the subdomain. The part of the
+ address that identifies the subdomain depends on the level at which the
+ address is viewed.
+
+
+
+
+ISO/TC-97/SC-6 [Page 12]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ Note: This conceptual structure should not be considered as implying
+ any detailed administration of NSAP addresses.
+
+ Graphical representation of the hierarchical structure of NSAP
+ addresses may be made according to an inverted tree diagram, as in
+ Figure 7-1 (a), or a domain diagram, as in 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 13]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+
+ **************
+ ***** *****
+ *** ***
+ *** Z ***
+ ** **
+ * *
+ *** ** ** ***
+ ** ** * * ** **
+ ** * ** ** * .**
+ ** ** * * ** r . **
+ * * * * * . *
+ X * * * * * . ------------>* Y
+ * * * * * /. . s +*
+ * * * * * / .. + *
+ * * * * * / .. + *
+ ** * * * * b .. + **
+ * + * * * * | ..+ *
+ * + * * * * | q + *
+ * + * ** * ..| + *
+ * + * * |... + a *
+ * + * * | p .... + *
+ * + * * V + *
+ * + ************************************ *
+ * ********* ********* *
+ ** **
+ ************************************
+ ********* + + *********
+ ** + + **
+ * + + *
+ ** + + **
+ * + + c *
+ * a + + *
+ * + + *
+ * + b + *
+ * + + *
+ ** + + **
+ ** + + **
+ ** + + **
+ *** + + ***
+ *** ***
+ ***** *****
+ **************
+ W
+
+ Figure 7-1 (b) - Hierarchical Structure of NSAP Addresses
+ Domain Diagram
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 14]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+7.2 Global Identification of any NSAP
+
+ In the context of Open Systems Interconnection, it is possible to
+ identify any NSAP within the global network addressing domain (see
+ Clause 6.2.1). Consequently,
+
+ a) At any Network Service Access Point, it is 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. Such considerations are not related to Network
+ Layer addressing, and therefore are not discussed in this Addendum.
+
+ 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.
+
+7.3 Route Independence
+
+ Network Service users cannot derive routing information from an NSAP
+ address. They cannot influence the Network Service provider's choice of
+ route by means of the source and destination NSAP addresses. Similarly,
+ they cannot deduce from the source and destination NSAP addresses the
+ route that was used by the Network Service provider. This is not
+ intended to exclude the possibility that an OSI end system may need to
+ influence the route selected for a particular instance of communication
+ with another OSI end system. (In particular, it may need to influence
+ the selection of intermediate systems to be used, and the paths to be
+ taken between them.) The means whereby such an influence may be exerted
+ is, however, not the NSAP address. Elements of Network Layer protocol
+ may be required to control routing within intermediate systems; such
+ elements of protocol are distinct from the network protocol address
+ information (NPAI).
+
+ Notwithstanding the restrictions imposed on the use that a Network
+
+
+ISO/TC-97/SC-6 [Page 15]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ Service user may make of an NSAP address, it is recognized that NSAP
+ addresses should be constructed in such a way that routing through
+ interconnected subnetworks is facilitated. That is, the Network Service
+ provider and relay-entities in particular, may take advantage of the
+ address structure to achieve economical processing of routing aspects.
+
+7.4 Service Type Independence
+
+ It may be necessary for Network Service users to distinguish Network
+ Layer services of different types (such as point-to-point versus
+ multipoint services, and connection-mode versus connectionless-mode
+ services). The nature of such service types is not explicitly contained
+ in the semantics of the NSAP address. Similarly, Network Layer quality
+ of service characteristics (such as throughput, transit delay, etc.)
+ are not explicitly specified by the NSAP address.
+
+8 NETWORK ADDRESS DEFINITION
+
+The intent of this document is best served by maintaining clear
+distinctions among three concepts: the abstract semantics of the NSAP
+address; the abstract syntax employed in this document as a means of
+defining the abstract semantics of the NSAP address, and employed by
+addressing authorities as a means of allocating and assigning addresses;
+and the concrete syntax in which the NSAP address semantics are encoded
+as NPAI in Network Layer protocols. These distinctions are illustrated
+in Figure 8-1:
+
+
+
+ NSAP Address Semantics------->Allocation by------->Abstract Syntax
+ |
+ |
+ |-->Representation in--->External
+ | Humanly-readable Reference
+ | Directories Syntax
+ |
+ |-->Encoding in--------->Concrete Syntax
+ Protocols
+
+ Figure 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. Network Layer
+protocol specifications define the way in which the NSAP address is
+encoded as NPAI (see clause 6.1.4).
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 16]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+8.1 Network Address Semantics
+
+ The NSAP address consists of two basic semantic parts. The first part
+ is the Initial Domain Part (IDP). The second part is the Domain
+ Specific Part (DSP). This is illustrated by Figure 8-2.
+
+ Following the conceptual structure of NSAP addresses described in
+ Clause 7.1, the IDP is a subdomain identifier: it specifies the
+ subdomain of the global network addressing domain (see Figure 7-1), and
+ identifies the authorities responsible for assigning addresses in each
+ of the subdomains created. The DSP is the corresponding subdomain
+ address. A further substructure of the DSP may or may not be defined by
+ the authority identified by the IDP.
+
+ 8.1.1 The IDP
+
+ The Initial Domain Part of the NSAP address itself consists of two
+ parts. The first part is the Authority and Format Identifier (AFI).
+ The second part is the Initial Domain Identifier (IDI). This is
+ illustrated by Figure 8-2:
+
+
+
+ <----------------------NSAP ADDRESS------------------------->
+
+ ___________________________________________________________
+ | | |
+ | IDP | DSP |
+ |___________|_______________________________________________|
+ :
+ :_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
+ :
+ ___________________________________________________________:
+ | | |
+ | AFI | IDI |
+ |___________|_______________________________________________|
+
+ Figure 8-2 - NSAP Address Structure
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 17]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ 8.1.1.1 The AFI
+
+ The Authority and Format Identifier 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 Initial Domain Identifier 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 semantics of the DSP is determined by the authority identified by
+ the IDI (see clause 8.1.1.2).
+
+8.2 Network Address Abstract Syntax
+
+ The Network Address is defined in this Addendum in terms of an abstract
+ syntax which expresses the semantics of the Network Address. The use of
+ this abstract syntax as a descriptive device enables this Addendum to
+ convey, in written form, a complete definition of the Network Address
+ without restricting it to the specific encoding of the NPAI. It also
+ enables this Addendum to identify two alternative preferred concrete
+ synataxes of the Network Address, to which reference may be made by
+ Network Layer protocol specification standards so as to unambiguously
+ define the way in which the Network Address is encoded as NPAI.
+
+ 8.2.1 Abstract Syntax and Allocation of the IDP
+
+ This clause defines the abstract syntax of the AFI, the currently
+ allocated values of the AFI, and the IDI formats corresponding to the
+ allocated AFI values. Among the currently allocated values of the
+ AFIsare values reserved for assignment to new IDI formats which may be
+ identified by ISO or CCITT. Assignment of these AFI values to new IDI
+ formats by either ISO or CCITT must be accompanied by appropriate
+ modification of this Addendum according to the rules established by
+ ISO for revising International Standards. Allocation of new AFI values
+ will be by joint agreement between ISO and CCITT, and will require an
+ appropriate modification of this Addendum.
+
+
+
+ISO/TC-97/SC-6 [Page 18]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ The abstract syntax of the IDP is decimal digits. The allocation of
+ the AFI (see Clause 8.1.1) ensures that the first decimal digit of the
+ IDP can never be zero. This provides a escape mechanism for use by
+ protocols that expect to hold incomplete NSAP addresses in a field
+ that normally carries a complete NSAP address. 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 consists of an integer with a value between 0 and 99 with an
+ abstract syntax of 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 CCITT
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 19]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ 8.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:
+
+
+
+ Table 8-2: AFI Values
+
+ ___________________
+ | 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 consists of a sequence of up to 14 digits allocated
+ according to CCITT Recommendation X.121. The 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 consists of 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
+ values of the ISO DCC are a subset of the DCC values allocated by
+
+
+
+ISO/TC-97/SC-6 [Page 20]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ CCITT in Recommendation X.121 to countries or geographical areas.
+ The DSP is allocated and assigned by the organization that
+ represents the country identified by the DCC.
+
+ IDP length: 5 digits.
+
+ c) F.69
+
+ The IDI consists of a telex number of up to 8 digits, allocated
+ according to CCITT Recommendation F.69, commencing 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 consists of a public switched telephone network (PSTN)
+ number of up to 12 digits allocated according to CCITT
+ Recommendation E.163, commencing 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 consists of an ISDN number of up to 15 digits allocated
+ according to CCITT Recommendation E.164, commencing 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 consists of 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.
+
+
+
+ISO/TC-97/SC-6 [Page 21]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ Note 1:
+
+ In cases (a), (c), (d), and (e) above, when the IDP is followed by a
+ decimal-syntax DSP, no discernible boundary is identified in this
+ Addendum between the IDP digits and the DSP digits.
+
+ Note 2:
+
+ A figure illustrating the division of the global network addressing
+ domain according to these formats is contained in Annex B.
+
+ Note 3:
+
+ The use of a particular IDI format as the basis for allocating an
+ NSAP address does not constrain routing to that NSAP to go through
+ any particular subnetwork. For example, the use of the E.163 IDI
+ format as the basis for allocating an NSAP address does not mean
+ that access to the NSAP necessarily involves use of the telephony
+ subnetwork (see clause 7.3).
+
+ Note 4:
+
+ Formats a, c, d, and e are based on specific CCITT numbering plans,
+ and as such may be affected by any changes to those plans. It
+ should be understood that in identifying and describing these
+ formats, this Addendum observes the current status of CCITT work on
+ numbering plans, and does not establish any preference or position
+ whatsoever concerning the way in which 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 results in the possibility
+ of a choice that must be made concerning which of formats a, c, d,
+ and e should be used for the allocation of NSAP addresses, and may
+ also lead to suggestions that it is not necessary to include all of
+ the 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 those
+ authorities must allocate using the same abstract syntax used by the
+ parent authority.
+
+
+ISO/TC-97/SC-6 [Page 22]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ An authority may choose to allocate NSAP addresses with the DSP in a
+ decimal or binary abstract syntax for all IDI formats, and may 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
+
+ As describe in Clause 8.1, the semantics of the NSAP address consists
+ of three fields in the following 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 23]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+
+
+ Table 8-3: Maximum DSP Length
+
+ ___________________
+ | 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 the way in which the semantics of an
+ NSAP address are encoded in Network Layer protocols by a concrete
+ syntax in NPAI (see Note following this clause). These encodings are
+ specified in Network Layer protocol standards.
+
+ Note: Encoding implies more than a concrete syntax, such as the order
+ of bit transmission, representation as tones or other signals, etc.
+
+ Nevertheless, this Addendum identifies two alternative concrete
+ syntaxes (see clauses 8.3.1 and 8.3.2) of the Network Address.
+ Reference to these may be made by Network Layer protocol specification
+ standards. It is possible that the concrete syntax used to encode the
+ Network Address as NPAI in a Network Layer protocol may be chosen to be
+ identical to one of these concrete syntaxes. It is not required that
+ this be the case, however (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
+
+
+ISO/TC-97/SC-6 [Page 24]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ protocol specifications making reference to this Addendum shall specify
+ the way in which 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,
+ yielding a value for each semi-octet in the rage 0000-1001;
+
+ b) padding the IDI with leading zero digits if necessary to obtain
+ 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 leading padding digits, if preset),
+ yielding 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 obtain 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, giving 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 obtain
+ the maximum IDI length (specified for each IDI format in Clause
+ 8.2.1.2), representing the result directly as decimal digits;
+
+
+
+ISO/TC-97/SC-6 [Page 25]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ 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 o, 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:
+
+
+
+ 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 of the combinations of
+ IDI abstract syntax is given in Table 8-5 both the decimal concrete
+ syntax and the binary concrete syntax.
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 26]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+
+
+ 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 which is capable of conveying a string of
+ variable length 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.
+
+
+
+
+ISO/TC-97/SC-6 [Page 27]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+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: The ability to base DSP allocation on National Character sets
+ allows DSP allocation based on international character sets. This may
+ simplify address assignment in some cases, and may facilitate
+ representation of NSAP address in humanly-readable form. Nevertheless,
+ NSAP addresses should not be confused with Application Layer entity
+ titles. NSAP addresses are not intended to provide the same degree of
+ human-readable, user-friendly naming and addressing capabilities as
+ may be expected in Application Layer entity titles.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 28]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 29]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ANNEX A - NETWORK ENTITY TITLES
+
+This Annex is an integral part of the Addendum.
+
+In order to perform routing functions and to distribute Network Layer
+management information concerning routing among Network entities, it is
+necessary to be able to unambiguously identify Network entities in end
+systems and intermediate systems. The Reference Model (ISO 7498)
+provides a definition of the concept of an (N)-entity title, which may
+be used to permanently and unambiguously identify a Network entity in an
+end system or intermediate system.
+
+Any authority responsible for allocating addresses to NSAPs may choose
+also to allocate Network entity titles. One of the ways in which this
+can be done is to use the principles and mechanisms defined in this
+Addendum for allocating Network addresses. When this approach is taken,
+a Network entity title has the same abstract syntax as an NSAP address.
+A value may be allocated as a Network entity tile only if it has not
+been allocated as an NSAP address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 30]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ANNEX B - NSAP ADDRESS ALLOCATION
+
+This Annex is not an integral part of the Addendum.
+
+The division of the global Network addressing domain according to the
+IDI formats described in clause 8.2.1.2 may be illustrated by the
+following figure. The numbers adjacent 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.
+
+ 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 CCITT
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 31]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ANNEX C - RATIONALES
+
+This annex contains tutorial and explanatory material, and is not an
+integral part of the Addendum.
+
+C.1 IDI FORMATS (Clause 8.2.1.2)
+
+ The rationale for the use of the specific IDI formats identified in
+ Clause 8.2.1.2 is to allow the allocation and assignment of NSAP
+ addresses to be based on existing, well-established network numbering
+ plans and organization-identification standards.
+
+ The CCITT numbering plans are included so as to allow for the
+ designation of the organization to which a number is assigned as an
+ authority for the assignment of NSAP addresses. If the organization
+ identified by a particular number from one of these plans chooses not
+ to define any further sub-addressing beyond that number, then the
+ number itself constitutes an NSAP address when it is used in the OSI
+ environment. This flexibility allows number allocated from the four
+ CCITT numbering plans identified in Clause 8.2.1.2 to be used directly
+ as NSAP addresses, with the addition of nothing more than the initial
+ AFI digits that identify the plan.
+
+ The ISO DCC format is included so as to allow for the designation,
+ where permitted by national regulations, of the organization that
+ represents a country in ISO (or an appropriately sponsored
+ organization) as an authority for the assignment of
+ geographically-based NSAP addresses. The way in which addresses are
+ allocated and assigned in the ISO DCC format is determined by the
+ 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 as to allow for the designation,
+ where permitted by national regulations, of an organization that may or
+ may not be tied to a particular country as an authority for the
+ assignment of NSAP addresses according to the hierarchy appropriate for
+ that organization (which may not be based on geographical or national
+ boundaries). The way which addresses are allocated and assigned in the
+ ISO 6523-ICD format is determined by the designated organization, which
+ might, for example, be the United Nations World Health Organization.
+
+ The Local format is included so as to allow for proprietary or other
+ non-standard network addressing schemes to coexist with the standard
+ OSI network addressing scheme. Use of the Local format for these
+ non-standard address ensures that they cannot be confused with standard
+ OSI network addresses. This capability will be useful in the evolution
+ of existing networks to OSI, and for the accommodation of non-OSI
+ addressing schemes that may be used in proprietary network
+ architectures or for testing and other interim purposes. It should be
+ emphasized that
+
+
+
+ISO/TC-97/SC-6 [Page 32]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ the Local format is not intended to give non-OSI schemes a permanent
+ place in OSI, but rather to permit the OSI network addressing sheme to
+ be used wherever possible without risk of conflict with other schemes
+ (which can be encapsulated safely under the Local format).
+
+C.2 RESERVATION OF AFI VALUES 00-09 (Table 8-2)
+
+ The reservation of AFI values beginning with the digit 0 is intended to
+ allow for the use of an initial 0 to handle special cases, such as:
+
+ a) as an escape to some other addressing scheme;
+
+ b) as a technique for the optimization of 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 in fact contains something
+ less than a full address (for example, a shorthand form that omits
+ specification of the higher-order domains, which might be used for
+ communication within a particular subdomain environment).
+
+ There may be other cases in which the use of an initial 0 digit is
+ found to be useful. This Addendum merely reserves the AFI values 00-09,
+ and does not 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)
+
+ In 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 with an odd number of decimal digits.
+
+ The first type of padding is necessary because some of the IDI formats
+ allow the IDI to consist of a variable number of digits. Since there is
+ no explicit syntactic marker between the IDI and the DSP, the only way
+ to find the end of the IDI is to know how long it is. The AFI, which
+ identifies which IDI format is used, allows only the maximum length of
+ that IDI to be determined. Rather than introduce either a specific
+ syntactic marker or a new field containing the length of the IDI
+ (either of which would have greatly complicated the encoding and
+ parsing of NSAP addresses), the Addendum specifies that for encoding
+ purposes the IDI must first be padded out to its maximum length. Note
+ that this does not apply to the DSP; only to the IDI.
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 33]
+ RFC 941 April 1985
+Network Layer Addressing
+
+
+ The second type of padding is necessary to ensure that a binary
+ encoding of the IDI consists of an integral number of binary octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ISO/TC-97/SC-6 [Page 34]
+