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



    
    
    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
    
    
    
    


Home

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