1. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 1 Multihop Management Frames and other matters Notice: This document has been prepared to assist IEEE 802.11. 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 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, 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 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2007-04-012 Authors:

2. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 2 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 M 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 with e.g. TGn This presentation addresses all of the above

3. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 3 Comments on multihop management (G13, G22) Need for clarity –CIDs 6, 316, 317, 318, 319, 1937, 4197, 4939 Mesh management header –CIDs 312, 313 Vendor-specific mesh management –CID 324 Remove Mesh Management subtype (includes encapsulation) –CIDs 1939, 3535, 3747, 4018, 4894, 5197, 2056 Merge all Mesh Management into one subtype –CID 2057 RRB –CID 2900

4. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 4 What is multihop 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 Multihop 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

5. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 5 Do we need multihop management? Essential usage: –Proxy/dependent registration at root MP That, or have each intermediate node interpret the IE and repackage it (if they actually understand it) –Mesh Authenticator to Portal messaging That, or create a new ethertype (EAPOM?) Possible usage: –Reuse of legacy actions over multiple hops Is address X inside or outside of the mesh? (11A3.4.1) –Direct communication to portal In one word: “yes” –The question is not “if”, but “how”

6. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 6 Current approach (draft 1.0x) 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 TYPESUBTYPECATEGORYACTIONIE MANAGEMENT 00 ACTION 1101 MESH MGT 00000100 PLM/OPEN 00000000 MANAGEMENT 00 ACTION 1101 MESH MGT 00000100 PLM/CLOSE 00000001 MANAGEMENT 00 ACTION 1101 MESH MGT 00000100 HWMP/RREQ 00000010 MANAGEMENT 00 ACTION 1101 MESH MGT 00000100 HWMP/RREP 00000011 etc “MESH MANAGEMENT”

7. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 7 Current approach (draft 1.0x) “Multihop management can use the mesh action encapsulation frame” (aka the “the spaghetti action frame”) TYPESUBTYPE CATEGORYACTION PAYLOAD MANAGEMENT 00 ACTION 1101 INFORMATION ELEMENT TX x MESH MGT 00000100 RX Y MESH ENCAPS 00000101 SOURCE A DEST B HWMP 00000100 PROXY REG 00000010 CATEGORYACTION ENCAPSULATED PAYLOAD SIMPLIFIED HEADER PRICE TO PAY FOR “SIMPLICITY”

8. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 8 Current approach (draft 1.0x) “Multihop management is implicit” –Each device implicitly knows who to forward the IE to This is appealing, but there are limitations: –If the two communicating devices know something that the intermediate devices don’t know, forwarding cannot happen: Example: Vendor A has a special way to register devices from a printer LAN to a portal. Intermediate devices are from Vendor B – should Vendor A use data frames to send management information (MAC address registration)? –Routing is designed to prevent loops from occurring Can we trust intermediate devices to know where to forward the IE? –If there are multiple portals, multiple roots, multiple AS (etc.), does the intermediate device really know what the destination is?

9. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 9 Alternative #1 Mesh Management is a separate frame type/subtype Pros: –Multihop is possible using a TTL field (single hop is TTL=1) –There is a clear distinction between MP-MP and STA-MP/STA communication Cons: –Requires a new type/subtype –Mesh management is a subtype of mesh, instead of a type TYPESUBTYPECATEGORYACTIONIE MESH 11 MANAGEMENT 0000 PLM 00000000 OPEN 00000000 MESH 11 MANAGEMENT 0000 PLM 00000000 CLOSE 00000001 MESH 11 MANAGEMENT 0000 HWMP 00000001 RREQ 00000000 MESH 11 MANAGEMENT 0000 HWMP 00000001 RREP 00000001 etc “MESH MANAGEMENT”

10. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 10 Alternative #1 The solution is to have a mesh management subtype (11-0000) This subtype takes full advantage of the four address format Single-hop management is supported using the TTL field (the exact same way it is done for data frames) The “Category” and “Action” fields are sufficient to appropriately describe all possible uses of mesh management frames!

11. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 11 Current Category values are very sparse Code Meaning 0 Spectrum management 1 QoS 2 DLS 3 Block Ack 4–126 Reserved 127Vendor Specific 255 Error (reserved for error processing)

12. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 12..use some for mesh management! Code Meaning 0 Spectrum management 1 QoS 2 DLS 3 Block Ack 4–15 Reserved 16-112 Mesh Management 127Vendor specific 255 Error (reserved for error processing)

13. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 13 Alternative #2 Mesh Management uses Action Frames identified by a set of Categories of Pros: –Requires no new type/subtype Cons: –Multihop not explicit in the MAC header TYPESUBTYPECATEGORYACTION, e.g.IE MANAGEMENT 00 ACTION 1101 MESH DISC 00010000 DIC/BEACON 00000000 MANAGEMENT 00 ACTION 1101 MESH PLM 0010000 PLM/OPEN 00000000 MANAGEMENT 00 ACTION 1101 M-ROUT 00110000 HWMP/RREQ 00000000 MANAGEMENT 00 ACTION 1101 MESH SEC 010000 HWMP/RREP 0000001 etc “MESH MANAGEMENT”

14. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 14 Alternative #2 Keeps a clear structure: 7 major categories for mesh management: 7 x 16 unique codes These are sufficient to appropriately describe all possible uses of mesh management frames! –Category and Action (Ex-ored) together can be used to form the IE Backward compatible with legacy Cat/Action codes

15. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 15 What to do with encapsulation? Encapsulation is designed to allow for the reuse of Action IEs (Spectrum mgt, QoS, DLS and Block Ack) Action frames are of Type/Subtype: 00-1101 Actions are defined first by their category (one octet), then by an action (variable length) Two possibilities: 1.Create an encapsulation category (e.g. 11-0000/5), which encapsulates an IE with the category number (e.g. “0” for spectrum mgt) in a header [not very elegant] 2.Use the 4 address fields+ mesh forwarding header to control forwarding [not very elegant, but it avoids consuming a subtypesubtype]

16. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 16 A Mesh Data Type? Do we actually need a mesh data type? –The data type is voracious when it comes to subtypes All 16 used in current standard! –Would we need to specify subtypes in a mesh subtype? If we did, there wouldn’t be room for a mesh management subtype! –An easy way out would be to use data types/subtypes as is: That’s right; no change needed at all! An AP/STA would never expect a data frame with a Mesh Header from an AP/STA An MP would always expect a data frame with a Mesh Header from an MP This would preclude MPs from communicating without the Mesh Header –And it assures forward compatibility with changes that other TGs might come with – e.g. TGn aggregation. –The only downside could be backward compatibility: An unprotected data broadcast could be seen by legacy devices as a vlaide frame –However, by setting TO DS and FROM DS to 1, that is avoided.

17. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 17 Keep Mesh Management/Action (00-1101) –Assures forward compatibility with other management amendments – e.g.11 W Re-use existing action/category def’s is no problem Create Mesh Management Category set (16-112-xxxx) –Category subsets correspond to mesh services (security, routing etc.) -xxxx is action code for category Multi-IE frames is no problem – just add Mesh management is both single hop and multihop: –always use the 4 address format, use mesh hdr to control fwrd Mesh data type; mesh data is implicit (existence or non- existence of valid Peer Link IDs) –Forward compatible with TGs, etc Plan B: Alt #2

18. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 18 Suggested resolution: Alt #1 Clean, easy to specify and maintain Can be mapped efficiently to IE Identifiers Multi-IE frames is no problem – just add Mesh management is both single hop and multihop: –always use the 4 address format, use mesh hdr to control fwrd Mesh data type; mesh data is implicit (existence or non- existence of valid Peer Link IDs) –Forward compatible with TGs, etc

19. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 19 References doc.: IEEE 802.11-07/0250r1 (Slide 8) doc.: IEEE 802.11-07-0023r19 (Issue Identifier G13, G22)

20. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 20 Background: Type/Subtype/Category One category for all mesh actions? One Action for both single hop and multihop management ? Two address format

21. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 21 Multihop management: guiding principles 1.Good fences make good neighbors –Keep each IE category separate from the others (break table s25 into subunits) Mesh Peer Link Maintenance Mesh Security Mesh Routing Mesh Congestion Control Mesh Deterministic Access Mesh Synchronization Mesh Power Save Mesh Proxy 2.Live within your means –Leave type/subtype as unaltered as possible (squandering is no longer an option) No new mesh data type One new mesh management subtype

22. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 22 Possible mesh management methods Multihop management as an extension to single-hop management Multihop management as a separate management method Mesh single hop management a category of management action Mesh single hop management the same type as mesh multihop management Encapsulation as a category of mesh management Encapsulation as a subtype of mesh management The question “how do we do multihop management” boils down to types, subtypes and categories. Let’s look at some of the solutions…

23. doc.: IEEE 802.11-07/0550r0 Submission March 2007 Guenael Strutt, Motorola e.a.Slide 23 Suggested alternatives Suggestion to remove Mesh Management/Mesh Action (7.3.1.18) frames, since existing Action Frames should be sufficient –Counter: make Mesh Management a multihop Action Frame Suggestion to remove Mesh Management/Mesh Action frames, since Action Encapsulation Frame (7.4.6.13) should be sufficient –Counter: Action Encapsulation is not designed to carry mesh management IEs. If it did, it would become the worst spaghetti action frame to-date. Suggestion to disallow forwarding of action frames across multiple hops (removing need for either Mesh Management/Mesh Action frames or Action Encapsulation Frame) –Reject: suggestion makes direct MP to portal communication impossible, and would require the creation of a new EAP transport protocol over multiple hops Suggestion to use the RRB mechanism from.11r to support multi-hop action frames –Reject: “Over-the-DS” communication should not be used for intra-mesh management. 11r needs RRB data frames because it cannot use 802.11 to communicate directly. One purpose of 11s is to do 11r without the DS. Suggestion to remove the term “Mesh Action Data Unit” –Accept: it is redundant terminology. MAC Management Protocol Data Unit (MMPDU) in a Mesh Management frame is sufficient. The term “Action” does not add value.