00001 /** 00002 * \ingroup devices 00003 * \defgroup PointToPointModel Point-to-Point Model 00004 * 00005 * \section PointToPointPointOverview Point-to-Point Model Overview 00006 * 00007 * The ns-3 point-to-point model is of a very simple point to point data link 00008 * connecting exactly two ns3::PointToPointNetDevice devices over an 00009 * ns3::PointToPointChannel. This can be viewed as equivalent to a full 00010 * duplex RS-232 or RS-422 link with null modem and no handshaking. 00011 * 00012 * Data is encapsulated in the Point-to-Point Protocol (PPP -- RFC 1661), 00013 * however the Link Control Protocol (LCP) and associated state machine is 00014 * not implemented. The PPP link is assumed to be established and 00015 * authenticated at all times. 00016 * 00017 * Data is not framed, therefore Address and Control fields will not be found. 00018 * Since the data is not framed, there is no need to provide Flag Sequence and 00019 * Control Escape octets, nor is a Frame Check Sequence appended. All that is 00020 * required to implement non-framed PPP is to prepend the PPP protocol number 00021 * for IP Version 4 which is the sixteen-bit number 0x21 (see 00022 * http://www.iana.org/assignments/ppp-numbers). 00023 * 00024 * The PointToPointNetDevice provides following Attributes: 00025 * 00026 * - Address: The ns3::Mac48Address of the device (if desired); 00027 * - DataRate: The data rate (ns3::DataRate) of the device; 00028 * - TxQueue: The trasmit queue (ns3::Queue) used by the device; 00029 * - InterframeGap: The optional ns3::Time to wait between "frames"; 00030 * - Rx: A trace source for received packets; 00031 * - Drop: A trace source for dropped packets. 00032 * 00033 * The PointToPointNetDevice models a transmitter section that puts bits 00034 * on a corresponding channel "wire." `The DataRate attribute specifies the 00035 * number of bits per second that the device will simulate sending over the 00036 * channel. In reality no bits are sent, but an event is scheduled for an 00037 * elapsed time consistent with the number of bits in each packet and the 00038 * specified DataRate. The implication here is that the receiving device 00039 * models a receiver section that can receive any any data rate. Therefore 00040 * there is no need, nor way to set a receive data rate in this model. By 00041 * setting the DataRate on the transmitter of both devices connected to a 00042 * given PointToPointChannel one can model a symmetric channel; or by 00043 * setting different DataRates one can model an asymmetric channel (e.g., 00044 * ADSL). 00045 * 00046 * The PointToPointNetDevice supports the assignment of a "receive error 00047 * model." This is an ns3::ErrorModel object that is used to simulate data 00048 * corruption on the link. 00049 * 00050 * \section PointToPointChannelModel Point-to-Point Channel Model 00051 00052 * The point to point net devices are connected via an 00053 * ns3::PointToPointChannel. This channel models two wires transmitting bits 00054 * at the data rate specified by the source net device. There is no overhead 00055 * beyond the eight bits per byte of the packet sent. That is, we do not 00056 * model Flag Sequences, Frame Check Sequences nor do we "escape" any data. 00057 * 00058 * The PointToPointNetChannel provides following Attributes: 00059 * 00060 * - Delay: An ns3::Time specifying the speed of light transmission delay for 00061 * the channel. 00062 * 00063 * \section PointToPointTracingModel Point-to-Point Tracing Model 00064 * 00065 * Like all ns-3 devices, the Point-to-Point Model provides a number of trace 00066 * sources. These trace sources can be hooked using your own custom trace code, 00067 * or you can use our helper functions to arrange for tracing to be enabled on 00068 * devices you specify. 00069 * 00070 * \subsection PointToPointTracingModelUpperHooks Upper-Level (MAC) Hooks 00071 * 00072 * From the point of view of tracing in the net device, there are several 00073 * interesting points to insert trace hooks. A convention inherited from other 00074 * simulators is that packets destined for transmission onto attached networks 00075 * pass through a single "transmit queue" in the net device. We provide trace 00076 * hooks at this point in packet flow, which corresponds (abstractly) only to a 00077 * transition from the network to data link layer, and call them collectively 00078 * the device MAC hooks. 00079 * 00080 * When a packet is sent to the Point-to-Point net device for transmission it 00081 * always passes through the transmit queue. The transmit queue in the 00082 * PoiintToPointNetDevice inherits from Queue, and therefore inherits three 00083 * trace sources: 00084 * 00085 * - An Enqueue operation source (see Queue::m_traceEnqueue); 00086 * - A Dequeue operation source (see Queue::m_traceDequeue); 00087 * - A Drop operation source (see Queue::m_traceDrop). 00088 * 00089 * The upper-level (MAC) trace hooks for the PointToPointNetDevice are, in fact, 00090 * exactly these three trace sources on the single transmit queue of the device. 00091 * 00092 * The m_traceEnqueue event is triggered when a packet is placed on the transmit 00093 * queue. This happens at the time that ns3::PointtoPointNetDevice::Send or 00094 * ns3::PointToPointNetDevice::SendFrom is called by a higher layer to queue a 00095 * packet for transmission. An Enqueue trace event firing should be interpreted 00096 * as only indicating that a higher level protocol has sent a packet to the device. 00097 * 00098 * The m_traceDequeue event is triggered when a packet is removed from the 00099 * transmit queue. Dequeues from the transmit queue can happen in two 00100 * situations: 1) If the underlying channel is idle when 00101 * PointToPointNetDevice::Send is called, a packet is dequeued from the transmit 00102 * queue and immediately transmitted; 2) a packet may be dequeued and 00103 * immediately transmitted in an internal TransmitCompleteEvent that functions 00104 * much like a transmit complete interrupt service routine. An Dequeue trace 00105 * event firing may be viewed as indicating that the PointToPointNetDevice has 00106 * begun transmitting a packet. 00107 * 00108 * \subsection CsmaTracingModelUpperHooks Lower-Level (PHY) Hooks 00109 * 00110 * Similar to the upper level trace hooks, there are trace hooks available at 00111 * the lower levels of the net device. We call these the PHY hooks. These 00112 * events fire from the device methods that talk directly to the 00113 * PointToPointChannel. 00114 * 00115 * The trace source m_dropTrace is called to indicate a packet that is dropped 00116 * by the device. This happens when a packet is discarded as corrupt due to a 00117 * receive error model indication (see ns3::ErrorModel and the associated 00118 * attribute "ReceiveErrorModel"). 00119 * 00120 * The other low-level trace source fires on reception of a packet (see 00121 * ns3::PointToPointNetDevice::m_rxTrace) from the PointToPointChannel. 00122 * 00123 * \section PointToPointModelSummary Point-To-Point Model Summary 00124 * 00125 * The ns3 Point-to-Point model is a simplistic model of a point to point 00126 * serial line link. 00127 * 00128 * Ns-3 Attributes provide a mechanism for setting various parameters in the 00129 * device and channel such as data rates, speed-of-light delays and error model 00130 * selection. Trace hooks are provided in the usual manner with a set of 00131 * upper level hooks corresponding to a transmit queue and used in ASCII 00132 * tracing; and also a set of lower level hooks used in pcap tracing. 00133 */