Re: [6lowpan] Datagram tag size (draft-ietf-6lowpan-format-00a.txt)

[Vipul Gupta <[e-mail]>]

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
no place in the 802.15.4 header to describe the higher
protocol type (ethernet, in contrast, does have such a
field).

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).

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
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).

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.

vipul

On Oct 23, 2005, at 1:40 PM, gabriel montenegro wrote:

> Hi Samita,
>
> --- Samita Chakrabarti <[e-mail]> wrote:
>> I am not quite clear on the need of version for lowpan layer ; how 
>> are other
>> ipv6 over protocol foo defined in this respect?
>
> Good question, you might want to look over those specs, but I don't 
> recall
> ever seeing a version number. If a future rev of 15.4 (e.g.,
> 15.4-on-steroids) ever makes it obvious that a new adaptation layer
> is needed, then instead of handling this via version numbers on the
> current spec, one could simply issue another document specifically
> for 'IP-over-15.4-on-steroids". Achieves the same thing without wasting
> bits on version numbers.
>
>> Also,  datagram tag size  increament  to 16bits does not seem to be a
>> clear need to me.  I am not sure if  there is a need for  
>> fragmentation
>> tax. Today folks run IP datagram over 10Gb/s ethernet, but  IP
>> identification
>> fileld size is not changing.
>
> Good point, I don't see a need for this to grow much either.
>
>> We need to be very sure that the datagram tag
>> rollover is an issue before  increasing  bit numbers in the lowpan 
>> header.
>
> This is the main issue, yes, let's not get too aggressive on 
> over-engineering
> in advance.
>
>> BTW,  currently protocol field is 11 bits - we should reduce that 
>> number
>> to 8 bits.
>
> Ok, let's do this.
>
>> We may want to use 1 bit  (8bit +1)  in highest order bit, to
>> indicate
>> private or standard protocol-type if  folks think that might be 
>> useful.
>
> I don't think this is useful. Private or proprietary encapsulations 
> are the
> majority (and will continue to be so according to some folks) and 
> these precisely
> couldn't care less about interoperability with anybody cuz they have 
> their own
> isolated network. This bit would remain unused.
>
> As for interoperability with zigbee, I'm thinking that the fact that 
> most of these
> applications will (hopefully) use some link-layer (15.4) security, 
> means that as long
> as you don't use the same keys for both lowpan and zigbee, you won't 
> even get a chance
> of being confused. This multiplexing will be achieved by traffic 
> separation due to
> different
> keying. So I'm thinking that there isn't much to do here either.
>
>> IMHO, we need more discussion and input from folks before changing
>> the tagsize to 16bits. My recommendation would be to start with  the 
>> current
>> size and change later if needed based on implementations input , ie, 
>> when
>> we have more experience with IPv6 over lowpan.
>
> Looking at the previous proposed formats I sent on this thread,
> how about using the 2 bits from the "Ver" field and assigning them to
> the tag size (to grow it from 8 to 10 bits)? This is what I propose:
>
> prot_type: 8 bits
> datagram_size: 11 bits
> datagram_tag: 10 bits
> datagram_offset: 8 bits (offsets expressed in increments of 8 octets)
>
> Format 1 (unfragmented):
>                         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| rsv     |Payload (or Mesh Delivery Hdr)...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Format 2 (first fragment):
>                         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      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Payload (or Mesh Delivery Hdr)...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Format 3 (middle or last fragment):
>                         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      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | Payload (or Mesh Delivery Hdr)...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> This is what I'll put into the draft before submission, unless I hear
> strong opposition, ok?
>
> -gabriel


_______________________________________________
6lowpan mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/6lowpan