Hi Pascal:
On Jul 18, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote:
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.
[Pascal]
That's how I see it too and this echoes Stephen's question about
forwarding compressed packets.
Except that Stephen (and Zach) was talking about L3 forwarding, where
reassembly must (explicitly or implicitly) happen hop-by-hop.
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?
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
