There are situations in which the 255-octet limit on elements is
problematic (e.g. PQC, MBSSID, Multi-Link element, beacon reports),
causing the need for truncation or fragmentation (sometimes even
double-fragmentation, which is almost guaranteed not to be
interoperable!).
Would there be interest in developing support for jumbo elements
in TGmf? I'm thinking of something like:
- Allocate element ID 254, say, to greenfield jumbo elements, where
the Length field is 2 octets. Obviously this could only be used for
unicasts to peers that understand that element (either explicitly
through a capability bit or implicitly because they are an
11bz/ultra-super-mega-high-throughput-and-efficiency-and-reliability STA),
and perhaps certain special broadcast cases where legacy receivers
will ignore the entire frame (e.g. new Action frame). E.g.:
1-octet element ID 254
1-octet subelement ID
2-octet length of information 1234 (say)
1234-octet information
- Allocate element ID 253, say, to backward-compatible jumbo elements
(because existing implementations would just ignore them), which
would be similar to fragmented elements except the size would be
known in advance. E.g.:
1-octet element ID 253
1-octet legacy length 255
2-octet real length of information 252+255+255+42 (say)
1-octet subelement ID
252-octet information fragment #1
1-octet element ID 253
1-octet legacy length 255
255-octet information fragment #2
1-octet element ID 253
1-octet legacy length 255
255-octet information fragment #3
1-octet element ID 253
1-octet legacy length 42
42-octet information fragment #4
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1