Comments/Clarifications on sas1r03 SSP transport layer
Elliott, Robert (Server Storage)
elliott at hp.com
Sat Mar 13 17:05:08 PST 2004
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <elliott at hp.com>
> * 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
> 220.127.116.11, 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.
It's just a "should." If it gets a NAK, it might try another target
port with access to that logical unit (perhaps using a different
initiator port altogether) if it has knows of one. Or, it might just
retry the command on the same I_T.
> 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.
The missing paragraphs from 03-186r5 will be included in sas1r04.
> 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,
> and XFER_RDY frames under the conditions defined in FIXFIX and shall
> be set to zero for all other frame types. This bit indicates the
> frame is a retransmission after the SSP target port failed in
> its previous attempt to transmit the frame"
> a) In the above "FIXFIX" needs to be sustituted with
> relevant section numbers.
Fixed in sas1r04.
> b) RETRANSMIT bit is also a indication of initiator port failed in
> its previous attempt to transmit a frame ( TASK frame )
Will remove "target" in sas1r04.
> 4) TASK frame - handling of link layer errors ( Sec 18.104.22.168,
> 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 ??
That's up to the initiator (same for COMMAND frames that are NAKed).
It knows the target didn't get it, so it can do whatever it wants.
a general rule that it should retransmit the frame at least once.
no requirement for the RETRANSMIT bit to be set to 1, though. That's
for ACK/NAK uncertainty. (see the application client error handling
> 5) XFER_RDY frame with transport layer re-tries ( Sec 22.214.171.124.3 , Page
> 283 )
> When the target recieves NAK for a XFER_RDY, probably it should
> not set RETRANSMIT bit to 1 in the retransmitted XFER_RDY.
The SAS WG discussed this and recommended keeping the RETRANSMIT
bit as 1 in this case to ease the job of logic analyzers and engineers
in the lab. As the editor's note says, it provides no benefit to
the initiator (since it sent a NAK and never saw the original frame).
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
* 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