First International Conference on Emerging Trends in Engineering and Technology
Traffic Analysis of MPLS and Non MPLS Network including MPLS Signaling
Protocols and Traffic distribution in OSPF and MPLS
Mahesh Kr. Porwal* Anjulata Yadav
M.E. (E & Tc) Final Yr Astt. Prof. Dept. of E &Tc
SGSITS, 23 Park Road SGSITS, 23 Park Road
Indore, India – 458003 Indore, India – 458003
porwal5@yahoo.com yadawanjulata@rediffmail.com
Abstract
Multi-Protocol Label Switching (MPLS) is rapidly
emerging technology, which plays a key role in next
generation networks by delivering QoS and traffic
engineering features. MPLS is helpful in managing traffic
when some links or paths are under and/or over utilized.
In MPLS a look – up in switching table is certainly less
complex and time consuming than a corresponding
routing table look – up in an IP router.
This paper present a analysis of MPLS signaling
protocols for traffic engineering, shows the capability
of providing traffic engineering in MPLS compared to the
conventional routing protocol, and explains the MPLS
LSR operations based on the basic LSR functionality
of classification, queue, and scheduling. The
comparisons of CR-LDP, RSVP, and RSVP-TE are
conducted based on the aspects of LSP reliability and
LSP adaptability. In addition, this paper also presents a
comparative analysis of MPLS and non-MPLS network
and shows that MPLS provides improved network
performance for heavy traffic environments.
Keywords– MPLS, LSP, Performance, Routing
Protocol, Traffic Engineering.
1. Introduction
Early computer networks carried continuous bit streams
over physical links in a technique called circuit switching.
This was well suited to transmit voice or real time data
from a single sender to a single receiver (unicast
communications). In this kind of network a single
physical link failure had dramatic consequences,
leading to the interruption of all communications
that was using the failed link. The Internet today is a
datagram packet switched network that fixes this
drawback by cutting data into small chunks called packets.
These packets are individually routed through the
network, so two packets from the same
communication are individually handled in the network.
978-0-7695-3267-7/08 $25.00 © 2008 IEEE 187
DOI 10.1109/ICETET.2008.58
S. V. Charhate
Prof. and Head, Dept. Of E & Tc
SGSITS, 23 Park Road
Indore, India – 458003
scharhate@sgsits.ac.in
Therefore if a link fails, packets can be rerouted to avoid
the failed link and communications are not interrupted.
This feature of a datagram switched network is called
resilient because it hides network failures from the end
users. On the other hand it is more difficult to manage
flows of data in a datagram packet switched network
than in a circuit switched network because each
packet is handled individually.
The convergence of voice and data communications
over a single network infrastructure is expected to
happen over IP-based networks. Traditional IP
networks offer little predictability of service, which is
unacceptable for applications such as telephony, as well
as for emerging and future real-time applications. IP
networks are often layered over ATM networks, which is
very costly in terms of overhead (adding 25 percent or
more of overhead to every IP packet)[5], but had one
great advantage: IP packets could be forced onto
particular ATM circuits, overriding IP routing, which
alleviated the congestion known as traffic engineering.
What service providers wanted was a ways to do traffic
engineering without using ATM. Traditional IP networks
have no means of tagging, cataloging, or monitoring the
packets that cross them.
As recent history tells us, the upper limit of transmittable
bandwidth doubles and sometimes quadruples every nine
to twelve months. Already transmission of tens of tera
bits-per-second over a single optical fiber is possible
and matching data transferring topologies as well as
improved system reliability are currently needed.
Based on the above facts, two major candidates that are
in competition to become the dominant future network
protocol and network architecture are differential
services (DS) and Multiprotocol label switching (MPLS)
[4]. In the competition of DS and MPLS, MPLS
has been emerging as the protocol of the future
for the following reasons: First, it is a true
“Multiprotocol Architecture” utilizing a simple label
switching mechanism, which is where its versatility in
application exists, e.g., MPLS over ATM, frame relay
(FR), etc. Second, through utilizing classification, queue,
and scheduling (CQS) traffic- engineering topologies
MPLS is capable of providing controllable quality of
service (QoS) features [6]. Third, MPLS provides a
solution to scalability and enables significant flexibility
in routing. Fourth, the connection oriented architecture
and QoS reliability features easily enable high quality
end-to-end service features that are necessary in
applications such as virtual private networks (VPN) [7].
These benefits of MPLS networking are made possible
through traffic engineering.
MPLS technology works to solve those shortcomings of
IP, placing labels on IP packets and providing the labeling
function. MPLS is not designed to replace IP; it is
designed to add a set of rules to IP so that traffic can be
classified, marked, and policed. MPLS (Multiprotocol
label switching) as a traffic-engineering tool has emerged
as an elegant solution to meet the bandwidth management
and service requirements for next generation Internet
Protocol (IP) based backbone networks [12].
An MPLS[4] network can offer the quality of service
guarantees that data transport service like frame relay (FR)
or ATM give, without requiring the use of any dedicated
lines. MPLS was devised to convert the Internet and IP
backbones from best effort data networks to business-class
transport mediums capable of handling traditional real
time services. The initial trust was to deliver much needed
traffic engineering capabilities and QoS enhancements to
the generic IP cloud. The availability of traffic engineering
has helped MPLS reach critical mass in term of service
provider mind share and resulting MPLS deployments.
Most carriers run MPLS underneath a wide range of
services, including FR, wide-area Ethernet, native IP, and
ATM. Advantages accrue primarily to the carriers. User
benefits include lower cost in most cases, greater control
over networks, and more detailed Quality of Services.
Currently, the constraint-based routing label distributions
protocol (CR-LDP) and the resource reservation protocol
(RSVP) are the signaling algorithms used for traffic
engineering. In this paper, we present a comparative
analysis of MPLS and non-MPLS network and also
compare the signaling procedures of the CR-LDP and
RSVP algorithms and discuss the appropriateness of the
applications in MPLS traffic engineering networks and
shows that MPLS improved network performance for
multimedia type application in heavy traffic environment.
This paper is organized as follows: Section 2 gives the
comparative analysis of MPLS and non-MPLS network.
Sections 3 introduce the operation of MPLS LSR. Section
4 and 5 gives detailed explanation of the CR-LDP and
RSVP-TE signaling respectively. 5 Section 6 compares
MPLS signaling protocols based on LSP reliability and
LSP adaptability. Section 7 and 8 yields the numerical
experiments and results in detail. Finally, Section 9
summarizes our work and concludes this paper.
188
2. Comparative Analysis of MPLS and Non –
MPLS Network
2.1 Traditional IP Routing
In conventional IP routing, each router in the
network has to make independent routing decisions
for each incoming packet. When a packet arrives at
a router, the router has to consult its routing table to
find the next hop for that packet based on the packets
destination address in the packets IP header (longest
match prefix lookup). To build routing tables each router
runs IP routing protocols like Border Gateway Protocol
(BGP), Open Shortest Path First (OSPF) or Intermediate
System-to-Intermediate System (IS-IS). When a packet
traverses through the network, each router performs
the same steps of finding the next hop for the
packet[1].
The main issue with conventional routing protocols is that
they do not take capacity constraints and traffic
characteristics into account when routing decisions are
made. The outcome is that some segments of a network
can become congested while other segments along
alternative routes become under utilized. Even in the face
of congested links, traditional routing protocol will
continue to forward traffic across these paths until packets
are dropped.
Conventional IP packet forwarding has several
limitations. It has limited capability to deal with
addressing information beyond just the destination IP
address carried on the packet. Because all traffic to the
same IP destination – prefix is usually treated similarly,
various difficulties arise. For example, it becomes
difficult to perform traffic engineering on IP networks.
Also, IP packet forwarding does not easily take into
account extra addressing-related information such as
Virtual Private Network (VPN) membership [11]. To
accommodate highly interactive application flows with
low delay and packet loss threshold, there is a clear need
to more efficiently utilize the available network resources.
The process whereby this is accomplished is known as
traffic engineering and MPLS provides these capabilities.
2.2 MPLS Technology
A common technique used among large ISPs is to use a
layer 2 network (ATM or FR) to manage a network. In
this approach often called the overlay solution, a complete
mesh of virtual circuits connects the IP backbone. This
serves to prevent the aggregation that occurs by hop-by-
hop routing in an IP backbone with destination based
routing. In this approach the flows can be individually
routed through the layer 2 topology and traffic
engineering can be achieved. But the drawback to this
approach is the issue of scalability and that a single link
failure can result in dozens of Virtual Circuits going
down, forcing the IP routing protocols to reconvert. A
solution for this problem can be coordination between the
layer 2 networks and the layer 3 IP network. This solution
is MPLS, a set of procedures for combining the
performance, QoS and traffic management of the Layer 2
label-swapping paradigm with the scalability and
flexibility of Layer 3 routing functionality.
Multiprotocol label switching (MPLS) is an extension to
the existing Internet Protocol (IP) architecture. By adding
new capabilities to the IP architecture, MPLS enables
support of new features and applications. In MPLS short
fixed-length labels are assigned to packets at the edge of
the MPLS domain and these pre assigned labels are used
rather then the original packet headers to forward packets
on pre-routed paths through the MPLS network [12]. In
MPLS, the route the packet is forwarded through the
MPLS domain is assigned only once i.e., when the packet
enters the domain. Before a router forwards a packet it
changes the label in the packet to a label that is used for
forwarding by the next router in the path.
2.3 MPLS Domain
In [12] the MPLS domain is described as "a
contiguous set of nodes which operate MPLS routing
and forwarding". This domain is typically managed
and controlled by one administration. The MPLS
domain can be divided into MPLS core and MPLS edge.
The core consists of nodes neighboring only to MPLS
capable nodes, while the edge consists of nodes
neighboring both MPLS capable and incapable nodes. The
nodes in the MPLS domain are often called LSRs (Label
Switch Routers). The nodes in the core are called transit
LSRs and the nodes in the MPLS edge are called LERs
(Label Edge Routers). If a LER is the first node in the path
for a packet traveling through the MPLS domain this node
is called the ingress LER, if it is the last node in a path it's
called the egress LER. A schematic view of the MPLS
domain is illustrated below.
Figure2. Schematic View of the MPLS Domain.
189
3. MPLS LSR Operation
The LSR that conducts the differential services is
required to conduct a three-step procedure to enable
traffic engineering. These three basic steps are
classification, queue, and scheduling (CQS). As label
attached packets arrive at the input ports, the input
label is used to identify the forwarding equivalent
class (FEC) and the corresponding output label. The
output label will replace the input label of the packet.
Then, based on the output label and FEC, the packet will
be sent to the corresponding output queue where the
scheduling multiplexer will decide on the output order,
timing, and the output port for the packet to be sent out.
The setup of the LSR is done by the signaling protocols
(CR-LDP, RSVP-TE). The functional diagram of a
LSR is provided in Figure. 1 [8].
Figure1. Functional Diagram of the LSR Classification,
Queue, and Scheduling operation
4. CR – LDP Signaling
CR-LDP standards attempt to enable the LDP protocol to
work over an explicit route, transporting various traffic
parameters for resource reservation as well as the options
for CR-LSP robustness features [2]. Both LDP and CR-
LDP are hard state protocols, where signaling messages
are transmitted once without any refreshing-information
requirements. The transport mechanism for peer
discovery is UDP, while TCP is used for session,
advertisement, notification, and LDP messages. To setup
an explicit route, a LABEL REQUEST message
containing a list of nodes along the constraint-based route
to be traversed is sent. The signaling message will be sent
to the destination following the selected path, and if the
requested path is able to satisfy the requirements, labels
are allocated and distributed by means of LABEL
MAPPING messages starting with the destination and
propagating in the reverse direction back to the source.
Assuming that resources are available, the LSP setup is
completed after a single round-trip of the signaling
message. CR-LDP is capable of establishing both strict RSVP-TE. The features of the three signaling protocols
and loose path setups with setup and holding priority, path are organized in Table 1 [7].
preemption, and path re-optimization. The procedure for
reporting failures in CR-LDP is based on ingress and Table1. Comparison of CR-LDP, RSVP and
egress router’s TCP layer transport operations. CR-LDP RSVP-TE
enables multiprotocol operations by using an opaque FEC,
which allows core LSRs to be indifferent with respect to CR-LDP RSVP RSVP-TE
Created to Established to
the type of traffic being transported across the network. enable LSP support soft
Proposed with
modification to
The opaque FECs are also used for security purposes as Protocol
setup for reliable state resource
differentiated
end to end reservation of
well, not enabling the LSRs to know the transport data Objectives
differentiated integrated
services with
RSVP for MPLS
services identity. services in services of IP
networks.
MPLS networks. networks.
Revised
Designed for Designed for
5. RSVP Signaling Network
Positioning
carrier backbone edge and host
designed for
backbone
networks. services.
networks.
Based on RFC 2205 [10], the RSVP signaling protocol Differentiated
Supported Not Supported Supported
standard published by the IETF is intended for soft state Services
Strict, Loose, Strict, Loose, Strict, Loose,
resource reservation focusing on enterprise networks to Routing Type
Pinning not Pinning Pinning
support integrated services [9]. RSVP inherently is a soft Scalability Good Poor Marginal
state protocol that uses PATH and RESV commands to User Security Low Low Low
LSP FEATURES
establish a LSP. In RSVP, based on the destination IP LSP State Hard Soft Soft
address and protocol ID, packets are transferred based on LSP State Periodic, Periodic,
None
raw IP datagram routing. The ingress LSR uses a PATH Refresh All Nodes All Nodes
Resource By Receiving By
message to inform every router along the selected LSP to Request
By sending LER
LER Receiving LER
acknowledge that this is a desired LSP to be established. LSP Forward, Backward, Backward,
Following this, the receiving LSR will use the RESV Setup Action Downstream Upstream Upstream
LSP Architecture Sink Tree Source Tree Source Tree
message with traffic and QoS parameters traversing RELIABILITY
upstream to reserve the resources on each node along the LSP Failure
Reliable Unreliable Unreliable
desired LSP. The node along the LSP will install the Detection
LSP Failure
reservation for the related state by creating an entry on the Recovery
Local & Global Local & Global Local & Global
label-forwarding table. At every node along the path, the LSP Failure
Low High, All Nodes High, All Nodes
Recovery Traffic
PATH and RESV messages are used periodically to
MULTIPLE CONNECTION SUPPORT
refresh the path and reservation states. Problems in Multipoint
Yes Yes Yes
resource reservation can result based on the RSVP soft LSP Merging
Multicasting
state mechanism and the merging points along the selected LSP Setup
No Yes No
LSP. Overall, there is no guarantee that the resources will ADAPTABILITY
be reserved based on the end-to-end request. RSVP-TE Loop Prevention Yes Yes Yes
Path Rerouting Yes Yes Yes
has been made and proposed to support ER-LSP as well as
Yes, Yes,
provide additional features to RSVP [3]. Since the RSVP Path Preemption Yes
But not reliable but not reliable
protocol was proposed to support MPLS LSP setups, a
considerable amount of modifications and extension have CR-LDP was created to enable LSP setup for reliable
been made to the original protocol to cope up with the end-to-end differentiated services in MPLS networks.
traffic engineering requirements. The major modifications Compared to this, RSVP was established to support soft
and extensions fall into the areas of adding traffic state resource reservation of integrated services over IP
engineering capabilities and resolving scalability networks. RSVP was created before CR-LDP with
problems. The revised RSVP protocol has been proposed originally a different intension of where it would be used.
to support both strict and loose explicit routed LSPs (ER- Therefore, it is not surprising that RSVP is not suitable
LSP). For the loose segment in the ER-LSP, the hop-by- for traffic engineering in MPLS networks. The RSVP-TE
hop routing can be employed to determine where to send contains several specifications to support differentiated
the PATH message. Thus, RSVP also supports hop-by-hop services with RSVP for MPLS traffic engineering
downstream-on demand ordered mode. networks, although some of the key components of the
architecture are the same. For example, the original
6. Comparison of Signaling Protocols protocol base of using the internetworking protocol (IP) is
In this section, the signaling protocols of MPLS traffic the same, also the hop-by-hop soft state refreshing
engineering are compared. The signaling protocols in algorithms are basically the same (although somewhat
comparison are the CR-LDP, original RSVP, and the modified), as well as the reverse upstream LSP setup
topology remains the same. Several features of CR-LDP,

190
that were not a part of RSVP, are now possible by the
RSVP-TE. As in terms of scalability, CR-LDP is a hard
state protocol, and due to this, it inherently possess better
scaling properties in terms of the volume of signaling
traffic in the network as the number of CR – LSPs
increase. One of the significant drawbacks of RSVP is its
scalability when there are a large number of paths passing
through a node. This is due to the soft state characteristics
of RSVP and RSVP-TE, which require periodical
refreshing of the state for each path.
7. Proposed Methodology
The simulation environment employed in this paper is
based on QualNet 4.0 simulator. The simulations were
setup using a normal IP network without Traffic
engineering (composed of OSPF) and a MPLS network
with Traffic Engineering (composed of with MPLS
signaling protocols such as CR-LDP and RSVP-TE) are
implemented. The results from these simulations are used
for comparison between the two networks. Both
simulations are based on the common topology as shown
in figure 3.
The network consists of 11 nodes. All links were setup as
duplex with 10 ms delay and using DropTail Queuing,
which serve packets on a First Come First Serve (FCFS)
basis. The Traffic connection was set up between node 0
and node 10 using UDP with CBR of 1000 byte packets
and 3ms inter-arrival time. The MPLS Traffic Engineering
8. Simulation Results
8.1 IP Network without Traffic Engineering:
In the IP network traffic uses the shortest path
(2_3_6_7_8) to forward traffic, which causes this path to
overlap at the link from node 3 – 6 thus causing
congestion on this link. The traffic from (2_3_6_7_8)
exceeds the capacity of the shortest path, while a longer
path between (2_3_4_5_7_8) is under-utilized. When the
path (2_3_6_7_8) of the network is busy, congestion is
occurring within the network. Packet from link (3 – 6) get
dropped and delayed as buffer overflow because the
resources in the network cannot meet all traffic demands.
8.2 MPLS Network with Traffic Engineering:
In MPLS an LSP is set up when a ‘label request message’
propagates from the ingress (node2) to the egress LSR
(node8). When the requested path satisfies the constraints
and labels are allocated, then a “label-mapping message”
propagates back from the egress LSR (node 8) to the
ingress LSR (node 2) carrying details of the final traffic
parameter reserved for the LSP. When LSP is setup,
MPLS traffic engineering is applied to switch the traffic
flow through an explicit rout (2_3_4_5_7_8), hence
under-utilized path is also used for forwarding the traffic.
Throughput at destination Node is shown in figure 4 and
figure 5.
IP MPLS

simulation topology is similar to the IP topology with only 140

difference being that nodes 2 through 8 are MPLS capable, 120
which allow non-shortest path links to be used. 100

The output trace file from the simulation is used to 80

measure the performances of the network such as: 60

Throughput at the destination node, link utilization and 40

total number of packets received. 20

0
0.5 1 1. 2 2.5 3 3.5 4 4. 5
5 5

Simulation Time(S)
Figure4. Throughput V/s Simulation Time

IP MPLS

0.40
0.35
0.30
0.25
0.20
0.15
0.10
0.05
0.00
100 200 300 400 500 600 700 800 900

Bandwidth (kbps)
Figure3. Simulation Topology
Figure5. Throughput V/s Bandwidth

191
Table2. Comparison between conventional routing (IP)
and MPLS routing.
IP MPLS
712 867
No. of Packets received
Throughput (Mbps) 0.5832 0.7102
BW Utilization (%) 58.32 71.02
End to End Delay (s) 0.042 0.038
Average Jitter (s) 0.35*10-3 0.21*10-4
9. Conclusion
This paper explains the MPLS LSR operations based on
the basic LSR functionality of classification, queue, and
scheduling. In addition, MPLS signaling protocols such as
CR-LDP, RSVP and RSVP-TE are summarized and
analyzed based on how to set up LSP for TE with help of
the protocol messages. CRLDP is a hard-state protocol and
capable of establishing both strict and loose path setups
with setup and holding priority, path preemption, and path
re-optimization. RSVP inherently is a soft state protocol
that uses PATH and RESV commands to establish a LSP.
RSVP-TE has been proposed to support ER-LSP as well
as provide additional features to RSVP and contains
several specifications to support differentiated services
with RSVP for MPLS traffic engineering networks. Based
on comparison of signaling protocols, it can be found that
RSVP has drawback in its scalability when there are a
large number of paths passing through a node due to the
periodical refreshing of the state for each path.
In the simulation, when MPLS signaling protocols were
implemented in a MPLS network of TE, the traffic is
moderately distributed into several LSPs, which is not able
to achieve in the conventional routing protocol. Through
the results analysis, it is clear that with proper MPLS
Traffic Engineering applied to the network, the
performance of the network is significantly improved.
192
10. References
[1]. A. Ghanwani. "Traffic Engineering Standards in IP
Networks Using MPLS" IEEE Communications Magazine, vol.
37, no. 12, pp. 49- 53. Dec. 1999.
[2]. B. Jamoussi et al, “Constraint-Based LSP Setup using LDP”
IETF RFC 3212, Jan. 2002.
[3]. D. Awduche et al, “RSVP-TE: Extensions to RSVP for LSP
Tunnels” IETF RFC 3209, Dec. 2001
[4]. E. Rosen, A. Viswanathan and R. Callon, “Multiprotocol
Label Switching Architecture,’’ RFC 3031, Jan. 2001.
[5]. IEEE Communication magazine, September – 2006.
[6]. J. L. Marzo, E. Calle, C. Scoglio, and T. Anjali, “QoS on-
line routing and MPLS multilevel protection: a survey,” IEEE
Communication Magazine, vol. 41, pp. 126-132, Oct. 2003.
[7]. J. M. Chung, E. Marroun, H. Sandhu, and S. C. Kim “VoIP
over MPLS Networking Requirements,” Proceedings of
IEEE International Conference on Networking,. France, July.
2001.
[8]. J. M. Chung, “Analysis of MPLS Traffic Engineering,”
Proceedings of the IEEE Midwest Symposium on Circuits
and Systems, USA, Aug. 2000.
[9]. J. Wroclawski, “The Use of RSVP with IETF Integrated
Services” IETF RFC 2210, Sep. 1997.
[10]. L. Zhang et al, “Resource Reservation Protocol (RSVP)”
IETF RFC 2205, Sep. 1997.
[11]. Muzammil Ahmad Khan. “Quantitative Analysis of MPLS
in VPN's”, Sir Syed University of Engineering and Technology,
from www.ieeexplorer.org.
[12]. UYLESS BLACK – MPLS and Label Switching Network.