QoS Service Design – MPLS

Introduction

The MPLS VPN service provided by MASS Communications supports the use of Quality of Service (QoS) to manage the business critical traffic flowing within a customer’s network. This is especially important in today’s multi-function networks with voice/video, critical business application, and general network access data sharing the same transmission media.

The design decisions for the QoS service focus on two key QoS functions—

  • Classification/Marking
  • Low-Latency Queuing

Once the design decisions have been made, the account team will provide VPN Engineering with the specifics of how traffic is to be classified and which QoS Policy is to be applied. The QoS Policy specifies how much bandwidth will be reserved for each class of traffic.

QoS

 

Classification/Marking

Classification involves the inspection of information contained in the packet header to identify the “class” of traffic that the packet belongs to. The information inspected could be the source/ destination IP address or subnet, source/destination port, a combination of these, or simply the Differentiated Service Code Point (DSCP) value that has been set previously. Once the class has been identified, marking is performed by setting the DSCP value in the packet header with the value that is associated with that class.

Classification/Marking is generally performed on the MPLS VPN router on the customer’s premises (also known as CPE). This distributes the overhead due to packet inspection to the CPE router. Alternatively, if devices within the customer’s network set DSCP values appropriate for the services they provide, and these DSCP values match the DSCP values supported by the QoS service, no re-marking is necessary. However, the trusting of devices to set appropriate DSCP values should be used with caution. This could be misused by some devices to gain preferential service.

Once the packet has been marked, a simpler method of classification can be performed on other routers such as the routers within the MASS Communications network. These routers can trust

the DSCP value and apply the bandwidth policy without the need for deeper inspection of the packet.

The QoS service offers two methods of classifying traffic—

  • IP Header Inspection­—Values in the packet’s IP header are inspected to identify the packets that are to be associated with one of the standard classes—EF (46), AF41 (34), or AF21 (18). Any packets that do not match one of the specified classes are placed into the “default” class and marked with a DSCP value of BE (0).
  • Trusted DSCP Value—DSCP values are placed into the packet’s IP header by devices needing preferential service (e.g., IP phones or voice-capable PBX) or other network infrastructure devices within the customer’s network (e.g., switches or routers).

 

When designing your QoS implementation, you should specify the matching criterion that will be used to identify the packets that belong to the classes within the QoS Policy. You will be able to select one of the Source options, one of the Destination options, or one each of the Source and Destination options from the following table for each class. You will also need to specify the values that are to be matched. If you select both Source and a Destination criterion, both values must be present in the packet for a match to occur.

QoS Source

 

Low-Latency Queuing

Once the packet has been classified, it can be placed into the Low-Latency Queuing (LLQ) queue that is associated with the packet’s class. This queuing only needs to be done when there is congestion on the outgoing interface. If there is no congestion, the packet is placed directly into the outgoing interface’s Transmit (TX) Ring/Queue.

Low-Latency Queuing (LLQ)[1] uses three levels of queuing, based upon the class associated with the DSCP value contained in the packet header—

  • Low-Latency Queue (LLQ)—Also referred to as the Priority Queue (PQ). Used for Expedited Forwarding (EF) traffic. Voice or other delay sensitive packets are placed into this queue.
  • Class-Based Weighted Fair Queue (CBWFQ)—Used for Assured Forwarding (AF) traffic. VoIP control packets, video conferencing, packets from critical business applications, or any other packets that are to receive a guaranteed bandwidth are placed into one of these queues based upon the packet’s classification.
  • Default—Used for Best Effort (BE) traffic. Flow-based Weighted Fair Queuing (WFQ) is used for all other packets that are not identified by explicit classification.

 

Packets in the LLQ queue are serviced before any packets in the other queues. Thus, delay and jitter sensitive traffic can be serviced without having to wait for the transmission of other traffic. The bandwidth usage of the LLQ queue is limited, through the use of policing, to a specified percent of the circuit’s total bandwidth. Any traffic in excess of this percentage is dropped. This ensures that the LLQ queue will not starve the other queues completely.

A bandwidth is specified for the critical application CBWFQ queues. The bandwidth is in terms of a percent of the circuit’s total bandwidth. These critical application queues are assured of receiving at least this minimum amount of bandwidth.

Note that there is no implied prioritization between the critical application queues. Each critical application queue is ensured its minimum bandwidth when congestion occurs. The relative bandwidth implies a “weight” for servicing data within these queues relative to each other.

Should the LLQ queue or one of the critical application queues not fully use their bandwidth, the excess bandwidth is available for other critical application queues or the default queue. This allows the default queue to service whatever bandwidth that isn’t used by the LLQ queue or critical application queues. The packets that would be placed into the default queue would be Internet traffic and other application traffic that has not been classified as “business critical”.

The QoS service offers two tiers of prioritization and bandwidth allocation—

  • Two Queues plus Default—Provides a LLQ queue for delay and jitter sensitive data (identified by DSCP value EF), and one CBWFQ queue for critical application data (identified by DSCP value AF41).
  • Three Queues plus Default—Provides a LLQ queue for delay and jitter sensitive data (identified by DSCP value EF), and two CBWFQ queues for critical application data (identified by DSCP value AF41 and AF21).

 

When designing your QoS implementation, you should select one of the standard QoS Policies as shown in the table below. Keep in mind that a different QoS Policy may be applied for each site within the customer’s network. This allows for different critical application bandwidth usage on a site-by-site basis. If no QoS Policy is specified, 75_24 will be applied by default.

QoS Policy


[1] For a more complete, technical description of LLQ, refer to the Cisco document Low Latency Queueing, available at:  http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/pqcbwfq.pdf

 

Comments are closed.

Telecommunications | Voice | Data | Networking | Support