On Sep 18, 2010, at 02:22, JP Vasseur wrote: > > On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote: > >>> Has anybody discussed adding a header with just the 3 bytes you need >>> *before* the IP header? >> >> Yes. Ever since you proposed pretty much that at a previous IETF meeting, >> I've been thinking that architecturally it makes a lot of sense to think >> about ROLL as a sub-IP protocol. > > Architecturally RPL is not a "sub-IP" protocol,
You are right, I was too terse: it contains one. Architecturally, the instance-id acts a lot like a VLAN tag, and the rank is something that happens "alongside" IP forwarding -- whether that's below, above, or sideways depends on your vantage point. But we probably don't need to discuss the fine architectural points here. (After thirty years, I'm a bit tired of trying to compress complex reality into "layers".) My point is not about labelling RPL as anything, but about making use of knowledge we already have. Erik's comments have been pretty eye-opening here for me. >>> The downside is that you need a new code point (for demux) in the different >>> layer2s that you want to run this on. >> >> And that is exactly the non-starter about the general proposal. >> It is not acceptable to require a new spec for each of the many link layers >> we want to run ROLL on, in particular for those who don't really care that >> much about the overhead. >> >> However, it would be pretty easy to put something in 6lowpan to carry those >> 3 bytes. >> (Consider it an advanced form of header compression for the 48-byte IP-in-IP >> thing, if you don't like the sub-IP thinking.) >> Consult http://tools.ietf.org/html/draft-bormann-6lowpan-ext-hdr-00 for a >> sample base design. >> Such a simple extension may actually be a preferable way to carry ROLL in >> 6lowpan. > > "preferable" in which sense ? In the sense of good performance and minimal impact. Again, just think of it as a 6lowpan-optimized form of header-compressing the 56-byte*) IP-in-IP/extension-header wrapper that other link layers will happily carry. Gruesse, Carsten *) (Note that 6lowpan-HC as is will probably already compress that wrapper to approximately 14 bytes -- I haven't done a fully worked example yet, though, as the RPL option processing is not yet fully defined, and there is a lot of complexity to get down to those ~ 14 bytes.) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
