Note: Part of networking concepts we found essential for this page are shortly presented in the Overview. For information about any networking topic you may check the RAD tutorials homepage. Recommended tutorials for a solid background to this page - Ethernet, Bridges, Packet Switching, Frame Relay, ATM, MPLS, all IP-related, BGP, VPN.
Q. What is a Virtual Private LAN Service (VPLS)?
A. VPLS is a Layer-2 Virtual Private Network (VPN) architecture.
Q. What is a Virtual Private Network (VPN)?
A. A VPN is a network. It interconnects two or more of its sub-networks. But, the interconnection is done over some shared public network (i.e. the internet), so it is "Virtual". It is "Private" since it prevents access and data transport over it from anyone that is not part of the network.
Figure 1 shows a basic model of a VPN:
Figure 1. A Basic VPN Model
VPNs can be categorized by layers: there are Layer-2 VPNs and Layer-3 VPNs. A thorough discussion about the differences between and similarities of these types is left out of this page, but we will say a few words: both types interconnect networks by creating logical tunnels in the public network (tunneling is explained further). Layer-3 VPNs focus on interconnection of sites over the internet, so security is a big issue there. Layer-2 VPNs are simpler in the way that they are almost independent of the network layer.
Q. What is a Layer-2 VPN architecture?
A. A layer-2 VPN architecture defines a network model that allows Layer-2 traffic between VPN sites, as if they were bridged. This extends the benefits of bridged LANs from small geographic area to the reach of the ISP's backbone. Layer-2 VPNs are classified as either Point-to-Point or Multipoint.
Point-to-Point Layer-2 VPNs provide interconnection of two VPN sites. The interconnection can be achived by either a private Point-to-Point line (PPP), a leased line from the ISP (i.e. FR/ATM backbone) or a layer-2 tunnel over the ISP's network (IP, MPLS). We will focus on the third option, since it is also relevant to VPLS.
Figure 2 shows a basic model of a Point-to-Point Layer-2 VPN:
Figure 2. A Basic Point-to-Point Layer-2 VPN Model
The customer site is also called Customer Edge (CE). It can refer to a router, a bridge or a hub. The Provider Edge (PE) is a router between the CE and the ISP network. The idea of putting the PE unit in between is that we would like the core network to be transparent to both CEs, while using the ISP core network as is (meaning it is not aware to any tunnels in it). We cannot use the ISP core network for Layer-2 traffic because the (original) Layer-2 header is stripped off as a frame enters there.
In order to preserve the original Layer-2 header, we define the following model:
This model creates an emulated LAN in which the CEs interconnect as if they were bridged. The tunnel between the PEs is called a "Layer-2 Tunnel" in figure 2, since it allows layer-2 traffic between its edges.
Multipoint Layer-2 VPNs provide interconnection of multiple VPN sites, enabling broadcast and multicast messages across far sites (the latter is not yet supported by VPLS, which is described in the next chapter), as well as supporting VLANs.
Generally, we have n VPN sites which we would like to interconnect. You could say, let us make a tunnel between each pair of PEs, and map remote MAC addresses to tunnels. Indeed, the idea is good - it works, although it has limitations, as we will see.
Figure 3 shows a basic model for a multipoint Layer-2 VPN:
Figure 3. A Basic Multipoint Layer-2 VPN Model
So, how are the tunnels created?
One protocol that defines the signaling of PEs is Label Distribution Protocol (LDP), which is used over MPLS (label switching). A tunnel between a pair of PEs is called a Label Switched Path (LSP). The following scenario defines a creation of an LSP between PE1 and PE2:
A single LSP can contain several VCs. When we look at a single VPLS, each PE needs a connection to all other PEs. So, it holds n-1 VC labels, one for each remote PE. If, for example, PE1 and PE2 both participate in VPLS A and VPLS B, the LSP between them contains two VCs, one for each VPLS. This way a configuration change in VPLS A (i.e. removing PE1 from the VPLS) would not affect VPLS B.There are some problems with the presented VPLS model. One problem is that in order to connect n sites we need n(n-1)/2 connections (a full mesh of PE tunnels). This reduces the scalability of the VPN (the same problem appears in IP over ATM). We will further present a possible solution for this problem (hierarchial structure). Another problem is that, a change in the configuration may affect all PEs (i.e. one PE has changed its address). The protocols that define auto-discovery of the VPN try to eliminate this problem, but their implementation is more complex, and they we will not be discussed.
We now move on to a description of VPLS.
VPLS is a Multipoint Layer-2 VPN based on IP/MPLS. There are two service types of VPLS:
The difference between these services is the ability of a PE to distinguish between separate broadcast domains on its customer side.
In a TLS VPLS, all CEs that are connected to a PE belong to the same broadcast domain. EVCS VPLS, on the other hand, supports several broadcast domains on the customer side. The first thing we need to do is to give a VLAN ID to each VLAN in the VPLS. The VLAN IDs are global to the VPLS. A PE is configured to support port-based VLANs - if two CEs are attached to a PE, it allows us to give a VLAN ID to each CE (or: the port that the CE connects to), such that whenever the PE forwards a frame of some VLAN through a tunnel over the core network, the VLAN ID is encapsulated in the packet. The destination PE reads the VLAN ID so that if the frame is broadcast, it is forwarded only to CEs on ports that were configured for the same VLAN. The PE implements a "virtual switch", since the switching is not only on local ports, but on remote ones as well.
In fact, PEs can participate in more than one VPLS, so distinct VPLS IDs need to be set to the VPLSs. MAC addresses learning - which is mapping of MAC addresses to either a local port for a CE or a "tunnel ID" for another PE - is done on a per-VPLS basis. By "tunnel ID" we mean an MPLS label or an IP address, it depends on the core network.
Figure 4 shows TLS VPLS versus EVCS VPLS:
Figure 4. TLS VPLS vs. EVCS VPLS
Assuming our VPLS is MPLS-based, we can use Label distribution protocol (LDP) to create LSPs (mentioned in the previous chapter). Once the tunnels are created in TLS VPLS, the PEs can start delivering frames over the core network while learning MAC addresses of local and remote stations. For EVCS VPLS (which means that we want to support VLANs on the customer side of a PE), we must encapsulate a VLAN ID in each packet that is sent over the core network.
The emulation of the VLAN ID is shown in Figure 5:
Figure 5. MPLS-based VPLS Label Stack
As we mentioned before, a VPLS with a full-mesh of tunnels is lacking in scalability. One solution for this is to use a hierarchial structure.
Figure 6 shows an example of Hierarchial VPLS:
Figure 6. Hierarchial VPLS Example
The model shows an example for nine CEs, that in flat VPLS defined 36 LSPs to create a full-mesh. Partitioning the VPLS to three logical sections (we saw that distance is no problem in VPLS, as long as the backbone reaches all sites), we get 9 LSPs for the edge-VPLSs, 3 LSPs for the main VPLS and another 3 connections between the main VPLS and the edge ones, for a total sum of 15 paths.
Another problem that this model solves is the amount of MAC addresses learned by PEs. As the number of sites grows, a single PE learns more MAC addresses (the rate of growth depends on added sites' size). Since MACs, unlike IPs, do not have a hierarchial structure (by prefix), learning tables do not scale well. The hierarchial model solves this by hiding edge-VPLS addresses with the address of the edge-VPLS PE that is attached to the main VPLS. This does not affect correctness, since once a packet arrives to an edge-VPLS, MAC addresses in it are learned in local (VPLS) resolution.
This project was made as a final project for the course "Protocols and Computer Networks" taught by Dr. Debby Koren in Tel Aviv University, 2006.
Written by: Itsik Hen and Naama Yehieli