Re: [LARTC] forwarding in tcng

[Johan Cimen <c99jcn@cs.umu.se>]

On Fri, 5 Dec 2003, Martin A. Brown wrote:

Hi Martin.

> Johan,
>  : I have read the tcng reference manual and cannot find information about
>  : forwarding. Is it possible to farward packets from ingress to egress
>  : without sending them upwards in layers?
>  :
>  : NIC---->ingress---->forward----->egress---->
>
> The reason you find no information about forwarding in the tcng manual, is
> that forwarding doesn't happen in the traffic control layer of the Linux
> IP stack.

I realised this after I had done some research on forwarding on the
Internet. :)  Thanks!!

> As far as I know, there's no way to prevent a packet from being
> passed up to the kernel bridge or routing code.  So, since you are
> probably using this machine as a router, you'll want to take a look at the
> KPTD at Stef's site [0].

Actually Im going to build a testplatform, where Im using a Wireless LAN,
BSS-topology with a central station (AP) to controll downlink. Dependent
on link quality, the AP is going to give access to the radio interface.
Stations are using a network card driver that includes the link quality
into the ttl_field. The ttl_field was availabla :)
At ingress I want to filter packets that are giving information about the
link quality. Value 0x81 is indicating that information about the link
quality is available.

>
> Makes sense.
>
>  : dev eth1 {
>  : 	$P = bucket(rate 1Mbps, burst 2kB, mpu 64B);
>  : 	ingress {
>  :     		class (<>)
>  : 			if ((ip_ttl & 0x81) = 0x81) &&
>  : 			(conform $p && count $P);
>
> Did you really mean to "confirm $p && count $P"?  I'd think that was meant
> to be "conform $P && count $P".

It was ment to be "conform $P && count $P".

>  : 	egress {
>  : 		class (<$high>) if (((ip_ttl & 0x1E) >> 1) <= 0x0F) &&
>  : 			(((ip_ttl & 0x1E) >> 1) >= 0x0C);
>
> Neat bit math (here and above).  I'm going to stick this one in my bag of
> tricks.

Thanks :)

>
> [ snip ]
>
>  : If forwarding is not possible can I use hash table with tcindex to store
>  : information at ingress, and use this information at egress?
>
> I'm not completely certain what your intent is with this hash table, but I
> think the answer to your general question is yes.  One of the points of
> tcindex is that you don't need to run through the same sets of tests on
> ingress and egress; tcindex is designed to be reusable packet metadata
> during a packet's lifetime on a given host.  You may find that Leonardo
> Balliache's DiffServ pages can help you with the Linux DiffServ
> architecture, in particular, tcindex [1].

I need a table with information of available stations and their link
quality for tests, where I am going to generate packets from AP to
stations with good quality. I think I have to use tcindex.

>
> If this is not helpful, try the LARTC HOWTO [2] on DSMARK (and tcindex),
> and then try a few of Werner's papers [3].
>
> Failing all of that, you might try asking this list again, or checking out
> the (fairly inactive) Linux-DiffServ mailing list [4].
>
> -Martin
>
>  [0] http://www.docum.org/stef.coene/qos/kptd/
>  [1] http://opalsoft.net/qos/DS.htm
>      http://opalsoft.net/qos/DS-210.htm
>  [2] http://lartc.org/howto/lartc.adv-qdisc.dsmark.html
>  [3] http://www.almesberger.net/cv/papers.html
>      http://www.almesberger.net/cv/papers/dsid-01.ps.gz

They have done a great job.

>  [4] http://diffserv.sourceforge.net/#list
>

Thank you Martin for this information.

/Johan Cimen
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/