Herding Packets

A common discussion I hear among seasoned network geeks and newbies alike is what is different between the ideas of tagging/labeling, tunnels, and “regular” encapsulation. Usually the newbies are trying to grok the entire concept while the old hands are trying to wing curveball exception cases at one another. While it seems nothing is absolute in networking and the astute engineer can always find a case that violates the usual rules, here are the working definitions I use which I think are right for about 98% of cases.

Encapsulation

According to Wikipedia, encapsulation is defined as:

A method of designing modular communication protocols in which logically separate functions in the network are abstracted from their underlying structures by inclusion or information hiding within higher level objects.

Wowww. This is why people have trouble with these concepts. Encapsulation is what we generally think of as the “normal” way that network data is wrapped up for shipping across a wire. My working definition is:

Encapsulation: Wrapping a PDU (Protocol Data Unit) with a header (and optional trailer) from the next layer “down”

In other words, taking a layer 4 PDU (a TCP segment, for example) and sticking a layer 3 header (the IP packet header) on the front. Then taking that layer 3 IP packet, and surrounding that with a layer 2 Ethernet header and trailer.

The previously mentioned Wikipedia article actually does have a pretty decent graphical representation of this idea:

Source: Wikipedia

The slightly sticky part of the encapsulation “wrapper” model comes when making the jump from layer 2 to layer 1. Layer 2 is the last one that we think of as having some structure about its PDUs. At layer 1, it’s just bits — electrical voltage levels on a conductor or light pulses in a fiber. I suppose you can still think of this as the encapsulation of the data link (layer 2) frame in the various modulation method to get it on the wire but that’s a bit of a stretch to me.

Long story short, “encapsulation” is the process of taking application-layer data and moving it down the network protocol stack to get it out onto the physical medium. At the receiver, the opposite process occurs as the physical transceiver scoops up the bits from the wire and passes them back up the stack where each successive header (and trailer) is stripped off, eventually presenting the receiving application with a chunk of data. That end of the process is “decapsulation,” of course.

Encapsulation is really the only of these three terms that has a pretty crisp, hard-to-find-an-exception-to definition.

Tagging/Labeling

I’m grouping tagging and labeling together here, and they are similar in some ways but maybe not in every way. A tag is a bit of data that has been jammed into a protocol header to carry some extra data. My working definition is:

Tagging: Inserting extension data within an existing layer N header to be processed by a device understanding that extension.

The classic example of tagging is the 802.1Q VLAN tag. It is a tag in the purest sense, as it is literally jammed in the middle of the 802.3 header:

Source: Wikipedia

In this graphic, the top portion is a normal Ethernet frame. All the colored portions are fields of the Ethernet frame header (and the CRC/FCS is the trailer). In the bottom portion, you can see that an extra 4-byte hunk of data is jammed right in there between the source MAC address and the Ethertype field. The result is a frame that is larger than usual, and also has a piece of data that an Ethernet driver unfamiliar with 802.1Q tags will not understand and will probably discard as a corrupted frame. However, a receiver that knows about Q-tags will recognize the tag and use it to associate the frame with a VLAN.

As an aside, I find it interesting that the Ethertype field is generally used to indicate the upper-layer protocol type contained in the frame, such as 0x0800 for IPv4 or 0x86DD for IPv6. But 802.1Q frames include 2 bytes that act like an Ethertype field (and exist in the same position), carrying a value of 0x8100. This is used to help signal the presence of the VLAN tag, but it means that the Ethertype field is being used to signal the content of the frame itself, not the next protocol. An interesting bending of the rules.

Another “tag” use related to the 802.1Q extension is the 802.1p priority (QoS) tag. It actually uses the same tag format, but indicates a set of values, 0-7, to identify the Class of Service (COS) for that frame.

So what’s a label? Well, in terms of Multi Protocol Label Switching (MPLS) which was derived from Cisco’s Tag Distribution Protocol (TDP), it’s another way of marking a packet. So is an MPLS label or a TDP tag a “tag” based on my definition above? That’s open for debate. The label isn’t shoved in the middle of a protocol header, it’s actually inserted right between the layer 2 and 3 headers. This is why MPLS is sometimes called “layer 2½”. But it does have the property of being an extension of existing protocols inserted in a way that wouldn’t be understood by a receiver not running that extension.

Tunneling

Tunneling can mean lots of things, but the working definition I usually use is this:

Tunneling: Wrapping a PDU with another header from the same layer, or even a higher-layer header.

OK, so that definition will cover most tunneling cases, but what is tunneling used for? Usually it’s a means to provide an abstracted logical path over an existing  topology (for layer 3 protocols like IP) or to extend a topology over a path that can’t carry the underlying protocol end-to-end.

An example of a protocol used for tunneling to create an abstracted path is the Generic Routing Encapsulation (GRE) protocol. The RFCs call GRE an “encapsulation” protocol, and don’t specify a layer for it. I think that’s pretty apt after thinking about it for a bit. While writing this article I was going to call GRE a layer 4 protocol since it has an IP protocol number (47), but then IPv6 also has an IPv4 protocol number so that can’t be the “thing” that defines a layer 4 protocol. GRE isn’t a layer 3 protocol either, since the definition of a layer 3 protocol is that it handles logical addressing and GRE does not do this either (GRE has no addressing whatsoever). So calling it an “encapsulation” protocol is probably a pretty good name. This is what GRE looks like in action (well, protocol block diagram action):

However, when you take the “outer” IP header and the GRE header together, you are really getting the “layer N in layer N” effect I describe in my working definition. GRE’s function is mainly just to keep track of some of the particulars of the tunnel which the outer IP header may not need to be responsible for. As you can see in my lovely diagram above, what was originally an IP packet containing a TCP segment of HTTP traffic (as indicated by the “Protocol” value of 6) is prepended with a GRE header, and another IP header that describes the GRE packet (now with the “Protocol” value of 47). This is what allows GRE to hide the topology described by the inner IP packet within the topology provided by the outer IP packet — that’s our abstracted logical path. The network handling the GRE packet may have no awareness of the IP addresses contained by the inner IP header.

Another common case for tunneling a layer within itself is an IPv6 tunnel. Consider a statically configured IPv6 tunnel over an IPv4 network (commonly called a Protocol-41 tunnel because of the IPv4 protocol value assigned for carrying IPv6 in this way):

Here our TCP segment is put into an IPv6 packet (with Next Header value of 6, just like the IPv4 Protocol field). Then, an IPv4 header with Protocol 41 is slapped on the front. This allows us to send an IPv6 packet between two IPv6 enabled hosts, across a network that may be IPv4 only:

The IPv4 network carries the packet based on the IPv4 header fields and when it reaches the far side of the tunnel (another dual-stacked router) that router breaks out the IPv6 packet within and interprets the IPv6 headers to continue forwarding the packet on the IPv6 side. The topology abstraction has allowed us to tunnel IPv6 across an IPv4 network.

In some cases, a lower-layer protocol can even be transported within a higher-layer protocol. Examples of this might be VXLAN for carrying Ethernet frames between virtual Ethernet segments that are only reachable by routing between IP nodes, or L2TPv3 which can carry any number of layer 2 protocols over an IP network using “pseudo-wires.”

Conclusion

The concepts of encapsulating, tagging/labeling, and tunnels are all very much intertwined. Many, many cases can break my simple definitions. For example, I lump MPLS labels in with “tagging.” And while the MPLS label itself is functionally a tag in some ways, the features it enables, such as MPLS L2VPN or L3VPN more closely fit the definition of a tunnel. I don’t consider my classification of MPLS labels wrong, per se, but it may be tightly scoped. I like to say that someone new to networking, or even at an intermediate level should be focusing on what the “rules” are. An expert knows how and when to break them.

My definitions in this article may not be perfect in every case, but I find they have helped my brain process these different concepts. Hopefully this article has helped these concepts “click” for you too.