Subject: To detail what I said at the mike today when we talked FRF

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 17 Nov 2011 19:42:20 +0800

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)

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 18 Nov 2011 08:00:10 +0800

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-masked]> 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).
>
> 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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 17 Nov 2011 23:43:08 -0500

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

> Comparison of Data Forwarding Mechanisms for AMI Networks. Sandra

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 18 Nov 2011 15:31:20 +0800

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-masked]> wrote:

> > We have code both for the real testbed and for the simulator. Moreover,
> I am currently developing open source code.
> >