Definitive MPLS Network Designs [Electronic resources] نسخه متنی

MPLS VPN Services in MPLS/IP Networks

A number of technologies provide Virtual Private Network (VPN) solutions. We define such solutions as those that can deliver private network access for many subscribers of the service across a shared infrastructure. One such technology used to provide these services is Multiprotocol Label Switching (MPLS).

MPLS may be used to deliver VPN solutions at either Layer 2 (as described in [L2VPN] and [VPLS]) through the use of Pseudowire technology or Layer 3 (as described in [2547bis]) of the OSI Reference Model. All solutions allow a network operator to deliver a private service over a shared IP network.

[GRE] or IP Security [IPSEC-ARCH]) provides Layer 3 service over an IP network.

During the late 1990s, only about 2 percent of Enterprise networks obtained Layer 3 VPN service from a service provider. The rest opted for Layer 2 transport services (primarily Frame Relay) and either a managed or unmanaged router service. The managed solution called for the operator of the network to provision and manage the customer premises equipment at the end of the transport circuit, whereas the unmanaged service simply provided a circuit to the customer on which that Enterprise installed routers and built their own VPN routing infrastructure.

However, over time, each of the aforementioned technologies suffers from scaling issues to varying degrees, especially when applications demand any-to-any connectivity (an example of which is voice over IP [VoIP]). When you select a VPN solution, the factors that determine its ultimate scaling properties are a key criterion. Evaluation of each technology should take into consideration the following points:

How much design, provisioning, and configuration are necessary for each new VPN

How provisioning and configuration scale with the number of VPN sites

How customer routing scales (how many adjacencies are needed)

How backbone routing scales (how many adjacencies and how much state)

How the service scales for the end customer

What type of services are required within a VPN

Splitting the different technologies into the two broad categories of overlay and network-based VPN can help you make such an evaluation. It is clear that an overlay arrangement does not scale to the size and number of client connections typically needed today. This is primarily because of the need to provision an individual connection from each site to every other site (so as to provide any-to-any connectivity) and the need to run routing adjacencies across these connections (an O(n) problem, where n is the number of sites). When contrasted with a network-based solution, where each site needs only a connection to its locally attached PE router (an O(1) problem, where 1 is a constant), it is easy to see that the network-based category is more appropriate for this environment. Therefore, the trend as we move into the 21st century is to deploy a network-based Layer 3 VPN solution. This is where the MPLS VPN architecture based on [2547bis] really shines.

This architecture provides complete isolation between different end-customer network domains, both within the service provider core network and at the edge routers that provide the interface to the VPN service. It also provides the ability to reduce the amount of routing state that core routers within the service provider backbone network need to hold to meet the scalability requirements and ensure optimal service delivery. This was not true of earlier [2547bis] architecture (called the Layer 3 MPLS VPN architecture from this point on) and all its necessary components. We will also look at how this technology is progressing across autonomous system boundaries. For more detailed technical information, refer to [2547bis], [MP-BGP], [MPLS-VPN-Vol1], and [MPLS-VPN-Vol2] as additional resources.

Layer 3 MPLS VPN Network Components

Several network components are defined within the Layer 3 MPLS VPN architecture. These components perform different functions within the overall architecture framework and are used in combination to constitute a Layer 3 VPN service.

Figure 1-1 summarizes each of the network components used in the Layer 3 MPLS VPN architecture:

Provider network (P-network) The core MPLS/IP network administered by the service provider. Two P-networks are illustrated to show how different autonomous systems may be connected.

Provider router (P-router) An MPLS/IP router deployed within the P-network with no edge service attachments.

Provider edge router (PE-router) A service provider edge router that provides VPN end-customer attachment and service delivery.

Autonomous system boundary router (ASBR-router) A service provider autonomous system edge router that provides attachment to an adjacent autonomous system that belongs to either the same or a different operator.

Customer network (C-network) A customer network administered by the end user attached to the Layer 3 MPLS VPN service.

Customer edge router (CE-router) A customer router that provides a gateway between the C-network and the P-network. The CE-router may be administered by the end user (and thus belong to the C-network) or may be managed by the service provider.

Separation of Routing State at PE Routers

Because each PE router needs to support multiple end customers, separation of routing state between these customers is mandatory. This separation is achieved by storing routing information in customer-specific Virtual Routing/Forwarding instances (VRFs). A VRF may be visualized as a separate virtual router instance within a physical router. It consists of the following structures:

An IP packet forwarding and routing table

A set of interfaces that use the forwarding table

A set of rules that control the import and export of routes to and from the VPN-specific routing table

A set of routing protocol peers that inject routes into the VPN-specific routing table

Without this separation it would be possible for one VPN customer to gain access to another customer's private network. The VRFs also provide a mechanism whereby each customer can use his or her own registered IP address space, or private addresses from the [PRIVATE] space, without concern that his or her routing information might clash with another customer of the service provider, or the service provider infrastructure itself. Figure 1-2 shows how a PE router separates routing information via VRFs.

In Figure 1-2, each customer site attaches to the service provider PE router by way of one or more CE routers (which incidentally may also be a switch) and some form of attachment circuit (Frame Relay, ATM, Ethernet, and so on). It is possible for multiple customer sites to attach to the same PE router and therefore the same VRF (as is the case with C-network 3 in Figure 1-2). Each PE router interface that faces a customer site wanting to belong to a given VPN is associated with the VRF that corresponds to that VPN. This is so that the PE router can determine which VPN customer can be reached via which interface(s).

Customer-to-Service Provider Routing Exchange

As soon as the CE router has physical connectivity with the PE router, it must be able to exchange routing information with the service provider. This may be achieved through static configuration. In this case a dynamic routing protocol is unnecessary, because static routes provide all the necessary IP forwarding information. However, for customers who do not want to use static routing (for example, because of dual-homing requirements or a large number of routes that cannot be summarized), the Layer 3 MPLS VPN architecture specifies the ability to exchange routing information using a dynamic routing protocol such as Border Gateway Protocol version 4 (BGP-4), Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), or Routing Information Protocol version 2 (RIPv2). A PE-router can run multiple dynamic routing protocols concurrently, as illustrated in Figure 1-3.

Because many VPN customers may be connected to a single PE router, each running one of the dynamic routing protocols (or static routing), the PE router must be able to know which routing protocol update came from which VPN client. This functionality may be called the routing context, and each routing protocol process at the PE router may run multiple contexts, each belonging to a separate VPN. This is illustrated in Figure 1-3, where both C-network2 and C-network3 run EIGRP and the PE router can determine which VRF should be populated with which routes based on the context.

Label Allocation at the PE Router

As discussed in the later section "Carrier's Carrier Architecture"), to perform forwarding. Therefore, for each route received from a locally attached customer site, the PE router may allocate a separate labela label that represents the entire VRFor it may allocate a single label to represent several routes from the same source attached to that VRF. The label allocation policy is driven by how the customer attaches to the Layer 3 MPLS VPN service. If a customer has a single connection into its local PE router, allocation of a different label for each prefix has little benefit and increases the number of resources required at the PE router to store the forwarding state. Therefore, allocating a single label that represents the gateway (that is, the CE router through which the routes can be reached) is appropriate in this case. On the other hand, a customer who wants to use the Carrier's Carrier architecture, where label switching is extended across the PE-CE link toward the customer site, must use a single label per prefix to maintain the Label-Switched Path (LSP) between source and destination endpoint.

Advertisement of VPNv4 Routes Across the IP/MPLS Backbone

Having received local routing information from attached customer sites, either via a dynamic routing protocol or through static configuration by the service provider, a PE router advertises the routing state to other PE routers in the network for subsequent distribution to remote customer sites in the same VPN.

Because multiple customers may use the same IP address space (which typically happens if they are using the addresses from [PRIVATE]), to avoid overlap within their service boundaries, the service provider needs to be able to distinguish between different customer routes. This is achieved through the creation of VPNv4 prefixes at the PE routers using extensions to BGP-4 (as detailed in [MP-BGP]) before the routes are advertised into the core network. VPNv4 prefixes are constructed by prepending a 64-bit route distinguisher to the IPv4 address, as shown in Figure 1-4. This ensures global uniqueness for each VPN route within the service provider backbone.

A number of different formats for the route distinguisher are possible, as shown in Figure 1-5. It should be noted that the route distinguisher value may differ at each PE router, even for the same VPN, because its purpose is to uniquely distinguish between IPv4 routes, not to identify a given VPN.