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

[Dario Tedeschi <[e-mail]>]

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