F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update the manual to reflect changes

Browse Source
This commit is contained in:
Tom Henderson
2010-01-25 09:21:19 +01:00
parent acf00df486
commit bde7128578
3 changed files with 49 additions and 22 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
doc/manual/animation.texi
View File

@@ -8,23 +8,22 @@
@end menu
Animation is an important tool for network simulation. While ns-3 does
not contain a graphical animation tool, it does provide an animation interface
for use with stand-alone animators. Currently, the animation
interface only supports point-to-point links; however, we hope
to support other link types such as CSMA and wireless in the near future.
The animation interface in ns-3 allows the generation of a custom trace
file to be used by an animation program.
An existing stand-alone program, NetAnim, uses these custom traces to
graphically display the simulation. NetAnim depicts packets traveling
on point-to-point links as they travel from node to node.
not contain a default graphical animation tool, it does provide an
animation interface for use with stand-alone animators. One such
animator called NetAnim, presently supporting packet flow animation
for point-to-point links, has been developed. Other animators and
visualization tools are in development; they may make use of the
existing animation interface or may develop new ones,
@node Animation interface
@section Animation interface
The animation interface uses underlying ns-3 trace sources to construct
a timestamped ASCII file that can be read by a standalone animator.
The animation interface in ns-3 currently only supports point-to-point
links and can generate a custom trace file for use by an animation
program. A snippet from a sample trace file is shown below.
links; however, we hope
to support other link types such as CSMA and wireless in the near future.
A snippet from a sample trace file is shown below.
@verbatim
0.0 N 0 4 5.5

3
doc/manual/flow-monitor.texi
View File

@@ -5,6 +5,7 @@
Placeholder chapter
@end cartouche
This feature was added as contributed code (@code{src/contrib}) in ns-3.6.
This feature was added as contributed code (@code{src/contrib}) in ns-3.6 and
to the main distribution for ns-3.7.
A paper on this feature is published in the proceedings of NSTools: @*
@uref{http://www.nstools.org/techprog.shtml,,http://www.nstools.org/techprog.shtml}

45
doc/manual/routing.texi
View File

@@ -270,22 +270,49 @@ and no further routing protocols will be searched.
@subsection Optimized Link State Routing (OLSR)
This is the first dynamic routing protocol for @command{ns-3}. The implementation
This IPv4 routing protocol was originally ported from the OLSR-UM
implementation for ns-2. The implementation
is found in the src/routing/olsr directory, and an example script is in
examples/simple-point-to-point-olsr.cc.
The following commands will enable OLSR in a simulation.
Typically, OLSR is enabled in a main program by use of an OlsrHelper class
that installs OLSR into an Ipv4ListRoutingProtocol object.
The following sample commands will enable OLSR in a simulation using
this helper class along with some other routing helper objects.
The setting of priority value 10, ahead of
the staticRouting priority of 0, means that OLSR will be consulted for
a route before the node's static routing table.
@verbatim
olsr::EnableAllNodes (); // Start OLSR on all nodes
olsr::EnableNodes(InputIterator begin, InputIterator end); // Start on
// a list of nodes
olsr::EnableNode (Ptr<Node> node); // Start OLSR on "node" only
NodeContainer c:
...
// Enable OLSR
NS_LOG_INFO ("Enabling OLSR Routing.");
OlsrHelper olsr;
Ipv4StaticRoutingHelper staticRouting;
Ipv4ListRoutingHelper list;
list.Add (staticRouting, 0);
list.Add (olsr, 10);
InternetStackHelper internet;
internet.SetRoutingHelper (list);
internet.Install (c);
@end verbatim
Once instantiated, the agent can be started with the Start() command,
and the OLSR "main interface" can be set with the SetMainInterface()
command. A number of protocol constants are defined in olsr-agent-impl.cc.
Once installed,the OLSR "main interface" can be set with the
SetMainInterface() command. If the user does not specify a main address,
the protocol will select the first primary IP address that it finds, starting
first the loopback interface and then the next non-loopback interface
found, in order of Ipv4 interface index. The loopback address of 127.0.0.1
is not selected. In addition, a number of protocol constants are defined in
olsr-routing-protocol.cc.
Olsr is started at time zero of the simulation, based on a call to
Object::Start() that eventually calls OlsrRoutingProtocol::DoStart().
Note: a patch to allow the user to start and stop the protocol at other
times would be welcome.
Presently, OLSR is limited to use with an Ipv4ListRouting object, and
does not respond to dynamic changes to a device's IP address or link up/down