SAS: Additional OPEN address frame received

George Penokie gop at us.ibm.com
Wed Sep 3 07:41:32 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 0050994686256D96_=
Content-Type: text/plain; charset="us-ascii"


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). 
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. 

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. 

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 0050994686256D96_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Jeff,</font>
<br>
<br><font size=2 face="sans-serif">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 face="sans-serif">If you receive an OPEN address while in the IDLE state there is a transition to the SELECTED state. </font>
<br><font size=2 face="sans-serif">So there is no way to receive a "second" OPEN address while in either of those two states.</font>
<br>
<br><font size=2 face="sans-serif">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>
<br><font size=2 face="sans-serif">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>
<br>
<br><font size=2 face="sans-serif">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>
<br><font size=2 face="sans-serif"><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>
<br>
<br><font size=2 face="sans-serif">I don't know how STP works but it probably has the same kind of words somewhere. </font>
<br><font size=2 face="sans-serif"><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/02/2003 05:23 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</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">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>
<br><font size=2 color=blue face="Comic Sans MS">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>
<br><font size=3>&nbsp;</font>
<br><font size=2 color=blue face="Comic Sans MS">Regards,</font>
<br><font size=2 color=blue face="Comic Sans MS">Jeff </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> 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<br>
</font>
<br><font size=2 face="sans-serif"><br>
Jeff,</font><font size=3> <br>
</font><font size=2 face="sans-serif"><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<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=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; &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; &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; &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>
* 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>
<br><font size=2 face="Courier New">* 'info t10' (no quotes) in the message body to majordomo at t10.org</font><font size=3><br>
<br>
</font>
<br>
<br>
--=_alternative 0050994686256D96_=--




More information about the T10 mailing list