Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11] 802.11ak motivated change in 802.11 tagged frame encoding



--- This message came from the IEEE 802.11 Working Group Reflector ---

Hi,

The body of network frames can be encoded in two incompatible ways
that differ in their prefix:
   LLC (LSAP-LSAP-Control), used by 802.11 (and previously by 802.2), and
   Length/Type (Length or Ethertype), used by 802.1 and 802.3 and most
other media.

Converting tagged frame payloads from one encoding to the other is, as
described below, impossible in general. Since the motivation for
802.11ak/802.1Qbz is to have such systems interoperate, a change in
encoding is necessary. Although it would not affect the 802.11 header,
in the worst case, this change in payload encoding could INVALIDATE a
CURRENTLY-COMPLIANT implementation of 802.11.

There is not much problem with just converting a simple untagged
payload, such as an untagged IP datagram. The problem comes when VLAN
and the numerous other tags that have been defined are prefixed to
such a simple untagged payload. In general, a device at the boundary
between one encoding method and the other, such as an 802.11ak AP,
would currently have to dig into the frame and change the encoding of
every tag as well as the encoding of the innermost payload. Partly
because there is no length infomation in LLC or Ethertype, this is
impossible without understanding every possible tag which in turn
makes it impractical to ever deploy a new tag, an untenable situation.

Because tags have been relatively rare on 802.11 traffic and because
the Length/Type encoding is more efficient, the proposal is to change
the format of 802.11 frames so that, while they would still start with
LLC, they would subsequently use Length/Type. Actually, this would be
a general change in the format of LLC frames but 802.11 is believed to
the the largest user of such frames. (The change would be actually
implemented as follows: When a new tag is added, the existing leading
LLC payload prefix would be converted to Length/Type and then the tag
added in LLC format. When a tag is being removed, the Length/Type
prefix uncovered by that removal would be converted to LLC.)

The question is, are there deployed systems that are critically
depended on the current repeated use of LLC within a frame that has a
tagged payload?

For further information, see 11-13/0952r1, a version of which may be
presented at the midweek plenary in Nanjing next month.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@xxxxxxxxx

_______________________________________________________________________________

If you wish to be removed from this reflector, do not send your request to this reflector - it will have no effect.

Instead, go to http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11 and then press the LEAVE button.

If there is no LEAVE button here, try http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-RO.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________