Subject: Re: iSCSI: Canonical Targets

From: [email-masked]
Date: Sat, 12 May 2001 07:39:35 +0300

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: James Smart <[email-masked]>
Date: Sat, 12 May 2001 08:42:09 -0400

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

---

From: Mark Bakke <[email-masked]>
Date: Mon, 14 May 2001 08:13:59 -0500

James-

Your argument for interoperability is correct.  Please see my comments
below on the other discovery mechanisms.

> confusing answers from devices that otherwise would not respond to the

Correct.  The danger in not supporting the canonical target on all devices
is that initiators may then choose not to look at it.  Even in an environment
without proxies and gateways, any medium-sized disk array should be able
to support more than one logical target.

> 4-tuple to classify on if rerouting is not allowed.. I would expect the

Actually, by defining several logical targets, a single IP address + IANA
TCP port can be shared by all.  This is a direction I suspect many implementors
will take.

> well-known IANA TCP port number. The canonical processing simply allows the

The SLP template includes the TCP port number on which the target is
listening.  If a target is discovered using SLP, the initiator could
skip using SendTargets on its address.

Although we are not considering using it, SSDP (used by UPnP) returns
a URL, which could include a TCP port number.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 14 May 2001 16:35:28 -0400

Mark,

I don't disagree with the general thrust of your statement, but I must
argue with:

> Even in an environment without proxies and gateways, any
> medium-sized disk array should be able to support more than one
> logical target.

Unless somebody's really building a medium sized disk array a)
completely from scratch b) for iSCSI use only, this is unlikely.

Existing disk arrays present all storage containers as LUNs.  The most
likely [credible] iSCSI targets will be existing storage arrays with
iSCSI front-ends.  This follows the ||SCSI->FCP pattern.  The
alternative interpretation, which I'm pretty sure is false, is that
the back-end part of a storage controller is really simple so the
serious iSCSI targets will not come from the same vendors (or groups)
as existing, serious storage targets.

Bridges are a different issue, but I've always felt (and you seem to
agree) that the bridges just have to suck it up and, well, bridge, the
semantic gaps between what's expected in a native initiator->target
interaction and what you get with an initiator->bridge->target one.

Steph

---

From: Mark Bakke <[email-masked]>
Date: Tue, 15 May 2001 07:56:13 -0500

> > medium-sized disk array should be able to support more than one

I did say "should".  OK, perhaps I'm engaging in a little bit of
wishful thinking, but it seems to me that most people would rather
deal with a set of logical targets, each created for use by a host
or application, rather than a single target with different LUN maps
depending on who's asking.  I know we'll have to support the latter
as well.

Anyway, I agree that bridges will always need to take up the
slack, but my point was that I didn't want to see initiators
make the assumption that there is only one target for them at
each address.  I just don't want to see us do a repeat of some
of the limitations of ||SCSI and FC.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054