doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 1 Multihop Management Frames and other matters 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, 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. Date: Authors:

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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”

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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 PLM/OPEN MANAGEMENT 00 ACTION 1101 MESH MGT PLM/CLOSE MANAGEMENT 00 ACTION 1101 MESH MGT HWMP/RREQ MANAGEMENT 00 ACTION 1101 MESH MGT HWMP/RREP etc “MESH MANAGEMENT”

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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 RX Y MESH ENCAPS SOURCE A DEST B HWMP PROXY REG CATEGORYACTION ENCAPSULATED PAYLOAD SIMPLIFIED HEADER PRICE TO PAY FOR “SIMPLICITY”

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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?

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 9 Alternative #1 Mesh Management is a separate frame type/subtype Pros: –Uses the same addressing and header conventions as data frames Cons: –Requires a new type/subtype –Mesh management is a subtype of mesh, instead of a type TYPESUBTYPECATEGORYACTIONIE EXTENDED 11 MESH MGT 0000 PLM OPEN EXTENDED 11 MESH MGT 0000 PLM CLOSE EXTENDED 11 MESH MGT 0000 HWMP RREQ EXTENDED 11 MESH MGT 0000 HWMP RREP etc “MESH MANAGEMENT”

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 10 Alternative #1 The solution is to have a mesh management subtype ( ) This subtype takes full advantage of the four address format Single-hop broadcast 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!

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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)

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 12..use some for mesh management! Code Meaning 0 Spectrum management 1 QoS 2 DLS 3 Block Ack 4–15 Reserved Mesh Management 127Vendor specific 255 Error (reserved for error processing)

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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 DIC/BEACON MANAGEMENT 00 ACTION 1101 MESH PLM PLM/OPEN MANAGEMENT 00 ACTION 1101 M-ROUT HWMP/RREQ MANAGEMENT 00 ACTION 1101 MESH SEC HWMP/RREP etc “MESH MANAGEMENT”

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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: Actions are defined first by their category (one octet), then by an action (variable length) Two possibilities: 1.Create an encapsulation category (e.g /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 subtype]

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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 valid frame –However, by setting TO DS and FROM DS to 1, that is avoided.

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 17 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 18 Keep Mesh Management/Action ( ) –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 ( 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 19 References doc.: IEEE /0250r1 (Slide 8) doc.: IEEE r19 (Issue Identifier G13, G22)

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 20 Background: Type/Subtype/Category One category for all mesh actions? One Action for both single hop and multihop management ? Two address format

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 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…

doc.: IEEE /0550r1 Submission April 2007 Guenael Strutt, Motorola etalSlide 23 Suggested alternatives Suggestion to remove Mesh Management/Mesh Action ( ) 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 ( ) 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 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.