1.1 --- a/doc/manual/Makefile Tue Jun 02 16:37:41 2009 +0200
1.2 +++ b/doc/manual/Makefile Tue Jun 02 16:38:24 2009 +0200
1.3 @@ -17,6 +17,8 @@
1.4 $(FIGURES)/node.eps \
1.5 $(FIGURES)/buffer.eps \
1.6 $(FIGURES)/sockets-overview.eps \
1.7 + $(FIGURES)/routing.eps \
1.8 + $(FIGURES)/routing-specialization.eps \
1.9 $(FIGURES)/testbed.eps \
1.10 $(FIGURES)/emulated-channel.eps \
1.11 $(FIGURES)/snir.eps \
2.1 --- a/doc/manual/attributes.texi Tue Jun 02 16:37:41 2009 +0200
2.2 +++ b/doc/manual/attributes.texi Tue Jun 02 16:38:24 2009 +0200
2.3 @@ -207,6 +207,8 @@
2.4 In the ns-3 attribute system, these value definitions and accessor
2.5 functions are moved into the TypeId class; e.g.:
2.6 @verbatim
2.7 +NS_OBJECT_ENSURE_REGISTERED (DropTailQueue);
2.8 +
2.9 TypeId DropTailQueue::GetTypeId (void)
2.10 {
2.11 static TypeId tid = TypeId ("ns3::DropTailQueue")
2.12 @@ -239,6 +241,11 @@
2.13 section, we will provide an example script that shows how users
2.14 may manipulate these values.
2.15
2.16 +Note that initialization of the attribute relies on the macro
2.17 +NS_OBJECT_ENSURE_REGISTERED (DropTailQueue) being called; if you leave
2.18 +this out of your new class implementation, your attributes will not be
2.19 +initialized corretly.
2.20 +
2.21 @subsection Basic usage
2.22
2.23 Let's look at how a user script might access these values.
3.1 Binary file doc/manual/figures/routing-specialization.dia has changed
4.1 Binary file doc/manual/figures/routing.dia has changed
5.1 --- a/doc/manual/routing.texi Tue Jun 02 16:37:41 2009 +0200
5.2 +++ b/doc/manual/routing.texi Tue Jun 02 16:38:24 2009 +0200
5.3 @@ -2,40 +2,213 @@
5.4 @chapter Routing overview
5.5
5.6 @menu
5.7 -* Routing-Overview::
5.8 -* Support for multiple routing protocols::
5.9 -* Roadmap and Future work::
5.10 -* Static routing::
5.11 +* Routing architecture::
5.12 +* Global centralized routing::
5.13 * Unicast routing::
5.14 * Multicast routing::
5.15 -* Global centralized routing::
5.16 -* Global Unicast Routing API::
5.17 -* Global Routing Implementation::
5.18 -* Optimized Link State Routing (OLSR)::
5.19 @end menu
5.20
5.21 -This chapter describes the overall design of routing in the
5.22 -@code{src/internet-stack}
5.23 -module, and some details about the routing approachs currently
5.24 -implemented.
5.25 +ns-3 is intended to support traditional routing approaches and protocols,
5.26 +support ports of open source routing implementations, and facilitate research
5.27 +into unorthodox routing techniques. The overall routing architecture
5.28 +is described below in @ref{Routing architecture}. Users who wish to
5.29 +just read about how to configure global routing for wired topologies
5.30 +can read @ref{Global centralized routing}. Unicast routing protocols
5.31 +are described in @ref{Unicast routing}. Multicast routing is documented in
5.32 +@ref{Multicast routing}.
5.33
5.34 -@node Routing-Overview
5.35 -@section Overview
5.36 +@node Routing architecture
5.37 +@section Routing architecture
5.38
5.39 -We intend to support traditional routing approaches and protocols,
5.40 -ports of open source routing implementations, and facilitate research
5.41 -into unorthodox routing techniques.
5.42 -For simulations that are not primarily focused on routing and that
5.43 -simply want correct routing tables to occur somehow, we have an
5.44 -global centralized routing capability. A singleton object
5.45 -(GlobalRouteManager) be instantiated, builds a network map, and
5.46 -populates a forwarding table on each node at time t=0 in the
5.47 -simulation. Simulation script writers can use the same node
5.48 -API to manually enter routes as well.
5.49 +@float Figure,fig:routing
5.50 +@caption{Overview of routing}
5.51 +@image{figures/routing, 6in}
5.52 +@end float
5.53
5.54 -@node Support for multiple routing protocols
5.55 -@section Support for multiple routing protocols
5.56 +Figure 11-1 shows the overall routing architecture for Ipv4. The key objects
5.57 +are Ipv4L3Protocol, Ipv4RoutingProtocol(s) (a class to which all
5.58 +routing/forwarding has been delegated from Ipv4L3Protocol), and Ipv4Route(s).
5.59
5.60 +Ipv4L3Protocol must have at least one Ipv4RoutingProtocol added to
5.61 +it at simulation setup time. This is done explicitly by calling
5.62 +Ipv4::SetRoutingProtocol ().
5.63 +
5.64 +The abstract base class Ipv4RoutingProtocol () declares a minimal interface,
5.65 +consisting of two methods: RouteOutput () and RouteInput ().
5.66 +For packets traveling outbound from a host, the transport protocol will query
5.67 +Ipv4 for the Ipv4RoutingProtocol object interface, and will request
5.68 +a route via Ipv4RoutingProtocol::RouteOutput ().
5.69 +A Ptr to Ipv4Route object is returned. This is analagous to a
5.70 +dst_cache entry in Linux. The Ipv4Route is carried down to the
5.71 +Ipv4L3Protocol to avoid a second lookup there. However, some
5.72 +cases (e.g. Ipv4 raw sockets) will require a call to RouteOutput()
5.73 +directly from Ipv4L3Protocol.
5.74 +
5.75 +For packets received inbound for forwarding or delivery,
5.76 +the following steps occur. Ipv4L3Protocol::Receive() calls
5.77 +Ipv4RoutingProtocol::RouteInput().
5.78 +This passes the packet ownership to the Ipv4RoutingProtocol object. There
5.79 +are four callbacks associated with this call:
5.80 +@itemize @bullet
5.81 +@item LocalDeliver
5.82 +@item UnicastForward
5.83 +@item MulticastForward
5.84 +@item Error
5.85 +@end itemize
5.86 +The Ipv4RoutingProtocol must eventually call one of these callbacks for each
5.87 +packet that it takes responsibility for. This is basically
5.88 +how the input routing process works in Linux.
5.89 +
5.90 +@float Figure,fig:routing-specialization
5.91 +@caption{Ipv4Routing specialization}
5.92 +@image{figures/routing-specialization, 5in}
5.93 +@end float
5.94 +
5.95 +This overall architecture is designed to support different routing
5.96 +approaches, including (in the future) a Linux-like policy-based routing
5.97 +implementation, proactive and on-demand routing protocols, and simple
5.98 +routing protocols for when the simulation user does not really care
5.99 +about routing.
5.100 +
5.101 +@ref{fig:routing-specialization} illustrates how multiple routing protocols
5.102 +derive from this base class. A class Ipv4ListRouting
5.103 +(implementation class Ipv4ListRoutingImpl) provides the existing
5.104 +list routing approach in ns-3. Its API is the same as base class
5.105 +Ipv4Routing except for the ability to add multiple prioritized routing
5.106 +protocols
5.107 +(Ipv4ListRouting::AddRoutingProtocol(), Ipv4ListRouting::GetRoutingProtocol()).
5.108 +
5.109 +The details of these routing protocols are described below in
5.110 +@ref{Unicast routing}. For now, we will first start with a basic
5.111 +unicast routing capability that is intended to globally build routing
5.112 +tables at simulation time t=0 for simulation users who do not care
5.113 +about dynamic routing.
5.114 +
5.115 +@node Global centralized routing
5.116 +@section Global centralized routing
5.117 +
5.118 +Global centralized routing is sometimes called ''God'' routing; it
5.119 +is a special implementation that walks the simulation topology and
5.120 +runs a shortest path algorithm, and populates each node's routing
5.121 +tables. No actual protocol overhead (on the simulated links) is incurred
5.122 +with this approach. It does have a few constraints:
5.123 +
5.124 +@itemize @bullet
5.125 +@item @strong{Wired only:} It is not intended for use in wireless networks.
5.126 +@item @strong{Unicast only:} It does not do multicast.
5.127 +@item @strong{Scalability:} Some users of this on large topologies
5.128 +(e.g. 1000 nodes)
5.129 +have noticed that the current implementation is not very scalable.
5.130 +The global centralized routing will be modified in the future to
5.131 +reduce computations and runtime performance.
5.132 +@end itemize
5.133 +
5.134 +Presently, global centralized IPv4 unicast routing over both
5.135 +point-to-point and shared (CSMA) links is supported.
5.136 +
5.137 +@subsection Global Unicast Routing API
5.138 +
5.139 +The public API is very minimal. User scripts include the following:
5.140 +@verbatim
5.141 +#include "ns3/global-route-manager.h"
5.142 +@end verbatim
5.143 +
5.144 +After IP addresses are configured, the following function call will
5.145 +cause all of the nodes that have an Ipv4 interface to receive
5.146 +forwarding tables entered automatically by the GlobalRouteManager:
5.147 +@verbatim
5.148 + GlobalRouteManager::PopulateRoutingTables ();
5.149 +@end verbatim
5.150 +
5.151 +@emph{Note:} A reminder that the wifi NetDevice will work but does not
5.152 +take any wireless effects into account. For wireless, we recommend
5.153 +OLSR dynamic routing described below.
5.154 +
5.155 +It is possible to call this function again in the midst of a simulation
5.156 +using the following additional public function:
5.157 +@verbatim
5.158 + GlobalRouteManager::RecomputeRoutingTables ();
5.159 +@end verbatim
5.160 +which flushes the old tables, queries the nodes for new interface information,
5.161 +and rebuilds the routes.
5.162 +
5.163 +For instance, this scheduling call will cause the tables to be rebuilt
5.164 +at time 5 seconds:
5.165 +@verbatim
5.166 + Simulator::Schedule (Seconds (5),&GlobalRouteManager::RecomputeRoutingTables);
5.167 +@end verbatim
5.168 +
5.169 +@subsection Global Routing Implementation
5.170 +
5.171 +This section is for those readers who care about how this is implemented.
5.172 +A singleton object (GlobalRouteManager) is responsible for populating
5.173 +the static routes on each node, using the public Ipv4 API of that node.
5.174 +It queries each node in the topology for a "globalRouter" interface.
5.175 +If found, it uses the API of that interface to obtain a "link state
5.176 +advertisement (LSA)" for the router. Link State Advertisements
5.177 +are used in OSPF routing, and we follow their formatting.
5.178 +
5.179 +The GlobalRouteManager populates a link state database with LSAs
5.180 +gathered from the entire topology. Then, for each router in the topology,
5.181 +the GlobalRouteManager executes the OSPF shortest path first (SPF)
5.182 +computation on the database, and populates the routing tables on each
5.183 +node.
5.184 +
5.185 +The quagga (http://www.quagga.net) OSPF implementation was used as the
5.186 +basis for the routing computation logic.
5.187 +One benefit of following an existing OSPF SPF implementation is that
5.188 +OSPF already has defined link state advertisements for all common
5.189 +types of network links:
5.190 +@itemize @bullet
5.191 +@item point-to-point (serial links)
5.192 +@item point-to-multipoint (Frame Relay, ad hoc wireless)
5.193 +@item non-broadcast multiple access (ATM)
5.194 +@item broadcast (Ethernet)
5.195 +@end itemize
5.196 +Therefore, we think that enabling these other link types will be more
5.197 +straightforward now that the underlying OSPF SPF framework is in place.
5.198 +
5.199 +Presently, we can handle IPv4 point-to-point, numbered links, as well
5.200 +as shared broadcast (CSMA) links, and we do not do equal-cost multipath.
5.201 +
5.202 +The GlobalRouteManager first walks the list of nodes and aggregates
5.203 +a GlobalRouter interface to each one as follows:
5.204 +@verbatim
5.205 + typedef std::vector < Ptr<Node> >::iterator Iterator;
5.206 + for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)
5.207 + {
5.208 + Ptr<Node> node = *i;
5.209 + Ptr<GlobalRouter> globalRouter = CreateObject<GlobalRouter> (node);
5.210 + node->AggregateObject (globalRouter);
5.211 + }
5.212 +@end verbatim
5.213 +
5.214 +This interface is later queried and used to generate a Link State
5.215 +Advertisement for each router, and this link state database is
5.216 +fed into the OSPF shortest path computation logic. The Ipv4 API
5.217 +is finally used to populate the routes themselves.
5.218 +
5.219 +@node Unicast routing
5.220 +@section Unicast routing
5.221 +
5.222 +There are presently four routing protocols defined:
5.223 +@itemize @bullet
5.224 +@item class Ipv4StaticRouting (covering both unicast and multicast)
5.225 +@item Optimized Link State Routing (a MANET protocol defined in
5.226 +@uref{http://www.ietf.org/rfc/rfc3626.txt,,RFC 3626})
5.227 +@item class Ipv4ListRouting (used to store a prioritized list of routing
5.228 +protocols)
5.229 +@item class Ipv4GlobalRouting (used to store routes computed by the global
5.230 +route manager, if that is used)
5.231 +@end itemize
5.232 +
5.233 +In the future, this architecture should also allow someone to implement
5.234 +a Linux-like implementation with routing cache, or a Click modular
5.235 +router, but those are out of scope for now.
5.236 +
5.237 +@subsection Ipv4ListRouting
5.238 +
5.239 +This section describes the current default ns-3 Ipv4RoutingProtocol.
5.240 Typically, multiple routing protocols are supported in user space and
5.241 coordinate to write a single forwarding table in the kernel. Presently
5.242 in @command{ns-3}, the implementation instead allows for multiple routing
5.243 @@ -50,163 +223,54 @@
5.244 routing) is used to determine the next hop, and on-demand
5.245 routing approaches where packets must be cached.
5.246
5.247 -There are presently two routing protocols defined:
5.248 -@itemize @bullet
5.249 -@item class Ipv4StaticRouting (covering both unicast and multicast)
5.250 -@item Optimized Link State Routing (a MANET protocol defined in
5.251 -@uref{http://www.ietf.org/rfc/rfc3626.txt,,RFC 3626})
5.252 -@end itemize
5.253 -but first we describe how multiple routing protocols are supported.
5.254 +@subsubsection Ipv4ListRouting::AddRoutingProtocol
5.255
5.256 -@subsection class Ipv4RoutingProtocol
5.257 -
5.258 -@code{class Ipv4RoutingProtocol} derives from ns-3 Object which means
5.259 -that it supports interface aggregation and reference counting. Routing
5.260 -protocols should inherit from this class, defined in src/node/ipv4.cc.
5.261 -
5.262 -The main function that must be supported by these protocols is called
5.263 -@code{RequestRoute}.
5.264 -@verbatim
5.265 - * This method is called whenever a node's IPv4 forwarding engine
5.266 - * needs to lookup a route for a given packet and IP header.
5.267 - *
5.268 - * The routing protocol implementation may determine immediately it
5.269 - * should not be handling this particular the route request. For
5.270 - * instance, a routing protocol may decline to search for routes for
5.271 - * certain classes of addresses, like link-local. In this case,
5.272 - * RequestRoute() should return false and the routeReply callback
5.273 - * must not be invoked.
5.274 - *
5.275 - * If the routing protocol implementations assumes it can provide
5.276 - * the requested route, then it should return true, and the
5.277 - * routeReply callback must be invoked, either immediately before
5.278 - * returning true (synchronously), or in the future (asynchronous).
5.279 - * The routing protocol may use any information available in the IP
5.280 - * header and packet as routing key, although most routing protocols
5.281 - * use only the destination address (as given by
5.282 - * ipHeader.GetDestination ()). The routing protocol is also
5.283 - * allowed to add a new header to the packet, which will appear
5.284 - * immediately after the IP header, although most routing do not
5.285 - * insert any extra header.
5.286 - */
5.287 - virtual bool RequestRoute (uint32_t interface,
5.288 - const Ipv4Header &ipHeader,
5.289 - Ptr<Packet> packet,
5.290 - RouteReplyCallback routeReply) = 0;
5.291 -@end verbatim
5.292 -
5.293 -This class also provides a typedef (used above) for a special Callback
5.294 -that will pass to the callback function the Ipv4Route that is found (see the
5.295 -Doxygen documentation):
5.296 -@verbatim
5.297 - typedef Callback<void, bool, const Ipv4Route&, Ptr<Packet>, const Ipv4Header&> RouteReplyCallback;
5.298 -@end verbatim
5.299 -
5.300 -@subsection Ipv4::AddRoutingProtocol
5.301 -
5.302 -Class Ipv4 provides a pure virtual function declaration for the
5.303 +Class Ipv4ListRouting provides a pure virtual function declaration for the
5.304 method that allows one to add a routing protocol:
5.305 @verbatim
5.306 void AddRoutingProtocol (Ptr<Ipv4RoutingProtocol> routingProtocol,
5.307 int16_t priority);
5.308 @end verbatim
5.309 -This method is implemented by class Ipv4L3Protocol in the internet-stack
5.310 +This method is implemented by class Ipv4ListRoutingImpl in the internet-stack
5.311 module.
5.312
5.313 The priority variable above governs the priority in which the routing
5.314 protocols are inserted. Notice that it is a signed int.
5.315 -When the class Ipv4L3Protocol is instantiated, a single routing
5.316 -protocol (Ipv4StaticRouting, introduced below) is added at priority
5.317 -zero. Internally, a list of Ipv4RoutingProtocols is stored, and
5.318 +By default in ns-3, the helper classes will instantiate a Ipv4ListRoutingImpl
5.319 +object, and add to it an Ipv4StaticRoutingImpl object at priority zero.
5.320 +Internally, a list of Ipv4RoutingProtocols is stored, and
5.321 and the routing protocols are each consulted in decreasing order
5.322 of priority to see whether a match is found. Therefore, if you
5.323 want your Ipv4RoutingProtocol to have priority lower than the static
5.324 routing, insert it with priority less than 0; e.g.:
5.325 @verbatim
5.326 - m_ipv4->AddRoutingProtocol (m_routingTable, -10);
5.327 + Ptr<MyRoutingProtocol> myRoutingProto = CreateObject<MyRoutingProtocol> ();
5.328 + listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10);
5.329 @end verbatim
5.330
5.331 -@subsection Ipv4L3Protocol::Lookup
5.332 +Upon calls to RouteOutput() or RouteInput(), the list routing object will
5.333 +search the list of routing protocols, in priority order, until a route
5.334 +is found. Such routing protocol will invoke the appropriate callback
5.335 +and no further routing protocols will be searched.
5.336
5.337 -The main function for obtaining a route is shown below:
5.338 +@subsection Optimized Link State Routing (OLSR)
5.339 +
5.340 +This is the first dynamic routing protocol for @command{ns-3}. The implementation
5.341 +is found in the src/routing/olsr directory, and an example script is in
5.342 +examples/simple-point-to-point-olsr.cc.
5.343 +
5.344 +The following commands will enable OLSR in a simulation.
5.345 +
5.346 @verbatim
5.347 -Ipv4L3Protocol::Lookup (
5.348 - uint32_t interface,
5.349 - Ipv4Header const &ipHeader,
5.350 - Ptr<Packet> packet,
5.351 - Ipv4RoutingProtocol::RouteReplyCallback routeReply)
5.352 + olsr::EnableAllNodes (); // Start OLSR on all nodes
5.353 + olsr::EnableNodes(InputIterator begin, InputIterator end); // Start on
5.354 + // a list of nodes
5.355 + olsr::EnableNode (Ptr<Node> node); // Start OLSR on "node" only
5.356 @end verbatim
5.357
5.358 -This function will search the list of routing protocols, in priority order,
5.359 -until a route is found. It will then invoke the RouteReplyCallback
5.360 -and no further routing protocols will be searched. If the caller does
5.361 -not want to constrain the possible interface, it can be wildcarded
5.362 -as such:
5.363 -@verbatim
5.364 - Lookup (Ipv4RoutingProtocol::IF_INDEX_ANY, ipHeader, packet, routeReply);
5.365 -@end verbatim
5.366 -
5.367 -@node Roadmap and Future work
5.368 -@section Roadmap and Future work
5.369 -
5.370 -Some goals for future support are:
5.371 -
5.372 -Users should be able to trace (either debug print, or redirect to a trace
5.373 -file) the routing table in a format such as used in an
5.374 -Unix implementation:
5.375 -@verbatim
5.376 -# netstat -nr (or # route -n)
5.377 -Kernel IP routing table
5.378 -Destination Gateway Genmask Flags MSS Window irtt Iface
5.379 -127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
5.380 -172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
5.381 -172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0
5.382 -
5.383 -# ip route show
5.384 -192.168.99.0/24 dev eth0 scope link
5.385 -127.0.0.0/8 dev lo scope link
5.386 -default via 192.168.99.254 dev eth0
5.387 -@end verbatim
5.388 -
5.389 -Global computation of multicast routing should be implemented as well.
5.390 -This would ignore group membership and ensure that a copy of every
5.391 -sourced multicast datagram would be delivered to each node.
5.392 -This might be implemented as an RPF mechanism that functioned on-demand
5.393 -by querying the forwarding table,
5.394 -and perhaps optimized by a small multicast forwarding cache. It is
5.395 -a bit trickier to implement over wireless links where the input
5.396 -interface is the same as the output interface; other aspects of the
5.397 -packet must be considered and the forwarding logic slightly changed
5.398 -to allow for forwarding out the same interface.
5.399 -
5.400 -In the future, work on bringing XORP or quagga routing to ns, but it will
5.401 -take several months to port and enable.
5.402 -
5.403 -There are presently no roadmap plans for IPv6.
5.404 -
5.405 -@node Static routing
5.406 -@section Static routing
5.407 -
5.408 -The internet-stack module provides one routing protocol (Ipv4StaticRouting)
5.409 -by default. This routing protocol allows one to add unicast or multicast
5.410 -static routes to a node.
5.411 -
5.412 -@node Unicast routing
5.413 -@section Unicast routing
5.414 -
5.415 -The unicast static routing API may be accessed via the functions
5.416 -@verbatim
5.417 -void Ipv4::AddHostRouteTo ()
5.418 -void Ipv4::AddNetworkRouteTo ()
5.419 -void Ipv4::SetDefaultRoute ()
5.420 -uint32_t Ipv4::GetNRoutes ()
5.421 -Ipv4Route Ipv4::GetRoute ()
5.422 -@end verbatim
5.423 -
5.424 -@uref{http://www.nsnam.org/doxygen/index.html,,Doxygen} documentation
5.425 -provides full documentation of these methods. These methods are forwarding
5.426 -functions to the actual implementation in Ipv4StaticRouting, when using
5.427 -the internet-stack module.
5.428 +Once instantiated, the agent can be started with the Start() command,
5.429 +and the OLSR "main interface" can be set with the SetMainInterface()
5.430 +command. A number of protocol constants are defined in olsr-agent-impl.cc.
5.431
5.432 @node Multicast routing
5.433 @section Multicast routing
5.434 @@ -288,113 +352,4 @@
5.435 void RemoveMulticastRoute (uint32_t index);
5.436 @end verbatim
5.437
5.438 -@node Global centralized routing
5.439 -@section Global centralized routing
5.440
5.441 -Presently, global centralized IPv4 @emph{unicast} routing over both
5.442 -point-to-point and shared (CSMA) links is supported.
5.443 -The global centralized routing will be modified in the future to
5.444 -reduce computations once profiling finds the performance bottlenecks.
5.445 -
5.446 -@node Global Unicast Routing API
5.447 -@section Global Unicast Routing API
5.448 -
5.449 -The public API is very minimal. User scripts include the following:
5.450 -@verbatim
5.451 -#include "ns3/global-route-manager.h"
5.452 -@end verbatim
5.453 -
5.454 -After IP addresses are configured, the following function call will
5.455 -cause all of the nodes that have an Ipv4 interface to receive
5.456 -forwarding tables entered automatically by the GlobalRouteManager:
5.457 -@verbatim
5.458 - GlobalRouteManager::PopulateRoutingTables ();
5.459 -@end verbatim
5.460 -
5.461 -@emph{Note:} A reminder that the wifi NetDevice is not yet supported
5.462 -(only CSMA and PointToPoint).
5.463 -
5.464 -It is possible to call this function again in the midst of a simulation
5.465 -using the following additional public function:
5.466 -@verbatim
5.467 - GlobalRouteManager::RecomputeRoutingTables ();
5.468 -@end verbatim
5.469 -which flushes the old tables, queries the nodes for new interface information,
5.470 -and rebuilds the routes.
5.471 -
5.472 -For instance, this scheduling call will cause the tables to be rebuilt
5.473 -at time 5 seconds:
5.474 -@verbatim
5.475 - Simulator::Schedule (Seconds (5),&GlobalRouteManager::RecomputeRoutingTables);
5.476 -@end verbatim
5.477 -
5.478 -@node Global Routing Implementation
5.479 -@section Global Routing Implementation
5.480 -
5.481 -A singleton object (GlobalRouteManager) is responsible for populating
5.482 -the static routes on each node, using the public Ipv4 API of that node.
5.483 -It queries each node in the topology for a "globalRouter" interface.
5.484 -If found, it uses the API of that interface to obtain a "link state
5.485 -advertisement (LSA)" for the router. Link State Advertisements
5.486 -are used in OSPF routing, and we follow their formatting.
5.487 -
5.488 -The GlobalRouteManager populates a link state database with LSAs
5.489 -gathered from the entire topology. Then, for each router in the topology,
5.490 -the GlobalRouteManager executes the OSPF shortest path first (SPF)
5.491 -computation on the database, and populates the routing tables on each
5.492 -node.
5.493 -
5.494 -The quagga (http://www.quagga.net) OSPF implementation was used as the
5.495 -basis for the routing computation logic.
5.496 -One benefit of following an existing OSPF SPF implementation is that
5.497 -OSPF already has defined link state advertisements for all common
5.498 -types of network links:
5.499 -@itemize @bullet
5.500 -@item point-to-point (serial links)
5.501 -@item point-to-multipoint (Frame Relay, ad hoc wireless)
5.502 -@item non-broadcast multiple access (ATM)
5.503 -@item broadcast (Ethernet)
5.504 -@end itemize
5.505 -Therefore, we think that enabling these other link types will be more
5.506 -straightforward now that the underlying OSPF SPF framework is in place.
5.507 -
5.508 -Presently, we can handle IPv4 point-to-point, numbered links, as well
5.509 -as shared broadcast (CSMA) links, and we do not do equal-cost multipath.
5.510 -
5.511 -The GlobalRouteManager first walks the list of nodes and aggregates
5.512 -a GlobalRouter interface to each one as follows:
5.513 -@verbatim
5.514 - typedef std::vector < Ptr<Node> >::iterator Iterator;
5.515 - for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++)
5.516 - {
5.517 - Ptr<Node> node = *i;
5.518 - Ptr<GlobalRouter> globalRouter = CreateObject<GlobalRouter> (node);
5.519 - node->AggregateObject (globalRouter);
5.520 - }
5.521 -@end verbatim
5.522 -
5.523 -This interface is later queried and used to generate a Link State
5.524 -Advertisement for each router, and this link state database is
5.525 -fed into the OSPF shortest path computation logic. The Ipv4 API
5.526 -is finally used to populate the routes themselves.
5.527 -
5.528 -@node Optimized Link State Routing (OLSR)
5.529 -@section Optimized Link State Routing (OLSR)
5.530 -
5.531 -This is the first dynamic routing protocol for @command{ns-3}. The implementation
5.532 -is found in the src/routing/olsr directory, and an example script is in
5.533 -examples/simple-point-to-point-olsr.cc.
5.534 -
5.535 -The following commands will enable OLSR in a simulation.
5.536 -
5.537 -@verbatim
5.538 - olsr::EnableAllNodes (); // Start OLSR on all nodes
5.539 - olsr::EnableNodes(InputIterator begin, InputIterator end); // Start on
5.540 - // a list of nodes
5.541 - olsr::EnableNode (Ptr<Node> node); // Start OLSR on "node" only
5.542 -@end verbatim
5.543 -
5.544 -Once instantiated, the agent can be started with the Start() command,
5.545 -and the OLSR "main interface" can be set with the SetMainInterface()
5.546 -command. A number of protocol constants are defined in olsr-agent-impl.cc.
5.547 -
6.1 --- a/src/core/names.cc Tue Jun 02 16:37:41 2009 +0200
6.2 +++ b/src/core/names.cc Tue Jun 02 16:38:24 2009 +0200
6.3 @@ -83,7 +83,7 @@
6.4 NamesPriv ();
6.5 ~NamesPriv ();
6.6
6.7 - bool Add (std::string name, Ptr<Object> obj);
6.8 + bool Add (std::string name, Ptr<Object> object);
6.9 bool Add (std::string path, std::string name, Ptr<Object> object);
6.10 bool Add (Ptr<Object> context, std::string name, Ptr<Object> object);
6.11
7.1 --- a/src/core/names.h Tue Jun 02 16:37:41 2009 +0200
7.2 +++ b/src/core/names.h Tue Jun 02 16:38:24 2009 +0200
7.3 @@ -45,7 +45,7 @@
7.4 * ("/Names") in the path.
7.5 *
7.6 * As well as specifying a name at the root of the "/Names" namespace, the
7.7 - * the <name> parameter can contain a path that fully qualifies the name to
7.8 + * name parameter can contain a path that fully qualifies the name to
7.9 * be added. For example, if you previously have named an object "client"
7.10 * in the root namespace as above, you could name an object "under" that
7.11 * name by making a call like Names::Add ("/Names/client/eth0", obj). This
7.12 @@ -63,9 +63,9 @@
7.13 *
7.14 * \param name The name of the object you want to associate; which may be
7.15 * prepended with a path to that object.
7.16 - * \param obj A smart pointer to the object itself.
7.17 + * \param object A smart pointer to the object itself.
7.18 */
7.19 - static void Add (std::string name, Ptr<Object> obj);
7.20 + static void Add (std::string name, Ptr<Object> object);
7.21
7.22 /**
7.23 * \brief An intermediate form of Names::Add allowing you to provide a path to
7.24 @@ -94,7 +94,7 @@
7.25 * \param path A path name describing a previously named object under which
7.26 * you want this new name to be defined.
7.27 * \param name The name of the object you want to associate.
7.28 - * \param obj A smart pointer to the object itself.
7.29 + * \param object A smart pointer to the object itself.
7.30 *
7.31 * \see Names::Add (Ptr<Object> context, std::string name, Ptr<Object> object);
7.32 */
7.33 @@ -145,7 +145,7 @@
7.34 * \param context A smart pointer to an object that is used in place of the path
7.35 * under which you want this new name to be defined.
7.36 * \param name The name of the object you want to associate.
7.37 - * \param obj A smart pointer to the object itself.
7.38 + * \param object A smart pointer to the object itself.
7.39 */
7.40 static void Add (Ptr<Object> context, std::string name, Ptr<Object> object);
7.41
7.42 @@ -162,7 +162,7 @@
7.43 * level ("/Names") in the path.
7.44 *
7.45 * As well as specifying a name at the root of the "/Names" namespace, the
7.46 - * the <name> parameter can contain a path that fully qualifies the name to
7.47 + * name parameter can contain a path that fully qualifies the name to
7.48 * be changed. For example, if you previously have (re)named an object
7.49 * "server" in the root namespace as above, you could then rename an object
7.50 * "under" that name by making a call like Names::Rename ("/Names/server/csma", "eth0").
8.1 --- a/src/devices/emu/emu-net-device.cc Tue Jun 02 16:37:41 2009 +0200
8.2 +++ b/src/devices/emu/emu-net-device.cc Tue Jun 02 16:38:24 2009 +0200
8.3 @@ -173,7 +173,9 @@
8.4 m_sock (-1),
8.5 m_readThread (0),
8.6 m_ifIndex (std::numeric_limits<uint32_t>::max ()), // absurdly large value
8.7 - m_sll_ifindex (-1)
8.8 + m_sll_ifindex (-1),
8.9 + m_isBroadcast (true),
8.10 + m_isMulticast (false)
8.11 {
8.12 NS_LOG_FUNCTION (this);
8.13 Start (m_tStart);
8.14 @@ -293,7 +295,19 @@
8.15 {
8.16 NS_FATAL_ERROR ("EmuNetDevice::StartDevice(): " << m_deviceName << " is not in promiscuous mode");
8.17 }
8.18 -
8.19 + if ((ifr.ifr_flags & IFF_BROADCAST) != IFF_BROADCAST)
8.20 + {
8.21 + // We default m_isBroadcast to true but turn it off here if not
8.22 + // supported, because in the common case, overlying IP code will
8.23 + // assert during configuration time if this is false, before this
8.24 + // method has a chance to set it during runtime
8.25 + m_isBroadcast = false;
8.26 + }
8.27 + if ((ifr.ifr_flags & IFF_MULTICAST) == IFF_MULTICAST)
8.28 + {
8.29 + // This one is OK to enable at runtime
8.30 + m_isMulticast = true;
8.31 + }
8.32 //
8.33 // Now spin up a read thread to read packets.
8.34 //
8.35 @@ -918,7 +932,7 @@
8.36 bool
8.37 EmuNetDevice::IsBroadcast (void) const
8.38 {
8.39 - return true;
8.40 + return m_isBroadcast;
8.41 }
8.42
8.43 Address
8.44 @@ -930,7 +944,7 @@
8.45 bool
8.46 EmuNetDevice::IsMulticast (void) const
8.47 {
8.48 - return false;
8.49 + return m_isMulticast;
8.50 }
8.51
8.52 Address
9.1 --- a/src/devices/emu/emu-net-device.h Tue Jun 02 16:37:41 2009 +0200
9.2 +++ b/src/devices/emu/emu-net-device.h Tue Jun 02 16:38:24 2009 +0200
9.3 @@ -453,6 +453,18 @@
9.4 bool m_linkUp;
9.5
9.6 /**
9.7 + * Flag indicating whether or not the underlying net device supports
9.8 + * broadcast.
9.9 + */
9.10 + bool m_isBroadcast;
9.11 +
9.12 + /**
9.13 + * Flag indicating whether or not the underlying net device supports
9.14 + * multicast.
9.15 + */
9.16 + bool m_isMulticast;
9.17 +
9.18 + /**
9.19 * Callback to fire if the link changes state (up or down).
9.20 */
9.21 Callback<void> m_linkChangeCallback;
10.1 --- a/src/devices/wifi/propagation-loss-model.h Tue Jun 02 16:37:41 2009 +0200
10.2 +++ b/src/devices/wifi/propagation-loss-model.h Tue Jun 02 16:38:24 2009 +0200
10.3 @@ -355,7 +355,7 @@
10.4 FixedRssLossModel ();
10.5 virtual ~FixedRssLossModel ();
10.6 /**
10.7 - * \param RSS (dBm) the received signal strength
10.8 + * \param rss (dBm) the received signal strength
10.9 *
10.10 * Set the RSS.
10.11 */
11.1 --- a/src/devices/wifi/wifi.h Tue Jun 02 16:37:41 2009 +0200
11.2 +++ b/src/devices/wifi/wifi.h Tue Jun 02 16:38:24 2009 +0200
11.3 @@ -7,7 +7,7 @@
11.4 * The set of 802.11 models provided in ns-3 attempts to provide
11.5 * an accurate MAC-level implementation of the 802.11 specification
11.6 * and to provide a not-so-slow PHY-level model of the 802.11a
11.7 - * specification.
11.8 + * and 802.11b specifications.
11.9 *
11.10 * The current implementation provides roughly 4 levels of models:
11.11 * - the PHY layer models
11.12 @@ -52,7 +52,7 @@
11.13 * <td><b> Access class </b></td>
11.14 * </tr>
11.15 * <tr>
11.16 - * <td> 7 </b></td>
11.17 + * <td> 7 </td>
11.18 * <td> AC_VO </td>
11.19 * </tr>
11.20 * <tr>
11.21 @@ -96,9 +96,9 @@
11.22 *
11.23 * The PHY layer implements a single model in the ns3::WifiPhy class: the
11.24 * physical layer model implemented there is described fully in a paper titled
11.25 - * "Yet Another Network Simulator", available there: http://cutebugs.net/files/wns2-yans.pdf
11.26 - *
11.27 - * It also provides a set of Rate control algorithms:
11.28 + * "Yet Another Network Simulator", available at: http://cutebugs.net/files/wns2-yans.pdf and recently extended to cover 802.11b physical layer.
11.29 + *
11.30 + * The Wifi Model also provides a set of Rate control algorithms:
11.31 * - ns3::ArfMacStations
11.32 * - ns3::AArfMacStations
11.33 * - ns3::IdealMacStations
12.1 --- a/src/helper/mobility-helper.h Tue Jun 02 16:37:41 2009 +0200
12.2 +++ b/src/helper/mobility-helper.h Tue Jun 02 16:38:24 2009 +0200
12.3 @@ -125,7 +125,7 @@
12.4 * The input item should be a node instance to which a mobility model
12.5 * has already been aggregated (usually by a call to Install).
12.6 *
12.7 - * If this this stack is not empty when MobilityHelper::Install
12.8 + * If this stack is not empty when MobilityHelper::Install
12.9 * is called, the model from the top of the stack is used
12.10 * to create a ns3::HierarchicalMobilityModel to make the
12.11 * newly-created models define their positions relative to that
12.12 @@ -138,13 +138,13 @@
12.13 */
12.14 void PushReferenceMobilityModel (Ptr<Object> reference);
12.15 /**
12.16 - * \param reference item to push.
12.17 + * \param referenceName named item to push.
12.18 *
12.19 * Push an item on the top of the stack of "reference mobility models".
12.20 * The input item should be a node instance to which a mobility model
12.21 * has already been aggregated (usually by a call to Install).
12.22 *
12.23 - * If this this stack is not empty when MobilityHelper::Install
12.24 + * If this stack is not empty when MobilityHelper::Install
12.25 * is called, the model from the top of the stack is used
12.26 * to create a ns3::HierarchicalMobilityModel to make the
12.27 * newly-created models define their positions relative to that
13.1 --- a/src/helper/on-off-helper.h Tue Jun 02 16:37:41 2009 +0200
13.2 +++ b/src/helper/on-off-helper.h Tue Jun 02 16:38:24 2009 +0200
13.3 @@ -76,7 +76,7 @@
13.4 * Install an ns3::OnOffApplication on the node configured with all the
13.5 * attributes set with SetAttribute.
13.6 *
13.7 - * \param node The node on which an OnOffApplication will be installed.
13.8 + * \param nodeName The node on which an OnOffApplication will be installed.
13.9 * \returns Container of Ptr to the applications installed.
13.10 */
13.11 ApplicationContainer Install (std::string nodeName) const;
14.1 --- a/src/helper/point-to-point-helper.h Tue Jun 02 16:37:41 2009 +0200
14.2 +++ b/src/helper/point-to-point-helper.h Tue Jun 02 16:38:24 2009 +0200
14.3 @@ -218,8 +218,8 @@
14.4 NetDeviceContainer Install (std::string aName, Ptr<Node> b);
14.5
14.6 /**
14.7 - * \param aName Name of first node
14.8 - * \param bName Name of second node
14.9 + * \param aNode Name of first node
14.10 + * \param bNode Name of second node
14.11 *
14.12 * Saves you from having to construct a temporary NodeContainer.
14.13 */
15.1 --- a/src/internet-stack/ipv4-interface.h Tue Jun 02 16:37:41 2009 +0200
15.2 +++ b/src/internet-stack/ipv4-interface.h Tue Jun 02 16:38:24 2009 +0200
15.3 @@ -130,7 +130,7 @@
15.4 uint32_t AddAddress (Ipv4InterfaceAddress address);
15.5
15.6 /**
15.7 - * \param i Index of Ipv4InterfaceAddress to return
15.8 + * \param index Index of Ipv4InterfaceAddress to return
15.9 * \returns The Ipv4InterfaceAddress address whose index is i
15.10 */
15.11 Ipv4InterfaceAddress GetAddress (uint32_t index) const;
15.12 @@ -141,7 +141,7 @@
15.13 uint32_t GetNAddresses (void) const;
15.14
15.15 /**
15.16 - * \param i index of Ipv4InterfaceAddress to remove from address list.
15.17 + * \param index index of Ipv4InterfaceAddress to remove from address list.
15.18 */
15.19 void RemoveAddress (uint32_t index);
15.20
16.1 --- a/src/internet-stack/ipv4-l3-protocol.cc Tue Jun 02 16:37:41 2009 +0200
16.2 +++ b/src/internet-stack/ipv4-l3-protocol.cc Tue Jun 02 16:38:24 2009 +0200
16.3 @@ -164,10 +164,10 @@
16.4 }
16.5
16.6 void
16.7 -Ipv4L3Protocol::SetRoutingProtocol (Ptr<Ipv4RoutingProtocol> routing)
16.8 +Ipv4L3Protocol::SetRoutingProtocol (Ptr<Ipv4RoutingProtocol> routingProtocol)
16.9 {
16.10 NS_LOG_FUNCTION (this);
16.11 - m_routingProtocol = routing;
16.12 + m_routingProtocol = routingProtocol;
16.13 // XXX should check all interfaces to see if any were set to Up state
16.14 // prior to a routing protocol being added
16.15 if (GetStaticRouting () != 0)
17.1 --- a/src/internet-stack/ipv4-l3-protocol.h Tue Jun 02 16:37:41 2009 +0200
17.2 +++ b/src/internet-stack/ipv4-l3-protocol.h Tue Jun 02 16:38:24 2009 +0200
17.3 @@ -67,7 +67,8 @@
17.4 void SetNode (Ptr<Node> node);
17.5
17.6 // functions defined in base class Ipv4
17.7 - void SetRoutingProtocol (Ptr<Ipv4RoutingProtocol> routing);
17.8 +
17.9 + void SetRoutingProtocol (Ptr<Ipv4RoutingProtocol> routingProtocol);
17.10 Ptr<Ipv4RoutingProtocol> GetRoutingProtocol (void) const;
17.11
17.12 Ptr<Socket> CreateRawSocket (void);
18.1 --- a/src/node/ipv4-list-routing.h Tue Jun 02 16:37:41 2009 +0200
18.2 +++ b/src/node/ipv4-list-routing.h Tue Jun 02 16:38:24 2009 +0200
18.3 @@ -24,10 +24,8 @@
18.4 namespace ns3 {
18.5
18.6 /**
18.7 - * \ingroup ipv4
18.8 - */
18.9 -
18.10 -/**
18.11 + * \ingroup ipv4-routing
18.12 + *
18.13 * This class is a specialization of Ipv4RoutingProtocol that allows
18.14 * other instances of Ipv4RoutingProtocol to be inserted in a
18.15 * prioritized list. Routing protocols in the list are consulted one
18.16 @@ -50,9 +48,16 @@
18.17 * Values may range between -32768 and +32767.
18.18 */
18.19 virtual void AddRoutingProtocol (Ptr<Ipv4RoutingProtocol> routingProtocol, int16_t priority) = 0;
18.20 -
18.21 + /**
18.22 + * \return number of routing protocols in the list
18.23 + */
18.24 virtual uint32_t GetNRoutingProtocols (void) const = 0;
18.25 -
18.26 + /**
18.27 + * \return pointer to routing protocol indexed by
18.28 + * \param index index of protocol to return
18.29 + * \param priority output parameter, set to the priority of the protocol
18.30 + being returned
18.31 + */
18.32 virtual Ptr<Ipv4RoutingProtocol> GetRoutingProtocol (uint32_t index, int16_t& priority) const = 0;
18.33 };
18.34
19.1 --- a/src/node/ipv4-route.h Tue Jun 02 16:37:41 2009 +0200
19.2 +++ b/src/node/ipv4-route.h Tue Jun 02 16:38:24 2009 +0200
19.3 @@ -31,25 +31,53 @@
19.4 class NetDevice;
19.5
19.6 /**
19.7 + * \ingroup ipv4-routing
19.8 + *
19.9 *\brief Ipv4 route cache entry (similar to Linux struct rtable)
19.10 *
19.11 - * In the future, we will add other entries from struct dst_entry, struct rtable, and struct dst_ops as needed.
19.12 + * This is a reference counted object. In the future, we will add other
19.13 + * entries from struct dst_entry, struct rtable, and struct dst_ops as needed.
19.14 */
19.15 class Ipv4Route : public RefCountBase {
19.16 public:
19.17 Ipv4Route ();
19.18
19.19 + /**
19.20 + * \param dest Destination Ipv4Address
19.21 + */
19.22 void SetDestination (Ipv4Address dest);
19.23 + /**
19.24 + * \return Destination Ipv4Address of the route
19.25 + */
19.26 Ipv4Address GetDestination (void) const;
19.27
19.28 + /**
19.29 + * \param src Source Ipv4Address
19.30 + */
19.31 void SetSource (Ipv4Address src);
19.32 + /**
19.33 + * \return Source Ipv4Address of the route
19.34 + */
19.35 Ipv4Address GetSource (void) const;
19.36
19.37 + /**
19.38 + * \param gw Gateway (next hop) Ipv4Address
19.39 + */
19.40 void SetGateway (Ipv4Address gw);
19.41 + /**
19.42 + * \return Ipv4Address of the gateway (next hop)
19.43 + */
19.44 Ipv4Address GetGateway (void) const;
19.45
19.46 - // dst_entry.dev
19.47 + /**
19.48 + * Equivalent in Linux to dst_entry.dev
19.49 + *
19.50 + * \param outputDevice pointer to NetDevice for outgoing packets
19.51 + */
19.52 void SetOutputDevice (Ptr<NetDevice> outputDevice);
19.53 + /**
19.54 + * \return pointer to NetDevice for outgoing packets
19.55 + */
19.56 Ptr<NetDevice> GetOutputDevice (void) const;
19.57
19.58 #ifdef NOTYET
19.59 @@ -71,26 +99,54 @@
19.60 std::ostream& operator<< (std::ostream& os, Ipv4Route const& route);
19.61
19.62 /**
19.63 - *\brief Ipv4 multicast route cache entry (similar to Linux struct mfc_cache)
19.64 + * \ingroup ipv4-routing
19.65 + *
19.66 + * \brief Ipv4 multicast route cache entry (similar to Linux struct mfc_cache)
19.67 */
19.68 class Ipv4MulticastRoute : public RefCountBase {
19.69 public:
19.70 Ipv4MulticastRoute ();
19.71
19.72 + /**
19.73 + * \param group Ipv4Address of the multicast group
19.74 + */
19.75 void SetGroup (const Ipv4Address group);
19.76 + /**
19.77 + * \return Ipv4Address of the multicast group
19.78 + */
19.79 Ipv4Address GetGroup (void) const;
19.80
19.81 - void SetOrigin (const Ipv4Address group);
19.82 + /**
19.83 + * \param origin Ipv4Address of the origin address
19.84 + */
19.85 + void SetOrigin (const Ipv4Address origin);
19.86 + /**
19.87 + * \return Ipv4Address of the origin address
19.88 + */
19.89 Ipv4Address GetOrigin (void) const;
19.90
19.91 + /**
19.92 + * \param iif Parent (input interface) for this route
19.93 + */
19.94 void SetParent (uint32_t iif);
19.95 + /**
19.96 + * \return Parent (input interface) for this route
19.97 + */
19.98 uint32_t GetParent (void) const;
19.99
19.100 + /**
19.101 + * \param oif Outgoing interface index
19.102 + * \param ttl time-to-live for this route
19.103 + */
19.104 void SetOutputTtl (uint32_t oif, uint32_t ttl);
19.105 + /**
19.106 + * \param oif outgoing interface
19.107 + * \return TTL for this route
19.108 + */
19.109 uint32_t GetOutputTtl (uint32_t oif) const;
19.110
19.111 - static const uint32_t MAX_INTERFACES = 16;
19.112 - static const uint32_t MAX_TTL = 255;
19.113 + static const uint32_t MAX_INTERFACES = 16; // Maximum number of multicast interfaces on a router
19.114 + static const uint32_t MAX_TTL = 255; // Maximum time-to-live (TTL)
19.115
19.116 private:
19.117 Ipv4Address m_group; // Group
20.1 --- a/src/node/ipv4-routing-protocol.h Tue Jun 02 16:37:41 2009 +0200
20.2 +++ b/src/node/ipv4-routing-protocol.h Tue Jun 02 16:38:24 2009 +0200
20.3 @@ -31,7 +31,9 @@
20.4 class NetDevice;
20.5
20.6 /**
20.7 - * \ingroup ipv4
20.8 + * \ingroup node
20.9 + * \defgroup ipv4-routing Ipv4 Routing
20.10 + *
20.11 * Abstract base class for Ipv4 routing protocols. Defines two
20.12 * virtual functions for packet routing and forwarding. The first,
20.13 * RouteOutput(), is used for locally originated packets, and the second,
21.1 --- a/src/node/ipv4-routing-table-entry.h Tue Jun 02 16:37:41 2009 +0200
21.2 +++ b/src/node/ipv4-routing-table-entry.h Tue Jun 02 16:38:24 2009 +0200
21.3 @@ -29,8 +29,10 @@
21.4 namespace ns3 {
21.5
21.6 /**
21.7 - * \ingroup internetStack
21.8 - * \brief A record of an IPv4 routing table entry for Ipv4GlobalRouting and Ipv4StaticRouting
21.9 + * \ingroup ipv4-routing
21.10 + *
21.11 + * A record of an IPv4 routing table entry for Ipv4GlobalRouting and
21.12 + * Ipv4StaticRouting. This is not a reference counted object.
21.13 */
21.14 class Ipv4RoutingTableEntry {
21.15 public:
21.16 @@ -38,50 +40,95 @@
21.17 * \brief This constructor does nothing
21.18 */
21.19 Ipv4RoutingTableEntry ();
21.20 -
21.21 /**
21.22 * \brief Copy Constructor
21.23 * \param route The route to copy
21.24 */
21.25 Ipv4RoutingTableEntry (Ipv4RoutingTableEntry const &route);
21.26 -
21.27 /**
21.28 * \brief Copy Constructor
21.29 * \param route The route to copy
21.30 */
21.31 Ipv4RoutingTableEntry (Ipv4RoutingTableEntry const *route);
21.32 -
21.33 + /**
21.34 + * \return True if this route is a host route; false otherwise
21.35 + */
21.36 bool IsHost (void) const;
21.37 /**
21.38 * \return The IPv4 address of the destination of this route
21.39 */
21.40 - Ipv4Address GetDest (void) const;
21.41 -
21.42 bool IsNetwork (void) const;
21.43 - Ipv4Address GetDestNetwork (void) const;
21.44 - Ipv4Mask GetDestNetworkMask (void) const;
21.45 /**
21.46 * \return True if this route is a default route; false otherwise
21.47 */
21.48 bool IsDefault (void) const;
21.49 -
21.50 + /**
21.51 + * \return True if this route is a gateway route; false otherwise
21.52 + */
21.53 bool IsGateway (void) const;
21.54 + /**
21.55 + * \return address of the gateway stored in this entry
21.56 + */
21.57 Ipv4Address GetGateway (void) const;
21.58 -
21.59 + /**
21.60 + * \return The IPv4 address of the destination of this route
21.61 + */
21.62 + Ipv4Address GetDest (void) const;
21.63 + /**
21.64 + * \return The IPv4 network number of the destination of this route
21.65 + */
21.66 + Ipv4Address GetDestNetwork (void) const;
21.67 + /**
21.68 + * \return The IPv4 network mask of the destination of this route
21.69 + */
21.70 + Ipv4Mask GetDestNetworkMask (void) const;
21.71 + /**
21.72 + * \return The Ipv4 interface number used for sending outgoing packets
21.73 + */
21.74 uint32_t GetInterface (void) const;
21.75 -
21.76 + /**
21.77 + * \return An Ipv4RoutingTableEntry object corresponding to the input parameters.
21.78 + * \param dest Ipv4Address of the destination
21.79 + * \param nextHop Ipv4Address of the next hop
21.80 + * \param interface Outgoing interface
21.81 + */
21.82 static Ipv4RoutingTableEntry CreateHostRouteTo (Ipv4Address dest,
21.83 Ipv4Address nextHop,
21.84 uint32_t interface);
21.85 + /**
21.86 + * \return An Ipv4RoutingTableEntry object corresponding to the input parameters.
21.87 + * \param dest Ipv4Address of the destination
21.88 + * \param interface Outgoing interface
21.89 + */
21.90 static Ipv4RoutingTableEntry CreateHostRouteTo (Ipv4Address dest,
21.91 uint32_t interface);
21.92 + /**
21.93 + * \return An Ipv4RoutingTableEntry object corresponding to the input parameters.
21.94 + * \param network Ipv4Address of the destination network
21.95 + * \param networkMask Ipv4Mask of the destination network mask
21.96 + * \param nextHop Ipv4Address of the next hop
21.97 + * \param interface Outgoing interface
21.98 + */
21.99 static Ipv4RoutingTableEntry CreateNetworkRouteTo (Ipv4Address network,
21.100 Ipv4Mask networkMask,
21.101 Ipv4Address nextHop,
21.102 uint32_t interface);
21.103 + /**
21.104 + * \return An Ipv4RoutingTableEntry object corresponding to the input parameters.
21.105 + * \param network Ipv4Address of the destination network
21.106 + * \param networkMask Ipv4Mask of the destination network mask
21.107 + * \param interface Outgoing interface
21.108 + */
21.109 static Ipv4RoutingTableEntry CreateNetworkRouteTo (Ipv4Address network,
21.110 Ipv4Mask networkMask,
21.111 uint32_t interface);
21.112 + /**
21.113 + * \return An Ipv4RoutingTableEntry object corresponding to the input
21.114 + * parameters. This route is distinguished; it will match any
21.115 + * destination for which a more specific route does not exist.
21.116 + * \param nextHop Ipv4Address of the next hop
21.117 + * \param interface Outgoing interface
21.118 + */
21.119 static Ipv4RoutingTableEntry CreateDefaultRoute (Ipv4Address nextHop,
21.120 uint32_t interface);
21.121
21.122 @@ -108,7 +155,8 @@
21.123 std::ostream& operator<< (std::ostream& os, Ipv4RoutingTableEntry const& route);
21.124
21.125 /**
21.126 - * \ingroup internetStack
21.127 + * \ingroup ipv4-routing
21.128 + *
21.129 * \brief A record of an IPv4 multicast route for Ipv4GlobalRouting and Ipv4StaticRouting
21.130 */
21.131 class Ipv4MulticastRoutingTableEntry {
21.132 @@ -123,43 +171,42 @@
21.133 * \param route The route to copy
21.134 */
21.135 Ipv4MulticastRoutingTableEntry (Ipv4MulticastRoutingTableEntry const &route);
21.136 -
21.137 /**
21.138 * \brief Copy Constructor
21.139 * \param route The route to copy
21.140 */
21.141 Ipv4MulticastRoutingTableEntry (Ipv4MulticastRoutingTableEntry const *route);
21.142 -
21.143 /**
21.144 * \return The IPv4 address of the source of this route
21.145 */
21.146 Ipv4Address GetOrigin (void) const;
21.147 -
21.148 /**
21.149 * \return The IPv4 address of the multicast group of this route
21.150 */
21.151 Ipv4Address GetGroup (void) const;
21.152 -
21.153 /**
21.154 * \return The IPv4 address of the input interface of this route
21.155 */
21.156 uint32_t GetInputInterface (void) const;
21.157 -
21.158 /**
21.159 * \return The number of output interfaces of this route
21.160 */
21.161 uint32_t GetNOutputInterfaces (void) const;
21.162 -
21.163 /**
21.164 * \return A specified output interface.
21.165 */
21.166 uint32_t GetOutputInterface (uint32_t n) const;
21.167 -
21.168 /**
21.169 * \return A vector of all of the output interfaces of this route.
21.170 */
21.171 std::vector<uint32_t> GetOutputInterfaces (void) const;
21.172 -
21.173 + /**
21.174 + * \return Ipv4MulticastRoutingTableEntry corresponding to the input parameters.
21.175 + * \param origin Source address for the multicast route
21.176 + * \param group Group destination address for the multicast route
21.177 + * \param inputInterface Input interface that multicast datagram must be received on
21.178 + * \param outputInterfaces vector of output interfaces to copy and forward the datagram to
21.179 + */
21.180 static Ipv4MulticastRoutingTableEntry CreateMulticastRoute (Ipv4Address origin,
21.181 Ipv4Address group, uint32_t inputInterface,
21.182 std::vector<uint32_t> outputInterfaces);
22.1 --- a/src/node/ipv4-static-routing.h Tue Jun 02 16:37:41 2009 +0200
22.2 +++ b/src/node/ipv4-static-routing.h Tue Jun 02 16:38:24 2009 +0200
22.3 @@ -44,6 +44,8 @@
22.4 class Ipv4MulticastRoutingTableEntry;
22.5
22.6 /**
22.7 + * \ingroup ipv4-routing
22.8 + *
22.9 * \brief Static routing protocol for IP version 4 stacks.
22.10 *
22.11 * In ns-3 we have the concept of a pluggable routing protocol. Routing
23.1 --- a/src/node/ipv4.h Tue Jun 02 16:37:41 2009 +0200
23.2 +++ b/src/node/ipv4.h Tue Jun 02 16:38:24 2009 +0200
23.3 @@ -37,9 +37,7 @@
23.4 /**
23.5 * \ingroup node
23.6 * \defgroup ipv4 Ipv4
23.7 - */
23.8 -
23.9 -/**
23.10 + *
23.11 * \brief Access to the Ipv4 forwarding table, interfaces, and configuration
23.12 *
23.13 * This class defines the API to manipulate the following aspects of
23.14 @@ -84,7 +82,7 @@
23.15 * registered. If you want to add multiple routing protocols, you must
23.16 * add them to a Ipv4ListRoutingProtocol directly.
23.17 *
23.18 - * \param routing smart pointer to Ipv4RoutingProtocol object
23.19 + * \param routingProtocol smart pointer to Ipv4RoutingProtocol object
23.20 */
23.21 virtual void SetRoutingProtocol (Ptr<Ipv4RoutingProtocol> routingProtocol) = 0;
23.22
23.23 @@ -132,7 +130,8 @@
23.24 * has an Ipv4 address within the prefix specified by the input
23.25 * address and mask parameters
23.26 *
23.27 - * \param addr The IP address assigned to the interface of interest.
23.28 + * \param address The IP address assigned to the interface of interest.
23.29 + * \param mask The IP prefix to use in the mask
23.30 * \returns The interface number of the Ipv4 interface with the given
23.31 * address or -1 if not found.
23.32 *
23.33 @@ -206,7 +205,7 @@
23.34 virtual bool IsUp (uint32_t interface) const = 0;
23.35
23.36 /**
23.37 - * \param i interface Interface number of Ipv4 interface
23.38 + * \param interface Interface number of Ipv4 interface
23.39 *
23.40 * Set the interface into the "up" state. In this state, it is
23.41 * considered valid during Ipv4 forwarding.
24.1 --- a/src/routing/olsr/olsr-repositories.h Tue Jun 02 16:37:41 2009 +0200
24.2 +++ b/src/routing/olsr/olsr-repositories.h Tue Jun 02 16:38:24 2009 +0200
24.3 @@ -21,7 +21,7 @@
24.4 */
24.5
24.6 ///
24.7 -/// \file OLSR_olsr-repositories.h
24.8 +/// \file olsr-repositories.h
24.9 /// \brief Here are defined all data structures needed by an OLSR node.
24.10 ///
24.11