Mike/Mark,
FWIW … another thought on FST and
MLO. I’m not sure they are “mutually exclusive features”.
I can imagine a non-AP MLD wanting to, for example, change from a set of
channels in the 5GHz band to an obviously different set of channels in the 6GHz
band, and do so “quickly” using FST functionality. From the
point of view of FST functionality, it’s a “single (MLD) MAC”
that wants a fast session transfer. I might be missing something here,
and if I am, I am confident you can help me out :^))))
Cheers,
RR
From: M Montemurro [mailto:montemurro.michael@xxxxxxxxx]
Sent: Wednesday, May 5, 2021 11:24
AM
To:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
Feedback Requested for CRs related to MLD architecture - 11-21-0577
Thanks for the comments. I believe this contribution gives a response
to your comments on TGbe with respect to MLO architecture. I
believe this is a really good starting point and will likely evolve
through the progress of P802.11be. My recommendation at this point is to get
this text for MLO operation into the draft and then add to it to provide more
information on mixed legacy AP/MLD operation.
My responses to your comments below:
Hi, Duncan,
Thanks for
this. Good progress! A few mostly minor (I think) comments:
- As I think you know, I struggle with the
Reference model figure (Figure 4-xxx), just stylistically – I think
it is hard to understand/visualize. I’d be happy to work more
with you off-line, to see if we can find an alternative. And,
whatever we end up doing with this Figure, we may want to consider a
contribution to REVme to do something similar to Figure 4-28 (REVme D0.0),
and maybe Figure 4-29. (If nothing else, the NOTEs you have in 4.9.5
would be good to add in the baseline 4.9.4.)
[MM] We can take this one offline. If there is something to be
contributed to REVme, my preference is to leave this as is in TGbe for now and
then adjust once the change in REVme is complete.
-
- I also think Figure 4-xxx and the text in 4.9.5
is a bit confusing because it doesn’t show/describe that many (most,
in fact) of these components are actually shared with the legacy operation
STA(s). What is “shared” and what is not is left to the
reader to figure out, and I think that could lead to interoperability
problems due to differing assumptions. Also, for example, the text
is clear about the link-specific operations, including SAs for
GTK/IGTK/BIGTK, but the figure implies there is only one
Authenticator/Supplicant and RSNA Key manager.
[MM] In my opinion the current text in 4.9.5 is complete and clear for
MLO. It could be that we add separate text and perhaps a separate figure to
cover MLO where the affiliated APs perform legacy operations. I think this
could be added after this text is accepted.
-
- 4.9.5, 6th paragraph (counting the
NOTEs), I don’t think the MLD MAC address can identify the
SME. That doesn’t fit the MAC addressing model from IEEE Std
802. The MLD MAC address is actually identifying the (single) MAC
SAP (or the entity(ies) supporting that MAC SAP, if you’d prefer),
which you have described in a later paragraph.
[MM] My recommendation is to change "The SME is identified
by" to "The IEEE 802.1X Authenticator of the AP MLD is identified
by"
-
- 5.1.5.1, in the new paragraph that starts
“During reception, …”: if we’re mentioning the
multiplexing, we probably also need to mention the split between the MLD
stack processing and the legacy stack(s) processing, based on stored
knowledge of the peer device/association type.
[MM] Similar to my earlier comment response. I believe concurrent
legacy/MLO operation should be covered by a separate text in a separate
submission. I believe this text is complete for MLO.
-
- Also in that same paragraph, it is not MSDUs from
the PHY SAPs that do the multiplexing, but the _MPDUs_ (they haven’t been decrypted/unpacked yet)
from the _top of the Lower
MACs_ that do this.
[MM] Yes, MSDU should be replaced by MPDU.
-
- I’m not sure why you have changed the order
of the functional blocks in Figure 5-3 (compared to the baseline Figure
5-1). We should discuss this re-ordering, and if agreed, update
Figures 5-1 and 5-2 to match. Also, why were some blocks left out
completely?
[MM] The only blocks that are missing are fragmentation/defragmentation
and PS Defer Queuing. TGbe has agreed not to support
fragmentation/defragmentation in release 1. I think I know what PS Defer
Queuing is, but its only used in Figure 5-1 and Figure 5-2 and not defined
anywhere in IEEE 802.11-2020 (sounds like a REVme issue) so I believe its OK to
leave it out of the proposed Figure 5-3 for now.
-
- Comparing the new text to the baseline, I am now
realizing that I have no idea what to think of a combination of FST and
MLO. I’m not sure that is even useful. Has that been
discussed? Can we just rule it out?
[MM] I believe FST and MLO are mutually
exclusive features. I don't have an idea how or why someone would combine them.
-
- A nit, but should we really add new subclauses
for 5.1.5.10 and 5.1.5.11, or just “fix up” the language in
5.1.5.2 and 5.1.5.3?
[MM] I think its good to have new subclauses given these are separate
entities at this point.
-
- Those subclauses (just above) point out a
question I hadn’t tried to think about yet – is there any
reason we can’t do GLK with MLD, or is the plan to support GLK MLD?
[MM] It seems that you could support GLK on an MLD. Would need someone
to figure out what the text changes were.
-
- The DA address filtering (and other discussion
about MAC addresses) makes me realize that we need to say somewhere that
when an MSDU is directed to/from an AP MLD or non-AP MLD, the DA/SA
(respectively) are the MLD address for the AP MLD or non-AP MLD. Do
we say that anywhere? That is, to external devices, it is the
“MLD address” that is visible on the broader 802 network (I
think).
[MM] That is currently covered in 35.3.3 but the text could be
cleaned up to be clearer.
-
- For the diagram in 7.1 (new Figure 7-1), this is
another spot where I find it confusing that the AP MLD does not have any
indication of how the legacy operation works. Especially in this
figure, where the legacy APs also have access to the DS (separately from
the MLD AP) I think that really needs to be shown in the figure. I
don’t know if you’ve seen the figure I did in 11-21/0396r2
slide 6? I think adding that figure (as a new 7-1a, rather than
making Figure 7-1 any more complicated) would be a better approach.
[MM] If we want to show mixed MLO/legacy operation, we should create
separate text and a separate featuree.
-
- At the end of subclause 7.1, do we need to add
“Accept non-AP-MLD-to-AP-MLD mapping updates from the AP
MLDs.”? Similarly, in the paragraph above, “mapping of
STAs _and non-AP MLDs_ to
APs, _AP MLDs_, or to mesh
gates.”\\
[MM] See my earlier comments on mixed operation.
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
|