{% set rfcid = “RFC-0243” %} {% include “docs/contribute/governance/rfcs/_common/_rfc_header.md” %}
{# Fuchsia RFCs use templates to display various fields from _rfcs.yaml. View the #} {# fully rendered RFCs at https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs #}
A device that is connected to a wireless network where there are multiple access points will gain the ability to roam between them. “Roam” means the client device moves its connection from one access point (AP) to another AP within the same wireless network, without incurring a full disconnection during the transition. A device may roam for many reasons: perhaps the device has moved farther from its current AP and closer to another AP; or perhaps a device's connection to its current AP has degraded in some way (e.g. high error rate). In cases like these, a device may attempt to roam to another AP to avoid incurring a full disconnection. This document addresses the API changes and logic necessary to support Fullmac-initiated and WLAN Policy-initiated roaming.
Maintaining WLAN connectivity sometimes requires that a device uses a different AP from the one it is currently using. Most commonly, this is because:
Roaming allows a device to move to a new AP with minimal disruption, using 802.11 reassociation. Without roaming, a device has to disconnect (or learn that it has been disconnected) from the original AP, tear down all its networking connections, and begin a new connection to an AP.
Contrast this with the situation when roaming is supported: a device can select a new AP while still connected to the original AP, and perform the reassociation. Reassociation is observed to take approximately 70 ms, while a disconnect followed by a reconnect is observed to take approximately 130 ms. While reassociation isn't a panacea, other features that further reduce the disruption require reassociation support. Once the plumbing for roaming is present (i.e. this design), a slew of further roaming enhancements will become possible with future work, such as:
Facilitator:
Reviewers:
Consulted:
Socialization:
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119. Requirements are included below.
Coordination of roaming requires FIDL API changes affecting almost all of WLAN: Fullmac, MLME, SME, and WLAN Policy. The API specified in this RFC supports two major modes of operation:
In a Fullmac-initiated roam, the decision of when and where to roam is made by the Fullmac firmware. In order for a roam to succeed, the start of the roam MUST be communicated upward through MLME and SME, and the result of the roam MUST be communicated upward through MLME, SME, and into WLAN Policy. A Fullmac-initiated roam attempt begins with Fullmac issuing a RoamStartInd
, and the result of the roam attempt results in WLAN Policy receiving a ConnectTransaction.OnRoamResult
. The messages follow these paths:
RoamStartInd
-> MLME RoamStartInd
-> SMERoamResultInd
-> MLME RoamResultInd
-> SME ConnectTransaction.OnRoamResult
-> WLAN PolicyIn a WLAN Policy-initiated roam, the decision of when and where to roam is made by WLAN Policy and MUST be communicated downward through SME, MLME, Fullmac driver, and finally into device firmware. The device firmware attempts the roam, and the result of the roam attempt MUST be reported upward through Fullmac, MLME, SME, and into WLAN Policy. A WLAN Policy-initiated roam attempt begins with WLAN Policy issuing a ClientSme.Roam
, and the result of the roam attempt eventually results in WLAN Policy receiving a ConnectTransaction.OnRoamResult
. The messages follow these paths:
ClientSme.Roam
-> MLME RoamReq
-> Fullmac RoamReq
-> Fullmac firmware roam commandRoamConf
-> MLME RoamConf
-> SME ConnectTransaction.OnRoamResult
-> WLAN PolicyTo implement these API changes, there will be logic changes throughout WLAN:
This RFC does not specify how roaming decisions are to be made by Fullmac or WLAN Policy, other than to advise that roaming decisions:
SME needs to track specific data about a client when it is roaming, and manage transitions between the roaming state and its other internal states. A new internal state named Roaming will be added to the SME client state machine. Like the SME Connecting state, Roaming state is where SME attempts to authenticate and associate with an AP (which we will refer to as the “target AP”). There are a few key differences:
RoamResultInd
and RoamConf
)Here is a high level overview of the SME client state machine (changes in red):
Here's a more detailed SME client state machine diagram for Fullmac-initiated roam, showing the happy path (RoamStartInd
followed by successful RoamResultInd
) and relevant failure paths:
Here's a similar SME client state machine diagram for WLAN Policy-initiated roam, showing the happy path (RoamReq
followed by successful RoamConf
) and relevant failure paths:
See Fullmac-initiated roam and WLAN Policy-initiated roam sections below for more details on how SME transitions to/from the Roaming state.
Some Fullmac device firmware can be configured to decide when and where to roam. Here's a high-level overview of how a roam initiated by Fullmac is handled by WLAN:
When a Fullmac-initiated roam attempt begins (step 1 in the above diagram), the Fullmac driver MUST send a RoamStartInd
up to MLME (step 2). The RoamStartInd
MUST be sent before the firmware begins the authentication or reassociation to the target AP. Like a ConnectReq
(which creates an initial connection to an AP), RoamStartInd
contains the BSS Description of the target AP. MLME SHOULD provide the full BSS Description to SME (see step 4 below).
The RoamStartInd
also MUST contain:
As more roaming features are implemented, other fields MAY be added to RoamStartInd
.
Because the roam attempt MUST use the same security configuration that was used to connect to the original AP when roaming to a target AP, Fullmac MUST retain the original security configuration that was used for the initial connection to the AP. Fullmac MUST NOT reassociate to an AP that does not match the original security configuration used in the initial connection. See Appendix D: Reassociation request security configuration for more details.
When a roam attempt is in progress, the Fullmac driver:
Because of these constraints, the Fullmac driver MUST set an internal roam timeout for completion of 802.11 authentication and reassociation. The timeout duration does not include any post-reassociation actions (e.g. EAPOL, DHCP). If the reassociation does not complete before the timeout:
The roam timeout is needed to avoid becoming stuck in a state where important functions such as scan and connect cannot be performed. The timeout SHOULD be set substantially longer than a typical authentication and reassociation (which have been observed to be in the neighborhood of 100 ms). A reasonable default roam timeout MAY be somewhere around 1 second.
When MLME receives a RoamStartInd
from Fullmac (steps 2 and 3), it MUST close the 802.1X controlled port. At this point, MLME MUST consider the device to be:
MLME informs SME that the roam has started via MLME RoamStartInd
(step 4). SME uses the BSS Description in MLME RoamStartInd
to perform 802.11 authentication and RSNA setup in concert with Fullmac. If the BSS Description provided by MLME RoamStartInd
is missing or invalid, SME MUST fail the roam.
Upon receipt of MLME RoamStartInd
, SME updates its internal state to represent that the device is roaming. Significant state and logic are already maintained in SME to support authentication and RSNA, processes which are performed in concert with the Fullmac firmware/driver and MLME. Fuchsia WLAN uses SME as the 802.11 authenticator (rather than an authenticator that might be provided by Fullmac firmware). Also, Fuchsia WLAN uses SME as an external supplicant for RSNA (rather than using a firmware supplicant, or a third party supplicant like wpa_supplicant).
If SME detects a malformed RoamStartInd
(e.g. missing fields, or invalid data), SME knows that the roam has failed due to an internal error. At the point that Fullmac issued the RoamStartInd
, the device was still associated with the original AP, though Fullmac may have since left the channel and/or band of the original AP shortly after. SME will take the following actions:
RoamStartInd
indicates that the original association is maintained, because the invalid roam attempt might otherwise continueOnRoamResult
indicating that the disconnect was due to a malformed RoamStartInd
If RoamStartInd
is not malformed, SME MUST transition to Roaming.
Note that WLAN Policy is not informed of the start of a roam. Stated differently, RoamStartInd
is propagated up to SME, but the start of a roam is not communicated to WLAN Policy through the ConnectTransaction
protocol. At design time, WLAN Policy team did not see a need for such an event, but it can be added if need arises. From observations of actual roams, lack of roam start notification to WLAN Policy results in a short duration where WLAN Policy is unaware that a roam is in progress; sending a roam start event from SME to WLAN Policy would reduce that duration by approximately 50 ms.
After sending the RoamStartInd
to MLME, the Fullmac firmware begins the process of 802.11 authentication with the target AP (step 5). Authentication is coordinated with higher layers in the same fashion as a regular connection. When 802.11 authentication is complete, the firmware begins the process of 802.11 reassociation with the target AP. (See IEEE 802.11-2020 11.3.5.4 for details about how authentication, reassociation, and RSNA are coordinated). Once Fullmac starts the reassociation exchange, the device is no longer associated with the original AP (but see Looking ahead to Fast BSS Transition for some subtle details).
Upon success, failure, or timeout of a Fullmac-initiated roam attempt (step 6), the Fullmac driver MUST send a RoamResultInd
up to MLME (steps 7 and 8). The RoamResultInd
provides information similar to what is provided in a ConnectConf
. Most importantly, it includes the 802.11 status code of the roam attempt. Similar to RoamStartInd
, RoamResultInd
MUST contain a boolean field to indicate whether the original association is maintained (see Looking ahead to Fast BSS Transition). original_association_maintained
MUST be false if the roam succeeded, because a successful roam always incurs disassociation from the original AP.
RoamResultInd
also MUST contain a boolean field to indicate whether the device is authenticated with the target AP:
target_bss_authenticated
MUST be true if the roam attempt succeededstatus_code
is anything other than success, target_bss_authenticated
specifies whether the device is currently authenticated with the target APUpon receipt of RoamResultInd
, MLME MUST keep the 802.1X controlled port closed (but see Looking ahead to Fast BSS Transition). If the roam succeeded:
If the roam failed:
target_bss_authenticated
MLME sends RoamResultInd
up to SME (step 9).
Upon receipt of the MLME RoamResultInd
, SME does the following if the roam succeeded:
If RoamResultInd
indicates that the roam failed, SME instead does the following:
target_bss_authenticated
is true:target_bss_authenticated
is false:SME communicates with WLAN Policy over a per-connection channel using the existing ConnectTransaction
API. SME MUST send an OnRoamResult
to WLAN Policy to inform it that a roam attempt has completed (step 10). The RoamResult
is similar to SME ConnectResult
. RoamResult
:
DisconnectInfo
if a disconnect was incurred; in other words, this is REQUIRED if roam failed and original association was not maintainedUpon receipt of OnRoamResult
, WLAN Policy will update its internal state. If the roam succeeded, WLAN Policy MUST continue to maintain the existing ConnectTransaction
with SME, but with the device now associated to the target AP. If the result indicates roam failure:
ConnectTransaction
and end the connectionWLAN Policy will gain the ability to initiate a roam attempt and learn of its outcome. A high-level overview of how a roam initiated by WLAN Policy is handled by WLAN:
When WLAN Policy initiates a roam attempt, it does so by issuing a ClientSme.Roam
to SME (step 1 in the above diagram). Roam
contains a RoamRequest
, which is conceptually similar to SME ConnectRequest
, though with fewer options because SSID and security configuration MUST NOT change during the roam (see Appendix D: Reassociation security configuration for more background on the security configuration used in a roam).
Because the roam attempt MUST use the same security configuration that was used to connect to the original AP when roaming to a target AP, WLAN Policy MUST retain the original security configuration that was used for the initial connection to the AP. WLAN Policy MUST NOT attempt to reassociate to an AP that does not match the original security configuration used in the initial connection.
In order for WLAN Policy to retain the security configuration used for the connection to the original AP, it must first obtain it, so SME ConnectTransaction.ConnectResult
MUST gain a new field that informs WLAN Policy of the exact security configuration that was used in the original association request.
Upon receipt of a ClientSme.Roam
from WLAN Policy, SME behaves the same as if it had received a RoamStartInd
from MLME, except that it sends a RoamReq
down to MLME (step 2).
Upon receipt of a RoamReq
from SME, MLME behaves the same as if it had received a RoamStartInd
from Fullmac, except that it sends a RoamReq
down to Fullmac (steps 3 and 4).
Upon receipt of a RoamReq
from MLME, Fullmac sends commands to the firmware to begin the authentication and reassociation processes (step 5), and then the firmware does just as it would for a Fullmac-initiated roam (step 6). When the firmware notifies the Fullmac driver of the result of the roam attempt (step 7), Fullmac sends a RoamConf
up to MLME (steps 8 and 9). RoamConf
is similar to RoamResultInd
.
Upon receipt of RoamConf
, MLME behaves the same as if it had received a RoamResultInd
, except that it sends a RoamConf
up to SME (step 10).
Upon receipt of RoamConf
, SME behaves the same as if it had received a RoamResultInd
from MLME. SME sends an OnRoamResult
to WLAN Policy over the ConnectTransaction
(step 11).
Upon receipt of OnRoamResult
, WLAN Policy takes the same actions as those discussed above at the end of a Fullmac-initiated roam.
The API changes can be made in two Gerrit changes: one for Fullmac-initiated roam, and another for WLAN Policy-initiated roam.
The strategy for roaming changes so far has been to introduce the roaming logic changes, without enabling them on production devices. Fullmac-initiated roaming is guarded by a driver feature in the brcmfmac driver. There are unit and integration tests to ensure that the roaming features are disabled, to prevent the feature from being accidentally enabled.
For WLAN Policy-initiated roaming, the API can be introduced without anything calling the SME ClientSme.Roam
/ConnectTransaction.OnRoamResult
API until WLAN Policy is confident that it can be enabled. Once the API is present, WLAN Policy can begin using roam success/failure as an input to its connection quality tracking, and WLAN Policy logic can decide whether to use the ClientSme.Roam
API for a specific AP, or even whether to use the ClientSme.Roam
API at all.
WLAN Policy MUST have the ability to enable or disable roaming features at interface creation time. This allows WLAN Policy to:
A simple API change to fuchsia.wlan.device
is necessary to support this need. A minimal implementation requires adding a single field to CreateIfaceRequest
to allow the caller to specify the roaming feature(s) that must be enabled during interface creation.
Note that for Fullmac interfaces, existing firmware can only enable features like roaming offloads at interface creation time.
For Fullmac-initiated roaming, the change can be tested on local developer builds (e.g. by uncommenting roaming features in the brcmfmac Fullmac driver code), and can be integration tested on real device and AP hardware using Antlion. There is already an Antlion integration test suite for Fullmac-initiated roaming (WlanWirelessNetworkManagementTest
), which tests successful and unsuccessful roaming attempts. The existing test suite requires a Fuchsia Fullmac-capable device that is instrumented to roam between two networks on a single physical AP device. Increasing integration coverage via a new Antlion test suite for additional Fullmac-initiated roaming scenarios is also expected.
For WLAN Policy-initiated roaming, the changes can be tested on local developer builds, and can be integration tested on real device and AP hardware using Antlion (by giving WLAN Policy the ability to enable roaming on an interface at runtime, see discussion in phase 1 above). Increasing integration coverage via a new Antlion test suite for additional WLAN Policy-initiated roaming scenarios is also expected.
Antlion test suites that exercise Fullmac-initiated or WLAN Policy-initiated roaming MUST know whether those features are in use on the Fuchsia device-under-test (DUT). This is necessary because Antlion needs to know whether to run or skip roaming tests on that DUT. For the existing Fullmac-initiated roaming test suite, Antlion configuration has special directives for WLAN features: presence of a roaming feature in the Antlion config tells Antlion to run Fullmac-initiated roaming tests, otherwise those tests are skipped. The implementation SHOULD give Antlion the explicit ability to query for feature support (using WLAN Driver Features), and SHOULD give Antlion the explicit ability to enable roaming features on a DUT before running tests on that DUT.
The existing Fullmac-initiated roaming Antlion test suite, as well as any new test suites, MUST be runnable on Connectivity Automation testbeds with a WLAN Antlion testbed.
A Fullmac-initiated roaming capable WLAN testbed:
When such a testbed is available, developers will be able to these tests against run work-in-progress changes using existing Antlion tryjobs infrastructure.
Deeper integration testing (e.g. using a third-party lab for testing roaming scenarios) is likely to be used as well.
Pending the outcome of integration testing, rollout can begin. WLAN Policy MUST have the ability to enable and disable roaming features on a per-interface basis, as discussed in phase 1 above.
Rollout of Fullmac-initiated and WLAN Policy-initiated roaming will be controlled by WLAN Policy, using WLAN Policy's typical feature rollout mechanisms (or a new rollout mechanism, at their option). WLAN Policy already has logic for connection selection, connection quality, and recovery from connection failure. WLAN Policy frequently makes changes to these functions in the usual course of operation. It is likely that additional runtime safeguards specific to roaming will be introduced by WLAN Policy, but this RFC does not endeavor to specify them.
Metrics that we will need to evaluate during the rollout phase include:
DisconnectInfo
(roughly, disconnect source and reason)We will need to monitor metrics that are not roaming-specific as well:
This RFC does not specify any end user control of roaming. Other operating systems provide end users no control over roaming (e.g. MacOS), or very limited control via special configuration (e.g. Windows, Linux). At this time we do not expect WLAN Policy to provide an end user control for roaming. Therefore, Fuchsia end users do not take on significant cognitive load from the introduction of Fullmac-initiated or WLAN Policy-initiated roaming. The only expected user visible effect is that some transitions between access points will be faster. To the end user, a failed roam will be indistinguishable from any other connection interruption, and the recovery from the interruption will be just like a connection interruption that did not involve roaming: a regular scan and connect.
The 802.11 spec has included roaming (reassociation) since long before Fuchsia existed.
The primary concern for backwards compatibility is that the introduction of roaming does not frequently cause a working network connection to become unusable, for the many existing devices that use Fuchsia WLAN. As the rollout section above mentions, giving WLAN Policy the ability to explicitly decide when to enable and use roaming features will go a long way to ensure that the use of roaming features does not leave interfaces in a degraded or unusable state. WLAN Policy MAY:
Three security concerns exist:
WLAN SME already validates that SSID and security parameters match the original security configuration, and the same mechanism will be used to validate them for the target AP. Failure of these validation steps results in tearing down the connection. See Appendix D for more detail on the security configuration used in a roam attempt.
As for responsibility for choosing an AP:
This design provides the API that allows Fullmac and WLAN Policy to initiate a roam and learn of the roam result. These actions incur use of the same information already used for existing (non-roaming) connection and disconnection logic. This design does not alter the current privacy posture of WLAN software.
FIDL changes will include significant documentation for new messages, fields, and methods. Additional documentation beyond the inline documentation is not planned.
Fullmac-initiated roaming is likely to require a BSSID blocklist API (similar to the one that exists in Android), allowing WLAN Policy to specify certain APs that should not be connected to. This would allow WLAN Policy to avoid a situation where the Fullmac firmware repeatedly roams to an AP that WLAN Policy knows is not functional.
This RFC specifies that WLAN Policy will have control over whether a Fullmac interface has roaming logic enabled. The expectation is that either Fullmac or WLAN Policy is in control of roaming logic for an interface, but probably not both. A situation where both Fullmac and WLAN Policy are simultaneously initiating roam attempts might cause “thrashing” between APs if Fullmac and WLAN Policy disagree about which AP is best. A BSSID Blocklist API would give WLAN Policy the ability to set a “guardrail” on Fullmac's roaming decisions, without having more than one initiator of roaming decisions. If we decide that there is a valid reason to have both Fullmac and WLAN Policy initiating roam attempts, this will require additional design.
Very careful analysis of disconnect scenarios is ongoing. We need to be confident that WLAN is resilient in the face of disconnects that occur during periods of ambiguity (e.g. when Fullmac knows that the roam has started, but higher layers like SME do not).
The current disconnection logic in SME attempts to deauthenticate from the AP as a cleanup measure in most disconnection scenarios. When a roam attempt causes the device to leave the channel (or even band) of the original AP:
In this and other cases that involve disconnects, we may discover that we need different disconnect behavior at the Fullmac and/or SME layers.
WLAN Policy and SME have existing “reconnect” behaviors, where re-establishing a previously working connection is attempted. For example, when a connection is disassociated but not deauthenticated, SME can preserve the ConnectTransaction
protocol between WLAN Policy and SME while SME attempts to associate to the AP. If the SME reconnect succeeds, SME was able to skip the authentication overhead and reduce the disconnected time. Behaviors like this will likely need to be scrutinized for how they interact with roaming. As a hypothetical example, there may be cases where we discover that we need to deauthenticate more aggressively during or after roam attempts in order to prevent reconnects from encountering problems after a failed roam attempt. We may also find that we need to change the timing of reconnects, or adjust other parameters.
WLAN software manages the data link layer, also known as “layer 2.” Above layer 2 is the network layer, also known as “layer 3,” which is managed by DHCP, Netstack, Network Policy, and other management software. When a roam attempt occurs, disruptions in layer 2 and layer 3 are likely:
In Fuchsia, a layer 3 link down currently causes a full DHCP client teardown and init. This may go unnoticed by the user, or may result in user-visible loss of IP connectivity. This “layer 2 disruption causing layer 3 disruption” scenario is not unique to roaming: a disconnect followed by a connect (even to the same AP) causes a full DHCP client teardown and init now.
This layer 3 disruption could be reduced with additional design (outside the scope of this RFC) to:
The exact mechanism(s), post-roam verifications, and logic needed would have to be worked out. Android has some prior art here (see Android updateLayer2Information), and IETF RFCs for DNAv4 and DNAv6 also cover this problem space (see DNAv4 and DNAv6).
Fast BSS Transition is not currently supported in Fuchsia WLAN. Fast BSS Transition allows a device to move its association to the target AP, with RSNA intact. When Fast BSS Transition becomes supported by WLAN, a few behaviors will change and the current design takes these behavior changes into account.
At initial connection time, WLAN Policy will need to see one (or more) additional information elements (abbreviated IE) that are specific to Fast BSS Transition support. It is likely these would be communicated to WLAN Policy within SME ConnectTransaction.ConnectResult
(similar to the way this RFC specifies that security config is communicated to WLAN Policy). Fast BSS Transition APs advertise a “mobility domain” IE that the device can use to identify other APs that accept Fast BSS Transitions from the current AP.
At the start of a roam that specifies that Fast BSS Transition is in use, WLAN MUST retain associated state and RSNA with the original AP. This is true whether the roam is Fullmac-initiated by RoamStartInd
or WLAN Policy-initiated by RoamReq
. One important ramification is that MLME will not close the controlled port at the start of a Fast BSS Transition roam. The original connection will continue as usual, while the new connection is being established via Fast BSS Transition. If the Fast BSS Transition roam succeeds and original_association_maintained
is true:
If the roam attempt fails (or reaches a roam attempt timeout):
RoamResultInd
/RoamConf
original_association_maintained
specifies whether the association with the original AP has been maintained throughout the unsuccessful roam attemptIf MLME sends a RoamResultInd
/RoamConf
to SME indicating that a Fast BSS Transition roam failed:
target_bss_authenticated
is true, SME MAY request deauthentication from the target AP (see Disconnect behavior for some subtle details)When Fast BSS Transition is supported, WLAN Policy will be able to maintain the existing ConnectTransaction
with the original AP even after WLAN Policy receives an OnRoamResult
that indicates a failed Fast BSS Transition roam attempt.
Fast BSS Transition will also add another consideration to Interactions with DHCP and layer 3 management: some successful roam attempts will not close the 802.1X controlled port during the attempt, so there will be no layer 3 link down. Without a layer 3 link down followed by a layer 3 link up, layer 3 management software will need some other signal to know that post-roam verification actions should occur.
Another ramification is that various state machines (MLME, SME, WLAN Policy) will need to maintain state for more than one AP. While this can be done by adding fields to existing states, it's likely that refactoring these state machines to be multiple-BSS aware will become more attractive once Fast BSS Transition is on the horizon. A quick look at the SME client state machine illustrates the quality of changes that might be necessary:
802.11 specifies that a device can be authenticated with multiple APs, but it can only be associated with a single AP at any given time. When a roam attempt fails, the device is still authenticated with the original AP, unless a deauthentication indication has been received from the original AP. This means that the SME could maintain enough state with the original AP to allow it to transition from Roaming state back into Connecting state, skipping the authentication process with the original AP. This would shorten the time to get back to associated state with the original AP. This was prototyped by adding two new states to the SME client state machine:
This prototype of a fallback-capable SME client state machine is not currently being pursued. After discussion with WLAN Core team, the general consensus was that implementing fallback-capable roaming would be easier if the SME client state machine were refactored to explicitly keep state for multiple APs. There may also be Fullmac firmware limitations to contend with--some firmware requires that the Fullmac driver disconnect and reset the firmware state upon a roam failure, which may preclude the ability to fallback.
If we decide to implement fallback-capable roaming, it can coexist with Fast BSS Transition. Fallback-capable roaming endeavors to keep authenticated state with the original AP; while Fast BSS Transition endeavors to keep associated state and RSNA. We could use both Fast BSS Transition and fallback-capable roaming, or just one of them, or neither.
A “Softmac” WLAN device differs from Fullmac in one important way. A Fullmac device has most of the 802.11 MLME logic implemented in firmware, while a Softmac device has most of the WLAN MLME logic implemented in driver software. Because Fullmac handles construction and parsing of reassociation frames, orchestrates the roaming process, and can even decide when and where to roam, the Fullmac API needs significant changes for roaming (i.e. this RFC). But in Softmac, the API and logic changes required for roaming support are likely to be different in nature:
When a device roams (via reassociation), the security configuration specified in the reassociation request frame MUST be the same security configuration that was used for the original connection (see IEEE 802.11-2020 11.3.5.4). This requirement merits a deeper discussion of how this affects the API changes specified in this RFC.
WLAN Policy stores saved networks, which are specified in NetworkConfig
which aims to represent them in human-understandable terms:
When WLAN Policy decides to connect to a specific AP, WLAN Policy sends SME a ConnectRequest
which contains additional details about the AP:
SME then:
MFPR
bit set to 1, meaning that management frame protection (MFP, see IEEE 802.11-2020 9.4.2.24.4) is required, so the device will not join a network that doesn't support MFPMFPR
to 0 (meaning not required), while setting MFPC
to 1, meaning that the device can join a network regardless of whether MFP is supported or required on that networkThe association will only succeed if the AP security configuration can match against the SME-specified security configuration (see IEEE 802.11-2020 12.6.3 for how this works). IEEE 802.11-2020 11.3.5.4 REQUIRES that the same RSNE that was included in the original association request is used in any subsequent reassociation (roam) requests.
For Fullmac-initiated roam attempts, this does not impose any need for any additional API. SME decides the security configuration that will be used in the original association request, Fullmac stores this configuration, and Fullmac uses this security configuration for any roam attempts. Because WLAN Policy is not choosing the target AP, WLAN Policy never needs to know the security configuration for Fullmac-initiated roam attempts in this case.
But for WLAN Policy-initiated roaming, there is a need for WLAN Policy to know the SME-specified security configuration that was used to connect to the original AP, because:
The solution is to add a field to SME ConnectResult
that will share the security IE with WLAN Policy at initial connection time.
If we discover that there are cases where Fullmac firmware uses a different security configuration during a roam:
If we discover a need for changing security configuration during a roam, we will have to evaluate that need against the security configuration invariant imposed by IEEE 802.11-2020 11.3.5.4. Considering that previous revisions of 802.11 did not clarify this question, it is possible that we will encounter Fullmac firmware which does not uphold the invariant. If we discover a case that we need to support, we could add API fields/methods to explicitly allow WLAN Policy to get and/or set the security configuration.
We may also discover that we want WLAN to uphold stronger security guarantees than just the 802.11 spec-imposed constraints. For WLAN Policy-initiated roaming, WLAN Policy will be free to enforce stronger security by choosing only APs that match stricter security criteria than what was used in the initial connection, still subject to the SME validation that security parameters match the original security configuration. For Fullmac-initiated roaming, it is likely that a driver API would need to be introduced to allow changing the association/reassociation request IEs, and/or firmware would have to be modified with additional configuration options to provide this behavior.