On Jul 22, 2008, at 12:51 AM, Pascal Thubert (pthubert) wrote:
[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.
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 :-)
[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.
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.
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.
It's clear now :-)
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?
Yup. I'm in complete agreement here.
--
Jonathan Hui
Pascal
--
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
