Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Quality of Service in AToM

This final section of the chapter covers concepts and configuration on quality of service (QoS). You review the common QoS techniques that are applicable to all Layer 2 protocols over MPLS and then explore the protocol-specific aspects. This section tries to be as platform-independent as possible. However, you might find hardware-specific conditions that preclude support of some QoS features.

The QoS model for AToM follows the Differentiated Services (DiffServ) QoS architecture in Cisco IOS that uses the Modular QoS CLI (MQC). DiffServ defines a scalable QoS architecture that relies on the separation of complex edge versus simple core behaviors. The edge behaviors are summarized in a small number of classes defined in the DiffServ code point (DSCP). MPLS support for DiffServ is defined in RFC 3270. It uses the Experimental bits in the MPLS header, also referred to as class of service (CoS) bits for the few classes that DiffServ uses to which LSPs are mapped.

The MQC model can be summarized as follows:

Interesting traffic is defined and classified as one or more classes using the class-map command.

Policies pertaining to these classes are defined using the policy-map command.

The policies are applied to either the input or output direction of the traffic flow using the service-policy command.

Case Study 9-13: Traffic Marking

The first of the QoS building blocks is the marking of traffic by setting the MPLS Experimental (Exp) bits. You apply the Exp bit setting to both the pseudowire and tunnel labels because of the possibility of PHP, which removes the tunnel label at the penultimate hop. This traffic marking based on the Exp bits is meaningful if the core network performs differentiated treatment of different classes, such as by queuing highest class traffic in a strict priority queue.

Figure 9-1.

Example 9-60. Setting Exp Bits

hostname PE1
!
class-map match-any all_traffic            
  match any                                
!
policy-map exp3                            
  class all_traffic                        
   set mpls experimental 3                 
!
policy-map exp5                            
  class all_traffic                        
   set mpls experimental 5                 
!
interface ATM4/0.1 point-to-point
description *** AAL5 SDU AToM to CE1 ***
pvc 0/100 l2transport
encapsulation aal5
xconnect 10.1.1.2 100 encapsulation mpls
  service-policy input exp3                
!
interface ATM4/0.2 point-to-point
description *** Cell VC AToM to CE1 ***
pvc 0/200 l2transport
encapsulation aal0
xconnect 10.1.1.2 200 encapsulation mpls
  service-policy input exp5                

The class-map all_traffic matches all traffic in which the corresponding service-policy is applied. Instead of defined class, you could have used the built-in class-default to obtain the same results. The policy-map exp3 sets the Exp bits to 3 for all the classified traffic (that is, all traffic). This policy is applied as an input service-policy to the ATM AAL5-SDU mode AC. Similarly, the policy-map exp5 sets the Exp bits to 5 and is applied to the ATM Cell Relay VC AC. Therefore, all traffic that is incoming into ATM PVC 0/100 and 0/200 is encapsulated with the MPLS Exp bits set to 3 or 5, respectively. You can also perform traffic marking using policing.

You can see this service policy working in Example 9-61 by enabling the debug mpls packets in PE2 and sending 5 default size (100 Bytes) PING packets from CE1 to CE2 in each PVC. Do not enable the debug mpls packets command in production networks.

Example 9-61. QoS Traffic Marking Verification

PE2#
*Jun 2 11:26:17.733: MPLS: Fa0/0: recvd: CoS=3, TTL=2, Label(s)=19
*Jun 2 11:26:17.737: MPLS: Fa0/0: recvd: CoS=3, TTL=2, Label(s)=19
*Jun 2 11:26:17.737: MPLS: Fa0/0: recvd: CoS=3, TTL=2, Label(s)=19
*Jun 2 11:26:17.737: MPLS: Fa0/0: recvd: CoS=3, TTL=2, Label(s)=19
*Jun 2 11:26:17.741: MPLS: Fa0/0: recvd: CoS=3, TTL=2, Label(s)=19
PE2#
*Jun 2 11:26:26.793: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.793: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.793: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.793: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.793: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.793: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21
*Jun 2 11:26:26.797: MPLS: Fa0/0: recvd: CoS=5, TTL=2, Label(s)=21

You can see from Example 9-61 that all the MPLS packets are arriving with the VC label only because of PHP, and the TTL of the VC label is 2. The first five MPLS packets have the Exp bits set to 3. These are the five 100-byte PING packets encapsulated in ATM AAL5-SDU mode, and the Exp bits are set by the policy-map exp3 on PE1. The output of the debug command shows the Exp value as CoS. After these five packets, you see 15 packets with the Exp set to 5. These are the five 100-byte PING packets that are encapsulated in ATM Cell Relay VC mode without cell packing. Each packet is broken into three ATM cells, and therefore three corresponding AToM packets. The Exp bits are set to 5 as defined in the policy-map exp5 on PE1.

Note

For ATM Cell Relay VP mode with QoS configuration, configure each ATM permanent virtual path (PVP) into its own multipoint ATM subinterface, and apply the service policy to the subinterface. This allows you to apply various service policies with unique policy actions such as marking or policing to the different ATM PVPs. In contrast to ATM PVC configuration, the atm pvp command-line interface (CLI) command does not enable a configuration submode.

The case for other Layer 2 transports is analogous, applying the service-policy in the main interface for ATM CRoMPLS Port mode, High-Level Data Link Control over MPLS (HDLCoMPLS), PPP over MPLS (PPPoMPLS), Ethernet over MPLS (EoMPLS), and in the subinterface for EoMPLS VLAN mode and ATM cell relay over MPLS (CRoMPLS) VP mode. The case for Frame Relay over MPLS (FRoMPLS) is slightly different. It is covered in "Case Study 9-17: ===Layer 2-Specific Matching and Setting."

Case Study 9-14: Traffic Policing

Policing CE traffic is similar to marking. The difference is the policy action taken with the classified traffic. The following two modes support policing actions for Frame Relay, ATM, and Ethernet:

Single-rate policer Policed traffic is checked against a single committed information rate (CIR).

Dual-rate policer Policed traffic is checked against two rates: CIR and peak information rate (PIR). This policer for IP networks is modeled after the Frame Relay policer.

The two policing modes can have color-awareness enabled or disabled:

Color-blind All the policed traffic is treated equally and policed against the same rate or rates.

Color-aware A user-defined criteria preclassifies policed traffic and checks it against different rates depending on the preclassification result. To this extent, you can use the conform-action and exceed-action commands under the police configuration mode to color traffic to be policed. Packets that are not classified under either the conform-action or exceed-action class belong to the violate-action class.

Example 9-62 shows a single bucket color-blind policing action.

Example 9-62. Single Bucket, Color-Blind Policing

hostname PE1
!
class-map match-any all_traffic
match any
!
policy-map policing
class all_traffic
   police cir 128000                        
     conform-action set-mpls-exp-transmit 5 
     exceed-action drop                     
!
interface ATM4/0.2 point-to-point
description *** Cell VC AToM to CE1 ***
pvc 0/200 l2transport
encapsulation aal0
xconnect 10.0.0.203 200 encapsulation mpls
  service-policy in policing                

A dual rate color-aware policer configuration is included in Example 9-66 in Case Study 9-17. Cisco IOS implements the single rate three-color policer based on RFC 2697 and the dual rate three-color policer based on RFC 2698.

Case Study 9-15: Queuing and Shaping

In general, the following features are supported for queuing and shaping actions:

Low-latency queuing (LLQ), also called priority queuing (PQ) The LLQ is a strict priority first-in, first-out (FIFO) queue. Strict priority queuing allows delay-sensitive data to receive a preferential queuing treatment by being dequeued and serviced before any other queues.

Class-based weighted fair queuing (CBWFQ) CBWFQ provides fair queuing based on defined classes with no strict priority. The weight for a packet that belongs to a specific class is given from the bandwidth that you assigned to the class.

Byte-based weighted random early detection (WRED) WRED drops packets selectively based on IP precedence. The higher the IP precedence, the less likely packets are to be dropped.

You can see egress queuing policies to provide CIR guarantees in Example 9-63.

Example 9-63. Queuing Configuration for CIR Guarantees in Frame Relay Pseudowires

!
hostname PE1
!
class-map match-all CustomerA
  match fr-dlci 100                  
class-map match-all CustomerB
  match fr-dlci 200                  
!
policy-map CIR_guarantee             
class CustomerA
bandwidth 128
class CustomerB
bandwidth 256
!
interface Serial3/1
no ip address
 service-policy output CIR_guarantee 
encapsulation frame-relay
frame-relay intf-type dce
!

In this example, customers use two seperate DLCIs in the same Frame Relay interface. Using a different class-map for each DLCI allows you to apply CBWFQ with the bandwidth command to each class for each DLCI. In addition, FRoMPLS supports traffic shaping and ATMoMPLS supports class-based shaping on ATM VCs.

You can accomplish per-class traffic shaping for ATM PVC and PVP ACs with the ATM PVC and PVP service type configuration using the following commands:

cbr {PCR}

ubr {PCR}

vbr-rt {PCR} {SCR} [MBS]

vbr-nrt {PCR} {SCR} [MBS]

Note

The distributed forms of these features are supported in distributed switching platforms, such as the Cisco 7500 series.

All queuing and shaping features are applied in the outbound direction. Marking and policing are input policies.

Case Study 9-16: Intermediate Markings

In this case study, you learn how to apply QoS actions on an egress interface based on matching criteria used at the ingress interface. This can be useful, for example, to match traffic based on MPLS Exp bits from the MPLS network and perform a policy action on packets going out of the egress interface.

Two internal markings called qos-group and discard-class preserve the classification that happened before the MPLS header popping operation. This classification would otherwise be lost when applying an output service-policy on the AC. The QoS group ID identifies an internal class, and the Discard Class identifies an internal precedence. These two intermediate markings "remember" the classification from the MPLS network. You can use the intermediate step to mark traffic from the MPLS network with a qos-group ID and use this qos-group ID to apply policy actions on the egress interface. Example 9-64 shows you how to set the ATM CLP bit in cells going toward the CE device based on the MPLS Exp bits received from the P router.

Example 9-64. Intermediate Marking

!
hostname PE1
!
class-map match-all exp3
match mpls experimental 3
class-map match-all qosg_class            
  match qos-group 1                       
!
policy-map clp1
  class qosg_class                        
set atm-clp
policy-map qosg
class exp3
   set qos-group 1                        
!
interface Serial4/0
ip unnumbered Loopback0
mpls ip
 service-policy input qosg                
!
interface ATM5/0
no ip address
pvc 0/100 l2transport
encapsulation aal5
xconnect 10.1.1.2 100 encapsulation mpls
  service-policy out clp1                 
!
!

You can see from Example 9-64 that the service-policy qosg is applied to traffic coming into the PE device from the P router on interface Serial4/0. With this service-policy, MPLS packets with Exp = 3 (from the class exp3) are marked with the qos-group of 1. On AC PVC 0/100 in ATM5/0, the outbound service-policy clp1 is applied. This service policy sets the ATM CLP bit for cells that were previously marked with a qos-group of 1. With this internal qos-group ID marking, a classification is conveyed from one interface to another.

Case Study 9-17: Layer 2Specific Matching and Setting

Different Layer 2 protocols comprise different characteristics and sometimes have an impact on the QoS configuration. This case study discusses the protocol-specific QoS characteristics and configuration. Table 9-2 outlines the different matching and setting criteria based on Layer 2 protocol.

Layer 2 Protocol

Matching

Setting

Ethernet over MPLS QoS

Ethernet frames that use IEEE 802.1q encapsulation contain the 802.1p CoS bits, which you can use for traffic classification (see Example 9-65).

Example 9-65. Traffic Classification

hostname PE1
!
class-map match-any cos2                
  match cos 2                           
!
policy-map eompls3
  class cos2                            
   set mpls experimental 3              
class class-default
set mpls experimental 0
!
interface Ethernet0/0.10
description *** To CE1 ***
encapsulation dot1Q 10
xconnect 10.1.1.2 10 encapsulation mpls
 service-policy input eompls3           

In Example 9-65, the Exp bits are set to 3 for traffic matching a CoS value of 2, and the rest of the traffic always matches the default class, which sets the Exp bits to 0. Besides traffic marking, policing is also supported.

In EoMPLS, the service policy is applied on the main interface for port mode EoMPLS and in the subinterface for VLAN mode EoMPLS.

Some platforms support a match vlan classification directive for a VLAN range, as follows:

  class-map match-any ethernet
 match vlan 3-5   

However, no platforms support a set vlan policy or include a set vlan command. The VLAN rewrite configuration was covered in detail in Chapter 7, "LAN Protocols over MPLS Case Studies."

Frame Relay over MPLS QoS

With FRoMPLS, you can match traffic using Frame Relay specific fields. The following QoS directives are specific to Frame Relay:

Matching:

match fr-de

match fr-dlci

match fr-dlci range

Setting:

set fr-de

set fr-fecn-becn

Example 9-66 shows a dual-rate color-aware policer using Frame Relay-specific fields.

Example 9-66. Dual-Rate Color-Aware Policer

hostname PE1
!
class-map match-any FR_DLCI_100            
  match fr-dlci 100                        
class-map match-any FR_DE0                 
  match not fr-de                          
!
policy-map FR_Policing
class FR_DLCI_100
   police cir 64000 pir 128000             
     conform-color FR_DE0                  
     conform-action set-mpls-exp-transmit 5
     exceed-action set-mpls-exp-transmit 2 
     violate-action drop                   
class class-default
set mpls experimental 0

In the FR_DE0 class, the not qualifier matches traffic that does not have the DE bit set. The FR_DE0 class is used for the color.

This policer allows policing traffic according to the color classification of whether the discard eligible (DE) bit is set in incoming Frame Relay frames. With this policy, only packets that do not have DE set are policed against CIR and PIR. Packets that do have the DE bit set are not treated as conforming. They are policed against PIR to determine whether they are exceeding or violating.

To apply this policy, you need to create a subinterface effectively to map to the Frame Relay PVC. This is accomplished with the command switched-dlci in Cisco 12000 series router platforms (see Example 9-67).

Example 9-67. Mapping a Subinterface to the Frame Relay PVC

interface POS4/0
encapsulation frame-relay cisco
!
interface POS4/0.1 point-to-point
 switched-dlci 100                        
 service-policy input FR_Policing         
!
connect frompls101 POS4/0 100 l2transport
xconnect 10.0.0.203 70 encapsulation mpls

Applying the FR_Policing policy to the point-to-point subinterface POS4/0.1 effectively applies the policy to the local AC that is defined with the connect command.

ATM over MPLS QoS

Currently, the only ATM-specific field for matching or setting is the cell loss priority (CLP) bit in the ATM Cell header. For ATM over MPLS, you can apply a service policy under an interface, a subinterface, or a PVC.

You can use the commands match atm clp and set atm-clp to match and set the ATM CLP bit, respectively.

Example 9-68 demonstrates how to use these two commands.

Example 9-68. Matching and Setting ATM CLP

!
hostname PE1
!
class-map match-all not-clp
  match not atm clp                       
policy-map exp-4
class not-clp
   set mpls experimental 4                
policy-map atm-clp
class class-default
   set atm-clp                            
!
interface ATM5/0
pvc 0/100 l2transport
encapsulation aal5
xconnect 10.1.1.2 100 encapsulation mpls
  service-policy input exp-4              
  service-policy output atm-clp           
!
!

You can see in Example 9-68 that because of the qualifier not, the class-map not-clp matches on all incoming ATM cells in PVC 0/100 that have the CLP bit clear. All AToM packets that encapsulate these matched cells have the MPLS Exp bits set to a value of 4. In addition, the service policy atm-clp that is applied in the same PVC in the outbound direction is setting the ATM CLP bit for all cells out of the PVC, because the set atm-clp directive is applied to the class-default for all outbound ATM cells.