VPNs were originally introduced to enable service providers to use common physical infrastructure to implement emulated point-to-point links between customer sites. A customer network implemented with any VPN technology would contain distinct regions under the customer's control called the customer sites connected to each other via the service provider (SP) network. In traditional router-based networks, different sites belonging to the same customer were connected to each other using dedicated point-to-point links. The cost of implementation depended on the number of customer sites to be connected with these dedicated links. A full mesh of connected sites would consequently imply an exponential increase in the cost associated.
Frame Relay and ATM were the first technologies widely adopted to implement VPNs. These networks consisted of various devices, belonging to either the customer or the service provider, that were components of the VPN solution. Generically, the VPN realm would consist of the following regions:
Depending on the service provider's participation in customer routing, the VPN implementations can be classified broadly into one of the following:
When Frame Relay and ATM provided customers with emulated private networks, the provider did not participate in customer routing. The service provider was only responsible for providing the customer with transport of customer data using virtual point-to-point links. As a result, the service provider would only provide customers with virtual circuit connectivity at Layer 2; this implementation was referred to as the Overlay model. If the virtual circuit was permanent or available for use by the customer at all times, it was called a permanent virtual circuit (PVC). If the circuit was established by the provider on-demand, it was called a switched virtual circuit (SVC). The primary drawback of an Overlay model was the full mesh of virtual circuits between all customer sites for optimal connectivity (except in the case of hub and spoke or partial hub and spoke deployments). If the number of customer sites was N, N(N-1)/2 was the total number of circuits that would be necessary for optimal routing.
Overlay VPNs were initially implemented by the SP by providing either Layer 1 (physical layer) connectivity or a Layer 2 transport circuit between customer sites. In the Layer 1 implementation, the SP would provide physical layer connectivity between customer sites, and the customer was responsible for all other layers. In the Layer 2 implementation (depicted in Figure 3-1), the SP was responsible for transportation of Layer 2 frames (or cells) between customer sites, which was traditionally implemented using either Frame Relay or ATM switches as PE devices. Therefore, the service provider was not aware of customer routing or routes. Later, overlay VPNs were also implemented using VPN services over IP (Layer 3) with tunneling protocols like L2TP, GRE, and IPSec to interconnect customer sites. In all cases, the SP network was transparent to the customer, and the routing protocols were run directly between customer routers.
Figure 3-1. Overlay and Peer-to-Peer Models
The peer-to-peer model was developed to overcome the drawbacks of the Overlay model and provide customers with optimal data transport via the SP backbone. Hence, the service provider would actively participate in customer routing. In the peer-to-peer model, routing information is exchanged between the customer routers and the service provider routers, and customer data is transported across the service provider's core, optimally. Customer routing information is carried between routers in the provider network (P and PE routers) and customer network (CE routers). The peer-to-peer model, consequently, does not require the creation of virtual circuits. As illustrated in Figure 3-1, the CE routers exchange routes with the connected PE routers in the SP domain. Customer routing information is propagated across the SP backbone between PE and P routers and identifies the optimal path from one customer site to another.
Separation of customer-specific routing information is achieved by implementing packet filters at the routers connecting to the customer network. Additionally, IP addressing for the customer is handled by the service provider. This process is also referred to as the shared PE peer-to-peer implementation. Figure 3-2 depicts the various implementations of the peer-to-peer model.
Figure 3-2. Peer-to-Peer Model Implementations
Controlled route distribution was another method of implementing the peer-to-peer model; routers in the core of the service provider's network contained network layer reachability information for all customers' networks. The PE routers (connecting customer network to provider network) in the provider network would contain only information pertaining to their connected customers. A dedicated PE router was required for each customer's site connecting to the provider network, and controlled route distribution would occur between P and PE routers in the SP backbone network. Only pertinent customer routes would be propagated to PE routers that were connected to sites belonging to a specific customer. BGP with communities was usually used in the SP backbone because it offered the most versatile route-filtering tools. This implementation is often referred to as the dedicated PE peer-to-peer model. This implementation, however, did not prove to be a viable operating business model due to the higher equipment costs that were incurred by the provider to maintain dedicated edge routers for customer sites connecting into the provider backbone. A need arose for deploying efficient VPN architectures that could implement a scalable peer-to-peer model.
Basic MPLS Configuration
Basic MPLS VPN Overview and Configuration
PE-CE Routing Protocol-Static and RIP
PE-CE Routing Protocol-OSPF and EIGRP
Implementing BGP in MPLS VPNs
Carrier Supporting Carriers
MPLS Traffic Engineering
Implementing VPNs with Layer 2 Tunneling Protocol Version 3
Any Transport over MPLS (AToM)
Virtual Private LAN Service (VPLS)
Implementing Quality of Service in MPLS Networks
MPLS Features and Case Studies