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. 126.96.36.199 Relationship of Times and Intervals The following note describes the relationship between the time described in Section 188.8.131.52 - 184.108.40.206. Note: a. The interrelationship of times for the worst case is as follows: M: maximum transit delay of the network (see 220.127.116.11) Ar maximum acknowledgement time of the remote transport entity (see 18.104.22.168) R: maximum local retransmission time (see 22.214.171.124) N: maximum number of transmission for a single TPDU (see 126.96.36.199) L: maximum time for a TPDU to be valid (see 188.8.131.52) R = T * (N-1) 1 R * M L * A =2*M + A + R R R * M
t t b. The interrelationship of times for the average case is as follows (see 184.108.40.206) 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 220.127.116.11) A : maximum acknowledgement time of the R remote transport entity (see 18.104.22.168) X E A T = 2*E + X + A R 1 R E t t 22.214.171.124 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
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. 126.96.36.199 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 188.8.131.52). 184.108.40.206 Incomimg Connection Request An incoming connection request is processed as for Class 3 220.127.116.11 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 18.104.22.168 22.214.171.124 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 126.96.36.199.
188.8.131.52 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 184.108.40.206). 220.127.116.11 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 18.104.22.168). 22.214.171.124 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. 126.96.36.199 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 188.8.131.52 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. 184.108.40.206 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
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. 220.127.116.11 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.
18.104.22.168 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 22.214.171.124). 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. 126.96.36.199 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. 188.8.131.52 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
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
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. 184.108.40.206 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
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. 220.127.116.11 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 18.104.22.168) 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. 22.214.171.124 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.
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
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:
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. 126.96.36.199 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
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. 188.8.131.52 Checksum Parameter (Class 4 only)
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.
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
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 184.108.40.206 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
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 220.127.116.11). 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
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.
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
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
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.
o Checksum (see 18.104.22.168) 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 22.214.171.124) 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
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 126.96.36.199) 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.
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 188.8.131.52) 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.
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 184.108.40.206). 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
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 220.127.116.11) 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
(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 18.104.22.168) 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.
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 22.214.171.124) SECTION THREE - CONFORMANCE 9. CONFORMANCE Implementations claiming conformance to this standard shall: 1. Implement either Class 0 or Class 2 or both.
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
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.