Subject: Re: iSCSI: Canonical Targets

From: [email-masked]
Date: Tue, 22 May 2001 20:47:16 +0300

Jim,

Analogies may be misleading.  You have no new web server behind a web
server (although you may have some redirection).

You are suggesting a discovery for several targets behind a portal
(address). Those can be disks, tapes, changers etc. in any combination.

I know this is valuable (we have it in almost from version 0!).

All discovery mechanisms have all this in already in a form or other (take
a look at Salutation, Jini, UpNP).

To build it under SCSI we are putting in place some artifacts (a different
login - perhaps secure?, some commands to be done only there or not?) that
are barely useful for other services.

Why shouldn't we take the road of deferring the name discovery to the
specialized (iSCSI) part of a more general
discovery protocol?

You don't expect the management applications to start using iSCSI for
discovery do you?

Julo

Jim Hafner@IBMUS
21-05-2001 18:04

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
From: Jim Hafner/Almaden/IBM@IBMUS
Subject:  Re: iSCSI: Canonical Targets  (Document link: Julian Satran -
      Mail)

Julo,

I was only teasing about the name.  I don't care either, it's a nit.

As for "discovery service". Here's a twist on the issue.

In the case of most services, at a single ipaddress:tcpport, you'll find a
single service entity (web server, ftp server, etc) and only AFTER you get
through the first layer does finer granularity of discovery occur (e.g.,
through the query string of the url). But even in these cases, there's
actually little of discovery going on.  You pretty much have to know what
you're going for first, or you drill manually (think of ftp server accessed
through browser -- you get directory listing which you browse).  What I
think we're doing here is providing a "directory list" function for the
single service entity that lives at the defined tcpport.   This "listing"
service can then be used to drill deeper.   I don't see much that's
different in what we're spec'ing and what needs to be spec'd for this
purpose.

We can rely on some mechanisms such as SLP and SNS for somethings.  SLP
helps to find the place to start for listing service.  SNS has "all the
answers".   We're attempting to fill in the middle ground.

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 05-19-2001 12:26:29 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI: Canonical Targets

Jim,

The canonical attribute is associated with strictly conforming to a rule
(as in canonical form for expressions or canon in music, or canonical
religious text).  I would use the term generic-name or class-name for it.
But again the objection on the name was only minor.  I strongly believe
this is a service-delivery discovery item and we are repeating an old
mistake - creating a specialized solution for a general problem.  Any
discovery service would be better than placing this in the iSCSI realm.

Julo

"Jim Hafner" <[email-masked]> on 14-05-2001 18:14:31

Please respond to "Jim Hafner" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI: Canonical Targets

Julo,

You object to the term "canonical"?  My dictionary says canonical is
"conforming to a general rule", but perhaps that isn't the best term.
Would "well-known" would be better?

Jim Hafner

Julian Satran/Haifa/IBM@[email-masked] on 05-12-2001 09:05:00 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI: Canonical Targets

Why would any discovery service be wiser/stupider than the mechanism we are
having in N&D?
If the issue of ports is widespread then others have it too and discovery
may include all the nice things we
have in iSCSI.  I don't see any reason iSNS or an LDAP repository can't
contain them.

My only claim is that this adds weight to iSCSI.

As for interoperability - I claim that adding features makes
interoperability an issue. Removing them does not.
The whole "canonical" (why canonical - there is nothing canonical about it)
target idea is good but in another realm - I don't think it belongs to
iSCSI - it belongs to discovery be it specific or general.

I can leave with the mechanism as it is - but I really feel that we are on
the wrong track.

Regards,
Julo

James Smart <[email-masked]> on 12-05-2001 15:42:09

Please respond to [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, Mark Bakke <[email-masked]>
cc:   [email-masked]
Subject:  Re: iSCSI: Canonical Targets

I'm in agreement with Mark, that canonical target support is mandatory. The
key is interoperability. The initiator must be mandated to probe the
canonical target and not assume a single target device. If all initiators
do
not support this type of probing, then interoperability goes out the
window.
Mark's effort, mandates the support on the target device - which indirectly
puts the mandate on the initiator to check, and makes sure there are not
confusing answers from devices that otherwise would not respond to the
canonical target.

Is this replacing discovery - perhaps in some ways. The real issue is
allowing i/o traffic to be rerouted to non-IANA TCP port numbers, which is
a
critical need of the proxy/routers/etc, which have little left in the
socket
4-tuple to classify on if rerouting is not allowed.. I would expect the
"discovery" (SLP, uPnP,etc) mechanisms would contain the "targets" that the
proxy/router/etc, but the expectation is that they would all point at the
well-known IANA TCP port number. The canonical processing simply allows the
target device to shift session-specific traffic to target-assigned port
numbers that can aid it's classification schemes.

-- James

[email-masked] wrote:

> Mark,
>
> I am not sure that we want to have your "canonical" target as a mandatory
> construct.
> It is good for proxies, routers, portals etc.? Don't the have better
> mechanisms for discovery.
> But why should you force it on some small box that has the name wired and
> printed on it's label.
> To reach the canonical you have to go through all the "login etc.".
>
> I think that all goes back to asking - why should we use iSCSI for
> discovery?
>
> SLP, UPnP, Salutation, Jini all attempt discovery using a a general form
> (good for iSCSI, Lpr printers etc.)
> Can't we take the same path?
>
> Julo
>
> Mark Bakke <[email-masked]> on 12-05-2001 00:04:24
>
> Please respond to Mark Bakke <[email-masked]>
>
> To:   IPS <[email-masked]>
> cc:
> Subject:  iSCSI: Canonical Targets
>
> It was pointed out during the interim meeting that the
> canonical target is defined somewhat ambiguously, and may
> be a bit too flexible for interoperability purposes.  This
> message is a stake in the ground for defining this a little
> more tightly.
>
> So here are the new canonical target rules.  Please let me
> know if there are major problems with any of them.  I tried
> to define them a-la-carte, to make it easier to pick out any
> that might cause trouble.
>
> 1. Each iSCSI implementation MUST include a canonical target.
>
> 2. A canonical target MUST be accessible at the default, IANA-
>    assigned TCP port on each IP address on which the iSCSI
>    implementation is listening for iSCSI connections.
>
> 3. A canonical target MUST NOT be used for SCSI commands.
>
>    A canonical target is an iSCSI construct only, and does not
>    have a corresponding SCSI device.  This means it may not
>    be used to access Logical Units.
>
>    A session created to a canonical target is a discovery session
>    only, and once in full feature phase, is used only for text
>    commands and asynchronous messages.  (Do any other commands make
>    sense)?
>
> 4. A device containing a single target MUST provide both the
>    canonical target and the real target.  (This is implied by the
>    above requirements).
>
>    An initiator connecting to such a device using only its IP address
>    would first connect to the canonical target, and use SendTargets
>    to obtain the iSCSI name of the real target.  It would then create
>    a separate session to the real target.  Essentially, this means
>    there's nothing special about a single-target device.
>
> 5. An iSCSI device MUST provide a unique iSCSI name for each of its
>    targets.  Using the canonical target as a nameless iSCSI target
>    is not supported.
>
> 6. We can further specify the order in which the SendTargets response
>    fields are returned, to simplify things further, e.g. each target
>    in the SendTargets response MUST return these fields in this order:
>
>    - A TargetName= field
>    - A TargetAlias= field (value left blank if there's no alias)
>    - One or more TargetAddress= fields
>    - Any vendor-specific fields (ignored by standard initiators)
>
> The above rules will make the behavior of various target implementations
> identical, regardless of the number of interfaces or targets they
> support.  This will reduce the number of end-cases that initiator
> implementations will have to handle.
>
> If we agree on these, we can edit them into the iSCSI and NDT documents.
>
> Additional questions to send input on:
>
> 1. Should a non-canonical target respond to a SendTargets command?
>
> 2. If so, should it respond only with addresses for its own target,
>    or should it respond with other targets, as a canonical target
>    might do?
>
> 3. If not, the initiator must connect to a canonical target to find
>    the other addresses of a target to which it is already connected;
>    is the information it has sufficient to do so?  (I think the answer
>    is yes, given canonical requirement #2 above).
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

---

From: Stephen Bailey <[email-masked]>
Date: Tue, 22 May 2001 22:08:16 -0400

Julian,

> Why shouldn't we take the road of deferring the name discovery to
> the specialized (iSCSI) part of a more general discovery protocol?

The reason is, for a minimal, useful iSCSI configuration, we must not
require any additional pieces of infrastructure beyond (Mark's term)
table stakes for IP (e.g. DNS), an iSCSI initiator and an iSCSI
target.  Assuming we want to allow multitarget iSCSI endpoints in
minimal configurations (I'm sure we do), there MUST be a way for the
initiator to learn what targets are behind that endpoint from within
the initiator's machine environment.  The solution to this problem
can't be `walk over to the target and read a bunch of numbers and type
them in to the initiator'.

> You don't expect the management applications to start using iSCSI for

Why not?

When you say `management application' you seem to imply an application
which would manage an arbitrary, possibly extremely large
configuration (e.g. OpenView).  Actual management applications range
from simple to complex, and many configurations (particularly in the
pilot phase that hopefully iSCSI will be entering) start very simple.

I don't think anybody would argue that FCP PL-DA provided very
complicated networks, yet every initiator implementation usually
provided a program or something which simply spat out the WWNs (and
probably the AL_PAs) for each target.  Such a simple `management
application' is going to be a lot like (perhaps IS) an existing SCSI
control utility that can give you a list of buses, targets, LUNs, some
inquiry data, and whatnot.

Clearly, iSNS has nothing to say about this scenario.

Are you proposing that SLP be used to supplant the existing simple
directory mechanism in the iSCSI draft (and that it be mandatory to
implement)?  That might work.  I'm not sure it makes sense, but if you
think so, let's discuss it.

In this case, multicast support (a typical objection to SLP) wouldn't
be necessary, because you'd already know where the target is by
configuration.  SLP+iSCSI mechanisms would be offering the same
service as the existing SendTargets but in a more ultimately scalable
way.  However, this proposal doesn't appear to solve any security
problems.  What security provisions does SLP have?  Presumably the
target would still authenticate the initiator in the SLP connection to
ensure the initiator had rights to get the target list.  That part is
the same as the current proposal, so you're not saving the target any
work.

Steph