Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] Feedback on doc 11-21/228

Dear Abhi,

 

Thank you for your comments; please find my responses inline in blue.

 

Regards,

Rojan

 

From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Sent: Thursday, May 20, 2021 8:05 AM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Feedback on doc 11-21/228

 

 

Hi Rojan,

 

Thank you for your contribution on Proxy ARP and addressing.

 

As we discussed offline, I have several concerns with the proposal.

 

  1. It is mandating proxy ARP for all EHT APs

[RC] Yes, we believe mandating proxy ARP service will benefit the whole network by cutting down on the frequent ARP/ND traffic.

 

  1. The proposal is changing the behavior of Proxy ARP service. It requires the AP to identify the requester’s capabilities and the link it is operating on. Based on this determination, the AP can respond with a different value of MAC address for the same IP address:
    1. If the request originated from a legacy STA, and

                                                    i.     If the non-AP MLD had a STA operating on the link where the legacy STA is operating on then, the AP responds back with the link MAC address of the non-AP MLD .

        • In this case, the legacy STA binds the non-AP MLD's IP address to the link MAC address of the non-AP MLD

                                                   ii.     Else the AP responds with the MAC address non-AP MLD

        • In this case the legacy STA binds the non-AP MLD’s IP address to the MLD MAC address of the non-AP MLD
    1. If the request came from another non-AP MLD or from a device on the DS, the AP responds with the non-AP MLD’s MAC address

[RC] Yes, thanks for you excellent summary of our proposal. While I agree that there will be some increase in AP’s processing, an EHT AP is already expected to perform many of similar operations, e.g. mapping of associated non-AP MLD’s link MAC Addresses to/from its MLD MAC Address etc. And in return we avoid having to modify the RA/TA being set to MLD MAC Address, thereby not requiring each and every EHT STA to also change its frame reception filtering rules (i.e. to look out for MLD MAC Address in the RA).

 

  1. In addition, for a frame that originated from a non-AP MLD, the proposal requires the AP to set the SA field differently based on the intended recipient of the frame
    1. If the recipient is a legacy STA operating on one of the link where the non-AP MLD has setup a link with the AP, the SA set to link MAC of the non-AP MLD
    2. Else the SA is set to the MLD MAC address of the non-AP MLD

 

  1. AP MLD needs to do a reverse translation when it receives a frame from legacy STA addressed to a non-AP MLD

[RC] Yes but EHT AP is already expected to perform many of similar operations, e.g. mapping of associated non-AP MLD’s correct link MAC Addresses when a frame needs to be forwarded on another link etc.

 

The above requirements put a heavy burden on the AP MLD.

Also, responding with different MAC address for the same IP address can have other ramifications.

[RC] Agree that our proposal is prioritizing non-AP’s benefits over AP’s complexity. Anyway APs are expected to be more powerful devices and we believe this is a fair trade off between AP complexity and non-AP’s benefits.

 

Our proposal in doc 240 does not put any additional requirements on the AP and the entire TDLS operation is transparent to the AP. It is in line with the AP’s processing of a packet arriving from the backhaul, where translation of MLD MAC address to link MAC address needs to be performed. In addition, Proxy ARP remains an optional feature at the AP MLD. If the AP MLD supports proxy ARP, the ARP response is always consistent regardless of who made the request (a non-AP MLD’s IP address is always mapped to the same value which is the MAC address of the non-AP MLD). Furthermore, the setting of the SA field at the AP is consistent for all frames originating at the non-AP MLD (i.e., SA is always set to the MAC address of the non-AP MLD) regardless of who is the recipient.

[RC] While we agree that your proposal does solve the TDLS addressing issue without requiring AP to do much extra processing, it does require modifying the current RA/TA setting rules which mandates that they are set as MAC address of the affiliated STA (and not the MLD MAC Address). Even if the RA/TA of selected frames are allowed to be set as the MLD MAC Address, all EHT STAs/MLDs will have to change their RA filtering rule to also accept frames with the RA matching its MLD MAC Address. So there is cost involved with this proposal as well, and it impacts the implementation for all EHT STAs/MLD and not just APs/AP MLDs. Below is the relevant text from 11be Draft, this clause needs to be suitably modified if the RA/TA are to be allowed to be set as MLD MAC Address:

35.3.3 Multi-link device addressing

(#1158)The value of the Address 2 (TA) field (if present) in the MAC header of a frame sent over-the-air shall be the MAC address of the transmitting STA affiliated with the MLD corresponding to that link except the Individual/Group bit, which is set to 1 when the TA field value is a bandwidth signaling TA and set to 0 otherwise.

The value of the Address 1 (RA) field in the MAC header of an individually addressed frame sentover-the-air shall be the MAC address of the receiving STA affiliated with the MLD corresponding to that link.

 

Regards,
Abhi

 

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1