As per Relevance of the word expedited, we have this rfc below:
Network Working Group Y.
Request for Comments: 2126 Digital Equipment
Category: Standards Track A.
ISODE
March 1997
ISO Transport Service on top of TCP (ITOT
Status of the
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document is a revision to STD35, RFC1006 written by Marshall T
Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987,
much experience has been gained in using ISO transport services
top of TCP. This document refines the protocol and will
supersede RFC1006.
This document describes the mechanism to allow ISO Transport
to run over TCP over IPv4 or IPv6. It also defines a number of
features, which are not provided in RFC1006.
The goal of this version is to minimise the number of changes
RFC1006 and ISO 8073 transport protocol definitions, while
performance, extending its applicability and protecting the
base of RFC1006 users
Table of
1. Introduction, Motivation.....................................2
2. The Model....................................................3
2.1 ISO Transport Model.........................................3
2.2 ISO Transport over TCP (ITOT) Model.........................4
2.3 Overview of Protocol and Service............................5
3 Service Definition............................................5
3.1 Transport Service Definition................................5
3.1.1 Transport Service Definition Primitives...................6
3.2 Network Service Definition..................................7
3.2.1 ISO 8348 CONS primitives..................................7
3.2.2 TCP Service primitives....................................8
3.2.3 Mapping TCP as a Network Service Provider.................8
Pouffary & Young Standards Track [Page 1]
RFC 2126 ISO Transport on top of TCP March 1997
3.2.3.1 Network Connection Establishment........................8
3.2.3.2 Network Data Transfer...................................9
3.2.3.3 Network Connection Release.............................10
4. Transport Protocol Specification............................10
4.1 Class 0 over TCP...........................................10
4.1.1 Connection Establishment.................................11
4.1.2 Data Transfer............................................11
4.1.3 Connection Release.......................................11
4.2 Class 2 over TCP...........................................12
4.2.1 Connection Establishment.................................12
4.2.2 Data Transfer............................................13
4.2.3 Connection Release.......................................15
4.3 TPKT Packet Format.........................................15
5. Address representations.....................................16
5.1 String representation of ITOT access point addresses.......17
5.2 OSI Network Address encoding...............................17
6. Notes to Implementors.......................................17
6.1 TCP Connection Establishment...............................17
6.2 TCP Data transfer..........................................17
6.3 Class negotiation..........................................18
6.4 Default maximum TPDU size..................................18
6.5 Class 0 TPDU bit encoding..................................18
6.6 Class 2 Options............................................19
6.7 Class 2 Expedited Data Acknowledgement.....................21
6.8 Class 2 Normal Data and Expedited Data handling............21
6.9 Class 2 Forward Connection procedure.......................22
6.10 TPKT......................................................22
7. Rationale - Interoperability with RFC1006...................22
8. Security Considerations.....................................23
Acknowledgements...............................................23
References.....................................................23
Authors' Addresses.............................................25
1. Introduction,
There are two basic approaches which can be taken when "porting"
applications to TCP/IP ([RFC793],[RFC791]) and IPv6 [IPV6]
environments. One approach is to port each individual
separately, developing local protocols on top of TCP. A
approach is based on the notion of layering the ISO Transport
over TCP/IP. This approach solves the problem for all
which use the ISO Transport Service. This document describes
second approach
The protocol described in this memo is based on the observation
both the Internet Protocol Suite and the ISO Protocol Suite
layered systems. A key aspect of the layering principle is that
layer-independence. The concept of layer-independence means that
Pouffary & Young Standards Track [Page 2]
RFC 2126 ISO Transport on top of TCP March 1997
one preserves the services offered by a particular layer (
Service-Provider) then the Service-User at that layer is
unaffected by changes in the underlying layers or by the
used within the layer
This document defines a Transport Service which appears to
identical to the Services and Interfaces offered by the ISO
Service Definition [ISO8072], but which will in fact implement
ISO Transport Protocol [ISO8073] on top of TCP/IP (IPv4 or IPv6),
rather than the ISO Network Service [ISO8348].
The basis of this document is STD35, RFC1006 [RFC1006] written
Marshall T. Rose and Dwight E. Cass and it defines two
classes of service. Transport Class 0 refines and supersedes
RFC1006 protocol and is aimed at preserving the RFC1006
base. Transport Class 2 defines a number of new features which
not provided in RFC1006, such as independence of Normal and
Data channels and Explicit Transport Disconnection. These
features are largely based on RFC1859 [RFC1859] and extend
applicability of RFC1006 to new groups of applications
This document specifies changes to the standards mentioned above
must be read in the context of the above mentioned standards. It
not be meaningful on its own
The 'well known' TCP port 102 is reserved for hosts which
the Protocol described in this document. Note that the Protocol
not mandate the use of TCP port 102 for all connections
2. The
This section describes the differences between the model used by
ISO Transport and that described in this document
2.1 ISO Transport
The ISO 8072 standard describes the ISO Transport Service
(TS). The ISO Transport Service Definition describes the
offered by the Transport Service Provider and the interfaces used
access these services
The ISO 8073 standard describes the ISO Transport
Specification (TP). The ISO Transport Protocol specifies
encoding rules and a number of classes of transport
procedure which can be used with different network Quality
Service
Pouffary & Young Standards Track [Page 3]
RFC 2126 ISO Transport on top of TCP March 1997
The ISO 8348 standard describes the ISO Network Service
(NS). The ISO Network Service Definition describes the
offered by the network service Provider and the interfaces used
access these services
The ISO Network Service specifies two type of service
- Connection Oriented Network Service (CONS
- ConnectionLess Network Service (CLNS
The ISO Transport Protocol specifies five classes of procedures
operating over CONS and one class of procedure when operating
CLNS
The relationship of these ISO standards is illustrated below
Transport Service
|
|-ISO Transport Service Definition [ISO8072]
|
+--------------------------------------------------+
| Transport Service Provider |
| ISO Transport Protocol Specification [ISO8073] |
+--------------------------------------------------+
|
|-ISO Network Service Definition [ISO8348]
|
2.2 ISO Transport over TCP (ITOT)
This document defines a model which provides ISO Transport Service
with minor extensions, running over TCP
The ISO 8072 Transport Service is supported with minor modifications
See section 3.1.
The ISO 8073 Transport Protocol with some modifications is used
provide the modified Transport Service
The Transmission Control Protocol is used in place of the ISO 8348
provide a CONS like service. See section 4.
This document specifies a simple encapsulation mechanism between
modified ISO 8073 Transport Protocol and the TCP
Pouffary & Young Standards Track [Page 4]
RFC 2126 ISO Transport on top of TCP March 1997
ISO 8073 Transport Protocol specifies five classes when
over ISO 8348 CONS. This document specifies how to operate class 0
and 2 over TCP. This document does not prevent use of other
from operating over TCP, but their specification is beyond the
of this document
The relationship of these standards is illustrated below
Transport Service
|
|-ISO Transport Service (modified
|
+--------------------------------------------------+
| Transport Service Provider |
| ISO Transport Protocol (modified) Specification |
+--------------------------------------------------+
|
|-TCP as a Connection Oriented Network
|
2.3 Overview of Protocol and
This document defines use of the ISO Transport Protocol (with
extensions) running over TCP. Two variants of the protocol
defined, "Class 0 over TCP" and "Class 2 over TCP", which are
closely on the ISO Transport Class 0 and 2 Protocol
Section 3 defines the Service offered to the Transport User by
protocol, and shows the differences from the ISO Transport Service
The mapping between the Service primitives in the ISO Network
and TCP are defined. Section 4 defines the Transport Protocol
3 Service
This section describes the Transport Service offered to the
User. It also defines the mapping between the Network
Definition and the TCP Service Definition
3.1 Transport Service
ISO 8072 Transport Service is supported with the
extensions
- Use of Quality of Service parameter is not
- Access to Non-disruptive Transport
Pouffary & Young Standards Track [Page 5]
RFC 2126 ISO Transport on top of TCP March 1997
3.1.1 Transport Service Definition
Information is transferred to and from the TS-User in the
Service primitives listed below
T-CONNECT.
- a TS-User indicates that it wants to establish
T-CONNECT.
- a TS-User indicates that it will honour the
T-DISCONNECT.
- a TS-User indicates that the transport connection is
be
T-DATA.
- a TS-User sends
T-EXPEDITED DATA.
- a TS-User sends "expedited"
T-CONNECT.
- a TS-User is notified that a transport
establishment is in
T-CONNECT.
- a TS-User is notified that the transport connection has
T-DISCONNECT.
- a TS-User is notified that the transport connection is
T-DATA.
- a TS-User is notified that data can be read from the
T-EXPEDITED_DATA.
- a TS-User is notified that expedited data can be read
the transport
Pouffary & Young Standards Track [Page 6]
RFC 2126 ISO Transport on top of TCP March 1997
3.2 Network Service
This section describes how TCP is used to provide ISO 8348 CONS
3.2.1 ISO 8348 CONS
Information is transferred to and from the NS-provider in the
Service Primitives listed below
N-CONNECT.
- a NS-user indicates that it wants to establish a
N-CONNECT.
- a NS-user indicates that it will honour the
N-DISCONNECT.
- a NS-user indicates that the network connection is to
N-DATA.
- a NS-user sends
N-EXPEDITED_DATA.
- a NS-user sends "expedited"
N-CONNECT.
- a NS-user is notified that a network connection
is in
N-CONNECT.
- a NS-user is notified that the network connection has
N-DISCONNECT.
- a NS-user is notified that the network connection is
N-DATA.
- a NS-user is notified that data can be read from the
N-EXPEDITED_DATA.
- a NS-user is notified that expedited data can be read
the
Pouffary & Young Standards Track [Page 7]
RFC 2126 ISO Transport on top of TCP March 1997
3.2.2 TCP Service
The mapping between, ISO 8348 CONS primitives and TCP
primitives, defined in this document assumes that the TCP offers
following service primitives
TCP-LISTEN_
- PASSIVE open on given
TCP-OPEN_
- ACTIVE open to the given
TCP-READ_
- data is read from the
TCP-SEND_
- data is sent on the
TCP-
- the connection is closed (pending data is sent
TCP-
- open succeeded (either ACTIVE or PASSIVE
TCP-CONNECT_
- ACTIVE open
TCP-DATA_
- Data can be read from the
TCP-
- the connection has errored and is now
TCP-
- an orderly disconnection has
3.2.3 Mapping TCP as a Network Service
3.2.3.1 Network Connection
In order to perform a N-CONNECT.REQUEST action, the TS-
performs a TCP-OPEN_PORT to the desired IPv4 or IPv6 address
the selected TCP port. When the TCP signals either success
failure, this results in an N-CONNECT.INDICATION action
Pouffary & Young Standards Track [Page 8]
RFC 2126 ISO Transport on top of TCP March 1997
In order to await a N-CONNECT.INDICATION event, a server performs
TCP-LISTEN_PORT to the selected TCP port. When a client
connects to this port, the TCP-CONNECTED event occurs and an
N-CONNECT.RESPONSE action is performed
Mapping parameters between the TCP service and the ISO 8348
service is done as follow
Network Service
--------------- ---
CONNECTION
Called address server's IPv4 or IPv6
and TCP port number
Calling address client's IPv4 or IPv6
all others parameters
Please also refer to 'Notes to Implementors' section 6.1.
TCP port 102 is reserved for implementations conforming to
specification. Use of any TCP port is conformant to
specification
3.2.3.2 Network Data
In order perform a N-DATA.REQUEST action, the TS-provider
the desired transport protocol data unit (TPDU), encapsulates
TPDU in a discrete unit called TPKT and uses the TCP-SEND_
primitive. Please also refer to 'Notes to Implementors' section 6.2.
In order to trigger a N-DATA.INDICATION action, the TCP
that data is ready through TCP-DATA_READY event and a TPKT is
using the TCP-READ_DATA primitive
Mapping parameters between the TCP service and the ISO 8348
service is done as follow
Network Service
--------------- ---
DATA
NS User Data (NSDU)
Pouffary & Young Standards Track [Page 9]
RFC 2126 ISO Transport on top of TCP March 1997
3.2.3.3 Network Connection
In order to perform an N-DISCONNECT.REQUEST action, the TS-
simply closes the TCP connection through TCP-CLOSE primitive
In order to trigger a N-DISCONNECT.INDICATION, the TCP indicates
the connection has been closed through TCP-CLOSE event. If the
connection has failed the TCP indicates that the connection has
closed through TCP-ERRORED event, this trigger a N
DISCONNECT.INDICATION
Mapping parameters between the TCP service and the ISO 8348
service is done as follow
Network Service
--------------- ---
CONNECTION
all parameters
4. Transport Protocol
ISO 8073 Transport Protocol Classes 0 and 2 are supported
extensions as defined in each subsections below
A Transport Protocol class is selected for a particular
connection based on the requirements of the TS-User
ISO 8073 Transport Protocol exchanges information between peers
discrete units of information called transport protocol data
(TPDU). The protocol defined in this document encapsulates
TPDUs in discrete units termed Packets (TPKT).
This document mandates the implementation of ISO 8073
Protocol options negotiation (which includes class negotiation).
Please refer to 'Notes to Implementors' section 6.3 with respect
Class negotiation and to the 'Rationale' section 7. with respect
Interoperability with RFC1006.
4.1 Class 0 over
Class 0 provides the functions needed for connection
with negotiation, data transfer with segmentation, and protocol
reporting. It provides Transport Connection with flow control
on that of the NS-provider (TCP). It provides
Disconnection based on the NS-provider Disconnection
Pouffary & Young Standards Track [Page 10]
RFC 2126 ISO Transport on top of TCP March 1997
Class 0 is suitable for data transfer with no Explicit
Disconnection
4.1.1 Connection
The principles used in connection establishment are based upon
described in ISO 8073, with the following extensions
- Connect Data may be exchanged using the user data
of Connect Request (CR) and Connect Confirm (CC)
- Use of "Expedited Data Transfer Service" may be
using the negotiation mechanism specified in ISO 8073.
default is to not use "Expedited Data Transfer Service".
- Non-standard TPDU size may be negotiated using the
mechanism specified in ISO 8073. The maximum TPDU size is 65531
octets. The Default maximum TPDU size is 65531 octets
Please refer to 'Notes to Implementors' section 6.4.
4.1.2 Data
The elements of procedure used during transfer are based upon
presented in ISO 8073, with the following extension
- Expedited Data may be supported (if negotiated during
establishment) by sending the defined Expedited Data (ED) TPDU
The ED TPDU is sent inband on the same TCP connection as all of
other TPDUs
To support Expedited Data a non-standard TPDU is defined. The
used for the ED TPDU is nearly identical to the format for the
Data (DT) TPDU. The only difference between ED TPDU and DT TPDU
that the value used for the TPDU code is ED and not DT. The size of
Expedited Data user data field is 1 to 16 octets
For TPDU bit encoding please refer to 'Notes to Implementors'
6.5.
4.1.3 Connection
The elements of procedure used during a connection release
identical to those presented in ISO 8073.
Transport Disconnection is based on the NS-provider (TCP
Disconnection and is therefore disruptive
Pouffary & Young Standards Track [Page 11]
RFC 2126 ISO Transport on top of TCP March 1997
4.2 Class 2 over
Class 2 provides the functions needed for connection
with negotiation, data transfer with segmentation, and protocol
reporting. It provides Transport Connection with flow control
on that of the NS-provider (TCP). It provides Explicit
Disconnection
Class 2 is suitable when independence of Normal and Expedited
channels are required or when Explicit Transport Disconnection
needed
4.2.1 Connection
The principles used in connection establishment are based upon
described in ISO 8073, with the following extensions
- Connection Request and Connection Confirmation TPDUs
negotiate use of "Transport Expedited Data Transfer" service
"Transport Expedited Data Transfer" service is
by setting bit 1 of the "Additional Option" parameter
and is negotiated using the mechanism specified in ISO 8073.
The default is to not use "Transport Expedited Data
Service".
- Connection Request and Connection Confirmation TPDUs
negotiate use of "Expedited Data Acknowledgement".
"Expedited Data Acknowledgement" is selected by
bit 6 of the "Additional Option" parameter, and
negotiated using the mechanism specified in ISO 8073.
The default is to not use "Expedited Data Acknowledgement
for Expedited Data transfer
- Connection Request and Connection Confirmation TPDUs
negotiate use of the "Non-blocking Expedited Data" service
"Non-blocking Expedited Data" is selected by
bit 7 of the "Additional Option" parameter, and
negotiated using the mechanism specified in ISO 8073.
The default is to not use the "Non-blocking
Data" service
- Connection Request and Connection Confirmation TPDUs
negotiate use of either "Forward Connection (
and Recombining)" or "Reverse Connection" procedure
Expedited Data transfer
Pouffary & Young Standards Track [Page 12]
RFC 2126 ISO Transport on top of TCP March 1997
Use of "Forward Connection" or use of "Reverse Connection
procedure is selected by setting bit 4 of the "
Option" parameter, and is negotiated using the
specified in ISO 8073.
The default is to use "Forward Connection" procedure
Expedited Data transfer
- Connection Request and Connection Confirmation TPDUs must
negotiate the use of "Explicit Flow Control".
- Non-standard TPDU size may be negotiated using the
mechanism specified in ISO 8073. The maximum TPDU size is 65531
octets. The default maximum TPDU size is 65531 octets
Please refer to 'Notes to Implementors' section 6.4.
In the absence of a Flow Control policy, the use of ISO 8073
Multiplexing procedure lead to degradation of the quality of service
The Protocol defined in this document does not
Multiplexing
For the values of the "Additional Option" parameter please refer
'Notes to Implementors' section 6.6.
For Class 2 options Profile please also refer to 'Notes
Implementors' section 6.6.
4.2.2 Data
The elements of procedure used during transfer are based upon
presented in ISO 8073, with the following extensions
- Expedited Data may be supported (if negotiated during
establishment) by sending Expedited Data (ED) TPDU
- "Expedited Data Acknowledgement" may be supported (if
during connection establishment) by sending Expedited
Acknowledgement (EA) TPDU
When using "Expedited Data Acknowledgement", ED TPDUs
acknowledgement, and once an ED TPDU is transmitted no
DT/ED TPDUs may be sent until the outstanding ED TPDU has
acknowledged
When non-use of "Expedited Data Acknowledgement" has
negotiated, ED TPDUs require no acknowledgement, and further DT/
TPDUs may be sent immediatly
Pouffary & Young Standards Track [Page 13]
RFC 2126 ISO Transport on top of TCP March 1997
Please refer to 'Notes to Implementors' section 6.7 and
6.8.
- "Non-blocking Expedited Data" service may be supported (
negotiated during connection establishment).
When using "Non-blocking Expedited Data" service, the sender of
ED TPDU shall send the ED TPDU on both the Normal Data
Expedited Data TCP connections. Transmission of subsequent DT
will not be interrupted. The receiver of ED TPDU counts how
ED TPDU it has seen on each TCP connection, and will only
to the TS-User the ED TPDU from the TCP connection with the
count
When non-use of "Non-blocking Expedited Data" has been negotiated
ED TPDUs will not be duplicated
Please refer to 'Notes to Implementors' section 6.7 and
6.8.
- For Expedited Data transfer, there are two
procedures for the establishment and assignment of the
Data TCP connection. Which one is used is negotiated
connection establishment
Both the "Forward Connection" procedure and "Reverse Connection
procedure guarantee independence of the Normal Data TCP
from the Expedited Data TCP connection. They also ensure that
busy Normal Data TCP connection cannot block an Expedited Data
connection
The Expedited Data TCP connection created by either procedure
be between the same pair of hosts as the Normal Data
connection, must not be shared among Transport Connections,
must remain established until the Transport Connection
terminated, at which time it must be closed
TCP connections created for Expedited Data transfer should also
the TCP primitives defined in this document
The Forward Connection (Splitting and Recombining) procedure
defined in ISO 8073. This procedure allows a transport
to make use of multiple TCP connections. Please refer to 'Notes
Implementors' section 6.9.
The Reverse Connection procedure is not defined in ISO 8073.
using the Reverse Connection procedure the initiator of a
Connection creates a Normal Data TCP connection using
Pouffary & Young Standards Track [Page 14]
RFC 2126 ISO Transport on top of TCP March 1997
arbitrarily-chosen local TCP port 'x' and a known remote TCP
(either the ITOT well-known port, or some other). The
listens for an incoming TCP connection on the TCP port 'x'.
responder of the Transport Connection must create a second
connection (to be used for Expedited Data) using an arbitrarily
chosen local TCP port 'y' and the remote TCP port 'x' , before
can issue a CC TPDU on the Normal Data TCP connection.
initiator need not listen for further TCP connections on port 'x
after the Expedited Data TCP connection is established
4.2.3 Connection
The elements of procedure used during a connection release are
upon those described in ISO 8073. A connection can be terminated
the TS-user in one of two ways
- Disruptive
- Non-Disruptive
Disconnect Request (DR) and Disconnect Confirm (DC) TPDUs
exchanged in both cases. The DR TPDU carries a Reason code
the reason for the Disconnection
Disruptive Disconnect specifies that all TPDUs still at the
are not required to be sent to the destination before the
is disconnected. The DR Reason code is normal (80 hex).
Non-Disruptive Disconnect specifies that all TPDUs already given
the local TS-provider must be delivered to the remote TS-user,
the connection is disconnected. The DR Reason code is normal (80 hex
with Additional Information parameter value set to 80 hex
4.3 TPKT Packet
A fundamental difference between the TCP and the ISO Network
expected by ISO Transport is that the TCP manages a continuous
of octets, with no explicit boundaries
ISO Transport expects information to be sent and delivered
discrete objects termed Network Service Data Units (NSDU).
ISO Transport allows combination of more than one TPDU inside
single NSDU for the purposes of discussion an NSDU is identical to
TPDU. Please refer to ISO 8073 for the valid set of
TPDUs
Pouffary & Young Standards Track [Page 15]
RFC 2126 ISO Transport on top of TCP March 1997
The protocol described by this memo uses a simple
scheme in order to delimit TPDU. Each packet (TPKT), is viewed as
object of variable length composed of an integral number of octets
A TPKT consists of two part
- a Packet
- a TPDU
The format of the Packet Header is constant regardless of the type
TPDU. The format of the Packet Header is as follows
+--------+--------+----------------+-----------....---------------+
|version |reserved| packet length | TPDU |
+----------------------------------------------....---------------+
<8 bits> <8 bits> < 16 bits > < variable length >
where
- Protocol Version
length: 8
Value: 3
-
length: 8
Value: 0 - (See 'Notes to Implementors' section 6.10)
- Packet
length: 16
Value: Length of the entire TPKT in octets, including
-
ISO Transport TPDU as defined in ISO 8073 and as defined in
document
5. Address
It is desirable to be able to represent ITOT access point
as
- Printable
- OSI Network Addresses (often known as NSAP
or simply NSAPAs
This section defines the formats which MUST be used in each case
Pouffary & Young Standards Track [Page 16]
RFC 2126 ISO Transport on top of TCP March 1997
5.1 String representation of ITOT access point
RFC1278 [RFC1278] defines a general string representation for
Presentation Addresses, including specific reference to RFC1006
addresses which encapsulate IPv4 addresses. RFC1278 is
applicable to ITOT addresses which encapsulate IPv4 addresses
This RFC is currently being updated to define a string
for ITOT addresses which encapsulate IPv6 addresses
ITOT access point address string representation specify an IP
(IPv4 or IPv6) and an optional TCP port number
5.2 OSI Network Address
RFC1277 [RFC1277] defines a general mechanism to encode
information within OSI Network Addresses (NSAPA), including
reference to RFC1006 using IPv4. RFC1277 is also applicable to
addresses using IPv4.
The RFC "IPv6 addresses inside an NSAPA" [IPv6] defines
mechanisms for the support of NSAP addressing in an IPv6 network.
also defines how to embed an IPv6 address inside a OSI NSAP address
This RFC is applicable to ITOT addresses using IPv6. For
addresses, the default selector of the NSAPA is defined to have
value '10000000'B
It should be noted that given that an IPv6 addresses can encode IPv
addresses, this format can also encode ITOT addresses using IPv4.
6. Notes to
6.1 TCP Connection
Implementors should be aware that ISO transport protocols assume
they will be told by the network service provider (in this
TCP/IP) when the network connection being used to transmit
TPDUs is unexpectedly terminated. It is therefore strongly
that the TCP keep alive mechanism be selected, as this
reporting of network connection loss
6.2 TCP Data
For performance reason it is suggested that the Nagle algorithm [
896] be disabled (using the TCP_NODELAY socket option). This
allows TPKT data to be sent without delay
Pouffary & Young Standards Track [Page 17]
RFC 2126 ISO Transport on top of TCP March 1997
6.3 Class
The principle used in Class negotiation is identical to
described in ISO 8073. Class and options are negotiated
Connection establishment. The choice made by the Transport
depend upon the TS-User requirements as expressed via T-
service primitives
The initiator of the Transport Connection proposes a preferred
and may propose an alternative class
The responder selects one class defined in the table below
If the preferred class is not selected then on receipt of the
confirm TPDU the initiator adjusts its operation according to
class selected
+---------------------------------------------+----------------------+
| Proposed in CR TPDU | CC TPDU |
| | |
|Preferred class | Alternative class | Response |
+--------------------+------------------------+----------------------+
| | | |
|class 0 | none | class 0 |
| | | |
|class 2 | class 0 | class 2 or 0 |
| | | |
|class 2 | none | class 2 |
| | | |
+---------------------------------------------+----------------------+
6.4 Default maximum TPDU
The default maximum TPDU size value specified in this document
ISO Transport negotiation rule which states that the maximum
size specified or defaulted by the CC TPDU cannot be greater than
maximum TPDU size proposed by the CR TPDU
To avoid the consequences of this, it is strongly recommended
the CC TPDU always specifies the maximum TPDU size value
6.5 Class 0 TPDU bit
This protocol no longer allows credit and TPDU-NR (bits 0 to 6)
fields to be ignored on input, which is in line with ISO 8073
encoding rules. RFC1006 TPDU encoding defined inconsistent
rules
Pouffary & Young Standards Track [Page 18]
RFC 2126 ISO Transport on top of TCP March 1997
6.6 Class 2
Class 2 Additional Option parameter
+--------------------------------------------------------------------+
| BIT | OPTION |
+--------------------------------------------------------------------+
| | |
| 8 | Not applicable |
| | |
| 7 | = 1 Use of Non-blocking Expedited Data |
| | = 0 Non-use of Non-blocking Expedited Data (default) |
| | |
|(*) 6 | = 1 Use of Expedited Data Acknowledgement |
| | = 0 non-use of Expedited Data Acknowledgement (default) |
| | |
| 5 | Not applicable |
| | |
|(*) 4 | = 1 Use of Reverse Connection procedure |
| | = 0 Use of Forward Connection procedure (default) |
| | |
| 3 | Not applicable |
| | |
| 2 | Not applicable |
| | |
| 1 | = 1 Use of Transport Expedited Data Service |
| | = 0 Non-use of Transport Expedited Data Service (default) |
| | |
+--------------------------------------------------------------------+
(*) In ISO 8073, bit 4 is defined as use of "Network Expedited"
bit 6 is defined as "Request Acknowledgement".
Pouffary & Young Standards Track [Page 19]
RFC 2126 ISO Transport on top of TCP March 1997
Class 2 Options
+--------------------------------------------------------------------+
| Bits Service selected |
| 1 4 6 7 |
+--------------------------------------------------------------------+
| 0 x x x Non-use of Transport Expedited Data Service |
| ---------------------------------------------------------|
| Bits 4 6 7 are not applicable (*) |
+--------------------------------------------------------------------+
| 1 x x x Use of Transport Expedited Data Service |
| ---------------------------------------------------------|
| 1 0 x x Use of Expedited Data Service with Forward Connection
| -----------------------------------------------------|
| 1 0 1 0 Forward Connection with Expedited Data |
| Acknowledgement |
| 1 0 1 1 Forward Connection with Expedited Data |
| Acknowledgement and use of Non-blocking |
| Expedited Data (**) |
| --------------------------------------------|
| 1 0 0 0 Forward Connection with non-use of Expedited
| Data Acknowledgement (***) |
| 1 0 0 1 Forward Connection with non-use of Expedited
| Data Acknowledgement and use of Non-blocking
| Expedited Data |
| -----------------------------------------------------|
| 1 1 x x Use of Expedited Data Service with Reverse Connection
| -----------------------------------------------------|
| 1 1 1 0 Reverse Connection with Expedited Data |
| Acknowledgement |
| 1 1 1 1 Reverse Connection with Expedited Data |
| Acknowledgement and use of Non-blocking |
| Expedited Data (**) |
| --------------------------------------------|
| 1 1 0 0 Reverse Connection with non-use of Expedited
| Data Acknowledgement (***) |
| 1 1 0 1 Reverse Connection with non-use of Expedited
| Data Acknowledgement and use of Non-blocking
| Expedited Data |
+--------------------------------------------------------------------+
(*) Note the default (0000) provides an RFC1006-like service
Explicit Transport Disconnection
(**) Note in this case use of Expedited Data Acknowledgement with
of Non-blocking Expedited Data is a wasted effort (See section 6.5)
Pouffary & Young Standards Track [Page 20]
RFC 2126 ISO Transport on top of TCP March 1997
(***) Note in this case Normal and Expedited Data TPDU are
synchronised. (See section 6.6)
6.7 Class 2 Expedited Data
The Protocol specified in this document does not define
relationship between use of "Expedited Data Acknowledgement"
and use of "Non-blocking Expedited Data" service
However please note that when using "Non-blocking Expedited Data
service it is a wasted effort to use "Expedited
Acknowledgement", since ED TPDUs are duplicated and sent on both
Normal Data and Expedited Data TCP connections
6.8 Class 2 Normal Data and Expedited Data
There exist two separate application requirements for using
Data
1- Synchronisation of the order of delivery between
and Expedited Data TPDU
2- Independence of Normal and Expedited data channels. A
Normal Data channel should not block an Expedited Data channel
The protocol described in this document can accommodate
requirements, separately or in combination
Synchronisation
If synchronised order of delivery between Normal and
Data TPDU is required then use of either "Expedited
Acknowledgement" TPDU or use of the "Non-blocking Expedited Data
service must be negotiated during connection establishment
If synchronised order of delivery between Normal and
Data TPDU is not required then non-use of "Expedited
Acknowledgement" need not be negotiated during
establishment
Independence
If Independence of Normal and Expedited data channels is
then Forward or Reverse connection must be negotiated
connection establishment. Expedited data TPDU must be sent on
Expedited data channel
Pouffary & Young Standards Track [Page 21]
RFC 2126 ISO Transport on top of TCP March 1997
If Independence of Normal and Expedited data channels is
required then Forward connection should be negotiated
connection establishment and the Expedited data channels
never be established. Expedited data TPDU is then sent inband
the Normal data channel
Finally please note that independence of Normal and Expedited
channels without synchronisation relaxes the Transport
definition of Expedited data and is not consistent with ISO 8072.
6.9 Class 2 Forward Connection
As defined in ISO 8073, when "Forward Connection" (Splitting
Recombining) procedure is used for Expedited Data transmission,
TPDU must only be sent over an outgoing NS-provider TCP connection
As defined in ISO 8073, this document does not mandates use of
Splitting procedure for Expedited Data transmission.
Recombination procedure, which associates Data (normal and expedited
TPDUs arriving for a transport connection over two TCP
must be handled
It is legal to send Expedited Data TPDU inband on the Normal Data
connection
Please note that the protocol specified in this document does
define when an Expedited Data TCP connection should be established
This is an implementation choice
When using "Non-blocking Expedited Data" service it is recommended
not delay establishing Expedited Data TCP connection
6.10
This document specifies the value of the TPKT reserved field
Implementation should not interpret and act upon any value in
reserved field. To avoid Interoperability issues with RFC1006,
field should be ignored on input
7. Rationale - Interoperability with RFC1006
We have chosen to maintain the same TPKT protocol version in ITOT
in RFC1006 (version 3). The reason for this decision is that
changes in this document do not conflict with RFC1006. If we were
change the protocol version we would prevent existing RFC1006
implementations which mandate version 3 from interoperating with
protocol defined in this document
Pouffary & Young Standards Track [Page 22]
RFC 2126 ISO Transport on top of TCP March 1997
One consequence of this decision relates to class negotiation.
protocol described in this document introduces Class 2 over TCP,
it therefore introduces the need to be able to perform
negotiation between Class 2 and Class 0. While all
implementations should be able to handle Class negotiation,
recognise that some RFC1006 implementations cannot.
Implementors should be aware that Class 2 Connect Request (with
Alternative class) could be accepted with a Class 0 Connect Confirm
at which point the Connect Confirm should be rejected as specified
ISO 8073.
8. Security
Security issues are not specifically addressed in this document
Operation of this protocol is no more and no less secure
operation of TCP and ISO 8073 protocols. The reader is directed
for further reading
The authors are pleased to acknowledge the suggestions and
of Harald T. Alvestrand, Jim Bound, John Day, Mike Dyer,
Furniss, Dan Harrington, Steve Kille, Keith G. Knightson,
Sklower, Matt Thomas, Robert Watson and many other members of
IETF TOSI mailing list. The support of Allison Mankin of the IESG
essential
[ISO8072] ISO. "International Standard 8072. Information
Systems - Open Systems Interconnection: Transport
Definition."
[ISO8073] ISO. "International Standard 8073. Information
Systems - Open Systems Interconnection: Transport
Specification." ISO 8073:1992 and 8073:1992/Amd.5:1995.
[ISO8348] ISO. "International Standard 8348. Information
Systems - Open Systems Interconnection: Network
Definition."
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
Pouffary & Young Standards Track [Page 23]
RFC 2126 ISO Transport on top of TCP March 1997
[RFC896] Nagle, J., "Congestion Control in IP/TCP Inertnetworks",
RFC 896, January 1984.
[RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top
the TCP Version 3", STD 35, RFC 1006, May 1987.
[RFC1277] Hardcastle-Kille, S., "Encoding Network Addresses
support operation over non-OSI lower layers", RFC 1277,
November 1991.
[RFC1278] Hardcastle-Kille, S., "String encoding of
Address", RFC 1278, November 1991.
A string encoding of Presentation
update to RFC1278, Work in Progress
[RFC1859] Pouffary, Y., "ISO Transport Class 2 Non-use of
Flow Control over TCP - RFC1006 extension", RFC 1859,
October 1995.
[IPV6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 1883, December 1995.
Hinden,, R., and S. Deeing, "IP Version 6
Architecture", RFC 1884, December 1995.
Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
Pouffary & Young Standards Track [Page 24]
RFC 2126 ISO Transport on top of TCP March 1997
Authors'
Yanick
End Systems
Digital Equipment
Centre Technique (Europe
B.P. 027
950 Routes des
06901 Sophia antipolis,
Phone: +33 92-95-62-85
Fax: +33 92-95-62-35
EMail: pouffary@taec.enet.dec.
Alan
ISODE
The
The
Richmond,
Phone: +44 181 332 9091
Fax: +44 181 332 9019
EMail: A.Young@isode.
Pouffary & Young Standards Track [Page 25]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
