Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0926

Protocol for providing the connectionless mode network services

Pages: 107
Obsoleted by:  0994
Part 1 of 3 – Pages 1 to 34
None   None   Next

ToP   noToC   RFC0926 - Page 1
Network Working Group                                                ISO
Request for Comments: 926                                  December 1984

 
 
    Protocol for Providing the Connectionless-Mode Network Services
 
                         (Informally - ISO IP)

                              ISO DIS 8473

Status of this Memo:

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

Note:

 This document has been prepared by retyping the text of ISO DIS 8473 of
 May 1984, which is currently undergoing voting within ISO as a Draft
 International Standard (DIS).  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
ToP   noToC   RFC0926 - Page 2
                           TABLE OF CONTENTS

 1   SCOPE AND FIELD OF APPLICATION........................ 2

 2   REFERENCES............................................ 3

 3   DEFINITIONS........................................... 4
 3.1   Reference Model Definitions......................... 4
 3.2   Service Conventions Definitions..................... 4
 3.3   Network Layer Architecture Definitions.............. 4
 3.4   Network Layer Addressing Definitions................ 5
 3.5   Additional Definitions.............................. 5

 4   SYMBOLS AND ABBREVIATIONS............................. 7
 4.1   Data Units.......................................... 7
 4.2   Protocol Data Units................................. 7
 4.3   Protocol Data Unit Fields........................... 7
 4.4   Parameters.......................................... 8
 4.5   Miscellaneous....................................... 8

 5   OVERVIEW OF THE PROTOCOL.............................. 9
 5.1   Internal Organization of the Network Layer.......... 9
 5.2   Subsets of the Protocol............................. 9
 5.3   Addressing......................................... 10
 5.4   Service Provided by the Network Layer.............. 10
 5.5   Service Assumed from the Subnetwork Service
    Provider.............................................. 11
 5.5.1   Subnetwork Addresses............................. 12
 5.5.2   Subnetwork Quality of Service.................... 12
 5.5.3   Subnetwork User Data............................. 13
 5.5.4   Subnetwork Dependent Convergence Functions....... 13
 5.6   Service Assumed from Local Evironment.............. 14

 6   PROTOCOL FUNCTIONS................................... 16
 6.1   PDU Composition Function........................... 16
 6.2   PDU Decomposition Function......................... 17
 6.3   Header Format Analysis Function.................... 17
 6.4   PDU Lifetime Control Function...................... 18
 6.5   Route PDU Function................................. 18
 6.6   Forward PDU Function............................... 19
 6.7   Segmentation Function.............................. 19
 6.8   Reassembly Function................................ 20
 6.9   Discard PDU Function............................... 21
ToP   noToC   RFC0926 - Page 3
 6.10   Error Reporting Function.......................... 22
 6.10.1   Overview........................................ 22
 6.10.2   Requirements.................................... 23
 6.10.3   Processing of Error Reports..................... 24
 6.11   PDU Header Error Detection........................ 25
 6.12   Padding Function.................................. 26
 6.13   Security.......................................... 26
 6.14   Source Routing Function........................... 27
 6.15   Record Route Function............................. 28
 6.16   Quality of Service Maintenance Function........... 29
 6.17   Classification of Functions....................... 29

 7   STRUCTURE AND ENCODING OF PDUS....................... 32
 7.1   Structure.......................................... 32
 7.2   Fixed Part......................................... 34
 7.2.1   General.......................................... 34
 7.2.2   Network Layer Protocol Identifier................ 34
 7.2.3   Length Indicator................................. 35
 7.2.4   Version/Protocol Identifier Extension............ 35
 7.2.5   PDU Lifetime..................................... 35
 7.2.6   Flags............................................ 36
 7.2.6.1   Segmentation Permitted and More Segments Flags. 36
 7.2.6.2   Error Report Flag.............................. 37
 7.2.7   Type Code........................................ 37
 7.2.8   PDU Segment Length............................... 37
 7.2.9   PDUChecksum...................................... 38
 7.3   Address Part....................................... 38
 7.3.1   General.......................................... 38
 7.3.1.1     Destination and Source Address Information... 39

 7.4   Segmentation Part.................................. 40
 7.4.1   Data Unit Identifier............................. 41
 7.4.2   Segment Offset................................... 41
 7.4.3   PDU Total Length................................. 41
 7.5   Options Part....................................... 41
 7.5.1   General.......................................... 41
 7.5.2   Padding.......................................... 43
 7.5.3   Security......................................... 43
 7.5.4   Source Routing................................... 44
 7.5.5   Recording of Route............................... 45
 7.5.6   Quality of Service Maintenance................... 46
 7.6   Priority........................................... 47
ToP   noToC   RFC0926 - Page 4
 7.7   Data Part.......................................... 47
 7.8   Data (DT) PDU...................................... 49
 7.8.1   Structure........................................ 49
 7.8.1.1   Fixed Part..................................... 50
 7.8.1.2   Addresses...................................... 50
 7.8.1.3   Segmentation................................... 50
 7.8.1.4   Options........................................ 50
 7.8.1.5   Data........................................... 50
 7.9   Inactive Network Layer Protocol.................... 51
 7.9.1   Network Layer Protocol Id........................ 51
 7.9.2   Data Field....................................... 51
 7.10   Error Report PDU (ER)............................. 52
 7.10.1   Structure....................................... 52
 7.10.1.1   Fixed Part.................................... 53
 7.10.1.2   Addresses..................................... 53
 7.10.1.3   Segmentation.................................. 53
 7.10.1.4   Options....................................... 54
 7.10.1.5   Reason for Discard............................ 54
 7.10.1.6   Error Report Data Field....................... 55

 8   FORMAL DESCRIPTION................................... 56
 8.1   Values of the State Variable....................... 57
 8.2   Atomic Events...................................... 57
 8.2.1   N.UNITDATA_request and N.UNITDATA_indication..... 57
 8.2.2   SN.UNITDATA_request and SN.UNITDATA_indication... 58
 8.2.3   TIMER Atomic Events.............................. 59
 8.3   Operation of the Finite State Automation........... 59
 8.3.1   Type and Constant Definitions.................... 61
 8.3.2   Interface Definitions............................ 65
 8.3.3   Formal Machine Definition........................ 67

 9   CONFORMANCE.......................................... 84
 9.1   Provision of Functions for Conformance............. 84
ToP   noToC   RFC0926 - Page 5
INTRODUCTION

 This Protocol is one of a set of International Standards produced to
 facilitate the interconnection of open systems. The set of standards
 covers the services and protocols required to achieve such
 interconnection.

 This Protocol Standard is positioned with respect to other related
 standards by the layers defined in the Reference Model for Open Systems
 Interconnection (ISO 7498). In particular, it is a protocol of the
 Network Layer. The Protocol herein described is a Subnetwork
 Independent Convergence Protocol combined with relay and routing
 functions as described in the Internal Organization of the Network
 Layer (ISO iiii). This Protocol provides the connectionless-mode
 Network Service as defined in ISO 8348/DAD1, Addendum to the Network
 Service Definition Covering Connectionless-mode Transmission, between
 Network Service users and/or Network Layer relay systems.

 The interrelationship of these standards is illustrated in Figure 0-1
 below:

      ______________OSI Network Service Definition______________  
                    |                             ^               
                                                  |               
                    |                             |               
         Protocol     Reference to aims __________|               
                    |                                             
                                                                  
      Specification | Reference to assumptions ___                
                                                  |               
                    |                             |               
                                                  |               
                    |                             |               
                                                  |               
                    |                             v               
      ______________Subnetwork Service Definition(s) ___________  

              Figure 0-1.  Interrelationship of Standards
ToP   noToC   RFC0926 - Page 6
1  SCOPE AND FIELD OF APPLICATION

 This International Standard specifies a protocol which is used to
 provide the Connectionless-mode Network Service as described in ISO
 8348/DAD1, Addendum to the Network Service Definition Covering
 Connectionless-mode Transmission. The protocol herein described relies
 upon the provision of a connectionless-mode subnetwork service.

 This Standard specifies:

  a)  procedures for the connectionless transmission of data and control
      information from one network-entity to a peer network-entity;

  b)  the encoding of the protocol data units used for the transmission
      of data and control information, comprising a variable-length
      protocol header format;

  c)  procedures for the correct interpretation of protocol control
      information; and

  d)  the functional requirements for implementations claiming
      conformance to the Standard.

 The procedures are defined in terms of:

  a)  the interactions among peer network-entities through the exchange
      of protocol data units;

  b)  the interactions between a network-entity and a Network Service
      user through the exchange of Network Service primitives; and

  c)  the interactions between a network-entity and a subnetwork service
      provider through the exchange of subnetwork service primitives.
ToP   noToC   RFC0926 - Page 7
2  REFERENCES

 ISO 7498       Information Processing Systems - Open Systems
                Interconnection - Basic Reference Model

 DP 8524        Information Processing Systems - Open Systems
                Interconnection - Addendum to ISO 7498 Covering
                Connectionless-Mode Transmission

 DIS 8348       Information Processing Systems - Data Communications -
                Network Service Definition

 ISO 8348/DAD1  Information Processing Systems - Data Communications -
                Addendum to the Network Service Definition Covering
                Connectionless-Mode Transmission

 ISO 8348/DAD2  Information Processing Systems - Data Communications -
                Addendum to the Network Service Definition Covering
                Network Layer Addressing

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

 DP 8509        Information Processing Systems - Open Systems
                Interconnection - Service Conventions

 ISO TC97/SC16  A Formal Description Technique based on an N1825
                Extended State Transition Model
ToP   noToC   RFC0926 - Page 8
SECTION ONE.  GENERAL

3  DEFINITIONS

 3.1  Reference Model Definitions

  This document makes use of the following concepts 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
   f) Service
   h) Network protocol
   i) Network relay
   j) Network protocol data unit
   k) End system

 3.2  Service Conventions Definitions

  This document makes use of the following concepts from the OSI Service
  Conventions (ISO 8509):

   l) Service user
   m) Service provider

 3.3  Network Layer Architecture Definitions

  This document makes use of the following concepts from the Internal
  Organization of the Network Layer (ISO iiii):

   n) Subnetwork
ToP   noToC   RFC0926 - Page 9
   o) Relay system
   p) Intermediate system
   q) Subnetwork service

 3.4  Network Layer Addressing Definitions

  This document makes use of the following concepts from DIS 8348/DAD2,
  Addendum to the Network Service Definition Covering Network layer
  addressing:

   r) Network entity title
   s) Network protocol address information
   t) Subnetwork address
   u) Domain

 3.5  Additional Definitions

  For the purposes of this document, the following definitions apply:

   a) automaton    -  a machine designed to follow automatically a
                      predetermined sequence of operations or to respond
                      to encoded instructions.

   b) local matter -  a decision made by a system concerning its
                      behavior in the Network Layer that is not subject
                      to the requirements of this Protocol.

   c) segment      -  part of the user data provided in the N_UNITDATA
                      request and delivered in the N_UNITDATA
                      indication.

   d) initial PDU  -  a protocol data unit carrying the whole of the
                      user data from an N_UNITDATA request.

   e) derived PDU  -  a  protocol data unit whose fields are identical
                      to those of an initial PDU, except that it carries
                      only a segment of the user data from an N_UNITDATA
                      request.
ToP   noToC   RFC0926 - Page 10
   f) segmentation -  the act of generating two or more derived PDUS
                      from an initial or derived PDU.  The derived PDUs
                      together carry the entire user data of the initial
                      or derived PDU from which they were generated.
                      [Note: it is possible that such an initial PDU
                      will never actually be generated for a particular
                      N_UNITDATA request, owing to the immediate
                      application of segmentation.]

   g) reassembly   -  the act of regenerating an initial PDU (in order
                      to issue an N_UNITDATA indication) from two or
                      more derived PDUs produced by segmentation.
ToP   noToC   RFC0926 - Page 11
4  SYMBOLS AND ABBREVIATIONS

 4.1  Data Units

  PDU          Protocol Data Unit
  NSDU         Network Service Data Unit
  SNSDU        Subnetwork Service Data Unit

 4.2  Protocol Data Units

  DT PDU       Data Protocol Data Unit
  ER PDU       Error Report Protocol Data Unit

 4.3  Protocol Data Unit Fields

  NPID         Network Layer Protocol Identifier
  LI           Length Indicator
  V/P          Version/protocol Identifier Extension
  LT           Lifetime
  SP           Segmentation Permitted Flag
  MS           More Segments Flag
  E/R          Error Report Flag
  TP           Type
  SL           Segment Length
  CS           Checksum
  DAL          Destination Address Length
  DA           Destination Address
  SAL          Source Address Length
  SA           Source Address
  DUID         Data Unit Identifier
  SO           Segment Offset
  TL           Total Length
ToP   noToC   RFC0926 - Page 12
 4.4  Parameters

  DA           Destination Address
  SA           Source Address
  QOS          Quality of Service

 4.5  Miscellaneous

  SNICP        Subnetwork Independent Convergence Protocol
  SNDCP        Subnetwork Dependent Convergence Protocol
  SNAcP        Subnetwork Access Protocol
  SN           Subnetwork
  P            Protocol
  NSAP         Network Service Access Point
  SNSAP        Subnetwork Service Access Point
  NPAI         Network Protocol Address Information
  NS           Network Service
ToP   noToC   RFC0926 - Page 13
5  OVERVIEW OF THE PROTOCOL

 5.1  Internal Organization of the Network Layer

  The architecture of the Network Layer is described in a separate
  document, Internal Organization of the Network Layer (ISO iiii), in
  which an OSI Network Layer structure is defined, and a structure to
  classify protocols as an aid to the progression toward that structure
  is presented. This protocol is designed to be used in the context of
  the internetworking protocol approach defined in that document,
  between Network Service users and/or Network Layer relay systems. As
  described in the Internal Organization of the Network Layer, the
  protocol herein described is a Subnetwork Independent Convergence
  Protocol combined with relay and routing functions designed to allow
  the incorporation of existing network standards within the OSI
  framework.

  A Subnetwork Independent Convergence Protocol is one which can be
  defined on a subnetwork independent basis and which is necessary to
  support the uniform appearance of the OSI Connectionless-mode Network
  Service between Network Service users and/or Network Layer relay
  systems over a set of interconnected homogeneous or heterogeneous
  subnetworks. This protocol is defined in just such a subnetwork
  independent way so as to minimize variability where subnetwork
  dependent and/or subnetwork access protocols do not provide the OSI
  Network Service.

  The subnetwork service required from the lower sublayers by the
  protocol described herein is identified in Section 5.5.

 5.2  Subsets of the Protocol

  Two proper subsets of the full protocol are also defined which permit
  the use of known subnetwork characteristics, and are therefore not
  subnetwork independent.

  One protocol subset is for use where it is known that the source and
  destination end-systems are connected by a single subnetwork. This is
  known as the "Inactive Network Layer Protocol" subset. A second subset
  permits simplification of the header where it is known that the source
  and destination end-systems are connected by subnetworks whose
  subnetwork service data unit (SNSDU) sizes are greater than or equal
  to a known bound large enough for segmentation not to be required.
  This subset, selected by setting the "segmentation permitted" flag to
  zero, is known as the "non-segmenting" protocol subset.
ToP   noToC   RFC0926 - Page 14
 5.3  Addressing

  The Source Address and Destination Address parameters referred to in
  Section 7.3 of this International Standard are OSI Network Service
  Access Point Addresses. The syntax and semantics of an OSI Network
  Service Access Point Address, the syntax and encoding of the Network
  Protocol Address Information employed by this Protocol, and the
  relationship between the NSAP and the NPAI is described in a separate
  document, ISO 8348/DAD2, Addendum to the Network Service Definition
  covering Network Layer Addressing.

  The syntax and semantics of the titles and addresses used for relaying
  and routing are also described in ISO 8348/DAD2.

 5.4  Service Provided by the Network Layer

  The service provided by the protocol herein described is a
  connectionless-mode Network Service. The connectionless-mode Network
  Service is described in document ISO 8348/DAD1, Addendum to the
  Network Service Definition Covering Connectionless-mode Transmission.
  The Network Service primitives provided are summarized below:
ToP   noToC   RFC0926 - Page 15
                 Primitives                Parameters          
      +--------------------------------------------------------+ 
      |                           |                            | 
      | N_UNITDATA Request        | NS_Destination_Address,    | 
      |            Indication     | NS_Source_Address,         | 
      |                           | NS_Quality_of_Service,     | 
      |                           | NS_Userdata                | 
      +--------------------------------------------------------+ 

                 Table 5-1.  Network Service Primitives

  The Addendum to the Network Service Definition Covering
  Connectionless-mode Transmission (ISO 8348/DAD1) states that the
  maximum size of a connectionless-mode Network-service-data-unit is
  limited to 64512 octets.

 5.5  Service Assumed from the Subnetwork Service provider

  The subnetwork service required to support this protocol is defined as
  comprising the following primitives:

                Primitives                  Parameters           
      +--------------------------------------------------------+ 
      |                           |                            | 
      | SN_UNITDATA Request       | SN_Destination_Address,    | 
      |             Indication    | SN_Source_Address,         | 
      |                           | SN_Quality_of_Service,     | 
      |                           | SN_Userdata                | 
      +--------------------------------------------------------+ 

               Table 5-2.  Subnetwork Service Primitives
ToP   noToC   RFC0926 - Page 16
  5.5.1  Subnetwork Addresses

   The source and destination addresses specify the points of attachment
   to a public or private subnetwork(s) involved in the transmission.
   Subnetwork addresses are defined in the Service Definition of each
   individual subnetwork.

   The syntax and semantics of subnetwork addresses are not defined in
   this Protocol Standard.

  5.5.2  Subnetwork Quality of Service

   Subnetwork Quality of Service describes aspects of a subnetwork
   connectionless-mode service which are attributable solely to the
   subnetwork service provider.

   Associated with each subnetwork connectionless-mode transmission,
   certain measures of quality of service are requested when the
   primitive action is initiated. These requested measures (or parameter
   values and options) are based on a priori knowledge by the Network
   Service provider of the service(s) made available to it by the
   subnetwork. Knowledge of the nature and type of service available is
   typically obtained prior to an invocation of the subnetwork
   connectionless-mode service.

    Note:

     The quality of service parameters identified for the subnetwork
     connectionless-mode service may in some circumstances be directly
     derivable from or mappable onto those identified in the
     connectionless-mode Network Service; e.g., the parameters

      a)  transit delay;
      b)  protection against unauthorized access;
      c)  cost determinants;
      d)  priority; and
      e)  residual error probability

     as defined in ISO 8348/DAD1, Addendum to the Network Service
     Definition Covering Connectionless-mode Transmission, may be
     employed.
ToP   noToC   RFC0926 - Page 17
     For those subnetworks which do not inherently provide Quality of
     Service as a parameter when the primitive action is initiated, it
     is a local matter as to how the semantics of the service requested
     might be preserved. In particular, there may be instances in which
     the Quality of Service requested cannot be maintained. In such
     circumstances, the subnetwork service provider shall attempt to
     deliver the protocol data unit at whatever Quality of Service is
     available.

  5.5.3  Subnetwork User Data

   The SN_Userdata is an ordered multiple of octets, and is transferred
   transparently between the specified subnetwork service access points.

   The subnetwork service is required to support a subnetwork service
   data unit size of at least the maximum size of the Data PDU header
   plus one octet of NS-Userdata. This requires a minimum subnetwork
   service data unit size of 256 octets.

   Where the subnetwork service can support a subnetwork service data
   unit (SNSDU) size greater than the size of the Data PDU header plus
   one octet of NS_Userdata, the protocol may take advantage of this. In
   particular, if all SNSDU sizes of the subnetworks involved are known
   to be large enough that segmentation is not required, then the
   "non-segmenting" protocol subset may be used.

  5.5.4  Subnetwork Dependent Convergence Functions

   Subnetwork Dependent Convergence Functions may be performed to
   provide a connectionless-mode subnetwork service in the case where
   subnetworks also provide a connection-oriented subnetwork service. If
   a subnetwork provides a connection-oriented service, some subnetwork
   dependent function is assumed to provide a mapping into the required
   subnetwork service described in the preceding text.

   A Subnetwork Dependent Convergence Protocol may also be employed in
   those cases where functions assumed from the subnetwork service
   provider are not performed.
ToP   noToC   RFC0926 - Page 18
 5.6  Service Assumed from Local Evironment

  A timer service is provided to allow the protocol entity to schedule
  events.

  There are three primitives associated with the S_TIMER service:

   1)  the S-TIMER request;

   2)  the S_TIMER response; and

   3)  the S_TIMER cancel.

  The S_TIMER request primitive indicates to the local environment that
  it should initiate a timer of the specified name and subscript and
  maintain it for the duration specified by the time parameter.

  The S_TIMER response primitive is initiated by the local environment
  to indicate that the delay requested by the corresponding S_TIMER
  request primitive has elapsed.

  The S_TIMER cancel primitive is an indication to the local environment
  that the specified timer(s) should be cancelled. If the subscript
  parameter is not specified, then all timers with the specified name
  are cancelled; otherwise, the timer of the given name and subscript is
  cancelled. If no timers correspond to the parameters specified, the
  local environment takes no action.

  The parameters of the S_TIMER service primitives are:
ToP   noToC   RFC0926 - Page 19
            Primitives                  Parameters             
      +--------------------------------------------------------+ 
      |                           |                            | 
      | S_TIMER Request           | S_Time                     | 
      |                           | S_Name                     | 
      |                           | S_Subscript                | 
      |                           |                            | 
      | S_TIMER Response          | S_Name                     | 
      |         Cancel            | S_Subscript                | 
      +--------------------------------------------------------+ 

                      Table 5-3.  Timer Primitives

  The time parameter indicates the time duration of the specified timer.
  An identifying label is associated with a timer by means of the name
  parameter. The subscript parameter specifies a value to distinguish
  timers with the same name. The name and subscript taken together
  constitute a unique reference to the timer.
ToP   noToC   RFC0926 - Page 20
SECTION TWO.  SPECIFICATION OF THE PROTOCOL

6  PROTOCOL FUNCTIONS

 This section describes the functions performed as part of the Protocol.

 Not all of the functions must be performed by every implementation.
 Section 6.17 specifies which functions may be omitted and the correct
 behavior where requested functions are not implemented.

 6.1  PDU Composition Function

  This function is responsible for the construction of a protocol data
  unit according to the rules of protocol given in Section 7. Protocol
  Control Information required for delivering the data unit to its
  destination is determined from current state information and from the
  parameters provided with the N_UNITDATA Request; e.g., source and
  destination addresses, QOS, etc. User data passed from the Network
  Service user in the N_UNITDATA Request forms the Data field of the
  protocol data unit.

  During the composition of the protocol data unit, a Data Unit
  Identifier is assigned to identify uniquely all segments of the
  corresponding NS_Userdata. The "Reassemble PDU" function considers
  PDUs to correspond to the same Initial PDU, and hence N_UNITDATA
  request, if they have the same Source and Destination Addresses and
  Data Unit Identifier.

  The Data Unit Identifier is available for ancillary functions such as
  error reporting. The originator of the PDU must choose the Data Unit
  Identifier so that it remains unique (for this Source and Destination
  Address pair) for the maximum lifetime of the PDU (or any Derived
  PDUs) in the network.
ToP   noToC   RFC0926 - Page 21
  During the composition of the PDU, a value of the total length of the
  PDU is determined by the originator and placed in the Total Length
  field of the PDU header. This field is not changed in any Derived PDU
  for the lifetime of the protocol data unit.

  Where the non-segmenting subset is employed, neither the Total Length
  field nor the Data Unit Identifier field is present. During the
  composition of the protocol data unit, a value of the total length of
  the PDU is determined by the originator and placed in the Segment
  Length field of the PDU header. This field is not changed for the
  lifetime of the PDU.

 6.2  PDU Decomposition Function

  This function is responsible for removing the Protocol Control
  Information from the protocol data unit. During this process,
  information pertinent to the generation of the N_UNITDATA Indication
  is retained. The data field of the PDU received is reserved until all
  segments of the original service data unit have been received; this is
  the NS_Userdata parameter of the N_UNITDATA Indication.

 6.3  Header Format Analysis Function

  This function determines whether the full Protocol described in this
  Standard is employed, or one of the defined proper subsets thereof. If
  the protocol data unit has a Network Layer Protocol Identifier
  indicating that this is a standard version of the Protocol, this
  function determines whether a PDU received has reached its destination
  using the destination address provided in the PDU is the same as the
  one which addresses an NSAP served by this network-entity, then the
  PDU has reached its destination; if not, it must be forwarded.

  If the protocol data unit has a Network Layer Protocol Identifier
  indicating that the Inactive Network Layer Protocol subset is in use,
  then no further analysis of the PDU header is required. The
ToP   noToC   RFC0926 - Page 22
  network-entity in this case determines that either the network address
  encoded in the network protocol address information of a supporting
  subnetwork protocol corresponds to a network Service Access Point
  address served by this network-entity, or that an error has occurred.
  If the subnetwork PDU has been delivered correctly, then the protocol
  data unit may be decomposed according to the procedure described for
  that particular subnetwork protocol.

 6.4  PDU Lifetime Control Function

  This function is used to enforce the maximum PDU lifetime. It is
  closely associated with the "Header Format Analysis" function. This
  function determines whether a PDU received may be forwarded or whether
  its assigned lifetime has expired, in which case it must be discarded.

  The operation of the Lifetime Control function depends upon the
  Lifetime field in the PDU header. This field contains, at any time,
  the remaining lifetime of the PDU (represented in units of 500
  Milliseconds). The Lifetime of the Initial PDU is determined by the
  originating network-entity, and placed in the Lifetime field of the
  PDU.

 6.5  Route PDU Function

  This function determines the network-entity to which a protocol data
  unit should be forwarded, using the destination NSAP address
  parameters, Quality of Service parameter, and/or other parameters. It
  determines the subnetwork which must be transited to reach that
  network-entity. Where segmentation occurs, it further determines which
  subnetwork(s) the segments may transit to reach that network-entity.
ToP   noToC   RFC0926 - Page 23
 6.6  Forward PDU Function

  This function issues a subnetwork service primitive (see Section 5.5)
  supplying the subnetwork identified by the "Route PDU" function with
  the protocol data unit as an SNSDU, and the address information
  required by that subnetwork to identify the "next" intermediate-system
  within the subnetwork-specific address domain.

  When an Error Report PDU is to be forwarded, and is longer than the
  maximum user data acceptable by the subnetwork, it shall be truncated
  to the maximum acceptable length ad forwarded with no other change.
  When a Data PDU is to be forwarded ad is longer than the maximum user
  data acceptable by the subnetwork, the Segmentation function is
  applied (See Section 6.7, which follows).

 6.7  Segmentation Function

  Segmentation is performed when the size of the protocol data unit is
  greater than the maximum size of the user data parameter field of the
  subnetwork service primitive.

  Segmentation consists of composing two or more new PDUs (Derived PDUs)
  from the PDU received. The PDU received may be the Initial PDU, or it
  may be a Derived PDU. The Protocol Control Information required to
  identify, route, and forward a PDU is duplicated in each PDU derived
  from the Initial PDU. The user data encapsulated within the PDU
  received is divided such that the Derived PDUs satisfy the size
  requirements of the user data parameter field of the subnetwork
  service primitive.

  Derived PDUs are identified as being from the same Initial PDU by
  means of

   a)  the source address,

   b)  the destination address, and

   c)  the data unit identifier.
ToP   noToC   RFC0926 - Page 24
  The following fields of the PDU header are used in conjunction with
  the Segmentation function:

   a)  Segment Offset - identifies at which octet in the data field of
       the Initial PDU the segment begins;

   b)  Segment Length - specifies the number of octets in the Derived
       PDU, including both header and data;

   c)  More Segments Flag - set to one if this Derived PDU does not
       contain, as its final octet of user data, the final octet of the
       Initial PDU; and

   d)  Total Length - specifies the entire length of the Initial PDU,
       including both header and data.

  Derived PDUs may be further segmented without constraining the routing
  of the individual Derived PDUs.

  A Segmentation Permitted flag is set to one to indicate that
  segmentation is permitted. If the Initial PDU is not to be segmented
  at any point during its lifetime in the network, the flag is set to
  zero.

  When the "Segmentation Permitted" flag is set to zero, the non-
  segmenting protocol subset is in use.

 6.8  Reassembly Function

  The Reassembly Function reconstructs the Initial PDU transmitted to
  the destination network-entity from the Derived PDUs generated during
  the lifetime of the Initial PDU.

  A bound on the time during which segments (Derived PDUs) of an Initial
  PDU will be held at a reassembly point is provided so that resources
  may be released when it is no longer expected that any outstanding
  segments of the Initial PDU will arrive at the reassembly point. When
  such an event occurs, segments (Derived PDUs) of the Initial PDU held
  at the reassembly point are discarded, the resources allocated for
  those segments are freed,
ToP   noToC   RFC0926 - Page 25
  and if selected, an Error Report is generated.

   Note:

    The design of the Segmentation and Reassembly functions is intended
    principally to be used such that reassembly takes place at the
    destination. However, other schemes which

     a)  interact with the routing algorithm to favor paths on which
         fewer segments are generated,

     b)  generate more segments than absolutely required in order to
         avoid additional segmentation at some subsequent point, or

     c)  allow partial/full reassembly at some point along the route
         where it is known that the subnetwork with the smallest PDU
         size has been transited

    are not precluded. The information necessary to enable the use of
    one of these alternative strategies may be made available through
    the operation of a Network Layer Management function.

    While the exact relationship between reassembly lifetime and PDU
    lifetime is a local matter, the reassembly algorithm must preserve
    the intent of the PDU lifetime. Consequently, the reassembly
    function must discard PDUs whose lifetime would otherwise have
    expired had they not been under the control of the reassembly
    function.

 6.9  Discard PDU Function

  This function performs all of the actions necessary to free the
  resources reserved by the network-entity in any of the following
  situations (Note: the list is not exhaustive):

   a)  A violation of protocol procedure has occurred.

   b)  A PDU is received whose checksum is inconsistent with its
       contents.
ToP   noToC   RFC0926 - Page 26
   c)  A PDU is received, but due to congestion, it cannot be processed.

   d)  A PDU is received whose header cannot be analyzed.

   e)  A PDU is received which cannot be segmented and cannot be
       forwarded because its length exceeds the maximum subnetwork
       service data unit size.

   f)  A PDU is received whose destination address is unreachable or
       unknown.

   g)  Incorrect or invalid source routing was specified. This may
       include a syntax error in the source routing field, and unknown
       or unreachable address in the source routing field, or a path
       which is not acceptable for other reasons.

   h)  A PDU is received whose PDU lifetime has expired or the lifetime
       expires during reassembly.

   i)  A PDU is received which contains an unsupported option.

 6.10  Error Reporting Function

  6.10.1  Overview

   This function causes the return of an Error Report PDU to the source
   network-entity when a protocol data unit is discarded. An "error
   report flag" in the original PDU is set by the source network-entity
   to indicate whether or not Error Report PDUs are to be returned.

   The Error Report PDU identifies the discarded PDU, specifies the type
   of error detected, and identifies the location at which the error was
   detected. Part or all of the discarded PDU is included in the data
   field of the Error Report PDU.

   The address of the originator of the Data Protocol Data Unit is
ToP   noToC   RFC0926 - Page 27
   conveyed as both the destination address of the Error Report PDU as
   well as the source address of the original Data PDU; the latter is
   contained in the Data field of the Error Report PDU. The address of
   the originator of the Error Report PDU is contained in the source
   address field of the header of the Error Report PDU.

    Note:

     Non-receipt of an Error Report PDU does not imply correct delivery
     of a PDU issued by a source network-entity.

  6.10.2  Requirements

   An Error Report PDU shall not be generated to report the discarding
   of a PDU that itself contains an Error Report.

   An Error Report PDU shall not be generated upon discarding of a PDU
   unless that PDU has the Error Report flag set to allow Error Reports.

   If a Data PDU is discarded, and has the Error Report flag set to
   allow Error Reports, an Error Report PDU shall be generated if the
   reason for discard (See Section 6.9)  is

    a)  destination address unreachable,

    b)  source routing failure,

    c)  unsupported options, or

    d)  protocol violation.
ToP   noToC   RFC0926 - Page 28
    Note:

     It is intended that this list shall include all nontransient
     reasons for discard; the list may therefore need to be amended or
     extended in the light of any changes made in the definitions of
     such reasons.

   If a Data PDU with the Error Report flag set to allow Error Reports
   is discarded for any other reason, an Error Report PDU may be
   generated (as an implementation option).

  6.10.3  Processing of Error Reports

   Error Report PDUs are forwarded by intermediate network-entities in
   the same way as Data PDUs. It is possible that an Error Report PDU
   may be longer than the maximum user data size of a subnetwork that
   must be traversed to reach the origin of the discarded PDU. In this
   case, the Forward PDU function shall truncate the PDU to the maximum
   size acceptable.

   The entire header of the discarded data unit shall be included in the
   data field of the Error Report PDU. Some or all of the data field of
   the discarded data unit may also be included.

    Note:

     Since the suppression of Error Report PDUs is controlled by the
     originating network-entity and not by the NS User, care should be
     exercised by the originator with regard to suppressing ER PDUs so
     that error reporting is not suppressed for every PDU generated.
ToP   noToC   RFC0926 - Page 29
 6.11  PDU Header Error Detection

  The PDU Header Error Detection function protects against failure of
  intermediate or end-system network-entities due to the processing of
  erroneous information in the PDU header. The function is realized by a
  checksum computed on the PDU header. The checksum is verified at each
  point at which the PDU header is processed. If PDU header fields are
  modified (for example, due to lifetime function), then the checksum is
  modified so that the checksum remains valid.

  An intermediate system network-entity must not recompute the checksum
  for the entire header, even if fields are modified.

   Note:

    This is to ensure that inadvertent modification of a header while a
    PDU is being processed by an intermediate system (for example, due
    to a memory fault) may still be detected by the PDU Header Error
    function.

  The use of this function is optional, and is selected by the
  originating network-entity. If the function is not used, the checksum
  field of the PDU header is set to zero.

  If the function is selected by the originating network-entity, the
  value of the checksum field causes the following formulae to be
  satisfied:

     L
   (SUM)     a   = 0  (modulo 255)
              i
     i=1

     L
   (SUM)     (L-i+1) a   = 0 (modulo 255)
                       i
     i=1

    Where L = the number of octets in the PDU header, and
          a = value of octet at position i.
           i
ToP   noToC   RFC0926 - Page 30
  When the function is in use, neither octet of the checksum field may
  be set to zero.

  Annex C contains descriptions of algorithms which may be used to
  calculate the correct value of the checksum field when the PDU is
  created, and to update the checksum field when the header is modified.

 6.12  Padding Function

  The padding function is provided to allow space to be reserved in the
  PDU header which is not used to support any other function. Octet
  alignment must be maintained.

   Note:

    An example of the use of this function is to cause the data field of
    a PDU to begin on a convenient boundary for the originating
    network-entity, such as a computer word boundary.

 6.13  Security

  An issue related to the quality of the network service is the
  protection of information flowing between transport-entities. A system
  may wish to control the distribution of secure data by assigning
  levels of security to PDUs. As a local consideration, the Network
  Service user could be authenticated to ascertain whether the user has
  permission to engage in communication at a particular security level
  before sending the PDU. While no protocol exchange is required in the
  authentication process, the optional security parameter in the options
  part of the PDU header may be employed to convey the particular
  security level between peer network-entities.

  The syntax and semantics of the security parameter are not specified
  by this Standard. The security parameter is related to the "protection
  from unauthorized access" Quality of service parameter described in
  ISO 8348/DAD1, Addendum to the Network Service Definition Covering
  Connectionless-mode Transmission. However, to facilitate
  interoperation between end-systems and relay-systems by avoiding
  different interpretations of the same encoding, a mechanism is
  provided to distinguish user-defined security encoding from
  standardized security encoding.
ToP   noToC   RFC0926 - Page 31
 6.14  Source Routing Function

  The Source Routing function allows the originator to specify the path
  a generated PDU must take. Source routing can only be selected by the
  originator of a PDU. Source Routing is accomplished using a list of
  intermediate system addresses (or titles, see Section 5.3 and 5.5.1)
  held in a parameter within the options part of the PDU Header. The
  size of the option field is determined by the originating
  network-entity. The length of this option does not change as the PDU
  traverses the network. Associated with this list is an indicator which
  identifies the next entry in the list to be used; this indicator is
  advanced by the receiver of the PDU when the next address matches its
  own address. The indicator is updated as the PDU is forwarded so as to
  identify the appropriate entry at each stage of relaying.

  Two forms of the source routing option are provided. The first form,
  referred to as complete source routing, requires that the specified
  path must be taken; if the specified path cannot be taken, the PDU
  must be discarded. The source may be informed of the discard using the
  Error Reporting function described in Section 6.10.

  The second form is referred to as partial source routing. Again, each
  address in the list must be visited in the order specified while on
  route to the destination. However, with this form of source routing
  the PDU may take any path necessary to arrive at the next address in
  the list. The PDU will not be discarded (for source routing related
  causes) unless one of the addresses specified cannot be reached by any
  available route.
ToP   noToC   RFC0926 - Page 32
 6.15  Record Route Function

  The Record Route function permits the exact recording of the paths
  taken by a PDU as it traverses a series of interconnected subnetworks.
  A recorded route is composed of a list of intermediate system
  addresses held in a parameter within the options part of the PDU
  header. The size of the option field is determined by the originating
  network-entity. The length of this option does not change as the PDU
  traverses the network.

  The list is constructed as the PDU traverses a set of interconnected
  subnetworks. Only intermediate system addresses are included in the
  recorded route. The address of the originator of the PDU is not
  recorded in the list. When an intermediate system network-entity
  processes a PDU containing the record route parameter, the system
  inserts its own address (or titles, see Sections 5.3 or 5.5.1) into
  the list of recorded addresses.

  The record route option contains an indicator which identifies the
  next available octet to be used for recording of route. This
  identifier is updated as entries are added to the list. If the
  addition of the current address to the list would exceed the size of
  the option field, the indicator is set to show that recording of route
  has terminated. The PDU may still be forwarded to its final
  destination, without further addition of intermediate system
  addresses.

   Note:

    The Record Route function is principally intended to be used in the
    diagnosis of network problems. Its mechanism has been designed on
    this basis, and may provide a return path.
ToP   noToC   RFC0926 - Page 33
 6.16  Quality of Service Maintenance Function

  In order to support the Quality of Service requested by Network
  Service users, the Protocol may need to make QOS information available
  at intermediate systems. This information may be used by network
  entities in intermediate systems to make routing decisions where such
  decisions affect the overall QOS provided to NS users.

  In those instances where the QOS indicated cannot be maintained, the
  NS provider will attempt to deliver the PDU at a QOS less than that
  indicated. The NS provider will not necessarily provide a notification
  of failure to meet the indicated quality of service.

 6.17  Classification of Functions

  Implementations do not have to support all of the functions described
  in Section 6. Functions are divided into three categories:

   Type 1:  These functions must be supported.

   Type 2:  These functions may or may not be supported. If an
            implementation does not support a Type 2 function, and the
            function is selected by a PDU, then the PDU shall be
            discarded, and an Error Report PDU shall be generated and
            forwarded to the originating network-entity, providing that
            the Error Report flag is set.

   Type 3:  These functions may or may not be supported. If an
            implementation does not support a Type 3 function, and the
            function is selected by a PDU, then the function is not
            performed and the PDU is processed exactly as though the
            function was not selected. The protocol data unit shall not
            be discarded.

  Table 6-1 shows how the functions are divided into these three
  categories:
ToP   noToC   RFC0926 - Page 34
         +---------------------------------------------------+
         | Function                       |  Type            |
         |--------------------------------|------------------|
         |                                |                  |
         | PDU Composition                |  1               |
         | PDU Decomposition              |  1               |
         | Header Format Analysis         |  1               |
         | PDU Lifetime Control           |  1               |
         | Route PDU                      |  1               |
         | Forward PDU                    |  1               |
         | Segment PDU                    |  1               |
         | Reassemble PDU                 |  1               |
         | Discard PDU                    |  1               |
         | Error Reporting                |  1 (note 1)      |
         | PDU Header Error Detection     |  1 (note 1)      |
         | Padding                        |  1 (notes 1   2) |
         | Security                       |  2               |
         | Complete Source Routing        |  2               |
         | Partial Source Routing         |  3               |
         | Priority                       |  3               |
         | Record Route                   |  3               |
         | Quality of Service Maintenance |  3               |
         +---------------------------------------------------+

            Table 6-1.  Categorization of Protocol Functions


(next page on part 2)

Next Section