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
Portsmouth University
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.
Ioannis Gallikas MSc
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
ii
GLOSSARY
ATM CoS CQ DIFFSERV DLSw DWRR FIFO FTP GRNET GUNET INTSERV IP IPX ISP MDRR MPLS PPP PQ QoS PBR RSVP SAP SMB SNA TCP ToS UDP VOIP WFQ Asynchronous Transfer Mode Class of Service Custom Queuing Differentiated Services Data-Link Switching Deficit Weighted Round Robin First In First Out File Transfer Protocol Greek Network Greek Universities Network Integrated Services Internet Protocol Internetwork Packet Exchange Internet Service Provider Modified Deficit Round Robin Multi Protocols Labeling Switching Point to Point Priority Queuing Quality of Service Policy-Based Routing ReSerVation Protocol Service Advertising Protocol Subnet Bandwidth Management Systems Network Architecture Transmission Control Protocol Type of Service User Datagram Protocol Voice Over IP Weighted Fair Queuing
iii
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.
Page 1
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 computerbased 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 Qualityof-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.
Page 2
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 countrys 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.
Page 3
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 companys network is the backbone of the companys 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. 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 applications QoS request, and subject to bandwidth management policy (internet reference 27) These kinds of applications are bandwidth demanding and sometimes these services need to have predictable
Page 4
Prioritization (differentiated Services) where the network traffic is classified and apportioned network resources according to bandwidth management policy criteria. A networks 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 doesnt 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 Page 5 Ioannis Gallikas MSc
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 PerAggregates. 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]
Page 6
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
Page 7
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
Page 8
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 SLAs. [1]
Page 9
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 1 3 Application Non-critical data Similar to Internet today No minimum information rate guaranteed Mission-critical data VPN outsourcing, ecommerce Similar to ATM VBR Real time applications Video streaming, voice, videoconferencing Priority Mapping Best-effort delivery Unmanaged performance
Low loss rate Controlled delay and delay variation Low loss rate Low delay and delay variation
Table 1. Quality service parameters (Internet reference 25)
Page 10
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 headers 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
Page 11
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.
Page 12
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 its 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.
Flow 1 Flow 2 Flow 3 Flow 4 Flow 5 Flow 6 Flow 7 Flow 8
5 3
2 6 4
FIFO Queue Multiplexer 6 5 4 3 2 1
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 doesnt have any other choice for them.
Page 13
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.
Page 14
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.
Page 15
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.
Page 16
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.
Page 17
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.
Page 18
( 50% B/W, Quantum [1] = 1000 ) Queue 1 Scheduler
( 25% b/w, Quantum [2] = 500 )

Queue 2 Queue 3 ( 25% b/w, Quantum [3] = 500 ) Q3
Q1
Port
Q2
2.1.3. MULTI PROTOCOL LABEL SWITSHING (MPLS)

MPLS is a hybrid technology that combines the best of ATMs circuit switching and the IPs 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 layer2 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]
Page 19
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)
Page 20
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 industrys 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 worlds most prestigious technology organizations to accelerate the R&D process. [5] Modellers object-oriented modelling approach and graphical editors mirror the structure of actual networks and network components, so your system intuitively maps to your model. 21 Ioannis Gallikas MSc
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] Create Network Models Choose Statistics
Run Simulations View Analyze Results
Figure 1. Steps to build a network in OPNET Modeller [2]
22
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. 23 Ioannis Gallikas MSc
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 projects network. [2]
24
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
25
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:
26
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 subnets 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]
Topology: Object Palette View: Go to parent Subnetwork View: Zoom in Results: Hide/or Show all panels Results: View Results
Topology: Verify Links
Results: View Web Reports Topology: Mark object as failed Topology: Mark object as recovered Simulation: Run Simulation
View: Zoom out 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:
27
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 FSMs 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 nodes 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. 28 Ioannis Gallikas MSc
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 endusers, 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.
29
The industrys 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 industrys most efficient simulation engine, with hybrid simulation capability. Outstanding support and services to ensure user success. [4]
30
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
31
GUNET consists of sixteen Universities in total. Table 1 below displays the Universities and their location in Greece. Greek Universities Agricultural University Pantion University Harokopio University University of Pireus National Metsovio University National Kapodistriako University University of Economics University of Good Arts Aristotelio University Macedonia University University of Patra University of Crete Ioannina University University of Thessaly University of Thrace Aegean University Location Athens Athens Athens Athens Athens Athens Athens Athens Thessaloniki Thessaloniki Patra Heraklio Ioannina Larissa Xanthi 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.
32
Picture 2 GUNET Network
Table 2 below displays the capacity of the Backbone Network links between the University Routers. From Location Athens Athens Athens Athens Athens Athens Athens To Location Thessaloniki Patra Heraklio Rhodes Larissa Ioannina Xanthi Capacity (Mbps) 69 Mbps 45 Mbps 60 Mbps 1000 Mbps 18 Mbps 4.5 Mbps 6 Mbps
Table 2 Capacity of the GUNET Backbone Network between the University Routers
33
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 Athens Athens Athens Athens Athens Athens Athens Athens Thessaloniki Thessaloniki Patra Heraklio Ioannina Larissa Xanthi Rhodes To University Agricultural University Pantion University Harokopio University University of Pireus National Metsovio University National Kapodistriako University University of Economics University of Good Arts Aristotelio University Macedonia University University of Patra University of Crete Ioannina University University of Thessaly University of Thrace Aegean University
Table 3 Capacity of the links Between Universities and City Router
Capacity (Mbps) 1000 Mbps 1000 Mbps 2 Mbps 1000 Mbps 1000 Mbps 1000 Mbps 1000 Mbps 2 Mbps 34 Mbps 18 Mbps 34 Mbps 28 Mbps 24 Mbps 8 Mbps 21 Mbps 1000 Mbps
34
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 OPNETs 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. 35 Ioannis Gallikas MSc
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.
36
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 Universitys 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.
37
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.
38
Network Traffic Control 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.
39
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: Product: Device Class: Configuration: Cisco Systems CISCO 12016 Gigabit Switch Router 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) 3. 2-port Packet over SONET (PoS) OC12 interfaces (PPP over SONET)(622.08Mbps) 4. 2-port Packet over SONET (PoS) OC48 interfaces (PPP over SONET)(2.48832Gbps) 5. 8-port ATM OC3 (155.52Mbps) 6. 2-port ATM OC12 (622.08Mbps) 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 40 Ioannis Gallikas MSc
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 0 1 2 3 4 5 6 7 8
Interface 0-3 4-7 8 9 10-17 18 19 20 21-32
Technology 4 atmOC3 4 atmOC3 1 atmOC12 1 atmOC12 8 eth100T 1 eth1000T 1 eth1000T 1 eth1000T 12 SLIP DS3 41 Ioannis Gallikas MSc
Network Traffic Control 9 10 11 12 13 14 33-36 37-40 41 42 43 44 4 SLIP OC3 4 SLIP OC3 1 SLIP OC12 1 SLIP OC12 1 SLIP OC48 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: Vendor: Product: Device Class: Configuration: Cisco Systems CISCO 12008 Gigabit Switch Router This model represents a specific configuration of an IP-based router switch model.
Interconnections: 1. 4-port Packet over SONET (PoS) OC3 interfaces (PPP over SONET)(155.52Mbps) 42 Ioannis Gallikas MSc
2. 4-port Packet over SONET (PoS) OC12 interfaces (PPP over SONET)(622.08Mbps) 3. 1-port Packet over SONET (PoS) OC48 interfaces (PPP over SONET)(2.48832Gbps) 4. 4-port ATM OC3 (155.52Mbps). 5. 1-port ATM OC12 (622.08Mbps) 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)
43
Network Traffic Control Slot 0 1 2 3 4 5 6 Interface 0-3 4 5-12 13 14-17 18-21 22 Technology 4 atmOC3 1 atmOC12 8 eth100T 1 eth1000T 4 SLIP OC3 4 SLIP OC12 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: Vendor: Product: Device Class: Configuration: Cisco Systems CISCO7204 Router This model was created using the device creator utility and contains the following technologies:
44
Network Traffic Control Technology ATM Ethernet FDDI Token Ring Slip IF/Port Count 2 8 4 4 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)
45
Network Traffic Control 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
46
Network Traffic Control 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 47 Ioannis Gallikas MSc
Network Traffic Control 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
48
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. 49 Ioannis Gallikas MSc
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.
50
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
51
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
52
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
53
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
54
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
55
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
56
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
57
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
58
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.
59
Picture 20 Profile Config Attributes
Picture 21 Profile Configuration Table
60
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 wouldnt 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
61
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.
62
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
63
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.
64
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.
65
Picture 28 LAN_1 Actual Name Table
66
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
67
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
68
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
69
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. 70 Ioannis Gallikas MSc
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
71
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 couldnt 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.
72
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.
73
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.
74
Network Traffic Control Links between Routers Athens - Thessaloniki Athens -Patra Athens - Heraklio Athens - Rhodes Thessaloniki - Xanthi Thessaloniki - Larissa Patra - Ioannina Data carried in (bits/sec) 34.100.000 (bits/sec) 29.700.000 (bits/sec) 29.800.000 (bits/sec) 14.600.000 (bits/sec) 2.321,2 (bits/sec) 8.896 (bits/sec) 1.112,2 (bits/sec)
Portsmouth University Data carried out (bits/sec) 37.600.000 (bits/sec) 29.500.000 (bits/sec) 46.500.000 (bits/sec) 16.700.000 (bits/sec) 2589,1 (bits/sec) 7.683,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 Thessaloniki Router to Aristotelio University Thessaloniki Router to Macedonia University Patra Router to Patra University
Table 5 Background Utilization between City Router and University Router
Data carried in (bits/sec) 19.600.000 (bits/sec) 6.335,1 (bits/sec) 22.400.000 (bits/sec)
Data carried out (bits/sec) 23.700.000 (bits/sec) 5.570,1 (bits/sec) 22.500.000 (bits/sec)
75
Network Traffic Control City Router to University Router Xanthi Router to Thrace University Larissa Router to Thessaly University Ioannina Router to Ioannina University Heraklio Router to Creta University 16.900.000 (bits/sec) 1.112,2 (bits/sec) 8.896 (bits/sec) Data carried in (bits/sec) 2.321,2 (bits/sec)
Portsmouth University Data carried out (bits/sec) 2589,1 (bits/sec) 7.683,2 (bits/sec) 1.395,6 (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 couldnt 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 Athens Router to Acropolis Router Athens Router to Ilissos Router Acropolis Router to Ilissos Router
Table 7 Background Utilization between Athens Routers
Data carried in (bits/sec) 8.863,4 (bits/sec) 96.500.000 (bits/sec) 4.944 (bits/sec)
Data carried out (bits/sec) 20.500.000 (bits/sec) 375.900.000 (bits/sec) 4.920 (bits/sec)
76
City Router to Router Athens City Router to Athens Router
Data carried in (bits/sec) 85.000.000 (bits/sec)
Data carried out (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 Athens - Thessaloniki Athens -Patra Thessaloniki - Xanthi Thessaloniki - Larissa Patra - Ioannina Initial Capacity (Mbps) 69 (Mbps) 45 (Mbps) 6 (Mbps) 18 (Mbps) 4.5 (Mbps) Upgraded Capacity (Mbps) 100 (Mbps) 60 (Mbps) 12 (Mbps) 12 (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.
77
Links between City Router and University Router Thessaloniki Router to Aristotelio University Router Thessaloniki Router to Macedonia University Router Xanthi Router to Thrace University Router Larissa Router to Thessaly University Router Patra Router to Patra University Router Ioannina Router to Ioannina University Router Athens Acropolis Router to Harokopio University Athens Ilissos Router to University of Good Arts
Initial Capacity (Mbps) 34 (Mbps) 18 (Mbps) 21 (Mbps) 8 (Mbps) 34 (Mbps) 22 (Mbps) 2 (Mbps) 2 (Mbps)
Upgraded Capacity (Mbps) 60 (Mbps) 22 (Mbps) 22 (Mbps) 22 (Mbps) 60 (Mbps) 22 (Mbps) 1000 (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 78 Ioannis Gallikas MSc
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.
79
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
80
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.
81
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.
82
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:
83
Network Traffic Control Project Name GUNET 1 Lower Links GUNET 2 Lower Links GUNET 3 Lower Links GUNET 4 Lower Links GUNET 5 Lower Links GUNET 6 Lower Links GUNET 7 Lower Links
Portsmouth University Queuing Technique FIFO WFQ Priority Queuing Custom Queuing MWRR DWRR MDRR
By changing the Type of Service from ToS to DSCP (252) which is the highest priority settings and running a simulation, there wasnt 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 84 Ioannis Gallikas MSc
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.
85
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
86
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.
87
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.
88
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.
89

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.
90
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.
91
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.
92

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 didnt 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.
93
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.
94
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.
95

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.
96
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.
97
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.
98

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.
99
100
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 doesnt 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.
101
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 wasnt 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.
102
7.2. FUTURE IMPROVEMENTS

Unfortunately due to the many problems and limitations observed during the period of the project, time didnt 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.
103
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 8) http://www.informit.com/articles/article.asp?p=26125&seqNum=6 104 Ioannis Gallikas MSc
Network Traffic Control 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 19) http://docs.sun.com/db/doc/816-4094/6mab39ut0?a=view 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 26) http://www.sciencedaily.com/encyclopedia/differentiated_services 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 105 Ioannis Gallikas MSc
35) http://www.cisco.com/warp/public/732/Tech/qos/ 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
106
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 8) http://www.informit.com/articles/article.asp?p=26125&seqNum=6 104 Ioannis Gallikas MSc
Network Traffic Control 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 19) http://docs.sun.com/db/doc/816-4094/6mab39ut0?a=view 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 26) http://www.sciencedaily.com/encyclopedia/differentiated_services 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 105 Ioannis Gallikas MSc
35) http://www.cisco.com/warp/public/732/Tech/qos/ 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
106

Network Traffic Control

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Network Traffic Control

Încărcat de

Drepturi de autor:

Formate disponibile

Department of Computer & Electronic Engineering