unicast.tex

柯老师网站上找到的

\item The instance procedure
\fcnref{\proc[]{lookup}}{../ns-2/route-proto.tcl}{RouteLogic::lookup}
takes two node numbers, $nodeId_1$ and $nodeId_2$, as argument;
it returns the id of the neighbor node that $nodeId_1$ uses to 
reach $nodeId_2$.

The procedure is used by the static route computation procedure to query
the computed routes and populate the routes at each of the nodes.
It is also used by the multicast routing protocols to perform the
appropriate RPF check.

Note that this procedure overloads an instproc-like of the same name.
The procedure queries the appropriate \code{rtObject} entities
if they exist
(which they will if dynamic routing strategies are used in the simulation);
otherwise, the procedure invokes the instproc-like to obtain the relevant
information.
\end{itemize}

\paragraph{\protect\clsref{rtObject}{../ns-2/route-proto.tcl}}
is used in simulations that use dynamic routing.
Each node has a rtObject associated with it, that
acts as a co-ordinator for the different routing protocols that
operate at a node.
At any node, the rtObject at that node 
tracks each of the protocols operating at that node;
it computes and installs the nest route to each destination
available via each of the protocols.
In the event that the routing tables change, or the topology changes,
the rtObject will alert the protocols to take the appropriate action.

The class defines the procedure
\fcnref{\proc[]{init-all}}{../ns-2/route-proto.tcl}{rtObject::init-all};
this procedure takes a list of nodes as arguments,
and creates a rtObject at each of the nodes in its argument list.
It subsequently invokes its \code{compute-routes}.

The assumption is that the constructor for each of the new objects
will instantiate the ``Direct'' route protocol at each of these nodes.
This route protocol is responsible for computing the routes to 
immediately adjacent neighbors.
When \proc[]{compute-routes} is run by the \proc[]{init-all} 
procedure, these direct routes are installed in the node by the
appropriate route object.

The other instance procedures in this class are:
\begin{itemize}
\item \fcnref{\proc[]{init}}{../ns-2/route-proto.tcl}{rtObject::init}
The constructor sets up pointers from itself to the node,
in its instance variable \code{node_}, and from the node to itself,
through the Node instance procedure
\proc[]{init-routing} and the Node instance variable \code{rtObject_}.
It then initializes an array of
\code{nextHop_}, \code{rtpref_}, \code{metric_}, \code{rtVia_}.
The index of each of these arrays is the handle of the destination node.

The \code{nextHop_} contains the link that will be used to reach the
particular destination;
\code{rtpref_} and \code{metric_} are
the preference and metric for the route installed in the node;
\code{rtVia_} is the name of the agent whose route is installed in the node.

The constructor also creates the instance of the Direct route protocol,
and invokes \proc[]{compute-routes} for that protocol.

\item
\fcnref{\proc[]{add-proto}}{../ns-2/route-proto.tcl}{rtObject::add-proto}
creates an instance of the protocol, stores a reference to it
in its array of protocols, \code{rtProtos_}.
The index of the array is the name of the protocol.
It also attaches the protocol object to the node,
and returns the handle of the protocol object.

\item \fcnref{\proc[]{lookup}}{../ns-2/route-proto.tcl}{rtObject::lookup}
takes a destination node handle, and returns the id of the neighbor node
that is used to reach the destination.

If multiple paths are in use, then it returns a list of the
neighbor nodes that will be used.

If the node does not have a route to the destination,
the procedure will return -1.

\item
\fcnref{\proc[]{compute-routes}}{../ns-2/route-proto.tcl}{rtObject::compute-routes}
is the core procedure in this class.
It first checks to see if any of the routing protocols
at the node have computed any new routes.
If they have,
it will determine the best route to each destination
from among all the protocols.
If any routes have changed,
the procedure will notify each of the protocols of the number of
such changes, in case any of these protocols wants to send a fresh update.
Finally, it will also notify any multicast protocol that new unicast route
tables have been computed.

The routine checks the protocol agent's instance variable,
\code{rtsChanged_} to see if any of the routes in that protocol
have changed since the protocol was last examined.
It then uses the protocol's instance variable arrays,
\code{nextHop_}, \code{rtpref_}, and \code{metric_}
to compute its own arrays.
The rtObject will install or modify any of the routes as the changes are found.

If any of the routes at the node have changed,
the rtObject will invoke the protocol agent's instance procedures,
\proc[]{send-updates} with the number of changes as argument.
It will then invoke the multicast route object, if it exists.
\end{itemize}

The next set of routines are used to query the rtObject for various state
information.
\begin{itemize}
\item
\fcnref{\proc[]{dump-routes}}{../ns-2/route-proto.tcl}{rtObject::dump-routes}
takes a output file descriptor as argument, and writes out the
routing table at that node on that file descriptor.

A typical dump output is:
{\small
\begin{verbatim}
\end{verbatim}
}

\item
\fcnref{\proc[]{rtProto?}}{../ns-2/route-proto.tcl}{rtObject::rtProto?}
takes a route protocol as argument, and returns a handle to the instance
of the protocol running at the  node.

\item
\fcnref{\proc[]{nextHop?}}{../ns-2/route-proto.tcl}{rtObject::nextHop?}
takes a destination node handle, and returns the link that is used to reach
that destination.

\item
Similarly,
\fcnref{\proc[]{rtpref?}}{../ns-2/route-proto.tcl}{rtObject::rtpref?} and
\fcnref{\proc[]{metric?}}{../ns-2/route-proto.tcl}{rtObject::metric?}
take a destination node handle as argument, and return the preference
and metric of the route to the destination installed at the node.
\end{itemize}

\paragraph{The \protect\clsref{rtPeer}{../ns-2/route-proto.tcl}}
is a container class used by the protocol agents.
Each object stores the address of the peer agent, and the 
metric and preference for each route advertised by that peer.
A protocol agent will store one object per peer.
The class maintains the instance variable \code{addr_}, and the
instance variable arrays, \code{metric_} and \code{rtpref_};
the array indices are the destination node handles.

The class instance procedures,
\fcnref{\proc[]{metric}}{../ns-2/route-proto.tcl}{rtPeer::metric} and
\fcnref{\proc[]{preference}}{../ns-2/route-proto.tcl}{rtPeer::preference},
take one destination and value, and set the respective array variable.
The procedures,
\fcnref{\proc[]{metric?}}{../ns-2/route-proto.tcl}{rtPeer::metric?} and
\fcnref{\proc[]{preference?}}{../ns-2/route-proto.tcl}{rtPeer::preference?},
take a destination and return the current value for that destination.
The instance procedure
\fcnref{\proc[]{addr?}}{../ns-2/route-proto.tcl}{rtPeer::addr?}
returns the address of the peer agent.

\paragraph{\protect\clsref{Agent/rtProto}{../ns-2/route-proto.tcl}}
This class is the base class from
which all routing protocol agents are derived.
Each protocol agent must define the procedure\proc[]{init-all}
to initialize the complete protocol,
and possibly instance procedures \proc[]{init}, \proc[]{compute-routes}, and
\proc[]{send-updates}.
In addition, if the topology is dynamic, and the protocol supports 
route computation to react to changes in the topology,
then the protocol should define the procedure \proc[]{compute-all}, and
possibly the instance procedure \proc[]{intf-changed}.
In this section, we will briefly describe the interface for the basic
procedures.
We will defer the description of \proc[]{compute-all} and
\proc[]{intf-changed}
to the section on network dynamics.
We also defer the description of the details of each of the protocols
to their separate section at the end of the chapter.
\begin{list}{---}{}
\item
The procedure
\fcnref{\proc[]{init-all}}{../ns-2/route-proto.tcl}{Agent/rtProto::init-all}
is a global initialization procedure for the class.
It may be given a list of the nodes as an argument.
This the list of nodes that should run this routing protocol.
However, centralised routing protocols such as static and session routing
will ignore this argument;
detailed dynamic routing protocols such as DV will use this argument
list to instantiate protocols agents at each of the nodes specified.

Note that derived classes in OTcl do not inherit the procedures
defined in the base class. 
Therefore, every derived routing protocol class must define its own
procedures explicitly.

\item
The instance procedure
\fcnref{\proc[]{init}}{../ns-2/route-proto.tcl}{Agent/rtProto::init}
is the constructor for protocol agents that are created.
The base class constructor initializes the default preference 
for objects in this class,
identifies the interfaces incident on the node and their current status.
The interfaces are indexed by the neighbor handle and stored in the instance
variable array, \code{ifs_};
the corresponding status instance variable array is \code{ifstat_}.

Centralized routing protocols such as static and session routing do not
create separate agents per node, and therefore do not access any of these
instance procedures.

\item
The instance procedure
\fcnref{\proc[]{compute-routes}}{../ns-2/route-proto.tcl}{Agent/rtProto::compute-routes}
computes the actual routes for the protocol.
The computation is based on the routes learned by the protocol, and
varies from protocol to protocol.

This routine is invoked by the rtObject whenever the topology changes.
It is also invoked when the node receives an update for the protocol.

If the routine computes new routes, 
\proc[]{rtObject::compute-routes} needs to be invoked
to recompute and possibly install new routes at the node.
The actual invoking of the rtObject is done by the procedure
that invoked this routine in the first place.

\item
The instance procedure
\fcnref{\proc[]{send-updates}}{../ns-2/route-proto.tcl}{Agent/rtProto::send-updates}
is invoked by the rtObject whenever the node routing tables have changed,
and fresh updates have to be sent to all peers.
The rtObject passes as argument the number of changes that were done.
This procedure may also be invoked when there are no changes to the routes,
but the topology incident on the node changes state.
The number of changes is used to determine the list of peers to which
a route update must be sent.
\end{list}
Other procedures relate to responding to topology changes and
\href{are described later}{Section}{sec:rtglibAPI}.

\paragraph{Other Extensions to the Simulator, Node, Link, and Classifier}
\begin{list}{---}{}
\item   % class Simulator
  We have discussed the methods \proc[]{rtproto} and \proc[]{cost}
  in the class Simulator \href{earlier}{Section}{sec:API}.
  The one other method used internally is
  \fcnref{\proc[]{get-routelogic}}{../ns-2/route-proto.tcl}{Simulator::get-routelogic};
  this procedure returns the instance of routelogic in the simulation.

  The method is used by the class Simulator, and unicast and multicast routing.

\item   % class Node
   The class Node contains these additional instance procedures
   to support dynamic unicast routing:
\fcnref{\proc[]{init-routing}}{../ns-2/route-proto.tcl}{Node::init-routing},
\fcnref{\proc[]{add-routes}}{../ns-2/route-proto.tcl}{Node::add-routes},
\fcnref{\proc[]{delete-routes}}{../ns-2/route-proto.tcl}{Node::delete-routes},
and
\fcnref{\proc[]{rtObject?}}{../ns-2/route-proto.tcl}{Node::rtObject?}.

The instance procedure \proc[]{init-routing}
is invoked by the \code{rtObject} at the node.
It stores a pointer to the rtObject, in its instance variable
\code{rtObject_}, for later manipulation or retrieval.
It also checks its class variable to see if it should use multiPath routing,
and sets up an instance variable to that effect.
If multiPath routing could be used,
the instance variable array \code{routes_} stores a count of the number of
paths installed for each destination.
This is the only array in unicast routing that is indexed by the node id,
rather than the node handle.

The instance procedure \proc[]{rtObject?}
returns the rtObject handle for that node.

The instance procedure \proc[]{add-routes}
takes a node id, and a list of links.
It will add the list of links as the routes to reach the destination
identified by the node id.
The realization of multiPath routing is done by using a separate
Classifier/multiPath.
For any given destination id $d$, if this node has multiple paths to $d$,
then the main classifier points to this multipath classifier instead of 
the link to reach the destination.
Each of the multiple paths identified by the interfaces being used is
installed in the multipath classifier.
The multipath classifier will use each of the links installed in it for
succeeding packets forwarded to it.

The instance procedure \proc[]{delete-routes}
takes a node id, a list of interfaces, and a nullAgent.
It removes each of the interfaces in the list from the installed list of
interfaces.
If the entry did not previously use a multipath classifier,
then it must have had only one route, and the route entry is set to point
to the nullAgent specified.

Q:  WHY DOES IT NOT POINT TO NULLAGENT IF THE ENTRIES IN THE MPATHCLASSIFIER
GOES TO ZERO?

\item   % class Link
  The main extension to the class Link for unicast routing is
  to support the notion of link costs.
  The instance variable \code{cost_}
  contains the cost of the unidirectional link.
  The instance procedures
  \fcnref{\proc[]{cost}}{../ns-2/route-proto.tcl}{Link::cost}
  and
  \fcnref{\proc[]{cost?}}{../ns-2/route-proto.tcl}{Link::cost?}
  set and get the cost on the link.