On Sep 2, 2009, at 11:13 AM, Carl Williams wrote:
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.
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
Carl
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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.
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
Geoff Mulligan wrote:
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
