Subject: RE: [Capwap] to mux or not to mux?

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 10:33:35 -0700

> I am not sure I understand: Does every control message also 
> contain the BSSID? If not, then how is BSSID the binding 
> between the control and data messages? With a single port 
> approach all traffic on that 
> <src_ip,src_port,dst_ip,dst_port> is one bound channel.
It is part of the CAPWAP header, but as requested it is optional. If the
encap type is 802.11, then this is not required, because the BSSID is
part of the 802.11 header. However, the MAC address field is useful for
802.3 data. So yes, it is present.

> I thought the DSCP/ToS values in the IP header was the 
> standard way to do QoS (and the 802.1p priorities), not based 
> on UDP port numbers.
> WiFi WMM tests for example dont map wired traffic to wireless 
> access categories depending on what UDP port number that 
> traffic came on, they use DSCP/802.1p.
What we have done in the protocol is define a default set of values.
While this happens in many protocols today, IT administrators still use
ACLs to provide additional policy enforcement.

> So the WAN router looks at the DSCP values of the packets, 
> and provides better service to the CAPWAP control frames. In 
> fact this should work without any configuration on a 
> networking device that honors DSCP/ToS bits. With the UDP 
> port QoS proposal every device between the AC and the WTP 
> would have to be configured to understand that there are two 
> port numbers here and one of them is of higher priority than 
> the other.
Except the values we've provided may conflict with existing values they
use, so the administrator may want to *re-write* the DSCP/ToS bits based
on the packet type.

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: Puneet <[email-masked]>
Date: Fri, 5 May 2006 10:56:28 -0700

> 802.3 data. So yes, it is present.

but thats an optional field, unlike the binding that mux provides
which will always be present. So strictly speaking, use of 2 ports
*might* provide binding between the control and data channels
depending on the implementation. A single port + mux always works.

<snip>

> use, so the administrator may want to *re-write* the DSCP/ToS bits based

for that case how about making the DSCP mappings configurable? The AC
can pick the value that is provided to it by the local configuration,
and the AC can then provide these values to the WTP in the
configuration message. The WTP can then start using these DSCP/ToS
values for its control and data frames. This way the users can get
whatever QoS values they want from the two devices that are actually
doing the talking, without having to muck with ACL rules in the
intermediate devices.

Thanks,
Puneet