Capwap Mailing List: RE: question on LWAPP-03 draft

[Pat Calhoun (pacalhou) (pcalhoun]

See below

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

> -----Original Message-----
> From: Puneet Agarwal [mailto:pagarwal [at] broadcom.com] 
> Sent: Monday, July 25, 2005 4:34 PM
> To: Pat Calhoun (pacalhou); capwap [at] frascone.com
> Subject: RE: question on LWAPP-03 draft
> 
> Hi Pat,
> 
> Thanks for your clarifications. A few follow-on comments and 
> a couple of new questions.
> 
> (a) I completely agree with you that with the introduction of 
> HCCA, it makes sense to have the .11 fragmentation and hence 
> .11i encryption at the WTP. By the symmetry argument, I 
> presume that you are also implying that .11i decryption and 
> .11 defragmentation should also happen at the WTP (for LWAPP 
> Split MAC).
<PRC> That is correct. Note that LWAPP supports the AC providing this
feature, with the restriction that HCCA cannot be used (and this is not
an LWAPP limitation, this is a technology limitation for any protocol
that encrypts in the AC).

> 
> (b) Thanks for clarifying this. As a corollary, it would be 
> great if you could also state what .11 header fields MUST be 
> valid when sending a .11 frame (in LWAPP) from the AC to the 
> WTP. I assume that, at the minimum, the Address1, Address2 
> and Address3 fields MUST be valid. If this is a .11e enabled 
> client, then the TID field MUST be valid. However what is not 
> clear is that if the client needs .11i encryption, is the AC 
> required to attach the .11i dummy CCMP header as well as a 
> dummy MIC to the .11 data frame before sending it to the WTP 
> (in a LWAPP tunnel)?
<PRC> Good point. Today, all of the address and 802.11e TID fields must
be present,
and include the proper values. However, the encryption pad is not
present if encryption
is done in the WTP. I will update the draft to make this explicit.

> 
> (c) While LWAPP tunneling, an AC implementation may decide to 
> fragment at the
> .11 level to get over network MTU limits and avoid LWAPP/IP 
> fragmentation (it seems to be legal in LWAPP though there is 
> no explicit mention in the spec either allowing/disallowing 
> it). In this case, the WTP implementations will require valid 
> values in the "Sequence number" and "Fragment number" for 
> correct LWAPP reassembly - though these may be rewritten by 
> the WTP before transmission to the Client. Hence it would be 
> great if you could specify which .11 fields MUST be valid and 
> which fields are ignored by the WTP for data packets received 
> by the WTP from the AC.
<PRC> hmm.... We don't assume this because we cannot control the client
- hence you have this problem in traffic from the station. I believe the
current model the protocol provides is more reliable.

> 
> (d) For packets from Client to the network, the WTP will 
> reassemble the fragmented .11 frames. In order to send the 
> MSDU to the AC, the WTP would need to create a new .11 header 
> (before encapsulation the frame into a LWAPP
> tunnel) but without fragments (ie .11 Header.More_Frag = 0). 
> Is this a correct assumption?
> Similarly, if the Client's frame came in with .11i 
> encryption, then will the WTP send the MSDU to the AC with a 
> dummy .11i CCMP header/MIC or will it remove the .11i CCMP 
> header. Hence it would be great if you can clarify which
> .11 header fields must be valid when .11 data frames are sent 
> from WTP to AC (in LWAPP).
<PRC> Correct, I believe this goes back to your point #2 (above), which
we will address in the next version of the draft.