📄 rfc2114.txt
字号:
RFC 2114 DCAP February 1997
The next two fields are the Host and Client SAPs. Each is one byte
long. The Host SAP is the SAP used by the station with the Host MAC
address. The Client SAP is the SAP used by the client.
The Origin Session ID, is the ID of the originating station that
initiates the circuit. The originating station uses this ID to
identify the newly created circuit. Before the START_DL frame is sent
to the target station, the originating station sets up a control
block for the circuit. This link station information is set because
DCAP does not use a three-way handshake for link station
establishment. In the DL_STARTED and the START_DL_FAILED frames, the
Origin Session ID is returned as received in the START_DL frame. The
Target Session ID is set by the target station and returned in the
DL_STARTED frame.
The Target Session ID is not valid for the START_DL and the
START_DL_FAILED frame, and should be treated as Reserved fields. In
the DL_STARTED frame, it is the session ID that is used to set up
this circuit by the target station.
The Largest Frame Size field is used to indicate the maximum frame
size that can be used by the client. It is valid only when it is set
by the server. The Largest Frame Size field must be set to zero when
a frame is sent by the client. Both START_DL and DL_STARTED use the
Largest Frame Size field and only its rightmost 6 bits are used. The
format is defined in the IEEE 802.1D Standard, Annex C, Largest Frame
Bits (LF). Bit 3 to bit 5 are base bits. Bit 0 to bit 2 are extended
bits. The Largest Frame Size field is not used in the START_DL_FAILED
frame and must be set to zero.
bit 7 6 5 4 3 2 1 0
r r b b b e e e
Figure 3-7. Largest Frame Size
Please note that if the client is a PU 2.1 node, the client should
use the maximum I-frame size negotiated in the XID3 exchange.
The Initial window size in the START_DL frame specifies the receive
window size on the originating side, and the target DCAP station
returns its receive window size in the DL_STARTED frame. The field is
reserved in the START_DL_FAILED frame. The usage of the window size
is the same as the one used in DLSw. Please refer to RFC 1795 for
details.
The last two bits are reserved for future use. They must be set to
zero by the sender and ignored by the receiver.
Chiang, et. al. Informational [Page 12]
RFC 2114 DCAP February 1997
3.4.3. HALT_DL, HALT_DL_NOACK, and DL_HALTED Frames
These frame types are used by DCAP to disconnect a link station. A
HALT_DL frame is sent directly to the remote workstation to indicate
that the sender wishes to disconnect a session. When the receiver
receives this frame, it tears down the session that is associated
with the Original Session ID and the Target Session ID provided in
the HALT_DL frame. The receiver should respond with the DL_HALTED
frame. The DL_HALTED frame should use the same Session ID values as
the received HALT_DL frame without swapping them. The HALT_DL_NOACK
frame is used when the response is not required. The TCP session
between the client and server should remain up after the
HALT_DL/DL_HALTED/ HALT_DL_NOACK exchange.
+---------------+-----------------------+
| Field Name | Information |
+---------------+-----------------------+
| Message Type | 0x0C, 0x0D, or 0x0E |
+---------------+-----------------------+
| Packet Length | 0x10 |
+---------------+-----------------------+
Figure 3-8. HALT_DL, HALT_DL_NOACK, and DL_HALTED Header
Chiang, et. al. Informational [Page 13]
RFC 2114 DCAP February 1997
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Sender Session ID |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
4 | Receiver Session ID |
+ - - - - - - - - - - - - - - - - - +
5 | |
+ - - - - - - - - - - - - - - - - - +
6 | |
+ - - - - - - - - - - - - - - - - - +
7 | |
+-----------------------------------+
8 | Reserved |
+ - - - - - - - - - - - - - - - - - +
9 | |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
Figure 3-9. START_DL, DL_STARTED, and START_DL_FAILED Data
3.4.4. XID_FRAME, CONTACT_STN, STN_CONTACTED, INFO_FRAME, FCM_FRAME,
and DGRM_FRAME
These frame types are used to carry the end-to-end data or establish
a circuit. The Destination Session ID is the Session ID created in
the START_DL frame or the DL_STARTED frame by the receiver. The usage
of the flow control flag is the same as the one used in DLSw. Please
refer to RFC 1795 for details.
+---------------+----------------------------+
| Field Name | Information |
+---------------+----------------------------+
| Message Type | Based on Message type |
+---------------+----------------------------+
| Packet Length | 0x0C + length of user data |
+---------------+----------------------------+
Figure 3-10. Generic DCAP Header
Chiang, et. al. Informational [Page 14]
RFC 2114 DCAP February 1997
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Destination Session ID |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+-----------------------------------+
4 | Flow Control Flags |
+-----------------------------------+
5 | Reserved |
+ - - - - - - - - - - - - - - - - - +
6 | |
+ - - - - - - - - - - - - - - - - - +
7 | |
+-----------------------------------+
Figure 3-11. Generic DCAP Data Format
3.4.5. DATA_FRAME
This frame type is used to send connectionless SNA and NetBIOS
Datagram (UI) frames that do not have a link station associated with
the source and destination MAC/SAP pair. The difference between
DGRM_FRAME and DATA_FRAME is that DGRM_FRAME is used to send UI
frames received for stations that have a link station opened, whereas
DATA_FRAME is used for frames with no link station established.
+---------------+-----------------------------+
| Field Name | Information |
+---------------+-----------------------------+
| Message Type | 0x0A |
+---------------+-----------------------------+
| Packet Length | 0x10 + Length of user data |
+---------------+-----------------------------+
Figure 3-12. DATA_FRAME Header
Chiang, et. al. Informational [Page 15]
RFC 2114 DCAP February 1997
+-----------------------------------+
| Field Name (Each row is one byte) |
+===================================+
0 | Host MAC Address |
+ - - - - - - - - - - - - - - - - - +
1 | |
+ - - - - - - - - - - - - - - - - - +
2 | |
+ - - - - - - - - - - - - - - - - - +
3 | |
+ - - - - - - - - - - - - - - - - - +
4 | |
+ - - - - - - - - - - - - - - - - - +
5 | |
+-----------------------------------+
6 | Host SAP |
+-----------------------------------+
7 | Client SAP |
+-----------------------------------+
8 | Broadcast Type |
+-----------------------------------+
9 | Reserved |
+ - - - - - - - - - - - - - - - - - +
10| |
+ - - - - - - - - - - - - - - - - - +
11| |
+-----------------------------------+
Figure 3-13. DATA_FRAME Data Format
The definition of the first 8 bytes is the same as the START_DL
frame. The Broadcast Type field indicates the type of broadcast
frames in use; Single Route Broadcast, All Route Broadcast, or
Directed. The target side will use the same broadcast type. In the
case of Directed frame, if the RIF information is known, the target
peer can send a directed frame. If not, a Single Route Broadcast
frame is sent.
3.4.6. CAP_XCHANGE Frame
In DCAP, the capability exchange frame is used to exchange the
capability information between a client and a server. CAP_XCHANGE
frames are exchanged between a client and a server as soon as the TCP
session is established. The capability exchange must be completed
before the other frame types can be sent. Once the capability
exchange is done, CAP_XCHANGE frame should not be used again.
Chiang, et. al. Informational [Page 16]
RFC 2114 DCAP February 1997
CAP_XCHANGE frame contains the clients MAC address, if a client has
one. If it does not, then the MAC address field must be set to zero.
When the DCAP server receives the CAP_XCHANGE frame, it should cache
the MAC address if it is non zero. The DCAP server also verifies that
the MAC address is unique. The server should return a CAP_XCHANGE
response frame with the MAC address supplied by the client if the MAC
address is accepted. If a client does not have its own MAC address,
the server should assign a MAC address to the client and put that
address in the CAP_XCHANGE command frame.
A client should record the new MAC address assigned by the server and
return a response with the assigned MAC address. If the client cannot
accept the assigned MAC address, another CAP_XCHANGE command with the
MAC address field set to zero should be sent to the server. The
server should allocate a new MAC address for this client.
During the capability exchange, both the client and the server can
send command frames. The process stops when either side sends a
CAP_XCHANGE response frame. When the response frame is sent, the MAC
address in the CAP_XCHANGE frame should be the same as the one in the
previous received command. The sender of the CAP_XCHANGE response
agrees to use the MAC address defined in the previous command.
The number of CAP_XCHANGE frames that need to be exchanged is
determined by the client and the server independently. When the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -