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
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
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
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
- 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.
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.
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:
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.
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:
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
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
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
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
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)
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
- 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)
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.
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
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.
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
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
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.
