International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084 Volume-3, Issue-4, April-2015

Qos PROVISIONING FOR MULTIMEDIA TRAFFIC ON MPLS VPN

WITH TRAFFIC ENGINEERING
1
LOGESH K, 2Dr. T.P. SARAVANABAVA
1
M.E SEOR, Ramanujan Computing Center, Anna University, Chennai 600 025
2
Professor, Ramanujan Computing Center, Anna University, Chennai 600 025
Email: 1logesh123@gmail.com, 2tpsbava@yahoo.co.uk

Abstract: Multi-Protocol Label Switching (MPLS) is considered as a good packet switching technology that
ensures the Quality of Service (QoS) useful for multimedia applications, reliability and efficient use of network
resources. Virtual Private Networks (VPNs) provide customers with predictable and secure network connections
over a shared network with the concern to address the QoS and security issues associated with deployment.
Hence the combination of VPN over MPLS will provision the QoS for the Multimedia traffic to the end
customers. We propose here the RSVP based resource reservation technique along with the MPLS-VPN
architecture to achieve better bandwidth utilization, low delay and packet drop. The Simulation Results have
shown the better performance of the proposed approach.

Keywords: Qos; MPLS; RSVP.

I. INTRODUCTION Each MPLS packet has a header. In a non ATM

1.1. MPLS Overview
Multi-Protocol Label Switching (MPLS) is a
protocol introduced as a synthesis of many ideas to
form a fast and controllable structure in IP backbone.
MPLS is a high performance method used to transmit
packets over the network. The labels of MPLS which
are short, which have fixed lengths and which can be
easily transmitted, make the promotion of IP packet
headers in easier way [1]. MPLS integrates a label
swapping framework with network layer routing. Its
basic idea involves assigning short fixed length labels
to packets at the ingress to the MPLS cloud (based on
the concept of forwarding equivalence classes) and
making forwarding decisions according to the labels
attached to packets throughout the interior of the
MPLS domain [2].
1.2. MPLS Network
MPLS is a protocol-agnostic mechanism for
transporting data using either a connection oriented
approach (based on MPLS plus RSVP) or
connectionless (IP/MPLS with LDP (Label
Distribution Protocol)). MPLS has been standardized
by the IETF, and has been designed to carry both
circuit and packet traffic over virtual circuits known as
LSPs (Label Switched Path). It makes forwarding
decisions using labels that are added (and removed) by
the MPLS routers. This means it can act as a single
transport mechanism for many different kind of
traffic. ATM, Ethernet, IP and TDM traffic can all be
carried, and can use connection oriented mechanisms
to ensure circuit-switched traffic can be delivered
across a packet core [15].
environment, the header contains a 20-bit label, a 3-bit
Experimental field (formerly known as Class of
Service, or CoS field), a 1-bit label stack indicator and
an 8-bit TTL field. In a ATM environment, the header
contains only a label encoded in the VCI/VPI field.
An MPLS capable router, termed Label Switching
Router (LSR), examines the label and possibly the
experimental field in forwarding the packet.
Constraint Based Routing (CBR) computes routes
that are subject to constraints such as bandwidth and
administrative policy. Because Constraint Based
Routing considers more metrics than network
topology alone in computing routes, it may find a
longer but lightly loaded path better than heavily
loaded shortest path. Network traffic is hence
distributed more evenly. Constraint Based Routing
can be online or offline. With online Constraint Based
Routing, routers may compute paths for LSPs (Label
Switched Paths) at any time. With offline Constraint
Based Routing, an offline server computes paths for
LSP’s periodically (hourly / daily). LSPs are then
configured to take the computed paths.
Online Constraint-based Routing will compute
paths for the LSPs such that for every link, the
maximum reservable bandwidth of the link is greater
than or equal to the sum of the specified bandwidth of
all LSPs traversing the link. Under this premise,
whether high utilization will occur in a link depends
on how close the total actual traffic rate of all the
LSPs matches the total specified bandwidth, high
utilization may occur in the link [5].
1.3. Traffic Engineering in MPLS Network
Traffic Engineering (TE) is essential for
service provider backbone networks. Such backbones
must support a high use of transmission capacity, and
the network must be very resilient, so that they can
withstand link or node failures. MPLS traffic

QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering

51
International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084
engineering provides an integrated approach to traffic
engineering. With MPLS, traffic engineering
capabilities are integrated into Layer-3 (Network),
which optimizes the routing to IP traffic, given the
constraints imposed by backbone capacity and
topology
MPLS Traffic Engineering [4]:
 Enhances standard IGPs, such as IS-IS or
OSPF, to automatically map packets onto
the traffic flows
 Transports traffic flows across a network
using MPLS forwarding
 Determine the routes for traffic flows across
a network based on the resources the traffic
flow requires and the resources available in
the network.
 Employs “Constraint Based Routing” in
which the path for a traffic flow is the
shortest path that meets the resource
requirements (constraints) of the traffic
flow. In MPLS Traffic Engineering, the
traffic flow has bandwidth requirements,
media requirements, a priority versus other
flow, and so on
 Recovers to link or node failures that change
the topology of the backbone by adapting to
a new set of constraints [4].
II. RELATED WORK
Xipeng Xiao [5] has proposed a procedure for
deploying MPLS system. In their research they have
discussed traffic engineering with Multi-Protocol
Label Switching in an Internet Service provider
network. They have reviewed MPLS, Constraint
based routing and enhanced link state Interior gateway
protocols to provide background for traffic
engineering and also they have discussed ways to
provide quality of service in a network with MPLS.
Mingui Zhang [6] have formulated the traffic
engineering problem as a Multi commodity flow
problem with hybrid MPLS/OSPF routing (MCFTE).
As a result, the majority of the traffic is routed by
regular OSPF, while only a small number of MPLS
tunnels are needed to fine-tune the traffic distribution.
It keeps OSPF link weights unchanged to avoid
triggering network convergence, and needs far fewer
MPLS tunnels than the full mesh to adjust traffic.
Compared with existing hybrid routing approaches
MCFTE achieves the optimal link utilization, runs
about two orders of magnitude faster and is more
robust against measurement inaccuracy in traffic
demand.
R. Boutaba [7] have proposed DORA, a dynamic
online routing algorithm for construction of
bandwidth guaranteed paths in MPLS-enabled
networks. The main objective of DORA is to place
paths with reserved bandwidth evenly across the
network in order to allow more future paths to be
QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering
52
Volume-3, Issue-4, April-2015
accepted into the network and to balance the traffic
load. During path computation, the key operation in
DORA is to avoid routing over links that have (1)
high potential to be part of any other path, and (2) low
residual bandwidth available.
Rong Xu [9] have presented a novel
approach integrating recent advances in MPLS traffic
engineering with wavelength switch routing
technologies to achieve optical interconnect for IP-
centric data networks. New node architecture for
scalable wavelength label switching networks
(WLSNet) is proposed, which supported label
switching and wavelength routing. Their research
showed that network adds more flexible routing,
traffic engineering, and explicit routes via MPLS, is
the best way to realize optical interconnects and to
reduce management complication and cost of
network. They have showed an approach to
dynamically interconnect routers via wavelength,
including a bypass routing in the node, by this way
new wavelengths may easily be introduced to the
network at a reasonable cost.
Nasser-Eddine Rikli, Saad Almogari [10]
has done the simulation on the MPLS VPN network
using NS2 with various queuing policies to evaluate
the provisioning of the end to end QoS requirements
for multimedia traffic. After simulation, effect on the
multimedia traffic QoS after the deployment of the
various queuing policies, merits / shortcomings has
been compared
III. PROPOSED FRAMEWORK
3.1. Network Setup diagram for MPLS TE Model
The network model for MPLS VPN considered for
simulation study is shown in the following diagram.
Below model indicates various types of routers. A
brief description on the functionality of those routers
is described below:
CE RTR – Customer Edge Routers – It will be
located on the customer premises which provide an
interface between customer LAN / WAN and Service
provider’s network. In this model, 2 Nos. of Clients
and 2 Nos. of Servers are connected across the
network in the Customer’s side. In real time, many
10/100/1000 Mbps Ethernet switches will be
connected to the CE RTRs. These routers may be
Non-MPLS router also.
LER – Label Edge Router – These are routers
which sits at the edge of the network also termed as
PE (Provider Edge) Routers. This forms the boundary
between the Customer’s Network and Service
Provider’s Network. MPLS label pushing (at ingress
side) and poping (at egress side) will happen at these
routers.
International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084
Fig. 1. Network Setup Diagram
Provider (P) Routers – These routers are
indicated as Site-1 to Site 5 in the below diagram. It
should be noted that, in real time scenario multiple
sites with CE routers shall connect to PE routers and
PE routers shall connect to other PE routers over P
routers (core of the provider or carrier’s network) in
the real time backbone network
The network model has been designed
considering the mesh topology connectivity between
the P routers. Efforts have been taken in the design to
make the simulation traffic which should match with
the real time scenario.
In NS2, we had taken the following traffic
models which are equivalent to the real time
multimedia traffic. CBR (Constant Bit Rate) objects
will generate the packets at a constant bit rate at
predefined packet size. Hence we had selected this
traffic as equivalent to data traffic. Exponential
objects generate ON/OFF Traffic. During ON
periods, packets are generated at constant burst rate.
During OFF period,, no traffic is generated. Burst
times and idle times are taken from the exponential
distribution. This kind of model resembles voice
traffic; hence we had selected this traffic as
equivalent to voice. For Video Traffic, we had
implemented with the publicly available library of
traces of encoded (compressed) video. We had used
H.263 codec compressed file for the simulation.
These traces have been generated from encodings of
several videos of typically 60 minutes length each.
3.2. RSVP based resource reservation in MPLS
VPN Architecture
In order to secure promised services, it is not
sufficient simply to select a route that can provide the
correct resources. These resources must be reserved to
ensure that they are not shared or “stolen” by other
LSP. The traffic requirements can be passed during
LSP setup (as with constrained based routing). They
are used at each LSR to reserve the resources required,
or to fail the setup if the resources are not available.
In order to support QoS, the developed module is
also able to perform resource reservation for the LSP
itself. The RSVP-TE agent is responsible for this
QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering
53
Volume-3, Issue-4, April-2015
action. The resource reservation process, shown in
Fig.2 can be summarized as follows. When a Path
message is received at the ingress interface of the
LSR, the RSVP-TE agent performs admission control
and policing functions. If there are enough available
resources it forward the Path message to the
downstream LSR [13].
After admission control and policing operations
have been performed all along with LSP, a Resv
message is generated and forwarded upstream along
the LSP. An LSR, when processing a Resv message,
allocates resources and calls the resource manager to
properly configure the queues in the packet scheduler.
The scheduler used with the RSVP-TE module is the
Weighted Fair Queuing (WFQ), which is already
implemented in NS2. Moreover, the RSVP-TE agent
calls the MPLS classifier to create the corresponding
entries in the LIB (Label Information Base) and PFT
(Partial forwarding Table) tables used for label
switching [13].
RSVP-TE
Path Messages Resv Messages
LIB
Admission Resource
Control Manager
Policing
MPLS Node
ERB
Packet Schedul er WFQ
Link
Fig. 2. Resource Reservation Process [13]
IV. RESULTS AND ANALYSIS
4.1. RSVP-TE/ns Module [13]
The below section explains the functionalities of
the RSVP TE simulator in the NS2 environment. In
this section, the main functionalities of the RSVP-TE
module in the MPLS routers were described. The
functionalities can be divided into two distinct sets.
 LSP’s establishment
 LSP’s Teardown
4.1.1 LSP’s establishment
In this LSP establishment phase, two different
commands are used. The first one is used when the
ingress LER wants to establish an ER-LSP, while the
second one is used when it wants to create an ER-LSP
with the reserved bandwidth.
<ingress-LSR>create-erlsp-rsvpte
<egress-LSR><sessionID><FlowID>
<TunnelID><er>
International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084
<ingress-LSR>create-erbwlsp-rsvpte
<egress-LSR><sessionID><FlowID>
<TunnelID><rate><bucket><ttl><er>
In both the cases, the Path message sent by the
ingress LER contains, in addition to the classical
RSVP objects, a LABEL_REQUEST object, used for
requesting to the downstream nodes the allocation of
the labels. The simulator allows to create an LSP that
follows an explicit path specifying <er> option a
sequence of nodes addresses. This field, if not empty,
is used to create an EXPLICIT_ROUTE_OBJECT
(ERO), which is added to the Path message.
When an LSR receives a Path message, it
performs several operations; the first ones are related
to admission control and policing. Then the node
processes the ERO: it inserts the ERO contents in the
Path State Block (PSB) and then it looks for the next
abstract node, to forward the Path message to. The
insertion of the ERO value in the PSB is needed in
order to assure that Resv messages follow, in the
upstream direction, the same route of the Path ones.
Once the egress LER has received and processed the
Path message, it generates a Resv message that
contains, in the LABEL object, the label value to be
used by the upstream node.
When an LSR receives a Resv message, the node
sets a new label value to be suggested to the upstream
node. Moreover, if the issued command is for an ER-
LSP with bandwidth reservation, the LSR calls the
Resource manager which, in turn, executes the
resource allocation.
Subsequently, it passes the label contained in the
Resv message (outgoing label) and the new label
(incoming label) to the MPLS classifier, which uses
them to create the corresponding entry in the label
switching tables. Finally, the LSR generates a Resv
message, with a LABEL object containing the value
of the suggested label, and forwards it to the previous
node as stores in the PSB. When the ingress LER
processes the Resv message the LSP is established.
Another command may be used to bind a flow to the
LSP.
4.1.2 LSP’s Teardown
In this teardown phase, it allows a tear down an
LSP when failure occurs. This command drives the
simulation of a link failure.
<upstream node>break-link<downstream node>
<ID downstream node><ID upstream node>
The following subsequent actions, related to
handling this event, are automatically performed.
 The link between the <downstream node> and
<upstream node> fails;
 The rsvp agent of the <upstream node> sends,
for each LSP that is established on the broken
QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering
54
Volume-3, Issue-4, April-2015
link, a PathErr message upstream, so as to
notify the ingress LER of the failure;
 The rsvp agent of the <downstream node>
sends, for each LSP that is established on the
broken link, a ResvErr message downstream,
so as to notify the egress LER of the failure;
 The egress LSR, after processing each
ResvErr message, sends to the <downstream
node> a ResvTear message, in order to release
the previously allocated resources;
 The ingress LER, after processing each
PathErr message, sends to the <upstream
node> a PathTear message, in order to release
the previously allocated resources;
 The ingress LER, deletes the corresponding
entry in the LIB, PFT and ERB tables.
After these operations, all the flows bound to an
LSP that has been torn down are forwarded according
to a Layer 3 routing protocol. This allows applying
different rerouting techniques.
4.2. Simulation Section
We had created the MPLS VPN architecture in
NS2 based on the proposed network setup model as
shown in Fig.1. Implemented topology in NS2 has
shown in Fig.3.
In this model, we had established the traffic path in
the network with multiple sources. First, external
traffic has been established between the client and
server nodes. Further internal traffic has been created
among various sites to have multiple cumbersome
traffic paths which are normal in a real time backbone
network.
Initially simulation has done without RSVP TE
implementation i.e., with MPLS LDP, and then the
same model has been simulated after RSVP-TE
deployment. We have taken the metrics of bandwidth
utilization, end-to end delay and packet loss ratio for
evaluation. Methods of obtaining the results are
described below: Loss ratio is given by the ratio of
average number of packets lost at the receivers to the
average number of packets sent. Average data
consumption is the bandwidth utilization during the
simulation time which has been calculated by
calculating the no. of packets received at both the
sinks multiplied by the packet size. End to end delay
has been calculated by obtaining the average time
taken by the data packets to reach the destination
sinks. For all the three performance metrics, we had
varied the data sending rate of each source and the
results were obtained. Simulation parameters are listed
in Table-1.
The results and comparison are described in
the next section.
International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084 Volume-3, Issue-4, April-2015

Fig. 5 Data Sending Rate / Source Vs Packet Drop – CBR

Traffic
Fig. 3. Simulation Topology
Table-I Simulation Parameters
Description Parameters
Total No. of Routers 13 Nos.
Traffic Type CBR, Exponential, Video
512 Bytes (For CBR & Expo)
Packet Size
250 to 400 Bytes (For Video)
Rate / Source 1.5, 2, 2.5, 3 Mb
No. of flows 2,4,6 and 8
Link Bandwidth 12Mb Fig. 6 Data Sending Rate / Source Vs Avg Data Consumption –
Maximum Reserved CBR Traffic
99%
Bandwidth
Bottleneck Bandwidth 5Mb Fig. 4 to Fig.6 shows the results of delay,
packet drop and average data consumption by varying
Simulation Time 10 Secs
the rate from 1.5Mb/s to 3Mb/s for the CBR traffic in
4.3. Results Analysis RSVP and MPLS VPN protocols. When comparing
the performance of the two protocols, we infer that
In this section, the results are obtained by varying RSVP outperforms MPLS VPN by 32% in terms of
the data sending rate at each source node from 1.5 to 3 average data consumption, 59% in terms of delay and
Mb. The performance are measured considering each 31% in terms of packet drop.
traffic separately and combination of all the traffics
types. 4.3.2. Case-II – Exponential Traffic
Since RSVP allocates the resources as per the user
requirement and the path is selected as per the Below are the results of Exponential Traffic
allocated resources, the bandwidth utilization of the
users will tend to increase when compared to the
normal MPLS VPN architecture. Moreover, since it
chooses the optimum path, the packet drops will be
less and hence the end-to-end delay becomes less
when compared to the MPLS VPN. This fact can be
proved by the results described in the following
section.
4.3.1. Case-I - CBR Traffic

Below are the results of CBR Traffic. Fig. 7 Data Sending Rate / Source Vs Delay – Exponential
Traffic

Fig. 8 Data Sending Rate / Source Vs Drop – Exponential

Fig. 4 Data Sending Rate / Source Vs Delay – CBR Traffic Traffic

QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering

55
International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084 Volume-3, Issue-4, April-2015

Fig. 10 to Fig.12 shows the results of delay,

packet drop and average data consumption by varying
the packet size from 250 bytes to 400 bytes for video
traffic in RSVP and MPLS VPN protocols. When
comparing the performance of two protocols, we infer
that RSVP outperforms MPLS VPN by 15% in terms
of average data consumption, 82% in terms of delay
and 94% in terms of packet drop.
4.3.4. Case-IV –Combined Traffic

Fig. 9 Data Sending Rate / Source Vs Avg Data Consumption –

In the combined scenario, we had assigned the
Exponential Traffic traffic flows randomly with CBR, Exponential and
Video Flows used to analysis the metrics of delay,
Fig.7 to Fig.9 shows the results of delay, packet drop and average data consumption. The
packet drop and average data consumption by varying results are compared and indicated below.
the rate from 1.5Mb/s to 3Mb/s for the Exponential
traffic in RSVP and MPLS VPN protocols. When
comparing the performance of the two protocols, we
infer that RSVP outperforms MPLS VPN by 32% in
terms of bandwidth, 58% in terms of delay and 30%
in terms of packet drop

4.3.3. Case-III –Video Traffic

Below are the results of Video Traffic

Fig.13 Data Sending Rate / Source Vs Delay – Combined
Traffic

Fig.10 Packet Size / Source Vs Delay – Video Traffic

Fig.14 Data Sending Rate / Source Vs Drop – Combined

Traffic

Fig.11 Packet Size / Source Vs Drop – Video Traffic

Fig.15 Data Sending Rate / Source Vs Avg Data consumption–

Combined Traffic

Fig. 13 to Fig. 15 shows the results of delay,

packet drop and average data consumption by varying
Fig.12 Packet Size / Source Vs Avg Data consumption– Video the rate from 1.5Mb/s to 3Mb/s for the combined
Traffic traffic in the RSVP and MPLSVPN protocols. When

QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering

56
International Journal of Electrical, Electronics and Data Communication, ISSN: 2320-2084
comparing the performance of the two protocols, we
infer that RSVP outperforms MPLSVPN by 66% in
terms of average data consumption and 22% in terms
of delay and 10% of packet drop.
CONCLUSIONS
The QoS is an important consideration in MPLS
network. In our proposed method, the MPLS VPN
architecture is combined with the Traffic Engineering.
This improves the performance metrics such as packet
delay, jitter and packet. RSVP allocates the resources
as per the user requirement and the path is selected as
per the allocated resources, hence the bandwidth
utilization of the users will tend to increase when
compared to the normal MPLS VPN architecture.
Moreover, since it chooses the optimum path, the
packet drops will be less and hence the end-to-end
delay becomes less when compared to the MPLS
VPN. The simulation results also showed the better
performance improvements in the performance
metrics for proposed RSVP based architecture.
REFERENCES
[1] O. Gure, B.K Boyaci and N.O. Unverdi “Analysis of the
Service Quality on MPLS Networks”, 5th European
Conference on Circuits and Systems for Communications
(ECCSC’10), Belgrade, Serbia, November 23-25 2010.
[2] Peng Zhang and Raimo Kantola, “Building MPLS VPNs with
QoS Routing Capability”, INTERWORKING, 292-301,
2000.
[3] Rozita Yunos, Siti Arpah Ahmad, Noorhayati Mohamed
Noor, Raihana Md Saidi and Zarina Zainol, “Analysis of
Routing Protocols of VoIP VPN over MPLS Network”. IEEE
Conference on Systems, Process & Controls (ICSPC2013),
Kuala Lumpur, Malaysia 13-15 December 2013.

QOS Provisioning For Multimedia Traffic On MPLS VPN With Traffic Engineering
57
Volume-3, Issue-4, April-2015
[4] “MPLS Traffic Engineering”, Cisco IOS release 12.0(8)S
[5] Xipeng Xiao, Alan Hannan, Brook Bailey and Lionel M. Ni,
“Traffic Engineering with MPLS in the Internet”, Network
IEEE, Volume:14, Issue:2, page 28-33, 2000.
[6] Mingui Zhang, Bin Liu and Beichuan Zhang, “Multi-
Commodity Flow Traffic Engineering with Hybrid
MPLS/OSPF Routing” , GLOBECOM, page 1-6, 2009.
[7] R. Boutaba, W. Szeto and Y. Iraqi, “DORA: Efficient
Routing for MPLS Traffic Engineering” , Journal of Network
and Systems Management, Vol. 10, No. 3, September 2002.
[8] Bernard Fortz, Jennifer Rexford and Mikkel Thorup, “Traffic
EngineeringWith Traditional IP Routing Protocols”, IEEE
Communication Magazine, October 2002.
[9] Rong Xu, YueFeng Ji, Qian Gong and Peida Ye, “A New
Node Architecture for Scalable Wavelength Label Switching
Networks Using MPLS”, 2”d IEEE International Conference
on Microwave and Millimeter Wave Technology
Proceedings, 2000.
[10] Nasser-Eddine Rikli and Saad Almogari, “Efficient priority
schemes for the provision of end-to-end quality of service for
multimedia traffic over MPLS VPN networks”, Journal of
King Saud University – Computer and Information Sciences
,25, 89–98, 2013.
[11] Balazs Szviatovszki, Aron Szentesi and Alpar Juttner,
“Minimizing Re-Routing in MPLS Networks with
Preemption-Aware Constraint-Based Routing”, Computer
Communications 25(11-12) 1076-1084 ,2002.
[12] Paul Brittain and Adrian Farrel, "MPLS Traffic Engineering-
AChoice of Signaling Protocols", MetaSwitch Networks,First
issued January 2000.
[13] D. Adami, C. Callegari, S. Giordano, F. Mustacchio, M.
Pagano and F. Vitucci, “Overview of the RSVP-TE Network
Simulator: Design and Implementation”, Proceedings of
Internet Performance, Simulation, Monitoring and
Measurements (IPS-MOME), 276-281, 2005.
[14] Joel Repiquet, “A Whitepaper on Simulating Classes of
Services over an IP/MPLS backbone, VPN case study”, delve
intoTech, 2005.
[15] MPLS-TP and IP/MPLS – their applicability for metro
networks by Innovation observatory Ltd, Silvaco Technology
Centre, http://www.innovationobservatory.com
[16] Network Simulator: http:///www.isi.edu/nsnam/ns