iSCSI Network architecture
An explanation of this new storage protocol's network architecture. Part 1.
By Tom Clark, marketing director, McDATA | Techworld | Published: 00:00, 05 December 2003
The intent of an iSCSI SAN is to be composed of native iSCSI initiators and iSCSI targets.
Because each host and storage resource supports a Gigabit Ethernet interface and an iSCSI protocol stack, devices can be plugged directly into Gigabit Ethernet switches and/or IP routers. In this respect, iSCSI end nodes appear simply as any other IP entities. As with standard IP implementations, direct connection to the IP network pushes responsibility for connection establishment and integrity back onto the end device, in contrast to Fibre Channel's reliance on intelligence within the fabric switch.
Consequently, an iSCSI end device must have additional logic to deal proactively with the SAN. A Fibre Channel switch or iFCP gateway, for example, assumes responsibility for monitoring device status and issuing SCNs. Because iSCSI does not assume storage intelligence in the Gigabit Ethernet switch or IP router, an iSCSI device itself must have alternate means of dealing with storage-specific phenomena.
ISCSI Protocol Layering Model
As with FCIP and iFCP, iSCSI uses TCP/IP for reliable data transmission over potentially unreliable networks. The iSCSI layer interfaces to the operating system's standard SCSI Access Method (SAM) command set, fulfilling the same function as FCP.
In addition to the normal TCP/IP transport, the iSCSI specification allows for a lower functional level on top of IP to provide services such as IPSec data encryption. The specification also allows for an optional data synchronisation and data steering mechanism, which may reside below the iSCSI layer. The purpose of this layer is to ensure in-order receipt of iSCSI data and commands, and to accommodate missing packets as data is written ("steered") directly to application memory. Without such a mechanism, an iSCSI device would require larger buffers and possibly multiple copy operations to store and then reassemble data sequences before they are passed to upper layer applications.
One or more TCP connections are established to support an iSCSI session between initiator and target. TCP connections ensure the orderly transport of the SCSI commands, status, and data carried within iSCSI packets known as PDUs. PDUs encapsulate standard SCSI CDBs to convey commands and/or data. At the iSCSI/SCSI boundary, iSCSI's PDUs thus represent a new messaging structure, distinct from the Fibre Channel FCP layer.
ISCSI Address and Naming Conventions
Following the SCSI SAM-2 architecture, iSCSI implements a client/server model. Targets are servers of data, responding to the requests from client initiators for data reads and writes. Because iSCSI represents networked stor-age, the clients and servers have a network entity identity, which is equiva-lent to the IP addresses they are assigned. The network entity may contain one or more iSCSI nodes.
The iSCSI node object defines a specific SCSI device within a network entity that is accessible through the network via a network portal. The net-work portal is the combination of the assigned IP address and the TCP port number. The network entity allows for multiple iSCSI nodes because it may represent a gateway that fronts multiple initiators or targets. Each iSCSI node is identified by a unique iSCSI name that may be manually adminis-tered. The iSCSI node name may be as long as 255 bytes.
The separation of iSCSI names and iSCSI addresses ensures that a storage device will have a unique identity in the network even if its location in the network changes. Although the IP address plus the TCP port number will necessarily change if a device is moved to a different network segment, the iSCSI name will travel with the device, allowing it to be rediscovered. In addition, the iSCSI name is “soft assigned” and remains independent of hardware. This allows, for example, a device driver on a host platform to present a single iSCSI name even if multiple storage NICs are used to attach to the network. Likewise, a target device could have multiple connections to the network for redundant “pathing” and yet be consistently identified as a single entity.
The iSCSI naming scheme is meant to rationalise the discovery process and validate a device’s identity during login. The potentially very long 255-byte iSCSI name is therefore not used for routing, which would place an immense burden on parsing engines. Instead, once the IP address and TCP port number are established for a specific iSCSI node, only the IP/TCP port combination is required for storage transactions.
iSCSI naming conventions follow the requirements of the uniform resource names (URN) standard as detailed in RFC 1737. The intention is to create a naming mechanism that provides a unique identity, is scalable, and is human readable. The default iSCSI name is “iSCSI” and it is supplied as a convenience for probing real iSCSI names if the IP address/TCP port number is known. The standard iSCSI name is composed of a type designator and naming authority, followed by the unique identifier assigned by the naming authority. For example, a fully qualified name would have a type of “fqn.”
The naming authority might be a corporation maintaining a DNS server, “ramjack.com.” The unique device name might be “bigarray.research.30221.” When assembled as a fully qualified name, the authority field is reversed, yielding “fqn.com.ramjack.bigarray.research.30221” as the full iSCSI name.
In Fibre Channel, the unique identity of a device is provided by a 64-bit WWN, whereas the network address is the 24-bit Fibre Channel address. The WWN convention is also accommodated by iSCSI naming as an IEEE extended unique identifier (EUI) format or “eui.” This provides a more streamlined, if less user-friendly name string, because the resulting iSCSI name is simply “eui” followed by the hexidecimal WWN (for example, eui.0300732A32598D26).
In either format, the usual uniform resource locator (URL)-type rules apply in that no white spaces and no special characters other than ASCII dots and dashes are allowed. The fully qualified name format, in particular, enables storage resources to be identified by signficant names that are more easily managed by an administrator. The unique identifier component can be a combination of site, department, manufacturer name, serial number, or asset number of any moniker useful for recognising a storage resource.
In addition, ISCSI provides for alias naming, although an alias is not a substitute for an assigned 1SCSI name. The alias option is provided as a convenience for quickly identiflying user resources, particularly if iSCSI names have been assigned by a manufacturer or third party and have little relevance to the customer’s network naming conventions. Alias names may he exchanged during login and can also he as long as 255 bytes. Management software is typically required to surface these names to the administrator via a command-line interface or management graphical user interface (GUI).
Regarding discovery using iSCSI, as implied by the structure of iSCSI names, either a distributed or a centralised DNS-type lookup facilitates mapping of iSCSI names required for login to actual iSCSI network addresses. For small IP SANs, the Service Locator Protocol (SLP) may be used for iSCSI discovery.
Thanks to Tom Clark and to Addison-Wesley Pearson Education for permission to quote from ' IP SANs', ISBN 0-201-75277-8