Re: [mpls-linux-general] How do you want to use TC with MPLS?

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

Hi Olivier,

good point :) seems i overlooked that one. 

Actually i didn't have a good look at your patch before (until this
afternoon--CET) and only added the direct iptables approach last week,
without looking thoroughly at all the consequences (you know, the famous
way of testing it: 'it worked for ping so it'll work for everything').

Your patch would indeed be more adequate for the job.

i think however that it would be a great thing if we could bypass the
routing from netfilter, it would add mpls support in a way that is much
more isolated from the 'standard' kernel (i.e. just touches it at L2),
making it easier to follow the kernel developments. What are the exact
requirements, i assume fragmentation is the most important one (i also
assume destination checking and ip header integrity is done at the
egress, after popping the label).

Cheers,
Steven

PS: Jim, could you send a more detailed description of your current qos
approach? Might help to get some "usage examples" and corresponding
requirements from the list. 

On Wed, 2001-11-28 at 18:52, Olivier Dugeon wrote:
> Hi Steven,
> 
> Steven Van den Berghe wrote:
> 
> > Hi Jim,
> > 
> > First of all, the label/exp classification to a diffserv per hop behaviour must be
> > done in every node (not only the ingress).
> > Now, about our diffserv approach, what we currently (read as experimental) do is:
> > 
> > * ingress node
> >     netfilter ==refence to label/exp==> mpls_output ==fixed label/exp mapping to
> > tc_index ==> Queueing/scheduling
> > (sorry Jim, we're bypassing all your hard work on getting the labels attached to
> > routing entries and go direct from iptables classification to mpls_output)
> > The "direct iptables"-approach  has only been written last week, and is currently
> > under test.
> 
> 
> Just a point of clarification. Do you bypass the ip stack at ingress or 
> LSR node ? In the first case, how do you handle all the normal ip stuff 
> ie. ip header checking/integrity, destination adresse checking and the 
> fragmentation in case of the packet become to big after adding a label ?
> 
> We have envisage to bypass this part of ip stuff - going directly from 
> iptable to mpls_output (in a similar way the iptable mirror function 
> call directly ip_route_output_slow). We had let down this option because 
> of all the ip stack stuff included the fragmentation.
> 
> Regards,
> 
> Olivier
> 
> 
> > 
> > *core node
> >     mpls_input==> mpls_output ==fixed label/exp mapping to tc_index ==>
> > Queueing/scheduling
> > 
> > The mapping from label/exp to tc_index is done in sch_dsmark (a pseudo scheduler
> > that was originally used to set tc_index based on the dscp field in the
> > IP-header).
> > dsmark is however no requirement (you could use u32 classifiers, ....), but it
> > allows to have a uniform diffserv configuration for a combination of mpls and
> > 'normal' ip traffic.
> > 
> > Hope this helps,
> > Steven
> > 
> > "James R. Leu" wrote:
> > 
> > 
> >>Hello all,
> >>
> >>I'm working on testing some of the feature I've added recently, and I just
> >>realized I have no idea how anyone would use them.  So I'm asking all of you
> >>how do you want to use the features of TC with MPLS?  Are the feature provided
> >>by iptables more apt for being used with MPLS?
> >>
> >>One way I know people want to use TC and MPLS is with respect to
> >>DiffServ.   Using the DSCP to determine which LSP (L-LSP) or which EXP/LSP
> >>(E-LSP) a packet should be sent with, then mapping the LSP or EXP/LSP
> >>back to a DSCP at egress.  But what about the LSRs?  Don't they need to
> >>do special queuing?  How does TC accomplish special queing without MPLS?
> >>How should it work with MPLS?
> >>
> >>Thanks,
> >>Jim
> >>
> >>PS Yes Olivier, I'm now starting to catch up with you, soon I'll understand why
> >>your iptables work is so useful :-)
> >>
> >>PPS Please Steven respond and explain how you made your DiffServ stuff work
> >>
> >>--
> >>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
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> > Application has reported a 'Not My Fault' in module
> > KRNL.EXE in line 0200:103F
> > 
> > 
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> > 
> > 
> > 
> > 
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> > 
> > 
> 
> 
> -- 
>   FTR&D/DAC/CPN
>   Technopole Anticipa     | mailto:Oli...@fr...
>   2, Avenue Pierre Marzin | Phone:  +(33) 2 96 05 28 80
>   F-22307 LANNION         | Fax:    +(33) 2 96 05 18 52
> 
> 
-- 
--
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*