RFC 4172
iFCP - A Protocol for Internet Fibre Channel Storage Networking
6. TCP Session Control Messages
TCP session control messages are used to create and manage an iFCP session as described in Section 5.2.2. They are passed between peer iFCP Portals and are only processed within the iFCP layer. The message format is based on the fibre channel extended link service message template shown below. Word 0<--Bits-->7 8<---------------Bits------------------------>31 +------------+------------------------------------------------+ 0| R_CTL | D_ID [0x00 00 00] | |[Req = 0x22]| [Destination of extended link Service request] | |[Rep = 0x23]| | +------------+------------------------------------------------+ 1| CS_CTL | S_ID [0x00 00 00] | | [0x0] | [Source of extended link service request] | +------------+------------------------------------------------+ 2|TYPE [0x1] | F_CTL [0] | +------------+------------------+-----------------------------+ 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | |[0x0] | | | +------------+------------------+-----------------------------+ 4| OX_ID [0x0000] | RX_ID_[0x0000] | +-------------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_COMMAND | | [Session Control Command Code] | +-------------------------------------------------------------+ 7| | .| Additional Session Control Parameters | .| ( if any ) | n| | +=============================================================+ n| Fibre Channel CRC | +| | 1+=============================================================+ Figure 17. Format of Session Control Message
The LS_COMMAND value for the response remains the same as that used for the request. The session control frame is terminated with a fibre channel CRC. The frame SHALL be encapsulated and de-encapsulated according to the rules specified in Section 5.3. The encapsulation header for the link Service frame carrying a session control message SHALL be set as follows: Encapsulation Header Fields: LS_COMMAND_ACC 0 iFCP Flags SES = 1 TRP = 0 INT = 0 SOF code SOFi3 encoding (0x2E) EOF code EOFt encoding (0x42) The encapsulation time stamp words SHALL be set as described for each message type. The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above.
Table 6 lists the values assigned to byte 0 of the LS_COMMAND field
for iFCP session control messages.
+--------------+-------------------------+----------+-------------+
| LS_COMMAND | Function | Mnemonic | iFCP |
| field, byte 0| | | Support |
+--------------+-------------------------+----------+-------------+
| 0xE0 | Connection Bind | CBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE4 | Unbind Connection | UNBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE5 | Test Connection Liveness| LTEST | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0x01-0x7F | Vendor-Specific | | |
+--------------+-------------------------+----------+-------------+
| 0x00 | Reserved -- Unassignable| | |
+--------------+-------------------------+----------+-------------+
| All other | Reserved | | |
| values | | | |
+--------------+-------------------------+----------+-------------+
Table 6. Session Control LS_COMMAND Field, Byte 0 Values
6.1. Connection Bind (CBIND)
As described in Section 5.2.2.2, the CBIND message and response are used to bind an N_PORT login to a specific TCP connection and establish an iFCP session. In the CBIND request message, the source and destination N_PORTs are identified by their worldwide port names. The time stamp words in the encapsulation header SHALL be set to zero in the request and response message frames. The following shows the format of the CBIND request. +------+------------+------------+-----------+----------+ | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | | | (Seconds) | | | +------+-------------------------+-----------+----------+ | 2 | USER INFO | +------+------------+------------+-----------+----------+ | 3 | | +------+ SOURCE N_PORT NAME | | 4 | | +------+------------------------------------------------+ | 5 | | +------+ DESTINATION N_PORT NAME | | 6 | | +------+------------------------------------------------+ Addr Mode: The addressing mode of the originating gateway. 0 = Address Translation mode; 1 = Address Transparent mode. iFCP Ver: iFCP version number. SHALL be set to 1. LIVENESS TEST If non-zero, requests that the receiving INTERVAL: gateway transmit an LTEST message at the specified interval in seconds. If set to zero, LTEST messages SHALL NOT be sent. USER INFO: Contains any data desired by the requestor. This information MUST be echoed by the recipient in the CBIND response message. SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway originating the CBIND request.
DESTINATION N_PORT The Worldwide Port Name (WWPN) of the
NAME: N_PORT locally attached to the gateway
receiving the CBIND request.
The following shows the format of the CBIND response.
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+-------------------------+----------------------+
| 7 | Reserved | CBIND Status |
+------+-------------------------+----------------------+
| 8 | Reserved | CONNECTION HANDLE |
+------+-------------------------+----------------------+
Total Length = 36
Addr Mode: The address translation mode of the
responding gateway. 0 = Address
Translation mode, 1 = Address Transparent
mode.
iFCP Ver: iFCP version number. Shall be set to 1.
LIVENESS TEST If non-zero, requests that the gateway
INTERVAL: receiving the CBIND RESPONSE transmit an
LTEST message at the specified interval in
seconds. If zero, LTEST messages SHALL NOT
be sent.
USER INFO: Echoes the value received in the USER INFO
field of the CBIND request message.
SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of
the N_PORT locally attached to the gateway
issuing the CBIND request.
DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of
NAME: the N_PORT locally attached to the gateway
issuing the CBIND response.
CBIND STATUS: Indicates success or failure of the CBIND
request. CBIND values are shown below.
CONNECTION HANDLE: Contains a value assigned by the gateway to
identify the connection. The connection
handle is required when the UNBIND
request is issued.
CBIND Status Description
------------ -----------
0 Success
1 - 15 Reserved
16 Failed - Unspecified Reason
17 Failed - No such device
18 Failed - iFCP session already exists
19 Failed - Lack of resources
20 Failed - Incompatible address translation mode
21 Failed - Incorrect protocol version number
22 Failed - Gateway not Synchronized (see Section
8.2)
Others Reserved
6.2. Unbind Connection (UNBIND)
UNBIND is used to terminate an iFCP session and disassociate the TCP
connection as described in Section 5.2.3.
The UNBIND message is transmitted over the connection that is to be
unbound. The time stamp words in the encapsulation header shall be
set to zero in the request and response message frames.
The following is the format of the UNBIND request message.
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
USER INFO Contains any data desired by the requestor.
This information MUST be echoed by the
recipient in the UNBIND response message.
CONNECTION HANDLE: Contains the gateway-assigned value from
the CBIND request.
The following shows the format of the UNBIND response message.
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+-----------+----------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
| 5 | Reserved | UNBIND STATUS |
+------+------------+------------+-----------+----------+
USER INFO Echoes the value received in the USER INFO
field of the UNBIND request message.
CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in
the UNBIND request message.
UNBIND STATUS: Indicates the success or failure of the
UNBIND request as follows:
Unbind Status Description
------------- -----------
0 Successful - No other status
1 - 15 Reserved
16 Failed - Unspecified Reason
18 Failed - Connection ID Invalid
Others Reserved
6.3. LTEST -- Test Connection Liveness
The LTEST message is sent at the interval specified in the CBIND
request or response payload. The LTEST encapsulation time stamp
SHALL be set as described in Section 8.2.1 and may be used by the
receiver to compute an estimate of propagation delay. However, the
propagation delay limit SHALL NOT be enforced.
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Reserved |
| | (Seconds) | |
+------+-------------------------+----------------------+
| 2 | COUNT |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
LIVENESS TEST Copy of the LIVENESS TEST INTERVAL
INTERVAL: specified in the CBIND request or reply
message.
COUNT: Monotonically increasing value, initialized
to 0 and incremented by one for each
successive LTEST message.
SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME
specified in the CBIND request.
DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT
NAME: NAME specified in the CBIND request.
7. Fibre Channel Link Services
Link services provide a set of fibre channel functions that allow a
port to send control information or request another port to perform a
specific control function.
There are three types of link services:
a) Basic
b) Extended
c) ULP-specific (FC-4)
Each link service message (request and reply) is carried by a fibre
channel sequence and can be segmented into multiple frames.
The iFCP layer is responsible for transporting link service messages
across the IP network. This includes mapping link service messages
appropriately from the domain of the fibre channel transport to that
of the IP network. This process may require special processing and
the inclusion of supplemental data by the iFCP layer.
Each link service MUST be processed according to one of the following
rules:
a) Pass-through - The link service message and reply MUST be
delivered to the receiving N_PORT by the iFCP protocol layer
without altering the message payload. The link service message
and reply are not processed by the iFCP protocol layer.
b) Special - Applies to a link service reply or request requiring
the intervention of the iFCP layer before forwarding to the
destination N_PORT. Such messages may contain fibre channel
addresses in the payload or may require other special processing.
c) Rejected - When issued by a locally attached N_PORT, the specified
link service request MUST be rejected by the iFCP gateway. The
gateway SHALL return an LS_RJT response with a Reason Code of 0x0B
(Command Not Supported), and a Reason Code Explanation of 0x0 (No
Additional Explanation).
This section describes the processing for special link services, including the manner in which supplemental data is added to the message payload. Appendix A enumerates all link services and the iFCP processing policy that applies to each.7.1. Special Link Service Messages
Special link service messages require the intervention of the iFCP layer before forwarding to the destination N_PORT. Such intervention is required in order to: a) service any link service message that requires special handling, such as a PLOGI, and b) service any link service message that has an N_PORT address in the payload in address translation mode only . Unless the link service description specifies otherwise, support for each special link service is MANDATORY. Such messages SHALL be transmitted in a fibre channel frame with the format shown in Figure 18 for extended link services or Figure 19 for FC-4 link services.
Word 0<---Bit-->7 8<-------------------------------------------->31 +------------+------------------------------------------------+ 0| R_CTL | D_ID | |[Req = 0x22]|[Destination of extended link Service request] | |[Rep = 0x23]| | +------------+------------------------------------------------+ 1| CS_CTL | S_ID | | | [Source of extended link service request] | +------------+------------------------------------------------+ 2| TYPE | F_CTL | | [0x01] | | +------------+------------------+-----------------------------+ 3| SEQ_ID | DF_CTL | SEQ_CNT | +------------+------------------+-----------------------------+ 4| OX_ID | RX_ID | +-------------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_COMMAND | | [Extended Link Service Command Code] | +-------------==----------------------------------------------+ 7| | .| Additional Service Request Parameters | .| ( if any ) | n| | +-------------------------------------------------------------+ Figure 18. Format of an Extended Link Service Frame
Word 0<---Bit-->7 8<-------------------------------------------->31 +------------+------------------------------------------------+ 0| R_CTL | D_ID | |[Req = 0x32]| [Destination of FC-4 link Service request] | |[Rep = 0x33]| | +------------+------------------------------------------------+ 1| CS_CTL | S_ID | | | [Source of FC-4 link service request] | +------------+------------------------------------------------+ 2| TYPE | F_CTL | | (FC-4 | | | specific) | | +------------+------------------+-----------------------------+ 3| SEQ_ID | DF_CTL | SEQ_CNT | +------------+------------------+-----------------------------+ 4| OX_ID | RX_ID | +-------------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_COMMAND | | [FC-4 Link Service Command Code] | +-------------------------------------------------------------+ 7| | .| Additional Service Request Parameters | .| ( if any ) | n| | +-------------------------------------------------------------+ Figure 19. Format of an FC-4 Link Service Frame7.2. Link Services Requiring Payload Address Translation
This section describes the handling for link service frames containing N_PORT addresses in the frame payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated, and such link service messages SHALL NOT be sent as special frames unless other processing by the iFCP layer is required. Supplemental data includes information required by the receiving gateway to convert an N_PORT address in the payload to an N_PORT address in the receiving gateway's address space. The following rules define the manner in which such supplemental data shall be packaged and referenced.
For an N_PORT address field, the gateway originating the frame MUST
set the value in the payload to identify the address translation type
as follows:
0x00 00 01 - The gateway receiving the frame from the IP network
MUST replace the contents of the field with the N_PORT alias of
the frame originator. This translation type MUST be used when the
address to be converted is that of the source N_PORT.
0x00 00 02 - The gateway receiving the frame from the IP network
MUST replace the contents of the field with the N_PORT ID of the
destination N_PORT. This translation type MUST be used when the
address to be converted is that of the destination N_PORT
0x00 00 03 - The gateway receiving the frame from the IP network
MUST reference the specified supplemental data to set the field
contents. The supplemental information is the 64-bit worldwide
identifier of the N_PORT, as set forth in the fibre channel
specification [FC-FS]. If not otherwise part of the link service
payload, this information MUST be appended in accordance with the
applicable link service description. Unless specified otherwise,
this translation type SHALL NOT be used if the address to be
converted corresponds to that of the frame originator or
recipient.
Since fibre channel addressing rules prohibit the assignment of
fabric addresses with a domain ID of 0, the above codes will never
correspond to valid N_PORT fabric IDs.
If the sending gateway cannot obtain the worldwide identifier of an
N_PORT, the gateway SHALL terminate the request with an LS_RJT
message as described in [FC-FS]. The Reason Code SHALL be set to
0x07 (protocol error), and the Reason Explanation SHALL be set to
0x1F (Invalid N_PORT identifier).
Supplemental data is sent with the link service request or ACC frames
in one of the following ways:
a) By appending the necessary data to the end of the link service
frame.
b) By extending the sequence with additional frames.
In the first case, a new frame SHALL be created whose length includes
the supplemental data. The procedure for extending the link service
sequence with additional frames is dependent on the link service
type.
For each field requiring address translation, the receiving gateway
SHALL reference the translation type encoded in the field and replace
it with the N_PORT address as shown in Table 7.
+------------------+------------------------------------+
| Translation | N_PORT Translation |
| Type Code | |
+------------------+------------------------------------+
| 0x00 00 01 | Replace field contents with N_PORT |
| | alias of frame originator. |
+------------------+------------------------------------+
| 0x00 00 02 | Replace field contents with N_PORT |
| | ID of frame recipient. |
+------------------+------------------------------------+
| | Lookup N_PORT via iSNS query. |
| | If locally attached, replace with |
| 0x00 00 03 | N_PORT ID. |
| | If remotely attached, replace with |
| | N_PORT alias from remote N_PORT. |
| | descriptor (see Section 5.2.2.1). |
+------------------+------------------------------------+
Table 7. Link Service Address Translation
For translation type 3, the receiving gateway SHALL obtain the
information needed to fill in the field in the link service frame
payload by converting the specified N_PORT worldwide identifier to a
gateway IP address and N_PORT ID. This information MUST be obtained
through an iSNS name server query. If the query is unsuccessful, the
gateway SHALL terminate the request with an LS_RJT response message
as described in [FC-FS]. The Reason Code SHALL be set to 0x07
(protocol error), and the Reason Explanation SHALL be set to 0x1F
(Invalid N_PORT identifier).
After applying the supplemental data, the receiving gateway SHALL
forward the resulting link service frames to the destination N_PORT
with the supplemental information removed.
7.3. Fibre Channel Link Services Processed by iFCP
The following Extended and FC-4 Link Service Messages must receive special processing. Extended Link Service LS_COMMAND Mnemonic Messages ---------- -------- ---------------------- Abort Exchange 0x06 00 00 00 ABTX Discover Address 0x52 00 00 00 ADISC Discover Address Accept 0x02 00 00 00 ADISC ACC FC Address Resolution 0x55 00 00 00 FARP-REPLY Protocol Reply FC Address Resolution 0x54 00 00 00 FARP-REQ Protocol Request Logout 0x05 00 00 00 LOGO Port Login 0x30 00 00 00 PLOGI Read Exchange Concise 0x13 00 00 00 REC Read Exchange Concise 0x02 00 00 00 REC ACC Accept Read Exchange Status Block 0x08 00 00 00 RES Read Exchange Status Block 0x02 00 00 00 RES ACC Accept Read Link Error Status 0x0F 00 00 00 RLS Block Read Sequence Status Block 0x09 00 00 00 RSS Reinstate Recovery 0x12 00 00 00 RRQ Qualifier Request Sequence 0x0A 00 00 00 RSI Initiative Scan Remote Loop 0x7B 00 00 00 SRL Third Party Process Logout 0x24 00 00 00 TPRLO Third Party Process Logout 0x02 00 00 00 TPRLO ACC Accept FC-4 Link Service Messages LS_COMMAND Mnemonic -------------------------- ---------- -------- FCP Read Exchange Concise 0x13 00 00 00 FCP REC FCP Read Exchange Concise 0x02 00 00 00 FCP REC Accept ACC Each encapsulated fibre channel frame that is part of a special link service MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header, as specified in Section 5.3.1. If an ACC link service response requires special processing, the responding gateway SHALL place a copy of LS_COMMAND bits 0 through 7, from the
link service request frame, in the LS_COMMAND_ACC field of the ACC encapsulation header. Supplemental data (if any) MUST be appended as described in the following section. The format of each special link service message, including supplemental data, where applicable, is shown in the following sections. Each description shows the basic format, as specified in the applicable FC standard, followed by supplemental data as shown in the example below. +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | LS_COMMAND | +------+------------+------------+-----------+----------+ | 1 | | | . | | | . | Link Service Frame Payload | | | | | n | | +======+============+============+===========+==========+ | n+1 | | | . | Supplemental Data | | . | (if any) | | n+k | | +======+================================================+ Figure 20. Special Link Service Frame Payload
7.3.1. Special Extended Link Services
The following sections define extended link services for which special processing is required.7.3.1.1. Abort Exchange (ABTX)
ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | RRQ Status | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| +------+------------+------------+-----------+----------+ | 3-10 | Optional association header (32 bytes | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------ ----------- Exchange Originator 1, 2 N/A S_ID Other Special Processing: None.
7.3.1.2. Discover Address (ADISC)
Format of ADISC ELS: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Hard address of ELS Originator | +------+------------+------------+-----------+----------+ | 2-3 | Port Name of Originator | +------+------------+------------+-----------+----------+ | 4-5 | Node Name of originator | +------+------------+------------+-----------+----------+ | 6 | Rsvd | N_PORT ID of ELS Originator | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------- ------------ N_PORT ID of ELS 1 N/A Originator Other Special Processing: The Hard Address of the ELS originator SHALL be set to 0.
7.3.1.3. Discover Address Accept (ADISC ACC)
Format of ADISC ACC ELS: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Hard address of ELS Originator | +------+------------+------------+-----------+----------+ | 2-3 | Port Name of Originator | +------+------------+------------+-----------+----------+ | 4-5 | Node Name of originator | +------+------------+------------+-----------+----------+ | 6 | Rsvd | N_PORT ID of ELS Originator | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------- ------------ N_PORT ID of ELS 1 N/A Originator Other Special Processing: The Hard Address of the ELS originator SHALL be set to 0.
7.3.1.4. FC Address Resolution Protocol Reply (FARP-REPLY)
The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see Section 7.3.1.5) to perform the address resolution services required by the FC-VI protocol [FC-VI] and the fibre channel mapping of IP and ARP specified in RFC 2625 [RFC2625]. Format of FARP-REPLY ELS: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Match Addr | Requesting N_PORT Identifier | | | Code Points| | +------+------------+------------+-----------+----------+ | 2 | Responder | Responding N_PORT Identifier | | | Action | | +------+------------+------------+-----------+----------+ | 3-4 | Requesting N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 5-6 | Requesting N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 7-8 | Responding N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 9-10 | Responding N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 11-14| Requesting N_PORT IP Address | +------+------------+------------+-----------+----------+ | 15-18| Responding N_PORT IP Address | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ----------------- ------------ Requesting N_PORT 2 N/A Identifier Responding N_PORT 1 N/A Identifier Other Special Processing: None.
7.3.1.5. FC Address Resolution Protocol Request (FARP-REQ)
The FARP-REQ ELS is used in conjunction with the FC-VI protocol [FC-VI] and IP-to-FC mapping of RFC 2625 [RFC2625] to perform IP and FC address resolution in an FC fabric. The FARP-REQ ELS is usually directed to the fabric broadcast server at well-known address 0xFF-FF-FF for retransmission to all attached N_PORTs. Section 9.4 describes the iFCP implementation of FC broadcast server functionality in an iFCP fabric. Format of FARP_REQ ELS: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Match Addr | Requesting N_PORT Identifier | | | Code Points| | +------+------------+------------+-----------+----------+ | 2 | Responder | Responding N_PORT Identifier | | | Action | | +------+------------+------------+-----------+----------+ | 3-4 | Requesting N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 5-6 | Requesting N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 7-8 | Responding N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 9-10 | Responding N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 11-14| Requesting N_PORT IP Address | +------+------------+------------+-----------+----------+ | 15-18| Responding N_PORT IP Address | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ----------------- ----------- Requesting N_PORT 3 Requesting N_PORT Identifier Port Name Responding N_PORT 3 Responding N_PORT Identifier Port Name
Other Special Processing:
None.
7.3.1.6. Logout (LOGO) and LOGO ACC
ELS Format:
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT ID being logged out |
+------+------------+------------+-----------+----------+
| 2-3 | Port name of the LOGO originator (8 bytes) |
+======+============+============+===========+==========+
This ELS SHALL always be sent as a special ELS regardless of the
translation mode in effect.
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ---------------
-----------
N_PORT ID Being 1 N/A
Logged Out
Other Special Processing:
See Section 5.2.3.
7.3.1.7. Port Login (PLOGI) and PLOGI ACC
A PLOGI ELS establishes fibre channel communications between two
N_PORTs and triggers the creation of an iFCP session if one does not
exist.
The PLOGI request and ACC response carry information identifying the
originating N_PORT, including a specification of its capabilities.
If the destination N_PORT accepts the login request, it sends an
Accept response (an ACC frame with PLOGI payload) specifying its
capabilities. This exchange establishes the operating environment
for the two N_PORTs.
The following figure is duplicated from [FC-FS], and shows the PLOGI message format for both the request and Accept (ACC) response. An N_PORT will reject a PLOGI request by transmitting an LS_RJT message containing no payload. +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 | | | Acc = 0x2 | | | | +------+------------+------------+-----------+----------+ | 1-4 | Common Service Parameters | +------+------------+------------+-----------+----------+ | 5-6 | N_PORT Name | +------+------------+------------+-----------+----------+ | 7-8 | Node Name | +------+------------+------------+-----------+----------+ | 9-12 | Class 1 Service Parameters | +------+------------+------------+-----------+----------+ |13-17 | Class 2 Service Parameters | +------+------------+------------+-----------+----------+ |18-21 | Class 3 Service Parameters | +------+------------+------------+-----------+----------+ |22-25 | Class 4 Service Parameters | +------+------------+------------+-----------+----------+ |26-29 | Vendor Version Level | +======+============+============+===========+==========+ Figure 21. Format of PLOGI Request and ACC Payloads Details of the above fields, including common and class-based service parameters, can be found in [FC-FS]. Special Processing As specified in Section 5.2.2.2, a PLOGI request addressed to a remotely attached N_PORT MUST cause the creation of an iFCP session if one does not exist. Otherwise, the PLOGI and PLOGI ACC payloads MUST be passed through without modification to the destination N_PORT using the existing iFCP session. In either case, the SPC bit must be set in the frame encapsulation header as specified in 5.3.3. If the CBIND to create the iFCP session fails, the issuing gateway SHALL terminate the PLOGI with an LS_RJT response. The Reason Code and Reason Code Explanation SHALL be selected from Table 8 based on the CBIND failure status.
+---------------+-------------------+---------------------+
| CBIND Failure | LS_RJT Reason | LS_RJT Reason Code |
| Status | Code | Explanation |
+===============+===================+=====================+
| Unspecified | Unable to Perform | No Additional |
| Reason (16) | Command Request | Explanation (0x00) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| No Such | Unable to Perform | Invalid N_PORT |
| Device (17) | Command Request | Name (0x0D) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| Lack of | Unable to Perform | Insufficient |
| Resources (19)| Command Request | Resources to Support|
| | (0x09) | Login (0x29) |
+---------------+-------------------+---------------------+
| Incompatible | Unable to Perform | No Additional |
| Address | Command Request | Explanation (0x00) |
| Translation | (0x09) | |
| Mode (20) | | |
+---------------+-------------------+---------------------+
| Incorrect iFCP| Unable to Perform | No Additional |
| Protocol | Command Request | Explanation (0x00) |
| version Number| (0x09) | |
| (21) | | |
+---------------+-------------------+---------------------+
| Gateway Not | Unable to Perform | No Additional |
| Synchronized | Command Request | Explanation (0x00) |
| (22) | (0x09) | |
+---------------+-------------------+---------------------+
Table 8. PLOGI LS_RJT Status for CBIND Failures
7.3.1.8. Read Exchange Concise (REC)
Link Service Request Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +======+============+============+===========+==========+ | 3-4 |Port Name of the Exchange Originator (8 bytes) | | | (present only for translation type 3) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ----------------- ----------- Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator Other Special Processing: None.
7.3.1.9. Read Exchange Concise Accept (REC ACC)
Format of REC ACC Response: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 2 | Rsvd | Originator Address Identifier | +------+------------+------------+-----------+----------+ | 3 | Rsvd | Responder Address Identifier | +------+------------+------------+-----------+----------+ | 4 | FC4VALUE (FC-4-Dependent Value) | +------+------------+------------+-----------+----------+ | 5 | E_STAT (Exchange Status) | +======+============+============+===========+==========+ | 6-7 |Port Name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ | 8-9 |Port Name of the Exchange Responder (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Originator Address 1, 2, or 3 Port Name of the Identifier Exchange Originator Responder Address 1, 2, or 3 Port Name of the Identifier Exchange Responder When supplemental data is required, the frame SHALL always be extended by 4 words as shown above. If the translation type for the Originator Address Identifier or the Responder Address Identifier is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros. Other Special Processing: None.
7.3.1.10. Read Exchange Status Block (RES)
ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 3-10 | Association Header (may be optionally req**d) | +======+============+============+===========+==========+ | 11-12| Port Name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator Other Special Processing: None.
7.3.1.11. Read Exchange Status Block Accept (RES ACC)
Format of ELS Accept Response: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 2 | Rsvd | Exchange Originator N_PORT ID | +------+------------+------------+-----------+----------+ | 3 | Rsvd | Exchange Responder N_PORT ID | +------+------------+------------+-----------+----------+ | 4 | Exchange Status Bits | +------+------------+------------+-----------+----------+ | 5 | Reserved | +------+------------+------------+-----------+----------+ | 6-n | Service Parameters and Sequence Statuses | | | as described in [FC-FS] | +======+============+============+===========+==========+ |n+1- | Port Name of the Exchange Originator (8 bytes) | |n+2 | | +======+============+============+===========+==========+ |n+3- | Port Name of the Exchange Responder (8 bytes) | |n+4 | | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Exchange Originator 1, 2, or 3 Port Name of the N_PORT ID Exchange Originator Exchange Responder 1, 2, or 3 Port Name of the N_PORT ID Exchange Responder When supplemental data is required, the ELS SHALL be extended by 4 words as shown above. If the translation type for the Exchange Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros. Other Special Processing: None.
7.3.1.12. Read Link Error Status (RLS)
ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | N_PORT Identifier | +======+============+============+===========+==========+ | 2-3 | Port Name of the N_PORT (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ----------------- ----------- N_PORT Identifier 1, 2, or 3 Port Name of the N_PORT Other Special Processing: None.
7.3.1.13. Read Sequence Status Block (RSS)
ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | SEQ_ID | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +======+============+============+===========+==========+ | 3-4 |Port Name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator Other Special Processing: None.
7.3.1.14. Reinstate Recovery Qualifier (RRQ)
ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 3-10 | Association Header (may be optionally req**d) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Exchange Originator 1 or 2 N/A S_ID Other Special Processing: None.
7.3.1.15. Request Sequence Initiative (RSI)
ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 3-10 | Association Header (may be optionally req**d) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Exchange Originator 1 or 2 N/A S_ID Other Special Processing: None.
7.3.1.16. Scan Remote Loop (SRL)
SRL allows a remote loop to be scanned to detect changes in the device configuration. Any changes will trigger a fibre channel state change notification and subsequent update of the iSNS database. ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x7B | Reserved | +------+------------+------------+-----------+----------+ | 1 | Flag | Address Identifier of the FL_PORT | | | | (see B.1) | +======+============+============+===========+==========+ | 2-3 | Worldwide Name of the Remote FL_PORT | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- Section 7.2) ------------------ ----------- Address Identifier 3 Worldwide Name of of the FL_PORT the Remote FL_PORT Other Special Processing: The D_ID field is the address of the Domain Controller associated with the remote loop. The format of the Domain Controller address is the hex 'FF FC' || Domain_ID, where Domain_ID is the gateway- assigned alias representing the remote gateway or switch element being queried. After translation by the remote gateway, the D_ID identifies the gateway or switch element to be scanned within the remote gateway region. The FLAG field defines the scope of the SRL. If set to 0, all loop port interfaces on the given switch element or gateway are scanned. If set to one, the loop port interface on the gateway or switch element to be scanned MUST be specified in bits 8 through 31. If the Flag field is zero, the SRL request SHALL NOT be sent as a special ELS.
If the Domain_ID represents a remote switch or gateway and an iFCP
session to the remote Domain Controller does not exist, the
requesting gateway SHALL create the iFCP session.
7.3.1.17. Third Party Process Logout (TPRLO)
TPRLO provides a mechanism for an N_PORT (third party) to remove one
or more process login sessions that exist between the destination
N_PORT and other N_PORTs specified in the command. This command
includes one or more TPRLO LOGOUT PARAMETER PAGEs, each of which,
when combined with the destination N_PORT, identifies a process login
to be terminated by the command.
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
Figure 22. Format of TPRLO ELS
Each TPRLO parameter page contains parameters identifying one or more
image pairs and may be associated with a single FC-4 protocol type
that is common to all FC-4 protocol types between the specified image
pair or global to all specified image pairs. The format of a TPRLO
page requiring address translation is shown in Figure 23. Additional
information on TPRLO can be found in [FC-FS].
+------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16-31 | +------+------------+------------+-----------+----------+ | 0 | TYPE Code | TYPE CODE | | | | or | EXTENSION | TPRLO Flags | | | Common SVC | | | | | Parameters | | | +------+------------+------------+-----------+----------+ | 1 | Third Party Process Associator | +------+------------+------------+-----------+----------+ | 2 | Responder Process Associator | +------+------------+------------+-----------+----------+ | 3 | Reserved | Third Party Originator N_PORT ID | +======+============+============+===========+==========+ | 4-5 | Worldwide Name of Third Party Originator | | | N_PORT | +------+------------------------------------------------+ Figure 23. Format of an Augmented TPRLO Parameter Page The TPRLO flags that affect supplemented ELS processing are as follows: Bit 18: Third party Originator N_PORT Validity. When set to one, this bit indicates that word 3, bits 8-31 (Third Party Originator N_PORT ID), are meaningful. Bit 19: Global Process logout. When set to one, this bit indicates that all image pairs for all N_PORTs of the specified FC-4 protocol shall be invalidated. When the value of this bit is one, only one logout parameter page is permitted in the TPRLO payload. If bit 18 has a value of zero and bit 19 has a value of one in the TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS. Otherwise, the originating gateway SHALL process the ELS as follows: a) The first word of the TPRLO payload SHALL NOT be modified. b) Each TPRLO parameter page shall be extended by two words as shown in Figure 23.
c) If word 0, bit 18 (Third Party Originator N_PORT ID validity), in
the TPRLO flags field has a value of one, then the sender shall
place the worldwide port name of the fibre channel device's N_PORT
in the extension words. The N_PORT ID SHALL be set to 3.
Otherwise, the contents of the extension words and the Third Party
Originator N_PORT ID SHALL be set to zero.
d) The ELS originator SHALL set the SPC bit in the encapsulation
header of each augmented frame comprising the ELS (see Section
5.3.1).
e) If the ELS contains a single TPRLO parameter page, the originator
SHALL increase the frame length as necessary to include the
extended parameter page.
f) If the ELS to be augmented contains multiple TPRLO parameter
pages, the FC frames created to contain the augmented ELS payload
SHALL NOT exceed the maximum frame size that can be accepted by
the destination N_PORT.
Each fibre channel frame SHALL contain an integer number of
extended TPRLO parameter pages. The maximum number of extended
TPRLO parameter pages in a frame SHALL be limited to the number
that can be held without exceeding the above upper limit. New
frames resulting from the extension of the TPRLO pages to include
the supplemental data SHALL be created by extending the SEQ_CNT in
the fibre channel frame header. The SEQ_ID SHALL NOT be modified.
The gateway receiving the augmented TPRLO ELS SHALL generate ELS
frames to be sent to the destination N_PORT by copying word 0 of the
ELS payload and processing each augmented parameter page as follows:
a) If word 0, bit 18, has a value of one, create a parameter page by
copying words 0 through 2 of the augmented parameter page. The
Third Party Originator N_PORT ID in word 3 shall be generated by
referencing the supplemental data as described in Section 7.2.
b) If word 0, bit 18, has a value of zero, create a parameter page by
copying words 0 through 3 of the augmented parameter page.
The size of each frame to be sent to the destination N_PORT MUST NOT
exceed the maximum frame size that the destination N_PORT can accept.
The sequence identifier in each frame header SHALL be copied from the
augmented ELS, and the sequence count SHALL be monotonically
increasing.
7.3.1.18. Third Party Logout Accept (TPRLO ACC)
The format of the TPRLO ACC frame is shown in Figure 24. +--------+------------+--------------------+----------------------+ | Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 | +--------+------------+--------------------+----------------------+ | 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length | +--------+------------+--------------------+----------------------+ | 1 | TPRLO Logout Parameter Page 0 | +--------+--------------------------------------------------------+ | 5 | TPRLO Logout Parameter Page 1 | +--------+--------------------------------------------------------+ .... +--------+--------------------------------------------------------+ |(4*n)+1 | TPRLO Logout Parameter Page n | +--------+--------------------------------------------------------+ Figure 24. Format of TPRLO ACC ELS The format of the parameter page and rules for parameter page augmentation are as specified in Section 7.3.1.17.7.3.2. Special FC-4 Link Services
The following sections define FC-4 link services for which special processing is required.7.3.2.1. FC-4 Link Services Defined by FCP
The format of FC-4 link service frames defined by FCP can be found in [FCP-2].7.3.2.1.1. FCP Read Exchange Concise (FCP REC)
The payload format for this link service is identical to the REC extended link service specified in Section 7.3.1.8 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against early revisions of FCP-2, an iFCP gateway MUST support both versions.
7.3.2.1.2. FCP Read Exchange Concise Accept (FCP REC ACC)
The payload format for this link service is identical to the REC ACC extended link service specified in Section 7.3.1.9 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against earlier revisions of FCP-2, an iFCP gateway MUST support both versions.7.4. FLOGI Service Parameters Supported by an iFCP Gateway
The FLOGI ELS is issued by an N_PORT that wishes to access the fabric transport services. The format of the FLOGI request and FLOGI ACC payloads are identical to the PLOGI request and ACC payloads described in Section 7.3.1.7. +------+------------+------------+-----------+----------+ | Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31| +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 | | | Acc = 0x2 | | | | +------+------------+------------+-----------+----------+ | 1-4 | Common Service Parameters | +------+------------+------------+-----------+----------+ | 5-6 | N_PORT Name | +------+------------+------------+-----------+----------+ | 7-8 | Node Name | +------+------------+------------+-----------+----------+ | 9-12 | Class 1 Service Parameters | +------+------------+------------+-----------+----------+ |13-17 | Class 2 Service Parameters | +------+------------+------------+-----------+----------+ |18-21 | Class 3 Service Parameters | +------+------------+------------+-----------+----------+ |22-25 | Class 4 Service Parameters | +------+------------+------------+-----------+----------+ |26-29 | Vendor Version Level | +======+============+============+===========+==========+ Figure 25. FLOGI Request and ACC Payload Format A full description of each parameter is given in [FC-FS]. This section tabulates the protocol-dependent service parameters supported by a fabric port attached to an iFCP gateway.
The service parameters carried in the payload of an FLOGI extended
link service request MUST be set in accordance with Table 9.
+-----------------------------------------+---------------+
| | Fabric Login |
| Service Parameter | Class |
| +---+---+---+---+
| | 1 | 2 | 3 | 4 |
+-----------------------------------------+---+---+---+---+
| Class Validity | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Service Options | |
+-----------------------------------------+---+---+---+---+
| Intermix Mode | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Stacked Connect-Requests | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Sequential Delivery | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Dedicated Simplex | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Camp On | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Buffered Class 1 | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Priority | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Initiator/Recipient Control | |
+-----------------------------------------+---+---+---+---+
| Clock Synchronization ELS Capable | n | n | n | n |
+-----------------------------------------+---+---+---+---+
Table 9. FLOGI Service Parameter Settings
Notes:
1) "n" indicates a parameter or capability that is not supported
by the iFCP protocol.
2) "M" indicates an applicable parameter that MUST be supported by
an iFCP gateway.