Free Tutor’s on IP storage standards: iSCSI, iFCP, mFCP, FCIP and iSNS

Free Tutor's on IP storage standards: iSCSI, iFCP, mFCP, FCIP and iSNS

Three protocols are available for transmitting storage data traffic over TCP/IP: Internet SCSI (iSCSI), Internet FCP (iFCP) and Fibre Channel over IP (FCIP) – not to be confused with IPFC. They form the family of IP-based storage protocols that are also known as IP storage. These standards have in common that in one form or another they transmit SCSI over IP and thus in practice usually over Ethernet. Although we do not yet know which of these standards will dominate the IP storage market, if we look at the products announced by manufacturers we find that iSCSI and FCIP are currently receiving the most attention. 'Storage over IP (SoIP)' is sometimes called a standard in association with IP storage.This is incorrect: SoIP is a product from Nishan Technologies (acquired by McData Corporation in September 2003) that, according to the manufacturer, is compatible with various IP storage standards. The basic idea behind Internet SCSI (iSCSI) is to transmit the SCSI protocol over TCP/IP (Figure 3.35). iSCSI thus takes a similar approach to Fibre Channel SAN, the difference being that in iSCSI a TCP/IP/Ethernet connection replaces the SCSI cable. Just like Fibre Channel SAN, iSCSI has to be installed in the operating system as a device driver. Like FCP, this realizes the SCSI protocol and maps the SCSI daisy chain onto aTCP/IP network. Although the Internet Engineering Task Force (IETF) did not ratify the iSCSI standard until the beginning of 2003, there are already (end of 2003) end devices that directly support iSCSI and more and more reputable manufacturers are announcing the appearance of iSCSI products. As one option, conventional Ethernet network cards can be used on the servers, for which an additional iSCSI driver is installed that realizes the protocols in the form of software, thereby placing a load on the server CPU. As an alternative, iSCSI HBAs are available, which – in a similar manner to the TCP/IP offload engines – realize the iSCSI/TCP/IP/Ethernet protocol stack in the form of hardware. Initial measurements on iSCSI HBAs (network cards that handle a large part of the iSCSI/TCP/IP/Ethernet protocol stack on the network card) show that the load on the server CPU can be significantly reduced by offloading the protocol processing into hardware. Therefore, iSCSI HBAs can be used for high performance requirements, whereas conventional, and thus significantly cheaper, Ethernet cards are sufficient for low and possibly even average performance requirements. It is feasible that later versions of the iSCSI standard will also be based upon UDP/IP, IP or in the forms of SDP and iSER on Remote Direct Memory Access (RDMA, Section 3.7).

In production environments, the use of iSCSI is still largely limited to the connection of iSCSI servers to Fibre Channel storage devices over an iSCSI-to-Fibre Channel gateway. Since many manufacturers are only just launching the first versions of their iSCSI devicesand drivers onto the market, incompatibilities are currently unavoidable. Therefore, iSCSI is currently only used in niche markets. A common example is the booting of diskless servers over iSCSI. They take their hard disks, including boot image and operating system, from a Fibre Channel disk subsystem via iSCSI-to-Fibre Channel gateway by means of iSCSI (Figure 3.36). Such a shifting of the storage capacity from internal hard drives to external disk subsystems brings with it the normal cost benefits associated with storage

networks. Manufacturer-specific techniques are currently still being used for this. The IETF is now working on the standardization of booting by means of iSCSI.

In contrast to iSCSI, which defines a new protocol mapping of SCSI on TCP/IP, Internet FCP (iFCP) describes the mapping of Fibre Channel FCP on TCP/IP. The idea is to protect the investment in a large number of Fibre Channel devices that have already been installed and merely replace the Fibre Channel network infrastructure by an IP/Ethernet network infrastructure. The developers of iFCP expect that this will provide cost benefits in relation to a pure Fibre Channel network. For the realization of iFCP, LAN switches must either provide a Fibre Channel F-Port or an FL-Port. Alternatively, Fibre Channel FCP-to-iFCP

gateways could also be used (Figure 3.37). The difference between Metro FCP (mFCP) and iFCP is that mFCP is not based upon TCP/IP but on UDP/IP. This means that mFCP gains performance at the expense of the reliability of the underlying network connection. The approach of replacing TCP/IP by UDP/IP has proved itself many times. For example, NFS was originally based upon TCP/IP, but today it can be based upon TCP/IP or UDP/IP. Error correction mechanismsin the application protocol (in this case NFS or mFCP) ensure that no data is lost. This is only worthwhile in low-error networks such as LANs. In order to provide fabric services, iFCP/mFCP must evaluate the Fibre Channel frames received from the end devices and further process these accordingly. It forwards useful

data for a different end device to the appropriate gateway or switch via TCP/IP. Likewise,

it also has to map infrastructure services of the fabric such as zoning and name serviceon TCP/IP. In our opinion, the benefits of iFCP and mFCP remain to be proved. Both protocols make a very elegant attempt to protect investments that have already been madeby connecting existing Fibre Channel storage devices into IP-based storage networks.Furthermore, the use of iFCP/mFCP makes it possible to reach back to the fully developed techniques, services and management tools of an IP network. However, iFCP and mFCP are complex protocols that have to be intensively tested before cross-manufacturer compatibility can be ensured. iFCP and mFCP offer few new benefits for the transmission of Fibre Channel FCP over IP: today, Fibre Channel-to-iSCSI gateways and the FCIP mentioned below provide alternative methods of connecting existing Fibre Channel devices over IP. Therefore, the benefits, and thus the future, of iFCP/mFCP remain dubious in view of the required implementation and testing cost for the manufacturer of iFCP/mFCP components.The third protocol for IP storage, Fibre Channel over IP (FCIP), was designed as a supplement to Fibre Channel, in order to remove the distance limitations of Fibre Channel. Companies are increasingly requiring longer distances to be spanned, for example for data mirroring or to back-up data to back-up media that is a long way from the production data in order to prevent data loss in the event of large-scale catastrophes. Until now, such requirements meant that either the tapes had to be sent to the back-up data centre by courier or comparatively expensive and difficult to manage WAN techniques such as Dark Fiber, DWDM or SONET/SDH had to be used. FCIP represents an alternative to the conventional WAN techniques: it is a tunnelling protocol that connects two Fibre Channel islands together over a TCP/IP route (Figure 3.38). FCIP thus creates a point-to-point connection between two Fibre Channel SANs and simply compresses all Fibre Channel frames into TCP/IP packets. The use of FCIP remains completely hidden from the Fibre Channel switches, so both of the Fibre Channel SANs connected using FCIP merge into a large storage network. Additional services and drivers are unnecessary.A further advantage of FCIP compared to the connection of Fibre Channel etworks

using conventional WAN techniques lies in the encryption of the data to be transmitted. Whereas encryption techniques are still in their infancy in Dark Fibre, DWDM and SONET/SDH, the encryption of the data traffic between two IP routers by means of IPSec has now become a standard technique.

Currently, many manufacturers have announced the expansion of their product port folio to include FCIP or have already brought this onto the market. The passing of the FCIP standard by the IETF is still awaited (end of 2003). Only then can work on the interoperability of the FCIP components of different manufacturers be driven forward. Until then, FCIP-to-Fibre Channel gateways from the same manufacturer will have to be used at both ends of a FCIP route.

A common feature of all the protocols introduced here is that they transmit SCSI data traffic over IP in one form or another. In addition to the data transmission, a service is required to help scan for devices or communication partners in the IP network and to query device properties. Internet Storage Name Service (iSNS) is a standard that defines precisely such a service. iSNS is a client-server application, in which the clients register their attributes with the server, which for its part informs clients about changes to the topology. Both iSCSI and iFCP integrate iSNS. FCIP does not need to do this because it only provides a transmission route between two Fibre Channel SANs and thus has the same function as a Fibre Channel cable. iSCSI, iFCP and FCIP are similar protocols that can easily be mistaken for one another. Therefore it makes sense to contrast these protocols once again from different points of view. Figure 3.39 compares the protocol stacks of the different approaches: FCP is realized completely by Fibre Channel protocols. FCIP creates a point-to-point connection between two Fibre Channel SANs, with all Fibre Channel frames simply being packetized in TCP/IP packets. iFCP represents an expansion of FCIP, since it not only tunnels Fibre

Channel frames, but also realizes fabric services such as routing, name server and zoning over TCP/IP. Finally, iSCSI is based upon TCP/IP without any reference to Fibre Channel. Table 3.4 summarizes which parts of the protocol stack in question are realized by Fibre Channel and which by TCP/IP/Ethernet. Finally, Figure 3.40 compares the frame formats.