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

[Dario Tedeschi <[e-mail]>]

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