Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

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

On Thu, May 9, 2024 at 5:48 PM <mark.hamilton2152@xxxxxxxxx> wrote:

Thanks, Binita,

I was not aware that TGbe discussed this, already. Do you have any pointer to a submission or which meeting (so I can look at minutes, etc.)? Perhaps there are already decisions made/answers provided/direction decided, as you mention below.

Thanks! Mark

From: Binita Gupta <bingupta.ieee@xxxxxxxxx>
Sent: Thursday, 9 May, 2024 17:38
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Mark,

Thanks for your response. Agree with your feedback that RCM is for #1 point and IRM is really solving #2 point.

Also, I agree that the IRM which is provided during the 4-way handshake is for recognizing the non-AP MLD, not an affiliated STA of the non-AP MLD. The AP infrastructure will maintain the mapping of IRM identifier with the non-AP MLD device. When it gets a pre-assoc frame with that same IRM as TA it knows that the device is that specific non-AP MLD. Recognizing the device at the AP infra does not depend on getting that IRM in the ML element, and using in TA provides the flexibility to recognize any pre-assoc frame. With the TA approach, a non-AP MLD does not need to differentiate how it provides IRM to the network, in case of MLD vs non MLD frames, it is just sent as TA.

The topic of having more than one non-AP affiliated STA doing pre-assoc activity was discussed before in TGbe. Group aligned that only one IRM is sufficient for identification. Same IRM can be used by all affiliated STAs as TA if needed. I think it is also ok if the group prefers to assign multiple IRMs during 4-way handshake in case STA implementations require separate IRMs when doing pre-assoc activity in parallel, but we concluded otherwise in TGbe.

Even if IRM is provided in the ML element, there is still TA in the same frame that needs to be randomized for privacy, and it can as well provide IRM.

Imo there are two drawbacks of mandating that IRM must be sent in an ML element for MLD:
1) Limits the number of pre-assoc frames through which non-AP MLD can be recognized, since most pre-assoc frames don't contain ML element.
2) Forces STA and AP to implement two different ways to signal IRM (as TA and in ML element), which complicates the rules and implementation, without any gain. We could just support TA approach which works for both MLO and not MLO case.

Thanks,
Binita

On Thu, May 9, 2024 at 3:49 PM <mark.hamilton2152@xxxxxxxxx> wrote:
Binita,

A have some comments in response:

the purpose of IRM identifier is two fold:
1) to provide privacy to the STA using RCM, and …
I disagree. The purpose of randomizing a MAC Address (RCM) is provide privacy. The purpose of IRM (and Device ID) in 11bh is to solve your #2 point, given that the market is already using RCM.

and AP should be able to identify non-AP MLD in pre-assoc frames
Unfortunately, things are a bit more complicated, since several of the pre-assoc frame usage scenarios are not MLD-MLD interactions, but the AP MLD would still like to know the non-AP MLD’s identity.

. The simplest solution is to send IRM as TA in any pre-assoc frame (as done in baseline 11bh), basically port the 11bh solution as is for 11be.
Here is where the comment just above comes in, and things get more complicated. So, imagine the scenario: a non-AP MLD associates (MLD association) with an AP MLD, and during that association the “network” (i.e. the infrastructure northbound of the AP) becomes aware of the “real” identify of the non-AP MLD, for the use cases discussed in TGbh. The features of TGbh are designed to allow that non-AP device (I’ll use the term “device” loosely) to leave the ESS, and to come back some time in the future with all new MAC addresses, and be recognized by the network. So, we are likely identifying the non-AP MLD, and not any particular non-AP affiliated STAs. If some affiliated STA uses the IRM, pre-association, then what does the non-AP MLD use its MLD MAC Address? What if more than one non-AP affiliated STAs need/want to do pre-association activity? They can’t all use the same IRM… This just turns into a mess, of requiring much more complicated interaction between the MAC Addresses (TA) of _all_ the non-AP affiliated STAs, and the MLD Address.

Mark

From: Binita Gupta <bingupta.ieee@xxxxxxxxx>
Sent: Thursday, 9 May, 2024 14:55
To: mark.hamilton2152 <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Resending with correction. Thanks.

On Thu, May 9, 2024 at 1:52 PM Binita Gupta <bingupta.ieee@xxxxxxxxx> wrote:
Hi Mark, All,

As I understand, based on my reading of 11bh spec and offline discussions, the purpose of IRM identifier is two fold:
1) to provide privacy to the STA using RCM, and
2) for the AP to be able to recognize the STA when it comes back next time (if STA chooses to do so using IRM), in both pre-association and association signaling.

These requirements should be met for MLO too, and AP should be able to identify non-AP MLD in pre-assoc frames. The simplest solution is to send IRM as TA in any pre-assoc frame (as done in baseline 11bh), basically port the 11bh solution as is for 11be.

This way no need to change pre-assoc frames to add an ML element. Note that a Probe Request is link specific as defined in 11be. The IRM feature should not require changing MLO behavior and mandate that Probe Request be made MLD specific. 11be already defines an (ML) Probe Request for that. Also per 11be draft, a non-AP MLD can send either Probe Request or (ML) Probe Request pre-association and AP should be able to identify the non-AP MLD in both cases. Sending IRM as TA would accomplish that in the simplest way. Requiring STA to send IRM in TA for non-MLO and in ML element for MLO also complicates behavior at the STA and AP, and this can be totally avoided.

I also have the opinion that the simple and straightforward way to resolve this CID is to port what was done in 11bh for IRM. If the group can't align on that direction, then more discussion is needed either in 11bh, in 11be or both.

Thanks,
Binita

On Thu, May 9, 2024 at 8:18 AM mark.hamilton2152 <mark.hamilton2152@xxxxxxxxx> wrote:
Thanks, Mike.

I believe that affiliated STAs, when acting independently of their MLD (as seems to be the case for FTM), are just "STAs", so the existing 11bh facilities do cover them already, no change required.

Thus (for perhaps different reasons) I agree with Mike. We need to add the basic ML element to ML Probe Request and ANQP, and (so far) nothing else.

Mark

-------- Original message --------
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Date: 5/9/24 8:37 AM (GMT-07:00)
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi all,

I would expect that FTM would be link to link as well. Which means either IRM would need to be extended to cover affiliated STAs or FTM would need to be modified to support MLO. In my opinion, this issue goes beyond these comment resolutions.

So I suggest that Jay add the ML Probe Request frame to the list of frames in his contribution and we stop there.

Cheers,

Mike

On Thu, May 9, 2024 at 9:45 AM Jerome Henry <jhenry@xxxxxxxx> wrote:
Hey Mark,

I am by no mean an MLD expert, so this is just my reading. 35.3.14.1 says that some frames are intended for MLD-to-MLD exchanges, which FTM is not. So I make the same conclusion as you did, that FTM would be link-to-link, which is kinda logical, given that the range accuracy depends on link-specific factors like bandwidth etc... but an MLD-guru might find a contribution that clarified this point further, one way or the other.

Jerome

---- On Wed, 08 May 2024 22:04:26 -0400 Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote ---

Jerome,

Actually, are (public action) FTM frames in fact ever sent from MLD to MLD, or are they “link-specific”? I’m finding various exceptions for FTM frame in 11be (for example, 35.3.14 does not apply), but I’m having a hard time finding the text that therefore _does_ apply….

Mark

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Wednesday, 8 May, 2024 18:46
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Jerome,
I agree with Mark.
Do we really need to cover the identification on FTM frame without PASN ? Should we encourage FTM frame to be protected by PASN in Wi-Fi industry?
I agree it's quite a long and painful road to pick up all kinds of pre-association public action frames, and add Basic ML element to support IRM feature.
To make our job more efficiently, we may not cover some corner cases in this round, like identification FTM frame without PASN .

Thanks

Best Regards

Jay Yang (杨志杰)

Original
From: JeromeHenry <jhenry@xxxxxxxx>
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Date: 2024年05月09日 06:06
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD
Thank you Mark,

imho , redefining the baseline to set conditions as to when the STA should be able or allowed to use IRM is likely to be a long and painful road, we both know that it took hundreds of contributions and 2 years for 11bh to come up with the DeviceID and IRM schemes, each with its own properties. IRM allows the STA to be recognized upon next contact with the AP, at or before the assoc, and as the STA wishes. The MLO version should allow for the same properties in my view (no more, no less)...

My 2 cents

Jerome

---- On Wed, 08 May 2024 13:53:10 -0400 <mark.hamilton2152@xxxxxxxxx> wrote ---

Thanks, Jerome,

FTM is also an important use case.

That said, note that we do have STA identification carried in PASN negotiation frames. So, I think the question is what do we think about using FTM , without PASN (so no privacy protection), using MLO (and therefore an MLD address that wouldn’t be covered by the 802.11bh basic IRM mechanism), and with all that the client wanting to be identified? I can certainly see it could happen. But, I also wonder if this is getting way into a corner, and maybe not worth adding support directly in the FTM frames.

Mark

From: Jerome Henry <jhenry@xxxxxxxx>
Sent: Wednesday, 8 May, 2024 9:29
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Thank you Jay.

The goal of IRM is to allow the non-AP STA to be recognized at or before next association. So if the group decides that the right vehicle for the IRM is the ML element, then should we also make sure that the element is present in all pre-associaiton frames of interest (ANQP , as you mention, but also of course FTM )?

Jerome

---- On Wed, 08 May 2024 03:49:53 -0400 Jay Yang <yang.zhijie@xxxxxxxxxx> wrote ---

Hi Mark,

I quickly check the approved use cases tracking document in 11bh group (https://mentor.ieee.org/802.11/dcn/21/11-21-0332-37-00bh-issues-tracking.docx), Specially in subclause 4.1 Preassociation client steering(AP steering, band steering, network steering).
In the comment part, you marked up as a case to say "Need to consider Neighbor Report ANQP -element" based on the discussion from the group, I guess that's why in current11bh draft, we have the rule to say the IRM can be applied in public action frame.
Personally, I think there is a useful use case in Passpoint network(e.g. 3GPP and Wi-Fi hybrid network), if a STA roams from 3GPP network to Wi-Fi network, the STA may send a ANQP query frame, and the AP will respond with ANQP response frame including NR element. At this moment, based on 11bh identifier, the network can recommend the some serving AP/AP MLD list in NR element. To capture this, I add Basic ML element in Table 9-412—ANQP -element definitions. Please help review it.

Hi TGbe members,

I would like to remind you to help review this documents as well, based on the discussion and the new direction in this mail loop, I add Basic ML element in probe request and ANQP frame to support 11bh feature under MLO framework.

Welcome further comments.

Thanks

Best Regards

Jay Yang (杨志杰)

Original
From: MarkHamilton <mark.hamilton2152@xxxxxxxxx>
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Date: 2024年05月08日 05:33
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD
HI, Mike,

what is the point of band steering?
I didn’t mean band steering, but AP (that is, the device, not “IEEE AP”) steering. Plus, at least for the short term, we’re seeing a lot of MLD clients that don’t connect on all available bands, and we’d still need to be able to band steer them (perhaps?).

I'd be OK with adding Muti-Link Probe Request frames to the list of frames that could contain the IRM in the Basic Multi-Link element.
That seems like a big help. Good suggestion. Any other public action frames that we really need to round out the use cases? @Yang.zhijie@xxxxxxxxxx: Can you think of significant use cases that would still be missing?

Mark

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, 7 May, 2024 14:25
To: mark.hamilton2152@xxxxxxxxx
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Mark,

In my opinion, the features you are asking for go beyond the scope of the comments.

Even with 11bh with non-MLO , a STA is not required to active scan prior to selecting an AP.

Furthermore, if the device is multi-link (and likely multi-band) what is the point of band steering? You could use TTLM to steer traffic and possibly use link reconfiguration on BTM to steer traffic flow over multiple links.

In any case, a non-AP MLD can elect to do an ML Probe Request which includes an ML element. I'd be OK with adding Muti-Link Probe Request frames to the list of frames that could contain the IRM in the Basic Multi-Link element.

Cheers,

Mike

On Tue, May 7, 2024 at 1:01 PM <mark.hamilton2152@xxxxxxxxx> wrote:
Jay, all,

(NOT as chair, but my individual opinion …)

I know that I haven’t been very active in this discussion (apologies – too much stuff going on). However, I find abandoning any identification of an MLD device while it is pre-association to be too much loss of functionality to support.

This would eliminate:
Pre-association client steering
Which is extremely useful in enterprise and large venue installations
Customer support and troubleshooting
We are going to extreme lengths to solve the WPA3-Personal transition problems (yes, I know, that’s in WFA , but IEEE is talking about it, also) to help providers with support call overload, but we’re going to shoot ourselves in the foot by bringing back complete opaqueness in helping resolve “I can’t connect” issues?
Virtual BSSID
This is catching on as a very powerful tool in “multi-tenant” situations.
We could solve it by requiring an associated non-AP STA to use its same address (TA?) when scanning/probing for AP-AP handoffs , but I suspect the client devices are not going to want to do probes differently depending on context.

These are several of the important advantages that IRM has. We are balancing between two facilities (IRM and Device ID), each has its advantages and tradeoffs , making each useful in different scenarios. If we remove all pre-association support from IRM , in my opinion, we might as well remove IRM . It seems to me that rather than sort out how MAC addresses will be used for MLD devices, we are just “punting” and giving up on trying to solve the problem(s).

I would vote “no” on this direction.

Mark

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, 7 May, 2024 9:10
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 24/305--IRM solution for MLD

Hi Jay,

Thanks for producing this document. It looks good to me.

Cheers,

Mike

On Mon, May 6, 2024 at 9:53 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:
Hi All,

For 24/305, I received new comments from some members to say, as for the MAC address, the MLD MAC address rather than link MAC address is unique to identify each non-AP MLD . Based on that, in the latest revision 24/305r5, I change the place of IRM from TA field to ML element. Because some frames, like probe request, public action frame don't include ML element according to 11be baseline. I have to drop the relevent use cases in MLO subclause (Maybe these use case are not very strong in MLO senario ) . That's, non-AP MLD may set IRM in MLD MAC address field in basic ML element in authentication and association frame.
Besides, I have some offline checked with 11bh group members and the Chair Mark, they confirmed that the Reassocation case is out of 11bh scope, and 11bh group intends to git rid of them after initial SA ballot. To keep this align with the on-going 11bh draft, I change (Re)association to Association in all occurrences in new subclause .
This is all the change compared with 305r4 that we are ageed with, Welcome futher comments or thought on this.

Hi Alfred,

Could you help put 24/305r5 (https://mentor.ieee.org/802.11/dcn/24/11-24-0305-05-00be-cr-for-rcm-relevant-cids.docx ) to the MAC queue in F2F meeting?

Thanks

Best Regards

Jay Yang (杨志杰)

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

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