Both targets and initiators require names for the purpose of
identification, so that iSCSI storage resources can be managed
regardless of location (address). Note that this means iSCSI names
are independent of location.
Furthermore, iSCSI names are associated with iSCSI nodes instead of
with network adapter cards to ensure the free movement of network
HBAs between hosts without loss of SCSI state information
(reservations, mode page settings etc) and authorization
configuration. An iSCSI node also has one or more addresses.
An iSCSI address specifies a single path to an iSCSI node and consists
of the iSCSI name, plus a transport (TCP) address which uses the following format: [: ] If the is not specified, the
default port 3260, assigned by IANA, will be assumed. For iSCSI
initiators, the is omitted.
The concepts of names and addresses have been carefully separated in
iSCSI:
– An iSCSI Name is a location-independent, permanent identifier for
an iSCSI node. An iSCSI node has one iSCSI name, which stays
constant for the life of the node.
– An iSCSI Address specifies not only the iSCSI name of an iSCSI
node, but also a location of that node. The address consists of a
host name or IP address, a TCP port number (for the target), and
the iSCSI Name of the node. An iSCSI node can have any number of
addresses, which can change at any time.
To assist in providing a more human-readable user interface for
devices that contain iSCSI targets and initiators, a target or
initiator may also provide an alias. The alias strings are communicated
between the initiator and target at login, and can be displayed by a user interface on either end, helping the user tell at a glance whether the
initiators and/or targets at the other end appear to be correct.
The alias is a variable length string, between 0 and 255 characters.
Constructing iSCSI names using the iqn. format.
– The string “iqn.”
– A date code specifying the year and month in which the
organization registered the domain or sub-domain name used as the
naming authority string.
– The organizational naming authority string, which consists of a
valid, reversed domain or subdomain name.
– Optionally, a ‘:’, followed by a string of the assigning
organization’s choosing, which must make each assigned iSCSI name
unique.
The following is an example of an iSCSI qualified name from an
equipment vendor:
Organizational Subgroup Naming Authority
Naming and/or string Defined by
Type Date Auth Org. or Local Naming Authority
+–++—–+ +———+ +——————————–+
| || | | | | |
iqn.2001-04.com.example:diskarrays-sn-a8675309
The following is an example of an iSCSI name string from a storage
service provider:
Organization String
Naming Defined by Org.
Type Date Authority Naming Authority
+-+ +—–+ +————-+ +———————-+
| | | | | | | |
iqn.1995-11.com.example.ssp:customers.4567.disks.107
Note that when reversing these domain names, the first component
(after the “iqn.”) will always be a top-level domain name, which
includes “com”, “edu”, “gov”, “org”, “net”, “mil”, or one of the
two-letter country codes. The use of anything else as the first
component of these names is not allowed.
Constructing iSCSI names using the eui. format
The iSCSI eui. naming format allows a naming authority to use IEEE
EUI-64 identifiers in constructing iSCSI names. The details of
constructing EUI-64 identifiers are specified by the IEEE
Registration Authority (see [EUI64]).
Example iSCSI name:
Type EUI-64 identifier (ASCII-encoded hexadecimal)
+–++————–+
| || |
eui.02004567A425678D
iSCSI Discovery
The goal of iSCSI discovery is to allow an initiator to find the
targets to which it has access, and at least one address at which
each target may be accessed. This should generally be done using as
little configuration as possible. The iSCSI discovery mechanisms
listed here only deal with target discovery and one still needs
to use the SCSI protocol for LUN discovery. In order for an iSCSI
initiator to establish an iSCSI session with an iSCSI target, the
initiator needs the IP address, TCP port number and iSCSI target name information.
iSCSI supports the following discovery mechanisms:
a. Static Configuration: This mechanism assumes that the IP address,
TCP port and the iSCSI target name information are already
available to the initiator. The initiators need to perform no
discovery in this approach. The initiator uses the IP address and
the TCP port information to establish a TCP connection, and it
uses the iSCSI target name information to establish an iSCSI
session. This discovery option is convenient for small iSCSI
setups.
b. SendTargets: This mechanism assumes that the target’s IP address
and TCP port information are already available to the initiator.
The initiator then uses this information to establish a discovery
session to the Network Entity (IP address). The initiator then subsequently issues the SendTargets text command to query
information about the iSCSI targets available at the particular
Network Entity (IP address).
c. Zero-Configuration: This mechanism assumes that the initiator does
not have any information about the target. In this option, the
initiator can either multicast discovery messages directly to the
targets or it can send discovery messages to storage name servers.
Currently, the main discovery frameworks available are
SLP and iSNS. (Not supported in the first release of ESX 3.)]]>