File: rfc892.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (4333 lines) | stat: -rw-r--r-- 185,677 bytes
parent folder | download | duplicates (2)
<pre>Network Working Group                                   ISO
Request for Comments:  892                              December 1983


                     <span class="h1">ISO Transport Protocol Specification</span>

This document is distributed as an RFC for information only.
It does not specify a standard for the ARPA Internet.

Note:  This document appeared in:

ISO/TC97/SC16/WG6.  Information Processing Systems - Open Systems
    Interconnection - Transport Protocol Specification.  Computer
    Communication Review 12, 3-4 (July/October 1982), pp.  24-67.

and differs from it only in format.


Table of Contents

<span class="h2"><a class="selflink" id="section-0" href="#section-0">0</a>.   Introduction</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.   Scope and Field of Application</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.   References</span>

Section One - General

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.   Definitions</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.   Symbols and Abbreviations</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.   Overview</span>

     5.1  Service provided by the transport layer
     5.2  Service assumed from the network layer
     5.3  Functions of the transport layer
     5.4  Model of the transport layer

Section Two - Transport Protocol Specification

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.   Protocol Mechanisms</span>

     6.1  Assignment to network connection
     6.2  Transport protocol data unit (TPDU) transfer
     6.3  Data TPDU length and segmenting
     6.4  Concatenation and separation
     6.5  Connection establishment
     6.6  Connection refusal
     6.7  Release
     6.8  Implicit termination
     6.9  Spurious disconnect
     6.10 Data TPDU numbering
     6.11 Expedited data transfer
     6.12 Reassignment
     6.13 Reassignment after failure</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 2
International Standards Organization


     6.14 Retention until acknowledgement of TPDUs
     6.15 Resynchronization
     6.16 Multiplexing and demultiplexing
     6.17 Explicit flow control
     6.18 Checksum
     6.19 Frozen references
     6.20 Retransmission on timeout
     6.21 Resequencing
     6.22 Inactivity control
     6.23 Treatment of protocol errors
     6.24 Splitting and recombining

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.   Protocol Classes</span>
<span class="h2">     7.0  Protocol description of class 0:  simple class</span>
     7.1  Protocol description of class 1:  basic error recovery class
     7.2  Protocol description of class 2:  multiplexing class
     7.3  Protocol description of class 3:  error recovery and multiplexing
                                            class
     7.4  Protocol description of class 4:  error detection and recovery class

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.   Encoding</span>

     8.1  Summary
     8.2  Structure
     8.3  Connection Request (CR)
     8.4  Connection Confirm (CC)
     8.5  Disconnect Request (DR)
     8.6  Disconnect Confirm (DC)
     8.7  Data (DT
     8.8  Expedited Data (ED)
     8.9  Data Acknowledgement (AK)
     8.10 Expedited Data Acknowledgement (EA)
     8.11 Reject (RJ)
     8.12 TPDU Error (ERR)

Section Three  -  Conformance

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.   Conformance</span>

<span class="h2"><a class="selflink" id="section-0" href="#section-0">0</a>.   Introduction</span>

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

        The Transport Protocol Standard is positioned with respect to
other related standards by the layers defined in the Reference Model
for Open Systems Interconnection (ISO 7498).  It is most closely
related to, and lies within the field of application of the Transport</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 3
International Standards Organization


Service Standard (DP aaaa).  It also uses and makes reference to the
Network Service Standard (DP bbbb), whose provisions it assumes in
order to accomplish the transport protocol's aims.  The
interrelationship of these standards is depicted in Figure 1.

-----------------------------------TRANSPORT SERVICE DEFINITION-----

 Transport                --Reference to aims---------------
 Protocol
 Specification            --Reference to assumptions--------

------------------------------------NETWORK SERVICE DEFINITION------

Figure 1  -  Relationship between the transport protocol and adjacent
             services

        The standard specifies a common encoding and a number of
classes of transport protocol procedures to be used with different
network qualities of service.

        It is intended that the Transport Protocol should be simple
but general enough to cater for the total range of Network Service
qualities possible, without restricting future extensions.

        The protocol is structured to give rise to classes of protocol
which are designed to minimize possible incompatibilities and
implementation costs.

        The classes are selectable with respect to the Transport and
Network Services in providing the required quality of service for the
interconnection of two session entities (note that each class provides
a different set of functions for enhancement of service qualities).

        This protocol standard is concerned with optimisation of network
tariffs and the following qualities of service:

     a)  different throughput rates;
     b)  different error rates;
     c)  integrity of data requirements;
     d)  reliability requirements.

        The aim of this standard is primarily to provide a definition
for implementors.  Since the protocol is complex, the document contains
much material which is advisory or descriptive, but mandatory
requirements on implementations are clearly identified.

        It should be noted that, as the number of valid protocol sequences
is very large, it is not possible with current technology to verify that an
implementation will operate the protocol defined in this document
correctly under all circumstances.  It is possible by means of testing</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 4
International Standards Organization


to establish confidence that an implementation correctly operates the
protocol in a representative sample of circumstances.  It is, however,
intended that this standard can be used in circumstances where two
implementations fail to communicate in order to determine whether one
or both have failed to operate the protocol correctly.

        The variations and options available within this standard are
essential to enable a Transport Service to be provided for a wide
variety of applications over a variety of network qualities.  Thus, a
minimally conforming implementation will not be suitable for use in
all possible circumstances.  It is important therefore to qualify all
references to this standard with statements of the options provided or
required or with statements of the intended purpose of provision or
use.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.      Scope and Field of Application</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>     This International Standard Specifies:</span>

        a)  five classes of procedures

                1) Class 0.  Simple class;
                2) Class 1.  Basic error recovery class;
                3) Class 2.  Multiplexing class;
                4) Class 3.  Error recovery class;
                5) Class 4.  Error detection and recovery class,

                for the transfer of data and control information from
                one transport entity to a peer transport entity;

        b)  the means of negotiating the class of procedures to be
            used by the transport entities;

        c)  the encoding of the transport protocol data units used for
            the transfer of data and control information;

        d)  the functional requirements of equipment within a
            computer system claiming to implement these procedures.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>     The procedures are defined in terms of:</span>

        a)  the interactions between peer transport entities through
            the exchange of transport protocol data units;

        b)  the interactions between a transport entity and the
            transport service user in the same system through the exchange of
            transport service primitives;

        c)  the interactions between a transport entity and the
            network service provider through the exchange of network</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 5
International Standards Organization


            service primitives.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>     This International Standard is applicable to equipment which</span>
<span class="h3">        supports the Transport Layer of the OSI Reference Model and which</span>
        wishes to interconnect in an open systems environment.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.      References</span>

ISO 7498        Information processing systems - Open systems inter-
                connection - Basic Reference Model

DP aaaa         Information processing systems - Open systems inter-
                connection - Transport service definition (N1169).

DP bbbb         Information processing systems - Open systems inter-
                connection - Connection-oriented network service
                definition (N729)

Section One - General

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.      Definitions</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>     Equipment:  </span>Hardware or software or a combination of both; it
        need not be physically distinct within a computer system.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>     Transport service user:  </span>An abstract representation of the
        totality of those entities within a single system that make
        use of the transport service.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>     Network service provider:  </span>An abstract machine which models
        the totality of the entities providing the network service,
        as viewed by a transport entity.

        Explanatory Notes

        1.  Definitions 3.1 to 3.3 relate to terms used in clause 1.

        2.  This standard makes use of the terms, concepts, and
            definition defined in ISO 7498.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.      Symbols and Abbreviations</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>     Data Units</span>

        TPDU    Transport protocol data unit
        TSDU    Transport service data unit
        NSDU    Network service data unit

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>     Types of transport protocol data units</span>
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 6
International Standards Organization


        CR TPDU         Connection request TPDU
        CC TPDU         Connection confirm TPDU
        DR TPDU         Disconnect request TPDU
        DC TPDU         Disconnect confirm TPDU
        DT TPDU         Data TPDU
        ED TPDU         Expedited data TPDU
        AK TPDU         Data acknowledge TPDU
        EA TPDU         Expedited acknowledge TPDU
        RJ TPDU         Rejected TPDU
        ERR TPDU        Error TPDU

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>     TPDU fields</span>

        LI              Length indicator (field)
        CDT             Credit (field)
        TSAP-ID         Transport service access point identifier
                        (field)
        DST-REF         Destination reference (field)
        SCE-REF         Source reference (field)
        EOT             End of TSDU mark
        TPDU-NR         DT TPDU number (field)
        ED-TPDU-NR      ED TPDU number (field)
        YR-TU-NR        Sequence number response (field)

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>     Parameters</span>

        T (R)           Receive sequence number
        T (S)           Send sequence number

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>     Timer variables</span>

        T1              Elapse time between retransmissions
        N               The maximum number of retransmissions
        L               Bound for the maximum time between the
                        decision to transmit a TPDU and the receipt of
                        any response relating to it
        T-WAIT          Maximum time for a reassignment to take place
                        before TC failure is assumed
        I               Inactivity timer - Maximum time allowed to
                        elapse between receipt of TPDUs before TC
                        failure is assumed
        W               Window timer - Maximum interval between trans-
                        mission of up to date window information

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>     Other variables</span>

        n               The number of bits in the sequence number
                        field
        p               The number of bits in the credit field of a
                        CR, CC or AK TPDU</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 7
International Standards Organization


<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>     Miscellaneous</span>

        TS-user         Transport service user
        TSAP            Transport service access point
        NSAP            Network service access point
        TC              Transport connection
        NC              Network Connection

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.      Overview of the Transport Protocol</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>     Service Provided by the Transport Layer</span>

        The services provided by the protocol described in this
document are connection-oriented services.  They are defined in
document DP aaaa.  The Transport Service primitives provided are
summarized in Figure 1.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 8
International Standards Organization


        Primitive                               Parameters
------------------------------------------------------------------------
T-CONNECT       Request                 To Transport Address, From
                Indication              Transport Address, Expedited
                                        Data Option, Quality of
                                        Service, TS-User data.
------------------------------------------------------------------------
T-CONNECT       Response                Responding Address, Quality
                Confirmation            of Service, Expedited Data
                                        Option, TS-User data.
------------------------------------------------------------------------
T-DATA          Request                 TS-User data.
                Indication
------------------------------------------------------------------------
T-EXPEDITED     Request                 TS-User data.
DATA            Indication
------------------------------------------------------------------------
T-DISCONNECT    Request                 TS-User data.
------------------------------------------------------------------------
T-DISCONNECT    Indication              Disconnect reason, TS-User
                                        data.
------------------------------------------------------------------------

                Figure 1.  Transport Service Primitives

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>     Service Assumed from the Network Layer</span>

        The transport protocol described in this document assumes of
the Network Services described in DP bbbb.  The Network Service
primitives used are summarized in Figure 2.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                    Page 9
International Standards Organization


        Primitive               X/Y             Parameters      X/Y/Z
------------------------------------------------------------------------
N-CONNECT  Request               X              Called Address,    X
           Indication            X              Calling Address,   X
           Response              X              NS-User data,      Z
           Confirmation          X              QOS.               X
------------------------------------------------------------------------
N-DATA     Request                X              NS-User data,      X
           Indication             X              Conf. Request      Y
------------------------------------------------------------------------
N-DATA      Request               Y
ACKNOWLEDGE Indication
------------------------------------------------------------------------
N-EXPEDITED Request               Y
DATA        Indication                            NS-User data       Y
------------------------------------------------------------------------
N-RESET      Request              X
             Indication           X
             Response             X
             Confirmation         X
------------------------------------------------------------------------
N-DISCONNECT Request              X               NS-User data       Z
             Indication           X
------------------------------------------------------------------------

        X - The Transport Protocol assumes that this facility is
            provided in all networks.

        Y - The Transport Protocol assumes that this facility is
            provided in some networks and a mechanism is provided
            to optionally use the facility.

        Z - The Transport Protocol does not use this parameter.

                Figure 2.  Network Service Primitives

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>     Functions of the Transport Layer</span>

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>   Connection Oriented Functions</span>

<span class="h5"><a class="selflink" id="section-5.3.1.1" href="#section-5.3.1.1">5.3.1.1</a>  Overview of Functions</span>

        The functions in the transport layer are at least those
necessary to bridge the gap between the services available from the
network layer and those to be offered to the transport users.

        The functions in the transport layer are concerned with the
enhancement of quality of service, including all aspects of cost
optimization.  They are described below; the descriptions are grouped
into those concerned with the establishment phase, the data transfer</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 10
International Standards Organization


phase, and the release phase.

<span class="h6"><a class="selflink" id="section-5.3.1.1.1" href="#section-5.3.1.1.1">5.3.1.1.1</a>  Establishment Phase</span>

        The goal of the establishment phase is to establish a
transport connection, i.e., between two transport users.  The
functions of transport layer during this phase must match the
requested class of services with the services provided by the network
layer as follows:

        o  Select network service which best matches the requirement
           of the TS-user taking into account charges for various
           services.

        o  Decide whether to multiplex multiple transport connection
           onto a single network connection.

        o  Establish the optimum TPDU size.

        o  Select the functions that will be operational upon entering
           the data transfer phase.

        o  Map transport addresses onto network addresses.

        o  Provide a means to distinguish between two different
           transport connections.

        o  Transportation of user's data.

<span class="h6"><a class="selflink" id="section-5.3.1.1.2" href="#section-5.3.1.1.2">5.3.1.1.2</a>  Data Transfer Phase</span>

        The purpose of the data transfer phase is to permit two-way
simultaneous transport of TSDUs between the session entities connected
by the transport connection.  This purpose is achieved by means of
two-way simultaneous communication in the Transport protocol and by
the following functions. Each of these functions is used or not used
in accordance with the result of the selection performed in the
establishment phase.

        o  Concatenation and Separation

           A function used to collect several TPDUs into a single
           NSDU; the destination transport entity separates the TPDUs.

        o  Segmenting and Reassembling

           The splitting of a single data TSDU into multiple TPDUs
           which are reassembled into their original format at the
           destination.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 11
International Standards Organization


        o  Multiplexing and Demultiplexing

           A function used to share a single network connection
           between two or more transport connections.

        o  Splitting and Recombing

           A function allowing the simultaneous use of two or more
           network connections to support the same transport connec-
           tion.

        o  Flow Control

           A function used to regulate the flow of TPDUs between two
           transport entities on one transport connection.

        o  Error Detection

           A function used to detect the loss, corruption,
           duplication, misordering or misdelivery of TPDUs.

        o  Transport Connection Identification

           A means to uniquely identify a transport connection
           between the pair of transport entities supporting the
           connection during the lifetime of the transport
           connection.

        o  Error Recovery

           A function used to recover from detected and signalled
           errors.

        o  Expedited Data

           A function used to bypass the flow control of normal data
           TPDU.  Expedited data TPDUs' flow is controlled by
           separate flow control.

        o  TSDU Delimiting

           A function used to determine the beginning and ending of
           a TSDU.

<span class="h6"><a class="selflink" id="section-5.3.1.1.3" href="#section-5.3.1.1.3">5.3.1.1.3</a>  Release Phase</span>

        A function to provide a disconnection of the transport
        connection, regardless of the current activity.

<span class="h5"><a class="selflink" id="section-5.3.1.2" href="#section-5.3.1.2">5.3.1.2</a>  Classes and Options</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 12
International Standards Organization


        A class defines a set of functions.   In this protocol five
        classes are defined:

        o  Class 0:  Simple Class
        o  Class 1:  Basic Error Recovery Class
        o  Class 2:  Multiplexing Class
        o  Class 3:  Error Recovery and Multiplexing Class
        o  Class 4:  Error Detection and Recovery Class.

        Note that with the exception of classes 0 and 1, transport
        connections of different class may be multiplexed together
        onto the same network connection.

<span class="h6"><a class="selflink" id="section-5.3.1.2.2" href="#section-5.3.1.2.2">5.3.1.2.2</a>  Options within Classes</span>

        Options define potential functions which may be used within
        a class.

<span class="h6"><a class="selflink" id="section-5.3.1.2.3" href="#section-5.3.1.2.3">5.3.1.2.3</a>  Negotiation</span>

        Classes and options within classes are negotiated during
        the connection establishment phase.

<span class="h6"><a class="selflink" id="section-5.3.1.2.4" href="#section-5.3.1.2.4">5.3.1.2.4</a>  Choice of the Class of Protocol</span>

        The choice will be made by the transport entities according
        to:

        o  the users requirement expressed via T-CONNECT service
           primitives.  In particular, for the choice of the
           class of protocol, the following rules apply:

           - if the TS-User requests either transmission of
             user data during the connection phase, or use of
             Expedited data transfer, then Class 0 cannot be
             selected.

           - if the TS-User requests use of Expedited data
             transfer, then Class 2 with the non-explicit
             flow control option cannot be selected.

        o  the quality of the available Network services;

        o  the user required service versus cost ratio
           acceptable for the transport user.

        The following is a classification of network services in terms
of quality with respect to error behavior relative to the user
requirements.  Its main purpose is to provide a basis for the decision
regarding which class of transport connection should be used on top of</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 13
International Standards Organization


a given network connection.

        Type A: Network connection with acceptable residual error
                rate (for example not signalled by 'clear' or 'reset')
                and acceptable rate of signalled failures.

        Type B: Network connections with acceptable residual error
                rate (for example not signalled by 'clear' or 'reset')
                but unacceptable rate of signalled failures.

        Type C: Network connections with residual error rate not
                acceptable to the TS-user.

        It is assumed that each transport entity is aware of the
quality of service provided by particular Network connections.

<span class="h5"><a class="selflink" id="section-5.3.1.3" href="#section-5.3.1.3">5.3.1.3</a>  Potential Functions</span>

        The protocol described in this document does not include the
following set of functions which have been identified as potential
transport layer functions:

        o  provision for encryption

        o  provision for accounting mechanisms

        o  provision for status exchanges and monitoring of quality
           of service

        o  provision for blocking

        o  temporary release of network connections

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>     Model of the Transport Layer</span>

             TSAP                               TSAP

        Transport Protocol              Transport Protocol
             Entity                           Entity


              NSAP   -------                    NSAP  -------
               |     (NSAP)                      |     (NSAP)
               |       |                         |       |
               |       |-------------------------|--------
               |                                 |
               -----------------------------------

        A Transport Protocol entity within the Transport Layer
communicates with a Transport User through a TSAP by means of the</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 14
International Standards Organization


service primitives as defined by the transport service definition DP
aaaa.  Service primitives will cause or be the result of Transport
Protocol Data Unit exchanges between the peer Transport Protocol
entities supporting a Transport Connection.  These protocol exchanges
are effected using the services of the Network Layer as defined by the
Network Service Definition DP bbbb through one or more NSAPs.

        Transport connection endpoints are identified in end systems
by an internal, implementation dependent, mechanism so that the
Transport User and the Transport Protocol entity can refer to each
Transport connection.

Section Two - Transport Protocol Specification

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.      Protocol Mechanisms</span>

        Several functions are described as 'inherent' or 'pervasive'.
Inherent functions must be invoked for every transport connection.
Pervasive functions are optional, but if one is invoked for the first
transport connection over a network connection, it must also be invoked
for any and all other transport connections which use that network
connection during its lifetime.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>     Assignment to Network Connection</span>

        Purpose:  Assignment of transport connections to network
                  connections.

        Network Service Primitives:

        N-CONNECT
        N-DISCONNECT

        Description:

        This function is inherent.

        Before a transport connection can be created or used, it must
be assigned to one (or more if splitting function is being used)
network connection(s).  Both transport entities involved must become
aware of this assignment.  A transport connection may be assigned to a
suitable existing network connection; one or more new network
connections may also be created for the purpose.

        An existing network connection, which connects the relevant
transport entities, is unsuitable for assignment of a transport
connection if, for example:

        o  the quality of service needed for the transport connection
           can not be met by using or enhancing the network</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 15
International Standards Organization


           connection.

        o  the protocol class preferred or in use for the transport
           connection is incompatible with the current usage of the
           network connection as regards the use of pervasive
           functions (e.g., multiplexing).

        When a new network connection is created, the quality of
service requested is a local matter, though it will normally be
related to the requirements of transport connection(s) expected to be
assigned to it.

        A Network Connection with no transport connections will be
available after initial establishment or because explicit
disconnection of all the transport connections previously assigned to
it has taken place.  Either Transport entity may as a local
matter choose to disconnect the Network Connection or assign other
Transport Connections to it.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>     Transport Protocol Data Unit (TPDU) Transfer</span>

        Purpose:  To convey transport protocol data unit in user
                  data fields of network service primitives.

        Network Service Primitives

        N-DATA
        N-EXPEDITED DATA

        Description:

        This function is inherent.

        The Transport Protocol Data Units (TPDUs) defined for the
protocol are listed in Figure 3.

                TPDU name                Abbreviation

        Connection Request                      CR
        Connection Confirm                      CC
        Disconnect Request                      DR
        Disconnect Confirm                      DC
        Data                                    DT
        Expedited Data                          ED
        Data Acknowledge                        AK
        Expedited Acknowledge                   EA
        Reject                                  RJ
        TPDU Error                              ERR

                Figure 3.  Transport Protocol Data Units</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 16
International Standards Organization


        TPDUs are conveyed using the NS-User data parameters of the
Network Service primitives, primarily with the N-DATA, but also with
N-EXPEDITED primitives.

        Transport entities shall accept all permissible assignments and
may issue any permissible assignments.  The permissible assignments of
TPDUs to these primitives are shown in Figure 4.  Concatenation of
TPDUs is also permitted (see <a href="#section-6.4">section 6.4</a>).

Primitive               Applicable TPDUs                        Note

N-DATA                  CR, CC, DR, DT, ED,
                        AK, EA, RJ, DC, ERR

N-EXPEDITED             ED, EA                                  1

Notes:

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  This assignment is permissible only when using class 1 and when</span>
<span class="h2">    the network expedited variant has been agreed.</span>

Figure 4.  Network Service Primitives which can convey TPDUs.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>     Data TPDU Length and Segmenting</span>

        Purpose:  Mapping between one TSDU and TPDUs.

        TPDUs and fields used:

        DT
        -  End of TSDU (1 bit)

        Description:

        The data field of Data TPDUs may contain any number of octets
up to an agreed maximum as negotiated at connection time.

        A transport entity uses an End of TSDU mark as defined below:

        In each Data TPDU a transport entity may indicate the end of a
TSDU.

        Category 1      Having the End of TSDU mark set to yes.  These
                        TPDUs may or may not have the maximum length.

        Category 2      Having the End of TSDU mark set to no.  These
                        TPDUs do not necessarily have the maximum
                        length.

        A complete Data TPDU sequence is defined as being composed of</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 17
International Standards Organization


either a single category 1 DT TPDU or consecutive category 2 followed
by a category 1 DT TPDU.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>     Concatenation and Separation</span>

        Pupose:  Conveyance of multiple TPDUs in one NSDU.

        Description:

        All TPDUs carry in their TPDU header a length indicator (see
<a href="#section-8.2.1">Section 8.2.1</a>).  Additionally, TPDUs are classified as either Data
TPDUs or Control TPDUs.  Control TPDUs may or may not contain a data
field.  For TPDUs containing data the length of the data field is
indicated by the length of the NSDU.  These provisions permit any
number of Control TPDUs that may not contain data to be concatenated
with a single control TPDU which may contain data or with a single
Data TPDU.  The control TPDUs without data must precede the TPDU with
data, if any.  The number of TPDUs so concatenated is terminated by
the end of the NSDU.

        The concatenated set of TPDUs may be for the same or different
transport connections.  An implementation shall accept concatenated
TPDUs and may concatenate TPDUs before transmission.  The transport
entity shall not send a concatenated set of TPDUs which exceeds twice
the overall maximum TPDU length for all the TCs assigned to the
network connection.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>     Connection Establishment</span>

        Purpose:  Creation of a new transport connection.

        Network Service Primitives:

        N-DATA

        TPDUs and fields used:

        CR, CC
        - source reference (16 bits)
        - initial credit (if applicable)
        - calling transport address (optional)
        - called transport address (optional)
        - user data (optional)
        - TPDU size (optional)
        - sequence number length (optional)
        - checksum selection (optional)
        - acknowledgement time (optional)
        - quality of service (optional)
        CR
        - preferred protocol class</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 18
International Standards Organization


        - alternative protocol classes (zero or more)
        - version number (optional)
        - security (optional)
        - proposed options
        CC
        - destination reference (16 bits)
        - selected protocol class
        - selected options

        Description:

        This function is inherent:

        A transport connection is established by means of one
transport entity (the initiator) transmitting a Connection Request
(CR) TPDU to the other transport entity (the responder), which replies
with a Connection Confirm (CC) TPDU.  Before sending the CR TPDU, the
initiator assigns the transport connection being created to one (or
more if the splitting function is being used) network connection(s).
It is this set of network connections over which the TPDUs are sent.
During this exchange, all information and parameters needed for the
transport entities to operate must be exchanged or negotiated.

        The following information is exchanged:

        o  references.  Each transport entity chooses a reference which
           is 16 bits long and which is arbitrary except for the following
           restrictions:

           - it cannot already be in use or "frozen" (see "Frozen
             References", <a href="#section-6.19">Section 6.19</a>).

           - it cannot be zero.

        Each transport entity is responsible for selecting the
Reference which the partner will use.  This mechanism is symmetrical
and therefore avoids the need to assign a status of master or slave to
partners and avoids call collision.  This mechanism also provides
identification of the transport connection independent of the network
connection. The range of References used for transport connections, in
a given transport entity, is a local system parameter.

        o  addresses (optional).  Indicate the calling and called
           transport service access points.  When either network
           address unambiguously defines the transport address this
           information may be omitted.

        o  initial credit.  Only relevant for classes which include
           the Explicit Flow Control Function.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 19
International Standards Organization


        o  user data.  Not available in class 0.  Up to 32 octets in
           in other classes.

        The following negotiations take place:

        o  protocol class.  The initiator shall propose a preferred
class and any number of alternatives.  (Except that no alternatives are
allowed when class 0 is the preference.)  The initiator should assume
when it sends the CR TPDU that its preferred class will be agreed to,
and commence the functions associated with that class.

        Note:  This means, for example, that when a class which
includes resynchronization (see "Resynchronization", <a href="#section-6.15">Section 6.15</a>) is
preferred, resynchronization will occur if a reset is signalled during
connection establishment.

        When the responder has decided which class is to be used, it
shall indicate this in the CC TPDU and shall invoke the appropriate
functions for the class.  The responder may select the preferred
class, or any of the alternative classes or may select class 0 if
class 1 is proposed or class 2 if class 3 or 4 is proposed. (see
<a href="#section-9">Section 9</a>)

        If the preferred class is not selected, then on receipt of the
CC TPDU, the initiator shall adjust its functions accordingly.

        o  TPDU Size.  The initiator may propose a maximum size for
TPDUs, and the responder may accept this value or respond with any
value between the proposed value and 128 in the set of values
available (see "Encoding", <a href="#section-8">Section 8</a>).

        o  sequence number length.  Either normal or extended is
available.  When the sequence number is extended, the credit field (if
applicable) is also extended.

        o  checksum selection.  This defines whether or not TPDUs of
the connection are to include a checksum.

        o  version number.  This defines the version of the transport
protocol standard used for this connection.

        o  security parameter.  This parameter and its semantics are
user defined.

        o  quality of service parameter.  This defines the throughput,
delay, priority and residual error rate.

        o  The non-use of explicit flow control in class 2 is
negotiated.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 20
International Standards Organization


        o  The use of Network Receipt Confirmation and Network
expedited is negotiated when class 1 is to be used.

        The negotiation rules for the options are such that the
initiator may propose either to use or not to use the option.  The
responder may either accept the proposed choice or select the
mandatory alternative defined in <a href="#section-9">Section 9</a>.

        During the establishment phase of the transport connection,
the use of the expedited data option field of CR/CC  allows both
Transport Service user to negotiate the use or non use of the
expedited data transport service as described in the transport service
definitions.

        The following table summarizes the negotiation possibilities
for the options.

                                Proposition Made        Possible
                                by the Initiator        Selection by
        Option                                          the Responder

Transport expedited data             Yes                  Yes or No
transfer service                     No                       No

Use of receipt confir-               Yes                  Yes or No
mation (class 1 only)                No                       No

Use of the network                   Yes                  Yes or No
expedited variant                    No                       No
(class 1 only)

Non use of checksum                  Yes                  Yes or No
(class 4 only)                       No                       No

Non use of explicit                  Yes                  Yes or No
flow control (class 2 only)          No                       No

Use of extended format               Yes                  Yes or No
                                     No                       No

        In class 2, whenever a transport entity requests or agrees to
the Transport Expedited data transfer service or to the use of
extended formats, it must also request or agree (respectively) to the
use of explicit flow control.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>     Connection Refusal</span>

        Purpose:        Refusal of the transport connection.

        TPDUs and fields used:</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 21
International Standards Organization


        DR
        -  reason (1 octet)
        -  user data (maximum of 64 octets)

        ERR
        -  reject code (1 octet)
        -  rejected TPDU parameter

        Description:

        If a transport connection cannot be accepted, the called
transport entity shall respond to the CR TPDU with a DR TPDU.  The
clearing reason shall indicate why the connection was not accepted.
The source reference field in the DR TPDU is set to zero to indicate
an unassigned reference.

        If the CR is regarded as an invalid TPDU, the called transport
entity will respond by sending an ERR TPDU.  On receipt of this TPDU,
the calling entity will regard the connection as closed.

<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>     Release</span>

        Variants:  'implicit' or 'explicit'

        Purpose:  Termination of the transport connection.

        Network Service Primitives:

        N-DISCONNECT (implicit variant only)
        N-DATA

        TPDUs and fields used:

        DR
        - clearing reason (1 octet)
        - user data (maximum of 64 octets)

        DC

        Description:

        This function is inherent.

        In the 'implicit' variant, either transport entity disconnects
a transport connection by disconnecting the network connection to
which it is assigned.  Similarly when a transport entity is informed
that the network connection has been disconnected by the peer
transport entity, this should be considered as a transport
disconnect.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 22
International Standards Organization


        In the 'explicit' variant, either transport entity transmits a
Disconnect Request (DR) TPDU, and the other responds with a Disconnect
Confirm (DC) TPDU.  When the DC TPDU is sent or received by a
transport entity, that entity should consider the transport connection
not to exist (note 1).  After the sending of a DR TPDU, other TPDUs
received before the DC TPDU are ignored.  It is possible that a
disconnect collision will occur, when both transport entities send a
DR TPDU at about the same time.  This results in each transport entity
receiving a DR, after sending one.  Each transport entity shall
consider the received DR TPDU as a confirmation of its DR TPDU, and
shall not send or expect to receive a DC TPDU.

        The DR can convey a limited amount (up to 64 octets) of data.

<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>     Implicit Termination</span>

        Purpose:  Termination of a Transport Connection on the
occurrence of a signalled error for which recovery functions are not
operative.

        Network Service Primitives:

        N-DISCONNECT Indication
        N-RESET Indication

        Description:

        When, on the network connection to which a Transport
Connection is assigned, an N-DISCONNECT or N-RESET Indication occurs,
both transport entities shall consider that the transport connection
no longer exists, and so inform the session entities.

Note 1:

        When a connection has been released, after the exchange of DR
and DC, the reference can be re-used immediately (except in Class 4,
where the Frozen Reference function is used, see <a href="#section-6.19">Section 6.19</a>).  This
is because the releasing transport entity does not know with certainty
that the remote transport entity considers use of the reference to be
ended.  Therefore, the reference should not be re-used for further
connections.  (In practice, the reference may be re-used after a
reasonable period when it is possible to be reasonably certain that
the remote transport entity will not continue to use it).

<span class="h3"><a class="selflink" id="section-6.9" href="#section-6.9">6.9</a>     Spurious Disconnect</span>

        Purpose:  To deal with the arrival of an "unknown" DR TPDU.

        TPDUs and fields used:
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 23
International Standards Organization


        DR, DC
        - source reference
        - destination reference

        Description:

        A DR TPDU can be received for a transport connection which
does not exist.  Rather than treating this as an error, a DC TPDU
should be send back which reflects the references of the DR TPDU.

Note:
        This only applies when one or more transport connections using
a multiplexing class exist over the network connection, or when no
transport connections exist.  At other times it is a protocol error.

<span class="h3"><a class="selflink" id="section-6.10" href="#section-6.10">6.10</a>    Data TPDU Numbering</span>

        Variants:  'normal' or 'extended'

        Purpose:   Numbering of DT TPDUs for use in recovery,
                   flow control, or sequencing functions.

        TPDUs and Fields Used:

        DT
        - TPDU-NR (7 or 31 bits)

        Description:

        DT TPDUs transmitted in each direction on a transport
connection bear a sequence number 'TPDU-NR'.  Its value in the first
DT TPDU in each direction after connection establishment will be zero.
Thereafter each TPDU had 'TPDU-NR' one greater than the previous.
Modulo 2**7 arithmetic is used in the 'normal' variant, and modulo 2**31
in the 'extended' variant.

        In the sections that follow, the relationships 'greater than'
and 'less than' are used in connection with TPDU numbers.  In all
such uses, the numbers being compared cover a range less than the
modulus and in fact lie within a contiguous set of TPDU numbers called
a 'window'.  The window has a known starting TPDU number and finishing
number.  The term 'less than' means 'occurring sooner in the window
sequence' and the term 'greater than' means 'occurring later in the
window sequence'.

<span class="h3"><a class="selflink" id="section-6.11" href="#section-6.11">6.11</a>    Expedited Data Transfer</span>

        Variants:  'network expedited' or not

        Purpose:  Provision of the expedited data service</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 24
International Standards Organization


        Network Service Primitives:

        N-DATA
        N-EXPEDITED DATA

        TPDUs and Fields Used:

        ED
        - ED TPDU-NR (7 or 31 bits)

        EA
        - YR-TU-NR (7 or 31 bits)

        Description:

        Each expedited TSDU is conveyed as the data field of an Expedited
Data (ED) TPDU.

        Each ED TPDU received must be acknowledged by an Expedited
Acknowledge (EA) TPDU.

        There may only be one ED TPDU unacknowledged at any time for each
direction of a transport connection.

        In the 'network expedited' variant (available in class 1 only),
ED and EA TPDUs are conveyed in the data fields of N-EXPEDITED DATA
primitives.  Otherwise, N-DATA is used.

<span class="h3"><a class="selflink" id="section-6.12" href="#section-6.12">6.12</a>    Reassignment</span>

        Purpose:  Assignment of a Transport Connection to a different
Network Connection.

        TPDUs and Fields Used:

        CR
        - source reference

        RJ, DR
        - destination reference

        Description:

        When the Network Connection to which a Transport Connection was
assigned no longer exists, the Transport Connection can be assigned to
another Network Connection.

        When one transport entity has assigned the Transport Connection,
it is important that the other transport entity recognise to which
Network Connection it has been assigned.  This can only take place when it</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 25
International Standards Organization


has received a TPDU for the Transport Connection on a Network Connection
with calling and called network addresses which imply
the same transport entities as the old.  The TPDU will have been sent
as a result of the assigning transport entity commencing resynchronization,
and will thus be a RJ, or a retransmitted CR or DR.

        The Transport Connection shall be recognised as having been
assigned to the Network Connection on which the TPDU was received.

<span class="h3"><a class="selflink" id="section-6.13" href="#section-6.13">6.13</a>    Reassignment After Failure</span>

        Purpose:  Recovery from network provider initiated disconnect.

        Network Service Primitives:

        N-DISCONNECT Indication

        Description:

        When a N-DISCONNECT Indication arrives for the network connection
to which a transport connection is assigned, the transport connection must
be reassigned by its initiator (see "Reassignment")

        If the reassignment has not successfully occurred within a time
of T-wait seconds, then the transport connection must be considered as
non-existent by both transport entities.1

        1.      The CR TPDU does not have a destination reference;
                nevertheless it can be distinguished from a new
                connection attempt by having the same source
                reference.

        NOTE:  The value of T-wait has to be agreed by the communicating
transport entities.

<span class="h3"><a class="selflink" id="section-6.14" href="#section-6.14">6.14</a>    Retention Until Acknowledgement of TPDUs</span>

        Variants:  'confirmation of receipt' or 'AK'

        Purpose:  To enable and minimize retransmission after
possible loss of TPDUs.

        Network Service Primitives:

        N-DATA
        N-DATA ACKNOWLEDGE

        TPDUs and Fields Used:

        CR, CC, DR, DC</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 26
International Standards Organization


        RJ, AK, EA
        - YR-TU-NR (7 or 31 bits)

        DT
        - TPDU-NR (7 or 31 bits)

        ED
        - ED TPDU-NR (7 or 31 bits)

        Description:

        Copies of the following TPDUs shall be retained upon transmission
to permit their later retransmission:

                CR, CC, DR, DT, ED.

        NOTE:  If DR is sent in response to CR there is no need to
retain a copy of the DR.

        In the 'confirmation of receipt' variant, applicable only
in Class 1, transport entities receiving N-DATA Indications which
convey DT TPDUs and have the confirmation request field set shall
issue a N-DATA Acknowledge Request at the earliest possible
opportunity (1).

        (1)     It is a local matter for each transport entity to
                decide which N-DATA Requests should have the
                confirmation request parameter set.  This decision
                will normally be related to the amount of storage
                available for retained copies of the DT TPDUs.
                Use of the confirmation request parameter may
                affect the quality of network service.

        After each TPDU is acknowledged, as shown in Figure 5,
the copy need not be retained.  Copies may also be discarded when
the transport connection ceases to exist.

        TPDU                            ACKNOWLEDGED BY

        CR              receipt of CC, DR, or ERR, TPDU

        DR              receipt of DC or DR (in case of collision)
                        TPDU

        CC              receipt of RJ, DT, AK, ED, EA TPDUs (or
                        N-DATA ACKNOWLEDGE Indication.)

        DT              N-DATA ACKNOWLEDGE Indication when the
        (Note 1)        DT TPDU was sent before or with the oldest
                        N-DATA which had the confirmation request</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 27
International Standards Organization


                        field set.

        DT              receipt of Data Acknowledge (AK) or
        (Note 2)        Reject (RJ) TPDU for which 'YR-TU-NR'
                        is greater than 'TPDU-NR' in the DT TPDU.

        ED              receipt of EA TPDU for which 'YR-TU-NR'
                        is equal to 'ED-TPDU-NR' in the ED TPDU.        Notes:


        1.      Applies to 'confirmation of receipt' variant.
        2.      Applies to 'AK' variant.

                Figure 5.  Acknowledgement of TPDUs

<span class="h3"><a class="selflink" id="section-6.15" href="#section-6.15">6.15</a>    Resynchronization</span>

        Purpose:  To restore the connection to normal after an
error.

        Network Service Primitives:

        N-RESET Indication

        TPDUs and Fields Used:

        CR, DR, CC, DC

        RJ, EA
        - YR-TU-NR (7 or 31 bits)

        DT
        - TPDU-NR (7 or 31 bits)

        ED
        - ED TPDU-NR (7 or 31 bits)

        Description:

        After the reset of an underlying network connection,
the resynchronization procedures below are carried out by both
transport entities.

        After a network connection failure, the reassignment after
failure function is invoked and then the resynchronization function.
The sequence of events at the two transport entities is the following:

        Events at the transport entity initiating reassignment:
        (the transport entity immediately commences resynchronization
         by sending a TPDU)</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 28
International Standards Organization


        o       if a CR is retained then retransmit it.

        o       if a DR is retained then retransmit it.

        o       otherwise, resynchronize data:

                -       send RJ TPDU with 'YR-TU-NR' field set to
                        the 'TPDU-NR' of the first unreceived DT
                        TPDU

                -       when RJ TPDU has been received retransmit any
                        ED TPDUs then DT TPDUs which are unacknowledged

                -       any ED TPDUs received which are duplicates shall
                        be acknowledged (by EA TPDUs) and discarded.

        Events at the other transport entity:

        The transport entity shall not send any TPDUs until after
receipt of the TPDU which commenced resynchronization.  This TPDU
therefore serves two purposes, namely indication of re-assignment
and commencement of resynchronization.

        o       if the first received TPDU os a DR, then transmit
                a DC TPDU.

        o       if the first received TPDU is a CR and the transport
                connection is not idle, this means that a CC TPDU is
                retained:  then retransmit it followed by any ED TPDU
                and then DT TPDUs which are outstanding (that may or
                may not have been transmitted previously).

        NOTE:  no TPDUs can be transmitted using network expedited until
CC becomes acknowledged, to prevent the network expedited overtaking the
CC.

        o       if the first received TPDU is a RJ, then act as follows:

                -       if a DR TPDU is retained, then retransmit it

                -       if a CC TPDU remains unacknowledged, then carry
                        out the data resynchronization procedure described
                        below

                -       otherwise resynchronize data:

                        -       send RJ TPDU with 'YR-TU-NR' field set to
                                the 'TPDU-NR' of the first unreceived DT
                                TPDU
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 29
International Standards Organization


                        -       retransmit any ED TPDUs then DT TPDUs which
                                are unacknowledged

                        -       any ED TPDUs received which are duplicates
                                should be acknowledged (by EA TPDUs) and
                                discarded.

        NOTE:  It is possible for a transport entity using the Class 1
protocol to decide on a local basis to issue an N-RESET Request.  The effect
of this request at the remote transport entity is to force it to perform
the resynchronization mechanism.  This possibility may be used to remove
congestion within the network connection.

<span class="h3"><a class="selflink" id="section-6.16" href="#section-6.16">6.16</a>    Multiplexing and Demultiplexing</span>

        Purpose:  Concurrent sharing of a network connection by several
transport connections.

        TPDUs and Fields Used:

        CC, DR, DC, DT, AK, ED, EA, RJ, ERR
        - destination reference

        Description:

        This function is pervasive.

        When this function is in operation, more than one transport
connection can be simultaneously assigned to the same network connection.

        Every TPDU (including DT TPDUs) must carry the destination
reference, to identify the transport connection to which it refers.

<span class="h3"><a class="selflink" id="section-6.17" href="#section-6.17">6.17</a>    Explicit Flow Control</span>

        Purpose:  Regulation of flow of DT TPDUs independently of
the flow control in the other layers.

        TPDUs and Fields Used:

        CR, CC, AK, RJ
        - CDT (4 or 16 bits)

        DT
        - TPDU-NR (7 or 31 bits)

        AK, RJ
        - YR-TU-NR (7 or 31 bits)
        - subsequence number (optional)
        - flow control confirmation (optional)</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 30
International Standards Organization


        Description:

        The mechanism depends on the class.  Thus the description can
be found in the section describing the class.

<span class="h3"><a class="selflink" id="section-6.18" href="#section-6.18">6.18</a>    Checksum</span>

        Purpose:  To detect corruption of TPDUs by the network service
provider.

        TPDUs and Fields Used:

        All TPDUs
        - checksum (16 bits - 32 bits)

        Description:

        When a TPDU is to be transmited for a TC which has selected the
checksum option, the sending transport entity must generate a checksum
for the TPDU and store it in the checksum parameter in the variable
part of the TPDU header.  The checksum must be generated as follows:

        1.      Set up the complete TPDU, including the header and
user data (if any).  The header must include the checksum parameter in
its variable part.  The value field of the checksum parameter must be
set to zero at this point.

        2.      Initialize two variables to zero.  Let these variables
be called C0 and C1.

        3.      For each octet of the TPDU, including the header,
variable part of the header and the user data, add the octet value to
C0, and then add the value of C0 to C1.  Octets should be processed
sequentially, starting with the first octet (the Length Indicator) and
proceeding through the TPDU.  All addition is to be performed modulo 255.

        4.      Calculate the value field of the checksum parameter as
follows.  Let the offset into the TPDU of the first octet of the value
field be 'n' (where the first octet of the TPDU, the Length Indicator
of the header, is considered to be at offset 1).  Let the length
of the TPDU, i.e. the number of times the above operation was repeated,
be 'L'.  Let the first octet of the checksum value, i.e., the one at offset
'n' be called 'X', and the second octet, at offset 'n+1', be called 'Y'.
Then:

        X = (((L - n) *  C0) - C1) modulo 255
        Y = (((L - n + 1) * (-C0)) + C1) modulo 255

        5.      Place the computed values of X and Y in the appropriate
octets of the TPDU.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 31
International Standards Organization


                                NOTE

        An implementation may use one's complete arithmetic as an
        alternative to modulo 255 arithmetic.  However, if either
        of the checksum octets X and Y has the value minus zero
        (i.e., 255) then it must be converted to plus zero
        (i.e., 0) before being stored.

        When a TPDU is received for a TC for which the checksum option
has been selected, the TPDU must be verified to ensure that it has been
received correctly.  This is done by computing the checksum, using the
same algorithm by which it was generated.  The nature of the checksum
algorithm is such that it is not necessary to compare explicitly the stored
checksum bytes.  The procedure described below may be used to verify that
a TPDU has been correctly received.

        1.      Initialize two variable to zero.  Let these variables
be called C0 and C1.

        2.      For each octet in the received TPDU, add the value of
the octet to C0 and then add the value of C0 to C1, starting with the
first octet and proceeding sequentially through the TPDU.  All
addition is to be performed modulo 255.

        3.      When all octets have been sequentially processed, the
values of C0 and C1 should be zero.  If either or both of them is
non-zero, the TPDU has been received incorrectly and the verification
has failed.  Otherwise, the TPDU has been received correctly and the
TPDU should be processed normally.

                                NOTE

        An implementation may use one's complement arithmetic as an
        alternative to modulo 255 arithmetic.  In this case, if either
        C0 or C1 has the value minus zero (i.e., 255) it is to be
        regarded as though it was plus zero (i.e., 0)

        If a checksum verification failure occurs, it is not possible
to determine the TC that the TPDU relates to, since the Reference field
of the TPDU may have been received incorrectly.  Therefore, all TCs
multiplexed onto the same NC must be treated as though a network signalled
error has occurred.

<span class="h3"><a class="selflink" id="section-6.19" href="#section-6.19">6.19</a>    Frozen References</span>

        Purpose:  To prevent re-use of a reference while TPDUs associated
with the old use of the reference may still exist.

        Description:  When a transport entity determines that a particular
connection has terminated, the reference shall be placed in a frozen state</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 32
International Standards Organization


during which time it will not be reused.  The circumstances under which
this is done, and the period of time for which the reference remains
frozen depends on the class.

<span class="h3"><a class="selflink" id="section-6.20" href="#section-6.20">6.20</a>    Retransmission on Timeout</span>

        Purpose:  To cope with unsignalled loss of TPDUs by the network
service provider.

        TPDUs and Fields Used:

        CR, CC, DR, DT, ED, AK

        Description:

        The description is given in the section related to class 4.

<span class="h3"><a class="selflink" id="section-6.21" href="#section-6.21">6.21</a>    Resequencing</span>

        Purpose:  To cope with misordering of TPDUs by the network
service provider.

        TPDUs and Field Used:

        DT
        - TPDU NR

        ED
        - ED TPDU NR

        Description:

        The description is given in the section related to class 4.

<span class="h3"><a class="selflink" id="section-6.22" href="#section-6.22">6.22</a>    Inactivity Control</span>

        Purpose:  To cope with unsignalled termination of a network
connection.

        TPDUs and Fields Used:

        AK

        Description:

        The description is given in the section related to class 4.

<span class="h3"><a class="selflink" id="section-6.23" href="#section-6.23">6.23</a>    Treatment of Protocol Errors</span>

        Purpose:  To deal with invalid TPDUs.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 33
International Standards Organization


        TPDUs and Fields Used:

        ERR
        - reject cause
        - TPDU in error (string of octets)

        DR
        - reason code

        Description:

        This function is inherent.

        Any received TPDU which is invalid or which cannot be dealt with by
any operative function, or which is regarded as a violation of the protocol
rules of the class in use (e.g., receipt in a wrong state, window error,
sequencing error, TPDU with incorrect format), shall be considered as a
protocol error.  Such an error shall be signalled to the transport entity
responsible by the sending of an TPDU Error (ERR) TPDU or by initiating a
release.  The ERR TPDU conveys the octets of the offending TPDU up to
and including the octet where the error was detected.

        In general, no further action is defined for the sender of
ERR TPDU, since it is expected that the offender will either correct
the error, or close the connection.

        Action to be done by the receiver depends on local implementation
decision; e.g., freeze the connection, report to management, disconnect.

NOTES:

        1.      Further action is a local implementation issue.  Care
should be taken by the transport entity receiving several invalid TPDUs
or ERR TPDUs to avoid looping if the error is repeatedly generated.

        2.      There are two cases in which specific action is defined
for the receiver of the ERR TPDU (see Sections <a href="#section-6.6">6.6</a> and <a href="#section-7.0.7">7.0.7</a>).

<span class="h3"><a class="selflink" id="section-6.24" href="#section-6.24">6.24</a>    Splitting and Recombining</span>

        Purpose:  To allow a transport connection to make use of
multiple network connections to provide additional resilience against
network failure, to increase throughput, or for other reasons.

        Description:

        This function is available only in Class 4.

        When this function is being used, a transport connection is
assigned (see <a href="#section-6.1">Section 6.1</a>) to multiple network connections. TPDUs for the</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 34
International Standards Organization


connection may be sent over any assigned network connection.  The
resequencing function of Class 4 (see <a href="#section-6.21">Section 6.21</a>) is used to ensure
that TPDUs are processed in the correct sequence.

        If the use of Class 4 is not accepted by the remote transport
entity following the negotiation rules, only the network connection
over which the CR TPDU was sent may be used for this transport
connection.

        The splitting function should only be used where the
supporting network connections provide similar transmit delay.

   Protocol Mechanism           Variant         0  1  2  3  4

Assignment to Network Conn.                     *  *  *  *  *

TPDU Transfer                                   *  *  *  *  *

DT TPDU Length and Segmenting                   *  *  *  *  *

Concatenation and Separation                       *  *  *  *

Connection Establishment                        *  *  *  *  *

Connection Refusal                              *  *  *  *  *

Release                         implicit        *
                                explicit           *  *  *  *

Implicit Termination                            *     *

DT TPDU Numbering               normal             *  m  m  m
                                extended            (1)o o  o

Expedited Data Transfer         network exp.      ao
                                not "              m  *  *  *
                                                     (1)

Reassigment                                        *     *

Reassignment after Failure                         *     *

Retention until Acknowledge-    Conf. Receipt     ao
ment of TPDUs                   AK                 m     *  *

Resynchronization                                  *     *

Multiplexing and                                      *  *  *
Demultiplexing
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 35
International Standards Organization


Explicit Flow Control With                            m  *  *
                      Without                   *  *  o

Checksum   (use of)                                         m
           (non-use of)                         *  *  *  *  o

Frozen References                                           *

Retransmission on Timeout                                   *

Resequencing                                                *

Inactivity Control                                          *

Treatment of Protocol Errors                    *  *  *  *  *

Splitting and recombining                                   *

(1)  not applicable in class 2 when the non use of explicit flow
control is selected.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.      PROTOCOL CLASSES</span>

        The details of the implementation of the protocol
mechanisms are in certain cases different for different classes.
For this reason, the following table is not intended to provide a
complete description of the classes, but more to give an overview of
how each class works.  The exact definition of the protocol is given
in the subsequent sections.

                            KEY

        *  include in the class (always)

        m  mandatory function (negotiable but always implemented)

        o  additional function (negotiable but not necessarily implemented)

        ao additional function (negotiable but not necessarily implemented).
             Use of this option depends on the willingness of both transport
             entities and availability of network service.

        na not applicable.

<span class="h3"><a class="selflink" id="section-7.0" href="#section-7.0">7.0</a>     PROTOCOL DESCRIPTION OF CLASS 0: SIMPLE CLASS</span>

<span class="h4"><a class="selflink" id="section-7.0.1" href="#section-7.0.1">7.0.1</a>   Characteristics of Class 0</span>

        The characteristic of this class is that it provides
the simplest type of transport connection and fully compatible</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 36
International Standards Organization


with the CCITT recommendations S.70 for Teletex terminals.

        The class is designed for use in association with
network connections of type A (see 5.3.1.2.4.).

<span class="h4"><a class="selflink" id="section-7.0.2" href="#section-7.0.2">7.0.2</a>   Functions of Class 0</span>

        This class is designed to have minimum functionality.
It provides only the functions needed for connection
establishment with negotiation, data transfer with segmenting and
protocol error reporting.

        Class 0 provides transport connections with flow
control based on the network service provided flow control, and
disconnection based on the network service disconnection.

<span class="h4"><a class="selflink" id="section-7.0.3" href="#section-7.0.3">7.0.3</a>   Protocol Mechanisms of Class 0</span>

<span class="h5"><a class="selflink" id="section-7.0.3.1" href="#section-7.0.3.1">7.0.3.1</a>  Connection Establishment Phase</span>

        Connection shall be made in accordance with the
general rules (Assignment of Network Connection, Connection
Establishment and Connection Refusal) with the following
restrictions:

        o  No exchange of user data is allowed.

        o  Only TSAP-ID and TPDU size parameters are allowed.

<span class="h5"><a class="selflink" id="section-7.0.3.2" href="#section-7.0.3.2">7.0.3.2</a>  Data Transfer Phase</span>

        o  Segmenting  (DT TDPU length and Segmenting)

        o  Detection and indication of procedural errors.

<span class="h5"><a class="selflink" id="section-7.0.3.3" href="#section-7.0.3.3">7.0.3.3</a>  Release Phase</span>

        There is no explicit transport connection release
procedure for this class.  The lifetime of the transport connection
is directly correlated to the lifetime of the network connection.

<span class="h4"><a class="selflink" id="section-7.0.4" href="#section-7.0.4">7.0.4</a>   Connection Establishment for Class 0</span>

        The connection establishment function is used
with the contraint that only the transport entity which has
requested the establishment of the network connection may send the
CR TPDU.  If the calling transport entity receives a CR TPDU, it
shall transfer a TPDU Error (ERR) TPDU to notify the called
transport entity of the procedure error.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 37
International Standards Organization


<span class="h4"><a class="selflink" id="section-7.0.5" href="#section-7.0.5">7.0.5</a>   Data Transfer Procedures</span>

<span class="h5"><a class="selflink" id="section-7.0.5.1" href="#section-7.0.5.1">7.0.5.1</a>  General</span>

        The data transfer procedures described in the
following subsections apply only when the transport layer is in the
data transfer phase, that is after completion of Transport
Connection establishment.

<span class="h5"><a class="selflink" id="section-7.0.5.2" href="#section-7.0.5.2">7.0.5.2</a>  Transport Data TPDU maximum length</span>

        For Class 0 the standard maximum transport data
TPDU length is 128 octets including the data TPDU header octets.

        Other maximum TPDU lengths may be supported in
conjunction with the optional transport data TPDU size negotiation
function (see <a href="#section-8.3">Section 8.3</a> and 8.4).  Optional maximum data field
lengths shall be chosen from the following list:  256, 512, 1024
and 2048 octets.

        TSDUs are transmitted using the segmenting function.

<span class="h4"><a class="selflink" id="section-7.0.6" href="#section-7.0.6">7.0.6</a>   Release  </span>Procedure

        The "implicit" variant of the release function is used.

<span class="h4"><a class="selflink" id="section-7.0.7" href="#section-7.0.7">7.0.7</a>   Treatment of invalid TPDUs</span>

        The "treatment of protocol errors' function is used.

<span class="h4"><a class="selflink" id="section-7.0.8" href="#section-7.0.8">7.0.8</a>   Behaviour after an error signalled by the network service.</span>

        The implicit termination function is used and the
high layer is informed about this disconnection.

<span class="h4"><a class="selflink" id="section-7.0.9" href="#section-7.0.9">7.0.9</a>   Supported Options</span>

        None

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>     PROTOCOL DESCRIPTION OF CLASS 1:  </span>BASIC ERROR RECOVERY CLASS

<span class="h4"><a class="selflink" id="section-7.1.1" href="#section-7.1.1">7.1.1</a>   Characteristics of Class 1</span>

        The characteristic of this class is that it
provides a basic transport connection with minimal overheads.

        The main purpose of the class if to recover from
network signalled errors (network disconnect or reset).

        Selection of this class is usually based on</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 38
International Standards Organization


reliability criteria.  Class 1 has been designed to be used in
association with type B network connections.

<span class="h4"><a class="selflink" id="section-7.1.2" href="#section-7.1.2">7.1.2</a>   Functions of Class 1</span>

        Class 1 provides transport connections with flow
control based on the network service provided flow control, error
recovery, expedited data transfer, disconnection, and also the
ability to support consecutive Transport connections on a network
connection.

        This class provides the functionality of Class 0
plus the ability to recover after a failure signalled by the Network
Service, without involving the user of the Transport Service.

<span class="h4"><a class="selflink" id="section-7.1.3" href="#section-7.1.3">7.1.3</a>   Protocol Mechanisms of Class 1</span>

        Class 1 protocol mechanisms include Class 0
protocol mechanisms plus the following:

<span class="h5"><a class="selflink" id="section-7.1.3.1" href="#section-7.1.3.1">7.1.3.1</a>  User Data in the Connection Phase</span>

        Class 1 provides the possibility of conveying
data in the connection request and confirm commands.

<span class="h5"><a class="selflink" id="section-7.1.3.2" href="#section-7.1.3.2">7.1.3.2</a>  Numbering of Data TPDU</span>

        Each Data TPDU transmitted between transport entities for
each direction of transmission in a transport connection is
sequentially numbered.

<span class="h5"><a class="selflink" id="section-7.1.3.3" href="#section-7.1.3.3">7.1.3.3</a>  Release</span>

        The "explicit" variant of the release function is used.

<span class="h5"><a class="selflink" id="section-7.1.3.4" href="#section-7.1.3.4">7.1.3.4</a>  Error Recovery</span>

        The sending Transport entity keeps a copy of transmitted
TPDUs until it receives an acknowledgment which allows copies to be released.
After a failure is indicated by the nerwork service (Reset,
Disconnect), the resynchronization function is used to determine
which TPDUs must be retransmitted.

        Resynchronization may also be invoked by a transport entity
as a local matter.  For that purpose the Resynchronization function is
used (see note at the end of <a href="#section-6.15">Section 6.15</a>).

<span class="h5"><a class="selflink" id="section-7.1.3.5" href="#section-7.1.3.5">7.1.3.5</a>  Acknowledgement</span>

        Acknowledgements are used to release copies of retained TPDUs.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 39
International Standards Organization


Two methods of acknowledgment are provided in the Retention until
Acknowledgement of TPDUs function:

        o  use of AK TPDU ("AK" variant) - mandatory

           Note:  The credit field of the AK TPDU is
           not used in this class (always Set to zero).

        o  use of network layer Confirmation of Receipt Service.
           ('confirmation of receipt' variant) - optional

        The variant to be used is negotiated during the
Connection Establishment Phase.  The default option is the "AK TPDU"
variant.  Use of Network Layer Receipt Confirmation is allowed only
in Class 1, and depends on the availability of the network layer
receipt confirmation service, the expected cost reduction, and the
agreement of both transport entities to use it.

<span class="h4"><a class="selflink" id="section-7.1.4" href="#section-7.1.4">7.1.4</a>   Connection Establishment Procedures for Class 1</span>

        The 'assignment to network connection' and
'connection establishment' mechanisms are used.  From the point at
which a transport entity issues a CR proposing the use of Class 1 or
a CC accepting the use of Class 1  the following mechanisms must be
available to deal with signalled errors during connection
establishment:

        o  Reassignment after failure
        o  Retention until Acknowledgement of TPDUs
        o  Resynchronization

        If no DT or ED TPDU is to be sent, receipt of a CC should be
acknowledged.

<span class="h4"><a class="selflink" id="section-7.1.5" href="#section-7.1.5">7.1.5</a>   Data Transfer Phase</span>

        Data transfer is accomplished using the 'TPDU
transfer' 'Concatenation' and 'DT TPDU Length and Segmenting'
mechanisms.  'DT TPDU Numbering' and 'Retention until
Acknowledgement of TPDUs' are used in support of error recovery.

<span class="h5"><a class="selflink" id="section-7.1.5.1" href="#section-7.1.5.1">7.1.5.1</a>  Behaviour after an error</span>

        After receiving a network reset, the Resynchronization
mechanism is invoked.  After receiving a network disconnect, the
'Reassignment after Failure' mechanism is invoked after which the
'Resynchronization' mechanism is invoked.

        The 'Spurious Disconnect' mechanism is used to
deal with receipt of a DR TPDU for an unrecognised Transport</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 40
International Standards Organization


Connection.

<span class="h5"><a class="selflink" id="section-7.1.5.2" href="#section-7.1.5.2">7.1.5.2</a>  Procedure for Expedited Data Transfer</span>

        The Expedited Data Transfer mechanism is used.
Two methods are possible to provide the function:

        o  non network expedited variant

           Note: (1) This method is always included in this class.

           Note: (2) The EDTPDU-NR of the ED TPDU contains an
identification number.  This number must be different for successive ED TPDUs.
That is, when an ED TPDU has been sent and an EA TPDU for the ED
TPDU has been received, the next ED TPDU must have a different value
in the EDTPDU-NR field.  No other significance is attached to
EDTPDU-NR field.  It is recommended but not essential, that the
values used be consecutive modulo 128.

        o  network expedited variant

           Note: (1) The use of this method is
determined through negotiation during transport connection
establishment.

<span class="h4"><a class="selflink" id="section-7.1.6" href="#section-7.1.6">7.1.6</a>   Release Procedures</span>

        The 'explicit' variant of the Release mechanism is used.

        Receipt of an error indication by a transport
entity, which, prior to this event has sent a DR, causes this
transport entity to retransmit DR.  Only DC and DR will be accepted
and interpreted as the completion of the connection release
sequence.  The related Reference will become unassigned.

<span class="h4"><a class="selflink" id="section-7.1.7" href="#section-7.1.7">7.1.7</a>   Treatment of Unknown TPDUs</span>

        The 'Treatment of Protocol Errors' mechanism is used.

<span class="h4"><a class="selflink" id="section-7.1.8" href="#section-7.1.8">7.1.8</a>   Supported Options</span>

        Use of network receipt confirmation.

        Use of network expedited.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>     PROTOCOL DESCRIPTION OF CLASS 2: MULTIPLEXING CLASS</span>

<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>   Characteristics of Class 2</span>

        The characteristic of this class is to provide a</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 41
International Standards Organization


way to multiplex several transport connections onto a single network
connection.  This class has been designed to be used in association
with type A network connections.

        Use of Explicit Flow Control

        The objective is to provide flow control to help
avoid congestion at end-points and on the network connection.
Typical use is when traffic is heavy and continuous, or when there
is intensive multiplexing.  Use of flow control can optimize
response times and resource utilization.

        Non Use of Explicit Flow Control (optional)

        The objective is to provide a basic transport
connection with minimal overheads suitable when independence of
transport and network connection lifetime is desirable.  The class
would typically be used for unsophisticated terminals, and when no
multiplexing onto network connections is required.  Expedited data
is never available.

<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>   Functions of Class 2</span>

        Class 2 provides transport connections with or
without individual flow control - no error detection or error
recovery is provided.

        If the network resets or clears, the transport
connection is terminated without the transport clearing sequence
and the transport user is informed.

        When explicit flow control is used a credit
mechanism is defined allowing the receiver to inform the sender of
the exact amount of data he is willing to receive and expedited data
transfer is available.

<span class="h4"><a class="selflink" id="section-7.2.3" href="#section-7.2.3">7.2.3</a>   Protocol Mechanisms of Class 2</span>

<span class="h5"><a class="selflink" id="section-7.2.3.1" href="#section-7.2.3.1">7.2.3.1</a>  Connection Establishment Phase</span>

        The connection establishment function shall be used.

<span class="h6"><a class="selflink" id="section-7.2.3.1.1" href="#section-7.2.3.1.1">7.2.3.1.1</a>  User Data in the Connection Phase</span>

        Class 2 provides the possibility to convey data in the
connection request and confirm commands.

<span class="h5"><a class="selflink" id="section-7.2.3.2" href="#section-7.2.3.2">7.2.3.2</a>  Connection Identification</span>

        In Class 2 each TPDU conveys a Destination Reference.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 42
International Standards Organization


This uniquely identifies the transport connection within the
receiving transport entity and thus allows multiplexing.

<span class="h5"><a class="selflink" id="section-7.2.3.3" href="#section-7.2.3.3">7.2.3.3</a>  Release Phase</span>

        The release of a transport connection results either
from the use of the 'explicit' variant of the release function or
from the Implicit Termination function.

<span class="h5"><a class="selflink" id="section-7.2.3.4" href="#section-7.2.3.4">7.2.3.4</a>  Protocol Mechanisms when Explicit Flow Control is used.</span>

        The following mechanisms are provided:

<span class="h6"><a class="selflink" id="section-7.2.3.4.1" href="#section-7.2.3.4.1">7.2.3.4.1</a>  Numbering of Data TPDU</span>

        Each Data TPDU transmitted between transport entities
for each direction of transmission in a transport connection is
sequentially numbered.

        Each Data TPDU contains a Send Sequence Number T(S).

<span class="h6"><a class="selflink" id="section-7.2.3.4.2" href="#section-7.2.3.4.2">7.2.3.4.2</a>  Flow Control Principles</span>

        The receiver of data TPDUs holds a count of the sequence
number of the next expected TPDU.  This count is called the
Receive Sequence Number, T(R). The receiver indicated to the sender
the number of Data TPDUs he is ready to receive by means of a 'credit'
mechanism.  Credits are given using the credit field in the AK TPDU.
The value of the credit field, in conjunction with the value of T(R)
transported by the YR-TU-NR (your TPDU number) field
of the AK TPDU, is used by the receiver of the AK TPDU to determine
whether and how many Data TPDUs may be accepted by the sender of the
AK TPDU. Precise definition of flow control principles appears in <a href="#section-7.2.5.5.3">Section
7.2.5.5.3</a>.

<span class="h6"><a class="selflink" id="section-7.2.3.4.3" href="#section-7.2.3.4.3">7.2.3.4.3</a>  Expedited Flow</span>

        The non network expedited variant is used.  Normal
flow is the flow of data subject to the flow control mechanism,
expedited flow is the flow of data that the sender may send without
explicit agreement of the receiver.  This expedited flow has a
limited capability and could for example be used to carry session
supervisory commands.

        The number of expedited data units outstanding at any
time is limited to one and the amount of TS-user data is limited (up
to 16 octets).

        An expedited data may arrive before normal data which
was submitted earlier.  Normal data submitted after the expedited</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 43
International Standards Organization


data will arrive after the expedited data.

<span class="h4"><a class="selflink" id="section-7.2.4" href="#section-7.2.4">7.2.4</a>   Connection Establishment Procedures for Class 2</span>

<span class="h5"><a class="selflink" id="section-7.2.4.1" href="#section-7.2.4.1">7.2.4.1</a>  References</span>

        See <a href="#section-6.5">Section 6.5</a> for reference assignment.  Receipt of
any TPDU with a reference that is not assigned to a transport
connection other than a Disconnect Request (DR) or Connection
Request (CR) will be ignored.

        Receipt of a Disconnect Request (DR) for an unassigned
Reference will result in a Disconnect Confirm (DC) response.

<span class="h5"><a class="selflink" id="section-7.2.4.2" href="#section-7.2.4.2">7.2.4.2</a>  Connection Eastablishment</span>

        This phase is achieved by exchange of CR/CC TPDU using
the 'connection establishment' function.  Since the multiplexing
function is in use, then more than one transport connection may be
assigned to the same network connection concurrently.  The
restrictions of Class 0 does not apply to this class and the other
higher classes.

<span class="h4"><a class="selflink" id="section-7.2.5" href="#section-7.2.5">7.2.5</a>   Data Transfer Procedures for Class 2</span>

        The data transfer procedures described in the
following section apply independently to each transport connection
existing between two transport entities.

<span class="h5"><a class="selflink" id="section-7.2.5.1" href="#section-7.2.5.1">7.2.5.1</a>  TPDU Maximum Length and Segmenting</span>

        The general rules defined in <a href="#section-6.3">Section 6.3</a> apply.

<span class="h5"><a class="selflink" id="section-7.2.5.2" href="#section-7.2.5.2">7.2.5.2</a>  Concatenation</span>

        The general rules defined in <a href="#section-6.4">Section 6.4</a> apply.

<span class="h5"><a class="selflink" id="section-7.2.5.3" href="#section-7.2.5.3">7.2.5.3</a>  Sending Data TPDU (No Explicit Flow Control Option)</span>

        In this case the data TPDU is built in accordance
with the rules stated in <a href="#section-6.2">Section 6.2</a> and 6.3 and sent without any
additional mechanisms.  Thus, the DT TPDU NR field may take any
value and no AK TPDU is used.

<span class="h5"><a class="selflink" id="section-7.2.5.4" href="#section-7.2.5.4">7.2.5.4</a>  Sending Data TPDU (When Explicit Flow Control is Used)</span>

        On each transport connection the transmission of Data
TPDUs is controlled separately for each direction and is based on
authorization from the receiver.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 44
International Standards Organization


        This authorization is provided through the use of
the TPDUs Credit field.  Credit field values are only present in
the following TPDUs:  CR, CC, AK..

<span class="h6"><a class="selflink" id="section-7.2.5.4.1" href="#section-7.2.5.4.1">7.2.5.4.1</a>  Numbering of Data TPDUs</span>

        Each Data TPDU transmitted between transport entities,
for each direction of transmission in a transport connection, is
sequentially numbered.

        The sender of Data TPDUs holds a count of the next
TPDU to be sent.  This count is called the Send Sequence Number
T(S).  The sender indicates to the receiver the number of the data
TPDU he sends by putting the current T(S) value into the TPDU-NR
field of the data TPDU.

        Sequence numbering is performed modulo 2**n, where n
is the number of bits of the sequence number field.  The T(S)
counter cycles through the entire range 0 to (2**n)-1.

        At connection establishment time both Transport
entities initialize their T(S) and T(R) counts to zero (i.e. the
first Data TPDU to be transmitted between transport entities for a
given direction of data transmission after the connection
establishment has a TPDU-NR field set to zero).

        Receipt of a Data TPDU whose TPDU-NR field is not
equal to the expected value T(R), is to be regarded as a protocol
error.

        Operations described above are summarized as follows:

        o  initalization

           T(S) = 0     T(R) = 0

               Sending of Data TPDU
                         put T(S) into the TPDU-NR field of
                         the Data TPDU to be sent

                         T(S) = (T(S) + 1) (modulo 2**n)

               Receiving of Data TPDU

                         TPDU-NR field of the received data
                         TPDU which is not equal to T(R) is
                         a protocol error.

                         T(R) = (T(R) + 1) (modulo 2**n)
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 45
International Standards Organization


<span class="h6"><a class="selflink" id="section-7.2.5.4.2" href="#section-7.2.5.4.2">7.2.5.4.2</a>  Window Definition</span>

        For each transport connection and for each direction
of data transmission a 'transmit window' is defined as the (possibly
null) ordered set of consecutive data TPDUs authorized to be
transmitted in that direction.  At any given time, the lowest
sequence number of a data TPDU which a transport entity is
authorized to transmit is referred to as the 'lowest window edge'.
The 'upper window edge' is calculated  by adding the credit
allocation, given by the value of the Credit (CDT) field contained
in a received TPDU, to the lower window edge.  Note that a transport
entity is authorized to send data TPDUs with sequence numbers up to
but not including the upper window edge.

<span class="h6"><a class="selflink" id="section-7.2.5.4.3" href="#section-7.2.5.4.3">7.2.5.4.3</a>  Flow Control</span>

        Flow control is performed as follows:

        o  initialization time

           Lower window edge = 0

           Upper window edge = N (Credit received either in
           CR or in CC and N &lt; 2**p &lt; 2** (n-1), where P is the number of
           bits in credit field of CR and CC.

        o  Sending of a Data TPDU

           Send data TPDUs while T(S) is less than the upper window
           edge.  If T(S) equals the upper window edge then wait for
           additional credit before sending.

        o  Reception of Data TPDU (with TPDU NR = T(R)

           If T(R) is greater than or equal to the upper window edge
           authorized to the sending transport entity, then the receiving
           transport entity shall use the Treatment of Protocol Errors
           function.  Otherwise T(R) shall be incremented.

           Sending Credit

                    Send AK TPDU with YR-TU-NR = T(R) and Credit equals N.
                    (Where N = number of additional data
                    TPDUs the entity is prepared to receive.)

           Receiving Credit in AK.

                    Lower window edge = YR-TU-NR received.

                    Upper window edge =  Lower window edge + N.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 46
International Standards Organization


<span class="h6"><a class="selflink" id="section-7.2.5.4.4" href="#section-7.2.5.4.4">7.2.5.4.4</a>  Reducing the Upper Window Edge</span>

        The value of the upper window edge cannot be decreased
in this class.  If, at a certain point of time, the upper window edge
value is U, the reception of an AK TPDU having YR-TU-NR = M and CDT
= N such that:

        (U-M) (mod. 2**n) &gt; N

is a protocol error

        Provided the previous statements are respected, CDT
field may take any value including zero.

<span class="h6"><a class="selflink" id="section-7.2.5.4.5" href="#section-7.2.5.4.5">7.2.5.4.5</a>  Procedure for Expedited Data Transfer</span>

        The procedure of expedited data transfer allows a
transport entity to transmit data to the remote transport entity
without following the flow control procedure of the normal data
flow.  This procedure can only apply in the transfer phase.

        The expedited procedure has no effect on the transfer
and flow control applying to normal Data TPDUs.

        To transmit expedited data, the transport entity sends
an expedited data TPDU (ED TPDU).  The size of a data field is
limited (up to 16 octets).  The data field contains a complete ED
TSDU.  The remote transport will then confirm the receipt of the ED
TPDU by transmitting an expedited TPDU acknowledgement (EA TPDU).
A transport entity can send another ED TPDU only after having
received an EA TPDU for the previously transmitted ED TPDU.  In
class 2 the ED TPDU NR field of the ED and YR-TU-NR field of the EA
TPDU are not defined and may take any value.

<span class="h4"><a class="selflink" id="section-7.2.6" href="#section-7.2.6">7.2.6</a>   Release Procedures for Class 2</span>

        The data phase ends after a transport entity has sent
or received a Disconnect Request (DR).  The transport entity will
ignore any incoming TPDU except DC or DR.

        If the network resets or clears the network
connection, all transport connections are terminated without the
transport clearing sequence.  The References become frozen.

        For Class 2 the explicit variant of the 'release'
mechanism is used, enabling transport connections to be cleared
independently of the underlying network connection.

<span class="h4"><a class="selflink" id="section-7.2.7" href="#section-7.2.7">7.2.7</a>   Treatment of Invalid TPDUs</span>
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 47
International Standards Organization


        The 'Treatment of Protocol Error' mechanism in Section
<span class="h3"><a class="selflink" id="section-6.23" href="#section-6.23">6.23</a> is used.</span>

<span class="h4"><a class="selflink" id="section-7.2.8" href="#section-7.2.8">7.2.8</a>   Behaviour after an Error signalled by the Network Layer.</span>

        The implicit termination mechanism is used.

<span class="h4"><a class="selflink" id="section-7.2.9" href="#section-7.2.9">7.2.9</a>   Supported Options</span>

        Non use of explicit flow control.
        Extended formats.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>     PROTOCOL DESCRIPTION OF CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS</span>

<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>   Characteristics of Class 3</span>

        The characteristics of Class 3 in addition to those of
Class 2 is to mask errors indicated by the network.  Selection of
this class is usually based upon reliability criteria.  Class 3 has
been designed to be used in association with type B network connections.

<span class="h4"><a class="selflink" id="section-7.3.2" href="#section-7.3.2">7.3.2</a>   Functions of Class 3</span>

        This class provides the functionality of Class 2 (with
use of explicit flow control) plus the ability to recover after a
failure signalled by the Network Layer without involving the user
of the transport service.

        The mechanisms used to achieve this functionality also
allow the implementation of more flexible flow control.

<span class="h4"><a class="selflink" id="section-7.3.3" href="#section-7.3.3">7.3.3</a>   Protocol Mechanisms of Class 3</span>

        Class 3 mechanisms include Class 2 (with use of
explicit flow control option) mechanisms and the ability to recover
after a failure signalled by the network without informing the user
of the transport connection.

<span class="h5"><a class="selflink" id="section-7.3.3.1" href="#section-7.3.3.1">7.3.3.1</a>  Error Recovery Principles</span>

        The sending transport entity keeps a copy of
transmitted Data TPDUs and ED TPDUs until it receives a positive
aknowledgement which allows copies to be released.  It may also
receive an RJ command inviting it to retransmit or transmit all Data
TPDUs, if any, from the point in the sequence indicated in the  RJ
command.

        This is especially the case, when a failure is
indicated by the network.  The transport entity sends an RJ command
in order to indicate the sequence number of the next expected TPDU.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 48
International Standards Organization


        Error recovery for ED TPDU is achieved by retransmission
(see 7.3.5.3).

<span class="h5"><a class="selflink" id="section-7.3.3.2" href="#section-7.3.3.2">7.3.3.2</a>  Relationship between Flow Control and Error Recovery</span>

        Acknowledgement is performed by use of the T(R) count.          A
 credit is associated with this acknowledgement which may
be equal to or greater than zero.  Thus it is possible to acknowledge
data without giving the right to send new data.

        Credit may be reduced, by the use of the RJ TPDU.

<span class="h4"><a class="selflink" id="section-7.3.4" href="#section-7.3.4">7.3.4</a>   Connection Establishment Procedure for Class 3</span>

        The rules for Class 2 (with use of explicit flow
control) apply with the addition of the following rules which apply
on receipt of an eror indication from the Network layer.

        o  Reception of an error indication by a
           transport entity which, prior to this event, has
           sent a CR and has not yer received a CC, causes
           the transport entity to retransmit CR.

        o  Reception of an error indication by a
           transport entity to wait for reception of CR, RJ
           or DR TPDU.  In this case:

           - Reception of CR will cause the transport
             entity to retransmit CC.

           - Reception of RJ will cause the transport
             entity to transmit an RJ with a YR-TU-NR
             equal to zero and enter the data phase.

           - Reception of a DR will cause termination
             of the transport connection as for Classes 1
             and 2 (see 7.1.4).

<span class="h4"><a class="selflink" id="section-7.3.5" href="#section-7.3.5">7.3.5</a>   Data Transfer Procedures for Class 3</span>

<span class="h5"><a class="selflink" id="section-7.3.5.1" href="#section-7.3.5.1">7.3.5.1</a>  Acknowledgement</span>

        The 'AK' variant of the Retention until
Acknowledgement of TPDUs function is used.

<span class="h5"><a class="selflink" id="section-7.3.5.2" href="#section-7.3.5.2">7.3.5.2</a>  Retransmission Procedure</span>

        TPDU retransmission is a procedure which allows
a transport entity to request retransmission of one or several
consecutive Data TPDUs from the remote transport entity.  A</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 49
International Standards Organization


transport reject condition is signalled to the remote transport
entity by transmission of an RJ TPDU whose YR-TU-NR field indicates
the sequence number of the next expected Data TPDU.

        On receipt of a RJ TPDU, a Transport entity shall
accept credit to the value contained in the credit field and shall
re-transmit TPDUs, starting with the one whose number is specified in
the YR-TU-NR field of the received RJ TPDU, subject to the new
credit.

        The transport entity shall not specify a T(R) in the
RJ TPDU less than that which has previously been acknowledged.
Receipt of an RJ TPDU with a T(R) which has been previously
acknowledged will be considered a protocol error.

        Additional DT TPDUs pending initial transmission may
follow the retransmitted DT TPDU(s) if the window is not closed.

<span class="h5"><a class="selflink" id="section-7.3.5.3" href="#section-7.3.5.3">7.3.5.3</a>  Reducing the upper window edge</span>

        It is possible to decrease the value of the upper
window edge down to the sequence number transported by YR-TU-NR
field of the RJ TPDU.  Receipt of an DT TPDU which would have been
inside the window before the reduction is not a protocol error and
this TPDU may be discarded.

        Note:  In such a case the credit equal to zero
achieves the effect of a Receive not Ready Condition.

<span class="h5"><a class="selflink" id="section-7.3.5.4" href="#section-7.3.5.4">7.3.5.4</a>  Behaviour after an error signalled by the network layer</span>

        After receiving an error indication from the Network
Service, the transport entity shall tranmit to the remove entity an
RJ TPDU with YR-TU-NR field indicating the sequence number of the
next expected Data TPDU.

<span class="h5"><a class="selflink" id="section-7.3.5.5" href="#section-7.3.5.5">7.3.5.5</a>  Procedure for Expedited Data Transfer</span>

        In Class 3, the ED TPDU-NR field of the Expedited
Data (ED) TPDU contains an identification number.  This number must
be different for successive ED TPDUs.  That is, when an ED TPDU has
been sent and an EA TPDU for the ED TPDU has been received, the next
ED TPDU must have a different value in the NR field of the ED
TPDU.  No other significance is attached to this field.  It is
recommended, however, that the values used be consecutive modulo
2**n.  When a transport entity receives an ED TPDU for a transport
connection, it shall respond by transmitting an expedited
acknowledgement (EA) TPDU.

        It places in the YR-TU-NR field the value contained in</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 50
International Standards Organization


the NR field of the received ED TPDU.  If, and only if, this value
is different from the NR field of the previously received ED TPDU,
the data contained in the TPDU is to be passed to the session entity.

        If an error indication from the Network layer is
received before the receipt of the expected Expedited Acknowledgement
(EA) TPDU, the transport entity shall retransmit the ED TPDU with
the same value in the NR field.  By the rule described in the
previous paragraph, the session entity does not receive data
corresponding to the same expedited TPDU more than once.

<span class="h4"><a class="selflink" id="section-7.3.6" href="#section-7.3.6">7.3.6</a>   Release Procedures for Class 3</span>

        The rules for Class 2 apply with the addition of the
following rule:

        Receipt of an eror indication by a transport entity,
which prior to this event has sent a DR, causes this transport
entity to retransmit DR.  Only DC and DR will be accepted and
interpreted as the completion of the connection clearing sequence.
The related Reference will become unassigned.

<span class="h4"><a class="selflink" id="section-7.3.7" href="#section-7.3.7">7.3.7</a>   Treatment of Invalid TPDUs</span>

        The 'Treatment of Protocol Errors' mechanism is used.

<span class="h4"><a class="selflink" id="section-7.3.8" href="#section-7.3.8">7.3.8</a>   Supported Options</span>

        Extended formats.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>     PROTOCOL DESCRIPTION OF CLASS 4: ERROR DETECTION AND RECOVERY CLASS</span>

<span class="h4"><a class="selflink" id="section-7.4.1" href="#section-7.4.1">7.4.1</a>   Characteristics of Class 4</span>

        The characteristic of Class 4, in addition to those of
Class 3, is the detection of errors which occur as a result of the
low grade of service available from the network layer.  The kinds of
errors to be detected include:  TPDU loss, TPDU delivery out of
sequence, TPDU duplication.  These errors may afect control TPDUs as
well as Data TPDUs.

        Class 4 has been designed to be usd in association
with network connections of type C.

<span class="h4"><a class="selflink" id="section-7.4.2" href="#section-7.4.2">7.4.2</a>   Functions of Class 4</span>

        This class provides the functionality of Class 3, plus
the ability to detect and recover from lost, duplicated or out of
sequence TPDUs without involving the user of the transport service.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 51
International Standards Organization


        This detection of errors is made by extended use of
the sequence numbering of Classes 2 and 3, by a timeout mechanism,
and by additional protocol mechanisms.

        This class additionally detects and recovers from
damaged TPDUs by using a checksum mechamism.  The use of the
checksum mechanism must be available but its use or its non use is
subject to negotiation.  Class 4 does not attempt to deal with
detection of errors due to the misdelivery of TPDUs.

<span class="h4"><a class="selflink" id="section-7.4.3" href="#section-7.4.3">7.4.3</a>   Protocol Mechanisms of Class 4</span>

<span class="h5"><a class="selflink" id="section-7.4.3.1" href="#section-7.4.3.1">7.4.3.1</a>  Network Service Data Unit Lifetime</span>

        The network layer is assumed to provide, as an aspect
of its grade of service, for a bound on the maximum lifetime of
NSDUs in the network.  This value is known by the Transport Layer.
The maximum time which may elapse between the transmission of an
NSDU into the network layer and the receipt of any copy of it is
referred to as M.

<span class="h5"><a class="selflink" id="section-7.4.3.2" href="#section-7.4.3.2">7.4.3.2</a>  Average Transit Delay</span>

        It is assumed that there is some value of transmit
delay in the network, typically much less than M, which will be the
maximum delay suffered by all but a small proportion of NSDUs.  This
value is referred to as E.

<span class="h5"><a class="selflink" id="section-7.4.3.3" href="#section-7.4.3.3">7.4.3.3</a>  Remote Acknowledge Time Assumptions</span>

        Any transport entity is assumed to provide a bound for the
maximum time which can elapse between its receipt of a TPDU from
the Network Layer and its transmisssion of the Corresponding response.
this value is referred to as A/L.  The corresponding time given by the
remote transport entity is referred to as A/R.  The values for these
timers may be conventionally established or may be established
at connection establishment time.

<span class="h5"><a class="selflink" id="section-7.4.3.4" href="#section-7.4.3.4">7.4.3.4</a>  Local Retransmission Time</span>

        The local transport entity is assumed to maintain a
bound on the time it will wait for an acknowledgement before
retransmitting the TPDU.  This time is the local retransmission time
and is referred to as T1.

                  T1 = 2*E +  X  + Ar?

             Where X is a value to allow for TPDU processing in the
local transport entity.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 52
International Standards Organization


<span class="h5"><a class="selflink" id="section-7.4.3.5" href="#section-7.4.3.5">7.4.3.5</a>  Persistence Time</span>

        The local transport entity is assumed to provide a
bound for the maximum time for which it may continue to retransmit
a TPDU requiring positive acknowledgment.  This value is referred to
as R.

        The value is clearly related to the time elapsed
between retransmission, T1, and the maximum number of
retransmissions, N.  It is not less than T1*N+X, where X is small
quantity to allow for additional internal delays, the granularity of
the mechanism used to implement T1 and so on.  Because R is a bound,
the exact value of X is unimportant as long as it is bounded and
the value of a bound is known.

<span class="h5"><a class="selflink" id="section-7.4.3.6" href="#section-7.4.3.6">7.4.3.6</a>  Bound on Reference Identifier and Sequence Numbers</span>

        Using the above values, a bound L may be established
for the maximum time between the decision to transmit a TPDU and the
receipt of any response relating to it.  The value of L is given by:

                  L = 2*M+R+Ar

        It is necessary to wait for a period L before reusing
any reference or sequence number, to avoid confusion in case a TPDU
referring to it may be duplicated or delayed.

        (Note:  In practive, the value of L may be
unacceptably large.  It may also be only a statistical figure at a
certain confidence level.  A smaller value may therefore be used
where this still allows the required quality of service to be
provided).

<span class="h5"><a class="selflink" id="section-7.4.3.7" href="#section-7.4.3.7">7.4.3.7</a>  Inactivity Time</span>

        To protect against unsignalled breaks in the network
connection (Half-open connections), each transport entity maintains
an inactivity time interval.   If the interval passes without
receipt of some TPDU, the transport entity will terminate the TC by
making use of the release procedure.  This interval is referred to
as I.

<span class="h5"><a class="selflink" id="section-7.4.3.8" href="#section-7.4.3.8">7.4.3.8</a>  Window Time</span>

        A transport entity maintains a time to ensure that
there is a maximum interval between transmission of up-to-date
window information.  This interval is referred to as the window
time, W.

<span class="h5"><a class="selflink" id="section-7.4.3.9" href="#section-7.4.3.9">7.4.3.9</a>  Class 4 Error Recovery Principles</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 53
International Standards Organization


        In class 4, the transport entity associates a response time
with TPDUs sent requiring a response.  If an appropriate response is
not received within time T1, the recovery procedure must be invoked
by the sender.  This will usually involve the retransmission of the
corresponding TPDU.

        A TPDU may be transmitted a maximum number of times,
This number is referred to a N.  The value of N is chosen so that
the required quality of service can be provided given the known
characteristics of the network connection.

<span class="h5"><a class="selflink" id="section-7.4.3.10" href="#section-7.4.3.10">7.4.3.10</a>  Relationship of Times and Intervals</span>

        The following note describes the relationship between
the time described in <a href="#section-7.4.3.1">Section 7.4.3.1</a> - 7.4.3.9.

        Note:

             a.   The interrelationship of times for the worst case
                  is as follows:

                  M:   maximum transit delay of the network (see
                       7.4.3.1)

                  Ar  maximum acknowledgement time of the remote
                       transport entity (see 7.4.3.3)

                  R:   maximum local retransmission time (see
                       7.4.3.5)

                  N:   maximum number of transmission for a single
                       TPDU (see 7.4.3.9)

                  L:   maximum time for a TPDU to be valid (see
                       7.4.3.6)

                                             R = T * (N-1)
                                                  1

                            R

                            *
                            M
             L              *

                            A                =2*M  +  A   + R
                             R                         R

                            *
                            M</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 54
International Standards Organization



                                 t      t

             b.   The interrelationship of times for the average
                  case is as follows (see 7.4.3.4)

                  E:        average transit delay for the network
                            (E&lt;&lt;M)

                  X:        TPDU processing time

                  T :       average time from sending a TPDU until
                   1        the receipt of its acknowledgement (see
                            7.4.3.4)

                  A :       maximum acknowledgement time of the
                   R        remote transport entity (see 7.4.3.3)

                         X

                         E

                         A         T  = 2*E + X + A
                          R         1              R

                         E
t                t

<span class="h5"><a class="selflink" id="section-7.4.3.11" href="#section-7.4.3.11">7.4.3.11</a>  Sequence Numbering</span>

        In Class 4 sequence numbering is applied to certain
control TPDUs and their acknowledgements, as well as to DT TPDUs.
These are ED and its acknowledgement EA.

        The length of sequence numbers may be negotiated at
connection establishment.  Where other than the default length is
used, an extended header format is used for sequenced TPDUs
containing additional octets of sequence numbers.  Extended header
format includes a credit field on the appropriate TPDU types
allowing extended credit allocation.

<span class="h4"><a class="selflink" id="section-7.4.4" href="#section-7.4.4">7.4.4</a>   Procedures for Connection Establishment Phase</span>

        The following features pertain to connection
establishment for Class 4:

        o  In Class 4, a connection is not considered
           established until the successful completion
           of a 3-way TPDU exchange.  The sender of a
           CR TPDU must respond to the corresponding CC</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 55
International Standards Organization


           TPDU by immediately sending a DT, ED or AK TPDU.

        o  As a result of duplication, a CR TPDU may be
           received specifying a source reference which
           is already in use with the sending transport
           entity.  If the receiving transport entity
           is in the data transfer phase, having
           completed the 3-way TPDU exchange procedure,
           the receiving transport entity should ignore
           such a TPDU.  Otherwise a CC TPDU should be
           transmitted.

        o  As a result of duplication or
           retransmission, a CC TPDU may be received
           specifying a paired reference which is
           already in use.  The receiving transport
           entity should ignore such a CC TPDU.

        o  A CC TPDU may be received specifying a
           reference which is in the frozen state.  The
           response to such a TPDU should be a DR TPDU.

<span class="h5"><a class="selflink" id="section-7.4.4.1" href="#section-7.4.4.1">7.4.4.1</a>  Connection Request</span>

        When a transport entity transmits a CR TPDU it starts
timer T1.  If this timer expires before a CC TPDU is received, the
CR TPDU is retransmitted and the timer restarted.  After
transmission of the CR TPDU N times, the connection establishment
procedure is abandoned and the failure reported to the transport
user.  The reference must be placed in the frozen state for a period
L (see <a href="#section-7.4.3.6">section 7.4.3.6</a>).

<span class="h5"><a class="selflink" id="section-7.4.4.2" href="#section-7.4.4.2">7.4.4.2</a>  Incomimg Connection Request</span>

        An incoming connection request is processed as for Class 3

<span class="h5"><a class="selflink" id="section-7.4.4.3" href="#section-7.4.4.3">7.4.4.3</a>  Connection Confirm</span>

        When a transport entity transmits a CC TPDU it starts
timer T1.  If this timer expires before an AK or DT TPDU is
received, the CC TPDU is retransmitted according to the
retransmission principles in <a href="#section-7.4.3.9">Section 7.4.3.9</a>

<span class="h5"><a class="selflink" id="section-7.4.4.4" href="#section-7.4.4.4">7.4.4.4</a>  Incoming Connection Confirm</span>

        When a CC TPDU is received, the receiving transport entity
enters the data transfer phase.  It must immediately transmit an
AK, ED or DT TPDU to complete the 3-way TPDU exchange.  The
CC TPDU is subject to the usual rules of the data transfer phase
regarding retransmission, see <a href="#section-7.4.5.3">Section 7.4.5.3</a>.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 56
International Standards Organization


<span class="h5"><a class="selflink" id="section-7.4.4.5" href="#section-7.4.4.5">7.4.4.5</a>  Incoming Acknowledgement</span>

        When an AK, DT or ED TPDU is received the receiving
transport entity can enter the data transfer phase.  If the entity
has data to send it may send DT TPDUs or an ED TPDU.  The DT TPDUs
are subject to flow control.  Otherwise, the transport entity must
obey the inactivity principles (see <a href="#section-7.4.5.8">Section 7.4.5.8</a>).

<span class="h5"><a class="selflink" id="section-7.4.4.6" href="#section-7.4.4.6">7.4.4.6</a>  Unsuccessful Connection</span>

        When a DR TPDU is received in response to a CR TPDU,
the timer T1 is cancelled and the reference placed in the frozen
state for a period L (see <a href="#section-7.4.6.1">Section 7.4.6.1</a>).

<span class="h5"><a class="selflink" id="section-7.4.4.7" href="#section-7.4.4.7">7.4.4.7</a>  Initial Credit Allocation</span>

        The CR and CC TPDUs may allocate an initial credit value
to their respective recipients.  This value is limited to 15 by the
encoding of the TPDU.  Where the extended header format is in use,
credit values greater than 15 must be allocated using AK TPDUs.

<span class="h5"><a class="selflink" id="section-7.4.4.8" href="#section-7.4.4.8">7.4.4.8</a>  Exchange of Acknowledge Time</span>

        A transport entity may transmit the value it intends
to use for AL at connection establishment, as the 'Acknowledge
Time' parameter in the CR or CC TPDU (depending on whether the
transport entity is initiating or accepting the transport
connection).  If this parameter is present in a received CR or CC
TPDU, the value of AR should be set accordingly.  If this
parameter is not present, AR may be assumed to be insignificant in
comparison to E the typical maximum transit delay.

<span class="h4"><a class="selflink" id="section-7.4.5" href="#section-7.4.5">7.4.5</a>   Procedure for Data Transfer Phase</span>

<span class="h5"><a class="selflink" id="section-7.4.5.1" href="#section-7.4.5.1">7.4.5.1</a>  Sequence Control</span>

        The receiving transport entity is responsible for
maintaining the proper sequence of DT TPDUs.

        DT TPDUs received out of sequence must not be
delivered to the TS-user until in-sequence TPDUs have also been
received.

        AK TPDUs also contain information allowing the
receiving transport entity to process them in the correct order.

<span class="h5"><a class="selflink" id="section-7.4.5.2" href="#section-7.4.5.2">7.4.5.2</a>  Duplicate DT TPDUs</span>

        Duplicate TPDUs can be detected because the T(S) value
matches that of previously received TPDUs.  T(S) values must not be</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 57
International Standards Organization


reused for the period L after their previous use.  Otherwise, a
new, valid TPDU could be confused with a duplicated TPDU which had
previously been received and acknowledged.

        Duplicated DT TPDUs must be acknowledged, since the
duplicated TPDU may be the result of a retransmission resulting from
the loss of an AK TPDU.

        The data contained in a duplicated DT TPDU should be
ignored.

<span class="h5"><a class="selflink" id="section-7.4.5.3" href="#section-7.4.5.3">7.4.5.3</a>  Retransmission Principles</span>

        When a transport entity has some outstanding DT or ED
TPDUs that require acknowledgement, it will check that no T1
interval elapses without the arrival of an AK or EA TPDU that
acknowledges one of them.  If the timer expires, the first TPDU is
retransmitted and the timer is restarted.  After N transmissions
(N-1 retransmissions) the connection is assumed to have failed and
the release phase is entered, and the transport user is informed.

        DT TPDUs which fall beyond the current window (due to
reduction of the upper window edge) are not retransmitted until
advancement of the upper window edge so permits.

     Note:     This requirement can be met by different
                       means, for example.

             1.   One timer is associated with each TPDU.  If the
                  timer expires, the associated TPDU will be
                  retransmitted, and the timer T1 will be
                  restarted for all subsequent DT TPDUs.

             2.   One timer is associated with each TC:

                  if the transport entity transmits a DT TPDU
                  requiring acknowledgement, it starts timer
                  T1,

                  if the transport entity receives a TPDU that
                  acknowledges one of the TPDUs to be
                  acknowledged, timer T1 is restarted,

                  if the transport entity receives a TPDU that
                  acknowledges the last TPDU to be
                  acknowledged, timer T1 is stopped.

        For the decision whether the retransmission timer T1
is maintained on a per TPDU or on a per TC basis, throughput
considerations have to be taken into account.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 58
International Standards Organization


<span class="h5"><a class="selflink" id="section-7.4.5.4" href="#section-7.4.5.4">7.4.5.4</a>  Acknowledgement Principles</span>

        A transport entity operating class 4 must acknowledge
all TPDUs received requiring acknowledgment.  To avoid unnecessary
retransmissions and to avoid delays to transmission by the remote
transport entity, the delay for acknowledgement should not exceed
timer A  (see <a href="#section-7.4.3.2">Section 7.4.3.2</a>).
       L

        There are two TPDU types that must be acknowledged:
ED and DT.  Receipt of an ED TPDU must be acknowledged by an EA
TPDU.  A DT TPDU is acknowledged with an AK TPDU.

        An AK TPDU has the sequence number of the next DT
TPDU the receiving transport entity expects to receive.  It thus
acknowledges receipt of all DT TPDUs with sequence numbers less than
the acknowledgement number.

        An AK TPDU may be repeated at any time, using the
sequence number in the last AK TPDU sent.

<span class="h5"><a class="selflink" id="section-7.4.5.5" href="#section-7.4.5.5">7.4.5.5</a>  Flow Control Principles</span>

        Flow control in Class 4 is subject to the same
principles as in Classes 2 and 3.  The credit mechanism and window
principle of those classes still apply, except that in class 4, the
upper window edge can be reduced by the receiving transport entity
by sending an AK TPDU with a smaller credit.

        A receiving transport entity may send an AK TPDU at
any time to change the window size.  This AK TPDU may acknowledge a
new DT TPDU or may repeat a previous acknowledgement.

<span class="h5"><a class="selflink" id="section-7.4.5.6" href="#section-7.4.5.6">7.4.5.6</a>  Window Synchronization Principles</span>

        To ensure the synchronization of flow control
information the window timer provokes the frequent exchange of AK
TPDUs between transport entities.  The window timer maintains a
minimum level of TPDU traffic between transport entities cooperating
in a transport connection.

        In Class 4 the window size can be reduced in any AK
TPDU.  Due to the possibility of misordering of AK TPDUs and the
associated loss of efficiency, the AK TPDU for class 4
includes an additional field called the AK TPDU  subsequence
parameter.

        An AK TPDU should contain the subsequence parameter
whenever a duplicate AK TPDU is sent with the same sequence number
but with reduced credit.  The value of the subsequence parameter is</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 59
International Standards Organization


set to one for the first time the AK TPDU is resent with reduced
credit.

        When an AK TPDU is transmitted whose sequence
number is increased, the 'sub-sequence' parameter is omitted
until credit reduction takes place.

        When an AK TPDU is received, it must be processed
(i.e., its contents made use of) only if:

        o  The sequence number is greater than in any
           previously received AK TPDU, or,

        o  The sequence number is equal to the highest
           in any previously received AK TPDU, and the
           sub-sequence parameter is greater than in
           any previously received AK TPDU having the
           same sequence number (where an
           absent sub-sequence parameter is regarded
           as having a value of zero), or

        o  The sequence number and sub-sequence
           parameter are both equal to the highest in
           any previously received AK TPDU (where an
           absent sub-sequence parameter is regarded as
           having a value of zero), and the credit
           field is greater than in any previously
           received AK TPDU having the same sequence
           and sub-sequence numbers.

        When an AK TPDU is transmitted which opens a closed
window (i.e. increases credit from zero), it should be retransmitted
at an interval of T1.  Transmission should occur a maximum of N
times, after which the usual inactivity retransmission timer should
be reverted to.  Retransmission may also cease if the local
transport entity becomes sure that the new credit information has
been received by the remote transport entity.

        If a transport entity receives an AK TPDU containing
a 'Flow Control Confirmation' parameter, whose Lower Window Edge and
Your-Sub-Sequence fields are equal to its own lower window edge and
sub-sequence number, it may note that the credit available at the
remote transport entity (relative the Lower Window Edge field) is at
least equal to the value conveyed as Your Credit.  This enables the
transport entity to cease the frequent retransmission of window
information, if it thereby knows that the remote window is open.

        A transport entity need not retransmit window
information (except as described under Inactivity Principles) if it
is aware by the receipt of DT TPDUs that the remote transport entity</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 60
International Standards Organization


has sufficient credit to prevent deadlock.  When an AK TPDU is
transmitted in response to a DT TPDU, the transport entity may
normally assume that the transmitter of the DT TPDU will ensure that
the AK TPDU is received, be retransmission of the DT TPDU if
necessary.  Therefore, it can normally be assumed that the credit
conveyed in such an AK TPDU will be available to the remote
transport entity, and frequent retransmission is unnecessary.

        The assumption that the DT TPDU will be retransmitted
may be incorrect if credit reduction has taken place.  Therefore, a
transport entity may not make this assumption if the
sequence number of the DT TPDU is less than or equal to the highest
value for which permission to transmit (i.e., credit) has been given
and subsequently withdrawn.

        Upon receipt of an AK TPDU which increases the upper
window edge, a transport entity may transmit an AK TPDU which
repeats the information contained in the received TPDU in a 'Flow
Control Confirmation' parameter in its variable part an thereby
assures the transmitter of the original AK TPDU of its own state.
Such an AK TPDU may be tranmmitted:

        o  Upon receipt of a duplicated AK TPDU
           (i.e., one which is identical in all fields,
           including the sub-sequence parameter if
           present, to the most recently received AK
           TPDU which was not discarded due to
           detection of a sequence error), not
           containing the 'Flow Control Confirmation'
           parameter.

        o  Upon receipt of an AK TPDU which increases
           the upper window edge but does not increase
           the lower window edge, when the upper window
           edge was formerly equal to the lower window
           edge.

<span class="h5"><a class="selflink" id="section-7.4.5.7" href="#section-7.4.5.7">7.4.5.7</a>  Procedure for Expedited Data</span>

        The procedure for expedited data is as for Class 3,
with the following exceptions.

        The ED TPDU has a sequence number which is allocated
from a separate sequence space from that of the DT TPDUs.  The EA
TPDU carries the same sequence number as the corresponding ED TPDU.
Only a single ED TPDU may be transmitted and awaiting
acknowledgements at any time.

        Upon receipt of an unduplicated ED TPDU, a transport
entity immediately forwards the data to the transport user.  The ED</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 61
International Standards Organization


TPDU sequence number is recorded in an EA TPDU sent to the other
transport entity.

        The sender of an ED TPDU shall not send any new DT
TPDU with higher T(S) until it receives the EA TPDU.  This
guarantees the arrival of the ED TPDU before any subsequently sent
DT TPDUs.

<span class="h5"><a class="selflink" id="section-7.4.5.8" href="#section-7.4.5.8">7.4.5.8</a>  Inactivity Principles</span>

        If the Inactivity Time I passes without receipt of
some TPDU, the transport entity will terminate the TC by making use
of the release procedure.  To present expiration of the remote
transport entity's inactivity times when no data is being sent, the
local transport entity must send AK TPDUs at suitable intervals in
the absence of data, having regard to the probability of TPDU loss.
The Window Synchronization Principles (see 7.4.5.6) may ensure that
this requirement is met.

        Note: It is likely that the release procedure
initiated due to inactivity timer expiration will fail, as such
expiration indicates probable failure of the supporting NC or of the
remote transport entity.  This case is described in <a href="#section-7.4.6">Section 7.4.6</a>.

<span class="h4"><a class="selflink" id="section-7.4.6" href="#section-7.4.6">7.4.6</a>   Procedures for Release Phase</span>

        The rules for class 3 apply.  The DR TPDU is subject
to the usual retransmission procedure.  After N retransmissions, the
transport connection is considered disconnected, the Reference is
placed in the frozen state for a period L and retransmission ceases.

        The DC TPDU is sent only in response to a DR TPDU, and
is not subject to the retransmission procedure.

        The DC TPDU when received allows the transport entity
to release all resources maintained for the transport connection.

        The DR TPDU does not carry a sequence number.  Any
previously transmitted TPDUs (including DT and ED) which are
received after the DR TPDU result in a further DR TPDU but are
otherwise ignored.  After disconnection, for whatever reason, the
Reference is placed in the frozen state for a period L.

<span class="h5"><a class="selflink" id="section-7.4.6.1" href="#section-7.4.6.1">7.4.6.1</a>  Unassigned Frozen References</span>

        When a transport connection is terminated, the
corresponding references cannot be immediately reused since TPDUs
containing these references may continue to exist in the network for
a time up to L.  Therefore, these references will be placed in an
unassignable, frozen state for this peiod.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 62
International Standards Organization


        After an event involving loss of transport entity
state information, including the status of reference assignments,
all references relating to network connections whose transport
state information has been lost must be placed in the frozen state
for a period L.

        If a DC TPDU is received for a local reference which
is in the frozen state, or with a remore reference not matching the
already recorded one, this DC TPDU shall be ignored.

<span class="h4"><a class="selflink" id="section-7.4.7" href="#section-7.4.7">7.4.7</a>   Treatment of Invalid TPDUs</span>

        The 'Treatment of Protocol Erorrs' function is used.

<span class="h4"><a class="selflink" id="section-7.4.8" href="#section-7.4.8">7.4.8</a>   Supported Options</span>

        Non use of checksum.

        Use of extended formats.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.      ENCODING</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>     Summary</span>

                                    Classes
                                  0  1  2  3  4   Sect.       Code

CR Connection Request             x  x  x  x  x   8.3      1110xxxx

CC Connection Confirm             x  x  x  x  x   8.4      1101xxxx

DR Disconnect Request             x  x  x  x  x   8.5      10000000

DC Disconnect Confirm                x  x  x  x   8.6      11000000

DT Data                           x  x  x  x  x   8.7      11110000

ED Expedited Data                    x  NF x  x   8.8      00010000

AK Data Acknowledgement            NRC  NF x  x   8.9      0110xxxx
    (Note 1)

EA Expedited Data                    x  NF x  x   8.10     00100000
   Acknowledgement

RJ Reject (Note 1)                   x     x      8.11     0101xxxx

ERR TPDU Error                    x  x  x  x  x   8.12     01110000

not available (Note 2)                             -      00000000</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 63
International Standards Organization


not available (Note 2)                             -      00110000

not available (Note 2)                             -      1001xxxx

not available (Note 2)                             -      1010xxxx

Where xxxx (bits 4-1) is used to signal the CDT

Note 1: In extended header format, the code for AK=0110 0000 and the
        code for RJ=0101 0000.

Note 2: These codes are already in use in compatible protocols
        defines by standards organizations other than CCITT/ISO.

NF:     Not available when the non explicit flow control option is
        selected.

NRC:    Not available when the receipt confirmation option is
        selected.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>     Structure</span>

        As defined in the previous sections, all the Transport
Protocol Data Units (TPDU) shall contain an integral number of
octets.  The octets in a TPDU are numbered starting from 1 and
increasing in the order of transmission.  The bits in an octet are
numbered from 1 to 8, where bit 1 is the low-ordered bit.

        There are tao types of TPDUs:

        o  Data TPDUs, used to transfer Transport Service
           Data Units (TSDUs).  The structure of the TSDUs is
           maintained by means of the TSDU End Mark.

        o  Control TPDUs, used to control the transport
           protocol functions, including the optional
           functions.

Octets  1  2  3  4           n  n+1          p  p+1
        ------------      --------------   --------------   --------
        LI|  | |  |  ...    |  |   |    .... | |    |   .... |
        ------------      --------------   --------------   --------

         &lt;--- Fixed Part -----&gt;&lt;-- Variable Part-&gt;
                                   (including checksum
                                    where applicable)

        &lt;--------------Header-------------------&gt;&lt;----Data Field-&gt;

A TPDU is divided into four parts:</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 64
International Standards Organization


        o  Length Indicator Field (LI)

        o  Fixed Part

        o  Variable Part (may be omitted)

        o  Data Field (may be omitted)

The length Indicator Field, Fixed Part and Variable Part constitute
the Header of the TPDU.

<span class="h4"><a class="selflink" id="section-8.2.1" href="#section-8.2.1">8.2.1</a>   Length Indicator Field</span>

        This field is contained in the first octet of the
TPDUs.  The length is indicated by a binary number, with a maximum
value of 254 (11111110).  The length indicated is the header length,
including parameters, but excluding the length indicator field and
user data, if any.  The value 255 (11111111) is reserved for
possible extensions.

<span class="h4"><a class="selflink" id="section-8.2.2" href="#section-8.2.2">8.2.2</a>   Fixed Part</span>

        The fixed part contains frequently occurring functions
including the code of the TPDU.  The length and the structure of the
fixed part are defined by the TPDU code, defined by bits 5 to 8 of
the second octet of the header.

<span class="h5"><a class="selflink" id="section-8.2.2.1" href="#section-8.2.2.1">8.2.2.1</a>  TPDU Code</span>

        This field contains the TPDU code and is contained in
Octet 2 of the header.  It is used to define the structure of the
remaining header.  This field is a full octet except in the
following cases:

             1110 xxxx      Connecting Request
             1101 xxxx      Connection Confirm
             0101 xxxx      Reject
             0110 xxxx      Data Acknowledgement

        Where xxxx (bits 4-1) is used to signal the CDT.

        Any other bit pattern may be used to define a TPDU Code.
        Only those codes defined in <a href="#section-8.1">Section 8.1</a> are currently valid.

<span class="h4"><a class="selflink" id="section-8.2.3" href="#section-8.2.3">8.2.3</a>   Variable Part</span>

        The variable part is used to define parameters
relating to optional functions.  If the variable part is present, it
shall contain one or more parameters.  The number of parameters that
may be contained in the varialbe part is indicated by the length of</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 65
International Standards Organization


the variable part which is a LI minus the length of the fixed part.

        Since the currently defined minimum fixed part for
headers which allow parameters is four octets, and since the length
indication field is limited to a maximum of 254, the maximum length
of the variable part is 250 octets.

        Each parameter contained within the variable part is
coded as follows:

                      Bits 8   7   6   5   4   3   2   1
        Octets
        n+1                            Parameter Code
        n+2                            Parameter Length
                                        Indication (e.g."m")
        n+3                            Parameter Value

        n+2+m

        o       The parameter code field is coded in binary and,
                without extensions, provides a maximum number of
                255 different parameters.  However, as noted below,
                bits 8 and 7 indicates the source of definition,
                so the practical maximum number of different
                parameters is less.  Parameter code 1111 1111 is
                reserved for possible extensions of the parameter code.

        o       The parameter length indication indicates the length,
                in octets, of the parameter value field.  The length
                is indicated by a binary number, "m" with a theoretical
                maximum value of 255.  The practical maximum value of
                "m" is lower.  For example, in the case of a single parameter
                contained within the variable part, two octets
                are required for the Parameter Code and the Parameter Length
                Indication itself.  Thus, the value of "m"  is limited
                to 248.  For larger fixed parts of the header and for
                each succeedimg parameter, the maximum value of "m" decreases.

        o       The parameter value field contains the value of the
                parameter identified in the parameter code field.

        o       No standard parameter codes use bits 8 and 7 with the
                value 00.

        o       Implementations shall accept the parameters defined in
                the variable part in any order.  If any parameter is
                duplicated then the later value will be used.

<span class="h5"><a class="selflink" id="section-8.2.3.1" href="#section-8.2.3.1">8.2.3.1</a>  Checksum Parameter (Class 4 only)</span>
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 66
International Standards Organization


        All TPDU types may contain a checksum parameter in
their variable part.  This parameter must always be present except
when the non use of checksum option is selected.

             Parameter Code:     1100 0011
             Parameter Length:      2
             Parameter Value:    Result of checksum algorithm.
                                 This algorithm is specified in
                                 <a href="#section-6.18">Section 6.18</a>.

<span class="h4"><a class="selflink" id="section-8.2.4" href="#section-8.2.4">8.2.4</a>   Data Field  </span>    This field contains transparent user data.
Restrictions on its size are noted for each command.

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>     Connections Request (CR)</span>

<span class="h4"><a class="selflink" id="section-8.3.1" href="#section-8.3.1">8.3.1</a>   Structure</span>

        1     2         3        4     5    6     7     8     p   p+1
        LI  CR  CDT 00000000 00000000 SOURCE-   class  VARIABLE  USER DATA
                                      REFERENCE options   PART

<span class="h4"><a class="selflink" id="section-8.3.2" href="#section-8.3.2">8.3.2</a>   LI</span>

        See Section  8.2.1

<span class="h4"><a class="selflink" id="section-8.3.3" href="#section-8.3.3">8.3.3</a>   Fixed Part (Octets 2 to 7)</span>

             CR:       Connection Request Code:      1110

             CDT:      Initial Credit Allocation (set to 0000 in
                       Classes 0 and 1 when specified as preferred class).

             SOURCE REFERENCE:        Reference selected by the transport
                                      entity initiating the CR TPDU to
                                      identify the requested TC.

             CLASSES:   Bits 8-5 octer 7 defines the preferred Transport
                        Protocol class to be operated over the requested
                        TC.  This field may take on one of the following
                        values.

                                 0000           Class 0
                                 0001           Class 1
                                 0010           Class 2
                                 0011           Class 3
                                 0100           Class 4

        The CR contains the first choice of class in the fixed
part as above.  Second and subsequent choices are listed in the
variable part if required.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 67
International Standards Organization


        Bits 4-1 of octet 7 are reserved for options to be
used on the requested transport connection.

        The use of bits 4-1 is as follows:

                  BIT            OPTION

                  4              0    always

                  3              0    always

                  2              =0   use of normal formats
                                 =1   use of extended formats

                  1              =0   use of explicit flow control
                                      in Class 2

                                 =1   no use of explicit flow
                                      control in Class 2

        Note:

        1.  It is not valid to request 'use of expedited data
            transfer' (Additional option parameter) and no use of
            explicit flow control in Class 2' (bit 1 = 1).

        2.  Bits 4 to 1 are always zero in Class 0 and have
            no meaning.

<span class="h4"><a class="selflink" id="section-8.3.4" href="#section-8.3.4">8.3.4</a>   Variable Part (Octets 8 to p)</span>

        The following parameters are permitted in the variable part:

        o  Transport Service Access Point Identifier (TSAP-ID)

           Parameter code 11000001 for the identifier of the Calling TSAP.

           11000010 for the identifier of the Called TSAP.

        If a TSPA-ID is given in the request it may be
returned in the confirmation.

        o  TPDU size

        This parameter defines the proposed maximum TPDU size
(in octets including the header) to be used over the requested
transport connection.  The coding of this parameter is:

        Parameter Code 11000000
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 68
International Standards Organization


        Parameter value field

        00001101  8192 octets (not allowed in Class 0 of 1)

        00001100  4096 octets (not allowed in Class 0 of 1)

        00001011  2048 octets

        00001010  1024 octets

        00001001  512 octets

        00001000  256 octets

        00000111  128 octets

        Default value is 00000111 (128 octets)

        Version Number (not used in Class 0)

        Parameter code 11000100

        Parameter value field 00000001

        Default value 00000001

        Default value 00000001 (not used in Class 0)

       o Security Parameter (not used in Class 0)

         This parameter is user defined.

         Parameter code 11000101

         Parameter value and length field are user defined

       o Checksum (not used in Classes 0 through 3)

             See <a href="#section-8.2.3.1">Section 8.2.3.1</a>

         This parameter must always be present in a CR TPDU
         requesting Class 4, even if the checksum selection
         parameter is used to request non-use of the checksum facility.

       o Additional Option Selection (not used in Class 0)

        This parameter defines the selection to be made as to
        whether or not additional options are to be used.

        Parameter code 11000110</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 69
International Standards Organization


        Parameter length:  1
        Parameter value field:

        Bits related to options particular to one class are
        not meaningful and may take any value in the other classes.

             BITS                OPTION

             4    1=   Use of network expedited in Class 1
                  0=   Non use of network expedited in Class 1

             3    1=   Use of receipt confirmation in Class 1
                  0=   Use of explicit AK variant in Class 1

             2    0=   Checksums are to be used in Class 4
                  1=   Checksums are not to be used in Class 4

             1    1=   Use of transport expedited data transfer
                       service
                  0=   No use of transport expedited data transfer
                       service

             Default falue is 00000001

        o Alternative protocol class (not used in Class 0)

             Parameter code 11000111

             Parameter length  n

        Parameter value encoded as a sequence of single
octets.  Each octet is encoded as for octet 7 but with bits 4-1 set
to zero (i.e., no alternative option selections permitted).

        o  Acknowledge Time

        This parameter conveys the maximum acknowledge time
        AL to the remote transport entity.  It is an indication only, and
        is not subject to negotiation (see <a href="#section-7.4.5.3">section 7.4.5.3</a>).

        Parameter Code 10000101

        Parameter Value field: n a binary number (2 octets)

        n is the maximum acknowledge time, expressed in
        milliseconds.

        o  Throughput      Parameter code:    10001001

                            Length         :    12</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 70
International Standards Organization


                            1st 3 octets   :    Targer value,
                                                calling-called user
                                                direction

                            2nd 3 octets   :    Min. acceptable,
                                                calling-called
                                                user direction

                            3rd 3 octets    :   Target value,
                                                called-calling user
                                                direction

                            4th 3 octets  :     Min. acceptable,
                                                called-calling user
                                                direction

             Values are expressed in octets per second.

        o Residual          Parameter code:     10000110
          error rate
                            Length        :     3

                            1st octet     :     Target value, power
                                                of 10

                            2nd octet     :     Min. acceptable,
                                                power of 10

                            3rd octet     :     TSDU size of
                                                interest, expressed
                                                as a power of 2

        o  Priority         Parameter code:     10000111

                            Length        :     2

                            Value         :     Integer

        o  Transit          Parameter code:     10001000
             delay

                            Length        :     8

                            1st 2 octets  :     Target value,
                                                calling-called user
                                                direction

                            2nd 2 octets  :     Max. acceptable,
                                                calling-called user
                                                direction.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 71
International Standards Organization


                            3rd 2 octets  :     Target value,
                                                called-calling user
                                                direction.

                            4th 2 octets  :     Max. acceptable,
                                                called-calling user
                                                direction

             Values are expressed in milliseconds.

<span class="h4"><a class="selflink" id="section-8.3.5" href="#section-8.3.5">8.3.5</a>   User Data (Octets p+1 to the end)</span>

        No user data are permitted in class 0, and are
optional in the other classes.  Where permitted, it may not exceed
<span class="h2"><a class="selflink" id="section-32" href="#section-32">32</a> octets.</span>

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>     Connection Confirm (CC)</span>

<span class="h4"><a class="selflink" id="section-8.4.1" href="#section-8.4.1">8.4.1</a>   Structure</span>

        1     2     3     4     5     6    7    8    p   p+1

        LI CC  CDT DST-REF SOURCE-REF  class  VARIABLE  USER DATA
          1101                         options  Part

<span class="h4"><a class="selflink" id="section-8.4.2" href="#section-8.4.2">8.4.2</a>   LT</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>.

<span class="h4"><a class="selflink" id="section-8.4.3" href="#section-8.4.3">8.4.3</a>   Fixed Part (Octets 2 to 7)</span>

             CC                      :          Connection Confirm
                                                Code:  1101

             CDT                     :          Initial Credit
                                                Allocation (set to
                                                0000 in Classes 0
                                                and 1).

             DST-REFERENCE           :          Reference
                                                identifying the
                                                requested transport
                                                connection at the
                                                remote transport
                                                entity.

             SOURCE REFERENCE        :          Reference selected
                                                by the transport
                                                entity initiating
                                                the CC TPDU to</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 72
International Standards Organization


                                                identify the
                                                confirmed TC.

             CLASSES                 :          Defines the selected
                                                transport protocol class to
                                                be operated over the accepted
                                                TC according to the
                                                negotiation rules specified
                                                in <a href="#section-6.5">Section 6.5</a>.

<span class="h4"><a class="selflink" id="section-8.4.4" href="#section-8.4.4">8.4.4</a>   Variable part (Octet 8 to p)</span>

        See <a href="#section-8.3.4">Section 8.3.4</a>

<span class="h4"><a class="selflink" id="section-8.4.5" href="#section-8.4.5">8.4.5</a>   User Data (Octets p+1 to the end)</span>

        See <a href="#section-8.3.5">Section 8.3.5</a>

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>     Disconnect Request (DR)</span>

<span class="h4"><a class="selflink" id="section-8.5.1" href="#section-8.5.1">8.5.1</a>   Structure</span>

LI  DR        DST-REF   SOURCE-REF    REASON    VARIABLE  USER DATA
   10000000                                       PART

<span class="h4"><a class="selflink" id="section-8.5.2" href="#section-8.5.2">8.5.2</a>   LI</span>

             See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.5.3" href="#section-8.5.3">8.5.3</a>   Fixed Part (Octets 2 to 7)</span>

        DR                :      Disconnect Request Code:   1000

        DST-REFERENCE     :      Reference identifying the TC at
                                 the remote transport entity.

        SOURCE REFERENCE  :      Reference identifying the TC at
                                 the transport entity initiating
                                 the command.  Value zero when
                                 reference is unassigned.

        REASON            :      Defines the reason for
                                 disconnecting the TC.  This field
                                 shall take one of the following
                                 values:

                                 The following values can be used
                                 for class 1 to 4:

                                 128 + 0 - Normal disconnect</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 73
International Standards Organization


                                 initiated by session entity.

                                 128 + 1 - Remote transport entity
                                 congestion at connect request time

                                *128 + 2 - Connection negotiation failed
                                (i.e. proposed class(es) not supported).

                                 128 + 3 - Duplicated connection detected

                                 128 + 4 - Mismatched references

                                 128 + 5 - Protocol error

                                 128 + 6 - Not used

                                 128 + 7 - Reference overflow

                                 128 + 8 - Connection request refused on this
                                 network connection

                                 128 + 9 - Not used

                                 128 + 10 - Header or parameter length invalid

             The following values can be used for all classes.

                  0 -  Reason not specified

                  1 -  Congested at TSAP

                  *2   Session entity not attached to TSAP

                  *3   Address unknown

             Note:     Reasons marked with '*' may be reported to
                       the TS-user as 'persistent', other reasons
                       as 'transient'.

<span class="h4"><a class="selflink" id="section-8.5.4" href="#section-8.5.4">8.5.4</a>   Variable Part (Octets 8 to 10)</span>

        o    A parameter may be provided to allow additional
             information related to the clearing of the connection.

             Parameter code:       11100000

             Parameter Value Field:  Additional information.  This
             field is intended to be used by the transport service
             provider for internal purposes.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 74
International Standards Organization


        o    Checksum (see 8.2.3.1)

<span class="h4"><a class="selflink" id="section-8.5.5" href="#section-8.5.5">8.5.5</a>   User Data (Octets p+1 to the end)</span>

        Not allowed in class 0,

        This field may not exceed 64 octers and is used
to carry TS-User data.  The successful transfer of this data is not
guaranteed.

<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>     Disconnect Confirm (DC)</span>

        (Not used in Class 0)

<span class="h4"><a class="selflink" id="section-8.6.1" href="#section-8.6.1">8.6.1</a>   Structure</span>

        1     2         3       4       5      6        7        p
        LI             DST-REFERENCE  SOURCE-REFERENCE  Variable Part
           11000000

<span class="h4"><a class="selflink" id="section-8.6.2" href="#section-8.6.2">8.6.2</a>   LI</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.6.3" href="#section-8.6.3">8.6.3</a>   Fixed Part (Octets 2 to 6)</span>

             DC            :     Disconnect Confirm Code:  1100

             DST-REFERENCE :     See <a href="#section-8.3.3">Section 8.3.3</a>

             SOURCE-REFERENCE:   See <a href="#section-8.4.3">Section 8.4.3</a>

<span class="h4"><a class="selflink" id="section-8.6.4" href="#section-8.6.4">8.6.4</a>   Variable Part</span>

             Checksum (see 8.2.3.1)

<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>     Data (DT)</span>

<span class="h4"><a class="selflink" id="section-8.7.1" href="#section-8.7.1">8.7.1</a>   Structure</span>

             Normal Format for Class 0 to 1

        1     2          3           4         5

        LI   DT     E    TPDU-NR    User Data
           11110000 0
                    T

             Normal format for Class 2, 3 and 4
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 75
International Standards Organization


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>        2  </span>      3        4          5          6       p     p+1
LI             DST-REFERENCE    E   TPDU-NR   Variable Part  User Data
   11110000                     O
                                T

        Extended Format for optional use in Classes 2,3 and 4

        1       2      3       4     5,6,7,8    9        p p+1

        LI   DT     DST-REFERENCE  E  TPDU-NR  Variable  User Data
           11110000                O
                                   T

<span class="h4"><a class="selflink" id="section-8.7.2" href="#section-8.7.2">8.7.2</a>   LI</span>

        <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.7.3" href="#section-8.7.3">8.7.3</a>   Fixed Part</span>

        (Classes 0 to 1  : -  Octets  2 to 3; classes 2,3,4
normal format:  Octets 2 to 5; classes 2,3,4 extended format: -
Octets 2 to 8)

             DT             :    Data Transfer Code:  1111

             DST-REFERENCE  :    See <a href="#section-8.4.3">Section 8.4.3</a>

             EOT            :    When set to ONE, indicates that
                                 the current DT TPDU is the last
                                 Data Unit of a complete DT TPDU
                                 sequence (End of TSDU).

             TPDU-NR        :    TPDU Send Sequence Number (Zero in
                                 Class 0), may take any value in
                                 Class 2 without explicit flow
                                 control.

<span class="h4"><a class="selflink" id="section-8.7.4" href="#section-8.7.4">8.7.4</a>   Variable Part</span>

        Checksum (See 8.2.3.1)

<span class="h4"><a class="selflink" id="section-8.7.5" href="#section-8.7.5">8.7.5</a>   User Data Field</span>

        This field contains data of the TSDU being transmitted.
The length of this field is limited to the negotiated TPDU size for
this transport connection minus 3 octets in Classes 0 and 1,
and minus 5 octets (normal header format) or
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a> octets (extended header format) in the other classes.  </span>The
variable part, if presemt, amy further reduce the size of the user
data field.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 76
International Standards Organization


<span class="h3"><a class="selflink" id="section-8.8" href="#section-8.8">8.8</a>     Expedited Data (ED)</span>

        (Not used in Class 2 when "no explicit flow
         control" option is selected.)

<span class="h4"><a class="selflink" id="section-8.8.1" href="#section-8.8.1">8.8.1</a>   Structure</span>

        Normal Format

     1        2      3        4        EOT 5        6     p        p + 1

     LI       ED    DST-REFERENCE     EDTPDU-NR    Variable Part  User Data
           00010000                 1.

        Extended Format

     1        2        3      4        EOT 5,6,7,8  9    p          p + 1

     LI       ED     DST-REFERENCE       EDTPDU-NR  Variable Part   User Data
           00010000                    1.

<span class="h4"><a class="selflink" id="section-8.8.2" href="#section-8.8.2">8.8.2</a>   LI</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.8.3" href="#section-8.8.3">8.8.3</a>   Fixed Part</span>

        (Octets 2 to 5, normal format: 2 to 8, extended format)

        ED:            Expedited Data command code: 0001

        DST-REFERENCE: Same as <a href="#section-8.4.3">Section 8.4.3</a>

        ED TPDU-NR:    Expedited TPDU identification number
                       (Classes 1, 3, and 4; may take any value in
                       Class 2).

<span class="h4"><a class="selflink" id="section-8.8.4" href="#section-8.8.4">8.8.4</a>   Variable Part</span>

        Checksum (See 8.2.3.1)

<span class="h4"><a class="selflink" id="section-8.8.5" href="#section-8.8.5">8.8.5</a>   User Data Field</span>

        This field contains an expedited TSDU.  Up to 16 octets.

<span class="h3"><a class="selflink" id="section-8.9" href="#section-8.9">8.9</a>     Data Acknowledgement (AK)</span>

        Not applicable for Class 0 and Class 2 when the "no
explicit flow control" option is selected, and for Class 1 when the
network receipt confirmation option is selected.</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 77
International Standards Organization


        Flow Control Confirmation (class 4 only - optionally used)

        This parameter contains a copy of the information received
in an AK TPDU, to allow the transmitter of the AK TPDU to be certain
of the state of the receiving transport entity (See <a href="#section-7.4.5.6">Section 7.4.5.6</a>).

        Parameter Code:  100001011

        Parameter value field 64 bits, used as follows:

        o  Lower Window Edge (32 bits)
           Bit 32 is set to zero, bits 31 to 1 contain the
           YR-TU-NR value of the received AK TPDU.  When normal
           format is in use, only the least significant seven
           bits (bits 1 to 7) of this field are significant.

        o  Your Sub-Sequence (16 bits)
           Contains the value of the sub-sequence parameter of
           the received AK TPDU, or zero if this parameter was
           not present.

        o  Your Credit (16 bits)
           Contains the value of the CDT field of the received AK
           TPDU.  When normal format is in use, only the least
           significant four bits (bits 1 to 4) of this field are
           significant.

<span class="h3"><a class="selflink" id="section-8.10" href="#section-8.10">8.10</a>    Expedited Data Acknowledgement (EA)</span>

        (Not applicable for Class 0 and Class 2 when the no
        explicit flow control option is selected).

<span class="h4"><a class="selflink" id="section-8.10.1" href="#section-8.10.1">8.10.1</a>  Structure</span>

        Normal Format

     1       2       3       4         5               6         p

     LI      EA      DST-REFERENCE      . YR-TU-NR     Variable Part
            00100000                  0.

        Extended Format

     1      2         3       4          5,6,7,8            9      p

     LI     EA        DST-REFERENCE       . YR-TU-NR        Variable Part
           00100000                     0.

<span class="h4"><a class="selflink" id="section-8.9.1" href="#section-8.9.1">8.9.1</a>   Structure</span>
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 78
International Standards Organization


        Normal Format

      1       2          3          4         5            6       p

      LI      AK CDT     DST-REFERENCE         . YR-TU-NR  Variable Part
             0110                            0.

        Extended Format

     1      2         3       4        5,6,7,8       9,10    11    p

     LI     AK        DST-REFERENCE     . YR-TU-NR   CDT     Variable Part
           01100000                   0.

<span class="h4"><a class="selflink" id="section-8.9.2" href="#section-8.9.2">8.9.2</a>   LI</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.9.3" href="#section-8.9.3">8.9.3</a>   Fixed Part</span>

        (Octets 2 to 5, normal format:  2 to 10, extended format)

        AK:            Acknowledgement command code:  0110

        CDT:           Credit Value (set to 0 in class 1)

        DST-REFERENCE: Same as <a href="#section-8.4.3">Section 8.4.3</a>

        YR-TU-NR:      Sequence number indicating the next expected
                       DT TPDU number.

<span class="h4"><a class="selflink" id="section-8.9.4" href="#section-8.9.4">8.9.4</a>   Variable Part</span>

        Checksum (See 8.2.3.1)

        Sub-sequence number (class 4 only - optionally used).

        This parameter is used to ensure that AK TPDUs are
        processed in the correct sequence.  If it is absent, this is
        equivalent to transmitting the parameter with a value of zero.

        Parameter Code:  100001010

        Parameter Value: 16-bit sub-sequence number.

<span class="h4"><a class="selflink" id="section-8.10.2" href="#section-8.10.2">8.10.2</a>  LI</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.10.3" href="#section-8.10.3">8.10.3</a>  Fixed Part</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 79
International Standards Organization


        (Octets 2 to 5, normal format; 2 to 8, extended
        format)

        EA:            Acknowledgement command code:  0010

        DST-REFERENCE: Same as <a href="#section-8.4.3">Section 8.4.3</a>

        YR-TU-NR:      Identification of the ED TPDU being
                       acknowledged.  May take any value in Class 2.

<span class="h4"><a class="selflink" id="section-8.10.4" href="#section-8.10.4">8.10.4</a>  Variable Part</span>

        Checksum (See 8.2.3.1)

<span class="h3"><a class="selflink" id="section-8.11" href="#section-8.11">8.11</a>    Reject (RJ)</span>

        (Not used in Classes 0, 2, and 4)

<span class="h4"><a class="selflink" id="section-8.11.1" href="#section-8.11.1">8.11.1</a>  Structure</span>

        Normal Format

       1       2        3       4          EOT 5          6       p

       LI      RJ CDT   DST-REFERENCE       . YR-TU-NR    Variable Part
              0101                        0.

        Extended Format

      1        2       3        4          EOT 5,6,7,8    9,10     11      p
      LI       RJ      DST-REFERENCE        .  YR-TU-NR   CDT      Variable
              0l0l0000                                              Part

<span class="h4"><a class="selflink" id="section-8.11.2" href="#section-8.11.2">8.11.2</a>  LI</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.11.3" href="#section-8.11.3">8.11.3</a>  Fixed Part</span>

        (Octets 2 to 5, normal format; 2 to 10, extended format)

        RJ:            Reject Command Code:  0101

        CDT:           Credit Value (set to 0 in class 1)

        DST-REFERENCE: Same as <a href="#section-8.4.3">Section 8.4.3</a>

        YR-TU-NR:      Sequence number indicating the next expected
                       TPDU from which retransmission should occur.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 80
International Standards Organization


<span class="h4"><a class="selflink" id="section-8.11.4" href="#section-8.11.4">8.11.4</a>  Variable Part</span>

        No parameters exclusive to this TPDU type.

<span class="h3"><a class="selflink" id="section-8.12" href="#section-8.12">8.12</a>    TPDU Error (ERR)</span>

      1         2          3        4        5             6

      LI        ERR        DST-REFERENCE     Reject        Parameters
               01110000                      Cause

<span class="h4"><a class="selflink" id="section-8.12.1" href="#section-8.12.1">8.12.1</a>  LI</span>

        See <a href="#section-8.2.1">Section 8.2.1</a>

<span class="h4"><a class="selflink" id="section-8.12.2" href="#section-8.12.2">8.12.2</a>  Fixed Part</span>

        ERR:           TPDU Error Code: 0111

        DST-REFERENCE: Same as <a href="#section-8.4.3">Section 8.4.3</a>

        REJECT CAUSE:
                       00000000  Reason not specified

                       00000001  Invalid parameter code

                       00000010  Invalid TPDU type

                       00000011  Invalid parameter value

<span class="h4"><a class="selflink" id="section-8.12.3" href="#section-8.12.3">8.12.3</a>  Variable Part (Octets 6 to the end)</span>

        Parameter Code:  1100001

        Parameter Value Field:

        Contains the bit pattern of the rejected TPDU up to and
including the octet which caused the rejection.  This parameter is
mandatory in Class 0.

        Checksum (See <a href="#section-8.2.3.1">Section 8.2.3.1</a>)

SECTION THREE - CONFORMANCE

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.      CONFORMANCE</span>

        Implementations claiming conformance to this standard shall:

        1.   Implement either Class 0 or Class 2 or both.
</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 81
International Standards Organization


        2.   If other classes are implemented, the following rules
             shall be observed:

             a)  If Class 3 or Class 4 is implemented then Class 2
             must be implemented

             b)  If Class 1 is implemented then Class 0 must be
             implemented.

        3.   The following table defines the requirements for the
             implementation of the options defined in previous
             sections:

                                                Class
                                            0     1    2     3    4

        TPDU with Checksum                 no    no   no    no    m
        TPDU without Checksum               m     m    m     m    o

        Expedited Data Transfer            no     m    m     m    m
        No Expedited Data Transfer          m     m    m     m    m

        Flow Control in Class 2            no    no    m    no   no
        No Flow Control in Class 2         no    no    o    no   no

        7 bits format (normal)             m     m    m     m    m
        31 bits format (extended)          no    no    o     o    o

        Use of Receipt Confirmation in     no     o   no    no   no
        Class 1
        No use of Receipt Confirmation in  no     m   no    no   no
        Class 1

        Use of Network Expedited in Class  no     o   no    no   no
        1, if T-EXPEDITED DATA necessary

        No use of Network Expedited in     no     m   no    no   no
        Class 1, if T-EXPEDITED DATA necessary

        o  -  optional:     An implementation may or may not
                            provide this user-selected option.

        m  -  mandatory:    An implementation must provide for this
                            option

        no  -               An implementation shall not provide
                            this option.

        4.   Implementations claiming conformance shall support a
             TPDU length of 128 octets.  If larger maximum TPDU</pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'>ISO Transport Protocol Specification                                   Page 82
International Standards Organization


             sizes can be supported in Classes 1,2,3, or 4, then
             all permitted TPDU sizes between the maximum and 128
             octets shall be supported.

        5.   Claims of conformance shall state:

             a)  which class of protocol is supported.

             b)  which additional options indicated by the letter
             'o' in the above table are supported.
</pre>