لطفا منتظر باشید ...
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.
Figure 8-3. Cisco HDLCoMPLS Packet Format
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.
Figure 8-4. PPPoMPLS Packet Format
[View full size image]
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).
As a result, the following will not work:
FCS alternatives
Address and Control Field Compression (ACFC)
Asynchronous Control Character Map (ACCM)
PFC, however, will work.
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.
Figure 8-5. FRoMPLS Packet Format
Figure 8-2.
FECN The FECN bit is sent in the F-bit in the FRoPW Header (that is, control word).
BECN The BECN bit is sent in the B-bit in the FRoPW Header (that is, control word).
DE The discard eligible bit is sent in the D-bit in the FRoPW Header (that is, control word).
EA During pseudowire establishment, PEs negotiate the characteristic of a Frame Relay PVC with respect to extended addressing. They do this by including the optional Frame Relay DLCI length interface parameter in the VC FEC element in the FEC TLV inside the LDP Label Mapping message. The optional Frame Relay DLCI length interface parameter (interface parameter type 0x08) indicates the length of the FR Header and can have a value of 2 or 4.
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.
Figure 8-6. Format of Routed Frames with SNAP Header
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:
Using an IP assigned NLPID of 0xCC. This is the preferred method specified in RFC 2427 and also the method used in Cisco routers.
Using an NLPID value of 0x80 indicates that a SNAP header follows. A SNAP header includes an OUI of 0x000000 that indicates an Ethertype follows. The Ethertype of 0x0800 is for IP.
ATM over MPLS
You can categorize the transport of ATMoMPLS as follows:
ATM AAL5 over MPLS Transport of RFC 2684/1483 AAL5 SDUs over MPLS.
ATM Cell over MPLS Relay of ATM cells over MPLS. You can subcategorize ATM Cell Relay over MPLS as follows:
Port Mode Transport of ATM cells from an ATM interface.
VP Mode Transport of ATM cells from an ATM virtual path (VP).
VC Mode Transport of ATM cells from an ATM virtual circuit (VC).
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:
Convergence sublayer (CS)
Segmentation and reassembly (SAR) sublayer
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. AAL5oMPLS Packet Format
[View full size image]
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.
Figure 8-8. Understanding PDU Versus SDU
Figure 8-2). The following list enumerates the different ATM cell header fields and how they are transported in AAL5 SDU mode:
Virtual path identifier (VPI) and virtual circuit identifier (VCI) PE routers do not carry or exchange the VPI and VCI. The PEs keep the VPI and VCI values in the state of the pseudowire, and the disposition PE router rewrites the VPI and VCI value.
Payload type identifier (PTI) The PTI contains three fields:
C This field indicates whether the cell contains user data or control (management) data; you can loosely map this field to the transport bit (T-bit) in the AAL5 control word. The T-bit indicates whether an AToM packet contains a cell or an AAL5 SDU. OAM cells on an AAL5 pseudowire are sent as cells and set the T-bit.
EFCI The EFCI is transported in the E-bit in the control word.
End of packet (EOP) You do not need the end of the AAL5 packet bit because the cells are reassembled in the ingress PE.
CLP The CLP-bit is carried in the C-bit in the control word.
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.
Figure 8-9. CRoMPLS Packet Format
From 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:
Max AToM packet = (52 * max number of packed cells) + AToM Header +
(depth ofMPLS label stack * MPLS Header size)
In the formula, the AToM Header refers to the 4-byte control word.
