SAS: Additional OPEN address frame received

George Penokie gop at us.ibm.com
Wed Sep 3 11:18:56 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <gop at us.ibm.com>
*
This is a multipart message in MIME format.
--=_alternative 0064808686256D96_=
Content-Type: text/plain; charset="us-ascii"


Jeff, 

I seem to be missing my main point which is 'it can't happen' unless you
have an illegal transmitting SL state machine AND an illegally operating
XL state machine. I see no point in attempting to define in the standard
third or fourth level error recovery scenarios. 

Your proposed solution requires the SL_RA state machine have knowledge
of which state the SL_CC is currently in. It has no such knowledge. 

And lastly, if everything is broken and a second OPEN address overwrites
OPEN address information how can you say the whether the first one or
the second one is the 'right' one with so many things broken to start
with?

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





	"Zheng, Jeff" <Jeff.Zheng at Emulex.Com> 


09/03/2003 12:18 PM 
        
        To:        George Penokie/Rochester/IBM at IBMUS 
        cc:        "'t10 at t10.org'" <t10 at t10.org> 
        Subject:        RE: SAS: Additional OPEN address frame received 





George, 
  
these are exact the cases I would like to discuss.  I realized that it's
much more difficult to define what is the "additional" OPEN address
frame than "additional" IDENTIFY address frame.  let me try to see if I
can distinguish this additional open frame based on the cases you
described as in your email.  see following. 
  
-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Wednesday, September 03, 2003 7:42 AM
To: Zheng, Jeff
Cc: t10 at t10.org
Subject: RE: SAS: Additional OPEN address frame received


Jeff, 

If you receive an OPEN address while in the ARBSEL state and it
overrides the OPEN address sent by the ARBSEL state then transitions to
the SELECTED state. Any other OPEN address received while in the ARBSEL
state is ignored. (See section 7.14.4.3 SL_CC1:ArbSel state). 
[Zheng, Jeff] there are two cases in ARBSEL state, a) received OPEN
address frame wins arbitration and state transitions to SELECTED state.
b) received OPEN address frame lose the arb and state stay in ARBSEL.
in case b) any subsequent OPEN address frames are still valid and will
be arbitrated if this actually can happen.   
to conclude, there is no OPEN frame received in ARBSEL state can be
consider as "additional" OPEN frame. 

If you receive an OPEN address while in the IDLE state there is a
transition to the SELECTED state. 
So there is no way to receive a "second" OPEN address while in either of
those two states. 

If a second OPEN address was somehow received while in the SELECTED
state it would be ignored because there is no OPEN received message set
to the SELECTED state. But by the time a second OPEN address was
received the SELECTED state would most likely have been exited to either
the CONNECTED state or the IDEL state. The CONNECTED state would handle
it by ignoring it and the IDEL state would handle like it always does. 
[Zheng, Jeff] in the SELECTED state, if for any reason (-this is not
normal), a second OPEN address frame received, although this state does
not care the OPEN received message, but on the receiver side,  either
this second OPEN frame will overwrite the first OPEN frame or we have
two OPEN frames sitting at the inbox.  in both case, it becomes a gray
area to choose the valid OPEN frame. I think we can define the OPEN
address frame received in SELECTED state as "additional" address frame.
and this frame should be ignored. 
  

But all that is moot because there is no legal way to get a second OPEN
address until the connection is established (i.e., in the CONNECT state)
because  the ARBSEL state (which is the only state that can send an OPEN
address) can only send one then has to wait for a response before
anything else can happen. And even if that fails the expander will not
see, and therefore not transmit, a second OPEN address because it is in
the XL1:Request_Path state that does not respond to OPEN address. 

It makes no difference whether you end up connecting using SSP, SMP, or
STP; SL and XL work the same during the establishment of the connection.


When in the CONNECTED state SMP works just like SSP in that it ignores
the SOAF and EOAF. (See section "7.18.4.2 SMP transmitter and receiver "
the last sentence). 

I don't know how STP works but it probably has the same kind of words
somewhere. 
[Zheng, Jeff] in the CONNECTED state, any OPEN address frame received
should be considerred as "additional" address frame, and it should be
ignored. 
  

[Zheng, Jeff] if you agree on above "additional" OPEN address frame
definition, we can add the following item d) in sas SL_RA 7.14.3 as we
qualify the OPEN address frame: 
  
"the state machine shall accept an address frame as a valid OPEN address
frame if: 
a) the ADDRESS FRAME TYPE field is set to OPEN; 
b) the number of data dwords between the SOAF and EOAF is 8; 
c) the CRC field contains a valid CRC; and 
d) the SL_CC state machine is not at SL_CC2:Selected state or
SL_CC3:Connected state. " 
  
will this proposal work?   
  
thanks, 
Jeff Zheng 
  
 
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




	"Zheng, Jeff" <Jeff.Zheng at Emulex.Com> 


09/02/2003 05:23 PM         
       To:        George Penokie/Rochester/IBM at IBMUS 
       cc:        t10 at t10.org 
       Subject:        RE: SAS: Additional OPEN address frame received 





George, 
 
I think the SSP section you referred does not have the case coverage as
general as the phrase we put it for the additional IDENTIFY frames.   
the SSP section only covers the case when SSP connection is opened, but
it does not cover what if SAS link is at SL_CC1:Arbsel or
SL_CC2:Selected or SMP/STP connections.   
 
Regards, 
Jeff 
 
-----Original Message-----
From: George Penokie [mailto:gop at us.ibm.com]
Sent: Tuesday, September 02, 2003 2:53 PM
To: Zheng, Jeff
Cc: t10 at t10.org
Subject: Re: SAS: Additional OPEN address frame received


Jeff, 

What you are suggesting is already in SAS. Look in section "7.16.7.2 SSP
transmitter and receiver". The last sentence states "The SSP receiver
shall ignore all other dwords.". If you look you will see the SOAF and
EOAF are not listed so they and all the DWORDs between them are ignored
after the connection has been established.

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



	"Zheng, Jeff" <Jeff.Zheng at emulex.com> 
Sent by: owner-t10 at t10.org 


09/02/2003 03:15 PM         
      To:        "T10 (E-mail)" <t10 at t10.org> 
      cc:        "Zheng, Jeff" <Jeff.Zheng at emulex.com> 
      Subject:        SAS: Additional OPEN address frame received 






* From the T10 Reflector (t10 at t10.org), posted by:
* "Zheng, Jeff" <Jeff.Zheng at Emulex.Com>
*

In sas spec. r05 pg179. it says,

" If a device receives an additional IDENTIFY address frames 
after the first one, without an intervening the phy reset 
sequence, it shall ignore the additional IDENTIFY address frame." 

I haven't seen the same clause in the sas spec for OPEN address frame.
for
whatever reason a device received an additional OPEN address frames in
sequence, should this  additional OPEN address frame case be covered by
the
spec too?  any reason we can not put the similar ignore clause on the
additional OPEN address frame as well?  

Regards,

Jeff Zheng
Emulex Corp.

*
* For T10 Reflector information, send a message with 
* 'info t10' (no quotes) in the message body to majordomo at t10.org






--=_alternative 0064808686256D96_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Jeff,</font>
<br>
<br><font size=2 face="sans-serif">I seem to be missing my main point which is 'it can't happen' unless you have an illegal transmitting SL state machine AND an illegally operating XL state machine. I see no point in attempting to define in the standard third or fourth level error recovery scenarios. </font>
<br>
<br><font size=2 face="sans-serif">Your proposed solution requires the SL_RA state machine have knowledge of which state the SL_CC is currently in. It has no such knowledge.</font>
<br>
<br><font size=2 face="sans-serif">And lastly, if everything is broken and a second OPEN address overwrites OPEN address information how can you say the whether the first one or the second one is the 'right' one with so many things broken to start with?<br>
<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Zheng, Jeff" <Jeff.Zheng at Emulex.Com&gt;</b></font>
<p><font size=1 face="sans-serif">09/03/2003 12:18 PM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;George Penokie/Rochester/IBM at IBMUS</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;"'t10 at t10.org'&quot; <t10 at t10.org&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: SAS: Additional OPEN address frame received</font>
<br></table>
<br>
<br>
<br><font size=2 color=blue face="Comic Sans MS">George, </font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS">these are exact the cases I would like to discuss. &nbsp;I realized that it's much more difficult to define what is the "additional" OPEN address frame than "additional" IDENTIFY address frame. &nbsp;let me try to see if I can distinguish this additional open frame based on the cases you described as in your email. &nbsp;see following.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2 face="Tahoma">-----Original Message-----<b><br>
From:</b> George Penokie [mailto:gop at us.ibm.com]<b><br>
Sent:</b> Wednesday, September 03, 2003 7:42 AM<b><br>
To:</b> Zheng, Jeff<b><br>
Cc:</b> t10 at t10.org<b><br>
Subject:</b> RE: SAS: Additional OPEN address frame received<br>
</font>
<br><font size=2 face="sans-serif"><br>
Jeff,</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
If you receive an OPEN address while in the ARBSEL state and it overrides the OPEN address sent by the ARBSEL state then transitions to the SELECTED state. Any other OPEN address received while in the ARBSEL state is ignored. (See section 7.14.4.3 SL_CC1:ArbSel state). </font>
<br><font size=2 color=blue face="Comic Sans MS">[Zheng, Jeff] there are two cases in ARBSEL state, a) received OPEN address frame wins arbitration and state transitions to SELECTED state. &nbsp;b) received OPEN address frame lose the arb and state stay in ARBSEL. &nbsp;in case b) any subsequent OPEN address frames are still valid and will be arbitrated if this actually can happen. &nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS">to conclude, there is no OPEN frame received in ARBSEL state can be consider as "additional" OPEN frame.</font>
<br><font size=2 face="sans-serif"><br>
If you receive an OPEN address while in the IDLE state there is a transition to the SELECTED state. <br>
So there is no way to receive a "second" OPEN address while in either of those two states.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
If a second OPEN address was somehow received while in the SELECTED state it would be ignored because there is no OPEN received message set to the SELECTED state. But by the time a second OPEN address was received the SELECTED state would most likely have been exited to either the CONNECTED state or the IDEL state. The CONNECTED state would handle it by ignoring it and the IDEL state would handle like it always does. </font>
<br><font size=2 color=blue face="Comic Sans MS">[Zheng, Jeff] in the SELECTED state, if for any reason (-this is not normal), a second OPEN address frame received, although this state does not care the OPEN received message, but on the receiver side, &nbsp;either this second OPEN frame will overwrite the first OPEN frame or we have two OPEN frames sitting at the inbox. &nbsp;in both case, it becomes a gray area to choose the valid OPEN frame. I think we can define the OPEN address frame received in SELECTED state as "additional" address frame. &nbsp;and this frame should be ignored. </font>
<br><font size=3>&nbsp;</font>
<br><font size=2 face="sans-serif"><br>
But all that is moot because there is no legal way to get a second OPEN address until the connection is established (i.e., in the CONNECT state) because &nbsp;the ARBSEL state (which is the only state that can send an OPEN address) can only send one then has to wait for a response before anything else can happen. And even if that fails the expander will not see, and therefore not transmit, a second OPEN address because it is in the XL1:Request_Path state that does not respond to OPEN address.</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
It makes no difference whether you end up connecting using SSP, SMP, or STP; SL and XL work the same during the establishment of the connection.</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
When in the CONNECTED state SMP works just like SSP in that it ignores the SOAF and EOAF. (See section "7.18.4.2 SMP transmitter and receiver " the last sentence).</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
I don't know how STP works but it probably has the same kind of words somewhere. </font>
<br><font size=2 color=blue face="Comic Sans MS">[Zheng, Jeff] in the CONNECTED state, any OPEN address frame received should be considerred as "additional" address frame, and it should be ignored. </font>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS"><br>
[Zheng, Jeff] if you agree on above "additional" OPEN address frame definition, we can add the following item d) in sas SL_RA 7.14.3 as we qualify the OPEN address frame: </font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS">"the state machine shall accept an address frame as a valid OPEN address frame if:</font>
<br><font size=2 color=blue face="Comic Sans MS">a) the ADDRESS FRAME TYPE field is set to OPEN;</font>
<br><font size=2 color=blue face="Comic Sans MS">b) the number of data dwords between the SOAF and EOAF is 8; </font>
<br><font size=2 color=blue face="Comic Sans MS">c) the CRC field contains a valid CRC; and </font>
<br><font size=2 color=blue face="Comic Sans MS">d) the SL_CC state machine is not at SL_CC2:Selected state or SL_CC3:Connected state. " </font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS">will this proposal work? &nbsp;</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS">thanks,</font>
<br><font size=2 color=blue face="Comic Sans MS">Jeff Zheng</font>
<br><font size=3 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">&nbsp;<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208<br>
External: 507-253-5208 &nbsp; FAX: 507-253-2880<br>
</font><font size=3><br>
<br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=2%>
<td width=39%><font size=1 face="sans-serif"><b>"Zheng, Jeff" <Jeff.Zheng at Emulex.Com&gt;</b></font><font size=3> </font>
<p><font size=1 face="sans-serif">09/02/2003 05:23 PM</font><font size=3> </font>
<td width=57%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;To: &nbsp; &nbsp; &nbsp; &nbsp;George Penokie/Rochester/IBM at IBMUS</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;cc: &nbsp; &nbsp; &nbsp; &nbsp;t10 at t10.org</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; &nbsp;Subject: &nbsp; &nbsp; &nbsp; &nbsp;RE: SAS: Additional OPEN address frame received</font><font size=3> </font></table>
<br><font size=3><br>
<br>
</font><font size=2 color=blue face="Comic Sans MS"><br>
George,</font><font size=3> <br>
 &nbsp;</font><font size=2 color=blue face="Comic Sans MS"><br>
I think the SSP section you referred does not have the case coverage as general as the phrase we put it for the additional IDENTIFY frames. &nbsp;</font><font size=3> </font><font size=2 color=blue face="Comic Sans MS"><br>
the SSP section only covers the case when SSP connection is opened, but it does not cover what if SAS link is at SL_CC1:Arbsel or SL_CC2:Selected or SMP/STP connections. &nbsp;</font><font size=3> <br>
 &nbsp;</font><font size=2 color=blue face="Comic Sans MS"><br>
Regards,</font><font size=3> </font><font size=2 color=blue face="Comic Sans MS"><br>
Jeff </font><font size=3><br>
 &nbsp;</font><font size=2 face="Tahoma"><br>
-----Original Message-----<b><br>
From:</b> George Penokie [mailto:gop at us.ibm.com]<b><br>
Sent:</b> Tuesday, September 02, 2003 2:53 PM<b><br>
To:</b> Zheng, Jeff<b><br>
Cc:</b> t10 at t10.org<b><br>
Subject:</b> Re: SAS: Additional OPEN address frame received</font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
<br>
Jeff,</font><font size=3> </font><font size=2 face="sans-serif"><br>
<br>
What you are suggesting is already in SAS. Look in section "7.16.7.2 SSP transmitter and receiver". The last sentence states "The SSP receiver shall ignore all other dwords.". If you look you will see the SOAF and EOAF are not listed so they and all the DWORDs between them are ignored after the connection has been established.<br>
<br>
Bye for now,<br>
George Penokie<br>
<br>
Dept 2C6 &nbsp;114-2 N212<br>
E-Mail: &nbsp; &nbsp;gop at us.ibm.com<br>
Internal: &nbsp;553-5208</font>
<br><font size=2 face="sans-serif">External: 507-253-5208 &nbsp; FAX: 507-253-2880</font><font size=3><br>
<br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=2%>
<td width=41%><font size=1 face="sans-serif"><b>"Zheng, Jeff" <Jeff.Zheng at emulex.com&gt;</b></font><font size=3> </font><font size=1 face="sans-serif"><br>
Sent by: owner-t10 at t10.org</font><font size=3> </font>
<p><font size=1 face="sans-serif">09/02/2003 03:15 PM</font><font size=3> </font>
<td width=56%><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;"T10 (E-mail)" <t10 at t10.org&gt;</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;"Zheng, Jeff" <Jeff.Zheng at emulex.com&gt;</font><font size=3> </font><font size=1 face="sans-serif"><br>
 &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;SAS: Additional OPEN address frame received</font><font size=3> </font></table>
<br><font size=3><br>
<br>
</font><font size=2 face="Courier New"><br>
<br>
* From the T10 Reflector (t10 at t10.org), posted by:<br>
* "Zheng, Jeff" <Jeff.Zheng at Emulex.Com&gt;<br>
*<br>
<br>
In sas spec. r05 pg179. it says,<br>
<br>
" If a device receives an additional IDENTIFY address frames <br>
after the first one, without an intervening the phy reset <br>
sequence, it shall ignore the additional IDENTIFY address frame." <br>
<br>
I haven't seen the same clause in the sas spec for OPEN address frame. &nbsp;for<br>
whatever reason a device received an additional OPEN address frames in<br>
sequence, should this &nbsp;additional OPEN address frame case be covered by the<br>
spec too? &nbsp;any reason we can not put the similar ignore clause on the<br>
additional OPEN address frame as well? &nbsp;<br>
<br>
Regards,<br>
<br>
Jeff Zheng<br>
Emulex Corp.<br>
<br>
*<br>
* For T10 Reflector information, send a message with</font><font size=3> </font><font size=2 face="Courier New"><br>
* 'info t10' (no quotes) in the message body to majordomo at t10.org</font><font size=3><br>
<br>
<br>
</font>
<br>
<br>
--=_alternative 0064808686256D96_=--




More information about the T10 mailing list