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

Re: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

Hi Duncan,

 

Thanks for reviving the thread and for the updated figures. Yes, these seem more inline with your original slides (at least for option2). Few questions:

 

Option1:

In your slides (#7), the APs serving legacy STAs appear to be the same as the APs affiliated with the AP MLD (AP1, AP2). In your updated figures however, they appear to be independent APs (with different L2 AMC Addresses a5, a6). Or, did you mean that a1, a2, a3 can also serve legacy STAs? Figure shows legacy STAs associating with a5, a6 and not a1, a2. I thought Option 1 was about the SSID being the same on all links?

 

Option2:

I am supportive of option 2, I agree its good to be able to configure different SSIDs; however wanted to clarify few points:

1) If all links used the same parameters (SSID, security scheme etc.), would the MLOSSID still be required?

2) The legacy ssid6 seems to be served through the MLD MAC SAP? If so, why does ssid24 and ssid5 need to be served through different MAC SAPs? Or, the MAC SAP for ssid6 just not shown in the figure?

3) What are the assumptions for BSSIDs of each link? I assume they are same for both legacy and MLDs? If so, any thought on how the devices on a link handle broadcast traffic of different SSIDs? E.g. on the 2.4 link, legacy STAs (on ssid24) will also receive broadcast traffic for MLOSSID (encrypted with WPA3) and will not be able to decrypt them and vice-versa right?

4) Is it necessary to restrict the MLOSSID to be the same for all links of an AP MLD? E.g. any reason why a 4 link AP MLD, cannot advertise two different MLOSSID, say 1 (MLOSSID1:STAFF) for links 1, 2 and another (MLOSSID1:GUEST)  for links3, 4? The AP MLD could server 2-links non-AP MLDs on different SSIDs. This seems to be an unnecessary restriction at .11 level, forcing all links to operate with same security scheme etc. Wouldn’t this be better left to vendors to configure; .11 spec would only needs to provide the means to signal the SSIDs?

 

Regards,

Rojan

 

From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Thursday, July 23, 2020 5:29 AM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

Hi Rojan,

 

So sorry I missed your email till now and thought this thread went cold! Thanks for your questions and comments.

 

I think the previous diagrams may be too complicated and distracting. I’ve attached a much simpler example for option 2 and option 1, which hopefully will answer some of your questions too. Yes, I prefer option 2 since it’s more flexibility.

 

Hopefully we can revive this thread.

 

Thanks,

Duncan

 

From: rojan.chitrakar@xxxxxxxxxxxxxxxx <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Friday, June 19, 2020 10:57 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

CAUTION: This email originated from outside of the organization.

Hi Duncan,

 

Thanks for this, this figure is much clearer and is very helpful for discussions, to ensure we are on the same page.

 

I guess this figure is for the case with VAPs-option 1? (slide 8), but even then the scenario depicted are not exactly the same as in the slides. My original comments were more targeted for option 2 and the case without VAPs (Slide 7), do you have a similar figure for slide 7 & 9? I thought you were promoting Option 2 (btw I am supportive of the motivation behind it)?

 

On this figure, I think the case of the non-MLO guest device is the most interesting. Is this a legacy STA or a EHT STA? If it’s a EHT STA, how are legacy (pre-EHT) STAs served: all by a6 only?

About AP MLD2:

1) How are the SSIDs advertised, in this example I would think the legacy method is sufficient?

2) Does the non-MLO guest device also accesses the DS through the MAC-SAP2? Your answers to my earlier email seem to imply legacy STAs go through different MAC-SAPs.

 

Regards,

Rojan

 

From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Saturday, June 20, 2020 12:48 AM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

Hi Rojan,

 

Sorry about that. I’ve attached both the .vsd and jpg formats. Please let me know if you still have problems opening them.

 

Thanks,

Duncan

 

From: rojan.chitrakar@xxxxxxxxxxxxxxxx <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Thursday, June 18, 2020 8:00 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

CAUTION: This email originated from outside of the organization.

Hi Duncan,

 

Thanks. I am not able to open the attached image (perhaps I am using older version of visio). Could you resend in a different format: jpg or .vsd? Thanks.

 

Regards,

Rojan

 

From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Friday, June 19, 2020 7:17 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

Hi Rojan, Ming, Xiaofei, and Thomas,

 

Thanks for the discussion and I’ve attached a diagram for easier discussion. Please refer to it if it helps to illustrate your points. Please also see my response inline below.

 

From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, June 18, 2020 1:04 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

CAUTION: This email originated from outside of the organization.

>> we can leave SSID for operators

>> leave SSID setting to the network operator/user like today, not need to add the restriction to .11 spec

 

Could you guys please clarify what you mean by this? 

 

(1) Do we agree that, per the *current* standard, there is already a “restriction” that one BSS (which has a unique BSSID) has exactly one SSID?

 

[DH] Agree and that’s been my assumption.

 

(2) Is anyone proposing that it should be possible for one AP MLD to have more than one SSID (for MLD operation)? If so, why?

 

[DH] Second these questions.

 

(3) Is the discussion *only* about whether or not it should be possible for the BSSs that are affiliated with the same AP MLD to have different SSIDs (from each other, and/or from the AP MLD) for some kind of legacy purposes? 

 

[DH] Yes, that’s my goal here to focus on just this aspect first. Per people’s comment it seems there are different understanding even with pure green field MLO case (no legacy clients involved).

 

            - Related: Are there any use cases in which a non-AP STA that supports MLO would first want to associate to a single BSS without any MLD discovery/association, and then subsequently discover/associate to the MLD device?

 

[DH] Not that I’m aware of. In fact, the current MLO discovery design is trying to convey MLO info pre-assoc to give the client a choice.

 

-Thomas

 

On June 18, 2020 at 8:55:13 AM, Xiaofei Wang (xiaofei.wang@xxxxxxxxxxxxxxxx) wrote:

Hi Duncan,

 

Thank you for the presentation.

 

I agree somewhat with Ming and Rojan that we can leave SSID for operators.

 

Though I also see a good point in your presentation that a MLD should be clearly identified as such. I was wondering whether including the MLD address for all links of the MLD would be sufficient for this purpose?

[DH] I think that is a different issue. Here I’m trying to design how a non-AP MLD discovers an SSID to connect to. This SSID is “served” by an AP MLD.

 

Best regards,

 

Xiaofei Clement Wang

Principal Engineer | InterDigital

T: (631) 622.4028

E:  Xiaofei.wang@xxxxxxxxxxxxxxxx

 

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Thursday, June 18, 2020 10:24
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

Hello Duncan and Rojan

 

I agree with Rojan, for each AP in the AP MLD, we should leave SSID setting to the network operator/user like today, not need to add the restriction to .11 spec. They can be either different or same.

 

Thomas, feedback to your questions in the chat window

 

1.      I am not aware of any implementation where there is more than one SSID advertised/assigned to a single BSSID (??)

->correct, now each AP in an AP MLD has a unique BSSID, based on your awareness, it is reasonable to have a SSID per AP. Their SSID could be either same or different, depending on the network  operator/user

[DH] Please check my diagram. I don’t see how an MLD can advertise different SSID values on its APs.

2.      @Ming, one example (not the only one, by far) - you do SAE auth with an MLD MAC and derive pwd-seed as follows - which SSID do you use? If the two peers don't use the same value it fails. pwd-seed = HKDF-Extract(ssid, password [|| identifier])

->It is a professional example, I am not good at this security. Could more than one SSID be mapped to one pwd? As I know, it can be done today. When the STA does SAE with one AP in a MLD, it could use the SSID of this AP, is there any issue? Aha, I would like to learn it from you.

[DH] Even WPA2, the SSID and password are used to generate the PMK between the AP MLD and the non-AP MLD.

 

Best wishes

Ming Gan

 

发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
发送时间: 2020年6月18日 10:45
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

Hi Duncan,

 

Thank you for initiating this conversation, I couldn’t ask my question during the call yesterday. Today, SSID is a parameter that is decided by the network operator/User based on the usage scenario. My opinion is that we should continue this philosophy and not add restrictions in the .11 specification on how the SSIDs are assigned. The MLD framework should be flexible enough to accommodate different deployment scenarios. I have some further comments/questions inline in blue.

 

Regards,

Rojan

 

From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Thursday, June 18, 2020 2:00 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on MLO SSID - 0443r1

 

Hi all,

 

Thanks for all the comments and discussion regarding this contribution today. Based on the webex chat and comments, seems there are some fundamental issues we may need to resolve first before discussing the options.

[RC]: Totally agree that we should resolve the fundamental issues before discussing specific solutions.

 

I’ve listed my assumptions and rationale below. Please let me know your thoughts.

 

Assumption 1: MAC-SAP <-> AP MLD addr <-> AP MLD <-> mlo_ssid are all one-to-one mapped

Rationale:

  • Today, a BSSID can only be configured a single SSID and one set of authentication methods associated with it.

[RC]: Older APs did support multiple SSIDs/BSSID, but agree that it increases broadcast traffic in a BSS. The motivation for one to one SSID to BSSID mapping was primarily to reduce the broadcast traffic. What’s your assumption about BSSID for multi-link, is it per link, or do you also assume a MLO BSSID? If it is per link, your proposal actually brings back the issue of mixed broadcast traffic in a BSS. Taking your example in option2 (slide 7), since the MLO_SSID is overlaid in both links, in each link there will be broadcast traffics for both legacy SSIDs as well as MLD_SSID. If the same per-link BSSID is used in the broadcast frames, it will cause STAs to unnecessarily receive broadcast traffic not intended for them (which will likely fail due to wrong GTK).

[DH] Please check if my diagram clears up the above.

  • Traffic of two different SSIDs should not be mixed together in a single MAC-SAP. The AP device naturally uses different MAC-SAPs to separate the traffic of different SSIDs (e.g., home traffic vs guest traffic).

[RC]: I guess you are saying different IP addresses are assigned for different SSIDs, but I think there could be other methods to map upper layer traffic to SSIDs. E.g. for virtual LANs, SSIDs can be mapped to VLAN IDs; or socket/port based solutions can be used. Q: btw, what’s your assumption for legacy AP MAC-SAP? Is it different from the MLD MAC-SAP or is it the same?  

[DH] To me, the MAC-SAP is similar to the legacy AP MAC-SAP, except that the AP MLD has multiple APs “connected” to the MAC-SAP.

  • The AP MLD address will be used for MLO security key generation (along with the non-AP MLD address) and the AP MLD has a common security association that applies to all the links of the AP MLD.

[RC]: Yes, but we did agree that different links have different GTKs, so even with the same SA different SSIDs can still have different GTKs (of course PTKs are always different).

Assumption 2: a user (MLO or not) looks for a specific (single) SSID to connect to and inputs the credential corresponding to the SSID. i.e., a user has no control of which specific BSSID the client should connect to (it’s a client’s decision). Therefore, the mlo_ssid will need to be exposed to the user via scanning.

Rationale: preserve the existing Wi-Fi connection user experience (connect to a specific SSID displayed by scan result using the corresponding credential).

[RC]: That means the network has one more name. e.g. say you already have a “family” SSID and a “guest” SSID on 5 GHz and 2.4GHz respectively. Now you are saying that there will be one more “family_MLO” SSID running over both 5GHz and 2.4GHz and specifically caters to the family’s MLO devices right? So essentially the “family_MLO” SSID is overlaid on the 2.4GHz link (and also the 5GHz link). Even for this example, for discovery, each AP could advertise the same “family_MLO” SSID e.g. in the MLO RNR element (it already has the compressed SSID field), or the MLA element can carry SSID, and a client can easily figure out that this is a MLO SSID. I fail to see why the MLO SSID has to be signaled in a special way. This way, we can achieve this usage scenario (single MLO SSID over all links), but it also allows SSIDs to be different for links if the deployment chooses.

 [DH] Your example is NOT something I would recommend because it will be very confusing if my family members see TWO SSIDs with “family…” in them. They will not know which one to connect to. A more practical example would be “IoT” SSID on 2.4, “guest” SSID on 5GHz, and “Family” SSID on the AP MLD (2.4+5).

We can further discuss how to convey the “Family” SSID. One way is like my diagram shows using M-BSSID set.

Assumption 3: Most AP vendors provide an App to configure the AP. By default the App can set up a single SSID value for a network created by the user (e.g., home_ssid). For more advanced users, the App can provide an option to configure extra legacy SSIDs per band

Rationale:

  • Most users will be happy with a single SSID (per network created).
  • However, some advanced users may want separate legacy SSIDs so they can control which BSSID each legacy client connects to. It is also desirable not to force the user to re-onboard all the legacy clients (e.g., IoT devices) to the new mlo_ssid.

[RC]: Agree that it is useful to have different SSIDs, but I disagree that a MLO level SSID should be mandated. Lets say for enterprise networks, you have 2 exiting VLANs on your wired network: VLAN1 for staff and VLAN2 for guests, and 2 legacy BSSs with SSIDs: “STAFF” and “GUEST” that maps to VLAN1 and VLAN2 respectively. Now if the network operator wants to deploy a new AP MLD, how does the VLAN maps to the MLO_SSID? Does a new VLAN needs to  be added just to cater to this new SSID? I think a easier solution is to use the exiting VLAN mapping and let the AP MLD use the same SSIDs, but the SSID is mapped to multiple links for MLDs.

 [DH] I think the point is an AP MLD should have a single SSID associated with it. The non-AP MLD will request such SSID when associating with the AP MLD. In your VLAN example above, I would create two AP MLDs, one for “Staff” and another for “Guest”, and they will be connected to VLAN1 and VLAN2, respectively.

Thanks,

Duncan

 

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