Search Linux Wireless

Re: [RFC] Introduce NL80211_IFTYPE_MLO_LINK_DEVICE for MLO link (IEEE 802.11be)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-02-18 22:56, usdutt@xxxxxxxxxxxxxx wrote:
On 2021-02-12 22:33, usdutt@xxxxxxxxxxxxxx wrote:
Hi ,
Thanks for your response.

The switch / change interface among the STA or MLO Link shall happen
only in the disconnected state.
At this point, (in the disconnected state) these MLO Link wdev’s are not linked to the STA interface ( either on the same / different wiphy ).
These shall be linked after the Association to an MLO AP.
The intention here is to have the wdev in the right mode ( STA or MLO
Link ) before the connect / Association is triggered.
This wdev is put in to a MLO_LINK_DEVICE, before the connect /
association is triggered on the respective MLD (IFTYPE_STA) interface
for an MLO connection.
This wdev is put in the IFTYPE_STA mode, before triggering a connect /
association on this interface.

This should be applicable for different drivers too.

Please let us know if there are any caveats in this design


Just to summarize, to see if I'm understanding it correctly.

You're basically saying that on the client side

1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with whatever MAC address it may have, and does not maintain its "own" association
    to an AP;
2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the DEVICE it's long enough) are added to it, with appropriate link addresses
    selected for them;
3) this configuration can only happen while none of them are connected.

Right?

No . Our intention was the NL80211_IFTYPE_STATION interface to also represent the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents other MLO
Links of an MLO connection.
This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev shall
link all such MLO_LINK’s which are part of the same MLD connection.
That way , there will be a single netdev interface exposed to the applications for the data transfer and these MLO_LINK wdevs along with NL80211_IFTYPE_STATION wdev represent the corresponding connection/link status with the MLD AP. Please note that in this case the NL80211_IFTYPE_STATION Acts as both the MLD
and one of the MLO Link’s.


Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK could share a MAC address with the MLD (_STATION), although I hear that there's still a discussion right now on MLD-addressed and link-addressed
management frames, so I think we need to wait until we know that for
sure.

A couple of questions:

 1) How do we present this to userspace, is that it? Wouldn't the
_STATION (MLD) interface ideally still have *some* visible wireless
    state, and show which network it's connected to? It might be very
awkward to require all userspace tools to be updated to know about
    and query for _MLO_LINKs.

Obviously, wpa_supplicant needs to be aware of these and can handle
    it just fine, so I'm more concerned about other userspace. After
    all, people still use tools built on wireless extensions

As I have mentioned above , the _STATION is both the MLD and one of the
MLO Links.
This shall still have the connected state with its MLO Link representing
the connection info with the AP.
The other MLO Link of a 2 Link MLO connection to the AP (for example) is
represented by the _MLO_LINK wdev.
Userspace tools can still see this _STATION as both the MLD and non MLD
station interface connection.
For an MLD connection this _STATION interface will also link with the
corresponding _MLO_LINK wdev’s and thus any
MLO aware user applications can as well get the connection stats of the corresponding MLO Links along with _STATION link through the _STATION interface.


2) In some ways related to 1), but in other ways also not - perhaps we
    need to anticipate that some devices will want to handle MLO link
decisions in firmware? I haven't thought about this much at all, but if we require separate MLO_LINK type wdevs for each link that might
    be tricky?

Are you saying that these devices want to totally handle the MLO link
establishments with in the firmware ?
Let me take an example here. I have taken a 2 link MLO for a reference.
Such devices want to still represent the station interface with
NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with in
the firmware ?
Technically, the _STATION interface here is connected to 2 BSSID’s .
Can I know What would _STATION(wdev)->current_bss represent here ?


 3) I keep thinking about moving much "associated" state into the STA
    struct we maintain in the kernel, and actually maintaining the
*links* only as "multiple associations". This also gets tricky with
    the link MAC addresses in a way, though that could be handled. It
    might also be an easier way to manage some of that state problem
    from my question 1)?

Any thoughts on this? I'm definitely not saying this would be easy,
    but would it simplify things regarding the userspace APIs and the
    offload question in 2)?

Can I know how these “multiple associations” would be represented as to
the user space ?
With your proposal above, the userspace applications shall still see a
single NL80211_IFTYPE_STATION and multiple links are maintained within this
wdev ?
Fine , this would work as long as these links are with in the same wiphy.

Let me present the two use cases we considered MLO for.

1)single wiphy to represent multiple bands on which the MLO Links can
be formed :
In this case the _STATION interface would be on a single wiphy and yeah your proposal would hold good. We initially thought on similar lines. Thanks. 2) single wiphy for each supported band: Say there are two wiphy’s here , each representing the respective bands 2G and 5G/6G. In this specific case, the non
MLO solution had two _STATION interfaces connecting to the AP’s on
respective bands.

We are aiming to enhance this design for MLO . In this case, the MLO Links spawn across different wiphy’s and at the same time has to be backward compatible for
the non MLO connection ( dual STA ) .
To suite the above two use cases , we proposed the introduction of
_MLO_LINK wdev
and the _STATION interface to link all the _MLO_LINK wdev’s that are part of the
respective MLD connection.
Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice
versa to have
both the MLO and non MLO connection (Dual STA).

    Any other designs than the MLO_LINK wdev that you have considered
    and discarded, and if so for which reasons?


The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link”
on the non-AP MLD.This would not be required for an AP MLO.

FWIW, I don't buy the part about this not being required for an AP MLD.

The following explains our design for AP.
For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance for
non-MLO / legacy client and an MLO link for AP-MLD.
To be specific, For a 2 link AP MLD , there will be 2 NL80211_IFTYPE_AP
wdev's created.

This will not work if there's a need (and possibly spec requirement) to have an MLD address that's different from *all* the link addresses. It
will also be difficult to manage that one of the AP interfaces would
have to be defacto the MLD, but (at least in theory) any one of the AP
interfaces could be removed for 'degraded' operation.

I suspect will also not work right if you want to have AP_VLAN on the AP
MLD.

IMHO it'd be better for things to be symmetric like you suggest for the
client side.

Now, I can see the need for legacy interoperability, but then it seems it would probably be better to do this the other way around and declare
a new AP_MLD interface type (with a netdev) that doesn't maintain its
own beacons etc. but just has its own MAC address (the AP MLD address)
and bubbles up the data frames exchanged on the MLD.

OK. A new AP_MLD with a netdev to represent the MLD. I guess this is to
only facilitate the need for a different MLD address over the MLO link
addresses?

Taking an example , A 2 MLO AP would have the following . Please correct me . Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP instance
for a non MLD AP ( for the legacy clients to connect ). These two
wdev’s maintain
their own beacon’s and do have the corresponding netdev’s.
A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon. The two _IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD interface
for the MLD address ?

We had seen some concerns on this model and please allow me to get back to you
as early as possible.

Continuing with this 2 link MLO example further, our thought is to bridge the
2 netdev’s associated with each MLO Link ( MLD AP ) / AP instance (
non MLD AP ).
Thus, the bridge interface shall represent the network interface for
the non MLD &
MLD AP to the network stack.
Adding further, it is this bridge interface that gets routed over the
network stack
and thus the destination / source MAC address of the IP frames from /
to non MLO / MLO
clients associated to the AP would be the bridge MAC address.
If this is agreed, then in the above topology the MLD MAC Address /
netdev is not used
and this MAC address is used as the destination MAC only for certain frames
( EAPOL frames , from our study till now ) .
So, we were debating if we need a separate netdev to represent the MLD
MAC address.
Would it be needed for RX / TX of EAPOL frames also from the hostapd /
user space ?
IMHO No, as these frames could as well be exchanged over the NL
interface , isn’t ?

Another thought is to just consider this MLD MAC address as a logical entity
(without associating to the netdev) which is different address from
the Link addresses.
That said, can this model of “AP_MLD interface type ( with a netdev )
“ made optional
and left for the driver architectures to use it ( separate netdev for
the MLD MAC ) ?

Regards,
Sunil

Hi ,
Can you please help us review the proposal for MLO AP and STA.
The following is the high level summary of MLO behavior for both the modes, based on your earlier suggestions.

MLO STA ( non – AP )

1) An MLD is represented by the NL80211_IFTYPE_STATION wdev.
2) Each MLO Link is represented by a new wdev type - NL80211_IFTYPE_MLO_LINK 3) Each MLO Link wdev represent the connection information of the respective link with the MLO AP. 4) The NL80211_IFTYPE_STATION wdev behavior would change based on if the connection is MLO vs non MLO. a) For a non MLO NL80211_IFTYPE_STATION Wdev, the current_bss (wdev) represents the current connected bss information. b) For an MLO, NL80211_IFTYPE_STATION Wdev will fetch the current_bss info from the respective NL80211_IFTYPE_MLO_LINK Wdev. 5) Thus, the NL80211_IFTYPE_STATION wdev will maintain the list of all such NL80211_IFTYPE_MLO_LINK Wdev's for an MLO station. 6) These NL80211_IFTYPE_MLO_LINK Wdev’s can be either on the same or different wiphy as that of NL80211_IFTYPE_STATION Wdev. This is to facilitate the dual band architectures, where each wiphy represents the respective band. 7) Can either of following options be considered to represent a MLD STA. Leave up to the driver architectures to use the same. a) Having a separate wdev for an MLD STA. This provides an option to set any link specific attributes ( e.g., MAC address) via MLO Link wdev while ML specific attributes can be set via MLD STA wdev b) No separate wdev / netdev representation for the MLD STA. We wanted to explore if a NL80211_IFTYPE_STATION wdev can as well act as one of the MLO Link’s. For the architectures that can support same MLO Link and MLD. This will allow driver to support the model of MLD mac being same as link mac address or different.


MLO AP

1) For AP , NL80211_IFTYPE_AP wdev shall represent both – distinct AP instance (for non-MLO client associations) and an AP in AP MLD for MLO client associations. 2) The MLO Links for the AP are represented by the respective NL80211_IFTYPE_AP wdev's.
3) Can either of following options be considered to represent a MLD AP.
Leave up to the driver architectures to use the same.
a) A new wdev interface type NL80211_IFTYPE_MLD_AP represents the MLD for an MLO AP. This NL80211_IFTYPE_MLD_AP Shall not have its own beacon, but will have a netdev associated to it, which represents the MLD of MLO AP. b) No separate wdev / netdev representation for the MLD AP. Hostapd is aware of/derives the MLD MAC address and uses the regular MLO Link AP wdevs(any) for all the required ML mgmt and EAPOL interactions. This is for the architectures where there are no Data frames ( apart from EAPOL ) destined to MLD. The MLO Link AP’s are added to the bridge interface and data frames are forwarded via bridge, practically. This also helps in architectures where large number of virtual AP’s are the requirement but resources such
       as the net devices are a constraint.

Regards,
Sunil





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux