Hi Geoff and Mark,
Some overdue comments/feedback in line.
On Jun 25, 2007, at 1:45 PM, Mark Townsley wrote:
Geoff Mulligan wrote:
6LoWPAN group,
It would appear that we have consensus on the work items for the
working group rechartering - the following 5 topics have been
relatively
unchanged for months.
As I have been working with folks that are implementing 6LoWPAN
and from
some of the messages on the list I have realized that we should
probably
be focused on those topics that are necessary to resolve for
interoperability between implementations. Some of the 5 items
here are
targeted to this and some of the topics mentioned on the list,
such as a
standard/defined MIC could fall under one of the topics.
- “6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations”
- “Problem Statement for Stateful Header Compression in 6lowpans”
- “Recommendations for 6lowpan Applications”
- “6lowpan Mesh Routing”
- “6lowpan Security Analysis”
Few comments here:
6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations:
JP> Yes.
“Problem Statement for Stateful Header Compression in 6lowpans”
JP> Yes.
“Recommendations for 6lowpan Applications”
JP> Do you mean applicability statement ? In this case, in strong
support.
This is one of the missing pieces particularly important to show that
PAN
can be implemented on IP. Note that there are many other pieces that
must
first be worked out (security, management, routing, ...) before we
will be able
to produce applicability statement but would be good to have it in
the charter
indeed.
“6lowpan Mesh Routing”
JP> One of these "hot" topic. And of course, the main question will
to be
discuss whether Mesh-under routing is required if Route over is
available.
In particular, open questions are "If we claim a need for a mesh
under routing,
does that mean that we'll see a plethora of IDs showing how to adapt all
protocols (e.g. MANET) used in a 802.15.4 environment ?"
“6lowpan Security Analysis”
JP: All for it. We are starting some work on RSN to address that
particular issue
from a routing standpoint we clearly this is a key item of the WG.
Yes we still hear
people promoting proprietary standards because they think that this
is provides
a high degree of security.
I would propose to add "Management": in most PANs we do expect a high
number
of devices requiring self-management, so I think that this should be
listed at a
WG item.
And the final one is "Service discovery"
I have attached a proposed new charter for the working group.
geoff
---------------------------------------------------------------------
---
Background/Introduction:
Well-established fields such as control networks, and burgeoning ones
such as "sensor" (or transducer) networks, are increasingly being
based on wireless technologies. Most (but certainly not all) of these
nodes are amongst the most constrained that have ever been networked
wirelessly. Extreme low power (such that they will run potentially
for
years on batteries) and extreme low cost (total device cost in single
digit dollars, and riding Moore's law to continuously reduce that
price point) are seen as essential enablers towards their deployment
in networks with the following characteristics:
* Significantly more devices than current networks
This statement seems a bit dubious to me. More devices than what
"current" networks? And, what exactly is the limit of a "network"
in this statement (the Internet is a network, for example, and I
don't think you are building anything larger than the Internet
itself).
Indeed, and it depends on what we mean by "larger" but at least we
can safely
refer to a potentially large number of devices per square foot with
densely
connected devices.
* Severely limited code and ram space (e.g., highly desirable to
fit the required code--MAC, IP and anything else needed to
execute the embedded application-- in, for example, 32K of flash
memory, using 8-bit microprocessors)
* Unobtrusive but very different user interface for configuration
(e.g., using gestures or interactions involving the physical
world)
* Robustness and simplicity in routing or network fabric
This is a bit of a platitude, and why *or* here?
A chief component of these devices is wireless communication
technology. In particular, the IEEE 802.15.4 standard is very
promising for the lower (physical and link) layers. As for higher
layer functions, there is considerable interest from non-IETF groups
in using IP technology. The working group is expected to coordinate
and interact with such groups.
Which groups ? Are you referring to official liaisons with non
official SDO ?
The working group has completed a problem statement/requirements RFC
and and adaptation layer (IPv6 over 802.15.4) RFC. The working group
Double "and"
has as its main objective to complete those topics and areas
necessary
for successful implmentation interoperability.
What do you mean by "complete those topics"? Continue to advance on
the standards track?
I guess that stands for "start working on several missing pieces" ?
The required work includes items in the following (incomplete) list:
* Addressing schemes and address management
* Network management
* Routing in dynamically adaptive topologies
Of course we need to be more specific here: under-mesh ?
* Security, including set-up and maintenance
* Application programming interface
We should then explain what this means since this is typically a topic
what could meant very different things ...
* Discovery (of devices, of services, etc)
* Implementation considerations
You mean implementation considerations.
Looks to me that the number of topics is really large without sufficient
description for each of them.
Whereas at least some of the above items are within the purview of
the
IETF, at this point it is not clear that all of them are.
Accordingly,
the 6LoWPAN working group will address a reduced, more focused set of
objectives.
I think the above list raises more questions than it answers. When
I read it, I immediately ask "who is doing all this work? Should we
liaise with someone on it? is it possible to have interoperable
implementations without addressing all of these items? What else is
left? etc." Rather than try and capture the entire landscape in an
incomplete list, let's focus the charter on two things (1) What the
6lowpan group is going to do, and (2) any *important* things that
this WG is *not* going to do. For the latter, any pointers to other
WGs, SDOs, etc. would be welcome.
AD's call but I do concur.
Scope of 6lowpan:
1. Produce “6lowpan Bootstrapping and 6lowpan IPv6 ND
Optimizations”
to define the required optimizations to make IPv6 ND applicable in
6lowpans, given the fact that IPv6 ND is too expensive for the
devices
of 6lowpan and requires multicast.
Do we have consensus that ND is too expensive? If so, great, but I
want to be sure.
I'm not so sure ... shouldn't we conduct some careful analysis first
and just
indicate the WG item with no conclusion at this stage ?
Secondly, do we have consensus that ND is required? If 6lowpans
have their own built-in address resolution due to the way addresses
are managed, what aspects of ND are necessary?
This document will define how to
bootstrap a 6lowpan network and explore ND optimizations such as
reusing the 802.15.4 network structure (use the coordinators), and
obviate multicast by having devices talk to coordinators without
creating a single point-of-failure, and changing the IPv6 ND
multicast
semantics. This document will be a proposed standard.
This work item needs to be a little more crisp. Is this
"Bootstrapping" or "ND" or both? If both, are we making the
assumption that ND is the Bootstrapping method, but that it needs
to be changed to work in a lowpan?
Got the same questions.
2. Produce “Problem Statement for Stateful Header Compression in
6lowpans” to document the problem of using stateful header
compression
(2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of
stateless header compression given the assumption that stateful
header
compression may be too complex. This document will determine if the
assumption is correct and will be an informational document.
For the last sentence "The WG will determine if the assumption is
correct at this time and record the findings in this informational
document."
3. Produce “Recommendations for 6lowpan Applications” to define a
set of recommendations of protocols to use for applications. The
recommendations will cover protocols for transport, application
layer,
discovery, configuration and commissioning. This document will be an
informational document.
Can we be specific as to which protocols will be covered? This
seems very open-ended.
Do we want to really provide recommendations or applicability
statements ??
Also recommendations for configuration, commissioning and application
layers
seem a bit out of the scope.
4. Produce “6lowpan Mesh Routing” to evaluate different mesh
routing
protocols for use within 6lowpans. While most routing protocols are
defined above the IP layer, 6lowpan requires a mesh routing protocol
below the IP layer. “6lowpan Mesh Routing” may be several proposed
standard documents.
I think we need to be sure that the line between this and the "RSN"
effort that is spinning up is clear. Also, nailing down which PS
documents will be necessary would be a very nice thing to do.
Indeed + first agree that a Mesh under solution is indeed required. I
know
that this is likely to provide reactions but fair to ask at this point.
5. Produce “6lowpan Security Analysis” to define the threat
model of
6lowpans and to document suitability of existing key management
schemes and to discuss bootstrapping/installation/commissioning/setup
issues. This document will be an informational document.
And you will need a security area adviser appointed for this. When
the time comes we will need to ask the secdir to appoint someone.
The working group will reuse existing specifications whenever
reasonable and possible.
s/specifications/protocols and mechanisms
The working group will also serve as a venue for ongoing discussions
on other topics related to the more complete list outlined above.
Additional related milestones may be added in the future via a
rechartering operation.
Not sure this is good advice. You already have a big chunk of work
to chew on. If discussion naturally ends up on this list for other
work, that's fine, but I don't see why it needs to be listed in the
charter as specifically allowed.
Note: As may be obvious from its official name above, this particular
working group will not work on IPv4 over IEEE 802.15.4
specifications.
Given the limitations of the target devices, dual-stack deployments
are not practical. Because of its higher potential for header
compression, its support for the huge number of devices expected and
of cleanly built-in features such as address autoconfiguration, IPv6
is the exclusive focus of the working group.
I understand keeping IPv4 out of scope for within the lowpan, but I
do think it is important to write a recommendation for the 6lowpan
communicating on the Internet at large, in particular the IPv4
Internet. Thoughts on this?
Oh yes ! Would be happy to help there.
Still, I think that it would be nice to have at some point an open
discussion on why NOT
IPv4, not pushing for anything here ... but having a "documented"
discussion would I think
be helpful.
Cheers.
JP.
Thanks,
- Mark
---------------------------------------------------------------------
---
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
