Purpose


NS(version 2)는 UC Berkely에서 C++과 OTcl로 쓴 object-orient인 이산사건 구동 시뮬레이터로서 LAN과 WAN을 시뮬레이트 하는데 매우 유용하다. NS는 시뮬레이터를 한번 알게되면 비록 쉽지만, 처음으로 사용하는 사람에게는 매우 어렵기 때문에 사용자에게 그리 익숙하지는 않다. 시뮬레이터를 깊이 있게 설명한, 개발자에 의해 쓰여진 Document가 많이 있기는 하지만 그것은 NS에 익숙한 User의 깊이로 쓰여져 있다. 이 project의 목적은 주로 간단한 예와 우리의 경험을 토대로 한 간략한 설명을 곁들여 새로운 User에게 시뮬레이터를 동작하는 방법과 네트워크를 setup하는 방법, 시뮬레이터 code에 있는 Network 구성요소에 대한 진보된 정보를 어디서 찾는가, 또한 새로운 Network 구성요소를 어떻게 만드는가 하는 방법 등을 제공하기 위한 것이다. 비록 이 프로젝트에서 시뮬레이터의 모든 사용 예나, 가능한 네트워크 시뮬레이션 setup이 cover되지 않는다 하더라도, 이 프로젝트는 새로운 사용자에게 보다 빠르게 접근할 수 있도록 해줄 것이다.

http://perform.wpi.edu/NS/index.html

 

1. OverView

NS는 UC Berkeley에서 개발한 Event 구동 네트워크 시뮬레이터로, 다양한 IP 네트워크를 시뮬레이트한다. 그것은 TCP와 UDP와 같은 네트워크 프로토콜, FTP, Telnet, Web, CBR과 VBR 그리고 Drop Tail, RED와 CBQ와 같은 router queue 관리 메카니즘, Dijkstra 등과 같은 routing 알고리즘을 구현한다.

NS는 또한 multicasting과 LAN 시뮬레이션을 위한 MAC layer 프로토콜의 많은 부분을 구현한다. NS 프로젝트는 현재 시뮬레이션 결과를 표시, 분석 및 잘 알려진 생성기에 의해 생성된 네트워크 Topology를 NS format으로 변환하기 위한 VINT Project의 일부분이다. 현재 C++과 OTcl(Tcl script language with Object-oriented extensions developed at MIT)로 쓰여진 NS(version 2)가 유용하다. 이 document는 NS의 기본적인 구조에 대해서 간략하게 이야기하며, 대부분 예를 들어서 NS를 어떻게 사용하는가를 상세히 설명한다. NS 기본 구조를 기술하는데 사용된 대부분의 그림과 네트워크 구성요소들은 5th VINT/NS Simulator Tutorial/Workshop 슬라이드와 필요에 따라 약간 변형한 NS Notes and Document로부터 사용했다. NS와 관련된 Tool에 대한 보다 자세한 정보는 VINT project home page를 방문해 보라.



그림 1. Simplified User's View of NS

 

간단한 User's view에 있는 그림1.에서 NS는 시뮬레이션 event scheduler와 network 구성 object libraries, network setup(plumbing:배관, 설비, 재는 것, 이해하는 것) module libraries(실제, plumbing module는 기본 시뮬레이터 object의 member 함수로 구현된다.)를 갖는 Otcl script 인터프리터이다. 다시 말해서 NS를 사용한다는 것은 OTcl script language안에서 프로그램 한다는 것이다. 시뮬레이션 네트워크를 setup하고 동작시키기 위해서 사용자는 event scheduler를 시작하는 OTcl script를 쓰고, library에 있는 plumbing 함수와 network object를 사용하는 network topology를 setup하며, event scheduler를 통하여 전송되는 패킷을 시작하고 정지할 때 traffic source를 알려줘야 한다. Network를 setup하는 것은 적정한 object의 주소로 object의 포인터를 "neighbor"로 setting 함으로써,Network object 사이에서 가능한 data 경로를 재는 것이기 대문에 "Plumbing"항은 네트워크 setup를 위해서 사용된다.

사용자가 새로운 network object를 만들기 원할 때, 새로운 object를 쓰거나, object library로부터 합성된 object를 만들거나, 또는 object를 통과하는 data를 plumb함으로써 쉽게 object를 만들 수 있다. 이것은 복잡한 일로 보일지 모르나, plumbing OTcl 모듈은 실제적으로 매우 쉽게 job을 만든다. NS의 power는 이 plumbing으로부터 온다. network object외에 NS의 다른 major 구성요소는 event scheduler이다. NS에 있는 event는 schedule된 time을 가진 packet에 대해 유일한, event를 조정하는 object를 가리키는 packet ID이다. NS에서 event scheduler는 시뮬레이션 time의 track을 유지하며, 적당한 network 구성요소(그것은 보통 event를 발생시키는 사람이며, 그들을 event에 의해 지적된 packet과 관련된 적정한 행위를 하도록 한다.)들을 불러냄으로써 현재 시간에 대해 schedule된 event queue에 있는 모든 event들을 자극한다. Network 구성요소들은 다른 passing packet과 통신한다. 그러나, 이것은 실제적인 시뮬레이션 시간을 소모하지는 않는다. packet(지연 필요성 등)을 조정하는 많은 시뮬레이션 time을 소비해야할 필요가 있는 모든 network 구성요소들은 packet에 대한 event를 발행함으로써, packet를 조정하는 나중의 동작을 하기 전에 그 자신을 자극하기 위한 event를 기다림으로써, event scheduler를 사용한다. 예를 들어, 20㎲으로 스위치를 시뮬레이트하는 network 구성요소는 20㎲후의 event로서 schedulerfhf 변환되는 packet에 대한 event를 발행한다. 20㎲후의 scheduler는 event를 dequeue하며, 스위치 구성요소에게 그것을 자극한다. 그때 그것은 적당한 출력링크 구성요소에 packet을 전달한다.

event scheduler의 또 다른 사용은 timer이다. 예를 들어, TCP는 재전송(다른 NS packet ID를 제외한 동일한 TCP packet 번호를 가진 packet의 전송)에 대한 packet 전송 time-out의 track을 유지하기 위한 timer를 필요로 한다. Timer는 delay가 하는 비슷한 방법으로 event scheduler를 사용한다. 오로지 다른 점은 timer는 packet과 관련된 time 값을 측정하며, 어떤 시간이 지나간 후에 그 packet과 관련된 적정한 동작을 하고, delay를 시뮬레이트 하지 않는다는 것이다.

NS는 OTcl 뿐만 아니라 C++로 쓰여졌다. 이러한 능력 때문에, NS는 제어경로 구현으로부터 data 경로 구현을 분리한다. packet와 event 처리 시간(시뮬레이션 시간이 아니고)을 줄이기 위하여, event scheduler와 data 경로에 있는 기본적인 network 구성요소 object는 C++을 사용하여 쓰여지고 compile된다. 이러한 compile된 object는 C++ object의 각각 요소들과 matching되는 OTcl object를 생성하고 제어함수와 member 함수로 동작하는 C++ object에 의해 규정된 구성 가능한 변수, 그리고 일치하는 OTcl object의 member 변수를 만드는 OTcl 링크를 통해 OTcl 인터프리터로 유용하게 만들어진다. 이러한 방법으로 C++ object의 제어가 OTcl로 주어진다. C++ linked OTcl object로 member 함수와 변수들을 추가하는 것은 가능하다. 시뮬레이션에서 제어되거나, 다른 object에 의해 내부적으로 사용될 필요가 없는 C++에 있는 object들은 OTcl에 링크될 필요가 없다. 마찬가지로 object(data 경로에 있지 않은)는 OTcl에서 전적으로 구현될 수 있다. 그림2는 C++과 OTcl에 있는 object hierachy한 예를 보여준다. 그림에서 주목할 만한 하나는 hierarcy를 구성하는 OTcl 링크를 갖는 C++ object에 대한 것이다. 거기에는 C++과 매우 유사하게 matching되는 OTcl object hierachy가 있다.



그림 2. C++ and OTcl: The Duality
 


그림 3. Architectural View of NS

그림3은 NS의 일반적인 구조를 보여준다. 이 그림에서 일반 user(NS 개발자가 아닌)는 OTcl library에 있는 시뮬레이터 object를 사용하는 Tcl에서 시뮬레이션을 설계하고 동작하는 왼쪽 아래 코너에 있는 것으로 생각된다. event scheduler와 대부분의 network 구성요소들은 C++에서 구현되며, tclcl을 사용하여 구현되는 OTcl 링크를 통해 OTcl로 가용된다. NS를 함께 만드는 모든 일들은 network simulator library와 더불어 OO 확장된 Tcl 인터프리터이다.

이 section에서 NS의 일반적인 구성과 구조를 간략하게 설명했다. 이 점에서, 사람들은 NS 시뮬레이션 결과를 어떻게 얻느냐 하는 것에 대해 의문을 가질지 모른다. 그림1.에서 보는바와 같이 시뮬레이션이 끝날 때, NS는 입력 Tcl(보다 상세하게는 OTcl)에서 그렇게 하도록 규정하였다면, 상세한 시뮬레이션 data를 포함하는 하나 혹은 그 이상의 text-based 출력파일을 생성한다. 그 data는 시뮬레이션 분석(두 개의 시뮬레이션 결과 분석의 예가 다음절에 있다)을 위해 사용되거나, VINT 프로젝트의 일부로 개발된 Network Animator(NAM)으로 불리는 graphical 시뮬레이션 display tool로 의 입력으로 사용될 수 있다. NAM은 CD palyer(play, fast forward, rewind, pause and so on)와 비슷하게 훌륭한 graphical user 인터페이스를 가졌으며 display speed controller를 가졌다. 나아가, 그것은 비록 graphical 정보가 적정한 시뮬레이션 분석을 위해 사용되지 못한다 하더라도 throughput과 packet이 각 링크에서 drop되는 숫자와 같은 정보를 graphical하게 표현할 수 있다.



















 

2. Basics

2.1 OTcl: The User Language

언급된 overview section에서처럼, NS는 기본적으로 network simulation object library와 함께 하는 OTcl 인터프리터이다. NS를 사용하기 위해 OTcl에서 어떻게 프로그램 하는가를 아는 것은 매우 유용하다. 이번 절에서는 사람들이 OTcl에서 프로그래밍에 대한 기본적인 idea를 가짐으로써 Tcl과 OTcl script를 작성하는 예를 보여준다. 이 예들은 5소 VINT/NS simulation Tutorial/Workshop으로부터 가져왔다. 이 절과 이후의 절들은 독자가 NS를 인스톨하였고, C와 C++에 익숙한 것으로 가정한다.

예 1은 Procedure를 생성하고 그것을 호출을 어떻게 하는가 하는 것을 보여주는 일반적인 Tcl script이다. OTcl은 Tcl의 Object-oriented extension이며 C와 C++의 관계와 같이 Tcl의 모든 명령은 OTcl상에서 동작한다. 이 script를 동작시키기 위해서는 ex-tcl.tcl을 다운받으시오. 그리고 shell prompt에서 "ns ex-tcl.tcl"을 입력하시오. "ns" 명령어는 NS(OTcl 인터프리터)를 기동한다. 만일 tcl8.0이 install되어 있다면, "tcl ex-tcl.tcl"을 입력해도 같은 결과를 얻을 것이다.

 

Example 1. A simple Tcl Script

# Writing a procedure called "test"

proc test {} {

set a 43

set b 27

set c [expr $a + $b]

set d [expr [expr $a - $b] * $c]

for {set k 0} {$k < 10} {incr k} {

if {$k < 5} {

puts "k < 5, pow = [expr pow($d, $k)]"

} else {

puts "k >= 5, mod = [expr $d % $k]"

}

}

}

# Calling the "test" procedure created above

test

-. Tcl에서 keyword proc는 procedure를 정의하기 위해 사용되며

뒤에 프로세져의 이름과 { }가 사용된다.

-. keyword set는 변수에 값을 할당하기 위해 사용된다.

-. [expr ...]는 keyword 뒤에 braket에 있는 표현의 값을 계산하는 인터프 리터를 만드는 것이다.

-. $는 변수 이름과 함께 사용된다.

-. puts는 double quotation mark 내에 있는 스트링을 출력한다.

다음은 예제1의 결과를 보여준다.

k < 5, pow = 1.0

k < 5, pow = 1120.0

k < 5, pow = 1254400.0

k < 5, pow = 1404928000.0

k < 5, pow = 1573519360000.0

k < 5, pow = 0

k < 5, pow = 4

k < 5, pow = 0

k < 5, pow = 0

k < 5, pow = 4

다음 예는 OTcl에서 object-oriented programming 예이다. 이 예는 매우 단순하나, object가 OTcl에서 생성되고 사용되는 방법을 보여준다. 통상적인 NS 사용자는 자신의 object를 쓸 기회가 드물 것이다. 그러나, NS simulation programming에서 사용하는 모든 NS project가 C++로 쓰여졌는지 아닌지 OTcl 내에서만 쓰여졌는지, link를 경유하여 OTcl이 유용하게 만들어졌는지의 문제 때문에 OTcl object를 이해하는 것이 도움이 된다.

예제2는 "mom"과 "kid"두 개의 object class를 정의하는 OTcl script이다. 거기에서 "kid"는 "mom"의 child class이며, member 함수는 각 class에 대해 "greet"를 호출하였다. class 정의 후에, 각 object instance는 무시되며, 각 instance의 "age" 변수는 45(for mom)와 15(for kid)로 set된다. 그리고 각 object instance의 member 함수 "greet"가 호출된다. keyword Class는 object class를 생성하는 것이며, instproc는 object class로 member 함수를 정의하는 것이다, Class 상속은 keyword -superclass를 사용하여 규정된다. member 함수를 정의함에 있어서, $self는 C++에서 "this" pointer와 같이 동작한다.
 

Example 2. A sample OTcl Script

# Create a class call "mom" and

# add a member function call "greet"

Class mom

mom instproc greet {} {

$self instvar age_

puts "$age_ years old mom say:

How are you doing?"

}

# Create a child class of "mom" called "kid"

# and overide the member function "greet"

Class kid -superclass mom

kid instproc greet {} {

$self instvar age_

puts "$age_ years old kid say:

What's up, dude?"

}

# Create a mom and a kid object set each age

set a [new mom]

$a set age_ 45

set b [new kid]

$b set age_ 15

# Calling member function "greet" of each object

$a greet

$b greet


그리고, instvar는 만일 다음 변수 이름이 그 자신의 class나 superclass에서 이미 선언되었는지를 점검한다. 주어진 변수 이름이 이미 선언된 것이라면, 그 변수가 참조된다. 그렇지 않다면 새로운 이름이 선언된다. 결과적으로, object instance를 생성하기 위해서 keyword new가 예에서 보는바와 같이 사용된다.

ex-otcl.tcl을 Downloding하고 "ns ex-otcl.tcl"을 실행하면 다음과 같은 결과를 얻을 것이다.


45 years old mom say:

How are you doing ?

15 years old kid say:

What's up, dude ?



2.2 Simple Simulation Example

이 section은 간단한 NS simulation script를 보여주며, 각 line이 무엇을 하는지를 설명한다. 예제3 은 간단한 network 구성을 생성하는 OTcl script이며, 그림4.에 있는 시뮬레이션 scenario를 동작한다. 이 시뮬레이션을 동작하기 위해서 "ns-simple"를 다운받고, shell prompt에서 "ns ns-simple.tcl"을 입력하라.


fig 4. A simple Network Topology and Simulation Scenario
 

이 network는 4개의 node(n0, n1, n2, n3)를 위의 그림에서 보는바와 같이 구성한다. n0와 n2, n1과 n2 사이의 duplex link들은 2 Mbps의 대역폭과 10ms 지연을 가진다. n2와 n3사이의 duplex link는 1.7Mbps의 대역폭과 20ms 지연을 가진다. 각 node는 최대 크기가 10인 DropTail queue를 사용한다. "tcp" Agent는 n0에 접속되며, 연결은 n3에 접속된 tcp "sink" agent로 설정된다. "tcp" agent가 생성할 수 있는 packet의 최대 크기는 default로 1KByte이다. tcp "sink" agent는 ACK packet을 생성하고, sender(tcp agent)로 보내며, 수신된 packet을 자유롭게 한다.

n1에 접속된 "udp" agent는 n3에 접속된 "null" agent와 연결된다. "null" agent는 수신된 packet를 바로 자유롭게 한다. "ftp"와 "cbr" 트래픽 생성기는 "tcp"와 "udp" agent에 각기 접속되어있다. 그리고 "cbr"는 1Mbps의 속도에서 1KByte packet를 생성하도록 구성되어있다. "cbr"은 0.1초에서 start하고 4.5초에서 stop하도록 set되어 있다. 그리고 "ftp"는 1.0초에서 start, 4.0초에서 stop하도록 set되어 있다.


Example 3. A Simple NS Simulation Script

#Create a simulator object

set ns [new Simulator]

#Define different colors for data flows (for NAM)

$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 NAM trace file

close $nf

#Execute NAM on the trace file

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 links between the nodes

$ns duplex-link $n0 $n2 2Mb 10ms DropTail

$ns duplex-link $n1 $n2 2Mb 10ms DropTail

$ns duplex-link $n2 $n3 1.7Mb 20ms DropTail

#Set Queue Size of link (n2-n3) to 10

$ns queue-limit $n2 $n3 10

#Give node position (for NAM)

$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

#Monitor the queue for link (n2-n3). (for NAM)

$ns duplex-link-op $n2 $n3 queuePos 0.5

#Setup a TCP connection

set tcp [new Agent/TCP]

$tcp set class_ 2

$ns attach-agent $n0 $tcp

set sink [new Agent/TCPSink]

$ns attach-agent $n3 $sink

$ns connect $tcp $sink

$tcp set fid_ 1

#Setup a FTP over TCP connection

set ftp [new Application/FTP]

$ftp attach-agent $tcp

$ftp set type_ FTP

#Setup a UDP connection

set udp [new Agent/UDP]

$ns attach-agent $n1 $udp

set null [new Agent/Null]

$ns attach-agent $n3 $null

$ns connect $udp $null

$udp set fid_ 2

#Setup a CBR over UDP connection

set cbr [new Application/Traffic/CBR]

$cbr attach-agent $udp

$cbr set type_ CBR

$cbr set packet_size_ 1000

$cbr set rate_ 1mb

$cbr set random_ false

#Schedule events for the CBR and FTP agents

$ns at 0.1 "$cbr start"

$ns at 1.0 "$ftp start"

$ns at 4.0 "$ftp stop"

$ns at 4.5 "$cbr stop"

#Detach tcp and sink agents (not really necessary)

$ns at 4.5 "$ns detach-agent $n0 $tcp ; $ns detach-agent $n3 $sink"

#Call the finish procedure after 5 seconds of simulation time

$ns at 5.0 "finish"

#Print CBR packet size and interval

puts "CBR packet size = [$cbr set packet_size_]"

puts "CBR interval = [$cbr set interval_]"

#Run the simulation

$ns run


다음은 위 script에 대한 설명이다. 일반적으로 NS script는 Simulator object instance를 만들어서 시작한다.

 

○ set ns[new Simulator]:

NS simulator object instance를 생성하며, 변수 ns로 그것을 할당한다.(italics은 이 section에서 변수와 값으로 사용된다.) 이 라인의 역할은 다음과 같다.

-. packet format를 초기화(여기서는 이것을 무시)

-. scheduler를 생성(default는 calendar scheduler임)

-. default address format를 선택(여기서는 이것을 무시)

이 "Simulator" object는 다음의 일을 하는 member 함수를 가진다.

-. node와 link같은 복합 object를 생성(desired later)

-. 생성된 network 구성 object를 연결(ex. attach-agent)

-. network 구성 parameter를 set(mostly for compound object)

-. agent 사이의 연결 생성(ex. "tcp"와 "sink"사이의 연결을 만든다)

-. NAM display option을 규정

-. Etc.

member 함수의 대부분은 simulation setup(Overview section에서 plumbing 함수와 관련된)과 scheduling을 위해서 있다. 그러나, 그들 중 대부분은 NAM display를 위해서 있다. "Simulator" object member 함수 구현은 "ns-2/tcl/lib/ns-lib.tcl" file내에 위치해 있다.

 

○ $ns color fid color:

flow id(fid)에 의해 규정된 flow에 대한 packet의 color를 set 하는 것. 이 "Simulator" object의 member 함수는 NAM display를 위한 것이다. 그리고 실제적인 시뮬레이션 상에 어떤 효과도 미치지 않는다.

 

○ $ns namtrace-all file-descriptor:

이 member 함수는 NAM input format에 있는 simulation trace를 기록하기 위한 시뮬레이터를 말한다. 그것은 또한 trace가 $ns flush-trace 명령에 의해 나중에 쓰여질 file name을 준다.

 

○ proc finish {}:

이 시뮬레이션 뒤에 $ns at 5.0 "finish" 명령에 의해 호출된다. 이 함수에서 post-simulation process가 규정된다.

 

○ set n0 [$ns node]:

member 함수 node는 node를 생성한다. NS에 있는 node는 address와 port classifier들로 만들어진 복합 object이다.(다음 section에서 기술된다) 사용자는 주소와 port classifier object를 분리하여 생성하고, 그들을 함께 연결함으로써 node를 생성할 수 있다. 그러나, 이 Simulator object의 member 함수는 job를 보다 쉽게 만든다. node가 생성되는 방법을 보기 위해 file "ns-2/tcl/libs/ns-lib.tcl" 과 "ns-2/tcl/ns-node.tcl"을 살펴보라.

 

○ $ns duplex-link node1 node2 bandwidth delay queue-type:

상술된 bandwidth와 delay의 두 개의 simplex link를 생성하며, 두 개의 상술된 node를 연결한다. NS에서 node의 출력 queue는 link의 부분으로 구현된다. 그러므로, user는 link를 생성할 때 queue type를 상술해야 한다. 위의 시뮬레이션 script에서, DropTail queue가 사용된다. 만일 독자가 RED queue를 사용하기를 원한다면, 간단하게 DropTail을 RED로 대치하면 된다. link의 NS 구현은 다음 section에서 보여진다. node처럼, link도 compound object이며 user는 그것의 sub-object를 생성하고 그들과 node를 연결할 수 있다. Link source code는 "ns-2/tcl/libs/ns-lib.tcl"과 "ns-2/tcl/libs/ns-link.tcl" 파일에서 찾을 수 있다. 주목해야하는 하나는 당신이 lossy link(실제 user는 어떤 network object를 만들고 삽입할 수 있다.) 를 시뮬레이트 하기 위해서 link component 안에서 error module를 삽입할 수 있다. 이것을 어떻게 찾는가 하는 것은 NS document를 참고하라.

 

○ $ns queue-limit node1 node2 number:

이 라인은 상술된 숫자로 node1고 node2를 연결하는 두 개의 simplex link의 queue limit를 set한다. 이 점에서, 저자는 얼마나 많은 시뮬레이터 object의 member 함수의 종류들이 유용한지, 그리고 그것들이 무엇인지를 알지 못한다. "ns-2/tcl/libs/ns-lib.tcl"과 "ns-2/tcl/libs/ns-link.tcl"을 찾아보거나, 보다 자세한 정보를 찾으려면 NS document를 참고하라.

 

○ $ns duplex-link-op node1 node2...:

line의 다음 couple는 NAM display를 위해서 사용된다. 이 라인의 효과를 보기 위해서 user는 이 라인을 구성하고 시뮬레이션을 시도할 수 있다.

지금, 기본적인 network setup이 행해졌다. 다음에 해야할 일은 TCP와 UDP 같은 traffic agent, FTP와 CBR같은 traffic source를 setup하는 것이다. 그리고 그것들을 각각 node와 agent로 접속하는 것이다.

 

○ set tcp[new Agent/TCP]:

이 라인은 TCP agent를 생성하는 방법을 보여준다. 그러나, 일반적으로 user는 이런 방법으로 어떤 agent나 traffic source를 생성할 수 있다. Agent와 traffic source는 사실상 기본적인 object(not compound object)이며, 대부분 C++에서 구현되고 OTcl로 링크된다. 그러므로, 이러한 object instance를 생성하는 특수한 Simulator object member 함수는 없다. Agentsk traffic source를 생성하기 위해서, User는 object class 이름(Agent/TCP, Agent/TCPSink, Application/FTP 등등)을 알아야 한다. 이 정보는 NS document나 이 document에서 부분적으로 찾을 수 있다. 그러나, one shortcut는 "ns-2/tcl/libs/ns-default.tcl" file을 보는 것이다. 이 file은 가용한 network object에 대한 default 구성 parameter 값 setting을 포함한다. 그러므로, 그것은 어떤 종류의 network object가 NS에 유용한가 그리고 구성 parameter가 무엇인가에 대한 훌륭한 indicator로서 동작한다.

 

○ $ns attach-agent node agent:

attach-agent member 함수는 node object로 생성된 agent object를 접속한다. 실제적으로, 이 함수는 규정된 node의 attach member 함수를 호출한다. 그것은 그 자신으로 주어진 agent를 접속한다. 그러므로, user는 예를 들면, $n0 attach $tcp에 의해 동일한 일을 할 수 있다. 유사하게, 각 agent object는 그 자신으로 traffic source object를 접속하는 member 함수 attach-agent를 가진다.

 

○ $ns connect agent1 agent2:

서로간에 통신을 할 두 개의 agent가 생성된 후에, 다음 일은 그들 사이에 logical network 연결을 설정하는 것이다. 이 라인은 각기 다른 network와 port address pair로 목적지 address를 setting함으로서 network 연결을 설정한다.

network 구성이 모두 완료되었다고 가정하면, 다음에 해야할 일은 simulation 시나리오(시뮬레이션 scheduling 등)를 쓰는 일이다. Simulator object는 많은 scheduling member 함수를 갖는다. 그러나, 대부분 사용되는 방법은 다음과 같다.

 

○ $ns at time "string":

Simulator object의 member 함수는 주어진 simulation time에 규정된 string의 실행을 schedule하기 위해 scheduler(scheduler_ 는 script 시작 부분에서 [net scheduler] 명령에 의해 생성된 scheduler object를 지시하는 변수이다.)를 만든다. 예를 들어, $ns at 0.1 "$cbr start"는 data 전송을 위해 CBR을 시작하는 CBR traffic source object의 start member 함수를 호출하는 call를 만들 것이다. NS에서 보통 traffic source가 실제적인 data를 전송하지는 않지만 그것은 전송해야하는 data가 많으며, 전송할 data가 얼마나 많은지 알고 있다는 것을 기초적인 Agent에게 공지하고 packet을 생성하며 그것들을 전송한다.

모든 network 구성 후에, scheduling과 post-simulation 절차 specification이 행해진다. 남아있는 유일한 일은 시뮬레이션을 작동시키는 것이다. 이것은 $ns run으로 실행된다.





























 

2.3 Event Scheduler

이 section은 NS의 discrete event scheduler에 관해 설명한다. 앞의 section에서 기술한 바와 같이, event scheduler의 main user는 packet-handling delay를 시뮬레이트 하거나, 시간을 필요로 하는 network 구성요소들이다. 그림5는 event scheduler를 사용하는 각 network object를 모여준다. event를 발행하는 network object는 schedule된 시간에서 뒤에 event를 조정하는 사람임을 주목하라. 또한, network object들 간의 data path가 event path와 다르다는 것도 주목하라. 실제적으로, packet들은 하나의 network object로부터 sender의 방법인 send(Packet* P) {target_ -> recv(p)};와 receiver의 방법인 recv(Packet*, Handler*h=0)를 사용하는 다른 object에게 전달된다.



fig 5. Discrete Event Scheduler

 

NS는 구현된 event scheduler의 두 개의 다른 type을 가지고 있다. 이들은 real-time과 non-real-time scheduler이다. non-real-time-scheduler에 대해서는 그들이 모두 같은 것을 논리적으로 수행한다 하더라도, 세 개의 구현(List, Heap와 Calendar)이 가용하다. 이것은 backward 호환성: 사용자(package에 포함된 원래 사용자가 아닌)에 의해 부가된 network 구성요소들의 조기구현의 대부분은 public 함수를 통해서 뿐만 아니라 내부 주위를 빈둥거리는 scheduler의 특수한 type을 사용하기 때문이다. Calendar non-real-time scheduler는 default로 set된다. real-time scheduler는 emulation을 위한 것이며, 그것은 시뮬레이터가 real network으로 상호 작용하는 것을 허용한다. 현재, emulation은 experimental version이 유용함을 통과하고 개발 중에 있다. 다음은 특수한 event scheduler를 선택하는 예이다.

...

set ns[new Simulator]

$ns use-scheduler Heap

...

event scheduler의 또 다른 사용은 예컨대, FTP 응용을 시작할 때, 시뮬레이션을 끝낼 때, 시뮬레이션이 동작에 앞서 시뮬레이션 시나리오를 생성하기 위함 등의 simulation event를 schedule하는 것이다. event scheduler object는 그 자신이 특수한 시뮬레이션 time에 AtEvent로 불리는 특수한 event를 발행하는 at time "string"과 같은 simulation scheduling member 함수를 가지고 있다. "AtEvent"는 실제적으로 "Event"의 child class이며, 그것은 주어진 string을 hold하기 위한 부가적인 변수를 가지고 있다. 그러나, 그것은 event scheduler 내에서 normal(packet related) event와 같이 취급된다. 시뮬레이션이 시작될 때, 그리고 event queue에 있는 AtEvent에 대한 예정된 시간이 될 때, AtEvent는 한번 생성된 "AtEvent handler"로 넘어간다. 그리고 모든 AtEvent를 조정하며, AtEvevt의 string field에 의해 규정된 OTcl 명령어가 실행된다. 다음은 위 예의 버전을 부가한 simulation event scheduling line이다.

...

set ns[new Simulator]

$ns use-scheduler Heap

$ns at 300.5 "complete_sim"

...

proc complete_sim{} {

....

}

당신은 위의 예로부터 at time "string"이 Simulator object(set ns[new Simulator])의 member 함수임을 주목했다. 그러나, 방금의 시뮬레이터 object는 user interface로 동작하며, 그것은 실제적으로 real job를 행하는 network object나 scheduler object의 member 함수를 호출한다는 것을 기억하라. 다음은 부분적인 list이며, scheduler member 함수에 정합하는 Simulator object member 함수에 대한 간략한 기술이다.

Simulator instproc now #return scheduler's notion of current time

Simulator instproc at args #schedule execution of code at specified time

Simulator instproc at-now args #schedule execution of code at now

Simulator instproc after n args #schedule execution of code after n secs

Simulator instproc run args #start scheduler

Simulator instproc halt #stop(pause) scheduler




























 

2.4 Network Components

이 section은 대부분 혼합 network component인 NS components에 관해서 설명한다. 그림6.은 NS의 부분적인 OTcl class 계층구조를 보여준다. 이것은 기본적인 network component를 이해하는데 도움을 준다. NS class 계층구조를 완성하기 위해서 http://www-sop.inria.fr/rodeo/personnel/Antoine.Clerget/ns를 방문하라.


fig 6. Class Hierarchy (partial)

 

계층구조의 root는 모든 OTcl library object(scheduler, network components, timer와 NAM 관련한 것들을 포함하는 다른 object들)의 superclass인 TclObject이다. TclObject를 선조 class로 갖는 NSObject class는 packet을 조정하는 모든 기본적인 network component object의 superclass이다. 그것은 node와 link와 같은 혼합 network object를 구성한다. 기본적인 network 구성요소는 가능한 출력 data 경로의 수에 기반을 둔 Connector와 Classfier의 두 개의 subclass로 더 나뉘어 진다. 하나의 출력 data 경로만을 갖는 기본적인 network object는 Connector class하에 있다. 그리고 multiple 출력 data 경로를 갖는 switching object는 Classfier class하에 있다.

Node와 Routing

node는 node entry object와 그림 7.에서 본 classfier로 구성된 혼합 object이다. NS에는 두 type의 node가 있다. unicast node는 routing을 unicast하는 address classfier와 port classfier를 가지고 있다. multicast node는 unicast packet으로부터 multicast packet을 분리하는 classfier와 multicast routing을 수행하는 multicast classfier를 가지고 있다.



fig 7. Node(Unicast and Multicast)
 

NS에서 Unicast node는 default node이다. Multicast node를 생성하기 위해서는 사용자는 scheduler object를 생성하는 right after을 사용하여, 입력 OTcl script내에 명확하게 명시를 해야한다. 생성될 모든 node는 multicast node들이다. node type을 규정한 후에 user는 default를 사용하는 것과는 다른 특수한 routing protocol을 선택할 수 있다.

 

○ Unicast

-. $ns rtproto type

-. type: Static, Session, DB, cost, multi-path

 

○ Multicast

-. $ns multicast (right after set $ns[new Scheduler])

-. $ns mrtproto type

-. type: CtrMcast, DM, ST, BST

routing에 관한 상세한 정보는 NS document를 참고하라. documentation은 unicast와 multicast routing에 관하여 설명하는 chapter가 있다.



Link

link는 NS에 있는 또 다른 복합 object이다. user가 simulator object의 member 함수인 duplex-link를 사용하는 link를 생성할 때, 양 방향에 있는 두 개의 simplex link들이 그림8.에 보는 바와 같이 생성된다.



fig 8. Link
 

주목할 하나는 node의 출력 queue가 실제적으로 simplex link object의 일부로 구현된다는 것이다. queue로부터 dequeue된 Packet들은 link delay를 시뮬레이트하는 Delay object로 통한다. 그리고 queue에서 drop된 Packet들은 Nul Agent로 보내지며 거기서 자유롭게 된다. 결과적으로, TTL object는 수신된 각 packet에 대한 TTL parameter를 계산하고 Packet의 TTL field를 갱신한다.

 

○ Tracing

NS에서, network active들은 simplex link 주위로 trace된다. 만일 simulator가 network activities를 trace하도록 지시를 받는다면($ns trace-all file 혹은 $ns namtrace-all file), 명령 뒤에 생성된 link는 그림9.에서 보는 바와 같이 삽입된 후속 trace object를 가질 것이다. User는 또한 create-trace {type file src dst} 명령을 사용하여 src와 dst node 사이에 type으로 정의한 type의 trace object를 명확하게 생성할 것이다.


fig 9. Inserting Trace Objects
 

각 삽입된 trace object(EnqT, DeqT, DrpT, RecvT 등)가 packet를 수신할 때, 그것은 어떤 시뮬레이션 time에 의해 소비함이 없이 규정된 trace file에 기록한다. 그리고 다음 network object로 packet를 전달한다. trace format은 General Analysis Example section에서 시험될 것이다.

 

○ Queue Monitor

기본적으로, object를 tracing하는 것은 그것들이 위치한 곳에서 packet arrival time을 기록하기 위해서 설계된다. 비록 user가 trace로부터 충분한 정보를 얻는다 하더라도, 특별한 출력 queue 내부에서 무엇이 지나가고 있는지에 관해 흥미가 있을 것이다. 예를 들어, RED queue 동작에 관심있는 user는 평균 queue 크기의 dynamics 및 특별한 RED queue(queue monitoring이 필요한 등등)의 현재 queue 크기를 측정하기를 원할 것이다. Queue monitoring은 그림 10에 보는 바와 같이 queue monitor object와 snoop queue object를 사용하여 얻을 수 있다.



fig 10. Monitoring Queue
 

packet이 도착할 때, snoop queue object는 이 event의 queue monitor object를 주시한다. 이 정보를 사용하는 queue monitor는 queue를 monitor한다. RED queue monitoring 예는 RED queue monitor Example section에 서 보여진다. snoop object는 비록 그것이 위 그림에서 보여지지 않는다 하더라도 object를 tracing하는 것과 병렬로 사용될 수 있다는 점을 주목하라.

Packet Flow Example

지금까지 두 개의 가장 중요한 network 구성요소(node와 link)가 시험되었다. 그림11.은 예제 simulation network setup과 packet flow의 내부를 보여준다. network는 network address가 각각 0과 1인 두 개의 node(n0와 n1)를 구성한다. port 0을 사용하여 no에 접속된 TCP agent는 port 0와 n1에 접속된 TCP sink object와 통신한다. 결국, FTP application(혹은 traffic source)는 역간 많은 data를 전송할 것을 요청하는 TCP agent에 접속된다.



fig 11. Packet Flow Example
 

위 그림은 FTP over TCP의 정확한 동작을 보여주지는 않는다는 것에 주목하라. 그것은 오직 simulation network setup과 packet flow의 상세한 내부를 보여줄 뿐이다.





















 

2.5 Packet

NS packet은 header들의 stack과 optional data space로 구성된다. "Simple Simulation Example" section에서 간단히 언급된 것처럼, packet header format은 Simulator object가 생성될 때 초기화되며, 필요한 만큼 어떤 object에 의해 통상적으로 사용되는 common header 즉, IP header, TCP header, RTP header(UDP는 RTP header를 사용한다.)와 trace header와 같은 (아마 사용 가능한)header를 모든 stack이 등록한 곳에서 정의되며, stack에 있는 각 header의 offset이 기록된다. 이것이 의미하는 바는, 특수한 header가 사용되는지 아닌지 하는 것이며, 등록된 모든 header로 구성된 stack은 packet이 agent에 의해 할당될 때 생성되고, network object가 packet의 stack에 있는 어떤 header도 access할 수 있다는 것이다.



fig 12. NS Packet Format
 

보통, header stack(그리고 null인 data space pointer)을 가지기만 한다. 비록 packet이 data space 할당에 의해 응용으로부터 실제적인 data를 운반할 수 있다 하더라도, 매우 극소수의 응용과 agent implementation들이 이것을 지원한다. 이것은 non-real-time simulation 주위에 있는 data를 운반하는 것은 의미 없는 것이기 때문이다. 그러나, 만일 당신이 network을 횡단하여 다른 응용에게 talk하는 응용을 구현하기를 원한다면, 기초적인 agent 구현에서 약간의 변형을 가한 것을 사용하기 원할 것이다. 또 다른 가능한 approach는 응용을 위한 새로운 header를 생성하고, 응용에서 새로운 header로 수신된 data를 쓰기 위해 기초적인 agent를 변형될 것이다. second approach는 "Add New Application and Agent"라 불리는 마지막 section의 예로 보여진다.

 

 

 

 

 

3. Post Simulation

3.1 Trace Analysis Example

이 section은 trace 분석 예를 보여준다. Example 4.는 trace file을 열고 그것에 trace를 쓰기 위해 약간의 line이 부가된 "Simple Simulation Example" section에 있는 것과 동일한 OTcl script이다. 시뮬레이션 시나리오를 생성하는 network topology는 "Simple Simulation Example" section에 있는 그림4.를 참고하라. 이 scrip를 동작시키기 위해서 "ns-simple-trace.tcl"을 down 받고, shell prompt에서 "ns ns-simple-trace.tcl"을 입력하라.

 

Example 4. Trace Enabled Simple NS Simulation Script

(Modified from Example 3)

......

#Open the NAM trace file

set nf [open out.nam w]

$ns namtrace-all $nf

#Open the Trace file

set tf [open out.tr w]

$ns trace-all $tf

#Define a 'finish' procedure

proc finish {} {

global ns nf tf

$ns flush-trace

#Close the NAM trace file

close $nf

#Close the Trace file

close $tf

#Execute NAM on the trace file

exec nam out.nam &

exit 0

}

......



위의 script를 동작함으로써, NAM에 입력으로 사용되는 NAM trace file과 시뮬레이션 분석을 위해 사용될 "out.tr"로 불리는 trace file를 생성한다. 그림13은 trace format과 "out.tr"로부터의 예제 trace data를 보여준다.





fig 13. Trace Format Example
 

각 trace line은 뒤에 event simulation time(단위: 초)과 발생된 event 상에 있는 link를 구별하는 from node, to node를 뒤에 둔 event(+, -, d, r) 서술자로 시작한다. 각 event type이 어디에 있는 link에서 trace 되는지 보기 위해서는 "Network Component" section에 있는 그림 9를 보라. flag(set된 flag가 없기 때문에 "------"로 표시되는)앞 line에 있는 다음 정보는 Packet type과 size(in Bytes)이다. 현재 NS는 Explicit Congestion Notification(ECN) bit만 구현하며, 남은 bits는 사용되지 않는다. 다음 field는 user가 입력 OTcl script에서 각 flow를 위해 set할 수 있는 IPv6의 flow id(fid)이다. 비록 fid field가 시뮬레이션 내에서 사용되지 않는다 하더라도 user는 분석을 위해서 이 field를 사용할 수 있다. fid field는 NAM display를 위해 stream color를 규정할 때도 사용될 수 있다. 다음 두 개의 field는 "node.port"의 형태로 된 source와 destination 주소이다. 다음 field는 network layer protocol의 packet sequence number를 보여준다. 비록 UDP 구현이 sequence number를 사용하지 않는다 하더라도 NS는 분석 목적을 위해 UDP packet sequence number의 track을 유지한다. 마지막 field는 packet의 unique id를 보여준다.

simulation trace data를 얻었으므로, 모든 사람은 관심있는 data의 subset을 이해할 수 있는 정보로 변형시키고 그것을 분석해야 한다. 아래에 있는 것은 작은 data 전송의 예이다. 이 예는 주어진 입력의 column을 선택하는 "column"으로 불리는 perl에서 쓰여진 명령을 사용한다. 당신의 machine에서 동작하는 예를 만들기 위해서, 당신은 "column"을 down받고 그것을 실행할 수 있도록 만들라 ("chmod 755 column "을 사용). 다음은 "out.tr"에 있는 data를 사용하여 수신 node(n3)에서 CBR traffic jitter을 계산하고, "jitter.txt"에서 결과 data를 저장하는 awk로 조합된 tunneled shell 명령어이다.

참고 :


How to get things done with awk ?

Author: Sakari Mattila

Updated: 30-Mar-1999

Updated: 22-Jan-1996

awk is a pattern matching program. It takes two inputs: data file and command file. The data file contains text, that is lines containing words. Data file need not be usual text, any data composed of character groups (words) and lines is suitable. Default character group separator is space, but other separators may be defined on awk starting command line. More on awk starting command is at the end of this document. The command file contains pattern matching instructions, it is equal to ordinary computer program. Feel free to thing awk as an interpreter executing commands from the command file on the data file.

awk comes with all Unix and Linux operating systems. It is a command line utility. awk is also included in several Unix-like utilities packages for MS Windows 95/98, MS Windows NT and other operating systems. Cygwin http://sourceware.cygnus.com/cygwin in one source of these packages. awk source code in C is available with full Linux packages and GNU packages.

awk can be used to extract parts from a large text body.





cat out.tr | grep " 2 3 cbr " | grep ^r | column 1 10 | awk '{dif = $2 - old2; if(dif==0) dif = 1; if(dif > 0) {printf("%d\t%f\n", $2, ($1 - old1) / dif); old1 = $1; old2 = $2}}' > jitter.txt

이 shell 명령은 n3에서 "CBR packet receive" event를 선택하고, time(column 1)과 sequence number (column 10)을 선택하고, 마지막 packet 수신시간과 각 sequence number에 대한 sequence number(loss packet에 대한)에서의 차이로 나눈 차이를 계산한다. 다음은 gnuplot를 사용하여 생성된 jitter graph이다. X축은 packet sequence number이며, Y축은 초당 simulation 시간이다.

참고 :

The gnuplot program for plotting 2D and 3D graphs

--------------------------------------------------------------------

SHAZAM provides an interface to GNUPLOT. This is described in the PLOTS AND GRAPHS chapter in the SHAZAM User's Reference Manual. SHAZAM will produce a simple gnuplot command file. You can then customize the command file with many of the gnuplot features that are available.

Gnuplot web site

For downloading gnuplot, a number of file options are given at the gnuplot download page. The following files are recommended for use with SHAZAM.


gnuplot name required by SHAZAM

gnuplot file download

Windows SHAZAM

wgnuplot.exe

gp371cyg.zip

SHAZAMD

MSDOS command prompt

gnuplot.exe

gp371dyg.zip




fig 14. CBR Jitter at The Receiving Node(n3)
 

보다 많은 utility를 보기 위해서 http://perform.wpi.edu/NS/utilities를 점검해 보라.

이 section은 NS에서 trace를 생성하고 그것을 interpret하며, trace로부터 유용한 정보를 얻는 방법의 예를 보여 주었다. 이 예에서, post simulation process는 시뮬레이션 후에 shell prompt에서 행해진다. 그러나, 이 process는 input OTcl script에 포함될 수 있다. 그것은 다음 section에서 보여준다.

 

 

 

 

3.2 RED Queue Monitor Example

이 section은 RED queue monitoring 예제를 보여준다. 예제5는 Polly Huang에 의해 쓰여진 OTcl script이며, 그것은 network topology를 setup하고 그림15.에 나타난 시뮬레이션 시나리오를 동작한다.

25 packet까지 hold up 할 수 있는 RED queue가 link r1-r2에 사용되었으며, 우리는 current와 average queue size의 dynamics를 측정함으로써 RED queue가 어떻게 동작하는지 보기를 원한다는 것을 주목하라. 이 script를 동작시키기 위해서, "red.tcl"을 다운받고 "ns red.tcl"을 입력하라.



fig 15. RED Monitor Example Setup



 

Example 5. RED Queue Monitor Simulation Script

# Polly Huang 8-7-98

set ns [new Simulator]

#

# Create a simple six node topology:

#

# s1 s3

# \ /

# 10Mb,2ms \ 1.5Mb,20ms / 10Mb,4ms

# r1 --------- r2

# 10Mb,3ms / \ 10Mb,5ms

# / \

# s2 s4

#

set node_(s1) [$ns node]

set node_(s2) [$ns node]

set node_(r1) [$ns node]

set node_(r2) [$ns node]

set node_(s3) [$ns node]

set node_(s4) [$ns node]

$ns duplex-link $node_(s1) $node_(r1) 10Mb 2ms DropTail

$ns duplex-link $node_(s2) $node_(r1) 10Mb 3ms DropTail

$ns duplex-link $node_(r1) $node_(r2) 1.5Mb 20ms RED

$ns queue-limit $node_(r1) $node_(r2) 25

$ns queue-limit $node_(r2) $node_(r1) 25

$ns duplex-link $node_(s3) $node_(r2) 10Mb 4ms DropTail

$ns duplex-link $node_(s4) $node_(r2) 10Mb 5ms DropTail

$ns duplex-link-op $node_(s1) $node_(r1) orient right-down

$ns duplex-link-op $node_(s2) $node_(r1) orient right-up

$ns duplex-link-op $node_(r1) $node_(r2) orient right

$ns duplex-link-op $node_(r1) $node_(r2) queuePos 0

$ns duplex-link-op $node_(r2) $node_(r1) queuePos 0

$ns duplex-link-op $node_(s3) $node_(r2) orient left-down

$ns duplex-link-op $node_(s4) $node_(r2) orient left-up

set tcp1 [$ns create-connection TCP/Reno $node_(s1) TCPSink $node_(s3) 0]

$tcp1 set window_ 15

set tcp2 [$ns create-connection TCP/Reno $node_(s2) TCPSink $node_(s3) 1]

$tcp2 set window_ 15

set ftp1 [$tcp1 attach-source FTP]

set ftp2 [$tcp2 attach-source FTP]

# Tracing a queue

set redq [[$ns link $node_(r1) $node_(r2)] queue]

set tchan_ [open all.q w]

$redq trace curq_

$redq trace ave_

$redq attach $tchan_

$ns at 0.0 "$ftp1 start"

$ns at 3.0 "$ftp2 start"

$ns at 10 "finish"

# Define 'finish' procedure (include post-simulation processes)

proc finish {} {

global tchan_

set awkCode {

{

if ($1 == "Q" && NF>2) {

print $2, $3 >> "temp.q";

set end $2

}

else if ($1 == "a" && NF>2)

print $2, $3 >> "temp.a";

}

}

set f [open temp.queue w]

puts $f "TitleText: red"

puts $f "Device: Postscript"

if { [info exists tchan_] } {

close $tchan_

}

exec rm -f temp.q temp.a

exec touch temp.a temp.q

exec awk $awkCode all.q

puts $f \"queue

exec cat temp.q >@ $f

puts $f \n\"ave_queue

exec cat temp.a >@ $f

close $f

exec xgraph -bb -tk -x time -y queue temp.queue &

exit 0

}

$ns run



위 script에서 주목할 만한 것이 두 곳이 있다. 첫째, 보다 진보된 Simulator member 함수 create-connection이 TCP 연결을 생성하기 위해 사용되었다. 둘째, script의 queue tracing(monitoring) part에서 멋진 모습을 보라. 이 라인들은 RED queue object를 가리키는 변수를 만들고 현재 queue size(curq_)와 평균 queue size(avg_)를 monitor하기 위해서 그것의 member 함수 trace를 호출한다. 그리고 그것들이 결과를 "all.q" file에 쓰도록 한다. 다음은 평균 queue size와 현재 queue size에 대한 두 개의 queue trace 출력 format들이다.

a time avg_q_size

Q time crnt_q_size

지금 RED queue monitoring을 위해 필요한 모든 명령어들은 시뮬레이션이 행해질 때 "all.q" file을 닫는 것을 제외하고 행해진다. 남은 작업은 post-simulation process를 설계한다. awk를 사용하는 이 script는 XGraph(a plotter) 입력 format 속으로 monitored information을 전송하는 process를 수행한다. 그리고 주어진 정보(see 그림16)를 그리기 위해 그것을 내보낸다.








fig 16. RED Queue Trace Graph

 

 

Trace Analysis Utilities

여기에 유용한 trace 분석 utility의 모음이 있다. :

○ 만일 column을 추출할 수 있다면 많은 문장의 분석이 쉽게된다. 여기에 whitespace에 의해 분리된 column 속으로 text 출력을 분석하는 "column"으로 불리는 helper-perl utility가 있다.

 

column

#!/usr/bin/perl

# Mark Claypool

# Last significantly modified: April 27, 1994

# This program prints out fields of an indicated column.

# The columns are numbered 1, 2, 3 ...

&ParseCommandLine;

$line = <STDIN>;

while ($line) {

$line =~ s/^\s+//; # remove initial white-space

$line =~ s/\s+/ /g; # turn double-space into single space

@word = split('\s+',$line); # columns will then be $1, $2, $3 ...

$i =0;#

while ($i <= $#col) {

print "@word[@col[$i]]\t";

$i += 1;

}

print "\n";

$line = <STDIN>;

}

exit;

 

#######################################################################

# ParseCommandLine

# check for the right number of command line arguments

# print usage message and quit if there is an error

# global variables are @col

sub ParseCommandLine

{

while ($#ARGV >= 0) {

$arg = shift(@ARGV);

if ($arg =~ /^(\d+)/) {

push(@col, $1);

} else {

&usage;

}

}

if ($#col < 0) {

&usage;

}

}

##########################################################################

# usage

# print a usage maessage and quit

sub usage

{

print STDERR "column: print fields from an indicated column\n";

print STDERR "Usage: column <flags>, where flags are:\n";

print STDERR " {# [#...]}\tcolumn(s) to print, numbered 0,1,2...\n";

exit;

}


 


그것은 아래의 많은 script에 의해 사용된다.

○ 여기에 출력 file stats.tr의 bottleneck link(이 경우에는 node1에서 node2)를 따라서 어떤 상태를 출력하는 stat.pl script라 불리는 간단한 perl이 있다.

다음의 명령어로 그것을 동작하라.: stats.pl -l1 1 -l2 2 -max 1.5 stats.tr

○ 여기에 awk로 조합된 jitter.sh로 불리는 tunneled shell 명령이 있다. 그것은 "out.tr"에 있는 data를 사용하는 수신 node(n3)에서 CBR traffic jitter를 계산한다. 그리고, "jitter.txt"에 결과 data를 저장한다. 이 shell 명령은 n3에서 "CBR packet receive" event를 선택하고, time(column 1)과 sequence number (column 10)을 선택하고, 마지막 packet 수신시간과 각 sequence number에 대한 sequence number(loss packet에 대한)에서의 차이로 나눈 차이를 계산한다.

 

 

 

 

4. Extending NS

4.1 Where to Find What ?

NS를 어떻게 확장하는가 하는 논의에 들어가기 전에, 무슨 정보가 어떤 디렉토리나 file에 저장되는가 하는 것을 간략하게 시험해 보도록 하자. 그림 17은 ns-allinone-2.1b package를 사용하여 install 했을 때의 시뮬레이터 디렉토리 구조의 일부분을 보여준다.



fig 17. NS Directory Structure

 

ns-allinone-2.1b의 sub-directory 가운데, ns-2는 모든 시뮬레이터의 구현을(OTcl에서 혹은 C++에서) 즉, validation test OTcl script와 example OTcl script를 가지고 있는 장소이다. 이 디렉토리 내부에 있는 모든 OTcl code와 test/example script들은 sub-directory tcl 밑에 위치해 있다. 그리고 WWW와 관련된 것을 제외하고, event scheduler와 basic network component object class를 구현하는 C++ code 대부분은 main level에 위치해 있다. 예를 들어, 당신이 UDP agent의 구현을 보기 원한다면, 당신은 "ns-allinone-2.1b/ns-2" 디렉토리로 가서 "udp.h", "udp.cc"와 필요한 UDP의 선조 calss의 구현을 포함하는 file을 open 해야한다. 네트워크 구성요소들의 class 계층 구조에 대해서는 "Network Components" section에 있는 Figure 6.을 참고하라. 앞으로는 당신이 이미 "ns-allinone-2.1b" 디렉토리에 있는 것으로 가정한다.

가장 기본적이며 NS 구현(agent, node, link, packet, address, routing, and etc.)의 가장 필요한 부분을 위한 OTcl source code를 포함하는 lib 디렉토리들 가운데서 sub-directory를 가지고 있는 tcl 디렉토리는 user로서 또는 developer로서 가장 빈번히 방문하게 되는 곳이다. LAN, Web, Multicast 구현에 대한 OTcl source code는 tcl의 분리된 subdirectory 내에 위치하고 있다는 것을 주목하라.

다음은 "ns-2/tcl/lib" 디렉토리에 있는 file의 부분적인 list이다.

 

○ ns-lib.tcl:

simulator class와 그것의 member 함수 정의의 대부분(LAN, Web, Multicast와 관계된 것들을 제외하고)이 여기에 위치해 있다. 만일, 당신이 simulator object class의 member 함수가 유용한지 그리고 그것들이 어떻게 동작하는지를 알기 원한다면, 이 곳을 보면 된다.

 

○ ns-default.tcl:

다양한 network 구성요소들을 위한 구성 가능한 parameter에 대한 default 값들이 여기에 있다. network 구성요소의 대부분이 C++로 구현되었기 때문에, 구성 가능한 parameter들은 OTcl linkage 함수인 bind(C++_variable_name, OTcl_variable_name)를 경유하여 OTcl에 유용하게 만들어진 실제적인 C++ 변수들이다. C++ code로부터 OTcl linkage를 어떻게 만들 것인가 하는 것은 다음 section에서 기술된다.

 

○ ns-packet.tcl:

packet header format initialization implementation이 여기에 위치해 있다. 당신이 새로운 packet header를 생성할 때, 당신은 header stack format 속으로 당신의 header를 포함시키고, stack에 있는 당신의 header의 offset를 당신에게 주기 위한 packet header initialization process를 만들기 위해서 이 file내에 header를 등록해야 한다. 새로운 header 생성 예제는 "Add New Application and Agent" section에서 보여준다.

 

○ other OTcl files:

이 디렉토리에 있는 다른 OTcl file들은 network object를 조합한 OTcl 구현이나, C++에 있는 network의 front end(control part)를 포함한다. FTP응용은 OTcl에서 완벽하게 구현되어 있다. 그리고 source code는 "ns-source.tcl"에 위치해 있다.

특별한 시뮬레이션의 설계를 어떻게 하는지 알기를 원하는 user에게 흥미있는 tcl의 두 개의 sub-directories는 ex와 test이다. ex 디렉토리는 다양한 예제 시뮬레이션 script를 포함하고 있으며, test 디렉토리는 다양한 시뮬레이션을 동작시키고 예상된 결과와 그 결과를 비교함으로써 당신의 컴퓨터에 인스톨되어 있는 NS의 유효성을 시험하는 시뮬레이션 script를 포함한다.































4.2 OTcl Linkage

보통 새로운 기본적인 network object를 추가함으로써 NS를 확장시키는 것은 C++ code로부터 OTcl linkage를 만드는 일들을 포함한다. 따라서, data 경로에 있는 object class는 효율성 이유로 인해 C++로 쓰여져야 한다. 이 section은 어떤 agent 동작도 하지 않는(packet의 생성과 전송이 없는) "MyAgent"라 불리는 간단하고 둔한(dull) agent를 생성하는 예제를 줌으로써 NS에서 가용한 C++/OTcl linkage들을 소개한다. 그림 18~21은 함께 완벽한 구현(3 extra header line을 가지고)을 만드는 "MyAgent"에 대한 C++ source file의 일부를 보여준다. 또한, 당신이 "MyAgent"를 시험할 수 있는 OTcl script는 이 section의 말미에 표시되어 있다.

Export C++ class to OTcl

당신이 "Agent" class로부터 유도된 "MyAgent"라 부르는 C++ class에서 새로운 network class를 생성하고, OTcl에 있는 이 object의 instance를 생성하는 것이 가능하도록 하기를 원한다고 가정한다. 이것을 하기 위해서 당신은 "TclClass"로부터 유도되어야 하는 "MyAgentClass"라 부르는 linkage object를 정의해야 한다. 이 linkage object는 규정된 이름(이 예제에서는 "Agent/MyAgentOtcl")의 OTcl object를 생성한다. 그리고 OTcl object와 C++ object사이에 linkage를 생성한다. 그것의 instance launching procedure는 "create" member 함수에서 규정되어 있다. 그림 18.은 "MyAgent" class 정의와 linkage class 정의를 보여준다.

 


class MyAgent : public Agent {

public:

MyAgent();

protected:

int command(int argc, const char*const* argv);

private:

int my_var1;

double my_var2;

void MyPrivFunc (void);

};

 

static class MyAgentClass : public TclClass {

public:

MyAgentClass () : TclClass("Agent/MyAgentotcl") {}

TclObject* create(int, const char*const*) {

return(new MyAgent());

}

} class_my_agent;


fig 18. Example C++ Network Component and The Linkage Object

 


NS가 처음 시작될 때, 그것은 static variable "class_my_agent"에 대한 constructor 임무를 수행한다. 그래서 "MyAgentClass"의 instance가 생성된다. 리 process에서, "Agent/MyAgentOtcl" class와 그것의 적정한 method(member functions)는 OTcl space에서 생성된다. OTcl space에 있는 user가 "new Agent/MyAgentOtcl" 명령어를 이용하여 이 object의 instance를 생성하려고 할 때, 그것은 "MyAgent"의 instance를 생성하는 "MyAgentClass::create"를 부른다. 그리고 그 address를 되돌린다. OTcl로부터 C++ object instance를 생성하는 것은 당신이 member 함수를 부르고 (invoke), OTcl로부터 C++ object instance의 member 변수를 access할 수 있다는 것을 의미하는 것은 아니라는 점에 주목하라.

Export C++ class variables to OTcl

당신의 새로운 C++ object인 "MyAgent"는 당신이 input simulation script를 사용하여 OTcl로부터 쉽게 구성(혹은 변화)하기를 원하는 "my_var1"과 "my_var2"로 불리는 두 개의 parameter 변수를 가졌다고 가정하자. 이것을 하기 위해서 당신은 export하기를 원하는 각 C++ class 변수에 대한 binding 함수를 사용해야만 한다. binding 함수는 matching되는 OTcl object class("Agent/MyAgentOtcl")에서 주어진 이름(first argument)의 새로운 member 변수를 생성한다. 그리고, OTcl class 변수와 address가 두 번째 변수로 규정된 C++ 변수 사이에서 bi-directional bindings를 생성한다, 그림19는 그림 18에서 보여진 "my_var1"과 "my_var2"에 대한 binding을 만드는 방법을 보여준다.

 

그림 19. Variable Binding Creation Example

MyAgent::MyAgent() : Agent(PT_UDP) {

bind("my_var1_otcl", &my_var1);

bind("my_var2_otcl", &my_var2);

}

 

binding 함수는 이 object의 instance가 생성될 때 binding을 만들기 위해서 "MyAgent" constructor 함수에 놓이게 된다. NS는 다음과 같이 5개의 다른 변수 type에 대해 4개의 다른 binding 함수를 재공한다.

- bind() : real or integer variables

- bind_time() : time variable

- bind_bw() : bandwidth variable

- bind_bool() : boolean variable

이 방법에서, OTcl script를 사용하여 시뮬레이션을 설계하고 동작시키는 user는 C++로 구현된 network components의 configurable parameter(혹은 variable values)를 변경하거나 access할 수 있다. 당신이 C++ 변수를 export할 때마다, 당신이 "ns-2/tcl/lib/ns-lib.tcl" file에 있는 변수에 대한 default 값을 set 하는 것을 권고한다. 반면, 당신은 새로운 object의 instance를 생성할 때 경고 메시지를 보게될 것이다.

Export C++ Object COntrol Command to OTcl

약간의 C++ object 변수를 export하는 것에 부가하여, OTcl에 C++ object의 control을 주기를 원할지도 모른다. 이것은 OTcl 명령 인터프리터로 동작하는 C++ object("MyAgent")의 "command" member 함수를 정의함으로써 행해진다. 사실상, C++ object의 "command" member 함수에서 정의된 OTcl 함수는 user에게 matching OTcl object의 member 함수와 동일하게 보인다. 그림20은 그림18에 있는 'MyAgent"에 대한 "command" member 함수 정의예제를 보여준다.

 

그림 20. Example OTcl command interpreter

int MyAgent::command(int argc, const char*const* argv) {

if(argc ==2) {

if(strcmp(argv[1], "call-my-priv-func") == 0) {

MyPrivFunc();

return(TCL_OK);

}

}

return(Agent::command(argc, argv));

}



"MyAgent" object와 정합되는 shadow OTcl의 instance가 OTcl space(set myagent [new Agent/MyAgentOtcl] 등)에서 생성될 때, 그리고 user가 object의 member 함수를 호출( $myagent call-my-priv-func 등)하려고 할 때, OTcl은 OTcl object에서 주어진 member 함수 이름을 찾는다. 만일 주어진 member 함수 이름과 argc/argv format에 있는 인수가 발견되지 않을 때, 호출된 OTcl member 함수를 passing하는 "MyAgent::command"를 요청(invoke)한다. 만일 "command" member 함수 내에 invoke된 OTcl member 함수 이름에 대한 정의한 action이 있다면, 그것은 질문된 내용을 수행하고 그 결과를 되돌린다. 만일 그렇지 않다면, 그것의 조상(ancestor) object에 대한 "command" 함수는 그 이름이 찾아질 때까지 반복적으로 호출할 것이다. 만일 그 이름이 조상(ancestor)중에 어느 곳에서도 발견되지 않는다면, error message가 OTcl object로 되돌아 온다. 그리고 OTcl object는 user에게 error message를 준다. 이러한 방법으로 OTcl space에 있는 user는 C++ object의 동작을 제어할 수 있다.

Execute an OTcl command from C++

당신은 C++에 있는 새로운 network object를 구현함으로써, C++ object로부터 OTcl command를 실행하기를 원할 것이다. 그림 21은 그림 18에 있는 "MtAgent"의 member 함수인 "MyPrivFunc"의 구현을 보여준다. 그것은 OTcl interpreter가 "my_var1"과 "my_var2" private member 변수에 있는 값을 프린트하는 것을 만든다.

 

그림 21. Example OTcl command from a C++ Object

void MyAgent::MyPrivFunc(void) {

Tcl& tcl = Tcl::instance();

tcl.eval("puts \"Message From MyPrivFunc\" ");

tcl.evalf("puts \" my_var1 = %d\" ", my_var1);

tcl.evalf("puts \" my_var2 = %d\" ", my_var2);

}


C++로부터 OTcl command를 실행시키기 위해서, 당신은 static member 함수로 선언된 "Tcl:;instance()"에 대한 reference를 취해야 한다. 이것은 당신이 interpreter("MyPrivFunc"의 첫 라인이 이것을 한다)에게 OTcl command를 전달하도록 하는 couple 함수를 당신에게 제공한다. 이 예제는 OTcl command passing 함수의 완벽한 list에 대해서는 NS document를 참조하시오.


Compile, run and test "MyAgent"

지금까지, 우리는 "MyAgent" 예제를 사용하는 NS에서 유용한 essential OTcl linkage들을 시험했다. 이 예제를 running하고 testing하는 것이 독자의 이해를 더욱 돕는다고 가정하고, 우리는 당신이 "MyAgent"를 compile하고, 동작시키며 test하는 것을 돕는 절차를 보인다.

1. "ex-linkage.cc" file을 다운받고, 그것을 "ns-2" directory밑에 저장하라.

2. "Makefile" file을 열고, object file list의 끝에서 "ex-linkage.o"를 추가

3. "make" 명령을 사용하여 NS를 re-compile

4. OTcl 명령어들을 시험하는 "MyAgent"를 포함하는 "ex-linkage.tcl"을 down 받으라.(입력 script와 그 결과에 대해서는 그림 22를 보라)

5. "ns ex-linkage.tcl" 명령을 사용하여 OTcl script를 실행하라.

 

ex-linkage.tcl


# Create MyAgent (This will give two warning message that

# no default values exist for my_var1_otcl and my_var2_otcl)

set myagent [new Agent/MyAgentOtcl]

# Set configurable parameters of MyAgent

$myagent set my_var1_otcl 2

$myagent set my_var2_otcl 3.14

# Give a command to MyAgent

$myagent call-my-priv-func


result

warning: no class variable Agnet/MyAgentOtcl::my_var1_otcl

see tcl-object.tcl in tclcl for info about this warning.

warning: no class variable Agent/MyAgentOtcl::my_var2_Otcl

Message From MyPrivFunc

my_var1 = 2

my_var2 = 3.140000

그림 22. Test OTcl Script and The Result



 

 

 

4.3 Add New Application and Agent

Objective

우리는 UDP 연결 상에서 동작하는 multimedia application을 만들기 원한다. 그것은 encoding과 scale parameter 값과 연관이 있는 transmission policy pair을 변화시킴으로써 어떤 범위로 network congestion에 응답할 수 있는 "five rate media scaling"을 구현하는 imaginary multimedia application의 동작을 시뮬레이트 한다.

Application Description

이 구현에서, 연결이 설립될 때 sender와 receiver는 encoding과 transmission policy pair간에 5개의 다른 set에 대해 동의한다는 것을 가정한다. 그리고 그것들을 5개의 scale 값(0-4)으로 결합시킨다고 가정한다. 단순한 이유 때문에, constant transmission rate이 encoding과 transmission policy pair의 각각에 대해 역시 결정된다는 것을 가정한다. 그리고 모든 pair는 encoding scheme의 동일한 크기의 regardless의 packet을 사용한다.

기본적으로, "five rate media scaling"은 다음과 같이 동작한다. sender는 scale 0과 결합한 전송 속도로 출발한다. 그리고 수신측이 인지하는 scale 값에 따라서 전송속도를 변화한다. receiver는 network congestion을 monitor하고 scale factor를 결정할 책임이 있다. congestion monitoring을 위해 간단한 주기적(for every RTT second) packet loss monitoring이 사용된다. 그리고, 각 주기에 대한 단일 packet loss까지 network congestion으로 간주된다. 만일 congestion이 검출되면, receiver는 scale parameter 값을 반으로 감소시키며, 이 값을 sender에게 알린다. 만일, 아무 packet loss가 검출되지 않으면 receiver는 1만큼 그 값을 증가시키며 그것을 sender에게 알린다.

Problem Analysis

이 응용을 구현하기 전에, UDP agent 구현이 시험되고 하나의 major 문제가 발견된다. UDP agent가 network packet을 할당하고 전송하기 때문에, application level communication에 필요한 모든 정보는 data stream으로서 UDP agent로 조정되어야 한다. 그러나, UDP 구현은 header stack만을 갖는 packet를 할당한다. 그러므로, 우리는 응용으로부터 수신된 data를 전송하는 mechanism을 추가하기 위한 UDP 구현을 modify 해야할 필요가 있다. 그것은 또한 IP router queue management mechanism 상에서 향후의 연구를 위해 이 응용을 사용하기를 원한다는 점을 주목하시오. 그러므로, 우리는 다른 stream type으로부터 multimedia stream type을 구별하기 위한 방법이 필요하다. 그것은 우리가 또한 현재 사용되지 않고 있는 IP header field의 하나에 data type을 기록하기 위한 UDP agent를 변경할 필요가 있다는 것이다.

Design and Implementation

응용에 대해서, 우리는 CBR 구현을 취하고 그것을 "five media scaling" 특징을 갖도록 변형할 것을 결정했다. 우리는 C++ hierachy를 시험하고 이 응용의 class를 "MmApp"로 명명하고, "Application"의 child class로 구현할 것을 결정했다. matching되는 OTcl hierachy 이름은 "Application/MmApp"이다.

application의 sender와 receiver의 동작은 "MmApp"에서 함께 구현된다. "MmApp"를 제공하는 변형된 UDP agent에 대해서, 우리는 "UdpAmAgent"로 명명하고, "UdpAgent"의 child class로 그것을 구현할 것을 결정했다. matching되는 OTcl hierachy 이름은 "Agent/UDP/UDPmm"이다.

 

○ MmApp Header:

application level의 통신을 위해, 우리는 structure가 C++에서 "hdr_mm"로 명명한 header를 정의할 것을 결정했다. application이 전송할 정보를 가질 때마다, 그것은 "hdr_mm" structure format에 있는 "UdpMmAgent"로 그것을 전달한다. 그때, "UdpMmAgent"는 하나 혹은 그 이상의 packet(시뮬레이트된 data packet size에 달려있는)을 할당하고, 그 data를 각 packet의 multimedia header에 기록한다. 그림 23은 header와 header class object에 대한 구조 내부에서 "PacketHeaderClass"로부터 추출되어야 하는 "MultimediaHeaderClass"가 정의되어야 한다는 header 정의를 보여준다. 이 class를 정의하는 데 있어서, header("PacketHeader/Multimedia")에 대한 OTcl 이름과 jd의된 header structure의 크기가 나타나 있다.


C++에 있는 header를 정의한 뒤에, 우리는 새로운 header offset OTcl 변수 이름으로 "off_mm_"로 정하고, 그림 24에서 보는바와 같이 OTcl header와 "ns-packet.tcl"로 offset 변수 이름 pair를 부가하였다. 이것은 header stack format속으로 당신의 header를 포함하는 NS를 만들고, 주어진 offset 변수로 stack에 있는 당신의 header의 offset을 저장할 것이다.


header 생성 process가 끝난 시점에서, 그리고 "UdpMmAgent"가 변수를 정의함으로써 새로운 header를 access하고 "off_mm_" OTcl 변수로 그것을 bind할 것이다. 응용의 나머지 부분과 변형된 UDP agent description에 대해서는 "mm-app.h", "mm-app.cc", "udp-mm.h"와 "udp-mm.cc"를 참조하라.


 

ㅇ MmApp Sender:

sender는 다음 응용 data packet 전송을 scheduling하기 위해 timer를 사용한다. 우리는 "TimeHandler" class로부터 유도한 "SendTimer" class를 정의했다. 그리고, "MmApp" objectfml "send_mm_pkt()" member 함수를 호출하기 위해 그것의 "expire()" member 함수 write했다. 그때, 우리는 "snd_timer_" 만큼 관련된 "MmApp"의 private member로서 이 object의 instance를 포함했다. 그림 25는 "SendTimer" 구현을 보여준다.

 

이 timer를 setting하기 전에, "MmApp"는 입력 simualtion script(or use the default size)에서 주어진 응용 data packet의 크기와 현재 scale value와 관련된 전송 rate를 사용하는 next transmission time을 재 계산한다. ACK 응용 packet이 수신측으로부터 도착할 때 "MmApp" sender는 scale parameter를 갱신한다.

 

 

○ MmApp Receiver:

receiver는 interval이 평균 RTT와 동일한 next application ACK packet 전송을 schedule하기 위해서 "ack_timer_"로 이름지어진 timer를 사용한다. receiver는 sender로부터 응용 data packet을 수신할 때, 수신된 packet의 수를 count하고, packet sequence number를 사용하는 lost packet의 수를 count한다. "ack_timer_"가 초과할 때, 그것은 수신된 그리고 lost된 packet accounting 정보를 주시하는 scale value를 조정하는 "MmApp"의 "send_ack_pkt" member 함수를 불러내고, 수신된 그리고 lost된 count를 0으로 reset하며, 조정된 scale value로 ACK packet을 전송한다. receiver는 어떤 연결 수립이나 절단 method를 갖고있지 않다. 그러므로, first packet arrival로부터 start함으로써, receiver는 주기적으로 ACK packet을 전송하고 절대 stop하지 않는다.(이것은 bug이다.)

 

○ UdpMmAgent:

"UdpMmAgent"는 다음과 같은 부가적인 특징을 갖는 "UdpAgent"로부터 갱신된다.

(1) "MmApp"로부터 수신된 정보를 전송되고 있는 data packet MM header에 writing 하는 것(혹은 수신된 data packet MM header로부터 정보를 읽고 있는)

(2) segmentation과 re-assembly("UdpAgent"는 segmentation만을 구현한다.)

(3) "MmApp" packet을 위해 15(max priority)까지 priority bit(IPv6)를 setting

 

○ Modify "agent.h":

당신의 NS distribution으로 동작하는 새로운 application과 agent를 만들기 위해서, 당신은 "Agent" class를 public으로 하는 두 개의 methods를 부가해야 한다.


"MmApp"의 "command" member 함수에서, "attach-agent" OTcl command가 정의되어 있다. 이 명령이 OTcl로부터 수신될 때, "MmApp"는 그 자신이 underlying agent로 접속하도록 노력한다. 접속 전에, 그것은 underlying agent가 멀티미디어 전송(응용에서 응용으로 data를 옮길 수 있는지 등등)을 지원하는지를 점검하기 위해서 underlying agent의 "supportMM()" member 함수를 불러낸다. 그리고, 만일 그것이 행해진다면 "enableMM()"을 불러낸다. 비록 이 두 개의 member 함수가 "UdpMmAgent" class에 정의되어 있지만, 그것은 그것의 base 조상(ancestor) "Agent" class에 정의되지 않고, 일반적인 "Agent" class의 두 member 함수들이 호출된다. 그러므로, 그 code를 compile하려고 할 때, 그것은 error message를 줄 것이다. 다음과 같은 "Agent" class(in "agent.h")의 public member 함수로서 두 methods를 삽입함으로써, 이 문제를 해결할 것이다.

 

 

○ Set default values for new parameter in the "ns-default.tcl":

응용과 agent의 모든 부분을 구현한 뒤에, 마지막으로 할 일은 "ns-default.tcl" file에 있는 새롭게 소개된 configurable parameter에 대한 default 값을 set하는 것이다. 그림 26은 "MmApp"에 의해 소개된 configurable parameter에 대한 default 값을 setting하는 예를 보여준다.

 

Download and Compile

여기에 당신의 NS를 compile하기 전에 해야하는 checklist가 있다.

1. "ns-2" 디렉토리로 "mm-app.h", "mm-app.cc", "udp-mm.h" and "udp-mm.cc"를 download하라.

2. 상기에 규정된 것처럼 "ns-packet.tcl"에서 새로운 응용 header를 등록했는지 확인하라.

3. 상기에 규정된 것처럼 "agent.h" file에서 "Agent" class로 두 개의 method를 부가하라.

4. 상기에 기술한 바와 같이 "ns-default.tcl"에 있는 새롭게 소개된 configurable parameter에 대한 default 값을 Set하라.

이 checklist에 있는 모든 것을 행한 후에, 필요한 만큼(object file list에 있는 "mm-app.o"와 "udp-mm.o"를 포함하여) "Makefile"를 갱신하고, NS를 re-compile하라. 일반적으로 re-compile하기 전에 "Makefile"에서 변경을 한 후에 "make depend"를 하는 것은 훌륭한 실습이다.

Test Simulation

그림28은 "MmApp"를 시험하는데 사용되는 시뮬레이션 topology와 scenario를 보여준다. 그리고 그림 29는 test 시뮬레이션 script를 보여준다. 이 script를 down 받고 새롭게 부가된 component를 시험하라.



 

그림 29. "MmApp" Test Simulation Script

# Author: Jae Chung

# Date: 7/17/99

#

#

# s1 s3

# \ /

# 5Mb,3ms \ 2Mb,10ms / 5Mb,3ms

# r1 --------- r2

# 5Mb,3ms / \ 5Mb,3ms

# / \

# s2 s4

#

set ns [new Simulator]

#Define different colors for data flows

$ns color 1 Red

$ns color 2 Blue

#Open the nam trace file

set nf [open out.nam w]

set tf [open out.tr w]

$ns namtrace-all $nf

$ns trace-all $tf

#Define a 'finish' procedure

proc finish {} {

global ns nf tf

$ns flush-trace

#Close the trace file

close $nf

close $tf

#Execute nam on the trace file

exec nam out.nam &

exit 0

}

set node_(s1) [$ns node]

set node_(s2) [$ns node]

set node_(r1) [$ns node]

set node_(r2) [$ns node]

set node_(s3) [$ns node]

set node_(s4) [$ns node]

$ns duplex-link $node_(s1) $node_(r1) 5Mb 3ms DropTail

$ns duplex-link $node_(s2) $node_(r1) 5Mb 3ms DropTail

$ns duplex-link $node_(r1) $node_(r2) 2Mb 10ms RED

$ns duplex-link $node_(s3) $node_(r2) 5Mb 3ms DropTail

$ns duplex-link $node_(s4) $node_(r2) 5Mb 3ms DropTail

#Setup RED queue parameter

$ns queue-limit $node_(r1) $node_(r2) 20

Queue/RED set thresh_ 5

Queue/RED set maxthresh_ 10

Queue/RED set q_weight_ 0.002

Queue/RED set ave_ 0

$ns duplex-link-op $node_(r1) $node_(r2) queuePos 0.5

$ns duplex-link-op $node_(s1) $node_(r1) orient right-down

$ns duplex-link-op $node_(s2) $node_(r1) orient right-up

$ns duplex-link-op $node_(r1) $node_(r2) orient right

$ns duplex-link-op $node_(s3) $node_(r2) orient left-down

$ns duplex-link-op $node_(s4) $node_(r2) orient left-up

#Setup a MM UDP connection

set udp_s [new Agent/UDP/UDPmm]

set udp_r [new Agent/UDP/UDPmm]

$ns attach-agent $node_(s1) $udp_s

$ns attach-agent $node_(s3) $udp_r

$ns connect $udp_s $udp_r

$udp_s set packetSize_ 1000

$udp_r set packetSize_ 1000

$udp_s set fid_ 1

$udp_r set fid_ 1

#Setup a MM Application

set mmapp_s [new Application/MmApp]

set mmapp_r [new Application/MmApp]

$mmapp_s attach-agent $udp_s

$mmapp_r attach-agent $udp_r

$mmapp_s set pktsize_ 1000

$mmapp_s set random_ false

#Setup a TCP connection

set tcp [$ns create-connection TCP/Reno $node_(s2) TCPSink $node_(s4) 0]

$tcp set window_ 15

$tcp set fid_ 2

#Setup a FTP Application

set ftp [$tcp attach-source FTP]

#Simulation Scenario

$ns at 0.0 "$ftp start"

$ns at 1.0 "$mmapp_s start"

$ns at 7.0 "finish"

$ns run





 

 

 

4.4 Add New Queue

Objective

간단한 drop-tail을 만들기 위해 router는 ("MmApp" over "UDPmm"으로부터) priority 15 packets와 queue에서 공존하는 다른 packet들에 대한 round-robin dequeue scheduling을 사용하는 queue를 출력한다. 그것은 각 type의 가장 오래된 packet와 일대 일로 번갈아 dequeue한다.

 

Design

queue는 total size가 physical queue(PQ)의 크기와 동일한(LQ1+LQ2=PQ 등) LQ1과 LQ2라고 하는 두 개의 logical FIFO queue를 가지고 있다.

normal drop-tail enqueue 동작을 구현하기 위해서, packet이 enqueue될 때, enqueue manager는 LQ1+LQ2의 크기가 허용된 PQ의 최대 크기보다 작은지를 검사한다. 만일 그렇다면, packet은 적당한 logical queue로 enqueue될 것이다.

round-robin dequeue scheduling을 구현하기 위해서, dequeue manager는 한 logical queue로부터 하나의 packet을 dequeue하고 차례로 다른 logical queue로부터 다음 packet을 dequeue하려고 한다. 만일 양 queue가 모두 packet을 가졌다면, 두 개의 logical queue에 있는 packet들은 1:1의 비율로 dequeue된다.

 

Implementation

우리는 이 queue object에 대한 C++ 이름을 "Queue" class로부터 유도된 "DtRrQueue"(Drop-Tail Round_Robin Queue)라 명명했다. matching되는 OTcl 이름은 "Queue/DTRR"이다. "Queue" class에서(in "queue.cc") 구현된 "recv" member 함수가 packet을 수신할 때, 그것은 queue object이 "enqueue" member 함수를 호출하고, link object가 block되지 않는다면 "dequeue"를 호출한다. link가 block된 상태로부터 나왔을 때, 그것은 또한 그것의 queue object의 "dequeue" member 함수를 호출한다. 그러므로, 우리는 "DtRrQueue" object class의 member 함수 "enqueue"와 "dequeue"를 쓸 필요가 있다. 그림 30은 "DtRrQueue" class 정의와 "enqueue"와 "dequeue" member 함수를 보여준다. 완전한 구현을 위해서, "dtrr-queue.h"와 "dtrr-queue.c" file을 참고하라. 이 code는 실제로 이해하기에 쉽기 때문에 더 이상의 설명은 없다.

 

dtrr-queue.h

// Author: Jae Chung

// Date: 7/19/99, File: dtrr-queue.h

#include <string.h>

#include "queue.h"

#include "address.h"

class DtRrQueue : public Queue {

public:

DtRrQueue() {

q1_ = new PacketQueue;

q2_ = new PacketQueue;

pq_ = q1_;

deq_turn_ = 1;

bind("off_ip_", &off_ip_);

}

protected:

void enque(Packet*);

Packet* deque();

PacketQueue *q1_; // First FIFO queue

PacketQueue *q2_; // Second FIFO queue

int deq_turn_; // 1 for First queue 2 for Second

int off_ip_;

};


 

dtrr-queue.cc

// Author: Jae Chung

// Date: 7/19/99, File: dtrr-queue.cc

#include "dtrr-queue.h"

static class DtRrQueueClass : public TclClass {

public:

DtRrQueueClass() : TclClass("Queue/DTRR") {}

TclObject* create(int, const char*const*) {

return (new DtRrQueue);

}

} class_dropt_tail_round_robin;

void DtRrQueue::enque(Packet* p)

{

hdr_ip* iph = (hdr_ip*)p->access(off_ip_);

// if IPv6 priority = 15 enqueue to queue1

if (iph->prio_ == 15) {

q1_->enque(p);

if ((q1_->length() + q2_->length()) > qlim_) {

q1_->remove(p);

drop(p);

}

}

else {

q2_->enque(p);

if ((q1_->length() + q2_->length()) > qlim_) {

q2_->remove(p);

drop(p);

}

}

}


 

dtrr-queue.cc


Packet* DtRrQueue::deque()

{

Packet *p;

if (deq_turn_ == 1) {

p = q1_->deque();

if (p == 0) {

p = q2_->deque();

deq_turn_ = 1;

}

else {

deq_turn_ = 2;

}

}

else {

p = q2_->deque();

if (p == 0) {

p = q1_->deque();

deq_turn_ = 2;

}

else {

deq_turn_ = 1;

}

}

return (p);

}

그림 30. "DtRrQueue" class implementation

 

 

Test Simulation

우리는 앞의 section에서 링크 r1-r2에 대해 RED queue를 DTRR queue로 바꿈으로써, "UDPmm"상의 "MmApp" 시험을 위해 사용된 simulation script를 사용했다. 이 script를 down 받고 새롭게 부가된 queue component를 시험하라.


그림 31. "DtRrQueue" test simulation script


# Author: Jae Chung, Date: 7/17/99

# s1 s3

# \ /

# 5Mb,3ms \ 2Mb,10ms / 5Mb,3ms

# r1 --------- r2

# 5Mb,3ms / \ 5Mb,3ms

# / \

# s2 s4

set ns [new Simulator]

#Define different colors for data flows

$ns color 1 Red

$ns color 2 Blue

#Open the nam trace file

set nf [open out.nam w]

set tf [open out.tr w]

$ns namtrace-all $nf

$ns trace-all $tf

#Define a 'finish' procedure

proc finish {} {

global ns nf tf

$ns flush-trace

#Close the trace file

close $nf

close $tf

#Execute nam on the trace file

exec nam out.nam &

exit 0

}

set node_(s1) [$ns node]

set node_(s2) [$ns node]

set node_(r1) [$ns node]

set node_(r2) [$ns node]

set node_(s3) [$ns node]

set node_(s4) [$ns node]

$ns duplex-link $node_(s1) $node_(r1) 5Mb 3ms DropTail

$ns duplex-link $node_(s2) $node_(r1) 5Mb 3ms DropTail

$ns duplex-link $node_(r1) $node_(r2) 2Mb 10ms DTRR

$ns duplex-link $node_(s3) $node_(r2) 5Mb 3ms DropTail

$ns duplex-link $node_(s4) $node_(r2) 5Mb 3ms DropTail

#Set DTRR queue size to 20

$ns queue-limit $node_(r1) $node_(r2) 20

$ns duplex-link-op $node_(r1) $node_(r2) queuePos 0.5

$ns duplex-link-op $node_(s1) $node_(r1) orient right-down

$ns duplex-link-op $node_(s2) $node_(r1) orient right-up

$ns duplex-link-op $node_(r1) $node_(r2) orient right

$ns duplex-link-op $node_(s3) $node_(r2) orient left-down

$ns duplex-link-op $node_(s4) $node_(r2) orient left-up

#Setup a MM UDP connection

set udp_s [new Agent/UDP/UDPmm]

set udp_r [new Agent/UDP/UDPmm]

$ns attach-agent $node_(s1) $udp_s

$ns attach-agent $node_(s3) $udp_r

$ns connect $udp_s $udp_r

$udp_s set packetSize_ 1000

$udp_r set packetSize_ 1000

$udp_s set fid_ 1

$udp_r set fid_ 1

#Setup a MM Application

set mmapp_s [new Application/MmApp]

set mmapp_r [new Application/MmApp]

$mmapp_s attach-agent $udp_s

$mmapp_r attach-agent $udp_r

$mmapp_s set pktsize_ 1000

$mmapp_s set random_ false

#Setup a TCP connection

set tcp [$ns create-connection TCP/Reno $node_(s2) TCPSink $node_(s4) 0]

$tcp set window_ 15

$tcp set fid_ 2

#Setup a FTP Application

set ftp [$tcp attach-source FTP]

#Simulation Scenario

$ns at 0.0 "$ftp start"

$ns at 1.0 "$mmapp_s start"

$ns at 7.0 "finish"

$ns run



















5. More Examples

 

 

5.1 LAN Example

이 절은 예제 LAN simulation script에 pointer를 포함한다. 그리고, 그것의 network topology와 simulation scenario를 보여준다. "ns-2/tcl/ex/lantest.tcl"로부터 약간 변형된 "ex-lan.tcl" file을 down 받고, 그것을 시험해 보라.

 

 

ex-lan.tcl


# Author: Jae Chung

# Date: 7/20/99

#

# This file is modified from

# "ns-2/tcl/ex/lantest.tcl"

set opt(tr)"out.tr"

set opt(namtr)"out.nam"

set opt(seed)0

set opt(stop)5

set opt(node)8

set opt(qsize)100

set opt(bw)10Mb

set opt(delay)1ms

set opt(ll)LL

set opt(ifq)Queue/DropTail

set opt(mac)Mac/Csma/Ca

set opt(chan)Channel

set opt(tcp)TCP/Reno

set opt(sink)TCPSink

set opt(app)FTP

proc finish {} {

global ns opt trfd ntrfd

$ns flush-trace

close $trfd

close $ntrfd

exec nam $opt(namtr) &

exit 0

}

proc create-trace {} {

global ns opt

set trfd [open $opt(tr) w]

$ns trace-all $trfd

return $trfd

}

proc create-namtrace {} {

global ns opt

set ntrfd [open $opt(namtr) w]

$ns namtrace-all $ntrfd

}

proc create-topology {} {

global ns opt

global lan node source node0

set num $opt(node)

for {set i 0} {$i < $num} {incr i} {

set node($i) [$ns node]

lappend nodelist $node($i)

}

set lan [$ns newLan $nodelist $opt(bw) $opt(delay) \

-llType $opt(ll) -ifqType $opt(ifq) \

-macType $opt(mac) -chanType $opt(chan)]

set node0 [$ns node]

$ns duplex-link $node0 $node(0) 2Mb 2ms DropTail

$ns duplex-link-op $node0 $node(0) orient right

}

## MAIN ##

set ns [new Simulator]

set trfd [create-trace]

set ntrfd [create-namtrace]

create-topology

set tcp0 [$ns create-connection TCP/Reno $node0 TCPSink $node(7) 0]

$tcp0 set window_ 15

set ftp0 [$tcp0 attach-app FTP]

$ns at 0.0 "$ftp0 start"

$ns at $opt(stop) "finish"

$ns run




 

 

5.2 Multicasting Example

이 section은 example multicasting simulation script에 pointer를 포함하고 시뮬레이션의 NAM screen capture를 보여준다. "ex-mcast.tcl" file을 down 받고, 그것을 시험해 보라. 이 예제는 5소 VINT/NS Simulator Tutorial/Workshop로부터 가져 왔다.



 

 

ex-mcast.tcl

# Polly Huang 8-7-98

set ns [new Simulator]

$ns multicast

set f [open out.tr w]

$ns trace-all $f

$ns namtrace-all [open out.nam w]

$ns color 1 red

# prune/graft packets

$ns color 30 purple

$ns color 31 green

set n0 [$ns node]

set n1 [$ns node]

set n2 [$ns node]

set n3 [$ns node]

# Use automatic layout

$ns duplex-link $n0 $n1 1.5Mb 10ms DropTail

$ns duplex-link $n1 $n2 1.5Mb 10ms DropTail

$ns duplex-link $n1 $n3 1.5Mb 10ms DropTail

$ns duplex-link-op $n0 $n1 orient right

$ns duplex-link-op $n1 $n2 orient right-up

$ns duplex-link-op $n1 $n3 orient right-down

$ns duplex-link-op $n0 $n1 queuePos 0.5

set mrthandle [$ns mrtproto DM {}]

set cbr0 [new Application/Traffic/CBR]

set udp0 [new Agent/UDP]

$cbr0 attach-agent $udp0

$ns attach-agent $n1 $udp0

$udp0 set dst_ 0x8001

set cbr1 [new Application/Traffic/CBR]

set udp1 [new Agent/UDP]

$cbr1 attach-agent $udp1

$udp1 set dst_ 0x8002

$udp1 set class_ 1

$ns attach-agent $n3 $udp1

set rcvr [new Agent/LossMonitor]

#$ns attach-agent $n3 $rcvr

$ns at 1.2 "$n2 join-group $rcvr 0x8002"

$ns at 1.25 "$n2 leave-group $rcvr 0x8002"

$ns at 1.3 "$n2 join-group $rcvr 0x8002"

$ns at 1.35 "$n2 join-group $rcvr 0x8001"

$ns at 1.0 "$cbr0 start"

$ns at 1.1 "$cbr1 start"

$ns at 2.0 "finish"

proc finish {} {

global ns

$ns flush-trace

puts "running nam..."

exec nam out.nam &

exit 0

}

$ns run








 

 

 


5.3 Web Server Example

이 section은 예제 Web Server 시뮬레이션 script에 pointer를 포함하고, 그 network topology를 보여준다. "ex-web.tcl"과 "dumbbell.tcl" file을 down 받고, 그것들을 시험해 보라. 당신은 당신의 machine에서 그것을 동작하게 하기 위해서 script의 시작 부분에서 "http-mod.tcl"에 대한 path를 변경해야한다는 점에 주의하라.


 

 

 

 

dumbbell.tcl

# Polly Huang 8-7-98

# Initial setup

source ~/ns-allinone-2.1b4a/ns-2/tcl/http/http-mod.tcl

source dumbbell.tcl

global num_node n

set ns [new Simulator]

$ns set-address 7 24 ;# set-address <bits for node address> <bits for port>

# set up colors for nam

for {set i 1} {$i <= 30} {incr i} {

set color [expr $i % 6]

if {$color == 0} {

$ns color $i blue

} elseif {$color == 1} {

$ns color $i red

} elseif {$color == 2} {

$ns color $i green

} elseif {$color == 3} {

$ns color $i yellow

} elseif {$color == 4} {

$ns color $i brown

} elseif {$color == 5} {

$ns color $i black

}

}

# Create nam trace and generic packet trace

$ns namtrace-all [open out.nam w]

# trace-all is the generic trace we've been using

$ns trace-all [open out.tr w]

create_topology

########################### Modify From Here #####################

## Number of Pages per Session

set numPage 10

set httpSession1 [new HttpSession $ns $numPage [$ns picksrc]]

set httpSession2 [new HttpSession $ns $numPage [$ns picksrc]]

## Inter-Page Interval

## Number of Objects per Page

## Inter-Object Interval

## Number of Packets per Object

## have to set page specific attributes before createPage

## have to set object specific attributes after createPage

$httpSession1 setDistribution interPage_ Exponential 1 ;#in sec

$httpSession1 setDistribution pageSize_ Constant 1 ;# number of objects/page

$httpSession1 createPage

$httpSession1 setDistribution interObject_ Exponential 0.01 ;# in sec

$httpSession1 setDistribution objectSize_ ParetoII 10 1.2 ;# number of packets

# uses default

$httpSession2 createPage

$ns at 0.1 "$httpSession1 start" ;# in sec as well

$ns at 0.2 "$httpSession2 start"

$ns at 30.0 "finish"

proc finish {} {

global ns

$ns flush-trace

puts "running nam..."

# exec to run unix command

exec nam out.nam &

exit 0

}

# Start the simualtion

$ns run

# Created by Polly Huang

# Simple 4-node star topology

# 8 7 2 3

# \ | | /

# 9 -- 1 ----- 0 -- 4

# / | | \

# 10 11 6 5

proc create_topology {} {

global ns n num_node

set num_node 12

for {set i 0} {$i < $num_node} {incr i} {

set n($i) [$ns node]

}

$ns set src_ [list 2 3 4 5 6]

$ns set dst_ [list 7 8 9 10 11]

# EDGES (from-node to-node length a b):

$ns duplex-link $n(0) $n(1) 1.5Mb 40ms DropTail

$ns duplex-link $n(0) $n(2) 10Mb 20ms DropTail

$ns duplex-link $n(0) $n(3) 10Mb 20ms DropTail

$ns duplex-link $n(0) $n(4) 10Mb 20ms DropTail

$ns duplex-link $n(0) $n(5) 10Mb 20ms DropTail

$ns duplex-link $n(0) $n(6) 10Mb 20ms DropTail

$ns duplex-link $n(1) $n(7) 10Mb 20ms DropTail

$ns duplex-link $n(1) $n(8) 10Mb 20ms DropTail

$ns duplex-link $n(1) $n(9) 10Mb 20ms DropTail

$ns duplex-link $n(1) $n(10) 10Mb 20ms DropTail

$ns duplex-link $n(1) $n(11) 10Mb 20ms DropTail

$ns duplex-link-op $n(0) $n(1) orient left

$ns duplex-link-op $n(0) $n(2) orient up

$ns duplex-link-op $n(0) $n(3) orient right-up

$ns duplex-link-op $n(0) $n(4) orient right

$ns duplex-link-op $n(0) $n(5) orient right-down

$ns duplex-link-op $n(0) $n(6) orient down

$ns duplex-link-op $n(1) $n(7) orient up

$ns duplex-link-op $n(1) $n(8) orient left-up

$ns duplex-link-op $n(1) $n(9) orient left

$ns duplex-link-op $n(1) $n(10) orient left-down

$ns duplex-link-op $n(1) $n(11) orient down

}

# end of create_topology




 

 

 

6. Hot Links

○ VINT Project Home Page: http://netweb.usc.edu/vint

○ NS Home Page: http://www-mash.cs.berkeley.edu/ns

○ NS Installation: http://www-mash.cs.berkeley.edu/ns/ns-build.html

○ NS Documentation: http://www-mash.cs.berkeley.edu/ns/ns-documentation.html

○ NS Manual Page (very out of date): http://www-mash.cs.berkeley.edu/ns/ns-man.html

○ NS CVS history (directory structure): http://www-mash.cs.berkeley.edu/cgi-bin/cvsweb

○ NS Class Hierarchy: http://www-sop.inria.fr/rodeo/personnel/Antoine.Clerget/ns

○5th VINT/NS Simulator Tutorial/Workshop: http://www-mash.cs.berkeley.edu/ns/ucb-tutorial.html

○ Tcl/Tk Quick Reference Guide: http://www.slac.stanford.edu/~raines/tkref.html

○ OTcl Tutorial (Berkeley Version): http://bmrc.berkeley.edu/research/cmt/cmtdoc/otcl

○ OTcl Tutorial (MIT Version): ftp://ftp.tns.lcs.mit.edu/pub/otcl/README.html

○ Guide to awk: http://www.canberra.edu.au/~sam/whp/awk-guide.html

○ GNU Plot: http://shazam.econ.ubc.ca/gnuplot.html

○ XGraph: http://jean-luc.ncsa.uiuc.edu/Codes/xgraph

○ Network Animator (NAM): http://www-mash.cs.berkeley.edu/nam/nam.html

 

contribution : Rahul Pradhan - SRM Example