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