--- Vipul Gupta <[EMAIL PROTECTED]> wrote:
> Given that IPv4 has managed to do fine with a

I wouldn't necessarily say that IPv4 is fine with only 16 bits.
This is a known issue. See for example:

http://www.watersprings.org/pub/id/draft-mathis-frag-harmful-00.txt

And some updated discussion in the context of tunnels in:

http://www.ietf.org/internet-drafts/draft-savola-mtufrag-network-tunneling-05.txt

> 16-bit identifier, I'd say this size represents a
> reasonable compromise.

16 bits would buy us over a minute at 1Mbps (dunno if this is a possible rate
in the future, though). For comparison, RFC 1122 (3.3.2  Reassembly) requires 
that the IPv4 reassembly timeout be between 1 and 2 minutes. Not sure what is
reasonable for us to drive for. 

Given that these puny devices have to put out all that traffic, do we 
understand the
system implications of such a feat? How reasonable is it to expect the required 
buffer
space, bus bandwidth (I2C, etc) on these platforms to sustain that level of 
offered 
traffic? Of course, one can always 15.4-enable a regular computer, in which case
such sustained throughput is not an issue. However, I wouldn't know the 
difference
between this scenario and a "denial of service" attack...

Frankly, I don't loose much sleep over this, and would be fine even at less 
than 
16 bits. For example, even if 1 Mbps were possible with 802.15.4a (my guess
is that we won't have that) it would represent 512K max, by the same reason 
that 
802.15.4's "250Kbps" becomes a max (perhaps unattained) of actual 128Kbps on 
the wire, 
If so, 15 bits is fine and would give us over a minute before rollover at 512K.

If we just look at the packet formats, and extrapolate, here's an example of 
what
one might end up with:

Format 2:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|      prot_type      |M|   datagram_size     |datagram_tag |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | datagram_tag  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Format 3:
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LF|   datagram_offset   |M|   datagram_size     |datagram_tag |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | datagram_tag  | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What do folks think?

We haven't discussed at all about alignment issues (perhaps a discussion
to have with respect to IPv6 header alignment requirements, implications
and what we wish to do about it), but the above keeps
an octet alignment. Typical radio chips will read in min 1 octet most
probably 2 octets at a time, I believe.

Comments?

-gabriel



_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan

Reply via email to