Tony Li wrote:
|The code for reassembly isn't hard, it's allocating the buffers to |store the arrived fragments. That's nearly impossible in hardware.Patently nonsense. Packet reassembly in hardware is very much straightforward if one is willing to burn large buffers to do so. Imagine taking an implemention in C and simply converting it to Verilog. Not at all out of the question. In fact, a subset of this problem has been solved for a very long time. Remember ATM? Remember a SAR chip? That's reassembly of fixed size packet fragments.
I remember building ATM networks (not voluntarily) and that whole movement seemed to burn out when it was discovered that SAR chips couldn't keep up above OC-12 speeds -- and that was with easy fixed-size cells. I also remember months of my life around the same time eaten up by tuning a certain vendor's routers for optimum use of various-sized IP buffers so that they wouldn't drop packets even without reassembly being an issue.
Now, I'm not a hardware guy, but I'd like to see some assurance from those that are that things have changed enough that we can ask routers now and in the foreseeable future will be able to reassemble the 50% of packets that will be at the Ethernet MTU (whatever that may be) + LISP header size at line rate -- including for customers who have GE, 10GE, and (in a few years) 100GE uplinks to their ISP(s).
S -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg