I agree alex.
It gets worse for people that are doing ASIC which is not programmable, then
they need to spin a new version their ASIC when the protocols changes. For
people that are doing programmable ASIC (network processors etc) this is not
a problem.
But common for both approaches is that the header format is really challenge
for the ASIC engineers
-- thomas
>-----Original Message-----
>From: Alex Conta [mailto:[EMAIL PROTECTED]]
>Sent: den 20 augusti 2001 22:15
>To: Thomas Narten
>Cc: Brian E Carpenter; Bob Hinden; ipng
>Subject: Re: Higher level question about flow label
>
>
>
>
>Thomas Narten wrote:
>>
>> [...] When someone can make a compelling argument for why
>> the bits need to be defined in a certain way (i.e., there is a real
>> application for which using the bits provides significant benefits,
>> and those benefits do not appear achievable through other means) that
>> is the time to define the bits. What I do sense with many of the
>> recent discussions surrounding the Flow Label is that there are many
>> folks (i.e., folks putting IPv6 into hardware) that want to know what
>> they should implement w.r.t. the Flow Label. While it would
>be nice to
>> be able tell them what to do, we shouldn't standardize something just
>> for the sake of having a definition.
>>
>> Thomas
>
>10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2
>instructions of a hypothetical
>1Ghz processor which can execute one instruction per cycle. That's a
>hell of a requirement.
>
>As consumers, we all enjoy the very cost-effective availability of
>100Mb/sec line speed packet processing in almost every
>Notebook, or PC.
>
>IP and QoS Engines implemented in silicon, on a chip or a few chips, by
>IBM, INTEL, and many, many others, is one of the reasons of the low
>costs, along with the ability to optimizing the hardware
>in so many more and different ways than the software (for instance
>parallel header, or parallel header field processing).
>
>1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just
>around the
>corner, with 40Gb/sec following not long after.
>
>With such drastic "timing" requirements, implementing engines in
>silicon, and inventing *clever* mechanisms to handle the sequential
>processing of headers alone, will not be sufficient to implement very
>cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a
>disadvantage relative to IPv4.
>
>We need all the help we can get from the protocol, that is headers, and
>their fields, for forwarding and QoS processing, and by that I
>mean both
>Intserv, and Diffserv.
>
>Regards,
>Alex
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> --------------------------------------------------------------------
>> IETF IPng Working Group Mailing List
>> IPng Home Page: http://playground.sun.com/ipng
>> FTP archive: ftp://playground.sun.com/pub/ipng
>> Direct all administrative requests to [EMAIL PROTECTED]
>> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
