WHITE PAPER

Mobile VPNs for Next Generation GPRS and UMTS Networks

Alex Shneyderman With participation: Abbas Bagasrawala Alessio Casati

Introduction The concurrent evolution of computing, microelectronics, wireless data technologies, and the Internet have given rise to a new trend in global telecommunications - data mobility. There are now about 100 million hosts connected to the Internet, and this number is almost doubling yearly. With mobile subscribers expected to surpass one billion by 2003 (about half of which will be worldwide business users), wireless data is definitely a communications technology whose time is fast approaching. These skyrocketing subscriber numbers combined with recent technology advances are generating fast growing interest in the emerging Third Generation (3G) wireless data standards, which among other things specify the higher data rates necessary for wireless traffic. As this technology converges with the exponential growth of the Internet, network-based, Mobile Virtual Private Networks (VPNs) will become the major enabling technology for communicating business information via public networking infrastructures. Indeed businesses today already are looking to wireless carriers for Mobile VPNs (and other value-added IP services) as they attempt to cope with global on-demand communications, complex applications, productivity requirements, and shortages of IT talent. In the next few years, an enormous market opportunity clearly awaits wireless carriers who can meet demands for such advanced services. Two wireless packet data technologies — General Packet Radio Service (GPRS), a packet data overlay to the existing GSM and TDMA networks and Universal Mobile Telecommunication System (UMTS), the next generation of GSM/GPRS technologies — are central to the ability to provide high speed Mobile VPNs. These technologies provide necessary architectural framework for private mobile communications through the public Internet. This paper will focus on Mobile VPN services, comparing and contrasting circuit and packet approaches to wireless data. It also will examine the design and implementation of Mobile VPNs within GPRS and UMTS cellular systems.

Wireless Data Concepts: Packet vs. Circuit Existing Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), and Global System for Mobile Communications (GSM) cellular systems supporting circuit-based data, provide users with low-speed data connectivity. These technologies have a number of drawbacks including poor utilization of air-interface resources, limited availability, use of wasteful dial-up connection technology, and limited infrastructure integration. Packet technologies such as GPRS and UMTS were designed to overcome these limitations. With traditional, circuit-switched wireless data services, dedicated circuits at the physical layer are allocated to subscribers whether or not they are being used. In contrast, wireless packet data services allow subscribers to send and receive data without maintaining dedicated circuits.

Figure 1. Wireless Packet Data Concepts

Existing wireless packet data technologies that address these and other problems largely are conceptually similar and based on various tunneling mechanisms. (See Figure 1.) In all of them tunnels are dynamically established between the mobile node’s temporary point of attachment to the Internet and its home network (where the user is logically assigned the IP address). An alternative approach terminates tunnels at an Intermediate Gateway node that acts as an anchor point. User packets then may either be tunneled back to the home network (using another tunnel or a Link Layer technology) or directly delivered to a local interface for forwarding. As mobile nodes dynamically change their points of attachment to the network (traveling through certain area of the country from Mobile Switching Center (MSC) to MSC for example), tunnels are dynamically established between the home and visited networks.

Mobile VPNs Today’s growing mobile workforce — and its attendant requirements for remote data access — is forever changing the telecommunications industry. Telemetry and other un-tethered equipment, traveling sales forces, field maintenance crews, telecommuters, and other mobile professionals are driving demands for secure, anytime/anywhere access to corporate intranets, databases and e-mail servers. In this new environment, productivity gains (or losses) will be directly linked to the information delivery process. In the roughly ten years since their emergence, data VPNs typically have been implemented at the data link layer using Frame Relay and ATM networking technologies. Now VPN services based on IP and the use of the Internet are quickly gaining public interest and market acceptance. VPNs are evolving from voice to data services and from wireline to wireless data networks. Like traditional VPNs, IP VPNs utilize shared facilities to emulate private networks and deliver reliable, secure services to end users. Mobile IP VPNs, which must provide these services over wireless media, also use IP tunneling technologies. (See Figure 2.) GPRS and UMTS-based VPNs use a combination of GPRS Tunneling Protocol (GTP) on the dynamic “mobile” tunnel side and IETF-defined tunneling protocols on the “fixed” side. The business benefits of deploying Mobile VPNs (MVPNs) are numerous. MVPNs provide remote workers with constant, media-independent connectivity to corporate sites or to the ISPs and ASPs of their choice. MVPNs also enable businesses and ISPs to outsource mobile remote access — thereby eliminating the costs of purchasing and supporting the infrastructure while maintaining full control over address assignments and user authentication and security. In this way, corporations can leverage the Internet to provide anytime/anywhere, secure connectivity to remote offices, SOHOs, mobile employees, e-commerce and extranet business partners over public network infrastructure. By enabling always on connectivity, there is the potential to enhance relationships with customers, business partners, and suppliers by sharing in real time information.

Figure 2. Mobile VPN © 2000 Lucent Technologies, Inc.

Figure 3. Mobile VPN: Voluntary Tunnel

Implementing Mobile VPNs IP tunneling is central to implementing MVPN. In addition to traditional wireline VPN features, MVPN includes a set of mechanisms that use dynamic IP tunneling to support user mobility. IP tunnels are paths that IP packets follow while encapsulated within the payload portion of another packet. These encapsulated packets are sent to destination endpoints from originating endpoints via public (non-secure) channels. Tunnels also can exist on a link layer (similar to the Frame Relay model), providing encapsulation for non-routable protocols, such as Layer 2 Tunneling Protocol (L2TP) for Point-to-Point Protocol (PPP). There are two basic tunneling methods for implementing IP VPNs — end-to-end or “voluntary;” and network-based or “compulsory”. MVPNs based on voluntary tunneling are implemented by providing users with public Internet access, and subsequently with access behind corporate firewalls via available tunneling techniques that allow secure data transmission. (See Figure 3.) The end-to-end tunnel used in this case must exist for the duration of the session only.

Figure 4. Mobile VPN: Compulsory Tunnel

While voluntary tunneling provides a simple, secure end-to-end solution for access to private networks, it also leads to extra encapsulation overhead over last-hop wireless links. Also, this is a less efficient, more costly use of radio resources. In volume-based charging scenarios for instance, such overhead could significantly increase corporate costs for remote connectivity. Voluntary tunneling carries a number of other drawbacks as well. For example, it requires that mobile nodes be given public addresses allowing end-to-end transparent IP connectivity. In addition, it requires complex encryption and decryption algorithms, which can increase the complexity and cost of mobile devices, which typically have low processing power and are often battery power consumption limited. Also, with voluntary tunneling, applications that need to inspect or modify encapsulated packets will be unable to get access to user traffic. This means that QoS solutions, traffic-shaping mechanisms, monitoring equipment and firewalls will fail to perform their functions, and encapsulated (secured) packets cannot be modified by the Network Address Translation (NAT) protocol. Network-based “compulsory tunneling,” on the other hand, provides a more optimal foundation for MVPN solutions. (See Figure 4.) This tunneling approach assumes that not mobile devices, but the wireless operator’s network infrastructure itself features the intelligence and functionality necessary for the deployment of MVPNs. This approach assumes that the air interface owned by the wireless carriers is secure. With “compulsory tunneling,” network components such as access servers, gateways, etc. (not the mobiles) initiate tunnels, which typically terminate at the private network. Compulsory tunnels can be used by multiple subscribers and can remain active even if no subscriber transactions are in progress (thus placing less burden on the computing and routing infrastructure). The compulsory approach to tunneling also assumes the existence of proper agreements between corporations or ISPs and wireless operators. Service Level Agreements (SLAs) address the business relationships between service providers and corporations, while the Security Associations (SAs) or shared secrets used to generate IP Security (IPSec) session keys address the technical relationships. IPSec is a group of RFCs (RFC 2401 and companion documents) dealing with the secure encapsulation of IP traffic. Compulsory tunnels established through the public Internet require protection through authentication and encryption. This protection, however, need not be extended through the radio link but can be implemented between the tunnel end points only. Security in this scenario is likely to be based on IPSec, and will include mechanisms for distributing keys such as the Internet Key Exchange (IKE - RFC 2409).

Figure 5. 3GPP Release 99 interface reference model

To implement MVPNs capable of supporting services on a large scale, wireless data infrastructures will require a new class of platforms that fully comply with 3G and 2.5G wireless standards. Such systems will provide the critical ability to rapidly address demands for business-class IP services. SpringTide 7000 Wireless IP Service Switch addresses these requirements by leveraging a service-intelligent architecture, multi-protocol tunnel switching and true virtual routing. This powerful platform will enable wireless carriers to deliver the industry’s broadest portfolio of highly available IP services including Mobile Virtual Private Networks.

GPRS and UMTS Networks GPRS and UMTS wireless packet data technologies provide the higher speed data rates and the support for standard mobile protocols necessary for secure MVPN service offerings for private corporate customers. By enabling secure mobile data access, these technologies allow wireless carriers to meet the expectations of corporations and ISPs whishing to enable traveling professional with constant on-demand data access. The European Telecommunications Standards Institute (ETSI) defined GPRS as the standard for providing packet data services in GSM networks. UMTS, the Universal Mobile Telecommunication Systems specified by 3GPP, represents the 3rd generation of mobile communication systems. UMTS is an evolution of current GSM and GPRS standards, which is based on Wideband CDMA radio interface. A UMTS network is logically divided into a UMTS Terrestrial Radio Access Network (UTRAN) and a Core Network (CN) connected via an open Interface (the Iu interface). Both GSM GPRS and UMTS systems allow wireless service providers to offer bi-directional packet data over both air interfaces and backbone networks. As a result, both GPRS and UMTS CN allow for more efficient use of network resources for many types of applications. [a1]3GPP reference model defines the elements and interfaces of both GPRS and UMTS CN (See Figure 5.). GPRS defines radio channels with flexible allocation. From one to eight radio-interface timeslots can be allocated per TDM frame. Active users share timeslots and up and downlinks are allocated separately. Radio-interface resources can be shared dynamically between speech and data services as a function of service load and operator preference. EGPRS, an enhancement of GPRS, allows even higher bit rates on the radio interface. It achieves these rates by using new modulation and coding. The main elements of the GPRS and UMTS CN are the System GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN). The GPRS SGSN performs mobility management, implements authentication procedures and routes packet data. SGSN is the node to which mobile devices attach via the base station when making data calls. The SGSN performs session management and state control. It also handles data packet routing on the downlink to the mobile station, including location tracking and authentication between the network and the mobile device and its peers. SGSN sends queries to the Home Location Register (HLR) to obtain profile data on GPRS subscribers. It detects new GPRS mobile devices in a given service area, processes new subscriber registrations, and keeps records of their locations in that area. The GGSN is the gateway node between PLMN (Public Land Mobile Network) GPRS Backbone Systems (also known as UMTS Packet Switched Domain Backbone System in UMTS) and external data networks. In order to support data-user mobility, the GGSN acts as an anchor point for mobile session. It terminates the GPRS Tunneling Protocol (GTP) tunnels running over IP-based backbones between the GGSN and the SGSN to which the user is currently attached. GTP encapsulates user packets over IP/UDP transport paths and provides the set of control messages needed to set up and modify tunnels. The GGSN also provides functions including: • • • • • • • • •

Routing Address management (i.e. DHCP relay, static, dynamic address pool) Authentication, Authorization, Accounting (AAA) Client screening Traffic control Service performance measurements Firewalling Accounting data collection Advanced IP services (i.e. MVPNs, directory services, per-flow accounting, etc.)

Wireless data platforms such as GGSN can be implemented on general-purpose non-real time computers platforms with software routing capability such as Unix-based solutions or dedicated routing platforms such as Remote Access Servers (RAS), Routers, and IP Service Switches. © 2000 Lucent Technologies, Inc.

RAS devices are used to aggregate low-speed connections such as modem or ISDN calls from the PSTN and a small number of T1’s or T3’s. Typical RAS is designed to handle specific numbers of sessions, which are physically limited by a known number of interfaces with a known maximum throughput. RAS’s are relatively costly in that they employ resource allocation strategies and operating systems that generally are not optimized for efficient routing and tunneling support. In turn general-purpose routers traditionally have been designed to dynamically communicate with large numbers of networks via a limited number of individual connections. In today’s networks, IP router designs are optimized for use in dynamic clustered topologies that scale overall system performance by adding interconnected routers, rather than by scaling the number of connections to a specific router. Router designs were never intended to terminate tens (or even hundreds) of thousands of simultaneous individual connections, PPP sessions, tunnels or tunneling sessions.

SpringTide 7000 Wireless for Mobile VPN Services Lucent’s GGSN implementation is based on the industry-leading SpringTide 7000 IP Service Switch platform. By incorporating the strengths of the existing wireline platform with newly designed wireless capabilities, the Lucent GGSN will enable wireless operators to provide business-quality IP services for mobile users. The SpringTide 7000 architecture uses virtual routing to deliver carrier-class scalability and services for wireless carriers. It supports a flexible mix of tunneling protocols at both layer 2 and layer 3. These protocols can be mixed and matched on the access or backbone side of the device so that flows may be switched between one tunneling format and another as they traverse the switch. The service software within the 7000 dynamically creates the encapsulation and protocol stacks required to terminate, authenticate, route, and mediate policy for all of the supported tunneling technologies — all under policy control. As a state-of-the-art IP Service Switch, the SpringTide 7000, is designed to address the general shortcomings of routing solutions for wireless data and MVPN’s in that it can terminate and switch hundreds of thousands individual tunnels while applying the necessary service processing functions to each user traffic flow. Traffic enters and exits over any high-speed interfaces (i.e. ATM, Frame Relay) deployed within the wireless carrier GPRS and UMTS core network. The SpringTide 7000 can handle multiple tunnels over each of its interfaces and is equipped with carrier-class features such as NEBS 3 certification and full redundancy. The number of tunnels supported is limited only by the amount of memory and processing power of the routing/tunneling engines available. The SpringTide 7000 conveys traffic flows in virtual connections (i.e. virtual circuits, PPP sessions, IP tunnels) that are aggregated over its interfaces. It also is capable of aggregating and terminating hundreds or thousands of user communication (PPP) sessions. The SpringTide 7000 enables flexible, high-performance Mobile VPN services. It is equipped with all the necessary hardware and software to terminate, authenticate, encrypt, and route a multitude of VPN tunneling technologies including GTP, Mobile IP, IPSec, IP in IP, L2TP, PPTP, PPPoE, and PPPoA and GRE. Wireless carriers can use the tunneling technology of their choice and easily scale their MVPN services as they grow their businesses.

The “Virtual Router” Approach Like other products in the SpringTide family, the SpringTide 7000 Wireless is based on a switch architecture that uses a virtual router concept in which services are dynamically created across “virtual”-rather than physical-routers (GGSNs). Virtual routers provide the secure, segregated environments required for delivering business-quality IP services. Within the virtual router (GGSN), individualized service definitions for bandwidth, priority, and security are retrieved from policy directories and provisioned on either a per-subscriber or per-traffic flow basis. Virtual routers have their own routing tables and separate code address space with memory, which prevents any one virtual router from affecting other virtual routers. Each virtual router within the SpringTide 7000 Wireless has dedicated resources including allocated memory and instruction cycles that handle updates, make necessary changes to forwarding tables, and send them to be stored on — and utilized from — the local virtual router. Virtual routers also employ highly efficient methods of calculating and maintaining routing and forwarding tables. When the Route Processor Engine (RPE) gets the route update, it inserts it into the memory that has been allocated for that virtual router. The RPE then executes the correct algorithm unique to that virtual router. Several algorithms can be executed simultaneously within this architecture, each running individually without affecting the other since each virtual router is also allocated its own dedicated CPU cycles. © 2000 Lucent Technologies, Inc.

In contrast, general routing is a time-consuming, complex process in which devices map each packet to a specific context, based on the identity of the ingress port. The packet is marked with a label describing it as a member of a particular context. It is then handed off to a general-purpose processor through a shared PCI bus that recognizes the packet as a routing update. The processor then runs an algorithm to rebuild the entire routing table for every routing context within the entire switch, paying attention to the context labels.

GPRS and UMTS VPN Implementation GPRS and UMTS CN VPNs share most of the requirements for VPNs in general — such as authentication and data integrity, security and confidentiality, and non-repudiation and robustness. Often, MVPN users must be authenticated by both wireless access networks (through mechanisms such as HLR and VLR) and private IP networks (through AAA servers such as Remote Authentication Dial In User Service (RADIUS)). To prevent eavesdropping on data flowing between mobile users and corporate private networks and alteration of data by a third party, GPRS and UMTS Radio Access Network technologies protect packet data traffic by encryption over the air. This provides better performance than end-to-end encryption methods which add extra bytes to each packet sent over the air. It must be noted that there are a number of obstacles to VPN support in GPRS and UMTS CN systems frameworks. Standards require that both the initiating and terminating nodes of the GTP tunnels supporting mobility (SGSN and GGSN) must be located within private GPRS or UMTS CN networks owned by wireless operators. To provide VPN services in such environments, carriers must provision new tunnels between GTP tunnel termination points (GGSN) and corporate networks. This would require GGSN systems to perform tunnel switching, which places great demands on their processing power and tunneling capabilities. This also limits the VPN implementation options due to security considerations (more on this later). Extending GTP tunnels into corporate domains by placing a GGSN at or behind the corporate firewall is a possible remedy. But because this would force wireless carriers to open their private GPRS networks, it raises even more security issues. Although this model would allow corporations greater control over their data traffic, they would have responsibility for maintaining and administering wireless data networking equipment at their premises. Other issues with such scenarios would include the security of the whole GPRS infrastructure, and premises access when outsourcing GGSN management back to wireless carriers. The GPRS Technical Specification provides for transparent and non-transparent modes of interconnection between private GPRS networks and external IP networks. Transparent Mode supports only IP-based communication and creation of IP-type Packet Data Protocol (PDP) contexts at the GGSN. Non-transparent mode supports both IP and PPP modes of operation with IP or PPP-type PDP contexts created at GGSN. With Transparent GPRS access mode: • • • •

GPRS operators offer connectivity to IP networks without any user access authentication Mobile devices do not send any authentication request at PDP context activation GGSNs do not take part in the user authentication or authorization process Authentication is applied only at the wireless level between mobile devices and SGSNs by utilizing HLR , VLR, and other physical layer elements. • GPRS operators issue public IP addresses to GPRS users Wireless operator in this scenario has an option to assign dynamic IP address to mobiles, using DHCP relay mechanism. In this scenario GGSN will relay requests on to a DHCP server and responses to the mobile station. Once the IP address has been established, GGSN will update its routing tables and send a GTP Update context message to the SGSN. The transparent mode provides at least a basic ISP service. It may also provide a bearer service for an endto-end tunnel (for example IPSec) to a private intranet (See Figure 6). Non-transparent access mode can be utilized for providing network-based VPN services. With nontransparent GPRS access: • The MS is allocated (statically or dynamically) a private IP address belonging to the ISP or corporation • GGSNs request user RADIUS authentication based on user authentication requests made at PDP context activation • Tunneling protocols, such as IPSec or L2TP, are used between GGSNs and ISPs or corporate private network to transmit user traffic to a final destination point © 2000 Lucent Technologies, Inc.

Figure 6. Transparent Internet access; Voluntary Tunnelling In this mode the GGSN can perform authentication and obtain a dynamic IP address for the mobile station. A Non-transparent IP session will rely on PPP CHAP and IPCP messages being in the protocol options during session negotiation for authentication and IP address assignment or validation. The Lucent GGSN enables a number of efficient approaches based on IPSec tunneling, IP/MPLS RFC 2547, L2TP, etc. for building network-based GPRS VPNs in Non-transparent mode. It also features unique capabilities to dynamically create virtual routers (GGSNs) that enable highly scalable Mobile VPNs.

IPSec based MVPN The IPSec protocol suite (RFC 2401) specifies a set of IP extensions that provide security services at the network layer. IPSec technology is based on standard cryptographic technologies that enable very strong data integrity and privacy guarantees. As IPSec secures the network layer connectivity, the IPSec protocol suite guarantees security for any application using it. Security services offered include connectionless integrity, data origin authentication, confidentiality (encryption), and traffic flow confidentiality. These services are accomplished via two traffic security protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP). Each protocol supports two modes: transport mode and tunnel mode. In transport mode, the protocols provide protection primarily for upper layer protocols. In tunnel mode, the protocols are applied to tunneled IP packets. IPSec normally is associated with end-to-end voluntary tunneling approaches, but also can be used in a network-to-network, compulsory tunneling context and for security at the transport layer when combined with an L2TP based solution. This solution requires that the GGSN directly associate the mobile device’s IP address with the IPSec tunnel so that packets to/from the mobile traverse only that tunnel. Corporations may use private IP addresses that conflict with public Internet address assignments, as described in RFC1918. Figure 7 depicts the session flow of a PDP context establishment in which users are authenticated for private network access via highly-trusted, third-party Private Key Exchange (PKI) service providers. This scenario may be viable for corporations seeking to lower the cost of internal security systems, while avoiding full trust in their wireless carrier. Wireless carriers could, themselves, offer to provide the PKI as part of a value-added service, which might also include wireless e-commerce transaction services for horizontal services/markets. In such cases, each VPN would be defined by filtering rules in a managed firewall, with trusted GPRS HLR look-ups used to authenticate mobile subscribers to “VPN groups” for access behind the corporate firewall. When implementing and using IPSec, the security and system requirements of users, applications, and sites must be carefully considered. Service providers also need to be aware that IPSec, if deployed incorrectly, can adversely affect users, hosts, and other Internet components. For this reason, corporations © 2000 Lucent Technologies, Inc.

Figure 7. Transparent Access, IPSec in tunnel mode using IPSec for wireless remote access and Mobile VPN connectivity might require professional services to provide the necessary expertise for deployment. IPSec based VPN is the most likely scenario for the wireless operators whose GGSNs can not support PPP mode of operation in a required scale. Non-transparent IP based mode do not allow for access challenges to be generated by RADIUS servers. Instead, challenges are generated locally by the Mobile Termination (MT) component of the mobile phone. Because it is possible for impostors to tweak mobile phones to generate replayed challenge/response pairs, AAA mechanisms are weaker (in terms of anti-replay protection) than PPP-based systems, such as the ones obtained using PPP PDP types. This limits the ability of corporations and ISPs to administer users through AAA and IP address assignment. Instead, corporations, ISPs and their customers must trust wireless carriers to perform all these functions. In today’s security-conscious environment, offering services to ISPs and corporations experienced in handling PPP based communications without supporting PPP-based PDP contexts (or only small numbers of them), severely limits service provider ability to offer business-quality IP services.

MPLS based MVPN Because of its traffic engineering capabilities, MPLS (Multi-Protocol Label Switching) is fast emerging as an attractive option for forwarding IP packets over multi-service backbones in wireline networks. MPLSbased VPNs are relatively easy to implement on GGSN based on routing platforms and, for this reason, are being heavily promoted by traditional router manufacturers (whose products lacking the scaleable support for other types of tunneling) trying to enter the wireless market. In contrast Lucent is offering the unique solution that leverages two of VPN technologies - virtual router and MPLS, to offer the business quality MVPN. MPLS labels include distinct VPN identifiers that associate packets with private routing domains. This maintains both address secrecy, and the ability to handle duplicate or overlapping addresses. MPLS labelset-up protocols such as RSVP (Resource Reservation Protocol) or CR-LDP (Label Distribution Protocol) can communicate dynamic reachability information through the MPLS network The fundamental building block for SpringTide 7000 Wireless MPLS based VPN is Virtual Router (VR). Virtual routers provide the secure, segregated environments required for delivering business-quality IP services. Each virtual router has its own routing information base (RIB), forwarding information base (FIB) and a separate MPLS data forwarding engine with its own code address space with memory, which prevents any one virtual router from affecting other virtual routers. Within each virtual router, individualized service definitions for bandwidth, priority, and security are retrieved from policy directories and provisioned on either a per-subscriber or per-traffic flow basis. Since virtual router is not run as a separate task in the underlying operating system, CPU resources and memory utilization are independent of other virtual routers in the same system. The performance of one virtual router does not affect other virtual routers in the system. © 2000 Lucent Technologies, Inc.

Figure 8. Non-Transparent Access, MPLS-based VPN The Lucent MPLS MVPN architecture consists of two logical layers - Service layer and Network layer. The virtual customer equipment (VCE) supports the service layer. The provider router acts as a virtual label edge router (VLER) and interfaces with the SP backbone. The VLER supports the network layer. These two layers are tightly integrated and provide an elegant solution to building VPN. The beauty of this architecture is in its flexibility and scalability. The flexibility is provided in the VPN management. The VR maintains separate route, forwarding and MIB database. The database separation of each VR allows the wireless carrier and/or its corporate customers to monitor traffic statistics, configure policies to build dynamic on-the-fly extranets to corroborate with their business partners. One method for deploying GPRS VPNs is using a combination of BGP-4 and MPLS protocols defined in RFC 2547. This implementation is relatively straightforward when GGSN supports both BGP-4 and MPLS. GGSNs (or Provider Edge (PE) devices) are tasked with associating Customer Edge (CE) devices into a VPN group by virtue of common MPLS labels that combine the VPN ID with address prefixes used within each private routing domain. The GGSN PE has knowledge of all of the networks to which it is directly connected via CE devices. This includes knowledge of which networks belong to which private domain. Using that information, each GGSN (PE) builds and maintains its forwarding table. The information is then shared with other PE routers by using techniques (attributes, communities, new address “families,” etc.) supported by the BGP-4 standard. With a complete set of reachability information, as well as the knowledge of which networks belong to which VPN, the PE routers can label packets with the information necessary to forward them through the MPLS core over LSPs. Although MPLS can be combined with IPSec for security and with L2TP to utilize the advantages of PPP, this approach can significantly degrade network performance.

L2TP based MVPN Standardized L2TP (RFC 2661) evolved from various proprietary protocols such as layer 2 forwarding (L2F) and point-to-point tunneling protocol (PPTP). It specifies improved interoperability between multivendor tunneling equipment by extending PPP connections over different devices in separate networks, as well as over multiple links and networks. L2TP in and of itself, is not fully secure. Although it can provide secure CHAP-like authentication of the L2TP control connection, the potential for tunnel hijacking by expert hackers remains a possibility. To fully secure L2TP tunnels, service providers can use standard IPSec mechanisms independently developed by IETF. Manually configured static security associations could be part of an SLA between the corporation and the wireless network operator. Or, dynamic negotiation procedures could be used, if a PKI is deployed and trusted by both parties. L2TP operates in compulsory mode in which tunnels are supported by service provider network equipment. It also can operate in voluntary mode with tunnels initiated by mobile devices. L2TP compulsory service operation is made possible in GRPS and UMTS CN by the R’98 and RR ‘99 standards (PPP-relay case). To support this option, GGSN must support PPP-based PDP contexts on a significant scale. In this © 2000 Lucent Technologies, Inc.

case, mobile VPN users access corporate networks by first attaching to the GPRS network and then initiating PPP sessions and specifying Access Point Names (APNs). Once the PDP context is active, control of the communication session is passed to the L2TP Access Concentrator (LAC) supported by GGSN, which triggers the establishment of a L2TP connection to the corporate L2TP Network Server (LNS) and performs GTP-to-L2TP tunnel switching. Newly-attached users can share previously established L2TP tunnels by creating new L2TP sessions within those pre-established tunnels. If the tunnel does not exist, a new tunnel will be created. The GGSN/LAC then uses the L2TP control connection to establish an L2TP call (L2TP tunnel to carry PPP) between the LAC and the LNS. Using the services of the corporate AAA system (e.g. RADIUS), the LNS performs the authentication of the mobile user. Following authentication, an IP address is assigned to the mobile using IPCP or other address assignment mechanisms. For corporate network management purposes, using private corporate intranet IP addresses is preferable. It also saves carrier’s limited number of public Internet addresses. Such communications, like security arrangements, are governed by SLAs or defined between a GGSN/LAC and corporate-based LNS. (See Figure 9.) In compulsory service operations, the wireless operator assigns APN network identifiers to corporations according to certain rules. The APNs are used by the SGSN to select the GGSN to be addressed for a specific group of corporate mobile users. Using data stored locally or IP roaming mechanisms requiring LACs to query AAA subsystems using the mobile user’s Network Access Identifier (NAI), the GGSN determines the IP addresses of the GGSNs/LACs to which mobile users will be attached.

Figure 9. Non-Transparent Access, L2TP-based VPN L2TP-based GPRS VPNs carry a number of advantages over other MVPN technologies. For example, because L2TP is the only GPRS VPN technology supporting full RADIUS authentication of mobile users, it provides extra levels of security beyond handset authentication by cellular systems. L2TP also can be used in remote access solutions that allow ISPs and corporations (possessing extensive experience in deploying L2TP based networks) to effectively combine their wireless and wireline access by outsourcing the mobile access to wireless carriers. In addition, value-added services (i.e. load sharing, backup support) will be available from any access server vendor supporting L2TP and corporations with L2TP based VPNs can retain full control over IP address assignments and AAA functions.

The Virtual Router Approach The virtual GGSNs, as implemented on SpringTide 7000 Wireless platform, are essentially a collection of individual logical GGSNs upon which a variety of advanced IP services can be built. With the virtual router approach, customers essentially lease network resources that are located on the GGSN owned by the wireless operator. The Mobile VPN behaves, and is managed, in much the same way as an actual physical private router network. © 2000 Lucent Technologies, Inc.

The services and functions of virtual routers — available individually to each of hundreds of virtual GGSNs provisioned in the SpringTide 7000 Wireless — include: • • • • • • • • • • • • • •

IP routing over varied protocols (RIP, OSPF, BGP-4, etc.) Route policies over high-speed cell or packet media GTP/PPP session termination GTP/IP session termination PPP tunneling (PPTP and L2TP) initiation and termination RADIUS client LDAP client (for directory-enabled policy and service attainment) QoS-enabled forwarding (both DiffServ and ATM CoS) Stateful firewall (as well as basic packet filtering) IPSec tunnel initiation and termination NAT/PT MPLS LER DHCP Relay Agent VLAN (802.1Q)

Some of the advantages of Springtide 7000 Wireless - based VPN solution are: • Management Flexibility: The VR model provides complete separation of software stack, management MIBs, routing and forwarding tables. This approach provides complete privacy for network management functionality-an important feature for wireless carriers serving business customers. Since each virtual GGSN has it’s own SNMP MIB, administrative access to individual virtual GGSNs can be isolated. • Directory Driven Model: The Springtide’s service definition is directory based. The directory-based approach is highly scalable and easy to deploy since if changes need to be made it has to be done in a single place. • Customized Services: The directory based policy model and fine grain identification of the user and/or application flows allows SP to customize services not only per VPN customers but also per applications for a VPN customer. For example, the SP can offer additional services to VPN customers such that certain traffic flows (applications) get strongly encrypted In addition, wireless carrier can leverage other Lucent GGSN features such as traffic engineering capabilities, directory based model, subscriber management features etc. to increase revenue and reduce operational cost (See Figure 10.)

Figure 10. Virtual Routing; Reduced Complexity, Higher Profits.

Conclusion In summary, virtual router approaches provide the multiple functions of traditional GGSN, B-RAS, ATM edge routers, customer premises VPN appliances, firewalls, and QoS/MPLS-enabled routers, among others. Virtual routing-based MVPNs utilizing the SpringTide 7000 Wireless effectively allow wireless operators to deploy any of the existing GPRS and UMTS VPN options without the drawbacks associated with the individual technologies.

Glossary 3G . . . . . 3GPP . . . AAA . . . . ATM . . . . AuC . . . . BLST . . . . BS . . . . . BTS . . . . . CDMA . . CGF . . . . EDGE . . . EIR . . . . . ETSI . . . . GGSN . . . GPRS . . . GSM . . . . GTP . . . . HLR . . . . IETF . . . . IMEI . . . . IMSI . . . . IMT-2000 IPSec . . . ISP . . . . . ITU . . . . . LCS . . . . . L2TP . . . . LAC . . . . LAN . . . . LNS . . . . MAN . . . MAP . . . . MSC . . . . NodeB . . OA& M . . PLMN . . . PDP . . . . PSTN . . . PVC . . . . QoS . . . . RA . . . . . RADIUS . RAS . . . . RNC . . . . RNS . . . . SGSN . . . SIM . . . . SMS . . . . SRNS . . . SVC . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.Third Generation .3rd-Generation Partnership Project .Authentication Authorization, Accounting .Asynchronous Transfer Mode .Authentication Center .Board Level Self Test .Base Station .Base station Transceiver System .Code Division Multiple Access .Charging Gateway Function .Enhanced Data rates through Global Evolution .Equipment Identity Register .European Telecommunications Standards Institute .Gateway GPRS Support Node .General Packet Radio Service .Global System for Mobile Communications .GPRS Tunneling Protocol .Home Location Register .Internet Engineering Task Force .International Mobile Equipment Identity .International Mobile Subscriber Identity .International Mobile Telecommunications 2000 .IP security .Internet Service Provider .International Telecommunication Union .Location Services .Layer 2 Tunneling Protocol .L2TP Access Concentrator .Local Area Network .L2TP Network Server .Metropolitan Area Network .Mobile Application Part .Mobile-services Switching Center .UMTS BaseStation .Operations, Administration and Maintenance .Public Land Mobile Network .Packet Data Protocol .Public Switched Telephone Network .Permanent Virtual Circuit .Quality of Service .Routing Area .Remote Authentication Dial-in User Service .Remote Access Server .Radio Network Control .Radio Network Subsystem .Serving GPRS Support Node .Subscriber Identity Module .Short Message Service .Serving RNS .Switched Virtual Circuit © 2000 Lucent Technologies, Inc.

TCP . . . . TIA . . . . TDD . . . TDM . . . TDMA . . UCR . . . UCU . . . UDP . . . UE . . . . URC . . . USIM . . UMTS . . UTRA . . UTRAN . VLR . . . VPN . . . WAN . . WAP . . . WCDMA

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

.Transmission Control Protocol .Telecommunication Industry Association .Time Division Duplex .Time Division Multiplex .Time Division Multiple Access .UTRA/ cdma2000 Radio .UTRA Channel Unit .User Datagram Protocol .User Equipment .Universal Radio Controller .User Service (or Subscriber) Identity Module .Universal Mobile Telecommunications System .UMTS Terrestrial Radio Access .UMTS Terrestrial Radio Access Network .Visitor Location Register .Virtual Private Network .Wide Area Network .Wireless Access Protocol .Wideband Code Division Multiple Access

SpringTide 7000 is a trademark of SpringTide Networks, Inc. All other trademarks, registered trademarks, service names, product and/or brand names are the sole property of their respective owners. This document is for planning purposes only and is not intended to modify or supplement any specifications or warranties relating to these products and services. Entire contents copyrighted by Lucent Technologies, Inc. Unauthorized redistribution electronic or otherwise, without prior written approval of Lucent Technologies, Inc. is prohibited by law. Requests for permission to copy or distribute, Lucent Technologies, Inc. Three Clock Tower Place, Maynard, MA 01754. To learn more, contact your Lucent Technologies representative, authorized reseller or sales agent. Or, visit our Web site at www.lucent.com. Specifications subject to change without notice.

05-GPRS601

© 2001 Lucent Technologies, Inc.