.. include:: replace.txt

CSMA NetDevice
--------------

This is the introduction to CSMA NetDevice chapter, to complement the Csma model
doxygen.

Overview of the CSMA model
**************************

The |ns3| CSMA device models a simple bus network in the spirit of Ethernet.
Although it does not model any real physical network you could ever build or
buy, it does provide some very useful functionality.

Typically when one thinks of a bus network Ethernet or IEEE 802.3 comes to mind.
Ethernet uses CSMA/CD (Carrier Sense Multiple Access with Collision Detection
with exponentially increasing backoff to contend for the shared transmission
medium. The |ns3| CSMA device models only a portion of this process, using the
nature of the globally available channel to provide instantaneous (faster than
light) carrier sense and priority-based collision "avoidance." Collisions in the
sense of Ethernet never happen and so the |ns3| CSMA device does not model
collision detection, nor will any transmission in progress be "jammed."

CSMA Layer Model
++++++++++++++++

There are a number of conventions in use for describing layered communications
architectures in the literature and in textbooks. The most common layering model
is the ISO seven layer reference model. In this view the CsmaNetDevice and
CsmaChannel pair occupies the lowest two layers -- at the physical (layer one),
and data link (layer two) positions. Another important reference model is that
specified by RFC 1122, "Requirements for Internet Hosts -- Communication
Layers." In this view the CsmaNetDevice and CsmaChannel pair occupies the lowest
layer -- the link layer. There is also a seemingly endless litany of alternative
descriptions found in textbooks and in the literature. We adopt the naming
conventions used in the IEEE 802 standards which speak of LLC, MAC, MII and PHY
layering. These acronyms are defined as:

* LLC:  Logical Link Control;
* MAC:  Media Access Control;
* MII:  Media Independent Interface;
* PHY:  Physical Layer.

In this case the *LLC* and *MAC* are sublayers of the OSI data link layer and
the *MII* and *PHY* are sublayers of the OSI physical layer.

The "top" of the CSMA device defines the transition from the network layer to
the data link layer. This transition is performed by higher layers by calling
either CsmaNetDevice::Send or CsmaNetDevice::SendFrom.

In contrast to the IEEE 802.3 standards, there is no precisely specified PHY in
the CSMA model in the sense of wire types, signals or pinouts. The "bottom"
interface of the CsmaNetDevice can be thought of as as a kind of Media
Independent Interface (MII) as seen in the "Fast Ethernet" (IEEE 802.3u)
specifications. This MII interface fits into a corresponding media independent
interface on the CsmaChannel. You will not find the equivalent of a 10BASE-T or
a 1000BASE-LX PHY.

The CsmaNetDevice calls the CsmaChannel through a media independent interface.
There is a method defined to tell the channel when to start "wiggling the wires"
using the method CsmaChannel::TransmitStart, and a method to tell the channel
when the transmission process is done and the channel should begin propagating
the last bit across the "wire": CsmaChannel::TransmitEnd.

When the TransmitEnd method is executed, the channel will model a single uniform
signal propagation delay in the medium and deliver copes of the packet to each
of the devices attached to the packet via the CsmaNetDevice::Receive method.

There is a "pin" in the device media independent interface corresponding to
"COL" (collision). The state of the channel may be sensed by calling
CsmaChannel::GetState. Each device will look at this "pin" before starting a
send and will perform appropriate backoff operations if required.

Properly received packets are forwarded up to higher levels from the
CsmaNetDevice via a callback mechanism. The callback function is initialized by
the higher layer (when the net device is attached) using
CsmaNetDevice::SetReceiveCallback and is invoked upon "proper" reception of a
packet by the net device in order to forward the packet up
the protocol stack.

CSMA Channel Model
******************

The class CsmaChannel models the actual transmission medium. There is no fixed
limit for the number of devices connected to the channel. The CsmaChannel models
a data rate and a speed-of-light delay which can be accessed via the attributes
"DataRate" and "Delay" respectively. The data rate provided to the channel is
used to set the data rates used by the transmitter sections of the CSMA devices
connected to the channel. There is no way to independently set data rates in the
devices. Since the data rate is only used to calculate a delay time, there is no
limitation (other than by the data type holding the value) on the speed at which
CSMA channels and devices can operate; and no restriction based on any kind of
PHY characteristics.

The CsmaChannel has three states, ``IDLE``, ``TRANSMITTING`` and
``PROPAGATING``. These three states are "seen" instantaneously by all devices on
the channel. By this we mean that if one device begins or ends a simulated
transmission, all devices on the channel are *immediately* aware of the
change in state. There is no time during which one device may see an ``IDLE``
channel while another device physically further away in the collision domain may
have begun transmitting with the associated signals not propagated down the
channel to other devices. Thus there is no need for collision detection in the
CsmaChannel model and it is not implemented in any way.

We do, as the name indicates, have a Carrier Sense aspect to the model.  Since
the simulator is single threaded, access to the common channel will be
serialized by the simulator. This provides a deterministic mechanism for
contending for the channel. The channel is allocated (transitioned from state
``IDLE`` to state ``TRANSMITTING``) on a first-come first-served basis.
The channel always goes through a three state process:::

  IDLE -> TRANSMITTING -> PROPAGATING -> IDLE

The ``TRANSMITTING`` state models the time during which the source net device is
actually wiggling the signals on the wire. The ``PROPAGATING`` state models the
time after the last bit was sent, when the signal is propagating down the wire
to the "far end."  

The transition to the ``TRANSMITTING`` state is  driven by a call to
CsmaChannel::TransmitStart which is called by the net device that transmits the
packet. It is the responsibility of that device to end the transmission with a
call to CsmaChannel::TransmitEnd at the appropriate simulation time that
reflects the time elapsed to put all of the packet bits on the wire. When
TransmitEnd is called, the channel schedules an event corresponding to a single
speed-of-light delay. This delay applies to all net devices on the channel
identically. You can think of a symmetrical hub in which the packet bits
propagate to a central location and then back out equal length cables to the
other devices on the channel. The single "speed of light" delay then corresponds
to the time it takes for: 1) a signal to propagate from one CsmaNetDevice
through its cable to the hub; plus 2) the time it takes for the hub to forward
the packet out a port; plus 3) the time it takes for the signal in question to
propagate to the destination net device.

The CsmaChannel models a broadcast medium so the packet is delivered to all of
the devices on the channel (including the source) at the end of the propagation
time. It is the responsibility of the sending device to determine whether or not
it receives a packet broadcast over the channel.

The CsmaChannel provides following Attributes:

* DataRate:  The bitrate for packet transmission on connected devices;
* Delay: The speed of light transmission delay for the channel.

CSMA Net Device Model
*********************

The CSMA network device appears somewhat like an Ethernet device. The
CsmaNetDevice provides following Attributes:

* Address:  The Mac48Address of the device;
* SendEnable:  Enable packet transmission if true;
* ReceiveEnable:  Enable packet reception if true;
* EncapsulationMode:  Type of link layer encapsulation to use;
* RxErrorModel:  The receive error model;
* TxQueue:  The transmit queue used by the device;
* InterframeGap:  The optional time to wait between "frames";
* Rx:  A trace source for received packets;
* Drop:  A trace source for dropped packets.

The CsmaNetDevice supports the assignment of a "receive error model." This is an
ErrorModel object that is used to simulate data corruption on the link.

Packets sent over the CsmaNetDevice are always routed through the transmit queue
to provide a trace hook for packets sent out over the network. This transmit
queue can be set (via attribute) to model different queuing strategies.

Also configurable by attribute is the encapsulation method used by the device.
Every packet gets an EthernetHeader that includes the destination and source MAC
addresses, and a length/type field. Every packet also gets an EthernetTrailer
which includes the FCS. Data in the packet may be encapsulated in different
ways.

By default, or by setting the "EncapsulationMode" attribute to "Dix", the
encapsulation is according to the DEC, Intel, Xerox standard. This is sometimes
called EthernetII framing and is the familiar destination MAC, source MAC,
EtherType, Data, CRC format.

If the "EncapsulationMode" attribute is set to "Llc", the encapsulation is by
LLC SNAP. In this case, a SNAP header is added that contains the EtherType (IP
or ARP).  

The other implemented encapsulation modes are IP_ARP (set "EncapsulationMode" to
"IpArp") in which the length type of the Ethernet header receives the protocol
number of the packet; or ETHERNET_V1 (set "EncapsulationMode" to "EthernetV1")
in which the length type of the Ethernet header receives the length of the
packet.  A "Raw" encapsulation mode is defined but not implemented -- use of the
RAW mode results in an assertion.  

Note that all net devices on a channel must be set to the same encapsulation
mode for correct results. The encapsulation mode is not sensed at the receiver.

The CsmaNetDevice implements a random exponential backoff algorithm that is
executed if the channel is determined to be busy (``TRANSMITTING`` or
``PPROPAGATING``) when the device wants to start propagating. This results in a
random delay of up to pow (2, retries) - 1 microseconds before a retry is
attempted. The default maximum number of retries is 1000.

Using the CsmaNetDevice
***********************

The CSMA net devices and channels are typically created and configured using the
associated ``CsmaHelper`` object.  The various |ns3| device helpers generally
work in a similar way, and their use is seen in many of our example programs.

The conceptual model of interest is that of a bare computer "husk" into which
you plug net devices. The bare computers are created using a ``NodeContainer``
helper. You just ask this helper to create as many computers (we call them
``Nodes``) as you need on your network:::

  NodeContainer csmaNodes;
  csmaNodes.Create (nCsmaNodes);

Once you have your nodes, you need to instantiate a ``CsmaHelper`` and set any
attributes you may want to change.::

  CsmaHelper csma;
  csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
  csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560)));

  csma.SetDeviceAttribute ("EncapsulationMode", StringValue ("Dix"));
  csma.SetDeviceAttribute ("FrameSize", UintegerValue (2000));
 
Once the attributes are set, all that remains is to create the devices and
install them on the required nodes, and to connect the devices together using a
CSMA channel. When we create the net devices, we add them to a container to
allow you to use them in the future. This all takes just one line of code.::

  NetDeviceContainer csmaDevices = csma.Install (csmaNodes);

CSMA Tracing
************

Like all |ns3| devices, the CSMA Model provides a number of trace sources.
These trace sources can be hooked using your own custom trace code, or you can
use our helper functions to arrange for tracing to be enabled on devices you
specify.

Upper-Level (MAC) Hooks
+++++++++++++++++++++++

From the point of view of tracing in the net device, there are several
interesting points to insert trace hooks. A convention inherited from other
simulators is that packets destined for transmission onto attached networks pass
through a single "transmit queue" in the net device. We provide trace hooks at
this point in packet flow, which corresponds (abstractly) only to a transition
from the network to data link layer, and call them collectively the device MAC
hooks.

When a packet is sent to the CSMA net device for transmission it always passes
through the transmit queue. The transmit queue in the CsmaNetDevice inherits
from Queue, and therefore inherits three trace sources:

* An Enqueue operation source (see Queue::m_traceEnqueue);
* A Dequeue operation source (see Queue::m_traceDequeue);
* A Drop operation source (see Queue::m_traceDrop).

The upper-level (MAC) trace hooks for the CsmaNetDevice are, in fact, exactly
these three trace sources on the single transmit queue of the device.  

The m_traceEnqueue event is triggered when a packet is placed on the transmit
queue. This happens at the time that CsmaNetDevice::Send or
CsmaNetDevice::SendFrom is called by a higher layer to queue a packet for
transmission.

The m_traceDequeue event is triggered when a packet is removed from the transmit
queue. Dequeues from the transmit queue can happen in three situations:  1) If
the underlying channel is idle when the CsmaNetDevice::Send or
CsmaNetDevice::SendFrom is called, a packet is dequeued from the transmit queue
and immediately transmitted;  2) If the underlying channel is idle, a packet may
be dequeued and immediately transmitted in an internal TransmitCompleteEvent
that functions much like a transmit complete interrupt service routine; or 3)
from the random exponential backoff handler if a timeout is detected.

Case (3) implies that a packet is dequeued from the transmit queue if it is
unable to be transmitted according to the backoff rules. It is important to
understand that this will appear as a Dequeued packet and it is easy to
incorrectly assume that the packet was transmitted since it passed through the
transmit queue. In fact, a packet is actually dropped by the net device in this
case. The reason for this behavior is due to the definition of the Queue Drop
event. The m_traceDrop event is, by definition, fired when a packet cannot be
enqueued on the transmit queue because it is full. This event only fires if the
queue is full and we do not overload this event to indicate that the CsmaChannel
is "full."

Lower-Level (PHY) Hooks
+++++++++++++++++++++++

Similar to the upper level trace hooks, there are trace hooks available at the
lower levels of the net device. We call these the PHY hooks. These events fire
from the device methods that talk directly to the CsmaChannel.

The trace source m_dropTrace is called to indicate a packet that is dropped by
the device. This happens in two cases: First, if the receive side of the net
device is not enabled (see CsmaNetDevice::m_receiveEnable and the associated
attribute "ReceiveEnable").

The m_dropTrace is also used to indicate that a packet was discarded as corrupt
if a receive error model is used (see CsmaNetDevice::m_receiveErrorModel and the
associated attribute "ReceiveErrorModel").

The other low-level trace source fires on reception of an accepted packet (see
CsmaNetDevice::m_rxTrace). A packet is accepted if it is destined for the
broadcast address, a multicast address, or to the MAC address assigned to the
net device.
