SAS SL_CC missing a Connection Closed (Break Received)

George Penokie gop at us.ibm.com
Wed Apr 30 06:46:46 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*




Rob,
OK, I agree it's not a good idea to tell the port layer something has
happened before it really has happened. But I still do not believe your
solution is a good one. See my comments below.

Bye for now,
George Penokie

Dept 2C6  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880




                                                                                                                                       
                      "Elliott, Robert                                                                                                 
                      (Server Storage)"        To:       George Penokie/Rochester/IBM at IBMUS, <t10 at t10.org>                             
                      <Elliott at hp.com>         cc:                                                                                     
                                               Subject:  RE: SAS SL_CC missing a Connection Closed (Break Received)                    
                      04/29/2003 05:11                                                                                                 
                      PM                                                                                                               
                                                                                                                                       
                                                                                                                                       





> -----Original Message-----
> From: George Penokie [mailto:gop at us.ibm.com]
> Sent: Tuesday, April 29, 2003 4:20 PM
> Subject: Re: SAS SL_CC missing a Connection Closed (Break Received)
>
> Rob,
> You are correct that there is a problem but the solution you
> propose would result in multiple notifications to the port
> layer that a connection has closed or conflicting
> notifications indicating that the connection has failed to
> open and was then closed. The correct place to fix this is in
> section 7.14.4.5.3.
>
> Change from:
> 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.
>
> To:
> 7.14.4.5.3 Transition SL_CC3:Connected to SL_CC5:BreakWait
> This transition shall occur if:
> a) a Request Break message is received;
> b) a BREAK Received message has not been received; and
> c) after sending a Connection Closed (Break Received)
> confirmation to the port layer
>
> Bye for now,
> George Penokie
>
> Dept 2C6  114-2 N212
> E-Mail:    gop at us.ibm.com
> Internal:  553-5208
> External: 507-253-5208   FAX: 507-253-2880


That change would send Connection Closed (Break Received) before a BREAK
really
is received, and ends up sending two confirmations in case of a Break
Timeout (the false Break Received, followed by a truthful Break
Timeout).

These are the state machine paths through BreakWait and the
confirmations
that could be sent if the confirmation is added to the Connected state:

|from ArbSel (sent OPEN):
             Open Failed (Port Layer Request or Open Timeout Occurred or
Break Received)
             then, if appropriate, Connection Closed (Break Timeout)

|from Connected (from an established connection):
             >>> Connection Closed (Break Received) <<<
             then, if appropriate, Connection Closed (Break Timeout)

|from DisconnectWait (sent CLOSE, timed out):
             Connection Closed (Close Timeout)
             then, if appropriate, Connection Closed (Break Timeout)

<<GOP - In all of the cases above the second confirmation only occurs if
there is an error. The error being that there was no response to the BREAK
when there should have been. With the suggested change there would always
be a second confirmation. So you have taken an error case response and made
it the normal operation. That is what I object to. For example with this
change the port layer will always get both an Open Failed and a Connection
Closed instead of just an Open Failed and hardly ever getting the
Connection Closed.

So the only solution I see is to place a conditional statement into the
BreakWait state so that only if it is entered from the Connected state will
it send the Connection Closed (Break Received) if a BREAK Received message
is received before the timeout occurs. >>

Making DisconnectWait the state that issues exactly one of them yields
this set:

|from ArbSel (sent OPEN):
             Open Failed (Port Layer Request or Open Timeout Occurred or
Break Received)
             >> then, Connection Closed (Break Received) or Connection
Closed
(Break Timeout) <<

|from Connected (from an established connection):
             >> Connection Closed (Break Received) or Connection Closed
(Break Timeout) <<

|from DisconnectWait (sent CLOSE, timed out):
             Connection Closed (Close Timeout)
             >> then, Connection Closed (Break Received) or Connection
Closed
(Break Timeout) <<


> From: Rob Elliott
> ...
> If the protocol-specific link layer (SSP or SMP) sends
> Transmit Break to SL_CC, SL_CC leaves the Connected state and
> goes to the BreakWait state . This state sends a BREAK and
> waits for one in reply.  SL_CC then goes to idle when either
> a BREAK arrives in reply, or the Break Timeout timer expires.
>
>
> If the timer expires, Connection Closed (Break Timeout) is
> sent up to the port layer (see the SL_CC5:BreakWait to
> SL_CC0:Idle text).
>
>
> If a BREAK arrives, however, no Connection Closed is ever
> sent up to the port layer.  I think Connection Closed (Break
> Received) needs to be sent.
>
>
> Change:
> "
> 7.14.4.7.2 Transition SL_CC5:BreakWait to SL_CC0:Idle
> This transition shall occur after receiving a BREAK Received
> message or if the Break Timeout timer expires. If a BREAK
> Received message is not received before the Break Timeout
> timer expires, this state shall send a Connection Closed
> (Break Timeout) confirmation to the port layer before making
> this transition."
>
>
> to:
> "
> 7.14.4.7.2 Transition SL_CC5:BreakWait to SL_CC0:Idle
> This transition shall occur after receiving a BREAK Received
> message or if the Break Timeout timer expires. If a BREAK
> Received message is not received before the Break Timeout
> timer expires, this state shall send a Connection Closed
> (Break Timeout) confirmation to the port layer before making
> this transition. <<If a BREAK Received message is received,
> this state shall send a Connection Closed (Break Received)
> confirmation to the port layer before making this transition.>>"
> --
> Rob Elliott, elliott at hp.com
> Hewlett-Packard Industry Standard Server Storage Advanced
> Technology https://ecardfile.com/id/RobElliott



*
* 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 mailing list