rfc3721.txt

一个学习iSCSI协议的文档

      "a8675309" is the serial number of the disk array, uniquely
      identifying it from all other arrays.

      Another example shows how the ':' separator helps owners of sub-
      domains to keep their name spaces unique:

                  Naming            Defined by
   Type  Date     Authority         Naming Authority
   +--++-----+ +-----------------+ +-----------+
   |  ||     | |                 | |           |

   iqn.2001-04.com.example.storage:tape.sys1.xyz

                  Naming                Defined by
   Type  Date     Authority             Naming Authority
   +--++-----+ +----------------------+ +-----------+
   |  ||     | |                      | |           |

   iqn.2001-04.com.example.storage.tape:sys1.xyz







Bakke, et al.                Informational                      [Page 6]

RFC 3721               iSCSI Naming and Discovery             April 2004


   Note that, except for the ':' separator, both names are identical.
   The first was assigned by the owner of the subdomain
   "storage.example.com"; the second was assigned by the owner of
   "tape.storage.example.com".  These are both legal names, and are
   unique.

   The following is an example of a name that might be constructed by a
   research organization:

                Naming        Defined by  Defined by
   Type  Date    Authority      cs dept    User "oaks"
    +-+ +-----+ +------------+ +--------+ +-----------+
    | | |     | |            | |        | |           |
    iqn.2000-02.edu.example.cs:users.oaks:proto.target4

   In the above example, Professor Oaks of Example University is
   building research prototypes of iSCSI targets.  EU's computer science
   department allows each user to use his or her user name as a naming
   authority for this type of work, by attaching "users.<username>"
   after the ':', and another ':', followed by a string of the user's
   choosing (the user is responsible for making this part unique).
   Professor Oaks chose to use "proto.target4" for this particular
   target.

   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

   In this case, a storage service provider (ssp.example.com) has
   decided to re-name the targets from the manufacturer, to provide the
   flexibility to move the customer's data to a different storage
   subsystem should the need arise.

   The Storage Service Provider (SSP) has configured the iSCSI Name on
   this particular target for one of its customers, and has determined
   that it made the most sense to track these targets by their Customer
   ID number and a disk number.  This target was created for use by
   customer #4567, and is the 107th target configured for this customer.

   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



Bakke, et al.                Informational                      [Page 7]

RFC 3721               iSCSI Naming and Discovery             April 2004


   two-letter country codes.  The use of anything else as the first
   component of these names is not allowed.  In particular, companies
   generating these names must not eliminate their "com." from the
   string.

   Again, these iSCSI names are NOT addresses.  Even though they make
   use of DNS domain names, they are used only to specify the naming
   authority.  An iSCSI name contains no implications of the iSCSI
   target or initiator's location.  The use of the domain name is only a
   method of re-using an already ubiquitous name space.

1.2.  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

2.  iSCSI Alias

   The iSCSI alias 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 requirements of the iSCSI
   name.  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, as defined
   in [RFC3720].  No other structure is imposed upon this string.

2.1.  Purpose of an Alias

   Initiators and targets are uniquely identified by an iSCSI Name.
   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 to be
   assigned from a point of view different from that of the other side



Bakke, et al.                Informational                      [Page 8]

RFC 3721               iSCSI Naming and Discovery             April 2004


   of the connection.  For instance, a target name 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 name, 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.

   Both targets and initiators may have aliases.

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 Target Name for the new target, and probably an
   address, back to the user.  The user then adds this Target Name 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 management "show targets" button to show the targets to which
   the host is currently connected.

   +--Connected-To-These-Targets----------------------
   |
   |  Target Name
   |
   |  iqn.1995-04.com.example:sn.5551212.target.450
   |  iqn.1995-04.com.example:sn.5551212.target.489
   |  iqn.1995-04.com.example:sn.8675309
   |  iqn.2001-04.com.example.storage:tape.sys1.xyz
   |  iqn.2001-04.com.example.storage.tape:sys1.xyz
   |
   +--------------------------------------------------






Bakke, et al.                Informational                      [Page 9]

RFC 3721               iSCSI Naming and Discovery             April 2004


   In the above example, the user sees a collection of iSCSI Names, 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 storage administrator configures an alias for each target name,
   the alias can provide a more descriptive name.  This alias may be
   sent back to the initiator as part of the login response, or found in
   the iSCSI MIB.  It then might be used in a display such as the
   following:

   +--Connected-To-These-Targets----------------------
   |
   |  Alias          Target Name
   |
   |  Oracle 1       iqn.1995-04.com.example:sn.5551212.target.450
   |  Local Disk     iqn.1995-04.com.example:sn.5551212.target.489
   |  Exchange 2     iqn.1995-04.com.example: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 if seen in the login
   response.

2.3.  Initiator Alias

   An initiator alias can be used in the same manner as a target alias.
   An initiator may send the alias in a login request, when it sends its
   iSCSI Initiator Name.  The alias is not used for authentication, but
   may be kept with the session information for display through a
   management Graphical User Interface (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.




Bakke, et al.                Informational                     [Page 10]

RFC 3721               iSCSI Naming and Discovery             April 2004


   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 Web
   Server".

   Here's an example of a management interface showing a list of
   sessions on an iSCSI target network entity.  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 Name
   |
   |  450      iqn.1995-04.com.example.sw:cd.12345678-OEM-456
   |  451      iqn.1995-04.com.example.os:hostid.A598B45C
   |  309      iqn.1995-04.com.example.sw:cd.87654321-OEM-259
   |
   +--------------------------------------------------

   And with the initiator alias displayed:

   +--Connected-To-These-Initiators-------------------
   |
   |  Target Alias               Initiator Name
   |
   |  450    Web Server 4        iqn.1995-04.com.example.sw:cd.12...
   |  451    scsigw.example.com  iqn.1995-04.com.example.os:hosti...
   |  309    Exchange Server     iqn.1995-04.com.example.sw:cd.87...
   |
   +--------------------------------------------------

   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 and require a
   management application.

   Aliases are extremely easy to implement.  Targets just send a
   TargetAlias whenever they send a TargetName.  Initiators just send an
   InitiatorAlias whenever they send an InitiatorName.  If an alias is
   received that does not fit, or seems invalid in any way, it is
   ignored.



Bakke, et al.                Informational                     [Page 11]