One document matched: draft-ietf-ips-iscsi-name-disc-00.txt-94091.txt
iSCSI
Internet Draft
Mark Bakke
Cisco
Joe Czap
IBM
Jim Hafner
IBM
Howard Hall
Pirus
Jack Harwood
EMC
John Hufferd
IBM
Yaron Klein
Sanrad
Lawrence Lamers
San Valley Systems
Todd Sperry
Adaptec
Joshua Tseng
Nishan
Kaladhar Voruganti
IBM
draft-ietf-ips-iscsi-name-disc-00. February, 2001
Expires August 2001
iSCSI Naming and Discovery Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to produce
derivative works is not granted. Internet-Drafts are working documents
of the Internet Engineering.Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft documents
valid for a maximum of six months and may be updated, replaced, or
obsoleted by other documents at any time. It is inappropriate to use
Internet- Drafts as reference material or to cite them other than as
"work in progress." The list of current Internet-Drafts can be
accessed at http://www.ietf.org/ietf/1id-abstracts.txt
Voruganti Internet Draft Expires August 2001 1
iSCSI Naming and Discovery February 2000
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or
to kaladhar@us.ibm.com
1. Abstract
This document describes the iSCSI [7] naming and discovery
requirements. The requirements presented in this document have been
agreed to by the members of the iSCSI naming and discovery team. This
document complements the iSCSI IETF draft. Flexibility is the key
guiding principle behind this requirements document. That is, an
effort has been made to satisfy the needs of both small isolated
environments, as well as large environments requiring secure/scalable
Page 2
draft-ietf-ips-iscsi-name-disc-00.doc
solutions.
This document has been organized into the following sections:
a) Section 3 presents the naming requirements. It discusses the
concept of a world wide unique identifer (WWUI).
b) Section 4 discusses the discovery requirements.
c) Section 5 presents Storage Name Server (SNS) requirements.
d) Section 6 presents the details of iSNS. iSNS
meets the requirements of SNS. The protocols identified in section
6, which are used by iSNS, MUST also be supported by any iSCSI
compliant SNS protocol.
e) Section 7 briefly lists the other existing discovery protocols.
f) Section 8 briefly discusses the security implications on the
discovery mechanism.
g) Appendix A describes the different hardware and software components
with whom the initiator and target WWUIs can be associated.
h) Appendix B contains examples on how the WWUIs are to be used in
iSCSI Login commands.
i) Appendix C contains a taxonomy of iSCSI proxy and firewall
concepts. This taxonomy helps to evaluate the behavior of the
discovery mechanism when dealing with proxies and firewalls.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3. Naming Requirements
In order for an iSCSI initiator to connect to an iSCSI target, the
initiator needs to provide information about the Network Entity
object, Portal Object and the target Storage Node object. The details
of these three iSCSI objects are as follows:
a) Network Entity Object
The Network Entity object represents a device or gateway that is
accessible from the IP network. This device or gateway may support
one or more initiators or targets that are either internal to the
storage device or accessible through a network behind the gateway.
Each initiator or target is represented by subordinate Storage Node
objects.
b) Portal Object
The Portal object is a port through which access to any Storage Node
object within the Network Entity object can be obtained. A Network
Entity object must have one or more Portal objects, each of which is
usable by Storage Node objects contained in that Network Entity
object to gain access to the IP network. The Portal object is
identified by its IP address and Port number.
c) Storage Node Object
The Storage Node object defines an individual iSCSI initiator or
target. There may be one or more Storage Node objects within the
Network Entity object. A Storage Node object is identified by its
world wide unique identifier (WWUI). There is a requirement to have
the ability to generate world wide unique identifiers (WWUIs) for both
iSCSI initiators and targets. However, it is not mandatory for the
initiators and targets to use WWUIs because a globally unique
Page 3
draft-ietf-ips-iscsi-name-disc-00.doc
identifier might not be required in some simple, isolated iSCSI
configurations. WWUIs are useful because in some cases (e.g. when DHCP
services [6] are used etc), the combination of IP address and port
number [6] cannot uniquely identify an initiator or a target.
There is a default Storage Node object present at every target network
entity that can be accessed without specifying the WWUI. However, if
there are multiple iSCSI target Storage Nodes that are serviced by a
single Network Entity and Portal objects, then it is necessary for
the initiator to specify the target Storage Node WWUI to uniquely
identify the target storage node. An alias string could also be
associated with a target storage node. The target alias helps an
organization to associate their own semantic meaning with the target
alias string. However, the target alias string is not a substitute for
the target WWUI.
3.1 World Wide Unique Identifier
The WWUI uniquely identifies iSCSI initiators and targets. The
initiator WWUI corresponds to the logical operating system on which
the initiator is running, and the target WWUI corresponds to the
target Storage Node entity.
A WWUI really names a logical software entity, and is not generally
tied to a port or other hardware that can be changed. For instance,
an initiator WWUI should name the iSCSI initiator driver, and not
a particular NIC or HBA card. When multiple NICs are used, they
should generally all present the same WWUI to the targets, since
they are really to the same entity. In most operating systems, the
named entity is the operating system image. Most hosts will have a
single OS running; some of the really big ones could have multiples.
A target WWUI should similarly not be tied to hardware interfaces
that can be changed. A WWUI should identify the logical target,
and must be the same for the target regardless of the physical port
on which it is addressed. This gives iSCSI initiators an easy way
to determine that two targets it has discovered are really two paths
to the same target.
The iSCSI WWUI is designed to fulfill the functional requirements
for Uniform Resource Names (URN) [RFC1737]. Among these requirements
are that the WWUI must have a global scope, independent of address
or location, and that it be persistent and globally unique. It must
be extensible, and scale with the use of naming authorities. The
encoding of the WWUI should be transcribable by a human, as well as
be machine-readable. There are other requirements as well; please
read RFC1737 (only 5 pages) for definitions of these requirements.
The WWUI may be displayed by user interfaces, but is generally
uninterpreted and used as an opaque, case-insensitive string for
comparison with other WWUI values.
A WWUI is text-based. This was done for the following reasons:
- A text-based identifier is transcribable, and is easier to
differentiate when looking at a user interface, or while
debugging problems with iSCSI login and discovery.
- WWUIs are only used during login and discovery phases, so the
overhead does not get in the way of the data path.
- The iSCSI protocol communicates these via text strings anyway,
Page 4
draft-ietf-ips-iscsi-name-disc-00.doc
so it "fits in" easily.
A WWUI consists of three parts: a type designator, followed by a
naming authority, with the remaining format designated by the naming
authority itself, subject to the following requirements.
A WWUI can be any Unicode character string with the following
properties:
- it is in Normalization Form C (see Unicode Standard Annex #15,
"Unicode Normalization Forms" at
http://www.unicode.org/unicode/reports/15)
- it contains only the ASCII dash character ('-'=U+002d) or the
ASCII dot character ('.'=U+002e) or is in one of the following
Unicode
General Categories:
a) Lu (Letter, Uppercase)
b) Ll (Letter, Lowercase)
c) Lt (Letter, Titlecase)
d) Lm (Letter, Modifier)
e) Lo (Letter, Other)
f) Nd (Number, Decimal Digit)
g) Nl (Number, Letter)
h) No (Number, Other)
- when encoded in UTF-8, it is no more than 255 bytes
In particular, white space, punctuation (except as noted), marks and
symbols are not allowed.
When included in Text or Login messages, a WWUI SHALL be formatted in
UTF-8 form.
For the purposes of comparison, computing hash values, or anything
else that operates on a WWUI, the WWUI must first be converted to
lower-case in a locale-independent manner (case-folding) per the rules
described in Unicode Technical Report #21, "Case Mappings", section
2.3 "Caseless Matching" (see
"http://www.unicode.org/unicode/reports/tr21").
When inserting a WWUI into a URI format to be used as either a URL
or a URN, the following transformations should take place. The WWUI
should be first converted to a UTF-8 string. Then the rules of RFC
2396 (excluded characters) and RFC 2732 (re-allowed characters) SHALL
be applied to convert this byte string into an allowable URI ASCII
string. This process is invertable so there is no loss of information.
The format for an iSCSI URN is specified in [20].
Since there are different types of naming authorities, there are
different types of WWUIs to make use of them. Each WWUI is
prefixed with a short type designator string that indicates the
type of naming authority being used.
Here are the type designator strings that may currently be used:
iscsi - Not unique; indicates a "canonical" target or
initiator.
iscsi. - Naming authority is a reverse DNS name
eui. - Remainder of the string is an EUI-64 address.
oui. - Naming authority is a 24-bit Organizationally
Unique Identifier.
dns. - A format tied to a particular DNS address as
a naming authority.
Page 5
draft-ietf-ips-iscsi-name-disc-00.doc
The creation of additional type designator strings must be done
via the IETF IPS working group. Use of type strings not listed
here is not allowed, as they cannot be guaranteed to be unique.
The use of the naming authority means that WWUIs can be assigned by
virtually any uniqueness scheme that can be devised by OS vendors,
driver or iSCSI NIC vendors, device vendors, gateway vendors, and even
the customer.
The WWUI scheme's use of naming authorities is designed to fulfill
RFC 1737 "Functional Requirements for Uniform Resource Names".
A WWUI can be incorporated into a Uniform Resource Name (URN) by
methods shown later in this document.
Type "iscsi"
This type does not specify a real WWUI; it is used during login
as a default or canonical WWUI.
Example WWUI:
iscsi
This type does not use a naming authority, and so is not a real
WWUI. Every device allowing target connections will support this
as a default target, so it is not world-wide unique. Every device
supporting the "iscsi" WWUI should also support an actual WWUI of
one of the other three types.
Type "iscsi." (reverse DNS naming authority format)
This WWUI type can be used by either a manufacturer, end user,
or service provider. This naming authority is handy especially
when an end user or service provider wishes to provide the WWUI
for a target. These customers all own DNS domains; the same is
not true for OUI, SCSI Vendor ID, or any of the other assigned
identifiers that could be used as a naming authority.
The Text WWUI string is defined as follows:
After the "iscsi.", the string starts with a backwards domain
name specifying the Naming Authority, using dots as separators,
just as in a regular domain name. It's backwards, since it is
not really used as a fully qualified host name; only the necessary
top levels need by used.
Basically, everything after the backwards domain name, followed
by another dot ".", can be assigned as needed by the owner of
the domain name.
Here is an example Text WWUI string:
iscsi.com.acme.diskarrays.sn.a8675309
Where:
"iscsi" defines that the Naming Authirity is in the DNS string.
"com.acme" defines the Naming Authority. The owner of the DNS
name "acme.com" has the sole right of use of this name within
a WWUI, as well as the responsibility to keep the remainder of
the WWUI unique. In this case, acme.com happens to manufacture
Page 6
draft-ietf-ips-iscsi-name-disc-00.doc
disk arrays.
"diskarrays" was picked arbitrarily by acme.com to use to
identify the disk arrays they manufacture. Another product
that ACME makes might use a different name, and have their
own namespace independent of the disk array group.
"sn" was picked by the disk array group of Acme to show that
what follows is a serial number. They could have just assumed
that all WWUIs are based on serial numbers, but they thought
that perhaps later products might be better identified by
something else. Adding "sn" was a future-proof measure.
"a8675309" is the serial number of the disk array, uniquely
identifying it from all other arrays.
Please note that WWUI is NOT an address - even though it uses a DNS
name, this is for the naming authority only; it is not an address
used to discover anything.
Note that we could have used the SCSI Vendor ID as a naming
authority. However, some large customers and service providers
may wish to use their own identification scheme, rather than
that provided by the manufacturer. These customers would not
likely have a registered Vendor ID, but the domain name we
used is ubiquitous, and seemed more appropriate.
Further examples of DNS WWUIs are given at the end of this
document.
Type "eui." (IEEE EUI format)
The IEEE WWUI might be used when a manufacturer is already
basing unique identifiers on World-Wide Names as defined in
the SCSI SPC-2 specification.
It may also be used by a gateway representing a Fibre Channel
or SCSI device that is already adequately identified using a
world-wide name.
The format is "eui." followed by 16 hex digits.
Example WWUI:
eui.02004567A425678D
Type "oui." (Organizationally Unique Identifier)
The format is "oui.", followed by 6 hex digits specifying the naming
authority's OUI, followed by whatever format the naming authority
wishes to use.
Example WWUI:
oui.04205A.08940593B45A
oui.04205A.diskserialnumber.4G521AZ
Type "dns." (DNS Address used as a naming authority)
This format may be used to provide a very localized naming authority
Page 7
draft-ietf-ips-iscsi-name-disc-00.doc
by adding a fully qualified domain name (FQDN) after the "dns.". This
format may be used when generating WWUIs that will not change
locations, since it includes the host name of the target within its
format.
The format is "dns.", followed by the FQDN of the entity providing
the name, followed by whatever format the naming authority wishes
to use.
An advantage of this format is that an address may be extracted
from it without querying a name server.
CAUTION: This format includes an address, and therefore does not
fulfill the global name space requirement for a Uniform Resource
Name (URN). Please consider whether one of the other formats
is appropriate before using this one.
Initiator and Target Requirements for WWUI support:
Each initiator and target implementation must support the use
of a WWUI.
The initiator MUST send an InitiatorWWUI and a TargetWWUI as text
fields within the login request. If the initiator does not have or
support a WWUI, it must send an InitiatorWWUI of "iscsi". If the
initiator is logging in to the canonical (default) target, it must
specify a TargetWWUI of "iscsi". Note that if an InitiatorWWUI
of "iscsi" is used, the initiator stands the risk that it will be
excluded from accessing some of all of its targets.
An initiator MAY send an InitiatorAlias as a text field within its
login request. The target may use this as an informational field
only; it must not be used for unique identification or
authentication purposes.
The target MUST send a TargetWWUI as a text field within its login
response. Unless the initiator specified the TargetWWUI "iscsi"
in the request, this TargetWWUI MUST match that specified by the
initiator. If the initiator had specified a TargetWWUI of "iscsi",
this TargetWWUI should be the actual WWUI of the target, or can
be returned as "iscsi" if either the target is just a canonical
target used for the SendTargets command, or if the target does
not have a WWUI.
The target MAY send a TargetAlias as a text field within its login
response. The initiator may use this as an informational field
only; it must not be used for unique identification or
authentication purposes.
Initiators and targets shall support the receipt of WWUIs of up to
the maximum length. If configuration of the initiator or target WWUI
is allowed, the implementation shall support the maximum length.
In their user interfaces, both shall support, at a minimum, the
display of the ASCII characters within the WWUI UTF-8 string. If
the other characters are unsupported, they may be displayed with
escape codes as specified in [RFC 2396].
3.2 Alias String
Page 8
draft-ietf-ips-iscsi-name-disc-00.doc
The alias string is a UTF-8 text string that may be used as an
additional descriptive name for an initiator and target. This
may not be used to identify a target or initiator during login,
and does not have to follow the uniqueness or other requirments
of the WWUI. 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 must NOT be used to identify, address, or
authenticate initiators and targets.
The alias is a variable length string, between 0 and 255 characters,
and is terminated with at least one NULL (0x00) character. No
other structure is imposed upon this string.
3.2.1 Purpose of an Alias
Initiators and targets are uniquely identified by a World-Wide
Unique Identifier (WWUI). These identifiers may be assigned by
a hardware or software manufacturer, a service provider, or even
the customer. Although these identifiers are nominally human-
readable, they are likely be be assigned from a point of view
different from that of the other side of the connection. For
instance, a target WWUI for a disk array may be built from the
array's serial number, and some sort of internal target ID.
Although this would still be human-readable and transcribable,
it offers little assurance to someone at a user interface who
would like to see "at-a-glance" whether this target is really
the correct one.
The use of an alias helps solve that problem. An alias is
simply a descriptive name that can be assigned to an initiator
or target, that is independent of the WWUI, and does not have
to be unique. Since it is not unique, the alias must be used
in a purely informational way. It may not be used to specify
a target at login, or used during authentication. It is not used
in place of the old iscsi "path" concept; WWUI is used there
instead.
Both targets and initiators may have aliases.
3.2.2 Target Alias
To show the utility of an alias, here is an example using an
alias for an iSCSI target.
Imagine sitting at a desktop station that is using some iSCSI
devices over a network. The user requires another iSCSI disk,
and calls the storage services person (internal or external),
giving any authentication information that the storage device
will require for the host. The services person allocates a
new target for the host, and sends the WWUI for the new target,
and probably an address, back to the user. The user then adds
this WWUI to the configuration file on the host, and discovers
the new device.
Without an alias, a user managing an iSCSI host would click
on some sort of "show targets" button to show the targets to
which the host is currently connected.
+--Connected-To-These-Targets----------------------
|
Page 9
draft-ietf-ips-iscsi-name-disc-00.doc
| WWUI
|
| com.acme.sn.5551212.target.450
| com.acme.sn.5551212.target.489
| com.acme.sn.8675309
|
+--------------------------------------------------
In the above example, the user sees a collection of WWUIs, but
with no real description of what they are for. They will, of
course, map to a system-dependent device file or drive letter,
but it's not easy looking at numbers quickly to see if everything
is there.
If a more intelligent target configures an alias for each target,
perhaps at the time the target was allocated to the host, a more
descriptive name can be given. This alias is sent back to the
initiator as part of the login or sendTargets responses, for use
in a display such as this. The new display might look like:
+--Connected-To-These-Targets----------------------
|
| Alias WWUI
|
| Oracle 1 com.acme.sn.5551212.target.450
| Local Disk com.acme.sn.5551212.target.489
| Exchange 2 com.acme.sn.8675309
|
+--------------------------------------------------
This would give the user a better idea of what's really there.
In general, flexible, configured aliases will probably be
supported by larger storage subsystems and configurable gateways.
Simpler devices will likely not keep configuration data
around for things such as an alias. The TargetAlias string
could be either left unsupported (not given to the initiator
during login) or could be returned as whatever the "next best
thing" that the target has that might better describe it.
Since it does not have to be unique, it could even return
SCSI inquiry string data.
Note that if a simple initiator does not wish to keep or display
alias information, it can be simply ignored in the login or
sendTargets responses.
3.2.3 Initiator Alias
An initiator alias can be used in the same manner as a target
alias. An initiator would send the alias in a login request,
when it sends its WWUI. The alias is not used for authentication,
but may be kept with the session information for display through
a management GUI or command-line interface (for a more complex
subsystem or gateway), or through the iSCSI MIB.
Note that a simple target can just ignore the Initiator Alias
if it has no management interface on which to display it.
Usually just the hostname would be sufficient for an initiator
alias, but a custom alias could be configured for the sake of the
service provider if needed. Even better would be a description of
what the machine was used for, such as "Exchange Server 1", or "User
Page 10
draft-ietf-ips-iscsi-name-disc-00.doc
Web Server".
Here's an example showing a list of sessions on a target device.
For this display, the targets are using an internal target number,
which is a fictional field that has purely internal significance.
+--Connected-To-These-Initiators-------------------
|
| Target Initiator WWUI
|
| 450 com.sw.cd.12345678-OEM-456
| 451 com.os.hostid.A598B45C
| 309 com.sw.cd.87654321-OEM-259
|
+--------------------------------------------------
And with the initiator alias displayed:
+--Connected-To-These-Initiators-------------------
|
| Target Alias Initiator WWUI
|
| 450 Web Server 4 com.sw.cd.12345678-OEM-456
| 451 scsigate.yours.com com.os.hostid.A598B45C
| 309 Exchange Server com.sw.cd.87654321-OEM-259
|
+--------------------------------------------------
This gives the storage administrator a better idea of who is
connected to their targets. Of course, one could always do
a reverse DNS lookup of the incoming IP address to determine
a host name, but simpler devices really don't do well with that
particular feature due to blocking problems, and it won't
always work if there is a firewall or iSCSI gateway involved.
Again, these are purely informational and optional.
Aliases are extremely easy to implement. Targets just send
a TargetAlias whenever they send a TargetWWUI. Initiators just
send an InitiatorAlias whenever they send an InitiatorWWUI.
If an alias is received that does not fit, or seems invalid
in any way, it is ignored.
4. iSCSI Discovery
The goal of iSCSI discovery is to allow an initiator to find the
targets to which it has access (named by their WWUIs), and at least
one address at which each target may be accessed. This should
generally be done using as little configuration as possible. This
section defines the discovery mechanism only; no attempt is made
to specify central management of iSCSI devices within this document.
There are several methods that may be used to find targets and their
addresses, ranging from configuring a list of targets and addresses
on each initiator and doing no discovery at all, to configuring
nothing on each initiator, and allowing the initiator to discover
targets via multicast mechanisms.
An iSCSI initiator can discover iSCSI targets in these ways:
a. iSCSI targets are configured on the initiator.
b. The initiator queries iSCSI servers using the SendTargets command.
Page 11
draft-ietf-ips-iscsi-name-disc-00.doc
c. The initiator queries a storage name server, such as iSNS, for
targets.
d. The initiator uses the Service Location Protocol (SLP) to find
iSCSI targets, iSCSI servers, and storage name servers.
4.1 Configuring Target Information
The exact manner in which the target information is hard-coded at the
initiator is an implementation detail. The information could be
present in some persistent location (such as a file) that can be
accessed by the initiator.
Target discovery can be configured on an initiator in several ways:
- Full Target URL. This includes the target's IP address or host
name, TCP port, and WWUI. No further discovery is required to
contact this target.
- Target WWUI. This includes only the target's WWUI, and contains
no address information. The initiator must query SLP or a name
server to locate this target.
- Canonical Target WWUI. This is just an iSCSI server's IP address
and TCP port, the canonical WWUI "iscsi". The initiator must
connect to this address, log in to the canonical target, and issue
a SendTargets command to acquire the list of targets it can use.
- Storage Name Server Address. This is an address of a storage name
server, such as iSNS, that the initiator may query to find more
targets. The information required to configure an initiator for a
storage name server is outside the scope of this document.
4.2 SendTargets Command
An initiator may connect to an iSCSI address (IP address + TCP port)
and log in to the canonical target WWUI "iscsi". The login process
for this target is identical to that of any other target. If there
are no targets available that would provide access to the initiator's
WWUI, the target SHOULD reject the initiator's login to the canonical
target with the status code set to 0x42 "forbidden target".
Upon successful login to the "iscsi" target, the initiator may send
the text command "SendTargets", to retrieve a list of target WWUIs
to which it may attempt login.
The canonical target MUST support this command, and MUST return a list
of zero or more target WWUIs. Each WWUI returned may include zero or
more TargetAddress fields, as well one optional TargetAlias field. If
zero WWUIs are returned, the canonical target is unaware of any
targets
that are accessible by the initiator.
The command is sent by formatting an iSCSI Text Command, with the
Final (F) bit set to 1. The first key in the command's text must
be
SendTargets=
No value is sent for the send-targets key, and no other keys are
sent.
Page 12
draft-ietf-ips-iscsi-name-disc-00.doc
The response to this command is a text response containing a
list of text keys. Each target starts with one text key of the
form:
TargetWWUI=<target-wwui-goes-here>
It may then include zero or more address keys:
TargetAddress=<hostname-or-ipaddress>[:<tcp-port>]
It may then include the optional target alias key:
TargetAlias=<alias-string-goes-here>
This example is the SendTargets response from a single target,
that has no other interface ports, and does not support an alias:
TargetWWUI=com.acme.diskarray.sn.8675309
Note that all it really had to return in the simple case was the
WWUI. It is assumed by the initiator that the IP address and TCP
port for this WWUI are the same as used on the current connection
to the canonical iSCSI target.
The next example has two internal iSCSI targets, each support via
two different ports with different IP addresses:
TargetWWUI=com.acme.diskarray.sn.8675309
TargetAddress=10.1.0.45:3000
TargetAddress=10.1.1.45:3000
TargetAlias=Oracle disk four
TargetWWUI=com.acme.diskarray.sn.1234567
TargetAddress=10.1.0.45:3000
TargetAddress=10.1.1.45:3000
TargetAlias:Oracle disk five
Note that both targets share both addresses; the multiple addresses
are likely used to provide multi-path support. The initiator may
connect to either targetWWUI on either address.
Also note that in the above example, a DNS host name could have
been returned instead of an IP address, and that an IPv6 addresses
(5 to 16 dotted-decimal numbers) could have been returned as well.
After obtaining a list of targets in this manner, an iSCSI initiator
may create new sessions to log in to the discovered targets. The
initiator MAY keep the session to the canonical target open, and MAY
send subsequent SendTargets commands to discover new targets. The
target MUST send any iSCSI-level async event notifications on this
session, to allow the initiator to discover new targets as they are
created.
4.2.1 Redirect Responses
If a target has moved, or if the iSCSI device logged in to has
knowledge of another address at which a target should be accessed,
it MAY return a redirect response by setting the iSCSI login status
to one of the 0x3x status codes, and returning at least one text
key with a new target address on which to find the target. This
status terminates the session.
Page 13
draft-ietf-ips-iscsi-name-disc-00.doc
The initiator, upon receiving a redirect response, SHOULD either
abandon attempts to log in to the intended target, or attempt to
re-login to the target using one of the addresses provided.
A target might do this for load balancing or it might do this to
provide
multiple virtual targets through a simple initiator discovery
protocol.
The target's response includes the WWUI of the target, plus one
or more TargetAddress fields, as specified in the SendTargets
response.
Here's a simple example:
T->Login Response(status=3x)
TargetWWUI=iscsi.com.acme.diskarray.sn.999999
TargetAddress=10.1.0.49:3000
In the above example, a new address exists for the target WWUI at
10.1.0.49, TCP port 3000. If the TCP port was not specified, it
would use the default port (to be assigned by IANA).
Another example would include multiple addresses for a target, perhaps
through multiple ports on a storage controller, or through multiple
gateways:
T->Login Response(status=3x)
TargetWWUI=iscsi.com.acme.diskarray.sn.999999
TargetAddress=10.2.30.100
TargetAddress=10.2.40.100:2301
TargetAddress=mystorage.mycompany.com
Note that the address may be either an IP address or DNS host name.
The first and third addresses to not include a TCP port; these would
use the default, IANA-assigned TCP port.
In any case, the TargetWWUI returned is identical to that requested
by the initiator in the initial Login Request. The redirect status
is not used to change WWUIs; it is only used to move a WWUI from
one IP address and/or TCP port to another.
4.3 Initiator queries a Storage Name Server (SNS)
Discovery and management of iSCSI devices can be extended by the use
of Storage Name Servers (SNS). The term "SNS" used in this document
should not be confused with the specific implementation used in
Fibre Channel; it is meant to be a generic term.
An SNS can add capabilities beyond discovery of iSCSI targets, but for
the purposes of this section it must at least provide a method of
discovering:
1. The addresses at which a particular WWUI may be found
2. A list of WWUIs and/or addresses to which the initiator has access
To make use of an SNS, an initiator must support a protocol that
provides SNS query facilities.
4.4 Initiator Uses the Service Location Protocol
Page 14
draft-ietf-ips-iscsi-name-disc-00.doc
A storage name server address may be either configured, or discovered
through SLP.
An initiator may use the Service Location Protocol, Version 2 (SLPv2)
to locate iSCSI targets, canonical targets, and storage name servers,
without having to configure their addresses. SLP Version 1 is not
supported by iSCSI.
The Service Location Protocol (SLP) is a standard protocol for
locating the addresses of resources on a network. iSCSI targets,
canonical targets, and storage name servers may advertise themselves
to iSCSI initiators using SLP.
Three types of nodes participate in SLP discovery. A User Agent (UA)
is the entity that wishes to discover resources. In this case, the UA
is part of the iSCSI initiator. A Service Agent (SA) is the entity
that wishes to be discovered. In our case, the SA is part of the
iSCSI target, canonical target, or storage name server. A third
entity, the
Directory Agent (DA) is an optional part of discovery. If a DA is
present, it collects information about the Service Agents, and is
queried by the User Agents, to reduce the network load of all UAs
trying to discovery all SAs.
For true zero-configuration, SLP makes use of multicast to locate DAs
or SAs. However, SLP is designed to use as little multicast traffic
as possible, and by using a DA, and configuring its address on each
initiator, will not require multicast at all.
The SLP Protocol is described in detail in [RFC2608].
A target can register either its canonical target address, its
targets themselves, or both with SLP. A storage name server can
register its address with SLP, or can also register its targets
with SLP, if desired.
Initiators can send the following service requests using SLP:
1. Locate all canonical targets ("iscsi")
2. Locate specific targets to which the initiator might have access
3. Locate a specific target by WWUI
4. Locate storage name servers
In addition, a storage name server can act as an initiator and make
use of SLP to discover targets and canonical targets for its own use.
If a specific target is found, the initiator may simply attempt to
log in to that target. An initiator supporting a storage name
service may additionally query the SNS for more information on the
target before logging in. Note that the same target may exist at
more than one address; it is the responsibility of the initiator to
ensure that the targets' WWUIs are compared, and that either only
one address is used, or that some form of multi-path software is
in place.
If a canonical target is found, the initiator may log in to the
canonical target, and issue a SendTargets command as described in
the previous section.
If a storage name server is found, and the initiator supports the
use of this type of storage name server, the initiator may query
the SNS as described by its particular protocol specification.
Page 15
draft-ietf-ips-iscsi-name-disc-00.doc
In general, if an initiator supports an SNS, it should normally
not attempt to discover targets and canonical targets via SLP; it
should first attempt to discover the SNS itself, and query the SNS
for this information.
The choice of static configuration, SNS discovery or target storage
discovery protocols is a configuration choice of the initiator.
In summary, this discovery approach is flexible in that the initiators
have the freedom to select static configuration, a multicast based
discovery mechanism for small, isolated iSCSI environments, or they
can choose a scalable storage name server based discovery mechanism
for large iSCSI environments.
Additionally, targets and initiators may be configured to participate
or not participate in an SLP Scope, which allows the SLP discovery
environment to be contained within a smaller group.
The Service Location Protocol uses templates, registered with IANA,
to define the addresses and attributes that are communicated via
SLP. The SLP templates implementation details are provided in [21]
draft-bakke-iscsi-SLP-template.00, but a brief summary is as follows:
Service:iscsi - A top-level abstract template, which is just a name
under which to place our other templates.
service:iscsi:target - A concrete target template, which defines
the addresses and attributes for iSCSI targets and canonical targets.
service:iscsi:name-service - A concrete target template, which
defines the addresses and attributes for storage name services.
5. Storage Name Server (SNS)
The following section describes requirements for any Storage Name
Server used to support iSCSI. An example of a Storage Name Server is
the iSNS described in the draft document draft-ietf-ips-iSNS-00.txt
[8]. There potentially could be other protocols which also satisfy SNS
requirements.
5.1 Overview
A SNS shall be architected using a client-server paradigm, with a SNS
server predominantly serving a passive role. SNS clients actively
register and manipulate entity objects and their attributes in the SNS
server. A SNS server MAY send asynchronous state change notifications
to registered SNS clients in response to an action by a SNS client.
Examples of SNS clients include initiators, targets, management
stations, and switches. A SNS server can be hosted on a target,
switch, or stand-alone server.
5.2 Login Control and Discovery Domains
Discovery Domains (DD's) are logical groupings of iSCSI devices that
are allowed to "see" each other. SNS MUST support Discovery Domains
and Login control. SNS must provide SNS clients with the ability to
Enforce Discovery Domain configurations which may exist on a SNS
server. Targets and management stations shall be able to register
Page 16
draft-ietf-ips-iscsi-name-disc-00.doc
(i.e., upload) Login Control and Discovery Domain configurations to
the SNS if authorized by the end user. Discovery Domains and Login
control supports two separate purposes:
5.2.1 Discovery Domain Partitions
A SNS SHALL support the ability to partition the storage network into
Separate "Discovery Domains". A SNS shall not provide information if
the SNS client performing the query is not in a common Discovery
Domain (DD) as the SNS client that is the subject of the request.
This capability prevents an initiator from attempting an iSCSI login
to every single target in a large enterprise network, and is the iSCSI
equivalent of "Soft" zoning.
5.2.2 Login Control
Login access security which is specified in the iSCSI
Draft (Appendix A) [7] and may be implemented by the iSCSI target. A
SNS shall support login control by storing a mapping of initiators
that are permitted to access each target. Targets shall be able to
query the SNS for a list of initiators that are allowed login access.
This list shall include the key attribute (e.g., WWUI) used to
identify the initiator. This capability is the iSCSI equivalent of
"Hard" zoning.
5.3 Object Model
A SNS MUST store the following objects and attributes:
Network Entity:
- Entity Identifier
- Management IP Address
- Entity Type (iSCSI)
Portal:
- IP Address
- TCP Port Number
Storage Node:
- WWUI
- Alias
- Node Type (target or initiator or both)
Discovery Domain:
- DD symbolic name
- DD ID
- DD Member: WWUI
- DD Member: IP Address
A diagram of how the above objects are related is shown
below.
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
Page 17
draft-ietf-ips-iscsi-name-disc-00.doc
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -WWUI | | | | -WWUI | |
| | -Alias: "server1"| | | | Alias: "disk1" | |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (DNS): | | -Entity ID (DNS): |
| "strg1.foo.com" | | "strg2.bar.com" |
| -Type: iSCSI | | -Type: iSCSI |
| | | |
+-------------------------+ +-------------------------+
A DISCOVERY DOMAIN contains one or more NETWORK ENTITY,
PORTAL,
and/or STORAGE NODE, objects. Each NETWORK ENTITY object contains
one or more PORTAL objects, and one or more STORAGE NODE objects.
5.4 SNS Message Format Requirements
The SNS protocol SHALL be TLV based.
TLV (TLV is already used in many networking protocols such as DHCP).
The SNS protocol shall allow manipulation of multiple objects and
attributes in a SNS server through a single message and response.
5.5 SNS Authentication Requirements
The SNS protocol SHALL include optional authentication of SNS protocol
messages from SNS clients. The authentication mechanism will allow for
authentication of both client and server.
5.6 SNS Query and Registration Services Requirements
The SNS protocol allows initiators and targets to register themselves
at The SNS server. Initiators and targets can also query a SNS server
for information. For example, targets can register themselves at a SNS
server, and the initiators can query a SNS server about which targets
they can access.
During registration, the initiators and the targets must
provide the following information:
a) Portal object address (IP address and Port Number)
b) WWUI information
c) Storage node type
They could optionally also provide other information such as:
a) Storage Entity ID
b) Alias string information
c) Registration for State Change Notification
If the Storage Entity ID is not provided in the initial
registration, then a SNS shall create a unique Entity ID for that
client, and the client shall use that Entity ID for all subsequent
queries and updates.
When querying address information in order to establish an
iSCSI connection, the query, as a minimum, should return the following
Page 18
draft-ietf-ips-iscsi-name-disc-00.doc
information:
a) Storage Entity IP address
The Portal Object IP address can be the same as the Storage Entity IP
address, and the Portal Object port number can be the (TBD) default
iSCSI port number. Furthermore, the WWUI of the target device can be
queried by issuing the SendTarget command to the default canonical
iSCSI target present at the IP address and port number.
5.7 State Change Notification Requirements
Asynchronous notification (State Change Notifications): A SNS must be
able to inform SNS clients of changes to its database, including
changes or modifications to Discovery Domain or login control policies
and the presence or absence of initiators and targets. These changes
may occur as a result of various events, including an SNS client
(e.g., a management workstation) actively changing the SNS database,
response or non-response to an SNS status inquiry message, or a
hardware interrupt delivered by a SNS host platform (such as a
switch). Asynchronous notification shall be delivered only to SNS
clients that register for the notification, and only for SNS clients
that are in the same Discovery Domain as the event.
5.8 The SNS protocol SHALL be a lightweight protocol that can be
scaled down for implementation on switches and targets, or scaled up
for implementation on servers.
5.9 The SNS protocol SHALL meet the iSCSI boot requirements (see
draft-ietf-ips-iscsi-boot-00.txt).
6. iSNS - Internet Storage Name Service
iSNS is a name service protocol which can be used for discovery and
management of iSCSI devices. The iSNS protocol is described in the
document draft-ietf-ips-iSNS-01.txt, and meets the requirements of
section 5 of this document. The following section describe how iSNS
is used to support iSCSI devices.
6.1 iSCSI Requirements for iSNS
iSNS MAY be used to fulfill iSCSI Naming and Discovery Requirements.
Section 5.1 of the iSNS document lists specific implementation and
usage requirements for iSCSI. Sections 5.2 and 5.3 are applicable to
non-iSCSI protocols, and do NOT have to be implemented to support
iSCSI. The remaining sections of the iSNS document provide important
background and protocol format information which are generally
applicable to an iSNS implementation that supports iSCSI. One
exception is the RqstDmnID and RlsDmnID commands, which are used to
support Fibre Channel and iFCP fabrics.
6.2 Summary of iSNS Features & Capabilities
The following are a summary of iSNS capabilities used to support
iSCSI:
6.2.1 iSNS Registration Service
iSNS allows iSCSI devices to register their identity and attributes in
the iSNS database. Multiple attributes can be registered in a single
Page 19
draft-ietf-ips-iscsi-name-disc-00.doc
message. This allows management stations to directly manage large
numbers of iSCSI devices by accessing the iSNS as a single,
consolidated information repository.
6.2.2 Discovery Domains (DD's)
iSNS organizes iSCSI devices into logical groups. This accomplishes
two primary purposes: 1) it limits the targets visible to each
initiator to the more relevant and appropriate subset of devices in
the entire storage network universe; 2) it eases administration by
partitioning storage devices into smaller, more manageable groups.
6.2.3 iSCSI Device Query Service
iSNS responds to queries from iSCSI devices requesting information
about other iSCSI devices residing in a common Discovery Domain.
Multiple attributes can be queried for in a single message.
6.2.4 State Change Notification (SCN's)
A network event, such as removal of another device from a common
Discovery Domain, will cause the iSNS to send an asynchronous
notification message of the event to iSCSI devices that have
registered for such a notification.
6.2.5 Distribution and Retrieval of Public Key Certificates
iSNS provides a convenient mechanism to distribute X.509 Public Key
certificates. These certificates can be used to set up TLS or IPSec
security associations for authenticating and/or encrypting storage
traffic, as well as for the Public Key authentication method in the
iSCSI login process. iSCSI devices can upload their own Public Key
Certificates, allowing other iSCSI devices in their Discovery Domain
to retrieve them.
6.2.6 Entity Status Inquiry (ESI)
iSNS provides a polling service to detect the removal or loss of
connectivity to iSNS clients. iSCSI devices that register for ESI
will receive an inquiry message from the iSNS server at regular time
intervals. If the iSCSI device does not respond to three consecutive
ESI messages, the iSNS server will determine that the iSCSI device is
no longer available. Appropriate SCN messages will be sent to affected
devices in the Discovery Domain.
6.2.7 Event Logging
iSNS provides an SCN Event Bitmap attribute for each iSCSI device
allowing a management client to learn the last State Change
Notification event to occur to that device. The Timestamp attribute
records the precise time of the latest SCN event.
6.2.8 Name Service Heartbeat
iSNS provides a regular local subnet broadcast that allows iSCSI
devices in the local network to passively listen for and learn the IP
address of the iSNS server.
6.2.9 Network Time Service
iSNS provides an optional network time service allowing iSCSI devices
to synchronize their time to the clock used by the iSNS.
6.3 iSCSI Attributes Supported by iSNS
The following attributes are supported by the iSNS protocol.
Attributes indicated in the "REQUIRED TO IMPLEMENT" column MUST be
supported by a server compliant with the iSNS protocol. Attributes
indicated in the "REQUIRED TO USE" column MUST have values stored for
Page 20
draft-ietf-ips-iscsi-name-disc-00.doc
an iSCSI device registered in the iSNS server.
REQUIRED REQUIRED
Object Attribute to Implement to Use
------ --------- ------------ --------
NETWORK ENTITY Entity Identifier * *
Entity Type * *
Management IP Address
ESI Interval *
Timestamp *
Entity Certificate *
SCN Event Bitmap *
ESI TCP/UDP Port * *
PORTAL IP Address * *
TCP/UDP Port * *
Portal Symbolic Name *
STORAGE NODE WWUI * *
Node Type * *
Alias/Symbolic Node Name *
Node Certificate *
DISCOVERY DOMAIN DD_ID * *
DD_Symbolic Name *
DD Member (Entity ID) *
DD_Member (WWUI) * *
DD_Member (IP Address) *
6.4 iSNS Message Summary
The following messages are used by iSNS to support iSCSI devices.
Messages listed in the "REQUIRED TO IMPLEMENT" column MUST be
supported in the iSNS server. Messages listed in the "REQUIRED TO
USE" column MUST be supported in the iSCSI device using iSNS.
REQUIRED TO:
Message Description Abbreviation Func_ID Implement Use
------------------- ------------ ------- --------- ---
Register Dev Attr Req RegDevAttr 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DeregDev 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
Register DD RegDD 0x0009 * *
Deregister DD DeregDD 0x000A * *
Register Dev in DD RegDevDD 0x000B * *
Deregister Dev in DD DeregDevDD 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E
NOT USED 0x000F
Request Network Time RqstTime 0x0010
NOT USED 0x0011-0x0012
RESERVED 0x0013-0x8000
The following are iSNSP response messages used in support of iSCSI:
REQUIRED TO:
Response Message Desc Abbreviation Func_ID Implement Use
Page 21
draft-ietf-ips-iscsi-name-disc-00.doc
--------------------- ------------ ------- --------- ---
Register Dev Attr Rsp RegDevRsp 0x8001 * *
Dev Attr Query Resp DevAttrQryRsp 0x8002 * *
Dev Get Next Resp DevGetNextRsp 0x8003 *
Deregister Dev Resp DeregDevRsp 0x8004 * *
SCN Register Resp SCNRegRsp 0x8005 *
SCN Deregister Resp SCNDeregRsp 0x8006 *
SCN Event Resp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
Register DD Resp RegDDRsp 0x8009 * *
Deregister DD Resp DeregDDRsp 0x800A * *
Register Dev in DD Resp RegDevDDRsp 0x800B * *
Deregister Dev in DD Resp DeregDevDDRsp 0x800C * *
Entity Stat Inquiry Resp ESIRsp 0x800D *
NOT USED 0x800E-0x800F
Request Net Time Resp RqstTimeRsp 0x8010
NOT USED 0x8011-0x8012
RESERVED 0x8013-0xFFFF
7) Related Work
Jini [1], and PnP [2] and are two other discovery protocols that were
evaluated as potential iSCSI discovery protocol candidates, but iSCSI
uses SLP broadcast discovery mechanism. SLP is an IETF approved
protocol which helps iSCSI to realize the broadcast discovery
functionality present in Jini and PnP.
8) Security
The iSCSI initiators and targets must have a secure way of
interacting with each other. Hence, once a target or name server is
discovered, authentication and authorization are handled by either the
iSCSI protocol, or by the name server's protocol. It is the
responsibility of the providers of these services to ensure that an
inappropriately advertised or discovered service does not compromise
their security.
8. Appendix A: iSCSI WWUI Notes
Some WWUI Examples for Targets
- Assign to a target based on controller serial number
iscsi.com.acme.diskarray.sn.8675309
See the ASCII WWUI example above for discussion.
- Assign to a target based on serial number and logical target alias
iscsi.com.acme.diskarray.sn.8675309.oracle_database_1
Where oracle_database_1 might be a target alias assigned by a user.
This would be useful for a controller that can present
different logical targets to different hosts.
Obviously, any naming authority may come up with its own
Page 22
draft-ietf-ips-iscsi-name-disc-00.doc
scheme and hierarchy for these names, and be just as valid.
A target WWUI should NEVER be assigned based on interface
hardware, or other hardware that can be swapped and moved to other
devices.
Some WWUI Examples for Initiators
- Assign to the OS image by fully qualified host name
iscsi.com.osvendor.dns.com.customer1.host_four
Note the use of two FQDNs - that of the naming
authority and also that of the host that is being
named. This can cause problems, due to limitations
imposed on the size of the WWUI.
( write in what to do about this )
- Assign to the OS image by OS install serial number
iscsi.com.osvendor.newos5.12345-OEM-0067890-23456
Note that this breaks if an install CD is used more
than once. Depending on the O/S vendor's philosophy,
this might be a feature.
- Assign to the OS image by a service provider
iscsi.com.mydisk.users.mbakke05657
Note that this could also be assigned to a particular
iSCSI address if more than one service provider is used.
Using Initiator and Target WWUI During Login
Some examples.
1. Login to a known target WWUI; initiator supports WWUI.
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
.
. text/login commands flow here during authentication phase
.
T->Login Response
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAlias= foo
2. Login to an unknown target WWUI; initiator supports WWUI.
This only works if there is a single WWUI at the IP address
and TCP port to which the initiator has connected.
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi
.
. text/login commands flow here during authentication phase
Page 23
draft-ietf-ips-iscsi-name-disc-00.doc
.
T->Login Response
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAlias= 8675309
3. Login to a canonical target, for the SendTargets command.
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi
.
. text/login commands flow here during authentication phase
.
T->Login Response
TargetWWUI= iscsi
Since the target returned a WWUI of "iscsi", the initiator will
now use the SendTargets text command to find out which target WWUIs
are actually supported at this address. It will then create
new connections for each target, and do the login scenario shown
in example 1.
[ What if this is a really simple device with no WWUI, and no
SendTargets? At this point, the initiator could just be logged
in and start doing stuff, but what's the rule it should use
to know that? Or is it silly not to have a WWUI, since even a
single disk or tape drive will have something to make one out
of? ]
Answers to Potentially Frequently Asked Questions
What happens if an Initiator WWUI is not unique?
- Targets will authenticate both as same entity
- Targets will believe that one initiator is using
them via different network interfaces.
- Initiators may end up sharing a device by
accident.
Appendix B: iSCSI Login Scenarios
B.1. Introduction
The Initiator WWUI MUST always be sent during login. As a target may
use the Initiator WWUI as part of its access control mechanism, an
initiator that does not send its WWUI stands the risk that it will be
excluded from accessing some or all of its targets.
The target WWUI MUST be sent in the login phase (with the exception
that the key-word iscsi can replace unknown target). This can enable
the distinction between several (virtual of physical) storage entities
in the device.
The WWUIs MUST be sent in the Login Request message, establishing the
login session (together with the other login parameters). The WWUIs
MUST be in text command format - UTF-8 coded as described in chapter
3.
The target MUST response to the login request with the appropriate
Page 24
draft-ietf-ips-iscsi-name-disc-00.doc
status. The status codes are defined in the iSCSI draft [7].
B.2. Request Format
The requests and responses are in key:value format. When more than one
Value is required, a comma separator is used, i.e.,
key=value1,value2,..valuen.
The key words are:
+-----------------------------------------+
| Key | Description |
+------------------+----------------------+
| InitiatorWWUI | Initiator's WWUI |
| TargetWWUI | Target's WWUI |
| TargetAlias | Target's Alias |
| InitiatorAlias | Initiator's Alias |
| TargetAddress | Target IP:Port |
+-----------------------------------------+
In the Login Request command, the initiator uses the keys and the
appropriate WWUI as values. For example:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
Here, both initiator and target WWUI are presented. Other parameters
(security, negotiation) MAY be added.
In the following example, only the initiator's WWUI is presented (the
key-word iscsi is used):
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
TargetWWUI= iscsi
Other parameters (security, negotiation) MAY be added.
B.3. Response Format
The response to the login request can be to accept the request, to
reject it or to proceed for further processing (authentication). This
status should be reflected on the response message.
B.4. Examples
B.4.1 Successful login, known target:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
If no further process is needed:
T->Login Response ("login accept 00", F set)
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAlias= foo
Or, if more authentication and/or negotiation is required:
Page 25
draft-ietf-ips-iscsi-name-disc-00.doc
T->Login Response ("challenge 20", F clear)
.
. authentication/negotiation
.
T->Login Response ("login accept", F set)
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAlias= foo
In this case, target WWUI is specified in the request. The response
Reflects the WWUIs, indicating successful login. Target Alias MAY be
presented.
B.4.2 Successful login, unknown target:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi
.
. authentication/negotiation
.
T->Login Response ("login accept", F set)
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAlias= foo
If there is a single WWUI at the IP address and TCP port to which the
initiator has connected, this will work. The target returns its WWUI
so the initiator can keep it for future use.
Note that in the case of partial response, the target WWUI is
reflected Only after the authentication process.
B.4.3 Login to a canonical target, for the SendTargets command.
The initiator MUST use the key word iscsi as target's WWUI:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi
.
. authentication/negotiation
.
T->Login Response ("login accept", F set)
TargetWWUI= iscsi
Since the target returned a WWUI of "iscsi", the initiator MAY now use
the SendTargets text command to find out which target WWUIs are
actually supported at this address. It will then create new
connections for each target, and do the login scenario shown in A.4.1.
B.4.4 Redirection
If a target has moved, or is accessible only via a proxy, the target
may respond with one of several redirection status codes, along with
one or more TargetAddress fields specifying the new location(s) of the
target.
Note that a "moving target" is not changing its identity, or WWUI. It
is only changing its address. A target returning a redirect status
SHOULD also include one or more TargetAddress fields specifying the
Page 26
draft-ietf-ips-iscsi-name-disc-00.doc
new locations of the target.
For example, if the target moved temporarily:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
.
. authentication/negotiation
.
T->Login Response ("Target moved temporarily 31", F set)
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAddress= 10.1.40.50:384
TargetAddress= storage1.mydata.com
(The same goes for the permanent move - code 32). Note that if TCP
port is not specified, the canonical port is assumed.
The login response terminates the session and the initiator SHOULD
start a new login session with the forwarded target. Further
parameters MAY be reflected on other key=value pairs.
Or, if a proxy is required for this target:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
InitiatorAlias= myhost
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
.
. authentication/negotiation
.
T->Login Response ("Proxy required 33", F set)
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAddress= 10.1.40.50:384
If more than one proxy exist, their addresses can be reflected in a
list format.
B.4.5 Login fail
In case of login failure - forbidden target, unauthorized initiator
and so on, the target terminates the session.
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
T->Login Response ("forbidden target 42", F set)
In this example, the initiator is not allowed on the required target.
The initiator SHOULD terminate the login session and MAY try
connecting to another target.
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
T->Login Response ("Target removed 44", F set)
In this case the target has been removed. In contrast with codes 31
and 32 (in B.4.4), no redirection information is supplied.
I->Login Request
Page 27
draft-ietf-ips-iscsi-name-disc-00.doc
InitiatorWWUI= iscsi.com.os.hostid.34567890
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
T->Login Response ("Target Conflict 45", F set)
Here, the target is busy with another initiator and cannot handle
another one. The initiator MAY try again later. This can be the case
of simple devices that can handle one device or the target has reached
the limit of its initiators' capacity. In contrast to the previous
examples, this rejection is temporary.
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
T->Login Response ("Target removed 44", F set)
Here, the target has been removed. The initiator SHOULD terminate the
login session. It MAY query the SNS for the new location of the
target. (This should apply for the case when the target was not found
- code 44).
In any case of the 4x and 5x class, there is no WWUI reflection on the
Login response. However, detailed messages can be carried on other
key=value pairs.
B.4.6 Proxy Login
When the initiator logs to a target via an (iSCSI) proxy, the
following procedure is applied:
The initiator connects to the proxy's port and sends a login request
of the destination target's WWUI and address:
I->Login Request
InitiatorWWUI= iscsi.com.os.hostid.34567890
TargetWWUI= iscsi.com.acme.diskarray.sn.8675309
TargetAddress= 10.1.30.75:240
Using the TargetAddress key saves the discovery process of the target.
The proxy logs into the required target with the initiator's WWUI. The
results of the login are reflected back to the initiator.
Note that a transparent (iSCSI) proxy does not have a WWUI of its own.
Appendix C: iSCSI Proxies and Firewalls Taxonomy
iSCSI has been designed to allow SCSI initiators and targets
to communicate over an arbitrary network. This, making some
assumptions about authentication and security, means that in
theory, the whole internet could be used as one giant storage
network.
However, there are many access and scaling problems that would
come up when this is attempted.
1. Most iSCSI targets are only meant to be accessed by one or
a few initiators. Discovering everything would be silly.
2. The initiator and target may be owned by separate entities,
each with their own directory services, authentication, and
other schemes. An iSCSI-aware proxy may be required to
map between these things.
Page 28
draft-ietf-ips-iscsi-name-disc-00.doc
3. Many environments use non-routable IP addresses, such as the
10. network.
For these and other reasons, various types of firewalls and proxies
will be deployed for iSCSI, similar in nature to those already
handling protocols such as HTTP and FTP.
1. Port Redirector
A port redirector is a stateless device that is not aware of iSCSI.
It is used to do Network Address Translation (NAT), which can map IP
addresses between routable and non-routable domains, as well as map
TCP ports. While devices providing these capabilities can often
filter based on IP addresses and TCP ports, they generally do not
provide meaningful security, and are used instead to resolve
internal network routing issues.
Since it is entirely possible that these devices are used as
routers and/or aggregators between a firewall and an iSCSI
initiator or target, iSCSI connections must be operable through
them.
Effects on iSCSI:
- iSCSI-level data integrity checks must not include information
from the TCP or IP headers, as these may be changed in between
the initiator and target.
- iSCSI messages that specify a particular initiator or target,
such as login requests and third party requests, should specify
the initiator or target in a location-independent manner.
This is accomplished using the WWUI.
2. SOCKS server
A SOCKS server can be used to map TCP connections from one network
domain to another. It is aware of the state of each TCP connection.
The SOCKS server provides authenticated firewall traversal for
applications that are not firewall-aware. Conceptually, SOCKS is
a "shim-layer" that exists between the application (i.e., iSCSI)
and TCP.
To use SOCKS, the iSCSI initiator must be modified to use the
encapsulation routines in the SOCKS library. The initiator
the opens up a TCP connection to the SOCKS server, typically on
the canonical SOCKS port 1080. A subnegotiation then occurs,
during which the initiator is either authenticated or denied
the connection request. If authenticated, the SOCKS server then
opens a TCP connection to the iSCSI target using addressing
information sent to it by the initiator in the SOCKS shim. The
SOCKS server then forwards iSCSI commands, data, and responses
between the iSCSI initiator and target.
Use of the SOCKS server requires special modifications to the
iSCSI initiator. No modifications are required to the iSCSI target.
As a SOCKS server can map most of the addresses and information
contained within the IP and TCP headers, including sequence numbers,
its effects on iSCSI are identical to those in the port redirector.
Page 29
draft-ietf-ips-iscsi-name-disc-00.doc
3. iSCSI Proxy
An iSCSI proxy is similar to proxies available in HTTP.
The initiator is aware of the actual addresses of the targets,
but instead of connecting to the addresses, connects instead
to a proxy's address. The proxy, in turn, connects to the
actual targets. This is similar to the HTTP/1.1 proxy, where
the client passes the entire URL (including IP and TCP address)
to the proxy, rather than just the path name.
An iSCSI proxy can provide some good iSCSI-level access
control and other functionality, while adding fairly light
configuration responsibilities.
Effects on iSCSI:
- When logging in to a target at a proxy address instead of the
actual address, the target should include the TargetAddress (IP
address and TCP port) of the target, in addition to its WWUI.
Note, however, that this directly conflicts with the statement made
regarding NAT firewalls. Since the WWUI is enough to uniquely
identify an iSCSI device, the TargetAddress must then be used by
the proxy as a hint on where to find the WWUI, and not as the final
authority.
- This is beginning to be covered in the iSCSI specification.
Having the address passed with the WWUI would allow an iSCSI
proxy to exist without extra configuration or name services.
Using this type of proxy can eliminate the need to implement SOCKS.
4. SCSI gateway
This gateway presents logical targets (WWUIs) to the initiators, and
maps them to real iSCSI targets as it chooses. The initiator sees
this gateway as a real iSCSI target, and is unaware of any proxy or
gateway behavior. The gateway may manufacture its own WWUIs, or use
those provided by the real devices. This type of gateway is used to
represent parallel SCSI, Fibre Channel, SSA, or other devices as iSCSI
devices.
Nearly any capability that could be imagined is possible with this
type of gateway, but it may require more configuration than an
iSCSI proxy.
Effects on iSCSI:
- Since the initiator is unaware of any addresses beyond the
gateway, the gateway's own address is for all practial
purposes the real address of a target. Only the WWUI needs
to be passed. This is already done in iSCSI, so there are
no further requirements to support SCSI gateways.
5. Stateful Inspection Firewall (stealth iSCSI firewall)
The Stealth model would exist as an iSCSI-aware firewall, that
is invisible to the initiator, but provides capabilities found
in the iSCSI proxy.
Effects on iSCSI:
- Since this is invisible, I don't think there are any
Page 30
draft-ietf-ips-iscsi-name-disc-00.doc
additional requirements on the iSCSI protocol for this
one.
This one is more difficult in some ways to implement, simply
because it has to be part of a standard firewall product,
rather than part of an iSCSI-type product. For this reason,
I would not expect to see these implemented for a while.
Also note that this type of firewall is only effective
in the outbound direction (allowing an initiator behind the
firewall to connect to an outside target), unless the iSCSI target
is located in a DMZ. It does not provide adequate security otherwise.
8. References
[1] Edwards, K., "Core Jini: In Depth: Discovery", Prentice Hall,
1999.
[2] John, R., "UPnP, Jini and Salutation- A look at some popular
coordination frameworks for future networked devices",
http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999.
[3] http://www.srvloc.org
[4] Freed, N., "Behavior of and Requirements for Internet Firewalls",
RFC 2979, October 2000.
[5] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and
Metropolitan Area Networks: Overview and Architecture
[6] Kessler, G. and Shepard, S., "A Primer On Internet and TCP/IP
Tools
and Utilities", RFC 2151, June 1997.
[7] Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P.,
Haagens, R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI",
draft-ietf-ips-iscsi-00.txt, February, 2000.
[8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage Name
Service", draft-tseng-ips-isns-00.txt, October 2000.
[9] RFC 1737, "Functional Requirements for Uniform Resource Names".
[10] RFC 1035, "Domain Names - Implementation and Specification".
OUI - "IEEE OUI and Company_Id Assignments",
http://standards.ieee.org/regauth/oui/index.shtml
[11]EUI - "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
[12] RFC 2396, "Uniform Resource Identifiers".
[13] RFC 2276, "Architectural Principles of URN Resolution".
[14] RFC 2483, "URI Resolution Services".
Page 31
draft-ietf-ips-iscsi-name-disc-00.doc
[15] RFC 2141, "URN Syntax".
[16] RFC 2611, "URN Namespace Definition Mechanisms".
.
[17] RFC 2608, SLP Version 2.
[18] RFC 2610, DHCP Options for the Service Location Protocol.
[19] P. Sarkar et al, "A Standard for Bootstrapping Clients using the
iSCSI Protocol", draft-ietf-ips-iscsi-boot-01.
[20] M. Bakke et al, "A URN Namespace for iSCSI World-Wide Unique
Identifiers", draft-bakke-iscsi-wwui-urn-00 February 2001.
[21] M. Bakke et al,öFinding iSCSI Targets and Name Servers using
SLPö, draft-bakke-iscsi-SLP-template.00.
6. Contact Author
Kaladhar Voruganti
650 Harry Road
IBM Almaden Research
San Jose, CA
USA
Email: kaladhar@us.ibm.com
Voruganti Internet Draft Expires August 2001
iSCSI Naming and Discovery February 2001
"Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed,in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, Full Copyright
Statement such as by removing the copyright notice or references to
the Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"As IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED , INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE"
Page 32
draft-ietf-ips-iscsi-name-disc-00.doc
Expires August 2001
Voruganti iSCSI Naming and Discovery Draft Expires August 2001
.
| PAFTECH AB 2003-2026 | 2026-04-20 06:12:03 |