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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 17 Sep 2006 13:10:52 -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.  

Abhijit,

The -03 spec includes specific language about tunneling 802.11 MAC
Management frames within 802.3. However, data frames are not
encapsulated, which means that you lose the concept of the BSSID.
However, you can request this information via the optional Radio MAC
Address header. I would be interested in knowing whether you believe the
latest spec addresses this sufficiently (once it is made available, of
course).

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 20 Sep 2006 15:08:50 -0700

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

<PRC> I believe that this is adequately covered in 802.11e, and more
importantly, WMM. The process of tagging 802.1p frames, based on the
802.11e UP field is well defined, and I believe, outside the scope of
CAPWAP.

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

I believe we need to have a consistent approach here, and complete
separation of the wireless binding of control vs. data is necessary.

> 
> ***********
> 	> 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." 
> 	> 
[...]
> <PRC> Fair enough. Will create a tracker issue next time I 
> have 'net access.

I've created issue 223.

> <PRC> Spec says 16, not 256. Don't understand the change 
> request/comment.
> 
> [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 #.
> ***********

The IEEE 802.11 WTP Radio Configuration specifically states:

  BSSID
    This attribute contains the maximum number of BSSIDs supported by
the
    WTP. This value restricts the number of logical networks supported
    by the WTP, and is between 1 and 16.

Given the correlation between BSSIDs and SSIDs (or WLANs), the maximum
WLANIDs would be 16.

Pat Calhoun