Exploring Complex MPLS VPN Applications: Models

and Implementations for Modern Communication

Demands
Emad S. Hassan (  [email protected] )
Jazan University
Ayman E. A. Abdelaal
Menoufia University
Ahmed S. Oshaba
Jazan University
Atef El-Emary
Jazan University
Moawad I. Dessouky
Menoufia University
Fathi E. Abd El‑Samie
Menoufia University

Research Article

Keywords: Multiprotocol Label Switching (MPLS), VPN services, Modern Communication Demands,
Layer-3

Posted Date: September 22nd, 2023

DOI: https://doi.org/10.21203/rs.3.rs-3347362/v1

License:   This work is licensed under a Creative Commons Attribution 4.0 International License.
Read Full License

Page 1/16
Abstract
In the modern landscape, robust data communication is pivotal for businesses and lifestyles. This has
led to intricate demands from enterprise customers for sophisticated communication solutions. As a
response, MPLS (Multiprotocol Label Switching) technology is being leveraged to meet these complex
connectivity needs. This paper undertakes a comprehensive exploration of intricate MPLS- Virtual Private
Networks (VPN) applications. The study entails both in-depth analysis and practical application on an
operational network to validate its efficacy. The research primarily delves into diverse models of complex
Layer 3 VPNs over MPLS. It commences by elucidating the foundational concept of a simple VPN and
subsequently navigates through various designs for deploying Layer-3 VPNs on MPLS networks. MPLS
technology has expanded the horizons of VPN services, catering precisely to contemporary business and
customer requirements. Beyond conventional peer-to-peer private communication, the technology
facilitates sophisticated iterations like managed service VPNs and overlapping VPNs. This paper
systematically navigates these intricacies, offering comprehensive insights into their mechanisms and
operational feasibility.

1. Introduction
Contemporary customers often express reservations about conventional Internet connectivity, primarily
due to security concerns associated with potential risks to confidentiality and integrity in public network
access. This apprehension has spurred the concept of Virtual Private Networks (VPNs), which have
emerged in various forms. VPNs leverage public infrastructures, such as the Internet, to establish private
networks accessible solely to authorized parties, mirroring the attributes of local networks in accessibility,
privacy, and management [1–3]. These VPNs fall into categories like Customer-Provisioned VPNs (CP-
VPNs) and Provider-Provisioned VPNs (PP-VPNs), further subdivided into Layer-2 and Layer-3 VPNs [4–
5].

In the realm of service provider-operated converged networks catering to diverse customer traffic, issues
arise, especially concerning time-sensitive data like voice and video, which may experience delivery
challenges affecting their desired characteristics. To ensure Service Level Agreement (SLA) adherence,
enhancing performance becomes imperative. This research presents an exhaustive survey of both
straightforward and intricate applications of MPLS VPNs, serving as the foundation for evaluating voice
traffic in this study [6–8].

Although Internet Protocol (IP) communication reigns supreme, it faces ongoing challenges, especially in
accommodating the diverse traffic requirements anticipated in modern and next-gen networks. These
networks must adeptly manage an array of traffic types serving distinct end-user applications, each with
unique characteristics and tolerance levels for disruption. For instance, voice traffic remains relatively
constant, whereas video traffic tends to be bursty, differing not only in traffic nature but also in sensitivity
to factors like Jitter. Non-real-time data transmissions are more forgiving of delay variations due to their

Page 2/16
tolerance for queuing. To enable a unified network catering to these diverse applications, performance
enhancement techniques are vital to tailor treatment to each application's distinctive needs [9–11].

This paper examines the utilization of MPLS VPNs for voice traffic transmission, evaluating various
performance enhancement methods to optimize throughput, minimize delay, and reduce jitter. The
intricate scenarios of MPLS VPN application are thoroughly expounded and practically implemented on
an operational network system to validate their efficacy. The study introduces diverse models of complex
Layer 3 VPNs over an MPLS infrastructure. It commences with the foundational simple VPN model,
elaborated in the initial section. Subsequently, the paper delves into distinct designs for Layer-3 VPNs
over MPLS networks, providing insights into their implementation strategies.

2. Classification based on Layer

2.1 Layer-2 VPN
VPN categorization comprises Layer-2 VPNs and Layer-3 VPNs, aligned with the OSI Model's Seven
Layers. Specifically, Layer-2 corresponds to the Data-Link layer, while Layer-3 pertains to the Network
Layer [12–13]. In a Layer-2 VPN, the Service Provider's entire network is perceived by the customer as a
Layer-2 Circuit/Switch. This arrangement precludes Layer-3 routing and header checks within the Service
Provider's network. Consequently, the Provider's devices remain devoid of customer-specific IP interfaces.
This design necessitates point-to-point IP addresses to be configured at both customer sites. For
example, if one site employs the IP address 10.1.1.1/30, the other site should adopt the corresponding IP
10.1.1.2/30 from the same subnet [14].

Customer-Provisioned VPNs are inherently Layer-2 VPNs, wherein the Provider remains unaware of the
VPN's creation. In terms of the VPN tunnel, the Provider functions akin to a Layer-2 switch. It's essential to
distinguish between the two interfaces at each customer site. The tunnel interface signifies the VPN and
presents a Layer-2 perspective, while the physical interface establishes IP peering with the Provider,
potentially involving routing protocols, and assumes a Layer-3 connection. Clarifying this hinge on
comprehending the tunnel interface's standpoint.
2.2 Layer-3 VPN
The Layer-3 VPN entails active involvement of the Service Provider in the routing process alongside the
customer. This involves configuring a Layer-3 interface with an IP address within the Service Provider's
network that corresponds to the customer's private network. For instance, if the customer's WAN interface
employs the IP address 172.16.1.1/30, the Provider's device facing that peer site configures the IP
address 172.16.1.2/30 within the same VPN. Moreover, a distinct subnet is designated for the point-to-
point connection between the Provider and the other peer site. For example, the subnet 172.16.7.1/30 and
172.16.7.2/30 might be allocated for this purpose [15–16].

Page 3/16
In the pre-MPLS era, implementing Layer-3 VPNs was notably intricate. It necessitated a dedicated router
for each customer on every Point of Presence (POP) of the provider, a management-intensive and
expensive undertaking. The advent of MPLS revolutionized Layer-3 VPN deployment, rendering it more
feasible.
2.3 MPLS – VPN
The core concept of MPLS-VPN revolves around the capability to allocate multiple labels (or a label
stack) to a single packet. The outer label serves as the transport label, overseeing the packet's
conveyance to its intended endpoint. As the packet progresses to the next Label Switching Router (LSR),
this outer label is assessed and potentially replaced or removed to facilitate the packet's journey to its
ultimate destination. An essential quandary arises: how does the ultimate destination router process this
incoming data? This is contingent upon the presence of an additional label, known as the inner label. In
its absence, the data advances to the routing engine, where its Layer 3 attributes (IP address) are
evaluated, culminating in the definitive decision concerning its ultimate target [17–20].

Conversely, if an additional label is present, it serves as a determinant for the associated VPN type (Layer-
2 or Layer-3). Consider a Layer-3 VPN scenario: the router scrutinizes the IP destination within the traffic
and endeavors to discover a corresponding entry within the Virtual Routing and Forwarding (VRF) table.
This specialized table corresponds to the specific VPN, assisting the router in shaping routing
determinations for the incoming data.

3. Applications of MPLS Layer-3 VPN

The conducted experiments were carried out on a Samsung Laptop equipped with an Intel Core i3
processor and 12 GB of RAM. The emulation utilized the renowned GNS3 emulator, which boasts
exceptional capabilities for simulating environments of various vendors such as Cisco and Juniper. Cisco
routers were emulated through the use of the IOU (IOS over Unix) software. In the provided topology,
individual customer routers (labeled as 'x') each possess a corresponding Loopback IP address that
corresponds to the router's number. For instance, for router 1, the Loopback address is set as 1.1.1.1, and
for router 2, the Loopback address is configured as 2.2.2.2, and so forth.

3.1 Simple VPN

Figure 1 presents the outlined requisites for the Simple VPN Topology [21]. The diagram depicts a
scenario with two distinct customers, labeled as 1 and 2, each encompassing two sites designated as A
and B. The fundamental premise of the simple VPN is to establish communication exclusively between
sites within the same VPN, while precluding interaction with any other sites. This traffic flow is explicated
in Fig. 2, which illustrates the allowed and restricted directions of communication. Achieving this
necessitates the allocation of route targets, as visualized in Fig. 3. Configuration details regarding the
Route-Target assignment across various nodes of the topology are showcased in Fig. 4. The ensuing

Page 4/16
outcomes are outlined in Figs. 5 (a, b, c, d), where a conspicuous alignment between the theory and the
routing tables of customer routers is evident.

3.2 Overlapping VPN

In the overlapping scenario, every customer features a Headquarters (HQ) site that interacts exclusively
with the branches within its own VPN [22]. However, the HQ site needs to communicate solely with the
counterpart HQ of the other customer, excluding the branches of that customer. The experimental
topology is presented in Fig. 6. While the route target configuration remains unaltered for PEs interfacing
with regular branch sites, modifications are implemented solely for PEs connected to the HQ sites,
represented by R3 and R4. The route-target assignment is elucidated in Fig. 7, offering insight into the
topology's configuration adjustments. These changes are visually detailed in Fig. 8, encapsulating the
configuration adaptations for both R3 and R4.

The anticipated outcome revolves around observing that the routing table of each branch exclusively
contains routes from its own branches and the HQ within the same customer. For instance, in the case of
Customer 1 Branch A, denoted as R7, we expect to find routes from Customer 1 Branch B and Customer 1
HQ, specifically 10.8.8.0/24 and 10.15.15.0/24, respectively. This pattern extends across the other
branches and their corresponding HQs.

Additionally, we foresee the HQ routers of each customer encompassing routes from their own branches
alongside the route linked to the counterpart HQ. For example, Customer 2 HQ router (R16) should include
routes from Customer 2 Branch A, Customer 2 Branch B, and Customer 1 HQ, which are 10.9.9.0/24,
10.10.10.0/24, and 10.15.15.15.0/24 respectively. Figures 9 (a, b, c, d, e, f) provide a visual depiction of
the BGP table for all customer routers. Notably, on HQ routers 15 and 16, certain routes only bear the AS
of the provider, indicative of routes stemming from the same VPN of the respective customer. Meanwhile,
routes marked with an unfamiliar AS (100 or 200) signify routes originating from the HQ of the other
customer.

Figure 10 shows the traffic flow on the Overlapping VPN.

3.3 Central Service VPNs

The Central Services VPN concept involves establishing multiple distinct simple VPNs. Each of these
simple VPNs may comprise numerous sites, coexisting alongside a centralized VPN accessible to all the
aforementioned simple VPNs [23]. Importantly, these simple VPNs remain isolated from one another. This
arrangement proves particularly useful when the provider maintains a server farm, offering services to its
customers through these servers over pre-existing VPN connections.

The experimental setup employs a topology depicted in Fig. 11. To implement this, route targets are
allocated, as depicted in Fig. 12, and subsequently configured, as outlined in Fig. 13.

In the preceding scenario, the anticipated outcome involves the presence of routes for all branches' LANs
across all customers in the routing table of router 15. Similarly, the LAN associated with the centralized
Page 5/16
service, denoted as 10.15.15.15.0, is expected to be present in the routing tables of all customer routers.
Conversely, no routes pertaining to customer 1 should be present on any router within customer 2.
Figures 14 (a, b, c, d, e) visually portray the BGP table for all customer routers, alongside the centralized
services router.

Upon scrutiny, the centralized services router reveals the coexistence of all LANs, complete with the
accurate AS numbers corresponding to the respective customers.

3.4 Hybrid VPN Configurations

3.4.1 Synthesizing Overlapping and Centralized Services
Various implementation scenarios emerge by amalgamating the distinctive attributes of the preceding
complex types. An instance of this integration occurs when solely the HQ sites within the customers'
VPNs necessitate communication with the centralized service VPN.

3.4.2 Managed CE VPN

This configuration can be regarded as an offshoot of the centralized services model. Here, the emphasis
lies on managing the loopbacks of the Customer Edge (CE) routers, introducing the service of overseeing
customer routers through a centralized Network Management System (NMS). This can be executed by
means of selective import and export policies. These policies designate the Loopback of the CE routers to
be exported with a designated Route Target, which is subsequently imported onto the centralized service
router.

4. Conclusion
Our exploration into complex MPLS VPN applications highlights their pivotal role in addressing
contemporary business and communication needs. The study delves deeply into Layer 3 MPLS VPNs,
dissecting their intricacies and implementations to cater to diverse demands. Through meticulous
experimentation, we analyze scenarios involving overlapping VPNs, centralized services, and managed
CE VPNs, showcasing their adaptability in dynamic networking environments. The study's insights hold
significance as businesses navigate evolving communication landscapes. The seamless integration of
VPNs, optimized performance enhancements, and precise route-target assignments form a robust
networking foundation, catering to multifaceted demands. This research underscores MPLS VPNs'
versatility in accommodating intricate communication scenarios, ensuring secure data exchange, and
facilitating tailored information flow. Ultimately, the study showcases MPLS technology's efficacy,
offering insights that guide businesses in constructing resilient, customized networking solutions in
today's digital era.

Declarations

Page 6/16
Acknowledgments: The authors extend their appreciation to the Deputyship for Research& Innovation,
Ministry of Education in Saudi Arabia for funding this research work through the project number ISP23-
56.

Competing Interests: N/A.

Supplementary Materials: No supplementary materials.

Data Availability Statement: Data sharing not applicable to this article as no datasets were generated or
analyzed during the current study.

Conflicts of Interest: The authors declare no conflict of interest.

Author contributions: Emad S. Hassan; methodology, Ayman E. A. Abdelaal; software, Emad S. Hassan;
validation, Ayman E. A. Abdelaal; formal analysis, Ahmed S. Oshaba; investigation, Ahmed S. Oshaba;
resources, Atef El-Emary; data curation, Atef El-Emary; writing—original draft preparation, Emad S.
Hassan; writing—review and editing, Moawad I. Dessouky; visualization, Fathi E. Abd El‑Samie;
supervision, Fathi E. Abd El‑Samie; project administration, Emad S. Hassan; funding acquisition. All
authors have read and agreed to the published version of the manuscript.

Funding: This research was funded by Deputyship for Research& Innovation, Ministry of Education in
Saudi Arabia, grant number ISP23-56.

References
1. Cheng, T., Zhou, F.: "5G Virtual Private Network Planning Methodology Analysis," 14th International
Conference on Wireless Communications and Signal Processing (WCSP), Nanjing, China, 2022,
pp. 1–4, (2022). 10.1109/WCSP55476.2022.10039428
2. Aung, S.T., Thein, T.: "Comparative Analysis of Site-to-Site Layer 2 Virtual Private Networks," IEEE
Conference on Computer Applications(ICCA), Yangon, Myanmar, 2020, pp. 1–5, (2020).
10.1109/ICCA49400.2020.9022848
3. Figueiredo, R., Subratie, K.: "Demo: EdgeVPN.io: Open-source Virtual Private Network for Seamless
Edge Computing with Kubernetes," 2020 IEEE/ACM Symposium on Edge Computing (SEC), San Jose,
CA, USA, pp. 190–192, (2020). 10.1109/SEC50012.2020.00032
4. Guo, K., Mukherjee, S., Paul, S., Rangarajan, S.: "Optimal customer provisioning in network-based
mobile VPNs," The First Annual International Conference on Mobile and Ubiquitous Systems:
Networking and Services, 2004. MOBIQUITOUS 2004., Boston, MA, USA, pp. 95–104, (2004).
10.1109/MOBIQ.2004.1331714
5. Houidi, Z.B., Meulle, M.: "A new VPN routing approach for large scale networks," The 18th IEEE
International Conference on Network Protocols, Kyoto, Japan, pp. 124–133, (2010).
10.1109/ICNP.2010.5762761

Page 7/16
 6. Zubilevich, A.L., Sidney, S.A., Tsarenko, V.A.: "The Effect of the Use of Service Level Agreement for
Operators of Transport Systems and On-Board Systems," 2021 Systems of Signals Generating and
Processing in the Field of on Board Communications, Moscow, Russia, pp. 1–5, (2021).
10.1109/IEEECONF51389.2021.9416045
7. Ganapathy, D.N., Joshi, K.P.: A Semantically Rich Framework to Automate Cloud Service Level
Agreements. IEEE Trans. Serv. Comput. 16(1), 53–64 (2023). 1 Jan.-Feb 10.1109/TSC.2022.3140585
8. Sahoo, S., Bigo, S., Benzaoui, N.: "Introducing Best-in-Class Service Level Agreement for Time-
Sensitive Edge Computing," European Conference on Optical Communication (ECOC), Bordeaux,
France, 2021, pp. 1–4, (2021). 10.1109/ECOC52684.2021.9605824
9. Ganapathy, D.N., Joshi, K.P.: A Semantically Rich Framework to Automate Cloud Service Level
Agreements. IEEE Trans. Serv. Comput. 16(1), 53–64 (2023). 1 Jan.-Feb 10.1109/TSC.2022.3140585
10. Zhang, H., Pan, G., Xu, S., Zhang, S., Jiang, Z., Hard, A.: and Soft Hybrid Slicing Framework for Service
Level Agreement Guarantee via Deep Reinforcement Learning," 2022 IEEE 95th Vehicular Technology
Conference: (VTC Helsinki, Finland, 2022, pp. 1–5, (2022). 10.1109/VTC2022-
Spring54318.2022.9860789
11. Peoples, C., Moore, A., Georgalas, N.: "Customer Classification Recommender to Support
Personalised Service Level Agreements Across the Internet of Things," IEEE 8th World Forum on
Internet of Things (WF-IoT), Yokohama, Japan, 2022, pp. 1–6, (2022). 10.1109/WF-
IoT54382.2022.10152125
12. Saputra, B.G.A., Nugroho, K., Ikhwan, S.: "Implementation of Layer 2 MPLS VPN on the SDN Hybrid
Network using Ansible and ONOS Controllers," IEEE International Conference on Communication,
Networks and Satellite (COMNETSAT), Purwokerto, Indonesia, 2021, pp. 27–31, (2021).
10.1109/COMNETSAT53002.2021.9530788
13. Budiyanto, S., Gunawan, D.: "Comparative Analysis of VPN Protocols at Layer 2 Focusing on Voice
Over Internet Protocol," in IEEE Access, vol. 11, pp. 60853–60865, (2023).
10.1109/ACCESS.2023.3286032
14. Darmawan, E., Budiyanto, S., Silalahi, L.M., "QoS Analysis on VoIP with VPN using SSL and L2TP
IPSec Method,": IEEE International Conference on Communication, Networks and Satellite
(COMNETSAT), Solo, Indonesia, 2022, pp. 130–136, (2022).
10.1109/COMNETSAT56033.2022.9994572
15. Yautibug Coro, A.L., Avila-Pesantez, D., Arellano-Aucancela, A.: "Evaluation of 6PE and 6VPE
techniques in MPLS-VPN networks for video streaming," IEEE International Conference on Machine
Learning and Applied Network Technologies (ICMLANT), Soyapango, El Salvador, 2021, pp. 1–5,
(2021). 10.1109/ICMLANT53170.2021.9690563
16. Pazienza, A., Lella, E., Noviello, P., Vitulano, F., "Analysis of Network-level Key Exchange Protocols in
the Post-Quantum Era,": IEEE 15th Workshop on Low Temperature Electronics (WOLTE), Matera, Italy,
2022, pp. 1–4, (2022). 10.1109/WOLTE55422.2022.9882818

Page 8/16
17. Sllame, A.M., "Performance Evaluation of Multimedia over MPLS VPN and IPSec Networks,": IEEE
2nd International Maghreb Meeting of the Conference on Sciences and Techniques of Automatic
Control and Computer Engineering (MI-STA), Sabratha, Libya, 2022, pp. 32–37, (2022). 10.1109/MI-
STA54861.2022.9837572
18. Gupron, M.Y., Umaisaroh, U., Wicaksono, A.: "Network Automation for CE Router with Route Leaking
in MPLS-VPN Network," 2022 International Symposium on Information Technology and Digital
Innovation (ISITDI), Padang, Indonesia, pp. 162–167, (2022). 10.1109/ISITDI55734.2022.9944460
19. Yan, T., Wu, W., Li, L., Xie, W., "Configuration method of cross-domain MPLS VPN based on double
MCE,": 6th International Conference on Wireless Communications and Applications (ICWCAPP),
Haikou, China, 2022, pp. 106–108, (2022). 10.1109/ICWCAPP57292.2022.00033
20. Gales, E.-M., Croitoru, V.: "Traffic Engineering and QoS in a Proposed MPLS-VPN," 2020 International
Symposium on Electronics and Telecommunications (ISETC), Timisoara, Romania, 2020, pp. 1–4,
10.1109/ISETC50328.2020.9301135
21. Ameur, S.Z.: Techniques and Tools for Encryption, IPSec and VPN. In: Computer Science Security:
Concepts and Tools, pp. 109–132. Wiley (2022). 10.1002/9781394163847.ch6
22. Sarsembagieva, K., Gardikis, G., Xilouris, G., Kourtis, A., "A fast route planning algorithm for MPLS-
TE,": International Conference on Telecommunications and Multimedia (TEMU), Heraklion, Greece,
2012, pp. 142–146, (2012). 10.1109/TEMU.2012.6294706
23. Rossberg, M., Grey, M., Trapp, M., Girlich, F., Schaefer, G.: "Distributed monitoring of self-configuring
Virtual Private Networks," 2013 IFIP/IEEE International Symposium on Integrated Network
Management (IM Ghent, Belgium, 2013, pp. 1080–1081. (2013)

Figures

Figure 1

Simple VPN Topology.

Page 9/16
Figure 2

Traffic Flow Direction in Simple VPN.

Figure 3

Route-Target assignment for the Simple VPN.

Page 10/16
Figure 4

Route target assignment on the network nodes.

Figure 5

a) Routing table of Router 7 For Simple VPN.

b) Routing table of Router 8 For Simple VPN.

c) Routing table of Router 9 For Simple VPN.

d) Routing table of Router 10 For Simple VPN.

Page 11/16
Figure 6

Overlapping VPN Topology.

Figure 7

Route Target assignment on Topology.

Page 12/16
Figure 8

RT assignment on PEs facing HQs for Overlapping VPN.

Figure 9

a) BGP table of R7 for Overlapping VPN.

b) BGP table of R8 for Overlapping VPN.

c) BGP table of R9 for Overlapping VPN.

d) BGP table of R10 for Overlapping VPN.

e) BGP table of R15 for Overlapping VPN.

f) BGP table of R16 for Overlapping VPN.

Figure 10

Page 13/16
Traffic Flow for Overlapping VPN.

Figure 11

Centralized Services VPN Topology.

Figure 12

RT assignment on the topology for Centralized Services VPN.

Page 14/16
Figure 13

RT assignment on configuration for Centralized Services VPN.

Figure 14

a) BGP table of router 7 for Centralized Services VPN.

b) BGP table of router 8 for Centralized Services VPN.

c) BGP table of router 9 for Centralized Services VPN.

Page 15/16
d) BGP table of router 10 for Centralized Services VPN.

e) BGP table of router 15 for Centralized Services VPN.

Page 16/16