首页 ANT WEEK1-2

ANT WEEK1-2

举报
开通vip

ANT WEEK1-2 Advanced Network Technologies Practical Laboratories. Introduction The purpose of this laboratory is to provide an introduction Network Design and Simulation using Network Simulator (NS) version 2 by methods of creating, editing, and manipulating ...

ANT WEEK1-2
Advanced Network Technologies Practical Laboratories. Introduction The purpose of this laboratory is to provide an introduction Network Design and Simulation using Network Simulator (NS) version 2 by methods of creating, editing, and manipulating objects, included in this tool. Also, aspects concerning the running of a simulation, the reports and the statistics that may be obtained from running a network simulation will be covered. This laboratory sheet is comprised of three sections; (i) background on NSv2, (ii) introductory exercises, and (iii) a more complete set of exercises. You are advised to read all sections before arriving at the laboratory, as you will find time will be limited. You will also need to bring a 3.5” disk with you to the lab to save your work. Section A : Network Simulator: The Basics There is increasing dependence on computing and communication networks in the day-to-day operation of all types of organizations. As these networks become larger and more complex their design and management becomes an ever more challenging task. Network simulation provides a means of testing proposed changes prior to placing them into effect, performing what-if analysis concerning the reliability of key components in a network and the effects of losing a component, planning for future growth, and initial design of a proposed network. The costs associated with the building and operating of a network make simulation a viable option in making choices in the building, modification, and performance analysis of a network. NS (version 2) is an object-oriented, discrete event driven network simulator developed at UC Berkely written in C++ and Otcl, that simulates a variety of IP networks. NS is primarily useful for simulating local and wide area networks IP networks. It implements network protocols such as TCP and UDP, traffic source behaviour such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms such as Dijkstra, and more. NS also implements multicasting and some of the MAC layer protocols for LAN simulations. As shown in figure 1, in a simplified user's view, NS is Object-oriented Tcl (OTcl) script interpreter that has a simulation event scheduler and network component object libraries, and network setup module libraries. In other words, to use NS, you program in OTcl script language. To setup and run a simulation network, a user should write an OTcl script that initiates an event scheduler, sets up the network topology using the network objects and the functions in the library, and tells traffic sources when to start and stop transmitting packets through the event scheduler. Figure 1: User interface simplified view NS is written not only in OTcl but in C++ also (figure 2). For efficiency reason, NS separates the data path implementation from control path implementations. In order to reduce packet and event processing time (not simulation time), the event scheduler and the basic network component objects in the data path are written and compiled using C++. These compiled objects are made available to the OTcl interpreter through an OTcl linkage, that creates a matching OTcl object for each of the C++ objects and makes the control functions and the configurable variables specified, by the C++ object act as member functions and member variables of the corresponding OTcl object. In this way, the controls of the C++ objects are given to OTcl. It is also possible to add member functions and variables to a C++ linked OTcl object. Figure 2: C++ and OTcl duality Figure 3 shows the general architecture of NS. In this figure a general user (not an NS developer) can be thought of standing at the left bottom corner, designing and running simulations in Tcl using the simulator objects in the OTcl library. The event schedulers and most of the network components are implemented in C++ and available to OTcl through an OTcl linkage that is implemented using tclcl. The whole system together is the NS, which is an extended Tcl interpreter with network simulator libraries. Figure 3: Architectural view of NS Section A, briefly examined the general structure and architecture of NS. At this point, one might be wondering about how to obtain NS simulation results. As shown in Figure 1, when a simulation is finished, NS produces one or more text-based output files that contain detailed simulation data, if specified to do so in the input Tcl (or more specifically, OTcl) script. The data can be used for simulation analysis (two simulation result analysis examples are presented in later sections) or as an input to a graphical simulation display tool called Network Animator (NAM) that is developed as a part of VINT project. NAM has a nice graphical user interface similar to that of a CD player (play, fast forward, rewind, pause and so on), and also has a display speed controller. Furthermore, it can graphically present information such as throughput and number of packet drops at each link, although the graphical information cannot be used for accurate simulation analysis. Starting NS Start NS typing the command 'ns ', in the system console (open this console clicking in the “screen” icon at the left top of your desktop), where '' is the name of a Tcl script file which defines the simulation scenario (i.e. the topology and the events). Everything else depends on the Tcl script. Starting NAM Start NAM, with the command 'nam ' , where '' is the name of a NAM trace file that was generated by NS; NAM can be executed directly out of the Tcl script for the simulation that you want to visualize. Figure 4 illustrates a screenshot GUI of a NAM window where the most important functions are explained. Figure 4: Network Animator GUI Section B : Introductory exercises. How to begin. Login with the user and password assigned by the demonstrator. Open the xterm, clicking in the terminal icon. First you must type a text file, with the tcl/otcl code that makes the simulation. The basic code will be explained in the following exercises. A „template‟ is needed so that it can be used for all Tcl scripts. The scripts can be edited within any editor. Type the following code. Save this code using the 'template.tcl'. Note: The code to be written in your file (TCL script) is presented here in courier new font. set ns [new Simulator] set nf [open out.nam w] $ns namtrace-all $nf proc finish {} { global ns nf $ns flush-trace close $nf exec nam out.nam & exit 0 } $ns at 5.0 "finish" $ns run This code is the template you will use in the following examples. The first line creates the simulator object, and assigns to it the handle ns. Second line opens the file out.nam for writing and gives it the file handle 'nf'. Next line tells the simulator object to write all simulation data that is going to be relevant for nam into this file. The next step is to add a 'finish' procedure that closes the trace file and starts nam. Exercise 1. Two nodes, one link First step. A very simple topology is defined with two nodes that are connected by a link. The following two lines define the two nodes. (Note: Insert the code in this section before the line '$ns at 5.0 "finish" in template.tcl file). set n0 [$ns node] set n1 [$ns node] A new node object is created with the command '$ns node'. The above code creates two nodes and assigns them to the handles 'n0' and 'n1'. The next line connects the two nodes. $ns duplex-link $n0 $n1 1Mb 10ms DropTail This line tells the simulator object to connect the nodes n0 and n1 with a duplex link with the bandwidth 1Megabit, a delay of 10ms and a DropTail queue. The next step is to send some data from node n0 to node n1. In ns, data is always being sent from one 'agent' to another. So the next step is to create an agent object that sends data from node n0, and another agent object that receives the data on node n1. #Create a UDP agent and attach it to node n0 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 # Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 $cbr0 attach-agent $udp0 These lines create a UDP agent and attach it to the node n0, then attach a CBR traffic generatoro to the UDP agent. CBR stands for 'constant bit rate'.. The packetSize is being set to 500 bytes and a packet will be sent every 0.005 seconds (i.e. 200 packets per second). The next lines create a Null agent which acts as traffic sink and attach it to node n1. set null0 [new Agent/Null] $ns attach-agent $n1 $null0 Now the two agents have to be connected with each other. $ns connect $udp0 $null0 And now we have to tell the CBR agent when to send data and when to stop sending. Note: It's probably best to put the following lines just before the line '$ns at 5.0 "finish"'. $ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop" Save your script with the name: example1.tcl. To run the simulation type ns example1.tcl at the command line; the file out.nam is the result obtained. A nam window will appear and you should see an output that resembles the picture below. Remember that namprogram is called from the script in the finish procedure. When you click on the 'play' button in the nam window, you will see that after 0.5 simulation seconds, node 0 starts sending data packets to node 1. You might want to slow nam down then with the 'Step' slider. Start some experiments with nam and the Tcl script. You can click on any packet in the nam window to monitor it. Try to change the 'packetsize_' and 'interval_' parameters in the Tcl script to see what happens. The full example is this: #Create a simulator object set ns [new Simulator] #Open the nam trace file set nf [open out.nam w] $ns namtrace-all $nf #Define a 'finish' procedure proc finish {} { global ns nf $ns flush-trace #Close the trace file close $nf exit 0 } #Create two nodes set n0 [$ns node] set n1 [$ns node] #Create a duplex link between the nodes $ns duplex-link $n0 $n1 1Mb 10ms DropTail #Create a UDP agent and attach it to node n0 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 # Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 $cbr0 attach-agent $udp0 #Create a Null agent (a traffic sink) and attach it to node n1 set null0 [new Agent/Null] $ns attach-agent $n1 $null0 #Connect the traffic source with the traffic sink $ns connect $udp0 $null0 #Schedule events for the CBR agent $ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop" #Call the finish procedure after 5 seconds of simulation time $ns at 5.0 "finish" #Run the simulation $ns run Exercise 2. Two senders, one router, one destination. A topology with four nodes in which one node acts as router that forwards the data that two nodes are sending to the fourth node, is presented; also a way to distinguish the data flows from the two nodes from each other, how a queue can be monitored to see how full it is, and how many packets are being discarded, will be shown. The topology. As always, the first step is to define the topology. You should create a file 'example2.tcl', using the template code from the previous section. This code will always be similar. You will always have to create a simulator object, you will always have to start the simulation with the same command, and you will always have to open a trace file, initialise it, and define a procedure that closes it. Now insert the following lines into the code to create four nodes. set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] The following piece of Tcl code creates three duplex links between the nodes. $ns duplex-link $n0 $n2 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n3 $n2 1Mb 10ms DropTail $ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns duplex-link-op $n2 $n3 orient right The options for the orientation of a link are right, left, up, down and combinations of these orientations. The events The next step is to create two UDP agents with CBR traffic sources and to attach them to the nodes n0 and n1. Then to create a Null agent and to attach it to node n3. #Create a UDP agent and attach it to node n0 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 # Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 $cbr0 attach-agent $udp0 #Create a UDP agent and attach it to node n1 set udp1 [new Agent/UDP] $ns attach-agent $n1 $udp1 # Create a CBR traffic source and attach it to udp1 set cbr1 [new Application/Traffic/CBR] $cbr1 set packetSize_ 500 $cbr1 set interval_ 0.005 $cbr1 attach-agent $udp1 set null0 [new Agent/Null] $ns attach-agent $n3 $null0 The two CBR agents have to be connected to the Null agent. $ns connect $udp0 $null0 $ns connect $udp1 $null0 The first CBR agent to start sending at 0.5 seconds and to stop at 4.5 seconds while the second CBR agent starts at 1.0 seconds and stops at 4.0 seconds. $ns at 0.5 "$cbr0 start" $ns at 1.0 "$cbr1 start" $ns at 4.0 "$cbr1 stop" $ns at 4.5 "$cbr0 stop" Question. When you start the script now with './ns example2.tcl', you will notice that there is more traffic on the links from n0 to n2 and n1 to n2 than the link from n2 to n3 can carry. Now make a simple calculation to find the Bandwidth required for the links from n0 to n2 and from n1 to n2; then find the total Bandwidth required for the link between n2 and n3. (Calculate the rate in Bits per second transmitted by each source). This link only has a capacity of 1Mb/s, so obviously some packets are being discarded. But which ones? Both flows are black, so the only way to find out what is happening to the packets is to monitor them in nam by clicking on them, what information is displayed when this clicking is done? Marking flows Add the following two lines to your CBR agent definitions. $udp0 set class_ 1 $udp1 set class_ 2 Now add the following piece of code to your Tcl script, preferably at the beginning after the simulator object has been created, since this is a part of the simulator set up. $ns color 1 Blue $ns color 2 Red This code allows you to set different colours for each flow id. Now you start the script and one flow should be blue, while the other one is red. Watch the link from node n2 to n3 for a while, and you will notice that after some time the distribution between blue and red packets isn't too fair anymore (at least that's the way it is on my system). Monitoring a queue You only have to add the following line to your code to monitor the queue for the link from n2 to n3. $ns duplex-link-op $n2 $n3 queuePos 0.5 Start ns again and you will see a picture similar to the one below after a few moments. You can see the packets in the queue now, and after a while you can even see how the packets are being dropped, though (at least on my system, I guess it might be different in later or earlier releases). only blue packets are being dropped. But you can't really expect too much 'fairness' from a simple DropTail queue. So let's try to improve the queuing by using a SFQ (stochastic fair queuing) queue for the link from n2 to n3. Change the link definition for the link between n2 and n3 to the following line. $ns duplex-link $n3 $n2 1Mb 10ms SFQ Question. Is the queuing 'fair' now? Why? The full example is this: #Create a simulator object set ns [new Simulator] $ns color 1 Blue $ns color 2 Red #Open the nam trace file set nf [open out.nam w] $ns namtrace-all $nf #Define a 'finish' procedure proc finish {} { global ns nf $ns flush-trace #Close the trace file close $nf exec nam out.nam & exit 0 } #Create four nodes set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] #Create three duplex link between the nodes $ns duplex-link $n0 $n2 1Mb 10ms DropTail $ns duplex-link $n1 $n2 1Mb 10ms DropTail $ns duplex-link $n3 $n2 1Mb 10ms SFQ $ns duplex-link-op $n2 $n3 queuePos 0.5 $ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns duplex-link-op $n2 $n3 orient right #Create a UDP agent and attach it to node n0 set udp0 [new Agent/UDP] $ns attach-agent $n0 $udp0 # Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR] $cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 $cbr0 attach-agent $udp0 $udp0 set class_ 1 #Create a UDP agent and attach it to node n1 set udp1 [new Agent/UDP] $ns attach-agent $n1 $udp1 # Create a CBR traffic source and attach it to udp1 set cbr1 [new Application/Traffic/CBR] $cbr1 set packetSize_ 500 $cbr1 set interval_ 0.005 $cbr1 attach-agent $udp1 $udp1 set class_ 2 #Create a Null agent (a traffic sink) and attach it to node n3 set null0 [new Agent/Null] $ns attach-agent $n3 $null0 #Connect the traffic source (two CBR agents) with the traffic sink (Null agent) $ns connect $udp0 $null0 $ns connect $udp1 $null0 #Schedule events for the CBRs agents $ns at 0.5 "$cbr0 start" $ns at 1.0 “$cbr1 start” $ns at 4.0 "$cbr1 stop" $ns at 4.5 “$cbr0 stop” #Call the finish procedure after 5 seconds of simulation time $ns at 5.0 "finish" #Run the simulation $ns run Question. Modify and test example2.tcl so that  There is no packet loss  The final link of the graph is full when both nodes are sending packets Note: packets may still queue, but the queue always clears
本文档为【ANT WEEK1-2】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_666100
暂无简介~
格式:pdf
大小:406KB
软件:PDF阅读器
页数:11
分类:互联网
上传时间:2011-10-19
浏览量:18