11s

IEEE P802.11s/D1.
05, June 2007
1
2 IEEE P802.11s™/D1.05
3
4
5
6
7
Draft STANDARD for
8
9
Information Technology-
10
11 Telecommunications and information exchange
12
13 between systems-
14
15
16
Local and metropolitan area networks-
17
18 Specific requirements-
19
20
21
22
23
Part 11: Wireless LAN Medium Access Control
24
25
(MAC) and Physical Layer (PHY) specifications
26
27
28
29 Amendment <number>: Mesh Networking
30
31
32 EDITORIAL NOTE—the amendment number will be inserted by IEEE-SA editorial staff during
33
preparation for publication.
34
35
36
37
38 Prepared by the 802.11 Working Group of the IEEE 802 Committee
39
40 Copyright © 2007 by the IEEE.
41
42 3 Park Avenue
43 New York, NY 10016-5997, USA
44
45 All rights reserved.
46
47
48 This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to
49 change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be
50 utilized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards
51
52 Committee participants to reproduce this document for purposes of IEEE standardization activities only.
53 Prior to submitting this document to another standards development organization for standardization
54 activities, permission must first be obtained from the Manager, Standards Intellectual Property, IEEE
55
Standards Activities Department. Other entities seeking permission to reproduce this document, in whole or
56
57 in part, must obtain permission from the Manager, Standards Intellectual Property, IEEE Standards
58 Activities Department.
59
60
61 IEEE Standards Activities Department
62 Standards Licensing and Contracts
63
64 445 Hoes Lane, P.O. Box 1331
65 Piscataway, NJ 08855-1331, USA
Copyright © 2007 IEEE. All rights reserved. i

This is an unapproved IEEE Standards Draft, subject to change.
IEEE P802.11s/D1.05, June 2007
1 Abstract: This amendment defines an IEEE 802.11 Wireless LAN (WLAN) Mesh using the IEEE
2 802.11 MAC/PHY layers that supports both individually addressed and group addressed delivery
3
over self-configuring multi-hop topologies.
4
5
6 Keywords: Wireless LAN, Medium Access Control, Mesh, Multi-hop
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
ii Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1
2
Introduction
3
4 (This introduction is not part of IEEE P802.11s/D1.05, Draft Amendment to Standard for
5 Information Technology - Telecommunications and Information Exchange Between Systems - LAN/
6 MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer
7
8 (PHY) specifications: Amendment: Mesh Networking.)
9
10 This amendment specifies enhancements to the following draft standard and draft amendments, in order to
11 support mesh networking:
12
13 — IEEE P802.11-2007
14
15 — IEEE P802.11k D7.0
16 — IEEE P802.11n D2.02
17
18 — IEEE P802.11r D5.0
19
— IEEE P802.11w D2.0
20
21 — IEEE P802.11y D2.0
22
23
24 The networks described in this amendment make use of layer-2 mesh path selection and forwarding (that is,
25 a mesh network that performs routing at the link layer). Mesh networks have advantageous properties in
26 terms of robustness, range extension and density, but also have potential challenges such as power consump-
27 tion and security. This amendment is specifically designed to address these challenges.
28
29
30
31 Notice to users
32
33
34 Errata
35
36 Errata, if any, for this and all other standards can be accessed at the following URL: http://
37
38 standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for
39 errata periodically.
40
41
42 Interpretations
43
44
45 Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/
46 index.html.
47
48
49 Patents
50
51
52
Attention is called to the possibility that implementation of this standard may require use of subject matter
53 covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
54 validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying
55 patents or patent applications for which a license may be required to implement an IEEE standard or for
56 conducting inquiries into the legal validity or scope of those patents that are brought to its attention. A patent
57
58
holder or patent applicant has filed a statement of assurance that it will grant licenses under these rights
59 without compensation or under reasonable rates and nondiscriminatory, reasonable terms and conditions to
60 applicants desiring to obtain such licenses. The IEEE makes no representation as to the reasonableness of
61 rates, terms, and conditions of the license agreements offered by patent holders or patent applicants. Further
62 information may be obtained from the IEEE Standards Department.
63
64
65
Copyright © 2007 IEEE. All rights reserved. iii

IEEE P802.11s/D1.05, June 2007
1 Participants
2
3
4 At the time this draft amendment to standard was completed, the 802.11 Working Group had the following
5 membership:
6
7 Stuart J. Kerry, Chair
8
9 Al Petrick and Harry Worstell, Vice-chair
10 Tim Godfrey, Secretary
11
12
13
14 EDITORIAL NOTE—a three column list of voting members of 802.11 on the day the draft was sent for
15
16 sponsor ballot will be inserted
17
18
19 The following were officers of Task Group s:
20
21 Donald E. Eastlake 3rd, Chair
22 Stephen Rayment, Secretary
23
24
W. Steven Conner, Technical Editor
25
26 The following members of the balloting committee voted on this Standard. Balloters may have voted for
27
28 approval, disapproval, or abstention.
29
30
31
32 EDITORIAL NOTE—a three-column list of responding sponsor ballot members will be inserted by IEEE
33 staff
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
iv Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1
2
Editorial Notes
3
4 EDITORIAL NOTE—Two forms of editorial markup are used: Notes and Comments. Editorial Notes
5 and Editorial Comments are not part of the amendment and will be removed before it is published,
6 together with any other contents in this subclause. This paragraph is an example of how an Editorial
7
Note is marked. Editorial Comments are marked (Ed:), and contain references to submissions or
8
9 comment resolutions to track the origin of changes.
10
11 EDITORIAL NOTE—Headings with empty content or Headings preceding editing instructions that
12 modify the contents of the referenced subclause are there to provide context to the reader of this
13 document, they have no other significance.
14
15
EDITORIAL NOTE—Except when referring to tables and figures that exist in the baseline, figure and
16
17 table numbers are preceded by “s” and are assigned sequentially. This will be changed prior to sponsor
18 ballot.
19
20 EDITORIAL NOTE—The default IEEE-SA style for tables is to “float”. This means that they be
21 repositioned later, usually at the head of the next page, to avoid splitting the table and reduce the amount
22
of blank space. The table can appear to move out of the subclause it is referenced first from, and can even
23
24 split a paragraph. This is the intended IEEE-SA behavior, please do not report it as a defect in the draft.
25
26 EDITORIAL NOTE—Line numbering is only approximate. This is a limitation of the FrameMaker tool.
27 Whitespace between paragraphs is part of the IEEE-SA style, as defined in their templates. The
28 combination of these two facts leads to the appearance of blank lines in the draft between every
29
paragraph. Please do not report this as an editorial defect as it is the unavoidable behavior.
30
31
32 EDITORIAL NOTE—New subclauses are generally introduced by an editorial instruction “insert the
33 following new subclause”. New subclause headings are generally introduced by an editorial instruction
34 “insert the following new subclause heading”. Each new heading or subclause has its own editorial
35 instruction. The instruction intentionally does not include where to insert the subclause because that is
36
determined uniquely by the subclause number.
37
38
39 EDITORIAL NOTE—Pronunciation. It is assumed that while reading the spec aloud, a reader will read
40 “MP” as “emm pea” rather than read it as “mesh point”. This determines the spelling of the indefinite
41 article to be “an” rather than “a”
42
43
44
45
46 .
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Copyright © 2007 IEEE. All rights reserved. i

IEEE P802.11s/D1.05, June 2007
1 Status of this document

2
3
4 Draft Date Changes
5
6 D1.01 2007-03-09 Conversion of draft from Word format to FrameMaker format.
7 Implementation of most comment resolutions marked as Accept/
8
9 Counter in 11-07/23r5 and 11-07/23r6 adopted by motions during
10 January 2007 meeting. Implemented resolutions are marked with
11 “D1.01” in “Edited in Draft” column of 11-07/23r20.
12
13 D1.02 2007-03-27 Implementation of resolutions marked with D1.02 in “Edited in
14 Draft” column of 11-07/23r26.
15
16 D1.03 2007-04-06 Updated draft to correspond to latest baseline documents: IEEE
17 P802.11-2007, .11k D7.0, .11r D5.0, .11y D2.0. Editorial fixes to
18 implementation of changes in 11-07/286r0 and 11-07/440r0. Imple-
19
20 mentation of resolutions marked with D1.03 in “Edited in Draft” col-
21 umn of 11-07/23r27.
22
23 D1.04 2007-06-06 Implementation of draft changes adopted in the May 2007 interim
24 meeting in Montreal, including resolutions marked with D1.04 in
25 “Edited in Draft” column of 11-07/23r36. Updated draft to corre-
26 spond to latest baseline documents: IEEE .11n D2.02, .11w D2.0.
27
Editorial updates for consistency with .11 WG editors best practices.
28
29 D1.05 2007-06-25 Updated draft to reflect editorial revisions in published baseline doc-
30
31 ument P802.11-2007 (primarily changes to figure and table num-
32 bers). Fixed formatting issues in tables throughout clause 11A.
33 Editorial fixes to implementation of changes in 11-07/618r0 and 11-
34 07/631r1. Cleanup of editorial notes throughout the draft.
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Copyright © 2007 IEEE. All rights reserved. ii

IEEE P802.11s/D1.05, June 2007
1
2
3
Table of Contents
4
5
6
7
8
9
10
11 3. Definitions ................................................................................................................................................. 2
12
13 4. Abbreviations and acronyms ..................................................................................................................... 3
14
15
16 5. General description .................................................................................................................................... 4
17
18 5.2 Components of the IEEE 802.11 architecture ............................................................................. 4
19 5.2.9 Wireless LAN mesh..................................................................................................... 4
20
5.2.9.1 Introduction to mesh ................................................................................ 4
21
22 5.2.9.2 Mesh network model ............................................................................... 5
23 5.2.9.3 Organization of mesh subclauses............................................................. 6
24
25 7. Frame formats ............................................................................................................................................ 7
26
27
28 7.1 MAC frame formats..................................................................................................................... 7
29 7.1.2 General frame format................................................................................................... 7
30 7.1.3 Frame fields ................................................................................................................. 8
31 7.1.3.1 Frame control field................................................................................... 8
32
7.1.3.1.2 Type and subtype fields ..................................................... 8
33
34 7.1.3.1.3 To DS and From DS fields ................................................ 8
35 7.1.3.1.6 Power Management field ................................................... 8
36 7.1.3.1.8 More Data field.................................................................. 8
37 7.1.3.5a Mesh Header field.................................................................................... 9
38
7.1.3.5a.1 General............................................................................... 9
39
40 7.1.3.5a.2 Mesh Flags field................................................................. 9
41 7.1.3.5a.3 Mesh Time to Live field .................................................. 10
42 7.1.3.5a.4 Mesh Sequence Number field.......................................... 10
43 7.1.3.5a.5 Mesh Address Extension field ......................................... 10
44
7.2 Format of individual frame types............................................................................................... 10
45
46 7.2.1.4 PS-Poll frame format ............................................................................. 10
47 7.2.3 Management frames................................................................................................... 11
48 7.2.3.1 Beacon frame format ............................................................................. 12
49 7.2.3.3 IBSS ATIM frame format...................................................................... 12
50
7.2.3.4 Probe Request frame format .................................................................. 12
51
52 7.2.3.5 Probe Response frame format................................................................ 12
53 7.2.4 Extended frames ........................................................................................................ 14
54 7.2.4.1 General................................................................................................... 14
55 7.2.4.2 Mesh Data frame format ........................................................................ 14
56
7.2.4.3 Mesh Management frame format........................................................... 14
57
58 7.3 Management frame body components ....................................................................................... 16
59 7.3.1 Fields that are not information elements.................................................................... 16
60 7.3.1.4 Capability Information field .................................................................. 16
61 7.3.1.7 Reason Code field .................................................................................. 16
62
7.3.1.8 AID field ................................................................................................ 16
63
64 7.3.1.9 Status Code field.................................................................................... 17
65 7.3.1.11 Action field ............................................................................................ 17
Copyright © 2007 IEEE. All rights reserved. iii

IEEE P802.11s/D1.05, June 2007
1 7.3.1.17 QoS Info field ........................................................................................ 17

2 7.3.1.34 Mesh Action field .................................................................................. 18
3
7.3.1.35 Message integrity check field ................................................................ 18
4
5 7.3.1.36 Mesh Key Transport Control field......................................................... 18
6 7.3.1.37 Mesh Wrapped Key field ....................................................................... 19
7 7.3.2 Information elements ................................................................................................. 20
8 7.3.2.1 SSID element ......................................................................................... 21
9
7.3.2.25 RSN information element ..................................................................... 22
10
11 7.3.2.25.2 AKM Suites ..................................................................... 22
12 7.3.2.54 Mesh Configuration element ................................................................. 22
13 7.3.2.54.1 Active Path Selection Protocol Identifier ........................ 22
14 7.3.2.54.2 Active Path Selection Metric Identifier ........................... 23
15
7.3.2.54.3 Channel Precedence ......................................................... 24
16
17 7.3.2.54.4 Mesh Capability............................................................... 24
18 7.3.2.55 Mesh ID element.................................................................................... 24
19 7.3.2.56 Link metric report element .................................................................... 25
20 7.3.2.57 Mesh ATIM window parameter element............................................... 25
21
7.3.2.58 Target Transmission Rate element ........................................................ 26
22
23 7.3.2.59 Offered Traffic Load element ................................................................ 26
24 7.3.2.60 Neighborhood Congestion element ....................................................... 26
25 7.3.2.61 Peer Link Management element ............................................................ 27
26 7.3.2.62 Mesh Channel Switch Announcement element ..................................... 28
27
7.3.2.63 Mesh Neighbor List element.................................................................. 28
28
29 7.3.2.64 Mesh TIM element................................................................................. 30
30 7.3.2.65 Beacon Timing element ......................................................................... 31
31 7.3.2.66 MDAOP Setup Request element ........................................................... 33
32 7.3.2.67 MDAOP Setup Reply element............................................................... 34
33
7.3.2.68 MDAOP Advertisements Request element ........................................... 34
34
35 7.3.2.69 MDAOP Advertisements element ......................................................... 34
36 7.3.2.70 MDAOP Set Teardown element ............................................................ 35
37 7.3.2.71 Connectivity Report element ................................................................ 36
38 7.3.2.72 PANN information element ................................................................... 37
39
7.3.2.73 RANN information element................................................................... 38
40
41 7.3.2.74 PREQ information element.................................................................... 38
42 7.3.2.75 PREP information element .................................................................... 40
43 7.3.2.76 PERR Information element.................................................................... 41
44 7.3.2.77 Proxy Update (PU) information element ............................................... 42
45
7.3.2.78 Proxy Update Confirmation (PUC) information element...................... 42
46
47 7.3.2.79 RA-OLSR Common Information elements ........................................... 43
48 7.3.2.79.1 HELLO element............................................................... 43
49 7.3.2.79.2 Topology Control (TC) element ...................................... 44
50 7.3.2.79.3 Multiple Interface Declaration (MID) element................ 45
51
7.3.2.79.4 Local Association Base Advertisement (LABA) element45
52
53 7.3.2.79.5 Local Association Base Checksum Advertisement (LAB-
54 CA) element 46
55 7.3.2.79.6 Association Base Block Request (ABBR) element ......... 46
56 7.3.2.80 Mesh security capability information element [MSCIE]....................... 46
57
7.3.2.81 MSA information element [MSAIE] ..................................................... 48
58
59 7.4 Action frame format details ....................................................................................................... 50
60 7.4.9 Mesh Peer Link Management action frame details ................................................... 50
61 7.4.9.1 Peer Link Open frame format ................................................................ 50
62 7.4.9.2 Peer Link Confirm frame format ........................................................... 51
63
7.4.9.3 Peer Link Close frame format................................................................ 52
64
65 7.4.10 Mesh Link Metric action frame details...................................................................... 52
iv Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1 7.4.10.1 Link Metric Request frame format ........................................................ 53

2 7.4.10.2 Link Metric Report frame format .......................................................... 53
3
7.4.11 Mesh Path Selection action frame details .................................................................. 54
4
5 7.4.11.1 Path Request frame format .................................................................... 54
6 7.4.11.2 Path Reply frame format........................................................................ 54
7 7.4.11.3 Path Error frame format ......................................................................... 55
8 7.4.11.4 Root Announcement frame format ........................................................ 55
9
7.4.11.5 RA-OLSR frame format ........................................................................ 56
10
11 7.4.12 Mesh Interworking action frame details .................................................................... 56
12 7.4.12.1 Portal Announcement frame format ...................................................... 57
13 7.4.13 Mesh Resource Coordination action frame details .................................................... 57
14 7.4.13.1 Congestion Control Request frame format ............................................ 58
15
7.4.13.2 Congestion Control Response frame format.......................................... 58
16
17 7.4.13.3 Neighborhood Congestion Announcement frame format...................... 58
18 7.4.13.4 Mesh Deterministic Access frame format ............................................. 59
19 7.4.13.5 Beacon Timing Request frame format................................................... 59
20 7.4.13.6 Beacon Timing Response frame format ................................................ 60
21
7.4.13.7 Mesh Channel Switch Announcement frame format............................. 60
22
23 7.4.13.8 Connectivity Report frame format ......................................................... 61
24 7.4b Mesh Action (4-addr action frames) .......................................................................................... 61
25 7.4b.1 MSA mesh action details ........................................................................................... 61
26 7.4b.1.1 Mesh key holder security establishment frame format .......................... 62
27
7.4b.1.2 PMK-MA delivery push frame format .................................................. 63
28
29 7.4b.1.3 PMK-MA confirm frame format ........................................................... 64
30 7.4b.1.4 PMK-MA request frame format ............................................................ 64
31 7.4b.1.5 PMK-MA delivery pull frame format.................................................... 65
32 7.4b.1.6 PMK-MA delete frame format .............................................................. 65
33
7.4b.1.7 Mesh EAP encapsulation frame format ................................................. 66
34
35
36 8. Security .................................................................................................................................................... 68
37
38 8.2 Pre-RSNA security methods ...................................................................................................... 68
39
8.4.1.1 Security association definitions ............................................................. 68
40
41 8.4.1.1.1A PMK-MKD SA ................................................................ 68
42 8.4.1.1.1B PMK-MA SA................................................................... 68
43 8.5 Keys and key distribution .......................................................................................................... 68
44 8.5.2 EAPOL-Key frames................................................................................................... 68
45
8.5.2.1 EAPOL-Key frame notation .................................................................. 69
46
47 8.5.3 4-Way Handshake...................................................................................................... 70
48 8.5.3.1 4-Way Handshake Message 1................................................................ 70
51
8.5.3.4 4-Way Handshake Message 4................................................................ 70
52
53 8.5.4 Group Key Handshake............................................................................................... 70
54 8.5.4.1 Group Key Handshake Message 1......................................................... 70
55 8.5.4.2 Group Key Handshake Message 2......................................................... 70
56 8.8 Key distribution for MSA .......................................................................................................... 71
57
8.8.1 Overview.................................................................................................................... 71
58
59 8.8.2 Key hierarchy............................................................................................................. 72
60 8.8.3 Key derivation function ............................................................................................. 73
61 8.8.4 PMK-MKD ................................................................................................................ 73
62 8.8.5 PMK-MA ................................................................................................................... 74
63
8.8.6 PTK ............................................................................................................................ 75
64
65 8.8.7 MKDK ....................................................................................................................... 76
Copyright © 2007 IEEE. All rights reserved. v

IEEE P802.11s/D1.05, June 2007
1 8.8.8 MPTK-KD ................................................................................................................. 76

2 8.8.9 Mesh key holders ....................................................................................................... 77
3
8.8.9.1 Key holder requirements........................................................................ 77
4
5 8.8.9.2 Authorization of mesh key holders........................................................ 78
6 8.8.9.3 PMK-MA distribution within an MKD domain .................................... 78
7
8 9. MAC sublayer functional description...................................................................................................... 80
9
10
11 9.21 MDA (Optional) ........................................................................................................................ 80
12 9.21.1 MDA opportunity (MDAOP) .................................................................................... 80
13 9.21.2 MDAOP sets .............................................................................................................. 80
14 9.21.3 MDA TXOP............................................................................................................... 80
15
9.21.4 Neighborhood MDAOP times at an MP.................................................................... 80
16
17 9.21.5 Neighbor MDAOP interfering times for an MP ........................................................ 81
18 9.21.6 MDA access fraction (MAF) ..................................................................................... 81
19 9.21.7 Action frames for MDAOPs setup, teardown, and MDAOP advertisements ........... 81
20 9.21.8 MDAOP setup procedure........................................................................................... 81
21
9.21.9 MDAOP advertisements ............................................................................................ 82
22
23 9.21.10 MDAOP set teardown................................................................................................ 82
24 9.21.11 Access during MDAOPs............................................................................................ 83
25
26 10. Layer management................................................................................................................................... 84
27
28
29 10.3 MLME SAP interface ................................................................................................................ 84
30 10.3.39 PassivePeerLinkOpen ................................................................................................ 84
31 10.3.39.1 MLME-PassivePeerLinkOpen.request .................................................. 84
32 10.3.39.1.1 Function ........................................................................... 84
33
10.3.39.1.2 Semantics of the service primitive................................... 84
34
35 10.3.39.1.3 When generated ............................................................... 84
36 10.3.39.1.4 Effect of receipt ............................................................... 84
37 10.3.39.2 MLME-PassivePeerLinkOpen.confirm ................................................. 84
38 10.3.39.2.1 Function ........................................................................... 84
39
10.3.39.2.2 Semantics of the service primitive................................... 85
40
41 10.3.39.2.3 When generated ............................................................... 85
43 10.3.40 ActivePeerLinkOpen ................................................................................................. 85
44 10.3.40.1 MLME-ActivePeerLinkOpen.request.................................................... 85
45
10.3.40.1.1 Function ........................................................................... 85
46
47 10.3.40.1.2 Semantics of the service primitive................................... 85
48 10.3.40.1.3 When generated ............................................................... 85
50 10.3.40.2 MLME-ActivePeerLinkOpen.confirm .................................................. 86
51
10.3.40.2.1 Function ........................................................................... 86
52
54 10.3.40.2.3 When generated ............................................................... 86
56 10.3.41 SignalPeerLinkStatus................................................................................................. 86
57
10.3.41.1 MLME-SignalPeerLinkStatus.indication .............................................. 87
58
59 10.3.41.1.1 Function ........................................................................... 87
61 10.3.41.1.3 When generated ............................................................... 87
63
10.3.42 CancelPeerLink.......................................................................................................... 87
64
65 10.3.42.1 MLME-CancelPeerLink.request............................................................ 87
vi Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1 10.3.42.1.1 Function ........................................................................... 87

3
10.3.42.1.3 When generated ............................................................... 88
4
6 10.3.42.2 MLME-CancelPeerLink.confirm........................................................... 88
7 10.3.42.2.1 Function ........................................................................... 88
9
10.3.42.2.3 When generated ............................................................... 88
10
12 10.3.43 Mesh layer management (Informative)...................................................................... 89
13 10.3.43.1 Principles of operation ........................................................................... 89
14 10.3.43.2 Inter-layer management ......................................................................... 90
15
10.3.43.3 Re-transmit process................................................................................ 90
16
17 10.3.43.4 Filtering database ................................................................................... 90
18 10.3.43.5 Forwarding database .............................................................................. 90
19 10.3.43.6 Learning cache ....................................................................................... 91
20 10.3.43.7 Protocol entity........................................................................................ 91
21
10.3.43.8 Service primitives .................................................................................. 91
22
23 10.3.43.8.1 MLME-SendMeshMgmt.request ..................................... 91
24 10.3.43.8.2 MLME-SendMeshMgmt.confirm.................................... 91
25 10.3.43.8.3 MLME-RecvMeshMgmt.request..................................... 91
26 10.3.43.8.4 MLME-RecvMeshMgmt.confirm.................................... 92
27
10.3.43.8.5 MLME-PathAdd.request.................................................. 92
28
29 10.3.43.8.6 MLME-PathAdd.confirm ................................................ 93
30 10.3.43.8.7 MLME-PathRemove.request ........................................... 93
31 10.3.43.8.8 MLME-PathRemove.confirm .......................................... 93
32
33
11. MLME ..................................................................................................................................................... 93
34
35
36 11.3 STA Authentication and Association ........................................................................................ 93
37 11.3.3 Additional Mechanisms for APs with Mesh Functionality ....................................... 93
38 11.9 DFS procedures.......................................................................................................................... 94
39
11.9.7 Selecting and advertising a new channel ................................................................... 94
40
41 11.9.7.2a Selecting and advertising a new channel in a mesh............................... 94
42
43 11A.Mesh networking ................................................................................................................................... 95
44
45
11A.1 Mesh discovery .......................................................................................................................... 95
46
47 11A.1.1 General....................................................................................................................... 95
48 11A.1.2 Use of mesh identifier................................................................................................ 95
49 11A.1.3 Profiles for extensibility............................................................................................. 95
50 11A.1.4 Candidate peer MP discovery .................................................................................... 95
51
11A.2 Mesh peer link management ...................................................................................................... 96
52
53 11A.2.1 Overview.................................................................................................................... 96
54 11A.2.2 Processing Peer Link Management Frames............................................................... 98
55 11A.2.2.1 Overview................................................................................................ 98
56 11A.2.2.2 Process Peer Link Close frames............................................................. 99
57
11A.2.2.3 Process Peer Link Open frames ............................................................. 99
58
59 11A.2.2.4 Process Peer Link Confirm frames ........................................................ 99
60 11A.2.3 Finite State Machine ................................................................................................ 100
61 11A.2.3.1 States .................................................................................................... 100
62 11A.2.3.2 Events and Actions .............................................................................. 100
63
11A.2.3.3 State transitions.................................................................................... 102
64
65 11A.2.3.4 IDLE state ............................................................................................ 105
Copyright © 2007 IEEE. All rights reserved. vii

IEEE P802.11s/D1.05, June 2007
1 11A.2.3.5 LISTEN state ....................................................................................... 105

2 11A.2.3.6 OPEN_SENT state............................................................................... 105
3
11A.2.3.7 CNF_RCVD state ................................................................................ 106
4
5 11A.2.3.8 OPEN_RCVD state.............................................................................. 107
6 11A.2.3.9 ESTAB state ....................................................................................... 108
7 11A.2.3.10 HOLDING state ................................................................................... 108
8 11A.3 Mesh network channel selection.............................................................................................. 108
9
11A.3.1 General..................................................................................................................... 108
10
11 11A.3.2 Simple channel unification protocol ........................................................................ 108
12 11A.3.3 Channel graph switch protocol ................................................................................ 109
13 11A.4 Mesh link security.................................................................................................................... 110
14 11A.4.1 Overview of MSA.................................................................................................... 110
15
11A.4.1.1 Mesh key holders ................................................................................. 110
16
17 11A.4.1.2 Discovery & MSA capability advertisement ....................................... 111
18 11A.4.1.3 Role determination............................................................................... 111
19 11A.4.1.4 Policy selection .................................................................................... 111
20 11A.4.1.5 MSA authentication ............................................................................. 112
21
11A.4.1.6 Mesh key holder security handshake ................................................... 113
22
23 11A.4.1.7 Mesh key and EAP message transport protocols................................. 114
24 11A.4.1.8 Secure link operation ........................................................................... 117
25 11A.4.2 MSA establishment procedure................................................................................. 117
26 11A.4.2.1 General................................................................................................. 117
27
11A.4.2.2 MSA authentication mechanism .......................................................... 117
28
29 11A.4.2.2.1 Peer Link Open message contents ................................. 118
30 11A.4.2.2.2 Processing Peer Link Open message ............................. 118
31 11A.4.2.2.3 Peer Link Confirm message contents ............................ 121
32 11A.4.2.2.4 Processing Peer Link Confirm message ........................ 122
33
11A.4.2.2.5 Initial MSA Authentication ........................................... 123
34
35 11A.4.2.2.6 MSA 4-way Handshake ................................................. 123
36 11A.4.2.3 MSA key holder communication......................................................... 124
37 11A.4.3 Mesh key holder security association ...................................................................... 124
38 11A.4.3.1 Mesh key distributor discovery............................................................ 125
39
11A.4.3.2 Mesh key holder security handshake ................................................... 125
40
41 11A.4.3.2.1 Mesh key holder security handshake message 1 ........... 125
44 11A.4.4 Mesh key transport protocol .................................................................................... 127
45
11A.4.4.1 Mesh key transport pull protocol ......................................................... 128
46
47 11A.4.4.2 Mesh key transport push protocol........................................................ 129
48 11A.4.4.3 Mesh key delete protocol ..................................................................... 131
49 11A.4.5 Mesh EAP message transport protocol .................................................................... 132
50 11A.4.5.1 EAP encapsulation request message.................................................... 132
51
11A.4.5.2 EAP encapsulation response message ................................................. 133
52
53 11A.5 Mesh path selection and forwarding framework ..................................................................... 134
54 11A.5.1 Overview.................................................................................................................. 134
55 11A.5.2 Extensible path selection framework ....................................................................... 134
56 11A.5.3 Path selection metrics and protocols........................................................................ 135
57
11A.5.4 Link metric reporting ............................................................................................... 135
58
59 11A.5.5 Frame addressing and forwarding in a mesh network ............................................. 135
60 11A.5.5.1 Overview.............................................................................................. 135
61 11A.5.5.2 Addressing and Forwarding of Unicast Frames ................................. 137
62 11A.5.5.2.1 At Source MPs ............................................................... 137
63
11A.5.5.2.2 At Intermediate and destination MPs............................. 137
64
65 11A.5.5.3 Addressing and Forwarding of Broadcast Frames .............................. 138
viii Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1 11A.5.5.3.1 At Source MPs ............................................................... 138

2 11A.5.5.3.2 At Intermediate and destination MPs............................. 139
3
11A.5.5.4 Multicast Frames.................................................................................. 139
4
5 11A.5.5.5 Note on 7.2.3 Management Frames .................................................... 139
6 11A.6 Interworking............................................................................................................................. 139
7 11A.6.1 Overview of interworking in a mesh ....................................................................... 139
8 11A.6.2 MPP announcement protocol................................................................................... 140
9
11A.6.2.1 Function ............................................................................................... 140
10
11 11A.6.2.2 Conditions for generating and sending a PANN ................................. 140
12 11A.6.2.3 PANN processing ................................................................................ 141
13 11A.6.2.3.1 Acceptance criteria ........................................................ 141
14 11A.6.2.3.2 Effect of receipt ............................................................. 142
15
11A.6.3 MP behavior............................................................................................................. 142
16
17 11A.6.4 MPP data forwarding behavior ................................................................................ 142
18 11A.6.4.1 Egress message handling ..................................................................... 142
19 11A.6.4.2 Ingress message handling .................................................................... 142
20 11A.6.5 Proxy protocol.......................................................................................................... 143
21
11A.6.5.1 Proxy Update (PU)............................................................................... 143
22
23 11A.6.5.1.1 Function ......................................................................... 143
24 11A.6.5.1.2 Conditions for generating and sending a PU ................. 143
25 11A.6.5.1.3 PU processing ................................................................ 144
26 11A.6.5.2 Proxy Update Confirmation (PUC) ..................................................... 144
27
11A.6.5.2.1 Function ......................................................................... 144
28
29 11A.6.5.2.2 Conditions for generating and sending a PUC............... 144
30 11A.6.5.2.3 PUC processing.............................................................. 144
31 11A.7 Airtime link metric computation procedures ........................................................................... 144
32 11A.8 Hybrid Wireless Mesh Protocol (HWMP)............................................................................... 145
33
11A.8.1 Overview.................................................................................................................. 145
34
35 11A.8.1.1 General................................................................................................. 145
36 11A.8.1.2 On demand path selection mode .......................................................... 146
37 11A.8.1.3 Proactive tree building mode ............................................................... 147
38 11A.8.1.3.1 Proactive PREQ mechanism .......................................... 147
39
11A.8.1.3.2 Proactive RANN mechanism......................................... 147
40
41 11A.8.2 Parameters for Extensible Path Selection Framework............................................. 148
42 11A.8.3 Definitions ............................................................................................................... 148
43 11A.8.4 General rules for processing HWMP information elements.................................... 150
44 11A.8.4.1 HWMP propagation............................................................................. 150
45
11A.8.4.2 Destination Sequence Number (DSN) ................................................. 150
46
47 11A.8.4.3 Metric of last link................................................................................. 151
48 11A.8.4.4 Forwarding information ....................................................................... 151
49 11A.8.4.5 Creation and update of forwarding information .................................. 151
50 11A.8.4.6 Repeated attempts at path discovery.................................................... 152
51
11A.8.4.7 Rate of sequence number changes ....................................................... 152
52
53 11A.8.5 Path Request (PREQ).............................................................................................. 152
54 11A.8.5.1 Function ............................................................................................... 153
55 11A.8.5.2 Conditions for generating and sending a PREQ .................................. 153
56 11A.8.5.3 PREQ processing ................................................................................. 159
57
11A.8.5.3.1 Acceptance criteria ........................................................ 159
58
60 11A.8.6 Path Reply (PREP)................................................................................................... 160
61 11A.8.6.1 Function ............................................................................................... 160
62 11A.8.6.2 Conditions for generating and sending a PREP................................... 160
63
11A.8.6.3 PREP processing.................................................................................. 164
64
Copyright © 2007 IEEE. All rights reserved. ix

IEEE P802.11s/D1.05, June 2007

2 11A.8.7 Path Error information element (PERR).................................................................. 164
3
11A.8.7.1 Function ............................................................................................... 165
4
5 11A.8.7.2 Conditions for generating and sending a PERR .................................. 165
6 11A.8.7.3 PERR Reception .................................................................................. 166
9
11A.8.8 Root Announcement (RANN) ................................................................................. 167
10
11 11A.8.8.1 Function ............................................................................................... 167
12 11A.8.8.2 Conditions for generating and sending a RANN ................................. 167
13 11A.8.8.3 RANN Reception ................................................................................. 168
15
11A.8.8.3.2 Effect of receipt ............................................................. 169
16
17 11A.8.9 Considerations for support of STAs without mesh functionality ............................ 169
18 11A.8.10 HWMP parameters .................................................................................................. 169
19 11A.9 Radio Aware OLSR path selection protocol (Optional) .......................................................... 169
20 11A.9.1 Introduction.............................................................................................................. 169
21
11A.9.2 Overview.................................................................................................................. 170
22
23 11A.9.2.1 Terminology......................................................................................... 170
24 11A.9.3 Parameters for Extensible Path Selection Framework............................................. 171
25 11A.9.4 Element processing and forwarding ........................................................................ 171
26 11A.9.4.1 Element processing and flooding......................................................... 171
27
11A.9.4.2 Default forwarding algorithm .............................................................. 172
28
29 11A.9.4.3 Considerations on processing and forwarding..................................... 173
30 11A.9.4.4 Element emission and jitter.................................................................. 173
31 11A.9.5 Information repositories........................................................................................... 174
32 11A.9.5.1 Link set ................................................................................................ 174
33
11A.9.5.2 Neighbor set ......................................................................................... 174
34
35 11A.9.5.3 Interface association set ....................................................................... 175
36 11A.9.5.4 2-hop neighbor set ............................................................................... 175
37 11A.9.5.5 MPR set................................................................................................ 176
38 11A.9.5.6 MPR selector set .................................................................................. 176
39
11A.9.5.7 Topology set ........................................................................................ 176
40
41 11A.9.5.7.1 Local Association Base (LAB) ...................................... 177
42 11A.9.5.7.2 Global Association Base (GAB).................................... 177
43 11A.9.6 Multiple Interface Declaration (MID) element........................................................ 178
44 11A.9.6.1 Conditions for generating a MID element ........................................... 178
45
11A.9.6.2 Conditions for forwarding a MID element .......................................... 178
46
47 11A.9.6.3 MID processing.................................................................................... 178
48 11A.9.6.4 Mapping interface addresses and MP addresses.................................. 179
49 11A.9.7 HELLO element....................................................................................................... 179
50 11A.9.7.1 Conditions for generating a HELLO element...................................... 179
51
11A.9.7.2 Conditions for forwarding a HELLO element ..................................... 180
52
53 11A.9.7.3 HELLO processing .............................................................................. 180
54 11A.9.8 Populating the neighbor set...................................................................................... 180
55 11A.9.8.1 HELLO element processing................................................................. 180
56 11A.9.9 Populating the 2-hop neighbor set ........................................................................... 181
57
11A.9.9.1 HELLO element processing................................................................. 181
58
59 11A.9.10 Populating the MPR set ........................................................................................... 181
60 11A.9.10.1 MPR Computation ............................................................................... 182
61 11A.9.11 Populating the MPR selector set .............................................................................. 183
62 11A.9.11.1 HELLO processing .............................................................................. 183
63
11A.9.11.2 Neighborhood and 2-hop neighborhood changes ................................ 183
64
65 11A.9.12 Topology discovery ................................................................................................. 184
x Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1 11A.9.12.1 Advertised neighbor set ....................................................................... 184

2 11A.9.12.2 Conditions for generating a TC element.............................................. 184
3
11A.9.12.3 Conditions for forwarding a TC element ............................................. 185
4
5 11A.9.12.4 TC processing ...................................................................................... 185
6 11A.9.13 Path selection table calculation................................................................................ 186
7 11A.9.13.1 General................................................................................................. 186
8 11A.9.13.2 Path selection algorithm....................................................................... 186
9
11A.9.14 Interworking through Mesh Portal (MPP) ............................................................... 187
10
11 11A.9.15 Associated station discovery.................................................................................... 187
12 11A.9.15.1 Overview.............................................................................................. 187
13 11A.9.15.2 Local Association Base Advertisement (LABA) element ................... 187
14 11A.9.15.2.1 Function ......................................................................... 188
15
11A.9.15.2.2 Conditions for generating and sending a LABA element ...
16
17 188
18 11A.9.15.2.3 Conditions for forwarding a LABA element ................. 190
19 11A.9.15.2.4 LABA processing .......................................................... 192
21
22
23 11A.9.15.3 Local Association Base Checksum Advertisement (LABCA) ............ 193
24 11A.9.15.3.1 Function ......................................................................... 193
25 11A.9.15.3.2 Conditions for generating a LABCA element ............... 193
26 11A.9.15.3.3 Conditions for forwarding a LABCA element .............. 194
27
11A.9.15.3.4 LABCA processing........................................................ 194
28
31 11A.9.15.3.7 Checksum calculation .................................................... 195
32 11A.9.15.4 Association Base Block Request (ABBR) element ............................. 195
33
11A.9.15.4.1 Function ......................................................................... 195
34
35 11A.9.15.4.2 Conditions for generating an ABBR element ................ 195
36 11A.9.15.4.3 Conditions for forwarding an ABBR element ............... 197
37 11A.9.15.4.4 ABBR processing .......................................................... 197
39
40
41 11A.9.15.5 Associated station discovery basic mechanism ................................... 199
42 11A.9.16 Recommended values for constants......................................................................... 199
43 11A.9.16.1 Setting emission intervals and holding times ...................................... 199
44 11A.9.16.2 Emission intervals................................................................................ 199
45
11A.9.16.3 Holding time ........................................................................................ 200
46
47 11A.9.17 Sequence number ..................................................................................................... 200
48 11A.10 Null path selection protocol ..................................................................................................... 201
49 11A.11 Intra-mesh congestion control ................................................................................................. 201
50 11A.11.1 Motivation (Informative) ......................................................................................... 201
51
11A.11.2 Local congestion monitoring (Informative)............................................................. 202
52
53 11A.11.3 Congestion control signaling ................................................................................... 202
54 11A.11.4 Target rate computation (Informative) .................................................................... 203
55 11A.11.5 Local rate control mechanism (Informative) ........................................................... 204
56 11A.12 Mesh beaconing and synchronization...................................................................................... 204
57
11A.12.1 Synchronization ....................................................................................................... 204
58
59 11A.12.2 Non-synchronizing MPs .......................................................................................... 205
60 11A.12.2.1 Synchronizing MPs (Optional) ............................................................ 205
61 11A.12.2.2 Interaction between synchronizing and non-synchronizing MPs ........ 205
62 11A.12.3 Beaconing ................................................................................................................ 206
63
11A.12.3.1 Beaconing by non-synchronizing MPs ................................................ 206
64
65 11A.12.3.2 Beaconing by synchronizing MPs ....................................................... 206
Copyright © 2007 IEEE. All rights reserved. xi

IEEE P802.11s/D1.05, June 2007
1 11A.12.3.2.1 Designated Beacon Broadcaster .................................... 207

2 11A.12.3.2.2 Reporting to the Beacon Broadcaster using Connectivity
3
Reports 207
4
5 11A.12.3.2.3 Change of Beacon broadcaster ...................................... 208
6 11A.12.4 Mesh Beacon Collision Avoidance (MBCA) mechanism ....................................... 209
7 11A.12.4.1 Action frames for beacon timing request and response ....................... 210
8 11A.13 Power management in a mesh (Optional)................................................................................ 210
9
11A.13.1 Overview.................................................................................................................. 210
10
11 11A.13.2 MP Power Management modes ............................................................................... 211
12 11A.13.3 Initialization of Power Management within a mesh ................................................ 212
13 11A.13.3.1 Initialization of Power Management of non-sync MP......................... 213
14 11A.13.3.2 Initialization of Power Management of sync MP ................................ 213
15
11A.13.4 Receive operation for MPs in Power Save mode .................................................... 213
16
17 11A.13.4.1 Receiving frames from non-sync MP .................................................. 214
18 11A.13.4.2 Receiving frames from sync MP ......................................................... 214
19 11A.13.4.3 Receive operation using APSD............................................................ 214
20 11A.13.5 Transmit operation for MPs transmitting to MPs in Power Save mode ................ 215
21
11A.13.5.1 Operation of power save supporting non-sync MP ............................. 215
22
23 11A.13.5.2 Operation of power save supporting sync MP..................................... 215
24 11A.13.5.3 Operation of APSD supporting MP ..................................................... 216
25 11A.13.6 Power management with APSD .............................................................................. 216
26 11A.13.6.1 Aperiodic APSD .................................................................................. 216
27
11A.13.6.2 Periodic APSD..................................................................................... 217
28
29
30 Annex A (normative) Protocol Implementation Conformance Statement (PICS) proforma ...................... 219
31
32 A.4 PICS proforma - IEEE Std 802.11, 2006 Edition .................................................................... 219
33
A.4.4 MAC protocol ......................................................................................................... 219
34
35 A.4.4.1 MAC protocol capabilities................................................................... 219
36
37 Annex D (normative) ASN.1 encoding of the MAC and PHY MIB........................................................... 220
38
39
Annex T Mesh Annex (Informative) ........................................................................................................... 223
40
41
42 T.1 Overview of Single-Channel and Multi-Channel Operation in a Mesh .................................. 223
43 T.1.1 Unified channel graphs ............................................................................................ 223
44 T.1.2 Single and multiple PHY devices ............................................................................ 225
45
T.2 Recommended HWMP default values..................................................................................... 225
46
47 T.3 Radio Aware OLSR flowcharts ............................................................................................... 226
48 T.4 Interworking support example and flowcharts ........................................................................ 234
49 T.4.1 General interworking example topologies ............................................................... 234
50 T.4.2 Operational considerations for interworking ........................................................... 234
51
T.4.2.1 Formation and maintenance of the IEEE 802.1D spanning tree.......... 234
52
53 T.4.2.2 MP mobility ......................................................................................... 234
54 T.5 MP boot sequence example ..................................................................................................... 235
55 T.6 MP Table Examples................................................................................................................. 236
56 T.6.1 MP neighbor table.................................................................................................... 236
57
T.6.2 MP proxy table......................................................................................................... 237
58
59 T.7 Power Save parameters selection............................................................................................. 239
60 T.8 Informative references ............................................................................................................. 239
61
62
63
64
65
xii Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1
2 List of Figures
3 Figure s1—Non-mesh IEEE 802.11 deployment model and device classes. .................................................. 4
4 Figure s2—Example mesh containing MPs, Mesh APs, and Mesh Portal...................................................... 5
5 Figure s3—MAC data transport over a Mesh.................................................................................................. 5
6
7 Figure 7.1—MAC frame format ...................................................................................................................... 7
8 Figure s4—Mesh Header field......................................................................................................................... 9
9 Figure s5—Mesh Flags field............................................................................................................................ 9
10 Figure s6—Mesh Address Extension field .................................................................................................... 10
11 Figure s7—Mesh data frame.......................................................................................................................... 14
12
13 Figure s8—Mesh management frame ........................................................................................................... 15
14 Figure s9—Mesh Action field ....................................................................................................................... 18
15 Figure s11—Mesh Key Transport Control field............................................................................................ 19
16 Figure s12—Mesh Wrapped Key field .......................................................................................................... 19
17 Figure s10—Message integrity check field ................................................................................................... 19
18
19 Figure s13—Mesh Configuration element .................................................................................................... 22
20 Figure s15—Active path selection metric identifier field ............................................................................. 23
21 Figure s14—Active path selection protocol identifier field .......................................................................... 23
22 Figure s16—Mesh Capability field................................................................................................................ 24
23 Figure s17—Mesh ID element format ........................................................................................................... 24
24
25 Figure s18—Link Metric Report element...................................................................................................... 25
26 Figure s19—Mesh ATIM window parameter element.................................................................................. 25
27 Figure s20—Target Transmission Rate element format................................................................................ 26
28 Figure s21—Offered Traffic Load element format ....................................................................................... 26
29 Figure s23—Peer Link Management element ............................................................................................... 27
30
31 Figure s22—Neighborhood Congestion element format............................................................................... 27
32 Figure s24—Mesh Channel Switch Announcement element ........................................................................ 28
33 Figure s26—MP Control field ....................................................................................................................... 29
34 Figure s25—Mesh Neighbor List element..................................................................................................... 29
35 Figure s27—Mesh TIM element.................................................................................................................... 30
36
37 Figure s28—Beacon Timing element ............................................................................................................ 31
38 Figure s29—Self Beacon timing.................................................................................................................... 31
39 Figure s30—Synchronized Beacon Timing field .......................................................................................... 32
40 Figure s31—Non-synchronized Beacon Timing field................................................................................... 32
41 Figure s32—MDAOP Setup Request element .............................................................................................. 33
42
43 Figure s33—Values for Periodic MDAOP Info field for an example MDAOP set ...................................... 34
44 Figure s34—MDAOP Setup Reply element.................................................................................................. 34
45 Figure s35—MDAOP Advertisements Request element .............................................................................. 34
46 Figure s36—MDAOP Advertisements element ............................................................................................ 34
47 Figure s37—The format of the TX-RX times report and Interfering times report fields .............................. 35
48
49 Figure s38—MDAOP Teardown element ..................................................................................................... 35
50 Figure s39—Connectivity Report ................................................................................................................. 36
51 Figure s40—Connectivity Report Control field ............................................................................................ 36
52 Figure s41—PANN element ......................................................................................................................... 37
53 Figure s42—RANN element ........................................................................................................................ 38
54
55 Figure s44—PREQ Per-Destination Flags field format ................................................................................ 39
56 Figure s43—PREQ element........................................................................................................................... 39
57 Figure s45—Path Reply element ................................................................................................................... 40
58 Figure s46—Path Error element .................................................................................................................... 41
59 Figure s47—Proxy Update (PU) Element ..................................................................................................... 42
60
61 Figure s48—Proxy Update Confirmation (PUC) element............................................................................. 42
62 Figure s49—RA-OLSR common information element format ..................................................................... 43
63 Figure s51—Fields specific to TC element ................................................................................................... 44
64 Figure s50—Fields specific to HELLO element ........................................................................................... 44
65
Copyright © 2007 IEEE. All rights reserved. xiii

IEEE P802.11s/D1.05, June 2007
1 Figure s52—Fields specific to MID element................................................................................................. 45

2 Figure s53—Fields specific to RA-OLSR LABA element ........................................................................... 45
3
Figure s54—Fields specific to LABCA element ........................................................................................... 46
4
5 Figure s55—Fields specific to RABBR element ........................................................................................... 46
6 Figure s57—Mesh Security Configuration field ........................................................................................... 47
7 Figure s56—Mesh security capability information element.......................................................................... 47
8 Figure s58—MSA information element [MSAIE] ........................................................................................ 48
9
Figure s59—Handshake Control field ........................................................................................................... 48
10
11 Figure s60—Optional parameters field.......................................................................................................... 48
12 Figure s61—Transport type selector format .................................................................................................. 49
13 Figure s62—Key holder security field........................................................................................................... 63
14 Figure s63—EAP Authentication field.......................................................................................................... 66
15
Figure s64—Mesh key hierarchy................................................................................................................... 72
16
17 Figure s65—Key distribution between mesh key holders ............................................................................. 72
18 Figure s66—Extensible Path Selection Framework system architecture ...................................................... 89
19 Figure s67—Inter-layer management entities and their relationship and service access points (SAPs) used for
20 internal communication. ................................................................................................................................ 90
21
Figure s68—Finite State Machine of Peer Link Management Protocol...................................................... 104
22
23 Figure s69—MSA Authentication Mechanism, including initial MSA Authentication ............................. 113
24 Figure s70—Mesh key holder security handshake ...................................................................................... 114
25 Figure s71—Mesh key transport delivery pull protocol .............................................................................. 115
26 Figure s72—Mesh key transport delivery push protocol............................................................................. 115
27
Figure s73—Mesh key delete protocol ........................................................................................................ 116
28
29 Figure s74—EAP message transport protocol (single exchange) ............................................................... 116
30 Figure s75—Valid address field usage for Mesh Data and Mesh Management frames.............................. 136
31 Figure s76—Example Addressing for a Mesh Data frame transmitted and forwarded on a mesh path from an
32 MAP to an MPP. ......................................................................................................................................... 136
33
Figure s77—Illustration of definitions ........................................................................................................ 148
34
35 Figure s78—Example channel configurations in a mesh. ........................................................................... 224
36 Figure s79—Example unified channel graphs in a mesh. ........................................................................... 224
37 Figure s80—Flowchart for processing an RA-OLSR path selection message. ........................................... 226
38 Figure s81—Flowchart for processing a HELLO message. ........................................................................ 227
39
Figure s82—Flowcharts for processing an MID message........................................................................... 228
40
41 Figure s83—Flowcharts for processing a TC message. .............................................................................. 228
42 Figure s84—Flowchart for processing LABA message. ............................................................................. 229
43 Figure s85—Flowcharts for processing an LABCA message. .................................................................... 230
44 Figure s86—Flowcharts for processing an ABBR message........................................................................ 230
45
Figure s87—Flowchart for processing an optional STU message. ............................................................. 231
46
47 Figure s88—Flowchart for selection of MPRs. ........................................................................................... 232
48 Figure s89—Flowchart for selection of optimal paths. ............................................................................... 233
49 Figure s90—Connecting a Mesh with other LANs via mesh portals. (a) Layer 2 bridging. (b) Layer 3 inter-
50 networking. .................................................................................................................................................. 234
51
Figure s91—MP Boot Sequence.................................................................................................................. 236
52
53 Figure s92—Example of optional proxy registration procedure to MPP. ................................................... 238
54
55
56
57
58
59
60
61
62
63
64
65
xiv Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1
2 List of Tables
3 Table s1—Organization of mesh subclauses ................................................................................................... 6
4 Table 7.1—Valid type and subtype combinations........................................................................................... 8
5 Table 7.2—To/From DS combinations in data frames.................................................................................... 8
6
7 Table 7.8—Beacon frame body ..................................................................................................................... 12
8 Table 7.14—Probe Request frame body........................................................................................................ 13
9 Table 7.15—Probe Response frame body ..................................................................................................... 14
10 Table 7.22—Reason codes ............................................................................................................................ 16
11 Table 7.23—Status codes .............................................................................................................................. 17
12
13 Table 7.24—Category values ........................................................................................................................ 17
14 Table s2—Mesh Action Category values ...................................................................................................... 18
15 Table 7.26—Element IDs .............................................................................................................................. 20
16 Table 7.34—AKM Suite Selectors ................................................................................................................ 22
17 Table s4—Path selection metric identifier values ......................................................................................... 23
18
19 Table s3—Path selection protocol identifier values ...................................................................................... 23
20 Table s5—Meaning of Mesh Security Configuration bits............................................................................. 47
21 Table s7—Transport types............................................................................................................................. 49
22 Table s6—Sub-element IDs........................................................................................................................... 49
23 Table s8—Mesh Peer Link Management Action field values ....................................................................... 50
24
25 Table s9—Peer Link Open frame body ......................................................................................................... 50
26 Table s10—Peer Link Confirm frame body .................................................................................................. 51
27 Table s11—Peer Link Close frame body....................................................................................................... 52
28 Table s13—Link Metric Request frame body ............................................................................................... 53
29 Table s14—Link Metric Report frame body ................................................................................................. 53
30
31 Table s12—Mesh Link Metric Action field values ....................................................................................... 53
32 Table s15—Mesh Path Selection Action field values ................................................................................... 54
33 Table s16—Path Request frame body ........................................................................................................... 54
34 Table s18—Path Error frame body ................................................................................................................ 55
35 Table s19—Root Announcement frame body ............................................................................................... 55
36
37 Table s17—Path Reply frame body............................................................................................................... 55
38 Table s20—RA-OLSR frame body ............................................................................................................... 56
39 Table s21—Mesh Interworking Action field values...................................................................................... 56
40 Table s22—Portal Announcement frame body ............................................................................................. 57
41 Table s23—Mesh Resource Coordination Action field values ..................................................................... 57
42
43 Table s24—Congestion Control Request frame body ................................................................................... 58
44 Table s25—Congestion Control Response frame body................................................................................. 58
45 Table s27—Mesh Deterministic Access frame body .................................................................................... 59
46 Table s28—Beacon Timing Request frame body.......................................................................................... 59
47 Table s26—Neighborhood Congestion Announcement frame body............................................................. 59
48
49 Table s29—Beacon Timing Response frame body ....................................................................................... 60
50 Table s30—Mesh Channel Switch Announcement frame body.................................................................... 60
51 Table s31—Connectivity Report frame body ................................................................................................ 61
52 Table s33—Mesh key holder security establishment frame body format ..................................................... 62
53 Table s32—MSA Action field values............................................................................................................ 62
54
55 Table s34—PMK-MA delivery push frame body format.............................................................................. 63
56 Table s35—PMK-MA confirm frame body format....................................................................................... 64
57 Table s36—PMK-MA request frame body format........................................................................................ 64
58 Table s37—PMK-MA delivery pull frame body format ............................................................................... 65
59 Table s38—PMK-MA delete frame body format.......................................................................................... 65
60
61 Table s39—Mesh EAP encapsulation frame body ........................................................................................ 66
62 Table s40—Encapsulation Type values......................................................................................................... 67
63 Table s41—Peer Link Management Finite State Machine .......................................................................... 103
64 Table s42—Key selection procedure ........................................................................................................... 120
65
Copyright © 2007 IEEE. All rights reserved. xv

IEEE P802.11s/D1.05, June 2007
1 Table s43—Content of a PANN element in Case A.................................................................................... 140

2 Table s44—Content of a PANN element in Case B .................................................................................... 141
3
Table s45—Content of a PU element .......................................................................................................... 143
4
5 Table s46—Content of a PUC element........................................................................................................ 144
6 Table s47—Airtime cost constants .............................................................................................................. 145
7 Table s48—Parameters of the Airtime Link Metric for Extensible Path Selection Framework ................. 145
8 Table s49—Parameters of HWMP for Extensible Path Selection Framework ........................................... 148
9
Table s50—Precursor and Next Hop Examples .......................................................................................... 149
10
11 Table s51—Content of a PREQ element in Case A .................................................................................... 153
12 Table s52—Content of a PREQ element in Case B..................................................................................... 154
13 Table s53—Content of a PREQ element in Case C..................................................................................... 155
14 Table s54—Content of a PREQ element in Case D1 .................................................................................. 156
15
Table s56—Contents of a PREQ element in Case D3................................................................................. 157
16
17 Table s55—Contents of a PREQ element in Case D2................................................................................. 157
18 Table s57—Contents of a PREQ in Case E ................................................................................................. 158
19 Table s58—Contents of a PREP element in Case A ................................................................................... 161
20 Table s60—Contents of a PREP element in Case C.................................................................................... 162
21
Table s59—Contents of a PREP element in Case B.................................................................................... 162
22
23 Table s61—Contents of a PREP element in Case D ................................................................................... 163
24 Table s62—Contents of a PERR element in Case A ................................................................................... 165
25 Table s63—Contents of a PERR element in Case B ................................................................................... 166
26 Table s64—Contents of a RANN element in Case A.................................................................................. 167
27
Table s65—Contents of a RANN element in Case B .................................................................................. 168
28
29 Table s66—Terminology for RA-OLSR ..................................................................................................... 170
30 Table s67—Parameters of RA-OLSR for Extensible Path Selection Framework....................................... 171
31 Table s68—Content of a LABA element in Case A1.................................................................................. 189
32 Table s69—Content of a LABA element in Case A2.................................................................................. 189
33
Table s70—Content of a LABA element in Case B1 .................................................................................. 190
34
35 Table s71—Content of a LABA element in Case B2 .................................................................................. 191
38 Table s74—Content of a LABA element in Case C2 .................................................................................. 193
39
Table s75—Content of a LABCA element in Case A ................................................................................. 194
40
41 Table s77—Content of a ABBR element in Case B1 .................................................................................. 196
42 Table s76—Content of a ABBR element in Case A.................................................................................... 196
45
Table s80—Content of an ABBR element for forwarding .......................................................................... 198
46
47 Table s81—MP neighbor table entry........................................................................................................... 237
48 Table s82—State values............................................................................................................................... 237
49 Table s83—A logical proxy table maintained at each MP (the information can be derived from other sources).
50 238
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
xvi Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1
2 IEEE P802.11s™/D1.05
3
4
5
6 Draft STANDARD for
7
8
9
Information Technology-
10
11
Telecommunications and information exchange
12
13 between systems-
14
15 Local and metropolitan area networks-
16
17 Specific requirements-
18
19
20
21
22
Part 11: Wireless LAN Medium Access Control
23
24 (MAC) and Physical Layer (PHY) specifications
25
26
27
28 Amendment <number>: Mesh Networking
29
30
31 EDITORIAL NOTE—the amendment number will be inserted by IEEE-SA editorial staff in the
32 publication preparation phase.
33
34 The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert,
35
and replace. Change is used to make corrections in existing text or tables. The editing instruction specifies
36
37 the location of the change and describes what is being changed by using strikethrough (to remove old mate-
38 rial) and underscore (to add new material). Delete removes existing material. Insert adds new material with-
39 out disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are
40 given in the editing instruction. Replace is used to make changes in figures or equations by removing the
41
existing figure or equation and replacing it with a new one. Editing instructions, change markings, and this
42
43 NOTE will not be carried over into future editions because the changes will be incorporated into the base
44 standard.
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Copyright © 2007 IEEE. All rights reserved. 1

IEEE P802.11s/D1.05, June 2007
1 3. Definitions
2
3
4 Insert the following new definitions alphabetically:
5
6 3.s1 candidate peer mesh point: a neighbor mesh point (MP) to which a mesh link has not been established
7
8 but meets eligibility requirements to become a peer MP.
9
10 3.s2 channel precedence: a criterion used to enable peer mesh points to coalesce to a common wireless
11 medium communication channel.
12
13
14 3.s3 mesh: A network consisting of two or more mesh points communicating via mesh services.
15
16
17 3.s4 mesh access point (MAP): A mesh point that is collocated with one or more access point(s).
18
19 3.s5 mesh deterministic access opportunity (MDAOP): MDAOP is a period of time within every mesh
20 DTIM interval that is set up between a transmitter and a receiver.
21
22
23 3.s6 mesh delivery traffic indication message (DTIM) interval: The value indicated by the mesh DTIM
24 period subfield in the mesh TIM element in Beacon frames or Probe Response frames.
25
26
27 3.s7 mesh link: A link from one MP to another MP that has been established with the peer link management
28 protocol.
29
30
31 3.s8 link metric: A criterion used to characterize the performance/quality/eligibility of a mesh link for use
32 in a mesh path.
33
34 3.s9 mesh neighborhood: The set of all neighbor MPs relative to a particular MP.
35
36
37 3.s10 mesh path: A concatenated set of mesh links from a source mesh point to a destination mesh point.
38
39
40
3.s11 mesh path selection: The process of selecting a mesh path.
41
42 3.s12 mesh point (MP): An IEEE 802.11 entity that contains an IEEE 802.11-conformant medium access
43 control (MAC) and physical layer (PHY) interface to the wireless medium (WM) that supports mesh ser-
44
45
vices.
46
47 3.s13 mesh portal: A mesh point that is collocated with one or more portal(s).
48
49
50 3.s14 mesh services: The set of services defined in this standard that together with other 802.11 MAC ser-
51 vices provide for the creation and operation of mesh networks using 802.11 PHY services (see 7.3.2.54).
52
53
54
3.s15 neighbor mesh point: An MP that is in direct communication range of another MP. Not all neighbor
55 MPs are peer MPs.
56
57 3.s16 path metric: An aggregate multi-hop criterion used to characterize the performance/quality/eligibility
58
of a mesh path.
59
60
61 3.s17 peer mesh point: MP to which a mesh link has been established.
62
63
64 3.s18 unified channel graph (UCG): A set of mesh point PHYs that are connected to each other via a com-
65 mon wireless medium communication channel.
2 Copyright © 2007 IEEE. All rights reserved.

IEEE P802.11s/D1.05, June 2007
1 4. Abbreviations and acronyms

2
3
4 Insert the following new acronym in alphabetical order:
5
6
7 AODV Ad hoc On-demand Distance Vector
8 BB Beacon Broadcaster
9
10 DSN Destination sequence number
11
12 EAPAIE EAP Authentication information element
13 EAPMIE EAP Message information element
14
15 MSA Mesh Security Association
16
17 MSAIE MSA Handshake information element
18 HWMP Hybrid Wireless Mesh Protocol
19
20 MA Mesh Authenticator
21
22 MA-ID Mesh Authenticator Identifier
23
24
MAP Mesh Access Point
25 MDA Mesh Deterministic Access
26
27 MDAOP Mesh Deterministic Access Opportunity
28
29 MEKIE Mesh encrypted key information element
30 MKCK-KD Mesh key confirmation key for key distribution
31
32 MKD Mesh Key Distributor
33
34 MKD-ID Mesh Key Distributor Identifier
35 MKDK Mesh key Distribution Key
36
37 MKEK-KD Mesh key encryption key for key distribution
38
39 MKHSIE Mesh key holder security information element
40 MKDD-ID MKD domain Identifier
41
42 MPTK-KD Mesh pairwise transient key for key distribution
43
44 MSCIE Mesh security capability information element
45 MP Mesh Point
46
47 MPP Mesh Point collocated with a mesh Portal
48
49 OLSR Optimized Link State Routing
50
PMK-MA Mesh Authenticator PMK
51
52 PMK-MKD Mesh Key Distributor PMK
53
54 RA-OLSR Radio Aware Optimized Link State Routing
55
56
PERR Path Error
57 PREP Path Reply
58
59 PREQ Path Request
60
61 TTL Time to Live
62 UCG Unified Channel Graph
63
64
65

IEEE P802.11s/D1.05, June 2007
1 5. General description
2
3
4 5.2 Components of the IEEE 802.11 architecture
5
6
7 EDITORIAL NOTE—5.2.9 is the first unused subclause -- TGk used 5.2.7 and TGn used 5.2.8
8
9 Insert the following new clause after 5.2.8, renumbering figures as appropriate.
10
11
12 5.2.9 Wireless LAN mesh
13
14 5.2.9.1 Introduction to mesh
15
16 In wireless local area network (WLAN) deployments without mesh services, end stations (STAs) must asso-
17
18 ciate with an AP in order to gain access to the network. These STAs are dependent on the AP with which
19 they are associated to communicate. An example of the non-mesh WLAN deployment model and device
20 classes are illustrated in Figure s1.
21
22 External network
23
24
25
26
27 Access Point
28
29 AP
30 AP
31
32 AP
33
34 STA
35 Station
36 STA
37 STA STA
38 STA
39
40
41 Figure s1—Non-mesh IEEE 802.11 deployment model and device classes.
42
43
44 Many WLAN implementations can benefit from support for more flexible interoperable wireless connectiv-
45 ity. Functionally, the DS of an AP can be replaced with interoperable wireless links or multi-hop paths
46 between multiple APs. End-user devices can benefit from the ability to establish interoperable peer-to-peer
47 wireless links with neighboring end-user devices and APs in a mesh network.
48
49
50 An example Mesh is illustrated in Figure s2. Mesh points (MPs) are entities that support mesh services, i.e.
51 they participate in interoperable formation and operation of the mesh network. An MP may be collocated
52 with one or more other entities (e.g., AP, portal, etc.). The implementation of collocated entities is beyond
53 the scope of this standard. The configuration of an MP that is collocated with an Access Point is referred to
54 as a Mesh Access Point (MAP). Such a configuration allows a single entity to logically provide both mesh
55
56 functionalities and AP functionalities simultaneously. STAs associate with APs to gain access to the net-
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 work. Only MPs participate in mesh functionalities such as path selection and forwarding, etc. Mesh portals
2 (MPPs) interface the network to other IEEE 802 LAN segments. Figure s2 illustrates this.
3
4 External network
5
6
7
8
9
10 Mesh Portal
11
12 Portal Mesh Point
13
MP
14 MP
15
16
17 Mesh Links
18 MP Mesh AP
19
20 AP MP
21
22 AP
23
24
25 STA
STA STA
26
27 Non-mesh Stations STA
28
29
30 Figure s2—Example mesh containing MPs, Mesh APs, and Mesh Portal.
31
32
33 5.2.9.2 Mesh network model
34
35 A Mesh network is an IEEE 802 LAN comprised of IEEE 802.11 links and control elements to forward
36
37 frames among the network members. Effectively, this means that a Mesh network appears functionally
38 equivalent to a broadcast Ethernet from the perspective of other networks and higher layer protocols. Thus,
39 it normally appears as if all MPs in a Mesh are directly connected at the link layer. This functionality is
40 transparent to higher layer protocols (see in Figure s3).
41
42 MSDU source may be
43 endpoint application,
44 higher-layer protocol MSDU MSDU
45 (802.1D, IP, etc.), e.g. at Source MSDU Destination
46 Mesh Portal, etc. MAC SAP
47
48 MPDU
49
50
51
52 MP MP
53 MP
54
55
56
57
58
59 MP
60 MP
61
62
63
64
65 Figure s3—MAC data transport over a Mesh

IEEE P802.11s/D1.05, June 2007
1 5.2.9.3 Organization of mesh subclauses

2
3
Mesh functionalities are described in the subclauses shown in Table s1:
4
5
6
7 Table s1—Organization of mesh subclauses
8
9
10 Functional Area Clause
11
12 Frame Formats 7
13
Mesh Security 8.8, 11A.4
14
15 Mesh Deterministic Access (MDA) 9.21
16
17 Mesh Discovery and Peer Link Management 11A.1
18
19 Mesh Peer Link Management 11A.2
20
21 Mesh Channel Selection 11A.3
22
23 Mesh Path Selection, Forwarding, and Interworking 11A.5, 11A.6, 11A.7, 11A.8, 11A.9,
24 11A.10
25
26 Intra-Mesh Congestion Control 11A.11
27
28 Mesh Beaconing and Synchronization 11A.12
29
30 Power Management in a Mesh 11A.13
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7. Frame formats
2
3
4 7.1 MAC frame formats
5
6
7 7.1.2 General frame format
8
9 Change the text in 7.1.2 and Figure 7.1 as shown:
10
11
12 The MAC frame format comprises a set of fields that occur in a fixed order in all frames. Figure 7.1 depicts
13 the general MAC frame format. The first three fields (Frame Control, Duration/ID, and Address 1) and the
14 last field (FCS) in Figure 7.1 constitute the minimal frame format and are present in all frames (except
15 NDP), including reserved types and subtypes. The fields Address 2, Address 3, Sequence Control, Address
16 4, QoS Control, HT Control, Mesh Header, and Frame Body are present only in certain frame types and sub-
17
18 types. When present, the Mesh Header field is prepended to the Frame Body. The Mesh Header field is han-
19 dled identically to the contents of the body with respect to MPDU processing. Each field is defined in 7.1.3.
20 The format of each of the individual subtypes of each frame type is defined in 7.2. The components of man-
21 agement frame bodies are defined in 7.3. The formats of management frames of subtype Action are defined
22 in 7.4. The format of mesh management frames of subtype Mesh Action is defined in 7.4b.
23
24
25 Octets:
26 2 6 6 6 2 6 2 4 0-7955 4
2
27
28 Frame Dura Addr Addr Addr Sequen Addr QoS HT Body FCS
29 Control tion/ 1 2 3 ce Con- 4 Control Control
30 ID trol Mesh
31 Header
32
33
34 MAC Header
35
36 Figure 7.1—MAC frame format
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.1.3 Frame fields

2
3
4 7.1.3.1 Frame control field
5
6 7.1.3.1.2 Type and subtype fields
7
8
9 Change the contents of Table 7.1 as shown:
10
11
12 Table 7.1—Valid type and subtype combinations
13
14
15 Type value Subtype value
Type description Subtype description
16 b3 b2 b7 b6 b5 b4
17
18 <ANA 1> 11 Extended <ANA 2> 0000 Mesh Data
19
20 <ANA 1> 11 Extended <ANA 3> 0001 Mesh Management
21
<ANA 1> 11 ReservedExtended <ANA 4> 00000010-1111 Reserved
22
23
24
25
EDITORIAL NOTE—These type and subtype values need to be allocated before sponsor ballot by ANA.
26
27
28 7.1.3.1.3 To DS and From DS fields
29
30
31 Change the contents of Table 7.2 as shown:
32
33
34 Table 7.2—To/From DS combinations in data frames
35
36
37 To DS and From DS values Meaning
38
39 To DS = 1 A data frame using the four-address format. This
40 From DS = 1 standard does not define procedures for using this
41 combination of field values.
42
43
44
45 7.1.3.1.6 Power Management field
46
47
48
Change the contents of 7.1.3.1.6 as shown:
49
50 The Power Management field is 1 bit in length and is used to indicate the power management mode of a
51 STA. The value of this field remains constant in each frame from a particular STA within a frame exchange
52 sequence defined in 9.12. In the case of STA in a BSS, tThe value indicates the mode in which the station
53
54 will be after the successful completion of the frame exchange sequence. In the case of MP in a Mesh, the
55 value indicates the mode in which the MP will be after the successful completion of the frame exchange
56 sequence with all of its peer MPs.
57
58
59
A value of 1 indicates that the STA or MP will be in PS mode. A value of 0 indicates that the STA or MP
60 will be in active mode. This field is always set to 0 in frames transmitted by an AP.
61
62 7.1.3.1.8 More Data field
63
64
65 Insert the following text to the end of 7.1.3.1.8

IEEE P802.11s/D1.05, June 2007
1 Special considerations exist within a mesh. The ‘more data’ bit is set to 1 by MPs for individually addressed
2 MSDU/MMPDUs sent to a neighboring MP when there are more frames to be transmitted to that MP in the
3
transmitter’s current beacon interval. The ‘more data’ bit is set to 1 by MPs for group addressed MSDUs/
4
5 MMPDUs when there are more group addressed frames to be transmitted in the transmitter’s current beacon
6 interval.
7
8 Insert the following new clause after 7.1.3.5:
9
10
11 7.1.3.5a Mesh Header field
12
13 7.1.3.5a.1 General
14
15
16 The mesh header field is a 4 or 16 octet field that includes:
17 — an 8-bit Mesh Flags field to control mesh header processing
18
19 — a time to live field for use in multi-hop forwarding to aid in limiting the effect of transitory path
20 selection loops
21
22 — a mesh sequence number to suppress duplicates in flooding algorithms and for other services
23 — and optionally a 12-octet mesh address extension field containing two addresses resulting in a total
24
25 of 6 addresses in mesh data frames
26
27 The Mesh Header field, shown in Figure s4, is present in all frames of type Extended with subtypes Mesh
28 Data and Mesh Management.
29
30
31 Octets: 1 1 2 12
32
33 Mesh Flags Mesh Time To Live Mesh Sequence Mesh
34 (TTL) Number Address Extension
35 (present in some con-
36 figurations)
37
38
39 Figure s4—Mesh Header field
40
41
42 7.1.3.5a.2 Mesh Flags field
43
44
45 The Mesh Flags field, shown in Figure s5, is 8 bits in length and the flags therein are used to control mesh-
46 specific header processing, e.g., for mesh address extension.
47
48
49
50
51 B0 B1 B7
52
53 Address Extension (AE) Reserved
54
55 Bits: 1 7
56
57
58 Figure s5—Mesh Flags field
59
60
61 The “Address Extension (AE)” flag is used to indicate the existence of — and thereby the use of — the mesh
62
address extension field for mesh address extension based on 6-address format: If AE = 1, the mesh address
63
64 extension field follows the Mesh Sequence Number field and provides two additional address fields for
65 mesh address extension (see 11A.5.5 for the usage of address fields in 6-address format); if AE is 0, the

IEEE P802.11s/D1.05, June 2007
1 mesh address extension field is not present. The “AE” flag can be set to 1 only when both “To DS” and
2 “From DS” fields are set to 1.
3
4
5 The reserved field is set to zero.
6
7 7.1.3.5a.3 Mesh Time to Live field
8
9
10
The Mesh Time to Live (TTL) field is 8 bits in length and is used to mitigate the possibility of transient
11 loops in a mesh network by ensuring frames that are caught in a loop are eventually discarded.
12
13 7.1.3.5a.4 Mesh Sequence Number field
14
15
16 The Mesh Sequence Number field is 16 bits in length and used to detect duplicate reception of messages in a
17 Mesh network.
18
19 In an individually addressed data frame, the Mesh Sequence Number field uniquely identifies the frame
20 from a given Source MP. This field is set by the Source MP, kept unchanged at the intermediate Relay MPs,
21
22 and used by the Destination MP to eliminate duplicate frames.
23
24 7.1.3.5a.5 Mesh Address Extension field
25
26 The Mesh Address Extension field, shown in Figure s6, is 12 octets in length and follows the Mesh
27
28 Sequence Number field only when the “AE” flag of Mesh Flags field is set to 1. Mesh Address Extension
29 field provides two additional address fields, Address 5 and Address 6, for mesh address extension based on
30 6-address format.
31
32
33 Octets: 6 6
34
35 Address 5 Address 6
36
37 Figure s6—Mesh Address Extension field
38
39
40
41 Address 5 and Address 6 may be used to transport the addresses of source and destination end points in cases
42 where either (or both) of the end points are not MPs at the beginning or end of a single mesh path. This is
43 useful, for example, in the following cases:
44
45 — When the end points of IEEE 802 communication are non-mesh, proxied entities which communi-
46 cate over a mesh via proxy MPs.
47 — When the end points are MPs communicating with each other via a root MP in HWMP proactive tree
48
building mode, where two distinct mesh paths are used (the first path being from the source MP to
49
50 the root MP and the second path being from the root MP to the destination MP).
51
52 Details on the usage of these optional address fields are given in 11A.5.5 as part of the description of frame
53 addressing and forwarding in a mesh network.
54
55
56 7.2 Format of individual frame types
57
58
59 7.2.1.4 PS-Poll frame format
60
61 Change the second paragraph in 7.2.1.4 as shown:
62
63
64 When the frame is transmitted by a STA in a BSS, tThe BSSID is the address of the STA contained in the
65 AP. When the frame is transmitted by an MP in a mesh, the BSSID field is simply interpreted as RA. The

IEEE P802.11s/D1.05, June 2007
1 TA field is the address of the STA transmitting the frame. When the frame is transmitted by a STA in a BSS,
2 tThe AID is the value assigned to the STA transmitting the frame by the AP in the association response
3
frame that established that STA’s current association. When the frame is transmitted by an MP in a mesh,
4
5 the AID is the value assigned to the power saving MP (MP which operates in power save mode) transmitting
6 the frame by the power save supporting MP (MP which supports power save service) in the peer link con-
7 firm frame that established that MP’s current peer link.
8
9
7.2.3 Management frames
10
11
12 Insert the following text at the end of the bulleted list in the fourth paragraph of 7.2.3:
13
d) For management frames transmitted between MPs, the BSSID field is not used and should be set to
14
15 0.
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.2.3.1 Beacon frame format

2
3
4 Change the contents of the of Table 7.8-Beacon frame body as follows:
5
6
7 Table 7.8—Beacon frame body
8
9
10 Order Information Notes
11
12 4 Service Set When dot11MeshEnabled is true and the interface on which the beacon is
13 being sent is not configured as an Access Point, the SSID information
Identifier (SSID) element is set to the wildcard value.
14
15
16
17
18 Insert the following additional rows (preserving their order) in Table 7.8-Beacon frame body just before
19 the Vendor Specific information element and insert contiguous numbering in the “Order” column:
20
21
22
24
25 Mesh ID The Mesh ID information element may be present within Beacon frames
26 when dot11MeshEnabled is true.
27
28 Mesh The Mesh Configuration information element may be present within
29 Configuration Beacon frames when dot11MeshEnabled is true.
30
31 Mesh Neighbor The Mesh Neighbor List information element may be present within
32 List frames with the DTIM bit set when dot11MeshEnabled is true and the
33 MP transmits to other MPs in power save mode.
34
Mesh TIM The Mesh TIM element may be present in Beacon frames generated by
35 the MP when dot11MeshEnabled is true and MP is supporting
36 Transmission to MP in power save mode.
37
38 Mesh ATIM The Mesh ATIM window parameter element may be present only when
39 Window dot11MeshEnabled is true and the MP intends to operate in power save
40 mode.
41
42 Beacon Timing The Beacon Timing information element may be present within Beacon
43 frames when dot11MeshEnabled is true.
44 MDAOP The MDAOP Advertisements information element may be present within
45 Beacon frames when dot11MeshEnabled is true.
46 Advertisements
47
48 MSCIE The MSCIE element may be present when dot11MeshEnabled is true.
49
50
51
52 Change the title of 7.2.3.2 as shown:
53
54
7.2.3.3 IBSS ATIM frame format
55
56
57 7.2.3.4 Probe Request frame format
58
59
60 Insert the following additional rows (preserving their order) in before the last row of Table 7.14-Probe
61 Request frame body just before the Vendor Specific information element and insert contiguous
62 numbering in the “Order” column:
63
64
65 7.2.3.5 Probe Response frame format

IEEE P802.11s/D1.05, June 2007
1 Table 7.14—Probe Request frame body

2
3
5
6 Mesh ID The Mesh ID information element may be present within Probe Request frames
7 when dot11MeshEnabled is true.
8
9 Mesh Configuration The Mesh Configuration information element may be present within Probe
10 Request frames when dot11MeshEnabled is true.
11
12 Mesh Neighbor List The Mesh Neighbor List information element may be present within frames with
the DTIM bit set when dot11MeshEnabled is true and the MP transmits to other
13 MPs in power save mode.
14
15 Mesh DTIM The Mesh DTIM information element may be present in Probe Request frames
16 generated by the MP when dot11MeshEnabled is true and MP is supporting
17 Transmission to MP in power save mode.
18
19 Beacon Timing The Beacon Timing information element may be present within Probe Request
21
MDAOP The MDAOP Advertisements information element may be present within Probe
22 Request frames when dot11MeshEnabled is true.
23 Advertisements
24
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 Insert the following additional rows (preserving their order) in before the last row of Table 7.15-Probe
2 Response frame body just before the Vendor Specific information element and insert contiguous
3
numbering in the “Order” column:
4
5
6
7 Table 7.15—Probe Response frame body
8
9
11
12 Mesh ID The Mesh ID information element may be present within Probe Response
14
15 Mesh Configuration The Mesh Configuration information element may be present within Probe
16 Response frames when dot11MeshEnabled is true.
17 Mesh TIM The Mesh TIM element may be present within Probe Response frames
18 only when dot11MeshEnabled is true and MP supports Power Save mode.
19
20 Mesh ATIM Window The Mesh ATIM window parameter element may be present only when
21 dot11MeshEnabled is true and the MP intends to operate in power save
22 mode.
23
24 Beacon Timing The Beacon Timing information element may be present within Probe
25 Response frames when dot11MeshEnabled is true.
26
28
29
30
31 Insert the following new clause after 7.2.3:
32
33
34 7.2.4 Extended frames
35
36 7.2.4.1 General
37
38
39 Frames of type “11” are referred to as extended frames. The frame format for an extended frame is depen-
40 dent on the Subtype field as described in the following subclauses.
41
42
43 7.2.4.2 Mesh Data frame format
44
45
46
The frame format for a mesh data frame is based on the format of a data frame as defined in 7.2.2 with the
47 addition of the Mesh Header field described in 7.1.3.5a.
48
49 Octets: 2 2 6 6 6 2 6 2 4 or 16 0-2312 4
50
51 Frame Duration/ Address Address Address Sequence Address QoS Mesh Body FCS
52 Control ID 1 (RA) 2 (TA) 3 (DA) Control 4 (SA) Control Header
53
54
55 MAC Header
56
57 Figure s7—Mesh data frame
58
59
60
61 7.2.4.3 Mesh Management frame format
62
63
64 The frame format for a mesh management frame is defined in Figure s8. Mesh management frames are not
65 the same as management frames as defined in 7.2.3.

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 2 2 6 6 6 2 6 4 or 16 0-2312 4
3 Frame Duration/ Address Address Address Sequence Address Mesh Body FCS
4 Control ID 1 (RA) 2 (TA) 3 (DA) Control 4 (SA) Header
5
6
7 MAC Header
8
9 Figure s8—Mesh management frame
10
11
12
13 The Duration field contains a duration value as defined in 7.1.4.
14
15
16 The duration value calculation for the mesh management frame is based on the rules in 9.6 that determine
17 the data rate at which the control frames in the frame exchange sequence are transmitted. If the calculated
18 duration includes a fractional microsecond, that value is rounded up to the next higher integer.
19
20
21 The address fields for mesh management frames do not vary by frame subtype.
22
23
24 The RA field contains the MAC address of the MP that is the immediate intended receiver of the frame or
25 the group address of the MPs that are the immediate intended receivers of the frame.
26
27
28 The TA field contains the address of the MP that is transmitting the frame.
29
30
31 The SA field contains the address of the MP that initiated the Mesh management frame.
32
33
34 An MP uses the contents of the RA field to perform address matching for receiving decisions. In cases
35 where the RA field contains a group address, the TA also is validated to verify that the group addressed
36 frame originated from a peer MP. An MP uses the contents of the TA field to direct the acknowledgment if
37 an acknowledgment is necessary.
38
39
40 The Mesh Header field is defined in 7.1.3.5a.
41
42
43 Use of the Address 3 and Mesh Header fields is specified in 11A.5.5.
44
45
46 The Sequence Control field is defined in 7.1.3.4.
47
48
49 The frame body consists of Mesh Action Data Units and a security header and trailer that is present. A Mesh
50 Action Data Unit is an MMPDU sent between two mesh MAC entities. The Mesh Action Data Unit con-
51 tains the Mesh Action field, defined in 7.3.1.34. The Mesh Action field comprises Category and Action
52
53 fields followed by the information elements defined for each Mesh Action. Destination MPs that encounter
54 an element ID they do not recognize in the frame body of a received management frame ignore that element
55 and continue to parse the remainder of the management frame body (if any) for additional information ele-
56 ments with recognizable element IDs.
57
58
59 The maximum size of a Mesh Action Data Unit is 2312 octets.
60
61
62 Elements are included in ascending order.
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.3 Management frame body components

2
3
4 7.3.1 Fields that are not information elements
5
6 7.3.1.4 Capability Information field
7
8
9 Change the fourth paragraph of 7.3.1.4 “Capability Information field” as shown:
10
11 APs set the ESS subfield to 1 and the IBSS subfield to 0 within transmitted Beacon or Probe Response man-
12 agement frames. STAs within an IBSS set the ESS subfield to 0 and the IBSS subfield to 1 in transmitted
13
Beacon or Probe Response management frames. MPs set the ESS and IBSS subfields to 0 in transmitted
14
15 Beacon and Probe Response management frames.
16
17 7.3.1.7 Reason Code field
18
19
20 Insert the following rows into Table 7.22 and change the last row (Reserved) as shown.
21
22
23 Table 7.22—Reason codes
24
25
26 Reason code Meaning
27
28 <ANA 5> “MESH-LINK-CANCELLED”. IEEE 802.11 SME cancels the link instance with the reason
29 other than reaching the maximum number of neighbors
30 <ANA 6> “MESH-MAX-NEIGHBORS”. The Mesh Point has reached the supported maximum number of
31 neighbors
32
33 <ANA 7> “MESH-CAPABILITY-POLICY-VIOLATION”. The received information violates the Mesh
34 Configuration policy configured in the Mesh Point profile
35
36 <ANA 8> “MESH-CLOSE-RCVD”. The Mesh Point has received a Peer Link Close message requesting to
37 close the peer link.
38
39 <ANA 9> “MESH-MAX-RETRIES”. The Mesh Point has re-sent dot11MeshMaxRetries Peer Link Open
40 messages, without receiving a Peer Link Confirm message.
41
42 <ANA 10> “MESH-CONFIRM-TIMEOUT”. The confirmTimer for the mesh peer link instance times out.
43
44 <ANA 11> “MESH-SECURITY-ROLE-NEGOTIATION-DIFFERS”. The Mesh Point uses a different
45 method for Role Negotiation, preventing MSA authentication from completing.
46
47 <ANA 12> “MESH-SECURITY-AUTHENTICATION-IMPOSSIBLE”. No common PMK-MA exists, and
48 Initial MSA Authentication is also impossible, since no connection to the MKD exists.
49
<ANA 13> “MESH-SECURITY-FAILED-VERIFICATION”. The security-related information received in
50
the peer link management message does not match the expected values.
51
52
4655-65 535 Reserved
53
54
55
56 EDITORIAL NOTE—The Mesh reason codes need to be allocated before sponsor ballot by ANA.
57
58
59 7.3.1.8 AID field
60
61 Change the text in Clause 7.3.1.8 as shown:
62
63
64 The In case of BSS operation, the AID field is a value assigned by an AP during association that represents
65 the 16-bit ID of a STA. In mesh operation, the AID field is a value assigned by an MP during peerlink estab-

IEEE P802.11s/D1.05, June 2007
1 lishment that represents the 16-bit ID of a neighboring MP. The length of the AID field is 2 octets. The AID
2 field is illustrated in Figure 7-26.
3
4
5 7.3.1.9 Status Code field
6
8
9
10
11
Table 7.23—Status codes
12
13
Reason code Meaning
14
15 <ANA 14> “MESH-LINK-ESTABLISHED”. The mesh peer link has been successfully established
16
17 <ANA 15> “MESH-LINK-CLOSED”. The mesh peer link has been closed completely
18
19
5559-65 535 Reserved
20
21
22
23 EDITORIAL NOTE—The Mesh status codes need to be allocated before sponsor ballot by ANA.
24
25
26
27
28 7.3.1.11 Action field
29
30
32
33
34 Table 7.24—Category values
35
36
37 Value Meaning See subclause
38
39 <ANA 16> Mesh Peer Link 7.4.9
40 Management
41
42 <ANA 17> Mesh Link Metric 7.4.10
43
<ANA 18> Mesh Path Selection 7.4.11
44
45 <ANA 19>
46 Mesh Interworking 7.4.12
47 <ANA 20> Mesh Resource Coordination 7.4.13
48
49 <ANA 21> Mesh Security Architecture 7.4.14
50
(MSA)
51
52 97-126 Reserved ---
53
54
55
56 EDITORIAL NOTE—The Mesh category value to be allocated by allocated before sponsor ballot by
57 ANA.
58
59
60 7.3.1.17 QoS Info field
61
62 Insert the following text to the end of 7.3.1.17
63
64
65 The format of the QoS Info field, when sent by the MP, is as same as when sent by a non-AP QSTA.

IEEE P802.11s/D1.05, June 2007
1
2
3 EDITORIAL NOTE—numbering of following subclauses based on TGn ending with 7.3.1.33
4
5
6
Insert the following new subclauses after the last subclause in 7.3.1 and renumber accordingly:
7
8 7.3.1.34 Mesh Action field
9
10 The Mesh Action field provides a mechanism for specifying mesh management actions. The format of the
11
12
Mesh Action field is shown in Figure s9.
13
14 Octets: 1 variable
15
16 Category Mesh Action Details
17
18
19
Figure s9—Mesh Action field
20
21
22 The Category field is set to one of the nonreserved values shown in Table s2. Mesh Action frames of a
23 given category are referred to as <category name> Mesh Action frames.
24
25
26 If an MP receives an individually addressed Mesh Action frame with an unrecognized Category field or
27 some other syntactic error and the MSB of the Category field set to 0, then the MP returns the Mesh Action
28 frame to the source without change except that the MSB of the Category field is set to 1.
29
30
31 The Mesh Action Details field contains an action value followed by zero or more non-information element
32 fields, and zero or more information elements. The details of the actions allowed in each category are
33 described in the appropriate subclause referenced in Table s2.\
34
35
36 Table s2—Mesh Action Category values
37
38
39 Code Meaning See subclause
40
41 0 MSA 7.4A.1
42
43 1-126 Reserved –
44
45 127 Vendor Specific –
46
47 128-255 Error (MSB reserved for error
48 signalling)
49
50
51
52 7.3.1.35 Message integrity check field
53
54 The Message integrity check field contains a MIC value calculated over the contents of an action frame.
55 The MIC is calculated using the AES-128-CMAC algorithm. AES-128-CMAC is defined by FIPS SP800-
56 38B. The length of the Message integrity check field is 16 octets.
57
58
59 The Message integrity check field is defined in Figure s10.
60
61 7.3.1.36 Mesh Key Transport Control field
62
63
64 The Mesh Key Transport Control field is used in the Mesh Action frames that implement the Mesh Key
65 Transport protocol (see 7.4b.1).

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 16
3
4 MIC
5
6 Figure s10—Message integrity check field
7
8
9
10 The Mesh Key Transport Control field is 62 octets in length and is defined in Figure s11A.
11
12
13 Octets: 8 6 16 32
14
15 Replay SPA PMK-MKD MPTKANonce
16 Counter Name
17
18 Figure s11—Mesh Key Transport Control field
19
20
21
22 The Replay Counter field contains a sequence number, represented as an unsigned binary number, used to
23 detect replayed frames.
24
25 The SPA field contains the MAC address of the supplicant MP that, during its Initial MSA Authentication,
26
created the PMK-MA that is being requested, delivered, confirmed, or deleted.
27
28
29 The PMK-MKDName field contains the identifier of the PMK-MKD that was used to derive the PMK-MA
30 that is being requested, delivered, confirmed, or deleted.
31
32
The MPTKANonce field contains the pseudo-random value selected by the MKD and used in the derivation
33
34 of the PMK-MKD identifier provided in the PMK-MKDName field.
35
36 7.3.1.37 Mesh Wrapped Key field
37
38
The Mesh Wrapped Key field is used in the PMK-MA delivery push and PMK-MA delivery pull Mesh
39
40 Action frames (see 7.4b.1.2 and 7.4b.1.5).
41
42 The Mesh Key Transport Control field is defined in Figure s12.
43
44
45 Octets: 2 variable
46
47 Wrapped Context Length Wrapped Context
48
49
Figure s12—Mesh Wrapped Key field
50
51
52
53 The Wrapped Context Length field indicates the number of octets contained in the Wrapped Context field.
54
55
The Wrapped Context field contains a PMK-MA and related key context information, wrapped using the
56
57 NIST AES Key Wrap algorithm, as defined in IETF RFC 3394.
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.3.2 Information elements

2
3
4 Insert the following entries in Table 7.26 and change the Reserved row as shown.
5
6
7 Table 7.26—Element IDs
8
9
10 Information element Element ID Length (in octets)
11
12 Mesh Configuration <ANA 22> 18
13
14 Mesh ID <ANA 23> 0 to 255
15
16 Link Metric Report <ANA 24> 1 to 255
17
18 Target Transmission Rate <ANA 25> 18
19 Offered Traffic Load <ANA 26> 16
20
21 Neighborhood Congestion <ANA 27> 3
22
23 Peer Link Management <ANA 28> 3 to 7
24
25 Mesh Channel Switch Announcement <ANA 29> 13
26
27 Mesh Neighbor List <ANA 30> 1 to 255
28 Mesh DTIM <ANA 31> 2
29
30 Beacon Timing <ANA 32> 5 to 255
31
32 MDAOP Setup Request <ANA 33> 8 to 255
33
34 MDAOP Setup Reply <ANA 34> 3
35
36 MDAOP Advertisements Request <ANA 35> 0
37 MDAOP Advertisements <ANA 36> 1 to 255
38
39 MDAOP Set Teardown <ANA 37> 7
40
41 Connectivity Report <ANA 38> 14 to 255
42
43 Portal Announcement (PANN) <ANA 39> 17
44
45 Root Announcement (RANN) <ANA 40> 21
46 Path Request (PREQ) <ANA 41> 36 to 255
47
48 Path Reply (PREP) <ANA 42> 32 to 255
49
50 Path Error (PERR) <ANA 43> 13
51
52 Proxy Update (PU) <ANA 44> 12 to 255
53
54 Proxy Update Confirmation (PUC) <ANA 45> 10
55 HELLO <ANA 46> 27 to 255
56
57 Topology Control (TC) <ANA 47> 25 to 255
58
59 Multiple Interface Declaration (MID) <ANA 48> 19 to 255
60
61 Local Association Base Advertisement <ANA 49> 28 to 255
62 (LABA)
63
64 Local Association Base Checksum Advertise- <ANA 50> 18 to 255
65 ment (LABCA)

IEEE P802.11s/D1.05, June 2007
1 Table 7.26—Element IDs

2
3
4 Information element Element ID Length (in octets)
5
6 Association Base Block Request (ABBR) <ANA 51> 21 to 255
7
8 Mesh Security Capability <ANA 52> 7
9
10 MSA Handshake <ANA 53> 88 to 255
11 Mesh Key Holder Security <ANA 54> 98
12
13 Mesh Encrypted Key <ANA 55> 82 to 255
14
15 EAP Authentication <ANA 56> 42
16
17 EAP Message <ANA 57> 2 to 255
18
19 Reserved <ANA 58>
20
21
22 EDITORIAL NOTE—Assignment of values for these information elements needs to be approved by
23
IEEE 802.11 ANA. Until that time, these values are marked as <ANA>. Final values will be requested
24
25 from IEEE 802.11 ANA once this amendment reaches the 75% approval threshold in Sponsor Ballot.
26
27
28
29
7.3.2.1 SSID element
30
31
32 Change the second paragraph of 7.3.2.1 as shown:
33
34 The length of the SSID information field is between 0 and 32 octets. A 0 length information field is used
35
within Probe Request management frames to indicate the wildcard SSID. The wildcard SSID is also used in
36
37 Beacon management frames transmitted by non-AP MPs.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.3.2.25 RSN information element

2
3
4
7.3.2.25.2 AKM Suites
5
6 Insert two new rows and change the existing ‘Reserved’ row in Table 7.34 as shown.
7
8
9 Table 7.34—AKM Suite Selectors
10
11
12 OUI Suite Type Authentication type Key management type
13
14 00-0F-AC <ANA 59> MSA Authentication negotiated MSA Key Management
15 over IEEE 802.1X, or using
16 PMKSA caching as defined in
17 8.4.6.2
18
19 00-0F-AC <ANA 60> MSA Authentication using PSK MSA Key Management
20
21 00-0F-AC 57-255 Reserved Reserved
22
23
24
25 EDITORIAL NOTE—Assignment of AKM Suite Selector types needs to be approved by IEEE 802.11
26 ANA. Until that time, these values are labeled as <ANA>. Final values will be requested from ANA once
27 this amendment reaches the 75% approval threshold in Sponsor Ballot.
28
29
Insert the following new subclauses after 7.3.2.52
30
31
32 EDITORIAL NOTE—numbering of following subclauses based on TGw ending with 7.3.2.53
33
34 7.3.2.54 Mesh Configuration element
35
36
37 The “Mesh Configuration” element shown in Figure s13 is used to advertise Mesh services. It is contained in
38 Beacon frames transmitted by MPs, and is also contained in Peer Link Open and Peer Link Confirm frames.
39
40
41 Octets:1 1 1 4 4 4 2
42 ID Length Version Active Path Active Path Channel Mesh Capability
43 Selection Selection Precedence
44 Protocol Metric Iden-
45 Identifier tifier
46
47
48 Figure s13—Mesh Configuration element
49
50
51
52
The Element ID is set to the value given in Table 7.26 for this information element. The Length field is set to
53 15. The version is set to 1.
54
55 The remainder of the fields are described in the following subclauses.
56
57
58 7.3.2.54.1 Active Path Selection Protocol Identifier
59
60 MPs support one or more path selection protocols and one or more path metrics. However, only one path
61 selection protocol and one path metric may be active in a particular mesh network at a time. The Active Path
62
Selection Protocol Identifier field indicates the path selection protocol that is currently used to generate path
63
64 selection information on an MP, as defined in 11A.5. The format of the Active Path Selection Protocol iden-
65 tifier is shown in Figure s14. Path selection protocol identifier values are listed in Table s3.

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 3 1
3 OUI Path selection protocol
4 identifier value
5
6
7 Figure s14—Active path selection protocol identifier field
8
9
10 Table s3—Path selection protocol identifier values
11
12
13 OUI Value Meaning
14
15 00-0F-AC 0 Hybrid Wireless Mesh Protocol (default
16 path selection protocol)
17
18 00-0F-AC 1 Radio Aware OLSR (optional path selection
19 protocol)
20
21 00-0F-AC 2-254 Reserved for future use
22
23 00-0F-AC 255 Null protocol
24 Vendor OUI 0-255 Vendor specific
25
26
27
28 A Null protocol indicates the MP has no active layer 2 path selection and forwarding. An MP with Null pro-
29 tocol does not send or respond to path selection protocol messages.
30
31
32 7.3.2.54.2 Active Path Selection Metric Identifier
33
34
35 The Active Path Selection Metric Identifier field indicates the path metric that is currently used by the active
36
path selection protocol in the mesh network. The format of the Active Path Selection Metric Identifier is
37
38 shown in Figure s15. Path selection metric identifier values are defined in Table s4.
39
40 Octets: 3 1
41
42 OUI Path selection metric
43 identifier value
44
45
46 Figure s15—Active path selection metric identifier field
47
48
49 Table s4—Path selection metric identifier values
50
51
52 OUI Value Meaning
53
54 00-0F-AC 0 Airtime link metric defined in 11A.7
55 (default path selection metric)
56
57 00-0F-AC 1-254 Reserved for future use
58
59 00-0F-AC 255 Null metric
60 Vendor OUI 0-255 Vendor specific
61
62
63
64
65 The null metric is used in conjunction with null path selection protocol setting.

IEEE P802.11s/D1.05, June 2007
1 7.3.2.54.3 Channel Precedence

2
3
4 The channel precedence field is set to the value of channel precedence of the unified channel graph to which
5 the MP PHY belongs. Usage of the channel precedence field is described in 11A.3. A value of 0 identifies
6 that the MP PHY is not currently operating with the simple channel unification protocol.
7
8
9 7.3.2.54.4 Mesh Capability
10
11 The mesh capability field comprises a set of values indicating whether an MP is a possible candidate for peer
12
13 link establishment. The details of the mesh capability field are shown in Figure s16.
14
15 B0 B1 B2 B3 B4 B5 B6 B15
16
17 Accepting Power Save Synchroniza- Synchroniza- Synchroniza- MDA Reserved
18 Peer Links Support tion Enabled tion Active tion Support Enabled
19 Enabled Required
20 from Peer
21
22 Bits: 1 1 1 1 1 1 10
23
24
Figure s16—Mesh Capability field
25
26
27
28 The “Accepting Peer Links” field is set to 1 if the MP is able and willing to establish peer links with other
29
30
MPs and set to 0 otherwise.
31
32 The “Power Save Support Enabled” field is set to 1 if the MP is a power save supporting MP and capable of
33 maintaining peer links with MPs in Power Save mode and set to 0 otherwise.
34
35
36 The “Synchronization Enabled” field is set to 1 if the MP supports timing synchronization with peer MPs
37 and is set to 0 otherwise.
38
39
40 The “Synchronization Active” field is set to 1 if the MP is currently a synchronizing MP and set to 0 other-
41 wise.
42
43
44 The “Synchronization Support Required from Peer” field is set to 1 if the MP requests MP peers attempting
45 to communicate with it to synchronize with it and set to 0 otherwise.
46
47
48
The “MDA Enabled” field is set to 1 if the MP supports MDA services and set to 0 otherwise.
49
50
51
52
53 7.3.2.55 Mesh ID element
54
55
The “Mesh ID” element is used to advertise the identification of a mesh network and is described in
56
57 11A.1.2. The contents are shown in Figure s17. The Mesh ID element may be transmitted in Beacon frames,
58 Peer Link Open and Peer Link Confirm frames, and Probe Request and Response frames.
59
60
61 Octets: 1 1 0-32
62 ID Length Mesh ID
63
64
65 Figure s17—Mesh ID element format

IEEE P802.11s/D1.05, June 2007
1 The Element ID is set to the value given in Table 7.26 for this information element.
2
3
4 The length of the Mesh ID is between 0 and 32 octets. A value of 0 in the length field may be used to indi-
5 cate the wildcard Mesh ID.
6
7
8 7.3.2.56 Link metric report element
9
10
11 A link metric report element is transmitted by an MP to a peer MP to indicate the quality of the link between
12 them. This information may be used to ensure that the link metric is symmetric for all mesh links if the path
13 selection protocol so requires.
14
15
16 The contents of the element are shown in Figure s18.
17
18
19 Octets: 1 1 variable
20
21 ID Length metric M
22
23 Figure s18—Link Metric Report element
24
25
26
27 The Element ID is set to the value given in Table 7.26 for this information element. The length is set to the
28
length of the metric field, as defined by the active path selection metric.
29
30
31 The metric M is the value of the link metric associated with the link between the peer MP sending the link
32
33 metric report and the local MP.
34
35
The link metric report element may be used in the generation of a link metric such as the airtime metric
36
37 defined in 11A.7.
38
39
40
7.3.2.57 Mesh ATIM window parameter element
41
42 The Mesh ATIM window parameter element contains the ATIM Window parameter. It is present in Beacon
43
44 and Probe Response frames when the MP is operating in power save mode or intends to operate in power
45 save mode.
46
47
48 The contents of the element are shown in Figure s19.
49
50 Octets: 1 1 2
51
52 ID Length ATIM Win-
53 dow param-
54 eter
55
56
57 Figure s19—Mesh ATIM window parameter element
58
59
60
61 The Element ID is set to the value given in Table 7.26 for this information element. The length is set to 2.
62
63
64 The Mesh ATIM window parameter field is 2 octets in length and contains the ATIM window length in
65 TUs.

IEEE P802.11s/D1.05, June 2007
1 7.3.2.58 Target Transmission Rate element

2
3
4
The Target Transmission Rate element is used in the Congestion Control Request frame by an MP to indi-
5 cate to its upstream neighbor the target data rate the two MPs should coordinate to maintain. It contains four
6 target Data Rate fields for the four EDCA access categories and an Expiration Timer. The format of the ele-
7 ment is shown in Figure s20.
8
9
10 Octets: 1 1 4 4 4 4 2
11
12 ID Length Target Data Target Data Target Data Target Data Expiration
13 Rate Rate Rate Rate Timer
14 (AC_BK) (AC_BE) (AC_VI) (AC_VO)
15
16 Figure s20—Target Transmission Rate element format
17
18
19
21
22 Target Data Rate for a given Access Category indicates the mean transmission rate in b/s from the upstream
23 MP to the downstream neighboring MP for this AC. The upstream MP does not exceed the target Data Rate;
24
25 otherwise it may result in congestion at the downstream MP.
26
27 Expiration timer indicates the valid period of Target Data Rates information provided in this element. Expi-
28 ration Timer is represented in TU.
29
30
31 7.3.2.59 Offered Traffic Load element
32
33 An “Offered Traffic Load” element is used in the Congestion Control Response frame by an MP to indicate
34 to its downstream neighbor the incoming traffic load between itself and the downstream neighbor. It con-
35
tains four Offered Traffic Load fields for the four access categories. The format of the element is shown in
36
37 Figure s21.
38
39 Octets: 1 1 4 4 4 4
40
41 ID Length Offered Offered Offered Offered
42 Traffic Traffic Traffic Traffic
43 Load Load Load Load
44 (AC_BK) (AC_BE) (AC_VI) (AC_VO)
45
46
47 Figure s21—Offered Traffic Load element format
48
49
51
52
53 Offered Traffic Load for a given Access Category indicates the incoming traffic rate in b/s estimated or mea-
54 sured at the MAC interface. This information can be used by the downstream neighboring MP to better esti-
55 mate the Target Data Rate.
56
57
58 7.3.2.60 Neighborhood Congestion element
59
60 A “Neighborhood Congestion” element is used by an MP to indicate to its neighbors its congestion level. It
61 contains a congestion level field and an expiration timer field. The format of the element is shown in
62 Figure s22.
63
64

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 1 1 1 2
3 ID Length Congestion Expiration
4 Level Timer
5
6
7 Figure s22—Neighborhood Congestion element format
8
9
10 The congestion level is TBD.
11
12
13 The expiration timer indicates the valid period of congestion information provided in this element and is rep-
14 resented in TU.
15
16 7.3.2.61 Peer Link Management element
17
18
19 The Peer Link Management element is transmitted by an MP to manage a peer link with a peer MP. The for-
20 mat of the Peer Link Management element is shown in Figure s23.
21
22
23 Octets: 1 1 1 2 2 2
24
25 Element ID Length Subtype Local Link ID Peer Link ID Reason Code
26
27 Figure s23—Peer Link Management element
28
29
30
32
33 The Subtype field specifies the type of the Peer Link Management element. There are three subtypes: Peer
34 Link Close (0), Peer Link Open (1), and Peer Link Confirm (2). The values 3—28-1 are reserved.
35
36
37 The Peer Link Management element with subtype 0 is referred to as Peer Link Close element. The Peer Link
38 Management element with subtype 1 is referred to as Peer Link Open element. The Peer Link Management
39 element with subtype 2 is referred to as Peer Link Confirm element.
40
41
42 The value of the Length field varies depending on the subtype of the Peer Link Management element. The
43 Length is 7 for Peer Link Close, 3 for Peer Link Open, and 5 for Peer Link Confirm.
44
45 The Local Link ID is the integer generated by the MP to identify the link instance. This field is present for
46
47
all three types of Peer Link Management elements.
48
49 The Peer Link ID is the integer generated by the peer MP to identify the link instance. This field is not
50 present for the Peer Link Open subtype, is present for the Peer Link Confirm subtype, and may be present
51 for the Peer Link Close subtype.
52
53
54 The Reason Code field enumerates reasons for sending a Peer Link Close. It is present for the Peer Link
55 Close subtype and is not present for Peer Link Open or Peer Link Confirm subtypes. This field enumerates
56 the following reasons:
57
58 — MESH-LINK-CANCELLED: IEEE 802.11 SME cancels the link instance.
59 — MESH-MAX-NEIGHBORS: The limit of maximum of neighbors is reached.
60
61 — MESH-CONFIGURATION-POLICY-VIOLATION: The received request violates the MP’s Mesh
62 Configuration.
63
64 — MESH-CLOSE-RCVD: The MP has received a correct Peer Link Close message (according to crite-
65 ria defined in 11A.2.2).

IEEE P802.11s/D1.05, June 2007
1 — MESH-MAX-RETRIES: The limit of dot11MeshMaxRetries is reached.

2
3 — MESH-CONFIRM-TIMEOUT: The confirmTimer times out.
4
5
6
7
7.3.2.62 Mesh Channel Switch Announcement element
8
9
10 The Mesh Channel Switch Announcement element is used by an MP in a Mesh to advertise when it is
11 changing to a new channel and the channel number and precedence value of the new channel (See 11A.3.3).
12 The format of the Mesh Channel Switch Announcement element is shown in Figure s24.
13
14
15
16 Octets: 1 1 1 1 4 1 6
17
18 ID Length Channel New Chan- New Chan- Channel Source
19 Switch nel Number nel Prece- Switch Address
20 Mode dence Count
21 Indicator
22
23
24 Figure s24—Mesh Channel Switch Announcement element
25
26
27 The Element ID is set to the value given in Table 7.26 for this information element. The length is set to 13
28
octets.
29
30
31 The Channel Switch Mode field indicates restrictions on transmission until a channel switch. An MP sets the
32 Channel Switch Mode field to either 0 or 1 on transmission. A Channel Switch Mode set to 1 means that the
33 MP to which the frame containing the element is addressed is advised to transmit no further frames on the
34
35
current channel until the scheduled channel switch. A Channel Switch Mode set to 0 does not impose
36 requirement on the receiving MP. Values from 2 to 255 are reserved.
37
38 The New Channel Number field is set to the number of the channel to which the MP is moving.
39
40
41 The New Channel Precedence Indicator field is set to the channel precedence value of the channel to which
42 the MP is moving. See 11A.3 for more information on the channel precedence indicator.
43
44 The Channel Switch Count field is set to the time in TUs (in the range from 0-255) until the MP sending the
45 Mesh Channel Switch Announcement element switches to the new channel.
46
47
48 The Source Address field is set to the address of the MP that originates the frame.
49
50 The Mesh Channel Switch Announcement element is included in Mesh Channel Switch Announcement
51
52
frames.
53
54 7.3.2.63 Mesh Neighbor List element
55
56 The Mesh Neighbor List element is used by an MP to advertise its peer MPs and their Power Management
57
58 Mode. The element contains list of the MAC addresses of current peer MPs and information about their
59 Power Management Mode. The MP Control field contains the connectivity reporting control information.
60
61 The format of the Mesh Neighbor List element is shown in Figure s25.
62
63
64 The Element ID is set to the value given in Table 7.26 for this information element. The length is set to 1 to
65 255 octets.

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 1 1 1 1 6 6 ... 6 ceiling(n/8)
3 ID Length MP con- Neighbor MAC MAC ... MAC Neighbor
4 trol Count Address Address Address operating in
5 of neigh- of neigh- of neigh- power save
6 bor 1 bor 2 bor n mode (bit-
7 field)
8
9
10 Figure s25—Mesh Neighbor List element
11
12
13 The format of the MP control field is shown in Figure s26.
14
15
16 B1 B3 B4 B5 B6 B7
17
18 Connectivity Reserved Designated BB switch Power man-
19 Reporting BB agement
20 Interval mode of
21 reporting MP
22
23 Bits: 4 1 1 1 1
24
25 Figure s26—MP Control field
26
27
28
29 The Connectivity Reporting Interval specifies an integer value of the mesh DTIM Beacon frames between
30 the Connectivity Report transmissions. Connectivity Reporting Interval set to zero indicates that connectiv-
31
ity reporting is not used.
32
33
34 The Designated BB field is set to 1 if the current beacon broadcaster is a designated beacon broadcaster that
35
36
operates according to the scheme described in 11A.12.3.2.1. It is set to 0 otherwise.
37
38 The BB switch bit field is used to indicate the change of the beacon broadcaster. If this bit is set to 1, the
39
40 next beacon is sent by the MP whose MAC address is the first one in the neighbor list.
41
42 The Power management mode of reporting MP field indicates the beacon broadcaster’s power management
43
44 mode. If the Power management mode of reporting MP bit is set to 1, then the beacon broadcaster sends only
45 Beacons sent with the DTIM count field in the DTIM element set to 0. If the Power management mode of
46 reporting MP bit is set to 0, then the beacon broadcaster is in active mode.
47
48
49 The MAC addresses of the neighbors are set for the MPs that have established links to their peers, which are
50 listed in the Connectivity Reports received by the BB within dot11BBConnectivityReportTimeout
51 mesh DTIM intervals.
52
53
54 The neighbor operating in power save mode bitfield indicates the current power save mode of each neighbor
55 list member. Each bit of this field indicates the power management mode of the corresponding neighbor list
56
member. If a bit is set to 0, then the corresponding neighbor list member is in “active mode” and if a bit is set
57
58 to 1, the corresponding neighbor list member is in “Power Save mode”. For example, if the Mesh Neighbor
59 List element contains 8 MAC addresses and the neighbor operating in power save mode bitfield is
60 ‘00110001’, then the MPs with MAC addresses in positions 3, 4, and 8 in the neighbor list are in the power
61 save mode. The neighbor operating in power save mode bitfield length is zero-padded to an integer number
62
of octets. The bits are in the same order as the MAC addresses. The length of the neighbor operating in
63
64 power save mode field is the following number of octets: least integer greater than or equal to n divided by
65 8.

IEEE P802.11s/D1.05, June 2007
1 7.3.2.64 Mesh TIM element

2
3
4 The Mesh TIM element contains four fields: Mesh DTIM count, Mesh DTIM period, Bitmap control, and
5 Partial virtual bitmap. The field structure of the Mesh TIM element is the same as the TIM element.
6
7 The format of the Mesh DTIM element is shown in Figure s27.
8
9
10 Octets: 1 1 1 1 1 1-251
11
12 ID Length Mesh DTIM Mesh DTIM Bitmap Partial Vir-
13 Count Period Control tual Bitmap
14
15 Figure s27—Mesh TIM element
16
17
18
19 The Element ID is set to the value given in Table 7.26 for this information element. The length field indi-
20 cates the length of this information element, which is constrained as described below.
21
22
23 The Mesh DTIM Count field indicates the number of Beacon frames (including the current frame) that
24 appear before the next Mesh DTIM. A Mesh DTIM count of 0 indicates that the current TIM is a Mesh
25 DTIM. The Mesh DTIM count field is a single octet.
26
27
28 The Mesh DTIM Period field indicates the number of Beacon intervals between successive Mesh DTIMs. If
29 all TIMs are Mesh DTIMs, the Mesh DTIM Period has the value 1. The Mesh DTIM Period value 0 is
30 reserved. The Mesh DTIM period field is a single octet.
31
32
33 The Bitmap Control field is a single octet. Bit 0 of the field contains the Traffic Indicator bit associated with
34 AID 0. This bit is set to 1 in Mesh TIM elements with a value of 0 in the Mesh DTIM Count field when one
35 or more broadcast or multicast frames are buffered at the MP. The remaining 7 bits of the field form the Bit-
36
map Offset.
37
38
39 The traffic-indication virtual bitmap, maintained by the MP that generates a Mesh TIM, consists of 2008
40 bits, and is organized into 251 octets such that bit number N ( 0 ≤ N ≤ 2007 ) in the bitmap corresponds to bit
41 number (N mod 8) in octet number N/8 where the low-order bit of each octet is bit number 0, and the high
42
43 order bit is bit number 7. Each bit in the traffic-indication virtual bitmap corresponds to traffic buffered for a
44 specific neighboring MP within the Mesh that the MP is prepared to deliver at the time the beacon frame is
45 transmitted.
46
47
48 Bit number N is 0 if there are no directed frames buffered for the neighboring MP whose AID is N. If any
49 directed frames for that neighboring MP are buffered and the MP is prepared to deliver them, bit number N
50 in the traffic-indication virtual bitmap is 1.
51
52
53
The Partial Virtual Bitmap field consists of octets numbered N1 through N2 of the traffic indication virtual
54 bitmap, where N1 is the largest even number such that bits numbered 1 through (N1 × 8) - 1 in the bitmap
55 are all 0 and N2 is the smallest number such that bits numbered (N2 + 1) × 8 through 2007 in the bitmap are
56 all 0. In this case, the Bitmap Offset subfield value contains the number N1/2, and the Length field is be set
57 to (N2 - N1) + 4.
58
59
60 In the event that all bits other than bit 0 in the virtual bitmap are 0, the Partial Virtual Bitmap field is
61 encoded as a single octet equal to 0, the Bitmap Offset subfield is 0, and the Length field is 4.
62
63
64 Beacon frames transmitted by MAP may include both contains both TIM element and Mesh TIM element, if
65 it supports both BSS power management and Mesh power management. The DTIM Period in TIM element

IEEE P802.11s/D1.05, June 2007
1 and Mesh DTIM period in Mesh TIM element do not have to be identical since one will be used for the AP
2 service while the other will be used for the Mesh service.
3
4
5 7.3.2.65 Beacon Timing element
6
7 The Beacon Timing element is used by a synchronizing MP to advertise an offset between its self TSF and
8
the Mesh TSF, and to advertise the beacon timing information of zero or more of its neighbors. The format
9
10 of the Beacon Timing element is shown in Figure s28.
11
12 Octets: 1 4 1 1 3 1 3 ...
13 1
14
15 ID Length Self Bea- Number of Last byte of Synchro- Last byte of Synchro- ...
16 con Timing Synchro- MAC nized MAC nized
17 nizing Address of Beacon Address of Beacon
18 neighbors Synch MP Timing Synch MP Timing
19 reported 1 MP 1 2 MP 2
20
21
22
23
24
25 1 3 1 5 … 1 5
26
27 Last byte of Synch Last byte of Non-syn- … Last byte of Non-syn-
28 MAC Beacon MAC chronized MAC chronized
29 Address of Timing Address of Beacon Address of Beacon
30 Synch MP MP n Non-synch Timing Non-synch Timing
31 n MP 1 non-synch MP m non-synch
32 MP 1 MP m
33
34
35
36 Figure s28—Beacon Timing element
37
38
39
41 255 octets.
42
43 The format of the Self Beacon Timing field is shown in Figure s29.
44
45
46 Octets: 3 1
47
48 Self TBTT MP DTIM
49 offset period
50
51 Figure s29—Self Beacon timing
52
53
54
55 The ‘Self TBTT offset’ subfield of the Self Beacon timing field indicates the offset, measured in TUs, used
56 by the MP for its TSF time compared to the Mesh TSF. The sum of the MP TSF time stamp and the offset
57
equals the mesh TSF time.
58
59
60 The ‘MP DTIM period’ subfield of the Self Beacon timing field indicates the MP DTIM period of the spe-
61 cific MP (i.e., how many Beacon intervals of the MP compose a single Mesh DTIM interval).
62
63
64 The ‘Number of Synchronizing Neighbors Reported’ field specifies the number of synchronizing neighbors
65 whose beacon timing information is reported following this field.

IEEE P802.11s/D1.05, June 2007
1 The beacon timing information of synchronizing neighbors is reported in terms of the last byte of MAC
2 address field and the ‘Synchronized Beacon Timing’ field that are included as pairs. The Beacon Timing
3
element may contain zero or more ‘Last byte of MAC Address of Synch MP’ and the ‘Synchronized Beacon
4
5 Timing’ field pairs.
6
7 The Last Byte of MAC Address of Synch MP field indicates the last byte of the MAC address of neighbors
8 that have a non-zero Self TBTT offset value, whose information is reported in the value of the next ‘Syn-
9
10 chronized Beacon Timing’ field. The Last Byte of MAC address need not be unique, as the relevant infor-
11 mation is the timing information that follows it. The relevant information is the set of times when successful
12 Beacon frames are being received.
13
14
The format of the Synchronized Beacon Timing field is shown in Figure s30.
15
16
17 Octets: 1 1 1
18
19 TBTT off- Time since MP DTIM
20 set last beacon period
21
22
Figure s30—Synchronized Beacon Timing field
23
24
25
26 The ‘TBTT offset’ field is expressed in units of TU, and indicates the offset used by the neighboring MPs
27 for their TSF time stamps compared to the Mesh TSF. For those MPs reporting self TBTT offsets with a
28
29 higher resolution than a TU, the field is rounded to the nearest TU.
30
31 The ‘Time since last beacon’ field indicates the time passed measured in units of Mesh DTIM intervals since
32 last beacon was received from the specific MP.
33
34
35 The ‘MP DTIM period’ field indicates the MP DTIM period of the specific MP (i.e., how many Beacon
36 intervals of the MP compose a single Mesh DTIM interval).
37
38
Beacon timing information for non-synchronizing MP neighbors may also be included at the end of the Bea-
39
40 con timing element following the synchronizing neighbor information.
41
42 The beacon timing information of non-synchronizing neighbors is reported in terms of the ‘Last byte of the
43 MAC Address of Non-synch MP’ and the ‘Non-synchronized Beacon Timing’ fields that are included as
44
45 pairs.
46
47 The ‘Last byte of the MAC Address of Non-synch MP’ indicates the last byte of the MAC address of non-
48 synchronizing neighbor whose beacon timing information is reported in the value of the next ‘Non-synchro-
49
nized Beacon Timing’ field.
50
51
52 The format of the ‘Non-synchronized Beacon Timing’ field is as shown in Figure s31.
53
54
55 Octets: 3 2
56
Last Bea- MP Beacon
57
con Time Interval
58
59
60 Figure s31—Non-synchronized Beacon Timing field
61
62
63
64 The Last Beacon Time field is measured in microseconds and specifies the time at which the last beacon
65 from the specified MP was received relative to the beacon time stamp of the information element transmit-

IEEE P802.11s/D1.05, June 2007
1 ting MP, or the most recent TBTT of the information element transmitting MP if the Beacon Timing element
2 is encapsulated in a response frame.
3
4
5 The MP Beacon Interval field specifies the beacon interval being used by the MP whose information is
6 being reported.
7
8
9 7.3.2.66 MDAOP Setup Request element
10
11 The MDAOP Setup Request information element is used by an MP to request the setup of a set of MDAOPs,
12
13 identified by a single MDAOP Set ID, between itself (transmitter) and a receiver. This information element
14 is transmitted in individually addressed MDA action frames. The format of the information element is as
15 shown in Figure s32.
16
17
18 Octets: 1 1 1 1 1 2
19
20 Element ID Length MDAOP Set ID MDAOP Duration MDAOP Periodicity MDAOP Offset
21
22 Figure s32—MDAOP Setup Request element
23
24
25
27 octets.
28
29
30 The MDAOP Set ID field is an eight bit unsigned integer that represents the ID for the requested Set.
31
32
33 The MDAOP Duration field specifies the duration of the MDAOP in multiples of 32 µs .
34
35 The MDAOP Periodicity field is a non-negative integer that specifies the number of subinterval periods by
36
which the Mesh DTIM interval is divided. A value of zero indicates a non-repeated reservation for and
37
38 MDAOP in the mesh DTIM interval following the setup.
39
40 The MDAOP Offset field specifies the position of an MDAOP beginning from the beginning of the Mesh
41
42
DTIM interval and subsequent subinterval periods within the Mesh DTIM interval. The value is specified in
43 multiples of 32 µs .
44
45 An example of periodicity, duration, and offset values for a periodic MDAOP Info field is shown in
46
47 Figure s33. In this particular example, the periodicity equals four, so that there are four subintervals within
48 the mesh DTIM interval. As further illustrated in the figure, the two offset values indicate the start of the
49 MDAOP relative to the start of these subintervals.
50
51 Mesh DTIM Interval
52
53 Periodicity = 4 (equal size sub-intervals)
54
55 Subinterval
56
57
58
59
60
61 Offset
Duration
62
63
64 = MDAOPs
65

IEEE P802.11s/D1.05, June 2007
1 Figure s33—Values for Periodic MDAOP Info field for an example MDAOP set
2
3
4 7.3.2.67 MDAOP Setup Reply element
5
6 The MDAOP Setup Reply element is used to reply to an MDAOP Setup Request. Its format is as shown in
7 Figure s34. The Element ID is set to the value given in Table 7.26 for this information element. The length is
8
9
set to 3.
10
11 Octets: 1 1 1 1 variable
12
13 Element ID Length MDAOP Set Reply Code Alternate sug-
14 ID gested Request
15 element
16
17
18 Figure s34—MDAOP Setup Reply element
19
20
21
The reply code set to 0 is used to accept the request and 1 rejects the request. All other bits are reserved.
22
23
24 The Alternate Suggested Request information element field includes a suggested format of the MDAOP
25 Setup Request information element without the length and element ID fields, so that the setup request may
26 be accepted. This field is an optional field and is only included/interpreted when the reply code indicates
27
28 rejection.
29
30 7.3.2.68 MDAOP Advertisements Request element
31
32
33 The MDAOP Advertisements Request element is used to request MDA advertisements from neighbors. The
34 format of the information element is shown in Figure s35.
35
36
37 Octets: 1 1
38
39 Element ID Length
40
41 Figure s35—MDAOP Advertisements Request element
42
43
44
46
47
48
7.3.2.69 MDAOP Advertisements element
49
50 The MDAOP Advertisements Element is used by an MP to advertise its MDA state to its neighbors. This
51 information element may be carried in selected Beacon frames with a chosen frequency. This information
52
element may also be transmitted in an MDA action frame. The format of the information element is as
53
55
56 B0 B7 B8 B15 B16 B19 B20 B23
57
58 Element Length MDA MDA Access TX-RX Interfering times
59 ID Access frac- fraction limit times report
60 tion report
61
62 Bits: 8 8 4 4 variable variable
63
64
65 Figure s36—MDAOP Advertisements element

IEEE P802.11s/D1.05, June 2007
2 255 octets.
3
4
5 MDA Access Fraction and MDA Access Fraction Limit fields are both 4 bit unsigned number fields. They
6 denote a positive fraction expressed in units of (1/16). The MDA Access Fraction field represents the current
7 value of MDA Access Fraction at the MP rounded down (floor) to the nearest multiple of (1/16). The MDA
8 Access Fraction Limit field represents the maximum MDA access fraction allowed at the MP. This number
9
10 is always a multiple of (1/16).
11
12 The TX-RX Times Report field is a variable length field that advertises the times in the Mesh DTIM interval
13 that are busy for the MP as a transmitter or a receiver. These times may include known and otherwise un-
14
15
advertised transmission and reception times besides MDAOPs. For example, an MAP may include its
16 HCCA times in the advertisement.
17
18 The Interfering Times Report field is identical in format to the TX-RX times report field. However, through
19
this field, an MP reports the times when one of its neighbors is in TX or RX as reported by their (neighbors’)
20
21 TX-RX times report fields. This field may not include times for which the MP is a transmitter or receiver
22 (Such times are taken care of in the TX-RX times report). The Interfering Times reported may not be used to
23 transmit through MDA to the reporting MP because there may be interference between such transmission
24 sequence and the transmission sequences already setup for the reported times. However, these reported
25
times may possibly be used for transmissions through MDA to other MPs.
26
27
28 The format of the TX-RX Times and the Interfering Times Report field is shown in Figure s37. The fields
29 involved are similar to the fields involved in the MDAOP Setup Request element. While the fields are the
30 same as in an MDAOP setup request element, the TX-RX times and Interfering times reports can more effi-
31
32 ciently report information compared to MDAOP setup request elements. This is possible because different
33 MDAOPs may be combined in an efficient way and reported. MDAOP Set IDs are not reported in the adver-
34 tisements.
35
36
37 Octets: 1 4 4
38
39 Number of MDAOP 1 … MDAOP n
40 MDAOPs
41
42 Figure s37—The format of the TX-RX times report and Interfering times report fields
43
44
45
46 7.3.2.70 MDAOP Set Teardown element
47
48
The MDAOP Teardown element is as shown in Figure s38, and is used to announce the teardown of an
49
50 MDAOP Set. An MDAOP Set teardown information element may be transmitted by either the transmitter or
51 the receiver of the MDAOP Set to tear it down. The MDAOP Set Owner field is an optional field that indi-
52 cates the MAC address of the owner (transmitter) of the MDAOP Set. This field is only included if the infor-
53 mation element is transmitted by the receiver in an MDAOP set, to tear it down. The MDAOP teardown
54
element may be transmitted in Beacon frames or group addressed MDA action frames. When received in
55
56 frames (e.g., Beacon frames), the MDAOP Set Owner field is ignored, even if it is present.
57
58 Octets: 1 1 1 6
59
60 Element Length MDAOP MDAOP
61 ID Set ID Set Owner
62
63
64
65 Figure s38—MDAOP Teardown element

IEEE P802.11s/D1.05, June 2007
1 7.3.2.71 Connectivity Report element

2
3
4 The Connectivity Report element is used by an MP to list the number of beacon broadcasters during the
5 reporting interval and to list the neighbors that transmitted a connectivity report and their Power Manage-
6 ment Mode. The element contains a list of neighbor MAC addresses, where the connectivity report has been
7 received and information about the neighbor power management mode. The format of the Connectivity
8
9 Report is shown in Figure s39.
10
11 Octets: 1 1 2 6 6 … 6 6 . 6 K
12 .
13 .
14
15 ID Lengt Connectiv- SSID MAC … MAC MAC . MAC Beacon and
16 h ity Report Address Address Address of . Address of Connectiv-
17 Control of Bea- of bea- Connectiv- . Connectiv- ity Report-
18 coning coning ity Report- ity Report- ing Power
19 MP 1 MP n ing MP 1 ing MP n manage-
20 ment mode
21
22
23 Figure s39—Connectivity Report
24
25
27
28
29 The Length field is set to 8+6*(n + m) + Ceiling((n + m)/8), where n is the number of Beacon MACs and m
30 is the number of MPs. The format of the Connectivity Report Control field is shown in Figure s40.
31
32
33 B0 B3 B4 B6 B7 B8 B15
34
35 Reserved Number of Power Man- Number of
36 Sources of agement Reported
37 Received mode of MPs
38 Beacons Reporting MP
39
40 Bits: 4 3 1 8
41
42 Figure s40—Connectivity Report Control field
43
44
45
46 The Number of Sources of Received Beacons is an integer number indicating the number of Beacon frames
47 received from different transmitters. Value 0 indicates that no beacon has been received correctly during the
48 previous Connectivity Reporting Interval. Value 7 defines that 7 or more transmitters have transmitted at
49
50 least one correctly received beacon during the previous Connectivity Reporting Interval.
51
52 The Power Management Mode of Reporting MP indicates the power management mode of the reporting
53
MP. If the power management mode of the reporting MP is set to 1, then the reporting MP is required to lis-
54
55 ten only during the mesh DTIM Beacon frames and the following ATIM periods. If the Power management
56 mode of reporting MP bit is set to 0, then the Reporting MP is in active mode.
57
58
59 The Number of Reported MPs is an integer number indicating the number of Connectivity Reports or Bea-
60 con frames received from different transmitters. The Number of Reported MPs indicates the total number of
61 MAC addresses, which are reported in Connectivity Report.
62
63
64 The SSID specifies the SSID of the BSS. This information is used to differentiate connectivity reports from
65 multiple BSSs.

IEEE P802.11s/D1.05, June 2007
1 The MAC address of the Beaconing MP indicates the address, where at least one beacon has been received
2 during the previous Connectivity Reporting Interval. The number of the MAC Addresses is controlled by the
3
Number of Sources of Received Beacons field. The last received beacon in the Connectivity Reporting
4
5 Interval is the first reported MAC address of the beacon transmitter. If Beacon frames are received from
6 more than seven different MPs during the Connectivity Reporting Interval, the addresses of the first beacon
7 transmitters during the connectivity reporting interval are listed as MPs that send a Connectivity Report.
8
9
10 The MAC addresses of the MPs are set for MPs from which the Connectivity Report is received within
11 dot11BBConnectivityReportTimeout. If the Connectivity Report from the MP is not received within
12 the dot11BBConnectivityReportTimeout the MAC address of the MP is not present in the Connectiv-
13 ity Report List element.
14
15
16 The beacon and connectivity reporting power management mode field indicates the current power manage-
17 ment mode of each Beaconing and connectivity Reporting MP list member. Each bit of this field indicates
18 the power save state of the corresponding beaconing and connectivity reporting member. If a bit is set to 0,
19 then the corresponding beaconing or connectivity reporting list member is in “active mode” and if a bit is set
20
21
to 1, the corresponding beaconing or connectivity reporting list member is in “Power Save mode”. For
22 example, if the beaconing list contains one MAC address and the connectivity list elements contains 7 MAC
23 addresses and the neighbor power management mode field is ‘00110001’, then the beaconing MP is in full
24 power and the MPs that have transmitted a connectivity report with MAC addresses in positions 2, 3, and 7
25 in the connectivity reporting list are in the power save mode. The beacon and connectivity reporting power
26
27
management mode field length is always an integer number of octets.
28
29 7.3.2.72 PANN information element
30
31
32 The Portal Announcement (PANN) element is used for announcing in the mesh the presence of an MP con-
33 figured as a Portal MP (that has a live connection to an external network). MPs may use this information to
34 increase the efficiency of communication with stations outside the mesh.
35
36
37
The format of the PANN element is shown in Figure s41.
38
39 Octets: 1 1 1 1 1 6 4 4
40
41 Element Length Flags Hopcount Time to Origina- Sequence Metric
42 ID Live tor Number
43 Address
44
45
46
Figure s41—PANN element
47
48
50
51 The Flags field is reserved for future use.
52
53 The Hop Count field indicates the number of hops from the originator to the MP transmitting the request.
54
55 The Time to Live field indicates the maximum number of hops allowed for this element.
56
57 The Originator Address is set to the MAC address of the MP that is collocated with the portal.
58
59 The Sequence Number field is set to a sequence number specific for the originator.
60
61 The Metric field indicates a cumulative metric from the originator to the MP transmitting the announcement.
62
63 Detailed usage of the PANN element is described in 11A.6.
64
65

IEEE P802.11s/D1.05, June 2007
1 7.3.2.73 RANN information element

2
3
4 The RANN information element is used for announcing the presence of an MP configured as Root MP.
5 RANN elements are sent out periodically by the Root MP.
6
7 The format of the RANN element is shown in Figure s42.
8
9
10 Octets: 1 1 1 1 1 6 4 4 4
11
12 Element Length Flags Hopcount Time to Origina- Destina- Lifetime Metric
13 ID Live tor tion
14 Address Sequence
15 Number
16
17 Figure s42—RANN element
18
19
20
22
23
24 The Flags field is set as follows. Bit 0: Portal Role (0 = non-portal, 1 = portal). Bit 1 – 7: Reserved
25
26 The Hop Count field indicates the number of hops from the originator (root MP) to the MP transmitting the
27 request.
28
29
30 The Time to Live field indicates the remaining number of times the RANN may be forwarded.
31
32 The Originator Address is set to the Root MP MAC address.
33
34
35 The Destination Sequence Number is set to a sequence number specific to the originator (root MP).
36
37 The Lifetime field is set to the time for which MPs receiving the RANN consider the forwarding information
38
39 to be valid.
40
41 The Metric is set to the cumulative metric from the originator to the MP transmitting the announcement.
42
43
44 Detailed usage of the RANN element is described in 11A.8.8.
45
46
47
48
49 7.3.2.74 PREQ information element
50
51 The PREQ element is used for discovering a path to one or more destinations, building a proactive (reverse)
52
path selection tree to the root MP, and confirming a path to a destination (optional).
53
54
55 The format of the PREQ element is shown in Figure s43.
56
57
58
The Element ID is set to the value given in Table 7.26 for this information element. The length is set to 37 to
59 255 octets.
60
61 The Flags field is set as follows. Bit 0: Portal Role (0 = non-portal, 1 = portal), Bit 1: (0 = group addressed,
62
1 = individually addressed) (see 11A.8.3), Bit 2: Proactive PREP (0 = off, 1 = on), Bit 3 – 5: Reserved, Bit 6:
63
64 Address Extension (AE) (1= (destination count ==1 && proxied device address present), 0 = otherwise), Bit
65 7: Reserved.

IEEE P802.11s/D1.05, June 2007
1
2 Octets:1 1 1 1 1 4 6 4 0 or 6 4
3
4 Element Length Flags Hop- Time to PREQ Origina- Origina- Proxied Lifetime
5 ID count Live ID tor tor Address
6 Address Sequenc
7 e Num-
8 ber
9
10
11
12 4 1 1 6 4 ... 1 6 4
13
14 Metric Destina- Per Des- Destina- Destina- ... Per Des- Destina- Destina-
15 tion tination tion tion Seq. tination tion tion Seq.
16 Count Flags #1 Address Num. #1 Flags #N Address Num.
17 #1 #N #N
18
19 Figure s43—PREQ element
20
21
22
The Hop Count field is set to the number of hops from the originator to the MP transmitting the request.
23
24
25 The Time to Live field is set to the maximum number of hops allowed for this element.
26
27
28 The PREQ ID field is set to some unique ID for this PREQ.
29
30
31 The Originator Address is set to the originator MAC address.
32
33
34 The Originator Sequence Number is set to a sequence number specific to the originator.
35
36
37 The Proxied Address field is the MAC address of a proxied entity (e.g. STA) in case the PREQ is generated
38 because of a frame received from outside the mesh (e.g. BSS) and the proxied entity is the source of the
39 frame. This field is only present if the AE flag is set to 1.
40
41
42 The Lifetime field is set to the time for which MPs receiving the PREQ consider the forwarding information
43 to be valid.
44
45
46 The Metric is set to the cumulative metric from the originator to the MP transmitting the PREQ.
47
48
49 The Destination Count N gives the number of Destinations (N) contained in this PREQ.
50
51
The format of the Per Destination Flags field is shown in Figure s44.
52
53
54 B0 B1 B2 B7
55
56 DO RF Reserved
57
58 Bits: 1 1 6
59
60
61 Figure s44—PREQ Per-Destination Flags field format
62
63
64
65 Per Destination Flags are set as follows.

IEEE P802.11s/D1.05, June 2007
1 Bit 0: DO (Destination Only): If DO=0, an intermediate MP with active forwarding information to the corre-
2 sponding destination responds to the PREQ with a unicast PREP; if DO=1, only the destination can respond
3
with a unicast PREP. The default value is 1.
4
5
6 Bit 1: RF (Reply-and-Forward): The RF flag controls the forwarding of PREQ at intermediate MPs. When
7 DO=0 and the intermediate MP has active forwarding information to the corresponding destination, the
8 PREQ is not forwarded if RF=0 and forwarded if RF=1. The default value is 1. When DO=1, the RF flag has
9
10 no effect.
11
12 Bit 2-7: Reserved
13
14
15 The Destination Address is the MAC address of the destination MP.
16
17 The Destination Sequence Number is the latest sequence number received in the past by the originator for
18 any path towards the destination.
19
20
21 Detailed usage of the PREQ element is described in 11A.8.5.
22
23 The PREQ element may be transmitted to a peer MP via either unicast or broadcast. A “unicast PREQ” is a
24
PREQ element contained in a management frame that is unicast to a peer MP. A “broadcast PREQ” is a
25
26 PREQ element contained in a management frame that is broadcast to all peer MPs.
27
28 7.3.2.75 PREP information element
29
30
31 The PREP element is used to establish a forward path to a destination and to confirm that a destination is
32 reachable.
33
34 The format of the PREP element is shown in Figure s45.
35
36
37 Octets: 1 1 1 1 1 6 4 0 or 6 4
38
39 ID Length Flags Hopcount Time to Destina- Destina- Destina- Lifetime
40 Live tion tion tion Prox-
41 Address Seq.Num. ied
42 Address
43
44
45
4 6 4 1 6 4 6 4
46
47 Metric Origina- Origina- Depen- Depen- Depen- ... Depen- Depen-
48 tor tor Seq. dent MP dent MP dent MP dent MP dent MP
49 Address Num. Count N MAC DSN #1 MAC DSN #N
50 #1 Address Address
51 #1 #N
52
53
54 Figure s45—Path Reply element
55
56
57
The Element ID is set to the value given in Table 7.26 for this information element. The length is set to 32 to
58
59 255 octets.
60
61 The Flags field is set as follows. Bit 0-5: Reserved. Bit 6: Address Extension (AE) (1=proxied address
62 present, 0=otherwise). Bit 7: Reserved.
63
64
65 The Hop Count field is set to the number of hops from the path destination to the local MP.

IEEE P802.11s/D1.05, June 2007
1 The Time to Live field is set to the maximum number of hops allowed for this element.
2
3
The Destination MP Address is the MAC address [of the destination for which a path is supplied].
4
5
6 The Destination Sequence Number field is set to the DSN of the target of the PREQ.
7
8 The Destination Proxied Address field is set to proxied address on behalf of which the PREP is sent. This
9
10
field is present only if Bit 6 (AE) in Flags = 1.
11
12 The Lifetime field, if applicable, reflects the Lifetime of the PREQ this PREP responds to.
13
14 The Metric field indicates the cumulative metric from the path destination to the local MP.
15
16
17 The Originator Address field is set to the MAC address of the originator of the PREQ.
18
19 The Originator Sequence Number field is set to the sequence number of the originator of the PREQ.
20
21
22 The Dependent MP Count N field indicates the number of dependent MPs (N).
23
24 The Dependent MP MAC Address # indicates the MAC address of dependent MP.
25
26
The Dependent MP DSN # indicates the Destination Sequence Number associated with MAC address of
27
28 dependent MP.
29
30 The detailed usage of the PREP element is described in 11A.8.6.
31
32
33
7.3.2.76 PERR Information element
34
35 The Path Error (PERR) element is used for announcing a broken link to all traffic sources that have an active
36 path over this broken link.
37
38
39 The format of the PERR element is shown in Figure s46.
40
41 Octets: 1 1 1 1 6 4
42
43 ID Length Mode Flags Num of Des- Destination Destination MP
44 tinations Address Seq. Num
45
46
47 Figure s46—Path Error element
48
49
51 octets.
52
53 The Mode Flags field is reserved.
54
55 The Number of Destinations indicates the number of announced destinations in PERR (destination address
56
and destination MP sequence number).
57
58 The Destination Address indicates the detected unreachable destination MAC address.
59
60 The Destination Sequence Number indicates the sequence number of detected unreachable destination MP.
61
62 The detailed usage of the PERR element is described in 11A.8.7.
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.3.2.77 Proxy Update (PU) information element

2
3
4 The Proxy Update information element is transmitted by a source MP to a destination MP to update its proxy
5 information. This frame is transmitted using individual addresses. The frame format is shown in Figure s47.
6
7
8 Octets: 1 1 1 1 6 2 6 6
9
10 ID Length Flags Sequence Proxy Number Proxied ... Proxied
11 number Address of prox- MAC MAC
12 ied Address Address
13 addresses #1 #N
14 (N)
15
16 Figure s47—Proxy Update (PU) Element
17
18
19
20 The Element ID is set to the value given in Table s7.26 for this information element.
21
22
The length is set to 12 + N*6.
23
24
25 The Flags field is set as follows. Bit 0: (0 = add proxy information, 1 = delete proxy information). Bit 1 – 7:
26 Reserved.
27
28
29 The sequence number field is set to the sequence number of PU. The Source MP shall set the Sequence
30 Number field in the PU Element to a value from a single modulo-256 counter that is incrementing by 1 for
31 each new PU
32
33
34 The Proxy Address is set to the MAC address of proxy MP.
35
36 The Number of Proxied Address is set to the number of proxied addresses reported to the destination MP.
37
38
39 The Proxied MAC Address is the MAC address of the proxied entities.
40
41 7.3.2.78 Proxy Update Confirmation (PUC) information element
42
43
44 The Proxy Update Confirmation element is transmitted by an MP in response to a PU. This frame is trans-
45 mitted using individual addresses. The frame format is shown in Figure s48.
46
47
48 Octets: 1 1 1 1 6
49
50 ID Length Flags Sequence number Destination MP
51 Address
52
53
Figure s48—Proxy Update Confirmation (PUC) element
54
55
56
57 The Element ID is set to the value given in Table s7.26 for this information element.
58
59
60 The length is set to 10.
61
62 The Flags field is set as follows. Bit 0 – 7: Reserved
63
64
65 The sequence number field is the sequence number of received PU which is being confirmed.

IEEE P802.11s/D1.05, June 2007
1 The Destination MP Address is set to the MAC address of the recipient of the PU.
2
3
4 7.3.2.79 RA-OLSR Common Information elements
5
6 RA-OLSR elements are carried in RA-OLSR frames (defined in 7.4.11.5) and have the common informa-
7
8 tion element format shown in Figure s49.
9
10 Octets: 1 1 1 6 1 1 2 Variable
11
12 ID Length Vtime Originator TTL Hop Sequence Number Information
13 Address Count Element-
14 specific
15 fields
16
17
18 Figure s49—RA-OLSR common information element format
19
20
21 The Element ID is set to the value given in Table 7.26 for the information element.
22
23
24 The Vtime field indicates the validity time (in seconds) during which an MP considers the information con-
25 tained in the information element as valid after its reception, unless a more recent update to the information
26
is received. The validity time is represented by its mantissa (four highest bits of V time field) and by its expo-
27
28 nent (four lowest bits of V time field). In other words:
29
30 a
V time = C × ⎛ 1 + ------⎞ × 2
31 ⎝ 16⎠
32
33 where ‘a’ is the integer represented by the four highest bits of Vtime field.
34
35 The Originator Address is the MAC address of the MP that has originally generated this information
36 element. This may be different from the sender-address in case that multiple elements are encapsulated in
37
38 one frame.
39
40 The Time To Live (TTL) field indicates the maximum number of hops allowed for this information element.
41
42 The Hop Count field indicates the number of hops an information element has attained.
43
44 The Sequence Number field indicates a sequence number assigned by the originator MP, which ensures that
45 each element can be uniquely identified in the network.
46
47 The Information Element-Specific fields are fields specific to each element and are described in the
48 following subclauses.
49
50
51 7.3.2.79.1 HELLO element
52
53 The fields specific to the HELLO element are shown in Figure s50.
54
55
56 The Htime field indicates the HELLO emission interval (in seconds) used by the MP on this particular inter-
57 face. The HELLO emission interval is represented by its mantissa (four highest bits of Htime field) and by
58 its exponent (four lowest bits of Htime field). In other words:
59
60 b
a
61 H time = C × ⎛ 1 + ------⎞ × 2 ,
⎝ 16⎠
62
63
64 where ‘a’ is the integer represented by the four highest bits of Htime field and ‘b’ the integer represented by
65 the four lowest bits of Htime field.

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 1 1 1 1 6 4 … 6 4
3 Htime Willing- Block 1 Block 1 Block 1 Block 1 … Block 1 Block 1
4 ness Link Number of Neighbor Link Neighbor Link
5 Code Neighbor Interface Metric 1 Interface Metric X
6 Interface Address 1 Address X
7 Address
8
9
10
11 … 1 1 6 4 … 6 4
12
13 … Block N Block N Block N Block N … Block N Block N
14 Link Number of Neighbor Link Neighbor Link
15 Code Neighbor Interface Metric 1 Interface Metric Y
16 Interface Address 1 Address Y
17 Address
18
19
20 Figure s50—Fields specific to HELLO element
21
22
23 The Willingness field indicates the willingness of an MP to carry and forward traffic for other MPs (i.e., to
24 be selected as MPR). The value of willingness is 0-7: WILL_NEVER(0), WILL_DEFAULT(3),
25 WILL_ALWAYS(7). The values 8-255 are reserved.
26
27
28 The Link Code field indicates the link state. The value of the link code is defined as: NOT_NEIGH(0),
29 SYM_NEIGH(1) and MPR_NEIGH(2). The values 3-255 are reserved.
30
31
32 The Number of Neighbor Interface Addresses field indicates the number of neighbor interface addresses of
33 each Link Code.
34
35
36 The Neighbor Interface Address field indicates the MAC address of an interface of a neighbor MP.
37
38
39 The Link Metric field indicates the metric of the link.
40
41 7.3.2.79.2 Topology Control (TC) element
42
43
44 The fields specific to the Topology Control (TC) element are shown in Figure s51.
45
46
47 Octets: 2 6 4 … 6 4
48
Advertised Advertised Link Metric 1 … Advertised Link Metric N
49
Neighbor Neighbor Neighbor
50
Sequence Main Address Main Address
51
Number 1 N
52
(ANSN)
53
54
55 Figure s51—Fields specific to TC element
56
57
58
59 The ANSN field indicates a sequence number associated with the advertised neighbor set. Every time an MP
60 detects a change in its advertised neighbor set, it increments this sequence number (“Wrap-around” is han-
61 dled as described in 11A.9.17). This number is sent in this ANSN field of the TC element to keep track of
62
the most recent information. When an MP receives a TC element, it can decide on the basis of this advertised
63
64 ANSN, whether or not the received information about the advertised neighbors of the originator MP is more
65 recent than what it already has.

IEEE P802.11s/D1.05, June 2007
1 The Advertised Neighbor Main Address field indicates the main address of a neighbor MP.
2
3
4 The Link Metric field indicates the metric of the link.
5
6 7.3.2.79.3 Multiple Interface Declaration (MID) element
7
8
9 The fields specific to the Multiple Interface Declaration (MID) element are shown in Figure s52.
10
11
12 Octets: 6 … 6
13
14 RA-OLSR … RA-OLSR
15 Interface Interface
16 Address 1 Address N
17
18 Figure s52—Fields specific to MID element
19
20
21
22 The RA-OLSR Interface Address field indicates the address of an RA-OLSR interface of the MP, excluding
23 the MPs main address (which is already indicated in the Originator Address field).
24
25
26 7.3.2.79.4 Local Association Base Advertisement (LABA) element
27
28
29
The fields specific to the Local Association Base Advertisement (LABA) element are shown in Figure s53.
30
31 Octets: 6 1 1 6 1 … 6 1 …
32
33 MAP Block 1 Block 1 Block 1 Block 1 … Block 1 Block 1 …
34 Address Index Number STA STA STA STA
35 of STA Address 1 Sequence Address X Sequence
36 Number 1 Number X
37
38
39
40 1 1 6 1 … 6 1
41
Block N Block N Block N Block N … Block N Block N
42
Index Number STA STA STA STA
43
of STA Address 1 Sequence Address Y Sequence
44
Number 1 Number Y
45
46
47 Figure s53—Fields specific to RA-OLSR LABA element
48
49
50
51 The MAP Address field indicates the main address of the MAP of the association information element.
52
53
54
The Block Index field indicates the index of a block that stores a list of STA addresses. The value of Block
55 Index is 0-253.
56
57 The Block Number of STA field indicates the size of a block counted in octets and measured from the begin-
58
59 ning of the preceding “Block Index” field until the next “Block Index” field (or to the end of the information
60 element if there are no more blocks).
61
62
The STA Address field indicates the MAC address of the associated station. The station address does not
63
64 include the “Group MAC address bit” in the 48-bit MAC address as described for Local Association Base
65 (LAB) and Global Association Base (GAB) in 11A.9.5.

IEEE P802.11s/D1.05, June 2007
1 The STA Sequence Number field indicates the sequence number in the association management frame sent
2 by the STA.
3
4
5 7.3.2.79.5 Local Association Base Checksum Advertisement (LABCA) element
6
7 The fields specific to the Local Association Base Checksum Advertisement (LABCA) element are shown in
8 Figure s54.
9
10
11 Octets: 1 16 … 1 16
12
13 Block Block Check- … Block Block Check-
14 Index (1) sum Index (N) sum
15
16 Figure s54—Fields specific to LABCA element
17
18
19
20 The Block Index field indicates the index of a block that stores a list of STA addresses. The value of the
21 Block Index is 0-253.
22
23
24 The Block Checksum field indicates the checksum of a block. This field length is calculated using the
25 CRC32 method.
26
27
7.3.2.79.6 Association Base Block Request (ABBR) element
28
29
30 The fields specific to the Association Base Block Request (ABBR) element are shown in Figure s55.
31
32
33 Octets: 1 6 6 … 1
34
Flag MAP Block … Block
35
Address Index 1 Index N
36
37
38 Figure s55—Fields specific to RABBR element
39
40
41
42 The Flag field is set as follows: Bit 0: Mismatch Detection (0=false, 1=true) and Bit 1-7: Reserved.
43
44 The MAP Address field indicates the main address of the MAP of the required association information ele-
45 ment.
46
47
48 The Block Index field indicates the index of a block that has been detected to be inconsistent and is
49 requested for readvertisement by the MP generating this information element, except when the Block Index
50 is 254, whereby an originator MP generates an element when the entire local association information of an
51 MAP is needed, or the Block Index is 255, whereby an originator MP generates an element when the global
52
53 association information is needed.
54
55 7.3.2.80 Mesh security capability information element [MSCIE]
56
57
58 The Mesh security capability information element contains the MKD domain identifier. A mesh authentica-
59 tor uses the Mesh security capability information element to advertise its status as an MA, and to advertise
60 that it is included in the group of MAs that constitute an MKD domain. The format for this information ele-
61 ment is given in Figure s56.
62
63
64 The Element ID is set to the value given in Table 7.26 for this information element. The Length field is set to
65 7.

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 1 1 6 1
3 Element ID Length MKD domain ID Mesh Security Con-
4 figuration
5
6
7 Figure s56—Mesh security capability information element
8
9
10 The MKD domain Identifier is a 6-octet value, following the ordering conventions from 7.1.1.
11
12
13 The Mesh Security Configuration field is one octet and is defined in Figure s57.
14
15
16 B0 B1 B2 B3 B7
17
18 Mesh Authenti- Connected to Default Role Reserved
19 cator MKD Negotiation
20
21 Bits: 1 1 1 5
22
23 Figure s57—Mesh Security Configuration field
24
25
26
27 The Mesh Authenticator bit is set to one to indicate that an MP is configured as a mesh authenticator in the
28
MKD domain identified in this information element, and that the MP may act in the IEEE 802.1X Authenti-
29
30 cator role during an MSA handshake.
31
32
33 The Connected to MKD bit is set to one to indicate that the MP has a valid path to the MKD and a current
34 security association with the MKD. The Connected to MKD bit is not set to one if the Mesh Authenticator
35 bit is set to zero.
36
37
38 The interpretation of the Mesh Authenticator and Connected to MKD bits is described in Table s5.
39
40
41
42 Table s5—Meaning of Mesh Security Configuration bits
43
44
Mesh Connected to
45 Meaning
Authenticator MKD
46
47
0 0 The device is not configured to act as a mesh authenticator.
48
49 0 1 Invalid
50
51 1 0 The device is configured to act as a mesh authenticator but
52 does not have a connection to the MKD. In this case the
53 device may successfully act as an IEEE 802.1X authenticator,
54 for example, if it possesses a cached key for the supplicant
55 MP.
56
57 1 1 The device is configured to act as a mesh authenticator and
58 has a connection to the MKD.
59
60
61
62 The Default Role Negotiation bit is set to one by an MP if it is using the default method to select IEEE
63
64 802.1X Authenticator and Supplicant roles, and is set to 0 otherwise. When set to 0, the Authenticator/Sup-
65 plicant selection method to use is specified by a mechanism outside the scope of this standard.

IEEE P802.11s/D1.05, June 2007
1 7.3.2.81 MSA information element [MSAIE]

2
3
4 The MSA information element includes information needed to perform the authentication sequence during
5 an MSA handshake. This information element is shown in Figure s58.
6
7
8 Octets: 1 1 1 6 4 4 variable
9 Element ID Length Handshake MA-ID Selected Selected Pair- Optional
10 Control AKM Suite wise Cipher Parameters
11 Suite
12
13
14 Figure s58—MSA information element [MSAIE]
15
16
17
18 The Element ID is set to the value given in Table 7.26 for this information element. The Length field for
19 this information element indicates the number of octets in the information field (fields following the Ele-
20 ment ID and Length fields).
21
22
23 The Handshake Control field contains two subfields as shown in Figure s59.
24
25 B0 B1 B7
26
27 Request Authentication Reserved
28
29 Bits: 1 7
30
31 Figure s59—Handshake Control field
32
33
34
35 The “Request Authentication” subfield is set to 1 to indicate an MP requests authentication during the Initial
36 MSA Authentication procedure.
37
38
39 The MA-ID field contains the MAC address of the MA, which is used by the supplicant MP for deriving the
40 PMK-MA. It is encoded following the conventions from 7.1.1.
41
42
43 The Selected AKM Suite field contains an AKM suite selector, as defined in 7.3.2.25.2, indicating the
44 authentication type and key management type to be used to secure the link.
45
46
47
The Selected Pairwise Cipher Suite field contains a pairwise cipher suite selector, as defined in 7.3.2.25.1,
48 indicating a cipher suite to be used to secure the link.
49
50 The format of the optional parameters is shown in Figure s60.
51
52
53 Octets: 1 1 variable
54
55 Sub-element ID Length Data
56
57 Figure s60—Optional parameters field
58
59
60
61 The Sub-element ID is one of the values from Table s6.
62
63
64 MKD-ID contains the MAC address of the MP implementing the MKD function that the supplicant MP may
65 contact to initiate the mesh key holder security handshake.

IEEE P802.11s/D1.05, June 2007
1 Table s6—Sub-element IDs

2
3
4 Value Contents of data field Length
5
6 0 Reserved
7
8 1 MKD-ID 6
9
10 2 EAP Transport List variable
11 3 PMK-MKDName 16
12
13 4 MKD-NAS-ID variable
14
15 5-255 Reserved
16
17
18
19 EAP Transport List contains a series of transport type selectors that indicate the EAP transport mechanism.
20 A transport type selector has the format shown in Figure s61.
21
22
23 Octets: 3 1
24 OUI Transport
25 Type
26
27
28 Figure s61—Transport type selector format
29
30
31
The order of the organizationally unique identifier (OUI) field follows the ordering convention for MAC
32
33 addresses from 7.1.1. The transport types defined by this standard are provided in Table s7.
34
35
36 Table s7—Transport types
37
38
39 OUI Transport Type Meaning
40
41 00-0F-AC 0 None specified
42
43 00-0F-AC 1 EAP Transport mechanism as defined in 11A.4.5
44
45 00-0F-AC 2-255 Reserved
46 Vendor OUI Any Vendor specific
47
48 Other Any Reserved
49
50
51
52 The transport type 00-0F-AC:1 is the default transport type selector value.
53
54
PMK-MKDName contains an identifier of a PMK-MKD as defined in 8.8.4.
55
56
57 MKD-NAS-ID contains the identity of the MKD that facilitates authentication, and that will be bound into
58 the first-level keys PMK-MKD and MKDK.
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 7.4 Action frame format details

2
3
4 EDITORIAL NOTE—11ma ends with 7.4.5, 11k adds 7.4.6, 11r adds 7.4.7, 11n adds 7.4.8.
5
6
7
Insert the following new clauses after 7.4.8:
8
9 7.4.9 Mesh Peer Link Management action frame details
10
11
12 Action frame formats for Mesh Peer Link Management are defined in this subclause.
13
14
15 An Action field, in the octet field immediately after the Category field, differentiates the frame format. The
16 Action field values associated with each frame format are defined in Table s8.
17
18
19
20
Table s8—Mesh Peer Link Management Action field values
21
22 Action field
23 Description
value
24
25 0 Peer Link Open
26
27 1 Peer Link Confirm
28
29 2 Peer Link Close
30
31 3-255 Reserved
32
33
34
35
36 7.4.9.1 Peer Link Open frame format
37
38
The Peer Link Open frame is used to open a peer link using the procedures defined in 11A.2. The frame
39
40 body of a Peer Link Open frame contains the information shown in Table s9.
41
42
43 Table s9—Peer Link Open frame body
44
45
47
48 1 Category
49
50 2 Action Value
51
52 3 Capability
53 4 Supported rates
54
55 5 Extended Supported Rates The Extended Supported Rates element is present whenever there are
56 more than eight supported rates, and it is optional otherwise.
57
58 6 Power Capability The Power Capability element shall be present if
59 dot11SpectrumManagementRequired is true.
60
61 7 Supported Channels The Supported Channels element shall be present if
62 dot11SpectrumManagementRequired is true.
63
64 8 RSN The RSN information element is only present within Peer Link Open
65 frames generated by MPs that have dot11RSNAEnabled set to TRUE.

IEEE P802.11s/D1.05, June 2007
1 Table s9—Peer Link Open frame body

2
3
4 9 QoS Capability The QoS Capability element is present when dot11QoS-OptionImple-
5 mented is true.
6
7 10 Mesh ID The Mesh ID information element is present when dot11MeshEnabled
8 is true.
9 11 Mesh Configuration The Mesh Configuration information element is present when
10 dot11MeshEnabled is true.
11
12 12 Peer Link Management The Peer Link Management information element is present only when
13 dot11MeshEnabled is true. The subtype of the Peer Link Management
14 Element is set to 1.
15
16 13 MSCIE The MSCIE element is present when dot11MeshEnabled is true.
17
18 14 MSAIE The MSAIE element is present when dot11MeshEnabled is true.
19
20 Last Vendor Specific One or more vendor-specific information elements may appear in this
21 frame. This information element follows all other information ele-
22 ments.
23
24
25 The Category field is set to the value in Table 7.24 for category Mesh Peer Link Management.
26
27
28 The Action field is set to the value in Table s8 for this action frame type.
29
30
7.4.9.2 Peer Link Confirm frame format
31
32
33 The Peer Link Confirm frame is used to confirm a peer link using the procedures defined in 11A.2. The
34 frame body of a Peer Link Open frame contains the information shown in Table s10.
35
36
37
38 Table s10—Peer Link Confirm frame body
39
40
42
43 1 Category
44 2 Action Value
45
46 3 Capability
47
48 4 Status code
49
50 5 AID
51
52 6 Supported rates
53 7 Extended Supported Rates The Extended Supported Rates element is present whenever there are
54 more than eight supported rates, and it is optional otherwise.
55
56 8 RSN The RSN information element is only present when
57 dot11RSNAEnabled is set to TRUE.
58
59 9 EDCA Parameter Set
60
61 10 Mesh ID The Mesh ID information element is present when dot11MeshEnabled
62 is true.
63
64 11 Mesh Configuration The Mesh Configuration information element is present when
65 dot11MeshEnabled is true.

IEEE P802.11s/D1.05, June 2007
1 Table s10—Peer Link Confirm frame body

2
3
7
8 13 MSCIE The MSCIE element is present when dot11MeshEnabled is true.
9 14 MSAIE The MSAIE element is present when dot11MeshEnabled is true.
10
13 ments.
14
15
16
18
20
21
22 7.4.9.3 Peer Link Close frame format
23
24 The Peer Link Close frame is used to close a peer link using the procedures defined in 11A.2. The frame
25 body of a Peer Link Open frame contains the information shown in Table s11.
26
27
28
29 Table s11—Peer Link Close frame body
30
31
33
34 1 Category
35 1 Action Value
36
37 1 Reason code
38
42
45 ments.
46
47
48
50
52
53
7.4.10 Mesh Link Metric action frame details
54
55
56 Action frame formats for management of Mesh Link Metrics are defined in this subclause.
57
59
Action field values associated with each frame format are defined in Table s12.
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 Table s12—Mesh Link Metric Action field values

2
3
4 Action field
Description
5 value
6
7 0 Link Metric Request
8
9 1 Link Metric Report
10
11 2-255 Reserved
12
13
14
15 7.4.10.1 Link Metric Request frame format
16
17
18 The Link Metric Request frame is transmitted by an MP to a peer MP in a mesh to request metric informa-
19 tion. This frame is transmitted in an individually addressed manner. The frame body of a Link Metric
20 Request frame contains the information shown in Table s13.
21
22
23 Table s13—Link Metric Request frame body
24
25
26 Order Information
27
28 1 Category
29
30 2 Action Value
31
32
33
34 The Category field is set to the value in Table 7.24 for category Mesh Link Metric.
35
36
38
39
40 7.4.10.2 Link Metric Report frame format
41
42
43 The Link Metric Report frame is transmitted by an MP to a peer MP in a mesh to advertise metric informa-
44 tion. This frame is transmitted in an individually addressed manner. The frame body of a Link Metric Report
45 frame contains the information shown in Table s14.
46
47
48 Table s14—Link Metric Report frame body
49
50
52
53 1 Category
54
55 2 Action Value
56
57 3 Local Link State
58 Announcement Element
59
60
61
62 The Category field is set to the value in Table 7.24 for category Mesh Link Metric.
63
64

IEEE P802.11s/D1.05, June 2007
1 7.4.11 Mesh Path Selection action frame details

2
3
4 Action frame formats for management of Mesh Path Selection are defined in this subclause.
5
8
9
10
11 Table s15—Mesh Path Selection Action field values
12
13
14 Action field
Description
15 value
16
17 0 Path Request
18
1 Path Reply
19
20 2 Path Error
21
22 3 Root Announcement
23
24 4 RA-OLSR
25
26 5-255 Reserved
27
28
29
30 7.4.11.1 Path Request frame format
31
32
33 The Path Request frame is transmitted by a source MP to discover the path to the destination MP using the
34 HWMP protocol defined in 11A.8. This frame may be transmitted using group addresses or individual
35 addresses. The frame body of a Path Request frame contains the information shown in Table s16.
36
37
38
39 Table s16—Path Request frame body
40
41
Order Information
42
43
1 Category
44
45 2 Action Value
46
47 3 Path Request element
48
49
50
51 The Category field is set to the value in Table 7.24 for category Mesh Path Selection.
52
53
55
56 The Path Request element is set as described in 7.3.2.74.
57
58
59 7.4.11.2 Path Reply frame format
60
61 The Path Reply frame is transmitted by a destination MP to a source MP in the mesh to determine the path
62
between the source and destination MP using the HWMP protocol defined in 11A.8. This frame may be
63
64 transmitted using group addresses or individual addresses. The frame body of a Path Reply frame contains
65 the information shown in Table s17.

IEEE P802.11s/D1.05, June 2007
1 Table s17—Path Reply frame body

2
3
4 Order Information
5
6 1 Category
7
8 2 Action Value
9
10 3 Path Reply element
11
12
14
15
17
18 The Path Reply element is set as described in 7.3.2.75.
19
20
21 7.4.11.3 Path Error frame format
22
23
The Path Error frame is transmitted by an MP that detected a link error on a mesh path to the precursor
24
25 MP(s) using the HWMP protocol defined in 11A.8. This frame may be transmitted using group addresses or
26 individual addresses. The frame body of a Path Error frame contains the information shown in Table s18.
27
28
29 Table s18—Path Error frame body
30
31
33
34 1 Category
35
36 2 Action Value
37
38 3 Path Error element
39
40
41
43
45
46
47 The Path Error element is set as described in 7.3.2.76.
48
49
50
7.4.11.4 Root Announcement frame format
51
52 The Root Announcement frame is transmitted by a Root MP using the HWMP protocol defined in 11A.8.
53 This frame may be transmitted using group addresses or individual addresses. The frame body of a Root
54
Announcement frame contains the information shown in Table s19.
55
56
57
58 Table s19—Root Announcement frame body
59
60
62
63 1 Category
64
65 2 Action Value

IEEE P802.11s/D1.05, June 2007
1 Table s19—Root Announcement frame body

2
3
4 3 Root Announcement ele-
5 ment
6
7
8
The Category field is set to the value in Table 7.24 for category Mesh Path Selection.
9
10
12
13
14 The Root Announcement element is set as described in 7.3.2.73.
15
16
17 7.4.11.5 RA-OLSR frame format
18
19 The RA-OLSR frame is transmitted by MPs using the RA-OLSR path selection protocol defined in 11A.9.
20
21 This frame may be transmitted using group addresses or individual addresses. The frame body of a RA-
22 OLSR frame contains the information shown in Table s20.
23
24
25 Table s20—RA-OLSR frame body
26
27
29
30 1 Category
31
32 2 Action Value
33
34 3 RA-OLSR element
35
36
37
39
40
42
43
The RA-OLSR element is set as described in 7.3.2.79.
44
45
46 7.4.12 Mesh Interworking action frame details
47
48
49 Action frame formats for management of Mesh Interworking are defined in this subclause.
50
51
54
55
56 Table s21—Mesh Interworking Action field values
57
58
59 Action field
60 Description
value
61
62 0 Portal Announcement
63
64 1-255 Reserved
65

IEEE P802.11s/D1.05, June 2007
1 7.4.12.1 Portal Announcement frame format

2
3
4 The Portal Announcement is transmitted by an MPP to announce its presence in the mesh network. This
5 frame is transmitted using group addresses. The frame body of a Portal Announcement frame contains the
6
7 information shown in Table s16.
8
9
10 Table s22—Portal Announcement frame body
11
12
14
15 1 Category
16
17 2 Action Value
18
3 Portal Announcement ele-
19
ment
20
21
22
23
24 The Category field is set to the value in Table 7.24 for category Mesh Interworking.
25
26
28
29
30 The Portal Announcement element is set as described in 7.3.2.72.
31
32
33 7.4.13 Mesh Resource Coordination action frame details
34
35
36 Action frame formats for management of Mesh Resource Coordination are defined in this subclause.
37
38
41
42
43
44 Table s23—Mesh Resource Coordination Action field values
45
46
47 Action field
Description
48 value
49
50 0 Congestion Control Request
51 1 Congestion Control Response
52
53 2 Neighborhood Congestion Announcement
54
55 3 Mesh Deterministic Access
56
57 4 Beacon Timing Request
58
59 5 Beacon Timing Response
60 6 Mesh Channel Switch Announcement
61
62 7 Connectivity Report
63
64 8-255 Reserved
65

IEEE P802.11s/D1.05, June 2007
1 7.4.13.1 Congestion Control Request frame format

2
3
The Congestion Control Request frame is transmitted by an MP to it upstream peer MP to indicate the target
4
5 data rate it desires, or the peak data rate it wants a peer not to exceed so as to avoid or control congestion.
6 This frame is transmitted using individual addresses. The frame body of a Congestion Control Request
8
9
10
Table s24—Congestion Control Request frame body
11
12
14
15 1 Category
16
17 2 Action Value
18
19 3 Target Transmission Rate
20 element
21
22
23
24 The Category field is set to the value in Table 7.24 for category Mesh Resource Coordination.
25
27
28
29 The Target Transmission Rate element is set as described in 7.3.2.58.
30
31 7.4.13.2 Congestion Control Response frame format
32
33
34 The Congestion Control Response frame is transmitted by an MP as a response to a Congestion Control
35 Request from its downstream peer MP. This frame is transmitted using individual addresses. The frame
36 body of a Congestion Control Request frame contains the information shown in Table s25.
37
38
39 Table s25—Congestion Control Response frame body
40
41
43
44 1 Category
45
46 2 Action Value
47
48 3 Offered Traffic Load ele-
49 ment
50
51
52
54
56
57
58 The Offered Traffic Load element is set as described in 7.3.2.59.
59
60 7.4.13.3 Neighborhood Congestion Announcement frame format
61
62
The Neighborhood Congestion Announcement frame is transmitted by an MP that is congested due to the
63
64 high channel load in the neighborhood. This frame is transmitted using group addresses. The frame body of
65 a Neighborhood Congestion Announcement frame contains the information shown in Table s26.

IEEE P802.11s/D1.05, June 2007
1 Table s26—Neighborhood Congestion Announcement frame body

2
3
4 Order Information
5
6 1 Category
7
8 2 Action Value
9
10 3 Neighborhood Congestion
11 element
12
13
15
16
18
19 The Neighborhood Congestion element is set as described in 7.3.2.60.
20
21
22 7.4.13.4 Mesh Deterministic Access frame format
23
24 The Mesh Deterministic Access frame is transmitted by an MDA-active MP to one or more peer MDA-
25
26 active MPs. This frame may be transmitted using group addresses or individual addresses. The frame body
27 of a Mesh Deterministic Access frame contains the information shown in Table s27.
28
29
30 Table s27—Mesh Deterministic Access frame body
31
32
34
35 1 Category
36
37 2 Action Value
38
39 3 One or more MDA-related
40 elements
41
42
43
45
47
48
49 The MDA related elements are set as described in 7.3.2.66 through 7.3.2.70.
50
51 7.4.13.5 Beacon Timing Request frame format
52
53
54 The Beacon Timing Request frame is used to request beacon timing information from peer MPs. This frame
55 is transmitted using group addresses or individual addresses. The frame body of a Beacon Timing Request
57
58
59
60 Table s28—Beacon Timing Request frame body
61
62
64
65 1 Category

IEEE P802.11s/D1.05, June 2007
1 Table s28—Beacon Timing Request frame body

2
3
4 2 Action Value
5
6
7
The Category field is set to the value in Table 7.24 for category Mesh Resource Coordination.
8
9
11
12 7.4.13.6 Beacon Timing Response frame format
13
14
15 The Beacon Timing Response frame is used to respond to a Beacon Timing Request frame with neighbor
16 MP beacon timing information. This frame is transmitted using individual addresses. The frame body of a
17 Beacon Timing Response frame contains the information shown in Table s29.
18
19
20
21
Table s29—Beacon Timing Response frame body
22
23
Order Information
24
25
1 Category
26
27 2 Action Value
28
29 3 Most Recent TBTT
30
31 4 Beacon Timing element
32
33
34
36
38
39
40 The Most Recent TBTT information is an 8-octet field that reflects the most recent TBTT of the transmitting
41 MP, measured in units of microseconds, so that the beacon timing information element reflects information
42 as if it was transmitted in a beacon at that TBTT.
43
44 The Beacon Timing element is set as described in 7.3.2.65.
45
46
47 7.4.13.7 Mesh Channel Switch Announcement frame format
48
49 The Mesh Channel Switch Announcement frame is transmitted by an MP to signal a channel switch as
50
described in 11A.3.3. This frame may be transmitted using group addresses or individual addresses. The
51
52 frame body of a Mesh Channel Switch Announcement frame contains the information shown in Table s30.
53
54
55 Table s30—Mesh Channel Switch Announcement frame body
56
57
59
60 1 Category
61
62 2 Action Value
63
64 3 Mesh Channel Switch
65 Announcement element

IEEE P802.11s/D1.05, June 2007
2
3
5
6
7 The Mesh Channel Switch Announcement element is set as described in 7.3.2.62.
8
9
10 7.4.13.8 Connectivity Report frame format
11
12
13 The Connectivity Report frame is transmitted by an MP to advertise the number of beacon broadcasters dur-
14 ing the reporting interval and the peers that transmitted a connectivity report and the Power Management
15 Mode of each peer. This frame is transmitted using group addresses. The frame body of a Connectivity
16 Report frame contains the information shown in Table s31.
17
18
19
20 Table s31—Connectivity Report frame body
21
22
24
25 1 Category
26 2 Action Value
27
28 3 Connectivity Report ele-
29 ment
30
31
32
33
35
36
37
The Action field is set to the value in Table s23 for this action frame type.
38
39 The Connectivity Report element is set as described in 7.3.2.71.
40
41
42
43
44
45 Insert the following after 7.4:
46
47
48 EDITORIAL NOTE—TGn defined 7.4a -- first unused is 7.4b.
49
50
51 7.4b Mesh Action (4-addr action frames)
52
53
54 This subclause describes the Mesh Action frame formats, including the Mesh Action Details field, allowed
55
in each of the mesh action categories defined in Table s2 in 7.3.1.34. Usage of Mesh Action frames is
56
57 described in 11A.4.
58
59
60 7.4b.1 MSA mesh action details
61
62
Seven Mesh Action frame formats are defined for MSA. An Action Value field, in the octet field immedi-
63
64 ately after the Category field, differentiates the five formats. The Action Value field values associated with
65 each frame format are defined in Table s32.

IEEE P802.11s/D1.05, June 2007
1 Table s32—MSA Action field values

2
3
4 Action Field
Description
5 Value
6
7 0 Mesh key holder security establish-
8 ment
9
10 1 PMK-MA delivery push
11
12 2 PMK-MA confirm
13 3 PMK-MA request
14
15 4 PMK-MA delivery pull
16
17 5 PMK-MA delete
18
19 6 Mesh EAP encapsulation
20
21 7-255 Reserved
22
23
24 7.4b.1.1 Mesh key holder security establishment frame format
25
26
27 The Mesh key holder security establishment frame uses the Mesh Action frame body format and is transmit-
28 ted by a mesh key holder to perform the mesh key holder security handshake. The format of the mesh key
29 holder security establishment frame body is shown in Table s33.
30
31
32
Table s33—Mesh key holder security establishment frame body format
33
34
36
37 1 Category
38
39 2 Action Value
40
41 3 Mesh ID (see 7.3.2.55)
42
43 4 MSCIE (see 7.3.2.80)
44
45 5 Key Holder Security
46 6 Message integrity check (optional, see 7.3.1.35)
47
48
49
50 The Category field is one octet and is set to 0 (representing MSA).
51
52
53 The Action Value field is one octet and is set to 0 (representing a Mesh key holder security establishment
54 frame).
55
56 The Mesh ID information element is described in 7.3.2.55.
57
58
59 The MSCIE is described in 7.3.2.80.
60
61 The Key Holder Security field is 81 octets in length and is defined in Figure s62.
62
63
64 The Handshake Sequence subfield contains a sequence number, represented as an unsigned binary number,
65 used to differentiate messages in a handshake.

IEEE P802.11s/D1.05, June 2007
1
2 Octets: 1 32 32 6 6 4
3
4 Handshake MA- MKD- MA-ID MKD- Trans-
5 Sequence Nonc Nonce ID port Type
6 e Selector
7
8 Figure s62—Key holder security field
9
10
11
12 The MA-Nonce field contains a pseudo-random value chosen by the MA. It is encoded following the con-
13 ventions from 7.1.1.
14
15 The MKD-Nonce field contains a pseudo-random value chosen by the MKD. It is encoded following the
16
17 conventions from 7.1.1.
18
19 The MA-ID field contains the MAC address of the MA. It is encoded following the conventions from 7.1.1.
20
21
22 The MKD-ID field contains the MAC address of the MKD. It is encoded following the conventions from
23 7.1.1.
24
25 The Transport Type Selector field contains a single transport type selector that indicates the supported trans-
26
27 port types. The transport type selector format is given in Figure s61. The transport types defined by this stan-
28 dard are provided in Table s7.
29
30 The optional Message integrity check field is described in 7.3.1.35. The inclusion of the Message integrity
31
32 check field is dependent upon the value of the Handshake Sequence subfield of the Key Holder Security
33 field. The Message integrity check field is omitted when Handshake Sequence is 1; otherwise, it is present.
34
35 7.4b.1.2 PMK-MA delivery push frame format
36
37
38 The PMK-MA delivery push frame uses the Mesh Action frame body format and is transmitted by an MKD
39 in the mesh key transport push protocol. The format of the PMK-MA delivery push frame body is shown in
40 Table s34.
41
42
43
44 Table s34—PMK-MA delivery push frame body format
45
46
48
49 1 Category
50 2 Action Value
51
52 3 Mesh Key Transport Control (see 7.3.1.36)
53
54 4 Mesh Wrapped Key (see 7.3.1.37)
55
56 5 Message integrity check (see 7.3.1.35)
57
58
59
61
62 The Action Value field is one octet and is set to 1 (representing a PMK-MA delivery push frame).
63
64
65 The Mesh Key Transport Control field is described in 7.3.1.36.

IEEE P802.11s/D1.05, June 2007
1 The Mesh Wrapped Key field is described in 7.3.1.37.

2
3
4 The Message integrity check field is described in 7.3.1.35.
5
6 7.4b.1.3 PMK-MA confirm frame format
7
8
9
The PMK-MA confirm frame uses the Mesh Action frame body format and is transmitted by an MA in the
10 mesh key transport push or the mesh key delete protocol. The format of the PMK-MA confirm frame body
11 is shown in Table s35.
12
13
14 Table s35—PMK-MA confirm frame body format
15
16
18
19 1 Category
20
21 2 Action Value
22
24
26
27
28
30
31 The Action Value field is one octet and is set to 2 (representing a PMK-MA confirm frame).
32
33
35
37
38
39
7.4b.1.4 PMK-MA request frame format
40
41 The PMK-MA request frame uses the Mesh Action frame body format and is transmitted by an MA in the
42 mesh key transport pull protocol. The format of the PMK-MA request frame body is shown in Table s36.
43
44
45
46 Table s36—PMK-MA request frame body format
47
48
50
51 1 Category
52 2 Action Value
53
55
57
58
59
61
62 The Action Value field is one octet and is set to 3 (representing a PMK-MA request frame).
63
64

IEEE P802.11s/D1.05, June 2007

2
3
4 7.4b.1.5 PMK-MA delivery pull frame format
5
6 The PMK-MA delivery pull frame uses the Mesh Action frame body format and is transmitted by an MKD
7 in the mesh key transport pull protocol. The format of the PMK-MA delivery pull frame body is shown in
8
9 Table s37.
10
11
12 Table s37—PMK-MA delivery pull frame body format
13
14
16
17 1 Category
18
19 2 Action Value
20
3 Mesh Key Transport Control (see 7.3.1.36)
21
22 4 Mesh Wrapped Key (see 7.3.1.37)
23
25
26
27
29
30
31 The Action Value field is one octet and is set to 4 (representing a PMK-MA delivery pull frame).
32
34
35
36 The Mesh Wrapped Key field is described in 7.3.1.37.
37
39
40
41 7.4b.1.6 PMK-MA delete frame format
42
43 The PMK-MA delete frame uses the Mesh Action frame body format and is transmitted by an MKD in the
44
45 mesh key delete protocol. The format of the PMK-MA delete frame body is shown in Table s38.
46
47
48 Table s38—PMK-MA delete frame body format
49
50
52
53 1 Category
54
55 2 Action Value
56
3 Mesh Key Transport Control (see 7.3.1.36)
57
59
60
61
63
64
65 The Action Value field is one octet and is set to 5 (representing a PMK-MA delete frame).

IEEE P802.11s/D1.05, June 2007

2
3
5
6 7.4b.1.7 Mesh EAP encapsulation frame format
7
8
9 The Mesh EAP encapsulation frame uses the Mesh Action frame body format and is transmitted by a mesh
10 key holder in the mesh EAP message transport protocol. The frame body of the Mesh EAP encapsulation
12
13
14
15 Table s39—Mesh EAP encapsulation frame body
16
18
19 1 Category
20
21 2 Action Value
22
23 3 EAP Authentication
24
25 Message integrity check (see
4
26 7.3.1.35)
27
28
29
31
32
33 The Action Value field is one octet and is set to 6 (representing a Mesh EAP encapsulation frame).
34
35 The EAP Authentication field is 25 octets or greater in length and is defined in Figure s63.
36
37
38 Octets: 1 16 6 2 variable
39
40 Encapsulation Message SPA EAP Message EAP
41 Type Token Length Message
42
43
44 Figure s63—EAP Authentication field
45
46
47 The Encapsulation Type subfield identifies the type of EAP Encapsulation message, and is set to a value
48
49 described in Table s40.
50
51 The Message Token field contains a random nonce in messages of type request. In messages of type
52 response, response-accept, and response-reject, the Message Token field contains the value of the Message
53
54
Token field in the request message to which the response message corresponds.
55
56 The SPA subfield contains the MAC address of the supplicant MP that is performing EAP authentication.
57
58
59 The EAP Message Length subfield is two octets and contains an unsigned binary integer indicating the
60 length in octets of the EAP message subfield. The EAP Message Length subfield contains the value zero if
61 the EAP Message field is omitted.
62
63
64 The EAP Message subfield, when present, contains an EAP packet, with format as defined in IETF RFC
65 3748.

IEEE P802.11s/D1.05, June 2007
1 Table s40—Encapsulation Type values

2
3
4 Value Message Type
5
6 0 Reserved
7
8 1 Request
9
10 2 Response – Accept
11 3 Response – Reject
12
13 4-10 Reserved
14
15 11 Response
16
17 12-255 Reserved
18
19
20
The Message integrity check field is described in 7.3.1.35.
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 8. Security
2
3
4 8.2 Pre-RSNA security methods
5
6
7 Insert the following text at the end of the first paragraph of 8.2:
8
9 Open System Authentication and De-authentication shall not be used between MPs.
10
11
12 8.4.1.1 Security association definitions
13
14 Insert the following items in the bulleted list in 8.4.1.1 after the first item (after PMKSA):
15
16 — PMK-MKD SA: A result of a successful Initial MSA authentication.
17
18 — PMK-MA SA: A result of a successful Initial MSA authentication or Subsequent MSA authentica-
19 tion.
20
21
22
23 Insert the following two new subclauses after 8.4.1.1:
24
25 8.4.1.1.1A PMK-MKD SA
26
27
28 The PMK-MKD SA is the result of successful authentication during the Initial MSA authentication mecha-
29 nism. The security association consists of the following elements:
30
31
— MKDD-ID
32 — PMK-MKD
33
34 — PMK-MKDName
35 — SPA, and
36
37 — authorization information including PMK-MKD lifetime.
38
39 8.4.1.1.1B PMK-MA SA
40
41
42 The PMK-MKD SA is the result of a successful Initial MSA authentication, or the successful completion of
43 the Subsequent MSA authentication mechanism. The security association consists of the following ele-
44 ments:
45
46 — PMK-MA,
47 — PMK-MA lifetime,
48
49 — PMK-MAName,
50 — MA-ID,
51
52 — PMK-MKDName,
53 — SPA, and
54
55 — authorization information.
56
57
58 8.5 Keys and key distribution
59
60
61 8.5.2 EAPOL-Key frames
62
63 Change List Item 1 of “Key Information” (list entry b) in 8.5.2 as shown:
64
65 1) Key Descriptor Version (bits 0-2) specifies the key descriptor version type.

IEEE P802.11s/D1.05, June 2007
1 i) The value 1 shall be used for all EAPOL-Key frames to and from a STA when neither the
2 group nor pairwise ciphers are CCMP for Key Descriptor 1. This value indicates the fol-
3
lowing:
4
5
6 —HMAC-MD5 is the EAPOL-Key MIC.
7
8
9 —ARC4 is the EAPOL-Key encryption algorithm used to protect the Key Data field.
10 ii) The value 2 shall be used for all EAPOL-Key frames to and from a STA when either the
11 pairwise or the group cipher is AES-CCMP for Key Descriptor 2. This value indicates the
12
13
following:
14
15 —HMAC-SHA1-128 is the EAPOL-Key MIC. HMAC is defined in IETF RFC 2104; and
16
SHA1, by FIPS PUB 180-1-1995. The output of the HMAC-SHA1 shall be truncated to
17
18 its 128 MSBs (octets 0-15 of the digest output by HMAC-SHA1), i.e., the last four octets
19 generated shall be discarded.
20
21
22 —The NIST AES key wrap is the EAPOL-Key encryption algorithm used to protect the
23 Key Data field. IETF RFC 3394 defines the NIST AES key wrap algorithm.
24 iii) The value 3 shall be used for all EAPOL-Key frames between MPs when
25
26 dot11RSNAAuthenticationSuiteSelected is 5 or 6. This value indicates the following:
27
28 —AES-128-CMAC is the EAPOL-Key MIC. AES-128-CMAC is defined by FIPS
29
30 SP800-38B. The output of the AES-128-CMAC shall be 128 bits.
31
32 —The NIST AES key wrap is the EAPOL-Key encryption algorithm used to protect the
33 Key Data field. IETF RFC 3394 defines the NIST AES key wrap algorithm.
34
35
36 Change list entry h, “Key MIC” in 8.5.2 as shown:
37
38 h) Key MIC. This field is 16 octets in length when the Key Descriptor Version subfield is 1, 2 or 23.
39 The EAPOL-Key MIC is a MIC of the EAPOL-Key frames, from and including the EAPOL proto-
40 col version field to and including the Key Data field, calculated with the Key MIC field set to 0. If
41 the Encrypted Key Data subfield (of the Key Information field) is set, the Key Data field is
42 encrypted prior to computing the MIC.
43
44
45 1) Key Descriptor Version 1: HMAC-MD5; IETF RFC 2104 and IETF RFC 1321 together define
46 this function.
47
48
49 2) Key Descriptor Version 2: HMAC-SHA1-128.
50
51 3) Key Descriptor Version 3: AES-128-CMAC.
52
53
54
55
56 8.5.2.1 EAPOL-Key frame notation
57
58
59 Change the text as follows:
60
61 Lifetime is the key lifetime KDE used for sending the expiry timeout value for
62 SMK used during PeerKey Handshake for STA-to-STA SMK key
63
64 identification. The lifetime KDE is also used during MSA
65 Authentication in a mesh to express the timeout value of the PMK-MA.

IEEE P802.11s/D1.05, June 2007
1 8.5.3 4-Way Handshake

2
3
8.5.3.1 4-Way Handshake Message 1
4
5
6 Change 8.5.3.1 as follows:
7
8 Key Information:
9
10
11 Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with
12 HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC)
13
14 8.5.3.2 4-Way Handshake Message 2
15
16
18
19 Key Information:
20
21
23 HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC) - same as Message 1.
24
26
27
29
30 Key Information:
31
33
35
37
39
40
41 Key Information:
42
44
45
HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC) - same as Message 1.
46
47 8.5.4 Group Key Handshake
48
49 8.5.4.1 Group Key Handshake Message 1
50
51
53
54 Key Information:
55
56
Key Descriptor Version = 1 (ARC4 encryption with HMAC-MD5) or 2 (NIST AES key wrap with
57
58 HMAC-SHA1-128) or 3 (NIST AES key wrap with AES-128-CMAC)
59
60 8.5.4.2 Group Key Handshake Message 2
61
62
63
Change 8.5.4.2 as follows:
64
65 Key Information:

IEEE P802.11s/D1.05, June 2007
2
4
5 Insert the following new clause after 8.7:
6
7
8 8.8 Key distribution for MSA
9
10 8.8.1 Overview
11
12
13 This subclause describes the mesh key hierarchy and its supporting architecture. The mesh key hierarchy per-
14 mits an MP to create secure associations with peer MPs without the need to perform an IEEE 802.1X authen-
15 tication each time. The mesh key hierarchy can be used with either IEEE 802.1X authentication or PSK
16 authentication. It is assumed by this standard that the PSK is specific to a single MP and a single MKD.
17
18
19 A key hierarchy consisting of two branches is introduced for use within a mesh, and is shown in Figure s64.
20 A link security branch consists of three levels, supporting distribution of keys between mesh key holders to
21 permit the use of the mesh key hierarchy between a supplicant MP and an MA. A key distribution branch
22 provides keys to secure the transport and management of keys between mesh key holders.
23
24
25 In the link security branch, the first level key (PMK-MKD) is derived by the MKD from either the PSK or
26 from the MSK resulting (per IETF RFC 3748) from a successful IEEE 802.1X Authentication between the
27 AS and the supplicant MP. One or more second level keys (PMK-MAs) are derived from the PMK-MKD.
28
Each PMK-MA may be used to derive one or more PTKs.
29
30
31 In the key distribution branch, the first level key (MKDK) is derived from either the PSK or MSK. A second
32 level key (MPTK-KD) is derived from the MKDK during the mechanism described in 11A.2.3.2. The
33 MKDK permits derivation of more than one MPTK-KD, if required.
34
35
36 As shown in Figure s65, the mesh key distributor (MKD) generates the first level key for both branches from
37 either the PSK or the MSK The second level keys in both branches are generated by the MKD as well. A
38 unique PMK-MA may be delivered from the MKD to each MA using a secure protocol, as described in
39 11A.2.4. Figure s64 illustrates an example of two unique PMK-MAs being distributed to two MAs, labeled
40
41 (a) and (b).
42
43 Upon a successful authentication between a supplicant MP and the MKD, the supplicant MP and the MKD
44 shall delete the prior PMK-MKD, MKDK, and MPTK-KD keys and all PMK-MA keys that were created be-
45
tween the supplicant MP and the same MKD domain. Upon receiving a new PMK-MA key for a supplicant
46
47 MP, an MA shall delete the prior PMK-MA key and all PTKs derived from the prior PMK-MA key.
48
49 The lifetime of all keys derived from the PSK or MSK are bound to the lifetime of the PSK or MSK. For
50 example, the IEEE 802.1X AS may communicate the MSK key lifetime with the MSK. If such an attribute
51
52
is provided, the lifetimes of the PMK-MKD and MKDK shall be not more than the lifetime of the MSK. If
53 the MSK lifetime attribute is not provided, or for PSK, the key lifetime shall be the value of the MIB variable
54 dot11MeshFirstLevelKeyLifetime.
55
56 The lifetime of the PTK and PMK-MA shall be the same as that of the PMK-MKD and the lifetime of the
57
58 MPTK-KD shall be the same as that of the MKDK, as calculated above. When the key lifetime expires, each
59 key holder shall delete their respective derived keys.
60
61 The mesh key hierarchy derives its keys using the Key Derivation Function (KDF) as defined in 8.8.3 with
62 separate labels to further distinguish derivations.
63
64
65 The operations performed by mesh key holders and the movement of keys within the mesh key hierarchy are

IEEE P802.11s/D1.05, June 2007

2
3
4 MSK or PSK
5
6
7
8
9
10 PMK-MKD MKDK
11
12
13
14 PMK-MA*
15 MPTK-KD*
16
17
18
19 PTK*
20
21
*Multiple keys may be derived.
22
23
24
25 Figure s64—Mesh key hierarchy
26
27
28
29
30 Authentication Server
31 (802.1X Authentication only)
32
33
34 MSK PSK
35
36
Mesh Key Distributor
37
MKD-ID
38 Derives PMK-MKD, PMK-MAs
39 Derives MKDK and MPTK-KD
40
41
PMK-MA(a) PMK-MA(b)
42
43
44
45 Mesh Authenticator(a) Mesh Authenticator(b)
46 MA-ID(a) MA-ID(b)
Derives PTK(a) Derives PTK(b)
47
48
49
50
51 Figure s65—Key distribution between mesh key holders
52
53 8.8.2 Key hierarchy
54
55
56 The mesh key hierarchy consists of two branches whose keys are derived using the KDF described in 8.8.3.
57
58 The first branch, the link security branch, consists of three levels and results in a PTK for use in securing a
59
60 link.
61 — PMK-MKD – The first level of the link security branch, this key is derived as a function of the MSK
62
or PSK and the Mesh ID. It is cached by the supplicant MP and the PMK-MKD key holder, namely
63
64 the MKD. This key is mutually derived by the supplicant MP and the MKD. There is only a single
65 PMK-MKD derived between the supplicant MP and the MKD domain.

IEEE P802.11s/D1.05, June 2007
1 — PMK-MA – The second level of the link security branch, this key is mutually derived by the suppli-
2 cant MP and the MKD. It is delivered by the MKD to an MA to permit completion of an MSA
3
handshake between the supplicant MP and the MA.
4
5 — PTK – The third level of the link security branch that defines the IEEE 802.11 and IEEE 802.1X pro-
6 tection keys. The PTK is mutually derived by the supplicant and the PMK-MA key holder, namely
7 the MA.
8
9
10 The PTK is used as defined by 8.5 for secure link operation.
11
12 The second branch, the key distribution branch, consists of two levels and results in a MPTK-KD for use in
13
14
allowing an MP to become an MA, and in securing communications between an MA and the MKD.
15 — MKDK – The first level of the key distribution branch, this key is derived as a function of the MSK
16 or PSK and the Mesh ID and cached by the supplicant MP and the MKD. This key is mutually
17
derived by the supplicant MP and the MKD. There is only a single MKDK derived between the sup-
18
19 plicant MP and the MKD.
20 — MPTK-KD – The second level of the key distribution branch that defines protection keys for com-
21 munication between MA and MKD. The MPTK-KD is mutually derived by the supplicant MP
22
23 (when it becomes an MA) and the MKD.
24
25 8.8.3 Key derivation function
26
27
28
The key derivation function for the mesh key hierarchy, KDF, is a variant of the PRF function defined in
29 8.5.1.1, and defined as follows:
30
31
32 Output = KDF-Length (K, label, Context) where
33 Input: K, a 256 bit key derivation key
34 label, a string identifying the purpose of the keys derived using this KDF
35
36 Context, a bit string that provides context to identify the derived key
37 Length, the length of the derived key in bits
38 Output: a Length-bit derived key
39
40
41 result = ""
42
iterations = (Length+255)/256
43
44 do i = 1 to iterations
45 result = result || HMAC-SHA256(K, i || label || 0x00 || Context || Length)
46
47
od
48 return first Length bits of result, and securely delete all unused bits
49
50 In this algorithm, i and Length are encoded as 16-bit unsigned integers, represented using the bit ordering con-
51 ventions of 7.1.1.
52
53
54 8.8.4 PMK-MKD
55
56 The first level key of the mesh key hierarchy link security branch, PMK-MKD binds the SPA, MKD domain
57
58 identifier, MKD-NAS-ID, and Mesh ID with the keying material resulting from the negotiated AKM. The
59 PMK-MKD is the top level 256-bit keying material used to derive the next level keys (PMK-MAs):
60
61 PMK-MKD = KDF-256(XXKey, “MKD Key Derivation”, MeshIDlength || MeshID ||
62
63
NASIDlength || MKD-NAS-ID || MKDD-ID || SPA || MPTKANonce)
64
65 where

IEEE P802.11s/D1.05, June 2007
1 — KDF-256 is the KDF function as defined in 8.8.3 used to generate a key of length 256 bits.
2
3 — If the AKM negotiated is 00-0F-AC:5, then XXKey shall be the second 256 bits of the MSK (MSK
4 being derived from the IEEE 802.1X authentication), i.e., XXKey = L(MSK, 256, 256). If the AKM
5 negotiated is 00-0F-AC:6, then XXKey shall be the PSK.
6
7
— “MKD Key Derivation” is 0x4D4B44204B65792044657269766174696F6E.
8 — MeshIDLength is a single octet whose value is the number of octets in the Mesh ID.
9
10 — Mesh ID is the mesh identifier, a variable length sequence of octets, as it appears in the Beacon
11 frames and Probe Response frames.
12 — NASIDlength is a single octet whose value is the number of octets in the MKD-NAS-ID.
13
14 — MKD-NAS-ID is the identifier of the MKD sent from the 802.1X Authenticator MP to the 802.1X
15 Supplicant MP during Initial MSA Authentication.
16
17 — MKDD-ID is the 6-octet MKD domain identifier field from the Mesh security capability information
18 element that was used during Initial MSA Authentication.
19 — SPA is the supplicant MP’s MAC address.
20
21 — MPTKANonce is an unpredictable 256-bit pseudo-random value generated by the PMK-MKD
22 holder (MKD), delivered along with PMK-MA to the MA, and provided by the MA to the suppli-
23 cant MP during Initial MSA Authentication.
24
25
26 The PMK-MKD is referenced and named as follows:
27
28 PMK-MKDName = Truncate-128(SHA-256(“MKD Key Name” || MeshIDlength || MeshID ||
29 NASIDlength || MKD-NAS-ID || MKDD-ID || SPA || MPTKANonce))
30
31
32 where
33 — “MKD Key Name” is 0x4D4B44204B6579204E616D65.
34
35 — Truncate-128(-) returns the first 128 bits of its argument, and securely destroys the remainder.
36
37 8.8.5 PMK-MA
38
39
40 The second level key of the mesh key hierarchy link security branch, PMK-MA, is a 256-bit key used to de-
41 rive the PTK. The PMK-MA binds the SPA, MKD, and MA:
42
43 PMK-MA = KDF-256(PMK-MKD, “MA Key Derivation”, PMK-MKDName || MA-ID || SPA)
44
45
46 where
48
49 — PMK-MKD is the key defined in 8.8.4.
50 — “MA Key Derivation” is 0x4D41204B65792044657269766174696F6E.
51
52 — PMK-MKDName is defined in 8.8.4.
53 — MA-ID is the identifier of the holder of PMK-MA (MA).
54
55 — SPA is the supplicant MP’s MAC address.
56
57 The PMK-MA is referenced and named as follows:
58
59
60 PMK-MAName = Truncate-128(SHA-256(“MA Key Name” || PMK-MKDName || MA-ID ||
61 SPA))
62
63 where
64
65 — “MA Key Name” is 0x4D41204B6579204E616D65.

IEEE P802.11s/D1.05, June 2007
1 8.8.6 PTK
2
3
4
The third level key of the mesh key hierarchy link security branch is the PTK. This key is mutually derived
5 by the Supplicant MP and the MA with the key length being a function of the negotiated cipher suites as de-
6 fined by Table 8-2 in 8.5.2.
7
8 The PTK derivation is as follows:
9
10
11 PTK = KDF-PTKLen(PMK-MA, “Mesh PTK Key derivation”, MPTKSNonce || MPTKANonce ||
12 MA-ID || SPA || PMK-MAName)
13
14
where
15
16 — KDF-PTKLen is the KDF function as defined in 8.8.3 used to generate a PTK of length PTKLen.
17
18 — PMK-MA is the key that is shared between the Supplicant MP and the MA
19 — “Mesh PTK Key derivation” is 0x4D6573682050544B204B65792064657269766174696F6E.
20
21 — MPTKSNonce is a 256 bit pseudo-random bit string contributed by the Supplicant MP
22 — MPTKANonce is a 256 bit pseudo-random string contributed by the MKD or MA
23
24 — SPA is the Supplicant MP’s MAC address
25 — MA-ID is the MAC address of the MA.
26
27 — PMK-MAName is defined in 8.8.5
28 — PTKlen is the total number of bits to derive, e.g., number of bits of the PTK. The length is dependent
29
30 on the negotiated cipher suites as defined by Table 8-2 in 8.5.2.
31
32 Each PTK has three component keys, KCK, KEK, and TK, derived as follows:
33
34
35
The KCK shall be computed as the first 128 bits (bits 0-127) of the PTK:
36
37 KCK = L(PTK, 0, 128)
38
39 where L(-) is defined in 8.5.1.
40
41
42 The KCK is used to provide data origin authenticity between a supplicant MP and the MA when used in
43 EAPOL-Key frames defined in 8.5.2.
44
45 The KEK shall be computed as bits 128-255 of the PTK:
46
47
48 KEK = L(PTK, 128, 128)
49
50 The KEK is used to provide data confidentiality between a supplicant MP and the MA when used in EAPOL-
51 Key frames defined in 8.5.2.
52
53
54 Temporal keys (TK) shall be computed as bits 256-383 (for CCMP) or bits 256-511 (for TKIP) of the PTK:
55
56 TK = L(PTK, 256, 128), or
57
58 TK = L(PTK, 256, 256)
59
60 The temporal key is configured into the Supplicant MP through the use of the MLME-SETKEYS.request
61 primitive. The MP uses the temporal key with the pairwise cipher suite; interpretation of this value is cipher-
62 suite specific.
63
64
65 The PTK is referenced and named as follows:

IEEE P802.11s/D1.05, June 2007
1 PTKName = Truncate-128(SHA-256(“Mesh PTK Name” || PMK-MAName || MPTKSNonce ||

2
3 MPTKANonce || MA-ID || SPA))
4
5 where
6
7 — “Mesh PTK Name” is 0x4D6573682050544B204E616D65.
8
9 8.8.7 MKDK
10
11
12
The first level key of the key distribution branch, MKDK binds the MA-ID (the MAC address of the MP es-
13 tablishing the MKDK to become an MA), MKD domain identifier, and Mesh ID with the keying material re-
14 sulting from the negotiated AKM. The MKDK is used to derive the MPTK-KD.
15
16 MKDK = KDF-256(XXKey, “Mesh Key Distribution Key”, MeshIDLength || MeshID ||
17
18 NASIDlength || MKD-NAS-ID || MKDD-ID || MA-ID || MPTKANonce)
19
20 where
21
23 — If the AKM negotiated is 00-0F-AC:5, then XXKey shall be the second 256 bits of the MSK (MSK
24
being derived from the IEEE 802.1X authentication), i.e., XXKey = L(MSK, 256, 256). If the AKM
25
26 negotiated is 00-0F-AC:6, then XXKey shall be the PSK.
27 — “Mesh Key Distribution Key” is 0x4D657368204B657920446973747269627574696F6E204B6579.
28
29 — MeshIDLength is a single octet whose value is the number of octets in the Mesh ID.
30 — Mesh ID is the mesh identifier, a variable length sequence of octets, as it appears in the Beacon
31
33 — NASIDlength is a single octet whose value is the number of octets in the MKD-NAS-ID.
34
35 — MKD-NAS-ID is the identifier of the MKD sent from the 802.1X Authenticator MP to the 802.1X
36 Supplicant MP during Initial MSA Authentication.
37
38 — MKDD-ID is the 6-octet MKD domain identifier field from the Mesh security capability information
39 element that was used during Initial MSA Authentication.
40 — MA-ID is the MAC address of the MP establishing a security association with the MKD in order to
41
42 become configured as an MA.
43 — MPTKANonce is identical to the value used to calculate PMK-MKDName, as described in 8.8.4.
44
45
46 The KDK is referenced and named as follows:
47
48 MKDKName = Truncate-128(SHA-256(“MKDK Name” || MeshIDLength || MeshID ||
49
NASIDlength || MKD-NAS-ID || MKDD-ID || MA-ID || MPTKANonce))
50
51
52 where
53 — “MKDK Name” is 0x4D4B444B204E616D65.
54
55 — Truncate-128(-) returns the first 128 bits of its argument, and securely destroys the remainder.
56
57
8.8.8 MPTK-KD
58
59
60 The second level key of the key distribution branch, MPTK-KD, is a 256-bit key that is mutually derived by
61 an MA and an MKD. The MPTK-KD is derived:
62
63
64 MPTK-KD = KDF-256(MKDK, “Mesh PTK-KD Key”, MA-Nonce || MKD-Nonce || MA-ID ||
65 MKD-ID)

IEEE P802.11s/D1.05, June 2007
1 where
2
3 — MKDK is the key defined in 8.8.7.
4 — “Mesh PTK-KD Key” is 0x4D6573682050544B2D4B44204B6579.
5
6 — MA-Nonce is a 256-bit pseudo-random string contributed by the MA.
7 — MKD-Nonce is a 256-bit pseudo-random string contributed by the MKD.
8
9 — MA-ID is the MAC address of the MA.
10 — MKD-ID is the MAC address of the MKD.
11
12
13 The MPTK-KD has two component keys, the Mesh Key confirmation key for key distribution (MKCK-KD)
14 and the Mesh Key encryption key for key distribution (MKEK-KD), derived as follows:
15
16 The MKCK-KD shall be computed as the first 128 bits (bits 0-127) of the MPTK-KD:
17
18
19 MKCK-KD = L(MPTK-KD, 0, 128)
20
21 where L(-) is defined in 8.5.1.
22
23
24 The MKCK-KD is used to provide data origin authenticity in messages exchanged between MA and MKD,
25 as defined in 11A.4.2.3.
26
27 The MKEK-KD shall be computed as bits 128-255 of the MPTK-KD:
28
29
30 MKEK-KD = L(MPTK-KD, 128, 128)
31
32 The MKEK-KD is used to provide data confidentiality in messages exchanged between MA and MKD, as
33 defined in 11A.4.2.3.
34
35
36 The MPTK-KD is referenced and named as follows:
37
38 MPTK-KDName = Truncate-128(SHA-256(MKDKName || “MPTK-KD Name” || MA-Nonce ||
39 MKD-Nonce || MA-ID || MKD-ID))
40
41
42 where
43 — “MPTK-KD Name” is 0x4D50544B2D4B44204E616D65.
44
45
46 8.8.9 Mesh key holders
47
48 8.8.9.1 Key holder requirements
49
50
51 The MKD and MA are responsible for the derivation of keys in the mesh key hierarchy.
52
53 The MKD shall meet the following requirements.
54
55 — The MKD shall provide NAS client (the client component of a Network Access Server that commu-
56 nicates with an Authentication Server) functionality.
57 — The MKD domain identifier (MKDD-ID) uniquely identifies an MKD (i.e., there is a one-to-one
58
59
mapping between an MKD domain identifier and an MKD). The MKDD-ID is bound into the deri-
60 vation of the first level keys (PMK-MKD and MKDK).
61 — The MKD NAS Identifier (MKD-NAS-ID) shall be set to the identity of the NAS Client provided by
62
the MKD (e.g., NAS-Identifier as defined in RFC 2865 if RADIUS is used as the backend protocol).
63
64 MKD-NAS-ID shall not be longer than 48 octets. MKD-NAS-ID is bound into the derivation of the
65 first level keys (PMK-MKD and MKDK).

IEEE P802.11s/D1.05, June 2007
1 — The mesh key distributor identifier (MKD-ID) shall be set to a MAC address of the physical entity
2 that stores the MKD. The MKD-ID is used in the generation of the MPTK-KD.
3
4 — When the PMK-MKD lifetime expires, the MKD shall delete the PMK-MKD SA and shall delete all
5 PMK-MAs cached within the MKD that were derived from the PMK-MKD.
6
7 — The MKD shall not expose the PMK-MKD to other parties.
8
— The MKD shall not expose the PMK-MA to parties other than the authorized MA.
9
10
11 The MA shall meet the following requirements.
12
13 — The mesh authenticator identity (MA-ID) shall be set to a MAC address of the physical entity that
14 stores the PMK-MA and uses it to generate the PTK. That same MAC address shall be used to
15 advertise the MA identity to MPs and to the MKD.
16
17 — The MA shall provide the IEEE 802.1X Authenticator function, and its Port Access Entity shall
18 authorize the controlled Port for communication with a peer MP only upon installation of a PTK
19 derived with the peer MP. The PTK shall be derived from a PMK-MA received from the MKD.
20
21 — The MA shall provide the IEEE 802.11 Authenticator function to derive and distribute the GTK to
22 connected MPs.
23
24 — When the PMK-MA lifetime expires, the MA shall delete the PMK-MA SA and shall revoke all
25 PTKs derived from the PMK-MA using the MLME-DELETEKEYS primitive.
26
27
— The MA shall not expose the PMK-MA to other parties.
28
29 8.8.9.2 Authorization of mesh key holders
30
31
32 The authorization of an MKD is achieved through Initial MSA Authentication. An MP implementing the
33 MKD function is authorized to be an MKD by any MP that performs authentication through the MKD.
34 Explicitly, successful completion of Initial MSA Authentication, including the confirmed creation of the
35 mesh key hierarchy, provides authorization of the MKD identified by MKD-NAS-ID (an identity bound into
36 the PMK-MKD) to be an MKD for the MP performing authentication.
37
38
39 An MA is authorized by the MKD with which the MA communicates. If an MA is co-located with an MKD
40 (in the same physical device), the MA function is authorized by the MKD due to the co-location. Otherwise,
41 the authorization of the MA occurs through the Mesh key holder security association (11A.4.3). The first
42
43 message of the Mesh key holder security handshake (11A.4.3.2) contains the identity of the aspirant MA in
44 the MA-ID field. Upon receiving this message, the MKD shall locate the PMK-MKD SA that contains an
45 SPA entry that is identical to the MA-ID received in the first message of the Mesh key holder security hand-
46 shake. The MKD shall authorize the MA to receive PMK-MA keys if and only if (a) the contents of the
47 PMK-MKD SA allow the authorization, and (b) the aspirant MA successfully completes the Mesh key
48
49 holder security handshake.
50
51 The distribution of PMK-MAs within a mesh shall satisfy the following requirements:
52
53 — Delivery of PMK-MA keys shall be performed using the protocol defined in 11A.4.4.
54
— A PMK-MA key shall be delivered to an MA only if the MA is authorized to receive PMK-MA keys.
55
56 — A PMK-MA key shall be delivered to an authorized MA only if the authorized identity of the MA
57 (i.e., the MA-ID exchanged during the MA’s Mesh key holder security handshake) is identical to the
58
59
MA-ID value used to derive the PMK-MA being delivered.
60
61 8.8.9.3 PMK-MA distribution within an MKD domain
62
63
64 An MKD domain is identified by the MKD domain identifier (MKDD-ID). An MKD domain contains a sin-
65 gle MKD and at least one MA which has established a security association with the MKD.

IEEE P802.11s/D1.05, June 2007
1 An MP creates its mesh key hierarchy during the Initial MSA Authentication, utilizing information for-
2 warded from the MKD by the MA. During the Initial MSA Authentication, the MKD derives the PMK-
3
MKD from the MSK acquired during IEEE 802.1X authentication, when the negotiated AKM is 00-0F-
4
5 AC:5, or from the PSK, when the negotiated AKM is 00-0F-AC:6.
6
7 Additionally, the MKD is responsible for deriving a PMK-MA for each MA within the MKD domain. The
8 MKD is responsible for transmitting the derived PMK-MA keys securely to those key holders, along with the
9
PMK-MAName, the key lifetime, the PMK-MKDName used to derive the PMK-MA, and the MPTKANonce
10
11 used in the calculation of PMK-MKDName.
12
13 The secure transmission of keys and key information from MKD to MA shall be through the use of the mesh
14 key transport protocol described in 11A.4.2.3.
15
16
17 Each MA shall derive the PTK mutually with the supplicant MP.
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 9. MAC sublayer functional description

2
3
4 Insert the following new clause after 9.13:
5
6 EDITORIAL NOTE—The following clause numbering based on 11n/D2.0 ending with 9.20
7
8
9 9.21 MDA (Optional)
10
11 Mesh Deterministic Access (MDA) is an optional access method that allows supporting MPs that support
12
13 MDA to access the channel at selected times with lower contention than would otherwise be possible. This
14 standard does not require all MPs to use MDA. MDA can be used by a subset of MPs in a Mesh. However,
15 MDA connections can only be setup among MDA-supporting MPs. The performance of MDA may be
16 impacted by devices that do not respect MDA reservations. MDA sets up time periods in mesh neighbor-
17 hoods when a number of MDA-supporting MPs that may potentially interfere with each others’ transmis-
18
19 sions or receptions are set to not initiate transmission sequences. For each such time period, supporting MPs
20 that set up the state for the use of these time periods are allowed to access the channel using MDA access
21 parameters (CWMin, CWMax, and AIFSN). In order to use the MDA method for access, an MP shall be a
22 synchronizing MP. The MDA method is described in detail below.
23
24
25 9.21.1 MDA opportunity (MDAOP)
26
27 An MDAOP is a period of time within every Mesh DTIM interval that is set up between a transmitter and a
28 receiver such that the following are satisfied. Once an MDAOP is setup,
29
30 — The transmitter that owns the MDAOP uses CSMA/CA and backoff to obtain a TXOP as described
31 in 9.9.1 and using parameters MDACWmin, MDACWmax, and MDAIFSN. The ranges of values
32 allowed for MDACWMin, MDACWMax, and MDAIFSN parameters are identical to those allowed
33 for EDCA.
34
35 — The MDAOP is advertised and all MPs supporting MDA that hear these advertisements except the
36 transmitter that set up the MDAOP are required to not initiate new transmission during the TXOP
37 initiated in the MDAOP.
38
39
40 9.21.2 MDAOP sets
41
42 A set of MDAOPs may be setup for individually addressed transmissions from a transmitter to a receiver by
43 the transmitter. Such a set is identified by a unique ID called the MDAOP Set ID. The MDAOP Set ID has to
44 be unique for a transmitter, so that the MDAOP set ID and the transmitter (or set owner) MAC address
45
46 uniquely identifies an MDAOP set in the mesh. The MDAOP set ID is a handle that allows operation such as
47 setup and teardown to be conducted together for the entire set of MDAOPs in an MDAOP set. An example
48 use of MDAOP set concept is to establish an MDAOP set for a single QoS flow.
49
50 MDAOP set ID is an 8-bit unsigned number. The special value of MDAOP set ID, when all bits are set to 1,
51
52 is reserved to mean all MDAOPs.
53
54 9.21.3 MDA TXOP
55
56
A TXOP that is obtained by an MP by using MDA parameters in an MDAOP is called an MDA TXOP. An
57
58 MDA TXOP is required to end within the MDAOP in which it was obtained. Thus, an MDA TXOP ends
59 either by MDA TXOP limit time after it began or by MDAOP end time, whichever is earlier.
60
61 9.21.4 Neighborhood MDAOP times at an MP
62
63
64 In a neighborhood surrounding an MP, all the TX-RX times reported by its neighbors (in their MDAOP
65 advertisements) form a set of MDAOPs that are already being used in the neighborhood. No new MDAOPs

IEEE P802.11s/D1.05, June 2007
1 may be set up by the MP during these times. These times are referred to as Neighborhood MDAOP times for
2 the MP. In effect, Neighborhood MDAOP Times at an MP include all MDAOPs for which the MP and its
3
neighbors are either the transmitters or receivers.
4
5
6 9.21.5 Neighbor MDAOP interfering times for an MP
7
8
9 The Interfering times reported by an MP in its MDAOP advertisements are times that may not be used for a
10 new MDAOP with that specific MP. While the MP itself is not the transmitter or receiver in an MDAOP
11 during these times, one of its neighbors is. New MDAOPs to the MP during these times may experience
12 interference. However, new MDAOPs may be setup with another MP during these interfering times. Thus,
13
14 for every neighbor, there is a set of times that are interfering. These times are referred to as Neighbor
15 MDAOP interfering times for that neighbor.
16
17
18
9.21.6 MDA access fraction (MAF)
19
20 The MDA access fraction at an MP is the ratio of the total duration of its ‘Neighborhood MDAOP Times’
21 (see definition above) in a Mesh DTIM interval to the duration of the Mesh DTIM interval. This parameter
22
23 may be used to limit the use of MDA in a neighborhood centered at an MP to a certain fraction of the total
24 channel time. The maximum value for MAF that is allowed at an MP is specified by the dot11MAFlimit
25 parameter.
26
27
28 The dot11MAFlimit is copied into the MDA Access Fraction Limit field of the MDAOP Advertisements
29 information element. Before attempting to set up an MDAOP Set with a neighbor, an MP is required to
30 ensure that the new MDAOP set does not cause the MAF of its neighbors to exceed their MAF Limit. An
31 MDAOP setup request may be refused by the intended receiver if the MAF limit of its own neighbors is
32
33
exceeded due to the new setup.
34
35 9.21.7 Action frames for MDAOPs setup, teardown, and MDAOP advertisements
36
37
38 The elements that are used for MDA may be carried in action frames. The format of such actions frames
39 that carry the elements and the MDA frame is described in 7.4.13.4.
40
41
42 9.21.8 MDAOP setup procedure
43
44
The setup of an MDAOP set is initiated by the intended transmitter, and is accepted/rejected by the intended
45
46 receiver. Once accepted, the transmitter is referred to as the owner of the MDAOP. The setup procedure for
47 an MDAOP set is as follows:
48
49 a) The MP that intends to be the transmitter in a new MDAOP set builds a map of Neighborhood
50 MDAOP times in the Mesh DTIM interval after hearing Advertisements from all of its neighbors
51 that have MDA active. If no advertisement was heard from a neighbor in the last
52 dot11MDAdvertPeriodMax, the MP may request the neighbor for MDAOP Advertisement.
53
54 b) The intended transmitter MP also considers the Neighbor MDAOP Interfering Times of the intended
55 receiver.
56
57 c) Based on traffic characteristics, it then chooses MDAOP starting times and durations in the Mesh
58 DTIM interval that do not overlap with either its Neighborhood MDAOP Times or the Neighbor
59
MDAOP Interfering Times of the intended receiver. It also avoids using times that are known to it as
60
61 being used by itself or one of its neighbors for other activities such as beacon transmissions.
62
d) It then verifies that the new MDAOP Set will not cause the MAF limit to be crossed for its neigh-
63
64 bors. If MAF limit would be crossed for its neighbors, due to the new MDAOP Set, it suspends the
65 setup process.

IEEE P802.11s/D1.05, June 2007
1 e) If the MAF limits at all neighbors are respected despite the new MDAOP set, it transmits an
2 MDAOP Setup request information element to the intended receiver with chosen MDAOP locations
3
and durations.
4
5 f) The receiver of the MDAOP Setup Request information element checks to see if the MDAOP times
6 have overlap with its Neighborhood MDAOP Times. The receiver also checks if the new MDAOP
7 Set will cause the MAF limit to be crossed for its neighbors. The MDAOP Setup Reply information
8
9 element is used to reply to a setup request.
10 g) The receiver rejects the setup request if there are overlaps of the requested MDAOP set with its
11 Neighborhood MDAOP Times, or other times that it knows are set to be used by itself or its neigh-
12
bors for activities such as beacon transmissions. It may suggest alternate times by including the
13
14 optional field Alternate Suggested Request information element in the MDAOP Setup Reply ele-
15 ment.
16 h) The receiver also rejects the setup request if the MAF limit of itself or its neighbors will be exceeded
17
18 due to the new setup.
19 i) If suitable, the receiver accepts the setup.
20
21
22
9.21.9 MDAOP advertisements
23
24 Every MP that has MDA active is required to advertise TX-RX and Interfering times using the MDAOP
25 Advertisements information element, at least once in dot11MDAdvertPeriodMax. These advertisements are
26 always transmitted in group addressed frames; either in Beacon frames or MDA action frames. The adver-
27
28
tised times include:
29 a) TX-RX times report:
30
31
1) All MDAOP times for which the MP is the transmitter or the receiver.
32 2) All other times that it knows are busy/reserved such that it is either the transmitter or the
33 receiver. A non exhaustive list includes expected HCCA times for an MAP and self or neigh-
34
bor’s expected beacon times.
35
36 b) Interfering times report:
37
1) All TX-RX times reported by the MP’s neighbors so that the MP is neither the transmitter nor
38
39 the receiver during those times.
40
41 9.21.10 MDAOP set teardown
42
43
An MDAOP set is successfully torn down once both the transmitter and the receiver stop advertising the set
44
45 in their TX-RX times. Either the transmitter or the receiver may indicate a teardown by transmitting the
46 MDAOP Set Teardown information element to the other communicating end (transmitter or the receiver).
47 The teardown is assumed successful once the ACK is received, or maximum retry attempts are exceeded.
48
49
The transmitter assumes a successful teardown and stops using or advertising (in TX-RX times report) an
50
51 MDAOP set if any of the following happens:
52 a) Its MDAOP Set Teardown information element is successfully Acked.
53
54 b) The maximum retries for the teardown information element it is transmitting are exceeded.
55 c) The receiver’s advertisement does not include the MDAOP set
56
57 d) The receiver is unreachable for greater than dot11MDAOPtimeout time
58
59 The receiver assumes a successful teardown and stops advertising an MDAOP set if any of the following
60 happens:
61
62 a) Its MDAOP Set Teardown information element is successfully Acked.
63 b) The maximum retries for the teardown information element it is transmitting are exceeded.
64
65 c) The transmitter’s advertisement does not include the MDAOP set.

IEEE P802.11s/D1.05, June 2007
1 d) The transmitter is inactive for greater than dot11MDAOPtimeout time

2
3
The interfering times are directly derived from neighbors’ TX-RX times report. The interfering times report
4
5 reflects the latest TX-RX times reports from the neighbors.
6
7 9.21.11 Access during MDAOPs
8
9
MPs that have MDA active maintain the Neighborhood MDAOP Times state of MDAOPs when either they
10
11 or their neighbors are transmitters or receivers. The access behavior for such MPs during the Neighborhood
12 MDAOP Times is described as below.
13 a) Access by MDAOP owners:
14
15 If the MP is the owner of the MDAOP, it attempts to access the channel using CSMA/CA and
16 backoff using MDACWmax, MDACWmin, and MDAIFSN parameters. If the MP successfully
17 captures an MDA TXOP, before the end of its MDAOP, it may transmit until the end of the
18
MDAOP or until a time less than MDA TXOP limit from the beginning of the MDA TXOP,
19
20 whichever is earlier. The retransmission rules for access in an MDAOP are the same as that of
21 EDCA. Specifically, if there is loss inferred during the MDA TXOP, retransmissions require
22 that a new TXOP be obtained using the MDA access rules in the MDAOP. No MDA TXOPs
23 may cross MDAOP boundaries.
24
25 The MP shall not use MDA access parameters to access the channel outside of MDAOPs
26 owned by it.
27
b) Access by non-owners of MDAOP:
28
29 MDA MPs that are not the owner of the current MDAOP can start transmitting after the owner
30 of the MDAOP has finished its transmission.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 10. Layer management

2
3
4
5
10.3 MLME SAP interface
6
7 EDITORIAL NOTE—11ma ended with 10.3.29, 11k added 30-33, 11r added 34-35, 11y added 36, 11n
8 added 38
9
10
11 Insert the following new clause after 10.3.38:
12
13 10.3.39 PassivePeerLinkOpen
14
15
16 The following primitives describe how a mesh entity passively starts a peer link establishment process.
17
18
10.3.39.1 MLME-PassivePeerLinkOpen.request
19
20
21 10.3.39.1.1 Function
22
23
24
This primitive requests that the mesh entity start the link establishment protocol passively.
25
26 10.3.39.1.2 Semantics of the service primitive
27
28
29 The primitive parameters are as follows:
30
31 MLME-PassivePeerLinkOpen.request(
32
33 localLinkID
34 )
35
36
37
38 Name Type Valid range Description
39
40 localLinkID Integer 1—216-1 Specifies the integer generated by the IEEE
41 802.11 SME in the effort of identifying the
42 link instance about to be established with a
43 neighboring mesh entity.
44
45
46
47 10.3.39.1.3 When generated
48
49
50 This primitive is generated when the mesh entity wishes to establish a link with a neighbor mesh entity, but
51 does not specify a particular neighbor.
52
53
10.3.39.1.4 Effect of receipt
54
55
56 This primitive initiates a mesh link instance and corresponding finite state machine. The MLME
57 subsequently issues an MLME-PassivePeerLinkOpen.confirm that reflects the results.
58
59
60 10.3.39.2 MLME-PassivePeerLinkOpen.confirm
61
62 10.3.39.2.1 Function
63
64
65 This primitive reports the results of a passive open attempt.

IEEE P802.11s/D1.05, June 2007

2
3
The primitive parameters are as follows:
4
5
6 MLME-PassivePeerLinkOpen.confirm(
7 Local Link ID
8 )
9
10
11
12
13
14
16
17 local Link Integer 1—216-1 Specifies the integer identifying the
18 ID link instance about to be estab-
19 lished with a neighboring mesh
20 entity.
21
22
23
25
26 This primitive is generated as a result of an MLME-PassivePeerLinkOpen.request.
27
28
29 10.3.39.2.4 Effect of receipt
30
31 The SME is notified of the results of the passive open procedure.
32
33 10.3.40 ActivePeerLinkOpen
34
35
36 The following primitives describe how a mesh entity actively starts a peer link management procedure with
37 a specified peer MAC entity that is within a mesh entity.
38
39
10.3.40.1 MLME-ActivePeerLinkOpen.request
40
41
42 10.3.40.1.1 Function
43
44 This primitive requests that the mesh entity start the link management procedure actively with a specified
45
46
peer MAC entity that is within a mesh entity.
47
49
51
52
53 MLME-ActivePeerLinkOpen.request(
54 peerMAC,
55 localLinkID
56 )
57
58
59 Additional parameters needed to perform active open procedure are not included in the primitive parameter
60 list since the MLME already has that data (maintained as internal state).
61
62
10.3.40.1.3 When generated
63
64
65 This primitive is generated when the mesh entity wishes to establish a link with a neighbor mesh entity.

IEEE P802.11s/D1.05, June 2007
1
3
4 PeerMAC MAC Address Valid individ- Specifies the address of the peer MAC entity
5 ual MAC with which to perform the link management
6 address procedure.
7
8 local Link ID Integer 1—216-1 Specifies the integer identifying the link
9 instance about to be established with a neigh-
10 boring mesh entity.
11
12
14
15
16 This primitive initiates a peer link management procedure. The Peer Link Open message is transmitted. The
17 MLME subsequently issues an MLME-ActivePeerLinkOpen.confirm that reflects the results.
18
19 10.3.40.2 MLME-ActivePeerLinkOpen.confirm
20
21
22 10.3.40.2.1 Function
23
24 This primitive reports the results of an active peer link open attempt.
25
26
27
10.3.40.2.2 Semantics of the service primitive
28
30
31 MLME-ActivePeerLinkOpen.confirm(
32
33 PeerMAC,
34 local Link ID
35 )
36
37
38
40
41 PeerMAC MAC Address Valid individual MAC address Specifies the address of the peer
42 MAC entity with which to per-
43 form the link establishment pro-
44 cess.
45
46 local Link ID Integer 1—216-1 Specifies the integer identifying
47 the link instance about to be estab-
48 lished with a neighbor mesh
49 entity.
50
51
52
54
55 This primitive is generated as a result of an MLME-ActivePeerLinkOpen.request.
56
57
59
60 The SME is notified of the results of the active peer link open procedure.
61
62
10.3.41 SignalPeerLinkStatus
63
64
65 The following primitives report the link status to the mesh entity as the result of peer link management.

IEEE P802.11s/D1.05, June 2007
1 10.3.41.1 MLME-SignalPeerLinkStatus.indication
2
3
4
10.3.41.1.1 Function
5
6 This primitive indicates that the mesh entity has finished the link establishment procedure with a specified
7 peer mesh entity and reports the status of the link.
8
9
11
13
14
15
MLME-SignalPeerLinkStatus.indication(
16 local Link ID,
17 StatusCode
18 )
19
20
21
23
24 local Link ID Integer 1—216-1 Specifies the integer generated by the local
25 mesh entity to identify this link instance
26
27 StatusCode Enumeration MESH-LINK-ESTAB- Indicates the result of the peer link establish-
28 LISHED, ment procedure
29 MESH-LINK-CLOSED
30
31
32
34
35
36
This primitive is generated when the mesh entity finishes the link management procedure, either when the
37 peer link is established, or when it is closed.
38
40
41
42 This primitive enables the mesh entity to handle the link instance status.
43
44 10.3.42 CancelPeerLink
45
46
This mechanism supports the process of cancelling the link instance with a specified peer mesh entity.
47
48
49 10.3.42.1 MLME-CancelPeerLink.request
50
51 10.3.42.1.1 Function
52
53
54 This primitive requests the link instance with a specified peer mesh entity be cancelled.
55
57
58
60
61 MLME-CancelPeerLink.request(
62 local Link ID,
63
64 ReasonCode
65 )

IEEE P802.11s/D1.05, June 2007
1
3
5 mesh entity to identify the link instance
6
7 ReasonCode Enumeration MESH-MAX-NEIGH- Reason that the link instance is cancelled.
8 BORS
9
10
12
13
14 This primitive is generated by the SME to cancel a link instance.
15
16
18
19 This primitive sets the mesh entity to get ready to close the peer link with the specified peer mesh entity. The
20
21 MLME subsequently issues a MLME-CancelPeerLink.confirm to reflect the results.
22
23 10.3.42.2 MLME-CancelPeerLink.confirm
24
25
26 10.3.42.2.1 Function
27
28
29 This primitive reports the result of cancel link request.
30
32
33
35
36
37 MLME-CancelPeerLink.confirm(
38
39 local Link ID,
40 ResultCode
41
42 )
43
44
45
47
49 mesh entity to identify the link instance
50
51 ResultCode Enumeration SUCCESS, Indicates the result of the cancel link request.
52 FAILURE-NOT-FOUND The result is either success or failure when
53 the link instance is not found.
54
55
56
58
59
This primitive is generated by the MLME as the result of an MLME-CancelPeerLink.request.
60
61
63
64
65 The SME is notified of the results of the cancel link procedure.

IEEE P802.11s/D1.05, June 2007
1 10.3.43 Mesh layer management (Informative)

2
3
4 The mesh MAC defines a set of protocol independent layer entities, service access points (SAPs) and man-
5 agement objects that support implementation of path selection and forwarding protocols. The layer entities
6 are responsible for:
7
8 a) Forwarding and filtering of individually addressed and group addressed MPDUs
9 b) Maintenance of the information required to make forwarding and filtering decisions
10
11 c) Management of the above
12
13 The forwarding of the MPDUs is handled by the mesh MAC. The maintenance of the information needed to
14
15
make forwarding and filtering decisions is handled by the MAC Layer Management Entity (MLME) and the
16 Station Management Entity (SME). The management of these is handled by the SME.
17
18 The forwarding and filtering processing are time critical functions. The maintenance of the information
19 needed to make forwarding and filtering decisions is not time critical and only impacts the performance of
20
21 the path selection protocol.
22
23 Figure s66 illustrates the functional architecture provided by the Extensible Path Selection Framework enti-
24 ties and the principles of operation.
25
26
27 MLME_SAP
28
29 Protocol
30
31
entity
Mesh
32
33 Path Selection
34 MIB
35 Forwarding Filtering
36 database database
37 MLME_GET/SET
38
39
40
41 Learning
42
Forwarding Cache
43
44
45
46
47
48
49 MMPDUs
50
51
52
53 Figure s66—Extensible Path Selection Framework system architecture
54
55
56
57
58 10.3.43.1 Principles of operation
59
60 The MPDUs are received and re-transmitted by the MAC forwarding entity. The Protocol entity is responsi-
61 ble for implementing the path selection algorithm. It uses the internal MLME_SAP interface to send MMP-
62
DUs for path discovery and maintenance. The received MMPDUs are cached in the Learning cache. The
63
64 Protocol entity retrieves data from the cache. Its internal algorithm is used to compute paths and maintain
65 network topology. The Protocol entity adds and removes entries in the Forwarding and Filtering databases

IEEE P802.11s/D1.05, June 2007
1 based on the internal computations. The Mesh Path Selection MIB is used to manage the entities that com-
2 prise the Extensible Path Selection Framework.
3
4
5 10.3.43.2 Inter-layer management
6
7 Figure s67 illustrates the following entities supporting path selection, as illustrated in Figure s67:
8
9 d) Re-transmit process (forwarding)
10 e) Filtering database
11
12 f) Forwarding database
13 g) Learning cache
14
15 h) Protocol entity
16
17
18
19
20 Protocol
21 entity
22 MAC Sub-Layer MLME
23
24 Data Filtering
25 MLME_GET/SET
26 Link database
27 Layer
28 Forwarding
29 Station
database
30 Management
31 Forwarding Entity
32 process Learning
33 cache
34
35
36 PLME
37
38 Physical
39 Layer PLME_GET/SET
40 PMD Sub-layer
41
42
43
44 Figure s67—Inter-layer management entities and their relationship and service access
45 points (SAPs) used for internal communication.
46
47
48
49 10.3.43.3 Re-transmit process
50
51
52
When an IEEE 802.11 MPDU is received, its header is examined to determine the destination. If the destina-
53 tion is local, it is forwarded to the upper layer protocol. If its destination is not local, it is re-transmitted. The
54 re-transmit process uses the information in the forwarding table to determine the address of the next hop des-
55 tination.
56
57
58 10.3.43.4 Filtering database
59
60 The filtering decisions are based on the destination and source addresses and any group addressing policy.
61
62 10.3.43.5 Forwarding database
63
64
65 The forwarding database is used for making the forwarding decision for individually addressed MPDUs.

IEEE P802.11s/D1.05, June 2007
1 10.3.43.6 Learning cache

2
3
The learning cache keeps track of the protocol specific topology metrics collected from the MMPDUs
4
5 received. This is a simple cache of the received protocol MMPDUs. It is maintained by the MLME and can
6 be periodically queried by the protocol entity.
7
8 10.3.43.7 Protocol entity
9
10
11 The protocol entity implements the specific path discovery protocol logic, sends MMPDUs, queries the
12 learning database, and updates the forwarding and filtering databases.
13
14 10.3.43.8 Service primitives
15
16
17 The SME uses the MLME SAP interface to gain access to the entities needed to control the data path
18 processing, send MMPDUs, retrieve status based on the received MMPDUs. These service primitives are
19 defined in addition to the standard IEEE 802.11 GET and SET primitives that operate on the Mesh Path
20 Selection MIB objects. The exact implementation details of these entities are beyond the scope of this
21
22 standard.
23
24 10.3.43.8.1 MLME-SendMeshMgmt.request
25
26 This primitive is used to send an MMPDU.
27
28 MLME-SendMeshMgmt.request(
29 Interval,
30 Count,
31 Action,
32
33
OUI,
34 Contents
35 )
36
37
38
39 Name Type Valid Range Description
40
41 Interval Integer Time interval for sending
42 MMPDUs
43
44 Count Enumeration Number of times to send the
45 MMPDU
46
47 Action Enumeration Management action
48
OUI Octet String IEEE OUI
49
50 Contents Octet String Protocol dependent infor-
51 mation
52
53
54
55 10.3.43.8.2 MLME-SendMeshMgmt.confirm
56
57
58 This service primitive indicates the result of the request.
59
60 10.3.43.8.3 MLME-RecvMeshMgmt.request
61
62 This service primitive is used to retrieve one or more received MMPDUs.
63
64
65

IEEE P802.11s/D1.05, June 2007
1 MLME-RecvMeshMgmt.request (
2 Count,
3
4 Action,
5 OUI,
6 Vendor specific contents
7
8 )
9
10
11
13
14 Count Enumeration Number of items to retrieve
15
16 Action Enumeration Management action
17
OUI Octet String IEEE OUI
18
19 Contents Octet String Protocol dependent infor-
20 mation
21
22
23
24 10.3.43.8.4 MLME-RecvMeshMgmt.confirm
25
26
28
29 10.3.43.8.5 MLME-PathAdd.request
30
31
32 This service primitive is used to add a path to the forwarding table.
33
34
35 MLME-PathAdd.request(
36 OUI,
37
38
Id,
39 Dest,
40 Gw,
41
42 Metrics
43 )
44
45
46
47
48
49
51
52 OUI OctetString IEEE OUI
53
54 Id OctetString Protocol Identifier
55
56 Dest MACAddress Destination MAC address
57 matched with the contents
58 of DA field
59
60 Gw MACAddress Next hop MAC address
61 matched with the contents
62 of the RA field
63
64 Metrics OctetString forwarding metrics used to
65 rank alternate paths.

IEEE P802.11s/D1.05, June 2007
1
2
3
4 10.3.43.8.6 MLME-PathAdd.confirm
5
7
8
9 10.3.43.8.7 MLME-PathRemove.request
10
11 This service primitive is used to remove a path from the forwarding table.
12
13
14 MLME-pathRemove.request(
15 OUI,
16 Id,
17
18
Dest,
19 Gw,
20 Metrics
21 )
22
23
24
26
27 OUI OctetString IEEE OUI
28
29 Id OctetString Protocol Identifier
30
31 Dest MACAddress Destination MAC address matched with
32 the contents of DA field
33
34 Gw MACAddress Next hop MAC address matched with the
35 contents of the RA field
36
Metrics OctetString forwarding metrics used to rank alternate
37
paths.
38
39
40
41
42
43
44 10.3.43.8.8 MLME-PathRemove.confirm
45
46
48
49
50
51
52 11. MLME
53
54
55 11.3 STA Authentication and Association
56
57
58 Insert new clause 11.3.3 at the end of clause 11.3:
59
60 11.3.3 Additional Mechanisms for APs with Mesh Functionality
61
62
After the initial state for a non-AP STA with no mesh functionality has been established for authentication /
63
64 association, the AP with mesh functionality may verify in a timely fashion that the MAC address of the non-
65 AP STA does not belong to another STA with mesh functionality in the mesh network.

IEEE P802.11s/D1.05, June 2007
1 If the MAC address of the non-AP STA does already exist in the mesh network, the AP with mesh function-
2 ality will reject the station. Depending on the progress of the authentication / association, the rejected station
3
will be disassociated and/or deauthenticated with Status Code "unspecified reason".
4
5
6 The mechanism for verifying disjunct MAC addresses depends on the active path selection protocol and
7 might be vendor specific. See 11A.8.9 for HWMP and 11A.9 for RA-OLSR.
8
9
10 11.9 DFS procedures
11
12
13 11.9.7 Selecting and advertising a new channel
14
15 Insert the following new clause after 11.9.7.2:
16
17 EDITORIAL NOTE—clause numbering based on 11y/D2.0 adding 11.9.7.3. The following clause should
18 appear immediately after 11.9.7.2 (i.e., before 11y clause 11.9.7.3)
19
20
21 11.9.7.2aSelecting and advertising a new channel in a mesh
22
23 If an MP detects the need to switch the channel of a PHY (e.g., due to regulatory requirement for radar
24 avoidance), the MP shall attempt to inform peer MPs to which a mesh link has been established on the PHY
25
26 of the need to channel switch.
27
28 Once the MP identifies the candidate channel to switch its PHY to, it creates a new candidate channel
29 precedence indicator value by adding a pseudo-random number to the current channel precedence value. The
30 random value shall be in the range 0 to 8191 inclusive. The random value shall be selected in a manner that
31 minimizes the probability of MPs generating the same number, even when those MPs are subjected to the
32
33 same initial conditions. It is important that designers recognize the need for statistical independence among
34 the random number streams among MPs.
35
36 The MP then executes the UCG switch procedure described in 11A.3.3.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 Insert the following new clause after 11:

2
3
4
5 11A. Mesh networking
6
7
8 11A.1 Mesh discovery
9
10
11 11A.1.1 General
12
13
Mesh discovery and peer link management require that MPs have sufficient information about themselves
14
15 and potential neighbors. This process requires detection of potential mesh neighbors through Beacons or
16 through active scanning using Probe Requests. Mesh peer link management is a continuous process that
17 entails monitoring of neighbors so as to detect and react to changes in connectivity.
18
19
20 11A.1.2 Use of mesh identifier
21
22 The Mesh ID is used as a shorthand for a group of MPs that may form a mesh network. A matching Mesh ID
23
is necessary for joining a mesh, along with other required conditions described in 11A.1.4. The Mesh ID
24
25 may be installed in mesh capable devices by a variety of means which are beyond the scope of this standard.
26 In the simplest case, the Mesh ID is set by the user, e.g., “Mike’s Mesh”.
27
28 NOTE--The Mesh ID is similar in purpose to an SSID, which is used to allow simple STAs to identify can-
29
30 didate APs with which to associate. SSIDs are used in STA implementations for AP discovery, thus to
31 enable MP-to-MP discovery in a mesh while avoiding confusing non-mesh STAs, a new mesh-specific iden-
32 tifier is specified rather than reusing the existing overloaded SSID identifier. To avoid having STAs send
33 association requests to MPs, a valid SSID should not be included in Beacon frames sent by MPs. To avoid
34 compatibility issues, rather than removing the SSID information element from MP Beacon frames, the wild-
35
36 card value is used.
37
38 11A.1.3 Profiles for extensibility
39
40
41 An MP shall support at least one mesh profile. A mesh profile consists of:
42
43 1. A Mesh ID
44 2. A path selection protocol identifier
45
46 3. A path selection metric identifier
47
48 The path selection protocol and path selection metrics in use may be different for different profiles.
49
50
51 11A.1.4 Candidate peer MP discovery
52
53 The purpose of this procedure is to discover candidate peer MPs and their properties, covering cases both
54
55 before and after an MP is a member of a mesh network.
56
57 A configured MP, by definition, has at least one mesh profile. If the MP is a member of a mesh, exactly one
58 mesh profile is active.
59
60
61 An MP performs passive or active scanning to discover neighbor MPs. In case of passive scanning, an MP
62 shall be considered a neighbor MP if and only if all of the following conditions are met (a similar mecha-
63 nism with probe response can be used for active scanning):
64
65 1. A beacon is received from that MP.

IEEE P802.11s/D1.05, June 2007
1 2. The received beacon contains a Mesh ID that matches the Mesh ID of the MP’s active mesh profile
2
3 or that matches the Mesh ID of at least one of the MP’s mesh profiles if the MP is not currently a
4 member of a mesh.
5
6
3. The received beacon contains a Mesh Configuration element (see 7.3.2.54) that contains
7 a. A supported version number
8
9 b. A path selection protocol identifier and metric identifier matching the MP’s active mesh
10 profile or matching at least one of the MP’s mesh profiles if the MP is not currently a
11 member of a mesh.
12
13
14 A neighbor MP shall also be considered a candidate peer if and only if, in addition:
15
16 4. The beacon contains an Mesh Configuration element (see 7.3.2.54) with the “Accepting Peer
17
18 Links” field set to 1.
19
20 The MP attempts to discover all neighbor and candidate peer MPs, and maintains the neighbor MP
21 information (see T.6.1) indicating the MAC address of each MP, the most recently observed link state
22 parameters, the received channel number and state.
23
24
If an MP is unable to detect neighbor MPs, it may adopt a Mesh ID from one of its mesh profiles, and
25
26 proceed to the active state. This may occur, for example, when the MP is the first MP to power on (or
27 multiple MPs power on simultaneously). Peer MP links are established later as part of the continuous mesh
28 peer link management procedures.
29
30
31 11A.2 Mesh peer link management
32
33
34 11A.2.1 Overview
35
36 The Mesh Peer Link Management protocol is used to establish and close peer links between MPs. 11A.2.3
37 specifies the protocol details. The following summarizes the protocol operations.
38
39 MPs shall not transmit data frames or management frames other than the ones used for discovery and peer
40
41
link management until the peer link has been established.
42
43 An MP shall be able to establish at least one mesh link with a peer MP, and may be able to establish many
44 such links simultaneously, if the maximum number of peer MPs is not reached. The procedure of choosing a
45 candidate peer MP from a set of neighbor MPs to establish a mesh link is specified in 11A.1.4.
46
47
48 The MP management peer links using link instances. A link instance is a logical entity that the MP uses to
49 handle a peer link or an attempt of establishing a peer link. Its behavior is governed by a peer link manage-
50 ment finite state machine defined in 11A.2.3.
51
52
53 The MP shall identify a link instance with the peer MP. The link instance identifier is defined as <local-
54 MAC, peerMAC, localLinkID, peerLinkID>. localMAC is the MAC address of the MP. peerMAC is the
55 MAC address of the peer MP or the candidate peer MP. localLinkID is an integer generated by the MP. peer-
56 LinkID is an integer generated by the peer MP or the candidate peer MP. The localLinkID shall be unique
57
58 among all link identifiers used by the MP for its current mesh link instances. The MP selects the localLinkID
59 to provide high assurance that the same number has not been used to identify a recent link instance. The
60 peerLinkID shall be supplied by the peer MP or candidate peer MP in Peer Link Open and Confirm frames.
61 The link identifiers are transmitted via peer link management frames.
62
63
64 The MP shall keep information of link instance identifier and the respective policy as the link state of the
65 link instance. The actual method of handling the link state is out of the scope this specification.

IEEE P802.11s/D1.05, June 2007
1 The MP shall start the peer link management protocol in either of the following two cases. In case one, the
2 IEEE 802.11 SME instructs the MP to passively listen to incoming requests from candidate peer MPs. The
3
SME issues the MLME-PassivePeerLinkOpen.request(localLinkID) primitive to create a finite state
4
5 machine to handle peer link establishment attempts initiated by other MPs. The MP shall issue the MLME-
6 PassivePeerLinkOpen.confirm(localLinkID) primitive to inform the completion of creating the finite state
7 machine. The localLinkID identifies the link instance.
8
9
10 The SME issues a MLME-ActivePeerLinkOpen.request(peerMAC, localLinkID) primitive to create an
11 instance of a finite state machine establishing a link with the candidate peer MP whose MAC address is
12 peerMAC. The MP shall issue the MLME-ActivePeerLinkOpen.confirm(peerMAC, localLinkID) primitive
13 to inform the completion of creating the finite state machine.
14
15
16 A link instance ends when the peer link is closed. The link close can be caused by either an internal event or
17 an external event. The specification of internal events is beyond the scope of this standard.
18
19
20 The IEEE 802.11 SME can close the link instance identified by the instance identifier localLinkID by issu-
21 ing the MLME-CancelPeerLink.request(localLinkID, ReasonCode) primitive. The MP shall issue MLME-
22 CancelPeerLink.confirm(localLinkID, ResultCode) to inform the SME the completion of closing the link.
23
24
Upon closing the link completely, the MP shall issue the MLME-SignalPeerLinkStatus.indication(localL-
25 inkID, statusCode) primitive to report the result of the close.
26
27 Receiving of a correct Peer Link Close frame or a failure of processing the incoming peer link management
28
29 frame shall close the link instance. Such events are external events.
30
31 The behavioral details of closing a link instance are specified in 11A.2.3.
32
33
34 The MP uses the peer link management frames to manage a link instance.
35
36
37 A Peer Link Open frame requests that a mesh link instance be established between the Peer Link Open
38 sender and the receiver. The MP shall send a Peer Link Confirm frame in response to the Peer Link Open
39 frame if the link instance proceeds with the protocol. The Peer Link Close frame is used to inform the
40 receiver to close the mesh peer link. The protocol succeeds in establishing a mesh link when the following
41
requirements are satisfied: 1) both MPs have sent and received (and correctly processed) a Peer Link Open
42
43 frame regarding this mesh link; 2) both MPs have sent and received (and correctly processed) a correspond-
44 ing Peer Link Confirm frame regarding this mesh link.
45
46
47 The protocol has a retry mechanism. The retryTimer controls the maximum time the link instance waits for a
48 Peer Link Confirm frame responding to any Peer Link Open frame the link instance has sent. The MP sets
49 the retryTimer when it sends a Peer Link Open frame. If the MP does not receive a corresponding Peer Link
50 Confirm frame before the retryTimer expires, the link instance shall retry the request by sending the same
51 Peer Link Open frame. The MP shall clear the retryTimer when it receives a corresponding Peer Link Con-
52
53 firm frame or when the link instance is closed. If the MP does not receive a Peer Link Confirm frame after
54 re-sending the Peer Link Open frame for dot11MeshMaxRetries times, the MP shall abort the attempt
55 to establish a peer link instance with the candidate peer MP. The retryCounter is a variable in link state that
56 keeps record of the number of Peer Link Open frames been re-sent for the link instance. It is initiated to zero
57 when the first Peer Link Open frame is sent out for the link instance.
58
59
60 The protocol defines a confirmTimer to bound the time that the MP waits for a Peer Link Open frame after
61 receiving a Peer Link Confirm frame. The MP sets the confirmTimer when the Peer Link Confirm frame is
62
received but the corresponding Peer Link Open frame has not. If the Peer Link Open frame is not received
63
64 when confirmTimer expires, the MP shall abort the attempt to establish a peer link with the candidate peer
65 MP and send a Peer Link Close frame to close the link instance.

IEEE P802.11s/D1.05, June 2007
1 The protocol shall set the holdingTimer when the MP sends the first Peer Link Close frame for the link
2 instance; this timer provides a grace period that prevents deadlock or livelock. Before the holdingTimer
3
expires, the link instance shall respond to the incoming Peer Link Open frames associated with the link
4
5 instance by sending the Peer Link Close frame. When the holdingTimer expires, the MP shall terminate the
6 link instance completely and issue MLME-SignalPeerLinkStatus.indication(localLinkID, MESH-LINK-
7 CLOSED) primitive to inform the IEEE 802.11 SME the result of the close.
8
9
11A.2.2 Processing Peer Link Management Frames
10
11
12 11A.2.2.1 Overview
13
14 The MP shall classify the incoming peer link management frames to decide either to accept, reject, or
15
16
silently ignore the frame. If the frame contains a broadcast/multicast address in TA, it shall be silently
17 ignored. The result of frame process shall trigger an event accordingly (see 11A.2.3.2). The mechanism that
18 to classify frames is beyond the scope of this standard.
19
20 The MP shall verify the link instance identifier in a peer link management frame determining whether the
21
22 identifier identifies a known link instance, fails to match any instance, or is incomplete. The rules for verify-
23 ing instance identifier are frame specific; see 11A.2.2.2, 11A.2.2.3, and 11A.2.2.4.
24
25 The MP shall also verify the configuration parameters, if present, conveyed in the Open and Confirm
26 frames. The Mesh Configuration information element and Frame Control field supply the configuration
27
28 parameters. If either is present in the Confirm, the MP shall verify that the parameters reported by the Candi-
29 date peer MP match those the MP has agreed to use for this link instance. In particular, the MP shall verify
30 the following fields or subfields. This verification is needed to satisfy the consistency property, i.e., to guar-
31 antee that MPs agree on the configuration before establishing a mesh link.
32
33 a) Fields in Mesh Configuration element
34 1) Active Path Selection Protocol ID field
35
36 2) Active Path Selection Metric ID field
37 3) Mesh Capability field, including the following subfields
38
39 •Accepting Peer Links
40 •Power Save Support Enabled
41 •Synchronization Enabled
42
•Synchronization Active
43
44 •Synchronization Support Required from Peer
45 •MDA Enabled
46 b) Frame Control field
47
48 1) Power Management field
49
50 MPs shall verify that the same Path Selection Protocol and the same Path Selection Metric are used.
51
52
53 MPs shall verify that the same parameters defined in the candidate peer MP’s Mesh Capability field are
54 used.
55
56 The MP shall verify that it supports power save support services when the candidate peer MP sets the Power
57
58 Management field of the Frame Control field to 1.
59
60 The MP shall verify that the candidate peer MP supports power save support when the MP intends to operate
61 in Power Save mode.
62
63
64 The MP shall verify that it supports synchronization services when the candidate peer MP sets the “Synchro-
65 nization Support Required from Peer” field to 1.

IEEE P802.11s/D1.05, June 2007
1 The MP shall verify that it supports MDA services when the candidate peer MP sets the “MDA Enabled”
2 field to 1.
3
4
5 The MP shall ignore all security related parameters if the RSN information element is not present.
6
7 11A.2.2.2 Process Peer Link Close frames
8
9
The CLS_IGNR event shall be triggered if the Peer Link Close frame contains a mismatched instance iden-
10
11 tifier or an incomplete instance identifier.
12
13 A received instance identifier is a mismatch if:
14
15 — the locally recorded peerLinkID exists and it does not match the value in the Local Link ID field in
16 the frame, or
17 — the frame carries a non-zero value in the Peer Link ID field of the frame, but the value does not
18
19
match the local record of localLinkID.
20
21 The received instance identifier is incomplete if the value of the Peer Link ID field is zero.
22
23 In other cases, the CLS_ACPT event shall be triggered.
24
25
26 11A.2.2.3 Process Peer Link Open frames
27
28 The OPN_RJCT event shall be triggered if the Peer Link Open frame contains an unacceptable or erroneous
29 configuration parameter (see 11A.2.2.1) or the value of a configuration parameter (see 11A.2.2.1) is not the
30
31 same as the value in either a Peer Link Open frame or a Peer Link Confirm frame received earlier when
32 establishing the link instance.
33
34 The OPN_IGNR event shall be triggered if the Peer Link Open frame contains a mismatched instance iden-
35 tifier.
36
37
38 If the MP has local information of peerLinkID and the value does not match the value in the Local Link ID
39 field of the Peer Link Open frame, the instance identifier is a mismatch.
40
41 In other cases, the OPN_ACPT event shall be triggered. The link state is updated to include the link instance
42
43 identifier and other information from Mesh Configuration element.
44
45 11A.2.2.4 Process Peer Link Confirm frames
46
47 The CNF_RJCT event shall be triggered if the Peer Link Confirm frame contains an unacceptable or errone-
48
49 ous configuration parameter (see 11A.2.2.1) or the value of a configuration parameter (see 11A.2.2.1) is not
50 the same as the value from a frame (either a Peer Link Open frame or a Peer Link Confirm frame) received
51 earlier during the link instance establishment attempt.
52
53 The CNF_IGNR event shall be triggered if the Peer Link Confirm frame contains a mismatched instance
54
55 identifier.
56
57 The instance identifier in the frame is a mismatch if:
58
59
— the value in the Peer Link ID field of the frame does not match the local state of localLinkID.
60 — the value in the Local Link ID field of the frame does not match the local state of peerLinkID,
61 excluding the case that the peerLinkID value is unknown.
62
63
64 In other cases, the CNF_ACPT event shall be triggered. The link state is updated to include the link instance
65 identifier and other information from Mesh Configuration element.

IEEE P802.11s/D1.05, June 2007
1 11A.2.3 Finite State Machine

2
3
4 11A.2.3.1 States
5
6 The finite state machine uses the following seven states:
7
8 a) IDLE – In the IDLE state, the finite state machine only responses to events generated by IEEE
9 802.11 SME (see 11A.2.3.2). Other types of events are silently ignored. IDLE state is a terminal
10 state. The IDLE state is for explanatory purpose, which enables complete specification of the finite
11
state machine to avoid deadlock and livelock. It is not mandatory to implement the IDLE state.
12
13 b) LISTEN – In the LISTEN state, the finite state machine is passively listening for an incoming Peer
14 Link Open frame from a candidate peer MP.
15
16 c) OPN_SNT – In the OPEN_SENT state, the finite state machine has actively sent a Peer Link Open
17 frame and is waiting for the incoming Peer Link Open and Peer Link Confirm frames from the can-
18 didate peer MP.
19
20 d) CNF_RCVD – In the CNF_RCVD state, the finite state machine has received a Peer Link Confirm
21 frame, but has not received a Peer Link Open frame; therefore the MP has not sent the corresponding
22
Peer Link Confirm frame.
23
24 e) OPN_RCVD – In the OPEN_RCVD state, the finite state machine has received only the Peer Link
25 Open frame but not the Peer Link Confirm. The MP has also sent a Peer Link Confirm frame upon
26
27 receiving a Peer Link Open frame.
28 f) ESTAB – In the ESTAB state, the finite state machine has received both the Peer Link Open and
29 Peer Link Confirm frames. The MP has also sent both the Peer Link Open frame and Peer Link Con-
30
31 firm frame. The link is established and configured for exchanging frames with peer MPs in the
32 ESTAB state.
33
g) HOLDING − In the HOLDING state, the finite state machine is closing the link with the peer MP or
34
35 the candidate peer MP.
36
37 11A.2.3.2 Events and Actions
38
39
40 The finite state machine uses three types of events: events created by IEEE 802.11 SME, external events
41 generated by frame processing, and events associated internal timers.
42
43
44 IEEE 802.11 SME uses the following primitives to pass events to the finite state machine.
45 a) CNCL -- MLME-CancelPeerLink.request(localLinkID, ReasonCode) event is used to instruct the
46
link instance to cancel the link with the peer MP. The link instance uses MLME-CancelPeer-
47
48 Link.confirm(localLinkID, ResultCode) primitive to return the result to IEEE 802.11 SME.
49 b) PASOPN -- MLME-PassivePeerLinkOpen.request event is used to instruct the link instance to pas-
50
51 sively listen to a peer link establishment frame from a candidate peer MP. The link instance uses
52 MLME-PassivePeerLinkOpen.confirm(localLinkID) to return the result to IEEE 802.11 SME.
53 c) ACTOPN -- MLME-ActivePeerLinkOpen.request(peerMAC) event is used to instruct the link
54
55 instance to actively initiate the peer link establishment with the candidate peer MP whose MAC
56 address is peerMAC. The link instance uses MLME-ActivePeerLinkOpen.confirm(peerMAC,
57 localLinkID) primitive to return the result to IEEE 802.11 SME.
58
59
60 The events generated by frame processing are
61 a) CLS_ACPT -- PeerLinkClose_Accept(peerMAC, localLinkID, peerLinkID, reasonCode) event
62
indicates that a Peer Link Close frame meeting the correctness criteria of 11A.2.2.2 has been
63
64 received from peerMAC for the link instance identified by localLinkID and peerLinkID. The rea-
65 sonCode specifies the reason that causes the generation of the Peer Link Close frame.

IEEE P802.11s/D1.05, June 2007
1 b) CLS_IGNR -- PeerLinkClose_Ignore(peerMAC, localLinkID, peerLinkID) event indicates that a

2 Peer Link Close frame with mis-matched link identifiers, as specified in 11A.2.2.2, has been
3
received from peerMAC for the link instance identified by localLinkID and peerLinkID.
4
5 c) OPN_ACPT -- PeerLinkOpen_Accept(peerMAC, peerLinkID, Configuration) event indicates that a
6 Peer Link Open frame meeting the correctness criteria of 11A.2.2.3 has been received from
7
peerMAC for the link instance identified by localLinkID and peerLinkID. The Configuration is the
8
9 set of information received in the Mesh Configuration information element.
10 d) OPN_IGNR -- PeerLinkOpen_Ignore(peerMAC, peerLinkID) event indicates that a Peer Link Open
11
frame with mismatched link identifiers, as specified in 11A.2.2.3, has been received from peerMAC
12
13 for the link instance identified by locakLinkID and peerLinkID.
14 e) OPN_RJCT -- PeerLinkOpen_Reject(peerMAC, peerLinkID, Configuration, ReasonCode) event
15
indicates that a Peer Link Open frame with an invalid Configuration field, as specified in 11A.2.2.3,
16
17 has been received from peerMAC for the link instance identified by localLinkID and peerLinkID.
18 The Configuration is the set of information as received from Mesh Configuration element. The Rea-
19 sonCode is set to MESH-CONFIGURATION-POLICY-VIOLATION.
20
21 f) CNF_ACPT -- PeerLinkConfirm_Accept(peerMAC, localLinkID, peerLinkID, Configuration)
22 event indicates that a Peer Link Confirm frame meeting the correctness criteria of 11A.2.2.4 has
23 been received from peerMAC for the link instance identified by localLinkID and peerLinkID. The
24 Configuration is the set of information as received from Mesh Configuration element.
25
26 g) CNF_IGNR -- PeerLinkConfirm_Ignore(peerMAC, localLinkID, peerLinkID) event indicates that a
27 Peer Link Confirm frame with mis-matched link identifiers, as specified in 11A.2.2.4, has been
28 received from peerMAC for the link instance identified by localLinkID and peerLinkID.
29
30 h) CNF_RJCT -- PeerLinkConfirm_Reject(peerMAC, localLinkID, peerLinkID, Configuration, Rea-
31 sonCode) event indicates that a Peer Link Confirm frame with an invalid Configuration fields, as
32 specified in 11A.2.2.4, has been received from peerMAC for the link instance identified by localL-
33
inkID and peerLinkID. The Configuration is the set of information as received from Mesh Configu-
34
35 ration element. The ReasonCode is set to MESH-CONFIGURATION-POLICY-VIOLATION. This
36 event is denoted as.
37
38 The internal events are as follows. The term Timeout(localLinkID, item) represents a timeout identified
39
40 locally by item, for the link instance identified by localLinkID. Three types of timers are used by the finite
41 state machine. The retryTimer triggers a re-send of the Peer Link Open frame when a Peer Link Confirm
42 frame was not received as a response.
43
44 a) TOR1 – This event refers to Timeout(localLinkID, retryTimer) and the dot11MeshMaxRetries
45 has not been reached. The state machine shall resend the Peer Link Open frame.
46 b) TOR2 – This event refers to Timeout(localLinkID, retryTimer) and the dot11MESHMaxRetries
47
48 has been reached. The link instance shall be closed when TOR2 occurs.
49 c) TOC – The Timeout(localLinkID, confirmTimer) event. The confirmTimer aborts a link establish-
50 ment attempt if a Peer Link Open frame never arrives after receiving the Peer Link Confirm frame.
51
52 TOC event occurs, the link instance shall be closed.
53 d) TOH event – The Timeout(localLinkID, holdingTimer) event. The holdingTimer allows a grace
54 period for closing the link instance; it is necessary to avoid deadlocks and livelocks that arise due to
55
56 interactions between link establishment and termination. When TOH occurs, the link instance shall
57 be closed completely and the finite state machine shall transition to IDLE state.
58
59 The finite state machine may take an action triggered by an event. It uses two types of actions: sending a
60 peer link management frame and handling a timer.
61
62 Actions related to sending a peer link management frame:
63
64 a) sndOPN -- The sendOpen(peerMAC, localLinkID, Configuration) is the action that the link instance
65 takes to send a Peer Link Open frame to the candidate peer MP, whose MAC address is peerMAC.

IEEE P802.11s/D1.05, June 2007
1 The frame shall carry localLinkID and the supported Mesh Configuration, as specified as Configura-
2 tion.
3
4 b) sndCNF -- The sendConfirm(peerMAC, localLinkID, peerLinkID, Configuration) is the action that
5 the link instance takes to send a Peer Link Confirm frame to the candidate peer MP, whose MAC
6 address is peerMAC. The frame shall carry localLinkID, peerLinkID, and the supported Mesh Con-
7 figuration, as specified as Configuration.
8
9 c) sndCLS -- The sendClose(peerMAC, localLinkID, peerLinkID, reasonCode) is the action that the
10 link instance takes to send a Peer Link Close frame to the peer MP or candidate peer MP, whose
11 MAC address is peerMAC. The frame shall carry localLinkID and peerLinkID. If the peerLinkID is
12
unknown, it shall be set to zero. The reasonCode shall specify the reason that the Peer Link Close is
13
14 sent, whose value shall be set to a value between 46 to 51 as specified in Table 7.22.
15 The actions on handling timers are setTimer(localLinkID, item, value) and clearTimer(localLinkID, item).
16
17 a) The setTimer(localLinkID, item, timeout) action sets the timeout value specified by timeout to the
18 timer specified by item. This action only sets the timer for one time for the link instance identified
19
by localLinkID. When the timeout time has passed, the timer expires and the event Timeout(localL-
20
21 inkID, item) is triggered, after which the timer is no longer in effect.
22 The corresponding actions are denoted as setR, setC, setH, for timer retryTimer, confirmTimer,
23 holdingTimer respectively.
24
25 Before setting the retryTimer, the finite state machine shall apply the default link open request back-
26 off algorithm to compute the updated timeout value as the following:
27
28 timeout = return timeout + (getRandom mod timeout),
29
where getRandom routine generates a random value. The initial value of timeout shall be set to
30
31 dot11MeshRetryTimeout. This function statistically increases the length of time for each Peer
32 Link Open retry by 50%. The backoff was inserted into the design to recover from a “gold rush”,
33 which could happen if several already-linked MPs simultaneously detected a new MP trying to enter
34 the mesh network.
35
36 b) The clearTimer(localLinkID, item) action clears the timer item for the link instance identified by
37 localLinkID. The corresponding actions are denoted as clR, clC, clH, for timer retryTimer, confirm-
38 Timer, holdingTimer respectively.
39
40
41 NOTE -- The value of dot11MeshMaxRetries is under study. If zero is the appropriate value, the back-
42 off algorithm is not need and will be removed.
43
44 11A.2.3.3 State transitions
45
46
47 Table s41 and Figure s68 summarize the state transitions for the peer link management protocol.
48
49 In Table s41, each row represents state transitions from the state to all other states. The blank entry means
50 impossible transition.
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 Table s41—Peer Link Management Finite State Machine

2
3
4 To State
5
6 IDLE LISTEN OPN_SNT CNF_RCVD OPN_RCVD ESTAB HOLDING
7
8 IDLE PASOPN/ -- ACTOPN/
9 (sndOPN,
10 setR)
11
12 LISTEN CNCL / -- ACTOPN/ OPN_ACPT/
13 (sndOPN, (sndOPN, snd-
14 setR) CNF, setR)
15 OPN_SNT TOR1/ CNF_ACPT/ OPN_ACPT/ CLS_ACPT,
16 (sndOPN, (clR, setC) (sndCNF) OPN_RJCT,
17 setR) CNF_RJCT,
18 TOR2, CNCL/
19 (sndCLS, clR,
20 setH)
21
22 CNF_RCVD CNF_ACPT / - OPN_ACPT / CLS_ACPT,
23 - (clC, sndCNF) OPN_RJCT,
24 CNF_RJCT,
25
From State
CNCL/ (snd-
26 CLS, clC,
27 setH)
28 TOC / (snd-
29 CLS, setH)
30
31 OPN_RCVD TOR1 / CNF_ACPT / CLS_ACPT,
32 (sndOPN, clR OPN_RJCT,
33 setR) CNF_RJCT,T
34 OR2, CNCL/
35 (sndCLS, clR,
36 setH)
37
38 ESTAB OPN_ACPT / CLS_ACPT,
39 sndCNF OPN_RJCT,
40 CNF_RJCT,C
41 NCL/ (snd-
42 CLS, setH)
43
44 HOLDING TOH, OPN_ACPT /
45 CLS_ACPT / - sndCLS
46 -
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 In Figure s68, each arrow represents a state transition. All other events not shown in Figure s68 indicates
2 that no action causes the state transition.
3
4
5 IDLE
6
7 TOH, CLS_ACPT / --
8
9
PASOPN/--
CNCL/--
10
11
12
13
14
15
LISTEN
16
ACTOPN /
17 (sndOPN, setR)
18
19
) N,
20
AC
etR O P
TO
, s snd
21
PN
22 NF / (
dC T
/(
sn ACP
sn
23
dO
N_
24
PN
TOR1 / (sndOPN, setR)
OP
TOR1 / (sndOPN, setR)
,s
25
et
R)
26
27
OPN_ACPT / sndCNF
28 OPN_RCVD OPN_SNT
29
30
31
32 CNF_ACPT /
33 CNF_ACPT / clR (clR, setC)
OPN_ACPT /
34 sndCNF CNF_ACPT / --
35
36
37 OPN_ACPT / (clC, sndCNF)
ESTAB CNF_RCVD
38
39
40
/
CL
41
CL
CLS_ACPT, CLS_ACPT,
CN
S_
42 OPN_RJCT, OPN_RJCT,
T,
AC
CNF_RJCT, CNF_RJCT,
set RJC
43
)
setH
PT
TOR2, CNCL / TOR2, CNCL /

44
lC, NF_
H)
, O (sn
(sndCLS, clR, (sndCLS, clR,

,
45
PN dCL
CLS
setH) setH)
LS , C
_ R S,
46
dC JCT
( snd
,c
JC se
47
(sn N_R
T, t H)
/
CN
48
TOC
OP
F_
49
P t,
RJ
AC
50
CT
S_
51
, CN
CL
52
CL
53
/
54
55 HOLDING
56
57 OPN_ACPT /
58 sndCLS
59
60
61 Figure s68—Finite State Machine of Peer Link Management Protocol
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1 The event/action representation is defined as the following. “E/A” string represents that the action A is taken
2 given that the event E occurs. “E1, E2/A” string represents that the action A is taken given that the event E1
3
or event E2 occurs. “E/(A1, A2)” string represents that the action A1 and A2 are taken at a time when event
4
5 E occurs.
6
7 Note that Table s41 and Figure s68 are used for illustration purpose. The protocol behavior is in the follow-
8 ing subclauses.
9
10
11 11A.2.3.4 IDLE state
12
13 In the IDLE state the state machine shall not respond to incoming frames from a candidate peer MP.
14
15
16 When PASOPN event occurs, the link instance shall record information in Configuration, generate a new
17 link identifier localLinkID, initiate the retryCounter to zero, and begin listening for a Link Open frame. The
18 link instance shall issue MLME-PassivePeerLinkOpen.confirm(localLinkID) to return the result to IEEE
19 802.11 SME. The finite state machine transitions to LISTEN state.
20
21
22 When ACTOPN event occurs, The link instance shall encode the link information in the Mesh Configura-
23 tion element, generate a new link identifier localLinkID, initiate the retryCounter to zero, and send a Peer
24 Link Open frame to the candidate peer MP whose address is peerMAC. The retryTimer is set according to
25
26
retryTimeout. The MP uses MLME-ActivePeerLinkOpen.confirm(peerMAC, localLinkID) to return the
27 result to IEEE 802.11 SME. The finite state machine transitions to OPEN_SENT state.
28
29 All other events shall be ignored in this state.
30
31
32 11A.2.3.5 LISTEN state
33
34 In the LISTEN state, the link instance waits for unsolicited Link Open frames.
35
36
37 When a CNCL event occurs, the state machine transitions to IDLE state. The link instance shall use the
38 MLME-SignalPeerLinkStatus.indication(localLinkID, MESH-LINK-CLOSED) primitive to report the
39 result to the IEEE 802.11 SME.
40
41
42 When an ACTOPN event occurs, the link instance shall send a Peer Link Open frame to the candidate peer
43 MP identified by peerMAC. The Peer Link Open frame shall contain the localLinkID and Mesh Configura-
44 tion information. The retryTimer is set according to dot11MeshRetryTimeout. The finite state
45 machine transitions to OPEN_SENT state.
46
47
48 When a CLS_ACPT event occurs, the finite state machine transitions to IDLE state. The link instance shall
49 use the MLME-SignalPeerLinkStatus.indication(localLinkID, MESH-LINK-CLOSED) primitive to report
50 the result to the IEEE 802.11 SME.
51
52
53 When an OPN_ACPT event occurs, the link instance shall send the corresponding Peer Link Confirm frame
54 to respond to the Peer Link Open frame. And it shall send a Peer Link Open frame to request a Peer Link
55 Confirm frame from the candidate peer MP. The retryTimer is set according to
56 dot11MeshRetryTimeout value. The finite state machine transitions to OPEN_RCVD state.
57
58
60
61 11A.2.3.6 OPEN_SENT state
62
63
64 In the OPEN_SENT state, the link instance waits for a Peer Link Confirm frame. In this state, the retryTimer
65 is set.

IEEE P802.11s/D1.05, June 2007
1 When a CNCL event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with reason
2 code MESH-LINK-CANCELLED, and set the holdingTimer according to the value of
3
dot11MeshHoldingTimeout. The finite state machine transitions to HOLDING state.
4
5
6 When a CLS_ACPT event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with rea-
7 son code MESH-CLOSE-RCVD, and set the holdingTimer according to the value of
8
9 dot11MeshHoldingTimeout. The finite state machine transitions to HOLDING state.
10
11 When an OPN_ACPT event occurs, the MP shall send the corresponding Peer Link Confirm frame to
12 respond to the incoming Peer Link Open frame. The finite state machine transitions to OPN_RCVD state.
13
14 Note that the retryTimer is still in effect after the state transition.
15
16 When an OPN_RJCT event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with
17
18
reason code specified by the OPN_RJCT event, and set the holdingTimer according to the value of
20
21 When a CNF_ACPT event occurs, the MP shall clear the retryTimer and shall set the confirmTimer accord-
22
23 ing to the value of dot11MeshConfirmTimeout and the finite state machine transitions to CNF_RCVD
24 state.
25
26
27
When a CNF_RJCT event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with rea-
28 son code specified by the CNF_RJCT event, and set the holdingTimer according to the value of
30
31
32 When a TOR1 event occurs, the Peer Link Open frame shall be resent and the retryCounter shall be incre-
33 mented. The retryTimer shall be set according to the updated retryTimeout computed by the backoff algo-
34 rithm. No state transition occurs.
35
36
37 When a TOR2 event occurs, the MP shall send a Peer Link Close frame with reason code MESH-MAX-
38 RETRIES. The holdingTimer shall be set according to the value of dot11MeshHoldingTimeout, and
39 the finite state machine transitions to HOLDING state.
40
41
43
44
11A.2.3.7 CNF_RCVD state
45
46
47 In the CNF_RCVD state, the link instance has received a Peer Link Confirm frame and is waiting for a Peer
48 Link Open frame.
49
50
51 When a CNCL event occurs, the MP shall clear the confirmTimer, send a Peer Link Close frame with the
52 reason code MESH-LINK-CANCELLED, and set the holdingTimer according to the value of
53
54
55
56 When a CLS_ACPT event occurs, the MP shall clear the confirmTimer, send a Peer Link Close frame with
57 reason code MESH-CLOSE-RCVD, and set the holdingTimer according to the value of
58
60
61 When an OPN_ACPT event occurs, the MP shall clear the confirmTimer and shall send the corresponding
62
Peer Link Confirm frame to respond to the incoming Peer Link Open frame. The finite state machine transi-
63
64 tions to ESTAB state. The link instance shall use the MLME-SignalPeerLinkStatus.indication(localLinkID,
65 MESH-LINK-ESTABLISHED) primitive to report the result to the IEEE 802.11 SME.

IEEE P802.11s/D1.05, June 2007
1 When an OPN_RJCT event occurs, the MP shall clear the confirmTimer, send a Peer Link Close frame with
2 reason code as specified by the OPN_RJCT event, and set the holdingTimer according to the value of
3
4
5
6 When a CNF_RJCT event occurs, the MP shall clear the confirmTimer, send a Peer Link Close frame with
7 reason code as specified by the CNF_RJCT event, and set the holdingTimer according to the value of
8
9
10
11 When TOC event occurs, the MP shall send a Peer Link Close frame with reason code MESH-CONFIRM-
12 TIMEOUT and set the holdingTimer according to the value of dot11MeshHoldingTimeout. The finite
13
14 state machine transitions to HOLDING state.
15
17
18
19 11A.2.3.8 OPEN_RCVD state
20
21
22 In the OPEN_RCVD state, the link instance has received a Peer Link Open frame and sent a Peer Link Open
23 frame and the corresponding Peer Link Confirm frame. An incoming Peer Link Confirm is expected.
24
25
When a CNCL event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with reason
26
27 code MESH-LINK-CANCELLED, and set the holdingTimer according to the value of
29
30
31 When a CLS_ACPT event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame, and set
32 the holdingTimer according to the value of dot11MeshHoldingTimeout. The finite state machine tran-
33 sitions to HOLDING state.
34
35
36 When an OPN_ACPT event occurs, the MP shall resend the corresponding Peer Link Confirm frame. No
37 state transition occurs.
38
39
40
When an OPN_RJCT event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with
41 reason code as specified by the OPN_RJCT event, and set the holdingTimer according to the value of
43
44
45 When a CNF_ACPT event occurs, the retryTimer shall be cleared. The finite state machine transitions to
46 ESTAB state. The MP invokes the MLME-SignalPeerLinkStatus.indication(localLinkID, MESH-LINK-
47 ESTABLISHED) to report the result to the IEEE 802.11 SME.
48
49
50 When a CNF_RJCT event occurs, the MP shall clear the retryTimer, send a Peer Link Close frame with rea-
51 son code as specified by the CNF_RJCT event, and set the holdingTimer according to the value of
53
54
55 When a TOR1 event occurs, the Peer Link Open frame shall be resent and the retryCounter shall be incre-
56 mented. The retryTimer shall be set according to the updated retryTimeout computed by the backoff algo-
57 rithm. No state transition occurs.
58
59
60 When a TOR2 event occurs, the MP shall send a Peer Link Close frame with reason code MESH-MAX-
61 RETRIES. The holdingTimer shall be set according to the value of dot11MeshHoldingTimeout, and
62 the finite state machine transitions to HOLDING state.
63
64

IEEE P802.11s/D1.05, June 2007
1 11A.2.3.9 ESTAB state

2
3
4 In the ESTAB state, the link instance has been successfully established with the peer MP.
5
6 When a CNCL event occurs, the MP shall send a Peer Link Close frame with reason code MESH-LINK-
7 CANCELLED, and set the holdingTimer according to the value of dot11MeshHoldingTimeout. The
8
9 finite state machine transitions to HOLDING state.
10
11 When a CLS_ACPT event occurs, the MP shall send a Peer Link Close frame with reason code MESH-
12 CLOSE-RCVD, and set the holdingTimer according to the value of dot11MeshHoldingTimeout. The
13
14 finite state machine transitions to HOLDING state.
15
16 When an OPN_ACPT event occurs, the MP shall respond again by resending the corresponding Peer Link
17 Confirm frame. No state transition occurs.
18
19
21
22
11A.2.3.10 HOLDING state
23
24
25 In HOLDING state, the MP is closing the link. The holdingTimer is in effect.
26
27
28 When a CLS_ACPT event occurs, the primitive MLME-SignalPeerLinkStatus.indication(localLinkID,
29 MESH-LINK-CLOSED) shall be used to report the result to the IEEE 802.11 SME. The finite state machine
30 transitions to IDLE state.
31
32
33 When an OPN_ACPT event occurs, the MP shall respond by resending the corresponding Peer Link Close
34 frame. No state transition occurs.
35
36 When a CFN_ACPT event occurs, the MP shall respond by resending the corresponding Peer Link Close
37
38 frame. No state transition occurs.
39
40 When a TOH event occurs, the primitive MLME-SignalPeerLinkStatus.indication(localLinkID, MESH-
41 LINK-CLOSED) shall be used to report the result to the IEEE 802.11 SME. The finite state machine transi-
42
43 tions to IDLE state.
44
45 All other events are ignored in this state.
46
47
48
49
50
51 11A.3 Mesh network channel selection
52
53
54 11A.3.1 General
55
56 An MP PHY shall select a channel in a controlled way such that it enables the formation of a mesh network
57 that coalesces to a unified channel for communication. The MP PHY shall establish links with neighbors
58
59
that match the Mesh ID and Mesh Profile and select its channel based on the highest channel precedence
60 value.
61
62 11A.3.2 Simple channel unification protocol
63
64
65 A separate instance of the simple channel unification protocol shall be used for each MAC+PHY.

IEEE P802.11s/D1.05, June 2007
1 An MP PHY shall periodically perform passive or active scanning to discover neighboring MPs. If an MP is
2 unable to detect neighbor MPs, it may adopt a Mesh ID from one of its profiles, select a channel for
3
operation, and select an initial channel precedence value. The initial channel precedence value shall be
4
5 initialized to a random value. The random value is a 31 bit number. The random value shall be selected in a
6 manner that minimizes the probability of MPs generating the same number, even when those MPs are
7 subjected to the same initial conditions. It is important that designers recognize the need for statistical
8 independence among the random number streams among MPs.
9
10
11 In the event that an MP’s PHY discovers a disjoint mesh, that is, the list of candidate peer MPs spans more
12 than one channel, the MP shall select the channel that is indicated by the candidate peer MP that has the
13 numerically highest channel precedence indicator (or the smallest MAC address in case multiple peer MPs
14 report the same numerically highest channel precedence indicator) to be the unification channel.
15
16
17 If the identified unification channel is different from the current operating channel of the MP PHY, the MP
18 shall execute the channel graph switch protocol described in 11A.3.3.
19
20 11A.3.3 Channel graph switch protocol
21
22
23 This subclause describes the procedure used for an MP to initiate switching of a unified channel graph to a
24 new channel, with a new channel precedence indicator. Due to the possibility of more than one MP of a
25 unified channel graph executing the channel graph switch protocol concurrently, this protocol includes a
26
27 mechanism to resolve such possible conflicts by introducing a Mesh Channel Switch timer (MCS timer) that
28 assures adequate time for the decision process of this protocol.
29
30 An MP that determines the need to switch the channel of its UCG shall transmit a Mesh Channel Switch
31 Announcement to announce this intent. The MP first chooses a Mesh Channel Switch wait time in the range
32
33
from 0 to 255, representing the time (in TUs) until the MP switches to the new channel. The MP sets the
34 MCS timer with this wait time and then sends a Mesh Channel Switch Announcement frame to each peer
35 MP to which a mesh link has been established in the unified channel graph, copying the value of the new
36 candidate channel and new candidate channel precedence indicator and setting the Channel Switch Count
37 field value to the chosen wait time.
38
39
40 If an MP receives a Mesh Channel Switch Announcement with a channel precedence value larger than the
41 current channel precedence value of the PHY on which the frame was received, the MP shall set an MCS
42 timer equal to the channel switch count value of the frame and then sends a Mesh Channel Switch
43 Announcement frame to each peer MP to which a mesh link has been established on the PHY, copying the
44
45
values from the received Mesh Channel Switch Announcement.
46
47 It is possible that more than one MP in the unified channel graph may independently detect the need to
48 switch channels and send separate Mesh Channel Switch Announcements. If an MP receives more than one
49 Mesh Channel Switch Announcement, it only acts upon the frame if the channel precedence value is larger
50
than the channel precedence value of a previously received Mesh Channel Switch Announcement frame. In
51
52 case a newly received Mesh Channel Switch Announcement frame has the same channel precedence value
53 as a previously received frame, the new frame is acted upon only if the source address is smaller than the
54 source address from the previously received frame. If the MP acts upon the newly received Mesh Channel
55 Switch Announcement frame, it updates its candidate channel and candidate channel precedence indicator,
56
sets its MCS timer to the channel switch count value of the frame and then sends a Mesh Channel Switch
57
58 Announcement frame to each peer MP to which a mesh link has been established on the PHY, copying the
59 values from the received Mesh Channel Switch Announcement frame.
60
61 If an MCS timer has been set on an MP, the MP shall not originate a new Mesh Channel Switch
62
Announcement frame during the duration of the MCS timer. When the MCS timer expires on an MP the MP
63
64 switches its PHY to the candidate channel and updates its channel precedence indicator to the candidate
65 channel precedence indicator.

IEEE P802.11s/D1.05, June 2007
1 11A.4 Mesh link security

2
3
4 11A.4.1 Overview of MSA
5
6 Mesh security association (MSA) services are used to permit establishment of link security between two MPs
7 in a wireless mesh network, and support both centralized and distributed authentication schemes. MSA ser-
8
vices are provided through the use of a mesh key hierarchy, a hierarchy of derived keys that is established
9
10 through the use of a PSK or when an MP performs IEEE 802.1X authentication.
11
12 The operation of MSA relies on mesh key holders, which are functions that are implemented at MPs within
13 the wireless mesh network. Two types of mesh key holders are defined: mesh authenticators (MAs) and mesh
14
15
key distributors (MKDs). A single MP may implement both MKD and MA key holders, or an MA or neither.
16
17 MSA requires information to be exchanged during an MP’s initial security association with an MA, and is
18 referred to as “Initial MSA Authentication.” Subsequent security associations to other MAs within the same
19 MKD domain (and the same mesh, as identified by the Mesh ID) may utilize the mesh key hierarchy that is
20
21 established during Initial MSA Authentication.
22
23 MSA provides mechanisms for secure communications between mesh key holders. The “Mesh Key Holder
24 Security Handshake” provides the mechanism for establishing a security association between an MA and
25
MKD. Secure mesh key transport protocols and an EAP message transport protocol are defined.
26
27
28 11A.4.1.1 Mesh key holders
29
30 Mesh key holders, MAs and MKDs, manage the mesh key hierarchy by performing key derivation and secure
31
32 key distribution. A mesh key distributor (MKD) domain is defined by the presence of a single MKD. Within
33 the MKD domain, several MAs may exist, each implemented at an MP, and each MA maintains both a path
34 to and a security association with the MKD. The MKD derives keys to create a mesh key hierarchy, and dis-
35 tributes derived keys to MAs.
36
37
38 An MP implementing the MA key holder function may play the IEEE 802.1X Authenticator role during an
39 MSA exchange (e.g., Initial MSA Authentication) as determined according to the procedures in 11A.4.1.3.
40 The MA receives derived keys from the MKD, and derives additional keys for use in securing a link with a
41 supplicant MP.
42
43
44 MSA assumes that the AS and MKD have a trustworthy channel between them that can be used to exchange
45 cryptographic keys without exposure to intermediate parties. The IEEE 802.1X AS never exposes the MSK
46 to any party except the MKD implementing the NAS Client functionality of the IEEE 802.1X Authenticator
47 with which the supplicant is communicating. The communication between AS and MKD is beyond the scope
48
of this standard.
49
50
51 An EAP transport mechanism is defined in 11A.4.5, and may be used to facilitate EAP authentication of MPs
52 by transporting EAP messages between an MA and MKD. An EAP transport mechanism is needed when an
53 MP implements the MA function, but not the MKD function. In addition to the EAP transport mechanism
54
55 defined in 11A.4.5, other mechanisms, such as vendor specific mechanisms, may be used to facilitate EAP
56 authentication. An EAP transport mechanism must satisfy the following requirements:
57 — The mechanism shall permit the MKD to provide a secure indication of the result of EAP authentica-
58
59
tion to the MA. Here, "secure" means the mechanism provides data origin authentication (of the
60 MKD) and message integrity.
61 — The mechanism shall explicitly identify the supplicant MP involved in EAP authentication during
62
the transport of an EAP message. In other words, since multiple supplicant MPs may be undergoing
63
64 EAP authentication through a single MA, the mechanism shall permit the MA and MKD to distin-
65 guish the transported EAP message using the identity of the supplicant MP.

IEEE P802.11s/D1.05, June 2007
1 11A.4.1.2 Discovery & MSA capability advertisement

2
3
4 The support of MSA is advertised by MPs in Beacon and Probe Response frames through the inclusion of
5 the MSCIE. Moreover, an MP that wants to utilize MSA to authenticate with other MPs shall advertise its
6 security policy by inserting an RSN information element into its Beacon frames and Probe Response frames.
7
8 The MSCIE shall be included in Beacon and Probe Response frames to advertise support for MSA and to
9
10 advertise the MKD domain identifier (MKDD-ID) and the Mesh Security Configuration. The value of
11 MKDD-ID that is advertised by the MP shall be the value received from the MKD during the mesh key
12 holder security handshake (as specified in 11A.4.3.2), or the value of dot11MeshKeyDistributorDomainID
13 if the MP implements the MKD function. An MP that has not yet received the MKDD-ID value shall set the
14 MKD domain ID field in the MSCIE to zero and shall set the Mesh Authenticator and Connected to MKD
15
16 bits of the Mesh Security Configuration field to zero.
17
18 The Mesh Security Configuration field in the Mesh security capability information element shall be set as
19 follows:
20
21 — Mesh Authenticator: The MP shall set this bit to 1 if the MP is configured to play the IEEE 802.1X
22 Authenticator role during an MSA handshake. The selection of the IEEE 802.1X Authenticator and
23 Supplicant roles is described in 11A.4.1.3.
24
25 — Connected to MKD: The MP shall set this bit to 0 if Mesh Authenticator is set to 0. Otherwise, the
26 MP shall set this bit to 1 if the MP has a security association with the MKD and has a valid path to
27 the MKD. If the MA and MKD are both implemented at the MP and Mesh Authenticator is set to 1,
28 the MP shall set this bit to 1.
29
30 — Default Role Negotiation: The MP shall set this bit to 1 if it uses the mesh default role determination
31 scheme specified in 11A.4.1.3. The MP shall set this bit to 0 if it uses some other role determination
32 scheme, such as a proprietary scheme. The specification of other schemes is beyond the scope of this
33 standard.
34
35
36 An MKD may support zero or more EAP transport mechanisms. An MA advertises the mechanisms support-
37 ed by the MKD with which it has a security association during the Initial MSA Authentication (using the EAP
38 Transport List optional parameter in the MSAIE).
39
40
41 11A.4.1.3 Role determination
42
43 The MSA Authentication mechanism assigns roles during peer link management to permit the MSA 4-way
44 handshake and, if required, 802.1X authentication. The procedure for determining 802.1X authenticator and
45
46 supplicant roles is given in 11A.4.2.2.
47
48 11A.4.1.4 Policy selection
49
50
An MP may initiate the link establishment mechanism defined in 11A.2. This mechanism leverages Peer
51
52 Link Open frames and Peer Link Close frames to exchange Peer Link Open and Peer Link Confirm informa-
53 tion elements.
54
55 If an IEEE 802.1X-based authentication is used, the MP playing the role of the IEEE 802.1X Supplicant shall
56
57 include an RSN information element in the Peer Link Confirm frame. In the RSN information element, the
58 Supplicant MP shall specify one pairwise ciphersuite and one AKM suite.
59
60 In a mesh, all STAs shall utilize the same group ciphersuite. Therefore, a Supplicant MP shall not send a Peer
61 Link Confirm frame, and the Authenticator MP shall reject Peer Link Open frames from the Supplicant (with
62
63 Status Code 41), if the group ciphersuite advertised by the Authenticator MP does not match its own.
64
65 The Authenticator MP shall reject the Peer Link Open frame from the Supplicant MP if either the pairwise

IEEE P802.11s/D1.05, June 2007
1 cipher suite (with Status Code 42) or AKM suite (with Status Code 43) selected by the Supplicant is not in-
2 cluded in the corresponding lists of pairwise ciphersuites and AKM suites specified in its own Beacon frames
3
and Probe Response frames. The Authenticator MP may also reject the Supplicant MP’s Peer Link Open
4
5 frame for other reasons unrelated to security. The Authenticator MP may accept the Peer Link Open frame if
6 the Supplicant selected pairwise and AKM suites from among those specified by the Authenticator in its Bea-
7 con frames and Probe Response frames.
8
9
The Supplicant MP shall additionally include an MSCIE in the Peer Link Open frame. The Authenticator MP
10
11 shall reject the Peer Link Open frame from the Supplicant MP if the MKDD-ID included in the MSCIE does
12 not match the value advertised by the Authenticator MP in its Beacon frames and Probe Response frames.
13
14 Selection of the EAP Transport mechanism to be used between an MP and MKD is performed during the
15
mesh key holder security handshake described in 11A.4.3.2. The MP shall decline to establish a mesh key
16
17 holder security association with the MKD if the EAP transport mechanisms supported by the MP and MKD
18 do not overlap.
19
20 11A.4.1.5 MSA authentication
21
22
23 Pre-RSNA authentication shall not be supported for mesh link establishment.
24
25 The MSA Authentication mechanism permits an MP to establish a secure link with a peer MP. The MSA
26 authentication mechanism may also comprise the authentication of an MP (such as through the use of
27
802.1X authentication) and the establishment of its mesh key hierarchy. This procedure, known as Initial
28
29 MSA Authentication, is required, for example, when an MP establishes its first peer link within an MKD
30 domain. On the establishment of subsequent links within the MKD domain, an MP’s execution of the MSA
31 authentication mechanism may utilize its mesh key hierarchy to omit the authentication and key establish-
32 ment steps.
33
34
35 Initial MSA Authentication is described in 11A.2.2.2.5. When Initial MSA Authentication occurs, and
36 IEEE 802.1X is selected, 8.4.5 specifies the authentication procedure. If pre-shared keys (PSKs) are selected
37 instead, then the key hierarchy is derived from the PSK.
38
39
The MSA Authentication mechanism includes an MSA 4-Way Handshake, as specified in 11A.2.2.2.6,
40
41 which establishes a PTK, and allows each MP to provide its GTK to the peer MP. After the MSA 4-Way
42 Handshake completes, either MP may initiate a Group Key Handshake (see 8.5.4) at any time during the
43 link’s lifetime, to update its GTK.
44
45
The MSA authentication mechanism, when Initial MSA Authentication is included, is shown in Figure s69,
46
47 with procedures specified in 11A.2.2.2.
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1
2
3
4
Mesh Mesh
5 Point Point
6
7
8 Peer Link Open Peer Link Open
9
10
11
12
13
14 Peer Link Confirm Peer Link Confirm
15
16
17
18
19 Initial MSA Authentication (e.g.,
20
21
EAP Authentication)
22
23 MSA 4-way Handshake #1
24
25
27
28
30
31
33
34
35
36
37
38
39
40 Figure s69—MSA Authentication Mechanism, including initial MSA Authentication
41
42
43
44
45 11A.4.1.6 Mesh key holder security handshake
46
47 The mesh key holder security handshake establishes a security association between an MP and an MKD, per-
48 mitting the MP to begin operating as an MA. The MP may initiate the mesh key holder security handshake
49 after it has completed Initial MSA Authentication. The mesh key holder security handshake is shown in
50
51 Figure s70, with procedures specified in 11A.4.3.
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30 Figure s70—Mesh key holder security handshake
31
32
33
34 11A.4.1.7 Mesh key and EAP message transport protocols
35
36
37 The mesh key transport protocol comprises three mechanisms for performing key delivery and key manage-
38 ment within a mesh key hierarchy.
39
40 The delivery pull protocol is initiated by the MA to request delivery of a PMK-MA, is shown in Figure s71,
41
42 and is specified in 11A.4.4.1.
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 Figure s71—Mesh key transport delivery pull protocol
26
27
28 The delivery push protocol is initiated by the MKD to deliver a PMK-MA, is shown in Figure s72, and is
29 specified in 11A.4.4.2.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55 Figure s72—Mesh key transport delivery push protocol
56
57
58 The key delete protocol is initiated by the MKD to revoke a PMK-MA, is shown in Figure s73, and is speci-
59 fied in11A.4.4.3.
60
61
62
63
64
65

IEEE P802.11s/D1.05, June 2007
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25 Figure s73—Mesh key delete protocol
26
27
28 The EAP message transport protocol may be initiated by the MA to facilitate EAP authentication with the
29 supplicant during a supplicant MP’s Initial MSA Authentication. The protocol permits an EAP message re-
30 ceived from the supplicant to be transported from MA to MKD, and permits EAP messages received from the
31
32 authentication server to be transported from MKD to MA.
33
34 A single request/response EAP message transport frame exchange is shown in Figure s74. The authentication
35 of a supplicant typically requires several such exchanges. The protocol is specified in 11A.4.5.
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62 Figure s74—EAP message transport protocol (single exchange)
63
64
65

IEEE P802.11s/D1.05, June 2007
1 11A.4.1.8 Secure link operation

2
3
4 In the case when the 4-Way Handshake completes successfully, then both the IEEE 802.1X Authenticator
5 and Supplicant shall open their respective controlled ports, to permit data traffic to be exchanged using the
6 selected ciphersuites.
7
8
When key management completes, each MP further uses the session key to protect the contents of mesh
9
10 action data units using the agreed upon ciphersuites. Each MP permits MPDUs protected by the session key
11 and group key using the agreed upon ciphersuites and discards unprotected MPDUs that are received from
12 other MPs that have a secure link with the receiving MP.
13
14
15 11A.4.2 MSA establishment procedure
16
17 11A.4.2.1 General
18
19
20 MSA defines the following procedures for use within a mesh:
21
22 — MSA Authentication (11A.4.2.2) is used by an MP to securely establish links with peer MPs, and, if
23 required, to authenticate and establish the mesh key hierarchy that may be used when securing future
24 links.
25
26 — MSA Key Holder Communication comprises three related mechanisms:
27 • The procedure for establishing communications and a security association between an MA and
28
29 an MKD is the mesh key holder security handshake (11A.4.3).
30 • The mesh key transport protocol (11A.4.4) describes the mechanisms for key delivery and key
31 management within the mesh key hierarchy.
32
33 • The mesh EAP message transport protocol (11A.4.5) describes a mechanism for transporting
34 EAP messages between MKD and MA to facilitate authentication of a supplicant MP.
35
36 11A.4.2.2 MSA authentication mechanism
37
38
39 An MP uses the MSA authentication mechanism to establish a secure link with a peer MP. The mechanism
40 consists of the establishment of a peer link, in accordance with 11A.2, followed by an MSA 4-way hand-
41 shake, which is based on the 4-way handshake described in 8.5.3.
42
43
44 The MSA authentication mechanism may also comprise the authentication of an MP (such as through the
45 use of 802.1X authentication) and the establishment of its mesh key hierarchy. This procedure, known as
46
Initial MSA Authentication, is required, for example, when an MP establishes its first peer link within an
47
48 MKD domain. On the establishment of subsequent links within the MKD domain, an MP’s execution of the
49 MSA authentication mechanism may utilize its mesh key hierarchy to omit the authentication and key estab-
50 lishment steps.
51
52
53 During the peer link management portion of the MSA authentication mechanism, the exchanged information
54 determines whether Initial MSA Authentication will occur. If so, the authentication of the MP and establish-
55 ment of the mesh key hierarchy occurs after peer link management completes, but before the MSA 4-way
56 handshake begins. An MP indicates a request for Initial MSA Authentication by setting the “Requests
57
Authentication” bit in the MSAIE that is included in the peer link open message. An MP may request Initial
58
59 MSA Authentication during its first peer link within an MKD domain, but also to refresh its key hierarchy
60 due to, for example, its past or impending expiration.
61
62
Prior to beginning the MSA authentication mechanism, the MP determines if it is the Selector MP for the
63
64 duration of the protocol. The MP is the Selector MP if its MAC address is numerically larger than that of the
65 candidate peer MP.

IEEE P802.11s/D1.05, June 2007
1 11A.4.2.2.1 Peer Link Open message contents

2
3
4 An MP initiates the MSA authentication mechanism with a candidate peer MP by sending a peer link open
5 message to the candidate peer MP, in accordance with the peer link management procedure. In addition to
6 the peer link management element, which is set according to 11A.2, the peer link open message shall con-
7 tain:
8
9 — RSNIE, which shall be configured as advertised by the local MP in its Beacon frames and Probe
10 Response frames. However, the PMKID list field may contain the following entries, in the order
11
12
given:
13 • PMK-MAName(sender), the identifier of the currently-valid PMK-MA belonging to the key
14
hierarchy created by the local MP during a prior Initial MSA Authentication, that may be used to
15
16 secure a link with the peer MP. This entry shall be omitted if no currently valid PMK-MA exists,
17 or if the local MP requests Initial MSA Authentication.
18 • PMK-MAName(receiver), the identifier of a PMK-MA belonging to the key hierarchy created
19
20 by the peer MP during its Initial MSA Authentication. This entry is included only if a PMK-
21 MAName(sender) is included, and only if the MA function of the local MP has cached the iden-
22 tified PMK-MA that may be used to secure a link with the peer MP.
23
24 — MSCIE, configured exactly as advertised by the local MP in its Beacon frames and Probe Response
25 frames.
26
27 — MSAIE, where
28
• Requests Authentication subfield of the Handshake Control field shall be set to 1 if the local MP
29
30 requests Initial MSA Authentication during this MSA authentication mechanism. This subfield
31 shall be set to zero if the PMKID list field of the RSNIE contains one or more entries.
32 • Selected AKM Suite field shall be zero if the local MP is not the Selector MP. If it is the Selector
33
34 MP, the field shall indicate an AKM suite selected by the local MP.
35 • Selected Pairwise Cipher Suite field shall be zero if the local MP is not the Selector MP. If it is
36 the Selector MP, the field shall indicate a pairwise cipher suite selected by the local MP.
37
38 • PMK-MKDName shall be present if the RSNIE in this message contains a PMK-
39 MAName(sender) value in the PMKID list field. If present, it shall identify the PMK-MKD cre-
40 ated by the local MP during its prior Initial MSA Authentication.
41
42 • All other fields shall be set to zero.
43
44 11A.4.2.2.2 Processing Peer Link Open message
45
46
47 Upon reception of a peer link open message from a candidate peer MP that contains an MSAIE, the local
48 MP shall determine if it is the Selector MP. Further, the local MP shall:
49
50 — Verify that the “Default Role Negotiation” field included in the MSCIE of the peer link open mes-
51 sage is identical to the value included in the local MP’s MSCIE in Beacon frames and Probe
52 Response frames.
53
54 — Verify that the local MP supports the peer MP’s group cipher suite as indicated in the RSNIE
55 received in the peer link open message. Further, verify that the pairwise cipher suite list and AKM
56
57
suite list in the received RSNIE each contain at least one entry that is also supported by the local
58 MP.
59
— If the local MP is not the Selector MP, verify that the AKM suite and pairwise cipher suite selected
60
61 in the MSAIE are among those supported by the local MP.
62
— Verify that it wishes to establish a link with the peer MP that sent the peer link open message, based
63
64 on the policies advertised in the peer link open message, and, if present, the Selector MP’s choice of
65 AKM suite and pairwise cipher suite.

IEEE P802.11s/D1.05, June 2007
1 If any of these verifications fail, an OPN_RJCT event (see 11A.2.2.3) shall be triggered in order to close the
2 link, with a ReasonCode that describes the failed verification (for example, “Invalid Pairwise Cipher,” or
3
MESH-SECURITY-ROLE-NEGOTIATION-DIFFERS).
4
5
6 If the local MP has received a peer link confirm message from the candidate peer MP, it shall also verify
7 that:
8
9 — RSNIE is identical to the RSNIE included in the peer link confirm message received from the candi-
10 date peer MP, except the PMKID list.
11 — MSCIE is identical to the MSCIE included in the peer link confirm message received from the candi-
12
13 date peer MP.
14 — In the MSAIE, Handshake Control field is identical to that included in the received peer link confirm
15 message. If the candidate peer MP is the selector MP, the values in the Selected AKM Suite and
16
Selected Pairwise Cipher Suite fields are identical to the values received in peer link confirm mes-
17
18 sage.
19
20 If any of these verifications fail, an OPN_RJCT event (see 11A.2.2.3) shall be triggered in order to close the
21 link, with ReasonCode set to MESH-SECURITY-FAILED-VERIFICATION.
22
23
24 The local MP shall perform the key selection procedure based on the contents of the peer link open message.
25 The result of the procedure determines if a PMK-MA is available to be used to secure the link, or if Initial
26 MSA Authentication must occur. One of two PMK-MAs may be selected: PMK-MA(local) is a PMK-MA
27 belonging to the key hierarchy created by the local MP during its prior Initial MSA Authentication; PMK-
28
29 MA(peer) is a PMK-MA belonging to the key hierarchy created by the peer MP during its prior Initial MSA
30 Authentication.
31
32 The key selection procedure first determines if Initial MSA Authentication shall occur. No common PMK-
33 MA is available and Initial MSA Authentication shall occur if any of the following are true:
34
35 — The PMKID list entry in the received peer link open message is empty; or,
36
— The local MP requests authentication during this MSA authentication mechanism; or,
37
38 — No PMK-MA(local) is currently valid to secure the link with the candidate peer MP; or,
39
40
— The MKDD-ID values included in the received peer link open message and included by the local MP
41 in its Beacon frames and Probe Response frames are different.
42
43 Otherwise, the key selection procedure is given in Table s42.
44
45
46 The table input Valid-local-key is set to true if PMK-MAName(receiver), contained in the PMKID list field
47 in the RSNIE of the received peer link open message, identifies the PMK-MA belonging to the local MP’s
48 key hierarchy that is currently valid for securing the link with the peer MP; otherwise, and when there is
49 only one PMK-MAName entry, it is false.
50
51
52 The table input Cached-peer-key is set to true if the key named by PMK-MAName(sender), contained in the
53 PMKID list field in the RSNIE of the received peer link open message, is cached by the MA function of the
54 local MP and is currently valid for securing the link. Otherwise, it is false.
55
56 The “Connected to MKD” bits in the MSCIE, as in the local MP’s Beacon frames and Probe Response
57
58 frames, and as included by the peer MP in the peer link open message, are also inputs to the procedure. A
59 final input for the key selection procedure is the determination of whether the local MP is the Selector MP.
60
61 If the key selection procedure resulted in the choice of PMK-MA(peer), but the local MA function does not
62
have PMK-MA(peer) in its cache, then the MA shall contact the MKD and retrieve the selected key. The
63
64 MA shall use the PMK-MKDName value received in the peer link open message to identify the PMK-MA
65 to be retrieved.

IEEE P802.11s/D1.05, June 2007
1 Table s42—Key selection procedure

2
3
4 Cached- “Connected to MKD” of Local MP
5 Valid-
peer- is Selector Selected Key
6 local-key Peer MP Local MP
key MP?
7
8 False False 0 0 (any) No PMK-MA available (and no connec-
9 tion to MKD available): OPN_RJCT
10 event shall be triggered in order to close
11 the link, with ReasonCode set to MESH-
12 SECURITY-AUTHENTICATION-
13 IMPOSSIBLE.
14
15 False False 0 1 (any) PMK-MA(peer), identified by PMK-
16 MAName(sender) in the received mes-
17 sage, which the local MP must retrieve
18 from the MKD.
19
20 False False 1 0 (any) PMK-MA(local), the currently-valid
21 PMK-MA belonging to the key hierarchy
22 created by the local MP during a prior
23 Initial MSA Authentication, that may be
24 used to secure a link with the candidate
25 peer MP.
26
27 False False 1 1 True PMK-MA(peer), identified by PMK-
28 MAName(sender) in the received mes-
29 sage, which the local MP must retrieve
30 from the MKD.
31
False False 1 1 False PMK-MA(local), the currently-valid
32
PMK-MA belonging to the key hierarchy
33
created by the local MP during a prior
34
Initial MSA Authentication, that may be
35
used to secure a link with the candidate
36
peer MP.
37
38 False True (any) (any) (any) PMK-MA(peer), which is identified by
39 PMK-MAName(sender) in the received
40 message.
41
42 True False (any) (any) (any) PMK-MA(local), which is identified by
43 PMK-MAName(receiver) in the received
44 message.
45
46 True True (any) (any) True PMK-MA(peer), which is identified by
47 PMK-MAName(sender) in the received
48 message.
49
50 True True (any) (any) False PMK-MA(local), which is identified by
51 PMK-MAName(receiver) in the received
52 message.
53
54
55 If the key selection procedure resulted in an indication that Initial MSA Authentication shall occur, the
56
57 “Connected to MKD” bits contained in the received peer link open message and as set by the local MP in its
58 Beacon frames and Probe Response frames shall be examined. If both MPs have “Connected to MKD” bits
59 set to zero, an OPN_RJCT event (see 11A.2.2.3) shall be triggered in order to close the link, with Reason-
60
61 Code set to MESH-SECURITY-AUTHENTICATION-IMPOSSIBLE, since authentication cannot occur.
62
63
64 If the local MP has received a peer link confirm message from the candidate peer MP, the local MP shall
65 verify that the PMK-MAName value contained in the received peer link confirm message identifies the key

IEEE P802.11s/D1.05, June 2007
1 chosen by the key selection procedure, or is empty if Initial MSA Authentication shall occur. If the verifica-
2 tion fails, an OPN_RJCT event (see 11A.2.2.3) shall be triggered in order to close the link, with Reason-
3
Code set to MESH-SECURITY-FAILED-VERIFICATION.
4
5
6 Following the key selection procedure, the MP shall perform the 802.1X role selection procedure based on
7 the contents of the received peer link open message and its own configuration. If the “Default Role Negoti-
8 ation” bits sent by the peer MP in the peer link open message and as set by the local MP in its Beacon frames
9
10
and Probe Response frames are set to zero, the determination of 802.1X roles is outside the scope of this
11 standard. Otherwise, the following procedure indicates which node plays the 802.1X authenticator role; the
12 other MP is the 802.1X supplicant.
13
14 The inputs to the 802.1X role selection procedure are:
15
16 — The “Connected to MKD” bit in the MSCIE and the “Request Authentication” bit in the MSAIE,
17 both in the peer link open message received from the peer,
18
19 — The “Connected to MKD” bit in the MSCIE of the local MP’s Beacon frames and Probe Response
20 frames,
21 — Whether the local MP requests authentication during this MSA authentication mechanism, and
22
23 — Whether the local MP is the Selector MP.
24
25 The 802.1X role selection procedure is as follows:
26
27 — If neither MP has the “Connected to MKD” bit set to 1, then the 802.1X Authenticator is the Selector
28 MP.
29
30 — If only one MP has the “Connected to MKD” bit set to 1, then that MP is the 802.1X Authenticator.
31 — If both MPs have “Connected to MKD” bit set to 1, then:
32
33 • If both MPs request authentication during this handshake, then the 802.1X Authenticator is the
34 Selector MP.
35 • If neither MP requests authentication during this handshake, then the 802.1X Authenticator is the
36 Selector MP.
37
38 • Otherwise, the MP that requests authentication is the 802.1X Supplicant, and the other MP is the
39 802.1X Authenticator.
40
41 If the local MP has received a peer link confirm message from the candidate peer MP, the local MP shall
42
verify that the MA-ID value received in the peer link confirm message matches the result of the 802.1X role
43
44 selection procedure. If not, an OPN_RJCT event (see 11A.2.2.3) shall be triggered in order to close the link,
45 with ReasonCode set to MESH-SECURITY-FAILED-VERIFICATION.
46
47 The processing of the peer link open message is completed after the 802.1X roles are determined. The
48
OPN_ACPT event shall be generated to indicate successful message processing. On the OPN_ACPT event,
49
50 the peer link management messages are sent according to the peer link management procedures of 11A.2.
51
52 11A.4.2.2.3 Peer Link Confirm message contents
53
54
55 The peer link confirm message is sent according to the peer link management procedures of 11A.2. In addi-
56 tion to the peer link management element, the peer link confirm message shall contain:
57 — RSNIE, identical to the RSNIE included in the peer link open message sent by the local MP during
58
59
this protocol. If the local MP has not sent a peer link open message during this protocol, the RSNIE
60 is configured as advertised by the local MP in its Beacon frames and Probe Response frames. How-
61 ever, the PMKID list shall be empty if Initial MSA Authentication will occur; otherwise, it shall
62 contain the PMK-MAName identifying the PMK-MA chosen by the key selection procedure.
63
64 — MSCIE, identical to the MSCIE included in the peer link open message sent by the local MP during
65 this protocol. If the local MP has not sent a peer link open message during this protocol, the MSCIE

IEEE P802.11s/D1.05, June 2007
1 is configured exactly as advertised by the local MP in its Beacon frames and Probe Response
2 frames.
3
4 — MSAIE, where
5 • “Requests Authentication” in the Handshake Control field shall be set to 1 if the local MP
6
7
requests Initial MSA Authentication during this protocol.
8 • MA-ID is set to the MAC address of the 802.1X authenticator
9 • Selected AKM Suite and Selected Pairwise Cipher Suite shall be set using the following proce-
10 dure: If the local MP is the Selector MP but has not sent a peer link open message, the fields
11 shall contain the local MP’s selection of each suite from among those supported by both MPs.
12
13 Otherwise, the fields shall contain the suites chosen by the Selector MP in the MSAIE of the peer
14 link open message that it sent during this protocol.
15 • If Initial MSA Authentication will occur and if the local MP is the 802.1X authenticator, MKD-
16 ID shall be included in the Optional Parameters field, and shall contain the identifier of the MKD
17 with which the local MP’s MA has a security association.
18
19 • If Initial MSA Authentication will occur and if the local MP is the 802.1X authenticator, EAP
20 Transport List shall be included in the Optional Parameters field. If the local MP’s MA imple-
21 ments the MKD function, the EAP Transport List shall contain the list of transport types sup-
22 ported by the MKD. If the MKD function does not support external communication with other
23 MAs, the EAP Transport List shall contain the single entry 00-0F-AC:0. If the local MP’s MA
24
25 does not implement the MKD function, EAP Transport List shall contain the list that the local
26 MP received during its Initial MSA Authentication within the same MKD domain.
27 • If the local MP is the 802.1X authenticator, MKD-NAS-ID shall be included in the Optional
28 Parameters field. If the local MP implements the MKD function, MKD-NAS-ID shall contain
29
the value of dot11MeshMKDNASID. Otherwise, MKD-NAS-ID shall contain the value that the
30
31 local MP received during its Initial MSA Authentication within the same MKD domain.
32 • All other fields are set to zero.
33
34 11A.4.2.2.4 Processing Peer Link Confirm message
35
36
37 Upon reception of a peer link confirm message during the MSA authentication mechanism, an MP shall pro-
38 cess the security parameters of the message, as described here. If the local MP has received a peer link open
39 message from the candidate peer MP, the local MP shall:
40
41 — Verify that the MSCIE and the Handshake Control field of the MSAIE that were received in the peer
42 link confirm message are identical to those received from the candidate peer MP in the peer link
43 open message during this handshake.
44
45 — Verify that the contents of the PMKID list field of the RSNIE in the received message agree with the
46 local MP’s key selection procedure. Verify that the remaining fields of the RSNIE match those
47 received from the peer MP in its peer link open message during this handshake.
48
49
— Verify that the assertion of the 802.1X authenticator in the MA-ID field of the MSAIE is correct,
50 based on the role selection procedure.
51 — Verify that the selected AKM suite and pairwise cipher suite values contained in the MSAIE match
52
those chosen by the Selector MP in the MSAIE of the peer link open message that it sent during this
53
54 protocol.
55
56 If any of these message components are not verified, a CNF_RJCT event (see 11A.2.2.4) shall be triggered
57 in order to close the link, with ReasonCode set to MESH-SECURITY-FAILED-VERIFICATION.
58
59
60 On the other hand, if the local MP has not received a peer link open message from the candidate peer MP,
61 — The local MP shall verify that the selected AKM suite and pairwise cipher suite values contained in
62
the MSAIE are supported by the local MP. If not, a CNF_RJCT event (see 11A.2.2.4) shall be trig-
63
64 gered in order to close the link, with a ReasonCode that describes the failed verification (for exam-
65 ple, “Invalid Pairwise Cipher”).

IEEE P802.11s/D1.05, June 2007
1 — If the local MP is the selector MP, it shall verify that the selected AKM suite and pairwise cipher
2 suite values match its selections that have been sent to the candidate peer MP in the peer link open
3
message. If not, a CNF_RJCT event (see 11A.2.2.4) shall be triggered in order to close the link,
4
5 with ReasonCode set to MESH-SECURITY-FAILED-VERIFICATION.
6
7 Otherwise, the CNF_ACPT event shall be generated to indicate successful message processing.
8
9
10 11A.4.2.2.5 Initial MSA Authentication
11
12 If Initial MSA Authentication was negotiated during peer link management, authentication and establish-
13 ment of the 802.1X supplicant’s key hierarchy shall occur after peer link management completes. If the
14
15 negotiated AKM suite requires 802.1X authentication, it is initiated by the 802.1X authenticator MP. The
16 IEEE 802.1X exchange is sent between the 802.1X supplicant and the 802.1X authenticator using EAPOL
17 messages carried in IEEE 802.11 data frames. The 802.1X authenticator may transport the IEEE 802.1X
18 exchange to the MKD using the optional mesh EAP message transport protocol, as specified in 11A.4.5.
19
20
21 Upon successful completion of IEEE 802.1X authentication, the MKD receives the MSK and authorization
22 attributes associated with it and with the supplicant MP. If a mesh key hierarchy already exists for this sup-
23 plicant, the MKD shall delete the old PMK-MKD SA and PMK-MA SAs. It then generates the PMK-MKD
24 SA as well as a PMK-MA SA.
25
26
27 The MKD then delivers the PMK-MA to the MA using the mesh key distribution protocol defined in
28 11A.4.4. Once the PMK-MA is delivered, the MSA authentication mechanism proceeds with the MSA 4-
29 way handshake.
30
31
32 11A.4.2.2.6 MSA 4-way Handshake
33
34 Following peer link management and, if required, Initial MSA Authentication, the 802.1X authenticator ini-
35 tiates an MSA 4-way handshake. The EAPOL-Key frame notation is defined in 8.5.2.1.
36
37
38 Authenticator -> Supplicant: Data(EAPOL-Key(0, 0, 1, 0, P, 0, 0, MPTKANonce, 0,
39 DataKD_M1)) where DataKD_M1 = 0.
40
41
42 Supplicant -> Authenticator: Data(EAPOL-Key(0, 1, 0, 0, P, 0, 0, MPTKSNonce, MIC,
43 DataKD_M2)) where DataKD_M2 = (RSNIE, MSCIE, MSAIE, GTK KDE).
44
45 Authenticator -> Supplicant: Data(EAPOL-Key(1, 1, 1, 1, P, 0, 0, MPTKANonce, MIC,
46
47 DataKD_M3)) where DataKD_M3 = (RSNIE, MSCIE, MSAIE, GTK KDE, Lifetime KDE).
48
49 Supplicant -> Authenticator: Data(EAPOL-Key(1, 1, 0, 0, P, 0, 0, 0, MIC, DataKD_M4)) where
50 DataKD_M4 = 0.
51
52
53 The message sequence is similar to that of 8.5.3. The contents of each message shall be as described in
54 8.5.3, except as follows:
55
56 — Message 1: MPTKANonce is the value received by the Authenticator from the MKD during PMK-
57 MA delivery. The Key Data field is empty.
58
— Message 2: The RSNIE, MSCIE, and MSAIE shall be the same as those contained in the peer link
59
60 confirm message sent by the Supplicant. However, if Initial MSA Authentication occurred, the
61 RSNIE shall also contain the PMK-MAName in the PMKID list field of the RSNIE. The GTK KDE
62 shall contain the GTK of the supplicant MP. The Key Data field shall be encrypted.
63
64 — Message 3: The RSNIE, MSCIE, and MSAIE shall be the same as those contained in the peer link
65 confirm message sent by the Authenticator. However, if Initial MSA Authentication occurred, the

IEEE P802.11s/D1.05, June 2007
1 RSNIE shall also contain the PMK-MAName in the PMKID list field of the RSNIE. The Lifetime
2 KDE shall contain the lifetime of the PMK-MA.
3
4
5 The processing, upon reception, of Message 1 of the 4-way handshake shall be as described in 8.5.3.1 (fol-
6 lowing “Processing for PTK Generation”).
7
8 The processing of Message 2 is as described in 8.5.3.2 (following “Processing for PTK Generation”), except
9
10 that verification of the Message 2 MIC (step b) shall be as follows: If the calculated MIC does not match the
11 MIC that the Supplicant included in the EAPOL-Key frame, the Authenticator silently discards Message 2.
12 If the MIC is valid, the Authenticator checks that the RSNIE, excluding the PMKID Count and PMKID List
13 fields, bit-wise matches the RSNIE sent by the Supplicant in its peer link confirm message. Additionally, the
14 Authenticator checks that the MSCIE and MSAIE each bit-wise match those sent by the Supplicant in its
15
16 peer link confirm message. The Authenticator also unwraps the supplicant’s encrypted GTK. If any of
17 these comparisons fail, or if the unwrapping of the GTK failed, the Authenticator shall close the link.
18
19 The processing of Message 3 is as described in 8.5.3.3 (following “Processing for PTK Generation”), except
20
that step (a) is replaced with the following: Verifies that the RSNIE, excluding the PMKID Count and
21
22 PMKID List fields, bit-wise matches the RSNIE sent by the Authenticator in its peer link confirm message.
23 Additionally, the Supplicant checks that the MSCIE and MSAIE each bit-wise match those sent by the
24 Authenticator in its peer link confirm message. If any of these comparisons fail, the Authenticator shall
25 close the link.
26
27
28 The processing of Message 4 is as described as in 8.5.3.4 (following “Processing for PTK Generation”),
29 except that step (b) contains the following additional action: If the MIC is valid, the Authenticator uses the
30 MLME-SETKEYS.request primitive to configure the GTK received in Message 2 into the IEEE 802.11
31 MAC.
32
33
34 During processing of the 4-way handshake, the PTK shall be calculated by both MPs according to the proce-
35 dures given in 8.8.6.
36
37 Following a successful MSA 4-way handshake, the IEEE 802.1X controlled port shall be opened at both
38
39 MPs (for communication with the peer). Subsequent EAPOL-Key frames shall use the Key Replay Counter
40 to ensure they are not replayed. Messages protected with the PTK shall use the Pairwise cipher suite given in
41 the MSAIE of the peer link confirm messages exchanged as part of Initial MSA Authentication.
42
43
11A.4.2.3 MSA key holder communication
44
45
46 In order to support the mesh key hierarchy, mesh key holders shall communicate securely to provide the fol-
47 lowing services to MPs:
48
49 — transporting EAP traffic between key holders to permit a supplicant MP to perform 802.1X authenti-
50 cation, and
51
— securely delivering derived keys to facilitate the use of a derived key hierarchy.
52
53
54 An MP invokes the mesh key holder security handshake to establish a security association with a mesh key
55 distributor (MKD). The mechanism permits the MP to operate as a mesh authenticator (MA). Subsequently,
56 the MA advertises, in Beacon frames and Probe Response frames, its capability to authenticate MPs using the
57
58
mesh key hierarchy.
59
60 11A.4.3 Mesh key holder security association
61
62
A security association is established between an MA and MKD to provide secure communications between
63
64 these two key holders within a mesh. The mesh key holder security association is used to provide message
65 integrity and data origin authenticity in all messages passed between MA and MKD after the security associ-

IEEE P802.11s/D1.05, June 2007
1 ation is established. Further, it provides encryption of derived keys and key context during key delivery pro-
2 tocols. Establishing the mesh key holder security association begins with discovery of the MKD, followed
3
by a handshake initiated by the MA. The result of the security association is the pairwise transient key for
4
5 key derivation (MPTK-KD), used to provide the security services between MA and MKD.
6
7 11A.4.3.1 Mesh key distributor discovery
8
9
10 Prior to initiating the mesh key holder security handshake described in 11A.4.3.2, an MA shall obtain the ad-
11 dress of its MKD. If the MA is not also an MKD, it may obtain the MKD-ID address of its MKD from the
12 MSAIE conveyed in the Peer Link Confirm frame received during its initial MSA security association.
13
14
15 11A.4.3.2 Mesh key holder security handshake
16
17 The mesh key holder security handshake may commence after an MP has completed its Initial MSA Authen-
18 tication. This mechanism permits an “aspirant MA” to establish a security association with the MKD that
19
20 derived its PMK-MKD during Initial MSA Authentication. An “aspirant MA” is defined as an MP that has
21 completed Initial MSA Authentication with an MKD, and that will become an MA after completing the mesh
22 key holder security handshake with the same MKD.
23
24
The aspirant MA initiates the exchange by constructing mesh key holder security handshake message 1, and
25
26 sending the message to the MKD identified by the MKD-ID received in the Peer Link Confirm frame during
27 the aspirant MA’s Initial MSA Authentication. The aspirant MA selects an EAP Transport mechanism from
28 among those listed in the MSAIE received in the Peer Link Confirm frame during the aspirant MA’s Initial
29 MSA Authentication. The aspirant MA shall decline to establish a mesh key holder security association with
30
the MKD if the EAP transport mechanisms supported by the aspirant MA and MKD do not overlap, or if the
31
32 EAP Transport List received by the aspirant MA contains the single entry 00-0F-AC:0. The contents of hand-
33 shake message 1 are given in 11A.4.3.2.1.
34
35 Upon receiving handshake message 1, the MKD chooses MKD-Nonce, a value chosen randomly (see 8.5.7),
36
37 and computes the MPTK-KD using the MA-Nonce received in handshake message 1 and MKD-Nonce, as
38 specified in 8.8.8. The MKD verifies that it supports the selected EAP Transport mechanism; if not, the hand-
39 shake fails. The MKD sends handshake message 2, with contents as given in 11A.4.3.2.2. Upon receiving
40 handshake message 2, the aspirant MA computes the MPTK-KD, and sends handshake message 3, with con-
41 tents as given in 11A.4.3.2.3.
42
43
44 After completing the handshake, the aspirant MA sets both the “Mesh Authenticator” and “Connected to
45 MKD” bits to 1 in the MSCIE in its Beacon frames and Probe Response frames to advertise that it is config-
46 ured as a mesh authenticator that is connected to the MKD. The MSCIE shall contain the MKDD-ID that is
47
48 received from the MKD in mesh key holder security handshake message 2.
49
50 An MA shall maintain a mesh path to the MKD. If the mesh path is lost and cannot be repaired, the MA shall
51 set the “Connected to MKD” bit to 0 in the MSCIE. In such a case, the “Mesh Authenticator” bit may be set
52
to 1 to advertise the ability to act in the IEEE 802.1X Authenticator role using, for example, cached keys.
53
54 After the mesh path is re-established, the MA may again set the “Connected to MKD” bit to 1.
55
56 The MA and the MKD maintain separate key replay counters for sending messages providing mesh key trans-
57 port that are protected using the MPTK-KD. Immediately upon deriving the MPTK-KD, both the MKD and
58
59 MA shall reset their replay counters to zero.
60
61 11A.4.3.2.1 Mesh key holder security handshake message 1
62
63
64 Mesh key holder security handshake message 1 is a mesh key holder security establishment MSA mesh action
65 frame (see 7.4b.1.1) with the following contents:

IEEE P802.11s/D1.05, June 2007
1 The MAC address of the MKD shall be asserted in the DA field of the message header.
2
3
4
The MAC address of the aspirant MA shall be asserted in the SA field of the message header.
5
6 The Mesh ID information element shall contain the Mesh ID that the aspirant MA advertises in its Beacon
8
9
10 The MSCIE shall contain the value of MKDD-ID that was contained in the MSCIE received in the Peer Link
11 Confirm frame during the aspirant MA’s Initial MSA Authentication. The Mesh Security Configuration field
12 shall be set to zero.
13
14 The Key Holder Security field shall be set as follows:
15
16 — Handshake Sequence shall be set to 1.
17
— MA-Nonce shall be set to a value chosen randomly (see 8.5.7) by the aspirant MA, following the rec-
18
19 ommendations of 8.5.7.
20 — MKD-Nonce shall be set to zero.
21
22 — MA-ID shall be set to the MAC address of the aspirant MA.
23 — MKD-ID shall be set to the MAC address of the MKD.
24
25 — The Transport Type Selector field shall contain a single transport type selector (with format as given
26 in Figure s61). The specified transport type shall be from among those listed in the MSAIE received
27 in the Peer Link Confirm frame during the aspirant MA’s Initial MSA Authentication. The value 00-
28 0F-AC:0 shall not be specified.
29
30
31 The message integrity check field shall be omitted.
32
33 11A.4.3.2.2 Mesh key holder security handshake message 2
34
35
37 frame with the following contents:
38
39 The MAC address of the aspirant MA shall be asserted in the DA field of the message header.
40
41
42 The MAC address of the MKD shall be asserted in the SA field of the message header.
43
44 The Mesh ID information element shall contain the Mesh ID as configured in dot11MeshID.
45
46
47 The MSCIE shall contain the MKDD-ID as configured in dot11MeshKeyDistributorDomainID. The Mesh
48 Security Configuration field shall be set to zero.
49
51
53 — MA-Nonce, MA-ID, and MKD-ID shall be set to the values contained in handshake message 1.
54
55 — MKD-Nonce shall be set to a value chosen randomly (see 8.5.7) by the MKD, following the recom-
56 mendations of 8.5.7.
57
58 — The Transport Type Selector field shall be set to the value contained in handshake message 1 if and
59 only if the MKD supports the selected Transport Type. If the MKD does not support the selected
60 Transport Type, the MKD shall decline to send handshake message 2.
61
62
The message integrity check field shall contain a MIC. The 16-octet MIC shall be calculated using the
63
64 MKCK-KD, using the AES-128-CMAC algorithm (AES-128-CMAC is defined by FIPS SP800-38B), on
65 the concatenation in the following order, of:

IEEE P802.11s/D1.05, June 2007
1 — Aspirant MA MAC address

2
3 — MKD MAC address
4 — Contents of the Category field of the Mesh Key Holder security establishment MSA mesh action
5 frame.
6
7 — Contents of the Action Value field of the Mesh Key Holder security establishment MSA mesh action
8 frame.
9
10 — Contents of the Mesh ID information element, from the element ID to the end of the Mesh ID infor-
11 mation element.
12
13
— Contents of the MSCIE, from the element ID to the end of the MSCIE.
14 — Contents of the Key Holder Security field.
15
16
17
11A.4.3.2.3 Mesh key holder security handshake message 3
18
20 frame with the following contents:
21
22
23 The MAC address of the MKD shall be asserted in the DA field of the message header.
24
25 The MAC address of the aspirant MA shall be asserted in the SA field of the message header.
26
27
28 The Mesh ID information element shall contain the Mesh ID information element received in handshake mes-
29 sage 2.
30
31 The MSCIE shall contain the MSCIE received in handshake message 2.
32
33
36
37 — MA-Nonce, MKD-Nonce, MA-ID, MKD-ID, and Transport Type Selector shall be set to the values
38 contained in handshake message 2.
39
40
41 The message integrity check field shall contain a MIC. The 16-octet MIC shall be calculated using the
42 MKCK-KD, using the AES-128-CMAC algorithm (AES-128-CMAC is defined by FIPS SP800-38B), on
43 the concatenation in the following order, of:
44
45
— Aspirant MA MAC address
47
48 — Contents of the Category field of the Mesh Key Holder security establishment MSA mesh action
49 frame.
50 — Contents of the Action Value field of the Mesh Key Holder security establishment MSA mesh action
51
52 frame.
53 — Contents of the Mesh ID information element, from the element ID to the end of the Mesh ID infor-
54 mation element.
55
56 — Contents of the MSCIE, from the element ID to the end of the MSCIE.
57
58
— Contents of the Key Holder Security field.
59
60 11A.4.4 Mesh key transport protocol
61
62
The mesh key transport protocol describes the method by which the MKD securely transmits a derived PMK-
63
64 MA to an MA, along with key context and additional related information. An additional management proto-
65 col permits the MKD to request that the MA delete a key that has previously been delivered.

IEEE P802.11s/D1.05, June 2007
1 Three protocols are defined for mesh key delivery and management, each consisting of 2 messages. The pull
2 protocol is initiated by the MA by sending a request message, followed by the MKD delivering the PMK-
3
MA. The push protocol is initiated by the MKD delivering (unsolicited) the PMK-MA, followed by the MA
4
5 sending a confirmation message. Finally, the key delete protocol is initiated by the MKD by sending a mes-
6 sage requesting key deletion to the MA, followed by the MA sending a confirmation message.
7
8 The MA and MKD maintain separate key replay counters for use in these three protocols. In the pull protocol,
9
10
the MA’s key replay counter is used to protect the first message, which the MA sends. In both the push pro-
11 tocol and the key delete protocol, the MKD’s key replay counter is used to protect the first message, which
12 the MKD sends.
13
14 In each protocol, prior to sending the first message, the sender shall increment the value of its replay counter.
15
16 Upon receiving the first message, the recipient shall verify that the replay counter value contained in the first
17 message is a value not yet used by the sender in a first message. If the replay counter value has been previ-
18 ously used, the message shall be discarded. MA and MKD shall each maintain the state of two replay
19 counters: the counter used to generate a value for first messages that it sends, and a counter used to detect
20 replay in first messages that it receives.
21
22
23 Further, the second message of each protocol shall contain a replay counter value that equals the value in the
24 first message of the protocol, to permit matching messages within a state machine instance.
25
26
27
11A.4.4.1 Mesh key transport pull protocol
28
29 The key transport pull protocol is a two-message exchange consisting of a PMK-MA request message sent to
30 the MKD, followed by a key delivery sent to the MA. Both messages contain a MIC for integrity protection,
31 and the PMK-MA being delivered is encrypted.
32
33
34 Mesh key transport pull message 1 is a PMK-MA request MSA mesh action frame (see 7.4b.1.4). The MAC
35 address of the MKD shall be asserted in the DA field of the message header, and the MAC address of the MA
36 shall be asserted in the SA field of the message header. Prior to constructing the message, the value of the
37 MA’s replay counter associated with the MPTK-KD shall be incremented by 1.
38
39
40 The contents of the Mesh Key Transport Control field shall be as follows:
41
— Replay counter shall be set to the value of the MA’s replay counter.
42
43 — SPA shall be set to the MAC address of the MP that, during its Initial MSA Authentication, gener-
44 ated the mesh key hierarchy that includes the PMK-MA being requested
45
46 — PMK-MKDName shall be set to the identifier of the key from which the PMK-MA being requested
47 was derived.
48
49
— MPTKANonce shall be set to zero.
50
52 MKCK-KD, using the AES-128-CMAC algorithm (AES-128-CMAC is defined by FIPS SP800-38B) on the
53 concatenation in the following order, of:
54
55 — MA MAC address
56
57
— MKD MAC address
58 — Contents of the Category field of the PMK-MA request MSA mesh action frame.
59
60 — Action Value field of the PMK-MA request MSA mesh action frame, which contains the value
61 shown for “PMK-MA request” in Table s32.
62 — Contents of the Mesh Key Transport Control field.
63
64
65 Upon receiving message 1, the MKD shall verify the MIC, and shall verify that the Replay counter field con-

IEEE P802.11s/D1.05, June 2007
1 tains a value not previously used with the MPTK-KD in a first message sent by the MA. If verified, the MKD
2 may attempt to derive the PMK-MA for use between the MP identified by SPA and the MA that sent message
3
1, using the key identified by PMK-MKDName. Subsequently, the MKD constructs and sends message 2.
4
5
6 Mesh key transport pull message 2 is a PMK-MA delivery pull MSA mesh action frame (see 7.4b.1.5). The
7 MAC address of the MA shall be asserted in the DA field of the message header, and the MAC address of the
8 MKD shall be asserted in the SA field of the message header.
9
10
12 — Replay counter shall be set to the value of replay counter in message 1.
13
14 — SPA shall be set to the value contained in message 1.
15 — PMK-MKDName shall be set to the value contained in message 1 if an encrypted PMK-MA is
16
17 included in the Mesh Wrapped Key field. If the PMK-MA is omitted, then PMK-MKDName shall
18 be set to zero.
19 — MPTKANonce shall be set to the pseudo-random value that was selected by the MKD for derivation
20
21 of the PMK-MKDName that was indicated in message 1. If the PMK-MKDName field is set to
22 zero, then the MPTKANonce shall be set to zero.
23
24 The contents of the Mesh Wrapped Key field shall be as follows:
25
26 — Wrapped Context Length field shall be set to the length in octets of the Wrapped Context field, or
27 shall be set to zero if the Wrapped Context field is omitted.
28
— Wrapped Context shall be set as follows:
29
30 • If the MKD does not have a PMK-MA to send to the MA (e.g., it was unable to derive the key),
31 the Wrapped Context field shall be omitted.
32
• If the MKD is sending a PMK-MA to the MA, then the Wrapped Context field shall contain the
33
34 concatenation: key_data = {PMK-MA || PMK-MAName || Lifetime KDE}.
35 •Lifetime KDE is defined in Figures 143 and 149. The KDE contains a 4-octet value containing
36 the number of seconds remaining in the lifetime of the PMK-MA.
37 •The concatenation key_data shall be wrapped using NIST AES Key Wrap algorithm, with the
38
39 MKEK-KD, as defined in RFC 3394, prior to being inserted in the Wrapped Context field.
40
44
46
47
— MKD MAC address
48 — Contents of the Category field of the PMK-MA delivery pull MSA mesh action frame.
49
50 — Action Value field of the PMK-MA delivery pull MSA mesh action frame, which contains the value
51 shown for “PMK-MA delivery pull” in Table s32.
53
54 — Contents of the Mesh Wrapped Key field.
55
56 Upon receiving message 2, the MA shall verify the MIC, and shall verify that the Replay counter field con-
57
58 tains the value as in message 1.
59
60 11A.4.4.2 Mesh key transport push protocol
61
62
The key transport push protocol is a two-message exchange consisting of a PMK-MA delivery message sent
63
64 to the MA, followed by a confirmation message sent in reply. Both messages contain a MIC for integrity
65 protection, and the PMK-MA being delivered is encrypted.

IEEE P802.11s/D1.05, June 2007
1 Mesh key transport push message 1 is a PMK-MA delivery push MSA mesh action frame (see 7.4b.1.2). The
3
MKD shall be asserted in the SA field of the message header. Prior to constructing the message, the value of
4
5 the MKD’s replay counter associated with the MPTK-KD shall be incremented by 1.
6
8
9 — Replay counter shall be set to the value of the MKD’s replay counter.
11 ated the mesh key hierarchy that includes the PMK-MA being delivered
12
13 — PMK-MKDName shall be set to the identifier of the key from which the PMK-MA being delivered
14 was derived.
15
16
— MPTKANonce shall be set to the pseudo-random value that was selected by the MKD for derivation
17 of the PMK-MKDName indicated in this message.
18
19 The contents of the Mesh Wrapped Key field shall be as follows:
20
21 — Wrapped Context Length field shall be set to the length in octets of the Wrapped Context field.
22 — Wrapped Context field shall contain the concatenation: key_data = {PMK-MA || PMK-MAName ||
23 Lifetime KDE}
24
25 • Lifetime KDE is defined in Figures 144 and 149. The KDE contains a 4-octet value containing
26 the number of seconds remaining in the lifetime of the PMK-MA.
27 • The concatenation key_data shall be wrapped using NIST AES Key Wrap algorithm, with the
28
MKEK-KD, as defined in RFC 3394, prior to being inserted in the Wrapped Context field.
29
30
34
37
38 — Contents of the Category field of the PMK-MA delivery push MSA mesh action frame.
39 — Action Value field of the PMK-MA delivery push MSA mesh action frame, which contains the value
40
shown for “PMK-MA delivery push” in Table s32.
41
43
44
— Contents of the Mesh Wrapped Key field.
45
46 Upon receiving message 1, the MA shall verify the MIC, and shall verify that the replay counter field contains
47 a value not previously used with the MPTK-KD in a first message sent by the MKD. If verified, the MA shall
48 send a confirmation message to the MKD.
49
50
51 Mesh key transport push message 2 is a PMK-MA confirm MSA mesh action frame (see 7.4b.1.3). The MAC
52 address of the MKD shall be asserted in the DA field of the message header, and the MAC address of the MA
53 shall be asserted in the SA field of the message header.
54
55
56
The contents of the Mesh Key Transport Control field shall be identical to those values received in message 1.
57
61
64
65 — Contents of the Category field of the PMK-MA confirm MSA mesh action frame.

IEEE P802.11s/D1.05, June 2007
1 — Action Value field of the PMK-MA confirm MSA mesh action frame, which contains the value
2 shown for “PMK-MA confirm” in Table s32.
3
5
6
Upon receiving message 2, the MKD shall verify the MIC, and shall verify that the Replay counter field con-
7
9
10 11A.4.4.3 Mesh key delete protocol
11
12
13 The MKD may initiate the mesh key delete protocol in order to request that a previously-delivered PMK-MA
14 be revoked. Revocation of the PMK-MA implies that the PMK-MA shall be deleted and all keys derived
15 from the PMK-MA shall be deleted.
16
17
18 The key delete protocol is a two-message exchange consisting of a PMK-MA delete message sent to the MA,
19 followed by a confirmation message sent in reply. Both messages contain a MIC for integrity protection.
20
21
22
Mesh key delete message 1 is a PMK-MA delete MSA mesh action frame (see 7.4b.1.6). The MAC address
23 of the MA shall be asserted in the DA field of the message header, and the MAC address of the MKD shall
24 be asserted in the SA field of the message header. Prior to constructing the message, the value of the MKD’s
25 replay counter associated with the MPTK-KD shall be incremented by 1.
26
27
29 — Replay counter shall be set to the value of the MKD’s replay counter.
30
32 ated the mesh key hierarchy that includes the PMK-MA that shall be deleted.
33
34 — PMK-MKDName shall be set to the identifier of the key from which the PMK-MA that shall be
35 deleted was derived.
36
37 — MPTKANonce shall be set to zero.
38
40
MKCK-KD, using the AES-128-CMAC algorithm (AES-128-CMAC is defined by FIPS SP800-38B) on the
41
44
46
47 — Contents of the Category field of the PMK-MA delete MSA mesh action frame.
48 — Action Value field of the PMK-MA delete MSA mesh action frame, which contains the value shown
49
50
for “PMK-MA delete” in Table s32.
52
53
54 Upon receiving message 1, the MA shall verify the MIC, and shall verify that the replay counter field contains
55 a value not previously used with the MPTK-KD in a first message sent by the MKD. If verified, the MA shall
56 compute the value of PMK-MAName using the PMK-MKDName and SPA included in message 1. The MA
57 shall revoke the PMK-MA named by PMK-MAName, and shall send a confirmation message to the MKD.
58
59
60 Mesh key delete message 2 is a PMK-MA confirm MSA mesh action frame (see 7.4b.1.3). The MAC address
61 of the MKD shall be asserted in the DA field of the message header, and the MAC address of the MA shall
62 be asserted in the SA field of the message header.
63
64
65 The contents of the Mesh Key Transport Control field shall be identical to those values received in message 1.

IEEE P802.11s/D1.05, June 2007
3
concatenation in the following order, of:
4
6
8 — Contents of the Category field of the PMK-MA confirm MSA mesh action frame.
9
10 — Action Value field of the PMK-MA confirm MSA mesh action frame, which contains the value
11 shown for “PMK-MA confirm” in Table s32.
12
14
15
Upon receiving message 2, the MKD shall verify the MIC, and shall verify that the Replay counter field con-
16
18
19 11A.4.5 Mesh EAP message transport protocol
20
21
22 This protocol describes how the MA may initiate and perform authentication via EAP with the supplicant dur-
23 ing the supplicant MP’s Initial MSA Authentication. The use of this protocol is selected during the mesh key
24 holder security handshake defined in 11A.4.3.2 and is described by transport type selector 00-0F-AC:1.
25 When the transport type selector specifies any other value, the mechanism for EAP Transport is beyond the
26
27 scope of this standard.
28
29 EAP, as described in IETF RFC 3748, is a “lock-step protocol,” with alternating request and response mes-
30 sages exchanged. The mesh authentication message transport protocol permits transport of these request and
31
32
response messages through the mesh, between the MA and the MKD.
33
34 The MA initiates IEEE 802.1X authentication with the supplicant by sending a first EAP message to the sup-
35 plicant. If the MA is configured with the appropriate first EAP message to send, then the MA does so. Oth-
36
erwise, the MA may request the first EAP message from the AS, using the EAP-Start indication described
37
38 below. When the MA receives an EAP message from the supplicant, the MA sends an EAP Encapsulation
39 MSA mesh action frame to the MKD that contains the received EAP message. When the MKD has an EAP
40 message, received from the AS and destined for the supplicant, it sends an EAP Encapsulation MSA mesh
41 action frame to the MA containing the EAP message.
42
43
44 The final EAP Encapsulation MSA mesh action frame of a sequence is sent by the MKD, and is given a spe-
45 cial type to provide information to the MA. If the EAP authentication of the supplicant provided an “accept”
46 indication to the MKD, then the MKD sends the final message with type “accept” to indicate to the MA that
47 the supplicant should be granted access. Alternatively, if EAP failed, the MKD sends the final message with
48
49 type “reject” to the MA. Upon reception of an EAP Encapsulation MSA mesh action frame of type “reject,”
50 the MA shall terminate the peer link with the supplicant.
51
52 When an IETF RFC 3748 EAP message is included in a EAP Encapsulation MSA mesh action frame, it is
53
54 carried in the EAP Message subfield. The maximum length EAP message that may be included in the EAP
55 Message subfield is 2273 octets, due to the maximum length of a Mesh Action Data Unit (see 7.2.4.3).
56
57 The EAP-Start indication is sent from MA to MKD by constructing an EAP Encapsulation request message
58
59 that omits the EAP Message subfield.
60
61 11A.4.5.1 EAP encapsulation request message
62
63
64 An EAP Encapsulation mesh action message with Encapsulation type request is sent from MA to MKD, ei-
65 ther to transport an EAP message from the supplicant, or to request the AS to initiate EAP (“EAP-Start”).

IEEE P802.11s/D1.05, June 2007
1 EAP Encapsulation request message is an EAP Encapsulation MSA mesh action frame (see 7.4b.1.7). The
2 MAC address of the MKD shall be asserted in the DA field of the message header, and the MAC address of
3
the MA shall be asserted in the SA field of the message header. The contents of the EAP Authentication field
4
5 are as follows:
6 — Encapsulation Type shall be set to 1 to indicate “request”.
7
8 — Message Token shall be set to a unique nonce value chosen by the MA.
9 — SPA shall be set to the MAC address of the supplicant MP that is participating in EAP.
10
11 — EAP Message Length shall indicate the length in octets of the EAP message that is included in the
12 EAP Message subfield. If the MA is sending an “EAP-Start” notification, the EAP Message Length
13 subfield shall be set to zero.
14
15 — If the EAP Message Length subfield is nonzero, the EAP message subfield shall be present, and shall
16 contain an EAP message with format as defined in IETF RFC 3748. If the EAP Message Length
17 subfield is zero, the EAP message subfield shall be omitted. The EAP message subfield shall be no
18 longer than 2273 octets.
19
20
21 The Message integrity check field shall contain a MIC. The 16-octet MIC shall be calculated using the
24
25
— MA MAC address
27
28
— Contents of the Category field of the EAP Encapsulation MSA mesh action frame
29 — Contents of the Action Value field of the EAP Encapsulation MSA mesh action frame
30
31 — Contents of the EAP Authentication field.
32
33 Upon receiving a request message, the MKD shall verify the MIC, and store the Message Token for use in
34 constructing the response message.
35
36
37 11A.4.5.2 EAP encapsulation response message
38
39 An EAP Encapsulation mesh action message with Encapsulation type response, accept, or reject is sent from
40 MKD to MA, to transport an EAP message from the AS, and, in the final response message of a sequence,
41 provide an indication of the success of EAP.
42
43
44 EAP Encapsulation response message is an EAP Encapsulation MSA mesh action frame (see 7.4b.1.7). The
46 MKD shall be asserted in the SA field of the message header. The contents of the EAP Authentication field
47 are as follows:
48
49 — Encapsulation Type shall be set as follows:
50 • If this is the final message of the sequence, and the EAP authentication of the supplicant resulted
51
52 in an “accept” indication, Encapsulation Type shall be set to 2, to indicate “accept.”
53 • If this is the final message of the sequence, and the EAP authentication of the supplicant resulted
54 in a “reject” indication, Encapsulation Type shall be set to 3, to indicate “reject.”
55 • Otherwise, Encapsulation Type shall be set to 11, to indicate “response.”
56
57 — Message Token shall be set to the value contained in the request message to which this response cor-
58 responds.
59
— SPA shall be set to the value contained in the request message to which this response corresponds.
60
61 — EAP Message Length shall indicate the length in octets of the EAP message that is included in the
62 EAP message subfield.
63
64 — The EAP message subfield shall contain an EAP message with format as defined in IETF RFC 3748.
65 The EAP message subfield shall be no longer than 2273 octets.

IEEE P802.11s/D1.05, June 2007
1 The Message integrity check field shall contain a MIC. The 16-octet MIC shall be calculated using the
3
concatenation in the following order, of:
4
6
8
9 — Contents of the Category field of the EAP Encapsulation MSA mesh action frame
10
11 — Contents of the Action Value field of the EAP Encapsulation MSA mesh action frame
12
13 — Contents of the EAP Authentication field.
14
15
16 Upon receiving a response message, the MA shall verify the MIC, and verify that the Message Token
17 received in the message matches the value sent in the most recent request message. If the final response
18 message received has type “reject,” the MA shall terminate the peer link with the supplicant.
19
20
21
22 11A.5 Mesh path selection and forwarding framework
23
24
11A.5.1 Overview
25
26
27 The terms “mesh path selection” and “mesh forwarding” are used to describe selection of single-hop or
28
29
multi-hop paths and forwarding of data frames across these paths between MPs at the link layer. Data
30 messages use four or six addresses; the 6-address format is designed such that an intermediate MP on a mesh
31 path need not maintain forwarding information for any IEEE 802 entity outside the mesh.
32
33
34 Path selection messages are also transported at the link layer, using management frames (MMPDUs). Each
35 Mesh uses a single method to determine paths through the Mesh.
36
37
38 11A.5.2 Extensible path selection framework
39
40 This standard includes an extensible framework to enable flexible implementation of path selection
41
42 protocols and metrics within the mesh framework. The standard includes a default mandatory path selection
43 protocol (HWMP) and default mandatory path selection metric (Airtime Link Metric) for all
44 implementations, to ensure minimum capabilities for interoperability between devices from different
45 vendors. However, the standard also allows any vendor to implement any path selection protocol and/or
46 path selection metric in the mesh framework to meet special application needs, for instance with high
47
48 mobility of MPs. The mesh framework allows flexibility to integrate future path selection protocols for
49 wireless mesh networks.
50
51 An MP may include multiple protocol implementations (that is, the default protocol, optional protocols,
52
53 vendor specific protocols, etc.) as well as multiple metric implementations, but only one path selection
54 protocol and only one path selection metric shall be active in a particular mesh at a time. Different meshes
55 may have different active path selection protocols, but a particular mesh shall have one active protocol at a
56 time.
57
58
59 As described in 11A.1.3 and 11A.1.4, MPs use the Mesh Configuration element (7.3.2.54) to announce the
60 active path selection protocol and active path selection metric of the mesh network. This allows a neighbor
61 MP to identify if and how it should participate in the mesh. This standard does not force an existing mesh
62
that is using a protocol other than the default protocol to switch to the default protocol when a new MP
63
64 requests peer link establishment. While it is possible, in principle, to implement such behavior, an algorithm
65 to coordinate such reconfiguration is beyond the scope of this standard.

IEEE P802.11s/D1.05, June 2007
1 11A.5.3 Path selection metrics and protocols

2
3
4 The mesh extensibility framework allows a mesh to be implemented with any path selection metric(s) and/or
5 any path selection protocol(s). Each specification and implementation of any path selection protocol and any
6 path selection metric identifies the following parameters:
7
8 — unique identifier as defined in 7.3.2.54.1 and 7.3.2.54.2
9
10 — data type of metric values
11
12 — length of the metric field
13
14 — operator for aggregation of link metrics to a path metric; the symbol ⊕ is used to identify an arbi-
15
16 trary operator for aggregation
17
18 — comparison operator for determining a better or worse path; how this is performed depends on the
19 actual comparison operator
20
21 — initial value of the path metric
22
23
24 The selected path selection protocol and path selection metric must be compatible, that is:
25
26 — all possible metric values as defined by the data type and the length of the path selection metric can
27 be handled by the path selection protocol
28
29 — the operator for aggregating link metrics is supported by the path selection protocol implementation
30
31
32 11A.7 defines a default radio-aware path selection metric (the Airtime Link Metric) to enable baseline
33 interoperability. 11A.8 defines a default path selection protocol (the Hybrid Wireless Mesh Protocol) that
34 shall be implemented on all MPs to ensure interoperability.
35
36
37 11A.5.4 Link metric reporting
38
39
40 The purpose of the link metric reporting procedure is to determine the link metric associated with a
41 particular link.
42
43
44 If bi-directional link metrics are required in the network, each MP may request a link metric report from a
45 peer MP, or may voluntarily submit a link metric report to a peer MP. Upon reception of a link metric
46 report, an MP may update its local link metric information using the link metric information received.
47
48
49 To request a link metric report, an MP sends a link metric request to a peer MP. An MP receiving a link
50 metric request shall reply with a link metric report containing the measured metric for the link to the
51 requesting MP.
52
53
54 To submit a link metric report, an MP sends a link metric report frame to a peer MP.
55
56
57 11A.5.5 Frame addressing and forwarding in a mesh network
58
59
60 11A.5.5.1 Overview
61
62
Mesh Data frames and Mesh Management frames are designed to support multi-hop frame forwarding in a
63
64 mesh network using the Mesh Header described in 7.1.3.5a. In this subclause, addressing and forwarding of
65 these frames are described.

IEEE P802.11s/D1.05, June 2007
1 Figure s75 shows the valid combinations of address fields in Mesh Data frames and Mesh Management
2 frames along with the corresponding values of the “To DS”, “From DS”, and “AE Flag” fields.
3
4
5 Supported To From AE
Address 1 Address 2 Address 3 Address 4 Address 5 Address 6
Frames DS DS Flag
6
7 Mesh Data,
8 DA = SA = Not Not
Mesh 1 1 0 RA TA
9 Mesh DA Mesh SA Present Present
Management
10
11
12 Mesh Data 1 1 1 RA TA Mesh DA Mesh SA DA SA
13
14
15
16
17 Figure s75—Valid address field usage for Mesh Data and Mesh Management frames.
18
19 Address 1 and Address 2 correspond to the MP receiver address (RA) and the MP transmitter address (TA)
20
21
for a particular mesh link. Address 3 and Address 4 correspond to the destination and source endpoints of a
22 mesh path. The AE flag indicates the existence of the optional address extension field including Address 5
23 and Address 6 in the Mesh Header which correspond to the end-to-end destination address (DA) and source
24 address (SA) in the following cases:
25
26 — When the end points of IEEE 802 communication are non-mesh, proxied entities which communi-
27 cate over a mesh via proxy MPs.
28
29 — When the end points are MPs communicating with each other via a root MP in HWMP proactive tree
30 building mode, where two distinct mesh paths are used (the first path being from the source MP to
31 the root MP and the second path being from the root MP to the destination MP).
32
33
34 The term source MP refers to the first MP that transmits a frame on a mesh path. A source MP may be an
35 MP that is the original source of a frame or a proxy MP that receives a frame from an entity outside of the
36 mesh and translates and forwards the frame on a mesh path. The address of the source MP is referred to as
37
38 the Mesh SA.
39
40 The term destination MP refers to the final MP on a mesh path. A destination MP may be an MP that is the
41
42
final destination of a frame or an MP that receives a frame from a mesh path and translates and forwards the
43 frame on another mesh path or to an entity outside of the mesh. The address of the destination MP is
44 referred to as the Mesh DA.
45
46
47 Figure s76 illustrates example addressing of a Mesh Data frame transmitted and forwarded on a mesh path
48 from an MAP to an MPP where the original source is an 802.11 STA associated with the MAP and the final
49 destination is an entity outside of the mesh that is reachable via the MPP.
50
51 SA Mesh SA Mesh DA DA
52
53 802.11
54 MAP MP MPP STA
STA
55 link link link link
56
57
58 mesh path
59
60 End-to-end 802 communication
61
62
63
64 Figure s76—Example Addressing for a Mesh Data frame transmitted and forwarded on a
65 mesh path from an MAP to an MPP.

IEEE P802.11s/D1.05, June 2007
1 Details on how these address mappings work in forwarding processing are described in 11A.5.5.2 and
2 11A.5.5.3.
3
4
5 11A.5.5.2 Addressing and Forwarding of Unicast Frames
6
7 11A.5.5.2.1 At Source MPs
8
9
10 In cases where both end points are MPs at the beginning and end of a single mesh path, the source MP shall
11 use 4-address frames (with AE flag set to 0) where the four address fields in the header are set as follows:
12
13
— Address 1: The address of the next-hop MP (toward the Destination MP according to forwarding
14 information)
15 — Address 2: The address of the Source MP
16
17 — Address 3: The address of the Destination MP
18
19
— Address 4: The address of the Source MP
20
21 In cases where either (or both) of the end points is not an MP at the beginning or end of a single mesh path,
22 the source MP at the beginning of the mesh path shall use 6-address frames (with AE flag set to 1) where the
23 mesh address extension field in the Mesh Header carries the addresses of the end points, as follows:
24
25 — Address 1: The address of the next-hop MP (toward the last MP of the mesh path, according to for-
26 warding information)
27
28 — Address 2: The address of the source MP at the beginning of the mesh path
29 — Address 3: The address of the destination MP at the end of the mesh path
30
31 — Address 4: The address of the source MP at the beginning of the mesh path
32
33 — Address 5: The address of the destination end point (may be the same as Address 3 if the destination
34 is the MP at the end of the mesh path)
35 — Address 6: The address of the source end point (may be the same as Address 4 if the source is the MP
36
37 at the beginning of the mesh path)
38
39 The Source MP shall set the Mesh Sequence Number field in the Mesh Header to a value from a single mod-
40 ulo-65536 counter that is incrementing by 1 for each new frame.
41
42
43 The TTL field in the Mesh Header shall be set to the value of dot11MeshTTL.
44
45 11A.5.5.2.2 At Intermediate and destination MPs
46
47
48 On receipt of a unicast frame, an MP shall decipher it and check it for authenticity. If it is not from a peer
49 MP, the frame shall be silently discarded.
50
51
The MP shall then check to see whether the Mesh DA in Address 3 field is known; if it is an unknown
52
53 address, the MP may either silently discard the frame or trigger a path discovery procedure depending on the
54 path selection protocol that is currently active in the mesh.
55
56 If Address 3 does not match the MP’s own address, but is a known MAC addresses in the forwarding infor-
57
58 mation, the MP shall decrement the TTL field in the Mesh Header. If zero has been reached, the frame shall
59 be discarded. Otherwise, the MP shall forward the frame by setting the Address 1 field to the MAC address
60 of the next hop MP as determined from the forwarding information and the TA field to its own MAC address
61 and queueing the frame for transmission.
62
63
64 If Address 3 matches the MP’s own MAC address, then the MP shall check the AE flag in the Mesh Header
65 field and take the following actions based on its value:

IEEE P802.11s/D1.05, June 2007
1 — If the AE flag is set to 0, indicating this MP is the final destination of the frame, the MP shall process
2 and send it to an upper layer. By the pair of source MP Address (identified by Address 4 field of the
3
MAC header) and Mesh Sequence Number, the destination MP may detect duplicate frames. Dupli-
4
5 cate frames may be discarded.
6 — If the AE flag is set to 1:
7
8 • If the current MP is a proxy MP for non-mesh, proxied entities, the MP shall first check whether
9 or not the destination address (DA) in Address 5 field is one of the addresses of its proxied enti-
10
11
ties. If the destination address is the address of one of its proxied entities, the MP shall translate
12 the frame to the corresponding format and queue it for transmission to the final destination.
13 • If the current MP is a root MP (in HWMP proactive tree building mode), the MP shall check
14 whether the DA in Address 5 field is one of its known addresses or not:
15
16 •If the DA in Address 5 corresponds to an MP, the MP shall reformat the frame as a 4-
17 address frame with Address 3 field set to the DA, Address 4 set to the source end-point
18 address, Address 1 set to the next-hop MP on the mesh path to the destination MP, and
19 Address 2 set to the root MP’s address. The MP shall then queue the frame for transmis-
20
21 sion.
22 •If the DA in Address 5 corresponds to a non-mesh entity proxied by one of its known MPs,
23 the MP shall update the Address 3 field to the address of the proxy MP, the Address 1
24 field to the next-hop MP on the mesh path to the proxy MP, and Address 2 to the root
25
26 MP’s address. The MP shall then queue the frame for transmission.
27
28 Note that in some cases, an MP could be both a proxy MP and a root MP. In such a case, the MP should fol-
29 low both the steps described for the case that AE flag is set to 1.
30
31
32 Also, note that during the forwarding process at intermediate MPs, the contents of the frame body are not
33 changed.
34
35
36 11A.5.5.3 Addressing and Forwarding of Broadcast Frames
37
38
39
11A.5.5.3.1 At Source MPs
40
41 An MP that is the source of a broadcast frame shall use a 4 address frame and set the Address 3 field to the
42 broadcast address and the Address 2 and Address 4 fields to its own MAC address.
43
44
45 If the frame is originally received by an MP from proxied entities (i.e., at MAPs/MPPs) with a broadcast
46 address in the Address 1 (RA/DA) field the Source MP shall enable Mesh Address Extension by setting the
47 AE flag to 1 and encode Address 5 to the broadcast address and Address 6 to the address of the proxied
48
49 entity. It shall set the Address 3 field to the broadcast address and the Address 2 and Address 4 fields to its
50 own MAC address.
51
52 The Source MP shall set the TTL field in the Mesh Header to dot11MeshTTL in order to control the
53
54 reachability of broadcast frames in terms of hop count. For example, if the TTL field is set to 1, frames are
55 delivered to immediate neighbors only. Otherwise, the frames are broadcasted multiple hops, limited by the
56 TTL value.
57
58
59 The Source MP shall set the Mesh Sequence Number field in the Mesh Header to a value from a single mod-
60 ulo-65536 counter that is incrementing by 1 for each new frame.
61
62
In order to increase the reliability of broadcast frame delivery, a Source MP may optionally transmit the
63
64 same broadcast frame multiple times or break the frame in to multiple unicast frames to peer MPs with
65 Address 1 set to each peer MP’s address and Address 3 set to the broadcast address.

IEEE P802.11s/D1.05, June 2007
1 11A.5.5.3.2 At Intermediate and destination MPs

2
3
4 On receipt of a frame with Address 1 (RA) set to its MAC address or the broadcast MAC address and with
5 Address 3 (DA/Mesh DA) set to the broadcast address, an MP deciphers the frame and checks for authentic-
6 ity. If it is not from a peer MP, the frame shall be silently discarded. Otherwise, it shall be further processed
7 as follows.
8
9
10 The tuple of Address 4 (SA/Mesh SA) and Mesh Sequence Number from the Mesh Header shall be used as
11 a unique message signature for tracking broadcast frames. The MP checks whether the frame has previously
12 been received. If this is the case, the frame shall be discarded. Otherwise, the MP shall retain the signature
13 and continues processing the frame.
14
15
16 The MP then decrements the TTL field in the Mesh Header field. If the TTL value has reached zero, the
17 message shall not be forwarded to other MPs. Otherwise, the frame is queued for transmission to peer MPs
18 in order to propagate this broadcast frame throughout the mesh. The transmission procedure of the broadcast
19
frame is as described in the previous subclause.
20
21
22 If the MP is a proxy MP, the MP shall transmit the frame to all its proxied entities outside the boundary of
23 the mesh after translating the frame to the appropriate frame formats for proxied entities.
24
25
26 Note that during the forwarding process at intermediate MPs, the contents of the frame body are not
27 changed.
28
29
11A.5.5.4 Multicast Frames
30
31
32 On transmission or receipt of a multicast frame, the same process used for broadcast forwarding in
33 11A.5.5.3 is applied for the multicast frame.
34
35
36 The MP may implement multicast filtering technology to reduce multicast traffic flooding in the mesh net-
37 work. This may be achieved, for example, by using the GARP Multicast Registration Protocol (GMRP)
38 defined in IEEE802.1D. This filtering technology is beyond the scope of this specification.
39
40
41 Support for special multicast capabilities is an implementation choice and requires invoking the extensibility
42 feature of this standard.
43
44 11A.5.5.5 Note on 7.2.3 Management Frames
45
46
47 Management frames which utilize the normal 3-address management frame headers specified in 7.2.3, such
48 as Mesh Management Action frames (3-address action frames) described in 7.4.6, are transmitted only one
49 hop to peer MPs.
50
51
52 Note that in several cases, the reception and processing of a 3-address action frame leads to the transmission
53 of a new action frame of the same type that may include an identical or a modified version of the contents
54 from the information elements of the received action frame.
55
56
57 11A.6 Interworking
58
59
60 11A.6.1 Overview of interworking in a mesh
61
62
63
A mesh functions like an IEEE 802 LAN segment that is compatible with IEEE 802.1D.
64
65 The combination of MP functionality and the IEEE 802.1D bridging functionality is called an MPP.

IEEE P802.11s/D1.05, June 2007
1 The mesh MAC entity appears as a single port to an IEEE 802.1D MAC Relay entity in IEEE 802.1D (to
2 which it presents the Internal Sublayer Service interface) or any other higher-layer entity, such as a
3
Spanning Tree Protocol entity, or a layer 3 router (to which it provides the MAC service to LLC, e.g., LLC
4
5 type 1 to support the Spanning Tree Protocol entity).
6
7 A mesh network may have zero or more MPPs which may be connected to one or more LAN segments. In
8 case two MPPs connect the mesh to one external LAN segment, broadcast loops may occur and the IEEE
9 802.1D bridging protocol may cause the LAN ports of one of the MPPs to be closed. These cases can be
10
11 prevented by proper configuration measures.
12
13 The default path selection protocol supports the transfer of "proxy information" towards the MPP. The MPP
14 shall support the Internal Sublayer Service interface to transfer this information to the MAC Relay Entity as
15 defined in IEEE 802.1D. As a result, the bridge, or, more specifically, the Learning Process within the MAC
16 Relay Entity will learn the addresses of all the MPs and their attached stations.
17
18
19 11A.6.2 MPP announcement protocol
20
21 This subclause describes the function, generation and processing of the Portal Announcement (PANN).
22
23
24 Enabling the announcement protocol in a given MPP is beyond the scope of this standard.
25
26 11A.6.2.1 Function
27
28
29 The Portal Announcement (PANN) element, described in 7.3.2.72, is used to announce the presence of an
30 MP configured as an MPP in the mesh. Portal Announcements allow MPs to select the appropriate MPP and
31 build a path towards it. An MP which receives a Portal Announcement message shall propagate the Portal
32
33
Announcement as described below but may ignore its content.
34
35 The MPP sequence number of the Portal Announcement shall be incremented by the MPP before each trans-
36 mission.
37
38
39 11A.6.2.2 Conditions for generating and sending a PANN
40
41 An MP shall transmit a PANN in the following cases:
42
43
44 Case A: Original transmission
45
46 All of the following applies:
47 • The MP is configured as an MPP
48 • At every PORTAL_ANNOUNCEMENT_INTERVAL
49
50
51 The content of a PANN element in Case A shall be as shown in Table s43.
52
53
54 Table s43—Content of a PANN element in Case A
55
56
57 Field Value
58
59 ID Value given in Table 7.26 for the PANN element
60
61 Length As required
62
63 Flags Not used
64
65 Hop Count 0

IEEE P802.11s/D1.05, June 2007
1 Table s43—Content of a PANN element in Case A

2
3
4 Time to Live Maximum number of hops allowed for the Portal Announcement
5
6 Address MPP MAC address
7 Sequence Number A sequence number specific for the MPP
8
9 Metric Initial value of active path selection metric
10
11
12
13
14
Case B: Forwarding
15
17 • The MP has received a Portal Announcement
18 • PORTAL_PROPAGATION_DELAY has expired
19
20 • The decremented TTL of the Portal Announcement is equal to or greater than 1
21
22
23 The content of a PANN element in Case B shall be as shown in Table s44.
24
25
26 Table s44—Content of a PANN element in Case B
27
28
29 Field Value
30
31 ID Value given in Table 7.26 for the PANN ele-
32 ment
33
34 Length As received
35 Flags As received
36
37 Hop Count As received + 1
38
39 Time to Live As received – 1
40
41 Originator Address As received
42
43 Sequence Number As received
44 Metric As received ⊕ own metric toward the trans-
45 mitting MP
46
47
48
49 11A.6.2.3 PANN processing
50
51
52 A received Portal Announcement is subject to certain acceptance criteria. Processing depends on the con-
53 tents of the Portal Announcement and the information available at the receiving MP.
54
55
56 11A.6.2.3.1 Acceptance criteria
57
58 The Portal Announcement shall be discarded if
59
60 — the Sequence Number of the Portal Announcement is lower than the Sequence Number of the previ-
61 ously received Portal Announcement from this MPP, or
62
— the Sequence Number of the Portal Announcement is the same as the Sequence Number of the previ-
63
64 ously received Portal Announcement from this MPP, and the metric is worse that the metric of the
65 previously received Portal Announcement from this MPP

IEEE P802.11s/D1.05, June 2007
1 11A.6.2.3.2 Effect of receipt

2
3
The following applies only to Portal Announcements that were not discarded during the check described in
4
5 11A.6.2.3.1 (Acceptance criteria) above.
6 a) The receiving MP shall initiate a PANN_PROPAGATION_DELAY
7
8 b) The receiving MP shall transmit a Portal Announcement as defined in 11A.6.2.2 (Conditions for
9 generating and sending a PANN), Case B
10
11 11A.6.3 MP behavior
12
13
14 When an MP receives Portal Announcements sent by MPPs in the mesh, it records the MAC address and
15 path metric to all active MPPs in the mesh.
16
17 When an MP has a data message to send, it first follows the data forwarding procedures defined in 11A.5.5.
18 If the MP is not able to determine an intra-mesh path to the destination MAC address, the MP shall assume
19
20 that the destination is outside the mesh and shall forward the message to all active MPPs in the mesh (see
21 11A.6.4.1, Egress message handling). If the destination appears to be outside the mesh but there is no MPP
22 available, the MP has a problem that is efficiently solved by putting the frame in the bit bucket.
23
24 11A.6.4 MPP data forwarding behavior
25
26
27 Forwarding of frames by the MPP into the mesh follows the procedures given in 11A.5.5.
28
29 MPPs learn the addresses of the MPs and of devices attached to these MPs through the receipt of messages
30 carrying proxy information (see 11A.8.9). The bridge learns via the Learning Process in the MAC Relay
31
32 Entity per usual IEEE 802.1D procedures.
33
34 11A.6.4.1 Egress message handling
35
36 A frame sent by an MP in the mesh has the following final destinations:
37
38 a) An MP address or a proxied address that the MPP knows is reachable through the mesh
39
The MPP forwards the frame to the destination MP.
40
41 b) An address that the MPP knows is outside the Mesh
42
The MPP forwards the frame on the external network.
43
44 c) An address unknown to the MPP
45
46
The MPP forwards the frame on the external network and on the mesh. For the latter it has two
47 options:
48 1) To attempt to establish a path to the destination
49
50 2) To broadcast the frame within the mesh using the Mesh Broadcast procedure (see 11A.5.5.3)
51 The criteria for making this choice are beyond the scope of this standard.
52
53
54 11A.6.4.2 Ingress message handling
55
56 A frame received by an MPP in an MA_UNITDATA.request at the MAC service has two possible destina-
57 tions:
58
59 a) An MP address or proxied address that the MPP knows is inside the Mesh
60 The MPP forwards the frame to the destination MP.
61
62 b) An address unknown to the MPP
63 The MPP has two options:
64
65 1) To attempt to establish a path to the destination

IEEE P802.11s/D1.05, June 2007
1 2) To broadcast the frame within the mesh using the Mesh Broadcast procedure (see 11A.5.5.3)
2
3 The criteria for making this choice are beyond the scope of this standard.
4
5
6 11A.6.5 Proxy protocol
7
8
11A.6.5.1 Proxy Update (PU)
9
10
11 This clause describes the function, generation and processing of the PU element.
12
13
14 11A.6.5.1.1 Function
15
16
17 A PU element is generated by an MP to inform a destination MP of its proxied addresses.
18
19
20
11A.6.5.1.2 Conditions for generating and sending a PU
21
22 An MP shall send out a PU in the following cases:
23
24 — The MP needs to inform a destination MP of its proxy information.
25
26 — A change is made in the local proxy information of the MP due to addition or deletion of proxy
27 entries.
28
29 — If a root receives a PU element with a add proxy information or if it detects a new proxied address in
30 its DS (e.g. through bridge learning) and the root already has proxy information for one or more of
31
these proxied address, it shall send a PU element with Bit 0 set to 1 (delete proxy information) to
32
33 each of the old proxy. PU element in this case includes the list of corresponding proxied addresses
34 which should be removed by the proxy.
35
36 — On a periodic basis to refresh the proxy information at the destination MP.
37
38
39
The PU element is transmitted via unicast from the MP to a destination MP. This request may be repeated
40 after every PU_ TIMEOUT for MAX_PU times until the MP receives a PUC element.
41
42
The content of a PU element shall be as shown in Table s45.
43
44
45
46 Table s45—Content of a PU element
47
48
49 Field Value/description
50
51 ID Value given in Table 7.26 for the PU element
52
53 Length Length of the element
54 Flags Bit 0: 0: add proxy information; 1: delete proxy information
55 1 – 7: Reserved
56
57 Sequence number Sequence number of the PU
58
59 Proxy Address MAC address of the proxy MP
60
61 Number of Proxied Device Number of proxied addresses reported to the destination MP
62 Address (N)
63
64 Proxied Device MAC MAC address of proxied entities to which the MP is providing mesh services
65 Address

IEEE P802.11s/D1.05, June 2007
1 11A.6.5.1.3 PU processing
2
3
4 A PU is a unicast message sent from an MP to a destination MP. The destination MP shall update the proxy
5 address in its proxy information with the list of proxied addresses reported in the PU.
6
7 11A.6.5.2 Proxy Update Confirmation (PUC)
8
9
10 This clause describes the function, generation and processing of the PUC element.
11
12 11A.6.5.2.1 Function
13
14
15 A PUC IE is generated by a destination MP in response to a PU element.
16
17 11A.6.5.2.2 Conditions for generating and sending a PUC
18
19
20 A PUC is unicast from the destination MP to the MP that sent the PU.
21
22 The content of a PUC element shall be as shown in Table s46.
23
24
25
26 Table s46—Content of a PUC element
27
28
29 Field Value/description
30
31 ID Value given in Table 7.26 for the PUC element
32 Length Length of the element
33
34 Flags Bit 0- 7: Reserved
35
36 Sequence number Sequence number of the PU which is being confirmed
37
38 Destination MP Address MAC address of the recipient of the PU
39
40
41
42 11A.6.5.2.3 PUC processing
43
44 On receiving a PUC IE, the MP shall no longer send any PU with the same sequence number.
45
46
47
48
11A.7 Airtime link metric computation procedures
49
50 In order to compute the forwarding table for individually addressed frames, the MP shall first calculate the
51 link metric for each pairwise link to its peer MPs in the Mesh. This subclause defines a default link metric
52 that may be used by a path selection protocol to identify an efficient radio-aware path. The extensibility
53
54 framework allows this metric to be overridden by any path selection metric as specified in the active profile.
55
56 The default link metric is the airtime metric. Airtime reflects the amount of channel resources consumed by
57 transmitting the frame over a particular link. This measure is approximate and designed for ease of
58 implementation and interoperability.
59
60
61 The airtime for each link is calculated as:
62
63 B 1
64 c a = O + -----t -------------
65 r 1 – ef

IEEE P802.11s/D1.05, June 2007
1 Where O and Bt are constants listed in Table s47, and the input parameters r and ef are the data rate in Mb/s
2 and the frame error rate for the test frame size Bt respectively. The rate r represents the data rate at which the
3
4 MP would transmit a frame of standard size Bt based on current conditions and its estimation is dependent
5 on local implementation of rate adaptation. The frame error rate ef is the probability that when a frame of
6
7 standard size Bt is transmitted at the current transmission bit rate r, the frame is corrupted due to
8 transmission error; its estimation is a local implementation choice. Frame drops due to exceeding TTL
9 should not be included in this estimate as they are not correlated with link performance.
10
11
12 The airtime link metric shall be measured in increments of 10.24 microseconds, or one hundredth of a TU.
13
14
15 Table s47—Airtime cost constants
16
17
18 Recommended
19 Parameter Description
Value
20
21 O varies depend- Channel access overhead, which includes
22 ing on PHY frame headers, training sequences, access
23 protocol frames, etc.
24
25 Bt 8192 Number of bits in test frame
26
27
28
29 Table s48 gives the parameters of the airtime link metric for the Extensible Path Selection Framework.
30
31
32
33
Table s48—Parameters of the Airtime Link Metric for Extensible Path Selection Framework
34
35 Path Selection Metric ID See Table s4 in 7.3.2.54.2.
36
37 Data type Unsigned integer, 0 ≤ metric value ≤ 4, 294, 967, 296
38
39 Length of metric field 4 octets
40
41 Operator for metric aggregation addition ( + )
42 Comparison operator less than, equal to, greater than as used with integers
43
44 — metric a is better than metric b iff a < b
45 — metric a is equal to metric b iff a = b
46
47 — metric a is worse than metric b iff a > b
48
49 Initial value of path metric 0
50
51
52
53 11A.8 Hybrid Wireless Mesh Protocol (HWMP)
54
55
56 11A.8.1 Overview
57
58
59
11A.8.1.1 General
60
61 The Hybrid Wireless Mesh Protocol (HWMP) is a mesh path selection protocol that combines the flexibility
62
of on-demand path selection with proactive topology tree extensions. The combination of reactive and
63
64 proactive elements of HWMP enables optimal and efficient path selection in a wide variety of mesh
65 networks (with or without infrastructure).

IEEE P802.11s/D1.05, June 2007
1 HWMP uses a common set of protocol primitives, generation and processing rules inspired by Ad Hoc On
2 Demand Distance Vector (AODV) protocol [IETF RFC 3561] adapted for MAC address-based path
3
selection and link metric awareness. HWMP is completely specified herein and does not require reference to
4
5 AODV.
6
7 HWMP supports two modes of operation depending on the configuration. These modes are:
8 — On demand mode: this mode allows MPs to communicate using peer-to-peer paths. The mode is
9
10 used in situations where there is no root MP configured. It is also used in certain circumstances if
11 there is a root MP configured and an on demand path can provide a better path to a given destination
12 in the mesh.
13
— Proactive tree building mode: this can be performed by using either the PREQ or RANN mechanism.
14
15
16 These modes are not exclusive: on demand and proactive modes may be used concurrently. One example of
17 concurrent usage of on-demand and proactive mode is for two MPs that are part of the same mesh to begin
18 communicating using the proactively built tree but subsequently to perform an on-demand discovery for a
19 direct path between each other. This type of concurrent usage of the proactive and on-demand modes allows
20
communication to begin immediately while an on-demand discovery finds a more optimal path between two
21
22 MPs.
23
24 All HWMP modes of operation utilize common processing rules and primitives. HWMP information
25 elements are the Path Request (PREQ), Path Reply (PREP), Path Error (PERR) and Root Announcement
26 (RANN). The metric cost of the links determines which paths HWMP builds. In order to propagate the
27
metric information between MPs, a metric field is used in the PREQ, PREP and RANN messages.
28
29
30 Path selection in HWMP uses a sequence number mechanism to maintain loop-free connectivity at all times.
31 Each MP maintains its own sequence number, which is propagated to other MPs in the HWMP information
32 elements.
33
34
11A.8.1.2 On demand path selection mode
35
36
37 If a source MP needs to find a path to a destination MP using the on demand path selection mode, it
38 broadcasts a PREQ with the destination MP specified in the destination list and the metric field initialized to
39 the initial value of the active path selection metric.
40
41
When an MP receives a PREQ it creates a path to the source or updates its current path if the PREQ contains
42
43 a greater sequence number, or the sequence number is the same as the current path and the PREQ offers a
44 better metric than the current path. If a new path is created or an existing path modified, the PREQ is also
45 forwarded (re-broadcast). Each MP may receive multiple copies of the same PREQ that originated in the
46 source, each PREQ traversing a unique path from the source to the MP.
47
48
Whenever an MP forwards a PREQ, the metric field in the PREQ is updated to reflect the cumulative metric
49
50 of the path to the PREQ’s source. After creating or updating a path to the source, the destination MP sends
51 a unicast PREP back to the source.
52
53 The PREQ provides “Destination Only” (DO) and “Reply and Forward” (RF) flags that allow path selection
54 to take advantage of existing paths to the destination by allowing an intermediate MP to return a PREP to the
55
source. If the DO flag is set to 1, only the destination sends a PREP. The effect of setting the DO flag to 0 is
56
57 the quick establishment of a path using the PREP generated by an intermediate MP, allowing the forwarding
58 of data frames with a low path selection delay. The effect of setting the RF flag to 1 (in addition to setting
59 the DO flag to 0) is the selection (or validation) of the best path after the path selection procedure has
60 completed. If the RF flag is set to 1, the first intermediate node that has a path to the destination sends a
61
PREP and forwards the PREQ with the DO flag set to 1 to avoid all intermediate MPs sending a PREP.
62
63
64 Intermediate MPs create a path to the destination on receiving the PREP, and also forward the PREP toward
65 the source. When the source receives the PREP, it creates a path to the destination. If the destination receives

IEEE P802.11s/D1.05, June 2007
1 further PREQs with a better metric, then the destination updates its path to the source to the new path and
2 also sends a fresh PREP to the source along the updated path. A bidirectional, best metric end-to-end path is
3
established between the source and destination.
4
5
6 In HWMP the PREQ processing at intermediate MPs is controlled per destination.
7
8 11A.8.1.3 Proactive tree building mode
9
10
11 There are two mechanisms for proactively disseminating path selection information for reaching the root
12
13
MP. The first method uses a proactive Path Request (PREQ) message and is intended to create paths
14 between the root MP and all MPs in the network proactively. The second method uses a Root
15 Announcement (RANN) message and is intended to distribute path information for reaching the root MP but
16
the actual paths to the root MP can be built on-demand.
17
18
An MP configured as root MP would send either proactive PREQ or RANN messages periodically.
19
20
21 11A.8.1.3.1 Proactive PREQ mechanism
22
23
24
The PREQ tree building process begins with a proactive Path Request message sent by the root MP, with the
25 destination address set to all ones (broadcast address), the DO flag set to 1 and the RF flag set to 1. The
26 PREQ contains the path metric (set to the initial value of the active path selection metric by the root MP) and
27 a sequence number. The proactive PREQ is sent periodically by the root MP, with increasing sequence
28 numbers.
29
30
31 An MP hearing a proactive PREQ creates or updates its forwarding information to the root MP, updates the
32 metric and hop count of the PREQ, records the metric and hop count to the root MP, and then transmits the
33 updated PREQ. Information about the presence of and distance to available root MP(s) is disseminated to all
34 MPs in the network.
35
36
37 Each MP may receive multiple copies of a proactive PREQ, each traversing a unique path from the root MP
38 to the MP. An MP updates its current path to the root MP if and only if the PREQ contains a greater
39 sequence number, or the sequence number is the same as the current path and the PREQ offers a better
40 metric than the current path to the root MP. The processing of the proactive PREQ is the same as in the on-
41
demand mode described in 11A.8.1.2.
42
43
44 If the proactive PREQ is sent with the “Proactive PREP” bit set to 0, the recipient MP may send a proactive
45 PREP if required (for example, if the MP has data to send to the root MP and requires establishing a
46 bidirectional path with the root MP). If the PREQ is sent with a “Proactive PREP” bit set to 1, the recipient
47 MP shall send a proactive PREP. The proactive PREP establishes the path from the root MP to the MP.
48
49 When the path from an MP to a root MP changes, and the root MP PREQ was sent with a “Proactive PREP”
50 bit set to 1, the recipient MP shall send a proactive PREP to the root MP containing the addresses of the MPs
51 that have established a path to the root MP through the current MP.
52
53
54 11A.8.1.3.2 Proactive RANN mechanism
55
56 The root MP periodically floods a RANN message into the network. The information contained in the
57 RANN is used to disseminate path metrics to the root MP.
58
59
60 Upon reception of a RANN, each MP that has to create or refresh a path to the root MP sends a unicast
61 PREQ to the root MP via the MP from which it received the RANN.
62
63 The unicast PREQ follows the same processing rules defined in the on demand mode.
64
65

IEEE P802.11s/D1.05, June 2007
1 The root MP sends a PREP in response to each PREQ. The unicast PREQ creates the reverse path from the
2
3 root MP to the originating MP, while the PREP creates the forward path from the MP to the root MP.
4
5
6 When the path from an MP to a root MP changes, it may send a PREP with the addresses of the MPs that
7 have established a path to the root MP through the current MP.
8
9 11A.8.2 Parameters for Extensible Path Selection Framework
10
11
12 Table s49 gives the parameters of HWMP for the Extensible Path Selection Framework.
13
14
15 Table s49—Parameters of HWMP for Extensible Path Selection Framework
16
17
18 Path Selection Protocol ID See Table s3 in 7.3.2.54.1.
19
20 Data type of metric field As defined by active path selection metric
21
23
24 Operator for metric aggregation As defined by active path selection metric
25 Comparison operator As defined by active path selection metric
26
27 Initial value of path metric As defined by active path selection metric
28
29
30
31 11A.8.3 Definitions
32
33
34 This subclause describes terminology for HWMP. Figure s77 illustrates an example utilizing this terminol-
35 ogy.
36
37
38
39 Forward Path
40
41
42
43 Path Intermediate Intermediate Intermediate Path
44 Originator 1 2 3 Target
45
46
47
48
49 Reverse Path
50
51
52
53
54 Figure s77—Illustration of definitions
55
56
57 The following definitions are made within the context of a single PREQ/PREP action frame pair (path dis-
58 covery).
59
60 — path originator: The path originator is the MP that triggers the path discovery.
61 — path originator address: The MAC address of the path originator.
62
63 — path target: The path target is the MP to which the path originator attempts to establish a path.
64
65 — path target address: The MAC address of the path target.

IEEE P802.11s/D1.05, June 2007
1 — intermediate MP: The intermediate MP is the MP which participates in path selection and is neither
2 path originator nor path target.
3
4 — intermediate MP address: The MAC address of the intermediate MP.
5 — forward path: The forward path is the path to the path target, set up at the path originator and inter-
6
7 mediate MPs.
8 — reverse path: The reverse path is the path to the path originator, set up at the path target and inter-
9 mediate MPs.
10
11 — forwarding information: The forwarding information maintained by an intermediate MP that
12 allows the MP to perform its path selection and forwarding functions.
13
14 The terminology used when discussing Forwarding Information is relative to the MP (reference MP)
15 and a particular destination of the path. The following terms are specific to a given instance of the
16 Forwarding Information.:
17
18 —destination MP: The end point of a path.
19 —destination MP address: The MAC address of the path destination.
20
21 —next hop MP: The next hop MP is a peer MP on the path to the destination MP.
22 —next hop MP address: The MAC address of the next hop MP.
23
24 —precursor MP: A precursor MP is an MP that identifies a given MP as the next hop MP to
25 some destination MP.
26
27 —precursor MP address: The MAC address of the precursor MP.
28
29 Table s50 shows the roles of the various MPs in the Forward Path and Reverse Path generated as a result of
30 the full path PREQ/PREP processing as shown in Figure s77. Each row in the table contains the roles of a
31
32 forward/reverse path from the reference MP’s perspective.
33
34
35 Table s50—Precursor and Next Hop Examples
36
37
38
39 Forward Path (to Path Target)
40
41
Reference MP Precursor MP Next Hop MP Destination MP
42
43
Path Originator N/A Intermediate 1 Path Target
44
45 Intermediate 2 Intermediate 1 Intermediate 3 Path Target
46
47 Path Target Intermediate 3 N/A Path Target
48
49
50 Reverse Path (to Path Originator)
51
52
53 Reference MP Precursor MP Next Hop MP Destination MP
54
55 Path Originator Intermediate 2 N/A Path Originator
56 Intermediate 2 Intermediate 3 Intermediate 1 Path Originator
57
58 Path Target N/A Intermediate 3 Path Originator
59
60
61
62
63
64 — unknown destination: A destination MP is considered unknown if the MP does not have any for-
65 warding information for that MP.

IEEE P802.11s/D1.05, June 2007
1 — unreachable destination: A destination MP is considered unreachable if the MP does not have valid
2 forwarding information for that MP.
3
4 — destination sequence number (DSN): The sequence number of the MP when the MP is referred to
5 as the destination. The destination sequence number is used to distinguish newer from older for-
6 warding information to the destination MP. See also 11A.8.4.2.
7
8 — target sequence number: The sequence number of the MP when the MP is referred to as the path
9 target. It is only used in PREQ/PREP during the establishment of the path.
10
11 — time-to-live (TTL): An integer number that is used to limit the number of hops an HWMP Informa-
12 tion Element may be processed and propagated. Note that this TTL is not related to the TTL in the
13 mesh header (see 7.1.3.5a).
14
15 — root MP: A root MP is the root of a path selection tree.
16
— dependent MP: An MP that has a Next Hop MP on the path to the Root MP.
17
18
19
20
21 11A.8.4 General rules for processing HWMP information elements
22
23
24 This subclause describes the rules for the processing of the following components of the HWMP messages
25 and information elements:
26
27
— Destination Sequence Number
28 — TTL
29
30 — Metric
31
32 Note: It is assumed that the receiving MP only receives HWMP messages from MPs with which it has estab-
33
34
lished a secure link. Therefore, all HWMP messages received are presumed to have originated in the same
35 mesh network that the receiving MP belongs to.
36
37 11A.8.4.1 HWMP propagation
38
39
40 Many HWMP information elements are intended to be processed and propagated across a mesh by MPs.
41 Each propagation is subject to certain rules or limitations as explained in the following subclauses. Certain
42 parameters in the HWMP information elements are updated during the propagation. See 11A.8.8, 11A.8.5,
43 11A.8.6, and 11A.8.7.
44
45
46 The originator of an HWMP information element sets the initial value of TTL. The MP which receives the
47 HWMP information element shall propagate it if the TTL value is greater than zero. Before propagating the
48 HWMP information element, the MP decrements the TTL value.
49
50
51 In general, the propagation of an HWMP information element is not subject to a delay. Exception exists for
52 the RANN information element as described in 11A.8.8.
53
54
55 11A.8.4.2 Destination Sequence Number (DSN)
56
57 The DSN is included in the RANN, PREQ or PREP information elements. The DSN is updated whenever an
58 MP receives new (i.e. not stale) information about the sequence number from a PREQ, PREP or PERR that
59
60 may be received related to that destination MP. HWMP depends on each MP in the network to own and
61 maintain its destination sequence number to guarantee the loop-freedom of all paths towards that MP. A des-
62 tination MP increments its own sequence number in two circumstances:
63
64 — Immediately before an MP originates a path discovery, it shall increment its own sequence number.
65 This prevents conflicts with previously established reverse paths towards the originator of a PREQ.

IEEE P802.11s/D1.05, June 2007
1 — Immediately before a destination MP originates a PREP in response to a PREQ, it shall update its
2 own sequence number to the maximum of its current sequence number and the destination sequence
3
number in the PREQ.
4
5
6 Sequence numbers are processed as follows:
7
8 a) Sequence numbers are incremented as unsigned integers.
9 b) When checking the freshness of received path information, the receiving MP compares its value of
10
11
the stored sequence number with that in the incoming HWMP message using signed 32-bit arith-
12 metic. This is necessary to assure correct results if the sequence number rolls over (changes to zero).
13 If the result of subtracting the stored sequence number from the incoming sequence number is less
14 than zero, then the information in the HWMP message is stale and shall be discarded.
15
16
17 In general, when an MP receives an information element with a DSN that is less than the last received DSN
18 for that originator, it discards the received information element. If they are the same, the outcome (informa-
19 tion element discarded or not) depends on the type of the information element and some additional condi-
20 tions. These cases are noted in the applicable information element descriptions.
21
22
23 The only other circumstance in which an MP may change the destination sequence number in one of its for-
24 warding information entries is in response to a lost or expired link to the next hop towards that destination
25 MP. The MP determines which destinations use a particular next hop by consulting its forwarding informa-
26 tion. In this case, for each destination that uses the next hop, the MP increments the sequence number and
27
28 marks the path as invalid (see also 11A.8.7). Whenever any forwarding information containing a sequence
29 number at least equal to the recorded sequence number for an affected destination is received by an MP that
30 has marked that forwarding information as invalid, the MP shall update its forwarding information accord-
31 ing to the information contained in the update.
32
33
34 An MP may change the sequence number in the forwarding information of a destination MP if the link to the
35 Next Hop MP towards the destination MP breaks.
36
37
11A.8.4.3 Metric of last link
38
39
40 The term metric of last link specifies the current link metric between the transmitter of the information ele-
41 ment under consideration and the MP that received this information element. The latter is the MP under con-
42 sideration.
43
44
45 11A.8.4.4 Forwarding information
46
47
48
The forwarding information consists of at least a destination MP address, the Destination Sequence Number
49 (DSN), the Next Hop address, the path metric, the precursor list, and the lifetime of this forwarding informa-
50 tion. Stored forwarding information can be active and inactive. The latter means that the forwarding infor-
51 mation is still known for future reference but not used for forwarding. The Forwarding Information becomes
52 inactive when either the MP receives a RERR regarding the destination MP or the information is no longer
53
54
active according to the lifetime.
55
56 11A.8.4.5 Creation and update of forwarding information
57
58
59 HWMP path selection information elements create or update the forwarding information in the MPs that
60 process these information elements. The creation and update of forwarding information follows the same
61 rules for PREQ, PREP, and RANN. These rules are given below. Unless otherwise noted, the term
62 “HWMP_IE” stands for the information element under consideration (PREQ, PREP, or RANN). In the fol-
63 lowing text, the “Æ” indicates an entry into the local forwarding data base, i.e., the path selection table.
64
65

IEEE P802.11s/D1.05, June 2007
1 1) If the MP does not have any valid forwarding information to the originator of the HWMP_IE
2
3 (hwmp_ie.originator_address), the value of the destination sequence number is set to
4 hwmp_ie.destination_sequence_number (field: destination_sequence_number), it creates this
5 information from the field hwmp_ie.originator_address (field: destination), the transmitter address of
6
7
the management frame containing the HWMP_IE (field: next hop), the accumulation of the value of
8 field hwmp_ie.metric with the metric of the last link (field: path metric), and the value of field
9 hwmp_ie.lifetime (field: lifetime).
10
11 2) If the MP does not have any valid forwarding information to the transmitter of the HWMP_IE, it creates
12 this information from the transmitter address of the management frame containing the HWMP_IE
13 (field: destination and next hop), the destination sequence number is set to invalid, the metric of the last
14
15 link (field: path metric), and the value of field hwmp_ie.lifetime (field: lifetime).
16 3) If the MP has valid forwarding information to the originator of the HWMP_IE
17
18 (hwmp_ie.originator_address), and the acceptance criteria of the corresponding element as described in
19 11A.8.8.3.1, 11A.8.5.3.1, 11A.8.6.3.1, 11A.8.7.3.1 are satisfied, then the MP updates this forwarding
20 information with the transmitter address of the management frame containing the HWMP_IE (field:
21
22 next hop), the value of the destination sequence number is set to
23 hwmp_ie.destination_sequence_number (field: destination_sequence_number), the accumulation of the
24 value of field hwmp_ie.metric with the metric of the last link (field: path metric), and the larger one of
25
26
the lifetime of the stored forwarding information and the value of field hwmp_ie.lifetime (field:
27 lifetime).
28
4) If the MP has valid forwarding information to the transmitter of the HWMP_IE and if the path metric of
29
30 this information is worse than the metric of the last link, then the MP updates this forwarding
31 information with the transmitter address of the management frame containing the HWMP_IE (field:
32 next hop), the destination sequence number is set to invalid, the metric of the last link (field: path
33
34 metric), and the larger one of the lifetime of the stored forwarding information and the value of field
35 hwmp_ie.lifetime (field: lifetime).
36
37
38 11A.8.4.6 Repeated attempts at path discovery
39
40 EDITORIAL NOTE—This text moved from “Note 1” in PREQ clause, per CID 1446
41
42
43 Repeated attempts by an MP at path discovery towards a given (set of) destination(s) shall be limited to
44 HWMP_MAX_PREQ_RETRIES and utilize a binary exponential backoff between transmissions. The
45 minimum waiting time for the PREP corresponding to a PREQ is 2 *
46
47 HWMP_NETDIAMETER_TRAVERSAL_TIME.
48
49 11A.8.4.7 Rate of sequence number changes
50
51
52 In order to improve path stability (and further reduce overhead), an MP may use the same Originator Desti-
53 nation Sequence Number (Originator DSN) for a certain time interval. The Originator DSN shall be incre-
54
mented only after at least HWMP_NETDIAMETER_TRAVERSAL_TIME has elapsed since the previous
55
56 increment. This mechanism prevents MPs from changing the path frequently to the source every time the
57 source sends a burst of PREQs within a very short time. This element of the protocol allows a source MP to
58 immediately initiate on-demand path discovery to a new destination without affecting recently refreshed
59 paths to the source in other MPs.
60
61
62 11A.8.5 Path Request (PREQ)
63
64
65 This subclause describes the function, generation and processing of the Path Request information element.

IEEE P802.11s/D1.05, June 2007
2
3
4 The Path Request (PREQ) element, described in 7.3.2.74, is used for three purposes:
5 — Discovering a path to one or more destinations
6
7 — Building a proactive (reverse) path selection tree to the root MP
8 — Confirming a path to a destination (optional)
9
10
11
12 11A.8.5.2 Conditions for generating and sending a PREQ
13
14
15 An MP shall send a PREQ element in a PREQ frame in the following cases:
16
17 Case A: Original Transmission (Path Discovery)
18
20 • The MP needs to establish an on-demand path to one or more destination MPs or the proxy of a
21 given destination for which there is no ongoing path discovery initiated by this MP.
22 • The MP has not sent more than (HWMP_PREQ_RATELIMIT – 1) path request messages during
23 the last second. If this is the case, the transmission of the PREQ has to be postponed until this
24
25 condition becomes true.
26 • The MP has not made more than (HWMP_MAX_PREQ_RETRIES – 1) repeated attempts at
27 path discovery towards the destination of the PREQ.
28 The content of a PREQ element in Case A shall be as shown in Table s51.
29
30
31
32 Table s51—Content of a PREQ element in Case A
33
34
35 Field Value
36
37 ID Value given in Table 7.26 for the PREQ element
38 Length 27 + N*11
39
40 Flags Bit 0: 0 (no portal role)
41 Bit 1: 0 (broadcast)
42 Bit 2: 0 (no proactive PREP applicable)
43 Bit 3 – 5: Reserved
44 Bit 6: Address Extension (AE) (1=if (destination_count=1 and prox-
45 ied address present), 0=otherwise)
46 Bit 7: Reserved
47
48 Hop Count 0
49
50 Time to Live Maximum number of hops allowed for this information element, e.g.,
51 HWMP_NET_DIAMETER.
52
53 PREQ ID Previous PREQ ID + 1
54 Originator Address MAC address of the originator of the PREQ
55
56 Originator’s Destination Sequence Previous Originator DSN + 1. See Note 2
57 Number
58
59 Proxied Address Present only if Bit 6 in Flags = 1. This value is set to the proxied
60 address which is the source of the frame.
61
62 Lifetime The time for which MPs receiving the PREQ consider the forwarding
63 information to be valid, e.g. HWMP_ACTIVE_ROOT_TIMEOUT.
64

IEEE P802.11s/D1.05, June 2007
1 Table s51—Content of a PREQ element in Case A

2
3
4 Destination Count (N)
5
6 Per Destination Flags DO flag, RF flag, as required
7 Destination Address MAC address of requested destination
8
9 Destination Sequence Number The latest sequence number received in the past by the originator for
10 any path towards the destination.
11
12
13
14
15
16 Case B: Original Transmission (Path Maintenance) (optional implementation enhancement)
18 • the MP has a path to a given destination that is not a Root MP
19
20 • the HWMP_PATH_MAINTENANCE_INTERVAL has expired
21
22
23 The content of a PREQ in Case B shall be as shown in Table s52.
24
25
26 Table s52—Content of a PREQ element in Case B
27
28
29 Field Value
30
32
34
39 Bit 6: 0 (no address extension)
40 Bit 7: Reserved
41
42 Hop Count 0
43 Time to Live Maximum number of hops allowed for this information element =
45
46 PREQ ID Previous PREQ ID +1
47
49
50 Originator’s Destination Sequence Originator DSN + 1. See Note 2 under Case A.
51 Number
52
56
57 Destination Count N
58
59 DO flag = 1
60 Per Destination Flags RF flag = 0
61
62 Destination Address MAC Address of destination
63
64 Destination Sequence Number The latest destination sequence number for this destination known to the
65 originator

IEEE P802.11s/D1.05, June 2007
1
2
3
Case C: Root Path Confirmation.
5 • the MP has a path to a Root MP that broadcasts RANNs
6 • the HWMP_PATH_CONFIRMATION_INTERVAL has expired
7
8
9
10 The content of a PREQ element in Case C shall be as shown in Table s53.
11
12
13
Table s53—Content of a PREQ element in Case C
14
15
16 Field Value
17
18
ID Value given in Table 7.26 for the PREQ element
19
21
23 Bit 1: 1 (individually addressed)
27 Bit 7: Reserved
28
29 Hop Count 0
30
31 Time to Live 1
32
PREQ ID Not used
33
35
36 Originator’s Destination Sequence Originator DSN + 1. See Note 2 under Case A.
37 Number
38
41
43
Destination Count 1
44
45 Per Destination Flags DO flag = 1,
46 RF flag = 0
47
48 Destination Address Root MP MAC Address
49
50 Destination Sequence Number The latest destination sequence number for this destination known to
51 the originator
52
53
54
55
56 Case D: PREQ Forwarding
57
58 Case D1 (destination count = 1, no PREP generation):
60 • the MP has received and accepted a PREQ – See 11A.8.5.3.1
61 • Destination_count = 1
62
• the MP is not the destination of the PREQ OR the destination of the PREQ is the MAC broadcast
63
64 address (all 1’s)
65 • the MP is not the proxy of the destination address

IEEE P802.11s/D1.05, June 2007
1 • the MP has no valid forwarding information for the requested destination

2 • [Destination Only flag of the destination in the PREQ is ON (DO = 1)]
3
OR
4
5 [{Destination Only flag of the destination in the PREQ is OFF (DO = 0)} AND {MP has no
6 active forwarding information for the requested destination preq.destination_address}]
7
8
9 The content of a PREQ element in Case D1 shall be as shown in Table s54.
10
11
12 Table s54—Content of a PREQ element in Case D1
13
14
15 Field Value
16
18
19 Length 37
20
Flags As received
21
23
25
26 PREQ ID As received
27
29
Originator’s Sequence Number As received
30
31 Proxied Address As received. This field is only present if Bit 6 of the Flags field (AE
32 flag) is set to 1.
33
34 Lifetime As received
35
36 Metric As received ⊕ own metric toward transmitter of received PREQ
37
38 Destination Count 1
39
Per Destination flags #1 As received
40
41 Destination MAC address #1 As received
42
43 Destination Sequence Number #1 As received
44
45
46
47
48
Case D2 (destination count = 1, PREP generation as intermediate MP):
49
52 • preq.destination_count = 1
53 • the MP is not the destination of the PREQ
54
55
• the MP has active forwarding information for the requested destination preq.destination_address
56 • Destination Only flag of the destination in the PREQ is OFF (DO = 0)
57 • Reply and Forward flag of the destination in the PREQ is ON (RF = 1)
58
59
60 The contents of a PREQ element in Case D2 shall be as shown in Table s55.
61
62
63 Case D3 (destination count > 1): All of the following applies
65 • there is at least one requested destination left after processing the PREQ according to 11A.8.5.3.

IEEE P802.11s/D1.05, June 2007
1 Table s55—Contents of a PREQ element in Case D2

2
3
4 Field Value
5
7
8 Length 37
9
12
14
16
18
19 Originator’s Sequence Number As received
20 Proxied Address As received. This field is only present if Bit 6 of the Flags field (AE
21 flag) is set to 1.
22
24
25 Metric As received ⊕ own metric toward transmitter of received PREQ
26
28
29 Per Destination flags #1 Bit 0 (DO): 1 (set to 1 before forwarding because MP sent a PREP)
30 Bit 1 (RF): As received
31 Destination MAC address #1 As received
32
33 Destination Sequence Number #1 As received
34
35
36
37
38 The contents of a PREQ element in Case D3 shall be as shown in Table s56.
39
40
41
43
44
45 Field Value
46
48 Length 26 + N * 11
49
51
53
55
58
59 Originator’s Sequence Number As received
60
62
63 Metric As received ⊕ own metric toward the transmitter of the received
64 PREQ
65

IEEE P802.11s/D1.05, June 2007

2
3
4 Destination Count 1 ≤ destination count ≤ received destination count
5
6 received destination count less the number of requested
7 destinations, for which the processing MP
8
9 — is the destination or
10 — has active forwarding information for the requested
11
destination and the corresponding Destination Only
12
13 flag is off (DO=0) and Reply and Forward flag is on
14 (RF = 1)
15
16 Per Destination Flags #A As received
17
Destination MAC address #A As received
18
19 Destination Sequence Number #A As received
20
21 Per Destination Flags #B Bit 0 (DO): 1 (set to 1 because MP sent PREP)
22 Bit 1 (RF): As received
23
24 Destination MAC address #B As received
25
26 Destination Sequence Number #B As received
27
28
29 For the per destination fields (per destination flags, destination MAC address, destination sequence number)
30
31 assume the following:
32
33 — destination #A: If destination A would have been the only requested destination, it would generate a
34 PREQ for forwarding according to case D1.
35
36 — destination #B: If destination B would have been the only requested destination, it would generate a
37 PREQ for forwarding according to case D2.
38
39
40
41
42
43 Case E: Proactive PREQ (original transmission)
44
46
47 • The Root MP is configured to send proactive root PREQs
48
49 • The Root Announcement interval has expired
50
51
52
53
54
55 The contents of a PREQ in Case E shall be as shown in Table s57.
56
57
58 Table s57—Contents of a PREQ in Case E
59
60
61 Field Value
62
64
65 Length 37

IEEE P802.11s/D1.05, June 2007
1 Table s57—Contents of a PREQ in Case E

2
3
4 Flags Bit 0: As needed (portal role)
6 Bit 2: As needed (proactive PREP)
9 Bit 7: Reserved
10
11 Hop Count 0
12 Time to Live Maximum number of hops allowed for this information element, e.g.
14
15 PREQ ID Previous PREQ ID + 1
16
17 Originator Address root MP MAC address
18
19 Originator’s Destination Sequence Previous DSN of root MP + 1
20 Number
21
22 Lifetime HWMP_PATH2ROOT_TIMEOUT (shall be greater than
23 ROOT_ANNOUNCEMENT_INTERVAL)
25
27
28 Per Destination Flags DO = 1,
29 RF = 1
30
31 Destination Address Broadcast address
32
33 Destination Sequence Number 0
34
35
36
37
38
39 11A.8.5.3 PREQ processing
40
41 Received PREQ elements are subject to certain acceptance criteria. Processing and actions taken depend on
42
43 the contents of the PREQ and the information available to the receiving MP.
44 See also 11A.8.4: General rules for message processing
45
46
47
49
50 The PREQ is discarded if any of the following is true:
51
52 — The Originator DSN < previous Originator DSN
53 — (DSN = previous DSN) AND (updated path metric is worse than previous path metric)
54
55
56
57
Otherwise, the PREQ information element is accepted.
58
59
61
63
64
65 The following applies only to a PREQ that has not been discarded:

IEEE P802.11s/D1.05, June 2007
1
2
3 1. The receiving MP shall record the PREQ ID, the Originator Address, and entries for each
4 destination MAC Address and DSN
5 2. The receiving MP shall update the active forwarding information it maintains for the originator and
6
7 previous hop MPs of the PREQ (see 11A.8.4.5)
8 3. If the MP is addressed by the PREQ or is the proxy of the destination MAC address it shall initiate
9 the transmission of a PREP to the originator (11A.8.6.2 Case A). If the PREQ carries a proxied
10
11 address (indicated by the AE flag), the MP shall update its proxy information with the proxied
12 address and set the PREQ originator address as the corresponding proxy.
13 4. If step 3 was not applicable for the MP and the AE flag in the PREQ is set to 1, the MP may update
14
15 its proxy information with the proxied address and set the PREQ originator address as the
16 corresponding proxy.
17 5. If the MP has valid forwarding information to any of the requested destinations and the DO flag for
18
19
such a destination is OFF (DO=0), it initiates the transmission of a PREP to each of these
20 destinations (see 11A.8.6.2 Case A)
21 6. If there are destinations in the PREQ that have been not processed in steps 3 or 4 or that have been
22
23
processed in step 4 but the corresponding Reply and Forward Flag is ON (RF = 1), the receiving
24 MP shall forward the PREQ as defined in 11A.8.5.2, Case D.
25 7. If the MP is initiating a PREP transmission on behalf of another destination (intermediate reply), it
26
should update its forwarding information by placing the last hop MP (from which it received the
27
28 PREQ) into the precursor list for the forward path entry for the destination. In addition, this
29 intermediate MP also updates its forwarding information for the MP originating the PREQ by
30 placing the next hop toward the destination in the precursor list for the reverse path entry.
31
32
33 11A.8.6 Path Reply (PREP)
34
35 This subclause describes the function, generation and processing of the Path Reply information element.
36
37
39
40 The Path Reply (PREP) element is transmitted in individually addressed frames and is described in 7.3.2.75.
41
42 The purpose of the PREP is:
43 — to confirm the forward path to a destination and
44
45 — to establish a reverse path to the originator.
46
47
48
49 11A.8.6.2 Conditions for generating and sending a PREP
50
51
52
An MP sends out a PREP element in a PREP frame in the following cases:
53
55
56 A PREP is transmitted if the MP has received a PREQ fulfilling all of the following conditions:
57 a. One of the following applies:
58 o The Destination Address of the PREQ is the same as MAC address of the receiving
59
60 MP
61 o The Destination Address of the PREQ = all 1’s (broadcast) and the PREP flag is set to
62 1 (”Proactive PREP”)
63
64 o The Destination Address of the PREQ is currently proxied by the MP
65 b. One of the following applies:

IEEE P802.11s/D1.05, June 2007
1 o The Originator DSN of the PREQ (preq.orig_dsn) is greater than the DSN of the last
2
3 PREQ received from the same originator address (that includes the case that there is
4 no path to the originating MP)
5 o The Metric is better than the path selection metric currently associated with the
6
7 Originator Address and the Originator DSN of the PREQ (preq.orig_dsn) is equal to
8 the DSN of the last PREQ received from the same originator address
9
10
11 The content of the generated PREP in Case A shall be as shown in Table s58.
12
13
14 Table s58—Contents of a PREP element in Case A
15
16
17 Field Value
18
19 ID Value given in Table 7.26 for the PREP element
20
22 Flags Bit 0 – 5: Reserved
23 Bit 6: Address Extension (AE) (1 = proxied device address present,
24 0 = otherwise)
25 Bit 7: Reserved
26
27 Hop Count 0
28
29 Time to Live Maximum number of hops allowed for this element
30
31 Destination Address MAC address of the originator of the PREP
32
33 Destination Sequence Number Sequence number of the target of the PREQ after it has been incre-
34 mented
35 Destination Proxied Address Proxied address on behalf of which the PREP is sent. Present only if
36 Bit 6 (AE) in Flags = 1.
37
38 Lifetime As per the PREQ that triggered the transmission of this PREQ
39
41
42 Originator Address MAC address of the originator (of the PREQ)
43
44 Originator Sequence Number Sequence number of the originator (of the PREQ)
45 Dependent MP Count N N
46
47 Dependent MP MAC Address # MAC address of dependent MP
48
49 Dependents MP DSN # Destination sequence number associated with the MAC address of
50 the dependent MP.
51
52
53
54 Note: the DA of the action frame carrying the PREP element is set to the Originator Address
55
value in the PREQ that triggered the PREP.
56
57
58 Case B: PREP Propagation
59
60
A PREP is propagated if all of the following applies:
61 1. the MP has received and accepted the PREP – See 11A.8.6.3.1
62 2. the MP is not the destination of the PREP
63
64
65 The contents of a PREP element in Case B shall be as shown in Table s59.

IEEE P802.11s/D1.05, June 2007
1 Table s59—Contents of a PREP element in Case B

2
3
4 Field Value
5
6 ID Value given in Table 7.26 for the PREP ele-
7 ment
8
10
13
15
16 Destination Address As received
17
18 Destination Sequence Number As received
19
20 Destination Proxied Address As received
22
23 Metric As received ⊕ own metric toward the trans-
24 mitting MP
25
27
28 Originator Sequence Number Sequence number of the originator (of the
29 PREQ)
30
32 Dependent MP MAC Address # MAC address of the dependent MP
33
34 Dependent MP DSN # Destination sequence number associated with
35 the MAC address of the dependent MP
36
37
38
39
40
41
Note: the DA of the action frame carrying the PREP element is set to the address of the next hop
42 to the Originator Address of the PREQ or RANN that triggered the PREP.
43
44
45 Case C: Intermediate reply
46 A PREP is transmitted if the MP has received a PREQ fulfilling all of the following conditions:
47
48 1. The PREQ Destination Only flag is set to 0
49 2. The receiving MP has active forwarding information with:
50
51 a. A destination that is the same as the Destination Address of the PREQ
52 b. A DSN that is greater than or equal to the DSN of the PREQ (preq.dest_dsn)
53
c. A non-zero lifetime
54
55
56 The content of the generated PREP in Case C shall be as shown in Table s60.
57
58
59
60 Table s60—Contents of a PREP element in Case C
61
62
63 Field Value
64

IEEE P802.11s/D1.05, June 2007
1 Table s60—Contents of a PREP element in Case C

2
3
5
6 Flags Bit 0: 0
7 Bits 1– 7: Reserved
8 Hop Count 0
9
11
12 Destination Address Destination MAC address from the PREQ
13
14 Destination Sequence Number DSN of the stored forwarding information of the Destination MAC
15 address of the PREQ
16
17 Destination Proxied Address As received
19
20 Metric Value of path metric taken from the active forwarding information
21 for the destination address of the PREQ
22
24
26
29
30 Dependent MP DSN # Destination sequence number associated with the MAC address of
31 the dependent MP
32
33
34
35
36
Case D: PREP in Proactive PREP mode
37
39 — The MP has received a PREQ broadcast with the “Proactive PREP” flag set to 0.
40
41 — The MP needs the root MP to establish a path to itself
42
43 The content of the generated PREP in Case D shall be as shown in Table s61.
44
45
46 Table s61—Contents of a PREP element in Case D
47
48
49 Field Value
50
52
54
55 Flags Bit 0: 0
56 Bits 1– 7: Reserved
57 Hop Count 0
58
60
61 Destination Address MAC address of the originator of the PREP
62
63 Destination Sequence Number DSN of the originator of the PREP
64
65 Destination Proxied Address 0

IEEE P802.11s/D1.05, June 2007
1 Table s61—Contents of a PREP element in Case D

2
3
5
8
10
12
14
15 Dependent MP DSN # Destination sequence number associated with the MAC address of
16 the dependent MP
17
18
19 11A.8.6.3 PREP processing
20
21
22 Received PREP elements are subject to certain acceptance criteria. Processing and actions taken depend on
23 the contents of the PREP and the information available to the receiving MP.
24
25
27
28
29 The PREP is discarded if any of the following is true:
30 — The DSN < previous DSN from this originator
31
32 — The Time to Live is 1 or less
33
34
35
11A.8.6.3.2 Effect of receipt
36
37 The following applies only to a PREP that has not been discarded
38
39
40 1) The receiving MP shall record the Originator Address, together with the DSN, hopcount and metric
41
42 according to the rules defined in 11A.8.4.5.
43 2) The receiving MP may record the list of dependent MPs if present in the PREP.
44
45 3) If the receiving MP is not the final destination of the PREP, the PREP is propagated as per Case B
46 above.
47 4) If the receiving MP is the final destination of the PREP and the AE-flag is set, the MP shall store the
48
49 proxy information with the destination proxied address and shall set the corresponding proxy as the
50 destination MP address.
51
5) If the receiving MP is not the final destination of the PREP and the AE-flag is set, the MP may store the
52
53 proxy information with the destination proxied address and sets the corresponding proxy as the
54 destination MP address.
55
56 6) If the MP propagates the PREP, the precursor list for the Destination Address is updated by adding the
57 next hop MP to which the PREP is propagated. In addition, at the MP the precursor list for the originator
58 address is updated by adding the next hop MP towards the Destination Address.
59
60
61 11A.8.7 Path Error information element (PERR)
62
63
This subclause describes the function, generation and processing of the path error information element.
64
65

IEEE P802.11s/D1.05, June 2007
2
3
4
The PERR information element is used for announcing a broken link to all traffic sources that have an active
5 path over this broken link. The active forwarding information associated with the unreachable destinations
6 should no longer be used for forwarding.
7
8 A PERR element may be either broadcast (if there are many precursors), unicast (if there is only one precur-
9
10 sor), or iteratively unicast to all precursors depending on the size of precursor list for the destinations. The
11 PERR element should contain those destinations that are part of the created list of unreachable destinations
12 and have a non-empty precursor list. The peer MPs that should receive the PERR are all those that belong to
13 a precursor list of at least one of the unreachable destination(s) in the newly created PERR.
14
15
16 A PERR information element is propagated by MPs receiving a PERR if certain conditions are fulfilled.
17
18 An MP generating or receiving a PERR may decide to establish paths to unreachable destinations using any
19 of the available HWMP mechanisms.
20
21
22 11A.8.7.2 Conditions for generating and sending a PERR
23
24 An MP sends out a PERR in the following cases:
25
26
28
29
All of the following applies:
30 • The MP detects a link break to the next hop of an active path in its stored forwarding information
31 while transmitting frames to it. Note: the detection may be triggered by the fact that an MP is
32 unable to forward a data frame to a next hop MP.
33 • The MP did not send more than HWMP_PERR_RATELIMIT – 1 PERR messages during the
34
35
last second.
36
37 Actions before sending the PERR:
38 • The MP first makes a list of unreachable destinations consisting of the unreachable MP and any
39 additional destinations in the local forwarding table that use the unreachable MP as the next hop.
40
41 • The destination sequence numbers in all valid stored forwarding information of unreachable des-
42 tinations announced in this PERR shall be incremented.
43 • The stored forwarding information for each unreachable destination announced in this PERR
44 shall be invalidated.
45
46
47 The contents of a PERR element in Case A shall be as shown in Table s62.
48
49
50
Table s62—Contents of a PERR element in Case A
51
52
53 Field Value
54
55 ID Value given in Table 7.26 for the PERR element
56
57 Length 2 + N * 10
58
59 Mode Flags Bit 0 – 7: Reserved
60
61 Number of Destinations Number of announced unreachable destinations in PERR.
62 A destination is unreachable if its next hop in the stored forwarding
63 information is an unreachable neighbor.
64
65 Destination Address MAC address of detected unreachable destination #1

IEEE P802.11s/D1.05, June 2007
1 Table s62—Contents of a PERR element in Case A

2
3
4 Destination Sequence Number Last used DSN for Destination Address #1 + 1
5
6
7
8
9 Case B: PERR propagation
10
12
13 • The MP creates a list of unreachable destinations consisting of those destinations in the PERR
14 for which there exists valid forwarding information that has the transmitter of the PERR as the
15 next hop.
16 • The MP received a PERR from a neighbor for one or more of its active paths in its stored for-
17
18 warding information.
19 • The MP has not sent or forwarded more than HWMP_PERR_RATELIMIT – 1 PERR messages
20 during the last second.
21
22
23 The contents of a PERR element in Case B shall be as shown in Table s63.
24
25
26 Table s63—Contents of a PERR element in Case B
27
28
29 Field Value
30
31 ID Value given in Table 7.26 for the PERR element
32
33 Length 2 + N * 10
34
35 Mode Flags Bit 0 – 7: Reserved
36
Number of Destinations Number of announced unreachable destinations in PERR (≤
37
received value)
38
A destination is unreachable if its next hop in the corresponding
39
stored forwarding information is the transmitter of the received
40
PERR.
41
42 Destination Address MAC address of detected unreachable destination #1 (as received,
43 but maybe at different position in destination list)
44
45 Destination Sequence Number As received (but maybe at different position in destination list)
46
47
48
49
50
51
52 11A.8.7.3 PERR Reception
53
54 Received PERR elements are subject to certain acceptance criteria. Processing and actions taken depend on
55
56 the contents of the PERR and the information available to the receiving MP.
58
59
60
62
63 The PERR is not discarded if the following applies:
64
65 — The MP that receives the PERR has forwarding information stored where

IEEE P802.11s/D1.05, June 2007
1 • the destination is contained in the list of unreachable destinations of the PERR and
2 • the next hop is the transmitter of the received PERR
3
4
5
7
8 The following applies only to PERR that has not been discarded.
9
10 1) If the received sequence number for a referenced destination is higher than the current sequence
11 number for that destination, the receiving MP shall consider that destination unreachable and update
12 its stored information for that destination accordingly.
13
14 2) The receiving MP shall transmit a PERR as defined in 11A.8.8.2, Case B
15
16
17
18
19 11A.8.8 Root Announcement (RANN)
20
21 This subclause describes the function, generation and processing of the Root Announcement information ele-
22 ment.
23
24
26
27 The RANN element, described in 7.3.2.73, is used for announcing the presence of an MP configured as Root
28 MP. RANN elements are sent out periodically by the root MP.
29
30
31 The RANN information element propagates path metric information across the network so that each MP can
32 select a best metric path to the announced root MP. This mechanism allows bidirectional trees to be built,
33 using a robust procedure based on individually addressed frames initiated by the MPs. This ensures that the
34 root MP is aware of all MPs in the mesh.
35
36
37 Receiving MPs shall propagate the RANN as described below.
38
39 11A.8.8.2 Conditions for generating and sending a RANN
40
41
42 An MP sends out a RANN in the following cases:
43
44
45
Case A: Original transmission
46
48 •The MP is configured as a Root MP
49 •at every ROOT_ANNOUNCEMENT_INTERVAL
50
51
52 The contents of a RANN element in Case A shall be as shown in Table s64.
53
54
55 Table s64—Contents of a RANN element in Case A
56
57
58 Field Value
59
60 ID Value given in Table 7.26 for the RANN element
61
62 Length 21
63
64 Flags Bit 0: Portal Role (0 = non-portal, 1 = portal)

IEEE P802.11s/D1.05, June 2007
1 Table s64—Contents of a RANN element in Case A

2
3
4 Hop Count 0
5
7 Originator Address MAC address of the Root MP
8
9 Destination Sequence Number Last used DSN + 1
10
11 Lifetime HWMP_PATH2ROOT_TIMEOUT (shall be greater than
12 ROOT_ANNOUNCEMENT_INTERVAL)
13
14 Metric initial metric value (0 for airtime metric)
15
16
17
18
19 Case B: Forwarding
20
22
23
•the MP has received and accepted a RANN – See 11A.8.8.3
24 •RANN_PROPAGATION_DELAY has expired – See 11A.8.8.3.2
25
26 The contents of a RANN element in Case B shall be as shown in Table s65.
27
28
29
30 Table s65—Contents of a RANN element in Case B
31
32
Field Value
33
34
ID Value given in Table 7.26 for the RANN ele-
35
ment
36
38
40
42
43 TTL As received – 1
44
Originator Address As received
45
46 Destination Sequence Number As received
47
49
50 Metric As received ⊕ own link metric toward the
51 transmitting MP
52
53
54
55 11A.8.8.3 RANN Reception
56
57 Received RANN elements are subject to certain acceptance criteria. Processing and actions taken depend on
58
59 the content of the RANN and the forwarding information maintained by the receiving MP.
61
63
64
65 The RANN is discarded if any of the following is true:

IEEE P802.11s/D1.05, June 2007
1 — The DSN < previous DSN from this originator

2
3 — (DSN = previous DSN) AND (updated path metric is worse than previous path metric)
4
6
7
8 The following applies only to RANN that has not been discarded.
9
10
11 1) The receiving MP shall initiate a timer for RANN_PROPAGATION_DELAY.
12 2) The receiving MP may initiate a PREQ/PREP exchange with the root MP to set up or update a path to
13
14 the root MP. See PREQ, when generated, case C.
15 3) The receiving MP shall record the Originator Address, together with the DSN, hopcount, metric.
16
17 The receiving MP shall transmit a RANN as defined in 11A.8.8.2, Case B.
18
19 11A.8.9 Considerations for support of STAs without mesh functionality
20
21
22 The verification of disjunct MAC addresses between a non-AP STA without mesh functionality and MPs
23 during authentication/association of the non-AP STA (11.3.3) may be done by issuing a PREQ for the MAC
24 address of the non-AP STA by the AP with mesh functionality. The destination only flag of the PREQ shall
25 be set to 1.
26
27
28 The MAC address of the non-AP STA does already exist in the mesh network if the AP with mesh function-
29 ality receives a PREP for the MAC address of the non-AP STA and it can be derived from the PREP that the
30 requested MAC address is originated from an MP. (The AE flag of the PREP is set to 0, see clause 7.3.2.75).
31
32
33 11A.8.10 HWMP parameters
34
35
See T.2 for recommended parameter values.
36
37
38
39
40
41 11A.9 Radio Aware OLSR path selection protocol (Optional)
42
43
11A.9.1 Introduction
44
45
46 Radio Aware Optimized Link State Routing (RA-OLSR) protocol is a proactive, link-state wireless mesh
47 path selection protocol based on Optimized Link State Routing (OLSR) protocol [IETF RFC 3626] with
48 extensions from Fisheye State Routing (FSR) protocol and uses radio-aware metrics in forwarding path and
49
50 multipoint relay (MPR) set calculation. RA-OLSR enables the discovery and maintenance of optimal paths
51 based on a predefined metric, given that each MP has a mechanism to determine the metric cost of a link to
52 each of its neighbors. In order to propagate the metric link cost information between MPs, a metric field is
53 used in RA-OLSR information elements. In disseminating topology information over the network, RA-
54 OLSR adopts the following approaches in order to reduce the related control overhead:
55
56 — It uses only a subset of MPs in the network, called MPRs, in flooding process;
57
58 — It optionally controls (and thereby reduces) the element exchange frequencies based on the Fisheye
59 scopes.
60
61 The RA-OLSR protocol also includes an association discovery and maintenance protocol to support STAs
62
associated with MAPs). When a STA is a source or a destination of an IEEE 802 data link, RA-OLSR
63
64 protocol sets up a path selection path to the MAP or the MPP associated with the STA by complementing
65 path selection information among MPs with STA association information.

IEEE P802.11s/D1.05, June 2007
1 11A.9.2 Overview
2
3
4 The optimization in RA-OLSR mainly focuses on the minimization of flooding overhead: First, in RA-
5 OLSR only a selected subset of 1-hop neighbor MPs (i.e., MPRs) is used by an MP in forwarding
6 information elements. The MPRs are selected such that a broadcast element, forwarded by these MPRs, can
7
8
reach all 2-hop neighbor MPs of the selecting MP (i.e., MPR selector). The information required to perform
9 MPR selection is acquired through the periodic exchange of HELLO elements. In addition, RA-OLSR can
10 also optionally control the element exchange frequencies based on the fisheye scopes to further reduce the
11 amount of information elements exchanges. These techniques significantly reduce the number of forwarding
12 transmissions required to flood a element to all MPs in the network. Second, RA-OLSR requires only partial
13
14
link state to be flooded in order to provide best path paths. The minimal set of link state information required
15 is that all the MPs selected as MPRs shall declare the links to their MPR selectors. Additional topological
16 information, if present, may be utilized, e.g., for redundancy purposes.
17
18
19 In wireless mesh networks, associated STAs that do not support mesh services are indirectly participating in
20 path selection procedures through their associated MAPs. To support these STAs, RA-OLSR provides
21 information repositories for associated STAs at MAPs — Local Association Base (LAB) and Global
22 Association Base (GAB) — with efficient advertisement and management schemes, which complements a
23 path selection table at each MP during path selection process. For handling the association information (i.e.
24
25 LAB or GAB), RA-OLSR is designed to work in a distributed manner and also in a centralized manner
26 through active MPPs in the mesh network.
27
28
Given a network with only single-interface MPs, an MP may deduct the neighbor set directly from the
29
30 information exchanged as part of link sensing: the “Main Address” of a single interface MP is, by definition,
31 the address of the only interface on that MP. In a network with multiple-interface MPs, additional
32 information is required in order to map interface addresses to main addresses (and, thereby, to MPs). This
33 additional information is acquired through multiple interface declaration (MID) elements.
34
35
36 11A.9.2.1 Terminology
37
38
39 Terminology for RA-OLSR is listed in Table s66.
40
41
42 Table s66—Terminology for RA-OLSR
43
44
45
46 Terminology Description
47
48 Main Address Primary MAC address of the MP, if it has more than one PHY
49
50 Originator Address The main address of an MP, which sent a given element
51
52 Sender Interface Address The address of the interface, over which the element was last transmitted
53 Receiving Interface The interface, over which the element was received
54
55 Associated Station A station that is associated with an MAP
56
57 Local Association Base (LAB) The table of the associated stations to a given MAP
58
59 Global Association Base (GAB) The information base that maintains the list of the associated stations to all the
60 MAPs in the Mesh (in other terms, all the Local Association Base of all the
61 MAPs of the Mesh)
62
63 Association Tuple The information about associated stations is maintained in entries called “associ-
64 ation tuples”, either “Local Association Tuple”, in the LAB, or “Global Associa-
65 tion Tuple”, in the GAB

IEEE P802.11s/D1.05, June 2007
1 Table s66—Terminology for RA-OLSR

2
3
4 Checksum The value obtained by applying the CRC32 function to the information in the
5 LAB / GAB (or subsets of these Association Bases)
6
7
8
11A.9.3 Parameters for Extensible Path Selection Framework
9
10
11 Table s67 gives the parameters of RA-OLSR for the Extensible Path Selection Framework.
12
13
14
15 Table s67—Parameters of RA-OLSR for Extensible Path Selection Framework
16
17
Path Selection Protocol ID See Table s3 in 7.3.2.54.1.
18
19 Data type of metric field As defined by active path selection metric
20
22
23 Operator for metric aggregation As defined by active path selection metric
24
25 Comparison operator As defined by active path selection metric
26
Initial value of path metric As defined by active path selection metric
27
28
29
30
31 11A.9.4 Element processing and forwarding
32
33
34 Here we describe a general rule for processing and forwarding RA-OLSR elements (see 7.3.2.79 for details
35 and 7.4.11.5 for its format).
36
37
38 11A.9.4.1 Element processing and flooding
39
40
41 Upon receiving an RA-OLSR management frame, an MP examines each of the included elements. Based on
42 the “ID” value, the MP can determine the further processing of the element.
43
44
45 An MP may receive the same element several times in a wireless mesh network. Therefore, each MP
46 maintains a “Duplicate Set” where the MP records information about the most recently received elements,
47 by which any duplicate processing of those elements can be avoided. For such an element, an MP records a
48 “Duplicate Tuple” as follows:
49
50
51 (D_addr, D_seq_num, D_forwarded, D_iface_list, D_time)
52
53
54
55 Field Description
56
57 D_addr The originator address of the element
58
59 D_seq_num The element sequence number of the element
60
61 D_forwarded A boolean indicating if the element has already been forwarded
62
63 D_iface_list A list of the addresses of the interfaces on which the element has been received
64
65 D_time Expiration time of the tuple

IEEE P802.11s/D1.05, June 2007
1 In an MP, the set of Duplicate Tuples are denoted the “Duplicate set”.
2
3 Upon receiving an RA-OLSR management frame, an MP shall perform the following tasks for each
4
5
encapsulated element:
6 a) If the RA-OLSR frame contains no elements, the frame shall be silently discarded.
7
8 b) If the TTL of the element is less than or equal to zero, or if the element was sent by the receiving MP
9 (i.e., the Originator Address of the element is the main address of the receiving MP), then the ele-
10 ment shall be silently dropped.
11
12 c) Processing condition:
13 1) If there exists a tuple in the duplicate set, where:
14
15 D_addr = Originator Address, AND
16 D_seq_num = Sequence Number.
17
18 Then the element has already been processed and shall not be processed again.
19 2) Otherwise, if the MP implements the element type (i.e., element ID), the element shall be pro-
20
21
cessed according to the specifications for the element ID.
22 d) Forwarding condition:
23
24 3) If there exists a tuple in the duplicate set, where:
26
27 D_seq_num = Sequence Number, AND
28 the receiving interface (address) is in D_iface_list.
29
30 Then the element has already been considered for forwarding and should not be forwarded again.
31 4) Otherwise:
32
33 •If the MP implements the element type (i.e., element ID), the element shall be processed accord-
34 ing to the specifications of the element ID.
35 •Otherwise, the MP implements the element type (i.e. element ID), the element shall be pro-
36
37 cessed according to the default forwarding algorithm described in 11A.9.4.2.
38
39 11A.9.4.2 Default forwarding algorithm
40
41
The default forwarding algorithm is the following:
42
43 a) If the sender interface address of the element is not detected to be in the symmetric 1-hop peer of the
44 MP, the forwarding algorithm shall silently stop here (and the element shall not be forwarded).
45
46 b) If there exists a tuple in the duplicate set where:
48
50 Then the element is further considered for forwarding if and only if:
51
52 D_forwarded is false, AND
53
54
the (address of the) interface that received the element is not included among the addresses in
55 D_iface_list.
56 c) Otherwise, if such an entry doesn’t exist, the element is further considered for forwarding.
57
58
59
60 If the element is not considered for forwarding after steps a through c, the processing of this clause stops
61 here (i.e., steps d to h are ignored). Otherwise, the following algorithm is used:
62
63
64 d) If the sender interface address is an interface address of an MPR selector of this MP AND the TTL
65 of the element is greater than ‘1’, the element shall be forwarded (as described later in steps f to h).

IEEE P802.11s/D1.05, June 2007
1 e) If there exists an entry in the duplicate set with the same Originator Address and Sequence Number,
2 the entry is updated as follows:
3
4 D_time = current time + DUP_HOLD_TIME
5 The receiving interface MAC address is added to D_iface_list.
6
7 D_forwarded is set to true if and only if the element is forwarded according to step d.
8
Otherwise a new entry is added to the duplicate set with:
9
10 D_addr = Originator MAC Address.
11
13 D_time = current time + DUP_HOLD_TIME.
14
15 D_iface_list contains the receiving interface address.
16 D_forwarded is set to true if and only if the element is forwarded according to step d.
17
18
19
20 If, and only if, according to step d, the element shall be forwarded then:
21 f) The TTL of the element is decremented by one.
22
23 g) The hop-count of the element is increased by one.
24 h) The element is broadcast on all interfaces.
25
26
27 11A.9.4.3 Considerations on processing and forwarding
28
29 It should be noted that the processing and the forwarding of elements are two different actions, conditioned
30
31
by different rules. Processing is related to using the content of the elements, while forwarding is related to
32 forwarding the same element for other MPs in the network.
33
34 Notice that this standard includes a description for both the forwarding and the processing of each known
35 element type (i.e., element ID). Elements with known element types shall not be forwarded “blindly” by the
36 algorithm described in 11A.9.4.2. Forwarding (and setting the correct element field in the forwarded, known
37
38 element) is the responsibility of the algorithm

Sprache

Willkommen bei Scribd!

11s

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

11s

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Verwandte Titel

IEEE P802.11s/D1.

05, June 2007

Copyright © 2007 IEEE. All rights reserved. i

ii Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. iii

iv Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. i

1 Status of this document

Copyright © 2007 IEEE. All rights reserved. ii

Copyright © 2007 IEEE. All rights reserved. iii

1 7.3.1.17 QoS Info field ........................................................................................ 17

iv Copyright © 2007 IEEE. All rights reserved.

1 7.4.10.1 Link Metric Request frame format ........................................................ 53

Copyright © 2007 IEEE. All rights reserved. v

1 8.8.8 MPTK-KD ................................................................................................................. 76

vi Copyright © 2007 IEEE. All rights reserved.

1 10.3.42.1.1 Function ........................................................................... 87

Copyright © 2007 IEEE. All rights reserved. vii

1 11A.2.3.5 LISTEN state ....................................................................................... 105

viii Copyright © 2007 IEEE. All rights reserved.

1 11A.5.5.3.1 At Source MPs ............................................................... 138

Copyright © 2007 IEEE. All rights reserved. ix

1 11A.8.6.3.2 Effect of receipt ............................................................. 164

x Copyright © 2007 IEEE. All rights reserved.

1 11A.9.12.1 Advertised neighbor set ....................................................................... 184

Copyright © 2007 IEEE. All rights reserved. xi

1 11A.12.3.2.1 Designated Beacon Broadcaster .................................... 207

xii Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. xiii

1 Figure s52—Fields specific to MID element................................................................................................. 45

xiv Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. xv

1 Table s43—Content of a PANN element in Case A.................................................................................... 140

xvi Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 1

2 Copyright © 2007 IEEE. All rights reserved.

1 4. Abbreviations and acronyms

Copyright © 2007 IEEE. All rights reserved. 3

4 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 5

1 5.2.9.3 Organization of mesh subclauses

6 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 7

1 7.1.3 Frame fields

8 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 9

10 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 11

1 7.2.3.1 Beacon frame format

12 Copyright © 2007 IEEE. All rights reserved.

1 Table 7.14—Probe Request frame body

Copyright © 2007 IEEE. All rights reserved. 13

14 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 15

1 7.3 Management frame body components

16 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 17

18 Copyright © 2007 IEEE. All rights reserved.

Copyright © 2007 IEEE. All rights reserved. 19