📄 rfc983.txt
字号:
| ... | ... | ... | ... |
| ... | ... | ... | ... |
| ... | 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 bits
This replaces the class/option fields of the CR or CC TPDU. Any
value, as specified in [ISO-8073], may be used in this field.
This memo makes use of several:
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
Cass & Rose [Page 21]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
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 ignored
on input), there is one additional field prior to the user data:
6. TPDU-NR and EOT 16 bits
This field is always ZERO on output and ignored on input.
7. Expedited Data
This memo utilizes a second TCP connection to handle expedited data
and does not make use of the TCP URGENT mechanism. The primary
disadvantage of this decision is that single-threaded implementations
of TCP may have some difficulty in supporting two simultaneous
connections. There are however several advantages to this approach:
a. Use of a single connection to implement the semantics of
expedited data implies that the TSAP peer manage a set of buffers
independent from TCP. The peer would, upon indication of TCP
urgent information, have to buffer all preceeding TPKTs until the
TCP buffer was empty. Expedited data would then be given to the
TS-user. When the expedited data was flushed, then the buffered
(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 of
TCP urgency occuring when the send window is zero-sized. Further,
it assumes that the implementations can signal this event to the
TCP-user in a meaningful fashion. In a single-threaded
implementation, this is not likely.
Given a reasonable TCP implementation, the TS-peer need listen on two
Cass & Rose [Page 22]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
TCP sockets in either polling or interrupt mode. When the TS-peer is
given data, the TCP must indicate which connection should be read
from.
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:
time client Server
---- ------ ------
0. passive OPEN of port 102
1. T-CONNECT.REQUEST from user
passive OPEN of expedited
port (non-blocking)
2. active OPEN of port 102
3. send CC TPKT
4. port 102 connected
5. receive CC TPKT
T-CONNECT.INDICATION to
user
T-CONNECT.RESPONSE from
user
6. active OPEN to expedited
port
7. expedited port connected
8. send CR TPKT
9. receive CR TPKT
verify expedited port
connected correctly
Multi-threaded implementations of TCP should be able to support this
sequence of events without any great difficulty.
Cass & Rose [Page 23]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
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.
A prototype implementation of the protocol described by this memo is
available for 4.2BSD UNIX. Interested parties should contact the
authors for a copy. To briefly mention its implementation, a given
ISO service is implemented as a separate program. A daemon listens
on TCP port 102, consults a database when a connection request packet
is received, and fires the appropriate program for the ISO service
requested. Of course, given the nature of the BSD implementation of
TCP, as the child fires, responsibility of that particular connection
is delegated to the child; the daemon returns to listening for new
connection requests. The prototype implementation consists of both
the daemon program and subroutine libraries which are loaded with
programs providing ISO services.
Cass & Rose [Page 24]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
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)
[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 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)
Cass & Rose [Page 25]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
[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)
Appendix A: Reserved TSAP IDs
Version 1 of this protocol uses a relatively simple encoding scheme
for TSAP IDs. A TSAP ID is an attribute list containing two
parameters, a 32-bit IP address, and a 16-bit port number. This is
used to identify both the client TSAP and the server TSAP. When it
appears in a TPKT with code CR or CC, the TSAP ID is encoded in the
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 connection
for expedited data. If one were present, the length of the TSAP ID
attribute would be 16 instead of 8, and the 8 bytes following the
Internet address would be "2" for the attribute code, "6" for the
Cass & Rose [Page 26]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
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.)
Where [a.b.c.d] is the IP address of the host where the respective
TSAP peer resides, and port is a 16-bit unsigned integer describing
where in the TSAP port space the TS-user lives.
Port value Designation
---------- -----------
0 illegal
1-4096 privileged
4097-65535 user
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.
Port name ISO service
---- ---- -----------
1 echo unofficial echo
2 sink unofficial data sink
3 FTAM File Transfer, Access, and Management
4 VTS ISO-8571 Virtual Terminal Service
5 MHS Message Handling System [X.411]
CCITT X.400
6 JTM Job Transfer and Manipulation
ISO 8831/8832
7 CASE Common Application Service Elements
Kernel ISO-8650/2
If anyone knows of a list of "official" ISO services, the authors
would be very interested.
Cass & Rose [Page 27]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -