Sie sind auf Seite 1von 49

UNIVERSITY OF NAIROBI

DEPARTMENT OF ELECTRICAL AND INFORMATION


ENGINEERING

SIMULATION OF MULTI-PROTOCOL LABEL SWITCHING

Project Index: 124

By

Geoffrey Omeke Mosongo


F17/2367/2009

Supervisor: Dr. G.S.O Odhiambo

Examiner: Prof. V.K Oduol

Project report of the final year project towards partial fulfillment of the
requirements for the degree of Bachelor of Science in Electrical and Electronic
Engineering of the University of Nairobi

Submitted on: April 28, 2014


Computer Simulation of Multi-Protocol Label Switching

DECLARATION OF ORIGINALITY

NAME: MOSONGO GEOFFREY OMEKE

REGISTRATION NUMBER: F17/2367/2009

COLLEGE: Architecture and Engineering

FACULTY/SCHOOL/INSTITUTE: Engineering

DEPARTMENT: Electrical and Information Engineering

COURSE NAME: Bachelor of Science in Electrical and Electronic Engineering

TITLE OF WORK: Computer Simulation of Multiprotocol Label switching

1) I understand what plagiarism is and I am aware of the University Policy in this regard.
2) I declare that this final year project report is my original work and has not been submitted
elsewhere for examination, award of degree or publication. Where other peoples work or
my work has been used, this has properly been acknowledged and referenced in
accordance with the University of Nairobis requirements
3) I have not sought or used the services of any professional agencies to produce this work
4) I have not allowed, and shall not allow anyone to copy my work with the intention of
passing it off as his/her own work
5) I understand that any false claim in respect of this work shall result in disciplinary action,
in accordance with the University anti-plagiarism policy

Signature: ..........

Date: ...

[i]
Computer Simulation of Multi-Protocol Label Switching

ABSTRACT
Multiprotocol Label Switching (MPLS) is a ubiquitous technology used by Internet Service
Providers and enterprise networks to forward packets. This project shall present a description of
Multiprotocol Label Switching architecture and its functionality through a computer simulation
model. An MPLS network will be simulated and its performance measured. Analysis of results
related to latency, link utilization, amount of traffic in the Label Switched Paths (LSPs) and
throughput within nodes in the network shall be done to show the key performance metrics of
MPLS. The simulation tool used in this project is OPNET Modeler version 14.5 from Riverbed
Technologies.

[ii]
Computer Simulation of Multi-Protocol Label Switching

ACKNOWLEGEMENT

I would like to thank my parents for their encouragement and prayers during the time I was
undertaking this project. Their enormous support gave me the energy and ability to complete
this task.

I would also like to thank my project supervisor Dr. GSO Odhiambo for all the guidance that
he accorded me during this period.

I would also like to recognize Mr. Paul Msava and Mr. Eric Gaitho from Safaricom Limited
for their guidance and support that enabled me complete this work successfully, may God
Almighty bless them in their endeavors.

This project work is dedicated to the final year Electrical Engineering class of 2014 at the
University of Nairobi for all the best moments we had together.

[iii]
Computer Simulation of Multi-Protocol Label Switching

Table of Contents
DECLARATION OF ORIGINALITY ...........................................................................................................................i
ABSTRACT ................................................................................................................................................................. ii
ACKNOWLEGEMENT.............................................................................................................................................. iii
Table of Contents..........................................................................................................................................................iv
LIST OF FIGURES ......................................................................................................................................................vi
ABBREVIATIONS ............................................................................................................................................... viii
1. INTRODUCTION .................................................................................................................................................1
2. SHORTEST PATH ROUTING PRINCIPLE........................................................................................................3
2.1 Shortest path routing principle and its drawbacks ...............................................................................................4
3. MPLS TECHNOLOGY OVERVIEW ..................................................................................................................7
3.1 MPLS Label .................................................................................................................................................7
3.2 MPLS Network Architecture ...............................................................................................................................8
3.2.1 Label Switched path (LSP) ......................................................................................................................9
3.2.2 Forwarding Equivalence Class (FEC)......................................................................................................9
3.2.3 Label Distribution Protocol (LDP) ..........................................................................................................9
3.3 MPLS Control Plane and Forwarding plane ................................................................................................9
3.4 Path Determination.....................................................................................................................................11
3.4.1 Offline Path calculation .........................................................................................................................11
3.5 Constraint-Based Routing (CBR)...............................................................................................................11
3.6 MPLS Signaling Protocols.........................................................................................................................12
3.6.1 LDP........................................................................................................................................................12
3.6.2 CR-LDP .................................................................................................................................................13
3.7 Label Merging............................................................................................................................................13
3.8 Traffic Engineering in MPLS Networks ............................................................................................................14
3.8.1 Distribution of Topology information ...................................................................................................14
3.8.2 Path selection .........................................................................................................................................14
3.8.3 Directing traffic along the computed paths ..............................................................................................14
3.8.4 Traffic Management ..............................................................................................................................14
4. NETWOTK MODEL AND SIMULATION .......................................................................................................17
4.1 Simulation Tool .................................................................................................................................................17
4.2 OPNET Model Configuration Objects...............................................................................................................17
4.3 OPNET Simulated Application Traffic .............................................................................................................18
4.4 Network Topology.............................................................................................................................................19
4.5 Description of the Topology ..............................................................................................................................20
4.6 OSPF Simulation Scenario ................................................................................................................................20
4.7 RESULTS..........................................................................................................................................................21
4.8 Analysis and Discussion ....................................................................................................................................23
4.8.1 OSPF Throughput .......................................................................................................................................23

[iv]
Computer Simulation of Multi-Protocol Label Switching

4.8.2 Queuing delay.............................................................................................................................................24


4.9 MPLS Simulation Scenario ...............................................................................................................................24
4.10 MPLS SCENARIO RESULTS........................................................................................................................27
4.11 Analysis and Discussion ..............................................................................................................................29
4.11.1 Throughput.............................................................................................................................................29
4.11.2 Queuing delay ........................................................................................................................................31
5. CONCLUSION ...................................................................................................................................................32
6. REFERENCES ....................................................................................................................................................33
7. APPENDIX .........................................................................................................................................................35
7.1 APPENDIX A: PROCEDURE FOR MODELLING OSPF EXPERIMENT ....................................................35
7.2 APPENDIX B: PROCEDURE FOR MODELLING MPLS EXPERIMENT ...................................................37

[v]
Computer Simulation of Multi-Protocol Label Switching

LIST OF FIGURES
Fig 2.1 Illustrated architecture of a backbone of an ISP ...3

Fig 2.2 Illustrated model of an Autonomous system ...3

Figure 2.3 Forwarding based on shortest path (minimum cost) ....5

Figure 2.4 Illustration of under-utilized paths in the backbone 6

Figure 2.4 Illustration of optimized backbone link utilization ...6

Fig. 3.1 MPLS Header ........7

Fig. 3.2 MPLS Network Architecture and node types ...8

Fig. 3.3 MPLS Network Illustration .10

Fig 4.1: Overview of the experiential network model ...19

Fig 4.2 TCP and UDP Throughput (Bits/second ..21

Fig 4.3 TCP and UDP Throughput (Packets/second) ..21

Fig 4.4 Throughput Shortest Path (bits/sec)..21

Fig 4.5 Average Link Utilization Shortest path 21

Fig 4.6 Queuing delay shortest path .22

Fig 4.7 Queuing delay longest path 22

Fig 4.8 Utilization Longest Path ...22

Fig 4.9 Longest path Throughput (bits/sec)...22

Fig 4.10 Network for MPLS simulation scenario..25

Fig 4.11 TCP and UDP Throughput (Bits/second)...27

Fig 4.12 TCP and UDP Throughput (Packets/second).27

Fig 4.13 Traffic In and Out of PE_1 -PE_2 (Bits/second) ...27

Fig 4.14 Average LSP PE_1 - PE_2 Delay (sec) ..27

Fig4.16 LSP PE_1 PE1_2 1 Delay (sec)28

[vi]
Computer Simulation of Multi-Protocol Label Switching

Fig 4.15 Traffic In and Out of PE_1 -PE_2 1 (Bits/sec)...28

Fig 4.17 Traffic In and Out of PE_2 -PE_1 (Bits/second) ...28

Fig4.18 LSP PE_2 PE_1 Delay (Seconds) 28

Fig 4.19 Traffic In and Out of PE_2 -PE_1 1 (Bits/second) 29

Fig 4.20 LSP PE_2 PE1_1 1 Delay (sec) ..29

[vii]
Computer Simulation of Multi-Protocol Label Switching

ABBREVIATIONS

CSPF Constraint Shortest Path First


CR-LDP Constraint based Label Routing Protocol
FEC Forward Equivalence Class
IP Internet Protocol
IPv4 -- Internet Protocol version 4
ISIS Intermediate System to Intermediate System
IGP Interior Gateway Protocol
LDP Label Distribution Protocol
LER Label Edge Router
LFIB Label Forwarding Information Base
LSP Label Switch Path
LSR Label Switch Router
MPLS Multi Protocol Label Switching
OPNET Optimized Network Engineering Tool
OSPF Open Shortest Path First
RSVP Resource Reservation Protocol
SPF Shortest Path First
TCP Transmission Control Protocol
TE Traffic Engineering
TED Traffic Engineering Database
UDP User Datagram Protocol
VPN Virtual Private Network

[viii]
Computer Simulation of Multi-Protocol Label Switching

1. INTRODUCTION
In the recent past there has been an enormous growth in the use of Internet. This rapid growth
has made a huge impact on the type of services requested from consumers and the kind of
performance they demand from the services they wish to use. Consequently as service providers
encourage businesses on the Internet, there has been a requirement for them to develop, manage
and improve IP- network infrastructure in terms of performance. Therefore, the interest of traffic
control through traffic engineering has become important for ISPs. Multi-Protocol Label
Switching (MPLS) is an emerging technology which plays an important role in the next
generation networks by providing Traffic Engineering (TE). It overcomes the limitations like
excessive delays and high packet loss of IP networks by providing scalability and congestion
control. Due to the low latency and low packet loss during routing of packets MPLS is
considered ideal for mission critical applications.

Todays networks often function with well-known shortest path routing protocols. Shortest path
routing protocols as their name implies, are based on the shortest path forwarding principle. In
short, this principle is about forwarding IP- traffic only through the shortest path towards their
destination. At one point, when several packets destined from different networks start using
the same shortest path, it may become heavily loaded. This will result in congestion within
the network. Various techniques have been developed to cope with the shortest path routing
protocols shortcomings. However, recent research has come up with another way to deal with
the problem. With traffic engineering, one can engineer traffic through other paths than the
shortest path. The network carries IP-traffic, which flows through interconnected network
elements, including response systems such as protocols and processes. Traffic engineering
establishes the parameters and operating points for these mentioned elements. Internet
traffic leads to control problem. Therefore a desire and need for better control over the traffic
may be accomplished with help of Traffic Engineering (TE).

The main objective of this project is to study and understand Multiprotocol Label Switching
architecture and functionality. The specific objectives are:

F17/2367/2009 - University of Nairobi Page 1


Computer Simulation of Multi-Protocol Label Switching

Designing a topology to simulate an MPLS network


Choosing the performance parameters such as latency, link utilization, amount
of traffic in the Label Switched Paths (LSPs) and throughput within nodes
Analysis of the results and showing them graphically

In order to outline the performance achieved by traffic engineering, it was necessary to start by
giving a description of the shortest path routing principle and its drawbacks. Then, the
architecture of Multiprotocol Label Switching shall be presented together with its functionality.

After giving a description of the technology, the simulation network is presented to measure its
performance. Initially, the network is configured to run shortest path routing protocol OSPF. To
measure performance outbreaks, TCP and UDP traffic is generated to measure their treatment
under a heavily loaded network. Then, the same network with its traffic once again is used, this
time implementing Multiprotocol Label Switching to engineer the flows to separate paths.
Results collected from both scenarios are then analyzed and shown graphically.

F17/2367/2009 - University of Nairobi Page 2


Computer Simulation of Multi-Protocol Label Switching

2. SHORTEST PATH ROUTING PRINCIPLE


The internet today consists of multiple service providers network connected to each other,
forming a global network communication infrastructure. This infrastructure enables people
around the world to communicate with each other through interconnected network devices.
These devices are set up to process any data that traverse through them. The devices or nodes are
often formed in logical and hierarchical way. With customers networks connected to a node or a
router often called customer edge router (CE) at one end, and to an Internet service
providers (ISP) network edge router, which is referred to as provider edge router (PE) at the
other end. The core routers within the providers network form the inner routers forwarding
packets a step closer to its destination. These often smaller autonomous systems (AS) are then
connected to more powerful networking area referred to as the backbone. The backbone often
carries the extensive amount of traffic that is to be transmitted or/and received between ASs. An
example over such architecture is given in the figure below.

Fig 2.1 Illustrated architecture over backbone of an ISP

Fig 2.2 Illustrated model of an Autonomous system

F17/2367/2009 - University of Nairobi Page 3


Computer Simulation of Multi-Protocol Label Switching

An AS may look like the one illustrated in figure 2. In order to make right delivery of packets
received from the customers networks, routers must exchange information with each other. In
short, the routing and forwarding mechanism is primarily divided into three processes. The first
process is mainly responsible for exchanging topology information. This is needed for the
second part of the process, which is the calculation of routes. Calculation happens
independently within each router to build up a forwarding table. The forwarding table enables
processing incoming packets to be forwarded towards its destination. The forwarding table is
used when a packet is being forwarded and therefore must contain enough information to
accomplish the forwarding function.

Within an AS, routing is based on Interior Gateway Protocols (IGPs) such as Routing
Information Protocol (RIP) [5], Open Shortest Path First (OSPF) [3] and Intermediate System-
Intermediate System (IS-IS) [6]. RIP is based on the distance vector algorithm and always
tries to find the minimum hop route. Routing protocols such as OSPF and IS-IS are more
advanced in the sense that routers exchange link state information and forward packets along
shortest path based on Dijkstras algorithm [2]. In short, Dijkstras algorithm computes the
shortest path from every node to every other node in the network that it can reach. This is of
course a highly simplified description. With help of Dijkstras algorithm, every node can
compute the shortest path tree to every destination [2].

2.1 Shortest path routing principle and its drawbacks


The shortest path routing principle imposes some drawbacks within the routing area. The
scenario in Figure 2.3 illustrates the forwarding of packets based on the shortest path
algorithms. Looking at the figure 2.3, it can be assumed that routers 1, 2, 3, and 4 form a
smaller piece of a larger AS or backbone. Traffic is coming in from both R_1 and R_2 and
destined for the same terminating router R_7 through router R_7. In this case, congestion may
appear after a while between router R_3 and router R_4 since all the packets are sent over the
minimum cost (high bandwidth) path to its destination. It uses only one path per source
destination pair, thereby potentially limiting the throughput of the network [2].

To give an example of the impacts this may pose in the network, the following is considered: It
is known that TCP connections tend to lower their transfer rate when signs of congestion
appears, consequently making more room for UDP traffic to fill up the link and suppress the

F17/2367/2009 - University of Nairobi Page 4


Computer Simulation of Multi-Protocol Label Switching

TCP flows [4]. This causes the UDP traffic sent by one of the sources suppress the TCP flows
sent by the other sources. Clearly, the situation can be avoided if the TCP and UDP traffic
choose different non-shortest paths to achieve a better performance.

Congestion in the network is caused by lack of network resources or uneven load balancing of
traffic. The latter one is the one that can be remedied by traffic engineering, which is the major
advantage of MPLS. If all packets sent from customers use the same shortest path to their
destination, it may be difficult to assure some degree of QoS and traffic control. There are of
course ways to support every single traffic flow with different technologies to assure QoS. For
instance, a signaling protocol may be used to reserve resources for a certain flow travelling
through the network, but this will only be per-flow basis and when many of these are configured
it makes it impractical for an ISP to manage and administer, since it isnt a scalable solution
[7]. This can be proven by a simple formula, which states that if there exist N routers in the
topology and C classes of services, it would be needed (N* (N-1) * C) trunks containing traffic
flows [7].

Figure 2.3 Forwarding based on shortest path (minimum cost)

The other problem with the shortest path routing protocols is the lack of ability to utilize the
network resources efficiently [1]. This is not achieved by the shortest path routing protocols
since they all just depend on the shortest path [1]. This is illustrated in the below figure, where
packet from both networks connected to R2 and R8 traverse through the path with minimum
cost, leaving other paths underutilized. Its capability to adapt to changing traffic conditions is
limited by oscillation effects. If the routers flood the network with new link state advertisement
messages based on the traffic weight on the links, this could result in changing the shortest path

F17/2367/2009 - University of Nairobi Page 5


Computer Simulation of Multi-Protocol Label Switching

route. At one point, packets are forwarded along the shortest path, and suddenly right after
exchange of link states advertisement choosing another shortest path through the network. The
result may again be poor resource utilization [2]. This unstable characteristic has more or less
been dealt with in the current version of OSPF, but with the side effect of been less sensitive to
congestion and speed of response to it [2].

Figure 2.4 Illustration of under-utilized paths in the backbone

Looking at figure 2.5, it can be seen that a more balanced network has been achieved when
traffic from networks connected to R2 and R8 start using the underutilized paths of figure 2.4

Figure 2.5 Illustration of optimized backbone link utilization

F17/2367/2009 - University of Nairobi Page 6


Computer Simulation of Multi-Protocol Label Switching

3. MPLS TECHNOLOGY OVERVIEW


Multiprotocol Label Switching (MPLS) is a high performance technology that enables a much
faster switching of packets making up a data stream. [15]. Main MPLS processing and sorting
of packets takes place only once at the beginning of a connection. MPLS has turned out to be
the most efficient technology for efficiently managing and operating IP networks. Common areas
of application of the protocol could include:

Switching of connections for real time data streams (such as video, multimedia or Voice
over IP [VoIP])
Creation of virtual private networks (VPNs)

MPLS is however not a replacement of the IP network but a reinforcement of its functionality. A
label is added to the packet header once it enters the MPLS domain. A label is a short fixed
entity with no internal structure. The label alone will control the switching process along the
entire length of the connection directing it along the previously determined path without
requiring further unpackaging or processing of the normal IP header.

3.1 MPLS Label


The flow label consists of 20 bits (Corresponding to approximately one million labels). Its length
is shorter compared to IPv4 (32 bits wide) and IPv6 (128 bits wide). This in effect adds to the
speed with which packets can be processed and switched by intermediate routers. The labels are
either interface-significant labels or domain-significant labels. An interface-significant label is
recognized only at a single interface by the two routers at the end of that interface. In domain
significant labeling, the same label will be used for the same FEC by all routers within the MPLS
domain.

An MPLS label will be defined inside the MPLS-SHIM header which is 32 bit wide and
organized as shown in the figure below.

20-Bit Label EXP (3 Bits) (S) TTL (8 Bits)

Fig. 3.1 MPLS Header

F17/2367/2009 - University of Nairobi Page 7


Computer Simulation of Multi-Protocol Label Switching

The labels on the packets are established by using Forwarding equivalence class (FEC).
Following the Label field there are 3 bits EXP field which is known as Traffic class field (TC
field) this is used for Quality of Service (QoS) related functions. Next field is called stack field
which is 1 bit field and this is used to indicate bottom of label stack. The tail consist 8-bit TTL
(Time to Live) field which has a similar functionality as that of the TTL field in the IP header

3.2 MPLS Network Architecture


MPLS domains form a part of a given administrations network comprising of MPLS-capable
routers at the backbone. These routers are referred to as Label Switched Routers (LSRs) The
MPLS domain is thus typically surrounded by an IP-routing domain used at its periphery to
connect more remote devices. There are different types of nodes (LSRs) which together form an
MPLS domain as shown in the figure 3.2 below:

MPLS nodes Routers capable of supporting MPLS services


MPLS edge nodes nodes at the edge of an MPLS domain. They convert other
network layer protocols into the MPLS format or provide for gateway functions
between different MPLS domains.
MPLS ingress nodes these are edge nodes at the point where MPLS traffic is
originated usually by entering from a non-MPLS routing domain.
MPLS egress nodes these are MPLS edge nodes at the point where the data flow
leaves the MPLS domain for delivery via a non-MPLS domain.
Intermediate LSR They receive an incoming labeled packet, perform an operation
on it, switch the packet and send it to the correct data link [16].

Fig. 3.2 MPLS Network Architecture and node types

F17/2367/2009 - University of Nairobi Page 8


Computer Simulation of Multi-Protocol Label Switching

Other terms used in MPLS technology are explained as follows;

3.2.1 Label Switched path (LSP)


A Label Switched Path (LSP) is a series of LSRs that switch a labeled packet through an MPLS
network or part of an MPLS network. In MPLS domain, there exists a number of LSPs that
originate at the Ingress node, traverses one or more intermediate nodes and terminate at the
Egress node

3.2.2 Forwarding Equivalence Class (FEC)


This can be visualized as describing a group of IP packets that are forwarded in the same
manner, over the same path, with the same forwarding treatment [10]. All packets belonging to
the same FEC have the same label. However, not all packets containing the same label belong to
the same FEC, because their FEC values might differ, their forwarding treatment could differ and
they could belong to a different FEC. Each packet in MPLS network is assigned with FEC only
once at the Ingress node.

3.2.3 Label Distribution Protocol (LDP)


It is a protocol in which the label mapping information is exchanged between LSRs. It is
responsible in establishing and maintaining labels

3.3 MPLS Control Plane and Forwarding plane


Nodes in an MPLS domain have two architectural planes: control plane and forwarding plane
[11]. A LSR is able to process both conventionally routed IP packets and MPLS routed packets,
so both the control plane and the forwarding plane has functionalities for both IP and MPLS. The
control plane is the IP routing protocols and the label distribution protocol used. The forwarding
plane is the conventional IP forwarding and the MPLS Forwarding.

The control plane maintains and controls the forwarding table by learning the network topology
from the routing protocols such as OSPF, IS-IS and BGP. It is responsible for building the MPLS
IP routing control by updating the label bindings which are exchanged between the routers. The
forwarding plane is the conventional IP forwarding and the MPLS Forwarding.

The forwarding plane is the conventional IP forwarding and the MPLS Forwarding. The MPLS
forwarding plane forwards packets according to the labels attached to packets. The MPLS
forwarding can perform different label actions according to the instructions in the NHLFE (next

F17/2367/2009 - University of Nairobi Page 9


Computer Simulation of Multi-Protocol Label Switching

hop label forwarding entry) and in the Incoming Label Map (ILM) table at each node. In MPLS
routers control plane and data plane are separated entities. This separation allows the deployment
of a single algorithm that is used for multiple services and traffic types.

The label-swapping forwarding algorithm explains how the packets are routed in the MPLS
domain which is described in the following steps.

When a packet enters the MPLS domain a label of short fixed-length is inserted in the
packet header by the Ingress router. FEC is identified from the label.

The packets belonging to one particular FEC are forwarded through the same path
through the MPLS network even though all the packets do not have the same destination
address.

The path on which the packets are forwarded to the next hop in the network is LSP.

Every hop in MPLS network forwards the packets based on the label but not on IP
address. This is done until the packets reach the final hop in MPLS network and then the
label is removed by Egress router and normal IP forwarding resumes.

Here the Ingress and Egress routers are the LERs and the hops within the MPLS domain
are LSRs which is shown in Fig.3.3

Fig. 3.3 MPLS network illustration

The following is the brief description of MPLS routing:

MPLS uses signaling protocols to establish the paths. Label Distribution Protocol is the signaling
protocol and the paths established are called Label Switched path. Routers that support MPLS
are Label Switched Routers (LSRs). The LSRs which are located at the edges of MPLS are

F17/2367/2009 - University of Nairobi Page 10


Computer Simulation of Multi-Protocol Label Switching

called Label Edge Routers (LERs). All the packets enter or exit the MPLS domain through
LERs. In Fig.3 LER_1, LER_2, LER_3 and LER_4 are the Labe Edge Routers. LER_2 is the
Ingress router which maps the incoming traffic into the MPLS domain. LER_3 is the Egress
router through which the packets exit from the MPLS domain. An LSP originates at Ingress
router and travels through one or more LSRs and terminates at Egress router.

When packet enters the MPLS domain, labels are inserted in their headers by Ingress router and
the packets are mapped on to the LSP using Forwarding Equivalence Class (FEC).All the
packets which match a Particular FEC, are forwarded on the same LSP. The FEC is described by
the set of attributes e.g. destination IP, type of service etc. The core LSRs (which are LSR_1,
LSR_2 and LSR_3 in the Fig.3) forwards the packets based on label information but not on
the IP address. When a router receives the packet it checks label information base (LIB) instead
of routing table and determines the next hop in MPLS domain.

Finally the Egress router LER_3 removes the label from the packet header and forwards the
packet to the next hop based on IP address and from here the conventional IP forwarding of
packets continues.

3.4 Path Determination


There are two main approaches used to determine the desired path for FECs; offline path
calculation and constraint based routing.

3.4.1 Offline Path calculation


The LSPs and FECs can be determined with an off line tool without the LSRs directly
participating in the process. The basic input to the tool is ingress and egress points, physical
topology and traffic estimates. Based on the inputs the tool can be used to calculate a set of
physical paths for LSPs that optimize the usage of the network resources. Then those routes can
be explicitly setup in the MPLS domain. This way of doing path calculations can lead to optimal
resource usage, predictable routing and stable network configurations.

3.5 Constraint-Based Routing (CBR)


With constraint based routing, network parameters (constraints) are used to determine the best
route a set of packets should take. Each LSR determines an explicit route for each traffic trunk
(aggregation of traffic flows) originating from that LSR based on bandwidth and cost of the links

F17/2367/2009 - University of Nairobi Page 11


Computer Simulation of Multi-Protocol Label Switching

and other topology state information. The LSP created is the route that satisfies the requirements
of the traffic and the constraints that are set.

Calculating a path that satisfies these constraints requires that the information about whether the
constraints can be met is available for each link, and this information must be distributed to all
the nodes that perform path calculation. This means that the relevant link properties have to be
advertised throughout the network. This is achieved by adding TE-specific extensions to the link-
state protocols ISIS and OSPF that allow them to advertise not just the state (up/down) of the
links, but also the links administrative attributes and the bandwidth that is available. In this way,
each node has knowledge of the current properties of all the links in the network. Once this
information is available, a modified version of the shortest-path-first (SPF) algorithm, called
constrained SPF (CSPF), can be used by the ingress node to calculate a path with the given
constraints. CSPF operates in the same way as SPF, except it first prunes from the topology all
links that do not satisfy the constraints.

3.6 MPLS Signaling Protocols


Signaling is a way in which routers exchange important information. In an MPLS network, the
type of information exchanged between routers depends on the signaling protocol being used. At
a base level, labels must be distributed to all MPLS enabled routers that are expected to forward
data for a specific FEC and LSPs created. The MPLS architecture does not assume any single
signaling protocol [12]. Therefore, for the purposes of this project report I will discuss only two
methods for label distribution.

Label Distribution Protocol (LDP)


Constrained Routing with LDP (CR-LDP)

3.6.1 LDP
It is designed for the explicit purpose of distributing MPLS labels, thus setting up LSPs in the
MPLS domain. It always selects the same physical path that conventional IP routing would
select. Thus LDP does not support TE. Because of the recent development in routing technology,
LDP is not much for label distribution today. There is however an extension to the original LDP
protocol that brings new functionality for the LDP protocol called CR-LDP.

F17/2367/2009 - University of Nairobi Page 12


Computer Simulation of Multi-Protocol Label Switching

3.6.2 CR-LDP
This is an extension of LDP that supports constraint-based routed LSPs. The term constraint
implies that in a network and for each set of nodes there exists a set of constraint that must be
satisfied for the link or links between two nodes to be chosen for an LSP. An example of a
constraint is to find a path that needs a specific amount of bandwidth.

LSRs that use CR-LDP to exchange label and FEC mapping information are called LDP peers;
they exchange this information by forming a LDP session. There are four categories of LDP
messages:

Discovery messages announce and maintain the presence of an LSR in an MPLS domain. This
message is periodically sent as a Hello message through a UDP port with the multicast address of
all routers on this subnet.

Session message is sent to establish, maintain and delete sessions between LDP peers.

Advertisement messages create, change and delete label mappings for FECs.

Notification Messages provides status, diagnostic and error information.

3.7 Label Merging


If multiple LSPs arriving at a LSR have different incoming labels but are to be forwarded the
same path towards the egress router, then these LSPs may not need to be treated as separate LSPs
for the rest of the path [13]. If the FECs carried by these LSPs can be aggregated, this can be
seen as an aggregation of traffic. Then those LSPs can be merged together and switched using a
common label. This is known as label merging or aggregation of flows.

Aggregation can reduce the number of labels needed to handle a particular set of packets and can
also reduce the amount of label distribution traffic needed. An LSR is capable of label merging if
it can receive two packets from different incoming interfaces, with different labels, and send both
packets out the same outgoing interface with the same label without the use of the label stack.
Once the packets are sent, the information that they arrived from different interfaces with
different labels is lost and they are treated as one flow.

F17/2367/2009 - University of Nairobi Page 13


Computer Simulation of Multi-Protocol Label Switching

3.8 Traffic Engineering in MPLS Networks


Traffic Engineering (TE) is a mechanism that controls the traffic flows in the networks and
provides performance optimization by optimally utilizing the network resources [14]. Some of
the key features of TE are resource reservation, fault-tolerance and optimum Resource
utilization. Important factors needed for TE include:

Distribution of Topology information


Path selection
Directing traffic along the computed paths
Traffic Management

3.8.1 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 failures have to be rapidly propagated through the networks, this makes
the problem to be fixed quickly [15].

3.8.2 Path selection


This process involves computing the path information between nodes in the network. The
shortest path with minimum links is selected. The other constraints like bandwidth and delay is
also considered during the path selection.

3.8.3 Directing traffic along the computed paths


Traffic is forwarded along the particular calculated path between source and destination
node. Typically this is achieved by forwarding table.

3.8.4 Traffic Management


Traffic management deals with the process of forwarding the traffic with the predictable
quality. The parameters such as bandwidth, delay, jitter and packet loss are the main concern
for the traffic management.

The main objective of considering TE is to efficiently use the available network resources and
increase service quality of applications on the Internet. The motivation behind MPLS TE is

F17/2367/2009 - University of Nairobi Page 14


Computer Simulation of Multi-Protocol Label Switching

Constraint Based Routing (CBR) which takes bandwidth, policies and network into
consideration for establishing a path (LSPs) in MPLS domain to forward the packets.

Constraint Based Routing (CBR) takes bandwidth, policies and network into consideration for
establishing a path (LSPs) in MPLS domain to forward the packets. In this case:

All links in the domain should be characterized with traffic engineered attributes
The configured attributes must be advertised to all routers in the IGP area
A constraint path calculation mechanism to be implemented at each node

There is obviously a need of routing protocol and possibly the link state algorithm to convey
link attributes among nodes. Rather than developing a new routing protocol specific for this
purpose, existing link state protocols are extended to support CBR, hence results in ISIS TE and
OSPF-TE. The set of newly added attributes include:

Traffic Engineered (TE) metric, other than IGP metric to be configured upon the
links
Maximum Bandwidth, the TE link capacity
Maximum Reserve Bandwidth, how much bandwidth on a link can be reserved
(TE pool)
Unreserved Bandwidth, still available bandwidth on a link from TE pool
Administrative Group

TE metric: is a value assigned at a specific link for TE calculation, if TE metric is not


configured across the links then by default IGP-TE takes into account IGP metric at that link. It
is also considered to be TE administrative weight over the TE capable links

Maximum bandwidth: A static value configured by operator at each link. A configurable value
across a link can be greater than the actual link capacity resulted in over provisioning the links,
while keeping in mind the constraint that not all the circuits passing through an over provisioned
link should be active at the same time.

Unreserved bandwidth: This value changes on every TE-LSP setup/tear down and the
updated information is sent across the domain. Flooding the value upon every change,
results in number of Traffic Engineered Link State Advertisements (TE-LSA) to be sent per

F17/2367/2009 - University of Nairobi Page 15


Computer Simulation of Multi-Protocol Label Switching

unit time, and TE network is susceptible to being unstable. Link state protocol calculation is
distributed mostly; each node requires full information regarding network statistics.

Administrative group: A 32-bit value used as a flexibility mechanism across TE


links. Each administrative group bit can be used to specify different parameters of a TE link.
Link can be marked optionally with different values (or colors) which can be understood
generally in terms of a tag on the link. Each color/value corresponds to a specific property as
latency, delay, packet loss. Thus, it provides interfaces statistics using attribute names expressed
in strings [16].

F17/2367/2009 - University of Nairobi Page 16


Computer Simulation of Multi-Protocol Label Switching

4. NETWOTK MODEL AND SIMULATION


4.1 Simulation Tool
In this project, OPNET Modeler was used. Optimized Network Performance (OPNET) is a
discrete event simulation tool. It provides a comprehensive development environment
supporting the modeling and simulation of communication networks. This contains data
collection and data analysis utilities. OPNET allows large numbers of closely spaced events in
a sizeable network to be represented accurately. This tool provides a modeling approach where
networks are built of nodes interconnected by links. Each nodes behavior is characterized by
the constituent components. The components are modeled as a final state machine. Details of
OPNET Modeler 14.5 can be found in [17, 18]

4.2 OPNET Model Configuration Objects


The network components as used in this project work from OPNET library include:

ethernet_wkstn: Ethernet workstation OPNET element is used to simulate the network users. It
consists of single Ethernet connection at a selected rate, directed by the underlying medium used
to connect to an Ethernet switch.

ethernet_server: Ethernet server provided in OPNET is used to simulate the service server in
the network. It contains one Ethernet connection to the switch, facilitating that subnet.

Cisco 7200 router: Router model capable of supporting MPLS

100BaseT: This is a full duplex link operating at 100 Mbps used to connect the ethernet_server
and Ethernet_wkstn to the Cisco 7200 series routers

PPP_E3: This is a duplex link connecting two nodes running IP at a rate of 34.368 Mbps. It was
used to connect the Cisco 7200 routers

MPLS_E-LSP_STATIC: Static LSP are not signaled during the startup. They allow more
routing control

Application Config: This element is used to tell OPNET which application is going to be
modeled upon the underlying network. A single Application Config. is used to instruct OPNET
for multiple network applications. Application parameters for different application types being
observed are configured in this element.

F17/2367/2009 - University of Nairobi Page 17


Computer Simulation of Multi-Protocol Label Switching

Profile Config: Profiles describe the activity patterns of a user or group of users in
terms of the applications used over a period of (simulation) time [25]. There can be several
different profiles running on a given network under observation. User profiles have diverse
properties, so configuring a certain profile with a specific application was done here. The
configured profiles are then assigned to the network users.

mpls_config_object: Configuring MPLS FEC and Traffic Trunk is done under this
element configuration. The configured specification is used at the Ingress Edge router to direct
the traffic flows and assign different LSP to different application traffic.

4.3 OPNET Simulated Application Traffic


FTP Traffic: FTP stands for File Transfer Protocol. It is used to generate traffic flow from the
FTP server towards the FTP client (CE_1), thus simulating file downloading based upon the
request from the client. The FTP traffic characteristics are provided in the figure 1 below.

Table 4.1: FTP traffic Configuration in OPNET

Video Conferencing Traffic: The video conferencing inherits the mentioned characteristics. It is
given a TOS value which equals to DSCP AF41. The traffic generated by Video application per
second includes:

(128x240 byes) (15 frames per second) = 3,686,400 bits/second

F17/2367/2009 - University of Nairobi Page 18


Computer Simulation of Multi-Protocol Label Switching

Table 4.2: Video Conferencing traffic Configuration in OPNET

4.4 Network Topology


Figure 4 .1 illustrates the networking topology that was used. The network topology cannot be
said to be a realistic operational network. The intention was to create a networking environment,
which could represent a part of an overall network topology of an ISP network. The model
suite supported workstations, servers, routers, and link models. Cisco 7200 access routers were
used at the edge of the network where the traffic was transmitted to or received from the
workstations and the servers.

Fig 4.1: Overview of the experiential network model.

F17/2367/2009 - University of Nairobi Page 19


Computer Simulation of Multi-Protocol Label Switching

4.5 Description of the Topology


Two applications were configured which used TCP and UDP as their transport protocol. With
these applications generating traffic, the intention was to measure the treatment of these traffic
types when shortest path routing and MPLS is implied. Since most of the traffics getting
transmitted in todays Internet use TCP or UDP as transport protocols, these protocols were the
right choice for experiments within the simulations.

We gave the network approximately two minutes before traffic generation was triggered. This
was done to make sure the routers had enough time to exchange topology information and
building up their routing tables. From the second minute, file transfer application was triggered
to start, making TCP to transport its packets through the network. TCP traffic intensity was set
to 50,000,000 bytes of files downloaded from the server. The other application was set to start
one minute later transporting its packets with UDP transport protocol. The traffic intensity for
UDP was set to 3,686,400 bits/second.

The maximum transmission unit (MTU) was set to the Ethernet value of 1500 bytes. The MTU
specify the IP datagram packet that can be carried in a frame. When a host sends an IP
datagram, therefore, it can choose any size that it wants.

With reference to figure3, CE_1 was to communicate with the FTP_SERVER using the file
transfer application, meaning it would start generating the TCP traffic intensity described above
at the second minute. CE_2 on other hand, were to use the video conferencing application, thus
making it to generate UDP traffic one minute later. The UDP traffic was transmitted to CE_3,
which accepted video conferencing related UDP traffic.

4.6 OSPF Simulation Scenario


The first scenario was created to highlight some of the shortest path routing principle
characteristics as mentioned in chapter 2. Specifically, the parameters of interest are,
throughput, link utilization and queuing delay issues when traffic flows compete for same scarce
resources under overloaded situations. All paths were set to an equal cost of 100. All the routers
were configured using only Open Shortest Path First (OSPF) as their routing protocol. Details
over configurations of network nodes and traffic implementations within OPNET can be
reviewed in appendix A.

F17/2367/2009 - University of Nairobi Page 20


Computer Simulation of Multi-Protocol Label Switching

4.7 RESULTS

Fig 4.2 TCP and UDP Throughput (Bits/second) Fig 4.3 TCP and UDP Throughput (Packets/second)

Fig 4.4 Throughput Shortest Path (bits/sec) Fig 4.5 Average Link Utilization Shortest path

F17/2367/2009 - University of Nairobi Page 21


Computer Simulation of Multi-Protocol Label Switching

Fig 4.6 Queuing delay shortest path Fig 4.7 Queuing delay longest path

Fig 4.8 Utilization Longest Fig 4.9 Longest path Throughput (bits/sec)

F17/2367/2009 - University of Nairobi Page 22


Computer Simulation of Multi-Protocol Label Switching

4.8 Analysis and Discussion

4.8.1 OSPF Throughput


From the configuration, CE_1 was set to send and receive two 50,000,000 byte files over the
simulation time starting the second minute. Observing from the collected statistics the maximum
transfer rate achieved was 3,484,036.93333333 bits/second during the 234th second.

A minute later, CE_2 started generating UDP traffic. From the configuration, CE_2 is sending
and receiving video conferencing traffic at the Ethernet NIC card. The maximum transmission
rate recorded was 6,010,935.25333333 bits/second during the 600th second of the simulation.

Keeping in mind that both traffic utilized their links towards the ingress router, it was registered
that the UDP traffic intensity had a tremendous effect on the TCP traffic intensity. These effects
were registered between clients and the ingress router PE_1 every time UDP- traffic intensity
was being transmitted. Figure 4.2 and 4.3 shows that the TCP throughput starts falling, when the
video client starts generating traffic. This causes TCP throughput to fall to
1,935,580.07407407 bits/second during the 210 th minute. The UDP traffic does not care about
congestion within the network, continuing transmitting its traffic regardless of packets managing
to arrive at the intended destination.

Figure 4.3 shows the amount of packets sent from the clients towards the server. Observing the
registered result, it was witnessed that each times UDP- traffic increased its traffic intensity; the
TCP traffic intensity lowered y equally.

However, some increase was registered right after such incidents. It can be said that these
increases of intensity made by TCP after each decreases are related to the fast retransmit
option of TCP RENO implementation.

The other statistical result gathered from the simulation were the throughput measured from
paths between routers that handled the traffic flows. Figures 4.4 and 4.9 shows the results
gathered from the simulation. It was observed that the throughput between routers combining
one path (PE_1, P_3, P_4, P_5, PE_2), were unutilized, while the other path (PE_1, P_1, P_2
and PE_2) were fully utilized. This indicated weakness of OSPF when it came to load balancing
the traffic.

F17/2367/2009 - University of Nairobi Page 23


Computer Simulation of Multi-Protocol Label Switching

From the figures, it was observed that the longest path had a stable amount of zero throughput.
The shortest path however, had a non-zero throughput which reached a maximum of
8,693,475.86531986 bits/second. It was also observed that the link was utilized all the time.

The overall picture that was aimed at here was the fact that OSPF routing protocol did not
utilize the network resources efficiently at times were traffic load conditions are heavy,
utilizing only the shortest path between any pair of ingress and egress routers. With this
functionality implied, bottlenecks arise and congestion takes place within the network. If the
network topology was more complex and other traffic was forwarded from other routers and
utilized this path towards some destination, the results may have been even worst from the
ones registered. In the real world of ISP networks, different traffic types may end up utilizing
the same shortest path, making it possible to achieve the same negative results at any point
between any routers that gets to become part of a shortest path. This force out congestion points
and bottlenecks within a network configured with a shortest path routing protocol.

4.8.2 Queuing delay


Some statistics concerning queuing delay and throughput from the edge and core routers were
also collected. From figure 4.8 and 4.9, it was registered that no activities were taking place
between routers combining the longest path. A delay of 0.000027963998 seconds was recorded,
which is negligible. This was due to the fact that the links remained unutilized within the
simulation time.

On the other hand, the queuing delay from PE_1 to P_1 grows every time the UDP traffic starts
generating its traffic intensity

Figure 4.6 shows that the queuing is much heavier between the ingress router and the first
router along the path. From the second router and after, the queuing delay has a stable value.
This indicates that heavy queuing only occurs between the first routers along the shortest path.
This is quite reasonable since the ingress router forwards enough packets that the link
connected to the first core router can carry.

4.9 MPLS Simulation Scenario


Figure 4.10 illustrates the MPLS simulation scenario. The preceding network model was copied
and the only changes made were the red, green and blue colored stretched arrows combining

F17/2367/2009 - University of Nairobi Page 24


Computer Simulation of Multi-Protocol Label Switching

label-switching paths through the experiential network. Below, details of the MPLS related
configurations shall be presented. For complete and more detailed specifications over this
experiential network, refer to appendix B

In order to be able to control flows of traffic, label-switching paths (LSPs) had to be installed.
Static LSPs were established; in order to have a more precise control over the path a flow was to
use. Flow specifications governed by the ingress router (PE_1) for traffics injected into the
network were also specified.

Fig 4.10 Network for MPLS simulation scenario

Four LSPs were created between the ingress router (PE_1) and the egress router (PE_2). Two
traffic trunks were specified for the traffic flowing through the LSPs. Trunk FTP was created to
engineer the traffic from the FTP client (CE_1) to the FTP server. Its specifications were as
shown in table 1 below

Table 4.3 FTP trunk profile specification

F17/2367/2009 - University of Nairobi Page 25


Computer Simulation of Multi-Protocol Label Switching

Trunk video was created to engineer video conferencing traffic from the video caller (CE_2) to
the video receiving client (CE_3). The specifications are indicated in table 2 below.

Table 4.4 Video trunk profile specification

Two Forwarding Equivalent Classes (FECs) were created, one for Video traffic (FEC Video)
based on the type of service DSCP AF41 and another for FTP traffic (FEC FTP) with the type of
service being DSCP AF11. Four Static LSPs were configured from PE_1 to PE_2 and from PE_2
to PE_1 to map the traffic as outlined below

PE_1 - P_1 - P_2 - PE_2 TCP traffic from the TCP client to the TCP server
PE_1 P_3 P_4 P_5 PE_2 Video conferencing traffic from CE_2 to CE_3
PE_2 - P_2 - P_1 - PE_1 -- TCP traffic from the TCP server to the TCP client
PE_2 P_5 P_4 P_3 PE_1 -- Video conferencing traffic from CE_3 to CE_2

Traffic binding was configured on PE_1: FEC FTP was bound to flow through LSP PE_1 - P_1
- P_2 - PE_2 from CE_1 while FEC Video was bound to flow through LSP PE_1 P_3 P_4
P_5 PE_2 from CE_2. The same was done with PE_2 with FEC FTP transporting traffic from
the FTP server through LSP PE_2 - P_2 - P_1 - PE_1. Video traffic from CE_3 was mapped to
FEC Video and bound to LSP PE_2 P_5 P_4 P_3 PE_1.

The following parameters were set on all routers: LDP was enabled, link discovery Hellos were
enabled, Loop Back interfaces were enabled and configured, LDP neighbors were set and finally
all the interfaces in the routers were enabled.

F17/2367/2009 - University of Nairobi Page 26


Computer Simulation of Multi-Protocol Label Switching

4.10 MPLS SCENARIO RESULTS

Fig 4.11 TCP and UDP Throughput (Bits/second) Fig 4.12 TCP and UDP Throughput (Packets/second)

Fig 4.14 Average LSP PE_1 - PE_2 Delay (sec) Fig 4.13 Traffic In and Out of PE_1 -PE_2 (Bits/second)

F17/2367/2009 - University of Nairobi Page 27


Computer Simulation of Multi-Protocol Label Switching

Fig4.15 LSP PE_1 PE1_2 1 Delay (sec) Fig 4.16 Traffic In and Out of PE_1 -PE_2 1 (Bits/sec)

Fig 4.17 Traffic In and Out of PE_2 -PE_1 (Bits/second) Fig4.18 LSP PE_2 PE_1 Delay (Seconds)

F17/2367/2009 - University of Nairobi Page 28


Computer Simulation of Multi-Protocol Label Switching

Fig 4.19 Traffic In and Out of PE_2 -PE_1 1 (Bits/second) Fig 4.20 LSP PE_2 PE1_1 1 Delay (sec)

4.11 Analysis and Discussion

4.11.1 Throughput
From the configuration, CE_1 was set to send and receive two 50,000,000 byte files over the
simulation time starting the second minute. Observing from the collected statistics indicated in
figure 4.11, the maximum transfer rate achieved was 1,923,004.16 bits/second during the 594th
second. UDP traffic was generated a minute later from CE_2 reaching a maximum transmission
rate of 3,017,570.373333 bits/second during the 594 th second. Keeping in mind that both traffic
utilized their links towards the ingress router, it was registered that the UDP traffic intensity
had some effect on the TCP traffic intensity. These effects took place over the simulation time.

The minimum value recorded by TCP traffic was 388,712.827586206 bits/second 168 second
after the simulation while a maximum of 1,923,004.16 bits/second was registered during the
594th second. The transients can be attributed TCP acknowledgements travelling from the server
back towards the client along the shortest path.

F17/2367/2009 - University of Nairobi Page 29


Computer Simulation of Multi-Protocol Label Switching

Another factor that is related to the ingress router which is responsible for the forwarding of
traffic transmitted to it could also cause the transients. Packets intended to be traffic engineered
must follow the policy of and reservation of the label- switching path that they are going to use.
When utilizing a LSP, the router must keep track of which flow spec established for the LSP the
packets get to use. PE_1 which is the ingress router must then govern the amount of average bit
rate allowed by the flow spec defined for each LSP. The flow spec which was defined and
used by UDP traffic, allowed only an average bit rate of 4,214,400 bits/sec. With UDPP traffic
exceeding at some points the average bit rate traffic intensity, some queuing at the
ingress router had to take place to govern the amount of average bit rate limit configured.

Figure 4.14 shows the amount of queuing delay between the ingress router PE_1 and the routers
along the path. The queuing delay has some direct impact on the TCP protocol.

Other results gathered from the MPLS experimentation were the throughput measured from
paths between routers that handled traffic flows. Figures 4.13, 4.16, 4.17 and 4.19 shows the
results gathered from the simulation.

It was recorded that the throughput between routers combining the shortest path and longest path
were more balanced compared with the shortest path configured network simulated earlier. It
was witnessed that TCP traffic travelling along LSP PE_1-PE_2 reaches a maximum of
28,247.7866666666 bits/second. Here, the throughput starts climbing 120 seconds after the start
of the simulation.

From the results registered, it was confirmed that the longest path was more efficiently utilized
with the traffic engineering capabilities of MPLS. With no traffic engineering, it was noted that
probably no throughput was witnessed at the non-shortest path as simulated in the preceding
experiment. TCP traffic would have then suffered a lot more when competing with its rival UDP
traffic along the shortest path

From figure 4.19, the throughput intensity from path combining routers PE_1 P_3 P_4
P_5 PE_2 through PE_1-PE_21 LSP was shown. Since UDP traffic gets to utilize this path
alone, i t w a s p o s s i b l e to avoid congestion within the network. If shortest path routing
were configured, the path would have been over utilized making both traffic streams to suffer
from congestion within the network.

F17/2367/2009 - University of Nairobi Page 30


Computer Simulation of Multi-Protocol Label Switching

4.11.2 Queuing delay


Some statistics concerning queuing delay from the edge and core routers were also collected.
From figures 4.14, 4.15, 4.18 and 4.20, it can be observed that the queuing delay is more
balanced between both paths comparing it with the shortest path routing scenario.

UDP traffic, which utilizes the path PE_1 P_3 P_4 - P_5 seems to have a lower queuing
delay values than the TCP traffic. It keeps a steady value approximately at 0.0045 seconds.
Another interesting detail of it is the slightly queuing delay drop offs at each second along the
simulation time

The other result registered, was the fact that almost all- significant queuing appeared between
the first few seconds along both paths. Thereafter, the values kept stable queuing delay
values along the forwarding path. This happens because the entire major queuing takes place
between the ingress and first router along the path and since the queuing values arent very high,
a very stable queuing value between other routers along the path was recorded.

The amount of traffic between these routers are more predictable since the second router along
the path get the right amount of traffic that it can forward further closer towards some
destination. Its the first router that gets to queue the heavy amount of traffic that the links cant
cope to carry immediately.

Comparing these results with the earlier result from the shortest path routing scenario network,
the queuing delay keep a much less queuing delay value (Maximum -- 0.000112047308 seconds
and Minimum -- 0.000028934959 seconds) between the ingress router and the egress router
along the shortest path, than the OSPF routing scenario.

F17/2367/2009 - University of Nairobi Page 31


Computer Simulation of Multi-Protocol Label Switching

5. CONCLUSION

F17/2367/2009 - University of Nairobi Page 32


Computer Simulation of Multi-Protocol Label Switching

6. REFERENCES

[1] Daniel O. Aweduche, MPLS and Traffic Engineering in IP Networks, IEEE

Communication Magazine December 1999, UUNET (MCI Worldcom)

[2] D Bertsekas & R Gallager, Data Networks, Second Edition, Prentice Hall 1992.

[3] J. Moy,OSPF version 2, RFC 2328, Ascend Communications Inc. April 1998.

[4] Wei Sun, Praveen Bhaniramka, Raj Jain,Quality of Service usingTraffic Engineering

over MPLS: An analysis, IEEE 2000, 0-7695-0912-6/00.

[5] C. Hedrick, Routing Information Protocol, RFC 1058, Rutgers University, June 1988.

[6] D. Oran, OSI IS-IS Intra-domain Routing Protocol, RFC 1142, Digital

Equipment Corp., February 1990.

[7] T. Li, Y. Rekhter, A Provider Architecture for Differentiated Services and Traffic

Engineering (PASTE) RFC 2430, October 1998.

[8] Martin P. Clark, Telecommunications Consultant, Germany Data Networks, IP and the

Internet; Protocols, Design and Operation

[9] Luc De Ghein, CCIE No.1897, MPLS Fundamentals; A Comprehensive introduction to

MPLS Theory and Practice

[10] Ivan Pepelnjak, Jim Guichard, MPLS and VPN Architectures; A Practical guide to

understanding, designing and deploying MPLS and MPLS enabled VPNs

[11] Vivek Alwayn, Advanced MPLS design and Implementation

[12] E. Rosen, A. Viswanathan, R.Callon Multiprotocol Label Switching Architecture (RFC

3031) http://www.ietf.org/rfc/rfc3031.txt January 2001

F17/2367/2009 - University of Nairobi Page 33


Computer Simulation of Multi-Protocol Label Switching

[13] Fernando Solano, Student Member, IEEE, Ramon Fabregat, and Jose Luis Marzo,

Member, IEEE, On Optimal Computation of MPLS Label Binding for Multipoint-to-

Point Connections IEEE Transactions on Communications, Vol. 56, No. 7, July

[14] Xipeng Xiao, Alan Hannan, and Brook Bailey, Global Center Inc. Lionel M, NI,

Michigan State University. Traffic Engineering with MPLS in the Internet

[15] Haris Hodzic, Sladjana Traffic Engineering with Constraint Based Routing Zoric 50th

International Symposium ELMAR-2008, 10-12 September 2008, Zadar, Croatia.

[16] Ina Minei, Julian Lucek, MPLS enabled applications: emerging developments and

new technologies, 3rd edition, Wiley, 2010

[17] OPNET Technologies Inc., "OPNET Modeler Modeling Manual", Bethesda, MD,

release 14.5, June 2008

[18] OPNET Technologies Inc., "OPNET Protocol Model Documentation", Bethesda, MD,

release 14.5, June 2008

F17/2367/2009 - University of Nairobi Page 34


Computer Simulation of Multi-Protocol Label Switching

7. APPENDIX
7.1 APPENDIX A: PROCEDURE FOR MODELLING OSPF EXPERIMENT
Creating the Network

1. Add the following objects from the object palette to the project workspace:
Application Config, Profile Config, QoS Attribute, MPLS Config, 3 Ethernet wkstn, 1 Ethernet server, 7
Cisco 7200 routers
2. Connect the Cisco 7200 routers together with DS2 links (from the Link model palette) as
per the diagram.
3. Connect the workstations and the server to the routers with 100Base_T links.
4. Select the following menu was: Protocols/IP/Routing/Select routing Protocols, OSPF
was selected and applied to all subinterfaces and all interfaces (including loopback,
VLAN).
5. Select all routers then Protocols/OSPF/Configure Area, insert area 0 in the box then click
OK.
6. Select all WAN links from LER1, LSR1, and LSR4 to LER2. Select OSPF/Configure
Interface Costs and set the interface cost explicitly for all selected links to 100.

Configuring the Application

Here the applications and file sizes to be used on the model are defined.

1. Select Edit Attributes from the Applications node; s e t Application Definitions to 2


(because there are 2 applications). Name t he rows: FTP Application and Video
Application.
2. From the FTP Application Description row, set the value of FTP to High Load. Change
the value in the (Ftp) Table for a size of 50,000,000 and an Inter-Request Time of
constant (100) to continue to request files of 50,000,000 bytes. Set the TOS field to
AF11 for DSCP.
3. From the Video Application row, set the Video Conferencing value to Low Resolution
Video. Click on Low Resolution Video and choose Edit from the drop down menu.
Select the value in the (Video Conferencing) Table to high resolution video and the TOS
set to DSCP AF41).

F17/2367/2009 - University of Nairobi Page 35


Computer Simulation of Multi-Protocol Label Switching

Configuring the Profiles

1. From the Profiles node, select Edit Attributes; s e t Profile Definitions to 2 (because
there are 2 profiles). T he rows are named: TCP Profile and UDP Profile.
2. Name and set the attributes of row 0 as shown below with the FTP traffic starting 120
seconds after the start of the simulation

3. Set streaming video traffic to start 180 seconds after the start of the simulation

Configuring the Workstations and Servers

1. Right-click the FTP Client, from Edit Attributes: Application: Supported Profiles, s et
t h e rows to 1. Set the Profile Name to TCP Profile: OK.
2. Right-click the Video Clients, from Edit Attributes: Application: Supported Profiles s et
t h e rows to 1. Application was edited: Supported Services and rows set to 1. Set service
name to Video Application: OK twice
3. Right-click the FTP Server: Edit Attributes: Application: Supported Services and set rows
to 1. Set service name to FTP Application: OK twice.

Traffic and Flows

1. Set OSPF to run on all routers with an area of 0.


2. Run DES for 600 seconds and quantify the different traffic flows after choosing the
appropriate statistics.

F17/2367/2009 - University of Nairobi Page 36


Computer Simulation of Multi-Protocol Label Switching

7.2 APPENDIX B: PROCEDURE FOR MODELLING MPLS EXPERIMENT


Copy the current scenario and name it MPLS_TE.

Here Trunk profiles are created. For each traffic flow FECs are assigned and then bound to the
static LSPs at LER PE_1 and LER PE_2.

TCP traffic will be made to flow along the route PE_1 - P_1 - P_2 - PE_2. Two unidirectional
paths are made one originating at each LER.

Video traffic will flow between LER PE_1 and LER PE_2 via PE_1 P_3 P_4 P_5 PE_2.
Again, two unidirectional paths will be made.

Creation of traffic Trunk profiles.

Two traffic flows need to be defined for the two different DSCP classes of flows. Right click on
the MPLS configuration object and select Edit Attributes. Select Traffic Trunk Profiles and edit
the fields and enter two rows. For each row add a trunk name and enter the traffic profile as
shown below for each flow. Trunk_Video is added as shown below (it is a CBR profile):

Finally Trunk_FTP is added with the following configurations

Creation of FEC classes

Here two Forward Equivalent Classes (FEC) are created; one for Video and one for FTP. These
flows can be managed in the network

F17/2367/2009 - University of Nairobi Page 37


Computer Simulation of Multi-Protocol Label Switching

Right click on the MPLS configuration object and select Edit Attributes. Select FEC
Specifications and edit the fields and enter two rows. For each row add a FEC name (Video and
another for FTP traffic) Details for FEC_FTP are as shown below:

For the FEC_Video enter the FEC details as shown below. Assign DSCP code point AF41 for
video

Configuration of static LSP between PE_1, P_1, P_2, PE_2

Using the MPLS_E-LSP_STATIC object, configure a unidirectional static route from PE_1 to
PE__2

Click on the MPLS_E-LSP_STATIC object in the MPLS object palette. From the project
workspace, click on the LSPs ingress LER PE_1, Click on the next link or router in the LSPs
route

The tooltips indicate which links and routers can be added to the route. Hold the cursor over a link
or router for details about adding it to the LSP.

Continue clicking on each link or router in the route until all have been added. Right-click in the
project workspace and select Finish Path Definition to finish drawing the LSP

Configure a static LSP between PE_2, P_2, P_1, and PE_1

Same as above but from PE_2 towards PE_1 on the top path

F17/2367/2009 - University of Nairobi Page 38


Computer Simulation of Multi-Protocol Label Switching

Configure static routes along the bottom path.

Configure a static LSP between PE_1 P_3 P_4 P_5 PE_2 as above and one between PE_2-
P_5-P_4-P_3-PE_1 as above. When creation of LSPs is finished, right-click in the project
workspace and select Abort Path Definition, otherwise, draw the next static LSP

Update the LSP details.

From the Protocols > MPLS menu, choose Update LSP Details to configure label switching
information on the LSP(s). Choose Protocols/MPLS/Show all LSPs to show the paths on the
topology diagram. Right-click on the link between PE_1 and P_1 to reveal the path names. Click
on the PE_1 to P_2 path and select Edit Attributes. Click on Path Details and examine the path
details to see the labels being used to determine the path between the routers.

Configure Traffic Mapping configuration on PE_1

Here we are going to bind the FEC_ Video profile to the Video trunk and map this onto one or
more Label Switched Paths (LSPs).

Then the FEC_ FTP profile is bound to the FTP trunk and mapped onto a different LSP.
On PE_1, choose the Edit Attributes/MPLS/MPLS parameters/Traffic Mapping Configuration
attribute and enter 2 rows. Choose the Interface In as shown below:

Configure the FEC/Destination Prefix as FEC_Video with the Traffic Trunk to Trunk_Video, the
Primary LSP from PE_1 to PE_2 (weight 100), and the Backup LSP to PE_1 to PE_21. Configure
the next row as above for the same FEC and LSPs except set the Traffic Trunk to Trunk_FTP as
shown below:

F17/2367/2009 - University of Nairobi Page 39


Computer Simulation of Multi-Protocol Label Switching

Configure Traffic Mapping configuration on LER_2

Now it is necessary to bind the FEC_Video profile to the Video trunk and map this onto one or
more Label Switched Paths (LSPs) at PE_2

Then the FEC_ FTP profile is bound to FTP trunk and mapped onto a different LSP. On PE_2,
choose the Edit Attributes/MPLS/MPLS parameters/Traffic Mapping

Choose the Interface In as shown below:

Configure Link Discovery Protocols on the routers.

Select the PE_1 router and right click. Select Edit Attributes/MPLS/LDP parameters. Set the
Status to Enabled; the Discovery configuration/Link Hellos to enabled; the Loopback Interfaces to
Enabled and select the router loopback address (LB0).

Set the Neighbor Configuration, number of rows to 2 and name the neighbors as P_1 and P_3.
Click OK to save the parameters. (Ensure that the appropriate interfaces between the MPLS
routers have been enabled).

A similar exercise should be done on all the other routers.

F17/2367/2009 - University of Nairobi Page 40

Das könnte Ihnen auch gefallen