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 [EMAIL PROTECTED] 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