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

[Dario Tedeschi <[e-mail]>]

Hi Jonathan

On 02/11/2012 10:18 PM, Jonathan Hui (johui) wrote:
>
> 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.
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

>
> --
> Jonathan Hui
>
> On Nov 2, 2012, at 12:34 PM, Dario Tedeschi <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> On 01/11/2012 7:12 PM, Jonathan Hui (johui) wrote:
>>> On Nov 1, 2012, at 6:47 PM, Dario Tedeschi<[e-mail]>  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).
>>
>> 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.
>>
>>
>>>> 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?
>>
>> The destination in the inner header determines if the packet needs to 
>> be forwarded or not, or forwarded on a different interface.
>>
>>
>>>> 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?
>>
>> 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
>>
>>
>