MPLS QoS

The Quality of Service (QoS) has become more popular than past few years, because of high-bandwidth and delay sensitive applications. QoS is prioritizing more important data over less important traffic. There are two ways to implement QoS in an IP network: IntServ and DiffServ. Internet is operating based on best-effort model.

As the DiffServ model does not require a signaling protocol such as RSVP, it’s more popular or better to say the only applicable model in today’s networks. (Although we use RSVP in MPLS TE for path signaling and reservation).

IETF in RFC 3270 has recommended three QoS models for DiffServ tunneled traffic in MPLS networks:

• Pipe model
• Short Pipe model
• Uniform model

The Pipe and Short Pipe models are almost the same: They do not change IP ToS of customers data at all. They might change the EXP field in the path (EXP of MPLS Label) but the IP header QoS field remains unchanged. The Pipe model performs forwarding/discarding/scheduling based on EXP at the egress LSR while the Short Pipe model does that based on IP ToS. Because in the Short pipe model there might be no label at all. (remember PHP operation – Penultimate-Hop Popping)

In the Uniform model, there’s no guarantee that ToS of customers packet remains intact, but the EXP and IP ToS fields of a data packet will always show the same thing. It means if the provider changes the EXP header, that will be copied later to the IP ToS field at the egress point.

IOS Default Behavior:

In short IOS does not change your QoS in the path if you don’t change it. 

        Imposition – Copy TOS bits to EXP (TOS Reflection) when adding labels by ingress LSR.
        Swap – Copy EXP from old label to new label.
        Disposition – Do NOT Copy EXP from label to IP.

Configuration

Label to Label (on PHP) sets EXP 5 (if top is 5) after disposing the top label:

     class-map match-all in1
      match mpls experimental topmost 5
     class-map match-all out1
      match qos-group 5
    !
     policy-map in1
      class in1
       set qos-group mpls experimental topmost
     policy-map out1
      class out1
       set mpls experimental topmost 5
    !
    interface Ethernet0/0
     service-policy input in1
    !
    interface Ethernet0/1
     service-policy output out1
    !

Label to IP (on PE) sets precedence 5 (if top is 5) after popping the label:

         class-map match-all in1
          match mpls experimental topmost 5
         class-map match-all out1
          match qos-group 5
        !
         policy-map in1
          class in1
           set qos-group mpls experimental topmost
         policy-map out1
          class out1
           set ip precedence 5
        !
        interface Ethernet0/0
         service-policy input in1
        !
        interface Ethernet0/1
         service-policy output out1

Scenario

In this sceniaro based on the service provider’s policy, the EXP value is changed in the path and is copied to inner label by P router. At the egress LSR, the EXP value is copied to the DSCP. (Uniform model)

Ingress PE:

!
policy-map out1
  class class-default
   set mpls experimental topmost 7
policy-map in1
  class class-default
   set mpls experimental imposition 3
!

P:


!
class-map match-any in1
  match mpls experimental topmost 0  1  2  3  4  5  6  7
class-map match-any out1
  match qos-group 0
  match qos-group 1
  match qos-group 2
  match qos-group 3
  match qos-group 4
  match qos-group 5
  match qos-group 6
  match qos-group 7
!
policy-map in1
  class in1
   set qos-group mpls experimental topmost
policy-map out1
  class out1
   set mpls experimental topmost qos-group
!

Egress PE:

!
class-map match-any in1
  match mpls experimental topmost 0  1  2  3  4  5  6  7
class-map match-any out1
  match qos-group 0
  match qos-group 1
  match qos-group 2
  match qos-group 3
  match qos-group 4
  match qos-group 5
  match qos-group 6
  match qos-group 7
!
policy-map in1
  class in1
   set qos-group mpls experimental topmost
policy-map out1
  class out1
   set precedence qos-group
!

To see the differences between the Uniform model and the Pipe model. As mentioned earlier in the Part one of MPLS Quality of Service, the Pipe model does not change customer marking (IP TOS – DSCP). So in the following example, we will see that the provider is able to change the EXP marking but will not change the packet marking in the end. Provider also performs QoS tasks (even at the egress LSR) based on EXP and MPLS QoS marking, not based on IP header properties (Short-pipe model is different in this case).

As depicted in the above picture, egress PE is configured to send an Explicit Null to the P router. In this case the egress PE will be able to see transport label EXP field as well as VPN label EXP field.

R1(config)#mpls ldp explicit-null


R0#show mpls forwarding-table Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop   
tag    tag or VC   or Tunnel Id      switched   interface             
16     Pop tag     3.3.3.3/32        0          Et0/0      192.168.30.3
17     0           1.1.1.1/32        137        Et0/1      192.168.10.1

In this case, on R0 (the P router) we don’t need to copy EXP from topmost label (received from R3) to the topmost transport label sent to R1, because the Explicit Null (label 0) maintains the EXP bit. This is only one example for practicing purpose and learning the MPLS QoS feature. In this example, we like to perform our marking on the topmost label and not rely on the second label, to demonstrate explicit-null feature. The Uniform and the Pipe models difference is not in the ingress part but in the egress: to save or not to save the customer marking on the IP packet.

Configuration

Ingress PE: !
access-list 110 permit icmp host 5.5.5.5 host 6.6.6.6
!
class-map match-any in1
  match access-group 110
class-map match-any out1
  match qos-group 7
!
policy-map in1
  class in1
   set mpls experimental imposition 3
   set qos-group 7
policy-map out1
  class out1
   set mpls experimental topmost 7
!
R3#sh policy-map interface e0/0
Ethernet0/0
  Service-policy output: out1
    Class-map: out1 (match-any)
      10 packets, 1220 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 7
        10 packets, 1220 bytes
        5 minute rate 0 bps
      QoS Set
        mpls experimental topmost 7
          Packets marked 10
    Class-map: class-default (match-any)
      28 packets, 11442 bytes
      5 minute offered rate 3000 bps, drop rate 0 bps
      Match: any
P:
no configuration!

Egress PE:
!
class-map match-all in1
  match mpls experimental topmost 7
class-map match-all out1
  match qos-group 7
!
!
policy-map in1
  class in1
   set qos-group 7
policy-map out1
  class out1
   priority 256
  class class-default
   shape average 500000
!
R1#sh policy-map interface e0/1
Ethernet0/1
  Service-policy output: out1
    Class-map: out1 (match-all)
      10 packets, 1140 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: qos-group 7
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 256 (kbps) Burst 6400 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0
    Class-map: class-default (match-any)
      20 packets, 2080 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Traffic Shaping

Why there is no configuration on P LSR? Because IOS by default maintains your EXP and as long as PE LSR requesting Explicit Null, the topmost label is kept and contains EXP value of incoming labeled packet. (there’s no label disposition on the P LSR – R0)