Brian
You're missing my point.
Yes, there are some silicon forwarders that can be
easily adapted to changes in the header fields --
assuming that those changes are within the range of
flexibility that was already placed in the silicon.
ASICs are less flexibile than FPGAs which are less
flexible than NP's. But all that is more or less
irrelevant.
The issue is the "format" of the flowid. I'd code things
up to classify on the full 20 bits of the flowid and
be done with it. That way, I will not have to go back
into the forwarder design, _regardless_ of the
environment. Any time we have to change code, it's
a bad thing -- bugs can creep in, unintended behaviors
can result, performance can suffer. Even if the silicon
is flexible, it has some "programming" and that programming
would have to change if I made it too aware of the internal
details of the field.
Frank Kastenholz
At 05:10 PM 8/24/01 -0500, Brian E Carpenter wrote:
>Frank,
>
>Not all network processors have the degree of inertia
>you describe. I know of at least one that can adapt to
>format changes without new silicon. But that aside,
>what I am talking about is multi-field classifiers in
>border routers, not what happens in core/trunk routers
>where you are completely correct - that is why the diffserv
>code point is 6 bits (sorry, we couldn't squeeze to 4).
>Multi-field classifiers don't need to be "slow path" but
>they aren't subject to quite the constraints you mention,
>in the diffserv architecture.
>
>This is the essence of why diffserv scales and intserv
>doesn't- you only need to do multi-field classification
>at the borders. Actually the format we are proposing
>simplifies MF classifiers because it takes away the need
>to look at port and protocol numbers.
>
> Brian
>
>"Kastenholz, Frank" wrote:
>>
>> All this talk about the format of the flow-id field
>> is rather interesting. But one thing has been missing --
>> input from someone who will actually _look_ at the
>> field, at very very very high speeds, in hardware,
>> and make forwarding decisions based on it.
>>
>> I am fairly confident in saying that there will not
>> be many sqmm of silicon devoted to determining
>> if the flow id is 'intserv-format' or 'diff-serv
>> format' or 'tennis-serv format'. The edit/compile
>> /debug loop of silicon is such that we can not
>> react soon enough to the next format that is
>> developed. This means that the flowid looker-
>> upper will be very very general. That means
>> that we don't care what the format is. We just
>> take the whole 20-bits and look 'em up (e.g.,
>> throw them all at a CAM, and see what comes out)
>>
>> The only thing that would make the looker-upper's
>> job easier is to know that the flow-id is going
>> going to be shorter than 20 bits (maybe via the
>> protocol specification, maybe via some software
>> magic ala MPLS label negotiations). A looker-upper
>> that is limited to 4 bits is a different beast
>> than a looker-upper that does 20.
>>
>> So, you folks can argue all you want about the format
>> of the flow-id and those format differences may matter
>> at some level in the software. But to the people who
>> are the actual customers of the bits -- the silicon
>> forwarders -- it just doesn't matter.
>>
>> Frank Kastenholz
>>
>> --------------------------------------------------------------------
>> 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]
--------------------------------------------------------------------
