Frame Processing and the preamble

[lmqtechnology]

When looking at Fragment Free frame processing within a switch it says that the first 64-bytes have to be received before the frame is forwarded, but it is not clear as to whether this 64 bytes includes the preamble?

[Peter Paluch · Accepted solution]

Hi,

No, the preamble is not included in the 64 byte limit. The idea of the Fragment Free operation is to make sure that the frame we are processing is not a collision fragment by waiting for its minimal valid size which is indeed 64 bytes of useful data (Dst MAC (6B), Src MAC (6B), Type (2B), Payload (46B), FCS (4B)). If any collision occurred, it would have happened sooner as that was the requirement on the Ethernet operation, so the received frame would be, among other symptoms, shorter than 64B. On the other hand, a valid Ethernet frame is not allowed to be shorter than 64B of useful data, so the length itself becomes an indicator of whether a collision could have happened. The preamble is not counted into this byte count.

Best regards,
Peter

[lmqtechnology]

Thats great, thanks for the quick response.. one other QQ though.. FF Processing was designed to solve the late collision issue.. but I cant see how it does it?

[Peter Paluch]

Hi,

That is most probably a misunderstanding. The Fragment Free switching method was not invented to prevent late collisions, and as you have correctly stated, it has no impact on whether a late collision occurs. Fragment Free merely prevents a switch from forwarding "shreds" of frames that were the result of a collision, yet still have readable Dst MAC fields. Such frame fragments are entirely useless, yet the other rapid switching method, the Fast Forward, would forward them as it was perfectly happy with receiving the first 6B of a frame (the Dst MAC field).

Late collisions are collisions that occur after 64 or more bytes of a frame have already been sent. In a well-constructed network, late collisions should never happen. The occurrence of a late collision always indicates a serious hardware problem - overly long cabling, noise on the cabling, using too many repeaters or hubs between two hosts, having a faulty network card or a network component. The particular behavior of a switch - whether it forwards a frame sooner or later after it started arriving to the switch - has no impact on these factors.

Best regards,
Peter

[lmqtechnology]

Thank you very much

[lmqtechnology]

so FF processing processes the first 50 bytes of data correct? (assuming there is 50 bytes of data to process)

[Peter Paluch]

Hi,

Yes, or, in other words, the Fragment Free waits for 50 bytes worth of data to accumulate after the DstMAC+SrcMAC+Type have arrived.

However, it is better to define it simply as 64 bytes of data including the frame header (the preamble is not a part of the frame header). The reason is that there are different frame formats (802.2 LLC, 802 SNAP) in which the fields following the SrcMAC are defined differently but to the Fragment Free, this does not make a difference. Starting with the first byte of the DstMAC, Fragment Free will wait for 64 bytes to come in, and then it will start forwarding the frame, not sooner.

Best regards,
Peter

[lmqtechnology]

so I guess technically if the payload of the frame was only 46 bytes FF processing would actually receive the entire frame?  IF this is true I would assume that FF still does not check the CRC?

[Peter Paluch · Accepted solution]

Hi,

technically if the payload of the frame was only 46 bytes FF processing would actually receive the entire frame?

Yes, that is so.

IF this is true I would assume that FF still does not check the CRC?

To my best knowledge, it would not check the CRC. Note that this particular length (46 bytes in the payload portion; 64 bytes in total including the header and CRC) is the only one out of many allowable lengths of a valid frame (64 - 1518 bytes) that would allow the switch to check the CRC. It would not be worth the effort.

Best regards,
Peter