Introducing WAN Protocols over MPLS

The following sections detail the different WAN protocols over MPLS. This section presents fundamental concepts about the transport of HDLC frames over MPLS (HDLCoMPLS), Point-to-Point Protocol over MPLS (PPPoMPLS), FRoMPLS, and different flavors of Asynchronous Transfer Mode over MPLS (ATMoMPLS).

HDLC over MPLS

As you learned in Chapter 5, Cisco HDLC is proprietary. It differs from the International Organization for Standardization (ISO) standard HDLC in that Cisco HDLC does not perform windowing and retransmission. In addition, the higher layer protocol identification is not standardized. Cisco HDLC uses the Ethernet Type value to identify the higher layer protocol that it carries. The frame format and bit-stuffing techniques used in HDLC are defined in the American National Standards Institute (ANSI) T1.618 standard.

Figure 8-3 depicts the Cisco HDLCoMPLS frame format highlighting the fields that are stripped and removed at AToM imposition.

You can see that, except for the start and the end of the frame flag equal to 0x7E and the frame checksum carried in the frame check sequence (FCS), the complete HDLC frame including all header fields is transported unmodified. Frame flags and FCS fields are removed at ingress and re-created at egress. All header fields are uninspected, meaning that no one attempts to interpret the header and make assumptions.

At this point, you might be thinking that HDLC is too basic, so HDLCoMPLS is basic, too. Why would you want to use HDLCoMPLS? The answer to that question is specific: The strength of HDLCoMPLS is its simplicity. Because someone checks only the flag and FCS fields, you can transport an HDLC-like protocol by using HDLCoMPLS. As long as the Layer 2 protocol contains a 0x7E flag and a frame checksum as a trailer, you can tunnel it by using HDLCoMPLS in a port-to-port or interface-to-interface mode. In fact, that is why you can transport Cisco HDLC over HDLCoMPLS. As far as HDLCoMPLS is concerned, standard HDLC and Cisco HDLC frames are indistinguishable. Other protocols that share HDLC-like framing and can be transported in a port-mode fashion are Synchronous Data Link Control (SDLC), CCITT No. 7 signaling, IBM Systems Network Architecture (SNA), PPP, Frame Relay, and X.25.

PPP over MPLS

Modeled after the HDLC frame with the addition of the protocol fields, PPP is a standard method for transporting multiprotocol datagrams over point-to-point links.

The transportation of PPP frames over MPLS is quite similar to the transportation of HDLC frames. The two frames share many common characteristics, including the same control word format.

In contrast to HDLCoMPLS, however, PPPoMPLS requires some interpretation of the PPP header. Specifically, in addition to the 0x7E flag and FCS fields being removed at imposition, the Address (0xFF) and Control (0x03) fields are stripped at the imposition router. These fields are not transported in PPPoMPLS packets (that information can be implicitly gleaned because the VC type is PPP) and re-created at the disposition PE before transmitting to the remote CE. Figure 8-4 shows the PPPoMPLS packet format.

As you can see in Figure 8-4, all media-specific framing information is excluded and not transported. The PPP PDU is transported in its entirety, including the Protocol field (whether compressed using Protocol Field Compression [PFC] or not).

Because in PPPoMPLS the Address and Control fields are interpreted and not transported, CEs should not negotiate ACFC. ACFC is not recommended anyway, because the performance penalty in alignment is larger than the bandwidth savings. Using ACFC results in a 2-byte PPP header, and using PFC results in a 3-byte PPP header; in both cases, the PPP PDU does not start after a 32-bit-word. If you want the CEs to perform ACFC anyway, use HDLCoMPLS.

Note

Using either ACFC or PFC (both defined in RFC 1661, "The Point-to-Point Protocol [PPP]") changes the alignment of the network data inside the frame, which in turn decreases switching efficiency in both the ingress and egress CE.

Because the Protocol field is transported unmodified, you can negotiate PFC between PEs. That is not recommended though, because of the same word alignment reasons explained for ACFC.

One important aspect of the transport of PPPoMPLS is the PPP Finite State Machine (FSM) negotiation, specifically between which peers PPP negotiation (that is Link Control Protocol [LCP], authentication, and Network Control Protocols [NCP]) occur. In PPPoMPLS, the PPP negotiation takes place directly between CE devices. In other words, PPP does not actually run or terminate on the PE devices. After you configure an interface for PPP encapsulation in a PE router, PPP leaves the closed state and tries to negotiate LCP and NCP. Then, when a pseudowire is configured for PPPoMPLS, PPP enters a closed state, and LCP and NCP negotiation is nonexistent with the CE.

Frame Relay over MPLS

At this point, you have already learned of a way to transport Frame Relay frames in port mode over an MPLS PSN: using HDLCoMPLS. When you are using HDLCoMPLS, Local Management Interface (LMI) runs directly between CE devices and not between PE and CE. Therefore, if the CE devices are Frame Relay switches, use Frame Relay Network-to-Network Interface (NNI); if the CE devices are routers, use Frame Relay data communication equipment-data terminal equipment (DCE-DTE) LMI.

There exists, however, a much more granular way to transport Frame Relay frames over MPLS, and that is by using Frame Relay DLCI mode. FRoMPLS DLCI mode enables you to transport a specific Frame Relay VC over an MPLS cloud. Perhaps even more importantly, it provides the framework for local management between PE and CE device by means of Frame Relay LMI. LMI enables the exchange of Link Status by way of a keepalive mechanism using Status Enquiry and Status messages, in addition to Frame Relay PVC or DLCI Status using a Full Status message. In contrast to PPPoMPLS, FRoMPLS has some PE-CE management exchange because LMI runs between PE and CE devices.

As detailed in Chapter 5, you can configure two different Frame Relay encapsulations on a Cisco router: IETF and Cisco. Figure 8-5 depicts these two encapsulation methods.

From Figure 8-5, you can see that for both encapsulation methods, and similarly to HDLCoMPLS and PPPoMPLS, the Flag of 0x7E and the FCS are stripped at imposition and are not transmitted over AToM. The 2-byte Q.922 header is also stripped at imposition and is not transported in AToM. In consequence, a mechanism should be in place to inform the remote PE of the value of all the fields in the Q.922 header so that the remote PE can re-create it and send a Frame Relay packet to the remote CE without losing information. The following list details the different methods for conveying the Q.922 FR header information to the remote PE:

In summary, the C/R, FECN, BECN, and DE are sent on the control word flags on a per-packet basis. In contrast, LDP sends the extended addressing characteristics of the FR PVC on pseudowire establishment P. This implies that on a given Frame Relay PVC, all packets need to use normal addressing (Q.922 header of 2 bytes) or extended addressing (that is, Q.922 header of 4 bytes), but not mixed.

Note

FRoMPLS requires the control word.

As shown in Figure 8-5, the difference between IETF and Cisco encapsulation for Frame Relay is the upper layer protocol identification. You can configure a Cisco router to run either of the two encapsulations.

For IETF encapsulation, the format for routed frames allows an NLPID value of 0x80, indicating that a SNAP header follows (see Figure 8-6). Because not all protocols have an NLPID value assigned (NLPID space is limited), you have to use the SNAP form in such cases. Using the SNAP form increases the transport overhead for Frame Relay IETF to a total of 8 bytes.

One of the direct consequences of the dual encapsulation method using NLPID or SNAP is that IP datagrams over Frame Relay can be encapsulated in two different ways:

ATM over MPLS

ATMoMPLS presents three different degrees of transport granularity: granularity at the VC, VP, or Port level. If a user wants to transport an ATM VC over MPLS, he has the option of doing AAL5 over MPLS (AAL5oMPLS) or CRoMPLS VC mode. A user has to use CRoMPLS if the ATM frames transported over the VC are not AAL5 but a different adaptation layer, such as AAL2. In the next section, you learn some of the differences between the two. If a user wants to transport an ATM VP (for example, for virtual trunking applications) or an ATM port (for trunking or cell transport applications), the only mode available is CRoMPLS.

Encapsulations and Packet Format for AAL5 Transport

ATM is the Layer 2 WAN technology that involves more data plane complexity than the others. As detailed in Chapter 5, the ATM protocol stack includes the ATM Adaptation Layer (AAL) and the ATM layer. AAL is in turn divided into two sublayers:

The first AToM mode for transporting ATM is the AAL5 mode, in which the pseudowire transports AAL5 common part convergence sublayer (CPCS) service data units (SDU).

Figure 8-7 shows that the AAL5 CPCS protocol data unit (PDU) is composed of the CPCS-PDU payload or CPCS-SDU, padding to ensure that the CPCS-PDU length is an integer multiple of 48 bytes for the SAR layer, and a CPCS-PDU trailer. The CPCS-PDU trailer in turn contains a 1-byte User-to-User indication (CPCS-UU) field, a 1-byte common part indicator (CPI), a 2-byte Length indicator that specifies the length of the payload in octets, and a 4-byte cyclic redundancy check (CRC). Only the CPCS-SDUthe CPCS-PDU's payload or the CPCS-PDU without its padding and traileris transported in AAL5oMPLS SDU mode.

Figure 8-7 shows the format of the AAL5 CPCS-SDU for routed ISO (such as Connectionless Network Service [CLNS]) and non-ISO (such as IP) protocols. These formats are useful in understanding the different overheads that play for different protocols that are transported in AAL5oMPLS.

The only supported AAL5 transport mode over MPLS is AAL5 SDU mode. In protocol layering or protocol encapsulation, a service access point (SAP) exists between two layers (see Figure 8-8). Each protocol sends (down direction) and receives (up direction) data via the SAP. The PDU at a higher layer N+1 becomes the layer N SDU when traversing the SAP. At layer N, protocol control information (PCI) is added to the SDU to form the PDU at that layer N, which in turn becomes the SDU at layer N-1. In summary, at a given layer, PDU = PCI + SDU. PDU includes the protocol control data (PCI) plus the carried data (SDU). The PDU at layer N is the SDU at layer N-1. Any data that enters the AAL5 layer becomes an SDU for AAL5 CS.

In AAL5 SDU mode, the AToM payload's (AAL5 CPCS-SDU) length need not be an integer multiple of 48 bytes, because the padding and trailer were stripped before AToM encapsulation.

In AAL5oMPLS, the ingress PE receives ATM cells from the customer premises equipment (CPE), and it needs to reassemble them to send an AAL5 SDU over MPLS in a single packet. The cell headers are not transported, so it is critical to understand how the different ATM cell header fields are conveyed to the other end. In AAL5oMPLS, the presence of a control word is required, although its use is optional (refer to Figure 8-2). The following list enumerates the different ATM cell header fields and how they are transported in AAL5 SDU mode:

In AAL5 SDU mode, the ingress PE reassembles the AAL5 CPCS-PDU, strips off the padding and CPCS-PDU trailer, and sends the AAL5 CPCS-SDU in an AToM packet; at the other end, the egress PE regenerates the PAD and AAL5 trailer. Each AAL5oMPLS packet contains an AAL5 SDU or an OAM Cell. AAL5 SDU mode has less overhead compared to AAL5 PDU mode, because the 8-byte trailer and padding are not transported. The padding can be significant for small packets, given that the smallest TCP packet requires at least two cells when transported natively over ATM.

Encapsulations and Packet Format for Cell Transport

In contrast, the different CRoMPLS modes operate at the ATM layer of the ATM reference model. Figure 8-9 depicts the encapsulation of n-to-one CRoMPLS by including two ATM cells in an AToM packet. Cisco implementation of ATM CRoMPLS uses n-to-one cell transport modes.

From Figure 8-9, you can see that for cell relay, the control word is optional. However, Cisco implementation of CRoMPLS advertises the disposition capability for the control word (C-bit in pseudowire ID FEC) and uses the control word whenever possible (that is, when the remote side supports the control word as a disposition capability).

In n-to-one ATM cell transport, a complete ATM layer cell header is appended after the control word, followed by 48 bytes of ATM cell payload.

Note

In the ATM reference model, the cell header is only 4 bytes long at the ATM layer. The Transmission Convergence (TC) sublayer calculates and appends the fifth byte (header error control [HEC]), which is a checksum of the ATM cell header in the ATM physical layer. The TC sublayer handles functions such as cell delineation and error detection and correction by adding a 1-byte CRC. Because cell relay acts in the ATM layer, and for alignment and efficiency reasons, the HEC byte is not included in the transport of ATM cells over MPLS.

An ATM cell is transported with 52 bytes in the AToM payload out of the 53 bytes of the ATM cell, thereby carrying VPI, VCI, PTI, and CLP fields.

Note

In contrast to AAL5oMPLS, in CRoMPLS, encapsulation for a user cell and management or OAM cell is the same.

The VPI field in ATM cell encapsulation is 12 bits long to accommodate the NNI ATM header format's VPI range. The field is interpreted as VPI; therefore, if the cell is actually using UNI ATM header format, the Generic Flow Control field (first nibble) is always 0.

In n-to-1 ATM CRoMPLS, an imposition PE can concatenate multiple ATM cells into a single AToM PDU. Concatenation of cells (also called cell packing) is optional in transmission at the ingress PE and is supported in ATM cell port, VP, and VC modes. You can view the cell concatenation as a disposition property, in which an egress PE can support disposition for concatenated cells up to a certain number of cells. The imposition PE knows the maximum number of cells that can be linked because it is indicated during pseudowire establishment with a new interface parameter. The Maximum Number of concatenated ATM cells interface parameter (interface parameter type 0x02) specifies the maximum number of cells in a single AToM PDU that you can process at disposition.

Note

Because the interface parameter is included in the Label Mapping LDP message at VC setup, changing its value would tear down and resignal the pseudowire.

The Maximum Number of concatenated ATM cells interface parameter is required for all the different ATM cell transport modes (port, VP, and VC modes). If the egress PE supports concatenated cells, the ingress PE should only link cells up to the Maximum Number of concatenated ATM cells interface parameter received from the remote PE in the pseudowire ID FEC element.

Note

The Maximum Number of concatenated or "packed" cells is configurable and does not need to be identical between the PE routers. The configuration and details for this feature are included in the section titled "Case Study 8-8: Packed Cell Relay over MPLS," later in this chapter.

Naturally, the cell concatenation encapsulation is more bandwidth efficient than single cell relay (that is, sending one ATM cell per AToM packet), because multiple cells share the AToM overhead. Each ATM cell that is encapsulated in an AToM frame is 52 bytes long, and each AToM packet is at least 64 bytes (52 bytes + two MPLS headers + control word). On the other hand, the compromise is that when you are using cell concatenation, the imposition router introduces more delay when waiting for cells to be packed. Even with a value for packed cells greater than 1, OAM cells are transported in a single AToM packet.

In ATM cell transport, the MTU considerations are different from all other Layer 2 transports. In ATM cell transport, you can predict the maximum AToM PDU size differently than with the other Layer 2 technologies, because the packet size is fixed for ATM cells. You can configure the maximum number of cells to be packed into an MPLS packet up to the MTU of the interface divided by 52 bytes for each ATM cell. Alternatively, you can easily calculate the maximum length of an AToM packet from the following formula and set up the core MTU accordingly: