Ezine

This article can also be found in the Premium Editorial Download "Storage magazine: Exploring new options for disk-based backup."

Download it now to read this article plus other related content.

iFCP vs. FCIP

The FCIP protocol
At a very high level, FCIP is a tunneling protocol that creates a logical tunnel to transport the FC packet from one FC SAN to another over IP. An FCIP gateway switch is installed on each SAN. Each FCIP port contains one or more FCIP tunnels. Each tunnel is a virtual connection point,

    Requires Free Membership to View

and each tunnel is given an IP address. When the FCIP switch receives an FC packet, the packet is wrapped as data into an IP packet and sent along. It's analogous to putting an FC-addressed envelope into an IP-addressed envelope and giving it to the IP postman to deliver. There's some overhead because of the larger IP envelope that's needed, but it's a relatively simple process--although there might be special delivery charges for the use of the tunnel if it has to be specially provisioned.

FCIP is most often implemented to solve primary-to-secondary data center disk replication; unfortunately, it doesn't scale well beyond this application. This is because the tunneling design creates an interconnection between two FC SANs that makes them, logically, a single FC SAN, but leads to a proliferation of tunnels. If, for example, a user wishes to connect an Atlanta FC SAN with a Boston FC SAN, then only an Atlanta/Boston (AB) tunnel is needed. If the Chicago FC SAN has to be brought online to share data with Atlanta and Boston, an Atlanta/Chicago (AC) and a Boston/Chicago (BC) tunnel will be needed, making three data centers and three tunnels. If you add Denver to the mix, three more tunnels will be required for a total of four data centers and six tunnels, but it would still be one logical SAN. The geometric growth of these tunnels occurs because the network is essentially flat; reducing the number of tunnels would result in more hops across the latency of IP WANs.

Even when this tunneling growth can be managed easily, there's another limitation that hampers SAN growth through FCIP. Because all connected FC SANs become a single logical FC SAN, all of the FC protocol limitations apply, including the limitation of 239 switches in a fabric and a single fabric name server to manage it all. Any topology changes at any of the connected sites are transmitted to the other SANs. This is why fundamental changes in the FC protocol itself will be required to make FCIP scalable. Another approach to this limitation is to add proprietary methods of segmentation at the tunnel points. This approach, however, won't allow a mix of vendor connections on any single tunnel.

The resiliency of FCIP is limited to the resiliency of the IP tunnel. Storage administrators have to be aware of this limitation because the FCIP protocol can't easily recover from LAN/WAN connection losses without administrator intervention. When a problem occurs in the LAN/WAN, the tunnel may be lost. If no other path exists, the fabric will be split into two fabrics that will each undergo a fabric reconfiguration with the usual outage potential. When the tunnel is recreated, a second outage, managed by a storage administrator, will occur as one of the fabrics is brought down and then back up to re-establish the single logical fabric configuration.

Vendor interoperability won't become a feature of the FCIP protocol until the Internet Engineering Task Force (IETF) and/or T11 (a group within the InterNational Committee for Information Technology Standards) ratifies FCIP as a standard that would allow compliant switches from different vendors to interconnect. Ratification is further complicated because to make FCIP work well, vendors will have to give the existing FC protocol some means of recognizing the latencies and scaling issues IP connections introduce. But until the standards committees provide FCIP standardization, there won't be an obvious market for independent software vendors that might create new solutions to improve the IP WAN link transfer. In the absence of proven standardization, storage managers should plan on using a single FCIP vendor's switch at each side of the tunnel. This will add complexity if one of the connected SANs is composed of another vendor's switches. In that case, proof-of-concept testing should focus on the inter-switch link between the two vendors' switches.

At the core of the development problems for the FCIP protocol is that its design emulates rather than implements TCP/IP routing methodologies. A similar design approach was used for FC. The FC protocol has many network components whose designs were based on an IP-like network, but the designs were modified to favor speed and accuracy. For instance, the limitation of 239 switches on a single fabric came about because it allowed all routing to be based on a single leading byte in the header. Because only one byte of the entire packet had to be read to make a path choice, it allowed for incredible speed. Zoning within FC is somewhat analogous to an IP virtual LAN. The design goal is to isolate one group's traffic from another's at a layer above the routing layer.

There's an inherent weakness in this FCIP approach to mimicking IP solutions. Vendors are currently implementing proprietary FCIP mimics of the IP features that the market needs. The accumulation of non-standard features will tighten the lock on a vendor's customers because of the cost of replacing the incumbent vendor's infrastructure.

This was first published in June 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: