Re: [Roll] [roll] #128: Trickle multicast could be considered in other applications?

[Don Sturek <[e-mail]>]

Hi Esko,

Not quite sure about this statement:    "It is not described how a non-MPL
host can 'inject' its multicast packet into an MPL domain, or how an MPL
Forwarder should 'demux' a multicast packet out from the MPL Domain so
that nearby listening non-MPL hosts can receive the multicast."

The scope of a multicast message arriving at a MPL capable border router
determines whether it is injected into the MPL domain or not (and it would
then be encapsulated) and, again, the scope of any generated multicast
within a MPL domain determines whether it exits the MPL domain
(encapsulated on generation in the MPL domain and de-encapsulated at the
MPL border and forwarded if necessary based on the addressing scope of the
interface).

For our use case (ZigBee IP), we use 0x03 (realm-specific scope) for
forwarding in the MPL domain (FF03::FC) and then we encapsulate our (at
least our discovery messages) as site specific (FF05::FB).  That said, it
would be easy to add other applications with different address scope.

I think it is really up to the application to determine the scope of the
messages that are sent and then the rest of the addressing architecture
simply ensures the messages are forwarded to all potential group members.

Don




On 8/21/13 5:50 AM, "Dijk, Esko" <[e-mail]> wrote:

>>    adrian> - do the hosts need to be in any way aware
>>    adrian> that their mcast is supported by MPL?
>>
>> At some point the answer has been yes and at other points it has been
>>no, and I guess I have to back to the document to remember what we
>>concluded.
>
>I believe that MPL-04 does not answer this, and perhaps even cannot,
>because it is out of scope in the current text.
>It is not described how a non-MPL host can 'inject' its multicast packet
>into an MPL domain, or how an MPL Forwarder should 'demux' a multicast
>packet out from the MPL Domain so that nearby listening non-MPL hosts can
>receive the multicast.
>
>Solutions for this exist that require a host to be aware of MPL, and
>solutions exist as well that don't require this.
>
>If Section 3 (Applicability Statement) could just mention this, plus the
>other questions from ticket #128 that are now answered, I believe the
>ticket can be closed.
>
>regards,
>Esko
>
>
>________________________________
>The information contained in this message may be confidential and legally
>protected under applicable law. The message is intended solely for the
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.
>
>_______________________________________________
>Roll mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/roll