Layer 2 Vpn Architectures [Electronic resources]

WAN Protocols over L2TPv3 Technology Overview

Chapter 11, "LAN Protocols over L2TPv3 Case Studies," presented the configuration steps for LAN protocols over L2TPv3. In the broadest sense, the configuration, transport, and tunneling of WAN protocols over L2TPv3 are analogous to what was explored in Chapter 11; however, differences and special cases exist. When you transport WAN protocols using L2TPv3, the fundamental control plane does not change. Different virtual circuit (VC) types indicate the specific attachment circuit technology. This section presents some opening ideas about the transport of WAN protocols using L2TPv3.

Control Plane

All the control plane concepts covered in Chapter 10 are applicable to the transport and tunneling of WAN protocols. On session negotiation, the type of attachment circuit is indicated in the Pseudowire Type AVP (currently Cisco AVPusing a Structure of Management Information [SMI] enterprise code of 9Type 7) part of the Session Management AVPs. The values that the Pseudowire Type AVP can take for WAN protocols are enumerated in Table 12-1.

Pseudowire Type

Description

Usage

^[1] DLCI = data-link connection identifier

^[2] FRoL2TPv3 = Frame Relay over L2TPv3

^[3] SDU = service data unit

^[4] VCC = virtual channel connection

^[5] ATMoL2TPv3 = ATM over L2TPv3

^[6] HDLCoL2TPv3 = HDLC over L2TPv3

^[7] PPPoL2TPv3 = PPP over L2TPv3

^[8] VPC = virtual path connection

Note

Although the values for the pseudowire type AVP from Table 12-1 are numerically the same as the ones used in Any Transport over MPLS (AToM) for the pseudowire type forward error correction (FEC) field, they belong to different registries. You can find the registry for "L2TPv3 Pseudowire Types" at the Internet Assigned Numbers Authority (IANA) at http://www.iana.org/assignments/l2tp-parameters.

These pseudowire types are also included in the Pseudowire Capabilities List AVP part of the Control Connection Management AVPs to indicate the Layer 2 payload types that a sender can support.

Data Plane

The transport of WAN protocols over L2TPv3 follows the base specification Internet document for L2TPv3, plus the additional companion documents for each WAN technology. Cisco implemented L2TPv3 directly over IP using IP protocol number 115. Figure 12-1 shows the data plane encapsulation for the transport of WAN protocols over L2TPv3.

In Figure 12-1, you can see the data plane packet that goes directly encapsulated in IP. The L2TP session header consists of a 32-bit session ID and an optional cookie. In addition, an optional 32-bit L2-specific sublayer exists, referred to as Pseudowire Control Encapsulation. Figure 12-1 shows the default Layer 2-Specific Sublayer header. The presence of the Layer 2-Specific Sublayer is indicated in the Layer 2-Specific Sublayer AVP part of the session management AVPs.

A NULL session ID identifies L2TPv3 control messages over IP, as shown in Figure 12-2.

The fields from Figure 12-2 are as follows:

T-Bit A field setting of 1 indicates that it is a control message.

L-Bit A field setting of 1 indicates that the length field is present.

S-Bit A field setting of 1 indicates that sequence numbers are present.

Ver The version is set to 3 for L2TPv3.

Length This is the total length of the message in octets.

Control Connection ID This contains an identifier for the "tunnel" or control connection.

Ns This contains the sequence number for this control message.

Nr This indicates the sequence number that is expected in the next control message to be received.

Using the Layer 2-Specific Sublayer

The Layer 2-Specific Sublayer is equivalent to the control word in AToM that was discussed in Chapter 8, "WAN Protocols over MPLS Case Studies," and carries control and payload-specific fields. During session establishment, the use of an Layer 2-Specific Sublayer is negotiated by means of the Layer 2-Specific Sublayer AVP part of the Session Management AVPs. The Layer 2-Specific Sublayer AVP type is an unsigned 16-bit integer that can take the following values:

0 No Layer 2-Specific Sublayer is present.

1 The default Layer 2-Specific Sublayer is used.

2 The ATM Layer 2-Specific Sublayer is used.

Note

The first two values are defined and assigned in the base "Layer Two Tunneling Protocol (Version 3)" IETF document, whereas the third value is defined in the "ATM Pseudo-Wire Extensions for L2TP" IETF document. ATM AAL5 transport needs an ATM-Specific Sublayer to transport ATM cell header fields that would otherwise be lost; other transported protocols, however, rely on the default Layer 2-Specific Sublayer.

If the usage of the Layer 2-Specific Sublayer header has been negotiated, the L2TP Control Connection Endpoint (LCCE) must include the specified Layer 2-Specific Sublayer in all outgoing data messages. Figure 12-3 details the two currently defined Layer 2-Specific Sublayer formats: default and ATM-Specific.

The fields shown in Figure 12-3 are defined as follows:

All Layer 2-Specific Sublayers:

S-Bit The Sequence bit is set to indicate that the Sequence Number field contains a valid sequence number for this sequenced frame, and it is cleared otherwise. When the field is cleared, you must ignore the contents of the Sequence Number.

Sequence Number The Sequence Number field contains a free-running counter of 2²⁴ sequence numbers. As opposed to AToM, the sequence number begins at 0, which is a valid sequence number.

X-Bits Set the Reserved bits to 0 on transmission and ignore them on reception.

ATM-Specific Sublayer:

T-Bit The Transport bit indicates whether the L2TPv3 packet contains an ATM admin cell (when T is set) or an AAL5 payload (when T is cleared). OAM cells are examples of admin cells.

G-Bit The Explicit Forward Congestion Indication (EFCI) bit indicates congestion. The LCCE sets the G bit if the EFCI bit of the final cell of the incoming AAL5 payload or the (EFCI) in the single ATM cell is set to 1.

C-Bit The cell loss priority (CLP) bit in the ATM cell header indicates cell loss priority. The LCCE sets the C bit if any of the CLP bits of any of the incoming ATM cells of the AAL5 payload or of the single ATM cell is set to 1.

U-Bit The U-bit carries the Command/Response (C/R) bit, which is used with FRF.8.1 "Frame Relay/ATM PVC Service Interworking."

Note

Bits 2 and 3 in both Layer 2-Specific Sublayers indicate fragmentation as negated Beginning and End of fragment bits.

Different transported Layer 2 WAN protocols have different requirements for the Layer 2-Specific Sublayer. Two situations require the use of the Layer 2-Specific Sublayer:

AAL5 The transport and tunneling of ATM AAL5 CPCS-SDU require the usage of an ATM Specific Sublayer that carries the EFCI, CLP, and C/R and identifies AAL5 CPCSSDU versus ATM Cell. Otherwise, those fields would be lost because the cell header is not transported.

Sequencing Sequencing for all Layer 2 protocols transported requires an Layer 2-Specific Sublayer that carries the Sequence Number.

For all other cases, an Layer 2-Specific Sublayer is optional. In contrast to the transport of Frame Relay over MPLS, which requires the control word, FRoL2TPv3 does not require the Layer 2-Specific Sublayer, which is equivalent to the control word. The difference lies in the fact that Frame Relay over MPLS (FRoMPLS) does not transport the Q.922 header, and the only way to transport control bits is by piggybacking them in the control word. In FRoL2TPv3, the Q.922 header is transported; therefore, the Layer 2-Specific Sublayer header is not needed.

MTU Considerations

When you tunnel a Layer 2 protocol data unit (PDU) by means of encapsulation, you need to factor the additional overheads associated with this tunneling scheme into packet sizes and maximum transmission unit (MTU). When encapsulating the Layer 2 PDU to be transported using L2TPv3 across an IP packet-switched network (PSN), you need to take into account a series of overheads that are added. This section details all the associated overheads.

You can categorize these overheads as follows:

Transport Overhead The overhead that is associated with the specific Layer 2 being transported. Table 12-2 lists this overhead for the transport and tunneling of different WAN protocols.

Transport Type

Transport

Header Size

Transport Header Reason [Bytes]

^[1] IETF = Internet Engineering Task Force

^[2] SNAP = Subnetwork Access Protocol

^[3] NLPID = Network Layer Protocol Identifier

^[4] OUI = Organizationally Unique Identifier

^[5] DLL = Data Link Layer

L2TPv3 Overhead The tunneling overhead that is associated with the L2TP data message headers. It can be further subdivided into the following:

L2TP Session Overhead The overhead that is associated to the L2TP Session Header:

Session ID The 4-byte overhead that is always present

Cookie Optional overhead that can be NULL, 4 bytes, or 8 bytes

L2-Specific Overhead An optional overhead that is associated with the Layer 2-Specific Sublayer. It can be either NULL or 4 bytes, depending on whether the field is present.

Delivery (IPv4) Overhead The overhead that is associated with the outer IP header without options identifying protocol type 115 for L2TPv3. It is always 20 bytes.

You can see the transport overhead for all WAN protocols over L2TPv3 in Table 12-2. ATM Cell transport is deliberately left out of Table 12-2. In ATM cell relay over L2TPv3 (CRoL2TPv3), the packets transported are of a fixed length of 52 bytes. You can concatenate them up to a maximum number of packed cells, making MTU calculation different from all other Layer 2 transports.

Note

You can compare transport overheads for L2TPv3 in Table 12-2 with the AToM transport overheads and draw the conclusion that the only different overhead is for transporting Frame Relay DLCI mode. In L2TPv3, the Q.922 header is transported but is not in AToM. A 2-byte Q.922 header without extended addressing is assumed.

From the different overheads presented, you can calculate the total overhead and infer the MTU in the provider edge (PE) and provider (P) routers toward the PSN (Core MTU) from the MTU in the PE attachment circuit interface (Edge MTU). The following equations calculateg the core MTU for different WAN protocols:

Core MTU  Edge MTU + Transport Header + L2TPv3 Header + IPv4 Header
Where
L2TPv3 Header = L2TP Session Header + Layer 2-Specific Sublayer Header
L2TP Session Header = Session ID (4 bytes) + Cookie (0, 4 or 8 bytes)
Layer 2-Specific Sublayer Header = 0 or 4 bytes

In addition to the transport overhead, the maximum overhead that IP and L2TPv3oIP add is 36 bytes (20 bytes from the IP header, 4 bytes of the L2TPv3 Session ID, 8 bytes of Cookie, and 4 bytes of the Layer 2-Specific Sublayer Header). The minimum overhead is 24 bytes, skipping the Cookie and Layer 2-Specific Sublayer fields. This minimum overhead is the default for the transport of WAN protocols over L2TPv3. By default, cookies and sequencing are nonexistent, except for AAL5 SDU transport, in which the ATM-Specific Sublayer is required.

HDLC and PPP over L2TPv3

You can transport HDLC pseudowire that is defined in an L2TPv3 companion Internet document using L2TPv3 by including all HDLC data and control fields (address, control, and protocol fields) and stripping the flag and frame check sequence (FCS) fields. From Chapter 5, you know that Cisco routers use a proprietary version of HDLC referred to as Cisco HDLC. It differs from standard HDLC in that the higher layer protocol identification is performed using the Ethernet type.

Because the behavior of an HDLC pseudowire is to function in a port-mode fashion, removing the flag and FCS during imposition and transporting the complete packet over the pseudowire without inspecting it, Cisco HDLC is also transported over an HDLC pseudowire. In fact, therein is one of the most important facets of the HDLC pseudowire: it can transport transparently in an interface-to-interface mode all protocols that contain HDLC-like framing (meaning 0x7E flag and FCS). This includes but is not limited to PPP, Frame Relay, X.25, Synchronous Data Link Control (SDLC), and so on.

The transport of PPP frames over L2TPv3 pseudowires is quite similar to the transport of HDLC frames. This coincides with the fact that PPP was modeled after HDLC with the addition of protocol fields to transport multiprotocol datagrams over point-to-point links.

Differences and optimizations exist, however, traceable to the fact that PPPoL2TPv3 has some Layer 2 packet inspection. At imposition, the Address (0xFF) and Control (0x03) fields of the PPP frame are removed, leaving the first field transported as the PPP DLL Protocol Number. The IANA assigns these PPP DLL Protocol Numbers. You can check them at http://www.iana.org/assignments/ppp-numbers.

Figure 12-4 shows the encapsulation and packet formats for HDLCoL2TPv3 and PPPoL2TPv3.

Because the Address and Control fields are stripped at imposition and not transported over L2TPv3, FCS Alternatives (specify different FCS formats or no FCS at all by means of the LCP configuration option) and Address and Control Field Compression (ACFC) do not work. In contrast, the protocol field is transported so that Protocol Field Compression (PFC) works.

Frame Relay over L2TPv3

At this point, you already know that you can transport and tunnel Frame Relay in a port-mode fashion using an HDLC pseudowire because Frame Relay frames employ HDLC-like framing. The PE configuration for Frame Relay Port mode does not specify the encapsulation as Frame Relay, but it leaves the default of HDLC. In this case, however, Local Management Interface (LMI) is also tunneled over the pseudowire; therefore, you need to properly configure the customer edge (CE) devices for LMI:

If the CE devices are Frame Relay switches, use Frame Relay Network-to-Network Interface (NNI) LMI in both ends.

If the CE devices are Frame Relay routers, use Frame Relay data terminal equipment (DTE) LMI in one end and Frame Relay DCE LMI in the other end. Alternatively, configure Frame Relay NNI LMI to run between routers to better indicate the DLCI status between CE and CE.

Another method of transporting Frame Relay frames at the DLCI level uses the pseudowire type of 0x0001. This method to provide Frame Relay pseudowires is specified in an L2TPv3 IETF companion document.

When you use Frame Relay pseudowire DLCI mode, the Frame Relay PDU is transported in its entirety. Only the opening and closing HDLC flags of 0x7E and the FCS field are stripped at imposition, and the complete Frame Relay frameincluding the Q.922 headeris transported. When you are using different DLCIs at both ends, the DLCI value is rewritten at the disposition (egress) PE (see Figure 12-5).

From Figure 12-5, you can see both Frame Relay IETF encapsulation and Frame Relay Cisco encapsulation. They differ in the upper-layer protocol identification. You can configure Cisco routers for either type of encapsulation.

Because the complete Q.922 header is transported, you do not need to transport the Command/Response (C/R), forward explicit congestion notification (FECN), backward explicit congestion notification (BECN), and discard eligibility (DE) bits separately, as was the case with FRoMPLS. However, the DLCIs can be different at both ends of the Frame Relay pseudowire, so you must rewrite the Frame Relay DLCI at disposition.

ATM over L2TPv3

The tunneling and transport of ATM over L2TPv3 presents two operational modes:

ATM AAL5-SDU Mode The ingress LCCE performs reassembly and the AAL5 CPCSSDU is transported over the ATM pseudowire. The EFCI, CLP, and C/R bits are transported in the required ATM-Specific Sublayer. The egress LCCE performs segmentation.

ATM Cell Mode No reassembly occurs at the ingress LCCE, and ATM-Layer ATM cells are transported over the ATM pseudowire. The ATM-Specific Sublayer is optional. Two operational submodes are also supported:

Single cell relay

Cell concatenation

Figure 12-6 shows a graphical definition of the AAL5 CPCS-SDU transported over L2TPv3. The payload that is transported in AAL5 CPCS-SDUs over L2TPv3 is the same as the one transported in AAL5 CPCS-SDUs over MPLS. From Figure 12-6, you can see that the ATM cell headers are not transported, which is why it is necessary to add the ATM-Specific Sublayer.

ATM cell mode over L2TPv3 also allows multiple granularities with three different services:

ATM VCC Cell-Relay Service

ATM VPC Cell-Relay Service

ATM Port Cell-Relay Service

These three modes exist for both single-cell relay mode and cell concatenation mode. Figure 12-7 shows the packet format for the transport of two packed ATM cells over L2TPv3.

Note

In ATM cell mode, ATM layer cells are transported. This translates to a 4-byte ATM cell header plus a 48-byte cell payload. The fifth byte in the ATM cell header contains the header error control (HEC) and is appended by the Transmission Convergence (TC) sublayer in the ATM physical layer. The HEC byte is not transported over an L2TPv3 ATM pseudowire.

Because the transport of ATM over L2TPv3 has unique characteristics compared to other protocols that are transported, the control plane needs to signal these attributes that only pertain to ATM attachment circuits. To that effect, the following are two new AVPs defined for transport of ATM over L2TPv3 that are not present for other protocols:

ATM Maximum Concatenated Cells AVP This AVP only applies to ATM cell relay pseudowire types. It consists of a 16-bit value that indicates the maximum number of concatenated or packed ATM cells that the sending LCCE can process at disposition. Using cell concatenation increases the bandwidth efficiency given that multiple cells share the same L2TPv3 tunneling overhead; the expense is additional latency incurred while waiting for cells to be concatenated in a single L2TPv3 packet.

OAM Emulation Required AVP This AVP can be used in AAL5 CPCS-SDU mode to request OAM emulation. This is helpful when the ATM pseudowire does not support the transport of OAM cells (by setting the T-bit) in an AAL5 ATM pseudowire; therefore, you can terminate OAM cells in the LCCE. For it to work, you must use OAM emulation in both ends simultaneously. This AVP has a NULL value. The mere presence of this AVP indicates that OAM emulation is required.