Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 1 Nov 2012 15:28:42 +0000

If the draft indicates that the MPL domain scope is a required configuration parameter, would that be sufficient?

--
Jonathan Hui

On Oct 31, 2012, at 7:37 AM, roll issue tracker <[email-masked]> wrote:

> #105: trickle-mcast: how to determine scope of MPL domain
> 
> There's no explanation on how a node would determine what scope
> corresponds
> to a MPL domain. How would it do that without being given some additional
> information from the edge-router/s. I think what is needed, here, is some
> multicast routing information from the edge-router/s.
> 
> -- 
> -----------------------------+---------------------------------------------
> Reporter:  mcr@…            |      Owner:  draft-ietf-roll-trickle-mcast@…
>     Type:  defect           |     Status:  new
> Priority:  major            |  Milestone:
> Component:  trickle-mcast    |    Version:
> Severity:  In WG Last Call  |   Keywords:
> -----------------------------+---------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/105>
> roll <http://tools.ietf.org/wg/roll/>
>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 1 Nov 2012 15:56:45 +0000

[attempting to move the discussion to this ticket thread]

Peter has two concerns:
1) Encapsulation when the source and destination of a multicast packet are within the same MPL domain.
2) Limiting the physical extent of an MPL domain to a connected subset of devices within an LLN.

Restricting the MPL scope to link-local and requiring encapsulation for non-link-local multicast does not address either of Peter's concerns.

I think we can solve (2) by allowing the MPL scope to be non-link-local but still require encapsulation.  The outer IPv6 header's IPv6 Destination Address then serves to identify the MPL domain, with the IPv6 Destination Address carrying the IPv6 multicast group address for the MPL domain.  Of course, MPL interfaces would need to be configured with the appropriate IPv6 multicast group(s), but the actual configuration method can be left out-of-scope for this draft.

I think we can also solve (1) and (2) simultaneously if we require the IPv6 Destination Address to identify both the MPL domain and application endpoints.  Said differently, if the IPv6 Destination for the packet corresponds to the IPv6 multicast group address for an MPL domain, then no encapsulation is required.

Thoughts?

--
Jonathan Hui

---

From: Don Sturek <[email-masked]>
Date: Thu, 01 Nov 2012 09:38:14 -0700

Hi Jonathan,

I agree with the approach you outlined below (ie, require the IPv6
Destination Address to identify both the MPL domain and application
endpoints.  Said differently, if the IPv6 Destination for the packet
corresponds to the IPv6 multicast group address for an MPL domain, then no
encapsulation is required).

Don

On 11/1/12 8:56 AM, "Jonathan Hui (johui)" <[email-masked]> wrote:

>Restricting the MPL scope to link-local and requiring encapsulation for
>non-link-local multicast does not address either of Peter's concerns.
>
>I think we can solve (2) by allowing the MPL scope to be non-link-local
>but still require encapsulation.  The outer IPv6 header's IPv6
>Destination Address then serves to identify the MPL domain, with the IPv6
>Destination Address carrying the IPv6 multicast group address for the MPL
>domain.  Of course, MPL interfaces would need to be configured with the
>appropriate IPv6 multicast group(s), but the actual configuration method
>can be left out-of-scope for this draft.
>
>I think we can also solve (1) and (2) simultaneously if we require the
>IPv6 Destination Address to identify both the MPL domain and application
>endpoints.  Said differently, if the IPv6 Destination for the packet
>corresponds to the IPv6 multicast group address for an MPL domain, then
>no encapsulation is required.
>
>Thoughts?
>
>--
>Jonathan Hui
>
>> Reporter:  mcr@Š            |      Owner:
>>draft-ietf-roll-trickle-mcast@Š
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 1 Nov 2012 18:54:47 +0000

On Nov 1, 2012, at 10:10 AM, Michael Richardson <[email-masked]> wrote:

> Is there a reason to encapsulate other than the Path MTU discovery issue?
> I think it has to do with getting the packet to the seed, but I'm
> unclear on this.

The other reason to encapsulate is for clean removal of the MPL Option.  Removing the MPL Option would be fairly straightforward if that were the only IPv6 Option contained in an IPv6 Hop-by-Hop Option header.  But things get a bit hairy when other IPv6 Options exist.

> Am I understranding correctly: if the packet originates in the LLN from
> an MPL aware node, then encapsulation is not necessary: the originator
> knows about the Hop-by-Hop option, and takes that into account for Path
> MTU calculations.
> 
> Is this Peter's concern?

Peter's primary concern is to eliminate any header overhead caused by encapsulation.  But you are correct that a MPL-aware node can take the MPL Option into account in Path MTU calculations.

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 01 Nov 2012 17:59:21 -0700

I'm not so sure. What if, for example, I connected my BR to an existing 
network that already had say scope 4 (admin-scope) configured to cover a 
wider domain than just the PAN. I then could not configure the BR to 
report 4 as the scope of the PAN (the "MPL scope"). Yes, one could use 
scope 3, but it is currently reserved. Besides, it wouldn't really solve 
the problem, if you consider that scope 3 could quite easily also cover 
a wider domain than just the PAN.

This is where unicast-prefix-based multicast addressing would become 
useful. It would remove the need for an "MPL scope", since the MPL 
domain would be defined by the PAN's prefix.

- Dario

On 01/11/2012 8:28 AM, Jonathan Hui (johui) wrote:
> On Oct 31, 2012, at 7:37 AM, roll issue tracker<[email-masked]>  wrote:
>
>> Ticket URL:<http://trac.tools.ietf.org/wg/roll/trac/ticket/105>
>> roll<http://tools.ietf.org/wg/roll/>
>>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 2 Nov 2012 01:13:23 +0000

Hi Dario,

Unicast-prefix-based multicast addresses also contain a scope identifier.  So while the prefix does bound the scope, the scope of a prefix can contain multiple scopes.

In any case, I don't think I properly articulated what I had in mind in my email below.  It seems that we are converging on a definition where an MPL domain is defined by the IPv6 multicast address that interfaces subscribe to.  In other words, an IPv6 multicast address identifies an MPL domain.  All MPL multicast packets containing an MPL Option must have the IPv6 Destination Address set to the MPL domain that they are being transported in.  If an MPL forwarder wants to forward a multicast packet within an MPL domain and that multicast packet does not have an IPv6 Destination Address corresponding to the domain's IPv6 multicast address, then the forwarder MUST encapsulate it.  So now it becomes a simple address match rather whether an IPv6 address is within the scope zone.

Does that solve the issue?

--
Jonathan Hui

On Nov 1, 2012, at 5:59 PM, Dario Tedeschi <[email-masked]> wrote:

> I'm not so sure. What if, for example, I connected my BR to an existing network that already had say scope 4 (admin-scope) configured to cover a wider domain than just the PAN. I then could not configure the BR to report 4 as the scope of the PAN (the "MPL scope"). Yes, one could use scope 3, but it is currently reserved. Besides, it wouldn't really solve the problem, if you consider that scope 3 could quite easily also cover a wider domain than just the PAN.
> 
> This is where unicast-prefix-based multicast addressing would become useful. It would remove the need for an "MPL scope", since the MPL domain would be defined by the PAN's prefix.
> 
> - Dario
> 
>

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 01 Nov 2012 18:47:51 -0700

I don't understand what benefit is gained by allowing the use of 
non-link-local in the outer header, if encapsulation is required. 
Supporting both link-local and higher in the outer header just servers 
to complicate the forwarder.

Is item 2 a requirement that a subset of devices in the LLN participate 
in MPL forwarding and others don't, or is it that there are two MPL 
domains, or is it that one subset of devices are listening on multicast 
address A while others are listening on multicast address B? In any 
case, I don't see how the use of link-local scope in the *outer* header 
would not work.

As for encapsulation, using an MPL multicast address of the from 
FF02::00XX, in the outer header, would only add three bytes to the 
packet after 6lowpan compression.

- Dario

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Fri, 2 Nov 2012 02:12:57 +0000

On Nov 1, 2012, at 6:47 PM, Dario Tedeschi <[email-masked]> wrote:

> I don't understand what benefit is gained by allowing the use of non-link-local in the outer header, if encapsulation is required. Supporting both link-local and higher in the outer header just servers to complicate the forwarder.

The purpose is to limit the extent to which MPL disseminates a packet to something smaller than the entire LLN (item 2).

> Is item 2 a requirement that a subset of devices in the LLN participate in MPL forwarding and others don't, or is it that there are two MPL domains, or is it that one subset of devices are listening on multicast address A while others are listening on multicast address B? In any case, I don't see how the use of link-local scope in the *outer* header would not work.

As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message.  If we use a link-local destination address in the outer header, how do you propose to limit the region?

> As for encapsulation, using an MPL multicast address of the from FF02::00XX, in the outer header, would only add three bytes to the packet after 6lowpan compression.

I agree.

Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list?

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 02 Nov 2012 10:22:21 -0700

Ok, so an entire multicast address defines an MPL domain. Sending to a 
multicast address, that does not match an MPL domain's address, requires 
encapsulation. So if an MPL domain had been assigned an address 
FF05::1234 and a device sends to FF05::1235 or FF04::1234, it must 
encapsulate.

This would work, but we've also added the need for devices in the 
network to be told what addresses are MPL addresses (i.e. routing 
information). In my example above, devices would have to be told that 
FF05::1234 is an MPL domain adddress. If we take this approach, I think 
we should also define how this information is disseminated.

In one of my previous emails, I suggested adding a RIO to RPL DIO 
advertisements. If we also allow prefix lengths less than 128, multiple 
MPL addresses could be aggregated by one RIO. So instead of a simple 
address match, a device would use longest-prefix match, just like it 
would for unicast forwarding/sending.

- Dario

On 01/11/2012 6:13 PM, Jonathan Hui (johui) wrote:
> On Nov 1, 2012, at 5:59 PM, Dario Tedeschi<[email-masked]>  wrote:
>

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 02 Nov 2012 12:34:07 -0700

On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote:
> On Nov 1, 2012, at 6:47 PM, Dario Tedeschi<[email-masked]>  wrote:
>

Isn't that what multicast groups and/or unicast-prefix-based multicasts 
are for? That is to say, to reach a defined set of devices.

> As mentioned above, the purpose is to limit the physical extent of MPL forwarders that disseminate a message.  If we use a link-local destination address in the outer header, how do you propose to…

The destination in the inner header determines if the packet needs to be 
forwarded or not, or forwarded on a different interface.

> Maybe you could describe a concrete example of how using link-local addresses in the outer header would address Peter's scenario that he posted to the list?

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.

Note:
I chose a non-MPL aware originator of a multicast packet, because I 
wanted to be more thorough. I could have chosen an example where the 
originator of the packet *was* a MPL aware device. In such a case, it 
would have encapsulated with its own MPL HbH option as if it were 
forwarding the packet (i.e. outer and inner destinations would have been 
[FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL aware 
devices sending non-link-local multicasts is the problem of fan-out: If 
such a device multicasts/broadcasts at the link-layer for IPv6 
multicasts, then many MPL routers may hear the packet and try forward it 
with their own seeds. Although this wouldn't cause a real packet-storm, 
it would cause something close to it, depending on how many routers were 
in earshot of the originator. However, this is a general problem that 
has nothing to do with MPL's address scope.

Secondly, notice that FF02::MPL can be viewed as a well defined address 
for a "tunnel exit point". It just so happens that it actually 
identifies multiple physical "exit points".

- Dario

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 03 Nov 2012 11:08:43 +0900

I don't see much benefit of dynamically allocating an MPL domain address 
and advertising it via a routing protocol, as each node can be 
pre-configured to a member of an MPL domain.

Isn't it simpler if we can register a fixed MPL domain address with IANA 
(for each multicast scope that uses MPL)?

Yoshihiro Ohba

(2012/11/03 2:22), Dario Tedeschi wrote:
> multicast address, that does not match an MPL domain's address, 
> requires encapsulation. So if an MPL domain had been assigned an 
> address FF05::1234 and a device sends to FF05::1235 or FF04::1234, it 
> must encapsulate.
>
> FF05::1234 is an MPL domain adddress. If we take this approach, I 
> think we should also define how this information is disseminated.
>
> advertisements. If we also allow prefix lengths less than 128, 
> multiple MPL addresses could be aggregated by one RIO. So instead of a 
> simple address match, a device would use longest-prefix match, just 
> like it would for unicast forwarding/sending.
>
> - Dario
>
>> Unicast-prefix-based multicast addresses also contain a scope 
>> identifier.  So while the prefix does bound the scope, the scope of a 
>> prefix can contain multiple scopes.
>>
>> In any case, I don't think I properly articulated what I had in mind 
>> in my email below.  It seems that we are converging on a definition 
>> where an MPL domain is defined by the IPv6 multicast address that 
>> interfaces subscribe to.  In other words, an IPv6 multicast address 
>> identifies an MPL domain.  All MPL multicast packets containing an 
>> MPL Option must have the IPv6 Destination Address set to the MPL 
>> domain that they are being transported in.  If an MPL forwarder wants 
>> to forward a multicast packet within an MPL domain and that multicast 
>> packet does not have an IPv6 Destination Address corresponding to the 
>> domain's IPv6 multicast address, then the forwarder MUST encapsulate 
>> it.  So now it becomes a simple address match rather whether an IPv6 
>> address is within the scope zone.
>>
>>> I'm not so sure. What if, for example, I connected my BR to an 
>>> existing network that already had say scope 4 (admin-scope) 
>>> configured to cover a wider domain than just the PAN. I then could 
>>> not configure the BR to report 4 as the scope of the PAN (the "MPL 
>>> scope"). Yes, one could use scope 3, but it is currently reserved. 
>>> Besides, it wouldn't really solve the problem, if you consider that 
>>> scope 3 could quite easily also cover a wider domain than just the PAN.
>>>
>>>> If the draft indicates that the MPL domain scope is a required 
>>>> configuration parameter, would that be sufficient?
>>>>
>>>> -- 
>>>> Jonathan Hui
>>>>
>>>> On Oct 31, 2012, at 7:37 AM, roll issue 
>>>> tracker<[email-masked]>   wrote:
>>>>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Sat, 3 Nov 2012 05:18:30 +0000

Hi Dario,

Thanks for the detailed example - I see our disconnect now.

With your approach (require link-local in the outer header), the IPv6 multicast address identifies the application endpoints *and* the MPL domain.  For that reason, your approach really only needs a single identifier to both limit the flooding scope and determine the application endpoints.  I can see how that would work (as you demonstrated) if we make the restriction that the IPv6 multicast addresses used within an MPL domain have the same prefix that identifies the MPL domain itself.  The trouble comes when you want to support the full generality that IPv6 multicast addresses used by application endpoints can be arbitrary.

For example, how does MPL support an application that subscribes to a well-known non-link-local IPv6 multicast address?  I guess one approach is to say that if the IPv6 multicast address is not a unicast-prefix-based multicast address, then it disseminates across the entire region of connected MPL forwarders.

One minor point with your approach is that the delivery requires processing the MPL Option of the outer header and the inner IPv6 header.  That isn't so nice from an architectural perspective, but that is what we did with RFC 6553.

In my approach (allow non-link-local in the outer header), I tried to separate out the identifiers for the application endpoints and the MPL domain.  That is why I used the outer header's destination address to identify the MPL domain and the inner header's destination address to identify the application endpoints.  With this approach, it actually becomes feasible to address situations where the devices within an MPL domain subscribe to arbitrary IPv6 multicast addresses - not just ones that are based on the unicast prefix.

--
Jonathan Hui

On Nov 2, 2012, at 12:34 PM, Dario Tedeschi <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 1, 2012, at 6:47 PM, Dario Tedeschi <[email-masked]><mailto:[email-masked]> wrote:

Isn't that what multicast groups and/or unicast-prefix-based multicasts are for? That is to say, to reach a defined set of devices.

The destination in the inner header determines if the packet needs to be forwarded or not, or forwarded on a different interface.

I agree.

--- Network 2 (BR2) ---

  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.

Note:
I chose a non-MPL aware originator of a multicast packet, because I wanted to be more thorough. I could have chosen an example where the originator of the packet *was* a MPL aware device. In such a case, it would have encapsulated with its own MPL HbH option as if it were forwarding the packet (i.e. outer and inner destinations would have been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL aware devices sending non-link-local multicasts is the problem of fan-out: If such a device multicasts/broadcasts at the link-layer for IPv6 multicasts, then many MPL routers may hear the packet and try forward it with their own seeds. Although this wouldn't cause a real packet-storm, it would cause something close to it, depending on how many routers were in earshot of the originator. However, this is a general problem that has nothing to do with MPL's address scope.

Secondly, notice that FF02::MPL can be viewed as a well defined address for a "tunnel exit point". It just so happens that it actually identifies multiple physical "exit points".

- Dario

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 08 Nov 2012 11:10:58 -0800

Hi Jonathan

On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
> With your approach (require link-local in the outer header), the IPv6 
> multicast address identifies the application endpoints *and* the MPL 
> domain.  For that reason, your approach really only needs a single 
> identifier to both limit the flooding scope and determine the 
> application endpoints.
It depends on what you mean by MPL domain. In my view,  FF02::MPL 
identifies the MPL domain, while the inner IPv6 destination address 
identifies the application endpoint.

>  I can see how that would work (as you demonstrated) if we make the 
> restriction that the IPv6 multicast addresses used within an MPL 
> domain have the same prefix that identifies the MPL domain itself. 
>  The trouble comes when you want to support the full generality that 
> IPv6 multicast addresses used by application endpoints can be arbitrary.

The "generality", you talk of, is why protocols like MLD exist. MLD 
informs routers of mc addresses other devices are interested in. 
Essentially it provides routing information. How could we support the 
"full generality" of mc addresses without this information (whether 
implied or from something like MLD).  With this in mind, I don't 
understand the need for non-link-local scope in the outer header, 
because the "generality" you seek would be determined by the mc address 
of the original packet (i.e. the mc address of the inner header). All my 
approach is really saying is that only the original/inner mc address 
determines how far a packet will propagate, regardless of routing 
domain. MPL could just be one of many routing domains a mc packet must 
traverse before reaching its furthermost boundary. Or MPL may be the 
only routing domain, where the mc packet only reaches a sub-set of 
devices within the domain (i.e. a multicast group or a set based on 
unicast-prefix-based mc).

>
> For example, how does MPL support an application that subscribes to a 
> well-known non-link-local IPv6 multicast address?  I guess one 
> approach is to say that if the IPv6 multicast address is not a 
> unicast-prefix-based multicast address, then it disseminates across 
> the entire region of connected MPL forwarders.

Granted one could have a situation where all routers hear an mc packet 
that is only intended for a subset of devices, but that does not mean 
all routers need to forward that packet or pass it to a higher layer. 
Again, this would depend on the inner mc address and the routing 
information available to routers. The routers without the appropriate 
routing information would not forward. Similarly, routers without mc 
membership information from an app would not pass the packet to the next 
higher layer.

>
> One minor point with your approach is that the delivery requires 
> processing the MPL Option of the outer header and the inner IPv6 
> header.  That isn't so nice from an architectural perspective, but 
> that is what we did with RFC 6553.

Using non-link-local in the outer header does not mitigate that. The 
forwarder still needs to look at the inner header to determine if the 
inner mc address is one an app is listening on. In fact implementing 
this is a bit messy compared to my approach, because the forwarder has 
to look ahead into the packet before decapsulating. My approach always 
requires decapsulation before making any decision about where the packet 
must go next. It's simpler and more consistent. I've actually had the 
fortune/misfortune of implementing both and I can safely say the 
link-local approach was cleaner.

>
> In my approach (allow non-link-local in the outer header), I tried to 
> separate out the identifiers for the application endpoints and the MPL 
> domain.  That is why I used the outer header's destination address to 
> identify the MPL domain and the inner header's destination address to 
> identify the application endpoints.  With this approach, it actually 
> becomes feasible to address situations where the devices within an MPL 
> domain subscribe to arbitrary IPv6 multicast addresses - not just ones 
> that are based on the unicast prefix.

Firstly, yes I agree the inner destination address should determine the 
application endpoint. What I'm not clear on is why we need an MPL domain 
to cover more than the LLN or why we need to support multiple MPL 
domains in one LLN. Tf the latter case is required to allow for 
different sets of MPL propagation parameters, then I'd imagine that 
should rather be handled by the HbH option.

- Dario

>> Isn't that what multicast groups and/or unicast-prefix-based 
>> multicasts are for? That is to say, to reach a defined set of devices.
>>
>>
>> The destination in the inner header determines if the packet needs to 
>> be forwarded or not, or forwarded on a different interface.
>>
>>
>>  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.
>> 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.
>> 18. Seeing that the destination address is FF02::MPL, N2R2
>>     decapsulates the packet (i.e. the original packet exits the tunnel).
>> forwarding the packet (i.e. outer and inner destinations would have 
>> been [FF02::MPL][FF35:0040:FD01::1]). One complication of non-MPL 
>> aware devices sending non-link-local multicasts is the problem of 
>> fan-out: If such a device multicasts/broadcasts at the link-layer for 
>> IPv6 multicasts, then many MPL routers may hear the packet and try 
>> forward it with their own seeds. Although this wouldn't cause a real 
>> packet-storm, it would cause something close to it, depending on how 
>> many routers were in earshot of the originator. However, this is a 
>> general problem that has nothing to do with MPL's address scope.
>>
>> Secondly, notice that FF02::MPL can be viewed as a well defined 
>> address for a "tunnel exit point". It just so happens that it 
>> actually identifies multiple physical "exit points".
>>
>> - Dario
>>
>>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Nov 2012 15:22:16 -0500

>>>>> "Dario" == Dario Tedeschi <[email-masked]> writes:
    >> In my approach (allow non-link-local in the outer header), I
    >> tried to separate out the identifiers for the application
    >> endpoints and the MPL domain.  That is why I used the outer
    >> header's destination address to identify the MPL domain and the
    >> inner header's destination address to identify the application
    >> endpoints.  With this approach, it actually becomes feasible to
    >> address situations where the devices within an MPL domain
    >> subscribe to arbitrary IPv6 multicast addresses - not just ones

    Dario> Firstly, yes I agree the inner destination address should
    Dario> determine the application endpoint. What I'm not clear on is
    Dario> why we need an MPL domain to cover more than the LLN or why
    Dario> we need to support multiple MPL domains in one LLN. Tf the
    Dario> latter case is required to allow for different sets of MPL
    Dario> propagation parameters, then I'd imagine that should rather
    Dario> be handled by the HbH option.

So, I think we really need to hear some use cases for having multiple
MPL domains in one LLN.  Please exclude mDNS(ext) in the list.

-- 
Michael Richardson
-on the road-

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Thu, 8 Nov 2012 21:02:16 +0000

Hi Dario,

On Nov 8, 2012, at 11:10 AM, Dario Tedeschi <[email-masked]> wrote:

>> With your approach (require link-local in the outer header), the IPv6 multicast address identifies the application endpoints *and* the MPL domain.  For that reason, your approach really only needs a single identifier to both limit the flooding scope and determine the application endpoints.
> It depends on what you mean by MPL domain. In my view,  FF02::MPL identifies the MPL domain, while the inner IPv6 destination address identifies the application endpoint.

Let me introduce a new term to help move the discussion forward:  Dissemination Region - a connected set of MPL devices that attempt to forward the packet so that all devices receive the packet at least once.  Another definition may be: a region within which the SeedID must be unique.

>>  I can see how that would work (as you demonstrated) if we make the restriction that the IPv6 multicast addresses used within an MPL domain have the same prefix that identifies the MPL domain itself.  The trouble comes when you want to support the full generality that IPv6 multicast addresses used by application endpoints can be arbitrary.
> 
> The "generality", you talk of, is why protocols like MLD exist. MLD informs routers of mc addresses other devices are interested in. Essentially it provides routing information. How could we support the "full generality" of mc addresses without this information (whether implied or from something like MLD).  With this in mind, I don't understand the need for non-link-local scope in the outer header, because the "generality" you seek would be determined by the mc address of the original packet (i.e. the mc address of the inner header). All my approach is really saying is that only the original/inner mc address determines how far a packet will propagate, regardless of routing domain. MPL could just be one of many routing domains a mc packet must traverse before reaching its furthermost boundary. Or MPL may be the only routing domain, where the mc packet only reaches a sub-set of devices within the domain (i.e. a multicast group or a set based on unicast-prefix-based mc).

The original intent of MPL was to avoid any routing information within the Dissemination Region.  A router then only maintains state about what multicast addresses are of interest to devices within the Dissemination Region.

> Granted one could have a situation where all routers hear an mc packet that is only intended for a subset of devices, but that does not mean all routers need to forward that packet or pass it to a higher layer. Again, this would depend on the inner mc address and the routing information available to routers. The routers without the appropriate routing information would not forward. Similarly, routers without mc membership information from an app would not pass the packet to the next higher layer.

We have different thoughts on how a device determines whether or not to forward the packet.  You take a routing perspective, where a device determines whether or not to forward based on the identifier for the application endpoints.  In contrast, I view it as a device determines whether or not to forward based on the Dissemination Region it is in.  Note that in my view, the Dissemination Region does not have to have any relationship with the identifier for application endpoints.  In other words, you can configure the Dissemination Region without any knowledge of the multicast addresses that devices are interested in.

> Using non-link-local in the outer header does not mitigate that. The forwarder still needs to look at the inner header to determine if the inner mc address is one an app is listening on. In fact implementing this is a bit messy compared to my approach, because the forwarder has to look ahead into the packet before decapsulating. My approach always requires decapsulation before making any decision about where the packet must go next. It's simpler and more consistent. I've actually had the fortune/misfortune of implementing both and I can safely say the link-local approach was cleaner.

I'd argue that using non-link-local in the outer header helps to preserve the layering.
1) Processing the outer header allows a device to determine whether it is a part of the Dissemination Region and the packet was received before.
2) Processing the inner header allows a device to determine whether it should process the payload.

Can you explain why a device needs to "look ahead" into the packet before decapsulating when using a non-link-local outer header?

> Firstly, yes I agree the inner destination address should determine the application endpoint. What I'm not clear on is why we need an MPL domain to cover more than the LLN or why we need to support multiple MPL domains in one LLN. Tf the latter case is required to allow for different sets of MPL propagation parameters, then I'd imagine that should rather be handled by the HbH option.

Peter's use case involves having multiple Dissemination Regions within a single IEEE 802.15.4 PAN.  I agree, one could argue whether the devices should all be within the same PAN or different PANs based on the nearest border router.

During the WG meeting, people made a good argument that we actually don't know the answer - either because all the use cases are not obvious or because we don't understand all the consequences of each approach.  One proposal was to have the draft specify well-defined forwarding behavior that supports both situations.  For example:
1) If the outer header has an IPv6 Destination Address matching the link-local all-MPL-forwarders address, do …
2) Otherwise, do …

Then leave it up to those who are using this spec to determine what subset they want to use.  Not sure if this is a reasonable approach and would like to get feedback from the WG.

--
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Thu, 08 Nov 2012 23:55:53 +0000

Hi Dario,

Comments inline, bracketed by <RCC></RCC>

Robert

On 08/11/2012 7:10 PM, Dario Tedeschi wrote:
> because the "generality" you seek would be determined by the mc 
> address of the original packet (i.e. the mc address of the inner header). 
<RCC>Peter van der Stok had a use case where this might be useful 
whereby a PAN is subdivided into two subnets, using e.g. Prefix1 and 
Prefix2. A site local multicast would be encapsulated in a packet using 
a unicast prefix-based multicast for e.g. Prefix1. Then it would only be 
forwarded through Prefix1 subnet to maybe only one border router and 
emanate on another interface on that border router. Prefix2 MPL 
forwarders would not do anything. I don't see how you could do that with 
link local multicast as the inner packet's scope has no relation in this 
case.</RCC>
> All my approach is really saying is that only the original/inner mc 
> address determines how far a packet will propagate, regardless of 
> routing domain. MPL could just be one of many routing domains a mc 
> packet must traverse before reaching its furthermost boundary. Or MPL 
> may be the only routing domain, where the mc packet only reaches a 
> sub-set of devices within the domain (i.e. a multicast group or a set 
> based on unicast-prefix-based mc).
<RCC>In the last case, you don't need encapsulation of course</RCC>
> information available to routers.

<RCC>See above case where this may be different</RCC>
> The routers without the appropriate routing information would not 
> forward. Similarly, routers without mc membership information from an 
> app would not pass the packet to the next higher layer.
<RCC>
It is important to distinguish forwarding from processing.

1. In the unencapsulated case:

1a. Whether to forward or not is based in the destination address and 
the MPL option
1b. Whether to process or not is based in the destination address

2. In the MDM encapsulated case:

2a. Whether to forward or not is based in the outer destination address 
and the MPL option
2b. Whether to process or not is based in the inner destination address

3. In the LLM encapsulated case:

3a. Whether to forward or not is based in the inner destination address 
and the MPL option
3b. Whether to process or not is based in the inner destination address

When looking at choosing (2) or (3), consider some of these statements:

(1a) is consistent with (2a) but not consistent with (3a). On that 
basis, (2) makes more sense
(2b) and (3b) are the same, so both are acceptable
(2b) may seem inconsistent with (2a), i.e. basing the decision to 
process on the inner header, but clearly separates the endpoint domain 
from the forwarding domain. (3) cannot make that distinction.
</RCC>

> to look ahead into the packet before decapsulating. 
<RCC>I don't see that. It has to decapsulate anyway for processing. If 
the address means it doesn't get processed, it throws it away. The 
forwarding logic may come to the same conclusion.</RCC>
> My approach always requires decapsulation before making any decision 
> about where the packet must go next. It's simpler and more consistent. 
> I've actually had the fortune/misfortune of implementing both and I 
> can safely say the link-local approach was cleaner.
<RCC>I would disagree on the single point that  you need an additional 
mechanism for handling forwarding from the unencapsulated case. I agree 
it is a trivial addition but an addition nevertheless</RCC>
>> separate out the identifiers for the application endpoints and the 
>> MPL domain.  That is why I used the outer header's destination 
>> address to identify the MPL domain and the inner header's destination 
>> address to identify the application endpoints.  With this approach, 
>> it actually becomes feasible to address situations where the devices 
>> within an MPL domain subscribe to arbitrary IPv6 multicast addresses 
>> - not just ones that are based on the unicast prefix.
>
> Firstly, yes I agree the inner destination address should determine 
> the application endpoint. What I'm not clear on is why we need an MPL 
> domain to cover more than the LLN or why we need to support multiple 
> MPL domains in one LLN. Tf the latter case is required to allow for 
<RCC>It could be done that way but you are now introducing another 
"label" by which to determine forwarding when address scope an group ID 
seems perfectly adequate to me</RCC>

>>> The destination in the inner header determines if the packet needs 
>>> to be forwarded or not, or forwarded on a different interface.
>>>
>>>
>>>     mc group. Also, this step is not a prerequisite for the next
>>>     step to occur.
>>>     option such that the outer and inner destination addresses
>>>     appear as: [FF02::MPL][FF35:0040:FD01::1], respectively.
>>> originator of the packet *was* a MPL aware device. In such a case, 
>>> it would have encapsulated with its own MPL HbH option as if it were 
>>> fan-out: If such a device multicasts/broadcasts at the link-layer 
>>> for IPv6 multicasts, then many MPL routers may hear the packet and 
>>> try forward it with their own seeds. Although this wouldn't cause a 
>>> real packet-storm, it would cause something close to it, depending 
>>> on how many routers were in earshot of the originator. However, this 
>>> is a general problem that has nothing to do with MPL's address scope.
>>>

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 08 Nov 2012 17:40:16 -0800

On 08/11/2012 1:02 PM, Jonathan Hui (johui) wrote:
> Hi Dario,
>
> On Nov 8, 2012, at 11:10 AM, Dario Tedeschi<[email-masked]>  wrote:
>

OK, that makes sense to me.

> The original intent of MPL was to avoid any routing information within the Dissemination Region.  A router then only maintains state about what multicast addresses are of interest to devices within…

Yes I understand, but I'm not sure how we can avoid routing information, 
if we are to support sending to sub-sets of devices within one LLN 
(whether we use non-link-local or link-local in the outer header). To me 
it sounds like we are trying to offer what a storing network provides 
without actually storing any information on the routers. For unicasts, 
in RPL, this done by offloading the burden of storing routing 
information onto the RPL root node (i.e. source-routing). This works for 
unicasts, but it wouldn't work for multicasts.

> We have different thoughts on how a device determines whether or not to forward the packet.  You take a routing perspective, where a device determines whether or not to forward based on the identif…

OK I  see your point of view more clearly now. I assume then that a 
Dissemination Region would be defined by a non-link-local mc address 
prefix, and if so, how would MPL routers become aware of it? Without it 
how would a router be able to differentiate one Dissemination Region 
from another?

> Can you explain why a device needs to "look ahead" into the packet before decapsulating when using a non-link-local outer header?

Lets say the packet has outer and inner destination addresses 
[FF05::1234] and [FF05::5678], respectively. An app on a device 
receiving this packet, might be interested in [FF05::1234] or 
[FF05::5678] or both. Which version of the packet gets passed up: The 
entire MPL encapsulated one or just the inner packet or both. To get 
around this, I had to add a hack that would do two things:
1. If the network device is a member of [FF05::1234] and there is no 
IPv6-in-IPv6 encapsulation, then pass the packet up.
2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH option 
and the network device is a member of [FF05::5678], then decapsulate and 
pass the inner packet up.

Note that logic 2. required looking ahead at the inner header to 
determine if the mc address there was an address some higher layer was 
interested in. What made things even less palatable, was having to skip 
over potential extended headers just to determine whether or not the 
packet was encapsulated. Aside from passing mc packets up, the hack was 
also needed to decrement the hop-limit when forwarding.

Back then, there was no idea of having an IANA assigned MPL mc-group so 
I could not rely on a well-known non-link-local address. With a 
well-known MPL address a MPL router would be able to be a member of that 
group and always try decapsulate upon hearing a packet destined for that 
address. Without this MPL mc address using the link-local all-routers mc 
address, removed the need for the hack. This was because all routers are 
members of the all-routers group.

> Peter's use case involves having multiple Dissemination Regions within a single IEEE 802.15.4 PAN.  I agree, one could argue whether the devices should all be within the same PAN or different PANs…

  Or an argument for having multiple Destination Regions identified by 
some field in the HbH option.

> Then leave it up to those who are using this spec to determine what subset they want to use.  Not sure if this is a reasonable approach and would like to get feedback from the WG.

My current implementation is just such a hybrid, except that action 1 is 
decided by scope and not the full address. From an implementation point 
of view, I'd prefer not to have two code paths, but if it satisfies 
everyone's needs and we have an IANA assigned address, I can live with 
it. :-)

- Dario

---

From: peter van der Stok <[email-masked]>
Date: Fri, 09 Nov 2012 15:23:48 +0100

Hi Jonathan, Dario, Robert and all,

Given the discussion it is may be helpful when I elaborate a bit my 
example use case. For that purpose I have added a drawing in the PDF 
format (I apologize for the choice of PDF).
The  example does not represent an existing building, but is close 
enough to reality to warrant a look. I am sure that when IP-based 
wireless building control becomes successful more interesting and 
challenging examples will appear.
The drawing represents an office floor with a corridor in the middle. 
On both sides 3 areas are drawn representing open plan offices. I 
covered each open plan office and the corridor with one dissemination 
area (term proposed by Jonathan). Each dissemination area is covered by 
one network and one border router (as proposed by dario)
Example: 6 border routers (BR1,  BR2, BR3, …) each forming a network:

--- Network 2 (BR2) ---

ETC.

The nodes in all networks use the same communication channel.
For example, imagine the following scenario. A sensor in dissemination 
area 1 multicasts a message, m, to a set of nodes within dissemination 
area1.  Some forwarders in dissemination areas2-6 receive the multicast 
message as well. Because there are no destinations for the multicast 
message in dissemination areas2-6, it is better for the network load if 
the forwarders in dissemination areas2-6 do not forward the message.
In this network configuration the dissemination area is identical with 
a network.
 From a cost perspective (less border routers) it is more realistic if 
one network covers the whole floor. However, for the same reason as 
cited earlier, forwarders in dissemination areas2-6 should not forward 
messages originating in dissemination area 1.
I hope this helps
peter

Dario Tedeschi schreef op 2012-11-09 02:40:
>>>> With your approach (require link-local in the outer header), the 
>>>> IPv6 multicast address identifies the application endpoints *and* 
>>>> the MPL domain.  For that reason, your approach really only needs a 
>>>> single identifier to both limit the flooding scope and determine the 
>>>> application endpoints.
>> Let me introduce a new term to help move the discussion forward:  
>> Dissemination Region - a connected set of MPL devices that attempt to 
>> forward the packet so that all devices receive the packet at least 
>> once.  Another definition may be: a region within which the SeedID 
>> must be unique.
>
>>>>   I can see how that would work (as you demonstrated) if we make 
>>>> the restriction that the IPv6 multicast addresses used within an MPL 
>>> address of the original packet (i.e. the mc address of the inner 
>>> header). All my approach is really saying is that only the 
>>> original/inner mc address determines how far a packet will propagate, 
>>> regardless of routing domain. MPL could just be one of many routing 
>>> domains a mc packet must traverse before reaching its furthermost 
>>> boundary. Or MPL may be the only routing domain, where the mc packet 
>>> only reaches a sub-set of devices within the domain (i.e. a multicast 
>>> group or a set based on unicast-prefix-based mc).
>> The original intent of MPL was to avoid any routing information 
>> within the Dissemination Region.  A router then only maintains state 
>> about what multicast addresses are of interest to devices within the 
>> Dissemination Region.
>
> Yes I understand, but I'm not sure how we can avoid routing
> information, if we are to support sending to sub-sets of devices
> within one LLN (whether we use non-link-local or link-local in the
> outer header). To me it sounds like we are trying to offer what a
> storing network provides without actually storing any information on
> the routers. For unicasts, in RPL, this done by offloading the burden
> of storing routing information onto the RPL root node (i.e.
> source-routing). This works for unicasts, but it wouldn't work for
> multicasts.
>
>
>>
>>>> For example, how does MPL support an application that subscribes 
>>>> to a well-known non-link-local IPv6 multicast address?  I guess one 
>>> Granted one could have a situation where all routers hear an mc 
>>> packet that is only intended for a subset of devices, but that does 
>>> not mean all routers need to forward that packet or pass it to a 
>>> higher layer. Again, this would depend on the inner mc address and 
>>> the routing information available to routers. The routers without the 
>>> appropriate routing information would not forward. Similarly, routers 
>>> without mc membership information from an app would not pass the 
>>> packet to the next higher layer.
>> We have different thoughts on how a device determines whether or not 
>> to forward the packet.  You take a routing perspective, where a device 
>> determines whether or not to forward based on the identifier for the 
>> application endpoints.  In contrast, I view it as a device determines 
>> whether or not to forward based on the Dissemination Region it is in.  
>> Note that in my view, the Dissemination Region does not have to have 
>> any relationship with the identifier for application endpoints.  In 
>> other words, you can configure the Dissemination Region without any 
>> knowledge of the multicast addresses that devices are interested in.
>
> prefix, and if so, how would MPL routers become aware of it? Without
> it how would a router be able to differentiate one Dissemination
> Region from another?
>
>
>>
>>> Using non-link-local in the outer header does not mitigate that. 
>>> The forwarder still needs to look at the inner header to determine if 
>>> the inner mc address is one an app is listening on. In fact 
>>> implementing this is a bit messy compared to my approach, because the 
>>> forwarder has to look ahead into the packet before decapsulating. My 
>>> approach always requires decapsulation before making any decision 
>>> about where the packet must go next. It's simpler and more 
>>> consistent. I've actually had the fortune/misfortune of implementing 
>>> both and I can safely say the link-local approach was cleaner.
>> 1) Processing the outer header allows a device to determine whether 
>> it is a part of the Dissemination Region and the packet was received 
>> before.
>> Can you explain why a device needs to "look ahead" into the packet 
>> before decapsulating when using a non-link-local outer header?
>
> 2. If there is IPv6-in-IPv6 encapsulation and there is a MPL HbH
> option and the network device is a member of [FF05::5678], then
> decapsulate and pass the inner packet up.
>
> interested in. What made things even less palatable, was having to
> skip over potential extended headers just to determine whether or not
> the packet was encapsulated. Aside from passing mc packets up, the
> hack was also needed to decrement the hop-limit when forwarding.
>
> Back then, there was no idea of having an IANA assigned MPL mc-group
> so I could not rely on a well-known non-link-local address. With a
> well-known MPL address a MPL router would be able to be a member of
> that group and always try decapsulate upon hearing a packet destined
> for that address. Without this MPL mc address using the link-local
> all-routers mc address, removed the need for the hack. This was
> because all routers are members of the all-routers group.
>
>
>
>>
>>>> In my approach (allow non-link-local in the outer header), I tried 
>>>> to separate out the identifiers for the application endpoints and 
>>>> the MPL domain.  That is why I used the outer header's destination 
>>>> address to identify the MPL domain and the inner header's 
>>>> destination address to identify the application endpoints.  With 
>>>> this approach, it actually becomes feasible to address situations 
>>>> where the devices within an MPL domain subscribe to arbitrary IPv6 
>>>> multicast addresses - not just ones that are based on the unicast 
>>>> prefix.
>> Peter's use case involves having multiple Dissemination Regions 
>> within a single IEEE 802.15.4 PAN.  I agree, one could argue whether 
>> the devices should all be within the same PAN or different PANs based 
>> on the nearest border router.
>
>> During the WG meeting, people made a good argument that we actually 
>> don't know the answer - either because all the use cases are not 
>> obvious or because we don't understand all the consequences of each 
>> approach.  One proposal was to have the draft specify well-defined 
>> forwarding behavior that supports both situations.  For example:
>> 1) If the outer header has an IPv6 Destination Address matching the 
>> link-local all-MPL-forwarders address, do …
>> 2) Otherwise, do …
>>
>> Then leave it up to those who are using this spec to determine what 
>> subset they want to use.  Not sure if this is a reasonable approach 
>> and would like to get feedback from the WG.
>
> My current implementation is just such a hybrid, except that action 1
> is decided by scope and not the full address. From an implementation
> point of view, I'd prefer not to have two code paths, but if it
> satisfies everyone's needs and we have an IANA assigned address, I 
> can
> live with it. :-)
>
> - Dario
>
>
>
>

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 09 Nov 2012 09:46:33 -0800

Hi Jonathan

According to your approach please could you give examples of what the 
outer and inner mc addresses would look like and where the HbH option 
would be placed.

- Dario

On 08/11/2012 5:40 PM, Dario Tedeschi wrote:
>>>> single identifier to both limit the flooding scope and determine 
>>>> the application endpoints.
>>>> the restriction that the IPv6 multicast addresses used within an 
>>>> MPL domain have the same prefix that identifies the MPL domain 
>>>> itself.  The trouble comes when you want to support the full 
>>>> generality that IPv6 multicast addresses used by application 
>>>> endpoints can be arbitrary.
>>> Essentially it provides routing information. How could we support 
>>> the "full generality" of mc addresses without this information 
>>> (whether implied or from something like MLD).  With this in mind, I 
>>> don't understand the need for non-link-local scope in the outer 
>>> header, because the "generality" you seek would be determined by the 
>>> mc address of the original packet (i.e. the mc address of the inner 
>>> original/inner mc address determines how far a packet will 
>>> propagate, regardless of routing domain. MPL could just be one of 
>>> many routing domains a mc packet must traverse before reaching its 
>>> furthermost boundary. Or MPL may be the only routing domain, where 
>>> the mc packet only reaches a sub-set of devices within the domain 
>>> (i.e. a multicast group or a set based on unicast-prefix-based mc).
>>>> For example, how does MPL support an application that subscribes to 
>>>> a well-known non-link-local IPv6 multicast address?  I guess one 
>>> the routing information available to routers. The routers without 
>>> the appropriate routing information would not forward. Similarly, 
>>> routers without mc membership information from an app would not pass 
>>> the packet to the next higher layer.
>> to forward the packet.  You take a routing perspective, where a 
>> device determines whether or not to forward based on the identifier 
>> for the application endpoints.  In contrast, I view it as a device 
>> determines whether or not to forward based on the Dissemination 
>> Region it is in.  Note that in my view, the Dissemination Region does 
>> not have to have any relationship with the identifier for application 
>> endpoints.  In other words, you can configure the Dissemination 
>> Region without any knowledge of the multicast addresses that devices 
>> are interested in.
>
>>> forwarder still needs to look at the inner header to determine if 
>>> implementing this is a bit messy compared to my approach, because 
>>> the forwarder has to look ahead into the packet before 
>>> decapsulating. My approach always requires decapsulation before 
>>> making any decision about where the packet must go next. It's 
>>> simpler and more consistent. I've actually had the 
>>> the application endpoint. What I'm not clear on is why we need an 
>>> MPL domain to cover more than the LLN or why we need to support 
>>> multiple MPL domains in one LLN. Tf the latter case is required to 
>>> allow for different sets of MPL propagation parameters, then I'd 
>>> imagine that should rather be handled by the HbH option.
> satisfies everyone's needs and we have an IANA assigned address, I can 
> live with it. :-)
>
> - Dario
>
>
>
>

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 09 Nov 2012 11:35:17 -0800

After some lengthy discussions, Owen Kirby and I think the use of a 
non-link-local mc address in the outer header is fine as long as that 
address *uniquely* identifies the MPL domain (whether it be IANA 
assigned or determined at run-time).

- Dario

---

From: Dario Tedeschi <[email-masked]>
Date: Fri, 09 Nov 2012 17:37:51 -0800

Actually, I missed something. I should have said:

Non-link-local would be fine with the following caveats:

 1. A non-link-local mc address that *uniquely* identifies the MPL
    domain must exist, whether it be IANA assigned or determined at
    run-time.
 2. A packet injected into an MPL domain that has a mc address that does
    not match the MPL domain address must be tunneled.

- Dario

On 09/11/2012 11:35 AM, Dario Tedeschi wrote:
>>>>> the MPL domain.  For that reason, your approach really only needs 
>>>>> a single identifier to both limit the flooding scope and determine 
>>> Dissemination Region - a connected set of MPL devices that attempt 
>>> to forward the packet so that all devices receive the packet at 
>>> least once.  Another definition may be: a region within which the 
>>> SeedID must be unique.
>>
>>>> header, because the "generality" you seek would be determined by 
>>>> the mc address of the original packet (i.e. the mc address of the 
>>>> inner header). All my approach is really saying is that only the 
>>>>> to a well-known non-link-local IPv6 multicast address?  I guess 
>>>>> one approach is to say that if the IPv6 multicast address is not a 
>>>>> unicast-prefix-based multicast address, then it disseminates 
>>>>> across the entire region of connected MPL forwarders.
>>>> routers without mc membership information from an app would not 
>>>> pass the packet to the next higher layer.
>>> Region it is in.  Note that in my view, the Dissemination Region 
>>> does not have to have any relationship with the identifier for 
>>> application endpoints.  In other words, you can configure the 
>>> Dissemination Region without any knowledge of the multicast 
>>> addresses that devices are interested in.
>>
>>>> The forwarder still needs to look at the inner header to determine 
>>>> if the inner mc address is one an app is listening on. In fact 
>> determine if the mc address there was an address some higher layer 
>> was interested in. What made things even less palatable, was having 
>> to skip over potential extended headers just to determine whether or 
>> not the packet was encapsulated. Aside from passing mc packets up, 
>> the hack was also needed to decrement the hop-limit when forwarding.
>>
>>> the devices should all be within the same PAN or different PANs 
>>> based on the nearest border router.
>>
>> can live with it. :-)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 17:14:02 -0500

see inline

>>>>> "Dario" == Dario Tedeschi <[email-masked]> writes:
    Dario> Non-link-local would be fine with the following caveats:

    Dario> 1. A non-link-local mc address that *uniquely* identifies the MPL
    Dario> domain must exist, whether it be IANA assigned or determined at
    Dario> run-time.

    Dario> 2. A packet injected into an MPL domain that has a mc address that does
    Dario> not match the MPL domain address must be tunneled.

okay...
a packet with a link-local mc address does not need tunnelling, because,
by definition, it can not leave the MPL domain, so it never needs
tunnelling?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2012 17:07:40 -0500

splitting up your text to emphasize a few things:

>>>>> "peter" == peter van der Stok <[email-masked]> writes:
    peter> The nodes in all networks use the same communication channel.

...

    peter> not forward the message.  In this network configuration the
    peter> dissemination area is identical with a network.  From a cost
    peter> perspective (less border routers) it is more realistic if one
    peter> network covers the whole floor. 

But, in your diagram, you have 6 border routers?!?

I don't understand why nodes in area1 and area2 should use the same
communication channel.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 14 Nov 2012 09:38:28 +0100

Hi Michael,

sorry to be confusing.

Again, this is not a real installation, just an example of what to 
expect.
Surface area can be something like 100x30 square meters.

I show 6 border routers coinciding with 6 disseminatiuon areas due to a 
remark by Dario where he asked if it is possible that multiple 
disseminations areas can be present in one PAN.
The answer is yes, because giving a border router to each dissemination 
area (6) is quite expensive.

Concerning the use of the same channel.
When we have one PAN, one channel is used, that is clear.
Having several PANs, it perspires that often only 2 channels of the 
ones specified by 802.15.4 provide good communication ([presence of 
802.11, etc.).

Several other additional organisational boundary conditions can dictate 
the channel numbers.

Hope this helps,

peter

---

From: Robert Cragie <[email-masked]>
Date: Wed, 14 Nov 2012 11:39:06 +0000

On 12/11/2012 10:14 PM, Michael Richardson wrote:
> see inline
>
>>>>>> "Dario" == Dario Tedeschi<[email-masked]>  writes:

It's not quite as simple as that:

 1. A packet with a link-local mc address doesn't need tunnelling and
    doesn't need trickle multicast as it is intended to go only one hop
    and is therefore sent using link-layer broadcast without any MPL option.
 2. We have generally used the term "subnet-local" in the case of where
    the MPL domain covers the multi-link subnet exactly. If the
    originator is in the MPL domain, and all the intended recipients are
    in the MPL domain, then any packet forwarded by a MPL forwarder will be:
     1. Unencapsulated
     2. Have subnet-local mc address (e.g. FF03-based)
     3. Have a MPL option
 3. There is the other case where if the originator is not in the MPL
    domain or at least one of the intended recipients is not in the MPL
    domain (scope rules), then any packet forwarded by a MPL forwarder
    will be:
     1. Encapsulated
     2. Outer header will have subnet-local mc address (e.g.
        FF03-based). This can be used to control propagation in
        conjunction with the MPL option.
     3. Outer header will have a MPL option
     4. Inner header will have site local mc address (e.g. FF05-based).
        This will be tunnelled to multicast exit points
     5. Inner header will not have a MPL option
 4. The alternative to (3) is to use link-local mc address in
    conjunction with a MPL option:
     1. Encapsulated
     2. Outer header will have link-local mc address (e.g. FF02-based).
        This cannot be used to control propagation as it only goes one
        hop; the MPL option is used alone
     3. Outer header will have a MPL option
     4. Inner header will have site local mc address (e.g. FF05-based).
        This will not be tunnelled as it is recapsulated every hop
     5. Inner header will not have a MPL option

---

From: "roll issue tracker" <[email-masked]>
Date: Wed, 14 Nov 2012 21:09:15 -0000

Comment (by mcr@…):

 From: Robert Cragie <[email-masked]>

 1. A packet with a link-local mc address doesn't need tunnelling and
    doesn't need trickle multicast as it is intended to go only one hop
    and is therefore sent using link-layer broadcast without any MPL
 option.

    in the MPL domain, then any packet forwarded by a MPL forwarder will
 be:

-- 
----------------------------+----------------------------------------------
 Reporter:  mcr@…           |       Owner:  draft-ietf-roll-trickle-mcast@…
     Type:  defect          |      Status:  new
 Priority:  major           |   Milestone:
Component:  trickle-mcast   |     Version:
 Severity:  In WG Last      |  Resolution:
  Call                      |
 Keywords:                  |
----------------------------+----------------------------------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/105#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 15 Nov 2012 09:46:51 +0000

Hi Peter, Michael,

a question from your last 2 emails is the following:
if multiple LoWPAN networks are assigned the same 802.15.4 channel (which is likely as Peter explained), would they not be assigned a different Pan-ID to logically separate them? So for the drawing that shows the 6 border routers case, there would be no mutual connectivity between dissemination regions anyway.

A related question is whether nodes from different LoWPANs are allowed, or not, to mutually communicate. (I could not find text on this in RFC 6282 and RFC 6775 (6lowpan-nd) ).
If they are allowed that leads to some strange implications, for example a node in LoWPAN1 sends a link-local packet which is received by a node in LoWPAN2 even though it is on a different link (and different IPv6 prefix).

I can put this question on the 6lowpan list, if needed.

regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Wednesday 14 November 2012 9:38
To: Michael Richardson
Cc: [email-masked]
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

Hi Michael,

sorry to be confusing.

Hope this helps,

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.

---

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

HI Esko,

The few LoWPAN implementations I have experience with, ignore the 
PANid.
Actually, this is great because when the original PANid node is removed 
the network continues to exist.
Contrary to Zigbee, where this is a problem and has led to 
standardization modifications.
So please do not start this discussion again.

So your implication (strange or not) is correct, and therfore I create 
these problems with unicast prefix based MC addresses.

Greetings,

Peter

Dijk, Esko schreef op 2012-11-15 10:46:
> if multiple LoWPAN networks are assigned the same 802.15.4 channel
> (which is likely as Peter explained), would they not be assigned a
> different Pan-ID to logically separate them? So for the drawing that
> shows the 6 border routers case, there would be no mutual 
> connectivity
> between dissemination regions anyway.
>
> A related question is whether nodes from different LoWPANs are
> allowed, or not, to mutually communicate. (I could not find text on
> this in RFC 6282 and RFC 6775 (6lowpan-nd) ).
> If they are allowed that leads to some strange implications, for
> example a node in LoWPAN1 sends a link-local packet which is received
> by a node in LoWPAN2 even though it is on a different link (and
> different IPv6 prefix).
>
> 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: "Dijk, Esko" <[email-masked]>
Date: Thu, 15 Nov 2012 10:30:06 +0000

Hi Peter,

Did not mean to start a new discussion - Just noticed that you assume different LoWPAN nodes will process eachother's 6LoWPAN frames, while Michael assumed that would never be the case because they are separate subnets. So the conclusion is it *can* be the case even though that violates the IPv6 link/subnet model.

In ContikiOS (where I have experience with) the Pan-ID is not ignored; 6LoWPAN frames destined to another PAN than the node is configured with, are filtered out.

Esko

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: Thursday 15 November 2012 11:01
To: Dijk, Esko
Cc: [email-masked]; Michael Richardson; [email-masked]
Subject: RE: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

HI Esko,

Greetings,

Peter

---

From: Don Sturek <[email-masked]>
Date: Thu, 15 Nov 2012 06:03:17 -0800

Hi Esko,

I actually don't know of an IEEE 802.15.4 radio implementation that would
not filter on PAN ID.  You should only see (at the next higher layer)
frames with the PAN ID you are a member of or the broadcast PAN ID (but
never multiple different PAN ID's)

Don

On 11/15/12 2:30 AM, "Dijk, Esko" <[email-masked]> wrote:

>Hi Peter,
>
>Did not mean to start a new discussion - Just noticed that you assume
>different LoWPAN nodes will process eachother's 6LoWPAN frames, while
>Michael assumed that would never be the case because they are separate
>subnets. So the conclusion is it *can* be the case even though that
>violates the IPv6 link/subnet model.
>
>In ContikiOS (where I have experience with) the Pan-ID is not ignored;
>6LoWPAN frames destined to another PAN than the node is configured with,
>are filtered out.
>
>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.

---

From: Don Sturek <[email-masked]>
Date: Thu, 15 Nov 2012 06:08:05 -0800

Hi Esko,

The topic discussed below is really an IEEE 802.15.4 topic.   That
specification has a management information block (MIB) that holds the PAN
ID the device is a member of as well as the short ID of the device within
that PAN.

While it is possible to implement devices which are simultaneously members
of multiple PAN ID's, each with different short ID's, in practice, most
silicon implementations use the MIB values as described in the
specification to perform filtering on incoming packets.   To that end, you
should only see packets with the PAN ID/short or long ID of your device
(or the broadcast PAN ID) but never packets with multiple different PAN
ID's/short ID's (at least from all of the implementations I know
about......)

Don

On 11/15/12 1:46 AM, "Dijk, Esko" <[email-masked]> wrote:

>if multiple LoWPAN networks are assigned the same 802.15.4 channel (which
>is likely as Peter explained), would they not be assigned a different
>Pan-ID to logically separate them? So for the drawing that shows the 6
>border routers case, there would be no mutual connectivity between
>dissemination regions anyway.
>
>A related question is whether nodes from different LoWPANs are allowed,
>or not, to mutually communicate. (I could not find text on this in RFC
>6282 and RFC 6775 (6lowpan-nd) ).
>If they are allowed that leads to some strange implications, for example
>a node in LoWPAN1 sends a link-local packet which is received by a node
>in LoWPAN2 even though it is on a different link (and different IPv6
>prefix).
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 15 Nov 2012 15:09:32 +0000

On 14/11/2012 9:13 PM, Michael Richardson wrote:
> Robert, has written 3 rules about when to encapsulate, and how to
> recognize the MPL domain.  With two options #3 and #4.
>
> the difference is  (#3):
>
> vs (#4)
> <    2. Outer header will have link-local mc address (e.g. FF02-based).
> <       This cannot be used to control propagation as it only goes one
> <       hop; the MPL option is used alone
>
> and as far as I can understand in both cases MPL forwarders will
> decapsulate and re-encapsulate, thus decrementing the inner TTL each
> time.   Or did I misunderstand here?
<RCC>
Almost there. In the case of forwarding using MPL domain (subnet-local) 
mc address, the inner packet is strictly tunnelled, i.e. there will be 
no hop count decrementing per hop. I discussed this offline with 
Jonathan Hui and he thought that was acceptable. In the case of 
link-local mc address, the inner packet would have its hop count 
decremented.

Why the difference? Consider the two cases more closely:

  * In the MPL domain multicast case, the encapsulated packet traverses
    throughout the scope dictated by the MPL domain multicast address.
    On receipt, the inner packet is decapsulated for processing. Once it
    has been processed it is effectively discarded. The outer packet,
    complete with MPL option is then passed to the MPL forwarder, which,
    if it decides to forward, manipulates the MPL option only and sends
    the outer packet as it came in
  * In the link-local case, the encapsulated packet only goes one hop.
    On receipt, the inner packer is decapsulated for processing. The
    outer header is discarded and the MPL option retained. As the inner
    packet is no longer encapsulated, it can be manipulated. The MPL
    forwarder is then passed the MPL option and the inner packet, which,
    if it decides to forward, manipulates the MPL option and
    recapsulates the inner packet

See attached diagrams for pictorial explanation.
</RCC>
>
> I think that we are very closing to closing issue #105, and I think that
> issue #106 would be resolved as "no" by this choice.
>

---

From: Dario Tedeschi <[email-masked]>
Date: Thu, 15 Nov 2012 09:59:45 -0800

> by definition, it can not leave the MPL domain, so it never needs
Agreed. I was assuming we were only talking of the forwarding of 
non-link-local multicasts. Of course, link-local scoped packets must not 
be forwarded.

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 19 Nov 2012 08:03:35 +0000

> Yes, this is my belief as well.
> so I still do not think that we have a clear use case/description of what/how a less-than-subnet MPL domain would be
> defined/used.

A clear use case seems to be Peter's office topology where all nodes are connected as a single LoWPAN with one 6LBR. Each office/room can be configured as an MPL domain. The event information sent by a pushbutton or sensor (to trigger the lights) only needs to be disseminated to all the nodes in the local room; hence defining a separate MPL domain is useful.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Saturday 17 November 2012 20:35
To: Dijk, Esko
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

>>>>> "Dijk" == Dijk, Esko <[email-masked]> writes:
    Dijk> a question from your last 2 emails is the following: if
    Dijk> multiple LoWPAN networks are assigned the same 802.15.4
    Dijk> channel (which is likely as Peter explained), would they not
    Dijk> be assigned a different Pan-ID to logically separate them? So
    Dijk> for the drawing that shows the 6 border routers case, there
    Dijk> would be no mutual connectivity between dissemination regions
    Dijk> anyway.

Yes, this is my belief as well.
so I still do not think that we have a clear use case/description of what/how a less-than-subnet MPL domain would be defined/used.

It seems to me that we understand how we would implement such a thing, at least.

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 19 Nov 2012 15:32:46 +0000

> but, it's not at all clear to me that this is a real use case!
> Is the PAN-ID relevant?  is there one 6LBR or 6 of them?

As Peter remarked earlier, the case with one 6LBR is more realistic than the case with 6 6LBRs for cost reasons. For the case of a single 6LoWPAN (one 6LBR), the PAN-ID discussion is not relevant as there's just one big LoWPAN.

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Monday 19 November 2012 16:15
To: Dijk, Esko
Cc: [email-masked]; [email-masked]
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

<#part sign=pgpmime>

    >> Yes, this is my belief as well.  so I still do not think that we
    >> have a clear use case/description of what/how a less-than-subnet
    >> MPL domain would be defined/used.

    Dijk> A clear use case seems to be Peter's office topology where all
    Dijk> nodes are connected as a single LoWPAN with one 6LBR. **Each
    Dijk> office/room can be configured as an MPL domain** The event

but, it's not at all clear to me that this is a real use case!
Is the PAN-ID relevant?  is there one 6LBR or 6 of them?