iFCP
This section provides a brief introduction to Internet Fibre Channel Protocol (iFCP).
iFCP Functional Overview
As indicated in Chapter 2, "The OSI Reference Model Versus Other Network Models," iFCP maps to the OSI session layer. The IETF began working on iFCP in 2000 and published the first standard in 2005 (RFC 4172). iFCP originally sought to supplant FC switching and routing mechanisms with Ethernet switching and IP routing mechanisms by replacing the FC fabric with an IP network. However, end nodes would be FC-attached to iFCP gateway devices. Only the iFCP gateway devices would communicate with each other via TCP/IP. The login procedures of FC would still be used by end nodes, but the IP network would provide the FC network services (in particular, the FCNS and FC Zone Server [FCZS]). Rather than augment the existing IP network services (such as SLP), a new service (iSNS) was created to provide the functionality of the FCNS and FCZS. As iSCSI development progressed in parallel to iFCP, modifications were made to iSNS to meet the needs of iSCSI. However, iSCSI can be deployed without iSNS. By contrast, iFCP requires iSNS. Figure 4-4 illustrates the original design concept of iFCP that was submitted to the IETF.
)
Figure 4-4 Original iFCP Design Concept
The motivation behind this approach is to reduce the total solution cost by leveraging cost-effective IP-based technology and widely available IP skill sets, extend the reach of FC attached devices beyond the FC limits, and enable the integration of FC and IP management operations. Unfortunately, the cost savings are undermined by the requirement for end nodes to be attached via FC. If the end nodes were attached via IP/Ethernet, the cost would be lower, but the solution would closely resemble iSCSI. Because iSCSI was designed to provide an IP/Ethernet alternative to FC-SANs, iSCSI provides a much more elegant and cost-effective solution than iFCP. Another challenge for iFCP is that only one vendor produces iFCP gateways today, and its iFCP products do not currently provide sufficient FC port densities to accommodate the connectivity requirements of most modern FC-SANs. So, iFCP gateways are usually deployed in conjunction with FC switches. Combined, these factors relegate iFCP usage to FC-SAN interconnectivity. Thus, iFCP competes against FCIP despite the original iFCP design goals. Figure 4-5 illustrates the current deployment practice.
)
Figure 4-5 Current iFCP Deployment Practice
The remainder of this section focuses on FC-SAN interconnectivity. iFCP gateways can operate in address transparency mode so that all FC devices share a single address space across all connected FC-SANs. This mode allows IP network failures to disrupt the attached FC-SANs just as FCIP does. For this reason, iFCP is rarely deployed in address transparency mode, and iFCP gateway support for address transparency mode is optional. iFCP gateways can also operate in address-translation mode. Devices in each FC-SAN communicate with devices in other FC-SANs using FC addresses allocated from the local FC-SAN address space. In this mode, the effect of IP network failures is mitigated. Each FC-SAN operates autonomously, as does the IP network. Network services are provided to FC attached devices via the FC switches. The state of FC network services in each FC-SAN must be replicated to the iSNS for propagation to other FC-SANs. Support for address translation mode is mandatory. Translation mode is customary in almost every deployment, so the remainder of this section focuses on translation mode.
iFCP operation is transparent to end nodes, and encapsulation is accomplished per the FC-FE specification (RFC 3643). However, connectivity across the IP network is handled differently than FCIP. Instead of creating a single tunnel to carry all FC traffic, each iFCP gateway creates a unique iFCP session to the appropriate destination iFCP gateway for each initiator-target pair that needs to communicate. This model might work well in the originally intended iFCP deployment scenario, but it can impede performance in the current iFCP deployment scenario by limiting the size of the TCP window available to each iFCP session. Two factors complicate this potential problem. First, iFCP sessions are created dynamically in response to PLOGI requests and are gracefully terminated only in response to LOGO requests. Second, PLOGI sessions are typically long-lived.
Like FCIP, IPsec support is mandatory for every iFCP product, and the iFCP standard stipulates which specific IPsec features must be supported. That said, use of IPsec is optional, and most iFCP deployments currently do not use IPsec. iFCP supports attachment of FC-ALs to FC switches within each FC-SAN, but low-level FC-AL signals (primitives) cannot traverse an iFCP session. This is not a problem because each iFCP gateway is usually connected to an FC switch, so FC-AL primitives never enter the iFCP gateways. iFCP gateways act like hosts on the IP network and do not require support for IP routing protocols. Multiple iFCP gateways may be deployed in each FC-SAN to increase fault tolerance and performance. Load balancing iFCP sessions across multiple iFCP gateways is implementation-specific. iFCP supports all FC-4 protocols when operating in transparent mode. However, it is possible for address translation mode to prevent certain FC-4 protocols from operating properly. Currently, iFCP is deployed only in FCP environments.
iFCP Procedural Overview
Following data-link layer initialization, IP initialization occurs. Next, iFCP gateways discover each other via iSNS. Likewise, configuration parameters for the iFCP fabric are discovered via iSNS. Once the iFCP fabric parameters are known, an IPsec connection is optionally established between each pair of iFCP gateways. As FC devices register in the FCNS of each FC-SAN, the attached iFCP gateway propagates the registration information to the iSNS. The iSNS then propagates the information to each of the other iFCP gateways. Upon receipt, each iFCP gateway updates the FCNS of its attached FC-SAN with the remote node information and creates an entry in its address translation table for the remote node. At this point, the iFCP fabric is ready for initiator-target communication. TCP connections can be handled in two ways. An iFCP gateway can proactively establish and maintain multiple TCP connections to other gateways. These are called unbound TCP connections. When a PLOGI request is received, the iFCP gateway creates an iFCP session and binds it to one of the unbound TCP connections. Alternately, an iFCP gateway can wait until it receives a PLOGI request and then establish a TCP connection immediately followed by iFCP session establishment. While a TCP connection is bound to an iFCP session, it cannot be used by other iFCP sessions. iFCP enforces FC frame lifetimes in the same manner as FCIP. Likewise, detection and recovery of FC frames that are lost due to timeout are handled by FCP and FC. Due to limited vendor support and a low adoption rate, further examination of iFCP is currently outside the scope of this book.