iFCP - A Protocol for Internet Fibre Channel Storage Networking
updated by
Extracted elements (29)
Address translation is applied only on the inbound (receiving) gateway, not the sender: outbound frames are encapsulated and sent without header modification (except for special link service payloads). This concentrates translation logic at the point where local address context is known and avoids requiring the sender to know the receiver's alias assignments.
Address translation mode (unbounded fabric) is the mandatory baseline because it scales beyond the 239-element FC Domain ID limit and provides fault isolation: address reassignment in one gateway region does not cascade to others. Address transparent mode (bounded fabric) is optional and trades scalability for the ability to carry vendor-specific or user-specific payloads that embed N_PORT IDs opaquely.
TCP Keep Alive and the Nagle algorithm should not be used in iFCP sessions. Keep Alive is superseded by the more comprehensive LTEST and FC-4-level keepalive mechanisms. The Nagle algorithm introduces transmission delays that degrade I/O throughput because small iFCP transfers frequently carry storage I/O requests.
A bounded iFCP fabric (address transparent mode) is limited to a combined total of 239 gateways and Fibre Channel switch elements due to the FC Domain ID allocation range of 1–239. This constraint does not apply to unbounded iFCP fabrics in address translation mode, where inter-region addressing is not subject to FC limits.
iFCP gateways in address transparent mode will not interoperate with gateways in address translation mode. The TRP bit in the encapsulation flags field enforces this: transparent-mode gateways reject frames without TRP=1 and abort the session, while translation-mode gateways reject frames with TRP=1.
A gateway in address transparent mode SHALL obtain domain IDs for use in the gateway region by issuing the appropriate iSNS query using its worldwide name, and MUST reside in one and only one bounded fabric.
A gateway operating in address translation mode MUST assign a locally significant N_PORT alias to each remotely attached device and MUST establish an iFCP session descriptor mapping the alias to the appropriate TCP/IP connection context and N_PORT ID.
A Remote N_PORT descriptor MUST NOT be deleted while any iFCP sessions reference that remote N_PORT, since deletion frees the N_PORT alias for reuse.
All iFCP gateways MUST support unbounded iFCP fabrics operating in address translation mode. Support for bounded iFCP fabrics (address transparent mode) is OPTIONAL.
All iFCP gateways SHALL support liveness testing via the LTEST message. An iFCP session SHALL be terminated if LTEST message contents are incorrect or an LTEST message is not received within twice the specified interval.
All iFCP implementations MUST support operations in address translation mode; implementation of address transparent mode is OPTIONAL. An implementation MUST NOT allow the addressing mode to be changed after the gateway begins processing FC frame traffic, permit operation in more than one mode simultaneously, or establish an iFCP session with a gateway not in the same mode.
For inbound frames received from the IP network, the receiving gateway SHALL replace the D_ID field with the destination N_PORT ID and the S_ID field with the assigned N_PORT alias from the session descriptor, and MUST then recalculate the FC CRC. The received S_ID and D_ID values are considered undefined.
iFCP gateways in address transparent mode SHALL NOT originate or accept frames without the TRP bit set to one in the iFCP flags field of the encapsulation header, and SHALL immediately terminate all iFCP sessions with any gateway from which such frames are received.
No more than one iFCP session SHALL exist between a given pair of N_PORTs. All iFCP traffic between a given remote and local N_PORT pair MUST flow through the same iFCP session.
TCP Wrapped Sequence Protection (PAWS, RFC 1323) SHOULD be supported to prevent out-of-order frame delivery or data corruption caused by wrapped sequence numbers on high-bandwidth links.
When multiple gateways serve the same gateway region, they MUST coordinate assignment of N_PORT IDs and aliases so each N_PORT has exactly one address, and all iFCP traffic between a given remote/local N_PORT pair MUST flow through the same iFCP session.
An iFCP fabric supports Fibre Channel Class 2 (frame-multiplexed with end-to-end flow control) and Class 3 (frame-multiplexed, no delivery confirmation) transport services. Class 1 (dedicated circuit), Class 4 (virtual circuit with QoS), and Class 6 (reliable multicast) are not supported.
An iFCP session consists of a pair of N_PORTs joined by a single TCP/IP connection. It is identified by the N_PORT network addresses of both endpoints (N_PORT ID plus iFCP Portal IP address and TCP port). TCP connections may be pre-established in an Unbound state and allocated to a session via a CBIND message.
iFCP defines three TCP session control messages: CBIND (Connection Bind — allocates a TCP connection to an iFCP session and negotiates the LIVENESS TEST INTERVAL), UNBIND (terminates a session), and LTEST (tests connection liveness; its encapsulation header may also be used to estimate propagation delay).
The CBIND request and response carry a LIVENESS TEST INTERVAL field. When set to a non-zero value, the receiving gateway SHALL transmit LTEST messages at the specified interval, beginning as soon as the session enters the OPEN state.
The iFCP session descriptor tracks: TCP connection context, local N_PORT ID, remote N_PORT ID, and remote N_PORT alias. It is created when a session enters the OPEN state and drives inbound frame address translation.
The Remote N_PORT Descriptor aggregates: N_PORT worldwide unique name (64-bit), iFCP Portal Address (IP+TCP port), N_PORT ID assigned by the remote gateway, and N_PORT alias assigned locally. A gateway SHALL have exactly one descriptor per remote N_PORT, populated from iSNS query results.
Section 12 (IANA Considerations) addresses registry assignments for the iFCP protocol, including the TCP port number used for iFCP session establishment. IANA registered TCP port 3420 for iFCP.
iFCP security threats include unauthorized device access, traffic interception, and replay attacks across the IP network. The recommended architecture uses IPsec with IKE for authentication, confidentiality, and key management between iFCP gateways. Certificate-based authentication using X.509 certificates is supported, with iSNS used to distribute security policies.
The minimal security policy for an iFCP gateway requires all iFCP sessions to remote gateways and all iSNS communications to be protected by IPsec. The iSNS server is the distribution point for gateway security policies (Section 10.5), making its availability and integrity critical to the security of the entire iFCP fabric.
An iFCP session has two states: OPEN PENDING (CBIND issued, no response yet received — no FC frames may be sent) and OPEN (CBIND Success received — FC frames may be sent and received). A duplicate CBIND collision is resolved by comparing Source N_PORT Names; the greater name wins.
iFCP sessions are terminated by: PLOGI LS_RJT, N_PORT state change notification (removal/reconfiguration), LOGO ACC from peer, fabric logout (LOGO to D_ID 0xFF-FF-FE), implicit LOGO, LTEST error, non-fatal encapsulation error, TCP connection failure, UNBIND receipt, gateway entering Unsynchronized state, or incorrect address mode detection (last case uses TCP RST without UNBIND).
iFCP frames are fibre channel frames encapsulated per the FC Frame Encapsulation specification. The encapsulation header includes an iFCP flags field containing the TRP bit (set to one for address transparent mode frames). The encapsulated FC frame consists of a 24-byte header, 0–2112 bytes of payload, and a 32-bit CRC, bracketed by SOF and EOF delimiter words.
The Fibre Channel N_PORT address is a 24-bit field divided into: Domain ID (bits 0–7, high-order, range 1–239/0xEF), Area ID (bits 8–15), and Port ID (bits 16–23, low-order). The source (S_ID) and destination (D_ID) addresses occupy words 1 and 2 of the FC frame header, respectively.