SprintLink Customer Guidelines for Use of IP Class Of Service
Sprint has developed Class of Service guidelines and recommendations for providing Class of Service on dedicated IP and CPE-based IP VPN networks. These are guidelines and recommendations only. As each customer's requirements will vary, Sprint cannot guarantee that the recommendations will be optimal or applicable to a particular's customer's requirements. Sprint can assist customers with Class of Service policies as a managed service or professional service. Please contact your account team for more information on these services. For more information on router configurations, please visit Cisco's website at www.cisco.com.
Sprint makes no representations or warranties regarding the below information, or with regard to these guidelines, and Sprint will not be responsible for any claims, damage, loss or harm, including consequential damages, caused to an entity's equipment or services based on the use of information provided on this website.
IP Class Of Service Overview
The IP Class Of Service (CoS) product consists of allowing SprintLink Dedicated IP and CPE-based IP VPN customers the ability to prioritize the queuing treatment of their application traffic during periods of congestion on both the egress port of their Cisco enterprise CPE router and the egress port of the SprintLink Gateway router they are homed to.
SprintLink IP CoS customers will have the capability to prioritize their traffic into 4 separate classes.Three of those classes will be user-defined classes while the 4th class will be an implied class-default. Traffic not destined for one of the configured classes is sent to the class-default class, which will not appear in IOS show running configuration commands. The only instance in which it would appear would be if an explicit bandwidth argument was configured for it or one explicitly configures a class-default queue.
The only exception to the flexibility of configuring the 3 user-defined queues is that a queue configured as a Low Latency Queue (LLQ) via the Priority command can accept either packetized voice or video as the application type. Sprint will provide SprintLink customers an overall recommendation concerning bandwidth allocation percentages to the 4 IP CoS queues, however, the customer will have the flexibility to change such allocations to their desired need.
The IP Class Of Service product involves Cisco IOS configurations utilizing only Access Control Lists (ACLs) for Non-IP VPN customers. For IP VPN customers, a combination of ACLs and the 3-Bit IP Precedence field found within the Type Of Service (ToS) byte of the IP header are the classification mechanisms used to place specific application traffic types into their proper queues. Low-Latency Queuing and Class-Based Weighted Fair Queuing will be the queue management techniques utilized on the outbound CPE and Access Router interfaces.
Sprint will accept IP Class Of Service requests from SprintLink Dedicated IP customers whose Cisco enterprise customer premise equipment (CPE) router is provisioned via T-1-based access links to a SprintLink Cisco 7507 or 7513 Gateway Router equipped with, at a minimum, a 2nd Generation R5000 Versatile Interface Processor (VIP2-50) with a minimum of 128MB of main memory (SDRAM) and 4MB of Static RAM (SRAM).
Customer Guidelines for Configuration of IP CoS Access Lists and IP Precedence
Utilizing carefully configured Access Control List statements and/or the 3-Bit IP Precedence field found in the IP Type Of Service byte, the router determines the order of packet transmission by controlling which packets are placed in which queue and how queues are serviced with respect to each other.
In order for the router to be able to filter outbound traffic based on application type for destination to its proper outbound interface queue (e.g. http, telnet, smtp), the customer will need to configure an Extended ACL. It is the customers discretion on whether to utilize a numbered or named access control list.
The general format of an extended IP access list is shown here:

Access-list[list number][permit|deny][protocol keyword][source address source-wildcard][source port][destination address][destination-wildcard][destination port][log][options]

Numbered extended access lists utilize the numbers 100-199

For more detailed information on Extended Access Control Lists, please refer to the following Cisco Connection Online (CCO) web page:

http://www.cisco.com/en/US/docs/ios/12_0/np1/command/reference/1rip.html

Extended ACL Configuration for Non-IP VPN SprintLink Customers with and without Packetized Voice
The following configuration example shows extended access-list numbers 101,102 and 103 permitting the transport protocol of TCP originating from any source to any destination prefix AND carrying email traffic (smtp), web (www) traffic and ftp traffic as its application types respectively. It should be noted that specific network or host prefixes may replace the "any" keywords for more source and destination granularity.
Without Packetized Voice Extended ACL Example
Configuration Example: Router(config)# access-list 101 permit tcp any any eq smtp
Router(config)# access-list 102 permit tcp any any eq www
Router(config)# access-list 103 permit tcp any any eq ftp
With Packetized Voice Extended ACL Example
The following configuration example shows extended access-list numbers 101,102 and 103 permitting the transport protocols of UDP and TCP originating from any source to any destination prefix AND carrying Voice Over IP (UDP port range), email traffic (smtp) and web (www) traffic as its application types respectively.
Configuration Example:
Router(config)# access-list 101 permit udp any any eq 16384 
32768 (range of udp ports for packetized voice traffic streams)
Router(config)# access-list 102 permit tcp any any eq smtp
Router(config)# access-list 103 permit tcp any any eq www
VPN Traffic with ClearText Traffic Extended ACL Example
The following configuration example shows access-list numbers 101,102, 103 and 104 permitting the transport protocol of TCP originating from any source to any destination prefix AND carrying email traffic (smtp) and web (www) traffic as well as the protocol ESP (IPSec) as the application types respectively
Configuration Example:
Router(config)# access-list 101 permit tcp any any eq telnet
Router(config)# access-list 102 permit tcp any any eq smtp
Router(config)# access-list 103 permit tcp any any eq www
Router(config)# access-list 104 permit esp any any
VPN Traffic with Use of 3-Bit IP Precedence Field AND Extended ACL Example
The following configuration example shows access-list numbers 101,102 and 103 permitting the encrypted application traffic types (Telnet, Email and FTP) via their IPv4 3-bit IP Precedence numbers (set by the customer VPN device) AND ESP application designation originating from any source to any destination prefix respectively.
Configuration Example:
Router(config)# access-list 101 permit esp any any precedence 5 (critical)
(e.g. - carrying encrypted telnet traffic)
Router(config)# access-list 102 permit esp any any precedence 4 (flash-override)
(e.g. -encrypted smtp)

Router(config)# access-list 103 permit esp any any precedence 3 (flash)
(e.g. encrypted ftp data)
Customer Guidelines for Configuration of IP CoS Definition of Traffic Classes
The definition of traffic classes entails the creation of queues, assignment of packets to those queues based on the classification of the packet (ACLs and/or IP Precedence bits) and scheduling of the packets in a queue for transmission. SprintLinks IP Class Of Service product supports Low Latency Queueing (LLQ) and Class-Based Weighted Fair Queueing (CBWFQ) as the queueing strategies to be utilized on the desired outbound interface(s). CBWFQ provides support for user-defined traffic classes. SprintLink customers will define their traffic classes based on "match criteria", which in this case involves extended IP ACLs and IP Precedence bit settings. Packets satisfying the match criteria for a class constitute the traffic for that class. Once a class has been defined according to its match criteria, the customer can assign the class "characteristics", which in this case will be bandwidth. The bandwidth assigned to a class is the guaranteed bandwidth delivered to the class during congestion. During periods of non-congestion, all packets are sent out the interface as soon as they arrive. Low-Latency Queueing, configured by the priority command, enables use of a single strict priority queue within CBWFQ at the class level. LLQ allows jitter and delay-sensitive traffic such as voice or video to be dequeued and sent before packets in other queues are dequeued. With the priority command, the customer is specifying the "maximum" amount of bandwidth allocated for packets belonging to the LLQ configured class.

IMPORTANT: The sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth. The remaining 25 percent is used for other overhead, including Layer 2 overhead, routing traffic and best-effort traffic.

Also, an overloaded service class will always yield poor service outcomes. So the customer is advised not to consistently go beyond the bandwidth allocations theyve setup within their service class definitions (e.g.: an overloaded LLQ priority queue for Voice Over IP traffic will yield either poor voice quality or an inability to set new calls up).

Example Traffic Class Configuration for Non-IP VPN SprintLink Customers

The configuration example below creates 3 traffic classes called Platinum, Gold and Silver along with the implied class-default class. The class-map command is used to create a traffic class. Also, the match access-group command in class-map configuration mode specifies the numbered access list against whose contents packets are checked to determine if they belong to the class. In addition, weve created the IPCOS service policy and assigns the Platinum and Gold classes we configured to that service policy along with defining the allocated bandwidth in kbps for each class.

The policy-map global configuration command specifies the traffic policy name and configures a traffic policy. The traffic class is associated with the traffic policy by use of the class command. The class command must be issued immediately after entering policy-map configuration mode. Also, the bandwidth command is used to specify the bandwidth allocated for a class belonging to a policy map. The allocated bandwidth can be specified in Kbps or use of the percent operator to specify a "percentage" of bandwidth.

Configuration Example:

Router(config)# class-map Platinum
Router(config-cmap)# match access-group 101
Router(config-cmap)# exit
Router(config)# class-map Gold
Router(config-cmap)# match access-group 102
Router(config)# exit
Router(config)# class-map Silver
Router(config-cmap)# match access-group 102
Router(config)# exit

Configuration Example:

Router(config)# policy-map IPCOS
Router(config-pmap)# class Platinum
Router(config-pmap-c)# bandwidth percent 33
Router(config-pmap)# exit
Router(config)# policy-map IPCOS
Router(config-pmap)# class Gold
Router(config-pmap-c)# bandwidth percent 25
Router(config-pmap)# exit
Router(config)# policy-map IPCOS
Router(config-pmap)# class Gold
Router(config-pmap-c)# bandwidth percent 15
Router(config-pmap)# exit Finally, use of the service-policy interface configuration command attaches the traffic policy to your specified interface also specifying the "direction" in which the policy should be applied (either on packets coming into the interface or packets leaving the interface). For the purposes of our IP Class Of Service product, service policies will be applied on the "outbound" of the customer CPE WAN interface as well as the "outbound" (towards the customer) of the gateway router interface they are homed to.

Configuration Example:

Router(config)# interface s0/0
Router(config-if)# service-policy output IPCOS
Router(config)# exit

Class Based Weighted Fair Queuing (CBWFQ) Usage Guidelines

CBWFQ Weighting: For CBWFQ, the weight specified for a particular class becomes the weight of each packet that meets the match criteria of the class. Packets that arrive at the output interface are classified according to the match criteria filters (ACLs with application port numbers/names and IP Precedence bits in our situation) that have been defined, then each one is assigned the appropriate weight. The weight for a packet belonging to a specific class is derived from the bandwidth you assigned to the class when you configured it. After the weight for a packet is assigned, the packet is enqueued in the appropriate class queue. CBWFQ uses the weights assigned to the queued packets to ensure that the class queue is serviced fairly. CBWFQ Bandwidth Allocation: The sum of all bandwidth allocation on an interface cannot exceed 75 percent of the total available interface bandwidth (e.g. 75% of 1.536Mbps T-1 equals 1.152Mbps available to configured classes). The remaining 25 percent is used for other overhead such as best effort traffic, control traffic and layer 2 overhead. Bandwidth for the CBWFQ "class-default" class, for instance, is taken from the remaining 25 percent. However, under "aggressive" circumstances, this rule can be overridden by use of the max-reserved-bandwidth command. Extreme caution is recommended when using this command in ensuring one leaves enough remaining bandwidth to support best effort, control and layer 2 overhead traffic.   CBWFQ and its Bandwidth Command: Its important to know that the bandwidth command defines a "behavior" which provides a minimum bandwidth guarantee during congestion. The 3 forms of the command syntax are as follows:

bandwidth (kbps) specifies bandwidth allocation as a bit rate

bandwidth percent (value) specifies bandwidth allocation as a percentage of the underlying link rate.

bandwidth remaining percent (value) specifies bandwidth allocation as a percentage of the bandwidth that has not been allocated to other classes.

Low Latency Queuing Usage (LLQ) Guidelines

LLQ Weighting: The weighting of the strict priority queue of LLQ is accomplished similar to that specified for CBWFQ. When specifying its weight, the bandwidth command normally used by CBWFQ is replaced by the priority command and then the bandwidth value in either kbps or a percentage of link bandwidth.

LLQ Bandwidth Allocation: When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kbps. You use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. 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 configured bandwidth is exceeded. When congestion occurs, traffic destined for the priority queue is metered to ensure that the bandwidth allocation configured for the class to which the traffic belongs is not exceeded.

Priority traffic metering is only performed under congestion conditions. When the device is not congested, the priority class traffic is allowed to exceed its allocated bandwidth. Priority traffic metering is performed on a per packet basis. It restrains priority traffic to its allocated bandwidth to ensure that non-priority traffic, such as routing packets and other data, is not starved.

The bandwidth allocated to a priority queue always includes the Layer 2 encapsulation header.

Also, the 75%/25% bandwidth rule also applies to the LLQ queuing technique.

LLQ and its Priority Command: During congestion conditions, the priority traffic class is guaranteed bandwidth equal to the specified rate. (Recall that bandwidth guarantees are only an issue when an interface is congested.) In other words, the priority command provides a minimum bandwidth guarantee.

The priority command can allocate bandwidth utilizing either a bandwidth argument which gives the maximum bandwidth in kbps or specification of a percentage of available bandwidth to be reserved for the priority queue.

In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested.

The purpose of the built-in policer is to ensure that the other queues are serviced by the queuing scheduler. The priority command provides a strict de-queuing priority to provide a bound on latency. Strict De-queuing refers to the queuing scheduler servicing the priority queue and forwarding its packets to the interface hardware transmit ring first. The transmit ring is the last stop before the physical media.

IP Class Of Service Recommendations On Bandwidth Allocations

The following are "recommendations" concerning bandwidth allocations for a 3 or 4 class defined IP Class Of Service scenario.

Packetized Voice: Per T-1 access link, either a bandwidth argument of 510 (kbps) or a percentage allocation of 33% going to the priority defined class (e.g. Platinum).

Packetized Voice Control Traffic (H.323 or SIP-based): This would consist of such things as call setup, management and teardown signaling traffic. Recommend assigning this traffic type to the highest weighted CBWFQ queue (e.g. Gold) of which it should have either 31 kbps or 2% of the available link bandwidth.

Customer Defined Mission Critical Data Traffic (e.g. Email): This could rest in the same CBWFQ as the packetized voice control traffic for a VoIP customer or its own defined queue. The recommendation is either a bandwidth argument of 386 (kbps) or a percentage allocation of 25% (Gold queue traffic).

Customer Defined Less Than Mission Critical Data Traffic (e.g. Bulk FTP-Data): This could represent a customers Silver defined class. The recommendation is either a bandwidth argument of 232 (kbps) or a percentage allocation of 15%.

Customer Defined "Best-Effort" Data Traffic (e.g. RealAudio/Video, Layer 2 Overhead, all other data not falling into one of the user defined classes): This class could be considered the customers Bronze class and represents the class-default class either implicitly or explicitly defined. The recommendation for this queue follows the 75%/25% rule so this "could" have a bandwidth argument of 386 (kbps) or a percentage allocation of 25%.

More comprehensive technical information on the aforementioned IP Class Of Service implementation details can be found on Cisco's website:

Cisco - Quality of Service