Vipul, --- Vipul Gupta <[EMAIL PROTECTED]> wrote: > If we assume that the LowPAN design this group comes up > with will only need to be revised when a new lower layer > is designed, then yes there is no need for version numbers. > > However, if there's even a small chance that, based on > deployment experience, we may revise the LowPAN > header format while still wanting to run it on top of the > same lower layer then I don't see how the recipient > would figure out how to interpret the received packet > without a version number. From what I can tell, there is
Yes, there is that risk. I guess the more complex an encapsulation, the more justifiable it is to have a version field. > no place in the 802.15.4 header to describe the higher > protocol type Correct, 802.15.4-2003 does not. But as an 802 technology, you're supposed to use 802.2 LLC (section 5.3 in the 15.4 spec), which we've abandoned because of its overhead. Instead, we provide our own protocol field within the lowpan layer. > (ethernet, in contrast, does have such a > field). Well, the 802.3-2002 spec talks about a Type/Length field. When one uses the "ethernet II" frame format, this field is interpreted as "Type", so what you say is true. But when you use the other available formats (802.3, 802.2 LLC, SNAP/RFC1042) then this field is interpreted as "Length". In these cases, the ethernet frame does not have such a type field, and this is left to the higher layer encapsulation, e.g., 802.2 LLC or the LLC-derived SNAP encapsulation. Notice that none of the basic ethernet frame, LLC or SNAP have a version field. Our LoWPAN encapsulation is somewhat similar in function to the 802.2 LLC. It is a bit more complex. A much closer analogy is the encapsulation format defined in section 4.2 of the "IPv4 over IEEE 1394" (RFC 2734) spec (not suprisingly, as this was the model for our adaptation layer at the start). Again, this encapsulation does not have a version field either. So I wonder, if a version field was deemed superfluous for all the above encapsulation formats (which did not have the stringent constraints we do), why would it be justified in our case? Our complexity is similar to that of the encapsulation for IEEE 1394. One thing we do in addition to what they do is have a mesh header. Is this additional complexity enough to justify adding a version header? > Perhaps the following example will make things clearer. > Because SSL includes a version number, the IETF was > able to define TLS and now TLS 1.1 without requiring > a new underlying protocol (all versions of SSL and > TLS run atop TCP). Like I said, the more complex an encapsulation, the more chances you'll want a version field in there. For higher layer protocols like HTTP, TLS/SSL, SSH, etc, you definitely want one. No question there. But protocols at those layers are hardly applicable to what we're doing. When I look at what I believe is applicable (frame formats as discussed above), I have not seen version numbers. Perhaps we've just added enough complexity to just tilt the balance enough that we should use one. Not sure yet. I'd certainly like to hear from implementors and people deploying this stuff. I didn't add the version field before this submission cuz I think we need more discussion (and frankly, cuz I didn't have time). Let's discuss some more. > It seems like a prudent tradeoff to me to spend 2 bits > for the ability to later revise LowPAN (based on deployment > experience) without requiring a new lower layer. > > As for the tag size, I think 7 bits is still too low (based on > the previously posted analysis). If the general consensus That analysis is a theoretical one. I'm quite unconvinced that we'll ever hit this in practice given the type of applications that 15.4 is for (after all, the max frame size is remarkably puny). I think before over-engineering this is one point that requires input from folks actually deploying (hopefully comercially) 15.4 networks. > is to bump it to 10 and wait for deployment experience > before changing it to a higher value, that's fine (at current > data rates, 10 bits would allow for a reassembly timeout of > around 8 seconds which might be ok). >From RFC 2734 I note that the 1394 encapsulation uses a datagram tag length of >16 bits. Comparing with the lowest speed or 100Mbps in RFC 2734 (with an MTU of 512 octets), it seems like there's a factor of slightly under 2^8 as compared to 802.15.4's expected max throughput of 125Kbps at 128 octets MTU. If so, and given that 1394 is *MUCH* more probable to transfer long packets than 802.15.4, I'd say for us a datagram tag of 8 bits is at least equivalent (and in reality much safer, given expected usage) than their 16 bits. In keeping with this reasoning, and if we determined that a version field was useful, I'd suggest taking 2 bits from the tag (bumping it down to 8 bits as per the previous paragraph). > In terms of saving bits, supporting short addresses > provides the biggest bang for the buck -- instead > of carrying two 8-byte addresses across each hop > (for a multihop pkt), carrying two 2-byte addresses > saves 96 bits. Compared to this, the extra few > bits spent on the version or the tag are minuscule. Agree, small addresses are the best bang for the buck. The latest version of the draft supports these. But I don't think we can claim that by doing so we are being particularly good citizens. This is a savings enabled fundamentally by the 802.15.4 spec regardless of us. On the contrary, *not* supporting short addresses would have made us bad citizens. We only become good citizens by being careful about the stuff we are adding. That stuff is the fixed overhead in the encapsulation formats. The first version had very little overhead, and we've been growing it slowly. -gabriel _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
