Manual: Nodes and Packet Forwarding

From nsnam
Revision as of 06:25, 28 November 2008 by Lachlan (Talk | contribs) (Start: Sections 1-3)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Previous chapter: "The Class Simulator" | index | Next chapter: "Links: Simple Links"

This chapter describes one aspect of creating a topology in ns, i.e., creating the nodes. In the next chapter, we will describe second aspect of creating the topology, i.e., connecting the nodes to form links.

Recall that each simulation requires a single instance of the class Simulator to control and operate that simulation. The class provides instance procedures to create and manage the topology, and internally stores references to each element of the topology. We begin by describing the procedures in the class Simulator. We then describe the instance procedures in the class Node (Section 5.2) to access and operate on individual nodes. We conclude with detailed descriptions of the Classifier (Section 5.4) from which the more complex node objects are formed.

The procedures and functions described in this chapter can be found in ~ns/tcl/lib/ns-lib.tcl, ~ns/tcl/lib/ns-node.tcl, ~ns/tcl/lib/ns-rtmodule.tcl, ~ns/rtmodule.{cc,h}, ~ns/classifier.{cc, h}, ~ns/classifier-addr.cc, ~ns/classifier-mcast.cc, ~ns/classifiermpath.cc, and, ~ns/replicator.cc.

Node Basics

The basic primitive for creating a node is

set ns [new Simulator]
$ns node

The instance procedure node constructs a node out of more simple classifier objects (Section 5.4). The Node itself is a standalone class in OTcl. However, most of the components of the node are themselves TclObjects. The typical structure of a (unicast) node is as shown in Figure 5.1. This simple structure consists of two TclObjects: an address classifer (classifer_) and a port classifier (dmux_). The function of these classifiers is to distribute incoming packets to the correct agent or outgoing link.

All nodes contain at least the following components:

  • an address or id_, monotonically increasing by 1 (from initial value 0) across the simulation namespace as nodes are created,
  • a list of neighbors (neighbor_),
  • a list of agents (agent_),
  • a node type identifier (nodetype_), and
  • a routing module (described in Section 5.5 below)

By default, nodes in ns are constructed for unicast simulations. In order to enable multicast simulation, the simulation should be created with an option “-multicast on”, e.g.:

set ns [new Simulator -multicast on]

The internal structure of a typical multicast node is shown in Figure 5.2.

When a simulation uses multicast routing, the highest bit of the address indicates whether the particular address is a multicast address or an unicast address. If the bit is 0, the address represents a unicast address, else the address represents a multicast address.

Node Methods: Configuring the Node

Procedures to configure an individual node can be classified into:

  • Control functions
  • Address and Port number management, unicast routing functions
  • Agent management
  • Adding neighbors

We describe each of the functions in the following paragraphs.

Control functions

  1. $node entry returns the entry point for a node. This is the first element which will handle packets arriving at that node.

The Node instance variable, entry_, stores the reference this element. For unicast nodes, this is the address classifier that looks at the higher bits of the destination address. The instance variable, classifier_ contains the reference to this classifier. However, for multicast nodes, the entry point is the switch_ which looks at the first bit to decide whether it should forward the packet to the unicast classifier, or the multicast classifier as appropriate. 2. $node reset will reset all agents at the node.

Address and Port number management The procedure $node id returns the node number of the node. This number is automatically incremented and assigned to each node at creation by the class Simulator method, $ns node. The class Simulator also stores an instance variable array (i.e., an instance variable of a class that is also an array variable), Node_, indexed by the node id, and contains a reference to the node with that id.

The procedure $node agent hporti returns the handle of the agent at the specified port. If no agent at the specified port number is available, the procedure returns the null string.

The procedure alloc-port returns the next available port number. It uses an instance variable, np_, to track the next unallocated port number.

The procedures, add-route and add-routes, are used by unicast routing (Chapter 28) to add routes to populate the classifier_ The usage syntax is $node add-route hdestination idi hTclObjecti. TclObject is the entry of dmux_, the port demultiplexer at the node, if the destination id is the same as this node’s id, it is often the head of a link to send packets for that destination to, but could also be the the entry for other classifiers or types of classifiers.

$node add-routes hdestination idi hTclObjectsi is used to add multiple routes to the same destination that must be used simultaneously in round robin manner to spread the bandwidth used to reach that destination across all links equally. It is used only if the instance variable multiPath_ is set to 1, and detailed dynamic routing strategies are in effect, and requires the use of a multiPath classifier. We describe the implementation of the multiPath classifier later in this chapter (Section 5.4); however, we defer the discussion of multipath routing (Chapter 28) to the chapter on unicast routing.

The dual of add-routes{} is delete-routes{}. It takes the id, a list of TclObjects, and a reference to the simulator's nullagent. It removes the TclObjects in the list from the installed routes in the multipath classifier. If the route entry in the classifier does not point to a multipath classifier, the routine simply clears the entry from classifier_, and installs the nullagent in its place.

Detailed dynamic routing also uses two additional methods: the instance procedure init-routing{} sets the instance variable multiPath_ to be equal to the class variable of the same name. It also adds a reference to the route controller object at that node in the instance variable, rtObject_. The procedure rtObject?{} returns the handle for the route object at the node.

Finally, the procedure intf-changed{} is invoked by the network dynamics code if a link incident on the node changes state. Additional details on how this procedure is used are discussed later in the chapter on network dynamics (Chapter 30).

Agent management Given an <agent>, the procedure attach{} will add the agent to its list of agents_, assign a port number the agent and set its source address, set the target of the agent to be its (i.e., the node’s) entry{}, and add a pointer to the port demultiplexer at the node (dmux_) to the agent at the corresponding slot in the dmux_ classifier.

Conversely, detach{}will remove the agent from agents_, and point the agent’s target, and the entry in the node dmux_ to nullagent.

Tracking Neighbors Each node keeps a list of its adjacent neighbors in its instance variable, neighbor_. The procedure add-neighbor{} adds a neighbor to the list. The procedure neighbors{} returns this list.

Node Configuration Interface

NOTE: This API, especially its internal implementation which is messy at this point, is still a moving target. It may undergo significant changes in the near future. However, we will do our best to maintain the same interface as described in this chapter. In addition, this API currently does not cover all existing nodes in the old format, namely, nodes built using inheritance, and

parts of mobile IP. It is principally oriented towards wireless and satellite simulation. [Sep 15, 2000; updated June 2001].

Simulator::node-config{} accommodates flexible and modular construction of different node definitions within the same base Node class. For instance, to create a mobile node capable of wireless communication, one no longer needs a specialized node creation command, e.g., dsdv-create-mobile-node{}; instead, one changes default configuration parameters, such as

$ns node-config -adhocRouting dsdv

before actually creating the node with the command: $ns node. Together with routing modules, this allows one to combine "arbitrary" routing functionalities within a single node without resorting to multiple inheritance and other fancy object gimmicks. We will describe this in more detail in Section 5.5. The functions and procedures relevant to the new node APIs may be found in ~ns/tcl/lib/ns-node.tcl.

The node configuration interface consists of two parts. The first part deals with node configuration, while the second part actually creates nodes of the specified type. We have already seen the latter in Section 5.1, in this section we will describe the configuration part.

Node configuration essentially consists of defining the different node characteristics before creating them. They may consist of the type of addressing structure used in the simulation, defining the network components for mobilenodes, turning on or off the trace options at Agent/Router/MAC levels, selecting the type of adhoc routing protocol for wireless nodes or defining their energy model.

As an example, node-configuration for a wireless, mobile node that runs AODV as its adhoc routing protocol in a hierarchical topology would be as shown below. We decide to turn tracing on at the agent and router level only. Also we assume a topology has been instantiated with "set topo [new Topography]". The node-config command would look like the following:

$ns_ node-config -addressType hierarchical \
                 -adhocRouting AODV \
                 -llType LL \
                 -macType Mac/802_11 \
                 -ifqType Queue/DropTail/PriQueue \
                 -ifqLen 50 \
                 -antType Antenna/OmniAntenna \
                 -propType Propagation/TwoRayGround \
                 -phyType Phy/WirelessPhy \
                 -topologyInstance $topo \
                 -channel Channel/WirelessChannel \
                 -agentTrace ON \
                 -routerTrace ON \
                 -macTrace OFF \
                 -movementTrace OFF

Previous chapter: "The Class Simulator" | index | Next chapter: "Links: Simple Links"