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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 16 Sep 2006 17:57:05 -0700

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

<PRC> So if I understand correctly, you believe that providing guidance
on the use of QoS is not sufficient, and that the AC must "negotiate"
with the WTP on what values to use for control, binding management and
binding data? This would be considered a new feature. 

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

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

<PRC> I think architecturally, I disagree. I believe that the CAPWAP
Control entity handles the base spec - maintaining that connection and
configuration with the peer. The CAPWAP Data entity, on the other hand,
is the one that actually understands the subtleties of 802.11 (or
whatever wireless binding). It handles the user associations, the 802.1x
state machine, etc. Further, as I noted above, it becomes complex to
decide what's management and what's not. Clearly, an 802.11 MAC
management frame would be a candidate, but what about EAPOL? What about
IAPP? This would require use to do an extensive protocol survey and list
the proper destination for each. 

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

	[Puneet]: It would be really nice to have a little blurb to this
effect in the spec. 
<PRC> Fair enough. Will create a tracker issue next time I have 'net
access.

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

	[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".

<PRC> Spec says 16, not 256. Don't understand the change
request/comment. 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Monday, September 11, 2006 6:40 PM
	To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]
	Subject: RE: Comments on -02 version of capwap spec

	Hi Pat, 

	Thanks for your reply. Pl see my comments. 

	<stuff deleted> 

	<stuff deleted> 

	<stuff deleted> 

	<stuff deleted> 

	Thanks. 

	-Puneet 

************************************************************************
********************** 
	-----Original Message----- 
	From: Pat Calhoun (pacalhou) [mailto:[email-masked]
<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 

	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: "Abhijit Choudhury" <[email-masked]>
Date: Sun, 17 Sep 2006 04:51:01 -0700

I agree with Pat here. The current architecture hands it 
cleanly. Sending 802.11 management traffic on the control
channel would cause lots of problems unless the 802.1X
and 4-way handshake were also carried on the control channel.
Since the latter are carried in 802.11 data packets, they
definitely belong on the data channel.
 
I think the real problem is that the 802.3 tunneling mode
has not been fully specified.  It's not clear how the 
802.11 management frames will be carried in the data channel
in 802.3 tunneling mode.  
 
Thanks,
   Abhijit

---

From: "David T. Perkins" <[email-masked]>
Date: Sun, 17 Sep 2006 09:27:41 -0700 (PDT)

HI,

Several of the proposals for the base capwap document specified that
802.11 control messages and 802.1X messages were encapsulated in
CAPWAP control messages. So, some believed (and maybe implemented)
such approaches.

It would be extremely useful to show the actual packet flows to
compare and contrast "stand-alone AP", "local-MAC WTP with AC",
and "split-MAC WTP with AC". I'm not sure this is well understood
by the WG, nor explained well in the CAPWAP spec.

Regards,
/david t. perkins

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 20 Sep 2006 12:18:13 -0700

Hi Pat,

Please see comments inline - tagged with [Puneet-9-20-06].

Thanks.

-Puneet 

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Saturday, September 16, 2006 5:57 PM
To: Puneet Agarwal; [email-masked]; [email-masked]
Subject: RE: Comments on -02 version of capwap spec

AC or 

[Puneet-9-20-06]: I think the spec does an adequate job of calling out
the mapping for  CAPWAP control and .11 management information mapping
to .1p etc values in the CAPWAP transport. However, my issue was how the
8 priorities in the .11 Data frames are mapped to the CAPWAP DATA .1p
transport - I have not seen how this mapping is done consistently across
all the WTPs.
For example, assume voice traffic has .11 DATA priority 7

WTP A maps .11 DATA priority 7 to CAPWAP DATA priority 4
WTP A maps .11 DATA priority !7 to CAPWAP DATA priority 0

WTP B maps all .11 DATA priority to CAPWAP DATA priority 0

Where both WTPs (A & B) are CAPWAP compliant but maybe from different
vendors.

In this case, I am not sure how one can have a consistent QoS policy in
the network as there is no mechanism in the current spec that instructs
the WTPs on mapping of .11 DATA frame QoS to CAPWAP DATA Transport QoS -
hence my earlier comment.

***********

[Puneet-9-20-06]: For .11 what you say may be the right choice. However
(and this may be more of a discussion for the base protocol spec), the
base protocol should provide a channel to carry the wireless protocols
native control/management frames inside CAPWAP control.

***********
with the 

[Puneet-9-20-06]: The specs defines a 8 bit WLANID in all the CAPWAP
messages - hence I assume that one can presumably support 256 WLANIDs.
If we can only support 16 WLANIDs per WTP (regardless of multicast),
then that should be called out specifically in the spec. If it is
already called out, then I would appreciate if you could point me to the
section #.
***********