Re: [mpls-linux-general] Better to use nfmark vs tc_index?

[Steven V. d. B. <ste...@in...>]

On Thu, 2001-11-29 at 05:20, James R. Leu wrote:
> After looking at iptable a bit more I see that it can set a nfmark via
> the MARK rule.  Should I use this as oppsed to tc_index to influence the
> LSP and EXP? (note that DSCP will still be an options)
Would be a clean choice (note: you'll still need part of Olivier's patch
to implement a FEC like behavior per iptables result). 
> 
> I think I now understand what Olivier did, he created something similar
> to MARK but for MPLS.  If we are going to continue to use that I would
> like to change it alittle.  Instead of storing the mpls_index, I think it
> should build a dst and store it with the rule.  This dst will direct the
> skb to mpls_output() and will have the outgoung label info attached.
> When it gets to mpls_output() MPLS processing will occur like normal.
> The dst will be slapped on to any packet that matches the rule.
Iptables has hooks in several places along the forwarding path: before,
in or after the "routing". Is there no possibility that dev will be
overwritten by the ip-code? I still feel, we should be able to bypass
routing completely (i'm searching what can be done to handle
fragmentation etc.)
> 
> Do you think that by using nfmark we can accomplish the same thing?
> We would have to relay upon another mean of getting data to mpls_output()
> like a MPLS tunnel interface or a entry in the FIB that has been marked
> for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> the LSP or EXP.
> 
first guess (warning: statistically proven it's mostly wrong): possible
approach.

> Ofcourse maybe it's just safer to have both options availble :-)
> 
> Now to the matter of tc_index.  It seems that nfmark can be used by a
> scheduling classifier, but it looks like the classifier for tc_index is
> better.  So it might be that nfmark (or a MPLS mark) is used to influence
> LSP and EXP descisions (note that DSCP will still be option) and that
> tc_index is used to influence scheduling.
> 
tc_index is indeed no "must". There are other solutions possible to get
the same effect, especially in the ingress (in the core, we don't want
to use iptables for anything). The only thing from the original diffserv
for ip the sch_dsmark  + tc_index combination offers you is:

 1 you can read the (ip) dscp and put it in tc_index (enqueue operation)
 2 you can classify based on tc_index
 3 you can modify the value of tc_index during the traffic control
 4 you can re-write the dscp based on tc_index in the ip-header when
exiting sch_dsmark (dequeue operation) 

1 and 2 can be done using iptables and fw_mark classifier
3 and 4 need more study. At first sight, i'd say we can do this either
in ingress policing or add it to iptables (configuration would be
something like: if offered load <1Mbps set fwmark 2, if offered load
<2Mbps set fwmark 1, else set fwmark 0).

just a personal opinion: i would keep the sch_dsmark approach in LSR and
egress, but for ingress (where the more complex TC functions should be
performed, to achieve scaleability), forgetting about sch_dsmark and
tc_index would be just fine.


 Does that make any sense?  It's late.  I'm going to sleep and think about
> it some more.
>
why, i've just woken up :)
 

cheers,
Steven
-- 
--
Steven Van den Berghe
ste...@in...
Workgroup Broadband Communication Networks
Department Information Technology
Ghent University - Belgium
Phone:  +32 (0)9 267 35 86 | Fax  :  +32 (0)9 267 35 99
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
DiffServ over MPLS for Linux: http://dsmpls.atlantis.rug.ac.be
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
A computer is like an Old Testament god, with a lot of
rules and no mercy. - Joseph Campbell
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*