This chapter is from the book
This chapter is from the book
This chapter is from the book
FCIP
This section provides a brief introduction to Fibre Channel Over TCP/IP (FCIP).
FCIP Functional Overview
As indicated in Chapter 2, "The OSI Reference Model Versus Other Network Models," FCIP maps to the OSI session layer. The IETF began working on FCIP in 2000 and published the first standard in 2004 (RFC 3821). FCIP provides FC backbone functionality as defined in the ANSI T11 FC-BB series of specifications. Like iSCSI, FCIP seamlessly fits into the traditional IP network service model. This simplifies FCIP implementation for product vendors by reducing development overhead. IPsec support is mandatory for every FCIP product, and the FCIP standard stipulates which specific IPsec features must be supported. That said, use of IPsec is optional, and most FCIP deployments currently do not use IPsec.
FCIP enables interconnection of two switched FC-SANs using TCP/IP. This enables "distance applications" such as data replication from a primary site to a disaster recovery site. A point-to-point tunnel is created through an IP network, and FC traffic is transparently encapsulated or de-encapsulated at the tunnel endpoints. For multi-site connectivity, a separate tunnel must be created between each pair of FC-SANs. For this reason, each FCIP entity is architecturally capable of supporting multiple tunnels simultaneously. Each FCIP entity acts like a host on the IP network and does not require support for IP routing protocols. FCIP tunnels are long-lived. Once a tunnel is established, the two FC-SANs merge to form a single logical FC-SAN. All FC switches on each side of the tunnel see the remote FC switches as if they were local. All FC devices at both ends of the tunnel share a single address space. The FCIP tunnel is completely transparent to all FC devices. So, all aspects of the FC network architecture operate as if the tunnel were not present, and FC timers must be enforced end-to-end across the tunnel. FCIP's transparency enables all FC-4 protocols to be transported between the connected FC-SANs. FC-ALs can be attached to the FC switches within each FC-SAN, but low-level FC-AL signals (called primitives) cannot traverse an FCIP tunnel. This is not a problem because FCIP entities are either integrated into an FC switch or embodied in an external bridge device that connects to an FC switch, so low-level FC-AL signals never reach the FCIP entities. Figure 4-3 illustrates an FCIP tunnel connecting two physical FC-SANs.
)
Figure 4-3 FCIP Tunnel Connecting Two Physical FC-SANs
The two switches at the FCIP tunnel endpoints establish a standard FC inter-switch link (ISL) through the tunnel. Essentially, the FCIP tunnel appears to the switches as a cable. Each FCIP tunnel is created using one or more TCP connections. Multiple tunnels can be established between a pair of FC-SANs to increase fault tolerance and performance. Each tunnel carries a single FC ISL. Load balancing across multiple tunnels is accomplished via FC mechanisms just as would be done across multiple FC ISLs in the absence of FCIP. As mentioned in Chapter 3, "An Overview of Network Operating Principles," encapsulation is accomplished per the Fibre Channel Frame Encapsulation (FC-FE) specification (RFC 3643). Eight bytes of the encapsulation header are used by each encapsulating protocol (such as FCIP) to implement protocol-specific functionality. The remainder of the encapsulation header is used for purposes common to all encapsulating protocols, such as identifying the encapsulating protocol and enforcing FC timers end-to-end.
Connectivity failures within the transit IP network can disrupt FC operations. Obviously, a circuit failure that results in FCIP tunnel failure will segment the FC-SAN and prevent communication between the FC-SAN segments. Unfortunately, the effect of the disruption is not limited to cross-tunnel traffic. Local connectivity is temporarily disrupted in each FC-SAN segment while the FC routing protocol reconverges and Registered State Change Notifications (RSCNs) are processed by end nodes. Additionally, one of the FC-SAN segments must select a new principle switch (see Chapter 5, "The OSI Physical and Data-Link Layers," for details). The local effect of routing protocol reconvergence and principal switch selection can be eliminated via proprietary isolation techniques, but there currently is no mechanism within the FCIP standard to isolate FC-SANs from IP connectivity failures. This is generally considered to be the only significant drawback of FCIP.
FCIP Procedural Overview
Following data-link layer initialization, IP initialization occurs. The FCIP tunnel parameters can be configured manually or discovered via SLPv2. Once the tunnel parameters are known, an IPsec connection is optionally established followed by TCP connection establishment. The FCIP endpoint that initiated the TCP connection (the tunnel initiator) then transmits an FCIP Special Frame (FSF). The FSF contains the FC identifier and FCIP endpoint identifier of the tunnel initiator, the FC identifier of the intended destination, and a 64-bit randomly selected number that uniquely identifies the FSF. The receiver verifies that the contents of the FSF match its local configuration. If the FSF contents are acceptable, the unmodified FSF is echoed back to the tunnel initiator. After the tunnel initiator receives and verifies the FSF, the FCIP tunnel may carry FC traffic.
A time stamp is inserted into the header of each FCIP packet transmitted. The receiver checks the time stamp in each packet. If the time stamp indicates that the packet has been in flight longer than allowed by the FC timers, the packet is dropped. TCP is not responsible for retransmitting the dropped packet because the packet is dropped after TCP processing completes. FCP and FC error detection and recovery mechanisms are responsible for retransmitting the lost FC frame or notifying SCSI.