As per Relevance of the word transport, we have this rfc below:
M. Rose & D. Cass [Page 1]
Network Working Group Marshall T. Rose, Dwight E.
Request for Comments: RFC 1006 Northrop Research and Technology
Obsoletes: RFC 983 May 1987
ISO Transport Service on top of the
Version: 3
Status of this
This memo specifies a standard for the Internet community.
on the Internet that choose to implement ISO transport
on top of the TCP are expected to adopt and implement
standard. TCP port 102 is reserved for hosts which implement
standard. Distribution of this memo is unlimited
This memo specifies version 3 of the protocol and
[RFC983]. Changes between the protocol as described in Request
Comments 983 and this memo are minor, but are
incompatible
M. Rose & D. Cass [Page 1]
RFC 1006 May 1987
1. Introduction and
The Internet community has a well-developed, mature set
transport and internetwork protocols (TCP/IP), which are
successful in offering network and transport services
end-users. The CCITT and the ISO have defined various session
presentation, and application recommendations which have
adopted by the international community and numerous vendors
To the largest extent possible, it is desirable to offer
higher level directly in the ARPA Internet, without
existing facilities. This permits users to develop
with ISO and CCITT applications which previously were
available in the ARPA Internet. It also permits a
graceful convergence and transition strategy
TCP/IP-based networks to ISO-based networks in
medium-and long-term
There are two basic approaches which can be taken when "porting
an ISO or CCITT application to a TCP/IP environment.
approach is to port each individual application separately
developing local protocols on top of the TCP. Although this
useful in the short-term (since special-purpose interfaces to
TCP can be developed quickly), it lacks generality
A second approach is based on the observation that both the
Internet protocol suite and the ISO protocol suite are
layered systems (though the former uses layering from a
pragmatic perspective). A key aspect of the layering
is that of layer-independence. Although this section
redundant for most readers, a slight bit of background
is necessary to introduce this concept
Externally, a layer is defined by two definitions
a service-offered definition, which describes the
provided by the layer and the interfaces it provides
access those services; and
a service-required definitions, which describes the
used by the layer and the interfaces it uses to access
services
Collectively, all of the entities in the network which co-
to provide the service are known as the service-provider
Individually, each of these entities is known as a service-peer
Internally, a layer is defined by one definition
a protocol definition, which describes the rules which
service-peer uses when communicating with other service-peers
M. Rose & D. Cass [Page 2]
RFC 1006 May 1987
Putting all this together, the service-provider uses the
and services from the layer below to offer the its service to
layer above. Protocol verification, for instance, deals
proving that this in fact happens (and is also a fertile
for many Ph.D. dissertations in computer science).
The concept of layer-independence quite simply is
IF one preserves the services offered by the service-
THEN the service-user is completely naive with respect to
protocol which the service-peers
For the purposes of this memo, we will use the layer-
to define a Transport Service Access Point (TSAP) which
to be identical to the services and interfaces offered by
ISO/CCITT TSAP (as defined in [ISO8072]), but we will in
implement the ISO TP0 protocol on top of TCP/IP (as defined
[RFC793,RFC791]), not on top of the the ISO/CCITT
protocol. Since the transport class 0 protocol is used over
TCP/IP connection, it achieves identical functionality
transport class 4. Hence, ISO/CCITT higher level layers (
session, presentation, and application entities) can
fully without knowledge of the fact that they are running on
TCP/IP internetwork
M. Rose & D. Cass [Page 3]
RFC 1006 May 1987
2.
In migrating from the use of TCP/IP to the ISO protocols,
are several strategies that one might undertake. This memo
written with one particular strategy in mind
The particular migration strategy which this memo uses is
on the notion of gatewaying between the TCP/IP and ISO
suites at the transport layer. There are two strong
for this approach
1. Experience teaches us that it takes just as long to get
implementations of the lower level protocols as it takes to
implementations of the higher level ones. In particular, it
been observed that there is still a lot of work being done at
ISO network and transport layers. As a result,
of protocols above these layers are not being
pursued. Thus, something must be done "now" to provide a
in which the higher level protocols can be developed.
TCP/IP is mature, and essentially provides
functionality, it is an ideal medium to support this development
2. Implementation of gateways at the IP and ISO IP layers
probably not of general use in the long term. In effect,
would require each Internet host to support both TP4 and TCP
As such, a better strategy is to implement a graceful
path from TCP/IP to ISO protocols for the ARPA Internet when
ISO protocols have matured sufficiently
Both of these arguments indicate that gatewaying should occur
or above the transport layer service access point. Further,
first argument suggests that the best approach is to perform
gatewaying exactly AT the transport service access point
maximize the number of ISO layers which can be developed
NOTE: This memo does not intend to act as a migration
intercept document. It is intended ONLY to meet
needs discussed above. However, it would not
unexpected that the protocol described in this
might form part of an overall transition plan.
description of such a plan however is
beyond the scope of this memo
Finally, in general, building gateways between other layers in
TCP/IP and ISO protocol suites is problematic, at best
To summarize: the primary motivation for the standard described
this memo is to facilitate the process of gaining experience
higher-level ISO protocols (session, presentation,
application). The stability and maturity of TCP/IP are ideal
M. Rose & D. Cass [Page 4]
RFC 1006 May 1987
providing solid transport services independent of
implementation
M. Rose & D. Cass [Page 5]
RFC 1006 May 1987
3. The
The [ISO8072] standard describes the ISO transport
definition, henceforth called TP
ASIDE: This memo references the ISO specifications
than the CCITT recommendations. The
between these parallel standards are quite small
and can be ignored, with respect to this memo
without loss of generality. To provide the
with the relationships
Transport service [ISO8072] [X.214]
Transport protocol [ISO8073] [X.224]
Session protocol [ISO8327] [X.225]
The ISO transport service definition describes the
offered by the TS-provider (transport service) and the
used to access those services. This memo focuses on how the
Transmission Control Protocol (TCP) [RFC793] can be used to
the services and provide the interfaces
+-----------+ +-----------+
| TS-user | | TS-user |
+-----------+ +-----------+
| |
| TSAP interface TSAP interface |
| [ISO8072] |
| |
+----------+ ISO Transport Services on the TCP +----------+
| client |-----------------------------------------| server |
+----------+ (this memo) +----------+
| |
| TCP interface TCP interface |
| [RFC793] |
| |
For expository purposes, the following abbreviations are used
TS-peer a process which implements the protocol
by this
TS-user a process talking using the services of a TS-
M. Rose & D. Cass [Page 6]
RFC 1006 May 1987
TS-provider the black-box entity implementing the
described by this
For the purposes of this memo, which describes version 2 of
TSAP protocol, all aspects of [ISO8072] are supported with
exception
Quality of Service
In the spirit of CCITT, this is left "for further study".
future version of the protocol will most likely support the
parameters for TP by mapping these onto various TCP parameters
The ISO standards do not specify the format of a session
(termed a TSAP ID). This memo mandates the use of the
specification [GOSIP86] for the interpretation of this field
(Please refer to Section 5.2, entitled "UPPER LAYERS ADDRESSING".)
Finally, the ISO TSAP is fundamentally symmetric in behavior
There is no underlying client/server model. Instead of a
listening on a well-known port, when a connection is established
the TS-provider generates an INDICATION event which,
the TS-user catches and acts upon. Although this might
implemented by having a server "listen" by hanging on
INDICATION event, from the perspective of the ISO TSAP, all TS
users just sit around in the IDLE state until they either
a REQUEST or accept an INDICATION
M. Rose & D. Cass [Page 7]
RFC 1006 May 1987
4. The
The protocol assumes that the TCP[RFC793] offers the
service primitives
connected - open succeeded (either ACTIVE or PASSIVE
connect fails - ACTIVE open
data ready - data can be read from the
errored - the connection has errored and is now
closed - an orderly disconnection has
listen on port - PASSIVE open on the given
open port - ACTIVE open to the given
read data - data is read from the
send data - data is sent on the
close - the connection is closed (pending data
sent
This memo describes how to use these services to emulate the
service primitives, which are required by [ISO8073]:
N-CONNECT.
- An NS-user (responder) is notified
connection establishment is in
N-CONNECT.
- An NS-user (responder) is notified
the connection has been
N-DATA.
- An NS-user is notified that data can
read from the
M. Rose & D. Cass [Page 8]
RFC 1006 May 1987
N-DISCONNECT.
- An NS-user is notified that the
is
N-CONNECT.
- An NS-user (initiator) indicates that
wants to establish a
N-CONNECT.
- An NS-user (responder) indicates that
will honor the
N-DATA.REQUEST - An NS-user sends
N-DISCONNECT.
- An NS-user indicates that the
is to be
The protocol offers the following service primitives, as
in [ISO8072], to the TS-user
T-CONNECT.
- a TS-user (responder) is notified
connection establishment is in
T-CONNECT.
- a TS-user (initiator) is notified that
connection has been
T-DATA.
- a TS-user is notified that data can be
from the
T-EXPEDITED DATA.
- a TS-user is notified that "expedited"
can be read from the
T-DISCONNECT.
- a TS-user is notified that the
is
M. Rose & D. Cass [Page 9]
RFC 1006 May 1987
T-CONNECT.
- a TS-user (initiator) indicates that
wants to establish a
T-CONNECT.
- a TS-user (responder) indicates that
will honor the
T-DATA.REQUEST - a TS-user sends
T-EXPEDITED DATA.
- a TS-user sends "expedited"
T-DISCONNECT.
- a TS-user indicates that the
is to be
M. Rose & D. Cass [Page 10]
RFC 1006 May 1987
5. The
The protocol specified by this memo is identical to the
for ISO transport class 0, with the following exceptions
- for testing purposes, initial data may be
during connection
- for testing purposes, an expedited data service
- for performance reasons, a much larger TSDU size
- the network service used by the protocol is
by the
The ISO transport protocol exchanges information between peers
discrete units of information called transport protocol data
(TPDUs). The protocol defined in this memo encapsulates
TPDUs in discrete units called TPKTs. The structure of
TPKTs and their relationship to TPDUs are discussed in the
section
The mapping between the TCP service primitives and the
primitives expected by transport class 0 are quite straight
forward
network service
--------------- ---
CONNECTION
N-CONNECT.REQUEST open
N-CONNECT.INDICATION listen (PASSIVE open
N-CONNECT.RESPONSE listen
N-CONNECT.CONFIRMATION open (ACTIVE open
DATA
N-DATA.REQUEST send
N-DATA.INDICATION data ready followed
M. Rose & D. Cass [Page 11]
RFC 1006 May 1987
read
CONNECTION
N-DISCONNECT.REQUEST
N-DISCONNECT.INDICATION connection closes
Mapping parameters is also straight-forward
network service
--------------- ---
CONNECTION
Called address server's IP
(4 octets
Calling address client's IP
(4 octets
all others
DATA
NS-user data (NSDU)
CONNECTION
all parameters
CONNECTION
The elements of procedure used during connection
are identical to those presented in [ISO8073], with
exceptions
In order to facilitate testing, the connection request
connection confirmation TPDUs may exchange initial user data
using the user data fields of these TPDUs
In order to experiment with expedited data services,
connection request and connection confirmation TPDUs
negotiate the use of expedited data transfer using
negotiation mechanism specified in [ISO8073] is used (e.g.,
setting the "use of transport expedited data transfer service
bit in the "Additional Option Selection" variable part).
default is not to use the transport expedited data
service
M. Rose & D. Cass [Page 12]
RFC 1006 May 1987
In order to achieve good performance, the default TPDU size
65531 octets, instead of 128 octets. In order to negotiate
smaller (standard) TPDU size, the negotiation
specified in [ISO8073] is used (e.g., setting the desired
in the "TPDU Size" variable part).
To perform an N-CONNECT.REQUEST action, the TS-peer
an active open to the desired IP address using TCP port 102.
When the TCP signals either success or failure, this
in an N-CONNECT.INDICATION action
To await an N-CONNECT.INDICATION event, a server listens
TCP port 102. When a client successfully connects to
port, the event occurs, and an implicit N-CONNECT.
action is performed
NOTE: In most implementations, a single server
perpetually LISTEN on port 102, handing
connections as they are
DATA
The elements of procedure used during data transfer are
to those presented in [ISO8073], with one exception:
data may be supported (if so negotiated during
establishment) by sending a modified ED TPDU (described below).
The TPDU is sent on the same TCP connection as all of the
TPDUs. This method, while not faithful to the spirit of [ISO8072],
is true to the letter of the specification
To perform an N-DATA.REQUEST action, the TS-peer constructs
desired TPKT and uses the TCP send data primitive
To trigger an N-DATA.INDICATION action, the TCP indicates
data is ready and a TPKT is read using the TCP read
primitive
CONNECTION
To perform an N-DISCONNECT.REQUEST action, the TS-peer simply
the TCP connection
If the TCP informs the TS-peer that the connection has been closed
has errored, this indicates an N-DISCONNECT.INDICATION event
M. Rose & D. Cass [Page 13]
RFC 1006 May 1987
6. Packet
A fundamental difference between the TCP and the network
expected by TP0 is that the TCP manages a continuous stream
octets, with no explicit boundaries. The TP0 expects
to be sent and delivered in discrete objects termed
service data units (NSDUs). Although other classes of
may combine more than one TPDU inside a single NSDU,
class 0 does not use this facility. Hence, an NSDU is
to a TPDU for the purposes of our discussion
The protocol described by this memo uses a simple
scheme in order to delimit TPDUs. Each packet, termed a TPKT,
viewed as an object composed of an integral number of octets,
variable length
NOTE: For the purposes of presentation, these objects
shown as being 4 octets (32 bits wide).
representation is an artifact of the style of
memo and should not be interpreted as
that a TPKT be a multiple of 4 octets in length
A TPKT consists of two parts: a packet-header and a TPDU.
format of the header is constant regardless of the type of packet
The format of the packet-header is as follows
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vrsn | reserved | packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
vrsn 8
This field is always 3 for the version of the protocol described
this memo
packet length 16 bits (min=7, max=65535)
This field contains the length of entire packet in octets
including packet-header. This permits a maximum TPDU size
65531 octets. Based on the size of the data transfer (DT) TPDU
this permits a maximum TSDU size of 65524 octets
The format of the TPDU is defined in [ISO8073]. Note that
TPDUs formatted for transport class 0 are exchanged (
transport classes may use slightly different formats).
M. Rose & D. Cass [Page 14]
RFC 1006 May 1987
To support expedited data, a non-standard TPDU, for expedited
is permitted. The format used for the ED TPDU is nearly
to the format for the normal data, DT, TPDU. The only
is that the value used for the TPDU's code is ED, not DT
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header length | code |credit |TPDU-NR and EOT| user data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
After the credit field (which is always ZERO on output and
on input), there is one additional field prior to the user data
TPDU-NR and EOT 8
Bit 7 (the high-order bit, bit mask 1000 0000) indicates the
of a TSDU. All other bits should be ZERO on output and ignored
input
Note that the TP specification limits the size of an
transport service data unit (XSDU) to 16 octets
M. Rose & D. Cass [Page 15]
RFC 1006 May 1987
7.
Since the release of RFC983 in April of 1986, we have gained
experience in using ISO transport services on top of the TCP.
September of 1986, we introduced the use of version 2 of
protocol, based mostly on comments from the community
In January of 1987, we observed that the differences
version 2 of the protocol and the actual transport class 0
definition were actually quite small. In retrospect,
realization took much longer than it should have: TP0 is is
to run over a reliable network service, e.g., X.25. The TCP can
used to provide a service of this type, and, if no one
too loudly, one could state that this memo really just describes
method for encapsulating TPO inside of TCP
The changes in going from version 1 of the protocol to version 2
and then to version 3 are all relatively small. Initially,
describing version 1, we decided to use the TPDU formats from
ISO transport protocol. This naturally led to the
described above
M. Rose & D. Cass [Page 16]
RFC 1006 May 1987
8.
[GOSIP86] The U.S. Government OSI User's Committee
"Government Open Systems Interconnection
(GOSIP) Specification for Fiscal years 1987
1988." (December, 1986) [draft status
[ISO8072] ISO
"International Standard 8072. Information
Systems -- Open Systems Interconnection:
Service Definition."
(June, 1984)
[ISO8073] ISO
"International Standard 8073. Information
Systems -- Open Systems Interconnection:
Protocol Specification."
(June, 1984)
[ISO8327] ISO
"International Standard 8327. Information
Systems -- Open Systems Interconnection:
Protocol Specification."
(June, 1984)
[RFC791] Internet Protocol
Request for Comments 791 (MILSTD 1777)
(September, 1981)
[RFC793] Transmission Control Protocol
Request for Comments 793 (MILSTD 1778)
(September, 1981)
[RFC983] ISO Transport Services on Top of the TCP
Request for Comments 983
(April, 1986)
[X.214] CCITT
"Recommendation X.214. Transport Service
for Open Systems Interconnection (OSI) for
Applications."
(October, 1984)
[X.224] CCITT
"Recommendation X.224. Transport
Specification for Open Systems Interconnection (OSI
for CCITT Applications." (October, 1984)
M. Rose & D. Cass [Page 17]
RFC 1006 May 1987
[X.225] CCITT
"Recommendation X.225. Session Protocol
for Open Systems Interconnection (OSI) for
Applications."
(October, 1984)
M. Rose & D. Cass [Page 18]
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
