CHAPTER 20 Multiprotocol label switching (MPLS) combines the performance and capabilities of Layer 2 (data link layer) switching with the proven scalability of Layer 3 (network layer) routing. MPLS enables you, as service providers, to meet the challenges of the explosive growth in network utilization while providing the opportunity to differentiate services without sacrificing the existing network infrastructure. You can employ the flexible MPLS architecture in any combination of Layer 2 technologies. The Cisco 10000 series router offers MPLS support for all Layer 3 protocols. This chapter describes QoS for MPLS-enabled networks and includes the following topics: MPLS QoS, page 20-1 MPLS CoS Multi-VC Mode, page 20-12 MPLS Traffic Engineering DiffServ Aware, page 20-18 Per VRF AAA, page 20-32 Related Documentation, page 20-32 MPLS QoS Multiprotocol Label Switching (MPLS) quality of service (QoS) allows you, as the service provider, to provide varying levels of QoS services for different types of traffic in an MPLS network. MPLS allows you to "tunnel" the QoS of a packet. You can classify packets according to their type, input interface, and other factors without changing the IP precedence or DSCP field of the packet. The IP precedence and DSCP fields allow you to specify the QoS for an IP packet. The MPLS experimental (EXP) field, consisting of 3 bits in the IP header, allows you to specify the QoS for an MPLS packet. The EXP field is used to support differentiated services and can carry all of the information encoded in the IP precedence or DSCP field. In some cases, the EXP bits are used exclusively to encode the drop precedence within a traffic class. The router applies QoS services based on the class of service (CoS) set for a packet. If the IP precedence field specifies the CoS, the router treats the packet based on the IP precedence marking. In an MPLS network, the router copies the IP precedence bits into the MPLS EXP field at the edge of the network. However, based on the service offering, you might need to set the MPLS EXP field to a value that is different from the IP precedence value. In this case, MPLS QoS allows the IP precedence or DSCP setting of a packet to remain unmodified as the packet passes through the provider network. During congestion, packets receive the appropriate priority, based on the MPLS EXP setting. 20-1
MPLS QoS Chapter 20 You can mark the EXP bits independently of the per-hop behavior (PHB). Instead of overwriting the value in the IP precedence field, you can set the MPLS EXP field, choosing from a variety of criteria (including those based on IP PHB) to classify a packet and set the MPLS EXP field. For example, you can classify packets with or without considering the rate of the packets that the PE1 receives. If the rate is a consideration, you can mark in-rate packets differently from out-of-rate packets. As the packet travels through the MPLS network, the marking value of an IP packet does not change and the IP header remains available for use. In some instances, it is desirable to extend the MPLS PHB to the egress interface between the provider edge (PE) router and customer edge (CE) router. This has the effect of extending the MPLS QoS tunnel, which allows the MPLS network owner to classify scheduling and discarding behavior on that final interface. Feature History for MPLS QoS Cisco IOS Release Description Required PRE Release 12.0(19)SL The MPLS QoS feature was introduced on the PRE1. PRE1 Release 12.0(22)S This feature was enhanced to allow classification and PRE1 marking based on the MPLS experimental (EXP) field. Release 12.2(16)BX This feature was introduced on the PRE2. PRE2 Release 12.2(28)SB This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2. PRE2 MPLS QoS Services The MPLS experimental (EXP) field allow you to specify the QoS for an MPLS packet while the IP precedence and DSCP fields allow you to specify the QoS for an IP packet. By setting the MPLS EXP field, the router does not modify the IP precedence or DSCP field of IP packets as they traverse the network. MPLS QoS supports the following QoS services: Policing Classifies packets according to input or output transmission rates. Allows you to set the MPLS EXP, IP precedence, or DSCP bits (whichever is appropriate). For more information about policing, see Chapter 6, Policing Traffic. Weighted Random Early Detection (WRED) Monitors network traffic to prevent congestion by dropping packets based on the IP precedence value, DSCP value, MPLS EXP value, or the discard class value. For more information about WRED, see Chapter 11, Managing Packet Queue Congestion. Class-Based Weighted Fair Queuing (CBWFQ) An automated scheduling system that uses a queuing algorithm to ensure bandwidth allocation to different classes of network traffic. For more information about CBWFQ, see Chapter 12, Sharing Bandwidth Fairly During Congestion. 20-2
Chapter 20 MPLS QoS MPLS Tunneling Modes MPLS QoS provides QoS on MPLS packets using the following tunnel modes: Uniform Provides uniformity in per-hop behavior (PHB) throughout the network. In this mode, all customers of your MPLS network use the same precedence settings. Short Pipe (Default) Provides for a distinct MPLS PHB layer (on top of the IP PHB layer) across the entire MPLS network. In this mode, your customers implement their own IP PHB marking scheme. Pipe Similar to short pipe mode, except that at the egress of the provider edge (PE) router the MPLS PHB layer is used to classify the packet for discard and scheduling behavior at the outbound interface. In this mode, you schedule and discard packets without needing to know your customer setting. Figure 20-1 shows a service provider MPLS network that connects two sites of a customer s network. To use these features in a network, set the MPLS experimental field value at PE1 (the ingress label switching router) by using the modular QoS CLI. This sets the QoS value in the MPLS packet. Figure 20-1 MPLS Network Connecting Two Sites of a Customer's IP Network IP network MPLS network MPLS network IP network Host A CE1 PE1 P1 P2 PE2 CE2 Host B 41867 Owned by service provider Short pipe tunnel mode discards the MPLS EXP value on label disposition. To enable MPLS EXP-based classification after label disposition, you can map the EXP values to the qos-group values at the inbound interface and use qos-group to classify packets into different classes at the outbound interface. However, Weighted Random Early Detection (WRED) on the outbound interface is still based on the IP type of service (ToS) value rather than the disposed EXP value. The Cisco 10000 series router does not support the propagate-cos command to enable uniform mode. The router does not copy the MPLS EXP values on disposition to the packet s IP header, unless you map the EXP value to a qos-group value at the inbound interface and use the qos-group value to set the IP ToS value on the outbound interface. 20-3
MPLS QoS Chapter 20 How QoS Works for MPLS Traffic The Cisco 10000 series router bypasses the IP header-based classification for MPLS packets you cannot classify MPLS packets into distinct classes using the embedded IP header of the MPLS packet. The router classifies MPLS packets as belonging to the class-default class, except if you specify qos-group or input-interface match statements for traffic classes. Normal QoS processing applies to incoming IP packets that the router later tags. Normal QoS processing resumes for outgoing IP packets that arrived tagged. Precedence-based Weighted Random Early Detection (WRED) uses the MPLS experimental (EXP) value for MPLS packets. Upon MPLS imposition, by default the router sets the EXP values of all pushed labels to the packet s IP precedence value. Upon label swap, the new label carries the EXP value of the swapped label. A set or police command directive might modify the default EXP setting. MPLS QoS and Packet Priority During Congestion The router classifies packets based on the classification and marking criteria you define, such as a source address, destination address, port, protocol identification, or class of service field. The packets classification in turn determines each packet s priority and how the router treats the packet during periods of congestion (for example, forward or drop the packet). For example, service level agreements (SLAs), contracted between providers and their customers, specify how much traffic the service provider agrees to deliver. Packets that comply with the agreed-upon rate are considered in-rate and packets that do not comply are considered out-of-rate. During congestion, the router gives preferential treatment to in-rate packets and might aggressively drop out-of-rate packets. Interfaces Supporting MPLS QoS The following describes interface support for MPLS QoS: The router supports the match mpls experimental topmost command on both input and output interfaces on which MPLS is enabled. The set mpls experimental imposition command and the set mpls experimental command are supported on the provider edge (PE) router input interface connecting to customer edge (CE) router. You can also use these commands on input interfaces on the CE, in pipe mode of MPLS QoS DiffServ tunneling models. Note The set mpls experimental imposition command replaces the set mpls experimental command, which the router supports only for backward compatibility. We recommend that you use the set mpls experimental imposition command. The set-mpls-exp-imposition-transmit action of the police command is only supported on the PE input interface that is connected to the CE. The mpls ip encapsulate explicit-null command is supported on the CE router interface that is connected to the PE. This command is only used in pipe mode of MPLS QoS DiffServ tunneling models. 20-4
Chapter 20 MPLS QoS MPLS QoS Implementation When precedence-based weighted random early detection (WRED) is configured on an output policy map and outgoing packets are MPLS packets, the router drops the MPLS packets based on the three EXP bits in the MPLS label, instead of using the three bits of the IP precedence field in the underlying IP packets. When DSCP-based WRED is configured on an output policy map and outgoing packets are MPLS packets, the router drops the MPLS packets based on the three EXP bits in the MPLS label, instead of using the six bits of the DSCP field in the underlying IP packets. The router left shifts the three EXP bits and makes it six bits. For example, if the value of the EXP bits is 5 (binary 101), the router converts them to binary 101000 (makes it looks like six DSCP bits), and drops packets based on this value. When configuring the set and police commands in a traffic class, regardless of whether it is an input or output policy map, the police command is processed later than the set command. This means that the values implemented by the police command override the values set by the set command. The value can be IP precedence, DSCP, qos-group, MPLS experimental imposition, discard-class, or ATM CLP bit. Discard-class is a number between 0 and 7; qos-group is a number between 0 and 63. Restrictions and Limitations for MPLS QoS The router does not support the set mpls experimental imposition topmost command. Configuring MPLS QoS on the Ingress Label Switching Router A label switching router (LSR) is an ingress provider edge (PE) router, a provider (P) router, or a penultimate-hop provider router. Setting the MPLS EXP field is only valid for packets that arrive on a non-mpls interface of the LSR and leave on an MPLS interface. Therefore, only input service policies can cause the MPLS EXP bits to be set when the packet goes out an MPLS interface. If the packet arrives on an MPLS interface, setting the MPLS EXP field has no affect. The IP header of an outbound IP packet determines the packet s QoS. For general information, see the Cisco IOS Quality of Service Solutions Configuration Guide. The MPLS EXP field in the topmost label of an outbound MPLS packet determines the packet s QoS. For general information, see the MPLS Class of Service manual. To configure MPLS QoS on the ingress LSR, perform the following configuration tasks to configure the ingress label switching router: Classifying IP Packets Using a Class Map, page 20-6 Setting the MPLS EXP Field Using a Policy Map, page 20-7 Attaching an MPLS QoS Service Policy to an Interface, page 20-8 20-5
MPLS QoS Chapter 20 Classifying IP Packets Using a Class Map To classify IP packets using a class map, enter the following commands on the ingress LSR beginning in global configuration mode: Command Purpose Step 1 Router(config)# class-map class-map-name Creates or modifies a class map. class-map-name is the name of the class map. Step 2 Router(config-cmap)# match mpls experimental topmost value Configuration Example for Classifying IP Packets Using a Class Map The following example creates a class map named exp4 with MPLS EXP 4 defined as the match criterion. The router classifies all packets whose EXP bits are set to 4 as belonging to the exp4 traffic class. Router(config)# class-map match-all exp4 Router(config-cmap)# match mpls experimental topmost 4 Router(config-cmap)# end The following example creates a class map named IP_prec4 with IP precedence 4 defined as the match criterion. The router classifies all packets that contain IP precedence 4 as belonging to the IP_prec4 traffic class. Router(config)# class-map match-all IP_prec4 Router(config-cmap)# match ip precedence 4 Router(config-cmap)# end The following example creates a class map named http with the access control list (ACL) named http defined as the match criterion. The router classifies all packets that match the http ACL as belonging to the http traffic class. Router(config)# class-map match-all http Router(config-cmap)# match access-group name http Router(config-cmap)# end (Optional) Specifies the MPLS EXP bits value used to classify traffic. Note You can configure MPLS EXP-based classification on the ingress provider edge (PE), egress PE, provider (P), or penultimate P router. This command is available only on the PRE2. Step 3 Router(config-cmap)# match criteria Defines criteria by which the router matches packets to this traffic class. criteria is the match type (for example, precedence or DSCP level) For more information about match types, see the Defining Match Criteria Using the match Commands section on page 2-5. 20-6
Chapter 20 MPLS QoS The following example creates a class map named af41 with DSCP AF41 defined as the match criterion. The router classifies all packets that contain the IP DSCP binary value 100010 as belonging to the af41 traffic class. Router(config)# class-map match-all af41 Router(config-cmap)# match ip dscp af41 Router(config-cmap)# end Setting the MPLS EXP Field Using a Policy Map To set the MPLS EXP field of packets belonging to a specific traffic class, enter the following commands beginning in global configuration mode: Note Even though the commands in Steps 3 through 6 are optional, you must configure one of the commands to set the MPLS EXP field. The router sets the EXP bits when the packet leaves the router using an MPLS interface. If the packet arrives on an MPLS interface, the router does not set the EXP bits. You can only set the EXP bits of packets that arrive on a non-mpls interface and leave on an MPLS interface. Command Purpose Step 1 Router(config)# policy-map policy-map-name Creates or modifies a policy map that specifies the QoS actions to take on specific traffic classes. policy-map-name is the name of the policy map. Step 2 Router(config-pmap)# class class-map-name Assigns a traffic class to a policy map. Enters policy-map class configuration mode. class-map-name is the name of a previously configured class map. Step 3 Step 4 Step 5 Step 6 Router(config-pmap-c)# police [cir] bps [bc] burst-normal [be] burst-excess [conform-action set-mpls-exp-imposition-transmit] [exceed-action action] [violate-action action] Router(config-pmap-c)# police {cir cir} [bc] burst-normal [pir pir] [be] peak-burst [conform-action set-mpls-exp-imposition-transmit] [exceed-action action] [violate-action action] police [cir] percent percent [bc] normal-burst-in-msec [pir pir] [be] excess-burst-in-msec [conform-action set-mpls-exp-imposition-transmit] [exceed-action action] [violate-action action] Router(config-pmap-c)# set mpls experimental imposition mpls-exp-value (Optional) Configures traffic policing based on bits per second and sets the MPLS EXP field for all packets that conform to the rate. For more information, see Chapter 6, Policing Traffic. (Optional) Configures traffic policing using the committed information rate (CIR) and the peak information rate (PIR) and sets the MPLS EXP field for all packets that conform to the rate. For more information, see Chapter 6, Policing Traffic. (Optional) Configures traffic policing on the basis of a percentage of bandwidth available on an interface and sets the MPLS EXP field for all packets that conform to the rate. For more information, see Chapter 6, Policing Traffic. (Optional) Sets the MPLS EXP bits of the packets belonging to this traffic class. mpls-exp-value specifies the value used to set the MPLS EXP bits. Valid values are from 0 to 7. 20-7
MPLS QoS Chapter 20 For more information about other QoS actions you can define in the policy map, see the Types of QoS Actions section on page 3-4. Configuration Example for Setting the MPLS EXP Field Using a Policy Map The following example shows how to set the MPLS EXP field using the set mpls experimental imposition command. The sample configuration creates a policy map named set_experimental_5 and defines the traffic class named IP_prec4. The router sets the MPLS EXP bits to 5 for all of the packets belonging to the IP_prec4 class. Router(config)# policy-map set_experimental_5 Router(config-pmap)# class IP_prec4 Router(config-pmap-c)# set mpls experimental imposition 5 Router(config-pmap-c)# end Attaching an MPLS QoS Service Policy to an Interface An MPLS QoS service policy is a policy map that sets the MPLS EXP field of packets belonging to a specific traffic class. To attach an MPLS QoS service policy to an interface, enter the following commands beginning in global configuration mode: Command Purpose Step 1 Router(config)# interface type number Creates or modifies an interface. Enters interface configuration mode. type is the type of interface (for example, serial). number is the number of the interface (for example, 1/0/0). Step 2 Router(config-if)# service-policy input policy-map-name Configuration Example for Attaching an MPLS QoS Service Policy to an Interface Attaches the specified policy map to the input interface. policy-map-name is the name of the policy map you want to attach to the interface. The following example applies the MPLS QoS service policy named set_experimental_5 to the Gigabit Ethernet interface 1/0/0 for inbound packets. Router(config)# interface GigabitEthernet1/0/0 Router(config-if)# service-policy input set_experimental_5 Router(config-if)# end Configuration Examples for MPLS QoS This section provides example configurations for the following: Configuration Example for Short Pipe Mode, page 20-9 Configuration Example for Pipe Mode, page 20-10 20-8
Chapter 20 MPLS QoS Configuration Example for Short Pipe Mode The following example shows how to configure short pipe mode on the ingress PE router for the following sample topology. In this topology, esr5 is the CE router, esr6 is the PE router, esr4 is the P router. Customer router/switch---(gig4/0/0) esr5 (gig3/0/0.2)---(gig3/0/0.2) esr6 (pos4/0/0)--- ---(pos4/0/0) esr4 (gig5/0/0)---pe router Esr6 (ingress PE router): policy-map set-exp class http police 200000000 10000000 10000000 conform-action set-mpls-exp-imposition-transmit 1 exceed-action set-mpls-exp-imposition-transmit 0 violate-action drop class telnet set mpls experimental imposition 5 set ip precedence 2 class rtp set mpls experimental 3 set dscp cs4 class tftp set mpls experimental 2 class dscp32 set mpls experimental imposition 5 class prec6 set mpls experimental imposition 6! policy-map wred class exp0 bandwidth percent 10 bandwidth remaining percent 12 random-detect precedence-based random-detect precedence 0 500 1500 1 shape 120000 class exp1 bandwidth percent 10 bandwidth remaining percent 12 random-detect precedence-based random-detect precedence 1 500 1500 1 random-detect precedence 2 800 1300 5 random-detect precedence 3 1000 1800 15 random-detect precedence 4 1500 2000 20 shape 550000 class exp2 bandwidth percent 10 random-detect dscp-based random-detect dscp 16 800 1200 5 shape 120000 class exp3 bandwidth remaining percent 12 random-detect precedence-based random-detect precedence 1 500 1000 1 random-detect precedence 2 800 1300 5 random-detect precedence 3 500 1500 1 random-detect precedence 4 1500 2000 20 shape 120000 class exp4 bandwidth remaining percent 12 random-detect precedence-based random-detect precedence 1 500 1000 1 random-detect precedence 2 800 1300 5 random-detect precedence 3 1000 1800 15 20-9
MPLS QoS Chapter 20 random-detect precedence 4 500 1500 1 shape 120000 class exp5 bandwidth percent 10 bandwidth remaining percent 12 random-detect precedence-based random-detect precedence 5 500 1500 1 shape 120000 class exp6 bandwidth percent 10 bandwidth remaining percent 12 random-detect precedence-based random-detect precedence 6 500 1500 1 shape 120000 class exp7 bandwidth percent 10vbandwidth remaining percent 12 random-detect precedence-based random-detect precedence 7 500 1500 1 shape 120000 class class-default! interface GigabitEthernet3/0/0.2 encapsulation dot1q 2 ip vrf on forwarding vrf_2 ip address 220.220.56.6 255.255.255.0 service-policy input set-exp!! interface POS4/0/0 ip address 220.220.46.6 255.255.255.0 load-interval 30 tag-switching ip crc 32 clock source internal service-policy output wred Configuration Example for Pipe Mode The following example shows how to configure pipe mode on the CE and PE routers in the following sample topology. In this topology, esr5 is the CE router, esr6 is the PE router, esr4 is the P router. Customer router/switch---(gig4/0/0) esr5 (gig3/0/0.2)---(gig3/0/0.2) esr6 (pos4/0/0)--- ---(pos4/0/0) esr4 (gig5/0/0)---pe router Configuration for esr5 (CE router): class-map match-all prec0 match ip precedence 0 class-map match-all prec1 match ip precedence 1 class-map match-all prec2 match ip precedence 2 class-map match-all prec3 match ip precedence 3 class-map match-all prec4 match ip precedence 4 class-map match-all prec5 match ip precedence 5 class-map match-all prec6 match ip precedence 6 class-map match-all prec7 match ip precedence 7! 20-10
Chapter 20 MPLS QoS policy-map prec2exp class prec0 set mpls experimental imposition 1 class prec1 set mpls experimental imposition 2 class prec2 set mpls experimental imposition 3 class prec3 set mpls experimental imposition 4 class prec4 set mpls experimental imposition 5 class prec5 set mpls experimental imposition 6 class prec6 set mpls experimental imposition 7 class prec7 set mpls experimental imposition 0!! interface GigabitEthernet4/0/0 ip address 220.5.1.1 255.255.255.0 service-policy input prec2exp load-interval 30 no negotiation auto no keepalive! interface GigabitEthernet3/0/0.2 encapsulation dot1q 2 ip address 220.220.56.5 255.255.255.0 mpls ip encapsulate explicit-null Configuration for esr6 (ingress PE router): class-map match-all exp4 match mpls experimental topmost 4 class-map match-all exp5 match mpls experimental topmost 5 class-map match-all exp7 match mpls experimental topmost 7 class-map match-all exp6 match mpls experimental topmost 6 class-map match-all exp1 match mpls experimental topmost 1 class-map match-all exp0 match mpls experimental topmost 0 class-map match-all exp3 match mpls experimental topmost 3 class-map match-all exp2 match mpls experimental topmost 2! policy-map exp2exp class exp0 set mpls experimental imposition 1 class exp1 set mpls experimental imposition 2 class exp2 set mpls experimental imposition 3 class exp3 set mpls experimental imposition 4 class exp4 set mpls experimental imposition 5 class exp5 set mpls experimental imposition 6 class exp6 20-11
MPLS CoS Multi-VC Mode Chapter 20 set mpls experimental imposition 7 class exp7 set mpls experimental imposition 0! interface GigabitEthernet3/0/0.2 encapsulation dot1q 2 ip vrf forwarding vrf_2 ip address 220.220.56.6 255.255.255.0 service-policy input exp2exp tag-switching ip MPLS CoS Multi-VC Mode The Multiprotocol Label Switching Class of Service (MPLS CoS) Multi-Virtual Circuit (VC) Mode feature on the Cisco 10000 router provides multi-vc support on the performance routing engine (part number PRE1) and extends QoS functionality to Label-Controlled Asynchronous Transfer Mode (LC-ATM) and multi-vc subinterfaces 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. The MPLS CoS Multi-VC Mode feature enables you to map the experimental (EXP) field values of an MPLS label to an ATM VC to create sets of labeled virtual circuits (LVCs). Each set, called an LVC Service Group, 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. Each member of the set may have a different quality of service from other members of the set. By using multi-vc sets, you can provide differentiated services to users of MPLS-enabled service provider networks. To provide this service differentiation, the provider edge (PE) router in the service provider network sets an appropriate value in the EXP field in the header of each incoming packet as it is received. A standard IP access list (ACL) together with a class of service (CoS) map and a prefix map are used to specify the number of classes (and LVCs) per IP destination. For information on a CoS map, see the Class of Service Map section on page 20-13. Each MPLS-enabled ATM interface in the service provider network, including each ATM edge interface and each ATM router or 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 ATM traffic. Accordingly, MPLS CoS multi-vc functionality is virtually indistinguishable from the QoS support provided for IP packet interfaces. For more information, see the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module. Feature History for MPLS CoS Multi-VC Mode Cisco IOS Release Description Required PRE Release 12.0(27)S This feature was introduced on the router. PRE1 Release 12.2(16)BX This feature was introduced on the PRE2. PRE2 Release 12.2(28)SB This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2. PRE2 20-12
Chapter 20 MPLS CoS Multi-VC Mode Label Switched Paths IP packets travel through the core of an MPLS-enabled service provider network by means of multiple, label-switched paths (LSPs). In ATM networks, label virtual circuits (LVCs) are automatically established for each IP destination prefix. A standard IP access list (ACL) together with a class of service (CoS) map and a prefix map are used to specify the number of classes (and LVCs) per IP destination. For information on a CoS map, see the Class of Service Map section on page 20-13. If there are multiple equal-cost paths through an ATM network from a P router within the core of the network to a destination, it is possible that each LVC relating to the same destination could take a different path through the network, since 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 on. 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. If there are multiple equal-cost paths through an ATM network from a PE router on the edge of the network to a destination, LVCs are established for all configured classes of service for each of the equal-cost paths. The configured load-balancing mechanism determines path selection for data forwarding. Class of Service Map A class of service (CoS) map is a template that maps EXP values to a VC number within an LVC service group. The Cisco IOS software uses the CoS map to create a binding table that maps EXP values to the actual VCs. Each LVC has a CoS map and a separate binding table. You can specify a maximum of four LVCs for each service group. Table 1 shows the default CoS map. Based on this map, the binding table will have four VCs named available, standard, premium, and control. The two least significant bits of the EXP field determine the LVC to which the IP packets will be directed. Table 1 Default CoS Map EXP Values VC Number VC Name 0, 4 0 Available 1, 5 1 Standard 2, 6 2 Premium 3, 7 3 Control You can configure a CoS map to limit the number of LVCs created and to redefine the mapping of the EXP bits. Table 2 shows a configured CoS map. Based on this map, the binding table will have two VCs named available and premium. 20-13
MPLS CoS Multi-VC Mode Chapter 20 Table 2 Configured CoS Map EXP Values VC Number VC Name 0, 4 0 Available 1, 5 0 Available 2, 6 2 Premium 3, 7 2 Premium QoS for Label-Controlled ATM VCs Default Bandwidth for LVCs The router dynamically creates label-controlled ATM virtual circuits (LC-ATM VCs), also referred to as LVCs. In Cisco IOS Release 12.0(28)S and later releases, the implementation of LC-ATM interfaces is expanded to provide QoS capability for LVCs. The router treats LVCs like unspecified bit rate (UBR) permanent virtual circuits (PVCs). By default, the LVCs share the bandwidth on an ATM interface with UBR PVCs. You can configure the bandwidth on the LC-ATM subinterface using a nested policy map. For more information, see the Allocating LVC Bandwidth Using Policy Maps section on page 20-14. The default bandwidth is the bandwidth an LC-ATM interface will have when it first becomes active. LVCs and UBR PVCs share all available bandwidth. Allocating LVC Bandwidth Using Policy Maps The router allows you to configure bandwidth for an LC-ATM subinterface. Because the router does not support a default bandwidth for LVCs, you must use a nested policy map to configure the bandwidth. The router does not allow non-nested policy maps to be attached to an LC-ATM subinterface. The nested policy map provides the bandwidth. The router treats the configured bandwidth like the SCR of the VBR PVCs, in that all LVCs on a specific LC-ATM subinterface use the aggregate bandwidth specified in the nested policy map. The available bandwidth for UBR PVCs is then reduced by the configured bandwidth amount. MPLS QoS Support in an MPLS Network MPLS QoS provides IOS IP QoS (Layer 3) functionality for MPLS devices, including label edge routers (LERs), label switching routers (LSRs), and Asynchronous Transfer Mode LSRs (ATM-LSRs). You can use MPLS QoS in an MPLS-enabled networking environment in several different ways. The method you choose depends on whether the core of the network contains LSRs or ATM label switching routers (ATM-LSRs). In either case, the same QoS services are provided, such as CAR, weighted random early detection (WRED), class-based weighted fair queueing (CBWFQ). For information about how you can deploy LSRs and ATM-LSRs to take advantage of QoS functions in an MPLS network, refer to the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(2)T feature module. 20-14
Chapter 20 MPLS CoS Multi-VC Mode Benefits of MPLS CoS Multi-VC Mode The MPLS CoS Multi-VC Mode feature has the following benefits: Ensures effective deployment of differentiated service classes in an MPLS-enabled ATM network Leverages the use of existing ATM infrastructures Restrictions for MPLS CoS Multi-VC Mode The MPLS CoS Multi-VC Mode feature has the following restrictions: A multi-vc service group can have up to four LVCs. The Cisco 10000 series router supports a maximum of 500 LVC service groups. The Cisco 10000 series router does not support available bit rate (ABR) for ATM VCs. Therefore, the router also does not support ABR LVCs. All LVCs and the control-vc share the same QoS policy. Any QoS policy changes are applied to the subinterface. All LVCs will then automatically share the new policy. Prerequisites for MPLS CoS Multi-VC Mode The MPLS CoS Multi-VC Mode feature has the following requirements: The Cisco 10000 series router must be running Cisco IOS Release 12.0(27)S or later releases. The performance routing engine (PRE), part number PRE1 must be installed in the router s chassis. To use MPLS QoS to full advantage in your network, the following functionality must be supported: Multiprotocol Label Switching (MPLS) The standardized label switching protocol defined by the Internet Engineering Task Force (IETF). Cisco Express Forwarding (CEF) 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) International standard for cell relay in which multiple service types (such as voice, video, or data) are conveyed in fixed-length cells. ATM signaling is required if you use ATM interfaces in your network. The following QoS features are required: MPLS CoS Multi-VC Mode to provide QoS functionality on ATM interfaces in a service provider MPLS-enabled network. Class-based weighted fair queueing (CBWFQ) to allocate bandwidth fairly to all network traffic. Weighted random early detection (WRED) to configure different discard priorities or classes of service using the MPLS experimental field in the MPLS packet header. 20-15
MPLS CoS Multi-VC Mode Chapter 20 Configuring MPLS CoS Multi-VC Mode To configure the MPLS CoS Multi-VC Mode feature on the Cisco 10000 router, perform the following required configuration tasks: Configuring Multi-VC Mode in the Core of an ATM Network, page 20-16 Configuring Queueing Functions on Router Output Interfaces, page 20-17 Configuring Multi-VC Mode in the Core of an ATM Network To configure multi-vc mode in the core of an ATM network, perform the following required configuration tasks: Configuring Multi-VC Mode Using the Default CoS Map, page 20-16 Configuring Multi-VCs Using a Specific CoS Map, page 20-17 Configuring Multi-VC Mode Using the Default CoS Map To configure multi-vc mode in an MPLS-enabled network using the default CoS map, enter the following commands beginning in global configuration mode: Step 1 Step 2 Command Router(config)# interface atm number [slot/module/port.subinterface-number] mpls Router(config-if)# ip unnumbered type number Purpose Configures an ATM MPLS interface or subinterface and enters interface or subinterface configuration mode. Enables IP processing on the interface without assigning an explicit IP address to the interface. Step 3 Router(config-if)# mpls atm multi-vc Enables ATM multi-vc mode on the interface. Configures the ATM interface to create one or more label virtual circuits (VCs) over which packets of different classes are sent. Note This command results in the creation of the default CoS map shown in Table 1 on page 20-13. Step 4 Router(config-if)# mpls ip Enables MPLS forwarding of IP version 4 (IPv4) packets along normally routed paths. Step 5 Router(config-if)# mpls label protocol {ldp tdp both} Specifies the label distribution protocol to be used on the interface. 20-16
Chapter 20 MPLS CoS Multi-VC Mode Configuring Multi-VCs Using a Specific CoS Map To configure multi-vcs using a CoS map that you specify, enter the following commands beginning in global configuration mode: Step 1 Command Router(config)# mpls cos-map cos-map number Configuring Queueing Functions on Router Output Interfaces Purpose Creates a class of service (CoS) map that specifies how classes map to label virtual circuits (LVCs) when they are combined with a prefix map. Enters cos-map configuration submode. Step 2 Router(config-tag-cos-map)# class class [available standard premium control] Maps traffic classes to LVCs. class is the precedence of identified traffic to classify traffic. The default values for assigning traffic classes to the CoS map range from 0 to 3: Class 0 Available Class 1 Standard Class 2 Premium Class 3 Control The two least significant bits of the EXP field in the packet header determine the class of a packet. Step 3 Router(config-tag-cos-map)# exit Exits the cos-map configuration submode. Step 4 Step 5 Router(config)# access-list access-list-number permit destination Router(config)# mpls prefix-map prefix-map access-list access-list cos-map cos-map Creates an access list to control traffic going to the specified destination address. Configures the router to use a specified QoS map when an MPLS destination prefix matches the specified access list. To configure queuing functions on the router s output interfaces, see Chapter 3, Configuring QoS Policy Actions and Rules. 20-17
MPLS Traffic Engineering DiffServ Aware Chapter 20 Monitoring and Maintaining MPLS CoS Multi-VC Mode Configuration To monitor and maintain the configuration of MPLS CoS Multi-VC Mode on ATM interfaces, enter any of the following commands in privileged EXEC mode: Command Router# show mpls interfaces [interface] [detail] Router# show mpls cos-map [cos-map] Router# show mpls prefix-map [prefix-map] Router# debug mpls atm-cos [bind request] Purpose Displays information about one or more interfaces that have been configured for label switching. If you do not specify an interface, information about all interfaces that have been configured for label switching displays. detail displays detailed label switching information for the specified interface or for all interfaces if you do not specify an interface. Displays the quality of service (QoS) map used to assign a quantity of label virtual circuits and the associated class of service (CoS) for those virtual circuits. cos-map is an optional number that specifies the QoS map to be displayed. Displays the prefix map used to assign a QoS map to network prefixes that match a standard IP access list. prefix-map is an optional number that specifies the prefix map to be displayed. Displays ATM label VC bind or request activity that is based on the configuration of a QoS map. Configuration Examples for MPLS CoS Multi-VC Mode For an example of how to configure MPLS CoS multi-vc mode functionality, see the Configuration Examples section in the MPLS QoS Multi-VC Mode for PA-A3, Release 12.2(4)T3 feature module. MPLS Traffic Engineering DiffServ Aware The MPLS Traffic Engineering DiffServ Aware (DS-TE) feature extends MPLS traffic engineering capabilities to provide stricter quality of service (QoS) guarantees. TE tunnels provide differentiated services (DiffServ) to satisfy bandwidth requirements of regular traffic. However, the bandwidth currently advertised for TE tunnels and the tunnel traffic does not correspond to any queue. Instead, the MPLS class of service (CoS) provides DiffServ service, which is adequate for most customer services. Special services such as voice, however, require stricter QoS guarantees. The DS-TE feature addresses this need, providing strict bandwidth guarantees for TE tunnels. The DS-TE feature introduces awareness of a particular class of traffic referred to as the guaranteed bandwidth traffic. DS-TE enables you, as service providers, to perform separate admission control and separate route computation of the guaranteed bandwidth traffic. Therefore, you can develop QoS services for end customers that rely on signaled QoS rather than provisioned QoS, which enables you to build QoS services with hard commitments and without overprovisioning. 20-18
Chapter 20 MPLS Traffic Engineering DiffServ Aware MPLS traffic engineering allows constraint-based routing of IP traffic. One of the constraints satisfied by constraint-based routing is the availability of required bandwidth over a selected path. DS-TE extends MPLS TE so that constraint-based routing and admission control of special TE tunnels (referred to as guaranteed bandwidth TE tunnels) are performed over a more restrictive bandwidth constraint than regular TE tunnels. A more restrictive bandwidth constraint enables you to achieve higher QoS performance (in terms of delay, jitter, or loss) for the guaranteed traffic. The more restrictive bandwidth is referred to as a sub-pool, while the regular TE tunnel bandwidth is called the global pool. The sub-pool is a portion of the global pool and applies to tunnels that carry traffic requiring strict bandwidth guarantees or delay guarantees. The global pool applies to tunnels that carry traffic requiring only differentiated service. Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the amount of guaranteed traffic is limited to a portion of the total link bandwidth. Having a separate pool for other traffic (best-effort or DiffServ traffic) allows you to have a separate limit for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up links with best-effort and DiffServ traffic, thereby achieving a greater utilization of those links. The DS-TE feature also extends the Open Shortest Path First (OSPF) routing protocol so that the available sub-pool bandwidth at each preemption level is advertised in addition to the available global pool bandwidth at each preemption level. The DS-TE feature also modifies constraint-based routing to take this more complex advertised information into account during path computation. For more information, see the MPLS Traffic Engineering DiffServ Aware, Release 12.2(14)S feature module. Feature History for MPLS TE DS Cisco IOS Release Description Required PRE Release 12.3(7)XI The MPLS Traffic Engineering DiffServ Aware (DS-TE) PRE2 feature was introduced on the PRE2. Release 12.2(28)SB This feature was integrated in Cisco IOS Release 12.2(28)SB for the PRE2. PRE2 Sub-pool Tunnels A sub-pool tunnel carries traffic that requires strict bandwidth guarantees or delay guarantees, such as real-time voice, virtual IP leased line, and bandwidth trading traffic. As traffic enters the sub-pool tunnel, DS-TE marks the traffic with a unique value in the MPLS EXP field. The router places traffic with this unique value in the guaranteed bandwidth queue at the outbound interface of every tunnel hop. The strict guaranteed traffic has exclusive use of the guaranteed bandwidth queue; no other traffic can use this queue. DS-TE ensures that the guaranteed bandwidth queue is never oversubscribed and limits the amount of traffic that enters the queue to a percentage of the total bandwidth of the corresponding outbound link. Therefore, the amount of traffic sent into the sub-pool is never more than the amount the guaranteed bandwidth queue can handle. 20-19
MPLS Traffic Engineering DiffServ Aware Chapter 20 Global Pool Tunnels A tunnel that uses global pool bandwidth carries the best-effort class of traffic as well as other classes of traffic. To ensure that traffic from each class receives differentiated services (DiffServ), each traffic class has a distinct DiffServ queue and the router marks each class of traffic with a unique value in the MPLS EXP field. The router places traffic in the appropriate queue based on this unique value. The router sets tunnel bandwidth based on the expected aggregate traffic across all classes of service. Prerequisites for DS-TE To run DS-TE your network must support the following Cisco IOS features: Multiprotocol Label Switching (MPLS) IP Cisco Express Forwarding (CEF) Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS) routing protocols Resource Reservation Protocol-Traffic Engineering (RSVP-TE) QoS Note IP CEF is enabled by default on the Cisco 10000 series router and it cannot be turned off. If you attempt to disable IP CEF, an error appears. Restrictions and Limitations for DS-TE The total number of TE tunnels (regular TE tunnels and DS-TE tunnels) that can originate on a device is limited to 1013 tunnels. Configuring DS-TE To configure DS-TE, perform the following required configuration tasks: Activating Traffic Engineering on the Router, page 20-21 Activating Traffic Engineering on the Interface, page 20-23 Configuring the Tunnel Interface, page 20-24 Configuring Guaranteed Bandwidth Service, page 20-25 20-20
Chapter 20 MPLS Traffic Engineering DiffServ Aware Activating Traffic Engineering on the Router To globally activate traffic engineering on the router, enter the following commands beginning in global configuration mode: Command Purpose Step 1 Router(config)# mpls traffic-eng tunnels Enables MPLS traffic engineering tunnel signaling on the router. Step 2 Router(config)# router ospf Invokes the OSPF routing process for IP and enters router configuration mode. Continue with Step 9. Step 3 or Router(config)# router isis Router(config-router)# network network-entity-title Step 4 Router(config-router)# metric-style wide [transition] [{level-1 level-2 level-1-2}] Step 5 Router(config-router)# is-type {level-1 level-1-2 level-2-only} Step 6 Router(config-router)# mpls traffic-eng {level-1 level-2} Invokes the IS-IS routing process and enters router configuration mode. Continue with Step 3. Specifies the IS-IS network entity title (NET) for the routing process. network-entity-title specifies the area address and the system ID for an IS-IS routing process. You can specify an address or a name for network-entity-title. Enables the router to generate and accept IS-IS only new-style type, length, and value (TLV) objects. Configures the IS-IS level at which the Cisco IOS software operates. When you specify level-1, the router acts as a station router and learns about destinations inside its area. For interarea routing information, the router depends on the closest level-1-2 (L1L2) router. When you specify level-1-2, the router acts as both a station router and an area router. The router has one link state database (LSDB) for destinations inside the area (L1 routing) and runs a shortest path first (SPF) calculation to discover the area topology. The router also has another LSDB with link state protocol (LSP) packets of all other backbone (L2) routers and runs another SPF calculation to discover the topology of the backbone, and the existence of all other areas. When you specify level-2-only, the router acts an area router only. This router is part of the backbone and does not talk to L1-only routers in its own area. Configures the router to flood MPLS traffic engineering link information into the IS-IS level you specify. The IS-IS level you specify must be the same level you specified in the preceding step. 20-21
MPLS Traffic Engineering DiffServ Aware Chapter 20 Step 7 Step 8 Step 9 Command Router(config-router)# passive-interface type number Router(config-router)# mpls traffic-eng router-id interface-name Router(config-router)# mpls traffic-eng area num Purpose Disables the IS-IS routing protocol from sending routing updates on the interface you specify. IS-IS advertises the IP address of the interface without actually running IS-IS on that interface. For type number, specify the loopback0 interface. Note When you enable passive-interface on an interface, IS-IS continues to advertise the subnet to other interfaces and continues to receive and process updates on the interface from other routers. Specifies that the traffic engineering router identifier for the node is the IP address associated with a specific interface. interface-name specifies the IP address associated with the loopback0 interface. Note For IS-IS configurations, this completes the activation of TE on the router. Do not continue to Step 9. Turns on MPLS traffic engineering for a particular OSPF area. Note Enter this command for OSPF configurations only. Do not enter this command for IS-IS configurations. Configuration Example for Activating Traffic Engineering on the Router Example 20-1 configures the router for TE using the OSPF routing protocol. Example 20-1 Activating Traffic Engineering on the Router Router(config)# mpls traffic-eng tunnels Router(config)# router ospf 100 Router(config-router)# network 10.1.1.0 0.0.0.255 area 0 Router(config-router)# network 10.16.1.1 0.0.0.0 area 0 Router(config-router)# mpls traffic-eng area 0 Router(config-router)# mpls traffic-eng router-id loopback0 Router(config-router)# exit 20-22
Chapter 20 MPLS Traffic Engineering DiffServ Aware Activating Traffic Engineering on the Interface To activate traffic engineering on the physical interface, enter the following commands beginning in global configuration mode: Command Purpose Step 1 Router(config)# interface type number Configures an interface and enters interface configuration mode. type is the type of interface (for example, serial). number is the number of the interface (for example, 1/0/0). Step 2 Step 3 Router(config-if)# ip rsvp bandwidth interface-kbps [sub-pool kbps] Router(config-if)# mpls traffic-eng tunnels Configuration Example for Activating Traffic Engineering on the Interface Enables Resource Reservation Protocol (RSVP) for IP on an interface. interface-kbps specifies the amount of bandwidth (in kbps) on an interface to be reserved. Valid values are from 1 to 10,000,000. (Optional) sub-pool kbps is the amount of bandwidth (in kbps) on an interface to be reserved to a portion of the total. Valid values are from 1 to the value of interface-kbps. Note The sum of bandwidth used by all tunnels on this interface cannot exceed interface-kbps and the sum of bandwidth used by all sub-pool tunnels cannot exceed sub-pool kbps. Enables MPLS traffic engineering tunnel signaling on the interface. Step 4 Router(config-if)# ip router isis Enables the IS-IS routing protocol on the interface. Note Do not enter this command if you are configuring an OSPF configuration. Example 20-2 configures TE on a physical interface using the IS-IS routing protocol. Example 20-2 Activating Traffic Engineering on a Physical Interface with IS-IS Router(config-if)# ip address 10.1.1.1 255.255.255.255 Router(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000 Router(config-if)# mpls traffic-eng tunnels Router(config-if)# ip router isis 20-23