SAS: Additional OPEN address frame received

Zheng, Jeff Jeff.Zheng at emulex.com
Wed Sep 3 10:18:13 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Zheng, Jeff" <Jeff.Zheng at Emulex.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_01C3723F.5B54DC20
Content-Type: text/plain

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






------_=_NextPart_001_01C3723F.5B54DC20
Content-Type: text/html

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

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





------_=_NextPart_001_01C3723F.5B54DC20--




More information about the T10 mailing list