doc.: ieee 802.11-07/0550r0 submission march 2007 guenael strutt, motorola e.a.slide 1 multihop...

March 2007

Guenael Strutt, Motorola e.a.

Slide 1

doc.: IEEE 802.11-07/0550r0

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-012

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]

Authors:

March 2007


Slide 2

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 3

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 4

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 5

doc.: IEEE 802.11-07/0550r0

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”

March 2007


Slide 6

doc.: IEEE 802.11-07/0550r0

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

“ME

SH

MA

NA

GE

ME

NT

”

March 2007


Slide 7

doc.: IEEE 802.11-07/0550r0

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

PAYLOAD

MANAGEMENT00

ACTION1101

INFORMATION ELEMENT

TXx

MESH MGT00000100

RXY

MESH ENCAPS00000101

SOURCEA

DESTB

HWMP00000100

PROXY REG00000010

CATEGORY ACTION

ENCAPSULATED PAYLOAD

SIMPLIFIED HEADER

PRICE TO PAY FOR “SIMPLICITY”

March 2007


Slide 8

doc.: IEEE 802.11-07/0550r0

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?

March 2007


Slide 9

doc.: IEEE 802.11-07/0550r0

Submission

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

TYPE SUBTYPE CATEGORY ACTION IE

MESH11

MANAGEMENT0000

PLM00000000

OPEN00000000

MESH11

MANAGEMENT0000

PLM00000000

CLOSE00000001

MESH11

MANAGEMENT0000

HWMP00000001

RREQ00000000

MESH11

MANAGEMENT0000

HWMP00000001

RREP00000001

etc

“ME

SH

MA

NA

GE

ME

NT

”

March 2007


Slide 10

doc.: IEEE 802.11-07/0550r0

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 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!

March 2007


Slide 11

doc.: IEEE 802.11-07/0550r0

Submission

Current Category values are very sparse

Code Meaning 0 Spectrum management 1 QoS 2 DLS3 Block Ack

4–126 Reserved127 Vendor Specific

255 Error (reserved for error processing)

March 2007


Slide 12

doc.: IEEE 802.11-07/0550r0

Submission

..use some for mesh management!

Code Meaning 0 Spectrum management 1 QoS 2 DLS3 Block Ack

4–15 Reserved16-112 Mesh Management127 Vendor specific

255 Error (reserved for error processing)

March 2007


Slide 13

doc.: IEEE 802.11-07/0550r0

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

“ME

SH

MA

NA

GE

ME

NT

”

March 2007


Slide 14

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 15

doc.: IEEE 802.11-07/0550r0

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 subtypesubtype]

March 2007


Slide 16

doc.: IEEE 802.11-07/0550r0

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 vlaide

frame– However, by setting TO DS and FROM DS to 1, that is avoided.

March 2007


Slide 17

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 18

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 19

doc.: IEEE 802.11-07/0550r0

Submission

References

• doc.: IEEE 802.11-07/0250r1 (Slide 8)

• doc.: IEEE 802.11-07-0023r19 (Issue Identifier G13, G22)

March 2007


Slide 20

doc.: IEEE 802.11-07/0550r0

Submission

Background: Type/Subtype/Category

One category for all mesh actions?

One Action for both single

hop and multihop

management?

Two address format

March 2007


Slide 21

doc.: IEEE 802.11-07/0550r0

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

March 2007


Slide 22

doc.: IEEE 802.11-07/0550r0

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…

March 2007


Slide 23

doc.: IEEE 802.11-07/0550r0

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.

doc.: ieee 802.11-07/0550r0 submission march 2007 guenael strutt, motorola e.a.slide 1 multihop...

Documents