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 |