Re: iSCSI: Canonical Targets

[julian_satran@il.ibm.com]

Mark,

I don't see any iSCSI interoperability issue if you don't have the
canonical target.
This is a service discovery mechanism that we are mistakenly taking on a
specialized track.
I assume that many other services "hide" behind portals (print is one good
example).
We are not going to leverage this commonality if we are attempting a
specialized interface.
Perhaps the boxes should be mandated to have something to enable discovery.
My only claim is that this is not an "iSCSI item" it is a service discovery
issue and it should be
handled in that realm and enable interoperability with other service
discovery mechanisms.

Julo


Mark Bakke <mbakke@cisco.com> on 14-05-2001 16:13:59

Please respond to Mark Bakke <mbakke@cisco.com>

To:   james.smart@trebia.com
cc:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
Subject:  Re: iSCSI: Canonical Targets




James-

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

James Smart wrote:
>
> 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.

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.

> 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

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.

> "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

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.

> target device to shift session-specific traffic to target-assigned port
> numbers that can aid it's classification schemes.

--
Mark

> -- James
>
> julian_satran@il.ibm.com 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 <mbakke@cisco.com> on 12-05-2001 00:04:24
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > To:   IPS <ips@ece.cmu.edu>
> > 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
> > mbakke@cisco.com
> > 763.398.1054

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054