rfc2114.txt

中、英文RFC文档大全打包下载完全版 .


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