Pascal
>-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: lundi 21 juillet 2008 20:56 >To: Pascal Thubert (pthubert) >Cc: Zach Shelby; 6lowpan >Subject: Re: [6lowpan] Mesh-header, do we need it anymore? > > >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. [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. > >> 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). [Pascal] Please note well the request here for the ECN bits 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. > [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. 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. 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? 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
