Our description of the MPLS/VPN architecture so far has assumed that all VPN customer sites are connected to a single service provider backbone across PE-to-CE links, and that the exchange of routing information across these links occurs without the need of MPLS, and without any direct exchange of routing information between customer sites. We have also highlighted the fact that a customer may choose to use the MPLS/VPN service to connect sites because this provides a more scalable way of providing VPN connectivity when compared to traditional methods such as the overlay or peer-to-peer models (described in Chapter 7, "Virtual Private Network (VPN) Implementation Options").
However, it is possible that these customer sites may actually belong to an Internet service provider (ISP) (where the ISP is a VPN customer of the service provider offering connectivity or bandwidth services). In addition, the customer sites could be dispersed across a wide geographical area, so they might need to attach to multiple service providers to obtain their VPN service throughout their organization.
All these possibilities require that extensions be provided to the basic MPLS/VPN architecture that we have so far described, to help scale the deployment and maintain connectivity between VPN sites when inter-site traffic crosses service provider boundaries. These extensions are provided through the carrier's carrier and inter-provider VPN architectures, and they are described also within RFC 2547bis.
As with all complex subjects, example topologies will be used throughout this chapter to help describe these architectural extensions. An example topology in which the carrier's carrier architecture may be appropriate can be seen in Figure 14-1.
Figure 14-1 provides the topology of the SuperCom MPLS/VPN backbone and shows that two VPN customers, EuroISP1 and EuroISP2, attach to the backbone in various points of presence (POP) locations. Each of these customers is an Internet service provider (ISP); the customers exchange full Internet routing information between their POP sites. Both of these VPN customers use the SuperCom network as transport between their sites.