RFC 2625
IP and ARP over Fibre Channel
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:
- 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.
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 | +-------------------------------------+---------+---------------------+
+---------------------------------------------------------------------+ | 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.
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.
+------------------------------------------------------------------+ | 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.
+----------+-------------------------------------------------------+ | | 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.
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 | | +--------------------------------------------------------------------+
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 | |
+--------------------------------------------------------------------+
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.
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).
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.
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.
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_Ports7.8 Login Parameters
Unless explicitly noted here, a compliant implementation shall use the login parameters as described in [4].
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].
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
[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.
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
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.
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 | +-------+--------------------+---------------------------------------+
+---------------------------------------------------------------------+ | 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 | +-------------------------------+---------+---------------------------+
+---------------------------------------------------------------------+ | 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 page on part 3)
