The SMP target port actions in SAS expander.

Elliott, Robert (Server Storage) elliott at
Sat Mar 13 16:22:33 PST 2004

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert (Server Storage)" <elliott at>
> * From the T10 Reflector (t10 at, posted by:
> * Shinji Ugawa <ugawa-sxa at>
> *
> The SMP target port in SAS expander is an important unit 
> for the SMP functions processing (i.e. it processes the 
> PHY CONTROL function for any other PHYs in the expander).
> I thought that the expander should not hang its SMP target port.
> So, I have two questions about the SMP target port actions 
> in SAS expander device.
> /// Question-1. 
> What should the SMP target port do, if the SMP target port 
> never receives a SMP_REQUEST frame when that port has connected 
> with a SMP initiator port?
> // method-aa.
> The SMP target port is forever waiting to receive the 
> SMP_REQUEST frame or BREAK primitive from SMP initiator port.
> // method-bb. 
> When the SMP target port detects a timeout of any Time 
> Limit timer, it sends a BREAK primitive to SMP initiator port.
> But it is difficult to decide that an initial value of this 
> timer is dealt with any SAS domains.

All the standard provides for is to wait forever.  Any target-based
timeout is vendor-unique.  We discussed defining some sort of timeout 
in SAS-1, but T10 wanted to keep the expander simple and not require it
to police the initiators' activity.  There are plenty of other ways 
an initiator and target can hang the domain, e.g. just keep a connection

open forever.

Anyone is free to propose a timeout for SAS-1.1 or SAS-2.

> /// Question-2.
>   The SSP port discards a received frame which has illegal 
> SOF-EOF sequence, in SAS-1.1 spec And I thought that 
> the SMP target port should discard a received SMP_REQUEST frame 
> which has illegal SOF-EOF sequence.
>   Example-1.
>     1st. The SMP initiator port has transmitted a SMP_REQUEST 
> frame. Please refer to the figure below. The SMP target port 
> receives two SMP_REQUEST frames because the first idle dword 
> has changed to the SOF primitive for bit errors (i.e. The 
> SMP_REQUEST(BBB) is  incomplete for the targe port).
>               ------> time
>     initiator [idle dw][idle dw][idle dw][idle
>        target
> // method-aa.
> The SMP target port should process the complete SMP_REQUEST(AAA) 
> frame and it should discard the SMP_REQUEST(BBB) frame.
> // method-bb.
> The SMP target port should transmit a BREAK primitive for the 
> breaking a SMP connection when it has received the 
>     What do you think about both methods?

The SMP link layer doesn't say what to do, so a proposal will be 
needed if T10 wants to mandate one behavior or the other.

The target should never try to process BBB itself; it might try to
process a concatenation of BBB followed by AAA, which should result
in a CRC error.

>   Example-2.
>     I believe that the SMP initiator port transmits a single 
> SMP_REQUEST frame. What if the SMP target port has received double 
> SMP_REQUEST frames in once SMP connection by something accident?
>               ------> time
>        target
>     I thought that the SMP target port should be processing the first
>     SMP_REQUEST frame and it will discard the second SMP_REQUEST
>     Otherwise, the SMP target port should transmit a BREAK primitive 
>     for the breaking the SMP connection.

The SMP link and transport layers for the target ignore any 
additional frames that somehow show up, so only the 1st should be
There's no requirement that the target send a BREAK if it sees anything
but idle dwords after the EOF.

> -- Thanks
> Shinji Ugawa
> NEC System Technologies, Ltd.
>   External:(+81)89-947-7901

Rob Elliott, elliott at
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

More information about the T10 mailing list