rfc2114.txt

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

   number of exchange frames has exceeded the pre-defined number set by
   either the server or the client, the session should be brought down.

   The flag is used to show the capability of the sender. The following
   list shows the valid flags:

   0x01 NetBIOS support. If a client sets this bit on, the server will
        pass all NetBIOS explorers to this client. If this bit is not
        set, only SNA traffic will be sent to this client.

   0x02 TCP Listen Mode support. If a client supports TCP listen mode,
        the server will keep the client's MAC and IP addresses even
        after the TCP session is down. The cached information will be
        used for server to connect out. If a client does not support
        TCP listen mode, the cache will be deleted as soon as the TCP
        session is down.

   0x04 Command/Response. If this bit is set, it is a command,
        otherwise, it is a response.

   The values 0x01 and 0x02 are used only by the client. When a server
   sends the command/response to a client, the server does not return
   these values.



Chiang, et. al.              Informational                     [Page 17]

RFC 2114                          DCAP                     February 1997


   Starting with the Reserved field, implementers can optionally
   implement the Capability Exchange Control Vector. Each Capability
   Exchange Control Vector consists of three fields: Length (1 byte),
   Type (1 byte), and Data (Length - 2 bytes). Two types of Control
   Vectors are defined: SAP_LIST and VENDOR_CODE (described below). To
   ensure compatibility, implementers should ignore the unknown Control
   Vectors instead of treating them as errors.

   0x01 SAP_LIST. Length: 2+n bytes, where n ranges from 1 to 16.
        This control vector lists the SAPs that the client can support.
        The maximum number of SAPs a client can define is 16. Therefore,
        the length of this Control Vector ranges from 3 to 18. If the
        SAP_LIST is not specified in the capability exchange, the server
        assumes that the client can support all the SAP values. For
        example, if a client can only support SAP 4 and 8, then the
        following Control Vectors should be sent: "0x04, 0x01, 0x04,
        0x08". The first byte indicates the length of 4. The second byte
        indicates the control vector type of SAP_LIST. The last two
        bytes indicate the supported SAP values; 0x04 and 0x08. This
        Control Vector is used only by the client. If the server accepts
        this Control Vector, it must return the same Control Vector to
        the client.

   0x02 VENDOR_CODE. Length: 3 bytes.
        Each vendor is assigned a vendor code that identifies the
        vendor. This Control Vector does not require a response.

   After the receiver responds to a Control Vector, if the capability
   exchange is not done, the sender does not have to send the same
   Control Vector again.

           +---------------+-----------------------+
           | Field Name    | Information           |
           +---------------+-----------------------+
           | Message Type  | 0x12                  |
           +---------------+-----------------------+
           | Packet Length | 0x1C                  |
           +---------------+-----------------------+
                    Figure 3-14. CAP_XCHANGE Header












Chiang, et. al.              Informational                     [Page 18]

RFC 2114                          DCAP                     February 1997


             +-----------------------------------+
             | Field Name (Each row is one byte) |
             +===================================+
           0 | MAC Address                       |
             + - - - - - - - - - - - - - - - - - +
           1 |                                   |
             + - - - - - - - - - - - - - - - - - +
           2 |                                   |
             + - - - - - - - - - - - - - - - - - +
           3 |                                   |
             + - - - - - - - - - - - - - - - - - +
           4 |                                   |
             + - - - - - - - - - - - - - - - - - +
           5 |                                   |
             +-----------------------------------+
           6 | Flag                              |
             +-----------------------------------+
           7 | Reserved                          |
             +-----------------------------------+
                  Figure 3-15. CAP_XCHANGE Data Format

3.4.7.  CLOSE_PEER_REQ Frames

   This frame is used for peer connection management and contains a
   reason code field. The following list describes the valid reason
   codes:

   0x01 System shutdown. This indicates shutdown in progress.

   0x02 Suspend. This code is used when there is no traffic between the
        server and the client, and the server or the client wishes to
        suspend the TCP session. When the TCP session is suspended, all
        circuits should remain intact. The TCP session should be re-
        established when new user data needs to be sent. When the TCP
        session is re-established, there is no need to send the
        CAP_XCHANGE frame again.

   0x03 No MAC address available. This code is sent by the server when
        there is no MAC address is available from the MAC address pool.

           +---------------+-----------------------+
           | Field Name    | Information           |
           +---------------+-----------------------+
           | Message Type  | 0x13                  |
           +---------------+-----------------------+
           | Packet Length | 0x08                  |
           +---------------+-----------------------+
                   Figure 3-16. CLOSE_PEER_REQ Header



Chiang, et. al.              Informational                     [Page 19]

RFC 2114                          DCAP                     February 1997


             +-----------------------------------+
             | Field Name (Each row is one byte) |
             +===================================+
           0 | Reason Code                       |
             +-----------------------------------+
           1 | Reserved                          |
             + - - - - - - - - - - - - - - - - - +
           2 |                                   |
             + - - - - - - - - - - - - - - - - - +
           3 |                                   |
             +-----------------------------------+
                Figure 3-17. CLOSE_PEER_REQ Data Format

3.4.8.  CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP Frames

   These three frames are used for peer connection management. There is
   no data associated with them.

   o CLOSE_PEER_RSP
     CLOSE_PEER_RSP is the response for CLOSE_PEER_REQ.

   o PEER_TEST_REQ and PEER_TEST_RSP
     PEER_TEST_REQ and PEER_TEST_RSP are used for peer level keepalive.
     Implementing PEER_TEST_REQ is optional, but PEER_TEST_RSP must be
     implemented to respond to the PEER_TEST_REQ frame. When a
     PEER_TEST_REQ frame is sent to the remote station, the sender
     expects to receive the PEER_TEST_RSP frame in a predefined time
     interval (the recommended value is 60 seconds). If the
     PEER_TEST_RSP frame is not received in the predefined time
     interval, the sender can send the PEER_TEST_REQ frame again. If a
     predefined number of PEER_TEST_REQ frames is sent to the remote
     station, but no PEER_TEST_RSP frame is received (the recommended
     number is 3), the sender should close the TCP session with this
     remote station and terminate all associated circuits.

           +---------------+-----------------------+
           | Field Name    | Information           |
           +---------------+-----------------------+
           | Message Type  | 0x14, 0x1D, or 0x1E   |
           +---------------+-----------------------+
           | Packet Length | 0x04                  |
           +---------------+-----------------------+
   Figure 3-18. CLOSE_PEER_RSP, PEER_TEST_REQ, and PEER_TEST_RSP DCAP

4.  Protocol Flow Diagram

   The following diagram shows a normal session start up/tear down
   sequence between a client and a server.



Chiang, et. al.              Informational                     [Page 20]

RFC 2114                          DCAP                     February 1997


                              +-----------+                +-------+
       +-----------+  Token   | DLSw/DCAP |                | DCAP  |
       | Mainframe +- Ring ---+   Router  +-- ip backbone--+ Client|
       +-----------+          +-----------+                +-------+

                                             TCP Session Up
                                             <-------------
                                             CAP_EXCHANGE (cmd)
                                             <-------------
                                             CAP_EXCHANGE (cmd)
                                             ------------->
                                             CAP_EXCHANGE (rsp)
                                             ------------->
                     TEST(P)                 CAN_U_REACH
                    <--------                <-------------
                     TEST(F)                 I_CAN_REACH
                    -------->                ------------->
                                             START_DL
                                             <-------------
                                             DL_STARTED
                                             ------------->
                     XID(P)                  XID_FRAME
                    <--------                <-------------
                     XID(F)                  XID_FRAME
                    -------->                ------------->
                     XID(P)                  XID_FRAME
                    <--------                <-------------
                     SABME                   CONTACT_STN
                    -------->                ------------->
                     UA                      STN_CONTACTED
                    <--------                <-------------
                     I FRAME                 INFO_FRAME
                    <--------                <-------------
                     I FRAME                 INFO_FRAME
                    -------->                ------------->
                     DISC                    HALT_DL
                    <--------                <-------------
                     UA                      DL_HALTED
                    -------->                ------------->
                                             CLOSE_PEER_REQ
                                             <-------------
                                             CLOSE_PEER_RSP
                                             ------------->
                                             TCP session down
                                             <-------------






Chiang, et. al.              Informational                     [Page 21]

RFC 2114                          DCAP                     February 1997


5.  Acknowledgments

   The authors wish to express thanks to Rodger Erickson of Wall Data,
   Inc. for his helpful comments and suggestions.

6.  References

   [1] AIW DLSw Related Interest Group, RFC 1795,
       "DLSw: Switch-to-Switch Protocol", April 1995

   [2] IBM Token Ring Network Architecture Reference
       SC30-3374-02, September 1989.

   [3] IBM LAN Technical Reference IEEE 802.2 and NETBIOS Application
       Program Interfaces SC30-3587-00, December 1993.

   [4] ISO 8802-2/IEEE Std 802.1D International Standard.

Authors' Addresses

   Steve T. Chiang
   InterWorks Business Unit
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA 95134
   Phone: [phone]
   EMail: [e-mail]

   Joseph S. Lee
   InterWorks Business Unit
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA 95134
   Phone: [phone]
   EMail: [e-mail]

   Hideaki Yasuda
   System Product Center
   Network Products Department
   Network Software Products Section B
   Mitsubishi Electric Corp.
   Information Systems Engineering Center
   325, Kamimachiya Kamakura Kanagawa 247, Japan
   Phone: [phone]
   EMail: [e-mail]






Chiang, et. al.              Informational                     [Page 22]