full duplex extensions for CSMA

This is a continuation of issue https://codereview.appspot.com/5615049/

This code can be tested by checking out http://code.nsnam.org/tomh/ns-3-dev-csmafd

There seem to be basically two existing issues to resolve before trying to merge this.

1) Hugo Pinto raised some questions about possible bugs in the previous review issue here:
https://codereview.appspot.com/5615049/#msg28
2) I have asked for some test cases and tests 

A third issue that I'll ask now is whether to just default the ns-3 implementation to use full duplex mode.  This patch requires the user to explicitly enable it.

[Luciano Chaves, 2016-02-24 16:03:05]

Hi,

About the full-duplex extension for CSMA, questions raised by Hugo at
https://codereview.appspot.com/5615049/#msg28 are relevant. Also, I found a
small bug at CsmaChannel::Attach.

I have been using this full duplex extension for CSMA model for more than a
year, and I have experienced no errors (I have tested it on ns-3.22, 3.23 and
3.24.1 together with the OpenFlow 1.3 module that I’ve been working with). I
believe that it is a simple model for high-speed links that is working perfectly
fine, and should be considered for ns-3.26 release. I’ll try to provide a patch
for the upcoming 3.25 release, including an example scenario.

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.cc
File src/csma/model/csma-channel.cc (left):

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.c...
src/csma/model/csma-channel.cc:240: Simulator::Schedule (m_delay,
&CsmaChannel::PropagationCompleteEvent,
As indicated by Hugo at https://codereview.appspot.com/5615049/#msg28, the
device shouldn't be busy while propagating. The patch from MurphyMc at 
https://github.com/nsnam/ns-3-dev-git/commit/e3b384e009446d390e9aa494a0f56eff...
solves the issue.

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.cc
File src/csma/model/csma-channel.cc (right):

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.c...
src/csma/model/csma-channel.cc:83: if (m_fullDuplex && m_deviceList.size () > 2)
To ensure that no more than two devices are attached to the channel, the testing
case should be m_deviceList.size () > 1, as this test is performed before adding
the 'device'.

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-net-devic...
File src/csma/model/csma-net-device.cc (left):

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-net-devic...
src/csma/model/csma-net-device.cc:450: m_txMachineState = BACKOFF;
The question raised by at Hugo Pinto at
https://codereview.appspot.com/5615049/#msg28 is perfectly relevant. There is no
contention for full-duplex channels, so the multiple access algorithm is
unnecessary and is not used. So, the TX machine state must never enters in
backoff state. The patch from MurphyMc at 
https://github.com/nsnam/ns-3-dev-git/commit/af68adc10f18912ed26de47da410734a...
solves the issue.

[joao, 2016-08-13 23:21:56]

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.cc
File src/csma/model/csma-channel.cc (right):

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.c...
src/csma/model/csma-channel.cc:195: if (GetState (srcId) != IDLE)
Can't a transmission start if there is some packet PROPAGATING?

[Luciano Chaves, 2016-08-15 18:00:25]

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.cc
File src/csma/model/csma-channel.cc (right):

https://codereview.appspot.com/187880044/diff/1/src/csma/model/csma-channel.c...
src/csma/model/csma-channel.cc:195: if (GetState (srcId) != IDLE)
On 2016/08/13 23:21:56, joao wrote:
> Can't a transmission start if there is some packet PROPAGATING? 

Yeah, in full-duplex operation there is no need to wait for the packet
propagation delay before starting the transmission of the next packet.
I was checking the code and found that it is working ok. The GetState () on
TransmitStart function will never return the PROPAGATING state because the
PROPAGATING state is set by the TransmitEnd () function, which also schedules
the PropagationCompleteEvent () for the same time in full duplex operation. This
PropagationCompleteEvent () will set the channel state back to IDLE even during
the packet propagation.

[Luciano Chaves, 2017-01-05 17:14:02]

A revised patch for this extension, including updated documentation and an
example was submitted to https://www.nsnam.org/bugzilla/show_bug.cgi?id=2354.