Home > Articles > Cisco Network Technology > General Networking > Traffic Engineering with MPLS

Traffic Engineering with MPLS

Chapter Description

This sample chapter offers a brief look at the DiffServ architecture and its interaction with IP and MPLS packets, the MQC, and DS-TE.

Label Stack Treatment

As mentioned earlier in this book, MPLS has 3 EXP bits in the label header that are used in much the same way as IP Precedence bits or the DSCP CS bits.

You should consider three cases. The first case is when IP packets enter an MPLS network. This is known as the ip-to-mpls case, often written as ip2mpls.

The second case is when packets that already have one or more labels have their label stack manipulated. This is known as the mpls-to-mpls case, or mpls2mpls.

The third case is when packets exit an MPLS network and have all their labels removed. This is known as the mpls-to-ip path, or mpls2ip.


Packets entering an MPLS network have one or more labels applied to an underlying IP packet. This is an ip2mpls push, because labels are pushed onto an unlabeled IP packet.

By default, when Cisco IOS Software pushes labels onto an IP packet, the most significant bits in the DiffServ field (the IP Precedence bits) are copied to the EXP field of all imposed labels.

Figure 6-2 shows an ip2mpls push.

Figure6-2Figure 6-2 ip2mpls Push


Similarly, when a label is pushed onto a packet that already has a label, the EXP value from the underlying label is copied into the EXP field of the newly imposed label. This is known as the mpls2mpls path.

Three actions are possible in the mpls2mpls path:

  • Push—An mpls2mpls push is when one or more labels are added to an already-labeled packet.

  • Swap—An mpls2mpls swap is when the topmost label on a packet is swapped for another label.

  • Pop—An mpls2mpls pop is when one or more labels are removed from a packet, but at least one label is left.

Figure 6-3 illustrates these three cases.

Figure6-3Figure 6-3 mpls2mpls Operations


Packets leaving an MPLS network have their label stack removed; this is known as the mpls-to-ip operation, or mpls2ip. The only operation in the mpls2ip case is a pop, as illustrated in Figure 6-4.

Figure6-4Figure 6-4 mpls2ip Pop

EXP and DSCP Are Independent

As you can see, the default Cisco IOS Software behavior is to propagate the IP Precedence bits (the three most significant DSCP bits) through your network.


To avoid confusion and to make things simpler, this chapter calls the bits that are copied from the IP header to the EXP field the "IP Precedence bits." This is deliberate; there is no DiffServ term that means "only the three most significant bits of the DSCP field." There are CSs, but to talk about copying the DSCP CS to EXP isn't accurate, because CS definitions cover all six of the DSCP bits. So, when you see text such as "IP Precedence is copied to EXP," this reminds you that only the three most significant DSCP bits are copied to the MPLS EXP field.

Two things interact to define the basic EXP and IP Precedence interaction:

  • Cisco IOS Software allows you to set the EXP value on a label independently of any IP or EXP values that might already be set.

  • In both the ip2mpls and mpls2mpls pop cases, nothing is done to the lower-level packet when labels are removed.

These two facts, when considered together, mean that if you set a packet's EXP values differently from the underlying IP packet, or if you change EXP values on the top of a label stack midway through your network, these changes are not propagated downward. Figure 6-5 shows this in action, by default, in both the mpls2mpls pop and mpls2ip.

Figure6-5Figure 6-5 Default EXP Treatment When Popping

Generally, this is acceptable. However, you might want to do things differently in some cases.

In Figure 6-5, you might want to preserve the fact that the outermost label has an EXP value of 0, even after that outermost label is removed and the underlying label (with an EXP of 3) is exposed.

This means copying the value of EXP 0 down and overwriting the value of EXP 3 in the underlying label. The motivation and mechanics of this scenario are explained in the upcoming "Tunnel Modes" section.

Per-Hop Behaviors in the ip2mpls and mpls2ip Cases

Another thing to consider is how your packets are treated if the outermost label on a packet has its EXP value set to something other than the EXP or IP Precedence underneath it. If you push a label of EXP 0 onto a packet with EXP 3 (or IP Precedence 3), how do you treat the packet as it leaves the box? Is the packet given PHB treatment as if it has EXP 0, or as if it has IP Precedence 3/DSCP 24? Figure 6-6 illustrates this question.

Figure6-6Figure 6-6 PHB Decision on Label Push

As it turns out, the case of label imposition is an easy one. The router doing the imposition always treats the packet according to the new outgoing PHB indicator. In Figure 6-6, this means that the packet is given PHB treatment for EXP 0.

The mpls2mpls and mpls2ip pop cases are not as straightforward. Figure 6-7 illustrates these cases.

Figure 6-7Figure 6-7 PHB Decision on Label Pop

In some cases, you will want the resulting packet to receive treatment according to the label that was removed, and in other cases, you will want the resulting packet to receive treatment according to the outermost indicator in whatever remains after the POP (MPLS EXP in the case of mpls2mpls and IP DSCP in the case of mpls2ip).

All these label operations can be confusing. The next section aims to unify them and make things easier to understand.

6. Tunnel Modes | Next Section Previous Section