Re: [STDS-802-11-TGBE] Discussions on tentative reassociation

["Yang, Zhijie (NSB - CN/Shanghai)" <zhijie.yang@xxxxxxxxxxxxxxx>]

Hi Guogang,

 

Thanks for your explain, the below question is clear now.

 

Per we talked through WeChat, I think there are still two issues on your proposal.

1. For the fast transmission case(802.11R roaming), how STA indicate that AC need to waiting for the BA process completed and then receive the STA-AP mapping signaling used to switch traffic on the targeting AP? As you know, AC takes part in the process of 802.11r roaming, and AC will switch the traffic to the target AP automatically once the STA completes the reassociation process with target AP.

 

2. For non-802.11R roaming between two ESS case, you want to use different SSIDs to distinguish the different ESS, so that STA knows whether to set up DHCP process to obtain IP address for different ESS roaming. I’m afraid it’s not a common method in WIFI industry.

 

I think your proposal can get more support from other experts if it can fix the above two issues.

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: 2020年8月3日 17:06
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] [STDS-802-11-TGBE] 答复: Discussions on tentative reassociation

 

Hi Jay yang,

 

If the following is right: STA-AP routing may switch back to the current AP if the link is still alive, this will break the principle.

 

At any given instant, a STA is associated with no more than one AP. This allows the DS to determine a unique answer to the question, “Which AP is serving STA X?”

 

 

Regards

Guogang Huang

Huawei Technologies Co.,Ltd.

 

发件人: huangguogang [mailto:huangguogang1@xxxxxxxxxx]
发送时间: 2020年8月3日 16:59
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] 答复: Discussions on tentative reassociation

 

Hi Jay Yang,

 

I check with our product-line guys. And their understanding is the same with me.  For the sentence “This primitive is generated by an AP or mesh gate to update the DS’s STA-to-AP map or mesh STA-to-mesh gate map”, it means that:

For the infrastructure BSS, this primitive is generated by an AP to update the DS’s STA-to-AP map; For the mesh network, this primitive is generated by mesh gate to update the mesh STA-to-mesh gate map.

 

For the specific implement, maybe the AP sends the DS-STA-NOTIFY.request to AC to update the STA-AP mapping info.

 

FYI.  

mesh gate: Any entity that has a mesh station (STA) function and a distribution system access function

(DSAF) to provide access to a single distribution system for the mesh basic service set (MBSS).

 

 

Regards

Guogang Huang

Huawei Technologies Co.,Ltd.

 

发件人: Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
发送时间: 2020年8月2日 7:31
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussions on tentative reassociation

 

Hi Guogang,

 

See my short comment inline. We could do detail talk on it on the next Monday.

 

Thanks

 

Best Regards

 

Jay Yang

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: 2020年7月30日 22:57
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: Discussions on tentative reassociation

 

Thanks for discussion. Please see my quick response inline.

 

发件人: Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
发送时间: 2020年7月30日 21:39
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: Discussions on tentative reassociation

 

Hi Guogang,

 

There are two mainly issues on your proposal, one is on STA side, as you confirmed, STA need to keep two copies of AP info, Key info and so on, it will be more complicated compared to current design.

[Guogang Huang] The current Spec. has allowed that the STA maintains key info with multiple AP. Please see the 12.6.10.2

On the other hand, it not allowed to set up two links with ESS through two different APs(current and target AP) in current design. Because it will cause a lot of management issue if ESS system found the STA archor on two different APs.  We may let the current AP sent deauth/disconnect to the STAs if found the STA set up another link with target AP.

[Guogang Huang] set up two links? You mean that the STA cannot associate with two Aps simultaneously., right? Yes, I totally agree that the STA only can associate with only one AP. In other words, this require that the STA-AP mapping is unique for DS. But this doesn’t means that the STA cannot negotiate with two Aps using management frames, rather that data frames.

<Jay 8-2> From the SPEC description, I understand that STA can cache multi KEY-info with multi APs, but it doesn’t mean STA can install these pre-authentication KEY-info into HW and use them to encrypt/decrypt MGMT frame with multi AP at the same time.

 

Successful completion of EAP authentication over IEEE Std 802.1X establishes a PMKSA at the

Supplicant. The Authenticator has the PMKSA when the AS completes the authentication, passes the keying

information (the master session key (MSK), a portion of which is the PMK) to the Authenticator, and the

Authenticator creates a PMKSA using the PMK. The PMKSA is inserted into the PMKSA cache. Therefore,

if the Supplicant and Authenticator lose synchronization with respect to the PMKSA, the 4-way handshake

fails. In such circumstances, dot11RSNA4WayHandshakeFailures shall be incremented.

A Supplicant may initiate preauthentication with any AP within its present ESS with preauthentication

enabled regardless of whether the targeted AP is within radio range.

 

 

On the other hand, both current AP and target AP will have the STA’s data structure in MAC layer in this moment. That’s to say, MLD STA may have two links with the mesh network(or ESS system) in model 1, it will bring a lot of management issues from the system perspective.

[Guogang Huang] After the target AP MLD sends DS-STA-NOTIFY.request primitive to DS, the DS will deliver the MSDU addressed to this non-AP MLD to the target AP MLD, rather than the current AP MLD. Because the STA-AP routing info is updated.

à<Jay> No, not such a simple logic as you said, STA-AP routing may switch back to the current AP if the link is still alive.

[Guogang Huang]why the non-AP MLD may switch back to the current AP? When the target AP MLD sends the DS-STA-NOTIFY.request with Type of MOVE to the DS, the STA-AP routing info is updated. You can see 7.2.3.2 Rmd3.0

à<Jay-8-2> For the case in model1, I think the primitive of STA-to-AP map is generated by mesh gate, not single AP.   AC/ gate way controls and selects the serving AP, STA need give the gate a clear signal if it wants to archor at the target AP.

 

7.2.3.2.3 When generated

This primitive is generated by an AP or mesh gate to update the DS’s STA-to-AP map or mesh STA-tomesh

gate map.

7.2.3.2.4 Effect of receipt

When generated by an AP, this primitive updates the DS’s STA-to-AP map, which controls to which AP the

DS delivers MAC service tuples that are destined for a given STA.

When generated by a mesh gate, this primitive updates the DS’s mesh STA-to-mesh gate map, which

controls to which mesh gate the DS delivers MAC service tuples that are destined for a given mesh STA.

The mesh STA-to-mesh gate map can be incomplete.

There are many mechanisms to implement this mapping update for the cases of ADD and MOVE. One

example mechanism, in the case where the DS is an IEEE 802 LAN, is to use an IEEE 802.2™ XID null

frame.

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: 2020年7月30日 9:44
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: Discussions on tentative reassociation

 

Hi Jay Yang,

 

Thank you for your discussion. Please see the response inline. If you have further comments or questions, please let me know.

 

 

Regards

Guogang Huang

Huawei Technologies Co.,Ltd.

 

发件人: Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
发送时间: 2020年7月30日 7:05
收件人: huangguogang <huangguogang1@xxxxxxxxxx>
主题: RE: Discussions on tentative reassociation

 

Hi Guanggang,

 

There are mainly two different roaming models, I don’t know which one you prefer in your contribution.

 

                                         

 

[Guogang Huang] I only consider the Model 1 in my contribution.

 

 

In Slide 6:

 

Then the STA can negotiate with the new AP to set up the correct conditions for data connectivity, while still using the old AP for data connectivity

 

I remember 11be STA can’t set up connection with two different MLD APs at the same time, I’m afraid your thought will beak this principle.  

 

[Guogang Huang] The reason that the STA only can associate with one AP is that the DS need to know “which AP is serving this STA”.  The answer to this question needs to be unique. When successfully exchanging Association Request/Response with Status code SUCCESS, the AP will send DS-STA-NOTIFY.request primitive to the DS. If the target AP doesn’t send this primitive to the DS, the STA still associate with the current AP. Because the STA-AP routing info isn’t updated. I also mentioned it in slide 4.

 

In Silde 14.

 

From the diagram, I guess it’s not 11R fast roaming case since I see 4-way handshake happened with the target AP MLD. Correct?

[Guogang Huang] Yes, it is the BSS transition using PMK caching, rather than  fast BSS transition. The fast BSS transition is shown in slide 15.

 

In this case, STA need to keep two copies of PTK,GTK and even IP address with two different MLD APs. IP address is not always the same especially in model2.

[Guogang Huang] Yes, the STA can maintain two copies of PTK and GTK. For the Model 1 mentioned, I’m pretty sure that the IP Address will not changed. Otherwise, all the upper layer connections need to be re-setup.

 

 I think your proposal is to get more DL traffic from current AP MLD, how do you consider the UL traffic in this moment?  It’s too complicated on STA side compared to current design.

[Guogang Huang] Note that the STA cannot receive DL traffic from the current AP MLD and transmit the uplink traffic to the target AP MLD simultaneously. What I mean is that after the STA sends a frame to trigger AP to send DS-STA-NOTIFY.request primitive, the data connection will completely switch from the current AP MLD to the target AP MLD. I think you misunderstood my proposal.

 

On the other hand, both current AP and target AP will have the STA’s data structure in MAC layer in this moment. That’s to say, MLD STA may have two links with the mesh network(or ESS system) in model 1, it will bring a lot of management issues from the system perspective.

[Guogang Huang] After the target AP MLD sends DS-STA-NOTIFY.request primitive to DS, the DS will deliver the MSDU addressed to this non-AP MLD to the target AP MLD, rather than the current AP MLD. Because the STA-AP routing info is updated.

 

I also mentioned that traffic switch issue in the call. For model 1, It’s necessary to give the AC a clear signal of the archor AP of the STA so that the AC knows which ethernet port is used for the DL traffic delivery for STA.  What’s your opinion in the two links case?

[Guogang Huang] The non-collocated MLD is pretty complicated. I didn’t touch this topic.

 

 

 

Note: Two links case diagram as bellow, it doesn’t mean STA MLD have two links with same AP MLD.

 

 

 

Thanks

 

Best Regards

 

Jay Yang

 

From: huangguogang <huangguogang1@xxxxxxxxxx>
Sent: 2020年7月30日 0:31
To: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Subject: Discussions on tentative reassociation

 

Hi Zhijie Yang,

 

Thank you for your comments. Maybe I miss something during the call. If you have comments or questions, please send email to me.

 

 

Regards

Guogang Huang

 

 

---

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

---

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

---

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1