Mobile VPNs For Next Generation GPRS And UMTS Networks

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.