July 201011-10-0837r0
IEEE P802.11
Wireless LANs
Date: 2010-07-12
Author(s):
Name / Affiliation / Address / Phone / email
Dee Denteneer / Philips / HTC 34; 5656 AE Eindhoven, The Netherlands /
Dan Harkins / Aruba Networks /
EDITORIAL NOTE—The following clause numbering based on 802.11u ending with 11B. 11C is the first unused clause.
Insert the following new clause after 11B:
11C. MLME mesh procedures
11C.1 Mesh STA dependencies
When dot11MeshActivated is true, the STA is a mesh STA and dot11ExtendedChannelSwitchEnabled and dot11SpectrumManagementRequired shall be true.
11C.2 Mesh discovery
11C.2.1 General
A mesh STA shall perform either active scanning or passive scanning to discover an operating mesh BSS using the SCAN primitive (see 10.3.2 (Scan)). A mesh profile, a set of parameters identifying the mesh BSS configuration, may be installed in mesh capable devices by a variety of means that are beyond the scope of this standard. A mesh profile can be also obtained through the scanning process, and it can be used to determine the scanning mesh STA's active mesh profile. Based on the result of the scan, the mesh STA may establish a new mesh BSS or become a member of the existing mesh BSS, using the START primitive (see 10.3.10 (Start)). MLME-START.request triggers beaconing that facilitates the discovery of the mesh STA by the neighbor mesh STAs. The A mesh STA that becomes a member of the an existing mesh BSS may establish a mesh peering with one or more neighbor mesh STAs that are in the existing mesh BSS.
11C.2.2 Mesh identifier
A Mesh ID indicates the identity of an MBSS. The Mesh ID may be installed in mesh capable devices by a variety of means that are beyond the scope of this standard. For example, the Mesh ID might be set by the user, e.g., “Mike’s Mesh”. A mesh STA shall include the Mesh ID element (see 7.3.2.97 (
Mesh ID element)) containing its Mesh ID in its Beacon and Probe Response frames, in order to advertise its identity. A mesh STA shall also include the Mesh ID element containing its Mesh ID in its Mesh Peering Open frames, Mesh Peering Confirm frames, and Mesh Peering Close frames.
A mesh STA shall set SSID element (see 7.3.2.1 (SSID element)) in Beacon, Probe Request, and Probe Response frames to the wildcard SSID.
NOTE—The wildcard SSID is used to notify non-mesh STAs that the mesh STA is neither a part of an infrastructure BSS nor an IBSS, so that the non-mesh STAs do not try to join the mesh BSS.
11C.2.3 Mesh profile
The A mesh profile is a set of parameters that identifies specifies the attribute of the a mesh BSS. A mesh profile consists of:
a) A Mesh ID — specified by dot11MeshID
b) A path selection protocol identifier — specified by dot11MeshActivePathSelectionProtocol
c) A path selection metric identifier — specified by dot11MeshActivePathSelectionMetric
d) A congestion control mode identifier — specified by dot11MeshActiveCongestionControlMode
e) A synchronization protocol identifier — specified by dot11MeshActiveSynchronizationProtocol
f) An authentication protocol identifier — specified by dot11MeshActiveAuthenticationProtocol
g) A mesh peering protocol identifier — specified by dot11MeshActivePeeringProtocol
In a mesh BSS, all mesh STAs use the same mesh profile. Mesh profiles are considered identical if all parameters in the mesh profile match
Before establishing a mesh BSS or becoming a member of a mesh BSS, the a mesh STA shall activate one mesh profile. The mesh STA may not change the its mesh profile unless it leaves the mesh BSS of which it is a member. When a mesh STA leaves the mesh BSS of which it is a member, it should explicitly close all of its active mesh peerings using Mesh Peering Close frames (see 11C.4.3.4 (Mesh Peering Close frames
)) and shall discard all session information obtained while the mesh profile was active, such as local forwarding information, security associations (and related keys), etc. An MLME receives the mesh STA’s active mesh profile from the SME upon receipt of an MLME-START.request primitive.
A mesh profile is considered as the same if all parameters comprise the mesh profile matches. A mesh profile consists of:
a) A Mesh ID — specified by dot11MeshID
b) A path selection protocol identifier — specified by dot11MeshActivePathSelectionProtocol
c) A path selection metric identifier — specified by dot11MeshActivePathSelectionMetric
d) A congestion control mode identifier — specified by dot11MeshActiveCongestionControlMode
e) A synchronization protocol identifier — specified by dot11MeshActiveSynchronizationProtocol
f) An authentication protocol identifier — specified by dot11MeshActiveAuthenticationProtocol
g) A mesh peering protocol identifier — specified by dot11MeshActivePeeringProtocol
The Active mesh profile is signalled through by means of the Beacon and Probe Response frames via the Mesh ID element and the Mesh Configuration element, . The active mesh profile is included in Beacon and Probe Response frames, so that the mesh profile can be obtained by its neighbor mesh STAs through the scan. Mesh Configuration element is also present in Mesh Peering Open frames and Mesh Peering Confirm frames also contain a mesh profile.
Note to the Editor: Include a new section 11C2.4 here, and renumber the following sections accordingly
11C.2.4 Mesh STA configuration
The configuration consists of the mesh profile from section 11C.2.3, the Supported Rates element, the Extended Supported Rates element, and the HT Operations element (if present).
Mesh STA configurations are identical if the following conditions hold:
- the mesh profiles are identical,
- the BSSBasicRateSet parameters are identical
- for HT mesh STAs the BSSBasicMCSSet parameters are identical.
11C.2.4 Supplemental information for the mesh discovery
A mesh STA shall signal if it is willing capable to establish an additional mesh peerings with other mesh STAs. The mesh STA sets the Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the Mesh Configuration element to 1 when it is willing capable to accept new mesh peerings (see 7.3.2.96.9 (Mesh Capability)). The mesh STA sets the Accepting Additional Mesh Peerings subfield in the Mesh Capability field in the Mesh Configuration element to 0 when it is not capable to accept new mesh peerings. This parameter is dynamically controlled by SME and given to MLME by dot11MeshAcceptingAdditionalPeerings.
NOTE— This control is driven by the internal policy. When Accepting Additional Mesh Peering subfield is 1, the mesh STA is supposed to have internal resource to accommodate more mesh peerings. The internal policy is outside the scope of this standard. For instance, a mesh STA might be configured to be able to maintain only two mesh peerings.
A mesh STA shall announce its topological information through the Mesh Formation Info field in the Mesh Configuration element. The contents of the Mesh Formation Info field shall be coded to reflect the current configuration.
11C.2.5 Scanning mesh BSSs
A mesh STA shall perform active scanning or passive scanning, depending on the value of the ScanMode parameter of the MLME-SCAN.request primitive (see 11.1.3 (Acquiring synchronization, scanning)), to discover neighbor mesh STAs. Upon receipt of an MLME-SCAN.request with the Mesh ID parameter set to the wildcard Mesh ID, the STA shall passively scan for any Beacon frames, or actively transmit Probe Request frames containing the wildcard Mesh ID, as appropriate depending on the value of ScanMode. Upon completion of scanning, an MLME-SCAN.confirm is issued by the MLME indicating all of the discovery information received. Further, mesh STAs shall conform to the passive scan procedure as described in 11.1.3.1 (Passive scanning) and the active scan procedure as described in 11.1.3.2 (Active scanning).
11C.2.6 Determination of the cCandidate peer mesh STA discovery
When a mesh STA discovers one or morea neighbor mesh STAs through the scanning process, it may try to become a member of the mesh BSS of which the discovered mesh STA is a member, and establish a mesh peering with the neighbor mesh STA. A discovered neighbor mesh STA shall be considered a candidate peer mesh STA if and only if all of the following conditions are met:
a) A Beacon or Probe Response frame is received from the discovered neighbor mesh STA.
b) The received Beacon or Probe Response frame indicates that the neighbor mesh STA uses the same mesh profile as the mesh STA.
c) The received Beacon or Probe Response frame contains Tthe Accepting Additional Mesh Peerings subfield in the Mesh Capability field of the received Beacon or Probe Response frame equalsthat is set to 1.
d) The received Beacon or Probe Response frame indicates that the neighbor mesh STA uses the same BSSBasicRateSet as the mesh STA.
Additionally, if both the scanning mesh STA and the discovered neighbor STA are HT STAs, the following condition shall be met to consider the discovered mesh STA a candidate mesh STA.
e) The received Beacon or Probe Response frame indicates that the neighbor mesh STA uses the same BSSBasicMCSSet as the mesh STA’s.
NOTE1— If the scanning mesh STA has not become a member of any MBSS yet, it may simply activate the same mesh profile as the discovered neighbor mesh STA’s profile to fulfill these conditions.
The Mesh Formation Info field in the Mesh Configuration element is available to assist mesh STAs in determining which neighbor mesh STAs to establish mesh peerings with. The details of the usage of this information are beyond the scope of this standard.
NOTE2—Selection of candidate peer mesh STAs with whom to form links is outside the scope of this standard. That is, the mesh STA might freely select the mesh STAs with which it attempts to establish a mesh peering.
A candidate peer mesh STA becomes a peer mesh STA only after the mesh peering management protocol (see 11C.4 (Mesh peering management)) has been completed successfully and a mesh peering is established between the two mesh STAs.
11C.2.7 Establishing or becoming a member of a mesh BSS
After the determination of the active mesh profile, the mesh STA may establish a new mesh BSS or become a new member to an existing mesh BSS. In either case, the mesh STA shall start beaconing using START primitive. Upon receipt of an MLME-START.request, a mesh STA shall initialize and start its TSF timer as specified by its active synchronization protocol as described in 11C.12.2 (Extensible synchronization framework), and begin transmitting Beacon frames as described in 11C.12.3 (Beaconing).
If dot11MultiDomainCapabilityActivated is true, a mesh STA shall not establish or become a member of a mesh BSS, unless a properly formed Beacon frame including a Country element can be constructed, and dot11CountryString has been set.
A STA shall include a Country element in the transmission of Beacon frames if either dot11MultiDomainCapabilityActivated, dot11SpectrumManagementRequired, or dot11RadioMeasurementEnabled is true. See 7.2.3.1 (
Beacon frame format) for the description of a properly formed Beacon frame.
A mesh STA may continue the discovery procedure after establishing or becoming a member of an MBSS, in order to look for other candidate peer mesh STAs to establish mesh peerings with.
11C.3 Mesh Peering Management framework
11C.3.1 General
The Mesh Peering Management framework supports all functions to establish, manage, and tear down mesh peerings between mesh STAs. When dot11MeshSecurityActivated is true, a mesh STA shall manage Mesh mesh peerings and Mesh TKSAs for each peer mesh STA.
MBSS peering management functions shall be invoked after a candidate peering mesh STA is has been discovered via the candidate peer mesh STA discovery procedure described in 11C.2.6 (Determination of the candidate peer mesh STA). Mesh STAs shall not transmit frames other than the ones used for candidate peer mesh STA discovery, mesh peering management, and SAE to a neighboring mesh STA until a mesh peering has been established with the mesh STA. Upon successful completion of a mesh peering, mesh STAs may transmit other frames, such as Mesh Action frames, to maintain the integrity of the mesh BSS.
Depending on the setting of dot11MeshSecurityActiviated, one of the following protocols shall be invoked to establish the a mesh peering with the a candidate peer mesh STA:
—When dot11MeshSecurityActivated is false, the Mesh Peering Management (MPM) protocol is used to establish and manage the mesh peering between with candidate peer mesh STAs. See 11C.4 (Mesh peering management) for MPM protocol details.
—When dot11MeshSecurityActivated is true, the Authenticated Mesh Peering Exchange (AMPE) protocol is used to establish and manage the mesh peering and Mesh TKSA between with the candidate peer mesh STAs using an existing Mesh PMK security association (Mesh PMKSA). See 11C.5 (Authenticated Mesh Peering Exchange
) for AMPE protocol details. If an existing Mesh PMKSA is identified during discovery it shall be used directly with AMPE. If no Mesh PMKSA is identified a Mesh PMKSA shall be established using SAE.
The Mesh Peering Exchange (MPM) establishes a peering between Mesh STAs. Using MPM both peers agree on capabilities to govern the peering. Upon successful completion of MPM, mesh STAs may transmit other frames, such as Mesh Action frames, to maintain the integrity of the mesh BSS.
The Authenticated Mesh Peering Exchange is inclusive ofincludes the Mesh Peering Management protocol but differs in that it has additional requirements on creation and processing of frames. The successful completion of AMPE establishes the mesh peering and Mesh TKSA with the peer mesh STA, and the mesh TK and MGTKs are installed. Then data traffic is allowed to flow on the mesh link and protection on the data traffic is enabled. If the 802.1X ports are attached to 802.11 SME, the 802.1X uncontrolled port shall be closed to enable data traffic. Upon failure of AMPE, the mesh STA shall terminate the mesh peering establishment procedure with the current candidate peer mesh STA, and the mesh STA shall[n1] continue with the candidate peer mesh STA discovery procedure.
Mesh STAs shall support SAE authentication (see 8.2a (Authentication using a password) using a pre-shared secret with the candidate peer mesh STA.
Figures51 (Logical flowchart of protocol interaction in Mesh Peering Management framework) shows the logical flow of protocol interactions in the peering management framework.
Figure s51—Logical flowchart of protocol interaction in Mesh Peering Management framework11C.3.2 Mesh pPeering Instance Controllercontroller
11C.3.2.1 Functions
A mesh STA shall use a Mesh mesh Peering peering Instance instance Controller controller to manage all mesh peering instances established or in the process of establishment or teardown with its peer mesh STAs and candidate peer mesh STAs.
A mesh peering instance is identified by a mesh peering instance identifier.In case dot11MeshSecurityActivated is false, the mesh peering instance consists of the localLinkID, peerLinkID, localMAC, and peerMAC. If dot11MeshSecurityActivated is false, the mesh peering instance consists of the localLinkID, peerLinkID, localMAC, peerMAC, and additionally the PMKName from the Mesh Peering Management element.
localMAC is the MAC address of the mesh STA that is being used with this mesh peering instance. peerMAC is the MAC address of the peer mesh STA or the candidate peer mesh STA. localLinkID is an integer generated by the mesh STA. peerLinkID is an integer generated by the peer mesh STA or the candidate peer mesh STA.The localLinkID shall be unique among all existing link identifiers used by the mesh STA for its current mesh peering management finite state machines. The mesh STA selects the localLinkID to provide high assurance that the same number has not been used to identify a recent mesh peering management finite state machine. The peerLinkID shall be supplied by the peer mesh STA or candidate peer mesh STA in Mesh Peering Open and Confirm frames.
The A mesh peering instance is represented by the an MPM finite state machine (see Tables32 (Mesh Peering Management Finite State Machine) or the an AMPE finite state machine (see Tables33 (Authenticated Mesh Peering Exchange Finite State Machine)) and all associated information and mesh peering state used to process and manage Peer Link Management frames.
The Mesh Peering Instance Controllermesh peering instance controller shall support the following functions:
—Create and destroy MPM finite state machines and AMPE finite state machines
—Manage instance identifiersand Mesh TKSA states for each mesh peering instance
—Manage Mmesh TKSAs for each mesh peering instance when dot11MeshSecurityActivated is true.
—Pre-process the mesh peering instance identifier of the incoming Mesh Peering Management frames and pass the frames to the corresponding protocol finite state machine with matching instance identifier
—Pass internal command to corresponding protocolthe finite state machine which haswith matching instance identifier
The Mesh Peering Instance Controllermesh peering instance controller may provide useful information to the mesh STA discovery procedure depending on the outcome of SAE, MPM, and AMPE to make candidate peer mesh STA discovery more effective.
—If SAE execution fails, depending on the reason of failure from SAE, the mesh STA may or may not discover the same candidate peer mesh again through the new candidate peer mesh STA discovery procedure.