Re: [mpls-linux-general] How do you want to use TC with MPLS?
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
Re: [mpls-linux-general] How do you want to use TC with MPLS?
|
From: Steven V. d. B. <ste...@in...> - 2001-11-28 18:33:45
|
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 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* |
