Subject: [Roll] ISA100.11a status and requirements (was RE: [6lowpan] New charter for 6lowpan)

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

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: jeudi 22 mai 2008 00:20
>To: Mark Townsley (townsley)
>Cc: [email-masked]
>Subject: Re: [6lowpan] New charter for 6lowpan
>
>
>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
>
>>
>>>
>>> - 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.
>> I agree that we should develop mechanisms that could work
>> generically whenever possible.
>>
>> - Mark
>>>
>>> Rest of the charter looks good to me.
>>>
>>> Thanks.
>>>
>>> --
>>> Jonathan Hui
>>>
>>>
>>>
>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote:
>>>
>>>> Pascal Thubert (pthubert) wrote:
>>>>> 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.
>>>>>
>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager
to
>>>> improve RFC 4944, but not eager to endorse changes that inhibit
>>>> interoperability.
>>>>> - 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.
>>>>>
>>>> Fragmentation, OK, but why is flow control a network layer issue
>>>> rather
>>>> than a transport layer issue?
>>>>> 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
>>>>> .
>>>>>
>>>> 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
>>>>> 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
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 6lowpan mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/6lowpan
>>>
>>>
>>
>
>_______________________________________________
>6lowpan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

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: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: 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
>To: Pascal Thubert (pthubert)
>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)

---

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

On May 27, 2008, at 2:29 AM, Carles Gomez Montenegro wrote:
>
> 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:

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

Benjamin,

On 5/29/08, Benjamin A. Rolfe <[email-masked]> wrote:
> 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?

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

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

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

>
> ----- Original Message -----
> From: "Eunsook "Eunah" Kim" <[email-masked]>
> To: "Philip Levis" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, May 28, 2008 7:54 PM

---

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: "Benjamin A. Rolfe" <[email-masked]>
Date: Wed, 28 May 2008 21:02:07 -0700

---

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.