| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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? Best regards, Xiaofei Clement Wang Principal Engineer | InterDigital T: (631) 622.4028 From: Ganming (Ming) <ming.gan@xxxxxxxxxx> 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
->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
->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. Best wishes Ming Gan 发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
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>
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:
[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).
[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?
[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. 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:
[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. 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 |