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
