mpls-linux-general — Mailing list for general discussion about MPLS for Linux

[mpls-linux-general] restricted amount of labels

[Kauder T. <Tho...@ic...>]

Hi Everyone,
I managed to get the LDP (linux-port) working and found out that one 
has to be very carefull using it.
A single wrong input sometimes causes a segmentation-fault.

Here's the scenario I established:

     dummy0 --------- eth0   eth0 ------- eth1   eth0 --------- dummy0
      <-----| LER 1 |-------------| LSR  |------------| LER 2 |---->   
20.0.0.0/24 --------- 10.0.0.0/24 ------- 11.0.0.0/24 --------- 20.0.0.0/24

I have zebra running on all machines and propagate virtual routes pointing out the dummy devices using OSPF.
After the Routing-tables are correct on all mashines by typing:

	./ldp_linux

after hitting enter twice the prompt appears.

On LSR:

I add a global object at the LSR with the LSR-ID 10

	add global 10

then enable LDP on both interfaces

	add interface eth0
	add interface eth1

On LER1:

	add global 2
 	add interface eth0
 
On LER2:

	add global 3
	add interface eth1

I found out that this order is the safest.
What happens now is that they really exchange labels wich is fine!! but I still have some problems:
- If I change the routing table while LDP is running the label-mapping stays unchanged. ( if I got you right. with ldp_zebra this should work )
- you're adding interfaces by their names but delete them by ID. deleting with the name as argument causes a crash quite often.
- according to /proc/net/mpls-in a forward on LSR is only assigned to the routes pointing to the LER who was activated first ( here LER1 ). 
	 in other words the mappings aren't updated if a new LDP-Router is added.
That's all not so important for my purposes. It works somehow.....

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The thing I could really use is support for lots of label-mappings. Right now, after a bit more than a hundred label-mappings there 
appears one partial labelmapping (only FEC and label no op-code..) Then nothing.
This occurs not only when using LDP but also when mapping the labels using the mplsadm tool. So I guess this is rather a mpls 
than a ldp problem. I really need at least 1000 labels for test-purposes.
Would that be possible or is there a lack of memory somewhere ???
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

greetings
Thorsten

[mpls-linux-general] =?gb2312?B?16q3ojogbXBscy1saW51eC1nZW5lcmFsIC0tIGNvbmZpcm1hdGlv?= =?gb2312?B?biBvZiBzdWJzY3JpcHRpb24gLS0gcmVxdWVzdCAyMDg2MTM=?=

[Wei Zhang(S. Development) <zha...@as...>]

-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: mpl...@li...
[mailto:mpl...@li...]=B4=FA=B1=ED
mpl...@li...
=B7=A2=CB=CD=CA=B1=BC=E4: 2001=C4=EA12=D4=C27=C8=D5 16:34
=CA=D5=BC=FE=C8=CB: Wei Zhang(Solution Development)
=D6=F7=CC=E2: mpls-linux-general -- confirmation of subscription -- =
request
208613


mpls-linux-general -- confirmation of subscription -- request 208613

We have received a request from 211.100.11.8 for subscription of your
email address, <zha...@as...>, to the
mpl...@li... mailing list.  To confirm the
request, please send a message to
mpl...@li..., and either:

- maintain the subject line as is (the reply's additional "Re:" is
ok),

- or include the following line - and only the following line - in the
message body:=20

confirm 208613

(Simply sending a 'reply' to this message should work from most email
interfaces, since that usually leaves the subject line in the right
form.)

If you do not wish to subscribe to this list, please simply disregard
this message.  Send questions to
mpl...@li....

Re: [mpls-linux-general] help for MPLS-LINUX install

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

On Thu, Dec 06, 2001 at 11:52:44AM -0800, sandra zeng wrote:
> hi, folks,
> 
> is there anyone who recently installed that
> mpls-linux-1.0 patch from gmpls.org website?
> 
> i followed everything in the QUICK.START file,
> however, my knew kernel even did not boot properly.
> 
> my working environment is Redhat 7.1 with kernel
> 2.4.2-2. i downloaded kernel 2.4.7 and mpls-linux-1.0
> from the website later on.

get the 2.4.13 kernel source.

cd /usr/src/
mv linux linux.old
ncftpget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.13.tar.bz2
tar -Ixf linux-2.4.13.tar.bz2
mv linux linux-2.4.13
ln -s linux-2.4.13 linux
cd /usr/include/
mv linux linux.old
mv asm asm.old
ln -s /usr/src/linux/include/linux
ln -s /usr/src/linux/include/asm


> two things that bothered me a lot was the relationship
> between "make bzImage" and "make bzlilo", and the
> "initrd" line in lilo.conf(i didnot have this line
> even in my old working kernel). i searched around the
> Web and could not get the whole picture...

Use 'make install' to compile the kernel.

> anyway, it would be very nice if someone could share
> his/her practical installation process with me. Thanks
> a lot!!!
> 
> all the best,
> Lily
> 
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

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

[mpls-linux-general] help for MPLS-LINUX install

[sandra z. <lil...@ya...>]

hi, folks,

is there anyone who recently installed that
mpls-linux-1.0 patch from gmpls.org website?

i followed everything in the QUICK.START file,
however, my knew kernel even did not boot properly.

my working environment is Redhat 7.1 with kernel
2.4.2-2. i downloaded kernel 2.4.7 and mpls-linux-1.0
from the website later on.

two things that bothered me a lot was the relationship
between "make bzImage" and "make bzlilo", and the
"initrd" line in lilo.conf(i didnot have this line
even in my old working kernel). i searched around the
Web and could not get the whole picture...

anyway, it would be very nice if someone could share
his/her practical installation process with me. Thanks
a lot!!!

all the best,
Lily

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

[mpls-linux-general] Looking for examples to test TC/DS/IPTABLE

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

Hello,

I have (re)implemented my version of TC/DS enhanced mpls-linux. I would
like to describe what I have created so I can get feed back.  Also
I would like to get examples from people of how to use TC and iptables
to actually excercise this new code and to show me what this implementation
cannot do.

First this to keep in mind is that 'outgoing info' nolonger can be interpreted
as 'outgoing label'.  A particular 'outgoing info' can fwd on to another
'outgoing info' which may do a 'push'.  'incoming labels', aux_proto, and
mpls tunnels all point to 'outgoing info' (in addition 'outgoing info' can
point to other 'outgoing info').  I will refer to 'outgoing info' as
'MOI' (in the code it stands for the mpls_outgoing_info structure).

Incoming labels and MOI's have an array of 'instructions' associated
with them.  Each instruction has a 'data block' associated with it.
The original set of instructions, have changed very little:

MPLS_OP_POP	-> IN: pop off top label (no data)
MPLS_OP_PEEK	-> IN: make the top label the active 'incoming label' (no data)
MPLS_OP_PUSH	-> OUT: push a label on to the top of the label stack
		   (label to push)
MPLS_OP_DLV	-> IN: deliver the packet to a specify protocol handler
		   (protocol id to send the packet to ie IPv4 IPv6)
MPLS_OP_FWD	-> IN: transfer control to mpls_output() (pointer to the MOI)
		   OUT: start processing the instructions wit the new MOI
			(pointer to the new MOI)
MPLS_OP_SET	-> IN: set the incoing interface
		   OUT: set the dst_entry on the skb [last step before TXing a
		   MPLS packet] (pointer to the dst_entry)

These are the new instructions:

*nfmark comes from skb
#dsmark comes from IP header
*tc_index comes from the skb
*EXP comes from the active incoming label

MPLS_OP_NF_FWD	-> IN/OUT: index into the datablock by using the (nfmark & mask)
		   start processing the MOI that was found. (array of MOIs)
MPLS_OP_DS_FWD	-> IN: index into the datablock by using the (dsmark & mask)
		   start processing the MOI that was found. (array of MOIs)
MPLS_OP_TC_FWD	-> OUT: index into the datablock by using the (tc_index & mask)
		   start processing the MOI that was found. (array of MOIs)
MPLS_OP_EXP_FWD	-> IN: index into the datablock by using the (EXP)
		   start processing the MOI that was found. (array of MOIs)
MPLS_OP_SET_TC	-> IN/OUT: set the tc_index (tc_index to use)
MPLS_OP_SET_DS	-> IN/OUT: set the dsmark (DSCP to use)
MPLS_OP_SET_EXP	-> IN/OUT: set EXP on the top label (EXP to use)
MPLS_OP_EXP2TC	-> IN: index into the data block by using the (EXP) and set the
		   tc_index to the value found
MPLS_OP_EXP2DS	-> IN: index into the data block by using the (EXP) and set the
		   dsmark to the value found



So here are some examples:

Egress LER:

On input of label 100 EXP 1 gets DSCP 0x4, EXP 4 gets DSCP 0x7

MII(100) -> PEEK POP EXP2DS(1->0x4,4->0x7) DLV(IPv4)

Ingress LER (DSCP):

Packets going to 11.0.0.0/16 goes out with label 100, DSCP 0x4 get EXP 1,
    DSCP 0x7 gets EXP 4

IPROUTE(11.0.0.0/16) -> MOI(1000)
    MOI(1000) DS_FWD(0x4->MOI(500), 0x7->MOI(2000))
	MOI(500) SET_EXP (1) PUSH(100) SET(next hop info)
	MOI(2000) SET_EXP (4) PUSH(100) SET(next hop info)

IP routing tranfer control to mpls_output and starts processing MOI(1000).
MOI(1000) looks at the DSCP and starts processing either MOI(500) or
MOI(2000).  MOI(500) and MOI(2000) set the EXP, puch the label,
set the dst_entry and then send the packet)

(you could implement L-LSPs in a similar way, push differnt label in MOI(500)
and MOI(2000) and do not set the EXP value)

Alternative:

IPROUTE(11.0.0.0/16) -> MPLS_TUNNEL(mpls0)
    mpls0 -> MOI(1000)
	MOI(500) SET_EXP (1) PUSH(100) SET(next hop info)
	MOI(2000) SET_EXP (4) PUSH(100) SET(next hop info)

IP routing tranfer send the packet out interface mpls0.  Interface mpls0
transfers control to mpls_output and starts processing MOI(1000).
MOI(1000) looks at the DSCP and starts processing either MOI(500) or
MOI(2000).  MOI(500) and MOI(2000) set the EXP, puch the label,
set the dst_entry and then send the packet)

Ingress LER NFMARK and TCINDEX, work simlarly.

Transit:

INCOMING_LABEL(100) PEEK POP EXP2TC(1->0xF,4->0xE) -> MOI(10000)
    MOI(10000) PUSH(100) SET(next hop info)

Incoming label 100 looks at the EXP bits and sets tc_index to 0xF when
EXP is 1 and to 0xE when EXP is 4.  MOI(10000) is responsible for
trasmitting the label.  It pushed on label 100 (and the same EXP bits)
and send it on it way.  As it leaved via the physical interface a packet
scheduler can look at the tc_index and schedule it appropriately.

If you want to translate the EXP then you could use an EXP forward
to differnt MOIs that push on the same label, but set differnt EXP bits.

Additional intructions?

MPLS_OP_TC2EXP	-> coule be use in a MOI to translate the tc_index set on
		   input to differnt EXP values.  This would avoid having
		   to do a EXP FWD just to set differnt EXP values.

MPLS_OP_DS2EXP	-> same as above, but would look at DSCP in the IP header
		   and could only be execute on packet that came directly
		   from the IP layer.  It would avoid having to have
		   seperate MOIs to implement E-LSPs.

Comments, questions, political statments?

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

Re: [mpls-linux-general] sniffing mpls-packets with ethereal

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

On Thu, Dec 06, 2001 at 09:23:17AM +0100, Kauder Thorsten wrote:
> Hi James,
> I guess you know that there's a problem sniifing mpls-packets if the machine 
> running ethereal is the destination of these packets. 
> I posted a message to the ethereal-user-mailinglist and that's what I've got as
> answer.
> 
> >Well, if you can get the Linux networking stack to send *raw Ethernet*
> >frames to PF_PACKET/SOCK_RAW sockets *AND*, if the Linux MPLS code
> >modifies those frames in place, get it to do a copy-on-write of the
> >frame, so that it doesn't damage the copy of the frame sent to the
> >PF_PACKET/SOCK_RAW socket, that might help.
> >
> >I don't know how one would do that, however.

Yes.  I know what they mean but I haven't had a chance to implement it.
I've seen some of the other networking stack use skb_cow() (copy on write).
It's a guess, but I think I need to do that after receiving the packet
in mpls_rcv().

> Maybe you can use that.

Thanks for the info,
Jim

> greetings 
> Thorsten
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

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

[mpls-linux-general] sniffing mpls-packets with ethereal

[Kauder T. <Tho...@ic...>]

Hi James,
I guess you know that there's a problem sniifing mpls-packets if the machine 
running ethereal is the destination of these packets. 
I posted a message to the ethereal-user-mailinglist and that's what I've got as
answer.

>Well, if you can get the Linux networking stack to send *raw Ethernet*
>frames to PF_PACKET/SOCK_RAW sockets *AND*, if the Linux MPLS code
>modifies those frames in place, get it to do a copy-on-write of the
>frame, so that it doesn't damage the copy of the frame sent to the
>PF_PACKET/SOCK_RAW socket, that might help.
>
>I don't know how one would do that, however.

Maybe you can use that.

greetings 
Thorsten

Re: [mpls-linux-general] X-Windows doesn't work after mpls-linux installed

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

Hmmmmm.....  interesting.

What kernel were you running previous to this?
If you can boot the old kernel, boot it up and start X.  Then do a lsmod
and send me the output.

Also send the .config from the new kernel.

Jim

On Wed, Dec 05, 2001 at 09:45:43AM -0500, Hanxi Zhang wrote:
> 
> Hi buddies:
> 
> I found the x-windows system doesn't work after I installed mpls-linux-0.993
> on my redhat linux box. When I try to start x-windows by running 'startx',
> it will freeze there and I have to power off the computer.
> 
> Has anybody experienced the same problem? I am quite sure the installation
> of mpls-linux-0.993 is the only thing I did before the x-windows went wrong,
> although I don't understand yet how these two can interference with each other.
> 
> Thank you very much.
> 
> 
> 
> ----------------------------------------------------------
> Hanxi Zhang
> Research Engineer
> Broadband and Optical Networks
> Communications Research Center
> 
> Tel: (613)991-2960 Fax: (613)990-8382
> 3701 Carling Ave, Ottawa, ON K2H 8S2
> ----------------------------------------------------------
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

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

[mpls-linux-general] X-Windows doesn't work after mpls-linux installed

[Hanxi Z. <han...@cr...>]

Hi buddies:

I found the x-windows system doesn't work after I installed mpls-linux-0.993
on my redhat linux box. When I try to start x-windows by running 'startx',
it will freeze there and I have to power off the computer.

Has anybody experienced the same problem? I am quite sure the installation
of mpls-linux-0.993 is the only thing I did before the x-windows went wrong,
although I don't understand yet how these two can interference with each other.

Thank you very much.



----------------------------------------------------------
Hanxi Zhang
Research Engineer
Broadband and Optical Networks
Communications Research Center

Tel: (613)991-2960 Fax: (613)990-8382
3701 Carling Ave, Ottawa, ON K2H 8S2
----------------------------------------------------------

[mpls-linux-general] Re: Asking for materials on netlink socket programming

[Manish K. <ka...@is...>]

Hanxi,


you should check out this introduction to netlink at:

http://qos.ittc.ku.edu/netlink/netlink.pdf   (dated: 1999)

manish


> FROM: Hanxi ZhangDATE: 11/26/2001 09:38:15SUBJECT:  [mpls-linux-general]
> Asking for materials on netlink socket programming 
> Hi All:
>
> Could any of you refer me to any good tutorials on netlink socket
> programming/
> ioctl call that are used in mplsadm? I went through mplsadm.c and
> netlink.c,
> but I don't totally understand how a AF_INET socket is related to a
> AF_NETLINK
> socket.
>
> Thanks a lot!
>
>
>
> ----------------------------------------------------------
> Hanxi Zhang
> Research Engineer
> Broadband and Optical Networking
> Communications Research Center
> 
> Tel: (613)991-2960 Fax: (613)990-8382
> 3701 Carling Ave, Ottawa, ON K2H 8S2
> ----------------------------------------------------------

[mpls-linux-general] How to interprete the buffer received from the netlink socket.

[Suryakant <s_...@ya...>]

Hi,
I am trying to read routing table on linux machine using netlink socket.

Can anybody please help me, how to interprete the buffer received
from the netlink socket.

The buffer containes data like this :
[Print format is <space> between two bytes and <\n> between to entries]

84    0    0    0   24    0    2    0  148   99    0   64   14    3
0    0    2   32    0    0  254    0    0    3    0    2    0  144
8    0    1    0  255  255  255  255    8    0    4    0    1    0
0    0    8    0    7    0  192  168  250  137   24    0   12    0
1    0    0    0  252    9    0    0    0    0    0    0    0    0
0    0   21    4    0    0    8    0    3    0    3    0    0    0

92    0    0    0   24    0    2    0  148   99    0   64   14    3
0    0    2   32   32    0  254    0    0    3    0    2    0  148
8    0    1    0  192  168  250  159    8    0    2    0  192  168  250
144    8    0    4    0    1    0    0    0    8    0    7    0  192
168  250  137   24    0   12    0    1    0    0    0  224   48    0
0    0    0    0    0    0    0    0    0  101    6    0    0    8
0    3    0    3    0    0    0

92    0    0    0   24    0    2    0  148   99    0   64   14    3
0    0    2   32   32    0  254    0    0    2    0    2    0  128
8    0    1    0  192  168  250  137    8    0    2    0  192  135  240
218    8    0    4    0    1    0    0    0    8    0    7    0  192
168  250  137   24    0   12    0    1    0    0    0    1    0    0
0    0    0    0    0    0    0    0    0   93    0    0    0    8
0    3    0    3    0    0    0

104    0    0    0   24    0    2    0  148   99    0   64   14    3
0    0    2   32   32    0  254    0    0    1    0    2    0    0
8    0    1    0  192  135  240  218    8    0    2    0  192  168  250
137    8    0    4    0    3    0    0    0    8    0    5    0  192
168  250  129   20    0    8    0    8    0    2    0  220    5    0
0    8    0    4    0   44    1    0    0   24    0   12    0    2
0    0    0  181   62    1    0    0    0    0    0    0    0    0    0
2    0    0    0

My requirement is to get routing entries (fib) but what I am getting is
matching with entries in /proc/net/rt_cache

[Print of  /proc/net/rt_cache]
1 Iface   Destination     Gateway         Flags           RefCnt
Use     Metric  Source          MTU     Window  IRTT    TOS     HHRef
HHUptod SpecDst

2 lo      FFFFFFFF        FFFFFFFF        90000000        0
1057    0       00000000        0       0       0       00      -1
0       89FAA8C0

3 lo      9FFAA8C0        9FFAA8C0        94000000        0
1675    0       90FAA8C0        0       0       0       00      -1
0       89FAA8C0

4 lo      89FAA8C0        89FAA8C0        80000000        0
139     0       DAF087C0        0       0       0       00      -1
0       89FAA8C0

5 eth0    DAF087C0        81FAA8C0               0        1
2       0       89FAA8C0        1500    0       300     00      2
1       89FAA8C0


Kindly reply ASAP.

Thanks in advance ....
Surya

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

Hi Jim,

James R. Leu wrote:

> Comments within ...
> 
> On Thu, Nov 29, 2001 at 05:32:17PM +0100, Olivier Dugeon wrote:
> 
>>Hi Jim,
>>
>>James R. Leu wrote:
>>
>>
>>>After looking at iptable a bit more I see that it can set a nfmark via
>>>the MARK rule.  Should I use this as oppsed to tc_index to influence the
>>>LSP and EXP? (note that DSCP will still be an options)
>>>
>>>
>>
>>Look at our patch. We have post a full and a small one. The small one 
>>use nfmark and is very close to the actual kernel. The only reason that 
>>we have developpe a similar approach with mpls_index is the ability to 
>>use both nfmark route and mpls_index iptable classification :
>>
>>Our small patch which use nfmark as mpls key override all time the 
>>nfmark route selection. With iptable, you can mark packet ie. nfmark 
>>field in the skbuff and used this nfmark to enhance routing stuff. In 
>>the ip_route_input(net/ipv4/route.c) routine only @ip dst, @ip src, 
>>interface number (input or output) and tos field are used to compute the 
>>hash route table key. Look at the CONFIG_IP_ROUTE_FWMARK flag (line 1686 
>>to 1688) and you can saw that nfmark can be used to enhance this key 
>>calculation. We have mimic this for mpls_index mark. So with the full 
>>patch you can used both mpls_index and/or nfmark as enhancement for the 
>>hash key route table computation.
>>
> 
> So you're saying that by using nfmark for MPLS we'd be overloading nfmark
> and wouldn't be able to do specialized route lookups (with nfmark) and
> have nfmark choose the LSP.  I guess I understand that.  So we need something
> like MARK (MPLS) and stores the value on the skb (mpls_index).  I might
> agrees with that, but the details of what it stores in the skb are still
> unclear to me.  (as in, I need to think about it more)
> 


mplx_index in the original patch (until to v0.3) store the RADIX_TREE 
index. After v0.4 (include) we store the label. So, it's more user 
friendly, we haven't the nedd of retrieve the RADIX_TREE key from 
/proc/net/mpls_xxx. From the label we recompute the RADIX_TREE key in 
the (net/ipv4/route.c)rt_set_next_hop routine. So, we are abble to 
retrieve the moi from the RADIX_TREE and setup the route key ops_data field.

This is execute only once per flow. After executing the 
(net/ipv4/route.c)rt_set_next_hop routine, the 
(net/ipv4/route.c)ip_route_input_slow routine finish to compute the 
route hash key. So, the moi is store in this structure, and the next 
packet are directly process. The mpls_index is used like the nfmark to 
setup different route hash key and distinguish different packet 
labelling comming from a same or to a same IP address. To convince 
Steven, mpls long stuff is made only once per flow. Activate the debug 
and look at the trace. You can see that rt_set_next_hop mpls stuff is 
call only once per flow. I made some test. A ping without MPLS between 2 
node take around 80 micro-second. With MPLS + iptables + TC, the first 
ping packet take around 150-180 micro-second and the subsequent one 
around 120-130 micro-second.

As you not in your previous mail, i doesn't want to bypass the ipv4 
stack. I think its a bad think and we can't do this because in MPLS, the 
box is first of all a router. So, it must process the packet as a normal 
router. It's just at the end that we decide to labelled the packet. You 
and me respect this both with the FIB and the iptable stuff.



> 
>>>I think I now understand what Olivier did, he created something similar
>>>to MARK but for MPLS.  If we are going to continue to use that I would
>>>like to change it alittle.  Instead of storing the mpls_index, I think it
>>>should build a dst and store it with the rule.  This dst will direct the
>>>skb to mpls_output() and will have the outgoung label info attached.
>>>When it gets to mpls_output() MPLS processing will occur like normal.
>>>The dst will be slapped on to any packet that matches the rule.
>>>
>>>Do you think that by using nfmark we can accomplish the same thing?
>>>We would have to relay upon another mean of getting data to mpls_output()
>>>like a MPLS tunnel interface or a entry in the FIB that has been marked
>>>for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
>>>the LSP or EXP.
>>>
>>>Ofcourse maybe it's just safer to have both options availble :-)
>>>
>>>Now to the matter of tc_index.  It seems that nfmark can be used by a
>>>scheduling classifier, but it looks like the classifier for tc_index is
>>>better.  So it might be that nfmark (or a MPLS mark) is used to influence
>>>LSP and EXP descisions (note that DSCP will still be option) and that
>>>tc_index is used to influence scheduling.
>>>
>>
>>Actually for the TC part, we use mpls_index. My latest patch (not 
>>publish yet) use mpls_index when it has been configured in the 
>>kernel_config and directly the label in the other case. We can recopy 
>>this index into the tc_index. The TC mpls classifier has been written 
>>for this purpose. The original way we want code is to use u32 
>>classifier. But there is two pb.
>>
>>1/ the label is not accessible by u32 classifier. They only start at the 
>>ip header not the shim header.
>>
>>2/ Why classify again the packet (CPU power ....) if it has already been 
>>classified with iptable or another process ? The shim header (formely 
>>the label and/or the EXP fields of the shim header) can be used as a 
>>filter mark.
>>
> 
> Would using the tc_index sched classifier solve #1?  As for number 2 you
> need both.  iptables simply marks it, no scheduling is actually done.
> The sched classifier is mearly trying to sort the marked packets into the
> appropriate "queues".
> 
> Jim
> 
> 


-- 
  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] CR-LDP

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

Don't even bother playing with 0.060.  Get tha lastest version from CVS.

On Fri, Nov 30, 2001 at 04:05:14AM -0800, Mouli T wrote:
> hi Mrugendra,
>     Few days back we worked with LDP code version
> 0.060 and are able to establish Downstream on demand
> Ordered LSP (by changing the options accordingly and
> rebuilding ldp_linux executable).
>     In the process we feel few fixes are needed to the
> present code. they are=20
>=20
> While adding new route using add_route() in
> ldp_linux.c
> instead of=20
>   dest->next_hop.u.ipv4 =3D ntohl(inet_addr(net_str));
> use=20
>   dest->next_hop.u.ipv4 =3D ntohl(inet_addr(nh_str));
>=20
> while preparing attributes for a new route added using
> Recognize_new_fec() r_attr is NULL and thus causing
> segmentation fault in Prepare_Label_Request_Attributes
> (ldp_label_request.c). We went for a quick fix by
> setting s_attr fields to 1 whenever r_attr is NULL.
>=20
> After doing the two fixes try establish LDP sessions
> and add route in LDP at INGRESS. You should be able to
> establish DoD ordered LSP successfully.
>=20
> pl. give yr feedback....
>=20
> Thanks,
> Mouli.
>=20
>=20
> =1A
> --- =03 Singhai <mru...@ya...> wrote:
> > Hi All,
> >=20
> > I was wondering if any one has tested Downstream on=20
> > =20
> >  Demand Ordered Control on the current LDP code of =20
> > =20
> > James.
> >=20
> > Is there any way in current code to support the   =20
> > requirement of CR-LDP i.e. to have DoD Ordered
> > Control
> >  to be infered from existance of any TLV defined in=20
> > =20
> >  CR-LDP. Since the present code fixes the control
> > and=20
> >   distribution at startup.
> >=20
> > If anybody can help about how we can map Label
> > request
> > Procedure defined in LDP Spec & CR-LDP section 3 to
> > present LDP code.
> >=20
> > Also James if you could pls briefly write about
> > mpls-linux 1.1
> >=20
> > Regards
> > Mrugendra
> >=20
> >=20
> > --- "James R. Leu" <jl...@mi...> wrote:
> > > I will be posting mpls-linux-1.1.tar.gz soon,
> > which
> > > has a lot of
> > > integration for E-LSPs L-LSP and hooks to DSCP.
> > >=20
> > > I hope to post more about this tomorrow morning.
> > >=20
> > > Jim
> > >=20
> > > On Tue, Nov 20, 2001 at 06:12:04PM -0800,
> > Mrugendra
> > > Singhai wrote:
> > > > Hi All,
> > > >=20
> > > > This is regarding implementing "MPLS support of
> > > > Diffserv" in current LDP code of James.=20
> > > >=20
> > > > I did go through the extension implemented by
> > > people
> > > > at Intec. Last I saw, it had E-LSP support using
> > > RSVP.
> > > > And the way they implemented it was by having
> > > changing
> > > > the mpls label and by changing the key to store
> > > label
> > > > to include the exp as well.
> > > >=20
> > > > But this approach does not supports L-LSP. Also
> > I
> > > > could not figure out how and where they were
> > > handling
> > > > the Diffserv context associated with the LSP.
> > > >=20
> > > > What I was interested in knowing was
> > > >=20
> > > > 1) Will it not be a better idea to store the
> > > entire
> > > > diffserv context associated with a LSP in one
> > > in_info
> > > > entry in radix tree.
> > > >=20
> > > > Any other suggestions on how exactly to
> > implement
> > > EXP
> > > > support is deeply appreciated.
> > > >=20
> > > > Regards
> > > > Mrugendra
> > > >=20
> > > >=20
> > > >
> > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! GeoCities - quick and easy web site
> > > hosting, just $8.95/month.
> > > > http://geocities.yahoo.com/ps/info1
> > > >=20
> > > > _______________________________________________
> > > > mpls-linux-general mailing list
> > > > mpl...@li...
> > > >
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> > >=20
> > > --=20
> > > James R. Leu
> >=20
> >=20
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! GeoCities - quick and easy web site hosting,
> > just $8.95/month.
> > http://geocities.yahoo.com/ps/info1
> >=20
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> >
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
>=20
>=20
> __________________________________________________
> Do You Yahoo!?
> Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
> http://geocities.yahoo.com/ps/info1
>=20
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

--=20
James R. Leu
jl...@mi...

Re: [mpls-linux-general] CR-LDP

[Mouli T <mou...@ya...>]

hi Mrugendra,
    Few days back we worked with LDP code version
0.060 and are able to establish Downstream on demand
Ordered LSP (by changing the options accordingly and
rebuilding ldp_linux executable).
    In the process we feel few fixes are needed to the
present code. they are 

While adding new route using add_route() in
ldp_linux.c
instead of 
  dest->next_hop.u.ipv4 = ntohl(inet_addr(net_str));
use 
  dest->next_hop.u.ipv4 = ntohl(inet_addr(nh_str));

while preparing attributes for a new route added using
Recognize_new_fec() r_attr is NULL and thus causing
segmentation fault in Prepare_Label_Request_Attributes
(ldp_label_request.c). We went for a quick fix by
setting s_attr fields to 1 whenever r_attr is NULL.

After doing the two fixes try establish LDP sessions
and add route in LDP at INGRESS. You should be able to
establish DoD ordered LSP successfully.

pl. give yr feedback....

Thanks,
Mouli.



---  Singhai <mru...@ya...> wrote:
> Hi All,
> 
> I was wondering if any one has tested Downstream on 
>  
>  Demand Ordered Control on the current LDP code of  
>  
> James.
> 
> Is there any way in current code to support the    
> requirement of CR-LDP i.e. to have DoD Ordered
> Control
>  to be infered from existance of any TLV defined in 
>  
>  CR-LDP. Since the present code fixes the control
> and 
>   distribution at startup.
> 
> If anybody can help about how we can map Label
> request
> Procedure defined in LDP Spec & CR-LDP section 3 to
> present LDP code.
> 
> Also James if you could pls briefly write about
> mpls-linux 1.1
> 
> Regards
> Mrugendra
> 
> 
> --- "James R. Leu" <jl...@mi...> wrote:
> > I will be posting mpls-linux-1.1.tar.gz soon,
> which
> > has a lot of
> > integration for E-LSPs L-LSP and hooks to DSCP.
> > 
> > I hope to post more about this tomorrow morning.
> > 
> > Jim
> > 
> > On Tue, Nov 20, 2001 at 06:12:04PM -0800,
> Mrugendra
> > Singhai wrote:
> > > Hi All,
> > > 
> > > This is regarding implementing "MPLS support of
> > > Diffserv" in current LDP code of James. 
> > > 
> > > I did go through the extension implemented by
> > people
> > > at Intec. Last I saw, it had E-LSP support using
> > RSVP.
> > > And the way they implemented it was by having
> > changing
> > > the mpls label and by changing the key to store
> > label
> > > to include the exp as well.
> > > 
> > > But this approach does not supports L-LSP. Also
> I
> > > could not figure out how and where they were
> > handling
> > > the Diffserv context associated with the LSP.
> > > 
> > > What I was interested in knowing was
> > > 
> > > 1) Will it not be a better idea to store the
> > entire
> > > diffserv context associated with a LSP in one
> > in_info
> > > entry in radix tree.
> > > 
> > > Any other suggestions on how exactly to
> implement
> > EXP
> > > support is deeply appreciated.
> > > 
> > > Regards
> > > Mrugendra
> > > 
> > > 
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! GeoCities - quick and easy web site
> > hosting, just $8.95/month.
> > > http://geocities.yahoo.com/ps/info1
> > > 
> > > _______________________________________________
> > > mpls-linux-general mailing list
> > > mpl...@li...
> > >
> >
>
https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> > 
> > -- 
> > James R. Leu
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! GeoCities - quick and easy web site hosting,
> just $8.95/month.
> http://geocities.yahoo.com/ps/info1
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
>
https://lists.sourceforge.net/lists/listinfo/mpls-linux-general


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

OK, it seems it's time for a change in terminology: when i say bypass
IPv4 routing, i mean it in an engineering way, not a conceptional way.
The basic scheme we want from a linux ingress box is:

+------------------+   +----------+   +--------------+
|MF Classification +-->+Forwarding+-->+get ip nexthop|
|Policing/Shaping  |   |selection ++  +------------+-+  
+------------------+   +----------+ \               \
(MF=multifield)        (MPLS or ip)  \  +----------+ \   +--+
                                      +>+push label+--+->+TC|
                                        +----------+     +--+
     (1)                                   (2)            (3)

e.g. 1 classification in phase (1), to be used wherever needed. Now what
i would like (personal opinion) is to have to go through only one of the
two phases in (2). So i don't want to harm the hybrid mpls/ip approach,
i just want to limit the amount of processing and interference with the
IP path.

Now, about TC:In the core, normally (1) is absent, since no complex
multi-field classifications are needed, just a dscp lookup, which can be
done in (3). 

cheers,
Steven

PS: anybody feels like hacking together an ascii-art drawing plugin for
mailclients. Would be a great help :)

On Fri, 2001-11-30 at 04:32, James R. Leu wrote:
> I want to make sure I've got your opinion correct:
> 
> On an ingress LER your think iptables -> nfmark is sufficient.
> On a transit LSR and egress LER tc_index is needed (to augment dsmask and
> scheduling).
> 
> In addition you would like the option of using iptables to do all
> marking/classifing AND bypass normal routing lookups, but it may be possible
> to use the existing mechanisms (aux_proto on a FIB entry or a MPLS tunnel
> interface) to achive the same functionality, but not necessarily the same
> level of efficiency.
> 
> Jim
> 
> On Thu, Nov 29, 2001 at 08:50:56AM +0100, Steven Van den Berghe wrote:
> > On Thu, 2001-11-29 at 05:20, James R. Leu wrote:
> > > After looking at iptable a bit more I see that it can set a nfmark via
> > > the MARK rule.  Should I use this as oppsed to tc_index to influence the
> > > LSP and EXP? (note that DSCP will still be an options)
> > Would be a clean choice (note: you'll still need part of Olivier's patch
> > to implement a FEC like behavior per iptables result). 
> > > 
> > > I think I now understand what Olivier did, he created something similar
> > > to MARK but for MPLS.  If we are going to continue to use that I would
> > > like to change it alittle.  Instead of storing the mpls_index, I think it
> > > should build a dst and store it with the rule.  This dst will direct the
> > > skb to mpls_output() and will have the outgoung label info attached.
> > > When it gets to mpls_output() MPLS processing will occur like normal.
> > > The dst will be slapped on to any packet that matches the rule.
> > Iptables has hooks in several places along the forwarding path: before,
> > in or after the "routing". Is there no possibility that dev will be
> > overwritten by the ip-code? I still feel, we should be able to bypass
> > routing completely (i'm searching what can be done to handle
> > fragmentation etc.)
> > > 
> > > Do you think that by using nfmark we can accomplish the same thing?
> > > We would have to relay upon another mean of getting data to mpls_output()
> > > like a MPLS tunnel interface or a entry in the FIB that has been marked
> > > for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> > > the LSP or EXP.
> > > 
> > first guess (warning: statistically proven it's mostly wrong): possible
> > approach.
> > 
> > > Ofcourse maybe it's just safer to have both options availble :-)
> > > 
> > > Now to the matter of tc_index.  It seems that nfmark can be used by a
> > > scheduling classifier, but it looks like the classifier for tc_index is
> > > better.  So it might be that nfmark (or a MPLS mark) is used to influence
> > > LSP and EXP descisions (note that DSCP will still be option) and that
> > > tc_index is used to influence scheduling.
> > > 
> > tc_index is indeed no "must". There are other solutions possible to get
> > the same effect, especially in the ingress (in the core, we don't want
> > to use iptables for anything). The only thing from the original diffserv
> > for ip the sch_dsmark  + tc_index combination offers you is:
> > 
> >  1 you can read the (ip) dscp and put it in tc_index (enqueue operation)
> >  2 you can classify based on tc_index
> >  3 you can modify the value of tc_index during the traffic control
> >  4 you can re-write the dscp based on tc_index in the ip-header when
> > exiting sch_dsmark (dequeue operation) 
> > 
> > 1 and 2 can be done using iptables and fw_mark classifier
> > 3 and 4 need more study. At first sight, i'd say we can do this either
> > in ingress policing or add it to iptables (configuration would be
> > something like: if offered load <1Mbps set fwmark 2, if offered load
> > <2Mbps set fwmark 1, else set fwmark 0).
> > 
> > just a personal opinion: i would keep the sch_dsmark approach in LSR and
> > egress, but for ingress (where the more complex TC functions should be
> > performed, to achieve scaleability), forgetting about sch_dsmark and
> > tc_index would be just fine.
> > 
> > 
> >  Does that make any sense?  It's late.  I'm going to sleep and think about
> > > it some more.
> > >
> > why, i've just woken up :)
> >  
> > 
> > cheers,
> > Steven
> > -- 
> > --
> > 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
> > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> > 
> > 
> > _______________________________________________
> > mpls-linux-general mailing list
> > mpl...@li...
> > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general
> 
> -- 
> 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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
A computer is like an Old Testament god, with a lot of
rules and no mercy. - Joseph Campbell
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

Comments at the bottom:

On Thu, Nov 29, 2001 at 11:53:01PM +0100, Steven Van den Berghe wrote:
> Hi Olivier, Jim,
> 
> On Thu, 2001-11-29 at 17:32, Olivier Dugeon wrote:
> > Hi Jim,
> > 
> <did some cutting here>
> 
> > > Now to the matter of tc_index.  It seems that nfmark can be used by a
> > > scheduling classifier, but it looks like the classifier for tc_index is
> > > better.  So it might be that nfmark (or a MPLS mark) is used to influence
> > > LSP and EXP descisions (note that DSCP will still be option) and that
> > > tc_index is used to influence scheduling.
> > 
> > 
> > Actually for the TC part, we use mpls_index. My latest patch (not 
> > publish yet) use mpls_index when it has been configured in the 
> > kernel_config and directly the label in the other case. We can recopy 
> > this index into the tc_index. The TC mpls classifier has been written 
> > for this purpose. The original way we want code is to use u32 
> > classifier. But there is two pb.
> > 
> > 1/ the label is not accessible by u32 classifier. They only start at the 
> > ip header not the shim header.
> > 
> > 2/ Why classify again the packet (CPU power ....) if it has already been 
> > classified with iptable or another process ? The shim header (formely 
> > the label and/or the EXP fields of the shim header) can be used as a 
> > filter mark.
> > 
> agree, there is no use in doing the same job twice. I think for TC, the
> bottom line is that we want to be flexible on the type of classifier to
> use (especially in the ingress): tc_index, fw_mark,...

It seems you and Olivier have something against the Linux IPv4 stack, you
guys want to bypass it in any way possible :-)

I'm going to hop up on my soap box a give you my opinion about this, mind
you this is just opinion and further education about iptabels and TC may
change my mind, but:

MPLS is not meant to take the place of IP routing, it is mean to augment and
work with IP routing to do path selection upfront, and not per packet.
The same is true with traffic engineering or differentiated services, they
mean nothing without traditional IPv4 routing. So to say "we want to bypass
IP routing" is not a statment that is true to the definitions of MPLS or
TE or DiffServ.  We need to figure out what is the correct way to take
what IP routing tells us, augment it, and then find the correct place to
apply it.  Granted I'm definitly not an TE or DiffServ expert, but I have
leared the underlying mechanics of a number of MPLS implementation
(commercial).  I tend to think that marking route entries and using MPLS tunnel
interface are the only mechanisms you need to direct traffic into the
MPLS stack.  We do need additional info per packet, provided via iptables,
but iptables cannot replace the IPv4 stack.

Anyway, I'll get off my soap box now.

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

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

I want to make sure I've got your opinion correct:

On an ingress LER your think iptables -> nfmark is sufficient.
On a transit LSR and egress LER tc_index is needed (to augment dsmask and
scheduling).

In addition you would like the option of using iptables to do all
marking/classifing AND bypass normal routing lookups, but it may be possible
to use the existing mechanisms (aux_proto on a FIB entry or a MPLS tunnel
interface) to achive the same functionality, but not necessarily the same
level of efficiency.

Jim

On Thu, Nov 29, 2001 at 08:50:56AM +0100, Steven Van den Berghe wrote:
> On Thu, 2001-11-29 at 05:20, James R. Leu wrote:
> > After looking at iptable a bit more I see that it can set a nfmark via
> > the MARK rule.  Should I use this as oppsed to tc_index to influence the
> > LSP and EXP? (note that DSCP will still be an options)
> Would be a clean choice (note: you'll still need part of Olivier's patch
> to implement a FEC like behavior per iptables result). 
> > 
> > I think I now understand what Olivier did, he created something similar
> > to MARK but for MPLS.  If we are going to continue to use that I would
> > like to change it alittle.  Instead of storing the mpls_index, I think it
> > should build a dst and store it with the rule.  This dst will direct the
> > skb to mpls_output() and will have the outgoung label info attached.
> > When it gets to mpls_output() MPLS processing will occur like normal.
> > The dst will be slapped on to any packet that matches the rule.
> Iptables has hooks in several places along the forwarding path: before,
> in or after the "routing". Is there no possibility that dev will be
> overwritten by the ip-code? I still feel, we should be able to bypass
> routing completely (i'm searching what can be done to handle
> fragmentation etc.)
> > 
> > Do you think that by using nfmark we can accomplish the same thing?
> > We would have to relay upon another mean of getting data to mpls_output()
> > like a MPLS tunnel interface or a entry in the FIB that has been marked
> > for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> > the LSP or EXP.
> > 
> first guess (warning: statistically proven it's mostly wrong): possible
> approach.
> 
> > Ofcourse maybe it's just safer to have both options availble :-)
> > 
> > Now to the matter of tc_index.  It seems that nfmark can be used by a
> > scheduling classifier, but it looks like the classifier for tc_index is
> > better.  So it might be that nfmark (or a MPLS mark) is used to influence
> > LSP and EXP descisions (note that DSCP will still be option) and that
> > tc_index is used to influence scheduling.
> > 
> tc_index is indeed no "must". There are other solutions possible to get
> the same effect, especially in the ingress (in the core, we don't want
> to use iptables for anything). The only thing from the original diffserv
> for ip the sch_dsmark  + tc_index combination offers you is:
> 
>  1 you can read the (ip) dscp and put it in tc_index (enqueue operation)
>  2 you can classify based on tc_index
>  3 you can modify the value of tc_index during the traffic control
>  4 you can re-write the dscp based on tc_index in the ip-header when
> exiting sch_dsmark (dequeue operation) 
> 
> 1 and 2 can be done using iptables and fw_mark classifier
> 3 and 4 need more study. At first sight, i'd say we can do this either
> in ingress policing or add it to iptables (configuration would be
> something like: if offered load <1Mbps set fwmark 2, if offered load
> <2Mbps set fwmark 1, else set fwmark 0).
> 
> just a personal opinion: i would keep the sch_dsmark approach in LSR and
> egress, but for ingress (where the more complex TC functions should be
> performed, to achieve scaleability), forgetting about sch_dsmark and
> tc_index would be just fine.
> 
> 
>  Does that make any sense?  It's late.  I'm going to sleep and think about
> > it some more.
> >
> why, i've just woken up :)
>  
> 
> cheers,
> Steven
> -- 
> --
> 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
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> 
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

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

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

Comments within ...

On Thu, Nov 29, 2001 at 05:32:17PM +0100, Olivier Dugeon wrote:
> Hi Jim,
> 
> James R. Leu wrote:
> 
> > After looking at iptable a bit more I see that it can set a nfmark via
> > the MARK rule.  Should I use this as oppsed to tc_index to influence the
> > LSP and EXP? (note that DSCP will still be an options)
> > 
> 
> 
> Look at our patch. We have post a full and a small one. The small one 
> use nfmark and is very close to the actual kernel. The only reason that 
> we have developpe a similar approach with mpls_index is the ability to 
> use both nfmark route and mpls_index iptable classification :
> 
> Our small patch which use nfmark as mpls key override all time the 
> nfmark route selection. With iptable, you can mark packet ie. nfmark 
> field in the skbuff and used this nfmark to enhance routing stuff. In 
> the ip_route_input(net/ipv4/route.c) routine only @ip dst, @ip src, 
> interface number (input or output) and tos field are used to compute the 
> hash route table key. Look at the CONFIG_IP_ROUTE_FWMARK flag (line 1686 
> to 1688) and you can saw that nfmark can be used to enhance this key 
> calculation. We have mimic this for mpls_index mark. So with the full 
> patch you can used both mpls_index and/or nfmark as enhancement for the 
> hash key route table computation.

So you're saying that by using nfmark for MPLS we'd be overloading nfmark
and wouldn't be able to do specialized route lookups (with nfmark) and
have nfmark choose the LSP.  I guess I understand that.  So we need something
like MARK (MPLS) and stores the value on the skb (mpls_index).  I might
agrees with that, but the details of what it stores in the skb are still
unclear to me.  (as in, I need to think about it more)

> > I think I now understand what Olivier did, he created something similar
> > to MARK but for MPLS.  If we are going to continue to use that I would
> > like to change it alittle.  Instead of storing the mpls_index, I think it
> > should build a dst and store it with the rule.  This dst will direct the
> > skb to mpls_output() and will have the outgoung label info attached.
> > When it gets to mpls_output() MPLS processing will occur like normal.
> > The dst will be slapped on to any packet that matches the rule.
> > 
> > Do you think that by using nfmark we can accomplish the same thing?
> > We would have to relay upon another mean of getting data to mpls_output()
> > like a MPLS tunnel interface or a entry in the FIB that has been marked
> > for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> > the LSP or EXP.
> > 
> > Ofcourse maybe it's just safer to have both options availble :-)
> > 
> > Now to the matter of tc_index.  It seems that nfmark can be used by a
> > scheduling classifier, but it looks like the classifier for tc_index is
> > better.  So it might be that nfmark (or a MPLS mark) is used to influence
> > LSP and EXP descisions (note that DSCP will still be option) and that
> > tc_index is used to influence scheduling.
> 
> 
> Actually for the TC part, we use mpls_index. My latest patch (not 
> publish yet) use mpls_index when it has been configured in the 
> kernel_config and directly the label in the other case. We can recopy 
> this index into the tc_index. The TC mpls classifier has been written 
> for this purpose. The original way we want code is to use u32 
> classifier. But there is two pb.
> 
> 1/ the label is not accessible by u32 classifier. They only start at the 
> ip header not the shim header.
> 
> 2/ Why classify again the packet (CPU power ....) if it has already been 
> classified with iptable or another process ? The shim header (formely 
> the label and/or the EXP fields of the shim header) can be used as a 
> filter mark.

Would using the tc_index sched classifier solve #1?  As for number 2 you
need both.  iptables simply marks it, no scheduling is actually done.
The sched classifier is mearly trying to sort the marked packets into the
appropriate "queues".

Jim

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

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

Hi Olivier, Jim,

On Thu, 2001-11-29 at 17:32, Olivier Dugeon wrote:
> Hi Jim,
> 
<did some cutting here>

> > Now to the matter of tc_index.  It seems that nfmark can be used by a
> > scheduling classifier, but it looks like the classifier for tc_index is
> > better.  So it might be that nfmark (or a MPLS mark) is used to influence
> > LSP and EXP descisions (note that DSCP will still be option) and that
> > tc_index is used to influence scheduling.
> 
> 
> Actually for the TC part, we use mpls_index. My latest patch (not 
> publish yet) use mpls_index when it has been configured in the 
> kernel_config and directly the label in the other case. We can recopy 
> this index into the tc_index. The TC mpls classifier has been written 
> for this purpose. The original way we want code is to use u32 
> classifier. But there is two pb.
> 
> 1/ the label is not accessible by u32 classifier. They only start at the 
> ip header not the shim header.
> 
> 2/ Why classify again the packet (CPU power ....) if it has already been 
> classified with iptable or another process ? The shim header (formely 
> the label and/or the EXP fields of the shim header) can be used as a 
> filter mark.
> 
agree, there is no use in doing the same job twice. I think for TC, the
bottom line is that we want to be flexible on the type of classifier to
use (especially in the ingress): tc_index, fw_mark,...

Cheers,
Steven

 
-- 
--
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] Better to use nfmark vs tc_index?

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

Hi Jim,

James R. Leu wrote:

> After looking at iptable a bit more I see that it can set a nfmark via
> the MARK rule.  Should I use this as oppsed to tc_index to influence the
> LSP and EXP? (note that DSCP will still be an options)
> 


Look at our patch. We have post a full and a small one. The small one 
use nfmark and is very close to the actual kernel. The only reason that 
we have developpe a similar approach with mpls_index is the ability to 
use both nfmark route and mpls_index iptable classification :

Our small patch which use nfmark as mpls key override all time the 
nfmark route selection. With iptable, you can mark packet ie. nfmark 
field in the skbuff and used this nfmark to enhance routing stuff. In 
the ip_route_input(net/ipv4/route.c) routine only @ip dst, @ip src, 
interface number (input or output) and tos field are used to compute the 
hash route table key. Look at the CONFIG_IP_ROUTE_FWMARK flag (line 1686 
to 1688) and you can saw that nfmark can be used to enhance this key 
calculation. We have mimic this for mpls_index mark. So with the full 
patch you can used both mpls_index and/or nfmark as enhancement for the 
hash key route table computation.


> I think I now understand what Olivier did, he created something similar
> to MARK but for MPLS.  If we are going to continue to use that I would
> like to change it alittle.  Instead of storing the mpls_index, I think it
> should build a dst and store it with the rule.  This dst will direct the
> skb to mpls_output() and will have the outgoung label info attached.
> When it gets to mpls_output() MPLS processing will occur like normal.
> The dst will be slapped on to any packet that matches the rule.
> 
> Do you think that by using nfmark we can accomplish the same thing?
> We would have to relay upon another mean of getting data to mpls_output()
> like a MPLS tunnel interface or a entry in the FIB that has been marked
> for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> the LSP or EXP.
> 
> Ofcourse maybe it's just safer to have both options availble :-)
> 
> Now to the matter of tc_index.  It seems that nfmark can be used by a
> scheduling classifier, but it looks like the classifier for tc_index is
> better.  So it might be that nfmark (or a MPLS mark) is used to influence
> LSP and EXP descisions (note that DSCP will still be option) and that
> tc_index is used to influence scheduling.


Actually for the TC part, we use mpls_index. My latest patch (not 
publish yet) use mpls_index when it has been configured in the 
kernel_config and directly the label in the other case. We can recopy 
this index into the tc_index. The TC mpls classifier has been written 
for this purpose. The original way we want code is to use u32 
classifier. But there is two pb.

1/ the label is not accessible by u32 classifier. They only start at the 
ip header not the shim header.

2/ Why classify again the packet (CPU power ....) if it has already been 
classified with iptable or another process ? The shim header (formely 
the label and/or the EXP fields of the shim header) can be used as a 
filter mark.


> 
> Does that make any sense?  It's late.  I'm going to sleep and think about
> it some more.
> 
> Jim
> 


Hope you this help.


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] wrong command in readme

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

I've added the change to CVS

Thank you!

On Thu, Nov 29, 2001 at 03:29:42PM +0100, Kauder Thorsten wrote:
> Hi
> if anyone cares.
> There is a wrong commandline in the readme.hierarchy:
> 
> line Nr. 31 is:
> 
> On B:
> mplsadm -A -I gen:101:eth0:ipv4:C
> 
> this should create an incominging label. Therefor must be :
> 
> mplsadm -A -O ........
> 
> cheers
> Thorsten
> 
> _______________________________________________
> mpls-linux-general mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general

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

[mpls-linux-general] wrong command in readme

[Kauder T. <Tho...@ic...>]

Hi
if anyone cares.
There is a wrong commandline in the readme.hierarchy:

line Nr. 31 is:

On B:
mplsadm -A -I gen:101:eth0:ipv4:C

this should create an incominging label. Therefor must be :

mplsadm -A -O ........

cheers
Thorsten

Re: [mpls-linux-general] Better to use nfmark vs tc_index?

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

On Thu, 2001-11-29 at 05:20, James R. Leu wrote:
> After looking at iptable a bit more I see that it can set a nfmark via
> the MARK rule.  Should I use this as oppsed to tc_index to influence the
> LSP and EXP? (note that DSCP will still be an options)
Would be a clean choice (note: you'll still need part of Olivier's patch
to implement a FEC like behavior per iptables result). 
> 
> I think I now understand what Olivier did, he created something similar
> to MARK but for MPLS.  If we are going to continue to use that I would
> like to change it alittle.  Instead of storing the mpls_index, I think it
> should build a dst and store it with the rule.  This dst will direct the
> skb to mpls_output() and will have the outgoung label info attached.
> When it gets to mpls_output() MPLS processing will occur like normal.
> The dst will be slapped on to any packet that matches the rule.
Iptables has hooks in several places along the forwarding path: before,
in or after the "routing". Is there no possibility that dev will be
overwritten by the ip-code? I still feel, we should be able to bypass
routing completely (i'm searching what can be done to handle
fragmentation etc.)
> 
> Do you think that by using nfmark we can accomplish the same thing?
> We would have to relay upon another mean of getting data to mpls_output()
> like a MPLS tunnel interface or a entry in the FIB that has been marked
> for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
> the LSP or EXP.
> 
first guess (warning: statistically proven it's mostly wrong): possible
approach.

> Ofcourse maybe it's just safer to have both options availble :-)
> 
> Now to the matter of tc_index.  It seems that nfmark can be used by a
> scheduling classifier, but it looks like the classifier for tc_index is
> better.  So it might be that nfmark (or a MPLS mark) is used to influence
> LSP and EXP descisions (note that DSCP will still be option) and that
> tc_index is used to influence scheduling.
> 
tc_index is indeed no "must". There are other solutions possible to get
the same effect, especially in the ingress (in the core, we don't want
to use iptables for anything). The only thing from the original diffserv
for ip the sch_dsmark  + tc_index combination offers you is:

 1 you can read the (ip) dscp and put it in tc_index (enqueue operation)
 2 you can classify based on tc_index
 3 you can modify the value of tc_index during the traffic control
 4 you can re-write the dscp based on tc_index in the ip-header when
exiting sch_dsmark (dequeue operation) 

1 and 2 can be done using iptables and fw_mark classifier
3 and 4 need more study. At first sight, i'd say we can do this either
in ingress policing or add it to iptables (configuration would be
something like: if offered load <1Mbps set fwmark 2, if offered load
<2Mbps set fwmark 1, else set fwmark 0).

just a personal opinion: i would keep the sch_dsmark approach in LSR and
egress, but for ingress (where the more complex TC functions should be
performed, to achieve scaleability), forgetting about sch_dsmark and
tc_index would be just fine.


 Does that make any sense?  It's late.  I'm going to sleep and think about
> it some more.
>
why, i've just woken up :)
 

cheers,
Steven
-- 
--
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

[mpls-linux-general] Better to use nfmark vs tc_index?

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

After looking at iptable a bit more I see that it can set a nfmark via
the MARK rule.  Should I use this as oppsed to tc_index to influence the
LSP and EXP? (note that DSCP will still be an options)

I think I now understand what Olivier did, he created something similar
to MARK but for MPLS.  If we are going to continue to use that I would
like to change it alittle.  Instead of storing the mpls_index, I think it
should build a dst and store it with the rule.  This dst will direct the
skb to mpls_output() and will have the outgoung label info attached.
When it gets to mpls_output() MPLS processing will occur like normal.
The dst will be slapped on to any packet that matches the rule.

Do you think that by using nfmark we can accomplish the same thing?
We would have to relay upon another mean of getting data to mpls_output()
like a MPLS tunnel interface or a entry in the FIB that has been marked
for MPLS.  Once it gets to mpls_output() the nfmark could be used to influence
the LSP or EXP.

Ofcourse maybe it's just safer to have both options availble :-)

Now to the matter of tc_index.  It seems that nfmark can be used by a
scheduling classifier, but it looks like the classifier for tc_index is
better.  So it might be that nfmark (or a MPLS mark) is used to influence
LSP and EXP descisions (note that DSCP will still be option) and that
tc_index is used to influence scheduling.

Does that make any sense?  It's late.  I'm going to sleep and think about
it some more.

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

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