SAS SL_CC handling of CLOSE

Seto, Pak-lung pak-lung.seto at intel.com
Wed Apr 2 13:27:48 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Seto, Pak-lung" <pak-lung.seto at intel.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F95E.B58D17C0
Content-Type: text/plain;
	charset="iso-8859-1"

I like this choice to handle the CLOSE:
a) make SL_CC honor CLOSE during STP connections but ignore it during
SSP and SMP connections;
 
Pak
 

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Monday, March 31, 2003 8:44 PM
To: t10 at t10.org
Subject: SAS SL_CC handling of CLOSE



While connected, the SL_CC state machine currently only honors an
incoming CLOSE after the protocol-specific link layer (SSP, STP, or SMP)
has sent a Request Close message.  In SSP, Request Close is sent after
DONEs are exchanged.  In SMP, Request Close is sent after the RESPONSE
frame is transmitted.  No such time exists for STP and there is no way
to define when Request Close is needed.

This has a few problems:
1. There is no definition for when the STP link layer sends Request
Close, and in fact there is no time similar to SSP or STP where both
sides of a connection can expect the connection to be closed.  Either
side is allowed to request a close when the bus is idle (no R_RDY
granted).  One side's SL_CC can be waiting for its STP link layer to
signal Request Close when a CLOSE arrives.  Per the current standard, it
is supposed to ignore the CLOSE - definitely not the intention.  [this
is the issue prompting attention]

2. The XL state machine responds to CLOSE immediately; it has no
protocol-specific knowledge.  If a CLOSE shows up at the wrong time in
an SSP or SMP connection, the XL state machine starts closing down the
connection, but the SL_CC at the end of the connection ignores it.  This
eventually leads to 1 ms timeouts and BREAKs; it would be much cleaner
if SL_CC behaved the same as XL.

3. Scenarios that devolve into BREAKs mess up CLOSE (CLEAR AFFILIATION)
usage, since there is no BREAK (CLEAR AFFILIATION).


To solve this, we propose that SL_CC honor CLOSEs without waiting for
protocol-specific link layer permission.  This requires these changes:
1.  SL_CC honors CLOSE in the SL_CC3:Connected state.  If it sees CLOSE,
it transitions to a new state SL_CC7:Disconnect.

2. SL_CC7:Disconnect transmits a CLOSE and goes to SL_CC0:Idle.

3. Both SL_CC4:DisconnectWait and SL_CC7:Disconnect send Enable Disable
SSP (Disable), Enable Disable SMP (Disable), and Enable Disable STP
(Disable) messages to disable the protocol-specific link layers.
(rather than waiting for SL_CC0:Idle to do so).

Some other alternatives are:
a) make SL_CC honor CLOSE during STP connections but ignore it during
SSP and SMP connections; or
b) make the STP link layer detect CLOSE and send, in negative or zero
time, an Allow Close message to SL_CC so it also detects the CLOSE.


Specific wording:
7.14.4.5 SL_CC3:Connected state
7.14.4.5.1 State description
This state enables the SSP, STP, or SMP link layer state machine to
transmit dwords during a connection.
If this state is entered from SL_CC1:ArbSel state or the SL_CC2:Selected
state with an argument of Open
SMP Connection then this state shall send an Enable Disable SMP (Enable)
message to the SMP link layer
state machines (see 7.18.4).

If this state is entered from SL_CC1:ArbSel state or the SL_CC2:Selected
state with an argument of Open
SSP Connection then this state shall send an Enable Disable SSP (Enable)
message to the SSP link layer
state machines (see 7.16.7).

If this state is entered from SL_CC1:ArbSel state or the SL_CC2:Selected
state with an argument of Open
STP Connection then this state shall send an Enable Disable STP (Enable)
message to the STP link layer
state machines (see 7.17.7).

This state shall request idle dwords be transmitted by repeatedly
sending Transmit Idle Dword messages to
the SL transmitter until the SSP, SMP, or STP link layer state machine
starts transmitting.

7.14.4.5.2 Transition SL_CC3:Connected to SL_CC4:DisconnectWait
This transition shall occur if a Request Close message is received.

7.14.4.5.3 Transition SL_CC3:Connected to SL_CC5:BreakWait
This transition shall occur if a Request Break message is received and a
BREAK Received message has not
been received.

7.14.4.5.4 Transition SL_CC3:Connected to SL_CC6:Break
This transition shall occur if a BREAK Received message is received and
after sending a Connection Closed
(Break Received) confirmation to the port layer.

7.14.4.5.n Transition SL_CC3:Connected to SL_CC7:Disconnect [new]
This transition shall occur if a CLOSE Received message is received.


7.14.4.6 SL_CC4:DisconnectWait state
7.14.4.6.1 State description
This state closes the connection and releases all resources associated
with the connection.

[new paragraph:]
Upon entry to this state, this state shall send Enable Disable SSP
(Disable), Enable Disable SMP (Disable),
and Enable Disable STP (Disable) messages to the SSP, SMP, and STP link
layer state machines.

This state shall:
1) send a Transmit CLOSE (Normal) message or Transmit CLOSE (Clear
Affiliation) message to the SL transmitter;
2) send at least three Transmit Idle Dword messages to the SL
transmitter; and
3) initialize and start the Close Timeout timer.
A CLOSE Received message may be received at any time while in this
state.

7.14.4.6.2 Transition SL_CC4:DisconnectWait to SL_CC0:Idle
This transition shall occur after:
a) sending a Transmit CLOSE message to the SL transmitter;
b) receiving a CLOSE Received message; and
c) sending a Connection Closed (Normal) confirmation to the port layer.
[Editor's note: I hate these implied "shall send Connection Closed"
rules that are not directly stated, but leave them in this proposal.]

7.14.4.6.3 Transition SL_CC4:DisconnectWait to SL_CC5:BreakWait
This transition shall occur if:
a) a BREAK Received message has not been received;
b) no CLOSE Received message is received in response to a Transmit CLOSE
message before the Close Timeout timer expires; and
c) after sending a Connection Closed (Close Timeout) confirmation to the
port layer.

7.14.4.6.4 Transition SL_CC4:DisconnectWait to SL_CC6:Break
This transition shall occur after receiving a BREAK Received message and
after sending a Connection Closed
(Break Received) confirmation to the port layer.


7.14.4.n SL_CC7:Disconnect state [new section]
7.14.4.n.1 State description
This state closes the connection and releases all resources associated
with the connection.

Upon entry to this state, this state shall send Enable Disable SSP
(Disable), Enable Disable SMP (Disable),
and Enable Disable STP (Disable) messages to the SSP, SMP, and STP link
layer state machines.

This state shall:
1) send a Transmit CLOSE (Normal) message or Transmit CLOSE (Clear
Affiliation) message to the SL transmitter; and
2) send at least three Transmit Idle Dword messages to the SL
transmitter; and
3) send a Connection Closed (Normal) confirmation to the port layer.

7.14.4.n.2 Transition SL_CC4:Disconnect to SL_CC0:Idle
This transition shall occur after sending a Connection Closed (Normal)
confirmation.


--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
 <https://ecardfile.com/id/RobElliott>
https://ecardfile.com/id/RobElliott






------_=_NextPart_001_01C2F95E.B58D17C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 Message I like this choice to handle the CLOSE:
 a) make SL_CC honor CLOSE during STP connections but ignore it during SSP and SMP connections;
  
 Pak
  
 -----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Monday, March 31, 2003 8:44 PM
To: t10 at t10.org
Subject: SAS SL_CC handling of CLOSE


 While connected, the SL_CC state machine currently only honors an incoming CLOSE after the protocol-specific link layer (SSP, STP, or SMP) has sent a Request Close message.  In SSP, Request Close is sent after DONEs are exchanged.  In SMP, Request Close is sent after the RESPONSE frame is transmitted.  No such time exists for STP and there is no way to define when Request Close is needed.

This has a few problems:
1. There is no definition for when the STP link layer sends Request Close, and in fact there is no time similar to SSP or STP where both sides of a connection can expect the connection to be closed.  Either side is allowed to request a close when the bus is idle (no R_RDY granted).  One side's SL_CC can be waiting for its STP link layer to signal Request Close when a CLOSE arrives.  Per the current standard, it is supposed to ignore the CLOSE - definitely not the intention.  [this is the issue prompting attention] 2. The XL state machine responds to CLOSE immediately; it has no protocol-specific knowledge.  If a CLOSE shows up at the wrong time in an SSP or SMP connection, the XL state machine starts closing down the connection, but the SL_CC at the end of the connection ignores it.  This eventually leads to 1 ms timeouts and BREAKs; it would be much cleaner if SL_CC behaved the same as XL.

3. Scenarios that devolve into BREAKs mess up CLOSE (CLEAR AFFILIATION) usage, since there is no BREAK (CLEAR AFFILIATION).


To solve this, we propose that SL_CC honor CLOSEs without waiting for protocol-specific link layer permission.  This requires these changes:
1.  SL_CC honors CLOSE in the SL_CC3:Connected state.  If it sees CLOSE, it transitions to a new state SL_CC7:Disconnect.

2. SL_CC7:Disconnect transmits a CLOSE and goes to SL_CC0:Idle.

3. Both SL_CC4:DisconnectWait and SL_CC7:Disconnect send Enable Disable SSP (Disable), Enable Disable SMP (Disable), and Enable Disable STP (Disable) messages to disable the protocol-specific link layers.  (rather than waiting for SL_CC0:Idle to do so).

Some other alternatives are:
a) make SL_CC honor CLOSE during STP connections but ignore it during SSP and SMP connections; or
b) make the STP link layer detect CLOSE and send, in negative or zero time, an Allow Close message to SL_CC so it also detects the CLOSE.


Specific wording:
7.14.4.5 SL_CC3:Connected state
7.14.4.5.1 State description
This state enables the SSP, STP, or SMP link layer state machine to transmit dwords during a connection.
If this state is entered from SL_CC1:ArbSel state or the SL_CC2:Selected state with an argument of Open
SMP Connection then this state shall send an Enable Disable SMP (Enable) message to the SMP link layer
state machines (see 7.18.4).

If this state is entered from SL_CC1:ArbSel state or the SL_CC2:Selected state with an argument of Open
SSP Connection then this state shall send an Enable Disable SSP (Enable) message to the SSP link layer
state machines (see 7.16.7).

If this state is entered from SL_CC1:ArbSel state or the SL_CC2:Selected state with an argument of Open
STP Connection then this state shall send an Enable Disable STP (Enable) message to the STP link layer
state machines (see 7.17.7).

This state shall request idle dwords be transmitted by repeatedly sending Transmit Idle Dword messages to
the SL transmitter until the SSP, SMP, or STP link layer state machine starts transmitting.

7.14.4.5.2 Transition SL_CC3:Connected to SL_CC4:DisconnectWait
This transition shall occur if a Request Close message is received.

7.14.4.5.3 Transition SL_CC3:Connected to SL_CC5:BreakWait
This transition shall occur if a Request Break message is received and a BREAK Received message has not
been received.

7.14.4.5.4 Transition SL_CC3:Connected to SL_CC6:Break
This transition shall occur if a BREAK Received message is received and after sending a Connection Closed
(Break Received) confirmation to the port layer.

7.14.4.5.n Transition SL_CC3:Connected to SL_CC7:Disconnect [new]
This transition shall occur if a CLOSE Received message is received.


7.14.4.6 SL_CC4:DisconnectWait state
7.14.4.6.1 State description
This state closes the connection and releases all resources associated with the connection.

[new paragraph:]
Upon entry to this state, this state shall send Enable Disable SSP (Disable), Enable Disable SMP (Disable),
and Enable Disable STP (Disable) messages to the SSP, SMP, and STP link layer state machines.

This state shall:
1) send a Transmit CLOSE (Normal) message or Transmit CLOSE (Clear Affiliation) message to the SL transmitter;
2) send at least three Transmit Idle Dword messages to the SL transmitter; and
3) initialize and start the Close Timeout timer.
A CLOSE Received message may be received at any time while in this state.

7.14.4.6.2 Transition SL_CC4:DisconnectWait to SL_CC0:Idle
This transition shall occur after:
a) sending a Transmit CLOSE message to the SL transmitter;
b) receiving a CLOSE Received message; and
c) sending a Connection Closed (Normal) confirmation to the port layer.
[Editor's note: I hate these implied "shall send Connection Closed" rules that are not directly stated, but leave them in this proposal.]

7.14.4.6.3 Transition SL_CC4:DisconnectWait to SL_CC5:BreakWait
This transition shall occur if:
a) a BREAK Received message has not been received;
b) no CLOSE Received message is received in response to a Transmit CLOSE message before the Close Timeout timer expires; and
c) after sending a Connection Closed (Close Timeout) confirmation to the port layer.

7.14.4.6.4 Transition SL_CC4:DisconnectWait to SL_CC6:Break
This transition shall occur after receiving a BREAK Received message and after sending a Connection Closed
(Break Received) confirmation to the port layer.


7.14.4.n SL_CC7:Disconnect state [new section]
7.14.4.n.1 State description
This state closes the connection and releases all resources associated with the connection.

Upon entry to this state, this state shall send Enable Disable SSP (Disable), Enable Disable SMP (Disable),
and Enable Disable STP (Disable) messages to the SSP, SMP, and STP link layer state machines.

This state shall:
1) send a Transmit CLOSE (Normal) message or Transmit CLOSE (Clear Affiliation) message to the SL transmitter; and
2) send at least three Transmit Idle Dword messages to the SL transmitter; and
3) send a Connection Closed (Normal) confirmation to the port layer.

7.14.4.n.2 Transition SL_CC4:Disconnect to SL_CC0:Idle
This transition shall occur after sending a Connection Closed (Normal) confirmation.


--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott





------_=_NextPart_001_01C2F95E.B58D17C0--




More information about the T10 mailing list