Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

From: Robert Cragie <[email-masked]>
Date: Thu, 01 Nov 2012 08:30:31 +0000

Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully 
help to illustrate some of the thought processes we went through when 
implementing and testing between the ZigBee IP vendors (comments 
welcome). Apologies in advance for the PDF format but ASCII art would 
have been difficult :-)

Robert

On 31/10/2012 11:22 PM, Dario Tedeschi wrote:
> Yes, I'd like to try clarify why link-local scope was suggested for 
> the *outer* header. The reasons were:
>
>  1. Link-local scope is the only scope where the boundaries are well
>     defined (i.e. on the link). Higher scopes are not well-defined and
>     can cover wide domains depending on network configuration and
>     administration.
>
<RCC>I agree and made essentially the same comment re. higher scopes.</RCC>
>
>  1. With a higher scope, there is a chance that non-MPL aware routers
>     may simply forward encapsulated multicast datagrams (MPL HbH
>     option and all). We wouldn't want MPL datagrams to leak outside of
>     an MPL domain.
>
<RCC>Which is why I think the encapsulation rules do need to be pretty 
specific. If link-local encapsulation is always used then providing the 
MPL forwarder rules are clear, the MPL domain is then entirely bounded 
by the MPL forwarders and there is no question regarding address scope 
and administration thereof. This cleanly covers Peter's case as well 
where he wants to forward into another PAN - it would be processed 
internally as an original non-MPL packet and then be "launched" into the 
other PAN using LL encapsulation for that PAN. Using other scopes for 
the outer header would still work but then there is the issue of 
administering the scope. However, this would need to be done in the case 
where no encapsulation is done anyway.</RCC>
>
>  1. A higher scope complicates the forwarding logic that needs to be
>     implemented in an MPL router. The complication comes when a router
>     receives an MPL datagram and needs to figure out whether to
>     decapsulate or not. Granted, the use of an MPL group would
>     mitigate this problem to a degree, but link-local scope would make
>     the decision to decapsulate very obvious and simple.
>
<RCC>I think it would have to be effectively decapsulated at every 
router anyway irrespective of the scope of the outer header to see if it 
needs to be processed - it is the inner header which counts there and 
the comments about multicast groups come into play in that discussion. 
But I agree using link-local makes that decision easy and somewhat 
clearer</RCC>
>
>  1. In conjunction with 3. Link-local scope also makes it easier for
>     an MPL router to determine if the inner multicast address is one
>     that a higher layer (or an app) may be interested in.
>
<RCC>Agree that the rules are clearer for link-local</RCC>
>
> 1.
>
>
> Hopefully I haven't made things more confusing.

<RCC>Perish the thought ;-)</RCC>
>
> - Dario
>
> On 31/10/2012 7:53 AM, Jonathan Hui (johui) wrote:
>> Hi Peter,
>>
>> The current draft does not place any restrictions on the MPL multicast scope.
>>
>> If the LLN border router is an MPL forwarder, it can forward MPL multicast packets between different MPL multicast scope zones.  To be explicit, if the original multicast packet's destination address has link-local scope, the MPL forwarder should not forward the packet again.  If the original multicast packet's destination has a scope larger than the MPL multicast scope, then the MPL forwarder needs to forward the packet to other MPL multicast scope zones (which may or may not involve different interfaces).
>>
>> Does that address your question?
>>
>> --
>> Jonathan Hui
>>
>> On Oct 31, 2012, at 3:54 AM, peter van der Stok<[email-masked]>  wrote:
>>
>>> Hi Jonathan,
>>>
>>> To be absolutely sure: the MPL multicast scope can be link-local, ULA or site-local? meaning the LLN border router can be a MPL forwarder?
>>> In the latter case the LLN border router can forward link-local multicast from one interface to another?
>>>
>>> Greetings,
>>>
>>> peter
>>>
>>> Jonathan Hui (johui) schreef op 2012-10-30 18:27:
>>>> Yes, a goal of the current draft is to support both cases (use of
>>>> IPv6-in-IPv6 encapsulation or not).
>>>>
>>>> The intent is as follows:
>>>> 1) If the source of the multicast packet is within the MPL forwarding
>>>> domain and the destination has a scope equal to or smaller than the
>>>> MPL multicast scope, then no IPv6-in-IPv6 encapsulation is required.
>>>> 2) If the source of the multicast packet is outside the MPL
>>>> forwarding domain or the destination has scope greater than the MPL
>>>> multicast scope, then IPv6-in-IPv6 encapsulation is required.  When
>>>> using IPv6-in-IPv6 encapsulation, then the all MPL forwarders
>>>> multicast address with scope = MPL multicast scope is used as the
>>>> destination address in the outer header.
>>>>
>>>> As mentioned in my other email, IPv6-in-IPv6 encapsulation is
>>>> required if you want to use the IPv6 Destination Address to identify
>>>> MPL forwarding scope zones.
>>>>
>>>> Of course, this brings up Dario's practical point of how to configure
>>>> the MPL multicast scope if we allow that to dynamically change.  He
>>>> proposes a simplifying suggestion of requiring IPv6-in-IPv6
>>>> encapsulation for all non-link-local multicasts.  In other words,
>>>> setting the MPL multicast scope to link-local.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Jonathan Hui
>>>>
>>>> On Oct 30, 2012, at 4:46 AM, Don Sturek<[email-masked]>  wrote:
>>>>
>>>>> Hi Peter,
>>>>>
>>>>> I still need to read the latest draft so take what I say here with that in
>>>>> mind......
>>>>>
>>>>> I was hoping that we could support not using IP in IP tunneling if the
>>>>> scope of the multicast transmission was only within the multi-link subnet
>>>>> managed by the border router.   I was hoping that only transmission
>>>>> emanating from outside the multi-link subnet, received at the border
>>>>> router, with scope that includes the devices in the multi-link subnet
>>>>> would require IP in IP tunneling (and vice versa in terms of multicasts
>>>>> generated in the multi-link subnet with scope outside).  I haven't yet
>>>>> read the draft carefully to know if this is possible.
>>>>>
>>>>> Don
>>>>>
>>>>>
>>>>> On 10/30/12 1:34 AM, "peter van der Stok"<[email-masked]>  wrote:
>>>>>
>>>>>> Hi Don,
>>>>>>
>>>>>> and more specifically under which conditions. That gives the
>>>>>> possibility to choose the conditions such that the encapsulation is not
>>>>>> needed.
>>>>>>
>>>>>> Don Sturek schreef op 2012-10-29 16:56:
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> I think your suggested changes to the Trickle Multicast draft point
>>>>>>> out
>>>>>>> why IP in IP tunneling is needed.
>>>>>>>
>>>>>>> Don
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/29/12 3:44 AM, "peter van der Stok"<[email-masked]>  wrote:
>>>>>>>
>>>>>>>> Dear WG,
>>>>>>>>
>>>>>>>>
>>>>>>>> Attached my suggestions for text modifications including some nits. I
>>>>>>>> used the facilities of word to edit and comment text with traces.
>>>>>>>>
>>>>>>>> When writing text about MC scope and MC domain, I was puzzled by the
>>>>>>>> all MPL forwarders multicast address which removes the possibility to
>>>>>>>> address a given multicast group. We expect multiple (possibly
>>>>>>>> disjunct)
>>>>>>>> MC groups in our wireless networks.
>>>>>>>> Also I failed to understand why encapsulation was necessary once the
>>>>>>>> message was received by the seed.
>>>>>>>> To make it possible to configure the interface with one MC scope I
>>>>>>>> added the possibility to use Unicast-Prefix-based IPv6 Multicast
>>>>>>>> Addresses (RFC 3306).
>>>>>>>>
>>>>>>>>
>>>>>>>> Probably, I overlooked many aspects which make the suggestions
>>>>>>>> impractical, but I hope that the intention is clear.
>>>>>>>>
>>>>>>>> Peter van der Stok
>>>>>>>>
>>>>>>>> Michael Richardson schreef op 2012-10-25 23:30:
>>>>>>>>> I suggest that you propose specific text to the list to modify the
>>>>>>>>> document.
>>>>>>>> _______________________________________________
>>>>>>>> Roll mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>> _______________________________________________
>>>>> Roll mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 1 Nov 2012 12:26:16 +0000

Hi Robert,

these are very useful diagrams.  I just wanted to point out for page 6, "Site local multicast originating externally", that there is probably also configuration required (in the BR) of what multicast traffic is allowed by the BR onto the LLN.  I assume that not all multicast traffic from the high-speed backbone network should be forwarded onto the LLN into the MPL domain as that could lead to congestion?

As  a side note, this configuration would not be needed if we would have an equivalent of the MLD protocol , to let LLN nodes announce their interest in specific multicast groups.  One specific solution (in case the BR is also an RPL DODAG root) is for nodes to use standard RPL DAOs containing multicast addresses of interest, to advertize the multicast groups of interest to the BR which can then automatically set up the 'filtering rules'. But this is probably beyond the current MPL spec ;-)

regards,
Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: Thursday 1 November 2012 9:31
To: [email-masked]
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully help to illustrate some of the thought processes we went through when implementing and testing between the ZigBee IP vendors (comments welcome). Apologies in advance for the PDF format but ASCII art would have been difficult :-)

Robert

On 31/10/2012 11:22 PM, Dario Tedeschi wrote:
Yes, I'd like to try clarify why link-local scope was suggested for the *outer* header. The reasons were:

  1.  Link-local scope is the only scope where the boundaries are well defined (i.e. on the link). Higher scopes are not well-defined and can cover wide domains depending on network configuration and administration.
<RCC>I agree and made essentially the same comment re. higher scopes.</RCC>

  1.  With a higher scope, there is a chance that non-MPL aware routers may simply forward encapsulated multicast datagrams (MPL HbH option and all). We wouldn't want MPL datagrams to leak outside of an MPL domain.
<RCC>Which is why I think the encapsulation rules do need to be pretty specific. If link-local encapsulation is always used then providing the MPL forwarder rules are clear, the MPL domain is then entirely bounded by the MPL forwarders and there is no question regarding address scope and administration thereof. This cleanly covers Peter's case as well where he wants to forward into another PAN - it would be processed internally as an original non-MPL packet and then be "launched" into the other PAN using LL encapsulation for that PAN. Using other scopes for the outer header would still work but then there is the issue of administering the scope. However, this would need to be done in the case where no encapsulation is done anyway.</RCC>

  1.  A higher scope complicates the forwarding logic that needs to be implemented in an MPL router. The complication comes when a router receives an MPL datagram and needs to figure out whether to decapsulate or not. Granted, the use of an MPL group would mitigate this problem to a degree, but link-local scope would make the decision to decapsulate very obvious and simple.
<RCC>I think it would have to be effectively decapsulated at every router anyway irrespective of the scope of the outer header to see if it needs to be processed - it is the inner header which counts there and the comments about multicast groups come into play in that discussion. But I agree using link-local makes that decision easy and somewhat clearer</RCC>

  1.  In conjunction with 3. Link-local scope also makes it easier for an MPL router to determine if the inner multicast address is one that a higher layer (or an app) may be interested in.
<RCC>Agree that the rules are clearer for link-local</RCC>

  1.

- Dario

Hi Peter,

--

Jonathan Hui

On Oct 31, 2012, at 3:54 AM, peter van der Stok <[email-masked]><mailto:[email-masked]> wrote:

Hi Jonathan,

Greetings,

peter

Thoughts?

--

Jonathan Hui

On Oct 30, 2012, at 4:46 AM, Don Sturek <[email-masked]><mailto:[email-masked]> wrote:

Hi Peter,

mind......

Don

On 10/30/12 1:34 AM, "peter van der Stok" <[email-masked]><mailto:[email-masked]> wrote:

Hi Don,

needed.

Hi Peter,

out

Don

On 10/29/12 3:44 AM, "peter van der Stok" <[email-masked]><mailto:[email-masked]> wrote:

Dear WG,

disjunct)

Addresses (RFC 3306).

Peter van der Stok

document.

Roll mailing list

[email-masked]<mailto:[email-masked]>

Roll mailing list

[email-masked]<mailto:[email-masked]>

Roll mailing list

[email-masked]<mailto:[email-masked]>

Roll mailing list

[email-masked]<mailto:[email-masked]>

________________________________
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.

---

From: Robert Cragie <[email-masked]>
Date: Thu, 01 Nov 2012 12:48:22 +0000

Hi Esko,

Good point about multicast forwarding policy at the BR. I have redone 
the diagrams slightly to make a couple of corrections and include the 
note about multicast forwarding policy at the BR.

Robert

On 01/11/2012 12:26 PM, Dijk, Esko wrote:
>
> Hi Robert,
>
> these are very useful diagrams.  I just wanted to point out for page 
> 6, "Site local multicast originating externally", that there is 
> probably also configuration required (in the BR) of what multicast 
> traffic is allowed by the BR onto the LLN.  I assume that not all 
> multicast traffic from the high-speed backbone network should be 
> forwarded onto the LLN into the MPL domain as that could lead to 
> congestion?
>
> As  a side note, this configuration would not be needed if we would 
> have an equivalent of the MLD protocol , to let LLN nodes announce 
> their interest in specific multicast groups.  One specific solution 
> (in case the BR is also an RPL DODAG root) is for nodes to use 
> standard RPL DAOs containing multicast addresses of interest, to 
> advertize the multicast groups of interest to the BR which can then 
> automatically set up the 'filtering rules'. But this is probably 
> beyond the current MPL spec ;-)
>
> regards,
>
> Esko
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Robert Cragie
> *Sent:* Thursday 1 November 2012 9:31
> *To:* [email-masked]
> *Subject:* Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
>
> Hi Dario,
>
> Some comments inline. I have also attached some diagrams which 
> hopefully help to illustrate some of the thought processes we went 
> through when implementing and testing between the ZigBee IP vendors 
> (comments welcome). Apologies in advance for the PDF format but ASCII 
> art would have been difficult :-)
>
> Robert
>
>     Yes, I'd like to try clarify why link-local scope was suggested
>     for the *outer* header. The reasons were:
>
>      1. Link-local scope is the only scope where the boundaries are
>         well defined (i.e. on the link). Higher scopes are not
>         well-defined and can cover wide domains depending on network
>         configuration and administration.
>
> specific. If link-local encapsulation is always used then providing 
> the MPL forwarder rules are clear, the MPL domain is then entirely 
> bounded by the MPL forwarders and there is no question regarding 
> address scope and administration thereof. This cleanly covers Peter's 
> case as well where he wants to forward into another PAN - it would be 
> processed internally as an original non-MPL packet and then be 
> "launched" into the other PAN using LL encapsulation for that PAN. 
> Using other scopes for the outer header would still work but then 
> there is the issue of administering the scope. However, this would 
> need to be done in the case where no encapsulation is done anyway.</RCC>
>
> router anyway irrespective of the scope of the outer header to see if 
> it needs to be processed - it is the inner header which counts there 
> and the comments about multicast groups come into play in that 
> discussion. But I agree using link-local makes that decision easy and 
> somewhat clearer</RCC>
>
> On Oct 31, 2012, at 3:54 AM, peter van der Stok<[email-masked]>  <mailto:[email-masked]>  wrote:
>   
>
>     Hi Jonathan,
>
>       
>
>         On Oct 30, 2012, at 4:46 AM, Don Sturek<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>           
>
>             Hi Peter,
>
>               
>
>             On 10/30/12 1:34 AM, "peter van der Stok"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>               
>
>                 Hi Don,
>
>                   
>
>                     On 10/29/12 3:44 AM, "peter van der Stok"<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>                       
>
>                         Dear WG,
>
>                           
>
>                           
>
>                         [email-masked]  <mailto:[email-masked]>
>
>             [email-masked]  <mailto:[email-masked]>
>
> [email-masked]  <mailto:[email-masked]>
> [email-masked]  <mailto:[email-masked]>
> ------------------------------------------------------------------------
> 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.

---

From: peter van der Stok <[email-masked]>
Date: Thu, 01 Nov 2012 14:11:37 +0100

Hi all,

using link-local scope on the outer header is OK with me.
I have no ideas about using something else than HbH MPL option.
As long as a MPL message created on a host within the MPL domain with 
the MPL option can be forwarded wihin the zone without encapsulation,
my concern about payload size is minimized.(last case of Robert's 
HbHTunnelMcast-v7 cases).

Can some text be added in section 5.3 like:
When the multicast destination address in the original MPL message is a 
unicast prefix multicast address and the
  the unicast prefix of the forwarder is not a prefix of the unicast 
prefix of the MC address, the forwarder ignores the message.

I think that would limit the forwarding to a subnet identified by a 
prefix while routers to the subnet continue to forward the message.

Apologies for confusing things.

peter

Jonathan Hui (johui) schreef op 2012-11-01 04:54:
> Hi Dario,
>
> You've made good points on why restricting to link-local scope would
> be simpler overall. Except for point 2, non-MPL aware routers will 
> not
> simply forward encapsulated multicast datagrams as long as the MPL
> Option type has the highest order bits set to indicate that the
> processing node discard the packet if it does not recognize the
> option.
>
> However, restricting to link-local scope does not solve Peter's use
> case of limiting the multicast dissemination to a subset of devices.
> Having a non-link-local MPL scope is one method to solve his problem.
> Granted, the devices within each MPL scope zone needs to be 
> configured
> with an MPL multicast address that identifies the MPL multicast scope
> zone. One way forward is to have the draft explicitly indicate that 
> is
> a necessary configuration, and leave the actual configuration method
> out of scope. Of course, there are many ways one could configure an
> interface (including manual configuration), so that is one argument
> for leaving it out of scope.
>
> Another possible solution is to include an "MPL domain" identifier
> within the Hop-by-Hop Option itself rather than using the IPv6
> Destination Address. Still requires some way to configure devices 
> with
> an MPL domain.
>
> Yet another solution that was discussed is to include some kind of 
> Hop
> Limit field in the Hop-by-Hop Option. But that brought up
> complications with what happens with a devices first receives a
> messages with different Hop Limit values.
>
> One final point, if we restrict MPL scope to link-local, then we 
> could
> use a Destination Option instead of a Hop-by-Hop Option.
> Alternatively, we could even encapsulate using UDP.
>
> Thoughts (from Dario, Peter, and the rest of the WG)?
>
> --
> Jonathan Hui
>
> On Oct 31, 2012, at 4:22 PM, Dario Tedeschi <[email-masked] [1]>
> wrote:
>
>> * Link-local scope is the only scope where the boundaries are well
>> * With a higher scope, there is a chance that non-MPL aware routers
>> may simply forward encapsulated multicast datagrams (MPL HbH option
>> and all). We wouldn't want MPL datagrams to leak outside of an MPL
>> domain.
>> * A higher scope complicates the forwarding logic that needs to be
>> decapsulate or not. Granted, the use of an MPL group would mitigate
>> this problem to a degree, but link-local scope would make the
>> decision to decapsulate very obvious and simple.
>>
>> * In conjunction with 3. Link-local scope also makes it easier for
>>> If the LLN border router is an MPL forwarder, it can forward MPL
>>> multicast packets between different MPL multicast scope zones. To
>>> be explicit, if the original multicast packet's destination
>>> address has link-local scope, the MPL forwarder should not forward
>>> the packet again. If the original multicast packet's destination
>>> has a scope larger than the MPL multicast scope, then the MPL
>>> forwarder needs to forward the packet to other MPL multicast scope
>>> zones (which may or may not involve different interfaces).
>>>
>>>> To be absolutely sure: the MPL multicast scope can be
>>>> link-local, ULA or site-local? meaning the LLN border router can
>>>> be a MPL forwarder?
>>>>> On Oct 30, 2012, at 4:46 AM, Don Sturek <[email-masked]>
>>>>> wrote:
>>>>>
>>>>>> Hi Peter,
>>>>>>
> Links:
> ------
> [1] mailto:[email-masked]

---

From: Don Sturek <[email-masked]>
Date: Thu, 01 Nov 2012 06:13:26 -0700

Hi Esko,

I think much of what you write about below should be the subject of a
different I-D.

Back at an IETF a few years ago, we submitted a draft to v6ops that became
part of the problem statement for homenet.   One topic that I have not seen
addressed is how to determine the boundaries of a site scope multicast
(related to your point on configuring the border router for multicast
traffic).   I still think such a draft would be useful.

Also, the second paragraph might also be the subject of another interesting
I-D (perhaps for homenet).

Don

From:  "Dijk, Esko" <[email-masked]>
Date:  Thursday, November 1, 2012 5:26 AM
To:  "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject:  Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

Hi Robert,
 
these are very useful diagrams.  I just wanted to point out for page 6,
³Site local multicast originating externally², that there is probably also
configuration required (in the BR) of what multicast traffic is allowed by
the BR onto the LLN.  I assume that not all multicast traffic from the
high-speed backbone network should be forwarded onto the LLN into the MPL
domain as that could lead to congestion?
 
As  a side note, this configuration would not be needed if we would have an
equivalent of the MLD protocol , to let LLN nodes announce their interest in
specific multicast groups.  One specific solution (in case the BR is also an
RPL DODAG root) is for nodes to use standard RPL DAOs containing multicast
addresses of interest, to advertize the multicast groups of interest to the
BR which can then automatically set up the Œfiltering rules¹. But this is
probably beyond the current MPL spec ;-)
 
regards,
Esko

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Cragie
Sent: Thursday 1 November 2012 9:31
To: [email-masked]
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02
 
Hi Dario,

Some comments inline. I have also attached some diagrams which hopefully
help to illustrate some of the thought processes we went through when
implementing and testing between the ZigBee IP vendors (comments welcome).
Apologies in advance for the PDF format but ASCII art would have been
difficult :-)

Robert

On 31/10/2012 11:22 PM, Dario Tedeschi wrote:
> 1. Link-local scope is the only scope where the boundaries are well defined
> (i.e. on the link). Higher scopes are not well-defined and can cover wide
> domains depending on network configuration and administration.

1. With a higher scope, there is a chance that non-MPL aware routers may
simply forward encapsulated multicast datagrams (MPL HbH option and all). We
wouldn't want MPL datagrams to leak outside of an MPL domain.
<RCC>Which is why I think the encapsulation rules do need to be pretty
specific. If link-local encapsulation is always used then providing the MPL
forwarder rules are clear, the MPL domain is then entirely bounded by the
MPL forwarders and there is no question regarding address scope and
administration thereof. This cleanly covers Peter's case as well where he
wants to forward into another PAN - it would be processed internally as an
original non-MPL packet and then be "launched" into the other PAN using LL
encapsulation for that PAN. Using other scopes for the outer header would
still work but then there is the issue of administering the scope. However,
this would need to be done in the case where no encapsulation is done
anyway.</RCC>

1. A higher scope complicates the forwarding logic that needs to be
implemented in an MPL router. The complication comes when a router receives
an MPL datagram and needs to figure out whether to decapsulate or not.
Granted, the use of an MPL group would mitigate this problem to a degree,
but link-local scope would make the decision to decapsulate very obvious and
simple.
<RCC>I think it would have to be effectively decapsulated at every router
anyway irrespective of the scope of the outer header to see if it needs to
be processed - it is the inner header which counts there and the comments
about multicast groups come into play in that discussion. But I agree using
link-local makes that decision easy and somewhat clearer</RCC>

1. In conjunction with 3. Link-local scope also makes it easier for an MPL
router to determine if the inner multicast address is one that a higher
layer (or an app) may be interested in.
<RCC>Agree that the rules are clearer for link-local</RCC>

1.  

- Dario

The current draft does not place any restrictions on the MPL multicast
scope.
 
If the LLN border router is an MPL forwarder, it can forward MPL multicast
packets between different MPL multicast scope zones.  To be explicit, if the
original multicast packet's destination address has link-local scope, the
MPL forwarder should not forward the packet again.  If the original
multicast packet's destination has a scope larger than the MPL multicast
scope, then the MPL forwarder needs to forward the packet to other MPL
multicast scope zones (which may or may not involve different interfaces).

--
Jonathan Hui
 
On Oct 31, 2012, at 3:54 AM, peter van der Stok <[email-masked]>
<mailto:[email-masked]>  wrote:
 
> Hi Jonathan,
>  
> To be absolutely sure: the MPL multicast scope can be link-local, ULA or
> site-local? meaning the LLN border router can be a MPL forwarder?
>> <mailto:[email-masked]>  wrote:
>>  
>>> Hi Peter,
>>>  

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
[email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Thu, 01 Nov 2012 16:08:23 +0100

Hi Michael,

It is related to the scope of the multicast, but not in the 
administrative sense, but in an operational sense when wireless 
forwarders receive MPL messages and they should be able to filter only 
those messages that are targeted to the subnet of which they are part.

I explained the case earlier with an example.

Two border routers are connected to two 802.15.4 networks, N1 and N2. 
The nodes of N1 have a different unicast prefix from the nodes of N2.
The nodes of N1 receive packets coming from nodes of N2 and vice versa 
because the groups are closely spaced.
A node A1 in group N1 wants to send a multicast to a group G1 of nodes 
in N1.
The group members of G1 share a Unicast prefix multicast address with 
the unicast prefix belonging to group N1 nodes.
Node A1 uses this MC address when sending a message.
To my current understanding, MPL passes the message without 
encapsulation on to all forwarders in networks N1 and N2.
My hope was to limit the reception to forwarders in group N1 only.
That suggests a filter at reception on the unicast prefix, when the 
multicast address is a unicast prefix multicast address.

Michael Richardson schreef op 2012-11-01 15:15:
>>>>>> "peter" == peter van der Stok <[email-masked]> writes:
>     peter> As long as a MPL message created on a host within the MPL
> domain with the MPL
>     peter> option can be forwarded wihin the zone without 
> encapsulation,
>     peter> my concern about payload size is minimized.(last case of 
> Robert's
>     peter> HbHTunnelMcast-v7 cases).
>
>     peter> Can some text be added in section 5.3 like:
>
>     peter> When the multicast destination address in the original MPL
> message is a
>     peter> unicast prefix multicast address and the
>     peter> the unicast prefix of the forwarder is not a prefix of the
> unicast prefix of
>     peter> the MC address, the forwarder ignores the message.
>
> Peter, I want to capture this into a ticket somewhere, but I'm 
> unclear
> if this relates to determining the scope of the MPL domain, or if 
> it's
> related to another problem that I don't yet understand.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 02 Nov 2012 19:46:55 -0400

see inline

peter van der Stok <[email-masked]> wrote:
    peter> It is related to the scope of the multicast, but not in the
    peter> administrative sense, but in an operational sense when
    peter> wireless forwarders receive MPL messages and they should be
    peter> able to filter only those messages that are targeted to the
    peter> subnet of which they are part.

Is this about configuring multicast (hardware) filters so that the wrong
nodes aren't woken up?
Is the case you speak up articulated by one of Robert's diagrams?

    peter> I explained the case earlier with an example.

Yes, I had asked a question about that too.  I didn't understand how
the two networks overlapped.  Do they share the same 15.4 key material?
Do they have the same beacons?

My feeling is that you are solving a problem which exists on paper, but
not in a real 15.4 network.  But, I could be completely wrong.

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

---

From: peter van der Stok <[email-masked]>
Date: Mon, 05 Nov 2012 13:23:29 +0100

Hi Michael,

The answer to your question is given by the scenario of Dario that I 
reproduced below.

Actions  4 and 5 describe what I intended to limit the forwarding.

In addition I like to mention that when a multicast is intended for a 
group with members in N2 and N1
the multicast address could have a prefix that is a prefix to Fd01::/64 
and Fd02::/64.
For example the MC address is then FF35:0040:FD0::1.
In accordance, I suggest that all forwarders in N1 and in N2 accept and 
forward the message.

As an aside I like to mention that BR1 and BR2 use the same channel for 
802.15.4 because often there are many physical and organisational 
constraints who may dictate such an alocation.

Greetings,

Peter

-------- DArio scenario     -------

Example: Two border routers (BR1 and BR2) each forming a network:

--- Network 1 (BR1) ---
Unicast prefix: FD01::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD01::/96

--- Network 2 (BR2) ---
Unicast prefix: FD02::/64
Unicast-prefix-based multicast address prefix: FF35:0040:FD02::/96
1.	A non-MPL aware node in network 1 wishes to send a multicast to all 
nodes in network 1.
2.	It sends to multicast address FF35:0040:FD01::1, un-encapsulated.
3.	The packet is received by a MPL router in network 2 (N2R1).
4.	N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, 
therefore, does not pass the packet up.
5.	N2R1 finds no matching routing information for FF35:0040:FD01::1 and 
does not forward the packet. The packet is, therefore, discarded.
6.	The packet is also received by a MPL router in network 1 (N1R1).
7.	N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes 
a copy of the packet up. Note: This would depend on whether or not any 
higher layers were actually interested in the mc group. Also, this step 
is not a prerequisite for the next step to occur.
8.	N1R1 finds matching routing information for FF35:0040:FD01::1, 
because it is a member of network FD01::/64
9.	N1R1 encapsulates the packet with a MPL HbH option such that the 
outer and inner destination addresses appear as: 
[FF02::MPL][FF35:0040:FD01::1], respectively.
10.	N1R1 transmits the new resulting packet.
11.	The packet is received by another MPL router in network 1 (N1R2).
12.	Seeing that the destination address is FF02::MPL, N1R2 decapsulates 
the packet (i.e. the original packet exits the tunnel).
13.	N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes 
a copy of the inner packet up. Note: This step is not a prerequisite for 
the next step to occur.
14.	N1R2 also finds matching routing information for FF35:0040:FD01::1, 
because it is a member of network FD01::/64.
15.	N1R2 re-encapsulates the packet with the *original* MPL HbH option 
such that the outer and inner destination addresses appear as: 
[FF02::MPL][FF35:0040:FD01::1], respectively.
16.	N1R2 transmits the resulting packet.
17.	The packet is received by yet another MPL router in network 2 
(N2R2).
18.	Seeing that the destination address is FF02::MPL, N2R2 decapsulates 
the packet (i.e. the original packet exits the tunnel).
19.	N2R2 finds no matching routing information or listener for 
FF35:0040:FD01::1 and, therefore, discards the packet.

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Mon, 5 Nov 2012 13:27:18 +0000

Hi Peter,

To reiterate my thoughts - this works because the IPv6 multicast address identifying the endpoints also identifies the MPL domain.  How would you limit the scope of disseminating a message sent to a well-known IPv6 multicast address?  Or is the answer (i) we don't support anything other than unicast-prefix-based multicast addresses or (ii) we don't limit the dissemination scope sent to anything else?

The options I see:

1) Use the same IPv6 multicast address for identifying both endpoints and MPL domain.
1a) MPL is not used to disseminate packets destined to other IPv6 multicast addresses.
1b) MPL may be used to disseminate packets destined to other IPv6 multicast addresses, but will disseminate across any connected region of MPL forwarders.

In supporting the cases above, a well-known link-local multicast address is used in the outer IPv6 header when encapsulation is used.  The outer header's MPL Option and the inner header's IPv6 destination address is used to determine whether to (i) pass up to higher layers and (ii) forward the packet.

If we decide to support inclusion of the MPL Option without encapsulation, then a forwarder needs to understand that the MPL Option and IPv6 destination address in the same IPv6 header are used to determine (i) pass up to higher layers and (ii) forward the packet.

2) Decouple the concept of MPL domain and application endpoint identifiers.
2a) Identify MPL domain using outer header's IPv6 destination address.
2b) Identify MPL domain using "instance" field in MPL Option.

Both cases above would allow limiting the dissemination scope of any arbitrary IPv6 multicast address, including well-known addresses.  Furthermore, the forwarding decision is made using only information contained in a single IPv6 header - option 2a relies on the MPL Option and the IPv6 destination address of the outer header, option 2b relies only on information contained in the MPL Option.

Both options 1 and 2 require managing another identifier space.  Option 1 requires configuring the devices with a prefix.  Option 2a requires configuring devices with a multicast group.  Option 2b requires configuring devices with an MPL instance.

Option 1 avoids the need to carry a separate MPL domain identifier since it requires the IPv6 multicast addresses to use the same prefix that identifies the MPL domain.

Comments/thoughts?

--
Jonatan Hui

On Nov 5, 2012, at 7:23 AM, peter van der Stok <[email-masked]> wrote:

> Hi Michael,
> 
> The answer to your question is given by the scenario of Dario that I reproduced below.
> 
> In addition I like to mention that when a multicast is intended for a group with members in N2 and N1
> the multicast address could have a prefix that is a prefix to Fd01::/64 and Fd02::/64.
> In accordance, I suggest that all forwarders in N1 and in N2 accept and forward the message.
> 
> 
> As an aside I like to mention that BR1 and BR2 use the same channel for 802.15.4 because often there are many physical and organisational constraints who may dictate such an alocation.
> 
> Greetings,
> 
> Peter
> 
> 1.	A non-MPL aware node in network 1 wishes to send a multicast to all nodes in network 1.
> 4.	N2R1 finds no higher layer listening to FF35:0040:FD01::1 and, therefore, does not pass the packet up.
> 5.	N2R1 finds no matching routing information for FF35:0040:FD01::1 and does not forward the packet. The packet is, therefore, discarded.
> 7.	N1R1 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the packet up. Note: This would depend on whether or not any higher layers were actually interested in the mc group. Also, this step is not a prerequisite for the next step to occur.
> 8.	N1R1 finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64
> 9.	N1R1 encapsulates the packet with a MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
> 12.	Seeing that the destination address is FF02::MPL, N1R2 decapsulates the packet (i.e. the original packet exits the tunnel).
> 13.	N1R2 finds a higher layer listening to FF35:0040:FD01::1 and passes a copy of the inner packet up. Note: This step is not a prerequisite for the next step to occur.
> 14.	N1R2 also finds matching routing information for FF35:0040:FD01::1, because it is a member of network FD01::/64.
> 15.	N1R2 re-encapsulates the packet with the *original* MPL HbH option such that the outer and inner destination addresses appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
> 17.	The packet is received by yet another MPL router in network 2 (N2R2).
> 18.	Seeing that the destination address is FF02::MPL, N2R2 decapsulates the packet (i.e. the original packet exits the tunnel).
> 19.	N2R2 finds no matching routing information or listener for FF35:0040:FD01::1 and, therefore, discards the packet.
>

---

From: Robert Cragie <[email-masked]>
Date: Mon, 5 Nov 2012 15:55:11 +0000

Hi Jonathan,

Good summary.

The main issue with option 2a is that the inner packet then gets
effectively multicast tunneled (a slightly paradoxical concept but I was
reminded the term is used legitimately). In this case, it becomes difficult
to manipulate the inner packet as it should be forwarded verbatim. In this
case, the hop count is not decrement and emanates at the multiple tunnel
endpoints as if it had gone one hop. I remember this was not acceptable for
RPL HbH header encapsulation and that the inner packet had to have its hop
count decremented appropriately.

Attached is another revision of the diagrams which show the MPL domain
multicast encapsulation case.

Robert

On Mon, Nov 5, 2012 at 1:27 PM, Jonathan Hui (johui) <[email-masked]>wrote:

>
> Hi Peter,
>
> To reiterate my thoughts - this works because the IPv6 multicast address
> identifying the endpoints also identifies the MPL domain.  How would you
> limit the scope of disseminating a message sent to a well-known IPv6
> multicast address?  Or is the answer (i) we don't support anything other
> than unicast-prefix-based multicast addresses or (ii) we don't limit the
> dissemination scope sent to anything else?
>
> The options I see:
>
> 1b) MPL may be used to disseminate packets destined to other IPv6
> multicast addresses, but will disseminate across any connected region of
> MPL forwarders.
>
> In supporting the cases above, a well-known link-local multicast address
> is used in the outer IPv6 header when encapsulation is used.  The outer
> header's MPL Option and the inner header's IPv6 destination address is used
> to determine whether to (i) pass up to higher layers and (ii) forward the
> packet.
>
> If we decide to support inclusion of the MPL Option without encapsulation,
> then a forwarder needs to understand that the MPL Option and IPv6
> destination address in the same IPv6 header are used to determine (i) pass
> up to higher layers and (ii) forward the packet.
>
> Both cases above would allow limiting the dissemination scope of any
> arbitrary IPv6 multicast address, including well-known addresses.
>  Furthermore, the forwarding decision is made using only information
> contained in a single IPv6 header - option 2a relies on the MPL Option and
> the IPv6 destination address of the outer header, option 2b relies only on
> information contained in the MPL Option.
>
> Both options 1 and 2 require managing another identifier space.  Option 1
> requires configuring the devices with a prefix.  Option 2a requires
> configuring devices with a multicast group.  Option 2b requires configuring
> devices with an MPL instance.
>
> Option 1 avoids the need to carry a separate MPL domain identifier since
> it requires the IPv6 multicast addresses to use the same prefix that
> identifies the MPL domain.
>
> Comments/thoughts?
>
> --
> Jonatan Hui
>
> > 5.    N2R1 finds no matching routing information for FF35:0040:FD01::1
> and does not forward the packet. The packet is, therefore, discarded.
> > 7.    N1R1 finds a higher layer listening to FF35:0040:FD01::1 and
> passes a copy of the packet up. Note: This would depend on whether or not
> any higher layers were actually interested in the mc group. Also, this step
> > 12.   Seeing that the destination address is FF02::MPL, N1R2
> decapsulates the packet (i.e. the original packet exits the tunnel).
> > 13.   N1R2 finds a higher layer listening to FF35:0040:FD01::1 and
> passes a copy of the inner packet up. Note: This step is not a prerequisite
> for the next step to occur.
> > 14.   N1R2 also finds matching routing information for
> FF35:0040:FD01::1, because it is a member of network FD01::/64.
> > 18.   Seeing that the destination address is FF02::MPL, N2R2
> decapsulates the packet (i.e. the original packet exits the tunnel).

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 08 Nov 2012 12:04:07 -0800

On 05/11/2012 5:27 AM, Jonathan Hui (johui) wrote:
> Hi Peter,
>
> To reiterate my thoughts - this works because the IPv6 multicast address identifying the endpoints also identifies the MPL domain.

This depends on how one defines "MPL domain". Is it defined like a 
"routing domain", where a "routing domain"  is a collection of networked 
systems that operate a common routing protocol? Or is it defined as the 
area an mc address will cover. I think it should be the former, in which 
case FF02::MPL would identify the "MPL domain", since any router 
listening on FF02::MPL would be participating in the MPL protocol.

>    How would you limit the scope of disseminating a message sent to a well-known IPv6 multicast address?  Or is the answer (i) we don't support anything other than unicast-prefix-based multicast addresses or (ii) we don't limit the dissemination scope sent to anything else?

That is determined by routing information, and I'm not sure MPL should 
be trying to answer that question. MPL is not really a routing protocol, 
because it does not disseminate routing information. It's more a means 
of propagation. Routing information (implied or explicit) has to come 
from somewhere, though. And since I think MPL was written to support 
RPL's non-storing mode of operation, I think RPL should be responsible 
for providing that information. An example of implied routing 
information could be the prefix in a PIO used for address auto-config (a 
'la unicast-prefixed-based mc), while an example of explicit routing 
information might be a mc prefix in a RIO. If someone wants to use MPL 
without RPL, then routers have to either forward packets based on 
mc-scope alone or they'd have to define some means of disseminating 
routing information.

> On Nov 5, 2012, at 7:23 AM, peter van der Stok<[email-masked]>  wrote:
>
>> Hi Michael,
>>
>>> peter van der Stok<[email-masked]>  wrote: