Subject: [Roll] Interest in opportunistic routing?

From: Simon Duquennoy <[email-masked]>
Date: Fri, 7 Mar 2014 10:54:37 +0100

Dear all,

We have designed an opportunistic extension of RPL, where the basic idea is
to exploit all links of the DODAG rather than the tree defined by links to
preferred parents. We do this using anycast: transmissions are intended
either (upwards) to any parent or (downwards) to any child having the
destination below in the DODAG.

The intuition why this is a good idea is that you don't even need to find
out which link is best for you, but rather use available links whenever
they are usable (increases robustness). Furthermore, in radio duty cycled
environment, anycast is also notoriously more energy-efficient and
low-latency than unicast.

We have a working prototype [1] in Contiki that we evaluated thoroughly in
a 135-node testbed [2]. In a 4-min packet interval data collection, we
increase the reliability of RPL from 97.4 to 99.5%, while halving the
latency (below 0.5s) and radio duty cycle (below 0.5%).

If there is interest, we can come up with a simplified version of the
design presented in the paper, and propose a way to integrate it in RPL
through only a few minor additions. To be more specific, the simplified
version would use the existing RPL routing tables rather than Bloom
filters, and would be MAC-layer agnostic (the only assumption being that
the MAC layer supports anycast).

Best regards,
Simon Duquennoy

[1] https://github.com/simonduq/orpl
[2] www.simonduquennoy.net/papers/duquennoy13orpl.pdf

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Mar 2014 07:37:14 -0500

Simon Duquennoy <[email-masked]> wrote:
    > We have designed an opportunistic extension of RPL, where the basic idea is to
    > exploit all links of the DODAG rather than the tree defined by links to
    > preferred parents. We do this using anycast: transmissions are intended either
    > (upwards) to any parent or (downwards) to any child having the destination
    > below in the DODAG.

This is very interesting.

    > We have a working prototype [1] in Contiki that we evaluated thoroughly in a
    > 135-node testbed [2]. In a 4-min packet interval data collection, we increase
    > the reliability of RPL from 97.4 to 99.5%, while halving the latency (below
    > 0.5s) and radio duty cycle (below 0.5%).

    > If there is interest, we can come up with a simplified version of the design
    > presented in the paper, and propose a way to integrate it in RPL through only a
    > few minor additions. To be more specific, the simplified version would use the
    > existing RPL routing tables rather than Bloom filters, and would be MAC-layer
    > agnostic (the only assumption being that the MAC layer supports
    > anycast).

I'm not familliar with the concept of anycast at layer-2.
I think that ethernet supports this, but that actually one would have the
multicast bit set.  I think that you'd have to do the same thing on 802.11.
I guess that 15.4 has a specific support for this, or is just a choice of a
particular unicast mac?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Simon Duquennoy <[email-masked]>
Date: Fri, 7 Mar 2014 14:46:53 +0100

> I guess that 15.4 has a specific support for this, or is just a choice of a

Dear Michael, all,

There is no specific support for anycast in 802.15.4, but the standard MAC
layers can easily be used for anycast (often by setting multicast/broadcast
+ ACK bits).
I've see prototypes for 802.15.4 beacon-enabled [1], for a 15.4e RIT-like
MAC [2], and for a CSL-like MAC (our own implementation uses ContikiMAC,
which is similar CSL).
Should also be possible with 15.4 TSCH or even 802.11 PSM.
Doing this on an always-on link like ethernet or traditional 802.11 is more
tricky because you need an agreement procedure so that only one neighbor
that received the packet forwards it. There exist solutions for WiFi, such
as ExOR [3], which introduced opportunistic for 802.11 back in 2005. I
don't think we want to go into this though; I'd rather simply stipulate
that anycast is required at the MAC layer and possibly give some hints on
how to support it on the most common MAC protocols.

Best,
Simon

[1] http://clarinet.u-strasbg.fr/~theoleyre/uploads/Publis/pavkovic11rpl.pdf
[2] http://www.ti5.tuhh.de/publications/2012/EWSN12_Orinoco.pdf
[3] http://en.wikipedia.org/wiki/ExOR_(wireless_network_protocol)

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Mar 2014 15:26:52 +0000

I'd love to hear

Pascal

Le 7 mars 2014 à 14:47, "Simon Duquennoy" <[email-masked]<mailto:[email-masked]>> a écrit :

On Fri, Mar 7, 2014 at 1:37 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Dear Michael, all,

There is no specific support for anycast in 802.15.4, but the standard MAC layers can easily be used for anycast (often by setting multicast/broadcast + ACK bits).
I've see prototypes for 802.15.4 beacon-enabled [1], for a 15.4e RIT-like MAC [2], and for a CSL-like MAC (our own implementation uses ContikiMAC, which is similar CSL).
Should also be possible with 15.4 TSCH or even 802.11 PSM.
Doing this on an always-on link like ethernet or traditional 802.11 is more tricky because you need an agreement procedure so that only one neighbor that received the packet forwards it. There exist solutions for WiFi, such as ExOR [3], which introduced opportunistic for 802.11 back in 2005. I don't think we want to go into this though; I'd rather simply stipulate that anycast is required at the MAC layer and possibly give some hints on how to support it on the most common MAC protocols.

Best,
Simon

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Mar 2014 15:28:47 +0000

I'd love to hear more. This work reminds me of interesting Results Quentin showed at his PhD...

Pascal

Dear Michael, all,

Best,
Simon

---

From: Simon Duquennoy <[email-masked]>
Date: Fri, 7 Mar 2014 18:42:36 +0100

Dear Pascal,

AFAICT it does go along the same lines as Quentin's work. The main
difference is that we support addressable nodes, i.e. not only upwards but
also downwards routing.

As you're asking for more, let me elaborate a bit on how I see our protocol
(ORPL) integrated in RPL :)
* routing decision (assuming storing mode): the forwarding decision is made
at the receiver, not at the sender. Upon receiving a packet, a node decides
whether to forward it based on (1) its rank and (2) the inclusion of the
destination IPv6 address into its routing table.
  - If the packet is going up and the node has a lower rank then it will
forward with upwards anycast.
  - If the packet is going up or down and the node has a higher rank, and
the destination IPv6 address is in the routing table (i.e. the destination
is below in the DODAG) then it will forward with downwards anycast.
One interesting thing is any-to-any routing is that ORPL has many more
common ancestors to use than RPL. In our experiments, any-to-any routing is
where the benefits of ORPL are most significant, with the latency between
leaf nodes improved with a factor up to 15 (case where RPL has a common
ancestor several hops away whereas ORPL exploits many ancestors closer to
the source and destination).
* routing tables: the standard RPL tables will do. It is however worth
noting that because anycast transmission do not target a specific receiver,
all we need at every node is not a full routing table (<destination,next
hop> pairs) but only a set of reachable destinations. This makes the table
potentially more compact. In the paper we investigate fancy structures for
this such as Bloom filter but I regard this as out of the scope for a
potential integration in standard RPL.
* routing metric: ORPL can work with any routing metric, the only
requirement is to have a DODAG. In the SenSys'13 paper we use our own
metric, which is opportunistic routing-oriented. It helps but isn't
strictly required (could possibly be the object of a separate draft)

Regarding performance: our testbed experiments are on duty-cycled 802.15.4
nodes. We get great reliability. In the current implementation of ORPL
(posterior to the paper) we have most of the runs with 100% delivery ratio
(about 1500 packets sent and received end-to-end during the course of an
hour). The reason is that ORPL is not affected at all by isolated link
losses. It doesn't even notice it. If the link a parent is dead for some
time then another parent will forward the packet. The other side benefits
are latency and energy: when having duty cycled nodes, anycast nicely uses
the first that wakes up and gets the packet successfully, making the wakeup
procedure cheaper. A final note: opportunistic routing is great especially
in dense environments, as there are more links to exploit. In sparser
environments, as far as we have observed, the benefits reduce but are still
present.

The SenSys'13 paper contains a detailed design and thorough experimental
evaluation:
http://www.simonduquennoy.net/papers/duquennoy13orpl.pdf

If you want to know even more, I'm open to having a phone call.

Best,
Simon

On Fri, Mar 7, 2014 at 4:28 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Le 7 mars 2014 à 14:47, "Simon Duquennoy" <[email-masked]> a écrit :
>
>    On Fri, Mar 7, 2014 at 1:37 PM, Michael Richardson <
> [email-masked]> wrote:
>
>>
>  There is no specific support for anycast in 802.15.4, but the standard
> MAC layers can easily be used for anycast (often by setting
> multicast/broadcast + ACK bits).
> Doing this on an always-on link like ethernet or traditional 802.11 is
> more tricky because you need an agreement procedure so that only one
> neighbor that received the packet forwards it. There exist solutions for
> WiFi, such as ExOR [3], which introduced opportunistic for 802.11 back in
> 2005. I don't think we want to go into this though; I'd rather simply
> stipulate that anycast is required at the MAC layer and possibly give some
> hints on how to support it on the most common MAC protocols.
>
>  Best,
> Simon
>
>  [1]
> http://clarinet.u-strasbg.fr/~theoleyre/uploads/Publis/pavkovic11rpl.pdf

---

From: Simon Duquennoy <[email-masked]>
Date: Fri, 7 Mar 2014 19:17:11 +0100

As a complement:
* a visualization of ORPL during a 60-minute run:
http://simonduquennoy.net/resources/orpl-animation.html
* the slides of the SenSys'13 presentation:
http://simonduquennoy.net/resources/131111-oprl-sensys.pptx

Thanks,
Simon

On Fri, Mar 7, 2014 at 6:42 PM, Simon Duquennoy <[email-masked]> wrote:

> As you're asking for more, let me elaborate a bit on how I see our
> protocol (ORPL) integrated in RPL :)
> * routing decision (assuming storing mode): the forwarding decision is
> made at the receiver, not at the sender. Upon receiving a packet, a node
> decides whether to forward it based on (1) its rank and (2) the inclusion
> of the destination IPv6 address into its routing table.

---

From: Ines Robles <[email-masked]>
Date: Sat, 8 Mar 2014 13:20:49 -0300

Hi Simon,

Thank you very much for share ORPL with us.

I think it would be good to present it in the plugfests in next IETFs, in
case that it takes place.

The plugfest for this last IETF [
http://www.ietf.org/proceedings/89/slides/slides-89-6tisch-0.pdf] starting
in slide 65.

Kind Regards,

Ines.

2014-03-07 15:17 GMT-03:00 Simon Duquennoy <[email-masked]>:

>> Regarding performance: our testbed experiments are on duty-cycled
>> 802.15.4 nodes. We get great reliability. In the current implementation of
>> ORPL (posterior to the paper) we have most of the runs with 100% delivery
>> ratio (about 1500 packets sent and received end-to-end during the course of
>> an hour). The reason is that ORPL is not affected at all by isolated link
>>> I've see prototypes for 802.15.4 beacon-enabled [1], for a 15.4e
>>> RIT-like MAC [2], and for a CSL-like MAC (our own implementation uses
>>> ContikiMAC, which is similar CSL).

---

From: Simon Duquennoy <[email-masked]>
Date: Sat, 8 Mar 2014 17:59:36 +0100

Dear Ines,

Do you mean you see ORPL fitting 6TiSCH? I was mostly targeting ROLL, as I
see ORPL as a mac-independent addition to RPL.
That being said, yes, thanks for the invite, I'll definitely consider
presenting it at the next plugfest (potentially along with a TSCH
implementation in Contiki that we hope to have by then).

Best regards,
Simon

On Sat, Mar 8, 2014 at 5:20 PM, Ines Robles
<[email-masked]>wrote:

> http://www.ietf.org/proceedings/89/slides/slides-89-6tisch-0.pdf]
> starting in slide 65.
>
> Kind Regards,
>
> Ines.
>
>
>>>   - If the packet is going up or down and the node has a higher rank,
>>> and the destination IPv6 address is in the routing table (i.e. the
>>> destination is below in the DODAG) then it will forward with downwards
>>> anycast.
>>>>  There is no specific support for anycast in 802.15.4, but the
>>>> standard MAC layers can easily be used for anycast (often by setting

---

From: Ines Robles <[email-masked]>
Date: Sat, 8 Mar 2014 15:03:27 -0300

*Hi Simon,Please see comments below,*

> see ORPL as a mac-independent addition to RPL.

*I'm still reading about it, so I don't have an answer for it so far, it is
an interesting work to analyze.*

> implementation in Contiki that we hope to have by then).

*I meant, that it would be good to present ORPL in  plugfests about
Constrained Networks in the IETFs.I dont know when it is going to be the
next plugfest, but in case that it takes place, it would be nice consider
it.Thanks,Ines.*

> On Sat, Mar 8, 2014 at 5:20 PM, Ines Robles <
> [email-masked]> wrote:
>
>> Hi Simon,
>>
>>> On Fri, Mar 7, 2014 at 6:42 PM, Simon Duquennoy <[email-masked]>wrote:
>>>
>>>> Dear Pascal,
>>>>
>>>>   - If the packet is going up and the node has a lower rank then it
>>>> will forward with upwards anycast.
>>>> The SenSys'13 paper contains a detailed design and thorough
>>>> experimental evaluation:
>>>>>> IETF ROLL WG co-chair.
>>>>>> http://datatracker.ietf.org/wg/roll/charter/
>>>>>>
>>>>>>

---

From: Simon Duquennoy <[email-masked]>
Date: Sat, 8 Mar 2014 20:00:54 +0100

On Sat, Mar 8, 2014 at 7:03 PM, Ines Robles
<[email-masked]>wrote:

>
> *Hi Simon, Please see comments below,*
>
>> Do you mean you see ORPL fitting 6TiSCH? I was mostly targeting ROLL, as
>> I see ORPL as a mac-independent addition to RPL.
>>
>
>
> *I'm still reading about it, so I don't have an answer for it so far, it
> is an interesting work to analyze. *
>
>
>> * I meant, that it would be good to present ORPL in  plugfests about
> Constrained Networks in the IETFs. I dont know when it is going to be the
> it.*

Understood. I agree.
Thanks,
Simon

> * Thanks, Ines.*
>>> I think it would be good to present it in the plugfests in next IETFs,
>>> in case that it takes place.
>>>
>>>>>> Doing this on an always-on link like ethernet or traditional 802.11
>>>>>> is more tricky because you need an agreement procedure so that only one

---

From: "Gillmore, Matthew" <[email-masked]>
Date: Mon, 10 Mar 2014 14:16:26 +0000

Simon,

In 802.15.4,  setting the AR bit for acknowledgements on a broadcast is not a good idea because the network would be flooded with ACKS.

Matt

[Description: http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]<https://www.itron.com/>

Matthew Gillmore
Strategic Standards Architect, Office of the CTO
Mobile: +1.517.745.7350
Knowledge to Shape Your Future

[Description: http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron>  [Description: http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg] <http://www.facebook.com/ItronInc>   [Description: http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg] <http://www.linkedin.com/company/7550?trk=null>   [Description: http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg] <http://www.youtube.com/itronsmartmedia>

From: Roll [mailto:[email-masked]] On Behalf Of Simon Duquennoy
Sent: Friday, March 07, 2014 8:47 AM
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] Interest in opportunistic routing?

Dear Michael, all,

Best,
Simon

---

From: Simon Duquennoy <[email-masked]>
Date: Mon, 10 Mar 2014 15:45:58 +0100

Hi Matt,

The context where anycast is some sort of acked broadcast is with radio
duty cycling, in particular low-power listening. In this context,
broadcasting consists in repeated transmissions for an entire sleep period
so that all neighbors wake up once and get the frame. What we do is we set
the ACK bit and we stop the broadcast transmission upon receiving an ACK
from any neighbor (c.f. fig 2 in the paper). The concept can be applied
(with some adaptations) to different duty cycling solutions including
802.11 PSM, 802.15.4 CSL, RIT or TSCH.

Thanks,
Simon

On Mon, Mar 10, 2014 at 3:16 PM, Gillmore, Matthew <
[email-masked]> wrote:

>  Simon,
>
>
>
> In 802.15.4,  setting the AR bit for acknowledgements on a broadcast is
> not a good idea because the network would be flooded with ACKS.
>
>
>
> Matt
>
>
>
> [image: Description:
> http://marketing.itron.com/campaign/ribbon_logo_rgb_81h.jpg]<https://www.itron.com/>
>
> *Matthew Gillmore*
>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_twitter29.jpg]<http://twitter.com/#!/itron>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_facebook29.jpg]<http://www.facebook.com/ItronInc>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_linkedin29.jpg]<http://www.linkedin.com/company/7550?trk=null>
> [image: Description:
> http://marketing.itron.com/campaign/social_media_icon_youtube29.jpg]<http://www.youtube.com/itronsmartmedia>
>
>
>
>
>
> *From:* Roll [mailto:[email-masked]] *On Behalf Of *Simon Duquennoy
> *Sent:* Friday, March 07, 2014 8:47 AM
> *To:* Routing Over Low power and Lossy networks
> *Subject:* Re: [Roll] Interest in opportunistic routing?
>
>
>

---

From: "Gillmore, Matthew" <[email-masked]>
Date: Mon, 10 Mar 2014 21:18:09 +0000

Simon,

Not sure how that's possible because in 802.15.4-2011 it states

5.1.6.4 Use of acknowledgments and retransmissions
A data or MAC command frame shall be sent with the AR field set appropriately for the frame. A beacon or
acknowledgment frame shall always be sent with the AR field set to indicate no acknowledgment requested.
Similarly, any frame that is broadcast shall be sent with its AR field set to indicate no acknowledgment
requested.

Even if this restriction wasn't in place,  broadcasting with the AR bit set is not a good idea because any devices that hears the broadcast will respond within macSIFSPeriod will cause a flood.

Matthew Gillmore

From: Roll [mailto:[email-masked]] On Behalf Of Simon Duquennoy
Sent: Monday, March 10, 2014 10:46 AM
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] Interest in opportunistic routing?

Hi Matt,

The context where anycast is some sort of acked broadcast is with radio duty cycling, in particular low-power listening. In this context, broadcasting consists in repeated transmissions for an entire sleep period so that all neighbors wake up once and get the frame. What we do is we set the ACK bit and we stop the broadcast transmission upon receiving an ACK from any neighbor (c.f. fig 2 in the paper). The concept can be applied (with some adaptations) to different duty cycling solutions including 802.11 PSM, 802.15.4 CSL, RIT or TSCH.

Thanks,
Simon

On Mon, Mar 10, 2014 at 3:16 PM, Gillmore, Matthew <[email-masked]<mailto:[email-masked]>> wrote:
Simon,

Matt

Matthew Gillmore
Strategic Standards Architect, Office of the CTO
Mobile: +1.517.745.7350<tel:%2B1.517.745.7350>
Knowledge to Shape Your Future

From: Roll [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Simon Duquennoy
Sent: Friday, March 07, 2014 8:47 AM
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] Interest in opportunistic routing?

Dear Michael, all,

Best,
Simon

---

From: Simon Duquennoy <[email-masked]>
Date: Mon, 10 Mar 2014 23:49:17 +0100

The context is a network where nodes are duty cycled, and when you transmit
anycast frame, either:
* in most cases, only one node receives the frame and sends an ACK;
* in some cases, several nodes receive the same frame and send an ACK
(after macSIFSPeriod). This results in occasional duplicate forwarding but
as discussed before this is tolerated by the protocol. Note that several
ACK frames sent simultaneously are not a problem, the sender will typically
be able to decode the frame through constructive interference (c.f.
backcast [1], a concept that's been already re-validated by many including
us, in various contexts)

[1] http://conferences.sigcomm.org/hotnets/2008/papers/4.pdf

Best,
Simon

On Mon, Mar 10, 2014 at 10:18 PM, Gillmore, Matthew <
[email-masked]> wrote:

> *5.1.6.4 Use of acknowledgments and retransmissions*
>
> Even if this restriction wasn't in place,  broadcasting with the AR bit
> set is not a good idea because any devices that hears the broadcast will
> respond within *macSIFSPeriod *will cause a flood.
>
>
>
>
>
> [image: Description:
> *Sent:* Monday, March 10, 2014 10:46 AM

---

From: Don Sturek <[email-masked]>
Date: Mon, 10 Mar 2014 15:58:49 -0700

Hi Simon,

I think Matt's question might be in the context of an AMI application where
most of the devices are powered.  I think in that use case that setting the
AR field as you indicated would not work well.

Don

From:  Simon Duquennoy <[email-masked]>
Reply-To:  Routing Over Low power and Lossy networks <[email-masked]>
Date:  Monday, March 10, 2014 3:49 PM
To:  Routing Over Low power and Lossy networks <[email-masked]>
Subject:  Re: [Roll] Interest in opportunistic routing?

The context is a network where nodes are duty cycled, and when you transmit
anycast frame, either:
* in most cases, only one node receives the frame and sends an ACK;
* in some cases, several nodes receive the same frame and send an ACK (after
macSIFSPeriod). This results in occasional duplicate forwarding but as
discussed before this is tolerated by the protocol. Note that several ACK
frames sent simultaneously are not a problem, the sender will typically be
able to decode the frame through constructive interference (c.f. backcast
[1], a concept that's been already re-validated by many including us, in
various contexts)

Best,
Simon

On Mon, Mar 10, 2014 at 10:18 PM, Gillmore, Matthew
<[email-masked]> wrote:
> Simon,
>  
> Not sure how that¹s possible because in 802.15.4-2011 it states
>  
> Even if this restriction wasn¹t in place,  broadcasting with the AR bit set is
> not a good idea because any devices that hears the broadcast will respond
> within macSIFSPeriod will cause a flood.
>  
>  
>  <https://www.itron.com/>
> Matthew GillmoreStrategic Standards Architect, Office of the CTO
> Mobile: +1.517.745.7350 <tel:%2B1.517.745.7350>
>  <http://twitter.com/#!/itron>   <http://www.facebook.com/ItronInc>
> <http://www.linkedin.com/company/7550?trk=null>
> <http://www.youtube.com/itronsmartmedia>
>  
>  
> The context where anycast is some sort of acked broadcast is with radio duty
> cycling, in particular low-power listening. In this context, broadcasting
> consists in repeated transmissions for an entire sleep period so that all
> neighbors wake up once and get the frame. What we do is we set the ACK bit and
> we stop the broadcast transmission upon receiving an ACK from any neighbor
> (c.f. fig 2 in the paper). The concept can be applied (with some adaptations)
> to different duty cycling solutions including 802.11 PSM, 802.15.4 CSL, RIT or
> TSCH.
> 
>  
> 
> Thanks,
> 
> Simon
> 
>  
> 
>  
> 
> On Mon, Mar 10, 2014 at 3:16 PM, Gillmore, Matthew
> <[email-masked]> wrote:
> 
> Simon,
>  
> In 802.15.4,  setting the AR bit for acknowledgements on a broadcast is not a
> good idea because the network would be flooded with ACKS.
>  
> Matt
>  
>  <https://www.itron.com/>
> Matthew GillmoreStrategic Standards Architect, Office of the CTO
> Mobile: +1.517.745.7350 <tel:%2B1.517.745.7350>
>  <http://twitter.com/#!/itron>   <http://www.facebook.com/ItronInc>
> <http://www.linkedin.com/company/7550?trk=null>
> <http://www.youtube.com/itronsmartmedia>
>  
>  
>> either
>>     > the reliability of RPL from 97.4 to 99.5%, while halving the latency >>
(below
>> design
> layers can easily be used for anycast (often by setting multicast/broadcast +
> ACK bits).
> 
> I've see prototypes for 802.15.4 beacon-enabled [1], for a 15.4e RIT-like MAC
> [2], and for a CSL-like MAC (our own implementation uses ContikiMAC, which is
> similar CSL).
> 
> tricky because you need an agreement procedure so that only one neighbor that
> received the packet forwards it. There exist solutions for WiFi, such as ExOR
> [3], which introduced opportunistic for 802.11 back in 2005. I don't think we
> want to go into this though; I'd rather simply stipulate that anycast is
> required at the MAC layer and possibly give some hints on how to support it on
> the most common MAC protocols.
> 
>  
> 
> Best,
> 
> Simon
> 
>  
> 
>> Michael Richardson <[email-masked] <mailto:[email-masked]> >,
>> Sandelman Software Works
> _______________________________________________ Roll mailing list
> [email-masked]://www.ietf.org/mailman/listinfo/roll

---

From: Simon Duquennoy <[email-masked]>
Date: Tue, 11 Mar 2014 00:05:51 +0100

Hi Don,

Yes, definitely. If your devices are always on then anycast is much more
complex than acked broadcast.
Our opportunistic extension is primarily targeting radio duty cycled
networks.
In always-on networks, you would need an agreement procedure to achieve
anycast, such as that used by ExOr [1] with WiFi.

Best regards,
Simon

[1]
http://pdos.csail.mit.edu/papers/roofnet:exor-sigcomm05/roofnet_exor-sigcomm05.pdf

On Mon, Mar 10, 2014 at 11:58 PM, Don Sturek <[email-masked]> wrote:

> Hi Simon,
>
> I think Matt's question might be in the context of an AMI application
> where most of the devices are powered.  I think in that use case that
> setting the AR field as you indicated would not work well.
>
> Don
>
>
>
> The context is a network where nodes are duty cycled, and when you
> transmit anycast frame, either: