|
|
This chapter describes MPLS Class of Service (CoS) with the use of the BPX 8650 ATM label switch router (ATM LSR). A summary example is provided for configuring BPX 8650 ATM LSRs, their associated LSCs (6400, 7200, or 7500 series), and edge label switch routers:
For an overview of design issues, see Chapter 3, "Quality of Service in MPLS Networks."
For additional information, refer to Cisco 6400, 7200, or 7500 series router and MPLS-related IOS documentation. Refer to release notes for supported features.
The MPLS CoS feature enables network administrators to provide differentiated types of service across an MPLS Switching network. Differentiated service satisfies a range of requirements by supplying the particular kind of service specified for each packet by its CoS. Service can be specified in different ways---for example, through use of the IP precedence bit settings in IP packets or in source and destination addresses.
The MPLS CoS feature can be used optionally with MPLS Virtual Private Networks. MPLS CoS can also be used in any MPLS switching network.
In supplying differentiated service, MPLS CoS offers packet classification, congestion avoidance, and congestion management. Table 6-1 lists these functions and the means by which they are delivered.
| Service | CoS Function | 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 in order to control traffic into or out of the network. You can use CAR classification 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, trying to anticipate and prevent congestion at common network and internetwork bottlenecks. WRED can selectively discard lower priority traffic when an interface begins to get congested. It can also provide differentiated performance characteristics for different classes of service. |
Congestion management | Weighted fair queueing (WFQ). Packet classes are differentiated based on bandwidth and bounded delay. | WFQ is an automated scheduling system that provides fair bandwidth allocation to all network traffic. WFQ classifies traffic into conversations and uses weights (priorities) to determine how much bandwidth each conversation is allocated, relative to other conversations. |
MPLS CoS lets you duplicate Cisco IOS IP CoS (Layer 3) features as closely as possible in MPLS switching devices, including label switching routers (LSRs), edge LSRS, and ATM label switching routers (ATM LSRs). MPLS CoS functions map nearly one-for-one to IP CoS functions on all interface types.
For more information on configuration of the CoS functions (CAR, WRED, and WFQ), refer to the Cisco IOS Class of Service for Tag Switching Feature Guide, and the Cisco IOS Quality of Service Solutions Configuration Guide.
For complete command syntax information for CAR, WRED, and WFQ, refer to the Cisco IOS Quality of Service Solutions Command Reference.
For additional information on BPX 8650 CLI commands, refer to the Cisco WAN Switch Command Reference.
To use the MPLS CoS feature, your network must be running these Cisco IOS features:
Also, the BPX 8650 must have:
In IP+ATM networks, MPLS uses predefined sets of labels for each service class, so switches automatically know which traffic requires priority queuing. A different label is used per destination to designate each service class (see Figure 6-1).
There can be up to four labels per IP source-destination. Using these labels, core LSRs implement class based WFQ to allocate specific amounts of bandwidth and buffer to each service class. Cells are queued by class to implement latency guarantees.
On a Cisco IP+ATM LSR, the weights assigned to each service class are relative, not absolute. The switch can therefore borrow unused bandwidth from one class and allocate it to other classes according to weight. This scenario enables very efficient bandwidth utilization. The class-based WFQ solution ensures that customer traffic is sent whenever unused bandwidth is available, whereas ordinary ATM VCs drop cells in oversubscribed classes even when bandwidth is available.
Packets have their precedence bits in the Type of Service field of the IP header, set at either the host or an intermediate router, which could be the edge label switch router (LSR). The precedence bits define a Class of Service (CoS) 0-3, corresponding for to premium, standard, available, or control, for example.
To establish CoS operation when the BPX and the associated LSC router (6400, 7200, or 7500 series) are initially configured, the binding type assigned each LVC interface on the BPX is configured to be multiple LVCs.
Then under the routing protocol (OSPF, for example), four LVCs are set up across the network for each IP source to destination requirement. Depending on the precedence bits set in the packets that are received by the edge LSR, the packet ATM cells that are sent to the ATM LSR will be one four classes (as determined by the cell label, that is, VPI.VCI). Furthermore, two subclasses are distinguishable within each class by the use of the cell loss priority (CLP) bit in the cells.
Then the ATM LSR performs a MPLS data table look-up and assigns the appropriate template Class of Service template and qbin characteristics. The default mapping for CoS is listed in Table 6-2.
| Class of Service Mapping | Class of Service | IP ToS |
Available | 0 | ToS 0/4 |
Standard | 1 | ToS 1/5 |
Premium | 2 | ToS 2/6 |
Control | 3 | ToS 3/7 |
Figure 6-2 shows an example of IP traffic across an ATM core consisting of BPX 8650 ATM LSRs. The host is sending two types of traffic across the network, interactive video and non-time critical data. Because multiple LVCs have automatically been generated for all IP source-destination paths, traffic for each source destination is assigned to one of four LVCs, based on the precedence bit setting in the IP packet header.
In this case, the video traffic might be assigned to the premium CoS, and transmitted across the network starting with the cell label "51" out of the Edge LSR-A, and continuing across the network with the cell label "91" applied to the Edge LSR-C. In each BPX 8650 ATM LSR, the cells are processed with the pre-assigned bandwidth, queuing, and other ATM QoS functions suitable to "premium" traffic.
In a similar fashion, low-priority data traffic cells with the same IP source-destination might be assigned label "53 out of Edge LSR-A and arrive at Edge LSR-C with the label "93", receiving pre-assigned bandwidth, queuing and other ATM QoS functions suitable to "available" traffic.
The service class template provide a means of mapping a set of extended parameters. These are generally platform specific, based on the set of standard ATM parameters passed to the VSI slave in a BXM port interface during the initial setup of the interface.
A set of service templates is stored in each switch (BPX 8650) and downloaded to the service modules (BXMs) as needed during initial configuration of the VSI interface when a trunk or line is enabled on the BXM.
An MPLS service template is assigned to the VSI interface when the trunk or port is initialized. The label switch controller (LSC) automatically sets up LVCs via a routing protocol (such as OSPF) and the Label Distribution Protocol (LDP), when the class of service Multiple LVC option is enabled at the edge label switch routers (LSRs).
With the Multiple VC option enabled (at edge LSRs), four LVCs are configured for each IP source-destination. Each of the four LVCs is assigned a service template type. For example, one of the four cell labels might be assigned to label cos2 service type category.
Each service template type has an associated qbin (see Figure 6-3). The qbins provide the ability to manage bandwidth by temporarily storing cells and then serving them out as bandwidth is available based on a number of factors, including bandwidth availability and the relative priority of different classes of service.
When ATM cells arrive from the edge LSR at the BXM port with one of four CoS labels, they receive CoS handling based on that label. A table look up is performed, and the cells are processed, based on their connection classification. Based on its label, a cell receives the ATM differentiated service associated with its template type, (MPLS1 template) and service type (for example, label cos2 bw), plus associated qbin characteristics and other associated ATM parameters.
The service template contains two classes of data:
When a connection setup request is received from the VSI master in the Label Switch Controller, the VSI slave (in the BXM, for example) uses the service type identifier to index into a Service Class Template database (Figure 6-3) containing extended parameter settings for connections matching that index. The slave uses these values to complete the connection setup and program the hardware.
When you use the upport or uptrk command to activate an interface on the BXM card, the default service template, which is MPLS1, is assigned to the interface (Figure 6-3). Each template table row includes an entry that defines the qbin to be used for that class of service. This mapping defines a relationship between the template and the interface qbin's configuration.
Qbin templates are used only with qbins that are available to VSI partitions, namely qbins 10 through 15. Qbins 10 through 15 are used by the VSI on interfaces configured as trunks or ports. The rest of the qbins (0-9) are reserved for and configured by AutoRoute.
In a typical operation for MPLS CoS, a packet makes its way from the host on the left side of a network, through the network of conventional routers, label edge routers (LERs), Label Switch Routers (LSRs), and ATM LSRs such as a BPX 8650.
As the packet progresses, basic functions are applied to it, as shown in Figure 6-4:
1. Set the IP Type of Service (ToS) for a packet in the host (or router).
2. Apply one or more labels, and copy the IP ToS to Label CoS in the label header at the edge label switch router (LSR).
3. Queue the packet in a label switch router (LSR) according to its CoS.
4. Map the MPLS and MPLS CoS bits to an ATM Label-VC in (LSR at the edge of the ATM cloud).
5. Apply ATM CoS bandwidth and queuing to ATM cells based on their class of service in the ATM LSR (BPX 8650, for example).
6. Receive the packet from the ATM cloud and forward it with appropriate label CoS through a LSR (could be frame-based LSR) at the edge of the ATM cloud.
7. Receive the labeled packet, remove the label, and forward the IP packet with appropriate CoS towards its destination (edge LSR).
 |
Note In the figure, the functions are shown being performed by separate entities. In general, one or more functions can be performed by the same entity. For example, the setting of precedence and labeling could all be performed in a single label edge router if the host were not participating. |
There are four default policy types for MPLS CoS as shown in Table 6-3 with default relative bandwidth per xtagatm interface.
| Class of Service Mapping | Class of Service | IP ToS | Default Bandwidth Weight |
Available | 0 | ToS 0/4 | 50 |
Standard | 1 | ToS 1/5 | 50 |
Premium | 2 | ToS 2/6 | 0 |
Control | 3 | ToS 3/7 | 1 |
The relative bandwidth weights determine the proportion of bandwidth available to MPLS which is given to each class of service on each link. If a CoS does not use the bandwidth given to it, then the bandwidth may be shared among the other CoSs.
The Control CoS is important to guarantee a good quality of service for MPLS control traffic. For this reason, it is desirable to reserve a small amount of bandwidth for the Control CoS as shown in Table 6-4.
| Class of Service Mapping | Class of Service | IP ToS | Bandwidth Weight |
Available | 0 | ToS 0/4 | 49 |
Standard | 1 | ToS 1/5 | 50 |
Premium | 2 | ToS 2/6 | 0 |
Control | 3 | ToS 3/7 | 1 |
To verify an xtagatm interface after configuration on the LSC, run this command:
show xtagatm cos-bandwidth-allocation xtagatmxx
where xx is the interface number. The maximum value for CoS bandwidth is 100.
The setup for the configuration example is shown in Figure 6-5.
Configure the following resources according to the sample setup shown in Figure 6-5:
When configuring BPX1 and BPX1, verify that no software, card, or trunk errors are reported on the console. In this example, all VSI resources are allocated to maximum value.
uptrk 1.1 //LSC1 control port
uptrk 1.3 //trunk via BPX1
upln 1.2 //up line for LER1
cnfrsrc 1.1 0 352207 y 1 e 0 3000 1 20 0 352207 //LSC1
cnfrsrc 1.3 0 352207 y 1 e 0 3000 1 20 0 352207 //trunk
cnfrsrc 1.2 0 353207 y 1 e 0 3000 1 20 0 352307 //LER1 port
addshelf v 1 1 //control-id=1;partition number=1
uptrk 2.1 //LSC2 control port
uptrk 2.3 //trunk via BPX1
upln 2.2 //up line for LER2
cnfrsrc 2.1 0 352207 y 1 e 0 3000 1 20 0 352207 //LSC2
cnfrsrc 2.3 0 352207 y 1 e 0 3000 1 20 0 352207 //trunk
cnfrsrc 2.2 0 353207 y 1 e 0 3000 1 20 0 352307 //LER2 port
addshelf v 2 1 //control-id=2;partition number=1
Check that VSI resources have been allocated and that the LSC controller was added successfully.
dsptrks //successful with no alarms
dspvsipartinfo //verify lcns and bandwidth are allocated successfully
dsplns //no alarm
dspctrlrs //controller ID is added successfully
There are four default policy parameters for relative bandwidth per xtagatm interface:
Once xtagatm interface has been defined for each LSC, exeute the command:
show xtagatm cos-bandwidth-allocation xtagatmxx
where xx is interface number. Verify that default relative bandwidth is properly assigned in percentage value. The maximum value for CoS bandwidth is 100.
LSC11-1#config t
LSC1(config)#int atm1/0 //LSC1LSC1 control port
LSC1(config-if)#no shut
LSC1(config-if)#tag-control-protocol vsi
LSC1(config-if)#exit
LSC1(config)#int xtagatm12 //LSR1 port 1.2
LSC1(config-if)#extended-port atm1/0 bpx 1.2
LSC1(config-if)#tag-switching ip
LSC1(config-if)#tag-switching atm cos available 49
LSC1(config-if)#tag-switching atm cos standard 50
LSC1(config-if)#tag-switching atm cos premium 0
LSC1(config-if)#tag-switching atm cos control 1
LSC1(config-if)ip unnumbered loopback0
LSC1(config-if)#exit
LSC1(config)#int xtagatm13 //LSR1 port 1.3
LSC1(config-if)#extended-port atm1/0 bpx 1.3
LSC1(config-if)#tag-switching ip
LSC1(config-if)#tag-switching atm cos available 49
LSC1(config-if)#tag-switching atm cos standard 50
LSC1(config-if)#tag-switching atm cos premium 0
LSC1(config-if)#tag-switching atm cos control 1
LSC1(config-if)ip unnumbered loopback0
LSC1(config-if)#exit
LSC1(config)#int loopback0 //configure loopback0 interface
LSC1(config-if)#ip address 200.200.200.1 255.255.255.255
LSC1(config-if)#exit
LSC1(config)#ip routing //enable IP routing
LSC1(config)#ip cef //enable Cisco Express Forwarding Protocol
LSC1(config)#router ospf 10
LSC1(config-router)#network 200.200.200.1 0.0.0.0 area 0
LSC1(config-router)#end
LSC2#config t
LSC2(config)#int atm2/0 //LSC2 control port
LSC2(config-if)#no shut
LSC2(config-if)#tag-control-protocol vsi id 2
LSC2(config-if)#exit
LSC2(config)#int xtagatm22 //LSR2 port 2.2
LSC2(config-if)#extended-port atm1/0 bpx 2.2
LSC2(config-if)#tag-switching ip
LSC2(config-if)#tag-switching atm cos available 49
LSC2(config-if)#tag-switching atm cos standard 50
LSC2(config-if)#tag-switching atm cos premium 0
LSC2(config-if)#tag-switching atm cos control 1
LSC2(config-if)ip unnumbered loopback0
LSC2(config-if)#exit
LSC2(config)#int xtagatm23 //LSR2 port 2.3
LSC2(config-if)#extended-port atm1/0 bpx 2.3
LSC2(config-if)#tag-switching ip
LSC2(config-if)#tag-switching atm cos available 49
LSC1(config-if)#tag-switching atm cos standard 50
LSC1(config-if)#tag-switching atm cos premium 0
LSC1(config-if)#tag-switching atm cos control 1
LSC2(config-if)ip unnumbered loopback0
LSC2(config-if)#exit
LSC2(config)#int loopback0 //configure loopback0 interface
LSC2(config-if)#ip address 200.200.200.2 255.255.255.255
LSC2(config-if)#exit
LSC2(config)#ip routing //enable IP routing
LSC2(config)#ip cef //enable Cisco Express Forwarding Protocol
LSC2(config)#router ospf 10
LSC2(config-router)#network 200.200.200.2 0.0.0.0 area 0
LSC2(config-router)#end
LSR1LSR1#config t
LSR1(config)#int atm1/0 //LSR1 interface
LSR1(config-if)#no shut
LSR1(config-if)#exit
LSR1(config)#interface atm1/0.1 tag-switching //create tag sub-interface
LSR1(config-subif)#ip unnumbered loopback0
LSR1(config-subif)#tag-switching atm multi-vc //enable multi-vc mode (4 VCs)
LSR1(config-subif)#tag-switching ip
LSR1(config)#int loopback0 //configure loopback0 interface
LSR1(config-if)#ip address 200.200.100.1 255.255.255.255
LSR1(config)#ip routing //enable IP routing
LSR1(config)#ip cef //enable Cisco Express Forwarding Protocol
LSR1(config)#router ospf 10
LSR1(config-router)#network 200.200.100.1 0.0.0.0 area 0
LSR1(config-router)#exit In default multiple LVC mode, there are four MPLS Cos LVCs created by cos-map with clp set to off. The four classes of service are available (0/4), standard (1/5), premium (2/6), and control (3/7).
LSR2#config t
LSR2LSR2(config)#int atm2/0 //LSR2 interface
LSR2(config-if)#no shut
LSR2(config-if)#exit
LSR2(config)#interface atm2/0.1 tag-switching //create tag sub-interface
LSR2(config-if)#ip unnumbered loopback0
LSR2(config-if)#tag-switching ip
LSR2(config)#int loopback0 //configure loopback0 interface
LSR2(config-if)#ip address 200.200.100.2 255.255.255.255
LSR2(config)#ip routing //enable IP routing
LSR2(config)#ip cef //enable Cisco Express Forwarding Protocol
LSR2(config)#router ospf 10
LSR2(config-router)#network 200.200.100.2 0.0.0.0 area 0
LSR2(config-router)#end
LSR2(config)#tag-switching cos-map 1 //configure Cos-Map
LSR2(config-tag-cos-map)#end //for now use default 4 VCs
LSR2#sho tag-switching cos-map //there should be 4 VCs w/ clp off
LSR2#config t
LSR2(config)#access-list 1 permit 200.200.100.1 0.0.0.0 //create access list for network 200.200.100.1
LSR2(config)#tag-switching prefix-map 1 access-list 1 cos-map 1 //map access-list to cos-map 1
LSR2(config)#show tag forward 200.200.100.1 32 detail //verify forwarding table
Verify that the LSC/LSR is operational and BPXs have clear alarms. LSR1 should be able to ping to LSR2 successfully. Check that VSI resources have been allocated and controller was added successfully. BPXs should have clear alarms and no software log and trunk errors.
dsptrks //successful with no alarms
dspvsipartinfo //verify lcns and bandwidth are allocated successfully
dsplns //no alarm
dspctrlrs //controller ID is added successfully
Check that LSC/edge LSR interfaces are operational and TDP bindings are successful.
LSC1#sho tag interface //xtagatm interfaces are operational
LSC1#sho xtag cross-connect //verify crosss-connect
LSC1#sho xtag vc //verify tag vc
LSC1#sho control vsi descriptor //verify VSI VPI range and Bw
LSC1#sho control vsi control-interface //verify number of connections for each cross-connect
LSC1#sho control vsi traffic //verify traffic statistics
LSC1#sho tag atm bind //verify tag atm bindings
LSC1#sho tag atm sum //verify local/remote connections
LSR1#sho tag interface //xtagatm interfaces are operational
LSC2#sho tag tdp disc //verify tdp session rx/tx
LSC2#sho atm vc //verify atm pvc and tvc
|
Note MPLS CoS Multiple LVC mode lets you reconfigure the classes for different traffic configurations. You have the flexibility to modify the four LVCs for any CoS. For example, you have the choice of assigning a "high" weight to a low class (that is, available CoS =60 and control CoS = 20). |
Posted: Tue Jul 11 10:04:43 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.