MPLS virtual private networks allow service providers to deploy scalable VPNs. They build the foundation to deliver several
value-added services.
Connectionless service
A significant technical advantage of MPLS VPNs is that they are connectionless. The Internet owes its success to its basic
technology, TCP/IP. TCP/IP is built on a packet-based, connectionless network paradigm. This means that no prior action is
necessary to establish communication between hosts, making it easy for two parties to communicate. To establish privacy in
a connectionless IP environment, current VPN solutions impose a connection-oriented, point-to-point overlay on the network.
Even if it runs over a connectionless network, a VPN cannot take advantage of the ease of connectivity and multiple services
available in connectionless networks. When you create a connectionless VPN, you do not need tunnels and encryption for network
privacy, thus eliminating significant complexity.
Centralized service
Building VPNs in Layer 3 allows delivery of targeted services to a group of users represented by a VPN. A VPN must give service
providers more than a mechanism for privately connecting users to intranet services. It must also provide a way to flexibly
deliver value-added services to targeted customers. Scalability is critical, because you want to use services privately in
their intranets and extranets. Because MPLS VPNs are seen as private intranets, you may use new IP services such as:
You can customize several combinations of specialized services for individual customers. For example, a service that combines
IP multicast with a low-latency service class enables video conferencing within an intranet.
Scalability
If you create a VPN using connection-oriented, point-to-point overlays, Frame Relay, or ATM virtual connections (VCs), the
VPN’s key deficiency is scalability. Specifically, connection-oriented VPNs without fully meshed connections between customer
sites are not optimal. MPLS-based VPNs, instead, use the peer model and Layer 3 connectionless architecture to leverage a
highly scalable VPN solution. The peer model requires a customer site to peer with only one PE device as opposed to all other
CE devices that are members of the VPN. The connectionless architecture allows the creation of VPNs in Layer 3, eliminating
the need for tunnels or VCs.
Other scalability issues of MPLS VPNs are due to the partitioning of VPN routes between PE devices. And the further partitioning
of VPN and Interior Gateway Protocol (IGP) routes between PE devices and provider (P) devices in a core network.
PE devices must maintain VPN routes for those VPNs who are members. P devices do not maintain any VPN routes. This increases
the scalability of the provider’s core and ensures that no single device is a scalability bottleneck.
Security
MPLS VPNs offer the same level of security as connection-oriented VPNs. Packets from one VPN do not inadvertently go to another
VPN.
Security is provided in the these areas:
-
at the edge of a provider network, ensuring packets that are received from a customer are placed on the correct VPN, and
-
at the backbone, VPN traffic is kept separate. Malicious spoofing—an attempt to gain access to a PE device—is nearly impossible
because the packets that are received from customers are IP packets. These IP packets must be received on a particular interface
or sub-interface to be uniquely identified with a VPN label.
Ease of creation
To take full advantage of VPNs, customers must be able to easily create new VPNs and user communities. Because MPLS VPNs
are connectionless, no specific point-to-point connection maps or topologies are required. You can add sites to intranets
and extranets and form closed user groups. Managing VPNs in this manner enables membership of any given site in multiple VPNs,
maximizing flexibility in building intranets and extranets.
Flexible addressing
To make a VPN service more accessible, customers of a service provider can design their own addressing plan. This addressing
plan can be independent of addressing plans for other service provider customers. Many customers use private address spaces,
as defined in RFC 1918. They do not want to invest the time and expense of converting to public IP addresses to enable intranet
connectivity. MPLS VPNs allow customers to continue to use their present address spaces without Network Address Translation
(NAT) by providing a public and private view of the address. A NAT is required only if two VPNs with overlapping address spaces
want to communicate. This enables customers to use their own unregistered private addresses, and communicate freely across
a public IP network.
Integrated QoS support
QoS is an important requirement for many IP VPN customers. It provides the ability to address two fundamental VPN requirements:
-
predictable performance and policy implementation, and
-
support for multiple levels of service in an MPLS VPN.
Network traffic is classified and labeled at the edge of the network. The traffic is then aggregated according to policies
defined by subscribers and implemented by the provider and transported across the provider core. Traffic at the edge and core
of the network can then be differentiated into different classes by drop probability or delay.
Straightforward migration
For service providers to quickly deploy VPN services, use a straightforward migration path. MPLS VPNs are unique because
you can build them over multiple network architectures, including IP, ATM, Frame Relay, and hybrid networks.
Migration for the end customer is simplified because there is no requirement to support MPLS on the CE device. No modifications
are required to a customer’s intranet.
Feedback