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 <[EMAIL PROTECTED]> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
