rfc2106.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,068 行 · 第 1/3 页

           +---------------+-----------------------------+
           | Packet Length | 0x10 + Length of user data  |
           +---------------+-----------------------------+
                     Figure 3-12. DATA_FRAME Header













Chiang, et. al.              Informational                     [Page 13]

RFC 2106                         DLSRAP                    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 DRAP, the capability exchange frame is used to exchange the
   client's information, such as its MAC address, with the server. If a
   DRAP client has its own MAC address defined, it should put it in the
   MAC address field. Otherwise, that field must be set to zero.

   When the DRAP server receives the CAP_XCHANGE frame, it should cache
   the MAC address if it is non zero. The DRAP 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



Chiang, et. al.              Informational                     [Page 14]

RFC 2106                         DLSRAP                    February 1997


   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
   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.

   Starting with the Reserved field, implementors 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



Chiang, et. al.              Informational                     [Page 15]

RFC 2106                         DLSRAP                    February 1997


   ensure compatibility, implementors 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: 6 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 16]

RFC 2106                         DLSRAP                    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 17]

RFC 2106                         DLSRAP                    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 DRAP







Chiang, et. al.              Informational                     [Page 18]

RFC 2106                         DLSRAP                    February 1997


4.  References

   [1] Wells, L., Chair, and A. Bartky, Editor, "DLSw: Switch-to-Switch
       Protocol", RFC 1795, October 1993.

   [2] IEEE 802.1D 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 19]