Table Of Contents

MPLS QoS Multi-VC Mode for PA-A3

Feature Overview

Benefits

Tag Switching/MPLS Terminology

MPLS QoS Support in an MPLS Network

LSRs Used at the Edge of an MPLS Network

LSRs Used in the Core of an MPLS Network

ATM-LSRs Used in the Core of an MPLS Network

ATM Switches Used Without MPLS Enabled

Using MPLS QoS in ATM Backbone

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Configuration Tasks

Configuring Cisco Express Forwarding

Optionally Setting the MPLS Experimental Field Value

Classifying Packets

Packet Prioritization

Using Modular QoS CLI to Configure Ingress Label Switching Router

Using CAR to Configure Ingress Label Switching Router

Configuring Class of Service for IP Packets on Output

Configuring MPLS QoS in Core of ATM Network

Configuring Multi-VC Mode in MPLS-Enabled Network

Configuring Multi-VCs Using the QoS-Map Function

Configuring Queueing Functions on Router Output Interfaces

Configuring CBWFQ on Cisco 7200/7500 Series and Cisco MGX RPM-PR Router Interfaces

Configuring WRED on Cisco 7200/7500 Series or Cisco MGX RPM-PR Router Interfaces

Setting the ATM-CLP Bit on PA-A3 Interfaces

Verifying QoS Configuration on ATM Interfaces

Configuration Examples

Running IP on Customer Edge Router 1 (CE1)

Running IP on Customer Edge Router 2 (CE2)

Running MPLS on Provider Edge Router 1 (PE1)

Running MPLS on Provider Edge Router 2 (PE2)

Command Reference

Glossary

MPLS QoS Multi-VC Mode for PA-A3

---

Feature History

Release	Modification
12.2(1)T	This feature was introduced on the Cisco IOS Release 12.2(1)T.
12.2(4)T	Added support for the Cisco MGX 8850 and MGX 8950 switch with a Cisco MGX RPM-PR card.
12.2(4)T2	Support for the Cisco 7500 series routers added.
12.4(20)T	Support was removed for this feature in Cisco IOS Release 12.4(20)T and later releases.

This document describes the MPLS QoS Multi-VC Mode for PA-A3 feature being made available to customers for use with Cisco IOS Release 12.2(4)T. This document contains the following sections:

•Feature Overview

•Supported Platforms

•Supported Standards, MIBs, and RFCs

•Prerequisites

•Configuration Tasks

•Configuration Examples

•Command Reference

•Glossary

Feature Overview

MPLS quality of service (QoS) functionality enables network administrators to satisfy a wide range of requirements in transmitting IP packets through an MPLS-enabled network. Table 1 contains a brief summary of three primary MPLS QoS service offerings made available to customers through earlier Cisco IOS releases.

Table 1 MPLS QoS Services 

Service Category	Service Function	Service Description
Packet classification	Committed access rate (CAR). Packets are classified at the edge of the network before labels are assigned.	CAR uses the type of service (ToS) bits in the IP header to classify packets according to input and output transmission rates. CAR is often configured on interfaces at the edge of a network to control the flow of traffic into or out of the network. You can use CAR commands to classify or reclassify a packet.
Congestion avoidance	Weighted random early detection (WRED). Packet classes are differentiated based on drop probability.	WRED monitors network traffic to anticipate and prevent congestion at common network and internetwork bottlenecks. WRED can selectively discard lower priority traffic when an interface is congested; WRED can also provide differentiated performance characteristics for different classes of service.
Congestion management	Class-based weighted fair queueing (CBWFQ). Packet classes are differentiated based on bandwidth requirements and finite transmission delay characteristics.	CBWFQ is an automated scheduling system that ensures fair bandwidth allocation to all network traffic. CBWFQ uses weights (priorities) to determine how much bandwidth is allocated to each class of traffic.

For more information about configuring the MPLS QoS services summarized in Table 1, see the Cisco IOS Quality of Service Solutions Configuration Guide.

For complete command syntax information for configuring CAR, WRED, and CBWFQ functionality, see the Cisco IOS Quality of Service Solutions Command Reference.

In general, MPLS QoS enables the duplication of Cisco IOS IP QoS (Layer 3) functions on MPLS devices, including label edge routers (LERs), label switching routers (LSRs), and Asynchronous Transfer Mode LSRs (ATM-LSRs). MPLS QoS functions map nearly one-for-one to IP QoS functions on all types of interfaces.

The MPLS QoS Multi-VC Mode functionality described in this document significantly enhances the generalized MPLS QoS capabilities outlined in Table 1. Specifically, this new MPLS QoS feature enables users to map the experimental (EXP) field value of an MPLS label to an ATM virtual circuit (VC) to create sets of labeled virtual circuits (LVCs). Each set consists of multiple LVCs, and each LVC is treated as a member of the set.

All members of a set are associated with a label-switched path (LSP) that is set up between a pair of ATM-connected routers in the user's networking environment, and each member of a set has a different quality of service (QoS) from other members of the set.

By means of multi-VC sets, differentiated services can be provided to users of MPLS-enabled service provider networks. This service differentiation is accomplished by setting an appropriate value in the experimental (EXP) field in the header of each incoming packet as it is received by the provider edge (PE) router in the service provider network. This process is discussed in greater detail in the "Optionally Setting the MPLS Experimental Field Value" section.

The multi-VC mode functionality described in this document is used in conjunction with the Cisco Enhanced ATM Port Adapter (PA-A3) on a Cisco 7200 series router or a Cisco 7500 series router.

Benefits

The MPLS QoS Multi-VC Mode feature provides the following significant benefits:

•Ensures effective deployment of differentiated service classes in an MPLS-enabled ATM network.

•Leverages the use of existing ATM infrastructures.

Tag Switching/MPLS Terminology

Table 2 lists existing tag switching terms and the corresponding MPLS IETF terms used in this document and other related Cisco publications.

Table 2 Equivalent Tag Switching and MPLS Terms

Old Designation	New Designation
Tag bit rate (TBR)	Label bit rate (LBR)
Tag switching	Multiprotocol Label Switching
Tag (short for tag switching)	MPLS
Tag (item or packet)	Label
TDP (Tag Distribution Protocol)	LDP (Label Distribution Protocol). Cisco TDP and LDP (MPLS Label Distribution Protocol) closely parallel each other in function, but differ in detail, such as message formats and the commands required to configure the respective protocols and to monitor their operation.
Tag switched	Label switched
TFIB (tag forwarding information base)	LFIB (label forwarding information base)
TSR (tag switching router)	LSR (label switching router)
TSC (tag switch controller)	LSC (label switch controller)
ATM-TSR (ATM tag switch router)	ATM-LSR (ATM label switch router), for example, BPX 8650
TVC (tag VC, tag virtual circuit)	LVC (label VC, label virtual circuit)
TSP (tag switch path)	LSP (label switch path)
XTagATM (extended tag ATM)	XmplsATM (extended mpls ATM)

MPLS QoS Support in an MPLS Network

Several different possibilities exist for using MPLS QoS in an MPLS-enabled networking environment. The method you choose depends on whether the core of the network contains label switching routers (LSRs) or ATM label switch routers (ATM-LSRs). In either case, the QoS services provided are the same (the CAR, WRED, and CBWFQ services described in Table 1).

This section describes how LSRs and ATM-LSRs can be deployed to take advantage of QoS functions in an MPLS network:

•LSRs Used at the Edge of an MPLS Network

•LSRs Used in the Core of an MPLS Network

•ATM-LSRs Used in the Core of an MPLS Network

•ATM Switches Used Without MPLS Enabled

LSRs Used at the Edge of an MPLS Network

LSRs used at the edge of an MPLS network backbone are usually Cisco 7200 or Cisco 7500 series routers running MPLS software. Edge LSRs can operate at either the ingress or the egress side of an MPLS network, as described below.

At the ingress side of an MPLS network, LSRs process packets as follows:

1. IP packets enter the edge of the MPLS network at the edge LSR.

2. The edge LSR uses CAR or some other IP packet classification mechanism, such as Modular QoS CLI (on the Cisco series 7200 and 7500 routers only), to classify incoming IP packets and to set the IP precedence value. Note that IP packets can be received with the IP precedence value already set.

3. For each incoming packet, the LSR performs a lookup on the IP address to determine the next-hop LSR.

4. The appropriate label is inserted into the packet, and the IP precedence bits are copied into the MPLS EXP field in the label header.

5. The labeled packets are forwarded to the appropriate output interface on the LSR for processing.

6. The packets are differentiated by class according to one of the following:

–Drop probability—WRED

–Bandwidth allocation and delay—CBWFQ

In either case, the edge LSR enforces the defined differentiation by continuing to employ WRED or CBWFQ on every ingress router.

At the egress side of an MPLS network, LSRs process packets as follows:

1. MPLS-labeled packets arrive at the egress LSR from the MPLS network backbone.

2. The MPLS labels are removed from the packets and the packets are classified.

3. For each IP packet, the egress LSR performs a lookup on the IP address to determine the packet's destination; the egress LSR then forwards the packet to the appropriate destination interface for processing.

4. The packets are differentiated according to the IP precedence values and treated accordingly, depending on the WRED or CBWFQ drop probability configuration.

LSRs Used in the Core of an MPLS Network

LSRs used in the core of an MPLS network are usually Cisco 12000 series routers or Cisco 7500 series routers running MPLS software. Such routers process packets as follows:

1. Incoming MPLS labeled packets from an edge LSR (or other core device) arrive at the core LSR.

2. A table lookup is done by the core LSR to determine the next-hop LSR.

3. An appropriate label is placed (swapped) into the packet and the MPLS EXP bits are copied into the label header.

4. The labeled packet is then forwarded to the output interface of the core LSR for processing.

5. The outbound packet is differentiated by the MPLS EXP field marking and treated accordingly, depending on the WRED or CBWFQ configuration.

LSRs used in the core of an MPLS network implement the multiple LVC model. In this model, one label is assigned for each service class for each destination.

The operation of a core LSR is the same as that described in the preceding section for an edge LSR, except that the output of the core LSR is directed to an ATM interface.

WRED is used to define service classes and determine discard policy during periods of network congestion. CBWFQ is used to define the amount of bandwidth available for each class of service, enabling MPLS packets to be scheduled for transmission by traffic class during periods of network congestion.

ATM-LSRs Used in the Core of an MPLS Network

ATM-LSRs in the core of a service provider MPLS network also implement the multiple LVC model. Such devices differentiate classes using weighted fair queuing (WFQ) techniques, which cause packets to be discarded intelligently during periods of network congestion to stabilize network behavior.

By means of a Cisco 7200 or Cisco 7500 router that incorporates the PA-A3 Enhanced ATM port adapter (see Figure 2), the service provider can configure the policy map to set the cell loss priority (CLP) bit in the header of ATM cells traversing the network, based on a matched value in the EXP field of the IP packet header. To effect the setting of the CLP bit in ATM cell headers, the service provider executes a set atm-clp command on an upstream router in the service provider's MPLS network.

The service provider can choose to set the CLP bit, as described above. Based on the setting of the most significant bit of the EXP field in the IP packet header, the ATM-LSR in the core of the service provider network can use the CLP bit to preferentially discard ATM cells during periods of congestion. Thus, setting the CLP bit in the header of ATM cells traversing the service provider's network ensures consistent packet/ATM cell discard treatment among the IP routers and ATM switches in the network.

On an IP router, the WRED congestion avoidance algorithm discards packets based on one of eight different values that can be assigned using the two least significant bits (LSBs) of the EXP field in the IP packet header. The values assigned to these two bits of the EXP field are used to define the packet's class, while the most significant bit (MSB) of the field is used to differentiate whether a packet entering the service provider network from a customer is "in rate" or "out of rate." Thus, the MSB of the EXP field enables the user to establish a desired WRED profile, causing packets to be discarded more aggressively during congestion conditions, provided that such packets are marked as being "out of rate."

As a necessary precondition, IP packets can be marked on the input interface of an edge router to ensure desired packet discard behavior in the event of congestion on the router's output interface. Similarly, for ATM cells traversing the core of the service provider's network, appropriate cell discard activity can be ensured by setting the CLP bit in ATM cell headers as the cells pass through a given ATM-LSR into the core of the service provider's network.

Thus, the CLP mechanism can be used to ensure that the ATM switches in the core of the service provider's network exhibit the same discard behavior as the routers on the edge of the network. The only difference is that the edge routers deal with IP packets, while the core switches deal with ATM cells.

ATM Switches Used Without MPLS Enabled

When the core network uses ATM switches and the edge of the network uses MPLS-enabled edge LSRs, the edge LSRs are interconnected through a mesh of ATM Forum permanent virtual circuits (PVCs) involving constant bit rate (CBR) traffic, variable bit rate (VBR) traffic, or unspecified bit rate (UBR) traffic over the ATM core switches. The edge LSRs invoke WFQ on a per-VC basis to provide differentiation based on the delay characteristics of each type of QoS traffic multiplexed onto the ATM Forum PVC. Optionally, WRED can also be used on a per-VC basis to manage packet drop priority between classes when congestion occurs on the edge LSR.

Using MPLS QoS in ATM Backbone

You realize the following benefits when you use MPLS QoS in a backbone consisting of ATM switches running MPLS:

•Efficient resource allocation—Class-based weighted fair queueing (CBWFQ) is used to allocate bandwidth on a per-class and per-link basis, thereby guaranteeing a percentage of link bandwidth for network traffic.

•Connectionless environment—If you implement MPLS QoS in your ATM backbone, you can avoid configuration of end-to-end PVCs for each class of service. This is especially advantageous when you integrate MPLS QoS services in your network in conjunction with MPLS VPN services.

•Flexibility without additional overhead—MPLS QoS promotes efficient use of bandwidth, enabling unused bandwidth to be allocated for other purposes. Also, MPLS QoS requires no call setup procedures because reachability is determined and appropriate resource allocation is accomplished before MPLS QoS services are initiated.

Related Features and Technologies

You can use MPLS QoS with:

•MPLS virtual private networks (VPNs)

•Any MPLS network

Related Documents

For additional information about MPLS functionality running on Cisco routers or switches in an MPLS environment, consult the following documentation:

•MPLS Label Distribution Protocol—This document describes the use of the MPLS Label Distribution Protocol (LDP), which enables peer label switch routers (LSRs) in an MPLS network to exchange label binding information for supporting hop-by-hop forwarding along normally routed paths. LDP supports the dynamic creation of different routes between source and destination nodes in a network, thus enabling IP services to be provided efficiently over Internet backbones.

•Multiprotocol Label Switching on Cisco Routers—This document describes a generic set of CLI commands used for configuring and monitoring MPLS functionality on Cisco routers and switches in an MPLS operating environment.

•MPLS Label Switch Controller—This document describes the use of a label switch controller (LSC) that operates in conjunction with a Cisco BPX 8650 IP+ATM switch to deliver scalable integration of IP services over an ATM network. An LSC supports rapid and direct implementation of advanced IP services over ATM networks that incorporate BPX 8650 switches. MPLS combines the performance and virtual circuit capabilities of Layer 2 (data link layer) switching with the scalability of Layer 3 (network layer) routing. This delivers a solution to service providers that supports rapid growth and provides differentiated services, while leveraging the use of existing network infrastructures.

•MPLS Class of Service Enhancements—This document describes how the IP precedence field (the first three bits of the DSCP field in the IP packet header) is used to specify the class of service when a customer transmits IP packets from one site to another through a service provider network. Based on this IP precedence marking, the packet is given specified treatment for that class of service as the packet traverses the service provider network. However, if the service provider network is an MPLS network, the IP precedence bits in each packet are copied into the MPLS EXP field as the packet enters the edge of the service provider network. If the service provider wants to set an MPLS packet's class of service to a different value, based on a particular service offering, the service provider can set the MPLS EXP field rather than overwriting the value in the packet's IP precedence field. Thus, the IP packet header remains available for customer use, and the class of service for the IP packet is not changed as the packet traverses the MPLS network.

•MPLS Virtual Private Networks (VPNs)—This document describes how users can deploy and administer IPv4 Layer 3, value-added services and business applications across a public network infrastructure. Deploying business applications on a broad scale over WANs enables MPLS VPN users to reduce costs, increase revenue, and develop new business opportunities.

•Quality of Service Solutions Configuration Guide—This document describes the quality of service (QoS) features in Cisco IOS and the service models by which QoS functionality is delivered. It also outlines the benefits that come from incorporating QoS functionality in your network and describes the Cisco IOS features that ensure better services to selected network traffic in Frame Relay, ATM, Ethernet, SONET, and IP-routed networks.

•Modular Quality of Service Command Line Interface—This document describes how to configure QoS functionality using the Modular QoS CLI. Three basic QoS configuration tasks are described in this document: a) how to define a traffic class containing match criteria; b) how to create a service policy; and c) how to attach the service policy to an interface and specify the direction in which the service policy is to be applied to network traffic (either to packets entering an interface or to packets exiting an interface). The Modular QoS CLI enables users to specify traffic classes independently of QoS policies.

Supported Platforms

The MPLS Class of Service Multi-VC Mode feature is supported in Cisco IOS Release 12.2(4)T on the following platforms that are equipped with the Enhanced Asynchronous Transfer Mode (ATM) Port Adapter (ATM PA-A3):

•Cisco 7200 series routers

•Cisco 7500 series routers (supported for Cisco IOS Release 12.2(4)T3 and later)

The ATM PA-A3 is a single-port, single- and dual-wide ATM port adapter used with the Cisco 7200 and 7500 series routers. It is designed with a high-performance, dual segmentation and reassembly (SAR) architecture with local buffer memory.

A Cisco 7200 series router or a Cisco 7500 series router equipped with an ATM PA-A3 port adapter can interoperate in multi-VC mode with the following Cisco ATM switches located in the core of an MPLS network:

•Cisco LS1010 ATM switch

•Cisco Catalyst 8540 MSR

•Cisco BPX 8650 series of ATM switches

•Cisco MGX 8800 series of ATM switches

The MPLS QoS Multi-VC Mode feature is also supported on the Cisco MGX 8850 switch with the Cisco MGX 8850 Route Processor Module (RPM-PR).

Determining Platform Support Through Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Feature Navigator. Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image.

To access Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Feature Navigator home page at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIBs are supported by this feature.

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites

To use MPLS QoS to full advantage in your network, the following functionality must be supported:

•Multiprotocol Label Switching (MPLS)—MPLS is the standardized label switching protocol defined by the Internet Engineering Task Force (IETF).

•Cisco Express Forwarding (CEF)—CEF is an advanced Layer 3 IP switching technology that optimizes performance and scalability in networks that handle large volumes of traffic and exhibit dynamic traffic patterns.

•Asynchronous Transfer Mode (ATM)—ATM signaling support is required if you use ATM interfaces in your network.

---

Note If you use only packet interfaces in your network, ATM functionality is not required.

---

•Quality of service (QoS) features supported in this release:

–MPLS QoS Multi-VC mode feature—This feature provides QoS functionality on ATM interfaces in a service provider MPLS-enabled network. Such a network incorporates ATM interfaces on the edge of the network, as well as ATM interfaces within the core of the network.

IP packets travel through the core of an MPLS-enabled service provider network by means of multiple, label switched paths (LSPs), also known as label virtual circuits (LVCs), that are automatically established for each IP destination prefix. A standard IP access control list (ACL) is used to specify the number of traffic classes per IP destination, and hence the number of LVCs that will be created.

If there are multiple, equal cost paths through an ATM network, it is possible that each LVC relating to the same destination could take a different path through the network, because each LVC could be set up along an alternate, equal cost path. For example, if four equal cost paths exist through the network, the first LVC would be set up along the first path, the second LVC would be set up along the second path, and so forth. There is no guarantee, however, that each LVC would be set up along a parallel path in the network, nor is there any requirement that each LVC be set up in such a manner.

Each MPLS-enabled ATM interface in the service provider network, including each ATM edge interface and each ATM router/switch interface within the core of the network, provides QoS support in a manner similar to that provided for IP packet interfaces.

IP packets transiting the service provider's MPLS-enabled network are treated with the same priorities as afforded to ATM traffic. Accordingly, MPLS QoS multi-VC mode functionality is virtually indistinguishable from the QoS support provided for IP packet interfaces.

–Class-based weighted fair queueing (CBWFQ)—CBWFQ is a dynamic scheduling method that allocates bandwidth fairly to all network traffic. CBWFQ applies priorities, or weights, to traffic to classify the traffic into flows and determine how much bandwidth to allow each flow. WFQ moves interactive traffic to the front of a queue to reduce response time and fairly shares the remaining bandwidth among high-bandwidth flows.

–Weighted random early detection (WRED)—WRED is a congestion avoidance mechanism that extends random early detection (RED) functionality by allowing different discard priorities or classes of service to be configured per the MPLS experimental (EXP) field in the MPLS packet header. The EXP field value defines the relative importance or priority of an MPLS packet. The WRED mechanism uses the EXP field values to classify packets into any one of eight different discard priorities or classes of service to avoid congestion in an MPLS network.

Configuration Tasks

The following sections describe configuration tasks for using the MPLS QoS multi-VC mode feature:

•(Required) Configuring Cisco Express Forwarding

•(Optional) Optionally Setting the MPLS Experimental Field Value

–Classifying Packets

–Packet Prioritization

–Using Modular QoS CLI to Configure Ingress Label Switching Router

–Using CAR to Configure Ingress Label Switching Router

•(Optional) Configuring Class of Service for IP Packets on Output

•(Required) Configuring MPLS QoS in Core of ATM Network

–(Required) Configuring Multi-VC Mode in MPLS-Enabled Network

–(Optional) Configuring Multi-VCs Using the QoS-Map Function

•(Optional) Configuring Queueing Functions on Router Output Interfaces

–Configuring CBWFQ on Cisco 7200/7500 Series and Cisco MGX RPM-PR Router Interfaces

–Configuring WRED on Cisco 7200/7500 Series or Cisco MGX RPM-PR Router Interfaces

•(Optional) Verifying QoS Configuration on ATM Interfaces

Configuring Cisco Express Forwarding

Cisco Express Forwarding (CEF) is a prerequisite for using MPLS in the core of a network; CEF must be running on all the routers in the MPLS network. To enable CEF on the routers in an MPLS network, issue the appropriate command on each device, as indicated in Table 3.

Table 3 Cisco Express Forwarding Configuration Commands

For This Device ...	Enter This Command ...
Cisco 7200 series router	ip cef
Cisco 7500 series router	ip cef distributed

Optionally Setting the MPLS Experimental Field Value

Figure 1 is a representation of an MPLS service provider network that connects two hosts of a customer's IP network. This network topology provides a framework for this section (and subsequent sections) in which the configuration tasks associated with using the MPLS QoS multi-VC mode feature are described.

Figure 1 MPLS Network Connecting Hosts in an IP Network

The ability to optionally set the MPLS experimental (EXP) field of the label header upon entry of a customer IP packet into an MPLS network has no direct connection to the MPLS QoS multi-VC mode feature per se. However, if the service provider wants to preserve the IP precedence value in the IP type-of-service (TOS) byte in the header of an incoming IP packet for any reason (such as for managing queues or selecting LVCs based on the value of the EXP field), the ability to manipulate the EXP field provides such flexibility.

By default, the IP precedence field in the header of incoming IP packets is copied into the MPLS EXP field in the label header upon entry of IP packets into the service provider's MPLS network. This default action enables IP packets to be differentiated into queues (for congestion management purposes) and to be directed to appropriate LVCs (for transmission of customer data through the MPLS network). Thus, if the IP precedence field is set, either on the edge router in the MPLS network or on some other upstream device, the incoming customer IP packets are assured of using the appropriate LVCs for data transport through the service provider network.

Optionally, you can set the MPLS EXP field value in customer IP packets arriving at the provider edge router (the PE1 ingress label switching router in Figure 1) by means of modular QoS CLI commands or CAR commands executed on that edge router. This action establishes a specified level of service for customer data traversing the service provider's MPLS network, while, at the same time, preserving the value of the IP precedence field in the incoming customer IP packets.

By assigning any one of eight different values to the EXP field (see the "Classifying Packets" section), you can mark each incoming IP packet for transport through the service provider network according to such packet attributes as packet rate and packet type.

By classifying packets, you can establish the relative priority of packets for discard purposes if congestion is experienced within the service provider network. The "Packet Prioritization" section discusses in more detail the attributes used in determining the relative priority of packets for congestion management purposes.

Classifying Packets

To classify IP packets, the PE1 ingress label switching router (LSR) in the service provider network (see Figure 1) must be appropriately configured. When so configured, customer IP packets received at the ingress router are propogated through the service provider network as MPLS packets.

You can use either of two methods to classify IP packets at the ingress LSR in the service provider's MPLS network:

•Modular QoS CLI (a newer and more flexible method)—Use this method if you do not want to consider the rate of receipt of IP packets at the ingress LSR.

•CAR—Use this method if you do want to consider the rate of receipt of IP packets at the ingress LSR.

–If a packet conforms to the service level agreement (SLA) between the service provider and the customer (that is, if the incoming IP packet is "in-rate"), the service provider gives the packet preferential treatment during transit through the MPLS network under congestion conditions.

–If a packet does not conform to the SLA (that is, if the incoming IP packet is "out-of-rate") and congestion occurs in the service provider network, the service provider can discard the packet altogether or give the packet less preferential treatment relative to other network traffic.

Packet Prioritization

During Step 1 of the configuration process (described in the "Using Modular QoS CLI to Configure Ingress Label Switching Router" section and the "Using CAR to Configure Ingress Label Switching Router" section), customer IP packets are classified according to the following attributes:

•Source address

•Destination address

•Port

•Protocol identification

•Class of service field

Based on one or more of the above attributes, packets can be identified as Voice over IP (VoIP) traffic or File Transfer Protocol (FTP) traffic. This packet classification/marking process determines the packet's relative priority during transit through the service provider network, particularly amidst network congestion conditions.

The SLA in effect for each customer of the service provider network specifies how much bandwidth the service provider agrees to make available to each customer. To comply with the agreement, the customer must not exceed a specified traffic rate. Packets are considered to be either in-rate or out-of-rate per the SLA. Thus, during periods of congestion in the service provider network, the potential exists for out-of-rate packets to be discarded more aggressively.

Using Modular QoS CLI to Configure Ingress Label Switching Router

To use the modular QoS CLI to configure the ingress LSR (PE1 in Figure 1) appropriately for multi-VC mode functionality, perform the following steps:

---

Step 1 Configure a class map to classify IP packets according to their IP precedence.

Step 2 Configure a policy map to mark MPLS packets (that is, to write their classification into the MPLS EXP field).

Step 3 Configure the input interface of the ingress router to attach the service policy.

---

The following sections describe in detail how to accomplish the generalized steps outlined above.

Configuring a Class Map to Classify IP Packets

To configure a class map on the ingress LSR, use the following commands:

	Command	Purpose
Step 1	Router(config)# class-map class-map name	Specifies the class map to which incoming IP packets will be matched.
Step 2	Router(config-c-map)# match criteria	Specifies the packet characteristics that will be matched to the class.
Step 3	Router(config-c-map)# end	Exits the class map configuration mode.

In the following example, all packets that contain IP precedence 4 are matched by the class-map name IP_prec4:

Router(config)# class-map IP_prec4 
Router(config-c-map)# match ip precedence 4 
Router(config-c-map)# end

Configuring a Policy Map to Mark MPLS EXP Field

To configure a policy map to mark the MPLS EXP field in IP packets arriving at the ingress LSR, use the following commands:

	Command	Purpose
Step 1	Router(config)# policy-map policy-map name	Creates a policy map that can be attached to one or more ingress interfaces to specify a service policy.
Step 2	Router(config-p-map)# class class-map name	Specifies the name of the class map previously designated by means of the class-map command in the table above.
Step 3	Router(config-p-map-c)# set mpls experimental value	Designates the value to which the MPLS EXP bits will be set if the incoming IP packets match the specified policy map.
Step 4	Router(config-p-map-c)# end	Exits the policy map configuration mode.

In the following example, the MPLS EXP field of each IP packet that matches class-map IP_prec4 is set to a value of 5:

Router(config)# policy-map set_experimental_5 
Router(config-p-map)# class IP_prec4 
Router(config-p-map-c)# set mpls experimental 5 
Router(config-p-map-c)# end

Configuring Input Interface to Attach Service Policy

To configure the input interface of the ingress LSR to attach the service policy, use the following steps:

	Command	Purpose
Step 1	Router(config)# interface name	Designates the input interface.
Step 2	Router(config-if)# service-policy input policy-map name	Attaches the specified policy map to the input interface of the ingress device.
Step 3	Router(config-if)# end	Exits the interface configuration mode.

In the following example, the service policy set_experimental_5 is attached to the specified Ethernet input interface (et 1/0/0):

Router(config)# interface et 1/0/0 
Router(config-if)# service-policy input set_experimental_5 
Router(config-if)# end

Using CAR to Configure Ingress Label Switching Router

To use CAR to configure the ingress LSR (PE1 in Figure 1) for multi-VC mode functionality, perform the following steps:

---

Step 1 Configure an IP rate-limit access list for classifying IP packets according to their IP precedence.

Step 2 Configure a rate-limit on an input interface to mark the MPLS packets (to write the packet's classification into the MPLS EXP field).

---

The following sections describe in detail how to accomplish the generalized steps outlined above.

Configuring Rate-Limit Access List for Classifying IP Packets

To configure a rate-limit access list for classifying IP packets arriving at the ingress LSR, perform the following steps:

	Command	Purpose
Step 1	Router(config)# access-list rate-limit acl-index precedence	Specifies the criteria to be matched.
Step 2	Router(config)# end	Exits the global configuration mode.

In the following example, all packets containing IP precedence value 4 are matched by the rate-limit access list 24:

Router(config)# access-list rate-limit 24 4 
Router(config)# end

Configuring Rate-Limit on Input Interface to Mark MPLS Packets

To configure a rate-limit on an input interface to mark MPLS packets on the ingress LSR, perform the following steps:

	Command	Purpose
Step 1	Router(config)# interface name	Designates the input interface.
Step 2	Router(config-if)# rate-limit input [access-group [rate-limit]acl-index] bps burst-normal burst-max conform-action set-mpls-exp-transmit exp exceed-action set-mpls-exp-transmit exp	Specifies the actions to be taken on IP packets during label imposition.
Step 3	Router(config-if)# end	Exits the interface configuration mode.

In the following example, the MPLS EXP field is set to 4 on output of packets if input IP packets match the access-list and conform to the packet rate. The MPLS EXP field is set to 0 if packets match access list 24 and exceed the input rate.

Router(config)# interface et 1/0/0 
Router(config-if)# rate-limit input access-group rate-limit 24 8000 8000 8000 
conform-action set-mpls-exp-transmit 4 exceed-action set-mpls-exp-transmit 0 
Router(config-if)# end

Configuring Class of Service for IP Packets on Output

The class of service for IP packets exiting the service provider network is determined by information carried in the header of each IP packet. For configuration details, refer to the Cisco IOS Quality of Service Solutions Configuration Guide.

Configuring MPLS QoS in Core of ATM Network

The following sections describe how to configure MPLS QoS in the core of an ATM network.

Configuring Multi-VC Mode in MPLS-Enabled Network

To configure multi-VC mode in an MPLS-enabled network, issue the following commands:

	Command	Purpose
Step 1	Router(config)# interface type number mpls	Configures an ATM MPLS subinterface.
Step 2	Router(config-subif)# ip unnumbered Loopback0	Assigns an IP address to the subinterface.
Step 3	Router(config-subif)# mpls atm multi-vc	Enables ATM multi-VC mode on the subinterface. This step results in the creation of the default QoS map shown in Table 4.
Step 4	Router(config-subif)# mpls ip	Enables MPLS on the ATM subinterface.
Step 5	Router(config-subif)# mpls label-protocol ldp	Configures LDP, rather than TDP, as the label distribution protocol.

If you do not configure a QoS map and apply it to a destination by means of a prefix map, enabling the ATM multi-VC mode on a subinterface (as done in Step 3 above) results in the creation of the default QoS map shown in Table 4. This default action creates four LVCs (Available, Standard, Premium, and Control) for each destination, and the two least significant bits of the EXP field determine the LVC to which the IP packets will be directed.

Table 4 Default QoS Map

EXP Field Value	LVC
0	Available
1	Standard
2	Premium
3	Control
4	Available
5	Standard
6	Premium
7	Control

Configuring Multi-VCs Using the QoS-Map Function

If you choose to not use the default QoS map for configuring label VCs, you can configure fewer label VCs by using the QoS map function. To use this function, issue the following commands:

	Command	Purpose
Step 1	Router(config)# mpls cos-map cos-map number	Creates a QoS map.
Step 2	Router(config-tag-cos-map)# class 1 premium	Enters the cos-map submode and maps traffic classes to LVCs. The QoS map created by this step assigns class 1 traffic (standard) to share the same LVC as class 2 traffic (premium). The default values for assigning traffic classes to the QoS map range from 0 to 3, as follows: Class 0—Available Class 1—Standard Class 2—Premium Class 3—Control The class of a packet is determined by the two least significant bits of the EXP field in the packet header.
Step 3	Router(config-tag-cos-map)# exit	Exits the MPLS QoS map submode.
Step 4	Router(config)# access-list access-list-number permit destination	Creates an access list to control traffic going to the specified destination address.
Step 5	Router(config)# mpls prefix-map prefix-map access-list access-list cos-map cos-map	Configures the router to use a specified QoS map when an MPLS destination prefix matches the specified access list.

Configuring Queueing Functions on Router Output Interfaces

Configuring CBWFQ on Cisco 7200/7500 Series and Cisco MGX RPM-PR Router Interfaces

To configure class-based weighted fair queueing (CBWFQ) functionality on a Cisco 7200 or 7500 series router interface or on the router interface of a Cisco MGX Route Processor Module (RPM-PR) in the Cisco MGX 8850 or 8950 switch, issue the following commands:

	Command	Purpose
Step 1	Router(config)# class-map class-map-name	Creates a class-map.
Step 2	Router(config-cmap)# match mpls experimental 5	Enters the class-map submode and determines what packets this class-map should match on.
Step 3	Router(config-cmap)# policy-map policy-map-name	Creates a policy-map.
Step 4	Router(config-pmap)#class class-map-name	Calls the previously created class-map.
Step 5	Router(config-pmap-c)# bandwidth percent 35	Configures the policy-map to have CBWFQ acting on packets matching the previously created class-map.
Step 6	Router(config)# interface type number	Specifies the interface type and number.
Step 7	Router(config-if)# service-policy output policy-map-name	Assigns the policy-map on the interface.

Configuring WRED on Cisco 7200/7500 Series or Cisco MGX RPM-PR Router Interfaces

To configure weighted random early detection (WRED) functionality on a Cisco 7200 or 7500 series router interface or on the router interface of a Cisco MGX Route Processor Module (RPM-PR) in the Cisco MGX 8850 or 8950 switch, issue the following commands:

	Command	Purpose
Step 1	Router(config)# class-map class-map-name	Creates a class-map.
Step 2	Router(config-cmap)# match mpls experimental 5	Enters the class-map submode and determines what packets this class-map should match on.
Step 3	Router(config-cmap)# policy-map policy-map-name	Creates a policy-map.
Step 4	Router(config-pmap)# class class-map-name	Calls the previously created class-map.
Step 5	Router(config-pmap-c)# bandwidth percent 35	Configures the policy-map to have CBWFQ acting on packets matching the previously created class-map.
Step 6	Router(config-pmap-c)# random-detect	Configures the policy-map to have WRED acting on packets matching the class-map.
Step 7	Router(config)# interface type number	Specifies the interface type and number.
Step 8	Router(config-if)# service-policy output policy-map-name	Assigns the policy-map on the interface.

Setting the ATM-CLP Bit on PA-A3 Interfaces

To set the atm-clp bit in ATM cells exiting from a PA-A3 (Enhanced ATM Port Adapter) interface incorporated into a Cisco 7200 or Cisco 7500 router, issue the following commands on the router.

	Command	Purpose
Step 1	Router(config)# class-map class-map-name	Creates a class-map.
Step 2	Router(config-cmap)# match mpls experimental 5	Enters the class-map submode and determines what packets this class-map should match on.
Step 3	Router(config-cmap)# policy-map policy-map-name	Creates a policy-map.
Step 4	Router(config-pmap)# class class-map-name	Calls the previously created class-map.
Step 5	Router(config-pmap-c)# set atm-clp	Causes all MPLS packets matching this class to have the CLP bit set in the outgoing ATM cells.
Step 6	Router(config)# interface type number	Specifies the interface type and number.
Step 7	Router(config-if)# service-policy output policy-map-name	Assigns the policy-map on the interface.

Verifying QoS Configuration on ATM Interfaces

To verify MPLS QoS configuration on ATM interfaces, use the following commands:

	Command	Purpose
Step 1	Router# show mpls interfaces interfaces	Displays detailed information about label switching interfaces.
Step 2	Router# show mpls cos-map	Displays the QoS map used to assign LVCs.
Step 3	Router# show mpls prefix-map	Displays the prefix map used to assign a QoS map to network prefixes.

Configuration Examples

Figure 2 is a sample network topology for which MPLS QoS multi-VC mode functionality has been configured for Cisco 7200 series routers in a customer IP network and a service provider MPLS network. IP and MPLS configuration examples for the following network components are provided in this section:

•Running IP on Customer Edge Router 1 (CE1)

•Running IP on Customer Edge Router 2 (CE2)

•Running MPLS on Provider Edge Router 1 (PE1)

•Running MPLS on Provider Edge Router 2 (PE2)

Figure 2 Configuring MPLS QoS Multi-VC Mode Functionality on IP and MPLS Network Devices

Running IP on Customer Edge Router 1 (CE1)

The following sample output shows how IP has been configured to run on customer edge router 1 (CE1) shown in Figure 2:

interface Loopback0

ip address 11.11.11.11 255.255.255.255

!

interface POS3/2

ip address 31.0.0.1 255.0.0.0

no ip directed-broadcast

crc 16

clock source internal

!

router bgp 101

no synchronization

bgp log-neighbor-changes

network 11.11.11.11 mask 255.255.255.255

network 31.0.0.0

redistribute connected

redistribute static

neighbor 31.0.0.2 remote-as 100

neighbor 31.0.0.2 advertisement-interval 5

no auto-summary

Running IP on Customer Edge Router 2 (CE2)

The following sample output shows how IP has been configured to run on the customer edge router 2 (CE2) shown in Figure 2:

interface Loopback0

ip address 10.10.10.10 255.255.255.255

!

interface POS3/2

ip address 31.0.0.2 255.0.0.0

 no ip directed-broadcast

 crc 16

!

router ospf 100

log-adjacency-changes

auto-cost reference-bandwidth 10000

redistribute bgp 102

passive-interface POS3/2

passive-interface POS5/0

network 10.0.0.0 0.255.255.255 area 100

!

router bgp 102

no synchronization

bgp log-neighbor-changes

network 10.0.0.0

network 31.0.0.0

redistribute connected

redistribute static

redistribute ospf 100

neighbor 31.0.0.1 remote-as 100

neighbor 31.0.0.1 advertisement-interval 5

no auto-summary

Running MPLS on Provider Edge Router 1 (PE1)

The following sample output shows how MPLS has been configured to run on provider edge router 1 (PE1) shown in Figure 2:

ip cef

!

class-map match-all exp0 

match mpls experimental 0 4 

class-map match-all exp1 

match mpls experimental 1 5 

class-map match-all exp2 

match mpls experimental 2 6 

class-map match-all exp3 

match mpls experimental 3 7 

class-map match-all acl101 

match access-group 101

class-map match-all acl102 

match access-group 102

!

policy-map atm_output 

class exp0 

bandwidth percent 10 

class exp1 

bandwidth percent 25 

class exp2 

bandwidth percent 20 

class exp3 

bandwidth percent 20 

! 

policy-map input_int

class acl101 

police cir 64000 bc 2000 conform-action set-mpls-exp-transmit 2 exceed-action 
set-mpls-exp-transmit 1 

class acl102 

police cir 32000 bc 1500 conform-action set-mpls-exp-transmit 3 exceed-action drop 

!

ip vrf test1

rd 100:1

route-target export 100:1

route-target import 100:1

route-target import 100:2

no ip dhcp-client network-discovery

no mgcp timer receive-rtcp

call rsvp-sync

!

interface Loopback0

ip address 12.12.12.12 255.255.255.255

!

interface ATM1/0.1 tag-switching

ip unnumbered Loopback0

service-policy output atm_output

no ip mroute-cache

tag-switching atm multi-vc

tag-switching atm vpi 2-5

tag-switching ip

!

interface POS 6/0

service-policy input input_int 

ip vrf forwarding test1

ip address 31.0.0.2 255.0.0.0

clock source internal

!

router ospf 100

log-adjacency-changes

redistribute connected subnets

passive-interface POS6/0

network 12.0.0.0 0.255.255.255 area 100

!

router bgp 100

no synchronization

no bgp default ipv4-unicast

bgp log-neighbor-changes

redistribute static

neighbor 14.14.14.14 remote-as 100

neighbor 14.14.14.14 update-source Loopback0

 !

address-family ipv4 vrf test1

redistribute connected

neighbor 30.0.0.1 remote-as 101

neighbor 30.0.0.1 activate

neighbor 30.0.0.1 advertisement-interval 5

no auto-summary

no synchronization

exit-address-family

 !

address-family vpnv4

neighbor 14.14.14.14 activate

neighbor 14.14.14.14 send-community extended

bgp scan-time import 5

exit-address-family

!

access-list 101 permit ip host 11.11.11.11 any

access-list 102 permit ip host 31.0.0.1 any

Running MPLS on Provider Edge Router 2 (PE2)

The following sample output shows how MPLS has been configured to run on provider edge router 2 (PE2) shown in Figure 2:

ip cef

!

class-map match-all exp0 

match mpls experimental 0 4 

class-map match-all exp1 

match mpls experimental 1 5 

class-map match-all exp2 

match mpls experimental 2 6 

class-map match-all exp3 

match mpls experimental 3 7 

class-map match-all acl101 

match access-group 101

class-map match-all acl102 

match access-group 102

!

policy-map atm_output 

class exp0 

bandwidth percent 10 

class exp1 

bandwidth percent 25 

class exp2 

bandwidth percent 20 

class exp3 

bandwidth percent 20 

! 

policy-map input_int

class acl101 

police cir 64000 bc 2000 conform-action set-mpls-exp-transmit 2 exceed-action 
set-mpls-exp-transmit 1 

class acl102 

police cir 32000 bc 1500 conform-action set-mpls-exp-transmit 3 exceed-action drop 

!

ip vrf test2

rd 100:2

route-target export 100:2

route-target import 100:2

route-target import 100:1

no ip dhcp-client network-discovery

no mgcp timer receive-rtcp

call rsvp-sync

!

interface Loopback0

ip address 14.14.14.14 255.255.255.255

!

interface ATM5/0.1 tag-switching

ip unnumbered Loopback0

service-policy output atm_output

no ip mroute-cache

tag-switching atm multi-vc

tag-switching atm vpi 2-5

tag-switching ip

!

interface POS6/0

service-policy input input_int 

ip vrf forwarding test2

ip address 31.0.0.1 255.0.0.0

clock source internal

!

router ospf 100

log-adjacency-changes

auto-cost reference-bandwidth 10000

redistribute connected subnets

passive-interface POS6/0

network 14.0.0.0 0.255.255.255 area 100

!

router bgp 100

no synchronization

no bgp default ipv4-unicast

bgp log-neighbor-changes

redistribute static

neighbor 12.12.12.12 remote-as 100

neighbor 12.12.12.12 update-source Loopback0

!

address-family ipv4 vrf test2

redistribute connected

neighbor 31.0.0.2 remote-as 102

neighbor 31.0.0.2 activate

neighbor 31.0.0.2 advertisement-interval 5

no auto-summary

no synchronization

exit-address-family

!

address-family vpnv4

neighbor 12.12.12.12 activate

neighbor 12.12.12.12 send-community extended

bgp scan-time import 5

exit-address-family

!

access-list 101 permit ip host 10.10.10.10 any

access-list 102 permit ip host 31.0.0.2 any 

Command Reference

The following commands are introduced or modified in the feature or features documented in this module. For information about these commands, see the Cisco IOS Multiprotocol Label Switching Command Reference at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_book.html. For information about all Cisco IOS commands, go to the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or to the Cisco IOS Master Commands List.

•access-list rate-limit

•debug mpls atm-cos

•match mpls experimental

•mpls atm multi-vc

•mpls cos-map

•mpls prefix-map

•rate-limit

•set atm-clp

•set mpls experimental

•show mpls cos-map

•show mpls prefix-map

Glossary

ATM edge LSR—A router that is connected to the ATM-LSR cloud through an LSC-ATM interface. The ATM edge LSR adds labels to unlabeled packets and strips labels from labeled packets.

ATM-LSR—A label switch router with a number of LSC-ATM interfaces. The router forwards ATM cells among these interfaces using labels carried in the VPI/VCI field.

CAR—Committed access rate (packet classification). CAR is the main feature supporting packet classification. CAR uses the type of service (ToS) bits in the IP header to classify packets. You can use the CAR classification commands to classify or reclassify a packet.

Class-based weighted fair queueing (CBWFQ)—CBWFQ extends standard WFQ functionality to provide support for user-defined traffic classes. For CBWFQ, you define traffic classes based on match criteria which include protocols, access control lists (ACLs), and input interfaces. Packets satisfying match criteria for a class constitute the traffic for that class. A queue is reserved for each class, and the traffic belonging to a class is directed to the queue for that class.

IP precedence—A 3-bit value in the ToS byte that is used for assigning precedence to IP packets.

label—A short, fixed-length construct that tells switching nodes how to forward data (packets or cells) in a network.

label-controlled ATM interface (LC-ATM interface)—An interface on a router or switch that uses label distribution procedures to negotiate label VCs.

label edge router (LER)—A router that performs label imposition at thepoint of ingress in a network.

label imposition—The process of adding the first label on a packet.

label switch—A node that forwards units of data (packets or cells) on the basis of labels carried in the packets or cells.

label switch path (LSP)—An LSP results from a series of hops (Router 0...Router n) through which a packet travels from R0 to Rn by means of label switching mechanisms. A label-switched path can be determined dynamically (based on normal routing mechanisms), or it can be defined explicitly.

label-switched path (LSP) tunnel—A configured connection between two routers, in which label switching techniques are used for packet forwarding.

label switching router (LSR)—A Layer 3 router that forwards packets based on the value of a label encapsulated in each packet.

label VC (LVC)—An ATM virtual circuit that is set up through ATM LSR label distribution procedures.

LBR—Label bit rate. A service category defined for label-VC traffic. Link and per-VC bandwidth sharing can be controlled by relative bandwidth configuration at the edge of the network and each switch along a label-VC. No ATM traffic-related parameters are specified.

LDP—Label Distribution Protocol. The protocol used to distribute label bindings to LSRs.

LFIB—Label forwarding information base. The data structure used by switching functions to switch labeled packets.

LIB—Label information base. A database used by an LSR to store labels learned from other LSRs, as well as labels assigned by the local LSR.

MPLS—Multiprotocol Label Switching. An emerging industry standard that defines support for MPLS forwarding of packets along normally routed paths (sometimes called MPLS hop-by-hop forwarding).

QoS—Quality of service. A feature that provides scalable, differentiated types of service across an MPLS network.

RED—Random early detection. A congestion avoidance algorithm in which a small percentage of packets are dropped automatically when congestion is detected in the network and before the queue in question overflows completely.

ToS bits—Type of service bits. A byte in the IPv4 packet header.

traffic engineering—The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been applied.

traffic engineering tunnel—A label-switched tunnel that is used for traffic engineering. Such a tunnel is set up through means other than normal Layer 3 routing; the tunnel is used to direct traffic over a path different from the one that Layer 3 routing would otherwise cause the tunnel to take.

VPN—Virtual private network. Enables IP traffic to use tunneling to transport data securely over a public TCP/IP network.

WRED—Weighted random early detection. A variant of RED in which the probability of a packet being dropped depends on either its IP precedence, CAR marking, or MPLS class of service (as well as other factors in the RED algorithm).

WFQ—Weighted fair queueing. A queue management algorithm that provides a certain fraction of link bandwidth to each of several queues, based on a relative bandwidth applied to each of the queues.

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2007 Cisco Systems, Inc. All rights reserved.