This is a note on episode 102 of the fantastic-as-always Packet Pushers Podcast. Initially it was going to be destined for them and less than 140 characters long but I just couldn’t, so I started writing freely and all of this came up.

So, the whole episode is about analyzing if is MPLS tunneling. Maybe somebody asked the question or maybe there is some disagreement in the industry.

I found it very interesting (and fun, as usual) but after listening to the show it got me thinking: it’s the wrong question. It’s not if MPLS is tunneling, but if MPLS *can be used for* tunneling.

So before going deeper I also have to say that I have never implemented MPLS; I have labbed it but that’s about it. I don’t consider myself to have enough foundations or experience as these guys. I hope not to shoot myself in the foot. With that said…

Tunneling is an application of encapsulation. Transport, multiplexing and delivery are other applications of encapsulation. Protocols encapsulate their payload. I see Ethernet as layer 2 «delivery», IP as layer 3 «delivery» (or «transport» across multiple layer 2 domains), and 802.1Q as 1-factor multiplexing. I’m thinking TCP and UDP are 2-factor multiplexing.

I think we agree that IPv4 and IPv6 are network protocols, but you can create a tunnel with Hurricane Electric by setting the Protocol to 41 in IPv4, and without using GRE. The tunnel gets created by the way they are stacked and used.

So a valid question can be stated: am I setting up a tunnel when I start LDP and MPLS? So, from my point of view, the following are requirements for a tunnel to be made:

1. It is set up by or for a user outside of the domain of the transport network (even if the user is a network engineer in a data center). If I create a tunnel over the Internet, I’m the user outside of my ISP’s network. Note that I can tunnel over my own enterprise network; there is some interest in doing that and I’m the end user for that particular case. This takes away MPLS, but not MPLS VPN.

2. The tunnels created deliver the packet between two endpoints but neither of them are the final destination; or… well, technically yes, it can, but my point is that there is another endpoint higher in the OSI layers, even if it ends up being the same one. Once a packet gets delivered it gets decapsulated and further processed again for its delivery. Yes, Ethernet may fit here, but it doesn’t fit #1.

3. Two same or different delivery protocols with usually different address spaces are stacked onto each other. As such, there must be source and destination endpoint addresses endpoints in the encapsulated packet and in the lower-layer protocol. You may use the same address space, but most of the time it’s only a trick to get around some weird limitation. Oh, wait, just like tunnels! 😉

So, by how it works, no protocol is a tunneling protocol (well, except maybe IPSec in tunnel mode). It’s only by what it was designed for that can be called a «tunneling protocol».

Examples:
* ICMP is not a tunneling protocol but it can be used to create tunnels.
* Same for HTTP.
* It can be said that GRE is a tunneling protocol, but it doesn’t work by creating tunnels, but by encapsulating packets and making it easy to layer a protocol on top of another.

Was MPLS designed to do tunnels?

Best regards.