1. Mesh Frame Formats Date: 2007-05-14 Authors: May 2007 March 2007
doc.: IEEE yy/xxxxr0
May 2007
Mesh Frame Formats
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

2. March 2007
doc.: IEEE yy/xxxxr0
May 2007
Abstract
Comments were raised during LB93 about the purpose of multihop management frames, and alternatives thereto. This presentation identifies possible resolutions to comment identifiers G13 and G22.
For reasons of efficiency, Mesh management frames should not be action specific but ALLOW multiple action IEs to be carried
Ideally, the mesh management should be forward compatible with e.g. TGv and TGw.
The Mesh data frame format needs to be addressed such that it assures forward compatibility e.g. with TGn
This presentation addresses all of the above
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

3. Comments on multihop management (G13, G22)
March 2007
doc.: IEEE yy/xxxxr0
May 2007
Comments on multihop management (G13, G22)
CIDs in General Category G9: Need clarification on compatibility of mesh data
frame type with existing data subtypes
1672, 2235, 3467, 3601, 4468, 4893
CIDs in General Category G11: Clarification of extended frame type vs. mesh
management frame type vs. using existing frame types
42, 1582, 2024, 2031, 2055, 2278, 3760, 3761, 3764, 3765, 4470, 4471
CIDs in General Category G13: Mesh Management Frame and Mesh Action Data Unit
needs clarification
6, 312, 313, 316, 317, 318, 319, 324, 1937, 1939, 2057, 2619, 2900, 3535, 3747,
4018, 4081, 4197, 4894, 4939, 5197
CIDs in General Category G16: Incomplete frame descriptions
1805, 1936, 3605, 3666
CIDs in General Category G22: Action encapsulation frame needs clarification
3547
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

4. Current Approach for Mesh frames
May 2007
Current Approach for Mesh frames
Valid type and subtype combinations
Type value b3 b2
Type description
Subtype value b7 b6 b5 b4
Subtype description 11
Extended
0000
Mesh Data
0001
Mesh Management
ReservedExtended
Reserved
We received many comments on using last major type available (42, 4470, 3765, 3764, 3760, 3528, 2109, 1334, 1088)
Guenael Strutt, Motorola e.a.

5. Current Approach to Mesh Data Frames
May 2007
Current Approach to Mesh Data Frames
Do we need a Data type? It means repeating all the subtypes now defined for the DATA type!
Increases risk of incompatibility with other “Amendments”
So why bother: because we needed a way to signal the presence of the Mesh Forwarding header.
Guenael Strutt, Motorola e.a.

6. Solution: No Mesh Data Type!
March 2007
doc.: IEEE yy/xxxxr0
May 2007
Solution: No Mesh Data Type!
Use data types/subtypes as is:
Mesh Data frames are only exchanged between members of a mesh network.
An AP/STA would never expect a data frame with a Mesh Header from an AP/STA
Assures forward compatibility with changes that other TGs might come with – e.g. TGn aggregation.
An unprotected data broadcast could be seen by legacy devices as a valid frame
Setting TO DS and FROM DS to 1, avoids that.
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

7. Mesh Management Frames
May 2007
Mesh Management Frames
We need many new frames, > 20
Link Set-up, Path Selection, Security, Proxy Registration
We have to support some existing management frame types
It would be nice to be able to re-use current Management frames as is - even using them over multiple hops
There are other issues: existing hardware may not support an extended frame type
Guenael Strutt, Motorola e.a.

8. March 2007
doc.: IEEE yy/xxxxr0
May 2007
Multi-hop management?
Management in a mesh has to be mesh oriented, not link oriented: some nodes may control/exercise management functions executed by or on behalf of other nodes
E.g. a portal collecting proxy information from mesh points
Example: RRM measurements collected by a central node
Multi-hop management pertains to
A management frame (i.e. a frame with a payload that is never read by an upper layer entity)
A management payload that is transferred across multiple hops, without the intermediate MPs acting on this payload
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

9. Current approach for management frames
March 2007
doc.: IEEE yy/xxxxr0
May 2007
Current approach for management frames
Mesh Management is a Category of Action Frames (current draft)
Pros:
Requires no new type/subtype
Cons:
There are too many actions of category “Mesh”, and the list is growing .
The hierarchy of mesh categories (Security, Routing, PLM etc.) is “buried”
Multihopping is not explicitly feasible
TYPE
SUBTYPE
CATEGORY
ACTION IE
MANAGEMENT00
ACTION 1101
MESH MGT
PLM/OPEN
PLM/CLOSE
HWMP/RREQ
HWMP/RREP
etc
“MESH MANAGEMENT”
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

10. Current approach (draft 1.0x)
March 2007
doc.: IEEE yy/xxxxr0
May 2007
Current approach (draft 1.0x)
Multi-hop legacy management can use the mesh “action encapsulation frame”
TYPE
SUBTYPE
SIMPLIFIED HEADER
PAYLOAD
MANAGEMENT00
ACTION 1101
TX x
RX Y
CATEGORY
ACTION
MESH MGT
MESH ENCAPS
SOURCE A
DEST B
ENCAPSULATED PAYLOAD
Forwarding overhead
CATEGORY
ACTION
HWMP
PROXY REG
INFORMATION ELEMENT
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

11. May 2007
New approach
Re-use as much as of the existing definitions as possible while recognizing that new meanings may be applied to existing fields
Add a management forwarding header for multi-hop operations
Expand the Category list
Guenael Strutt, Motorola e.a.

12. Currently defined Categories
May 2007
Currently defined Categories
Code Meaning
0 Spectrum management
QoS
DLS
Block Ack
Undefined
RRM
Fast Hand-off
High Throughput
8–126 Reserved
127 Vendor Specific
255 Error (reserved for error processing)
Guenael Strutt, Motorola e.a.

13. Mesh Category and Action Types
May 2007
Category
Action(s)
Mesh PLM
Peer Link Open
Peer Link Confirm
Peer Link Close
Mesh HWMP
Path Request
Path Reply
Path Error
Root Announcement
Mesh Proxy
Proxy Update
Proxy Update Confirm
Mesh Security
Mesh Key Holder Security Establishment
PMK-MA delivery push
PMK-MA confirm
PMK-MA request
PMK-MA delivery pull
PMK-MA delete
Mesh EAP encapsulation
Etc… …
Guenael Strutt, Motorola e.a.

14. What to do with encapsulation?
March 2007
doc.: IEEE yy/xxxxr0
May 2007
What to do with encapsulation?
Originally proposed to allow for the reuse of Action IEs (Spectrum mgt, QoS, DLS and Block Ack)
This proposal makes encapsulation unnecessary
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

15. Proposed Management Frames for Mesh
March 2007
doc.: IEEE yy/xxxxr0
Proposed Management Frames for Mesh
May 2007
Current Action Frame Layout
PAYLOAD
CATEGORY X
ACTION Y
Fields/IEs related to this Category/Action
ACTION FIELD
TYPE
SUBTYPE
MGMT HEADER
MGMT 00
ACTION 1111
ADDR1 TA=SA
ADDR2 RA=DA
BSSID=0
Alternative Multi-hop Action Frame Layout: insert multi-hop hdr, keep the rest
SUBTYPE
MGMT HEADER
MGMT 00
MULTIHOP ACTION 1111
ADDR1 TA
ADDR2 RA
ADDR3 DA
PAYLOAD
ADDR4 SA
TTL
CATEGORY X
ACTION Y
Fields/IEs related to this Category/Action
MULTIHOP MAN’T FIELD
ACTION FIELD
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

16. March 2007
doc.: IEEE yy/xxxxr0
May 2007
Benefits
Applies a simple multi-hop header to Action frames to make them multi-hop-able
Adds one frame subtype: multi-hop action 1111
Uses 3 address format so existing forwarding designs can be re-used
Allows creation of a well ordered set of Categories/Actions for Mesh
Allows “re-use” of all existing Category/Action values in a multi-hop environment
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola

17. What about Management Security
May 2007
What about Management Security
Use the 11w “MIC” structure to assure integrity and origin authentication
Applies to all Man’t Cat/Actions with the exception of “security”
The list of protected/non-protected frame types/subtypes specified in 11w may have to be changed.
Apply content encryption/and or special integrity checks as required/described in the EMSA section.
11w operates at the lowest level of frame processing just above the transmit and receive functions: therefore there need not be a conflict with EMSA security, at best “duplication”
Guenael Strutt, Motorola e.a.

18. References doc.: IEEE 802.11-07/0250r1 (Slide 8)
March 2007
doc.: IEEE yy/xxxxr0
May 2007
References
doc.: IEEE /0250r1 (Slide 8)
doc.: IEEE r19 (Issue Identifier G13, G22)
Guenael Strutt, Motorola e.a.
Guenael Strutt, Motorola