Alia, it's great to hear that the work is of interest for the WG.
Essentially, the current specification is a mesh-under mechanism (i.e. on layer 2.5), using the 6lowpan headers, as that is where we got our experience from and have implementations. However, I see no problem of adding a layer of abstraction in the draft making it possible to run the mechanism on both layer 2.5 (6lowpan) and layer 3 (IPv6). The 6lowpan architecture is well described in RFC4944, and our current draft relies on that specification. I found the link to the paper I mentioned in my first email: http://www.flacp.fujitsulabs.com/~cardenas/Papers/forwarding-comparison-2.pdf I will also try to ask my management if I can disclose our results from the real deployment. Regards Ulrich On Fri, Nov 18, 2011 at 12:43 PM, Alia Atlas <[email protected]> wrote: > I think that it would be very beneficial to discuss this work in rtgwg. > There may be some experience we can bring to bear. > > I personally am not familiar with the different characteristics of 6lowpan > compared to IP. Could you summarize or send a pointer? > > Regards, > Alia > > > On Friday, November 18, 2011, Ulrich Herberg <[email protected]> wrote: > > Hi all, > > > > Our draft basically describes a data forwarding mechanism, currently > specified for 6lowpan (but it would be doable to add the same mechanism for > IP as well). The idea is that a node first tries to forward a data packet > along the route proposed by the routing protocol. However, if the topology > has changed or a link has become very unstable, instead of dropping the > packet, the node tries to find alternate paths towards the destination by > applying a "depth-first search" in the network, possibly updating the route > cost in the routing protocol. This allows for increasing the delivery ratio > until the route has been corrected by the routing protocol. The advantage > is that one requires fewer updates of the control plane, which may have > negative effects on an already unstable topology (e.g. by flooding RREQ or > LSAs). > > We have done a number of simulations and also real tests with several > hundred nodes at Fujitsu which showed a performance improvement. If you are > interested in reading the draft, I would appreciate any kind of feedback. > > > > I-D > > http://tools.ietf.org/html/draft-cardenas-dff > > > > We have code both for the real testbed and for the simulator. Moreover, > I am currently developing open source code. > > > > Some results in a paper (not yet available, but I will see if I can spin > out a research report and upload that somewhere with public access) > > Comparison of Data Forwarding Mechanisms for AMI Networks. Sandra > Céspedes, Alvaro A. Cárdenas, Tadashige Iwao. 2012 IEEE Innovative Smart > Grid Technologies Conference (ISGT). January 17-19, 2012. > > > > Best regards > > Ulrich > > > > On Thu, Nov 17, 2011 at 7:42 PM, Thomas Heide Clausen < > [email protected]> wrote: > >> > >> Dear all, > >> > >> In the FRR discussion at the mike today, I indicated that some work > targeting FRR in LLNs might be worth looking at (and/or bring it into this > wg). > >> > >> The draft I mentioned was this: > >> > >> http://tools.ietf.org/html/draft-cardenas-dff-03 > >> > >> I'm not an author of this I-D, but I Cc Ulrich, who is, and who can > probably say something much more intelligently than I can about it. > >> > >> Best, > >> > >> Thomas > >> > >> > >> -- > >> Thomas Heide Clausen > >> http://www.thomasclausen.org/ > >> > >> "Payload (noun): wasted bandwidth between headers" (C.Lavenu 2011) > >> > > > > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
