Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-02

[peter van der Stok <[e-mail]>]

Hi Michael,

The answer to your question is given by the scenario of Dario that I 
reproduced below.

Actions  4 and 5 describe what I intended to limit the forwarding.

In addition I like to mention that when a multicast is intended for a 
group with members in N2 and N1
the multicast address could have a prefix that is a prefix to Fd01::/64 
and Fd02::/64.
For example the MC address is then FF35:0040:FD0::1.
In accordance, I suggest that all forwarders in N1 and in N2 accept and 
forward the message.


As an aside I like to mention that BR1 and BR2 use the same channel for 
802.15.4 because often there are many physical and organisational 
constraints who may dictate such an alocation.

Greetings,

Peter

-------- DArio scenario     -------

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.

----- end Dario scenario -------

Michael Richardson schreef op 2012-11-03 00:46:
> see inline
>
> peter van der Stok <[e-mail]> wrote:
>     peter> It is related to the scope of the multicast, but not in 
> the
>     peter> administrative sense, but in an operational sense when
>     peter> wireless forwarders receive MPL messages and they should 
> be
>     peter> able to filter only those messages that are targeted to 
> the
>     peter> subnet of which they are part.
>
> Is this about configuring multicast (hardware) filters so that the 
> wrong
> nodes aren't woken up?
> Is the case you speak up articulated by one of Robert's diagrams?
>
>     peter> I explained the case earlier with an example.
>
> Yes, I had asked a question about that too.  I didn't understand how
> the two networks overlapped.  Do they share the same 15.4 key 
> material?
> Do they have the same beacons?
>
> My feeling is that you are solving a problem which exists on paper, 
> but
> not in a real 15.4 network.  But, I could be completely wrong.