Tunnel Modes
So far, you've seen two independent questions:
How is the queuing indicator (IP Precedence or MPLS EXP) propagated up and down the label stack and upon exit from the MPLS network?
In the mpls2mpls and mpls2ip pop cases, which PHB does the resulting packet get?
This section covers reasons why you might want to enforce different behaviors, as well as the mechanisms being defined to standardize those behaviors.
Currently, a set of behaviors are being defined that give you a set of mechanisms to control EXP values in various scenarios. These mechanisms are called tunnel modes. Three tunnel modes are defined in RFC 3270:
Uniform
Short-Pipe
Pipe
These modes are defined in the same IETF draft that defines L-LSP—“MPLS Support of Differentiated Services” (draft-ietf-mpls-diff-ext), which might well be an RFC by the time you read this. Because this is a developing technology, this chapter does not cover CLI commands for configuring tunnel modes. However, it's worth understanding the concepts behind tunnel modes so that you can design your network accordingly. If you're interested in the current state of affairs regarding tunnel mode in Cisco IOS Software, check CCO for availability.
Uniform Mode
In Uniform mode, any changes made to the EXP value of the topmost label on a label stack are propagated both upward as new labels are added and downward as labels are removed. The idea here is that the network is a single DiffServ domain, so any changes made to the EXP values on the MPLS packet in transit are supposed to be applied to all labels underneath the packet, as well as to the underlying IP packet.
The rules for Uniform mode are as follows:
On imposition, copy the DSCP/EXP upward.
On disposition, copy the removed EXP downward to both IP packet and MPLS (if stacked).
The question of deciding which PHB is applied on label disposition is irrelevant; no matter when you apply the PHB according to the received EXP value or the outgoing EXP/DSCP value, they're both the same.
Table 6-5 shows the EXP treatment in Uniform mode.
| Push | Swap | Pop | |
|---|---|---|---|
| ip2mpls | Copies the IP Precedence into the newly imposed label. | N/A | N/A |
| mpls2mpls | Copies the received EXP into the newly imposed EXP. | Copies the received EXP into the newly imposed EXP. | Copies the removed EXP into the newly revealed label. |
| mpls2ip | N/A | N/A | Copies the removed EXP into the DSCP. |
Figure 6-8 illustrates a case where a new label is pushed onto the stack with EXP 0 and, as this label is popped off, the underlying label (previously EXP 3) is changed to EXP 0.
Figure 6-8. Uniform Mode Packet Handling
You would apply Uniform mode when both the IP and the MPLS network are in the same DiffServ domain. You use Uniform mode if you want a change in EXP somewhere in your network to affect how the IP packet is treated after it exits the MPLS portion of the network.
Short-Pipe Mode
Short-Pipe mode is useful for ISPs implementing their own QoS policy independent of their customer's QoS policy. The IP Precedence bits on an IP packet are propagated upward into the label stack as labels are added. When labels are swapped, the existing EXP value is kept. If the topmost EXP value is changed, this change is propagated downward only within the label stack, not to the IP packet.
Table 6-6 shows EXP treatment in Short-Pipe mode.
| Push | Swap | Pop | |
|---|---|---|---|
| ip2mpls | Copies the IP Precedence into the EXP. | N/A | N/A |
| mpls2mpls | Copies the received EXP into the newly imposed EXP. | Copies the received EXP into the newly imposed EXP. | Copies the removed EXP into the newly revealed EXP. |
| mpls2ip | N/A | N/A | Doesn't modify the DSCP; selects the PHB based on the DSCP. |
Figure 6-9 illustrates this.
Figure 6-9. Short-Pipe Mode Packet Handling
The only difference between Uniform and Short-Pipe mode is that any changes to the label stack EXP are propagated throughout the MPLS network, but—in Short-Pipe mode—the underlying IP packet DSCP is not touched.
What about PHBs? There are two rules in Short-Pipe mode:
In the mpls2mpls pop case, the received EXP is propagated downward, so the question of which EXP value decides the PHB is moot.
In the mpls2ip pop case, the PHB is decided based on the DSCP on the IP packet that's revealed after the label stack is removed.
The assumption in Short-Pipe mode is that the link between the provider and the customer is where the mpls2ip processing happens. Because the customer is paying for the link between the provider and the customer, the customer is the one in charge of the queuing on that link, so the outgoing packet in the mpls2ip case is queued according to the DSCP the customer sent the packet into the network with.
Pipe Mode
Pipe mode is just like Short-Pipe mode, except the PHB on the mpls2ip link is selected based on the removed EXP value rather than the recently-exposed DSCP value. The underlying DSCP in the packet is not touched, but the mpls2ip path does not consider the DSCP for queuing on the egress link.
Table 6-7 shows EXP treatment in Pipe mode.
| Push | Swap | Pop | |
|---|---|---|---|
| ip2mpls | Copies the IP Precedence into the EXP. | N/A | N/A |
| mpls2mpls | Copies the received EXP into the newly imposed EXP. | Copies the received EXP into the newly imposed EXP. | Copies the removed EXP into the newly revealed EXP. |
| mpls2ip | N/A | N/A | Doesn't modify DSCP; selects the PHB based on the EXP. |
Figure 6-10 illustrates this.
Figure 6-10. Pipe Mode Packet Handling
When might you want to use Pipe mode? Pipe mode is useful if the ISP is the one that decides what the PHB selection is on the link immediately exiting the MPLS network. Typically, this is in a managed CPE scenario, in which the ISP does not want to extend MPLS all the way out to the CPE but wants PHB selection control over the link to the CPE.