iSCSI Discovery and SendTargets

[Mark Bakke <mbakke@cisco.com>]

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