6.3 Discovery in IP SANs

If hosts and storage targets are plugged in to a common network, only connectivity between them has been achieved. For initiators to actually communicate with targets, a discovery mechanism is required. In Fibre Channel, the discovery process is enabled by the Simple Name Server (SNS) in each fabric switch. Because all storage targets register with the SNS, initiators can simply query the SNS to identify potential resources. Unlike Fibre Channel fabrics, IP networks do not automatically provide discovery services. Typically, such advanced services are provided by a third-party server installed somewhere in the network for example, Domain Name System (DNS) servers that resolve uniform resource locator (URL) and IP address associations. Concurrent with the development of IP storage transport protocols, then, IP protocols to facilitate device discovery have also been required.

The two protocols under consideration for discovery in IP SANs are Service Locator Protocol (SLP) and Internet Storage Name Server (iSNS). SLP is an IP protocol that defines how queries can be directed to a server that in turn supplies IP addresses or names for designated storage resources. The iSNS protocol also provides IP address resolution but includes additional features for zoning, authentication, and the detection of changes in the storage network configuration.

6.3.1 Service Locator Protocol (SLP)

Although SLP was not designed for storage, it provides a means to perform elementary discovery of storage targets by initiators. Like FCIP, SLP offers a path of least resistance for vendors and is much simpler to implement than iSNS. The trade-off for vendor convenience, however, is that the SLP mechanism is not scalable to large deployments and does not offer the enhanced zoning and security features proposed by the iSNS protocol.

SLP uses a client/server scheme composed of user agents (UAs), service agents (SAs), and a directory agent (DA), as shown in Figure 6-14. The user agent can reside in an initiator or target and is responsible for establishing contact with service agents or a directory agent. The service agent maintains a list of storage resources and advertises their availability to interested user agents. A directory agent is a central repository of services; in effect, it is a management server installed somewhere in the network.

Figure 6-14. SLP user, service, and directory agents for iSCSI discovery

An SLP server agent maintains a list of storage resources as service URLs. A service URL may include the IP address, the TCP port number, and a device name for example, 10.1.30.21:5003/Fred. If the IP address is included, it is assumed that the address is static and will not change over a given time. If a URL-formatted iSCSI name with no address is used, an additional step for name resolution is required. Having obtained the URL of a storage resource, an initiator would have to query a DNS server to find the current IP address of that device. An SLP listing of targets may also have a scope entry, indicating which initiators are authorized to access the storage device.

The SLP proposal for IP storage discovery relies on the initial service request that an initiator sends when it comes onto the network. There is no equivalent of a state change notification if a storage resource is removed from the network. The initiator would instead have to rely on iSCSI session failure for notification. And although SLP includes a scope entry to identify authorized hosts for a target, there is no equivalent of Fibre Channel zones or zone sets.

This streamlined discovery mechanism is suitable for small IP SAN installations but may be difficult to scale to enterprise-class storage networks. The lack of asynchronous notifications, zoning capability, and security features may simplify the engineering tasks of vendors who implement SLP, but it narrows their market to small iSCSI configurations.

6.3.2 Internet Storage Name Server (iSNS)

The Internet Storage Name Server protocol combines Fibre Channel Simple Name Server with Domain Name System (DNS) functionality from IP networking. For proactive notification of resource availability, iSNS provides state change notification to designated initiators, and for zoning of resources provides discovery domains and domain sets. Security between initiators and targets is also enabled through public key/private key administration on an iSNS server.

Because iSNS borrows database objects from SNS, it can support discovery of both iFCP gateway-attached Fibre Channel devices and iSCSI devices. For heterogeneous SANs, iSNS thus facilitates discovery and zoning of both Fibre Channel and iSCSI targets by any mix of Fibre Channel and iSCSI hosts.

The iSNS protocol is based on a client/server model that can be implemented on IP storage switches or distributed among multiple switches and dedicated iSNS server platforms. The ability to accommodate both centralized and distributed models makes iSNS capable of scaling from small installations to enterprise-wide storage networks. Enterprise-class platforms such as Microsoft .NET can include both iSNS client and server agents.

iSNS features include facilities for registration, discovery, and management of IP storage resources as well as for zoning and state change management. The name registration service enables IP storage devices to register their attributes and address, as with the Fibre Channel SNS. Initiators can then query the iSNS to identify potential targets. Zoning functionality is provided by discovery domains (DDs), and that restricts the discovery of IP storage targets to authorized initiators. State change notification alerts iSNS clients to any change in status of a registered device or reconfiguration of the client's discovery domain.

iSNS discovery domains enable a device to participate in one or more zones. Like Fibre Channel zones, DDs must be administered manually, at least for the initial establishment of functional groups within the network. By default, a new device is isolated from the storage network until a management workstation assigns it to a specific discovery domain. This arrangement prevents inadvertent access by unauthorized initiators. After a DD has been configured for the device, state change notification is used to alert authorized initiators that a new resource has been added to the domain.

iSNS also supports discovery domain sets (DDS). Analogous to a zone set in Fibre Channel, a DDS can be used to quickly reconfigure an IP SAN for different application requirements. One DDS, for example, could include a tape resource in an NT discovery domain for one configuration, whereas an alternative DD configuration could move the tape device into a UNIX discovery domain.

As shown in Figure 6-15, an iSNS server can reside anywhere within the IP network, accessible by iFCP or iSCSI clients. One or more management workstations are used to configure and monitor the iSNS server, either by iSNS protocol or Simple Network Management Protocol (SNMP). Because iSNS provides a common resource for a variety of IP storage types, each can register with and query the iSNS server for information relevant to the functionality the device supports. An iFCP gateway, for example, could query the iSNS server for the existence of iSCSI storage targets and, if it provided iFCP to iSCSI translation, proxy additional entries that would make those resources available to iFCP-attached initiators.

Figure 6-15. A centralized iSNS server for a multiprotocol IP SAN

After devices have registered with the iSNS server, zoning information is supplied by a management workstation. With the appropriate DDs defined via management, the iSNS server can notify the clients that a reconfiguration of the network has occurred. The state change notification issued by the iSNS server will prompt any initiators to query the iSNS for available resources.

As the central repository of data for device discovery and discovery domain enforcement, the iSNS server is a logical place to host security services. As part of the iSNS registration process, for example, an IP storage device could register its X.509 Public Key Certificate with the iSNS server. After DDs are established, the iSNS server can distribute the appropriate public keys between devices within the same domain.

Compared with SLP, iSNS requires more engineering for iSCSI adapters, iSCSI targets, and iFCP gateways. That is a vendor issue, however, and should be transparent to the customer. The advanced services provided by iSNS make it more suitable than SLP for enterprise storage networking and the preferred discovery mechanism for SANs that include both Fibre Channel and iSCSI components.