Hi Abhi,
Thanks for the suggestion.
I would suggest to also add APs (non-MLD) that serve legacy STAs to the figure, similar to what Mike had on slide#18 as well as the corresponding description.
Regards,
Rojan
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Thursday, March 31, 2022 2:29 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
Hi Mike, All,
We had a good discussion on SSID topic during today’s call.
There were some suggestions on the Webex chat that the spec should provide some guidance on how an AP can advertise multiple SSIDs (by setting up virtual APs – i.e., multiple BSSID or co-hosted BSSID set).
Looking thru the spec, I felt that the easiest change could be to update Figure AA-7 in Annex AA to explain how this would work. I would like to get your inputs on updating figure AA7 as shown below (i.e., adds SSID for each AP and shows
connection to DS from each MLD). The descriptive text related to this figure can be updated to say that APs belonging to the same MLD have the same SSID and are all connect to the same DS via the MAC-SAP of the corresponding AP MLD.
Additional thoughts/suggestions are welcome.
Regards,
Abhi
From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, March 23, 2022 3:41 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
In addition to the security concern Thomas addressed below, there is a question of what IEEE Std 802 calls the “access domain”. In particular for broadcast traffic, this is important as the boundary of what MAC entities can directly communicate
with each other at the MAC level. (And, as has been pointed out, VLANs add another layer of separation, also.)
The architectural concepts are that traffic that gets onto a given DS is delivered to all (appropriate) APs that are attached to that DS. In the case of group-addressed traffic, that generally means all the APs, and for individually addressed
traffic it is the AP that has that destination MAC address associated to it. The ESS (the set of APs attached to a given DS) is defined to be this domain for 802.11.
Yes, this is all logical. In the real-world, the DS is not an isolated physical network, and there are often multiple logical DSs running across the same links, within the same LAN. But, the implementation of the DS manages this, and
keeps the traffic separated. If we suddenly allow multiple ESSs (multiple SSIDs) on the same DS, the DS implementations will not know how to keep this straight, and we’ll start mixing traffic. This extends, by the way, to the BSS(s) of the multiple logical
APs (within a single physical AP) that are keeping the traffic separated over-the-air. Each of those logical APs has its own BSSID, and distinct SSID, to deliver traffic only to the non-AP STAs that are associated with that logical AP.
Mark
From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, March 23, 2022 10:45 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
To my understanding, same GTK is used on a given link for both legacy STAs and 11be MLD STAs. So if the parallel stacks can interface with different DSs/ESSs, group addressed MSDUs from one DS/ESS could be decrypted by STAs in the other
DS/ESS, which should not be possible since they are generally separate security domains.
I think there would also be other issues to solve such as discovery (advertisement of multiple SSIDs supported by a given BSSID, etc).
I’m not really sure what problem is trying to be solved here anyway. As Mike pointed out, logically the AP “device” can support multiple SSIDs using multiple virtual AP and MLD stacks just like it does today. These are logical concepts
and do not imply anything about actual implementation complexity.
Thanks
Thomas
On Mar 23, 2022 at 6:33:48 AM, Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Given that each AP affiliated with AP MLD needs to interact with non-EHT STA by using legacy routing way, isn’t parallel upper MAC sublayers reasonable? As you said before, in theory the SSID could be different too in this case. I agree with this point.
If going to different SSIDs, you mentioned security impact. Could you provide more detail? You know, DS is an abstract concept.
发件人: Thomas Derham [mailto:00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2022年3月23日 4:33
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
Thanks Mark for the nice description and references, and also for confirmation that the (MLD upper MAC and legacy AP upper MAC) approach is expected to be the formal reference model.
As you point out, assuming the DS connectivity model shown in Figure 7-2, the model is immaterial to the discussion below because, in either case, all the upper stacks’ DSAFs interface with the same DS, and therefore need to use the same SSID.
I would also note that, even if (hypothetically) Figure 7-2 were to be modified to allow a legacy AP upper MAC to interface with a different DS compared to the MLD upper MAC, a number of other topics would arise - such as security impact of the same (per link) GTK being used for MSDUs to/from multiple DSs.
Thanks
Thomas
On Mar 21, 2022 at 6:05:46 PM, mark.hamilton2152@xxxxxxxxx wrote:
Thomas/all,
I bit of background/status from ARC, since you asked. 😊
ARC did discuss what we believe is the model for an AP MLD when communicating with a “legacy” (non-EHT) non-AP STA. The results can be found in 11-21/1111r9. Note that after off-line discussions with TGbe members that asked to be included in this topic, I have updated to 11-21/1111r10 (https://mentor.ieee.org/802.11/dcn/21/11-21-1111-10-00be-mld-architecture-part-2.docx), and this is still ongoing (no consensus, yet, and no review by TGbe, yet). However, the point you’re asking: what is the structure for the upper MAC sublayer when interacting with a non-EHT non-AP STA, I think there is agreement on the general approach (someone will jump in and correct me if I’m wrong about that, I’m sure).
A new figure, 4-30c is introduced, which shows that there are parallel upper MAC sublayers which handle such associations/communications, and form the upper part of the affiliated APs. A new Figure 7-2 shows the relationship to the DS (and thereby the ESS) and the SAPs. Note that the MLD AP and the affiliated APs all share the same DS, and thus the same ESS, and thus the same SSID.
Mark
From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, March 21, 2022 11:28 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
It’s clear to me from subclause 4.9.5 that an MLD has a single MAC SAP, and therefore interfaces with a single DS. Therefore, following the logic that Abhi explains, a given AP MLD has a single SSID.
What is perhaps less clear (not sure if it came up in the ARC discussions?) is the model for when an AP MLD (or just the APs?) interacts with non-EHT non-AP STAs.
For example, when an HE non-AP STA associates with a EHT AP, it’s not obvious (to me) from the reference diagrams whether the “MLD Upper MAC sublayer” (figure 4-30b and figure 5-2a) assumes the functionality of the “upper part” of a “regular” AP (i.e. everything above “Duplicate Detection” in figure 5-1), or whether the EHT AP actually has a parallel “upper” stack for handling non-MLD / non-EHT STAs.
If the former, then clearly the same MAC-SAP is used for all non-AP MLDs and non-AP STAs, so the same SSID applies to all of them.
If the latter, then theoretically the non-EHT STAs could access a different MAC-SAP compared to the EHT non-AP MLDs, and so I suppose in theory the SSID could be different too, although I don’t think the rest of the MLO design anticipates that possibility.
Thanks
Thomas
On Mar 20, 2022 at 7:50:25 PM, Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx> wrote:
Hi Abhi,
Thank you for initiating the thread and your detailed description of various terminologies, much appreciated. While I certaintly understand the value of having a single SSID at the MLD level; the thing that is still not clear, to me, and I believe to many other folks, is why this has to be mandated. Requiring multiple MLDs to support mutliple SSIDs, while certainly doable, appears too complicated.
During the call, Mike said he would be requesting agenda time for 21/209; it would be helpful to discuss this topic at the time rather than through emails. Mike, is that still the plan?
Regards,
Rojan
From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Sunday, March 20, 2022 1:41 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
Hi Rojan, All,
I am initiating this email thread to make progress on resolving CIDs 6725, 4036, 4919 and 6876
As I explained during the call, the relationship between SSID, ESS & DS is as follows:
APs that are members of the same ESS advertise the same SSID. In addition, APs that are members of the same ESS are connected to the same DS. An AP MLD has a single interface to the DS (via the AP MLD), therefore, all APs affiliated with an AP MLD need to be members of the same ESS and are connected to the same DSS. As a result, all APs affiliated with the same AP MLD must have the same SSID.
Please see the definitions of SSID, DS and ESS from baseline spec (REVme D1.0):
- SSID: A string used to identify the infrastructure basic service sets (BSSs) that comprise an extended service set (ESS), or to identify a non-infrastructure BSS
- DS: A system used to interconnect a set of basic service sets (BSSs) and integrated local area networks (LANs) to create an extended service set (ESS).
- ESS: A set of one or more basic service sets (BSSs) that are interconnected by a single distribution system (DS); an ESS appears as a single IEEE Std 802™ access domain to the logical link control (LLC) sublayer.
Furthermore, SSID is an input to perform authentication and in an ML setup, authentication is performed at the MLD level not per-link. Therefore, all APs of the AP MLD need to have the same SSID.
During the call, there was a question on allowance of more than one SSID on the same channel. This is allowed and is the same as the virtual AP concept done today (via multiple BSSID set or co-hosted BSSID set). There are a couple of examples shown in Annex AA. One of them is shown below:
In the above example:
- AP-x and AP-p advertise the same SSID (say IEEE Guest)
- AP-z, AP-q and AP-b advertise the same SSID (say IEEE Enterprise)
- AP-y and AP-r advertise the same SSID (say IEEE Lab)
- MLD-1, MLD-2 and MLD-3 co-exist and each are part of a different ESS (IEEE Guest, IEEE Enterprise and IEEE Lab respectively).
Hope this helps!
Regards,
Abhi
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