Annex B: Tunneling

B.1 Overview

Consider a device that provides a layer 3 tunnel endpoint. Some packets will need to be en-tunneled and then will leave the device in the tunnel. Other packets will arrive at the device in the tunnel and will need to be de-tunneled. This is illustrated in Figure 16, in which green indicates application traffic, yellow indicates an IP interface, and pink indicates a tunnel (carrying green application traffic).

Figure 16: Tunneling Overview

The Figure highlights three decisions:

  1. Whether to en-tunnel an upstream packet.
  2. Whether to de-tunnel a downstream packet.
  3. To which egress interface to send an outgoing packet.

This egress interface decision is just a normal forwarding decision. By separately modeling the Tunnel interface and the Tunnel, the Device:2 data model is able to present the en-tunnel decision as also being a forwarding decision. The de-tunnel decision is not really a decision at all, because it happens automatically as a result of normal packet processing.

This modeling approach imposes no restrictions on the device implementation; it is just how the en-tunnel and de-tunnel decisions are modeled.

A Tunnel is not a stackable interface object, because it breaks the layering order and can be regarded as separating two different protocol stacks, one of which acts as a carrier for the other. This is clearly illustrated in Figure 20 and the other interface stack Figures.

Even though a Tunnel is not an interface, it can be referenced by QoS classification rules. Traffic arriving on a Tunnel instance, i.e., packets that have just been encapsulated, is conceptually similar to locally-generated traffic.

In summary, the decision to en-tunnel a packet is a forwarding decision to send a packet to an IP interface that is stacked above a Tunnel interface instance, and the decision to de-tunnel a packet is a consequence of the fact that it is addressed to the CPE and is therefore passed to a Tunnel instance. Figure 17 extends Figure 16 by expanding the tunnel into a Tunnel IP interface, a Tunnel interface, and the Tunnel instance, thereby showing where these two decisions are made.

Figure 17: Tunneling Overview (Showing Forwarding Decisions)

The existing 6rd, DS-Lite and IPsec data models use a less flexible approach in which the Tunnel interfaces are not explicitly modeled, and a separate non-stackable Tunnel table references auto-created Tunnel/Tunneled IP interface pairs. See Details for further details.

The Tunnel interface and Tunnel approach is more flexible because (a) it supports multiple flows / sessions with a tunnel (e.g., GRE traffic flows or L2TP sessions), (b) it supports additional encapsulation layers between the Tunnel IP interface and the Tunnel interface (e.g., PPP for L2TP), and (c) it supports layer 2 tunneling use cases (traffic is bridged directly to the Tunnel interface and there is no Tunnel IP interface). See Details for further details.

Figure 18 and Figure 19 show upstream and downstream examples of how the Tunnel interface and Tunnel instances are used to describe the traffic path through the device for both untunneled and tunneled packets.

Figure 18: Sample Flow of Upstream Tunneled Traffic through the Device
Figure 19: Sample Flow of Downstream Tunneled Traffic through the Device

The less flexible (Tunnel,Tunneled) IP interface mechanism is used in the following three cases:

The flexible Tunnel interface and Tunnel mechanism is used for the following two cases and will be used for modeling all future tunneling scenarios:

B.2 Details

Figure 20 shows the interface stack for a general layer 3 tunneling scenario. Compare with Figure 21), which is derived from Figure 17. It can be seen that each Figure presents a different view of the same thing.

Figure 20: General Layer 3 Tunneling Interface Stack
Figure 21: General Layer 3 Tunneling (from Tunneling Overview)

IP.Interface.3 is labeled as Type=Normal in Figure 20 but as Tunnel IP interface in Figure 21. IP interface Type=Tunnel was defined specifically for the (Tunnel,Tunneled) IP interface mechanism and is not needed because IP.Interface.3 is stacked above TT.Tunnel.1.Interface.1.

Figure 20 is general in that it is independent of the tunnel technology, but it doesn’t illustrate all the possibilities. If supported by the tunnel technology:

Figure 22 shows an L2TP [17] example that illustrates both of the above.

Figure 22: L2TP Interface Stack Example

Some tunneling technologies support layer 2 tunnels, in which the tunnel payload is a layer 2 packet. Figure 23 shows the interface stack for a general layer 2 tunneling scenario. This is conceptually similar to the layer 3 case, but a bridge port rather than an IP interface is stacked above the Tunnel interface.

Figure 23: General Layer 2 Tunneling Interface Stack