As per Relevance of the word transport, we have this rfc below:
Network Working Group
Request for Comments: 892 December 1983
ISO Transport Protocol
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
Interconnection - Transport Protocol Specification.
Communication Review 12, 3-4 (July/October 1982), pp. 24-67.
and differs from it only in format
Table of
0.
1. Scope and Field of
2.
Section One -
3.
4. Symbols and
5.
5.1 Service provided by the transport
5.2 Service assumed from the network
5.3 Functions of the transport
5.4 Model of the transport
Section Two - Transport Protocol
6. Protocol
6.1 Assignment to network
6.2 Transport protocol data unit (TPDU)
6.3 Data TPDU length and
6.4 Concatenation and
6.5 Connection
6.6 Connection
6.7
6.8 Implicit
6.9 Spurious
6.10 Data TPDU
6.11 Expedited data
6.12
6.13 Reassignment after
ISO Transport Protocol Specification Page 2
International Standards
6.14 Retention until acknowledgement of
6.15
6.16 Multiplexing and
6.17 Explicit flow
6.18
6.19 Frozen
6.20 Retransmission on
6.21
6.22 Inactivity
6.23 Treatment of protocol
6.24 Splitting and
7. Protocol
7.0 Protocol description of class 0: simple
7.1 Protocol description of class 1: basic error recovery
7.2 Protocol description of class 2: multiplexing
7.3 Protocol description of class 3: error recovery and
7.4 Protocol description of class 4: error detection and recovery
8.
8.1
8.2
8.3 Connection Request (CR
8.4 Connection Confirm (CC
8.5 Disconnect Request (DR
8.6 Disconnect Confirm (DC
8.7 Data (
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 -
9.
0.
The Transport Protocol Standard is one of a set of
Standards produced to facilitate the interconection of
systems. The set of standards covers the services and
required to achieve such interconnection
The Transport Protocol Standard is positioned with respect
other related standards by the layers defined in the Reference
for Open Systems Interconnection (ISO 7498). It is most
related to, and lies within the field of application of the
ISO Transport Protocol Specification Page 3
International Standards
Service Standard (DP aaaa). It also uses and makes reference to
Network Service Standard (DP bbbb), whose provisions it assumes
order to accomplish the transport protocol's aims.
interrelationship of these standards is depicted in Figure 1.
-----------------------------------TRANSPORT SERVICE DEFINITION-----
Transport --Reference to aims---------------
Specification --Reference to assumptions--------
------------------------------------NETWORK SERVICE DEFINITION------
Figure 1 - Relationship between the transport protocol and
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
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
interconnection of two session entities (note that each class
a different set of functions for enhancement of service qualities).
This protocol standard is concerned with optimisation of
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
much material which is advisory or descriptive, but
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
implementation will operate the protocol defined in this
correctly under all circumstances. It is possible by means of
ISO Transport Protocol Specification Page 4
International Standards
to establish confidence that an implementation correctly operates
protocol in a representative sample of circumstances. It is, however
intended that this standard can be used in circumstances where
implementations fail to communicate in order to determine whether
or both have failed to operate the protocol correctly
The variations and options available within this standard
essential to enable a Transport Service to be provided for a
variety of applications over a variety of network qualities. Thus,
minimally conforming implementation will not be suitable for use
all possible circumstances. It is important therefore to qualify
references to this standard with statements of the options provided
required or with statements of the intended purpose of provision
use
1. Scope and Field of
1.1 This International Standard Specifies
a) five classes of
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
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
the transfer of data and control information
d) the functional requirements of equipment within
computer system claiming to implement these procedures
1.2 The procedures are defined in terms of
a) the interactions between peer transport entities
the exchange of transport protocol data units
b) the interactions between a transport entity and
transport service user in the same system through the exchange
transport service primitives
c) the interactions between a transport entity and
network service provider through the exchange of
ISO Transport Protocol Specification Page 5
International Standards
service primitives
1.3 This International Standard is applicable to equipment which
supports the Transport Layer of the OSI Reference Model and
wishes to interconnect in an open systems environment
2.
ISO 7498 Information processing systems - Open systems inter
connection - Basic Reference
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
definition (N729)
Section One -
3.
3.1 Equipment: Hardware or software or a combination of both;
need not be physically distinct within a computer system
3.2 Transport service user: An abstract representation of
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
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
4.1 Data
TPDU Transport protocol data
TSDU Transport service data
NSDU Network service data
4.2 Types of transport protocol data
ISO Transport Protocol Specification Page 6
International Standards
CR TPDU Connection request
CC TPDU Connection confirm
DR TPDU Disconnect request
DC TPDU Disconnect confirm
DT TPDU Data
ED TPDU Expedited data
AK TPDU Data acknowledge
EA TPDU Expedited acknowledge
RJ TPDU Rejected
ERR TPDU Error
4.3 TPDU
LI Length indicator (field
CDT Credit (field
TSAP-ID Transport service access point
(field
DST-REF Destination reference (field
SCE-REF Source reference (field
EOT End of TSDU
TPDU-NR DT TPDU number (field
ED-TPDU-NR ED TPDU number (field
YR-TU-NR Sequence number response (field
4.4
T (R) Receive sequence
T (S) Send sequence
4.5 Timer
T1 Elapse time between
N The maximum number of
L Bound for the maximum time between
decision to transmit a TPDU and the receipt
any response relating to
T-WAIT Maximum time for a reassignment to take
before TC failure is
I Inactivity timer - Maximum time allowed to
elapse between receipt of TPDUs before TC
failure is
W Window timer - Maximum interval between trans
mission of up to date window
4.6 Other
n The number of bits in the sequence
p The number of bits in the credit field of a
CR, CC or AK
ISO Transport Protocol Specification Page 7
International Standards
4.7
TS-user Transport service
TSAP Transport service access
NSAP Network service access
TC Transport
NC Network
5. Overview of the Transport
5.1 Service Provided by the Transport
The services provided by the protocol described in
document are connection-oriented services. They are defined
document DP aaaa. The Transport Service primitives provided
summarized in Figure 1.
ISO Transport Protocol Specification Page 8
International Standards
Primitive
------------------------------------------------------------------------
T-CONNECT Request To Transport Address, From
Indication Transport Address,
Data Option, Quality
Service, TS-User data
------------------------------------------------------------------------
T-CONNECT Response Responding Address, Quality
Confirmation of Service, Expedited
Option, TS-User data
------------------------------------------------------------------------
T-DATA Request TS-User data
------------------------------------------------------------------------
T-EXPEDITED Request TS-User data
DATA Indication
------------------------------------------------------------------------
T-DISCONNECT Request TS-User data
------------------------------------------------------------------------
T-DISCONNECT Indication Disconnect reason, TS-
data
------------------------------------------------------------------------
Figure 1. Transport Service
5.2 Service Assumed from the Network
The transport protocol described in this document assumes
the Network Services described in DP bbbb. The Network
primitives used are summarized in Figure 2.
ISO Transport Protocol Specification Page 9
International Standards
Primitive X/Y Parameters X/Y/
------------------------------------------------------------------------
N-CONNECT Request X Called Address,
Indication X Calling Address,
Response X NS-User data,
Confirmation X QOS.
------------------------------------------------------------------------
N-DATA Request X NS-User data,
Indication X Conf. Request
------------------------------------------------------------------------
N-DATA Request
ACKNOWLEDGE
------------------------------------------------------------------------
N-EXPEDITED Request Y
DATA Indication NS-User data
------------------------------------------------------------------------
N-RESET Request X
Indication
Response
Confirmation
------------------------------------------------------------------------
N-DISCONNECT Request X NS-User data
Indication
------------------------------------------------------------------------
X - The Transport Protocol assumes that this facility is
provided in all networks
Y - The Transport Protocol assumes that this facility
provided in some networks and a mechanism is
to optionally use the facility
Z - The Transport Protocol does not use this parameter
Figure 2. Network Service
5.3 Functions of the Transport
5.3.1 Connection Oriented
5.3.1.1 Overview of
The functions in the transport layer are at least
necessary to bridge the gap between the services available from
network layer and those to be offered to the transport users
The functions in the transport layer are concerned with
enhancement of quality of service, including all aspects of
optimization. They are described below; the descriptions are
into those concerned with the establishment phase, the data
ISO Transport Protocol Specification Page 10
International Standards
phase, and the release phase
5.3.1.1.1 Establishment
The goal of the establishment phase is to establish
transport connection, i.e., between two transport users.
functions of transport layer during this phase must match
requested class of services with the services provided by the
layer as follows
o Select network service which best matches the
of the TS-user taking into account charges for
services
o Decide whether to multiplex multiple transport
onto a single network connection
o Establish the optimum TPDU size
o Select the functions that will be operational upon
the data transfer phase
o Map transport addresses onto network addresses
o Provide a means to distinguish between two
transport connections
o Transportation of user's data
5.3.1.1.2 Data Transfer
The purpose of the data transfer phase is to permit two-
simultaneous transport of TSDUs between the session entities
by the transport connection. This purpose is achieved by means
two-way simultaneous communication in the Transport protocol and
the following functions. Each of these functions is used or not
in accordance with the result of the selection performed in
establishment phase
o Concatenation and
A function used to collect several TPDUs into a
NSDU; the destination transport entity separates the TPDUs
o Segmenting and
The splitting of a single data TSDU into multiple
which are reassembled into their original format at the
destination
ISO Transport Protocol Specification Page 11
International Standards
o Multiplexing and
A function used to share a single network
between two or more transport connections
o Splitting and
A function allowing the simultaneous use of two or
network connections to support the same transport connec
tion
o Flow
A function used to regulate the flow of TPDUs between
transport entities on one transport connection
o Error
A function used to detect the loss, corruption
duplication, misordering or misdelivery of TPDUs
o Transport Connection
A means to uniquely identify a transport
between the pair of transport entities supporting
connection during the lifetime of the
connection
o Error
A function used to recover from detected and
errors
o Expedited
A function used to bypass the flow control of normal data
TPDU. Expedited data TPDUs' flow is controlled by
separate flow control
o TSDU
A function used to determine the beginning and ending
a TSDU
5.3.1.1.3 Release
A function to provide a disconnection of the
connection, regardless of the current activity
5.3.1.2 Classes and
ISO Transport Protocol Specification Page 12
International Standards
A class defines a set of functions. In this protocol
classes are defined
o Class 0: Simple
o Class 1: Basic Error Recovery
o Class 2: Multiplexing
o Class 3: Error Recovery and Multiplexing
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
onto the same network connection
5.3.1.2.2 Options within
Options define potential functions which may be used
a class
5.3.1.2.3
Classes and options within classes are negotiated
the connection establishment phase
5.3.1.2.4 Choice of the Class of
The choice will be made by the transport entities
to
o the users requirement expressed via T-CONNECT
primitives. In particular, for the choice of
class of protocol, the following rules apply
- if the TS-User requests either transmission of
user data during the connection phase, or use
Expedited data transfer, then Class 0 cannot
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
of quality with respect to error behavior relative to the
requirements. Its main purpose is to provide a basis for the
regarding which class of transport connection should be used on top
ISO Transport Protocol Specification Page 13
International Standards
a given network connection
Type A: Network connection with acceptable residual
rate (for example not signalled by 'clear' or 'reset')
and acceptable rate of signalled failures
Type B: Network connections with acceptable residual
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
quality of service provided by particular Network connections
5.3.1.3 Potential
The protocol described in this document does not include
following set of functions which have been identified as
transport layer functions
o provision for
o provision for accounting
o provision for status exchanges and monitoring of
of
o provision for
o temporary release of network
5.4 Model of the Transport
TSAP
Transport Protocol Transport
Entity
NSAP ------- NSAP -------
| (NSAP) | (NSAP
| | | |
| |-------------------------|--------
| |
-----------------------------------
A Transport Protocol entity within the Transport
communicates with a Transport User through a TSAP by means of
ISO Transport Protocol Specification Page 14
International Standards
service primitives as defined by the transport service definition
aaaa. Service primitives will cause or be the result of
Protocol Data Unit exchanges between the peer Transport
entities supporting a Transport Connection. These protocol
are effected using the services of the Network Layer as defined by
Network Service Definition DP bbbb through one or more NSAPs
Transport connection endpoints are identified in end
by an internal, implementation dependent, mechanism so that
Transport User and the Transport Protocol entity can refer to
Transport connection
Section Two - Transport Protocol
6. Protocol
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
transport connection over a network connection, it must also be
for any and all other transport connections which use that
connection during its lifetime
6.1 Assignment to Network
Purpose: Assignment of transport connections to
connections
Network Service Primitives
N-
N-
Description
This function is inherent
Before a transport connection can be created or used, it
be assigned to one (or more if splitting function is being used
network connection(s). Both transport entities involved must
aware of this assignment. A transport connection may be assigned to
suitable existing network connection; one or more new
connections may also be created for the purpose
An existing network connection, which connects the
transport entities, is unsuitable for assignment of a
connection if, for example
o the quality of service needed for the transport
can not be met by using or enhancing the
ISO Transport Protocol Specification Page 15
International Standards
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
functions (e.g., multiplexing).
When a new network connection is created, the quality
service requested is a local matter, though it will normally
related to the requirements of transport connection(s) expected to
assigned to it
A Network Connection with no transport connections will
available after initial establishment or because
disconnection of all the transport connections previously assigned
it has taken place. Either Transport entity may as a
matter choose to disconnect the Network Connection or assign
Transport Connections to it
6.2 Transport Protocol Data Unit (TPDU)
Purpose: To convey transport protocol data unit in user
data fields of network service primitives
Network Service
N-
N-EXPEDITED
Description
This function is inherent
The Transport Protocol Data Units (TPDUs) defined for
protocol are listed in Figure 3.
TPDU name
Connection Request
Connection Confirm
Disconnect Request
Disconnect Confirm
Data
Expedited Data
Data Acknowledge
Expedited Acknowledge
Reject
TPDU Error
Figure 3. Transport Protocol Data
ISO Transport Protocol Specification Page 16
International Standards
TPDUs are conveyed using the NS-User data parameters of
Network Service primitives, primarily with the N-DATA, but also
N-EXPEDITED primitives
Transport entities shall accept all permissible assignments
may issue any permissible assignments. The permissible assignments
TPDUs to these primitives are shown in Figure 4. Concatenation
TPDUs is also permitted (see section 6.4).
Primitive Applicable TPDUs
N-DATA CR, CC, DR, DT, ED
AK, EA, RJ, DC,
N-EXPEDITED ED, EA 1
Notes
1. This assignment is permissible only when using class 1 and
the network expedited variant has been agreed
Figure 4. Network Service Primitives which can convey TPDUs
6.3 Data TPDU Length and
Purpose: Mapping between one TSDU and TPDUs
TPDUs and fields used
- End of TSDU (1 bit
Description
The data field of Data TPDUs may contain any number of
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
TSDU
Category 1 Having the End of TSDU mark set to yes.
TPDUs may or may not have the maximum length
Category 2 Having the End of TSDU mark set to no.
TPDUs do not necessarily have the
length
A complete Data TPDU sequence is defined as being composed
ISO Transport Protocol Specification Page 17
International Standards
either a single category 1 DT TPDU or consecutive category 2
by a category 1 DT TPDU
6.4 Concatenation and
Pupose: Conveyance of multiple TPDUs in one NSDU
Description
All TPDUs carry in their TPDU header a length indicator (
Section 8.2.1). Additionally, TPDUs are classified as either
TPDUs or Control TPDUs. Control TPDUs may or may not contain a
field. For TPDUs containing data the length of the data field
indicated by the length of the NSDU. These provisions permit
number of Control TPDUs that may not contain data to be
with a single control TPDU which may contain data or with a
Data TPDU. The control TPDUs without data must precede the TPDU
data, if any. The number of TPDUs so concatenated is terminated
the end of the NSDU
The concatenated set of TPDUs may be for the same or
transport connections. An implementation shall accept
TPDUs and may concatenate TPDUs before transmission. The
entity shall not send a concatenated set of TPDUs which exceeds
the overall maximum TPDU length for all the TCs assigned to
network connection
6.5 Connection
Purpose: Creation of a new transport connection
Network Service Primitives
N-
TPDUs and fields used
CR,
- 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
- preferred protocol
ISO Transport Protocol Specification Page 18
International Standards
- alternative protocol classes (zero or more
- version number (optional
- security (optional
- proposed
- destination reference (16 bits
- selected protocol
- selected
Description
This function is inherent
A transport connection is established by means of
transport entity (the initiator) transmitting a Connection
(CR) TPDU to the other transport entity (the responder), which
with a Connection Confirm (CC) TPDU. Before sending the CR TPDU,
initiator assigns the transport connection being created to one (
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
transport entities to operate must be exchanged or negotiated
The following information is exchanged
o references. Each transport entity chooses a reference
is 16 bits long and which is arbitrary except for the
restrictions
- it cannot already be in use or "frozen" (see "
References", Section 6.19).
- it cannot be zero
Each transport entity is responsible for selecting
Reference which the partner will use. This mechanism is
and therefore avoids the need to assign a status of master or slave
partners and avoids call collision. This mechanism also
identification of the transport connection independent of the
connection. The range of References used for transport connections,
a given transport entity, is a local system parameter
o addresses (optional). Indicate the calling and
transport service access points. When either
address unambiguously defines the transport address
information may be omitted
o initial credit. Only relevant for classes which
the Explicit Flow Control Function
ISO Transport Protocol Specification Page 19
International Standards
o user data. Not available in class 0. Up to 32 octets
in other classes
The following negotiations take place
o protocol class. The initiator shall propose a
class and any number of alternatives. (Except that no alternatives
allowed when class 0 is the preference.) The initiator should
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
includes resynchronization (see "Resynchronization", Section 6.15)
preferred, resynchronization will occur if a reset is signalled
connection establishment
When the responder has decided which class is to be used,
shall indicate this in the CC TPDU and shall invoke the
functions for the class. The responder may select the
class, or any of the alternative classes or may select class 0
class 1 is proposed or class 2 if class 3 or 4 is proposed. (
Section 9)
If the preferred class is not selected, then on receipt of
CC TPDU, the initiator shall adjust its functions accordingly
o TPDU Size. The initiator may propose a maximum size
TPDUs, and the responder may accept this value or respond with
value between the proposed value and 128 in the set of
available (see "Encoding", Section 8).
o sequence number length. Either normal or extended
available. When the sequence number is extended, the credit field (
applicable) is also extended
o checksum selection. This defines whether or not TPDUs
the connection are to include a checksum
o version number. This defines the version of the
protocol standard used for this connection
o security parameter. This parameter and its semantics
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
negotiated
ISO Transport Protocol Specification Page 20
International Standards
o The use of Network Receipt Confirmation and
expedited is negotiated when class 1 is to be used
The negotiation rules for the options are such that
initiator may propose either to use or not to use the option.
responder may either accept the proposed choice or select
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
Transport Service user to negotiate the use or non use of
expedited data transport service as described in the transport
definitions
The following table summarizes the negotiation
for the options
Proposition Made
by the Initiator Selection by
Option the
Transport expedited data Yes Yes or
transfer service No
Use of receipt confir- Yes Yes or
mation (class 1 only) No
Use of the network Yes Yes or
expedited variant No
(class 1 only
Non use of checksum Yes Yes or
(class 4 only) No
Non use of explicit Yes Yes or
flow control (class 2 only) No
Use of extended format Yes Yes or
No
In class 2, whenever a transport entity requests or agrees
the Transport Expedited data transfer service or to the use
extended formats, it must also request or agree (respectively) to
use of explicit flow control
6.6 Connection
Purpose: Refusal of the transport connection
TPDUs and fields used
ISO Transport Protocol Specification Page 21
International Standards
- reason (1 octet
- user data (maximum of 64 octets
- reject code (1 octet
- rejected TPDU
Description
If a transport connection cannot be accepted, the
transport entity shall respond to the CR TPDU with a DR TPDU.
clearing reason shall indicate why the connection was not accepted
The source reference field in the DR TPDU is set to zero to
an unassigned reference
If the CR is regarded as an invalid TPDU, the called
entity will respond by sending an ERR TPDU. On receipt of this TPDU
the calling entity will regard the connection as closed
6.7
Variants: 'implicit' or 'explicit
Purpose: Termination of the transport connection
Network Service Primitives
N-DISCONNECT (implicit variant only
N-
TPDUs and fields used
- clearing reason (1 octet
- user data (maximum of 64 octets
Description
This function is inherent
In the 'implicit' variant, either transport entity
a transport connection by disconnecting the network connection
which it is assigned. Similarly when a transport entity is
that the network connection has been disconnected by the
transport entity, this should be considered as a
disconnect
ISO Transport Protocol Specification Page 22
International Standards
In the 'explicit' variant, either transport entity transmits
Disconnect Request (DR) TPDU, and the other responds with a
Confirm (DC) TPDU. When the DC TPDU is sent or received by
transport entity, that entity should consider the transport
not to exist (note 1). After the sending of a DR TPDU, other
received before the DC TPDU are ignored. It is possible that
disconnect collision will occur, when both transport entities send
DR TPDU at about the same time. This results in each transport
receiving a DR, after sending one. Each transport entity
consider the received DR TPDU as a confirmation of its DR TPDU,
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
Purpose: Termination of a Transport Connection on
occurrence of a signalled error for which recovery functions are
operative
Network Service Primitives
N-DISCONNECT
N-RESET
Description
When, on the network connection to which a
Connection is assigned, an N-DISCONNECT or N-RESET Indication occurs
both transport entities shall consider that the transport
no longer exists, and so inform the session entities
Note 1:
When a connection has been released, after the exchange of
and DC, the reference can be re-used immediately (except in Class 4,
where the Frozen Reference function is used, see Section 6.19).
is because the releasing transport entity does not know with
that the remote transport entity considers use of the reference to
ended. Therefore, the reference should not be re-used for
connections. (In practice, the reference may be re-used after
reasonable period when it is possible to be reasonably certain
the remote transport entity will not continue to use it).
6.9 Spurious
Purpose: To deal with the arrival of an "unknown" DR TPDU
TPDUs and fields used
ISO Transport Protocol Specification Page 23
International Standards
DR,
- source
- destination
Description
A DR TPDU can be received for a transport connection
does not exist. Rather than treating this as an error, a DC
should be send back which reflects the references of the DR TPDU
Note
This only applies when one or more transport connections
a multiplexing class exist over the network connection, or when
transport connections exist. At other times it is a protocol error
6.10 Data TPDU
Variants: 'normal' or 'extended
Purpose: Numbering of DT TPDUs for use in recovery,
flow control, or sequencing functions
TPDUs and Fields Used
- 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
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
a 'window'. The window has a known starting TPDU number and finishing
number. The term 'less than' means 'occurring sooner in the
sequence' and the term 'greater than' means 'occurring later in
window sequence'.
6.11 Expedited Data
Variants: 'network expedited' or
Purpose: Provision of the expedited data
ISO Transport Protocol Specification Page 24
International Standards
Network Service Primitives
N-
N-EXPEDITED
TPDUs and Fields Used
- ED TPDU-NR (7 or 31 bits
- YR-TU-NR (7 or 31 bits
Description
Each expedited TSDU is conveyed as the data field of an
Data (ED) TPDU.
Each ED TPDU received must be acknowledged by an
Acknowledge (EA) TPDU.
There may only be one ED TPDU unacknowledged at any time for
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
primitives. Otherwise, N-DATA is used.
6.12
Purpose: Assignment of a Transport Connection to a
Network Connection
TPDUs and Fields Used
- source
RJ,
- destination
Description
When the Network Connection to which a Transport Connection
assigned no longer exists, the Transport Connection can be assigned
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
ISO Transport Protocol Specification Page 25
International Standards
has received a TPDU for the Transport Connection on a Network
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
assigned to the Network Connection on which the TPDU was received.
6.13 Reassignment After
Purpose: Recovery from network provider initiated disconnect
Network Service Primitives
N-DISCONNECT Indication
Description
When a N-DISCONNECT Indication arrives for the network
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
of T-wait seconds, then the transport connection must be considered
non-existent by both transport entities.1
1. The CR TPDU does not have a destination reference
nevertheless it can be distinguished from a
connection attempt by having the same source
reference.
NOTE: The value of T-wait has to be agreed by the
transport entities.
6.14 Retention Until Acknowledgement of
Variants: 'confirmation of receipt' or 'AK
Purpose: To enable and minimize retransmission
possible loss of TPDUs
Network Service Primitives
N-
N-DATA
TPDUs and Fields Used
CR, CC, DR,
ISO Transport Protocol Specification Page 26
International Standards
RJ, AK,
- YR-TU-NR (7 or 31 bits
- TPDU-NR (7 or 31 bits
- ED TPDU-NR (7 or 31 bits
Description:
Copies of the following TPDUs shall be retained upon
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
convey DT TPDUs and have the confirmation request field set
issue a N-DATA Acknowledge Request at the earliest
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
will normally be related to the amount of storage
available for retained copies of the DT TPDUs.
Use of the confirmation request parameter
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
the transport connection ceases to exist.
TPDU ACKNOWLEDGED
CR receipt of CC, DR, or ERR,
DR receipt of DC or DR (in case of collision
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
N-DATA which had the confirmation
ISO Transport Protocol Specification Page 27
International Standards
field set.
DT receipt of Data Acknowledge (AK)
(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
6.15
Purpose: To restore the connection to normal after an
error.
Network Service Primitives
N-RESET
TPDUs and Fields Used
CR, DR, CC,
RJ,
- YR-TU-NR (7 or 31 bits
DT
- TPDU-NR (7 or 31 bits
- ED TPDU-NR (7 or 31 bits
Description
After the reset of an underlying network connection
the resynchronization procedures below are carried out by
transport entities.
After a network connection failure, the reassignment
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
by sending a TPDU
ISO Transport Protocol Specification Page 28
International Standards
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
the 'TPDU-NR' of the first unreceived
- when RJ TPDU has been received retransmit
ED TPDUs then DT TPDUs which are
- any ED TPDUs received which are duplicates
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
therefore serves two purposes, namely indication of re-
and commencement of resynchronization.
o if the first received TPDU os a DR, then
a DC TPDU
o if the first received TPDU is a CR and the
connection is not idle, this means that a CC TPDU
retained: then retransmit it followed by any ED TPDU
and then DT TPDUs which are outstanding (that may
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
- if a CC TPDU remains unacknowledged, then
out the data resynchronization procedure
- otherwise resynchronize data
- send RJ TPDU with 'YR-TU-NR' field set
the 'TPDU-NR' of the first unreceived
ISO Transport Protocol Specification Page 29
International Standards
- retransmit any ED TPDUs then DT TPDUs
are
- 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
of this request at the remote transport entity is to force it to
the resynchronization mechanism. This possibility may be used to remove
congestion within the network connection.
6.16 Multiplexing and
Purpose: Concurrent sharing of a network connection by
transport connections
TPDUs and Fields Used
CC, DR, DC, DT, AK, ED, EA, RJ,
- destination
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
Purpose: Regulation of flow of DT TPDUs independently of
the flow control in the other layers.
TPDUs and Fields Used
CR, CC, AK,
- CDT (4 or 16 bits
- TPDU-NR (7 or 31 bits
AK,
- YR-TU-NR (7 or 31 bits
- subsequence number (optional
- flow control confirmation (optional
ISO Transport Protocol Specification Page 30
International Standards
Description
The mechanism depends on the class. Thus the description
be found in the section describing the class.
6.18
Purpose: To detect corruption of TPDUs by the network
provider.
TPDUs and Fields Used
All
- checksum (16 bits - 32 bits
Description
When a TPDU is to be transmited for a TC which has selected
checksum option, the sending transport entity must generate a
for the TPDU and store it in the checksum parameter in the
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
its variable part. The value field of the checksum parameter must
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
sequentially, starting with the first octet (the Length Indicator)
proceeding through the TPDU. All addition is to be performed modulo 255.
4. Calculate the value field of the checksum parameter
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
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
'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
octets of the TPDU.
ISO Transport Protocol Specification Page 31
International Standards
An implementation may use one's complete arithmetic as
alternative to modulo 255 arithmetic. However, if
of the checksum octets X and Y has the value minus
(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
has been selected, the TPDU must be verified to ensure that it has
received correctly. This is done by computing the checksum, using
same algorithm by which it was generated. The nature of the
algorithm is such that it is not necessary to compare explicitly the
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
be called C0 and C1.
2. For each octet in the received TPDU, add the value
the octet to C0 and then add the value of C0 to C1, starting with
first octet and proceeding sequentially through the TPDU. All
addition is to be performed modulo 255.
3. When all octets have been sequentially processed,
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
has failed. Otherwise, the TPDU has been received correctly and the
TPDU should be processed normally.
An implementation may use one's complement 