unicast.tex

柯老师网站上找到的

  Note that \proc[]{cost} takes the cost as argument.
  It is preferable to use the simulator method to set the cost variable,
  similar to the simulator instance procedures to set the queue or delay
  on a link.
  
\item   % class Classifier
The \clsref{Classifier}{../ns-2/ns-lib.tcl}
contains three new procedures, two of which overloads an existing
instproc-like, and the other two provide new functionality.

The instance procedure 
\fcnref{\proc[]{install}}{../ns-2/route-proto.tcl}{Classifier::install}
overloads the existing instproc-like of the same name.
The procedure stores the entry being installed in the instance
variable array, \code{elements_}, and then invokes the instproc-like.

The instance procedure 
\fcnref{\proc[]{installNext}}{../ns-2/route-proto.tcl}{Classifier::installNext}
also overloads the existing instproc-like of the same name.
This instproc-like simply installs the entry into the next available slot.

The instance procedure 
\fcnref{\proc[]{adjacents}}{../ns-2/route-proto.tcl}{Classifier::adjacents}
returns a list of \tup{key, value} pairs of all elements installed in the
classifier.
\end{list}

\subsection{Interface to Network Dynamics and Multicast}
\label{sec:rtglibAPI}
This section describes the methods applied in unicast routing to respond
to changes in the topology.
The complete sequence of actions that cause the changes in the topology,
and fire the appropriate actions is described in a different section.
% NEED XREF
The response to topology changes falls into two categories:
actions taken by individual agents at each of the nodes, and
actions to be taken globally for the entire protocol.

Detailed routing protocols such as the DV implementation
require actions to be performed by individual protocol agents at the
affected nodes.
Centralized routing protocols such as static and session routing fall into
the latter category exclusively.
Detailed routing protocols could use such techniques to gather statistics
related to the operation of the routing protocol;
however, no such code is currently implemented in \ns.

\paragraph{Actions at the individual nodes}
Following any change in the topology,
the network dynamics models will first invoke
\fcnref{\proc[]{rtObject::intf-changed}}{../ns-2/route-proto.tcl}{rtObject:;intf-changed}
at each of the affected nodes.
For each of the unicast routing protocols operating at that node,
\proc[]{rtObject::intf-changed} will invoke 
each individual protocol's instance procedure,  \proc[]{intf-changed},
followed by that protocol's \proc[]{compute-routes}.

After each protocol has computed its individual routes
\proc[]{rtObject::intf-changed} invokes \proc[]{compute-routes}
to possibly install new routes.
If new routes were installed in the node,
\proc[]{rtObject::compute-routes} will invoke
\proc[]{send-updates} for each of the protocols operating at the node.
The procedure will also
\fcnref{flag the multicast route
        object}{../ns-2/route-proto.tcl}{rtObject::flag-multicast}
of the route changes at the node, indicating the number of changes 
that have been executed.
\proc[]{rtObject::flag-multicast} will, in turn, notify
the multicast route object to take appropriate action.

The one exception
to the interface between unicast and multicast routing is the interaction
between dynamic dense mode multicast and detailed unicast routing.
This dynamicDM implementation in \ns\ assumes neighbor nodes
will send an implicit update whenever their routes change,
without actually sending the update.  
It then uses this implicit information to compute
appropriate parent-child relationships for the multicast spanning trees.
Therefore, detailed unicast routing will invoke
\code{rtObject_ flag-multicast 1} whenever it receives a route update as well,
even if that update does not result in any change in its own routing tables.

\paragraph{Global Actions}
Once the detailed actions at each of the affected nodes is completed,
the network dynamics models will
\fcnref{notify the RouteLogic instance (\proc[]{RouteLogic::notify})}{%
        ../ns-2/route-proto.tcl}{RouteLogic::notify} 
of changes to topology.
This procedure invokes the procedure \proc[]{compute-all}
for each of the protocols that were ever installed at any of the nodes.
Centralized routing protocols such as session routing use this signal to
recompute the routes to the topology.
Finally, the \proc[]{RouteLogic::notify} procedure notifies 
any instances of centralised multicast that are operating at the node.

\section{Protocol Internals}
\label{sec:protocol-internals}

In this section, we describe any leftover details of each of the routing
protocol agents.
Note that this is the only place where we describe the
internal route protocol agent, ``Direct'' routing.

\paragraph{Direct Routing}
This protocol tracks the state of the incident links,
and maintains routes to immediately adjacent neighbors only.
As with the other protocols, it maintains instance variable arrays
of \code{nextHop_}, \code{rtpref_}, and \code{metric_}, indexed by 
the handle of each of the possible destinations in the topology.

The instance procedure
\fcnref{\proc[]{compute-routes}}{../ns-2/route-proto.tcl}{Agent/rtProto/Direct::compute-routes}
computes routes based on the current state of the link, and the previously
known state of the incident links.

No other procedures or instance procedures are defined for this protocol.

\paragraph{Static Routing}
The procedure
\fcnref{\proc[]{compute-routes}}{../ns-2/ns-lib.tcl}{RouteLogic::compute-routes}
in the \clsref{RouteLogic}{../ns-2/ns-lib.tcl}
first creates the adjacency matrix, and then
invokes the C++ method, \fcn[]{compute\_routes} of the shadow object.
Finally, the procedure retrieves the result of the route computation,
and inserts the appropriate routes at each of the nodes in the topology.

The class only defines the procedure
\fcnref{\proc[]{init-all}}{../ns-2/route-proto.tcl}{Agent/rtProto/Static::init-all}
that invokes \proc[]{compute-routes}.

\paragraph{Session Routing}
The class defines the procedure
\fcnref{\proc[]{init-all}}{../ns-2/route-proto.tcl}{Agent/rtProto/Session::init-all}
to compute the routes at the start of the simulation.
It also defines the procedure
\fcnref{\proc[]{compute-all}}{../ns-2/route-proto.tcl}{Agent/rtProto/Session::compute-all}
to compute the routes when the topology changes.
Each of these procedures directly invokes \proc[]{compute-routes}.

\paragraph{DV Routing}
In a dynamic routing strategy, nodes send and receive messages,
and compute the routes in the topology based on the messages exchanged.
The procedure
\fcnref{\proc[]{init-all}}{../ns-2/route-proto.tcl}{Agent/rtProto/DV::init-all}
takes a list of nodes as the argument;
the default is the list of nodes in the topology.
At each of the nodes in the argument, the procedure starts the
\clsref{rtObject}{../ns-2/route-proto.tcl} and a 
\clsref{Agent/rtProto/DV}{../ns-2/route-proto.tcl} agents.
It then determines the DV peers for each of the newly created DV agents,
and creates the relevant \code{rtPeer} objects.

The
\fcnref{constructor for the DV agent}{%
        ../ns-2/route-proto.tcl}{Agent/rtProto/DV::init}
initializes a number of instance variables;
each agent stores an array, indexed by the destination node handle,
of the preference and metric, the interface (or link) to the next hop,
and the remote peer incident on the interface,
for the best route to each destination computed by the agent.
The agent creates these instance variables, and then
schedules sending its first update within the first
0.5 seconds of simulation start.

Each agent stores the list of its peers indexed by the handle
of the peer node.
Each peer is a separate peer structure that holds
the address of the peer agent, the metric and preference
of the route to each destination advertised by that peer.
We discuss the rtPeer structure later
when discuss the route architecture.
The peer structures are initialized by the procedure
\fcnref{\proc[]{add-peer}}{../ns-2/route-proto.tcl}{Agent/rtProto/DV::add-peer}
invoked by \proc[]{init-all}.

The routine 
\fcnref{\proc[]{send-periodic-update}}{../ns-2/route-proto.tcl}{Agent/rtProto/DV::send-periodic-update}
invokes \proc[]{send-updates} to send the actual updates.
It then reschedules sending the next periodic update
after \code{advertInterval} jitterred slightly to avoid
possible synchronization effects.

\fcnref{\proc[]{send-updates}}{../ns-2/route-proto.tcl}{Agent/rtProto/DV::send-updates}
will send updates to a select set of peers.
If any of the routes at that node have changed, or for periodic updates,
the procedure will send updates to all peers.
Otherwise, if some incident links have just recovered,
the procedure will send updates to the adjacent peers on those incident
links only.

\proc[]{send-updates} uses the procedure
\fcnref{\proc[]{send-to-peer}}{../ns-2/route-proto.tcl}{Agent/rtProto/DV::send-to-peer}
to send the actual updates.
This procedure packages the update, taking the
split-horizon and poison reverse mechanisms into account.
It invokes the instproc-like,
\fcnref{\proc[]{send-update} (Note the singular case)}{%
        ../ns-2/rtProto.cc}{rtProtoDV::command}
to send the actual update.
The actual route update is stored in the class variable
\code{msg_} indexed by a non-decreasing integer as index.
The instproc-like only sends the index to \code{msg_} to the remote peer.
This eliminates the need to convert from OTcl strings to alternate formats
and back.

When 
\fcnref{a peer receives a route update}{../ns-2/route-proto.tcl}{%
        Agent/rtProto/DV::recv-update}
it first checks to determine if the update from differs from the previous
ones.
The agent will compute new routes if the update contains new information.


\section{Unicast routing objects}
\label{sec:routeobjects}
Routelogic and rtobject are two objects that are significant to unicast
routing in \ns. Routelogic, essentially, represents the routing table
that is created and maintained centrally for every unicast simulation.
Routeobject is the object that every node taking part in dynamic
unicast routing, has an instance of. Note that nodes will not have an
instance of this object if Session routing is done as a detailed
routing protocol is not being simulated in this case. The methods for
routelogic and routeobjects are mentioned in the next section.


\section{Commands at a glance}
\label{sec:unicastcommand}

Following is a list of unicast routing related commands used in simulation
scripts:
\begin{flushleft}
\code{$ns_ rtproto <routing-proto> <args>}\\
where <routing-proto> defines the type of routing protocol to be used, like
Static, Manual, Session , DV etc. args may define the list of nodes on
which the protocol is to be run. The node list defaults to all nodes in
the topology.

Internal methods:

\code{$ns_ compute-routes}\\
This command computes \code{next_hop} information for all nodes in the
topology using the topology connectivity. This \code{next_hop} info is
then used to populate the node classifiers or the routing tables.
compute-routes calls compute-flat-routes or compute-hier-routes depending
on the type of addressing being used for the simulation.


\code{$ns_ get-routelogic}\\
This returns a handle to the RouteLogic object (the routing table),
if one has been created. Otherwise a new routing table object is created.


\code{$ns_ dump-routelogic-nh}\\
This dumps next hop information in the routing table.


\code{$ns_ dump-routelogic-distance}\\
This dumps the distance information in the routing table.


\code{$node add-route <dst> <Target>}\\
This is a method used to add routing entries (nexthop information) in the node's
routing table. The nexthop to <dst> from this node is the <target> object
and this info is added to the node's classifier.


\code{$routelogic lookup <srcid> <destid>}\\
Returns the id of the node that is the next hop from the node with id
srcid to the node with id destid. 


\code{$routelogic dump <nodeid>}\\
Dump the routing tables of all nodes whose id is less than nodeid. Node
ids are typically assigned to nodes in ascending fashion starting from 0
by their order of creation. 


\code{rtobject dump-routes <fileID>}\\
Dump the routing table to the output channel specified by fileID. fileID
must be a file handle returned by the Tcl open command and it must have
been opened for writing. 


\code{$rtobject rtProto? <proto>}\\
Returns a handle to the routing protocol agent specified by proto if it
exists at that node. Returns an empty string otherwise. 


\code{$rtobject nextHop? <destID>}\\
Returns the id of the node that is the next hop to the destination
specified by the node id, <destID>. 


\code{$rtobject rtpref? destID }\\
Returns the preference for the route to destination node given by destid.


\code{$rtobject metric? destID }\\
Returns metric for the route to destid.

\end{flushleft}

\endinput

### Local Variables:
### mode: latex
### comment-column: 60
### backup-by-copying-when-linked: t
### file-precious-flag: nil
### End: