Subject: Re: [Roll] Next items ...

From: [email-masked]
Date: Wed, 12 Aug 2009 22:42:57 +0200

Hi DT and rollers,

I?m arriving a bit late on the mailing list but I would like to say that I 
fully support Jerry and Mukul regarding P2P support. Efficient P2P support 
is essential for building application systems, especially for 
time-sensitive applications (lighting control, fire?). 
Beyond P2P, I would also like to get better understanding on multicast 
support with RPL. Even though multicast should be avoided when possible in 
a LLNs, it is still required for multiple building automation applications 
(to control banks of lights simultaneously, to control complex and 
time-sensitive automation scenes, to quickly trigger emergency procedures 
and disseminate information to multiple devices?) and to allow for future 
publish/subscribe architectures. In building scenarios, multicast traffic 
will not necessarily be initiated from the DAG root toward leaves but from 
any arbitrary node in the lowpan to a group of arbitrary nodes. Except in 
section 3.3.3.1 ?DAO can convey multicast listeners?, the draft provides 
little information on how multicast traffic will be spread. Is it possible 
to get some more details on multicast support in RPL? Is it conceivable to 
operate MLD into lowpans (I assume no), else is there any plan to define a 
tailored lightweight MLD protocol to avoid flooding the whole network and 
irrigate only zones where multicast flow subscribers exist?

Thanks and Best regards,
Nicolas

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Aug 2009 18:03:57 +0200

Salut Nicolas,

Yes we need to beef up the description of multicast.

Basically you can see DAO as a transport for MLD registrations. I would assume that a listener would use MLD over its link to its router. If the router is using ROLL, it would carry that registration as a DAO to its parent(s). Note that strictly speaking that should be only one parent (the preferred one) so we have real mcast tree. Note that passing the registration to multiple parents improves the reliability but is more costly and a pruning process is required. 

At the same time, the router populates its MRIB/MFIB so that it keeps an entry to forward a mcast packet to all its children router that passed a DAO, as well as all the attached node that registered.

For unicast, It is expected that the sink of the RPL DAG terminates RPL and inject RPL routes in the infrastructure using whatever protocol is used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the nodes attached to the RPL routers ( that's needed iff the source can be in the infrastructure). For such a source, the packet will be replicated has it flows down the preferred tree along the states installed from the DAO. 

For a source inside the DAG, the packet is passed up the tree and to all the registered children but the one that passed the packet. Then again, if there is a listener in the infrastructure then the sink has to propagate the packet in the infrastructure.

Makes sense?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: mercredi 12 août 2009 22:43
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Next items ...

Hi DT and rollers, 

I'm arriving a bit late on the mailing list but I would like to say that I fully support Jerry and Mukul regarding P2P support. Efficient P2P support is essential for building application systems, especially for time-sensitive applications (lighting control, fire...). 
Beyond P2P, I would also like to get better understanding on multicast support with RPL. Even though multicast should be avoided when possible in a LLNs, it is still required for multiple building automation applications (to control banks of lights simultaneously, to control complex and time-sensitive automation scenes, to quickly trigger emergency procedures and disseminate information to multiple devices...) and to allow for future publish/subscribe architectures. In building scenarios, multicast traffic will not necessarily be initiated from the DAG root toward leaves but from any arbitrary node in the lowpan to a group of arbitrary nodes. Except in section 3.3.3.1 "DAO can convey multicast listeners", the draft provides little information on how multicast traffic will be spread. Is it possible to get some more details on multicast support in RPL? Is it conceivable to operate MLD into lowpans (I assume no), else is there any plan to define a tailored lightweight MLD protocol to avoid flooding the whole network and irrigate only zones where multicast flow subscribers exist? 

Thanks and Best regards, 
Nicolas

---

From: [email-masked]
Date: Fri, 28 Aug 2009 12:22:36 +0200

Hi Pascal,

Thanks for your answer. It makes sense indeed.

Best regards,
Nicolas.

"Pascal Thubert (pthubert)" <[email-masked]> 
26/08/2009 18:03

A
Nicolas Riou/FR/Schneider@Europe, <[email-masked]>
cc

Objet
RE: [Roll] Next items ...

Salut Nicolas,

Basically you can see DAO as a transport for MLD registrations. I would 
assume that a listener would use MLD over its link to its router. If the 
router is using ROLL, it would carry that registration as a DAO to its 
parent(s). Note that strictly speaking that should be only one parent (the 
preferred one) so we have real mcast tree. Note that passing the 
registration to multiple parents improves the reliability but is more 
costly and a pruning process is required. 
 
At the same time, the router populates its MRIB/MFIB so that it keeps an 
entry to forward a mcast packet to all its children router that passed a 
DAO, as well as all the attached node that registered.
 
For unicast, It is expected that the sink of the RPL DAG terminates RPL 
and inject RPL routes in the infrastructure using whatever protocol is 
used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the nodes 
attached to the RPL routers ( that?s needed iff the source can be in the 
infrastructure). For such a source, the packet will be replicated has it 
flows down the preferred tree along the states installed from the DAO. 
 
For a source inside the DAG, the packet is passed up the tree and to all 
the registered children but the one that passed the packet. Then again, if 
there is a listener in the infrastructure then the sink has to propagate 
the packet in the infrastructure.
 
Makes sense?
 
Pascal
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: mercredi 12 août 2009 22:43
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Next items ...

Hi DT and rollers, 

Thanks and Best regards, 
Nicolas

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________