doc.: ieee 802.11-07/0550r1 submission april 2007 guenael strutt, motorola etalslide 1 multihop...
DESCRIPTION
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 2900TRANSCRIPT
April 2007
Guenael Strutt, Motorola etal
Slide 1
doc.: IEEE 802.11-07/0550r1
Submission
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 <http:// 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 <[email protected]> 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 <[email protected]>.
Date: 2007-04-13
Name Company Address Phone email
Guenael Strutt Motorola 1064 Greenwood Blvd, Lake Mary, FL 32746
+1-407-562-4050 [email protected]
Jan Kruys Cisco Systems Cisco Way Bld 14 San Jose, CA
+ 31 348 453719 [email protected]
Steve Conner Intel
Authors:
April 2007
Guenael Strutt, Motorola etal
Slide 2
doc.: IEEE 802.11-07/0550r1
Submission
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
April 2007
Guenael Strutt, Motorola etal
Slide 3
doc.: IEEE 802.11-07/0550r1
Submission
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
April 2007
Guenael Strutt, Motorola etal
Slide 4
doc.: IEEE 802.11-07/0550r1
Submission
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
April 2007
Guenael Strutt, Motorola etal
Slide 5
doc.: IEEE 802.11-07/0550r1
Submission
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”
April 2007
Guenael Strutt, Motorola etal
Slide 6
doc.: IEEE 802.11-07/0550r1
Submission
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
TYPE SUBTYPE CATEGORY ACTION IE
MANAGEMENT00
ACTION1101
MESH MGT00000100
PLM/OPEN00000000
MANAGEMENT00
ACTION1101
MESH MGT00000100
PLM/CLOSE00000001
MANAGEMENT00
ACTION1101
MESH MGT00000100
HWMP/RREQ00000010
MANAGEMENT00
ACTION1101
MESH MGT00000100
HWMP/RREP00000011
etc
“MES
H M
AN
AG
EMEN
T”
April 2007
Guenael Strutt, Motorola etal
Slide 7
doc.: IEEE 802.11-07/0550r1
Submission
Current approach (draft 1.0x)
• “Multihop management can use the mesh action encapsulation frame” (aka the “the spaghetti action frame”)
TYPE SUBTYPE
CATEGORY ACTION
PAYLOADMANAGEMENT
00ACTION1101
INFORMATION ELEMENT
TXx
MESH MGT00000100
RXY
MESH ENCAPS00000101
SOURCEA
DESTB
HWMP00000100
PROXY REG00000010
CATEGORY ACTION
ENCAPSULATED PAYLOAD
SIMPLIFIED HEADER
PRICE TO PAY FOR “SIMPLICITY”
April 2007
Guenael Strutt, Motorola etal
Slide 8
doc.: IEEE 802.11-07/0550r1
Submission
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?
April 2007
Guenael Strutt, Motorola etal
Slide 9
doc.: IEEE 802.11-07/0550r1
Submission
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
TYPE SUBTYPE CATEGORY ACTION IE
EXTENDED11
MESH MGT0000
PLM00000000
OPEN00000000
EXTENDED 11
MESH MGT0000
PLM00000000
CLOSE00000001
EXTENDED 11
MESH MGT0000
HWMP00000001
RREQ00000000
EXTENDED 11
MESH MGT0000
HWMP00000001
RREP00000001
etc
“MES
H M
AN
AG
EMEN
T”
April 2007
Guenael Strutt, Motorola etal
Slide 10
doc.: IEEE 802.11-07/0550r1
Submission
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 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!
April 2007
Guenael Strutt, Motorola etal
Slide 11
doc.: IEEE 802.11-07/0550r1
Submission
Current Category values are very sparse
Code Meaning 0 Spectrum management 1 QoS 2 DLS3 Block Ack
4–126 Reserved127 Vendor Specific255 Error (reserved for error processing)
April 2007
Guenael Strutt, Motorola etal
Slide 12
doc.: IEEE 802.11-07/0550r1
Submission
..use some for mesh management!
Code Meaning 0 Spectrum management 1 QoS 2 DLS3 Block Ack
4–15 Reserved16-112 Mesh Management127 Vendor specific255 Error (reserved for error processing)
April 2007
Guenael Strutt, Motorola etal
Slide 13
doc.: IEEE 802.11-07/0550r1
Submission
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
TYPE SUBTYPE CATEGORY ACTION, e.g. IE
MANAGEMENT00
ACTION1101
MESH DISC00010000
DIC/BEACON00000000
MANAGEMENT00
ACTION1101
MESH PLM0010000
PLM/OPEN00000000
MANAGEMENT00
ACTION1101
M-ROUT 00110000
HWMP/RREQ00000000
MANAGEMENT00
ACTION1101
MESH SEC010000
HWMP/RREP0000001
etc
“MES
H M
AN
AG
EMEN
T”
April 2007
Guenael Strutt, Motorola etal
Slide 14
doc.: IEEE 802.11-07/0550r1
Submission
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
April 2007
Guenael Strutt, Motorola etal
Slide 15
doc.: IEEE 802.11-07/0550r1
Submission
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 subtype]
April 2007
Guenael Strutt, Motorola etal
Slide 16
doc.: IEEE 802.11-07/0550r1
Submission
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.
April 2007
Guenael Strutt, Motorola etal
Slide 17
doc.: IEEE 802.11-07/0550r1
Submission
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
April 2007
Guenael Strutt, Motorola etal
Slide 18
doc.: IEEE 802.11-07/0550r1
Submission
• 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
April 2007
Guenael Strutt, Motorola etal
Slide 19
doc.: IEEE 802.11-07/0550r1
Submission
References
• doc.: IEEE 802.11-07/0250r1 (Slide 8)• doc.: IEEE 802.11-07-0023r19 (Issue Identifier G13,
G22)
April 2007
Guenael Strutt, Motorola etal
Slide 20
doc.: IEEE 802.11-07/0550r1
Submission
Background: Type/Subtype/Category
One category for all mesh actions?
One Action for both single
hop and multihop
management?
Two address format
April 2007
Guenael Strutt, Motorola etal
Slide 21
doc.: IEEE 802.11-07/0550r1
Submission
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
April 2007
Guenael Strutt, Motorola etal
Slide 22
doc.: IEEE 802.11-07/0550r1
Submission
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…
April 2007
Guenael Strutt, Motorola etal
Slide 23
doc.: IEEE 802.11-07/0550r1
Submission
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.