Re: [STDS-802-11-TGAK] A_MSDU indication of 11ak control header
Hi Adrian,
Thanks for the comments, see below...
On Tue, Mar 11, 2014 at 3:45 AM, Stephens, Adrian P
<Adrian.P.Stephens@xxxxxxxxx> wrote:
> Hello Both,
>
> One comment. A mesh STA only talks to other mesh STAs, so its choice of
> A-MSDU format is unambiguous.
>
> This also applies to .11ak only if an .11ak AP talks only to .11ak STAs.
> Of course a .11ak STA might also associate with a non-.11ak AP.
There is some current unofficial text which does require that .11ak
STAs only talk data with other .11ak STAs. After all, the data frame
formats are incompatible, current STAs using LLC/LPD encoding and
.11ak using Ethertype/EPD encoding.
> So the non-AP STA needs to know "associated with an .11ak AP".
>
> This is reasonable because what is logically an .11ak AP could be a single
> physical box supporting two logical APs, one for
> non-.11ak and one not. non-.11ak STAs can be excluded from the .11ak-only
> BSS using the BSS membership selector field.
There is current unofficial text that uses an information element to
distinguish .11ak STAs and goes through various other gyrations that
are, perhaps, a bit kludgy. Prompted by your message, I've been
thinking about this and it seems much nicer to use a capability bit
(perhaps the recently freed Bit 13) to indicate .11ak and use the BSS
membership selector field as an important part of assuring no
associations between incompatible STAs. How safe do you think it would
be to use Capability bit 13?
> I personally prefer to make all packet formats self-defining, i.e., to
> require the minimal amount of non-on-the-air
> state to decode them. It makes the designers' job easier. It also makes
> debugging and sniffing a whole lot
> easier. I don't know if this is possible in this case, but it is always my
> starting position, regardless of whether the
> entire BSS is .11ak-only.
I agree it is strongly desirable for data frames to be self-defining,
but in this case it seems hard to achieve. A new flavor of data frame
or just of A-MSDU seems moderately hard to indicate unless you steal a
bit that currently has some other specified use. Although perhaps I'm
missing something and it is easier than I think.
Just as an example, you could say we don't really need 2 bits of
802.11 version (or perhaps say that all we need is one bit of 802.11
version escape) and say that one of the current two 802.11 version
bits is now an additional frame sub-type bit. (It would have the
characteristic that any STA which does not understand what it means
for that bit to be non-zero will reject it. (I am assuming that, in
the real world, STAs actually check the version field.)) 11ak STAs
would understand this bit so it could be used for frames that only
11ak, and other STAs defined in the future to use this bit would
understand. I admit this would be a pretty major thing to do and it
was just an example, but it seems like it would work.
Thanks,
Donald
=============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
155 Beaver Street, Milford, MA 01757 USA
d3e3e3@xxxxxxxxx>
> Best Regards,
> Adrian P STEPHENS
>
>
> Tel: +44 (1793) 404825 (office)
> Tel: +44 (7920) 084 900 (mobile, UK)
>
> Tel: +1 (408) 2397485 (mobile, USA)
>
> ----------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
>
>
> From: Hamilton, Mark [mailto:Mark.Hamilton@xxxxxxxxxxxxxxx]
> Sent: 10 March 2014 21:27
> To: STDS-802-11-TGAK@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11-TGAK] A_MSDU indication of 11ak control header
>
>
>
> Donald,
>
>
> On the call just now, you brought up the topic of how to indicate a
> "different/unique" type of A-MSDU that would carry the additional
> 11ak-defined information, as distinct from a 'normal' A-MSDU which has no
> such control information. This was in an attempt to make this new frame
> structure re-usable by non-11ak devices, I believe.
>
>
> I thought about it for a brief time, and I think I'm concluding that we
> should treat the 11ak link somewhat similarly to a mesh link. That is,
> since there is already an assumption of mutual exclusion between 11ak and
> non-11ak devices within a BSS, we can safely ignore the backward
> compatibility problems of having frame formats that legacy devices cannot
> understand.
>
>
> Part of my rationale is that even if we did introduce some sort of method
> that would allow non-11ak devices to re-use this new format for A-MSDU, then
> it will require yet another capability mechanism to indicate when a set of
> peer STAs were both capable of understanding this format, and a
> justification for why this would be useful, to make it work and get it into
> the non-11ak world. Off hand, I don't see that.
>
>
> So, as I said, my recommendation would be to not worry about this aspect.
> Instead, we simply say that on an 11ak link, A-MSDUs have a different
> format, just like the way mesh says that today (see 802.11-2012, 8.3.2.2, if
> anyone is wondering what I'm talking about). I think it makes things
> simple, and we have a strong precedent for this approach.
>
>
> Comments, anyone?
>
>
> Mark
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAK and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________