As per Relevance of the word allocate, we have this rfc below:

---

Network Working Group
Request for Comments: 941 April 1985

Addendum to the Network Service Definition
Network Layer


ISO/DP8348/DAD
(also TC 97/SC 6/N 3444)

Status of this RFC

This document is distributed as an RFC for information only. It
not specify a standard for the ARPA-Internet. Distribution of
document is unlimited

Note

This document has been prepared by retyping the text of ISO/DP8348/DAD
of October 1984 (also numbered SC 6/N 3444), which is
undergoing voting within ISO as a Draft Proposed Addendum to
Network Service Definition. Although this RFC has been reviewed
typing, and is believed to be substantially correct, it is
that typographic errors not present in the ISO document have
overlooked

Alex
BBN





























ISO/TC-97/SC-6 [Page 1]
RFC 941 April 1985
Network Layer


ISO Statement on the Status of this Document

At its meeting in Zurich, April 2-11, 1984, SC 6/WG 2 produced
SC 6 N 3134 and, in accordance with Resolution 49 of the SC 6 meeting
Tianjin (September 19-30, 1983), forwarded it to the SC 6
for registration and ballot as a first Draft Proposed Addendum to
Network Service Definition (ISO DP 8348/DAD2).

The letter ballot on SC 6/N 3134 closed on August 20, 1984. The
of the ballot were 10-4-0-3 [approve-disapprove-abstain-no vote];
summary of voting is contained in document SC 6/N 3229 (late votes
contained in documents SC 6/N 3333 and 3360). These ballot results
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.
Editor's report, contained in document SC 6/N 3445, describes
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
second Draft Proposed Addendum to ISO 8348, and to circulate it for
two-month letter ballot



This Addendum to the Network Service Definition Standard, ISO 8348,
defines the abstract syntax and semantics of the Network
(Network Service Access Point Address). The Network Address defined
this Addendum is the address that appears in the primitives of
connection-mode Network Service as the calling address, called address
and responding address parameters, and in the primitives of
connectionless-mode Network Service as the source address
destination address parameters




















ISO/TC-97/SC-6 [Page 2]
RFC 941 April 1985
Network Layer


SCOPE AND FIELD OF

The scope of this Addendum is the definition of the abstract syntax
semantics of the Network Address. This Addendum does not specify
way in which the semantics of the NSAP address are encoded in
Layer protocols. The field of application of this Addendum is the
as the field of application described in Clause 1 of the Network
Definition (ISO 8348).

2

ISO 7498 Information Processing Systems - Open
Interconnection - Basic Reference Model [Note: See
CCITT Recommendation X.200]

DP 7498/DAD1 Information Processing Systems - Open
Interconnection - Addendum to the Basic Reference
Covering Connectionless Data

DP 8509 Information Processing Systems - Open
Interconnection - Service

ISO 8348 Information Processing Systems - Data Communications -
Network Service Definition [Note: See also
Recommendation X.213]

DIS 8348/DAD1 Information Processing Systems - Data Communications -
Addendum to the Network Service Definition
Connectionless Data

DP 8648 Information Processing Systems - Data Communications -
Internal Organization of the Network

ISO 6523 Data Interchange - Structure for the Identification


ISO 646 7-bit Coded Character Set for Information


ISO 2375 Procedure for the Registration of Escape

CCITT X.121 International Numbering Plan for Public Data

CCITT E.163 Numbering Plan for the International Telephone

CCITT E.164 The Numbering Plan for the ISDN

CCITT F.69 Plan for Telex Destination





ISO/TC-97/SC-6 [Page 3]
RFC 941 April 1985
Network Layer


Temporary

The list of References in the published Addendum will
only approved ISO Standards and CCITT Recommendations; items may
to be subtracted from, or added to, the current list
















































ISO/TC-97/SC-6 [Page 4]
RFC 941 April 1985
Network Layer


SECTION ONE -
---------------------

3

3.1 Reference Model

This Addendum makes use of the following terms defined in ISO 7498:

a) Network

b) Network

c) Network service access

d) Network service access point

e) Network

f)

g) Network

h) Network protocol control

i) Network protocol data

3.2 Service Conventions

This Addendum makes use of the following terms defined in ISO 8509:

j) Service

k) Service

3.3 Network Layer Architecture

This Addendum makes use of the following terms defined in ISO 8648
(Internal Organization of the Network Layer):

l)

m) Real

n) Subnetwork

o) Real end

p) Interworking

q) Intermediate


ISO/TC-97/SC-6 [Page 5]
RFC 941 April 1985
Network Layer


3.4 Network Addressing

This Addendum makes use of the following terms as defined below

r) DTE address: information used to identify a point of attachment
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
subnetwork, and a conceptual point at which a subnetwork service
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
identify a subnetwork point of attachment, or information used
the context of a particular subnetwork to identify the point
which the subnetwork service is offered within an end
intermediate system

u) Network protocol address information: information encoded in
network protocol data unit to carry the semantics of an
address. (This is known as an "address signal" or as the "coding
an address signal" in the Public Data Network environment.)

v) Domain (of the OSI environment): a subset of the OSI
within which identifiers for OSI environment entities of the
type are unambiguous

w) Global network addressing domain: the set of all Network
Access Point addresses in the OSI environment

x) Network addressing subdomain; a subset of the global
addressing domain

y) Authority (for a domain or subdomain): that which ensures
identifiers within the corresponding domain or subdomain
unambiguous
















ISO/TC-97/SC-6 [Page 6]
RFC 941 April 1985
Network Layer


4

This Addendum makes use of the following abbreviations

a) NSAP - Network Service Access

b) NPAI - Network Protocol Addressing

c) DCC - Data Country

d) CC - Country

e) ICD - International Code

f) PSTN - Public Switched Telephone

g) ISDN - Integrated Services Digital

h) IDP - Initial Domain

i) AFI - Authority and Format

j) IDI - Initial Domain

k) DSP - Domain Specific

l) NPDU - Network Protocol Data

m) SNPA - Subnetwork Point of

5

No particular standard conventions are invoked by this Addendum




















ISO/TC-97/SC-6 [Page 7]
RFC 941 April 1985
Network Layer


SECTION TWO - NETWORK LAYER
--------------------------------------

6 CONCEPTS AND TERMINOLOGY FOR NETWORK LAYER

6.1 Network

This Addendum defines the Network Service Access Point (NSAP
address. Since the term "network address" is commonly used in
contexts to refer to different things a more specific description
this concept is introduced below

6.1.1 Subnetwork

In one context, the term "network address" may be used to refer to
point at which a real end system, real subnetwork, or
unit is attached to a real subnetwork, or to the point at which
subnetwork service is offered within an end or intermediate system
In the case of attachment to a public data network, this point
called a DTE/DCE interface, and the term "DTE address" is used
reference to it

The specific term "subnetwork address" (or "subnetwork point
attachment address") is used in this case, as illustrated in
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









ISO/TC-97/SC-6 [Page 8]
RFC 941 April 1985
Network Layer


The subnetwork address is the information that a real subnetwork
to identify a particular real end system, another real subnetwork,
interworking unit that is attached to that real subnetwork

In the public network environment, the subnetwork address is what
public network operates on

Note: The point identified by a subnetwork address is a point
interconnection between a real end system or interworking unit and
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

In another context, the term "network address" is used to refer to
Network Service Access Point (NSAP) at which the OSI Network
is made available to a Network Service user by the Network
provider

The specific term "NSAP address" is used in this case, as
in Figure 6-2:


Network Service User

layer 4
______________________________ 0 _____________________________
\
layer 3 \____NSAP identified
by NSAP address

Network Service Provider

Figure 6-2 - NSAP

The NSAP address is the information that the OSI Network
provider needs to identify a particular Network Service Access Point
The values of the called address, calling address, and
address parameters in the N-CONNECT primitive, of the
address parameter in the N_DISCONNECT primitive, and of the
address and destination address parameters in the N-UNIDATA primitive
are NSAP addresses

Note that since the Network Service primitives are conceptual,
particular encoding of the NSAP address is specified by the
Service Definition

In both CCITT and ISO usage, the terms "Network Address" (with
the N and the A printed in capital letters) and "global
address" are synonymous with the term "NSAP address". Use of the



ISO/TC-97/SC-6 [Page 9]
RFC 941 April 1985
Network Layer


"NSAP address" is preferred when it is essential to avoid confusion
particularly in spoken references where "capitalization" is
possible

6.1.3 Network Protocol Address

In a third context, the term "network address" is used to refer to
address that is carried as network protocol control information in
network protocol data unit (NPDU).

The specific term "network protocol address information" (NPAI)
used in this case

In the public network environment, NPAI is also known as an "
signal" or as the "coding of an address signal".

There is a relationship between the NSAP address that appears
Network Service primitives and the NPAI that appears in a
Layer protocol, in that the semantics of the NSAP address is
by the NPAI. The syntax and encoding of NPAI are defined by
layer Protocol standards, which also specify the relationship
the NSAP address and the NPAI encoding employed by the protocol

6.2

A domain is a subset of the Open Systems Interconnection
within which identifiers for OSI environment entities of the same
are unambiguous

6.2.1 Global Network Addressing

The global network addressing domain is defined as the set of
Network Service Access Point addresses in the OSI environment

6.2.2 Network Addressing

A network addressing subdomain is a set of Network Service
Point addresses. It is a subset of the global network
domain

The relationship of the concepts of 6.2.1 and 6.2.2 is illustrated
Figure 6-3:











ISO/TC-97/SC-6 [Page 10]
RFC 941 April 1985
Network Layer



**************
***** *****
*** ***
*** ***
** ** ** ** <-- Global
** * * .** network
** ** ** . ** addressing
* * * . * domain
* * * . . *
* * * .. . *
* * * .. + *
* * * .. <-----------\
** * * .. + ** |
* + * * ..+ * |
* + * <------------------------------\|
* + * * ... + * |
* + * * ... + * |
* + * * .... + * |
* + * * + * |
* + ************************************ * |
* ********* + + ********* * |
** + + ** |
* + + * |
** + + ** |
* + + <-------------\|
* + + * |
* + + * |
* + + * |
* + + * |
** + + ** |
** + <--\ + ** |
** + \ + ** |
*** + \ + *** |
*** \ *** |
***** \**** |
***************\ Network
\------------- addressing
subdomains

Figure 6-3 - Domains and












ISO/TC-97/SC-6 [Page 11]
RFC 941 April 1985
Network Layer


6.3

The uniqueness of identifiers within a domain or subdomain is
by an authority associated with that domain. The term "authority"
not necessarily refer to an organization or administration: it
intended to refer to whatever it is (in an abstract sense) that
the uniqueness of identifiers in the associated domain

Domains are characterized by the authority that administers the
and by the rules that are established by that authority for
identifiers and identifying subdomains. The authority responsible
each subdomain determines how identifiers will be assigned
interpreted within that subdomain, and how any further subdomains
be created

The operation of an authority is independent of that of
authorities on the same level of the hierarchy, subject only to
common rules imposed by the parent authority

6.4 Network Address

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
domain identifier which identifies the allocating authority. An
shall not be allocated to identify a domain or NSAP if the address
previously been allocated to some other domain or NSAP, unless
authority can ensure that all use of the previous allocation
ceased

The authority shall ensure that allocations are made in such a way
efficient use is made of the address space

7 PRINCIPLES FOR CREATING THE OSI NETWORK ADDRESSING

7.1 Hierarchical Structure of NSAP

NSAP addresses are based on the concept of hierarchical
domains, as explained in Clause 6. Each domain may be
partitioned into subdomains. Accordingly, NSAP addresses have
hierarchical structure

The conceptual structure of NSAP addresses follows the principle that
at any level of the hierarchy, an initial part of the
unambiguously identifies a subdomain, and the rest is allocated by
management of the subdomain to unambiguously identify either a
level subdomain or an NSAP within the subdomain. The part of
address that identifies the subdomain depends on the level at which
address is viewed




ISO/TC-97/SC-6 [Page 12]
RFC 941 April 1985
Network Layer


Note: This conceptual structure should not be considered as
any detailed administration of NSAP addresses

Graphical representation of the hierarchical structure of
addresses may be made according to an inverted tree diagram, as
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
Inverted Tree
















ISO/TC-97/SC-6 [Page 13]
RFC 941 April 1985
Network Layer



**************
***** *****
*** ***
*** Z ***
** **
* *
*** ** ** ***
** ** * * ** **
** * ** ** * .**
** ** * * ** r . **
* * * * * . *
X * * * * * . ------------>* Y
* * * * * /. . s +*
* * * * * / .. + *
* * * * * / .. + *
** * * * * b .. + **
* + * * * * | ..+ *
* + * * * * | q + *
* + * ** * ..| + *
* + * * |... + a *
* + * * | p .... + *
* + * * V + *
* + ************************************ *
* ********* ********* *
** **
************************************
********* + + *********
** + + **
* + + *
** + + **
* + + c *
* a + + *
* + + *
* + b + *
* + + *
** + + **
** + + **
** + + **
*** + + ***
*** ***
***** *****
**************
W

Figure 7-1 (b) - Hierarchical Structure of NSAP
Domain






ISO/TC-97/SC-6 [Page 14]
RFC 941 April 1985
Network Layer


7.2 Global Identification of any

In the context of Open Systems Interconnection, it is possible
identify any NSAP within the global network addressing domain (
Clause 6.2.1). Consequently

a) At any Network Service Access Point, it is possible to
any other Network Service Access Point, within any OSI end system

b) A global Network Address can therefore be defined to
identify any Network Service Access Point

c) The OSI protocols established between correspondent
entities convey the complete information contained in a
Address (see Clause 6.1.4);

d) An NSAP address identifies the same NSAP regardless of
NS-user enunciated the address;

e) An NS-user, when given an NSAP address of the NS-provider in
primitive Indication, may subsequently use that NSAP address
another instance of communication with the corresponding NSAP

Some restrictions may be placed on communications in the context
OSI, on the basis of: technical feasibility of an interconnection
security, charging, etc. Such considerations are not related to
Layer addressing, and therefore are not discussed in this Addendum

Note: The global identification of NSAPs should not be taken to
the universal availability of directory functions required to
communication among all NSAPs to which NSAP addresses have
allocated

7.3 Route

Network Service users cannot derive routing information from an
address. They cannot influence the Network Service provider's choice
route by means of the source and destination NSAP addresses. Similarly
they cannot deduce from the source and destination NSAP addresses
route that was used by the Network Service provider. This is
intended to exclude the possibility that an OSI end system may need
influence the route selected for a particular instance of
with another OSI end system. (In particular, it may need to
the selection of intermediate systems to be used, and the paths to
taken between them.) The means whereby such an influence may be
is, however, not the NSAP address. Elements of Network Layer
may be required to control routing within intermediate systems;
elements of protocol are distinct from the network protocol
information (NPAI).

Notwithstanding the restrictions imposed on the use that a


ISO/TC-97/SC-6 [Page 15]
RFC 941 April 1985
Network Layer


Service user may make of an NSAP address, it is recognized that
addresses should be constructed in such a way that routing
interconnected subnetworks is facilitated. That is, the Network
provider and relay-entities in particular, may take advantage of
address structure to achieve economical processing of routing aspects

7.4 Service Type

It may be necessary for Network Service users to distinguish
Layer services of different types (such as point-to-point
multipoint services, and connection-mode versus connectionless-
services). The nature of such service types is not explicitly
in the semantics of the NSAP address. Similarly, Network Layer
of service characteristics (such as throughput, transit delay, etc.)
are not explicitly specified by the NSAP address

8 NETWORK ADDRESS

The intent of this document is best served by maintaining
distinctions among three concepts: the abstract semantics of the
address; the abstract syntax employed in this document as a means
defining the abstract semantics of the NSAP address, and employed
addressing authorities as a means of allocating and assigning addresses
and the concrete syntax in which the NSAP address semantics are
as NPAI in Network Layer protocols. These distinctions are
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

This Addendum does not specify the way in which the semantics of
NSAP address are encoded in Network Layer protocols. Network
protocol specifications define the way in which the NSAP address
encoded as NPAI (see clause 6.1.4).








ISO/TC-97/SC-6 [Page 16]
RFC 941 April 1985
Network Layer


8.1 Network Address

The NSAP address consists of two basic semantic parts. The first
is the Initial Domain Part (IDP). The second part is the
Specific Part (DSP). This is illustrated by Figure 8-2.

Following the conceptual structure of NSAP addresses described
Clause 7.1, the IDP is a subdomain identifier: it specifies
subdomain of the global network addressing domain (see Figure 7-1),
identifies the authorities responsible for assigning addresses in
of the subdomains created. The DSP is the corresponding
address. A further substructure of the DSP may or may not be defined
the authority identified by the IDP

8.1.1 The

The Initial Domain Part of the NSAP address itself consists of
parts. The first part is the Authority and Format Identifier (AFI).
The second part is the Initial Domain Identifier (IDI). This
illustrated by Figure 8-2:



<----------------------NSAP ADDRESS------------------------->

___________________________________________________________
| | |
| IDP | DSP |
|___________|_______________________________________________|
:
:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
:
___________________________________________________________:
| | |
| AFI | IDI |
|___________|_______________________________________________|

Figure 8-2 - NSAP Address















ISO/TC-97/SC-6 [Page 17]
RFC 941 April 1985
Network Layer


8.1.1.1 The

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 (
clause 8.2.1.2)

c) the abstract syntax of the DSP (see clauses 8.2 and 8.2.3).

8.1.1.2 The

The Initial Domain Identifier specifies

a) the Network Addressing subdomain from which values of the
are allocated;

b) the authority responsible for allocating values of the DSP
that subdomain

8.1.2 The

The semantics of the DSP is determined by the authority identified
the IDI (see clause 8.1.1.2).

8.2 Network Address Abstract

The Network Address is defined in this Addendum in terms of an
syntax which expresses the semantics of the Network Address. The use
this abstract syntax as a descriptive device enables this Addendum
convey, in written form, a complete definition of the Network
without restricting it to the specific encoding of the NPAI. It
enables this Addendum to identify two alternative preferred
synataxes of the Network Address, to which reference may be made
Network Layer protocol specification standards so as to
define the way in which the Network Address is encoded as NPAI

8.2.1 Abstract Syntax and Allocation of the

This clause defines the abstract syntax of the AFI, the
allocated values of the AFI, and the IDI formats corresponding to
allocated AFI values. Among the currently allocated values of
AFIsare values reserved for assignment to new IDI formats which may
identified by ISO or CCITT. Assignment of these AFI values to new
formats by either ISO or CCITT must be accompanied by
modification of this Addendum according to the rules established
ISO for revising International Standards. Allocation of new AFI
will be by joint agreement between ISO and CCITT, and will require
appropriate modification of this Addendum



ISO/TC-97/SC-6 [Page 18]
RFC 941 April 1985
Network Layer


The abstract syntax of the IDP is decimal digits. The allocation
the AFI (see Clause 8.1.1) ensures that the first decimal digit of
IDP can never be zero. This provides a escape mechanism for use
protocols that expect to hold incomplete NSAP addresses in a
that normally carries a complete NSAP address. When the NSAP
is represented as binary octets, the representation of the IDP is
defined in Clause 8.3.1.

The length of the IDP depends on the IDI format specified by the
of the AFI. The IDP length associated with each IDI format is given
clause 8.2.1.2.

8.2.1.1 Abstract Syntax and Allocation of the

The AFI consists of an integer with a value between 0 and 99 with
abstract syntax of two decimal digits. The values of the AFI
allocated or reserved as shown in Table 8-1:



Table 8-1: AFI

00-09 Reserved - will not be

10-35 Reserved for future allocation by joint
of ISO and

36-51 Allocated and assigned to the IDI formats
in clause 8.2.1.2

52-59 Reserved for future allocation by joint
of ISO and

60-69 Allocated for assignment to new IDI formats


70-79 Allocated for assignment to new IDI formats


80-99 Reserved for future allocation by joint
of ISO and












ISO/TC-97/SC-6 [Page 19]
RFC 941 April 1985
Network Layer


8.2.1.2 Format and Allocation of the

A specific combination of IDI format and DSP abstract syntax
associated with each allocated AFI value, as summarized in Table 8-2:



Table 8-2: AFI

___________________
| 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
according to CCITT Recommendation X.121. The X.121
identifies an authority responsible for allocating and
values of the DSP

IDP length: Up to 16 digits

b) ISO

The IDI consists of a three-digit Data Country Code (DCC). ISO
values are allocated by ISO and assigned to ISO member countries
appropriately sponsored non-member countries or authorities.
values of the ISO DCC are a subset of the DCC values allocated



ISO/TC-97/SC-6 [Page 20]
RFC 941 April 1985
Network Layer


CCITT in Recommendation X.121 to countries or geographical areas
The DSP is allocated and assigned by the organization
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,
according to CCITT Recommendation F.69, commencing with a 2-
3-digit destination code. The telex number identifies an
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
Recommendation E.163, commencing with the PSTN country code.
PSTN number identifies an authority responsible for allocating
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
according to CCITT Recommendation E.164, commencing with the
country code. The ISDN number identifies an authority
for allocating and assigning values of the DSP

IDP length: Up to 17

f) ISO 6523-

The IDI consists of a 4-digit International Code Designator (ICD
allocated according to ISO 6523. The ICD identifies
organizational authority responsible for allocating and
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)

The IDI is null

IDP length: 2 digits



ISO/TC-97/SC-6 [Page 21]
RFC 941 April 1985
Network Layer


Note 1:

In cases (a), (c), (d), and (e) above, when the IDP is followed by
decimal-syntax DSP, no discernible boundary is identified in
Addendum between the IDP digits and the DSP digits

Note 2:

A figure illustrating the division of the global network
domain according to these formats is contained in Annex B

Note 3:

The use of a particular IDI format as the basis for allocating
NSAP address does not constrain routing to that NSAP to go
any particular subnetwork. For example, the use of the E.163
format as the basis for allocating an NSAP address does not
that access to the NSAP necessarily involves use of the
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.
should be understood that in identifying and describing
formats, this Addendum observes the current status of CCITT work
numbering plans, and does not establish any preference or
whatsoever concerning the way in which CCITT may choose to
the plans, or their relationships with one another, in the future
Changes to this may be necessary to take any such further work
CCITT into account. For example, the CCITT numbering plans in
cases may provide escape mechanisms (such as a zero, 8, or 9 prefix
from one numbering plan to another. This results in the
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
also lead to suggestions that it is not necessary to include all
the formats a, c, d, and e in this Addendum. Such choices, however
are made within the context and responsibility of CCITT, and
preference for one choice or another is made or implied by
Addendum

8.2.2 Abstract Syntax and Allocation of the

Values of the DSP are allocated by the authority identified by the
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
DSP. If the authority identified by the IDI authorizes one or
authorities to allocate semantic parts of the DSP, then all
authorities must allocate using the same abstract syntax used by
parent authority


ISO/TC-97/SC-6 [Page 22]
RFC 941 April 1985
Network Layer


An authority may choose to allocate NSAP addresses with the DSP in
decimal or binary abstract syntax for all IDI formats, and may
to allocate NSAP addresses with the DSP in a character (ISO 646)
National Character abstract syntax when the IDI format is "Local" (
Table 8-2). Clause 9 describes the latter case in detail

8.2.3 Abstract Syntax of the

The DSP may be allocated by the responsible authority in one of
syntaxes, depending on the value of the AFI

a) Binary: The DSP consists of zero or more binary octets, up
the maximum specified in Table 8-3.

b) Decimal: The DSP consists of zero or more decimal digits,
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
character, from ISO 646, up to the maximum
in Table 8-3.

d) National Character: The DSP consists of zero or more
from a character set determined by the
authority, up to the maximum specified in Table 8-3.

Table 8-3 gives the maximum length of the DSP in its abstract
for each of the IDI formats defined in clause 8.2.1.2.
corresponding total NSAP address lengths are given in clause 8.4.

8.3 Network Address Concrete

As describe in Clause 8.1, the semantics of the NSAP address
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
digits;














ISO/TC-97/SC-6 [Page 23]
RFC 941 April 1985
Network Layer




Table 8-3: Maximum DSP

___________________
| 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
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
NSAP address are encoded in Network Layer protocols by a
syntax in NPAI (see Note following this clause). These encodings
specified in Network Layer protocol standards

Note: Encoding implies more than a concrete syntax, such as the
of bit transmission, representation as tones or other signals, etc

Nevertheless, this Addendum identifies two alternative
syntaxes (see clauses 8.3.1 and 8.3.2) of the Network Address
Reference to these may be made by Network Layer protocol
standards. It is possible that the concrete syntax used to encode
Network Address as NPAI in a Network Layer protocol may be chosen to
identical to one of these concrete syntaxes. It is not required
this be the case, however (see clause 9).

The entire NSAP address taken as a whole may be represented
as a string of either decimal digits (decimal concrete syntax)
binary octets (binary concrete syntax) as defined below. Network


ISO/TC-97/SC-6 [Page 24]
RFC 941 April 1985
Network Layer


protocol specifications making reference to this Addendum shall
the way in which either the decimal concrete syntax or the
concrete syntax of the NSAP address (or both) is encoded as NPAI (
clause 6.1.3).

8.3.1 Binary Concrete

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
the maximum IDI length (specified for each IDI format in
8.2.1.2), then using a semi-octet to represent the value of
decimal digit (including leading padding digits, if preset),
yielding a value in the range 0000-1001; and, if the DSP
is not decimal digits, using the semi-octet value 1111 as a
after the final semi-octet (if necessary) to obtain an
number of octets

c) representing a decimal syntax DSP using the technique described
(b);

d) representing a binary syntax DSP directly as binary octets

e) when the IDI format is "Local", representing an ISO 646
syntax DSP by converting each character to a number in the
32-127 using the ISO 646 encoding, with zero parity and
parity bit in the most significant position, reducing the
by 32, giving a number in the range 0-95, encoding this result
a pair of decimal digits; and applying the technique described
(b);

f) when the IDI format is "Local", representing a National
syntax DSP by converting each national character to either one
two octets according to the rules specified by the
responsible for allocating NSAP addresses including
character DSP syntaxes

8.3.2 Decimal Concrete

The decimal concrete syntax is generated by

a) representing the two digits of the AFI directly as two
digits

b) padding the IDI with leading zero digits if necessary to
the maximum IDI length (specified for each IDI format in
8.2.1.2), representing the result directly as decimal digits



ISO/TC-97/SC-6 [Page 25]
RFC 941 April 1985
Network Layer


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
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,
2. The pair of octets is represented by the sequence of five
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,
final octet is converted to a number in the range 0-255
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
8.3.1 (e);

f) when the IDI format is "Local", representing a
Character syntax DSP using the technique described in
8.3.1 (f).

8.4 Maximum Network Address

The maximum length of the NSAP address for each of the combinations
IDI abstract syntax is given in Table 8-5 both the decimal
syntax and the binary concrete syntax









ISO/TC-97/SC-6 [Page 26]
RFC 941 April 1985
Network Layer




Table 8-5: Maximum NSAP Address

________________________________________________________________
| | 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
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
is 20 octets;

b) the maximum length of an NSAP address in its decimal
syntax is 40 digits

A Network Layer protocol which is capable of conveying a string
variable length with a maximum length of either 20 binary octets or 40
decimal digits is capable of encoding the full semantic content of
Network Address




ISO/TC-97/SC-6 [Page 27]
RFC 941 April 1985
Network Layer


9 CHARACTER BASED DSP

An authority may choose to allocate NSAP addresses with the DSP in
National Character syntax. In such cases, the allocating authority
define and publish the mapping of the National Character syntax
either a binary abstract syntax or a decimal abstract syntax

Note: It is recommended that this mapping be done by reference to
ISO Register of Character Sets, which is maintained by the
Computer Manufacturers Association (ECMA) acting as a
authority according to ISO 2375, "Procedure for the Registration
Escape Sequences".

In the case where the authority defines and publishes the mapping of
National Character set to a binary abstract syntax, the result must
representable in either one or two octets per National Character.
this case, the resulting DSP is considered to be based on the
abstract syntax. AFI values from Table 8-2 and the mapping to binary
decimal concrete syntaxes are based on the binary abstract syntax

In the case where the authority defines and publishes the mapping of
National Character set to a decimal abstract syntax, the result must
representable in up to five decimal digits per National Character.
this case, the resulting DSP is considered to be based on the
abstract syntax. AFI values from Table 8-2 and the mapping to binary
decimal concrete syntaxes are based on the decimal abstract syntax

Note: The ability to base DSP allocation on National Character
allows DSP allocation based on international character sets. This
simplify address assignment in some cases, and may
representation of NSAP address in humanly-readable form. Nevertheless
NSAP addresses should not be confused with Application Layer
titles. NSAP addresses are not intended to provide the same degree
human-readable, user-friendly naming and addressing capabilities
may be expected in Application Layer entity titles


















ISO/TC-97/SC-6 [Page 28]
RFC 941 April 1985
Network Layer


10 REFERENCE PUBLICATION

Reference publication formats are defined to allow
representation of NSAP addresses in both written and oral communication

10.1 Decimal Reference Publication

The Decimal reference publication form (DRPF) consists of a string
up to 40 decimal digits. The DRPF is the written inscription of
decimal concrete syntax defined in clause 8.3.2.

10.2 Hexadecimal Reference Publication

The Hexadecimal reference publication format (HRPF) consists of
symbol "/" (solidus) followed by a string of up to 40
digits. The HRPF is the written inscription of the binary
syntax defined in clause 8.3.1, using two hexadecimal digits
from 00 through FF to represent each binary octet



































ISO/TC-97/SC-6 [Page 29]
RFC 941 April 1985
Network Layer


ANNEX A - NETWORK ENTITY

This Annex is an integral part of the Addendum

In order to perform routing functions and to distribute Network
management information concerning routing among Network entities, it
necessary to be able to unambiguously identify Network entities in
systems and intermediate systems. The Reference Model (ISO 7498)
provides a definition of the concept of an (N)-entity title, which
be used to permanently and unambiguously identify a Network entity in
end system or intermediate system

Any authority responsible for allocating addresses to NSAPs may
also to allocate Network entity titles. One of the ways in which
can be done is to use the principles and mechanisms defined in
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
been allocated as an NSAP address


































ISO/TC-97/SC-6 [Page 30]
RFC 941 April 1985
Network Layer


ANNEX B - NSAP ADDRESS

This Annex is not an integral part of the Addendum

The division of the global Network addressing domain according to
IDI formats described in clause 8.2.1.2 may be illustrated by
following figure. The numbers adjacent to each line in the figure
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

10-35 Reserved for future allocation by joint agreement of
and

36-37 X.121

38-39 ISO

40-41 F.69

42-43 E.163

44-45 E.164

46-47 ISO

48-51

52-59 Reserved for future allocation by joint agreement of
and

60-69 Allocated for assignment by

70-79 Allocated for assignment by

80-99 Reserved for future allocation by joint agreement of
and














ISO/TC-97/SC-6 [Page 31]
RFC 941 April 1985
Network Layer


ANNEX C -

This annex contains tutorial and explanatory material, and is not
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
Clause 8.2.1.2 is to allow the allocation and assignment of
addresses to be based on existing, well-established network
plans and organization-identification standards

The CCITT numbering plans are included so as to allow for
designation of the organization to which a number is assigned as
authority for the assignment of NSAP addresses. If the
identified by a particular number from one of these plans chooses
to define any further sub-addressing beyond that number, then
number itself constitutes an NSAP address when it is used in the
environment. This flexibility allows number allocated from the
CCITT numbering plans identified in Clause 8.2.1.2 to be used
as NSAP addresses, with the addition of nothing more than the
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
represents a country in ISO (or an appropriately
organization) as an authority for the assignment
geographically-based NSAP addresses. The way in which addresses
allocated and assigned in the ISO DCC format is determined by
designated organization, which might, for example, be the
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
may not be tied to a particular country as an authority for
assignment of NSAP addresses according to the hierarchy appropriate
that organization (which may not be based on geographical or
boundaries). The way which addresses are allocated and assigned in
ISO 6523-ICD format is determined by the designated organization,
might, for example, be the United Nations World Health Organization

The Local format is included so as to allow for proprietary or
non-standard network addressing schemes to coexist with the
OSI network addressing scheme. Use of the Local format for
non-standard address ensures that they cannot be confused with
OSI network addresses. This capability will be useful in the
of existing networks to OSI, and for the accommodation of non-
addressing schemes that may be used in proprietary
architectures or for testing and other interim purposes. It should
emphasized



ISO/TC-97/SC-6 [Page 32]
RFC 941 April 1985
Network Layer


the Local format is not intended to give non-OSI schemes a
place in OSI, but rather to permit the OSI network addressing sheme
be used wherever possible without risk of conflict with other
(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
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
Network Layer protocols, when the different parts of the
address semantics are encoded in different fields of the
header

c) as a way to indicate, in a protocol header, that a field
ordinarily contains a full NSAP address in fact contains
less than a full address (for example, a shorthand form that
specification of the higher-order domains, which might be used
communication within a particular subdomain environment).

There may be other cases in which the use of an initial 0 digit
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
the scope of this Addendum

C.3 DERIVATION OF THE CONCRETE SYNTAXES (Clause 8.3)

In describing the two "preferred" concrete syntaxes of the
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
semi-octet with the value 1111 at the end of the binary encoding of
IDI with an odd number of decimal digits

The first type of padding is necessary because some of the IDI
allow the IDI to consist of a variable number of digits. Since there
no explicit syntactic marker between the IDI and the DSP, the only
to find the end of the IDI is to know how long it is. The AFI,
identifies which IDI format is used, allows only the maximum length
that IDI to be determined. Rather than introduce either a
syntactic marker or a new field containing the length of the
(either of which would have greatly complicated the encoding
parsing of NSAP addresses), the Addendum specifies that for
purposes the IDI must first be padded out to its maximum length.
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


The second type of padding is necessary to ensure that a
encoding of the IDI consists of an integral number of binary octets



















































ISO/TC-97/SC-6 [Page 34]

---

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX

---