Please note that at lower line speeds, you may find silicon QoS engines,
which for lowering the costs, have implementations of classifiers
without using CAMs. The MF classification is still in the fast path, and
of course is still critical.
Alex
Thomas Eklund wrote:
>
> Brian,
> This is the key since many that do network processors are in fact fixed
> function ASICs (or configurale state machine approaches) and those are not
> programmable they are only configurable.
>
> Count us in as the second you know.
>
> And in fact most of the network processors have MF classifiers in the fast
> path (forwarding plane). The limiting factor is of course the speed of the
> CAM's.
>
> -- thomas
>
> -----Original Message-----
> From: Brian E Carpenter
> To: Kastenholz, Frank
> Cc: [EMAIL PROTECTED]
> Sent: 2001-08-25 00:10
> Subject: Re: Higher level question about flow label
>
> 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]
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
S/MIME Cryptographic Signature
