Re: iSCSI-related conclusions from Orlando interim Meeting

[julian_satran@il.ibm.com]

Santosh,

We have discussed the things at some length with Ralph Weber.  As I
explained in my previous note we use the Asynch Message both to convey to
the initiator iSCSI messages and SCSI messages.
the target is supposed to behave and stop sending events that the iSCSI
initiator should pop up to
the SCSI layer. An iSCSI initiator may fileter (check for compliance) SCSI
messages but it is NOT REQUIRED to do so (in order to do this it will have
to have knowledge of the SCSI state).

iSCSI has no provision to stop async messages.

All those are (except the names) already in the current draft (and some
before).

I am reluctant to consider any procedure that originates a command at the
target.

Note however that a target in trouble may drop a TCP connection and force
an initiator to recover.

Julo

Santosh Rao <santoshr@cup.hp.com> on 21/01/2001 21:21:46

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI-related conclusions from Orlando interim Meeting




Julian,

ON AER, SAM-2 states that :

"Each SCSI Protocol shall describe a mechanism for Asynchronous Event
Reporting, including a procedure whereby a SCSI device can selectively
enable or disable asynchronous event reports from being sent to it by a
specific target." (5.7.4.1)

From your response, it sounds like iSCSI intends to describe an
AER mechanism, but not define a procedure that allows initiators to
selectively enable or disable it. Is this in line with SAM ?

On the subject of Async Message "Target requests a logout", which is a
ping-pong procedure to achieve a logout, it may be worth considering an
alternate Async Message in its place that indicates "Target is logging out
for error recovery" and allow the target to follow up the Async Message
with a connection close.

This will simplify target driven connection level error recovery.

Regards,
Santosh

>
> Santosh,
>
> The answer is in the current draft.   AEN (newly renamed Asynch Messages)
> can have an iSCSI origin or a SCSI origin.
> SCSI can control only the SCSI reporting.  iSCSI initiators are supposed
to
> accept always iSCSI Asynch Messages. Well behaved targets are not
supposed
> to send SCSI messages when forbiden by SCSI.  The iSCSI initiator is not
> mandated to check conformance to the above rule.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 20/01/2001 03:49:30
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   Black_David@emc.com, Julian Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI-related conclusions from Orlando interim Meeting
>
>
>
>
> All,
>
> I have raised this question on the reflector earlier without getting any
> response.
>
> If the target's only means for a logout is to "request a logout" through
an
> AEN
> (now called Asynch Message) and host SCSI stacks disable AER by default
> (which
> is the behaviour today), then, targets DO NOT have a reliable means of
> logging
> initiators out, since they cannot send AE messages.
>
> Targets MUST be allowed to send logouts or another reliable means be
> defined in
> the spec that allow targets to logout initiators. This peer-to-peer model
> [wherein a target can originate logout] is not a violation of SAM and
> allowing
> targets to send logouts is the most expeditious form of error recovery at
> the
> target end.
>
> Such a peer-to-peer model will also rid the spec of its convoluted way of
> using
> NOP-IN [which is a NOP response] as a NOP request when targets wish to
> check
> the  connection.
>
> Targets MUST be allowed to originate Logout and NOP-OUT.
>
> Regards,
> Santosh
>
> Black_David@emc.com wrote:
>
> > - "AER" is used only for SCSI
>
> > - iSCSI communication of asynchronous events is through a
> > mechanism that is now called "Asynchronous Messages" - iSCSI
> > uses these to implement AER
>
> >  - If a SCSI initiator has disabled AER, iSCSI does not send
> > the corresponding Asynchronous Messages
>
>  - santoshr.vcf
>
>
>
>


--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
#################################