MPLS Quality of Service – Part Two

In the pervious post, we went through the Uniform model and its configuration. In this post we are going 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 to show QoS features. 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)