Dear AD, and chairmen, It's good to finally see official rechater text. I think it's pretty well delivering our discussion of rechartering so far, EXCEPT one part; 6lowpan routing requirement. Last meeting (71th IETF), we discussed RR matter and agreed to see IEEE 802.15.4 specific routing requirements for 6LoWPAN. If I remember correctly, we would keep this work with alignment with ROLL, as long as it's not duplicate work with ROLL.
I would like to know if it is implied that the RR work is included in Architecture work, OR, if you have *intentionally* excluded the work. If the first case, I would suggest 6LoWPANers check the updated version (-05) of draft. We updated our RR draft (-05) after the meeting based on the meeting discussion, and circulated to the mailing list. If the second case, I think we should get a chance to discuss the updated version. If the meeting decide the fate of this work after that, I would accept it. However, I have problem if AD or chairmen simply exclude this item without such discussion and concensus. Would you please clarify it to me? Thanks, -eunah On Thu, May 15, 2008 at 11:02 PM, Mark Townsley <[EMAIL PROTECTED]> wrote: > > I'd like to ask the group one final time for comments on the proposed new > charter. I've also asked the ROLL WG chairs to comment. > > As I said before, soon after the format document was published, there is > nothing stopping the WG from discussing and working on new and existing > items at this time. In fact, activity helps us to decide what should be in > and out of the charter. Please do not construe not having a charter in place > as a reason not to update drafts, or discuss topics that need to be > discussed. Just as when we have BoF's and mailing lists before creating a > new WG, it is good to have WG meetings and on-lists discussions when > creating new WG charters. > > - Mark > > > > > > > Background/Introduction: > > Note: Given that there is not much precedent for this type of activity > at the IETF, the text that follows is of an introductory > nature. Hence, its objective is to give a general idea of the > application area and motivations for the work. In particular, this > section is not to be construed as detailing work items for the working > group. That is done in the following section entitled "Scope of the > Working Group." > > 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 > > * 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 > > 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 ZigBee alliance, for example, is currently > studying what such a work item might entail). The working group is > expected to coordinate and interact with such groups. > > The required work includes items in the following (incomplete) list: > > * IP adaptation/Packet Formats and interoperability > * 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. > > Scope of 6lowpan: > > Produce "Problems Statement, Assumptions and Goals for IPv6 for > LoWPANs" (draft-ietf-lowpan-goals-assumptions-xx.txt) to define the > problem statement and goals of 6lowpan networks. > > Produce "Transmission of IPv6 Packets over IEEE 802.15.4 WPAN > Networks" (draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt) to define the > basic packet formats and sub-IP adaptation layer for transmission of > IPv6 packets over IEEE 802.15.4. This includes framing, adaptation, > header compression and address generation. Furthermore, IEEE 802.15.4 > devices are expected to be deployed in mesh topologies. > > As such, the working group may also work on an informational document > to show how to apply an existing MANET protocol to LoWPANs (e.g., > AODV, OLSR, DYMO, etc). > > 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. > Goals and Milestones: > Done Working group last call on > draft-ietf-lowpan-goals-assumptions-xx.txt > Done Submit draft-ietf-lowpan-goals-assumptions-xx.txt to IESG > for consideration of publication as Informational > Done Working Group Last Call on > draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt > Done Submit draft-ietf-lowpan-ipv6-over-802.15.4-xx.txt to IESG > for consideration of publication as Proposed Standard > > > > Background/Introduction: > > Note: Given that there is not much precedent for this type of activity > at the IETF, the text that follows is of an introductory > nature. Hence, its objective is to give a general idea of the > application area and motivations for the work. In particular, this > section is not to be construed as detailing work items for the working > group. That is done in the following section entitled "Scope of the > Working Group." > > 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 local area networks > > * 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) > > 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 IEEE 1451.5 standard for wireless > transducers has a chapter for 6LoWPAN and the ISA SP100 standard for > wireless industrial networks has adopted 6LoWPAN for their network > layer. This working group is expected to coordinate and interact with > such groups. > > Description of Working Group: > > The working group has completed two RFCs: "IPv6 over Low-Power > Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, > Problem Statement, and Goals" (RFC4919) that documents and discusses > the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 > Networks" (RFC4944) which defines the format for the adaptation > between IPv6 and 802.15.4. > > The Working Group will generate the necessary documents to enusre > interoperable implementations of 6LoWPAN networks and will define the > necessary security and management protocols and constructs for build > 6LoWPAN networks, paying particular attention to protocols already > available. > > Work Items: > > 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. > > This document (or these documents - as the working group delves into > this topic it may determine that this should be two separate > documents) 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. > > 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. The WG > will determine if the assumption is correct at this time and record > the findings in this informational document. > > 3. Produce "6LoWPAN Architecture" to describe the design and > implementation of 6LoWPAN networks. This document will cover the > concepts of "Mesh Under" and "Route Over", 802.15.4 design issues, > network components, addressing, and IPv4/IPv6 network connections. > > 4. 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. > > 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. > > The working group will continue to reuse existing protocols and > mechanisms whenever reasonable and possible. > > Goals and Milestones: > > Jan 2008 - First Draft of Bootstrapping and ND Optimization document > Feb 2008 - First Draft of Stateful Header Compression document > Dec 2007 - First Draft of 6LoWPAN Architecture docuement > Feb 2008 - First Draft of Applications document > Mar 2008 - First Draft of Security Analysis > Jun 2008 - Submit Bootstrapping and ND Optimiation document to IESG to > be considered as Proposed Standard > Jul 2008 - Submit Stateful Header Compression document to IESG to be > considered as Proposed Standard > May 2008 - Submit Architecture docuement to IESG to be considered as > Informational RFC > Jul 2008 - Submit Applications docuement to IESG to be considered as > Informational RFC > Sep 2008 - Submit Security Analysis document to IESG to be considered > as Informational RFC. > > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
