Hi Jonathan: As I expected we are off sync.
>over a different link technology appear as a single link, I'd much >rather see a Mesh Addressing header that can hold PANIDs of the source >and destination and then simply bridge 802.15.4 frames across the >backbone network. Then you aren't constrained to forcing all fragments >to ingress/egress through a single BbR. If you truly want to enable >multi-path routing, then why not support it in full? Do you mean D should reassemble 6LoWPAN packets? D should not see 6LoWPAN. D is an IPv6 node on the internet. >> 1) How the receive interface in C knows that the 6LowPAN continues >> (it is not the LoWPAN endpoint so it should not reassemble) > >If you're doing L3 forwarding, then simply match on the IPv6 >destination address. If you're doing L2 forwarding, then you need the >Mesh Addressing header if you're forwarding over >1 802.15.4 hop. The receive interface should not have to do a route lookup to decide to terminate L2. That's what I tried to tell you in the beginning of this thread. >> 2) How we make sure that all fragments reach BbR for reassembly. > >If you're doing L3 forwarding, fragments are constrained to a single >path. The BbR is replaced with a traditional IP router. There's nothing in IP routing that constrains all packets to go over a single path. Let's try again. Now we have: A---->B---->C---->Router1---------->D <-----------------> <-----------> LoWPAN (same PAN ID) Internet In my view, if a routing process in router 1 computes a path from A to D and passes the source route info to A, that is still route over. If the source route path is translated into a mesh header, that's just a mapping. So I have nothing against using mesh header for route over. Looks quite natural to me. Now if we have A---->B---->C---->Router1---------->D | ^ | | +---->E---->F---->Router2-----------+ <-----------------> <-----------> LoWPAN (same PAN ID) Internet It is certainly possible for the routing to enable both routes. And if fragments are spread over those routes we have an issue. We need something to force that all fragments go through either one of the routers for recomposition. A mesh header looks like the natural way of doing this. Obvisouly, a routing header could do but RH0 is being deprecated... Pascal >-----Original Message----- >From: Jonathan Hui [mailto:[EMAIL PROTECTED] >Sent: vendredi 30 mai 2008 19:13 >To: Pascal Thubert (pthubert) >Cc: Jean Philippe Vasseur (jvasseur); Philip Levis; Mark Townsley (townsley); [email protected] >Subject: Re: Complete reassemble at every hop (was: [6lowpan] New charter for 6lowpan) > > >Hi Pascal, > >On May 30, 2008, at 9:45 AM, Pascal Thubert (pthubert) wrote: >> Say the path over a LoWPAN from a node A to a Backbone Router BbR is >> via >> B and C >> Say A sends a packet to D that is reachable over the BbR that acts as >> default >> gateway and 6LoWPAN termination for the LoWPAN. >> >> A---->B---->C---->BbR---------->D >> <-----------------> <-----------> >> LoWPAN Backbone >> >> How I see things: >> If we use a mesh header then it will show (A->BbR) all the way through >> the LoWPAN >> In particular, between B and C, it seems to me that the frame should >> have: >> - (b->c) in the MAC hdr; >> - (a->BbR) in the mesh header; >> - and indicate in the HC that A address is compressed whereas D is >> not. >> That seems to work whether the routing is computed at L2 or L3. > >Okay. Given your scenario, the Mesh Addressing header may not identify >the endpoints of an IP hop. For me, things get more complex and >confusing in this scenario. You're trying to bridge one or more >802.15.4 PANs using a different link technology but the Mesh >Addressing header doesn't provide the means to address nodes in other >PANs. To cleanly support the scenario where multiple PANs connected >over a different link technology appear as a single link, I'd much >rather see a Mesh Addressing header that can hold PANIDs of the source >and destination and then simply bridge 802.15.4 frames across the >backbone network. Then you aren't constrained to forcing all fragments >to ingress/egress through a single BbR. If you truly want to enable >multi-path routing, then why not support it in full? > >> Now if you do not have a mesh header, I fail to understand: >> 1) How the receive interface in C knows that the 6LowPAN continues >> (it is not the LoWPAN endpoint so it should not reassemble) > >If you're doing L3 forwarding, then simply match on the IPv6 >destination address. If you're doing L2 forwarding, then you need the >Mesh Addressing header if you're forwarding over >1 802.15.4 hop. > >> 2) How we make sure that all fragments reach BbR for reassembly. > >If you're doing L3 forwarding, fragments are constrained to a single >path. The BbR is replaced with a traditional IP router. > >-- >Jonathan Hui > >> >> >> Pascal >> >>> -----Original Message----- >>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>> Sent: vendredi 30 mai 2008 17:33 >>> To: Jean Philippe Vasseur (jvasseur) >>> Cc: Pascal Thubert (pthubert); Philip Levis; Mark Townsley >>> (townsley); >> [email protected] >>> Subject: Re: Complete reassemble at every hop (was: [6lowpan] New >> charter for 6lowpan) >>> >>> >>> Hi Pascal and JP, see below: >>> On May 29, 2008, at 7:16 PM, JP Vasseur wrote: >>>>>> First is whether or not route-over implies complete reassembly at >>>>>> every hop. In my view, it doesn't. A node could simply cache the >>>>>> datagram tag when the first fragment arrives and forward the >>>>>> subsequent fragments accordingly. >>>> >>>> Oops ! You mean route a fragment based on the routing decision made >>>> for the >>>> first fragment ? Not sure I personally like this, since this >>>> introduces some >>>> states on intermediate nodes, which has strong implication. >>>> Further, this means that a fragmented packet cannot be rerouted >>>> along a >>>> backup path once the first fragment has been sent out since nodes >>>> along the >>>> alternate path would not have the required states to route them. >>> >>> Yes, it does consume extra state, but the overhead is pretty small, >>> around 10-bytes for caching two tags, two addresses, and timing >>> information. When the last fragment rolls by, you can quickly clean >>> up >>> the state. It's still an open question for me how may simultaneous >>> flows of fragmented datagrams is truly needed. Re-routing mid-stream >>> is arguably less important for delivering a fragmented datagram, >>> especially due to temporal properties of the link. >>> >>>> Note that this also saves header >>>>>> overhead because the mesh header doesn't have to be included in >>>>>> every >>>>>> fragment. When forwarding between different links, reassembly has >> to >>>>>> happen anyway. >>>>>> >>>>> >>>>> This should be addressed in the architecture very clearly. Whether >>>>> the >>>>> path is computed at L2 or L3, there's a need to decide and express >>>>> clearly in the packet what is the source that does the 6LowPAN >>>>> compression, and what is the destination that expands the packet. >>>>> An >>>>> interface on a router should not have to make assumptions on >>>>> whether a >>>>> packet will be routed on another interface of the same type or not. >>> >>> Yes, I've said all along that the architecture document is necessary. >>> Where reassembly happens has been pretty clear in my mind, and must >>> happen before you exit a 6lowpan-based IP link. >>> >>>>> I've been trying to parse another of your mails on the same subject >>>>> and >>>>> still fail to understand the model you have in mind for what goes >>>>> in the >>>>> mesh header if any and what is uncompressed over a multihop LowPAN >>>>> path. >>>>> I believe that a few examples with figures would help a lot and >>>>> that >>>>> they should end up in the architecture doc once we agree on them. >>> >>> The Mesh Addressing header is currently defined in RFC4944 and the >>> addresses carried within that header identify the end-points of an IP >>> hop. With L3 forwarding, the Mesh Addressing header contains the same >>> addresses as the 802.15.4 header and so the Mesh Addressing header >>> can >>> be elided. I've provided a few examples at the WG meetings. Can you >>> tell me what specific scenarios you're confused about, so I can >>> address them directly? >>> >>> -- >>> Jonathan Hui >>> >>>>> >>>>> >>>>> Fair? >>>> >>>> Indeed. >>>> >>>> Cheers, >>>> >>>> JP. >>>> >>>>> >>>>> Pascal >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>>>>> Sent: mardi 27 mai 2008 18:27 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: Philip Levis; Jean Philippe Vasseur (jvasseur); Mark Townsley >>>>> (townsley); [email protected] >>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> Hi Pascal, I see a few underlying issues in this discussion. >>>>>> >>>>>> First is whether or not route-over implies complete reassembly at >>>>>> every hop. In my view, it doesn't. A node could simply cache the >>>>>> datagram tag when the first fragment arrives and forward the >>>>>> subsequent fragments accordingly. Note that this also saves header >>>>>> overhead because the mesh header doesn't have to be included in >>>>>> every >>>>>> fragment. When forwarding between different links, reassembly has >> to >>>>>> happen anyway. >>>>>> >>>>>> The second issue is whether or not we constrain forwarding >> fragments >>>>>> of a given datagram to a single path. This is where mesh-under and >>>>>> route-over diverge. But to me, there are a lot of advantages to >>>>>> constraining delivery of a datagram to a single path. Hop-by-hop >>>>>> recovery can ensure in-order delivery. Hop-by-hop congestion >> control >>>>>> becomes much more meaningful. It's unclear to me what end-to-end >>>>>> congestion notification means in a mesh-under setting. We can also >>>>>> take advantage of link optimizations to increase throughput and >>>>>> decrease latency. And, as mentioned before, reduces header >>>>>> overhead by >>>>>> not needing addressing information in subsequent fragments. >>>>>> >>>>>> The third issue is whether or not end-to-end mechanisms should be >>>>>> used >>>>>> for recovery and congestion control. I think we agree that hop-by- >>>>>> hop >>>>>> mechanisms are required regardless. They increase reliability and >>>>>> can >>>>>> provide effective congestion control and mitigation. To me, hop- >>>>>> by- >>>>>> hop >>>>>> mechanisms are generally much more effective than end-to-end ones >>>>>> because they react to local conditions and can quickly provide >> back- >>>>>> pressure all the way to the source. From a reliability standpoint, >>>>>> we've seen solutions deliver >99.9% without end-to-end recovery. >>>>>> So >>>>>> one question is how much more reliability do we really need? and >>>>>> does >>>>>> it justify the added energy overhead and code size? >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> >>>>>> On May 26, 2008, at 7:18 AM, Pascal Thubert (pthubert) wrote: >>>>>> >>>>>>> Hi Phil: >>>>>>> >>>>>>> We do agree on the problem. >>>>>>> >>>>>>> Per-hop reassembly, though, comes at the expense of that traffic >>>>>>> fluidity that was so desirable to the ATM designers. In other >>>>>>> words, >>>>>>> because per-hop reassembly forces each intermediate node to store >>>>>>> and >>>>>>> forward a full packet, it is augmenting the latency of the flow >> and >>>>>>> the >>>>>>> memory requirements on the forwarding nodes on the way. >>>>>>> >>>>>>> This is why I had in mind to couple a few per-hop recovery with a >>>>> more >>>>>>> solid end-to-end recovery and flow control mechanism between the >>>>>>> LoWPAN >>>>>>> endpoints. >>>>>>> >>>>>>> Now I wonder what this discussion becomes in route over v.s. mesh >>>>>>> under. >>>>>>> In route over, it seems that the forwarding node terminates a >>>>>>> link >>>>>>> so it >>>>>>> has to reassemble before it forwards on a different link that >> might >>>>> or >>>>>>> might not be a LoWPAN; so maybe we end up doing the same thing in >>>>> that >>>>>>> case. >>>>>>> >>>>>>> Jonathan, what do you think? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Philip Levis [mailto:[EMAIL PROTECTED] >>>>>>>> Sent: vendredi 23 mai 2008 19:46 >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: Jean Philippe Vasseur (jvasseur); Mark Townsley (townsley); >>>>>>> [email protected] >>>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>>>> >>>>>>>> >>>>>>>> On May 23, 2008, at 3:50 AM, Pascal Thubert (pthubert) wrote: >>>>>>>> >>>>>>>>> Hi JP: >>>>>>>>> >>>>>>>>> I see your concern. >>>>>>>>> >>>>>>>>> I'd argue that ECN is now pretty well defined now in RFC 3168, >>>>>>>>> and >>>>>>>>> that >>>>>>>>> the basic operation is pretty simple: emulate a packet loss in >>>>>>>>> RED >>>>>>> but >>>>>>>>> save the packet. So the real problem is not ECN itself but what >>>>>>>>> RED >>>>>>>>> becomes in a LowPAN forwarding node. And that is something that >>>>>>>>> the >>>>>>>>> node >>>>>>>>> will have to define whether it does ECN or RED. >>>>>>>>> >>>>>>>>> If we do not have ECN then the LowPAN forwarding nodes will >>>>>>>>> have to >>>>>>>>> destroy frames which might be fragments. Considering the cost >>>>>>>>> of >>>>>>>>> energy >>>>>>>>> and bandwidth to getting the frame up to that forwarding node, >>>>>>>>> the >>>>>>>>> latency introduced by transport layer time out, and the risk of >>>>>>>>> congestion collapse introduced by resending the whole segment, >>>>>>>>> I'd >>>>>>>>> suggest that ECN is actually a good idea. >>>>>>>> >>>>>>>> This gets back to the point I brought up December 14, 2006. In >>>>>>>> lossy >>>>>>>> networks, end-to-end fragmentation and assembly is a real >> problem. >>>>> It >>>>>>>> makes much more sense to do per-hop fragmentation and assembly. >> In >>>>>>>> the >>>>>>>> former, the number of retransmitted fragments is exponential in >>>>>>>> the >>>>>>>> number of hops; in the latter, it is linear. >>>>>>>> >>>>>>>> Phil >>>>> >>>> >> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
