Context

This project examines the problem of hidden information, caused by MPLS clouds, to one of the most common form of active measurement: traceroute. In particular, we aim at developing, validating, and deploying new measurement techniques that would reveal the content of Internet wormholes caused by MPLS tunnels. Doing so, we should be able to improve our knowledge of MPLS deployment and usage by Internet Service Providers (ISPs). But we should also be able to revisit, deepen, and improve Internet model and topology generators.

MPLS

Figure 1: The MPLS label stack entry (LSE) format. An LSE is made of four fields, the label, the traffic class, the bottom of the stack, and the time-to-live.

The Multiprotocol Label Switching (MPLS) was originally designed to speed up the forwarding process. In practice, this was done with one or more 32 bits label stack entries (LSE) inserted between the frame header (Data-link layer) and the IP packet (Network layer). A given packet can manage several LSEs at the same time. In this case, the packet is said having a stack of labels. Each LSE is made of four fields, as illustrated in Fig. 1: a 20-bit label value used for forwarding the packet to the next router, a 3-bit Traffic Class field for quality of service (QoS), priority, and Explicit Congestion Notification (ECN), a 1-bit bottom of stack flag (when set the current label is the last in the stack), and an 8-bit time-to-live (LSE-TTL) field having the same purpose as the IP-TTL field.

Figure 2: General overview of MPLS (with PHP enabled). Here, there are three different LSPs between the Ingress LER and the Egress LER. LSPs between the Ingress LER and the Egress LER might be physically different (i.e., different IP addresses, as LSP1 and LSP3) or logically different (i.e., same IP addresses but different labels, as LSP1 and LSP2).

The first MPLS router (the Ingress Label Edge Router, or Ingress LER, i.e., the tunnel entry point) adds the label stack, while the last MPLS router (Egress Label Edge Router, or Egress LER, i.e., the tunnel exit point) removes the label stack (Ultimate Hop Popping, UHP, with explicit null labels -- label value of 0). In practice, and in most cases (at least this is the by default configuration), the top LSE is removed by the penultimate LSR (Penultimate Hop Popping, PHP with implicit null labels -- label value of 3), that we call the Penultimate Hop (PH). The Egress LER then performs a classic IP lookup and forwards the traffic, reducing so the load on it especially if the Egress LER is the root of large LSP-tree. This means that, when using PHP, the last MPLS operation (i.e., popping) is performed one hop before the Egress LER, on the PH. On the contrary, UHP is generally used only when the operator implements sophisticated traffic engineering operations considering a lookup of the Traffic Class field of the LSE on the Egress LER. Fig. 2 illustrates the main vocabulary associated to MPLS tunnels.

Historically, MPLS has been designed to reduce the time required to make forwarding decisions (an exact match in a LSE Label Information Base -- LIB -- is faster than a longest prefix match in a trie). Nowadays, MPLS has two main usages: (i) a basic encapsulation technique allowing to transparently transmit packets through an MPLS domain using best effort IP routes computed by an IGP, and (ii) a traffic engineering (TE) tool allowing to better control routing and resources used by some flows. These two different usages leverage two different signaling protocols to allocate and distribute labels (LDP and RSVP-TE).

Moreover, note that there exist other kinds of usage such as MPLS fast reroute to enable faster reaction to network failures with backup LSPs that are computed in a pro-active way. Eventually, one really promising MPLS usage, known as segment routing, will enable in a near future the possibility to easily define routing paths that are orthogonal to those ``forced'' by the IGP. Indeed, one may be able to recompose IGP paths as a collection of routing segments to deal with numerous interesting use cases such as load balancing, routing policies, or fast-rerouting.