Layer 2 VPNs were originally implemented using Layer 2 technologies like Frame Relay and ATM. However, there has been a considerable shift in technology; service provider (SP) networks are transitioning from circuit-switched networks to packet-switched networks. This shift is primarily due to increased revenue generation opportunities and improved management of current network resources. Overall, Layer 2 VPNs help reduce the cost for the provider because the cost of managing separate networks (TDM, FR, ATM, IP) is much higher from both a CAPEX and OPEX perspective than managing one larger aggregate network.
SPs can support both Layer 2 VPNs and Layer 3 MPLS VPNs over a single infrastructure because MPLS-enabled networks allow seamless integration of Layer 2 and Layer 3 services. Layer 2 VPNS provide several benefits, such as
A Layer 2 VPN is defined as a VPN comprising switched connections between subscriber endpoints over a shared network. Figure 11-1 shows an MPLS-based provider that offers Layer 2 VPN services.
Figure 11-1. Layer 2 VPNs
VPWS and VPLS
Virtual Private LAN Service (VPLS) and Virtual Private Wire Service (VPWS) are packet-switched VPN solutions that unify Layer 2 and Layer 3 services.
VPLS is designed for applications that require multipoint or broadcast access. It uses Layer 2 architecture to offer multipoint Ethernet VPNs that connect several sites over a metropolitan-area network (MAN) or wide-area network (WAN).
In VPWS, the two pseudo-wire technologies that enable point-to-point Layer 2 services are as follows:
Both AToM and L2TPv3 support the transport of Frame Relay, ATM, High-Level Data Link Control (HDLC), PPP, and Ethernet traffic over an MPLS or IP core.
Figure 11-2 (page 451) shows the various pseudo-wire technologies used in Layer 2 VPN networks.
Figure 11-2. Layer 2 VPN Model
Pseudo Wire Reference Model
AToM uses the Pseudo Wire Reference Model, shown in Figure 11-3, to transport Layer 2 traffic across an MPLS backbone. The Pseduo Wire Reference Model is based on the workings of the IETF PWE3 (Pseudo-Wire Emulation Edge to Edge) group that provides the framework for edge to edge wire emulation over a packet-based provider network.
Figure 11-3. Pseudo Wire Reference Model
A pseudo wire is a logical connection between two provider edge (PE) devices that connects two pseudo-wire end-services (PWES) of the same type. PWES can be either one of the following used between the PE and CE device:
The PE routers are configured as the endpoints of a pseudo-wire connection. After the formation of the pseudo wire, Layer 1 or Layer 2 PDUs are encapsulated at the ingress PW (pseudo wire) device. The encapsulated PDU is then sent over the PW to the egress PW device where the L2 or L3 headers are reconstructed and the frames are sent in its original format to the other CE device.
AToM Terminology
The following terminology is often used in AToM-based VPN networks:
Figure 11-4 shows the AToM terminology used.
Figure 11-4. Pseudo Wire Reference Model
An attachment circuit (AC) is a physical or virtual circuit (VC) that attaches a CE to a PE. An AC can be, among other things, a VC (for example, Frame Relay or ATM), an Ethernet port, a VLAN, an HDLC link, or a PPP connection.
A packet switched network (PSN) uses IP or MPLS as the mechanism for packet forwarding. The endpoints of a pseudo wire are two PE routers connected to ACs of the same type. PWE3 is a mechanism that emulates the essential attributes of a service (such as Frame Relay or ATM PVC) over a PSN.
An emulated VC is used to provide a Layer 2 connection between the two CE devices. The emulated circuits use three layers of encapsulation:
Protocol data units (PDUs) received from customer sites are encapsulated at the ingress PE router. In AToM architecture, encapsulation implies attaching a certain label stack and special control word. The encapsulated customer PDU is then label switched across the service provider backbone toward the remote PE. The pseudo-wire PDU contains all data and control information stored, if needed, in the control word that is necessary to provide Layer 2 service. Some information might be stored as a state at the pseudo-wire setup – for example, the mapping between label and outgoing interface.
How AToM Works
In an MPLS-based network providing AToM services, Layer 2 frames are received on the ingress interface of the ingress PE router. This Layer 2 frame is encapsulated into an MPLS packet using a label stack by the ingress PE router. The ingress PE encapsulates the frame into the MPLS label stack and tunnels it across the backbone to the egress PE. Figure 11-5 shows the operation of AToM in SP networks.
Figure 11-5. Tunnel LSP and Directed LDP
The egress PE decapsulates the packet and reproduces the Layer 2 frame on the appropriate egress interface. As mentioned earlier, the AToM frames are carried across the MPLS backbone using a label stack of two labels. In the AToM framework, the outer label is called the tunnel label. This outer label propagates the packet from the ingress PE to the correct egress PE router. This outer tunnel label is used for the PE-to-PE LSP.
The second label (inner label), known as the VC label, is used by the egress PE router to forward the packet out on the appropriate egress interface. This procedure is somewhat similar to MPLS VPN, where the egress PE router uses a VPN label. An IGP protocol similar to MPLS VPN implementation is required in the provider backbone between the PE routers so that they can exchange the VC labels. However, in L2 VPN, unlike MPLS VPN, extended communities in BGP are not used to carry VC labels.
In case of AToM, VC label exchange is achieved by establishing a directed multihop LDP session between the PE routers. The egress PE router sends an LDP Label Mapping Message that indicates the label value to use for a VC Forwarding Equivalence Class (VC-FEC). VC FEC is a new LDP element type defined for this purpose. The VC information exchange uses downstream unsolicited label distribution procedures. This label value is then used by the ingress PE router as the second label in the label stack imposed to the frames of the indicated VC-FEC.
LDP Label Mapping Procedure
An emulated VC is an LSP tunnel between the ingress and egress PE. The emulated VC consists of two unidirectional LSPs used to transport Layer 2 PDUs in each direction. A two-level label stack consisting of the tunnel label (top label) and the bottom label (VC label) is used to switch packets back and forth between the ingress and egress PE. The VC label is provided to the ingress PE by the egress PE of a particular LSP to direct traffic to a particular egress interface on the egress PE. A VC label is assigned by the egress PE during the VC setup and represents the binding between the egress interface and a given VC ID. A VC is identified by a unique and configurable VC ID that is recognized by both the ingress and egress PE. During a VC setup, the ingress and egress PE exchange VC label bindings for the specified VC ID. Figure 11-6 shows the LDP label mapping procedure that takes place in an MPLS-based AToM network.
Figure 11-6. LDP Label Mapping Procedure
The following procedure of setting the VC between the PE routers is independent of the transport:
Step 1. |
An MPLS L2 transport route is entered on the ingress interface on PE1 (xconnect remote-PE-ip-address VCID encapsulation mpls). |
Step 2. |
PE1 starts a remote LDP session with PE2 if it does not already exist. |
Step 3. |
The physical layer of the ingress interface on PE1 comes up. PE1 recognizes a VC configured for the ingress interface over which Layer 2 PDUs received from CE1 are forwarded, and, hence, allocates a local VC label and binds it to the VC ID configured under the ingress interface. |
Step 4. |
PE1 encodes this binding with the VC-label TLV and VC FEC TLV and sends it to PE2 in a label-mapping message. |
Step 5. |
PE1 receives a label-mapping message from PE2 with a VC FEC TLV and VC-label TLV. In the VC FEC TLV, the VC ID has a match with a locally configured VC ID. The VC label encoded in the VC-label TLV is the outgoing VC label that PE1 is going to use when forwarding Layer 2 PDUs to PE2 for that particular VC. |
Step 6. |
PE1 might receive a label-request message from some other PE with a specific VC FEC TLV at any time during the OPERATIONAL state. PE1 examines the VC ID encoded in the FEC element and responds to the peer with a label mapping with the local VC label corresponding to the VC ID. |
Step 7. |
After Steps 1 through 6, the LSP between PE1 to PE2 is up and unidirectional. PE2 now performs Steps 1 through 6 as it did with PE1. After both exchange the VC labels for a particular VC ID, the VC ID is considered established. |
Step 8. |
When the VC is taken down for some reason, for example, the CE-PE link goes down or the VC configuration is removed from one PE router, the PE router must send a label-withdraw message to its remote LDP peer to withdraw the VC label it previously advertised. |
PSN Tunnel and VC Label Distribution
This section covers the control and data plane forwarding operation that takes place in a provider network delivering AToM services.
Control Plane Operation
Figure 11-7 shows an MPLS backbone network that provides AToM services to the Customer A sites, CE1-A and CE2-A.
Figure 11-7. Control Plane – PSN Tunnel and VC Label Distribution
To establish the LSP between the PE routers, PE1 and PE2, for control plane traffic from PE1 to PE2, the IGP or LDP label propagation process begins when PE1 advertises the pop label (implicit-null) for its own loopback address (10.10.10.101). The backbone router P1-AS1 advertises a label value of L1 to the PE2 router. This is shown in Steps 1a and 1b in Figure 11-7. An LSP from PE1 to PE2 is now established.
A directed LDP session will also be created between the PE1 and PE2 routers to exchange the VC label. To provide AToM services, any PE pair requires a similar directed LDP session. The PE1 router allocates a local label of VC1 to be the VC label for the specific circuit. The VC label, VC1, is advertised to the PE2 router using the directed LDP session between PE1 and PE2. The PE2 router now forms a label stack. The top-most label, the tunnel label, has the value L1 and forwards the packets to the PE1.
Data Plane Operation
Figure 11-8 shows the data plane forwarding operation for traffic originating from CE2-A to CE1-A.
Figure 11-8. Data Plane Operation
Layer 2 data from CE2-A is received by PE2. PE2 does label imposition on the data packet with tunnel label L1 and VC label VC1. PE2 uses the outer or tunnel label L1 to forward the data packets to PE1. At P1, the tunnel label L1 is popped, and the resulting packet is forwarded to PE1. PE1 uses the inner label, or VC label, VC1 to forward the packets on the correct outgoing interface on PE1.
VC Label Withdrawal Procedure
If a PE router detects a condition that affects normal service, it must withdraw the corresponding VC label using the LDP protocol. Figure 11-9 (page 458) shows an MPLS-based AToM network in which a link failure between PE2 and CE2-A results in the VC label withdrawal message being sent by PE2 to PE1.
Figure 11-9. VC Label Withdrawal Procedure
Control Word
The ingress PE router will use a label stack to encapsulate the Layer 2 frames into MPLS by removing any preamble, frame checksums, and also some header information. Essential header information is carried across the MPLS backbone in a control word, or shim-header. The control word is also used for sequence numbering to guarantee sequenced delivery, if required.
Sequence number zero indicates that no sequencing is done. Small packets may need to be padded if the minimum maximum transmission unit (MTU) of the medium is larger than actual packet size. Control bits carried in the header of the Layer 2 frame may need to be transported in flag fields.
The control word is optional. Some Layer 2 protocols make use of it, while others do not. Both endpoints (ingress PE and egress PE) must, of course, agree to use or not to use the control word. When the control word is used, it is transmitted after the label stack but before the Layer 2 PDU.
The control word is 32 bits. It is divided into 4 fields. The first field is 4 reserved bits that must always be set to 0. The next field is a 4-bit flag field. The flags have different uses depending on the Layer 2 protocol being forwarded. The next 2 bits are always set to 0 when transmitting. The third field is a 6-bit field that is only used if the Layer 2 PDU is shorter than the minimum MPLS packet and padding is required. If no padding is required, the length field is not used. The fourth field is a 16-bit sequence number. Sequence numbering is only used on Layer 2 protocols, which guarantees ordered delivery. The special value 0 in the sequence field indicates that there is no guaranteed sequenced delivery.
When AToM is used for Frame Relay over MPLS, the Frame Relay header is removed and the FECN, BECN, DE, and C/R (CRC) bits are carried in the control word flag field. When AToM is used for ATM over MPLS, the first flag in the control word flag field indicates whether AAL5 frames or raw ATM cells are being transported by AToM. The other three flags are used for Explicit Forward Congestion Indicator (EFCI), Cell Loss Priority (CLP), and C/R.
If one of these flags is set in any of the ATM cells being transported in the MPLS packet, then the corresponding flag is set in the control word.
MPLS Overview
Basic MPLS Configuration
Basic MPLS VPN Overview and Configuration
PE-CE Routing Protocol-Static and RIP
PE-CE Routing Protocol-OSPF and EIGRP
Implementing BGP in MPLS VPNs
Inter-Provider VPNs
Carrier Supporting Carriers
MPLS Traffic Engineering
Implementing VPNs with Layer 2 Tunneling Protocol Version 3
Any Transport over MPLS (AToM)
Virtual Private LAN Service (VPLS)
Implementing Quality of Service in MPLS Networks
MPLS Features and Case Studies