Subject: RE: Higher level question about flow label

From: Thomas Eklund <[email-masked]>
Date: Sat, 25 Aug 2001 00:56:19 +0200

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-masked]
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-masked]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Alex Conta <[email-masked]>
Date: Mon, 27 Aug 2001 15:23:58 -0400

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