Subject: Re: [Capwap] Comments on -02 version of capwap spec

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 5 Sep 2006 09:14:31 -0700

Finally got to completing my response to your list of issues.

> 1) Section 11.1.1 Split MAC
>   " All client data frames are tunneled between the WTP and the AC."
> 
>   It is unclear what is meant by Client Data Frames - is it only
>   802.11 data Frames or does it include 802.11 
> Management/Control Frames also?

The rest of this section discusses which of the management frames are
sent to the AC. So this specific bullet item is about IEEE 802.11 Data
Frames being tunneled. Would you be satisfied with a changes from
"Client Data Frames" to "Client IEEE 802.11 Data Frames"?

Being tracked as issue 210.

> 
> 2) In Split MAC, are 802.11 Management Frames sent in CAPWAP 
> data frames?
Yes

> 
> 3) If (2) is true (ignore otherwise), then what is the CAPWAP 
> priority of these frames?
>From the draft:
11.6 Quality of Service for Control Messages

   It is recommended that IEEE 802.11 MAC management frames be sent by
   both the AC and the WTP with appropriate Quality of Service values,
   ensuring that congestion in the network minimizes occurrences of
   packet loss.  Therefore, a Quality of Service enabled CAPWAP device
   should use:

   802.1P:   The precedence value of 6 SHOULD be used for all IEEE
      802.11 MAC management frames, except for Probe Requests which
      SHOULD use 4.

   DSCP:   The DSCP tag value of 46 SHOULD be used for all IEEE 802.11
      MAC management frames, except for Probe Requests which SHOULD use
      34.

> 
> 4) In Fig 5, "Split MAC Message Flow", why is the "Probe 
> Request" from the Client sent to the AC also - even though 
> all the processing was done at the WTP for this message?
In order for the AC to know the client is probing.

> 
> 5) In Fig 5, what is the semantics of the notation:
> "Add Mobile (Clear Text, 802.1X)"?
> I could not find the 2 parameters implied by "Clear Text" and "802.1X"
> in the
> description of Add Mobile in section 4.4.8 or in section 
> 11.9.9 (IEEE 802.11 Mobile).
Ah, this is a bug. The -02 document changed to utilizing the RSN info,
but the section you discuss did not include the necessary changes.

Created issue 211 to track this one.

> 
> 6) Section 11.9.9: "If the QoS field is set," - which field 
> (where) are you checking for the presence or absence of the Qos Field?

Another good catch of a change that is missing as a result of splitting
up message elements.

Created issue 212 to track this one.

> 
> 7) Radio ID, WLAN ID, BSSID - is there an implied 
> relationship between these various configured element ie many 
> radios to one WLAN ID etc.

A BSSID is assigned to a WLAN ID - so there is a 1:1 corelation there. A
WLAN can exist on one or more radios on the WTP.

> 
> 8) Assoc ID vs MAC Addr for id (which takes precedence or do 
> you need to do both checks)
Assoc ID is only used for power save - and is defined in the 802.11
protocol. When a packet is queued on the MAC for a domant station, its
association ID is included in beacons to notify it of packets sitting on
the queue.

The station is identified via its MAC address, not the association ID.

> 
> 9) Section 11.5: Please state clearly that even though these 
> are 802.11 Control Messages, they are still sent in CAPWAP 
> DATA messages (at least for now). 

Actually, these are for MAC management messages, not control messages,
so the header is incorrect. Further, your request, while valid, needs to
be handled in another section of the document. I will make this clearer.

Created issue 213 to track this issue

> 
> 10) What is the recommendation for 802.1P and DSCP values for 
> 802.11 Data
>     Frames? Do you honor the .11 QoS semantics between WTP 
> and AC or are all
>     .11 Data Frames sent at the same priority in CAPWAP?
That's an implementation issue.

> 
> 11) Should 802.1X frames be sent with different QoS than 
> regular 802.11 Data Frames? What is our QoS Philosophy for 
> such control traffic?
One would think so, and we should possibly consider this.

Created issue 214 to track this issue.
> 
> 12) It seems that within CAPWAP Data channel, there are 
> multiple 802.11 control channels (it seems that different QoS 
> levels are an implicit attempt at this
> - refer to section 11.5).
> General question to the group: Would it be beneficial to 
> transport these
> .11 control channels as "raw" data channels in CAPWAP Control 
> messages allowing the network to honor the 8 .1p priorities 
> for 802.11 Data frames in the CAPWAP DATA message.

I do not believe so. I think this would unnecessarily complicate the
protocol. Furthermore, if you went down this path, you'd have to put the
802.1X/EAPOL protocol in that channel... what about IAPP? etc. The
current model keeps the separation of wireless binding to control best.

> 
> 13) Section 11.1.2 Local MAC: The spec defines capability to 
> tunnel Client data frames as 802.3 frames between the WTP and 
> the AC. It would seem that the CAPWAP Data tunnel (as 
> currently defined) would need to carry both
> 802.3
> payload (for client data frames) and 802.11 payload (for RSNA 
> Key Mgmnt frames). Is this capability really desired?

You are correct that 802.11 MAC management frames may be sent, but
normal user frames would be in 802.3 format, as you had earlier
requested on the list. Figure 7 on page 101 makes this clear.

> 
> 14) Section 4.1 CAPWAP Transport Header - It seems that this 
> section should be renamed "CAPWAP Header" or all references 
> in section 4 and other places should be updated to be "CAPWAP 
> Transport Header".

Correct, for consistency sake we should make this change.

Created issue 215 to track this one.
> 
> 15) Section 4.1: The RID field here is 5 bits while in all 
> control messages it seems to be 8 bits - this needs to be reconciled
DUP issue, and already taken care of.

> 
> 16) Section 4.1: Description of RID field is unclear especially:
> 
> " WTPs with multiple radios but a single MAC Address range
>       use this field to indicate which radio is associated with the
>       packet."
> 
> It would be great if this could be clarified - it seems to be 
> implying that this is  used to support the case where 
> multiple radios share the same Radio MAC address but is not 
> very clear - is this the case?
The point is that the BSSID is not sufficient since some WTP vendors
re-use the BSSID across their a/bg radios. Since you guessed it, I
suppose it is good enough? Any recommended changes?

> 
> 17) Section 4.1:  I assume that implementations MUST support 
> 802.3 frames as well as "Native" frames in the same CAPWAP 
> Data Tunnel. Is this true and is that what we really want?
That was the agreement in a previous thread.

> 
> 18) Section 4.1: M bit. You mention in the text that "this 
> field MUST NOT be set to one in pkts sent by the AC to the WTP".
> 
> However, when you are transporting 802.3 frames, won't the AC 
> need to indicate  to the WTP what BSSID to use when sending 
> the frame (or is it assumed that  the BSSID is derived from 
> the dest Client's MAC Addr for unicast)?
good catch. Will fix this.

Created issue 216 to track this one.
> 
> 19) Section 11.9.1: For Tunnel Mode == "802.3 tunnel" in 
> Local MAC mode, how are RSNA frames converted to 802.3 as 
> they seem to be required for Local Mac
They are not. see above comment

> 
> 20) In Local MAC with 802.3 tunnel, how are 4 MAC 802.11 converted to
> 802.3
> without loss of info? Ie do we need to define TX-MAC element 
> also (in CAPWAP data frames from WTP to AC)?
They are not. If you need 4 address, use 802.11 frame formats. I think
there's a point where it makes hacking the protocol to support every
possible frame format become more complex. As an aside, TGs is now
working on a 6 address format - what will we do for that one?

That said, most applications use 3 address format, so 802.3 covers a
broad range of applications.

> 
> 21) In Split MAC Mode: when the WTP does 
> encryption/decryption, please specify the exact fields that 
> are valid when WTP sends such frames to the AC (as they are 
> now pseudo-802.11 frames after potential 802.11 reassembly in 
> the WTP).

will do.

Create issue 217 to track this one.

> 
> 22) Can the same WLAN ID be assigned to different radios with 
> the same BSSID?
Yes.

> 
> 23) Can the same WLAN ID be assigned to different radios with 
> different BSSID?
Yes.

> 
> 24) For multicast pkts, does AC need to send multiple copies 
> of the packet to send to each radio on the WTP that is part 
> of the same WLAN ID or is the packet replicated by the WTP to 
> all radios that are part of the same WLAN ID?
The purpose for the bitmap field is to avoid the need to replicate
packets to the same WTP. Note that if the packets are centrally
encrypted, then the packet needs to be replicated, and encrypted using
the right GTK. So from a performance point of view, multicast/broadcast
along with centralized encryption is the worst case. Of course, this is
equally true if DTLS is applied on the data plane. If the packet is
encrypted on the WTP, then only a single copy needs to be sent, with the
right bitmap.

> 
> 25) Local MAC with local bridge is the default mode - this 
> implies that all implementations must support this config 
> (which has the most complex s/w for the AP) - is that the 
> correct default and why was it chosen - should this be changed?
It was discussed during a thread. We needed to pick one.

> 
> 26) Why is the MAC mode and Tunnel Mode part of the WLANID 
> config? What is the practical reason for allowing this per WLANID?
Some vendors want the behavior to be different across WLANs. Sometimes
tunnel, and sometimes don't. The MAC Mode probably should be done on a
per WTP, IMHO.

> 
> 27) How does multicast handle the case when the number of 
> WLANIDs is greater than 16 - how does AC indicate that to the 
> WTP? It seems you run out of bits in the CAPWAP data packets.

The protocol already states that 16 is the hard limit.

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Puneet Agarwal" <[email-masked]>
Date: Mon, 11 Sep 2006 18:39:58 -0700

Hi Pat,

Thanks for your reply. Pl see my comments.

<stuff deleted>
>     Frames? Do you honor the .11 QoS semantics between WTP and AC or 
> are all
That's an implementation issue.
[Puneet]: I am fine with that. However, in that case, CAPWAP should
define a CAPWAP control message for the AC and WTP to exchange their .11
Data Frame mapping capabilities and for the AC to then instruct the WTP
to apply a particular mapping. Without this I am not sure how one can
ensure a consistent QoS in the network.
 
<stuff deleted>

[Puneet]: My main concern is the way 802.11 Management traffic is
handled today. It wasn't clear to me why we (the group) specified to
carry them in CAPWAP Data frames. I would have thought that they would
be carried in CAPWAP Control Frames as they would most likely be handled
by the CAPWAP Control entity (and not necessarily the CAPWAP Data
entity). Hence sending such packets to the CAPWAP Data entity seems like
a waste and it would eventually need to be sent to the CAPWAP control
entity.

<stuff deleted>

[Puneet]: It would be really nice to have a little blurb to this effect
in the spec.

<stuff deleted>

[Puneet]: If one wants to support (N > 16) WLANIDs (since the spec
allows for 256 WLAN IDs), then the AC should at least have the
capability to send N unicast copies of the packets to the WTP but
indicate a different WLANID. It wasn't clear how this would be achieved
for "802.3 Frame Tunnel Mode".

Thanks.

-Puneet 

************************************************************************
**********************
-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Tuesday, September 05, 2006 9:15 AM
To: Puneet Agarwal; [email-masked]; [email-masked]
Subject: RE: Comments on -02 version of capwap spec

>   802.11 data Frames or does it include 802.11 Management/Control 
> Frames also?

> 
> 2) In Split MAC, are 802.11 Management Frames sent in CAPWAP data 
> frames?
Yes

> 
> 3) If (2) is true (ignore otherwise), then what is the CAPWAP priority

> of these frames?

> 
> 4) In Fig 5, "Split MAC Message Flow", why is the "Probe Request" from

> the Client sent to the AC also - even though all the processing was 
> done at the WTP for this message?

> 
> 7) Radio ID, WLAN ID, BSSID - is there an implied relationship between

> these various configured element ie many radios to one WLAN ID etc.

> 
> 8) Assoc ID vs MAC Addr for id (which takes precedence or do you need 
> to do both checks)

> 
> 9) Section 11.5: Please state clearly that even though these are 
> 802.11 Control Messages, they are still sent in CAPWAP DATA messages 
> (at least for now).

>     Frames? Do you honor the .11 QoS semantics between WTP and AC or 
> are all

will do.

Yes.

Yes.

PatC