Ericsson’s network-based IP-VPN solutions

Nail Kavak

The phenomenal success of the Internet and the universal adoption of the Internet proto- ty and reliability as from any other private
col are driving profound changes in the telecommunications industry. The infrastructure network, and can be used to offer the fol-
of the Internet is being used as the foundation for a new public IP network. In addition to lowing services:
existing best-effort applications, the emerging IP networks will offer the functionality need- • intranet—connectivity between corpo-
ed to support a variety of carrier-class and business-quality services, with the advantage of rate sites;
being ubiquitous, easier to access, and of costing less than competing alternatives. • dial-in access—business employees can
Many service providers are expanding the capacity and geographical coverage of their net- access the corporate network remotely;
works to meet rising customer demand. With virtual private networks, they can improve • extranet—secure connectivity between a
asset utilization and return on investments by leasing available capacity and providing new community of users or business partners
services. IP-based virtual private networks provide a means of extending the reach and scal- whose access is restricted to the resources
ability of legacy frame-relay and ATM networks. End-users gain ubiquitous access to the defined for that community; and
corporate intranet or extranet for business-to-business applications, IP telephony, or multi- • Internet access.
cast videoconferencing service. Ultimately, Internet VPNs will be the global means of busi- VPNs can be built in various ways. Some
ness communication just as the voice network is today. consist of routers and firewalls that are inter-
The author describes various virtual private network models and the details of Ericsson’s connected to the physical or logical leased
MPLS-based IP-VPN offering. line of carriers and service providers. Others
might include a combination of application
proxy firewall, encryption, intrusion detec-
tion, tunneling, and key management. Some
VPNs are managed in-house, while others
VPN services and are outsourced to a service provider.
architectures Whether the VPN constitutes remote-
access service to an intranet or extranet, a
VPN services service provider must somehow integrate
A virtual private network (VPN) consists of the VPN services into a common infra-
a set of geographically disparate sites that structure.
can communicate securely over a public or
shared infrastructure. IP-based VPNs (IP- VPN architectures
VPN) enable business customers seamless-
ly to receive the same security, connectivi- Remote access
Remote-access VPNs give end-users access
to a corporate intranet or extranet over a
shared public infrastructure. Ordinarily, a
VPN subscriber or a server in a remote of-
fice dials into a network access server (NAS)
Figure 1
Remote access scenario.
at the service provider’s point of presence
(PoP). After authentication, which is based
Enterprise 2 on the pre-configured user profile, a tunnel
ISDN is dynamically established to the tunnel
xDSL
PoP server on the customer premises (Figure 1).
A tunnel can be
Dial in LAC • client-initiated (voluntary)—in which
Telecommuters (NAS) case the tunnel is opened by the client and
L2TP PE
PE CPE terminated by the corporation without
LNS
any active involvement by the service
P
provider; or
• compulsory—in which case the tunnel is
P
created by the service provider’s network
P
access server and terminated either by a
PE
PE
service provider tunnel server or by a cen-
Enterprise 1 tral customer site server.
Enterprise 3
The security policy database can reside on
LNS the company premises or it can be out-
Tunnel ISP network LNS
end points sourced to the service provider.
A remote-access VPN allows users to take
CPE
advantage of low-cost Internet-access ser-
vices (as opposed to being assessed distance-
CPE sensitive bandwidth charges). Although
most remote-access services are currently

178 Ericsson Review No. 3, 2000

based on dial-in services, other access meth- CPE Router Router CPE
ods—including cable modems, xDSL, and
direct Internet access—are becoming in-
creasingly popular.
CPE Router Router CPE
CPE-based L2 overlay
The traditional way of building a VPN is to
use layer 2 (L2) overlay based on customer
premises equipment (CPE). L2 connectivi- CPE Router Router CPE
ty is provided between customer sites that
use asynchronous transfer mode (ATM) or
frame-relay via virtual circuits. In essence,
the provider furnishes a set of permanent vir- CPE Router Router CPE
tual circuits (PVC) between customer
sites—usually in full or partial mesh, but
sometimes also in hub-and-spoke configu-
rations (Figure 2). The PVCs are treated as Figure 2
“dumb pipes,” since they are not involved Layer 2 overlay VPN scenario.
in routing, packet filtering, or other layer 3
(L3) issues. An L3 overlay network is built
on top of the L2 network by running IP over
virtual interfaces between data link circuit
indentifiers (DLCI) or virtual circuits that
are connected to the CPE. The service
provider is usually responsible for configur-
ing and managing VPN connectivity.
The L2 VPNs described above can also be
used in combination with multiprotocol
label switching (MPLS). To the end-user, BOX A, ABBREVIATIONS
MPLS-based L2 VPNs are identical to tra-
ditional L2 VPNs. In reality, however, the ATM Asynchronous transfer mode LSR Label switch router
L2 circuits (ATM virtual circuits) initiated BA Behavior aggregate MF Multi-field classification
at the customer’s site are terminated at the BGP Border gateway protocol MPLS Multi-protocol label switching
ingress of the service provider’s domain and CBR Constant bit rate NAS Network access server
CCB Customer care and billing system NAT Network address translation
mapped to MPLS tunnels in the backbone. CIR Committed information rate OSPF Open shortest path first
This way, the service provider can offer mul- CoS Class of service P Core router
tiple services, such as public IP, private IP, CPE Customer premises equipment PDA Personal digital assistant
and voice over IP (VoIP), over a single ac- DiffServ Differentiated service PDM Policy deployment manager
DLCI Data link circuit identifier PE Provider edge router
cess circuit. DSCP Differentiated services code point PHB Per-hop behavior
DSL Digital subscriber line PoP Point of presence
CPE-based L3 overlay E-BGP Exterior border gateway protocol POS Packet over SONET
The VPN sites are interconnected via a mesh EXP Experimental POTS Plain old telephone service
of IP-over-IP (IPIP) tunnels that are estab- FEC Forwarding equivalence class PPTP Point-to-point tunneling protocol
FR Frame relay PVC Permanent virtual circuit
lished across the public network using any GRE Generic encapsulation protocol QoS Quality of service
kind of L2 technology (ATM, FR, PPP). In iBGP Internal BGP RD Route distinguisher
CPE-based VPNs, all complex functionali- IGP Internet gateway protocol RFC Request for comments
ty and all hardware needed to construct the INM IP network performance monitor RIP Routing information protocol
IPDA IP destination address RT Route target
VPN reside on the customer premises. The IPSA IP source address rt-VBR Real-time VBR
service provider merely provides access to IPsec IP security protocol SA Scheduling aggregate
the public network (without having to know ISIS Intermediate system-to-intermediate SLA Service-level agreement
anything about the topology of the VPN). system SLS Service-level specification
A VPN gateway is placed at each customer ISP Internet service provider SONET Synchronous optical network
L2FP Layer 2 forwarding protocol SP Service provider
site between the enterprise and the service L2TP Layer 2 tunneling protocol TE Traffic engineering
provider. Practically any tunneling tech- LAN Local area network UBR Unspecified bit rate
nique can be used between VPN sites, in- LER Label edge router VC Virtual circuit
cluding the LL Leased line VoIP Voice over IP
LNS Local network server VPN Virtual private network
• layer 2 forwarding protocol (L2FP); LPM Longest prefix match VR Virtual router
• point-to-point tunneling protocol LSP Label-switched path VRI Virtual router interface
(PPTP);

Ericsson Review No. 3, 2000 179

 • layer 2 tunneling protocol (L2TP);
• generic encapsulation protocol (GRE);
and
• IP security protocol (IPsec)—IPsec is be-
coming increasingly popular since it pro-
vides tunneling and security through data
encryption. It also facilitates confiden-
tiality, authenticity, integrity and key
management.
The end-user organization can choose to
manage the VPN in-house or it can out-
source the service to an external provider.
For many VPN user organizations, manag-
ing a VPN is costly and requires the services
of skilled, highly sought-after staff. On the
other hand, the management of outsourced
VPNs is a big business opportunity for ser-
vice providers, in particular because they can
amortize the cost over several customers.
They can provide basic Internet access with
best-effort services or they can offer multi-
ple class-of-service (CoS) and bandwidth
guarantees, emulating leased-line, frame-
relay, or ATM services.
Network-based MPLS VPNs
With a network-based MPLS VPN scenario,
the sites that constitute the VPN are con-
nected to the service provider’s edge router
Figure 3 ISDN access
Architectural overview of Ericsson’s VPN
backbone.
Router
AXI 520/
PSTN
AXD 301
AXI 540
SGSN
GGSN AXI 520/
AXD 301
Frame relay
Router
network
AXI 540
BSC
BSC
Mobile network
180
via physical or virtual links—through an
ATM or frame-relay access network. The
service provider’s backbone routers, which
carry the VPN traffic, are interconnected via
MPLS label-switched paths (LSP) or tun-
nels. MPLS is used for forwarding packets,
while the border gateway protocol (BGP) is
used to distribute routes and VPN mem-
bership information. All complex function-
ality and all hardware needed to build the
VPN reside on the service provider’s do-
main. Network-based MPLS VPNs do not
put any requirements on VPN customers,
which means customers can use their own
routers or an off-the-shelf router to connect
to the service provider’s network.
Network-based L3 VPNs
Network-based L3 VPNs are similar to
network-based MPLS VPNs—that is, all
VPN functionality, management, and hard-
ware resides on the service provider’s do-
main. However, instead of using MPLS tun-
nels to connect to the ingress and egress of
the provider’s edge routers, the network-
based L3 VPN uses IP tunneling mecha-
nisms, such as IPIP, GRE, and the L2 tun-
neling protocol (L2TP). This architecture
relaxes requirements for a fully native MPLS
Management center Remote access
Router
AXI 520/
AXD 301
AXI 540
Router
Central site
Telecommuters
Ericsson Review No. 3, 2000
backbone, and in cases of inter-provider op-
eration, it also relaxes the requirements to
support inter-provider MPLS.
Why network-based
VPNs?
End-user organizations can reap significant
advantages from outsourcing the operation
and management of their virtual private net-
works to service providers. Service providers
have solid network-management expertise.
They also have better resources and exper-
tise to provide cost-effective, carrier-class re-
liability, capacity, scalability, and global
reach. Moreover, service providers can offer
the services at a lower cost, by consolidat-
ing them over a common infrastructure.
Network-based VPNs can be imple-
mented on gigabit routers, or MPLS, ATM
or frame-relay switches—which is to say
that service provider investments in back-
bone equipment are protected. At the same
time, corporate customers need not invest
in special VPN hardware or software—any
off-the-shelf CPE router can be used to con-
nect to the service provider network.
In particular, network-based MPLS VPNs
provide more flexibility and scalability than
conventional VPN techniques (frame relay,
ATM, leased lines, and so on), since the edge
nodes of the network are “VPN aware.” Also,
MPLS better integrates IP and L2 networks
(FR, ATM) without the need for point-to-
point mesh configurations.
With respect to the IPsec-based L3 over-
lay, the additional security that is offered by
deploying CPE-based equipment does not
necessarily outweigh the costs of deploying
and managing the equipment.
The MPLS network can differentiate be-
tween services according to application type
and VPN membership. It can also provide
quality of service and privacy for delivering
value-added and closed user group services
over existing infrastructures. Furthermore,
it enables the service provider to utilize
backbone resources more efficiently thanks
to the advanced traffic-engineering mecha-
nisms that are an integral part of MPLS.
Ericsson’s MPLS VPN
Ericsson’s MPLS VPN solutions, which span
L2- and L3-based networks, offer compre-
hensive support for network-based and op-
erator-managed MPLS VPNs, but do not re-
quire service providers or customers to pro-
vide specialized CPE. In the section that fol-
Ericsson Review No. 3, 2000
lows, we will more closely examine
Ericsson’s support for IP-VPNs deployed
over L3 infrastructures with either packet-
over-SONET (POS) or ATM cores.
Ericsson’s VPN architecture makes use of
edge components such as the AXI 510 and
AXI 512 access routers and the AXI 540
edge aggregation router, as well as core com-
ponents such as the AXD 301 ATM switch
and the AXI 520 core router. Figure 3 gives
an overview of the available network com-
ponents.
VPN Requirements
Ericsson’s VPN offering addresses the re-
quirements put on CPE functionality, pri-
vate addressing, security, quality of service
(QoS) and service level agreements (SLA),
scalability, mobile or remote access, global
Internet access, inter-VPN connectivity and
policy, inter-provider operation, manage-
ability, and interoperability.
CPE complexity
A primary goal of the IP-VPN solution is
to minimize the configuration costs associ-
ated with the CPE. Service providers who
offer a turnkey service want to minimize the
management complexity and availability
concerns associated with managed CPE ser-
vices. Customers who manage their own
CPE typically want to minimize the re-
quirements put on internal technical staff.
Another requirement is that typical CPE
routers should be able to participate in the
VPN without a software upgrade. Ericsson’s
IP-VPN solutions, which make use of stan-
dard customer CPE (routers), do not require
special configurations or features, except
where service differentiation is required be-
tween customer equipment and the service
provider’s network. When this is the case,
the CPE must be configured to perform all
differentiated service-related (DiffServ)
edge functions, including classification,
marking, shaping, and scheduling. Cus-
tomers can enhance the security of the basic
VPN solution by introducing IPsec. Fur-
thermore, to gain access to the global Inter-
net via a single service provider connection,
customers with private address space must
implement a centralized network address
translation (NAT) function within their
VPN.
Private addressing
The service provider must be able to sup-
port a customer’s use of addresses that are
181
 PE
CPE
PE
CPE
Figure 4
Pipe model: Specified distribution of traf-
fic between each site.
not globally unique (for example, the local
addresses defined in RFC 1918, or address-
es that rightfully belong to another organi-
zation). Addresses are solely guaranteed
unique within the scope of a given VPN. An
address might, for example, be used in mul-
tiple VPNs, on the global Internet, or both.
Thus, an address must always be interpret-
ed within the scope of the VPN on which a
packet is traveling. The Ericsson IP-VPN
solutions support multiple instances of
overlapping address space without requir-
ing network address translation. The NAT
function is only required when two business
customers with overlapping address space
communicate with each other or when a
business customer who uses private ad-
dresses wants to access the global Internet.
Security
IP-VPNs replace private backbones with
the shared backbone of a public network
provider. Consequently, VPN customers
might be concerned about the confidential-
ity of data passing between VPN sites, wor-
rying that traffic originating from an unau-
thorized source outside the VPN can enter
the VPN (possibly masquerading as a legit-
imate VPN host). Security violations could
result in the exposure or corruption of sen-
sitive corporate data, unauthorized access to
computing resources, and denial of service
or electronic vandalism. While the utmost
security is obtained by implementing IPsec
or like technologies within the CPE, cus-
tomers who use IP-VPNs in place of frame
relay or ATM L2 VPN services obtain ade-
quate security via L2 (MPLS or ATM) or L3
182
PE
CPE
PE
CPE
tunneling within the service provider net-
work. In this case—provided it is possible
to limit the topology with which the data is
exposed when under the administrative con-
trol of a single service provider—the ad-
vantages of operational simplicity outweigh
the security risks of breached confidentiali-
ty. That is, topology control enhances data
confidentiality—the routing-decision pro-
cesses that include VPN constraints are
leveraged as part of the packet-forwarding
decision process.
QoS/SLA
Customers who build private leased-line
networks can be guaranteed specific band-
width on each link. Similarly, customers
who share public networks, such as frame
relay or ATM, receive service provider guar-
antees of bandwidth through, for example,
committed information rates (CIR). Obvi-
ously, customers who migrate to a shared IP
network must also be given the same kind
of assurances.
QoS models
Ericsson’s VPN solution can be based either
on a pipe or hose QoS model. The pipe model
is analogous to conventional leased-line
VPNs in which the customer knows the traf-
fic matrix or how traffic is distributed be-
tween VPN sites. The traffic matrix is trans-
lated into a set of pipes that meets the cus-
tomer requirements.
The hose QoS model guarantees perfor-
mance based on aggregate traffic specifica-
tions. In this model, the customer does not
necessarily know the traffic matrix. Instead,
Ericsson Review No. 3, 2000
 PE
CPE
PE Service provider network
CPE
to simplify the customer’s task of specifying
the performance requirements of the VPN,
performance characteristics are defined sole-
ly for traffic entering into a hose stub link
or exiting a hose to any other hose
(Figure 5). Apart from being very straight-
forward, this model allows customers to
vary, without changing their contract, the
volume of traffic that is sent to any other
hose endpoint, provided that the aggregate
traffic entering and exiting each of the end-
points does not exceed the capacity of each
hose.
The two VPN models put different re-
quirements on
• the engineering and provisioning of re-
sources in the backbone; and
• the description and monitoring of the ser-
vice level agreement.
Connectivity models
However, regardless of the QoS model used,
Ericsson offers two different connectivity
models for controlling QoS in IP-VPNs:
• Differentiated services—either the Diff-
Serv code point (DSCP) in the packet (for
pre-encapsulated packets, the router uses
the DSCP value in the clear-text header)
or the MPLS label+CoS is used to map the
packet to the behavior aggregate (and cor-
responding per-hop behavior) with strict-
ly configured scheduling parameters.
• Virtual circuit (VC)—traffic parameters
and a QoS service class (delay and
throughput sensitivity) are assigned to a
label-switched path or ATM VC with dy-
namic per-hop admission control, pre-
emption priority, and so on. Like the Diff-
Ericsson Review No. 3, 2000
PE
CPE
PE
CPE Figure 5
Hose model: Performance characteristics
specified for traffic from customer site to
the network.
Serv connectivity model, the virtual cir-
cuit connectivity model supports only a
few forwarding classes in the network.
Different LSPs that belong to the same
forwarding class are mapped to the same
buffer or queue. Distinct admission con-
trol policies and traffic conditioning
apply to each forwarding class.
To properly enforce service differentiation,
Ericsson products employ technologies that
identify, regulate, and isolate traffic.
• Identification is accomplished by means
of packet classification—that is, by
matching the components of a packet
header against a list of filters. In some cir-
cumstances, such as when a customer has
stringent security requirements or wants
to differentiate service to the stub link,
the classification must be performed at the
customer site.
• Regulation is accomplished by traffic con-
ditioning—that is, by shaping, dropping,
or re-marking packets based on the tem-
poral characteristics of the associated
packet stream (identified by a classifier)
relative to the traffic profile of the SLA.
• Isolation is achieved by using several
queuing or policy-based routing mecha-
nisms that provide dedicated router for-
warding resources (buffers, output link
bandwidth) or special network paths that
isolate enhanced-service traffic from con-
gestion that has been induced by tradi-
tional best-effort traffic.
Scalability
Obviously, service providers want to know
what impact VPN services will have on
183
 backbone resources. Concerns include the
scalability of routing protocols, stub link
density (with physical or logical interfaces),
and the per-packet processing required to
forward VPN traffic. Ericsson’s IP-VPN so-
lutions support techniques for increasing
scalability in carrier backbones.
Mobile and remote access
Besides fixed-site access, end-users should
be able to access the VPN over plain old
telephone service (POTS) dial-up, digital
subscriber line (DSL), cable modem, and
eventually, from truly mobile devices such
as personal digital assistants (PDA). Since
access is not necessarily tied to a physical
location, security is a major concern—for
instance, access might originate from an-
other provider’s network, such as a local
dial-up Internet service provider (ISP) who
operates in a wholesale scenario. Moreover,
because the CPE can be a laptop, cell phone,
or PDA, the CPE functionality must be
simple and ubiquitous. Ericsson’s IP-VPN
solutions support multiple tunneling
mechanisms (MPLS and L2TP) that permit
users who are connected via a fixed-site local
area network (LAN) or traditional dial-up,
DSL, and so on, to participate in the same
IP-VPN.
Global Internet access
Customers might want to access the global
Internet and the VPN from the same service
provider connection. Ericsson’s IP-VPN so-
lutions support customer networks with
globally unique addresses. If parts of the
VPN use non-unique addressing that con-
flicts with globally assigned addresses, the
VPN addresses take precedence over their
global counterparts.
Inter-VPN connectivity and policy
Some customers require more than one VPN
for inter-site communications. Some sites
might have to participate in multiple VPNs.
For example, a site could participate in
• an intranet VPN that connects it with
other corporate sites;
• an extranet that connects it with suppli-
ers; and
• a third extranet that connects it with other
organizations in the industry.
The site must communicate with each of the
VPNs simultaneously, and access must be
tightly controlled (an industry-wide ex-
tranet might include competitors who
should not be granted access to the corpo-
rate Intranet or who have access to only a
184
subset of resources). One VPN might also
function as a transit VPN which passes traf-
fic that originates at a second VPN and is
destined for a third VPN. When multiple
VPNs connect, their addresses must be
unique.
Inter-provider operation
Some customers want separate providers to
maintain distinct parts of their VPN. For
these customers, the IP-VPN solution must
span multiple provider networks and ensure
that all VPN forwarding, route propagation
and QoS/SLAs function across provider
boundaries. Initially, these inter-provider
VPNs will only be encountered where the
primary service provider cannot offer full
coverage for all customer sites or for all cus-
tomer access technologies. Inter-provider
operation stipulates that the VPN models
used must have minimum impact on
provider core networks, and that they sup-
port standards-based operation.
Manageability
Making the configuration of equipment in
the service provider’s network less complex
will have a good effect on scalability, oper-
ational functionality and operating costs. In
particular, this applies to the configuration
of provider edge (PE) routers that imple-
ment key parts of the IP-VPN service.
Interoperability
Ericsson’s IP-VPN solutions are designed to
operate within multi-vendor networks. To
minimize the impact on interoperation with
different core devices (some of which may
not support native MPLS), the solutions
support MPLS and L3 tunneling technolo-
gies. They also comply with industry stan-
dards for MPLS-VPNs in order to ensure in-
teroperability within networks composed of
multi-vendor PE solutions. Ericsson be-
lieves that compliance with appropriate
requests for comments (RFC) on MPLS VPNs
and dedicated interoperability testing will
yield implementations which are interoper-
able with other PEs that adhere to the MPLS
VPN RFC. There is no current standard for
non-MPLS VPNs (called IP overlay VPNs);
however, given the obvious benefit of sup-
porting multiple tunneling technologies, it
is believed that the industry’s standard fo-
rums can be induced to generate support for
them. Ericsson will consider accelerating
support for non-L2 tunneling mechanisms
if doing so accelerates interoperability with
third-party equipment.
Ericsson Review No. 3, 2000
Ericsson IP-VPN
architecture
The section that follows describes the inter-
network part of Ericsson’s IP-VPN solu-
tions. The main concepts of this architec-
ture are based on RFC 2547.
Overall topology
The VPN backbone is composed of the ser-
vice provider’s core routers (P) and edge
routers (PE) as illustrated in Figure 6. The
edge routers (AXI 510, AXI 512 or AXI
540) are
• connected to customer edge routers via
stub links (a physical or logical leased line)
and can run dynamic routing protocols
(routing information protocol, RIP, open
shortest path first, EBGP) to communi-
cate reachability information between the
customer and service provider; or
• statically configured with site reachabili-
ty information for the stub link.
Each edge router maintains separate for-
warding tables—every site to which the
edge router is attached is mapped to one of
these tables, which are used to determine
how a packet is to be routed. The core routers
(P) are unaware of the existence of VPNs at
the network’s edge boundaries. Two basic
architectures are supported: MPLS-VPNs
and IP-overlay VPNs.
VPN B1
MPLS backbone
PE P P
CPE
VR
VR
VPN A2 VR
Global
PE
VR
CPE VR
VR
VPN A1
Global
CPE
Ericsson Review No. 3, 2000
MPLS-VPNs
The CPE sends standard IP packets to the
ingress edge router, which routes the pack-
ets across MPLS tunnels to the egress edge
router. The core network (between the
ingress and egress edge router) is composed
of several routers or switches (P) that func-
tion as standard label switch routers. The
backbone that connects the ingress and
egress edge routers is fully compliant with
native MPLS.
A two-layer label stack is used across the
backbone: the top layer identifies a single
LSP connecting the ingress and egress edge
router, whereas the bottom layer, which de-
notes the CPE destination, is considered
only by the egress edge router. Since the
routers (P) are only concerned with the top
label, they only need to know the internal
topology of the backbone that connects the
edge router—that is, they do not require in-
formation on customer connections or
VPNs. The MPLS solution uses multi-
protocol extensions to BGP to communicate
VPN-specific routing information between
edge routers. The edge routers are fully
meshed and communicate through iBGP
sessions.
IP-overlay VPNs
The IP-overlay model is similar to the MPLS
model, but instead of using MPLS tunnels
VPN B2
Figure 6
MPLS-BGP/VPN architecture and compo-
nents.
CPE
PE
VR
P P
VR
VR VPN A3
Global
CPE
Internet
185

• Do lookup in VPN table
tunnels can be terminated at an entry point
• Determine path to egress router
of the VPN within the service provider’s
• Encapsulate in two-layer deep MPLS stack Internet
• Label swapping
Basic forwarding path operation
based on top level
VR
VR
VR
• Bind the label to
corresponding VR
Figure 7
VPN forwarding plane in action.
to connect ingress and egress edge routers,
the service provider employs IP tunneling
mechanisms. Initially, the IP-overlay model
supports L2TP tunneling, since this mech-
anism facilitates the multiplexing of VPN
traffic onto a single tunnel, thereby allevi-
ating scalability concerns. The use of L2TP
allows IP-VPNs to be deployed on back-
bones that do not fully support native
MPLS. And in cases of inter-provider oper-
ation, it relaxes the requirements for sup-
porting inter-provider MPLS.
In either architecture, fixed-site corpora-
tions are connected into the VPN via a stub
link that terminates at the edge router. Traf-
fic on the stub links can be transmitted in
the clear (assuming the customer site in-
cludes minimal CPE services) or it can be
tunneled or encrypted. Tunneling is used
across the service provider’s backbone to
support security, topology control, and cus-
tomer-addressing limitations. A combina-
tion of DiffServ, ATM QoS, and MPLS+CoS
is used to guarantee quality of service.
VPN customers with dial-up and broad-
band access connect to the network either
via CPE services—Windows PC supporting
point-to-point tunneling protocol (PPTP)
or IPsec over L2TP—or via AXI 510 or
AXI 512 access servers at the edge of the ser-
vice provider’s network (in which case the
186
tunnels originate on the access server). The
network or they can be terminated at the
customer premises.
The CPE router sends standard L3 IP pack-
ets to the edge router, usually without spe-
cial encapsulation or tagging. Using the vir-
tual router interface (VRI) scope that has
been configured for the virtual interface on
which the packet arrives, the edge router
performs standard longest prefix match
(LPM) lookup on the packet’s IPDA in a
VRI-specific forwarding table. The for-
warding table contains all reachable prefix-
es that reside in any of the VPNs of which
the interface is a member. If a matching pre-
fix is found, the packet is forwarded to a net-
work that resides in one of the VPNs; if no
matching prefix is found, the edge router
might look up the LPM in a global for-
warding table, which consists of global In-
ternet prefixes—the complete BGP table.
This table is only searched if the customer
interface has full global Internet connectiv-
ity. If the LPM lookups fail to return a
match, the packet is dropped and an “ICMP
unreachable” message is generated
(Figure 7). If a match is returned from the
VRI-specific table, the packet is encapsu-
lated in
• a two-layer MPLS label stack (for MPLS
VPNs) and forwarded along the LSP that
connects the ingress edge router with the
egress edge router; or
• L2TP headers (for IP-overlay VPNs) and
sent to the egress edge router over an IP
tunnel—a single L2TP tunnel that con-
nects a pair of ingress and egress edge
routers is used to multiplex traffic from
many VRI contexts (using the tunnel ID
field and a session ID field to identify the
VRI context).
Core devices are unaware of the existence and
configuration of VPNs (and associated per-
customer topology information) within the
PEs. Where the ingress edge router is at-
tached to a two-layer MPLS label stack on
each packet, the router (P) forwards the pack-
et using regular MPLS label-switched router
(LSR) pop-and-swap on the top label. Since
the top label defines the LSP that connects
the ingress edge router to the egress edge
router, the router (P) only needs topology in-
formation on the ISP backbone. This infor-
mation is usually obtained via an Internet
gateway protocol (IGP), such as OSPF or in-
Ericsson Review No. 3, 2000
termediate system-to-intermediate system
(ISIS). The backbone-forwarding path is also
completely protocol-independent. Thus,
any protocol that can be encapsulated in
MPLS can be forwarded between edge
routers.
In IP-overlay VPNs, most packets that
traverse the core are IP packets with the
IPSA and IPDA set to addresses that belong
to the ingress and egress edge routers. The
routers (P) must be able to route to addresses
that belong to edge routers, but require
no information on VPNs or customer
topology.
The egress edge router, which acts as an
MPLS label edge router (LER), uses the sec-
ond label in the stack to forward the pack-
et to the appropriate egress interface for the
destination CPE. The second label encodes
the VRI scope of the packet and the next
hop, and provides the information that is
needed to forward the packet to the appro-
priate CPE. If the CPE is in multiple VRIs,
the packet is forwarded across the appropri-
ate DLCI, VCI, or subinterface (or using the
appropriate tunneling or VLAN tagging
mechanism to denote the VRI scope of the
packet). The second label, which is assigned
by the egress edge router, is propagated via
the routing protocols (multiprotocol-BGP,
MP-BGP). This label, whose scope solely
• Translate IPv4 to VPN-unique address
VPN control plane in action.
• Send MP-iBGP update to all
EBGP, IGP
VR
(Static) VR
VR
• Import from BGP
• Distribute to CE
• Translate VPN-unique address to
IPv4
• Distribute to CE
Ericsson Review No. 3, 2000
applies to the egress edge router that assigns
it, is opaque to other routers. In IP-overlay
VPNs, packets received by the egress edge
router from the upstream routers (P) arrive
over an IP tunnel for which the edge router
serves as a termination point. The edge
router uses the IPSA, IPDA, and IP proto-
col field to identify the tunnel, and then uses
the L2TP tunnel ID and session ID to iden-
tify the CPE router to which the packet is
to be forwarded.
Routing and processing route updates
In VPN environments, the ISP backbone
serves as the core of an enterprise network.
The service provider is therefore responsible
for propagating reachability information
between each customer site, while preserv-
ing the VRI-specific context of prefixes, and
creating customized forwarding tables for
each distinct VRI.
Ericsson’s IP-VPN solutions support the
exchange of routing information with CPE
devices using standard IP routing protocols
(static routing, BGP, RIP, OSPF, or ISIS).
In all likelihood, given the requirements for
simple configuration of the CPE, static rout-
ing or RIP will become common methods
of communicating routing information.
Since the edge router is configured to con-
tain the VPN membership of each sub-
Figure 8
Internet
iBGP/MP
VR
VR
• Import from BGP
• Translate VPN-unique
address to IPv4
187
 interface, routes learned via a sub-interface
can be associated with the appropriate VRI
without requiring any special protocol sup-
port on the CPE. There is no one-to-one re-
lationship between a customer site and
VPN, since customers can be members of
multiple VPNs. The edge router inserts
routes obtained from a CPE into the appro-
priate VRI table, and then announces these
prefixes to other edge routers on the back-
bone using multiprotocol extensions to
BGP that allow each prefix to be qualified
with its VRI context. Similarly, each edge
router obtains VRI-specific reachability in-
formation via the internal BGP (iBGP) with
other edge routers, and propagates these pre-
fixes to the CPE using standard IGP or EGP
protocols (Figure 8). An isolated instance of
the IGP is used with each customer site to
ensure that routing domains are maintained
as distinct.
Prefixes are obtained from customers who
use conventional protocols (or static routing
information), but when non-unique prefix-
es are propagated across the provider’s back-
bone, they must be qualified with the VRI
context to which they belong. Standard
BGP4 can announce only one unique in-
stance of a prefix over a BGP session, and
BGP NEXT_HOP information is inher-
ently an IPv4 address. MP-BGP makes it
possible to announce a VPN-IPv4 prefix,
which is a standard IPv4 prefix qualified
with a 64-bit route distinguisher that com-
municates the VRI-specific context of that
prefix. When an edge router originates a
route into iBGP, either via a static an-
nouncement or by means of redistribution
from interior gateway protocol/external
gateway protocol (IGP/EGP) with a CPE, it
includes BGP NEXT_HOP, which points
to one of its own addresses and an MPLS
label. This label is essential to the edge
router. In traffic received from from the
backbone and destined to this prefix, the
MPLS label—the second in the label
stack—is used to forward the packet to the
appropriate CPE (Figure 4). In IP-overlay
VPNs, the egress edge router attaches an
identifier (L2TP tunnel and session IDs) to
the MP-BGP announcement of the route.
All VPN prefixes carried via MP-BGP
across the backbone are qualified with the
VPN in which they originated. These BGP
routes must only be announced (via an IGP
or EGP) to customers who are members of
the VPN from which the route originated.
A new BGP attribute, target VPN (effec-
tively a 64-bit extended communities at-
188
tribute), denotes the list of VPNs to which
the route must be announced.
Scalability
In traditional connection-oriented networks
(leased line, frame relay or ATM), circuits
are overlaid between each customer router
to provide VPN connectivity. For VPNs
that include many sites, this approach gen-
erates numerous circuits that must be man-
aged and processed. In contrast, with MPLS-
based VPNs, the label-switched paths are
established from peer to peer based on the
L3 topology. Thus, customer routers need
only peer to a single edge router, regardless
of the number of sites within a VPN.
In addition, MPLS tunnels can be shared
by different VPNs (VR). Thus, a rise in the
number of customers or VPNs has no im-
pact on the number of LSPs. L2TP tunnels
can also be multiplexed using the session or
tunnel ID to reduce the number of tunnels
in the backbone.
In MPLS, the edge routers must only keep
information on the VPN of directly attached
routers. In addition, sites that share the same
routing information or sites that belong to
the same VPN can share the same VPN rout-
ing table. Furthermore, thanks to label
stacking, the core routers (P) need not know
anything about VPNs.
To further reduce the burden on edge
routers, existing BGP techniques, such as
route reflectors, can be used to scale route
distribution. In this case, edge routers will
peer with route reflectors that serve the same
set of VPNs, so that individual edge routers
need not store all VPN information.
Security
MPLS-based VPNs provide a level of secu-
rity that is similar to that provided by L2
ATM or frame-relay networks. Because the
entire label-switched path of the packet is
pre-determined at the ingress point, cus-
tomers are assured that traffic injected into
an MPLS tunnel will not diverge from that
tunnel. The packet itself will not diverge
from the provider’s backbone; therefore, as-
suming appropriate security procedures by
the service provider, exposure is limited to
service provider staff. The label-swapping
nature of MPLS makes it impossible for a
third party to inject a packet into an MPLS
tunnel.
At the edge of a service provider network,
customer packets must enter through the
correct logical or physical interface. Packets
entering through an interface for which
Ericsson Review No. 3, 2000
there is no associated VRF are dropped. Fi-
nally, service providers assign a route dis-
tinguisher (RD) to each customer. These are
unknown to end-users, which makes it im-
possible for malefactors to enter the network
via another port.
VPN traffic remains separate at the back-
bone. Inter-VPN communication can be
tightly controlled in many ways, including
via route filters, firewalls, access lists, or au-
thentication servers.
In IP-overlay VPNs that employ L2TP
tunneling, an unauthorized third-party
might feasibly insert a packet into the IP
tunnel, forging a packet using the appro-
priate IPSA and IPDA addresses and prop-
er encapsulation. Consequently, when the
egress edge router receives the packet, it
processes the packet as if it had originated
at the ingress edge router. To prevent in-
trusion, packets destined for the L2TP tun-
nels are authenticated using an IPsec au-
thentication header (IPsec-AH).
DiffServ, MPLS and CoS
Due to the high processing and manage-
ment costs in carrier networks, it is not pos-
sible to scale
• quality of service when applied on a flow-
by-flow basis; or
• point-to-point virtual circuits when used
to implement class of service (CoS).
However, traffic that is placed into man-
ageable sets of service classes is more effi-
Figure 9
cient and scales well. In Ericsson’s VPN so- Ericsson AXI 540.
lutions, the QoS implementation is essen-
tially based on the DiffServ mechanisms
(RFC 2474 and RFC 2475). Where the
backbone is based on MPLS transport, Diff-
Serv is also applied in the edge in conjunc-
tion with MPLS trunking in the core. • network control intended for routing pro-
Traffic sent from the CPE must be classi- tocol signaling;
fied in accordance with the service commit- • best-effort service;
ted to the customer and might be subject to • assured service based on a subset of the as-
metering, policing, and shaping before it is sured forwarding PHB group; one for-
queued or scheduled for transmission by the warding class with two drop classes—a
edge router. token-bucket-style traffic-conditioning
Traffic in violation of the negotiated rate function at the network ingress handles
is either dropped or re-marked to ensure that policing and marks traffic according to
the appropriate level of service is provided. parameters (bandwidth per drop class) in
Several service classes are supported in the the sevice level specification (SLS);
core. The core of the network enforces the • strict QoS based on expedited forwarding
service classes based on the EXP value in the PHB. The ingress traffic-conditioning
MPLS header, MPLS label, or both. Each function is defined for the PHB; the band-
service category corresponds to an ordered width policing function is defined in the
traffic aggregate (OA) and a per-hop behav- SLS. For this service category, VC-style
ior (PHB) group that defines the forward- QoS is suitable, since admission can be
ing behavior. Ericsson’s current network so- controlled in each node during path sig-
lutions define four service categories: naling.

Ericsson Review No. 3, 2000 189


Customer care and billing (CCB) system
Network
Policy
Internet
Service
from the shortest path selected by the IGP
resource
deploym.
network
level
and onto potentially less congested physical
manager
manager
manager
manager
(NRM) (PDM) (INM) (SLM)
Management platform
icy and administrative constraints instead of
(Comms, discovery, topology,
management, etc)
Router
Router
Figure 10
Router
A high-level view of the Ericsson VPN
management system.
Core routers provide separate queues for
each service category. Traffic is scheduled
and buffered or queued according to service
categories and traffic mix. The AXI 520 and
AXI 540 employ the weighted round-robin
scheduling discipline. On some interface
types, the AXI 540 can also manage sched-
uling using a combination of fair round-robin
and priority scheduling (for EF PHB).
The AXD 301 can separate and isolate
DiffServ/MPLS and native ATM traffic as
defined in the MPLS ships-in-the-night
concept. Besides the ATM service cate-
gories, additional categories (output
queues) are provided for MPLS/DiffServ
traffic. By default, network control and as-
sured service traffic are mapped to separate
dedicated queues, while best-effort traffic is
handled together with unspecified bit rate
(UBR) traffic; strict QoS service is handled
as constant bit rate (CBR) or real-time vari-
able bit rate (rt-VBR).
In IP-overlay VPNs, the appropriate
DSCP field is marked in the outer IP pack-
et header (encapsulating the UDP/L2TP
packet) to ensure that the appropriate ser-
vice is provided within the core.
Traffic engineering and MPLS
If the core network is based on MPLS, traf-
fic engineering (TE) mechanisms can be
190
used to set up explicit paths to interconnect
edge router routers, in order to optimize net-
work performance and to facilitate more ef-
ficient and reliable management of network
resources. Traffic engineering enables ser-
vice operators to move traffic flows away
paths across the network. Explicit paths can
be set up based on the QoS/bandwidth, pol-
IGP topology alone.
Ericsson’s traffic engineering solutions
enable operators to establish label-switched
paths either manually or automatically. To
configure an LSP manually, the paths are
calculated off-line and all label switch
routers are manually pre-configured to in-
stall the forwarding state in routers. The
paths can also be computed online and es-
tablished semi-dynamically whereby only
the edge LSR is pre-configured, and from
there a signaling protocol (resource reserva-
tion protocol/contraint-based LDP,
RSVP/CRLDP) is used to install the
forwarding state in each LSR. The ad-
mission control procedures defined by
RSVP/CRLDP check the availability of re-
sources when the path is established.
Extranets
The MPLS VPN architecture does not make
any distinction between intranets and ex-
tranets. Certain sites within a VPN can be
allowed to communicate directly, whereas
others might have restricted connectivity or
might have to pass through a firewall before
communicating with other sites. Connec-
tivity between VPN sites is a matter of pol-
icy. While some sites might only be mem-
bers of an intranet VPN, others might be
members of the intranet and an extranet.
The MPLS VPN architecture accommodates
complex VPN topologies provided the ex-
tended attributes of BGP have been config-
ured properly.
Management and service provisioning
Although not the main focus of this article,
the following section briefly describes the
management components and procedure for
deploying VPNs. Ericsson’s IP manage-
ment architecture was described in greater
detail in Ericsson Review no. 1, 2000.
Management components
The Ericsson VPN management system
consists of the following components (Fig-
ure 10):
Ericsson Review No. 3, 2000
• The customer care and billing system
(CCB) contains a billing system and fa-
cilitates the definition of customers and
the provisioning of new customer services.
A service-level specification (SLS), which
is also part of the CCB, includes the sites
of a VPN, requested bandwidth and QoS,
VPN topology, activation/deactivation
time, and so on.
• The policy deployment manager (PDM)
receives high-level service requirements
from the CCB and maps them to appro-
priate configuration (CLI) commands that
are necessary to configure a VPN. The
PDM configures the VPN elements (vir-
tual routers, stub links, route targets,
route distinguishers) that are affected by
the addition or subtraction of a customer
site. Based on the service-level specifica-
tion from the CCB, the PDM is also re-
sponsible for configuring QoS-related el-
ements, such as access lists, and packet-
classification rules and actions for each
customer site.
• The network resource manager (NRM)
takes steps that are necessary for deploy-
ing a VPN. This includes the configura-
tion of MPLS tunnels between PEs, iBGP
sessions, queues, schedulers/drop levels in
routers, and so on.
• The service level manager (SLM) collects
network events and alarms. It can corre-
late network events and automatically fil-
ters out unimportant alarms. It also in-
forms the CCB of events that violate the
SLA.
• The IP network-performance monitor
(INM) measures network performance. For
example, it measures one-way delay, tests
connectivity, and monitors thresholds.
Deploying VPN service
1.The underlying network must be config-
ured before the VPN sites can be config-
ured. This also applies to the configura-
tion of BGP, iBGP sessions, MPLS tun-
nels, and QoS components (schedulers, in-
terfaces, drop levels).
2.A high-level CCB system provides the in-
Ericsson Review No. 3, 2000
terface to customer service representa-
tives. A service-level agreement is nego-
tiated—this agreement specifies VPN
sites, connectivity, QoS, time frame, and
so on. The information in this agreement
is then passed on to the policy deployment
manager.
3. The policy deployment manager receives
high-level information from the CCB and
determines the physical configuration to
be applied to the network.
4.Once a customer site is configured (in-
cluding virtual router instances, route tar-
get, route distinguisher, packet classifi-
cation rules and corresponding actions),
information pertaining to the newly cre-
ated VPN is passed to the INM. This ini-
tiates performance monitoring in the net-
work and guarantees conformance with
the SLA.
5.If events or alarms occur in the network—
for example, faults or performance-
related events from the INM—the SLM
informs the CCB of correlated events that
lead to SLA violations.
Conclusion
Network-based IP-VPNs give business cus-
tomers the same services and benefits as they
enjoy with their current networks, but use
shared public infrastructure instead of pri-
vate equipment, and external service
providers instead of expensive in-house spe-
cialists.
Ericsson’s MPLS VPN solution is scalable
and simple to deploy. It can seamlessly in-
tegrate customer routers into the service
provider’s backbone, thereby reducing the
cost of deploying and operating VPN ser-
vice. The implementation does not require
any changes or additional functions on the
customer’s intranet. At the same time, the
service provider’s backbone can be used in a
reliable and cost-effective way as a platform
for providing profitable value-added ser-
vices, such as telephony, centralized Web
hosting, multicast, e-commerce, and secu-
rity services for extranets.
191