Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 0926

Protocol for providing the connectionless mode network services

Pages: 107
Obsoleted by:  0994
Part 3 of 3 – Pages 70 to 107
First   Prev   None

ToP   noToC   RFC0926 - Page 70   prevText
        TIMER_cancel

             (Name      : timer_name_type;
              Subscript : integer);

    by Provider:
        TIMER_indication
           (Name      : timer_name_type;
            Subscript : integer);
ToP   noToC   RFC0926 - Page 71
  8.3.3  Formal Machine Definition

   module Connectionless_Network_Protocol_Machine
        (N:  Network_access_point (Provider) common queue;
         SN: array [subnet_id_type] of Subnetwork_access_point
                                          (User) common queue;
         S:  System_access_point (User) individual queue );

   var
       nsdu    : nsdu_type;
       pdu     : pdu_type;
       rcv_buf : buffer_type;

   state : (INITIAL, REASSEMBLING, CLOSED);
ToP   noToC   RFC0926 - Page 72
   procedure send_error_report (error : error_type;
                                pdu   : pdu_type);

    var
        er_pdu : pdu_type;

    begin
     if (pdu.er_flag) then
      begin
       er_pdu.nlp_id   := ISO_8473_protocol_id;
       er_pdu.vp_id    := version1;
       er_pdu.lifetime := get_er_lifetime(pdu.sa);
       er_pdu.sp       := get_er_seg_per(pdu);
       er_pdu.ms       := FALSE;
       er_pdu.er_flag  := FALSE;
       er_pdu.pdu_tp   := ER;
       er_pdu.da_len   := pdu.sa_len;
       er_pdu.da       := pdu.sa;
       er_pdu.sa_len   := get_local_NPAI_addr_len;
       er_pdu.sa       := get_local_NPAI_addr;
       er_pdu.options  := get_er_options
                          (error,
                          er_pdu.da,
                          pdu.options);
       er_pdu.hli      := get_header_length
                          (er_pdu.da_len, er_pdu.sa_len,
                           er_pdu.sp,
                           er_pdu.options);
       er_pdu.data     := get_er_data_field(error, pdu);
       if (er_pdu.sp) then
                        begin
                           er_pdu.du_id   :=
                           get_data_unit_id(er_pdu.da);
                           er_pdu.so      := ZERO;
                           er_pdu.tot_len := er_pdu.hli +
                           size(er_pdu.data);
                        end;
ToP   noToC   RFC0926 - Page 73
       if (NPAI_addr_local(er_pdu.da))
                        then
                           post_error_report(er_pdu)
                        else
                           send_pdu(er_pdu);
      end;
    end;
ToP   noToC   RFC0926 - Page 74
   procedure send_pdu (pdu : pdu_type);

    var

     rte_result   : route_result_type;
     error_code   : error_type;
     send_buf     : buffer_type;
     data_maxsize : integer;
     more_seg     : boolean;
     sn_qos       : SN_QOS_type;

    begin

     send_buf := make_buffer(pdu.data);
     more_seg := pdu.ms;

     repeat

      begin

       error_code := check_parameters
                     (pdu.hli,
                      pdu.sp,
                      pdu.da,
                      pdu.options,
                      size(pdu.data));

       if (error_code = NO_ERROR) then

                        begin

                           rte_result := route(pdu.hli,
                                               pdu.sp,
                                               pdu.da,
                                               pdu.options,
                                               size(pdu.data));

                           data_maxsize := rte_result.segment_size -
                           pdu.hli;
                           pdu.data     := extract(send_buf,
                           data_maxsize);
                           pdu.seg_len  := pdu.hli + size(pdu.data);

                           if (size(send_buf) = ZERO) then
                               pdu.ms   := more_seg
                           else
                               pdu.ms   := TRUE;
ToP   noToC   RFC0926 - Page 75
                           pdu.checksum := get_checksum(pdu);
                           sn_qos       := get_sn_qos
                           (rte_result.subnet_id,
                                                       pdu.options);

                           out SN[rte_result.subnet_id].UNITDATA_request
                                      (rte_result.sn_da,
                                       rte_result.sn_sa,
                                       sn_qos,
                                       pdu);

                           pdu.so := pdu.so + data_maxsize;

                        end

       else if (error_code = CONGESTION) then

                        begin

                           if (send_er_on_congestion (pdu)) then
                               send_error_report(CONGESTION, pdu);

                        end

       else

                        send_error_report(error_code, pdu);

      end;

     until (size_buf(data_buf) = ZERO) or
           (error_code <> NO_ERROR);

    end;
ToP   noToC   RFC0926 - Page 76
   procedure allocate_reassembly_resources
            (pdu_tot_len : integer);
   primitive;

    { This procedure allocates resources required for reassembly of a
    PDU of the specified total length.  If this requires discarding of a
    PDU in which the ER flag is set, then an error report is returned to
    the source of the discarded data unit. }

   function check_parameters
        (hli     : integer;
         sp      : boolean;
         da      : NPAI_addr_type;
         options : options_type;
         datalen : integer) : error_type;
   primitive;

    { This function examines various parameters associated with a PDU,
    to determine whether forwarding of the PDU can continue.  If a
    result of NO_ERROR is returned, then the primitive route can be
    called to specify the route and segment size.  Otherwise this
    function specifies the reason that an error has occurred. }

   function data_unit_complete
        (buf : buffer_type) : boolean;
   primitive;

    { This function returns a boolean value specifying whether the PDU
    stored in the specified buffer has been completely received. }
ToP   noToC   RFC0926 - Page 77
   function elapsed_time : integer;
   primitive;

    { This function returns an estimate of the time elapsed, in 500
    microsecond increments, since the PDU was transmitted by the
    previous peer network entity.  This estimate includes both time
    spent in transit, and any time to be spent in buffers within the
    local system.  Although this estimate need not be precise,
    overestimates are preferable to underestimates, as underestimating
    the time elapsed may defeat the intent of the lifetime function. }

   procedure empty_buffer
        (buf : buffer_type);
   primitive;

    { This procedure empties the specified buffer. }

   function extract
        (buf    : buffer_type;
         amount : integer) : data_type;
   primitive;

    { This function removes the specified amount of data from
    the specified buffer, and returns this data as the function
    value. }

   procedure free_reassembly_resources;
   primitive;

    { This procedure releases the resources that had been previously
    allocated by the procedure allocate_reassembly_resources. }

   function get_checksum
        (pdu : pdu_type) : integer;
   primitive;

    { This function returns the 16 bit integer value to be placed in the
    checksum field of the PDU.  If the checksum facility is not being
    used, then this function returns the value zero.  The algorithm for
    producing a correct checksum value is specified in Annex A. }

   function get_data_unit_id
        (da : NPAI_addr_type) : integer;
   primitive;

    { This function returns a data unit identifier which is unique for
    the specified destination address. }
ToP   noToC   RFC0926 - Page 78
   function get_er_data_field
        (error : error_type;
         pdu   : pdu_type) : data_type;
   primitive;

    { This function returns the correct data field for an error report,
    based on the information that the specified PDU is being discarded
    due to the specified error.  The data field of an error report must
    include the header of the discarded PDU, and may optionally contain
    additional user data. }

   function get_er_flag
        (nsdu : nsdu_type) : boolean;
   primitive;

    { This function returns a boolean value to be used as the error
    report flag in a PDU which transmits the specified nsdu.  If the PDU
    must be discarded at some future time, an error report can be
    returned only if this value is set to TRUE. }

   function get_er_lifetime
        (da : NPAI_addr_type) : integer;
   primitive;

    { This function returns the lifetime value to be used for an error
    report being sent to the specified destination address. }

   function get_er_options
        (error   : error_type;
         da      : NPAI_addr_type;
         options : options_type) : options_type;
   primitive;

    { This function returns the options field of an error report, based
    on the reason for discard, and the destination address and options
    field of the discarded PDU.  The options field contains the reason
    for discard option, and may contain other optional fields. }
ToP   noToC   RFC0926 - Page 79
   function get_er_seg_per

        (pdu     : pdu_type) : boolean;
   primitive;

    { This function returns the boolean value which will be used for the
    segmentation permitted flag of an error report. }

   function get_header_len
        (da_len  : integer;
         sa_len  : integer;
         sp      : boolean;
         options : options_type) : integer;
   primitive;

    { This function returns the header length, in octets.  This depends
    upon the lengths of the source and destination addresses, whether
    the segmentation part of the header is present, and the length of
    the options part. }

   function get_lifetime
        (da  : NSAP_addr_type;
         qos : quality_of_service_type) : lifetime_type;
   primitive;

    { This function returns the lifetime value to be used for a PDU,
    based upon the destination address and requested quality of service.
    }

   function get_local_NPAI_addr : NPAI_addr_type;
   primitive;

    { This functions returns the local address as used in the protocol
    header. }

   function get_local_NPAI_addr_len : integer;
   primitive;

    { This functions returns the length of the local address as used in
    the protocol header. }
ToP   noToC   RFC0926 - Page 80
   function get_NPAI
        (addr : NSAP_addr_type) : NPAI_addr_type;
   primitive;

    { This function returns the network address as used in the protocol
    header, or "Network Protocol Addressing Information", corresponding
    to the specified NSAP address. }

   function get_NPAI_len
        (addr : NSAP_addr_type) : integer;
   primitive;

    { This function returns the length of the network address
    corresponding to a specified NSAP address. }

   function get_NSAP_addr
        (addr : NPAI_addr_type;
         len  : integer) : NSAP_addr_type;
   primitive;

    { This function returns the NSAP address corresponding to the
    network protocol addressing information (as it appears in the
    protocol header) of the specified length. }

   function get_options
        (da  : NSAP_addr_type;
         qos : quality_of_service_type) : options_type;
   primitive;

    { This function returns the options field for a PDU, based on the
    requested destination address and quality of service. }

   function get_seg_permitted
        (da : NSAP_addr_type;
         qos : quality_of_service_type) : boolean;
   primitive;

    { This function returns the boolean value to be used in the
    segmentation permitted field of a PDU.  This value may depend upon
    the destination address, requested quality of service, and the
    length of the user data. }
ToP   noToC   RFC0926 - Page 81
   function get_sn_qos
        (subnet_id : subnet_id_type;

          options   : options_type) : SN_QOS_type;
   primitive;

    { This function returns the quality of service to be used on the
    specified subnetwork, in order to obtain the quality of service (if
    any) and other parameters requested in the options part of the PDU.
    }

   function get_qos
        (options : options_type) : quality_of_service_type;
   primitive;

    { This function determines, to the extent possible, the quality of
    service that was obtained for a particular PDU, based upon the
    quality of service and other information contained in the options
    part of the PDU header. }

   function make_buffer
        (data : data_type) : buffer_type;
   primitive;

    { This function places the specified data in a newly created buffer.
    The precise manner of handling buffers is implementation specific.
    This newly created buffer is returned as the function value. }

   procedure merge_seg
        (buf   : buffer_type;
         so    : integer;
         data  : data_type);
   primitive;

    { This procedure merges the specified data into the specified
    buffer, based on the specified segment offset of the data. }

   function NPAI_addr_local
        (addr : NPAI_addr_type) : boolean;
   primitive;

    { This function returns the boolean value TRUE only if the specified
    network protocol addressing information specifies a local address. }
ToP   noToC   RFC0926 - Page 82
   function NSAP_addr_local
        (addr : NSAP_addr_type) : boolean;
   primitive;

    { This function returns the boolean value TRUE only if the specified
    NSAP address specifies a local address. }

   procedure post_error_report
        (er_pdu : pdu_type);
   primitive;

    { This procedure posts the specified error report (ER) type PDU to
    the appropriate local entity that handles error reports. }

   function route
        (hli     : integer;
         sp      : boolean;
         da      : NPAI_addr_type;
         options : options_type;
         datalen : integer) : route_result_type;
   primitive;

    { This function determines the route to be followed by a PDU
    segment, as well as the segment size.  Note that in general, the
    segment size and route may be mutually dependent.  This
    determination is made on the basis of the header length, the
    segmentation permitted flag, the destination address, several
    parameters (such as source routing) contained in the options part of
    the PDU header, and the length of data.  This function returns a
    structure that specifies the subnetwork on which the segment should
    be transmitted, the source and destination addresses to be used on
    the subnetwork, and the segment size.  This routine may only be
    called if the primitive function check_parameters has already
    determined that an error will not occur. }
ToP   noToC   RFC0926 - Page 83
   function send_er_on_congestion
       (pdu : pdu_type) : boolean;
   primitive;

    { This function returns the boolean value true if an error report
    should be sent when the indicated data unit is discarded due to
    congestion.  Note that if the value true is returned, then the
    er_flag field of the discarded data unit must still be checked
    before an error report can be sent. }

   function size
       (data : data_type) : integer;
   primitive;

    { This function returns the length, in octets, of the specified
    data. }

   function size_buf
       (buf : buffer_type) : integer;
   primitive;

    { This function returns the length, in octets, of the data contained
    in the specified buffer. }

   initialize

    begin
        state to INITIAL;
    end;
ToP   noToC   RFC0926 - Page 84
   trans  (* begin transitions *)

   from INITIAL  to  CLOSED
   when      N.UNITDATA_request
   provided  not NSAP_addr_local(NS_Destination_Address)

   begin
     nsdu.da   := NS_Destination_Address;
     nsdu.sa   := NS_Source_Address;
     nsdu.qos  := NS_Quality_o  _Service;
     nsdu.data := NS_Userdata;

     pdu.nlp_id   := ISO_8473_protocol_id;
     pdu.vp_id    := version1;
     pdu.lifetime := get_lifetime(nsdu.da, nsdu.qos);
     pdu.sp       := get_seg_permitted(nsdu.da, nsdu.qos);
     pdu.ms       := FALSE;
     pdu.er_flag  := get_er_flag(nsdu);
     pdu.pdu_tp   := DT;
     pdu.da_len   := get_NPAI_len(nsdu.da);
     pdu.da       := get_NPAI(nsdu.da);
     pdu.sa_len   := get_NPAI_len(nsdu.sa);
     pdu.sa       := get_NPAI(nsdu.sa);
     pdu.options  := get_options(nsdu.da, nsdu.qos);
     pdu.data     := nsdu.data;

     pdu.hli      := get_header_len(pdu.da_len,
                                    pdu.sa_len,
                                    pdu.sp,
                                    pdu.options);

     if (pdu.sp) then
           begin
             pdu.du_id    := get_data_unit_id(pdu.da);
             pdu.so       := ZERO;
             pdu.tot_len  := pdu.hli  +  size(pdu.data);
           end;

     if (size(pdu.data) > max_user_data) then
           send_error_report(TOO_MUCH_USER_DATA, pdu)
     else
           send_pdu(pdu);
   end;
ToP   noToC   RFC0926 - Page 85
   from INITIAL  to  CLOSED
   when      N.UNITDATA_request
   provided  NSAP_addr_local(NS_Destination_Address)

   begin
     nsdu.da   := NS_Destination_Address;
     nsdu.sa   := NS_Source_Address;
     nsdu.qos  := NS_Quality_of_Service;
     nsdu.data := NS_Userdata;

     out N.UNITDATA_indication
         (nsdu.da, nsdu.sa, nsdu.qos, nsdu.data);

   end;

   from INITIAL  to  CLOSED
   when      SN[subnet_id].UNITDATA_indication
   provided  NPAI_addr_local(SN_Userdata.da)  and
             SN_Userdata.so       =  ZERO     and
             not  SN_Userdata.ms

   begin
     pdu := SN_Userdata;

     if (pdu.pdu_tp = DT) then
         out N.UNITDATA_indication
            (get_NSAP_addr(pdu.da_len, pdu.da),
             get_NSAP_addr(pdu.sa_len, pdu.sa),
             get_qos(pdu.options),
             pdu.data)

     else
         post_error_report(pdu);

   end;
ToP   noToC   RFC0926 - Page 86
   from INITIAL  to  REASSEMBLING
   when      SN[subnet_id].UNITDATA_indication
   provided  NPAI_addr_local(SN_Userdata.da)    and
             ((SN_Userdata.so > ZERO) or (SN_Userdata.ms))

   begin
     pdu := SN_Userdata;
     allocate_reassembly_resources(pdu.tot_len);
     empty_buffer(rcv_buf);

     merge_seg
        (rcv_buf,
         pdu.so,
         pdu.data);

     out S.TIMER_request
        (pdu.lifetime,
         lifetime_timer,
         ZERO);

   end;

   from INITIAL  to  CLOSED
   when      SN[subnet_id].UNITDATA_indication
   provided  not NPAI_addr_local(SN_Userdata.da)

   begin
     pdu := SN_Userdata;

     if (pdu.lifetime > elapsed_time) then
       begin
         pdu.lifetime := pdu.lifetime - elapsed_time;
         send_pdu(pdu);
       end
   else
       send_error_report(LIFETIME_EXPIRED, pdu);

   end;
ToP   noToC   RFC0926 - Page 87
   from REASSEMBLING  to  REASSEMBLING
   when      SN[subnet_id].UNITDATA_indication
   provided  (SN_Userdata.du_id   = pdu.du_id)   and
             (SN_Userdata.da_len  = pdu.da_len)  and
             (SN_Userdata.da      = pdu.da)      and
             (SN_Userdata.sa_len  = pdu.sa_len)  and
             (SN_Userdata.sa      = pdu.sa)

   begin
     merge_seg
        (rcv_buf,
         SN_Userdata.so,
         SN_Userdata.data);

   end;

   from REASSEMBLING  to  CLOSED
   provided  data_unit_complete(rcv_buf)
   no delay

   begin
     if (pdu.pdu_tp = DT) then
         out N.UNITDATA_indication
            (get_NSAP_addr(pdu.da_len, pdu.da),
             get_NSAP_addr(pdu.sa_len, pdu.sa),
             get_qos(pdu.options),
             extract (rcv_buf, size_buf(rcv_buf)))
    else
        post_error_report(pdu);
    out S.TIMER_cancel(lifetime_timer,ZERO);
    free_reassembly_resources;

   end;

   from REASSEMBLING  to  CLOSED
   when      S.TIMER_indication

   begin
     send_error_report(LIFETIME_EXPIRED, pdu);

   end;
ToP   noToC   RFC0926 - Page 88
9  CONFORMANCE

 For conformance to this International Standard, the ability to
 originate, manipulate, and receive PDUs in accordance with the full
 protocol (as opposed to the "non-segmenting" or "Inactive Network Layer
 Protocol" subsets) is required.

 Additionally, the provision of the optional functions described in
 Section 6.17 and enumerated in Table 9-1 must meet the requirements
 described therein.

 Additionally, conformance to the Standard requires adherence to the
 formal description of Section 8 and to the structure and encoding of
 PDUs of Section 7.

 If and only if the above requirements are met is there conformance to
 this International Standard.

 9.1  Provision of Functions for Conformance

  The following table categorizes the functions in Section 6 with
  respect to the type of system providing the function:
ToP   noToC   RFC0926 - Page 89
  +---------------------------------------------------------+
  | Function                   |  Send  | Forward | Receive |
  |---------------------------------------------------------|
  | PDU Composition            |   M    |    -    |    -    |
  | PDU Decomposition          |   M    |    -    |    M    |
  | Header Format Analysis     |   -    |    M    |    M    |
  | PDU Lifetime Control       |   -    |    M    |    I    |
  | Route PDU                  |   -    |    M    |    -    |
  | Forward PDU                |   M    |    M    |    -    |
  | Segment PDU                |   M    | (note 1)|    -    |
  | Reassemble PDU             |   -    |    I    |    M    |
  | Discard PDU                |   -    |    M    |    M    |
  | Error Reporting            |   -    |    M    |    M    |
  | PDU Header Error Detection |   M    |    M    |    M    |
  | Padding                    |(note 2)| (note 2)| (note 2)|
  | Security                   |   -    | (note 3)| (note 3)|
  | Complete Source Routing    |   -    | (note 3)|    -    |
  | Partial Source Routing     |   -    | (note 4)|    -    |
  | Record Route               |   -    | (note 4)|    -    |
  | QoS Maintenance            |   -    | (note 4)|    -    |
  +---------------------------------------------------------+

                Table 9-1.  Categorization of Functions

  +---------------------------------------------------------+
  | KEY:                                                    |
  |       M : Mandatory Function; must be implemented       |
  |       - : Not applicable                                |
  |       I : Implementation option, as described in text   |
  +---------------------------------------------------------+

  Notes:

   1)  The Segment PDU function is in general mandatory for an
       intermediate system. However, a system which is to be connected
       only to subnetworks all offering the same maximum SNSDU size
       (such as identical Local Area Networks) will not need to perform
       this function and therefore does not need to implement it.

       If this function is not implemented, this shall be stated as part
       of the specification of the implementation.
ToP   noToC   RFC0926 - Page 90
   2)  The correct treatment of the padding function requires no
       processing. A conforming implementation shall support the
       function, to the extent of ignoring this parameter wherever it
       may appear.

   3)  This function may or may not be supported. If an implementation
       does not support this function, and the function is selected by a
       PDU, then the PDU shall be discarded, and an ER PDU shall be
       generated and forwarded to the originating network-entity if the
       Error Report flag is set.

   4)  This function may or may not be supported. If an implementation
       does not support this function, and the function is selected by a
       PDU, then the function is not provided and the PDU is processed
       exactly as though the function was not selected. The PDU shall
       not be discarded.
ToP   noToC   RFC0926 - Page 91
                                ANNEXES

 (These annexes are provided for information for implementors and are
 not an integral part of the body of the Standard.)

                ANNEX A.  SUPPORTING TECHNICAL MATERIAL

 A.1  Data Unit Lifetime

  There are two primary purposes of providing a PDU lifetime capability
  in the ISO 8473 Protocol. One purpose is to ensure against unlimited
  looping of protocol data units. Although the routing algorithm should
  ensure that it will be very rare for data to loop, the PDU lifetime
  field provides additional assurance that loops will be limited in
  extent.

  The other important purpose of the lifetime capability is to provide
  for a means by which the originating network entity can limit the
  Maximum NSDU lifetime. ISO Transport Protocol Class 4 assumes that
  there is a particular Maximum NSDU Lifetime in order to protect
  against certain error states in the connection establishment and
  termination phases. If a TPDU does not arrive within this time, then
  there is no chance that it will ever arrive. It is necessary to make
  this assumption, even if the Network Layer does not guarantee any
  particular upper bound on NSDU lifetime. It is much easier for
  Transport Protocol Class 4 to deal with occasional lost TPDUs than to
  deal with occasional very late TPDUs. For this reason, it is
  preferable to discard very late TPDUs than to deliver them. Note that
  NSDU lifetime is not directly associated with the retransmission of
  lost TPDUs, but relates to the problem of distinguishing old
  (duplicate) TPDUs from new TPDUs.

  Maximum NSDU Lifetime must be provided to transport protocol entity in
  units of time; a transport entity cannot count "hops". Thus NSDU
  lifetime must be calculated in units of time in order to be useful in
  determining Transport timer values.

  In the absence of any guaranteed bound, it is common to simply guess
  some value which seems like a reasonable compromise. In essence one is
  simply assuming that "surely no TPDU would ever take more than 'x'
  seconds to traverse the network." This value is probably chosen by
  observation of past performance, and may
ToP   noToC   RFC0926 - Page 92
  vary with source and destination.

  Three possible ways to deal with the requirement for a limit on the
  maximum NSDU lifetime are: (1) specify lifetime in units of time,
  thereby requiring intermediate systems to decrement the lifetime field
  by a value which is an upper bound on the time spent since the
  previous intermediate system, and have the Network Layer discard
  protocol data units whose lifetime has expired; (2) provide a
  mechanism in the Transport Layer to recognize and discard old TPDUs;
  or (3) ignore the problem, anticipating that the resulting
  difficulties will be rare. Which solution should be followed depends
  in part upon how difficult it is to implement solutions (1) and (2),
  and how strong the transport requirement for a bounded time to live
  really is.

  There is a problem with solution (2) above, in that transport entities
  are inherently transient. In case of a computer system outage or other
  error, or in the case where one of the two endpoints of a connection
  closes without waiting for a sufficient period of time (approximately
  twice Maximum NSDU Lifetime), it is possible for the Transport Layer
  to have no way to know whether a particular TPDU is old unless
  globally synchronized clocks are used (which is unlikely). On the
  other hand, it is expected that intermediate systems will be
  comparatively stable. In addition, even if intermediate systems do
  fail and resume processing without memory of the recent past, it will
  still be possible (in most instances) for the intermediate system to
  easily comply with lifetime in units of time, as discussed below.

  It is not necessary for each intermediate system to subtract a precise
  measure of the time that has passed since an NPDU (containing the TPDU
  or a segment thereof) has left the previous intermediate system. It is
  sufficient to subtract an upper bound on the time taken. In most
  cases, an intermediate system may simply subtract a constant value
  which depends upon the typical near-maximum delays that are
  encountered in a specific subnetwork. It is only necessary to make an
  accurate estimate on a per NPDU basis for those subnetworks which have
  both a relatively large maximum delay, and a relatively large
  variation in delay.

  As an example, assume that a particular local area network has short
  average delays, with overall delays generally in the 1 to 5
ToP   noToC   RFC0926 - Page 93
  millisecond range and with occasional delays up to 20 milliseconds. In
  this case, although the relative range in delays might be large (a
  factor of 20), it would still not be necessary to measure the delay
  for actual NPDUs. A constant value of 20 milliseconds (or more) can be
  subtracted for all delays ranging from .5 seconds to .6 seconds (.5
  seconds for the propagation delay, 0 to .1 seconds for queueing delay)
  then the constant value .6 seconds could be used.

  If a third subnetwork had normal delays ranging from .1 to 1 second,
  but occasionally delivered an NPDU after a delay of 15 seconds, the
  intermediate system attached to this subnetwork might be required to
  determine how long it has actually take the PDU to transit the
  subnetwork. In this last example, it is likely to be more useful to
  have the intermediate systems determine when the delays are extreme ad
  discard very old NPDUs, as occasional large delays are precisely what
  causes the Transport Protocol the most trouble.

  In addition to the time delay within each subnetwork, it is important
  to consider the time delay within intermediate systems. It should be
  relatively simple for those gateways which expect to hold on to some
  data-units for significant periods of time to decrement the lifetime
  appropriately.

  Having observed that (i) the Transport Protocol requires Maximum NSDU
  to be calculated in units of time; (ii) in the great majority of
  cases, it is not difficult for intermediate systems to determine a
  valid upper bound on subnetwork transit time; and (iii) those few
  cases where the gateways must actually measure the time take by a NPDU
  are precisely the cases where such measurement truly needs to be made,
  it can be concluded that NSDU lifetime should in fact be measured in
  units of time, and that intermediate systems should required to
  decrement the lifetime field of the ISO 8473 Protocol by a value which
  represents an upper bound on the time actually taken since the
  lifetime field was last decremented.

 A.2  Reassembly Lifetime Control

  In order to ensure a bound on the lifetime of NSDUs, and to
  effectively manage reassembly buffers in the Network Layer, the
  Reassembly Function described in Section 6 must control the
ToP   noToC   RFC0926 - Page 94
  lifetime of segments representing partially assembled PDUs. This annex
  discusses methods of bounding reassembly lifetime and suggests some
  implementation guidelines for the reassembly function.

  When segments of a PDU arrive at a destination network-entity, they
  are buffered until an entire PDU is received, assembled, and passed to
  the PDU Decomposition Function. The connectionless Internetwork
  Protocol does not guarantee the delivery of PDUs; hence, it is
  possible for some segments of a PDU to be lost or delayed such that
  the entire PDU cannot be assembled in a reasonable length of time. In
  the case of loss of a PDU "segment", for example, this could be
  forever. There are a number of possible schemes to prevent this:

   a)  Per-PDU reassembly timers,

   b)  Extension of the PDU Lifetime control function, and

   c)  Coupling of the Transport Retransmission timers.

  Each of these methods is discussed in the subsections which follow.

  A.2.1  Method (a)

   assigns a "reassembly lifetime" to each PDU received and identified
   by its Data-unit Identifier. This is a local, real time which is
   assigned by the reassembly function and decremented while some, but
   not all segments of the PDU are being buffered by the destination
   network-entity. If the timer expires, all segments of the PDU are
   discarded, thus freeing the reassembly buffers and preventing a "very
   old" PDU from being confused with a newer one bearing the same
   Data-unit Identifier. For this scheme to function properly, the
   timers must be assigned in such a fashion as to prevent the
   phenomenon of Reassembly Interference (discussed below). In
   particular, the following guidelines should be followed:

    1)  The Reassembly Lifetime must be much less than the maximum PDU
        lifetime of the network (to prevent the confusion of old and new
        data-units).
ToP   noToC   RFC0926 - Page 95
    2)  The lifetime should be less than the Transport protocol's
        retransmission timers minus the average transit time of the
        network. If this is not done, extra buffers are tied up holding
        data which has already been retransmitted by the Transport
        Protocol. (Note that an assumption has been made that such
        timers are integral to the Transport Protocol, which in some
        sense, dictates that retransmission functions must exist in the
        Transport Protocol employed).

  A.2.2  Method (b)

   is feasible if the PDU lifetime control function operates based on
   real or virtual time rather than hop-count. In this scheme, the
   lifetime field of all PDU segments of a Data-unit continues to be
   decremented by the reassembly function of the destination
   network-entity as if the PdU were still in transit (in a sense, it
   still is). When the lifetime of any segment of a partially
   reassembled PDU expires, all segments of that PDU are discarded. This
   scheme is attractive since the delivery behavior of the ISO 8473
   Protocol would be identical for segmented and unsegmented PDUs.

  A.2.3  Method (c)

   couples the reassembly lifetime directly to the Transport Protocol's
   retransmission timers, and requires that Transport Layer management
   make known to Network Layer Management (and hence, the Reassembly
   Function) the values of its retransmission timers for each source
   from which it expects to be receiving traffic. When a PDU segment is
   received from a source, the retransmission time minus the anticipated
   transit time becomes the reassembly lifetime of that PDU. If this
   timer expires before the entire PDU has been reassembled, all
   segments of the PDU are discarded. This scheme is attractive since it
   has a low probability of holding PDU segments that have already been
   retransmitted by the source Transport-entity; it has, however, the
   disadvantage of depending on reliable operation of the Transport
   Protocol to work effectively. If the retransmission timers are not
   set correctly, it is possible that all PDUs would be discarded too
   soon, and the Transport Protocol would make no progress.

 A.3  The Power of the Header Error Detection Function
ToP   noToC   RFC0926 - Page 96
  A.3.1  General

   The form of the checksum used for PDU header error detection is such
   that it is easily calculated in software or firmware using only two
   additions per octet of header, yet it has an error detection power
   approaching (but not quite equalling) that of techniques (such as
   cyclic polynomial checks) which involve calculations that are much
   more time- or space-consuming. This annex discusses the power of this
   error detection function.

   The checksum consists of two octets, either of which can assume any
   value except zero. That is, 255 distinct values for each octet are
   possible. The calculation of the two octets is such that the value of
   either is independent of the value of the other, so the checksum has
   a total of 255 x 255 = 65025 values. If one considers all ways in
   which the PDU header might be corrupted as equally likely, then there
   is only one chance in 65025 that the checksum will have the correct
   value for any particular corruption. This corresponds to 0.0015  of
   all possible errors.

   The remainder of this annex considers particular classes of errors
   that are likely to be encountered. The hope is that the error
   detection function will be found to be more powerful, or at least no
   less powerful, against these classes as compared to errors in
   general.

  A.3.2  Bit Alteration Errors

   First considered are classes of errors in which bits are altered, but
   no bits are inserted nor deleted. This section does not consider the
   case where the checksum itself is erroneously set to be all zero;
   this case is discussed in section A.3.4.

   A burst error of length b is a corruption of the header in which all
   of the altered bits (no more than b in number) are within a single
   span of consecutively transmitted bits that is b bits long. Checksums
   are usually expected to do well against burst errors of a length not
   exceeding the number of bits in the header error detection parameter
   (16 for the PDU header). The PDU header error detection parameter in
   fact fails to detect only 0.000019  of all such errors, each distinct
   burst error of length 16 or less being considered to be equally
   likely. In particular,
ToP   noToC   RFC0926 - Page 97
   it cannot detect an 8-bit burst in which an octet of zero is altered
   to an octet of 255 (all bits = 1) or vice versa. Similarly, it fails
   to detect the swapping of two adjacent octets only if one is zero and
   the other is 255.

   The PDU header error detection, as should be expected, detects all
   errors involving only a single altered bit.

   Undetected errors involving only two altered bits should occur only
   if the two bits are widely separated (and even then only rarely). The
   PDU header error detection detects all double bit errors for which
   the spacing between the two altered bits is less than 2040 bits = 255
   octets. Since this separation exceeds the maximum header length, all
   double bit errors are detected.

   The power to detect double bit errors is an advantage of the checksum
   algorithm used for the protocol, versus a simple modulo 65536
   summation of the header split into 16 bit fields. This simple
   summation would not catch all such double bit errors. In fact, double
   bit errors with a spacing as little as 16 bits apart could go
   undetected.

  A.3.3  Bit Insertion/Deletion Errors

   Although errors involving the insertion or deletion of bits are in
   general neither more nor less likely to go undetected than are all
   other kinds of general errors, at least one class of such errors is
   of special concern. If octets, all equal to either zero or 255, are
   inserted at a point such that the simple sum CO in the running
   calculation (described in Annex C) happens to equal zero, then the
   error will go undetected. This is of concern primarily because there
   are two points in the calculation for which this value for the sum is
   not a rare happenstance, but is expected; namely, at the beginning
   and the end. That is, if the header is preceded or followed by
   inserted octets all equal to zero or 255 then no error is detected.
   Both cases are examined separately.

   Insertion of erroneous octets at the beginning of the header
   completely misaligns the header fields, causing them to be
   misinterpreted. In particular, the first inserted octet is
   interpreted as the network layer protocol identifier, probably
   eliminating any knowledge that the data unit is related to the
ToP   noToC   RFC0926 - Page 98
   ISO 8473 Protocol, and thereby eliminating any attempt to perform the
   checksum calculation or invoking a different form of checksum
   calculation. An initial octet of zero is reserved for the Inactive
   Network Layer Protocol. This is indeed a problem but not one which
   can be ascribed to the form of checksum being used. Therefore, it is
   not discussed further here.

   Insertion of erroneous octets at the end of the header, in the
   absence of other errors, is impossible because the length field
   unequivocally defines where the header ends. Insertion or deletion of
   octets at the end of the header requires an alteration in the value
   of the octet defining the header length. Such an alteration implies
   that the value of the calculated sum at the end of the header would
   not be expected to have the dangerous value of zero and consequently
   that the error is just as likely to be detected as is any error in
   general.

   Insertion of an erroneous octet in the middle of the header is
   primarily of concern if the inserted octet has either the value zero
   or 255, and if the variable CO happens to have the value zero at this
   point. In most cases, this error will completely destroy the parsing
   of the header, which will cause the data unit to e discarded. In
   addition, in the absence of any other error, the last octet of the
   header will be thought to be data. This in turn will cause the header
   to end in the wrong place. In the case where the header otherwise can
   parse correctly, the last field will be found to be missing. Even in
   the case where necessary, the length field is the padding option, and
   therefore not necessary, the length field for the padding function
   will be inconsistent with the header length field, and therefore the
   error can be detected.

  A.3.4  Checksum Non-calculation Errors

   Use of the header error detection function is optional. The choice of
   not using it is indicated by a checksum parameter value of zero. This
   creates the possibility that the two octets of the checksum parameter
   (neither of which is generated as being zero) could both be altered
   to zero. This would in effect be an error not detected by the
   checksum since the check would not be made. One of three
   possibilities exists:

    1)  A burst error of length sixteen (16) which sets the entire
ToP   noToC   RFC0926 - Page 99
    checksum to zero. Such an error could not be detected; however, it
        requires a particular positioning of the burst within the
        header. [A calculation of its effect on overall detectability of
        burst errors depends upon the length of the header.]

    2)  All single bit errors are detected. Since both octets of the
        checksum field must be non-zero when the checksum is being used,
        no single bit error can set the checksum to zero.

    3)  Where each of the two octets of the checksum parameter has a
        value that is a power of two, such that only one bit in each
        equals one (1), then a zeroing of the checksum parameter could
        result in an undetected double bit error. Furthermore, the two
        altered bits have a separation of less than sixteen (16), and
        could be consecutive. This is clearly a decline from the
        complete detectability previously described.

   Where a particular administration is highly concerned about the
   possibility of accidental zeroing of the checksum among data units
   within its domain, then the administration may impose the restriction
   that all data units whose source or destination lie within its domain
   must make use of the header error detection function. Any data units
   which do not could be discarded, nor would they be allowed outside
   the domain. This protects against errors that occur within the
   domain, and would protect all data units whose source or destination
   lies within the domain, even where the data path between all such
   pairs crosses other domains (errors outside the protected domain
   notwithstanding).
ToP   noToC   RFC0926 - Page 100
                      ANNEX B.  NETWORK MANAGEMENT

 The following topics are considered to be major components of Network
 Layer management:

  A.  Routing

   Considered by many to be the most crucial element of Network Layer
   management, since management of the Routing algorithms for networking
   seem to be an absolutely necessary prerequisite to a practical
   networking scheme.

   Routing management consists of three parts; forwarding, decision, and
   update. Management of forwarding is the process of interpreting the
   Network Layer address to properly forward NSDUs on its next network
   hop on a route through the network. Management of decision is the
   process of choosing routes for either connections or NSDUs, depending
   on whether the network is operating a connection-oriented or
   connectionless protocol. The decision component will be driven by a
   number of considerations, not the least of which are those associated
   with Quality of Service. Management of update is the management
   protocol(s) used to exchange information among
   intermediate-systems/network- entities which is used in the decision
   component to determine routes.

   To what extent is it desirable and/or practical to pursue a single
   OSI network routing algorithm and associated Management protocol(s)?
   It is generally understood that it is impractical to expect ISO to
   adopt a single global routing algorithm. On the other hand, it is
   recognized that having no standard at all upon which to make routing
   decisions effectively prevents an internetwork protocol from working
   at all. One possible compromise would be to define the principles for
   the behavior of an internetwork routing algorithm. A possible next
   step would be to specify the types of information that must be
   propagated among the intermediate-systems/network-entities via their
   update procedures. The details of the updating protocol might then be
   left to bilateral agreements among the cooperating administrations.
ToP   noToC   RFC0926 - Page 101
  B.  Statistical Analysis

   These management functions relate to the gathering and reporting of
   information about the real-time behavior of the global network. They
   consist of Data counts such as number of PDUs forwarded, entering
   traffic, etc., and Event Counts such as topology changes, quality of
   service changes, etc.

  C.  Network Control

   These management functions are those related to the control of the
   global network, and possibly could be performed by a Network Control
   Center(s). The control functions needed are not al all clear. Neither
   are the issues relating to what organization(s) is/are responsible
   for the management of the environment. Should there be a Network
   Control Center distinct from those provided by the subnetwork
   administrations? What subnetwork management information is needed by
   the network management components to perform their functions?

  D.  Directory Mapping Functions

   Does the Network layer contain a Directory function as defined in the
   Reference Model? Current opinion is that the Network Layer restricts
   itself to the function of mapping NSAP addresses to routes.

  E.  Congestion Control

   Does this come under the umbrella of Network Layer management? How?

  F.  Configuration Control

   This is tightly associated with the concepts of Resource Management,
   and is generally considered to be somehow concerned with the control
   of the resources used in the management of the global network. The
   resources which have to be managed are Bandwidth (use of subnetwork
   resources), Processor (CPU), and Memory (buffers). Where is the
   responsibility for resources assigned, and are they appropriate for
   standardization? It appears that these
ToP   noToC   RFC0926 - Page 102
   functions are tightly related to how one signals changes in Quality
   of Service.

  G.  Accounting

   What entities, administrations, etc., are responsible for network
   accounting? How does this happen? What accounting information, if
   any, is required from the subnetworks in order to charge for network
   resources? Who is charged? To what degree is this to be standardized?
ToP   noToC   RFC0926 - Page 103
      ANNEX C.  ALGORITHMS FOR PDU HEADER ERROR DETECTION FUNCTION

 This Annex describes algorithm which may be used to computer, check and
 update the checksum field of the PDU Header in order to provide the PDU
 Header Error Detection function described in Section 6.11.

 C.1  Symbols used in algorithms

  CO,C1  variables used in the algorithms
  i      number (i.e., position) of an octet within the header
  n      number (i.e., position) of the first octet of the checksum
         parameter (n=8)
  L      length of the PDU header in octets
  X      value of octet one of the checksum parameter
  Y      value of octet two of the checksum parameter
  a      octet occupying position i of the PDU header

 C.2  Arithmetic Conventions

  Addition is performed in one of the two following modes:

   a)  modulo 255 arithmetic;

   b)  eight-bit one's complement arithmetic in which, if any of the
       variables has the value minus zero (i.e., 255) it shall be
       regarded as though it was plus zero (i.e., 0).

 C.3  Algorithm for Generating Checksum Parameters

  A:  Construct the complete PDU header with the value of the checksum
      parameter field set to zero;

  B:  Initialize C0 and C1 to zero;

  C:  Process each octet of the PDU header sequentially from i = 1 to L
      by

   a)  adding the value of the octet to C0; then

   b)  adding the value of C0 to C1;

  D:  Calculate X = (L-8)C0 - C1 (modulo 255) and Y = (L-7) (-C0) + C1
      (modulo 255)
ToP   noToC   RFC0926 - Page 104
  E:  If X = 0, set X = 255;

  F:  If Y = 0, set Y = 255;

  G:  Place the values X and Y in octets 8 and 9 respectively.

 C.4  Algorithm for Checking Checksum Parameters

  A:  If octets 8 and 9 of PDU header both contain 0 (all bits off),
      then the checksum calculation has succeeded; otherwise initialize
      C1 = 0, C0 - 0 and proceed;

  B:  process each octet of the PDU header sequentially from i = 1 to L
      by

   a)  adding the value of the octet to C0; then

   b)  adding the value of C0 to C1;

  C:  If, when all the octets have been processed, C0 = C1 = 0 (modulo
      255) then the checksum calculation has succeeded; otherwise, the
      checksum calculation has failed.

 C.5  Algorithm to adjust checksum parameter when an octet is altered

  This algorithm adjusts the checksum when an octet (such as the
  lifetime field) is altered. Suppose the value in octet k is changed by
  Z = new_value - old_value.

  If X and Y denote the checksum values held in octets n and n+1,
  respectively, then adjust X and Y as follows:

   If X = 0 and Y = 0 do nothing, else;
        X := (k-n-1)Z + X (modulo 255) and
        Y := (n-k)Z + Y   (modulo 255).
   If X is equal to zero, then set it to 255; and
   similarly for Y.

  For this Protocol, n = 8. If the octet being altered is the lifetime
  field, k = 4. For the case where the lifetime is decreased by 1 unit
  (Z = -1), the results simplify to
ToP   noToC   RFC0926 - Page 105
   X := X + 5 (modulo 255) and
   Y := Y - 4 (modulo 255).

   Note:

    To derive this result, assume that when octet k has the value Z
    added to it then X and Y have values ZX and ZY added to them. For
    the checksum parameters to satisfy the conditions of Section 6.11
    both before and after the values are added, the following is
    required:

     Z + ZX + ZY = 0 (modulo 255) and
     (L-k+1)Z + (L-n+1)ZX + (L-n)ZY = 0 (modulo 255).

  Solving these equations simultaneously yields ZX = (k-n-1)Z and ZY +
  (m-k)Z.