Part I<br>iSNS: Technical overview of discovery in IP SANs

Posted on November 01, 2001

RssImageAltText

Internet Storage Name Service is a discovery and name services proposal under consideration by the Internet Engineering Task Force.

BY TOM CLARK

As the repositories of information that sustain institutions and enterprises, storage devices are at the center of modern network designs. High-speed access and high availability of stored data are now critical for both internal business operations and external e-commerce applications. Storage devices, however, are unique components in network design with their own specific requirements. Unlike hosts in a typical data-communications network, storage devices do not initiate transactions. In the vocabulary of storage administration, storage devices are targets, responding to read-and-write requests from initiators such as servers or workstations. In direct SCSI-attached storage configurations, a server can easily discover the storage resources at its disposal by polling the SCSI bus to which disk arrays are attached. Since the server is the exclusive owner of its attached storage, it can be assumed that any devices it discovers are available for its use.

In a storage area network (SAN), by contrast, disk and tape resources may be dispersed across a complex network. This presents challenges for device discovery as well as device ownership. Initiators must be able to identify storage resources in the SAN and determine whether they have access to them. SANs therefore require a mechanism to facilitate device discovery and to assign potentially shared storage resources to specific initiators. In this article, we will examine device discovery in storage networks and how the Internet Storage Name Service (iSNS) can be used to facilitate discovery in IP SANs.

Discovery in Fibre Channel SANs

Fibre Channel SANs support two basic topologies: arbitrated loop and fabric. An arbitrated loop is a shared medium, analogous to a Token Ring LAN. Devices attached to the loop must arbitrate for access to the shared bandwidth before launching transactions, and only 126 end nodes are supported. Fabrics provide full bandwidth to each device and can support up to 15.5 million end nodes. The topologies can be combined: A loop segment can be attached to a fabric switch to allow communication between loop nodes and fabric-attached nodes.


Figure 1: The iSCSI, iFCP, and FCIP protocols support a serial SCSI-3 interface to the standard SCSI command set expected by the operating system and upper-layer applications.
Click here to enlarge image

Discovery in an arbitrated loop relies heavily on the limited number of devices that can be connected to a single loop. Following loop initialization, an initiator such as a server simply can poll through the 126 possible addresses to solicit responses from potential targets. Walking the address space for 126 possible destinations may be inefficient but occurs fairly quickly at gigabit speeds. Targets that respond to an initiator's queries verify their presence on the loop, and an initiator can thereafter establish sessions with each device and begin storage transactions. In some proprietary implementations, a positional map generated during loop initialization is used for target discovery. Each active device records its loop address in the positional map, and the map, in turn, can be used to create an address list for session establishment. While this shortens the process of device polling, not all loop devices support the positional mapping feature.

With more than 15.5 million possible addresses, device polling is not a viable solution for Fibre Channel fabrics. Fibre Channel standards therefore provide a name service definition that enables device discovery without walking an enormous address space. Whereas in loop environments the initiator must perform all the work of device discovery, in fabrics this responsibility is shared between initiators and the Fibre Channel switches that compose the fabric topology. A device attached to a fabric switch must first log on to the fabric to obtain a unique network address. It then registers its presence on the fabric by logging on to the Simple Name Server (SNS) at a well-known address. The SNS maintained by the switch is a small database that contains the permanent device identifier, fabric address, class of service parameters, and other information. Of special importance for device discovery, the SNS provides an entry for the type of upper-layer protocol supported, which for storage applications is serial SCSI-3. Since every target device registers with the SNS, an initiator simply can send a query to the SNS asking for a list of all devices that support serial SCSI-3 protocol. The address list that is returned from the SNS becomes the polling list for the initiator, which then can send port logins to the listed targets and establish sessions with them.


Figure 2: Because FCIP tunneling requires both IP and Fibre Channel management applications, additional overhead is necessary for a tunneled solution.
Click here to enlarge image

In some cases, it may not be desirable for an initiator to discover all possible targets in the fabric. An NT server, for example, probably should not be allowed to discover and establish a session with a Unix storage array since NT would overwrite the array's boot sector and render it useless to Unix. Given that the SNS reports only addressing and protocol support information, there is no means within the SNS itself to restrict discovery of targets. In Fibre Channel fabric switches, segregation of devices is possible only through a technique called zoning. Zoning creates groups of devices authorized to communicate, either on the basis of port attachment or via World Wide Names. In some implementations, zoning definitions override an initiator's SNS query, and so the SNS reports only those target addresses that are in the same zone as the initiator. This leaves the initiator safely ignorant of other storage resources.

A third, related component of device discovery accommodates changes that may occur once devices have been discovered. The state change notification service is provided by a facility within the fabric that allows initiators to be notified if storage resources are removed or added to the network. State change notification (SCN) enables active responses to resource availability. For example, if a new storage resource enters the fabric, initiators can be notified and quickly establish sessions with it.

One of the main issues of Fibre Channel device discovery is scalability. Each fabric switch maintains its own SNS database. As more switches are added to a single fabric, they must be able to share SNS data so that an initiator anywhere on the network can discover viable targets. In addition, since zoning may be used to restrict the discovery process, zone information also must be exchanged. This scheme places an ever-increasing burden on switch resources as SANs scale from small departmental configurations to much larger implementations. Network convergence time is adversely impacted by the greater latency of a large network as switches update each other with SNS, zoning, and SCN information.

Discovery in IP SANs

While Fibre Channel has been forced to pioneer device discovery techniques where no precedents existed, IP-based SANs are able to draw from both IP networking applications such as Domain Name Server (DNS) as well as Fibre Channel SNS, zoning, and SCN. Nishan Systems authored the first comprehensive discovery proposal for IP storage, which has been submitted for standardization to the Internet Engineering Task Force (IETF) as an iSNS draft. iSNS leverages the database objects of SNS as well as familiar DNS techniques to create a discovery mechanism that can be distributed or centralized.

IP storage protocols

Because IP storage solutions can be based on several distinct protocols, iSNS provides support for a variety of implementations of block storage over IP. The three main protocols for IP SANs are Fibre Channel over IP (FCIP), Internet Fibre Channel Protocol (iFCP), and Internet SCSI (iSCSI). As shown in Figure 1, the iSCSI, iFCP, and FCIP protocols support a serial SCSI-3 interface to the standard SCSI command set expected by the operating system and upper-layer applications. This allows conventional storage I/O to be performed over a high-performance gigabit transport. Serial SCSI-3 transactions are carried over TCP/IP, although only iFCP and iSCSI leverage native TCP/IP for each storage end device. Each IP storage protocol has unique requirements for discovery.

FCIP is used to tunnel Fibre Channel traffic between two geographically separate Fibre Channel SANs. As shown in Figure 2, frames originating on one SAN are wrapped in IP packets and forwarded to the destination SAN. At the receiving end, the IP header is removed and native Fibre Channel frames are delivered to the fabric. A Fibre Channel fabric switch then makes the decision as to which end device the frame is intended for. In terms of discovery, the only devices that have IP addresses are the FCIP gateways themselves. IP discovery is thus limited to the FCIP gateways, while Fibre Channel discovery and management is still required for the storage end devices. Since FCIP tunneling requires both IP and Fibre Channel management applications, additional overhead is necessary for a tunneled solution. Due to the limited management requirements of FCIP gateways, FCIP is not included in the discovery and management services provided by iSNS.


Figure 3 (left): Storage devices can be dispersed throughout an IP network without being confined in Fibre Channel SANs. Figure 4 (right): iSCSI end devices can be connected by conventional IP routers and switches, which has the advantage of native IP attachment but does not accommodate existing Fibre Channel devices.
Click here to enlarge image

While FCIP can only connect Fibre Channel SANs, iFCP is used to connect individual Fibre Channel devices over an IP-based SAN. As shown in Figure 3, storage devices can be dispersed throughout an IP network without being confined in Fibre Channel SANs. iFCP storage switches are a direct replacement for Fibre Channel switches, which implies that iFCP needs something comparable to SNS for end node discovery. This function is included in iSNS. In addition to a 3-byte Fibre Channel address, an iFCP switch assigns a 4-byte IP address to each Fibre Channel end node. When a Fibre Channel device sends an SNS query, the request is intercepted by iSNS. At the Fibre Channel layer, a list of appropriate target addresses are reported to the initiator, while the IP "storage-aware" fabric handles the mapping of Fibre Channel addresses to their corresponding IP addresses to link devices across the IP network. The list of iSNS entries for iFCP devices therefore includes standard Fibre Channel-specific objects such as port address and upper layer protocol support (e.g., SCSI-3) and IP-specific entries.

iSCSI is a start-from-scratch reconstruction of a serial SCSI-3 over the IP stack and assumes that both initiators and targets are native iSCSI devices. As shown in Figure 4, iSCSI end devices can be connected by conventional IP routers and switches. This has the advantage of native IP attachment, but does not accommodate existing Fibre Channel devices. For iSCSI implementations, a gateway is required to bring both iSCSI and Fibre Channel devices into the same network. For an iSCSI initiator to discover iSCSI targets, it needs to identify which devices in the network are storage resources and what IP addresses it needs to access them. A query to an iSNS server consequently returns a list of IP addresses that the initiator has permission to access.

An enterprise network may contain all three IP storage protocol implementations, which presents an additional challenge for any discovery method. While FCIP will maintain Fibre Channel mechanisms for discovery, iSNS accommodates diversity across devices by including mechanisms for iSCSI and iFCP as well as future native IP storage protocols that may emerge.

For more information on iSNS, visit
www.ietf.org/internet-drafts/draft-ietf-ips-isns-03.txt


Tom Clark is director of technical marketing at Nishan Systems. He is also a board member of the Storage Networking Industry Association (SNIA), co-chair of the SNIA Interoperability Committee, and the author of Designing Storage Area Networks: A Practical Reference for Implementing Fibre Channel SANs (Addison Wesley Longman) and IP SANs: A Guide to iSCSI, iFCP, and FCIP Protocols for Storage Area Networks, ISBN: 0-201-75277-8 (Addison Wesley Longman, November 2001).


Coming in INFOSTOR...

DECEMBER
SPECIAL REPORT:

IP Storage: An in-depth analysis of the IP Storage standards under development, including iSCSI, iFCP, FCIP, iSNS, and more. In this collection of articles, we'll also position IP Storage against existing and future SAN technologies such as Fibre Channel and InfiniBand.

Features:


  • DWDM for storage networking and disaster recovery
  • Bandwidth vs. latency in SAN extensions
  • Security for SAN/MAN/WAN applications
  • Inside the iSNS specification
  • Storage virtualization: Part III

PLUS: Comdex New Products Wrap-up


Comment and Contribute
(Maximum characters: 1200). You have
characters left.

InfoStor Article Categories:

SAN - Storage Area Network   Disk Arrays
NAS - Network Attached Storage   Storage Blogs
Storage Management   Archived Issues
Backup and Recovery   Data Storage Archives