--- a/src/devices/csma/csma-net-device.h Thu Apr 08 23:01:34 2010 +0900
+++ b/src/devices/csma/csma-net-device.h Sat Apr 10 13:45:09 2010 -0700
@@ -185,108 +185,10 @@
void SetReceiveEnable (bool enable);
/**
- * Set The max frame size of packets sent over this device.
- *
- * Okay, that was easy to say, but the details are a bit thorny. We have a MAC-level MTU that is the payload that higher
- * level protocols see. We have a PHY-level MTU which is the maximum number of bytes we can send over the link
- * (cf. 1500 bytes for Ethernet). We also have a frame size which is some total number of bytes in a packet which could
- * or could not include any framing and overhead. There can be a lot of inconsistency in definitions of these terms. For
- * example, RFC 1042 asserts that the terms maximum transmission unit and maximum packet size are equivalent. RFC 791,
- * however, defines MTU as the maximum sized IP datagram that can be sent. Packet size and frame size are sometimes
- * used interchangeably.
- *
- * So, some careful definitions are in order to avoid confusion:
- *
- * In real Ethernet, a packet on the wire starts with a preamble of seven bytes of alternating ones and zeroes followed by
- * a Start-of-Frame-Delimeter (10101011). This is followed by what is usually called the packet: a MAC destination and
- * source, a type field, payload, a possible padding field and a CRC. To be strictly and pedantically correct the frame
- * size is necessarily larger than the packet size on a real Ethernet. But, this isn't a real Ethernet, it's a simulation
- * of a device similar to Ethernet, and we have no good reason to add framing bits. So, in the case of the CSMA device,
- * the frame size is equal to the packet size. Since these two values are equal, there is no danger in assuming they are
- * identical. We do not implement any padding out to a minimum frame size, so padding is a non-issue. We define packet
- * size to be equal to frame size and this excludes the preamble and SFD bytes of a real Ethernet frame. We define a
- * single (MAC-level) MTU that coresponds to the payload size of the packet, which is the IP-centric view of the term as
- * seen in RFC 791.
- *
- * To make this concrete, consider DIX II (Digital Equipment, Intel, Xerox type II) framing, which is used in most TCP/IP
- * stacks. NetWare and Wireshark call this framing Ethernet II, by the way. In this framing scheme, a real packet on the
- * wire starts with the preamble and Start-of-Frame-Delimeter (10101011). We ignore these bits on this device since it they
- * are not needed. In DIX II, the SFD is followed by the MAC (48) destination address (6 bytes), source address (6 bytes),
- * the EtherType field (2 bytes), payload (0-1500 bytes) and a CRC (4 bytes) -- this corresponds to our entire frame. The
- * payload of the packet/frame in DIX can be from 0 to 1500 bytes. It is the maxmimum value of this payload that we call
- * the MTU. Typically, one sees the MTU set to 1500 bytes and the maximum frame size set to 1518 bytes in Ethernet-based
- * networks.
- *
- * Different framing schemes can make for different MTU and frame size relationships. For example, we support LLC/SNAP
- * encapsulation which adds eight bytes of header overhead to the usual DIX framing. In this case, if the maximum frame
- * size is left at 1518 bytes, we need to export an MTU that reflects the loss of eight bytes for a total of 1492.
- *
- * Another complication is that IEEE 802.1Q adds four bytes to the maximum frame size for VLAN tagging. In order to
- * provide an MTU of 1500 bytes, the frame size would need to increased to 1522 bytes to absorb the additional overhead.
- *
- * So, there are really three variables that are not entirely free at work here. There is the maximum frame size, the
- * MTU and the framing scheme which we call the encapsulation mode.
- *
- * So, what do we do since there are be three values which must always be consistent in the driver? Which values to we
- * allow to be changed and how do we ensure the other two are consistent? We want to actually allow a user to change
- * these three variables in flexible ways, but we want the results (even at intermediate stages of her ultimate change) to
- * be consistent. We certainly don't want to require that users must understand the various requirements of an enapsulation
- * mode in order to set these variables.
- *
- * Consider the following situation: A user wants to set the maximum frame size to 1418 bytes instead of 1518. This
- * user shouldn't have to concern herself that the current encapuslation mode is LLC/SNAP and this will consume eight bytes.
- * She should not have to also figure out that the MTU needs to be set to 1392 bytes, and she should certainly not have to
- * do this in some special order to keep intermediate steps consistent.
- *
- * Similarly, a user who is interested in setting the MTU to 1400 bytes should not be forced to understand that
- * (based on encapsulation mode) the frame size may need to be set to eighteen + eight bytes more than what he wants
- * in certain cases (802,3 + LLC/SNAP), twenty-two + zero bytes in others (802.1Q) and other inscrutable combinations
- *
- * Now, consider a user who is only interested in changing the encapsulation mode from LLC/SNAP to DIX. This
- * is going to change the relationship between the MTU and the frame size. We've may have to come up with a new value
- * for at least one of the these? Which one? There are too many free variables.
- *
- * We could play games trying to figure out what the user wants to do, but that is typically a bad plan and programmers
- * have a long and distinguished history of guessing wrong. We'll avoid all of that and just define a flexible behavior
- * that can be worked to get what you want. Here it is:
- *
- * - If the user is changing the encapsulation mode, the PHY MTU will remain fixed and the MAC MTU will change, if required,
- * to make the three values consistent;
- *
- * - If the user is changing the MTU, she is interested in getting that part of the system set, so the frame size
- * will be changed to make the three values consistent;
- *
- * - If the user is changing the frame size, he is interested in getting that part of the system set, so the MTU
- * will be changed to make the three values consistent;
- *
- * - You cannot define the MTU and frame size separately -- they are always tied together by the emulation mode. This
- * is not a restriction. Consider what this means. Perhaps you want to set the frame size to some large number and the
- * MTU to some small number. The largest packet you can send is going to be limited by the MTU, so it is not possible to
- * send a frame larger than the MTU plus overhead. The larger frame size is not useful.
- *
- * So, if a user calls SetFrameSize, we assume that the maximum frame size is the interesting thing for that user and
- * we just adjust the MTU to a new "correct value" based on the current encapsulation mode. If a user calls SetMtu, we
- * assume that the MTU is the interesting property for that user, and we adjust the frame size to a new "correct value"
- * for the current encapsulation mode. If a user calls SetEncapsulationMode, then we take the MTU as the free variable
- * and set its value to match the current frame size.
- *
- * \param frameSize The max frame size of packets sent over this device.
- */
- void SetFrameSize (uint16_t frameSize);
-
- /**
- * Get The max frame size of packets sent over this device.
- *
- * \returns The max frame size of packets sent over this device.
- */
- uint16_t GetFrameSize (void) const;
-
- /**
* Set the encapsulation mode of this device.
*
* \param mode The encapsulation mode of this device.
*
- * \see SetFrameSize
*/
void SetEncapsulationMode (CsmaNetDevice::EncapsulationMode mode);
@@ -456,20 +358,6 @@
void Init (bool sendEnable, bool receiveEnable);
/**
- * Calculate the value for the MTU that would result from
- * setting the frame size to the given value.
- * \param frameSize size of frame
- */
- uint32_t MtuFromFrameSize (uint32_t frameSize);
-
- /**
- * Calculate the value for the frame size that would be required
- * to be able to set the MTU to the given value.
- * \param mtu MTU
- */
- uint32_t FrameSizeFromMtu (uint32_t mtu);
-
- /**
* Start Sending a Packet Down the Wire.
*
* The TransmitStart method is the method that is used internally in
@@ -804,15 +692,7 @@
*/
TracedCallback<> m_linkChangeCallbacks;
- static const uint16_t DEFAULT_FRAME_SIZE = 1518;
- static const uint16_t ETHERNET_OVERHEAD = 18;
-
- /**
- * The frame size/packet size. This corresponds to the maximum
- * number of bytes that can be transmitted as a packet without framing.
- * This corresponds to the 1518 byte packet size often seen on Ethernet.
- */
- uint32_t m_frameSize;
+ static const uint16_t DEFAULT_MTU = 1500;
/**
* The Maxmimum Transmission Unit. This corresponds to the maximum