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

[Dario Tedeschi <[e-mail]>]

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



On 08/11/2012 5:40 PM, Dario Tedeschi wrote:
> 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
>
>
>
>