|
185 |
void SetReceiveEnable (bool enable); |
185 |
void SetReceiveEnable (bool enable); |
186 |
|
186 |
|
187 |
/** |
187 |
/** |
188 |
* Set The max frame size of packets sent over this device. |
|
|
189 |
* |
190 |
* 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 |
191 |
* level protocols see. We have a PHY-level MTU which is the maximum number of bytes we can send over the link |
192 |
* (cf. 1500 bytes for Ethernet). We also have a frame size which is some total number of bytes in a packet which could |
193 |
* or could not include any framing and overhead. There can be a lot of inconsistency in definitions of these terms. For |
194 |
* example, RFC 1042 asserts that the terms maximum transmission unit and maximum packet size are equivalent. RFC 791, |
195 |
* however, defines MTU as the maximum sized IP datagram that can be sent. Packet size and frame size are sometimes |
196 |
* used interchangeably. |
197 |
* |
198 |
* So, some careful definitions are in order to avoid confusion: |
199 |
* |
200 |
* In real Ethernet, a packet on the wire starts with a preamble of seven bytes of alternating ones and zeroes followed by |
201 |
* a Start-of-Frame-Delimeter (10101011). This is followed by what is usually called the packet: a MAC destination and |
202 |
* source, a type field, payload, a possible padding field and a CRC. To be strictly and pedantically correct the frame |
203 |
* size is necessarily larger than the packet size on a real Ethernet. But, this isn't a real Ethernet, it's a simulation |
204 |
* of a device similar to Ethernet, and we have no good reason to add framing bits. So, in the case of the CSMA device, |
205 |
* the frame size is equal to the packet size. Since these two values are equal, there is no danger in assuming they are |
206 |
* identical. We do not implement any padding out to a minimum frame size, so padding is a non-issue. We define packet |
207 |
* size to be equal to frame size and this excludes the preamble and SFD bytes of a real Ethernet frame. We define a |
208 |
* single (MAC-level) MTU that coresponds to the payload size of the packet, which is the IP-centric view of the term as |
209 |
* seen in RFC 791. |
210 |
* |
211 |
* To make this concrete, consider DIX II (Digital Equipment, Intel, Xerox type II) framing, which is used in most TCP/IP |
212 |
* stacks. NetWare and Wireshark call this framing Ethernet II, by the way. In this framing scheme, a real packet on the |
213 |
* wire starts with the preamble and Start-of-Frame-Delimeter (10101011). We ignore these bits on this device since it they |
214 |
* are not needed. In DIX II, the SFD is followed by the MAC (48) destination address (6 bytes), source address (6 bytes), |
215 |
* the EtherType field (2 bytes), payload (0-1500 bytes) and a CRC (4 bytes) -- this corresponds to our entire frame. The |
216 |
* 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 |
217 |
* the MTU. Typically, one sees the MTU set to 1500 bytes and the maximum frame size set to 1518 bytes in Ethernet-based |
218 |
* networks. |
219 |
* |
220 |
* Different framing schemes can make for different MTU and frame size relationships. For example, we support LLC/SNAP |
221 |
* encapsulation which adds eight bytes of header overhead to the usual DIX framing. In this case, if the maximum frame |
222 |
* size is left at 1518 bytes, we need to export an MTU that reflects the loss of eight bytes for a total of 1492. |
223 |
* |
224 |
* Another complication is that IEEE 802.1Q adds four bytes to the maximum frame size for VLAN tagging. In order to |
225 |
* provide an MTU of 1500 bytes, the frame size would need to increased to 1522 bytes to absorb the additional overhead. |
226 |
* |
227 |
* So, there are really three variables that are not entirely free at work here. There is the maximum frame size, the |
228 |
* MTU and the framing scheme which we call the encapsulation mode. |
229 |
* |
230 |
* So, what do we do since there are be three values which must always be consistent in the driver? Which values to we |
231 |
* allow to be changed and how do we ensure the other two are consistent? We want to actually allow a user to change |
232 |
* these three variables in flexible ways, but we want the results (even at intermediate stages of her ultimate change) to |
233 |
* be consistent. We certainly don't want to require that users must understand the various requirements of an enapsulation |
234 |
* mode in order to set these variables. |
235 |
* |
236 |
* Consider the following situation: A user wants to set the maximum frame size to 1418 bytes instead of 1518. This |
237 |
* user shouldn't have to concern herself that the current encapuslation mode is LLC/SNAP and this will consume eight bytes. |
238 |
* 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 |
239 |
* do this in some special order to keep intermediate steps consistent. |
240 |
* |
241 |
* Similarly, a user who is interested in setting the MTU to 1400 bytes should not be forced to understand that |
242 |
* (based on encapsulation mode) the frame size may need to be set to eighteen + eight bytes more than what he wants |
243 |
* in certain cases (802,3 + LLC/SNAP), twenty-two + zero bytes in others (802.1Q) and other inscrutable combinations |
244 |
* |
245 |
* Now, consider a user who is only interested in changing the encapsulation mode from LLC/SNAP to DIX. This |
246 |
* is going to change the relationship between the MTU and the frame size. We've may have to come up with a new value |
247 |
* for at least one of the these? Which one? There are too many free variables. |
248 |
* |
249 |
* We could play games trying to figure out what the user wants to do, but that is typically a bad plan and programmers |
250 |
* have a long and distinguished history of guessing wrong. We'll avoid all of that and just define a flexible behavior |
251 |
* that can be worked to get what you want. Here it is: |
252 |
* |
253 |
* - If the user is changing the encapsulation mode, the PHY MTU will remain fixed and the MAC MTU will change, if required, |
254 |
* to make the three values consistent; |
255 |
* |
256 |
* - If the user is changing the MTU, she is interested in getting that part of the system set, so the frame size |
257 |
* will be changed to make the three values consistent; |
258 |
* |
259 |
* - If the user is changing the frame size, he is interested in getting that part of the system set, so the MTU |
260 |
* will be changed to make the three values consistent; |
261 |
* |
262 |
* - You cannot define the MTU and frame size separately -- they are always tied together by the emulation mode. This |
263 |
* is not a restriction. Consider what this means. Perhaps you want to set the frame size to some large number and the |
264 |
* 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 |
265 |
* send a frame larger than the MTU plus overhead. The larger frame size is not useful. |
266 |
* |
267 |
* So, if a user calls SetFrameSize, we assume that the maximum frame size is the interesting thing for that user and |
268 |
* we just adjust the MTU to a new "correct value" based on the current encapsulation mode. If a user calls SetMtu, we |
269 |
* assume that the MTU is the interesting property for that user, and we adjust the frame size to a new "correct value" |
270 |
* for the current encapsulation mode. If a user calls SetEncapsulationMode, then we take the MTU as the free variable |
271 |
* and set its value to match the current frame size. |
272 |
* |
273 |
* \param frameSize The max frame size of packets sent over this device. |
274 |
*/ |
275 |
void SetFrameSize (uint16_t frameSize); |
276 |
|
277 |
/** |
278 |
* Get The max frame size of packets sent over this device. |
279 |
* |
280 |
* \returns The max frame size of packets sent over this device. |
281 |
*/ |
282 |
uint16_t GetFrameSize (void) const; |
283 |
|
284 |
/** |
285 |
* Set the encapsulation mode of this device. |
188 |
* Set the encapsulation mode of this device. |
286 |
* |
189 |
* |
287 |
* \param mode The encapsulation mode of this device. |
190 |
* \param mode The encapsulation mode of this device. |
288 |
* |
191 |
* |
289 |
* \see SetFrameSize |
|
|
290 |
*/ |
192 |
*/ |
291 |
void SetEncapsulationMode (CsmaNetDevice::EncapsulationMode mode); |
193 |
void SetEncapsulationMode (CsmaNetDevice::EncapsulationMode mode); |
292 |
|
194 |
|
|
456 |
void Init (bool sendEnable, bool receiveEnable); |
358 |
void Init (bool sendEnable, bool receiveEnable); |
457 |
|
359 |
|
458 |
/** |
360 |
/** |
459 |
* Calculate the value for the MTU that would result from |
|
|
460 |
* setting the frame size to the given value. |
461 |
* \param frameSize size of frame |
462 |
*/ |
463 |
uint32_t MtuFromFrameSize (uint32_t frameSize); |
464 |
|
465 |
/** |
466 |
* Calculate the value for the frame size that would be required |
467 |
* to be able to set the MTU to the given value. |
468 |
* \param mtu MTU |
469 |
*/ |
470 |
uint32_t FrameSizeFromMtu (uint32_t mtu); |
471 |
|
472 |
/** |
473 |
* Start Sending a Packet Down the Wire. |
361 |
* Start Sending a Packet Down the Wire. |
474 |
* |
362 |
* |
475 |
* The TransmitStart method is the method that is used internally in |
363 |
* The TransmitStart method is the method that is used internally in |
|
804 |
*/ |
692 |
*/ |
805 |
TracedCallback<> m_linkChangeCallbacks; |
693 |
TracedCallback<> m_linkChangeCallbacks; |
806 |
|
694 |
|
807 |
static const uint16_t DEFAULT_FRAME_SIZE = 1518; |
695 |
static const uint16_t DEFAULT_MTU = 1500; |
808 |
static const uint16_t ETHERNET_OVERHEAD = 18; |
|
|
809 |
|
810 |
/** |
811 |
* The frame size/packet size. This corresponds to the maximum |
812 |
* number of bytes that can be transmitted as a packet without framing. |
813 |
* This corresponds to the 1518 byte packet size often seen on Ethernet. |
814 |
*/ |
815 |
uint32_t m_frameSize; |
816 |
|
696 |
|
817 |
/** |
697 |
/** |
818 |
* The Maxmimum Transmission Unit. This corresponds to the maximum |
698 |
* The Maxmimum Transmission Unit. This corresponds to the maximum |