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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

OK, it seems it's time for a change in terminology: when i say bypass
IPv4 routing, i mean it in an engineering way, not a conceptional way.
The basic scheme we want from a linux ingress box is:

+------------------+   +----------+   +--------------+
|MF Classification +-->+Forwarding+-->+get ip nexthop|
|Policing/Shaping  |   |selection ++  +------------+-+  
+------------------+   +----------+ \               \
(MF=multifield)        (MPLS or ip)  \  +----------+ \   +--+
                                      +>+push label+--+->+TC|
                                        +----------+     +--+
     (1)                                   (2)            (3)

e.g. 1 classification in phase (1), to be used wherever needed. Now what
i would like (personal opinion) is to have to go through only one of the
two phases in (2). So i don't want to harm the hybrid mpls/ip approach,
i just want to limit the amount of processing and interference with the
IP path.

Now, about TC:In the core, normally (1) is absent, since no complex
multi-field classifications are needed, just a dscp lookup, which can be
done in (3). 

cheers,
Steven

PS: anybody feels like hacking together an ascii-art drawing plugin for
mailclients. Would be a great help :)

On Fri, 2001-11-30 at 04:32, James R. Leu wrote:
> I want to make sure I've got your opinion correct:
> 
> On an ingress LER your think iptables -> nfmark is sufficient.
> On a transit LSR and egress LER tc_index is needed (to augment dsmask and
> scheduling).
> 
> In addition you would like the option of using iptables to do all
> marking/classifing AND bypass normal routing lookups, but it may be possible
> to use the existing mechanisms (aux_proto on a FIB entry or a MPLS tunnel
> interface) to achive the same functionality, but not necessarily the same
> level of efficiency.
> 
> Jim
> 
> On Thu, Nov 29, 2001 at 08:50:56AM +0100, Steven Van den Berghe wrote:
> > 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
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> > 
> > 
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> 
> -- 
> James R. Leu
> jl...@mi...
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> 
> 
-- 
--
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*