Subject: [6lowpan] New charter for 6lowpan

From: Mark Townsley <[email-masked]>
Date: Thu, 15 May 2008 23:02:20 +0200

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

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Fri, 16 May 2008 10:41:41 +0200

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-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.
>
> 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:
>
> 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:
>
> 1. Produce "6lowpan Bootstrapping and 6lowpan IPv6 ND Optimizations"
> 2. Produce "Problem Statement for Stateful Header Compression in
> 6lowpans" to document the problem of using stateful header compression
> 4. Produce "Recommendations for 6lowpan Applications" to define a set
> 5. Produce "6lowpan Security Analysis" to define the threat model of

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 May 2008 16:54:25 +0200

Hi Mark:

I think we need a work item (usually implicit) around the concept of
improving existing WG RFCs. RFC 4944 can be improved in several aspects:

- A major one is a better fit with ISA100.11a. Getting ISA100.11a to
conform to 6LoWPAN would be a major win, but is certainly not a given.
At the moment, the ISA100.11a documents expose discrepencies with RFC
4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve
for the most part.  

- The issue of fragmentation. Applying RFC 4944 over a multihop radio
mesh exposes the network to congestion collapse, as described in
http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec
overy . I think that the WG should dedicate some bandwitdth to provide
additional functions that would improve the LoWPAN operation WRT flow
control and recovery of fragments.

Another aspect of ISA100.11a is the concept of a backbone router. It
would be appropriate that the IETF comes up with a proposal to implement
the concept in the IPv6 world. This partially falls under the first work
item on ND but might also include ND proxy over the backbone which is a
stretch to the work item. More in
http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. 

What do you think?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Townsley
>(townsley)
>Sent: jeudi 15 mai 2008 23:02
>To: [email-masked]
>Subject: [6lowpan] New charter for 6lowpan
>
>

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 May 2008 20:46:55 +0200

> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc resolve
Are the resolutions backwards compatible with RFC 4944? I'm eager to 
improve RFC 4944, but not eager to endorse changes that inhibit 
interoperability.
> control and recovery of fragments.
Fragmentation, OK, but why is flow control a network layer issue rather 
than a transport layer issue?
> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router. 
Well, don't we need to define what ND looks like on a lowpan before we 
decide whether it needs to be proxied or not?

- Mark
>> As I said before, soon after the format document was published, there
>>     
> is
>

---

From: Zach Shelby <[email-masked]>
Date: Sun, 18 May 2008 17:18:55 +0300

Mark,

There are two issues that I would like to see clarified. They are both 
related to connecting 6lowpan networks with backbone IPv6 networks 
better than we can do it now. In my opinion this is the "killer" feature 
of 6lowpan. Including these in some future re-charter would be too late.

1. In my opinion the interconnection of 6lowpan and backbone networks 
using ND techniques along with whiteboarding are important and worth 
including into the standard track. “6lowpan Bootstrapping and 6lowpan 
IPv6 ND Optimizations” should include definition of how to do proxy-ND 
over BbRs? In other words to include some of the ideas from 
draft-thubert-6lowpan-backbone-router. I would like to propose expanding 
the text of that section to:

... will define how to bootstrap a 6lowpan network and explore
ND optimizations such as reusing the 802.15.4 network structure (use
the coordinators), the use of backbone routers, and obviate multicast by 
having devices talk to coordinators without creating a single 
point-of-failure, and changing the IPv6 ND multicast semantics.

2. I would also like to see further improvements to RFC4944, namely 
draft-hui-6lowpan-hc as a start. I don't see a place for this at all in 
the current charter. It can surely be done in a way sufficiently 
backward compatible with the current RFC. Shall a separate WG item exist 
for this?

Otherwise the charter has my full support.

- Zach

Mark Townsley wrote:
> ------------------------------------------------------------------------
> 

-- 
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd.   www.sensinode.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 19 May 2008 11:43:56 +0200

Hi Mark;

I'd say the other way around. We need to figure out whether the ISA100
concept of a backbone is a more generic one and if we agree that such a
backbone federates multiple LoWPANs as a single larger link.

If we agree on that then we need to design ND for that larger link.
That's when the concept of a registration protocol over the LowPAN
associated to proxy ND on the backbone comes into mind.

This model should work whether the host on the LoWPAN gets its addresses
from ND autoconf, DHCP or whatever new registration protocol that might
come up to fill the gap between the two. In particular, this can impact
the design of ND on the LowPAN and incline for a solution based on white
board.

This is why I feel it's important to discuss that now.

Pascal
>From: Mark Townsley (townsley)
>Sent: vendredi 16 mai 2008 20:47
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]
>Subject: Re: [6lowpan] New charter for 6lowpan
>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 19 May 2008 09:36:02 -0700

Hi Mark, thanks for reigniting the discussion on this.

- Improving RFC 4944 is an important one. The biggest issue I have  
with it in the near term is that the IPv6 header compression does not  
allow compression of non-link-local addresses, which is an important  
case if we truly intend to do inter-networking. This is the most  
important point of the 6lopwan-hc draft. Backwards compatibility is  
supported by utilizing new dispatch values. But it's important to  
consider what the implementation costs are of supporting the  
LOWPAN_HC1 defined in RFC 4944, especially since 6lowpan-hc does cover  
most of the useful cases in LOWPAN_HC1. Something for the WG to  
discuss...

- To your point on ND, this is precisely why the architecture draft is  
so important. We haven't given it as much attention lately, but it  
will help resolve the question your raise and many other questions in  
the future. For example, the architecture draft identifies two modes  
of operation: mesh-under and route-over. Both of which may require  
different ND mechanisms. This doesn't apply to just ND, but may apply  
questions of fragmentation, header compression, security, etc.

- I hesitate a bit that we suggest possible solutions to ND in the  
charter ("reusing the 802.15.4 network structure (use the  
coordinators)") especially since the definition of such link  
mechanisms are still in motion within the IEEE. It seems more  
productive to me if we can develop mechanisms that are less dependent  
on the specific structure of 802.15.4 mechanisms.

Rest of the charter looks good to me.

Thanks.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2008 09:11:37 +0200

Hi again Mark

>than a transport layer issue?

[Pascal] I'm talking about flow control on the fragments themselves;
this is either a LLC (the likes of 802.2 or LAPB) or a shim layer above
LLC problem (that would be us). The 802.15.4 MAC/PHY was not design to
cope with IPv6 MTU and when the IPv6 stack sends a NLPDU of 1280 bytes
minimum, it causes a burst of fragments that should be paced and
windowed. I suggest we do it in 6LoWPAN and handle the consequences of
our own fragmentation rather than rely on a LLC mechanism that might not
be there or adapted.

Pascal

---

From: "Robert Assimiti" <[email-masked]>
Date: Tue, 20 May 2008 08:56:35 -0400

Hello Pascal,

I agree with you that a well defined and standardized way of doing fragment recovery and controlling the flow of these fragments are quite needed.

I also agree with you, that it belongs functionally (if not academically) in the 6loWPAN NWK layer.

THks

"The nice thing about standards is that there are so many to choose from." - Andrew S. Tanenbaum 
Robert Assimiti
Executive Staff Engineer
Office: [678]-202-6859
Mobile: [404]-578-0205
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, May 20, 2008 3:12 AM
To: Mark Townsley (townsley)
Cc: [email-masked]
Subject: Re: [6lowpan] New charter for 6lowpan

Hi again Mark

Pascal

This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Mark Townsley <[email-masked]>
Date: Tue, 20 May 2008 11:24:54 -0400

> most of the useful cases in LOWPAN_HC1. Something for the WG to 
Yes, in is incumbent on us as the IETF to ensure that the 6lowpan can 
ultimately be a part of the wider Internet.
> questions of fragmentation, header compression, security, etc.
I worry about the under/over debate. It seems that with all the effort 
and enthusiasm in ROLL, we might be well-served at the moment by 
focusing on helping them be successful with route-over than spending too 
much of our time on route-under.
> on the specific structure of 802.15.4 mechanisms.
I agree that we should develop mechanisms that could work generically 
whenever possible.

- Mark

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2008 18:01:44 +0200

Hi Again Mark:

Another aspect of this is ECN. We do not have room for Explicit
Congestion Notification in the 6LoWPAN headers. ECN only takes 2 bits in
Frame Relay and in IP, though the bits are used differently. I have in
mind that the FR version with forward and backward bits is a better fit
if it acts upon the fragment flow control, though the FECN could then be
mapped into IP ECN.

This is additional work to the fragment recovery and I'm taking great
care to present them separate. But it could become an interesting
feature in some future as well.

Pascal

>Sent: mardi 20 mai 2008 17:18
>>
>>>> overy . I think that the WG should dedicate some bandwitdth to
>>>>
>> provide
>>
>OK, that makes sense. Of course, if the higher layer transports
consider
>this fragmented packet lost and retransmit in the mean time we will end
>up thrashing. We need to be very wary of the higher-layer transport
>affects. And, of course this isn't the first time I've thought we might
>need ot spin up a transport-area lowpan WG  similar to what we did with
>ROLL. But, sometimes its hard enough to keep 2 working groups working
>and making progress, much less 3.
>
>- Mark
>> Pascal
>>
>>
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2008 17:56:22 +0200

Hi Mark:

It would be great to get some help from transport area but forking a WG
could be overkill for the task at hand. We know that we'll get less than
32 fragments, so we can acknowledge the received ones with a simple
DWORD bitmap, and we do not really need a complex sliding window but
rather a simple number of outstanding fragments that we can play with
for flow control. 

For those who doubt that the feature is really important, I have
compiled some references and history on fragments in the Internet in my
draft; it appears that a multihop Low Power & Lossy mesh can be worse a
situation than many we've seen in the past and getting dozens of
fragments just do not help.

This is why I strongly suggest that we add fragment control and recovery
to the charter.

Pascal

consider

---

From: Mark Townsley <[email-masked]>
Date: Tue, 20 May 2008 11:47:02 -0400

> It's good to finally see official rechater text.
It's only proposed text.
> 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?
> 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

---

From: Mark Townsley <[email-masked]>
Date: Tue, 20 May 2008 11:18:26 -0400

> our own fragmentation rather than rely on a LLC mechanism that might not
OK, that makes sense. Of course, if the higher layer transports consider 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 21 May 2008 17:57:25 -0400

> backbone federates multiple LoWPANs as a single larger link.
Let me see if I understand, are you saying this is for a lowpan not 
based on 802.15.4?

- Mark
>>> improving existing WG RFCs. RFC 4944 can be improved in several
>>>       
> aspects:
>   
>>> conform to 6LoWPAN would be a major win, but is certainly not a
>>>       
> given.
>   
>>> would be appropriate that the IETF comes up with a proposal to
>>>       
> implement
>   
>>> the concept in the IPv6 world. This partially falls under the first
>>>       
> work
>   
>>> item on ND but might also include ND proxy over the backbone which is
>>>       
> a
>   
>>>> I'd like to ask the group one final time for comments on the
>>>>         
> proposed
>   
>>>> 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
>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 21 May 2008 15:19:51 -0700

Hi Mark:

On May 20, 2008, at 8:24 AM, Mark Townsley wrote:
>> - To your point on ND, this is precisely why the architecture draft  
>> is so important. We haven't given it as much attention lately, but  
>> it will help resolve the question your raise and many other  
>> questions in the future. For example, the architecture draft  
>> identifies two modes of operation: mesh-under and route-over. Both  
>> of which may require different ND mechanisms. This doesn't apply to  
>> just ND, but may apply questions of fragmentation, header  
>> compression, security, etc.
> I worry about the under/over debate. It seems that with all the  
> effort and enthusiasm in ROLL, we might be well-served at the moment  
> by focusing on helping them be successful with route-over than  
> spending too much of our time on route-under.

I worry too, especially since it will pull the WG in different  
directions. I'm with you on the preference for route-over, but others  
in this group feel strongly about mesh-under as well, especially since  
ISA100.11a seems to have adopted a mesh-under approach. I've  
personally been focused on developing route-over solutions while being  
conscious of supporting mesh-under when possible (evident with 6lowpan- 
hc). However, things will start to diverge when we start to talk about  
bootstrapping, ND, etc. So we should make a conscious decision of  
whether we're supporting one or both.

--
Jonathan Hui

>> productive to me if we can develop mechanisms that are less  
>> dependent on the specific structure of 802.15.4 mechanisms.
> I agree that we should develop mechanisms that could work  
> generically whenever possible.
>
> - Mark
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 May 2008 09:05:22 +0200

Hi Mark:

I'm saying that if we agree that the need for a high speed backbone is
not limited to ISA100 then it makes sense to specify it in 6LoWPAN. At
the moment, the LowPAN is 802.15.4 but the backbone is anything, though
Ethernet is a foremost candidate.

Still I do hope that what we design can easily be applied to other
LoWPANs (LP WIFI, 802.15.4a, ISA100 DLL) but that is not what I was
discussing here. Sorry for the confusion.

Pascal

>Sent: mercredi 21 mai 2008 23:57

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 May 2008 09:47:34 +0200

Hi:

My understanding is that defining how mesh-under computes its routes is
out of scope for the IETF overall. I'm not even sure we need to document
requirements in that space. It's good that we push some requirements to
ROLL on route-over, and that's certainly the right time to do so. 

To Jonathan: I do not completely agree that ISA100 is mesh under. The
routing is not specified and left to the system manager implementation.
My personal hope is to promote a ROLL solution in ISA100.11a next
release. See
http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req .

So the current release of ISA100.11a is at the same level as 6LoWPAN on
the matter of routing. 

In a same fashion, ISA does not define the backbone operation, the
fragment recovery mechanism or the Explicit Congestion Notification. For
all those features, there's a hope at ISA that the IETF will come up
with more generic solutions that they can apply. But time is running
out.

6LoWPAN hasn't produced anything for the last 6 months. At this rate,
ISA will have to define everything on its own and hopefully publish an
informational to this group. 

At the moment, the first draft of ISA100.11a is in letter ballot. The
current draft mostly applies 6loWPAN formats over ISA100.11a DLL, which
is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN
so ISA is using NaLP headers starting with b'00'.

What ISA needs from 6LoWPAN in very short term is in that order:
- promote Jonathan's draft as a convergence specification so ISA can at
least use standard HC headers.
  This enables: non-Link-Local-Address compression
                Hops limit compression
                UDP checksum compression
                Better placement of HC2
  Which are all mandatory for ISA100.11a
- better define the NaLPs. 
  There should be a way to indicate to a 6LoWPAN node whether a NaLP can
be skipped and what its length is. 
- define IP ECN bits in a 6LoWPAN header for use by intermediate nodes
to report congestion.
- specify a fragment flow control and recovery protocol at the 6LoWPAN
Shim layer
There is no rocket science in any of this and it all could/should be
carried out swiftly.

What ISA needs in longer term:
- define backbone operation when the backbone federates multiple LoWPANs
into a single link (or subnet, TBD).
This is more theoretical work for us. Related to proxy ND, a new
registration protocols, multilink subnet, etc...

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: jeudi 22 mai 2008 00:20
>>>>> stretch to the work item. More in
http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router
>>>>> .

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 22 May 2008 09:14:06 -0700

Hi Pascal,

So let's drop the mesh-under/route-over terminology for a second, I  
think they are confusing since everyone seems to have a different  
definition for those terms.

What I am mainly concerned about is the kind of IP Link abstraction  
6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g.  
802.15.4 and possible others through a BbR), what I've been calling  
mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the  
radio range of 802.15.4), what I've been calling route-over. My point  
to Mark's concern was that solutions to some work items within 6LoWPAN  
will be different depending on our IP Link abstraction. From what I  
understand, ISA100.11a has chosen option (i). But to your point below,  
using IP routing to provide connectivity between nodes within the same  
IP Link doesn't seem right to me, so it'd be great if you could help  
me see a path to get there.

A lot of this confusion can be cleaned up within the 6LoWPAN  
architecture document. But I think Mark's concern still stands:  
whether or not we're focused on one or both of these IP Link  
abstractions.

--
Jonathan Hui

---

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:
>> 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?
>> 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
>>>> proposed new
>>>> there is
>>>> be in

---

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

Hi Pascal,

On 5/22/08 12:47 AM, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

> requirements in that space.

Well you just saw my reply to the other email, we're in sync.

It's good that we push some requirements to
> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req .

Considering the quick progress we hope to have something soon.

> informational to this group.

Sharing your view.

> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes

This would be worth having a discussion on this, probably a specific thread.

> - specify a fragment flow control and recovery protocol at the 6LoWPAN

Will reply to this in another email thread.

> into a single link (or subnet, TBD).

Mmmm "Subnet" please.

Thanks.

JP.

---

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

Hi Jonathan,

> whether we're supporting one or both.

And I agree with, hence my previous email ... So far I have heard any strong
valid argument in support of both but I can certainly list a number of
reasons why not doing both.

But for the time being I think that we should try to quickly converge to get
the new charter stabilized to get back to Mark; there are IMO a long list of
items on which we should quickly move on (stateful header compression,
security, ...).

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 22 May 2008 10:22:25 -0400

Just one side note ... I also think that adding a WG item on fragment
recovery is needed. That said, we will need to be vigilant here. Mark is
right saying that adding too much of flow control there may badly impact the
transport layer thus resulting in high delays, waste of energy should the
two flow control mechanism get completely out of sync. But that can be
discussed once we'll get the work item added if there is a agreement of the
WG for doing so.

Mark, we had also a discussion with the Transport AD during the ROLL BOF ...
Yes, there is transport work to be done there for LLN (Low power and lossy
networks) (not specifically lowpan).

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 22 May 2008 10:24:06 -0400

Hi Mark,

> ultimately be a part of the wider Internet.

Exactly. A key WG item.

> much of our time on route-under.

Can't agree more.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 22 May 2008 10:30:48 -0400

Hi Pascal,

Just a word of cautious though. It is not the number of needed bits that
matters here but what you do with them. ECN is clearly a fairly big WG item
(Look at the history of IP in that area or even FR by the way where several
pretty sophisticated mechanisms had been designed to handle this - or
trivial task). I would personally suggest to not add this to the WG charter
for the moment.

Thanks.

JP.

---

From: "David E. Culler" <[email-masked]>
Date: Tue, 20 May 2008 13:42:05 -0700

D

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 22 May 2008 16:54:20 -0600

Aren't both abstractions equally valid?  I think that the biggest issue
with a mesh under is that there is no one standard for it.  ISA100 is
one; I have done another using AODVtiny; I think Jennic has one using
their mesh protocol and there are others.  If IEEE had defined a
multi-hop L2 mesh then we could point at that and define a solution for
ND and bootstrapping and security and ... for it.

The WG decided a couple of meetings ago that we would focus on solutions
for the Route Over abstraction.  [If while we are doing this we can keep
in mind some of the issues w.r.t. mesh under that's good.]

Somewhat independent from this is the HC1G draft that is important to
deal with since we do need a way to efficiently handle non-local
addresses.  So as to remove the mesh under vs. route over issues from
the HC1G draft I would like to see the draft updated to remove the UDP
checksum optimization.

I would like to ask the WG if we should consider taking
draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of
removing the UDP checksum compression.

	geoff

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 22 May 2008 18:18:37 -0600

Pascal,
> ROLL on route-over, and that's certainly the right time to do so. 
I'm not completely positive that this is true, but I do think that it is
not in the scope of 6lowpan right now.

> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req .
I have to disagree.  While the system manager can choose some routing
options, my understanding of the ISA100 DLL is that it does offer a mesh
under layer 2.

> so ISA is using NaLP headers starting with b'00'.

And this still needs to be discussed in ISA100.  I'm not sure that a
NALP is the correct header and we have had this discussion in ISA100.
I'm hoping that this will be corrected in a subsequent draft.

>   Which are all mandatory for ISA100.11a

I don't think that these are all mandatory.  The problem with the
current ISA100 draft is that there was a clear statement that ISA100
would be compliant with 6lowpan and the application layer has chosen not
to be compliant and to try to push changes into 6lowpan to make 6lowpan
compliant with ISA100.  There is some concern that has been expressed
that we are prematurely optimizing the headers.  I'm not convinced that
the benefits of saving 3 bytes outweighs un-thought-of issues that might
come about because of these optimizations.

> be skipped and what its length is. 

I'm not sure that 6lowpan should specify this.  I think that is what a
nalp is for.  The bits following it are unknown.  I think that ISA100
should apply for a dispatch value and should include a dll header length
so that it can be skipped.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 May 2008 09:48:08 +0200

Hi Jonathan:

I agree we need a definition of mesh under; and that we have not found
one yet that satisties us all.

For me, mesh under is when L2 takes care of the connectivity between
nodes and L3 sees everyone on the media. E.g. NBMA. And route over is
when IP has to take care of routing between nodes. E.g. P2MP.

What is important is that the route over has an end to end scope across
the radio hops and the rest of the way. Whereas mesh under optimizes
within the mesh but could create an overall poor end to end path, like a
zig zag.

Pascal
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: jeudi 22 mai 2008 18:14
>Cc: Mark Townsley (townsley); [email-masked]; Jay Werb; Polyzois,
Christos A; Chernoguzov,
>Alexander (PA35); Robert Assimiti; [email-masked]
>Subject: Re: ISA100.11a status and requirements (was RE: [6lowpan] New
charter for 6lowpan)
>>>>>>> I think we need a work item (usually implicit) around the
concept
>>>>>>> of
>>>>>>> - A major one is a better fit with ISA100.11a. Getting
ISA100.11a
>>>>>>> to
>>>>>>> At the moment, the ISA100.11a documents expose discrepencies
with
>>>>>>> RFC
>>>>>>> Another aspect of ISA100.11a is the concept of a backbone
router.
>>>>>>> It
>>>>>>>> From: [email-masked]
[mailto:[email-masked]]
>>>>>>>> On

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 May 2008 12:50:55 +0200

Hi JP:

I see your concern.

I'd argue that ECN is now pretty well defined now in RFC 3168, and that
the basic operation is pretty simple: emulate a packet loss in RED but
save the packet. So the real problem is not ECN itself but what RED
becomes in a LowPAN forwarding node. And that is something that the node
will have to define whether it does ECN or RED.

If we do not have ECN then the LowPAN forwarding nodes will have to
destroy frames which might be fragments. Considering the cost of energy
and bandwidth to getting the frame up to that forwarding node, the
latency introduced by transport layer time out, and the risk of
congestion collapse introduced by resending the whole segment, I'd
suggest that ECN is actually a good idea.

Please have a careful look at:
http://www.ietf.org/internet-drafts/draft-thubert-6lowpan-simple-fragmen
t-recovery-01.txt

that I just update with additions on flow control operation and ECN-echo
support.

Pascal

>From: Jean Philippe Vasseur (jvasseur)
>Sent: jeudi 22 mai 2008 16:31
>To: Pascal Thubert (pthubert); Mark Townsley (townsley)
>Cc: [email-masked]
>>>> our own fragmentation rather than rely on a LLC mechanism that
might
>> not

---

From: Philip Levis <[email-masked]>
Date: Fri, 23 May 2008 10:45:35 -0700

> suggest that ECN is actually a good idea.

This gets back to the point I brought up December 14, 2006. In lossy  
networks, end-to-end fragmentation and assembly is a real problem. It  
makes much more sense to do per-hop fragmentation and assembly. In the  
former, the number of retransmitted fragments is exponential in the  
number of hops; in the latter, it is linear.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 May 2008 16:18:01 +0200

Hi Phil:

We do agree on the problem. 

Per-hop reassembly, though, comes at the expense of that traffic
fluidity that was so desirable to the ATM designers. In other words,
because per-hop reassembly forces each intermediate node to store and
forward a full packet, it is augmenting the latency of the flow and the
memory requirements on the forwarding nodes on the way.

This is why I had in mind to couple a few per-hop recovery with a more
solid end-to-end recovery and flow control mechanism between the LoWPAN
endpoints.

Now I wonder what this discussion becomes in route over v.s. mesh under.
In route over, it seems that the forwarding node terminates a link so it
has to reassemble before it forwards on a different link that might or
might not be a LoWPAN; so maybe we end up doing the same thing in that
case.

Jonathan, what do you think?

Pascal

>From: Philip Levis [mailto:[email-masked]]
>Sent: vendredi 23 mai 2008 19:46
>Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley);
[email-masked]

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Tue, 27 May 2008 11:29:19 +0200 (CEST)

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
> 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

>>> new
>>> in

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 27 May 2008 09:26:35 -0700

Hi Pascal, I see a few underlying issues in this discussion.

First is whether or not route-over implies complete reassembly at  
every hop. In my view, it doesn't. A node could simply cache the  
datagram tag when the first fragment arrives and forward the  
subsequent fragments accordingly. Note that this also saves header  
overhead because the mesh header doesn't have to be included in every  
fragment. When forwarding between different links, reassembly has to  
happen anyway.

The second issue is whether or not we constrain forwarding fragments  
of a given datagram to a single path. This is where mesh-under and  
route-over diverge. But to me, there are a lot of advantages to  
constraining delivery of a datagram to a single path. Hop-by-hop  
recovery can ensure in-order delivery. Hop-by-hop congestion control  
becomes much more meaningful. It's unclear to me what end-to-end  
congestion notification means in a mesh-under setting. We can also  
take advantage of link optimizations to increase throughput and  
decrease latency. And, as mentioned before, reduces header overhead by  
not needing addressing information in subsequent fragments.

The third issue is whether or not end-to-end mechanisms should be used  
for recovery and congestion control. I think we agree that hop-by-hop  
mechanisms are required regardless. They increase reliability and can  
provide effective congestion control and mitigation. To me, hop-by-hop  
mechanisms are generally much more effective than end-to-end ones  
because they react to local conditions and can quickly provide back- 
pressure all the way to the source. From a reliability standpoint,  
we've seen solutions deliver >99.9% without end-to-end recovery. So  
one question is how much more reliability do we really need? and does  
it justify the added energy overhead and code size?

--
Jonathan Hui

---

From: Philip Levis <[email-masked]>
Date: Tue, 27 May 2008 22:34:50 -0700

On May 27, 2008, at 9:26 AM, Jonathan Hui wrote:
>
>
> The third issue is whether or not end-to-end mechanisms should be  
> used for recovery and congestion control. I think we agree that hop- 
> by-hop mechanisms are required regardless. They increase reliability  
> and can provide effective congestion control and mitigation. To me,  
> hop-by-hop mechanisms are generally much more effective than end-to- 
> end ones because they react to local conditions and can quickly  
> provide back-pressure all the way to the source. From a reliability  
> standpoint, we've seen solutions deliver >99.9% without end-to-end  
> recovery. So one question is how much more reliability do we really  
> need? and does it justify the added energy overhead and code size?

This is an excellent point. On one hand, it is critical that we do not  
preclude end-to-end recovery mechanisms, at the very least for the end- 
to-end argument. On the other, we might be getting a bit ahead of  
ourselves here; it's not clear at all whether the benefits of these  
mechanisms (increased layer 3 delivery ratios) significantly outweigh  
their costs (code size and energy).

Phil

---

From: Philip Levis <[email-masked]>
Date: Tue, 27 May 2008 22:38:21 -0700

> that route-over approach cannot provide or would provide only in a  

I disagree wholeheartedly. I think there is a big confusion here  
between a protocol specification and a protocol implementation.

These are all arguments for cross-layer design, that tightly  
integrating routing and the link layer will lead to a better solution.  
Practice has shown us otherwise; only by clearly separating concerns  
do you give a protocol the flexibility needed to evolve over time.  
What happens when a new low power link layer emerges? Having N  
different solutions, each with their own details, which somehow need  
to be made to work well together, seems like a path of brittle and  
difficult to manage networks. Switches are good, to a point; there's a  
reason you have routers.

The purpose of a protocol specification, IMO, is to specify what is  
needed for interoperability; there should, in theory, be multiple  
possible implementations (and by that, I mean power saving approaches)  
that can all interoperate.

Phil

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 28 May 2008 16:04:21 +0900

Hi Mark,

As Carles mentioned, and as already ROLL chairs replied, ROLL is not
considering L2 "route-under". I don't want to debate the preference
and benefits between 'route-over' and 'mesh-under'. Just want to
mention that the current document was written based on the necessity
to check if 6LOWPAN has its own specific routing requitments or not.
As I remember, 71th meeting discussed to make 6LoWPAN RR work with a
tight alignment with ROLL, avoiding duplicate work, and I believe that
-05 is handling well on this matter.

At this stage it may be too early to answer if mesh-under related
issues of 6LoWPAN don't need to be studied when route-over is
provided, since only 3 application specific requirements drafts are
available from ROLL so far.

I think that this work is related to the current mesh-under ND. Before
route-over becomes very clear, we can study in pararell. We can,
later, provide mesh-under as informational or just give some issues as
an input to route-over.
To see this, I think we need to study more, meaning we need this item alive.

Thanks,
-eunah

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 28 May 2008 17:04:14 +0900

Dear Philip,

> difficult to manage networks. Switches are good, to a point; there's a

We don't talk about solutions. We want to see if 6LoWPAN has special
routing requirements due to 802.15.4 specific or not. If route-over
solutions can be provided to fit the requirements of 6LoWPAN, I'm
happy.

-eunah

---

From: Philip Levis <[email-masked]>
Date: Wed, 28 May 2008 08:36:24 -0700

> solutions can be provided to fit the requirements of 6LoWPAN, I'm

Exactly: as soon as you start talking about things like LQI, you are  
coupling yourself not only to a specific link layer, but also a  
specific implementation of that link layer. In practice, many networks  
use the 802.15.4 link layer but not its MAC layer, as it has terrible  
energy properties.

Phil

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 29 May 2008 11:54:14 +0900

Philip,
Thanks for the comment. LQI in the draft was mentioned for one
requirement, and it is given as just one of the examples for routing
matrics to utilize possible information to build up better routing
metrics for low power networks. If you think we shouldn't bond 6LoWPAN
to use MAC metrics, I'm okay with that. We can rule out it, but keep
doing the study about routing matrics. Thank you.

-eunah

On 5/29/08, Philip Levis <[email-masked]> wrote:
> coupling yourself not only to a specific link layer, but also a specific
> implementation of that link layer. In practice, many networks use the
> 802.15.4 link layer but not its MAC layer, as it has terrible energy
> properties.
>
> Phil
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 28 May 2008 21:02:07 -0700

Sorry, first post to the list, so forgive if I'm sounding like a newbie...
How would one get link quality information to the upper layers other than 
via a MAC service?
I can see inserting a shim-layer service to isolate upper layers form the 
different MACs which may be under it, so as to provide a consistent service 
interface. Of course you can only get what the MAC provides, but the shim 
layer and upper layer's can be designed to handle gracefully different MAC 
capabilities (at least consistently).

I'm asking with a bit of a bias here: I'm currently working on MAC 
enhancements for 802.15.4 (in task group "e" in 802.15), including a 
proposal for enhanced link assessment information from the MAC. So of course 
I'd suggest not ruling out some better link metrics in the 802.15.4 MAC at 
some point, although upper layers still need to deal with existing 802.15.4 
devices.  So the general thinking from upper layer uses is very interesting.
Thanks
-Ben

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Thu, 29 May 2008 13:54:48 +0900

Benjamin,

> How would one get link quality information to the upper layers other than

We are in the same track. That's why I think we need to utilize
information from MAC for 6lowpan routing matrics.

> capabilities (at least consistently).

:)

> devices.  So the general thinking from upper layer uses is very interesting.

The current 6LoWPAN RR draft has been started with the reason you
concern, and we've kept working on it, as I believe that there are
necessity of this work nevertheless some folks have different
opinion(I'm trying to listen other side too).

Thank you for sharing your thought. :)

- eunah

---

From: Philip Levis <[email-masked]>
Date: Wed, 28 May 2008 22:49:40 -0700

> devices.  So the general thinking from upper layer uses is very  

This is a very good question. It turns out to be very difficult, for  
two major reasons: separation of concerns and time scale. For the  
sake of simplicity, let's just consider the simplest link quality  
metric, the packet reception ratio.

By separation of concerns, I mean that the MAC layer has to maintain  
state to generate link estimates. However, the MAC layer does not  
know which links are useful to a network layer. That is, it could  
learn and estimate the best links, but those links could be not very  
good for routing. For example, they could lead to a disconnected  
network, or high stretch routes.

By time scale, I mean that if the average PRR over ten seconds is  
50%, that could be due to bursts of high and bursts of low reception.  
Let's say that an application sends a packet every one second, the  
link layer transmits 5 times, and the 50% PRR is due to 5 seconds of  
0% and 5 seconds of 100%. During the 5 seconds of 0%, the node will  
transmit 25 packets, with no successful deliveries. Meanwhile, during  
the 5 seconds of 100%, it will transmit five packets with 5  
deliveries. While the PRR over the 10 second window was 50%, the link  
layer observed a PRR of 16% (5/30).

Most radio chips (e.g., CC2420 and RF230) provide LQI as chip  
correlation values over some number of packet octets. These physical  
layer measurements effectively add significant bits to the SNR in the  
sharp part of the BER curve, and are amazingly useful. However,  
because they are only taken on successful packets, they suffer from  
measurement bias; in the example above of 50% PRR, a network layer  
would see all packets having an excellent LQI value, even though  
packets are lost. This happens in practice, when you have channel  
variations.

Within the TinyOS community, our conclusion is that the MAC layer  
needs to provide 2 bits of information to the network layer. The  
first, the "white bit," is a simplification of things like LQI or SNR  
and essentially indicates whether a received packet had a very low  
BER, indicating it is probably -- but not certainly -- a good link.  
The second, the "ack bit" is signaled on each link layer transmission  
and indicates whether the transmitter received a layer 2 ack. A paper  
in HotNets last year quantified the benefits each of the bits  
provides.[1]

Phil

[1] http://enl.usc.edu/papers/abstract/Fonseca07.html

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 29 May 2008 00:00:17 -0700

We are diverging from the original issue of the route-over/mesh-under  
debate raised by Mark for the new 6lowpan charter. However, I do feel  
that increasing cross-layer cooperation while maintaining the layering  
is an interesting and important question and the discussion should  
continue in a separate thread.

The route-over/mesh-under issue covers more than just routing - it  
defines how we abstract the IP link and covers issues of fragment  
delivery, multicast emulation, neighbor discovery, autoconf, etc.  
While mesh-under is an acceptable approach for extending IP  
connectivity to 6lowpan devices, the real issue is that "IEEE  
802.15.4" is a very loaded term today. There are many link-layers that  
could be well-suited for 6lowpan (both existing and in development)  
that utilize 802.15.4 radios, but not the 802.15.4 multihop meshing  
itself. The real problem with IEEE 802.15.4 is that it fails to define  
a true low-power solution for a multihop mesh, which is explicitly  
stated in IEEE 802.15.4-2006. Work is under way in IEEE 802.15.4e to  
address this issue, but it is still in the formative stages.

Given where we are today, it is most desirable for us to develop  
solutions that do not assume specific functionality specified in IEEE  
802.15.4-2006 for creating a multihop mesh (e.g. beacons,  
coordinators, etc.). It would be a shame if, for each specific  
802.15.4 multihop mesh technology, we or others have to come up with a  
variety of different solutions (routing being only one piece of that)  
to successfully create an IP link.

W.r.t. the routing requirements draft, I think we would be much better  
off by developing a "requirements document for 6lowpan mesh-under  
subnetwork designs", something that others could use when developing  
their own L2 mesh-layer on 802.15.4 radios. This is something the  
6LoWPAN Architecture draft could include or could be broken out into a  
separate document.

--
Jonathan Hui

---

From: Bernard Tourancheau <[email-masked]>
Date: Thu, 29 May 2008 09:20:38 +0200

Hi Jonanthan,
I completly agree with you. Moreover, the spec. should be open enough  
to be able to take advantages of link layer specific properties.
At the extrem, as some proprietary systems are already running,  
should it precludes the usage of another mesh layer on an  
architecture running 6lowPAN ?
--
Bernard.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 May 2008 10:07:16 +0200

Hi Jonathan:

I'm trying here to break the thread into components because it's getting
unreadable.

>fragment. When forwarding between different links, reassembly has to

This should be addressed in the architecture very clearly. Whether the
path is computed at L2 or L3, there's a need to decide and express
clearly in the packet what is the source that does the 6LowPAN
compression, and what is the destination that expands the packet. An
interface on a router should not have to make assumptions on whether a
packet will be routed on another interface of the same type or not.

I've been trying to parse another of your mails on the same subject and
still fail to understand the model you have in mind for what goes in the
mesh header if any and what is uncompressed over a multihop LowPAN path.
I believe that a few examples with figures would help a lot and that
they should end up in the architecture doc once we agree on them.

Fair?

Pascal
>Sent: mardi 27 mai 2008 18:27
>Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley
(townsley); [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 May 2008 10:22:32 +0200

>not needing addressing information in subsequent fragments.

[Pascal] This is a critical design point. We had long talks with Rick
Enns on this. 

A classical Internet behavior when doing multipath load balancing is to
attach a flow on a given path. The reasoning is that if TCP flows are
balanced over multiple paths, then all the flows experience the speed of
the slowest path. This is due to the reaction of TCP flow control to
packets being delayed and arriving out of order.

So it's generally better to assign intelligently (based on feed back) or
blindly (round robin and hash) the flows to the paths and try your luck.
Is this the case here too?

Another angle on this is that if we allow fragments over multiple paths,
the reassembly process still forces all the paths to converge at the
intermediate point where reassembly occurs. Say we have a destination
outside of the LoWPAN. We could theoretically have to paths from a mote
to that destination over 2 different sinks (default gateways). But
that's not possible for fragments because one of the gateways needs all
the fragments to reassemble the packet.

Finally if we define ECN in 6LowPAN, for instance in the mesh header
where it would make sense, then there's always a way for the layer below
to pass its congestion information so that the 6LoWPAN mesh handler sets
the flag in the mesh header.

Many questions...

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 May 2008 10:25:18 +0200

Hi Jonathan:

Resending, I forgot to change the title

>The second issue is whether or not we constrain forwarding fragments of

>a given datagram to a single path. This is where mesh-under and 
>congestion notification means in a mesh-under setting. We can also take

>advantage of link optimizations to increase throughput and decrease 
>latency. And, as mentioned before, reduces header overhead by not 
>needing addressing information in subsequent fragments.

Many questions...

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 May 2008 14:05:57 +0200

Hi Jonathan:

>This is an excellent point. On one hand, it is critical that we do not
preclude end-to-end recovery >mechanisms, at the very least for the end-
to-end argument. On the other, we might be getting a bit >ahead of
ourselves here; it's not clear at all whether the benefits of these
mechanisms (increased >layer 3 delivery ratios) significantly outweigh
their costs (code size and energy).

Pascal:
For the sake of clarity for anyone reading this thread, the discussion
here is about end-to-end LoWPAN path not end-to-end IP path. We have
been discussing whether fragmentation can happen end-to-end and here the
question is about flow control and recovery.

- for flow control I'd argue that the source should be throttled but if
possible not all the hops on the way one by one. Hop by hop flow control
leads to a general and slow backoff all the way to the source that will
impact other connections which should not be impacted.

- for recovery, some level of hop by hop recovery helps fro sure but
there are limits. For instance is inteferences jam a given node, all the
retries will fail, even if it has an alternate next hop. Also, if you
have built a graph made of non congruent paths, then end to end retry
enables to try an entirely new path. I suspect a mix of the 2 can do
better.

About the cost of it, well we need to design simple and low overhead. I
listed a number of requirements in my draft:

   Number of fragments

      The recovery mechanism must support highly fragmented packets,
      with a maximum of 32 fragments per packet.

   Minimimum acknowledgement overhead

      Because the radio is half duplex, and because of silent time spent
      in the various medium access mechanisms, an acknowledgement
      consumes roughly as many resources as data fragment.

      The recovery mechanism should be able to acknowledge multiple
      fragments in a single message.

   Controlled latency

      The recovery mechanism must succeed or give up within the time
      boundary imposed by the recovery process of the Upper Layer
      Protocols.

   Support for out-of-order fragment delivery

      A Mesh-Under load balancing mechanism such as the ISA100 Data Link
      Layer can introduce out-of-sequence packets.  The recovery
      mechanism must account for packets that appear lost but are
      actually only delayed over a different path.

   Optional flow control

      The aggregation of multiple concurrent flows may lead to the
      saturation of the radio network and congestion collapse.

      The recovery mechanism should provide means for controlling the
      number of fragments in transit over the LoWPAN.

   Backward compatibility

      A node that implements this draft should be able to communicate
      with a node that implements [RFC4944].  This draft assumes that
      compatibility information about the remote LoWPAN endpoint is
      obtained by external means.

More in:
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recover
y

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 May 2008 11:48:02 -0400

Hi Phil,

I share your analysis, it is a difficult thing to do, especially with very
unstable links. But this is also true with many other technologies. Look at
QoS with RED when you need to decide when dropping packet based on queue
length with bursty traffic: you use low pass filters. They are not perfect
but good enough. As you pointed out below, you could end up collapsing the
metric to 1 bit or provide a more granular indicator/metric but in all cases
you need to make sure that the mechanism is robust enough to avoid routing
oscillation: an interesting topic of discussion to come ...

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 29 May 2008 11:48:09 -0400

In that particular example (LQI), translate it into a routing link metric
and we'll achieve what you're trying to do. The use of a dynamic metric has
to be studied with great care of course to prevent oscillations. Look at the
ARPANET experiment using dynamic metrics.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 30 May 2008 04:11:10 +0200

Hi,

> Is this the case here too?

And ... This is not the only issue. Should you need to apply RED mechanisms,
the use of multiple path for a single flow becomes challenging since you may
end up affecting many more flow than needed.

> the fragments to reassemble the packet.

This is one of the issues that I also pointed out when highlighting the
shortcomings of combining mesh under and route over.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 30 May 2008 04:16:50 +0200

Hi Pascal,

On 5/29/08 4:07 AM, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>> subsequent fragments accordingly.

Oops ! You mean route a fragment based on the routing decision made for the
first fragment ? Not sure I personally like this, since this introduces some
states on intermediate nodes, which has strong implication.
Further, this means that a fragmented packet cannot be rerouted along a
backup path once the first fragment has been sent out since nodes along the
alternate path would not have the required states to route them.

Note that this also saves header
> they should end up in the architecture doc once we agree on them.

Indeed.

Cheers,

JP.

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 30 May 2008 08:32:42 -0700

Hi Pascal and JP, see below:
> alternate path would not have the required states to route them.

Yes, it does consume extra state, but the overhead is pretty small,  
around 10-bytes for caching two tags, two addresses, and timing  
information. When the last fragment rolls by, you can quickly clean up  
the state. It's still an open question for me how may simultaneous  
flows of fragmented datagrams is truly needed. Re-routing mid-stream  
is arguably less important for delivering a fragmented datagram,  
especially due to temporal properties of the link.

>> packet will be routed on another interface of the same type or not.

Yes, I've said all along that the architecture document is necessary.  
Where reassembly happens has been pretty clear in my mind, and must  
happen before you exit a 6lowpan-based IP link.

>> they should end up in the architecture doc once we agree on them.

The Mesh Addressing header is currently defined in RFC4944 and the  
addresses carried within that header identify the end-points of an IP  
hop. With L3 forwarding, the Mesh Addressing header contains the same  
addresses as the 802.15.4 header and so the Mesh Addressing header can  
be elided. I've provided a few examples at the WG meetings. Can you  
tell me what specific scenarios you're confused about, so I can  
address them directly?

--
Jonathan Hui

>>> used
>>>>>> I'd argue that ECN is now pretty well defined now in RFC 3168,  
>>>>>> and
>>>>>> that
>>>>>> the basic operation is pretty simple: emulate a packet loss in  
>>>>>> RED
>>>> but
>>>>>> becomes in a LowPAN forwarding node. And that is something that  
>>>>>> the
>>>>>> node

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 May 2008 18:45:15 +0200

>tell me what specific scenarios you're confused about, so I can

Say the path over a LoWPAN from a node A to a Backbone Router BbR is via
B and C
Say A sends a packet to D that is reachable over the BbR that acts as
default
gateway and 6LoWPAN termination for the LoWPAN. 

A---->B---->C---->BbR---------->D    
<-----------------> <----------->
      LoWPAN           Backbone 

How I see things:
If we use a mesh header then it will show (A->BbR) all the way through
the LoWPAN
In particular, between B and C, it seems to me that the frame should
have: 
- (b->c) in the MAC hdr;
- (a->BbR) in the mesh header;
- and indicate in the HC that A address is compressed whereas D is not.
That seems to work whether the routing is computed at L2 or L3.

Now if you do not have a mesh header, I fail to understand:
1) How the receive interface in C knows that the 6LowPAN continues 
   (it is not the LoWPAN endpoint so it should not reassemble)
2) How we make sure that all fragments reach BbR for reassembly. 

Pascal

>Sent: vendredi 30 mai 2008 17:33
>To: Jean Philippe Vasseur (jvasseur)
>Cc: Pascal Thubert (pthubert); Philip Levis; Mark Townsley (townsley);
[email-masked]
>Subject: Re: Complete reassemble at every hop (was: [6lowpan] New
charter for 6lowpan)
>>>>> forward a full packet, it is augmenting the latency of the flow
and
>>>>> has to reassemble before it forwards on a different link that
might
>>> or
>>>>>> networks, end-to-end fragmentation and assembly is a real
problem.
>>> It
>>>>>> makes much more sense to do per-hop fragmentation and assembly.
In

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 30 May 2008 10:13:07 -0700

Hi Pascal,

> A---->B---->C---->BbR---------->D

Okay. Given your scenario, the Mesh Addressing header may not identify  
the endpoints of an IP hop. For me, things get more complex and  
confusing in this scenario. You're trying to bridge one or more  
802.15.4 PANs using a different link technology but the Mesh  
Addressing header doesn't provide the means to address nodes in other  
PANs. To cleanly support the scenario where multiple PANs connected  
over a different link technology appear as a single link, I'd much  
rather see a Mesh Addressing header that can hold PANIDs of the source  
and destination and then simply bridge 802.15.4 frames across the  
backbone network. Then you aren't constrained to forcing all fragments  
to ingress/egress through a single BbR. If you truly want to enable  
multi-path routing, then why not support it in full?

>   (it is not the LoWPAN endpoint so it should not reassemble)

If you're doing L3 forwarding, then simply match on the IPv6  
destination address. If you're doing L2 forwarding, then you need the  
Mesh Addressing header if you're forwarding over >1 802.15.4 hop.

> 2) How we make sure that all fragments reach BbR for reassembly.

If you're doing L3 forwarding, fragments are constrained to a single  
path. The BbR is replaced with a traditional IP router.

--
Jonathan Hui

>>>>> provide effective congestion control and mitigation. To me, hop- 
>>>>> by-
>>>>> hop
>>>>>> In route over, it seems that the forwarding node terminates a  
>>>>>> link
>>>>>> so it
>>>>>>>> destroy frames which might be fragments. Considering the cost  
>>>>>>>> of
>>>>>>>> energy