The next step is to
verify the QoS policy at the SSID level. The configuration assumes that voice
and video traffic are identified through the use of class-map and access-lists
and is tagged properly. However, some incoming traffic that is not targeted by
the access-list may not display its QoS marking. In such a case, you can decide
if this traffic should be marked with a default value or left untagged. The
same logic goes for traffic already marked but not targeted by the class-maps.
Use the
default copy
command in a table-map to ensure that unmarked traffic is left unmarked and the
tagged traffic keeps the tag and it is not remarked.
Table-maps decide
the outgoing DSCP value but are also used to create an 802.11 frame to decide
the frame UP value.
In the following
example, incoming traffic that displays voice QoS level (DSCP 46) maintains its
DSCP value and the value is mapped to the equivalent 802.11 marking (UP 6).
Incoming traffic that displays video QoS level (DSCP 34) maintains its DSCP
value and the value is mapped to the equivalent 802.11 marking (UP 5).
Similarly, traffic marked DSCP 24 may be voice signaling and the DSCP value
should be maintained and translated into the 802.11 UP 3:
Table-map dscp2dscp
Default copy
Table-map dscp2up
Map from 46 to 6
Map from 24 to 3
Map from 34 to 5
Default copy
Marking could also
be done at the incoming wired port level. The following figure shows what QoS
actions can be taken as traffic transits from wired to wireless:
Figure 2. QoS Touch
Points
The configuration
example described focuses on the wireless aspect of QoS configuration and marks
traffic at wireless client level. Once the marking portion has been completed,
you need to allocate bandwidth. Here, 6 Mbps of bandwidth is allocated to voice
traffic flows. (While this is the overall bandwidth allocation for voice, each
call would consume less - for example, 128 kbps.) The 6 Mbps bandwidth is
allocated with the
police
command to reserve the bandwidth and to drop traffic in excess.
The video traffic
is also allocated 6 Mbps and it is policed.
Note |
The configuration
assumes that there is only one video flow.
|
The signaling part
of the video and voice traffic also needs to be allocated bandwidth. There are
two possible strategies:
-
Use the shape
average command, which allows traffic in excess to be buffered and sent later.
This logic is not efficient for the voice or video flow because the voice and
video flows require consistent delay and jitter; however, it can be efficient
for signaling because signaling can be slightly delayed without an effect on
call quality. In the converged access solution,
shape
commands do not accept buckets configurations, which determine how much traffic
in excess of the allocated bandwidth can be buffered. Therefore, a second
command, queue-buffers ratio 0, must be added in order to specify that the
bucket size is 0. If you include signaling in the rest of the traffic and use
shape
commands, signaling traffic might be dropped in times of high congestion. This
might, in turn, cause the call to be dropped, because both the ends determine
that communication is no longer occurring.
-
To avoid the
risk of dropped calls, you can include signaling in one of the priority queues.
The configuration example previously defined the priority queues as voice and
video and now adds signaling to the video queue.
The policy uses
call admission control (CAC) for the voice flow. CAC targets wireless traffic
and matches a specific UP (in this configuration example, UP 6 and 7). CAC then
determines the maximum amount of bandwidth this traffic should use. In a
configuration where you police voice traffic, CAC should be allocated a subset
of the overall amount of bandwidth allocated for voice. For example, if voice
is policed to 6 Mbps, CAC cannot exceed 6 Mbps. CAC is configured in a
policy-map (called a child policy) that is integrated into the main downstream
policy-map (called the parent policy). CAC is introduced with the admit
cac
wmm-tspeccommand, followed by the target UPs and the bandwidth
allocated to the targeted traffic.
Each call does not
consume all the bandwidth allocated to voice. For example, each call may
consume 64 kbps each way, which results in 128 kbps of effective bi-directional
bandwidth consumption. The rate instruction determines each call bandwidth
consumption, while the police statement determines the overall bandwidth
allocated to voice traffic. If all calls that occur within the cell use close
to the maximum allowed bandwidth, any new call that is initiated from within
the cell and that causes the consumed bandwidth to exceed the maximum bandwidth
allowed for voice will be denied. You can fine tune this process through
configuration of CAC at the band level, as explained in Call Limitation with
CAC.
Therefore, you need
to configure a child policy that contains the CAC instructions and that is
integrated into the main downstream policy. CAC is not configured in the
upstream policy-map. CAC does apply to voice calls initiated from the cell,
but, because it is a response to those calls, CAC is set only into the
downstream policy-map. The upstream policy-map will be different. You cannot
use the class-maps created previously because these class-maps target traffic
based on an ACL. Traffic injected into the SSID policy has gone through the
client policy, so you should not perform inspection on the packets a second
time. Instead, target traffic with a QoS marking that results from the client
policy.
If you decide not
to leave signaling in the default class, you will also need to prioritize
signaling.
In the following
example, signaling and video are in the same class and more bandwidth is
allocated to that class to accommodate the signaling part. 6 Mbps is allocated
for video traffic (one Tandberg camera point-to-point flow) and 1 Mbps is
allocated to signaling for all voice calls and the video flow:
Class-map allvoice
match dscp ef
Class-map videoandsignaling
Match dscp af41
Match dscp cs3
The following
describes the downstream child policy:
Policy-map SSIDout_child_policy
class allvoice
priority level 1
police 6000000
admit cac wmm-tspec
rate 128
wlan-up 6 7
class videoandsignaling
priority level 2
police 1000000
The following
describes the downstream parent policy:
policy-map SSIDout
class class-default
set dscp dscp table dscp2dscp
set wlan user-priority dscp table dscp2up
shape average 30000000
queue-buffers ratio 0
service-policy SSIDout_child_policy
Upstream traffic
comes from wireless clients and is sent to the WCM before the traffic is sent
out of a wired port or to another SSID. In both cases, you can configure
policy-maps that define the bandwidth allocated to each type of traffic. The
policy will probably differ based on whether the traffic is sent out of a wired
port or to another SSID.
In the upstream
direction, the primary concern is to decide the priority and not the bandwidth.
In other words, the upstream policy-map does not allocate bandwidth to each
type of traffic. Because the traffic is already at the AP and has already
crossed the bottle-neck formed by the half-duplex wireless space, your goal is
to bring this traffic to the controller function of the Cisco Catalyst 3850
Series Switch for further processing. When traffic is collected at the AP
level, you can decide if you should trust potential existing QoS marking in
order to prioritize traffic flows sent to the controller. In the following
example, existing DSCP values can be trusted:
Policy-map SSIDin
Class class-default
set dscp dscp table dscp2dscp
As you create your
policies, apply the policy-maps to the WLAN.
In the following
example, any device connecting to the WLAN is expected to support WMM, so WMM
is required:
wlan test1
wmm require
service-policy client input taggingPolicy
service-policy input SSIDin
service-policy output SSIDout