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

[Robert Cragie <[e-mail]>]

Hi Jonathan,

Good summary.

The main issue with option 2a is that the inner packet then gets
effectively multicast tunneled (a slightly paradoxical concept but I was
reminded the term is used legitimately). In this case, it becomes difficult
to manipulate the inner packet as it should be forwarded verbatim. In this
case, the hop count is not decrement and emanates at the multiple tunnel
endpoints as if it had gone one hop. I remember this was not acceptable for
RPL HbH header encapsulation and that the inner packet had to have its hop
count decremented appropriately.

Attached is another revision of the diagrams which show the MPL domain
multicast encapsulation case.

Robert

On Mon, Nov 5, 2012 at 1:27 PM, Jonathan Hui (johui) <[e-mail]>wrote:

>
> Hi Peter,
>
> To reiterate my thoughts - this works because the IPv6 multicast address
> identifying the endpoints also identifies the MPL domain.  How would you
> limit the scope of disseminating a message sent to a well-known IPv6
> multicast address?  Or is the answer (i) we don't support anything other
> than unicast-prefix-based multicast addresses or (ii) we don't limit the
> dissemination scope sent to anything else?
>
> The options I see:
>
> 1) Use the same IPv6 multicast address for identifying both endpoints and
> MPL domain.
> 1a) MPL is not used to disseminate packets destined to other IPv6
> multicast addresses.
> 1b) MPL may be used to disseminate packets destined to other IPv6
> multicast addresses, but will disseminate across any connected region of
> MPL forwarders.
>
> In supporting the cases above, a well-known link-local multicast address
> is used in the outer IPv6 header when encapsulation is used.  The outer
> header's MPL Option and the inner header's IPv6 destination address is used
> to determine whether to (i) pass up to higher layers and (ii) forward the
> packet.
>
> If we decide to support inclusion of the MPL Option without encapsulation,
> then a forwarder needs to understand that the MPL Option and IPv6
> destination address in the same IPv6 header are used to determine (i) pass
> up to higher layers and (ii) forward the packet.
>
> 2) Decouple the concept of MPL domain and application endpoint identifiers.
> 2a) Identify MPL domain using outer header's IPv6 destination address.
> 2b) Identify MPL domain using "instance" field in MPL Option.
>
> Both cases above would allow limiting the dissemination scope of any
> arbitrary IPv6 multicast address, including well-known addresses.
>  Furthermore, the forwarding decision is made using only information
> contained in a single IPv6 header - option 2a relies on the MPL Option and
> the IPv6 destination address of the outer header, option 2b relies only on
> information contained in the MPL Option.
>
> Both options 1 and 2 require managing another identifier space.  Option 1
> requires configuring the devices with a prefix.  Option 2a requires
> configuring devices with a multicast group.  Option 2b requires configuring
> devices with an MPL instance.
>
> Option 1 avoids the need to carry a separate MPL domain identifier since
> it requires the IPv6 multicast addresses to use the same prefix that
> identifies the MPL domain.
>
> Comments/thoughts?
>
> --
> Jonatan Hui
>
> On Nov 5, 2012, at 7:23 AM, peter van der Stok <[e-mail]> wrote:
>
> > 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.
> >
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>