Ethernet VPWS Encapsulation Methods (RFC 4448) Explained with DATACOM DM4000 Switches - Part 1

VPWS (aka MPLS L2VPN Martini Encapsulation) allows service providers to offer an emulation of point-to-point Ethernet services, which can be provisioned as either Port-based VPWS or VLAN-based VPWS. Essentially, the former enables you to provide an emulation of Ethernet connectivity between two Ethernet interface over the MPLS backbone, whereas the later uses service-delimiting VLANs to distinguish the Ethernet service for each customer circuit, which means it is possible to multiplex several L2 circuits over the same Ethernet interface.

RFC 4448 1, as we’ll see shortly, specifies some requirements in terms of how Ethernet frames and their VLAN tags should be transported across an MPLS backbone, which can lead to several interesting and flexible use cases. In this article, I’ll explain some of these use cases with DATACOM DM4000 Switches 2. Before we dive in, let’s first review the two encapsulation methods specified in this RFC.

RFC 4448 Overview

One of the key definitions is to understand what the concept of service-delimiting VLAN represents. A service-delimiting VLAN is locally meaningful to the PE (Provider Edge) equipment that offers the VPWS service, which means it can be placed on the customer traffic by any service provider equipment in order to distinguish this traffic. On DM4000 Switches, the service-delimiting VLAN is defined by the xconnect vlan command.

The service-delimiting VLAN might or might not be encapsulated over the MPLS backbone. Depending on which VPWS use case you intend to provision, you may need the service-delimiting VLAN to be transported across the MPLS backbone. In summary, RFC 4448 specifies two encapsulation methods for the transport of Ethernet frames over an MPLS network:

Encapsulation Methods

Raw Mode vs Tagged Mode

  • Raw mode (VC-type 0x0005 aka VC-type ethernet):
    • The service-delimiting VLAN (which has to be a SVLAN) is never sent over the PW
      • If there is a service-delimiting VLAN present, the ingress PE must pop this tag before encapsulating over the PW
    • The egress PE (receiving PE) may or may not push a service-delimiting tag before transmitting the frame on the AC (attachment circuit). However, it must not rewrite or remove any VLAN tags that are already present
  • Tagged mode (VC-type 0x0004 aka VC-type vlan):
    • The service-delimiting VLAN must be sent over the PW
      • If there is not a service-delimiting present, the PE must push a dummy VLAN before encapsulating on the PW
    • The egress PE may swap, pop or leave the tag unchanged, before sending the frame to the AC depending on its configuration
  • Both modes:
    • Non-service-delimiting VLANs (usually customer VLANs – CVLANs) must be transported transparently

Regardless of which method you decide to use, remember that CVLANs are always transported transparently. The key point is to figure out if you need to transport the SVLAN across the MPLS backbone or not.

Network Design Tip
Ultimately, the characteristics of your carrier network will dictate how many SVLAN tags you expect to receive on the other end. Typically, this depends on whether the CE/CPE is directly connected to the PE or if there are L2 switches between your CE and PE, which could be stacking VLAN tags along the way.

According to these requirements, some VLAN manipulation operations, e.g., push, pop or swap may be executed by the egress PE depending on the VC-type mode and the local configuration in place. These VLAN normalization operations also enable service providers to leverage certain VPWS use cases with an asymmetrical number of SVLANs on their ACs. For instance, you can provision VLAN-based with one PE with just one SVLAN, whereas the other PE works with double SVLANs (QinQ). In the first part of this article, only VPWS with a symmetrical number of SVLANs on the ACs will be covered.

Port-based vs VLAN-based VPWS

As you can see, according to this RFC, certain VLAN operations will be executed depending on the local configuration. As a result, the concept of what VLAN-based or Port-based VPWS represents in terms of configuration is determined by both the VC-type in place and whether the service-delimiting VLAN (defined by the xconnect vlan on DM4000 Switches) is set as tagged or untagged.

VPWS Application Scenarios

Essentially, when it comes to the application scenarios there are two major cases, either both PEs (PE1 and PE2) have a symmetrical or an asymmetrical number of SVLANs on their attachment circuits.

PEs with symmetrical number of SVLAN tags on their ACs

If both PEs have a symmetrical number of SVLANs on their ACs, the application scenarios will fall into any of these two use cases:

VPWS Use Case # PE1’s AC Ingress Traffic PE2’s AC Ingress Traffic VC-type
VLAN-based (PE1) – VLAN-based (PE2) single SVLAN single SVLAN vlan
Port-based (PE1) – Port-based (PE2) no SVLAN (untagged or only CVLANs) no SVLAN (untagged or only CVLANs) ethernet

VPWS Configuration Mismatch
Always make sure the same VC-type is set on both PEs, otherwise the VPWS won’t come UP. Also, remember that both PW-ID and the AC’s MTU signaled must match.

Use Case 1: VLAN-based (PE1) - VLAN-based (PE2)

This use case is commonly used when both customers’ traffic arrive on the PE’s AC with a SVLAN, usually transported by a Metro Ethernet network. As shown in Figure 1, both customers’ edge (CE) equipment are not directly connected to the PE. Consequently, their network traffic are distinguished by the local SVLAN.

vlanbased_vlanbased

Note that both PEs (PE1 and PE2) use VC-type vlan and they expect to receive the customer’s traffic already tagged with a SVLAN. Specifically, PE1 provides this VLAN-based VPWS on the SVLAN S1001, whereas PE2 offers this service on SVLAN S1002. Because the service-delimiting VLAN is only meaningful between each PE-CE interface (AC), it is possible to use different service-delimiting-VLANs on both ends of this VPWS. As depicted in Figure 1, the SVLAN is sent over the PW. If there are CVLANs present, as stated in RFC 4448, they are always transported transparently over the VPWS.

Network Design Heads Up
Although it is possible to have different SVLAN tags on each PE-CE (AC) interface, keep in mind you can break the control plane of L2 protocols if they are being encapsulated over the VPWS. For example, RSTP expects to receive the same VLAN number on both ends of the Ethernet link.

In this VPWS use case, considering the traffic flow between CE1 and CE2 and the configurations in place, the SVLAN operations that will be executed when the traffic is being sent by each egress PE on their AC can be summarized according to this table:

From To Egress PE VC-type xconnect SVLAN Ethernet interface SVLAN Operation Executed
CE2 CE1 PE1 vlan tagged Eth 2/26 swap SVLAN S1002 with S1001
CE1 CE2 PE2 vlan tagged Eth 1/26 swap SVLAN S1001 with S1002

Configuration

The following sub sections show the configuration of the VPWS Use Case 1: VLAN-based (PE1) - VLAN-based (PE2).

VLAN-based VPWS on PE1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
! Board models in this configuration:
! Unit 1: MPU384
! Unit 2: ETH24GX+2x10GX H Series
! Unit 3: ETH24GX+2x10GX H Series
! Unit 4: ETH2x10GX H Series
!
hostname DM4004_PE1
!
interface loopback 0
ip address 1.1.1.1/32
mpls enable
!
interface vlan 1001
name VPWS_AC
set-member tagged ethernet 2/26
!
interface vlan 3003
name MPLS_Uplink
ip address 3.1.3.1/24
ip ospf network point-to-point
set-member tagged ethernet 2/25
ldp enable
!
router ospf
router-id 1.1.1.1
network 3.1.3.0/24 area 0
network 1.1.1.1/32 area 0
log-adjacency-changes
!
mpls ldp neighbor 2.2.2.2
!
mpls vpws
vpn 1
xconnect vlan 1001 vc-type vlan
neighbor 2.2.2.2 pwid 1 mplstype non-te
no shutdown
!

VLAN-based VPWS on PE2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
! Board models in this configuration:
! Unit 1: ETH24GX+2x10GX H Series
!
hostname DM40001_PE2
!
interface loopback 0
ip address 2.2.2.2/32
mpls enable
!
interface vlan 1002
name VPWS_AC
set-member tagged ethernet 1/26
!
interface vlan 3003
name MPLS_Uplink
ip address 3.1.3.3/24
ip ospf network point-to-point
set-member tagged ethernet 1/25
ldp enable
!
router ospf
router-id 2.2.2.2
network 2.2.2.2/32 area 0
network 3.1.3.0/24 area 0
log-adjacency-changes
!
mpls ldp neighbor 1.1.1.1
!
mpls vpws
vpn 1
xconnect vlan 1002 vc-type vlan
neighbor 1.1.1.1 pwid 1 mplstype non-te
no shutdown
!

Verification

As you can see, VPWS is UP and running. Packets are being sent and received over the MPLS network:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
DM4004_PE1#show mpls l2vpn vpn 1
-------------------------------------------------------------------------------
VPN |Access Int|Uplink Intfs (PW's) |Status |Labels
-------------------------------------------------------------------------------
ID |Type|VC typ/VID|Pwid |Dest address |PW |VC |Backup |Local |Remote
-------------------------------------------------------------------------------
1 |VPWS|vlan 1001 |1 |2.2.2.2 |Up |Up |None |16 |16
-------------------------------------------------------------------------------
DM4004_PE1#show mpls l2vpn counters vpn 1
Warning: Tx values can be overcounted if monitor is enabled at the interface.
+------+------+-----------+--------+-----------------+------------+------------+
| VPN | Type | Interface | Type | Peer/Tunnel | RX Pkts | TX Pkts |
+------+------+-----------+--------+-----------------+------------+------------+
| | Name - |
| 1 |------+-----------+--------+-----------------+------------+------------|
| | | Eth 2/26 | access | -- | 2 | 2 |
| | VPWS |-----------+--------+-----------------+------------+------------|
| | | Eth 2/25 | uplink | 2.2.2.2 | 2 | 2 |
+------+------+-----------+--------+-----------------+------------+------------+

Use Case 2: Port-based (PE1) - Port-based (PE2)

This use case is used when the customer edge (CE) device needs an exclusive Ethernet interface. The CE device is directly connected to the PE. As a result, even untagged traffic can be encapsulated over this Ethernet interface as illustrated in Figure 2. From the CE perspective, this Ethernet interface acts as a trunk that allows any VLANs.

vlanbased_vlanbased

As shown in Figure 2, both PEs (PE1 and PE2) use VC-type ethernet. In fact, PE1 provides this Port-based VPWS on the SVLAN 1001, whereas PE2 offers this service on SVLAN 1002. Although the service-delimiting VLAN is not encapsulated over the MPLS backbone, a local SVLAN is still necessary to be configured on each PE because all Ethernet interfaces on DM4000 Switches have to be associated with a VLAN internally. The Ethernet interface member of the SVLAN will be set as untagged.

On the egress PE (receiving PE) the MPLS header is stripped and because the AC interface is untagged, the PE will not push any SVLANs when transmitting the traffic on the AC. If there are CVLANs present, they are always transported transparently over the VPWS.

In this VPWS use case, considering the traffic flow between CE1 and CE2 represented in Figure 2, the SVLAN operations that will be executed when the traffic is being sent by the egress PE on the AC can be summarized according to this table:

From To Egress PE VC-type xconnect SVLAN Ethernet interface Native VLAN SVLAN Operation Executed
CE2 CE1 PE1 ethernet untagged Eth 2/26 1001 No Operation Executed
CE1 CE2 PE2 ethernet untagged Eth 1/26 1002 No Operation Executed

Configuration

The following sub sections point out the configuration of the VPWS Use Case 2, Port-based (PE1) - Port-based (PE2).

Port-based VPWS on PE1

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
! Board models in this configuration:
! Unit 1: MPU384
! Unit 2: ETH24GX+2x10GX H Series
! Unit 3: ETH24GX+2x10GX H Series
! Unit 4: ETH2x10GX H Series
!
hostname DM4004_PE1
!
interface ethernet 2/26
switchport native vlan 1001
!
interface loopback 0
ip address 1.1.1.1/32
mpls enable
!
interface vlan 1001
name VPWS_AC
set-member untagged ethernet 2/26
!
interface vlan 3003
name MPLS_Uplink
ip address 3.1.3.1/24
ip ospf network point-to-point
set-member tagged ethernet 2/25
ldp enable
!
router ospf
router-id 1.1.1.1
network 3.1.3.0/24 area 0
network 1.1.1.1/32 area 0
log-adjacency-changes
!
mpls ldp neighbor 2.2.2.2
!
mpls vpws
vpn 1
xconnect vlan 1001 vc-type ethernet
neighbor 2.2.2.2 pwid 1 mplstype non-te
no shutdown
!

Port-based VPWS on PE2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
! Board models in this configuration:
! Unit 1: ETH24GX+2x10GX H Series
!
hostname DM40001_PE2
!
interface ethernet 1/26
switchport native vlan 1002
!
interface loopback 0
ip address 2.2.2.2/32
mpls enable
!
interface vlan 1002
name VPWS_AC
set-member untagged ethernet 1/26
!
interface vlan 3003
name MPLS_Uplink
ip address 3.1.3.3/24
ip ospf network point-to-point
set-member tagged ethernet 1/25
ldp enable
!
router ospf
router-id 2.2.2.2
network 2.2.2.2/32 area 0
network 3.1.3.0/24 area 0
log-adjacency-changes
!
mpls ldp neighbor 1.1.1.1
!
mpls vpws
vpn 1
xconnect vlan 1002 vc-type ethernet
neighbor 1.1.1.1 pwid 1 mplstype non-te
no shutdown
!

Verification

As it can be seen bellow, VPWS is UP and running. Packets are being sent and received over the MPLS network:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
DM4004_PE1#show mpls l2vpn vpn 1
-------------------------------------------------------------------------------
VPN |Access Int|Uplink Intfs (PW's) |Status |Labels
-------------------------------------------------------------------------------
ID |Type|VC typ/VID|Pwid |Dest address |PW |VC |Backup |Local |Remote
-------------------------------------------------------------------------------
1 |VPWS| eth 1001 |1 |2.2.2.2 |Up |Up |None |16 |16
-------------------------------------------------------------------------------
DM4004_PE1#show mpls l2vpn counters vpn 1
Warning: Tx values can be overcounted if monitor is enabled at the interface.
+------+------+-----------+--------+-----------------+------------+------------+
| VPN | Type | Interface | Type | Peer/Tunnel | RX Pkts | TX Pkts |
+------+------+-----------+--------+-----------------+------------+------------+
| | Name - |
| 1 |------+-----------+--------+-----------------+------------+------------|
| | | Eth 2/26 | access | -- | 4 | 4 |
| | VPWS |-----------+--------+-----------------+------------+------------|
| | | Eth 2/25 | uplink | 2.2.2.2 | 4 | 4 |
+------+------+-----------+--------+-----------------+------------+------------+

Final Thoughts

In this article, two classic use cases of VPWS were discussed. VPWS is quite flexible in terms of configuration, which means you can leverage certain encapsulation characteristics when provisioning the service. I hope these two application scenarios helped you to understand better some nuances of VPWS encapsulation methods. Stay tuned in for the second part, where I’ll discuss more advanced use cases.

References