Subject: [6lowpan] WG last call on Use-Case draft document

From: Geoff Mulligan <[email-masked]>
Date: Tue, 01 Sep 2009 18:18:59 -0600

Folks,
  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-usecases-03.txt, "Design and Application Spaces for 6LoWPANs".

The document can be found at:
http://www.ietf.org/id/draft-ietf-6lowpan-usecases-03.txt

The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

This Last Call will end on Thursday 1 October 2009 at 2359 UTC.

        Thanks,
                Geoff & Carsten

---

From: Daniel Park <[email-masked]>
Date: Wed, 2 Sep 2009 18:59:46 +0900

I support this document to be moved forward...Well organized and written.

Thanks all author of document...

Daniel

On Wed, Sep 2, 2009 at 9:18 AM, Geoff Mulligan <[email-masked]> wrote:

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

-- 

Soohong Daniel Park
Standard Architect, http://blog.naver.com/natpt
DMC Business, Samsung Electronics, KOREA

NOTE: 본 메일은 Gmail에서 발송되었습니다

---

From: Jung-Soo Park <[email-masked]>
Date: Thu, 3 Sep 2009 02:33:34 +0900

I support this document to be moved forward.
Thanks for all authors of this document.

Jungsoo

-- 
JungSoo PARK
-----------------
u-Infra Standardization Team
Electronics and Telecommunications Research Institute (ETRI), Korea
Tel:+82-42-860-6514, Fax:861-5404
MSN: [email-masked], E-mail : [email-masked]

---

From: Kris Pister <[email-masked]>
Date: Wed, 02 Sep 2009 10:59:15 -0700

Eunah et al.
I would be much happier with this document if star-connected nodes were 
the exception rather
than the rule.  Can we add some more links in there so the reader will 
get used to the idea of meshes rather than trees?  Most people who have 
done commercial deployments will tell you that stars and trees are 
lethal for reliability.  As far as RFD vs. FFD goes, does anyone even 
make an RFD?

I'd also recommend an update to the "typical characteristics" in section 1.
* Under "low power" you're mixing RF transmit power ("up to 1000mW") and 
radio power consumption ("between 10 mW and 20mW").  Also, there's 
exactly one 802.15.4 radio that falls into that range (the DN2510).  The 
rest are all substantially higher.
* The specs on memory and processor horsepower are from the golden age 
of academic wsn research, and are almost a decade out of date.  Look at 
what Freescale, Atmel, Jennic, etc. are shipping in volume.  They are 
32-bit cores (typically ARM7) running at tens of MHz, with tens of kB of 
RAM.

Section 3:
* Connectivity: I disagree with the association of "sleeping mode" with 
"intermittent" connectivity.  There are many L2 protocols that allow 
tradeoffs between duty cycle and link BW.  I would not call those nodes 
that sleep >99% of the time intermittent - they just have lower 
effective bit rate links.  In particular, reading down in 4.1.1 the 
description of industrial monitoring connectivity as "always on for 
crucial processes, otherwise intermittent" does not fit with what's 
happening in the real world, and would tend to mislead someone not well 
versed in the field.
* "several traffic patterns may be overused in LoWPANs" - overused?
* "primordial" - I've seen networks like this, but I don't think that's 
what you really mean

4.1.2 Figures 4 and 5
You confuse "mesh" with "multi-hop" in your captions.  Figure 5 has no 
meshing at all.  maybe keep the caption, and put in some real meshing?
Same thing for figure 6 and 7.  I strongly disagree with the statement 
in 4.2.1 that this would work with a star topology, or a hierarchical star.

4.2.1
* "The network configuration and forwarding/routing tables are changed 
only in the case of node failure".
Huh?  Forwarding/routing tables will be updated *regularly* in a network 
like this due to connectivity changes.  The RF environment is not 
static, even on a 'static' structure like a bridge, and even with line 
of sight.  Every piece of metal on a bridge looks like a mirror to RF, 
and all of the mirrors move a little.

Overall, I'm concerned that this document does not feel to me like it 
embraces the practical knowledge from real world deployments from *many* 
different companies using *many* different protocols.  Did you talk to 
Arch Rock, Control 4, Dust, Ember, Emerson, Streetline, ...?  We're not 
in the academic phase anymore - we've actually got lots of real-world 
data now, and much of it seems to be at odds with what's in this document.

ksjp

---

From: "Carl Williams" <[email-masked]>
Date: Wed, 2 Sep 2009 14:13:51 -0400

Kris,

 Archrock was at the many many meetings that this document was presented
over the past several years so they had many opportunities to make comments
and did.  The document is in LC.  

Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Kris Pister
Sent: Wednesday, September 02, 2009 1:59 PM
To: Geoff Mulligan
Cc: 6lowpan
Subject: Re: [6lowpan] WG last call on Use-Case draft document

Eunah et al.

Section 3:

4.1.2 Figures 4 and 5

4.2.1

ksjp

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 2 Sep 2009 13:45:53 -0700

> and did.  The document is in LC.

The point of LC is to attract greater attention before the draft is  
submitted to the IESG for review.  Kris is putting forward useful and  
constructive comments - many of which I have to agree with.  I'm sure  
there are others that have not been able to provide their feedback as  
well.

As for my feedback:

- Section 1: Need an update w.r.t. common hardware capabilities.

- Section 1.1: It's more accurate to say that networks are comprised  
of routers and hosts.  Whether those hosts attach to a single router  
at a time depends on the implementation, and it's unclear to me  
whether attaching to 1 is more common than attaching to a few.  What  
is common is that many networks are comprised of only routers.  I'd  
also suggest changing the node-type terminology.  For example, I'd  
prefer that *all* LoWPAN nodes in a mesh-under configuration should be  
called LoWPAN Hosts - none forward IP datagrams, but some forward  
6LoWPAN frames.  The terminology as shown in Figure 3 apply the same  
terms to both L2 and L3.

- Section 1.1: Short address assignment does not have to be done by an  
802.15.4 coordinator - 6LoWPAN ND provides a mechanism to assign them  
as well.

- Section 3:
   - Power Source may include energy-harvesting as well, which have  
different characteristics from mains and battery-powered.
   - Connectivity should also include highly varying bit-rates due to  
differences in L2 duty-cycling settings.
   - Multi-hop communication is required in star as well.
   - Traffic patterns - avoid the word "overused"

- Section 4.2.2: Can you clarify a bit more why nodes do not need to  
obtain globally unique addresses?  Is each "star network" operating a  
private IPv6 network with it's own "star network"?

It is mentioned many times in the doc that 64-bit link addrs are  
preferred because they are better handled in the new HC, but HC is  
designed to handle both 16 and 64-bit addrs - arguably 16-bit addrs  
allow for more efficient header compression.

It is mentioned many times (e.g. Sections 4.1.2, 4.2.2, 4.3.2, 4.4.2,  
4.5.2, 4.6.2) that link-local IPv6 addresses may be used when not  
communicating outside the LoWPAN - in a route-over configuration,  
you'll need routable addresses to communicate with other LoWPAN nodes  
not reachable over a single radio transmission.

In those same sections, it is mentioned many times that a 16-bit  
address can only be used within a singe link-local scope.  I don't see  
why this is a fundamental limitation.  The current 6LoWPAN ND draft  
provides for unique 16-bit address assignment over an entire LoWPAN  
network - route-over or mesh-under.

I think there are enough technical issues here that the draft requires  
a new revision.

--
Jonathan Hui

>> draft-ietf-6lowpan-usecases-03.txt, "Design and Application Spaces  
>> for
> 6LoWPANs".
>>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 03 Sep 2009 15:49:33 +0100

A couple of minor comments in addition to Jonathan's and Kris' comments:

Section 1:

"Low bit rate: the IEEE 802.15.4 standard defines a maximum over-the-air
rate of 250 kb/s, as well as lower data rates of 40 kb/s and 20 kb/s for
each of the currently defined physical layers (2.4 GHz, 915 MHz and 868
MHz, respectively)."

Not for 802.15.4-2006 - there are higher bit rates in the sub-GHz bands
---
"Through their inability to transmit MAC layer beacons, RFDs can only
communicate with FFDs in a resulting "master/slave" star topology."

This isn't actually the case. There is a distinction between the
implicit tree topology for network membership implied by 802.15.4
through the beacon/association mechanisms and actual topology formed by
data communications. RFDs can transmit peer-to-peer providing they have
joined through an FFD, assuming use of 802.15.4 network membership
mechanisms, which aren't strictly necessary. I would generally avoid
mentioning FFD and RFD.
---

Robert

Robert Cragie, Principal Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Mon, 7 Sep 2009 23:28:17 +0900

Dear Kris, Jonathan, Robert,

Thanks for all your valuable comments.
Comments from industries are really appreciated, as i always asked
whenever i presented the documents.
I'm now quite tied-up by other meeting in Argentina,
so i will update the document applying the comments as soon as I
return back (next friday).

I also appreciate Daniel, Carl, Kihyong, Jungsoo, Hamid, Saif, and
other 6lowpaners who sent the support.

Thanks,
-eunah

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 7 Sep 2009 19:26:53 +0200 (CEST)

Hi all,

I support moving forward the document.

Regards,

Carles