00001 /** 00002 * \ingroup devices 00003 * \defgroup CsmaModel CSMA Model 00004 * 00005 * \section CsmaModelOverview CSMA Model Overview 00006 * 00007 * The ns-3 CSMA device models a simple bus network in the spirit of Ethernet. 00008 * Although it does not model any real physical network you could ever build 00009 * or buy, it does provide some very useful functionality. 00010 * 00011 * Typically when one thinks of a bus network Ethernet or IEEE 802.3 comes to 00012 * mind. Ethernet uses CSMA/CD (Carrier Sense Multiple Access with Collision 00013 * Detection with exponentially increasing backoff to contend for the shared 00014 * transmission medium. The ns-3 CSMA device models only a portion of this 00015 * process, using the nature of the globally available channel to provide 00016 * instantaneous (faster than light) carrier sense and priority-based 00017 * collision "avoidance." Collisions in the sense of Ethernet never happen and 00018 * so the ns-3 CSMA device does not model collision detection, nor will any 00019 * transmission in progress be "jammed." 00020 * 00021 * \section CsmaLayerModel CSMA Layer Model 00022 * 00023 * There are a number of conventions in use for describing layered 00024 * communications architectures in the literature and in textbooks. The most 00025 * common layering model is the ISO seven layer reference model. In this view 00026 * the ns3::CsmaNetDevice and ns3::CsmaChannel pair occupies the lowest two 00027 * layers -- at the physical (layer one), and data link (layer two) positions. 00028 * Another important reference model is that specified by RFC 1122, 00029 * "Requirements for Internet Hosts -- Communication Layers." In this view the 00030 * CsmaNetDevice and CsmaChannel pair occupies the lowest layer -- 00031 * the link layer. There is also a seemingly endless litany of alternative 00032 * descriptions found in textbooks and in the literature. We adopt the naming 00033 * conventions used in the IEEE 802 standards which speak of LLC, MAC, MII 00034 * and PHY layering. These acronyms are defined as: 00035 * 00036 * - LLC: Logical Link Control; 00037 * - MAC: Media Access Control; 00038 * - MII: Media Independent Interface; 00039 * - PHY: Physical Layer. 00040 * 00041 * In this case the LLC and MAC are sublayers of the OSI data link layer and the 00042 * MII and PHY are sublayers of the OSI physical layer. 00043 * 00044 * The "top" of the CSMA device defines the transition from the network layer 00045 * to the data link layer. This transition is performed by higher layers by 00046 * calling either ns3::CsmaNetDevice::Send or ns3::CsmaNetDevice::SendFrom. 00047 * 00048 * In contrast to the IEEE 802.3 standards, there is no precisely specified 00049 * PHY in the CSMA model in the sense of wire types, signals or pinouts. The 00050 * "bottom" interface of the CsmaNetDevice can be thought of as as a kind 00051 * of Media Independent Interface (MII) as seen in the "Fast Ethernet" 00052 * (IEEE 802.3u) specifications. This MII interface fits into a corresponding 00053 * media independent interface on the CsmaChannel. You will not find the 00054 * equivalent of a 10BASE-T or a 1000BASE-LX PHY. 00055 * 00056 * The CsmaNetDevice calls the CsmaChannel through a media independent 00057 * interface. There is a method defined to tell the channel when to start 00058 * "wiggling the wires" using the method ns3::CsmaChannel::TransmitStart, and 00059 * a method to tell the channel when the transmission process is done and 00060 * the channel should begin propagating the last bit across the "wire": 00061 * ns3::CsmaChannel::TransmitEnd. 00062 * 00063 * When the TransmitEnd method is executed, the channel will model a single 00064 * uniform signal propagation delay in the medium and deliver copes of the packet 00065 * to each of the devices attached to the packet via the 00066 * ns3::CsmaNetDevice::Receive method. 00067 * 00068 * There is a "pin" in the device media independent interface corresponding to 00069 * "COL" (collision). The state of the channel may be sensed by calling 00070 * ns3::CsmaChannel::GetState. Each device will look at this "pin" before 00071 * starting a send and will perform appropriate backoff operations if required. 00072 * 00073 * Properly received packets are forwarded up to higher levels from the 00074 * CsmaNetDevice via a callback mechanism. The callback function is 00075 * initialized by the higher layer (when the net device is attached) using 00076 * ns3::CsmaNetDevice::SetReceiveCallback and is invoked upon "proper" 00077 * reception of a packet by the net device in order to forward the packet up 00078 * the protocol stack. 00079 * 00080 * \section CsmaChannelModel CSMA Channel Model 00081 * 00082 * The class CsmaChannel models the actual transmission medium. 00083 * There is no fixed limit for the number of devices connected to the channel. 00084 * The CsmaChannel models a data rate and a speed-of-light delay which can 00085 * be accessed via the attributes "DataRate" and "Delay" respectively. 00086 * The data rate provided to the channel is used to set the data rates 00087 * used by the transmitter sections of the CSMA devices connected to the 00088 * channel. There is no way to independently set data rates in the 00089 * devices. Since the data rate is only used to calculate a delay time, there 00090 * is no limitation (other than by the data type holding the value) on the 00091 * speed at which CSMA channels and devices can operate; and no restriction 00092 * based on any kind of PHY characteristics. 00093 * 00094 * The CsmaChannel has three states, IDLE, TRANSMITTING and PROPAGATING. 00095 * These three states are "seen" instantaneously by all devices on the channel. 00096 * By this we mean that if one device begins or ends a simulated transmission, 00097 * all devices on the channel are immediately aware of the change in state. 00098 * There is no time during which one device may see an IDLE channel while 00099 * another device physically further away in the collision domain may have 00100 * begun transmitting with the associated signals not propagated. Thus there 00101 * is no need for collision detection in the CsmaChannel model and it is 00102 * not implemented in any way. 00103 * 00104 * We do, as the name indicates, have a Carrier Sense aspect to the model. 00105 * Since the simulator is single threaded, access to the common channel will 00106 * be serialized by the simulator. This provides a deterministic mechanism 00107 * for contending for the channel. The channel is allocated (transitioned from 00108 * state IDLE to state TRANSMITTING) on a first-come first-served basis. The 00109 * channel always goes through a three state process: 00110 * 00111 * IDLE -> TRANSMITTING -> PROPAGATING -> IDLE 00112 * 00113 * The TRANSMITTING state models the time during which the source net device 00114 * is actually wiggling the signals on the wire. The PROPAGATING state models 00115 * the time after the last bit was sent, when the signal is propagating down 00116 * the wire to the "far end." 00117 * 00118 * The transition to the TRANSMITTING state is driven by a call to 00119 * ns3::CsmaChannel::TransmitStart which is called by the net device that 00120 * transmits the packet. It is the responsibility of that device to end the 00121 * transmission with a call to ns3::CsmaChannel::TransmitEnd at the appropriate 00122 * simulation time that reflects the time elapsed to put all of the packet bits 00123 * on the wire. When TransmitEnd is called, the channel schedules an event 00124 * corresponding to a single speed-of-light delay. This delay applies to all 00125 * net devices on the channel identically. You can think of a symmetrical hub 00126 * in which the packet bits propagate to a central location and then back out 00127 * equal length cables to the other devices on the channel. 00128 * 00129 * The CsmaChannel models a broadcast medium so the packet is delivered 00130 * to all of the devices on the channel (including the source) at the end of 00131 * the propagation time. It is the responsibility of the sending device to 00132 * determine whether or not it receives a packet broadcast over the channel. 00133 * 00134 * The CsmaChannel provides following Attributes: 00135 * 00136 * - DataRate: The bitrate for packet transmission on connected devices; 00137 * - Delay: The speed of light transmission delay for the channel. 00138 * 00139 * \section CsmaNetDeviceModel CSMA Net Device Model 00140 * 00141 * The CSMA network device appears somewhat like an Ethernet device. The 00142 * CsmaNetDevice provides following Attributes: 00143 * 00144 * - Address: The Mac48Address of the device; 00145 * - SendEnable: Enable packet transmission if true; 00146 * - ReceiveEnable: Enable packet reception if true; 00147 * - EncapsulationMode: Type of link layer encapsulation to use; 00148 * - RxErrorModel: The receive error model; 00149 * - TxQueue: The trasmit queue used by the device; 00150 * - InterframeGap: The optional time to wait between "frames"; 00151 * - Rx: A trace source for received packets; 00152 * - Drop: A trace source for dropped packets. 00153 * 00154 * The CsmaNetDevice supports the assignment of a "receive error model." 00155 * This is an ErrorModel object that is used to simulate data corruption 00156 * on the link. 00157 * 00158 * Packets sent over the CsmaNetDevice are always routed through the 00159 * transmit queue to provide a trace hook for packets sent out over the 00160 * network. This transmit queue can be set (via attribute) to model different 00161 * queueing strategies. 00162 * 00163 * Also configurable by attribute is the encapsulation method used by the 00164 * device. By default, or by setting the "EncapsulationMode" attribute to 00165 * "Dix", the encapsulation is according to the DEC, Intel, Xerox standard. 00166 * This is sometimes called EthernetII framing and is the familiar destination 00167 * MAC, source MAC, EtherType, Data, CRC format. 00168 * 00169 * If the "EncapsulationMode" attribute is set to "Llc", the encapsulation is by 00170 * LLC SNAP. In this case, a SNAP header is added that contains the EtherType 00171 * (IP or ARP). 00172 * 00173 * The other implemented encapsulation modes are IP_ARP (set "EncapsulationMode" 00174 * to "IpArp") in which the length type of the Ethernet header receives the 00175 * protocol number of the packet; or ETHERNET_V1 (set "EncapsulationMode" to 00176 * "EthernetV1") in which the length type of the Ethernet header receives the 00177 * length of the packet. A "Raw" encapsulation mode is defined but not 00178 * implemented -- use of the RAW mode results in an assertion. 00179 * 00180 * The CsmaNetDevice implements a random exponential backoff algorithm 00181 * that is executed if the channel is determined to be busy (TRANSMITTING or 00182 * PROPAGATING) when the device wants to start propagating. This results in a 00183 * random delay of up to pow (2, retries) - 1 microseconds before a retry is 00184 * attempted. The default maximum number of retries is 1000. 00185 * 00186 * \section CsmaTracingModel CSMA Tracing Model 00187 * 00188 * Like all ns-3 devices, the CSMA Model provides a number of trace sources. 00189 * These trace sources can be hooked using your own custom trace code, or you 00190 * can use our helper functions to arrange for tracing to be enabled on devices 00191 * you specify. 00192 * 00193 * \subsection CsmaTracingModelUpperHooks Upper-Level (MAC) Hooks 00194 * 00195 * From the point of view of tracing in the net device, there are several 00196 * interesting points to insert trace hooks. A convention inherited from other 00197 * simulators is that packets destined for transmission onto attached networks 00198 * pass through a single "transmit queue" in the net device. We provide trace 00199 * hooks at this point in packet flow, which corresponds (abstractly) only to a 00200 * transition from the network to data link layer, and call them collectively 00201 * the device MAC hooks. 00202 * 00203 * When a packet is sent to the CSMA net device for transmission it always 00204 * passes through the transmit queue. The transmit queue in the 00205 * CsmaNetDevice inherits from Queue, and therefore inherits three 00206 * trace sources: 00207 * 00208 * - An Enqueue operation source (see Queue::m_traceEnqueue); 00209 * - A Dequeue operation source (see Queue::m_traceDequeue); 00210 * - A Drop operation source (see Queue::m_traceDrop). 00211 * 00212 * The upper-level (MAC) trace hooks for the CsmaNetDevice are, in fact, 00213 * exactly these three trace sources on the single transmit queue of the device. 00214 * 00215 * The m_traceEnqueue event is triggered when a packet is placed on the transmit 00216 * queue. This happens at the time that ns3::CsmaNetDevice::Send or 00217 * ns3::CsmaNetDevice::SendFrom is called by a higher layer to queue a packet for 00218 * transmission. 00219 * 00220 * The m_traceDequeue event is triggered when a packet is removed from the 00221 * transmit queue. Dequeues from the transmit queue can happen in three 00222 * situations: 1) If the underlying channel is idle when the 00223 * CsmaNetDevice::Send or CsmaNetDevice::SendFrom is called, a packet 00224 * is dequeued from the transmit queue and immediately transmitted; 2) If the 00225 * underlying channel is idle, a packet may be dequeued and immediately 00226 * transmitted in an internal TransmitCompleteEvent that functions much 00227 * like a transmit complete interrupt service routine; or 3) from 00228 * the random exponential backoff handler if a timeout is detected. 00229 * 00230 * Case (3) implies that a packet is dequeued from the transmit queue if it is 00231 * unable to be transmittted according to the backoff rules. It is important 00232 * to understand that this will appear as a Dequeued packet and it is easy to 00233 * incorrectly assume that the packet was transmitted since it passed through 00234 * the transmit queue. In fact, a packet is actually dropped by the net device 00235 * in this case. The reason for this behavior is due to the definition of the 00236 * Queue Drop event. The m_traceDrop event is, by defintion, fired when a 00237 * packet cannot be enqueued on the transmit queue becasue it is full. This 00238 * event only fires if the queue is full and we do not overload this event 00239 * to indicate that the CsmaChannel is "full." 00240 * 00241 * \subsection CsmaTracingModelUpperHooks Lower-Level (PHY) Hooks 00242 * 00243 * Similar to the upper level trace hooks, there are trace hooks available at 00244 * the lower levels of the net device. We call these the PHY hooks. These 00245 * events fire from the device methods that talk directly to the CsmaChannel. 00246 * 00247 * The trace source m_dropTrace is called to indicate a packet that is dropped 00248 * by the device. This happens in two cases: First, if the receive side of 00249 * the net device is not enabled (see ns3::CsmaNetDevice::m_receiveEnable and the 00250 * associated attribute "ReceiveEnable"). 00251 * 00252 * The m_dropTrace is also used to indicate that a packet was discarded as 00253 * corrupt if a receive error model is used (see 00254 * ns3::CsmaNetDevice::m_receiveErrorModel and the associated attribute 00255 * "ReceiveErrorModel"). 00256 * 00257 * The other low-level trace source fires on reception of an accepted packet 00258 * (see ns3::CsmaNetDevice::m_rxTrace). A packet is accepted if it is destined 00259 * for the broadcast address, a multicast address, or to the MAC address 00260 * assigned to the net device. 00261 * 00262 * \section CsmaModelSummary CSMA Model Summary 00263 * 00264 * The ns3 CSMA model is a simplistic model of an Ethernet-like network. It 00265 * supports a Carrier-Sense function and allows for Multiple Access to a 00266 * shared medium. It is not physical in the sense that the state of the 00267 * medium is instantaneously shared among all devices. This means that there 00268 * is no collision detection required in this model and none is implemented. 00269 * There will never be a "jam" of a packet already on the medium. Access to 00270 * the shared channel is on a first-come first-served basis as determined by 00271 * the simulator scheduler. If the channel is determined to be busy by looking 00272 * at the global state, a random exponential backoff is performed and a retry 00273 * is attempted. 00274 * 00275 * Ns-3 Attributes provide a mechanism for setting various parameters in the 00276 * device and channel such as addresses, encapsulation modes and error model 00277 * selection. Trace hooks are provided in the usual manner with a set of 00278 * upper level hooks corresponding to a transmit queue and used in ASCII 00279 * tracing; and also a set of lower level hooks used in pcap tracing. 00280 * 00281 * Although the ns-3 CsmaChannel and CsmaNetDevice does not model any kind of 00282 * network you could build or buy, it does provide us with some useful 00283 * functionality. You should, however, understand that it is explicitly not 00284 * Ethernet or any flavor of IEEE 802.3 but an interesting subset. 00285 */