Setting Up WAN over MPLS Pseudowires

In the most general sense, the transport and tunneling of Layer 2 WAN protocols is no different from the transport of Ethernet over MPLS. As discussed in detail in previous chapters, draft-martinibased technologies allow the transport of Layer 2 packets over an MPLS network over point-to-point pseudowires. Although the underlying architecture does not change, several Layer 2-specific customizations from the architectural model allow the transport of specific Layer 2 WAN protocols. This section covers some of these similarities and differences.

Control Plane

The setup and maintenance of AToM pseudowires is based on the targeted (also referred to as directed) Label Distribution Protocol (LDP) session between a pair of provider edge (PE) routers. You can bind the Layer 2 attachment circuit (AC) to the label by using the LDP Label Mapping message. Several pseudowires that are signaled by the targeted LDP session between PEs use one packet-switched network (PSN) tunnel label-switched path (LSP) signaled by Link LDP (IGP) or another label distribution protocol, such as Resource Reservation Protocol Traffic Engineering (RSVP-TE).

The fact that multiple pseudowires use the same PSN tunnel and that only PE devices participate in pseudowire signaling adds to the scalability of the AToM solution, given that only PEs know about pseudowire to attachment circuit mappings (PW<->AC), whereas the core P routers remain uninformed of them. The core only knows about Interior Gateway Protocol (IGP) layer LSPs.

One of the special cases of setting up WAN over MPLS pseudowires is the use of specific interface parameters in the Pseudowire ID FEC element, which you learned about in Chapter 6. For example, whereas some interface parameters are applicable to multiple VC types or emulated services (such as maximum transmission unit [MTU] and Interface Description), others are valid only for specific VC types.

The maximum number of concatenated ATM cells interface parameter is applicable only to the different ATM cell transport modes. The Frame Relay DLCI length interface parameter indicates the length of the DLCI field in the Frame Relay header and pertains only to Frame Relay over MPLS.

The following subsections explain more about the transport of WAN protocols over MPLS PSNs:

• Pseudowire types used

• Data plane encapsulation

• Usage of the control word

• MTU size requirements

Pseudowire Types Used

The 15-bit pseudowire type (or VC type) field identifies the type of pseudowire. The different VC types used in the transport of WAN protocols over MPLS are shown in Table 8-1.

Table 8-1. Pseudowire Types Used in WAN Transport

Pseudowire Type	Description	Usage
0x0001	Frame Relay DLCI	Frame Relay over MPLS DLCI Mode
0x0002	ATM AAL5 SDU VCC	ATM over MPLS AAL5 SDU Mode
0x0003	ATM Transparent Cell	ATM over MPLS Cell Relay Port Mode
0x0006	HDLC	HDLC over MPLS
0x0007	PPP	PPP over MPLS
0x0009	ATM n-to-one VCC[1] cell	ATM over MPLS Cell Relay VC Mode
0x000A	ATM n-to-one VPC[2] cell	ATM over MPLS Cell Relay VP Mode

^[1] Virtual channel connection

^[2] Virtual path connection

The case study sections later in this chapter reference these pseudowire types.

Data Plane Encapsulation

The encapsulation of Layer 2 WAN protocol data units (PDU) is specified in the encapsulation martini draft and subsequent Pseudowire Emulation Edge-to-Edge (PWE3) working group derivative drafts spawned from it (see Figure 8-1). Essentially, the Layer 2 PDU is encapsulated in an MPLS stack where the inner or bottom label (the VC label contained in the VC MPLS shim header) identifies the Layer 2 attachment circuit and is advertised in the LDP targeted session. The tunnel header is in turn comprised by 0 or more MPLS headers from the PSN tunnel control plane.

Figure 8-1. Encapsulation of WAN Protocols over MPLS

[View full size image]

Note that the depth of the tunnel header in terms of the number of MPLS shim headers can vary along the LSP. The tunnel header has 0 labels in the case of Penultimate Hop Popping (PHP), whereby the egress PE advertises an implicit null label in the link LDP session. In the most common case, the tunnel header is made of one label distributed by the core LDP session. However, the tunnel header can contain more than one label in cases such as traffic engineering (TE) with Fast Reroute (FRR), MPLS-VPN Carrier Supporting Carrier (CSC), or inter-AS (IAS) environments or when using the reserved Router Alert label of 1.

A 32-bit control word might reside between the VC label and the WAN Layer 2 PDU. The control word negotiation and usage are covered in Chapter 6. The upcoming section discusses the control word usage in the context of WAN protocols over MPLS.

Usage of the Control Word

During pseudowire setup, the usage of a control word is negotiated by setting the C bit in the pseudowire ID FEC element. Figure 8-2 compares the control word format for different WAN protocols over MPLS.

The following describes each component from Figure 8-2:

• All encapsulations

  First Nibble The first four bits are set to 0x0 to prevent aliasing with IP packets over MPLS. For IP over MPLS (IPoMPLS), the first nibble coincides with the IP Header's version field: 0x4 for IPv4 and 0x6 for IPv6.

  B- and E-Bits These two bits are fragmentation indicators that are used in PWE3 fragmentation and reassembly.

  Length The 6-bit Length field permits values from 0 to 64 only. You use this field when the link layer protocol in the PSN requires a minimum frame length. If the total length of an AToM packet's payloadincluding the control wordis less than 64 bytes, you set the Length field to the length of the AToM packet's payload, including the 4-byte control word. Otherwise, you set it to 0.

• Frame Relay over MPLS (FRoMPLS, also referred to as FRoPW in Internet Engineering Task Force [IETF] documents)

  F-bit FR forward explicit congestion notification (FECN) bit.

  B-bit FR backward explicit congestion notification (BECN) bit.

  D-bit FR DE bit, which indicates the discard eligibility.

  C-bit FR frame command/response (C/R) bit.

• AAL5 CPCS-SDU (often referred to as AAL5 SDU over MPLS)

  T-bit Transport type. Indicates ATM admin cell or AAL5 payload.

  E-bit Explicit Forward Congestion Indication (EFCI) bit.

  C-bit Cell loss priority (CLP) bit.

  U-bit Command/Response field.

Although the control word is optional for some encapsulations such as PPP, HDLC, and cell relay (ATM cell mode transport), it is required for Frame Relay and ATM AAL5 over MPLS. This requirement for Frame Relay and ATM AAL5 transport modes is because the control word carries control information. This information is specific for the Layer 2 that is being emulated that is not carried in the AToM payload. For example, you will see in the upcoming section "Frame Relay over MPLS" that the Frame Relay Q.922 header is stripped at the ingress PE at MPLS imposition, so the control word carries the FECN, BECN, and DE bits that were present in the now-stripped header.

MTU Requirements

Every time you encapsulate a PDU with a new protocol header, you need to take into account maximum transmission unit (MTU) considerations. In a Layer 2 VPN, PEs during imposition are encapsulating a customer edge's (CE) Layer 2 PDU to be switched across an MPLS network. You need to calculate a series of associated overheads to properly set up the core MTU. You can subdivide these overheads into three categories:

• Transport overhead This is the overhead that is associated with the specific Layer 2 that is being transported. Table 8-2 lists transport overheads for different WAN protocols.

  Table 8-2. Transport Overhead for Different WAN Protocols over MPLS

  Transport Type	Transport Header Size	Transport Header Reason [Bytes]
  Frame Relay DLCI, Cisco encapsulation	2 bytes	Ethertype [2]
  Frame Relay DLCI, IETF encapsulation	2-8 bytes	SNAP => Control [1] + Pad [1] + NLPID [1] + OUI [3] + Ethertype [2]
  Cisco HDLC	4 bytes	Address [1] + Control [1] + Ethertype [2]
  PPP	2 bytes	PPP DLL Protocol [2]
  AAL5	0-32 bytes	Header

  
  

• MPLS overhead This is the overhead that MPLS headers add (including the VC label). It is equal to 4 bytes times the number of MPLS headers included.

• AToM overhead This is the overhead incurred because of the control word. It is equal to 4 bytes.

ATM Cell transport is deliberately left out of Table 8-2. In ATM cell relay over MPLS (CRoMPLS), the packets that are transported are of a fixed length of 52 bytes. They can be concatenated up to a maximum number of cells, making MTU calculation different than for all other Layer 2 transports. The upcoming section "Encapsulations and Packet Format for Cell Transport" covers this topic.

Frame Relay with IETF encapsulation refers to RFC 2427, "Multiprotocol Interconnect over Frame Relay," which makes RFC 1490 obsolete. For Frame Relay with IETF encapsulation DLCI transport, the overhead is considered variable; many packets have a transport overhead of 2 bytes: the control byte of 0x03 and the Network Layer Protocol Identifier (NLPID). This is the minimum overhead in Frame Relay IETF. However, in some other cases (such as when a protocol does not have an NLPID assigned), the NLPID value of 0x80 indicates that a Subnet-work Attachment Point (SNAP) header follows. The Organizationally Unique Identifier (OUI) of 0x000000 indicates that a 2-byte Ethertype follows. In this case, in which the upper layer protocol has no NLPID, the transport overhead is 8 bytes, and you need to use the worst case when setting the core MTU.

On the other hand, for Frame Relay Cisco encapsulation, a 2-byte Ethertype is always used instead of control and NLPID, making the transport overhead permanently 2 bytes.

You can use the following generic formula to calculate the core MTU from the edge MTU. The edge MTU is the MTU configured in the interface of the CE-facing PE:

   Core MTU Edge MTU + Transport Header + AToM Header + (MPLS Label Stack *
   MPLS Header Size)