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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
