* Steven Whitehouse <[EMAIL PROTECTED]> 2006-11-09 14:55 > So here is roughly what I was thinking... this comes from having > spent a little while thinking about the best way to integrate > MPLS into the network stack. An MPLS label is 32 bits in size > which conviently matches the size of the packet mark. > > So one thought was this (for MPLS edge routers). Add the ability to > set a mark to the IP routing table. Something along the lines of: > > /sbin/ip route add 10.1.0.0/16 via 10.2.1.1 dev eth0 setmark 6 > > and then use the mark as the FEC (forwarding equivalence class) > for MPLS (which is just an index, but in simple cases could > contain a whole MPLS label). I was hoping that it might be possible > to use the xfrm infrastructure to deal with the actual application > of MPLS labels, but I'm not yet 100% certain that its a good fit. > > Either way, MPLS will require some kind of way to indicate the FEC > for each route, so using the generic mark like this seems to me > a reasonable solution on the basis that other uses might then be found for > it as well.
Using tc_index might work as well. Anyways, having a route metric which influences the mark and tc_index for packets being routed via said route is certainly a good thing. > Since MPLS labels are only a subset of the full 32 bits, being able > to use a mask in conjunction with setting the mark might also be > a useful feature, so that the logic (pseudo code) after route lookup > might look something like: > > skb->mark &= ~nh->nh_setmask; > skb->mark |= nh->nh_setmark; /* Assume mark only sets bits allowed by mask */ > > The big question being, is this going to be a problem bearing in mind > it would appear in the routing fast path? We probably don't know until we try it. IMHO fast path thoughts should never be a reason to not try and implement something in a clean fashion. There is always ways to optimize things. > On the MPLS input side, packet marks would be set according to the > incoming MPLS label and then work in just the same way that you propose > using the marks to create separate routing for different VLANs for > example. An ingress action which can both translate MPLS labels into a mark or tc_index value should suit us fine. This could be a simple 1:1 mapping or a more complex translation table which can be managed by userspace via netlink. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
