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

[Dario Tedeschi <[e-mail]>]

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

OK, that makes sense to me.

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

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

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?


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

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.



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

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


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