SoC 2009 Ayame MPLS

[basteon]

g'day,
I'm a student from Russia. I've a tiny bit kernel-development for
netbsd, but not complete yet, it would be support new fxo hardware on
zaptel driver. And I would be to assist implement mpls stack into
NetBSD on Google SoC 2009 or it's not priority project? I can testing
it with cisco hardware.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mihai Chelaru]

Post by basteon
g'day,
I'm a student from Russia. I've a tiny bit kernel-development for
netbsd, but not complete yet, it would be support new fxo hardware on
zaptel driver. And I would be to assist implement mpls stack into
NetBSD on Google SoC 2009 or it's not priority project? I can testing
it with cisco hardware.

Hi,

I think "implementing MPLS" sounds too generic and you have to refine
your goals.

Also, starting from Ayame implementation (I'd sugest you to stay away
from Ayame btw), I wrote a small implementation [1] containing an
in-kernel label switch engine and an userland ldp daemon. Although it's
not nearly finished (the ldp at least is not fully RFC compliant) it
enabled NetBSD to act as an LSR (including Edge-LSR) both in tests and
production first interacting with Cisco routers but then tested against
Juniper routers, too. It's a little rotten, patches are against -current
from one year ago but integrating them into today HEAD should be trivial.

At that time, there were some concerns regarding this approach, most
notably the interaction and mixing between MPLS and IP stacks, so I
suggest you write a new design and _DISCUSS_ it on tech-net@ prior to
start coding.

Hope I didn't discourage you :)

[1] - http://ftp.netbsd.org/pub/NetBSD/misc/kefren/mpls/

[basteon]

hi,

Post by Mihai Chelaru
the ldp at least is not fully RFC compliant

Why? In RFC5462 contained information about EXP field(on cisco it like
CoS), it's quality of service stuff switching labels via priority
traffic on top level like udp, tcp, http,... To implement that thing
on NetBSD it's quite hardwork:), I think. Because it needs use
pf-hooks so as to permit label in firewall and altq via queue cbq
frame prioriting. Or you mean something else?

Post by Mihai Chelaru

Post by basteon
g'day,
I'm a student from Russia. I've a tiny bit kernel-development for
netbsd, but not complete yet, it would be support new fxo hardware on
zaptel driver. And I would be to assist implement mpls stack into
NetBSD on Google SoC 2009 or it's not priority project? I can testing
it with cisco hardware.

Hi,
I think "implementing MPLS" sounds too generic and you have to refine
your goals.
Also, starting from Ayame implementation (I'd sugest you to stay away
from Ayame btw), I wrote a small implementation [1] containing an
in-kernel label switch engine and an userland ldp daemon. Although it's
not nearly finished (the ldp at least is not fully RFC compliant) it
enabled NetBSD to act as an LSR (including Edge-LSR) both in tests and
production first interacting with Cisco routers but then tested against
Juniper routers, too. It's a little rotten, patches are against -current
from one year ago but integrating them into today HEAD should be trivial.
At that time, there were some concerns regarding this approach, most
notably the interaction and mixing between MPLS and IP stacks, so I
start coding.
Hope I didn't discourage you :)
[1] - http://ftp.netbsd.org/pub/NetBSD/misc/kefren/mpls/
--
Mihai

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mihai Chelaru]

Post by basteon
hi,

Post by Mihai Chelaru
the ldp at least is not fully RFC compliant

Why? In RFC5462 contained information about EXP field(on cisco it like
CoS), it's quality of service stuff switching labels via priority
traffic on top level like udp, tcp, http,... To implement that thing
on NetBSD it's quite hardwork:), I think. Because it needs use
pf-hooks so as to permit label in firewall and altq via queue cbq
frame prioriting. Or you mean something else?

I was stricly speaking about RFC3036, which by the way, got obsoleted by
RFC5036.

[Nobuo Ogashiwa]

Hi,

I'm nobuo ogashiwa, an implementer of the AYAME LDP daemon.
I have implemented ldpd (CR-LDP daemon, static labeling daemon, and
rsvp-te daemon)
based on some RFCs published before 2004 like RFC3036, so that the ldpd
doesn't support recent RFCs.

Regards,
Nobuo Ogashiwa

Post by Mihai Chelaru

Post by basteon
hi,

Post by Mihai Chelaru
the ldp at least is not fully RFC compliant

Why? In RFC5462 contained information about EXP field(on cisco it like
CoS), it's quality of service stuff switching labels via priority
traffic on top level like udp, tcp, http,... To implement that thing
on NetBSD it's quite hardwork:), I think. Because it needs use
pf-hooks so as to permit label in firewall and altq via queue cbq
frame prioriting. Or you mean something else?

I was stricly speaking about RFC3036, which by the way, got obsoleted by
RFC5036.
--
Mihai Chelaru

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[basteon]

hello,
I'm come back.

Well, I getting dump hello's packets of cisco LDP's. Its with diff
service stuff, but like old mpls version with hello field's 0x0100,
the new specification has 0x0901 value. I've not juniper equipment. I
did test it on 3640 and 7206 in dynamips. DiffServ on netbsd and on
cisco has differently dscp values, for example...
#define DSCP_AF11 0x28
#define DSCP_AF12 0x30
#define DSCP_AF13 0x38
af11 Match packets with AF11 dscp (001010) 0xA
af12 Match packets with AF12 dscp (001100) 0xC
af13 Match packets with AF13 dscp (001110) 0xE
It's just local usage choose wait queue for either packet wich has
diffserv field "(c0) <-diff". However, cisco suppor the most dscp
modes than altq on NetBSD.

So, I would write new userland daemon wich can be support old version
like cisco(with diff field) and new with e-lsp, l-lsp via TE. E-lsp
and L-lsp are very different, first suppor just 8 class of service and
determine PHB from EXP until 8 per lsp, second most than 8 class of
service and can be support determine PHB from EXP or label and just
one per lsp. Furthermore, i'll be try to do it with support juniper
LDP's, if any body given me dump of the packet specify for same
vendor.


15:38:30.759819 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [none],
proto UDP (17), length 62) 10.10.0.1.646 > ALL-ROUTERS.MCAST.NET.646:
[udp
sum ok]
LDP, Label-Space-ID: 14.0.0.1:0, pdu-length: 30
Hello Message (0x0100), length: 20, Message ID: 0x00000000,
Flags: [ignore if unknown]
Common Hello Parameters TLV (0x0400), length: 4, Flags:
[ignore and don't forward if unknown]
Hold Time: 15s, Flags: [Link Hello]
IPv4 Transport Address TLV (0x0401), length: 4, Flags:
[ignore and don't forward if unknown]
IPv4 Transport Address: 14.0.0.1
0x0000: 0000 0000 0400 0004 000f 0000 0401 0004
0x0010: 0e00 0001
0x0000: 0100 5e00 0002 ca00 02d7 0000 0800 45(c0) <-diff
0x0010: 003e 0000 0000 0111 cee2 0a0a 0001 e000
0x0020: 0002 0286 0286 002a eb33 0001 001e 0e00
0x0030: 0001 0000 0100 0014 0000 0000 0400 0004
0x0040: 000f 0000 0401 0004 0e00 0001
15:38:30.963783 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [none],
proto UDP (17), length 62) 12.0.0.1.646 > 14.0.0.2.646: [udp sum ok]
LDP, Label-Space-ID: 14.0.0.1:0, pdu-length: 30
Hello Message (0x0100), length: 20, Message ID: 0x00000000,
Flags: [ignore if unknown]
Common Hello Parameters TLV (0x0400), length: 4, Flags:
[ignore and don't forward if unknown]
Hold Time: 90s, Flags: [Targeted Hello]
IPv4 Transport Address TLV (0x0401), length: 4, Flags:
[ignore and don't forward if unknown]
IPv4 Transport Address: 14.0.0.1
0x0000: 0000 0000 0400 0004 005a 8000 0401 0004
0x0010: 0e00 0001
0x0000: ca00 02e9 0000 ca00 02d7 0000 0800 45(c0) <-diff
0x0010: 003e 0000 0000 ff11 a0ec 0c00 0001 0e00
0x0020: 0002 0286 0286 002a 3af3 0001 001e 0e00
0x0030: 0001 0000 0100 0014 0000 0000 0400 0004
0x0040: 005a 8000 0401 0004 0e00 0001

Post by Mihai Chelaru

Post by basteon
hi,

Post by Mihai Chelaru
the ldp at least is not fully RFC compliant

Why? In RFC5462 contained information about EXP field(on cisco it like
CoS), it's quality of service stuff switching labels via priority
traffic on top level like udp, tcp, http,... To implement that thing
on NetBSD it's quite hardwork:), I think. Because it needs use
pf-hooks so as to permit label in firewall and altq via queue cbq
frame prioriting. Or you mean something else?

I was stricly speaking about RFC3036, which by the way, got obsoleted by
RFC5036.
--
Mihai Chelaru

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de