lan.tex

柯老师网站上找到的

schedules itself to resume after the transmission time has elapsed.

For an incoming packet, the MAC object does its protocol processing and
passes the packet to the link-layer.

\subsection{CSMA-based MAC}

The \clsref{CsmaMac}{../ns-2/mac-csma.cc} extends the \code{Mac} class
with new methods that implements carrier sense and backoff mechanisms.
The \code{CsmaMac::send()} method detects when the channel becomes idle
using \code{Channel::txtime()}.  If the channel is busy, the MAC
schedules the next carrier sense at the moment the channel turns idle.
Once the channel is idle, the \code{CsmaMac} object initiates the
contention period with \code{Channel::contention()}.  At the end of the
contention period, the \code{endofContention()} method is invoked.  At
this time, the basic \code{CsmaMac} just transmits the packet using
\code{Channel::send}.

\begin{program}
    class CsmaMac : public Mac \{
    public:
        CsmaMac();
        void send(Packet* p);
        void resume(Packet* p = 0);
        virtual void endofContention(Packet* p);
        virtual void backoff(Handler* h, Packet* p, double delay=0);
                . . .
    \};

    class CsmaCdMac : public CsmaMac \{
    public:
        CsmaCdMac();
        void endofContention(Packet*);
    \};

    class CsmaCaMac : public CsmaMac \{
    public:
        CsmaCaMac();
        virtual void send(Packet*);
    \};
\end{program}

The \code{CsmaCdMac} extends \code{CsmaMac} to carry out collision
detection procedure of the CSMA/CD (Ethernet) protocol.  When the
channel signals the end of contention period, the \code{endofContention}
method checks for collision using the \code{Channel::collision()}
method.  If there is a collision, the MAC invokes its \code{backoff}
method to schedule the next carrier sense to retransmit the packet.

The \code{CsmaCaMac} extends the \code{send} method of \code{CsmaMac} to
carry out the collision avoidance (CSMA/CA) procedure.  Instead of
transmitting immediately when the channel is idle, the \code{CsmaCaMac}
object backs off a random number of slots, then transmits if the channel
remains idle until the end of the backoff period.

\section{LL (link-layer) Class}
\label{sec:linklayer}

The link-layer object is responsible for simulating the data link
protocols.  Many protocols can be implemented within this layer such
as packet fragmentation and reassembly, and reliable link protocol. 

Another important function of the link layer is setting the MAC
destination address in the MAC header of the packet.  In the current
implementation this task involves two separate issues: finding the
next--hop--node's IP address (routing) and resolving this IP address
into the correct MAC address (ARP).  For simplicity, the default
mapping between MAC and IP addresses is one--to--one, which means that
IP addresses are re--used at the MAC layer.

\subsection{LL Class in C++}
\label{sec:llcplus}

The C++ class \code{LL} derives from the \code{LinkDelay} class.  Since
it is a duplex object, it keeps a separate pointer for the send target,
\code{sendtarget}, and the receive target, \code{recvtarget}.  It also
defines the methods \code{recvfrom()} and \code{sendto()} to handle the
incoming and outgoing packets respectively.

\begin{program}
   class LL : public LinkDelay \{
   public:
   	   LL();
   	   virtual void recv(Packet* p, Handler* h);
   	   virtual Packet* sendto(Packet* p, Handler* h = 0);
   	   virtual Packet* recvfrom(Packet* p);
   
   	   inline int seqno() { return seqno_; }
   	   inline int ackno() { return ackno_; }
   	   inline int macDA() { return macDA_; }
   	   inline Queue *ifq() { return ifq_; }
   	   inline NsObject* sendtarget() { return sendtarget_; }
   	   inline NsObject* recvtarget() { return recvtarget_; }
   
   protected:
   	   int command(int argc, const char*const* argv);
   	   void handle(Event* e) { recv((Packet*)e, 0); }
   	   inline virtual int arp (int ip_addr) { return ip_addr; } 
   	   int seqno_;			// link-layer sequence number
   	   int ackno_;			// ACK received so far
   	   int macDA_;			// destination MAC address
   	   Queue* ifq_;			// interface queue
   	   NsObject* sendtarget_;		// for outgoing packet 
   	   NsObject* recvtarget_;		// for incoming packet
   
   	   LanRouter* lanrouter_; // for lookups of the next hop
   \};
\end{program}

\subsection{Example: Link Layer configuration}
\label{ex:linklayer}

\begin{program}
    set ll_  [new LL]
    set ifq_ [new Queue/DropTail]
    $ll_ lanrouter  [new LanRouter $ns $lan] # LanRouter is one object
                                             # per LAN
    $ll_ set delay_ $delay        # link-level overhead
    $ll_ set bandwidth_ $bw       # bandwidth
    $ll_ sendtarget $mac          # interface queue at the sender side
    $ll_ recvtarget $iif          # input interface of the receiver
             . . .
\end{program}

\section{\code{LanRouter} class}
By default, there is just one \code{LanRouter} object per LAN, which
is created when a new \code{LanNode} is initialized.  For every node
on the LAN, the link layer object (\code{LL}) has a pointer to the
\code{LanRouter}, so it is able to find the next hop for the packet
that is sent on the LAN:
\begin{program}
Packet* LL::sendto(Packet* p, Handler* h)
\{        
        int nh = (lanrouter_) ? lanrouter_->next_hop(p) : -1;
        . . .
\}
\end{program}
\code{LanRouter} is able to find the next hop by querying the current
\code{RouteLogic}:
\begin{program}
int LanRouter::next_hop(Packet *p) \{
        int next_hopIP;
        if (enableHrouting_) \{
                routelogic_->lookup_hier(lanaddr_, adst, next_hopIP);
        \} else \{
                routelogic_->lookup_flat(lanaddr_, adst, next_hopIP);
        \}
\end{program}
One limitation of this is that \code{RouteLogic} may not be aware of
dynamic changes to the routing.  But it is always possible to derive a
new class from \code{LanRouter} so that to re--define its
\code{next_hop} method to handle dynamic changes appopriately.

\section{Other Components}
\label{sec:lan_others}

In addition to the C++ components described above, simulating local area
networks also requires a number of existing components in \ns\ such as
\code{Classifier}, \code{Queue}, and \code{Trace},
\code{networkinterface}, etc.  Configuring these
objects requires knowledge of what the user wants to simulate.  The
default configuration is implemented in the two Tcl files mentioned at
the beginning of this chapter.  To obtain more realistic simulations
of wireless networks, one can use the \code{ErrorModel} described in
Chapter~\ref{chap:error_model}.

\section{LANs and \ns\ routing}
\label{sec:lan_ns-routing}

When a LAN is created using either \code{make-lan} or \code{newLan}, a
``\textit{virtual LAN node}'' \code{LanNode} is created.
\code{LanNode} keeps together all shared objects on the LAN:
\code{Channel}, \code{Classifier/Mac}, and \code{LanRouter}.  Then for
each node on the LAN, a \code{LanIface} object is created.
\code{LanIface} contains all other objects that are needed on the
per--node basis: a \code{Queue}, a link layer (\code{LL}),
\code{Mac}, etc.  It should be emphasized that \code{LanNode} is a
node only for routing algorithms:  \code{Node} and \code{LanNode} have
very little in common.  One of few things that they share is an
identifier taken from the \code{Node} ID--space.  If
\textit{hierarchical routing} is used, \code{LanNode} \textit{has to be
assigned a hierarchical address} just like any other node.  From the
point of view of \ns\ (static) routing, \code{LanNode} is just another
node connected to every node on the LAN.
\begin{figure}[hbt]
	\centerline{\includegraphics{lan2}}
  	\caption{Actual LAN configuration (left) and as seen by
  	\ns\ routing (right)}
  	\label{fig:lan-routing1}
\end{figure}
Links connecting the \code{LanNode} with the nodes on the LAN are also
``virtual'' (\code{Vlink}).  The default routing cost of such a link
is $1/2$, so the cost of traversing two \code{Vlink}s
(e.g. \textbf{n1 $\rightarrow$ LAN $\rightarrow$ n2}) is counted as just one
hop.  

Most important method of \code{Vlink} is the one that gives the head
of the link:
\begin{program}
Vlink instproc head \{\} \{
    $self instvar lan_ dst_ src_
    if \{$src_ == [$lan_ set id_]\} \{
        # if this is a link FROM the lan vnode, 
        # it doesn't matter what we return, because
        # it's only used by $lan add-route (empty)
        return ""
    \} else \{
        # if this is a link TO the lan vnode, 
        # return the entry to the lanIface object
        set src_lif [$lan_ set lanIface_($src_)]
        return [$src_lif entry]
    \}
\}
\end{program}
This method is used by static (default) routing to install correct
routes at a  node (see \code{Simulator} methods \\ \code{compute-flat-routes} and
\code{compute-hier-routes} in \code{tcl/lib/ns-route.tcl}, as well
as \code{Node} methods \code{add-route} and \code{add-hroute} in
\code{tcl/lib/ns-node.tcl}).  

From the code fragment above it can be seen that it returns LAN
interface of the node as a head of the link to be installed in the
appropriate classifier. 

Thus, \code{Vlink} \textit{does not impose any delay on the packet}
and serves the only purpose to install LAN interfaces instead of
normal links at nodes' classifiers.  

Note, that this design allows to have nodes connected by parallel
LANs, while in the current implementation it is impossible to have
nodes connected by parallel simple links and use them both (the array
\code{Simulator instvar link_} holds the link object for each
connected pair of source and destination, and it can be only one
object per source/destination pair).

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

The following is a list of lan related commands commonly used in
simulation scripts:
\begin{flushleft}
\code{$ns_ make-lan  <nodelist> <bw> <delay> <LL> <ifq> <MAC> <channel> <phy>}\\
Creates a lan from a set of nodes given by <nodelist>. Bandwidth, delay characteristics
along with the link-layer, Interface queue, Mac layer and channel type for the
lan also needs to be defined. Default values used are as follows:\\
<LL> .. LL\\
<ifq>.. Queue/DropTail\\
<MAC>.. Mac\\
<channel>.. Channel and \\
<phy>.. Phy/WiredPhy


\code{$ns_ newLan <nodelist> <BW> <delay> <args>}\\
This command creates a lan similar to make-lan described above. But this
command can be used for finer control whereas make-lan is a more convinient and
easier command. For example newLan maybe used to create a lan with hierarchical
addresses. See \ns/tcl/ex/{vlantest-hier.tcl, vlantest-mcst.tcl, lantest.tcl,
mac-test.tcl} for usage of newLan. The possible argument types that can be
passed are LL, ifq, MAC, channel, phy and address.


\code{$lannode cost <c>}\\
This assigns a cost of c/2 to each of the (uni-directional) links in the lan.


\code{$lannode cost?}\\
Returns the cost of (bi-directional) links in the lan, i.e c.


Internal procedures :

\code{$lannode addNode <nodes> <bw> <delay> <LL> <ifq> <MAC> <phy>}\\
Lan is implemented as a virtual node. The LanNode mimics a real node and uses
an address (id) from node's address space.
This command adds a list of <nodes> to the lan represented by lannode.
The bandwidth, delay and network characteristics of nodes are given by
the above arguments. This is an internal command used by make-lan and newLan.


\code{$lannode id}\\
Returns the virtual node's id.


\code{$lannode node-addr}\\
Returns virtual nodes's address.


\code{$lannode dump-namconfig}\\
This command creates a given lan layout in nam. This function may be changed
to redefine the lan layout in a different way.


\code{$lannode is-lan?}\\
This command always returns 1, since the node here is a virtual node
representing a lan. The corresponding command for base class Node 
\code{$node is-lan?} always returns a 0.

\end{flushleft}

%\end{document}
\endinput