rfc2625.txt

<VC++网络游戏建摸与实现>源代码

 |    010    | MATCH_WW_NN        | OPTIONAL; see Appendix A        |
 +-----------+--------------------+---------------------------------+
 |    011    | MATCH_WW_PN_NN     | OPTIONAL; see Appendix A        |
 +-----------+--------------------+---------------------------------+
 |    100    | MATCH_IPv4         | OPTIONAL; see Appendix A        |
 +-----------+--------------------+---------------------------------+
 |    101    | MATCH_WW_PN_IPv4   | OPTIONAL; see Appendix A        |
 +-----------+--------------------+---------------------------------+
 |    110    | MATCH_WW_NN_IPv4   | OPTIONAL; see Appendix A        |
 +-----------+--------------------+---------------------------------+
 |    111    | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A        |
 +-----------+--------------------+---------------------------------+

   When a node receives a FARP-REQ with Code Point b'001', it checks its
   WW_PN against the one set in 'WW_PN of Responder' field of the FARP-
   REQ command.  If there is a match, then the node issues a response
   according to the action indicated by the FARP Responder Flag.  See
   table below.

   WW_NN and IPv4 address fields are not used with the b'001' Code Point
   operation.  They SHALL be set to '0' or a valid address either by the
   Requester or the Requester and the Responder.

   Note that there can be utmost one FARP-REPLY per FARP-REQ.

5.5 Responder Flags

   The Responder Flags define what Responder action to take if the
   result of the Match Address Code Points is successful. 'Responder
   Flags' is an 8-bit field (bits 0-7) and is defined in the table
   below. This field is used only in a FARP-REQ.  This field is retained
   unchanged in a FARP-REPLY. If no bits are set, the Responder will
   take no action.








Rajagopal, et al.           Standards Track                    [Page 23]

RFC 2625             IP and ARP over Fibre Channel             June 1999


 +----------+-------------------------------------------------------+
 |          |                 FARP Responder Flag                   |
 +----------+----------------+--------------------------------------+
 | Bit      | Bit Name       |            Action                    |
 | Position |                |                                      |
 +----------+----------------+--------------------------------------+
 |    0     | INIT_P_LOGI    | Initiate a P_LOGI to the Requester   |
 +----------+----------------+--------------------------------------+
 |    1     | INIT_REPLY     | Send FARP_REPLY to Requester         |
 +----------+----------------+--------------------------------------+
 | 2 to 7   | Reserved       |                                      |
 +----------+----------------+--------------------------------------+

   If INIT_P_LOGI bit is set then, a Login is performed with the port
   identified by "Port_ID of Requester" field.

   If INIT_REPLY is set then, a FARP-REPLY is sent to the Port
   Identified by "Port_ID of Requester" field.

   If both bits are set at the same time, then both Actions are
   performed.

   All other bit patterns are undefined at this time and are reserved
   for possible future use.

5.6 FARP Support Requirements

   Responder action - FARP-REPLY and/or Port Login - for a successful
   MATCH_WW_PN is always REQUIRED. If there is no address match then a
   silent behavior is specified.

   Support for all other Match Address Code Points is OPTIONAL and a
   silent behavior from the Responder is valid when it is not supported.
   Recipients of the FARP-REQ ELS SHALL NOT issue a Service Reject
   (LS_RJT) if FARP OPTIONAL mechanisms are not supported.

   In all cases, if there are no matches, then a silent behavior is
   specified.

   If an implementation issues a FARP-REQ with a Match Address Code
   Point that is OPTIONAL, and fails to receive a response, and the
   implementation has not obtained the Port_ID of the Responder's port
   by other means (e.g., prior FARP-REQ with other Code Points), then
   the implementation SHALL reattempt the FARP-REQ with the MATCH_WW_PN
   Code Point.






Rajagopal, et al.           Standards Track                    [Page 24]

RFC 2625             IP and ARP over Fibre Channel             June 1999


   Getting multiple FARP Replies corresponding to a single FARP-REQ
   should normally never occur.  It is beyond the scope of this document
   to specify conditions under which this error may occur or what the
   corrective action ought to be.

6. Exchange Management

6.1 Exchange Origination

   FC Exchanges shall be established to transfer data between ports.
   Frames on IP exchanges shall not transfer Sequence Initiative. See
   Appendix E for a discussion on FC Exchanges.

6.2 Exchange Termination

   With the exception of the recommendations in Appendix F, Section F.1,
   "Reliability in Class 3", the mechanism for aging or expiring
   exchanges based on activity, timeout, or other method is outside the
   scope of this document.

   Exchanges may be terminated by either port. The Exchange Originator
   may terminate Exchanges by setting the LS bit, following normal FC
   standard FC-PH [2] rules. This specification prohibits the use of the
   NOP ELS with LS set for Exchange termination.

   Exchanges may be torn down by the Exchange Originator or Exchange
   Responder by using the ABTS_LS protocol. The use of ABTS_LS for
   terminating aged Exchanges or error recovery is outside the scope of
   this document.

   The termination of IP Exchanges by Logout is discouraged, since this
   may terminate active Exchanges on other FC-4s.

7. Summary of Supported Features

   Note: 'Settable' means support is as specified in the relevant
   standard; all other key words are as defined earlier in this
   document.

7.1  FC-4 Header

 +--------------------------------------------------------------------+
 |                   Feature                     |   Support  | Notes |
 +--------------------------------------------------------------------+
 | Type Code ( = 5) ISO8802-2 LLC/SNAP           | REQUIRED   |   2   |
 | Network_Headers                               | REQUIRED   |   3   |
 | Other Optional Headers                        | MUST NOT   |       |
 +--------------------------------------------------------------------+



Rajagopal, et al.           Standards Track                    [Page 25]

RFC 2625             IP and ARP over Fibre Channel             June 1999


   Notes:

      1. This table applies only to FC-4 related data, such as IP and
         ARP packets. This table does not apply to link services and
         other non-FC-4 sequences (PLOGI, for example) that must occur
         for normal operation.

      2. The TYPE field in the FC Header (Word 2 bits 31-24) MUST
         indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This
         revision of the document focuses solely on the issues related
         to running IP and ARP over FC. All other issues are outside
         the scope of this document, including full support for IEEE
         802.2 LLC.

      3. DF_CTL field (Word 3, bits 23-16 of FC-Header) MUST indicate
         the presence of a Network_Header (0010 0000) on the First
         logical Frame of FC-4 Sequences.  It should not indicate the
         presence of a Network_Header on any subsequent frames of the
         Sequence.

7.2 R_CTL

   R_CTL in FC-Header: Word 0, bits 31-24
 +--------------------------------------------------------------------+
 |                      Feature                  |   Support  | Notes |
 +--------------------------------------------------------------------+
 | Information Category (R_CTL Routing):         |            |       |
 |                                               |            |       |
 |      FC-4 Device Data                         | REQUIRED   |   1   |
 |      Extended Link Data                       | REQUIRED   |       |
 |      FC-4 Link Data                           | MUST NOT   |       |
 |      Video Data                               | MUST NOT   |       |
 |      Basic Link Data                          | REQUIRED   |       |
 |      Link Control                             | REQUIRED   |       |
 |                                               |            |       |
 | R_CTL information :                           |            |       |
 |                                               |            |       |
 |      Uncategorized                            | MUST NOT   |       |
 |      Solicited Data                           | MUST NOT   |       |
 |      Unsolicited Control                      | REQUIRED   |       |
 |      Solicited Control                        | REQUIRED   |       |
 |      Unsolicited Data                         | REQUIRED   |   1   |
 |      Data Descriptor                          | MUST NOT   |       |
 |      Unsolicited Command                      | MUST NOT   |       |
 |      Command Status                           | MUST NOT   |       |
 +--------------------------------------------------------------------+





Rajagopal, et al.           Standards Track                    [Page 26]

RFC 2625             IP and ARP over Fibre Channel             June 1999


   Notes:

      1. This is REQUIRED for FC-4 (IP and ARP) packets

         - Routing bits of R_CTL field MUST indicate Device Data
           frames (0000)
         - Information Category of R_CTL field MUST indicate
           Unsolicited Data (0100)

7.3 F_CTL

   F_CTL in FC-Header: Word 2, bits 23-0
 +--------------------------------------------------------------------+
 |                      Feature                  |   Support  | Notes |
 +--------------------------------------------------------------------+
 | Exchange Context                              | Settable   |       |
 | Sequence Context                              | Settable   |       |
 | First / Last / End Sequence (FS/LS/ES)        | Settable   |       |
 | Chained Sequence                              | MUST NOT   |       |
 | Sequence Initiative (SI)                      | Settable   |   1   |
 | X_ID Reassigned / Invalidate                  | MUST NOT   |       |
 | Unidirectional Transmit                       | Settable   |       |
 | Continue Sequence Condition                   | REQUIRED   |   2   |
 | Abort Seq. Condition -continue and single Seq.| REQUIRED   |   3   |
 | Relative Offset - Unsolicited Data            | Settable   |   4   |
 | Fill Bytes                                    | Settable   |       |
 +--------------------------------------------------------------------+

   Notes

      1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for
         sending data to each N_Port in the network and a dedicated
         RX_ID for receiving data from each N_Port as well. Exchanges
         are used in a unidirectional mode, thus setting Sequence
         Initiative is not valid for FC-4 frames. Sequence Initiative is
         valid when using Extended Link Services.

      2. This field is required to be 00, no information.

      3. Sequence error policy is requested by an exchange originator in
         the F_CTL Abort Sequence Condition bits in the first data frame
         of the exchange. For Classes 1 and 2, ACK frame is required to
         be "continuous sequence".

      4. Relative offset prohibited on all other types (Information
         Category) of frames.





Rajagopal, et al.           Standards Track                    [Page 27]

RFC 2625             IP and ARP over Fibre Channel             June 1999


7.4 Sequences

 +---------------------------------------------------------------------+
 |                      Feature                    |   Support  |Notes |
 +---------------------------------------------------------------------+
 | Class 2 open Sequences / Exchange               |     1      |   1  |
 | Length of Seq. not limited by end-to-end credit | REQUIRED   |   2  |
 | IP and ARP Packet and FC Data Field sizes       | REQUIRED   |   3  |
 | Capability to receive Sequence of maximum size  | OPTIONAL   |   4  |
 | Sequence Streaming                              | MUST NOT   |   5  |
 | Stop Sequence Protocol                          | MUST NOT   |      |
 | ACK_0 support                                   | OPTIONAL   |   6  |
 | ACK_1 support                                   | REQUIRED   |   6  |
 | ACK_N support                                   | MUST NOT   |      |
 | Class of Service for transmitted Sequences      |  Class     |   7  |
 |                                                 | 1, 2, or 3 |      |
 | Continuously Increasing Sequence Count          | OPTIONAL   | 8, 9 |
 +---------------------------------------------------------------------+

   Notes:

      1. Only one active sequence per exchange is optional.

      2. A Sequence Initiator shall be capable of transmitting Sequences
         containing more frames than the available credit indicated by a
         Sequence recipient at Login. FC-PH [2] end-to-end flow control
         rules will be followed when transmitting such Sequences.

      3.  a) IP MTU size is 65280-bytes and resulting FC Sequence
             Payload size is 65536-bytes.
          b) Maximally Minimum IP Packet size is 68-bytes and resulting
             FC Data Field size is 92-bytes.
          c) ARP (and InARP) Packet size is 28-bytes and resulting FC
             Data Field size is 52-bytes.

      4. Some OS environments may not handle the max Sequence Payload
         size of 65536. It is up to the administrator to configure the
         Max size for all systems.

      5. All class 3 sequences are assumed to be non-streamed.

      6. Only applies for