university of nairobi department of...

UNIVERSITY OF NAIROBI

DEPARTMENT OF ELECTRICAL AND INFORMATIONENGINEERING

SIMULATION OF MULTI-PROTOCOL LABEL SWITCHING

Project Index: 124

By

Geoffrey Omeke MosongoF17/2367/2009

Supervisor: Dr. G.S.O Odhiambo

Examiner: Prof. V.K Oduol

Project report of the final year project towards partial fulfillment of therequirements 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

[i]

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 people’s work or

my work has been used, this has properly been acknowledged and referenced in

accordance with the University of Nairobi’s 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: ………………………………………………………………………………...


[ii]

ABSTRACTMultiprotocol Label Switching (MPLS) is a ubiquitous technology used by Internet ServiceProviders and enterprise networks to forward packets. This project shall present a description ofMultiprotocol Label Switching architecture and its functionality through a computer simulationmodel. An MPLS network will be simulated and its performance measured. Analysis of resultsrelated to latency, link utilization, amount of traffic in the Label Switched Paths (LSPs) andthroughput within nodes in the network shall be done to show the key performance metrics ofMPLS. The simulation tool used in this project is OPNET Modeler version 14.5 from RiverbedTechnologies.


[iii]

ACKNOWLEGEMENT

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

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

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

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


[iv]

Table of ContentsDECLARATION 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


[v]

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


[vi]

LIST OF FIGURESFig 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


[vii]

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


[viii]

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


F17/2367/2009 - University of Nairobi Page 1

1. INTRODUCTIONIn 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 ISP’s. 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.

Today’s 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:



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.



2. SHORTEST PATH ROUTING PRINCIPLEThe 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

provider’s (ISP) network edge router, which is referred to as provider edge router (PE) at the

other end. The core routers within the provider’s 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 AS’s. 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



An AS may look like the one illustrated in figure 2. In order to make right delivery of packets

received from the customer’s 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 Dijkstra’s algorithm [2]. In short, Dijkstra’s 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 Dijkstra’s 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



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 isn’t 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



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



3. MPLS TECHNOLOGY OVERVIEWMultiprotocol 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



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 administration’s 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



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 planeNodes 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



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 thepacket header by the Ingress router. FEC is identified from the label.

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

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 IPaddress. This is done until the packets reach the final hop in MPLS network and then thelabel 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 domainare 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

Internet



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 calculationThe 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



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 link’s 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.



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.



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



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



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].



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 node’s 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.



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



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.



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 today’s 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.



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



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)



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

v i d e o c l i e n t starts generating traffic. This causes TCP throughput to fall to

1,935,580.07407407 bits/second during the 210th 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.



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



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



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.



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)



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)



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 594th 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.



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.



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 aren’t 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. It’s the first router that gets to queue the heavy amount of traffic that the links can’t

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.



5. CONCLUSION



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



[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



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; se 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).



Configuring the Profiles

1. From the Profiles node, select Edit Attributes; se 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, set

the rows to 1. Set the Profile Name to TCP Profile: OK.

2. Right-click the Video Clients, from Edit Attributes: Application: Supported Profiles set

the 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.



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



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 LSP’s 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



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:



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.

university of nairobi department of...

Documents