Subject: Re: iSCSI: Async events - SCSI and iSCSI

From: "Julian Satran" <[email-masked]>
Date: Tue, 11 Sep 2001 12:16:19 +0300

Mark,

Vendor specific is wide enough to accomodate both what you want (text) or
what some others might want
- a binary log, some traces etc.

How about the following:

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    | AsyncVCode    | 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. The AsyncVCode details the vendor
      code and data MAY accompany the report.

   All other event codes are reserved.

1.1.2     AsyncVCode

   AsyncVCode is a vendor specific detail code valid only if the AsyncEvent
   field indicates a vendor specific event. Otherwise it is reserved.

1.1.3     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 <[email-masked]>@cisco.com on 10-09-2001 16:40:39

Please respond to Mark Bakke <[email-masked]>

Sent by:  [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI: Async events - SCSI and iSCSI

Julian-

I like this one a lot better.  How about adding one more event:

4  Target is sending a vendor-specific event message.  The message
   and its parameters are indicated in the data segment as a series
   of text keys and values, in the same format used by the text
   commands and responses.

This would allow an initiator and target to negotiate the sending
of an implementation-specific (or experimental) async message,
without using reserved AsyncEvent values.

--
Mark

Julian Satran wrote:
>
> 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 <[email-masked]>@ece.cmu.edu on 07-09-2001 18:54:22
>
> Please respond to Mark Bakke <[email-masked]>
>
> Sent by:  [email-masked]
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> 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 <[email-masked]>@ece.cmu.edu on 05-09-2001 23:09:12
> >
> > Please respond to Mark Bakke <[email-masked]>
> >
> > Sent by:  [email-masked]
> >
> > To:   IPS <[email-masked]>
> > 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
> > [email-masked]
> > 763.398.1054
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Tue, 11 Sep 2001 08:12:30 -0500

Julian-

That looks great.

Thanks,

Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054