diff -r 9e060dd421fa -r 8a5e1f9db873 src/devices/csma/csma-net-device.h --- 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