2000036

8/7/2019 2000036

1/14

VPN services andarchitecturesVPN services

A virtual private network (VPN) consists ofa set of geographically disparate sites that

can communicate securely over a public orshared infrastructure. IP-based VPNs (IP-VPN) enable business customers seamless-ly to receive the same security, connectivi-

ty and reliability as from any other privatenetwork, and can be used to offer the fol-lowing services: intranetconnectivity between corpo-

rate sites; dial-in accessbusiness employees can

access the corporate network remotely; extranetsecure connectivity between a

community of users or business partnerswhose access is restricted to the resourcesdefined for that community; and

Internet access.VPNs can be built in various ways. Someconsist of routers and firewalls that are inter-connected to the physical or logical leasedline of carriers and service providers. Othersmight include a combination of applicationproxy firewall, encryption, intrusion detec-tion, tunneling, and key management. SomeVPNs are managed in-house, while othersare outsourced to a service provider.Whether the VPN constitutes remote-access service to an intranet or extranet, aservice provider must somehow integratethe VPN services into a common infra-structure.

VPN architectures

Remote access

Remote-access VPNs give end-users accessto a corporate intranet or extranet over ashared public infrastructure. Ordinarily, aVPN subscriber or a server in a remote of-fice dials into a network access server (NAS)at the service providers point of presence(PoP). After authentication, which is basedon the pre-configured user profile, a tunnelis dynamically established to the tunnelserver on the customer premises (Figure 1).A tunnel can be client-initiated (voluntary)in which

case the tunnel is opened by the client andterminated by the corporation withoutany active involvement by the serviceprovider; or

compulsoryin which case the tunnel iscreated by the service providers networkaccess server and terminated either by aservice provider tunnel server or by a cen-tral customer site server.

The security policy database can reside onthe company premises or it can be out-

sourced to the service provider.A remote-access VPN allows users to take

advantage of low-cost Internet-access ser-vices (as opposed to being assessed distance-sensitive bandwidth charges). Althoughmost remote-access services are currently

178 Ericsson Review No. 3, 2000

Ericssons network-based IP-VPN solutions

Nail Kavak

The phenomenal success of the Internet and the universal adoption of the Internet proto-col are driving profound changes in the telecommunications industry. The infrastructureof the Internet is being used as the foundation for a new public IP network. In addition toexisting best-effort applications, the emerging IP networks will offer the functionality need-ed to support a variety of carrier-class and business-quality services, with the advantage ofbeing ubiquitous, easier to access, and of costing less than competing alternatives.

Many service providers are expanding the capacity and geographical coverage of their net-works to meet rising customer demand. With virtual private networks, they can improveasset utilization and return on investments by leasing available capacity and providing newservices. IP-based virtual private networks provide a means of extending the reach and scal-ability of legacy frame-relay and ATM networks. End-users gain ubiquitous access to thecorporate intranet or extranet for business-to-business applications, IP telephony, or multi-cast videoconferencing service. Ultimately, Internet VPNs will be the global means of busi-ness communication just as the voice network is today.

The author describes various virtual private network models and the details of EricssonsMPLS-based IP-VPN offering.

ISDNxDSL

Dial in LAC(NAS)

L2TP

ISP network

CPE

CPE

CPE

LNS

Enterprise 1

Tunnelend points

Enterprise 3

Enterprise 2

LNS

LNS

PoP

PE

PE

PE

PE

P

P

P

Telecommuters

Figure 1Remote access scenario.

8/7/2019 2000036

2/14

Ericsson Review No. 3, 2000 179

based on dial-in services, other access meth-odsincluding cable modems, xDSL, anddirect Internet accessare becoming in-creasingly popular.

CPE-based L2 overlay

The traditional way of building a VPN is touse layer 2 (L2) overlay based on customerpremises equipment (CPE). L2 connectivi-ty is provided between customer sites thatuse asynchronous transfer mode (ATM) orframe-relay via virtual circuits. In essence,the provider furnishes a set of permanent vir-tual circuits (PVC) between customersitesusually in full or partial mesh, butsometimes also in hub-and-spoke configu-rations (Figure 2). The PVCs are treated asdumb pipes, since they are not involvedin routing, packet filtering, or other layer 3(L3) issues. An L3 overlay network is builton top of the L2 network by running IP overvirtual interfaces between data link circuitindentifiers (DLCI) or virtual circuits thatare connected to the CPE. The serviceprovider is usually responsible for configur-ing and managing VPN connectivity.

The L2 VPNs described above can also beused in combination with multiprotocollabel switching (MPLS). To the end-user,MPLS-based L2 VPNs are identical to tra-ditional L2 VPNs. In reality, however, theL2 circuits (ATM virtual circuits) initiatedat the customers site are terminated at theingress of the service providers domain andmapped to MPLS tunnels in the backbone.This way, the service provider can offer mul-tiple services, such as public IP, private IP,and voice over IP (VoIP), over a single ac-cess circuit.

CPE-based L3 overlay

The VPN sites are interconnected via a meshof IP-over-IP (IPIP) tunnels that are estab-lished across the public network using anykind of L2 technology (ATM, FR, PPP). InCPE-based VPNs, all complex functionali-ty and all hardware needed to construct theVPN reside on the customer premises. Theservice provider merely provides access tothe public network (without having to knowanything about the topology of the VPN).A VPN gateway is placed at each customersite between the enterprise and the service

provider. Practically any tunneling tech-nique can be used between VPN sites, in-cluding the layer 2 forwarding protocol (L2FP); point-to-point tunneling protocol

(PPTP);

CPE Router

CPE Router

CPE Router

CPE Router

CPERouter

CPERouter

CPERouter

CPERouter

Figure 2Layer 2 overlay VPN scenario.

ATM Asynchronous transfer mode

BA Behavior aggregateBGP Border gateway protocolCBR Constant bit rateCCB Customer care and bil ling system

CIR Committed information rateCoS Class of serviceCPE Customer premises equipmentDiffServ Differentiated serviceDLCI Data l ink circuit identifier

DSCP Differentiated services code point

DSL Digital subscriber lineE-BGP Exterior border gateway protocolEXP ExperimentalFEC Forwarding equivalence class

FR Frame relayGRE Generic encapsulation protocoliBGP Internal BGPIGP Internet gateway protocol

INM IP network performance monitorIPDA IP destinat ion addressIPSA IP source addressIPsec IP security protocolISIS Intermediate system-to-intermediate

systemISP Internet service providerL2FP Layer 2 forwarding protocolL2TP Layer 2 tunneling protocol

LAN Local area networkLER Label edge routerLL Leased lineLNS Local network serverLPM Longest prefix match

LSP Label-switched path

LSR Label switch router

MF Multi-field classificationMPLS Multi-protocol label switchingNAS Network access serverNAT Network address translationOSPF Open shortest path first

P Core routerPDA Personal digital assistantPDM Policy deployment managerPE Provider edge router

PHB Per-hop behavior

PoP Point of presencePOS Packet over SONETPOTS Plain old telephone servicePPTP Point-to-point tunneling protocol

PVC Permanent v irtual circuitQoS Quality of serviceRD Route distinguisherRFC Request for comments

RIP Routing information protocolRT Route targetrt-VBR Real-time VBRSA Scheduling aggregateSLA Service-level agreement

SLS Service-level specificationSONET Synchronous optical networkSP Service providerTE Traffic engineering

UBR Unspecified bit rateVC Virtual circuitVoIP Voice over IP VPN Virtual private networkVR Virtual router

VRI Virtual router interface

BOX A, ABBREVIATIONS

8/7/2019 2000036

3/14

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 dataencryption. It also facilitates confiden-tiality, authenticity, integrity and keymanagement.

The end-user organization can choose tomanage 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 servicesof skilled, highly sought-after staff. On theother hand, the management of outsourcedVPNs is a big business opportunity for ser-vice providers, in particular because they canamortize the cost over several customers.They can provide basic Internet access withbest-effort services or they can offer multi-ple class-of-service (CoS) and bandwidthguarantees, 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 providers edge router

via physical or virtual linksthrough anATM or frame-relay access network. Theservice providers backbone routers, whichcarry the VPN traffic, are interconnected viaMPLS label-switched paths (LSP) or tun-nels. MPLS is used for forwarding packets,while the border gateway protocol (BGP) isused to distribute routes and VPN mem-bership information. All complex function-ality and all hardware needed to build theVPN reside on the service providers do-main. Network-based MPLS VPNs do notput any requirements on VPN customers,which means customers can use their ownrouters or an off-the-shelf router to connectto the service providers network.

Network-based L3 VPNs

Network-based L3 VPNs are similar tonetwork-based MPLS VPNsthat is, allVPN functionality, management, and hard-ware resides on the service providers do-main. However, instead of using MPLS tun-nels to connect to the ingress and egress ofthe providers edge routers, the network-based L3 VPN uses IP tunneling mecha-

nisms, such as IPIP, GRE, and the L2 tun-neling protocol (L2TP). This architecturerelaxes requirements for a fully native MPLS


TelecommutersCentral site

Mobile network

ISDN access Management center Remote access

PSTN

Frame relaynetwork

BSC

BSC

SGSN

GGSN

Router

Router

Router

Router

AXI 540

AXI 540

AXI 540

AXI520/AXD 301

AXI 520/AXD 301

AXI520/AXD 301

Figure 3Architectural overview of Ericssons VPNbackbone.

8/7/2019 2000036

4/14


backbone, and in cases of inter-provider op-eration, it also relaxes the requirements tosupport inter-provider MPLS.

Why network-basedVPNs?End-user organizations can reap significantadvantages from outsourcing the operationand management of their virtual private net-works to service providers. Service providershave solid network-management expertise.They also have better resources and exper-tise to provide cost-effective, carrier-class re-liability, capacity, scalability, and globalreach. Moreover, service providers can offerthe 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, ATMor frame-relay switcheswhich is to saythat service provider investments in back-bone equipment are protected. At the sametime, corporate customers need not investin special VPN hardware or softwareanyoff-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 thanconventional VPN techniques (frame relay,ATM, leased lines, and so on), since the edgenodes 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 bydeploying CPE-based equipment does notnecessarily outweigh the costs of deployingand managing the equipment.

The MPLS network can differentiate be-tween services according to application typeand VPN membership. It can also providequality of service and privacy for deliveringvalue-added and closed user group servicesover existing infrastructures. Furthermore,it enables the service provider to utilizebackbone resources more efficiently thanksto the advanced traffic-engineering mecha-nisms that are an integral part of MPLS.

Ericssons MPLS VPN

Ericssons MPLS VPN solutions, which spanL2- 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-

lows, we will more closely examineEricssons support for IP-VPNs deployedover L3 infrastructures with either packet-over-SONET (POS) or ATM cores.

Ericssons VPN architecture makes use ofedge components such as the AXI 510 andAXI 512 access routers and the AXI 540edge aggregation router, as well as core com-ponents such as the AXD 301 ATM switchand the AXI 520 core router. Figure 3 givesan overview of the available network com-ponents.

VPN Requirements

Ericssons 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, globalInternet access, inter-VPN connectivity andpolicy, 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 whooffer a turnkey service want to minimize themanagement complexity and availabilityconcerns associated with managed CPE ser-vices. Customers who manage their ownCPE typically want to minimize the re-quirements put on internal technical staff.Another requirement is that typical CPErouters should be able to participate in theVPN without a software upgrade. EricssonsIP-VPN solutions, which make use of stan-dard customer CPE (routers), do not requirespecial configurations or features, exceptwhere service differentiation is required be-tween customer equipment and the serviceproviders network. When this is the case,the CPE must be configured to perform alldifferentiated service-related (DiffServ)edge functions, including classification,marking, shaping, and scheduling. Cus-tomers can enhance the security of the basicVPN 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 mustimplement a centralized network address

translation (NAT) function within theirVPN.

Private addressing

The service provider must be able to sup-port a customers use of addresses that are

8/7/2019 2000036

5/14

not globally unique (for example, the localaddresses defined in RFC 1918, or address-es that rightfully belong to another organi-zation). Addresses are solely guaranteedunique 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 apacket is traveling. The Ericsson IP-VPNsolutions support multiple instances ofoverlapping address space without requir-ing network address translation. The NATfunction is only required when two businesscustomers with overlapping address spacecommunicate with each other or when abusiness customer who uses private ad-dresses wants to access the global Internet.

Security

IP-VPNs replace private backbones withthe shared backbone of a public networkprovider. Consequently, VPN customersmight 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 enterthe VPN (possibly masquerading as a legit-imate VPN host). Security violations couldresult in the exposure or corruption of sen-sitive corporate data, unauthorized access tocomputing resources, and denial of service

or electronic vandalism. While the utmostsecurity is obtained by implementing IPsecor like technologies within the CPE, cus-tomers who use IP-VPNs in place of framerelay or ATM L2 VPN services obtain ade-quate security via L2 (MPLS or ATM) or L3

tunneling within the service provider net-work. In this caseprovided it is possibleto limit the topology with which the data isexposed when under the administrative con-trol of a single service providerthe ad-

vantages of operational simplicity outweighthe security risks of breached confidentiali-ty. That is, topology control enhances dataconfidentialitythe routing-decision pro-cesses that include VPN constraints areleveraged as part of the packet-forwardingdecision process.

QoS/SLA

Customers who build private leased-linenetworks can be guaranteed specific band-width on each link. Similarly, customerswho share public networks, such as framerelay or ATM, receive service provider guar-antees of bandwidth through, for example,committed information rates (CIR). Obvi-ously, customers who migrate to a shared IPnetwork must also be given the same kindof assurances.

QoS models

Ericssons VPN solution can be based eitheron apipe or hose QoS model. The pipe modelis analogous to conventional leased-lineVPNs 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 notnecessarily know the traffic matrix. Instead,


CPE CPE

CPE CPE

PE

PE

PE

PE

Figure 4Pipe model: Specified distribution of traf-fic between each site.

8/7/2019 2000036

6/14


to simplify the customers task of specifyingthe performance requirements of the VPN,performance characteristics are defined sole-ly for traffic entering into a hose stub linkor exiting a hose to any other hose

(Figure 5). Apart from being very straight-forward, this model allows customers tovary, without changing their contract, thevolume of traffic that is sent to any otherhose endpoint, provided that the aggregatetraffic entering and exiting each of the end-points does not exceed the capacity of eachhose.

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 connectivitymodels for controlling QoS in IP-VPNs: Differentiated serviceseither the Diff-

Serv code point (DSCP) in the packet (forpre-encapsulated packets, the router usesthe DSCP value in the clear-text header)or the MPLS label+CoS is used to map thepacket to the behavior aggregate (and cor-responding per-hop behavior) with strict-ly configured scheduling parameters.

Virtual circuit (VC)traffic parametersand a QoS service class (delay andthroughput sensitivity) are assigned to alabel-switched path or ATM VC with dy-namic per-hop admission control, pre-emption priority, and so on. Like the Diff-

Serv connectivity model, the virtual cir-cuit connectivity model supports only afew forwarding classes in the network.Different LSPs that belong to the sameforwarding class are mapped to the same

buffer or queue. Distinct admission con-trol policies and traffic conditioningapply to each forwarding class.

To properly enforce service differentiation,Ericsson products employ technologies thatidentify, regulate, and isolate traffic. Identification is accomplished by means

of packet classificationthat is, bymatching the components of a packetheader against a list of filters. In some cir-cumstances, such as when a customer hasstringent security requirements or wantsto differentiate service to the stub link,the classification must be performed at thecustomer site.

Regulation is accomplished by traffic con-ditioningthat is, by shaping, dropping,or re-marking packets based on the tem-poral characteristics of the associatedpacket stream (identified by a classifier)relative to the traffic profile of the SLA.

Isolation is achieved by using severalqueuing or policy-based routing mecha-nisms that provide dedicated router for-warding resources (buffers, output linkbandwidth) or special network paths thatisolate enhanced-service traffic from con-

gestion that has been induced by tradi-tional best-effort traffic.

Scalability

Obviously, service providers want to knowwhat impact VPN services will have on

CPE CPE

CPE CPE

PE

PE

PE

PEService provider network

Figure 5Hose model: Performance characteristicsspecified for traffic from customer site tothe network.

8/7/2019 2000036

7/14

backbone resources. Concerns include thescalability of routing protocols, stub linkdensity (with physical or logical interfaces),and the per-packet processing required toforward VPN traffic. Ericssons IP-VPN so-lutions support techniques for increasingscalability in carrier backbones.

Mobile and remote access

Besides fixed-site access, end-users shouldbe able to access the VPN over plain oldtelephone service (POTS) dial-up, digitalsubscriber line (DSL), cable modem, andeventually, from truly mobile devices suchas personal digital assistants (PDA). Sinceaccess is not necessarily tied to a physicallocation, security is a major concernforinstance, access might originate from an-other providers network, such as a localdial-up Internet service provider (ISP) whooperates in a wholesale scenario. Moreover,because the CPE can be a laptop, cell phone,or PDA, the CPE functionality must besimple and ubiquitous. Ericssons IP-VPNsolutions support multiple tunnelingmechanisms (MPLS and L2TP) that permit

users who are connected via a fixed-site localarea network (LAN) or traditional dial-up,DSL, and so on, to participate in the sameIP-VPN.

Global Internet access

Customers might want to access the globalInternet and the VPN from the same serviceprovider connection. Ericssons IP-VPN so-lutions support customer networks withglobally unique addresses. If parts of theVPN use non-unique addressing that con-flicts with globally assigned addresses, theVPN addresses take precedence over theirglobal counterparts.

Inter-VPN connectivity and policy

Some customers require more than one VPNfor inter-site communications. Some sitesmight 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 theVPNs simultaneously, and access must betightly controlled (an industry-wide ex-tranet might include competitors whoshould not be granted access to the corpo-rate Intranet or who have access to only a

subset of resources). One VPN might alsofunction as a transit VPN which passes traf-fic that originates at a second VPN and isdestined for a third VPN. When multipleVPNs connect, their addresses must beunique.

Inter-provider operation

Some customers want separate providers tomaintain distinct parts of their VPN. Forthese customers, the IP-VPN solution mustspan multiple provider networks and ensurethat all VPN forwarding, route propagationand QoS/SLAs function across providerboundaries. Initially, these inter-providerVPNs will only be encountered where theprimary service provider cannot offer fullcoverage for all customer sites or for all cus-tomer access technologies. Inter-provideroperation stipulates that the VPN modelsused must have minimum impact onprovider core networks, and that they sup-port standards-based operation.

Manageability

Making the configuration of equipment in

the service providers network less complexwill have a good effect on scalability, oper-ational functionality and operating costs. Inparticular, this applies to the configurationof provider edge (PE) routers that imple-ment key parts of the IP-VPN service.

Interoperability

Ericssons IP-VPN solutions are designed tooperate within multi-vendor networks. Tominimize the impact on interoperation withdifferent core devices (some of which maynot support native MPLS), the solutionssupport 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 ofmulti-vendor PE solutions. Ericsson be-lieves that compliance with appropriaterequests for comments (RFC) on MPLS VPNsand dedicated interoperability testing willyield implementations which are interoper-able with other PEs that adhere to the MPLSVPN RFC. There is no current standard fornon-MPLS VPNs (called IP overlay VPNs);however, given the obvious benefit of sup-porting multiple tunneling technologies, it

is believed that the industrys standard fo-rums can be induced to generate support forthem. Ericsson will consider acceleratingsupport for non-L2 tunneling mechanismsif doing so accelerates interoperability withthird-party equipment.


8/7/2019 2000036

8/14


Ericsson IP-VPNarchitectureThe section that follows describes the inter-network part of Ericssons 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 providers core routers (P) and edgerouters (PE) as illustrated in Figure 6. Theedge routers (AXI 510, AXI 512 or AXI540) 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, openshortest path first, EBGP) to communi-cate reachability information between thecustomer and service provider; or

statically configured with site reachabili-ty information for the stub link.

Each edge router maintains separate for-warding tablesevery site to which theedge router is attached is mapped to one of

these tables, which are used to determinehow a packet is to be routed. The core routers(P) are unaware of the existence of VPNs atthe networks edge boundaries. Two basicarchitectures are supported: MPLS-VPNsand IP-overlay VPNs.

MPLS-VPNs

The CPE sends standard IP packets to theingress edge router, which routes the pack-ets across MPLS tunnels to the egress edgerouter. The core network (between theingress and egress edge router) is composedof several routers or switches (P) that func-tion as standard label switch routers. Thebackbone that connects the ingress andegress edge routers is fully compliant withnative MPLS.

A two-layer label stack is used across thebackbone: the top layer identifies a singleLSP connecting the ingress and egress edgerouter, whereas the bottom layer, which de-notes the CPE destination, is consideredonly by the egress edge router. Since therouters (P) are only concerned with the toplabel, they only need to know the internaltopology of the backbone that connects theedge routerthat is, they do not require in-formation on customer connections orVPNs. The MPLS solution uses multi-protocol extensions to BGP to communicateVPN-specific routing information betweenedge routers. The edge routers are fully

meshed and communicate through iBGPsessions.

IP-overlay VPNs

The IP-overlay model is similar to the MPLSmodel, but instead of using MPLS tunnels

PE

VR

VPN B2VPN B1

VPN A2

VPN A1

VPN A3

Internet

MPLS backbone

VR

VR

Global

VR

VR

VR

Global

VR

VR

VR

Global

P P

P P

PE

CPE

CPE

CPE

CPE

CPE

PE

Figure 6MPLS-BGP/VPN architecture and compo-nents.

8/7/2019 2000036

9/14

to connect ingress and egress edge routers,the service provider employs IP tunnelingmechanisms. Initially, the IP-overlay modelsupports L2TP tunneling, since this mech-anism facilitates the multiplexing of VPNtraffic onto a single tunnel, thereby allevi-ating scalability concerns. The use of L2TPallows IP-VPNs to be deployed on back-bones that do not fully support nativeMPLS. 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 stublink that terminates at the edge router. Traf-fic on the stub links can be transmitted inthe clear (assuming the customer site in-cludes minimal CPE services) or it can betunneled or encrypted. Tunneling is usedacross the service providers backbone tosupport security, topology control, and cus-tomer-addressing limitations. A combina-tion of DiffServ, ATM QoS, and MPLS+CoSis used to guarantee quality of service.

VPN customers with dial-up and broad-

band access connect to the network eithervia CPE servicesWindows PC supportingpoint-to-point tunneling protocol (PPTP)or IPsec over L2TPor via AXI 510 orAXI 512 access servers at the edge of the ser-vice providers network (in which case the

tunnels originate on the access server). Thetunnels can be terminated at an entry pointof the VPN within the service providersnetwork or they can be terminated at thecustomer premises.

Basic forwarding path operation

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 hasbeen configured for the virtual interface onwhich the packet arrives, the edge routerperforms standard longest prefix match(LPM) lookup on the packets IPDA in aVRI-specific forwarding table. The for-warding table contains all reachable prefix-es that reside in any of the VPNs of whichthe 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 nomatching prefix is found, the edge routermight look up the LPM in a global for-warding table, which consists of global In-ternet prefixesthe 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 amatch, the packet is dropped and an ICMPunreachable message is generated(Figure 7). If a match is returned from theVRI-specific table, the packet is encapsu-lated in a two-layer MPLS label stack (for MPLS

VPNs) and forwarded along the LSP thatconnects the ingress edge router with theegress edge router; or

L2TP headers (for IP-overlay VPNs) andsent to the egress edge router over an IPtunnela single L2TP tunnel that con-nects a pair of ingress and egress edgerouters is used to multiplex traffic frommany VRI contexts (using the tunnel IDfield and a session ID field to identify theVRI context).

Core devices are unaware of the existence andconfiguration of VPNs (and associated per-customer topology information) within thePEs. Where the ingress edge router is at-tached to a two-layer MPLS label stack oneach 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 connectsthe ingress edge router to the egress edgerouter, the router (P) only needs topology in-formation on the ISP backbone. This infor-mation is usually obtained via an Internetgateway protocol (IGP), such as OSPF or in-


VR

VR

VR

Internet

Do lookup in VPN table Determine path to egress router Encapsulate in two-layer deep MPLS stack

Bind the label to

corresponding VR

Label swappingbased on top level

Figure 7VPN forwarding plane in action.

8/7/2019 2000036

10/14


termediate system-to-intermediate system(ISIS). The backbone-forwarding path is alsocompletely protocol-independent. Thus,any protocol that can be encapsulated inMPLS can be forwarded between edgerouters.

In IP-overlay VPNs, most packets thattraverse the core are IP packets with theIPSA and IPDA set to addresses that belongto the ingress and egress edge routers. Therouters (P) must be able to route to addressesthat belong to edge routers, but requireno information on VPNs or customertopology.

The egress edge router, which acts as anMPLS label edge router (LER), uses the sec-ond label in the stack to forward the pack-et to the appropriate egress interface for thedestination CPE. The second label encodesthe VRI scope of the packet and the nexthop, and provides the information that isneeded 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 theappropriate tunneling or VLAN tagging

mechanism to denote the VRI scope of thepacket). The second label, which is assignedby the egress edge router, is propagated viathe routing protocols (multiprotocol-BGP,MP-BGP). This label, whose scope solely

applies to the egress edge router that assignsit, is opaque to other routers. In IP-overlayVPNs, packets received by the egress edgerouter from the upstream routers (P) arriveover an IP tunnel for which the edge routerserves as a termination point. The edgerouter uses the IPSA, IPDA, and IP proto-col field to identify the tunnel, and then usesthe L2TP tunnel ID and session ID to iden-tify the CPE router to which the packet isto be forwarded.

Routing and processing route updates

In VPN environments, the ISP backboneserves as the core of an enterprise network.The service provider is therefore responsiblefor propagating reachability informationbetween each customer site, while preserv-ing the VRI-specific context of prefixes, andcreating customized forwarding tables foreach distinct VRI.

Ericssons IP-VPN solutions support theexchange of routing information with CPEdevices 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 methodsof communicating routing information.Since the edge router is configured to con-tain the VPN membership of each sub-

VR

VR VR

VR

VR

Internet

EBGP, IGP

(Static)

iBGP/MP

Import from BGP

Translate VPN-unique address to

IPv4

Distribute to CE

Import from BGP

Translate VPN-unique

address to IPv4

Distribute to CE

Translate IPv4 to VPN-unique address

Send MP-iBGP update to all

Figure 8VPN control plane in action.

8/7/2019 2000036

11/14

interface, routes learned via a sub-interfacecan be associated with the appropriate VRIwithout requiring any special protocol sup-port on the CPE. There is no one-to-one re-lationship between a customer site andVPN, since customers can be members ofmultiple VPNs. The edge router insertsroutes obtained from a CPE into the appro-priate VRI table, and then announces theseprefixes to other edge routers on the back-bone using multiprotocol extensions toBGP that allow each prefix to be qualifiedwith its VRI context. Similarly, each edgerouter obtains VRI-specific reachability in-formation via the internal BGP (iBGP) withother edge routers, and propagates these pre-fixes to the CPE using standard IGP or EGPprotocols (Figure 8). An isolated instance ofthe IGP is used with each customer site toensure that routing domains are maintainedas distinct.

Prefixes are obtained from customers whouse conventional protocols (or static routinginformation), but when non-unique prefix-es are propagated across the providers back-bone, they must be qualified with the VRI

context to which they belong. StandardBGP4 can announce only one unique in-stance of a prefix over a BGP session, andBGP NEXT_HOP information is inher-ently an IPv4 address. MP-BGP makes itpossible to announce a VPN-IPv4 prefix,which is a standard IPv4 prefix qualifiedwith a 64-bit route distinguisher that com-municates the VRI-specific context of thatprefix. When an edge router originates aroute into iBGP, either via a static an-nouncement or by means of redistributionfrom interior gateway protocol/externalgateway protocol (IGP/EGP) with a CPE, itincludes BGP NEXT_HOP, which pointsto one of its own addresses and an MPLSlabel. This label is essential to the edgerouter. In traffic received from from thebackbone and destined to this prefix, theMPLS labelthe second in the labelstackis used to forward the packet to theappropriate CPE (Figure 4). In IP-overlayVPNs, the egress edge router attaches anidentifier (L2TP tunnel and session IDs) tothe MP-BGP announcement of the route.

All VPN prefixes carried via MP-BGPacross the backbone are qualified with the

VPN in which they originated. These BGProutes must only be announced (via an IGPor EGP) to customers who are members ofthe VPN from which the route originated.A new BGP attribute, target VPN (effec-tively a 64-bit extended communities at-

tribute), denotes the list of VPNs to whichthe route must be announced.

Scalability

In traditional connection-oriented networks(leased line, frame relay or ATM), circuitsare overlaid between each customer routerto provide VPN connectivity. For VPNsthat 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 areestablished from peer to peer based on theL3 topology. Thus, customer routers needonly peer to a single edge router, regardlessof the number of sites within a VPN.

In addition, MPLS tunnels can be sharedby different VPNs (VR). Thus, a rise in thenumber of customers or VPNs has no im-pact on the number of LSPs. L2TP tunnelscan also be multiplexed using the session ortunnel ID to reduce the number of tunnelsin the backbone.

In MPLS, the edge routers must only keepinformation on the VPN of directly attachedrouters. In addition, sites that share the same

routing information or sites that belong tothe same VPN can share the same VPN rout-ing table. Furthermore, thanks to labelstacking, the core routers (P) need not knowanything about VPNs.

To further reduce the burden on edgerouters, existing BGP techniques, such asroute reflectors, can be used to scale routedistribution. In this case, edge routers willpeer with route reflectors that serve the sameset of VPNs, so that individual edge routersneed not store all VPN information.

Security

MPLS-based VPNs provide a level of secu-rity that is similar to that provided by L2ATM or frame-relay networks. Because theentire label-switched path of the packet ispre-determined at the ingress point, cus-tomers are assured that traffic injected intoan MPLS tunnel will not diverge from thattunnel. The packet itself will not divergefrom the providers backbone; therefore, as-suming appropriate security procedures bythe service provider, exposure is limited toservice provider staff. The label-swappingnature of MPLS makes it impossible for a

third party to inject a packet into an MPLStunnel.

At the edge of a service provider network,customer packets must enter through thecorrect logical or physical interface. Packetsentering through an interface for which


8/7/2019 2000036

12/14


there is no associated VRF are dropped. Fi-nally, service providers assign a route dis-tinguisher (RD) to each customer. These areunknown to end-users, which makes it im-possible for malefactors to enter the networkvia another port.

VPN traffic remains separate at the back-bone. Inter-VPN communication can betightly controlled in many ways, includingvia route filters, firewalls, access lists, or au-thentication servers.

In IP-overlay VPNs that employ L2TPtunneling, an unauthorized third-partymight feasibly insert a packet into the IPtunnel, forging a packet using the appro-priate IPSA and IPDA addresses and prop-er encapsulation. Consequently, when theegress edge router receives the packet, itprocesses the packet as if it had originatedat 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-cient and scales well. In Ericssons VPN so-lutions, the QoS implementation is essen-tially based on the DiffServ mechanisms(RFC 2474 and RFC 2475). Where thebackbone is based on MPLS transport, Diff-Serv is also applied in the edge in conjunc-tion with MPLS trunking in the core.

Traffic sent from the CPE must be classi-fied in accordance with the service commit-ted to the customer and might be subject tometering, policing, and shaping before it isqueued or scheduled for transmission by theedge router.

Traffic in violation of the negotiated rateis either dropped or re-marked to ensure thatthe appropriate level of service is provided.

Several service classes are supported in thecore. The core of the network enforces theservice classes based on the EXP value in the

MPLS header, MPLS label, or both. Eachservice category corresponds to an orderedtraffic aggregate (OA) and a per-hop behav-ior (PHB) group that defines the forward-ing behavior. Ericssons current network so-lutions define four service categories:

network control intended for routing pro-tocol signaling;

best-effort service; assured service based on a subset of the as-

sured forwarding PHB group; one for-warding class with two drop classesatoken-bucket-style traffic-conditioningfunction at the network ingress handlespolicing and marks traffic according toparameters (bandwidth per drop class) inthe sevice level specification (SLS);

strict QoS based on expedited forwardingPHB. The ingress traffic-conditioning

function is defined for the PHB; the band-width policing function is defined in theSLS. For this service category, VC-styleQoS is suitable, since admission can becontrolled in each node during path sig-naling.

Figure 9Ericsson AXI 540.

8/7/2019 2000036

13/14

Core routers provide separate queues foreach service category. Traffic is scheduledand buffered or queued according to servicecategories and traffic mix. The AXI 520 andAXI 540 employ the weighted round-robinscheduling discipline. On some interfacetypes, the AXI 540 can also manage sched-uling using a combination offair round-robinandpriority scheduling (for EF PHB).

The AXD 301 can separate and isolateDiffServ/MPLS and native ATM traffic asdefined in the MPLS ships-in-the-nightconcept. Besides the ATM service cate-gories, additional categories (outputqueues) are provided for MPLS/DiffServtraffic. By default, network control and as-sured service traffic are mapped to separatededicated queues, while best-effort traffic ishandled together with unspecified bit rate(UBR) traffic; strict QoS service is handledas constant bit rate (CBR) or real-time vari-able bit rate (rt-VBR).

In IP-overlay VPNs, the appropriateDSCP 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

used to set up explicit paths to interconnectedge router routers, in order to optimize net-work performance and to facilitate more ef-ficient and reliable management of networkresources. Traffic engineering enables ser-vice operators to move traffic flows awayfrom the shortest path selected by the IGPand onto potentially less congested physicalpaths across the network. Explicit paths canbe set up based on the QoS/bandwidth, pol-icy and administrative constraints instead ofIGP topology alone.

Ericssons traffic engineering solutionsenable operators to establish label-switchedpaths either manually or automatically. Toconfigure an LSP manually, the paths arecalculated off-line and all label switchrouters are manually pre-configured to in-stall the forwarding state in routers. Thepaths can also be computed online and es-tablished semi-dynamically whereby onlythe edge LSR is pre-configured, and fromthere a signaling protocol (resource reserva-tion protocol/contraint-based LDP,RSVP/CRLDP) is used to install theforwarding state in each LSR. The ad-

mission control procedures defined byRSVP/CRLDP check the availability of re-sources when the path is established.

Extranets

The MPLS VPN architecture does not makeany distinction between intranets and ex-tranets. Certain sites within a VPN can beallowed to communicate directly, whereasothers might have restricted connectivity ormight have to pass through a firewall beforecommunicating 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 bemembers of the intranet and an extranet.The MPLS VPN architecture accommodatescomplex 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 themanagement components and procedure fordeploying VPNs. Ericssons IP manage-ment architecture was described in greater

detail in Ericsson Review no. 1, 2000.

Management components

The Ericsson VPN management systemconsists of the following components (Fig-ure 10):


Customer care and billing (CCB) system

Management platform(Comms, discovery, topology,

management, etc)

Networkresourcemanager(NRM)

Policydeploym.manager(PDM)

Internetnetworkmanager(INM)

Servicelevelmanager(SLM)

Router

Router

Router

Figure 10A high-level view of the Ericsson VPNmanagement system.

8/7/2019 2000036

14/14

The customer care and billing system(CCB) contains a billing system and fa-cilitates the definition of customers andthe provisioning of new customer services.A service-level specification (SLS), whichis also part of the CCB, includes the sitesof a VPN, requested bandwidth and QoS,VPN topology, activation/deactivationtime, and so on.

The policy deployment manager (PDM)receives high-level service requirementsfrom the CCB and maps them to appro-priate configuration (CLI) commands thatare necessary to configure a VPN. ThePDM configures the VPN elements (vir-tual routers, stub links, route targets,route distinguishers) that are affected bythe addition or subtraction of a customersite. 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 eachcustomer 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, iBGPsessions, queues, schedulers/drop levels inrouters, and so on.

The service level manager (SLM) collectsnetwork 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 theSLA.

The IP network-performance monitor(INM) measures network performance. Forexample, it measures one-way delay, testsconnectivity, 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-

terface to customer service representa-tives. A service-level agreement is nego-tiatedthis agreement specifies VPNsites, connectivity, QoS, time frame, andso on. The information in this agreementis then passed on to the policy deploymentmanager.

3.The policy deployment manager receiveshigh-level information from the CCB anddetermines the physical configuration tobe 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 withthe SLA.

5.If events or alarms occur in the networkfor example, faults or performance-related events from the INMthe SLMinforms the CCB of correlated events thatlead to SLA violations.

ConclusionNetwork-based IP-VPNs give business cus-tomers the same services and benefits as theyenjoy with their current networks, but useshared public infrastructure instead of pri-vate equipment, and external serviceproviders instead of expensive in-house spe-cialists.

Ericssons MPLS VPN solution is scalableand simple to deploy. It can seamlessly in-tegrate customer routers into the serviceproviders backbone, thereby reducing thecost of deploying and operating VPN ser-vice. The implementation does not requireany changes or additional functions on thecustomers intranet. At the same time, theservice providers backbone can be used in areliable and cost-effective way as a platformfor providing profitable value-added ser-vices, such as telephony, centralized Webhosting, multicast, e-commerce, and secu-rity services for extranets.

Date post:	08-Apr-2018
Category:	Documents
Upload:	faraz-khan
View:	223 times
Download:	0 times

2000036

Documents