Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 1 Nov 2012 12:45:48 +0000

Hi,

> the Option Type to '01', which indicates the receiver must drop the packet
My mistake - I had the version -00 draft opened, hence looking at '00' bits.

There's still the case that multicasts from non-MPL nodes are received by MPL-forwarder-nodes (presumably). Should there be guidelines here? Example: if an application on my MPL-forwarder node joins multicast group FF05::1234, will the application then receive IP multicasts sent with destination FF05::1234, or will it only receive those IP multicasts to FF05::1234 that were delivered encapsulated in an FF0X::MPL packet ?

That decision could be out of scope; but on the other hand may lead to different implementers making different choices here.

Esko

-----Original Message-----
From: Jonathan Hui (johui) [mailto:[email-masked]]
Sent: Wednesday 31 October 2012 17:19
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt

Hi Esko,

On Oct 31, 2012, at 8:37 AM, "Dijk, Esko" <[email-masked]> wrote:

> 1. Selection of the link-local all-nodes MPL forwarders multicast address.
> When IPv6-in-IPv6 encapsulation is applied, the "all-MPL-forwarders" MC address will be used a lot. A typical use case of MPL is in 6LoWPAN networks. It has best header compression of link-local IP multicast destination address when the multicast Group ID is in the range 0x00-0xFF. Therefore we should put in the IANA allocation request (and in the IANA section in the I-D too) that we urgently request an allocation in this range. Going outside this range to Group IP 0x100 and up, will incur 4 bytes extra overhead. (An example of a successful earlier registration in the 00-FF range is mDNS FF0X::FB).

Agree.  Will include in the next revision.

> 2. Warn against mixing MPL-forwarders with non-MPL-nodes in the same LLN.
> Mixing MPL-forwarders with non-MPL-nodes (that e.g. listen to specific multicast traffic) may lead to unpredictable behavior. For example, an MPL node N1 application sends to FF05::1234, and a non-MPL neighbor node N2 listens to FF05::1234. If MPL does use encapsulation, then node N2 will never receive the packet from N1 (because N1 will send to either FF02::MPL or FF05::MPL). If MPL happens to not use encapsulation, node N2 will receive the packet from N1.
> So depending on the encapsulation decision different nodes may get/not get the packet - is this intentional?
> If not we should warn for this situation, perhaps?

In both cases, the MPL multicast packet must contain the MPL Option.  The current draft sets the highest-order bits in the Option Type to '01', which indicates the receiver must drop the packet if it does not understand the MPL Option.  So non-MPL-nodes should not receive MPL Multicast packets.

> 3. Motivation for requiring encapsulation: MPL vs RPL
>   " IPv6-in-IPv6
>   encapsulation also allows an MPL forwarder to remove the MPL Option
>   when forwarding the original multicast packet over a link that does
>   not support MPL."
> It seems RPL does not use IPv6-in-IPv6 encapsulation but just states that the RPL router can remove the HbH option. (RFC 6550 Section 11.2.2.1, "A router that forwards a packet outside the RPL network MUST remove the RPL Packet Information.") Is there a reason that MPL cannot do it the RPL way?

RFC 6553, which specifies the RPL Option, requires the use of IPv6-in-IPv6 encapsulation, unless the source and destination are known to be within the same RPL Instance.

--
Jonathan Hui

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 1 Nov 2012 13:17:10 +0000

> Any feedback from others in the WG on this?  Should we include support for selecting 1, 2, or more parameter sets?

Having two parameter sets is useful to support two main uses of multicast in LLNs for the building control domain;

1) Device/service discovery, such as mDNS and CoAP's /.well-known/core.
Latency is less important here; avoiding high network load due to discovery traffic is also a goal if other more time-critical application are running at the same time.
-> "slow" Trickle parameter set

2) Building Control involving groups of devices
Latency can be important (e.g. lighting control, or any device operation triggered by sensors or smartphones)
-> "fast" Trickle parameter set

Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hui (johui)
Sent: Thursday 1 November 2012 6:00
To: Reddy, Joseph
Cc: [email-masked]
Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-02.txt

Hi Joseph,

Comments below:

On Oct 31, 2012, at 5:00 PM, "Reddy, Joseph" <[email-masked]> wrote:

> Here are some comments on the trickle multicast draft rev-02
>
> 1. MPL multicast scope:
> I think fixing it to link-local is too restrictive as it will force encapsulation even when it is not needed.
> Regarding the practical aspects of determining the MPL scope, I think that can be left to "administrative configuration". Other multicast details (e.g., the zone boundaries for scopes greater than link local) have to be administratively configured anyway.

I agree that it is desirable to avoid encapsulation when possible.

There is an important difference depending on whether encapsulation is used:

1) With encapsulation, the IPv6 Destination Address of the outer header explicitly identifies the MPL scope zone.

2) Without encapsulation, the IPv6 Destination Address identifies the endpoints that should process the IPv6 payload.  However, the IPv6 Destination Address may not explicitly identify the MPL scope zone.  Instead, the IPv6 Source Address identifies the MPL scope zone.  It is easy to determine the scope zone if we require the separation to occur across interface boundaries (just observe what interface the message came in on).  However, it is not so easy to determine the scope zone if we want a single interface to service more than one MPL scope zone.  I believe the latter case is what Peter is looking for.  One solution is to require the IPv6 Destination Address to also identify MPL forwarders that will forward the message.  Another solution is to include an MPL domain/instance identifier in the MPL Option.  Yet another solution is to eliminate this case and always require encapsulation.

> 2. Supporting different Trickle parameter sets:
> I think this is a useful feature and should be included even if it is a single flag (2 parameter sets). Typical use cases for multicast in LLN's try to achieve either high reliability or low latency and having two sets of trickle parameters for each of them should help

Any feedback from others in the WG on this?  Should we include support for selecting 1, 2, or more parameter sets?

> 3. Version field:
> I think adding an explicit version field ( 2 bits should be enough) will help.

OK.  Any additional inputs from the WG?

> 4. Destination address:
> Is there a reason to restrict the destination address of the MPL packet to the "all-MPL-forwarders" multicast address? Nodes that receives an MPL packet but don't understand the MPL option will discard it anyway.

I think the most compelling reason is to remove yet another configuration parameter.  But allowing arbitrary multicast addresses to identify MPL forwarders would be necessary to support multiple MPL scope zones using the IPv6 Destination Address.  If we require encapsulation with link-lcoal multicast, then an all-MPL-forwarders address would be ok.

Thoughts?

--
Jonathan Hui

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll