path: root/doc/rfc/rfc941.txt

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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^LRFC 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]
^L