| |
|
|
This chapter describes quality of service configuration on the Avici router.
Quality of Service (QoS) is a metric that defines the treatment of data as it is carried through the internet. Service providers, that do not support QoS, treat all internet data equally; no special treatment of data is possible except by network partitioning on their network. This equality of delivery was sufficient for services required by the early internet; it was enough to provide a commercial grade of service throughout. Any attempts at QoS within commercial grade networks were limited to end-to-end protocols such as RSVP and Streams-II, which would still require router support of classification, queueing and RSVP message processing. Though these end-to-end protocols provide additional functionality within a network, they have no impact upon aggregate flows across the internet. QoS over end-to-end flows across the entire internet represents both an unsolvable scaling problem and an additional operational cost associated with managing QoS for each end-to-end flow. For these reasons, such end-to-end protocols represent additional commercial grade service within a single network and not the implementation of an internet wide QoS metric.
Commercial grade service required properties such as robust communications hardware, successful dial-up connection services, reliable connection uptime, and equal treatment of data. With the rise of time sensitive applications such as teleconferencing, voice over IP, and virtual private networks, the need to provide guaranteed bandwidth to some applications and best effort bandwidth to others requires that bandwidth be allocated by type of service or class across the entire internet as opposed to solely within an individual provider's network. The QoS metric, using the differentiated services (DiffServ) protocol, is the industry's effort to meet this need to move from equal treatment of data to data treatment across the entire internet by aggregate grouping or class.
QoS addresses this need for treatment of aggregate internet data flows by summarizing traffic into classes throughout the network, allowing for the direction of traffic without the overhead of managing end-to-end flows.
Introduction
Avici implements QoS via interface hardware allowing QoS services at line rates without any degradation of routing performance. The Avici router supports output queuing for both IP and MPLS packets.
Output queuing support for IP packets is based on the DSCP bits of the IPv4 Differentiated Services field as defined in RFC 2474. Refer to Figure 4-1 for a graphic representation of the field.
Figure 4-1. IP Type of Service Field
Output queuing support for MPLS packets is based upon the EXP bits of the MPLS shim header as defined in RFC 3032. Refer to Figure 4-2 for a graphic representation of the EXP field within a generic MPLS header.
Figure 4-2. MPLS Header
The IPriori implementation derives traffic classes from either the six-bit DSCP field for IP packets or the three-bit EXP field for MPLS packets, and maps these classes to Per-hop behavior Scheduling Classes (PSC) for internal treatment as the packet crosses the fabric. The DSCP field allows for up to 64 different values from 0 - 63. The EXP field allows for eight values from 0 - 7.
IPriori supports QoS Marking. QoS marking is the capacity to determine a packet's internal treatment and exiting DSCP value (for IP packets) or EXP value (for MPLS packets), based upon the entering interface and initial DSCP value. The internal QoS treatment of a packet as it traverses the fabric is based upon a DSCP or EXP mapping that is configurable both globally and at the interface. This mapping associates an incoming DSCP or EXP value with a PSC. The PSC determines how the packet is treated as it crosses the fabric. A mapping configured in interface mode supersedes the global mapping. IPriori supports up to four DSCP/EXP to PSC mappings. The DSCP to PSC mapping supports the listing of IANA dscp-registry and IP Precedence including: Class Selector (CS), Assured Forwarding (AF), Expedited Forwarding (EF), IP Precedence (PREC), as well as numbers from 0 - 63.
How a packet is marked upon exiting the router is determined by a user configurable QoS mapping. The QoS mapping is configured on a global basis only. This mapping associates a PSC with an exiting DSCP or EXP value. IPriori supports up to four PSC to DSCP/EXP mappings. Once IPriori determines a packet's exiting DSCP or EXP value, the packet is internally treated as that QoS type for purposes of fabric prioritization, random early detect dropping, and packet queueing. QoS mapping may be disabled. When QoS mapping is disabled, the packet exits the router with the same DSCP or EXP values with which it entered the router providing there is no change in header type e.g. LDP to MPLS.
IPriori associates a drop preference with the internal treatment of the packet at the point of DSCP or EXP mapping. The drop preference is either green or red and maps to the standard assured forwarding AFx1 or AFx2/3 loss probabilities as defined in RFC2597. IPriori provides for the user configuration of up to two RED drop probabilities using the max-mark-spacing and red-max-mark-spacing options.
IPriori associates a configurable fabric priority with the internal treatment of the packet at the point of DSCP or EXP mapping. For queueing purposes, the router fabric recognizes four levels of priority, three of which are user configurable: best-effort, priority, and regulated. The control fabric priority is reserved for internal messaging only and is not user configurable. The best-effort and priority treatments are forwarded through low priority queues. The regulated and control treatments are forwarded through high priority queues.
For each interface you can configure up to eight output queues for QoS traffic assignment. A Traffic assignment assigns physical resources in accordance with a configured packet treatment and has an IP and/or MPLS PSC associated with it. A traffic assignment can be configured for IP and/or MPLS packets. There are three parts to the QoS traffic assignment implementation:
- The allocation of hardware resources through a traffic assignment
- The configuration of the traffic assignment according to a packet treatment
- The direction of traffic into that physical traffic assignment using packet classification.
Refer to Figure 4-3 for a block diagram of the QoS traffic assignment.
Figure 4-3. Traffic Assignment Block Diagram
Packet treatments are a means of grouping packet related parameter sets. This release supports two sets of packet treatment parameters: queue and Random Early Detect (RED).
There are three parameters associated with queue configuration: bandwidth, queue depth and an option to assign absolute-priority to this queue. You configure queues for bandwidth by specifying the queue bandwidth in terms of either absolute value or a percentage of link bandwidth. You configure queues for queue depth by specifying the amount of packet buffering for the queue in terms of either absolute size or the maximum time it will be allowed to reside in the queue. In either case you are determining the total packet bits that can be buffered in the queues before incoming packet drop begins. You can configure a single traffic assignment per interface with a low latency absolute-priority that functions similar to the EF class defined under the DiffServ specification. Unlike the EF class, there is no upward bounding of the amount of traffic which can flow through the absolute-priority queue and therefore is subject to packet drop under extreme conditions. Any packets in a queue configured for absolute-priority will be transmitted before any packet from any other queue.
Random Early Detect (RED) is a congestion avoidance mechanism that detects the onset of congestion by estimating an average observable queue size relative to minimum and maximum queue thresholds. You specify a drop probability relative to the maximum threshold. RED takes advantage of TCP's ability to cut back on transmission rates at the source as a reaction to REDs dropping of packets. Weighted Random Early Detect (WRED) combines DSCP and MPLS EXP with RED to assure that the higher the packet priority, as specified by the IP or MPLS class value, the higher the probability of packet delivery.
Traffic class is based on DSCP or MPLS EXP depending upon whether the packet is an IP packet or MPLS packet, respectively. At initial system startup, traffic classes for both DSCP and MPLS EXP are assigned to one of two traffic assignments: DSCP values 0 - 47 or EXP values 0 - 5 are mapped to PSC 0 - 2 and assigned to traffic assignment default. DSCP values 48 - 63 and EXP values 6 - 7 are mapped to PSC 3 and assigned to traffic assignment control. The default traffic assignment provides equal best effort system resources for the first three PSCs. The control traffic assignment provides a proportionately higher level of system resources to both traffic internal to the Avici router and to traffic marked with regulated priority DSCP or MPLS EXP values. Both sets of regulated values get mapped to PSC 3. All legitimate DSCP values are mapped in accordance with a default mapping to one of these two traffic assignments. If you do not wish to further modify QoS for your network, these default levels will assure that the minimum level of QoS required for proper operation of the Avici router is maintained.
When configuring the Avici router for QoS, you first define, at the global configuration level, traffic classes and/or classifiers, the queue and RED parameter sets, and packet treatments. These traffic class, parameter set and packet treatment configurations do not have actual resources assigned to them until a traffic assignment is configured using the qos command. You configure traffic assignments at the interface level. At this time physical resources in accordance with configured packet treatments are associated with traffic classes to form a traffic assignment. There are sixty-four DSCP and eight EXP traffic classes that can be mapped to up to eight PSCs: four DSCP PSCs and four EXP PSCs. These PSCs can be assigned over a maximum of eight unique traffic assignments per interface. You can assign as many traffic classes to a single traffic assignment as you wish; you can not assign any given traffic class to multiple traffic assignments.
Refer to Figure 4-4 for a presentation of QoS from the perspective of the router module.
Figure 4-4. Quality of Service on the Router Module
The following sections provide QoS configuration details. Each section will concentrate on the details associated with a single aspect of QoS. In "Stepping Through A Configuration Example" on page 111 you will be stepped through a complete global and interface configuration.
Understanding Parameter Modification Vs. Replacement
You configure QoS parameters not yet associated with physical resources at the global configuration command mode and parameters associated with actual physical resources in interface configuration command mode. Whether the CLI modifies the specified parameters and leaves unspecified parameters alone, or completely replaces a set of parameters, depends upon the command mode.
In global configuration command mode you assign values to named global parameters that are not yet associated with any actual resources. Global configuration mode parameter sets are: queue parameters, RED parameters, packet treatments, and classifiers. For these parameter sets the CLI operates in modification mode. In CLI modification mode, if there are multiple parameters associated with a command and you enter less than a complete set of possible parameters, IPriori only modifies the specific parameters provided on the command line; all other parameters remain unchanged whether they be default or previously defined using a different command line entry.
In interface configuration command mode IPriori associates physical resources with configured parameters. You configure traffic assignment parameter sets in interface configuration command mode. For traffic assignments the CLI operates in replacement mode. In replacement mode IPriori replaces all pre-existing values with specified values for any parameters explicitly entered and current default values for any unspecified parameters.
Example: For example, you configure queue parameters in global configuration command mode and the CLI operates in modification mode. Let's say the current configuration of queue parameter set q1 assigns:
Bandwidth Queue-depth 60%
40ms
You enter the following command:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#queue q1 bandwidth 70%
The configuration of queue parameter set q1 would change to:
Bandwidth Queue-depth 70%
40ms
Bandwidth now reflects the new value of 70% but queue-depth remains unchanged.
You configure traffic assignments in interface configuration mode and the CLI operates in replacement mode. In the following example a traffic assignment qos1 is configured as follows
:
Classifier Random Detect Parameter set Queue Parameter set c1
rd1
q1: w/
bandwidth=70%
queue-depth=40ms
You enter the following command:
:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#interface pos 1/2/3
router(config-if)#qos qos1 classifier c1 random-detect-parameters rd1 bandwidth 60%
The configuration of traffic assignment qos1 would change to:
Classifier Random Detect Parameter set Bandwidth Queue-depth c1
rd1
60%
10ms
Replacement mode requires that in order for the classifier and random detect parameter set to remain unchanged that they be entered on the command line, otherwise they would have been replaced by the classifier and random detect default values. q1 is no longer associated with qos1. Bandwidth has the configured value of 60% and because queue depth was not explicitly configured, the 40ms value associated with q1 is replaced by the default value of 10ms.
Configuring Queue Parameters
Weighted Fair Queuing (WFQ) provide greater resources for higher priority traffic without starving low-priority packet bandwidth. This is accomplished by assigning a weight to each queue that can be scheduled. When the interface is fully utilized, each queue receives bandwidth as a percentage of its weight relative to the sum of weights for all other queues. You can configure one WFQ group of queues per SONET interface. You can configure up to eight unique queue treatments per WFQ group. A queue treatment can be associated with any combination of the four possible PSCs for IP traffic and four possible PSCs for MPLS traffic. No single traffic class can be mapped to multiple PSCs and no single PSC can be associated with multiple queue treatments.
There are two aspects to configuring queues: how much of a link's bandwidth to associate with the queue and how much data can be buffered before incoming packets are dropped. Given the worst case bandwidth a queue will receive, the queue buffer size can be calculated from a specified worst case queue waiting time. Bandwidth can be expressed in absolute terms or as a weight. Weight is bandwidth associated with a queue expressed as a percentage. Queue depth is the maximum time a packet could reside in a queue, before incoming packets are dropped. Once a packet is in a queue it will not be dropped. You can not over allocate either of these parameters. You configure these two parameters at the global configuration level by configuring named parameter sets. Parameter sets can be applied to any interface, therefore no specific resources are associated with a queue configuration. You assign actual physical resources when configuring a QoS traffic assignment using the qos command, which includes queue parameters in its packet treatment field.
Refer to Figure 4-5 for a visual presentation of a link configured with three queue parameter sets representing traffic classes: priority, control and default. The left side of the figure contains three boxes containing the configured values; the right side shows a visual presentation of the reserved bandwidth and queue depth for these classes. The longer the configured time in queue the longer a congested period can be tolerated without dropping packets.
In this example the priority queue gets configured for a short time in queue relative to the default queue because of the time sensitive nature of the traffic class. This queue gets the largest chunk of reserved bandwidth. This bandwidth combined with a low drop probability configured for RED is typical of a priority queue.
Configure the control queue for adequate bandwidth and a relatively short time in queue because of the time sensitive nature of the traffic class. Configure the default queue for the remaining bandwidth with a relatively long time in queue because of the non-time sensitive nature of the traffic class.
NOTE By default the default traffic assignment has a weight of 1% assigned to it, plus any excess bandwidth. Unless you actually configure the default traffic assignment with 0% weight, the greatest weight value that can be assigned to other traffic assignment is 99%. If you wish to assign 100% of the weight to other queues, configure the default traffic assignment queue bandwidth for 0%.
Figure 4-5. Queue Parameters Link Configuration Example
You assign a name, bandwidth and queue depth to the queue parameter-set command to configure queue parameter sets.
The amount of bandwidth assigned to a queue can be expressed as a percentage of the link bandwidth, an absolute numerical value in kilo bits per second, or in link notation, if the entire link is being applied to the queue. Bandwidth is assigned using the bandwidth bw option. The total bandwidth weights applied to all queues for this interface can not exceed 100 percent of the link bandwidth in terms of either percentage or absolute terms. Configure bandwidth weight as a percentage of link bandwidth when you wish to set queue bandwidth usage regardless of the actual link bandwidth value. This is useful when you have different size interfaces to which you wish to apply a relative resource usage. When you are concerned with absolute queue bandwidth, configure bandwidth as an absolute value expressed in kilo, mega, or gigabits per second.
The amount of packet buffering available to a queue depends upon the value assigned to queue depth. Queue depth can be expressed in absolute terms as the number of bits or as the time a packet is allowed to reside in a queue before the dropping of incoming packets begins. Configuring time in queue rather than absolute queue size is useful when you have different size interfaces to which you wish to apply a relative resource usage. Queue depth specified in time uses the queue's configured bandwidth to determine the queue depth in kilo-bits. You can determine the buffer space in kilobits for a queue depth specified in time by using the following equation:
Buffer space in kbits = (time (ms)/1000) * (weight (percent)/100) * link bandwidth in kbits/sec
Example: For example, you set the queue depth at 35ms, the queue weight at 50%, on a 2,488Mbit link. The queue depth in kilobits would be:
.035 * .5 * 2,488Mbits = 43,540kbits
You can determine the buffer space in milliseconds for a queue depth specified in kilobits by using the following equation:
Buffer space in ms = queue-depth in kilobits/(weight * link bandwidth in kbits/sec)
The queue parameter-set command uses system defaults to fill any unspecified values.
You can delete a configured queue parameter set by using the no option.
A default queue parameter set is assigned at configuration time. The default queue parameter set is used by any packet treatment to which you do not explicitly assign queue parameters. You can change the queue parameter set default values by using the queue default command. The default parameter set at initialization assigns 1% of the link bandwidth to bandwidth and a queue depth of 10ms.
The following command creates the q1 parameter set and sets queue values to a bandwidth weight of 12 percent and queue depth time in queue to 10ms:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#queue parameter-set q1 bandwidth 12% queue-depth 10ms
A single queue per interface can be configured for absolute-priority by specifying priority highest in the queue command line. This option specifies that all traffic in this queue will exit before the traffic that resides in any other queue. The following command adds this option to the q1 parameter set:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#queue parameter-set q1 priority highest
Understanding Relative Bandwidth
This section explains how weighted fair queues work. When configuring a queue parameter set for bandwidth, the value entered represents a relative bandwidth rather than an absolute bandwidth. When you configure a traffic assignment for a specific interface this relative bandwidth is associated with the traffic class in that queue: IP and/or MPLS. The actual bandwidth an interface provides a given traffic assignment at any given time is relative to the other traffic assignments using that interface at that time. The collective bandwidth weights associated with an interface through traffic assignments can not exceed 100 percent, but can be any value less than 100 percent. IPriori assigns any unassigned weight to the default traffic assignment.
Example: For example, an interface pos 1/2/3 has been configured with a traffic assignment named qos1, which has a bandwidth weight of 70 percent and which is used by both IP and MPLS level 7, using a queue parameter set named q1 assigned to packet treatment p1. The only other traffic assignments associated with this interface are the control and default traffic assignments. The bandwidth weight associated with the control traffic assignment for this example is 20 percent used by the control IP and MPLS traffic class, which is always 6. Because the default traffic assignment is assigned any unassigned resources, it receives the remaining bandwidth weight of 10 percent to be used by its traffic classes: 0 - 5 for both IP and MPLS.
If traffic for traffic classes 6, 7, and any of 0 - 5 were present at the same time, than the actual weights would be as assigned: 70 percent for traffic class 7, 20 percent for traffic class 6, and 10 percent shared by any traffic classes 0 - 5. Refer to Figure 4-6 for a visual presentation of the configured bandwidth for this example.
Figure 4-6. Configured Bandwidth Example
Using the weighted fair queue (WFQ) algorithm, the same example with no control traffic (IP precedence 6) present would mean that the 20 percent reserved for control would be shared by levels 7 and levels 0 - 5 relative to their respective weights as follows: classification 7 at 87.5 percent and classification 0 - 5 sharing 12.5 percent. The reason for this allocation is that the bandwidth is divided 7 parts to traffic class 7 for every 1 part shared by traffic classes 0 - 5. Refer to Figure 4-7 for a visual presentation of the relative bandwidth for this example.
Figure 4-7. Relative Bandwidth Example
PROCEDURE: You would configure this example using the following steps:
Step 1 Configure a queue parameter set named q1:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#queue parameter-set q1 bandwidth 70%
Step 2 Assign the q1 queue parameter set to a packet treatment
named p1:
router(config)#packet-treatment p1 queue-parameters q1
Step 3 Configure a traffic assignment named qos1 for IP precedence and MPLS EXP 7 and packet treatment p1 for the desired interface:
router(config)#interface pos 1/2/3
router(config-if)#qos qos1 ip prec 7 mpls exp 7 packet-treatment p1
router(config-if)#end
Assuming the default bandwidth weight of 20 percent for the control traffic assignment and no other traffic assignments configured for this interface, this completes the configuration for this relative bandwidth example.
Configuring Random Early Detect
Random Early Detect (RED) provides congestion avoidance by taking advantage of TCP's congestion control mechanism. RED informs the packet source that it should cut back on its transmission rate by randomly dropping packets before high congestion would cause tail-drops to take place. Tail drop takes place when there is no longer any buffer capacity. The problem with tail drop is that all packets are dropped until congestion is eliminated and the queue is no longer full. Dropping a large number of packets at one time can produce global synchronization. By associating RED parameters with a packet treatment, RED will selectively drop packets based upon the average depth of the queue and the configured drop probability. Because a lower probability of drops can be associated with a higher priority IP precedence, higher priority traffic has a higher probability of delivery during heavy traffic periods than lower priority traffic.
You configure RED parameter sets globally. They can be applied to any interface, therefore no specific resources are associated with a RED parameter set. You configure actual traffic assignment and its associated resources using the qos command, which includes RED parameters in its packet treatment field. Traffic assignment also associates DSCP with RED providing the ability to configure Weighted Random Early Detect (WRED).
There are three values associated with RED: a minimum queue-depth threshold set using the min-th option, a maximum queue-depth threshold set using the max-th option, and up to two drop probabilities set using the max-mark-spacing and red-max-mark-spacing options. The minimum queue-depth threshold is the queue usage in either kilo-bits or drain time. Once the minimum queue-depth threshold is reached, RED starts to drop packets. As the queue usage increases, the probability of packet drop increases linearly until queue usage reaches the maximum queue-depth threshold. At the maximum queue-depth threshold, drop probability equals the configured drop probability. Once queue usage exceeds the maximum queue-depth threshold, all packets are dropped. The drop probability is 1/x where x is the value of max-mark-spacing or red-max-mark-spacing depending upon whether the drop preference for this packet's PSC mapping is green or red, respectively. Minimum and Maximum threshold values can be entered within a range, but IPriori translates the entered value into one of a set of discreet values. Refer to section "Calculating Random Early Detect Parameter Values" on page 165 for details.
Figure 4-8 provides a graphic presentation for the calculation of RED on drop preference. The rate of the packet drop line remains at zero until the average queue size reaches the minimum threshold value of 20ms. At this point the rate of drop climbs a linear ramp until it reaches the average queue size value set for maximum threshold. For this example the maximum mark spacing value was configured at 4. The packet drop probability is therefore one in four or .25 of all packets when the average queue size is at maximum threshold of 40ms. To determine the drop probability for any given average queue size between the minimum and maximum thresholds use the following format:
(((actual average queue size - minimum threshold) / minimum threshold) * drop probability at maximum threshold)
Example: For this example, with an actual average queue size of 24ms the drop probability would be:
(((24 - 20) / 20) * .25) = .05
for a drop probability of 1 in 20 packets.
Figure 4-8. Drop Preference Calculation
Once the average queue size exceeds the maximum threshold of 40ms, all packets are dropped.
Set the minimum queue-depth threshold high enough to maximize the utilization of the link without risk of congestion. A low minimum queue-depth threshold will cause an under-utilization of the link when packets are needlessly dropped. You must avoid a too small difference between the minimum and maximum thresholds in order to avoid global synchronization due to too many packets being dropped at once.
Use the random-detect parameter-set command to configure RED parameter sets.
The default RED parameter-set is configured at initialization time with default values of min-th 5ms, max-th 10ms, and max-mark-spacing 8. The default RED parameter set is used by any packet treatment to which you do not explicitly assign RED parameters. You can change these default values by using the random-detect default command.
To delete a RED parameter set use the no option for this command, specifying the name of the parameter set you wish to delete.
The following command sets the minimum threshold default value to 5ms, the maximum threshold default value to 12ms, and the maximum threshold mark spacing value to 8, which provides a drop probability of one in eight packets:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#random-detect default min-th 5ms max-th 12ms max-th-mark-spacing 8
Configuring Packet Treatments
Packet treatments are a means of grouping queue and RED parameters and parameter sets. Packet treatments are configured at the global level and do not have interface resources associated with them until you establish a traffic assignment at the interface level and specify the packet treatment, using the qos command. Because no resources are actually assigned to a packet treatment, you may configure as many packet treatments as you like. For both RED and queue configurations you may specify a unique set of parameter values or an already configured parameter set to the new packet treatment. If you do not specify anything for either RED or queue configurations, the default parameter set for the missing option is used. See the command random-detect default in the "IPriori CLI Reference (Vol. 3)" manual for information concerning RED default values and the command queue default in the "IPriori CLI Reference (Vol. 3)" manual for information concerning queue default values.
Refer to Figure 4-3 for a presentation of how a packet treatment fits into a traffic assignment.
Use the packet-treatment command to configure packet treatments.
Packet treatment configuration for both RED and queue parameters can be accomplished by either setting individual parameter values or by providing the name of an already existing parameter set.
Use the min-th, max-th, and max-mark-spacing options to specify the RED parameter values associated with this packet treatment. See the command random-detect parameter-set in the "IPriori CLI Reference (Vol. 3)" manual for the details associated with these parameters. Use the random-detect-parameters option to associate an already existing RED parameter set with this packet treatment.
The red-max-mark-spacing option provides a second drop probability that is configurable as a separate packet-treatment command parameter.
Use the bandwidth, priority, and queue-depth options to specify the queue parameter values associated with this packet treatment. See the command queue parameter-set in the "IPriori CLI Reference (Vol. 3)" manual for the details associated with these parameters.
Use the queue parameters option to associate an already existing queue parameter set with this packet treatment.
When you first create a packet treatment, if you do not enter a parameter or parameter set for either a RED or queue option, the defaults associated with these functions will be applied to this packet treatment.
For an already existing packet treatment, if you do not enter a parameter or parameter set for either a RED or queue option, the already existing values for these options do not change.
You can delete a packet treatment using the no option with this command.
The following command creates a packet treatment named p1 and associates with it the minimum threshold value of 5ms, a maximum threshold value of 12ms, a maximum threshold mark spacing value of 7, a red maximum threshold mark spacing value of 7, and a queue parameter set named q1:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#packet-treatment parameter-set p1 min-th 5ms max-th 12ms max-th-mark-spacing 7 red-max-mark-spacing 7 queue-parameters q1
Configuring PSCs
There are three parameters associated with configuring PSCs: A list that specifies the traffic classes to be mapped to the PSC, the specification of a drop preference, and the specification of a fabric priority. The mapping of these parameters to a PSC is based upon packet type: IP or MPLS. IP packets map DSCP traffic classes to IP PSCs. MPLS packets map EXP traffic classes to MPLS PSCs.
DSCP and EXP traffic classifications are not directly associated with packet treatments. Traffic classifications are first mapped to Per-hop behavior Scheduling Classes (PSC). A PSC is also referred to as an ordered aggregate. A PSC's traffic may not be reordered with respect to itself. IPriori treats the PSC as a traffic class which can be assigned to a traffic assignment using the qos command.
One or more PSCs are associated with a packet treatment to form a traffic assignment. DSCP values are mapped to IP PSCs using the dscp-mapping command to enter DSCP mapping configuration mode, specifying either default or the name of a DSCP parameter-set to be configured. EXP values are mapped to MPLS PSCs using the exp-mapping command to enter EXP mapping configuration mode, specifying either default or the name of an EXP parameter-set to be configured. While in either mapping configuration mode, the from command maps specified traffic classifications to specified PSCs.
Drop preference determines which packet treatment drop probability will be applied to packets associated with a given mapping. There are two drop preferences: green and red. If a PSC is mapped to a green drop preference, its drop probability as it crosses the fabric is based upon the packet treatment value configured for max-mark-spacing. If a PSC is mapped to a red drop preference, its drop probability as it crosses the fabric is based upon the packet treatment value configured for red-max-mark-spacing.
There are two fabric queue types: low and high priority. The fabric priority associated with a PSC determines which fabric queue will handle a given packet. If the fabric priority is best-effort or priority, the low priority queue will process the packet. If the fabric priority is regulated, the high priority queue will process the packet. In any case, best-effort packets will be dropped before priority traffic, and priority packets will be dropped before regulated. Access to the queues is as follows: IPriori schedules an internal control packet for queueing ahead of all other packets. If all control packets are scheduled, IPriori schedules a regulated packet for queueing. If all control and regulated packets are scheduled, best-effort and priority packets are scheduled for queueing on a round-robin basis. The affect of the round-robin is that lower volume priority packets get better access than higher volume best-effort packets.
Configuring IP PSCs
The DSCP bits of the Differentiated Services field provides for up to sixty-four unique values from 0 - 63. Any grouping or range of these values may be mapped to one of four IP PSCs. Up to four IP PSCs can be associated with a packet treatment to form a traffic assignment using the qos command. PSCs can be specified directly or first configured in a classifier when configuring a traffic assignment. A given PSC can not be associated with multiple traffic assignments on a single interface.
The DSCP to PSC mapping supports the listing of IANA dscp-registry and IP Precedence including: Class Selector (CS), Assured Forwarding (AF), Expedited Forwarding (EF), IP Precedence (PREC), as well as numbers from 0 - 63.
You map DSCP values to an IP PSC by associating a DSCP specifier list with the PSC. Table 4-1 lists the valid DSCP specifier list values and the DSCP mapping for each value by type.
Table 4-1. Specifier list Entry to DSCP Mapping Value
DSCP Type Valid Specifier List Values DSCP Mapping Number
0 - 63
0 - 63
Class Selector
CS
0, 8, 16, 24, 32, 40, 48, 56
CS0
0
CS1
8
CS2
16
CS3
24
CS4
32
CS5
40
CS6
48
CS7
56
Assured Forwarding
AF
10, 12, 14, 18, 20, 22, 26, 28, 30, 34, 36, 38
AF1
10, 12, 14
AF2
18, 20, 22
AF3
26, 28, 30
AF4
34, 36, 38
AF11
10
AF21
12
AF31
14
AF41
18
AF12
20
AF22
22
AF32
26
AF42
28
AF13
30
AF23
34
AF33
36
AF43
38
Expedited Forwarding
EF
16
IP Precedence
PREC0
0 - 7
PREC1
8 - 15
PREC2
16 - 23
PREC3
24 - 31
PREC4
32 - 39
PREC5
40 - 47
PREC6
48 - 55
PREC7
56 - 63
Use the dscp-mapping command, specifying either default or the name of a parameter-set, to enter DSCP mapping mode. When a new parameter set is created, it is initially filled with the current default values. Use the from command to associate a DSCP specifier list with a PSC. Any traffic classes not specified remain at the current default value. You can also specify whether the drop preference is green or red, and whether the fabric priority is best effort, priority, or regulated. Drop preference determines whether the max-mark-spacing, if drop preference is green, or red-max-mark-spacing, if the drop preference is red, will be used for the packet treatments drop probability. The fabric priority determines whether a low priority queue, if best effort or priority is specified, or a high priority queue, if regulated is specified, as the packet traverses the fabric.
A DSCP specifier list may contain any number of valid specifier list values, delineated by a comma, that will be mapped to the DSCP value listed in Table 4-1.
The following is the default DSCP to PSC mapping:
Table 4-2. IP to PSC mapping defaults
From DSCP To PSC Drop Preference Fabric Priority 0 - 7
0
Green
Best-effort
8 - 15
0
Green
Best-effort
16 - 23
1
Green
Best-effort
24 - 31
1
Green
Best-effort
32 - 39
2
Green
Best-effort
40 - 47
2
Green
Best-effort
48 - 55
3
Green
Regulated
56 - 63
3
Green
Regulated
Configuring MPLS PSCs
The EXP bits of the MPLS header EXP field provides for up to eight unique values from 0 - 7. Any grouping or range of these values may be mapped to one of four EXP PSCs. Up to four EXP PSCs can be associated with a packet treatment to form a traffic assignment using the qos command. PSCs can be specified directly or first configured in a classifier when configuring a traffic assignment. A given PSC can not be associated with multiple traffic assignments on a single interface.
You map EXP values to an EXP PSC by associating an EXP specifier list with the PSC.
Use the exp-mapping command, specifying either default or the name of a parameter-set, to enter EXP mapping mode. When a new parameter set is created, it is initially filled with the current default values. Use the from command to associate an EXP specifier list with a PSC. Any traffic classes not specified remain at the current default values. You can also specify whether the drop preference is green or red, and whether the fabric priority is best effort, priority, or regulated. Drop preference determines whether the max-mark-spacing, if drop preference is green, or red-max-mark-spacing, if the drop preference is red, will be used for the packet treatments drop probability. The fabric priority determines whether a low priority queue, if best effort or priority is specified, or a high priority queue, if regulated is specified, as the packet traverses the fabric.
An EXP specifier list may contain any number of valid specifier list values, delineated by a comma
The following is the default EXP to PSC mapping:
Table 4-3. EXP to PSC mapping defaults
From EXP To PSC Drop Preference Fabric Priority 0
0
Green
Best-effort
1
0
Green
Best-effort
2
1
Green
Best-effort
3
1
Green
Best-effort
4
2
Green
Best-effort
5
2
Green
Best-effort
6
3
Green
Regulated
7
3
Green
Regulated
PSC Configuration Example
The following example creates DSCP and EXP to PSC parameter sets that assign a red drop priority and regulated fabric priority to DSCP values 40 - 47 and EXP value 5, respectively.
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#dscp-mapping parameter-set redPREC5
router(config)#from 40-47 to psc 2 dropPref red fabricPriority regulated
router(config)#exp-mapping parameter-set redEXP5
router(config)#from 5 to psc 2 dropPref red fabricPriority regulated
router(config)#end
router#show dscp-mapping redPREC5
dscp-mapping redPREC5
from 0-7 to psc 0 dropPref green fabricPriority best-effort
from 8-15 to psc 0 dropPref green fabricPriority best-effort
from 16-23 to psc 1 dropPref green fabricPriority best-effort
from 24-31 to psc 1 dropPref green fabricPriority best-effort
from 32-39 to psc 2 dropPref green fabricPriority best-effort
from 40-47 to psc 2 dropPref red fabricPriority regulated
from 48-55 to psc 3 dropPref green fabricPriority regulated
from 56-63 to psc 3 dropPref green fabricPriority regulated
router#show exp-mapping redEXP5
exp-mapping redEXP5
from 0 to psc 0 dropPref green fabricPriority best-effort
from 1 to psc 0 dropPref green fabricPriority best-effort
from 2 to psc 1 dropPref green fabricPriority best-effort
from 3 to psc 1 dropPref green fabricPriority best-effort
from 4 to psc 2 dropPref green fabricPriority best-effort
from 5 to psc 2 dropPref red fabricPriority regulated
from 6 to psc 3 dropPref green fabricPriority regulated
from 7 to psc 3 dropPref green fabricPriority regulated
Configuring a Classifier
Classifiers provide a convenient means of grouping traffic classes. Traffic belonging to the same classifier is treated equally. Classifiers are configured by associating Per-hop behavior Scheduling Classes (PSC) with the specified classifier. This release supports the classification of data by DSCP and MPLS EXP mapped to between 1 and 4 IP PSCs, using the ip classifier command and 1 and 4 MPLS PSCs, using the mpls classifier command. Classifiers are configured at the global level and do not have actual interface resources associated with them until you establish a traffic assignment and associate the classifier with it using the qos command. When a traffic assignment is configured, one or more classifiers will be associated with a packet treatment and assigned to one of eight interface queues.
To configure a classifier enter a name and a list of the traffic classes you wish to associate with the classifier.
All classifier names reside in the same name space so you can not use the same name for both an IP and an MPLS classifier, i.e. there can not be an IP classifier c1 and an EXP classifier c1 configured on the same router. If you configured an IP classifier c1 and you decide you want to name an EXP classifier c1, you must first delete the IP classifier before you can configure the EXP classifier.
The following example will give you an error:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#ip classifier c1 psc 0-2
router(config)#mpls classifier c1 psc 3
Error: classifier c1 is an IP classifier
router(config)#
The following example will not give you an error:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#ip classifier c1 psc 0-2
router(config)#no ip classifier c1
router(config)#mpls classifier c1 psc 3
router(config)#
An IP classifier can contain one or more IP psc values. An MPLS classifier can contain one or more MPLS psc values. Each multiple value entry must be delineated based upon whether it is part of a consecutive range or nonconsecutive set. A range of consecutive values is delineated by a dash (-) e.g. values 0 through 2 are entered as 0-2. A nonconsecutive set of values is delineated by a comma (,) e.g. values 0 and 2 are entered as 0,2.
You can configure as many classifiers as you wish. A configured classifier can contain any combination of IP PSC values for an IP classifier or MPLS PSC values for an MPLS classifier. When assigning multiple classifiers to a single interface using traffic assignments, see "Configuring a Quality of Service Traffic Assignment" on page 102, the members of one classifier can not be a proper subset of another of the same classifier type: IP or MPLS. For example if one classifier has values 0-2 as its members, another group of the same type, assigned to the same interface, can not have values 0,1 as its members. An error will be generated if a proper subset of one classifier is found in a second classifier for a single interface.
To delete a classifier group use the no option with this command.
The following command creates a classifier named cIP1 and associates PSC values 0 and 1 with it:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#ip classifier cIP1 psc 0,1
The following command creates a classifier cEXP1 and associates MPLS PSC values 0 and 1 with it:
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#mpls classifier cEXP1 psc 0,1
Configuring QoS-Mark Mapping
QoS-Mark mapping determines how a packet should be marked as it exits the router, by mapping PSCs used to determine treatment as a packet crosses the fabric to the exiting DSCP or EXP value. Unlike DSCP and EXP mapping, QoS-Mark mapping can be disabled. If QoS-Mark mapping is disabled the exiting DSCP or EXP value will be unchanged, providing there is no change in header type e.g., if a packet enters as an IP packet and exits as an MPLS packet, change in exit value is required. In this case the factory default EXP QoS marking is used.
There are three parameters associated with configuring QoS-Mark mappings: the PSC or range to be mapped, the drop preference associated with the specified PSC, and a specific DSCP or EXP traffic class to be used by the exiting packet. The traffic class exit value is based upon packet type: IP or MPLS. IP packets are assigned the specified DSCP value. MPLS packets are assigned the specified EXP value.
The specification of a drop preference provides for the association of DSCP or EXP values with each of the two available drop preferences: green or red.
You must first enter QoS-Mark mapping mode specifying either the default mapping or a parameter set. If you specify a new parameter set, the mapping is initially filled with the current default values. Use the qosmark-mapping command to enter QoS-Mark mapping mode. Once in QoS-Mark mapping mode, use the from command to specify the PSC and drop preference to associate with the specified DSCP and/or EXP to be used by the exiting packet.
Use the no qosmark-mapping command to disable QoS-Mark mapping. QoS-Mark mapping on any interface is disabled by default. To override the default, enter in qosmark-mapping default or qosmark-mapping parameter-set-name. Using the default keyword restores factory-defaults as detailed in Table 4-4.
Configuration of QoS-Mark mapping is global if the qosmark-mapping command is entered in configuration command mode. Global configurations may be overwritten per interface by entering the qosmark-mapping command in interface mode, specifying either the default keyword or the name of a parameter-set.
The following is the default QoS-Mark mapping:
Table 4-4. PSC to Traffic Class Exit Mapping Defaults if Not Disabled
From PSC Drop Preference To DSCP To EXP 0
Green
CS0
0
0
Red
CS0
0
1
Green
CS1
1
1
Red
CS1
1
2
Green
CS2
2
2
Red
CS2
2
3
Green
CS6
6
3
Red
CS6
6
The following example creates a QoS-Mark mapping parameter set that assigns DSCP CS7 and EXP 7 as the exiting traffic class for any packet marked with PSC 2 and a green or red drop preference. All other values remain at the current default value for this parameter-set. The mark1 QoS-Mark mapping is then applied to interface 1/1/1.
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#qos-mapping parameter-set mark1
router(config)#from psc 2 dropPref green to dscp CS7 exp 7
router(config)#from psc 2 dropPref red to dscp CS7 exp 7
router(config)#end
router#show qosmark-mapping mark1
qosmark-mapping parameter-set mark1
from psc 0 dropPref green to dscp CS0 dscp 0
from psc 0 dropPref red to dscp CS0 exp 0
from psc 1 dropPref green to dscp CS0 dscp 1
from psc 1 dropPref red to dscp CS0 exp 1
from psc 2 dropPref green to dscp CS7 dscp 7
from psc 2 dropPref red to dscp CS7 exp 7
from psc 3 dropPref green to dscp CS6 exp 6
from psc 3 dropPref red to dscp CS6 dscp 6
router#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#interface 1/1/1
router(config-if)qos-mapping parameter-set mark1
router(config-if)exit
router#
Configuring a Quality of Service Traffic Assignment
A QoS traffic assignment provides for the association of mapped IP and MPLS PSC values, named classifier groups, and a packet treatment to interface resources. Up until now all configuration of traffic classes, classifier groups or parameter sets have been at the global configuration level; in other words, not associated with actual interface resources. With the configuration of a traffic assignment, PSCs, classifier groups, and parameter sets are assigned to a Weighted Fair Queue (WFQ). A WFQ group consists of physical queue resources that are divided based upon the QoS traffic assignments associated with it. You can configure a single WFQ group per interface. You can configure up to eight traffic assignments per WFQ group.
When you first initialize a system, two QoS traffic assignments are automatically configured: one named default for best effort traffic and one named control for internal control and priority traffic. The default traffic assignment provides a best effort packet treatment for packets in IP and MPLS PSCs 0 - 2. Any bandwidth or traffic not explicitly configured in a named QoS traffic assignment is assigned to the default traffic assignment. The control traffic assignment provides a priority packet treatment for packets with IP and MPLS PSC 3. If you do not wish to concern yourself with QoS, these two traffic assignments will provide a minimum level of QoS that treats best effort traffic equally while providing a higher level of packet treatment for both internal control packets and priority traffic.
Refer to Figure 4-9 and Figure 4-10 for default and control traffic assignment information in block diagram form.
Figure 4-9. Default Traffic Assignment Block Diagram
Figure 4-10. Control Traffic Assignment Block Diagram
CAUTION The Traffic assignment containing IP precedence traffic class 6 or DSCP traffic class 48 determines the treatment of control packets sourced by the Avici router. If you map t