I have same question as Rojan. DS, ESS are all abstract concepts. If we want to allow multiple SSIDs, then is making additional virtual Aps/using multiple BSSID feature only way?
发件人: Rojan Chitrakar [mailto:rojan.chitrakar@xxxxxxxxxxxxxxxx]
发送时间: 2022年3月23日
11:25
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Discussion on SSID (CIDs 6725, 4036, 4919 and 6876)
What about the wired side? The closest equivalent to VAPs would be Virtual LANs I guess. Do different virtual LANs connect to different DSs as well? Since a VLAN maps to a SSID, the wireless side needs to spawn off one
AP MLD (each with multiple VAPs) for each VLAN if we go with the single SSID concept, right?
DS, ESS are all abstract concepts; the important thing is to understand how virtualization would work in the least complicated manner in actual deployments in my humble opinion. Theoretically an AP MLD can serve 15 links,
can’t we make it serve multiple SSIDs?
>> An AP that supports multiple SSIDs supports multiple virtual APs
Right. And those multiple virtual APs might be separately beaconing (aka co-hosted), or they might be part of a Multiple BSSID set in which case only the AP corresponding to the transmitted BSSID sends beacons. It should
not make any difference from the reference model perspective.
Hi Joseph,
AP's that are connected to the same DS advertise are part of the same ESS and advertise the same SSID. An AP that supports multiple SSIDs supports multiple virtual APs, all connected to different DSs.
Hi Thomas –
I hate to jump in here with a questions, but I don’t understand your statement “…. all the upper stacks’ DSAFs interface with the same DS, and therefore need
to use the same SSID.” Why does having a common DS mean that all the connected APs use the same SSID?
My understanding is that the DS simply connects DASFs to each other and to the portal, and is responsible for routing the frames between the DASFs and the Portal
based on the knowledge of how the frame should be routed to reached the addressed MAC SAP. Don’t APs that support multiple SSIDs connect to only one DS?
Regards,
Joseph
Thanks Mark for the nice description and references, and also for confirmation that the “parallel upper stack” (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.
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
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.
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?
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):
1.
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
2.
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).
3.
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:
1.
AP-x and AP-p advertise the same SSID (say IEEE Guest)
2.
AP-z, AP-q and AP-b advertise the same SSID (say IEEE Enterprise)
3.
AP-y and AP-r advertise the same SSID (say IEEE Lab)
4.
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
|