12.07.2015 Views

The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...

The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...

The ns Manual (formerly ns Notes and Documentation)1 - NM Lab at ...

SHOW MORE
SHOW LESS
  • No tags were found...

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>The</strong> main problem facing the wired-cum-wireless scenario was the issue of routing. In <strong>ns</strong>, routing inform<strong>at</strong>ion is gener<strong>at</strong>edbased on the connectivity of the topology, i.e how nodes are connected to one another through Links. Mobilenodes on theother h<strong>and</strong> have no concept of links. <strong>The</strong>y route packets among themselves, within the wireless topology, using their routingprotocol. so how would packets be exchanged between these two types of nodes?So a node called BaseSt<strong>at</strong>ionNode is cre<strong>at</strong>ed which plays the role of a g<strong>at</strong>eway for the wired <strong>and</strong> wireless domai<strong>ns</strong>.<strong>The</strong> BaseSt<strong>at</strong>ionNode is essentially a hybrid between a Hierarchical node 1 (HierNode) <strong>and</strong> a MobileNode. <strong>The</strong>basest<strong>at</strong>ion node is respo<strong>ns</strong>ible for delivering packets into <strong>and</strong> out of the wireless domain. In order to achieve this we needHierarchical routing.Each wireless domain along with its base-st<strong>at</strong>ion would have an unique domain address assigned to them. All packets destinedto a wireless node would reach the base-st<strong>at</strong>ion <strong>at</strong>tached to the domain of th<strong>at</strong> wireless node, who would eventually h<strong>and</strong> thepacket over to the destin<strong>at</strong>ion (mobilenode). And mobilenodes route packets, destined to outside their (wireless) domain, totheir base-st<strong>at</strong>ion node. <strong>The</strong> base-st<strong>at</strong>ion knows how to forward these packets towards the (wired) destin<strong>at</strong>ion. <strong>The</strong> schem<strong>at</strong>icof a BaseSt<strong>at</strong>ionNode is shown in Figure 16.3.<strong>The</strong> mobilenodes in wired-cum-wireless scenario are required to support hierarchical addressing/routing. Thus the MobileNodelooks exactly like the BaseSt<strong>at</strong>ionNode. <strong>The</strong> SRNode, however, simply needs to have its own hier-address since it doesnot require any address demuxes <strong>and</strong> thus is not required to support hier routing 2 .<strong>The</strong> DSDV agent on having to forward a packet checks to see if the destin<strong>at</strong>ion is outside its (wireless) subnet. If so, it triesto forward the packet to its base-st<strong>at</strong>ion node. In case no route to base-st<strong>at</strong>ion is found the packet is dropped. Otherwisethe packet is forwarded to the next_hop towards the base-st<strong>at</strong>ion. Which is then routed towards the wired network by basest<strong>at</strong>ion’sclassifiers.<strong>The</strong> DSR agent, on receiving a pkt destined outside its subnet, sends out a route-query for its base-st<strong>at</strong>ion in case the route tobase-st<strong>at</strong>ion is not known. <strong>The</strong> d<strong>at</strong>a pkt is temporarily cached while it waits to hear route replies from base-st<strong>at</strong>ion. On gettinga reply the packet is provided with routing inform<strong>at</strong>ion in its header <strong>and</strong> send away towards the base-st<strong>at</strong>ion. <strong>The</strong> base-st<strong>at</strong>ionaddress demuxes routes it correctly toward the wired network.<strong>The</strong> example script for a wired-cum-wireless simul<strong>at</strong>ion can be found <strong>at</strong> ~<strong>ns</strong>/tcl/ex/wired-cum-wireless-sim.tcl. <strong>The</strong> methodsfor wired-cum-wireless implement<strong>at</strong>io<strong>ns</strong> are defined in ~<strong>ns</strong>/tcl/lib/<strong>ns</strong>-bsnode.tcl, ~<strong>ns</strong>/tcl/mobility/{com.tcl,dsr.tcl, dsdv.tcl},~<strong>ns</strong>/dsdv/dsdv.{cc,h} <strong>and</strong> ~<strong>ns</strong>/dsr/dsragent.{cc,h}.16.2.2 MobileIP<strong>The</strong> wired-cum-wireless exte<strong>ns</strong>io<strong>ns</strong> for the wireless model paved the p<strong>at</strong>h for supporting wireless MobileIP in <strong>ns</strong>. SunMicrosystem’s (Charlie Perki<strong>ns</strong> et al) MobileIP model was based on <strong>ns</strong>’s wired model (co<strong>ns</strong>isting of Node’s <strong>and</strong> Link’s)<strong>and</strong> thus didnot use CMU’s mobility model.Here we briefly describe the wireless MobileIP implement<strong>at</strong>ion. We hope th<strong>at</strong> Sun would provide the detailed version of thedocument<strong>at</strong>ion in the future.<strong>The</strong> mobileIP scenario co<strong>ns</strong>ists of Home-Agents(HA) <strong>and</strong> Foreign-Agents(FA) <strong>and</strong> have Mobile-Hosts(MH) moving betweentheir HA <strong>and</strong> FAs. <strong>The</strong> HA <strong>and</strong> FA are essentially base-st<strong>at</strong>ion nodes we have described earlier. While MHs arebasically the mobileNodes described in section 16.1.1. <strong>The</strong> methods <strong>and</strong> procedures for MobileIP exte<strong>ns</strong>io<strong>ns</strong> are described in~<strong>ns</strong>/mip.{cc,h}, ~<strong>ns</strong>/mip-reg.cc, ~<strong>ns</strong>/tcl/lib/<strong>ns</strong>-mip.tcl <strong>and</strong> ~<strong>ns</strong>/tcl/lib/<strong>ns</strong>-wireless-mip.tcl.<strong>The</strong> HA <strong>and</strong> FA nodes are defined as MobileNode/MIPBS having a registering agent (regagent_) th<strong>at</strong> sends beacon out to1 Refer to Chapter 32 for details on hierarchical routing <strong>and</strong> internals of HierNode.2 In order to do away with all these different vari<strong>at</strong>io<strong>ns</strong> of the definition of a node, we are planning to revise the node architecture th<strong>at</strong> would allow a moreflexible <strong>and</strong> modularised co<strong>ns</strong>truction of a node without the necessity of having to define <strong>and</strong> be limited to certain Class definitio<strong>ns</strong> only.162

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!