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

Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval



Hi all,

I think we should really limit as much as possible the use of the different Types, as this will highly complicate the parsing.

We have designed the common part so that we can indicate if fields are present or not, we should use that.

Similarly, the per-STA part is made of subelements so that we can include what we need, while having the same structure. If we want to have some indications that are fields and not elements, we can easily include a control field that will indicate the presence of the fields (same as the common part).

 

Best,

Laurent

 

 

From: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Sent: Tuesday, January 26, 2021 7:01 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval

 

Hi Yongho,

 

Yes, I am aware that we have defined GTK, IGTK, BIGTK KDEs in D0.3, however these are not subelements. If we go the subelement route, anyway we also need to define new subelements for each procedure (WNM, Fast BSS Transition, FILS etc.) in order to signal the Link Ids of the APs, so it is not really straightforward reusing of existing subelements as well.

 

While I agree with you that we should have a single consistent method, I think that using ML element is the better option. Instead of limiting to WNM case, we could expand the usage of Abhi’s new variant of ML element so that it can cater for all Key distributions scenarios, may be rename it “Key Distribution variant ML element“? Perhaps we can even revisit whether the new KDEs in D0.3 can be changed to use this ML element so that we have one unified way to distribute the keys. This approach is also similar to the inclusion of the Multi-band element in the 4-way handshake messages. Implementation wise this will also make the parsing simpler since a single ML element variant need to be parsed instead of different subelements. What do you think?

 

Regards,

Rojan

 

From: Yongho Seok <yongho.seok@xxxxxxxxx>
Sent: Tuesday, January 26, 2021 1:08 PM
To: Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 21/055 - PDT for WNM Sleep Interval

 

Hi Rojan, 

KDE format also needs to carry GTK, IGTK, and BIGTK of other APs.

On that purpose, in D0.3, we already defined the MLO GTK, MLO IGTK, and MLO BIGTK subelements, instead of creating a new variant of the ML element. This way is the same approach done in the Multi-band GTK KDE.

In addition to the WNM Sleep Mode Response, Fast BSS Transition IE needs to carry GTK, IGTK, and BIGTK of other APs. My preference is that all three just use a single consistent way. In that sense, it is straightforward to follow the same way done in KDE. Otherwise, too many variants of the ML element are needed for this simple usage scenarios. You know, FILS has not been discussed yet, if it is supported in MLO, Key Delivery element is also need to be updated...    

 

Regards, 

Yongho 

 

2021 1 25 () 오후 6:16, Rojan Chitrakar <rojan.chitrakar@xxxxxxxxxxxxxxxx>님이 작성:

Hi Abhi,

 

I am supportive of your use of the ML element, I think it is more organized and provides a unified method of signaling ML parameters.

 

Regarding the below, I see that the baseline covers two cases: current GTK and pending GTK, I believe we should also capture the two cases for the other APs. Now for pending GTKs, not all APs’ GTKs may need to be updated at the same time, so we cannot assume that the ML element carries GTKs of all APs, as such the inclusion should be a “may”.

11.2.3.16.3 WNM sleep mode AP operation

An AP of an AP MLD may include the WNM Sleep Response variant of Multi-Link element in the WNM Sleep Mode Response frame to provide the GTK/IGTK/BIGTK information for link(s), that are part of the multi-link setup, other than the one where the frame was transmitted.

 

Best regards,

Rojan Chitrakar

 


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


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


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