1

MPLS Core Network Simulation

Patrick W. Fitzgibbons, Ph.D.

pat@sunyit.edu
Associate Professor-Telecommunications Networking
Jay Talreja, SUNYIT MS Telecommunications Program
Harikrishna Rajagopalan, SUNYIT MS Telecommunications Program
State University of New York Institute of Technology
PO BOX 3050
Utica, NY 13504

Abstract
The quest for improved performance at all levels of networking has posed significant
challenges on the design and implementation of computer networks. Traffic loads have
been growing exponentially and there is so sign that this astounding growth will flatten
off in the next few years. With the increase in traffic load, there is a corresponding need
for differentiated services. Multi Protocol Label Switching (MPLS) has emerged as the
front runner in the internetworking core because of its enhanced capabilities and inherent
support for differentiated services. Legacy Internet routing protocols have some inherent
disadvantages that are overcome through MPLS. This study focuses on the advantages of
MPLS networks over legacy IP routing protocols.

Introduction
In the last decade the Internet has developed into the Worlds most ubiquitous network.
With more and more people now connected to this network this fact has not gone
unnoticed by the business community. Their focus has clearly shifted towards using the
Internet as a primary mechanism to reach their customers. E-commerce, M-commerce
and the resulting paradigm shift has resulted in an ever increasing need to create various
network applications. These network centric applications have in turn created the need
for increased and guaranteed bandwidth requirements at the core of the network. Along
with the traditional services, the Internet has spawned voice and multimedia services
which are straining the resources available at the core of the network. Quality of service
(QoS) has become the single most important issue needing to be addressed in order to
meet the diverse requirements of the ever increasing networking community. One such

3
solution to the abovementioned needs, Multi Protocol Label Switching (MPLS), is
currently being deployed at the core of the Internet.
Initially, a simple software-based router was used to meet the requirement of data transfer
over the internet. Then, as the need for speed increased, hardware switching was used at
layer 2 and layer 3. But these solutions did not take into consideration additional factors
like delay and jitter. Thus traffic engineering requirements also paved a path for the
widespread deployment of MPLS in the very heart of the Internet.
MPLS was originally developed to address Traffic Engineering issues. However in a very
short period of time, MPLS has become the forerunner in providing scalability and
resiliency to core networks. Fast rerouting and protection switching mechanisms that
MPLS offers have made the core MPLS networks better equipped to provide Quality of
Service and also made them more robust against catastrophic failures.

Methodology
The focal point of this study was to show how MPLS overcomes the topological
dependence of legacy Internet routing protocols. This was accomplished by designing
and simulating several alternative logical networks using OPNET Modeler 9.1. In order
to accomplish the study objective initial simulations were based on relatively small
networks implementing RIP and OSPF. The network size was subsequently increased to
demonstrate the shortcomings of RIP and OSPF. The results obtained from the
simulations are presented followed by a brief discussion and conclusion.

Generic Topology model:

4
The basic topology model consists of a core network with the attached nodes as shown
below in Figure 1.

Figure 1: Generic Topology Model

The end user workstations are based on the model ppn_wkstn present in the OPNET
models.

5
Figure 2 shows the attributes of a typical workstation

6
Figure 2: Workstation Model Attributes
The core consists of gateways which are specially developed (my_router_Basic). They
represent IP-based routers with 4 Ethernet interfaces and 32 Serial Line IP Interfaces
(SLIP) at a selectable data rate. Figure 3 shown below shows the attributes of the
specially developed router. The router was created using the Device Creator utility found
under the heading Topology.

Figure 3: Router Attributes

Within the core, the links are represented by bi-directional DS1 (1.544 Mbps) connectors.
At the edges the end-stations are attached via DS3 (44.736 Mbps).

7
Traffic configuration is done by specifying the details of the traffic in the Application
configuration object. Two types of traffic are defined: Http traffic is defined by Heavy
browsing while the Voice traffic corresponds to IP telephony and silence suppressed.
Thus two different types of traffic are specified: Http being TCP based while Voice is
UDP based.

Figure 4 below shows the attributes for the Application Configuration object

Figure 4: Application Configuration Attributes

8
There are two profiles configured to manage the traffic flows: Http user and Voice user.
The applications start times are set to constant 200 seconds for http and 250 seconds for
voice. Traffic is mapped to specific workstations with Application: Supported Profiles.
There is one httpUSER that employs User-http profiles. The other clients i.e.
voiceUSER1 and voiceUSER2 have User-voice configured. Voice users should have
Application: Supported Services set to voice, whereas http server should support http
traffic. Additionally for voice users Application: Destination Preferences are set so that
voiceUSER1 and voiceUSER2 communicate with each other.
Figure 5 below shows the attributes for the Profile Configuration object

Figure 5: Profile Configuration Attributes

Further scenarios consider additional background traffic flows that are developed by
means of ip_ace_traffic_flow model. There are conversation pairs configured by mapping
the flows onto the topology. Figure 6 below shows the network with the background
traffic flows between the nodes.

10

Figure 6: Generic topology set up with background traffic flow

Here the end stations communicate with each other in one to one manner. The back
ground traffic is also delayed so that they start after routing tables converge. The start
time is set to 300 seconds.

11
Figure 7 shows the attributes for the background traffic flowing between the two voice
users

Figure 7: Traffic Flow attributes

The background traffic can be specified explicitly or default traffic profiles can be chosen
from the various traffic flows provided by OPNET.
Figure 8 below shows the background traffic flow configuration dialog box

12

Figure 8: Traffic Attribute Profile

Background and Assumptions

The main objective of this section is to present basic Traffic Engineering best practices
and network design assumptions. The following factors were considered when
constructing the various scenarios simulated using OPNET Modeler.
1. Shortcomings of standard Internet routing: RIP and OSPF in terms of:

performance

resource utilization

traffic types vs. congestion effects

2. Benefits of Traffic Engineering (TE) best practices

The simulations are organized in three different areas:
1. IP routing protocols and traffic distribution in the network

13
The simulations involving RIP and OSPF were configured so that their basic
characteristics and performance could be compared. One of the primary factors in
running the simulations concentrated on traffic distribution in the network.
2. Traffic types vs. congestion effects
This set considers traffic behavior under different traffic conditions. The first scenario
deals with explicit traffic only. In further scenarios, background traffic is added and
another set treats all traffic scaled with factor 2. The relevant scenario sets are marked
with the following aliases:

explicit traffic

background traffic

traffic doubled

3. TE implementation with MPLS:

This simulation was used to study the application of MPLS static and dynamic LSPs
serving TE purposes. Based on the application definitions, profile configuration, explicit
traffic and background traffic the following scenario has been setup to study the
performance of standard routing protocols

14

Figure 9: Topology to measure the performance of standard routing protocols

Results and Discussion

The following utilization graphs (figures 10, 11 and 12) were obtained after simulating
the basic scenario for RIP and OSPF.
1) Utilization of Link node0- node 2 using RIP

15
Figure 10 above shows the link utilization of node0-node2 when RIP is the routing
protocol used. Since the background traffic chosen is 500,000 bps the link gets over
utilized and the utilization is 100%. Both the graphs show 100 % utilization thus
proving that the results obtained are correct.
2) Utilization of Link node0-node 2 using OSPF

Figure 11 above shows the link utilization of node0-node2 when OSPF is configured.
OSPF does load balancing and hence the traffic is shared between two links. Because
of the availability of multiple paths the link utilization is less. The load balancing
feature is inherent in OSPF and hence the link utilization remains low when
compared with RIP, even with the same background and explicit traffic load.
Comparing the two graphs above we see that the results obtained are valid.
3) Utilization of Node 0- Node 3 using OSPF and RIP

16

Figure 12: Utilization using OSPF and RIP

The above graph in figure 12 shows the link utilization for node0-node3. The utilization
for OSPF is almost 70% whereas for RIP it is zero. This is because RIP utilizes only 2
out of the 7 core links whereas OSPF utilizes 4 out of 7. The figure to the right shows the
link utilization for link node3-node4. It can be seen that the link utilization is zero for RIP
and OSPF both. Thus certain links have zero utilization while some have over utilization.
This leads to inefficient utilization of available resources by IP routing protocols viz. RIP
and OSPF.
Using OPNET link utilization feature we can display the links with different colors based
on the amount of Utilization.
Figure 13 below shows the Link Utilization for RIP & OSPF routing protocols

17

Figure 13: Generic topology employing RIP as the routing protocol

The links shown in red are 100 % utilized whereas the links in green are poorly utilized.
From the figure we can see that only 2 links out of 7 links in the core are being utilized
and the remaining links are under-utilized. The links that appear in yellow are the ones
that are utilized to a greater extent, whereas the ones in green as in the previous case with
RIP are underutilized

The primary reason for these underutilized links can be understood by focusing on the
relative queuing delays. The excessive utilization of certain links and underutilization of
others cause bottlenecks thus causing queuing delays that are intolerable and lead to

18
packets being dropped. From the results obtained it is evident that RIP leads to severe
delays whereas OSPF tries to keep the delays to minimum.
The following graphs shown as figure 14 compare the Queuing delays for RIP and OSPF
on links that are utilized the most by each of the routing protocols.

Figure 14: Queuing delay for RIP and OSPF

It can clearly be seen that RIP has a higher queuing delay compared to OSPF. It is also
interesting to observe the Application performance when RIP is used as the routing
protocol and compare the performance when OSPF is used as the routing protocol in the
core network.

19

Application Performance
The inadequate utilization of resources affects the user performance as well. The voice
application characteristics were measured to see how underutilized links can affect
performance.
The voice traffic characteristics that were measured to evaluate the performance are as
follows:
Voice packet end-to-end delay it represents the time it takes for a voice packet to reach
the destination node

Voice packet end-to-end delay

From the previous graphs we see that the queuing delay for RIP is greater than for OSPF.
This delay translates to the voice packet end-to-end delay. It is seen that the delay is
greater for RIP than for OSPF. However when the background traffic doubles the delay
becomes the same for both OSPF and RIP. The background traffic has a higher data rate
than the explicit voice traffic and hence the doubling of the background traffic affects
both the routing protocols equally, the explicit traffic being kept the same.
The following graph in Figure 15 shows the voice packet end-to-end delay for RIP and
OSPF with background traffic and double background traffic.

20

Figure 15: Voice packet end-to-end delay

Summary

21
From the above simulations we can summarize the following observations
1) RIP and OSPF both lead to underutilization of the core links. When RIP is
employed in the core network only 2 out of the 7 links are utilized whereas for
OSPF 4 out of the 7 links are utilized. Thus OSPF tends to spread the traffic based
on the topology.
2) The underutilization of the core links causes queuing delay in the links.
3) The queuing delay is higher for RIP when low background traffic is considered.
However both RIP and OSPF are affected equally for higher background traffic.

Conclusions

Standard routing protocols like RIP and OSPF have shortcomings that lead to inefficient
utilization of resources and hamper application performance. These shortcomings are due
to the shortest path algorithm that both RIP and OSPF rely on while making routing
decisions. It was seen from the simulations that voice performance gets severely affected
when RIP and OSPF are used for routing. MPLS helps in efficient utilization of
resources. By making use of predefined paths, unutilized links were utilized. Thus MPLS
helps in efficient resource utilization.

References
Anagnostakis K., et al. (2002) On the sensitivity of Network Simulation to
Topology. CIS Dept University of Pennsylvania. Retrieved March 12, 2004
http://www.cis.upenn.edu/~anagnost/papers/mbottle.pdf

22
Bajaj S., et. Al. (1999) Improving Simulation for Network Research. USC CS Dept.
Retrieved March 7, 2004 from
http://citeseer.ist.psu.edu/cache/papers/cs/3491/ftp:zSzzSzusc.eduzSzpubzSzcsinfozS
ztech-reportszSzpaperszSz99-702.pdf/bajaj99improving.pdf/
Conway R., & McClain J. (2003) The Conduct of an Effective Simulation Study Cornell
University Retrieved April 5, 2004 from
http://ite.pubs.informs.org/Vol3No3/ConwayMcClain/
Miller B., & Stewart E., (2004) Multi-Protocol Label Switching (MPLS) Conformance
and Performance Testing IXIA Com. Retrieved April 7, 2004 from
http://www.ixiacom.com/white_papers/pdfs/mpls.pdf
OPENT University Program: http://www.opnet.com/services/university
Trillium (n.d.) Multiprotocol Label Switching (MPLS) The International Engineering
Consortium Retrieved February 18, 2004 from
http://www.iec.org/online/tutorials/acrobat/mpls.pdf