Universal Transport Interface: L2TPv3's Predecessor

The prestandard predecessor for L2TPv3 was a Cisco proprietary protocol known as Universal Transport Interface (UTI). UTI's goal was to provide a high-performance IP-based tunneling mechanism for circuit-like Layer 2 connectivity (that is, pseudowire) over a packet-based core. UTI has no inherent signaling mechanism. Layer 2 frames from the attachment circuits are encapsulated with the necessary UTI formatting and are forwarded towards the remote endpoint. After the received frame is validated, the original data-link payload is forwarded out the appropriate attachment circuit. Figure 10-1 illustrates this connectivity model.

Figure 10-1. UTI Connectivity Model

[View full size image]

R1 and R2 are provider edge (PE) routers with connectivity to each other through an IP core. These PE routers provide pseudowire connectivity via two separate UTI tunnels: Tunnel 1 for the serial line connectivity between the customer edge (CE) routers, R3 and R4, and Tunnel 2 for Ethernet connectivity between LAN 1 and LAN 2. Assuming the serial lines are using Frame Relay encapsulation, a Frame Relay frame from R3 is encapsulated with a UTI header for UTI Tunnel 1 and an IP header with the destination address of R2. After R2 verifies the UTI header contents, it de-encapsulates the original Layer 2 payload and sends it to R4. Likewise, LAN 1 and LAN 2 are essentially bridged across UTI Tunnel 2 in a similar fashion.

UTI also attempts to optimize performance by avoiding suboptimal tunnel identification and parsing schemes that are present in other tunneling protocols. For example, generic routing encapsulation (GRE) tunnel identification requires a lookup on a combination of the source and destination address pair or tunnel key depending on RFC implementation: RFC 2784, RFC 1701, or RFC 2890. UTI's encapsulation shown in Figure 10-2 is designed to avoid some of the overhead that is required in tunnel identification and parsing by means of a tunnel ID that identifies the tunnel context on the de-encapsulating system.

The UTI encapsulation consists of the following fields:

• Delivery Header The Delivery Header is the header that carries the UTI packet across the packet core. Although this header can be an IPv4 or IPv6 header, the initial Cisco implementation supports only an IPv4 header without IPv4 options and an IP protocol number of 120. Fragmentation is not supported, so the IPv4 Don't Fragment (DF) bit is set. Therefore, the IP MTU of any intermediate links along the tunnel path should be sufficiently large to carry the largest Layer 2 packet.

• UTI Payload Independent Header The Payload Independent Header is composed of the following two subcomponents:

  Tunnel Identifier The Tunnel Identifier, sometimes referred to as a Session Identifier, is a 4-octet value that distinguishes the tunnel at the de-encapsulating endpoint. The Tunnel Identifier represents a unidirectional session. A bidirectional tunnel has two identifiers: a local and remote value. If the tunnel identifier does not match the tunnel value on the de-encapsulating endpoint, the packet is discarded. The UTI specification reserves value 0x00000000 and limits the user-defined tunnel identifier to the first 10 bits, leaving 1023 available values.

  Tunnel Key The Tunnel Key is an 8-octet field used to avoid misconfiguration or malicious attempts that lead to inserting unwanted traffic into the Layer 2 stream. The tunnel key value must match on both ends of the de-encapsulating endpoint; otherwise, the packet is discarded. The tunnel key is configured using a high key (the most significant 4 bytes) and low key value (the least significant 4 bytes).

• UTI Payload-Dependent Header The Payload-Dependent Header contains any payload information that is essential for the egress PE to properly forward the original Layer 2 frame toward the CE. The Cisco implementation does not define this header value and is not used.

• UTI Alignment Padding Alignment Padding ensures that the payload is aligned to a byte boundary that might assist implementations to more efficiently parse the payload. Although this field is defined in the UTI specification, Alignment Padding was never used in the initial Cisco implementation.

• Payload Payload is the original data link layer frame transported by UTI. This can be a Frame Relay, Ethernet, HDLC, or PPP frame.

Although UTI fulfilled its original goal of providing pseudowire connectivity, it had some limitations. As mentioned earlier in this section, one of UTI's restrictions is that it does not support IP fragmentation; therefore, the end-to-end packet-switched core MTU must be greater than the size of the UTI encapsulated packet.

Furthermore, although UTI eventually added support for an optional keepalive mechanism, this only detected whether the remote endpoint was no longer reachable and had no granularity at a pseudowire level. Because no inherent signaling method was available, UTI could not signal an individual pseudowire state. For example, in Figures 10-1, if R3's Frame Relay permanent virtual circuit (PVC) failed, the PE routers would not have a way to signal that information to each other so that R2 could signal that information via Local Management Interface (LMI) to R4. Instead, R4 and R2 would consider the Frame Relay PVC to be active, and R2 would continue sending Frame Relay traffic to the opposing PE router.

Another UTI limitation was the lack of a signaling protocol, which required that Tunnel Identifiers and Tunnel Keys be manually configured and preprovisioned on each PE router for each pseudowire. Although some providers might prefer the simplicity of manual provisioning, this can be operationally infeasible for large deployments.

Finally, UTI was a Cisco proprietary protocol. As such, it prohibited multivendor interoperable implementations. An open standards-based IP pseudowire solution that overcame these limitations was required.