mpls-linux-general

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

[James R. L. <jl...@mi...>]

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...

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

[Olivier D. <Oli...@rd...>]

Hi Jim,

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?
> 


We intend (and start some advanced test in a couple of week) to use MPLS 
+ TC for providing QoS support under MPLS not only DiffServ. So, we want 
to setup an LSP for a specific flow (using iptable for classification) 
and then affect a certian QoS to this flow (using TC). The next step is 
to manage all the LSP with a per-LSP queuing (using WFQ for example).

I'have allready completed a new version of our iptable+tc patch for LSR 
handle but, not yet tested (I'm waiting for new material to increase our 
test network). The two main improvment of this patch is :

- Modify tc mpls filter to hanlde both mpls_index (when setting 
CONFIG_MPLS_INGRESS_POLICING in the kernel config) and directly the 
packet label (when CONFIG_MPLS_INGRESS_POLICING is not set).

- Compute skbuff->mpls_index value with outgoing label for all incoming 
mpls packet inside an LSR node. (not sure where to put this patch)

With this two improvments, LSR can use TC to provide some per-LSP QoS. 
Iptable is not need because packet are allready labelled.

Starting to this, i thing implement CR-LDP and RSVP-TE with true Bandwidth

allocation is simplier. All the traffic management is handle by the kernel.



> 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 :-)


Thank's


> 


> PPS Please Steven respond and explain how you made your DiffServ stuff work
> 
> 

Olivier
-- 
  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

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

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

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.

*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


*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

[Olivier D. <Oli...@rd...>]

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

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

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

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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

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

[James R. L. <jl...@mi...>]

On Wed, Nov 28, 2001 at 11:56:08PM +0100, Steven Van den Berghe wrote:
> On Wed, 2001-11-28 at 22:44, James R. Leu wrote:
> > On Wed, Nov 28, 2001 at 07:34:26PM +0100, Steven Van den Berghe wrote:
> > > Hi Olivier,
> > > 
> > > good point :) seems i overlooked that one. 
> > 
> > <snip>
> > 
> > > 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. 
> > 
> > This is they way I think it can work, this is assuming I know how traffic
> > sheduling and filter works with TC and iptables :-\
> > 
> > Ingress:
> > 
> > With iptables you setup filters that mark tc_index on IP traffic that matches
> > the filters.  
> 
> Actually, AFAIK, iptables can't set tc_index ... (hope i haven't
> overlooked anything this time :), but it can set the dscp value, anyway
> it is a small extension to Olivier's patch to add extra info to SKB. 

As long as iptables can modify something that is understood by mpls_output()
this scheme should work.

Olivier, what role does iptable play in your scheme?

> > The traffic is then directed to the MPLS layer ny either a
> > route entry which has outgoing label info assocaited with it or via a MPLS
> > tunnel.  
> 
> or routing entry + mpls_index marked

is this in the case of ingress policing?  Can't ingress policing
mark the tc_index?

> > Either way the packet (now in SKB form and marked with a tc_index)
> > makes it way to mpls_output().  The instruction assocaited with the outgoing
> > label info can look at 2 things at this point, either the dsmark (in the IP
> > packet) or at the tc_index on the SKB.Either of these can be used to set a
> > EXP value, remark tc_index, forward on to differntard outgoing label info.
> > At the end of mpls_output() dev_queue_xmit() is called and if a scheduler
> > is attached to the outgoing interface, it can be setup to classify based
> > on tc_index.
> > 
> OK, sounds cool
> 
> > Transit:
> > 
> > Packets coming in off of a specific LSP or with a specific EXP can be used
> > to set a tc_index.  Again, if a scheduler is attached to the outgoing interface
> > it can be set to classify based on tc_index.
> > 
> > Egress:
> > 
> > Packets comeing off of a specific LSP or with a specifi EXP can be used to
> > set a dsmark or tc_index.  Further scheduling proceeds as normal.
> > 
> > This is probably a bit basic and glosses over some detail, but does it
> > sound like it will work (especially setting up a sched to classify on
> > tc_index)?
> >
> I assume we got everything we need: from a diffserv point of view, the
> usage examples i can think of are:
>  (done: possible with proposal + iptables patch)
> 
>  -translate the DSCP value of an IP packet to an EXP value: done
>  -translate the DSCP value of an IP packet to a label: done
>  -translate ingress queueing result to label: done
>  -translate ingress queueing result to label+exp: ? 

done, as long as ingress policing can set the tc_index

>  -translate iptables result to label: done
>  -translate iptables result to label+exp: 

What are the possible results from iptables?

>  -set tc_index in sch_dsmark based on exp or label: done
> 
> in diffserv terms, this would provide support for flexible multifield
> marking (iptables), policing (through ingress qdisc--would however be
> nice to be able to do this somewhere after the iptables classification),
> already marked traffic (e.g. host-marked or LSP-ingress not diffserv
> ingress), E-LSPs and L-LSPs.
> 
> Am i right to say, that this means to configure a kind of conditional
> instructions on a outgoing label: like
> PUSH(...), DSCP2EXP(0x2e,0x4),DSCP2EXP(0x31,0x1), SET(...)

Close.  Normally you'll have one DSCP2EXP instruction which has the full
table of mappings for DSCP -> EXP.  There are some defaults which can be
used too.

So your DSCP2EXP will look something like DSCP2EXP(0x2e:0x4,0x31:0x1)

Jim
-- 
James R. Leu
jl...@mi...