As defined earlier, CE-based VPNs are partitioned by tunnels established between CE devices. Routing inside the customer network often treats the tunnels as simple pointto-point links, or sometimes as broadcast local area networks. For customer-provisioned CE-based VPNs, provisioning and management of the tunnels is up to the customer network administration, which is also responsible for operation of the routing protocol between CE devices.
In provider-provisioned CE-based VPNs, the service provider(s) perform provisioning and management of the tunnels and may also configure and operate routing protocols on the CE devices. Of course, routing within a site is always under control of the customer.
CE Virtual Private Networks Over Virtual Connection Networks
The FR and ATM connection-oriented VPN alternatives largely apply to a single service provider. In order to connect each site to every other site in a fully meshed network of N number of sites, the service provider must provision on the order of N squared virtual connections (VCs). Note that each VC must be provisioned at every intermediate FR or ATM switch in the service provider network.
As the number of sites becomes large, service providers often interconnect the sites, creating what is called hub-and spoke architecture, as shown in Figure 6. Often, the hub sites are connected in a full mesh with branch sites dualhomed to a primary and secondary hub site, as shown in the figure. Another motivation for the hub-and-spoke design is that with a full mesh of sites, addition of a new site requires configuration not only of the new site but of each of the other VPN sites as well.
IP Security-Based Customer-Edge Virtual Private Networks
An analogous IP-based VPN network has the same number of hub-and-spoke sites but requires the addition of overlay IP security (IPsec) tunneling and/or encryption functions in the CE devices. There is no explicit connection through the devices in the service provider network. Instead, all the tunnel functions are implemented in the CE devices.
Scaling issues similar to those in CE devices overlaid on virtual connections arise in IPsec CE-based VPNs, but here the limits are the number of IPsec tunnels and the number of routing adjacencies a CE router can support. Therefore, large IPsec CE-based VPNs also have a hub-and-spoke architecture, as described previously.
Aggregated Routing Virtual Private Networks
The aggregated routing approach is one in which a separate forwarding table exists for each VPN on every PE that connects to a site in that VPN but where the exchange of routing information between the PEs is multiplexed, or aggregated together. The BGP/MPLS VPN approach uses extensions to the border gateway protocol (BGP) to implement this generic architecture. Llustrates an example of this approach, connecting sites from three VPNs, A, B, and C, in an extranet. Each PE has a separate virtual forwarding table for each VPN site that it serves, but the forwarded traffic and exchanged routing information uses a set of shared tunnels. Often these types of solutions are implemented on a single service provider network. However, there are some implementations across more than one provider network.
Virtual Router Virtual Private Networks
Although the virtual router (VR) also uses PE and P routers, there are several important differences, as illustrated in Figure 10. This example uses the same CE sites from the three VPNs discussed in the aggregated routing example above. In a VR VPN, a VR is dedicated to each VPN in every PE that supports a site for that VPN. This means that each enterprise can manage its own routing on the VR in the PE.
This works very well in cases where the enterprise network has other forms of connectivity between its sites: The VRs look like just another router to the enterprise network. Usually, a separate set of tunnels is allocated in a full mesh between the VRs, as shown by different line styles in the center of the figure. This allows excellent control of capacity allocation and control of QoS between the VPN sites.