Subject: Re: [Roll] [6lowpan] New charter for 6lowpan

From: JP Vasseur <[email-masked]>
Date: Thu, 22 May 2008 08:07:16 -0400

Hi,

On 5/20/08 1:42 PM, "David E. Culler" <[email-masked]> wrote:

> Here's my take from ROLL.  JP may want to weigh in.

For sure, mesh under is clearly out of the scope of ROLL. That said, if
there are specifics issues that must be addressed (for example) to take into
account 15.4 link specific characteristic they can be addressed as part of
the "routing link and node metric" ROLL WG item.

By the way I thought that the authors had mentioned to respin their document
to focus on 15.4 specific specific aspects.

With no ROLL co-chair hat ... my technical comment here is that I would
HIGHY want to stress the issue of trying to combine routing decisions at
multiple layers. We now have almost two decades of experience and almost (if
not all attempt in that direction) have *failed*, leading to complex *and*
poorly efficient routing decision: lack of end to end routing consistency,
multi-layer recovery issue (timer-based bottom-up approach is usually quite
ineffective), ...

Further, I would say that there are IMO further higher priorities for
6lowpan.

Thanks.

JP.

> 
> ROLL has a series of routing requirements documents.  We'd like 6LoWPAN
> to review, comment, and potentially contribute to those.  I think that
> it makes sense to continue to run them through ROLL.  They are to be
> used to guide the analysis of existing routing protocols.  I6LoWPAN
> might want to use them to guide 6LoWPAN efforts as well.
> 
> ROLL is looking at routing (L3) over low-power and lossy links -
> including but not limited to 802.15.4.  It is not looking at mesh-under
> (L2) forwarding, which the 6LoWPAN adaptation layer provides some
> support for.  The "requirements" documents in 6LoWPAN so far have been
> of a very general observational nature.  Perhaps those will become more
> focused on the issues most germane to 6LoWPAN.  If there is to be more
> work on L2 meshing, 6LoWPAN would likely be the only home for it in
> IETF.  There has been lots of discussion about providing the equivalents
> of ICMPv6 and IPv6 hop-by-hop options for mesh under, but it's not clear
> if that is on the table.  It certainly is not within ROLL.
> 
> A key place of cooperation seems like the ND, Autoconf, ICMPv6 aspects.
> For example, how will router advertisements be utilized?  To date, much
> of the 6LoWPAN ND and bootsrapping discussion has been from 802.15.4 MAC
> concepts-up (eg. PAN coordinator)  rather than IP down (e.g., DHCPv6).
> Being in the internet area, 6LoWPAN is well positioned to lead efforts
> that cut across areas.
> 
> D
> 
> 
> 
> Mark Townsley wrote:
>> 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 <[email-masked]>
>>> 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-masked]
>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>> 
>>>> 
>>>>     
>>> 
>>>   
>> 
> 

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll