Subject: [6lowpan] comments on draft 5

From: Geoff Mulligan <[email-masked]>
Date: Fri, 27 Oct 2006 00:30:55 -0600

Gabriel,
  First some editorial comments:

Section 3 Paragraph 1 Line 12 - occurred should be occurring

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

Section 5.2: Possible rewrite:

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

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.

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?

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

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

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

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?

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.

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.

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?

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?

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

---

From: "Ron Strich" <[email-masked]>
Date: Fri, 27 Oct 2006 09:07:09 -0500

1. Many sensor and control devices will be too small to support a full
mesh/ip adaptation implementation.  Some of these devices may be as small as
4K of flash and 100s of bytes of RAM and may only be used in a point to
point (P2P), simple star, or very simple mesh implementation (please see the
attached pdf drawing).  Incorporation of these very small devices, I
believe, is important to the broad adoption of 6lowpan.

Should we consider how to support these extremely limited devices?  Should
we make it easy for these simple protocol implementations at this level to
adapt to 6lowpan? If we want to include these small devices, should we
consider a more constrained design (limited payload, P2P/star only) that
would simplify the adaptation layer?

2. How will the group evaluate what mesh, P2P or star protocols should be
supported?  As David pointed out, we may not be allowing for future
capabilities in the current structure of the adaptation layer should we want
to support multiple types of L2 protocols.

3. Related to the pending mesh protocol evaluation, is the evaluation of any
functionality related to the "cost" of those technical choices in terms of
power, code size, complexity, RAM, instructions executed, etc?

4. As was mentioned on the list a while ago, neither the Problem Statement
nor the Format documents discuss the overall 6LoWPAN architecture.  As we
move forward with our next working group items, shouldn't we create a
document to describe the high level architecture which might well encompass
the criteria for evaluation of the protocols and costs mentioned above?

Ron Strich
Mobile: 228.369.4332

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Oct 2006 17:31:07 +0200

Ron,

good input.

Let me just pick up on one of these points:

The IETF is quite wary about "architecture" documents.

(The OSI reference model is the textbook example here:
ISO did an architecture ["reference model"], and then, only when  
defining the protocols, found out that the architecture didn't make  
sense.
But it was too late to fix the architecture, so the bad layers limped  
on until OSI finally died.
The really funny thing, of course, is that, in 2006, people are  
*still* citing the layers of the defunct reference model...)

In the IETF, we tend to standardize functional components and leave  
it to the market how to build "architectures" out of these.
Of course, that is not always possible.
Also, it may be necessary to have an (really: one or more)  
architectures in mind when building components.

So, I'd welcome discussion of architecture(s).  I'm just not sure we  
actually want to "standardize" them.

Gruesse, Carsten

---

From: Philip Levis <[email-masked]>
Date: Fri, 27 Oct 2006 09:00:49 -0700

> the next paragraph (starting with "If a link fragment") should also be

I'd differ on this one; it's good to describe what to do in error  
conditions without constraining the implementation unduly. Otherwise  
adversaries can profile your device based on its responses. That  
being said, it's really not a big deal, and so if nobody else feels  
strongly in this direction I have no objections to removing the  
paragraph.

Phil

---

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 30 Oct 2006 13:41:11 +0900

Carsten, 

I think it's a good concern especially from the implementation
prespective. Even it seems not scope of 6lowpan standardization
itself, I think we can input this concern to the relevant place, 
v6ops (IPv6 operations) working group in conjunciton with
6lowpan coordination in my mind.

Anyhow, I'd encourage Ron to continue this thread
on this list if we don't see any critical objection.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.