SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Async events - SCSI and iSCSI



    
    Julian-
    
    That looks great.
    
    Thanks,
    
    Mark
    
    Julian Satran wrote:
    > 
    > 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 <mbakke@cisco.com>@cisco.com on 10-09-2001 16:40:39
    > 
    > Please respond to Mark Bakke <mbakke@cisco.com>
    > 
    > Sent by:  mbakke@cisco.com
    > 
    > To:   Julian Satran/Haifa/IBM@IBMIL
    > cc:   ips@ece.cmu.edu
    > 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 <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
    > 
    > --
    > Mark A. Bakke
    > Cisco Systems
    > mbakke@cisco.com
    > 763.398.1054
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

Last updated: Tue Sep 11 10:17:15 2001
6506 messages in chronological order