Subject: Re: [6lowpan] comments on draft 5

From: gabriel montenegro <[email-masked]>
Date: Fri, 3 Nov 2006 14:52:03 -0800 (PST)

inline marked "gm>" 

----- Original Message ----
From: Geoff Mulligan <[email-masked]>
To: 6lowpan <[email-masked]>
Sent: Thursday, October 26, 2006 11:30:55 PM
Subject: [6lowpan] comments on draft 5

Gabriel,
  First some editorial comments:

Section 3 Paragraph 1 Line 12 - occurred should be occurring

gm> Fixed, thanks.

Section 5.1 Paragraph on datagram_size (page 8): I think that the NOTE:
should read:

While it may appear that this field does not need to be in every packet,
as one could send it with the first fragment and elide it subsequently,
it is included it in every link fragment to ease the task of reassembly
in the event that a second (or subsequent) link fragment arrives before
the first. ...

gm> I don't agree with the"it may appear". It's not just appearance, one can
actually elide it. I have not put in any change here.

Section 5.2: Possible rewrite:

The recipient of link fragments SHALL use (1) ...

gm> Ok, done.

I think that the next paragraph in the text, the paragraph starting with
"Upon receipt" should be removed since this is an implementation choice.

For the same reason and and per the discussion with Phil, I think that
the next paragraph (starting with "If a link fragment") should also be
removed.

gm> Phil and I feel like this is good info to have, but I have made some changes
to try to soften the prescriptiveness of the text, while still leaving in some
info for implementors.

And for the same reason, this is an implementation detail, the paragraph
starting with "Upon detection of a IEEE" should be removed unless there
is a specific reason for the 15 second time out - where did 15 seconds
come from?

gm> I think we found it in someone's hat. You have a point. If we look at 
rfc 2460, IPv6 implements a hard reassembly timeout of 60 seconds.
Since what we at the lowpan level may be transporting could potentially
be an IPv6 fragmented packet, it makes no sense for us to hold on to
our lower-layer reassembly process longer than that. So I've changed
our text to reflect the fact that we recommend some reassembly timeout 
which should not exceed 60 sec.

gm> Since there are several changes to this reassembly section here it is as it looks now after the tentative changes:

5.2  Reassembly

   The recipient of link fragments SHALL use (1) the sender's 802.15.4
   source address (or the Originator Address if a Mesh Delivery field is
   present), (2) the destination's 802.15.4 address (or the Final
   Destination address if a Mesh Delivery field is present), (3)
   datagram_size and (4) datagram_tag to identify all the link fragments
   that belong to a given datagram.

   Upon receipt of a link fragment, the recipient starts constructing
   the original unfragmented packet whose size is datagram_size.  It
   uses the datagram_offset field to determine the location of the
   individual fragments within the original unfragmented packet.  For
   example, it may place the data payload (except the encapsulation
   header) within a payload datagram reassembly buffer at the location
   specified by datagram_offset.  The size of the reassembly buffer
   SHALL be determined from datagram_size.

   If a link fragment is received that overlaps another fragment as
   identified above and differs in either the size or datagram_offset of
   the overlapped fragment, the fragment(s) already accumulated in the
   reassembly buffer SHALL be discarded.  A fresh reassembly may be
   commenced with the most recently received link fragment.  Fragment
   overlap is determined by the combination of datagram_offset from the
   encapsulation header and "Frame Length" from the 802.15.4 PPDU packet
   header.

   Upon detection of a IEEE 802.15.4 Disassociation event, fragment
   recipients SHOULD discard all link fragments of all partially
   reassembled payload datagrams, and fragment senders SHOULD discard
   all not yet transmitted link fragments of all partially transmitted
   payload (e.g., IPv6) datagrams.  Similarly, when a node first
   receives a fragment with a given datagram_tag, it starts a reassembly
   timer.  When this time expires, if the entire packet has not been
   reassembled, the existing fragments SHOULD be discarded and the
   reassembly state SHOULD be flushed.  The reassembly timeout MUST be
   set to a maximum of 60 seconds (this is also the timeout in the IPv6
   reassembly procedure [RFC2460] ).

Section 6: Paragraph 2 Line 6: I'm not sure that the phrase
"concatenated with" is clear as to the ordering.  I'm not sure that
"concatenated to" is precise (as used in the previous sentence).

gm> I had added some illustration of what the result looks like, but perhaps
that is lost in the text. I've now modified to more clearly show this and the
relevant text now looks like this:

   All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short
   addresses (Section 3 and Section 12) are also possible.  In these
   cases, a "pseudo 48-bit address" is formed as follows.  First, the
   left-most 32 bits are formed by concatenating 16 zero bits to the 16-
   bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
   used).  This produces a 32-bit field as follows:

      16_bit_PAN:16_zero_bits

   Then, these 32 bits are concatenated with the 16-bit short address.
   This produces a 48-bit address as follows:

      32_bits_as_specified_previously:16_bit_short_address

   The interface identifier is formed from this 48-bit address as per

Section 10.1: I think that it should be written as:

It is possible to use header compression even in advance of setting up
the customary state.  The following common IPv6 header...

gm> Not sure about this. "in advance" implies we will eventually enter a context-building
phase for header compression. But this is not what we do. We don't have the customary
(for header compression) context-building phase. So "in absence" describes what we do,
I think.

Appendix A Paragraph 1 line 18: frament should be fragment.

gm> Ok, thanks.

Questions:

Section 5.1 Paragraph on datagram_size (page 8): The datagram_size is
set to 40 octets more than the  Payload Length value in the IPv6 header,
but if the IPv6 header is compressed doesn't this lead to the wrong
datagram size calculation?

gm> Ok, added "uncompressed" before "IPv6 header".

Section 5.1 Encapsulation header format (meta question): if we were to
allow multiple mesh protocols under this adaptation layer do we think
that this should be carried in the prot_type field or should we add or
define the "rsv" field for the mesh network type, though 3 bits would
probably suffice or should we add one more byte.  I think that this is
partially what David was asking about.  Having this flexibility might be
especially important to allow for diagnosing the mesh layer.

gm> I think we've already answered this question a while back with the
drafts on DyMO, LOAD, etc. These are protocols that run on top of the lowpan
layer, just like IPv6 itself runs on the lowpan layer. In our  current design,
one runs one protocol at a time on top of the lowpan adaptation layer.
So one would run a mesh routing protocol of choice to set up routes
and populate nodes with the appropriate topological information.
Subsequent to that, any other protocol on top of that adaptation layer
(e.g., IPv6, appletalk, IPv4, whatever) could use the mesh delivery.
The "B" bit and the mesh delivery field are only used for the delivery
of data on a mesh. The control plane for the mesh is determined by prot_type
and is done with any of several mesh routing protocols.

Section 9 about Multicast Address mapping:  Does this preclude a network
from using 64-bit addressing for multicasting?  It seems to indicate
that you must use 16-bit addresses for multicast addresses.

gm> The mesh delivery header for multicast does not preclude that, as it also
includes the "O" and "F" bits to signal 16 or 64 bit address length. So one could
in the future define the mapping from IPv6 multicast to 64-bit addresses, but 
we're not doing that now. This could be a separate document for which I don't
see much urgency in current networks. 

Section 10.2 in the Length (bit 2) paragraph:  can we really compute the
udp length field from the possibly compressed frame length field or the
datagram_size field in a fragment header?  Is this a simple calculation?

gm> The frame length is never compressed. It is part of the layer 2 802.15.4
header which we do not control. The value of the UDP length field is equal
to the Payload Length from the IPv6 header, minus the length of any extension
headers present between the IPv6 header and the UDP header.  I've added this
sentence to clarify.

Section 11 - It doesn't look like we fixed the problem with the sequence
number before the destination address?  Did I miss a different solution?

gm> We added the 'B' bit. The paragraph before figure 10 now has this text,
for example:

   There are two types of Mesh delivery fields: the "Unicast Mesh
   Delivery Field" (Figure 10), and the "Broadcast or Multicast Mesh
   Delivery Field" (Figure 11).  The former is used if the 'B' bit is
   set to zero, and the latter is used if the 'B' bit is set to 1.  The
   'B' bit appears in all variations of the LoWPAN encapsulation header
   (Section 5). 
-gabriel

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

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

---

From: Geoff Mulligan <[email-masked]>
Date: Fri, 03 Nov 2006 16:14:00 -0700

Excellent Gabriel.  Thanks again for taking on the load of continuing to
edit the draft for the working group!

	geoff

On Fri, 2006-11-03 at 14:52 -0800, gabriel montenegro wrote:
> gm> Since there are several changes to this reassembly section here it
> is as it looks now after the tentative changes:
>  
> 5.2  Reassembly
>