Subject: [6lowpan] Mesh-header, do we need it anymore?

From: Zach Shelby <[email-masked]>
Date: Fri, 18 Jul 2008 16:05:10 +0300

I'd like to make a bold proposal. If we now decide to take HC into use, 
and depreciate HC1 (momentum seems to be there); I would like to go one 
step further. Let's depreciate the use of the RFC 4944 mesh-header at 
the same time.

draft-hui-6lowpan-hc-00 now allows us to do everything which the 
mesh-header does, and more. Sending packets to a global IPv6 node using 
the mesh header now requires both the mesh-header, plus an L3 
destination address. Quite inefficient. Plus there is again the issue of 
  implementation, testing, and interop along with a confusing spec where 
routing src/dst can be carried both in lowpan and IPv6 headers.. This 
situation is similar to that of HC1 and HC. The mesh-header will slowly 
depreciate anyways, especially with ROLL activity, and for interop 
reasons between vendors. Let's depreciate it now and stop the annoying 
mesh-under vs. route-over confusion.

LOWPAN_BC0 would still be used to eliminate duplicates.

At Sensinode we are likely the largest production deployers with the 
mesh-header at this time, and are willing to move to L3 at the same time 
as HC. How about other implementors using the mesh-header, can you 
support this motion? Can anyone think of a reason to keep the mesh header?

- Zach

-- 
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd.   www.sensinode.com
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 18 Jul 2008 08:24:09 -0700

Hi Zach, see below:

On Jul 18, 2008, at 6:05 AM, Zach Shelby wrote:
> I'd like to make a bold proposal. If we now decide to take HC into  
> use, and depreciate HC1 (momentum seems to be there); I would like  
> to go one step further. Let's depreciate the use of the RFC 4944  
> mesh-header at the same time.

Good question.

> mesh-header does, and more. Sending packets to a global IPv6 node  
> using the mesh header now requires both the mesh-header, plus an L3  
> destination address. Quite inefficient. Plus there is again the  
> issue of  implementation, testing, and interop along with a  
> confusing spec where routing src/dst can be carried both in lowpan  
> and IPv6 headers.. This situation is similar to that of HC1 and HC.  
> The mesh-header will slowly depreciate anyways, especially with ROLL  
> activity, and for interop reasons between vendors. Let's depreciate  
> it now and stop the annoying mesh-under vs. route-over confusion.

I'm all for simplicity - it's quite significant when we're dealing  
with resource-constrained devices that are hard to debug. Again, I  
think we should be more explicit about routing vs. forwarding. The  
mesh header allows L2 forwarding, but there's no reason why you  
couldn't combine that with L3 routing. Then there's the L3 vs. L2  
routing debate and, if it hasn't been obvious already, I'm all for an  
L3 routing approach. I wouldn't want us to relive the days of LAN  
emulation in dynamic, multihop networks, especially those that are  
resource-constrained.

> LOWPAN_BC0 would still be used to eliminate duplicates.

If you're doing L3 forwarding, you probably want to carry that in an  
L3 header (we place it in a compressed hop-by-hop option header). In  
light of some of the earlier discussion with HC, I think it's time to  
incorporate HBH options into the HC draft.

> mesh-header at this time, and are willing to move to L3 at the same  
> time as HC. How about other implementors using the mesh-header, can  
> you support this motion? Can anyone think of a reason to keep the  
> mesh header?

The only real advantage I see of the mesh header is that it allows you  
to pick an intermediate destination. But this requires packets to  
carry both the mesh header and L3 addressing as you pointed out above.  
A better application of L2 forwarding is to apply MPLS-style  
forwarding and utilize the traffic-engineering capabilities that it  
provides, but then we'd want a header that carries a label, not the  
mesh addressing header that carries a source and destination  
addresses. I think ISA100 is currently leaning in a direction of using  
the mesh addressing header, but this might still be in flux. On the  
other hand, we've had significant experience with L3 forwarding in low- 
power, lossy networks and must say that it's been working pretty well  
so far. But others with more experience in L2 forwarding should speak  
up as well.

--
Jonathan Hui

---

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

>emulation in dynamic, multihop networks, especially those that are
[Pascal] 

That's how I see it too and this echoes Stephen's question about 
forwarding compressed packets.

A simple way to decide whether to terminate 6LoWPAN or to forward a 
6LoWPAN packet still compressed is to have the information in the
header. 

For instance, the routing computes which sink is the best exit point
to leave the 6LoWPAN network towards the final destination.

That sink should become the place where 6LoWPAN is terminated and 
fragments are recomposed. The "mesh" header becomes a routing 
header that forces all the packets to be routed via the sink.

Forwarding happens along a graph towards that sink, and 6LoWPAN is not
finished until the next hop in the routing header is reached.

On the way back, The routing header indicates the last router (FFD) that
serves the final destination if that one does not route.

Makes sense?

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 18 Jul 2008 10:09:46 -0700

Hi Pascal:

> forwarding compressed packets.

Except that Stephen (and Zach) was talking about L3 forwarding, where  
reassembly must (explicitly or implicitly) happen hop-by-hop.

> serves the final destination if that one does not route.

For L2 forwarding, this is a sensible solution (routing headers are  
commonly used for these kinds of things). With L3 forwarding, there is  
no ambiguity of where the reassembly must happen.

--
Jonathan Hui

---

From: Kris Pister <[email-masked]>
Date: Sun, 20 Jul 2008 15:18:18 -0700

Zach - I agree.  Let's do it right, and stick with route over.

ksjp

Zach Shelby wrote:
> use, and depreciate HC1 (momentum seems to be there); I would like to 
> go one step further. Let's depreciate the use of the RFC 4944 
> destination address. Quite inefficient. Plus there is again the issue 
> of  implementation, testing, and interop along with a confusing spec 
> where routing src/dst can be carried both in lowpan and IPv6 headers.. 
> This situation is similar to that of HC1 and HC. The mesh-header will 
> slowly depreciate anyways, especially with ROLL activity, and for 
> interop reasons between vendors. Let's depreciate it now and stop the 
> annoying mesh-under vs. route-over confusion.
>
> you support this motion? Can anyone think of a reason to keep the mesh 
> header?
>
> - Zach
>

---

From: "Pete St. Pierre" <[email-masked]>
Date: Sun, 20 Jul 2008 16:30:01 -0700

> Zach - I agree.  Let's do it right, and stick with route over.

When we have a solution that is proven to work, that makes sense.  In  
the meantime, let's not deprecate things people are using and may  
still need, depending on the future successes.

I think it make a lot of sense to settle on a single HC model, since  
there is proven, implemented work.  I think abandoning the mesh header  
in its entirety at this point is premature.

...Pete

>> The mesh-header will slowly depreciate anyways, especially with  
>> ROLL activity, and for interop reasons between vendors. Let's  
>> depreciate it now and stop the annoying mesh-under vs. route-over  
>> confusion.
>>
>> At Sensinode we are likely the largest production deployers with  
>> the mesh-header at this time, and are willing to move to L3 at the  
>> same time as HC. How about other implementors using the mesh- 
>> header, can you support this motion? Can anyone think of a reason  
>> to keep the mesh header?
>>
>> - Zach
>>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 21 Jul 2008 10:14:50 +0300

Thanks for the feedback everyone. I'll just summarize here what feedback 
I've gotten so far. Still waiting or more reasons we need the 
mesh-header, and feedback from others who have implemented and are using 
mesh-header forwarding.

So far then we have 2 features the mesh-header allows:

  - Specification of intermediate destination (e.g. a particular BbR), 
but this comes at the cost of mesh-header + HC dst address for 
addressing outside the lowpan. Does the current BbR actually require 
this wrt the primary router?

  - Fragments are not reassembled at intermediate hops.

Are there some down-sides to doing IPv6 routing inside the lowpan?

  - Fragments must be "reassembled" at each router in the lowpan. Not 
necessarily a bad thing, could allow for hop-by-hop recovery.

  - We may have IPv6 ND issues if each node in the lowpan is an IPv6 
router. We need to differentiate between lowpan IPv6 routers (LpR?) and 
BbRs. IPv6 routers inside the lowpan should not e.g. send their own RAs.

As far as I understand ISA100 could just as easily use HC to achieve the 
routing options it has in mind. Geoff, Pascal, is this correct?

Pete had a good point about not prematurely depreciating something that 
works and is in use. However I would still like to hear who is really 
using it. I have an understanding there is actually quite equal 
implementation and deployment experience for both IPv6 routing and 
mesh-header forwarding inside lowpans at this time. I would say both 
work fine. However we don't have a standard algorithm for mesh 
forwarding (and are not going to get it), so what happens when ROLL 
algorithms come into use?

For example, our forwarding algorithm could just as easily store the 
src+dst+hopcount in the IPv6 header using HC as in the mesh-header as 
now without penalty. In practice in limited nodes lowpan and IPv6 are 
processed and implemented together, it is really a very small 
implementation detail whether to look at the mesh-header or HC IPv6 
header for the dst address, and then consult your routing table for the 
next hop.

- Zach

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jul 2008 09:33:09 +0200

Hi Jonathan:

I think it is desirable to be able to route packets in the compressed
form. Rassembling 6LoWPAN packets at each hop will slow the traffic down
and cause congestion on the intermediate nodes if they are limited in
capacity. The 6LoWPAN sublayer is already L3 so we should be able to
forward at that sublayer provided that there is a standard that
guarantees that both sides match. But that work if it happens should NOT
delay / be confused with the chartered work on HC. 

My vote is to standardize HC as it stands with its current coverage.
Other pieces of work, like deprecating 4944, compressed forwarding and
congestion handling can happen in parallel with their own schedule
though it would be good to figure the broad lines in case they impact HC
as it stands (eg ECN in HC).

We can note that mesh headers are already and should be defined by the
underlaying technology (like 802.11S and ISA do for instance). So I'm
all for deprecating the 6LowPAN mesh header and forget about it. But a
routing header is still route over even if the expression is compressed
so it is our business.

We can also note that a loose source routing enables all packet to reach
a reassambly point over a routing graph whereas a strict source routing
and hop-by-hop fragmentation/recomposition imply a single path for the
whole packet.

If the group agrees that we should define forwarding in compressed mode
then we can consider it in parallel or some future and see where that
leads us. If mobile IP plays a role someday, compressing RH2 and some
option headers will also be of interest.

Pascal

>-----Original Message-----
>From: Jonathan Hui [mailto:[email-masked]]
>Sent: vendredi 18 juillet 2008 19:10
>To: Pascal Thubert (pthubert)
>Cc: Zach Shelby; 6lowpan
>Subject: Re: [6lowpan] Mesh-header, do we need it anymore?
>
>
>Hi Pascal:
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Jul 2008 09:51:53 +0200

Hi Zach:

The way I understand it:

ISA100.11a defines its own mesh header at the Data Link (DL) layer. Mesh
header not considered to belong to 6LoWPAN in that architecture so we
ignore it. 

Out of my head, ISA can forget about RFC 4944 if 6LoWPAN standardizes
fragmentation, HC with ECN and Carsten's proposal to skip unknown
headers. Note that ISA needs the current capabilities to compress
addresses that are not EUI LLAs, the network hop limit and the transport
checksum. 

ISA would also apreciate other work like asserting the need for fragment
recovery and providing a solution if the need is established.

Finally, ISA100.11a is open to leave the path computation to a L3
process, though it should probably be offline. For the current release,
this is going to be unspecified and left to the implementation of the
system manager, but hopefully a solution out of ROLL can be standardized
in some future.

Pascal

>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Zach Shelby
>Sent: lundi 21 juillet 2008 09:15
>To: 6lowpan

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 21 Jul 2008 11:56:01 -0700

Hi Pascal,

> delay / be confused with the chartered work on HC.

I'm not in agreement with the above paragraph. There's nothing about  
L3 forwarding that prevents you from routing datagrams in the  
compressed form (we do it today). You can easily pull out the  
appropriate destination address from the HC-compressed IP header and  
forward accordingly. L3 forwarding also does not require explicit  
reassembly at every hop, just that fragments must travel the same  
path. I'd argue that there are many reasons why you'd want to route  
all fragments for the same datagram along the same path, the main  
reason being that it's easier to dynamically adapt L2 along a single  
path for the short burst of packets. I'm also not in agreement that  
6LoWPAN mesh addressing header is an L3 header - it only carries L2  
addresses.

> routing header is still route over even if the expression is  

Again, we should be explicit about whether you are talking about L2  
vs. L3 forwarding. An IPv6 Routing Header is, of course, L3 forwarding  
but that requires fragments to follow a single path. If you're talking  
about MPLS-like forwarding, then that's below L3.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 21 Jul 2008 12:07:55 -0700

Hi Zach,

On Jul 21, 2008, at 12:14 AM, Zach Shelby wrote:
> Thanks for the feedback everyone. I'll just summarize here what  
> feedback I've gotten so far. Still waiting or more reasons we need  
> the mesh-header, and feedback from others who have implemented and  
> are using mesh-header forwarding.
>

Agreed. From what I understand, the current BbR draft makes one or  
multiple PANs appear as a single IPv6 link. As a result, the BbR draft  
assumes L2 forwarding and because packets transported over the  
backbone link do not carry the mesh addressing header, they must be  
reassembled at a single BbR before forwarding over the backbone.

> - Fragments are not reassembled at intermediate hops.

It's more appropriate to say that all fragments for a given datagram  
must follow the same path. Complete reassembly does not need to happen  
at every hop.

> necessarily a bad thing, could allow for hop-by-hop recovery.

In addition to hop-by-hop recovery, it's also easier to optimize L2  
for burst transmissions along a single path.

> router. We need to differentiate between lowpan IPv6 routers (LpR?)  
> and BbRs. IPv6 routers inside the lowpan should not e.g. send their  
> own RAs.

I'm working on an ND draft that addresses this problem, but probably  
won't get it done in time for the meeting.

> As far as I understand ISA100 could just as easily use HC to achieve  
> the routing options it has in mind. Geoff, Pascal, is this correct?
>
> Pete had a good point about not prematurely depreciating something  
> that works and is in use. However I would still like to hear who is  
> really using it. I have an understanding there is actually quite  
> equal implementation and deployment experience for both IPv6 routing  
> and mesh-header forwarding inside lowpans at this time. I would say  
> both work fine. However we don't have a standard algorithm for mesh  

Right. And from what we've seen so far, others that are defining L2  
forwarding mechanisms are circumventing the mesh addressing header by  
defining their own...

> src+dst+hopcount in the IPv6 header using HC as in the mesh-header  
> as now without penalty. In practice in limited nodes lowpan and IPv6  
> are processed and implemented together, it is really a very small  
> header for the dst address, and then consult your routing table for  
> the next hop.

That's pretty much what we do today. End nodes have to be able to  
generate/process IPv6 headers anyway. Needing to process the mesh  
addressing header only adds to the resource requirements.

--
Jonathan Hui

---

From: Geoff Mulligan <[email-masked]>
Date: Mon, 21 Jul 2008 17:39:33 -0600

I don't think that we should or need to remove the mesh header.  I think
that there is a use for it (Sun is using it with sunspots).

It would seem that you could use some layer 2 packet to determine
forwarding information and then use the mesh header to create a single
layer 2.5 link for all the nodes on the pan - I think that this is what
sun does.

I'm experimenting with passing the routing information inside the ip
packet and then still using the mesh header to create single link layer
in the pan (I guess this is a hybrid of route over and mesh under -
Route Over Mesh).

I do not want to see the mesh header deprecated.

	geoff

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 22 Jul 2008 09:51:37 +0200

Pascal

>Sent: lundi 21 juillet 2008 20:56

[Pascal] I agree with this. My main reason for forwarding all fragments
over a same path is that if fragments from a same packet are distributed
over multiple paths, more packets might be delayed or lost if one single
hop experiences trouble. 

It is better that only some flows get hit and this can be achieved by 
sticking a flow to a path. This s a general behaviour that we can 
observe in the routers already. For fragments it's even more important
because of the recomposition buffers.

But we do not have to dictate that it always happens that way. We have
to 
provide the means that it happens that way when that's the desired 
behaviour. 
 
>> as it stands (eg ECN in HC).

[Pascal] Please note well the request here for the ECN bits in HC ;)

>about MPLS-like forwarding, then that's below L3.
 
[Pascal] Well, the route that MPLS follows is set up by L3. 
So a lot of the opposition against mesh under does not stand 
against the MPLS approach. But that's a discussion for ROLL I guess.

What I'm looking for is a new header that acts as an IPv6 routing
header and compresses the final destination and eventually some
intermediate hops.

In one use of the routing header, the destination IP address 
that would be compressed by HC would be the last router, 
and when the last router receives the 6LoWPAN packet, it 
would swap the destination with the address in the header
and forward to the final destination.

I hope it's clear that I'm in favor of replacing the mesh header
that belongs to L2 with a routing header that belongs to L3 with 
semantics extended from RFC 2460.

The routing header can be loose and thus may not force all the 
intermediate hops. So RH enables but does not require
fragments to follow a single path.

A record route capability would be useful for source routing 
though 2460 does not have one.

Looks better this way?

Pascal

---

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Jul 2008 11:26:26 +0300

Hi,

Needless to say, I see that there may be some uses for the mesh header 
in particular cases. Of course we need to keep it there for now. Later 
on (2009 e.g) it should however really be checked if anyone is using it.

Maybe in order to clarify the viable use of the mesh header, and to 
avoid confusion with route over, draft-culler-6lowpan-architecture-00 
could describe when and how it should be used in more specifics. Now the 
draft points out the limitations and realities of mesh header usage 
quite well. Could it go one step further, and define one viable, useful 
way to use the mesh header. The only time I see mesh under being useful 
as we stand, is when the L2 technology already sets up a topology that 
includes all needed forwarding information and messaging to maintain it. 
802.15.4 in beacon mode, with a tree topology, achieves that. Why don't 
we just limit the scope of mesh under for this case? Then we avoid tons 
of ambiguity. I think this draft would be the place to at least 
recommend this usage.

The problem I see is that the WG has put too much emphasis on mesh-under 
  in assumptions made in most drafts assuming it will be used most 
often. Whereas in reality it will likely be the exception, used only in 
cases like the one mentioned above. For routing between PANs, or without 
sufficient L2 forwarding information - we should recommend route over 
and work closely with ROLL to support that paradigm.

So I recommend that the architecture draft (and routereq draft) should 
be more explicit:

1. For complete broadcast domains, nothing needed.

2. For full-featured 802.15.4 beacon-mode networks, in a strict tree 
topology, forming a single PAN - you can use mesh under to form a single 
IP link. We should also explain how to do it in sufficient detail (could 
be done in dokaspar-6lowpan-routereq). ND optimizations should support 
this setup of mesh under.

3. For anything else (e.g. ad-hoc 802.15.4 networks), we recommend the 
use of L3 routing. For standardized routing algorithms see ROLL. ND 
optimizations and future HC improvements (e.g. IPv6 routing header 
compression suggested by Pascal) should support RO usage.

4. Experimentally you could use mesh-under with other L2 technologies or 
setups that maintain sufficient forwarding information, or in 
hybrid-mesh setups (note the dangers in hybrid-mesh from the 
architecture doc).

- Zach

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Tue, 22 Jul 2008 23:19:12 +0900

Dear all,

> that there is a use for it (Sun is using it with sunspots).

I don't know industries or other commercial fields, but
Korea has been building up some 6LoWPAN testbeds, and as I know the
biggest testbed in Jeju island use a comercial product which use the
mesh header.

> in the pan (I guess this is a hybrid of route over and mesh under -

This hybrid way is what exactly some Korean 6LoWPAN testbeds are using.

> I do not want to see the mesh header deprecated.

In my opinion, it's a bit early to say deprecation of mesh header as
it's in use.

-eunah

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 22 Jul 2008 21:29:24 -0700

> provide the means that it happens that way when that's the desired

Okay. I misunderstood what you meant by forwarding in "compressed  
form." You actually meant to inspect the compressed header rather than  
keeping it opaque and relying on lower-layer headers. I agree on your  
other statements as well.

> [Pascal] Please note well the request here for the ECN bits in HC ;)

Noted :-)

> against the MPLS approach. But that's a discussion for ROLL I guess.

Understood, but MPLS is still a lower-layer forwarding service that is  
capable of treating each fragment for the same datagram differently.  
I'm not convinced of its advantages in the sensornet space, but it is  
something to think about.

> semantics extended from RFC 2460.

It's clear now :-)

> though 2460 does not have one.

Yup. I'm in complete agreement here.

--
Jonathan Hui

>>>>>> routing debate and, if it hasn't been obvious already, I'm all  
>>>>>> for
>>> an
>>>>> On the way back, The routing header indicates the last router  
>>>>> (FFD)
>>>>> that

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 22 Jul 2008 21:34:04 -0700

>> though 2460 does not have one.

BTW, in case you didn't catch it in one of my previous emails, we do  
use both RH and RR mechanisms in our networks today, in compressed  
form of course, and they do work well for us.