MPLS and Next-Generation Networks: Foundations for NGN and Enterprise Virtualization

To understand this better, let us quickly create a reference model. In this reference model, we limit the discussion to the connection between the provider edge (PE) and the customer edge (CE) indicated by the remote access arrow in Figure 6-1.

The remote users can connect via cable, dial, or DSL and are terminated either directly on the PE or on another device, commonly referred to as a virtual home gateway (VHG) within the point of presence (POP). The method of access can vary depending on the service provider's facilities, service offerings, and protocols.

Remote access integration involves the mapping of users and their traffic to the appropriate MPLS VPNs. This requires the authentication and termination of sessions and the distribution of customer routes. L2TP or point-to-point tunnels might be required between customers' routers or user PCs and the provider's termination gateways. To understand these better, let us categorize them into three main components for a complete remote access integration solution with MPLS VPNs. They are as follows:

• Dial access

• DSL access

• Cable access

Let us now examine each of those components in some detail.

Dial Access

Dial access is used when a user is connected to the corporate VPN via a dial link. Dial access consists of both dial-in and dial-out to and from the PE device. A user can dial in to a network access server (NAS) device that terminates the user connection and maps the associated traffic to a VHG. Because each VRF within the PE holds customer routes, these VRFs must be populated with the dial user/route information. (Refer to Figure 6-1.)

Several components are common to various types of dial access. They are as follows:

• Virtual access interface The virtual access interface is an instance of a virtual profile or template used in the dialer configuration, and it must be VRF-aware.

• Authentication, authorization, and accounting (AAA) By using AAA, users are authenticated and per-user accounting stats can be maintained. Making the AAA servers aware of VRFs enables the sharing of AAA servers for use across AAA functions for multiple VPNs. Otherwise, a separate AAA server must be configured per VRF. The AAA server usually authenticates based on the user's domain and password to identify the VPN and then sends the configuration to the PE for the mapping of the user traffic to a particular VPN. Another authentication mechanism commonly used for dial users is Remote Access Dial-In User Service (RADIUS). RADIUS's usage principles are the same as those of AAA and can easily be adopted to authenticate remote users and map them to MPLS VPNs.

• Address management AAA servers can also perform address management using on-demand address pools (ODAP) and can provide addresses to clients. Address reusability is also possible using overlapping address pools. The Dynamic Host Configuration Protocol (DHCP) can be used to provide addresses to the VPN clients, and VRF-aware DHCP allows the sharing of the same DHCP server among multiple VPNs. Address pools can grow using ODAP for automated address management, and network address translation (NAT) can also be used for address translation from private to public address space.

One or more of these components is needed to enable dial access to MPLS VPN. Dial access can be further subdivided into the following categories:

• Individual users dialing in using an ISDN or PSTN network

• A CE dialing in to a PE creating a backup connection when the primary has failed

• A PE dialing out to remote CEs triggered by incoming traffic from the network

Let us now discuss each in detail.

Individual Access

One of the most common dial-in methods is dialing using public switched telephone network (PSTN) to a local or an 800 number. Figure 6-1 shows individual users dialing in to access a corporate VPN. The networks access server (NAS) then terminates the call and initiates a VPDN tunnel using L2TP to the appropriate customer VPN. This can include PPP, multilink PPP, or multichassis multilink protocols that are used for a better bandwidth connection. The sequence of events is fairly standard: The remote user initiates a PPP connection to the NAS via PSTN dial or ISDN dial. The NAS accepts the connection, authenticates the user, checks to see whether a tunnel exists with the VHG, and extends the user's PPP session to terminate on the VHG or PE in the appropriate VRF. The authentication process determines the specific VRF that this user needs mapped. If the L2TP tunnel does not exist between the NAS and VHG, the NAS establishes a new L2TP session.

The PE must then map remote users' sessions to the correct VRF and forward traffic. The PE can impose another level of authentication for PPP sessions to ensure that the correct users are being mapped to the correct VRFs. Additionally, the SP provides address management in such scenarios via DHCP using the VRF services discussed in the previous chapter. The rest of the route management and advertisement is standard to MPLS VPN operation and has been discussed in detail in the previous chapter.

Another option is to have the user directly dial in to the PE that is also a NAS device. In such a situation, the NAS/PE might authenticate the user and map the traffic to VPNs. This conforms to a collapsed NAS/VHG environment.

CE Dial Backup Access

Should the primary connection fail for any reason, dial backup is a common technique used as a cheap redundancy option for providing PE-to-CE connectivity. (See Figure 6-2 for details.)

The choice of using a redundant link for connectivity or dial backup is usually based on cost. In many places, using a redundant link is expensive; hence, dial backup is an affordable option especially for lower-speed connectivity between PE-CE devices.

The most common dial backup technique is to use ISDN dial backup to VHG or PE devices from the CE. The dial backup process can be to the same PE (if it also acts as a VHG for remote connections) or another PE that is a dedicated VHG. Either static routing or dynamic routing can be enabled on that dial connection.

The route learning and advertisement process is the same as in regular MPLS VPNs. However, dial backup usually works well with static routes. With dynamic routing protocols, though, the work involved with provisioning static routes can be less than that in a dynamic routing configuration.

If the service involves multiple CoS for the VPN, dial backup needs to take care of multiple classes. Special attention must be paid to address CoS requirements. For example, on the dial backup interface (due to lower available bandwidth) traffic is restricted to either high priority only or just high and medium priority and best effort is discarded or throttled down to accommodate high-priority traffic. This requires that different quality of service (QoS) templates be applied to regular interfaces and dial backup interfaces. In short, you must be sure to address dial backup for multiple classes of service.

Dial-Out Access

Instead of a remote CE initiating a connection to the VHG or PE, in this case, the PE dials out to the remote CE for connectivity. The PE-CE dial-out can be triggered based on incoming traffic from the network destined to the CE or scheduled at a particular time of the day. (See Figure 6-3.)

For example, a PE might dial out to remote point of sale sites to collect data or remote vending machines to collect inventories and sales data. This is useful for the retail market, where this function is automated. An example is discussed in a later section.

Dial-out uses the following sequence:

• Upon receiving the traffic, the PE brings up an L2TP tunnel and initiates a PPP session with the NAS. The NAS then dials out to the CE based on the information provided as part of the L2TP negotiation.

• In the direct dial-out case, the NAS directly dials out to the CE.

Much more complicated configurations can be easily created for load-balancing of NAS devices with a VHG/PE for large-scale dial-in/dial-out.

DSL Access

To understand DSL access to MPLS VPNs, let us examine the simple reference model shown in Figure 6-4.

In this reference model, the subscriber is connected to customer premises equipment (CPE)a DSL modemand is homed to a DSL access multiplexer (DSLAM). Multiple subscribers are aggregated to a DSLAM. Multiple DSLAMs can connect to a DSL aggregation router where the DSL connections (Point-to-Point Protocol [PPP] sessions) are terminated and routed into the network.

DSL access methods and configuration have several variations depending on the CPE configurations and the aggregation used in the access network. They are briefly described in the section that follows.

Routed Encapsulation

When the CPE equipment is a DSL modem with an integrated router, this encapsulation is used in the configuration. At the aggregation site, the interfaces are statically mapped to VRFs. For example, the PVC from DSLAM is terminated into a VRF on the PE. A normal interface configuration is required at the PE or the aggregation point, but no user authentication is required by the VHG or VHG/PE. The DSL router address assignment is done dynamically using DHCP and by using VRF-aware DHCP. A service provider can assign DHCP addresses to the CPE devices based on the VPN assigned. The PVC originating from the DSL router passes through the DSLAM and terminates at the VHG/PE. Static or dynamic routing can be enabled; however, in most cases static routing is used.

Bridged Encapsulation

CPE can also use bridged encapsulation. With the bridged encapsulation mode, the DSL modem provides transparent transport to user traffic. The ATM permanent virtual circuit (PVC) originates at the CPE and terminates at the aggregation point or the VHG/PE. The VHG/PE must be configured with IRB for packets to arrive as bridge encapsulation and then be routed to the VPN network. In this mode of operation, all user PCs/accounts sitting behind the DSL modem are assigned addresses by the provider and are authenticated by the provider. This can be an attractive option if the SP wants to bill based on the number of devices/connections using remote access connections. However, the provider might have to manage more than one user authentication per site. Address assignment is similar to that of the routed encapsulation except that it is now done for all devices behind the DSL modem.

The authentication mechanism here can be PPP over Ethernet (PPoE), and this can be done at the VHG/PE. The users are then mapped to VRFs after they are authenticated.

Cable Access

One of the most popular access method for remote access connectivity is cable. Cable is available in many more households than DSL. In fact, the Wall Street Journal reported in its September 13, 2004 Journal Report that a Harris Interactive study shows that cable modems have a slight advantage over DSL with 22 percent adoption versus DSL's 19 percent adoption across U.S. households. In-Stat/MDR (a market research firm) states in a 2003 report that more than 15 million households in the United States alone have access to cable broadband. The number reported for worldwide cable broadband access is 27 million subscribers. More and more corporations allow users to work from home or have remote offices. Getting cheap cable Internet access is easy and is almost the norm in metropolitan areas. To enable these sites and users to connect to corporate VPNs, these sites can nail a user-based IPSec tunnel to a VHG; then, the traffic is mapped to a VPN from the VHG.

The UMTS can also act as a PE device. For example, the Cisco uBR 10K can be the broadband router that performs the PE function in addition to terminating the broadband connections. Users are mapped to a VPN based on authentication. A simple identification procedure involves checking a user's domain name and authenticating the user with a password. The domain part identifies to which VPN the user needs to be mapped, and the password authenticates whether the user is allowed to access that VPN. VPN client software can be bundled to include such information as the nearest home gateway for authentication and authorization. Figure 6-5 depicts a remote access example for cable deployments.