NCTUNS - 國立金門大學

Report
NCTUNS網路模擬器操作與
模擬程式開發
柯志亨
國立金門大學資訊工程學系 副教授
[email protected]
http://csie.nqu.edu.tw/smallko
大綱
•
•
•
•
1. NCTUNS簡介與GUI操作
2. LAN & WLAN
3. Emulation
4. How to insert a new module into NCTUNS?
http://csie.nqu.edu.tw/smallko/nctuns/sfifo.htm
• 5. How to Get/Set a variable at the run-time?
http://csie.nqu.edu.tw/smallko/nctuns/run_time.htm
• 6. How to write a simple MAC for wireless network?
http://csie.nqu.edu.tw/smallko/nctuns/simple-mac.htm
• 7. How to write a flooding module for wireless simulations?
http://csie.nqu.edu.tw/smallko/nctuns/flooding.htm
1. NCTUNS簡介與GUI操作





Simulates and emulates network protocols
Open source
Modified Linux kernel
GUI and shell commands
Client-server model to allow communication between
simulation/emulation engine and interface
 Uses native Linux TCP/IP stack
 Interacts with real devices in virtual networks
 Allows experiments with real applications
 There is no need to change the real applications
 Allows remote simulations and concurrent simulations
 Easy to create simulation servers
 Can take advantage of multiple cores/processors
Features (1)
 Support to several protocols is already included:
 IEEE 802.3, IEEE 802.11, IEEE 802.16, Learning bridge
protocol, Spanning tree protocol, ...
 IP, Mobile IP, RIP, OSPF, OBS, GPRS, ...
 TCP, UDP, SDP, ...
 HTTP, FTP, telnet, ... (+ any real application)
 Some specific applications included:
 stcp/rtcp - Greedy TCP traffic
 ttcp - Greedy TCP/UDP trafic
 stg/rtg - Greedy TCP/UDP traffic, trace driven, self-similar traffic,
on-off, constant-bit-rate, and various packet streams.
4
Features (2)
 Support to several links and devices is already
included
PPP link, ethernet link, ...
Host, hub, switch, router, ...
QoS Diffserv boundary/interior routers
Optical burst/circuit switch
External host, external router (emulation)
5
Features (3)
 Creates virtual interfaces to simulate the devices of the
scenario
Inspiration from loopback interface
Utilizes IP address 1.0.0.0
During the simulation it is possible to “see” the interfaces
with the commands /sbin/ifconfig or /sbin/route
Interfaces named tun0, tun1, tun2, ...
6
Features (4)
 Kernel re-entering methodology
7
Utilization (1)
 Basic components (binaries)
nctunsclient – GUI interface between user and system
nctuns – shell interface between user and system
nctunsse – NCTUns core
dispatcher – Manage the simulation requests. Can
control multiple coordinators running in different
machines
coordinator – Receives the simulation from the
dispatcher and forward it to the nctunsse
10
Utilization (2)

Each simulation server = kernel modifications +
nctunsse + protocol modules + coordinator
11
Utilization (3)
Folders organization
tools = executable programs of various
applications and tools pre-installed
(/usr/local/nctuns/tools)
bin = executable programs of the GUI
program, dispatcher, coordinator, and the
simulation engine (/usr/local/nctuns/bin)
etc = configuration files needed by the
dispatcher and coordinator programs
(/usr/local/nctuns/etc)
BMP = icon bmp files uses by the GUI
program (/usr/local/nctuns/BMP)
lib = libraries used by the simulation engine
13
Utilization (4)
Execution order
dispatcher
Waits client connection via TCP port
9800
Waits coordinator connection via TCP
port 9810
coordinator
Connects to dispatcher
nctunsclient or nctuns
Connects to dispatcher to send the
scenario and waits the end of the
simulation. The nctunsse is started by
the coordinator
14
Utilization (5)
How to use the GUI?
15
Utilization (6)
Draw topology
NCTUns - Professor Nelson Fonseca
16
Utilization (7)
17
Utilization (8)
Edit property
18
Utilization (9)
19
Utilization (10)
Run simulation
20
Utilization (11)
21
Utilization (12)
22
Utilization (13)
Playback
23
Utilization (14)
24
Utilization (15)
25
Utilization (16)
26
Utilization (17)
Main simulation files
.emu: external routing table (needed to
emulation)
.ndt: nodes identification
.tfc: list of commands to be executed
.srt-l: internal routing table (tun[0-9]*
devices)
.tcl: scenario details
One example of each file is available at
http://www.lrc.ic.unicamp.br/~daniel/trento/nctuns/
See p54~p70 in DeveloperManual.pdf
NCTUns - Professor Nelson Fonseca
27
Utilization (18)
To run without the GUI
Create the basic scenario from the GUI (It is
easier)
Make the necessary changes in the files
Run nctuns <file.tcl>
<file.tcl> is generated by the GUI
Wait for the results
28
Examples (1)
Scenario 1
Network topology: 2 hosts connected by an
ethernet link
Protocols: TCP and UDP
Applications: rtcp/stcp
Devices:
29
Examples (2)
Scenario 1 – Applications configuration
To simulate data transfer between host 1
(1.0.1.1) and hosts 2 (1.0.1.2) via TCP using
stcp and rtcp
Host 1: stcp -p 8000 1.0.1.2
Sending TCP segments to 1.0.1.2 at
port 8000
Host 2: rtcp -p 8000
Receiving TCP segments from port
8000
30
Examples (3)
31
Examples (4)
Scenario 2
To simulate data transfer between host 1
(1.0.1.1) and host 2 (1.0.1.2) via UDP using stg
and rtg
Host 1: stg -u 1000 50 -m 50 50 -p 8000
1.0.1.2
Sending UDP datagrams to 1.0.1.2 at
port 8000. Transmission rate limited to
50Mbps and packet size equal to 1000
bytes.
Host 2: rtg -u -p 8000
Receiving UDP datagrams from port
8000
32
2. LAN & WLAN
•
•
•
•
Basic performance evaluation
Routing (Static routing vs. Dynamic routing)
Performance Anomaly Problem
Performance evaluation of ad hoc routing
protocols
• Performance evaluation of IEEE 802.11b
wireless networks
Basic performance evaluation
• Tools
– Wireshark (封包觀測)
• yum install wireshark*
– Gnuplot (繪圖)
• yum install gnuplot
• Throughput Measurement (Application and
MAC Level)
封包觀測
hub
udp_c 1.0.1.3
udp_s
Example: hub
tcpdump –i eth1 –U –w mylog
wireshark mylog
client  server
server->client
Example: switch
Application level
switch
3~30s: ttcp –t –s –p 1234 1.0.1.4
5~30s: ttcp –t –s –p 4321 1.0.1.3
0~30s: ttcp –r –s – p 1234 –w thr_n2n5
0~30s: ttcp –r –s –p 4321 –w thr_n3n4
MAC level
At Node 4 Throughput: Application level vs. MAC level
Dynamic routing vs. Static Routing
Bandwidth=10Mbps
Link down = 5 ~ 25 sec
(from R3 to R4)
Run time:1~100 seconds
stcp 1.0.2.1
rtcp
Example: routing_wired
How to manually set the routing tables
in wired simulation ?
1.0.3.2
1.0.4.1
1.0.3.1
1.0.4.2
1.0.5.1
1.0.2.1
1.0.2.2
1.0.5.2
1.0.6.1
1.0.1.1
rtcp
1.0.1.2
stcp 1.0.6.2
Example: routing_wired_static
1.0.6.2
*.srt-l
1.0.3.2
1.0.4.1
1.0.3.1
1.0.4.2
1.0.5.1
1.0.2.1
1.0.2.2
1.0.5.2
1.0.6.1
1.0.1.1
rtcp
1.0.1.2
stcp 1.0.6.2
1.0.6.2
1.0.3.2
1.0.4.1
1.0.4.2
1.0.3.1
1.0.2.1
1.0.1.2
1.0.5.1
1.0.2.1
1.0.2.2
1.0.5.2
1.0.6.1
1.0.6.2
How to manually set the routes in the wireless simulations?
$node_(NID) + entry-changing time + "set-next-hop" + SrcNode + DstNode + NextHop + "chan" + channel
無線網路異常問題 (Performance Anomaly Problem) 1
• 在IEEE的標準裡802.11a/b/g分別利用不同的編碼方
式可支援多種不同的傳輸速度,802.11b提供了四種
傳輸速度,(1M/2M/5.5M/11M),802.11a則提供多達
八種傳輸速度。
• 較低的傳輸速度對於訊號的抗干擾性較強,反之較
高的傳輸速度則較弱。當訊號不良的時候選擇低速
的傳輸速度,當訊號收訊良好時則選擇高速的傳輸。
所以在一個無線區域網路中,可能同時存在具有不
同傳輸速率的行動節點,我們通常稱這樣這網路為
多速率網路環境(multi-rate wireless network)。
無線網路異常問題 (Performance Anomaly Problem) 2
• 假設所有無線網路所有傳輸的封包大小都是相同
的,在此假設下,當低速節點得到通道存取機會
時,需要較久的時間才能把封包傳送完畢;另外,
若是高速節點和低速節點發生傳輸碰撞,則高速
節點還是需要等待低速節點把整個封包傳送過程
完成後,才能重新競爭通到存取機會。以上兩個
情況是主要造成整個無線網路效能變差的原因。
Performance Anomaly Problem
在group wireless nodes時,第一個一定要先選AP
stg -u 1024 10 1.0.1.1
10~20sec
11M
11M
stg -u 1024 29 1.0.1.2
1~30sec
Example: anomaly
stg -u 1024 10 1.0.1.1
10~20sec
1M
11M
stg -u 1024 29 1.0.1.2
1~30sec
Change link bandwidth from 11 to 1
1
4
3
2
Increase the cwmin value of the 1Mbps node
to lower the contending probability
a. Press the R
b. Edit the *.tcl file to increase the cwmin value
c. Run
Limit the packet length of the 1Mpbs node
Performance evaluation of ad hoc
routing protocols
Compare DSDV, AODV, DSR routing protocols under static or dynamic situations
The nodes are all fixed.
Example : wrouting
比較DSDV, AODV, DSR
Random Number要設定相同的數值,但不能為0
The nodes are randomly moving.
Example : wrouting2
Performance evaluation of IEEE
802.11b wireless networks
• packet size vs. throughput
– with/without wireless transmission error
Example: wperformance
without wireless transmission error
Application data:500 bytes
Kbytes/sec
Application data:1000 bytes
Kbytes/sec
Application data:2000 bytes
Kbytes/sec
??? Why ???
Packets are fragmented into
small packets and need to
contend more times for
transmission.
Packet size
Overhead
Throughput
Application data:2000 bytes
Kbytes/sec
With transmission error
Application data:500 bytes
Kbytes/sec
Set the bit error rate to 0.0001
With transmission error,
Packet size
throughput
Application data:1000 bytes
Kbytes/sec
How to design a mechanism that can adjust the packet size under different wireless
transmission error rates is important !!!
4. Emulation
Example: emu
192.168.0.179
Simulated Host
External Host
192.168.0.196
How to insert a new module into
NCTUNS?
[Background]
1. This is a simplified version of First In First Out (Drop Tail) Queue. The codes were
mainly re-written from original FIFO.cc/FIFO.h.
2. Please refer to DeveloperManual.pdf which is under /root/ NCTUns6.0/doc/Developer.Manual folder. Take a closer look at the chapter 2 and chapter 5.
[Preparation]
1. Change the path to /root/NCTUns-6.0/src/nctuns/module/ps
2. Create a new folder named sFIFO.
3. Prepare 3 files under sFIFO.
PACKET RECEPTION
PACKET TRANSMISSION
THE RELATIONSHIP BETWEEN PUT(), GET() AND SEND().
THE RELATIONSHIP BETWEEN PUT(), GET() AND RECV().
#ifndef __NCTUNS_sfifo_h__
#define __NCTUNS_sfifo_h__
sfifo.h
#include <object.h>
#include <pcket.h>
#include <timer.h>
/* Define Interface Queue for every Interface */
struct ifqueue {
ePacket_
*ifq_head; /* head of ifq */
ePacket_
*ifq_tail; /* tail of ifq */
int
ifq_len; /* current queue length */
int
ifq_maxlen;/* max queue length */
int
ifq_drops; /* drops count */
};
#define IF_PREPEND(ifq, m) { \
(m)->next_ep = (ifq)->ifq_head; \
if ((ifq)->ifq_tail == 0) \
(ifq)->ifq_tail = (m); \
(ifq)->ifq_head = (m); \
(ifq)->ifq_len++; \
}
#define IF_DEQUEUE(ifq, m) { \
(m) = (ifq)->ifq_head; \
if (m) { \
if (((ifq)->ifq_head = (m)->next_ep) == 0) \
(ifq)->ifq_tail = 0; \
(m)->next_ep = 0; \
(ifq)->ifq_len--; \
}\
}
/* Define Macros for IFq */
#define IF_QFULL(ifq)
((ifq)->ifq_len >= (ifq)->ifq_maxlen)
#define IF_DROP(ifq)
((ifq)->ifq_drops++)
#define IF_ENQUEUE(ifq, m) { \
if ((ifq)->ifq_tail == 0) \
(ifq)->ifq_head = m; \
else \
(ifq)->ifq_tail->next_ep = m; \
(ifq)->ifq_tail = m; \
(ifq)->ifq_len++; \
}
class sfifo : public NslObject {
private:
struct ifqueue
protected:
int
if_snd; /* output interface queue */
intrq(MBinder *);
public:
sfifo(u_int32_t type, u_int32_t id, struct plist* pl, const char *name);
~sfifo();
int
int
int
init();
recv(ePacket_ *);
send(ePacket_ *);
};
#endif /* __NCTUNS_sfifo_h__ */
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <nctuns_api.h>
#include <ps/sFIFO/sfifo.h>
#include <exportStr.h>
#include <mbinder.h>
sfifo.cc
/* initialize interface queue */
if_snd.ifq_head = if_snd.ifq_tail = 0;
if_snd.ifq_len = 0;
if_snd.ifq_drops = 0;
/* bind variable */
vBind("max_qlen", &if_snd.ifq_maxlen);
if_snd.ifq_maxlen = 50; /* by default */
}
MODULE_GENERATOR(sfifo);
sfifo::sfifo(u_int32_t type, u_int32_t id, struct plist* pl, const char *name)
sfifo::~sfifo() {
: NslObject(type, id, pl, name)
{
}
/* disable flow control */
int sfifo::init() {
s_flowctl = DISABLED;
r_flowctl = DISABLED;
int
(NslObject::*upcall)(MBinder *);
/* set upcall */
upcall = (int (NslObject::*)(MBinder *))&sfifo::intrq;
sendtarget_->set_upcall(this, upcall);
return(1);
}
int sfifo::send(ePacket_ *pkt) {
assert(pkt&&pkt->DataInfo_);
/*
* If Module-Binder Queue(MBQ) is full, we should
* insert the outgoing packet into the interface
* queue. If MBQ is not full, we can call the
* put() or NslObject::send() method to pass the
* outgoing packet to next module.
*/
if( sendtarget_->qfull() ) {
/* MBQ is full, insert to ifq */
if (IF_QFULL(&if_snd)) {
/* ifq full, drop it! */
IF_DROP(&if_snd);
else {
freePacket(pkt);
return(1);
}
/* otherwise, ifq not full, insert it */
IF_ENQUEUE(&if_snd, pkt);
return(1);
}
}
}
/*
* MBQ is not full, pass outgoing packet
* to next module.
*/
return(NslObject::send(pkt));
int sfifo::recv(ePacket_ *pkt) {
int sfifo::intrq(MBinder *port) {
/* Just by pass incoming packet */
assert(pkt&&pkt->DataInfo_);
return(NslObject::recv(pkt));
ePacket_ *pkt;
/*
* Push the packet in the interface queue
* to the MBQ. Whenever the pakcet in the
* MBQ is sent, the scheduler will call this
* member function to give sfifo module a
* chance to send the next packet in the
* interface queue.
*/
IF_DEQUEUE(&if_snd, pkt);
}
if (pkt != NULL) {
/*
* If still exist packet in the interface
* queue, we try to push it to the MBQ,
*/
assert(sendtarget_->enqueue(pkt) == 0);
}
return(1);
Makefile
#
# Makefile for the NCTUns engine module
#
obj-y
= sfifo.o
}
Change path to /root/NCTUns-6.0/src/nctuns and edit the nctuns.cc
Recompile the nctuns
方法一
(change FIFO to sFIFO and remove some redundant functions)
方法二
記得要關閉nctunsclient,再重新開啟才會生效
How to Get/Set a variable at the runtime?
[Background]
Refer to the section 2.1.3 in the DeveloperManual.pdf for advanced information. But in that document,
it teaches you to use “EXPORT” function to register the variables that you are interested in. And then modify
the module description file in order to get/set a variable at the run-time. Take the following scenario as an
example. Node 2 is using stg program to send packets to Node 3. If we are interested in the current queue
length in the Node 2, we have to do the following procedures: “Simulation/Run”->Node 2->
Node editor->FIFO->GET (Current Queue Length) in the Run Time Query group. It takes time and many
procedures to achieve what we want. Therefore, I will introduce another method. With this method, you can
get/set the information at the time exactly at any time you want during simulation.
How to write a flooding module for
wireless simulations?
How to write a simple MAC for
wireless network?
MYMAC_SIMPLE

similar documents