Hi Pascal,
On Jul 21, 2008, at 12:33 AM, Pascal Thubert (pthubert) wrote:
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.
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.
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.
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
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 PROTECTED]
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:
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
