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

["Jonathan Hui (johui)" <[e-mail]>]

Hi Dario,

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

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

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.

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

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.

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

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?

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

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