Introduce NL80211_IFTYPE_MLO_LINK_DEVICE for MLO link (IEEE 802.11be)

Multi-link support is introduced in 802.11be specification.

net/wireless/core.c +13 -0

+void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev,
+				   struct wireless_dev *wdev)
+{
+	ASSERT_RTNL();
+
+	if (WARN_ON(wdev->iftype != NL80211_IFTYPE_MLO_LINK_DEVICE))
+		return;
+
+	if (!wdev_running(wdev))
+		return;
+
+	rdev_stop_mlo_link_device(rdev, wdev);
+	wdev->is_running = false;

Hi,

Quoted 1 line

Multi-link support is introduced in 802.11be specification.

[...]

I'll definitely have to take a closer look at this and the spec and think about it - but a couple of quick comments below.

Quoted 6 lines

struct sk_buff *msg;
void *hdr;

net/wireless/nl80211.c +3 -0

+	struct nlattr *nested, *nested_mlo_links;
+	struct cfg80211_mlo_link_device_params *mlo_link;
+	int i = 0;

net/wireless/nl80211.c void nl80211_send_connect_result(struct cfg80211_registered_device *rdev, · line 16041

Quoted 5 lines

msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
cr->fils.kek_len + cr->fils.pmk_len +

net/wireless/nl80211.c +2 -1

-			(cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+			(cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+			(cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);

32 probably should be some NLA_SIZE or something constant?

There's also no point in the ternary operator since 0 * 32 is 0 :)

net/wireless/sme.c void cfg80211_connect_done(struct net_device *dev, · line 854

Quoted 9 lines

/* Consumes bss object one way or another */

net/wireless/sme.c +3 -1

@@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev,
  	ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
  		     params->req_ie_len + params->resp_ie_len +
  		     params->fils.kek_len + params->fils.pmk_len +
-		     (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+		     (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+		     (params->n_mlo_links ? params->n_mlo_links *
+		      sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);

same here, no need for the ternary

It feels strangely asymmetric to have stop and no start ... but I guess that's the part where I need to think about it and look a bit at how it all works :)

Quoted 7 lines · Johannes Berg

Hi,

Quoted 1 line

Multi-link support is introduced in 802.11be specification.

[...]

I'll definitely have to take a closer look at this and the spec and think about it - but a couple of quick comments below.

Did not get my hands on the spec yet, but just firing random thoughts. This multi-link support sounds a bit like bonding. Could that be leveraged for wireless? I wonder why there is a need for a non-netdev interface. Does networking layer need to be aware of the multi-link for scheduling traffic to it? Is there one driver per multi-link or per radio?

[...]

Quoted 4 lines

Quoted 4 lines

struct sk_buff *msg;
void *hdr;

net/wireless/nl80211.c +2 -0

+	struct nlattr *nested, *nested_mlo_links;
+	struct cfg80211_mlo_link_device_params *mlo_link;

Quoted 8 lines

net/wireless/nl80211.c void nl80211_send_connect_result(struct cfg80211_registered_device *rdev, · line 16041

Quoted 6 lines

net/wireless/nl80211.c +3 -1

+	int i = 0;
    	msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
  			cr->fils.kek_len + cr->fils.pmk_len +
-			(cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+			(cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+			(cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);

32 probably should be some NLA_SIZE or something constant?

Probably sizeof(*mlo_link) ?

Quoted 16 lines

There's also no point in the ternary operator since 0 * 32 is 0 :)

net/wireless/sme.c void cfg80211_connect_done(struct net_device · line 855

Quoted 10 lines

/* Consumes bss object one way or another */

net/wireless/sme.c +3 -1

@@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device 
 *dev,
  	ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
  		     params->req_ie_len + params->resp_ie_len +
  		     params->fils.kek_len + params->fils.pmk_len +
-		     (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+		     (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+		     (params->n_mlo_links ? params->n_mlo_links *
+		      sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);

same here, no need for the ternary

Quoted 3 lines

It feels strangely asymmetric to have stop and no start ... but I guess that's the part where I need to think about it and look a bit at how it all works :)

Had the same feeling in my gutt (wherever that is ;-)

Regards,
Arend

Quoted 8 lines · Arend van Spriel

Quoted 7 lines · Johannes Berg

Hi,

Quoted 1 line

Multi-link support is introduced in 802.11be specification.

[...]

I'll definitely have to take a closer look at this and the spec and think about it - but a couple of quick comments below.

Thanks for your comments. Please allow me to address your comments in the subsequent patches.
Our main intention through this RFC is to get the view on the proposal to introduce a new NL80211_IFTYPE for an MLO Link.
Please suggest on this.

Quoted 6 lines

Did not get my hands on the spec yet, but just firing random thoughts. This multi-link support sounds a bit like bonding. Could that be leveraged for wireless? I wonder why there is a need for a non-netdev interface. Does networking layer need to be aware of the multi-link for scheduling traffic to it? Is there one driver per multi-link or per radio?

The following is what the Bonding driver / interface does for the multiple network interfaces.
1. Bonding driver aggregates multiple network interfaces into a single logical bonded interface.
2. Each network interface is called as a slave in the bonding driver.
3. It’s the Bonding driver that schedules the traffic across these slaves.
4. Bonding interface operates on one of the following modes ( mentioning for a quick reference ).
balance-rr : Round-robin policy: Transmit packets in sequential
order from the first available slave through the last.
active-backup : Only one slave in the bond is active. A
different slave becomes active if, and only if, the active slave fails.
balance-xor : Transmit based on the selected transmit hash
policy.
balance-tlb : channel bonding that does not require any special
switch support. The outgoing traffic is distributed according to the current load
balance-alb : includes balance-tlb plus receive load balancing.
5. With the above modes, the scheduling of the traffic is determined with in the kernel / bonding driver and have the host driver / firmware follow it.

The following are the factors for not considering the MLO Link as a bonding interface and further to propose this RFC
(new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).

1. For MLO, our intention is to allow the traffic scheduling (among the MLO links) to be closer to the lower layers in
the driver/firmware, etc, unlike the bonding driver where
kernel schedules the traffic.
2. If MLO Link has to use a bonding interface, each MLO link has to be associated with a network interface and thus each

        of the MLO link has to be of NL80211_IF_TYPE  -> 

NL80211_IFTYPE_STATION.
3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs to get triggered on each of this MLO Link of the
MLO connection.
4. Our intention is to consider the MLO station as a single network interface . More specifically, have a single NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO
connection ( MLD + MLO Links).
5. The reason we had to introduce a new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding link connection specific information ( e.g., Connection State,
Connected BSS Info, Connection Frequency/properties, etc),
for each wdev / MLO Link and at the same time have a single
connect / association request to the driver / AP.
6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall represent an MLO Link and attribute to a network interface ( MLD ) of an
MLO connection.
7. The current proposal to introduce a new NL80211_IF_TYPE should support the architectures of MLO links across the multiple wiphy interfaces or on the same wiphy interface. These wiphy
interfaces can be from different drivers too.

Please review the above.

Quoted 38 lines

[...]

Quoted 4 lines

Quoted 4 lines

struct sk_buff *msg;
void *hdr;

net/wireless/nl80211.c +2 -0

+	struct nlattr *nested, *nested_mlo_links;
+	struct cfg80211_mlo_link_device_params *mlo_link;

Quoted 8 lines

net/wireless/nl80211.c void nl80211_send_connect_result(struct cfg80211_registered_device *rdev, · line 16041

Quoted 6 lines

net/wireless/nl80211.c +3 -1

+	int i = 0;
    	msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len +
  			cr->fils.kek_len + cr->fils.pmk_len +
-			(cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+			(cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+			(cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);

32 probably should be some NLA_SIZE or something constant?

Probably sizeof(*mlo_link) ?

Quoted 19 lines

There's also no point in the ternary operator since 0 * 32 is 0 :)

net/wireless/sme.c void cfg80211_connect_done(struct net_device · line 855

Quoted 10 lines

/* Consumes bss object one way or another */

net/wireless/sme.c +3 -1

@@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device 
 *dev,
  	ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) +
  		     params->req_ie_len + params->resp_ie_len +
  		     params->fils.kek_len + params->fils.pmk_len +
-		     (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp);
+		     (params->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+		     (params->n_mlo_links ? params->n_mlo_links *
+		      sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);

same here, no need for the ternary

It feels strangely asymmetric to have stop and no start ... but I guess that's the part where I need to think about it and look a bit at how it all works :)

Quoted 1 line

Had the same feeling in my gutt (wherever that is ;-)

Sure. Will take this point. In fact, this was documented in the commit message to consider the start (say start_mlo_link), but do not want the drivers to depend on this trigger for starting the MLO link. For example, the host drivers with SME can as well start the MLO Link after getting the Assoc response for MLO links from the AP.

Quoted 3 lines

Regards,
Arend

Quoted 119 lines · On 2020-12-23 21:59, [email protected] wrote:

Quoted 8 lines · Arend van Spriel

Quoted 7 lines · Johannes Berg

Hi,

Quoted 1 line

Multi-link support is introduced in 802.11be specification.

[...]

I'll definitely have to take a closer look at this and the spec and think about it - but a couple of quick comments below.

Thanks for your comments. Please allow me to address your comments in the subsequent patches.
Our main intention through this RFC is to get the view on the proposal to introduce a new NL80211_IFTYPE for an MLO Link.
Please suggest on this.

Quoted 6 lines

Did not get my hands on the spec yet, but just firing random thoughts. This multi-link support sounds a bit like bonding. Could that be leveraged for wireless? I wonder why there is a need for a non-netdev interface. Does networking layer need to be aware of the multi-link for scheduling traffic to it? Is there one driver per multi-link or per radio?

The following is what the Bonding driver / interface does for the multiple network interfaces.
1. Bonding driver aggregates multiple network interfaces into a single logical bonded interface.
2. Each network interface is called as a slave in the bonding driver.
3. It’s the Bonding driver that schedules the traffic across these slaves.
4. Bonding interface operates on one of the following modes ( mentioning for a quick reference ).
       balance-rr : Round-robin policy: Transmit packets in sequential order from the first available slave through the last. active-backup : Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails.
       balance-xor : Transmit based on the selected transmit hash policy. balance-tlb : channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load
       balance-alb : includes balance-tlb plus receive load balancing.
5. With the above modes, the scheduling of the traffic is determined with in the kernel / bonding driver and have the host driver / firmware follow it.

The following are the factors for not considering the MLO Link as a bonding interface and further to propose this RFC
(new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).

1. For MLO, our intention is to allow the traffic scheduling (among the MLO links) to be closer to the lower layers in
        the driver/firmware, etc, unlike the bonding driver where kernel schedules the traffic.
2. If MLO Link has to use a bonding interface, each MLO link has to be associated with a network interface and thus each
        of the MLO link has to be of NL80211_IF_TYPE  -> NL80211_IFTYPE_STATION.
3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs to get triggered on each of this MLO Link of the
        MLO connection.
4. Our intention is to consider the MLO station as a single network interface . More specifically, have a single
        NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO connection ( MLD + MLO Links).
5. The reason we had to introduce a new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding
       link connection specific information ( e.g., Connection State, Connected BSS Info, Connection Frequency/properties, etc),
       for each wdev / MLO Link and at the same  time have a single connect / association request to the driver / AP.
6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall represent an MLO Link and attribute to a network interface ( MLD ) of an
      MLO connection.
7. The current proposal to introduce a new NL80211_IF_TYPE should support the architectures of MLO links across the multiple wiphy interfaces or on the same wiphy interface. These wiphy interfaces can be from different drivers too.

Please review the above.

Quoted 38 lines

[...]

Quoted 11 lines

Quoted 10 lines

      struct sk_buff *msg;
      void *hdr;
+    struct nlattr *nested, *nested_mlo_links;
+    struct cfg80211_mlo_link_device_params *mlo_link; +    int i = 0;
        msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + cr->fils.kek_len + cr->fils.pmk_len +
-            (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); +            (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+            (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);

Quoted 1 line

32 probably should be some NLA_SIZE or something constant?

Probably sizeof(*mlo_link) ?

Quoted 19 lines

There's also no point in the ternary operator since 0 * 32 is 0 :)

Quoted 10 lines

  /* Consumes bss object one way or another */

(quoted diff) +0 -0

@@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev,

      ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + params->req_ie_len + params->resp_ie_len + params->fils.kek_len + params->fils.pmk_len + -             (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); +             (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + +             (params->n_mlo_links ? params->n_mlo_links * +              sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp);

same here, no need for the ternary

It feels strangely asymmetric to have stop and no start ... but I guess that's the part where I need to think about it and look a bit at how it all works :)

Quoted 12 lines

Quoted 1 line

Had the same feeling in my gutt (wherever that is ;-)

Sure. Will take this point. In fact, this was documented in the commit message to consider the start (say start_mlo_link), but do not want the drivers to depend on this trigger for starting the MLO link. For example, the host drivers with SME can as well start the MLO Link after getting the Assoc response for MLO links from the AP.

Quoted 3 lines

Regards,
Arend

Hi,

Can you please provide your comments on the proposal. We wanted to hear your feedback on the following points.

Represent MLO link of an MLO connection by a wdev of type NL80211_IFTYPE_MLO_LINK_DEVICE.
MLO link wdev does not have an active netdev associated to it but will be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s connection information ( connected channel , BSSID, etc). MLD interface of an MLO connection will be a station interface (NL80211_IFTYPE_STATION wdev) This station interface shall link the wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211 layer shall link all such wdev’s. Such MLO Link wdev’s shall be part of the same wiphy or different wiphy (if host driver's register a single wiphy for each supported band/MAC/PHY).
MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user space prior the MLO connection.

User space can as well change the interface type among NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To support the use case where an existing STA wdev can change to a MLO wdev and vice versa.

Quoted 136 lines · On 2/9/2021 3:48 PM, [email protected] wrote:

Quoted 120 lines · On 2020-12-23 21:59, [email protected] wrote:

Quoted 8 lines · Arend van Spriel

Quoted 7 lines · Johannes Berg

Hi,

Quoted 1 line

Multi-link support is introduced in 802.11be specification.

[...]

I'll definitely have to take a closer look at this and the spec and think about it - but a couple of quick comments below.

Thanks for your comments. Please allow me to address your comments in the subsequent patches.
Our main intention through this RFC is to get the view on the proposal to introduce a new NL80211_IFTYPE for an MLO Link.
Please suggest on this.

Quoted 6 lines

Did not get my hands on the spec yet, but just firing random thoughts. This multi-link support sounds a bit like bonding. Could that be leveraged for wireless? I wonder why there is a need for a non-netdev interface. Does networking layer need to be aware of the multi-link for scheduling traffic to it? Is there one driver per multi-link or per radio?

The following is what the Bonding driver / interface does for the multiple network interfaces.
1. Bonding driver aggregates multiple network interfaces into a single logical bonded interface.
2. Each network interface is called as a slave in the bonding driver.
3. It’s the Bonding driver that schedules the traffic across these slaves.
4. Bonding interface operates on one of the following modes ( mentioning for a quick reference ).
       balance-rr : Round-robin policy: Transmit packets in sequential order from the first available slave through the last. active-backup : Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails.
       balance-xor : Transmit based on the selected transmit hash policy. balance-tlb : channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load
       balance-alb : includes balance-tlb plus receive load balancing.
5. With the above modes, the scheduling of the traffic is determined with in the kernel / bonding driver and have the host driver / firmware follow it.

The following are the factors for not considering the MLO Link as a bonding interface and further to propose this RFC
(new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE).

1. For MLO, our intention is to allow the traffic scheduling (among the MLO links) to be closer to the lower layers in
        the driver/firmware, etc, unlike the bonding driver where kernel schedules the traffic.
2. If MLO Link has to use a bonding interface, each MLO link has to be associated with a network interface and thus each
        of the MLO link has to be of NL80211_IF_TYPE  -> NL80211_IFTYPE_STATION.
3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs to get triggered on each of this MLO Link of the
        MLO connection.
4. Our intention is to consider the MLO station as a single network interface . More specifically, have a single
        NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO connection ( MLD + MLO Links).
5. The reason we had to introduce a new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding
       link connection specific information ( e.g., Connection State, Connected BSS Info, Connection Frequency/properties, etc),
       for each wdev / MLO Link and at the same  time have a single connect / association request to the driver / AP.
6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall represent an MLO Link and attribute to a network interface ( MLD ) of an
      MLO connection.
7. The current proposal to introduce a new NL80211_IF_TYPE should support the architectures of MLO links across the multiple wiphy interfaces or on the same wiphy interface. These wiphy interfaces can be from different drivers too.

Please review the above.

Quoted 39 lines

[...]

Quoted 11 lines

Quoted 10 lines

      struct sk_buff *msg;
      void *hdr;
+    struct nlattr *nested, *nested_mlo_links;
+    struct cfg80211_mlo_link_device_params *mlo_link; +    int i = 0;
        msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + cr->fils.kek_len + cr->fils.pmk_len +
-            (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); +            (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) +
+            (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp);

Quoted 1 line

32 probably should be some NLA_SIZE or something constant?

Probably sizeof(*mlo_link) ?

Quoted 20 lines

There's also no point in the ternary operator since 0 * 32 is 0 :)

Quoted 11 lines

  /* Consumes bss object one way or another */

(quoted diff) +0 -0

@@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device 
 *dev,

      ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + params->req_ie_len + params->resp_ie_len + params->fils.kek_len + params->fils.pmk_len + -             (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); +             (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + +             (params->n_mlo_links ? params->n_mlo_links * +              sizeof(struct cfg80211_mlo_link_device_params) :
0), gfp);

same here, no need for the ternary

It feels strangely asymmetric to have stop and no start ... but I guess that's the part where I need to think about it and look a bit at how it all works :)

Quoted 12 lines

Quoted 1 line

Had the same feeling in my gutt (wherever that is ;-)

Sure. Will take this point. In fact, this was documented in the commit message to consider the start (say start_mlo_link), but do not want the drivers to depend on this trigger for starting the MLO link. For example, the host drivers with SME can as well start the MLO Link after getting the Assoc response for MLO links from the AP.

Quoted 3 lines

Regards,
Arend

Hi,

Quoted 8 lines

Can you please provide your comments on the proposal. We wanted to hear your feedback on the following points.

Represent MLO link of an MLO connection by a wdev of type NL80211_IFTYPE_MLO_LINK_DEVICE.
MLO link wdev does not have an active netdev associated to it but will be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s connection information ( connected channel , BSSID, etc). MLD interface of an MLO connection will be a station interface (NL80211_IFTYPE_STATION wdev) This station interface shall link the wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211 layer shall link all such wdev’s. Such MLO Link wdev’s shall be part of the same wiphy or different wiphy (if host driver's register a single wiphy for each supported band/MAC/PHY).
MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user space prior the MLO connection.

From your explanation earlier it makes more sense to me now.

Quoted 1 line

User space can as well change the interface type among NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To support the use case where an existing STA wdev can change to a MLO wdev and vice versa.

This seems complicated especially for the "vice versa" scenario where wdevs may be linked to it across different wiphy instances. btw. would that also mean different drivers. I suspect it does, right?

Your explanation seems to focus on the station side of the MLO link, but I think on the AP side one would also setup a MLO link. Would the MLD interface be an AP interface in that case?

Actually, if I am not too confused here then what you call an "MLO link" device is called MLD in the spec.:

"""
multi-link device (MLD): A device that is a logical entity and has more than one affiliated station (STA) and has a single medium access control (MAC) service access point (SAP) to logical link control (LLC), which includes one MAC data service.
"""

The spec refers to AP MLD and non-AP MLD.

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

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.

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.

Both these wdev’s shall represent the MLO Link for an AP-MLD and each also represent an AP instance for the non-MLO / legacy client’s to connect.

MLO Link MAC address will be the MAC address of respective AP’s (netdev/wdev).

With this proposal, We plan to extend this for MLO too, by reusing this NL80211_IFTYPE_STATION wdev to represent the “association link” for an MLD connection
and new wdev type - NL80211_IFTYPE_MLO_LINK_DEVICE to represent the additional links of the same MLD connection.

Quoted 13 lines

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.

Quoted 3 lines

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?

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

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?

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)?

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

Quoted 2 lines

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.

Quoted 5 lines

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.

Hi ,
Thanks for your response.

Quoted 27 lines

Quoted 13 lines

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.

Quoted 3 lines

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;

Quoted 8 lines

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.

Quoted 16 lines

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.

Quoted 4 lines

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.

Quoted 9 lines

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 ?

Quoted 8 lines

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)?

Quoted 4 lines

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).

Quoted 24 lines

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

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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.

Quoted 194 lines · On 2021-02-12 22:33, [email protected] wrote:

Hi ,
Thanks for your response.

Quoted 31 lines

Quoted 13 lines

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.

Quoted 3 lines

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

Quoted 5 lines

    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.

Quoted 17 lines

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.

Quoted 4 lines

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.

Quoted 9 lines

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 ?

Quoted 8 lines

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)?

Quoted 4 lines

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).

Quoted 24 lines

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

Quoted 2 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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 ?

Quoted 2 lines

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