<font color=gray><b>Part II</b></font> iSNS: Technical overview of discovery in IP SANs

Posted on January 01, 2002

RssImageAltText

Our second installment delves into the details of the Internet Storage Name Service (iSNS) specification for device discovery in IP storage area networks.

By Tom Clark

Internet Storage Name Service (iSNS) is designed to be a lightweight discovery protocol that can be deployed in iSNS servers, IP storage switches, and target devices. Part I of the series presented a technical overview of discovery in IP SANs (see InfoStor, November 2001, p. 42), while this article examines the inner workings of the iSNS specification, including facilities for registration, discovery, and management of IP storage resources as well as zoning and state change management.

The name registration service enables IP storage devices to register their attributes and address, analogous to the Fibre Channel SNS. Initiators can then query the iSNS to identify potential targets. Zoning functionality is provided by Discovery Domains, which restricts the discovery of IP storage targets to authorized functional groups. And state change notification alerts iSNS clients to any change in status of a registered device or reconfiguration of the client's Discovery Domain.


Figure 1: The iSNS server can reside anywhere within the IP network, accessible by iFCP or iSCSI clients.
Click here to enlarge image

Discovery Domains enable a device to participate in one or more zones. Like Fibre Channel zones, Discovery Domains must be manually administered, 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 prevents inadvertent access by unauthorized initiators. Once a Discovery Domain 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 (DDSs). Analogous to zone sets in Fibre Channel, a DDS can be used to quickly reconfigure an IP SAN for different application requirements. One DDS, for example, could in clude a tape resource in an NT Discovery Domain for one configuration, while an alternate Discovery Domain configuration could move the tape device into a Unix Discovery Domain.


Figure 2: Devices A, B, and C have registered with the iSNS server, with registration information for an iFCP device shown for device A.
Click here to enlarge image

As shown in Figure 1, the iSNS server can reside anywhere within the IP network, accessible by iFCP or iSCSI clients. One or more management workstations communicate with the iSNS server, either by iSNS protocol or by SNMP.

Since iSNS provides a common resource for a variety of IP storage types, each can register with and query the iSNS server for information appropriate to the functionality it supports. An iFCP gateway, for example, could be notified of a change of state of a peer gateway. The iSNS server provides the information database, but creative use of this information is product- dependent. An iFCP storage switch, for example, could query the iSNS server for the existence of iSCSI storage targets and proxy additional entries that would make those resources available to iFCP initiators.

iSNS discovery process

The first step in the iSNS discovery process is device registration. Depending on the IP storage device type (iFCP or iSCSI), a device will register its attributes and address information to the iSNS server. The server thus builds a database of iSNS clients, which forms the raw material for assignment of Discovery Domains.

In Figure 2, devices A, B, and C have registered with the iSNS server. An example of the registration information for an iFCP device is shown for device A. This includes the entity type (iFCP), the device's 64-bit World Wide Port Name, a port ID number, the upper-layer protocol support (in this case, FCP), the device's iFCP IP address, a 64-bit World Wide Node Name, and a bit map signifying what state changes this device should be alerted to (in this case, all events). Since these devices have just registered with the iSNS server, they have not yet been assigned to Discovery Domains. For initiators, this means that no storage resources are visible.


Figure 3: The iSNS server can notify the clients that a reconfiguration of the network has occurred, which is done via state change notification.
Click here to enlarge image

Once devices have registered with the iSNS server, zoning information is supplied by a management workstation. With the appropriate Discovery Domains defined, the iSNS server can notify the clients that a reconfiguration of the network has occurred. As shown in Figure 3, this is done via state change notification.

In this example, two Discovery Domains (DD 1 and DD 2) have been created via the management workstation. These domains group devices A and B into a common zone, and devices B and C into a zone. Since device B is a participant in two Discovery Domains, it will be able to discover both devices A and C. Device A, however, will only discover device B, or any additional resources that are subsequently added to DD 1.

The state change notification issued by the iSNS server will prompt any initiators to query the iSNS for available resources. An iSNS response to a query by device A, for example, would return the address and SCSI-3 capability of device B. Device A can then perform a login to device B and begin storage transactions.


Figure 4: The network entity for iFCP can be an iFCP gateway with Fibre Channel loop or fabric-attached storage devices.
Click here to enlarge image

This discovery process can scale from small departmental SANs to extended enterprise-class SANs that may span regional, national, or international boundaries. Except for the initial creation of Discovery Domains via management, the iSNS discovery process is automatic and requires no further administration. Network administrators, however, have the flexibility to reassign resources through reconfiguration of Discovery Domains and can verify network participation through the iSNS information base.

iSNS state change notification

In the example above, state change notification was used to alert devices to changes in Discovery Domain configuration. As in Fibre Channel, an SCN is triggered by management instruction or by the addition or removal of a device from the storage switch. SCN allows for active management of end nodes and enables iSNS to maintain updated information on device availability.

Since the storage switch is directly monitoring the insertion or removal of nodes on its ports, it is immediately aware of changes and can generate change notification. In IP storage environments, however, a native iFCP or iSCSI device may not be directly attached to an SNS-aware switch but to a standard Gigabit Ethernet switch. A means is therefore required to monitor state changes in devices that may be anywhere in an IP routed network. For iSNS, this is achieved through entity status inquiry (ESI). A registered device is polled by the iSNS server at pre-established intervals to monitor its availability. If an ESI response is not received after a number of retries, the device is de-registered from the iSNS server and, in the case of target devices, a state change notification will be issued to interested initiators. The iSNS server thus can maintain an updated database of active devices and actively report any changes throughout the IP SAN.

iSNS objects

iSNS database objects include structures that are broad enough to support a diversity of products and specific, when required, for detailed information on a device's attributes. At the top of the object hierarchy is the concept of a network entity, which could be an iFCP gateway or an iSCSI gateway or device. The network entity will have one or more IP interfaces to the network, defined as portals in iSNS.


Figure 5: The iSNS object model comprises the network entity, its portal to the IP network, and a storage node object that specifies whether the iSCSI device is an initiator or target.
Click here to enlarge image

The iFCP object model defines the iFCP gateway as well as iFCP storage devices it services. As shown in Figure 4, the network entity for iFCP can be an iFCP gateway with Fibre Channel loop or fabric-attached storage devices. The iFCP storage switch represented by the network entity designation can have one or more portals into the IP network, with unique IP address and TCP port numbers. The iFCP object for iSNS also includes a storage node, representing a disk controller or tape device that may have several Fibre Channel connections (storage ports) to the gateway. The storage node and storage port objects follow traditional Fibre Channel naming conventions, with both node and port World Wide Names. For discovery, each storage node that represents a disk or tape resource is identified as a target device.

For iSCSI, the iSNS object model includes the network entity, its portal to the IP network, and a storage node object that specifies whether the iSCSI device is an initiator or target (see Figure 5). In the case of iSCSI devices, the 64-bit identifier corresponding to a Fibre Channel World Wide Name is known as a World Wide Unique Identifier (WWUI). For discovery, an iSCSI initiator would register its own presence with the iSNS server and, after being notified of a state change of Discovery Domains, query the iSNS server for storage nodes with a type of "target."

iSNS security

In addition to restricting access between initiators and targets via Discovery Domains, it is also desirable to have higher-level authentication for storage resources. As the central repository of iSNS data for device discovery and Discovery Domain enforcement, the iSNS server is the logical place to host security services. As part of the registration process, for example, an IP storage device could register its X.509 Public Key Certificate with the iSNS server. Once Discovery Domains are established, the iSNS server can distribute the appropriate public keys between devices in the same domain. As shown in Figure 6, the exchange of private keys and digital signatures necessary for device authentication occurs during the login process. In this example, an iSCSI login between initiator and target includes public and private key exchanges to establish secure communication between them.


Figure 6: The exchange of private keys and digital signatures necessary for device authentication occurs during the login process.
Click here to enlarge image

The advantage of Public Key Certificates over other security methods is scalability. While manual administration (e.g., Kerberos) may be suitable for small IP SANs, it is more convenient to leverage public key distribution from iSNS for enterprise-class storage networks.

Summary

iSNS provides a comprehensive discovery and management solution for a variety of IP storage devices. As a lightweight protocol, iSNS functions can be embedded in an IP storage switch, gateway, or router, or centralized in an iSNS server. iSNS minimizes the manual administration of an IP storage network by automating the process of registration and state change notification. With Public Key Certificate distribution, iSNS also enables secure storage transactions between devices that may exist in a public or corporate IP network.

As one of the original authors of the iSNS protocol, Nishan Systems is incorporating iSNS support in its product line, including the IPS 3000 storage switch, IPS 1000 storage gateway, and IPS 2000 Gigabit Ethernet and SCSI storage switch. iSNS support ensures compatibility for mixed IP storage environments and facilitates topology discovery for both IP storage and legacy Fibre Channel devices.

For more information on iSNS, visit invalid link: www.ietf.org/internet-drafts/draft-ietf-ips-isns-03.txt 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).

null


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