Re: Recovery and ERL=0

[Black_David@xxxxxxx]

Prafulla,

This discussion is about data digest errors only, as with a header
digest error, the PDU type may have been affected by the corruption.
 
Section 6.7 applies regardless of the error recovery level, but some
of the options are not available at error recovery level 0.  I believe
that what you describe is acceptable at error recovery level 0, but
note that the following additional text (from Section 6.7) applies to
data digest errors at the target:
 
  If the target chooses to implement this option, it MUST wait to
  receive all the data (signaled by a Data PDU with the final bit
  set for all outstanding R2Ts) before sending the response PDU.
  A task management command (such as an abort task) from the
  initiator during this wait may also conclude the task.

For the initiator, aborting the task affected by a data digest error
may involve sending a task management function to the target.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------

________________________________

	From: ips-bounces@xxxxxxxx [mailto:ips-bounces@xxxxxxxx] On
Behalf Of Deuskar, Prafulla
	Sent: Wednesday, February 13, 2008 1:03 PM
	To: ips@xxxxxxxx
	Subject:  Recovery and ERL=0
	
	

	With ERL=0 and Multiple Connections/Session what options does an
Initiator have for error recovery?

	Session recovery seems very heavy weight with MCS - Does section
6.7 in RFC only apply to within-a-command' or 'within-a-connection' data
recovery classes?

	 

	For ex: In case of digest error can I do the following and still
be considered compliant with RFC with ERL=0

	If it is an iSCSI data PDU with digest error - abort the task
and terminate the command with an error

	If it is an iSCSI response PDU with digest error - logout the
connection  (abort all commands associated with the connection)

	 

	Thanks,

	Prafulla

_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ips