RE: iSCSI: Async events - SCSI and iSCSI

[Robert Snively <rsnively@Brocade.COM>]

Folks,

I have not followed all that led up to this very carefully, but
in the SCSI space, we have been reasonably careful to
require that the initiator identify itself as capable of
receiving an asynchronous event.  In the iSCSI realm, you
can invent any kind of event structure you like, but it
would not involve logical units (except perhaps to indicate
that the configuration of logical units has changed and
needs to be investigated), since logical units are not
known to the iSCSI session.  In the SCSI realm, you have
to have a SAM-2 compliant mechanism to determine that there is
a process available to receive (or at least to reject
the exchange of) an asynchronous message.  In the
past, that has often been done by making the asynchronous message
a standard SCSI command, with the initiator taking on the
target role and in fact identifying itself as a willing
recipient.  

I would expect the same separation to be required here.
In particular, SCSI asynchronous events may need to be rejected,
while iSCSI asynchronous events shall always be accepted.

Bob

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Saturday, September 08, 2001 12:56 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: Async events - SCSI and iSCSI
> 
> 
> OK Mark - How about:
> 
> 1.1  Asynchronous Message
> 
>    An Asynchronous Message may be sent from the target to the 
> initiator
>    without corresponding to a particular command. The target 
> specifies the
>    status and reason for the event and sense data.
> 
> 
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|1|1| 0x32      |1| Reserved                                    |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved      | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN                                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16/ Reserved                                                      /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    24| StatSN                                                        |
>      +---------------+---------------+---------------+---------------+
>    28| ExpCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    32| MaxCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    36| AsyncEvent    | Reserved      | Parameter1 or Reserved        |
>      +---------------+---------------+---------------+---------------+
>    40| Parameter2 or Reserved        | Parameter3 or Reserved        |
>      +---------------+---------------+---------------+---------------+
>    44| Reserved                                                      |
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Sense Data or iSCSI Event Data                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
> 
> 
>    Some Asynchronous Messages are strictly related to iSCSI 
> while others
>    are related to SCSI [SAM2].
> 
>    Please note that StatSN counts this PDU as an 
> acknowledgeable event,
>    allowing initiator and target state synchronization.
> 
> 1.1.1     AsyncEvent
> 
>    The codes used for iSCSI Asynchronous Messages (Events) are:
> 
>       0    A SCSI Asynchronous Event is reported in the sense 
> data. Sense
>       Data that accompanies the report, in the data segment, 
> identifies the
>       condition. Sending of a SCSI Event (Asynchronous Event 
> Notification
>       in SCSI terminology) is controlled by a SCSI Control 
> Mode Page bit.
>       1    Target requests Logout. This Async Message MUST be 
> sent on the
>       same connection as the one being requested to be logged out.
>       Initiator MUST honor this request by issuing a Logout 
> as early as
>       possible, but no later than Parameter3 seconds.  
> Initiator MUST send
>       a Logout with a reason code of "Close the connection" to cleanly
>       shutdown the connection.  If the initiator does not Logout in
>       Parameter3 seconds, the target should send an Async PDU 
> with iSCSI
>       event code "Dropped the connection" if possible, or 
> simply terminate
>       the transport connection. Parameter1 and Parameter2 are 
> reserved.
>       2    Target indicates it will drop the connection.
>       The Parameter1 field indicates on what CID the connection will
>       dropped.
>       The Parameter2 field indicates, in seconds, the minimum 
> time to wait
>       before attempting to reconnect.
>       Parameter3 indicates the maximum time to reconnect 
> and/or restart
>       commands after the initial wait (Parameter2).
>       If the initiator does not attempt to reconnect and/or 
> restart the
>       outstanding commands, within the time specified by 
> Parameter3 or, if
>       Parameter3 is 0, the target will terminate all 
> outstanding commands
>       on this connection, no other responses should be 
> expected from the
>       target for the outstanding commands on this connection.
>       A value of 0 for Parameter2 indicates that reconnect 
> can be attempted
>       immediately.
>       3    Target indicates it will drop all the connections of this
>       session.
>       The Parameter2 field indicates, in seconds, the minimum 
> time to wait
>       before attempting to reconnect.
>       The Parameter3 field indicates the maximum time to reconnect and
>       restart commands after the initial wait (Parameter2).
>       If the initiator does not attempt to reconnect within the time
>       specified by Parameter 3 or, if Parameter 3 is 0, the session is
>       terminated. In this case, the target will terminate all 
> outstanding
>       commands in this session; no other responses should be 
> expected from
>       the target for the outstanding commands in this 
> session.  A value of
>       0 for Parameter2 indicates that reconnect can be attempted
>       immediately.
>       255 Vendor specific iSCSI Event - additional data MAY 
> accompany the
>       report.
> 
>    All other event codes are reserved.
> 
> 1.1.2     Sense Data or iSCSI Event Data
> 
>    For a SCSI Event this is the data that accompanies the 
> report, in the
>    data segment, identifies the condition.
> 
>    For an iSCSI Event additional data that MAY accompany the report
> 
> 
> Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 07-09-2001 18:54:22
> 
> Please respond to Mark Bakke <mbakke@cisco.com>
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> 
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI: Async events - SCSI and iSCSI
> 
> 
> 
> Julian-
> 
> I'd like to see them separate for two reasons:
> 
> - iSCSI and SCSI-level events are typically orthogonal, so they
>   probably won't usually end up being combined anyway.  It would
>   be simpler for both the target and the initiator to not attempt
>   to combine them.
> 
> - Since the SCSI-level events use the data portion of the message
>   for sense data, that leave iSCSI events without any way to send
>   data of their own if there is a possibility of combining the
>   two.  By keeping them separate, iSCSI could use the data portion
>   for text keys.  In fact, Parameters 1, 2, and 3 might have been
>   easier to describe had they been communicated using text keys;
>   the processing of async messages is not a performance-critical
>   thing anyway.
> 
> That's about it.  A target could send both in one message, but since
> the desire to do this is probably an end case (a small percentage
> of async messages might combine both), there's no reason why we
> can't just have the target send two messages, and we end up with
> a simpler, and for iSCSI events, more flexible, implementation for
> both the initiator and target.
> 
> Anyway, I think that if we are going for a clear separation between
> SCSI and iSCSI events, that it's even clearer if they are always
> sent in separate messages.
> 
> Thanks,
> 
> Mark
> 
> Julian Satran wrote:
> >
> > Mark,
> >
> > As far as I recall it is not by chance. When we decided to 
> go for a clear
> > separation of SCSI and iSCSI events
> > I saw no reason why a target will not want to send both, if 
> it had them,
> in
> > one message.
> > Is there something I am missing? Obviously this runs 
> against your later
> > request for text async messages.
> >
> > Julo
> >
> > Mark Bakke <mbakke@cisco.com>@ece.cmu.edu on 05-09-2001 23:09:12
> >
> > Please respond to Mark Bakke <mbakke@cisco.com>
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> > To:   IPS <ips@ece.cmu.edu>
> > cc:
> > Subject:  iSCSI: Async events - SCSI and iSCSI
> >
> > Julian-
> >
> > I was looking at Async Message some more, and noticed that there
> > is nothing to stop a target from sending a message that includes
> > both iSCSI and SCSI events, since each of these are communicated
> > with a different set of fields.  I would guess that this is not
> > what is intended, and that the target ought to send one or 
> the other.
> >
> > Can we add some text to say:
> >
> >    A target may send this message as either a SCSI Event or an
> >    iSCSI Event, but not both.  Either the SCSI Event or iSCSI
> >    Event field MUST be zero.
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
> 
> 
> 
>