APPROVAL PAGE

COMPARATIVE ANALYSIS OF DYNAMIC VIRTUAL PRIVATE NETWORKS

RESOURCE ALLOCATION SCHEMES
OSUIZUGBE CHUKWUKAELO ANTHONY
PG/MENG/13/66526

A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS

FOR THE AWARD OF MASTERS OF ELECTRONIC ENGINEERING
(COMMUNICATION OPTION) IN THE DEPARTMENT OF ELECTRONIC
ENGINEERING, UNIVERSITY OF NIGERIA, NSUKKA.

OSUIZUGBE CHUKWUKAELO SIGNATURE: …………… DATE: ……….

ANTHONY
(STUDENT)

PROF. C. I. ANI SIGNATURE: …………… DATE: ……….

(SUPERVISOR)

EXTERNAL EXAMINER SIGNATURE: …………….DATE: ……….

PROF. C.I. ANI SIGNATURE: …………… DATE: ……….

(HEAD OF DEPARTMENT)

PROF. E. S. OBE SIGNATURE: …………….DATE: ……….

(CHAIRMAN, FACULTY
POSTGRADUATE COMMITTEE)

i
 CERTIFICATION
Osuizugbe Chukwukaelo Anthony, a Master’s degree postgraduate student in the
Department of Electronic Engineering and with registration number PG/M.ENG/13/66526
has satisfactorily completed the requirements for the award of Master of Engineering
(M.ENG) in Electronic Engineering.

______________________ _________________________
PROF. C.I. ANI PROF. C.I. ANI
(SUPERVISOR) (HEAD OF DEPARTMENT)

PROF. E. S. OBE
(CHAIRMAN, FACULTY POSTGRADUATE COMMITTEE)

ii
 DECLARATION

I, Osuizugbe Chukwukaelo Anthony, a Postgraduate student of the Department of Electronic

Engineering, University of Nigeria, Nsukka declare that the work embodied in this thesis is
original and has not been submitted by me in part or in full for any other diploma or degree of
this or any other University.

________________________________________ ______________
OSUIZUGBE CHUKWUKAELO ANTHONY DATE
PG/MENG/13/66526

iii
 DEDICATION

In Loving memory of Anthony Osuizugbe and Catherine Adanma Agwu.

iv
 ACKNOWLEDGEMENT

Deepest gratitude to the Almighty for all he has done especially in providing all that I needed
to accomplish this work.

I am grateful to my incredibly munificent supervisor Professor Cosmas I. Ani who also

doubles as the Head of Department words are not sufficient to express my gratitude for all
your contributions, corrections and direction. I remain indebted to your kindness.

I also acknowledge the effort of friends in the Department, Engr Christsantus, Engr Austin
Ajibo and very importantly Engr Ahaneku. My other friends whose efforts and contributions
I cannot forget to acknowledge Engr Ajimah Edmund and Engr Nnabuike for their immense
support, Engr Nnaemeka and the whole class of 2013. Thank you.

I cannot forget to appreciate Gods greatest gift to me, My Family- my lovely mother Mrs
M.U. Osuizugbe and my brother as well as Arc. Uche Jude Uche.

Sadly this is not an exhaustive list, but I must stop. Thank you all for being there when I most
needed you.

Osuizugbe Chukwukaelo Anthony

Department of Electronic Engineering

v
 ABSTRACT
The need for high performance resource allocation schemes for Virtual Private Networks
(VPNs) cannot be overemphasised, this need has led to the proliferation of algorithms for
resource allocation. While most works on VPN resource allocation focus either on admission
control or link reservation on the network, there is need to carry out research on the effect of
available resource allocation algorithms on the interface between service provider link and
the customer access network. Review of relevant literatures have revealed the need for a
resource allocation/scheduling scheme whose algorithm will be able to allocate bandwidth
and memory resources to different VPNS sharing the same link to the network service
provider in such a manner that resources are optimally utilized while VPN endpoints or
customers receive services that does not undermine the service-level agreement (SLA) with
the service provider. This work carried out a comparative analysis of the performance of two
of the most recent VPN resource allocation schemes. MATLAB Simulink was used to design
a simulation model for analysing the VPN access network obtaining and comparing results
for the link bandwidth utilization, buffer memory utilization and packet loss rate
performances of the RDVNP (Robust Dynamic Virtual Network Provisioning) algorithm
against the DWARF-Net (Dynamic bandWidth Allocation and guarantee on Resource
Fairness) algorithm. DWARF-Net performed better than RDVNP, by 21.15% in bandwidth
utilization, 1.45% in buffer utilization while RDVNP had a loss rate 95.05% higher than
DWARF-Net. From the simulation analysis and result of this work, DWARF-Net was
recommended to researchers as an optimal performing algorithm for VPN resource
allocation.

vi
 TABLE OF CONTENTS

APPROVAL PAGE___________________________________________________________i

CERTIFICATION___________________________________________________________ii

DECLARATION____________________________________________________________iii

DEDICATION______________________________________________________________iv

ABSTRACT________________________________________________________________vi

TABLE OF CONTENTS_____________________________________________________vii

LIST OF FIGURES___________________________________________________________x

LIST OF TABLES__________________________________________________________xii

ABBREVIATIONS_________________________________________________________xiii

CHAPTER 1 INTRODUCTION

1.1 BACKGROUND OF STUDY__________________________________________1

1.2 OBJECTIVE________________________________________________________4

1.3 PROBLEM STATEMENT_____________________________________________4

1.4 SCOPE____________________________________________________________5

1.5 SIGNIFICANCE OF STUDY___________________________________________5

1.6 METHODOLOGY___________________________________________________6

1.7 WORK OUTLINE___________________________________________________6

CHAPTER 2 LITERATURE REVIEW

2.1 MPLS_____________________________________________________________8

2.2 THE MPLS SYSTEM_________________________________________________9

2.2.1 FORWARDING EQUIVALENCY CLASS_____________________________10

vii
 2.2.2 MPLS LABELS__________________________________________________10

2.3 THE MPLS ARCHITECTURE________________________________________11

2.3.1 DATA PLANE___________________________________________________12

2.3.2 PUSH OPERATION:______________________________________________12

2.3.3 SWAP OPERATION:______________________________________________13

2.3.4 POP OPERATION:________________________________________________13

2.4 CONTROL PLANE_________________________________________________13

2.4.1 LABEL INFORMATION BASE_____________________________________14

2.4.2 LABEL FORWARDING INFORMATION BASE (LFIB)_________________14

2.5 MPLS VPN________________________________________________________18

2.5.1 MPLS VPN DEVICES_____________________________________________19

2.5.2 VPN ROUTING AND FORWARDING_______________________________21

2.5.3 ROUTE PROPAGATION IN MPLS VPN______________________________21

2.6 MPLS QOS________________________________________________________27

2.6.1 TRAFFIC ENGINEERING IN MPLS NETWORK_______________________27

2.7 VPN QOS REQUIREMENTS_________________________________________32

2.8 MPLS VPN SUPPORT OF QOS_______________________________________34

2.8.1 PIPE MODEL____________________________________________________34

2.8.2 HOSE MODEL___________________________________________________35

2.9 VPN QOS PHB_____________________________________________________38

2.10 RELATED WORKS IN VPN QOS PROVISIONING______________________39

2.11 CONCLUSION_____________________________________________________49

CHAPTER 3 MODELLING

3.1 ROBUST DYNAMICAL VIRTUAL NETWORK PROVISIONING (RDVNP)__51

viii
 3.2 DYNAMIC BANDWIDTH ALLOCATION AND GUARANTEE ON
RESOURCE FAIRNESS (DWARF-NET)______________________________________52

3.3 NETWORK ARCHITECTURE________________________________________55

3.4 PHYSICAL MODEL________________________________________________56

3.5 SIMULATION VALIDATION________________________________________57

CHAPTER 4 SIMULATION

4.1 MATLAB SIMULATION____________________________________________58

4.2 RESULT__________________________________________________________60

CHAPTER 5 CONCLUSION

5.1 RECOMMENDATIONS_____________________________________________65

5.2 CONTRIBUTIONS__________________________________________________65

5.3 FURTHER WORK__________________________________________________65

REFERENCES_____________________________________________________________67

ix
 LIST OF FIGURES
Figure 2.1 MPLS label Stacks with Fields...............................................................................11

Figure 2.2 Planes of the MPLS Architecture...........................................................................12

Figure 2.3 Relationship between Control plane Forwarding tables and information bases.....15

Figure 2.4 MPLS Architecture showing Control and Data Plane............................................16

Figure 2.5: Flowchart of operation of Label Switch Router....................................................17

Figure 2.6: Levels of MPLS-VPN devices..............................................................................20

Figure 2.7:Data forwarding in MPLS VPN.............................................................................20

Figure 2.8:Route Propagation in an MPLS VPN Network......................................................22

Figure 2.9: Providing VPN QoS with Pipe Model...................................................................34

Figure 2.10: Hose Model..........................................................................................................36

Figure 3.1: Network architecture.............................................................................................55

Figure 3.2: VPN Scheduler Architecture.................................................................................56

Figure 3.3: Model Validation of the Matlab simulator using Dynamic Bandwidth Allocation
and Guarantee for Virtualized Network algorithm..................................................................57

Figure 4.1 Matlab simulation Model for MPLS-VPN..............................................................58

Figure 4.2: VPN Subsystem.....................................................................................................59

Figure 4.3 Traffic Source for VPN..........................................................................................59

Figure 4.4 Traffic collation and Buffer subsystem..................................................................60

Figure 4.5 Scheduler Subsystem with Matlab function block.................................................60

x
Figure 4.6: Chart of Packet generation against Intergeneration time.......................................61

Figure 4.7: Link Bandwidth Utilization Chart of RDVNP against DWARF-Net...................62

Figure 4.8 Buffer Utilization Chart of RDVNP against DWARF-Net....................................62

Figure 4.9: Loss Rate Chart for RDVNP against DWARF-Net..............................................63

xi
 LIST OF TABLES
Table 3.1: DWARF-Net Model Formula Descriptor - - - - - -53

xii
 ABBREVIATIONS
AF Assured Forwarding

ATM Asynchronous Transfer Mode

BGP Border Gateway Protocol

CBR Constraint Based Routing

CBRA Cos Based Resource Allocation

CE Customer Edge

CoS Class of Service

CSPF Constrained Shortest Path First

DIFFSERV Differentiated Services

DWARF-NET Dynamic bandWidth Allocation and guarantee on Resource

Fairness

ECR Egress Committed Rate

EF Expedited Forwarding

FEC Forwarding Equivalency Class

FIB Forwarding Information Base

ICR Ingress committed rate

IETF Internet Engineering Task Force

INTSERV Integrated Services

IP Internet Protocol

IPV6 Internet Protocol version 6

IS-IS Intermediate System-Intermediate System

xiii
KPI Key Performance Index

LFIB Label Forwarding Information Base

LIB Label Information Base

LSP Label Switched Path

LSR Label Switched Router

MPLS Multiprotocol Label Switching

NGN Next Generation Network

OSPF Open Shortest Path First

PE Provider Edge

PHB Per Hop Behaviour

PN Private Network

PVC Private Virtual Circuit

QOS Quality of Service

RD Route Distinguisher

RDVNP Robust Dynamic Virtual Network Provisioning

RFC Request For Comment

RSVP Resource Reservation Protocol

RSVP-TE Resource Reservation Protocol with Traffic Engineering

RT Route targets

SDN Software Defined Network

SLA Service Level Agreement

SNMP Simple Network Management Protocol

xiv
TE Traffic Engineering

TOS Type of Service

TTL Time To Live

VC Virtual Circuit

VPN Virtual Private Network

VRF Virtual Routing and Forwarding

WAN Wide Area Network

xv
 Chapter 1 .
1 INTRODUCTION

1.1 BACKGROUND OF STUDY

For long, traditional Private Networks (PNs) were established by

connecting Private Network sites (e.g., campuses or branch offices of

enterprises) with leased lines over a Wide Area Network (WAN). Since

these lines were dedicated lines, Security and bandwidth guarantees were

assured[1]. As enterprises and other customer’s network sites proliferated

and spread globally, the number of endpoints of PN’s sites has spread

while the endpoints got more geographically dispersed. The distance

between endpoints in a Private Network is directly proportional to the fee

or cost of providing the links in the private network. Thus, connecting a

large number of dispersed PN sites with dedicated lines became very

expensive. As a result, there was a need for a cheaper readily available

alternative to the PNs. The remedy was provided by developing the Virtual

Private Network (VPN) services which ran over the public network’s

backbone or over the public Internet. This method has been quite

successful making VPNs quite ubiquitous in interconnecting Private

network sites.

A Virtual Private Network is described in [2] as “a way to simulate a Private Network over a

Public network, such as the Internet”. It is called "virtual" because it depends on the use of

virtual connections; that is, temporary connections that have no real physical presence, but

consist of packets routed over various machines on the Internet on an ad hoc basis. Secure

1
virtual connections [can be] created between two machines, a machine and a network, or two

networks[2]

The main challenge facing the VPN has been the need to provide

performance guarantees comparable to those obtained in a traditional

Private Networks implemented over a Wide Area Networks (WAN) using

dedicated leased-lines[1].

Traditional VPN services can be offered based on two major paradigms:

1. Overlay Virtual Private Networks where the Service Provider

provides virtual point-to- point links between customer sites

2. Peer-to-Peer Virtual Private Networks where the Service Provider

participates in the customer routing

Initially, traditional VPN implementations were built on the overlay model.

In this paradigm, the Service Provider sells virtual circuits between

customer sites as a replacement for dedicated point-to-point links. The

overlay model has a number of drawbacks, most important of them being

the need for the customer to establish point-to-point links or virtual

circuits between sites. For ‘n’ number of point to point sites, ((n) (n-1))/2

number of links or virtual circuits were needed in a best-case scenario. For

example, a full–mesh connectivity between 4 sites, you will need a total of

6 point-to-point links or virtual circuits[3]. To overcome these drawbacks

2
(particularly in IP-based customer networks) and provide the customer

with optimum data transport across the Service Provider backbone,

another model called peer-to-peer VPN was introduced where the Service

Provider actively participates in customer routing, accepting customer

routes, transporting them across the Service Provider backbone and

finally propagating them to other customer sites[3].

These traditional VPNS had some major challenges and according to [4]

the problems facing the peer to peer and overlay VPN models are

summarised below:

1. The inability of IP to support QOS when using the peer-to-peer

model.

2. In an overlay model (i.e. an IP network with an ATM backbone) to make

communication between ‘N’ routers in IP network, a mesh of the order ‘NxN’ is

needed in the ATM backbone.

3. ATM networks are mainly used for backbones rather than at end

user, converting IP to ATM cells and back can incur a huge overhead

to the system.

4. All the routers using the Internet Protocol within same IP-over-ATM network are

adjacent to each other. If there is any topology change and update in the network

occurs, the update will be sent to all routers in that network. Keeping in mind N^2

mesh within IP over ATM network, there will be N^4 topology update messages for a

single topology update in the network.

3
 5. Large computation is required with the increasing number of routers in IP over ATM

network, consequently overall scalability is decreased.

6. As ATM network within core is capable to provide QOS parameters, yet QoS

available at link layer can’t be extended to IP layer as IP does not support any QoS

guarantee.

In recent years, the Multiprotocol Label Switching (MPLS) has emerged as

a worthy replacement for IP and the overlay VPNs (ATM and Frame Relay).

MPLS VPN combines the best features of traditional Overlay and Peer-to-

Peer VPNs; enabling the Provider Edge routers (PE) participate in customer

routing, guaranteeing optimum routing between sites, easy provisioning

and customers can use overlapping addresses. The PE routers carry a

separate sets of routes for each, making it seem like each customer is

connected to a dedicated PE router. The basic aim of a VPN service

provider is to improve the utilization of network resource while satisfying

the user’s profiled-traffic demand as contained in the Service Level

Agreement (SLA), that is to say, the bandwidth reserved for VPN must be

utilised optimally, while the QoS of the VPN services to the customer

should be satisfied [5].

1.2 OBJECTIVE

The objective of this research work is to investigate the performances of

existing VPN resource allocation/scheduling schemes with respect to

utilization of the service provider’s resources (bandwidth and buffer

space) as well as customer QoS satisfaction as contained in the Service

4
Level Agreement (SLA). The work is expected to equip researchers with a

veritable model that can be used to analyse any MPLS based VPN as well

as provide information from the research carried out on which of the

algorithms analysed and modelled provided optimal performance based

on network resource utilization as well as satisfying the QoS requirement

of the customer in line with specified Service Level Agreement.

1.3 PROBLEM STATEMENT

One of the biggest challenges in network planning is how to deal with traffic uncertainty. In

the past, network operators had to resort to overprovisioning, which is costly. This

inefficient overprovisioning cannot optimise utilization, rather it promotes

wastage of scarce resources (bandwidth and buffer space), while Network

traffic tends to be dynamic due to a variety of factors, such as, load

sharing, changes in routing and flow control parameters also failure of

links, nodes or other network resources and most commonly non-

stationary input loads. Plenty of schemes have been proffered to

dynamically react and provide commiserate QoS to traffic flows according

to their demands and the resources available in the network An important

network management issue is how to maintain QoS requirements in this

dynamic environment.

Although several researches have dealt with the problem of capacity

allocation and scheduling, there is need to investigate the relationship

between the resource utilization of the VPN access links while traffic

pattern and demands of the attached endpoints change.

5
There is also a pressing need in research circles to discover which

dynamic resource allocation techniques can optimise link utilization and

provide optimum QoS at the interface between network provider and

customer premise devices i.e. a scheduling algorithm that will reduce

packet loss rate at customer premise and provide optimal utilization of

link resources at the same time.

1.4 SCOPE

In this paper, the emphasis is on how to effectively control the utilization

of this link and guarantee the QoS for each traffic class, using the hose

model to provision VPN QoS. In today’s networks, several types of traffic

traverses the VPN from one site to another, but in this work, only voice,

packet data and multimedia video traffic will be considered.

1.5 SIGNIFICANCE OF STUDY

This research should be of immense importance to VPN service providers and researchers

who in these days of network proliferation have had to resort to using VPNs to provide

network access to both large and small customers whose demands differ. This work will

recommend to researchers which of the two dynamic scheduling disciplines researched on

provide better performance. This will help increase utilization of scarce network resources

especially at the network bottle-neck regions as well as provide Optimal QoS in line with the

SLA with the customer.

1.6 METHODOLOGY

To realize the objectives of this work, the following methodology was adopted:

6
 Review of literatures in dynamic VPN provisioning techniques and resource

allocation schemes.

Suggest two schemes based on the most recent and ability to improve performance on

both sides of the bottle-neck interface, i.e. network provider and customer interface as

inferred from the review.

Develop computer models of scheduling scenarios implementing the schemes being

compared.

Validate model with performance of existing schemes.

Simulate the models and obtain data using Matlab.

Analyse data in terms of the performance metrics.

Compare the performance of the proposed schemes.

Make recommendations

Collation and compilation (write up) of thesis

Thesis submission

1.7 WORK OUTLINE

The write up of this work is presented and outlined in the following order: Chapter two

reviews the MPLS network, MPLS VPN and other research works on QoS and resource

allocation schemes for MPLS VPNs. In chapter three the models for the selected VPN

schemes are studied, regenerated, validated and simulated using Matlab. Chapter four the

simulation results are obtained, presented and discussed. Chapter five is the conclusion and

recommendations were made

7
 Chapter 2
2 LITERATURE REVIEW

2.1 MPLS

MPLS started out as tag switching by Cisco Inc., it was developed to solve the problems

facing the major WAN technologies, IP and ATM [6]. The challenges of IP networks were

due to its destination based routing which required each router in the link to independently

look up for the “best route” to route traffic to a particular destination IP address. Hence some

links which were seen as having low bandwidth or more cost were avoided in favour of

higher bandwidth or less costlier links this is popularly called the ‘Fish problem’ [7]. This

caused frequent congestions in the over-used links while leaving other links unutilised. The

only ways to use those unutilised routes were through policy based routing but this methods

were not scalable. ATM was introduced to solve this problem by using the virtual paths and

virtual circuits, using Virtual Channel Interface and Virtual Path Interface to create switched

paths for cells. ATM was optimised to carry voice and multimedia traffic with little delay, but

it came at a price, each cell was 53bytes long with 5bytes header. For very large file transfer

in the same direction or trying to implement a very large WAN i.e. the internet through an

ATM Network backbone would be problematic as scalability and the relatively large header

bytes would cause a large overhead costs to the network[8].

MPLS solved these problems by attaching a short label (32 bits) to an IP packet header or the

header of any datagram traffic passing through its network. Packet forwarding is then

implemented based completely on the contents of the label rather than the contents of the IP

address[9].

8
In MPLS, a label is mapped to an egress (exit) router rather than with the destination IP

address of the packet. The MPLS Label is usually a small piece of information attached to a

packet that tells every intermediate router to which egress edge router it must be forwarded.

The core routers do not forward the packets based on the destination IP address, but only

from the labels.

The edge routers however do look at the destination IP address of the packet, in order to

forward them in or out of the MPLS network hence the needs to run Border Gateway

Protocol (BGP) [10]. Each BGP prefix on the ingress MPLS routers has a BGP next-hop IP

address associated with it. This BGP next-hop IP address is an IP address of an egress MPLS

router. The label that is associated with an IP packet is the label that is associated with this

BGP next-hop IP address. Because every core router forwards a packet based on the attached

MPLS label that is associated with the BGP next-hop IP address, each BGP next-hop IP

address of an egress MPLS router must be known to all core routers. Any interior gateway

routing protocol, such as OSPF or ISIS, can accomplish this task[10].

Label switching can appropriately be described as a forwarding model allowing streamlined

forwarding of data by using labels to identify classes of data packets which are treated

indistinguishably when forwarding [11].

2.2 THE MPLS SYSTEM

For MPLS system relies on a plethora of mechanisms and protocols to make the system

functional, a select list of the most important of these mechanisms and subsystems will be

described forthwith

9
2.2.1 FORWARDING EQUIVALENCY CLASS

Forwarding Equivalency Class (FEC) is a set of Layer 3 packets that are forwarded in the

same manner over the same path with the same forwarding treatment. FEC for a packet can

be determined by one or more of a number of parameters, as specified by the network

manager. Among the possible parameters[12]:

Source or destination IP addresses or IP network addresses

Source or destination port numbers

IP protocol ID

Differentiated services code point

IPv6 flow label.

An FEC set, can also include

A set of unicast packets whose Layer 3 destination addresses match a certain address

prefix

A set of unicast packets whose destination addresses match a particular IP address

prefix with similar type of service (ToS) bits

A set of unicast packets whose destination addresses match a particular IP address

prefix and have the same destination TCP port number

A set of multicast packets with the same source and destination Layer 3 addresses

A set of multicast packets with similar source and destination Layer 3 addresses and

the same incoming interface[9]

2.2.2 MPLS LABELS

An MPLS label can be described as "a short fixed length physically contiguous identifier

which is used to identify a FEC, usually of local significance"[11]. The standard MPLS label

10
is a 32 bits long (4 octets) header which can be used over Ethernet 802.3, PPP links, Frame

Relay, ATM Private Virtual Circuits (PVC). The MPLS labels are attached to the header of

the packet, frame or cell and are used to index the forwarding decision an LSR makes[11].

Label value Exp S TTL

20 3 1 8

Figure 2.1 MPLS label Stacks with Fields

The fields in the MPLS Label stack above are explained below.

Label Value: It is a 20 bits field which carries the actual value of the label. Label

values 0 - 15 are reserved[13]. This is the value that is looked up by LSRs and

compared with their particular forwarding table. As noted previously, label values

have local significance

Experimental bits (Exp) (3 bits) - They were set for experimental use, and are

sometimes used for class of service using IP precedence values [14].

Bottom of Stack (S) (1 bit) - This field is set to 0 for all other label stack entries while

it is set to 1 if the current label is the only one present the last label in the stack.

TTL (Time to Live) (8 bits) - The TTL field has a function identical to that of the TTL

field in an IP header. It is used to detect loops in a network.

2.3 THE MPLS ARCHITECTURE

The MPLS architecture is made up of two planes, namely

1. Data plane
11
 2. Control plane.

MPLS

Data Control
Plane Plane
Figure 2.2 Planes of the MPLS Architecture

2.3.1 DATA PLANE

Also called the data Forwarding plane, it is responsible for forwarding packets within the

MPLS network. Each MPLS device in this plane is referred to as a Label Switch Router

(LSR)

There are basically two categories of LSR’s

Edge LSR

Ingress Router

Egress Router

Core LSR

While there are basically three types of operations that are carried out on a packet in the

forwarding plane in an MPLS network, they are:

12
2.3.2 PUSH OPERATION:

When a packet leaves the customers and is forwarded to the provider network, the label edge

device receives the packet and after inspecting the header, inserts and MPLS label into the

packet. This process of attaching an MPLS label to a non MPLS frame or packet is known as

a Push operation. It is important to note that labels are assigned to traffic based on their

forwarding equivalency class (FEC). It is important to note, that a label is not an encoding of

the destination address.

The edge routers forward the labelled MPLS packet towards the core routers which perform

another MPLS operation on the packet or traffic

2.3.3 SWAP OPERATION:

The adjacent LSR receives the traffic, inspects the labels, and replaces the label with its own

outgoing label, before forwarding the traffic to the next hop router through the specified

interface. This operation is referred to as the SWAP operation.

2.3.4 POP OPERATION:

When the packet arrives at the penultimate LSR i.e. the LSR before the egress router, the

penultimate router varies out a “pop” operation on the label stack by dropping the label stack.

After popping the label stack the packet is forwarded to the egress router through its

appropriate outgoing label. The process of the penultimate LSR popping the labels is known

as penultimate hop popping.

2.4 CONTROL PLANE

The MPLS control plane is managed by the following databases:

13
 Routing Information Base (routing table): it is usually generated from the routing

sources such as the routing protocol. It contains binding information linking the

destination IP and next hop adjacent router for that destination

Forwarding Information Base: it is usually generated from the routing table as well

as the layer two and layer three mapping. The FIB contains information as it concerns

mapping incoming routes to the next hop and through a specified outgoing interface

2.4.1 LABEL INFORMATION BASE

This database is populated with information from the routing table as well as information

derived from the label distribution protocol or any protocol used to advertise labels.

Information found in the LIB include the bindings between the destination address, local

label, next hop router and outgoing label.

2.4.2 LABEL FORWARDING INFORMATION BASE (LFIB)

The LFIB shares the same forwarding database as the FIB, the contents of the LIB and the

layer2 and layer3 mapping. It is important to note that the LFIB control bindings is

responsible for the control policy that is needed to properly route packets in the MPLS

network backbone.

The LFIB binding information maps destination label or IP address, next hop information,

outgoing interface and outgoing label to a particular FEC.

14
 ROUTING LDP
INFORMATION

RIB LIB

LABEL
POOL

FIB LFIB

LAYERS 2 AND 3
PROTOCOLS

Figure 2.3 Relationship between Control plane Forwarding tables and information bases

The control process is specified for forwarding packets in only one direction. The above

diagram can be used to show how the control plane enables packet forwarding in one

direction. Suppose traffic is transferred from A to B, for labelled switching to be possible on

an MPLS network, the different tables i.e. RIB, FIB, LIB and LFIB are populated with route

based on their table sources.

For labelled switching to take place, the LFIB has to be populated as it contains the primary

control information necessary to make a LABEL switch decision possible, since it contains

all the entries of the other tables.

Assuming node ‘A’ is sending packet traffic across to node ‘B’ through the MPLS Backbone,

the ingress router R1 inspects the header, which might be assumed to be an IP packet

15
assuming the customer node is not MPLS enabled. From the header inspection, R1 discovers

the Field equivalency class or FEC of the traffic usually from the destination address. The

destination IP address is looked up in the FIB, if an entry for such FEC exists in the FIB,

LFIB is looked up if there is an outgoing label for that FEC. If no entry is found in the FIB

with respect to the FEC of the traffic from node A the packets are dropped.

If an outgoing label is found in the LFIB for that FEC, the outgoing label is pushed into the

label stack of the packet and forwarded to the next hop through the outgoing interface as

indicated by the LFIB.

Figure 2.4 MPLS Architecture showing Control and Data Plane

16
When subsequent routers in the backbone receive the labelled traffic flow, it looks up the

incoming label if it matches an entry in its LFIB, if it doesn’t match any entry in the LFIB,

the packet is dropped. If a match is found, the incoming label is swapped with the outgoing

START
Drop the last
entry in the
label stack i.e.
2 Pop the label
Initiate Yes
systems and No
exchange label
Route Information Does
incoming label Yes is outgoing
correspond to an content ="implicit null"
LFIB Or label= "3"?
entry?

Populate databases
Look up the No
i.e. RIB, FIB, LIB and
incoming label
LFIB With routing Swap incoming
entry in LFIB Forward Packet to
information label with its
destination address
corresponding
Yes 2 through outgoing interface
outgoing label
1
Is there No
listen to open a label in
interfaces for header No
packet routing Drop Packet
request
Push Outgoing
No Label into
Yes look up LFIB for packet's label
No Traffic look up packet is
destination Yes outgoing label Stack
received? header for label address found matching the
packet's FEC Yes
in FIB?

Does any
look up the LFIB entry match
FIB for the packet's FEC?
destination
address

Figure 2.5: Flowchart of operation of Label Switch Router

label and forwarded through the outgoing interface. If outgoing label content equals implicit

null, penultimate hop popping takes place, the label stack is dropped and the packet is

forwarded to the egress router through the outgoing interface. In the egress router the packets

are received without a label, the FIB looks up the IP address and forwards it to the destination

which is a directly connected route through the specified interface.

17
MPLS VPN

MPLS-based VPN technology uses a combination of connection-oriented and connectionless

VPN technologies. The model of the MPLS VPN is described below:

The interface between the CE routers and the PE routers is connectionless, therefore no

additional configuration is needed on the CE devices [10].

The PE routers use a modified IP forwarding paradigm; a distinct IP routing and forwarding

table (called virtual routing and forwarding table, or VRF) is created for each customer.

The customer's addresses are extended with 64-bit route distinguishers to make non-unique

32 bit IP addresses globally unique within the service providers' backbone.

The resulting 96-bit addresses are called VPNv4 addresses [15].

A single routing protocol is run between the PE routers for all VPN customers. Modified

Border Gateway Protocol (BGP) with multiprotocol extensions is used in this function.

The PE routers use MPLS-based VCs (called label-switched paths, or LSPs) to transport the

customer's datagrams between PE routers. Additional MPLS labels are inserted in front of the

customer's IP datagrams to ensure their proper forwarding from ingress PE routers toward the

destination CE router.

The LSPs between all PE routers are established automatically based on the IP topology of

the P-network. It is unnecessary to configure or manually establish these paths.

The mapping between the customer's destination addresses and LSPs leading toward the

egress PE routers is performed automatically based on the BGP next-hops[15].

18
2.4.3 MPLS VPN DEVICES

MPLS core routers: The core routers, also known as Provider routers (P routers), do not

maintain any VPN routes. They typically reside in a full- or partial-mesh configuration with

other Provider LSRs and interface with provider edge (PE) routers. P routers are never

directly connected to customer routers.

MPLS edge routers (PE): Point-of-presence routers, also known as provider edge routers (PE

routers), maintain VPN routes for VPNs that are members. They peer with the customer edge

(CE) routers and interface to the core provider routers. PE routers peer with P routers or may

be directly connected to other PE routers.

Customer edge routers (CE): The customer edge routers (CE routers) do not have to support

MPLS and can use conventional routing methods to achieve connectivity. The peer model

requires a customer site to peer with only one PE router as opposed to all other CPE or CE

routers that are members of the VPN. CE routers are never directly connected to P routers.

Customer routers (C): The customer-owned internal routers, also known as C routers, do not

have to support MPLS and can use conventional routing methods to achieve connectivity

with the CE router and each other.

The VPN contains customer devices attached to the CE routers. The CE routers in either VPN

can be connected to any of the service provider's PE routers. The PE routers connect to each

other through a core network of P routers.

19
Figure 2.6: Levels of MPLS-VPN devices

Figure 2.7:Data forwarding in MPLS VPN [16]

20
2.4.4 VPN ROUTING AND FORWARDING

Virtual Routing and Forwarding (VRF) is an IP technology that allows multiple instances of a

routing table to coexist on the same router at the same time. Because the routing instances are

independent, the same or overlapping IP addresses can be used without conflict. It also refers

to a routing table instance that can exist in one or multiple instances per VPN on a Provider

Edge (PE) router[17]. Each PE-router has one VRF per VPN attached to a particular

attachment circuit or interface.

A VRF defines the VPN membership of a customer site attached to a PE router. A VRF

consists of an IP routing table, a derived Forwarding and information base table, a set of

interfaces that use the forwarding table, and a set of rules and routing protocol parameters

that control the information that is included in the routing table [9].

Route distinguisher RD: An RD is a 64-bit field used to make the VRF prefixes unique when

MP-BGP carries the VRF prefixes across the network. Each VRF has an RD attached to it.

There are two RD formats, one containing ASN: nn (autonomous system number: arbitrary

number) and another containing IP-address:nn (nn is still an arbitrary number. The RD solves

the problem of overlapping addresses.

Route Targets (RT): the RT is used to identify a set of sites or VRF.

2.4.5 ROUTE PROPAGATION IN MPLS VPN

The VRF is used to distinguish and separately route customer information through the PE

routers. The size of the routes needed to transport the VRF prefixes across the Service

provider network could become very large, hence the need to use an appropriate routing

protocol that can adequately carry such routes. [16]Posits the use of BGP due to its usefulness

in carrying large routing tables like the internet. But due to the long prefix of the VRF
21
addressing scheme using the IP, RD and RT (96 bit long address scheme), an extension of

BGP is used called MPLS-BGP or vpnv4

Figure 2.8:Route Propagation in an MPLS VPN Network[16]

22
 Receive
Packet

1 Discard Packet

is Packet YES
2
labelled?
1

NO
NO

NO is Destination
is packet from VPN look up LFIB for
Address in Forwarding
interface? Label
Table?

YES

Perform IP is there
NO
lookup using an LFIB entry for
Look up packet's FIB to discover destination
IP in VRF entry next hop address?

YES

is push label to
VPNv4 stack
1
address used
valid?

YES

Is destination router
location>1 hop?

YES

Push VPN label

corresponding to
destination VPN and set
S bit to 1

Also Push label

corresponding to next
hop and set S bit to 0

Forward to
outgoing
interface
interface

23
 2

Check label
content

is label
value available in 1
LFIB

what action POP

is available for the drop label
outgoing label?

SWAP

look up
Attach outgoing destination IP
label route

forward to
outgoing
interface

Figure 2.9 Flowchart of Switching in MPLS VPN

The label stack is imposed by the ingress PE router. The top label in the stack will be used by

LDP for P network traversal along an LSP that will get it to the egress PE router. The S-bit in

the top label will be set to 0. The second label will be assigned by the egress PE router.

Remember, the label values are downstream-assigned. The purpose of the second label is to

24
tell the router how to forward the incoming VPN packet. This label could point to a particular

outbound interface or to a VRF table. If the label points to an outbound interface, a label

lookup is performed on the VPN packet itself. If a VRF table pointer is specified, a label

lookup is performed to find the target VRF instance. An IP routing lookup is then performed

within that VRF instance. The S-bit in the second label will be set to 1. The S-bit is the “end-

of-stack” pointer. When set to 0, there will be further labels in the stack. The bottom label in

the stack will have the S-bit set to 1, indicating its position as the last label.

The second label in the stack points to an outbound interface when the CE router is the next

hop in the VPN route. The second label points to a VRF table for aggregate VPN routes,

VPN routes to the null interface, and directly connected VPN interfaces.

The P routers perform label switching based only on the top label. They never see the second

label because they do not analyse the structure any further than the first label.

The egress PE performs a label switch on the second label because the first one has been

popped. This will forward the packet according to the parameters of the packet, which point it

to a VRF or an outbound interface.

It seems inefficient and time wasting for the egress PE to process two labels as well as

perform routing, the use of Penultimate Hop Popping allows the final P router in the LSP to

pop the label, thereby relieving the egress PE router of the need to do so. This allows the

egress PE router to simply perform its function using only the VPN label in the stack. Once

that label is removed, an IP routing lookup can take place and the packet can be

forwarded[14].

25
In the area of QoS, the challenge is to develop a set of mechanisms that supports QoS in a

way that is flexible enough to support a wide range of VPN customers and scalable enough to

support a large number of VPN customers [18].

This work performs an investigation on the utilization of the resources allocated to users by

different resource allocation schemes used to provide quality of service for VPN users.

Quality of Service is defined by [9] as those mechanisms that let network managers control

the mix of bandwidth, delay, jitter, and packet loss in the network. It also advised that QoS

should not be seen as a device feature, rather it is an end-to-end system architecture. A robust

QoS solution should include technologies that interoperate to deliver scalable, media-

independent services throughout the network, with system-wide performance monitoring

capabilities. IP QoS capabilities allow providers to prioritize service classes, allocate

bandwidth, and avoid congestion.

The Internet Engineering Task Force (IETF) has defined two models for IP QoS

implementation: Integrated Services (IntServ) and Differentiated Services (DiffServ). IntServ

recommends the use of signalled QoS model, in which the end hosts signal their QoS need to

the network for reservation of bandwidth and any other network resources. DiffServ works on

the provisioned QoS model, in which network elements are set up to service multiple classes

of traffic with varying QoS requirements [1]. The IntServ and DiffServ models can be

enforced using the COPS (Common Open Policy Server) protocol.

Service providers offer premium services defined by Service-Level Agreements (SLAs) to

facilitate or expedite traffic from certain customers or applications. QoS in IP networks gives

devices the intelligence to preferentially handle traffic as dictated by the SLA and ensuring

26
network policy. QoS is defined as those mechanisms that let network managers control the

mix of bandwidth, delay, jitter, and packet loss in the network.

Bandwidth utilization is the wise use of available bandwidth to achieve specific goals.

Efficiency can be achieved by using multiplexing; privacy and anti-jamming can be achieved

by using spreading [19].

To facilitate QoS implementation in MPLS networks the MPLS traffic engineering was

developed by the IETF, giving it an edge over IP.

2.5 MPLS QOS

The term QoS is a bit ambiguous, in MPLS QoS can be described based on the requirement

of an application which is defined in terms of the service level agreement metrics for service

performances. Such service performances may include delay, jitter, packet loss, throughput,

service availability and per flow sequence preservation.

The goal QoS tries to achieve is to maximise end user satisfaction while preserving utility
and efficiency, at the same time minimizing cost.

2.5.1 TRAFFIC ENGINEERING IN MPLS NETWORK

Traffic Engineering (TE) is a mechanism that controls the traffic flows in the networks and

provides the performance optimization by optimally utilizing the network resources [20].

Some of the key features of TE are resource reservation, fault-tolerance and optimum

Resource utilization[21].

The following processes are needed to implement Traffic Engineering

Distribution of Topology information: There needs to be a mechanism to advertise the

current information about the links for the nodes, so that the nodes can build a map

about the network topology. It is crucial that the information about the link or node

27
 failures have to be rapidly propagated through the network enabling a quick solution

to the problem [22].

Path selection: This process involves computing the path information between nodes

in the network. The shortest path with minimum links is selected while considering

other constraints like bandwidth and delay during the path selection.

Directing Traffic along the computed paths: Traffic is forwarded along the particular

calculated path between source and destination node. Typically this is usually

achieved by using a forwarding table.

Traffic Management: Traffic management deals with the process of forwarding the

traffic with the predictable quality. The parameters such as bandwidth, delay, and

jitter and packet loss are the main concern for the traffic management.

It should be noted that MPLS was designed to implement traffic engineering since IP has

several limitations which includes

Congestion due to overlapping links from different sources

Underutilization of the longest path even when shortest path is experiencing

congestion

Poor utilization of links as IP is destination based routing and may not consider less

busy links

Load sharing cannot be achieved in IP networks between multiple paths of different

costs

The IETF document RFC2702 has described the traffic engineering model for MPLS and is

summarised in the following paragraphs[23].

28
The packets are forwarded to their destination based on the concepts of Forwarding

Equivalency Class (FEC) within the MPLS domain, only these labels are used to make

forwarding decisions without resorting to the original header of the packet.

Traffic engineering is concerned with optimizing the performance of an operational network

(most likely a large network; a service provider, large enterprise or the internet). TE

encompasses the application of technology and scientific principles to measure, model and

characterise traffic from a large network using or applying such knowledge and techniques to

achieve specific performance objectives.

The following factors make MPLS very attractive for Traffic Engineering [6]

1. MPLS has explicit label switched paths (LSPs) which can be manually created or

created by automated action. Setting up these LSPs are not affected by destination

based routing.

2. LSPs have the potential and ability to be effectively maintained.

3. Trunks of traffic (aggregation of traffic flows of the same class which are placed

together in an LSP) can be instantiated and mapped into an LSP.

4. Sets of attributes can be associated with traffic trunks to modulate their behavioural

characteristics.

5. A set of attributes can be associated with resources which constrain the placement of

LSPs and traffic trunks across them.

The objective of Traffic Engineering is to efficiently use the available network resources and

increase the quality of service of applications and users on the Network. The motivation

behind MPLS TE is Constraint Based Routing (CBR) [22]which takes bandwidth, policies

and network topology into consideration before establishing a path (or Label Switched Paths)

in MPLS domain to forward packets.

29
2.5.1.1 CONSTRAINT BASED ROUTING

Constraint Based Routing (CBR) is also known as constrained shortest path first (CSPF), it is

an extension of shortest path algorithms. CBR computes the path in MPLS, based on

constraints such as minimum amount of bandwidth required in a link, end-to-end delay and

other administrative policies [24]. CBR path selection involves the procedure of removing

paths with insufficient bandwidth or a required constraint set by the administrative policy.

Only paths which meets these requirements are selected and the shortest path algorithm is run

on these paths to find the shortest path from ingress to egress router of the MPLS network.

The path given by CBR routing may be a longer but lightly loaded path which is better than

heavily loaded shortest path [22].

CBR is extensively used in the MPLS TE for distributing the traffic evenly and increasing the

network performance.

For establishing the LSPs from Ingress to Egress router and implementing TE in MPLS

network signalling protocols are used. RSVP and CR-LDP are the signalling protocols

developed by IETF to implement TE in MPLS.

Below are the Requirements of signalling protocols used in MPLS TE:

It is essential that signalling protocols used in MPLS TE contain the following characteristics

as described in [24]

Robustness: Even in the presence of network congestion or failure the delivery of

signalling messages need to be reliable in the network

Scalability: If the size of MPLS network is large, each node needs to support a large

number of LSPs. It is required that the signalling system is scalable in order to deliver

the required performance, even though there are large number of LSPs and nodes.

30
 LSP establishment/teardown/maintenance: The signalling protocol has to provide LSP

establishment, teardown and maintenance in the MPLS network.

LSP priority/pre-emption: In MPLS network it is possible that high priority LSPs may

teardown lower priority LSPs, when there are not enough resources available for both.

Alternative path setup and rerouting capability: To deliver the dependable services it

is required to have the path optimization, resilience and failure recovery in the

networks. The failure situations have to be identified and recovered quickly with

minimum control.

For this work and in line with recent practice, only RSVP-TE will be considered in this

chapter.

2.5.1.2 RSVP TRAFFIC ENGINEERING

Although RSVP was originally designed to support an anticipated widespread demand for

real-time applications over the Internet, such as teleconferencing. That anticipated demand

has not materialized in practice and RSVP has not achieved widespread deployment.

However, the Traffic Engineering (TE) extension for RSVP [RFC 3209], referred to as

RSVP-TE, has been widely deployed by a large number of network service providers[25].

RSVP-TE is used for traffic engineering within Multiprotocol Label Switching (MPLS)

networks. Used in this context, there are some significant differences from RSVP. The most

significant difference is that rather than using paths already established by the Internal

Gateway Protocol (IGP), RSVP-TE is used to set up the data path; RSVP-TE establishes

MPLS label switched paths (LSPs), in addition to performing resource reservation and

admission control.

In the context of admission control, there are several ways that RSVP-TE could be deployed:

31
 RSVP-TE could be used in conjunction with MPLS as the tunnelling technology

underlying RSVP aggregation.

RSVP-TE could be used to provide end-to-end reservations for MPLS attached end-

systems, which support MPLS and RSVP-TE in service provider network

environments.

RSVP-TE is widely used for traffic engineering within service provider networks;

where it provides admission control for traffic “trunks” across the network. A “trunk”

is an aggregation of traffic from an ingress point to an egress point. RSVP-TE

provides capacity management within the core of an IP/MPLS network.

2.6 VPN QOS REQUIREMENTS

For different applications, there are some QoS requirements that must be
guaranteed to ensure customer satisfaction is assured.

Table 2.1.Performance Targets for Real-Time Interactive Services[26]

Typical
Degree of Data Key Performance
Mediu Symmetr Rates/Amou Parameters and Target
m Application y nt of Data Values
End-to-
End Delay
One- Variatio
Way n Within Informatio
Delay a Call n Loss
Audio Conversatio Two-way 425 kbps < 150 < 1 ms < 3
nal voice ms percent
preferre packet
d. loss ratio

32
 Typical
Degree of Data Key Performance
Mediu Symmetr Rates/Amou Parameters and Target
m Application y nt of Data Values
End-to-
End Delay
One- Variatio
Way n Within Informatio
Delay a Call n Loss
< 400
ms limit.
Video Videophone Two-way 32384 kbps < 150 < 1
ms percent
preferre packet
d. loss ratio

< 400
ms limit.

Lip-
synch: <
100 ms
Data Telemetry Two-way < 28.8 kbps < 250 0
two-way ms
control
Data Interactive Two-way < 1 KB < 250 0
games ms
Data Telnet Two-way < 1 KB < 250 0
(asymmetr ms
ic)

33
The table1 above elaborates on the delay sensitive nature of some real-
time services, stipulating the maximum delay, jitter and loss that can be
tolerated for some time affected traffic, while some applications can
tolerate some delay, <250 ms they will not tolerate loss, inversely some
could only tolerate delay of <150 ms but less than 3% loss. To provide
each traffic type with the required QoS in line with the specified SLA, an
appropriate priority scheme needs to be implemented to provide
satisfactory performance [27]–[29]. The VPN user is handed quality of
service assurances which correspond to the traffic the service provider
transports in the network. To keep operation and management cost low,
operators would like new services to support a high degree of automation
and reduced customer-provider interaction. For example, joining or
leaving VPNs should be a largely automated process, possibly using
policy-based configuration mechanisms on the provider side.[30]

2.7 MPLS VPN SUPPORT OF QOS

There are two popular models that are used to describe QoS in the VPN framework, they are

the “pipe” model and the “hose” model which are explicitly covered in [1], [18], [25], [31]–

[38], [38]–[53]

2.7.1 PIPE MODEL

34

Figure 2.9: Providing VPN QoS with Pipe Model

In the Pipe model (also known as the “customer pipe” model [34], [44], [54], [55]) a VPN

service provider supplies a VPN customer with certain QoS guarantees for the traffic from

one customer’s Customer Edge router to another. This model could be represented by a

“Pipe” that connects these two routers, and the traffic that enters this Pipe gets certain QoS

guarantees. One example of the sort of QoS guarantees that could be provided with the pipe

model is some guaranteed minimum bandwidth between two sites as presented in [25], [35],

[40], [42], [43], [46]–[48], [56].

Customer pipes could be further refined by making only a subset of all the traffic (i.e. only

specific applications) from one CE to another CE able to use the pipe. Decisions on what

traffic could use the “customer pipe” is totally local to the PE router at the ingress end of the

pipe.

Pipe model is closer in operation to the QoS model that VPN customers have with Frame

Relay or ATM-based solutions [18]. The essential difference is that Frame Relay or ATM

connections are bidirectional, whereas the pipe model offers unidirectional guarantees

(because label switched paths created allow traffic in only one direction). Since the customer

is left to specify their QoS requirements for every pair of endpoints [37][39][1][46], it

therefore means it is easily understood by customers. The pipe model has some major

drawback which arises from the assumption that a VPN customer knows the complete traffic

matrix of the network. Quite often this information is not available or could be outdated. Also

the pipe wastes resources as the connection between two edge routers have fixed bandwidths.

2.7.2 HOSE MODEL

The hose model was proposed by Duffield et al. to solve the problems of the Pipe model

[35].In the hose model, VPN customers just need to specify the incoming and outgoing traffic
35
volume of each VPN endpoint (known as ingress bandwidth and egress bandwidth) instead of

between every pair of VPN endpoints.

Figure 2.10: Hose Model [55]

They stated the advantages of the hose model in [12] and [13] as:

Ease of Specification: Only one inward and outward rate (possibly asymmetric) per

hose endpoint needs to be specified, as compared with that for each customer-pipe

between pairs of endpoints.

Flexibility: Data to and from a given hose endpoint can be distributed arbitrarily over

other endpoints provided the aggregate conforms to the hose size.

Multiplexing Gain: Due to statistical multiplexing gain, hose rates can be less than

the aggregate rate required for a set of customer-pipes.

Characterization: Hose requirements are easier to characterize because the statistical

variability in the individual source- destination traffic is smoothed by aggregation into

hoses.

In the hose model, a VPN service provider supplies a VPN customer with certain guarantees

for the traffic that the customer’s CE router sends to and receives from other CE routers of

the same VPN. As a result, in contrast to the pipe model, the hose model does not require a

36
customer to know its traffic matrix, which, in turn, places less burden on a customer that

wants to use the VPN service.

The Hose model uses two parameters, Ingress Committed Rate (ICR) and Egress Committed

Rate (ECR).

The ICR is the amount of traffic that a particular CE could send to other CEs,

The ECR is the amount of traffic that a particular CE could receive from other CEs.

It should be noted that, for a given CE, there is no requirement that its ICR should be equal to

its ECR.

Using a single guaranteed bandwidth LSP to carry multiple pipes between a pair of PE

routers improves the scaling properties of the solution. This is because the number of such

guaranteed bandwidth LSPs that a service provider has to establish and maintain is bound

(from above) by the number of PE router pairs of that service provider, rather than by the

number of pipes the VPN customers of that provider could have.

To support Classes of Service that fall into the hose model, a service provider uses DiffServ

support with MPLS. The service provider may also use MPLS traffic engineering to improve

network utilization while meeting the desired performance objectives.

The procedures by which an ingress PE router determines which traffic receives a particular

Class of Service, regardless of whether that Class of Service falls into the hose or the pipe

model, are purely local to that PE router. These procedures can take into account such factors

as incoming interface, IP source and destination addresses, IP precedence, TCP port numbers,

or any combination of the above [18]. This gives a service provider significant flexibility with

respect to control over what traffic gets a particular Class of Service. Although a customer

signs a contract with a service provider for a certain amount of traffic in a particular Class of

37
Service, the customer may send traffic in excess of this amount. To determine whether the

traffic is within the contract, the service provider uses policing at the ingress PE routers. For

traffic that is out of contract, the provider has two options: either to discard this traffic

immediately, at the ingress PE router, or to send the traffic, but mark it differently from the

traffic that is in contract. With the second option, in order to reduce out-of-order delivery,

both in- and out-of-contract traffic should be forwarded along the same LSP. The out-of-

contract traffic is marked differently, and this marking affects the drop probability in case of

congestion.

2.8 VPN QOS PHB

Currently, two Per-Hop-Behaviour (PHBs) are defined in the Diffserve QoS model, they are

Expedited Forwarding (EF) and Assured Forwarding (AF) [57]. The EF PHB can be used to

build a low-latency assured-bandwidth end-to-end service through a DiffServ domain. A

typical SLA for such a service might include the ingress and egress points of the DiffServ

domain and a peak rate, which can be guaranteed to the traffic stream. AF PHB defines four

classes, each class with three drop preferences. It is a way for a DiffServ provider to offer

different levels of forwarding assurances for IP packets received from a customer domain. A

typical SLA may include ingress/egress points and rates for low and medium drop priority

packets such flexibility allows a customer to specify a bandwidth range rather than a single

peak rate for a VPN tunnel. This is helpful for customers because they usually cannot provide

accurate traffic rates[57].

Within the service provider network, the P routers may use DiffServ PHBs for service

differentiation. Note that the P routers need only maintain queuing state on an aggregate (e.g.,

per-PHB) basis, rather than on a per-VPN basis.

38
2.9 RELATED WORKS IN VPN QOS PROVISIONING

There has been lots of research on MPLS-VPN networks especially in the area of QoS

provisioning, a brief review of the research materials that were reviewed for this work are

presented.

The authors in [35][48][39][58]investigated various ways to face the challenge of dealing

with uncertainty about the traffic’s spatial distribution and provide enough resources to

accommodate for the worst case traffic variation. Their efforts can be classified in static and

dynamic approaches. The static Provider-Pipes approach is the most simple of the static

schemes, consisting of reservations at the Hose’s peak rate between any two service

endpoints. Obviously, efficiency is very low and the overprovisioning factor, i.e. the

bandwidth requirement compared to the corresponding customer-pipes dimensioning, has

been found to increase linearly with the number of nodes in the network, which makes this

approach inappropriate for practical application as scalability becomes an issue [48].

More efficient static schemes make use of shared reservations for tunnels with a common

service endpoint or, more generally, resources are shared among tunnels of the same VPN on

common links anywhere in the network. These resource-sharing approaches differ with

respect to a number of parameters, like for example support of symmetric or asymmetric

interface parameterization, shortest-path, explicit or multi-path routing patterns and the

amount of information needed for service provisioning. Some approaches rely on sink-rooted

or source-rooted trees on the respective service endpoints, others try to compute a near-

optimum topology for the entire VPN.

39
In [39]the authors showed that the computation of such resource sharing topologies can be

computationally hard, depending on the type of routing and whether hose parameters are

symmetric or not.

The authors in [58] proposed an algorithm to calculate multi-path topologies and compared

the performance of several approximation algorithms. They found that running times of these

topology computation algorithms increase very quickly with the number of nodes and can be

in the order of minutes for large networks.

In [48], it has been shown that in order to achieve reasonably low over-provisioning factors,

the computation of a tree-structured resource-sharing topology for the whole VPN using

explicit routing is the only viable candidate among the statically provisioned models without

multi-path routing. In general, these computations require a global view of the VPN and the

parameters on the respective service endpoints.

[59] Proposed a new resource management concept has been proposed which is called the

point-to-set model. The major drawback of the traditional customer-pipes model to require

detailed information on traffic distribution is relaxed to a specification of a set of destinations

and the mean and variance of the traffic fraction to each of these service endpoints. However,

this specification still trades off flexibility of the customer’s traffic patterns against resource

efficiency of the VPN realization in the provider network.

In [60], Volner et al set out to develop a mathematical model for allocating VPN connections

to bandwidth. They assumed the traffic generated is memory-less, generation of traffic to

support the simulations was achieved by a negative exponentially distributed process to

specify packet inter-arrival time. They proposed a technique for determining optimal routing

and bandwidth reservation for VPNs in the hose model previous research work focuses on
40
routing and bandwidth provisioning for single VPN. Their analytical techniques are also

useful in tackling other network problems when traffic uncertainty is inherent.

In [61] Hachimi et al presented an “Efficient QoS implementation for VPN”, in their work

they Proposed an efficient QoS configuration scheme for MPLS based VPNs services. From

their study, they noted that VPN equipment could be configured to effectively provide QoS

guarantees to the customers. Their goal was to give customers the possibility to exceed their

contracted bandwidth if residual bandwidth is available in the link or if other VPNs users do

not utilise their contracted bandwidth. The excess traffic was guaranteed if accepted in the

scheme and the customer will be charged for it. While all VPNs were guaranteed to receive

their contracted bandwidth if needed.

In [38] the authors carried out simulations on different queuing schemes or policies using real

traffic. The four queuing mechanisms considered were FQ, PQ, CQ (two versions), and LLQ.

It was possible to determine the limitation on the number of calls in each customer’s site.

From their simulations and results, they concluded that the priority-based schemes PQ and

LLQ may be used when the number of high priority voice sources is low. When the number

of high-priority sources increases, they proposed that it became necessary to use the other

schemes, as a sort of starvation happening to the other low-priority sources. They also varied

the bandwidth of the last-mile link located at the customer’s main site, given that it was

considered as the main bottleneck to the traffic being carried. They introduced this technique

as an alternative for achieving the QoS requirements for the high priority traffic if the

corresponding number of sources increase and the priority scheme cannot add any

improvements. Consequently, they advised the service provider whether or not to increase the

bandwidth of the last-mile link at the main site if the need for accepting more customers of

certain type may arise.

41
In [62], Rakovetic et al presented the strategy of Dynamic Partitioning of link bandwidth in

IP networks. In the Dynamic Partitioning scheme the bandwidth of each link in the network is

partitioned into two parts, one for the low-priority data traffic, and one for the high-priority

stream (real-time) traffic. The partitioning is defined by the partitioning parameter, which

changes according to the traffic profile and intensity. The paper presented and algorithm for

the change of partitioning parameter. The evaluation of the scheme is done based on the

connection utility, which is the measurement of the average end-user utility. Based on this

measurement, the dynamic partitioning scheme is compared to several other bandwidth

allocation schemes. Their results showed that their dynamic partitioning of bandwidth

produced a better user utilisation compared to complete partitioning scheme.

[57] Describes a scheme for the support of Quality of Service over Virtual Private Networks

(VPN). They used a combination of Diffserv, MPLS and a dynamic resource allocation

technique in order to provide a QoS-enabled VPN. They carried out dynamic resource

allocation using traffic predictors. The predictor assumed that the statistical behaviour of

aggregate traffic streams are statistically described through a stable long-rage dependent

stochastic processes. In the work, they investigated scenarios in which the service provider

establishes Service Level Agreements (SLAs) with the customers, where the resources and

QoS requirements are defined. When operating the network, the provider uses dynamic

resource allocation algorithms to pace and forward traffic while optimizing the resource

utilization.

In [32] the authors proposed solutions to reduce the bandwidth over provisioning factor of the

hose-based VPN solutions, they proposed a two-step resolution approach. First, a pipe

workload was obtained exactly using the user specified hose and a mathematical

42
programming formulation. Second, a VPN solution was obtained using the pipe-based integer

programming formulation of the VPN provisioning problem.

[44] Proposed the Slotted Hose model for traffic engineering and provisioning VPN

resources. The slotted Hose model is a bandwidth specification model in which 24 hours of a

day are divided into s-time slots and customer specifies required bandwidth within each time

slot. The authors were able to incorporate time discretization into hose model and varied the

bandwidth provided with time according to the customer’s specifications.

In [63] the authors realised that VPN endpoint had specified bounds on the total amount of

traffic that it is likely to send or receive at any time. Hence the need to tailor the available

bandwidth to sufficiently accommodate any traffic matrix that is consistent with these

bounds. Their approach was to develop and Ad-hoc on-demand Distance Vector (AODV)

protocol, with a view to accomplish an enhancement in the performance of the network. The

scheme was developed for both symmetric and asymmetric bandwidth requirements and was

designed to offer multipath routing and minimise the total cost of bandwidth reservation. The

proposed scheme is meant to handle constraints and accordingly rearrange the topology to

continue the process of data transmission.

[64] Proposed a distributed bandwidth resizing algorithms for optimizing inter-VPN and

intra-VPN bandwidth allocations. Their work was developed to increase the number of

connections possible and as well as increase the utilization of the system. The link bandwidth

or the bandwidth allocated to tunnels over the link was partitioned based on the user’s utility.

Any change in the users’ requirement was followed by a linear change in the partitioning

parameter (α). They hypothesised that the approach suggested in their work would enable

43
VPN service providers satisfy more number of users with a quality of service guarantee and

also at the same time improve their revenue.

[33] The authors developed what was described as the dynamic model of the synthesis of

peer to peer private network, by using a system of differential equations they described a

process of redistributing the bandwidth capacity available to a VPN service provider to

different VPNs. They also developed non-linear algebraic equations to describe the

congestion control and routing process that could provide QOS guarantees to both hose and

pipe models of VPNs. The scheme was proposed to dynamically manage the networks

resources, taking into account changes in the traffic. By predicting the traffic providing states

of the VPNs their model could reallocate resources to other users within the service provider

network.

In [65] Yongtao Wei et al presented the design and evaluation of a service prototype over a

virtual network, which provided a bandwidth guaranteed multi-path routing with a bandwidth

allocation algorithm. Their evaluation showed that the packet loss rate, throughput and

bandwidth utilization of traffic using BGMR, was much better than that of OSPF. Their

simulation experiments showed a massive increase in throughput with that of low loss

tolerance and resource utilization compared with that of the conventional routing protocol

OSPF.

[66] Deployed the Multi-commodity Flow Problem (MFP) solver to carry out bandwidth

allocation. In other to avoid producing bottleneck links, they employed traffic predictor to

ensure that any inaccuracy would cause the links not to have enough capacity and violate the

linear constraints on the commodities for each link is avoided. They proposed the L-PREDEC

for Forecasting Virtual Network dynamic link usage, while employing a linear predictor.

44
Traffic predictor adjusted the link with the largest occupation (bottleneck link) by

periodically monitoring the traffic rate of a user link and adjusting the reserved bandwidth

based on the Forecasting made from the traffic history.

the authors in [67] proposed a scheme for enhancing VPN QoS using a method called “Log-

infinitely Divisible Cascades”. They proposed that the scheme would enable Several VPN

traffic between two Provider Edge routers and of the tag stack using MPLS VPN data also

they allowed different transmission to share a LSP tunnel. The VPN multiplicity reduces the

signalling load and the scale of forwarding table of routers to bring high system scalability.

The authors of [68] used VPN traffic matrices measurements in provisioning and outlining

scalable techniques to compute traffic matrices. They arrived at traffic matrices with coarse-

grained Simple Network Management Protocol (SNMP) measurements of traffic aggregated

across VPNs in the core of the network which could be used for measurements with large-

scale service deployments. They found that Hub/Spoke VPNs formed a significant percentage

of the prevalent structures. They suggested temporal trends in customer traffic show stability

over periods of a few weeks to a month, thereby they proposed the feasibility of

measurement-based learning of traffic characteristics.

In [69], an MPLS based load balancing was proposed for VoIP flows. It was implemented

with an effective flow classification technique which prioritized the Voice packets based on

their flow arrival rate and bandwidth utilization using probing techniques, they were

differentiated as responsive, unresponsive and dataflow. Whenever the network experienced

unbalanced load conditions due to link failure or system failure in the IP network, default

routing policy would be overridden by multipath routing policy. The data rates of

unresponsive flow were estimated and marked based on their data rates using Rainbow Fair

45
Queuing (RFQ) mechanism. To perform multipath dispersion and alleviate the problem of

congestion, the core router looks for congestion free paths and reroutes the flows into best

multiple paths that satisfies the given QoS requirements. Otherwise, it dropped some of the

low priority packets from those unresponsive flows

[70] Considered Quality of Service (QoS) requirements of next generation IP- based

backbone networks for managing multiple VPN services offered by a VPN Service Provider.

In their paper, they proposed a programmable Tempest framework for Class of Service (CoS)

Based Resource Allocation (CBRA) in Multi-Protocol Label Switching (MPLS) tunnelled

VPNs. Switchlet based resource partitioning concept were used to create, build and provision

multiple VPNs on demand. Their approach was to provide overlay control architecture for

both intra- and inter-VPN resource allocations. The intra-VPN resource allocation was based

on Class of Service (CoS) arbitration using derived labels and derived Switchlets and inter-

VPN resource allocation was through Bandwidth Brokering (BB).

In [69], the linear predictors (AR and fARIMA) were evaluated for VPN dynamic link

resizing. Based on their experiments with linear and Gaussian predictors, the authors

proposed the L-PREDEC and showed that L-PREDEC predictor improved the response time

of the linear predictor based on the burstiness of the traffic. Their work was concentrated on

the edge of the QoS provided VPN, they proposed the prediction based algorithm could be

implemented at the interior routers of public networks. They showed that linear predictors

rely on the correlation structure of the time series. Since Xt and X t +1 were not correlated¿, then

X t +1 could not be predicted based on Xt. They used E(Xt) to solve for the linear predictor.

With non-linear traffic models and rule-based predictors, they were able to get better

estimates of time series that were not necessarily correlated but were still dependent. In

46
addition, they investigated possibilities of using linear prediction techniques for the

enhancement of distributed simulation systems and for improving the capability of intrusion

detection systems in properly classifying abnormal traffic patterns at the edge or core of

public networks. After assessing the use of linear traffic predictors to dynamically resize the

bandwidth of VPN links. They presented the results of performance comparisons of three

predictors: Gaussian, auto- regressive moving average (ARMA) and fractional auto-

regressive integrated moving average (fARIMA). Their comparisons were based on the mean

packet delay, the variance of the packet delay, and the buffer requirements. From the results

obtained from their tests, they proposed and evaluated a predictor for link resizing- linear

predictor with dynamic error compensation (L-PREDEC). They carried out a performance

tests which showed that L-PREDEC worked better than Gaussian, ARMA and fARIMA in

terms of the three metrics listed above.

In [71] Keng et al proposed the Virtual Network Service (VNS) as a value-added network

service for deploying virtual private networks (VPNs) in a managed wide-area IP network, it

provides VPN service that is customizable and supports VPN-level QoS. They set out to

achieve VPN support at the IP level for interoperability across multiple network technologies.

Second, they wanted VPNs to be provisioned very similar to physical networks by providing

the flexibility to use a variety of QoS models inside the VPNs. Finally, the ability to

customize the management and control functions of VPNs. The model proposed in the paper-

VNS was designed using IP tunnels and IP security as the basic VPN infrastructure. To

support the VPN isolation and customization that was needed to meet their goals, they used

three complementary mechanisms. An H-FSC scheduler provided bandwidth isolation

between VPNs and allowed each VPN to independently manage the bandwidth that was

assigned to it. Customization of control plane functionality was provided by using a

47
programmable router platform that supports the execution of third party control plane

protocols. The H-FSC scheduler already supports virtualization of resource allocation

(scheduling) while the authors also demonstrated the virtualization of packet forwarding.

[72] Proposed different formulations as well as efficient solution approaches for the VPN

design problem under traffic uncertainty with symmetric bandwidths. The paper dealt with

the polyhedral model of Ben-Ameur [41]which allowed the traffic vector to belong to a

polytope defined by some customer specific constraints. They proffered three different

formulations for the VPN design problem where the solution was allowed to be an arbitrary

sub graph. They further proposed a Column Generation and a Cutting Plane Algorithm to

solve these formulations efficiently.

The authors in [73] realized the growing need to schedule virtual network requests at future

time instants. Their work focused on optimization problems for virtual network scheduling

and compared the findings to some advanced heuristics. It also presented an optimization

model to schedule user requests in an on-line manner. They also proposed an advanced

heuristic strategy using re-routing strategies to improve request blocking. Results showed that

the optimization model provided slightly lower blocking and lower resource utilization, but

can only scale to relatively small scenarios.

[74] Presented a robust dynamic model, they formulated the VN dynamic bandwidth
provisioning as a robust optimization problem which periodically identifies bandwidth
allocation to VNs not minding traffic patterns over a period of time. They used a robust
optimization problem path-flow model for computing the minimum cost bandwidth allocation
and designed a distributed algorithm by the use of primal decomposition technique. A
distributed algorithm is proposed by using the primal decomposition method. The algorithm
through the coordination of the global coordinating algorithm operate in the network while
through the local adjusting algorithm operate in the individual virtual private networks
48
[75] Proposed a new fairness and bandwidth guarantee model for providing isolated network
service for tenants in a virtual network they proposed the Dynamic Bandwidth Allocation and
Guarantee for Virtualized Networks, they used a distributed architecture to realize the
bandwidth guarantee model by dynamically limiting the rate of each flow at the network
edge. The experiment result exhibited a better utilization and better response under traffic
burst. Stable and fair bandwidth allocation were obtained under different traffic patterns, and
revealed satisfying response time in dynamic traffic scenario.

2.10 CONCLUSION

Most dynamic VPN provisioning algorithms reviewed in this work showed a propensity to

work and improve the core network performances such as link setup time, link rerouting

parameters, hose optimisation etc. all within the core network. A few others only looked at

the traffic flow at the user-network interface especially the Provider Edge (PE) routers to

obtain flow parameters to help optimise the bandwidth utilization at network providers’ end.

Also some Dynamic resource allocation or scheduling algorithms were only interested in

scheduling access to the core network without considering the utilization of service

provider’s link cf. [58], [60], [61], For the purpose of this work and considering the

limitations mentioned above, the following QoS provisioning algorithms: Robust Dynamical

Virtual Network Provisioning (RDVNP) [76] and Dynamic bandWidth Allocation and

guarantee on Resource Fairness (DWARF-Net) [75] were selected to be investigated on as

they were deployed to improve KPI of the network provider and achieve SLA with the

customer. Since the aim of the work is to compare some network provider based performance

as well as a user or customer based QoS/performance parameter of the selected Dynamic

Resource allocation schemes based on results of simulation test runs and recommend to

researchers the scheme that has optimal performance against the rest based on performance

49
evaluation. The performance parameters investigated were channel utilization, buffer

utilization and loss rate.

50
 Chapter 3
3 MODELLING

Simulators have been developed for investigating resource allocation in VPNs, but they

generally tend to be complex, while simulators like Opnet (academic version) have already

built-in algorithms written in Proto-C[77] which cannot be modified when using an academic

license, this license also does not provide access to MPLS based systems like the MPLS

VPN. Other models designed in NS2 are written in C and C++ but unfortunately are not

available in the public domain while NS2 is a relatively complex simulator. Of the two

dynamic resource allocation schemes being compared, The Robust Dynamical Virtual

Network Provisioning (RDVNP) [74] was simulated using Sprint’s network topology

obtained from the Rocketfuel project, which is not open to the public. While [75] used

Huawei’s simulation laboratory to implement the DWARF-Net architecture upon which their

simulation was run. The above stated limitations made it difficult to implement the schemes

being compared on already existing models. In the cause of reviewing literature, none of the

literatures used had models built using Matlab Simulink despite its simplicity, flexibility and

ease of access.

The Matlab simulation model was validated by testing and comparing its performance against

the experiment evaluation carried out in [75] to determine utilization of the link when two

nodes are transmitting through the link at the same time while varying the link bandwidth

allocated. The results for average utilization from 12 simulations for each allocated

bandwidth.

51
3.1 ROBUST DYNAMICAL VIRTUAL NETWORK PROVISIONING

(RDVNP)

The Virtual network was represented by an undirected graph G (V, E), where V and E are the

set of substrate nodes and the set of physical links, respectively. It was assumed that k

number of VPNs co-existed on the substrate network [74]

A set of k VPN was represented by a set of virtual links, denoted by

E(k)={ ( s(1k ) , t (1k ) ) , … , ( s(lkk ) , t (lkk ) ) } 3.1

Where (s, t) is a virtual link connecting node s and t, and lk is the number of virtual links of

the k-th VPN.

Let S(k) denote the set of nodes of the k-th VPN, By using the hose model constraints, all the

virtual links connected to the node i will have an upper bound bandwidth constraint of β(ki ) for

the k-th VPN. Therefore the traffic demands of the k-th VPN from the link is dij(k)

∑ (k ) (k )
d ij ≤ β i , ∀ i ∈ S 3.2
(k)

∀ ( i ,i ) V (i , j)∈E( k)

(k )
β i =μ ∑ (k)
α ij 3.3
(i , j)∈E( k)

(k )
Where α ij is the upper bound of the traffic demand of virtual links. And μ can be adjusted

from 0 to 1but was set as 0.8 for optimal performance in [74].

52
 ( k)
If c l is the allocated bandwidth to link l

(k)
And v l is the link weight of a node in the VPN.

The algorithm for the dynamic bandwidth allocation system is shown below

1. Given c (lk ) , ∀ l∈ E for each VPN

( k)
2. v(k) (k)
l ← cl −θ i ∙ λi ;

(k )
3. send v l , ∀ l∈ E , ¿ the global coordinating algorithm ;

(k )
4. wait for receiving c l , ¿ the coordinating algorithm ;

(k)
5. Receive v l , ∀ l ∈ E ¿ each VPN

6. Solve min ¿ ∀ l∈ E

7. For ∀ k , send bandwidth c (lk ) , ∀ l∈ E ,¿ the k −th VPN

3.2 DYNAMIC BANDWIDTH ALLOCATION AND GUARANTEE ON

RESOURCE FAIRNESS (DWARF-NET)

Proposed in [75], the bandwidth allocated to each VPN is guaranteed by rate limiting of other
VPN connections, this algorithm allows busy VPN traffic to take more bandwidth beyond its
guaranteed bandwidth by "borrowing" the underutilized bandwidth from idle VPNs, thus
better bandwidth utilization can be achieved. Such extra bandwidth, i.e., bandwidth allocated
beyond the guaranteed bandwidth, would be fairly allocated among virtual Ports or VPN
connections from different tenants with the weight proportional to the guaranteed bandwidth
they purchased. Although the algorithm was designed for both traffic transmitted from the
sites into the network and for traffic received from the network only the algorithm for
transmitted traffic was used for this work. The work was modelled to satisfy Pareto

53
Efficiency, i.e. when there is enough free bandwidth, any machine sharing the bandwidth
could be able to use it by exceeding its own SLA:

∑ t ij ≥ B ⟹ ∑ bij =ηB 3.4

i ∈host k i∈host k

Where η is the overall bandwidth utilization∧B istotal bandwidth of the link

∀ i, j ∑ t ij ≥ A i ⟹ ∑ bij ≥ A i 3.5
t t

j ≠i j ≠i

∑ A ti ≤ B k 3.6
i ∈host k

∀ i, ∑ Gij ≤ Ai 3.7
t

j ≠i

Ti represents the traffic sending request of VPN i, based on the model above,

T i=∑ b ij
j ≠i

Table 3.2: Model Formula Descriptor

tij Traffic sending request from VPN i to j
Ui Upper bound bandwidth for VPN i

Bk Total bandwidth shared in the host k

Ait Tx Access bandwidth guarantee for VPN i

Gij Pair Bandwidth guarantee from i to j

Ti Traffic sending request of VPN i

The algorithm of the Dynamic bandWidth Allocation and guarantee on Resource Fairness

(DWARF-NET) has an output of Lti as the rate limit of each VPN queue.

54
Algorithm

1. ∀ i∈ Host K k do

2. If Ti <= Gi then

3. ɑi←αTi +δ

4. else

5. ɑi←Ti

6. end if

7. end for

8. Bspare ← B−∑ a i
i

9. Bexcess ← ∑ T i−Gi
Ti<Gi

10. For all i∈Hostk do

11. if Ti<=Gi then

t
12. Li ← G i

13. else

14. max ⁡¿
t
15. Li ← max ⁡¿

16. End if

17. End for

18. Return Lti

3.3 NETWORK ARCHITECTURE

For the sake of this work some assumptions are made for the network architecture;

55
 There are three different VPNS connected to the service provider edge router, which has

a leased link through the network provider’s network.

That these VPNS are connected to their other site at another end through a provider edge

router as seen in fig 3.1 below.

The VPNs are not just work stations, but can contain several workstations and servers for

database, mail, ftp, HTTP and voice traffic. But for the sake of this research, only one

provider edge router will be considered as MPLS creates links or LSPs in one direction.

Figure 3.11: Network architecture

56
The above network architecture was implemented in MATLAB Simulink, the model created

focused on the Edge router at node 2.

3.4 PHYSICAL MODEL

Figure 3.12: VPN Scheduler Architecture

The physical model explains the interface at which the resource allocation schemes being

compared are deployed. A brief description of each block is provided below:

1. Admission control: this interface selects which node is served at a particular time (t).

2. Packet classifier: packets are distinguished in order of their priority and sent to their

different queues

3. Buffers: the buffers queue the packets according to their different priorities, Note

higher priority packets have shorter queues while lower priority packets have longer

queues.

4. Metering phase: Calculates the difference between the incoming packets and the

served packets and also determines the bandwidth to be reserved in the core network.

5. Scheduler: this is where the algorithm for the schemes being compared are

implemented in the form of MATLAB codes.

57
 6. Egress port is the external channel to the core network.

3.5 SIMULATION VALIDATION

The MATLAB simulation model was validated by testing and comparing its performance

against the experiment evaluation carried out in [75] to determine utilization of the link when

two nodes are transmitting through the link at the same time while varying the link bandwidth

allocated. The results for average utilization from 12 simulations for each allocated

bandwidth were obtained and compared in the chart below.

80

70

60
average utilization

50

40
DWARF-NET Test
30 Matlab Simulation

20

10

0
1Mb/s 2Mb/s 3Mb/s 4Mb/s 5Mb/s 6Mb/s
Allocated bandwidth

Figure 3.13: Model Validation of the Matlab simulator using Dynamic Bandwidth Allocation
and Guarantee for Virtualized Network algorithm

The chart shows that the performance of the MATLAB simulation model in this work and

that obtained from the test in [75] are very close as the average value for 68.35717903 was

obtained for the Matlab simulation model developed in this work, while the test run on the

Dynamic Bandwidth Allocation & Guarantee for Virtualized Networks model produced and

average of 68.80 with only a 0.643635131% error the MATLAB simulation model in this

work can be assumed valid for simulating similar VPN scenarios.

58
59
 Chapter 4
4 SIMULATION

4.1 MATLAB SIMULATION

The design for the Matlab simulation model in is seen in figure 4.1 below

Figure 4.14 Matlab simulation Model for MPLS-VPN

The model for this work has three VPNS populating the model with traffic, the design is
scalable and can handle numerous VPNS. Each VPN has three traffic sources generating
voice, video and best-effort packets. The makeup of the VPN subsystem is shown in fig 4.2
below

60
 Figure .: VPN Subsystem

The traffic source subsystems are all the same except for the parameters controlling attributes
and priority of traffic from the sources. Voice was allotted a highest priority and an attribute
value of 0.5, video was 0.3 and Best-effort was assigned 0.2. The figure 4.3 below shows the
Markov-modulated Poisson traffic generator, the intergeneration time for the generator is set
from a data store outside the subsystem.

Figure 4.15 Traffic Source for VPN

Packets generated from the traffic source is arranged, counted and the attribute of individual

entities are collated and statistics from this subsystem such as packet count and the entity

attributes are used as input for the scheduler.

61
Figure 4.16 Traffic collation and Buffer subsystem

The scheduler subsystem is made up of an embedded Matlab function block which contains
the codes that run the scheduler using metrics and statistics from other blocks, these statistics
include occupancy of the server and server utilization, QOS of the traffic flow, total available
bandwidth and the total QoS requirements of the traffic flow.

Figure 4.17 Scheduler Subsystem with Matlab function block

4.2 RESULT

Twelve simulations were carried out with 12 different mean (i.e. intergeneration time for time
based entity generator). The needed parameters were sent to Matlab workspace from where
the mean of the generated parameters were obtained for each intergeneration time used.

62
The chart in Fig 4.6 shows the relationship between intergeneration time with Packet
generation rate. Intergeneration time and packet generation exhibit an inverse relationship,
hence the lower the intergeneration time the higher the packet rate from the generators.

0.14

0.12
Intergeneration time-mean(seconds)

0.1

0.08

0.06

0.04

0.02

0
0 5000 10000 15000 20000 25000
Traffic generation rate (Packets/seconds)

Figure 4.18: Chart of Packet generation against Intergeneration time

The parameters needed were Link utilization which is a statistic already available from the
server block, packet arrival rate from the blocks, buffer utilization which was calculated as:

Number of packet ∈buffer

Buffer Utilization= * 100
Total buffer ¿ ¿ ¿

While loss rate was derived from the Simulink blocks, the number of dropped or timed out
packets was divided by simulation time and sent to workspace. As packet generation rate
increased, as described in Fig 4.6, the utilization of both RDVNP and DWARF-Net
increased, this is seen in Fig 4.7. While DWARF-NET algorithm peaked faster than the
RDVNP algorithm. From the channel utilization chart, the Performance of the DWARF-NET
algorithm is seen to be superior to the Robust Dynamical Virtual Network Provisioning
(RDVNP) algorithm by a factor of 21.15% meaning DWARF-Net has improved bandwidth
utilisation.

63
 100
90
Robust Dynamic Virtual
80 Network Provisioning
(RDVNP)

Average Link Utilization (%)

70
60 DWARF-NET
50
40
30
20
10
0
01 25 25 05 1 2 4 8 6 2 4 8
00 01 00 00 00 00 00 00 01 03 06 12
0. 0 0 . 0. 0. 0. 0. 0. 0. 0. 0.
0.
0 0. 0

Intergeneration time (s)

Figure 4.19: Link Bandwidth Utilization Chart of RDVNP against DWARF-Net

The buffer utilization for the two algorithms is represented in the chart of 4.7 below. The
chart confirms that for some values of intergeneration time the RDVNP performed better than
the DWARF-NET, but averagely the DWARF-Net outperformed the RDVNP by a factor of
1.45%. It is safe to infer that RDVNP sacrifices link utilization for better buffer utilization
when there is a packet flood in the system.

100
90 Robust Dynamic Virtual
Network Provisioning
80 (RDVNP)
70
DWARF-NET
Buffer Utilization (%)

60
50
40
30
20
10
0
01 5 5 5 1 2 4 8 6 2 4 8
00 12 02 00 00 00 00 00 01 03 06 12
. 0 0 .0 0. 0. 0. 0. 0. 0. 0. 0.
0 00 0.
0 0
0.
Intergeneration time (Seconds)

Figure 4.20 Buffer Utilization Chart of RDVNP against DWARF-Net

64
The chart in Fig 4.9 shows that RDVNP algorithm has a very high loss rate compared to
DWARF-Net which had a loss rate lower by 95.05%.

60

50
Robust Dynamic Virtual
Network Provisioning
Loss Rate (Packets/seconds)

40 (RDVNP)

30 DWARF-NET

20

10

0
01 5 5 5 1 2 4 8 6 2 4 8
00 12 02 00 00 00 00 00 01 03 06 12
. 0 0 .0 0. 0. 0. 0. 0. 0. 0. 0.
0 00 0.
0 0
0.
Intergeneration time (Seconds)

Figure 4.21: Loss Rate Chart for RDVNP against DWARF-Net

65
 Chapter 5
5 CONCLUSION

As start-ups blossom into enterprises, there is need to have dispersed sites connected together

in private networks to enable secure communication between staff who work remotely and

the office, different sites of the same enterprise (site to site) and extranet based connections

i.e. some third party connecting to the network. Due to the outrageous cost of building

networks ground-up, network administrators must be able to intelligently use public network

resources while preserving the security of data as well as ensure prudent management of

resources at the network edge. As the trend towards Next Generation Networks (NGN) and

Software Defined Network SDN there is need to have scheduling schemes whose metrics

points towards optimal performances for provisioning VPN QoS. This work has succeeded in

providing a simulation model that researchers can use in analysing Virtual Private Networks.

The model was used to investigate the performances of two VPN resource scheduling and

allocation schemes by varying the traffic generated and obtaining results with respect to Link

utilization, Buffer utilization and packet loss rate. Some conclusion from the investigation are

summarised below:

Link Utilization

Link utilization increased with more packet traffic in the network but was limited by the

scheduling algorithm from reaching optimal level, this was likely due to delay in executing

the algorithm. But the DWARF-Net algorithm provided more utilization against all other

algorithms.

Buffer Utilization

Buffer utilization increased with increase in packet generation.

66
 Loss Rate

Loss rate increased with packet generation but also lower losses were experienced in

DWARF-Net due to the higher utilization of the link and buffer.

5.1 RECOMMENDATIONS

By calculating the rate of packet generation that corresponds to highest possible utilization

and the point where the lowest loss occurs at the highest utilization, it will be savvy to create

partitions of resources in nodes corresponding to a bandwidth that can accommodate the

packet rate calculated above. This will greatly reduce the loss rate and keep loss rate below a

certain (constant) maximum level.

5.2 CONTRIBUTIONS

The major contributions of this work are

Provision of a model that can be used to analyse any VPN at the customer/service

provider interface

Results of the Investigations carried out was used to make recommendation to

researchers to help focus study on resource allocation schemes that provide optimal

utilization of resources as well as having the lowest loss rate.

The result of this analysis suggests that efficiency of resource allocation schemes go a

long way in improving network and user Key Performance Indices (KPI)

67
5.3 FURTHER WORK

Although delay was used to determine loss and cause packet loss in this model, there could

be further investigation on how to improve Buffer utilization in the DWARF-Net scheme

especially when packet generation becomes large.

Also todays network are becoming wireless and supporting wireless users. WiMAX and LTE

are becoming the mainstay of wireless technology and MPLS is finding a niche in these novel

systems[78], there is need to investigate the efficacy of using DWARF-Net algorithm as a

resource allocation scheme alongside the Matlab simulation model developed in this work for

WiMAX and LTE networks.

68
6 REFERENCES

[1] G. F. Italiano, R. Rastogi, and B. Yener, “Restoration algorithms for Virtual Private
Networks in the Hose Model,” Proceedings.Twenty-First Annu. Jt. Conf. IEEE
Comput. Commun. Soc., vol. 1, no. 4, pp. 565–578, 2002.

[2] C. Scott, P. Wolfe, M. Erwin, and A. Tunnel, Virtual Private Networks , Second
Edition, 2nd ed. Sebastopol: O’Reilly.

[3] Cisco systems, Advanced MPLS VPN Solutions, vol. 1. 2000.

[4] M. Ahmed and A. Basit, “QoS in MPLS VPN Based IP Backbone,” vol. 5, no. 6,
2014.

[5] Y. Zou, Z. Mi, and X. Meng, “A Genetic Algorithm for Optimization of Bandwidth
Assignment in Hose-Modeled VPN,” no. 60472105, pp. 315–323, 2006.

[6] Cisco Systems, “Advanced Topics in MPLS-TE Deployment,” 2009.

[7] E. Osborne and A. Simha, Traffic Engineering with MPLS. Indianapolis: Cisco Press,
2003.

[8] D. Andersen, “Lecture 8 Virtual Circuits , ATM , MPLS Exam stats,” 2006.

[9] V. Alwayn, Advanced MPLS Design and Implementation. Indianapolis, 2002.

[10] S. Ali and S. Ali, “OPNET Analysis of VoIP over MPLS VPN with IP QoS,” 2011.

[11] R. Callon, E. C. Rosen, and A. Viswanathan, “RFC-3031 Multiprotocol Label

Switching Architecture,” 2001.

[12] W. Stallings, “MPLS - The Internet Protocol Journal - Volume 4, Number 3.”
[Online]. Available:
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_4-3/mpls.html.
[Accessed: 18-Sep-2015].

[13] C. Barbiran, “Multiprotocol Label Switching (MPLS),” 2002. [Online]. Available:

http://services.eng.uts.edu.au/~kumbes/ra/Emerging/MPLS/MPLS.htm. [Accessed: 18-
Sep-2015].

[14] B. Morgan and N. Lovering, CCNP ISCW Official Exam Certification Guide.
Indianapolis, 2008.

[15] I. Pepelnjak and J. Guichard, MPLS and VPN Architectures. .

[16] L. De Ghein, MPLS Fundamentals. Indianapolis: Cisco Press, 2006.

69
[17] S. Jose, “Cisco Active Network Abstraction 3 . 7,” no. 6387, 2010.

[18] B. S. Davie and A. Farrel, MPLS: Next steps, Second. Burlington: Morgan Kaufmann
Publishers, 2008.

[19] Behrouz A. Forouzan, Data Communication and Networking, Fourth Edi. New York:
McGraw-Hill.

[20] X. Xiao, A. Hannan, B. Bailey, and L. M. Ni, “Traffic Engineering with MPLS in the
Internet,” pp. 1–14.

[21] R. M.A., K. A.H., L. K.A.M., H. M.Z., and A. M.R., “Performance analysis and the
study of the behavior of MPLS protocols,” in International Conference on Computer
and Communication Engineering ICCCE, pp. 226–229.

[22] H. Hodzic and Sladjana, “Traffic Engineering with Constraint Based Routing,” in
Zoric 50th International Symposium ELMAR-2008, 2008, pp. 10–12.

[23] Y. Rekhter, “BGP/MPLS VPNs,” 1999.

[24] K. Jannu and R. Deekonda, “OPNET simulation of voice over MPLS,” Blekinge
Institute of Technology, 2010.

[25] J. Evans and C. Filsfils, Deploying IP and MPLS QOS for Multiservice Networks:
Theory and Practice. San Francisco: Elsevier Inc, 2007.

[26] C. Lewis, S. Pickavance, M. Morrow, J. Monaghan, and C. Huegen, Selecting MPLS

VPN Services. Cisco Press, 2006.

[27] S. Fowler and S. Zeadally, “Priority-Based Congestion Control in MPLS-based

Networks,” vol. 48202, pp. 0–5, 2005.

[28] N. Saxena, “DIT - University of Trento A FRAMEWORK FOR DYNAMIC HYBRID

SCHEDULING STRATEGIES IN HETEROGENEOUS ASYMMETRIC,” no.
February, 2005.

[29] R. Ravi, S. Radhakrishnan, A. Nagar, V. District, and T. N. State, “Provisioning QoS

in Virtual Private Network using Dynamic Scheduling Department of Computer
Sciences and Engineering , Department of Computer Sciences and Engineering , A .
K . College of Engineering ,” J. Comput. Sci., vol. 4, no. 1, pp. 1–5, 2008.

[30] M. Christian, E. Dotaro, and D. Papadimitriou, “A Practical Approach to VPN

Resource Management using a Dynamic Hose Model.”

[31] B. Thabti, H. Yousse, A. Meddeb, and R. Mahjoub, “Evolutionary algorithm for

provisioning VPN trees based on pipe and hose workload models,” Proc. - 2011 7th
Int. Conf. Nat. Comput. ICNC 2011, vol. 4, pp. 2058–2064, 2011.

70
[32] B. Thabti, “From Constant Traffic Matrices to Hose Workload Model for VPN Tree
Design,” 2012.

[33] Д. М. Синтеза, В. Л. С. Терин, А. С. Е. Ременко, and Т. А. Н. Адия,

“ОДНОРАНГОВОЙ ВИРТУАЛЬНОЙ ЧАСТНОЙ СЕТИ,” http://pt.journal.kh.ua,
vol. 3, no. 15, pp. 12–29, 2014.

[34] N. G. Duffield, P. Goyal, A. Greenberg, P. Mishra, K. K. Ramakrishnan, and J. E. Van

Der Merwe, “Resource management with hoses: Point-to-cloud services for virtual
private networks,” IEEE/ACM Trans. Netw., vol. 10, no. 5, pp. 679–692, 2002.

[35] N. G. Duffield, P. Goyal, A. Greenberg, P. Mishra, K. K. Ramakrishnan, and J. E. van

der Merive, “A flexible model for resource management in virtual private networks,”
ACM SIGCOMM Comput. Commun. Rev., vol. 29, no. 4, pp. 95–108, 1999.

[36] G. S. Poo and H. Wang, “Multi-path routing versus tree routing for VPN bandwidth
provisioning in the hose model,” Comput. Networks, vol. 51, no. 6, pp. 1725–1743,
2007.

[37] W. Dong, “PROVIDING GUARANTEED QOS IN THE HOSE-MODELED VPN,”

New Jersey Institute of Technology, 2004.

[38] N.-E. Rikli and S. Almogari, “Efficient priority schemes for the provision of end-to-
end quality of service for multimedia traffic over MPLS VPN networks,” J. King Saud
Univ. - Comput. Inf. Sci., vol. 25, no. 1, pp. 89–98, 2012.

[39] A. Kumar, R. Rastogi, A. Silberschatz, and B. Yener, “Algorithms for provisioning

virtual private networks in the hose model,” IEEE/ACM Trans. Netw., vol. 10, no. 4,
pp. 565–578, 2002.

[40] A. Fabienne, “Network virtualization : performance , sharing and applications,” 2013.

[41] W. Ben-ameur and H. KERIVIN, “Routing of Uncertain Traffic Demands ∗,”

Springer Sci., no. 6, pp. 283–313, 2005.

[42] Z. Ma, “Multipath Resource Management in Overlay Networks Multipath Resource

Management in Overlay Networks Dissertation Director : Arvind Krishnamurthy.”

[43] M. Carugi and D. McDysan, “Service Requirements for Layer 3 Provider Provisioned
Virtual Private Networks (PPVPNs),” 2005.

[44] Y. L. Liu and Y. T. Chin, “Traffic engineering for provisioning VPNs with time-
varying bandwidth requirements,” ICEIE 2010 - 2010 Int. Conf. Electron. Inf. Eng.
Proc., vol. 2, no. Iceie, pp. 309–313, 2010.

[45] D. Mariz, J. Kelner, D. Sadok, and C. a Kamienski, “The Accurate Hose Model for
VPN Provisioning.”

71
[46] Y. Liu, Y. S. Sun, and M. C. Chen, “MTRA : An on-line hose-model VPN
provisioning algorithm,” telecommun syst, pp. 379–398, 2006.

[47] D. Wei and N. Ansari, “Implementing fair bandwidth allocation schemes in hose-
modelled VPN,” IEE Proc.-Commun, vol. 151, no. 6, pp. 521–528, 2004.

[48] J. Alpar, S. Istvan, and S. Aron, “On Bandwidth Efficiency of the Hose Resource
Management Model in Virtual Private Networks,” IEEE INFOCOM 2003. Twenty-
second Annu. Jt. Conf. IEEE Comput. Commun. Soc. (IEEE Cat. No.03CH37428), vol.
02, no. C, 2003.

[49] N. Rikli, “Evaluation of End-to-End Quality of Service over VPN Networks through
Various Priority Mechanisms,” no. c, pp. 145–149, 2011.

[50] J. Chu and C. Lea, “A restorable MPLS-based hose-model VPN network,” vol. 51, pp.
4836–4848, 2007.

[51] W. Dong and A. Nirwan, “Implementing fair bandwidth allocation schemes in hose-
modelled VPN Implementing fair bandwidth allocation schemes in,” IEE Proc., vol.
151, no. 6, pp. 521–528, 2004.

[52] G. De Veciana, S. Park, A. Sang, and S. Weber, “Routing and Provisioning VPNs
based on Hose Traffic Models and / or Constraints .”

[53] Y. L. Liu, Y. S. Sun, and M. C. Chen, “Traffic engineering for provisioning restorable
hose-model VPNs,” 2006 2nd Conf. Next Gener. Internet Des. Eng. NGI 2006, pp.
139–146, 2006.

[54] H. Byun and M. Lee, “Extensions to P2MP RSVP-TE for VPN-specific state
provisioning with fair resource sharing,” Comput. Commun., vol. 30, no. 18, pp. 3736–
3745, 2007.

[55] M. Christian, E. Dotaro, and D. Papadimitriou, “A Practical Approach to VPN

Resource Management using a Dynamic Hose Model,” vol. 00, no. c, pp. 147–153,
2006.

[56] J. Chu and C. T. Lea, “Optimal link weights for IP-based networks supporting hose-
model VPNs,” IEEE/ACM Trans. Netw., vol. 17, no. 3, pp. 778–788, 2009.

[57] Y. Jia, M. L. Guerrero, O. Kabranov, D. Makrakis, and L. O. Barbosa, “Dynamic

resource allocation in QoS-enabled/MPLS supported virtual private networks and its
Linux based implementation,” Can. Conf. Electr. Comput. Eng., vol. 3, no. 02, pp.
1448–1454, 2002.

[58] T. Erlebach and M. Rüegg, “Optimal bandwidth reservation in hose-model VPNs with
multi-path routing,” Proc. - IEEE INFOCOM, vol. 4, no. C, pp. 2275–2282, 2004.

72
[59] S. Raghunath and S. Kalyanaraman, “Statistical Point-to-Set Edge-Based Quality of
Service Provisioning,” vol. 1, pp. 132–141, 2003.

[60] R. Volner and V. Smrž, “Virtual Private Networks – Based Home System,” vol. 8, no.
8, pp. 8–10, 2009.

[61] M. E. L. Hachimi, M.-A. Breton, and M. Bennani, “Efficient QoS implementation for
MPLS VPN,” pp. 259–263, 2008.

[62] V. Rakocevic, J. M. Griffiths, and G. Cope, “Dynamic Partitioning of Link Bandwidth

in IPMPLS Networks,” pp. 2918–2922.

[63] M. C. Natarajan, R. Muthiah, and A. Nachiappan, “Performance Investigation of

Virtual Private Networks with Different Bandwidth Allocations,” vol. 7, no. 1, pp. 58–
63, 2010.

[64] C. Hota, S. Jha, and G. Raghurama, “ADAPTIVE BANDWIDTH MANAGEMENT

AND QoS PROVISIONING IN IPVPNs,” vol. 30, no. 2, 2008.

[65] Y. Wei, J. Wang, and C. Wang, “Bandwidth Guaranteed Multi-path Routing as a

Service over a Virtual Network,” in First International Workshop on Intelligent
Networks and Intelligent Systems, 2008, pp. 221–224.

[66] Y. Wei, J. Wang, and C. Wang, “Bandwidth Allocation in Virtual Network Based on
Traffic Prediction,” in 2010 International Conference On Computer Design And
Appliations (ICCDA 2010), 2010, vol. 5, no. Iccda, pp. 304–307.

[67] F. A. N. Ya-qin, W. Lin-zhu, and Z. Li-cui, “Research for QoS of MPLS VPN based
on Log-infinitely Divisible Cascades,” pp. 461–464, 2008.

[68] S. Raghunath and K. K. Ramakrishnan, “Resource Management for Virtual Private

Networks,” pp. 1–11.

[69] W. Cui and M. A. Bassiouni, “Virtual private network bandwidth management with
traffic Prediction,” Elsevier-Computer Networks, vol. 42, pp. 765–778, 2003.

[70] P. Kumar, N. Dhanakoti, S. Gopalan, and S. V., “CoS Based Resource Allocation in
VPNs over MPLS,” IEEE, vol. 4, no. 4, pp. 140–145, 2004.

[71] L. K. Lim, J. Gao, T. S. E. Ng, P. R. Chandra, P. Steenkiste, and H. Zhang,

“Customizable virtual private network service with QoS,” vol. 36, pp. 137–151, 2001.

[72] A. Altın, E. Amaldi, P. Belotti, and M. C. Pınar, “Virtual Private Network Design
Under Traffic Uncertainty,” Elsevier-Electronic Notes Discret. Math., vol. 17, pp. 19–
22, 2004.

[73] H. Bai, F. Gu, J. Crichignoi, S. Khan, and N. Ghani, “Virtual Network Scheduling
Design,” pp. 1–6.

73
 Virtual Network Provisioning ∗,” vol. 22, no. 1, 2013.
[74] Z. Min, W. U. Chunming, H. Yue, Y. Qiang, W. Bin, and J. Ming, “Robust Dynamical

[75] J. Wang, “Dynamic Bandwidth Allocation & Guarantee for Virtualized Networks in
Cloud,” 2013.

[76] L. Tan, P. Yang, W. Zhang, and F. Ge, “On utility-optimised router-level bandwidth
allocation,” Trans. Emerg. Telecommun. Technol., 2012.

[77] Z. Lu and H. Yang, Unlocking the Power of OPNET Modeler. 1994.

[78] C. Liang and F. R. Yu, “Wireless Network Virtualization : A Survey , Some Research
Issues and Challenges,” no. c, pp. 1–24, 2014.

74