According to the best practices, which statement is true as related to the QoS policy that should be implemented on the outbound provider (P) to provider (P) router link in a service provider network that is supporting both VoIP and data?
A.
CBWFQ and CB-WRED should be implemented on the P router egress to provide a maximum bandwidth guarantee for the VoIP traffic.
B.
LLQ and CB-WRED should be implemented on the P router egress to support both VoIP and data traffic.
C.
CBWFQ and CB-RTP header compression should be implemented on the P router egress to ensure minimum latency for VoIP traffic.
D.
In the DiffServ model, ingress and egress QoS mechanisms are only required on the provider edge (PE) routers, so no QoS policy is needed on the P to P link.
Explanation:
1. Weighted random early detection (WRED) is a queuing technique for congestion avoidance. WRED manages how packets are handled when an interface starts becoming congested. When traffic begins to exceed the interface traffic thresholds prior to any congestion, the interface starts dropping packets from selected flows. If the dropped packets are TCP, the TCP source recognizes that packets are getting dropped, and lowers its transmission rate. The lowered transmission rate then reduces the traffic to the interface, avoiding congestion. Because TCP retransmits dropped packets, no actual data loss occurs.
WRED drops packets according to the following criteria: RSVP flows are given precedence over non-RSVP flows, to ensure that time-critical packets are transmitted as required. Using IP precedence or DSCP value of the packets, packets with higher precedence are less likely to be dropped. If the default settings are preventing QoS, the precedence value can be used to control how WRED determines when and how often to drop packets. The amount of bandwidth used by the traffic flow. Flows that use the most bandwidth are more likely to have packets dropped. The weight factor defined for the interface determines how frequently packets are dropped. WRED can be combined with CBWFQ. In this combination CBWFQ provides a guaranteed percentage of the output bandwidth, WRED ensures that TCP traffic is not sent faster than CBWFQ can forward it.
The abbreviated configuration below shows how WRED can be added to a policy-map specifying CBWFQ:Router(config)# policy-map prioritybw
Router(config-pmap)# class class-default fair-queue
Router(config-pmap-c)# class prioritytraffic bandwidth percent 40 random-detectThe random-detect parameter specifies that WRED will be used rather than the default tail-drop action.
2. The LLQ feature brings strict Priority Queuing (PQ) to CBWFQ. Strict PQ allows delay-sensitive data such as voice to be sent before packets in other queues are sent. Without LLQ, CBWFQ provides WFQ based on defined classes with no strict priority queue available for real-time traffic. For CBWFQ, the weight for a packet belonging to a specific class is derived from the bandwidth assigned to the class. Therefore, the bandwidth assigned to the packets of a class determines the order in which packets are sent. All packets are serviced fairly based on weight and no class of packets may be granted strict priority. This scheme poses problems for voice traffic that is largely
intolerant of delay, especially variation in delay. For voice traffic, variations in delay introduce irregularities of transmission manifesting as jitter in the heard conversation. LLQ provides strict priority queuing for CBWFQ, reducing jitter in voice conversations. LLQ enables the use of a single, strict priority queue within CBWFQ at the class level. Any class can be made a priority queue by adding the priority keyword. Within a policy map, one or more classes can be given priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is sent to the same, single, strict priority queue.
Although it is possible to queue various types of real-time traffic to the strict priority queue, it is strongly recommend that only voice traffic be sent to it because voice traffic is well-behaved, whereas other types of real-time traffic are not. Moreover, voice traffic requires that delay be non- variable in order to avoid jitter. Real-time traffic such as video could introduce variation in delay, thereby thwarting the steadiness of delay required for successful voice traffic transmission. When the priority command is specified for a class, it takes a bandwidth argument that gives maximum bandwidth in kbps. This parameter specifies the maximum amount of bandwidth allocated for packets belonging to the class configured. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class. In the event of congestion, policing is used to drop packets when the bandwidth is exceeded. Voice traffic queued to the priority queue is UDP-based and therefore not adaptive to the early packet drop characteristic of WRED. Because WRED is ineffective, the WRED random-detect command cannot be used with the priority command. In addition, because policing is used to drop packets and a queue limit is not imposed, the queue-limit command cannot be used with the priority command.