Re: [STDS-802-11-ARC] [STDS-802-11-TGBC] Recap, for comments, on TGbc architecture
--- This message came from the IEEE 802.11 ARC Reflector ---
Morioka-san,
One follow-up:
> > • Discovery for eBCS-capable STAs
> > • An eBCS-capable/enabled “AP” (I’ll call this an eBCS AP from now on, but we might want a different term) sends Beacons (but not necessarily 802.11 Beacons!) indicating its capability, and (optionally?) particular broadcast services that are available. (Assuming this looks generally like an 802.11 Beacon, it should probably include a BSS Membership Selector for eBCS, to prevent Legacy STAs from becoming confused.)
> Yes, the EBCS Info frame is used for this purpose.
> EBCS Info frames are transmitted periodically in longer interval than Beacon.
Is the EBCS Info frame sufficient, if we now treat the eBCS AP as a separate entity from the Legacy AP (might even not be co-located with a Legacy AP)? That is, do we need to add some information from the traditional 802.11 Beacon to the EBCS Info frame, and/or require an eBCS AP to send its own Beacons (perhaps with a subset of information from a normal one), especially if it is not co-located with a Legacy AP?
Mark
-----Original Message-----
From: Hitoshi MORIOKA <hmorioka@xxxxxxxxxxxx>
Sent: Wednesday, June 2, 2021 8:25 AM
To: mark.hamilton2152@xxxxxxxxx
Cc: 森岡仁志 <hmorioka@xxxxxxxxxxxx>; STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBC] Recap, for comments, on TGbc architecture
Hello Mark and all,
Thanks for the recap.
> • Broadcast/Multicast streams that require association (for security reasons, or ???)
> • Can anyone list other reasons for these streams, for the “???” above?
> • Is there any reason these are not handled by existing 802.11, 802.1Q and IGMP features? (This includes security requirements, discovery requirements, power saving requirements, etc.)
> • If this is handled by legacy standards already in existence, does some prior agreement in TGbc need to be revisited, to stop talking about this? Alternatively, if something is not handled by legacy standards already in existence, can we be more specific about what new feature/behavior TGbc is adding, so we talk about it specifically?
In my understanding, the association required multicast/broadcast is out of scope of TGbc.
> • Discovery for eBCS-capable STAs
> • An eBCS-capable/enabled “AP” (I’ll call this an eBCS AP from now on, but we might want a different term) sends Beacons (but not necessarily 802.11 Beacons!) indicating its capability, and (optionally?) particular broadcast services that are available. (Assuming this looks generally like an 802.11 Beacon, it should probably include a BSS Membership Selector for eBCS, to prevent Legacy STAs from becoming confused.)
Yes, the EBCS Info frame is used for this purpose.
EBCS Info frames are transmitted periodically in longer interval than Beacon.
> • An eBCS STA can request (with a public action frame) to “enable” a broadcast service that is known (believed?) to be available at the eBCS AP, and is not currently being broadcast.
> • An eBCS STA can be co-located with a Legacy 802.11 STA. The 802.11 STA can be associated or unassociated, without any effect on eBCS behavior.
> • Note that “associated” or “unassociated” is not a concept in the context of eBCS.
> • What is an eBCS “AP”?
> • An eBCS “AP” might be, or might not be, co-located with a Legacy 802.11 AP
> • An eBCS AP Beacons information useful/necessary for eBCS operation (only? How far do we go in the 802.11bc spec to describe what is/isn’t in an eBCS Beacon?) If the eBCS AP happens to be co-located with a Legacy 802.11 AP, do we somehow “merge” the Beacons (Multiple BSSID, or something similar?) on the assumption that any eBCS STA will be able to understand any new construction we create?
Although we define some elements for Beacon, the receivers have to receive EBCS Info frame to consume contents.
> • There is no DS. (Without association or any concept of “location” there is no purpose for the DS.) eBCS APs are directly bridged to a non-802.11 network (optionally, of course, but they would be of limited value if no non-802.11 network is present, so it is almost always a good assumption).
> • Mapping of IP-layer information (src IP, dst IP, [port], etc.) is a higher-layer function. This higher layer’s configuration is where streams are classified as “requires association” or not. Routing/bridging to Legacy AP or eBCS AP happens at this layer (much like VLANs). I think this is the eBCS Proxy we mentioned (?) – and it is a function we can require in 802.11bc, but would be implemented in a higher layer (that understands IP frames). At the 802.11 SAP for the TGbc case, it would specified that the SAP assumes all MA-UNITDATA.request primitives would already be “filtered” and only MSDUs appropriate for eBCS transmission would be delivered to that primitive. (Note, a similar concept applies on the non-AP STA, as well.)
Thanks for the summary.
My understanding is same.
Thanks again.
I will update slides in a few days.
Best Regards,
---
Hitoshi MORIOKA
SRC Software Inc.
hmorioka@xxxxxxxxxxxx
> 2021/06/02 2:24、Mark Hamilton <mark.hamilton2152@xxxxxxxxx>のメール:
>
> All,
>
> To try to recap what I think were comments from today’s TGbc call, and to get discussion/feedback going, here is what I had in mind. Comments/flames/etc. are encouraged!
>
> • Broadcast/Multicast streams that require association (for security reasons, or ???)
> • Can anyone list other reasons for these streams, for the “???” above?
> • Is there any reason these are not handled by existing 802.11, 802.1Q and IGMP features? (This includes security requirements, discovery requirements, power saving requirements, etc.)
> • If this is handled by legacy standards already in existence, does some prior agreement in TGbc need to be revisited, to stop talking about this? Alternatively, if something is not handled by legacy standards already in existence, can we be more specific about what new feature/behavior TGbc is adding, so we talk about it specifically?
> • Discovery for eBCS-capable STAs
> • An eBCS-capable/enabled “AP” (I’ll call this an eBCS AP from now on, but we might want a different term) sends Beacons (but not necessarily 802.11 Beacons!) indicating its capability, and (optionally?) particular broadcast services that are available. (Assuming this looks generally like an 802.11 Beacon, it should probably include a BSS Membership Selector for eBCS, to prevent Legacy STAs from becoming confused.)
> • An eBCS STA can request (with a public action frame) to “enable” a broadcast service that is known (believed?) to be available at the eBCS AP, and is not currently being broadcast.
> • An eBCS STA can be co-located with a Legacy 802.11 STA. The 802.11 STA can be associated or unassociated, without any effect on eBCS behavior.
> • Note that “associated” or “unassociated” is not a concept in the context of eBCS.
> • What is an eBCS “AP”?
> • An eBCS “AP” might be, or might not be, co-located with a Legacy 802.11 AP
> • An eBCS AP Beacons information useful/necessary for eBCS operation (only? How far do we go in the 802.11bc spec to describe what is/isn’t in an eBCS Beacon?) If the eBCS AP happens to be co-located with a Legacy 802.11 AP, do we somehow “merge” the Beacons (Multiple BSSID, or something similar?) on the assumption that any eBCS STA will be able to understand any new construction we create?
> • There is no DS. (Without association or any concept of “location” there is no purpose for the DS.) eBCS APs are directly bridged to a non-802.11 network (optionally, of course, but they would be of limited value if no non-802.11 network is present, so it is almost always a good assumption).
> • Mapping of IP-layer information (src IP, dst IP, [port], etc.) is a higher-layer function. This higher layer’s configuration is where streams are classified as “requires association” or not. Routing/bridging to Legacy AP or eBCS AP happens at this layer (much like VLANs). I think this is the eBCS Proxy we mentioned (?) – and it is a function we can require in 802.11bc, but would be implemented in a higher layer (that understands IP frames). At the 802.11 SAP for the TGbc case, it would specified that the SAP assumes all MA-UNITDATA.request primitives would already be “filtered” and only MSDUs appropriate for eBCS transmission would be delivered to that primitive. (Note, a similar concept applies on the non-AP STA, as well.)
> • Stream start/stop
> • When a broadcast stream is started (or defined/identified – which might be ahead of time and more-or-less permanent, or it might be dynamic and ad hoc), the eBCS APs that will support that stream are managed “via an external management entity” to enable that stream.
> • Alternatively, eBCS APs can be enabled to handle any/all streams, without further external control.
> • I suspect this stuff makes the most sense to be in the MIB, as part of a eBCS AP “configuration”.
> • Actual start/stop of stream traffic is beyond the scope of 802.11, as the stream can come from anywhere.
>
> Comments? Arguments? What did I forget to include (as well as what do you think I got wrong)?
>
> Mark
>
>
> To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
>
________________________________________________________________________
To unsubscribe from the STDS-802-11-ARC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-ARC&A=1