[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3721

     IPS
    Internet Draft
   draft-ietf-ips-iscsi-name-disc-05.txt
   Draft Title: iSCSI Naming and Discovery
                                                                              Mark Bakke
                                                                                         Cisco
   
                                                                                Jim Hafner
                                                                           John Hufferd
                                                                Kaladhar Voruganti
                                                                                          IBM
   
                                                                    Marjorie Krueger
                                                                     Hewlett-Packard
   
                                                                        Joshua Tseng
                                                                    Nishan Systems
   
   
                                    iSCSI Naming and Discovery
   
             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
   
             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
   
   
             Abstract
   
   
             This document describes iSCSI [7] naming and discovery details. This
             document complements the iSCSI Protocol draft. Flexibility is the key
   
   
          Internet Draft         Naming and Discovery                2
   
   
   
   
             guiding principle behind this 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 solutions.
   
   
             Acknowledgements
             Joe Czap (IBM), Howard Hall (Pirus), Jack Harwood (EMC),
             Yaron Klein (SANRAD), Larry Lamers (SAN Valley Systems),
             and Todd Sperry (Adaptec) have participated and made
             contributions during the weekly Naming and Discovery
             teleconferences.
   
             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.
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                3
   
   
   
   
             Table of Contents
   
             1. iSCSI Naming Philosophy..........................................................3
             2. iSCSI Names.................................................................................4
             3. iSCSI ISID...................................................................................17
             4. iSCSI Discovery.........................................................................20
             5. Appendix A: iSCSI Naming Notes..........................................22
             6. Appendix B: Proxy Description...............................................23
             7. Appendix C: iSCSI Names and Security Identifiers..............26
             8. References..................................................................................27
             9. Author's Addresses.................................................................29
   
          1. iSCSI Naming Philosophy
             The notion of an iSCSI name is required at both the targets and at
             the initiators. iSCSI name is required at the target because it
             uniquely identifies a target as a storage resource for the initiators.
             iSCSI initiator name is required at the initiator because it helps to
             uniquely identify an initiator for the purpose of target resource
             allocation (i.e., which initiator has access to which target
             resource). iSCSI name is also used to provide a mechanism for world
             wide unique identification of SCSI Initiator Ports (analogous to FC
             WWPortnames). The SCSI port name is used by SCSI during SCSI
             reservations, SCSI initiator specific task queue management and
             SCSI mode page management. Furthermore, iSCSI initiator names can be
             also potentially used by software layers such as security and
              management software to uniquely identify initiators to targets.
   
   
             It is necessary for the iSCSI names to be unique within the operation
             domain of the end user. However, since user operation domains can
             potentially merge with other user operation domains, the iSCSI naming
             mechanism has been architected to ensure world wide uniqueness. In
             order to ensure both world wide name uniqueness iSCSI provides for
             the use of different types of naming authority mechanisms.
   
             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 carrying over the SCSI state information
             (reservations, mode page settings etc).
   
             Since there can be multiple separate iSCSI sessions (via different
             iSCSI ports) between the same iSCSI initiator and target nodes,
             iSCSI has introduced the notion of an initiator session id (ISID)
             and a target session id (TSID) to help in uniquely identifying each
             of the iSCSI sessions. The ISID and the TSID are not global identifiers
             but together uniquely identify a session only within the context of a
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                4
   
   
   
   
             given named iSCSI initiator and iSCSI target.
   
             In addition to the mandatory iSCSI concepts of iSCSI initiator name,
             iSCSI target name, ISID and TSID, iSCSI also optionally allows for
             the specification of initiator and target aliases. Initiator and
             target aliases are optional constructs which help the users to
             associate semantic meanings with a particular initiator or target.
   
   
   
          2. iSCSI Names
   
                The main addressable, discoverable entity in iSCSI is an iSCSI
                Node.  An iSCSI node can be either an initiator, a target, or
                both.
   
                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.  The terms "initiator
                    name" and "target name" also refer to an iSCSI name.
   
                 -  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, particularly
                    if they are assigned via DHCP.
   
                A similar analogy exists for people.  A person in the USA might be:
   
                    Robert Smith
                    SSN: 333-44-5555
                    Phone: +1 (763) 555.1212
                    Home Address: 555 Big Road, Minneapolis, MN 55444
   
                    Work Address: 222 Freeway Blvd, St. Paul, MN 55333
   
                In this case, Robert's globally unique name is really his Social
                Security Number his common name, "Robert Smith", is not guaranteed
                to be unique. Robert has three locations at which he may be reached;
                two Physical addresses, and a phone number.  In this example,
                Robert's SSN is like the iSCSI Name, his phone number and addresses
                are analogous to the iSCSI Address, and "Robert Smith" would be a
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                5
   
   
   
   
                human-friendly label for this person.
   
             2.1. iSCSI Name Requirements
   
                Each iSCSI node, whether an initiator or target, must have an
                iSCSI name.
   
                iSCSI names may be assigned by a hardware manufacturer, software
                manufacturer, or the end user.  A naming authority scheme is
                provided to ensure that each of these can confidently generate
                unique names.
   
                iSCSI names are designed to fulfill the following requirements:
   
                 1. iSCSI names are globally unique.  No two initiators or targets
                    should have the same name.
   
                 2. iSCSI names are permanent.  An iSCSI initiator or target has the
                    same name for its lifetime.
   
                 3. iSCSI names do not imply a location or address.  An iSCSI
                    initiator or target can move, or have multiple addresses.  A
                    change of address does not cause a change of name.
   
                 4. iSCSI names must not rely on a central name broker; the naming
                    authority must be distributed.
   
                 5. iSCSI names must support integration with existing unique naming
                    schemes.
   
                 6. iSCSI names must rely on existing naming authorities.  iSCSI
                    must not create its own naming authority.
   
                The encoding of an iSCSI name also has some requirements:
   
                 1. iSCSI names have one single encoding method when transmitted
                    over various protocols.
   
                 2. iSCSI names must be relatively simple to compare.  The algorithm
                    for comparing two iSCSI names for equivalence must not rely on
                    any external server.
   
                 3. iSCSI names must be transcribable by humans.  iSCSI names should
                    be kept as simple as possible, and should not use more than a
                    few special characters.  They must provide for the use of
                    international character sets, and must not allow the use of
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                6
   
   
   
   
                    different names that would be identical except for their case.
                     Whitespace characters must not be allowed.
   
                 4. iSCSI names must be transport-friendly.  They must be
                    transported using both binary and ASCII-based protocols, as well
                    as on paper.
   
                An iSCSI Name really names a logical software entity, and is not
                tied to a port or other hardware that can be changed.  For instance,
                an initiator name should name the iSCSI initiator node, and not a
                particular NIC or HBA card.  When multiple NICs are used, they
                should generally all present the same iSCSI initiator name 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 name should similarly not be tied to hardware interfaces
                which can be changed.  A target name should identify the logical
                target, and must be the same for the target regardless of the
                physical portion being 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 Name is designed to fulfill the functional requirements
                for Uniform Resource Names (URN) [RFC1737].  Among these
                requirements are that the name 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 name 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.
   
   
   
          2.2. iSCSI Name Encoding
   
           An iSCSI name is a UTF-8 encoding of a string of Unicode
          characters,  with the following properties, described in [26]:
   
              - it is in Normalization Form C [25]
   
              - it contains only the following types of characters:
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                7
   
   
   
   
                   - ASCII dash character ('-'=U+002d)
                   - ASCII dot character ('.'=U+002e)
                   - Any character allowed by the output of the iSCSI
                     stringprep template [26]
   
              - when encoded in UTF-8, it is no more than 255 bytes
   
           The stringprep process is described in [24]; iSCSI's use of the
           stringprep process is described in [26].  Stringprep is a
          method designed by the Internationalized Domain Name (IDN) working
          group to translate human-typed strings into a format that can  be
          compared as opaque strings, and does not include punctuation,
          spacing, dicritical marks, or other characters that could get
          in the way of transcribability. It also converts everything into its
          equivalent of lower case.
   
          Note that in most cases, the stringprep process does not need
          to be implemented:
   
             - If the names are just generated using lower-case (in any
               character set) plus digits, no normalization is required.
   
             - If the names are generated from some other all-ASCII
               string,  tolower() normalizes and isalnum() verifies.
   
             - If the names are generated from more general,
               internationalized  text, either the equivalent of tolower()
              and isalnum()  appropriate
               to the character set may be used, or the full stringprep
              procedure can be used.
   
             When included in Text or Login messages, an iSCSI Name MUST
              be  formatted in UTF-8 form.
   
             Since iSCSI names encoded in UTF-8 are "normalized" (there is
             one and only one representation for each possible name), they
             may be safely compared byte-for-byte.
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                8
   
   
   
   
           The iSCSI Name may be displayed by user interfaces, but its
          contents are not parsed or interpreted by initiators and targets
          themselves.
   
   
   
   
   
             2.3. iSCSI Name Structure
   
                An iSCSI name consists of Two parts: a type designator, followed by
                a unique name string
   
   
                The iSCSI Name does not define any new naming authorities.  Instead,
                it supports two existing authorities: an iSCSI-Qualified Name, using
                domain names as an authority, similar to the Java class naming
                hierarchy, and the EUI format used in Fibre Channel world-wide
                names.
   
                Since there are different types of naming authorities, there are
                different types of iSCSI Names to make use of them.  Each name 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:
   
   
                         iqn.       - iSCSI Qualified Name
                         eui.       - Remainder of the string is an EUI-64 address,
                                      in ASCII hexadecimal.
   
                As these two naming authorities will suffice in nearly every case
                for both software and hardware-based entities, the creation of
                additional type designators is discouraged.  One of these two type
                strings MUST be used when constructing an iSCSI name; any type
                string not listed here is not allowed, as they cannot be guaranteed
                to be unique.
   
             2.3.1.  Type "iqn." (iSCSI Qualified Name)
   
                This iSCSI name type can be used by any organization which owns a
                Domain Name.  This naming format is handy when an end user or
                service provider wishes to assign the iSCSI Name for a target or
                initiator.  Customers which own domain names may not own an EUI,
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                9
   
   
   
   
                OUI, SCSI Vendor ID, or any of the other assigned identifiers that
                could be used as a naming authority.
   
                To generate names of this type, the person or organization
                generating the name must own a DNS domain name.  This name does not
                have to be active, and does not have to resolve to an address; it
                just needs to be reserved to prevent others from generating iSCSI
                names using the same domain name.  For example, "ACME Storage
                Arrays, Inc.", might own the domain "acme.com".
   
                Since a domain name can expire, be acquired by another entity, and
                used to generate iSCSI names by both owners, the domain name must
                be additionally qualified by a date during which the naming authority
                owned the domain name.  A date code is provided as part of the IQN
                format for this reason.
   
                The iSCSI qualified name string consists of:
   
                -  The string "iqn.", used to distinguish these names from other
                   types, such as "eui".
   
                -  A date code, in yyyy-mm format.  This date code uses the Gregorian
                   calendar.  All four digits in the year must be present.  Both
                   digits of the month must be present, with January == "01" and
                   December == "12".  The dash must be present.  The date
                   reflected in this code MUST be a date during which the naming
                   authority owned the domain name used in this format, and SHOULD be
                   the date on which the domain name was acquired by the naming
                   authority.
   
                 -  Another ".".
   
                 -  A reversed domain name, owned by the person or organization
                    creating the iSCSI name.  For example, our storage vendor
                    example would reverse its name to "com.acme".
   
                 -  Another ".".
   
                 -  Any string, within the character set and length boundaries, that
                    the owner of "acme.com" deems appropriate.  This may contain
                    product types, serial numbers, host identifiers, software keys,
                    or anything else that makes sense to uniquely identify the
                    initiator or target.
   
                Everything after the backwards domain name, followed by another dot
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                10
   
   
   
   
               ".", can be assigned as needed by the owner of the domain name.  It is
               the responsibility of the Organizational (Company) naming authority to
               ensure that the iSCSI names it assigns are world wide unique.
   
               iSCSI has given the Organizational naming authority additional
               flexibility by permitting it to hand out local naming authority to
               subordinate organizations.  In this way it will be possible for the
               Organizational naming authority to assign for example, the string
               "storage", to one subgroup naming authority and "storage.tape" to
               another.  In this case the subgroups may add a ":" following their
               assigned subgroup string to ensure ongoing uniqueness. For example:
               "storage:" and "storage.tape:".  Also, additional sub-qualifiers can be
               assigned and separated by a "." as explained above.
   
               Using this approach, the subgroup with the sub-naming authority string
               of "storage" might, overtime, also create some Tape products.  In this
               case, both subgroups might use the same qualifying names.  It would be
               expected in this case that a naming conflict might occur, however by
               using the ":" appropriately the conflicts can be avoided.  In this
               example com.acme.storage:tape.sys1.xyz  and
               com.acme.storage.tape:sys1.xyz would not be in conflict even though the
               same sub-names are used.
   
               The following are examples of iSCSI qualified names from an
                equipment vendor:
   
                                 Organization    Subgroup Naming Authority
                                     Naming      and/or string Defined by
                       Type  Date     Auth       Org. or Local Naming Authority
                        +-+ +-----+ +------+ +--------------------------------+
                        | | |     | |      | |                                |
   
                        iqn.2001-04.com.acme.diskarrays-sn-a8675309
                        iqn.2001-04.com.acme.storage:tape.sys1.xyz
                        iqn.2001-04.com.acme.storage.tape:sys1.xyz
   
                Where:
   
                     "iqn" specifies the use of the iSCSI qualified name as the
                      authority.
   
                      "2001-04" is the year and month on which the naming authority
                      acquired the domain name used in this iSCSI name.
   
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                11
   
   
   
   
                    "com.acme" defines the Organizational naming authority.  The
                    owner of the DNS name "acme.com" has the sole right of use of
                    this name within an iSCSI name, as well as the responsibility to
                    keep the remainder of the iSCSI name unique.  In this case,
                    acme.com happens to manufacture disk arrays.
   
                      "diskarrays" was picked arbitrarily by acme.com to identify
                      the disk arrays they manufacture.  Another product
                      that ACME makes might use a different name, and have it's
                      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 iSCSI Names 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.
   
                    "storage:" is the string that represents another sub-naming
                    authority.
   
                    "storage.tape:" is still another sub-naming authority.
   
                    "sys1.xyz" is a naming sub-qualifier.
   
                The following is an example of a name that might be constructed by
                an research organization:
   
                                     Organization               String
                                       Naming                  Defined by Org.
                       Type  Date     Authority               Naming Authority
                        +-+ +-----+ +----------------------+ +-----------+
                        | | |     | |                      | |           |
                        iqn.2000-02.edu.pika-u.cs.users.oaks.proto.target4
   
   
                In the above example, Professor Oaks of Pika University is building
                research prototypes of iSCSI targets.  Pika-U's computer science
                department allows each user to use his or her user name as a naming
                authority for this type of work.  Professor Oaks chose to use
                "proto.target4" for a particular target.
   
                The following is an example of an iSCSI name string from a storage
                service provider:
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                12
   
   
   
   
   
                                    Organization       String
                                       Naming       Defined by Org.
                       Type  Date    Authority     Naming Authority
                        +-+ +-----+ +--------+ +----------------------+
                        | | |     | |        | |                      |
                        iqn.1995-11.com.my-ssp.customers.4567.disks.107
   
                In this case, a storage service provider (my-ssp.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.
   
                My-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 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.
   
                Note that the SCSI Vendor ID or IEEE OUI could have been specified
                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 was deemed more appropriate.
   
   
             2.3.2.  Type "eui." (IEEE EUI format)
   
                The IEEE iSCSI name might be used when a manufacturer is already
                basing unique identifiers on World-Wide Names as defined in the SCSI
                SPC-2 specification.
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                13
   
   
   
   
   
                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 iSCSI name :
   
                      Type    EUI-64 WWN
                       +-+ +--------------+
                       | | |              |
                       eui.02004567A425678D
   
   
   
             2.4 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.  No
                other structure is imposed upon this string.
   
             2.4.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 be be assigned from a point of view
                different from that of the other side 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
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                14
   
   
   
   
                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.4.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.acme.sn.5551212.target.450
                |  iqn.1995-04.com.acme.sn.5551212.target.489
                |  iqn.1995-04.com.acme.sn.8675309
                |  iqn.2001-04.com.acme.storage:tape.sys1.xyz
                |  iqn.2001-04.com.acme.storage.tape:sys1.xyz
                |
                +--------------------------------------------------
   
                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,
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                15
   
   
   
   
                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 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 this.  The new display might
               look like:
   
                +--Connected-To-These-Targets----------------------
                |
                |  Alias          Target Name
                |
                |  Oracle 1       iqn.1995-04.com.acme.sn.5551212.target.450
                |  Local Disk     iqn.1995-04.com.acme.sn.5551212.target.489
                |  Exchange 2     iqn.1995-04.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 if seen in the login
               response.
   
             2.4.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 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
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                16
   
   
   
   
                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 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.sw.cd.12345678-OEM-456
                |  451      iqn.1995-04.com.os.hostid.A598B45C
                |  309      iqn.1995-04.com.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.sw.cd.12345678-OEM-456
                |  451    scsigate.yours.com   iqn.1995-04.com.os.hostid.A598B45C
                |  309    Exchange Server      iqn.1995-04.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 and require a
               management application.
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                17
   
   
   
   
                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.
   
   
             2.5. Initiator and Target Requirements for iSCSI Name support:
   
                Each initiator and target implementation must support the use of
                iSCSI names.
   
               The initiator MUST send an InitiatorName and a TargetName as text
               fields within the initial login request on all connections within the
               session.
   
                Initiators and targets shall support the receipt of iSCSI names of
                up to the maximum length.  If configuration of the initiator or
                target name 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 iSCSI Name's UTF-8
                string.
   
                If the other characters are unsupported, they may be displayed with
                escape codes as specified in [RFC 2396].
   
   
   
          3. ISID
          The ISID is an initiator-defined component of the session identifier
          (SSID) and is structured as follows. See iSCSI [7] and Section 3.4
          Conservative Reuse of ISIDs for further information regarding the
          ISID.
   
          Byte/    0        |        1      |      2        |      3        |
             /              |               |               |               |
            |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
            +---------------+---------------+---------------+---------------+
           0| T |    A      |               B               |       C       |
            +---------------+---------------+---------------+---------------+
           4|               D               |
            +---------------+---------------+
   
          The T field identifies the format and usage of A, B, C & D
          as indicated below:
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                18
   
   
   
   
   
          T
   
          00b        OUI-format
                     A&B are 22 bits. OUI is the Naming Authority
                     (the I/G & U/L bits are omitted)
                     C&D are 24 bit Qualifier
          01b        EN - format (IANA Enterprise Number)
                     A - reserved
                     B&C EN (IANA Enterprise Number) is the Naming Authority
                     D - Qualifier
          10b        "Random"
                     A - reserved
                     B&C Random is the Naming Authority
                     D - Qualifier
          11b        A,B,C&D Reserved
   
          For T field values 00b and 01b, a combination of A and B (for 00b)
          or B and C (for 01b) identifies the vendor or organization whose
          component (software or hardware) generates this ISID. This is the
          Naming Authority field. See 3.2 for more information. A vendor or
          organization with one or more OUIs, or one or more Enterprise Numbers,
          must use at least one of these numbers and select the appropriate
          value for the T field when its components generate
          ISIDs. An OUI or EN value must be set in the corresponding fields
          in network byte order (i.e., big-endian).
   
          If the T field is 10b, B and C are set to a random 24 bit unsigned
          integer value in network byte order (i.e., big-endian). See iSCSI[7]
          and section 3.4) for how this affects the principle of "conservative
          reuse".
   
          The "Random" type (10b) is for the case where the component that
          generates an ISID (SW or HW) is provided by an entity that has no OUI
          or EN.  This includes, for example,
          - a user-written program that builds sessions (and has access to the
          system level iSCSI Name)
          - a university or other organization providing the component
          - a testing tool
   
   
          The T field of 11b is reserved.
   
          3.2 ISID Naming Authority
   
          If the Type field is 00b, the 22-bits of the Naming Authority field
          must be the lower 22-bits of one of the IEEE OUI (Organization Unique
          Identifier) a.k.a. "Company ID" assigned to the vendor whose component
          is generating this ISID. The OUI is set in the Naming Authority field
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                19
   
   
   
   
          in network byte order (big-endian).
   
          If the Type field is 01b, the Naming Authority field must be set to
          one of the IANA Enterprise Numbers assigned to the vendor whose
          component is generating this ISID.  The Enterprise Number is set in
          the Naming Authority field as a 24bit unsigned integer value in
          network byte order (big-endian).
   
          If the type field is 10b, the Naming Authority field is set randomly
          as specified above. It is important to note that the "Random" type
          does not guarantee uniqueness. The "Random" type has been introduced
          because it allows ISIDs to be used in experimental or isolated iSCSI
          setups. (See 3.4 on how this affects the principle of "conservative
          reuse").
   
          3.3 ISID Qualifier
   
          The Qualifier field is a 16 or 24 bit unsigned integer value that
          provides a range of possible values for the ISID within the selected
          namespace. It may be set to any value, within the constraints
          specified in the iSCSI protocol (see iSCSI [7]  and 3.4 for
          Consequences of the Model and Conservative Reuse of ISIDs).
   
          3.4 Conservative reuse of ISIDs
   
          The principle of "conservative reuse" of ISIDs (see iSCSI [7])
          specifies that ISIDs should be reused as much as possible.  This
          principle is there to both minimize the disruption of legacy
          applications and to better facilitate the SCSI features that rely
          on persistent names for SCSI ports.
   
          To facilitate conservative reuse, the Qualifier field of a set of
          ISIDs should be generated using either a repeatable algorithm (e.g,
          deterministic or pseudo-random but based on a fixed seed) or any
          algorithm to initialize a value or set of values but stored in a
          persistent location (e.g., registry or /etc file).
   
          For the "Random" type, conservative reuse may not be an issue
          (e.g., in a user application that doesn't care about reservations,
          etc.).  When it is an issue, the Naming Authority field should also
          be generated by a mechanism similar to that for the Qualifier field
          as specified above (e.g., defined in the SW at compilation time.)
   
   
          3.5 Notes on ISIDs
   
          (a) As noted, the structure of the ISID namespace provides each
          vendor with its own piece of the ISID namespace.  In effect, this
          provides for a vendor-partitioning of that namespace within each
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                20
   
   
   
   
          initiator.  An initiator will then fail to comply with the ISID
          RULE only if a vendor fails to implement the ISID generation use
          and reuse requirements correctly.
   
          (b) This structure also allows for a consortium of companies to
           develop common APIs or a common infrastructure for generation, use
           and reuse of ISIDs.  The consortium could, for example, select an
           OUI from amongst the member companies to be used in the Naming
           Authority field.  Or, the consortium could request an IANA
           Enterprise Number for the consortium itself and use this in the
           naming authority field.  Eventually, the OS implementers could
           provide such APIs, in which case the OS vendor could use its own
           OUI or EN in the naming authority.  In short, the design allows for
           a migration path from vendor-fragmented implementations to
          coordinated common implementations for ISID generation.
   
          (c) ISIDs have no global uniqueness requirements or properties.
          That is handled by the iSCSI Name of the initiator.  This means
          that a vendor can use the same algorithm to generate ISIDs (under
          its naming authority) in every initiator.
   
          (d) If the ISID is derived from something assigned to a hardware
          adapter or interface by a vendor as a preset default value, it must
          have a way to be changed (configured) to a new default value. The
          ISID value must be configurable so that a chosen ISID may be applied
          to a Portal Group containing more than one interface. In addition,
          any preset default value should be automatically adjusted to a common
          ISID when placed into a Network Entity as part of a Portal Group.
          Any configured ISID must also be persistent (e.g., across power
          cycles, reboots, and hot swaps). Refer to iSCSI [7] iSCSI Name and
          ISID/TSID.
   
   
   
   
   
          4. 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.  This section defines the
                discovery mechanism only; no attempt is made to specify central
                management of iSCSI devices within this document.  Moreover, iSCSI
                discovery mechanism only deals 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
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                21
   
   
   
   
                an iSCSI  target, the initiator needs the IP address, TCP port
                number and iSCSI  target name information. The goal of iSCSI
                discovery mechanism is to provide low overhead support for small
                iSCSI setups, and scalable discovery solutions for large enterprise
                setups. Thus, there are several methods that may be used to find
                targets 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
                dynamically. The various discovery mechanisms differ in their
                assumptions about what information is already available to the
                initiators and what information needs to be still discovered.
   
                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 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.  The initiator then subsequently issues the
                SendTargets text command to query information about the iSCSI
                targets available at the particular Network Entity (IP address).
                SendTargets command details can be found in the iSCSI draft [7].
                This discovery option is convenient for iSCSI gateways and routers.
   
              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, there are many general purpose discovery frameworks
              available such as Salutation[2], Jini[2],UPnP[2], SLP[17] and iSNS[8].
              However, with respect to iSCSI, SLP can clearly perform the needed
              discovery functions [21], while iSNS [8] can be used to provide related
              management functions including notification, access management,
              configuration, and discovery management.  iSCSI equipment that
              need discovery functions beyond SendTargets should at least implement
              SLP, and then consider iSNS when extended discovery management
              capabilities are required such as in larger storage networks.
              It should be noted that since iSNS will support SLP, iSNS can
              be used to help manage the discovery information returned by SLP.
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                22
   
   
   
   
   
   
   
   
   
   
          Appendix A: iSCSI Name Notes
   
                Some iSCSI Name Examples for Targets
   
                - Assign to a target based on controller serial number
   
                  iqn.2001-04.com.acme.diskarray.sn.8675309
   
                - Assign to a target based on serial number
   
                  iqn.2001-04.com.acme.diskarray.sn.8675309.oracle_database_1
   
                Where oracle_database_1 might be a target label 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 scheme and
                hierarchy for these names, and be just as valid.
   
                A target iSCSI Name should never be assigned based on interface
                hardware, or other hardware that can be swapped and moved to other
                devices.
   
                Some iSCSI Name Examples for Initiators
   
                - Assign to the OS image by fully qualified host name
   
                  iqn.2001-04.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 iSCSI Name.
   
                - Assign to the OS image by OS install serial number
   
                  iqn.2001-04.com.osvendor.newos5.12345-OEM-0067890-23456
   
                Note that this breaks if an install CD is used more than once.
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                23
   
   
   
   
                Depending on the O/S vendor's philosophy, this might be a feature.
   
   
                - Assign to the Raid Array by a service provider
   
                  iqn.2001-04.com.mydisk.users.mbakke05657
   
   
   
   
             Appendix B: 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 may only meant to be accessed by one or a few
                initiators.  Discovering everything would be unnecessary.
   
                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.
   
                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.
   
                B.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
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                24
   
   
   
   
                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 iSCSI Name.
   
                B.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 sub-negotiation 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.
   
                B.3. SCSI gateway
   
                This gateway presents logical targets (iSCSI Names) 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
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                25
   
   
   
   
                any proxy or gateway behavior.  The gateway may manufacture its own
                iSCSI Names, 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.
   
                Effects on iSCSI:
   
                - Since the initiator is unaware of any addresses beyond the gateway,
                  the gateway's own address is for all practical purposes the real
                  address of a target.  Only the iSCSI Name needs to be passed.  This
                  is already done in iSCSI, so there are no further requirements to
                  support SCSI gateways.
   
                B.4. iSCSI Proxy
   
                An iSCSI proxy is a SCSI gateway that happens to be terminating
                the iSCSI protocol on both sides, rather than translate between
                iSCSI and some other transport.  Since an iSCSI initiator's
                discovery or configuration of a set of targets makes use of
                address-independent iSCSI names, iSCSI does not have the same
                proxy addressing problems as HTTP, which includes address
                information into its URLs.  If a proxy is to provide services
                to an initiator on behalf of a target, the proxy allows the
                initiator to discover its address for the target, and the actual
                target device is discovered only by the proxy.  Neither the
                initiator nor the iSCSI protocol needs to be aware of the
                existence of the proxy.
   
                Effects on iSCSI:
   
                - Same as a SCSI gateway.  The only other effect is that
                  iSCSI must separate data integrity checking on iSCSI headers
                  and iSCSI data, to allow the data integrity check on the
                  data to be propagated end-to-end through the proxy.
   
                B.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, there are no additional
                  requirements on the iSCSI protocol for this one.
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                26
   
   
   
   
                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.
   
                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.
   
          Appendix C
   
             This document has described the creation and use of iSCSI Node Names.
             There will be trusted environments where this is a sufficient form of
             identification. In these environments the iSCSI Target may have an
             Access Control List (ACL), which will contain a list of authorized
             entities that are permitted to access a restricted resource (in this
             case a Target Storage Controller).  The iSCSI Target will then use
             that ACL to permit (or not) certain iSCSI Initiators to access the
             storage at the iSCSI Target Node. This form of ACL is used to prevent
             trusted initiators from making a mistake and connecting to the wrong
             storage controller.
   
             It is also possible that the ACL and the iSCSI Initiator Node Name
             can be used in conjunction with the SCSI layer for the appropriate
             SCSI association of LUNs with the Initiator.  The SCSI layer's use
             of the ACL will not be discussed further in this document.
   
             There will be situations where the iSCSI Nodes exist in untrusted
             environments. That is, some iSCSI Initiator Nodes may be authorized
             to access an iSCSI Target Node, however, because of the untrusted
             environment, nodes on the network cannot be trusted to give the
             correct iSCSI Initiator Node Names.
   
             In untrusted environments an additional type of identification is
             required to assure the target that it really knows the identity
             of the requesting entity.
   
             The authentication and authorization in the iSCSI layer is
             independent of anything that IPSec might handle, underneath
              or around the TCP layer. This means that the initiator node
              needs to pass some type of security related identification
              information (e.g. userid) to a security authentication process
              such as SRP, CHAP, Kerberos etc. (These authentication processes
              will not be discussed in this document).
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                27
   
   
   
   
             Upon the completion of the iSCSI security authentication, the
             installation knows "who" sent the request for access.  The
             installation must then check to ensure that such a request,
             from the identified entity, is permitted/authorized.  This
             form of Authorization is generally accomplished via an Access
             Control List (ACL) as described above.  Using this authorization
             process, the iSCSI target will know that the entity is authorized to
             access the iSCSI Target Node.
   
             It may be possible for an installation to set a rule that the security
             identification information (e.g. UserID) be equal to the iSCSI
             Initiator Node Name. In that case, the ACL approach described above
             should be all the authorization that is needed.
   
             If, however, the iSCSI Initiator Node Name is not used as the security
             identifier there is a need for more elaborate ACL functionality. This
             means that the target requires a mechanism to map the security
             identifier (e.g. UserID) information to the iSCSI Initiator Node Name.
             That is, the target must be sure that the entity requesting access is
             authorized to use the name, which was specified with the Login Keyword
             "InitiatorName=".
             For example, if security identifier 'Frank' is authorized to access
             the target via iSCSI InitiatorName=xxxx, but 'Frank' tries to access the
             target via iSCSI InitiatorName=yyyy, then this login should be rejected.
   
             On the other hand, it is possible that 'Frank' is a roaming user (or a
             Storage Administrator) that "owns" several different systems, and thus,
             could be authorized to access the target via multiple different iSCSI
             initiators. In this case, the ACL needs to have the names of all the
             initiators through which 'Frank' can access the target.
   
             There may be other more elaborate ACL approaches, which can also be
             deployed to provide the installation/user with even more security with
             flexibility.
   
             The above discussion is trying to inform the reader that, not only is
             there a need for access control dealing with iSCSI Initiator Node Names,
             but in certain iSCSI environments there might also be a need for other
             complementary security identifiers.
   
   
          5. References
                 [1]  Pascoe, R., "Building Networks on the Fly", in IEEE
                      Spectrum,March, 2002.
   
                 [2]  John, R., "UPnP, Jini and Salutation- A look at some popular
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                28
   
   
   
   
                      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., Chadalapaka, M., Zeidner, E., Dalle Ore, L., Klein,
                     Y., "iSCSI", draft-ietf-ips-iscsi-07.txt, July, 2001.
   
                 [8]  Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage
                      Name Service", draft-tseng-ips-isns-04.txt, July 2001.
   
                 [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".
   
                 [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
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                29
   
   
   
   
                      the iSCSI Protocol", draft-ietf-ips-iscsi-boot-03.
   
                 [21] M. Bakke et al,"Finding iSCSI Targets and Name Servers using
                      SLP", draft-ietf-ips-iscsi-slp-01.txt, July, 2002.
   
                 [22] Sun Microsystems, "Java Language Specification", section 7.7
                      "Unique Package Names", 2000,
                      http://java.sun.com/docs/books/jls/second_edition/html/
                      jTOC.doc.html.
   
                 [23] Flanagan, et. al, "Java in a Nutshell", O'Reilly, 1997.
   
                 [24] P. Hoffman, M. Blanchet, "Preparation of Internationalized
                      Strings", draft-hoffman-stringprep-00.txt, September, 2001.
   
                 [25] Unicode Standard Annex #15, "Unicode Normalization Forms",
                      http://www.unicode.org/unicode/reports/15
   
                  [26] M. Bakke, "String Profile for iSCSI Names",
                   draft-ietf-ips-iscsi-string-prep-00.txt, November 2001.
   
   
   
          6. Author's Addresses
   
                Address comments to:
   
                Kaladhar Voruganti
                650 Harry Road
                IBM Almaden Research
                San Jose, CA
                USA
                Email: kaladhar@us.ibm.com
   
                Mark Bakke
                Cisco Systems, Inc.
                6450 Wedgwood Road
                Maple Grove, MN 55311
                Phone: +1 763 398-1054
                Email: mbakke@cisco.com
   
                Jim Hafner
                IBM Research
                Almaden Research Center
                650 Harry Road
                San Jose, CA 95120
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                30
   
   
   
   
                Phone: +1 408-927-1892
                Email: hafner@almaden.ibm.com
   
   
                Josh Tseng
                Nishan Systems
                3850 North First Street
                San Jose, CA 95134
                Phone: 408 519-3749
                Email: jtseng@nishansystems.com
   
   
                Marjorie Krueger
                Hewlett-Packard Corporation
                8000 Foothills Blvd
                Roseville, CA 95747-5668, USA
                Phone: +1 916 785-2656
                Email: marjorie_krueger@hp.com
   
                Phone: (408) 957-4980
                Email: todd_sperry@adaptec.com
   
   
   
   
          Voruganti, K.  Informational-Track  Expires August 2002
   
          Internet Draft         Naming and Discovery                31
   
   
   
   
             "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"
   
   
   
   
   
          Voruganti, K.  Informational-Track  Expires August 2002
   

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/