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