_ Fascicle VIII.5 - Rec. X.224 Fascicle VIII.5 - Rec. X.224 _ Recommendation X.224 TRANSPORT PROTOCOL SPECIFICATION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS1 (Malaga-Torremolinos, 1984; amended at Melbourne, 1988) The CCITT, considering (a) that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT Applications; (b) that Recommendation X.214 is the Transport Service Definition for Open Systems Interconnection for CCITT Applications; (c) that Recommendation X.213 is the Network Service Definition for Open Systems Interconnection for CCITT Applications; (d) that Recommendation T.70 defines the Network-Independent Basic Transport Service for Teletex, unanimously declares (1) that scope, field of application, references, definitions, symbols and abbreviations are given in ¤¤ 1 to 4; (2) that the Transport Protocol is overviewed in ¤ 5; (3) that the elements of procedure are as specified in ¤ 6; (4) that the classes of protocol are as specified in ¤¤ 7 to 12; (5) that the structure and encoding of the transport protocol data units is as specified in ¤ 13; (6) that the conformance requirements are as specified in ¤ 14; (7) that the state table description of the Transport Protocol is contained in Annex A. CONTENTS 0 Introduction 1 Scope and field of application 2 References 3 Definitions 4 Symbols and abbreviations 5 Overview of the transport protocol 5.1 Service provided by the transport layer 5.2 Service assumed from the network layer 5.3 Functions of the transport layer 5.4 Classes and options 5.5 Model of the transport layer 6 Elements of procedure 6.1 Assignment to network connection 6.2 Transport protocol data unit (TPDU) transfer 6.3 Segmenting and reassembling 6.4 Concatenation and separation 6.5 Connection establishment 6.6 Connection refusal 6.7 Normal release 6.8 Error release 6.9 Association of TPDUs with transport connections 6.10 Data TPDU numbering 6.11 Expedited data transfer 6.12 Reassignment after failure 6.13 Retention until acknowledgment of TPDUs 6.14 Resynchronization 6.15 Multiplexing and demultiplexing 6.16 Explicit flow control 6.17 Checksum 6.18 Frozen references 6.19 Retransmission on timeout 6.20 Resequencing 6.21 Inactivity control 6.22 Treatment of protocol errors 6.23 Splitting and recombining 7 Protocol classes 8 Specification for Class 0: Simple Class 8.1 Functions of Class 0 8.2 Procedures for Class 0 9 Specification for Class 1: basic error recovery class 9.1 Functions of Class 1 9.2 Procedures for Class 1 10 Specification for Class 2: multiplexing class 10.1 Functions of Class 2 10.2 Procedures for Class 2 11 Specification for Class 3: error recovery and multiplexing class 11.1 Functions of Class 3 11.2 Procedures for Class 3 12 Specification for Class 4: error detection and recovery class 12.1 Functions of Class 4 12.2 Procedures for Class 4 13 Structure and encoding of TPDUs 13.1 Validity 13.2 Structure 13.3 Connection request (CR) TPDU 13.4 Connection confirm (CC) TPDU 13.5 Disconnect request (DR) TPDU 13.6 Disconnect confirm (DC) TPDU 13.7 Data (DT) TPDU 13.8 Expedited data (ED) TPDU 13.9 Data acknowledgment (AK) TPDU 13.10 Expedited data acknowledgment (EA) 13.11 Reject (RJ) TPDU 13.12 TPDU error (ER) TPDU 14 Conformance Annex A - State Tables Annex B - Transport Protocol Identification Appendix I - Checksum Algorithms Apendix II - Differences between Recommendation X.224 and ISO 8073 (1986) 0 Introduction The Transport Protocol is one of a set of Recommendations produced to facilitate the interconnection of computer systems. The set of Recommendations covers the services and protocols required to achieve such interconnection. The Transport Protocol is positioned with respect to other related Recommendations by the layers defined in the Reference Model of Open Systems Interconnection for CCITT Applications [1]. It is most closely related to, and lies within the field of application of the Transport Service [2]. It also uses and makes reference to the Network Service [3], whose provisions it assumes in order to accomplish the transport protocol's aims. The interrelationship of these Recommendations is depicted in Figure 1/X.224. FIGURE 1/X.224 This Recommendation 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 defines mechanisms that can be used to optimize network tariffs and enhance the following qualities of service: a) different throughput; b) different error rates; c) integrity of data requirements; d) reliability requirements. It does not require an implementation to use all of these mechanisms, nor does it define methods for measuring achieved quality of service or criteria for deciding when to release transport connections following quality of service degradation. The primary aim of this Recommendation 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 Recommendation will be designers and implementors of equipment and the Recommendation contains, in notes or in Annexes, guidance on the implementation of the procedures defined in the Recommendation. 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 Recommendation 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 Recommendation 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 Recommendation contains a section on conformance of equipment claiming to implement the procedures in this Recommendation. Attention is drawn to the fact that the Recommendation does not contain any tests to demonstrate this conformance. The variations and options available within this Recommendation 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 Recommendation with statements of the options provided or required or with statements of the intended purpose of provision or use. 1 Scope and field of application 1.1 This Recommendation specifies: a) five classes of procedures: 1) Class 0: Simple Class; 2) Class 1: Basic Error Recovery Class; 3) Class 2: Multiplexing Class; 4) Class 3: Error Recovery and Multiplexing Class; 5) Class 4: Error Detection and Recovery Class; for the connection oriented transfer of data and control information from one transport entity to a peer transport entity; b) the means of negotiating the class of procedures to be used by the transport entities; c) the structure and encoding of the transport protocol data units used for the transfer of data and control information. 1.2 The procedures are defined in terms of: a) the interactions between peer transport entities through the exchange of transport protocol data units; b) the interactions between a transport entity and the transport service user in the same system through the exchange of transport service primitives; c) the interactions between a transport entity and the network service provider through the exchange of network service primitives. These procedures are defined in the main text of the standard supplemented by state tables in Annex A. 1.3 These procedures are applicable to instances of communication between systems which support the Transport Layer of the OSI Reference Model and which wish to interconnect in an open systems environment. 1.4 This Recommendation specifies, in ¤ 14, conformance for systems implementing these procedures. It does not contain tests which can be used to demonstrate these conformance requirements. 2 References [1] Recommendation X.200 - Reference Model of Open Systems Interconnection for CCITT Applications (see also ISO 7498); [2] Recommendation X.214 - Transport Service Definition for Open Systems Interconnection for CCITT Applications (see also ISO 8072; [3] Recommendation X.213 - Network Service Definition for Open Systems Interconnection for CCITT Applications (see also ISO 8348; [4] Recommendation T.70 - Network-Independent Basic Transport Service for Teletex; 3 Definitions Note - The definitions contained in this section make use of abbreviations defined in ¤ 4. 3.1 This Recommendation is based on the concepts developed in the Reference Model of Open Systems Interconnection for CCITT Applications [1] and makes use of the following terms defined in that Recommendation: a) concatenation and separation; b) segmenting and reassembling; c) multiplexing and demultiplexing; d) splitting and recombining; e) flow control. 3.2 For the purpose of this Recommendation, the following definitions apply: 3.2.1 equipment Hardware or software or a combination of both; it need not be physically distinct within a computer system. 3.2.2 transport service user An abstract representation of the totality of those entities within a single system that make use of the transport service. 3.2.3 network service provider An abstract machine which models the totality of the entities providing the network service, as viewed by a transport entity. 3.2.4 local matter A decision made by a system concerning its behaviour in the Transport Layer that is not subject to the requirements of this protocol. 3.2.5 initiator A transport entity that initiates a CR TPDU. 3.2.6 responder A transport entity with whom an initiator wishes to establish a transport connection. Note - Initiator and responder are defined with respect to a single transport connection. A transport entity can be both an initiator and responder simultaneously. 3.2.7 sending transport entity A transport entity that sends a given TPDU. 3.2.8 receiving transport entity A transport entity that receives a given TPDU. 3.2.9 preferred class The protocol class that the initiator indicates in a CR TPDU as its first choice for use over the transport connection. 3.2.10 alternative class A protocol class that the initiator indicates in a CR TPDU as an alternative choice for use over the transport connection. 3.2.11 proposed class A preferred class or an alternative class. 3.2.12 selected class The protocol class that the responder indicates in a CC TPDU that it has chosen for use over the transport connection. 3.2.13 proposed parameter The value for a parameter that the initiator indicates in a CR TPDU that it wishes to use over the transport connection. 3.2.14 selected parameter The value for a parameter that the responder indicates in a CC TPDU that it has chosen for use over the transport connection. 3.2.15 error indication An N-RESET indication, or an N-DISCONNECT indication with a reason code indicating an error, that a transport entity receives from the NS-provider. 3.2.16 invalid TPDU A TPDU which does not comply with the requirements of this Recommendation for structure and encoding. 3.2.17 protocol error A TPDU whose use does not comply with the procedures for the class. 3.2.18 sequence number a) The number in the TPDU-NR field of a DT TPDU which 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 which indicates the sequence number of the next DT TPDU expected to be received by a transport entity. 3.2.19 transmit window The set of consecutive sequence numbers which a transport entity has been authorised by its peer entity to send at a given time on a given transport connection. 3.2.20 lower window edge The lowest sequence number in a transmit window. 3.2.21 upper window edge The sequence number which is one greater than the highest sequence number in the transmit window. 3.2.22 upper window edge allocated to the peer entity The value that a transport entity communicates to its peer entity to be interpreted as its new upper window edge. 3.2.23 closed window A transmit window which contains no sequence number. 3.2.24 window information Information contained in a TPDU relating to the upper and the lower window edges. 3.2.25 frozen reference A reference which is not available for assignment to a connection because of the requirements of ¤ 6.18. 3.2.26 unassigned reference A reference that is neither currently in use for identifying a transport connection nor in a frozen state. 3.2.27 transparent (data) TS-user data which is transferred intact between transport entities and which is unavailable for use by the transport entities. 3.2.28 owner (of a network connection) The transport entity that issued the N-CONNECT request leading to the creation of that network connection. 3.2.29 retained TPDU A TPDU which is subject to the retransmission procedure or retention until acknowledgment procedure and is available for possible retransmission. 4 Symbols and abbreviations 4.1 Data units TPDU Transport Protocol Data Unit TSDU Transport Service Data Unit NSDU Network Service Data Unit 4.2 Types of transport protocol data unit CR TPDU Connection Request TPDU CC TPDU Connection Confirm TPDU DR TPDU Disconnect Request TPDU DC TPDU Disconnect Confirm TPDU DT TPDU Data TPDU ED TPDU Expedited Data TPDU AK TPDU Data Acknowledge TPDU EA TPDU Expedited Acknowledge TPDU RJ TPDU Reject TPDU ER TPDU Error TPDU 4.3 TPDU fields LI Length Indicator (field) CDT Credit (field) TSAP-ID Transport Service Access Point Identifier (field) DST-REF Destination Reference (field) SRC-REF Source Reference (field) EOT End of TSDU mark TPDU-NR DT TPDU number (field) ED-TPDU-NR ED TPDU number (field) YR-TU-NR Sequence number response (field) YR-EDTU-NR ED TPDU number response (field) 4.4 Times and associated variables T1 Local retransmission time N The maximum number of retransmissions L Time bound on reference and sequence numbers 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 timer 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 acknowledge time AR Remote acknowledge time 4.5 Miscellaneous TS-user Transport Service user TSAP Transport Service Access Point NS-provider Network Service provider NSAP Network Service Access Point QOS Quality of service 5 Overview of the transport protocol Note - This overview is not exhaustive and has been provided for guidance to the reader of this Recommendation. 5.1 Service provided by the transport layer The protocol specified in this Recommendation supports the transport service defined in [2]. Information is transferred to and from the TS-user in the transport service primitives listed in Table 1/X.224. 5.2 Service assumed from the network layer The protocol specified in this Recommendation assumes the use of the network services defined in [3]. Information is transferred to and from the NS-provider in the network service primitives listed in Table 2/X.224. 5.3 Functions of the transport layer 5.3.1 Overview of functions The functions in the transport layer are those necessary to bridge the gap between the services available from the network layer and those to be offered to the TS-users. The functions in the transport layer are concerned with the enhancement of quality of service, including aspects of cost optimization. The 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 Recommendation does not include the following functions which are under consideration for inclusion in future editions of this Recommendation: a) encryption; b) accounting mechanisms; c) status exchanges and monitoring of QOS; d) blocking; e) temporary release of network connections; f) alternative checksum algorithm. TABLE 1/X.224 Transport service primitives Primitive Parameters T-CONNECT request Called Address, T-CONNECT indication Calling Address, Expedited Data Option, Quality of Service, TS-User data. T-CONNECT response Responding Address, T-CONNECT confirm Quality of Service, Expedited Data Option, TS-User data. T-DATA request TS-User data. T-DATA indication T-EXPEDITED DATA TU-User data. request T-EXPEDITED DATA indication T-DISCONNECT request TS-User data. T-DISCONNECT Disconnect reason, indication TS-User data. 5.3.1.1 Functions used at all times The following functions, depending on 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. TABLE 2/X.224 Network service primitives Primitives X/Y Parameters (1, 2) X/Y/Z N-CONNECT request X Called address, X N-CONNECT indication X Calling address, X Receipt confirmation Y selection, Y Expedited data selection, X QOS parameter set, Z N-CONNECT response X NS user data (3). X N-CONNECT confirmation X Responding address. Y Receipt confirmation Y selection, X Expedited data selection, Z QOS parameter set, NS user data (3). N-DATA request X NX-user data. X N-DATA indication X Confirmation request. Y N-DATA ACKNOWLEDGE Y request Y N-DATA ACKNOWLEDGE indication N-EXPEDITED DATA Y NS user data. Y request Y N-EXPEDITED DATA indication N-RESET request X Reason. Z N-RESET indication X Originator, Z Reason. Z N-RESET response X N-RESET confirmation X N-DISCONNECT request X Reason, Z NS user data, Z Responding address Z N-DISCONNECT X Originator, Z indication Reason, Z NS user data Z Responding address. Z X: The Transport Protocol assumes that this feature is provided by all network service providers. Y: The Transport Protocol assumes that this feature is provided by some network service providers and a mechanism is provided to optionally use the feature. Z: The Transport Protocol does not use this parameter. Note 1 - The parameters listed in this table are those in the network service definition (Reference 3). Note 2 - The way the parameters are exchanged between the transport entity and the NS-provider is a local matter. Note 3 - Although not used in the transport protocol per se, this parameter may be used for transport protocol identification, as specified in Annex B. 5.3.1.2 Connection establishment The purpose of connection establishment is to establish a transport connection between two TS-users. The following functions of the transport layer during this phase 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). 5.3.1.3 Data transfer The purpose of data transfer is to permit duplex transmission of TSDUs between the two TS-users connected by the transport connection. This purpose is achieved by means of two-way simultaneous communication and by the following functions, some of which are used or not used in accordance with the result of the selection performed in connection establishment. a) concatenation and separation (see ¤ 6.4), a function used to collect several TPDUs into a single NSDU at the sending transport entity and to separate the TPDUs at the receiving transport entity; b) segmenting and reassembling (see ¤ 6.3), a function used to segment a single 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. 5.3.1.4 Release The purpose of release (see ¤¤ 6.7 and 6.8) is to provide disconnection of the transport connection, regardless of the current activity. 5.4 Classes and options 5.4.1 General The functions of the transport layer have been organized into classes and options. A class defines a set of functions. Options define those functions within a class which may or may not be used. This Recommendation defines five classes of protocol: a) Class 0: Simple Class; b) Class 1: Basic Error Recovery Class; c) Class 2: Multiplexing Class; d) Class 3: Error Recovery and Multiplexing Class; e) Class 4: Error Detection and Recovery Class. Note 1 - Transport connections of Classes 2, 3 and 4 may be multiplexed together onto the same network connection. Note 2 - Classes 0 to 3 do not specify mechanisms to detect unsignalled network transmission failures. 5.4.2 Negotiation The use of classes and options is negotiated during connection establishment. The choice made by the transport entities will depend on: 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 for the TS-user. 5.4.3 Choice of network connection The following list classifies network services in terms of quality with respect to error behaviour in relation to user requirements; its main purpose is to provide a basis for the decision regarding which class of transport connection should be used in conjunction with a 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 connection. 5.4.4 Characteristics of Class 0 Class 0 provides the simplest type of transport connection and is fully compatible with Recommendation T.70 [4]. Class 0 has been designed to be used with type A network connections. 5.4.5 Characteristics of Class 1 Class 1 provides a basic transport connection with minimal overheads. The main purpose of the class is to recover from network disconnect or reset. Selection of this class is usually based on reliability criteria. Class 1 has been designed to be used with type B network connections. 5.4.6 Characteristics of Class 2 5.4.6.1 General Class 2 provides a way to multiplex several transport connections onto a single network connection. This class has been designed to be used with type A network connections. 5.4.6.2 Use of explicit flow control The objective is to provide flow control to help avoid congestion at transport-connection-end-points and on the network connection. Typical use is when traffic is heavy and continuous, or when there is intensive multiplexing. Use of flow control can optimize response times and resource utilization. 5.4.6.3 Non-use of explicit flow control The objective is to provide a basic transport connection with minimal overheads suitable when explicit disconnection of the transport connection is desirable. The option would typically be used for unsophisticated terminals, and when no multiplexing onto network connections is required. Expedited data is never available. 5.4.7 Characteristics of Class 3 Class 3 provides the characteristics of Class 2 plus the ability to recover from network disconnect or reset. Selection of this class is usually based upon reliability criteria. Class 3 has been designed to be used with type B network connections. 5.4.8 Characteristics of Class 4 Class 4 provides the characteristics of Class 3, plus the capability to detect and recover from errors which occur as a result of the low grade of service available from the NS-provider. The kinds of errors to be detected include: TPDU loss, TPDU delivery out of sequence, TPDU duplication and TPDU corruption. These errors may affect control TPDUs as well as data TPDUs. This class also provides for increased throughput capability and additional resilience against network failure. Class 4 has been designed to be used with type C network connections. 5.5 Model of the transport layer A transport entity communicates with its TS-users through one or more TSAPs by means of the service primitives as defined by the transport service definition (Reference 2). 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 [3] 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 (see Figure 2/X.224). FIGURE 2/X.224 - T0703600-88 6 Elements of procedure This section contains elements of procedure which are used in the specification of protocol classes in ¤¤ 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 ¤ 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 section. Note - Where network service primitives or TPDUs and parameters used are not significant for a particular element of procedure, they have not been included in the specification. 6.1 Assignment to network connection 6.1.1 Purpose The procedure is used in all classes to assign transport connections to network connections. 6.1.2 Network service primitives The procedure makes use of the following network service primitives: a) N-CONNECT; b) N-DISCONNECT. 6.1.3 Procedure Each transport connection shall be assigned to a network connection. The initiator may assign the transport connection to an existing network connection of which it is the owner or to a new network connection (see Note 1) which it creates for this purpose. The initiator shall not assign or reassign the transport connection to an existing network connection if the protocol class(es) proposed or the class in use for the transport connection are incompatible with the current usage of the network connection with respect to multiplexing (see Note 2). During the resynchronization (see ¤ 6.14) and reassignment after failure (see ¤ 6.12) procedures, a transport entity may reassign a transport connection to another network connection joining the same NSAPs, provided that it is the owner of the network connection and that the transport connection is assigned to only one network connection at any given time. During the splitting procedure (see ¤ 6.23), a transport entity may assign a transport connection to any additional network connection joining the same NSAPs, provided that it is the owner of the network connection and that multiplexing is possible on the network connection. The responder becomes aware of the assignment when it receives: a) a CR TPDU during the connection establishment procedure (see ¤ 6.5); or b) an RJ TPDU or a retransmitted CR or DR TPDU during the resynchronization (see ¤ 6.14) and reassignment after failure (see ¤ 6.12) procedures; or c) any TPDU when splitting (see ¤ 6.23) is used. Note 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. Note 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. Note 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 suggested that only the owner of such a network connection should release it. Furthermore, it is suggested that it not be released immediately after the transmission of the final TPDU of a transport connection - either a DR TPDU in response to a CR TPDU or a DC TPDU in response to a 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. Note 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. Note 5 - The transport protocol identification procedures specified in Annex B may need to be considered in conjunction with this procedure. 6.2 Transport protocol data unit (TPDU) transfer 6.2.1 Purpose The TPDU transfer procedure is used in all classes to convey transport protocol data units in user data fields of network service primitives. 6.2.2 Network service primitives This procedure uses the following network service primitives: a) N-DATA; b) N-EXPEDITED DATA. 6.2.3 Procedure The transport protocol data units (TPDUs) defined for the protocol are listed in ¤ 4.2. When the network expedited variant has been selected for Class 1, the transport entities shall transmit and receive ED and EA TPDUs as NS-user data parameters of N-EXPEDITED DATA primitives. In all other cases, transport entities shall transmit and receive TPDUs as NS-user data parameters of N-DATA primitives. When a TPDU is put into an NS-user data parameter, the significance of the bits within an octet and the order of octets within a TPDU shall be as defined in ¤ 13.2. Note 1 - TPDUs may be concatenated (see ¤ 6.4). Note 2 - The transport protocol identification procedures specified in Annex B may need to be considered in conjunction with this procedure. 6.3 Segmenting and reassembling 6.3.1 Purpose The segmenting and reassembling procedure is used in all classes to map TSDUs onto TPDUs. 6.3.2 TPDUs and parameters used The procedure makes use of the following TPDU and parameter: DT TPDU: - End of TSDU. 6.3.3 Procedure A transport entity shall map a TSDU on to an ordered sequence of one or more DT TPDUs. This sequence shall not be interrupted by other DT TPDUs on the same transport connection. All DT TPDUs except the last DT TPDU in a sequence greater than one shall have a length of data greater than zero. Note 1 - The EOT of a DT TPDU indicates whether or not there are subsequent DT TPDUs in the sequence. Note 2 - There is no requirement that the DT TPDUs shall be of the maximum length selected during connection establishment. 6.4 Concatenation and separation 6.4.1 Purpose The procedure for concatenation and separation is used in Classes 1, 2, 3 and 4 to convey multiple TPDUs in one NSDU. 6.4.2 Procedure A transport entity may concatenate TPDUs from the same or different transport connections while maintaining the order of TPDUs for a given transport connection compatible with the protocol operation. A valid 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. A transport entity shall accept a valid set of concatenated TPDUs. Note 1 - The TPDUs within a concatenated set may be distinguished by means of the length indicator parameter. Note 2 - The end of a TPDU containing data is indicated by the termination of the NSDU. Note 3 - The number of concatenated TPDUs referred to in ¤ 6.4.2 a) is bounded by the maximum number of transport connections which are multiplexed together, except during assignment or reassignment. 6.5 Connection establishment 6.5.1 Purpose The procedure for connection establishment is used in all classes to create a new transport connection. 6.5.2 Network service primitives The procedure uses the following network service primitive: N-DATA. 6.5.3 TPDUs and parameters used The procedure uses the following TPDUs and parameters: a) CR TPDU; - CDT; - DST-REF (set to zero); - SRC-REF; - CLASS and OPTIONS (preferred), i.e.: i) class, ii) use of extended format, iii) non-use of explicit flow control in Class 2; - calling TSAP-ID; - called TSAP-ID; - TPDU size (proposed); - version number; - protection parameter; - checksum; - additional option selection (preferred), i.e.: i) use of network expedited in Class 1, ii) use of receipt confirmation in Class 1, iii) non-use of checksums in Class 4, iv) use of transport expedited data transfer service; - alternative protocol class(es); - acknowledge time; - throughput (proposed); - residual error rate (proposed); - priority (proposed); - transit delay (proposed); - reassignment time; - user data. b) CC TPDU; - CDT; - DST-REF; - SRC-REF; - CLASS and OPTIONS (selected); - calling TSAP-ID; - called TSAP-ID; - TPDU size (selected); - protection parameter; - checksum; - additional option selection (selected); - acknowledge time; - throughput (selected); - residual error rate (selected); - priority (selected); - transit delay (selected); - user data. 6.5.4 Procedure A transport connection is established by means of one transport entity (the initiator) transmitting a CR TPDU to the other transport entity (the responder), which replies with a CC TPDU. Before sending the CR TPDU, the initiator assigns the transport connection being created to one (or more if the splitting procedure is being used) network connection(s). It is this set of network connections over which the TPDUs are sent. Note - Even if the initiator assigns the transport connection to more than one network connection, all the CR TPDUs (if repeated) or DR TPDUs with DST-REF set to zero which are sent prior to the receipt of the CC TPDU, shall be sent on the same network connection, unless an N-DISCONNECT indication is received. (This is necessary because the remote entity may not support Class 4 and therefore may not recognize splitting.) If the initiator has made other assignments, it will use them only after receipt of a Class 4 CC TPDU (see also the splitting procedure ¤ 6.23). During this exchange, all information and parameters needed for the transport entities to operate shall be exchanged or negotiated. Note 1 - The transport protocol identification procedures specified in Annex B may need to be considered in conjunction with this procedure. Note 2 - Except in Class 4, it is suggested that the initiator start 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. When an unexpected duplicated CR TPDU is received (with Class 4 as preferred class), it shall be ignored in Classes 0, 1, 2 and 3 and a CC TPDU shall be returned in Class 4. After receiving the CC TPDU for a class which includes the procedure for retention until acknowledgment of TPDUs, the initiator shall acknowledge the CC TPDU as defined in Table 5/X.224 (see ¤ 6.13). When the network expedited variant of expedited data transfer (see ¤ 6.11) has been agreed (possible in Class 1 only), the responder shall not send an ED TPDU before the CC TPDU is acknowledged. The following information is exchanged: a) references - Each transport entity chooses a reference to be used by the peer entity which is 16 bits long and which is arbitrary except for the following restrictions: 1) it shall not already be in use or frozen (see ¤ 6.18), 2) it shall not be zero. This mechanism is symmetrical and provides identification of the transport connection independent of the network connection. The range of references used for transport connections, in a given transport entity, is a local matter. b) calling and called TSAPs-IDs (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/X.224, 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) acknowledgment time - Only in Class 4. f) checksum parameter - Only in Class 4. g) protection parameter - This parameter and its semantics are user defined. TABLE 3/X.224 Valid responses corresponding to preferred and any alternative class proposed in the CR TPDU Preferre Alternative class d class 0 1 2 3 4 none 0 not not not not not class 0 valid valid valid valid valid 1 class 1 class 1 not not not class 1 or 0 or 0 valid valid valid or 0 2 class 2 not class 2 not not class 2 or 0 valid valid valid 3 class class class 3 class 3 not class 3 3, 2 3, 2, 1 or 2 or 2 valid or 2 or 0 or 0 4 class class class 4 class class 4 class 4 4, 2 4, 2, 1 or 2 4, 3 or 2 or 2 or 0 or 0 or 2 Note 1 - The valid responses indicated in the table result from both explicit negotiation, whereby each of the classes proposed is a valid response and implicit negotiation, whereby: - if class 3 or 4 is proposed then class 2 is a valid response; - if class 1 is proposed then class 0 is a valid response. Note 2 - Negotiation from class 2 to class 1 and from any class to a higher-numbered class is not valid. Note 3 - Redundant combinations of proposed classes can occur (e.g. due to the implicit negotiation rules). These are not considered as protocol errors. The following negotiations take place: h) protocol class - The initiator shall propose a preferred class and any number of alternative classes which permit a valid response as defined in Table 3/X.224. 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/X.224 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 to the procedures of the selected class. i) 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 for the class (see ¤ 13.3.4 b)). Note - The length of the CR TPDU does not exceed 128 octets (see ¤ 13.3). j) 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. k) checksum selection - This defines whether or not TPDUs of the connection are to include a checksum. l) quality of service parameters - This defines the throughput, transit delay, priority, and residual error rate. Note - The transport service defines transit delay as requiring a previously stated average TSDU size as a basis for any specification. The protocol, as specified in ¤ 13.3.4, l), uses a value of 128 octets. Conversion to and from specifications based upon some other value is a local matter. m) the non-use of explicit flow control in Class 2. n) the use of network receipt confirmation and network expedited when Class 1 is to be used. o) the 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 definition [2]. The following information is set only in the CR TPDU: p) version number - This defines the version of the transport protocol used for this connection. q) 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/X.224. When a parameter [which is valid for the proposed class(es)] is absent and a default value is defined in this Recommendation, this is equivalent to the presence of the parameter with the default value. 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 request or agree (respectively) to the use of explicit flow control. 6.6 Connection refusal 6.6.1 Purpose The connection refusal procedure is used in all classes when a transport entity refuses a transport connection in response to a CR TPDU. TABLE 4/X.224 Negotiation of options during connection establishment Option Proposal Valid made selection by the by the initiator responder Transport expedited data Yes Yes or No transfer service No No (Classes 1, 2, 3, 4 only) Use of receipt confirmation Yes Yes or No (Class 1 only) No No Use of network expedited Yes Yes or No variant No No (Class 1 only) Non-use of checksums Yes Yes or No (Class 4 only) No No Non-use of explicit flow Yes Yes or No control No No (Class 2 only) Use of extended format Yes Yes or No (Class 2, 3 4 only) No No Note - Table 4/X.224 defines the procedures for negotiation of options. This negotiation has been designed such that if the initiator proposes the mandatory implementation option specified in ¤ 14, the responder has to accept use of this option over the transport connection, except for the use of the transport expedited data transfer service which may be rejected by the TS-user. If the initiator proposes a non-mandatory implementation option, the responder is entitled to select use of the mandatory implementation option for use over the transport connection. 6.6.2 TPDUs and parameters used The procedure makes use of the following TPDUs and parameters: a) DR TPDU: - SRC-REF; - reason; - user data. b) ER TPDU: - reject cause; - invalid TPDU. 6.6.3 Procedure If a transport connection cannot be accepted, the responder shall respond to the CR TPDU with a DR TPDU. The reason shall indicate why the connection was not accepted. The source reference field in the DR TPDU shall be set to zero to indicate an unassigned reference. If a DR TPDU is received, the initiator shall regard the connection as released. The responder shall respond to an invalid CR TPDU by sending an ER or DR TPDU. If an ER TPDU is received in response to a CR TPDU, the initiator shall regard the connection as released. Note 1 - When the invalid CR TPDU can be identified as having Class 0 as the preferred class, it is suggested to respond with an ER TPDU. For all other invalid CR TPDUs, either an ER TPDU or DR TPDU may be sent. Note 2 - If the optional supervisory timer TS1 has been set for this connection, then the initiator should stop the timer on receipt of the DR or ER TPDU. 6.7 Normal release 6.7.1 Purpose The release procedure is used by a transport entity in order to terminate a transport connection. The implicit variant is used only in Class 0. The explicit variant is used in Classes 1, 2, 3 and 4. Note 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. Note 2 - The use of the explicit variant of the release procedure enables the transport connection to be released independently of the underlying network connection. 6.7.2 Network service primitives The procedure makes use of the following network service primitives: a) N-DISCONNECT (implicit variant only), b) N-DATA. 6.7.3 TPDUs and parameters used The procedure makes use of the following TPDUs and parameters: a) DR TPDU: - reason; - user data; - SRC-REF; - DST-REF. b) DC TPDU. 6.7.4 Procedure for implicit variant In the implicit variant, either transport entity disconnects a transport connection by disconnecting the network connection to which it is assigned. When a transport entity receives an N- DISCONNECT indication, this should be considered as the release of the transport connection. 6.7.5 Procedure for explicit variant When the release of a transport connection is to be initiated, a transport entity: a) if it has previously sent or received a CC TPDU (see Note 1), shall: 1) send a DR TPDU; 2) discard all subsequently received TPDUs other than a DR or DC TPDU; 3) consider the transport connection released on receipt of a DR or DC TPDU; b) if a) is not applicable, it shall: 1) for classes other than Class 4, wait for acknowledgment of the outstanding CR TPDU; if it receives a CC TPDU, it shall follow the procedure 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). In the former case, receipt of a CC TPDU specifying Class 4 will be ignored. Receipt of a CC TPDU with another class will be processed as follows: if the class is 0, the network connection shall be disconnected; otherwise, a DR TPDU with the DST-REF field set to the value of the SRC-REF field of the received CC TPDU shall be sent and the release procedure of the class is continued. 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); If the SRC-REF is not zero, a DC TPDU shall be sent using the SRC-REF as the DST-REF. Note - In this case, the DR TPDU has been associated regardless of its SRC-REF field (see ¤ 6.9.4). e) if c) and d) are not applicable, send a DC TPDU and consider the transport connection released. If the received DR has the DST-REF field set to zero, then a DC with SRC-REF set to zero shall be sent, regardless of the local reference. If the entity receiving such a DR TPDU has previously decided to negotiate down the class, this entity is always entitled to consider such a DR TPDU as spurious. Since no association has been made, the transport connection is not released at the responder side but the CC TPDU, when sent, will be answered by a DR TPDU (spurious CC TPDU). Note 1 - This requirement ensures that the transport entity is aware of the remote reference for the transport connection. Note 2 - When the transport connection is considered as released, the local reference is either available for re-use or is frozen (see ¤ 6.18). Note 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). Note 4 - Except in Class 4, it is suggested that if a transport entity does not receive acknowledgment 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 the same network connection, the procedures for reset or disconnect as appropriate should be followed. Note 5 - When a transport entity is waiting for a CC TPDU before sending a DR TPDU and the network connection is reset or released, it should consider the transport connection released and, in classes other than Classes 0 and 2, freeze the reference (see ¤ 6.18). 6.8 Error release 6.8.1 Purpose This procedure is used only in Classes 0 and 2 to release a transport connection on the receipt of a N-DISCONNECT or N-RESET indication. 6.8.2 Network service primitives The procedure makes use of the following service primitives: a) N-DISCONNECT indication; b) N-RESET indication. 6.8.3 Procedure When, on the network connection to which a transport connection is assigned, an N-DISCONNECT or N-RESET indication is received, both transport entities shall consider that the transport connection is released, and so inform the TS-users. Note - In other classes, since error recovery is used, the receipt of an N-RESET indication or N-DISCONNECT indication will result in the invocation of the error recovery procedure. 6.9 Association of TPDUs with transport connections 6.9.1 Purpose This procedure is used in all classes to interpret a received NSDU as TPDU(s) and, if possible, to associate each such TPDU with a transport connection. 6.9.2 Network service primitives This procedure makes use of the following network service primitives: a) N-DATA indication; b) N-EXPEDITED DATA indication. 6.9.3 TPDUs and parameters used This procedure makes use of the following TPDUs and parameters: a) in any TPDU except: CR TPDU; DT TPDU in Classes 0 or 1; AK TPDU in Class 1: - DST-REF. b) CR, CC, DR and DC TPDUs: - SRC-REF. c) DT TPDU in Classes 0 or 1 and AK TPDU in Class 1. 6.9.4 Procedures 6.9.4.1 Identification of TPDUs If the received NSDU or expedited NSDU cannot be decoded (i.e. does not contain one or more correct TPDUs) or is corrupted (i.e. contains a TPDU with a wrong checksum) then the transport entity shall: a) if the network connection on which the error is detected has a Class 0 or Class 1 transport connection assigned to it, then treat as a protocol error (see ¤ 6.22) for that transport connection; b) otherwise: 1) if the NSDU can be decoded but contains corrupted TPDUs, discard the TPDUs (Class 4 only) and optionally apply ¤ 6.9.4.1 b) 2); 2) if the NSDU cannot be decoded, issue an N-RESET (or N- DISCONNECT) request for the network connection and for all of 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 one TPDU and associate the TPDU with the transport connection (see ¤ 6.9.4.2); d) otherwise, invoke the separation procedures and for each of the individual TPDUs in the order in which they appear in the NSDU apply the procedure defined in ¤ 6.9.4.2. 6.9.4.2 Association of individual TPDUs If the received TPDU is a CR TPDU, then, if it is a duplicate as recognized by using the NSAPs of the network connection, and the SRC-REF parameter, then it is associated with the transport connection created by the original copy 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 Class 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 discard the TPDU if neither a DR TPDU nor CC TPDU. No association with a transport connection is made. Note - If the DR TPDU is carrying an SRC-REF field set to zero, then no DC TPDU shall be sent. 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 associated with this transport connection and 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 except in the case of DC, DR and CC TPDUs which are respectively described in ¤ 6.9.4.2 c), d) and e); 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 discarded. d) If the TPDU is a DR TPDU then there are four cases: 1) if the SRC-REF is not as expected, then a DC TPDU with a 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) if the transport entity implements Class 4 and if the DST- REF is zero and there is an unacknowledged CC TPDU or T-CONNECT response is awaited, then the DR TPDU shall be associated with the transport connection holding the SRC-REF as the remote reference; 4) otherwise, the DR TPDU is associated with the transport connection identified by the DST-REF parameter. e) If the TPDU is a CC TPDU whose DST-REF parameter identifies an open connection (one for which a CC TPDU has been previously received), and the SRC-REF in the CC TPDU does not match the remote reference, then a DR TPDU is sent back with DST-REF equal to the SRC-REF of the received CC TPDU and no association is made. f) If none of the above cases apply, then the TPDU is associated with the transport connection identified by the DST-REF parameter. 6.10 Data TPDU numbering 6.10.1 Purpose Data TPDU numbering is used in Classes 1, 2 (except when the non-use of explicit flow control option is selected), 3 and 4. Its purpose is to enable the use of recovery, flow control and resequencing functions. 6.10.2 TPDUs and parameters used This procedure makes use of the following TPDU and parameter: DT TPDU; - TPDU-NR. 6.10.3 Procedure A transport entity shall allocate the sequence number zero to the TPDU-NR of the first DT TPDU which it transmits for a transport connection. For subsequent DT TPDUs sent on the same transport connection, the transport entity shall allocate a sequence number one greater than the previous one. When a DT TPDU is retransmitted, the TPDU-NR parameter shall have the same value as in the first transmission of that DT TPDU. Modulo 27 arithmetic shall be used when normal formats have been selected and modulo 231 arithmetic shall be used when extended formats have been selected. In this Recommendation, the relationships Ògreater thanÓ and Òless thanÓ apply to a set of contiguous TPDU numbers whose range is less than the modulus and whose starting and finishing numbers are known. The term Òless thanÓ means Òoccurring sooner in the window sequenceÓ and the term Ògreater thanÓ means Òoccurring later in the window sequenceÓ. 6.11 Expedited data transfer 6.11.1 Purpose Expedited data transfer procedures are selected during connection establishment. The network normal data variant may be used in Classes 1, 2, 3 and 4. The network expedited variant is only used in Class 1. 6.11.2 Network service primitives The procedure makes use of the following network service primitives: a) N-DATA; b) N-EXPEDITED DATA. 6.11.3 TPDUs and parameters used The procedure makes use of the following TPDUs and parameters: a) ED TPDU: - ED-TPDU-NR. b) EA TPDU: - YR-EDTU-NR. 6.11.4 Procedure 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 shall be treated as a protocol error. Note 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). Note 2 - No TPDUs can be transmitted using network expedited until the CC TPDU becomes acknowledged, to prevent the network expedited from overtaking the CC TPDU. 6.12 Reassignment after failure 6.12.1 Purpose The reassignment after failure procedure is used in Classes 1 and 3 to commence recovery from an NS-provider signalled disconnect. 6.12.2 Network service primitives The procedure uses the following network service primitive: N-DISCONNECT indication. 6.12.3 Procedure When an N-DISCONNECT indication is received for 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 TTR expires and while waiting for the next event, it is suggested that the initiator set a timer with a value equal to TWR. If this 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). If reassignment occurs successfully, both transport entities shall continue with resynchronization. Note - The transport protocol identification procedures specified in Annex B may need to be considered in conjunction with this procedure. 6.12.4 Timers The reassignment after failure procedure uses two timers: a) TTR, the time to try reassignment/resynchronization timer; b) TWR, the time to wait for reassignment/resynchronization timer. The TWR timer is used by the initiator. Its value shall not exceed two minutes minus the sum of the maximum disconnect propagation delay and the maximum 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 maximum 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. Note 1 - Provided that the required quality of service is met, TTR may be set to zero (i.e., no reassignment), for example if the rate of NS-provider generated disconnects is very low. Note 2 - Inclusion of the reassignment time parameter in the CR TPDU allows the responder to use a TWR value of less than 2 minutes. Note 3 - If the optional TS1 and TS2 timers are used, it is suggested: 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 acknowledgment of TPDUs 6.13.1 Purpose The retention until acknowledgment of TPDUs procedure is used in Classes 1, 3 and 4 to enable and minimize retransmission after possible loss of TPDUs. The confirmation of receipt variant is used only in Class 1 when it has been agreed during connection establishment (see Note). The AK variant is used in Classes 3 and 4 and also in Class 1 when the confirmation of receipt variant has not been agreed during connection establishment. Note - Use of confirmation of receipt variant depends on the availability of the network layer receipt confirmation service and the expected cost reduction. 6.13.2 Network service primitives The procedure uses the following network service primitives: a) N-DATA; b) N-DATA ACKNOWLEDGE. 6.13.3 TPDUs and parameters used The procedure uses the following TPDUs and parameters: a) CR, CC, DR and DC TPDUs. b) RJ and AK TPDUs: - YR-TU-NR. c) DT TPDU: - TPDU-NR. d) ED TPDU: - ED-TPDU-NR. e) EA TPDU: - YR-EDTU-NR. 6.13.4 Procedure Copies of the following TPDUs shall be retained upon transmission to permit their later retransmission: CR, CC, DR, DT and ED TPDUs except that if a DR TPDU is sent in response to a CR TPDU, there is no need to retain a copy of the DR TPDU. A copy of each of these TPDUs shall be retained until: a) it is acknowledged, as specified in Table 5/X.224; or b) the transport connection is released. In the confirmation of receipt variant, applicable only in Class 1, transport entities shall: a) set the confirmation request parameter only if the data parameter contains a CC or DT TPDU (see Notes 1 and 2); and b) issue an N-DATA ACKNOWLEDGE request when it receives an N- DATA indication with the confirmation request parameter set. Note 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. Note 2 - Use of the confirmation request parameter may affect the quality of network service. TABLE 5/X.224 Acknowledgement of TPDUs Retained Variant Retained until acknowledged by TPDU CR both CC, DR or ER TPDU. DR both DC or DR (in case of collision) TPDU. CC Confirmation N-DATA ACKNOWLEDGE indication, of receipt RJ, DT, ED or EA TPDU. CC AK RJ, DT, AK, ED or EA TPDU. DT Confirmation N-DATA ACKNOWLEDGE indication of receipt corresponding to an N-DATA request which conveyed, or came after, the DTÊTPDU. DT AK 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. 6.14 Resynchronization 6.14.1 Purpose The resynchronization procedures are used in Classes 1 and 3 to restore the transport connection to normal after a reset or during reassignment after failure according to ¤ 6.12. 6.14.2 Network service primitives The procedure makes use of the following network service primitive: N-RESET indication. 6.14.3 TPDUs and parameters used The procedure uses the following TPDUs and parameters: a) CR, DR, CC and DC TPDUs. b) RJ TPDU: - YR-TU-NR. c) DT TPDU: - TPDU-NR. d) ED TPDU: - ED-TPDU-NR. e) EA TPDU: - YR-EDTU-NR. 6.14.4 Procedure A transport entity which is notified of the occurrence of an N- RESET or which is performing reassignment after failure according to ¤ 6.12 shall carry out the active resynchronization procedures (see ¤ 6.14.4.1) unless any of the following hold: a) the transport entity is the responder. In this case, the passive resynchronization procedure shall be 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 resynchronizaion 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 one 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 commences resynchronization (i.e. CR or DR or ED 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 action which is appropriate from the following: 1) if a CC TPDU has alredy 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 any unacknowledged ED TPDU (see Note 2) and any DT TPDU. Note 1 - A repeated CR can be identified by being on a network connection with the appropriate network addresses and having a correct source reference. Note 2 - The transport entity should not use network expedited until the CC 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) if a CC TPDU is unacknowledged, the RJ or ED TPDU shall be considered as acknowledging the CC TPDU, and the transport entity shall carry out the data resynchronization procedures (¤ 6.14.4.3); 3) if a CC TPDU was never sent, the RJ or ED TPDU should be considered as a protocol error; 4) otherwise, the transport entity shall carry out the data resynchronization procedures (¤ 6.14.4.3.) 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 it has already been received. If a DR TPDU is received, the transport entity shall send a DC TPDU, 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 procedures of ¤ 6.14.4.3 d) shall be followed. If an ED TPDU is received, the procedures as described in ¤ 6.11 shall be followed. If it is a duplicated ED TPDU, the transport entity shall acknowledge it with an EA TPDU, discard the duplicated ED TPDU and wait again for the next TPDU; d) (re)transmit any DT TPDUs which are unacknowledged, subject to any applicable flow control procedures (see Note). Note - The RJ TPDU may have reduced the credit. 6.15 Multiplexing and demultiplexing 6.15.1 Purpose The multiplexing and demultiplexing procedures are used in Classes 2, 3 and 4 to allow several transport connections to share a network connection at the same time. 6.15.2 TPDUs and parameters used The procedure makes use of the following TPDUs and parameters: CC, DR, DC, DT, AK, ED, EA, RJ and ER TPDUs: - DST-REF. 6.15.3 Procedure The transport entities shall be able to send and receive on the same network connection TPDUs belonging to different transport connections. Note 1 - When performing demultiplexing, the transport connection to which the TPDUs apply is determined by the procedures defined in ¤ 6.9. Note 2 - Multiplexing allows the concatenation of TPDUs belonging to different transport connections to be transferred in the same N-DATA primitive (see ¤ 6.4). 6.16 Explicit flow control 6.16.1 Purpose The explicit flow control procedure is used in Classes 2, 3 and 4 to regulate the flow of DT TPDUs independently of the flow control in the other layers. 6.16.2 TPDUs and parameters used The procedure makes use of the following TPDUs and parameters: a) CR, CC, AK and RJ TPDUs: - CDT. b) DT TPDU: - TPDU-NR. c) AK TPDU: - YR-TU-NR; - subsequence number; - flow control confirmation. d) RJ TPDU: - YR-TU-NR. 6.16.3 Procedure The procedures differ in different classes. They are defined in the sections specifying the separate classes. 6.17 Checksum 6.17.1 Purpose The checksum procedure is used to detect corruption of TPDUs by the NS-provider. Note - Although a checksum algorithm has to be adapted to the type of errors expected on the network connection, at present only one algorithm is defined. 6.17.2 TPDUs and parameters used The procedure uses the following TPDUs and parameters: All TPDUs: - checksum. 6.17.3 Procedure The checksum is used only in Class 4. It shall always be used for the CR TPDU, and shall be used for all other TPDUs unless the non-use of the checksum was selected during connection establishment. The sending transport entity shall transmit TPDUs with the checksum parameter set such that the following formulae are satisfied: Li=1 ai ¼ 0 (modulo 255) Li=1 iai ¼ 0 (modulo 255) where i = number (i.e. position) of an octet within the TPDU (see $ 13.2). ai = value of octet in position i. 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 formulae shall discard the TPDU (see also Note 2). When a spurious TPDU is received and an answer is to be sent the transport entity shall: a) if it supports the checksum algorithm and the received TPDU contains a checksum parameter, include a checksum parameter in the answering TPDU; or b) in all other cases, not include a checksum parameter in the answering TPDU. An entity not supporting checksum may always suppose that a CR TPDU with Class 4 proposed is correct and therefore negotiate down to a class lower than 4. Note 1 - An efficient algorithm for determining the checksum parameters is given in Appendix I. Note 2 - If the checksum is incorrect, it is not possible to know with certainty to which transport connection the TPDU is related; thus, further action may be taken for all the transport connections assigned to the network connection (see ¤ 6.9). Note 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. Note 4 - When a TPDU is received on a network connection, it is never possible to know with certainty that only Class 4 transport connections use this network connection because it may be a TPDU performing reassignment. Therefore the only way to check the validity is the following: a) if the network connection is used by a Class 0 or Class 1 transport connection, there is no checksum; b) examine the TPDU code; c) deduce the fixed part length; d) from LI, deduce the variable part; e) go through parameters and if the checksum parameter is found, then verify it; f) if it is incorrect, then assume that transport connection is Class 4 and drop it; g) if it is correct, then associate the TPDU with a transport connection; if the transport connection uses the checksum, it is correct; else, it must be considered as a protocol error. 6.18 Frozen references 6.18.1 Purpose This procedure is used in order to prevent re-use of a reference while TPDUs associated with the old use of the reference may still exist. 6.18.2 Procedure When a transport entity determines that a particular connection is released, it shall place the reference which it has allocated to the connection in a frozen state according to the procedures of the class. While frozen, the reference shall not be re-used. Note - The frozen reference procedure is necessary because retransmission or misordering can cause TPDUs bearing a reference to arrive at an entity after it has released the connection for which it allocated the reference. Retransmission, for example, can arise when the class includes either resynchronization (see ¤ 6.14) or retransmission on timeout (see ¤ 6.19). 6.18.2.1 Procedure for Classes 0 and 2 This Recommendation does not specify frozen reference procedures for classes 0 and 2. Note - For consistency with the other classes, references may be frozen as a local matter. 6.18.2.2 Procedure for Classes 1 and 3 The frozen reference procedure is used except in the following cases (see Note 1): a) when the transport entity receives a DC TPDU in response to a DR TPDU which it has sent (see Note 2); b) when the transport entity sends a DR 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. Note 1 - However, even in these cases, for consistency, freezing the reference may be done as a local decision. Note 2 - When the DC TPDU is received, it is certain that the other transport entity considers the connection released. Note 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). Note 4 - In ¤ 6.18.2 c), the transport entity has already effectively frozen the reference for an adequate period. 6.18.2.3 Procedure for Class 4 The frozen reference procedure shall be used in Class 4. The period for which the reference remains frozen shall be greater than L (see ¤ 12.2.1.1.6). 6.19 Retransmission on timeout 6.19.1 Purpose The procedure is used in Class 4 to cope with unsignalled loss of TPDUs by the NS-provider. 6.19.2 TPDUs used The procedure makes use of the following TPDUs: CR, CC, DR, DT, ED and AK TPDUs. 6.19.3 Procedure The procedure is specified in the procedures for Class 4 (see ¤ 12.2.1.2 i)). 6.20 Resequencing 6.20.1 Purpose The resequencing procedure is used in Class 4 to cope with misordering of TPDUs by the NS-provider. 6.20.2 TPDUs and parameters used The procedure uses the following TPDUs and parameters: a) DT TPDU: - TPDU-NR. b) ED TPDU: - ED-TPDU-NR. 6.20.3 Procedure The procedure is specified in the procedures for Class 4 (see ¤ 12.2.3.5). 6.21 Inactivity control 6.21.1 Purpose The inactivity control procedure is used in Class 4 to cope with unsignalled termination of a network connection. 6.21.2 Procedure The procedure is specified in the procedures for Class 4 (see ¤ 12.2.3.3). 6.22 Treatment of protocol errors 6.22.1 Purpose The procedure for treatment of protocol errors is used in all classes to deal with invalid TPDUs. 6.22.2 TPDUs and parameters used The procedure uses the following TPDUs and parameters: a) ER TPDU: - reject cause; - invalid TPDU. b) DR TPDU: - reason code. 6.22.3 Procedure A transport entity that receives a TPDU that can be associated to a transport connection and is invalid or constitutes a protocol error (see ¤¤ 3.2.16 and 3.2.17) shall take one of the following actions so as not to jeopardize any other transport connections not assigned to that network connection: a) transmitting an ER TPDU; b) resetting or closing the network connection; or c) invoking the release procedures appropriate to the class. Under certain circumstances it is also possible to discard the TPDU. 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 with a particular transport connection, the transport entity shall follow the procedure in ¤ 6.9. Note 1 - In general, no further action is specified for the receiver of the ER TPDU, but it is suggested 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). Note 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. Note 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. Note 4 - It is suggested that the sender of the ER TPDU start a 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. Note 5 - In classes other than 0, it is suggested that the invalid TPDU be also included in the ER TPDU. 6.23 Splitting and recombining 6.23.1 Purpose This procedure is used only in Class 4 to allow a transport connection to make use of multiple network connections to provide additional resilience against network failure, to increase throughput, or for other reasons. 6.23.2 Procedure When this function 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. Note 1 - The resequencing function of Class 4 (see ¤ 6.20) is used to ensure that TPDUs are processed in the correct sequence. Note 2 - Either transport entity may assign the connection to further network connections of which it is the owner at any time during the lifetime of the transport connection, provided the following constraints are respected: - the initiator does not start splitting before having received the CC TPDU; - as soon as a new assignment is done, it is recommended to send a TPDU on this network connection in order to make the remote entity aware of this assignment. Note 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. 7 Protocol classes Table 6/X.224 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/X.224 cannot be considered part of the definitive specification of the protocol. 8 Specification for Class 0: simple class 8.1 Functions of Class 0 Class 0 is designed to have minimum functionality. It provides only the functions needed for connection establishment with negotiation, data transfer with segmenting and protocol error reporting. Class 0 provides transport connections with flow control based on the network service provided flow control, and disconnection based on the network service disconnection. 8.2 Procedures for Class 0 8.2.1 Procedures applicable at all times The transport entities shall use the following procedures: a) TPDU transfer (see ¤ 6.2); b) association of TPDUs with transport connections (see ¤ 6.9); c) treatment of protocol errors (see ¤ 6.22); d) error release (see ¤ 6.8). TABLE 6/X.224 Allocation of elements of procedure within classes Procedure Cross Variant 0 1 2 3 4 ref. Assignment to network 6.1 X X X X X conn. TPDU Transfer 6.2 X X X X X Segmenting and 6.3 X X X X X reassembling Concatenation and 6.4 X X X X separation Connection 6.5 X X X X X Establishment Connection Refusal 6.6 X X X X X implicit X Normal Release 6.7 explicit X X X X Error Release 6.8 X X Association of TPDUs 6.9 X X X X X with TCs normal X m m m Data TPDU Numbering 6.10 extended a) o o o a) network m X X X Expedited Data 6.11 normal ao a) Transfer network express Reassignment after 6.12 X X c) failure Conf. ao X X Retention until 6.13 receipt m acknowledgement of AK TPDUs Resynchronization 6.14 X X c) Multiplexing and 6.15 X X X Demultiplexing b) Explicit Flow Control m X X (with) 6.16 X X o Explicit Flow Control (without) Checksum (use of) X Checksum (non-use of) 6.17 X X X X o Frozen References 6.18 X X X Retransmission on 6.19 X Timeout Resequencing 6.20 X Inactivity Control 6.21 X Treatment of Protocol 6.22 X X X X X Errors Splitting and 6.23 X Recombining X: Procedure always included in class. empty square: 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. a) Not applicable in class 2 when non-use of explicit flow control is selected. b) Multiplexing may lead to degradation of the quality of service if the non-use of explicit flow control has been selected. c) This function is provided in class 4 using procedures other than those used in the cross reference. 8.2.2 Connection establishment The transport entities shall use the following procedures: a) assignment to network connection (see ¤ 6.1); then b) connection establishment (see ¤ 6.5) and, if appropriate, connection refusal (see ¤ 6.6); subject to the following constraints: c) the CR and CC TPDUs shall contain no parameter field other than those for TSAP-ID and maximum TPDU size; d) the CR and CC TPDUs shall not contain a data field. 8.2.3 Data transfer The transport entities shall use the segmenting and reassembling procedure (see ¤ 6.3). 8.2.4 Release The transport entities shall use the implicit variant of the normal release procedure (see ¤ 6.7). Note - The lifetime of the transport connection is directly correlated with the lifetime of the network connection. 9 Specification for Class 1: basic error recovery class 9.1 Functions of Class 1 Class 1 provides transport connections with flow control based on the network service provided flow control, error recovery, expedited data transfer, disconnection, and also the ability to support consecutive transport connections on a network connection. This class provides the functionality of Class 0 plus the ability to recover after a failure signalled by the Network Layer, without involving the TS-user. 9.2 Procedures for Class 1 9.2.1 Procedures applicable at all times The transport entities shall use the following procedures: a) TPDU transfer (see ¤ 6.2); b) association of TPDU with transport connections (see ¤ 6.9); c) treatment of protocol errors (see ¤ 6.22); d) reassignment after failure (see ¤ 6.12); e) resynchronization (see ¤ 6.14), or reassignment after failure (see ¤ 6.12) together with resynchronization (see ¤ 6.14); f) concatenation and separation (see ¤ 6.4); g) retention until acknowledgment of TPDUs (see ¤ 6.13); the variant used, AK or confirmation of receipt, shall be as selected during connection establishment (see Notes); h) frozen references (see ¤ 6.18). Note 1 - The negotiation of the variant of retention until acknowledgment 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. Note 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. Note 3 - The confirmation of receipt variant is restricted to this class and its use depends on the availability of the network layer receipt confirmation service, and the expected cost reduction. 9.2.2 Connection establishment The transport entities shall use the following procedures: a) assignment to network connection (see ¤ 6.1); then b) connection establishment (see ¤ 6.5) and, if appropriate, connection refusal (see ¤ 6.6). 9.2.3 Data transfer 9.2.3.1 General The sending transport entity shall use the following procedures: a) segmenting (see ¤ 6.3); then b) the normal format variant of DT TPDU numbering (see ¤ 6.10). The receiving transport entity shall use the following procedures: c) the normal format variant of DT TPDU numbering (see ¤ 6.10); then d) reassembling (see ¤ 6.3). Note 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. Note 2 - It is possible to decide on a local basis to issue an N-RESET request in order to force the remote entity to carry out the resynchronization (see ¤ 6.14). 9.2.3.2 Expedited data The transport entities shall use either of 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 an 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. Note 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. Note 2 - This numbering enables the receiving transport entity to discard repeated ED TPDUs when resynchronization (see ¤ 6.14) has taken place. Note 3 - No other significance is attached to the ED-TPDU-NR parameter. It is suggested, but not essential, that the values used be consecutive modulo 128. 9.2.4 Release The transport entities shall use the explicit variant of the release procedure (see ¤ 6.7). 10 Specification for Class 2: multiplexing class 10.1 Functions of Class 2 Class 2 provides transport connections with or without individual flow control; no error detection or error recovery is provided. If the network connection resets or disconnects, the transport connection is terminated without the transport release procedure and the TS-user is informed. When explicit flow control is used, a credit mechanism is defined allowing the receiver to inform the sender of the exact amount of data he is willing to receive and expedited data transfer is available. 10.2 Procedures for Class 2 10.2.1 Procedures applicable at all times The transport entities shall use the following procedures: a) association of TPDUs with transport connections (see ¤ 6.9); b) TPDU transfer (see ¤ 6.2); c) treatment of protocol errors (see ¤ 6.22); d) concatenation and separation (see ¤ 6.4); e) error release (see ¤ 6.8). Additionally the transport entities may use the following procedure: f) multiplexing and demultiplexing (see ¤ 6.15). 10.2.2 Connection establishment The transport entities shall use the following procedures: a) assignment to network connection (see ¤ 6.1); then b) connection establishment (see ¤ 6.5) and, if applicable, connection refusal (see ¤ 6.6). 10.2.3 Data transfer when non-use of explicit flow control has been selected If this option has been selected as a result of the connection establishment, the transport entities shall use the segmenting procedure (see ¤ 6.3). The TPDU-NR field of DT TPDUs is not significant and may take any value. Note - Expedited data transfer is not applicable (see ¤ 6.5). 10.2.4 Data transfer when use of explicit flow control has been selected 10.2.4.1 General The sending transport entity shall use the following procedures: a) segmenting (see ¤ 6.3); then b) DT TPDU numbering (see ¤ 6.10); The receiving transport entity shall use the following procedures: c) DT TPDU numbering (see ¤ 6.10); if a DT TPDU is received which is out of sequence it shall be treated as a protocol error; then d) reassembling (see ¤ 6.3). The variant of the DT TPDU numbering which is used by both transport entities shall be that which was agreed at connection establishment. 10.2.4.2 Flow control The transport entities shall send an initial credit (which may be zero) in the CDT field of the CR or CC TPDU. This credit represents the initial value of the upper window 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 parameter 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 parameters 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 parameter 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). Note 1 - This means that credit reduction is not applicable. Note 2 - This means that a transport entity is required to stop sending if the TPDU-NR parameter 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. Note 3 - The rate at which a transport entity progresses the upper window edge allocated to its peer entity constrains the throughput attainable on the transport connection. 10.2.4.3 Expedited data The transport entities shall follow the network normal data variant of the expedited data transfer procedure in ¤ 6.11 if its use has been agreed during connection establishment. ED and EA TPDUs are not subject to the flow control procedures in ¤ 10.2.4.2. The ED-TPDU-NR and YR-EDTU-NR parameters of ED and EA TPDUs respectively are not significant and may take any value. 10.2.5 Release 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 11.1 Functions of Class 3 This class provides the functionality of Class 2 (with use of explicit flow control) plus the ability to recover after a failure signalled by the Network Layer without involving the TS-user. The mechanisms used to achieve this functionality also allow the implementation of more flexible flow control. 11.2 Procedures for Class 3 11.2.1 Procedures applicable at all times The transport entities shall use the following procedures: a) association of TPDUs with transport connections (see ¤ 6.9); b) TPDU transfer (see ¤ 6.2) and retention until acknowledgment of TPDUs (AK variant only) (see ¤ 6.13); c) treatment of protocol errors (see ¤ 6.22); d) concatenation and separation (see ¤ 6.4); e) reassignment after failure (see ¤ 6.12), together with resynchronization (see ¤ 6.14); f) frozen references (see ¤ 6.18). Additionally, the transport entities may use the following procedure: g) multiplexing and demultiplexing (see ¤ 6.15). 11.2.2 Connection establishment The transport entity shall use the following procedures: a) assignment to network connections (see ¤ 6.1); then b) connection establishment (see ¤ 6.5) and, if appropriate, connection refusal (see ¤ 6.6). 11.2.3 Data transfer 11.2.3.1 General The sending transport entity shall use the following procedures: a) segmenting (see ¤ 6.3); then b) DT TPDU numbering (see ¤ 6.10); after receipt of an RJ TPDU (see ¤ 11.2.3.2) the next DT TPDU to be sent may have a value which is not the previous value of TPDU-NR plus one. The receiving transport entity shall use the following procedures: c) DT TPDU numbering (see ¤ 6.10); the TPDU-NR parameter of each received DT TPDU shall be treated as a protocol error if it exceeds the greatest such value received in a previous DT TPDU by more than one (see Note); then d) reassembling (see ¤ 6.3); duplicated TPDUs shall be eliminated before reassembling is performed. Note - The use of RJ TPDUs (see ¤ 11.2.3.2) can lead to retransmission and reduction of credit. Thus the receipt of a DT TPDU which is a duplicate, or which is greater than or equal to the upper window edge allocated to the peer entity, is possible and is therefore not treated as a protocol error. 11.2.3.2 Use of RJ TPDU A transport entity may send an RJ TPDU at any time in order to invite retransmission or to reduce the upper window edge allocated to the peer entity (see Note 1). When an RJ TPDU is sent, the following constraints shall be respected: a) the YR-TU-NR parameter shall be at most one greater than the greatest such value received in a previous DT TPDU, or shall be zero if no DT TPDU has yet been received (see Note 2); b) if an AK or RJ TPDU has previously been sent, the YR-TU-NR parameter shall not be lower than that in the previously sent AK or RJ TPDU. When a transport entity receives an RJ TPDU (see Note 3): c) the next DT TPDU to be transmitted, or retransmitted, shall be that for which the value of the TPDU-NR parameter is equal to the value of the YR-TU-NR parameter of the RJ TPDU; d) the sum of the values of the YR-TU-NR and CDT parameters of the RJ TPDU becomes the new upper window edge (see Note 4). Note 1 - An RJ TPDU can also be sent as part of the resynchronization (see ¤ 6.14) and reassignment after failure (see ¤ 6.12) procedures. Note 2 - It is suggested that the YR-TU-NR parameter be equal to the TPDU-NR parameter of the next expected DT TPDU. Note 3 - These rules are a subset of those specified for when an RJ TPDU is received during resynchronization (see ¤ 6.14) and reassignment after failure (see ¤ 6.12). Note 4 - This means that RJ TPDU can be used to reduce the upper window edge allocated to the peer entity (credit reduction). 11.2.3.3 Flow control The procedures shall be as defined in ¤ 10.2.4.2, except that: a) a credit reduction may lead to the reception of a DT TPDU with a TPDU-NR parameter whose value is not but would have been less than the upper window edge allocated to the remote entity prior to the credit reduction. This shall not be treated as a protocol error; b) receipt of an AK TPDU which sets the lower window edge more than one greater than the TPDU-NR of the last transmitted DT TPDU shall not be treated as a protocol error, provided that all acknowledged DT TPDUs have been previously transmitted (see Notes 1 and 2). Note 1 - This can only occur during retransmission following receipt of an RJ TPDU. Note 2 - The transport entity may either continue retransmission as before or retransmit only those DT TPDUs not acknowledged by the AK TPDU. In either case, copies of the acknowledged DT TPDUs need not be retained further. 11.2.3.4 Expedited data The transport entities shall follow the network normal data variant of expedited data transfer procedure in ¤ 6.11 if its use has been agreed during connection establishment. The sending transport entity shall not allocate the same ED- TPDU-NR to successive ED TPDUs. The receiving transport entity shall transmit an EA TPDU with the same value in its YR-EDTU-NR-parameter. If, and only if, this number is different from that of the previously received ED TPDU, shall it generate a T-EXPEDITED DATA indication to convey the data to the TS-user (see Note 2). Note 1 - No other significance is attached to the ED-TPDU-NR parameter. It is suggested, but not essential, that the values be consecutive modulo 2n, where n is the number of bits of the parameter. Note 2 - This procedure ensures that the TS-user does not receive data corresponding to the same ED TPDU more than once. 11.2.4 Release The transport entities shall use the explicit variant of the release procedure (see ¤ 6.7). 12 Specification for Class 4: error detection and recovery class 12.1 Functions of Class 4 Class 4 provides the functionality of Class 3, plus the ability to detect and recover from lost, duplicated or out of sequence TPDUs without involving the TS-user. Class 4 detects signalled and unsignalled network failures (i.e. resets or disconnects or inactivity) and recovers from these failures by using timeout mechanisms. This detection of errors is made by extended user of the sequence numbering of Classes 2 and 3, by timeout mechanisms, and by additional procedures. This class additionally detects and recovers from damaged TPDUs by using a checksum mechanism. The use of the checksum mechanism must be available but its use or its non-use is subject to negotiation. Furthermore, this class provides additional resilience against network failure and increased throughput capability by allowing a transport connection to make use of multiple network connections. 12.2 Procedures for Class 4 12.2.1 Procedures available at all times 12.2.1.1 Timers used at all times This sub-clause defines timers that apply at all times in Class 4. These timers are listed in Table 7/X.224. TABLE 7/X.224 Timer parameters related to the operation of Class 4 Symbol Name Definition MLR NSDU lifetime A time bound for the maximum time which local-to-remote may elapse between the transmission of an NSDU by a local transport entity and the receipt of any copy of it by a remote peer entity. MRL NSDU lifetime A time bound for the maximum time which remote-to-local may elapse between the transmission of an NSDU by a remote transport entity and the receipt of any copy of it by a local peer entity. ELR Expected A time bound for the maximum delay maximum transit suffered by all but a small proportion delay local-to- of NSDUs transferred from the local remote transport entity to a remote peer entity. ELR Expected A time bound for the maximum delay maximum transit suffered by all but a small proportion delay remote-to- of NSDUs transferred from a remote local transport entity to the local peer entity. AL Local A time bound for the maximum time which acknowledge can elapse between the receipt of a TPDU time by the local transport entity from the network layer and the transmission of the corresponding acknowledgement. AR Remote As AL, but for the remote entity. acknowledge time T1 Local A time bound for the maximum time the retransmission local transport entity will wait for time acknowledgement before retransmitting a TPDU. R Persistence A time bound for the maximum time that time the local transport entity will continue to transmit a TPDU that requires acknowledgement. N Maximum number A bound for the number of times which of the local transport entity will continue transmissions to transmit a TPDU that requires acknowledgement L Time bound on A time bound for the maximum time references and between the transmission of a TPDU and sequence the receipt of any acknowledgement numbers relating to it. I Inactivity time A time bound for the time after which a transport entity will, if it does not receive a TPDU, initiate the release procedure to terminate the transport connection. Note - This parameter is required for protection against unsignalled failures. W Window time A time bound for the maximum time a transport entity will wait before retransmitting up-to-date window information. This Recommendation does not define specific values for the timers, and the derivations described in this subclause are not mandatory. The values should be chosen so that the required quality of service can be provided, given the known characteristics of the network. Timers that apply only to specific procedures are defined under the appropriate procedure. 12.2.1.1.1 NSDU lifetimes (MLR , MRL) The network layer is assumed to provide, as an aspect of its quality of service, for a bound on the maximum lifetime of NSDUs in the network. This value may be different in each direction of transfer through a network between two transport entities. The values, for both directions of transfer, are assumed to be known by the transport entities. The maximum NSDU lifetime local-to-remote (MLR) is the maximum time which may elapse between the transmission of an NSDU from the local transport entity to the network layer and the receipt of any copy of the NSDU from the network layer at the remote transport entity. The maximum NSDU lifetime remote-to-local (MRL) is the maximum time which may elapse between the transmission of an NSDU from the remote transport entity to the network layer and receipt of any copy of the NDSU from the network layer at the local transport entity. 12.2.1.1.2 Expected maximum transit delay (ELR ,ERL) The network layer is assumed to provide, as an aspect of its quality of service, an expected maximum transit delay for NSDUs in the network. This value may be different in each direction of transfer through a network between two transport entities. The values, for both directions of transfer, are assumed to be known by the transport entities. The expected maximum transit delay local-to-remote (ERL) is the maximum delay suffered by all but a small proportion of NSDUs transferred through the network from the local transport entity to the remote transport entity. The expected maximum transit delay remote-to-local (ERL) is the maximum delay suffered by all but a small proportion of NSDUs transferred through the network from the remote transport entity to the local transport entity. 12.2.1.1.3 Acknowledge time (AR , AL) Any transport entity is assumed to provide a bound for the maximum time which can elapse between its receipt of a TPDU from the Network Layer and its transmission of the corresponding response. This value is referred to as AL. The corresponding time given by the remote transport entity is referred to as AR. 12.2.1.1.4 Local retransmission time (T1) The local transport entity is assumed to maintain a bound on the time it will wait for an acknowledgment before retransmitting the TPDU. Its value is given by: T1 = ELR + ERL + AR + X where: ELR = expected maximum transit delay local-to-remote, ERL = expected maximum transit delay remote-to-local, AR = remote acknowledge time, and X = local processing time for a TPDU. Note - During connection establishment the value of AR is not known. In this case a suitable bound for T1 may be established either by estimating (or having Òa prioriÓ knowledge of) AR or by applying a suitable algorithm to the TC establishment delay QOS parameter. 12.2.1.1.5 Persistence time (R) The local transport entity is assumed to provide a bound for the maximum time for which it may continue to retransmit a TPDU requiring positive acknowledgement and which is not outside the current transmit window, even after credit reduction. This value is referred to as R. This value is clearly related to the time elapsed between retransmission, T1, and the maximum number of retransmissions, N. It is not less than T1 x (N - 1) + x, where x is a small quantity to allow for additional internal delays, the granularity of the mechanism used to implement T1 and so on. Because R is a bound, the exact value of x is unimportant as long as it is bounded and the value of a bound is known. 12.2.1.1.6 Time bound on references and sequence numbers (L) A time bound for the maximum time between the decision to transmit a TPDU and the receipt of any acknowledgement relating to it (L) is given by: L = MLR + MRL + R + AR where: MLR = NSDU lifetime local-to-remote, MRL = NSDU lifetime remote-to-local, AR = remote acknowledge time, and R = persistence time. It is necessary to wait for a period L before re-using any reference or sequence number, to avoid confusion in case a TPDU referring to it may be duplicated or delayed. Note 1 - In practice, the value of L may be unacceptably large. It may also be only a statistical figure at a certain confidence level. A smaller value may therefore be used where this still allows the required quality of service to be provided. Note 2 - The relationships between the times discussed above are illustrated in Figures 3 and 4/X.224. FIGURE 3/X.224 - T0706640-88 FIGURE 4/X.224 - T0706650-88 12.2.1.2 General procedures The transport entity shall use the following procedures: a) TPDU transfer (see ¤ 6.2); b) association of TPDUs with transport connections (see ¤ 6.9); c) treatment of protocol errors (see ¤ 6.22); d) checksum (see ¤ 6.17); e) splitting and recombining (see ¤ 6.23); f) multiplexing and demultiplexing (see ¤ 6.15); g) retention until acknowledgement of TPDUs (see ¤ 6.13); h) frozen reference (see ¤ 6.18); i) retransmission procedures; when a transport entity has some outstanding TPDUs that require acknowledgement, it will check that no T1 interval elapses without the arrival of a TPDU that acknowledges at least one of the outstanding TPDUs. If the timer expires, except if the TPDU to be retransmitted is a DT TPDU and it is outside the transmit window due to credit reduction, the first TPDU is retransmitted and the timer is restarted. After N transmissions (i.e. N-1 retransmissions), it is assumed that useful two-way communication is no longer possible and the release procedure is used, and the TS-user is informed. Note 1 - This procedure may be implemented by different means. For example: a) one interval is associated with each TPDU. If the timer expires, the associated TPDU will be retransmitted, and the timer T1 will be restarted for all subsequent DT TPDUs; or b) one interval is associated with each transport connection: 1) if the transport entity transmits a TPDU requiring acknowledgement, it starts timer T1; 2) if the transport entity receives a TPDU that acknowledges one of the TPDUs to be acknowledged, it restarts timer T1 unless the received TPDU is an AK TPDU which explicitly closes the transmit window; 3) if the transport entity receives a TPDU that acknowledges the last TPDU to be acknowledged, it stops timer T1. For a decision whether the retransmission timer T1 is maintained on a per TPDU or on a per transport connection basis, throughput considerations have to be taken into account. Note 2 - For DT TPDUs, it is a local choice to retransmit either only the first DT TPDU or all TPDUs waiting for an acknowledgement up to the upper window edge. Note 3 - It is suggested that after N transmissions of a DT TPDU, the transport entity waits T1 + W + MRL to provide a higher possibility of receiving an acknowledgement before entering the release phase. For other TPDU types which may be retransmitted, it is suggested that after N transmissions, the transport entity waits T1 + MRL to provide a higher possibility of receiving the expected reply. 12.2.2 Procedures for connection establishment 12.2.2.1 Timers used in connection establishment There are no timers specific to connection establishment. 12.2.2.2 General procedures The transport entities shall use the following procedures: a) when a network connection to which the transport connection is assigned is released (N DISind received): 1) if a CC TPDU is awaited the initiator shall perform a new assignment according to QOS and retransmission procedure (i.e., no more than N x T1 keeping sending CR TPDU); 2) if there is at least one other network connection to which the tranport connection is assigned both initiator and acceptor may either perform a new assignment or continue operation using one of the remaining network connections; 3) if the transport connection becomes unassigned the acceptor may either perform new assignment or wait (there is no risk of deadlock since either T1 or I is running), the initiator shall perform a new assignment (except in the closing state); b) connection establishment (see ¤ 6.5) and, if appropriate, connection refusal (see ¤ 6.6) together with the additional procedures: 1) a connection is not considered established until the successful completion of a 3-way TPDU exchange. The sender of a CR TPDU must respond to the corresponding CC TPDU by immediately sending a DT, ED, DR or AK TPDU; 2) as a result of duplication or retransmission, a CR TPDU may be received specifying a source referene which is already in use with the sending transport entity. If the receiving transport entity is in the data transfer phase, having completed the 3-way TPDU exchange procedure, or is waiting for the T-CONNECT response from the TS-user, the receiving transport entity shall discard such a TPDU. Otherwise, a CC TPDU shall be transmitted; 3) as a result of duplication or retransmission, a CC TPDU may be received specifying a paired reference which is already in use. The receiving transport entity shall only acknowledge the duplicate CC TPDU according to the procedure in ¤ 12.2.2.2, b) 1); 4) a CC TPDU may be received specifying a reference which is in the frozen state. The response to such a TPDU shall be a DR TPDU; 5) the retransmission procedures (see ¤ 12.2.1.2) are used for both the CR TPDU and CC TPDU. Note - After receiving a CR TPDU, it is recomended that the transport entity enforce a time limit upon the Transport Service user so that its late acceptance of the transport connection will not cause a delayed CC TPDU to be sent. 12.2.3 Procedures for data transfer 12.2.3.1 Timers used in data transfer The data transfer procedures use two additional timers. 12.2.3.1.1 Inactivity time (I) To protect against unsignalled breaks in the network connection, or failure of the peer transport entity, (half-open connections), each transport entity maintains an inactivity time interval. Note - A suitable value for I is given by 2 x [N x maximum of (T1, W)] unless local needs indicate another more appropriate value. 12.2.3.1.2 Window time (W) A transport entity maintains a timer interval to ensure that there is a bound on the maximum interval between window updates. 12.2.3.2 General procedures for data transfer The transport entities shall use the following procedures: a) inactivity control (see ¤ 6.21); b) expedited data (see ¤ 6.11); c) explicit flow control (see ¤ 6.16). The sending transport entity shall use the following procedures in the following order: d) segmenting (see ¤ 6.3); e) DT TPDU numbering (see ¤ 6.10). The receiving transport entity shall use the following procedures in the following order: f) DT TPDU numbering (see ¤ 6.10); g) resequencing (see ¤ 6.20); h) reassembling (see ¤ 6.3). 12.2.3.3 Inactivity control If the interval of the inactivity timer I expires without receipt of some TPDU, the transport entity shall initiate the release procedures. To prevent expiration of the remote transport entity's inactivity timer when no data is being sent, the local transport entity must send AK TPDUs at suitable intervals in the absence of data, having regard to the probability of TPDU loss. The window synchronization procedures (see ¤ 12.2.3.8) ensure that this requirement is met. Note - It is likely that the release procedures initiated due to inactivity timer expiration will fail, as such expiration indicates probable failure of the supporting network connection or of the remote transport entity. 12.2.3.4 Expedited data The transport entities shall follow the network normal data variant of the expedited data transfer procedures (see ¤ 6.11), if the use of transport expedited data transfer service option has been agreed during connection establishment. The ED TPDU shall have a TPDU-NR which is allocated from a separate sequence space from that of the DT TPDUs. A transport entity shall allocate the sequence number zero to the ET-TPDU-NR of the first ED TPDU which it transmits for a transport connection. For subsequent ED TPDUs sent on the same transport connection, the transport entity shall allocate a sequence number one greater than the previous one. Modulo 27 arithmetic shall be used when normal formats have been selected and modulo 231 arithmetic shall be used when extended formats have been selected. The receiving transport entity shall transmit an EA TPDU with the same sequence number in its YR-EDTU-NR parameter. If this number is one greater than in the previously received in-sequence ED TPDU, the receiving transport entity shall transfer the data in the ED TPDU to the TS-user. If a transport entity does not receive an EA TPDU in acknowledgement to an ET TPDU, it shall follow the retransmission procedures (see Note and ¤ 12.2.1.2). The sender of an ED-TPDU shall not send any new DT TPDUs created from a T-DATA request subsequent to the T-EXPEDITED DATA request, until it receives the EA TPDU. Note - This procedure ensures that ED TPDUs are delivered to the TS-user in sequence and that the TS-user does not receive data corresponding to the same ED TPDU more than once. Also, it guarantees the arrival of the ED TPDU before any data subsequently sent by the TS-user. 12.2.3.5 Resequencing The receiving transport entity shall deliver all DT TPDUs to the TS-user in the order specified by the TPDU-NR parameter. DT TPDUs received out of sequence but within the transmit window shall not be delivered to the TS-user until in-sequence TPDUs have also been received. DT TPDUs received out-of-sequence and outside the transmit window shall be discarded, but may result in transmission of an AK TPDU with up-to-date window information (see ¤ 12.2.3.8). Duplicate TPDUs can be detected because the sequence number matches that of previously received TPDUs. Sequence numbers shall not be reused for the period L after their previous use. Otherwise, a new, valid TPDU could be confused with a duplicated TPDU which had previously been received and acknowledged. Duplicated DT TPDUs shall be acknowledged, since the duplicated TPDU may be the result of a retransmmission resulting from the loss of an AK TPDU. The data contained in a duplicated DT TPDU shall be discarded. 12.2.3.6 Explicit flow control The transport entities shall send an initial credit (which may take the value 0) in the CDT parameter of the CR TPDU or CC TPDU. This credit represents the initial value of the upper window edge of the peer entity. The transport entity which receives the CR TPDU or CC TPDU shall consider its lower window edge as zero and its upper window edge as the value in the CDT parameter in the received TPDU. In order to authorize the transmission of DT TPDUs by its peer, a transport entity may transmit an AK TPDU at any time. The sequence number of an AK TPDU shall not exceed the sequence number of the next expected DT TPDU, i.e., shall not be greater than the highest sequence number of a received DT TPDU, plus one. A transport entity may send a duplicate AK TPDU containing the same sequence number, CDT, and subsequence number field at any time. A transport entity may increase or decrease the upper window edge at any time. A transport entity which receives an AK TPDU shall consider the value of the YR-TU-NR parameter as its new lower window edge if it is greater than any previously received in a YR-TU-NR parameter, and the sum of YR-TU-NR and CDT as its new upper window edge subject to the procedures for sequencing AK TPDUs (see ¤ 12.2.3.8). A transport entity shall not transmit or retransmit a DT TPDU with a sequence number outside the transmit window. 12.2.3.7 Sequencing of received AK TPDUs To allow a receiving transport entity to properly sequence a series of AK TPDUs that all contain the same sequence number and thereby use the correct CDT value, AK TPDUs may contain a sub- sequence parameter. For the purpose of determining the correct sequence of AK TPDUs, the absence of the sub-sequence parameter shall be equivalent to the value of the parameter set to zero. An AK TPDU is defined to be in sequence if: a) the sequence number is greater than in any previously received AK TPDU, or b) the sequence number is equal to the highest in any previously received AK TPDU, and the sub-sequence parameter is greater than in any previously received AK TPDU having the same value of YR-TU-NR field, or c) the sequence number and sub-sequence parameter are both equal to the highest in any previously received AK TPDU, and the CDT parameter is greater than or equal to that in any previously received AK TPDU having the same YR-TU-NR parameter. When the receiving transport entity recognizes an out of sequence AK TPDU, it shall discard it. 12.2.3.8 Procedures for transmission of AK TPDUs 12.2.3.8.1 Transmission of AK TPDUs An in-sequence DT TPDU shall be acknowledged within time AL, by the transmission of AK TPDU whose ÒYR-TU-NRÓ field is set to at least the sequence number of the received DT TPDU plus one. An AK TPDU shall be transmitted containing up-to-date window information if: a) a DT TPDU is received whose sequence number is lower than the lower window edge, but greater than or equal to the lower window edge minus the maximum credit value ever given for this transport connection, or b) a DT TPDU is received whose sequence number is above the current upper window but following credit reduction is within the upper window edge which has been granted and then withdrawn. Note 1 - A simpler implementation may send an AK TPDU upon receipt of any DT TPDU outside the transmit window. Note 2 - The procedure a) is required so that loss of an AK TPDU is correctly recovered, i.e., when the sender of the DT TPDU retransmits it following nonreceipt of an acknowledgement. Note 3 - The procedure b) is required due to the possibility of loss of the AK TPDU indicating the upper window edge reduction, which could otherwise cause incorrect termination of the transport connection. A transport entity shall not allow an interval W to pass without the transmission of an AK TPDU. If the transport entity is not using the procedure following setting CDT to zero (see ¤ 12.2.3.8.3) or reduction of the upper window edge (see ¤ 12.2.3.8.4), and does not have to acknowledge receipt of any DT TPDU, then it shall achieve this by retransmission of the most recent AK TPDU, with up-to-date window information. Note - The use of the procedures defined in ¤¤ 12.2.3.8.3 and 12.2.3.8.4 are optional for any transport entity. The protocol operates correctly either with or without these procedures which are defined to enhance the efficiency of its operation. 12.2.3.8.2 Sequence control for transmission of AK TPDUs To allow the receiving transport entity to process AK TPDUs in the correct sequence, as described in ¤ 12.2.3.7, the sub-sequence parameter shall be included following reduction of CDT. If the value of the sub-sequence number to be transmitted is zero, then the parameter should be omitted. The value of the sub-sequence parameter, if used, shall be zero (either explicitly or by absence of the parameter) if the sequence number is greater than the parameter in previous AK TPDUs sent by the transport entity. If the sequence number is the same as the previous AK TPDU sent and the CDT parameter is equal to or greater than the CDT parameter in the previous AK TPDU sent, then the sub-sequence parameter, if used, shall be equal to that in the previously sent AK TPDU. If the sequence number is the same as the previous AK TPDU sent and the CDT parameter is less than the value of the CDT parameter in the previous AK TPDU sent, then the sub-sequence parameter, if used, shall be one greater than the value in the previous AK TPDU. Note - If a transport entity never reduces credit then it does not need to use the sub-sequence parameter. 12.2.3.8.3 Retransmission of AK TPDUs after CDT set to zero Due to the possibility of loss of AK TPDUs, the upper window edge as perceived by the transport entity transmitting an AK TPDU may differ from that perceived by the intended recipient. To avoid the possibility of extra delay, the retransmission procedure (see ¤ 12.2.1.2) should be followed for an AK TPDU, if it opens the transmit window which has previously been closed by sending an AK TPDU with CDT field set to zero. The retransmission procedure, if used, terminates and the procedure in ¤ 12.2.3.8.1 is used when: a) AK TPDU is received containing the flow control confirmation parameter, whose lower window edge and sub-sequence fields are equal to the sequence number and sub-sequence number in the retained AK TPDU and whose credit field is not zero; b) an AK TPDU is transmitted with a sequence number higher than that in the retained AK TPDU, due to reception of a DT TPDU whose sequence number is equal to the lower window edge; c) N transmissions of the retained AK TPDU have taken place. In this case, the transport entity shall continue to transmit the AK TPDU at an interval of W. An AK TPDU which is subject to the retransmission procedure shall not contain the flow control confirmation parameter. If it is required to transmit this parameter concurrently, an additional AK TPDU shall be transmitted having the same values in the YR-TU-NR, sub-sequence (if applicable) and CDT parameters. 12.2.3.8.4 Retransmission procedures following reduction of the upper window edge This subsection specifies the procedure for retransmission of AK TPDUs after a transport entity has reduced the upper window edge (see ¤ 12.2.3.6) or for an AK TPDU with the credit field set to zero. This procedure is used until the lower window edge exceeds the highest value of the upper window edge ever transmitted (i.e. the value existing at the time of credit reduction, unless a higher value is retained from a previous credit reduction). The retransmission procedure should be followed for any AK TPDU which increases the upper window edge, unless it is known that the remote transport entity has an open window. This is known if: - a flow control confirmation (FCC) parameter has been received, corresponding to an AK TPDU transmitted following the most recent credit reduction, and - this FCC parameter conveys an upper window edge value (i.e., the sum of the lower window edge and credit fields) which is greater than the lower window edge of the transmitted AK TPDU. This retransmission procedure for any particular AK TPDU shall terminate when: a) an AK TPDU is received containing the flow control confirmation parameter, whose lower window edge and sub-sequence fields are equal to the lower window edge (YR-TU-NR) and sub- sequence number in the retained AK TPDU; or b) N transmission of the retained AK TPDU have taken place. In this case, the transport entity shall continue to transmit the AK TPDU as an interval of W. An AK TPDU which is subject to the retransmission procedure shall not contain the flow control confirmation parameter. If it is required to transmit this parameter concurrently, an additional AK TPDU shall be transmitted having the same values in the sequence, sub-sequence (if applicable) and credit fields. Note - Retransmission of AK TPDUs is normally not necessary, except following explicit closing of the window (i.e., transmission of an AK TPDU with CDT parameter set to zero). If data is available to be transmitted, the retransmission procedure for DT TPDUs will ensure that an AK TPDU is received granting further credit where this is available. Following credit reduction, this may no longer be so, because retransmission may be inhibited by the credit reduction. The rules described in this clause avoid extra delay. The rules for determining whether to apply the retransmission procedure to an AK TPDU may be expressed alternatively as follows: LWE = lower window edge UWE = upper window edge KUWE = lower bound on upper window edge held by remote transport entity. The retransmission procedure is used whenever: (UWE > LWE) and (KUWE = LWE) i.e. when the window is opened and it is not known definitely that the remote transport entity is aware of this. KUWE is maintained as follows. When credit is reduced, KUWE is set to LWE. Subsequently, it is increased only upon receipt of a valid flow control confirmation (i.e. one which matches the retained lower window edge and sub-sequence). In the case, KUWE is set to the implied upper window edge of the flow control confirmation, i.e. the sum of its lower window edge and credit fields. By this means, it can be ensured that KUWE is always less than or equal to the actual upper window edge in use by the transmitter of DT TPDUs. 12.2.3.9 Use of flow control confirmation parameter At any time, an AK TPDU may be transmitted containing a flow control confirmation parameter. The lower window edge, the sub- sequence and the credit fields shall be set to the same values as the corresponding parameters in the most recently received in- sequence AK TPDU. An AK TPDU containing a flow control confirmation parameter should be transmitted whenever: a) a duplicate AK TPDU is received, with the value of YR-TU- NR, CDT, and sub-sequence fields equal to the most recently received AK TPDU, but not itself containing the flow control confirmation parameter; b) an AK TPDU is received which increases the upper window edge but not the lower window edge, and the upper window edge was formerly equal to the lower edge; or c) an AK TPDU is received which increases the upper window edge but not the lower window edge, and the lower window edge is lower than the highest value of the upper window edge ever received and subsequently reduced (i.e. following credit reduction). 12.2.4 Procedures for release 12.2.4.1 Timers used for release There are no timers used only for release. 12.2.4.2 General procedures for release The transport entity shall use the explicit variant of normal release (see ¤ 6.7). 13 Structure and encoding of TPDUs 13.1 Validity Table 8/X.224 specifies those TPDUs which are valid for each class and the code for each TPDU. 13.2 Structure All the transport protocol data units (TPDUs) shall contain an integral number of octets. The octets in a TPDU are numbered starting from 1 and increasing in the order they are put into an NSDU. The bits in an octet are numbered from 1 to 8, where bit 1 is the low-order bit. When consecutive octets are used to represent a binary number or a binary coded decimal number (one digit per octet), the lower octet number has the most significant value. Note 1 - The numbering of bits within an octet is a convention local to this Recommendation. Note 2 - The use of the terms Òhigh orderÓ and Òlow orderÓ is common to this Recommendation and to adjacent layer Recommendations. Note 3 - The use of the above conventions does not affect the order of the bit transmission on a serial communications link. Note 4 - As described in ¤ 6.2.3, both transport entities respect these bit and octet ordering conventions, thus allowing communication to take place. TABLE 8/X.224 TPDU codes Validity within classes See Code 0 1 2 3 4 CR: Connection x x x x x ¤ 13.3 1110 Request xxxx CC: Connection x x x x x ¤ 13.4 1101 Confirm xxxx DR: Disconnect x x x x x ¤ 13.5 1000 Request 0000 DC: Disconnect x x x x ¤ 13.6 1100 Confirm 0000 DT: Data x x x x x ¤ 13.7 1111 0000 ED: Expedited Data x NF x x ¤ 13.8 0001 0000 AK: Data NRC NF x x ¤ 13.9 0110 Acknowledgement zzzz EA: Expedited x NF x x ¤ 0010 Data 13.10 0000 Acknowledgement RJ: Reject x x ¤ 0101 13.11 zzzz ER: TPDU Error x x x x x ¤ 0111 13.12 0000 PI: Transport Annex 0000 Protocol Id. B 0001 Not available (see - 0000 Note) 0000 - 0011 0000 - 1001 xxxx - 1010 xxxx xxxx (bits 4 to 1): used to signal the CDT in classes 2,3,4; set to 0000 in classes 0 and 1. zzzz (bits 4 to 1): used to signal the CDT in classes 2,3,4; set to 1111 in class 1. NF: not available when the non explicit flow control option is selected. NRC: not available when the receipt confirmation option is selected. Note - These codes are already in use in related protocols defined by standards organisations other than CCITT/ISO. Note 5 - When the encoding of a TPDU is represented using a diagram in this clause, the following representation is used: a) octets are shown with the lowest numbered octet to the left; higher numbered octets being further to the right; b) within an octet, bits are shown with bit 8 to the left and bit 1 to the right. TPDUs shall contain, in the following order: a) the header, comprising: 1) the length indicator (LI) field, 2) the fixed part, 3) the variable part, if present; b) the data field, if present. This strucutre is illustrated as follows: Oct 1 2 3 4 n n + 1 p p + 1 et LI Fixed part Variabl Data e part field _Â___________________¨_ Header 13.2.1 Length indicator field This field is contained in the first octet of the TPDUs. The length is indicated by a binary number, with a maximum value of 254, (1111 1110). The length indicated shall be the header length in octets including parameters, but excluding the length indicator field and user data, if any. The value 255 (1111 1111) is reserved for possible extensions. If the length indicated exceeds, or is equal to, the size of the NS user data which is present, this is a protocol error. 13.2.2 Fixed part 13.2.2.1 General The fixed part contains frequently occurring parameters including the code of the TPDU. The length and the structure of the fixed part are defined by the TPDU code and in certain cases by the protocol class and the formats in use (normal or extended). If any of the parameters of the fixed part have an invalid value, or if the fixed part cannot be contained within the header (as defined by LI), this is a protocol error. Note - In general the TPDU code defines unambiguously the fixed part. However, different variants may exist for the same TPDU code (see normal and extended formats). 13.2.2.2 TPDU code This field contains the TPDU code and is contained in octet 2 of the header. It is used to define the structure of the remaining header. This field is a full octet except in the following cases: 1110 xxxx Connection request 1101 xxxx Connection confirm 0101 xxxx Reject 0110 xxxx Data acknowledgement where xxxx (bits 4-1) is used to signal the CDT. Only those codes defined in ¤ 13.1 are valid. 13.2.3 Variable part The variable part is used to define less frequently used parameters. If the variable part is present, it shall contain one or more parameters. Note - The number of parameters that may be contained in the variable part is indicated by the length of the variable part which is LI minus the length of the fixed part. Each parameter contained within the variable part is structured as follows: 87 6 5 4 3 2 1 Bits Octets n + 1 Parameter code n + 2 Parameter Length Indication (e.g.m) n + 3 Parameter Value n + 2 + m - The parameter code field is coded in binary. Note - Without extensions, it provides a maximum number of 255 different parameters. However, as noted below, bits 8 and 7 cannot take every possible value, so the practical maximum number of different parameters is less. Parameter code 1111 1111 is reserved for possible extensions of the parameter code. - The parameter length indication indicates the length, in octets, of the parameter value field. Note - The length is indicated by a binary number, m , with a theoretical maximum value of 255. The practical maximum value of m is lower. In the case of a single parameter contained within the variable part, two octets are required for the parameter code and the parameter length indication itself. Thus, the value of m is limited to 248. For larger fixed parts of the header and for each succeeding parameter, the maximum value of m decreases. - The parameter value field contains the value of the parameter identified in the parameter code field. - No parameter codes use bits 8 and 7 with the value 00. - The parameters defined in the variable part may be in any order. If any parameter is duplicated, then the later value shall be used. A parameter not defined in this Recommendation shall be treated as a protocol error in any received TPDU except a CR TPDU. In a CR TPDU, it shall be ignored. If the responding transport entity selects a class for which a parameter of the CR TPDU is not defined, it may ignore this parameter, except the class and option and alternative protocol class parameters which shall always be interpreted. A parameter defined in this Recommendation, but having an invalid value, shall be treated as a protocol error in any received TPDU except a CR TPDU. In a CR TPDU, it shall be treated as a protocol error if it is the class and option parameter or the alternative class parameter or the additional option selection parameter; otherwise, it shall be either ignored or treated as a protocol error. 13.2.3.1 Checksum parameter (Class 4 only) All TPDU types may contain a 16-bit checksum parameter in their variable part. This parameter shall be present in a CR TPDU and shall be present in all other TPDUs except when the non-use of checksum option is selected. It is encoded as follows: Parameter Code: 1100 0011 Parameter Length: 2 Parameter Value: Result of checksum algorithm. This algorithm is specified in ¤ 6.17. 13.2.4 Data field This field contains transparent user data. Restrictions on its size are noted for each TPDU. 13.3 Connection request (CR) TPDU The length of the CR TPDU shall not exceed 128 octets. 13.3.1 Structure The structure of the CR TPDU is as follows: _______________________________ 1 Recommendation X.224 and ISO 8073 (Information Processing Systems - Open Systems Interconnection - Transport Protocol Specification) were developed in close collaboration and are technically aligned, except for the differences noted in Appendix II.