Differences between revisions 2 and 3
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
Produce "Optimization of the Adhoc Routing Protocol for 6lowpans"
to apply an existing MANET Protocol to LoWPANs.
''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.''
Line 16: Line 18:
Produce "Optimization of the Neighbor Discovery Protocol for 6lowpans"
to define how to apply the existing Neighbor Discovery protocol in a
6lowpan.
== High-priority items ==
Line 20: Line 20:
Produce "IPv6 over Low Power WPAN Security Analysis" to define the
assumptions for a security model for 6lowpan. This includes analysis
of threats, identify types of devices and define the levels of trust
between these devices.
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))
Line 25: Line 24:
Produce "6lowpan Co-existence 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.
Produce "Problem Statement for Stateful Hdr Compression in 6lowpan" documenting
issues with using ROHC, RFC 2507, etc. in a 6lowpan. ((draft: Carsten, Kim))
(The actual specification work is then perhaps done in another WG.)
Line 30: Line 28:
Produce "Service Discovery Protocol for 6LoWPAN" to define how
to discover, control and maintain services provided by 6lowpan devices.
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
Line 33: Line 38:
Produce "Scalability of 6LoWPAN" to define a routing protocol
for the lare number of devices which is expected to be deployed in
6LoWPAN while considering the limited capabilities of the devices
(low power, limited memory space, and small packet size).
== More ambitious items ==
Line 38: Line 40:
Produce "Interoperability of 6LoWPAN" to define the gateway 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 Beacons came up, also in
relationship with 802.21 and DNA ((draft: 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 lead to a draft 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
Line 41: Line 74:
As such, the working group may also work on informational documents for
mobility issues and naming service for mesh layer.
--- end of list still to be worked on ---

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.

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:

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.

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 Hdr Compression in 6lowpan" documenting issues with using ROHC, RFC 2507, etc. in a 6lowpan. ((draft: Carsten, Kim)) (The 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 Beacons came up, also in relationship with 802.21 and DNA ((draft: 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 lead to a draft 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 ---

recharter (last edited 2008-02-20 14:57:15 by localhost)