Network Traffic Control

Department of Computer & Electronic Engineering

“Network Traffic Control”

by

Ioannis Gallikas

MSc in Communication Network Planning and Management

Supervised by: Mr. Frank Margrave

2003-2004 “This report is submitted in partial submission for the degree of Master of Science”

Network Traffic Control Portsmouth University

Ioannis Gallikas MSc

i

Abstract

The need for communication and data transfer was the reason that networking was

introduced. Only lately though networks provide us with real-time applications. Real-time

applications are the ones that we need to have the smallest possible end-to-end delay.

Such application are voice and video conferencing.

Unfortunately these applications are bandwidth demanding and most of the times,

a new higher capacity link is needed in order to provide the required delays, something

that it is not cost effective. Hence a new way was needed in order to run these

applications and still maintain the low end-to-end delay without having to spent more

money on upgrading the network.

This is done by implementing certain QoS techniques in the network which will

promise low latencies on the desired applications. The technique that we are most

interested in is Differentiated Services. There are several different ways to apply DiffServ

in a network. All these ways will be explained later on the background theory.

A network was chosen in order to apply DiffServ. This network was decided to be

the GUNET since it is a highly utilized network and such applications are under testing in

reality.

Instead of doing all the calculations by hand, computer software will be used,

something that is much faster and much more accurate. The simulation package that will

be used is called OPNET and is one of the best in the market for network simulation.



ii

ACKNOWLEDGEMENTS I would like to thank my Supervisor Mr Frank Margrave for providing me with

useful knowledge and directions on how to deal this project and Dr. Nick Savage for his

help and his notes provided on differentiated services.

I would also like to thank my parents and the rest of my family who supported me

and helped me reach this far with my studies. I would also like to thank my colleagues

who helped me by providing useful tips and support during the past few months here in

Portsmouth. Finally I would like to thank Mr. Vasileios Adamos, whose previous

experience of OPNET was very helpful.

….dedicated to my mother



iii

GLOSSARY

ATM Asynchronous Transfer Mode

CoS Class of Service

CQ Custom Queuing

DIFFSERV Differentiated Services

DLSw Data-Link Switching

DWRR Deficit Weighted Round Robin

FIFO First In – First Out

FTP File Transfer Protocol

GRNET Greek Network

GUNET Greek Universities Network

INTSERV Integrated Services

IP Internet Protocol

IPX Internetwork Packet Exchange

ISP Internet Service Provider

MDRR Modified Deficit Round Robin

MPLS Multi Protocols Labeling Switching

PPP Point to Point

PQ Priority Queuing

QoS Quality of Service

PBR Policy-Based Routing

RSVP ReSerVation Protocol

SAP Service Advertising Protocol

SMB Subnet Bandwidth Management

SNA Systems Network Architecture

TCP Transmission Control Protocol

ToS Type of Service

UDP User Datagram Protocol

VOIP Voice Over IP

WFQ Weighted Fair Queuing


Ioannis Gallikas MSc Page 1

CHAPTER 1

1. INTRODUCTION

The demand for constant and instant data communication between companies,

organizations and universities which are spread in different locations has developed the need

of networking. As these networks become larger, much faster, more complex and more

bandwidth demanding, their design and management becomes an ever more challenging task.

Cost is a significant factor in a networks capacity. The increased demand on

bandwidth when new applications are introduced in a network makes a network to be cost

defective since better links are needed to keep the utilization levels and end-to-end delay in

minimal levels. Hence new ways should be introduced in a network that would cope with the

extra loading and still produce good results. This was succeeded by applying a new method

of traffic control called QoS. There are different approaches of QoS. The one of most interest

is differentiated services which work with real-time applications such as voice and video.

No matter what the nature of the network to be implemented is, before building

anything it is best to design it and, if possible, test it. This is the most cost efficient way as

potential errors are easier to be identified and corrected in an early stage. Problems can be

solved through, by running a computer simulation program since that would be more time

effectual than actually performing the calculations by hand.

OPNET is a graphically based package which allows the performance of

communication networks ranging from simple links to complex enterprise-wide systems to

be analyzed and predicted. It supports a building-block approach where the blocks are

familiar objects in the real world. The design tool has a library of these network objects, each

one representing one or more real-world objects. The object parameters are easily adjusted to

match the real world objects. It is capable for performing analysis of both computer and

communication networks and based on a description of a network, its control algorithms and

workload, it simulates the operation of the network and provides measures of network

performance.



1.1. PROJECT TITLE & DEFINITION

“Network Traffic Control”

“Differentiated Services is an architecture for providing different types or levels of

service for network traffic. One key characteristic of Diffserv is that flows are aggregated in

the network, so that core routers only need to distinguish a comparably small number of

aggregated flows, even if those flows contain thousands or millions of individual flows.

Support for Differentiated Services on Linux is part of the more general Traffic Control

architecture. This project will investigate the use of diffserv and its role in traffic

management. The project will include the use of OPNET for traffic modelling and

investigation of diffserv.”

1.2. THE OBJECTIVES OF THE PROJECT PROPOSAL

The objectives of this project are to study the implementation of Differentiated

Services in a network in order to decrease the end-to-end delay of real-time applications such

as voice and video conferencing. The simulations will be based on a powerful computer-

based simulation package called OPNET Modeller, where the implementation of a network

will be made in order to simulate and obtain results of a network once without any Quality-

of-Service and once after applying differentiated Services. By comparing the results obtained

on both case studies, we can investigate and understand the effect of Differentiated Services

in a congested network, evaluate Differentiated Services and illustrate advantages and

disadvantages over non Differentiated data flows.



The network on which Differentiated Services are going to be applied is the Greek

Universities Network, which is known as GUNET. The network consists of sixteen

universities, eight of which are located in Athens, two are located in Thessaloniki and the rest

six are spreaded around Greece. The decision of choosing that specific network was based on

the fact that GUNET is my country’s network which makes it easier to me to find vital

information and on the fact that only lately the universities started exploring the option of

adding VOIP in the network and Video Conferencing will be another advantage.



CHAPTER 2

2. BACKGROUND THEORY

The project consists of two parts. One is the theoretical background on Quality of

Service and specifically Differentiated services and the other is the practical part of the

OPNET simulation package which will be used to run the network simulation and with the

results obtained a comparison of the performance will be discussed.

A company’s network is the backbone of the company’s success. Such a network

carries vital applications and data. Real time applications such as voice and video which are

sensitive to delay variation are of huge importance in a company. These kinds of

applications are bandwidth demanding and sometimes these services need to have predictable

delays and generally guaranteed services.

Differentiated Services is one approach of applying QoS in a network QoS is used

for:

Applying different levels of service to groups, such as customers or

enterprises

Applying different priorities on services which are given to particular groups

or applications

Tracing and dissolving areas of network bottlenecks and other forms of

congestion by rerouting the application

Monitoring network performance

Regulates the incoming and outcoming Bandwidth of the network.

There are two ways that QoS can be applied in a network

Resource Reservation (integrated Services) where the network resources are

apportioned according to an application’s QoS request, and subject to

bandwidth management policy (internet reference 27)



Prioritization (differentiated Services) where the network traffic is classified

and apportioned network resources according to bandwidth management

policy criteria. A network’s elements give preferential treatment to

classifications identified as having more demanding requirements, when QoS

is enabled. (internet reference 27)

There are two more types that can characterize QoS.

Per Flow : Flow is a unidirectional data-stream between two nodes, and

is identified by its transport protocol, source address, source port, and

destination address and destination port.

Per Aggregate: Aggregate is just more than one flows which have some

common parameters as the ones mentioned earlier.

2.1. QUALITY OF SERVICE ARCHITECTURES

Standard networks are configured by default to provide with best effort data delivery.

This makes the network to have the minimum complexity as possible. In a network that

continuously grows, the increased demand of bandwidth from the host does not make the

network to deny the services but as more applications are introduced in the network, the most

it degrades. This is not a problem when the only applications in a network are client server

type such as FTP, E-mail or Database. These applications can cope vary easily with delay

variations. Instead it is of great concern when multimedia applications such as voice and

video are present, applications which cannot cope with delay variations since they are

characterised as peer to peer applications and they are more bandwidth hungry.

By increasing the bandwidth does not solve the problem, since the smallest increased

traffic which can occur will be enough to affect multimedia applications. QoS doesn’t

increase bandwidth, instead it manages the existing bandwidth in a more effective way for

certain applications.

QoS is a networking term which determines that a specific amount of data will be

transferred from one point A to another point B in a predetermined amount of time. The



biggest advantage of ATM over technologies such as Frame Relay and Fast Ethernet is that

ATM supports QoS which allows ISPs to guarantee to customers that a low end-to-end delay

will not exceed certain limits.

QoS is based in four Protocols:

ReSerVation Protocol (RSVP)

Is the one that provides the signalling to enable the resource

reservation Protocol on the network. Although RSVP is used mainly

on a Per-Flow basis, sometimes, it can be seen to be used also Per-

Aggregates.

Differentiated Services (DiffServ)

Is the simplest way to categorize and prioritise network traffic flows

and aggregates.

Multi Protocols Labeling Switching (MPLS)

Is the one that manages the bandwidth on a network by routing the

traffic according to the labels in the packet headers.

Subnet Bandwidth Management (SMB)

Is responsible of categorizing and prioritizing at the data link-layer on

wired networks.

2.1.1. INTEGRATED SERVICES (IntServ)

Integrated Services approach is based on the concept that a stream that is serviced at a

higher data rate than it requires will be guaranteed the delay bound of a flow-by-flow

resource reservation. When an application will make a request to the network, it signals its

required bandwidth and delay requirements along with its traffic profile. The network will

then assess this application along with any other applications that it is currently servicing and

then it may grant the request as long as the application honours its originally specified

characteristics (traffic profile).The network will maintain a service level commitment using

advanced queuing disciplines for link sharing. [1]



Picture 1 Integrated services Approach to providing QoS [1]

2.1.1.1 RESERVATION PROTOCOL (RSVP)

This mechanism should reserve resources along a network link so that they can

deliver the required network performance. Weather a resource is granted or not depends very

much on the policy that the network has in place. The exact nature of resource depends on

the network performance requirements and the specific network approach to satisfying them.

Resource reservation must be chargeable so a protocol must be in place that allows the

authentication, authorisation and accounting and settlement between different network

providers and between network providers and users. The authentication and authorisation

procedure is very important otherwise the reservation policy that is in place could be abused

to block network service to other users. Resource reservation is typically done with a

purpose-designed protocol such as RSVP. [1]

2.1.2. DIFFERENTIATED SERVICES (Diffserv)

Differentiated Services provides a scalable means of service differentiation in the

internet. No per-flow state needs to be maintained in the routers, neither is there an explicit

connection setup phase. The Differentiated Services architecture offers a framework within

which service providers can offer each customer a range of network services which are



differentiated on the basis of performance in addition to pricing tiers used in the past.

Diffserv provides a wide range of services through a combination of the following functions.

Setting bits in the TOS octet at network edges and administrative boundaries using

those bits to determine how packets are treated by the routers inside the network conditioning

the marked packets at network boundaries in accordance with the requirements of each

service.

The diffserv architecture is composed of a number of small functional units

implemented in the network nodes. This includes the definition of a set of Per-Hop Behaviors

(PHBs), packet classification and traffic conditioning functions like metering, marking,

shaping and policing. The resource allocation for each service type adds a new dimension to

the problem, for which the Bandwidth Brokers are being considered. (Internet reference 3)

The diffserv model is scalable because of a few reasons that are listed below:

Diffserv suggests that the more expensive tasks like multi-flow classification,

policing, shaping and marking be done at the border routers of the ISP networks. This is

because the border routers deal with the customer links that are slow as a result of which it

has time to do the costly functions like MFC and traffic conditioning. The core routers, on

the other hand simply does the forwarding based on the diffserv code point (DSCP), which is

the first six bits in the TOS byte in the IP header. Since the core routers need not maintain

any per-flow state, this model is more scalable. The granularity of service provisioning is a

class in diffserv, as opposed to being a flow in IntServ. Multiple flows may be mapped on to

a single per-hop behaviour (PHB), which is indicated by the value in the DSCP. This too,

ensures the scalability of the diffserv model. (Internet reference 3)

When implementing Diffserv, it can be seen that:

Diffserv codepoints (DSCPs) redefine the Type-of-Service (ToS) in the IPv4

field

Precedence bits are preserved

Type-of-Service bits are NOT



Figure 1 IPv4Ffield [25]

IP precedence utilizes the 3 precedence bits in the IPv4 header's Type of Service

(ToS) field to specify class of service for each packet. Traffic can be partitioned in up to six

classes of service using IP precedence (two others are reserved for internal network use). The

queuing technologies throughout the network can then use this signal to provide the

appropriate expedited handling. (Internet reference 25)

The service provider establishes a Service Level Agreement (SLA or service level

specification) with each user. A user can then only generate a certain amount of traffic of a

specific class. The traffic is policed at the border of the service provider network. This

method differs to the integrated services approach by treating each packet individually rather

than trying to specify a set route that the packet must take. The overall network must set-up

to meet all of the SLA’s. [1]



Picture 2 Differentiated services approach to providing QoS [1]

2.1.2.1. SERVICE LEVEL AGREEMENTS (SLA)

The SLA is and agreement between a user and a network provider to state the level of

availability, serviceability, performance, operation or other attributes of the service. The SLA

will define the parameters used and their associated values. It may contain general

parameters or may be technology specific. In the table below, the quality service parameters

can be seen and also the different service levels. [1]

QUALITY OF SERVICE PARAMETERS

Service Level Application Priority Mapping

1 • Non-critical data • Similar to Internet today • No minimum information

rate guaranteed

• Best-effort delivery • Unmanaged performance

2 • Mission-critical data • VPN outsourcing, e-

commerce • Similar to ATM VBR

• Low loss rate • Controlled delay and delay

variation

3 • Real time applications • Video streaming, voice,

videoconferencing

• Low loss rate • Low delay and delay

variation

Table 1. Quality service parameters (Internet reference 25)



2.1.2.2. IP PRECEDENCE

Use of IP Precedence allows specifying the class of service for a packet. The three

precedence bits in the IPv4 header’s type of service (ToS) field is used for this purpose.

Figure 2 shows the ToS field. (internet reference 28)

Figure 2 IPv4 Packet Type of Service Field

Using the ToS bits, we can define up to six classes of service. Other features

configured throughout the network can then use these bits to determine how to treat the

packet in regard to the type of service to grant it. These other QoS features can assign

appropriate traffic-handling policies including congestion management strategy and

bandwidth allocation. For example, although IP Precedence is not a queueing method,

queueing methods such as weighted fair queueing (WFQ) and Weighted Random Early

Detection (WRED) can use the IP Precedence setting of the packet to prioritize traffic.

(internet reference 28)

By setting precedence levels on incoming traffic and using them in combination with

the Cisco IOS QoS queueing features, we can create differentiated services. We can use

features such as policy-based routing (PBR) and CAR to set precedence based on extended

access list classification. These features afford considerable flexibility for precedence

assignment. For example, we can assign precedence based on application or user, or by

destination and source subnetwork. (internet reference 28)

So that each subsequent network element can provide service based on the

determined policy, IP Precedence is usually deployed as close to the edge of the network or

the administrative domain as possible. We can think of IP Precedence as an edge function



that allows core, or backbone, QoS features, such as WRED, to forward traffic based on CoS.

IP Precedence can also be set in the host or network client, but this setting can be overridden

by policy within the network. (internet reference 28)

We can use the three IP Precedence bits in the ToS field of the IP header to specify

CoS assignment for each packet. We can partition traffic into up to six classes, the remaining

two are reserved for internal network use and then use policy maps and extended ACLs to

define network policies in terms of congestion handling and bandwidth allocation for each

class. (internet reference 28)

However, the IP Precedence feature allows considerable flexibility for precedence

assignment. That means we can define your own classification mechanism. For example, we

might want to assign precedence based on application or access router. (internet reference 28)

2.1.2.3. QUEUEING DISCIPLINES

Queuing methods define the packet scheduling mechanism or the order in which

packets are dequeued to the interface for transmission on the physical wire. Based on the

order and number of times that a queue is serviced by a scheduler function, queuing methods

also support minimum bandwidth guarantees and low latencies.



2.1.2.3.1. First In – First Out QUEUEING DISCIPLINE (FIFO)

FIFO is the mostly used queuing discipline which is set as the default queuing

mechanism for routers around the world. As a result, nothing needs to be configured, the only

thing is to implement it and it’s ready to be used. On Cisco routers, when no other queuing

disciplines are configured, all interfaces, except serial interfaces at E1 (2.048 Mbps) and

below, use FIFO queuing discipline by default.

From its name it is obvious its simple behavior. FIFO stands for First In – First Out

which means that packets arriving from different flows are treated accordingly to their

arriving order. This means that the first packet that got in the queue will be the first that will

go out.

The figure above represents a FIFO queue. As it can be seen, different packet flows

are represented by different colors. The queue acts as a barrier for temporary burst of packets

avoiding unnecessary dropping by storing them, hoping that congestion will improve and

they can be dispatched. When congestion is heavy and the queue overflows new arriving

packets will be dropped since the router doesn’t have any other choice for them.

1

2

3

4

5

6

Flow 1

Flow 2

Flow 3

Flow 4

Flow 5

Flow 6

Flow 7

Flow 8

Multiplexer 1 2 3 4 5 6

FIFO Queue



2.1.2.3.2. WEIGHTED FAIR QUEUEING DISCIPLINE (WFQ)

There are two types of WFQ disciplines:

Flow-Based: Flow-based WFQ is responsible to allocate the ratio of the

transmission bandwidth between different traffic flows in periods of network

congestion

Class-Based: Class-based WFQ is responsible to allocate the transmission

bandwidth between different traffic flows during periods of congestion.

WFQ packets are classified by flow. Packets having the same source and destination

of IP address, same source and destination of TCP or UDP port, and packets with type of

service (ToS) field belong to the same flow.

In flow-based WFQ each flow corresponds to a separate output queue. When a packet

is assigned to a flow, it is placed in the queue for that flow. During periods of congestion,

WFQ allocates an equal share of the bandwidth to each active queue.

In class-based WFQ, packets are assigned to different queues based on their QoS

group or the IP precedence in the ToS field.

QoS groups allow the customization of a wanted QoS policy. A QoS group is an

internal classification of packets used by the router to determine how packets will be treated

by certain QoS features such as WFQ.

This can be implemented by applying a different weight for each class. During

periods of congestion, each group will be allocated a percentage of the output bandwidth

depending on the weight of the class. As an example, when a class is assigned a weight of 50,

all packets from this class will be allocated at least 50 percent of the outgoing bandwidth

when there is network congestion. When there is no congestion on the network, queues can

use any of the available bandwidth.



2.1.2.3.3. PRIORITY QUEUEING DISCIPLINE (PQ)

Priority queuing allows network administrators to define how they wish traffic to be

prioritized in the network. This is done by defining a series of filters based on packet

characteristics. Traffic is placed into different queues. The queue having the highest priority

will be the first to be serviced, while lower priority queues will be serviced in a priority

sequence. If the queue with the highest priority is always full, then this queue is constantly

serviced and all the packets from other queues are dropped. When using the Priority Queuing

algorithm the highest priority traffic will dominate all others kinds of traffic. Priority queuing

assigns all the traffic to one of the following four queues: high, medium, normal, and low.

In the above Figure, the priority-group command assigns priority list 1 to Serial1. The

priority-list command defines the queuing algorithm to be used by queue list 1 and maps the

traffic into various queues. Priority queuing is useful when you want to guarantee that the

DLSw+ traffic will get through even if it delays other types of traffic. It works best if the

DLSw+ traffic is low volume (for example, a small branch with a transaction rate of five to

ten transactions per minute), and the number of queues is kept to a minimum (two or three).

In this configuration, DLSw+ is in the highest-priority queue, Telnet (TCP port 23) is in the

medium queue, IPX is in the normal queue, and FTP (TCP port 21) is in the lowest-priority

queue.



2.1.2.3.4. CUSTOM QUEUEING DISCIPLINE (CQ)

Custom queuing, or bandwidth allocation, reserves a portion of the bandwidth of a

link for each selected traffic type. To configure custom queuing, the network manager must

determine how much bandwidth to reserve for each traffic type. If a particular type of traffic

is not using the bandwidth reserved for it, then other traffic types may use the unused

bandwidth.

Custom queuing works by cycling through the series of queues in round-robin order

and sending the portion of allocated bandwidth for each queue before moving to the next

queue. If one queue is empty, the router sends packets from the next queue that has packets

ready to send. Queuing of packets is still first in, first out in nature in each classification but

bandwidth sharing can be achieved between the different classes of traffic.

In the Figure below, custom queuing is configured to take 4000 bytes from the SNA

queue, 2000 bytes from the Telnet queue, and 2000 bytes from the default queue. This

allocates bandwidth in the proportions of 50, 25, and 25 percent. If SNA is not using all its

allocated 50 percent of bandwidth, the other queues can utilize this bandwidth until SNA

requires it again.

Custom queuing is commonly used when deploying DLSw+ networks because it

allows the network manager to ensure that a guaranteed percentage of the link can be used

for SNA, Telnet, and FTP. However, unless the DLSw+ traffic is broken into separate TCP

conversations (using SAP or LOCADDR prioritization described earlier), batch SNA transfer

or NetBIOS traffic shares the same output queue and may negatively impact interactive SNA

response times.



2.1.2.3.5. MODIFIED DEFICIT ROUND ROBIN QUEUEING DISCIPLINE (MDRR)

With MDRR configured as the queuing strategy, non-empty queues are served one

after the other, in a round-robin fashion. Each time a queue is served, a fixed amount of data

is dequeued. The algorithm then services the next queue. When a queue is served, MDRR

keeps track of the number of bytes of data that was dequeued in excess of the configured

value. In the next pass, when the queue is served again, less data will be dequeued to

compensate for the excess data that was served previously. As a result, the average amount of

data dequeued per queue will be close to the configured value. In addition, MDRR maintains

a priority queue that gets served on a preferential basis. MDRR is explained in greater detail

below.

Each queue within MDRR is defined by two variables:

Quantum value - Average number of bytes served in each round.

Deficit counter - This counter is used to track how many bytes a queue has

transmitted in each round. It is initialized to the quantum value.

Packets in a queue are served as long as the deficit counter is greater than zero. Each

packet served decreases the deficit counter by a value equal to its length in bytes. A queue

can no longer be served after the deficit counter becomes zero or negative. In each new

round, each non-empty queue's deficit counter is incremented by its quantum value.

Each MDRR queue can be given a relative weight, with one of the queues in the

group defined as a priority queue. The weights assign relative bandwidth for each queue

when the interface is congested. The MDRR algorithm dequeues data from each queue in a

round-robin fashion if there is data in the queue to be sent.



2.1.2.3.6. DEFICIT WEIGHTED ROUND ROBIN QUEUEING DISCIPLINE (DWRR)

Deficit Weighted Round Robin is the basis for a class of queue scheduling disciplines

that are designed to address the limitations of the WRR and WFQ models.

DWRR addresses the limitations of the WRR model by accurately

supporting the weighted fair distribution of bandwidth when servicing

queues that contain variable-length packets

DWRR addresses the limitations of the WFQ model by defining a

scheduling discipline that has lower computational complexity and that

can be implemented in hardware. This allows DWRR to support the

arbitration of output port bandwidth on high-speed interfaces in both the

core and at the edges of the network.

In the classic DWRR algorithm, the scheduler visits each non-empty queue and

determines the number of bytes in the packet in the head of the queue. The variable

DeficitCounter is incremented by the value quantum. If the size of the packet at the head of

the queue is greater that the variable DeficitCounter, then the scheduler moves on to service

the next queue. If the size of the packet at the head of the queue is less than or equal to the

variable DeficitCounter, then the variable DeficitCounter is reduced by the number of bytes

in the packet and the packet is transmitted on the output port. The scheduler continues to

dequeue packets and decrement the variable DeficitCounter by the size of the transmitted

packet until either the size of the packet at the head of the queue is greater than the variable

DeficitCounter or the queue is empty. If the queue is empty, the value of DeficitCounter is

set to zero. When this occurs, the scheduler moves on to service the next non-empty queue.

This can be seen in the figure below.



2.1.3. MULTI PROTOCOL LABEL SWITSHING (MPLS)

MPLS is a hybrid technology that combines the best of ATM’s circuit switching and the

IP’s packet routing. This way it enables fast forwarding in the cores and in the conventional

routing.

MPLS can achieve substantial speed gains in packet forwarding by using short layer-

2 labels. When a packet enters a MPLS network it is assigned a forward equivalence class

(FEC), which is encoded as a fixed-length string (label). When the packet is forwarded to the

next hop, the label is transmitting with it. At the next hop, the label is used as an index into a

preconfigured table to identify the following hop and a new label. This process continues

until the packet reaches its destination. The increase in speed is achieved because all the

packets with the same FEC are forwarded in the same way. To provide explicit QoS support

MPLS makes use of certain elements in the integrated and differentiated services approaches.

The level distribution protocol can be used on RSVP. As the resource reservation protocol

transverses the path, it can reserve network resources to guarantee the QoS of the following

packets. [1]

Queue 1

Queue 2

Scheduler

Port

( 50% B/W, Quantum [1] = 1000 )

( 25% b/w, Quantum [2] = 500 )

( 25% b/w, Quantum [3] = 500 )

Q1

Q3Q2

Queue 3



2.1.4. SUBNET BANDWIDTH MANAGEMENT (SBM)

SBM is a signalling scheme that provides a method for mapping an Internet-level

setup protocol such as RSVP onto IEEE 802-style networks. In particular, it describes the

operation of RSVP- enabled hosts/routers and link layer devices (switches and bridges) to

support reservation of LAN resources for RSVP-enabled data flows. For example, it can

signal 802.1p priorities between network switches or class of service information between

RSVP clients and RSVP networks. (Internet reference 24)



21

CHAPTER 3

3. OPNET MODELLER

Problems can be effectively solved through, by running a computer simulation program

since that would be more time efficient than actually doing the calculations by hand. OpNet

is a graphically based package which allows the performance of communication networks

ranging from simple links to complex enterprise-wide systems to be analysed and predicted.

It supports a building-block approach where the blocks are familiar objects in the real world.

The design tool has a library of these network objects, each one representing one or more

real-world objects. The object parameters are easily adjusted to match the real world objects.

It is capable for performing analysis of both computer and communication networks and

based on a description of a network, its control algorithms and workload, it simulates the

operation of the network and provides measures of network performance. [5]

One of the first steps before the beginning of the Project is to register with the

OPNET simulation package. This will be done through the OPNET website. In order to learn

the capabilities of the OPNET simulation package, there are several online models which

were contributed by users, and also there are tutorials on the Program that will be very

helpful to succeed in a quick understanding on how the programs works and how to model

the required network for this project. [5]

3.1. OVERVIEW OF OPNET

OPNET is the industry’s leading network technology development environment,

allowing you to design and study communication networks, devices, protocols, and

applications with unmatched flexibility. OPNET Modeller is used by the world’s most

prestigious technology organizations to accelerate the R&D process. [5]

Modeller’s object-oriented modelling approach and graphical editors mirror the structure

of actual networks and network components, so your system intuitively maps to your model.



22

Modeller supports all network types and technologies, allowing you to answer the most

difficult questions with confidence. Using OPNET Modeller, an organization will benefit by:

Boosting Network R&D Productivity: Leverage the specialized editors,

analysis tools, and off-the-shelf models provided with OPNET Modeller to

focus the time on the unique parts of a project. [5]

Improving Product Quality: Test product or service designs in realistic

customer scenarios before production. [5]

Reducing Time-to-Market: Develop and validate the designs ahead of the

competition. Use the models to demonstrate the value of the solutions to

customers and partners. [5]

Workflow: The workflow

Figure 1 for OPNET Modeller is the steps required to build a network model and run

simulations. It centres on the project editor. In this workspace you can create a network

model, collect statistics directly from each network object or from the network as a whole,

execute simulation and view results. [2]

Figure 1. Steps to build a network in OPNET Modeller [2]

Create Network Models

Choose Statistics

Run Simulations

View Analyze Results



23

3.2. FEATURES OF OPNET MODELLER

Modeller Editors: OPNET Modeller has many editors in order to design and simulate

flexible networks. These editors, which are very easy to use with the helping tool providing

by the modeller, help the user observe and better understand a network. We will briefly

describe each editor so we can understand the purpose of each one in the OPNET Modeller:

The project editor: As we said before it is the main staging area for creating a

network simulation.

The node editor: The node editor lets you define the behaviour of each network

object. Figure 2.

The process model editor: The process model editor lets you create process

models, which control the underlying functionality of the node models created in

the node editor. Figure 2.

The link (network) model editor: The link model editor lets you create new

types of link objects. Figure 2.

The path editor: We use the path editor to create new path objects that define a

traffic value.

The packet format editor: The packet editor lets you define the internal

structure of a packet as a set of fields.

The Antenna pattern editor (Radio version only): In Modeller/Radio, the

Antenna pattern editor lets you model the direction-dependent gain properties of

antennas.

The ICI editor: The ICI (Interface Control Information) editor lets you define

the internal structure of ICIs.

ICI used to formalize interrupt-based inter-process communication.

The modulation curve editor (Radio version only): In Modeller/Radio, the

modulation curve editor lets you create modulation functions to characterize the

vulnerability of an information coding and modulation scheme to noise.

The PDF editor: The PDF (Probability Density Function) editor lets you

describe the spread of probability over a range of possible outcomes.



24

The probe editor: The probe editor lets you specify the statistics to be collected

during simulation.

The simulation sequence editor: Although you can run simulations from within

the project editor, you may want to specify additional simulation constraints in

the simulation sequence editor.

The analysis tool: With analysis tool you can create scalar graphs, for parametric

studies, define templates to which you apply statistical data and create analysis

configurations that you can save and view later.

The filter editor: The filter editor lets you create additional filters.

Figure 2. The three primary editors of OPNET Modeller

The project editor will be explained below since is the one that will be used for the

design and simulation of the project’s network. [2]



25

3.2.1. PROJECT EDITOR

OPNET network models are based on three types of objects: subnetworks, nodes, and

links. These objects are worked in the Project Editor. The Project Editor provides the

resources needed to model all high-level components of a real-world network. Project Editor

Operations can be used to:

Create and edit network models

Create derived models of nodes and links

Customize the network environment

Run simulations

Choose and analyze simulation results

The Project Editor contains a workspace for creating and editing network models.

Subnetworks and nodes are placed in the workspace as objects and depicted there as icons.

Other objects, depicted as connecting lines, represent communication links between the

nodes and subnetworks. Network objects are characterized by attributes that control how they

behave within the overall model. The Project Editor provides extensive operations for

viewing and editing these attributes.

The Project Editor provides many operations for creating and working with network

models. These operations can be accessed from the project editor menu bar, which contains

the following menus:

File: contains operations that relate to high-level functions such as opening and

closing projects, saving scenarios, importing models, and printing graphics and

reports.

Edit: contains operations that allow you to edit the environment attributes that

control program operation and to manipulate text and objects.

View: contains operations that affect the appearance of the editor window and its

contents



26

Scenarios: contains operations that provide control over the scenarios included

in a project

Topology: contains operations related to network topology, including building a

network and creating network objects.

Traffic: contains operations related to specifying the traffic on a network,

including importing traffic files and specifying routing across the network.

Protocols: contains operations related to specific protocol models.

Simulation: contains operations for configuring and running simulations.

Results: contains operations that control the collection and viewing of statistics.

Windows: lists all open editor windows and allows the user to make one active.

Help: provides access to context-sensitive help, the online documentation and

tutorial, and information about the program.

Pop-Up Menus: In addition to the menu bar menus, several pop-up menus are available

within the Project Editor:

Workspace pop-up menu: contains operations related to setting the workspace

view, collecting results, and viewing results.

Object pop-up menu: contains operations related to setting object properties,

collecting results, and viewing results.

Statistic pop-up menu: contains operations related to a particular statistic.

Panel pop-up menu: contains operations related to the appearance and content

of an analysis panel.

Graph pop-up menu: contains operations related to the appearance and content

of a graph.

Miscellaneous Operations: There are also several operations available within the

Project Editor that do not appear on a menu:



27

Display Subnet View: this operation moves the user down to the network

hierarchy by displaying the contents of a subnetwork when he/she double clicks

on the subnet’s icon.

Open Node Model: this operation automatically opens the corresponding node

model when the user double clicks on a network node.

Zoom Panel: The Zoom Panel operation lets the user magnify a selected part of

an analysis panel by dragging the cursor across it. After this operation, the

selected area fills the panel. The user also can use <Control>+z and

<Control>+u to zoom into and out for the centre of the panel.

Pan Panel: in an analysis panel, this operation shifts the display along the

horizontal axis when the left-arrow or right-arrow keys are pressed by the user.

(Not available when the full horizontal scale is displayed.)

Action Buttons: The Project Editor provides action buttons for several frequently used

operations. The button labels in figure 2.11 identify the operation invoked by the button. [3]

Figure 3. Action buttons of the Project Editor [3]

Features: Originally developed at MIT, and introduced in 1987 as the first commercial

network simulator, OPNET Modeller continues to define the state of the art with the

following features:

Topology: Verify Links

Topology: Mark object as failed

Topology: Mark object as recovered

View: Go to parent Subnetwork

View: Zoom in

View: Zoom out

Simulation: Run Simulation

Results: View Results

Results: View Web Reports

Results: Hide/or Show all panels Topology: Object Palette



28

Hierarchical network models: Manage complex network topologies with

unlimited subnetwork nesting.

Object-oriented modelling: Nodes and protocols are modelled as classes with

inheritance and specialization.

Clear and simple modelling paradigm: Model the behaviour of individual

objects at the “Process Level” and interconnect them to form devices at the

“Node Level”. Interconnect devices using links to form networks at the

“Network Level”. Organize multiple network scenarios into “Projects” to

compare designs.

Finite state machine modelling of protocols and other processes. Simulate any

required behaviour with C/C++ logic in FSM’s states and transitions. We control

the level of detail.

Comprehensive support for protocol programming. Over 400 library functions

simplify writing protocol models.

Wireless, point-to-point, and multipoint links: Link behaviour is open and

programmable. Accurately account for delay, availability, bit errors and

throughput characteristics of links. Incorporate physical layer characteristics and

environmental effects.

Geographical and mobility modelling: Model cellular and satellite networks or

any network with mobile nodes. Control each node’s position dynamically or

pre-define trajectories. Add maps and other background graphics for context and

visual enhancement.

Total openness: APIs for program-driven construction or inspection of all

models and result files. Easily integrates existing code libraries into your

simulations. Source code provided for all standard models.

Integrated analysis tools: Comprehensive tools to display simulation results.

Easily plot and analyze time series, histograms, probability functions, parametric

curves, and confidence intervals. Export to spreadsheets pr use XML.

Animation: Animate model behaviour, either during or after simulation.

Integrated debugger: Quickly validate simulation behaviour or track down

problems.



29

Import data from text files, XML, and popular tools from HP, Concord,

Network Associates’ Sniffer, NetScout, Infovista, and others.

Financial cost attribute for devices: Export network costs to spreadsheets for a

financial bottom line.

Comprehensive library of detailed protocol and application models:

Including Multi-Tier Applications, Voice, HTTP, TCP, IP, OSPF, BGP, EIGRP,

RIP, RSVP, Frame Relay, FDDI, Ethernet, ATM, 802.11 Wireless LANs, MPLS,

PNNI, DOCSIS, UMTS, IP Multicast, Circuit Switch and many more. Provided

as FSMs with open source code.

Comprehensive library of detailed protocol and network devices: The

Standard Model Library includes hundreds of vendor specific and generic device

models including routers, switches, workstations, and packet generators. Quickly

assemble our own device models using the “Device Creator”. Aggregate traffic

from LANs or “Cloud” nodes.

Highly efficient simulation engine and memory management. Hybrid

simulations significantly improve performance by combining the accuracy of

discrete-event simulation with the speed of analytical modelling.

Runtime environment: Deliver proprietary protocol and device models to end-

users, running simulations and working at the network level only.

Windows NT, Windows 2000, and UNIX supported (transparent cross platform

usage).

Convenient licensing: Enhanced floating license system with automatic license

key downloads via the Internet and graphical license management.

What does OPNET Modeller Provide? OPNET Modeller provides:

An intuitive graphical environment that precisely models real networks, devices,

protocols, and applications.

The control over modelling detail needed to support our engineering decisions.

Built-in support for simulating all types of network technologies.



30

The industry’s most comprehensive library of standards-based protocol models,

with completely open source code.

An environment designed to model proprietary protocols using Finite State

Models, C/C++ and extensive libraries.

Powerful analysis tools integrated directly into the GUI.

The industry’s most efficient simulation engine, with hybrid simulation

capability.

Outstanding support and services to ensure user success. [4]



31

CHAPTER 4

4.1. NETWORK DECISION AND IMPLEMENTATION

The network that is to be implemented on the OPNET Modeler is the Greek

Universities Network (GUNET). This network is based on the existing Greek Network

(GRNET). In Picture 1 we can see the GRNET, the way it is connected between the Greek

cities and the available bandwidth of the network.

Picture 1 GRNET



32

GUNET consists of sixteen Universities in total. Table 1 below displays the

Universities and their location in Greece.

Greek Universities Location

Agricultural University Athens

Pantion University Athens

Harokopio University Athens

University of Pireus Athens

National Metsovio University Athens

National Kapodistriako University Athens

University of Economics Athens

University of Good Arts Athens

Aristotelio University Thessaloniki

Macedonia University Thessaloniki

University of Patra Patra

University of Crete Heraklio

Ioannina University Ioannina

University of Thessaly Larissa

University of Thrace Xanthi

Aegean University Rhodes

Table 1 Greek Universities and their location

As it can be seen in Table 1, there are eight Universities in Athens, two Universities

in Thessaloniki and the rest are some on the mainland and some on the islands. Picture 2

displays the GUNET Network and the backbone links that connect the University Routers

and the cities where the Universities are located.



33

Picture 2 GUNET Network

Table 2 below displays the capacity of the Backbone Network links between the

University Routers.

From Location To Location Capacity (Mbps)

Athens Thessaloniki 69 Mbps

Athens Patra 45 Mbps

Athens Heraklio 60 Mbps

Athens Rhodes 1000 Mbps

Athens Larissa 18 Mbps

Athens Ioannina 4.5 Mbps

Athens Xanthi 6 Mbps

Table 2 Capacity of the GUNET Backbone Network between the University Routers



34

By looking extensively at Picture 1, we can see the capacity of the links that each

University is connected with the main Router of the city. The capacity of the links can be

seen in Table 3 below. In Athens, it can be seen that there are three Routers in which the

universities are connected with and these three Routers are the ones that connect to the main

Router of Athens. The capacity of the link between these Routers is 2.5 Gbps.

From City Router To University Capacity (Mbps)

Athens Agricultural University 1000 Mbps

Athens Pantion University 1000 Mbps

Athens Harokopio University 2 Mbps

Athens University of Pireus 1000 Mbps

Athens National Metsovio University 1000 Mbps

Athens National Kapodistriako University 1000 Mbps

Athens University of Economics 1000 Mbps

Athens University of Good Arts 2 Mbps

Thessaloniki Aristotelio University 34 Mbps

Thessaloniki Macedonia University 18 Mbps

Patra University of Patra 34 Mbps

Heraklio University of Crete 28 Mbps

Ioannina Ioannina University 24 Mbps

Larissa University of Thessaly 8 Mbps

Xanthi University of Thrace 21 Mbps

Rhodes Aegean University 1000 Mbps

Table 3 Capacity of the links Between Universities and City Router



35

4.2. COMPONENTS USED

In this section of the report it can be seen the components that were used and the

configuration that was made to design the GUNET network in the OPNET Modeler

simulation package. All these components can be found inside the OPNET’s Model library

which is an advanced suite of real industry components.

When starting in designing a network, one of the first components to use is:

4.2.1. APPLICATION CONFIG

The "Application Config" node can be used for the following specifications:

1. "ACE Tier Information":

Specifies the different tier names used in the network model. This attribute will be

automatically populated when the model is created using the "Network->Import Topology-

>Create from ACE..." option.

The tier name and the corresponding ports at which the tier listens to incoming traffic

is cross-referenced by different nodes in the network.

2. "Application Specification":

Specifies applications using available application types. You can specify a name and

the corresponding description in the process of creating new applications.



36

For example, "Web Browsing (Heavy HTTP 1.1)" indicates a web application performing

heavy browsing using HTTP 1.1.

The specified application name will be used while creating user profiles on the

"Profile Config" object.

3. "Voice Encoder Schemes":

Specifies encoder Parameters for each of the encoder schemes used for generating

Voice traffic in the network.

4.2.2. PROFILE CONFIG

The "Profile Config" node can be used o create user profiles. These user profiles can

then be specified on different nodes in the network to generate application layer traffic.

The application defined in the "Application Config" objects are used by this object to

configure profiles. Therefore, you must create applications using the "Application Config"

object before using this object.

You can specify the traffic patterns followed by the applications as well as the

configured profiles on this object.



37

4.2.3. QoS CONFIG

Defines attribute configuration details for protocols supported at the IP layer. These

specifications can be refrenced by the individual nodes using symbolic names (character

strings.)

1. "Queuing Profiles": Defines different queuing profiles such as FIFO, WFQ, Priority

Queuing, Custom Queuing, MWRR, MDRR and DWRR.

2. "CAR Profiles": Defines different CAR profiles that can be used in the network.

4.2.4. SUBNET NODE

The Subnet node will be used to represent each city where the University will be

located. Inside each Subnet, there will be the nodes that will represent the University’s

Network configuration. In two cases though, the Subnet node will represent the University as

well since in these locations multiple Universities are located. These two locations are

Athens with 8 Universities and Thessaloniki with 2 Universities.



38

4.2.5. 100BaseT_LAN NODE

Use 100BaseT_LAN object to represent a Fast Ethernet LAN in a switched topology.

The object contains any number of clients as well as one server. Client traffic can be directed

to the internal server as well as external servers.

Supported applications include: FTP, Email, Database, Custom, Rlogin, Video, X windows,

HTTP etc. These applications run over TCP or UDP. For each application, you can specify

traffic for group of clients, allowing you to quickly characterize the entire LAN.

You may also wish to set the following attributes:

Switching Speed: (default = 500,000pkts/sec)

Number of Workstations: (default = 10)

LAN Server Name: (default = Auto Assigned)

4.2.6. PPP_SERVER NODE

The PPP_Server model represents a server node with server applications running over

TCP/IP and UDP/IP. This node supports one underlying SLIP connection. The operational

speed is determined by the data rate of the connected link.



39

Protocols: RIP, UDP, IP, TCP, OSPF

Interconnections:

One SLIP connection at a selectable data rate.

Attributes:

Server Configuration Table: This attribute allows for the specification of

application servers running on the node.

Transport Address: This attribute allows for the specification of the address of

the node.

"IP Forwarding Rate": specifies the rate (in packets/second) at which the node can

perform a routing decision for an arriving packet and transfer it to the appropriate

output interface.

"IP Gateway Function": specifies whether the local IP node is acting as a

gateway. Workstations should not act as gateways, as they only have one network

interface.

"RIP Process Mode": specifies whether the RIP process is silent or active. Silent

RIP processes do not send any routing updates but simply receive updates. All

RIP processes in a workstation should be silent RIP processes.

"TCP Connection Information": specifies whether diagnostic information about

CP connections from this node will be displayed at the end of the simulation.

"TCP Maximum Segment Size": determines the size of segments sent by TCP.

His value should be set to largest segment size that the underlying network can

carry unfragmented.

"TCP Receive Buffer Capacity": specifies the size of the buffer used to hold

received data before it is forwarded to the application.



40

4.2.7. CISCO ROUTER CS_12016_16s_a10_fe8_ge3_sl24_adv NODE

The model CS_12016_16s_a10_fe8_ge3_sl24_adv represents the following device:

Vendor: Cisco Systems

Product: CISCO 12016

Device Class: Gigabit Switch Router

Configuration: This model represents a specific configuration of an IP-based router

switch model.

Interconnections:

1. 12-port serial DS3 interfaces (44.736Mbps).

2. 8-port Packet over SONET (PoS) OC3 interfaces (PPP over SONET)(155.52Mbps)


4. 2-port Packet over SONET (PoS) OC48 interfaces (PPP over SONET)(2.48832Gbps)

5. 8-port ATM OC3 (155.52Mbps)


7. 8-port 100BaseT Fast Ethernet (100Mbps).

8. 3-port 1000BaseT Gigabit Ethernet (1000 Mbps)

General Operation:

IP packets arriving on an IP interface are routed to the appropriate output interface

based on their destination IP address. The Routing Information Protocol (RIP), Open Shortest



41

Path First (OSPF) protocol, Border Gateway Protocol (BGP), Interior Gateway Routing

Protocol (IGRP) or Enhanced Interior Gateway Routing Protocol (EIGRP) may be used to

automatically and dynamically create the routing tables and select routes in an adaptive

manner. The key model features are:

1. An IP forwarding rate of 60,000,000 packets/sec

2. The router model implements a "store and forward" type of switching methodology.

Implemented Protocols:

1. Ethernet (IEEE 802.3)

2. Internet Protocol (IP)

3. Routing Information Protocol (RIP)

4. User Datagram Protocol (UDP)

5. Open Shortest Path First (OSPF) Protocol

6. Border Gateway Protocol (BGP)

7. Interior Gateway Routing Protocol (IGRP)

8. Enhanced Interior Gateway Routing Protocol (EIGRP)

Slot Interface Technology

0 0-3 4 atmOC3

1 4-7 4 atmOC3

2 8 1 atmOC12

3 9 1 atmOC12

4 10-17 8 eth100T

5 18 1 eth1000T

6 19 1 eth1000T

7 20 1 eth1000T

8 21-32 12 SLIP DS3



42

9 33-36 4 SLIP OC3

10 37-40 4 SLIP OC3

11 41 1 SLIP OC12

12 42 1 SLIP OC12

13 43 1 SLIP OC48

14 44 1 SLIP OC48

Note: This router has 16 slots of which 15 slots are used as interface card slots and

one route processor slot. It has an aggregate switching capacity of 80 Gbps.

4.2.8. CISCO ROUTER CS_12008_8s_a5_fe8_ge1_sl9_adv NODE

The model CS_12008_8s_a5_fe8_ge1_sl9_adv represents the following device:


Product: CISCO 12008

Device Class: Gigabit Switch Router

Configuration: This model represents a specific configuration of an IP-based router

switch model.

Interconnections:




43


3. 1-port Packet over SONET (PoS) OC48 interfaces (PPP over SONET)(2.48832Gbps)

4. 4-port ATM OC3 (155.52Mbps).


6. 8-port 100BaseT Fast Ethernet (100Mbps).

7. 1-port 1000BaseT Gigabit Ethernet (1000 Mbps)

General Operation:

IP packets arriving on an IP interface are routed to the appropriate output interface

based on their destination IP address. The Routing Information Protocol (RIP), Open Shortest

Path First (OSPF) protocol, Border Gateway Protocol (BGP), Interior Gateway Routing

Protocol (IGRP) or Enhanced Interior Gateway Routing Protocol (EIGRP) may be used to

automatically and dynamically create the routing tables and select routes in an adaptive

manner. The key model features are:

1. An IP forwarding rate of 28,000,000 packets/sec

2. The router model implements a "store and forward" type of switching methodology.

Implemented Protocols:

1. Ethernet (IEEE 802.3)

2. Internet Protocol (IP)

3. Routing Information Protocol (RIP)

4. User Datagram Protocol (UDP)

5. Open Shortest Path First (OSPF) Protocol

6. Border Gateway Protocol (BGP)

7. Interior Gateway Routing Protocol (IGRP)

8. Enhanced Interior Gateway Routing Protocol (EIGRP)



44

Slot Interface Technology

0 0-3 4 atmOC3

1 4 1 atmOC12

2 5-12 8 eth100T

3 13 1 eth1000T

4 14-17 4 SLIP OC3

5 18-21 4 SLIP OC12

6 22 1 SLIP OC48

Note: This router has 8 slots of which 7 slots are used as interface card slots and one

route processor slot. It has an aggregate switching capacity of 40 Gbps.

4.2.9. CISCO ROUTER CS_7206_6s_a2_ae8_f4_tr4_slip16 NODE

The CS_7206_6s_a2_ae8_f4_tr4_slip16 model represents the following device:


Product: CISCO7204

Device Class: Router

Configuration: This model was created using the device creator utility and contains

the following technologies:



45

Technology IF/Port Count

ATM 2

Ethernet 8

FDDI 4

Token Ring 4

Slip 16

4.2.10. ETHERNET16_LAYER4_SWITCH NODE

The ethernet16_layer4_switch node model represents a layer-4 switch supporting up

to 16 Ethernet interfaces. The switch implements the Spanning Tree algorithm in order to

ensure a loop free network topology. Switches communicate with each other by sending

Bridge Protocol Data Units (BPDU's). Packets are received and processed by the switch

based on the current configuration of the layer-4 redirection information and the spanning

tree.

General Function: Switch

Supported Protocols: Spanning Tree Bridge, Ethernet

Protocols:

Spanning Tree Bridge Protocol (IEEE 802.1D), Ethernet (IEEE 802.3)



46

Interconnections:

1) 16 Ethernet connections at the specified data rate (10, 100, 1000 Mbps)

Restrictions:

The switch can only connect LAN's of the same type (Ethernet to Ethernet, FDDI to

FDDI, or Token Ring to Token Ring).

Port Interface Description:

Combination of up to 16 Ethernet ports (10 Mbps, 100 Mbps, or 1000 Mbps)

4.2.11. 100BaseT DUPLEX LINK

The 100BaseT duplex link represents an Ethernet connection operating at 100 Mbps.

It can connect any combination of the following nodes (except Hub-to-Hub, which cannot be

connected):

1) Station

2) Hub

3) Bridge

4) Switch

5) LAN nodes



47

Packet Formats:

Ethernet

Data Rate:

100 Mbps

Model Attributes:

"Propagation Speed": specifies the propagation speed (in meters/sec) for the medium.

If the "delay" attribute of the link is set to "Distance Based", this speed is used to calculate

the propagation delay based on the distance between two nodes.

Restrictions:

This link can not be used to connect two Ethernet hubs.

4.2.12. PPP_ADV POINT-TO-POINT LINK

The PPP_Adv point-to-point link connects two nodes with serial interfaces (e.g.,

routers with PPP ports) at a selectable data rate.

Packet Formats:

ip_dgram_v4, ipx_pkt



48

Data Rates:

Selectable (e.g., DS0, DS1, DS3, T1, T3, OC3, OC12, OC36, OC48).

4.3. NETWORK DESIGN AND IMPLEMENTATION IN OPNET

One of the first things to do in order to design and simulate the network is to

familiarize with OPNET. This is a powerful Network Simulation Package that will help us

design and simulate the network instead doing all the calculations by hand. After retrieving

the OPNET Modeler shortcut under the CAD tools on the SUN workstations we are ready to

launch the application.

Picture 3 Initial OPNET Modeler Logo

After the initial OPNET logo is displayed Picture 3, then it is time to create a new

project. This is done under the File menu New Project



49

By pressing ok, we were sent to the next window where we will put the name of the

Network that we want to build and also to name a scenario for it as well.

In our case, the name of the model was GUNET and the scenario position remained

as it was. Now, we are ready to insert the first attributes we want the program to have. This

mean, we created and empty scenario.

By pressing next, we are being sent to the next table, in which we can choose the

location where we want our network to be located in. In our case we choose World and in the

next table we choose Europe.



50

By pressing next, we will continue to the next dialog, where we must insert all the

nodes we want our template to include. This means to specify all the components like

routers, switches, LAN, links and servers.

After pressing the next button, a screen of Europe displays and then we have to zoom

in several times to reach to the desired location where our network will be designed which is

in Greece. After that, we can open the Object Pallet and start dragging the desired nodes in

the OPNET window and start building the network.



51

4.3.1. NETWORK CONFIGURATION

Since the network is an existing one and there can be no changes in the way it is

designed, the only thing that can be done is to specify the applications that will be supported

and different profile configurations for each university if needed

Since Differentiated Services is our main concern in this report, real-time applications

are the ones that we are mostly interested in. Hence videoconferencing and voip are

applications that will have to be included on the network, in addition to the HTTP services,

E-mail services, FTP services and Database access.

All the attributes of the nodes can be accessed by right click on the desired node and

then click on the attribute menu. By doing that, we can change the attributes in each node

separately, or we can choose the select similar nodes, do the required changes, press the

apply to all selected nodes tab and apply the new changes in all the selected nodes. By

applying this to all the desired nodes, the following changes where made:

4.3.1.1. APPLICATION CONFIGURATION

The Application Configuration Attributes can be seen in Picture 4 below:

Picture 4 Application Config for the Application Definitions



52

Inside the application definitions, is the table, were we can define all the applications

that we want to use on the network and the description of each application. The applications

that we used are FTP, Http, Email, Database, Voice and Video Conferencing and this can be

seen in Picture 5.

Picture 5 Applications Definition Table

By clicking inside the application and definition table in the description menu, we can

choose by High, Medium or Low setting of each application. The application descriptions for

the FTP application can be seen in Picture 6.

Picture 6 FTP Description Table



53

The FTP application was set to low load and the FTP table displays the values the

FTP low description has. This can be seen in Picture 7.

Picture 7 Ftp Table

The application descriptions for the Email application can be seen in Picture 6. Email

application was set to high load. This can be seen in Picture 8.

Picture 8 E-mail Description Table



54

The Email table displays the values that Email High description has. This can be seen

in Picture 9.

Picture 9 Email Table

The application description for the Database application can be seen in Picture 10. As

it can be seen the (…) value means that there was a change in the Database Table.

Picture 10 Database Description Table



55

The Database table displays the values that Email High application has. This can be

seen in Picture 9. Here we changes the Transaction Mix to 50% which means that half the

traffic will be the queries and the other half will be the response.

Picture 11 Database Table

The Http application was set to Heavy Browsing. The Http description table can be

seen in Picture 12.

Picture 12 HTTP Description Table



56

The Http table displays the values that Http application has. This can be seen in

Picture 13.

Picture 13 Http Table

The application description for the Voice application can be seen in Picture 14. As it

can be seen the (…) value means that there was a change in the Voice Table.

Picture 14 Voice Description Table



57

The change made in the Voice table was on the traffic mix, which means that the

voice application will be behave as background traffic, something that increased the

simulation speed and decreased the overall simulation time. Also the encoder scheme was

changed to GSM (silence) which is one of the best schemes because when there is no voice

detected in the network, no traffic will be transferred. This can be seen in Picture 15

Picture 15 Voice Table

The application description for the Video Conferencing application can be seen in

Picture 16. As it can be seen the (…) value means that there was a change in the Video

Conferencing Table.

Picture 16 Video Conferencing Description Table



58

The change made in the Video Conferencing table was on the traffic mix as

mentioned earlier in the voice table, which means that the Video Conferencing application

will be behave as background traffic, something that increased the simulation speed and

decreased the overall simulation time. This can be displayed in Picture 17.

Picture 17 Video Conferencing Table

In order for Voice Application to work, we need to define the Voice encoder

Schemes. This is done by clicking in the voice encoder scheme value as displayed in Picture

18 below:

Picture 18 Application Config for the Voice Encoder Schemes



59

In order to be sure that there will be no problems in specifying the correct Voice

Encoder Scheme, as it can be seen in Picture 19, all the supported schemes were inserted.

Picture 19 Voice Encoder Schemes

4.3.1.2. PROFILE CONFIGURATION

Now that the Application Config is configured, it is time to setup the Profile Config.

Picture 20 displays the Profile Config. It was decided that it would be better to use separate

profiles for each University even though all the profile configurations will be the same.

Hence there are sixteen profiles created as it can be seen in Picture 21 and a profile that is

only for Video Conferencing.



60

Picture 20 Profile Config Attributes

Picture 21 Profile Configuration Table



61

It can also be seen that the Operation mode is set to Simultaneous which means that

all profiles will run together instead of running in serial order which means that all profiles

would run one after another which wouldn’t be so realistic.

By clicking inside the application inside the Profile Configuration of each University,

we can set the different applications we want the profile to have. The following applications

can be seen as displayed in Picture 22 below:

Picture 22 Application Profile Configuration for each University

For the Video Conferencing profile the following Application table can be seen as

displayed in Picture 23 below:

Picture 23 Video Conferencing Application Profile



62

4.3.1.3. 100BaseT_LAN CONFIGURATION

Since no information on the exact number of the workstations in each University can

be found and the traffic is already known from the GUNET network monitor program, it was

decided that instead of adding random number of workstations on the network trying to

create the same amount of traffic that the workstations produce in reality, all that traffic

would be implemented as background traffic on the links and only the workstations of the

lecturers would be the ones that the applications would be implemented on.

Once again since the number of the actual workstations for the lectures could be

found, an assumption was made that in each university there will be two LANs. Each LAN

would support the appropriate Profile Configuration plus one of the two LANs would support

the Video Conference as well. Since Voice and Video Conferencing work better when they

are set-up with destination preferences, each LAN was renamed accordingly to the

University that they represent. The one that would support Video Conferencing would be

renamed as LAN_0 and the other would be LAN_1.

4.3.1.3.1. LAN_1 CONFIGURATION

For LAN_1 the following values were changed.

First change is to rename the name of the node and insert the initials of the

University it represents

Under the Application Supported Profiles we will insert the appropriate

profile for the university that the LAN represents. This can be seen in Picture

25

Under the Application Supported Services we will insert the appropriate

service which for LAN_1 is only Voice. This can be seen in Picture 26

Under LAN Server Name we insert the initials of the University it represents.



63

Under the Application Destination Preferences we will insert all the

destinations we want the supported services to go. This is shown in Picture 27

Under the Number of workstation we changed the default value of 10 to 25

which is a more realistic value for a University.

Picture 24 LAN_1 Attributes



64

The application Supported Profiles table can be seen in Picture 25 below:

Picture 25 LAN_1 Application Supported Profiles

The Application Supported Profiles of LAN_1 can be seen in Picture 26 below

Picture 26 LAN_1 Application Supported Services

Picture 27, displays the Application Destination Preferences table, where we can

specify the Actual Name destination of the voice application.



65

Picture 27 LAN_1 Application Destination Preferences

Assuming that each workstation has the ability to call any workstation on the GUNET

Network even workstations in the same LAN, the following settings where inserted in the

Actual name Table as it can be seen in Picture 28. In the left column we can see the

destinations and in the right column we can see the Selection Weight of the application

where we can select the type of priority with respect to the rest applications.



66

Picture 28 LAN_1 Actual Name Table



67

4.3.1.3.1. LAN_0 CONFIGURATION

For LAN_0 the following values were changed.

First change is to rename the name of the node and insert the initials of the

University it represents

Under the Application Supported Profiles we will insert the appropriate

profile for the university that the LAN represents. For LAN_0 we have two

profiles. One is the University it represents and the other is the Video

Conferencing profile. This can be seen in Picture 30

Under the Application Supported Services we will insert the appropriate

service which for LAN_0 is not only Voice but Video Conferencing as well.

This can be seen in Picture 31

Under LAN Server Name we insert the initials of the University it represents.

Under the Application Destination Preferences we will insert all the

destinations we want the supported services to go. Since we have two

supported applications that need destination preferences, for the voice is the

same as mentioned earlier in Picture 27 and for the video conferencing the

applications destinations preferences can be seen in Picture 32

Under the Number of workstation we changed the default value of 10 to 25

which is a more realistic value for a University



68

Picture 29 LAN_0 Attributes

The application Supported Profiles for LAN_0 can be seen in Picture 30

Picture 30 LAN_0 Application Supported Profiles



69

Picture 31 displays the two Application Supported Profiles for LAN_0.

Picture 31 LAN_0 Application Supported Services

Since we want the LAN to communicate with all the other LANs, but since the Video

Conferencing is only supported by the LAN_0 LANs, then a new Actual Name Table was

crated for this application as it can be seen in Picture 33 with all the LAN_0 ones.

Picture 32 LAN_0 Application Destination Preferences



70

Picture 33 LAN_0 Actual Name Table

4.3.1.4. ROUTERS CONFIGURATION

All the routers attributes remained at default settings. The only change made on the

routers was the name. The name of the router corresponds to the location it is in and in other

cases the initials of the university it represents.

4.3.1.5. SWITCH CONFIGURATION

The switches were used to connect the two LANs with the University router and the

only change that was made in the attributes was the name, where the initials of the University

it represents was inserted.



71

4.3.1.6. PPP_SERVER CONFIGURATION

There are four PPP_Servers inside each University. These servers were inserted in

order to support some of the applications that would run across the network. Each server

would support one application only. Hence the four servers were used to run HTPP, FTP,

Email and Database services. The PPP_Servers are connected with the University router with

1Gbps links.

Picture 34 PPP_Server Attributes



72

Under the application supported services, we inserted 1 row and choose to insert the

Http heavy application. All the other servers were done accordingly to the application they

would support

Picture 35 PPP_Server Application Supported Services

4.3.1.7. LINKS UTILISATION

As mentioned earlier, the traffic of the computers will be implemented as background

utilization on the links. This utilization is based on the two hours average traffic that was

found from the online GUNET networking monitor software. It was decided to get the two

hours average on the assumption that the simulation of the network would run for two hours,

something that couldn’t be done since in the end when running the simulations, a few

minutes would take days to finish.

The Utilization on the links was implemented in the Links attributes under the

Background load attribute. The way that the utilization was implemented can be seen in

Picture 36.



73

Picture 36 Link Attributes

Under the background load, we changed the intensity of the traffic in bps both

incoming and outgoing. These changes were done by clicking to change the intensity (bps)

value. A new window appears where we can put the number of bits/sec we want to put and

the period that we want this utilization to have. This can be seen in Picture 37 and Picture 38.



74

Picture 37 Incoming Background Loading Table

Picture 38 Outgoing Background Loading Table

The Background traffic was implemented in most of the links. Theses changes can be

seen in the following tables. Table 4 below displays the network activity on each link of the

backbone network.



75

Links between Routers Data carried in (bits/sec) Data carried out (bits/sec)

Athens - Thessaloniki 34.100.000 (bits/sec) 37.600.000 (bits/sec)

Athens -Patra 29.700.000 (bits/sec) 29.500.000 (bits/sec)

Athens - Heraklio 29.800.000 (bits/sec) 46.500.000 (bits/sec)

Athens - Rhodes 14.600.000 (bits/sec) 16.700.000 (bits/sec)

Thessaloniki - Xanthi 2.321,2 (bits/sec) 2589,1 (bits/sec)

Thessaloniki - Larissa 8.896 (bits/sec) 7.683,2 (bits/sec)

Patra - Ioannina 1.112,2 (bits/sec) 1.395,6 (bits/sec)

Table 4 Background Utilization between the City Routers

In some cases, this utilization is also for the traffic between the city routers and the

university router. Table 5 and Table 6 display the network activity between the city routers

and the university router.

City Router to University

Router

Data carried in

(bits/sec)

Data carried out

(bits/sec)

Thessaloniki Router to

Aristotelio University

19.600.000 (bits/sec) 23.700.000 (bits/sec)


Macedonia University

6.335,1 (bits/sec) 5.570,1 (bits/sec)

Patra Router to

Patra University

22.400.000 (bits/sec) 22.500.000 (bits/sec)

Table 5 Background Utilization between City Router and University Router



76

City Router to University

Router

Data carried in

(bits/sec)

Data carried out

(bits/sec)

Xanthi Router to

Thrace University

2.321,2 (bits/sec) 2589,1 (bits/sec)

Larissa Router to

Thessaly University

8.896 (bits/sec) 7.683,2 (bits/sec)

Ioannina Router to

Ioannina University

1.112,2 (bits/sec) 1.395,6 (bits/sec)

Heraklio Router to

Creta University

16.900.000 (bits/sec) 23.000.000 (bits/sec)

Table 6 Background Utilization between City Router and University Router

Unfortunately, exact number of the loading between the Athens routers and the

universities couldn’t be found and the only traffic implemented is based only between the

Athens Routers. There are three routers in ring topology in Athens which are connected with

2.5Gbps links and one of the routers connects to Athens city router with 1GBps link. Table 7

displays the Background Utilization between the Athens Routers and Table 8 displays the

Background Utilization between Athens City router and Athens Router

Athens Router to

Athens Router

Data carried in

(bits/sec)

Data carried out

(bits/sec)

Athens Router to

Acropolis Router

8.863,4 (bits/sec) 20.500.000 (bits/sec)

Athens Router to

Ilissos Router

96.500.000 (bits/sec) 375.900.000 (bits/sec)

Acropolis Router to

Ilissos Router

4.944 (bits/sec) 4.920 (bits/sec)

Table 7 Background Utilization between Athens Routers



77

City Router to

Router

Data carried in

(bits/sec)

Data carried out

(bits/sec)

Athens City Router to

Athens Router

85.000.000 (bits/sec) 75.900.000 (bits/sec)

Table 8 Background Utilization between Athens City Router and Athens Router

Unfortunately in most cases, the GUNET was a highly utilized network and by

getting voice and video conferencing in the network would certainly have a big impact on it.

Hence some of the links needed to be upgraded without of course exceeding the GRNET

links capacity available. In one case though the link was downgraded in order to get some

congestion later on the network during simulation time. Hence Table 9 displays the new

capacity of the backbone network.

Links between Routers Initial Capacity (Mbps) Upgraded Capacity (Mbps)

Athens - Thessaloniki 69 (Mbps) 100 (Mbps)

Athens -Patra 45 (Mbps) 60 (Mbps)

Thessaloniki - Xanthi 6 (Mbps) 12 (Mbps)

Thessaloniki - Larissa 18 (Mbps) 12 (Mbps)

Patra - Ioannina 4.5 (Mbps) 12 (Mbps)

Table 9 Capacity of the Upgraded Backbone Network

Some changes on the capacity of the links occurred from the City routers to the

University routers as well. These changes can be seen in Table 10 below. In two cases where

the universities are located in Athens, the capacity of the link was upgraded from 2 Mbps to

1000 Mbps since all the other universities of Athens use Gbit links.



78

Links between City Router

and University Router

Initial Capacity (Mbps) Upgraded Capacity

(Mbps)


Aristotelio University Router

34 (Mbps) 60 (Mbps)


Macedonia University Router

18 (Mbps) 22 (Mbps)

Xanthi Router to Thrace

University Router

21 (Mbps) 22 (Mbps)

Larissa Router to

Thessaly University Router

8 (Mbps) 22 (Mbps)

Patra Router to

Patra University Router

34 (Mbps) 60 (Mbps)

Ioannina Router to

Ioannina University Router

22 (Mbps) 22 (Mbps)

Athens Acropolis Router to

Harokopio University

2 (Mbps) 1000 (Mbps)

Athens Ilissos Router to

University of Good Arts

2 (Mbps) 1000 (Mbps)

Table 10 Capacity of the Upgraded Links between City Routers and University Routers

4.3.2. APPLYING QoS ON GUNET

4.3.2.1. SETTING UP THE APPLICATION CONFIGURTION

By reading several times the tutorial of OPNET on applying QoS in a network, the

attempt on applying QoS on the GUNET network was made. Fortunately the tutorial was

very helpful and the beginning of the simulation stared immediately. In order to configure



79

the network, we should first declare in the application configuration node the priority of the

applications we wanted to test under QoS. The two applications in which we changed the

priority settings was voice and video conferencing and on both we inserted the same setting

for priority. By default, both applications are set to best effort (0) as seen Picture 39 and in

Picture 40.

Picture 39 Voice Table

Picture 40 Video Conferencing Table

By clicking on the Type of Service value, a new window appears. This window can be seen

in Picture 41.



80

Picture 41 ToS/DSCP Priority Table

The options that we have in order to change the priority of the application can be seen

in Picture 42.

Picture 42 Options of different Priority Settings



81

Unfortunately due to luck of time, only the best priority could be simulated. Hence,

the settings on this window was changed from best effort (0) to Reserved (7). And also, in

order to have the best priority of the application, we clicked added the three options below

the type of service window in order the application to work better also for delay, throughput

and reliability. The final settings can be seen in Picture 43.

Picture 43 Final ToS/DSCP Priority Table

Since from the first minute it was observed that the simulation would take ages to

finish, we had to build the same project seven times and run each different queuing scenario

in different workstations in order to finish within the time limit.



82

4.3.2.2 SETTING UP QoS SCHEMES

In order to apply the different QoS schemes, we did the following steps: First of all

was to setup the FIFO profile. Although the routers have by default the FIFO queue, a

simulation was implemented to get the results. All the other scenarios with the different

queuing techniques ware based on FIFO queue and the desired queuing method. This was

done by pressing the Protocols tab in the program. This can be seen in Picture 44.

Picture 44 Setting Up QoS Schemes

By pressing the configure QoS menu, a new window appears. This window is where

we can change the different queues and can be seen in Picture 45.



83

Picture 45 QoS Configuration Table

The different queuing techniques available at OPNET Modeller are displayed in

Picture 46

Picture 46 Available Queuing Techniques

By selecting the desired queuing technique and applying the changes on the QoS

configuration table, all the connected interfaces on the network will be automatically

configured to run the selected QoS scheme.

The way that the different projects were named was the following:



84

Project Name Queuing Technique

GUNET 1 Lower Links FIFO

GUNET 2 Lower Links WFQ

GUNET 3 Lower Links Priority Queuing

GUNET 4 Lower Links Custom Queuing

GUNET 5 Lower Links MWRR

GUNET 6 Lower Links DWRR

GUNET 7 Lower Links MDRR

By changing the Type of Service from ToS to DSCP (252) which is the highest

priority settings and running a simulation, there wasn’t any change on the results and hence

only the ToS was the one that was used to change the priority.

These were the only changes made in order to run the simulation and applying QoS

respectively.

CHAPTER 4 --------------------------------------------------------------------------------------------31 4.1. NETWORK DECISION AND IMPLEMENTATION------------------------------------31 4.2. COMPONENTS USED -----------------------------------------------------------------------35

4.2.1. APPLICATION CONFIG .................................................................................... 35

4.2.2. PROFILE CONFIG .............................................................................................. 36

4.2.3. QoS CONFIG........................................................................................................ 37

4.2.4. SUBNET NODE................................................................................................... 37

4.2.5. 100BaseT_LAN NODE ........................................................................................ 38

4.2.6. PPP_SERVER NODE .......................................................................................... 38

4.2.7. CISCO ROUTER CS_12016_16s_a10_fe8_ge3_sl24_adv NODE ..................... 40

4.2.8. CISCO ROUTER CS_12008_8s_a5_fe8_ge1_sl9_adv NODE ........................... 42

4.2.9. CISCO ROUTER CS_7206_6s_a2_ae8_f4_tr4_slip16 NODE ........................... 44

4.2.10. ETHERNET16_LAYER4_SWITCH NODE ..................................................... 45

4.2.11. 100BaseT DUPLEX LINK ................................................................................. 46

4.2.12. PPP_ADV POINT-TO-POINT LINK ................................................................ 47

4.3. NETWORK DESIGN AND IMPLEMENTATION IN OPNET ------------------------48 4.3.1. NETWORK CONFIGURATION......................................................................... 51

4.3.1.1. APPLICATION CONFIGURATION---------------------------------------------51



85

4.3.1.2. PROFILE CONFIGURATION ----------------------------------------------------59 4.3.1.3. 100BaseT_LAN CONFIGURATION --------------------------------------------62 4.3.1.4. ROUTERS CONFIGURATION---------------------------------------------------70 4.3.1.5. SWITCH CONFIGURATION-----------------------------------------------------70 4.3.1.6. PPP_SERVER CONFIGURATION ----------------------------------------------71 4.3.1.7. LINKS UTILISATION -------------------------------------------------------------72

4.3.2. APPLYING QoS ON GUNET ............................................................................. 78

4.3.2.1. SETTING UP THE APPLICATION CONFIGURTION ----------------------78 4.3.2.2 SETTING UP QoS SCHEMES-----------------------------------------------------82



85

CHAPTER 5

5.1. GUNET_1 FIFO

5.1.1. VOICE

As a test to see if OPNET was working correctly, the simulation was run twice

with the FIFO queuing. From the picture below we can see only one graph for both

scenarios, which means that both graphs are 100% similar. This is because when in

OPNET results coincide with each other in overlay mode the program shows only the first

graph and does not multiplex the colours together. The End-to-End delay is the time taken

for a packet from the moment it leaves from the source to the moment it reaches the

destination. The smaller the End-to-End delays the better for the users.

Clearly in the picture we can see that the traffic is generated just after the second

minute of the simulation and increases vertically up to the third minute before it starts to

stabilize but still it continues to increase because the utilisation of the network is

increasing. This is due to the fact that the links of the network are setup to work on high

utilization in order to apply differentiated services. If the utilization of the links were low,

then by applying the differentiated services would actually give worst End-to-End delays

because it would take more time for the routers to apply the different queuing techniques

plus to send the data instead of sending the data directly.



86

Picture 1 Voice Packet End-to-End Delay

We can see in the graph below that the delay variation increases up to a certain

point when the traffic starts and then stabilizes a little. Then it starts decreasing slowly.

This means that the delay of the network is high in the beginning of the simulation and

then drops down as the traffic of the network moves on and because the network can

handle the traffic adequately.

Picture 2 Voice Packet Delay Variation



87

5.1.2. VIDEO CONFERENCING

In the graph below, we can see that the video conferencing, the end-to-end delay

is increasing in the beginning of the simulation up to a certain point and from that point

onwards it degrades rapidly. This is done because the utilization of the network gets to a

steady state after a while and the data throughput of the routers stabilizes to a certain

value dropping the end to end delay.

Picture 3 Video Conferencing Packet End-to-End Delay

We can see in the graph below that the delay variation increases up to a certain

point when the traffic starts. Then it starts decreasing rapidly. This means that the delay

of the network is high in the beginning of the simulation and then drops down as the

traffic of the network moves on and because the network can handle the traffic

adequately. As well we can see that the video had a smoother end-to-end delay and also a

better packet delay variation by comparing it with the voice. This is because, the video

conferencing application sent larger amounts of data and makes fewer transactions, where

the voice application is sending smaller amounts of data but has more transactions.



88

Picture 4 Video Conferencing Packet Delay Variation

5.2. GUNET_2 WFQ

5.2.1 VOICE

In the graph below we can see that WFQ compared to FIFO behaves much worse.

The end-to-end delay has increased significantly. While the FIFO delay is around 0.075

seconds in average the network with WFQ not only has a much higher delay but also it

never stabilizes to a certain value but continues to increase for the entire time that the

simulation was run.



89


In the graph below, we can observe that the blue which is the Fifo queuing, from

the minute the end-to-end delay stabilized, the packet delay variation started to drop.

Same thing can be seen for the red graph as well. From the minute it starts to stabilize, the

packet delay variation starts to decrease which means that the end-to-end delay starts to

stabilize.




90


In the graph below, we see that once again FIFO queuing works much better

compared to WFQ. Although the end-to-end delay is increased and is always more than

the Fifo end-to-end delay, we can see that while traffic goes on, the red which represents

the WFQ queuing is more smooth than the blue graph. We could say that while the WFQ

performs worst than Fifo, the WFQ queuing has smoother characteristics.


The graph below displays the video conferencing packet delay variation. As

expected, the Fifo queuing has stabilized as soon as the traffic went along and have a

normal behavior. The WFQ queuing had a new pinch which means that the packet delay

variation is not stable up to the time that the simulation finished.



91


5.3. GUNET_3 PRIORITY QUEUING

5.3.1. VOICE

The graph below displays the voice end-to-end delay using the Priority Queuing

technique. This is displayed with the red graph and the blue represents the FIFO queuing.

As we can see, by comparing the two graphs, the difference between the red and blue

graph is quite large which means that Priority Queuing is much more efficient than the

Fifo queuing since it produces much better results. We can also see that while the blue

graph is still increasing, the red has almost stopped increasing and is much smoother.

Priority queuing could be one option for an Internet Service Provider who wants to

promise some specific SLAs.



92


The graph below displays the voice packet delay variation. As we can see, the

priority queuing is much smoother and much smaller than the Fifo queuing which is

expected since the end-to-end delay of priority queuing was quite smooth. From the blue

graph, we can see that from the minute that the end-to-end delay starts to stabilize, the

packet delay variation starts to decrease.




93


The graph below, displays the end-to-end delay using the priority queuing and the

Fifo queuing. Although the blue graph which represents the Fifo queuing has a big spike

in the beginning of the simulation, in the end it has a smaller end-to-end delay which is

better than the red graph which represents the Priority queuing. By comparing the blue

graphs we can see that the red although in the end has an increased delay, the graph is

more stable than the blue. This is better again for Internet Service Providers when the

want to specify the SLAs because the delay didn’t have any major spikes.


As expected, the video conferencing packet delay variation of the priority queuing

is much better than the Fifo queuing. From the beginning of the simulation the red graph

is almost a straight line which means that there is no delay variation and the blue has a big

spike in the beginning which means that there was delay variation in the beginning of the

simulation but it degraded immediately. But in the end, the priority queuing is still the

best option over Fifo queuing.



94


5.4. GUNET_4 CUSTOM QUEUING

5.4.1. VOICE The graph below displays the voice end-to-end delay using the Custom Queuing

technique. This is displayed with the red graph and the blue represents the FIFO queuing.

As we can see, by comparing the two graphs, the difference between the red and blue

graph is quite large which means that Custom Queuing is much more efficient than the

Fifo queuing since it produces much better results. Custom queuing even gave better

results from Priority queuing whish was the best so far up to that point. We can also see

that while the blue graph is still increasing, the red has stopped increasing and is much

smoother. Custom queuing could be the best option for an Internet Service Provider who

wants to promise some specific SLAs.



95


The graph bellow displays the voice packet delay variation. We can observe that

the red graph is a straight line just above the x axis which means that there is minimum

delay variation The blue graph which is the Fifo queuing has a big spike in the beginning

of the simulation and as soon as traffic goes on, it starts degrading but still far away from

the custom queuing technique.




96


The graph below displays the video conferencing end-to-end delay. As we can

see, custom queuing once again performed much better than Fifo queuing. As we can see,

fifo although it started with a drop of the end-to-end delay, it increased rapidly and as the

traffic kept going, it started degrading again. The custom queuing which is represented by

the red graph, from the beginning of the simulation decreased and after a few minutes of

simulation, the line was a straight line. Once again, a very good option when specifying

SLAs is needed.


The graph below displays the video conferencing packet delay variation. As we

can see, the Fifo queuing has a spike in the beginning of the simulation, and then it

degrades immediately and as the traffic goes on, we see that due to the high utilisation of

the network, the packet delay variation increases again. The custom queuing represented

by the red graph, from the beginning of the simulation is a straight line close to the x axis

which means that there is minimal delay variation.



97


5.5. GUNET_5 MWRR

5.5.1. VOICE

In the graph below we can see that MWRR compared to FIFO behaves much

worse. Similar results as the WFQ queuing were obtained. The end-to-end delay has

increased significantly. While the FIFO delay is around 0.075 seconds in average the

network with MWRR not only has a much higher delay but also it never stabilizes to a

certain value but continues to increase for the entire time that the simulation was run.



98


In the graph below, we can observe that the blue which is the Fifo queuing, from

the minute the end-to-end delay stabilized, the packet delay variation started to drop.

Same thing can be seen for the red graph as well. From the minute it starts to stabilize, the

packet delay variation starts to decrease which means that the end-to-end delay starts to

stabilize.




99


In the graph below, we see that once again FIFO queuing works much better

compared to MWRR. Although the end-to-end delay is increased and is always more than

the Fifo end-to-end delay, we can see that while traffic goes on, the red which represents

the MWRR queuing is more smooth than the blue graph. We could say that while the

MWRR performs worst than Fifo, the MWRR queuing has smoother characteristics.


The graph below displays the video conferencing packet delay variation. As

expected, the Fifo queuing has stabilized as soon as the traffic went along and have a

normal behavior. The MWRR queuing had a new pinch which means that the packet

delay variation is not stable up to the time that the simulation finished.



100




101

6. CONCLUSION

The purpose of this project was to monitor the traffic on a network by implementing

Differentiated Services.

The GUNET network was proposed in order to implement DiffServ since it is a

slightly congested network and voice and video conferencing are applications that a technical

team is trying to insert to the network nowadays. The network uses as a backbone a part of

the GRNET links to transfer data between the universities. Due to the fact that GUNET

doesn’t use the whole capacity of the GRNET, some upgrades on the links were made in

order to get voice and video application a real possibility to be implemented.

The links although the network was setup in the beginning to provide with real-time

delays, when differentiated services were implemented, we had to downgrade the links in

order to increase the utilization on the links since DiffServ applies to congested networks.



102

CHAPTER 7

7.1. PROBLEMS OCCURRED AND LIMITATIONS

During the project period, there were many problems that occurred in the design and

simulation of the network. These problems were mostly with the OPNET Modeler package

and its configuration.

First problem that was observed was that when designing the network, it was

impossible to have both PPP and FDDI links in the network. While running the simulation,

the error that was given was the IPRouting wasn’t configured and more than two nodes had

the same IP which confused the program.

Second problem observed was that once the Hard disk limit on the account was on its

limits, then the program would turn the links to default values which in the end of the

simulation gave too many errors because all the links returned to default values and the

utilization of the network increased to 100% and hence the network had to keep

retransmitting data.

Third problem and limitation was found as soon as QoS was implemented on the

network. As soon as the simulation was starting, the speed of the simulation degraded

something that affected the time taken to finish each simulation, or the program would stop

responding and no results were obtained. Also, this is the reason why I have all my project

scenarios in separate projects and not only one where it would be much easier to discuss on

the results since all the results would be in the same screenshot.

All these problems during the period of the project had as an affect on the time

needed to finish all the simulations on schedule and spend less time on writing the final

report.



103

7.2. FUTURE IMPROVEMENTS Unfortunately due to the many problems and limitations observed during the period

of the project, time didn’t allow doing some more work on different architectures of QoS.

Hence as future work, Integrated services, RSVP could be implemented on the network and

hence we could observe and compare the two QoS architectures, in order to find the

capabilities of each one.

Another thing that could be done is to add some wireless networking inside the

University Subnets since more and more enterprises and organizations change from wired to

wireless networks.



104

CHAPTER 8 ]

8.1. REFERENCES

[1] N. Savage. (2004). B351 Multimedia Networks Study Notes, Portsmouth

University

[2] OPNET Online Tutorial. University of Portsmouth Department of Computer &

Electronic Engineering

[3] OPNET Online Documentation. University of Portsmouth Department of

Computer & Electronic Engineering

[4] Gremont, Boris (Dr.) “Data Communications & Networks 1” Issue 3

University of Portsmouth 2000-2001 Department of Computer & Electronic

Engineering

[5] OPNET Modeller Manual v9

8.2. INTERNET REFERNCES - BIBLIOGRAPHY

1) http://docs.sun.com/db/doc/816-4094/6mab39ut0?a=view

2) http://kabru.eecs.umich.edu/qos_network/diffserv/DiffServ_links.html

3) http://qos.ittc.ukans.edu/DiffSpec/node5.html

4) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm#1020698

5) http://www.cisco.com/warp/public/732/Tech/qos/

6) http://www.ietf.org/html.charters/diffserv-charter.html

7) http://www.informit.com/articles/article.asp?p=26125&seqNum=3




105

9) http://www.objs.com/survey/QoS.htm

10) http://www.protocols.com/papers/diffserv.htm

11) http://www.sciencedaily.com/encyclopedia/differentiated_services

12) http://www.telecom.tuc.gr/networkcourse/1

13) http://www.webopedia.com/TERM/Q/QoS.html

14) http://www.gunet.gr/index.pl?id=3121

15) http://netmon.grnet.gr/traffic/

16) http://diffserv.sourceforge.net/

17) http://qos.ittc.ukans.edu/diffoverview/index.htm

18) http://qos.ittc.ukans.edu/ipqos/ip_qos.htm


20) http://www.ypes.gr/nomarxiakh_aut.htm

21) http://www.ellada.net/travelinfo/rhodes.html

22) http://www.webopedia.com/TERM/A/ATM.html

23) http://www.webopedia.com/TERM/T/throughput.html

24) http://www.linktionary.com/s/sbm.html

25) http://www.telecom.tuc.gr/networkcourse/qos.ppt


27)http://66.102.9.104/search?q=cache:http%3A%2F%2Fwww.hep.ucl.ac.uk%2F~ytl%2

Fqos%2Findex.html

28)http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcp

rt1/qcdclass.htm

29) http://www.opalsoft.net/qos/WhyQoS.htm

30)http://www.cisco.com/en/US/netsol/ns339/ns392/ns399/ns404/networking_solutions_

white_paper0900aecd800dd974.shtml

31)http://www.cisco.com/en/US/products/sw/iosswrel/ps1820/products_feature_guide09

186a00800f4891.html#29478

32)http://www.cisco.com/en/US/tech/tk331/tk336/technologies_design_guide09186a008

0237a48.shtml#wp16388

33) http://www.cisco.com/warp/public/63/mdrr_wred_overview.html

34) http://networking.ittoolbox.com/documents/document.asp?i=2528



106


36)http://www.cisco.com/warp/public/105/dscpvalues.html#dscpandassuredforwardingcl

asses

37) http://www.cse.ohio-state.edu/~jain/cis788-99/ftp/qos_protocols/

38)http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/class/qpm1_1/usi

ng_qo/c1plan.htm#xtocid321027

39) http://www.cse.ohio-state.edu/~jain/cis788-99/ftp/qos_protocols/index.html

Last accessed 20/09/04



104

CHAPTER 8 ]

8.1. REFERENCES

[1] N. Savage. (2004). B351 Multimedia Networks Study Notes, Portsmouth

University

[2] OPNET Online Tutorial. University of Portsmouth Department of Computer &

Electronic Engineering

[3] OPNET Online Documentation. University of Portsmouth Department of

Computer & Electronic Engineering

[4] Gremont, Boris (Dr.) “Data Communications & Networks 1” Issue 3

University of Portsmouth 2000-2001 Department of Computer & Electronic

Engineering

[5] OPNET Modeller Manual v9

8.2. INTERNET REFERNCES - BIBLIOGRAPHY


2) http://kabru.eecs.umich.edu/qos_network/diffserv/DiffServ_links.html

3) http://qos.ittc.ukans.edu/DiffSpec/node5.html

4) http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm#1020698


6) http://www.ietf.org/html.charters/diffserv-charter.html





105

9) http://www.objs.com/survey/QoS.htm

10) http://www.protocols.com/papers/diffserv.htm


12) http://www.telecom.tuc.gr/networkcourse/1

13) http://www.webopedia.com/TERM/Q/QoS.html

14) http://www.gunet.gr/index.pl?id=3121

15) http://netmon.grnet.gr/traffic/

16) http://diffserv.sourceforge.net/

17) http://qos.ittc.ukans.edu/diffoverview/index.htm

18) http://qos.ittc.ukans.edu/ipqos/ip_qos.htm


20) http://www.ypes.gr/nomarxiakh_aut.htm

21) http://www.ellada.net/travelinfo/rhodes.html

22) http://www.webopedia.com/TERM/A/ATM.html

23) http://www.webopedia.com/TERM/T/throughput.html

24) http://www.linktionary.com/s/sbm.html

25) http://www.telecom.tuc.gr/networkcourse/qos.ppt


27)http://66.102.9.104/search?q=cache:http%3A%2F%2Fwww.hep.ucl.ac.uk%2F~ytl%2

Fqos%2Findex.html

28)http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcp

rt1/qcdclass.htm

29) http://www.opalsoft.net/qos/WhyQoS.htm

30)http://www.cisco.com/en/US/netsol/ns339/ns392/ns399/ns404/networking_solutions_

white_paper0900aecd800dd974.shtml

31)http://www.cisco.com/en/US/products/sw/iosswrel/ps1820/products_feature_guide09

186a00800f4891.html#29478

32)http://www.cisco.com/en/US/tech/tk331/tk336/technologies_design_guide09186a008

0237a48.shtml#wp16388

33) http://www.cisco.com/warp/public/63/mdrr_wred_overview.html

34) http://networking.ittoolbox.com/documents/document.asp?i=2528



106


36)http://www.cisco.com/warp/public/105/dscpvalues.html#dscpandassuredforwardingcl

asses

37) http://www.cse.ohio-state.edu/~jain/cis788-99/ftp/qos_protocols/

38)http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/class/qpm1_1/usi

ng_qo/c1plan.htm#xtocid321027

39) http://www.cse.ohio-state.edu/~jain/cis788-99/ftp/qos_protocols/index.html

Last accessed 20/09/04

Documents

Network Traffic Control