Understood. This is all fine as long as the ASIC or network
processor can use a common solution for per-flow and
per-traffic-class classification - in that case it doesn't
care what the bits in the flow label are (although the
software that configures the tables that drive the classifier
might care).
Brian
"Kastenholz, Frank" wrote:
>
> 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]
--------------------------------------------------------------------
