Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 11-20/1554 ML reconfiguration

Hi Rojan and Jarkko,

 

From the following text, we can see that the Reassociation Request/Response frame is encrypted.

 

 

Regards

Guogang Huang

 

发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
发送时间: 2021年2月5日 11:29
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-20/1554 ML reconfiguration

 

Hi Guogang,

 

Thanks for your comments.

 

If (Re)association request frame can be made robust (i.e. protected), I believe we can surely consider it. However the main point as Payam also mentioned in his original email is that the existing association/authentication states should be preserved. Usage of (Re)association request frame (or any other frames) should not cause any changes/disruption in the ongoing connections in non-related links.

 

Anyway, signaling is next step detail that we can discuss once we agree on the high level concept of ML reconfiguration. Do let us know if you have concerns/comments that we can address on the concept itself.

 

Btw, my understanding is that currently in FBT, reassociation frames are only authenticated (using the MIC in FTE) but not encrypted.

 

Regards,

Rojan

 

From: Jarkko Kneckt <00000d5619618f4f-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, February 5, 2021 5:16 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-20/1554 ML reconfiguration

 

Hi Guagang,

 

               I wish the (Re)-association frames would be protected.

 

               In the current definition for robust Management frames 802.1md D5.0 has the following clause:

 

               Typically a STA has not established its PTK when it associates. 

               The STA will run 4-way handshake after it has associated. During the 4-way handshake the STA will create PTK. This may be the reason why the association frames are not encrypted. 

 

               Cheers,

               Jarkko 

 

              

 

On Feb 4, 2021, at 03:58, huangguogang <huangguogang1@xxxxxxxxxx> wrote:

 

Hi Payam，

 

In Fast BSS transition protocol, the Reassociation Request/Response is encrypted using PTK. And In my understanding, the management frame (including Reassociation Request/Response) will be encrypted when the Management Frame Protection bit within RSN Capability is set to 0.

 

 

Regards

Guogang Huang

 

发件人: Payam Torab [mailto:torab@xxxxxxxx] 
发送时间: 2021年2月4日 8:23
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-20/1554 ML reconfiguration

 

Hello all, we will try to run the 1554 straw polls soon, including re-running SP1.

 

Authors strongly believe 1554 straw polls define essential tools in MLO architecture to add and remove links to non-AP MLDs, and to add and remove AP STAs on AP MLD side, post association, and without losing connection (without disassociation and re-association).

 

Please do reach out if you have any questions – I think the deck has answered a few questions, a short recap below. Thank you.

 

·       Is link add/remove the same as link enable/disable?

No. Link add is to add a new link post association, something that did not exist at association time (and therefore cannot be enabled). Link remove purges the link from all IEs, management too (clean up).

 

·       Relationship to TID-to-link mapping

Generally unrelated, sitting at two hierarchy levels. To have TID continuity however, operationally (don’t have to), it make sense to re-map/re-route TIDs away from a link that is about to be deleted (make before break). In addition some clean/simple rules to define what if this is not done (not hard to imagine).

 

·       Can we use association/reassociation frames to signal these

We should not. Associated/authenticated state allows confidentiality and link set level changes do not need to be visible for discovery. Adding and removing new STAs (e.g., AP STA added to MLD AP) obviously has to be visible depending on the intention. 

 

From: Payam Torab <torab@xxxxxxxx>
Date: Wednesday, January 20, 2021 at 5:25 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>, Arik Klein <arik.klein@xxxxxxxxxx>
Subject: Re: 11-20/1554 ML reconfiguration

Clarification below in red. Thanks.

 

From: Payam Torab <torab@xxxxxxxx>
Date: Wednesday, January 20, 2021 at 5:00 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>, Arik Klein <arik.klein@xxxxxxxxxx>
Subject: Re: 11-20/1554 ML reconfiguration

Hi all,

 

I uploaded a modified SP3 (below) to better gauge the group interest in the case of AP MLD requesting a client to delete one of its links to the AP MLD. Specifically, the “Yes” option has been split into AP recommending only (client can decline), or AP recommending as well as notifying (which the client cannot decline).

 

My own position is the first option in the straw poll below (i.e., what we had before, original SP3) - BSS optimization and traffic engineering need network-level knowledge and AP involvement, and we can think of additional conditions later in the text that could help establish trust in the AP operation (a simple one Tomo pointed to for example is the AP not to the delete the last link standing in a link set).

 

Please review and form an opinion for a possible straw poll in TGbe MAC call tomorrow/Thursday.

 

Thanks,
Payam

 

-----

 

  • [SP3] Do you agree to add to TGbe SFD in R1, a mechanism for an AP MLD to request an associated non-AP MLD to remove a link to the AP MLD, subject to the following,

 

    • Request in the form of a recommendation, which the non-AP MLD may reject, or a  mandate (notification, pointing to a future removal time), which the non-AP MLD cannot reject

 

Note: AP MLD practically can stop serving a non-AP MLD on a given MLO link; the mandate option (notification pointing to future removal time) aims to make the transition smooth by making the non-AP MLD aware of the impending link removal. This is similar in nature to the “Disassociation Imminent” indication in the BTM Request frame.

 

    • Yes, with request as recommendation (non-AP can decline) or notification (non-AP cannot decline)
    • Yes, with request as recommendation only (non-AP can decline)
    • No (AP may not send a request to remove a link)
    • Abstain

 

 

From: Payam Torab <torab@xxxxxxxx>
Date: Monday, January 18, 2021 at 12:39 PM
To: Arik Klein <arik.klein@xxxxxxxxxx>, STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: 11-20/1554 ML reconfiguration

Hi Arik, some of your comments are not aligned with 802.1 operation and ecosystem. What you see is a baseline formulated by AP and non-AP community. I would hope that you can support this baseline and then separately propose additional pieces that you see fit.

 

Regards,

Payam

 

From: Arik Klein <arik.klein@xxxxxxxxxx>
Date: Sunday, January 17, 2021 at 4:31 AM
To: Payam Torab <torab@xxxxxxxx>, STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: RE: 11-20/1554 ML reconfiguration

Hi Payam,

 

See my further comments inline

 

Regards,

Arik

 

From: Payam Torab <torab@xxxxxxxx> 
Sent: יום ו 15 ינואר 2021 01:50
To: Arik Klein <arik.klein@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: 11-20/1554 ML reconfiguration

 

Hi Arik,

 

If a non-AP tells AP it doesn’t want a link (from the MLO link set that it set up during association), for any reason, it’s free money (resource) returned to AP with no fight. Non-AP shouldn’t ask for this if it has any intention of using that link again, but if it does, well, it doesn’t want it. Smaller IEs, fewer transmissions, coming with no arbitration.

 

Please note the concept of “link” applies to non-AP/client. Cases designated as AP-initiated are in the form of request to non-AP to add/remove its link. On the AP MLD side, it can add and remove AP STAs serving the whole network. With that said,

 

-          AP asking non-AP to add a link: Non-AP can reject, may be costly or any other reason

-          AP asking non-AP to remove a link (in the context of network wide optimization for example): Non-AP can reject (I want to keep the 6 GHz I was given)

[Arik Klein] I think that from system-wise perspective, such a “claim” that the non-AP STA is entitled to reject the AP MLD request to remove a link just because this resource has already been allocated for it is inefficient. I think the AP MLD has much broader perspective for the needs of all non-AP MLDs (due to dynamic changes in the traffic / network conditions), thus its request to remove a link with a specific non-AP MLD shall no be rejected (at least as long as we requires the AP MLD not to reject similar request from the non-AP MLD) 

-          AP indicating to non-AP a link will not be there soon (because corresponding AP STA is going away, shutting down etc., similar to BTM disassociation imminent): This is a courtesy call similar to channel switch announcement

[Arik Klein] Agree with your point, but why shouldn’t it be “reciprocal” i.e. the non-AP MLD shall have courtesy indication for the time that the link will be removed (as an option)? 
In any case this “courtesy indication” is unicast and not broadcast (as CSA), so it can be applied by both sides….

 

Regards,

Payam

 

From: Arik Klein <arik.klein@xxxxxxxxxx>
Date: Thursday, January 14, 2021 at 8:58 AM
To: Payam Torab <torab@xxxxxxxx>, STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: RE: 11-20/1554 ML reconfiguration

Hi Payam,

 

Thanks for sharing the presentation.

 

I have questions regarding proposed SP1 and SP3

 

In the proposed Straw Poll 1, when the non-AP MLD requests the associated AP MLD to remove a link – the AP MLD can’t reject this request.

 

On the contrary, in proposed Straw Poll 3, when the AP MLD requests the associated non-AP MLD to remove a link you propose either of 2 options:

  • Option 1: this request is considered as a recommendation and the non-AP MLD can reject it.
  • Option 2: this request is mandatory and includes notification for the time that the link will actually be removed (and the non-AP can’t reject it).

 

My questions are:

  • If we take Option 1 (of SP3): can you explain the difference why the AP MLD can’t reject the request of the associated non-AP MLD, while the non-AP MLD can reject the request of the AP MLD?
  • If we take Option 2 (of SP3): why the proposed notification pointing to a future removal time can’t be applied for the case of link removal in SP 1 (i.e. when the non-AP MLD requests a link removal from the AP MLD)??  

 

Thanks for the swift reply.

 

Regards,

Arik

 

From: Payam Torab <torab@xxxxxxxx> 
Sent: יום ד 13 ינואר 2021 21:11
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-20/1554 ML reconfiguration

 

Hello all, we will likely have time in our next MAC call to run straw polls for the ML reconfiguration topic I presented today. It would be nice if you could share your comments and questions here.

 

Regards,

Payam

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

 

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