tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 2625

 
 
 

IP and ARP over Fibre Channel

Part 2 of 3, p. 18 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
5.  FARP

5.1 Scope

   FC Layer Mapping between the WW_PN and the Port_ID is independent of
   the ARP mechanism and is more closely associated with the details of
   the FC protocols. Name Server and FC Address Resolution Protocol
   (FARP) are two formal mechanisms that can be used to create and
   maintain WW_PN to Port_ID tables.

   FARP is a method using Extended Link Service (ELS) commands that
   resolves <WW_PN, Port_ID> mappings. The WW_PN to Port_ID address
   resolution using FARP is especially useful in instances where the
   Login table entries at a node expire and a Name Server is not
   available.  It is outside the scope of this document to describe Name
   Server. (See [14].)

   Additional address matching mechanisms that resolve <WW_NN, Port_ID>
   and <IP addr., Port_ID> mapping have been added to FARP. These
   additional mechanisms are optional and described in Appendix A.
   Direct IP address to Port_ID mapping is useful in applications where
   there is no visibility of the MAC address.

   Other less formal FC Layer Mapping mechanisms are described in
   Appendix C.

   Since Port_IDs are volatile, all mapped Port_IDs  at all times MUST
   be valid before use. There are many events that can invalidate this
   mapping. Appendix D discusses conditions when such a validation is
   required.

5.2 FARP Overview

   The FARP protocol uses two ELS commands - FARP-REQ and FARP-REPLY.

   Note: In the following discussion 'Requester' means the node
      issuing the FARP-REQ ELS message; 'Responder' means the
      node replying to the request by sending the FARP-REPLY
      command.

   The FARP-REQ ELS Broadcast Request command is used to retrieve a
   specific node's current Port_ID given its unique WW_PN. This Port_ID
   is sent in a FARP-REPLY unicast command.

   The FARP-REQ may indicate that the Responder:

Top      Up      ToC       Page 19 
          - Perform only a Login with it (Requester) or,
          - Send only a FARP-REPLY or,
          - Perform a Login and send a FARP-REPLY.

   No sequence initiative is transferred with the FARP-REQ and therefore
   no Reply (ACCEPT or REJECT) follows this command.

   Since a Sequence Initiative is transferred with the FARP-REPLY,
   either a ACCEPT or REJECT follows this command as a response.

   Reception of a FARP-REQ requires a higher level entity at the
   responding node to send a FARP-REPLY or perform a Port Login.

   You do not have to be logged in to issue a FARP Request. Also, you do
   not have to be logged in to the FARP Requester to issue a FARP-REPLY.

   The FARP Protocol Steps:

        FARP-REQ (ELS broadcast) Request Sequence

             (No Reply Sequence)

        FARP-REPLY (ELS command) Sequence

             Accept/Reject Reply Sequence

   The FARP Protocol Format [2] and Size:

          FT_1, 76-bytes fixed size

   The FARP Protocol Addressing:

      - In a FARP-REQ, the S_ID in the FC Header designates the
      Requester's Port ID. The D_ID in the FC Header is the broadcast
      identifier 0xFF-FF-FF.

      - In a FARP-REPLY, the S_ID in the FC Header designates the
      Responder's Port_ID. The D_ID in the FC Header is the Requester's
      Port_ID.

Top      Up      ToC       Page 20 
5.3 FARP Command Format

   FARP-REQ and FARP-REPLY commands have identical formats (76-bytes
   fixed size) and fields but use different command codes. See tables
   below.

 +---------------------------------------------------------------------+
 |                         FARP-REQ Command                            |
 +-------------------------------------+---------+---------------------+
 |               Field                 | Size    |   Remarks           |
 |                                     | (Bytes) |                     |
 +-------------------------------------+---------+---------------------+
 | 0x54-00-00-00                       |   4     | Request Command Code|
 +-------------------------------------+---------+---------------------+
 | Match Address Code Points           |   1     | Indicates Address   |
 |                                     |         | Matching  Mechanism |
 +-------------------------------------+---------+---------------------+
 | Port_ID of Requester                |   3     | Supplied by         |
 |                                     |         | Requester =         |
 |                                     |         | S_ID in FC Header   |
 +-------------------------------------+---------+---------------------+
 | Responder Flags                     |   1     | Response Action to  |
 |                                     |         | be taken            |
 +-------------------------------------+---------+---------------------+
 | Port_ID of Responder                |   3     | Set to 0x00-00-00   |
 +-------------------------------------+---------+---------------------+
 | WW_PN of Requester                  |   8     |Supplied by Requester|
 +-------------------------------------+---------+---------------------+
 + WW_NN of Requester                  |   8     |OPTIONAL;            |
 |                                     |         |See Appendix A       |
 +-------------------------------------+---------+---------------------+
 | WW_PN of Responder                  |   8     |Supplied by Requester|
 +-------------------------------------+---------+---------------------+
 | WW_NN of Responder                  |   8     |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+
 | IP Address of Requester             |   16    |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+
 | IP Address of Responder             |   16    |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+

Top      Up      ToC       Page 21 
 +---------------------------------------------------------------------+
 |                         FARP-REPLY Command                          |
 +-------------------------------------+---------+---------------------+
 |               Field                 | Size    |   Remarks           |
 |                                     | (Bytes) |                     |
 +-------------------------------------+---------+---------------------+
 | 0x55-00-00-00                       |   4     | Reply Command Code  |
 +-------------------------------------+---------+---------------------+
 | Match Address Code Points           |   1     | Not Used and        |
 |                                     |         | Unchanged from the  |
 |                                     |         | FARP-REQ            |
 +-------------------------------------+---------+---------------------+
 | Port_ID of Requester                |   3     | Extracted from      |
 |                                     |         | FARP-REQ            |
 +-------------------------------------+---------+---------------------+
 | Responder Flags                     |   1     | Not Used  and       |
 |                                     |         | Unchanged from the  |
 |                                     |         | FARP-REQ            |
 +-------------------------------------+---------+---------------------+
 | Port_ID of Responder                |   3     | Supplied by         |
 |                                     |         | Responder =         |
 |                                     |         | S_ID in FC Header   |
 +-------------------------------------+---------+---------------------+
 |WW_PN of Requester                   |   8     |Supplied by Requester|
 +-------------------------------------+---------+---------------------+
 |WW_NN of Requester                   |   8     |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+
 |WW_PN of Responder                   |   8     |Supplied by Requester|
 +-------------------------------------+---------+---------------------+
 |WW_NN of Responder                   |   8     |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+
 |IP Add. of Requester                 |   16    |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+
 |IP Address of Responder              |   16    |OPTIONAL; see App. A |
 +-------------------------------------+---------+---------------------+

   Following is a description of the address fields in the FARP
   Commands.

   Port_ID of Requester:

   It is the 24-bit Port_ID used in the S_ID field of the FC Header of a
   FARP-REQ.  It is supplied by the Requester in a FARP-REQ and retained
   in a FARP-REPLY.

Top      Up      ToC       Page 22 
   Port_ID of Responder:

   It is the 24-bit Port_ID used in the S_ID field of the FC Header of a
   FARP-REPLY.  It SHALL be set to 0x00-00-00 in a FARP-REQ. It is
   supplied by the Responder in a FARP-REPLY.

   WW_PN:

   This address field is used with the b'001', b'011', b'101, b'111',
   Match Address Code Points. See Match Address Code Point Table below.
   The Requester supplies the unique 8-byte WW_PN of the Requester and
   the Responder. It is retained in a FARP-REPLY.

   WW_NN:

   The WW_NN address field is used with Match Address Code Points
   b'010', b'011', b'110', and b'111', which are all optional. Its usage
   is fully described in Appendix A. When the WW_NN field is not used it
   SHALL be either set to '0' or a valid non-zero address.

   IPv4:

   The IPv4 address field is used with the Match Address Code Points
   b'100', b'101', b'110', and b'111', which are all optional. Its usage
   is fully described in Appendix A. When the IP Address field is not
   used it SHALL be either set to '0' or a valid IP address. A valid IP
   address consists of the 32-bit IPv4 Address with the upper 96 bits
   set to '0'.

5.4 Match Address Code Points

   For each receipt of the FARP-REQ Broadcast ELS, the recipients match
   one or more addresses based on the encoded bits of the "FARP Match
   Address Code Points" field shown in the table below. FARP operation
   with the Match Address Code Point equal to b'001' is described in
   this section. Other code points are OPTIONAL and are discussed in
   Appendix A. The upper 5 bits of the Match Address Code Point byte are
   unused and their use is not currently defined.

Top      Up      ToC       Page 23 
 +------------------------------------------------------------------+
 |                     Match Address Code Points                    |
 +------------------------------------------------------------------+
 |   LSBits  |     Bit name       |           Action                |
 +-----------+--------------------+---------------------------------+
 |    000    | Reserved           |                                 |
 +-----------+--------------------+---------------------------------+
 |    001    | MATCH_WW_PN        | If 'WW_PN of Responder' =       |
 |           |                    | Node's WW_PN then respond       |
 +-----------+--------------------+---------------------------------+
 |    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.

Top      Up      ToC       Page 24 
 +----------+-------------------------------------------------------+
 |          |                 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.

Top      Up      ToC       Page 25 
   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   |       |
 +--------------------------------------------------------------------+

Top      Up      ToC       Page 26 
   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   |       |
 +--------------------------------------------------------------------+

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
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 Class 1 and 2. Use of ACK_1 is default, ACK_0
         used if indicated by Sequence recipient at Login.

      7. The administrator configured class of service is used, except
         where otherwise specified (e.g. Broadcasts are always sent in
         Class 3).

Top      Up      ToC       Page 29 
      8. Review Appendix F, "Reliability in Class 3".

      9. The first frame of the first sequence of a new Exchange must
         have SEQ_CNT = 0 [2].

7.5 Exchanges

 +--------------------------------------------------------------------+
 |                      Feature                  |   Support  | Notes |
 +--------------------------------------------------------------------+
 | X_ID interlock support                        | OPTIONAL   |   1   |
 | OX_ID=FFFF                                    | MUST NOT   |       |
 | RX_ID=FFFF                                    | OPTIONAL   |   2   |
 | Action if no exchange resources available     | P_RJT      |   3   |
 | Long Lived Exchanges                          | OPTIONAL   |   4   |
 | Reallocation of Idle Exchanges                | OPTIONAL   |       |
 +--------------------------------------------------------------------+

   Notes:

      1. Only applies to Classes 1 and 2, supported by the Exchange
         Originator. A Port SHALL be capable of interoperating with
         another Port that requires X_ID interlock. The Exchange
         Originator facility within the Port shall use the X_ID
         Interlock protocol in such cases.

      2. An Exchange Responder is not required to assign RX_IDs. If a
         RX_ID of FFFF is assigned, it is identifying Exchanges based on
         S_ID / D_ID / OX_ID only.

      3. In Classes 1 and 2, a Port shall reject a frame that would
         create a new Exchange with a P_RJT containing reason code
         "Unable to establish Exchange". In Class 3, the frame would be
         dropped.

      4. When an Exchange is created between 2 Ports for IP/ARP data, it
         remains active while the ports are logged in with each other.
         An Exchange SHALL NOT transfer Sequence Initiative (SI).
         Broadcasts and ELS commands may use short lived Exchanges.

Top      Up      ToC       Page 30 
7.6 ARP and InARP

 +--------------------------------------------------------------------+
 |                      Feature                  |   Support  | Notes |
 +--------------------------------------------------------------------+
 | ARP Server Support                            | MUST  NOT  |   1   |
 | Response to ARP requests                      | REQUIRED   |   2   |
 | Class of Service for ARP requests             | Class 3    |   3   |
 | Class of Service for ARP replies              |  Class     |   4   |
 |                                               | 1, 2, or 3 |       |
 | Response to InARP requests                    | OPTIONAL   |       |
 | Class of Service for InARP requests/replies   | Class      |       |
 |                                               | 1, 2 or 3  |   5   |
 +--------------------------------------------------------------------+

 Notes:

      1. Well-known Address FFFFFC is not used for ARP requests. Frames
         from Well-known address FFFFFC are not considered to be ARP
         frames. Broadcast support is REQUIRED for ARP.

      2. The IP Address is mapped to a specific MAC address with ARP.

      3. An ARP request is a Broadcast Sequence, therefore Class 3
         is always used.

      4. An ARP reply is a normal Sequence, thus the administrator
         configured class of service is used.

      5. An InARP Request or Reply is a normal Sequence, thus an
         administrator configured class of service is used.

Top      Up      ToC       Page 31 
7.7 Extended Link Services (ELS)

 +--------------------------------------------------------------------+
 |                      Feature                  |   Support  | Notes |
 +--------------------------------------------------------------------+
 | Class of service for ELS commands / responses | Class      |       |
 |                                               | 1,2 or 3   |   1   |
 | Explicit N-Port Login                         | REQUIRED   |       |
 | Explicit F-Port Login                         | REQUIRED   |       |
 | FLOGI ELS command                             | REQUIRED   |       |
 | PLOGI ELS command                             | REQUIRED   |       |
 | ADISC ELS command                             | REQUIRED   |       |
 | PDISC ELS command                             | OPTIONAL   |   2   |
 | FAN ELS command                               | REQUIRED   |   5   |
 | LOGO ELS command                              | REQUIRED   |       |
 | FARP-REQ/FARP-REPLY ELS commands              | REQUIRED   |   3   |
 | Other ELS command support                     | OPTIONAL   |   4   |
 +-----------------------------------------------+------------+-------+

   Notes:

      1. The administrator configured class of service is used.

      2. PDISC shall not be used as a Requester; ADISC shall be used
         instead. As a Responder, an implementation may need to respond
         to both ADISC and PDISC for compatibility with other
         specifications.

      3. Responder Action - FARP-REPLY and/or Port Login - for a
         successful MATCH_WW_PN is always REQUIRED.
         Support for all other match Address Codes Points is 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 is not supported.

      4. If other ELS commands are received an LS_RJT may be sent. NOP
         is not required by this specification, and shall not be used as
         a mechanism to terminate exchanges.

      5. Required for FL_Ports

7.8 Login Parameters

   Unless explicitly noted here, a compliant implementation shall use
   the login parameters as described in [4].

Top      Up      ToC       Page 32 
7.8.1 Common Service Parameters - FLOGI

   - FC-PH Version, lowest version may be 0x09 to indicate
     'minimum 4.3'.
   - Can't use BB_Credit=0 for N_Port on a switched Fabric
     (F_Port).

7.8.2 Common Service Parameters - PLOGI

   - FC-PH Version, lowest version may be 0x09 to indicate
     'minimum 4.3'.
   - Can't use BB_Credit=0 for N_Port in a Point-to-Point
     configuration

   - Random Relative Offset is optional.

   - Note that the 'Receive Data Field Size' fields specified in
     the PLOGI represent both optional headers and payload.

   - The MAC Address can therefore be extracted from the 6 lower
     bytes of the WW_PN field (when the IEEE 48-bit Identifier
     format is chosen as the NAA) during PLOGI or ACC payload
     exchanged during Fibre Channel Login [2].

   - The MAC Address can also be extracted from the WW_PN field in
     the Network_Header during ADISC (and ADISC ACC), or PDISC
     (and PDISC ACC).

7.8.3 Class Service Parameters - PLOGI

   - Discard error policy only.

8. Security Considerations

8.1 IP and ARP Related

   IP and ARP do not introduce any new security concerns beyond what
   already exists within the Fibre Channel Protocols and Technology.
   Therefore IP and ARP related Security does not require special
   consideration in this document.

8.2 FC Related

   FC Standards [11] specify a Security Key Server (independent of IP
   and ARP) as an optional service. However, there are no known
   implementations of this server yet. Also, the previously defined [2]
   use of a Security Header has been discontinued [11].

Top      Up      ToC       Page 33 
9. Acknowledgement

   This specification is based on FCA IP Profile, Version 3.3.  The FCA
   IP Profile was a joint work of the Fibre Channel Association (FCA)
   vendor community.  The following organizations or individuals have
   contributed to the creation of the FCA IP Profile: Adaptec, Ancor,
   Brocade, Clariion, Crossroads, emf Associates, Emulex, Finisar,
   Gadzoox, Hewlett Packard, Interphase, Jaycor, McData, Migration
   Associates, Orca Systems, Prisa, Q-Logic, Symbios, Systran,
   Tektronix, Univ. of Minnesota, Univ. of New Hamshire. Jon Infante
   from Emulex deserves special mention for his contributions to the
   FARP Protocol. The authors extend their thanks to all who provided
   comments and especially to Lansing Sloan from LLNL for his detailed
   comments.

10. References

   [1] FCA IP Profile, Revision 3.3, May 15, 1997

   [2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI
       X3.230-1994

   [3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26,
       1996

   [4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.7, August
       12, 1997

   [5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA),
       Rev. 2.1, September 22, 1997

   [6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2),
       Rev. 7.4, ANSI X3.297-1996

   [7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996

   [8] Postel, J. and J. Reynolds, "A standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February
       1988.

   [9] Plummer, D. "An Ethernet Address Resolution Protocol -or-
       Converting Network Addresses to 48-bit Ethernet Address for
       Transmission on Ethernet Hardware", STD 37, RFC 826, November
       1982.

   [10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995

Top      Up      ToC       Page 34 
   [11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3),
        Rev. 9.3, ANSI X3.303-199x

   [12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek",
        Ancot Corporation

   [13] Fibre Channel -Gigabit Communications and I/O for Computers
        Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2

   [14] Fibre Channel Generic Services -2 (FC-GS-2), Rev. 5.2
        X3.288-199x

   [15] Bradley, T. and C. Brown, "Inverse Address Resolution Protocol",
        RFC 1293, January 1992.

   [16] Bradley, T., Brown, C. and A. Malis, "Inverse Address Resolution
        Protocol", RFC 2390, August 1992.

   [17] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [18] The Fibre Channel Consultant: A Comprehensive Introduction,
        "Robert W. Kembel", Northwest Learning Associates, 1998

   [19] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [20] Narten, T. and C. Burton, "A Caution on The Canonical Ordering
        of Link-Layer Addresses",  RFC 2469, December 1998.

Top      Up      ToC       Page 35 
11. Authors' Addresses

   Murali Rajagopal
   Gadzoox Networks, Inc.
   711 Kimberly Avenue, Suite 100
   Placentia, CA 92870

   Phone: +1 714 577 6805
   Fax: +1 714 524 8508
   EMail: murali@gadzoox.com


   Raj Bhagwat
   Gadzoox Networks, Inc.
   711 Kimberly Avenue, Suite 100
   Placentia, CA 92870

   Phone: +1 714 577 6806
   Fax: +1 714 524 8508
   EMail: raj@gadzoox.com


   Wayne Rickard
   Gadzoox Networks, Inc.
   711 Kimberly Avenue, Suite 100
   Placentia, CA 92870

   Phone: +1 714 577 6803
   Fax: +1 714 524 8508
   EMail: wayne@gadzoox.com

Top      Up      ToC       Page 36 
Appendix A: Additional Matching Mechanisms in FARP

   Section 5 described the FC Layer mapping between the WW_PN and the
   Port_ID using the FARP Protocol. This appendix describes other
   optional criteria for address matching and includes:

      - WW_NN

      - WW_PN & WW_NN at the same time

      - IPv4

      - IPv4 & WW_PN at the same time

      - IPv4 & WW_NN at the same time

      - IPv4 & WW_PN & WW_NN at the same time

   Depending on the Match Address Code Points, the FARP protocol
   fundamentally resolves three main types of addresses to Port_IDs and
   is described in table below.

      - For Match Address Code Point b'001':  WW_PN Names fields are
        used to resolve the WW_PN names to Port_IDs.  WW_NN and IP
        address fields are not used with these Code Points and SHALL be
        set to either '0' or valid addresses by Requester or Requester
        and Responder.

      - For Match Address Code Point b'010':  WW_NN Names fields are
        used to resolve the WW_NN names to Port_IDs.  WW_PN and IP
        address fields are not used with these Code Points and SHALL be
        set to either '0' or valid addresses by Requester or Requester
        and Responder.

      - For Match Address Code Point b'100':  IPv4 fields are used to
        resolve the IPv4 addresses to Port_IDs.  WW_PN and WW_NN fields
        are not used with these Code Points and SHALL be set to either '
        0' or valid addresses by Requester or Requester and Responder.

      - For all other Match Address Code Points b'011', b'101',b'110',
        b'111', depending on set bits one or more addresses are jointly
        resolved to a Port_ID. See table below. If fields are not used,
        then they are set either to '0' or valid addresses.

   The Responder Flags remain the same as before. Note that there can be
   utmost one FARP-REPLY per FARP-REQ.

Top      Up      ToC       Page 37 
   Tables showing FARP-REQ and FARP-REPLY and address fields setting are
   given below:

 +--------------------------------------------------------------------+
 |                       Match Address Code Points                    |
 +--------------------------------------------------------------------+
 | LSBits|      Bit name      |             Action                    |
 +-------+--------------------+---------------------------------------+
 | 000   |   Reserved         |                                       |
 +-------+--------------------+---------------------------------------+
 | 001   | MATCH_WW_PN        | If 'WW_PN of Responder' =             |
 |       |                    | Node's WW_PN then respond             |
 +-------+--------------------+---------------------------------------+
 | 010   | MATCH_WW_NN        | If 'WW_NN of Responder' =             |
 |       |                    | Node's WW_NN then respond             |
 +-------+--------------------+---------------------------------------+
 | 011   | MATCH_WW_PN_NN     | If both 'WW_PN of Responder' &        |
 |       |                    | 'WW_NN of Responder' =                |
 |       |                    | Node's WW_PN & WW_NN then respond     |
 +-------+--------------------+---------------------------------------+
 | 100   | MATCH_IPv4         | If 'IPv4 Address of Responder' =      |
 |       |                    | Node's IPv4 Address then respond      |
 +-------+--------------------+---------------------------------------+
 | 101   | MATCH_WW_PN_IPv4   | If 'WW_PN & IPv4 of Responder' =      |
 |       |                    | Node's WW_PN and IPv4 then respond    |
 +-------+--------------------+---------------------------------------+
 | 110   | MATCH_WW_NN_IPv4   | If both 'WW_NN of Responder' &        |
 |       |                    | 'IPv4 Address of Responder' =         |
 |       |                    | Node's WW_NN & IPv4 then respond      |
 +-------+--------------------+---------------------------------------+
 | 111   |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' &             |
 |       |                    | 'WW_NN of Responder' &                |
 |       |                    | 'IPv4 Address of Responder' =         |
 |       |                    | Nodes' WW_PN & WW_NN & IPv4           |
 |       |                    | then respond                          |
 +-------+--------------------+---------------------------------------+

Top      Up      ToC       Page 38 
 +---------------------------------------------------------------------+
 |                         FARP-REQ Command                            |
 +-------------------------------+---------+---------------------------+
 |               Field           | Size    |         Remarks           |
 |                               | (Bytes) |                           |
 +-------------------------------+---------+---------------------------+
 | 0x54-00-00-00                 |   4     | Request Command Code      |
 +-------------------------------+---------+---------------------------+
 | Match Address Code Points     |   1     | Indicates Address         |
 |                               |         | Matching Mechanism        |
 +-------------------------------+---------+---------------------------+
 | Port_ID of Requester          |   3     |Supplied by Requester      |
 +-------------------------------+---------+---------------------------+
 | Responder Flags               |   1     |Response Action to be taken|
 +-------------------------------+---------+---------------------------+
 | Port_ID of Responder          |   3     | Set to 0x00-00-00         |
 +-------------------------------+---------+---------------------------+
 |WW_PN of Requester             |   8     | Supplied by Requester     |
 +-------------------------------+---------+---------------------------+
 |WW_NN of Requester             |   8     |OPTIONAL;                  |
 |                               |         |Supplied by Requester      |
 +-------------------------------+---------+---------------------------+
 |WW_PN of Responder             |   8     |Supplied by Requester      |
 +-------------------------------+---------+---------------------------+
 |WW_NN of Responder             |   8     |OPTIONAL ;Supplied by      |
 |                               |         |Requester or Responder     |
 +-------------------------------+---------+---------------------------+
 |IP Add. of Requester           |   16    |OPTIONAL; Supplied by      |
 |                               |         |Requester                  |
 |                               |         |IPv4 Add.=low 32 bits      |
 +-------------------------------+---------+---------------------------+
 |IP Address of Responder        |   16    |OPTIONAL; Supplied by      |
 |                               |         |Requester or Responder     |
 |                               |         |IPv4 Add.=low 32 bits      |
 +-------------------------------+---------+---------------------------+

Top      Up      ToC       Page 39 
 +---------------------------------------------------------------------+
 |                         FARP-REPLY Command                          |
 +-------------------------------+---------+---------------------------+
 |               Field           | Size    |        Remarks            |
 |                               | (Bytes) |                           |
 +-------------------------------+---------+---------------------------+
 | 0x55-00-00-00                 |   4     |Reply Command Code         |
 +-------------------------------+---------+---------------------------+
 | Match Address Code Points     |   1     | Not Used and unchanged    |
 |                               |         |from the FARP-REQ          |
 +-------------------------------+---------+---------------------------+
 | Port_ID of Requester          |   3     |Supplied by Requester      |
 +-------------------------------+---------+---------------------------+
 | Responder Flags               |   1     | Not Used and unchanged    |
 |                               |         |from the FARP-REQ          |
 +-------------------------------+---------+---------------------------+
 | Port_ID of Responder          |   3     |Supplied by Responder      |
 +-------------------------------+---------+---------------------------+
 |WW_PN of Requester             |   8     |Supplied by Requester      |
 +-------------------------------+---------+---------------------------+
 |WW_NN of Requester             |   8     |OPTIONAL; Supplied by      |
 |                               |         |Requester                  |
 +-------------------------------+---------+---------------------------+
 |WW_PN of Responder             |   8     |Supplied by Requester      |
 +-------------------------------+---------+---------------------------+
 |WW_NN of Responder             |   8     |OPTIONAL; Supplied by      |
 |                               |         |Requester or Responder     |
 +-------------------------------+---------+---------------------------+
 |IP Add. of Requester           |   16    |OPTIONAL; Supplied by      |
 |                               |         |Requester                  |
 |                               |         |IPv4 Add.=low 32 bits      |
 +-------------------------------+---------+---------------------------+
 |IP Address of Responder        |   16    |OPTIONAL; Supplied by      |
 |                               |         |Requester or Responder     |
 |                               |         |IPv4 Add.=low 32 bits      |
 +-------------------------------+---------+---------------------------+


Next RFC Part