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

Re: [STDS-802-11-TGM] Extending the Element ID space



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Hello Donald,

Thank you for your comments.

I guess we need (and I will be asking for) guidance about
the intended use of the spaces,  specifically:
1. The remaining regular "element ID" space
2. The 1-octet extension space
3. The 2-octet extension space

A single octet extension is likely to last us a large number of years,
so whether we want to limit its usage is TBD by the members.

I have a pending request from TGai to allocate 2/3 of the remaining 
Element ID space to itself,  so the discussion is germain.


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

-----Original Message-----
From: Donald Eastlake [mailto:d3e3e3@xxxxxxxxx] 
Sent: 05 October 2014 18:41
To: Stephens, Adrian P
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Extending the Element ID space

The TGai fragmentation scheme is in 9.42 and 9.43 of Draft P802.11ai_D3.0.pdf and looks reasonable to me.

I think the two structures are fine but I'm wonder if there should be some mechanism to push back against everyone grabbing the shorter Structure A until it is used up before starting on Structure B. Maybe Structure A should only be allowed for IEs that have to be in Beacons or something...

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


On Thu, Oct 2, 2014 at 2:33 AM, Stephens, Adrian P <Adrian.P.Stephens@xxxxxxxxx> wrote:
> --- This message came from the IEEE 802.11 Task Group M Technical 
> Reflector
> ---
>
> Dear TGm folks,
>
>
>
> In the September meeting there was a discussion of the likely 
> exhaustion of Element ID space,  and a clear sentiment to
>
> be proactive in resolving the issue.
>
> TGai has just asked the ANA for 14 of the remaining ~20 Element IDs,   so we
> need to consider a possible extension mechanism urgently.
>
>
>
> In my mind the requirements of any extension are: (most important 
> first)
>
>
>
> 1.       To be parseable by existing parsers
>
> 2.       To support an effectively unlimited number of Element IDs. For this
> purpose  2**16 might be “unlimited”.
>
> 3.       To minimise added overhead
>
> 4.       To permit longer elements
>
>
>
> I don’t see how we can satisfy 1. and 4. simultaneously,  but brighter 
> minds may find a solution.
>
> (OK,  I can see a complex solution,  but not a simple one).
>
>
>
> I suggest,  as a starting point to stimulate discussion, the following
> structures:
>
>
>
> Structure A:   - 8 bit extension,  8 bit length
>
> Octet 1:   Element ID = 254
>
> Octet 2:   Length (1-255),  including Octet 3
>
> Octet 3:   Element ID Extension 0-255
>
> Octets 4 to Length+3:  Body
>
>
>
> Structure B:   - 16 bit extension,  8 bit length
>
> Octet 1:   Element ID = 255
>
> Octet 2:   Length (2-255), including Octets 3 and 4
>
> Octets 3-4:   Element ID Extension 0-65535,  less one escape
>
> Octets 5 to Length+3:  Body
>
>
>
>
>
> Regarding lengths greater than 255,  we already have a fragmentation 
> scheme in TGai.  I don’t see an obvious
>
> scheme that doesn’t need “compatibility element header mid-ambles” of some
> kind.   The complexity of such
>
> a scheme is similar to the fragmentation scheme of TGai,  so there is 
> little benefit to inventing it.
>
>
>
> I suggest we have an email thread.  If there is a consensus emerging,  
> I suggest those folks get together
>
> in a submission to TGmc for the November session.
>
>
>
>
>
>
>
> 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
>
>
>
> _______________________________________________________________________________
>
> 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-TGM 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
> _______________________________________________________________________________

_______________________________________________________________________________

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-TGM 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
_______________________________________________________________________________