diff options
Diffstat (limited to 'doc/rfc/rfc892.txt')
| -rw-r--r-- | doc/rfc/rfc892.txt | 4414 |
1 files changed, 4414 insertions, 0 deletions
diff --git a/doc/rfc/rfc892.txt b/doc/rfc/rfc892.txt new file mode 100644 index 0000000..0ff8ceb --- /dev/null +++ b/doc/rfc/rfc892.txt @@ -0,0 +1,4414 @@ +Network Working Group ISO +Request for Comments: 892 December 1983 + + + ISO Transport Protocol Specification + +This document is distributed as an RFC for information only. +It does not specify a standard for the ARPA Internet. + +Note: This document appeared in: + +ISO/TC97/SC16/WG6. Information Processing Systems - Open Systems + Interconnection - Transport Protocol Specification. Computer + Communication Review 12, 3-4 (July/October 1982), pp. 24-67. + +and differs from it only in format. + + +Table of Contents + +0. Introduction +1. Scope and Field of Application +2. References + +Section One - General + +3. Definitions +4. Symbols and Abbreviations +5. Overview + + 5.1 Service provided by the transport layer + 5.2 Service assumed from the network layer + 5.3 Functions of the transport layer + 5.4 Model of the transport layer + +Section Two - Transport Protocol Specification + +6. Protocol Mechanisms + + 6.1 Assignment to network connection + 6.2 Transport protocol data unit (TPDU) transfer + 6.3 Data TPDU length and segmenting + 6.4 Concatenation and separation + 6.5 Connection establishment + 6.6 Connection refusal + 6.7 Release + 6.8 Implicit termination + 6.9 Spurious disconnect + 6.10 Data TPDU numbering + 6.11 Expedited data transfer + 6.12 Reassignment + 6.13 Reassignment after failure + +ISO Transport Protocol Specification Page 2 +International Standards Organization + + + 6.14 Retention until acknowledgement of TPDUs + 6.15 Resynchronization + 6.16 Multiplexing and demultiplexing + 6.17 Explicit flow control + 6.18 Checksum + 6.19 Frozen references + 6.20 Retransmission on timeout + 6.21 Resequencing + 6.22 Inactivity control + 6.23 Treatment of protocol errors + 6.24 Splitting and recombining + +7. Protocol Classes + 7.0 Protocol description of class 0: simple class + 7.1 Protocol description of class 1: basic error recovery class + 7.2 Protocol description of class 2: multiplexing class + 7.3 Protocol description of class 3: error recovery and multiplexing + class + 7.4 Protocol description of class 4: error detection and recovery class + +8. Encoding + + 8.1 Summary + 8.2 Structure + 8.3 Connection Request (CR) + 8.4 Connection Confirm (CC) + 8.5 Disconnect Request (DR) + 8.6 Disconnect Confirm (DC) + 8.7 Data (DT + 8.8 Expedited Data (ED) + 8.9 Data Acknowledgement (AK) + 8.10 Expedited Data Acknowledgement (EA) + 8.11 Reject (RJ) + 8.12 TPDU Error (ERR) + +Section Three - Conformance + +9. Conformance + +0. Introduction + + The Transport Protocol Standard is one of a set of International +Standards produced to facilitate the interconection of computer +systems. The set of standards covers the services and protocols +required to achieve such interconnection. + + The Transport Protocol Standard is positioned with respect to +other related standards by the layers defined in the Reference Model +for Open Systems Interconnection (ISO 7498). It is most closely +related to, and lies within the field of application of the Transport + +ISO Transport Protocol Specification Page 3 +International Standards Organization + + +Service Standard (DP aaaa). It also uses and makes reference to the +Network Service Standard (DP bbbb), whose provisions it assumes in +order to accomplish the transport protocol's aims. The +interrelationship of these standards is depicted in Figure 1. + +-----------------------------------TRANSPORT SERVICE DEFINITION----- + + Transport --Reference to aims--------------- + Protocol + Specification --Reference to assumptions-------- + +------------------------------------NETWORK SERVICE DEFINITION------ + +Figure 1 - Relationship between the transport protocol and adjacent + services + + The standard specifies a common encoding and a number of +classes of transport protocol procedures to be used with different +network qualities of service. + + It is intended that the Transport Protocol should be simple +but general enough to cater for the total range of Network Service +qualities possible, without restricting future extensions. + + The protocol is structured to give rise to classes of protocol +which are designed to minimize possible incompatibilities and +implementation costs. + + The classes are selectable with respect to the Transport and +Network Services in providing the required quality of service for the +interconnection of two session entities (note that each class provides +a different set of functions for enhancement of service qualities). + + This protocol standard is concerned with optimisation of network +tariffs and the following qualities of service: + + a) different throughput rates; + b) different error rates; + c) integrity of data requirements; + d) reliability requirements. + + The aim of this standard is primarily to provide a definition +for implementors. Since the protocol is complex, the document contains +much material which is advisory or descriptive, but mandatory +requirements on implementations are clearly identified. + + It should be noted that, as the number of valid protocol sequences +is very large, it is not possible with current technology to verify that an +implementation will operate the protocol defined in this document +correctly under all circumstances. It is possible by means of testing + +ISO Transport Protocol Specification Page 4 +International Standards Organization + + +to establish confidence that an implementation correctly operates the +protocol in a representative sample of circumstances. It is, however, +intended that this standard can be used in circumstances where two +implementations fail to communicate in order to determine whether one +or both have failed to operate the protocol correctly. + + The variations and options available within this standard are +essential to enable a Transport Service to be provided for a wide +variety of applications over a variety of network qualities. Thus, a +minimally conforming implementation will not be suitable for use in +all possible circumstances. It is important therefore to qualify all +references to this standard with statements of the options provided or +required or with statements of the intended purpose of provision or +use. + +1. Scope and Field of Application + +1.1 This International Standard Specifies: + + a) five classes of procedures + + 1) Class 0. Simple class; + 2) Class 1. Basic error recovery class; + 3) Class 2. Multiplexing class; + 4) Class 3. Error recovery class; + 5) Class 4. Error detection and recovery class, + + for the transfer of data and control information from + one transport entity to a peer transport entity; + + b) the means of negotiating the class of procedures to be + used by the transport entities; + + c) the encoding of the transport protocol data units used for + the transfer of data and control information; + + d) the functional requirements of equipment within a + computer system claiming to implement these procedures. + +1.2 The procedures are defined in terms of: + + a) the interactions between peer transport entities through + the exchange of transport protocol data units; + + b) the interactions between a transport entity and the + transport service user in the same system through the exchange of + transport service primitives; + + c) the interactions between a transport entity and the + network service provider through the exchange of network + +ISO Transport Protocol Specification Page 5 +International Standards Organization + + + service primitives. + +1.3 This International Standard is applicable to equipment which + supports the Transport Layer of the OSI Reference Model and which + wishes to interconnect in an open systems environment. + +2. References + +ISO 7498 Information processing systems - Open systems inter- + connection - Basic Reference Model + +DP aaaa Information processing systems - Open systems inter- + connection - Transport service definition (N1169). + +DP bbbb Information processing systems - Open systems inter- + connection - Connection-oriented network service + definition (N729) + +Section One - General + +3. Definitions + +3.1 Equipment: Hardware or software or a combination of both; it + need not be physically distinct within a computer system. + +3.2 Transport service user: An abstract representation of the + totality of those entities within a single system that make + use of the transport service. + +3.3 Network service provider: An abstract machine which models + the totality of the entities providing the network service, + as viewed by a transport entity. + + Explanatory Notes + + 1. Definitions 3.1 to 3.3 relate to terms used in clause 1. + + 2. This standard makes use of the terms, concepts, and + definition defined in ISO 7498. + +4. Symbols and Abbreviations + +4.1 Data Units + + TPDU Transport protocol data unit + TSDU Transport service data unit + NSDU Network service data unit + +4.2 Types of transport protocol data units + + +ISO Transport Protocol Specification Page 6 +International Standards Organization + + + CR TPDU Connection request TPDU + CC TPDU Connection confirm TPDU + DR TPDU Disconnect request TPDU + DC TPDU Disconnect confirm TPDU + DT TPDU Data TPDU + ED TPDU Expedited data TPDU + AK TPDU Data acknowledge TPDU + EA TPDU Expedited acknowledge TPDU + RJ TPDU Rejected TPDU + ERR TPDU Error TPDU + +4.3 TPDU fields + + LI Length indicator (field) + CDT Credit (field) + TSAP-ID Transport service access point identifier + (field) + DST-REF Destination reference (field) + SCE-REF Source reference (field) + EOT End of TSDU mark + TPDU-NR DT TPDU number (field) + ED-TPDU-NR ED TPDU number (field) + YR-TU-NR Sequence number response (field) + +4.4 Parameters + + T (R) Receive sequence number + T (S) Send sequence number + +4.5 Timer variables + + T1 Elapse time between retransmissions + N The maximum number of retransmissions + L Bound for the maximum time between the + decision to transmit a TPDU and the receipt of + any response relating to it + T-WAIT Maximum time for a reassignment to take place + before TC failure is assumed + I Inactivity timer - Maximum time allowed to + elapse between receipt of TPDUs before TC + failure is assumed + W Window timer - Maximum interval between trans- + mission of up to date window information + +4.6 Other variables + + n The number of bits in the sequence number + field + p The number of bits in the credit field of a + CR, CC or AK TPDU + +ISO Transport Protocol Specification Page 7 +International Standards Organization + + +4.7 Miscellaneous + + TS-user Transport service user + TSAP Transport service access point + NSAP Network service access point + TC Transport connection + NC Network Connection + +5. Overview of the Transport Protocol + +5.1 Service Provided by the Transport Layer + + The services provided by the protocol described in this +document are connection-oriented services. They are defined in +document DP aaaa. The Transport Service primitives provided are +summarized in Figure 1. + +ISO Transport Protocol Specification Page 8 +International Standards Organization + + + Primitive Parameters +------------------------------------------------------------------------ +T-CONNECT Request To Transport Address, From + Indication Transport Address, Expedited + Data Option, Quality of + Service, TS-User data. +------------------------------------------------------------------------ +T-CONNECT Response Responding Address, Quality + Confirmation of Service, Expedited Data + Option, TS-User data. +------------------------------------------------------------------------ +T-DATA Request TS-User data. + Indication +------------------------------------------------------------------------ +T-EXPEDITED Request TS-User data. +DATA Indication +------------------------------------------------------------------------ +T-DISCONNECT Request TS-User data. +------------------------------------------------------------------------ +T-DISCONNECT Indication Disconnect reason, TS-User + data. +------------------------------------------------------------------------ + + Figure 1. Transport Service Primitives + +5.2 Service Assumed from the Network Layer + + The transport protocol described in this document assumes of +the Network Services described in DP bbbb. The Network Service +primitives used are summarized in Figure 2. + +ISO Transport Protocol Specification Page 9 +International Standards Organization + + + Primitive X/Y Parameters X/Y/Z +------------------------------------------------------------------------ +N-CONNECT Request X Called Address, X + Indication X Calling Address, X + Response X NS-User data, Z + Confirmation X QOS. X +------------------------------------------------------------------------ +N-DATA Request X NS-User data, X + Indication X Conf. Request Y +------------------------------------------------------------------------ +N-DATA Request Y +ACKNOWLEDGE Indication +------------------------------------------------------------------------ +N-EXPEDITED Request Y +DATA Indication NS-User data Y +------------------------------------------------------------------------ +N-RESET Request X + Indication X + Response X + Confirmation X +------------------------------------------------------------------------ +N-DISCONNECT Request X NS-User data Z + Indication X +------------------------------------------------------------------------ + + X - The Transport Protocol assumes that this facility is + provided in all networks. + + Y - The Transport Protocol assumes that this facility is + provided in some networks and a mechanism is provided + to optionally use the facility. + + Z - The Transport Protocol does not use this parameter. + + Figure 2. Network Service Primitives + +5.3 Functions of the Transport Layer + +5.3.1 Connection Oriented Functions + +5.3.1.1 Overview of Functions + + The functions in the transport layer are at least those +necessary to bridge the gap between the services available from the +network layer and those to be offered to the transport users. + + The functions in the transport layer are concerned with the +enhancement of quality of service, including all aspects of cost +optimization. They are described below; the descriptions are grouped +into those concerned with the establishment phase, the data transfer + +ISO Transport Protocol Specification Page 10 +International Standards Organization + + +phase, and the release phase. + +5.3.1.1.1 Establishment Phase + + The goal of the establishment phase is to establish a +transport connection, i.e., between two transport users. The +functions of transport layer during this phase must match the +requested class of services with the services provided by the network +layer as follows: + + o Select network service which best matches the requirement + of the TS-user taking into account charges for various + services. + + o Decide whether to multiplex multiple transport connection + onto a single network connection. + + o Establish the optimum TPDU size. + + o Select the functions that will be operational upon entering + the data transfer phase. + + o Map transport addresses onto network addresses. + + o Provide a means to distinguish between two different + transport connections. + + o Transportation of user's data. + +5.3.1.1.2 Data Transfer Phase + + The purpose of the data transfer phase is to permit two-way +simultaneous transport of TSDUs between the session entities connected +by the transport connection. This purpose is achieved by means of +two-way simultaneous communication in the Transport protocol and by +the following functions. Each of these functions is used or not used +in accordance with the result of the selection performed in the +establishment phase. + + o Concatenation and Separation + + A function used to collect several TPDUs into a single + NSDU; the destination transport entity separates the TPDUs. + + o Segmenting and Reassembling + + The splitting of a single data TSDU into multiple TPDUs + which are reassembled into their original format at the + destination. + + +ISO Transport Protocol Specification Page 11 +International Standards Organization + + + o Multiplexing and Demultiplexing + + A function used to share a single network connection + between two or more transport connections. + + o Splitting and Recombing + + A function allowing the simultaneous use of two or more + network connections to support the same transport connec- + tion. + + o Flow Control + + A function used to regulate the flow of TPDUs between two + transport entities on one transport connection. + + o Error Detection + + A function used to detect the loss, corruption, + duplication, misordering or misdelivery of TPDUs. + + o Transport Connection Identification + + A means to uniquely identify a transport connection + between the pair of transport entities supporting the + connection during the lifetime of the transport + connection. + + o Error Recovery + + A function used to recover from detected and signalled + errors. + + o Expedited Data + + A function used to bypass the flow control of normal data + TPDU. Expedited data TPDUs' flow is controlled by + separate flow control. + + o TSDU Delimiting + + A function used to determine the beginning and ending of + a TSDU. + +5.3.1.1.3 Release Phase + + A function to provide a disconnection of the transport + connection, regardless of the current activity. + +5.3.1.2 Classes and Options + +ISO Transport Protocol Specification Page 12 +International Standards Organization + + + A class defines a set of functions. In this protocol five + classes are defined: + + o Class 0: Simple Class + o Class 1: Basic Error Recovery Class + o Class 2: Multiplexing Class + o Class 3: Error Recovery and Multiplexing Class + o Class 4: Error Detection and Recovery Class. + + Note that with the exception of classes 0 and 1, transport + connections of different class may be multiplexed together + onto the same network connection. + +5.3.1.2.2 Options within Classes + + Options define potential functions which may be used within + a class. + +5.3.1.2.3 Negotiation + + Classes and options within classes are negotiated during + the connection establishment phase. + +5.3.1.2.4 Choice of the Class of Protocol + + The choice will be made by the transport entities according + to: + + o the users requirement expressed via T-CONNECT service + primitives. In particular, for the choice of the + class of protocol, the following rules apply: + + - if the TS-User requests either transmission of + user data during the connection phase, or use of + Expedited data transfer, then Class 0 cannot be + selected. + + - if the TS-User requests use of Expedited data + transfer, then Class 2 with the non-explicit + flow control option cannot be selected. + + o the quality of the available Network services; + + o the user required service versus cost ratio + acceptable for the transport user. + + The following is a classification of network services in terms +of quality with respect to error behavior relative to the user +requirements. Its main purpose is to provide a basis for the decision +regarding which class of transport connection should be used on top of + +ISO Transport Protocol Specification Page 13 +International Standards Organization + + +a given network connection. + + Type A: Network connection with acceptable residual error + rate (for example not signalled by 'clear' or 'reset') + and acceptable rate of signalled failures. + + Type B: Network connections with acceptable residual error + rate (for example not signalled by 'clear' or 'reset') + but unacceptable rate of signalled failures. + + Type C: Network connections with residual error rate not + acceptable to the TS-user. + + It is assumed that each transport entity is aware of the +quality of service provided by particular Network connections. + +5.3.1.3 Potential Functions + + The protocol described in this document does not include the +following set of functions which have been identified as potential +transport layer functions: + + o provision for encryption + + o provision for accounting mechanisms + + o provision for status exchanges and monitoring of quality + of service + + o provision for blocking + + o temporary release of network connections + +5.4 Model of the Transport Layer + + TSAP TSAP + + Transport Protocol Transport Protocol + Entity Entity + + + NSAP ------- NSAP ------- + | (NSAP) | (NSAP) + | | | | + | |-------------------------|-------- + | | + ----------------------------------- + + A Transport Protocol entity within the Transport Layer +communicates with a Transport User through a TSAP by means of the + +ISO Transport Protocol Specification Page 14 +International Standards Organization + + +service primitives as defined by the transport service definition DP +aaaa. Service primitives will cause or be the result of Transport +Protocol Data Unit exchanges between the peer Transport Protocol +entities supporting a Transport Connection. These protocol exchanges +are effected using the services of the Network Layer as defined by the +Network Service Definition DP bbbb through one or more NSAPs. + + Transport connection endpoints are identified in end systems +by an internal, implementation dependent, mechanism so that the +Transport User and the Transport Protocol entity can refer to each +Transport connection. + +Section Two - Transport Protocol Specification + +6. Protocol Mechanisms + + Several functions are described as 'inherent' or 'pervasive'. +Inherent functions must be invoked for every transport connection. +Pervasive functions are optional, but if one is invoked for the first +transport connection over a network connection, it must also be invoked +for any and all other transport connections which use that network +connection during its lifetime. + +6.1 Assignment to Network Connection + + Purpose: Assignment of transport connections to network + connections. + + Network Service Primitives: + + N-CONNECT + N-DISCONNECT + + Description: + + This function is inherent. + + Before a transport connection can be created or used, it must +be assigned to one (or more if splitting function is being used) +network connection(s). Both transport entities involved must become +aware of this assignment. A transport connection may be assigned to a +suitable existing network connection; one or more new network +connections may also be created for the purpose. + + An existing network connection, which connects the relevant +transport entities, is unsuitable for assignment of a transport +connection if, for example: + + o the quality of service needed for the transport connection + can not be met by using or enhancing the network + +ISO Transport Protocol Specification Page 15 +International Standards Organization + + + connection. + + o the protocol class preferred or in use for the transport + connection is incompatible with the current usage of the + network connection as regards the use of pervasive + functions (e.g., multiplexing). + + When a new network connection is created, the quality of +service requested is a local matter, though it will normally be +related to the requirements of transport connection(s) expected to be +assigned to it. + + A Network Connection with no transport connections will be +available after initial establishment or because explicit +disconnection of all the transport connections previously assigned to +it has taken place. Either Transport entity may as a local +matter choose to disconnect the Network Connection or assign other +Transport Connections to it. + +6.2 Transport Protocol Data Unit (TPDU) Transfer + + Purpose: To convey transport protocol data unit in user + data fields of network service primitives. + + Network Service Primitives + + N-DATA + N-EXPEDITED DATA + + Description: + + This function is inherent. + + The Transport Protocol Data Units (TPDUs) defined for the +protocol are listed in Figure 3. + + TPDU name Abbreviation + + Connection Request CR + Connection Confirm CC + Disconnect Request DR + Disconnect Confirm DC + Data DT + Expedited Data ED + Data Acknowledge AK + Expedited Acknowledge EA + Reject RJ + TPDU Error ERR + + Figure 3. Transport Protocol Data Units + +ISO Transport Protocol Specification Page 16 +International Standards Organization + + + TPDUs are conveyed using the NS-User data parameters of the +Network Service primitives, primarily with the N-DATA, but also with +N-EXPEDITED primitives. + + Transport entities shall accept all permissible assignments and +may issue any permissible assignments. The permissible assignments of +TPDUs to these primitives are shown in Figure 4. Concatenation of +TPDUs is also permitted (see section 6.4). + +Primitive Applicable TPDUs Note + +N-DATA CR, CC, DR, DT, ED, + AK, EA, RJ, DC, ERR + +N-EXPEDITED ED, EA 1 + +Notes: + +1. This assignment is permissible only when using class 1 and when + the network expedited variant has been agreed. + +Figure 4. Network Service Primitives which can convey TPDUs. + +6.3 Data TPDU Length and Segmenting + + Purpose: Mapping between one TSDU and TPDUs. + + TPDUs and fields used: + + DT + - End of TSDU (1 bit) + + Description: + + The data field of Data TPDUs may contain any number of octets +up to an agreed maximum as negotiated at connection time. + + A transport entity uses an End of TSDU mark as defined below: + + In each Data TPDU a transport entity may indicate the end of a +TSDU. + + Category 1 Having the End of TSDU mark set to yes. These + TPDUs may or may not have the maximum length. + + Category 2 Having the End of TSDU mark set to no. These + TPDUs do not necessarily have the maximum + length. + + A complete Data TPDU sequence is defined as being composed of + +ISO Transport Protocol Specification Page 17 +International Standards Organization + + +either a single category 1 DT TPDU or consecutive category 2 followed +by a category 1 DT TPDU. + +6.4 Concatenation and Separation + + Pupose: Conveyance of multiple TPDUs in one NSDU. + + Description: + + All TPDUs carry in their TPDU header a length indicator (see +Section 8.2.1). Additionally, TPDUs are classified as either Data +TPDUs or Control TPDUs. Control TPDUs may or may not contain a data +field. For TPDUs containing data the length of the data field is +indicated by the length of the NSDU. These provisions permit any +number of Control TPDUs that may not contain data to be concatenated +with a single control TPDU which may contain data or with a single +Data TPDU. The control TPDUs without data must precede the TPDU with +data, if any. The number of TPDUs so concatenated is terminated by +the end of the NSDU. + + The concatenated set of TPDUs may be for the same or different +transport connections. An implementation shall accept concatenated +TPDUs and may concatenate TPDUs before transmission. The transport +entity shall not send a concatenated set of TPDUs which exceeds twice +the overall maximum TPDU length for all the TCs assigned to the +network connection. + +6.5 Connection Establishment + + Purpose: Creation of a new transport connection. + + Network Service Primitives: + + N-DATA + + TPDUs and fields used: + + CR, CC + - source reference (16 bits) + - initial credit (if applicable) + - calling transport address (optional) + - called transport address (optional) + - user data (optional) + - TPDU size (optional) + - sequence number length (optional) + - checksum selection (optional) + - acknowledgement time (optional) + - quality of service (optional) + CR + - preferred protocol class + +ISO Transport Protocol Specification Page 18 +International Standards Organization + + + - alternative protocol classes (zero or more) + - version number (optional) + - security (optional) + - proposed options + CC + - destination reference (16 bits) + - selected protocol class + - selected options + + Description: + + This function is inherent: + + A transport connection is established by means of one +transport entity (the initiator) transmitting a Connection Request +(CR) TPDU to the other transport entity (the responder), which replies +with a Connection Confirm (CC) TPDU. Before sending the CR TPDU, the +initiator assigns the transport connection being created to one (or +more if the splitting function is being used) network connection(s). +It is this set of network connections over which the TPDUs are sent. +During this exchange, all information and parameters needed for the +transport entities to operate must be exchanged or negotiated. + + The following information is exchanged: + + o references. Each transport entity chooses a reference which + is 16 bits long and which is arbitrary except for the following + restrictions: + + - it cannot already be in use or "frozen" (see "Frozen + References", Section 6.19). + + - it cannot be zero. + + Each transport entity is responsible for selecting the +Reference which the partner will use. This mechanism is symmetrical +and therefore avoids the need to assign a status of master or slave to +partners and avoids call collision. This mechanism also provides +identification of the transport connection independent of the network +connection. The range of References used for transport connections, in +a given transport entity, is a local system parameter. + + o addresses (optional). Indicate the calling and called + transport service access points. When either network + address unambiguously defines the transport address this + information may be omitted. + + o initial credit. Only relevant for classes which include + the Explicit Flow Control Function. + + +ISO Transport Protocol Specification Page 19 +International Standards Organization + + + o user data. Not available in class 0. Up to 32 octets in + in other classes. + + The following negotiations take place: + + o protocol class. The initiator shall propose a preferred +class and any number of alternatives. (Except that no alternatives are +allowed when class 0 is the preference.) The initiator should assume +when it sends the CR TPDU that its preferred class will be agreed to, +and commence the functions associated with that class. + + Note: This means, for example, that when a class which +includes resynchronization (see "Resynchronization", Section 6.15) is +preferred, resynchronization will occur if a reset is signalled during +connection establishment. + + When the responder has decided which class is to be used, it +shall indicate this in the CC TPDU and shall invoke the appropriate +functions for the class. The responder may select the preferred +class, or any of the alternative classes or may select class 0 if +class 1 is proposed or class 2 if class 3 or 4 is proposed. (see +Section 9) + + If the preferred class is not selected, then on receipt of the +CC TPDU, the initiator shall adjust its functions accordingly. + + o TPDU Size. The initiator may propose a maximum size for +TPDUs, and the responder may accept this value or respond with any +value between the proposed value and 128 in the set of values +available (see "Encoding", Section 8). + + o sequence number length. Either normal or extended is +available. When the sequence number is extended, the credit field (if +applicable) is also extended. + + o checksum selection. This defines whether or not TPDUs of +the connection are to include a checksum. + + o version number. This defines the version of the transport +protocol standard used for this connection. + + o security parameter. This parameter and its semantics are +user defined. + + o quality of service parameter. This defines the throughput, +delay, priority and residual error rate. + + o The non-use of explicit flow control in class 2 is +negotiated. + + +ISO Transport Protocol Specification Page 20 +International Standards Organization + + + o The use of Network Receipt Confirmation and Network +expedited is negotiated when class 1 is to be used. + + The negotiation rules for the options are such that the +initiator may propose either to use or not to use the option. The +responder may either accept the proposed choice or select the +mandatory alternative defined in Section 9. + + During the establishment phase of the transport connection, +the use of the expedited data option field of CR/CC allows both +Transport Service user to negotiate the use or non use of the +expedited data transport service as described in the transport service +definitions. + + The following table summarizes the negotiation possibilities +for the options. + + Proposition Made Possible + by the Initiator Selection by + Option the Responder + +Transport expedited data Yes Yes or No +transfer service No No + +Use of receipt confir- Yes Yes or No +mation (class 1 only) No No + +Use of the network Yes Yes or No +expedited variant No No +(class 1 only) + +Non use of checksum Yes Yes or No +(class 4 only) No No + +Non use of explicit Yes Yes or No +flow control (class 2 only) No No + +Use of extended format Yes Yes or No + No No + + In class 2, whenever a transport entity requests or agrees to +the Transport Expedited data transfer service or to the use of +extended formats, it must also request or agree (respectively) to the +use of explicit flow control. + +6.6 Connection Refusal + + Purpose: Refusal of the transport connection. + + TPDUs and fields used: + +ISO Transport Protocol Specification Page 21 +International Standards Organization + + + DR + - reason (1 octet) + - user data (maximum of 64 octets) + + ERR + - reject code (1 octet) + - rejected TPDU parameter + + Description: + + If a transport connection cannot be accepted, the called +transport entity shall respond to the CR TPDU with a DR TPDU. The +clearing reason shall indicate why the connection was not accepted. +The source reference field in the DR TPDU is set to zero to indicate +an unassigned reference. + + If the CR is regarded as an invalid TPDU, the called transport +entity will respond by sending an ERR TPDU. On receipt of this TPDU, +the calling entity will regard the connection as closed. + +6.7 Release + + Variants: 'implicit' or 'explicit' + + Purpose: Termination of the transport connection. + + Network Service Primitives: + + N-DISCONNECT (implicit variant only) + N-DATA + + TPDUs and fields used: + + DR + - clearing reason (1 octet) + - user data (maximum of 64 octets) + + DC + + Description: + + This function is inherent. + + In the 'implicit' variant, either transport entity disconnects +a transport connection by disconnecting the network connection to +which it is assigned. Similarly when a transport entity is informed +that the network connection has been disconnected by the peer +transport entity, this should be considered as a transport +disconnect. + + +ISO Transport Protocol Specification Page 22 +International Standards Organization + + + In the 'explicit' variant, either transport entity transmits a +Disconnect Request (DR) TPDU, and the other responds with a Disconnect +Confirm (DC) TPDU. When the DC TPDU is sent or received by a +transport entity, that entity should consider the transport connection +not to exist (note 1). After the sending of a DR TPDU, other TPDUs +received before the DC TPDU are ignored. It is possible that a +disconnect collision will occur, when both transport entities send a +DR TPDU at about the same time. This results in each transport entity +receiving a DR, after sending one. Each transport entity shall +consider the received DR TPDU as a confirmation of its DR TPDU, and +shall not send or expect to receive a DC TPDU. + + The DR can convey a limited amount (up to 64 octets) of data. + +6.8 Implicit Termination + + Purpose: Termination of a Transport Connection on the +occurrence of a signalled error for which recovery functions are not +operative. + + Network Service Primitives: + + N-DISCONNECT Indication + N-RESET Indication + + Description: + + When, on the network connection to which a Transport +Connection is assigned, an N-DISCONNECT or N-RESET Indication occurs, +both transport entities shall consider that the transport connection +no longer exists, and so inform the session entities. + +Note 1: + + When a connection has been released, after the exchange of DR +and DC, the reference can be re-used immediately (except in Class 4, +where the Frozen Reference function is used, see Section 6.19). This +is because the releasing transport entity does not know with certainty +that the remote transport entity considers use of the reference to be +ended. Therefore, the reference should not be re-used for further +connections. (In practice, the reference may be re-used after a +reasonable period when it is possible to be reasonably certain that +the remote transport entity will not continue to use it). + +6.9 Spurious Disconnect + + Purpose: To deal with the arrival of an "unknown" DR TPDU. + + TPDUs and fields used: + + +ISO Transport Protocol Specification Page 23 +International Standards Organization + + + DR, DC + - source reference + - destination reference + + Description: + + A DR TPDU can be received for a transport connection which +does not exist. Rather than treating this as an error, a DC TPDU +should be send back which reflects the references of the DR TPDU. + +Note: + This only applies when one or more transport connections using +a multiplexing class exist over the network connection, or when no +transport connections exist. At other times it is a protocol error. + +6.10 Data TPDU Numbering + + Variants: 'normal' or 'extended' + + Purpose: Numbering of DT TPDUs for use in recovery, + flow control, or sequencing functions. + + TPDUs and Fields Used: + + DT + - TPDU-NR (7 or 31 bits) + + Description: + + DT TPDUs transmitted in each direction on a transport +connection bear a sequence number 'TPDU-NR'. Its value in the first +DT TPDU in each direction after connection establishment will be zero. +Thereafter each TPDU had 'TPDU-NR' one greater than the previous. +Modulo 2**7 arithmetic is used in the 'normal' variant, and modulo 2**31 +in the 'extended' variant. + + In the sections that follow, the relationships 'greater than' +and 'less than' are used in connection with TPDU numbers. In all +such uses, the numbers being compared cover a range less than the +modulus and in fact lie within a contiguous set of TPDU numbers called +a 'window'. The window has a known starting TPDU number and finishing +number. The term 'less than' means 'occurring sooner in the window +sequence' and the term 'greater than' means 'occurring later in the +window sequence'. + +6.11 Expedited Data Transfer + + Variants: 'network expedited' or not + + Purpose: Provision of the expedited data service + +ISO Transport Protocol Specification Page 24 +International Standards Organization + + + Network Service Primitives: + + N-DATA + N-EXPEDITED DATA + + TPDUs and Fields Used: + + ED + - ED TPDU-NR (7 or 31 bits) + + EA + - YR-TU-NR (7 or 31 bits) + + Description: + + Each expedited TSDU is conveyed as the data field of an Expedited +Data (ED) TPDU. + + Each ED TPDU received must be acknowledged by an Expedited +Acknowledge (EA) TPDU. + + There may only be one ED TPDU unacknowledged at any time for each +direction of a transport connection. + + In the 'network expedited' variant (available in class 1 only), +ED and EA TPDUs are conveyed in the data fields of N-EXPEDITED DATA +primitives. Otherwise, N-DATA is used. + +6.12 Reassignment + + Purpose: Assignment of a Transport Connection to a different +Network Connection. + + TPDUs and Fields Used: + + CR + - source reference + + RJ, DR + - destination reference + + Description: + + When the Network Connection to which a Transport Connection was +assigned no longer exists, the Transport Connection can be assigned to +another Network Connection. + + When one transport entity has assigned the Transport Connection, +it is important that the other transport entity recognise to which +Network Connection it has been assigned. This can only take place when it + +ISO Transport Protocol Specification Page 25 +International Standards Organization + + +has received a TPDU for the Transport Connection on a Network Connection +with calling and called network addresses which imply +the same transport entities as the old. The TPDU will have been sent +as a result of the assigning transport entity commencing resynchronization, +and will thus be a RJ, or a retransmitted CR or DR. + + The Transport Connection shall be recognised as having been +assigned to the Network Connection on which the TPDU was received. + +6.13 Reassignment After Failure + + Purpose: Recovery from network provider initiated disconnect. + + Network Service Primitives: + + N-DISCONNECT Indication + + Description: + + When a N-DISCONNECT Indication arrives for the network connection +to which a transport connection is assigned, the transport connection must +be reassigned by its initiator (see "Reassignment") + + If the reassignment has not successfully occurred within a time +of T-wait seconds, then the transport connection must be considered as +non-existent by both transport entities.1 + + 1. The CR TPDU does not have a destination reference; + nevertheless it can be distinguished from a new + connection attempt by having the same source + reference. + + NOTE: The value of T-wait has to be agreed by the communicating +transport entities. + +6.14 Retention Until Acknowledgement of TPDUs + + Variants: 'confirmation of receipt' or 'AK' + + Purpose: To enable and minimize retransmission after +possible loss of TPDUs. + + Network Service Primitives: + + N-DATA + N-DATA ACKNOWLEDGE + + TPDUs and Fields Used: + + CR, CC, DR, DC + +ISO Transport Protocol Specification Page 26 +International Standards Organization + + + RJ, AK, EA + - YR-TU-NR (7 or 31 bits) + + DT + - TPDU-NR (7 or 31 bits) + + ED + - ED TPDU-NR (7 or 31 bits) + + Description: + + Copies of the following TPDUs shall be retained upon transmission +to permit their later retransmission: + + CR, CC, DR, DT, ED. + + NOTE: If DR is sent in response to CR there is no need to +retain a copy of the DR. + + In the 'confirmation of receipt' variant, applicable only +in Class 1, transport entities receiving N-DATA Indications which +convey DT TPDUs and have the confirmation request field set shall +issue a N-DATA Acknowledge Request at the earliest possible +opportunity (1). + + (1) It is a local matter for each transport entity to + decide which N-DATA Requests should have the + confirmation request parameter set. This decision + will normally be related to the amount of storage + available for retained copies of the DT TPDUs. + Use of the confirmation request parameter may + affect the quality of network service. + + After each TPDU is acknowledged, as shown in Figure 5, +the copy need not be retained. Copies may also be discarded when +the transport connection ceases to exist. + + TPDU ACKNOWLEDGED BY + + CR receipt of CC, DR, or ERR, TPDU + + DR receipt of DC or DR (in case of collision) + TPDU + + CC receipt of RJ, DT, AK, ED, EA TPDUs (or + N-DATA ACKNOWLEDGE Indication.) + + DT N-DATA ACKNOWLEDGE Indication when the + (Note 1) DT TPDU was sent before or with the oldest + N-DATA which had the confirmation request + +ISO Transport Protocol Specification Page 27 +International Standards Organization + + + field set. + + DT receipt of Data Acknowledge (AK) or + (Note 2) Reject (RJ) TPDU for which 'YR-TU-NR' + is greater than 'TPDU-NR' in the DT TPDU. + + ED receipt of EA TPDU for which 'YR-TU-NR' + is equal to 'ED-TPDU-NR' in the ED TPDU. Notes: + + + 1. Applies to 'confirmation of receipt' variant. + 2. Applies to 'AK' variant. + + Figure 5. Acknowledgement of TPDUs + +6.15 Resynchronization + + Purpose: To restore the connection to normal after an +error. + + Network Service Primitives: + + N-RESET Indication + + TPDUs and Fields Used: + + CR, DR, CC, DC + + RJ, EA + - YR-TU-NR (7 or 31 bits) + + DT + - TPDU-NR (7 or 31 bits) + + ED + - ED TPDU-NR (7 or 31 bits) + + Description: + + After the reset of an underlying network connection, +the resynchronization procedures below are carried out by both +transport entities. + + After a network connection failure, the reassignment after +failure function is invoked and then the resynchronization function. +The sequence of events at the two transport entities is the following: + + Events at the transport entity initiating reassignment: + (the transport entity immediately commences resynchronization + by sending a TPDU) + +ISO Transport Protocol Specification Page 28 +International Standards Organization + + + o if a CR is retained then retransmit it. + + o if a DR is retained then retransmit it. + + o otherwise, resynchronize data: + + - send RJ TPDU with 'YR-TU-NR' field set to + the 'TPDU-NR' of the first unreceived DT + TPDU + + - when RJ TPDU has been received retransmit any + ED TPDUs then DT TPDUs which are unacknowledged + + - any ED TPDUs received which are duplicates shall + be acknowledged (by EA TPDUs) and discarded. + + Events at the other transport entity: + + The transport entity shall not send any TPDUs until after +receipt of the TPDU which commenced resynchronization. This TPDU +therefore serves two purposes, namely indication of re-assignment +and commencement of resynchronization. + + o if the first received TPDU os a DR, then transmit + a DC TPDU. + + o if the first received TPDU is a CR and the transport + connection is not idle, this means that a CC TPDU is + retained: then retransmit it followed by any ED TPDU + and then DT TPDUs which are outstanding (that may or + may not have been transmitted previously). + + NOTE: no TPDUs can be transmitted using network expedited until +CC becomes acknowledged, to prevent the network expedited overtaking the +CC. + + o if the first received TPDU is a RJ, then act as follows: + + - if a DR TPDU is retained, then retransmit it + + - if a CC TPDU remains unacknowledged, then carry + out the data resynchronization procedure described + below + + - otherwise resynchronize data: + + - send RJ TPDU with 'YR-TU-NR' field set to + the 'TPDU-NR' of the first unreceived DT + TPDU + + +ISO Transport Protocol Specification Page 29 +International Standards Organization + + + - retransmit any ED TPDUs then DT TPDUs which + are unacknowledged + + - any ED TPDUs received which are duplicates + should be acknowledged (by EA TPDUs) and + discarded. + + NOTE: It is possible for a transport entity using the Class 1 +protocol to decide on a local basis to issue an N-RESET Request. The effect +of this request at the remote transport entity is to force it to perform +the resynchronization mechanism. This possibility may be used to remove +congestion within the network connection. + +6.16 Multiplexing and Demultiplexing + + Purpose: Concurrent sharing of a network connection by several +transport connections. + + TPDUs and Fields Used: + + CC, DR, DC, DT, AK, ED, EA, RJ, ERR + - destination reference + + Description: + + This function is pervasive. + + When this function is in operation, more than one transport +connection can be simultaneously assigned to the same network connection. + + Every TPDU (including DT TPDUs) must carry the destination +reference, to identify the transport connection to which it refers. + +6.17 Explicit Flow Control + + Purpose: Regulation of flow of DT TPDUs independently of +the flow control in the other layers. + + TPDUs and Fields Used: + + CR, CC, AK, RJ + - CDT (4 or 16 bits) + + DT + - TPDU-NR (7 or 31 bits) + + AK, RJ + - YR-TU-NR (7 or 31 bits) + - subsequence number (optional) + - flow control confirmation (optional) + +ISO Transport Protocol Specification Page 30 +International Standards Organization + + + Description: + + The mechanism depends on the class. Thus the description can +be found in the section describing the class. + +6.18 Checksum + + Purpose: To detect corruption of TPDUs by the network service +provider. + + TPDUs and Fields Used: + + All TPDUs + - checksum (16 bits - 32 bits) + + Description: + + When a TPDU is to be transmited for a TC which has selected the +checksum option, the sending transport entity must generate a checksum +for the TPDU and store it in the checksum parameter in the variable +part of the TPDU header. The checksum must be generated as follows: + + 1. Set up the complete TPDU, including the header and +user data (if any). The header must include the checksum parameter in +its variable part. The value field of the checksum parameter must be +set to zero at this point. + + 2. Initialize two variables to zero. Let these variables +be called C0 and C1. + + 3. For each octet of the TPDU, including the header, +variable part of the header and the user data, add the octet value to +C0, and then add the value of C0 to C1. Octets should be processed +sequentially, starting with the first octet (the Length Indicator) and +proceeding through the TPDU. All addition is to be performed modulo 255. + + 4. Calculate the value field of the checksum parameter as +follows. Let the offset into the TPDU of the first octet of the value +field be 'n' (where the first octet of the TPDU, the Length Indicator +of the header, is considered to be at offset 1). Let the length +of the TPDU, i.e. the number of times the above operation was repeated, +be 'L'. Let the first octet of the checksum value, i.e., the one at offset +'n' be called 'X', and the second octet, at offset 'n+1', be called 'Y'. +Then: + + X = (((L - n) * C0) - C1) modulo 255 + Y = (((L - n + 1) * (-C0)) + C1) modulo 255 + + 5. Place the computed values of X and Y in the appropriate +octets of the TPDU. + +ISO Transport Protocol Specification Page 31 +International Standards Organization + + + NOTE + + An implementation may use one's complete arithmetic as an + alternative to modulo 255 arithmetic. However, if either + of the checksum octets X and Y has the value minus zero + (i.e., 255) then it must be converted to plus zero + (i.e., 0) before being stored. + + When a TPDU is received for a TC for which the checksum option +has been selected, the TPDU must be verified to ensure that it has been +received correctly. This is done by computing the checksum, using the +same algorithm by which it was generated. The nature of the checksum +algorithm is such that it is not necessary to compare explicitly the stored +checksum bytes. The procedure described below may be used to verify that +a TPDU has been correctly received. + + 1. Initialize two variable to zero. Let these variables +be called C0 and C1. + + 2. For each octet in the received TPDU, add the value of +the octet to C0 and then add the value of C0 to C1, starting with the +first octet and proceeding sequentially through the TPDU. All +addition is to be performed modulo 255. + + 3. When all octets have been sequentially processed, the +values of C0 and C1 should be zero. If either or both of them is +non-zero, the TPDU has been received incorrectly and the verification +has failed. Otherwise, the TPDU has been received correctly and the +TPDU should be processed normally. + + NOTE + + An implementation may use one's complement arithmetic as an + alternative to modulo 255 arithmetic. In this case, if either + C0 or C1 has the value minus zero (i.e., 255) it is to be + regarded as though it was plus zero (i.e., 0) + + If a checksum verification failure occurs, it is not possible +to determine the TC that the TPDU relates to, since the Reference field +of the TPDU may have been received incorrectly. Therefore, all TCs +multiplexed onto the same NC must be treated as though a network signalled +error has occurred. + +6.19 Frozen References + + Purpose: To prevent re-use of a reference while TPDUs associated +with the old use of the reference may still exist. + + Description: When a transport entity determines that a particular +connection has terminated, the reference shall be placed in a frozen state + +ISO Transport Protocol Specification Page 32 +International Standards Organization + + +during which time it will not be reused. The circumstances under which +this is done, and the period of time for which the reference remains +frozen depends on the class. + +6.20 Retransmission on Timeout + + Purpose: To cope with unsignalled loss of TPDUs by the network +service provider. + + TPDUs and Fields Used: + + CR, CC, DR, DT, ED, AK + + Description: + + The description is given in the section related to class 4. + +6.21 Resequencing + + Purpose: To cope with misordering of TPDUs by the network +service provider. + + TPDUs and Field Used: + + DT + - TPDU NR + + ED + - ED TPDU NR + + Description: + + The description is given in the section related to class 4. + +6.22 Inactivity Control + + Purpose: To cope with unsignalled termination of a network +connection. + + TPDUs and Fields Used: + + AK + + Description: + + The description is given in the section related to class 4. + +6.23 Treatment of Protocol Errors + + Purpose: To deal with invalid TPDUs. + +ISO Transport Protocol Specification Page 33 +International Standards Organization + + + TPDUs and Fields Used: + + ERR + - reject cause + - TPDU in error (string of octets) + + DR + - reason code + + Description: + + This function is inherent. + + Any received TPDU which is invalid or which cannot be dealt with by +any operative function, or which is regarded as a violation of the protocol +rules of the class in use (e.g., receipt in a wrong state, window error, +sequencing error, TPDU with incorrect format), shall be considered as a +protocol error. Such an error shall be signalled to the transport entity +responsible by the sending of an TPDU Error (ERR) TPDU or by initiating a +release. The ERR TPDU conveys the octets of the offending TPDU up to +and including the octet where the error was detected. + + In general, no further action is defined for the sender of +ERR TPDU, since it is expected that the offender will either correct +the error, or close the connection. + + Action to be done by the receiver depends on local implementation +decision; e.g., freeze the connection, report to management, disconnect. + +NOTES: + + 1. Further action is a local implementation issue. Care +should be taken by the transport entity receiving several invalid TPDUs +or ERR TPDUs to avoid looping if the error is repeatedly generated. + + 2. There are two cases in which specific action is defined +for the receiver of the ERR TPDU (see Sections 6.6 and 7.0.7). + +6.24 Splitting and Recombining + + Purpose: To allow a transport connection to make use of +multiple network connections to provide additional resilience against +network failure, to increase throughput, or for other reasons. + + Description: + + This function is available only in Class 4. + + When this function is being used, a transport connection is +assigned (see Section 6.1) to multiple network connections. TPDUs for the + +ISO Transport Protocol Specification Page 34 +International Standards Organization + + +connection may be sent over any assigned network connection. The +resequencing function of Class 4 (see Section 6.21) is used to ensure +that TPDUs are processed in the correct sequence. + + If the use of Class 4 is not accepted by the remote transport +entity following the negotiation rules, only the network connection +over which the CR TPDU was sent may be used for this transport +connection. + + The splitting function should only be used where the +supporting network connections provide similar transmit delay. + + Protocol Mechanism Variant 0 1 2 3 4 + +Assignment to Network Conn. * * * * * + +TPDU Transfer * * * * * + +DT TPDU Length and Segmenting * * * * * + +Concatenation and Separation * * * * + +Connection Establishment * * * * * + +Connection Refusal * * * * * + +Release implicit * + explicit * * * * + +Implicit Termination * * + +DT TPDU Numbering normal * m m m + extended (1)o o o + +Expedited Data Transfer network exp. ao + not " m * * * + (1) + +Reassigment * * + +Reassignment after Failure * * + +Retention until Acknowledge- Conf. Receipt ao +ment of TPDUs AK m * * + +Resynchronization * * + +Multiplexing and * * * +Demultiplexing + + +ISO Transport Protocol Specification Page 35 +International Standards Organization + + +Explicit Flow Control With m * * + Without * * o + +Checksum (use of) m + (non-use of) * * * * o + +Frozen References * + +Retransmission on Timeout * + +Resequencing * + +Inactivity Control * + +Treatment of Protocol Errors * * * * * + +Splitting and recombining * + +(1) not applicable in class 2 when the non use of explicit flow +control is selected. + +7. PROTOCOL CLASSES + + The details of the implementation of the protocol +mechanisms are in certain cases different for different classes. +For this reason, the following table is not intended to provide a +complete description of the classes, but more to give an overview of +how each class works. The exact definition of the protocol is given +in the subsequent sections. + + KEY + + * include in the class (always) + + m mandatory function (negotiable but always implemented) + + o additional function (negotiable but not necessarily implemented) + + ao additional function (negotiable but not necessarily implemented). + Use of this option depends on the willingness of both transport + entities and availability of network service. + + na not applicable. + +7.0 PROTOCOL DESCRIPTION OF CLASS 0: SIMPLE CLASS + +7.0.1 Characteristics of Class 0 + + The characteristic of this class is that it provides +the simplest type of transport connection and fully compatible + +ISO Transport Protocol Specification Page 36 +International Standards Organization + + +with the CCITT recommendations S.70 for Teletex terminals. + + The class is designed for use in association with +network connections of type A (see 5.3.1.2.4.). + +7.0.2 Functions of Class 0 + + This class is designed to have minimum functionality. +It provides only the functions needed for connection +establishment with negotiation, data transfer with segmenting and +protocol error reporting. + + Class 0 provides transport connections with flow +control based on the network service provided flow control, and +disconnection based on the network service disconnection. + +7.0.3 Protocol Mechanisms of Class 0 + +7.0.3.1 Connection Establishment Phase + + Connection shall be made in accordance with the +general rules (Assignment of Network Connection, Connection +Establishment and Connection Refusal) with the following +restrictions: + + o No exchange of user data is allowed. + + o Only TSAP-ID and TPDU size parameters are allowed. + +7.0.3.2 Data Transfer Phase + + o Segmenting (DT TDPU length and Segmenting) + + o Detection and indication of procedural errors. + +7.0.3.3 Release Phase + + There is no explicit transport connection release +procedure for this class. The lifetime of the transport connection +is directly correlated to the lifetime of the network connection. + +7.0.4 Connection Establishment for Class 0 + + The connection establishment function is used +with the contraint that only the transport entity which has +requested the establishment of the network connection may send the +CR TPDU. If the calling transport entity receives a CR TPDU, it +shall transfer a TPDU Error (ERR) TPDU to notify the called +transport entity of the procedure error. + + +ISO Transport Protocol Specification Page 37 +International Standards Organization + + +7.0.5 Data Transfer Procedures + +7.0.5.1 General + + The data transfer procedures described in the +following subsections apply only when the transport layer is in the +data transfer phase, that is after completion of Transport +Connection establishment. + +7.0.5.2 Transport Data TPDU maximum length + + For Class 0 the standard maximum transport data +TPDU length is 128 octets including the data TPDU header octets. + + Other maximum TPDU lengths may be supported in +conjunction with the optional transport data TPDU size negotiation +function (see Section 8.3 and 8.4). Optional maximum data field +lengths shall be chosen from the following list: 256, 512, 1024 +and 2048 octets. + + TSDUs are transmitted using the segmenting function. + +7.0.6 Release Procedure + + The "implicit" variant of the release function is used. + +7.0.7 Treatment of invalid TPDUs + + The "treatment of protocol errors' function is used. + +7.0.8 Behaviour after an error signalled by the network service. + + The implicit termination function is used and the +high layer is informed about this disconnection. + +7.0.9 Supported Options + + None + +7.1 PROTOCOL DESCRIPTION OF CLASS 1: BASIC ERROR RECOVERY CLASS + +7.1.1 Characteristics of Class 1 + + The characteristic of this class is that it +provides a basic transport connection with minimal overheads. + + The main purpose of the class if to recover from +network signalled errors (network disconnect or reset). + + Selection of this class is usually based on + +ISO Transport Protocol Specification Page 38 +International Standards Organization + + +reliability criteria. Class 1 has been designed to be used in +association with type B network connections. + +7.1.2 Functions of Class 1 + + Class 1 provides transport connections with flow +control based on the network service provided flow control, error +recovery, expedited data transfer, disconnection, and also the +ability to support consecutive Transport connections on a network +connection. + + This class provides the functionality of Class 0 +plus the ability to recover after a failure signalled by the Network +Service, without involving the user of the Transport Service. + +7.1.3 Protocol Mechanisms of Class 1 + + Class 1 protocol mechanisms include Class 0 +protocol mechanisms plus the following: + +7.1.3.1 User Data in the Connection Phase + + Class 1 provides the possibility of conveying +data in the connection request and confirm commands. + +7.1.3.2 Numbering of Data TPDU + + Each Data TPDU transmitted between transport entities for +each direction of transmission in a transport connection is +sequentially numbered. + +7.1.3.3 Release + + The "explicit" variant of the release function is used. + +7.1.3.4 Error Recovery + + The sending Transport entity keeps a copy of transmitted +TPDUs until it receives an acknowledgment which allows copies to be released. +After a failure is indicated by the nerwork service (Reset, +Disconnect), the resynchronization function is used to determine +which TPDUs must be retransmitted. + + Resynchronization may also be invoked by a transport entity +as a local matter. For that purpose the Resynchronization function is +used (see note at the end of Section 6.15). + +7.1.3.5 Acknowledgement + + Acknowledgements are used to release copies of retained TPDUs. + +ISO Transport Protocol Specification Page 39 +International Standards Organization + + +Two methods of acknowledgment are provided in the Retention until +Acknowledgement of TPDUs function: + + o use of AK TPDU ("AK" variant) - mandatory + + Note: The credit field of the AK TPDU is + not used in this class (always Set to zero). + + o use of network layer Confirmation of Receipt Service. + ('confirmation of receipt' variant) - optional + + The variant to be used is negotiated during the +Connection Establishment Phase. The default option is the "AK TPDU" +variant. Use of Network Layer Receipt Confirmation is allowed only +in Class 1, and depends on the availability of the network layer +receipt confirmation service, the expected cost reduction, and the +agreement of both transport entities to use it. + +7.1.4 Connection Establishment Procedures for Class 1 + + The 'assignment to network connection' and +'connection establishment' mechanisms are used. From the point at +which a transport entity issues a CR proposing the use of Class 1 or +a CC accepting the use of Class 1 the following mechanisms must be +available to deal with signalled errors during connection +establishment: + + o Reassignment after failure + o Retention until Acknowledgement of TPDUs + o Resynchronization + + If no DT or ED TPDU is to be sent, receipt of a CC should be +acknowledged. + +7.1.5 Data Transfer Phase + + Data transfer is accomplished using the 'TPDU +transfer' 'Concatenation' and 'DT TPDU Length and Segmenting' +mechanisms. 'DT TPDU Numbering' and 'Retention until +Acknowledgement of TPDUs' are used in support of error recovery. + +7.1.5.1 Behaviour after an error + + After receiving a network reset, the Resynchronization +mechanism is invoked. After receiving a network disconnect, the +'Reassignment after Failure' mechanism is invoked after which the +'Resynchronization' mechanism is invoked. + + The 'Spurious Disconnect' mechanism is used to +deal with receipt of a DR TPDU for an unrecognised Transport + +ISO Transport Protocol Specification Page 40 +International Standards Organization + + +Connection. + +7.1.5.2 Procedure for Expedited Data Transfer + + The Expedited Data Transfer mechanism is used. +Two methods are possible to provide the function: + + o non network expedited variant + + Note: (1) This method is always included in this class. + + Note: (2) The EDTPDU-NR of the ED TPDU contains an +identification number. This number must be different for successive ED TPDUs. +That is, when an ED TPDU has been sent and an EA TPDU for the ED +TPDU has been received, the next ED TPDU must have a different value +in the EDTPDU-NR field. No other significance is attached to +EDTPDU-NR field. It is recommended but not essential, that the +values used be consecutive modulo 128. + + o network expedited variant + + Note: (1) The use of this method is +determined through negotiation during transport connection +establishment. + +7.1.6 Release Procedures + + The 'explicit' variant of the Release mechanism is used. + + Receipt of an error indication by a transport +entity, which, prior to this event has sent a DR, causes this +transport entity to retransmit DR. Only DC and DR will be accepted +and interpreted as the completion of the connection release +sequence. The related Reference will become unassigned. + +7.1.7 Treatment of Unknown TPDUs + + The 'Treatment of Protocol Errors' mechanism is used. + +7.1.8 Supported Options + + Use of network receipt confirmation. + + Use of network expedited. + +7.2 PROTOCOL DESCRIPTION OF CLASS 2: MULTIPLEXING CLASS + +7.2.1 Characteristics of Class 2 + + The characteristic of this class is to provide a + +ISO Transport Protocol Specification Page 41 +International Standards Organization + + +way to multiplex several transport connections onto a single network +connection. This class has been designed to be used in association +with type A network connections. + + Use of Explicit Flow Control + + The objective is to provide flow control to help +avoid congestion at end-points and on the network connection. +Typical use is when traffic is heavy and continuous, or when there +is intensive multiplexing. Use of flow control can optimize +response times and resource utilization. + + Non Use of Explicit Flow Control (optional) + + The objective is to provide a basic transport +connection with minimal overheads suitable when independence of +transport and network connection lifetime is desirable. The class +would typically be used for unsophisticated terminals, and when no +multiplexing onto network connections is required. Expedited data +is never available. + +7.2.2 Functions of Class 2 + + Class 2 provides transport connections with or +without individual flow control - no error detection or error +recovery is provided. + + If the network resets or clears, the transport +connection is terminated without the transport clearing sequence +and the transport user is informed. + + When explicit flow control is used a credit +mechanism is defined allowing the receiver to inform the sender of +the exact amount of data he is willing to receive and expedited data +transfer is available. + +7.2.3 Protocol Mechanisms of Class 2 + +7.2.3.1 Connection Establishment Phase + + The connection establishment function shall be used. + +7.2.3.1.1 User Data in the Connection Phase + + Class 2 provides the possibility to convey data in the +connection request and confirm commands. + +7.2.3.2 Connection Identification + + In Class 2 each TPDU conveys a Destination Reference. + +ISO Transport Protocol Specification Page 42 +International Standards Organization + + +This uniquely identifies the transport connection within the +receiving transport entity and thus allows multiplexing. + +7.2.3.3 Release Phase + + The release of a transport connection results either +from the use of the 'explicit' variant of the release function or +from the Implicit Termination function. + +7.2.3.4 Protocol Mechanisms when Explicit Flow Control is used. + + The following mechanisms are provided: + +7.2.3.4.1 Numbering of Data TPDU + + Each Data TPDU transmitted between transport entities +for each direction of transmission in a transport connection is +sequentially numbered. + + Each Data TPDU contains a Send Sequence Number T(S). + +7.2.3.4.2 Flow Control Principles + + The receiver of data TPDUs holds a count of the sequence +number of the next expected TPDU. This count is called the +Receive Sequence Number, T(R). The receiver indicated to the sender +the number of Data TPDUs he is ready to receive by means of a 'credit' +mechanism. Credits are given using the credit field in the AK TPDU. +The value of the credit field, in conjunction with the value of T(R) +transported by the YR-TU-NR (your TPDU number) field +of the AK TPDU, is used by the receiver of the AK TPDU to determine +whether and how many Data TPDUs may be accepted by the sender of the +AK TPDU. Precise definition of flow control principles appears in Section +7.2.5.5.3. + +7.2.3.4.3 Expedited Flow + + The non network expedited variant is used. Normal +flow is the flow of data subject to the flow control mechanism, +expedited flow is the flow of data that the sender may send without +explicit agreement of the receiver. This expedited flow has a +limited capability and could for example be used to carry session +supervisory commands. + + The number of expedited data units outstanding at any +time is limited to one and the amount of TS-user data is limited (up +to 16 octets). + + An expedited data may arrive before normal data which +was submitted earlier. Normal data submitted after the expedited + +ISO Transport Protocol Specification Page 43 +International Standards Organization + + +data will arrive after the expedited data. + +7.2.4 Connection Establishment Procedures for Class 2 + +7.2.4.1 References + + See Section 6.5 for reference assignment. Receipt of +any TPDU with a reference that is not assigned to a transport +connection other than a Disconnect Request (DR) or Connection +Request (CR) will be ignored. + + Receipt of a Disconnect Request (DR) for an unassigned +Reference will result in a Disconnect Confirm (DC) response. + +7.2.4.2 Connection Eastablishment + + This phase is achieved by exchange of CR/CC TPDU using +the 'connection establishment' function. Since the multiplexing +function is in use, then more than one transport connection may be +assigned to the same network connection concurrently. The +restrictions of Class 0 does not apply to this class and the other +higher classes. + +7.2.5 Data Transfer Procedures for Class 2 + + The data transfer procedures described in the +following section apply independently to each transport connection +existing between two transport entities. + +7.2.5.1 TPDU Maximum Length and Segmenting + + The general rules defined in Section 6.3 apply. + +7.2.5.2 Concatenation + + The general rules defined in Section 6.4 apply. + +7.2.5.3 Sending Data TPDU (No Explicit Flow Control Option) + + In this case the data TPDU is built in accordance +with the rules stated in Section 6.2 and 6.3 and sent without any +additional mechanisms. Thus, the DT TPDU NR field may take any +value and no AK TPDU is used. + +7.2.5.4 Sending Data TPDU (When Explicit Flow Control is Used) + + On each transport connection the transmission of Data +TPDUs is controlled separately for each direction and is based on +authorization from the receiver. + + +ISO Transport Protocol Specification Page 44 +International Standards Organization + + + This authorization is provided through the use of +the TPDUs Credit field. Credit field values are only present in +the following TPDUs: CR, CC, AK.. + +7.2.5.4.1 Numbering of Data TPDUs + + Each Data TPDU transmitted between transport entities, +for each direction of transmission in a transport connection, is +sequentially numbered. + + The sender of Data TPDUs holds a count of the next +TPDU to be sent. This count is called the Send Sequence Number +T(S). The sender indicates to the receiver the number of the data +TPDU he sends by putting the current T(S) value into the TPDU-NR +field of the data TPDU. + + Sequence numbering is performed modulo 2**n, where n +is the number of bits of the sequence number field. The T(S) +counter cycles through the entire range 0 to (2**n)-1. + + At connection establishment time both Transport +entities initialize their T(S) and T(R) counts to zero (i.e. the +first Data TPDU to be transmitted between transport entities for a +given direction of data transmission after the connection +establishment has a TPDU-NR field set to zero). + + Receipt of a Data TPDU whose TPDU-NR field is not +equal to the expected value T(R), is to be regarded as a protocol +error. + + Operations described above are summarized as follows: + + o initalization + + T(S) = 0 T(R) = 0 + + Sending of Data TPDU + put T(S) into the TPDU-NR field of + the Data TPDU to be sent + + T(S) = (T(S) + 1) (modulo 2**n) + + Receiving of Data TPDU + + TPDU-NR field of the received data + TPDU which is not equal to T(R) is + a protocol error. + + T(R) = (T(R) + 1) (modulo 2**n) + + +ISO Transport Protocol Specification Page 45 +International Standards Organization + + +7.2.5.4.2 Window Definition + + For each transport connection and for each direction +of data transmission a 'transmit window' is defined as the (possibly +null) ordered set of consecutive data TPDUs authorized to be +transmitted in that direction. At any given time, the lowest +sequence number of a data TPDU which a transport entity is +authorized to transmit is referred to as the 'lowest window edge'. +The 'upper window edge' is calculated by adding the credit +allocation, given by the value of the Credit (CDT) field contained +in a received TPDU, to the lower window edge. Note that a transport +entity is authorized to send data TPDUs with sequence numbers up to +but not including the upper window edge. + +7.2.5.4.3 Flow Control + + Flow control is performed as follows: + + o initialization time + + Lower window edge = 0 + + Upper window edge = N (Credit received either in + CR or in CC and N < 2**p < 2** (n-1), where P is the number of + bits in credit field of CR and CC. + + o Sending of a Data TPDU + + Send data TPDUs while T(S) is less than the upper window + edge. If T(S) equals the upper window edge then wait for + additional credit before sending. + + o Reception of Data TPDU (with TPDU NR = T(R) + + If T(R) is greater than or equal to the upper window edge + authorized to the sending transport entity, then the receiving + transport entity shall use the Treatment of Protocol Errors + function. Otherwise T(R) shall be incremented. + + Sending Credit + + Send AK TPDU with YR-TU-NR = T(R) and Credit equals N. + (Where N = number of additional data + TPDUs the entity is prepared to receive.) + + Receiving Credit in AK. + + Lower window edge = YR-TU-NR received. + + Upper window edge = Lower window edge + N. + +ISO Transport Protocol Specification Page 46 +International Standards Organization + + +7.2.5.4.4 Reducing the Upper Window Edge + + The value of the upper window edge cannot be decreased +in this class. If, at a certain point of time, the upper window edge +value is U, the reception of an AK TPDU having YR-TU-NR = M and CDT += N such that: + + (U-M) (mod. 2**n) > N + +is a protocol error + + Provided the previous statements are respected, CDT +field may take any value including zero. + +7.2.5.4.5 Procedure for Expedited Data Transfer + + The procedure of expedited data transfer allows a +transport entity to transmit data to the remote transport entity +without following the flow control procedure of the normal data +flow. This procedure can only apply in the transfer phase. + + The expedited procedure has no effect on the transfer +and flow control applying to normal Data TPDUs. + + To transmit expedited data, the transport entity sends +an expedited data TPDU (ED TPDU). The size of a data field is +limited (up to 16 octets). The data field contains a complete ED +TSDU. The remote transport will then confirm the receipt of the ED +TPDU by transmitting an expedited TPDU acknowledgement (EA TPDU). +A transport entity can send another ED TPDU only after having +received an EA TPDU for the previously transmitted ED TPDU. In +class 2 the ED TPDU NR field of the ED and YR-TU-NR field of the EA +TPDU are not defined and may take any value. + +7.2.6 Release Procedures for Class 2 + + The data phase ends after a transport entity has sent +or received a Disconnect Request (DR). The transport entity will +ignore any incoming TPDU except DC or DR. + + If the network resets or clears the network +connection, all transport connections are terminated without the +transport clearing sequence. The References become frozen. + + For Class 2 the explicit variant of the 'release' +mechanism is used, enabling transport connections to be cleared +independently of the underlying network connection. + +7.2.7 Treatment of Invalid TPDUs + + +ISO Transport Protocol Specification Page 47 +International Standards Organization + + + The 'Treatment of Protocol Error' mechanism in Section +6.23 is used. + +7.2.8 Behaviour after an Error signalled by the Network Layer. + + The implicit termination mechanism is used. + +7.2.9 Supported Options + + Non use of explicit flow control. + Extended formats. + +7.3 PROTOCOL DESCRIPTION OF CLASS 3: ERROR RECOVERY AND MULTIPLEXING CLASS + +7.3.1 Characteristics of Class 3 + + The characteristics of Class 3 in addition to those of +Class 2 is to mask errors indicated by the network. Selection of +this class is usually based upon reliability criteria. Class 3 has +been designed to be used in association with type B network connections. + +7.3.2 Functions of Class 3 + + This class provides the functionality of Class 2 (with +use of explicit flow control) plus the ability to recover after a +failure signalled by the Network Layer without involving the user +of the transport service. + + The mechanisms used to achieve this functionality also +allow the implementation of more flexible flow control. + +7.3.3 Protocol Mechanisms of Class 3 + + Class 3 mechanisms include Class 2 (with use of +explicit flow control option) mechanisms and the ability to recover +after a failure signalled by the network without informing the user +of the transport connection. + +7.3.3.1 Error Recovery Principles + + The sending transport entity keeps a copy of +transmitted Data TPDUs and ED TPDUs until it receives a positive +aknowledgement which allows copies to be released. It may also +receive an RJ command inviting it to retransmit or transmit all Data +TPDUs, if any, from the point in the sequence indicated in the RJ +command. + + This is especially the case, when a failure is +indicated by the network. The transport entity sends an RJ command +in order to indicate the sequence number of the next expected TPDU. + +ISO Transport Protocol Specification Page 48 +International Standards Organization + + + Error recovery for ED TPDU is achieved by retransmission +(see 7.3.5.3). + +7.3.3.2 Relationship between Flow Control and Error Recovery + + Acknowledgement is performed by use of the T(R) count. A + credit is associated with this acknowledgement which may +be equal to or greater than zero. Thus it is possible to acknowledge +data without giving the right to send new data. + + Credit may be reduced, by the use of the RJ TPDU. + +7.3.4 Connection Establishment Procedure for Class 3 + + The rules for Class 2 (with use of explicit flow +control) apply with the addition of the following rules which apply +on receipt of an eror indication from the Network layer. + + o Reception of an error indication by a + transport entity which, prior to this event, has + sent a CR and has not yer received a CC, causes + the transport entity to retransmit CR. + + o Reception of an error indication by a + transport entity to wait for reception of CR, RJ + or DR TPDU. In this case: + + - Reception of CR will cause the transport + entity to retransmit CC. + + - Reception of RJ will cause the transport + entity to transmit an RJ with a YR-TU-NR + equal to zero and enter the data phase. + + - Reception of a DR will cause termination + of the transport connection as for Classes 1 + and 2 (see 7.1.4). + +7.3.5 Data Transfer Procedures for Class 3 + +7.3.5.1 Acknowledgement + + The 'AK' variant of the Retention until +Acknowledgement of TPDUs function is used. + +7.3.5.2 Retransmission Procedure + + TPDU retransmission is a procedure which allows +a transport entity to request retransmission of one or several +consecutive Data TPDUs from the remote transport entity. A + +ISO Transport Protocol Specification Page 49 +International Standards Organization + + +transport reject condition is signalled to the remote transport +entity by transmission of an RJ TPDU whose YR-TU-NR field indicates +the sequence number of the next expected Data TPDU. + + On receipt of a RJ TPDU, a Transport entity shall +accept credit to the value contained in the credit field and shall +re-transmit TPDUs, starting with the one whose number is specified in +the YR-TU-NR field of the received RJ TPDU, subject to the new +credit. + + The transport entity shall not specify a T(R) in the +RJ TPDU less than that which has previously been acknowledged. +Receipt of an RJ TPDU with a T(R) which has been previously +acknowledged will be considered a protocol error. + + Additional DT TPDUs pending initial transmission may +follow the retransmitted DT TPDU(s) if the window is not closed. + +7.3.5.3 Reducing the upper window edge + + It is possible to decrease the value of the upper +window edge down to the sequence number transported by YR-TU-NR +field of the RJ TPDU. Receipt of an DT TPDU which would have been +inside the window before the reduction is not a protocol error and +this TPDU may be discarded. + + Note: In such a case the credit equal to zero +achieves the effect of a Receive not Ready Condition. + +7.3.5.4 Behaviour after an error signalled by the network layer + + After receiving an error indication from the Network +Service, the transport entity shall tranmit to the remove entity an +RJ TPDU with YR-TU-NR field indicating the sequence number of the +next expected Data TPDU. + +7.3.5.5 Procedure for Expedited Data Transfer + + In Class 3, the ED TPDU-NR field of the Expedited +Data (ED) TPDU contains an identification number. This number must +be different for successive ED TPDUs. That is, when an ED TPDU has +been sent and an EA TPDU for the ED TPDU has been received, the next +ED TPDU must have a different value in the NR field of the ED +TPDU. No other significance is attached to this field. It is +recommended, however, that the values used be consecutive modulo +2**n. When a transport entity receives an ED TPDU for a transport +connection, it shall respond by transmitting an expedited +acknowledgement (EA) TPDU. + + It places in the YR-TU-NR field the value contained in + +ISO Transport Protocol Specification Page 50 +International Standards Organization + + +the NR field of the received ED TPDU. If, and only if, this value +is different from the NR field of the previously received ED TPDU, +the data contained in the TPDU is to be passed to the session entity. + + If an error indication from the Network layer is +received before the receipt of the expected Expedited Acknowledgement +(EA) TPDU, the transport entity shall retransmit the ED TPDU with +the same value in the NR field. By the rule described in the +previous paragraph, the session entity does not receive data +corresponding to the same expedited TPDU more than once. + +7.3.6 Release Procedures for Class 3 + + The rules for Class 2 apply with the addition of the +following rule: + + Receipt of an eror indication by a transport entity, +which prior to this event has sent a DR, causes this transport +entity to retransmit DR. Only DC and DR will be accepted and +interpreted as the completion of the connection clearing sequence. +The related Reference will become unassigned. + +7.3.7 Treatment of Invalid TPDUs + + The 'Treatment of Protocol Errors' mechanism is used. + +7.3.8 Supported Options + + Extended formats. + +7.4 PROTOCOL DESCRIPTION OF CLASS 4: ERROR DETECTION AND RECOVERY CLASS + +7.4.1 Characteristics of Class 4 + + The characteristic of Class 4, in addition to those of +Class 3, is the detection of errors which occur as a result of the +low grade of service available from the network layer. The kinds of +errors to be detected include: TPDU loss, TPDU delivery out of +sequence, TPDU duplication. These errors may afect control TPDUs as +well as Data TPDUs. + + Class 4 has been designed to be usd in association +with network connections of type C. + +7.4.2 Functions of Class 4 + + This class provides the functionality of Class 3, plus +the ability to detect and recover from lost, duplicated or out of +sequence TPDUs without involving the user of the transport service. + + +ISO Transport Protocol Specification Page 51 +International Standards Organization + + + This detection of errors is made by extended use of +the sequence numbering of Classes 2 and 3, by a timeout mechanism, +and by additional protocol mechanisms. + + This class additionally detects and recovers from +damaged TPDUs by using a checksum mechamism. The use of the +checksum mechanism must be available but its use or its non use is +subject to negotiation. Class 4 does not attempt to deal with +detection of errors due to the misdelivery of TPDUs. + +7.4.3 Protocol Mechanisms of Class 4 + +7.4.3.1 Network Service Data Unit Lifetime + + The network layer is assumed to provide, as an aspect +of its grade of service, for a bound on the maximum lifetime of +NSDUs in the network. This value is known by the Transport Layer. +The maximum time which may elapse between the transmission of an +NSDU into the network layer and the receipt of any copy of it is +referred to as M. + +7.4.3.2 Average Transit Delay + + It is assumed that there is some value of transmit +delay in the network, typically much less than M, which will be the +maximum delay suffered by all but a small proportion of NSDUs. This +value is referred to as E. + +7.4.3.3 Remote Acknowledge Time Assumptions + + Any transport entity is assumed to provide a bound for the +maximum time which can elapse between its receipt of a TPDU from +the Network Layer and its transmisssion of the Corresponding response. +this value is referred to as A/L. The corresponding time given by the +remote transport entity is referred to as A/R. The values for these +timers may be conventionally established or may be established +at connection establishment time. + +7.4.3.4 Local Retransmission Time + + The local transport entity is assumed to maintain a +bound on the time it will wait for an acknowledgement before +retransmitting the TPDU. This time is the local retransmission time +and is referred to as T1. + + T1 = 2*E + X + Ar? + + Where X is a value to allow for TPDU processing in the +local transport entity. + + +ISO Transport Protocol Specification Page 52 +International Standards Organization + + +7.4.3.5 Persistence Time + + The local transport entity is assumed to provide a +bound for the maximum time for which it may continue to retransmit +a TPDU requiring positive acknowledgment. This value is referred to +as R. + + The value is clearly related to the time elapsed +between retransmission, T1, and the maximum number of +retransmissions, N. It is not less than T1*N+X, where X is small +quantity to allow for additional internal delays, the granularity of +the mechanism used to implement T1 and so on. Because R is a bound, +the exact value of X is unimportant as long as it is bounded and +the value of a bound is known. + +7.4.3.6 Bound on Reference Identifier and Sequence Numbers + + Using the above values, a bound L may be established +for the maximum time between the decision to transmit a TPDU and the +receipt of any response relating to it. The value of L is given by: + + L = 2*M+R+Ar + + It is necessary to wait for a period L before reusing +any reference or sequence number, to avoid confusion in case a TPDU +referring to it may be duplicated or delayed. + + (Note: In practive, the value of L may be +unacceptably large. It may also be only a statistical figure at a +certain confidence level. A smaller value may therefore be used +where this still allows the required quality of service to be +provided). + +7.4.3.7 Inactivity Time + + To protect against unsignalled breaks in the network +connection (Half-open connections), each transport entity maintains +an inactivity time interval. If the interval passes without +receipt of some TPDU, the transport entity will terminate the TC by +making use of the release procedure. This interval is referred to +as I. + +7.4.3.8 Window Time + + A transport entity maintains a time to ensure that +there is a maximum interval between transmission of up-to-date +window information. This interval is referred to as the window +time, W. + +7.4.3.9 Class 4 Error Recovery Principles + +ISO Transport Protocol Specification Page 53 +International Standards Organization + + + In class 4, the transport entity associates a response time +with TPDUs sent requiring a response. If an appropriate response is +not received within time T1, the recovery procedure must be invoked +by the sender. This will usually involve the retransmission of the +corresponding TPDU. + + A TPDU may be transmitted a maximum number of times, +This number is referred to a N. The value of N is chosen so that +the required quality of service can be provided given the known +characteristics of the network connection. + +7.4.3.10 Relationship of Times and Intervals + + The following note describes the relationship between +the time described in Section 7.4.3.1 - 7.4.3.9. + + Note: + + a. The interrelationship of times for the worst case + is as follows: + + M: maximum transit delay of the network (see + 7.4.3.1) + + Ar maximum acknowledgement time of the remote + transport entity (see 7.4.3.3) + + R: maximum local retransmission time (see + 7.4.3.5) + + N: maximum number of transmission for a single + TPDU (see 7.4.3.9) + + L: maximum time for a TPDU to be valid (see + 7.4.3.6) + + R = T * (N-1) + 1 + + R + + * + M + L * + + A =2*M + A + R + R R + + * + M + +ISO Transport Protocol Specification Page 54 +International Standards Organization + + + + t t + + b. The interrelationship of times for the average + case is as follows (see 7.4.3.4) + + E: average transit delay for the network + (E<<M) + + X: TPDU processing time + + T : average time from sending a TPDU until + 1 the receipt of its acknowledgement (see + 7.4.3.4) + + A : maximum acknowledgement time of the + R remote transport entity (see 7.4.3.3) + + X + + E + + A T = 2*E + X + A + R 1 R + + E +t t + +7.4.3.11 Sequence Numbering + + In Class 4 sequence numbering is applied to certain +control TPDUs and their acknowledgements, as well as to DT TPDUs. +These are ED and its acknowledgement EA. + + The length of sequence numbers may be negotiated at +connection establishment. Where other than the default length is +used, an extended header format is used for sequenced TPDUs +containing additional octets of sequence numbers. Extended header +format includes a credit field on the appropriate TPDU types +allowing extended credit allocation. + +7.4.4 Procedures for Connection Establishment Phase + + The following features pertain to connection +establishment for Class 4: + + o In Class 4, a connection is not considered + established until the successful completion + of a 3-way TPDU exchange. The sender of a + CR TPDU must respond to the corresponding CC + +ISO Transport Protocol Specification Page 55 +International Standards Organization + + + TPDU by immediately sending a DT, ED or AK TPDU. + + o As a result of duplication, a CR TPDU may be + received specifying a source reference which + is already in use with the sending transport + entity. If the receiving transport entity + is in the data transfer phase, having + completed the 3-way TPDU exchange procedure, + the receiving transport entity should ignore + such a TPDU. Otherwise a CC TPDU should be + transmitted. + + o As a result of duplication or + retransmission, a CC TPDU may be received + specifying a paired reference which is + already in use. The receiving transport + entity should ignore such a CC TPDU. + + o A CC TPDU may be received specifying a + reference which is in the frozen state. The + response to such a TPDU should be a DR TPDU. + +7.4.4.1 Connection Request + + When a transport entity transmits a CR TPDU it starts +timer T1. If this timer expires before a CC TPDU is received, the +CR TPDU is retransmitted and the timer restarted. After +transmission of the CR TPDU N times, the connection establishment +procedure is abandoned and the failure reported to the transport +user. The reference must be placed in the frozen state for a period +L (see section 7.4.3.6). + +7.4.4.2 Incomimg Connection Request + + An incoming connection request is processed as for Class 3 + +7.4.4.3 Connection Confirm + + When a transport entity transmits a CC TPDU it starts +timer T1. If this timer expires before an AK or DT TPDU is +received, the CC TPDU is retransmitted according to the +retransmission principles in Section 7.4.3.9 + +7.4.4.4 Incoming Connection Confirm + + When a CC TPDU is received, the receiving transport entity +enters the data transfer phase. It must immediately transmit an +AK, ED or DT TPDU to complete the 3-way TPDU exchange. The +CC TPDU is subject to the usual rules of the data transfer phase +regarding retransmission, see Section 7.4.5.3. + +ISO Transport Protocol Specification Page 56 +International Standards Organization + + +7.4.4.5 Incoming Acknowledgement + + When an AK, DT or ED TPDU is received the receiving +transport entity can enter the data transfer phase. If the entity +has data to send it may send DT TPDUs or an ED TPDU. The DT TPDUs +are subject to flow control. Otherwise, the transport entity must +obey the inactivity principles (see Section 7.4.5.8). + +7.4.4.6 Unsuccessful Connection + + When a DR TPDU is received in response to a CR TPDU, +the timer T1 is cancelled and the reference placed in the frozen +state for a period L (see Section 7.4.6.1). + +7.4.4.7 Initial Credit Allocation + + The CR and CC TPDUs may allocate an initial credit value +to their respective recipients. This value is limited to 15 by the +encoding of the TPDU. Where the extended header format is in use, +credit values greater than 15 must be allocated using AK TPDUs. + +7.4.4.8 Exchange of Acknowledge Time + + A transport entity may transmit the value it intends +to use for AL at connection establishment, as the 'Acknowledge +Time' parameter in the CR or CC TPDU (depending on whether the +transport entity is initiating or accepting the transport +connection). If this parameter is present in a received CR or CC +TPDU, the value of AR should be set accordingly. If this +parameter is not present, AR may be assumed to be insignificant in +comparison to E the typical maximum transit delay. + +7.4.5 Procedure for Data Transfer Phase + +7.4.5.1 Sequence Control + + The receiving transport entity is responsible for +maintaining the proper sequence of DT TPDUs. + + DT TPDUs received out of sequence must not be +delivered to the TS-user until in-sequence TPDUs have also been +received. + + AK TPDUs also contain information allowing the +receiving transport entity to process them in the correct order. + +7.4.5.2 Duplicate DT TPDUs + + Duplicate TPDUs can be detected because the T(S) value +matches that of previously received TPDUs. T(S) values must not be + +ISO Transport Protocol Specification Page 57 +International Standards Organization + + +reused for the period L after their previous use. Otherwise, a +new, valid TPDU could be confused with a duplicated TPDU which had +previously been received and acknowledged. + + Duplicated DT TPDUs must be acknowledged, since the +duplicated TPDU may be the result of a retransmission resulting from +the loss of an AK TPDU. + + The data contained in a duplicated DT TPDU should be +ignored. + +7.4.5.3 Retransmission Principles + + When a transport entity has some outstanding DT or ED +TPDUs that require acknowledgement, it will check that no T1 +interval elapses without the arrival of an AK or EA TPDU that +acknowledges one of them. If the timer expires, the first TPDU is +retransmitted and the timer is restarted. After N transmissions +(N-1 retransmissions) the connection is assumed to have failed and +the release phase is entered, and the transport user is informed. + + DT TPDUs which fall beyond the current window (due to +reduction of the upper window edge) are not retransmitted until +advancement of the upper window edge so permits. + + Note: This requirement can be met by different + means, for example. + + 1. One timer is associated with each TPDU. If the + timer expires, the associated TPDU will be + retransmitted, and the timer T1 will be + restarted for all subsequent DT TPDUs. + + 2. One timer is associated with each TC: + + if the transport entity transmits a DT TPDU + requiring acknowledgement, it starts timer + T1, + + if the transport entity receives a TPDU that + acknowledges one of the TPDUs to be + acknowledged, timer T1 is restarted, + + if the transport entity receives a TPDU that + acknowledges the last TPDU to be + acknowledged, timer T1 is stopped. + + For the decision whether the retransmission timer T1 +is maintained on a per TPDU or on a per TC basis, throughput +considerations have to be taken into account. + +ISO Transport Protocol Specification Page 58 +International Standards Organization + + +7.4.5.4 Acknowledgement Principles + + A transport entity operating class 4 must acknowledge +all TPDUs received requiring acknowledgment. To avoid unnecessary +retransmissions and to avoid delays to transmission by the remote +transport entity, the delay for acknowledgement should not exceed +timer A (see Section 7.4.3.2). + L + + There are two TPDU types that must be acknowledged: +ED and DT. Receipt of an ED TPDU must be acknowledged by an EA +TPDU. A DT TPDU is acknowledged with an AK TPDU. + + An AK TPDU has the sequence number of the next DT +TPDU the receiving transport entity expects to receive. It thus +acknowledges receipt of all DT TPDUs with sequence numbers less than +the acknowledgement number. + + An AK TPDU may be repeated at any time, using the +sequence number in the last AK TPDU sent. + +7.4.5.5 Flow Control Principles + + Flow control in Class 4 is subject to the same +principles as in Classes 2 and 3. The credit mechanism and window +principle of those classes still apply, except that in class 4, the +upper window edge can be reduced by the receiving transport entity +by sending an AK TPDU with a smaller credit. + + A receiving transport entity may send an AK TPDU at +any time to change the window size. This AK TPDU may acknowledge a +new DT TPDU or may repeat a previous acknowledgement. + +7.4.5.6 Window Synchronization Principles + + To ensure the synchronization of flow control +information the window timer provokes the frequent exchange of AK +TPDUs between transport entities. The window timer maintains a +minimum level of TPDU traffic between transport entities cooperating +in a transport connection. + + In Class 4 the window size can be reduced in any AK +TPDU. Due to the possibility of misordering of AK TPDUs and the +associated loss of efficiency, the AK TPDU for class 4 +includes an additional field called the AK TPDU subsequence +parameter. + + An AK TPDU should contain the subsequence parameter +whenever a duplicate AK TPDU is sent with the same sequence number +but with reduced credit. The value of the subsequence parameter is + +ISO Transport Protocol Specification Page 59 +International Standards Organization + + +set to one for the first time the AK TPDU is resent with reduced +credit. + + When an AK TPDU is transmitted whose sequence +number is increased, the 'sub-sequence' parameter is omitted +until credit reduction takes place. + + When an AK TPDU is received, it must be processed +(i.e., its contents made use of) only if: + + o The sequence number is greater than in any + previously received AK TPDU, or, + + o The sequence number is equal to the highest + in any previously received AK TPDU, and the + sub-sequence parameter is greater than in + any previously received AK TPDU having the + same sequence number (where an + absent sub-sequence parameter is regarded + as having a value of zero), or + + o The sequence number and sub-sequence + parameter are both equal to the highest in + any previously received AK TPDU (where an + absent sub-sequence parameter is regarded as + having a value of zero), and the credit + field is greater than in any previously + received AK TPDU having the same sequence + and sub-sequence numbers. + + When an AK TPDU is transmitted which opens a closed +window (i.e. increases credit from zero), it should be retransmitted +at an interval of T1. Transmission should occur a maximum of N +times, after which the usual inactivity retransmission timer should +be reverted to. Retransmission may also cease if the local +transport entity becomes sure that the new credit information has +been received by the remote transport entity. + + If a transport entity receives an AK TPDU containing +a 'Flow Control Confirmation' parameter, whose Lower Window Edge and +Your-Sub-Sequence fields are equal to its own lower window edge and +sub-sequence number, it may note that the credit available at the +remote transport entity (relative the Lower Window Edge field) is at +least equal to the value conveyed as Your Credit. This enables the +transport entity to cease the frequent retransmission of window +information, if it thereby knows that the remote window is open. + + A transport entity need not retransmit window +information (except as described under Inactivity Principles) if it +is aware by the receipt of DT TPDUs that the remote transport entity + +ISO Transport Protocol Specification Page 60 +International Standards Organization + + +has sufficient credit to prevent deadlock. When an AK TPDU is +transmitted in response to a DT TPDU, the transport entity may +normally assume that the transmitter of the DT TPDU will ensure that +the AK TPDU is received, be retransmission of the DT TPDU if +necessary. Therefore, it can normally be assumed that the credit +conveyed in such an AK TPDU will be available to the remote +transport entity, and frequent retransmission is unnecessary. + + The assumption that the DT TPDU will be retransmitted +may be incorrect if credit reduction has taken place. Therefore, a +transport entity may not make this assumption if the +sequence number of the DT TPDU is less than or equal to the highest +value for which permission to transmit (i.e., credit) has been given +and subsequently withdrawn. + + Upon receipt of an AK TPDU which increases the upper +window edge, a transport entity may transmit an AK TPDU which +repeats the information contained in the received TPDU in a 'Flow +Control Confirmation' parameter in its variable part an thereby +assures the transmitter of the original AK TPDU of its own state. +Such an AK TPDU may be tranmmitted: + + o Upon receipt of a duplicated AK TPDU + (i.e., one which is identical in all fields, + including the sub-sequence parameter if + present, to the most recently received AK + TPDU which was not discarded due to + detection of a sequence error), not + containing the 'Flow Control Confirmation' + parameter. + + o Upon receipt of an AK TPDU which increases + the upper window edge but does not increase + the lower window edge, when the upper window + edge was formerly equal to the lower window + edge. + +7.4.5.7 Procedure for Expedited Data + + The procedure for expedited data is as for Class 3, +with the following exceptions. + + The ED TPDU has a sequence number which is allocated +from a separate sequence space from that of the DT TPDUs. The EA +TPDU carries the same sequence number as the corresponding ED TPDU. +Only a single ED TPDU may be transmitted and awaiting +acknowledgements at any time. + + Upon receipt of an unduplicated ED TPDU, a transport +entity immediately forwards the data to the transport user. The ED + +ISO Transport Protocol Specification Page 61 +International Standards Organization + + +TPDU sequence number is recorded in an EA TPDU sent to the other +transport entity. + + The sender of an ED TPDU shall not send any new DT +TPDU with higher T(S) until it receives the EA TPDU. This +guarantees the arrival of the ED TPDU before any subsequently sent +DT TPDUs. + +7.4.5.8 Inactivity Principles + + If the Inactivity Time I passes without receipt of +some TPDU, the transport entity will terminate the TC by making use +of the release procedure. To present expiration of the remote +transport entity's inactivity times when no data is being sent, the +local transport entity must send AK TPDUs at suitable intervals in +the absence of data, having regard to the probability of TPDU loss. +The Window Synchronization Principles (see 7.4.5.6) may ensure that +this requirement is met. + + Note: It is likely that the release procedure +initiated due to inactivity timer expiration will fail, as such +expiration indicates probable failure of the supporting NC or of the +remote transport entity. This case is described in Section 7.4.6. + +7.4.6 Procedures for Release Phase + + The rules for class 3 apply. The DR TPDU is subject +to the usual retransmission procedure. After N retransmissions, the +transport connection is considered disconnected, the Reference is +placed in the frozen state for a period L and retransmission ceases. + + The DC TPDU is sent only in response to a DR TPDU, and +is not subject to the retransmission procedure. + + The DC TPDU when received allows the transport entity +to release all resources maintained for the transport connection. + + The DR TPDU does not carry a sequence number. Any +previously transmitted TPDUs (including DT and ED) which are +received after the DR TPDU result in a further DR TPDU but are +otherwise ignored. After disconnection, for whatever reason, the +Reference is placed in the frozen state for a period L. + +7.4.6.1 Unassigned Frozen References + + When a transport connection is terminated, the +corresponding references cannot be immediately reused since TPDUs +containing these references may continue to exist in the network for +a time up to L. Therefore, these references will be placed in an +unassignable, frozen state for this peiod. + +ISO Transport Protocol Specification Page 62 +International Standards Organization + + + After an event involving loss of transport entity +state information, including the status of reference assignments, +all references relating to network connections whose transport +state information has been lost must be placed in the frozen state +for a period L. + + If a DC TPDU is received for a local reference which +is in the frozen state, or with a remore reference not matching the +already recorded one, this DC TPDU shall be ignored. + +7.4.7 Treatment of Invalid TPDUs + + The 'Treatment of Protocol Erorrs' function is used. + +7.4.8 Supported Options + + Non use of checksum. + + Use of extended formats. + +8. ENCODING + +8.1 Summary + + Classes + 0 1 2 3 4 Sect. Code + +CR Connection Request x x x x x 8.3 1110xxxx + +CC Connection Confirm x x x x x 8.4 1101xxxx + +DR Disconnect Request x x x x x 8.5 10000000 + +DC Disconnect Confirm x x x x 8.6 11000000 + +DT Data x x x x x 8.7 11110000 + +ED Expedited Data x NF x x 8.8 00010000 + +AK Data Acknowledgement NRC NF x x 8.9 0110xxxx + (Note 1) + +EA Expedited Data x NF x x 8.10 00100000 + Acknowledgement + +RJ Reject (Note 1) x x 8.11 0101xxxx + +ERR TPDU Error x x x x x 8.12 01110000 + +not available (Note 2) - 00000000 + +ISO Transport Protocol Specification Page 63 +International Standards Organization + + +not available (Note 2) - 00110000 + +not available (Note 2) - 1001xxxx + +not available (Note 2) - 1010xxxx + +Where xxxx (bits 4-1) is used to signal the CDT + +Note 1: In extended header format, the code for AK=0110 0000 and the + code for RJ=0101 0000. + +Note 2: These codes are already in use in compatible protocols + defines by standards organizations other than CCITT/ISO. + +NF: Not available when the non explicit flow control option is + selected. + +NRC: Not available when the receipt confirmation option is + selected. + +8.2 Structure + + As defined in the previous sections, all the Transport +Protocol Data Units (TPDU) shall contain an integral number of +octets. The octets in a TPDU are numbered starting from 1 and +increasing in the order of transmission. The bits in an octet are +numbered from 1 to 8, where bit 1 is the low-ordered bit. + + There are tao types of TPDUs: + + o Data TPDUs, used to transfer Transport Service + Data Units (TSDUs). The structure of the TSDUs is + maintained by means of the TSDU End Mark. + + o Control TPDUs, used to control the transport + protocol functions, including the optional + functions. + +Octets 1 2 3 4 n n+1 p p+1 + ------------ -------------- -------------- -------- + LI| | | | ... | | | .... | | | .... | + ------------ -------------- -------------- -------- + + <--- Fixed Part -----><-- Variable Part-> + (including checksum + where applicable) + + <--------------Header-------------------><----Data Field-> + +A TPDU is divided into four parts: + +ISO Transport Protocol Specification Page 64 +International Standards Organization + + + o Length Indicator Field (LI) + + o Fixed Part + + o Variable Part (may be omitted) + + o Data Field (may be omitted) + +The length Indicator Field, Fixed Part and Variable Part constitute +the Header of the TPDU. + +8.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 (11111110). The length indicated is the header length, +including parameters, but excluding the length indicator field and +user data, if any. The value 255 (11111111) is reserved for +possible extensions. + +8.2.2 Fixed Part + + The fixed part contains frequently occurring functions +including the code of the TPDU. The length and the structure of the +fixed part are defined by the TPDU code, defined by bits 5 to 8 of +the second octet of the header. + +8.2.2.1 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 Connecting Request + 1101 xxxx Connection Confirm + 0101 xxxx Reject + 0110 xxxx Data Acknowledgement + + Where xxxx (bits 4-1) is used to signal the CDT. + + Any other bit pattern may be used to define a TPDU Code. + Only those codes defined in Section 8.1 are currently valid. + +8.2.3 Variable Part + + The variable part is used to define parameters +relating to optional functions. If the variable part is present, it +shall contain one or more parameters. The number of parameters that +may be contained in the varialbe part is indicated by the length of + +ISO Transport Protocol Specification Page 65 +International Standards Organization + + +the variable part which is a LI minus the length of the fixed part. + + Since the currently defined minimum fixed part for +headers which allow parameters is four octets, and since the length +indication field is limited to a maximum of 254, the maximum length +of the variable part is 250 octets. + + Each parameter contained within the variable part is +coded as follows: + + Bits 8 7 6 5 4 3 2 1 + Octets + n+1 Parameter Code + n+2 Parameter Length + Indication (e.g."m") + n+3 Parameter Value + + n+2+m + + o The parameter code field is coded in binary and, + without extensions, provides a maximum number of + 255 different parameters. However, as noted below, + bits 8 and 7 indicates the source of definition, + so the practical maximum number of different + parameters is less. Parameter code 1111 1111 is + reserved for possible extensions of the parameter code. + + o The parameter length indication indicates the length, + in octets, of the parameter value field. The length + is indicated by a binary number, "m" with a theoretical + maximum value of 255. The practical maximum value of + "m" is lower. For example, in the case of a single parameter + contained within the variable part, two octets + are required for the Parameter Code and the Parameter Length + Indication itself. Thus, the value of "m" is limited + to 248. For larger fixed parts of the header and for + each succeedimg parameter, the maximum value of "m" decreases. + + o The parameter value field contains the value of the + parameter identified in the parameter code field. + + o No standard parameter codes use bits 8 and 7 with the + value 00. + + o Implementations shall accept the parameters defined in + the variable part in any order. If any parameter is + duplicated then the later value will be used. + +8.2.3.1 Checksum Parameter (Class 4 only) + + +ISO Transport Protocol Specification Page 66 +International Standards Organization + + + All TPDU types may contain a checksum parameter in +their variable part. This parameter must always be present except +when the non use of checksum option is selected. + + Parameter Code: 1100 0011 + Parameter Length: 2 + Parameter Value: Result of checksum algorithm. + This algorithm is specified in + Section 6.18. + +8.2.4 Data Field This field contains transparent user data. +Restrictions on its size are noted for each command. + +8.3 Connections Request (CR) + +8.3.1 Structure + + 1 2 3 4 5 6 7 8 p p+1 + LI CR CDT 00000000 00000000 SOURCE- class VARIABLE USER DATA + REFERENCE options PART + +8.3.2 LI + + See Section 8.2.1 + +8.3.3 Fixed Part (Octets 2 to 7) + + CR: Connection Request Code: 1110 + + CDT: Initial Credit Allocation (set to 0000 in + Classes 0 and 1 when specified as preferred class). + + SOURCE REFERENCE: Reference selected by the transport + entity initiating the CR TPDU to + identify the requested TC. + + CLASSES: Bits 8-5 octer 7 defines the preferred Transport + Protocol class to be operated over the requested + TC. This field may take on one of the following + values. + + 0000 Class 0 + 0001 Class 1 + 0010 Class 2 + 0011 Class 3 + 0100 Class 4 + + The CR contains the first choice of class in the fixed +part as above. Second and subsequent choices are listed in the +variable part if required. + +ISO Transport Protocol Specification Page 67 +International Standards Organization + + + Bits 4-1 of octet 7 are reserved for options to be +used on the requested transport connection. + + The use of bits 4-1 is as follows: + + BIT OPTION + + 4 0 always + + 3 0 always + + 2 =0 use of normal formats + =1 use of extended formats + + 1 =0 use of explicit flow control + in Class 2 + + =1 no use of explicit flow + control in Class 2 + + Note: + + 1. It is not valid to request 'use of expedited data + transfer' (Additional option parameter) and no use of + explicit flow control in Class 2' (bit 1 = 1). + + 2. Bits 4 to 1 are always zero in Class 0 and have + no meaning. + +8.3.4 Variable Part (Octets 8 to p) + + The following parameters are permitted in the variable part: + + o Transport Service Access Point Identifier (TSAP-ID) + + Parameter code 11000001 for the identifier of the Calling TSAP. + + 11000010 for the identifier of the Called TSAP. + + If a TSPA-ID is given in the request it may be +returned in the confirmation. + + o TPDU size + + This parameter defines the proposed maximum TPDU size +(in octets including the header) to be used over the requested +transport connection. The coding of this parameter is: + + Parameter Code 11000000 + + +ISO Transport Protocol Specification Page 68 +International Standards Organization + + + Parameter value field + + 00001101 8192 octets (not allowed in Class 0 of 1) + + 00001100 4096 octets (not allowed in Class 0 of 1) + + 00001011 2048 octets + + 00001010 1024 octets + + 00001001 512 octets + + 00001000 256 octets + + 00000111 128 octets + + Default value is 00000111 (128 octets) + + Version Number (not used in Class 0) + + Parameter code 11000100 + + Parameter value field 00000001 + + Default value 00000001 + + Default value 00000001 (not used in Class 0) + + o Security Parameter (not used in Class 0) + + This parameter is user defined. + + Parameter code 11000101 + + Parameter value and length field are user defined + + o Checksum (not used in Classes 0 through 3) + + See Section 8.2.3.1 + + This parameter must always be present in a CR TPDU + requesting Class 4, even if the checksum selection + parameter is used to request non-use of the checksum facility. + + o Additional Option Selection (not used in Class 0) + + This parameter defines the selection to be made as to + whether or not additional options are to be used. + + Parameter code 11000110 + +ISO Transport Protocol Specification Page 69 +International Standards Organization + + + Parameter length: 1 + Parameter value field: + + Bits related to options particular to one class are + not meaningful and may take any value in the other classes. + + BITS OPTION + + 4 1= Use of network expedited in Class 1 + 0= Non use of network expedited in Class 1 + + 3 1= Use of receipt confirmation in Class 1 + 0= Use of explicit AK variant in Class 1 + + 2 0= Checksums are to be used in Class 4 + 1= Checksums are not to be used in Class 4 + + 1 1= Use of transport expedited data transfer + service + 0= No use of transport expedited data transfer + service + + Default falue is 00000001 + + o Alternative protocol class (not used in Class 0) + + Parameter code 11000111 + + Parameter length n + + Parameter value encoded as a sequence of single +octets. Each octet is encoded as for octet 7 but with bits 4-1 set +to zero (i.e., no alternative option selections permitted). + + o Acknowledge Time + + This parameter conveys the maximum acknowledge time + AL to the remote transport entity. It is an indication only, and + is not subject to negotiation (see section 7.4.5.3). + + Parameter Code 10000101 + + Parameter Value field: n a binary number (2 octets) + + n is the maximum acknowledge time, expressed in + milliseconds. + + o Throughput Parameter code: 10001001 + + Length : 12 + +ISO Transport Protocol Specification Page 70 +International Standards Organization + + + 1st 3 octets : Targer value, + calling-called user + direction + + 2nd 3 octets : Min. acceptable, + calling-called + user direction + + 3rd 3 octets : Target value, + called-calling user + direction + + 4th 3 octets : Min. acceptable, + called-calling user + direction + + Values are expressed in octets per second. + + o Residual Parameter code: 10000110 + error rate + Length : 3 + + 1st octet : Target value, power + of 10 + + 2nd octet : Min. acceptable, + power of 10 + + 3rd octet : TSDU size of + interest, expressed + as a power of 2 + + o Priority Parameter code: 10000111 + + Length : 2 + + Value : Integer + + o Transit Parameter code: 10001000 + delay + + Length : 8 + + 1st 2 octets : Target value, + calling-called user + direction + + 2nd 2 octets : Max. acceptable, + calling-called user + direction. + +ISO Transport Protocol Specification Page 71 +International Standards Organization + + + 3rd 2 octets : Target value, + called-calling user + direction. + + 4th 2 octets : Max. acceptable, + called-calling user + direction + + Values are expressed in milliseconds. + +8.3.5 User Data (Octets p+1 to the end) + + No user data are permitted in class 0, and are +optional in the other classes. Where permitted, it may not exceed +32 octets. + +8.4 Connection Confirm (CC) + +8.4.1 Structure + + 1 2 3 4 5 6 7 8 p p+1 + + LI CC CDT DST-REF SOURCE-REF class VARIABLE USER DATA + 1101 options Part + +8.4.2 LT + + See Section 8.2.1. + +8.4.3 Fixed Part (Octets 2 to 7) + + CC : Connection Confirm + Code: 1101 + + CDT : Initial Credit + Allocation (set to + 0000 in Classes 0 + and 1). + + DST-REFERENCE : Reference + identifying the + requested transport + connection at the + remote transport + entity. + + SOURCE REFERENCE : Reference selected + by the transport + entity initiating + the CC TPDU to + +ISO Transport Protocol Specification Page 72 +International Standards Organization + + + identify the + confirmed TC. + + CLASSES : Defines the selected + transport protocol class to + be operated over the accepted + TC according to the + negotiation rules specified + in Section 6.5. + +8.4.4 Variable part (Octet 8 to p) + + See Section 8.3.4 + +8.4.5 User Data (Octets p+1 to the end) + + See Section 8.3.5 + +8.5 Disconnect Request (DR) + +8.5.1 Structure + +LI DR DST-REF SOURCE-REF REASON VARIABLE USER DATA + 10000000 PART + +8.5.2 LI + + See Section 8.2.1 + +8.5.3 Fixed Part (Octets 2 to 7) + + DR : Disconnect Request Code: 1000 + + DST-REFERENCE : Reference identifying the TC at + the remote transport entity. + + SOURCE REFERENCE : Reference identifying the TC at + the transport entity initiating + the command. Value zero when + reference is unassigned. + + REASON : Defines the reason for + disconnecting the TC. This field + shall take one of the following + values: + + The following values can be used + for class 1 to 4: + + 128 + 0 - Normal disconnect + +ISO Transport Protocol Specification Page 73 +International Standards Organization + + + initiated by session entity. + + 128 + 1 - Remote transport entity + congestion at connect request time + + *128 + 2 - Connection negotiation failed + (i.e. proposed class(es) not supported). + + 128 + 3 - Duplicated connection detected + + 128 + 4 - Mismatched references + + 128 + 5 - Protocol error + + 128 + 6 - Not used + + 128 + 7 - Reference overflow + + 128 + 8 - Connection request refused on this + network connection + + 128 + 9 - Not used + + 128 + 10 - Header or parameter length invalid + + The following values can be used for all classes. + + 0 - Reason not specified + + 1 - Congested at TSAP + + *2 Session entity not attached to TSAP + + *3 Address unknown + + Note: Reasons marked with '*' may be reported to + the TS-user as 'persistent', other reasons + as 'transient'. + +8.5.4 Variable Part (Octets 8 to 10) + + o A parameter may be provided to allow additional + information related to the clearing of the connection. + + Parameter code: 11100000 + + Parameter Value Field: Additional information. This + field is intended to be used by the transport service + provider for internal purposes. + + +ISO Transport Protocol Specification Page 74 +International Standards Organization + + + o Checksum (see 8.2.3.1) + +8.5.5 User Data (Octets p+1 to the end) + + Not allowed in class 0, + + This field may not exceed 64 octers and is used +to carry TS-User data. The successful transfer of this data is not +guaranteed. + +8.6 Disconnect Confirm (DC) + + (Not used in Class 0) + +8.6.1 Structure + + 1 2 3 4 5 6 7 p + LI DST-REFERENCE SOURCE-REFERENCE Variable Part + 11000000 + +8.6.2 LI + + See Section 8.2.1 + +8.6.3 Fixed Part (Octets 2 to 6) + + DC : Disconnect Confirm Code: 1100 + + DST-REFERENCE : See Section 8.3.3 + + SOURCE-REFERENCE: See Section 8.4.3 + +8.6.4 Variable Part + + Checksum (see 8.2.3.1) + +8.7 Data (DT) + +8.7.1 Structure + + Normal Format for Class 0 to 1 + + 1 2 3 4 5 + + LI DT E TPDU-NR User Data + 11110000 0 + T + + Normal format for Class 2, 3 and 4 + + +ISO Transport Protocol Specification Page 75 +International Standards Organization + + +1 2 3 4 5 6 p p+1 +LI DST-REFERENCE E TPDU-NR Variable Part User Data + 11110000 O + T + + Extended Format for optional use in Classes 2,3 and 4 + + 1 2 3 4 5,6,7,8 9 p p+1 + + LI DT DST-REFERENCE E TPDU-NR Variable User Data + 11110000 O + T + +8.7.2 LI + + Section 8.2.1 + +8.7.3 Fixed Part + + (Classes 0 to 1 : - Octets 2 to 3; classes 2,3,4 +normal format: Octets 2 to 5; classes 2,3,4 extended format: - +Octets 2 to 8) + + DT : Data Transfer Code: 1111 + + DST-REFERENCE : See Section 8.4.3 + + EOT : When set to ONE, indicates that + the current DT TPDU is the last + Data Unit of a complete DT TPDU + sequence (End of TSDU). + + TPDU-NR : TPDU Send Sequence Number (Zero in + Class 0), may take any value in + Class 2 without explicit flow + control. + +8.7.4 Variable Part + + Checksum (See 8.2.3.1) + +8.7.5 User Data Field + + This field contains data of the TSDU being transmitted. +The length of this field is limited to the negotiated TPDU size for +this transport connection minus 3 octets in Classes 0 and 1, +and minus 5 octets (normal header format) or +8 octets (extended header format) in the other classes. The +variable part, if presemt, amy further reduce the size of the user +data field. + +ISO Transport Protocol Specification Page 76 +International Standards Organization + + +8.8 Expedited Data (ED) + + (Not used in Class 2 when "no explicit flow + control" option is selected.) + +8.8.1 Structure + + Normal Format + + 1 2 3 4 EOT 5 6 p p + 1 + + LI ED DST-REFERENCE EDTPDU-NR Variable Part User Data + 00010000 1. + + Extended Format + + 1 2 3 4 EOT 5,6,7,8 9 p p + 1 + + LI ED DST-REFERENCE EDTPDU-NR Variable Part User Data + 00010000 1. + +8.8.2 LI + + See Section 8.2.1 + +8.8.3 Fixed Part + + (Octets 2 to 5, normal format: 2 to 8, extended format) + + ED: Expedited Data command code: 0001 + + DST-REFERENCE: Same as Section 8.4.3 + + ED TPDU-NR: Expedited TPDU identification number + (Classes 1, 3, and 4; may take any value in + Class 2). + +8.8.4 Variable Part + + Checksum (See 8.2.3.1) + +8.8.5 User Data Field + + This field contains an expedited TSDU. Up to 16 octets. + +8.9 Data Acknowledgement (AK) + + Not applicable for Class 0 and Class 2 when the "no +explicit flow control" option is selected, and for Class 1 when the +network receipt confirmation option is selected. + +ISO Transport Protocol Specification Page 77 +International Standards Organization + + + Flow Control Confirmation (class 4 only - optionally used) + + This parameter contains a copy of the information received +in an AK TPDU, to allow the transmitter of the AK TPDU to be certain +of the state of the receiving transport entity (See Section 7.4.5.6). + + Parameter Code: 100001011 + + Parameter value field 64 bits, used as follows: + + o Lower Window Edge (32 bits) + Bit 32 is set to zero, bits 31 to 1 contain the + YR-TU-NR value of the received AK TPDU. When normal + format is in use, only the least significant seven + bits (bits 1 to 7) of this field are significant. + + o Your Sub-Sequence (16 bits) + Contains the value of the sub-sequence parameter of + the received AK TPDU, or zero if this parameter was + not present. + + o Your Credit (16 bits) + Contains the value of the CDT field of the received AK + TPDU. When normal format is in use, only the least + significant four bits (bits 1 to 4) of this field are + significant. + +8.10 Expedited Data Acknowledgement (EA) + + (Not applicable for Class 0 and Class 2 when the no + explicit flow control option is selected). + +8.10.1 Structure + + Normal Format + + 1 2 3 4 5 6 p + + LI EA DST-REFERENCE . YR-TU-NR Variable Part + 00100000 0. + + Extended Format + + 1 2 3 4 5,6,7,8 9 p + + LI EA DST-REFERENCE . YR-TU-NR Variable Part + 00100000 0. + +8.9.1 Structure + + +ISO Transport Protocol Specification Page 78 +International Standards Organization + + + Normal Format + + 1 2 3 4 5 6 p + + LI AK CDT DST-REFERENCE . YR-TU-NR Variable Part + 0110 0. + + Extended Format + + 1 2 3 4 5,6,7,8 9,10 11 p + + LI AK DST-REFERENCE . YR-TU-NR CDT Variable Part + 01100000 0. + +8.9.2 LI + + See Section 8.2.1 + +8.9.3 Fixed Part + + (Octets 2 to 5, normal format: 2 to 10, extended format) + + AK: Acknowledgement command code: 0110 + + CDT: Credit Value (set to 0 in class 1) + + DST-REFERENCE: Same as Section 8.4.3 + + YR-TU-NR: Sequence number indicating the next expected + DT TPDU number. + +8.9.4 Variable Part + + Checksum (See 8.2.3.1) + + Sub-sequence number (class 4 only - optionally used). + + This parameter is used to ensure that AK TPDUs are + processed in the correct sequence. If it is absent, this is + equivalent to transmitting the parameter with a value of zero. + + Parameter Code: 100001010 + + Parameter Value: 16-bit sub-sequence number. + +8.10.2 LI + + See Section 8.2.1 + +8.10.3 Fixed Part + +ISO Transport Protocol Specification Page 79 +International Standards Organization + + + (Octets 2 to 5, normal format; 2 to 8, extended + format) + + EA: Acknowledgement command code: 0010 + + DST-REFERENCE: Same as Section 8.4.3 + + YR-TU-NR: Identification of the ED TPDU being + acknowledged. May take any value in Class 2. + +8.10.4 Variable Part + + Checksum (See 8.2.3.1) + +8.11 Reject (RJ) + + (Not used in Classes 0, 2, and 4) + +8.11.1 Structure + + Normal Format + + 1 2 3 4 EOT 5 6 p + + LI RJ CDT DST-REFERENCE . YR-TU-NR Variable Part + 0101 0. + + Extended Format + + 1 2 3 4 EOT 5,6,7,8 9,10 11 p + LI RJ DST-REFERENCE . YR-TU-NR CDT Variable + 0l0l0000 Part + +8.11.2 LI + + See Section 8.2.1 + +8.11.3 Fixed Part + + (Octets 2 to 5, normal format; 2 to 10, extended format) + + RJ: Reject Command Code: 0101 + + CDT: Credit Value (set to 0 in class 1) + + DST-REFERENCE: Same as Section 8.4.3 + + YR-TU-NR: Sequence number indicating the next expected + TPDU from which retransmission should occur. + + +ISO Transport Protocol Specification Page 80 +International Standards Organization + + +8.11.4 Variable Part + + No parameters exclusive to this TPDU type. + +8.12 TPDU Error (ERR) + + 1 2 3 4 5 6 + + LI ERR DST-REFERENCE Reject Parameters + 01110000 Cause + +8.12.1 LI + + See Section 8.2.1 + +8.12.2 Fixed Part + + ERR: TPDU Error Code: 0111 + + DST-REFERENCE: Same as Section 8.4.3 + + REJECT CAUSE: + 00000000 Reason not specified + + 00000001 Invalid parameter code + + 00000010 Invalid TPDU type + + 00000011 Invalid parameter value + +8.12.3 Variable Part (Octets 6 to the end) + + Parameter Code: 1100001 + + Parameter Value Field: + + Contains the bit pattern of the rejected TPDU up to and +including the octet which caused the rejection. This parameter is +mandatory in Class 0. + + Checksum (See Section 8.2.3.1) + +SECTION THREE - CONFORMANCE + +9. CONFORMANCE + + Implementations claiming conformance to this standard shall: + + 1. Implement either Class 0 or Class 2 or both. + + +ISO Transport Protocol Specification Page 81 +International Standards Organization + + + 2. If other classes are implemented, the following rules + shall be observed: + + a) If Class 3 or Class 4 is implemented then Class 2 + must be implemented + + b) If Class 1 is implemented then Class 0 must be + implemented. + + 3. The following table defines the requirements for the + implementation of the options defined in previous + sections: + + Class + 0 1 2 3 4 + + TPDU with Checksum no no no no m + TPDU without Checksum m m m m o + + Expedited Data Transfer no m m m m + No Expedited Data Transfer m m m m m + + Flow Control in Class 2 no no m no no + No Flow Control in Class 2 no no o no no + + 7 bits format (normal) m m m m m + 31 bits format (extended) no no o o o + + Use of Receipt Confirmation in no o no no no + Class 1 + No use of Receipt Confirmation in no m no no no + Class 1 + + Use of Network Expedited in Class no o no no no + 1, if T-EXPEDITED DATA necessary + + No use of Network Expedited in no m no no no + Class 1, if T-EXPEDITED DATA necessary + + o - optional: An implementation may or may not + provide this user-selected option. + + m - mandatory: An implementation must provide for this + option + + no - An implementation shall not provide + this option. + + 4. Implementations claiming conformance shall support a + TPDU length of 128 octets. If larger maximum TPDU + +ISO Transport Protocol Specification Page 82 +International Standards Organization + + + sizes can be supported in Classes 1,2,3, or 4, then + all permitted TPDU sizes between the maximum and 128 + octets shall be supported. + + 5. Claims of conformance shall state: + + a) which class of protocol is supported. + + b) which additional options indicated by the letter + 'o' in the above table are supported. +
\ No newline at end of file |