RFC

Network Working Group
Request for Comments: 892

ISO
December 1983

ISO Transport Protocol Specification

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

0 Introduction

1 Scope and Field of Application

2 References

Section One - General

3 Definitions

4 Symbols and Abbreviations

5 Overview

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

6 Protocol Mechanisms

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

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

7 Protocol Classes

7.0 Protocol description of class 0: simple class

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

8 Encoding

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

9 Conformance

0 Introduction

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

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

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.

1 Scope and Field of Application

1.1 This International Standard Specifies:

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.

1.2 The procedures are defined in terms of:

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

ISO Transport Protocol Specification Page 5

International Standards Organization

service primitives.

1.3 This International Standard is applicable to equipment which

supports the Transport Layer of the OSI Reference Model and which wishes to interconnect in an open systems environment.

2 References

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

3 Definitions

3.1 Equipment: Hardware or software or a combination of both; it

need not be physically distinct within a computer system.

3.2 Transport service user: An abstract representation of the

totality of those entities within a single system that make use of the transport service.

3.3 Network service provider: 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.

4 Symbols and Abbreviations

4.1 Data Units

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

4.2 Types of transport protocol data units

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

4.3 TPDU fields

        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)

4.4 Parameters

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

4.5 Timer variables

        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

4.6 Other variables

        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

ISO Transport Protocol Specification Page 7

International Standards Organization

4.7 Miscellaneous

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

5 Overview of the Transport Protocol

5.1 Service Provided by the Transport Layer

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.

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

5.2 Service Assumed from the Network Layer

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.

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

5.3 Functions of the Transport Layer

5.3.1 Connection Oriented Functions

5.3.1.1 Overview of Functions

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

ISO Transport Protocol Specification Page 10

International Standards Organization

phase, and the release phase.

5.3.1.1.1 Establishment Phase

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:

Select network service which best matches the requirement of the TS-user taking into account charges for various services.
Decide whether to multiplex multiple transport connection onto a single network connection.
Establish the optimum TPDU size.
Select the functions that will be operational upon entering the data transfer phase.
Map transport addresses onto network addresses.
Provide a means to distinguish between two different transport connections.
Transportation of user's data.

5.3.1.1.2 Data Transfer Phase

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.

Concatenation and Separation

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

Segmenting and Reassembling

The splitting of a single data TSDU into multiple TPDUs which are reassembled into their original format at the destination.

ISO Transport Protocol Specification Page 11

International Standards Organization

Multiplexing and Demultiplexing

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

Splitting and Recombing

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

Flow Control

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

Error Detection

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

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.

Error Recovery

A function used to recover from detected and signalled errors.

Expedited Data

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

TSDU Delimiting

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

5.3.1.1.3 Release Phase

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

5.3.1.2 Classes and Options

ISO Transport Protocol Specification Page 12

International Standards Organization

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

Class 0: Simple Class

Class 1: Basic Error Recovery Class

Class 2: Multiplexing Class

Class 3: Error Recovery and Multiplexing Class

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.

5.3.1.2.2 Options within Classes

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

5.3.1.2.3 Negotiation

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

5.3.1.2.4 Choice of the Class of Protocol

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

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.

the quality of the available Network services;
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

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.

5.3.1.3 Potential Functions

The protocol described in this document does not include the

following set of functions which have been identified as potential

transport layer functions:

provision for encryption
provision for accounting mechanisms
provision for status exchanges and monitoring of quality of service
provision for blocking

temporary release of network connections

5.4 Model of the Transport Layer

             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

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

6 Protocol Mechanisms

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.

6.1 Assignment to Network Connection

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:

the quality of service needed for the transport connection can not be met by using or enhancing the network

ISO Transport Protocol Specification Page 15

International Standards Organization

connection.

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.

6.2 Transport Protocol Data Unit (TPDU) Transfer

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

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 section 6.4).

Primitive Applicable TPDUs Note

N-DATA CR, CC, DR, DT, ED,

AK, EA, RJ, DC, ERR

N-EXPEDITED ED, EA 1

Notes:

1 This assignment is permissible only when using class 1 and when

the network expedited variant has been agreed.

Figure 4. Network Service Primitives which can convey TPDUs.

6.3 Data TPDU Length and Segmenting

Purpose: Mapping between one TSDU and TPDUs.

TPDUs and fields used:

        -  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

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.

6.4 Concatenation and Separation

Pupose: Conveyance of multiple TPDUs in one NSDU.

Description:

All TPDUs carry in their TPDU header a length indicator (see Section 8.2.1). 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.

6.5 Connection Establishment

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

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:

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", Section 6.19).

           - 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.

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.
initial credit. Only relevant for classes which include the Explicit Flow Control Function.

ISO Transport Protocol Specification Page 19

International Standards Organization

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

The following negotiations take place:

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", Section 6.15) 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

Section 9)

If the preferred class is not selected, then on receipt of the

CC TPDU, the initiator shall adjust its functions accordingly.

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", Section 8).

sequence number length. Either normal or extended is

available. When the sequence number is extended, the credit field (if

applicable) is also extended.

checksum selection. This defines whether or not TPDUs of

the connection are to include a checksum.

version number. This defines the version of the transport

protocol standard used for this connection.

security parameter. This parameter and its semantics are

user defined.

quality of service parameter. This defines the throughput,

delay, priority and residual error rate.

The non-use of explicit flow control in class 2 is

negotiated.

ISO Transport Protocol Specification Page 20

International Standards Organization

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 Section 9.

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.

6.6 Connection Refusal

        Purpose:        Refusal of the transport connection.

TPDUs and fields used:

ISO Transport Protocol Specification Page 21

International Standards Organization

        -  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.

6.7 Release

Variants: 'implicit' or 'explicit'

Purpose: Termination of the transport connection.

Network Service Primitives:

N-DISCONNECT (implicit variant only)
N-DATA

TPDUs and fields used:

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

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.

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.

6.8 Implicit Termination

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 Section 6.19). 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).

6.9 Spurious Disconnect

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

TPDUs and fields used:

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.

6.10 Data TPDU Numbering

Variants: 'normal' or 'extended'

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

TPDUs and Fields Used:

        - 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'.

6.11 Expedited Data Transfer

Variants: 'network expedited' or not

Purpose: Provision of the expedited data service

ISO Transport Protocol Specification Page 24

International Standards Organization

Network Service Primitives:

N-DATA
N-EXPEDITED DATA

TPDUs and Fields Used:

        - ED TPDU-NR (7 or 31 bits)

        - 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.

6.12 Reassignment

Purpose: Assignment of a Transport Connection to a different

Network Connection.

TPDUs and Fields Used:

        - 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

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.

6.13 Reassignment After Failure

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.

6.14 Retention Until Acknowledgement of TPDUs

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

ISO Transport Protocol Specification Page 26

International Standards Organization

RJ, AK, EA

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

        - TPDU-NR (7 or 31 bits)

        - 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

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

6.15 Resynchronization

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 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)

ISO Transport Protocol Specification Page 28

International Standards Organization

if a CR is retained then retransmit it.
if a DR is retained then retransmit it.
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.

if the first received TPDU os a DR, then transmit a DC TPDU.
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.

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

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.

6.16 Multiplexing and Demultiplexing

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.

6.17 Explicit Flow Control

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)

        - TPDU-NR (7 or 31 bits)

AK, RJ

        - YR-TU-NR (7 or 31 bits)
        - subsequence number (optional)
        - flow control confirmation (optional)

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.

6.18 Checksum

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.

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.

6.19 Frozen References

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

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.

6.20 Retransmission on Timeout

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.

6.21 Resequencing

Purpose: To cope with misordering of TPDUs by the network

service provider.

TPDUs and Field Used:

        - TPDU NR

        - ED TPDU NR

Description:

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

6.22 Inactivity Control

Purpose: To cope with unsignalled termination of a network

connection.

TPDUs and Fields Used:

Description:

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

6.23 Treatment of Protocol Errors

Purpose: To deal with invalid TPDUs.

ISO Transport Protocol Specification Page 33

International Standards Organization

TPDUs and Fields Used:

ERR

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

        - 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 6.6 and 7.0.7).

6.24 Splitting and Recombining

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 Section 6.1) to multiple network connections. TPDUs for the

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 Section 6.21) 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

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.

7 PROTOCOL CLASSES

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)

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.

7.0 PROTOCOL DESCRIPTION OF CLASS 0: SIMPLE CLASS

7.0.1 Characteristics of Class 0

The characteristic of this class is that it provides

the simplest type of transport connection and fully compatible

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.).

7.0.2 Functions of Class 0

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.

7.0.3 Protocol Mechanisms of Class 0

7.0.3.1 Connection Establishment Phase

Connection shall be made in accordance with the

general rules (Assignment of Network Connection, Connection

Establishment and Connection Refusal) with the following

restrictions:

No exchange of user data is allowed.
Only TSAP-ID and TPDU size parameters are allowed.

7.0.3.2 Data Transfer Phase

Segmenting (DT TDPU length and Segmenting)
Detection and indication of procedural errors.

7.0.3.3 Release Phase

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.

7.0.4 Connection Establishment for Class 0

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.

ISO Transport Protocol Specification Page 37

International Standards Organization

7.0.5 Data Transfer Procedures

7.0.5.1 General

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.

7.0.5.2 Transport Data TPDU maximum length

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 Section 8.3 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.

7.0.6 Release Procedure

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

7.0.7 Treatment of invalid TPDUs

The "treatment of protocol errors' function is used.

7.0.8 Behaviour after an error signalled by the network service.

The implicit termination function is used and the

high layer is informed about this disconnection.

7.0.9 Supported Options

None

7.1 PROTOCOL DESCRIPTION OF CLASS 1: BASIC ERROR RECOVERY CLASS

7.1.1 Characteristics of Class 1

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

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.

7.1.2 Functions of Class 1

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.

7.1.3 Protocol Mechanisms of Class 1

Class 1 protocol mechanisms include Class 0

protocol mechanisms plus the following:

7.1.3.1 User Data in the Connection Phase

Class 1 provides the possibility of conveying

data in the connection request and confirm commands.

7.1.3.2 Numbering of Data TPDU

Each Data TPDU transmitted between transport entities for

each direction of transmission in a transport connection is

sequentially numbered.

7.1.3.3 Release

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

7.1.3.4 Error Recovery

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 Section 6.15).

7.1.3.5 Acknowledgement

Acknowledgements are used to release copies of retained TPDUs.

ISO Transport Protocol Specification Page 39

International Standards Organization

Two methods of acknowledgment are provided in the Retention until

Acknowledgement of TPDUs function:

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).

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.

7.1.4 Connection Establishment Procedures for Class 1

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:

Reassignment after failure

Retention until Acknowledgement of TPDUs

Resynchronization

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

acknowledged.

7.1.5 Data Transfer Phase

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.

7.1.5.1 Behaviour after an error

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

ISO Transport Protocol Specification Page 40

International Standards Organization

Connection.

7.1.5.2 Procedure for Expedited Data Transfer

The Expedited Data Transfer mechanism is used.

Two methods are possible to provide the function:

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.

network expedited variant

Note: (1) The use of this method is

determined through negotiation during transport connection

establishment.

7.1.6 Release Procedures

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.

7.1.7 Treatment of Unknown TPDUs

The 'Treatment of Protocol Errors' mechanism is used.

7.1.8 Supported Options

Use of network receipt confirmation.

Use of network expedited.

7.2 PROTOCOL DESCRIPTION OF CLASS 2: MULTIPLEXING CLASS

7.2.1 Characteristics of Class 2

The characteristic of this class is to provide a

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.

7.2.2 Functions of Class 2

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.

7.2.3 Protocol Mechanisms of Class 2

7.2.3.1 Connection Establishment Phase

The connection establishment function shall be used.

7.2.3.1.1 User Data in the Connection Phase

Class 2 provides the possibility to convey data in the

connection request and confirm commands.

7.2.3.2 Connection Identification

In Class 2 each TPDU conveys a Destination Reference.

ISO Transport Protocol Specification Page 42

International Standards Organization

This uniquely identifies the transport connection within the

receiving transport entity and thus allows multiplexing.

7.2.3.3 Release Phase

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.

7.2.3.4 Protocol Mechanisms when Explicit Flow Control is used.

The following mechanisms are provided:

7.2.3.4.1 Numbering of Data TPDU

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).

7.2.3.4.2 Flow Control Principles

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 Section

7.2.5.5.3

7.2.3.4.3 Expedited Flow

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

ISO Transport Protocol Specification Page 43

International Standards Organization

data will arrive after the expedited data.

7.2.4 Connection Establishment Procedures for Class 2

7.2.4.1 References

See Section 6.5 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.

7.2.4.2 Connection Eastablishment

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.

7.2.5 Data Transfer Procedures for Class 2

The data transfer procedures described in the

following section apply independently to each transport connection

existing between two transport entities.

7.2.5.1 TPDU Maximum Length and Segmenting

The general rules defined in Section 6.3 apply.

7.2.5.2 Concatenation

The general rules defined in Section 6.4 apply.

7.2.5.3 Sending Data TPDU (No Explicit Flow Control Option)

In this case the data TPDU is built in accordance

with the rules stated in Section 6.2 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.

7.2.5.4 Sending Data TPDU (When Explicit Flow Control is Used)

On each transport connection the transmission of Data

TPDUs is controlled separately for each direction and is based on

authorization from the receiver.

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..

7.2.5.4.1 Numbering of Data TPDUs

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:

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)

ISO Transport Protocol Specification Page 45

International Standards Organization

7.2.5.4.2 Window Definition

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.

7.2.5.4.3 Flow Control

Flow control is performed as follows:

initialization time

           Lower window edge = 0

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

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.

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.

ISO Transport Protocol Specification Page 46

International Standards Organization

7.2.5.4.4 Reducing the Upper Window Edge

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) > N

is a protocol error

Provided the previous statements are respected, CDT

field may take any value including zero.

7.2.5.4.5 Procedure for Expedited Data Transfer

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.

7.2.6 Release Procedures for Class 2

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.

7.2.7 Treatment of Invalid TPDUs

ISO Transport Protocol Specification Page 47

International Standards Organization

The 'Treatment of Protocol Error' mechanism in Section

6.23 is used.

7.2.8 Behaviour after an Error signalled by the Network Layer.

The implicit termination mechanism is used.

7.2.9 Supported Options

Non use of explicit flow control.
Extended formats.

7.3 PROTOCOL DESCRIPTION OF CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS

7.3.1 Characteristics of Class 3

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.

7.3.2 Functions of Class 3

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.

7.3.3 Protocol Mechanisms of Class 3

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.

7.3.3.1 Error Recovery Principles

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.

ISO Transport Protocol Specification Page 48

International Standards Organization

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

7.3.3.2 Relationship between Flow Control and Error Recovery

        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.

7.3.4 Connection Establishment Procedure for Class 3

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.

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.
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).

7.3.5 Data Transfer Procedures for Class 3

7.3.5.1 Acknowledgement

The 'AK' variant of the Retention until

Acknowledgement of TPDUs function is used.

7.3.5.2 Retransmission Procedure

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

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.

7.3.5.3 Reducing the upper window edge

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.

7.3.5.4 Behaviour after an error signalled by the network layer

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.

7.3.5.5 Procedure for Expedited Data Transfer

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

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.

7.3.6 Release Procedures for Class 3

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.

7.3.7 Treatment of Invalid TPDUs

The 'Treatment of Protocol Errors' mechanism is used.

7.3.8 Supported Options

Extended formats.

7.4 PROTOCOL DESCRIPTION OF CLASS 4: ERROR DETECTION AND RECOVERY CLASS

7.4.1 Characteristics of Class 4

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.

7.4.2 Functions of Class 4

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.

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.

7.4.3 Protocol Mechanisms of Class 4

7.4.3.1 Network Service Data Unit Lifetime

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.

7.4.3.2 Average Transit Delay

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.

7.4.3.3 Remote Acknowledge Time Assumptions

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.

7.4.3.4 Local Retransmission Time

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.

ISO Transport Protocol Specification Page 52

International Standards Organization

7.4.3.5 Persistence Time

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.

7.4.3.6 Bound on Reference Identifier and Sequence Numbers

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).

7.4.3.7 Inactivity Time

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.

7.4.3.8 Window Time

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.

7.4.3.9 Class 4 Error Recovery Principles

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.

7.4.3.10 Relationship of Times and Intervals

The following note describes the relationship between

the time described in Section 7.4.3.1 - 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

                            *
                            M
             L              *

                            A                =2*M  +  A   + R
                             R                         R

                            *
                            M

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<<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)

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

t t

7.4.3.11 Sequence Numbering

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.

7.4.4 Procedures for Connection Establishment Phase

The following features pertain to connection

establishment for Class 4:

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

ISO Transport Protocol Specification Page 55

International Standards Organization

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

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.
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.
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.

7.4.4.1 Connection Request

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 section 7.4.3.6).

7.4.4.2 Incomimg Connection Request

An incoming connection request is processed as for Class 3

7.4.4.3 Connection Confirm

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 Section 7.4.3.9

7.4.4.4 Incoming Connection Confirm

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 Section 7.4.5.3.

ISO Transport Protocol Specification Page 56

International Standards Organization

7.4.4.5 Incoming Acknowledgement

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 Section 7.4.5.8).

7.4.4.6 Unsuccessful Connection

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 Section 7.4.6.1).

7.4.4.7 Initial Credit Allocation

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