Ethernet over USB framing
A general discussion of framing issues when transporting Ethernet frames over USB
Contents |
Background
USB has various speed variations and various transfer types, yielding maximum packet sizes ranging from 64 to 1024 bytes.
Ethernet frames, on the other hand, can be between 64 and 1518 bytes (more if using VLAN tagging), not including Jumbo frames (up to 9000 bytes).
The maximum data transfer rate for High-Speed USB (480Mbps) is using Bulk transfers which allow up to 512 bytes per USB transaction in High-Speed mode. For Full-Speed USB (12Mbps), the maximum Bulk transfer packet size is 64 bytes.
Therefore, any given Ethernet frame transported across High-Speed USB using Bulk transfers could utilise between 1 and 3 USB packets. Conversely, there could be up to eight minimum-sized Ethernet frames in a single 512 bytes High-Speed USB Bulk packet (if frame-stuffing is supported by the Ethernet-over-USB driver).
The main issue is how to determine when an Ethernet frame transferred over USB has ended, so that it can be further processed.
Furthermore, High-Speed USB packets will often be shoved into a FIFO at the device end. Individual USB packet boundaries may be preserved, but they may lose some resolution, eg. unable to differentiate between an odd length packet and the next-larger even length packet if the FIFO output is 16-bits wide.
Clearly, a robust framing mechanism needs to be employed.
Note that the USB Implementors Forum have defined a number of standards for implementing network protocols over USB, including the most recent Network Control Model (NCM) ([http://gnosia.anu.edu.au/ReferenceDocs/USB.org/ncm10.pdf local copy). NCM allows multiple Ethernet frames to be packed into a single BULK transfer.
Framing Mechanisms
In general, framing techniques can be divided into three groups:
- use of a special reserved "start-of-frame" token, which must then be "escaped" out of the data path
- use of a frame-length prefix
- use of time-outs
Start-of-Frame Token
This is similar to the special Flag byte used by HDLC and derivatives including PPP etc.
The main disadvantage is the need to stream process the data to look for SoF tokens in the data stream, and "escape" them using character stuffing.
However, we do know that the USB packets have end-of-packet signalling. If we assume at most one Ethernet frame per USB packet, then we have some of the framing already in place. How to detect the actual end of frame?
Zero Length Packets
ZLPs are allowed in the USB 2.0 standard and above. A ZLP can be sent at the end of each Ethernet frame.
This mechanism suffers from two disadvantages. If the received BULK data is placed directly into a FIFO, the ZLPs may not be correctly signalled by the FIFO logic (is the FIFO empty or not if a ZLP arrives?). Also, transferring the ZLP over the USB takes some overhead.
Continuous CRC
Using this mechanism, the CRC is continuously calculated for incoming (USB OUT) packets. Combined with
If a 16-bit interface is in the way, this can be done for both odd and even boundaries. If ever either is valid at the end of a FIFO transfer (512 bytes/256 words, or partial), then there is a good chance that this is the end of the frame. Using a 32bit CRC, there is a statistically small chance that random data may end up as a valid CRC on 512 byte boundaries. Can we model this?
Frame-Length Prefix
This is generally the most robust mechanism, but does require foreknowledge of the length of the frame before anything can be sent. Also, if the receiving end gets out of sync, then incorrect frame-lengths will be apparent, so there needs to be a way to perform some sanity checking and recovery in case of protocol failure.
Prepend 2-byte size
This is an extension of the NetFPGA Padded Switch project from the NetFPGA 2012 Summer Camp in which the various inputs to the switch add 2 bytes to each frame to re-align all the data fields to better align with the 8-byte wide pipeline.
Here, instead of padding the Ethernet frame as it arrives at the NetFPGA 1G, we add a two-byte length field to the start of the frame at the USB Host in the Kernel driver. When the frame arrives at the NetFPGA, the two bytes are used to determine the frame length and are passed through the NetFPGA infrastructure as padding, but do not participate in CRC validation, etc.
Overwrite part of source MAC address
The 6-byte Ethernet frame source MAC address is pretty much constant for any given interface, but is transported across the Host-to-NetFPGA transport anyway.
We could overwrite the most significant 2 bytes of the source MAC address, which the NetFPGA code can then remove and replace with the constant 2 bytes in use as the frame is received.
For outgoing frames (NetFPGA to Host), we overwrite the destination MAC address, being careful to preserve any data regarding possible broadcast or multicast destination addresses.
Use of Time-Outs
Time-outs can be accurately used to delimit packets. Alas, they negatively impact on performance as no data can be transferred during each timeout period. Also, for some hardware implementations, they may be harder to detect.
