As per Relevance of the word connection, we have this rfc below:
Network Working Group D. E. Cass (NRTC
Request for Comments: 983 M. T. Rose (NRTC
April 1986
ISO Transport Services on Top of the
Status of This
This memo describes a proposed protocol standard for the
Internet community. The intention is that hosts in the ARPA-
that choose to implement ISO TSAP services on top of the TCP
expected to adopt and implement this standard. Suggestions
improvement are encouraged. Distribution of this memo is unlimited
1. Introduction and
The ARPA Internet community has a well-developed, mature set
transport and internetwork protocols (TCP/IP), which are
successful in offering network and transport services to end-users
The CCITT and the ISO have defined various session, presentation,
application recommendations which have been adopted by
international community and numerous vendors. To the largest
possible, it is desirable to offer these higher level
directly in the ARPA Internet, without disrupting
facilities. This permits users to develop expertise with ISO
CCITT applications which previously were not available in the
Internet. It also permits a more graceful transition strategy
TCP/IP-based networks to ISO-based networks in the medium-
long-term
There are two basic approaches which can be taken when "porting"
ISO or CCITT application to a TCP/IP environment. One approach is
port each individual application separately, developing
protocols on top of the TCP. Although this is useful in
short-term (since special-purpose interfaces to the TCP can
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 both
systems (though the former uses layering from a more
perspective). A key aspect of the layering principle is that
layer-independence. Although this section is redundant for
readers, a slight bit of background material is necessary
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 to
those services; and
Cass & Rose [Page 1]
RFC 983 April 1986
ISO Transport Services on Top of the
a service-required definitions, which describes the services
by the layer and the interfaces it uses to access those services
Collectively, all of the entities in the network which co-operate
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
Putting all this together, the service-provider uses the protocol
services from the layer below to offer the its service to the
above. Protocol verification, for instance, deals with proving
this in fact happens (and is also a fertile field 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-independence
define a Transport Service Access Point (TSAP) which appears to
identical to the services and interfaces offered by the ISO/
TSAP (as defined in [ISO-8072]), but we will base the internals
this TSAP on TCP/IP (as defined in [RFC-793,RFC791]), not on
ISO/CCITT transport and network protocols. Hence, ISO/CCITT
level layers (all session, presentation, and application entities
can operate fully without knowledge of the fact that they are
on a TCP/IP internetwork
The authors hope that the preceding paragraph will not come as
shock to most readers. However, an ALARMING number of people seem
think that layering is just a way of cutting up a large problem
smaller ones, *simply* for the sake of cutting it up.
layering tends to introduce modularity into an architecture,
modularity tends to introduce sanity into implementations (
conceptual and physical implementations), modularity, per se, is
the end goal. Flexibility IS
Cass & Rose [Page 2]
RFC 983 April 1986
ISO Transport Services on Top of the
2.
In migrating from the use of TCP/IP to the ISO protocols, there
several strategies that one might undertake. This memo was
with one particular strategy in mind
The particular migration strategy which this memo uses is based
the notion of gatewaying between the TCP/IP and ISO protocol
at the transport layer. There are two strong arguments for
approach
a. Experience teaches us that it takes just as long to get
implementations of the lower level protocols as it takes to
good implementations of the higher level ones. In particular,
has been observed that there is still a lot of work being done
the ISO network and transport layers. As a result
implementations of protocols above these layers are not
aggressively pursued. Thus, something must be done "now"
provide a medium in which the higher level protocols can
developed. Since TCP/IP is mature, and essentially
identical functionality, it is an ideal medium to support
development
b. 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.
such, a better strategy is to implement a graceful migration
from TCP/IP to ISO protocols for the ARPA Internet when the
protocols have matured sufficiently
Both of these arguments indicate that gatewaying should occur at
above the transport layer service access point. Further, the
argument suggests that the best approach is to perform the
exactly AT the transport service access point to maximize the
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 the
discussed above. However, it would not be unexpected that
protocol described in this memo might form part of an
transition plan. The description of such a plan however
COMPLETELY 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
Cass & Rose [Page 3]
RFC 983 April 1986
ISO Transport Services on Top of the
this memo is to facilitate the process of gaining experience
higher-level ISO protocols (session, presentation, and application).
The stability and maturity of TCP/IP are ideal for providing
transport services independent of actual implementation
3. The
The [ISO-8072] standard describes the ISO transport
definition, henceforth called TP
ASIDE: This memo references the ISO specifications rather
the CCITT recommendations. The differences between these
standards are quite small, and can be ignored, with respect
this memo, without loss of generality. To provide the reader
the relationships
Transport service [ISO-8072] [X.214]
Transport protocol [ISO-8073] [X.224]
Session protocol [ISO-8327] [X.225]
The ISO transport service definition describes the services
by the TS-provider (transport service) and the interfaces used
access those services. This memo focuses on how the
Transmission Control Protocol (TCP) [RFC-793] can be used to
the services and provide the interfaces
+-------------+ +-------------+
| TS-user | | TS-user |
+-------------+ +-------------+
| |
| TSAP interface TSAP interface |
| [ISO-8072] |
| |
+------------+ ISO Transport Services on the TCP +------------+
| client |----------------------------------------| server |
+------------+ (this memo) +------------+
| |
| TCP interface TCP interface |
| [RFC-793] |
| |
For expository purposes, the following abbreviations are used
TS-peer a process which implements the
described by this
Cass & Rose [Page 4]
RFC 983 April 1986
ISO Transport Services on Top of the
TS-user a process talking using the services of
TS-
TS-provider the black-box entity implementing the
described by this
For the purposes of this memo, which describes version 1 of the
protocol, all aspects of [ISO-8072] are supported with one exception
Quality of Service
In the spirit of CCITT, this is left "for further study". Version 2
of the TSAP protocol will most likely support the QOS parameters
TP by mapping these onto various TCP parameters
Since TP supports the notion of a session port (termed a TSAP ID),
but the list of reserved ISO TSAP IDs is not clearly defined at
time, this memo takes the philosophy of isolating the TCP port
from the TSAP ID space and uses a single TCP port. This
reserves TCP port 102 for this purpose. This protocol manages
own TSAP ID space independent of the TCP. Appendix A of this
lists reserved TSAP IDs for version 1 of this TSAP protocol. It
expected that future editions of the "Assigned Numbers"
[RFC-960] will contain updates to this list. (Interested readers
encouraged to read [ISO-8073] and try to figure out exactly what
TSAP ID is.)
Finally, the ISO TSAP is fundamentally symmetric in behavior.
is no underlying client/server model. Instead of a server
on a well-known port, when a connection is established,
TS-provider generates an INDICATION event which, presumably
TS-user catches and acts upon. Although this might be implemented
having a server "listen" by hanging on the INDICATION event, from
perspective of the ISO TSAP, all TS-users just sit around in the
state until they either generate a REQUEST or accept an INDICATION
Cass & Rose [Page 5]
RFC 983 April 1986
ISO Transport Services on Top of the
4. The
The protocol assumes that the TCP [RFC-793] 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 is sent
The protocol offers the following service primitives, as defined
[ISO-8072], to the TS-user
T-CONNECT.
- a TS-user (server) is notified that connection
is in
T-DISCONNECT.
- a TS-user is notified that the connection is
T-CONNECT.
- a TS-user (client) is notified that the connection has
Cass & Rose [Page 6]
RFC 983 April 1986
ISO Transport Services on Top of the
T-DATA.
- a TS-user is notified that data can be read from
T-EXPEDITED DATA.
- a TS-user is notified that "expedited" data can be read
the
T-CONNECT.
- a TS-user (server) indicates that it will honor the
T-DISCONNECT.
- a TS-user indicates that the connection is to be
T-CONNECT.
- a TS-user (client) indicates that it wants to establish
T-DATA.
- a TS-user sends
T-EXPEDITED DATA.
- a TS-user sends "expedited"
Cass & Rose [Page 7]
RFC 983 April 1986
ISO Transport Services on Top of the
5. The
It is the goal of this memo to offer a TP interface on top of
TCP. Fortunately, the TCP does just about everything
TS-provider offers to the TS-user, so the hard parts of the
layer (e.g., three-way handshakes, choice of ISS, windowing
multiplexing, ad infinitum) are all taken care of by the TCP
Despite the symmetry of TP, it is useful to consider the
with the perspective of a client/server model
The information exchanged between TSAP-peers is in the form
packets termed "TPKT"s. The format of these packets is described
the next section. For the purposes of the description below, a
has a code which is one of
CR - request
CC - confirm
DR - request
DT -
ED - expedited
A TSAP server begins by LISTENing on TCP port 102. When a
client successfully connects to this port, the protocol begins
A client decides to connect to the port when a TS-user issues
T-CONNECT.REQUEST action. This action specifies the TSAP ID of
remote TS-user, whether expedited data is to be supported,
(optionally) some initial TS-user data. The client consults the
ID given to ascertain the IP address of the server. If the
data option was requested, the client opens a passive TCP port,
non-blocking mode, noting the port number. This TCP port is
the "expedited port". The client then tries to open a TCP
to the server on port 102. If not successful, the client
T-DISCONNECT.INDICATION for the TS-user specifying the reason
failure (and, closes the expedited port, if any). If successful,
client sends a TPKT with code CR containing
- the TSAP ID of the TS-user on the client's host (the "caller")
- the TSAP ID of the TS-user that the client wants to talk
(the "called")
- if the expedited data option was requested, the TSAP ID of
expedited port for the client's
- any TS-user data from the T-CONNECT.
The client now awaits a response
Cass & Rose [Page 8]
RFC 983 April 1986
ISO Transport Services on Top of the
The server, upon receipt of the TPKT, validates the contents of
TPKT (checking the version number, verifying that the code is CR,
so forth). If the packet is invalid, the server sends a TPKT
code DR specifying "PROTOCOL ERROR", closes the TCP connection,
goes back to the LISTEN state
If the packet is valid, the server examines the TSAP ID that
remote TS-user wants to communicate with. If the TS-user
can be located and started (e.g., the appropriate program
implements the indicated protocol is present), then the server
this TS-user by firing T-CONNECT.INDICATION. Otherwise, the
sends a TPKT with code DR specifying "SESSION ENTITY NOT ATTACHED
TSAP" or "REMOTE TRANSPORT ENTITY CONGESTED AT CONNECT REQUEST TIME
as appropriate, closes the TCP connection, and goes back to
LISTEN state
The server now waits for a T-CONNECT.RESPONSE or T-DISCONNECT.
from the TS-user it started. if the latter is given, the
sends a TPKT with code DR containing the reason for the disconnect
supplied by the TS-user
The server then closes the TCP connection and goes back to the
state
Instead, if T-CONNECT.RESPONSE is given, the server sees if
expedited port was specified in the connection request. If so,
server opens a second TCP connection and connects to the
port. If the connection fails, the server sends a TPKT with code
specifying "CONNECTION NEGOTIATION FAILED", closes the
connection, and goes back to the LISTEN state. If the
succeeded, the server notes the local port number used to connect
the expedited port
If an expedited port was not specified in the TPKT with code CR,
the server's TS-user indicates that it wants to use expedited data
then the server sends a TPKT with code DR specifying "
NEGOTIATION FAILED", fires T-DISCONNECT.INDICATION with this error
the TS-user, closes the TCP connection, and goes back to the
state
The server now sends a TPKT with code CC containing
- the TSAP ID of the TS-user responding to the
(usually the "called")
- if an expedited port was specified in the TPKT with code CR
Cass & Rose [Page 9]
RFC 983 April 1986
ISO Transport Services on Top of the
the TSAP ID of the port number on the server's host that
used to connect to the expedited
- any TS-user data from the T-CONNECT.
After sending the TPKT, the server enters the SYMMETRIC PEER state
The client, upon receipt of the TPKT, validates the contents of
TPKT (checking the version number, verifying that the code is CC
DR, and so forth). If the packet is invalid, the client sends a
with code DR specifying "PROTOCOL ERROR",
T-DISCONNECT.INDICATION with this error to the TS-user, and
the TCP connection (and the expedited port, if any).
If the packet's code is DR, the client fires T-DISCONNECT.
with the reason given in the TPKT to the TS-user, and closes the
connection (and the expedited port, if any).
If the packet's code is CC, the client checks if an expedited
was specified and that a connection is waiting on the expedited port
If not, a protocol error has occurred, a TPKT with code DR
returned, T-DISCONNECT.INDICATION is fired, and so on. Otherwise
the client checks the remote address that connected to the
port. If it differs from the port listed in the TPKT with code CC,
protocol error has occurred. Otherwise, all is well, two
connections have been established, one for all TPKTs except
data, and the second for the exclusive use of expedited data
The client now fires T-CONNECT.CONFIRMATION, and enters the
PEER state
Once both sides have reached the SYMMETRIC PEER state, the
is completely symmetric, the notion of client/server is lost.
TS-peers act in the following fashion
If the TCP indicates that data can be read, the TS-peer, upon
of the TPKT, validates the contents. If the packet is invalid,
TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR",
T-DISCONNECT.INDICATION with this error to the TS-user, and
the TCP connection (and expedited data connection, if any). If
TS-peer was the server, it goes back to the LISTEN state
NOTE: If the expedited data option was requested, then there
two TCP connections that can supply data for reading.
dialogue below assumes that only ED TPKTs are read from
expedited data connection. For simplicity's sake, when
from TCP the relation between connections and TPKTs is
and this memo URGES all implementations to be very lenient in
Cass & Rose [Page 10]
RFC 983 April 1986
ISO Transport Services on Top of the
regard. When writing to TCP, implementations should use
expedited data connection only to send TPKTs with code ED
Section 7 of this memo discusses the handling of expedited data
greater detail
If the packet's code is DR, the TS-peer fires T-DISCONNECT.
with the reason given in the TPKT to the TS-user, and closes the
connection (and expedited data connection, if any). If the TS-
was the server, it goes back to the LISTEN state
If the packet's code is ED or DT, the TS-peer fires T-DATA.
or T-EXPEDITED DATA.INDICATION as appropriate with the enclosed
data for the TS-user. It then goes back to the SYMMETRIC PEER state
If the packet is invalid, the TS-peer sends a TPKT with code
specifying "PROTOCOL ERROR", fires T-DISCONNECT.INDICATION with
error to the TS-user, and closes the TCP connection (and
data connection, if any). If the TS-peer was the server, it
back to the LISTEN state
If the TCP indicates that an error has occurred and the
has closed, then the TS-peer fires T-DISCONNECT.INDICATION to
TS-user specifying the reason for the failure. If the expedited
connection, if any, is still open, it is closed. If the TS-peer
the server, it goes back to the LISTEN state
If the TS-user issues a T-DATA.REQUEST or T-EXPEDITED DATA.
action, the TS-peer sends a TPKT with code DT or ED containing
TS-user data. It then goes back to the SYMMETRIC PEER state
If the TS-user issues a T-DISCONNECT.REQUEST action, the TS-
sends a TPKT with code DR containing the reason for the disconnect
supplied by the TS-user. The TS-peer then closes the TCP connection
(and expedited data connection, if any). If the TS-peer was
server, it goes back to the LISTEN state
In terms of (augmented) state tables, the protocol can be
as follows. The server starts in state S0, the client starts
state C0. "TCP:" refers to an event or action from the TCP service
"SS:" refers to an event or action from the TS-user (e.g., the
session service [ISO-8327]).
Cass & Rose [Page 11]
RFC 983 April 1986
ISO Transport Services on Top of the
S E R V E R S T A T E
state event action
----- ----- ------ ----
S0 TCP: listen on port 102 S
S1 TCP: connected TCP: read
parse, on
TCP: send DR, close S
code is
start session
SS: T-CONNECT S
.
otherwise
TCP: send DR, close S
S2 SS: T-CONNECT.RESPONSE if expedited option
TCP: open port
TCP: send CC P
S2 SS: T-DISCONNECT TCP: send DR, close S
.
Any event occuring for a state not listed above is considered
error, and handled thusly
state event action
----- ----- ------ ----
S* TCP: other if TCP is open, TCP: close S
otherwise ignore S
S* SS: other SS: T-
.
if TCP is open, close S
Cass & Rose [Page 12]
RFC 983 April 1986
ISO Transport Services on Top of the
C L I E N T S T A T E
state event action
----- ----- ------ ----
C0 SS: T-CONNECT.REQUEST if expedited option
TCP: non-
listen on port
TCP: open port 102 C
C1 TCP: connected TCP: send CR C
C1 TCP: connect fails TCP:
SS: T-DISCONNECT C
.
C2 TCP: data ready TCP: read
parse, on
TCP: send DR,
SS: T-DISCONNECT C
.
code is
if expedited option
verify port
connected correctly
if not, treat as
SS: T-CONNECT P
.
code is
TCP:
SS: T-DISCONNECT C
.
TCP: send DR,
SS: T-DISCONNECT C
.
Cass & Rose [Page 13]
RFC 983 April 1986
ISO Transport Services on Top of the
Any event occuring for a state not listed above is considered
error, and handled thusly
state event action
----- ----- ------ ----
C* TCP: other if TCP is open, close C
otherwise ignore C
C* SS: other SS: T-
.
if TCP is open, close C
Cass & Rose [Page 14]
RFC 983 April 1986
ISO Transport Services on Top of the
P E E R S T A T E
state event action
----- ----- ------ ----
P0 TCP: data ready TCP: read
parse, on
TCP: send DR,
SS: T-DISCONNECT
.
code is
SS: T-DATA.INDICATION P
code is
SS: T-EXPEDITED DATA P
.
code is
TCP:
SS: T-DISCONNECT
.
TCP: send DR,
SS: T-DISCONNECT
.
P0 TCP: other TCP:
SS: T-DISCONNECT
.
P0 SS: T-DATA.REQUEST TCP: send DT P
P0 SS: T-EXPEDITED DATA TCP: send ED P
.
P0 SS: T-DISCONNECT TCP: send DR, close
.
P0 SS: other TCP: send DR,
SS: T-DISCONNECT
.
Cass & Rose [Page 15]
RFC 983 April 1986
ISO Transport Services on Top of the
6. Packet
Two TS-peers exchange information over a TCP connection
encapsulating information in well-defined packets. A packet,
as "TPKT" in the previous sections, is viewed as an object
of an integral number of octets, of variable length
NOTE: For the purposes of presentation, these objects are
as being 4 octets (32 bits wide). This representation is
artifact of the style of this memo and should not be
as requiring that a TPDU be a multiple of 4 octets in length
A packet consists of two parts: a packet-header and a pseudo-TPDU
The format of the header is constant regardless of the type
packet. The format of the pseudo-TPDU follows the [ISO-8073]
recommendation very closely with the exceptions listed below. As
[ISO-8073], each TPDU consists of two parts: header and data
It is EXTREMELY important to observe that TPKTs
"indivisible" units of data to the TS-user. That is,
T-DATA.REQUEST initiated by the TS-user at the sending end of
connection should result in exactly one T-DATA.INDICATION
generated (with exactly that data) for the TS-user at the
end. To ensure this behavior, it is critical that any
event resulting from a TPKT be initiated ONLY after the entire
is fully received. Furthermore, exactly one such INDICATION
should be generated by the TS-peer. The packet length field,
described below, can accommodate on the order of 65K octets of
data. This should be well above the requirements of the size of
SPDU (Session Protocol Data Unit) for any real implementation. As
result, version 1 of this protocol has no need to either fragment
re-assemble TS-user data. If an application arises which requires
SPDU of size greater than 65K octets, this memo will be revised
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
1. vrsn 8
This field is always 1 for this memo
Cass & Rose [Page 16]
RFC 983 April 1986
ISO Transport Services on Top of the
2. packet length 16 bits (min=8, max=65535)
The length of entire packet in octets, including packet-header
The format of the TPDU (to re-phrase from [ISO-8073]) depends on
type of a TPDU. All TPDUs start with a fixed-part header length
the code. The information following after the code varies,
on the value of the code. In the context of this memo, the
codes are valid
CR: connect
CC: connect
DR: disconnect
DT:
ED: expedited
The format of a CR or CC TPDU is
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| destination reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference | class |options| variable data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | user data | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
3. header length 8 bits (min=6, max=min(254,
length-6))
The TPDU-header length in octets including parameters
excluding the header length field and user data (if any).
Cass & Rose [Page 17]
RFC 983 April 1986
ISO Transport Services on Top of the
4. code 4
The type of TPDU. Values, in the context of this memo, are
value
----- -------
14 CR: connection request (binary 1110)
13 CC: connection confirm (binary 1101)
8 DR: disconnect request (binary 1000)
15 DT: data (binary 1111)
1 ED: expedited data (binary 0001)
all other reserved
5. credit 4
This field is always ZERO on output and ignored on input
6. destination reference 16
This field is always ZERO on output and ignored on input
7. source reference 16
This field is always ZERO on output and ignored on input
8. class 4
This field is always 4 (binary 0100) on output and ignored
input. It is anticipated that future versions of this
will make use of this field
9. options 4
This field is always ZERO on output and ignored on input
10. variable data (header length - 6)
This portion of the TPDU is of variable length. For
TPDUs, this portion is empty (the header length field of
TPDU is exactly 6). The contents of the variable data
of zero or more "parameters". Each parameter has the
format
parameter code 1 octet in
parameter length 1 octet in size, value is the
of octets in parameter
parameter value parameter
Cass & Rose [Page 18]
RFC 983 April 1986
ISO Transport Services on Top of the
Normally, the parameter length is 1 octet. Any
conforming to this version of the protocol must recognize
parameter types listed in [ISO-8073]. With the exception
the parameters listed below, these parameters are
ignored
o Parameter name: Transport service access
identifier (TSAP-ID) of the
Parameter code: 193 (binary 1100 0001)
Parameter length:
Parameter value: TSAP-ID
Each TSAP-ID consists of 1 or more attributes.
attribute has this format
Attribute code 1 octet in
Attribute length 1 octet in size, value is the
of octets in attribute
Attribute value attribute
In version 1 of this protocol, only two attributes
defined. All others are reserved
Attribute name: Internet
Attribute code: 1
Attribute length: 6
Attribute value: IP address (4 octets
session port (2 octets,
integer
This attribute is ALWAYS required. Values for
port can be found in Appendix A of this memo
Attribute name: Internet Address for Expedited
Attribute code: 2
Attribute length: 6
Attribute value: IP address (4 octets
TCP port (2 octets, unsigned integer
This attribute is required ONLY if expedited data
to be exchanged. The attribute value is an <
address, TCP port> pair designated by the TS-peer
use with expedited data
Cass & Rose [Page 19]
RFC 983 April 1986
ISO Transport Services on Top of the
o Parameter name: TSAP-ID of the server
Parameter code: 194 (binary 1100 0010)
Parameter length:
Parameter value: TSAP-ID
o Parameter name: Additional option
Parameter code: 198 (binary 1100 0110)
Parameter length: 1
Parameter value: additional
The additional flags octet consists of 8-bits of
flags. Only one bit is of interest to this memo,
remaining bits should be ZERO on output and ignored
input. This bit indicates if the transport expedited
service is to be used. If this bit is set (bit mask 0000
0001) or this parameter does not appear in the TPDU,
the expedited data service is requested. If this
appears in the TPDU and the bit is not set then the
is disabled. If the service is requested, then the TSAP-
of the sender of the TPDU must include an
indicating the internet address to use for expedited data
o Parameter name: Alternative protocol
Parameter code: 199 (binary 1100 0111)
Parameter length:
Parameter value: 64 (binary 0100 0000) in each
This is used as a NOOP in the variable data. Its use
HIGHLY discouraged, but for those implementors who
to align the user data portion of the TPDU on word (
page) boundaries, use of this parameter for filling
recommended
11. user data (packet length - header length - 5)
This portion of the TPDU is actual user data, most probably
or more SPDUs (session protocol data units).
Cass & Rose [Page 20]
RFC 983 April 1986
ISO Transport Services on Top of the
The format of a DR TPDU is
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| destination reference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source reference | reason | variable data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | user data | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the fields is identical to those of a CR or CC TPDU
with the following exceptions
where
8. reason 8
This replaces the class/option fields of the CR or CC TPDU.
value, as specified in [ISO-8073], may be used in this field
This memo makes use of several
value
----- -------
1 Congestion at
2 Session entity not attached to
3 Address unknown (at TCP connect time
128+0 Normal disconnect initiated by the
128+1 Remote transport entity congestion at
request
128+3 Connection negotiation
128+5 Protocol
128+8 Connection request refused on this
Cass & Rose [Page 21]
RFC 983 April 1986
ISO Transport Services on Top of the
The format of a DT or ED TPDU is
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 | ... | ... | ... |
| ... | ... | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
After the credit field (which is always ZERO on output and
on input), there is one additional field prior to the user data
6. TPDU-NR and EOT 16
This field is always ZERO on output and ignored on input
7. Expedited
This memo utilizes a second TCP connection to handle expedited
and does not make use of the TCP URGENT mechanism. The
disadvantage of this decision is that single-threaded
of TCP may have some difficulty in supporting two
connections. There are however several advantages to this approach
a. Use of a single connection to implement the semantics
expedited data implies that the TSAP peer manage a set of
independent from TCP. The peer would, upon indication of
urgent information, have to buffer all preceeding TPKTs until
TCP buffer was empty. Expedited data would then be given to
TS-user. When the expedited data was flushed, then the
(non-expedited) data could be passed up to the receiving user
b. It assumes that implementations support TCP urgency correctly
This is perhaps an untrue assumption, particular in the case
TCP urgency occuring when the send window is zero-sized. Further
it assumes that the implementations can signal this event to
TCP-user in a meaningful fashion. In a single-
implementation, this is not likely
Given a reasonable TCP implementation, the TS-peer need listen on
Cass & Rose [Page 22]
RFC 983 April 1986
ISO Transport Services on Top of the
TCP sockets in either polling or interrupt mode. When the TS-peer
given data, the TCP must indicate which connection should be
from
The only tricky part of the protocol is that the client must be
to start a passive OPEN for the expedited port, and then wait to
from another connection. In between the passive OPEN and the
connection supplying data, the server will connect to the
port, prior to sending data on the other connection. To
from Section 5, the sequence of events, with respect to TCP, is
time client
---- ------ ------
0. passive OPEN of port 102
1. T-CONNECT.REQUEST from
passive OPEN of
port (non-blocking
2. active OPEN of port 102
3. send CC
4. port 102
5. receive CC
T-CONNECT.INDICATION
T-CONNECT.RESPONSE
6. active OPEN to
7. expedited port
8. send CR
9. receive CR
verify expedited
connected
Multi-threaded implementations of TCP should be able to support
sequence of events without any great difficulty
Cass & Rose [Page 23]
RFC 983 April 1986
ISO Transport Services on Top of the
8.
There are two design decisions which should be considered. The
deals with particular packet format used. It should be obvious
the reader that the TP packet format was adopted for use in
memo. Although this results in a few fields being ignored (e.g.,
source reference), it does not introduce an unacceptable amount
overhead. For example, on a connection request packet (the
case) there are 6 bytes of "zero on output, ignore on input" fields
Considering that the packet overhead processing is fixed,
that implementations allocate an additional 1.5 words is
unreasonable! Of course, it should be noted that some of
fields (i.e., class) may be used in future versions of the
as experience is gained
The second decision deals with how the TCP and TSAP port space
administered. It is probably a very bad idea to take
responsibility, whatsoever, for managing this addressing space,
after ISO has stabilized. There are two issues involved. First,
what level do the TCP and TSAP port spaces interact; second,
defines what this interaction looks like. With respect to the first
it wholly undesirable to require that each TSAP port map to a
TCP port. The administrative problems for the TCP "numbers czar (
czarina)" would be non-trivial. Therefore, it is desirable
allocate a single TCP port, namely port 102, as the port where
"ISO Transport Services" live in the TCP domain. Second,
interaction defined in Appendix A of this memo is embryonic at best
It will no doubt be replaced as soon as the ISO world
convergence on how services are addressed in ISO TP.
readers (and implementors) are asked to keep in mind that this
of the memo is guaranteed to change. Unfortunately, the authors
not permitted the luxury of waiting for a consensus in ISO. As
result, the minimal effort approach outlined in the appendix
was adopted
A prototype implementation of the protocol described by this memo
available for 4.2BSD UNIX. Interested parties should contact
authors for a copy. To briefly mention its implementation, a
ISO service is implemented as a separate program. A daemon
on TCP port 102, consults a database when a connection request
is received, and fires the appropriate program for the ISO
requested. Of course, given the nature of the BSD implementation
TCP, as the child fires, responsibility of that particular
is delegated to the child; the daemon returns to listening for
connection requests. The prototype implementation consists of
the daemon program and subroutine libraries which are loaded
programs providing ISO services
Cass & Rose [Page 24]
RFC 983 April 1986
ISO Transport Services on Top of the
9.
[ISO-8072] ISO
"International Standard 8072. Information
Systems -- Open Systems Interconnection:
Service Definition."
(June, 1984)
[ISO-8073] ISO
"International Standard 8073. Information
Systems -- Open Systems Interconnection:
Protocol Specification."
(June, 1984)
[ISO-8327] ISO
"International Standard 8327. Information
Systems -- Open Systems Interconnection:
Protocol Specification."
(June, 1984)
[RFC-791] Internet Protocol
Request for Comments 791
(September, 1981)
(See also: MIL-STD-1777)
[RFC-793] Transmission Control Protocol
Request for Comments 793
(September, 1981)
(See also: MIL-STD-1778)
[RFC-960] Assigned Numbers
Request for Comments 960
(December, 1985)
[X.214] CCITT
"Recommendation X.214. Transport Service
for Open Systems Interconnection (OSI) for
Applications."
(October, 1984)
[X.224] CCITT
"Recommendation X.224. Transport Protocol
for Open Systems Interconnection (OSI) for
Applications."
(October, 1984)
Cass & Rose [Page 25]
RFC 983 April 1986
ISO Transport Services on Top of the
[X.225] CCITT
"Recommendation X.225. Session Protocol
for Open Systems Interconnection (OSI) for
Applications."
(October, 1984)
[X.410] CCITT
"Recommendation X.410. Message Handling Systems:
Operations and Reliable Transfer Server."
(October, 1984)
Appendix A: Reserved TSAP
Version 1 of this protocol uses a relatively simple encoding
for TSAP IDs. A TSAP ID is an attribute list containing
parameters, a 32-bit IP address, and a 16-bit port number. This
used to identify both the client TSAP and the server TSAP. When
appears in a TPKT with code CR or CC, the TSAP ID is encoded in
variable data part for the client TSAP as
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 193 | 8 | 1 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a | b | c | d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and for the server TSAP as
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 194 | 8 | 1 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| a | b | c | d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Neither of these examples include an attribute for a TCP
for expedited data. If one were present, the length of the TSAP
attribute would be 16 instead of 8, and the 8 bytes following
Internet address would be "2" for the attribute code, "6" for
Cass & Rose [Page 26]
RFC 983 April 1986
ISO Transport Services on Top of the
attribute length, and then 6 octets for the Internet address to
for expedited data, 4 octets for IP address, and 2 octets for
port.)
Where [a.b.c.d] is the IP address of the host where the
TSAP peer resides, and port is a 16-bit unsigned integer
where in the TSAP port space the TS-user lives
Port value
---------- -----------
0
1-4096
4097-65535
The following table contains the list of the "official" TSAP ID
numbers as of the first release of this memo. It is expected
future editions of the "Assigned Numbers" document[RFC-960]
contain updates to this list
Port name ISO
---- ---- -----------
1 echo unofficial
2 sink unofficial data
3 FTAM File Transfer, Access, and
4 VTS ISO-8571 Virtual Terminal
5 MHS Message Handling System [X.411]
CCITT X.400
6 JTM Job Transfer and
ISO 8831/8832
7 CASE Common Application Service
Kernel ISO-8650/2
If anyone knows of a list of "official" ISO services, the
would be very interested
Cass & Rose [Page 27]
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
