RE: iSCSI Discovery and SendTargets

[Joshua Tseng <jtseng@NishanSystems.com>]

Mark,

I just wanted to add some additional information about iSNS
that might help make this analysis easier.

>    iSNS does not define a method for an initiator to discover
>    a target directly without an iSNS server, or to contact a
>    target directly to gain a list of its addresses.

There is no reason why an iSNS server can't be deployed in a
target device just to support that device's targets, and for the
iSNS protocol to fulfill the capabilities that are described in
your memo regarding simple iSCSI discovery.  I do not see a
fundamental difference between deploying an SLP SA on each
target, and deploying an iSNS server on each target.  iSNS can
be scaled down as well to fulfill simple discovery, if that's
all that is required.

As I look down the list of SLP capabilities, there is nothing
I see that iSNS does not also provide.  A comparison of iSNS
server code with SLP SA code shows that they are not significantly
different in size (both are roughly 10,000 loc).  But with iSNS,
you also have management capabilities such as Zoning (DD's), which
allow an iSCSI device to display a different view of its targets
to each initiator.  This might be especially important in a mixed
NT/Unix environment.

On the other hand, if the goal is to scale down to a simple,
discovery mechanism, all the management capabilities (zoning,
ESI polling, etc...) can be removed from iSNS, resulting
in an even lighterweight implementation.

Josh

> 
> We have had several discussions, both on and off the list,
> during and since the interim meeting on the SendTargets text
> command.  These discussions have included the following
> topics:
> 
> 1. Use of a default or well-known target for SendTargets and
>    related functions only.
> 
> 2. Iteration of the SendTargets command for responses that will
>    exceed the capacity of a single text response.
> 
> 3. The addition of other information to the SendTargets response,
>    such as aggregation tags, certificate subject names, or even
>    certificates themselves, and perhaps boot-related information.
> 
> 4. The splitting of SendTargets into two commands:
> 
>    ReportTargets - used on a well-known target connection to
>    get the list of target names the initiator should look for,
>    and at least one address for each.
> 
>    ReportPortalGroups - similar to SendTargets, but done on an
>    operational iSCSI connection, and returning only the addresses
>    for the particular target to which the connection belongs.
> 
> The question has been raised as to whether the addition of these
> features, along with the separation of SendTargets on its own
> connection type, really turns SendTargets into its own protocol.
> So if SendTargets is its own protocol, the question morphs into
> "why not use a standard protocol already defined for this purpose?"
> 
> If we consider that the purpose of SendTargets is to discover
> a set of targets and their addresses, protocols such as SLP
> and SSDP (used by universal plug & play), and those provided by
> Jini, Salutation, and others, already provide this.  As we have
> gone through the selection exercise before of deciding which of
> these to use for multicast discovery, we assumed that the correct
> protocol is SLP.
> 
> Providing SLP support for iSCSI targets and initiators allows
> initiator to discover targets and their addresses without a lot
> of configuration.  Specifically, an initiator does not need to
> be configured with any of the address of its targets; it can
> discover them either through multicast requests, or by contacting
> an optional directory agent.
> 
> Back to the naming & discovery requirements, and ignoring the
> specific discovery protocols used, an initiator may
> be configured with target information in a number of ways:
> 
> - The iSCSI target name and each of its addresses.  In this case,
>   absolutely no discovery is needed; the user did it already.
> 
> - The iSCSI target name and one of its addresses.  In this case,
>   the initiator can log in to the target, but needs a mechanism
>   to find out if there are more addresses on which the target may
>   be found.  SendTargets fills this need.
> 
> - The address at which an iSCSI target may be found.  In this case,
>   no target name is included; the initiator is expected to contact
>   the iSCSI entity at this address and find out which targets it is
>   supposed to see.  This is what SendTargets is intended to do.
> 
> - The iSCSI target name with no address.  In this case, there are
>   no hints given as to where the target is; the inititator must have
>   a further discovery mechanism configured to resolve this name.
>   SLP, iSNS, and SendTargets as a directory mechanism are all set
>   up to fill this need, with varying amounts of configuration
>   required.
> 
> - No iSCSI target names or addresses.  In this case there are no
>   hints even at which targets the initiator should see.  Again,
>   a further discovery mechanism is required.
> 
> Of course, most of the above methods are compatible with each other;
> one could configure an initiator to look for some iSCSI target names,
> and also go ask a few particular addresses, and also do multicast
> to go find any other targets that might be necessary.  This means
> that we really aren't choosing amongst the above options; we must
> eventually enable all of them, and let the users decide which one
> makes life easiest in their environment.
> 
> When the configuration method requires a discovery mechanism, there
> are a few proposed ways of implementing discovery:
> 
> 1. SLP can provide discovery with varying levels of configuration
>    required:
> 
>    - If nothing is configured, SLP will use un-authenticated
>      multicast requests to find its targets.
> 
>    - If the user configures SLP authentication, it can do
>      authenticated multicast requests in the same manner.
> 
>    - If the user configures an SLP directory agent address (or
>      assigns it via DHCP), and does this on the initiator and
>      target, discovery can be done without using multicast.
> 
>    The only thing missing is the ability to configure the
>    initiator with the address of the target, and have it
>    do the unicast request over TCP without a directory agent.
>    This is the gap that SendTargets currently fills.
> 
> 2. A SendTargets tree has been verbally proposed that would
>    include some sort of software implementation that knew about
>    targets and addresses for a collection of devices.  Such an
>    implementation may be part of a vendor's storage management
>    software.  The initiator would be configured with the IP
>    address of a well-known target on the management station,
>    and use SendTargets to get the list of target names and
>    addresses of the actual devices (implemented elsewhere)
>    to which it can connect.  By responding with other well-
>    known targets to which to make further requests, a
>    hierarchy of SendTargets servers can be built.
> 
>    This has the advantage of using the same login and authentication
>    schemes as iSCSI, since it is built on the iSCSI text commands.
> 
>    It has the disadvantage that zero-configuration is not
>    possible, but a very simplified SLP template could be used
>    to remedy this.
> 
> 3. iSNS has been proposed to fulfill the same requirements.
> 
>    iSNS can fulfill each of the configuration requirements
>    through an iSNS server.
> 
>    iSNS does not define a method for an initiator to discover
>    a target directly without an iSNS server, or to contact a
>    target directly to gain a list of its addresses.
> 
>    Zero-configuration of initiators in an iSNS enviroment is
>    done by listening for iSNS heartbeat messages advertising
>    the iSNS servers.  iSNS servers can also be discovered using
>    SLP.
> 
>    Like an SLP DA, an iSNS server's address (and optional
>    authentication information) can be configured on each host
>    and device to avoid multicast; it can also be assigned to
>    hosts using DHCP.
>    
> 
> Since SLP was the only protocol with only one of the configuration
> abilities missing (the ability to contact a target directly using
> a configured unicast address), I decided to take a look to see if
> it could be modified to add this as well.
> 
> I spent some time hacking at the OpenSLP, which is an open-source,
> BSD-license SLP implementation.  The hack I did was to allow the
> SLP user agent (UA; which would be integrated with an initiator)
> to specify the IP address of a service agent (SA; which would be
> integrated with a target), instead of finding the SA via multicast.
> Basically, the UA opened a TCP connection to the SA, sent its
> ServiceRequest message asking for iSCSI targets, and received a
> ServiceResponse containing the addresses advertised for the iSCSI
> targets.  The information contained in the response was identical
> to the information that would have been provided by SendTargets.
> 
> Modifying SLP in such a way caused no changes to be made to the
> protocol's message formats, to the SA or to the directory agent
> (DA, if one is present).  The only change was a behavioral change
> in the UA.  A brief conversation with one of the SLP developers
> found that other people have been thinking of adding the same
> functionality for other reasons, so I don't think we would be adding
> something that would not be supported by the SLP folks.  Anyway, 
> that's subject to verification.
> 
> After verifying that SLP can indeed be modified to fulfill
> each of the initiator's configuration requirements from a
> technical perspective, we now have to look at a few other
> problems, such as differences in authentication schemes, and
> the expediency of getting products released and interoperability-
> tested.
> 
> Here are the differences between using a Unicast SLP for the
> SendTargets function and using SendTargets as-is:
> 
> 1. Expediency - SendTargets is very easy to implement, many of us
>    have already implemented it, and I believe that it is intented
>    to be tested at the UNH plugfest in July.
> 
>    Given this, SendTargets is probably the best way to go.
> 
> 2. Philosophy - The internetworking philosophy is to build a
>    bunch of smaller "functional" protocols.  Each of these
>    protocols is designed to do one function, do it well, and do
>    it for everybody.  For example, if I was to build an NFS
>    server, I would use:
> 
>    NTP - to coordinate time
>    DNS - to resolve host names into addresses
>    DHCP - to assign IP addresses and other information
>    RADIUS - to request authentication of a username/password
>           hash.
>    SNMP - to monitor the server 
>    CIM - to configure the server
>    and so on.
> 
>    These protocols are modified over time, and new versions
>    introduced, as services are added that stretch their original
>    boundaries.  However, their basic function remains the same.
> 
>    SLP fits in with these best; it's designed to allow service
>    discovery for a whole bunch of unrelated services, and that's
>    all it attempts to do.  SSDP and other protocols are also
>    in this boat.
> 
>    The opposite philosophy is to build a single protocol that contains
>    just what is needed for a particular solution out of each of
>    the above categories of protocols.  This can be more expedient,
>    but is probably frowned upon by the IESG folks.
> 
>    Given this, SLP is probably the better philosophical way
>    to go.
> 
> 3. On the other hand, one could argue that SendTarget is really
>    a lot like "Report LUNs" for SCSI, or like "ls" for ftp, and
>    is really just providing a directory listing, not full discovery.
> 
> 4. Amount of code.  SLP will require somewhat more code to implement
>    than SendTargets, but at least there are code bases available.
>    So SendTargets will have the initial smaller footprint, but as
>    implementations add both SendTargets and SLP (for 
> zero-configuration),
>    the combined code base will be larger than if everyone just
>    used SLP in the first place.
> 
> 5. Authentication - The really hard part of all of this is that
>    SendTargets is the only method of discovery that can actually
>    share the exact same login & authentication method with the
>    iSCSI protocol itself.  This makes it really easy for an 
> implementation
>    to say that its authentication during discovery is 
> "at-least-as-good"
>    as the authentication between the eventual initiator and target.
>    SLP can be authenticated as well, but since it uses a different
>    authentication mechanism, we will have to take more time to figure
>    out how to guarantee that it's "at-least-as-good" in all cases.
> 
> Anyway, those are some thoughts; I am sure there are more.
> 
> Unfortunately for me, I have found that I am able to argue most of
> these points from either side.
> 
> In the end, we have three options:
> 
> 1. Keep SendTargets as-is in the iSCSI protocol, finish our 
> discussions
>    on the original four topics, and add whatever is needed.
> 
> 2. Reserve the well-known target "iscsi" within the iSCSI 
> specification,
>    with the note that interaction with this target is for discovery
>    purposes documented elsewhere, and moving all well-know target
>    functions (currently SendTargets), to another document.
> 
> 3. Drop SendTargets in favor of a "functional" protocol such as SLP.
> 
> In either of the three options, the naming & discovery team' rough
> consensus was that we keep at least the ReportPortalGroups
> functionality within iSCSI.
> 
> From an expediency vs. philosophical correctness of having a single
> discovery protocol, there are combinations:
> 
> - Implement SendTargets now, let it be used as a hierarchy, and
>   provide an optional, simplified SLP template to discover only
>   the well-known targets.  The real information is now provided
>   only within SendTargets or its kin.
> 
> - Implement SendTargets now, but keep it as simple as possible,
>   and encourage that discovery implementations migrate to SLP
>   later on.  This would stop the growth of SendTargets into its
>   own protocol, but get us something to work with for the very
>   near term.
> 
> - Probably more, but it's getting late.  Perhaps one of the former
>   two "compromise" bullets, perhaps combined with option (2) to 
>   move SendTargets to another document will be the right balance
>   between expediency and overall philophical consistency.
> 
> One important point to make is that regardless of the path we
> choose, we ought to at least reserve a well-known target name
> such as "iscsi", in case we need to add other things in the
> future that do not address any specific SCSI target.  The SCSI
> folks have had the same problem within a target; there is no
> way to address a command to a whole target, so target-specific
> commands have had to use LUN 0.  Perhaps a way to address the
> iSCSI target "all" or the iSCSI target "nothing" would be the
> way to go.
> 
> OK, the can is open.  Any comments?
> 
> -- 
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>