By Sujay G.
Let’s cover the MPLS technology aspects which are leveraged to provide VPN service.
MPLS transport allows SPs the benefits label switching gets, with a way to multiplex multiple services on a single MPLS IP transport path. This path in turn using MPLS signaling protocols like RSVP-TE can be carefully strict routed to choose a more reliable or beneficial path, at the same time gives the benefit of having a dynamic path computation done based on set metrics and bandwidth requirements. It is also possible to set these paths from a MPLS controller using technologies like PCEP or Segment Routing.
Irrespective of the MPLS signaling protocol used, and whether the path setup is using a distributed control layer or a centralized SDN controller, the core transport MPLS IP label switching is used by SPs.
The way MPLS multiplexes multiple services (customers) across a single transport pipe is by using label stacking.
As seen above every MPLS labels is 20 bits in size giving it a range from 0 to 2^20; which is a large range to choose from, leaving apart from the 0-15 space which is reserved.
Using label stacking mechanism, with the bottom label being used for actual transport, like push, swap and pop, the outer label can be transparently carried across from the ingress LER to the egress LER. This outer label in turn can be in turn identified to multiple services on the LER. As an example if there are 2 customers connecting on an Ingress LER over VLAN 10 and 20, an outer label of 101 may signify the VLAN 10 customer and 102 the VLAN 20 customer. This is the way of providing Layer2 services multiplexed over a single MPLS transport tunnel.
Transporting Layer2 services across a transport channel also entails the transport channel meets the requirements of Layer2 technology. Like few of the goals of the PSN is to make sure frequency and timing is correctly serviced when being transferred across the PSN. Besides this as the PW will use a shared IP PSN transport security, congestion control will have to be ensured. Mechanisms to initiate, control and monitor the PW have to be provided, few of these are achieved by using timing protocols, sequence numbers and fragment identifiers in the Pseudowire encapsulation packets.
We’ll focus primarily on a type of PW called as P2MP or Point to Multipoint, loosely also called as VPLS or VLAN Private LAN Service. It will further focus on a VPLS service using MPLS/IP services, with Ethernet at access points. This VPLS service goal will be to provide an ‘emulated’ LAN service across the service provider and customer end points. This goal will thus reduce our technological ask from IP/MPLS technologies to a select few.
An ‘Emulated’ Ethernet LAN requires the existing and standard LAN technology and mechanisms to be provided in the ‘emulated’ world as well. Some of the key services are; VLAN, QinQ, MACinMAC, 802.1p, STP, RSTP, MSTP, RPVST+, IGMP, MLD, flood and learn.
Specific to MPLS/IP case again and for Ethernet services, the MPLS control protocols like LDP already play the role of PW control protocol as well. Example it can be used to exchange the Pseudowire Up/Down notification messages when using LDP.
An interesting problem which arises when carrying both IP and PW encap packet in MPLS is in case an intermediate LSR does ECMP and thus load shares the traffic across different outgoing paths. While it is fine for IP traffic, for PW traffic if it is carrying traffic which should not be re-ordered, ECMP load sharing just does that. To avoid this the pseudo wire header, first 4 bits are marked as all zeros or only 1, the LSR examining the packet thus avoids these packets for ECMP load sharing.
Further the Pseudowire when linking Ethernet end-points, runs in 2 modes. One is called as a raw mode and the other tagged mode. In the tagged mode, the ingress PE examines the tag to determine what PW it should be mapped to, if required. Whereas in the raw mode the tag is not much of use and ignored. Naturally a scheme where the vlan tag is used as a way to distinguish a customer or customer’s service type the back end PW type should be a tagged mode, therefore for not matching conditions the packet s is dealt in a default manner. These two modes were again invented to cater to two classes of users, one who wished to use the pseudowire wholly to themselves like mobile backhaul connections and second for service providers to connect multiple customers(based on VLAN’s) and provide them services.
The standard IEEE 802.3 does expect frame loss or re-ordering, the MPLS PW thus does not specifically enable any sequencing and ordering scheme for it. As mentioned earlier the PW control header, yet has the mechanism for it like with fields like a 16 bit sequence number and fragmentation support, fields which are not used.
To signal and maintain Pseudowires there are two main choice of the protocol being used, they are either LDP or BGP. RFC 4447, explains how LDP can be used to setup and maintain the pseudowire.
As discussed above, Pseudowire is emulated by sending the Layer2 PDUs or bit steam with a de-multiplexor header, containing the Pseudowire distinguisher in the form of a label, a control word which optionally contains information to correctly sequence the packets. The egress PE using the de-multiplexer field delivers the PDU after forwarding processing to the right attachment circuit or service. LDP’s role in this process is to send the label bindings being used for a particular pseudowire, receive the response from the peer, and accordingly enable the pseudowire for use or not. The factors it negotiates are use of control word, MTU on attachment circuit. Apart from this it also maintains the psuedowire status and informs the peer’s about link down situations or attachment circuit state down event using either PW-status TLV or label withdraw messages.
For LDP to maintain the signaling a separate targeted LDP session is maintained between the peers. It is also possible however to use some sort of an auto-discovery protocol to learn about the LDP peers and start the targeted LDP session for it. A choice of protocol for this is BGP which is widely supported and extensible. Therefore; a combination of LDP for signaling and state control with initial auto-discovery and session creation triggered by BGP is an often used combination.
An often use case is that of identifying the customers by their C-tag or S-tag VLAN in the packet and then multiplexing it to the right pseudowire channel. As the VLAN’s are again used on the access side to identify a customer, it may lose relevance when delivering the packet out of the pseudowire on the egress PE, hence a flexible option to remove, swap and add a VLAN over the customer’s received packet is must to deliver the right service.
An alternate to LDP is to use BGP as the pseudowire creation, maintenance and controlling protocol. RFC 4761, where the label mapping for each pseudowire is formed and send to the remote peer using BGP. Unlike LDP in BGP the protocol allows auto-learning of label blocks associated with the pseudowire. Similar to LDP, a status vector information TLV as in RFC 6624 is send to signal the pseudowire status.
It is useful to compare the advantages and disadvantages of using BGP or LDP as the signaling protocol.
A useful combination therefore is to use BGP for auto-discovery of peers and then use automated targeted LDP sessions for L2VPN session creation and maintenance.
Below is a typical deployment topology, with customers connected to two routers for redundancy with active-active load sharing using VLANs. CPE devices can be single homed and thus have redundancy on the CE side only.
Basic steps in configuring a VPWS service*;
Step 1: Configure the attachment circuit and bind the Ethernet services with it.
On the interface connecting to the CE (Ethernet or port channel) configure;
Step 2: Configure the VPLS control plane protocol, in the example below LDP has been configured, optionally BGP can be chosen.
Note; above the command vpls-type vlan implies configuration of a VPLS session other option is;
Where; Ethernet option would imply setting up of a VPWS session.
In case the signaling chosen is type LDP, there is an additional step to configure the targeted vpls peer;
If the signaling chosen is type BGP the address-family l2vpn vpls configurations are required, as the BGP auto-discovers its peer.
Step 3: The last step is to set up the transport network side; this is essentially setting up the PSN tunnel using either standard LDP or RSVP signaling protocol.
When using LDP;
When using RSVP;
The above case shows setting up RSVP strict paths, with FRR 1:1 node-protection.
* Find detailed steps for MPLS-DCI configuration in OcNOS Validated Solution Guide MPLS-DCI.