In a managed CE scenario, the customer’s network is supporting VoIP and bulk file transfers. According to the best practices, which QoS mechanisms should be applied on the WAN edge CE-PE 56-kbps Frame Relay link on the CE outbound direction?
A.
WRR, FRTS, FRF.12, and CB-RTP header compression
B.
WRR, CB-WRED, CB-Marking, FRF.12, and CB-RTP header compression
C.
CBWFQ, CB-WRED, CB-Marking, CB-Policing, and FRTS
D.
CBWFQ, FRTS, FRF.12, and CB-RTP header compression
E.
LLQ, CB-WRED, CB-Marking, FRTS, FRF.12, and CB-RTP header compression
F.
LLQ, CB-WRED, CB-Policing, and CB-TCP and CB-RTP header compressions
Explanation:
1. 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, Domain.com
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.