IETF 69 charter discussion
At IETF 69, the contents of the charter proposal for phase 2 of the working group was finalized. See FrontPage for a first summary.
IETF 65 charter discussion
During the 6lowpan interim meeting in January 2006, the working group discussed possible topics for a future rechartering of 6lowpan.
The following text, which is an edited version of the scope present in the current 6lowpan charter, is based on available information from that meeting and feedback on the mailing list.
In the following list, there is a prioritization that is intended for discussion only; the final charter will just list the items. Also, the names given are just for discussion now and will go away in the charter, of course.
Please feel free to add your topics, but not all of them will make it into the final charter (we need to stay focused!).
--- start of scope ---
Scope of 6lowpan:
High-priority items
Produce "Optimization of the Neighbor Discovery Protocol for 6lowpans" to define how to apply the existing Neighbor Discovery protocol in a 6lowpan. ((draft: Erik/Samita))
Produce "Problem Statement for Stateful Header Compression in 6lowpan" documenting issues with using ROHC, RFC 2507, etc. in a 6lowpan. ((draft: Carsten, Daniel, Kim)) (Any actual specification work is then perhaps done in another WG.)
Produce a problem statement (also covering applicability of existing protocols) leading to "Recommendations for 6lowpan Applications", covering:
- Recommendations for transport (e.g., TCP) usage in 6lowpan ((draft: Geoff/Michel))
- Recommendations for application layer protocol (e.g., SNMP) usage in 6lowpan ((draft: Geoff))
- Giving structure to applications ((draft: Kim, Samita)):
- Service Discovery and application configuration, to define how to discover, control and maintain services provided by 6lowpan devices.
- Installation ("commissioning" or "provisioning")
- Application layer naming/name resolution
More ambitious items
Produce "Optimization of an Ad-Hoc Routing Protocol for 6lowpan Mesh routing" to apply an existing MANET Protocol to LoWPANs. ((draft: Daniel/Kim, maybe Ian))
Also, the issue of the content of 802.15.4 Beacons came up, also in relationship with 802.21 and DNA ((draft: Daniel, Geoff))
Items for which there is considerable interest
Produce "6lowpan Security Analysis" to define the assumptions for a security model for 6lowpans. This includes analysis of threats, identify types of devices and define the levels of trust between these devices. ((draft: e.g., Vipul, Daniel, Carsten))
This may later lead to work on "key management for 15.4 security", listing recommended practices in this space (ciphersuites etc.). One focus will be on managing the 6lowpan as a group, not so much individual associations.
Items that probably can't be done in the current round
Produce "6lowpan Co-existence and interference management with other Networks" to define how to co-exist with other networks. This includes analysis of how to survive interference caused by IEEE 802.11 based networks, and investigate how to recognize and co-exist with other networks based on IEEE 802.15.4. ((draft: Alex, Geoff))
Other items, such as "Mobility" ((draft: Samita)), "Performance optimization for reassembly in a mesh" ((draft: e.g., Nandu, Michel)), structural issues such as Scalability (scalable routing, scalable addressing, naming, etc.), Naming for mesh layer (assignment of addresses of different sizes, name lookup issues), gateway Architecture between 6LoWPAN and external IPv6 networks.
--- end of list still to be worked on ---
The working group will reuse existing specifications whenever reasonable and possible.
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.
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.
--- end of scope ---