Quality of Service Configuration

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 5-1 for a graphic representation of the field.

Figure 5-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 5-2 for a graphic representation of the EXP field within a generic MPLS header.

Figure 5-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. There are three drop preferences: green, yellow and red. These preferences map to the standard assured forwarding AFx1, AFx2, and AFx3 loss probabilities as defined in RFC2597. IPriori provides for the user configuration of up to three RED drop probabilities using the max-mark-spacing, min-th, and max-th (green), red-max-mark-spacing, red-min-th, red-max-th (red), and yellow-max-mark-spacing, yellow-min-th, yellow-max-th (yellow) options.

NOTE The yellow drop preference is fully supported on Family 2 modules. The 16xOC-3c supports green, yellow, and red drop preference settings for IP packets. For MPLS packets, green and red drop preference settings are configurable; output packet treatment of yellow packets is green. For all other Family 1 modules, green, yellow, and red drop preferences are configurable, but output packet treatment of yellow packets is green for both IP and MPLS packets.

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 5-3 for a block diagram of the QoS traffic assignment.

Figure 5-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 5-4 for a presentation of QoS from the perspective of the router module.

Figure 5-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 Table  "Stepping Through A Configuration Example" 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 parameter-set 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 5-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 5-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

router#show queue parameter-set q1 queue parameter-set q1 bandwidth 12.0000% priority lowest queue-depth 10.00ms used by : packet-treatment p1

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 router#show queue parameter-set q1 queue parameter-set q1 bandwidth 12.0000% priority highest queue-depth 10.00ms used by : packet-treatment p1

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 5-6 for a visual presentation of the configured bandwidth for this example.

Figure 5-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 5-7 for a visual presentation of the relative bandwidth for this example.

Figure 5-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 parameter-set 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 drop probability:

• Up to three minimum queue-depth threshold set using the min-th option for green, the yellow-min-th option for yellow, and the red-min-th option for red.
  
  
• Up to three maximum queue-depth threshold set using the max-th option for green, the yellow-max-th option for yellow, and the red-max-th option for red.
  
  
• Up to three drop preferences set using the max-mark-spacing option for green, the red-max-mark-spacing option for red, and the yellow-max-mark-spacing option for yellow.
  
  

  NOTE Configuring equal min-th and max-th values disables RED. The actual min-th and max-th values in a show qos interface display will reflect RED being disabled.

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, red-max-mark-spacing, or yellow-max-mark-spacing depending upon whether the drop preference for this packet's PSC mapping is green, red, or yellow, respectively. Minimum and Maximum threshold values can be entered within a range, but IPriori translates the entered value into one of a set of discrete values. Refer to section "Calculating Random Early Detect Parameter Values" for details.

Figure 5-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 5-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 for green, red, and yellow parameters as follows: minimum queue-depth threshold 5ms, maximum queue-depth threshold 10ms, and drop probability 8. The default values for red and yellow min-th, max-th and max-mark spacing are the same as for green. 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 10ms max-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 5-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 [yellow- | red-]min-th, [yellow- | red-]max-th, and [yellow- | red-]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.

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 for the green, yellow, and red max-mark-spacing options, 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-mark-spacing 7 yellow-min-th 5ms yellow-max-th 12ms yellow-max-mark-spacing 7 red-min-th 5ms red-max-th 12ms 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.

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.

Drop preference determines which packet treatment drop preference will be applied to packets associated with a given mapping. There are three drop preferences: green, red, and yellow. If a PSC is mapped to a green drop preference, its drop preference is based upon the packet treatment value configured for max-mark-spacing. If a PSC is mapped to a red drop preference, its drop preference is based upon the packet treatment value configured for red-max-mark-spacing. If a PSC is mapped to a yellow drop preference, its drop preference is based upon the packet treatment value configured for yellow-max-mark-spacing.

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 5-1 lists the valid DSCP specifier list values and the DSCP mapping for each value by type.

Table 5-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
	AF12	12
	AF13	14
	AF21	18
	AF22	20
	AF23	22
	AF31	26
	AF32	28
	AF33	30
	AF41	34
	AF42	36
	AF43	38
Expedited Forwarding
	EF	46
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, red, or yellow and whether the fabric priority is best effort, priority, or regulated. Drop preference determines whether the max-mark-spacing, red-max-mark-spacing, or yellow-
max-mark-spacing (green, red, or yellow drop preference, respectively) 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 5-1.

The following is the default DSCP to PSC mapping:

Table 5-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, red, or yellow and whether the fabric priority is best effort, priority, or regulated. Drop preference determines whether the max-mark-spacing, red-max-mark-spacing, or yellow-max-mark-spacing 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 5-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(dscp-mapping)#from 40-47 to psc 2 dropPref red fabricPriority regulated router(dscp-mapping)#exit router(config)#exp-mapping parameter-set redEXP5 router(exp-mapping)#from 5 to psc 2 dropPref red fabricPriority regulated router(exp-mapping)#end router#show dscp-mapping parameter-set redPREC5 dscp-mapping parameter-set redprec5 from 0-15 to psc 0 dropPref green fabricPriority best-effort from 16-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-63 to psc 3 dropPref green fabricPriority regulated router#show exp-mapping parameter-set redEXP5 exp-mapping parameter-set 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 exists with IP prec value! 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", 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 router(config)#end router#show ip classifier 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 router(config)#end router#show mpls classifier 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 three available drop preferences: green, red, or yellow.

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 5-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 5-4. PSC to Traffic Class Exit Mapping Defaults if Not Disabled

From PSC	Drop Preference	To DSCP	To EXP
0	Green	CS0	0
0	Yellow	CS0	0
0	Red	CS0	0
1	Green	CS1	1
1	Yellow	CS1	1
1	Red	CS1	1
2	Green	CS2	2
2	Yellow	CS2	2
2	Red	CS2	2
3	Green	CS6	6
3	Yellow	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)#qosmark-mapping parameter-set mark1 router(config)#from psc 2 dropPref green to dscp CS7 exp 7 router(config)#from psc 2 dropPref yellow to dscp CS7 exp 7 router(config)#from psc 2 dropPref red to dscp CS7 exp 7 router(config)#end router#show qosmark-mapping parameter-set mark1 qosmark-mapping parameter-set mark1 no disable-marking from psc 0 dropPref green to dscp 63 exp 0 from psc 0 dropPref red to dscp 30 exp 0 from psc 0 dropPref yellow to dscp CS0 exp 0 from psc 1 dropPref green to dscp 35 exp 1 from psc 1 dropPref red to dscp 0 exp 1 from psc 1 dropPref yellow to dscp CS1 exp 1 from psc 2 dropPref green to dscp CS7 exp 7 from psc 2 dropPref red to dscp CS7 exp 7 from psc 2 dropPref yellow to dscp CS7 exp 7 from psc 3 dropPref green to dscp 16 exp 6 from psc 3 dropPref red to dscp 0 exp 6 from psc 3 dropPref yellow to dscp CS6 exp 6 % used by : ( none ) router#show qosmark-mapping qosmark-mapping default qosmark-mapping parameter-set mark1 router#show qosmark-mapping default qosmark-mapping default disable-marking from psc 0 dropPref green to dscp CS0 exp 0 from psc 0 dropPref red to dscp CS0 exp 0 from psc 0 dropPref yellow to dscp CS0 exp 0 from psc 1 dropPref green to dscp CS1 exp 1 from psc 1 dropPref red to dscp CS1 exp 1 from psc 1 dropPref yellow to dscp CS1 exp 1 from psc 2 dropPref green to dscp CS2 exp 2 from psc 2 dropPref red to dscp CS2 exp 2 from psc 2 dropPref yellow to dscp CS2 exp 2 from psc 3 dropPref green to dscp CS6 exp 6 from psc 3 dropPref red to dscp CS6 exp 6 from psc 3 dropPref yellow to dscp CS6 exp 6 used by : gbe 1/13/1 gbe 1/13/2 pos 1/14/1 pos 1/14/2 pos 1/16/1 pos 1/17/1 pos 1/18/1 pos 1/18/2 pos 1/18/3 pos 1/18/4 pos 1/18/5 pos 1/18/6 pos 1/18/7 pos 1/18/8 pos 1/18/9 pos 1/18/10 pos 1/18/11 pos 1/18/12 pos 1/18/13 pos 1/18/14 pos 1/18/15 pos 1/18/16

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#interface pos 1/14/1 router(config-if)qosmark-mapping parameter-set mark1 router(config-if)exit router#show qosmark-mapping parameter-set mark1 qosmark-mapping parameter-set mark1 no disable-marking from psc 0 dropPref green to dscp 63 exp 0 from psc 0 dropPref red to dscp 30 exp 0 from psc 0 dropPref yellow to dscp CS0 exp 0 from psc 1 dropPref green to dscp 35 exp 1 from psc 1 dropPref red to dscp 0 exp 1 from psc 1 dropPref yellow to dscp CS1 exp 1 from psc 2 dropPref green to dscp CS7 exp 7 from psc 2 dropPref red to dscp CS7 exp 7 from psc 2 dropPref yellow to dscp CS7 exp 7 from psc 3 dropPref green to dscp 16 exp 6 from psc 3 dropPref red to dscp 0 exp 6 from psc 3 dropPref yellow to dscp CS6 exp 6 used by : pos 1/14/1

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 5-9 and Figure 5-10 for default and control traffic assignment information in block diagram form.

Figure 5-9. Default Traffic Assignment Block Diagram

Figure 5-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 these IP traffic classes to a PSC other than 3 or remove PSC 3 from the control traffic assignment, you change the packet treatment for all control packets sourced by the Avici router. Always assure that traffic classes associated with internal control packets are mapped to a PSC assigned to the control traffic assignment. Do not modify the control traffic assignment packet treatment options unless you are certain you know what you are doing.

If you wish to disassociate non-internal control traffic classes from the control traffic assignment, create a new traffic assignment using the qos command, map the desired traffic classes to another PSC and assign the PSC to the new traffic assignment.

You can reconfigure the default QoS traffic assignments by assigning the default name to the qos ip psc or qos mpls psc command. Each IP and MPLS PSC value is unique. You can only associate a single packet treatment with any given PSC value. If you create QoS traffic assignments with different names and assign already configured PSC values to the new traffic assignments, IPriori removes the PSCs from the old traffic assignment and assigns them to the newly created traffic assignment. If all traffic is removed, the unused traffic assignment is deleted.

Configure QoS traffic assignments by associating a name, one or more IP and/or MPLS PSCs and/or classifiers, and a packet treatment with the qos command. You can over-ride one or more packet treatment option values by specifying the packet treatment option and new value you wish to over-ride.

Use of the qos command is not additive. Each time you use the command it is a complete reconfiguration should the named QoS group already exist. For the reconfiguration of an already existing traffic assignment, default values replace any unspecified options, including pre-existing option values. See "Understanding Parameter Modification Vs. Replacement" for further information.

Use the no qos command to delete a QoS parameter group and automatically reassign associated classes and bandwidth to qos default for this interface. The qos default can not be deleted.

Quality of Service Traffic Assignments at System Initialization

At system initialization two QoS traffic assignments are automatically configured and named default and control. These two names are reserved. These two traffic assignments represent the minimum configuration required for IPriori QoS in that they provide best effort resources to all packets in IP DSCP traffic classes 0 - 47 and MPLS traffic classes 0 - 5 and higher level priority resources for packets with IP DSCP traffic classes 48 - 63 and MPLS traffic classes 6 and 7. The IP precedence value for all Avici router internal control packets is 6. The DSCP value for all Avici router internal control packets is 48. The IP precedence and MPLS traffic class 7 is the Avici router default for priority traffic. The DSCP traffic classes 49 - 63 is the Avici router default for priority traffic.

You can change the contents of either of these traffic assignments or create new QoS traffic assignments using the qos command. When doing so you must keep in mind the following unique aspects of the default QoS traffic assignment:

• It can not be deleted. It always exists even if no resources are assigned to it; i.e., all resources are assigned to other traffic assignments.
  
  
• All undistributed bandwidth is automatically assigned to it.
  
  
• Using the no qos default command resets the values to the original system initialization values. For all other traffic assignments the no qos name command deletes the named traffic assignment. This is the only way to restore the factory packet treatment.
  
  
• All unassigned traffic automatically returns to this traffic assignment.
  
  

Understanding the Default Traffic Assignment Packet Treatment

When you first initialize a Avici router, IPriori assigns a factory packet treatment to the default traffic assignment. The factory packet treatment is static; it can not be altered by the user. If you wish to change the contents of the packet treatment associated with the default traffic assignment, configure a default packet treatment with the desired values. The default packet treatment is automatically applied to the default traffic assignment.

For example, let us say you wanted to change RED values associated with the default traffic assignment: changing the min-th value from 5ms to 4ms and the red-max-mark-spacing value from 8 to 16. Assign the new values to the default packet treatment as follows:

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)packet-treatment default min-th 4ms red-max-mark-spacing 16

Refer to "Default Traffic Assignment Block Diagram" for a listing of the factory packet treatment values.

If you wish to reset the packet treatment for the default traffic assignment to initialization settings, including the factory packet treatment, use the no qos command. For example:

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#interface pos 1/1/1 router(config-if)#no qos default router(config-if)#end

Configuring IP and MPLS PSCs and Multiple Classifiers

There are two types of PSCs: IP and MPLS. For both PSC types, valid values are 0 - 3, with 0 representing best effort, 3 representing internal control and high priority. The IPriori system initialization assigns PSC values 0 - 2 to the default and value 3 to the control QoS traffic assignments. See "Quality of Service Traffic Assignments at System Initialization" for further information on default and control traffic assignments.

When assigning IP or MPLS PSCs to a QoS traffic assignment you can either explicitly state the traffic class values using the ip psc and/or the mpls psc options, or you can name up to eight pre-configured classifiers using the classifier cname_1, ... cname_8 option. See "Configuring a Classifier" for classifier configuration information.

Each multiple value IP or MPLS PSC 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 up to eight pre-configured classifiers: one for each of four IP and four MPLS PSCs. A configured IP classifier can contain any combination of valid IP PSC values; a configured MPLS classifier can contain any combination of valid MPLS PSC values. When assigning a single or multiple QoS traffic assignments to an interface, one classifier's PSC values can not constitute a proper subset of another classifier's PSC values assigned to that interface. This is true for both IP and MPLS PSC values. For example, if one classifier contains values 0-2 as its members, then another classifier, of the same classification type, assigned to the same interface can not have values 1,2 as its members whether or not the subset is in the same or a different traffic assignment. An error will be generated. Remember, you configure classifiers at the global configuration level. For IPriori to attempt to reconfigure classifiers as they are applied to an interface would have unknown and undesirable affects with the assignment of that classifier to another interface.

Configuring Packet Treatments

Packet treatments provide for the defining of queue resources and congestion behavior. A traffic assignment allocates interface resources configured by a packet treatment and associates them with one or more specified PSCs or classifiers. Packet treatments assigned to a traffic assignment must be globally pre-configured using the packet-treatment command. The global packet treatment name is associated with the traffic assignment using the packet-treatment option of the qos command. You assign a single packet treatment to each traffic assignment. You assign multiple packet treatments to a single interface's resources by configuring multiple traffic assignments. You can not configure more than 100 percent of an interfaces bandwidth resources. IPriori assigns any undistributed resources to the default packet treatment. If you do not associate a packet treatment with a traffic assignment, the default packet treatment is automatically assigned.

See "Configuring Packet Treatments" for the details associated with configuring global packet treatments.

Configuring Quality of Service on a Composite Link

Avici router composite links support QoS. You configure all aspects of a composite link for QoS exactly the same way you configure QoS for a POS interface. You first create a composite link and assign members to it as detailed in the "Interfaces" chapter IPriori Software Configuration Guide. Treat the created composite link the same way you would a single POS interface, and configure QoS accordingly.

Understanding Bandwidth and Queue Resources on a Composite Link

A composite link configured for modules of different speed and port number does not necessarily have a one to one relationship between port bandwidth and buffer space resources. IPriori must maintain a constant ratio between bandwidth and buffer space for QoS to function properly on a composite link. The actual buffer space available to a given link is directly related to the number of ports on the module, rather than any given port bandwidth. A one port module will have all available buffer space assigned to the single port. A four port module will have 25 percent of the available buffer space assigned per port regardless of port bandwidth. Because of this non-linear relationship between bandwidth and buffer space per port, IPriori determines the proper amount of queue depth to advertise for a composite link, based upon all its member links.

Traffic is distributed among the members of a composite link according to each member's link bandwidth. Thus, an OC-48c link receives four times more traffic than an OC-12c link. IPriori assures that buffer space available for any link is relative to the speed of the link. For instance, an OC-48c link receives four times the queue depth in kilobits of an OC-12c link to obtain equal behavior by each link.

To support the requirement that queue depth be proportional to link bandwidth, the following are examples of buffer space advertising:

• An OC-48c will be advertised with the module's available packet memory, as in a 1xOC-48c board.
  
  
• An OC-12c will be advertised with one quarter of the module's available packet memory, as in a 4xOC12 board.
  
  
• An OC-3c will be advertised with 1/16 of the module's available packet memory, as in a 16xOC-3c board or a 4xOC-3c board.
  
  

Over-allocation of Bandwidth or Queue Resources

QoS does not support over-allocation of bandwidth and queue resources. Because composite links are dynamic by nature, over-allocation is possible as members are deleted or go down.

Bandwidth and queue depth can be configured both relatively and absolutely. Bandwidth is configured relatively as a percentage; queue depth is configured relatively as time in queue. If all packet treatment parameters for a traffic assignment are configured relatively, IPriori assures that over-allocation will not take place. This is true because bandwidth percentages and time in queue will always be relative to the available resources.

Bandwidth and queue depth are configured absolutely in kilobits. If you configure either bandwidth or queue depth as an absolute value, IPriori can not assure against over-allocation of resources. If a major resource gets deleted or goes down, while absolute resource requirements for the remaining composite link remain unchanged, over-allocation of resources can take place.

There are three situations where resources change: the deletion of a member link, the failure of a member link, and the addition of a member link.

When the operator specifies that a member link be deleted, if absolute parameters were specified such that removal of the member link would cause over-allocation of either bandwidth or queue depth, the member link cannot be deleted and an error is returned. If over-allocation of resources will not result from the removal of a member link, then the member link is removed, and the QoS for the composite link is recalculated.

When a member link goes down, the bandwidth and queue depth available on the composite link changes. IPriori re-examines and re-installs the QoS configuration. If all parameters were specified relatively, or dynamic adaption does not affect the running config, this reconfiguration can happen simply. However, if some parameters were specified absolutely, and the composite link will have resources over-allocated as a result of the link going down, then appropriate scaling factors must be computed and applied.

When a member link is added or comes back up, the bandwidth and queue depth available change again. IPriori re-examines and re-installs the QoS configuration. Because resources were added, not removed, in most cases this adaption occurs simply. There may be resource issues for boards with greater link speeds than OC-48c.

If both absolute and relative configurations are present in a composite link, IPriori first attempts to prevent over-allocation by a systematic scaling back of relative resources as follows:

1. If some parameters are specified absolutely, IPriori first determines whether the resource is over-allocated. If resources are not over-allocated, then no scaling takes place.
   
   
2. If a resource is over-allocated, then relative resources are first scaled back in an attempt to maintain absolute resources.
   
   
3. If scaling of relative resources forces values below hard configured minimums, absolute resources are then scaled to levels required to prevent over-allocation.
   
   
4. If the scaling of absolute resources results in a scaling factor beneath the hard configured minimum values, the same scaling factor is applied to both relative and absolute resources.
   
   

If only absolute QoS values are configured, and over-allocation takes place, values are scaled back as required to eliminate over-allocation.

If absolute QoS values are scaled back, service degradation can be expected. Any concern for problems of over-allocating bandwidth or queue resources on a composite link can be alleviated by configuring only relative values for bandwidth and queue resources on composite links.

Initial Traffic Assignments

When a composite link is created, it is given a default and control traffic assignment according to the same rules as when a POS interface is created.

Default traffic assignment packet treatments are always configured with relative resources: bandwidth as a percentage and queue depth as time in queue. Default traffic assignments will never cause a failure to initialize a composite link.

Control traffic assignment packet treatments are also configured with relative resources by default. If you do not modify the control packet treatment with absolute values, the control traffic assignment will never fail to be created when initiating a composite link.

When a composite link is first created, it has no resources associated with it, so any traffic assignments requiring absolute resources will fail. If the control packet-treatment is re-defined by the user with any absolute bandwidth or queue depth values, automatic creation of the control traffic assignment will fail when the composite link is created. The configuration file will contain an explicit line for the composite link control traffic assignment if the traffic assignment was assigned to this composite link after the configuration of member links.

If you assigned the control traffic assignment to the composite link prior to configuring composite link members, an example of the relevant lines in the configuration file would be as follows:

router(config)packet-treatment parameter-set control bandwidth 5m ... router(config)#interface composite-link testCL router(config-if)#member-link pos 1/1/1 router(config-if)#no qos control

Because the control traffic assignment failed to initialize due to lack of resources, the configuration file specifically deletes it. Under these circumstances you can enter the desired qos control command at the CLI prompt or you can manually go in to the configuration file and replace the no qos control command line with an reassignment of your current control traffic assignment for this composite link.

If you changed the control packet treatment to absolute after creating the composite link and giving it members and then assigned the control traffic assignment to the composite link, an example of the relevant lines in the configuration file would be as follows:

router(config)packet-treatment parameter-set control bandwidth 5m .... router(config)#interface composite-link testCL router(config-if)#member-link pos 1/1/1 router(config-if)#qos control ip pcs 3 mpls psc 3 packet-treatment control

In this case, even though the initial attempt to assign the control traffic assignment to the composite link failed, because you reassigned the control traffic assignment after sufficient resources were available, the line is input into the configuration file.

NOTE Should you edit the configuration file, do not remove the reassignment of the control traffic assignment listed after the assignment of member links. This line is required for the reassignment of the control traffic assignment.

To avoid problems with control traffic assignments that contain packet treatments with absolute values:

• Create the composite link; at this time the control traffic assignment containing absolute values in the packet treatment will fail.
  
  
• Assign enough member links to assure that bandwidth and queue depth resources will meet or exceed any absolute values associated with the control traffic assignment.
  
  
• Reassign the control traffic assignment to this composite link.
  
  

With sufficient resources associated with the composite link, the control traffic assignment will now succeed.

CAUTION Since control traffic assignments determine the resources available to Avici router internal control messages, it is strongly recommended that you do not alter packet treatment values associated with it unless you are certain that you know what you are doing. If you do decide to alter packet treatments associated with the control traffic assignment, and you have or intend to configure composite links on this Avici router, assure that enough member links are associated with the composite link to provide sufficient control traffic assignment resources, and to account for any likely link failures to avoid degradation of service that may accompany scaling back of packet treatment values.

Displaying Composite Link Traffic Assignments

A show qos interface composite-link command is available to display composite link specific information.

Stepping Through A Configuration Example

The following QoS configuration example steps you through a complete configuration of an interface. This configuration example configures an interface for three traffic assignments: control, best-effort, and priority. The control traffic assignment does not change from the configuration at system initialization, except to move DSCP traffic classes 56 - 63 and MPLS traffic class 7 to the priority traffic assignment. The best-effort and priority traffic assignments take resources from both the control and default traffic assignments that exist at initialization time. The control traffic assignment assigns DSCP traffic classes 56 - 63 and EXP traffic class 7 to the newly configured priority traffic assignment. The default traffic assignment provides the remaining resources required for this configuration.

The control traffic assignment will handle Avici router internal control packets that use DSCP traffic class 48 or IP PREC 6. Because this traffic assignment handles time sensitive, must deliver traffic, bandwidth provided is large relative to the expected traffic, the time in queue is short, and RED is configured for a low likelihood of packet drop.

The priority traffic assignment will be configured to handle real-time application, must deliver packets, marked with IP and MPLS traffic class 7. Like the control traffic assignment it must be configured for high bandwidth, a short time in queue that takes into account the intended application, and low likelihood of packet drop.

The best-effort traffic assignment will be configured for applications that are not particularly time or drop sensitive and will therefore be configured for low bandwidth, relatively long times in queue and high likelihood of drop by RED.

At initialization two traffic assignments are created that hold all QoS resources for the interface. These traffic assignments are default, as shown in Figure 5-9, and control, as shown in Figure 5-10.

Traffic assignments can be configured by specifying the desired parameters, parameter sets, or packet treatments. The more unique a traffic assignment is the more likely specifying the individual parameters will actually save you time. For the purpose of this example we will assume that the same parameter groupings will be used for numerous traffic assignments. With that in mind, we will assign parameter groups to packet treatments and classifiers that provide for a more efficient entry of numerous traffic assignments.

PROCEDURE: Configuration of the necessary traffic assignments can be accomplished with the following steps:

Step 1 Configure queue and red parameter sets.

Step 2 Assign the configured parameter sets to packet treatments.

Step 3 Configure classifiers.

Step 4 Assign configured classifiers and packet treatments to the traffic assignments.

The following sections provide the details for each of these steps.

Configuring Queue and RED Parameter Sets

To configure the queue parameters for this example, there is an assumption of initial system values of 1 percent plus 79 percent excess bandwidth, and all queue depth not associated with initial control values available in the default queue. To assure that this is true, delete any configured traffic assignments for this interface with the exception of control; you can not delete the default traffic assignment.

The best effort queue parameter set will be named qB-E. The desired configuration for qB-E is:

Bandwidth	Queue-depth	Priority
10%	10ms	lowest

and you configure the parameter set with the following command lines:

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#queue parameter-set qB-E bandwidth 10% queue-depth 10ms

The best effort RED parameter set will be named rB-E. Because you want an early and high likelihood of packet drop for the best-effort traffic assignment, the desired configuration for the rB-E RED parameter set is:

min-th	max-th	max-mark-spacing
5ms	10ms	4

and you configure the parameter set with the following command line:

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#random-detect parameter-set rB-E min-th 5ms max-th 10ms max-mark-spacing 4

The priority queue parameter set will be named qP. This queue will be given absolute priority. The desired configuration for qP is:

Bandwidth	Queue-depth	Priority
69%	10ms	highest

and you configure the parameter set with the following command lines:

router(config)queue parameter-set qP bandwidth 69% queue-depth 10ms priority highest

The priority RED parameter set will be named rP. Because you want an late and low likelihood of packet drop for the priority traffic assignment, the desired configuration for the rP RED parameter set is:

min-th	max-th	max-mark-spacing
6ms	10ms	20

and you configure the parameter set with the following command line:

router(config)random-detect parameter-set rP min-th 6ms max-th 10ms max-mark-spacing 20

Assigning Queue and RED Parameter Sets to Packet Treatments

The packet treatments to be assigned to the best-effort and priority traffic assignments will be named pB-E and pP, respectively. For this example, yellow and red drop probability values for max-mark-spacing, minimum threshold, and maximum threshold will remain at default values for all packet treatments.

The following command lines assign the desired parameter sets to these packet treatments:

router(config)packet-treatment parameter-set pB-E queue-parameters qB-E random-detect-parameters rB-E router(config)end router#show packet-treatment parameter-set packet-treatment parameter-set control bandwidth 20.0000% priority lowest queue-depth 5.00ms min-th 4.00ms max-th 5.00ms max-mark-spacing 128 yellow-min-th 4.00ms yellow-max-th 5.00ms yellow-max-mark-spacing 128 red-min-th 4.00ms red-max-th 5.00ms red-max-mark-spacing 128 packet-treatment parameter-set pb-e queue-parameters qb-e random-detect-parameters rb-e default-yellow-random-detect-parameters default-red-random-detect-parameters router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)packet-treatment parameter-set pP queue-parameters qP random-detect-parameters rP router(config)end router#show packet-treatment parameter-set pP packet-treatment parameter-set pp queue-parameters qp random-detect-parameters rp default-yellow-random-detect-parameters default-red-random-detect-parameters % used by : ( none )

Configuring Classifier Parameter Sets

For this example we need to assign IP traffic classes 56 - 63 and MPLS traffic class 7 to the priority traffic assignment. This can be done directly, but we will configure two classifier groups. The first classifier group named cIPPri has the DSCP values assigned to it. The second classifier group named cEXPPri has MPLS EXP assigned to it.

We will do this by first mapping DSCP classes 56 - 63 to IP PSC 2 and mapping EXP 7 to MPLS PSC 2 before assigning the appropriate PSCs to the classifier groups

It is desirable that all IP traffic classes 0 - 47 and MPLS traffic classes 0 - 5 use the best-effort traffic assignment. We will assign DSCP levels 0 - 47 to a classifier group named cIPB-E and MPLS EXP levels 0-5 to a classifier group named cEXPB-E.

We will do this by first mapping DSCP classes 0 - 47 to IP PSC 0 and mapping EXP 0 - 5 to MPLS PSC 0 before assigning the appropriate PSCs to the classifier groups.

The following command lines first map the PSCs and then configure the appropriate classifier groups:

router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#dscp-mapping parameter-set pscIPPri router(dscp-mapping)#from 56-63 to psc 2 router(dscp-mapping)#exit router(config)#ip classifier cIPPri psc 2 router(config)#exp-mapping parameter-set pscEXPPri router(exp-mapping)#from 7 to psc 2 router(exp-mapping)#exit router(config)#mpls classifier cEXPPri psc 2 router(config)end router#show ip classifier cIPPri ip classifier cippri psc 2 used by:interface none router#show mpls classifier cEXPPri mpls classifier cexppri psc 2  used by:interface none router#config terminal Enter configuration commands, one per line. End with CNTL/Z. router(config)#dscp-mapping parameter-set pscIPB-E router(dscp-mapping)#from 0-47 to psc 0 router(dscp-mapping)#exit router(config)#ip classifier cIPB-E psc 0 router(config)#exp-mapping parameter-set pscEXPB-E router(exp-mapping)#from 0-5 to psc 0 router(exp-mapping)#exit router(config)#mpls classifier cEXPB-E psc 0 router(config)end router#show ip classifier cIPB-E ip classifier cipb-e psc 0 used by:interface none router#show mpls classifier cEXPB-E ip classifier cexpb-e psc 0 used by:interface none

Configuring Traffic Assignments

We now need to configure the two traffic assignments. The priority traffic assignment will be named qosPri, and the best-effort traffic assignment will be named qosB-E.

The following commands configure the two traffic assignments on the 1/14/1 interface:

router(config)#interface pos 1/14/1 router(config-if)#qos qosPri classifier cIPPri cEXPPri packet-treatment pP router(config-if)#qos qosB-E classifier cIPB-E cEXPB-E packet-treatment pB-E router(config-if)#end

router#show qos interface pos 1/14/1 INTERFACE pos 1/14/1 ============================================================================= Received Data Counters ============================================================================= PSC| Drop Pref | Octets | Unicast Pkts | Multicast Pkts ============================================================================= 0 | green/yellow | 0 | 0 | 0 0 | red | 0 | 0 | 0 1 | green/yellow | 0 | 0 | 0 1 | red | 0 | 0 | 0 2 | green/yellow | 0 | 0 | 0 2 | red | 0 | 0 | 0 3 | green/yellow | 0 | 0 | 0 3 | red | 0 | 0 | 0 ============================================================================= ============================================================== | Available | Allocated | ============================================================== Buffer | 69304 kb | 24053 kb| Bandwidth| 20.00% | 80.00% | ============================================================== Available WRED Drop Preferences: GREEN RED(max-mark-spacing)

============================================================== qos default ip psc 1,3 mpls psc 1,3 factory-packet-treatment ============================================================================= Configured Values | Actual Values ========================================================== Bandwidth 505129 kbps | Unavailable Percent of total 21.0000 % | Unavailable Queue-Depth 5051 kb | Unavailable Percent of total 0.00 % | Unavailable Min-th 2526 kb | Unavailable Max-th 5051 kb | Unavailable Max-Spacing 8 | Unavailable Red-Max-Spacing 8 | Unavailable ========================================================== queue bandwidth 1.0000% priority lowest queue-depth 10.00ms random-detect min-th 5.00ms max-th 10.00ms max-mark-spacing 8 yellow- random-detect yellow-min-th 5.00ms yellow-max-th 10.00ms yellow-max-mark-spacing 8 red- random-detect red-min-th 5.00ms red-max-th 10.00ms red-max-mark-spacing 8 ========================================================== RED Average Queue Length | 0 kb Instantaneous Queue Length | 0 kb   ========================================================== IPv4 Octets Sent | 0 IPv4 Unicast Packets Sent | 0 IPv4 Multicast Packets Sent | 0 Raw Octets Sent | 0 Raw Unicast Packets Sent | 0 Raw Multicast Packets Sent | 0 RED Discarded Packets - green | 0 RED Discarded Packets - red | 0 Tail drop Packets - green | 0 Tail drop Packets - red | 0

============================================================================= qos qosb-e classifier cexpb-e cipb-e packet-treatment pb-e mpls classifier cexpb-e psc 0 ip classifier cipb-e psc 0 ============================================================================= Configured Values | Actual Values ========================================================== Bandwidth 240538 kbps | Unavailable Percent of total 10.0000 % | Unavailable Queue-Depth 2405 kb | Unavailable Percent of total 0.00 % | Unavailable Min-th 1203 kb | Unavailable

Max-th 2405 kb | Unavailable Max-Spacing 4 | Unavailable Red-Max-Spacing 8 | Unavailable ========================================================== queue parameter-set qb-e bandwidth 10.0000% priority lowest queue-depth 10.00ms random-detect parameter-set rb-e min-th 5.00ms max-th 10.00ms max-mark-spacing 4 yellow-random-detect default yellow-min-th 5.00ms yellow-max-th 10.00ms yellow-max-mark-spacing 8 red-random-detect default red-min-th 5.00ms red-max-th 10.00ms red-max-mark-spacing 8 ========================================================== RED Average Queue Length | 0 kb Instantaneous Queue Length | 0 kb ========================================================== IPv4 Octets Sent | 0 IPv4 Unicast Packets Sent | 0 IPv4 Multicast Packets Sent | 0 Raw Octets Sent | 0 Raw Unicast Packets Sent | 0 Raw Multicast Packets Sent | 0 RED Discarded Packets - green | 0 RED Discarded Packets - red | 0 Tail drop Packets - green | 0    Tail drop Packets - red | 0 ============================================================================= qos qospri classifier cexppri cippri packet-treatment pp mpls classifier cexppri psc 2 ip classifier cippri psc 2 ============================================================================= Configured Values | Actual Values ==========================================================    Bandwidth 1659709 kbps | Unavailable Percent of total 69.0000 % | Unavailable Queue-Depth 16597 kb | Unavailable Percent of total 0.00 % | Unavailable

Min-th 9958 kb | Unavailable Max-th 16597 kb | Unavailable Max-Spacing 20 | Unavailable Red-Max-Spacing 8 | Unavailable ========================================================== queue parameter-set qp bandwidth 69.0000% priority highest queue-depth 10.00ms random-detect parameter-set rp min-th 6.00ms max-th 10.00ms max-mark-spacing 20 yellow-random-detect default yellow-min-th 5.00ms yellow-max-th 10.00ms yellow-max-mark-spacing 8 red-random-detect default red-min-th 5.00ms red-max-th 10.00ms red-max-mark-spacing 8

========================================================== RED Average Queue Length | 0 kb Instantaneous Queue Length | 0 kb ========================================================== IPv4 Octets Sent | 0 IPv4 Unicast Packets Sent | 0 IPv4 Multicast Packets Sent | 0 Raw Octets Sent | 0 Raw Unicast Packets Sent | 0 Raw Multicast Packets Sent | 0 RED Discarded Packets - green | 0 RED Discarded Packets - red | 0 Tail drop Packets - green | 0 Tail drop Packets - red | 0 ============================================================================= router#

There are now four traffic assignments associated with interface 1/14/1:

Figure 5-11. Configuration Example Default Traffic Assignment

Figure 5-12. Configuration Example Control Traffic Assignment

Figure 5-13. Configuration Example Priority Traffic Assignment

Figure 5-14. Configuration Example Best-Effort Traffic Assignment

This completes our configuration example.

Copyright © 2004 Avici Systems Inc.
Avici® and TSR® is a registered trademark of Avici Systems Inc.
IPriori™, Composite Links™, SSR™, QSR, and NSR® are trademarks of Avici Systems Inc.

   Source File Name: QoSConfig.fm
    HTML File Name: QoSConfig.html
    Last Updated: 05/10/04 at 17:12:40

Please email suggestions and comments to: doc@avici.com