|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: Async events - SCSI and iSCSIJulian- 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 |