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

[Jonathan Hui <[e-mail]>]

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.

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

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.

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

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

>
>
> - Zach
>
> -- 
> Zach Shelby | Head of Research | [phone]
> Sensinode Ltd.   www.sensinode.com
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan