Virtual Private LAN Service (VPLS) ( Part1)

Hierarchical VPLS

Virtual Private LAN Service (VPLS) has become a very attractive technology over the past few years with the advent of MPLS. The reason being some enterprises are very reluctant to relinquish routing control of their network to the service provider and desire L2VPN services with multipoint connectivity. VPLS allows service providers to deploy carrier-class service over Ethernet/MPLS-based network in a realiable and flexible way. This article will start with some VPLS basics and continue with H-VPLS.

VPLS

As its name implies, the purpose of VPLS is to provide a private multipoint LAN-type Ethernet connectivity service i.e. VPLS emulates a LAN segment over MPLS backbone across pseudowires or virtual circuits. VPLS creates one or more LANs for each customer who is using the service from the service provider. Each LAN is completely separate from the other emulated LAN segments. When a customer with different Ethernet sites connects to an MPLS backbone where VPLS is deployed, it appears as if all the sites are interconnected through a virtual Ethernet switch.

VPLS Terminology

• u-PE: User facing Provider Edge bridge that is used to connect Customer Edge (CE) devices to the service
• n-PE: Network Provider Edge that acts as a gateway between MPLS core and edge domain, which may be MPLS or Ethernet
• PE-Agg: Provider Edge - Aggregation Switch is an Ethernet switch that aggregates several u-PE connections for onward connection onto n-PE
• VSI: Virtual Switch Instance - A VSI describes an Ethernet bridge function within an n-PE that equates to a multipoint L2VPN. A unique atttribute of a VSI is that it terminates PW virtual interfaces, which differs from an Ethernet bridge that terminates physical Ethernet interface.
• PW: PsuedoWire - A PW is a virtual connection that connects two VSIs. A PW is bi-directional in nature and consists of a pair of uni-directional MPLS Virtual Circuits (VCs). A PW may also be used to connect a point-to-point circuit.
• AC: Attachment Circuit - An AC is the customer connection to a service provider network. An AC may be a physical port, or a virtual port.

VPLS Architecture

An Ethernet switch has the following characteristics:

• Forwarding of Ethernet frames
• Forwarding of Unicast frames with an unknown destination MAC address
• Replication of broadcast and multicast frames to more than one port
• Loop prevention
• Dynamic learning of MAC addresses
• MAC address aging

VPLS should also have these characteristics. If the PE router receives an Ethernet frame with unknown destination MAC address, the frame is replicated and forwarded to all ports that belong to that LAN segment.

VPLS Overview

For each VPLS, the PE routers are fully meshed with pseudowires. A PE receiving a frame from another PE can identify which VPLS the frame belongs to, on the basis of pseudowire label or VC label. As far as each customer is concerned, an Ethernet frame that is sent into the service provider network is delivered to the correct site(s), on the basis of destination MAC address. It is the task of each PE router to inspect the destination MAC address of each frame arriving from a locally attached site and to forward it to appropriate destination site. This destination site may be attached to the same PE on a different port or a remote PE. If the destination site is attached to the same PE, the PE locally switches the frame to correct port. If the destination site is attached to a remote PE, the ingress PE must forward the frame to appropriate pseudowire to the remote PE. This means that the ingress PE needs to know which egress PE to send the frame to.

There are two ways in which this can be achieved- one is to have a control plane signalling to carry information about MAC addresses between PEs, or to have a scheme based on MAC address learning. VPLS takes the latter approach by having each PE take the responsibility of learning which remote PE is associated with a given MAC address. Thus an ingress PE simply needs to identify which frames need to be sent to egress PEs, and egress PEs takes care of identifying which local ports to forward the packet to. By inspecting the source MAC address, say A, of the frame arriving on a port, whether an actual local port or a pseudowire from a remote PE, and by creating a corresponding entry in the forwarding table, the PE learns where to send frames in the future having destination MAC address, A.

In the case where Ethernet switches are used as CE devices and connected to PE routers, the PEs need to learn the MAC addresses of individual hosts attached to the switches. So, if a host is plugged into the office network served by a switch as a CE, the effect will be felt by all PEs. Thus, for a large deployment, it is better to use routers as CEs than switches.

Forwarding of Unicast Frames

In figure 1, suppose that the MAC address of host C is C and the MAC address of host B is B, for the customer network X. Suppose host C sends a frame with source MAC address C and destination MAC address B. Suppose that PE3 does not know the location of MAC address B. As a learning bridge would do, PE3 floods the packet on all ports except the port on which it arrived. This means the packet is flooded to the pseudowire to PE2 and the pseudowire to PE1.

PE1 and PE2 know that the packet belongs to customer X's VPLS, by virtue of the pseudowire on which the frame arrived. PE1 and PE2 both perform destination MAC address lookup in their VPLS forwarding tables corresponding to customer X. If PE1 does not know the location of MAC address B, it floods the frame on its local ports to CE. However, it does not flood the frame to any other PEs. This split horizon scheme ensures no forwarding loops occur. Similarly, PE2 forwards the frame on to the port facing the switch CE.

Receiving frames with MAC address C enables each PE to learn the location of host C. Thus, PE2 and PE1 creates an entry in their forwarding tables with an association between MAC address C and their respective pseudowires to PE3. In this way, all PEs learn the MAC addresses and creates an association between MAC addresses and pseudowires (for remote destinations) in their forwarding tables for that particular VPLS instance.

Forwarding of Broadcast and Multicast Frames

In figure 1, suppose PE3 receives a broadcast frame sent by host C. The frame must be sent to all sites of customer X's VPLS. PE3 floods the frame onto pseudowires to PE1 and PE2. In turn, PE1 and PE2 floods the frame to the attached CEs, but due to split horizon, do not send the frames to any PEs. Multicast traffic is also treated exactly this way.

VPLS Discovery - How does a PE know which other PEs have members of a particular VPLS attached?

The capability to manually configure the addresses of remote PEs is required. However, the use of manual configuration is not necessary if auto-discovery is used. Auto-discovery allows PE devices to automatically discover other PE devices that have an association with a particular VPLS instance. Once the PEs have discovered other PEs for a VPLS instance, they can then signal connections to interconnect the PEs.

There are a number of mechanisms that can be used to distribute VPLS associations between PE devices, which includes extensions to BGP version 2 (multiprotocol BGP), LDP-based, DNS-based, RADIUS-based, and static.

• Static configuration requires that each PE associated with a VPLS instance is configured as a peer. The scalability of this solution is low as manual configuration is required every time a VPLS is added, changed or deleted. However, as the peers are manually configured, the security and flexibility to signal additional attributes of the solution is fairly robust.
• NMS/OSS configuration uses a central management point that distributes VPLS membership to each PE associated with a particular VPLS. This provides syntax checking based upon the type of device being configured and allows other service specific attributes to be provisioned at the same time.
• DNS configuration uses a DNS to distribute VPLS membership information. This mechanism provides centralized management and also uses a common syntax. This mechanism requires that the requesting PE must belong to the DNS entries for the VPLS instance. However, this can not signal additional attributes and other mechanism is required to provide additional information.
• RADIUS configuration uses RADIUS attributes to distribute VPLS membership information. In this scheme, the PE sends a request to the RADIUS server containing an identifier specific to a VPLS instance. The RADIUS server returns a list of addresses of PEs belonging to that VPLS instance. This mechanism is centralized and requires that the requesting PE must belong to have a RADIUS attribute associating the PE with the requested VPLS. RADIUS attribute-value pairs can be used to signal additional attributes.
• LDP signalling requires that each PE is identified and a targeted LDP session is active for auto-discovery; it has no inherent auto-discovery, so the pseudowires must be manually configured or some external auto-discovery mechanism must be used. The overall scalability is poor as a PE must be associated with all other PEs for LDP discovery to work, which can lead to a large number of targeted LDP sessions. LDP can signal additional attributes but additional configuration is required from NMS/OSS or static.
• BGP signalling requires that a PE associated with a particular VPLS is configured under a BGP process. BGP then advertises VPLS membership information using NLRIs. Hence, BGP has inherent mechanism for auto-discovery and so frees the user from having to configure the pseudowires manually. BGP cannot easily distribute attributes such as bandwidth profiles without introducing additional overhead.

VPLS Signaling - How is a full mesh of pseudowires setup between PEs?

Once the PEs have ascertained that other PEs have an association with the same VPLS instance, each PE needs to setup a PE between each other and bind the PWs to the particular VSI. There are 2 solutions that have been described for signalling of PW between PEs-

• BGP-based VPLS (RFC 4761)
• LDP-based VPLS (RFC 4762)

LDP-based Signaling

LDP is used for the signaling of pseudowires that are used to interconnect the VPLS instance of a given customer on the PEs. In order to signal a full mesh of pseudowires required, a full mesh of targeted LDP (T-LDP) sessions is required between the PEs. In absence of auto-discovery, these sessions must be manually configured on each PE router. This LDP session is used to communicate the "inner label" or "VC label" that must be used for each pseudowire. The network operator assigns a VC ID which is used to identify a particular pseudowire, is configured to be the same for a particular VPLS instance on all PE routers.

Following is the information communicated over the LDP session including the label value itself. The FEC element includes the following fields-

• VC ID
• Control Word bit - This indicates whether a control word will be used.
• VC Type - This indicates the encapsulation type. This would be Ethernet or VLAN-tagged Ethernet.
• Interface parameters field - This contains information such as media MTU, etc.

Cisco IOS uses LDP to signal the setup, maintenance and teardown of a PW between PE devices. Once a PE discovers that other PEs have an association for a particular VPLS instance, the PEs signal using T-LDP to other PEs that a PW is required to be setup between PEs. When a PE device is associated with a particular VSI, LDP transmits a label-mapping message with VC-Type 0x0005 and a 4-byte VC-ID value. If the remote PE has an association with that particular VC ID, it will accept the LDP label-mapping message and respond with its own label-mapping message. Once the two uni-directional VCs are operational, they are combined to form a bi-directional PW.

BGP-based Auto-discovery and Signaling

The BGP NLRI takes care of auto-discovery and signaling at the same time, the NLRI generated by a given PE containing the necessary information required by any other PE. These components enable the automatic setting up of full mesh of pseudowires for each VPLS.

On each PE, a Route Distinguisher (RD) and a Router Target (RT) is configured for each VPLS, like in L3VPN and L2VPN. The RT is same for a particular VPLS across all PEs, and is used to identify which VPLS a particular BGP message pertains to. The RD is used to disambiguate routes. On each PE, for each VPLS an identifier is configured called VPLS Edge Identifier (VE ID). Each PE involved in a particular VPLS must be configured with a different VE ID. BGP is used to advertise the VE ID to other PEs. This, along with other information in NLRI, is used to calculate the value of pseudowire label required to reach the advertising PE.

For a given VPLS, a PE requires that each remote PE uses a different pseudowire label to send traffic to that PE. This is to facilitate the MAC learning process. This way, the receiving PE can learn which PE is associated with the source MAC address of the frame. A PE could send a list of pseudowire labels required to reach it, one per remote VPLS Edge in that VPLS. However, this would mean that a PE send a long list of labels if there are a large number of PEs. Instead, the necessary information is carried in BGP NLRI. This allows all remote PEs to calculate the pseudowire label expected by the advertising PE.

A BGP Update message contains the following items-

• Extended Community Route Target - This allows the receiving PE to ascertain which particular VPN the advertisement pertains to.
• Layer 2 Info - This is automatically generated by sending PE. It contains following information-
• Control Flags to indicate whether a Control Word is included
• Encapsulation type - Ethernet or VLAN tagged
• MTU
• Other BGP attributes like AS Path, Origin, etc
• The NLRI contains the following information-
• Route Distinguisher
• VE ID
• Label Base
• VE Block Offset
• VE Block size

The label base, VE block offset and VE block size are the information the receiving PE requires to calculate the pseudowire label when sending traffic for VPLS to the advertising PE. A PE allocates blocks of labels. Each block is a contiguous set of label values. The PE simply advertises the value of the first label (label base) and the number of labels in the block (block size). The label value that a remote PE having a VE ID value must use to reach the advertising PE is computed as

label value = label base + VE ID - 1

For example, say in figure 1, suppose PE1 advertises a label base of 100 to PE2 and PE3. Suppose the VE IDs of customer X's VPLS instance on PE1 is 1, on PE2 is 2 and on PE3 is 3. When PE2 wants to send traffic to PE1, it calculates the pseudowire label as follows-

label value = 100 + 2 (VE ID of PE2) - 1

                = 101

So, PE2 uses 101 as the VC label to send traffic to PE1. The VE Block offset is used in case there are multiple label blocks are advertised in separate NLRIs.

Both of these implementation options are identical from forwarding plane point-of-view, but they differ in control plane, particularly in the protocol they use to signal and establish the pseudowires. The BGP implementation advertises a PE's association with a particular VPLS as well as the label block from which labels may be assigned to communicate with that PE. This approach has many disadvantages-

1. All label information is broadcast to all PEs associated with a particular VPLS due to full mesh. This is acceptable for initial VPLS auto-discovery, subsequent PW discovery is inefficient.
2. PW signalling of peer-to-peer parameters are broadcast to all PE routers which wastes bandwidth.
3. This mechanism uses BGP for MAC address flush instead of IEEE Spanning Tree TCNs that makes it incompatible with IEEE bridges.
4. BGP scaling mechanisms such as Route Reflectors (RRs) have to take into account increased signalling overhead.

Although a full mesh of PWs is formed between PEs, each individual PW has a set of unique attributes that are specific to a PW and have significance to that PW only. As attributes are point-to-point in nature, targeted LDP (T-LDP) is best suited. Further, since most MPLS implementations are LDP based, the use of LDP does not introduce a new protocol into the network.

To prevent packets looping, split horizon forwarding technique is used. It prevents transmitting a packet back out of the interface it was received upon. If a packet is received on a PW, it cannot be forwarded on any other PW associated with a particular VSI. The VPLS implementation allows customer BPDUs to be transported across the network. These customer BPDUs are tunneled through VPLS network.

VPLS Summary

VPLS enables a multipoint Ethernet service to be delivered over MPLS infrastructure. However, it has several scaling limitations like the requirement for a full mesh targeted LDP sessions for VPLS discovery and signalling. The PE device must form adjacency with all other PE devices. This requires the PE devices to learn the IP addresses of all remote PE devices, and exchange label information with them. Also, the replication of broadcast and multicast frames which occurs at the ingress PE router, causes an inefficient use of network bandwidth. With VPLS, you can transparently tunnel Layer 2 control protocols like CDP, STP, or VTP.

H-VPLS

To address the scaling limitations within flat VPLS architecture, H-VPLS is described. VPLS requires a full mesh of tunnel LSPs between all PE routers that participate in the VPLS service. For each VPLS service, n*(n-1)/2 PWs must be setup between PEs. This creates signalling overhead. Also, packet replication requirement detriments large scale deployment. Hierarchical connectivity reduces signalling and replication overhead.

H-VPLS introduces u-PE and n-PE routers. u-PE routers are user-facing PE routers, while n-PE routers are network-facing PE routers. The hierarchy provides the benefits of less signalling in MPLS core network and less packet replication on n-PE routers. The u-PE routers have an aggregation role and do some packet replication and MAC address learning.

RFC 4762 defines 2 mechanisms for access domain in H-VPLS. They are-

1. H-VPLS with Q-in-Q in Access layer
2. H-VPLS with MPLS in Access layer

The VPLS core PWs (hub) are augmented with access PWs (spoke) to form a two-tier H-VPLS. In figure 2, 3 customer sites are connected to u-PE devices. The u-PE devices have single connection (PW) to n-PE routers. The n-PE routers are connected in a basic VPLS full mesh service. For each VPLS service, a single spoke PW is setup between u-PE and n-PE devices. Unlike traditional PWs that terminate on a physical or logical port, a spoke PW terminates on a VSI on u-PE and n-PE devices. The u-PEs and n-PEs treat each spoke connection like an attachment circuit of the VPLS service. The PW label is used to associate the traffic from the spoke PW to a VPLS instance.

u-PE Operation

The u-PE device supports Layer 2 switching and does all the normal bridging functions of learning and replication on all its ports, including spoke PW. Packets to unknown destination are replicated to all ports in the service including spoke PW. Once the MAC addresses of CE devices connected to the same u-PE device are learned, traffic between them is switched localled, saving the capacity of the spoke PW to n-PEs. Similarly, traffic between remotely connected CE devices to different u-PE devices is switched directly onto spoke PW and sent to n-PEs over the point-to-point PW.

Since the u-PE is bridging capable, only a single PW is required per VPLS instance for any number of access connections in the same VPLS service. This reduces the signalling overhead between u-PEs and n-PEs. If the u-PE is directly connected to n-PEs, Q-in-Q encapsulation can be used for spoke PW.

n-PE Operation

An n-PE device supports all bridging functions for VPLS service and supports the routing and MPLS encapsulation like in basic VPLS. The operation of n-PE is independent of the type of device at the other end of the spoke PW. Thus the n-PE will switch traffic between spoke PW, hub PWs, and ACs once it has learned the MAC addresses.

Dual-Homed u-PE

The failure of n-PE or connection of PW, the u-PE can suffer total loss of connectivity. To prevent this, redundant connections can be provided. The u-PE is dual-homed into two n-PE routers. In figure 2, the u-PE sets up two PWs for each VPLS instance. One of the two PWs is designated as primary and the other as standby. The u-PEs negotiate pseudowire labels for both PWs, but does not use the standby PW unless the primary PW fails. Spanning tree instance or manual configuration can be used to designate primary and standby status.

Upon failure of primary PW, the u-PE immediately switches to the standby PW. At this point, the n-PE that terminates the standby PW, starts learning MAC addresses on the spoke PW. All other n-PEs initially continue to send traffic to initial n-PE until they learn that the devices are now connected to a new n-PE. To enable faster unlearning process, the new n-PE may send out a flush message using the MAC List TLV (Type 0x404) to all n-PEs. Upon receiving the message, the n-PEs flush the MAC addresses associated with that VPLS instance.

H-VPLS Model using Ethernet Access Network

H-VPLS model is expanded to include an Ethernet access network. It still requires n-PEs fully meshed in MPLS core, but there is no restriction on the topology of Ethernet access network, so u-PEs and n-PEs are not hubs and spokes. One approach of tunneling customer's Ethernet traffic via an Ethernet access network is to add an additional VLAN tag customer's data i.e. a S-VLAN tag. The customer's data may be tagged or untagged. Inside the provider's network, each S-VLAN designates a VPLS instance for a customer. Therefore, there is 1-1 correspondence between S-VLAN and VPLS instance. The u-PEs must have the capability of adding S-VLAN tag to customer data.

The n-PEs need to perform bridging functionality over the standard Ethernet ports toward the access network, as well as over the PWs towards the core network. Also, the n-PEs may need to run STP in the access network as well as split horizon in core network. The n-PEs need to map a S-VLAN to a VPLS instance and its associated PWs, and vice versa.

H-VPLS Summary

H-VPLS provides a solution for VPLS for improved pseudowire scalability. This improvement is achieved by reducing the number of PE devices connected in full mesh topology and thus improves control plane scalability. It reduces the burden on core devices presented by frame replication. However, there are better way to address scalability problems than those defined by LDP-based H-VPLS. Also, H-VPLS does not offer a better solution to efficiently address multicast traffic. BGP-based VPLS with point-to-multipoint LSPs is a good option for service providers. 
(source: https://sites.google.com/site/amitsciscozone/home)