Documente Academic
Documente Profesional
Documente Cultură
Cass (NRTC)
Request for Comments: 983 M. T. Rose (NRTC)
April 1986
There are two basic approaches which can be taken when "porting" an
ISO or CCITT application to a TCP/IP environment. One approach is to
port each individual application separately, developing local
protocols on top of the TCP. Although this is useful in the
short-term (since special-purpose interfaces to the TCP can be
developed quickly), it lacks generality.
Putting all this together, the service-provider uses the protocol and
services from the layer below to offer the its service to the layer
above. Protocol verification, for instance, deals with proving that
this in fact happens (and is also a fertile field for many Ph.D.
dissertations in computer science).
The authors hope that the preceding paragraph will not come as a
shock to most readers. However, an ALARMING number of people seem to
think that layering is just a way of cutting up a large problem into
smaller ones, *simply* for the sake of cutting it up. Although
layering tends to introduce modularity into an architecture, and
modularity tends to introduce sanity into implementations (both
conceptual and physical implementations), modularity, per se, is not
the end goal. Flexibility IS.
2. Motivation
In migrating from the use of TCP/IP to the ISO protocols, there are
several strategies that one might undertake. This memo was written
with one particular strategy in mind.
3. The Model
+-------------+ +-------------+
| 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 the purposes of this memo, which describes version 1 of the TSAP
protocol, all aspects of [ISO-8072] are supported with one exception:
4. The Primitives
The protocol assumes that the TCP [RFC-793] offers the following
service primitives:
Events
Actions
Events
T-CONNECT.INDICATION
T-DISCONNECT.INDICATION
T-CONNECT.CONFIRMATION
T-DATA.INDICATION
T-EXPEDITED DATA.INDICATION
Actions
T-CONNECT.RESPONSE
T-DISCONNECT.REQUEST
T-CONNECT.REQUEST
T-DATA.REQUEST
T-EXPEDITED DATA.REQUEST
5. The Protocol
CR - request connection
CC - confirm connection
DR - request disconnection
DT - data
ED - expedited data
The server, upon receipt of the TPKT, validates the contents of the
TPKT (checking the version number, verifying that the code is CR, and
so forth). If the packet is invalid, the server sends a TPKT with
code DR specifying "PROTOCOL ERROR", closes the TCP connection, and
goes back to the LISTEN state.
If the packet is valid, the server examines the TSAP ID that the
remote TS-user wants to communicate with. If the TS-user specified
can be located and started (e.g., the appropriate program which
implements the indicated protocol is present), then the server starts
this TS-user by firing T-CONNECT.INDICATION. Otherwise, the server
sends a TPKT with code DR specifying "SESSION ENTITY NOT ATTACHED TO
TSAP" or "REMOTE TRANSPORT ENTITY CONGESTED AT CONNECT REQUEST TIME"
as appropriate, closes the TCP connection, and goes back to the
LISTEN state.
The server then closes the TCP connection and goes back to the LISTEN
state.
If an expedited port was not specified in the TPKT with code CR, and
the server's TS-user indicates that it wants to use expedited data,
then the server sends a TPKT with code DR specifying "CONNECTION
NEGOTIATION FAILED", fires T-DISCONNECT.INDICATION with this error to
the TS-user, closes the TCP connection, and goes back to the LISTEN
state.
the TSAP ID of the port number on the server's host that was
used to connect to the expedited port
- any TS-user data from the T-CONNECT.RESPONSE
After sending the TPKT, the server enters the SYMMETRIC PEER state.
The client, upon receipt of the TPKT, validates the contents of the
TPKT (checking the version number, verifying that the code is CC or
DR, and so forth). If the packet is invalid, the client sends a TPKT
with code DR specifying "PROTOCOL ERROR", fires
T-DISCONNECT.INDICATION with this error to the TS-user, and closes
the TCP connection (and the expedited port, if any).
Once both sides have reached the SYMMETRIC PEER state, the protocol
is completely symmetric, the notion of client/server is lost. Both
TS-peers act in the following fashion:
If the TCP indicates that data can be read, the TS-peer, upon receipt
of the TPKT, validates the contents. If the packet is invalid, the
TS-peer sends a TPKT with code DR specifying "PROTOCOL ERROR", fires
T-DISCONNECT.INDICATION with this error to the TS-user, and closes
the TCP connection (and expedited data connection, if any). If the
TS-peer was the server, it goes back to the LISTEN state.
NOTE: If the expedited data option was requested, then there are
two TCP connections that can supply data for reading. The
dialogue below assumes that only ED TPKTs are read from the
expedited data connection. For simplicity's sake, when reading
from TCP the relation between connections and TPKTs is unimportant
and this memo URGES all implementations to be very lenient in this
If the TCP indicates that an error has occurred and the connection
has closed, then the TS-peer fires T-DISCONNECT.INDICATION to the
TS-user specifying the reason for the failure. If the expedited data
connection, if any, is still open, it is closed. If the TS-peer was
the server, it goes back to the LISTEN state.
S E R V E R S T A T E S
C L I E N T S T A T E S
P E E R S T A T E S
6. Packet Format
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 bits
The format of the TPDU (to re-phrase from [ISO-8073]) depends on the
type of a TPDU. All TPDUs start with a fixed-part header length and
the code. The information following after the code varies, depending
on the value of the code. In the context of this memo, the following
codes are valid:
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:
4. code 4 bits
value meaning
----- -------
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 bits
8. class 4 bits
9. options 4 bits
Attribute code: 1
Attribute length: 6
Attribute value: IP address (4 octets)
session port (2 octets, unsigned
integer)
Attribute code: 2
Attribute length: 6
Attribute value: IP address (4 octets)
TCP port (2 octets, unsigned integer)
This portion of the TPDU is actual user data, most probably one
or more SPDUs (session protocol data units).
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 | ... | ... |
| ... | ... | ... | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
8. reason 8 bits
value meaning
----- -------
1 Congestion at TSAP
2 Session entity not attached to TSAP
3 Address unknown (at TCP connect time)
128+0 Normal disconnect initiated by the session
entity
128+1 Remote transport entity congestion at connect
request time
128+3 Connection negotiation failed
128+5 Protocol Error
128+8 Connection request refused on this network
connection
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 ignored
on input), there is one additional field prior to the user data:
7. Expedited Data
The only tricky part of the protocol is that the client must be able
to start a passive OPEN for the expedited port, and then wait to read
from another connection. In between the passive OPEN and the other
connection supplying data, the server will connect to the expedited
port, prior to sending data on the other connection. To summarize
from Section 5, the sequence of events, with respect to TCP, is:
3. send CC TPKT
5. receive CC TPKT
T-CONNECT.INDICATION to
user
T-CONNECT.RESPONSE from
user
8. send CR TPKT
9. receive CR TPKT
verify expedited port
connected correctly
8. Conclusions
There are two design decisions which should be considered. The first
deals with particular packet format used. It should be obvious to
the reader that the TP packet format was adopted for use in this
memo. Although this results in a few fields being ignored (e.g.,
source reference), it does not introduce an unacceptable amount of
overhead. For example, on a connection request packet (the worst
case) there are 6 bytes of "zero on output, ignore on input" fields.
Considering that the packet overhead processing is fixed, requiring
that implementations allocate an additional 1.5 words is not
unreasonable! Of course, it should be noted that some of these
fields (i.e., class) may be used in future versions of the protocol
as experience is gained.
The second decision deals with how the TCP and TSAP port space is
administered. It is probably a very bad idea to take any
responsibility, whatsoever, for managing this addressing space, even
after ISO has stabilized. There are two issues involved. First, at
what level do the TCP and TSAP port spaces interact; second, who
defines what this interaction looks like. With respect to the first,
it wholly undesirable to require that each TSAP port map to a unique
TCP port. The administrative problems for the TCP "numbers czar (and
czarina)" would be non-trivial. Therefore, it is desirable to
allocate a single TCP port, namely port 102, as the port where the
"ISO Transport Services" live in the TCP domain. Second, the
interaction defined in Appendix A of this memo is embryonic at best.
It will no doubt be replaced as soon as the ISO world reaches
convergence on how services are addressed in ISO TP. Therefore
readers (and implementors) are asked to keep in mind that this aspect
of the memo is guaranteed to change. Unfortunately, the authors are
not permitted the luxury of waiting for a consensus in ISO. As a
result, the minimal effort approach outlined in the appendix below
was adopted.
9. References
[ISO-8072] ISO.
"International Standard 8072. Information Processing
Systems -- Open Systems Interconnection: Transport
Service Definition."
(June, 1984)
[ISO-8073] ISO.
"International Standard 8073. Information Processing
Systems -- Open Systems Interconnection: Transport
Protocol Specification."
(June, 1984)
[ISO-8327] ISO.
"International Standard 8327. Information Processing
Systems -- Open Systems Interconnection: Session
Protocol Specification."
(June, 1984)
[X.214] CCITT.
"Recommendation X.214. Transport Service Definitions
for Open Systems Interconnection (OSI) for CCITT
Applications."
(October, 1984)
[X.224] CCITT.
"Recommendation X.224. Transport Protocol Specification
for Open Systems Interconnection (OSI) for CCITT
Applications."
(October, 1984)
[X.225] CCITT.
"Recommendation X.225. Session Protocol Specification
for Open Systems Interconnection (OSI) for CCITT
Applications."
(October, 1984)
[X.410] CCITT.
"Recommendation X.410. Message Handling Systems: Remote
Operations and Reliable Transfer Server."
(October, 1984)
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
attribute length, and then 6 octets for the Internet address to use
for expedited data, 4 octets for IP address, and 2 octets for TCP
port.)
The following table contains the list of the "official" TSAP ID port
numbers as of the first release of this memo. It is expected that
future editions of the "Assigned Numbers" document[RFC-960] will
contain updates to this list.