Network Working Group ISO Request for Comments: 905 April 1984
ISO Transport Protocol Specification ISO DP 8073
This document is distributed as an RFC for information only. It does not specify a standard for the ARPA-Internet.
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.
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
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
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
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
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
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
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
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
14.2 . 145 14.3 . 145 14.4 . 145 14.5 . 146 14.6 Claims of Conformance Shall State. 146
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.
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:
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.
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.1 This International Standard specifies:
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,
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.
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.
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.
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.
NOTE - The definitions contained in this clause make use of abbreviations defined in clause 4.
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:
For the purpose of this International Standard, the following definitions apply:
Hardware or software or a combination of both; it need not be physically distinct within a computer system.
An abstract representation of the totality of those entities within a single system that make use of the transport service.
An abstract machine that models the totality of the entities providing the network service, as viewed by a transport entity.
A decision made by a system concerning its behavior in the Transport Layer that is not subject to the requirements of this protocol.
A transport entity that initiates a CR TPDU.
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.
A transport entity that sends a given TPDU.
A transport entity that receives a given TPDU.
The protocol class that the initiator indicates in a CR TPDU as its first choice for use over the transport connection.
A protocol class that the initiator indicates in a CR TPDU as an alternative choice for use over the transport connection.
A preferred class or an alternative class.
The protocol class that the responder indicates in a CC TPDU that it has chosen for use over the transport connection.
The value for a parameter that the initiator indicates in a CR TPDU that it wishes to use over the transport connection.
The value for a parameter that the responder indicates in a CC TPDU that it has chosen for use over the transport connection.
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.
A TPDU that does not comply with the requirements of this International Standard for structure and encoding.
A TPDU whose use does not comply with the procedures for the class.
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.
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.
The lowest sequence number in a transmit window.
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.
A transmit window that contains no sequence number.
Information contained in a TPDU relating to the upper and the lower window edges.
A reference that is not available for assignment to a connection because of the requirements of 6.18.
A reference that is neither currently in use for identifying a transport connection or which is in a frozen state.
TS-user data that is transferred intact between transport entities and which is unavailable for use by the transport entities.
The transport entity that issued the N-CONNECT request leading to the creation of that network connection.
A TPDU that is subject to the retransmission procedure or retention until acknowledgement procedure and is available for possible retransmission.
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
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)
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
TS-user Transport service user TSAP Transport service access point NS-provider Network service provider NSAP Network service access point QOS Quality of service
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.
+-------------------------------------------------------------+ | 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. | +--------------------------------|----------------------------+
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.
+---------------------------------------------------------------+ | 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
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.
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.
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:
c) status exchanges and monitoring of QOS;
e) temporary release of network connections;
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.
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:
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).
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;
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.
The purpose of release (see 6.7 and 6.8) is to provide disconnection of the transport connection, regardless of the current activity.
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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
+------+ +------+ ----------| TSAP |------------------------| TSAP |---------- +------+ +------+ | | +---------------+ +---------------+ | Transport | | Transport | | entity | | entity | +---------------+ +---------------+ | | | | +------+ +------+ ----------| NSAP |------------------------| NSAP |---------- +------+ +------+ | | +-------------------------------+
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.
SECTION TWO. TRANSPORT PROTOCOL SPECIFICATION
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.
The procedure is used in all classes to assign transport connections to network connections.
The procedure makes use of the following network service primitives:
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.
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
The TPDU transfer procedure is used in all classes to convey transport protocol data units in user data fields of network service primitives.
The procedure uses the following network service primitives:
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).
The segmenting and reassembling procedure is used in all classes to map TSDUs onto TPDUs.
The procedure makes use of the following TPDU and parameter:
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.
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.
The procedure for concatenation and separation is used in classes 1, 2, 3 and 4 to convey multiple TPDUs in one NSDU.
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.
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.
The procedure for connection establishment is used in all classes to create a new transport connection.
The procedure uses the following network service primitive:
The procedure uses the following TPDUs and parameters:
- 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.
- 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.
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
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.
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),
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.
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.
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.
+------------------------------------------------------------+ | 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
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.
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.
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
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.
The connection refusal procedure is used in all classes when a transport entity refuses a transport connection in response to a CR TPDU.
The procedure makes use of the following TPDUs and parameters:
- reject code; - rejected TPDU parameter.
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.
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.
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.
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.
The procedure makes use of the following network service primitives:
a) N-DISCONNECT (implicit variant only),
The procedure makes use of the following TPDUs and parameters:
- clearing reason; - user data; - SRC-REF; - DST-REF.
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.
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;
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).
e) in other cases, send a DC TPDU and consider the transport connection released.
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).
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.
The procedure makes use of the following service primitives:
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
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.
This procedure makes use of the following network service primitives:
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;
c) DT TPDU in classes 0 or 1 and AK TPDU in class 1.
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:
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;
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.
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
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;
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.
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.
The procedure makes use of the following TPDU and parameter:
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’.
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.
The procedure makes use of the following network service primitives:
The procedure makes use of the following TPDUs and parameters:
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.
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.
The reassignment after failure procedure is used in Classes 1 and 3 to commence recovery from an NS-provider signalled disconnect.
The procedure uses the following network service primitive:
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:
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
transport connection is considered released and the reference is frozen (see 6.18).
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.
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:
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.
6.13 Retention until acknowledgement of TPDUs
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.
The procedure uses the following network service primitives:
The procedure uses the following TPDUs and parameters:
Copies of the following TPDUs shall be retained upon transmission to permit their later retransmission:
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.
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.
+-------------------------------------------------------------+ |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. | +-------------------------------------------------------------+
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.
The procedure makes use of the following network service primitive:
The procedure uses the following TPDUs and parameters:
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.
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;
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.
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;
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.
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.
The procedure makes use of the following TPDUs and parameters:
CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs
The transport entities shall be able to send and receive on the same network connection TPDUs belonging to different transport connections.
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).
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.
The procedure makes use of the following TPDUs and parameters:
- YR-TU-NR; - subsequence number; - flow control confirmation.
The procedures differ in different classes. They are defined in the clauses specifying the separate classes.
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.
The procedure uses the following TPDUs and parameters:
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)
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).
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.
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.
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).
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.
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.
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.
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).
The procedure is used in Class 4 to cope with unsignalled loss of TPDUs by the NS-provider.
The procedure makes use of the following TPDUs:
The procedure is specified in the procedures for Class 4 (see 12.2.1.2.j).
The resequencing procedure is used in Class 4 to cope with misordering of TPDUs by the network service provider.
The procedure uses the following TPDUs and parameters:
The procedure is specified in the procedures for Class 4 (see 12.2.3.5).
The inactivity control procedure is used in Class 4 to cope with unsignalled termination of a network connection.
The procedure is specified in the procedures for Class 4 (see 12.2.3.3).
The procedure for treatment of protocol errors is used in all classes to deal with invalid TPDUs.
The procedure uses the following TPDUs and parameters:
a) ER TPDU; - reject cause; - TPDU in error.
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:
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.
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.
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.
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.
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.
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.
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.
+---|---------------------------------------------------------+ | * |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. | +-------------------------------------------------------------+
+----------------------------------------------------------------+ | |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
+----------------------------------------------------------------+ | 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
8 SPECIFICATION FOR CLASS 0. SIMPLE CLASS
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.1 Procedures applicable at all times
The transport entities shall use the following procedures:
b) association of TPDUs with transport connections (see 6.9);
c) treatment of protocol errors (see 6.22);
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);
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.
The transport entities shall use the segmenting and reassembling procedure (see 6.3).
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.
9 SPECIFICATION FOR CLASS 1: BASIC ERROR RECOVERY CLASS
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.1 Procedures applicable at all times
The transport entities shall use the following procedures:
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);
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.
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).
The sending transport entity shall use the following procedures;
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
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).
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.
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
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.
The transport entities shall use the explicit variant of the release procedure (see 6.7).
10 SPECIFICATION FOR CLASS 2 - MULTIPLEXING CLASS
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.1 Procedures applicable at all times
The transport entities shall use the following procedures
a) association of TPDUs with transport connection (see 6.9);
c) treatment of protocol errors (see 6.22);
d) concatenation and separation (see 6.4);
Additionally the transport entities may use the following procedure:
f) multiplexing and demultiplexing (see 6.15).
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
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
The sending transport entity shall use the following procedures:
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
The variant of the DT TPDU numbering which is used by both transport entities shall be that which was agreed at connection establishment.
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).
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).
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.
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.
The transport entities shall use the explicit variant of the release procedure in 6.7.
11 SPECIFICATION FOR CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS
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.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);
Additionally, the transport entities may use the following procedure:
g) multiplexing and demultiplexing (see 6.15);
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).
The sending transport entity shall use the following procedures:
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.
Obstetric Medicine: The Medicine of Pregnancy Response to Adam Morton's Letter 'Reply to: Timothy A C Snow, Cara A Wasywich and Fiona M Stewart. A case of breathlessness during pregnancy: the difficulty in diagnosing heart failure' The online version of this article can be found at: can be found at: Obstetric Medicine: The Medicine of Pregnancy Additional services and inf