LLQ, or PQ/CBWFQ
With the emergence of voice traffic into data networks, the need to differentiate between the various classes of service has become greater. PQ/CBWFQ, most commonly known as LLQ, is a new feature that provides a strict priority queue for voice traffic and a weighted fair queue for each of the other classes of traffic. LLQ brings strict priority queuing to the CBWFQ scheme. Figure 18-4 illustrates the basic concepts of how LLQ works.
Figure 18-4. How LLQ Works
Without LLQ, the CBWFQ scheme provides WFQ to classes of traffic defined by the user, but there is no strict priority queue for delay-sensitive traffic, such as voice. CBWFQ allows the user to reserve a minimum bandwidth for a class during congestion. However, this scheme does not work well for voice traffic, which is intolerant of delay. Delay in voice traffic results in irregular transmission causing jitter in the heard conversation. For good voice quality, the one-way end-to-end delay should ideally be less than 150 milliseconds (ms). The new feature provided by LLQ is especially important for ensuring voice quality on slow-speed links.
With LLQ, a strict priority queuing scheme improves the QoS by allowing delay-sensitive traffic, such as voice, to be dequeued from the queuing system and sent before other classes of traffic. The priority queue is also policed to ensure that the fair queues are not starved of bandwidth. Packets that exceed the configured maximum in the PQ are dropped. Although LLQ is most commonly deployed on mixed voice/data networks for voice traffic, other mission-critical traffic can be classified and transmitted from the priority queue.
LLQ offers much more flexibility than previous Frame Relay QoS features, such as Real-Time Protocol (RTP) prioritization and PQ/WFQ for Frame Relay. With RTP prioritization and PQ/WFQ, traffic that matches a specified UDP/RTP port range is considered high priority and allocated to the PQ. LLQ allows the user to define classes of traffic based on protocols, source interfaces, or access lists. Each class of traffic can be assigned characteristics, such as priority, bandwidth, queue-limit, and random-detect (WRED), in a way similar to CBWFQ.
Frame Relay QoS Features Related to LLQ
LLQ for Frame Relay is related to several QoS features for Frame Relay and can be used in conjunction with them. The Frame Relay QoS features related to LLQ are the following:
• Frame Relay Traffic Shaping To use LLQ for Frame Relay, Frame Relay Traffic Shaping must be enabled on the main interface. FRTS is a prerequisite for LLQ. This is verified in the examples in the later sections of this chapter.
• RTP Prioritization for Frame Relay The RTP Prioritization for Frame Relay feature provides a strict priority queuing scheme for voice traffic. The voice traffic is identified by its RTP port numbers and classified into a priority queue using the frame-relay ip rtp priority map-class configuration command. When RTP Prioritization is used in conjunction with LLQ, voice traffic that matches the specified range is queued in the LLQ PQ and the interface priority queue.
• Voice over Frame Relay (VoFR) When VoFR is configured in conjunction with LLQ, it uses the LLQ PQ rather than its own priority queuing mechanism. VoFR is enabled with the frame-relay voice bandwidth map-class configuration command, which sets the total bandwidth made available to VoFR traffic. The vofr data command is supported with LLQ for Frame Relay. When VoFR has no data, all the voice and call control packets are queued in the VC priority queue. For VoFR with data, a FRF.11 PVC can carry both voice and data packets in different subchannels. The FRF.11 data packets are fragmented and interleaved with the voice packets.
• Frame Relay Fragmentation (FRF.12) Frame Relay Fragmentation (FRF.12) is used to support voice and data packets on lower-speed links without causing excessive delay to the voice packets. When FRF.12 is configured, the smaller voice packets queued in the priority queue are sent unfragmented. Large data packets classified to the priority queue are fragmented when dequeued. This causes the fragmented data packets to be interleaved with the unfragmented voice packets. This interleaving ensures minimum delay for the delay-sensitive voice packets.
• IP Cisco Express Forwarding (CEF) Switching The IP CEF switching functionality is transparent to LLQ for Frame Relay and is expected to work with LLQ for Frame Relay.
Features Not Supported with LLQ for Frame Relay
In Cisco IOS Release 12.1(2)T, the LLQ for Frame Relay feature is not compatible with certain legacy Frame Relay features. When using LLQ for Frame Relay with an earlier supported Cisco IOS release, please ensure the Frame Relay features listed in this section are not configured together with LLQ. The following Frame Relay features are not supported with LLQ for Frame Relay:
• Frame Relay switching
• GTS
• Traffic shaping commands in MQC CLI
• Fancy queuing: Frame Relay priority queuing and Frame Relay custom queuing
In addition, any queue other than a FIFO queue that is configured in the Frame Relay map class must be removed. LLQ for Frame Relay cannot be used if there is already a non-FIFO queue configured, except for the default queue created when fragmentation is enabled.
In the next section, a simple scenario illustrates how LLQ can be configured on a Cisco router to support voice and data traffic on a heterogeneous network.
Configuring LLQ for Frame Relay
The LLQ for Frame Relay feature is available in Cisco IOS Release 12.1(2)T or later and is supported on c805, c1600, c1700, c2500, c2600, c3600, c3810, and c7200 series routers. The latest Cisco IOS release might support the LLQ for Frame Relay feature on the newer Cisco router platforms, such as c2600-XM, c3700, and c7600.
The Cisco MQC interface CLI is used to configure LLQ for Frame Relay. To configure LLQ for Frame Relay, the queues are set up on a per-PVC basis. Each VC has a PQ and an assigned number of fair queues. In a manner identical to CBWFQ, LLQ for Frame Relay is configured with a combination of class-map, policy-map, and Frame Relay map-class commands. Traffic classes are set up with the class-map command to classify the traffic. The user determines how the traffic is classified based on protocols, source interfaces, or access lists. Then the policy-map command is used to create a traffic policy whereby the user can configure how each class of traffic is treated in the queuing system. The policies can be based on priority (PQ), bandwidth, queue limit, or WRED. Finally, the policy-map is attached to a Frame Relay VC using the service-policy output command in the Frame Relay map class. The map class is, in turn, assigned to the Frame Relay DLCI.
If you skipped the earlier sections on MQC interface CLI or CBWFQ, reading those sections to become familiarized with the configuration tasks for MQC or CBWFQ is recommended. Otherwise, Figure 18-5 shows the topology of the network that is used to illustrate LLQ for Frame Relay.
Figure 18-5. Network Diagram to Illustrate LLQ for Frame Relay
Figure 18-5 illustrates the scenario of a small firm that has a central office connected to several branch offices across a nationwide Frame Relay network. The firm wishes to leverage on VoIP and multicast to support desktop video conferencing applications on its network. To optimize the application performance for the real-time traffic on the network, the firm needs to manage the network performance with respect to bandwidth, delay, jitters, and packet loss. In addition, the firm needs to service the needs of other applications running over the WAN. Hence, the firm decides to implement LLQ on its Frame Relay network. A strict priority queue is created to minimize delay for the real-time delay-sensitive traffic. LLQ polices the real-time traffic in the strict priority queue and ensures that other nonpriority traffic on the network, such as SNA and sales data transfers, is not starved of bandwidth.
NOTE
The network implementer advised the firm against using oversubscription, because it usually leads to packet discards and might result in poor voice/video quality.
The network in Figure 18-5 is set up, and the configurations of the routers are shown in Example 18-9. Notice that only the configurations of routers R1 and R2 are shown in Example 18-9, because the configurations for R3 or R4 are very similar to those of R2.
Example 18-9. Configurations of the Routers in Figure 18-5
! Router R1:
<output omitted>
class-map match-all SALES_DATA
match access-group 103
class-map match-any SNA_DATA
match protocol dlsw
match access-group 102
class-map match-all VIDEO
match access-group 101
!
!
policy-map LLQ
class VIDEO
priority 64
class SNA_DATA
bandwidth 32
queue-limit 100
class SALES_DATA
bandwidth 16
class class-default
fair-queue
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
!
interface Serial4/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial4/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
frame-relay interface-dlci 102
class LLQ_class
!
interface Serial4/0.103 point-to-point
ip address 172.16.1.5 255.255.255.252
frame-relay interface-dlci 103
class LLQ_class
!
interface Serial4/0.104 point-to-point
ip address 172.16.1.9 255.255.255.252
frame-relay interface-dlci 104
class LLQ_class
!
!
map-class frame-relay LLQ_class
frame-relay cir 128000
frame-relay mincir 128000
no frame-relay adaptive-shaping
service-policy output LLQ
!
ip route 20.0.0.0 255.255.255.0 172.16.1.2
ip route 30.0.0.0 255.255.255.0 172.16.1.6
ip route 40.0.0.0 255.255.255.0 172.16.1.10
!
access-list 101 permit udp any any eq 12000
access-list 102 permit tcp any eq 2065 any
access-list 102 permit tcp any any eq 2065
access-list 103 permit tcp host 10.0.0.2 any eq 10000
________________________________________________________________
! Router R2:
<output omitted>
class-map match-all SALES_DATA
match access-group 103
class-map match-any SNA_DATA
match protocol dlsw
match access-group 102
class-map match-all VIDEO
match access-group 101
!
!
policy-map LLQ
class VIDEO
priority 64
class SNA_DATA
bandwidth 32
queue-limit 100
class SALES_DATA
bandwidth 16
class class-default
fair-queue
!
interface FastEthernet0/0
ip address 20.0.0.1 255.255.255.0
!
interface Serial2/1
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial2/1.201 point-to-point
ip address 172.16.1.2 255.255.255.252
frame-relay interface-dlci 201
class LLQ_class
!
map-class frame-relay LLQ_class
frame-relay cir 128000
frame-relay mincir 128000
no frame-relay adaptive-shaping
service-policy output LLQ
!
ip route 10.0.0.0 255.255.255.0 172.16.1.1
ip route 30.0.0.0 255.255.255.0 172.16.1.1
ip route 40.0.0.0 255.255.255.0 172.16.1.1
!
access-list 101 permit udp any any eq 12000
access-list 102 permit tcp any eq 2065 any
access-list 102 permit tcp any any eq 2065
access-list 103 permit tcp host 20.0.0.2 any eq 10000
In the network diagram in Figure 18-5, each remote site has a Frame Relay VC with a minimum access speed of 128 kbps terminating into the central location. To prevent oversubscription, Frame Relay Traffic Shaping is enabled, and the routers are allowed to burst only up to the CIR rate. Hence, both the minimum CIR and the CIR are set to 128 kbps in Example 18-9.
Although bursting over Frame Relay can be attractive for data networks, it might not be desirable on integrated voice and data networks because voice packets might be dropped. A discarded voice packet can result in retransmission and cause jitter and result in poor voice quality. This can also cause slow response to the user desktop application.
The various traffic classes are defined with the class-map commands. The traffic is classified to the class-map by means of protocol types, input interfaces, or access lists. For instance, in Example 18-9, the traffic destined for the priority queue is classified with an extended access list 101 that matches UDP traffic with port number 12000. Then the CBWFQ scheme is used to serve both the SNA and sales data traffic on the network. All the remaining traffic not matched by the priority class map or the CBWFQ class maps are sent to the default class.
A policy-map named LLQ is configured to define how each identified class of traffic is handled in the traffic policy. A priority queue with a bandwidth of 64 kbps is used to service desktop video conferencing traffic running on UDP port 12000. The SNA and sales data are assigned a bandwidth of 32 kbps and 16 kbps, respectively. Traffic in the default class is serviced based on best-effort delivery using a flow-based fair queuing scheme.
The next section verifies the workings of the LLQ system by observing the outputs of the various show commands.
Figure 18-4. How LLQ Works
Without LLQ, the CBWFQ scheme provides WFQ to classes of traffic defined by the user, but there is no strict priority queue for delay-sensitive traffic, such as voice. CBWFQ allows the user to reserve a minimum bandwidth for a class during congestion. However, this scheme does not work well for voice traffic, which is intolerant of delay. Delay in voice traffic results in irregular transmission causing jitter in the heard conversation. For good voice quality, the one-way end-to-end delay should ideally be less than 150 milliseconds (ms). The new feature provided by LLQ is especially important for ensuring voice quality on slow-speed links.
With LLQ, a strict priority queuing scheme improves the QoS by allowing delay-sensitive traffic, such as voice, to be dequeued from the queuing system and sent before other classes of traffic. The priority queue is also policed to ensure that the fair queues are not starved of bandwidth. Packets that exceed the configured maximum in the PQ are dropped. Although LLQ is most commonly deployed on mixed voice/data networks for voice traffic, other mission-critical traffic can be classified and transmitted from the priority queue.
LLQ offers much more flexibility than previous Frame Relay QoS features, such as Real-Time Protocol (RTP) prioritization and PQ/WFQ for Frame Relay. With RTP prioritization and PQ/WFQ, traffic that matches a specified UDP/RTP port range is considered high priority and allocated to the PQ. LLQ allows the user to define classes of traffic based on protocols, source interfaces, or access lists. Each class of traffic can be assigned characteristics, such as priority, bandwidth, queue-limit, and random-detect (WRED), in a way similar to CBWFQ.
Frame Relay QoS Features Related to LLQ
LLQ for Frame Relay is related to several QoS features for Frame Relay and can be used in conjunction with them. The Frame Relay QoS features related to LLQ are the following:
• Frame Relay Traffic Shaping To use LLQ for Frame Relay, Frame Relay Traffic Shaping must be enabled on the main interface. FRTS is a prerequisite for LLQ. This is verified in the examples in the later sections of this chapter.
• RTP Prioritization for Frame Relay The RTP Prioritization for Frame Relay feature provides a strict priority queuing scheme for voice traffic. The voice traffic is identified by its RTP port numbers and classified into a priority queue using the frame-relay ip rtp priority map-class configuration command. When RTP Prioritization is used in conjunction with LLQ, voice traffic that matches the specified range is queued in the LLQ PQ and the interface priority queue.
• Voice over Frame Relay (VoFR) When VoFR is configured in conjunction with LLQ, it uses the LLQ PQ rather than its own priority queuing mechanism. VoFR is enabled with the frame-relay voice bandwidth map-class configuration command, which sets the total bandwidth made available to VoFR traffic. The vofr data command is supported with LLQ for Frame Relay. When VoFR has no data, all the voice and call control packets are queued in the VC priority queue. For VoFR with data, a FRF.11 PVC can carry both voice and data packets in different subchannels. The FRF.11 data packets are fragmented and interleaved with the voice packets.
• Frame Relay Fragmentation (FRF.12) Frame Relay Fragmentation (FRF.12) is used to support voice and data packets on lower-speed links without causing excessive delay to the voice packets. When FRF.12 is configured, the smaller voice packets queued in the priority queue are sent unfragmented. Large data packets classified to the priority queue are fragmented when dequeued. This causes the fragmented data packets to be interleaved with the unfragmented voice packets. This interleaving ensures minimum delay for the delay-sensitive voice packets.
• IP Cisco Express Forwarding (CEF) Switching The IP CEF switching functionality is transparent to LLQ for Frame Relay and is expected to work with LLQ for Frame Relay.
Features Not Supported with LLQ for Frame Relay
In Cisco IOS Release 12.1(2)T, the LLQ for Frame Relay feature is not compatible with certain legacy Frame Relay features. When using LLQ for Frame Relay with an earlier supported Cisco IOS release, please ensure the Frame Relay features listed in this section are not configured together with LLQ. The following Frame Relay features are not supported with LLQ for Frame Relay:
• Frame Relay switching
• GTS
• Traffic shaping commands in MQC CLI
• Fancy queuing: Frame Relay priority queuing and Frame Relay custom queuing
In addition, any queue other than a FIFO queue that is configured in the Frame Relay map class must be removed. LLQ for Frame Relay cannot be used if there is already a non-FIFO queue configured, except for the default queue created when fragmentation is enabled.
In the next section, a simple scenario illustrates how LLQ can be configured on a Cisco router to support voice and data traffic on a heterogeneous network.
Configuring LLQ for Frame Relay
The LLQ for Frame Relay feature is available in Cisco IOS Release 12.1(2)T or later and is supported on c805, c1600, c1700, c2500, c2600, c3600, c3810, and c7200 series routers. The latest Cisco IOS release might support the LLQ for Frame Relay feature on the newer Cisco router platforms, such as c2600-XM, c3700, and c7600.
The Cisco MQC interface CLI is used to configure LLQ for Frame Relay. To configure LLQ for Frame Relay, the queues are set up on a per-PVC basis. Each VC has a PQ and an assigned number of fair queues. In a manner identical to CBWFQ, LLQ for Frame Relay is configured with a combination of class-map, policy-map, and Frame Relay map-class commands. Traffic classes are set up with the class-map command to classify the traffic. The user determines how the traffic is classified based on protocols, source interfaces, or access lists. Then the policy-map command is used to create a traffic policy whereby the user can configure how each class of traffic is treated in the queuing system. The policies can be based on priority (PQ), bandwidth, queue limit, or WRED. Finally, the policy-map is attached to a Frame Relay VC using the service-policy output command in the Frame Relay map class. The map class is, in turn, assigned to the Frame Relay DLCI.
If you skipped the earlier sections on MQC interface CLI or CBWFQ, reading those sections to become familiarized with the configuration tasks for MQC or CBWFQ is recommended. Otherwise, Figure 18-5 shows the topology of the network that is used to illustrate LLQ for Frame Relay.
Figure 18-5. Network Diagram to Illustrate LLQ for Frame Relay
Figure 18-5 illustrates the scenario of a small firm that has a central office connected to several branch offices across a nationwide Frame Relay network. The firm wishes to leverage on VoIP and multicast to support desktop video conferencing applications on its network. To optimize the application performance for the real-time traffic on the network, the firm needs to manage the network performance with respect to bandwidth, delay, jitters, and packet loss. In addition, the firm needs to service the needs of other applications running over the WAN. Hence, the firm decides to implement LLQ on its Frame Relay network. A strict priority queue is created to minimize delay for the real-time delay-sensitive traffic. LLQ polices the real-time traffic in the strict priority queue and ensures that other nonpriority traffic on the network, such as SNA and sales data transfers, is not starved of bandwidth.
NOTE
The network implementer advised the firm against using oversubscription, because it usually leads to packet discards and might result in poor voice/video quality.
The network in Figure 18-5 is set up, and the configurations of the routers are shown in Example 18-9. Notice that only the configurations of routers R1 and R2 are shown in Example 18-9, because the configurations for R3 or R4 are very similar to those of R2.
Example 18-9. Configurations of the Routers in Figure 18-5
! Router R1:
<output omitted>
class-map match-all SALES_DATA
match access-group 103
class-map match-any SNA_DATA
match protocol dlsw
match access-group 102
class-map match-all VIDEO
match access-group 101
!
!
policy-map LLQ
class VIDEO
priority 64
class SNA_DATA
bandwidth 32
queue-limit 100
class SALES_DATA
bandwidth 16
class class-default
fair-queue
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
!
interface Serial4/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial4/0.102 point-to-point
ip address 172.16.1.1 255.255.255.252
frame-relay interface-dlci 102
class LLQ_class
!
interface Serial4/0.103 point-to-point
ip address 172.16.1.5 255.255.255.252
frame-relay interface-dlci 103
class LLQ_class
!
interface Serial4/0.104 point-to-point
ip address 172.16.1.9 255.255.255.252
frame-relay interface-dlci 104
class LLQ_class
!
!
map-class frame-relay LLQ_class
frame-relay cir 128000
frame-relay mincir 128000
no frame-relay adaptive-shaping
service-policy output LLQ
!
ip route 20.0.0.0 255.255.255.0 172.16.1.2
ip route 30.0.0.0 255.255.255.0 172.16.1.6
ip route 40.0.0.0 255.255.255.0 172.16.1.10
!
access-list 101 permit udp any any eq 12000
access-list 102 permit tcp any eq 2065 any
access-list 102 permit tcp any any eq 2065
access-list 103 permit tcp host 10.0.0.2 any eq 10000
________________________________________________________________
! Router R2:
<output omitted>
class-map match-all SALES_DATA
match access-group 103
class-map match-any SNA_DATA
match protocol dlsw
match access-group 102
class-map match-all VIDEO
match access-group 101
!
!
policy-map LLQ
class VIDEO
priority 64
class SNA_DATA
bandwidth 32
queue-limit 100
class SALES_DATA
bandwidth 16
class class-default
fair-queue
!
interface FastEthernet0/0
ip address 20.0.0.1 255.255.255.0
!
interface Serial2/1
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial2/1.201 point-to-point
ip address 172.16.1.2 255.255.255.252
frame-relay interface-dlci 201
class LLQ_class
!
map-class frame-relay LLQ_class
frame-relay cir 128000
frame-relay mincir 128000
no frame-relay adaptive-shaping
service-policy output LLQ
!
ip route 10.0.0.0 255.255.255.0 172.16.1.1
ip route 30.0.0.0 255.255.255.0 172.16.1.1
ip route 40.0.0.0 255.255.255.0 172.16.1.1
!
access-list 101 permit udp any any eq 12000
access-list 102 permit tcp any eq 2065 any
access-list 102 permit tcp any any eq 2065
access-list 103 permit tcp host 20.0.0.2 any eq 10000
In the network diagram in Figure 18-5, each remote site has a Frame Relay VC with a minimum access speed of 128 kbps terminating into the central location. To prevent oversubscription, Frame Relay Traffic Shaping is enabled, and the routers are allowed to burst only up to the CIR rate. Hence, both the minimum CIR and the CIR are set to 128 kbps in Example 18-9.
Although bursting over Frame Relay can be attractive for data networks, it might not be desirable on integrated voice and data networks because voice packets might be dropped. A discarded voice packet can result in retransmission and cause jitter and result in poor voice quality. This can also cause slow response to the user desktop application.
The various traffic classes are defined with the class-map commands. The traffic is classified to the class-map by means of protocol types, input interfaces, or access lists. For instance, in Example 18-9, the traffic destined for the priority queue is classified with an extended access list 101 that matches UDP traffic with port number 12000. Then the CBWFQ scheme is used to serve both the SNA and sales data traffic on the network. All the remaining traffic not matched by the priority class map or the CBWFQ class maps are sent to the default class.
A policy-map named LLQ is configured to define how each identified class of traffic is handled in the traffic policy. A priority queue with a bandwidth of 64 kbps is used to service desktop video conferencing traffic running on UDP port 12000. The SNA and sales data are assigned a bandwidth of 32 kbps and 16 kbps, respectively. Traffic in the default class is serviced based on best-effort delivery using a flow-based fair queuing scheme.
The next section verifies the workings of the LLQ system by observing the outputs of the various show commands.
