Comments/Clarifications on sas1r03 SSP transport layer
ameen at cup.hp.com
Wed Mar 10 15:15:09 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* Ameen Rahman <ameen at cup.hp.com>
I have the following comments/clarifications on
SAS-1.1 Revision 3, Dated 24 Jan 2004
1) COMMAND frame - handling og link layer errors (Sec 188.8.131.52, Page 282)
The last sentence in this page is,
"An SSP initiator port should re-transmit each COMMAND frame that
does not receive an ACK ateast one time".
I think an SSP initiator port should retransmit only those COMMANDs
which were NOT delivered to the target port.
2) SSP frame format ( Sec 9.2.1, Page 270 )
This section doesn't explain the RETRY DATA FRAMES and CHANGING DATA
pointer fields of SSP frame header. Probably some text needs to be
added in this section to explain these fields.
Explanation for these fields can be found in later sections though.
3) SSP frame format ( Sec 9.2.1, Page 270 )
Explanation for RETRANSMIT bit from the standard:
"The RETRANSMIT bit is set to one for TASK frames, RESPONSE frames,
XFER_RDY frames under the conditions defined in FIXFIX and shall be
to zero for all other frame types. This bit indicates the frame is a
retransmission after the SSP target port failed in its previous
to transmit the frame"
a) In the above "FIXFIX" needs to be sustituted with relevant section
b) RETRANSMIT bit is also a indication of initiator port failed in
previous attempt to transmit a frame ( TASK frame )
4) TASK frame - handling of link layer errors ( Sec 184.108.40.206, Page 283 )
If a NAK is recieved for the TASK frame, what should be the action ?
Retry the TASK frame with RETRANSMIT bit set to 0 ??
5) XFER_RDY frame with transport layer re-tries ( Sec 220.127.116.11.3 , Page
When the target recieves NAK for a XFER_RDY, probably it should
not set RETRANSMIT bit to 1 in the retransmitted XFER_RDY.
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10