노드는 아래 그림과 같이 node entry object와 classifiers로 구성된 복합 object이다. NS에는 두가지 타입의 노드가 있다.
[unicast node] unicast routing과 port classifier의 역할을 하는 address classifier를 갖는다.
[multicast node] unicast 패킷으로부터 multicast 패킷을 분류하고 classifier와 multicast routing을 수행하는 multicast classfier를 갖는다.
Node (Unicast and Multicast)
NS에서는 unicast node가 디폴트 노드이다. multicast node를 생성하기 위해 사용자는 OTcl 스크립트를 명확히 알아야 하며 scheduler object를 생성한후 모든 노드들은 multicast node로 생성되어야 한다. 노드 타입을 명확히 한후에 사용자는 디폴트로 사용하던것보다 구체적인 routing protocol을 선택할수 있다.
Multicast - $ns multicast (right after set $ns [new Scheduler]) - $ns mrtproto [type] - type : CtrMcast, DM, ST, BST
2. Link
사용자가 simulator object의 멤버함수인 duplex-link를 사용하여 link를 생성하고자 할때, simplex links는 아래와 같이 생성된다.
Link
한가지 주의할 것은 노드의 output queue는 simplex link object의 일부분으로서 수행된다. 패킷은 link delay를 시뮬레이트하는 Delay object로 넘겨진 queue로부터 dequeue된다. 그리고 queue에서 drop된 패킷들은 Agent/Null로 보내지고 그곳에서 버려진다. TTL object는 수신된 각 패킷을 위해 Time To Live 파라미터를 계산하고, 패킷의 TTL field를 업데이트한다.
Tracing
NS에서 네트워크의 활동은 simplex links 여기저기를 추적하는 일이다. 만약 시뮬레이터에서 네트워크의 행동을 추적하도록 지시되었다면($ns trace-all file or $ns namtrace-all file), links는 아래 그림에서 보듯이 그 명령이 trace object 다음에 온후에 생성된다. 사용자는 create-trace {type file src dst} 명령을 사용하여 주어진 source와 destination 노드간의 type 형태의 trace objects를 생성할수 있다.
Inserting Trace Objects
각 삽입된 trace object (i.e. EnqT, DeqT, DrpT and RecvT)가 패킷을 수신할때, 다른 어떤 시뮬레이션 시간 소비없이 명시된 trace file을 write하고, 패킷을 다음 네트워크 object에서 넘긴다.
Queue Monitor
근본적으로, tracing objects는 자신이 위치한곳에서 패킷의 도착시간을 기록하도록 고안되었다. 비록 사용자가 trace로부터 충분한 정보를 얻더라도, 누군가가 특정 output queue 내부에서 무엇이 진행중인지 알고싶어한다. 예를들어, RED queue행동에 관심있는 사용자가 평균 queue size의 dynamics(?)와 현재 특정 RED queue의 queue size를 측정하기 바랄수있다. (즉, queue 모니터링이 필요하다) queue 모니터링은 다음그림과 같이 queue monitor objects와 snoop queue objects를 사용하여 이룰수 있다.
Monitoring Queue
패킷이 도착할때 snoop queue object는 이 상황을 queue monitor object에게 통보한다. 이러한 정보를 사용하는 queue monitor는 queue를 모니터한다. snoop queue object는 그림에 나오진 않았지만, tracing object와 같이 사용할수 있다는걸 명심해라.
♡ Packet Flow Example
The network consist of two nodes (n0 and n1) of which the network addresses are 0 and 1 respectively. A TCP agent attached to n0 using port 0 communicates with a TCP sink object attached to n1 port 0. Finally, an FTP application (or traffic source) is attached to the TCP agent, asking to send some amount of data.
Packet Flow Example
Note that the above figure does not show the exact behavior of a FTP over TCP. It only shows the detailed internals of simulation network setup and a packet flow.
set ns [new Simulator] : generates an NS simulator object instance, and assigns it to variable ns (italics is used for variables and values in this section).
What this line does is the following:
Initialize the packet format (ignore this for now)
Create a scheduler (default is calendar scheduler)
Select the default address format (ignore this for now) The "Simulator" object has member functions that do the following:
Create compound objects such as nodes and links
Connect network component objects created (ex. attach-agent)
Set network component parameters (mostly for compound objects)
Create connections between agents (ex. between a "tcp" and "sink")
Specify NAM display options
Etc.
Most of member functions are for simulation setup (referred to as plumbing functions in the Overview section) and scheduling, however some of them are for the NAM display. The "Simulator" object member function implementations are located in the "usr/local/ns-2/ns-2.31/tcl/lib/ns-lib.tcl" file.
#Define different colors for data flows (for NAM) $ns color 1 Blue $ns color 2 Red
more..
$ns color fid color : is to set color of the packets for a flow specified by the flow id (fid). This member function of "Simulator" object is for the NAM display, and has no effect on the actual simulation.
#Open the NAM trace file set nf [open out.nam w] $ns namtrace-all $nf
more..
$ns namtrace-all [file-descriptor] : This member function tells the simulator to record simulation traces in NAM input format. It also gives the file name that the trace will be written to later by the command $ns flush-trace. Similarly, the member function trace-all is for recording the simulation trace in a general format.
#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 }
more..
proc finish {}: is called after this simulation is over by the command $ns at 5.0 "finish". In this function, post-simulation processes are specified.
#Create four nodes set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node]
more..
set n0 [$ns node]: The member function node creates a node. A node in NS is compound object made of address and port classifiers (described in a later section). Users can create a node by separately creating an address and a port classifier objects and connecting them together. However, this member function of Simulator object makes the job easier. To see how a node is created, look at the files: "usr/local/ns-2/ns-2.31/tcl/lib/ns-lib.tcl" and "usr/local/ns-2/ns-2.31/tcl/lib/ns-node.tcl".
$ns duplex-link [node1] [node2] [bandwidth] [delay] [queue-type] : creates two simplex links of specified bandwidth and delay, and connects the two specified nodes. In NS, the output queue of a node is implemented as a part of a link, therefore users should specify the queue-type when creating links. In the above simulation script, DropTail queue is used. If the reader wants to use a RED queue, simply replace the word DropTail with RED. The NS implementation of a link is shown in a later section. Like a node, a link is a compound object, and users can create its sub-objects and connect them and the nodes. Link source codes can be found in "usr/local/ns-2/ns-2.31/tcl/libs/ns-lib.tcl" and "usr/local/ns-2/ns-2.31//tcl/libs/ns-link.tcl" files. One thing to note is that you can insert error modules in a link component to simulate a lossy link (actually users can make and insert any network objects). Refer to the NS documentation to find out how to do this.
#Set Queue Size of link (n2-n3) to 10 $ns queue-limit $n2 $n3 10
more..
$ns queue-limit [node1] [node2] [number] : This line sets the queue limit of the two simplex links that connect node1 and node2 to the number specified. At this point, the authors do not know how many of these kinds of member functions of Simulator objects are available and what they are. Please take a look at "usr/local/ns-2/ns-2.31/tcl/libs/ns-lib.tcl" and "usr/local/ns-2/ns-2.31/tcl/libs/ns-link.tcl", or NS documentation for more information.
$ns duplex-link-op [node1] [node2] ...: The next couple of lines are used for the NAM display. To see the effects of these lines, users can comment these lines out and try the simulation.
#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
more..
set tcp [new Agent/TCP]: This line shows how to create a TCP agent. But in general, users can create any agent or traffic sources in this way. Agents and traffic sources are in fact basic objects (not compound objects), mostly implemented in C++ and linked to OTcl. Therefore, there are no specific Simulator object member functions that create these object instances. To create agents or traffic sources, a user should know the class names these objects (Agent/TCP, Agnet/TCPSink, Application/FTP and so on). This information can be found in the NS documentation or partly in this documentation. But one shortcut is to look at the "usr/local/ns-2/ns-2.31/tcl/libs/ns-default.tcl" file. This file contains the default configurable parameter value settings for available network objects. Therefore, it works as a good indicator of what kind of network objects are available in NS and what are the configurable parameters.
$ns attach-agent [node] [agent] : The attach-agent member function attaches an agent object created to a node object. Actually, what this function does is call the attach member function of specified node, which attaches the given agent to itself. Therefore, a user can do the same thing by, for example, $n0 attach $tcp. Similarly, each agent object has a member function attach-agent that attaches a traffic source object to itself.
$ns connect [agent1] [agent2] : After two agents that will communicate with each other are created, the next thing is to establish a logical network connection between them. This line establishes a network connection by setting the destination address to each others' network and port address pair.
#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"
more..
$ns at [time] "string" : This member function of a Simulator object makes the scheduler (scheduler_ is the variable that points the scheduler object created by [new Scheduler] command at the beginning of the script) to schedule the execution of the specified string at given simulation time. For example, $ns at 0.1 "$cbr start" will make the scheduler call a start member function of the CBR traffic source object, which starts the CBR to transmit data. In NS, usually a traffic source does not transmit actual data, but it notifies the underlying agent that it has some amount of data to transmit, and the agent, just knowing how much of the data to transfer, creates packets and sends them.
#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_]"
이 네트워크는 위 그림과 같이 4개의 노드(n0, n1, n2, n3)로 구성된다. n0와 n2, n1과 n2 간에는 2Mbps의 bandwidth와 10ms의 delay를 갖는 duplex links로.. n2와 n3 간에는 1.7Mbps의 bandwidth와 20ms의 delay를 갖는 deplex links로 연결된다. 각 노드는 최대사이즈가 10인 DropTail queue를 사용한다.
"tcp" agent는 n0에 붙고, n3에 붙은 tcp "sink" agent와 연결된다. 디폴트로 패킷의 최대사이즈는 tcp agent에서 1KByte로 생성한다. tcp "sink" agent는 ACK 패킷을 sender(tcp agent) 측으로 생성하여 보내며, 받은 패킷을 제거한다(? frees the received packets).
"udp" agent는 n1에 붙고, n3에 붙은 "null" agnet와 연결된다. "null" agent는 단지 받은 패킷을 제거한다(? frees the packets received).
"ftp"와 "cbr" traffic generator(source)는 각각 "tcp" "udp" agent에 붙으며, "cbr"은 1Mbps 속도로 1KByte 패킷을 생성하기위해 구성된다.
"cbr"은 0.1sec에서 시작하고 4.5sec에서 멈춘다. "ftp"는 1.0sec에서 시작하고 4.0sec에서 멈춘다.
Trace Analysis Example
Trace Format Example
more..
event "+" : 큐에 들어오는 패킷 "-" : 큐에서 나가는 패킷 "r" : 패킷이 다른 노드에 도착 "d" : 큐에서 드롭된 패킷 time : 패킷의 이동시간 from / to node : 패킷의 이동 경로 pkt type : 패킷 타입 pkt size : 패킷 사이즈 flag : '---------' 표시는 어떤 플래그도 이용하고 있지 않음을 의미 src_addr / dst_addr : ex. 0.0, 3.0은 각각 node.port를 의미 seq num : 패킷의 순서번호 (udp는 순서번호를 이용하지 않지만, NS2에서는 사용) pkt id : 패킷 유일 id를 나타내는 필드
ns-simple.tcl
