📄 rfc983.txt
字号:
Cass & Rose [Page 14]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
P E E R S T A T E S
state event action goto
----- ----- ------ ----
P0 TCP: data ready TCP: read TPKT
parse, on error
TCP: send DR, close
SS: T-DISCONNECT end
.INDICATION
code is DT
SS: T-DATA.INDICATION P0
code is ED
SS: T-EXPEDITED DATA P0
.INDICATION
code is DR
TCP: close
SS: T-DISCONNECT end
.INDICATION
otherwise
TCP: send DR, close
SS: T-DISCONNECT end
.INDICATION
P0 TCP: other TCP: close
SS: T-DISCONNECT end
.INDICATION
P0 SS: T-DATA.REQUEST TCP: send DT P0
P0 SS: T-EXPEDITED DATA TCP: send ED P0
.REQUEST
P0 SS: T-DISCONNECT TCP: send DR, close end
.REQUEST
P0 SS: other TCP: send DR, close
SS: T-DISCONNECT end
.INDICATION
Cass & Rose [Page 15]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
6. Packet Format
Two TS-peers exchange information over a TCP connection by
encapsulating information in well-defined packets. A packet, denoted
as "TPKT" in the previous sections, is viewed as an object composed
of an integral number of octets, of variable length.
NOTE: For the purposes of presentation, these objects are shown
as being 4 octets (32 bits wide). This representation is an
artifact of the style of this memo and should not be interpreted
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 of
packet. The format of the pseudo-TPDU follows the [ISO-8073]
recommendation very closely with the exceptions listed below. As per
[ISO-8073], each TPDU consists of two parts: header and data.
It is EXTREMELY important to observe that TPKTs represent
"indivisible" units of data to the TS-user. That is, a
T-DATA.REQUEST initiated by the TS-user at the sending end of a
connection should result in exactly one T-DATA.INDICATION being
generated (with exactly that data) for the TS-user at the receiving
end. To ensure this behavior, it is critical that any INDICATION
event resulting from a TPKT be initiated ONLY after the entire TPKT
is fully received. Furthermore, exactly one such INDICATION event
should be generated by the TS-peer. The packet length field, as
described below, can accommodate on the order of 65K octets of user
data. This should be well above the requirements of the size of any
SPDU (Session Protocol Data Unit) for any real implementation. As a
result, version 1 of this protocol has no need to either fragment or
re-assemble TS-user data. If an application arises which requires an
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 bits
This field is always 1 for this memo.
Cass & Rose [Page 16]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
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 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:
CR: connect request
CC: connect confirm
DR: disconnect request
DT: data
ED: expedited data
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,packet
length-6))
The TPDU-header length in octets including parameters but
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 TCP
4. code 4 bits
The type of TPDU. Values, in the context of this memo, are:
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
This field is always ZERO on output and ignored on input.
6. destination reference 16 bits
This field is always ZERO on output and ignored on input.
7. source reference 16 bits
This field is always ZERO on output and ignored on input.
8. class 4 bits
This field is always 4 (binary 0100) on output and ignored on
input. It is anticipated that future versions of this protocol
will make use of this field.
9. options 4 bits
This field is always ZERO on output and ignored on input.
10. variable data (header length - 6) octets
This portion of the TPDU is of variable length. For most
TPDUs, this portion is empty (the header length field of the
TPDU is exactly 6). The contents of the variable data consist
of zero or more "parameters". Each parameter has the following
format:
parameter code 1 octet in size
parameter length 1 octet in size, value is the number
of octets in parameter value
parameter value parameter data
Cass & Rose [Page 18]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
Normally, the parameter length is 1 octet. Any implementation
conforming to this version of the protocol must recognize all
parameter types listed in [ISO-8073]. With the exception of
the parameters listed below, these parameters are simply
ignored.
o Parameter name: Transport service access point
identifier (TSAP-ID) of the client
TSAP
Parameter code: 193 (binary 1100 0001)
Parameter length: variable
Parameter value: TSAP-ID attributes
Each TSAP-ID consists of 1 or more attributes. Each
attribute has this format:
Attribute code 1 octet in size
Attribute length 1 octet in size, value is the number
of octets in attribute value
Attribute value attribute data
In version 1 of this protocol, only two attributes are
defined. All others are reserved.
Attribute name: Internet Address
Attribute code: 1
Attribute length: 6
Attribute value: IP address (4 octets)
session port (2 octets, unsigned
integer)
This attribute is ALWAYS required. Values for session
port can be found in Appendix A of this memo.
Attribute name: Internet Address for Expedited Data
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 is
to be exchanged. The attribute value is an <IP
address, TCP port> pair designated by the TS-peer for
use with expedited data.
Cass & Rose [Page 19]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
o Parameter name: TSAP-ID of the server TSAP
Parameter code: 194 (binary 1100 0010)
Parameter length: variable
Parameter value: TSAP-ID attributes
o Parameter name: Additional option selection
Parameter code: 198 (binary 1100 0110)
Parameter length: 1
Parameter value: additional flags
The additional flags octet consists of 8-bits of optional
flags. Only one bit is of interest to this memo, the
remaining bits should be ZERO on output and ignored on
input. This bit indicates if the transport expedited data
service is to be used. If this bit is set (bit mask 0000
0001) or this parameter does not appear in the TPDU, then
the expedited data service is requested. If this parameter
appears in the TPDU and the bit is not set then the service
is disabled. If the service is requested, then the TSAP-ID
of the sender of the TPDU must include an attribute
indicating the internet address to use for expedited data.
o Parameter name: Alternative protocol classes
Parameter code: 199 (binary 1100 0111)
Parameter length: variable
Parameter value: 64 (binary 0100 0000) in each octet
This is used as a NOOP in the variable data. Its use is
HIGHLY discouraged, but for those implementors who wish
to align the user data portion of the TPDU on word (or
page) boundaries, use of this parameter for filling is
recommended.
11. user data (packet length - header length - 5)
octets
This portion of the TPDU is actual user data, most probably one
or more SPDUs (session protocol data units).
Cass & Rose [Page 20]
RFC 983 April 1986
ISO Transport Services on Top of the TCP
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -