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”
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).
* 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.
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?
The required work includes items in the following (incomplete) list:
* Addressing schemes and address management
* Network management
* Routing in dynamically adaptive topologies
* Security, including set-up and maintenance
* Application programming interface
* Discovery (of devices, of services, etc)
* Implementation considerations
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.
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.
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?
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.
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.
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?
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
