Re: [6lowpan] New charter for 6lowpan

Hi Mark,

I would like to answer to one of the questions you raised regarding the
mesh-under Vs. route-over paradigms.

> Is there anything that the L3
> "route-over" model might not provide that is listed as a requirement for
> 6lowpan's "route-under" model?

At least, there are the following items listed in the routing requirements
draft (http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt)
that route-over approach cannot provide or would provide only in a limited
way:

- [R03] (use of 802.15.4 link layer feedback for power efficient operation)
- [R05] (use of mesh-under neighbor discovery for 6LoWPAN)
- [R06] (use of 802.15.4 beacons to deal with hibernating/unresponsive nodes)
- [R09] (about exploiting 802.15.4 join/leave messages)
- [R11] (on applying security mechanisms of 802.15.4 for securing the
routing protocol).
- [R12] (802.15.4 constraint on message sizes due to its small MTU)
- [R13] (on using 802.15.4 link layer feedback for link connectivity
maintenance)
- [R14] (on taking advantage of the LQI parameter, which is very critical
in routing decisions in 802.15.4 environments)

In my opinion, the "routing link and node metric" ROLL item can only
partially capture some of the specificities that may affect routing in
802.15.4 environments. Even if LQI parameter can be provided from 802.15.4
to layer three, all the specific 802.15.4 features (see the list above)
can only be fully exploited following a mesh-under approach. Hence, in my
opinion, routing decisions and efficiency of routing protocol operation
within a LoWPAN would be seriously limited if a route-over approach was
followed.

Thanks,

Carles

> Eunsook "Eunah" Kim wrote:
>> Dear AD, and chairmen,
>>
>> It's good to finally see official rechater text.
>>
> It's only proposed 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.
>>
> You could be right. I've cc'd the ROLL chairs here. Roll-chairs, what
> are your expectations from 6lowpan with respect to the
> routing-requirements document?
>
> http://tools.ietf.org/id/draft-dokaspar-6lowpan-routreq-05.txt
>
> I have some more questions for you specifically:
>
> Should that be pulled into roll, or left in 6lowpan? Is roll considering
> the L2"route-under" model at all? Is there anything that the L3
> "route-over" model might not provide that is listed as a requirement for
> 6lowpan's "route-under" model? If 6lowpan were to work on an L2
> "route-under" model, would there be constructs (e.g., the routing
> protocol itself and any low-power modifications) from ROLL that we would
> invariably want to try and reuse?
>> 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
>>
> There has never been any intention to go against consensus or limit
> discussion on this topic. So, let's use this thread to get to the bottom
> of what we want to do as a group here.
>
> - Mark
>> Would you please clarify it to me?
>>
>> Thanks,
>>
>> -eunah
>>
>> On Thu, May 15, 2008 at 11:02 PM, Mark Townsley <townsley@cisco.com>
>> 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
>>> 6lowpan@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan