RE: iSCSI: target discovery issue

[sandeepj@research.bell-labs.com (Sandeep Joshi)]

Josh & John,

Thanks for the hi-level perspective.  I do agree that iSNS
and/or SLP will do the trick here and that this functionality 
falls into the OA&M domain.

Four score and seven days ago (..approx!), this thread started due 
to confusion with the following line in the naming and discovery 
draft, which had no equivalent message code defined in the iSCSI 
Async PDU.   

> 1) Section 4.2 last line before Section 4.2.1
>    "the target MUST send any iSCSI-level async on the canonical
>    session, to allow the initiator to discover new targets as
>    they are created.."

Can the issue be laid to rest by removing this statement ?

Thanks,
-Sandeep


> John, Sandeep,
> 
> I would like to append to Mark's note that method D is
> the iSNS.  The iSNS breaks from the device-by-device
> management paradigm that the previous methods use.  It
> provides for network-wide storage device discovery,
> zoning and management.
> 
> The details of how iSNS works is documented in the
> iSNS document, and an overview is in the iSCSI N&D
> requirements document.  But the key concept is that
> instead of going to device A, configure its access
> list, then on to device B, configure its access list,
> then on to initiator A, configure its list of targets,
> etc....you instead go to a single entity, the iSNS
> server, to gain a network-wide view of all storage
> assets.  If all storage devices have slaved their
> discovery and management functions to the iSNS server,
> then the iSNS is a single management point that the
> GUI can use to configure discovery and access privileges
> for the entire storage network.
> 
> When a new target shows up on the network, it registers
> in the iSNS.  The iSNS server then sends notifications to
> interested iSNS clients (only those configured for this
> notification with the proper zoning) informing them of the
> new device. The iSNS client is a co-resident application
> on iSCSI targets and initiators that maintains communication
> with the iSNS server.
> 
> Hope this helps.
> 
> Josh
> 
> > -----Original Message-----
> > From: John Hufferd [mailto:hufferd@us.ibm.com]
> > Sent: Wednesday, April 18, 2001 3:08 PM
> > To: Sandeep Joshi
> > Cc: ips@ece.cmu.edu
> > Subject: iSCSI: target discovery issue
> > 
> > 
> > 
> > First off you need to understand that we are talking about 
> > Targets, NOT LUs
> > nor LUNs.
> > 
> > Next this is a feature that you want to have in your 
> > management SW, and I
> > believe that iSNS can help here. Josh Tseng pipe in here.
> > 
> > Further, storage events don't usually just happen that 
> > everyone needs to
> > know about it.  As a rule, storage is brought on to meet some 
> > requirement.
> > The requirement is usually needed by a specific host.  Just 
> > because you add
> > a Storage Controller does NOT mean that all the various host 
> > should start
> > using the storage.  The storage is first established as LUs 
> > and the LUs are
> > assigned to specific authorized Host (or iSCSI Nodes as we 
> > are calling them
> > now) and when the session is started, and authenticated, that Host can
> > issue the Report LUNs and that maybe the first time an LU has 
> > been given a
> > Number for that particular Host.   But none of that should 
> > begin until the
> > Host is sure that there is something for it to find.  And the thing it
> > wants to find is a LUN not a SCSI Device/iSCSI Node or 
> > Target.  Getting
> > knowledge of a new LU that can be used by a specific host is 
> > NOT an iSCSI
> > thing.  It is SCSI, and very deep into the Management SW and Admin
> > Processes.
> > 
> > I punished you with this information so that you can see why I did not
> > understand why you were concerned about a Host being 
> > automatically told
> > about a new SCSI Device/ iSCSI Node/Target.  I would expect 
> > that if the
> > administrator had gone to the work to bring in the storage controller,
> > configure it for specific Hosts to use, set up the various LUs to be
> > authorized for the various Hosts.  It seems reasonable for 
> > the Admin to ask
> > the Host to recycle its discovery functions.
> > .
> > .
> > .
> > John L. Hufferd
> > Senior Technical Staff Member (STSM)
> > IBM/SSG San Jose Ca
> > (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> > Internet address: hufferd@us.ibm.com
> > 
> > 
> > Sandeep Joshi <sandeepj@research.bell-labs.com>@ece.cmu.edu 
> > on 04/18/2001
> > 11:21:34 AM
> > 
> > Sent by:  owner-ips@ece.cmu.edu
> > 
> > 
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  Re: target discovery issue
> > 
> > 
> > 
> > 
> > just realized that the reflector is not seeing this discussion.
> > the question at hand is how should target discovery notification
> > be sent in the iSCSI world.
> > 
> > Mark Bakke wrote:
> > >
> > > Actually, I think that part of it is an iSCSI issue.  That is,
> > > if a new target is created, that's at the SCSI level.  But if I
> > > add an iSCSI address on which to access that target, it now must
> > > be discovered first by the iSCSI layer on the host, before it
> > > can be presented to the SCSI layer.  In this case, we would need
> > > to send an iSCSI event indicating that there is a new target (or
> > > at least that there is some change in availability of targets);
> > > the host would then use SendTargets to find out the specifics.
> > >
> > > This brings up Sandeep's question #2.  If I am a target, I can
> > > send this message either:
> > >
> > >  a) On every iSCSI connection
> > >
> > >   OR
> > >
> > >  b) On all connections to canonical targets
> > >
> > > Method a gives us better coverage, and does not require an
> > > initiator to keep its canonical target connection around in
> > > between these little sendtargets commands.  However, if an
> > > initiator logs into a canonical target, finds that it has no
> > > targets to connect to (yet), and one is added later, the
> > > initiator would only find out if it had kept its canonical
> > > target connection, unless it is using an out-of-band discovery
> > > mechanism.
> > >
> > > Method a will also tend to bother connections to targets
> > > that are doing the "real" work (data path stuff).
> > >
> > > Method b will keep these events away from the data path, and
> > > will not generally have to send so many events.  However, it
> > > would require each initiator that wanted to be notified to keep
> > > its canonical connection around.
> > >
> > > There is a Method C, which is a combination of the above:
> > >
> > >  c) The device will send this async event message on ONE of the
> > >     connections to each initiator name (formerly WWUI) that is
> > >     connected to it.  If one of these connections is to the
> > >     canonical target, the device will use that one.
> > >
> > > Method c allows the initiator to choose whether it would rather
> > > keep an explicit canonical target connection around (e.g. if the
> > > other connections have been pushed down to hardware), or whether
> > > it would rather not keep the connection around, and be notified
> > > on one of the others.  The number of messages sent by targets
> > > would be identical to that in method b.
> > >
> > > --
> > > Mark
> > >
> > > julian_satran@il.ibm.com wrote:
> > > >
> > > > Sandeep,
> > > >
> > > > I think we are deep in T10 territory - this is a SCSI issue.
> > > >
> > > > Julo
> > > >
> > > > Sandeep Joshi <sandeepj@research.bell-labs.com> on 
> > 18/04/2001 16:21:06
> > > >
> > > > Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>
> > > >
> > > > To:   Julian Satran/Haifa/IBM@IBMIL, mbakke@cisco.com
> > > > cc:
> > > > Subject:  target discovery issue
> > > >
> > > > Julian & Mark,
> > > >
> > > > Friendly reminder... the issue mentioned below may not
> > > > have been resolved.
> > > >
> > > > 1) Is target discovery going to be the SCSI event or will
> > > >    it be wrapped up as an iSCSI event ?
> > > > 2) Do we have to keep a session to the canonical target
> > > >    always open to be able to do target discovery?
> > > >
> > > > -Sandeep
> > > >
> > > > I am not sure.  There are some SCSI items in it too (SCSI 
> > handles now
> > the
> > > > appearnce of new LUs).
> > > >
> > > > I will need a longer discussion with NDT to understand 
> > the semantics.
> > > >
> > > > Julo
> > > >
> > > > Sandeep Joshi <sandeepj@research.bell-labs.com> on 
> > 12/03/2001 22:25:27
> > > >
> > > > Julian,
> > > >
> > > > in case you skip this one..
> > > > your response is required on point (1) for amending iSCSI draft.
> > > >
> > > > -sandeep
> > > >
> > > > Sandeep-
> > > >
> > > > The problem you pointed out in item number 1 creates the need
> > > > for an additional iSCSI-level event.  Since the discovery of
> > > > targets happens at the iSCSI level, rather than at the SCSI
> > > > level, how about adding this to 2.18.1 (in iSCSI-05)?
> > > >
> > > >   4   Network entity indicates that a "target discovery" event
> > > >       has occurred.
> > > >
> > > > Upon receiving this message, the initiator should use SendTargets,
> > > > or whatever other methods of discovery it is using, to find out
> > > > what has changed.  Usually, this would be due to adding a new
> > > > target.
> > > >
> > > > We will fix items 2-4; thanks for pointing them out.
> > > >
> > > > Thanks,
> > > >
> > > > Mark
> > > >
> > > > Sandeep Joshi wrote:
> > > > >
> > > > > 1) Section 4.2 last line before Section 4.2.1
> > > > >     "target MUST send any iSCSI-level async on this session,
> > > > >      allowing the initiator to discover new targets.."
> > > > >
> > > > >    The session mentioned here is a session to the 
> > canonical target.
> > > > >
> > > > >    However, the iSCSI 05 draft does not mention any 
> > such condition
> > > > >    in Sec 2.18 on Async Message.   In there, a SCSI 
> > event (note: not
> > > > >    iSCSI) is used to notify availability of new targets.
> > > > >