Network Working Group ISO

Request for Comments: 905 April 1984

ISO Transport Protocol Specification

ISO DP 8073

   Status of this Memo:       
   
     This document is distributed as an RFC for information only.   It
     does not specify a standard for the ARPA-Internet.

Notes:

     1)  RFC 892 is an older version of  the  ISO  Transport  Protocol
         Specification.   Therefore  this  RFC  should  be  assumed to
         supercede RFC 892.
     
     2)  This document has been  prepared  by  retyping  the  text  of
         ISO/TC97/SC16/N1576  and  then  applying  proposed  editorial
         corrections  contained  in  ISO/TC97/SC16/N1695.   These  two
         documents,  taken  together, are undergoing voting within ISO
         as a Draft International Standard (DIS).
     
     3)  Although this RFC has been  reviewed  after  typing,  and  is
         believed  to  be  substantially  correct, it is possible that
         typographic errors not present in the ISO documents have been
         overlooked.

Alex McKenzie
BBN

Table of Contents

     1   SCOPE AND FIELD OF APPLICATION........................ 3
     1.1   This International Standard specifies:.............. 3
     1.2   The procedures are defined in terms of:............. 4
     1.3   .................................................... 4
     1.4   .................................................... 5
     2   REFERENCES............................................ 5
     3   DEFINITIONS........................................... 6
     3.1   .................................................... 6
     3.2   .................................................... 6
     3.2.1   equipment:........................................ 7
     3.2.2   transport service user:........................... 7
     3.2.3   network service provider:......................... 7
     3.2.4   local matter:..................................... 7
     3.2.5   initiator:........................................ 7
     3.2.6   responder:........................................ 8
     3.2.7   sending transport entity:......................... 8
     3.2.8   receiving transport entity:....................... 8
     3.2.9   preferred class:.................................. 8
     3.2.10   alternative class:............................... 8
     3.2.11   proposed class:.................................. 9
     3.2.12   selected class:.................................. 9
     3.2.13   proposed parameter:.............................. 9
     3.2.14   selected parameter:.............................. 9
     3.2.15   error indication:................................ 9
     3.2.16   invalid TPDU:................................... 10
     3.2.17   protocol error:................................. 10
     3.2.18   sequence number:................................ 10
     3.2.19   transmit window:................................ 10
     3.2.20   lower window edge:.............................. 11
     3.2.21   upper window edge:.............................. 11
     3.2.22   upper window edge allocated to  the  peer
       entity:
          .................................................... 11
     3.2.23   closed window:.................................. 11
     3.2.24   window information:............................. 11
     3.2.25   frozen reference:............................... 12
     3.2.26   unassigned reference:........................... 12
     3.2.27   transparent (data):............................. 12

i

     3.2.28   owner (of a network connection):................ 12
     3.2.29   retained TPDU:.................................. 12
     4   SYMBOLS AND ABBREVIATIONS............................ 13
     4.1   Data units......................................... 13
     4.2   Types of transport protocol data units............. 13
     4.3   TPDU fields........................................ 13
     4.4   Times and associated variables..................... 14
     4.5   Miscellaneous...................................... 14
     5   OVERVIEW OF THE TRANSPORT PROTOCOL................... 15
     5.1   Service provided by the transport layer............ 15
     5.2   Service assumed from the network layer............. 16
     5.3   Functions of the Transport Layer................... 18
     5.3.1   Overview of functions............................ 18
     5.3.1.1   Functions used at all times.................... 19
     5.3.1.2   Connection Establishment....................... 19
     5.3.1.3   Data Transfer.................................. 20
     5.3.1.4   Release........................................ 21
     5.4   Classes and options................................ 21
     5.4.1   General.......................................... 21
     5.4.2   Negotiation...................................... 22
     5.4.3   Choice of network connection..................... 22
     5.4.4   Characteristics of Class 0....................... 23
     5.4.5   Characteristics of Class 1....................... 23
     5.4.6   Characteristics of Class 2....................... 24
     5.4.6.1   General........................................ 24
     5.4.6.2   Use of explicit flow control................... 24
     5.4.6.3   Non-use of explicit flow control............... 24
     5.4.7   Characteristics of Class 3....................... 24
     5.4.8   Characteristics of Class 4....................... 25
     5.5   Model of the transport layer....................... 25
     6   ELEMENTS OF PROCEDURE................................ 27
     6.1   Assignment to network connection................... 27
     6.1.1   Purpose.......................................... 27
     6.1.2   Network service primitives....................... 27
     6.1.3   Procedure........................................ 28
     6.2   Transport protocol data unit (TPDU) transfer....... 29
     6.2.1   Purpose.......................................... 29
     6.2.2   Network Service Primitives....................... 30
     6.2.3   Procedure........................................ 30
     6.3   Segmenting and reassembling........................ 30
     6.3.1   Purpose.......................................... 30
     6.3.2   TPDUs and parameter used......................... 31
     6.3.3   Procedure........................................ 31

ii

     6.4   Concatenation and separation....................... 31
     6.4.1   Purpose.......................................... 31
     6.4.2   Procedure........................................ 32
     6.5   Connection establishment........................... 32
     6.5.1   Purpose.......................................... 32
     6.5.2   Network service primitives....................... 33
     6.5.3   TPDUs and parameters used........................ 33
     6.5.4   Procedure........................................ 34
     6.6   Connection refusal................................. 40
     6.6.1   Purpose.......................................... 40
     6.6.2   TPDUs and parameters used........................ 40
     6.6.3   Procedure........................................ 41
     6.7   Normal release..................................... 41
     6.7.1   Purpose.......................................... 41
     6.7.2   Network service primitives....................... 42
     6.7.3   TPDUs and parameters used........................ 42
     6.7.4   Procedure for implicit variant................... 43
     6.7.5   Procedure for explicit variant................... 43
     6.8   Error Release...................................... 44
     6.8.1   Purpose.......................................... 45
     6.8.2   Network service primitives....................... 45
     6.8.3   Procedure........................................ 45
     6.9    Association   of   TPDUs   with   transport
       connections
          .................................................... 45
     6.9.1   Purpose.......................................... 45
     6.9.2   Network service primitives....................... 46
     6.9.3   TPDUs and parameters uses........................ 46
     6.9.4   Procedures....................................... 46
     6.9.4.1   Identification of TPDUs........................ 46
     6.9.4.2   Association of individual TPDUs................ 47
     6.10   Data TPDU numbering............................... 49
     6.10.1   Purpose......................................... 49
     6.10.2   TPDUs and parameters used....................... 49
     6.10.3   Procedure....................................... 50
     6.11   Expedited data transfer........................... 50
     6.11.1   Purpose......................................... 50
     6.11.2   Network service primitives...................... 50
     6.11.3   TPDUs and parameter used........................ 51
     6.11.4   Procedures...................................... 51
     6.12   Reassignment after failure........................ 52
     6.12.1   Purpose......................................... 52
     6.12.2   Network service primitives...................... 52

iii

     6.12.3   Procedure....................................... 52
     6.12.4   Timers.......................................... 54
     6.13   Retention until acknowledgement of TPDUs.......... 56
     6.13.1   Purpose......................................... 56
     6.13.2   Network service primitives...................... 56
     6.13.3   TPDUs and parameters used....................... 56
     6.13.4   Procedures...................................... 57
     6.14   Resynchronization................................. 60
     6.14.1   Purpose......................................... 60
     6.14.2   Network service primitives...................... 60
     6.14.3   TPDUs and parameters used....................... 60
     6.14.4   Procedure....................................... 61
     6.14.4.1   Active resynchronization procedures........... 61
     6.14.4.2   Passive resynchronization procedures.......... 62
     6.14.4.3   Data Resynchronization Procedures............. 63
     6.15   Multiplexing and demultiplexing................... 64
     6.15.1   Purpose......................................... 64
     6.15.2   TPDUs and parameters used....................... 64
     6.15.3   Procedure....................................... 65
     6.16   Explicit Flow Control............................. 65
     6.16.1   Purpose......................................... 65
     6.16.2   TPDUs and parameters used....................... 65
     6.16.3   Procedure....................................... 66
     6.17   Checksum.......................................... 66
     6.17.1   Purpose......................................... 66
     6.17.2   TPDUs and parameters used....................... 66
     6.17.3   Procedure....................................... 67
     6.18   Frozen references................................. 68
     6.18.1   Purpose......................................... 68
     6.18.2   Procedure....................................... 68
     6.18.2.1   Procedure for classes 0 and 2................. 68
     6.18.2.2   Procedure for classes 1 and 3................. 69
     6.18.2.3   Procedure for classes 4....................... 70
     6.19   Retransmission on time-out........................ 70
     6.19.1   Purpose......................................... 70
     6.19.2   TPDUs used...................................... 70
     6.19.3   Procedure....................................... 70
     6.20   Resequencing...................................... 70
     6.20.1   Purpose......................................... 71
     6.20.2   TPDUs and parameters used....................... 71
     6.20.3   Procedure....................................... 71
     6.21   Inactivity control................................ 71
     6.21.1   Purpose......................................... 71

iv

     6.21.2   Procedure....................................... 72
     6.22   Treatment of protocol errors...................... 72
     6.22.1   Purpose......................................... 72
     6.22.2   TPDUs and parameters used....................... 72
     6.22.3   Procedure....................................... 72
     6.23   Splitting and recombining......................... 74
     6.23.1   Purpose......................................... 74
     6.23.2   Procedure....................................... 74
     7   Protocol Classes..................................... 76
     8   SPECIFICATION FOR CLASS 0. SIMPLE CLASS.............. 79
     8.1   Functions of class 0............................... 79
     8.2   Procedures for class 0............................. 79
     8.2.1   Procedures applicable at all times............... 79
     8.2.2   Connection establishment......................... 79
     8.2.3   Data transfer.................................... 80
     8.2.4   Release.......................................... 80
     9    SPECIFICATION  FOR  CLASS  1:   BASIC   ERROR
       RECOVERY CLASS
          .................................................... 81
     9.1   Functions of Class 1............................... 81
     9.2   Procedures for Class 1............................. 81
     9.2.1   Procedures applicable at all times............... 81
     9.2.2   Connection establishment......................... 82
     9.2.3   Data Transfer.................................... 82
     9.2.3.1   General........................................ 82
     9.2.3.2   Expedited Data................................. 83
     9.2.4   Release.......................................... 84
     10   SPECIFICATION  FOR  CLASS  2  -  MULTIPLEXING
       CLASS
          .................................................... 85
     10.1   Functions of class 2.............................. 85
     10.2   Procedures for class 2............................ 85
     10.2.1   Procedures applicable at all times.............. 85
     10.2.2   Connection establishment........................ 86
     10.2.3   Data transfer when non  use  of  explicit
       flow control
          .................................................... 86
     10.2.4   Data transfer when use of  explicit  flow
       control
          .................................................... 86
     10.2.4.1   General....................................... 86
     10.2.4.2   Flow control.................................. 87
     10.2.4.3   Expedited data................................ 88

v

     10.2.5   Release......................................... 89
     11   SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND
       MULTIPLEXING CLASS
          .................................................... 90
     11.1   Functions of Class 3.............................. 90
     11.2   Procedures for Class 3............................ 90
     11.2.1   Procedures applicable at all times.............. 90
     11.2.2   Connection Establishment........................ 91
     11.2.3   Data Transfer................................... 91
     11.2.3.1   General....................................... 91
     11.2.3.2   Use of RJ TPDU................................ 92
     11.2.3.3   Flow Control.................................. 93
     11.2.3.4   Expedited data................................ 93
     11.2.4   Release......................................... 94
     12   SPECIFICATION FOR CLASS  4:  ERROR  DETECTION
       AND RECOVERY CLASS
          .................................................... 95
     12.1   Functions of Class 4.............................. 95
     12.2   Procedures for Class 4............................ 95
     12.2.1   Procedures available at all times............... 95
     12.2.1.1   Timers used at all times...................... 95
     12.2.1.1.1   NSDU lifetime (MLR, MRL).................... 98
     12.2.1.1.2   Expected maximum transit delay  (ELR,
       ERL)
          .................................................... 98
     12.2.1.1.3   Acknowledge Time (AR, AL)................... 99
     12.2.1.1.4   Local retransmission time (T1).............. 99
     12.2.1.1.5   Persistence Time (R)........................ 99
     12.2.1.1.6    Bound  on  References  and  Sequence
       Numbers (L)
          ................................................... 100
     12.2.1.2   General Procedures........................... 100
     12.2.2   Procedures for Connection Establishment........ 102
     12.2.2.1   Timers used in Connection Establishment...... 102
     12.2.2.2   General Procedures........................... 103
     12.2.3   Procedures for Data Transfer................... 104
     12.2.3.1   Timers used in Data Transfer................. 104
     12.2.3.2   General Procedures for data transfer......... 104
     12.2.3.3   Inactivity Control........................... 105
     12.2.3.4   Expedited Data............................... 105
     12.2.3.5   Resequencing................................. 106
     12.2.3.6   Explicit Flow Control........................ 107
     12.2.3.7   Sequencing of received AK TPDUs.............. 108

vi

     12.2.3.8   Procedure for transmission of AK TPDUs....... 109
     12.2.3.8.1   Retransmission of AK TPDUs for window
       synchronization
          ................................................... 109
     12.2.3.8.2   Sequence control for transmission  of
       AK TPDUs
          ................................................... 109
     12.2.3.8.3   Retransmission of AK TPDUs after  CDT
       set to zero
          ................................................... 110
     12.2.3.8.4   Retransmission  procedures  following
       reduction of the
          ................................................... 111
     12.2.3.9    Use  of  Flow   Control   Confirmation
       parameter
          ................................................... 112
     12.2.4   Procedures for Release......................... 113
     12.2.4.1   Timers used for Release...................... 113
     12.2.4.2   General Procedures for Release............... 113
     13   STRUCTURE AND ENCODING OF TPDUs.................... 114
     13.1   Validity......................................... 114
     13.2   Structure........................................ 116
     13.2.1   Length indicator field......................... 117
     13.2.2   Fixed part..................................... 117
     13.2.2.1   General...................................... 117
     13.2.2.2   TPDU code.................................... 117
     13.2.3   Variable part.................................. 118
     13.2.3.1   Checksum Parameter (Class 4 only)............ 120
     13.2.4   Data Field..................................... 120
     13.3   Connection Request (CR) TPDU..................... 120
     13.3.1   Structure...................................... 120
     13.3.2   LI............................................. 121
     13.3.3   Fixed Part (Octets 2 to 7)..................... 121
     13.3.4   Variable Part (Octets 8 to p).................. 122
     13.3.5   User Data (Octets p+1 to the end).............. 127
     13.4   Connection Confirm (CC) TPDU..................... 128
     13.4.1   Structure...................................... 128
     13.4.2   LI............................................. 128
     13.4.3   Fixed Part (Octets 2 to 7)..................... 128
     13.4.4   Variable Part (Octet 8 to p)................... 129
     13.4.5   User Data (Octets p+1 to the end).............. 129
     13.5   Disonnect Request (DR) TPDU...................... 129
     13.5.1   Structure...................................... 129

vii

     13.5.2   LI............................................. 129
     13.5.3   Fixed Part (Octets 2 to 7...................... 130
     13.5.4   Variable Part (Octets 8 to p).................. 131
     13.5.5   User Data (Octets p+1 to the end).............. 131
     13.6   Disconnect Confirm (DC) TPDU..................... 132
     13.6.1   Structure...................................... 132
     13.6.2   LI............................................. 132
     13.6.3   Fixed Part (Octets 2 to 6)..................... 132
     13.6.4   Variable Part.................................. 133
     13.7   Data (DT) TPDU................................... 133
     13.7.1   Structure...................................... 133
     13.7.2   LI............................................. 134
     13.7.3   Fixed Part..................................... 134
     13.7.4   Variable Part.................................. 135
     13.7.5   User Data Field................................ 135
     13.8   Expedited Data (ED) TPDU......................... 135
     13.8.1   Structure...................................... 135
     13.8.2   LI............................................. 136
     13.8.3   Fixed Part..................................... 136
     13.8.4   Variable Part.................................. 137
     13.8.5   User Data Field................................ 137
     13.9   Data Acknowledgement (AK) TPDU................... 137
     13.9.1   Structure...................................... 137
     13.9.2   LI............................................. 138
     13.9.3   Fixed Part..................................... 138
     13.9.4   Variable Part.................................. 139
     13.10   Expedited Data Acknowledgement (EA) TPDU........ 140
     13.10.1   Structure..................................... 140
     13.10.2   LI............................................ 141
     13.10.3   Fixed Part.................................... 141
     13.10.4   Variable Part................................. 141
     13.11   Reject (RJ) TPDU................................ 141
     13.11.1   Structure..................................... 142
     13.11.2   LI............................................ 142
     13.11.3   Fixed Part.................................... 142
     13.11.4   Variable Part................................. 143
     13.12   TPDU Error (ER) TPDU............................ 143
     13.12.1   Structure..................................... 143
     13.12.2   LI............................................ 143
     13.12.3   Fixed Part.................................... 144
     13.12.4   Variable Part................................. 144
     14   CONFORMANCE........................................ 145
     14.1   ................................................. 145

viii

     14.2   ................................................. 145
     14.3   ................................................. 145
     14.4   ................................................. 145
     14.5   ................................................. 146
     14.6   Claims of Conformance Shall State................ 146

ix

     INTRODUCTION
     
     The Transport Protocol Standard is one of a set of  International
     Standards  produced to facilitate the interconnection 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 Service Standard (DP 8072).  It also uses and makes
     reference  to  the  Network  Service  Standard  (DP  8348), whose
     provisions it  assumes  in  order  to  accomplish  the  transport
     protocol's  aims.   The  interelationship  of  these standards is
     depicted in figure 1.
     
     -------------------------TRANSPORT SERVICE DEFINITION------------
     Transport     | --- Reference to aims --------------
     Protocol      |
     Specification | --- Reference to assumptions -------
     -------------------------NETWORK SERVICE DEFINITION--------------

Relationaship between Transport Protocol and adjacent services

Figure 1 .

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

1

     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 defines mechanisms that  can  be  used  to
     optimize  network  tariffs and enhance the following qualities of
     service:

a) different throughput rates;

b) different error rates;

        c)  integrity of data requirements;

d) reliability requirements.

     It does not  require  an  implementation  to  use  all  of  these
     mechanisms,  nor  does  it  define methods for measuring achieved
     quality of service or  criteria  for  deciding  when  to  release
     transport connections following quality of service degradation.
     
     The primary aim of this International Standard is  to  provide  a
     set  of  rules  for  communication  expressed  in  terms  of  the
     procedures to be carried out by peer  entities  at  the  time  of
     communication.   These  rules  for  communication are intended to
     provide a sound basis for development in order to serve a variety
     of purposes:

a) as a guide for implementors and designers;

b) for use in the testing and procurement of equipment;

c) as part of an agreement for the admittance of systems into

the open systems environment;

d) as a refinement of the understanding of OSI.

     It is expected  that  the  initial  users  of  the  International
     Standard  will be designers and implementors of equipment and the
     International Standard contains, in notes or in annexes, guidance
     on the implementation of the procedures defined in the standard.

2

     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 International Standard correctly under
     all circumstances.   It  is  possible  by  means  of  testing  to
     establish  confidence  that  an implementation correctly operates
     the protocol in a representative sample of circumstances.  It is,
     however, intended that this International 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.
     
     This International Standard contains a section on conformance  of
     equipment   claiming   to   implement   the  procedures  in  this
     International Standard.  Attention is drawn to the fact that  the
     standard   does   not  contain  any  tests  to  demonstrate  this
     conformance.
     
     The variations and options available  within  this  International
     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
     International 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 and multiplexing class; 5) Class 4. Error detection and recovery class,

3

            for the connection oriented 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 structure and encoding of the transport protocol  data
            units   used   for   the  transfer  of  data  and  control
            information;
     
     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
            service primitives.
     
     These procedures are defined in the main  text  of  the  standard
     supplemented by state tables in annex A.
     
     1.3
     
     These procedures are applicable  to  instances  of  communication
     between  systems  which  support  the  Transport Layer of the OSI
     Reference Model and which wish to interconnect in an open systems
     environment.

4

     1.4
     
     This   International   Standard   also   specifies    conformance
     requirements  for systems implementing these procedures.  It does
     not  contain  tests  which  can  be  used  to  demonstrate   this
     conformance.
     
     2  REFERENCES
     
     ISO 7498  Information   processing   systems   -   Open   systems
               interconnection - Basic Reference Model
     
     DP 8072   Information   processing   systems   -   Open   systems
               interconnection - Transport service definition
     
     DP 8348   Information   processing   systems   -   Open   systems
               interconnection  -  Connection-oriented network service
               definition.

5

SECTION ONE. GENERAL

     3  DEFINITIONS
     
     NOTE - The definitions contained  in  this  clause  make  use  of
     abbreviations defined in clause 4.
     
     3.1
     
     This International Standard is based on the concepts developed in
     the  Reference  Model for Open Systems Interconnection (DIS 7498)
     and makes use of the following terms defined in that standard:

a) concatenation and separation;

b) segmenting and reassembling;

c) multiplexing and demultiplexing;

d) splitting and recombining;

e) flow control.

     3.2
     
     For the purpose of this  International  Standard,  the  following
     definitions apply:

6

     3.2.1  equipment:
     
     Hardware or software or a combination of both;  it  need  not  be
     physically distinct within a computer system.
     
     3.2.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.2.3  network service provider:
     
     An abstract machine that models  the  totality  of  the  entities
     providing the network service, as viewed by a transport entity.
     
     3.2.4  local matter:
     
     A decision made by  a  system  concerning  its  behavior  in  the
     Transport  Layer  that is not subject to the requirements of this
     protocol.
     
     3.2.5  initiator:

A transport entity that initiates a CR TPDU.

7

     3.2.6  responder:
     
     A transport entity with whom an initiator wishes to  establish  a
     transport connection.
     
     NOTE - Initiator and responder are  defined  with  respect  to  a
     single  transport  connection.  A transport entity can be both an
     initiator and responder simultaneously.
     
     3.2.7  sending transport entity:

A transport entity that sends a given TPDU.

     3.2.8  receiving transport entity:

A transport entity that receives a given TPDU.

     3.2.9  preferred class:
     
     The protocol class that the initiator indicates in a CR  TPDU  as
     its first choice for use over the transport connection.
     
     3.2.10  alternative class:
     
     A protocol class that the initiator indicates in a CR TPDU as  an
     alternative choice for use over the transport connection.

8

     3.2.11  proposed class:

A preferred class or an alternative class.

     3.2.12  selected class:

The protocol class that the responder indicates in a CC TPDU that it has chosen for use over the transport connection.

     3.2.13  proposed parameter:
     
     The value for a parameter that the initiator indicates  in  a  CR
     TPDU that it wishes to use over the transport connection.
     
     3.2.14  selected parameter:
     
     The value for a parameter that the responder indicates  in  a  CC
     TPDU that it has chosen for use over the transport connection.
     
     3.2.15  error indication:
     
     An N-RESET indication,  or  an  N-DISCONNECT  indication  with  a
     reason code indicating an error, that a transport entity receives
     from the NS-provider.

9

     3.2.16  invalid TPDU:
     
     A TPDU that  does  not  comply  with  the  requirements  of  this
     International Standard for structure and encoding.
     
     3.2.17  protocol error:
     
     A TPDU whose use does not comply  with  the  procedures  for  the
     class.
     
     3.2.18  sequence number:
     
        a)  The number  in  the  TPDU-NR  field  of  a  DT  TPDU  that
            indicates  the  order in which the DT TPDU was transmitted
            by a transport entity.
     
        b)  The number in the YR-TU-NR field of an AK or RJ TPDU  that
            indicates the sequence number of the next DT TPDU expected
            to be received by a transport entity.
     
     3.2.19  transmit window:
     
     The set of consecutive sequence numbers which a transport  entity
     has been authorized by its peer entity to send at a given time on
     a given transport connection.

10

     3.2.20  lower window edge:

The lowest sequence number in a transmit window.

     3.2.21  upper window edge:
     
     The sequence  number  which  is  one  greater  than  the  highest
     sequence number in the transmit window.
     
     3.2.22  upper window edge allocated to the peer entity:

The value that a transport entity communicates to its peer entity to be interpreted as its new upper window edge.

     3.2.23  closed window:

A transmit window that contains no sequence number.

     3.2.24  window information:
     
     Information contained in a TPDU relating to  the  upper  and  the
     lower window edges.

11

     3.2.25  frozen reference:
     
     A reference that is not available for assignment to a  connection
     because of the requirements of 6.18.
     
     3.2.26  unassigned reference:
     
     A reference that is neither currently in use  for  identifying  a
     transport connection or which is in a frozen state.
     
     3.2.27  transparent (data):
     
     TS-user  data  that  is  transferred  intact  between   transport
     entities  and  which  is  unavailable  for  use  by the transport
     entities.
     
     3.2.28  owner (of a network connection):

The transport entity that issued the N-CONNECT request leading to the creation of that network connection.

     3.2.29  retained TPDU:
     
     A TPDU  that  is  subject  to  the  retransmission  procedure  or
     retention  until  acknowledgement  procedure and is available for
     possible retransmission.

12

     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
     
        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          Reject TPDU
        ER 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)
        SRC-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)
        YR-EDTU-NR       ED TPDU number response (field)

13

     4.4  Times and associated variables
     
        T1               Elapsed time between retransmissions
        N                The maximum number of transmissions
        L                Bound on reference
        I                Inactivity time
        W                Window time
        TTR              Time to try reassignment/resynchronization
        TWR              Time to wait for
                            reassignment/resynchronization
        TS1              Supervisory timer 1
        TS2              Supervisory time 2
        MLR              NSDU lifetime  local-to-remote
        MRL              NSDU lifetime  remote-to-local
        ELR              Expected maximum transit delay
                            local-to-remote
        ERL              Expected maximum transit delay
                            remote-to-local
        R                Persistence time
        AL               Local acknowledgement time
        AR               Remote acknowledgement time
     
     4.5  Miscellaneous
     
        TS-user          Transport service user
        TSAP             Transport service access point
        NS-provider      Network service provider
        NSAP             Network service access point
        QOS              Quality of service

14

     5  OVERVIEW OF THE TRANSPORT PROTOCOL
     
     NOTE - This overview is not exhaustive and has been provided  for
     guidance to the reader of this International Standard.
     
     5.1  Service provided by the transport layer
     
     The protocol specified in this  International  Standard  supports
     the transport service defined in DP 8072.
     
     Information is  transferred  to  and  from  the  TS-user  in  the
     transport service primitives listed in table 1.

15

     +-------------------------------------------------------------+
     |           Primitive            |        Parameter           |
     |--------------------------------|----------------------------|
     |T-CONNECT         request       |   Called Address,          |
     |                  indication    |   Calling Address,         |
     |                                |   Expedited Data option,   |
     |                                |   Quality of Service,      |
     |                                |   TS User-Data.            |
     |--------------------------------|----------------------------|
     |T-CONNECT         response      |   Responding Address,      |
     |                  confirm       |   Quality of Service,      |
     |                                |   Expedited Data option,   |
     |                                |   TS User-Data.            |
     |--------------------------------|----------------------------|
     |T-DATA            request       |   TS User-Data.            |
     |                  indication    |                            |
     |--------------------------------|----------------------------|
     |T-EXPEDITED DATA  request       |   TS User-Data.            |
     |                  indication    |                            |
     |--------------------------------|----------------------------|
     |T-DISCONNECT      request       |   TS User-Data.            |
     |--------------------------------|----------------------------|
     |T-DISCONNECT      indication    |   Disconnect reason,       |
     |                                |   TS User-Data.            |
     +--------------------------------|----------------------------+

Table 1. Transport service primitives

     5.2  Service assumed from the network layer

The protocol specified in this International Standard assumes the use of the network service defined in DP 8348.

     Information is transferred to and from  the  NS-provider  in  the
     network service primitives listed in table 2.

16

     +---------------------------------------------------------------+
     |        Primitives          |X/Y|       Parameters       |X/Y/Z|
     |----------------------------|---|------------------------|-----|
     |N-CONNECT       request     | X | Called Address,        |  X  |
     |                indication  | X | Calling Address,       |  X  |
     |                response    | X | NS User-Data,          |  Z  |
     |                confirm     | X | QOS parameter set,     |  X  |
     |                            |   | Responding address,    |  Z  |
     |                            |   | Receipt confirmation   |  Y  |
     |                            |   | selection.             |     |
     |----------------------------|---|------------------------|-----|
     |N-DATA          request     | X | NS User-Data,          |  X  |
     |                indication  | X | Confirmation request   |  Y  |
     |----------------------------|---|------------------------|-----|
     |N-DATA ACKNOWLEDGE          |   |                        |     |
     |                request     | Y |                        |     |
     |                indication  | Y |                        |     |
     |----------------------------|---|------------------------|-----|
     |N-EXPEDITED DATA            |   |                        |     |
     |                request     | Y | NS User-Data.          |  Y  |
     |                indication  | Y |                        |     |
     |----------------------------|---|------------------------|-----|
     |N-RESET         request     | X | Originator,            |  Z  |
     |                indication  | X | Reason.                |  Z  |
     |                response    | X |                        |     |
     |                confirm     | X |                        |     |
     |----------------------------|---|------------------------|-----|
     |N-DISCONNECT    request     | X | NS User-Data.          |  Z  |
     |                indication  | X | Originator,            |  Z  |
     |                            |   | Reason.                |  Z  |
     +---------------------------------------------------------------+
                    Table 2. Network service primitives

17

Key:

        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.

NOTES:

        1 - The parameters listed in  this  table  are  those  in  the
            current network service (first DP 8348).

2 - The way the parameters are exchanged between the transport

entity and the NS-provider is a local matter.

     5.3  Functions of the Transport Layer
     
     5.3.1  Overview of functions
     
     The functions in the  Transport  Layer  are  those  necessary  to
     bridge  the  gap  between the services available from the Network
     Layer and those to be offered to the TS-users.
     
     The functions in the  Transport  Layer  are  concerned  with  the
     enhancement  of  quality  of  service,  including aspects of cost
     optimization.
     
     These functions are grouped below into those used  at  all  times
     during a transport connection and those concerned with connection
     establishment, data transfer and release.
     
     NOTE - This International Standard does not include the following
     functions  which  are under consideration for inclusion in future
     editions of this standard:
     
        a)  encryption;

18

b) accounting mechanisms;

c) status exchanges and monitoring of QOS;

        d)  blocking;

e) temporary release of network connections;

f) alternative checksum algorithm.

     5.3.1.1  Functions used at all times
     
     The following functions, depending upon the  selected  class  and
     options, are used at all times during a transport connection:

a) transmission of TPDUs (see 6.2 and 6.9);

        b)  multiplexing and demultiplexing  (see  6.15),  a  function
            used  to  share a single network connection between two or
            more transport connections;

c) error detection (see 6.10, 6.13 and 6.17), a function used

            to  detect  the loss, corruption, duplication, misordering
            or misdelivery of TPDUs;
        
        d)  error recovery (see 6.12, 6.14, 6.18, 6.19, 6.20, 6.21 and
            6.22),  a  function  used  to  recover  from  detected and
            signalled errors.
     
     5.3.1.2  Connection Establishment
     
     The  purpose  of  connection  establishment  is  to  establish  a
     transport   connection   between  two  TS-users.   The  following
     functions of the transport layer during this phase must match the
     TS-users'  requested quality of service with the services offered
     by the network layer:

19

        a)  select network service which best matches the  requirement
            of  the  TS-user  taking  into account charges for various
            services (see 6.5);

b) decide whether to multiplex multiple transport connections

onto a single network connection (see 6.5);

c) establish the optimum TPDU size (see 6.5);

        d)  select  the  functions  that  will  be  operational   upon
            entering the data transfer phase (see 6.5);

e) map transport addresses onto network addresses;

        f)  provide a  means  to  distinguish  between  two  different
            transport connections (see 6.5);

g) transport of TS-user data (see 6.5).

     5.3.1.3  Data Transfer
     
     The purpose of data transfer is to permit duplex transmission  of
     TSDUs  between  the  two  TS-users  connected  by  the  transport
     connection.   This  purpose  is  achieved  by  means  of  two-way
     simultaneous  communication  and by the following functions, some
     of which are used or not used in accordance with  the  result  of
     the selection performed in connection establishment:

a) concatenation and separation (see 6.4), a function used to

            collect  several  TPDUs  into a single NSDU at the sending
            transport  entity  and  to  separate  the  TPDUs  at   the
            receiving transport entity;
        
        b)  segmenting and reassembling (see 6.3), a function used  to
            segment  a  single  data  TSDU  into multiple TPDUs at the
            sending transport entity and to reassemble them into their
            original format at the receiving transport entity;

20

        c)  splitting and recombining (see 6.23), a function  allowing
            the simultaneous use of two or more network connections to
            support the same transport connection;
        
        d)  flow control (see 6.16), a function used to  regulate  the
            flow  of  TPDUs  between  two  transport  entities  on one
            transport connection;
        
        e)  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;
        
        f)  expedited data (see 6.11), a function used to  bypass  the
            flow  control  of  normal  data TPDU.  Expedited data TPDU
            flow is controlled by separate flow control;
        
        g)  TSDU delimiting (see 6.3), a function  used  to  determine
            the beginning and ending of a TSDU.
     
     5.3.1.4  Release
     
     The  purpose  of  release  (see  6.7  and  6.8)  is  to   provide
     disconnection  of  the  transport  connection,  regardless of the
     current activity.
     
     5.4  Classes and options
     
     5.4.1  General
     
     The functions of the Transport Layer  have  been  organized  into
     classes and options.
     
     A class  defines  a  set  of  functions.   Options  define  those
     functions within a class which may or may not be used.

This International Standard defines five classes of protocol:

21

        a)  Class 0:  Simple Class;
        
        b)  Class 1:  Basic Error recovery Class;
        
        c)  Class 2:  Multiplexing Class;

d) Class 3: Error Recovery and Multiplexing Class;

e) Class 4: Error Detection and Recovery Class.

     NOTE - Transport connections  of  classes  2,  3  and  4  may  be
     multiplexed together onto the same network connection.
     
     5.4.2  Negotiation
     
     The use of classes and options is  negotiated  during  connection
     establishment.   The  choice  made by the transport entities will
     depend upon:

a) the TS-users' requirements expressed via T-CONNECT service

            primitives;

b) the quality of the available network services;

        c)  the user required service versus cost ratio acceptable  to
            the TS-user.
     
     5.4.3  Choice of network connection
     
     The following  list  classifies  network  services  in  terms  of
     quality  with  respect  to  error  behavior  in  relation to user
     requirements; its main purpose is to  provide  a  basis  for  the
     decision  regarding  which  class of transport protocol should be
     used in conjunction with given network connection:

22

a) Type A. Network connection with acceptable residual error

            rate  (for  example  not signalled by disconnect or reset)
            and acceptable rate of signalled errors.
        
        b)  Type B.   Network  connections  with  acceptable  residual
            error  rate  (for  example  not signalled by disconnect or
            reset) but unacceptable rate of signalled errors.
        
        c)  Type C.  Network connections  with  unacceptable  residual
            error rate.
     
     It is assumed that each transport entity is aware of the  quality
     of service provided by particular network connections.
     
     5.4.4  Characteristics of Class 0
     
     Class 0 provides the simplest type of transport connection and is
     fully  compatible  with the CCITT recommendation S.70 for teletex
     terminals.
     
     Class 0 has  been  designed  to  be  used  with  type  A  network
     connections.
     
     5.4.5  Characteristics of Class 1
     
     Class 1  provides  a  basic  transport  connection  with  minimal
     overheads.
     
     The main  purpose  of  the  class  is  to  recover  from  network
     disconnect or reset.
     
     Selection of this class is usually based on reliability criteria.
     Class  1  has  been  designed  to  be  used  with  type B network
     connections.

23

     5.4.6  Characteristics of Class 2
     
     5.4.6.1  General
     
     Class 2 provides a way to multiplex several transport connections
     onto  a  single network connection.  This class has been designed
     to be used with type A network connections.
     
     5.4.6.2  Use of explicit flow control
     
     The objective is to provide flow control to help avoid congestion
     at transport-connection-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.
     
     5.4.6.3  Non-use of explicit flow control
     
     The objective is to provide a  basic  transport  connection  with
     minimal  overheads  suitable  when  explicit disconnection of the
     transport connection is desirable.  The option would typically be
     used for unsophisticated terminals, and when no multiplexing onto
     network  connections  is  required.   Expedited  data  is   never
     available.
     
     5.4.7  Characteristics of Class 3
     
     Class 3 provides the characteristics of Class 2 plus the  ability
     to  recover  from network disconnect or reset.  Selection of this
     class is usually based upon reliability criteria.   Class  3  has
     been designed to be used with type B network connections.

24

     5.4.8  Characteristics of Class 4
     
     Class 4  provides  the  characteristics  of  Class  3,  plus  the
     capability  to  detect  and  recover from errors which occur as a
     result of the  low  grade  of  service  available  from  the  NS-
     provider.   The  kinds  of  errors  to be detected include:  TPDU
     loss, TPDU delivery out of sequence, TPDU  duplication  and  TPDU
     corruption.   These  errors  may  affect control TPDUs as well as
     data TPDUs.
     
     This class also provides for increased throughput capability  and
     additional  resilience  against network failure. Class 4 has been
     designed to be used with type C network connections.
     
     5.5  Model of the transport layer
     
     A transport entity communicates with its TS-users through one  or
     more  TSAPs  by means of the service primitives as defined by the
     transport service definition DP 8072.   Service  primitives  will
     cause  or be the result of transport protocol data unit exchanges
     between  the  peer  transport  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 8348 through one or more NSAPs.
     
     Transport connection endpoints are identified in end  systems  by
     an  internal, implementation dependent, mechanism so that the TS-
     user and  the  transport  entity  can  refer  to  each  transport
     connection.

25

               +------+                        +------+
     ----------| TSAP |------------------------| TSAP |----------
               +------+                        +------+
                   |                               |
            +---------------+               +---------------+
            | Transport     |               | Transport     |
            |       entity  |               |       entity  |
            +---------------+               +---------------+
                   |                               |
                   |                               |
               +------+                        +------+
     ----------| NSAP |------------------------| NSAP |----------
               +------+                        +------+
                   |                               |
                   +-------------------------------+

Figure 2 . Model of the transport layer

     NOTE - For purpose of illustration, this figure  shows  only  one
     TSAP  and  one  NSAP  for  each  transport  entity.   In  certain
     instances, more than one TSAP and/or more than one  NSAP  may  be
     associated with a particular transport entity.

26

SECTION TWO. TRANSPORT PROTOCOL SPECIFICATION

     6  ELEMENTS OF PROCEDURE
     
     This clause contains elements of procedure which are used in  the
     specification  of  protocol  classes  in  clauses 7 to 12.  These
     elements are not meaningful on their own.
     
     The procedures define the transfer of TPDUs whose  structure  and
     coding  is  specified  in  clause  13.   Transport entities shall
     accept and respond to any TPDU received in a valid NSDU  and  may
     issue  TPDUs  initiating specific elements of procedure specified
     in this clause.
     
     NOTE - Where network service primitives and TPDUs and  parameters
     used  are  not significant for a particular element of procedure,
     they have not been included in the specification.
     
     6.1  Assignment to network connection
     
     6.1.1  Purpose
     
     The  procedure  is  used  in  all  classes  to  assign  transport
     connections to network connections.
     
     6.1.2  Network service primitives
     
     The  procedure  makes  use  of  the  following  network   service
     primitives:
     
        a)  N-CONNECT;

b) N-DISCONNECT.

27

     6.1.3  Procedure
     
     Each  transport  connection  shall  be  assigned  to  a   network
     connection.  The initiator may assign the transport connection to
     an existing network connection of which it is the owner or  to  a
     new  network  connection  (see  Note 1) which it creates for this
     purpose.
     
     The  initiator  shall  not  assign  or  reassign  the   transport
     connection  to  an  existing  network  connection if the protocol
     class(es)  proposed  or  the  class  in  use  for  the  transport
     connection are incompatible with the current usage of the network
     connection with respect to multiplexing (see Note 2).
     
     During the resynchronization (see 6.14)  and  reassignment  after
     failure  (see 6.12) procedures, a transport entity may reassign a
     transport connection to another network  connection  joining  the
     same  NSAPs,  provided  that  it  is  the  owner  of  the network
     connection and that the transport connection is assigned to  only
     one network connection at any given time.
     
     During the splitting procedure (see 6.23), a transport entity may
     assign   a   transport   connection  to  any  additional  network
     connection joining the same NSAPs, provided that it is the  owner
     of  the  network  connection and that multiplexing is possible on
     the network connection.

The responder becomes aware of the assignment when it receives

        a)  a CR TPDU during the  connection  establishment  procedure
            (see 6.5); or
        
        b)  an RJ TPDU or a retransmitted CR or  DR  TPDU  during  the
            resynchronization   (see   6.14)  and  reassignment  after
            failure (see 6.12) procedures; or

c) any TPDU when splitting (see 6.23) is used.

28

     NOTES
     
        1.  When a new network connection is created, the  quality  of
            service  requested  is  a  local  matter, although it will
            normally be  related  to  the  requirements  of  transport
            connection(s) expected to be assigned to it.
     
        2.  An existing network connection may also  not  be  suitable
            if,  for example, the quality of service requested for the
            transport  connection  cannot  be  attained  by  using  or
            enhancing the network connection.
     
        3.  A  network  connection  with  no  transport  connection(s)
            assigned   to   it,   may   be   available  after  initial
            establishment, or because all of the transport connections
            previously  assigned  to  it  have  been  released.  It is
            recommended  that  only  the  owner  of  such  a   network
            connection   should   release   it.   Furthermore,  it  is
            recommended that it not be released immediately after  the
            transmission of the final TPDU of a transport connection -
            either a DR TPDU in response to CR TPDU or a  DC  TPDU  in
            response  to DR TPDU.  An appropriate delay will allow the
            TPDU  concerned  to  reach  the  other  transport   entity
            allowing  the freeing of any resources associated with the
            transport connection concerned.
     
        4.  After the  failure  of  a  network  connection,  transport
            connections which were previously multiplexed together may
            be assigned to different  network  connections,  and  vice
            versa.
     
     6.2  Transport protocol data unit (TPDU) transfer
     
     6.2.1  Purpose
     
     The TPDU transfer procedure is used  in  all  classes  to  convey
     transport  protocol  data  units  in  user data fields of network
     service primitives.

29

     6.2.2  Network Service Primitives

The procedure uses the following network service primitives:

        a)  N-DATA;

b) N-EXPEDITED DATA

     6.2.3  Procedure
     
     The  transport  protocol  data  units  (TPDUs)  defined  for  the
     protocol are listed in 4.2.

When the network expedited variant has been selected for class 1, the transport entities shall transmit and receive ED and EA TPDUs as NS-user data parameters of N-EXPEDITED DATA primitives.

In all other cases, transport entities shall transmit and receive TPDUs as NS-user data parameters of N-DATA primitives.

     When  a  TPDU  is  put  into  an  NS-user  data  parameter,   the
     significance  of the bits within an octet and the order of octets
     within a TPDU shall be as defined in 13.2.

NOTE - TPDUs may be concatenated (see 6.4).

     6.3  Segmenting and reassembling
     
     6.3.1  Purpose
     
     The segmenting and reassembling procedure is used in all  classes
     to map TSDUs onto TPDUs.

30

     6.3.2  TPDUs and parameter used

The procedure makes use of the following TPDU and parameter:

        DT TPDUs;

• End of TSDU.

     6.3.3  Procedure
     
     A transport entity shall map a TSDU on to an ordered sequence  of
     one  or more DT TPDUs.  This sequence shall not be interrupted by
     other DT TPDUs on the same transport connection.
     
     All DT TPDUs except the last DT TPDU in a sequence  greater  than
     one shall have a length of data greater than zero.
     
     NOTES
     
        1.  The EOT parameter of a DT TPDU indicates  whether  or  not
            there are subsequent DT TPDUs in the sequence.
     
        2.  There is no requirement that the DT TPDUs shall be of  the
            maximum length selected during connection establishment.
     
     6.4  Concatenation and separation
     
     6.4.1  Purpose

The procedure for concatenation and separation is used in classes 1, 2, 3 and 4 to convey multiple TPDUs in one NSDU.

31

     6.4.2  Procedure
     
     A transport  entity  may  concatenate  TPDUs  from  the  same  or
     different transport connections.

The set of concatenated TPDUs may contain:

        a)  any number of TPDUs from the following list:  AK, EA,  RJ,
            ER,   DC  TPDUs,  provided  that  these  TPDUs  come  from
            different transport connections;
        
        b)  no more than one TPDU from the following  list:   CR,  DR,
            CC,  DT,  ED  TPDUs;  if this TPDU is present, it shall be
            placed last in the set of concatenated TPDUs.
     
     NOTES
     
        1.  The TPDUs within a concatenated set may  be  distinguished
            by means of the length indicator parameter.
     
        2.  The end of a TPDU containing  data  is  indicated  by  the
            termination of the NSDU.

3. The number of concatenated TPDUs referred to in 6.4.2.a is bounded by the maximum number of transport connections which are multiplexed together except during assignment or reassignment.

     6.5  Connection establishment
     
     6.5.1  Purpose

The procedure for connection establishment is used in all classes to create a new transport connection.

32

     6.5.2  Network service primitives

The procedure uses the following network service primitive:

     N-DATA
     
     6.5.3  TPDUs and parameters used

The procedure uses the following TPDUs and parameters:

a) CR TPDU;

            - CDT;
            - DST-REF (set to zero);
            - SRC-REF
            - CLASS and OPTIONS (i.e. preferred class, use of extended
              format, non-use of explicit flow control in class 2);
            - calling TSAP-ID;
            - called TSAP-ID;
            - TPDU size (proposed);
            - version number;
            - security parameter;
            - checksum;
            - additional  option  selection  (i.e.  use   of   network
              expedited  in  class  1,  use of receipt confirmation in
              class  1,  non-use  of  checksum  in  class  4,  use  of
              transport expedited data transfer service);
            - alternative protocol class(es);
            - acknowledge time;
            - throughput (proposed);
            - residual error rate (proposed);
            - priority (proposed);
            - transit delay (proposed);
            - reassignment time;
            - user data.

b) CC TPDU;

            - CDT;
            - DST-REF;

33

            - SRC-REF;
            - CLASS and OPTIONS (selected);
            - calling TSAP-ID;
            - called TSAP-ID;
            - TPDU size (selected);
            - security parameter;
            - checksum;
            - additional option selection (selected);
            - acknowledge time;
            - throughput (selected);
            - residual error rate (selected);
            - priority (selected);
            - transit delay (selected);
            - user data.
          
          NOTE - The  transport  service  defines  transit  delay   as
          requiring  a  previously stated average TSDU size as a basis
          for any  specification.   This  protocol,  as  specified  in
          13.3.4(n),  uses  a  value of 128 octets.  Conversion to and
          from specifications based upon some other value is  a  local
          matter.
     
     6.5.4  Procedure
     
     A transport connection is established by means of  one  transport
     entity  (the  initiator)  transmitting  a  CR  TPDU  to the other
     transport entity (the responder), which replies with a CC TPDU.
     
     Before sending the CR TPDU, the initiator assigns  the  transport
     connection  being  created  to  one  (or  more  if  the splitting
     procedure is being use) 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 shall be exchanged or negotiated.
     
          NOTE - Except  in  class  4,  it  is  recommended  that  the
          initiator  starts  an  optional timer TS1 at the time the CR
          TPDU is  sent.   This  timer  should  be  stopped  when  the
          connection   is   considered   as  accepted  or  refused  or
          unsuccessful.  If the timer expires,  the  initiator  should

34

          reset or disconnect the network connection and, in classes 1
          and 3 freeze  the  reference  (see  6.18).   For  all  other
          transport  connection(s)  multiplexed  on  the  same network
          connection  the  procedures  for  reset  or  disconnect   as
          appropriate should be followed.
     
     After receiving the CC  TPDU  for  a  class  which  includes  the
     procedure  for  retention  until  acknowledgement  of  TPDUs  the
     initiator shall acknowledge the CC TPDU as  defined  in  table  5
     (see 6.13).
     
     When the network expedited variant of the expedited data transfer
     (see  6.11)  has  been  agreed  (possible  in  class 1 only), the
     responder shall not send  an  ED  TPDU  before  the  CC  TPDU  is
     acknowledged.

The following information is exchanged:

        a)  references.  Each transport  entity  chooses  a  reference
            which is to be used by the peer entity is 16 bits long and
            which is arbitrary except for the following restrictions:

1. it shall not already be in use or frozen (see 6.18),

2. it shall not be zero.

            This mechanism is symmetrical and 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
            matter.
        
        b)  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.
        
        c)  initial credit.  Only relevant for classes  which  include
            the explicit flow control function.
        
        d)  user data.  Not available if  Class  0  is  the  preferred
            class (see note).  Up to 32 octets in other classes.

35

            NOTE - If class 0 is a valid response according  to  table
            3,  inclusion  of  user  data in the CR TPDU may cause the
            responding entity to refuse the  connection  (e.g.  if  it
            only supports class 0).

e) acknowledgement time. Only in class 4.

f) checksum parameter. Only in class 4.

        g)  security parameter.  This parameter and its semantics  are
            user defined.

The following negotiations take place:

        h)  protocol class.  The initiator shall propose  a  preferred
            class  and  may  propose  any  number of alternative class
            which permit a valid response as defined in table 3.   The
            initiator should assume when it sends the CR TPDU that its
            preferred class  will  be  agreed  to,  and  commence  the
            procedures  associated  with  that  class,  except that if
            class 0 or class 1 is an alternative  class,  multiplexing
            shall  not  commence  until a CC TPDU selecting the use of
            classes 2, 3 or 4 has been received.
        
            NOTE - This means, for example, that  when  the  preferred
            class    includes   resynchronization   (see   6.14)   the
            resynchronization will  occur  if  a  reset  is  signalled
            during connection establishment.
     
     The responder shall select one class defined  in  table  3  as  a
     valid  response  corresponding  to the preferred class and to the
     class(es), if any, contained in the alternative  class  parameter
     of  the  CR TPDU.  It shall indicate the selected class in the CC
     TPDU and shall follow the procedures for the selected class.
     
     If the preferred class is not selected, then on receipt of the CC
     TPDU  the  initiator  shall  adjust  its  operation according the
     procedures of the selected class.

36

     +------------------------------------------------------------+
     | Pre-  |                Alternative class                   |
     |ferred |----------------------------------------------------|
     |class  |   0    |   1    |   2    |   3    |   4    | none  |
     |-------|--------|--------|--------|--------|--------|-------|
     |   0   |not     |not     |not     |not     |not     |class  |
     |       |valid   |valid   |valid   |valid   |valid   |  0    |
     |-------|--------|--------|--------|--------|--------|-------|
     |   1   |class   |class   |not     |not     |not     |class  |
     |       |1 or 0  |1 or 0  |valid   |valid   |valid   |1 or 0 |
     |-------|--------|--------|--------|--------|--------|-------|
     |   2   |class   |not     |class   |not     |not     |class  |
     |       |2 or 0  |valid   |2       |valid   |valid   |  2    |
     |-------|--------|--------|--------|--------|--------|-------|
     |   3   |class   |class 3,|class   |class   |not     |class  |
     |       |3,2 or 0|2,1 or 0|3 or 2  |3 or 2  |valid   |3 or 2 |
     |-------|--------|--------|--------|--------|--------|-------|
     |   4   |class   |class 4,|class   |class   |class   |class  |
     |       |4,2 or 0|2,1 or 0|4 or 2  |4,3 or 2|4 or 2  |4 or 2 |
     +------------------------------------------------------------+
                                 Table 3.
     
     Valid responses corresponding to  the  preferred  class  and  any
     alternative class proposed in the CR TPDU

NOTES:

        1.  The valid responses indicated in table 3 result from  both
            explicit negotiation, whereby each of the classes proposed
            is a valid response, and implicit negotiation whereby:
        
            a)  if class 3 or 4 is proposed then class 2  is  a  valid
                response;
            b)  if class 1  is  proposed  then  class  0  is  a  valid
                response.

37

        2.  Negotiation from class 2 to class 1 and from any class  to
            an higher-numbered class is not valid.

3. Redundant combinations are not a protocol error.

        j)  TPDU size.  The initiator may propose a maximum  size  for
            TPDUs,  and the responder may accept this value or respond
            with any value between 128 and the proposed value  in  the
            set of values available (see 13.3.4.b).
        
            NOTE - The length of the  CR  TPDU  does  not  exceed  128
            octets (see 13.3).
        
        k)  normal or extended format.  Either normal or  extended  is
            available.   When  extended  is  used this applies to CDT,
            TPDU-NR, ED-TPDU-NR, YR-TU-NR and YR-EDTU-NR parameters.
        
        m)  checksum selection.  This defines whether or not TPDUs  of
            the connection are to include a checksum.
        
        n)  quality  of  service   parameters.    This   defines   the
            throughput,  transit  delay,  priority  and residual error
            rate.

p) the non-use of explicit flow control in class 2.

        q)  the  use  of  network  receipt  confirmation  and  network
            expedited when class 1 is to be used.
        
        r)  use of expedited data transfer service.  This allows  both
            TS-users  to negotiate the use or non-use of the expedited
            data transport service as defined in the transport service
            (ISO 8072).

The following information is sent only in the CR TPDU:

s) version number. This defines the version of the transport

protocol standard used for this connection.

        t)  reassignment time parameter.  This indicates the time  for
            which   the   initiator  will  persist  in  following  the
            reassignment after failure procedure.

38

     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  an
     alternative choice as defined in table 4.
     
     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 shall also request or  agree  (respectively)
     to the use of explicit flow control.
     
     +-------------------------------------------------------------+
     |        Option         |  Proposal Made   | Valid Selection  |
     |                       | by the Initiator | by the Responder |
     |-----------------------|------------------|------------------|
     |Transport expedited    |       Yes        |    Yes or No     |
     |data transfer service  |       No         |        No        |
     |(Classes 1,2,3,4 only) |                  |                  |
     |-----------------------|------------------|------------------|
     |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           |       No         |        No        |
     |(Class 2 only)         |                  |                  |
     |-----------------------|------------------|------------------|
     |Use of extended format |       Yes        |    Yes or No     |
     |(Classes 2,3,4 only)   |       No         |        No        |
     +-------------------------------------------------------------+

Table 4. Negotiation of options during connection establishment

39

     NOTE - Table 4 defines the procedures for negotiation of options.
     This  negotiation  has  been  designed such that if the initiator
     proposes the mandatory implementation option specified in  clause
     14,  the  responder  has  to  accept  use of this option over the
     transport  connection  except  for  the  use  of  the   transport
     expedited  data transfer service which may be rejected by the TS-
     user.  If the initiator proposes a  non-mandatory  implementation
     option,  the responder is entitled to select use of the mandatory
     implementation option for use over the transport connection.
     
     6.6  Connection refusal
     
     6.6.1  Purpose
     
     The connection refusal procedure is used in all  classes  when  a
     transport  entity refuses a transport connection in response to a
     CR TPDU.
     
     6.6.2  TPDUs and parameters used

The procedure makes use of the following TPDUs and parameters:

a) DR TPDU;

            - SRC-REF;
            - reason;
            - user data.

b) ER TPDU;

- reject code;
- rejected TPDU parameter.

40

     6.6.3  Procedure
     
     If a transport connection cannot be accepted, the responder shall
     respond to the CR TPDU with a DR TPDU.  The reason shall indicate
     why the connection was not accepted.  The source reference  field
     in  the  DR  TPDU  shall be set to zero to indicate an unassigned
     reference.
     
     If  a  DR  TPDU  is  received  the  initiator  shall  regard  the
     connection as released.
     
     The responder shall respond to an invalid CR TPDU by  sending  an
     ER  or  DR  TPDU.   If an ER TPDU is received in response to a CR
     TPDU, the initiator shall regard the connection as released.
     
     NOTES
     
     1.  When the invalid CR TPDU can be identified as having class  0
         as  the preferred class, it is recommended to respond with an
         ER TPDU.  For all other invalid CR TPDUs either an ER TPDU or
         DR TPDU may be sent.
     
     2.  If the optimal supervisory timer TS1 has been  set  for  this
         connection  then  the entity should stop the timer on receipt
         of the DR or ER TPDU.
     
     6.7  Normal release
     
     6.7.1  Purpose
     
     The release procedure is used by a transport entity in  order  to
     terminate  a  transport connection.  The implicit variant is used
     only in class 0.  The explicit variant is used in  classes  1,2,3
     and 4.

41

     NOTES
     
     1.  When the implicit variant is used  (i.e.  in  class  0),  the
         lifetime  of  the transport connection is directly correlated
         with the lifetime of the network connection.
     
     2.  The use of the explicit  variant  of  the  release  procedure
         enables the transport connection to be released independently
         of the underlying network connection.
     
     6.7.2  Network service primitives
     
     The  procedure  makes  use  of  the  following  network   service
     primitives:
     
        a)  N-DISCONNECT (implicit variant only),
     
        b)  N-DATA
     
     6.7.3  TPDUs and parameters used

The procedure makes use of the following TPDUs and parameters:

a) DR TPDU;

            - clearing reason;
            - user data;
            - SRC-REF;
            - DST-REF.

b) DC TPDU.

42

     6.7.4  Procedure for implicit variant
     
     In the implicit variant either  transport  entity  disconnects  a
     transport  connection  by disconnecting the network connection to
     which it is assigned.  When a transport  entity  receives  an  N-
     DISCONNECT  this  should  be  considered  as  the  release of the
     transport connection.
     
     6.7.5  Procedure for explicit variant
     
     When the release of a transport connection is to be  initiated  a
     transport entity
     
        a)  if it has previously sent or received a CC TPDU (see  note
            1),   shall   send   a  DR  TPDU.   It  shall  ignore  all
            subsequently received TPDUs other than a DR  or  DC  TPDU.
            On  receipt  of  a  DR  or  DC  TPDU it shall consider the
            transport connection released;

b) in other cases it shall:

            1)  For  classes  other  than  class  4   wait   for   the
                acknowledgement  of  the  outstanding  CR  TPDU; if it
                receives a CC TPDU, it shall follow the procedures  in
                6.7.5.a.

2. For class 4 either send a DR TPDU with a zero value in the DST-REF field or follow the procedure in 6.7.5.b.1.

A transport entity that receives a DR TPDU shall

c) if it has previously sent a DR TPDU for the same transport

connection, consider the transport connection released;

        d)  if it has previously sent a CR  TPDU  that  has  not  been
        
            acknowledged by a CC TPDU, consider the connection refused
            (see 6.6).

43

        e)  in other cases, send a DC TPDU and consider the  transport
            connection released.
        
        NOTES
        
        1)  This requirement ensures  that  the  transport  entity  is
            aware   of   the   remote   reference  for  the  transport
            connection.
        
        2)  When the transport connection is  considered  as  released
            the  local  reference is either available for re-use or is
            frozen (see 6.18).
        
        3)  After the release of a transport  connection  the  network
            connection  can  be released or retained to enable its re-
            use for the assignment of other transport connections (see
            6.1.).
        
        4)  Except in class 4, it is recommended that, if a  transport
            entity  does  not  receive  acknowledgement  of  a DR TPDU
            within time TS2, it should either reset or disconnect  the
            network   connection,   and   freeze  the  reference  when
            appropriate  (see  6.18).    For   all   other   transport
            connection(s)  multiplexed  on this network connection the
            procedures for reset or disconnect as  appropriate  should
            be followed.
        
        5)  When a transport entity is waiting for a  CC  TPDU  before
            sending  a  DR TPDU and the network connection is reset or
            released, it  should  consider  the  transport  connection
            released  and,  in  classes  other  than  classes 0 and 2,
            freeze the reference (see 6.18).
     
     6.8  Error Release

44

     6.8.1  Purpose
     
     This procedure is used only in classes  0  and  2  to  release  a
     transport connection on the receipt of an N-DISCONNECT or N-RESET
     indication.
     
     6.8.2  Network service primitives

The procedure makes use of the following service primitives:

a) N-DISCONNECT indication;

b) N-RESET indication.

     6.8.3  Procedure
     
     When, on the network connection to which a  transport  connection
     is  assigned,  an N-DISCONNECT or N-RESET indication is received,
     both  transport  entities  shall  consider  that  the   transport
     connection is released and so inform the TS-users.
     
     NOTE - In other  classes,  since  error  recovery  is  used,  the
     receipt  of an N-RESET indication or N-DISCONNECT indication will
     result in the invocation of the error recovery procedure.
     
     6.9  Association of TPDUs with transport connections
     
     6.9.1  Purpose
     
     This procedure is used in all classes  to  interpret  a  received
     NSDU  as  TPDU(s)  and,  if possible, to associate each such TPDU
     with a transport connection.

45

     6.9.2  Network service primitives
     
     This  procedure  makes  use  of  the  following  network  service
     primitives:

a) N-DATA indication;

b) N-EXPEDITED DATA indication.

     6.9.3  TPDUs and parameters uses

This procedure makes use of the following TPDUs and parameters:

        a)  any TPDU except CR TPDU, DT TPDU in classes 0 or 1 and  AK
            TPDU in class 1;

• DST-REF

        b)  CR, CC, DR and DC TPDUs;

• SCR-REF.

c) DT TPDU in classes 0 or 1 and AK TPDU in class 1.

     6.9.4  Procedures
     
     6.9.4.1  Identification of TPDUs
     
     If the received NSDU or Expedited NSDU cannot  be  decoded  (i.e.
     does not contain one or more correct TPDUs) or is corrupted (i.e.
     contains a TPDU with a wrong checksum) then the transport  entity
     shall:

46

        a)  if the network connection on which the error  is  detected
            has  a class 0 or class 1 transport connection assigned to
            it, then treat as a protocol error  (see  6.22)  for  that
            transport connection;
        
        b)  otherwise
        
            1)  if the NSDU can  be  decoded  but  contains  corrupted
                TPDUs,  ignore the TPDUs (class 4 only) and optionally
                apply 6.9.4.b.2.
        
            2)  if the NSDU cannot be decoded issue an N-RESET  or  N-
                DISCONNECT  request for the network connection and for
                all the transport connections assigned to this network
                connection  (if any), apply the procedures defined for
                handling of network signalled reset or disconnect.
        
            If the NSDU can be  decoded  and  is  not  corrupted,  the
            transport entity shall:
        
        c)  if the network connection on which the NSDU  was  received
            has  a  class  0 transport connection assigned to it, then
            consider the NSDU as forming TPDU and associate  the  TPDU
            with the transport connection (see 6.9.4.2).
        
        d)  otherwise, invoke the separation procedures and  for  each
            of  the individual TPDUs in the order in which they appear
            in the NSDU apply the procedure defined in 6.9.4.2.
     
     6.9.4.2  Association of individual TPDUs
     
     If the received TPDU is a CR TPDU then, if it is a duplicate,  as
     recognized  by using the NSAPs of the network connection, and the
     SRC-REF parameter, then  it  is  associated  with  the  transport
     connection  created  by  the  original  value  of  the  CR  TPDU;
     otherwise it is processed as requesting the  creation  of  a  new
     transport connection.
     
     If the received TPDU is a DT TPDU and the network connection  has
     a class 0 or 1 transport connection assigned to it, or an AK TPDU

47

     where a class 1 transport connection is assigned, then  the  TPDU
     is associated with the transport connection.

Otherwise, the DST-REF parameter of the TPDU is used to identify the transport connection. The following cases are distinguished:

a) if the DST-REF is not allocated to a transport connection,

            the  transport  entity  shall  respond on the same network
            connection with a DR TPDU if the TPDU is a CC TPDU, with a
            DC TPDU if the TPDU is a DR TPDU and shall ignore the TPDU
            if neither a DR TPDU nor CC TPDU.  No association  with  a
            transport connection is made.
        
        b)  if the DST-REF is allocated to a connection, but the  TPDU
            is   received   on  a  network  connection  to  which  the
            connection has not been  assigned  then  there  are  three
            cases:
        
            1)  if the transport connection is of class 4 and  if  the
                TPDU is received on a network connection with the same
                pair of NSAPs as that of the CR TPDU then the TPDU  is
                considered as performing assignment,
        
            2)  if the transport connection is  not  assigned  to  any
                network  connection  (waiting  for  reassignment after
                failure) and if the TPDU  is  received  on  a  network
                connection  with the same pair of NSAPs as that of the
                CR TPDU  then  the  association  with  that  transport
                connection is made.
        
            3)  Otherwise, the TPDU is considered as having a  DST-REF
                not allocated to a transport connection (case a).
        
        c)  If the TPDU is a DC TPDU then it is  associated  with  the
            transport  connection  to  which the DST-REF is allocated,
            unless the SRC-REF is not the expected one, in which  case
            the DC TPDU is ignored.

d) If the TPDU is a DR TPDU then there are three cases:

            1)  if the SRC-REF is not as expected then a DC TPDU  with
                DST-REF  equal  to the SRC-REF of the received DR TPDU
                is sent back and no association is made;

48

            2)  if a CR TPDU is unacknowledged then  the  DR  TPDU  is
                associated  with  the transport connection, regardless
                of the value of its SRC-REF parameter;
            
            3)  otherwise,  the  DR  TPDU  is  associated   with   the
                transport   connection   identified   by  the  DST-REF
                parameter.
        
        e)  if  the  TPDU  is  a  CC  TPDU  whose  DST-REF   parameter
            identifies an open connection (one for which a CC TPDU has
            been previously received), and the SRC-REF in the CC  TPDU
            does  not  match  the  remote reference, then a DR TPDU is
            sent back  with  DST-REF  equal  to  the  SRC-REF  of  the
            received CC TPDU and no association is made.
        
        f)  if none  of  the  above  cases  apply  then  the  TPDU  is
            associated with the transport connection identified by the
            DST-REF parameter.
     
     6.10  Data TPDU numbering
     
     6.10.1  Purpose
     
     Data TPDU numbering is used in classes  1,  2  (except  when  the
     non-use  of  explicit  flow control option is selected), 3 and 4.
     Its purpose is to enable the use of recovery,  flow  control  and
     re-sequencing functions.
     
     6.10.2  TPDUs and parameters used

The procedure makes use of the following TPDU and parameter:

        DT TPDU;

• TPDU-NR.

49

     6.10.3  Procedure
     
     A Transport entity shall allocate the sequence number zero to the
     TPDU-NR  of  the first DT TPDU which it transmits for a transport
     connection.  For subsequent DT TPDUs sent on the  same  transport
     connection, the transport entity shall allocate a sequence number
     one greater than the previous one.

When a DT TPDU is retransmitted, the TPDU-NR parameter shall have the same value as in the first transmission of that DT TPDU.

     Modulo 2**7 arithmetic shall be used  when  normal  formats  have
     been  selected  and  modulo  2**31  arithmetic shall be used when
     extended formats  have  been  selected.   In  this  International
     Standard  the  relationships 'greater than' and 'less than' apply
     to a set of contiguous TPDU numbers whose range is less than  the
     modulus  and whose starting and finishing numbers are known.  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
     
     6.11.1  Purpose
     
     Expedited data transfer procedures are selected during connection
     establishment.   The  network  normal data variant may be used in
     classes 1, 2, 3 and 4.  The network  expedited  variant  is  only
     used in class 1.
     
     6.11.2  Network service primitives
     
     The  procedure  makes  use  of  the  following  network   service
     primitives:
     
        a)  N-DATA;

50

b) N-EXPEDITED DATA.

     6.11.3  TPDUs and parameter used

The procedure makes use of the following TPDUs and parameters:

a) ED TPDU;

• ED TPDU-NR.

b) EA TPDU;

• YR-EDTU-NR.

     6.11.4  Procedures

The TS-user data parameter of each T-EXPEDITED DATA request shall be conveyed as the data field of an Expedited Data (ED) TPDU.

     Each ED TPDU received  shall  be  acknowledged  by  an  Expedited
     Acknowledge (EA) TPDU.
     
     No more than one ED TPDU shall remain unacknowledged at any  time
     for each direction of a transport connection.

An ED TPDU with a zero length data field is a protocol error.

51

     NOTES
     
        1.  The network normal data variant is used, except  when  the
            network expedited variant (available in Class 1 only), has
            been agreed, in which case ED and EA TPDUs are conveyed in
            the  data  fields  of  N-EXPEDITED  DATA  primitives  (see
            6.2.3).
     
        2.  No TPDUs can be transmitted using network expedited  until
            the  CC  TPDU becomes acknowledged, to prevent the network
            expedited from overtaking the CC TPDU.
     
     6.12  Reassignment after failure
     
     6.12.1  Purpose

The reassignment after failure procedure is used in Classes 1 and 3 to commence recovery from an NS-provider signalled disconnect.

     6.12.2  Network service primitives

The procedure uses the following network service primitive:

          N-DISCONNECT indication
     
     6.12.3  Procedure
     
     When an N-DISCONNECT indication  is  received  from  the  network
     connection  to  which  a  transport  connection  is assigned, the
     initiator shall apply one of the following alternatives:

a) if the TTR timer has not already run out and no DR TPDU is

retained then:

52

1. assign the transport connection to a different network connection (see 6.1) and start its TTR timer if not already started.

2. while waiting for the completion of assignment if:

                - an N-DISCONNECT indication is received,  repeat  the
                  procedure from 6.12.3.a,

• the TTR timer expires, begin procedure 6.12.3.b.

            3)  when     reassignment     is     completed,      begin
            
                resynchronization (see 6.14) and:
            
                - if a valid TPDU is received as  the  result  of  the
                  resynchronization, stop the TTR timer, or

• if TTR runs out, wait for the next event, or

                - if an  N-DISCONNECT  indication  is  received,  then
                  begin   either   procedure   6.12.3.a   or  6.12.3.b
                  depending on the TTR timer.
            
            NOTE - After the TTR timer expires and while  waiting  for
            the  next  event,  it  is  recommended  that the initiator
            starts the TWR timer.  If the TWR timer expires before the
            next  event  the  initiator  should begin the procedure in
            6.12.3.b.
        
        b)  if the TTR timer  has  run  out,  consider  the  transport
            connection  as  released  and  freeze  the  reference (see
            6.18).
        
        c)   if a DR TPDU is retained and the TTR timer  has  not  run
            out,  then  follow  the  actions  in  either  6.12.3.a  or
            6.12.3.b.
     
     The responder shall start its TWR timer if not  already  started.
     The arrival of the first TPDU related to the transport connection
     (because of resynchronization by  the  initiator)  completes  the
     reassignment  after  failure procedure.  The TWR timer is stopped
     and the responder  shall  continue  with  resynchronization  (see
     6.14).  If reassignment does not take place within this time, the

53

     transport connection is considered released and the reference  is
     frozen (see 6.18).
     
     6.12.4  Timers

The reassignment after failure procedure uses two timers:

        a)  TTR, the time to try reassignment/resynchronization timer;
        
        b)  TWR, the time to wait  for  reassignment/resynchronization
            timer.
     
     The TTR timer is used by the  initiator.   Its  value  shall  not
     exceed  two  minutes  minus  the  sum  of  the maximum disconnect
     propagation  delay  and  the  transit  delay   of   the   network
     connections  (see  note  1).   The value for the TTR timer may be
     indicated in the CR TPDU.
     
     The TWR timer is used by the responder.  If the reassignment time
     parameter is present in the CR TPDU, the TWR timer value shall be
     greater than the sum of the TTR timer plus the maximum disconnect
     propagation   delay   plus  the  transit  delay  of  the  network
     connections.

If the reassignment time parameter is not present in the CR TPDU, a default value of 2 minutes shall be used for the TWR timer.

     NOTES

1. Provided that the required quality of service is met, TTR may be set to zero (i.e. no assignment). This may be done, for example, if the rate of NS-provider generated disconnects is very low.

     2.  Inclusion of the reassignment time parameter in the  CR  TPDU
         allows  the  responder  to  use  a  TWR  value of less than 2
         minutes.
     
     3.  If  the  optional  TS1  and  TS2  timers  are  used,  it   is
         recommended:

54

            a)  to stop TS1 or TS2 if  running  when  TTR  or  TWR  is
                started;
            
            b)  to  restart  TS1  or  TS2  if   necessary   when   the
                corresponding TPDU (CR TPDU or DR TPDU respectively is
                repeated);

c) to select for TS1 and TS2 values greater than TTR.

55

     6.13  Retention until acknowledgement of TPDUs
     
     6.13.1  Purpose
     
     The retention until acknowledgement of TPDUs procedure is used in
     classes  1,  3  and 4 to enable and minimize retransmission after
     possible loss of TPDUs.
     
     The confirmation of receipt variant is used only in Class 1  when
     it has been agreed during connection establishment (see note).
     
     The AK variant is used in classes 3 and 4 and  also  in  Class  1
     when  the  confirmation  of  receipt  variant has not been agreed
     during connection establishment.
     
     NOTE - Use of confirmation of  receipt  variant  depends  on  the
     availability  of  the  network layer receipt confirmation service
     and the expected cost reduction.
     
     6.13.2  Network service primitives

The procedure uses the following network service primitives:

        a)  N-DATA;

b) N-DATA ACKNOWLEDGE.

     6.13.3  TPDUs and parameters used

The procedure uses the following TPDUs and parameters:

        a)  CR, CC, DR and DC TPDUs;
        
        b)  RJ and AK TPDUs;

• YR-TU-NR.

56

c) DT TPDU;

• TPDU-NR.

d) ED TPDU;

• ED-TPDU-NR.

e) EA TPDU;

• YR-EDTU-NR.

     6.13.4  Procedures

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

        CR, CC, DR, DT and ED TPDUs
     
     except that if a DR is sent in response to a CR TPDU there is  no
     need to retain a copy of the DR TPDU.
     
     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
     an N-DATA ACKNOWLEDGE request (see notes 1 and 2).
     
     After each TPDU is acknowledged, as shown in table  5,  the  copy
     need  not  be  retained.   Copies  may also be discarded when the
     transport connection is released.

57

     NOTES
     
        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.
     
        2.  Use of the confirmation request parameter may  affect  the
            quality of network service.

58

     +-------------------------------------------------------------+
     |RETAINED|              |                                     |
     |  TPDU  |   VARIANT    |    RETAINED UNTIL ACKNOWLEDGED BY   |
     |--------|--------------|-------------------------------------|
     |   CR   | both         |CC, DR or ER TPDU.                   |
     |        |              |                                     |
     |   DR   | both         |DC or DR (in case of collision) TPDU.|
     |        |              |                                     |
     |   CC   | confirmation |N-DATA Acknowledge indication, RJ,   |
     |        | of receipt   |DT, EA or ED TPDU.                   |
     |        | variant      |                                     |
     |        |              |                                     |
     |   CC   | AK variant   |RJ, DT, AK, ED or EA TPDU.           |
     |        |              |                                     |
     |   DT   | confirmation |N-DATA ACKNOWLEDGE indication cor-   |
     |        | of receipt   |responding to an N-DATA request which|
     |        | variant      |conveyed, or came after, the DT TPDU.|
     |        |              |                                     |
     |   DT   | AK variant   |AK or RJ TPDU for which the YR-TU-NR |
     |        |              |is greater than TPDU-NR in the DT    |
     |        |              |TPDU.                                |
     |        |              |                                     |
     |   ED   | both         |EA TPDU for which the YR-EDTU-NR is  |
     |        |              |equal to the ED-TPDU-NR in the       |
     |        |              |ED TPDU.                             |
     +-------------------------------------------------------------+

Table 5. Acknowledgement of TPDUs

59

     6.14  Resynchronization
     
     6.14.1  Purpose
     
     The resynchronization procedures are used in Classes 1 and  3  to
     restore  the  transport  connection  to  normal  after a reset or
     during reassignment after failure according to 6.12.
     
     6.14.2  Network service primitives
     
     The  procedure  makes  use  of  the  following  network   service
     primitive:

N-RESET indication.

     6.14.3  TPDUs and parameters used

The procedure uses the following TPDUs and parameters:

        a)  CR, DR, CC and DC TPDUs

b) RJ TPDUs;

• YR-TU-NR.

c) DT TPDU;

• TPDU-NR

d) ED TPDU;

• ED TPDU-NR.

e) EA TPDU;

• YR-EDTU-NR.

60

     6.14.4  Procedure
     
     A transport entity which is notified of the occurence  of  an  N-
     RESET   or  which  is  performing  'reassignment  after  failure'
     according to 6.12 shall carry out  the  active  resynchronization
     procedure (see 6.14.4.1) unless any of the following hold:

a) the transport entity is the responder (see note). In this

            case  the  passive  resynchronization procedure is carried
            out (see 6.14.4.2).
        
        b)  the transport entity has  elected  not  to  reassign  (see
            6.12.3.c).  In this case no resynchronization takes place.
     
     6.14.4.1  Active resynchronization procedures
     
     The Transport  entity  shall  carry  out  one  of  the  following
     actions:
     
        a)  if the TTR timer has been previously started and  has  run
            out  (i.e. no valid TPDU has been received), the transport
            connection is considered as released and the reference  is
            frozen (see 6.18).
     
        b)  otherwise, the TTR timer shall be started  (unless  it  is
            already running) and the first applicable of the following
            actions shall be taken:
     
            1)  if a CR TPDU is  unacknowledged,  then  the  transport
                entity shall retransmit it;
     
            2)  if a DR TPDU is  unacknowledged,  then  the  transport
                entity shall retransmit it;
     
            3)  otherwise, the transport entity shall  carry  out  the
                data resynchronization procedures (6.14.4.3).

The TTR timer is stopped when a valid TPDU is received.

61

     6.14.4.2  Passive resynchronization procedures
     
     The transport entity shall not send any TPDUs until  a  TPDU  has
     been received.  The transport entity shall start its TWR timer if
     it was not already started (due to a previous N-DISCONNECT or  N-
     RESET indication).  If the timer runs out prior to the receipt of
     a valid TPDU which commence resynchronization (i.e. CR or  DR  or
     RJ  TPDU)  the transport connection is considered as released and
     the reference is released (see 6.18).
     
     When a valid TPDU is received the transport entity shall stop its
     TWR  timer  and  carry  out  the appropriate one of the following
     actions, depending on the TPDU:

a) if it is a DR TPDU, then the transport entity shall send a

            DC TPDU;
        
        b)  if it is  a  repeated  CR  TPDU  (see  note  1)  then  the
            transport  entity  shall  carry out the appropriate action
            from the following:
        
            1)  if a CC TPDU has already been sent, and  acknowledged:
                treat as a protocol error;
        
            2)  if a DR TPDU is unacknowledged (whether or  not  a  CC
                TPDU  is  unacknowledged): retransmit the DR TPDU, but
                setting the source reference to zero;
        
            3)  if the T-CONNECT response has not  yet  been  received
                from the user:  take no action;
        
            4)  otherwise; retransmit  the  CC  TPDU  followed  by  an
                unacknowledged ED TPDU (see note 2) and any DT TPDU;
        
         NOTES
        
            1.  A repeated CR TPDU can be identified  by  being  on  a
                network   connection   with  the  appropriate  network
                addresses and having a correct source reference.

62

            2.  The transport entity should not use network  expedited
                until  the  CC  TPDU  is acknowledged (see 6.5).  This
                rule prevents the network  expedited  from  overtaking
                the CC TPDU.
        
        c)  if it is an RJ or  ED  TPDU  then  one  of  the  following
            actions shall be taken:
        
            1)  if a DR TPDU is  unacknowledged,  then  the  transport
                entity shall retransmit it;
        
            2)  otherwise, the transport entity shall  carry  out  the
                data resynchronization procedures (6.14.4.3).
        
            3)  If a CC TPDU was unacknowledge,  the  RJ  or  ED  TPDU
                should  then  be  considered  as  acknowledging the CC
                TPDU.  If a CC TPDU was never sent, the RJ TPDU should
                then be considered as a protocol error.
     
     6.14.4.3  Data Resynchronization Procedures

The transport entity shall carry out the following actions in the following order:

a) (re)transmit any ED TPDU which is unacknowledged,

b) transmit an RJ TPDU with YR-TU-NR field set to the TPDU-NR

of the next expected DT TPDU;

63

        c)  wait for the next TPDU from the  other  transport  entity,
            unless an RJ or DR TPDU has already been received; if a DR
            TPDU is received the transport entity  shall  send  a  DC,
            freeze   the   reference,   inform   the  TS-user  of  the
            disconnection and take no further action  (i.e.  it  shall
            not  follow  the procedures in 6.14.4.3.d).  If an RJ TPDU
            is  received,  the  procedure  of  6.14.4.3.d   shall   be
            followed.   If  an  ED  TPDU is received the procedures as
            described  in  6.11  shall  be  followed.   If  it  is   a
            duplicated  ED-TPDU the transport entity shall acknowledge
            it, with an EA TPDU, discard the duplicated  ED  TPDU  and
            wait again for the next TPDU.
        
        d)  (re)transmit  any  DT  TPDUs  which  are   unacknowledged,
            subject  to  any  applicable  flow control procedures (see
            note);

NOTE - The RJ TPDU may have reduced the credit.

     6.15  Multiplexing and demultiplexing
     
     6.15.1  Purpose
     
     The  multiplexing  and  demultiplexing  procedures  are  used  in
     Classes  2,  3  and  4  to allow several transport connections to
     share a network connection at the same time.
     
     6.15.2  TPDUs and parameters used

The procedure makes use of the following TPDUs and parameters:

        CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs

• DST-REF

64

     6.15.3  Procedure
     
     The transport entities shall be able to send and receive  on  the
     same  network  connection  TPDUs belonging to different transport
     connections.
     
     NOTES

1. When performing demultiplexing the transport connection to which the TPDUs apply is determined by the procedures defined in 6.9.

        2.  Multiplexing allows the concatenation of  TPDUs  belonging
            to  different  transport  connections to be transferred in
            the same N-DATA primitive (see 6.4).
     
     6.16  Explicit Flow Control
     
     6.16.1  Purpose
     
     The explicit flow control procedure is used in Classes 2, 3 and 4
     to  regulate  the  flow  of  DT  TPDUs  independently of the flow
     control in the other layers.
     
     6.16.2  TPDUs and parameters used

The procedure makes use of the following TPDUs and parameters:

        a)  CR, CC, AK and RJ TPDUs

• CDT.

b) DT TPDU

• TPDU-NR.

65

c) AK TPDU

            - YR-TU-NR;
            - subsequence number;
            - flow control confirmation.

d) RJ TPDU

• YR-TU-NR.

     6.16.3  Procedure
     
     The procedures differ in different classes.  They are defined  in
     the clauses specifying the separate classes.
     
     6.17  Checksum
     
     6.17.1  Purpose
     
     The checksum procedure is used to detect corruption of  TPDUs  by
     the NS-provider.
     
     NOTE - Although a checksum algorithm has to  be  adapted  to  the
     type  of  errors  expected  on the network connection, at present
     only one algorithm is defined.
     
     6.17.2  TPDUs and parameters used

The procedure uses the following TPDUs and parameters:

All TPDUs

• checksum

66

     6.17.3  Procedure
     
     The checksum is used only in Class 4.  It is always used for  the
     CR TPDU, and is used for all other TPDUs except if the non-use of
     the procedure was agreed during connection establishment.
     
     The sending  transport  entity  shall  transmit  TPDUs  with  the
     checksum  parameter  set  such  that  the  following formulas are
     satisfied:

SUM(from i=1 to i=L) OF a[i] EQUALS <zero> (module 255)

SUM(from i=1 to i=L) OF i*a[i] EQUALS <zero> (module 255)

     where
     
        i    = number (i.e. position) of an octet within the TPDU
               (see 13.2);
        a[i] = value of octet in position 1;
        L    = length of TPDU in octets.
     
     A  transport  entity  which  receives  a  TPDU  for  a  transport
     connection  for  which  the  use  of checksum has been agreed and
     which does not satisfy the above formulas shall discard the  TPDU
     (see also note 2).
     
     NOTES
     
        1.  An  efficient  algorithm  for  determining  the   checksum
            parameters is given in annex B.
     
        2.  If the checksum is incorrect, it is not possible  to  know
            with  certainty  to which transport connection the TPDU is
            related; further action may be taken for all the transport
            connections assigned to the network connection (see 6.9).

3. The checksum proposed is easy to calculate and so will not impose a heavy burden on implementations. However, it will not detect insertion or loss of leading or trailing zeros and will not detect some octets misordering.

67

     6.18  Frozen references
     
     6.18.1  Purpose
     
     This procedure is used in order to prevent re-use of a  reference
     while  TPDUs  associated  with  the  old use of the reference may
     still exist.
     
     6.18.2  Procedure
     
     When a transport entity determines that a  particular  connection
     is  released  it shall place the reference which it has allocated
     to the connection in a frozen state according to  the  procedures
     of the class.  While frozen, the reference shall not be re-used.
     
     NOTE - The  frozen  reference  procedure  is  necessary   because
     retransmission or misordering can cause TPDUs bearing a reference
     to arrive at an entity after it has released the  connection  for
     which  it  allocated the reference.  Retransmission, for example,
     can arise when the class includes either  resynchronization  (see
     6.14) or retransmission on time out (see 6.19).
     
     6.18.2.1  Procedure for classes 0 and 2

The frozen reference procedure is never used for these classes.

     NOTE - However for consistency with the  other  classes  freezing
     the references may be done as a local decision.

68

     6.18.2.2  Procedure for classes 1 and 3
     
     The frozen reference procedure is used except  in  the  following
     cases (see note 1):
     
        a)  when the transport entity receives a DC TPDU  in  response
            to a DR TPDU which it has sent (see note 2);
     
        b)  when the transport  entity  sends  a  DR  or  ER  TPDU  in
            response to a CR TPDU which it has received (see note 3);

c) when the transport entity has considered the connection to

            be  released  after  the  expiration of the TWR timer (see
            note 4);
        
        d)  when the transport entity receives a  DR  or  ER  TPDU  in
            response to a CR TPDU which it has sent.
     
     The period of time for which the reference remains  frozen  shall
     be greater than the TWR time.
     
     NOTES

1. However, even in these cases, for consistency freezing the reference may be done as a local decision.

        2.  When the DC TPDU is received it is certain that the  other
            transport entity considers the connection released.
        
        3.  When the DR or ER TPDU is sent the peer  transport  entity
            has not been informed of any reference assignment and thus
            cannot possibly make use of a reference (this includes the
            case where a CC TPDU was sent, but was lost).
        
        4.  In 6.18.2.c the transport entity has  already  effectively
            frozen the reference for an adequate period.

69

     6.18.2.3  Procedure for classes 4
     
     The frozen reference procedure is always used in  class  4.   The
     period  for  which the reference remains frozen should be greater
     than L (see 12.2.1.1.6).
     
     6.19  Retransmission on time-out
     
     6.19.1  Purpose

The procedure is used in Class 4 to cope with unsignalled loss of TPDUs by the NS-provider.

     6.19.2  TPDUs used

The procedure makes use of the following TPDUs:

CR, CC, DR, DT, ED, AK TPDUs.

     6.19.3  Procedure
     
     The procedure is specified in the procedures  for  Class  4  (see
     12.2.1.2.j).
     
     6.20  Resequencing

70

     6.20.1  Purpose
     
     The resequencing procedure is  used  in  Class  4  to  cope  with
     misordering of TPDUs by the network service provider.
     
     6.20.2  TPDUs and parameters used

The procedure uses the following TPDUs and parameters:

a) DT TPDU;

• TPDU-NR.

b) ED TPDU

• ED TPDU-NR

     6.20.3  Procedure
     
     The procedure is specified in the procedures  for  Class  4  (see
     12.2.3.5).
     
     6.21  Inactivity control
     
     6.21.1  Purpose
     
     The inactivity control procedure is used in Class 4 to cope  with
     unsignalled termination of a network connection.

71

     6.21.2  Procedure
     
     The procedure is specified in the procedures  for  Class  4  (see
     12.2.3.3).
     
     6.22  Treatment of protocol errors
     
     6.22.1  Purpose
     
     The procedure for treatment of protocol errors  is  used  in  all
     classes to deal with invalid TPDUs.
     
     6.22.2  TPDUs and parameters used

The procedure uses the following TPDUs and parameters:

a) ER TPDU;

- reject cause;
- TPDU in error.

b) DR TPDU;

• reason code.

     6.22.3  Procedure
     
     A transport entity that receives a TPDU that can be associated to
     a  transport  connection and is invalid or constitutes a protocol
     error (see 3.2.16 and 3.2.17) shall take  one  of  the  following
     actions  so  as not to jeopardize any other transport connections
     not assigned to that network connection:

a) ignoring the TPDU;

        b)  transmitting an ER TPDU;

72

c) resetting or closing the network connection; or

d) invoking the release procedures appropriate to the class.

     If an ER TPDU is sent in Class 0 it shall contain the  octets  of
     the  invalid  TPDU  up to and including the octet where the error
     was detected (see notes 3, 4 and 5).
     
     If the TPDU  cannot  be  associated  to  a  particular  transport
     connection then see 6.9.
     
     NOTES
     
        1.  In  general,  no  further  action  is  specified  for  the
            receiver  of  the  ER  TPDU  but it is recommended that it
            initiates the release procedure appropriate to the  class.
            If the ER TPDU has been received as an answer to a CR TPDU
            then the connection is regarded as released (see 6.6).
     
        2.  Care should be  taken  by  a  transport  entity  receiving
            several  invalid TPDUs or ER TPDUs to avoid looping if the
            error is generated repeatedly.
     
        3.  If the invalid received TPDU is greater than the  selected
            maximum  TPDU  size  it  is  possible  that  it  cannot be
            included in the invalid TPDU parameter of the ER TPDU.

4. It is recommended that the sender of the ER TPDU starts an optional timer TS2 to ensure the release of the connection. If the timer expires, the transport entity shall initiate the release procedures appropriate to the class. The timer should be stopped when a DR TPDU or an N-DISCONNECT indication is received.

        5.  In classes other  than  0,  it  is  recommended  that  the
            invalid TPDU be also included in the ER TPDU.

73

     6.23  Splitting and recombining
     
     6.23.1  Purpose
     
     This procedure is used only in  class  4  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.
     
     6.23.2  Procedure
     
     When this procedure is being used, a transport connection may  be
     assigned  (see 6.1) to multiple network connections (see note 1).
     TPDUs for the connection  may  be  sent  over  any  such  network
     connection.
     
     If the use of Class 4 is not accepted  by  the  remote  transport
     entity   following   the   negotiation  rules,  then  no  network
     connection except that over which the CR TPDU was sent  may  have
     this transport connection assigned to it.
     
     NOTES

1. The resequencing function of Class 4 (see 6.20) is used to ensure that TPDUs are processed in the correct sequence.

        2.  Either transport  entity  may  assign  the  connection  to
            further  network  connections  of which it is the owner at
            any time during the life of the transport connection.

74

        3.  In order to enable the detection  of  unsignalled  network
            connection   failures,   a   transport  entity  performing
            splitting should ensure that TPDUs are sent  at  intervals
            on  each  supporting  network  connection, for example, by
            sending   successive   TPDUs   on    successive    network
            connections,  where the set of network connections is used
            cyclically.  By  monitoring  each  network  connection,  a
            transport entity may detect unsignalled network connection
            failures, following the inactivity procedures  defined  in
            12.2.3.3.   Thus,  for each network connection no period I
            (see 12.2.3.1) may elapse without the receipt of some TPDU
            for some transport connection.

75

     7  Protocol Classes
     
     Table 6 gives an overview of  which  elements  of  procedure  are
     included  in  each  class.   In  certain  cases  the  elements of
     procedure within different classes are  not  identical  and,  for
     this  reason,  table  6  cannot  be  considered  as  part  of the
     definitive specification of the protocol.

KEY TO TABLE 6

     +---|---------------------------------------------------------+
     | * |Procedure always included in class                       |
     |---|---------------------------------------------------------|
     |   |Not applicable                                           |
     |---|---------------------------------------------------------|
     | m |Negotiable procedure whose implementation in equipment is|
     |   |mandatory                                                |
     |---|---------------------------------------------------------|
     | o |Negotiable procedure whose implementation in equipment is|
     |   |optional                                                 |
     |---|---------------------------------------------------------|
     | ao|Negotiable procedure whose implementation in equipment is|
     |   |optional and where use depends on availability within the|
     |   |network service                                          |
     |---|---------------------------------------------------------|
     |(1)|Not applicable in class 2 when non-use of explicit flow  |
     |   |control is selected                                      |
     |---|---------------------------------------------------------|
     |(2)|When non use of explicit flow control has been selected, |
     |   |multiplexing may lead to degradation of quality of       |
     |   |service                                                  |
     |---|---------------------------------------------------------|
     |(3)|This function is provided in class 4 using procedures    |
     |   |other than those in the cross reference.                 |
     +-------------------------------------------------------------+

76

     +----------------------------------------------------------------+
     |                             |Cross |            |  |  |  |  |  |
     |     Protocol Mechanism      |refe- |   Variant  | 0| 1| 2| 3| 4|
     |                             |rence |            |  |  |  |  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Assignment to network Conn. | 6.1  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | TPDU Transfer               | 6.2  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Segmenting and Reassembling | 6.3  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Concatenation and Separation| 6.4  |            |  | *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Connection Establishment    | 6.5  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Connection Refusal          | 6.6  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Normal Release              | 6.7  | implicit   | *|  |  |  |  |
     |                             |      | explicit   |  | *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Error Release               | 6.8  |            | *|  | *|  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Association of TPDUs with   |      |            |  |  |  |  |  |
     | Transport Connection        | 6.9  |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | DT TPDU Numbering           | 6.10 | normal     |  | *|m(1)m| m|
     |                             |      | extended   |  |  |o(1)o| o|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Expedited Data Transfer     | 6.11 | network    |  |  | *|  |  |
     |                             |      | normal     |  | m|(1) *| *|
     |                             |      | network    |  |  |  |  |  |
     |                             |      | expedited  |  |ao|  |  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Reassignment after failure  | 6.12 |            |  | *|  | *|(3)
     +----------------------------------------------------------------+

Table 6. (First of 2 pages) Allocation of procedures within classes

77

     +----------------------------------------------------------------+
     | Retention until Acknowledge-|      |Conf.Receipt|  |ao|  |  |  |
     | ment of TPDUs               | 6.13 |AK          |  | m|  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Resynchronisation           | 6.14 |            |  | *|  | *|(3)
     |-----------------------------|------|------------|--|--|--|--|--|
     | Multiplexing and            |      |            |  |  |(2)  |  |
     | Demultiplexing              | 6.15 |            |  |  | *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Explicit Flow Control With  | 6.16 |            |  |  | m| *| *|
     |                    Without  |      |            | *| *| o|  |  |
     |-----------------------------|------|------------|--|--|--|--|--|
     | Checksum (use of)           | 6.17 |            |  |  |  |  | m|
     |          (non-use of)       |      |            | *| *| *| *| o|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Frozen References           | 6.18 |            |  | *|  | *| *|
     |------------------------------------|------------|--|--|--|--|--|
     | Retransmission on Timeout   | 6.19 |            |  |  |  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Resequencing                | 6.20 |            |  |  |  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Inactivity Control          | 6.21 |            |  |  |  |  | *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Treatment of Protocol Errors| 6.22 |            | *| *| *| *| *|
     |-----------------------------|------|------------|--|--|--|--|--|
     | Splitting and Recombining   | 6.23 |            |  |  |  |  | *|
     +----------------------------------------------------------------+

Table 6. (2nd of 2 pages) Allocation of procedures within classes

78

     8  SPECIFICATION FOR CLASS 0. SIMPLE CLASS
     
     8.1  Functions of class 0
     
     Class 0 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.
     
     8.2  Procedures for class 0
     
     8.2.1  Procedures applicable at all times

The transport entities shall use the following procedures:

        a)  TPDU transfer (see 6.2);

b) association of TPDUs with transport connections (see 6.9);

        c)  treatment of protocol errors (see 6.22);

d) error release (see 6.8).

     8.2.2  Connection establishment

The transport entities shall use the following procedures:

a) assignment to network connection (see 6.1); then

        b)  connection establishment (see 6.5)  and,  if  appropriate,
            connection refusal (see 6.6);

subject to the following constraints:

79

c) the CR and CC TPDUs shall contain no parameter field other

than those for TSAP-ID and maximum TPDU size;

d) the CR and CC TPDUs shall not contain a data field.

     8.2.3  Data transfer
     
     The transport entities shall use the segmenting and  reassembling
     procedure (see 6.3).
     
     8.2.4  Release
     
     The transport entities shall use  the  implicit  variant  of  the
     normal release procedure (see 6.7).
     
     NOTE - the lifetime  of  the  transport  connection  is  directly
     correlated with the lifetime of the network connection.

80

     9  SPECIFICATION FOR CLASS 1: BASIC ERROR RECOVERY CLASS
     
     9.1  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 TS-user.
     
     9.2  Procedures for Class 1
     
     9.2.1  Procedures applicable at all times

The transport entities shall use the following procedures:

        a)  TPDU transfer (see 6.2);

b) association of TPDU with transport connections (see 6.9);

        c)  treatment of protocol errors (see 6.22);
        
        d)  reassignment after failure (see 6.12);
        
        e)  resynchronization  (see  6.14),  or   reassignment   after
            failure  (see  6.12)  together with resynchronization (see
            6.14);
        
        f)  concatenation and separation (see 6.4);
        
        g)  retention until acknowledgement of TPDU  (see  6.13);  the
            variant  used,  AK or confirmation of receipt, shall be as
            selected during connection establishment (see notes);

h) frozen references (see 6.18).

81

     NOTES
     
        1.  The  negotiation  of  the  variant  of   retention   until
            acknowledgement  of  TPDUs  procedure  to be used over the
            transport connection has been designed such  that  if  the
            initiator  proposes  the  use  of the AK variant (i.e. the
            mandatory implementation option),  the  responder  has  to
            accept  use  of  this option and if the initiator proposes
            use of the confirmation of receipt variant  the  responder
            is entitled to select use of the AK variant.
     
        2.  The AK variant makes use of AK TPDUs to release copies  of
            retained DT TPDUs.  The CDT parameter of AK TPDUs in class
            1 is not significant, and is set to 1111.

3. The confirmation of receipt variant is restricted to this class and its use depends on the availability of the network layer receipt confirmation service, and the expected cost reduction.

     9.2.2  Connection establishment

The transport entities shall use the following procedures:

a) assignment to network connection (see 6.1); then

        b)  connection establishment (see 6.5)  and,  if  appropriate,
            connection refusal (see 6.6).
     
     9.2.3  Data Transfer
     
     9.2.3.1  General

The sending transport entity shall use the following procedures;

        a)  segmenting (see 6.3); then

82

b) the normal format variant of DT TPDU numbering (see 6.10).

        The  receiving  transport  entity  shall  use  the   following
        procedures;

c) the normal variant of DT TPDU numbering (see 6.10,; then

d) reassembling (see 6.3).

     NOTES

1. The use of RJ TPDU during resynchronization (see 6.14) can lead to retransmission. Thus the receipt of a duplicate DT TPDU is possible; such a DT TPDU is discarded.

        2.  It is possible to decide on a local basis to issue  an  N-
            RESET request in order to force the remote entity to carry
            out the resynchronization (see 6.14).
     
     9.2.3.2  Expedited Data
     
     The transport entities shall use either the network  normal  data
     or  the network expedited variants of the expedited data transfer
     procedure (see 6.11)  if  their  use  has  been  selected  during
     connection establishment (see note 1).
     
     The sending transport entity shall  not  allocate  the  same  ED-
     TPDU-NR to successive ED TPDUs (see notes 2 and 3).
     
     When acknowledging  an  ED  TPDU  by  sending  and  EA  TPDU  the
     transport  entity  shall put into the YR-EDTU-NR parameter of the
     EA TPDU the value received in the ED-TPDU-NR parameter of the  ED
     TPDU.
     
     NOTES
     
        1.  The negotiation of the variant of expedited data  transfer
            procedure  to  be  used  over the transport connection has
            been designed such that if the initiator proposes the  use
            of  the  network  normal  data variant (i.e. the mandatory

83

            implementation option), the responder has to accept use of
            this  option  and  if  the  initiator  proposes use of the
            network expedited variant, the responder  is  entitled  to
            select use of the network normal data variant.
        
        2.  This numbering enables the receiving transport  entity  to
            discard  repeated  ED  TPDUs  when  resynchronization (see
            6.14) has taken place.
        
        3.  No other  significance  is  attached  to  the  ED  TPDU-NR
            parameter.  It is recommended, but not essential, that the
            values used be consecutive modulo 128.
     
     9.2.4  Release
     
     The transport entities shall use  the  explicit  variant  of  the
     release procedure (see 6.7).

84

     10  SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS
     
     10.1  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 connection resets or  disconnects,  the  transport
     connection  is terminated without the transport release procedure
     and the TS-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.
     
     10.2  Procedures for class 2
     
     10.2.1  Procedures applicable at all times

The transport entities shall use the following procedures

a) association of TPDUs with transport connection (see 6.9);

        b)  TPDU transfer (see 6.2);
        
        c)  treatment of protocol errors (see 6.22);
        
        d)  concatenation and separation (see 6.4);

e) error release (see 6.8).

        Additionally the transport  entities  may  use  the  following
        procedure:

f) multiplexing and demultiplexing (see 6.15).

85

     10.2.2  Connection establishment

The transport entities shall use the following procedures:

a) assignment to network connection (see 6.1); then

        b)  connection establishment  (see  6.5)  and,  if  applicable
            connection refusal (see 6.6).
     
     10.2.3  Data transfer when non use of explicit flow control
     
             has been selected
     
     If this option has been selected as a result  of  the  connection
     establishment,  the  transport  entities shall use the segmenting
     procedure (see 6.3).

The TPDU-NR field of DT TPDUs is not significant and may take any value.

NOTE- -Expedited data transfer is not applicable (see 6.5).

     10.2.4  Data transfer when use of explicit flow control
     
             has been selected
     
     10.2.4.1  General

The sending transport entity shall use the following procedures:

        a)  segmenting (see 6.3); then
        
        b)  DT TPDU numbering (see 6.10);

86

        The  receiving  transport  entity  shall  use  the   following
        procedures:
        
        c)  DT TPDU numbering (see 6.10); if a  DT  TPDU  is  received
            which is out of sequence it shall be treated as a protocol
            error; then

d) reassembling (see 6.3).

        The variant of the DT TPDU numbering which  is  used  by  both
        transport   entities   shall  be  that  which  was  agreed  at
        connection establishment.
     
     10.2.4.2  Flow control
     
     The transport entities shall send an initial credit (which may be
     zero)  in  the  CDT  field  of  the  CR  or CC TPDU.  This credit
     represents the initial value of the upper window  edge  allocated
     to the peer entity.
     
     The transport entity that receives the CR or the  CC  TPDU  shall
     consider its lower window edge as zero, and its upper window edge
     as the value of the CDT field in the received TPDU.
     
     In order to authorize the transmission of DT TPDUs, by its  peer,
     a  transport  entity may transmit an AK TPDU at any time, subject
     to the following constraints:
     
        a)  the YR-TU-NR parameter shall be at most one  greater  than
            the TPDU-NR field of the last received DT TPDU or shall be
            zero if no DT TPDU has been received;
     
        b)  if an AK TPDU has previously been sent the  value  of  the
            YR-TU-NR  parameter  shall  not  be lower than that in the
            previously sent AK TPDU.
     
        c)  the sum of the YR-TU-NR and CDT fields shall not  be  less
            than  the upper window edge allocated to the remote entity
            (see note 1).

87

     A transport entity which receives an AK TPDU shall  consider  the
     YR-TU-NR  field  as its new lower window edge, and the sum of YR-
     TU-NR and CDT as its new upper window edge.  If either  of  these
     have  been  reduced  or  if the lower window edge has become more
     than one greater than the TPDU-NR  of  the  last  transmitted  DT
     TPDU, this shall be treated as a protocol error (see 6.22).
     
     A transport entity shall not  send  a  DT  TPDU  with  a  TPDU-NR
     outside of the transmit window (see notes 2 and 3).
     
     NOTES

1. This means that credit reduction is not applicable.

        2.  This means that a transport entity  is  required  to  stop
            sending  if  the  TPDU-NR  field of the next DT TPDU which
            would be sent would be the upper window edge.  Sending  of
            DT  TPDU  may  be  resumed if an AK TPDU is received which
            increases the upper window edge.
        
        3.  The rate at which a transport entity progresses the  upper
            window  edge  allocated  to its peer entity constrains the
            throughput attainable on the transport connection.
     
     10.2.4.3  Expedited data
     
     The transport entities shall follow the network normal variant of
     the expedited data transfer procedure in 6.11 if its use has been
     agreed  during  connection  establishment.   ED  and   EA   TPDUs
     respectively  are  not  subject to the flow control procedures in
     10.2.4.2.  The ED-TPDU-NR and YR-ETDU-NR  fields  of  ED  and  EA
     TPDUs respectively are not significant and may take any value.

88

     10.2.5  Release
     
     The transport entities shall use  the  explicit  variant  of  the
     release procedure in 6.7.

89

     11  SPECIFICATION FOR CLASS 3: ERROR  RECOVERY  AND  MULTIPLEXING
     CLASS
     
     11.1  Functions of Class 3
     
     Class 3 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.
     
     11.2  Procedures for Class 3
     
     11.2.1  Procedures applicable at all times

The transport entities shall use the following procedures:

a) association of TPDUs with transport connections (see 6.9);

        b)  TPDU   transfer   (see   6.2)    and    retention    until
            acknowledgement of TPDUs (AK variant only) (see 6.13);
        
        c)  treatment of protocol errors (see 6.22);
        
        d)  concatenation and separation (see 6.4);
        
        e)  reassignment  after  failure  (see  6.12),  together  with
            resynchronization (see 6.14);

f) frozen references (see 6.18).

     Additionally,  the  transport  entities  may  use  the  following
     procedure:
     
        g)  multiplexing and demultiplexing (see 6.15);

90

     11.2.2  Connection Establishment

The transport entities shall use the following procedures;

a) assignment to network connections (see 6.1); then

        b)  connection establishment (see 6.5)  and,  if  appropriate,
            together with connection refusal (see 6.6).
     
     11.2.3  Data Transfer
     
     11.2.3.1  General

The sending transport entity shall use the following procedures:

        a)  segmenting (see 6.3), then
        
        b)  DT TPDU numbering (see 6.10); after receipt of an RJ  TPDU
            (see  11.2.3.2)  the  next  DT  TPDU to be sent may have a
            value which is not the previous value of TPDU-NR plus one.
     
     The  receiving  transport  entity   shall   use   the   following
     procedures:
     
        c)  DT TPDU numbering (see 6.10); the TPDU-NR  field  of  each
            received  DT  TPDU shall be treated as a protocol error if
            it exceeds the greatest such value received in a  previous
            DT TPDU by more than one (see note); then
     
        d)  reassembling  (see  6.3);  duplicated   TPDUs   shall   be
            eliminated before reassembling is performed.
     
     NOTE - The  use  of  RJ  TPDUs  (see  11.2.3.2)   can   lead   to
     retransmission and reduction of credit.  Thus the receipt of a DT
     TPDU which is a duplicate, or which is greater than or  equal  to
     the  upper  window edge allocated to the peer entity, is possible
     and is therefore not treated as a protocol error.

91

     11.2.3.2  Use of RJ TPDU
     
     A transport entity may send an RJ TPDU at any time  in  order  to
     invite   retransmission  or  to  reduce  the  upper  window  edge
     allocated to the peer entity (see note 1).
     
     When an RJ TPDU is  sent,  the  following  constraints  shall  be
     respected:
     
        a)  the YR-TU-NR parameter shall be at most one  greater  than
            the greatest such value received in a previous DT TPDU, or
            shall be zero if no DT TPDU has  yet  been  received  (see
            note 2);
     
        b)  if an AK or RJ TPDU has previously been sent the  YR-TU-NR
            parameter  shall  not be lower than that in the previously
            sent AK or RJ TPDU or lower than zero if no AK or RJ TPDU.

When a transport entity receives an RJ TPDU (see note 3):

        c)  the next DT TPDU  to  be  transmitted,  or  retransmitted,
            shall be that for which the value of the TPDU-NR parameter
            is equal to the value of the YR-TU-NR parameter of the  RJ
            TPDU;
        
        d)   the sum of the values of the YR-TU-NR and CDT  parameters
            of the RJ TPDU becomes the new upper window edge (see note
            4).
     
     NOTES
     
        1.  An  RJ  TPDU  can  also   be   sent   as   part   of   the
            resynchronization   (see   6.14)  and  reassignment  after
            failure (see 6.12) procedures.
     
        2.  It is recommended that the YR-TU-NR parameter be equal  to
            the TPDU-NR parameter of the next expected DT TPDU.

3. These rules are a subset of those specified for when an RJ TPDU is received during resynchronization (see 6.14) and reassignment after failure (see 6.12).

92

        4.  This means that RJ TPDU can be used to  reduce  the  upper
            window   edge   allocated   to  the  peer  entity  (credit
            reduction).
     
     11.2.3.3  Flow Control

The procedures shall be as defined in 10.2.4.2, except that:

        a)  a credit reduction may lead to the reception of a DT  TPDU
            with  a  TPDU-NR  parameter  whose value is not, but would
            have been less than the upper window edge allocated to the
            remote  entity  prior to the credit reduction.  This shall
            not be treated as a protocol error;
     
        b)  receipt of an AK TPDU which sets  the  lower  window  edge
            more  than  one  greater  than  the  TPDU-NR  of  the last
            transmitted DT TPDU shall not be  treated  as  a  protocol
            error,  provided  that all acknowledged DT TPDUs have been
            previously transmitted (see notes 1 and 2).
     NOTES
     
        1.  This  can  only  occur  during  retransmission   following
            receipt of an RJ TPDU.

2. The transport entity may either continue retransmission as before or retransmit only those DT TPDUs, not acknowledged by the AK TPDU. In either case, copies of the acknowledged DT TPDUs, need not be retained further.

     11.2.3.4  Expedited data
     
     The transport entities  shall  follow  the  network  normal  data
     variant  of  expedited data transfer procedure in 6.11 if its use
     has been agreed during connection establishment.
     
     The sending transport entity shall  not  allocate  the  same  ED-
     TPDU-NR to successive ED TPDUs.

93

     The receiving transport entity shall transmit an EA TPDU with the
     same  value  in  its YR-EDTU-NR parameter.  If, and only if, this
     number is different from that of the previously received ED  TPDU
     shall  it  generate  a  T-EXPEDITED DATA indication to convey the
     data to the TS-user (see note 2).
     
     NOTES
     
        1.  No  other  significance  is  attached  to  the  ED-TPDU-NR
            parameter.  It is recommended, but not essential, that the
            values be consecutive modulo 2**n, where n is  the  number
            of bits of the parameter.
     
        2.  This procedure ensures that the TS-user does  not  receive
            data corresponding to the same ED TPDU more than once.
     
     11.2.4  Release
     
     The transport entities shall use  the  explicit  variant  of  the
     release procedure in 6.7.

94

     12  SPECIFICATION FOR CLASS 4: ERROR DETECTION AND RECOVERY CLASS
     
     12.1  Functions of Class 4
     
     Class 4 provides the functionality of Class 3, plus  the  ability
     to  detect  and recover from lost, duplicated, or out of sequence
     TPDUs without involving the TS-user.
     
     This detection of errors is made by extended use of the  DT  TPDU
     numbering  of Class 2 and Class 3, by time-out mechanisms, and by
     additional procedures.
     
     This class additionally detects and recovers from  damaged  TPDUs
     by using a checksum mechanism.  The use of the checksum mechanism
     must be available but its  use  or  its  non-use  is  subject  to
     negotiation.
     
     Further on this  class  provides  additional  resilience  against
     network failure and increased throughput capability by allowing a
     transport connection to make use of multiple network connections.
     
     12.2  Procedures for Class 4
     
     12.2.1  Procedures available at all times
     
     12.2.1.1  Timers used at all times

This subclause defines timers that apply at all times in class 4. These timers are listed in table 7.

     This International Standard does not define specific  values  for
     the  timers,  and the derivations described in this subclause are
     not mandatory.  The values should be chosen so that the  required
     quality   of   service   can   be   provided,   given  the  known
     characteristics of the network.
     
     Timers that apply only to specific procedures are  defined  under
     the appropriate procedure.

95

     +---------------------------|------------------------------------+
     |Symbol|        Name        |            Definition              |
     |------|--------------------|------------------------------------|
     | MLR  |NSDU lifetime       | A bound for the maximum time which |
     |      |local-to-remote     | may elapse between the transmis-   |
     |      |                    | sion of an NSDU by a local trans-  |
     |      |                    | port entity and the receipt of any |
     |      |                    | copy of it by a remote peer entity.|
     |      |                    |                                    |
     | MRL  |NSDU lifetime       | A bound for the maximum time which |
     |      |remote-to-local     | may elapse between the transmission|
     |      |                    | of an SNDU from a remote transport |
     |      |                    | entity to a remote peer entity.    |
     |      |                    |                                    |
     | ELR  |Expected maximum    | A bound for the maximum delay suf- |
     |      |transit delay       | fered by all but a small proportion|
     |      |local-to-remote     | of NSDUs transferred from the local|
     |      |                    | transport entity to a remote peer  |
     |      |                    | entity.                            |
     |      |                    |                                    |
     | ERL  |Expected maximum    | A bound for the maximum delay suf- |
     |      |transit delay       | fered by all but a small proportion|
     |      |remote-to-local     | of NSDUs transferred from a remote |
     |      |                    | transport entity to the local peer |
     |      |                    | entity.                            |
     |      |                    |                                    |
     |  AL  |Local acknowledge   | A bound for the maximum time which |
     |      |time                | can elapse between the receipt of  |
     |      |                    | a TPDU by the local transport en-  |
     |      |                    | tity from the network layer and    |
     |      |                    | the transmission of the corres-    |
     |      |                    | ponding acknowledgement.           |
     |      |                    |                                    |
     |  AR  |Remote acknow-      | As AL, but for the remote entity.  |
     |      |ledgement time      |                                    |
     +----------------------------------------------------------------+

Table 7. (First of 2 pages) Time Parameters related to class 4

96

     +----------------------------------------------------------------+
     |  T1  |Local retrans-      | A bound for the maximum time that  |
     |      |mission time        | the local transport entity will    |
     |      |                    | wait for acknowledgement before re-|
     |      |                    | transmitting a TPDU.               |
     |      |                    |                                    |
     |  R   |Persistence time    | A bound for the maximum time the   |
     |      |                    | the local transport entity will    |
     |      |                    | continue to transmit a TPDU that   |
     |      |                    | requires acknowledgement.          |
     |      |                    |                                    |
     |  N   |Maximum number of   | A bound for the maximum number of  |
     |      |transmissions       | times which the local transport    |
     |      |                    | entity will continue to transmit a |
     |      |                    | TPDU that requires acknowledgement.|
     |      |                    |                                    |
     |  L   |Bound on references | A bound for the maximum time       |
     |      |and sequence        | between the transmission of a TPDU |
     |      |numbers             | and the receipt of any acknow-     |
     |      |                    | ledgement relating to it.          |
     |      |                    |                                    |
     |  I   |Inactivity time     | A bound for the time after which   |
     |      |                    | a transport entity will, if it     |
     |      |                    | does not receive a TPDU, initiate  |
     |      |                    | the release procedure to terminate |
     |      |                    | the transport connection.          |
     |      |                    |                                    |
     |      |                    | NOTE - This parameter is required  |
     |      |                    | for protection against unsignalled |
     |      |                    | breaks in the network connection.  |
     |      |                    |                                    |
     |  W   |Window time         | A bound for the maximum time a     |
     |      |                    | transport entity will wait before  |
     |      |                    | retransmitting up to date window   |
     |      |                    | information.                       |
     +----------------------------------------------------------------+

Table 7. (Second of 2 pages) Time Parameters related to class 4

97

     12.2.1.1.1  NSDU lifetime (MLR, MRL)
     
     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 may be different in  each  direction  of
     transfer  through  a network between two transport entities.  The
     values, for both directions of transfer, are assumed to be  Known
     by  the  transport entities.  The maximum NSDU lifetime local-to-
     remote (MLR) is the maximum time which  may  elapse  between  the
     transmission  of  an  NSDU from the local transport entity to the
     network and receipt of any copy of the NSDU from the  network  at
     the  remote  transport entity.  The maximum NSDU lifetime remote-
     to-local (MRL) is the maximum time which may elapse  between  the
     transmission  of  an NSDU from the remote transport entity to the
     network and receipt of any copy of the NSDU from the  network  at
     the local transport entity.
     
     12.2.1.1.2  Expected maximum transit delay (ELR, ERL)
     
     The network layer is assumed to provide,  as  an  aspect  of  its
     grade  of service, an expected maximum transit delay for NSDUs in
     the network.  This value may be different in  each  direction  of
     transfer  through  a network between two transport entities.  The
     values, for both directions of transfer, are assumed to be  Known
     by  the  transport  entities.  The expected maximum transit delay
     local-to-remote (ELR) is the maximum delay suffered by all but  a
     small  proportion  of  NSDUs transferred through the network from
     the local transport entity to the remote transport  entity.   The
     expected  maximum  transit  delay  remote-to-local  (ERL)  is the
     maximum delay suffered by all but a  small  proportion  of  NSDUs
     transfer  through the network from the remove transport entity to
     the local transport entity.

98

     12.2.1.1.3  Acknowledge Time (AR, AL)
     
     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  transmission  of  the  corresponding
     response.   This  value  is referred to as AL.  The corresponding
     time given by the remote transport entity is referred to as AR.
     
     12.2.1.1.4  Local retransmission time (T1)
     
     The local transport entity is assumed to maintain a bound on  the
     time  it  will  wait for an acknowledgement before retransmitting
     the TPDU.  Its value is given by:
     
        T1 = ELR + ERL + AR + X

where:

        ELR = Expected maximum transit delay local-to-remote,
        ERL = Expected maximum transit delay remote-to-local,
        AR  = Remote acknowledge time, and
        X   = local processing time for a TPDU.
     
     12.2.1.1.5  Persistence Time (R)
     
     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 acknowledgement.  This value is referred to as
     R.
     
     The  value  is  clearly  related  to  the  time  elapsed  between
     retransmission,  T1,  and the maximum number of transmissions, N.
     It is not less than T1 * N + X, where X is a  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.

99

     12.2.1.1.6  Bound on References and Sequence Numbers (L)
     
     A bound for the maximum time between the decision to  transmit  a
     TPDU  and the receipt of any response relating to it (L) is given
     by:
     
        L = MLR + MRL + R + AR

where:

        MLR = NSDU lifetime local-to-remote,
        MRL = NSDU lifetime remote-to-local,
        R   = Persistence time, and
        AR  = Remote acknowledgement time.
     
     It is necessary to  wait  for  a  period  L  before  reusing  any
     reference  of  sequence number, to avoid confusion in case a TPDU
     referring to it may be duplicated or delayed.
     
     NOTES

1. In practice, 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.

        2.  The  relationships  between  times  discussed  above   are
            illustrated in figures 3 and 4.

[Figures 3 and 4 are omitted from this copy.]

     12.2.1.2  General Procedures

The transport entity shall use the following procedures:

        a)  TPDU transfer (see 6.2);

b) association of TPDUs with transport connections (see 6.9);

100

        c)  treatment of protocol errors (see 6.22);

d) checksum (see 6.17);

        e)  splitting and recombining (see 6.23);
        
        f)  multiplexing and demultiplexing (see 6.15);

g) retention until acknowledgement of TPDUs (see 6.13);

h) frozen references (see 6.18).

        j)  retransmission procedures; when  a  transport  entity  has
            some  outstanding  TPDUs  that require acknowledgement, it
            will check that no T1 interval elapses without the arrival
            of   a   TPDU  that  acknowledges  at  least  one  of  the
            outstanding TPDUs.
        
            If  the  timer  expires,  except  if  the   TPDU   to   be
            retransmitted  is a DT TPDU and it is outside the transmit
            window  due  credit   reduction,   the   first   TPDU   is
            retransmitted   and  the  timer  is  restarted.   After  N
            transmissions (i.e. N-1  retransmissions)  it  is  assumed
            that  useful  two-way  communication is no longer possible
            and the release procedure is  used,  and  the  TS-user  is
            informed.
        
        NOTES

1. This procedure may be implemented by different means. For example:

            a)  one interval is associated with  each  TPDU.   If  the
                timer  expires the associated TPDU will be transmitted
                and the timer T1 will be restarted for all  subsequent
                TPDUs; or
            
            b)  one  interval  is  associated  with   each   transport
                connection:

1. if the transport entity transmits a TPDU requiring acknowledgement, it starts timer T1;

101

                2)  if the  transport  entity  receives  a  TPDU  that
                    acknowledges  one of the TPDUs to be acknowledged,
                    it restarts timer T1 unless the received  TPDU  is
                    an AK which explicitly closes the transmit window.
                
                3)  if the  transport  entity  receives  a  TPDU  that
                    acknowledges  the last TPDU to be acknowledged, it
                    stops timer T1.
            
            For a decision whether  the  retransmission  timer  T1  is
            maintained  on a per TPDU or on a per transport connection
            basis, throughput considerations have  to  be  taken  into
            account.
        
        2.  For DT TPDUs it is a local  choice  to  retransmit  either
            only  the  first  DT  TPDU  or  all  TPDUs  waiting for an
            acknowledgement up to the upper window edge.

3. It is recommended that after N transmissions of a DT TPDU, the transport entity waits T1 + W + MRL to provide a higher possibility of receiving an acknowledgement before entering the release phase. For other TPDU types which may be retransmitted, it is recommended that after N transmissions the transport entity waits T1 + MRL to provide a higher possibility of receiving the expected reply.

     12.2.2  Procedures for Connection Establishment
     
     12.2.2.1  Timers used in Connection Establishment

There are no timers specific to connection establishment.

102

     12.2.2.2  General Procedures

The transport entities shall use the following procedures:

        a)  assignment to network connection (see 6.1);
        
        b)  connection establishment  (see  6.5)  and  if  appropriate
            connection  refusal (see 6.6) together with the additional
            procedures:
        
            1)  a connection is not considered established  until  the
                successful  completion  of a 3-way TPDU exchange.  The
                sender of a CR TPDU shall respond to the corresponding
                CC  TPDU  by  immediately  sending  a DT, ED, DR or AK
                TPDU;
        
            2)  as a result of duplication  or  retransmission,  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,  or  is waiting for the T-CONNECT
                response from the  TS-user,  the  receiving  transport
                entity  shall ignore such a TPDU.  Otherwise a CC TPDU
                shall be transmitted;
        
            3)  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  shall  only  acknowledge the duplicate CC TPDU
                according to the procedure in 12.2.2.2.b.1.

4. a CC TPDU may be received specifying a reference which is in the frozen state. The response to such a TPDU shall be a DR TPDU;

            5)  the retransmission procedures (see 12.2.1.2) are  used
                for both the CR TPDU and CC TPDU.

103

     12.2.3  Procedures for Data Transfer
     
     12.2.3.1  Timers used in Data Transfer

The data transfer procedures use two additional timers:

a) Inactivity Time (I)

        To  protect  against  unsignalled  breaks   in   the   network
        connection  or failure of the peer transport entity (half-open
        connections), each transport entity  maintains  an  inactivity
        interval.  The interval must be greater than E.

NOTE - A suitable value for I is given by
2 * (N * maximum of (T1, W))
unless local needs indicate another more appropriate value.

b) Window Time (W)

        A transport entity maintains a timer interval to  ensure  that
        there  is  a  bound  on  the  maximum  interval between window
        updates.
     
     12.2.3.2  General Procedures for data transfer

The transport entities shall use the following procedures:

        a)  inactivity control    (see 6.21);
        
        b)  expedited data        (see 6.11);

c) explicit flow control (see 6.16).

     The sending transport entity shall use the  following  procedures
     in the following order:
     
        d)  segmenting            (see 6.3);
     
        e)  DT TPDU numbering     (see 6.10).

104

The receiving transport entity shall use the following procedures in the following order:

        f)  DT TPDU numbering     (see 6.10);
        
        g)  resequencing          (see 6.20);
        
        h)  reassembling          (see 6.3).
     
     12.2.3.3  Inactivity Control
     
     If the interval of the inactivity timer I expires without receipt
     of  some  TPDU,  the  transport entity shall initiate the release
     procedures.   To  prevent  expiration  of  the  remote  transport
     entity's  inactivity  timer when no data is being sent, the local
     transport entity must send AK TPDUs at suitable intervals in  the
     absence  of  data, having regard to the probability of TPDU loss.
     The window synchronization procedures (see 12.2.3.8) ensure  that
     this requirement is met.
     
     NOTE - It is likely that the release procedure initiated  due  to
     the  expiration  of  the  inactivity  timer  will  fail,  as such
     expiration indicates probable failure of the  supporting  network
     connection or of the remote transport entity.
     
     12.2.3.4  Expedited Data
     
     The transport entities  shall  follow  the  network  normal  data
     variant  of the expedited data transfer procedures (see 6.11), if
     the use of transport expedited service  option  has  been  agreed
     during connection establishment.
     
     The ED TPDU shall have  a  TPDU-NR  which  is  allocated  from  a
     separate sequence space from that of the DT TPDUs.
     
     A transport entity shall allocate the sequence number zero to the
     ED  TPDU-NR  of  the  first  ED  TPDU  which  it  transmits for a

105

     transport connection.  For subsequent ED TPDU sent  on  the  same
     transport  connection,  the  transport  entity  shall  allocate a
     sequence number one greater than the previous one.
     
     Modulo 2**7 arithmetic shall be used  when  normal  formats  have
     been  selected  and  modulo  2**31  arithmetic shall be used when
     extended formats have been selected.
     
     The receiving transport entity shall transmit an EA TPDU with the
     same  sequence number in its YR-ETDU-NR field.  If this number is
     one greater than in the previously in sequence received ED  TPDU,
     the  receiving transport entity shall transfer the data in the ED
     TPDU to the TS-user.
     
     If  a  transport  entity  does  not  receive  an   EA   TPDU   in
     acknowledgement  to an ED TPDU it shall follow the retransmission
     procedures (see note and 12.2.1.2).
     
     The sender of an ED TPDU shall not send  any  new  DT  TPDU  with
     higher TPDU-NR until it receives the EA TPDU.
     
     NOTE - This procedure ensures that ED TPDUs are delivered to  the
     TS-user  in  sequence  and that the TS-user does not receive data
     corresponding to the same  ED  TPDU  more  than  once.   Also  it
     guarantees  the  arrival  of  the ED TPDU before any subsequently
     sent DT TPDU.
     
     12.2.3.5  Resequencing

The receiving transport entity shall deliver all DT TPDUs to the TS-user in the order specified by the sequence number field.

     DT TPDUs received out-of-sequence but within the transmit  window
     shall not be delivered to the TS-user until all in-sequence TPDUs
     have been received.  DT TPDU received out-of-sequence and outside
     the transmit window shall be discarded.
     
     Duplicate TPDUs can  be  detected  because  the  sequence  number
     matches  that  of  preciously  received  TPDUs.  Sequence numbers
     shall not be reused for the period L after  their  previous  use.

106

     Otherwise,  a new, valid TPDU could be confused with a duplicated
     TPDU which had previously been received and acknowledged.
     
     Duplicated DT TPDUs shall be acknowledged, since  the  duplicated
     TPDU  may  be  the  result of a retransmission resulting from the
     loss of an AK TPDU.

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

     12.2.3.6  Explicit Flow Control
     
     The transport entities shall send an initial  credit  (which  may
     take  the  value  0)  in the CDT field of the CR TPDU or CC TPDU.
     This credit represents the initial value of the upper window edge
     of the peer entity.
     
     The transport entity which receives the CR TPDU or CC TPDU  shall
     consider  its lower window edge as zero and its upper window edge
     as the value in the CDT field in the received TPDU.

In order to authorize the transmission of DT TPDUs by its peer, a transport entity may transmit an AK TPDU at any time.

     The sequence number of an AK TPDU shall not exceed  the  sequence
     number of the next expected DT TPDU, i.e. it shall not be greater
     than the highest sequence number of a received DT TPDU, plus one.
     
     A transport entity may send a duplicate AK  TPDU  containing  the
     same  sequence  number,  CDT, and subsequence number field at any
     time.
     
     A transport entity which receives an AK TPDU shall  consider  the
     value of the YR-TU-NR field as its new lower window edge if it is
     greater than any previously received in a YR-TU-NR field, and the
     sum  of  YR-TU-NR and CDT as its new upper window edge subject to
     the  procedures  for  sequencing  AK  TPDUs  (see  12.2.3.8).   A
     transport  entity shall not transmit or retransmit a DT TPDU with
     a sequence number outside the transmit window.

107

     12.2.3.7  Sequencing of received AK TPDUs
     
     To allow a receiving transport  entity  to  properly  sequence  a
     series  of AK TPDUs that all contain the same sequence number and
     thereby use the  correct  CDT  value,  AK  TPDUs  may  contain  a
     subsequence  parameter.   For  the  purpose  of  determining  the
     correct sequence of AK TPDUs,  the  absence  of  the  subsequence
     parameter  shall  be equivalent to the value of the parameter set
     to zero.

An AK TPDU is defined to be in sequence if:

        a)  the sequence number is  greater  than  in  any  previously
            received AK TPDU, or
        
        b)  the sequence  number  is  equal  to  the  highest  in  any
            previously received AK TPDU, and the subsequence parameter
            is greater than in any previously received AK TPDU  having
            the same value for YR-TU-NR field, or
        
        c)  the sequence number and  subsequence  parameter  are  both
            equal  to  the  highest in any previously received AK TPDU
            and the credit field is greater than or equal to  that  in
            any  previously  received AK TPDU having the same YR-TU-NR
            field.
     
     A transport entity is not required  to  include  the  subsequence
     number  in  its  AK  TPDUs.   It  may  also choose not to use the
     subsequence parameter in sequencing  received  AK  TPDUs.   If  a
     transport   entity  chooses  not  to  recognize  the  subsequence
     parameter it shall still sequence received AK TPDUs according  to
     12.2.3.7.a.

When the receiving transport entity recognizes an out of sequence AK TPDU it shall ignore it.

108

     12.2.3.8  Procedure for transmission of AK TPDUs
     
     12.2.3.8.1  Retransmission of AK TPDUs for window synchronization
     
     A transport entity shall not allow an interval W to pass  without
     the  transmission  of an AK TPDU.  if the transport entity is not
     using  the  procedure  following  setting  CDT   to   zero   (see
     12.2.3.8.3)   or   reduction   of  the  upper  window  edge  (see
     12.2.3.8.4), and does not have to acknowledge receipt of  any  DT
     TPDU,  then  it  shall achieve this by retransmission of the most
     recent AK TPDU, with up-to-date window information.
     
     NOTE - The use  of  the  procedures  defined  in  12.2.3.8.3  and
     12.2.3.8.4  are  optional for any transport entity.  The protocol
     operates correctly either with or without these procedures  which
     are defined to enhance the efficiency of its operation.  However,
     if these procedures are not used then W must  be  set  to  ensure
     enough  retransmissions  of  the AK TPDU so that release of TC is
     avoided.    The   value   of   W    should    be    approximately
     W = (T1 * N)/(N-1) when the procedures are not used.
     
     12.2.3.8.2  Sequence control for transmission of AK TPDUs
     
     To allow the receiving transport entity to process  AK  TPDUs  in
     the  correct  sequence, as described in 12.2.3.7, the subsequence
     parameter may be included following reduction  of  CDT.   If  the
     value  of  the subsequence number to be transmitted is zero, then
     the parameter should be omitted.
     
     The value of the subsequence parameter, if used,  shall  be  zero
     (either  explicitly  or  by  absence  of  the  parameter)  if the
     sequence number is greater than the field in previous  AK  TPDUs,
     sent by the transport entity.
     
     If the sequence number is the same as the previous AK  TPDU  sent
     and  the  CDT  field is equal to or greater than the CDT field in
     the previous AK TPDU sent  then  the  subsequence  parameter,  if
     used, shall be equal to that in the previously sent AK TPDU.
     
     If the sequence number is the same as the previous AK  TPDU  sent

109

     and  the CDT field is less than the value of the CDT field in the
     previous AK TPDU sent than the subsequence  parameter,  if  used,
     shall be one greater than the value in the previous AK TPDU..
     
     12.2.3.8.3  Retransmission of AK TPDUs after CDT set to zero
     
     Due to the possibility of loss of AK TPDUs, the upper window edge
     as  perceived by the transport entity transmitting an AK TPDU may
     differ from that perceived by the intended recipient.   To  avoid
     the possibility of extra delay, the retransmission procedure (see
     12.2.1.2) should be followed for an AK  TPDU,  if  it  opens  the
     transmit window which has previously been closed by sending an AK
     TPDU with CDT field set to zero.
     
     The  retransmission  procedure,  if  used,  terminates  and   the
     procedure in 12.2.3.8.1 is used when:
     
        a)  an  AK  TPDU  is  received  containing  the  flow  control
            confirmation  parameter,  whose lower window edge and your
            subsequence fields are equal to the  sequence  number  and
            subsequence  number  in  the  retained  AK  TPDU and whose
            credit field is not zero.
     
        b)  an AK TPDU is transmitted with a  sequence  number  higher
            than  that  in the retained AK TPDU, due to reception of a
            DT TPDU whose sequence number is equal to the lower window
            edge;
     
        c)  N transmissions of the retained AK TPDU have taken  place.
            In  this  case  the  transport  entity  shall  continue to
            transmit the AK TPDU at an interval of W.
     
     An AK TPDU which is subject to the retransmission procedure shall
     not  contain  the  flow control confirmation parameter.  If it is
     required to transmit this parameter concurrently,  an  additional
     AK  TPDU  shall  be  transmitted  having  the  same values in the
     sequence, subsequence (if applicable) and credit fields.

110

     12.2.3.8.4  Retransmission procedures following reduction of the
     
                 upper window edge
     
     This subclause specifies the procedure for retransmission  of  AK
     TPDUs  after a transport entity has reduced the upper window edge
     (see 12.2.3.6) or for an AK TPDU with the  credit  field  set  to
     zero.  This procedure is used until the lower window edge exceeds
     the highest value of the upper window edge ever transmitted (i.e.
     the  value  existing  at  the  time of credit reduction, unless a
     higher value is retained from a previous credit reduction).
     
     This retransmission procedure should be followed for any AK  TPDU
     which increases the upper window edge, unless an AK TPDU has been
     received containing a flow control confirmation parameter,  which
     corresponds to an AK TPDU transmitted following credit reduction,
     for which the sum of the credit  and  lower  window  edge  fields
     (i.e.  the  upper  window  edge  value) is greater than the lower
     window edge (YR-TU-NR field) of the transmitted AK TPDU.
     
     This retransmission procedure for any particular  AK  TPDU  shall
     terminate when:
     
        a)  an  AK  TPDU  is  received  containing  the  flow  control
            confirmation  parameter,  whose lower window edge and your
            subsequence fields are equal to the lower window edge  and
            subsequence number in the retained AK TPDU; or
     
        b)  N transmissions of the retained AK TPDU have taken  place.
            In  this  case  the  transport  entity  shall  continue to
            transmit the AK TPDU at an interval of W.
     
     An AK TPDU which is subject to the retransmission procedure shall
     not  contain  the  flow control confirmation parameter.  If it is
     required to transmit this parameter concurrently,  an  additional
     AK  TPDU  shall  be  transmitted  having  the  same values in the
     sequence, subsequence (if applicable) and credit fields.
     
        NOTE - Retransmission of AK TPDUs is normally  not  necessary,
        except   following   explicit  closing  of  the  window  (i.e.
        transmission of an AK TPDU with CDT field set  to  zero).   If
        data  is  available  to  be  transmitted,  the  retransmission
        procedure for DT TPDUs will ensure that an AK TPDU is received

111

        granting  further  credit  where this is available.  Following
        credit  reduction,  this  may  no  longer   be   so,   because
        retransmission  may be inhibited by the credit reduction.  The
        rules described in this clause avoid extra delay.
     
     The rules for determining whether  to  apply  the  retransmission
     procedure  to  an  AK  TPDU  may  be  expressed  alternatively as
     follows.  Let:
     
          LWE  = lower window edge
          UWE  = upper window edge
          KUWE = lower bound on upper window edge
                 held by remote transport entity

The retransmission procedure is to be used whenever:

          (UWE>LWE) and (KUWE = LWE)
     
     i.e. when the window is opened and it  is  not  known  definitely
     that the remote transport entity is aware of this.
     
     KUWE is maintained as follows.  When credit is reduced,  KUWE  is
     set to LWE.  Subsequently, it is increased only upon receipt of a
     valid flow control  confirmation  (i.e.  one  which  matches  the
     retained  lower  window edge and subsequence).  In this case KUWE
     is set to the implied upper  window  edge  of  the  flow  control
     confirmation,  i.e.  the  sum  of  its lower window edge and your
     credit fields.  By this means, it can be  ensured  that  KUWE  is
     always  less than or equal to the actual upper window edge in use
     by the transmitter of DT TPDUs.
     
     12.2.3.9  Use of Flow Control Confirmation parameter
     
     At any time, an AK TPDU may  be  transmitted  containing  a  flow
     control  confirmation  parameter.   The  lower  window edge, your
     subsequence and your credit fields  shall  be  set  to  the  same
     values  as the corresponding fields in the most recently received
     in sequence AK TPDU.

112

     An AK TPDU  containing  a  flow  control  confirmation  parameter
     should be transmitted whenever:
     
        a)  a duplicate AK TPDU is received, with the value of  YR-TU-
            NR, CDT, and subsequence fields equal to the most recently
            received AK TPDU,  but  not  itself  containing  the  flow
            control confirmation parameter;
     
        b)  an AK TPDU is received which increases  the  upper  window
            edge  but  not the lower window edge, and the upper window
            edge was formerly equal to the lower window edge; or
     
        c)  an AK TPDU is received which increases  the  upper  window
            edge  but  not the lower window edge, and the lower window
            edge is lower than the highest value of the  upper  window
            edge  received  and  subsequently  reduced (i.e. following
            credit reduction).
     
     12.2.4  Procedures for Release
     
     12.2.4.1  Timers used for Release

There are no timers used only for release.

     12.2.4.2  General Procedures for Release
     
     The transport entity shall use the  explicit  variant  of  normal
     release (see 6.7).

113

     13  STRUCTURE AND ENCODING OF TPDUs
     
     13.1  Validity
     
     Table 8 specifies those TPDUs which are valid for each class  and
     the code for each TPDU.
     
        KEY:  xxxx (bits 4-1):  used to signal the CDT (set to 0000
                                in classes 0 and 1)
     
              zzzz (bits 4-1):  used to signal CDT in classes 2, 3,
                                4 set to 1111 in class 1
     
              NF:               Not available when the non explicit
                                flow control option is selected.
     
              NRC:              Not available when the receipt
                                confirmation option is selected.
     
     NOTE  - These codes are  already  in  use  in  related  protocols
     defined by standards oganizations other than CCITT/ISO.

114

     +-------------------------------------------------------------+
     |                       | Validity within   |       |         |
     |                       |     classes       |  see  |  Code   |
     |                       |-------------------| Clause|         |
     |                       | 0 | 1 | 2 | 3 | 4 |       |         |
     |-----------------------|-------------------|-------|---------|
     |CR Connection Request  | x | x | x | x | x | 13.3  |1110 xxxx|
     |-----------------------|---|---|---|---|---|-------|---------|
     |CC Connection Confirm  | x | x | x | x | x | 13.4  |1101 xxxx|
     |-----------------------|---|---|---|---|---|-------|---------|
     |DR Disconnect Request  | x | x | x | x | x | 13.5  |1000 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |DC Disconnect Confirm  |   | x | x | x | x | 13.6  |1100 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |DT Data                | x | x | x | x | x | 13.7  |1111 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |ED Expedited Data      |   | x | NF| x | x | 13.8  |0001 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |AK Data Acknowledgement|   |NRC| NF| x | x | 13.9  |0110 zzzz|
     |-----------------------|---|---|---|---|---|-------|---------|
     |EA Expedited Data      |   | x | NF| x | x | 13.10 |0010 0000|
     |Acknowledgement        |   |   |   |   |   |       |         |
     |-----------------------|---|---|---|---|---|-------|---------|
     |RJ Reject              |   | x |   | x |   | 13.11 |0101 zzzz|
     |-----------------------|---|---|---|---|---|-------|---------|
     |ER TPDU Error          | x | x | x | x | x | 13.12 |0111 0000|
     |-----------------------|---|---|---|---|---|-------|---------|
     |                       |   |   |   |   |   |   -   |0000 0000|
     |                       |---|---|---|---|---|-------|---------|
     |not available          |   |   |   |   |   |   -   |0011 0000|
     | (see note)            |---|---|---|---|---|-------|---------|
     |                       |   |   |   |   |   |   -   |1001 xxxx|
     |                       |---|---|---|---|---|-------|---------|
     |                       |   |   |   |   |   |   -   |1010 xxxx|
     +-------------------------------------------------------------+

Table 8. TPDU code

115

     13.2  Structure
     
     All the transport protocol data units (TPDUs)  shall  contain  an
     integral  number  of  octets.   The octets in a TPDU are numbered
     starting from 1 and increasing in the order they are put into  an
     NSDU.  The bits in an octet are numbered from 1 to 8, where bit 1
     is the low-ordered bit.
     
     When consecutive octets are used to represent  a  binary  number,
     the lower octet number has the least significant value.
     
     NOTE -  When the encoding  of  a  TPDU  is  represented  using  a
     diagram in this clause, the following representation is used:
     
        a)  octets are shown with the lowest  numbered  octet  to  the
            left, higher numbered octets being further to the right;

b) within an octet, bits are shown with bit 8 to the left and

bit 1 to the right.

TPDUs shall contain, in the following order:

a) the header, comprising:

            1)  the length indicator (LI) field;

2. the fixed part;

            3)  the variable part, if present;

b) the data field, if present.

This structure is illustrated below:

          octet    1   2 3 4 ... n   n+1  ...    p  p+1 ...end
                 +---+-------------+--------------+-----------+
                 | LI| fixed part  | variable part| data field|
                 +---+-------------+--------------+-----------+
                 <---------------   header ------>

116

     13.2.1  Length indicator field
     
     This field is contained in the first octet  of  the  TPDUs.   The
     length  is  indicated by a binary number, with a maximum value of
     254 (1111 1110).  The length indicated shall be the header length
     in   octets   including  parameters,  but  excluding  the  length
     indicator field and user data, if any.  The value 255 (1111 1111)
     is  reserved  for  possible  extensions.  If the length indicated
     exceeds the size of the NS-user data which is present, this is  a
     protocol error.
     
     13.2.2  Fixed part
     
     13.2.2.1  General
     
     The fixed part contains frequently occurring parameters including
     the  code of the TPDU.  The length and the structure of the fixed
     part are defined by the TPDU code and in  certain  cases  by  the
     protocol  class  and the formats in use (normal or extended).  If
     any of the parameters of the fixed part have an invalid value, or
     if the fixed part cannot be contained with the header (as defined
     by LI) this is a protocol error.
     
     NOTE - In  general,  the  TPDU  code  defines  the   fixed   part
     unambiguously.   However,  different  variants  may exist for the
     same TPDU code (see normal and extended formats).
     
     13.2.2.2  TPDU code
     
     This field contains the TPDU code and is contained in octet 2  of
     the  header.  It is used to define the structure of the remaining
     header.  This field is a  full  octet  except  in  the  following
     cases:

117

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

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

Only those codes defined in 13.1 are valid.

     13.2.3  Variable part
     
     The  variable  part  is  used  to  define  less  frequently  used
     parameters.   If  the  variable part is present, it shall contain
     one or more parameters.
     
     NOTE - The number of parameters that  may  be  contained  in  the
     variable  part  is  indicated  by the length of the variable part
     which is LI minus the length of the fixed part.
     
     Each parameter contained within the variable part  is  structured
     as follows:
     
                    Bits   8    7    6    5    4    3    2    1
          Octets          +------------------------------------+
           n+1            |          Parameter Code            |
                          |------------------------------------|
           n+2            |          Parameter Length          |
                          |          Indication (e.g. m)       |
                          |------------------------------------|
           n+3            |                                    |
                          |          Parameter Value           |
           n+2+m          |                                    |
                          +------------------------------------|

118

• The parameter code field is coded in binary;

       NOTE - Without extensions, it provides a maximum number of  255
       different  parameters.   However,  as noted below, bits 8 and 7
       cannot take every possible  value,  so  the  practical  maximum
       number  of  different  parameters is less.  Parameter code 1111
       1111 is reserved for possible extensions of the parameter code.
     
     - The  parameter  length  indication  indicates  the  length,  in
       octets, of the parameter value field.
     
       NOTE - The length is indicated by a binary number,  m,  with  a
       theoretical  maximum value of 255.  The practical maximum value
       of m is lower.  For example, in the case of a single  parameter
       contained within the variable part, two octets are required for
       the parameter code and the parameter length indication  itself.
       Thus, the value of m is limited to 248.  For larger fixed parts
       of the header and for each succeeding  parameter,  the  maximum
       value of m decreases.
     
     - The parameter value field contains the value of  the  parameter
       identified in the parameter code field.

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

     - The parameters defined in the  variable  part  may  be  in  any
       order.   If  any  parameter  is duplicated then the later value
       shall be used.  A parameter not defined in  this  International
       Standard  shall  be treated as a protocol error in any received
       TPDU except a CR TPDU; in a CR TPDU it shall  be  ignored.   If
       the  responding  transport  entity  selects a class for which a
       parameter of the CR TPDU is not defined,  it  may  ignore  this
       parameter,   except  the  class  and  option,  and  alternative
       protocol class parameters which shall always be interpreted.  A
       parameter  defined in this International Standard but having an
       invalid value shall be treated  as  a  protocol  error  in  any
       received  TPDU  except  a  CR  TPDU.   In a CR TPDU it shall be
       treated as a protocol error if  it  is  either  the  class  and
       option  parameter  or  the  alternative  class parameter or the
       additional option  parameter;  otherwise  it  shall  be  either
       ignored or treated as a protocol error.

119

     13.2.3.1  Checksum Parameter (Class 4 only)
     
     All TPDU types may contain a 16-bit checksum parameter  in  their
     variable  part.  This parameter shall be present in a CR TPDU and
     shall be present in all other TPDUs except when the  non  use  of
     checksum option is selected.
     
     Parameter Code:    1100 0011
     Parameter Length:  2
     Parameter Value:   Result of checksum algorithm.  This algorithm
                        is specified in 6.17.
     
     13.2.4  Data Field
     
     This field contains transparent user data.  Restrictions  on  its
     size are noted for each TPDU.
     
     13.3  Connection Request (CR) TPDU

The length of the CR TPDU shall not exceed 128 octets.

     13.3.1  Structure

The structure of the CR TPDU shall be as follows:

      1    2        3        4       5   6    7    8    p  p+1...end
     +--+------+---------+---------+---+---+------+-------+---------+
     |LI|CR CDT|     DST - REF     |SRC-REF|CLASS |VARIAB.|USER     |
     |  |1110  |0000 0000|0000 0000|   |   |OPTION|PART   |DATA     |
     +--+------+---------+---------+---+---+------+-------+---------+

120

     13.3.2  LI
     
     See 13.2.1
     
     13.3.3  Fixed Part (Octets 2 to 7)

The structure of this part shall contain:

        a)  CR       :  Connection Request Code:  1110.  Bits  8-5  of
                        octet 2;
        
        b)  CDT      :  Initial Credit  Allocation  (set  to  0000  in
                        Classes  0  and  1 when specified as preferred
                        class).  Bits 4-1 of octet 2;
        
        c)  DST-REF  :  Set to zero;
        
        d)  SRC-REF  :  Reference selected  by  the  transport  entity
                        initiating   the   CR  TPDU  to  identify  the
                        requested transport connection;
        
        e)  CLASS and   Bits 8-5 of octet 7 defines the preferred
            OPTION:     transport protocol class to be  operated  over
                        the   requested  transport  connection.   This
                        field shall take one of the following values:
        
                        0000  Class 0
                        0001  Class 1
                        0010  Class 2
                        0011  Class 3
                        0100  Class 4
     
     The CR TPDU contains the first choice of class in the fixed part.
     Second  and subsequent choices are listed in the variable part if
     required.
     
     Bits 4-1 of octet 7 define options to be used  on  the  requested
     transport connection as follows:

121

     +-----|-----------------------------------------------+
     | BIT |                  OPTION                       |
     |-----|-----------------------------------------------|
     |  4  |  0   always                                   |
     |     |                                               |
     |  3  |  0   always                                   |
     |     |                                               |
     |  2  | =0   use of normal formats in all classes     |
     |     | =1   use of extended formats in Classes 2,3,4 |
     |     |                                               |
     |  1  | =0   use of explicit flow control in Class 2  |
     |     | =1   no use of explicit flow control in       |
     |     |      Class 2                                  |
     +-----------------------------------------------------+
     
     NOTES
     
     1.  The connection establishment procedure  (see  6.5)  does  not
         permit  a given CR TPDU to request use of transport expedited
         data transfer service (additional option  parameter)  and  no
         use of explicit flow control in Class 2 (bit 1 = 1).

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

     13.3.4  Variable Part (Octets 8 to p)

The following parameters are permitted in the variable part:

a) Transport Service Access Point Identifier (TSAP-ID)

            Parameter code:    1100 0001 for  the  identifier  of  the
                               Calling TSAP.
                               1100 0010 for  the  identifier  of  the
                               Called TSAP
            Parameter length:  not defined in this standard
            Parameter value:   identifier of  the  calling  or  called
                               TSAP respectively.

122

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

b) TPDU size

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

Parameter value:

            0000 1101  8192 octets (not allowed in Class 0)
            0000 1100  4096 octets (not allowed in Class 0)
            0000 1011  2048 octets
            0000 1010  1024 octets
            0000 1001   512 octets
            0000 1000   256 octets
            0000 0111   128 octets

Default value is 0000 0111 (128 octets)

        c)  Version Number (not used  if  Class  0  is  the  preferred
            class)
        
            Parameter code:         1100 0100
            Parameter length:       1 octet
            Parameter value field:  0000 0001

Default value is 0000 0001 (not used in Class 0)

        d)  Security Parameters (not used if Class 0 is the  preferred
            class)
        
            This parameter is user defined.
            Parameter code:    1100 0101
            Parameter length:  user defined
            Parameter value:   user defined
        
        e)  Checksum (used only if class 4  is  the  preferred  class)
            (see 13.2.3.1)

123

            This parameter shall  always  be  present  in  a  CR  TPDU
            requesting   Class  4,  even  if  the  checksum  selection
            parameter is used  to  request  non-use  of  the  checksum
            facility.
        
        f)  Additional Option Selection (not used if Class  0  is  the
            preferred class)
        
            This parameter defines the selection  to  be  made  as  to
            whether or not additional options are to be used.
        
            Parameter code:    1100 0110
            Parameter length:  1
            Parameter value:
        
            +------------------------------------------------------+
            |BIT|                   OPTION                         |
            |---|--------------------------------------------------|
            | 4 | 1=  Use of network expedited in Class 1          |
            |   | 0=  Non use of network expedited in Class 1      |
            |   |                                                  |
            | 3 | 1=  Use of receipt confirmation in Class 1       |
            |   | 0=  Use of explicit AK variant in Class 1        |
            |   |                                                  |
            | 2 | 0=  16-bit checksum defined in 6.17 is to be used|
            |   |     in Class 4                                   |
            |   | 1=  16-bit checksum defined in 6.17 is not to be |
            |   |     used on Class 4                              |
            |   |                                                  |
            | 1 | 1=  Use of transport expedited data transfer     |
            |   |     service                                      |
            |   | 0=  No use of transport expedited data transfer  |
            |   |     service                                      |
            +------------------------------------------------------+

Default value is 000 0001

            Bits related to options particular  to  a  class  are  not
            meaningful  if that class is not proposed and may take any
            value.

124

g) Alternative protocol class(es) (not used if Class 0 is the

            preferred class)
            
            Parameter code:    1100 0111
            Parameter length:  n
            
            Parameter value encoded as a sequence  of  single  octets.
            Each octet is encoded as for octet 7 but with bits 4-1 set
            to zero (i.e. no alternative option selections permitted).
        
        h)  Acknowledge Time (used only if class 4  is  the  preferred
            class)
        
            This parameter conveys the maximum acknowledge time AL  to
            the  remote  transport  entity.  It is an indication only,
            and is not subject to negotiation (see 12.2.1.1.3)
            Parameter code:    1000 0101
            Parameter length:  2
            Parameter value:   n, a binary number where n is the
                               maximum acknowledge time, expressed
                               in milliseconds.

j) Throughput (not used if class 0 is the preferred class)

            Parameter code:    1000 1001
            Parameter length:  12 or 24
            Parameter value:

1st 12 Octets: maximum throughput, as follows:

            1st 3 octets:      Target   value,   calling-called   user
                               direction
            2nd 3 octets:      Min.  acceptable,  calling-called  user
                               direction
            3rd 3 octets:      Target   value,   called-calling   user
                               direction
            4th 3 octets:      Min.  acceptable,  called-calling  user
                               direction
            
            2nd 12 octets (optional):  average throughput, as follows:
            
            5th 3 octets:      Target   value,   calling-called   user
                               direction

125

            6th 3 octets:      Min.  acceptable,  calling-called  user
                               direction
            7th 3 octets:      Target   value,   called-calling   user
                               direction
            8th 3 octets:      Min.  acceptable,  called-calling  user
                               direction
            
            Where the average throughput is omitted, it is  considered
            to have the same value as the maximum throughput.

Values are expressed in octets per second.

        k)  Residual error rate (not used if class 0 is the  preferred
            class)
        
            Parameter code:    1000 1001
            Parameter length:  12
            1st 3 octets:      Target   value,   calling-called   user
                               direction
            2nd 3 octets:      Min.  acceptable,  calling-called  user
                               direction
            3rd 3 octets:      Target   value,   called-calling   user
                               direction
            4th 3 octets:      Min.  acceptable,  called-calling  user
                               direction
        
        l)  Residual error rate (not used if class 0 is the  preferred
            class)
        
            Parameter code:    1000 0110
            Parameter length:  3
            Parameter value:
            1st octet:         Target value, power of 10
            2nd octet:         Min. acceptable, power of 10
            3rd octet:         TSDU size of interest, expressed  as  a
                               power of 2

m) Priority (not used if class 0 is the preferred class)

            Parameter code:    1000 0111
            Parameter length:  2
            Parameter value:   Integer (0 is the highest priority)

126

n) Transit delay (not used if class 0 is the preferred class)

            Parameter code:    1000 1000
            Parameter length:  8
            Parameter value:
            1st 2 octets:      Target   value,   calling-called   user
                               direction
            2nd 2 octets:      Max.  acceptable,  calling-called  user
                               direction
            3rd 2 octets:      Target   value,   called-calling   user
                               direction
            4th 2 octets:      Max.  acceptable,  called-calling  user
                               direction

Values are expressed in milliseconds, and are based upon a TSDU size of 128 octets.

        p)  assignment time (not used if class 0, 2 or class 4 is  the
        
            preferred class)
        
            This parameter conveys the Time to Try Reassignment  (TTR)
            which  will  be  used  when  following  the  procedure for
            Reassignment after Failure (see 6.12).
            Parameter code:    1000 1011
            Parameter length:  2
            Parameter value:   n, a binary number where n is  the  TTR
                               value expressed in seconds.
     
     13.3.5  User Data (Octets p+1 to the end)
     
     No user data are permitted in Class 0, and are  optional  in  the
     other classes.  Where permitted, it may not exceed 32 octets.

127

     13.4  Connection Confirm (CC) TPDU
     
     13.4.1  Structure

The structure of the CC TPDU shall be as follows:

       1      2     3   4   5   6     7     8     p   p+1 ...end
     +---+----+---+---+---+---+---+-------+--------+-------------+
     |LI | CC  CDT|DST-REF|SRC-REF| CLASS |VARIABLE| USER        |
     |   |1101|   |   |   |   |   | OPTION|  PART  | DATA        |
     +---+----+---+---+---+---+---+-------+--------+-------------+
     
     13.4.2  LI
     
     See 13.2.1
     
     13.4.3  Fixed Part (Octets 2 to 7)

The fixed part shall contain:

        a)  CC:  Connection Confirm Code:  1101.  Bits 8-5 of octet 2;
        
        b)  CDT:  Initial Credit Allocation (set to 0000 in Classes  0
            and 1).  Bits 4-1 of octet 2;
        
        c)  DST-REF:  Reference identifying  the  requested  transport
            connection at the remote transport entity;
        
        d)  SRC-REF:  Reference identifying  the  requested  transport
            connection at the remote transport entity.
        
        e)  Class and Option:  Defines the selected transport protocol
            class   and  option  to  be  operated  over  the  accepted
            transport connection according to  the  negotiation  rules
            specified in 6.5;

128

     13.4.4  Variable Part (Octet 8 to p)
     
     The parameters are defined in  13.3.4  and  are  subject  to  the
     constraints states in 6.5 (connection establishment).  Parameters
     ruled out by selection of an alternative class and  option  shall
     not be present.
     
     13.4.5  User Data (Octets p+1 to the end)
     
     No user data are permitted in class 0, and are  optional  in  the
     other  classes.   Where  permitted,  it may not exceed 32 octets.
     The user data are subject to the constraints of  the  negotiation
     rules (see 6.5).
     
     13.5  Disonnect Request (DR) TPDU
     
     13.5.1  Structure

The structure of the DR TPDU shall be as follows:

       1     2      3     4    5     6     7    8     p   p+1 ...end
     +--+---------+----+-----+----+-----+------+--------+----------+
     |LI|    DR   | DST-REF. | SRC-REF. |REASON|VARIABLE| USER     |
     |  |1000 0001|    |     |    |     |      |  PART  | DATA     |
     +--+---------+----+-----+----+-----+------+--------+----------+
     
     13.5.2  LI
     
     See Section 13.2.1

129

     13.5.3  Fixed Part (Octets 2 to 7

The fixed part shall contain:

        a)  DR:  Disconnect Request Code:  1000 0000;
        
        b)  DST-REF:  Reference identifying the  transport  connection
            at the remote transport entity;
        
        c)  SRC-REF:  Reference identifying the  transport  connection
            at  the  transport entity initiating the TPDU.  Value zero
            when reference is unassigned;
        
        d)  REASON:   Defines  the  reason   for   disconnecting   the
            transport  connection.   This  field shall take one of the
            following values:

The following values may be used for Classes 1 to 4:

            1)  128 + 0 - Normal  disconnect  initiated   by   session
                   entity
            2)  128 + 1 - Remote  transport   entity   congestion   at
                   connect request time
            3) *128 + 2 - Connection negotiation failed (i.e. proposed
                   class(es) not supported)
            4)  128 + 3 - Duplicate source reference detected for  the
                   same pair of NSAPS.
            5)  128 + 4 - Mismatched references
            6)  128 + 5 - Protocol error
            7)  128 + 6 - Not used
            8)  128 + 7 - Reference overflow
            9)  128 + 8 - Connection request refused on  this  network
                   connection
            10) 128 + 9 - Not used
            11) 128 + 10- Header or parameter length invalid

130

The following values can be used for all classes:

            12)       0 - Reason not specified
            13)       1 - Congestion at TSAP
            14)      *2 - Session entity not attached to TSAP
            15)      *3 - Address unknown
        
        NOTE - Reasons marked with an asterisk (*) may be reported  to
        the TS-user as persistent, other reasons as transient.
     
     13.5.4  Variable Part (Octets 8 to p)

The variable part may contain

a) A parameter allowing additional information related to the

clearing of the connection.

            Parameter code:    1110 0000
            Parameter length:  Any value provided that the  length  of
                               the DR TPDU does not exceed the maximum
                               agreed TPDU size or  128  when  the  DR
                               TPDU  is  used  during  the  connection
                               refusal procedure
            Parameter value:   Additional information.  The content of
                               this field is user defined.

b) Checksum (see 13.2.3.1)

     13.5.5  User Data (Octets p+1 to the end)
     
     This field shall not exceed 64 octets and is used  to  carry  TS-
     user   data.   The  successful  transfer  of  this  data  is  not
     guaranteed by the transport protocol.  When a DR TPDU is used  in
     Class 0 it shall not contain this field.

131

     13.6  Disconnect Confirm (DC) TPDU

This TPDU shall not be used in Class 0.

     13.6.1  Structure

The structure of DC TPDU shall be as follows:

       1       2         3     4     5     6    7        p
     +----+-----------+-----+-----+-----+-----+-------+--------+
     | LI |    DC     |  DST REF  |  SRC REF  | Variable Part  |
     |    | 1100 0000 |     |     |     |     |       |        |
     +----+-----------+-----+-----+-----+-----+-------+--------+
     
     13.6.2  LI
     
     See 13.2.1
     
     13.6.3  Fixed Part (Octets 2 to 6)

The fixed part shall contain:

        a)  DC:  Disconnect Confirm Code:  1100 0000;
        
        b)  DST-REF:  See 13.4.3;
        
        c)  SRC-REF:  See 13.4.3.

132

     13.6.4  Variable Part
     
     The variable part shall contain the  checksum  parameter  if  the
     condition in (see 13.2.3.1) applies.
     
     13.7  Data (DT) TPDU
     
     13.7.1  Structure
     
     Depending on the class and the option the DT TPDU shall have  one
     of the following structures.

a) Normal format for Classes 0 and 1

       1       2         3          4       5             ... end
     +----+-----------+-----------+------------ - - - - - -------+
     | LI |    DT     |  TPDU-NR  | User Data                    |
     |    | 1111 0000 |  and EOT  |                              |
     +----+-----------+-----------+------------ - - - - - -------+

b) Normal format for Classes 2, 3 and 4

       1      2       3   4     5     6       p    p+1       ... end
     +----+---------+---+---+-------+-----+-------+----------- - - -+
     | LI |   DT    |DST-REF|TPDU-NR|Variable Part|User Data        |
     |    |1111 0000|   |   |and EOT|     |       |                 |
     +----+---------+---+---+-------+-----+-------+----------- - - -+
     
        c)  Extended Format for  use  in  Classes  2,  3  and  4  when
            selected during connection establishment.
     
       1      2       3   4   5,6 7,8  9     p  p+1      ... end
     +----+---------+---+---+---------+--------+---------- - - -+
     | LI |   DT    |DST-REF| TPDU-NR |Variable|User Data       |
     |    |1111 0000|   |   | and EOT |  Part  |                |
     +----+---------+---+---+---------+--------+---------- - - -+

133

     13.7.2  LI
     
     See 13.2.1
     
     13.7.3  Fixed Part

The fixed part shall contain:

        a)  DT:       Data Transfer Code:  1111 0000;
        
        b)  DST-REF:  See 13.4.3;
        
        c)  EOT:      When set to ONE, indicates that the  current  DT
                      TPDU is the last data unit of a complete DT TPDU
                      sequence (End of TSDU).  EOT is bit 8 of octet 3
                      in  class  0  and 1, bit 8 of octet 5 for normal
                      formats for classes 2, 3 and  4  and  bit  8  of
                      octet 8 for extended formats;
        
        d)  TPDU-NR:  TPDU send Sequence Number  (zero  in  Class  0).
                      May  take  any value in Class 2 without explicit
                      flow control.  TPDU-NR is bits 7-1  of  octet  3
                      for  classes  0  and  1, bits 7-1 of octet 5 for
                      normal formats in classes 2, 3 and 4, octets  5,
                      6  and  7  together with bits 7-1 of octet 8 for
                      extended formats.
        
        NOTE - Depending on the class, the fixed part of the  DT  TPDU
        uses the following octets:

Classes 0 and 1: Octets 2 to 3;

Classes 2,3,4 normal format: Octets 2 to 5;

Classes 2,3,4 extended format: Octets 2 to 8.

134

     13.7.4  Variable Part
     
     The variable part shall contain the  checksum  parameter  if  the
     condition in see 13.2.3.1 applies.
     
     13.7.5  User Data Field

This field contains data of the TSDU being transmitted.

     NOTE - The length of this field is limited to the negotiated TPDU
     size  for  this  transport connection minus 3 octets in Classes 0
     and 1, and minus 5 octets (normal  header  format)  or  8  octets
     (extended  header  format)  in  the  other classes.  The variable
     part, if present, may further reduce the size of  the  user  data
     field.
     
     13.8  Expedited Data (ED) TPDU
     
     The ED TPDU shall not be used in Class 0 or in Class 2  when  the
     no explicit flow control option is selected or when the expedited
     data transfer service has not been selected for the connection.
     
     13.8.1  Structure
     
     Depending on the format negotiated  at  connection  establishment
     the ED TPDU shall have one of the following structures:

135

        a)  Normal Format (classes 1, 2, 3, 4)
     
      1     2       3   4      5     6        p    p+1     ... end
     +--+---------+---+---+---------+-----+-------+---------------+
     |LI|   ED    |DST-REF|EDTPDU-NR|Variable Part|User Data      |
     |  |0001 0000|   |   |and EOT  |     |       |               |
     +--+---------+---+---+---------+-----+-------+---------------+
     
        b)  Extended Format (for use in classes 2, 3, 4 when  selected
            during connection establishment).
     
      1     2       3   4   5,6,7,8  9        p    p+1     ... end
     +--+---------+---+---+---------+-----+-------+---------------+
     |LI|   ED    |DST-REF|EDTPDU-NR|Variable Part|User Data      |
     |  |0001 0000|   |   |and EOT  |     |       |               |
     +--+---------+---+---+---------+-----+-------+---------------+
     
     13.8.2  LI
     
     See 13.2.1
     
     13.8.3  Fixed Part

The fixed part shall contain:

a) ED: Expedited Data code: 0001 0000;

        b)  DST-REF:     see 13.4.3;
        
        c)  ED-TPDU-NR:  Expedited TPDU  identification  number.   ED-
                         TPDU-NR is used in classes 1, 3 and 4 and may
                         take any value in Class 2.  Bits 7-1 of octet
                         5  for  normal  formats and octets 5, 6 and 7
                         together  with  bits  7-1  of  octet  8   for
                         extended formats;

136

        d)  EOT:         end of TSDU always set to 1 (bit 8 of octet 5
                         for  normal  formats and bit 8 of octet 8 for
                         extended formats).
        
        NOTE - Depending on the format the fixed part shall be  either
        octets 2 to 5 or 2 to 8.
     
     13.8.4  Variable Part
     
     The variable part shall contain the  checksum  parameter  if  the
     condition defined in 13.2.3.1 applies.
     
     13.8.5  User Data Field

This field contains an expedited TSDU (1 to 16 octets).

     13.9  Data Acknowledgement (AK) TPDU
     
     This TPDU shall not be used for Class 0 and Class 2 when the  "no
     explicit  flow  control" option is selected, and for Class 1 when
     the network receipt confirmation option is selected.
     
     13.9.1  Structure
     
     Depending on the class and option agreed the AK TPDU  shall  have
     one of the following structures:

137

        a)  Normal Format (classes 1, 2, 3, 4)
     
      1     2      3     4        5        6        p
     +--+--------+----------+------------+---------------+
     |LI| AK CDT | DST-REF  |  YR-TU-NR  | Variable Part |
     |  | 0110   |          |            |               |
     +--+--------+----------+------------+---------------+
     
        b)  Extended Format (for use in classes 2, 3, 4 when  selected
            during connection establishment).
     
      1      2      3     4    5,6,7,8   9,10 11    p
     +--+---------+---------+----------+-----+--------+
     |LI|    AK   | DST-REF | YR-TU-NR | CDT |Variable|
     |  |0110 0000|         |          |     |  Part  |
     +--+---------+---------+----------+-----+--------+
     
     13.9.2  LI
     
     See 13.2.1
     
     13.9.3  Fixed Part
     
     The fixed part shall contain (in octet 2 to 5 when normal  format
     is used, 2 to 10 otherwise) the following parameters:
     
        a)  AK:        Acknowledgement code:  0110;
     
        b)  CDT:       Credit Value (set to 1111 in  class  1).   Bits
                       4-1  of octet 2 for normal formats and octets 9
                       and 10 for extended formats;
     
        c)  DST-REF:   See 13.4.3;
     
        d)  YR-TU-NR:  Sequence number indicating the next expected DT
                       TPDU  number.   For normal formats, bits 7-1 of
                       octet 5; bit 8 of octet 5  is  not  significant

138

                       and  shall  take  the  value  0.   For extended
                       formats, octets 5, 6 and 7 together  with  bits
                       7-1  of  octet  8;  bit  8  of  octet  8 is not
                       significant and shall take the value 0.
     
     13.9.4  Variable Part

The variable part contains the following parameters:

        a)  Checksum  See  13.2.3.1  if  the  condition  in   13.2.3.1
            applies;
        
        b)  Subsequence  number  when  optionally   used   under   the
            conditions  defined in class 4.  This parameter is used to
            ensure  that  AK  TPDUs  are  processed  in  the   correct
            sequence.    If  it  is  absent,  this  is  equivalent  to
            transmitting the parameter with a value of zero.
            Parameter code:    1000 1010
            Parameter length:  2
            Parameter value:   16-bit sub-sequence number;
        
        c)  Flow Control Confirmation Class  4  when  optionally  used
            under  the  conditions defined in class 4.  This parameter
            contains a copy of the information received in an AK TPDU,
            to  allow  the transmitter of the AK TPDU to be certain of
            the  state  of  the  receiving   transport   entity   (see
            12.2.3.10).
            Parameter code:    1000 1011
            Parameter length:  8
            Parameter value:   defined as follows

1. Lower Window Edge (32 bits) Bit 8 of octet 4 is set to zero, the remainder contains the YR-TU-NR value of the received AK TPDU. When normal format has been selected, only the least significant seven bits (bits 1 to 7 of octet 1) of this field are significant.

            2.  Your Sub-Sequence (16 bits)
                Contains the value of the  sub-sequence  parameter  of

139

                the  received  AK  TPDU, or zero if this parameter was
                not present.
            
            3.  Your Credit (16 bits)
                Contains the value of the CDT field of the received AK
                TPDU.   When normal format has been selected, only the
                least significant four bits (bits 1 to 4 of  octet  1)
                of this field are significant.
     
     13.10  Expedited Data Acknowledgement (EA) TPDU
     
     This TPDU shall not be used for Class 0 and Class 2 when  the  no
     explicit flow control option is selected.
     
     13.10.1  Structure
     
     Depending on the option (normal  or  extended  format)  the  TPDU
     structure shall be:
     
        a)  Normal Format (classes 1,2,3,4)
     
             1      2      3     4      5      6        p
            +--+---------+---------+----------+------+------+
            |LI|   EA    | DST-REF | YR-TU-NR |Variable Part|
            |  |0010 0000|         |          |      |      |
            +--+---------+---------+----------+------+------+
     
        b)  Extended Format (for use in classes 2, 3,  4  if  selected
            during connection establishment)
     
             1      2      3     4    5,6,7,8  9        p
            +--+---------+---------+----------+------+------+
            |LI|   EA    | DST-REF | YR-TU-NR |Variable Part|
            |  |0010 0000|         |          |      |      |
            +--+---------+---------+----------+------+------+

140

     13.10.2  LI
     
     See 13.2.1
     
     13.10.3  Fixed Part

The fixed part shall contain (in octets 2 to 5 when normal format is used, in octets 2 to 8 otherwise):

        a)  EA:          Expedited Acknowledgement code:  0010 0000;
        
        b)  DST-REF:     See 13.4.3;
        
        c)  YR-EDTU-NR:  Identification   of   the   ED   TPDU   being
                         acknowledged.  May take any value in Class 2;
        
                         For normal formats bits 7-1 of octet 5; bit 8
                         of  octet 5 is not significant and shall take
                         the value 0.  For  extended  formats,  octets
                         5,6  and 7 together with bits 7-1 of octet 8;
                         bit 8 of octet 8 is not significant and shall
                         take the value 0.
     
     13.10.4  Variable Part
     
     The  variable  part  may  contain  the  checksum  parameter  (see
     13.2.3.1).
     
     13.11  Reject (RJ) TPDU

The RJ TPDU shall not be used in Classes 0, 2 and 4.

141

     13.11.1  Structure

The RJ TPDU shall have one of the following formats:

a) Normal Format (classes 1 and 3)

              1      2        3     4       5
            +----+----------+----+----+------------+
            | LI |  RJ CDT  | DST-REF |  YR-TU-NR  |
            |    | 0101     |    |    |            |
            +----+----------+----+----+------------+
        
        b)  Extended Format (for use in classes 3 if  selected  during
            connection establishment).
        
             1       2       3     4   5,6,7,8   9,10
            +--+-----------+----+----+----------+-----+
            |LI|     RJ    | DST-REF | YR-TU-NR | CDT |
            |  | 0101 0000 |    |    |          |     |
            +--+-----------+----+----+----------+-----+
     
     13.11.2  LI

See 13.2.1.

     13.11.3  Fixed Part

The fixed part shall contain (in octets 2 to 5 when normal format is used, in octets 2 to 10 otherwise):

a) RJ: Reject Code: 0101. Bits 8-5 of octet 2;

        b)  CDT:       Credit Value (set to 1111 in  class  1).   Bits
                       4-1  of octet 2 for normal formats and octets 9
                       and 10 for extended formats;
        
        c)  DST-REF:   See 13.4.3;

142

        d)  YR-TU-NR:  Sequence number indicating  the  next  expected
                       TPDU from which retransmission should occur.
        
                       For normal formats, bits 7-1 of octet 5; bit  8
                       of  octet  5  is not significant and shall take
                       the value 0.  For extended formats, octets  5,6
                       and  7 together with bits 7-1 of octet 8; bit 8
                       of octet 8 is not significant  and  shall  take
                       the value 0.
     
     13.11.4  Variable Part

There is no variable part for this TPDU type.

     13.12  TPDU Error (ER) TPDU
     
     13.12.1  Structure
     
       1        2       3     4     5         6   P
     +----+-----------+----+----+--------+----------+
     | LI |    ER     | DST-REF | Reject | Variable |
     |    | 0111 0000 |    |    | Cause  |   Part   |
     +----+-----------+----+----+--------+----------+
     
     13.12.2  LI
     
     See 13.2.1

143

     13.12.3  Fixed Part

The fixed part shall contain:

        a)  ER:            TPDU Error Code:  0111 0000;
        
        b)  DST-REF:       See 13.4.3;
        
        c)  REJECT CAUSE:  0000 0000  Reason not specified
                           0000 0001  Invalid parameter code
                           0000 0010  Invalid TPDU type
                           0000 0011  Invalid parameter value.
     
     13.12.4  Variable Part

The variable part may contain the following parameters:

a) Invalid TPDU

            Parameter code:    1100 0001
            
            Parameter length:  number of octets of the value field
            
            Parameter Value:  Contains the bit pattern of the rejected
                               TPDU  up  to  and  including  the octet
                               which  caused  the   rejection.    This
                               parameter is mandatory in Class 0.
        
        b)  Checksum
        
            This parameter  shall  be  present  if  the  condition  in
            13.2.3.1 applies.

144

SECTION THREE. CONFORMANCE

     14  CONFORMANCE
     
     14.1
     
     A system claiming to implement the procedures specified  in  this
     standard shall comply with the requirements in 14.2 - 14.5.
     
     14.2

The system shall implement Class 0 or Class 2 or both.

     14.3
     
     If the system implements Class  3  or  Class  4,  it  shall  also
     implement Class 2.
     
     14.4
     
     If the system implements Class 1, it shall also  implement  Class
     0.

145

     14.5
     
     For each class which the system claims to implement,  the  system
     shall be capable of:
     
        a)  initiating CR TPDUs or responding  to  CR  TPDUs  with  CC
            TPDUs or both;

b) responding to any other TPDU and operating network service

in accordance with the procedures for the class;

        c)  operating all the  procedures  for  the  class  listed  as
            mandatory in table 9;
        
        d)  operating  those  procedures  for  the  class  listed   as
            optional in table 9 for which conformance is claimed;

e) handling all TPDUs of lengths up to the lesser value of:

1. the maximum length for the class;

2) the maximum for which conformance is claimed.

            NOTE - This requirement indicates that TPDU sizes  of  128
            octets are always implemented.
     
     14.6  Claims of Conformance Shall State

a) which class or classes of protocol are implemented;

        b)  whether the system is capable of initiating or  responding
            to CR TPDUs or both;
        
        c)  which of the procedures listed as optional in table 9  are
            implemented;

146

        d)  the maximum size of TPDU implemented; the value  shall  be
            chosen  from the following list and all values in the list
            which are less than this maximum shall be implemented:

128, 256, 512, 1024, 2048, 4096 or 8192 octets.

147

     +------------------------------------------------------------+
     |       PROCEDURE          |    CLASS 0     |    CLASS 1     |
     |--------------------------|----------------|----------------|
     |                          |                |                |
     |TPDU with checksum        | NA             | NA             |
     |TPDU wihout checksum      | mandatory      | mandatory      |
     |                          |                |                |
     |--------------------------|----------------|----------------|
     |Expedited data transfer   | NA             | mandatory      |
     |No expedited data transfer| mandatory      | mandatory      |
     |                          |                |                |
     |--------------------------|----------------|----------------|
     |Flow control in Class 2   | NA             | NA             |
     |No flow control in Class 2| NA             | NA             |
     |                          |                |                |
     |--------------------------|----------------|----------------|
     |Normal formats            | mandatory      | mandatory      |
     |Extended formats          | NA             | NA             |
     |                          |                |                |
     |--------------------------|----------------|----------------|
     |Use of receipt confirma-  |                |                |
     |tion in Class 1           | NA             | optional       |
     |No use of receipt con-    |                |                |
     |firmation in Class 1      | NA             | mandatory      |
     |                          |                |                |
     |--------------------------|----------------|----------------|
     |Use of network expedited  |                |                |
     |in Class 1                | NA             | optional       |
     |No use of network expedi- |                |                |
     |ted in Class 1            | NA             | mandatory      |
     |                          |                |                |
     +------------------------------------------------------------+

NA indicates the procedure is not applicable.

Table 9. (First of 2 pages) Provision of options

148

     +------------------------------------------------------------+
     |       PROCEDURE          | CLASS 2  | CLASS 3  |  CLASS 4  |
     |--------------------------|----------|----------|-----------|
     |                          |          |          |           |
     |TPDU with checksum        |NA        |NA        |mandatory  |
     |TPDU wihout checksum      |mandatory |mandatory |optional   |
     |                          |          |          |           |
     |--------------------------|----------|----------|-----------|
     |Expedited data transfer   |mandatory |mandatory |mandatory  |
     |No expedited data transfer|mandatory |mandatory |mandatory  |
     |                          |          |          |           |
     |--------------------------|----------|----------|-----------|
     |Flow control in Class 2   |mandatory |NA        |NA         |
     |No flow control in Class 2|optional  |NA        |NA         |
     |                          |          |          |           |
     |--------------------------|----------|----------|-----------|
     |Normal formats            |mandatory |mandatory |mandatory  |
     |Extended formats          |optional  |optional  |optional   |
     |                          |          |          |           |
     |--------------------------|----------|----------|-----------|
     |Use of receipt confirma-  |          |          |           |
     |tion in Class 1           |NA        |NA        |NA         |
     |No use of receipt con-    |          |          |           |
     |firmation in Class 1      |NA        |NA        |NA         |
     |                          |          |          |           |
     |--------------------------|----------|----------|-----------|
     |Use of network expedited  |          |          |           |
     |in Class 1                |NA        |NA        |NA         |
     |No use of network expedi- |          |          |           |
     |ted in Class 1            |NA        |NA        |NA         |
     |                          |          |          |           |
     +------------------------------------------------------------+

NA indicates the procedure is not applicable

Table 9. (Second of 2 pages) Provision of options

149

ANNEX A - STATE TABLES

     This annex is an integral part of the body of this  International
     Standard.
     
     This Annex provides a more precise description of  the  protocol.
     In  the  event  of a discrepancy between the description in these
     tables and that contained in the text, the text takes precedence.
     
     The state table also  define  the  mapping  between  service  and
     protocol events that TS-users can expect.
     
     This annex describes the transport protocol  in  terms  of  state
     tables.    The  state  tables  show  the  state  of  a  transport
     connection, the events that occur in the  protocol,  the  actions
     taken and the resultant state.

[The state tables have been omitted from this copy.]

150

ANNEX B - CHECKSUM ALGORITHMS

     (This annex is provided for information for implementors  and  is
     not an integral part of the body of the standard.)
     
     B.1  SYMBOLS

The following symbols are used:

        C0  variables used in the algorithms
        C1
        
        i   number (i.e. position) of an octet within  the  TPDU  (see
            12.1)
        
        n   number (i.e. position) of the first octet of the  checksum
            parameter
        
        L   length of the complete TPDU

X value of the first octet of the checksum parameter

Y value of the second octet of the checksum parameter.

     B.2  ARITHMETIC CONVENTIONS

Addition is performed in one of the two following modes:

a) modulo 255 arithmetic;

        b)  one's  complement  arithmetic  in  which  if  any  of  the
            variables  has the value minus zero (i.e. 255) it shall be
            regarded as though it was plus zero (i.e. 0).
     
     B.3  ALGORITHM FOR GENERATING CHECKSUM PARAMETERS

151

     B.3.1  Set up the complete TPDU with the value  of  the  checksum
     parameter field set to zero.
     
     B.3.2  Initialize C0 and C1 to zero.
     
     B.3.3  Process each octet sequentially from i = 1 to L by:

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

b) adding the value of C0 to C1.

     B.3.4  Calculate X and Y such that
     
        X = -C1 + (L-n).CO
        Y =  C1 - (L-n+1).C0
     
     B.3.5  Place the values  X  and  Y  in  octets  n  and  (n  +  1)
     respectively.
     
     [A Note describing the above algorithm in  mathematical  notation
     has been omitted from this copy.]
     
     B.4  ALGORITHM FOR CHECKING CHECKSUM PARAMETERS
     
     B.4.1  Initialize C0 and C1 to zero.
     
     B.4.2  Process each octet of the TPDU sequentially from i = 1  to
     L by:

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

b) adding the value of C0 to C1.

152

     B.4.3  If, when all the octets have  been  processed,  either  or
     both  of  C0  and  C1  does not have the value zero, the checksum
     formulas in 6.17 have not been satisfied.
     
     NOTE - The nature of  the  algorithm  is  such  that  it  is  not
     necessary to compare explicitly the stored checksum bytes.

153

     Explanatory Report
     
     The Transport Layer Services and Protocols have been under  study
     within  TC97/SC16  since  1979.   It  was  agreed  by SC16 at its
     meeting in Berlin, November 1980, that the Service  and  Protocol
     documents would be progressed concurrently.
     
     At the SC16 meeting in Tokyo, June 1982, authorization was  given
     (Resolutions  10  and  11,  SC16  N  1233)  to  register both the
     Transport  Service  Definition   and   the   Transport   Protocol
     Specification  as Draft Proposals and to circulate them for a 90-
     day ballot.
     
     Following the close of the letter ballot  an  Editing  Group  was
     convened to integrate editorial comments and make recommendations
     regarding proposed technical  changes.   The  revised  texts  and
     proposed recommendations were reviewed by SC16/WG6 at its meeting
     in Vienna, March 1983.  The revised text of the Transport Service
     Definition  (SC16  N  1435) was accepted as presented whereas the
     revised  text  of  the  Transport  Protocol  (SC16  N  1433)  was
     subjected  to  an  additional 60-day ballot.  Consistent with the
     SC16 decision regarding the parallel progression of both DPs, the
     Transport   Service  Definition  was  held  in  abeyance  pending
     acceptance by SC16 of the revised Transport Protocol  (Second  DP
     8073).
     
     A second Editing Group was  convened  in  Paris,  July  1983,  to
     review  comments  submitted  on  Second DP 8073.  The Minutes and
     Report of this meeting are documented in SC16 N1575  and  N  1574
     respectively.   The  two  negative votes (DIN and NNI) were given
     full consideration.  The NNI concerns have been fully covered  in
     the revised text prepared by the Editing Group.  The DIN concerns
     have been taken into account  and  incorporated  in  their  large
     majority.
     
     Upon the recommendation of the Editing Group, DP 8072 and DP 8073
     are  forwarded  for registration as Draft International Standards
     and letter ballot of ISO Member Bodies.

154