From c689bb030388184bcdf72775a93c42300fe107ba Mon Sep 17 00:00:00 2001 From: Tom Henderson Date: Sat, 30 May 2009 10:38:27 -0700 Subject: [PATCH] some revisions to the routing section of the manual --- doc/manual/Makefile | 2 + doc/manual/figures/routing-specialization.dia | Bin 0 -> 2723 bytes doc/manual/figures/routing.dia | Bin 0 -> 3091 bytes doc/manual/routing.texi | 497 ++++++++---------- 4 files changed, 228 insertions(+), 271 deletions(-) create mode 100644 doc/manual/figures/routing-specialization.dia create mode 100644 doc/manual/figures/routing.dia diff --git a/doc/manual/Makefile b/doc/manual/Makefile index c1bc99b92..c8c46674c 100644 --- a/doc/manual/Makefile +++ b/doc/manual/Makefile @@ -17,6 +17,8 @@ IMAGES_EPS = \ $(FIGURES)/node.eps \ $(FIGURES)/buffer.eps \ $(FIGURES)/sockets-overview.eps \ + $(FIGURES)/routing.eps \ + $(FIGURES)/routing-specialization.eps \ $(FIGURES)/testbed.eps \ $(FIGURES)/emulated-channel.eps \ $(FIGURES)/snir.eps \ diff --git a/doc/manual/figures/routing-specialization.dia b/doc/manual/figures/routing-specialization.dia new file mode 100644 index 0000000000000000000000000000000000000000..9c8122593e94bbbd0e48988a5640a950675f1a3f GIT binary patch literal 2723 zcmZwGc_0%E1IKZah=-NrK5{Hqi8*o~Il>&t{kX~%=1Q(Pk|jr&D~4r=IU@IcJ|h`( zlxq`u6=`d;VUG5=-sgSaKi__z|9<~}#WUEM{yUbfQuokxb-olDUE%zU6{mE&al*a8 z5;-lFpy+3E)kU573pZ6dwOWbjTAzOYqh-Y3VIt;*H^GH6J0dLfhpC%5BfF;Q%F2)W zXS|NfP8LBC# zoRfamSax={tlOA=X&ndeik!%L-O;Uoe>#C4-Lr7HD3KYOZAlF>f`i zdj1T=uaoXq+3)aa`iBJnXBIA+X(+XA%-=0SMRC8ahIX~It?t1d_zAu@HpT2jQRtQl2FlZa%7$_ERe`WH??@ zDO~wOASh^NKf>#>w~EXd&T2-1ALV5I+DS1@MnSQvJgEU}tqBm!3U`p>S#*~<2&gS2 z3^vCaKNdF|2V|b1QXV6jb`fRpPVelM9(KPYz{>rM6c4fI#cq~^+^X(S8aXL8k^S2P zp;q@wfF!h)imxFJ{!Q|s4kX0QEaV(6#>5u&O!^({)TBarCY|FS6c;S3?zPL7WC5mP zJKUGk$35S^Zcs_jX)KoQP3+ROf{e1cX-v1dtj#4B-OAWLJw2(6svH0Wh-7!lrCMmf zmR5=R9w=m>>RTD#xQ=m`otmr3R>l;vu<&IBVWF0c`Xmi1byQ2{NHV481V`Q%#7iH% zOV9Ov7@trnt9A z7kF3R*G$|Iu=ogNw!ZzF z4{MA~Z(iG_35GSxC9VV1y<(mUVvPv52EL?! z1sE?d?+ay?UC$>a0sz43iExzZ&fceEK`)mPz@^e>mCw0Yz!B%NRS>d z-JuXQi@1Jb7jOWwDr7Hy0{whHzV-Wy=zDk#l9spym2oaaxd86;R73RnN_FJ=Ni(5n z+`dQ8CB-I-j4qUc$*qZnQja+twR= zGxQ9(G2Hx8aCc7BHCJ3l%@~CB6D-|e7W*i_dL~Fay}PVPYb0%7^UcI0gy$$e+MuS; z)wbf)fz8=%XxOEPFWQ=g@yaah(m!%IpX96)pgkOQK1S}IggtQt4hXd^cP;pf=nA}+ z<|d4d+Rg!dS-8Wwz)n0rYPpNBdgd01wQk$W zX}-3g?q~Ng0Bs1X{+$-4m#p`0Jo94aRm0_@Q_#C#Fddk1n25~CE@%0UK3ePEG5E)hGLzCc-v2CcgzeoJU8D1+{Tw+N9M&?dax*^shU%mJ97ccZj=0jKP!F1*v$o{e_W}wxJ8?1nJ@@6KxY1Tm#Y}?T z{KpMgfJ@kCT6|%$z5h}O=p0exw~o(8Q1=>(kyxQqzbF->-KkZ|`BLw(t}nSA%n?^K z9ieJNyKzhU3CDCgaCOk*)#R8?=BNPGgN^5R^jXvM2c@akEE~DpPjrd5+vNpck3Y!U z8lv_VJ`OIzj*L7tf}CxCPB5(Ba@*yjh|l*9T+_i1PBkG$21Eb)@&6E0KSF3(1ktM6 zS*$?R+7v<5XQ?MIcWVswWwr6qD=PPZ#E~24{ zY|8hojZH9T(Y*?Bm`amX|L#>iyUkKTVt2A^uJnA*d8$z?uZrSC8Mhg>ZBl|<93K1= z=GvS3bu>9xl6b@Hn{EcP;QLM;oHEy{nvPQ!Aqz@86oae27_#>`nY@}geD#lk!w_Ee z-LzmgBvyI+qwD>RJF$Tr$Qr&`ZE|(9?N}z7L*riXu4Y4fK!1bu!~;CFbr!{ZTg6%P z43f*Tn7_Ui5h-Xm6$-a{(VJH2^i^4*CF9Qm16NyrehHxq^xE*AuvF#_hw;Si_7rV* z-HDWW$_u|f@2MZQRorW;Wp70vBFp?azuSy*6zG8Ow{O|l#nhQCXzAv13Jv5--D;A} z5!1$Z;<7j-*r1Mug2m^N7K?2j&o7>0)+w`9QDsZhR9@SN&KoHp;HFUkI|% zjX;=bPjK`U`Q%2VHMK|>!of;Qc#vrPboD#rrUOyzark9Q?X3_eq^+>Yh~cN>!OAh? zE8}fk?QHTax(n)g7!DR2bm~{>gM~g%uYf)~o>ZLqYdhD++Fu~Nw8&I5CV=)M8cj)+ zcZ4h*%@=x)Y=1oZiZ z9jyrh-cRgAi#JaT12pP}IzpGo5a^(jl+JT-DF!mcDK#%VhgA`%IC+`*(Wn|m64i6Q zFpKa?Ce=3ZZ6_Gd1=)c_`!Drx_tA$(%(8}j?~wY%#7ECR45C=diXQW1sfrdvmf!qv zplsE~1;m*B2iY|6DOd{Fgg3Ji{z}0)>K+1NjHE&m@yV57d^3J=Xsvv$oS#x|%^3LL zB08Tiz#S-O*WyVon2OjAMq<>glx&n{RyP9@!1O(j7HDjmtoLKK#_Z@_YYJruV4k(w v;@U;tf0wg{T0`+uP*I+TlVzz9Q}37SkJJBF;g4V({5(T9IGPgXnV9|!nmSSx literal 0 HcmV?d00001 diff --git a/doc/manual/figures/routing.dia b/doc/manual/figures/routing.dia new file mode 100644 index 0000000000000000000000000000000000000000..0c0845329af82c816c1e56670aa7a2e1edfa39fe GIT binary patch literal 3091 zcmV+u4D9nCiwFP!000001MOW~Z`-&Me)q2syucy_QigYt^|p&HisBU5vki9J=RmPp zSEq{PBg;v%59hZZ4&~-z)45otH)?61Y2`BfNNMJq;cz(m<=3xgMRIQHd0v$-hXmna zV#;wf$;;`>;l~eepR3`ouLi$N^6Z8EGp)0;#QsJ(hpU&v&rLIXaddQXae<1{p3n2s z!uUp?m(9+)zuZmtt53(V_w}!Ll!msqjpkvZj4O})<@Ek)vT~BuljM2wdtRF1 zwcBBxj(qZR_#WTBKdUpcy;p(fb_!WJEli8S zk+vUpn6`h9xI{!?Vqu98SZ#+quFCSnloL0XN6v7)5ex~&gYCGs8&A178_!mU;Zs(> z1{_^K{0B(G2lKVLAq`|H4Wz3yr1pu}$HYTQgTs(Wj|fI7QOe?}E%6$-4fk-}N}Ell z+c}4~+O7DJ!^Pax&*!sjY=#>=$~$OylTEM6#s>=DC!eyjytuSu%gXsMnKzff7izft z)qk1d+%)+(d;b2k$p3rWZ+ZMkKAU{{**lhNdx??4w?Dia=xt$qpg?W|blXJTv5vvG z8<2GXr{$UPKUHHnVtFSYh~hOskJFKJH>6c9xgHAJ3p3H~%)}(nc$$XgrWS=#F(L#B zD|{M}v=8+3#nh!KB0=q)pgeLJDe5Ux)Nj>Sk0;H#G8ExR9NHg}hGZxUz#WW8#fV|> zZHY#5TZ%G;IXf9wmOAQ?Q*$tGMZP}0tJSzb;+F2x4p?h!u>!W`Jm#OPixW?{_5N5= zK-* z*Np6UXsCfk#Kmms01j$2dl?V-LT)WTgA=Xu_XfJ00 ztt+)^dlQV1KAKy-Ro{`{n0Dr5yZ8m-QbFCuZzzmfLB@!}LPYf;B=e!RE*oq-4`xe`F&P{fG)2kB zH^z;1;Glgr`XU5w#_H#ohM+tjS} z2>yvJ&W${p)y+v(*VV;lF{89|=O=|Jr*}CP7>Vv6_c$+GV^}!|b&syP4tIyHAv)im z-4KfI?D|+|nt{?W5!Cllh-mF_tZ`u@rV+J>hlC)_0@I3rivD&mAQfpP(#nrbD+KQ# z%;jQ1I_Q#$Y9uw64hTy+0#vCK#O4*1GBmOH=ICjLVLa?fu}Wc|`-xjcZB`f_Rq-jP zV&`1A<>qRNI1Q|eT4Ae;3{gd$E~*r+EwJW1v@Uul>DO5SV@zq($Ec56q^5Sx0Am#V zOc^+C-l7P%hKB$WjwJNUXq46Crw;RP*A6qptUhX0~V!;x0*W*4iMc zk+=HDTYLu_B}}z^5|p>T;SeMh?3QT67^Q$K_0#9Aa?X-EyGZ8M_={=gk)%SC)CRGP zB-O*sT+%rgkTb}bg9PH>F;WeSKP@mBSx`kJcd$~1j?4I_=&{|}<;SY+LsT&;^J7Oz zfsi8nC>DW!DU9$ z(D?{TXaGu6-sU4JQFT9b;`bcHnb4>|S z5R0Ipsq6~JQ5l2eL7Bq7AK@|IG*Z^xl;s!FNLhWPEVhF%t+WP=;qYPFB@Tm(Q|+<` z8AZ4c38x2^rl$6uO`i?^FwGltp2t<<9*D{>nvtmbNL1acO-eY!4smc9G-(8ImH~Gx zt#d`Jhc7gRI#@V;`c(C&8Jqmv!~pyr%1rttGV)U&`KfbuDP_*3u{1%0^3yjQD|J9m z7LQP^09U5{2xI-uVkz9c9nlkgIqwxT7hL_>Y?HhMw(@CvGfytG}%=*6B_2Y%6v zmiI|pUh{Wu>J8cUv~x}@fp^wH&S==}At*een1b9e2)0toQw}sGTP8rCn!iu(O|$n; z&eKlA%h@2ja(971>o+JtD9l3L-J_i#5o_%pca{KrixZHC`DS6mYlHCqU(8zHL)QA8 zirP8Vm$WA&gDWaQDdvy}#c7(3sP$Z_KD2@_i43Z$-syQ13%j=gkktUZr-DB$GT}7a z-R*#h>}+M!(;xfb8ta_!YB`^GqWp&i+bCk3Gfil8m9#Gwz7dgthk@z8E$ z73A1jRGFPFme~&8(#(}hRii5G%TNIZG={+T8Anu82Cyl8`fKIit8rGmF-30g|G~4w zUK9{DiOc2iFGTeTXIw4!cD2mtE{fp+kEp_97@uJ-7<7I z46?%@1}`OZ6>nG{_6*&@jCbX1(If}U^BTt)94dpu8ixaZwK9r_%=WUC=o8sUU_C5j z$;1wpMf6Z2A;h+a?jM?GD7j7n36oThU^RjUgYJM=s4{y)U-*EqwCbiXt~}&MWf{zXCcEDG;%N! zX-(Z5G->LN+^4!1@1t98>K!~AyqjHZ^<8}#X=@KPjXYu+Ije`9#qkd6bVDv#ikJ*r zrklH^UJ8uG;j|Z}7PJ?Pwe+VF@V}sFWHy@>mKz%TB%+hGkILQa0vgGxk7U(3DVw;{ z>hOv}6_Ty4VJOfQVF*Ja6}%Ov4}A5Zwlp!T>Si!omJS&l7&Jx6$2Z5(y$Zi7^a^QY htbdfT+Up{_H1(@Ndtv`f>+I~+;Q#C>{# >::iterator Iterator; + for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++) + { + Ptr node = *i; + Ptr globalRouter = CreateObject (node); + node->AggregateObject (globalRouter); + } +@end verbatim + +This interface is later queried and used to generate a Link State +Advertisement for each router, and this link state database is +fed into the OSPF shortest path computation logic. The Ipv4 API +is finally used to populate the routes themselves. + +@node Unicast routing +@section Unicast routing + +There are presently four routing protocols defined: +@itemize @bullet +@item class Ipv4StaticRouting (covering both unicast and multicast) +@item Optimized Link State Routing (a MANET protocol defined in +@uref{http://www.ietf.org/rfc/rfc3626.txt,,RFC 3626}) +@item class Ipv4ListRouting (used to store a prioritized list of routing +protocols) +@item class Ipv4GlobalRouting (used to store routes computed by the global +route manager, if that is used) +@end itemize + +In the future, this architecture should also allow someone to implement +a Linux-like implementation with routing cache, or a Click modular +router, but those are out of scope for now. + +@subsection Ipv4ListRouting + +This section describes the current default ns-3 Ipv4RoutingProtocol. Typically, multiple routing protocols are supported in user space and coordinate to write a single forwarding table in the kernel. Presently in @command{ns-3}, the implementation instead allows for multiple routing @@ -50,163 +223,54 @@ where more information than destination IP address (e.g., source routing) is used to determine the next hop, and on-demand routing approaches where packets must be cached. -There are presently two routing protocols defined: -@itemize @bullet -@item class Ipv4StaticRouting (covering both unicast and multicast) -@item Optimized Link State Routing (a MANET protocol defined in -@uref{http://www.ietf.org/rfc/rfc3626.txt,,RFC 3626}) -@end itemize -but first we describe how multiple routing protocols are supported. +@subsubsection Ipv4ListRouting::AddRoutingProtocol -@subsection class Ipv4RoutingProtocol - -@code{class Ipv4RoutingProtocol} derives from ns-3 Object which means -that it supports interface aggregation and reference counting. Routing -protocols should inherit from this class, defined in src/node/ipv4.cc. - -The main function that must be supported by these protocols is called -@code{RequestRoute}. -@verbatim - * This method is called whenever a node's IPv4 forwarding engine - * needs to lookup a route for a given packet and IP header. - * - * The routing protocol implementation may determine immediately it - * should not be handling this particular the route request. For - * instance, a routing protocol may decline to search for routes for - * certain classes of addresses, like link-local. In this case, - * RequestRoute() should return false and the routeReply callback - * must not be invoked. - * - * If the routing protocol implementations assumes it can provide - * the requested route, then it should return true, and the - * routeReply callback must be invoked, either immediately before - * returning true (synchronously), or in the future (asynchronous). - * The routing protocol may use any information available in the IP - * header and packet as routing key, although most routing protocols - * use only the destination address (as given by - * ipHeader.GetDestination ()). The routing protocol is also - * allowed to add a new header to the packet, which will appear - * immediately after the IP header, although most routing do not - * insert any extra header. - */ - virtual bool RequestRoute (uint32_t interface, - const Ipv4Header &ipHeader, - Ptr packet, - RouteReplyCallback routeReply) = 0; -@end verbatim - -This class also provides a typedef (used above) for a special Callback -that will pass to the callback function the Ipv4Route that is found (see the -Doxygen documentation): -@verbatim - typedef Callback, const Ipv4Header&> RouteReplyCallback; -@end verbatim - -@subsection Ipv4::AddRoutingProtocol - -Class Ipv4 provides a pure virtual function declaration for the +Class Ipv4ListRouting provides a pure virtual function declaration for the method that allows one to add a routing protocol: @verbatim void AddRoutingProtocol (Ptr routingProtocol, int16_t priority); @end verbatim -This method is implemented by class Ipv4L3Protocol in the internet-stack +This method is implemented by class Ipv4ListRoutingImpl in the internet-stack module. The priority variable above governs the priority in which the routing protocols are inserted. Notice that it is a signed int. -When the class Ipv4L3Protocol is instantiated, a single routing -protocol (Ipv4StaticRouting, introduced below) is added at priority -zero. Internally, a list of Ipv4RoutingProtocols is stored, and +By default in ns-3, the helper classes will instantiate a Ipv4ListRoutingImpl +object, and add to it an Ipv4StaticRoutingImpl object at priority zero. +Internally, a list of Ipv4RoutingProtocols is stored, and and the routing protocols are each consulted in decreasing order of priority to see whether a match is found. Therefore, if you want your Ipv4RoutingProtocol to have priority lower than the static routing, insert it with priority less than 0; e.g.: @verbatim - m_ipv4->AddRoutingProtocol (m_routingTable, -10); + Ptr myRoutingProto = CreateObject (); + listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10); @end verbatim -@subsection Ipv4L3Protocol::Lookup +Upon calls to RouteOutput() or RouteInput(), the list routing object will +search the list of routing protocols, in priority order, until a route +is found. Such routing protocol will invoke the appropriate callback +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 +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. -The main function for obtaining a route is shown below: @verbatim -Ipv4L3Protocol::Lookup ( - uint32_t interface, - Ipv4Header const &ipHeader, - Ptr packet, - Ipv4RoutingProtocol::RouteReplyCallback routeReply) + olsr::EnableAllNodes (); // Start OLSR on all nodes + olsr::EnableNodes(InputIterator begin, InputIterator end); // Start on + // a list of nodes + olsr::EnableNode (Ptr node); // Start OLSR on "node" only @end verbatim -This function will search the list of routing protocols, in priority order, -until a route is found. It will then invoke the RouteReplyCallback -and no further routing protocols will be searched. If the caller does -not want to constrain the possible interface, it can be wildcarded -as such: -@verbatim - Lookup (Ipv4RoutingProtocol::IF_INDEX_ANY, ipHeader, packet, routeReply); -@end verbatim - -@node Roadmap and Future work -@section Roadmap and Future work - -Some goals for future support are: - -Users should be able to trace (either debug print, or redirect to a trace -file) the routing table in a format such as used in an -Unix implementation: -@verbatim -# netstat -nr (or # route -n) -Kernel IP routing table -Destination Gateway Genmask Flags MSS Window irtt Iface -127.0.0.1 * 255.255.255.255 UH 0 0 0 lo -172.16.1.0 * 255.255.255.0 U 0 0 0 eth0 -172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0 - -# ip route show -192.168.99.0/24 dev eth0 scope link -127.0.0.0/8 dev lo scope link -default via 192.168.99.254 dev eth0 -@end verbatim - -Global computation of multicast routing should be implemented as well. -This would ignore group membership and ensure that a copy of every -sourced multicast datagram would be delivered to each node. -This might be implemented as an RPF mechanism that functioned on-demand -by querying the forwarding table, -and perhaps optimized by a small multicast forwarding cache. It is -a bit trickier to implement over wireless links where the input -interface is the same as the output interface; other aspects of the -packet must be considered and the forwarding logic slightly changed -to allow for forwarding out the same interface. - -In the future, work on bringing XORP or quagga routing to ns, but it will -take several months to port and enable. - -There are presently no roadmap plans for IPv6. - -@node Static routing -@section Static routing - -The internet-stack module provides one routing protocol (Ipv4StaticRouting) -by default. This routing protocol allows one to add unicast or multicast -static routes to a node. - -@node Unicast routing -@section Unicast routing - -The unicast static routing API may be accessed via the functions -@verbatim -void Ipv4::AddHostRouteTo () -void Ipv4::AddNetworkRouteTo () -void Ipv4::SetDefaultRoute () -uint32_t Ipv4::GetNRoutes () -Ipv4Route Ipv4::GetRoute () -@end verbatim - -@uref{http://www.nsnam.org/doxygen/index.html,,Doxygen} documentation -provides full documentation of these methods. These methods are forwarding -functions to the actual implementation in Ipv4StaticRouting, when using -the internet-stack module. +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. @node Multicast routing @section Multicast routing @@ -288,113 +352,4 @@ remove multicast routes: void RemoveMulticastRoute (uint32_t index); @end verbatim -@node Global centralized routing -@section Global centralized routing - -Presently, global centralized IPv4 @emph{unicast} routing over both -point-to-point and shared (CSMA) links is supported. -The global centralized routing will be modified in the future to -reduce computations once profiling finds the performance bottlenecks. - -@node Global Unicast Routing API -@section Global Unicast Routing API - -The public API is very minimal. User scripts include the following: -@verbatim -#include "ns3/global-route-manager.h" -@end verbatim - -After IP addresses are configured, the following function call will -cause all of the nodes that have an Ipv4 interface to receive -forwarding tables entered automatically by the GlobalRouteManager: -@verbatim - GlobalRouteManager::PopulateRoutingTables (); -@end verbatim - -@emph{Note:} A reminder that the wifi NetDevice is not yet supported -(only CSMA and PointToPoint). - -It is possible to call this function again in the midst of a simulation -using the following additional public function: -@verbatim - GlobalRouteManager::RecomputeRoutingTables (); -@end verbatim -which flushes the old tables, queries the nodes for new interface information, -and rebuilds the routes. - -For instance, this scheduling call will cause the tables to be rebuilt -at time 5 seconds: -@verbatim - Simulator::Schedule (Seconds (5),&GlobalRouteManager::RecomputeRoutingTables); -@end verbatim - -@node Global Routing Implementation -@section Global Routing Implementation - -A singleton object (GlobalRouteManager) is responsible for populating -the static routes on each node, using the public Ipv4 API of that node. -It queries each node in the topology for a "globalRouter" interface. -If found, it uses the API of that interface to obtain a "link state -advertisement (LSA)" for the router. Link State Advertisements -are used in OSPF routing, and we follow their formatting. - -The GlobalRouteManager populates a link state database with LSAs -gathered from the entire topology. Then, for each router in the topology, -the GlobalRouteManager executes the OSPF shortest path first (SPF) -computation on the database, and populates the routing tables on each -node. - -The quagga (http://www.quagga.net) OSPF implementation was used as the -basis for the routing computation logic. -One benefit of following an existing OSPF SPF implementation is that -OSPF already has defined link state advertisements for all common -types of network links: -@itemize @bullet -@item point-to-point (serial links) -@item point-to-multipoint (Frame Relay, ad hoc wireless) -@item non-broadcast multiple access (ATM) -@item broadcast (Ethernet) -@end itemize -Therefore, we think that enabling these other link types will be more -straightforward now that the underlying OSPF SPF framework is in place. - -Presently, we can handle IPv4 point-to-point, numbered links, as well -as shared broadcast (CSMA) links, and we do not do equal-cost multipath. - -The GlobalRouteManager first walks the list of nodes and aggregates -a GlobalRouter interface to each one as follows: -@verbatim - typedef std::vector < Ptr >::iterator Iterator; - for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++) - { - Ptr node = *i; - Ptr globalRouter = CreateObject (node); - node->AggregateObject (globalRouter); - } -@end verbatim - -This interface is later queried and used to generate a Link State -Advertisement for each router, and this link state database is -fed into the OSPF shortest path computation logic. The Ipv4 API -is finally used to populate the routes themselves. - -@node Optimized Link State Routing (OLSR) -@section Optimized Link State Routing (OLSR) - -This is the first dynamic routing protocol for @command{ns-3}. 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. - -@verbatim - olsr::EnableAllNodes (); // Start OLSR on all nodes - olsr::EnableNodes(InputIterator begin, InputIterator end); // Start on - // a list of nodes - olsr::EnableNode (Ptr node); // Start OLSR on "node" only -@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.