SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI: Canonical Targets



    
    Steph,
    
    I'll need more time to absorb more of what you're saying, but I want to
    make one wording clarification which you alluded to in your first
    paragraph.  It's the misunderstood and overused term "target".  There are
    three interpretations of that term running around in this space:
    1) "SCSI target port": this is the more common interpretation of "target",
    at least in the SCSI world  (the multiport model for SAM-2 was titled
    "Defining targets/initiators as ports" so you see where the legacy comes
    from).
    2) "SCSI target device": this one is only now more formally being added to
    the SAM-2 model; essentially it is a container of SCSI target ports and
    SCSI logical units (and a few other things)
    3) "iSCSI target": this is the thing that gets the iSCSI name (at least as
    we've been looking at it) and is a purely iSCSI construct.
    [A similar distinction is required on the term "initiator".]
    
    I personally always attempt to be completely clear when I use the terms.
    So, if you read my note carefully, I use the term "iSCSI target"
    exclusively to mean thing 3.
    
    Can we all agree to use these terms carefully, to avoid the confusion
    misinterpretation of intent can cause?  Or should we come up with different
    terms?
    
    Here's short outline of how we've modeled things (and how I interpret the
    use of these terms):
    
    -- Each iSCSI target gets an iSCSI name.
    -- Each iSCSI target MAY contain at most one SCSI target device.
    -- An iSCSI target that does not contain a SCSI target device is there only
    for iSCSI purposes (such as SendTargets).
    -- Each iSCSI target must require it's name be supplied during login.
    This was so that iSCSI initiators (those things that initiate iSCSI login
    but may or may not have a SCSI initiator device within them) will always do
    the same login process, that is, include the iSCSI name.  [In other words,
    the name is mandatory for every login.]
    
    -- For an iSCSI target that only performs the SendTargets (has no SCSI
    target device), we allowed that to have the generic name "iSCSI".
    -- For an iSCSI target that has a SCSI target device, we wanted such things
    to have unique names for two reasons:
       (a) so that there would be something the initiator can authenticate and
    configure against
       (b) so that the SCSI target device could have a name as well (it would
    inherit the name from it's parent entity, the iSCSI target).
    
    We could easily remove the name from the SCSI-deviceless iSCSI target, but
    then the iSCSI initiator has to make the distinction of when to include the
    tag and when not to.  It's a nit.  We could make the name="none".  It's a
    placeholder, more than anything else.  On the other hand, there may be a
    need latter for other iSCSI targets that don't contain SCSI targets.  These
    might be administrative entities in the box.  So other "well-known names"
    could be defined as well.
    
    As I said above, I need some time to digest the rest of your note, but in
    the meantime, I am not confortable with an iSCSI target that contains a
    SCSI target device not having a unique name (if for no other reason to meet
    (b) above).  If it has a unique name and because it is available to the
    iSCSI initiator, there is no reason that initiator can't use it.
    
    Jim Hafner
    
    
    Stephen Bailey <steph@cs.uchicago.edu>@ece.cmu.edu on 05-17-2001 09:17:47
    AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:
    cc:
    Subject:  Re: iSCSI: Canonical Targets
    
    
    
    Jim, Mark, et al.,
    
    > I guess I'm having trouble understanding the issues here.   We seem to be
    > moving toward three types of iSCSI targets:
    
    I disagree.  We still only have one type of target, but our choice of
    terms is makes it look otherwise.
    
    > 1) one for discovery only, suitable for login only by authenticated
    > initiators, i.e., a one-sided authentication, but ONLY for the purposes
    of
    > SendTargets.
    
    A discovery login does not involve a target at all.  A target is a
    SCSI entity, and, as Mark pointed out, there's no SCSI interaction in
    a discovery login.
    
    If, as Mark, you don't like the empty string to denote no target, we
    could use:
    
      TargetName=none
    
    for discovery login.  I don't really care how the notion is
    represented, only that we agree upon the notion itself.
    
    > 2) one "nameless" target ("iSCSI"), again suitable for login only by
    > authenticated initiators, i.e., a one-sided authentication, but used for
    > real SCSI stuff
    
    This target is not nameless.  It has a full-fledged iSCSI name, which
    is returned in the LoginResponse of the login interchange.  `iSCSI' is
    A name (not THE name) for the DEFAULT (as administered at the target)
    target.  The specific target named by iSCSI may vary based upon
    initiator, or phase of the moon (a target-based administrative
    choice).  Authentication is performed with the initiator against the
    specific, target-chosen default target.  An initiator should only ask
    for the default target when it wants the associated default behavior.
    
    The advantage of the default target is you get an extremely
    low-overhead way of administering the storage accessed by an initiator
    which is configured purely at the target, without requiring additional
    infrastructure.  As Doug pointed out, this behavior is useful for
    initiators with limited resources, or just limited desire (or ability)
    to select a particular target (e.g. booting servers in an
    Infiniband-style zillion*3*1U rack farm).
    
    I'm having a hard time swallowing the `it makes the specification more
    complicated' argument.  After all, I tried that on multiconnection
    sessions, where it really DOES make the specification more complicated
    :^) Seriously, it's not complex to specify, we simply have to actually
    do it.
    
    Also, that somebody besides me and Doug (I'm sure there are many of
    you out there for whom our mail doesn't even reach your inbox....)
    hasn't specifically requested this feature isn't really a good
    argument.  The set of iSCSI applications represented presently is
    somewhat limited.  We all know iSCSI has huge potential, but if we
    make it purely market-targeted based upon the present, (aim for the
    immediate money), we're going miss future low-hanging fruit.
    
    Put another way, we're not expecting anybody to throw away their
    existing, local storage connection as soon as the ink dries on the
    iSCSI RFC.  However, removing one entire port from systems is a
    compelling argument for iSCSI in the long run.  To that end, the
    default target is a simple, familiar mechanism which will make that
    process easier.  Why?  Because although the rubber (dollars) really
    meets the road in this case when you have many servers, and a big
    network (and probably a complicated management infrastructure), a
    natural consequence will be that people will want to take those same
    components (off the shelf) and build small configurations, e.g. with a
    SINGLE server, and a SINGLE target and little or no management
    infrastructure.  Every large configuration begins as a small one.
    
    Steph
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:41 2001
6315 messages in chronological order