This article can also be found in the Premium Editorial Download "Storage magazine: Low-cost storage pieces fall into place."
Download it now to read this article plus other related content.
FCIP: Tunneling through the cloud
FCIP is a tunneling protocol designed to provide an IP transport between SAN islands. When a local FC port needs to talk to a remote FC port, the FC frame is sent to an FCIP device, which in turn encapsulates the frame in a TCP/IP header and sends it across the transport to the IP port of the FCIP device at the other end (see "
Although the user datagram protocol (UDP) can be used to transport packets across an IP link, TCP is the most widely used transport because in-order delivery, data integrity and congestion control are desirable on the WAN. Because TCP is the desired transport, the line quality of the WAN link is of the utmost importance to keep retransmissions at a minimum level.
The size of the WAN pipe ranges from OC-3 (155Mb/s) to OC-192 (10Gb/s). As you collect data in the application assessment phase, consider the burst rates and times of your applications, as well as over-subscription calculations to arrive at your required bandwidth between sites. Also, you should provision additional capacity for time-sensitive applications to minimize or eliminate latency during such operations as synchronous disk activity.
Because the FC frame isn't traversing the network under its native header as it would with DWDM, the FC frame and the IP transport are each subject to the other's timeout values. Additionally, when there isn't any application data flowing over the wire, the IP ports on the FCIP devices will send keepalive packets to each other at a configurable rate. This improves the monitoring function of the link and helps to maintain the connections between the FCIP devices.
The E_Ports between FC linked by FCIP are unaware that there's an IP tunnel between them. They exchange F Class traffic as if they were directly connected to one another. And for all intents and purposes, they don't care as long as their frames are delivered and their acknowledgements are received before expiration timers are fired off.
If the IP tunnel is lost due to a hardware or carrier failure, the fabric will segment in the same way as if the E_Ports were directly connected. However, when the IP tunnel is recovered, at least one of the switches joining the fabric across the long-distance SAN link will need to be reinitialized. This can be fixed by your FCIP switch vendor.
Flow control is implemented and used by both FCP and TCP on both sides of the FCIP device. If you're using Class 3 as your FC transport mechanism, then flow control is implemented in receive ready (R_RDYs ) frames or buffers where buffer credits are allotted to the sending port as R_RDYs are returned from the recipient after having emptied its buffer of the previous frame. If however, the IP side of the FCIP device needs to send packets over the IP transport, its sending will be governed by the advertised sliding window of its IP partner on the remote FCIP device.
Management of the encapsulated FC frames that traverse IP transport will need to be performed with IP network management tools. These tools won't be able to peek inside to determine the characteristics of the FC frame; therefore, you will need a combination of the FC and IP network management tools to get a complete picture of your extended SAN. The same isn't true for extended SAN solutions completely engineered around IP (i.e., iFCP and iSCSI).
This was first published in October 2003