Subject: Re: MLD version for node req. draft

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Apr 2011 16:49:13 -0400

Hitoshi Asaeda <[email-masked]> writes:

> >> "Nodes that need to join multicast groups SHOULD also implement either
> >>  MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]."
> > 
> > Is there a short (less than one page) description of the difference
> > between RFCs 3810 and 5790? One that actually explains what the
> > implementation  differences are?

Ah, thanks for this description.  The key is is that the EXCLUDE
functionality of MLDv2 adds considerable complexity, but is rarely
used. SO the Lighteight MLDv2 effectively excludes that functionality.

Here is what I propose to put into the Node Requirements revision:

   5.10.  Multicast Listener Discovery (MLD) for IPv6

   Nodes that need to join multicast groups MUST support MLDv1
   [RFC2710].  MLDv1 is needed by any node that is expected to receive
   and process multicast traffic.  Note that Neighbor Discovery (as used
   on most link types -- see Section 5.2) depends on multicast and
   requires that nodes join Solicited Node multicast addresses.

   MLDv2 [RFC3810] extends the functionality of MLDv1 by supporting
   Source-Specific Multicast.  The original MLDv2 protocol [RFC3810]
   supports two types of "filter modes".  Using an INCLUDE filter, a
   node indicates a multicast group along with a list of senders for
   that group it wishes to receive traffic from.  Using an EXCLUDE
   filter, a node indicates a multicast group along with a list of
   senders it wishes to exclude receiving traffic from.  In practice,
   EXCLUDE filters are rarely used, but add considerable implementation
   complexity to MLDv2.  Lightweight MLDv2 [RFC5790] is a simplified
   subset of the original MLDv2 specification that omits EXCLUDE
   functionality.

   Nodes SHOULD implement either MLDv2 [RFC3810] or Lightweight MLDv2
   [RFC5790].  Specifically, nodes supporting applications using Source-
   Specific Multicast that expect to take advantage of MLDv2's EXCLUDE
   functionality [RFC3569] MUST support MLDv2 as defined in [RFC3810],
   [RFC4604] and [RFC4607].  Nodes supporting applications that expect
   to only take advantage of MLDv2's INCLUDE functionality will find it
   sufficient to support MLDv2 as defined in [RFC5790].

   If the node only supports applications that use Any-Source Multicast
   (i.e, they do not use source-specific multicast), implementing MLDv1
   [RFC2710] is sufficient.  In all cases, however, nodes are strongly
   encouraged to implement MLDv2 rather than MLDv1, as the presence of a
   single MLDv1 participant on a link requires that all other nodes on
   the link operate in version 1 compatibility mode.

   When MLDv1 is used, the rules in the Source Address Selection for the
   Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be
   followed.

Thomas

Hitoshi Asaeda <[email-masked]> writes:

> >> "Nodes that need to join multicast groups SHOULD also implement either
> >>  MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]."
> > 
> > Is there a short (less than one page) description of the difference
> > between RFCs 3810 and 5790? One that actually explains what the
> > implementation  differences are?

> To start listening a multicast session/channel, an MLDv2 host
> specifies either 1) multicast address or 2) source and multicast
> addresses.

> When the host specifies only multicast address, multicast packets sent
> from any source are forwarded to the host. This is ASM.

> When the host specifies source address(es) as well as multicast
> address, it MUST also specify the "filter mode", which is either
> INCLUDE or EXCLUDE. When the host wants to "receive" the multicast
> packets sent from the specified source(es), INCLUDE is chosen as the
> filter mode. When the host wants to "block" the multicast packets sent
> from the specified source(es), EXCLUDE is chosen as the filter mode.
> The former case, INCLUDE (S,G) join, is known as SSM. The latter case,
> noted by EXCLUDE (S,G) join, is not SSM, rather ASM with an additional
> function; to establish EXCLUDE (S,G) state, routers need to maintain
> ASM state, because the routers need to forward every source data to
> their downstreams "except" the excluded S.

> In fact, there are no major applications that require EXCLUDE (S,G)
> join/leave. It is only useful to filter out bogus sources in ASM
> communications, but if you want to block unwanted source, say Sx,
> you'd specify other sources to join the session such as INCLUDE
> ({S1,S2,S3},G) (without including Sx).

> According to such consideration, talking abour the host-side
> implementation, the LW-MLDv2 spec (5790) supports both ASM and SSM
> communications, but eliminates EXCLUDE (S,G) join/leave operations.
> In fact, implementing both INCLUDE and EXCLUDE mode operations
> requires complex state machine in kernel; therefore LW-MLDv2 gives the
> chance for simpler kernel implementation. This is very positive
> condition, and it is sure according to my experience of both IGMPv3
> and LW-IGMPv3 host-side kernel implementations in NetBSD. (I also
> have implemented MLDv2 kernel but no LW-MLDv2.) IMO, it is hence
> advantageous especially for mobile terminals or tiny OSes.
> Of course, LW-MLDv2 supports interoerability with any MLD versions; it
> works either with MLDv1, MLDv2, or LW-MLDv2 routers.

> I hope this helps.

> Regards,
> --
> Hitoshi Asaeda

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 25 Apr 2011 23:19:51 +0900 (JST)

Hi Thomas,

> used. SO the Lighteight MLDv2 effectively excludes that functionality.

What we also need to understand in the fiter operation is that (*,G)
join (i.e. ASM join) is expressed by "EXCLUDE (NULL,G)" in the MLDv2's
definition.
LW-MLDv2 [RFC5790] of course supports ASM as well as SSM, hence it
does not completely eliminate an EXCLUDE filter mode operation.
Simply, LW-MLDv2 hosts eliminate the functionality to trigger an
"EXCLUDE (S,G)" operation.

>    Source-Specific Multicast.  The original MLDv2 protocol [RFC3810]

Better to add the SSM's reference.

"... supporting Source-Specific Multicast [RFC4607]."

In fact, the draft-ietf-6man-node-req-bis-08 refers RFC3569 as the
SSM's reference, but RFC4607 seems better as it, I think.

>    senders it wishes to exclude receiving traffic from.

I agree to the above statements.

>  In practice, EXCLUDE filters are rarely used, but add considerable
>    implementation complexity to MLDv2.

I may want to change this to;

"In practice, operations to block source(s) by EXCLUDE filter mode are
rarely used, but add considerable implementation complexity to MLDv2."

>    Lightweight MLDv2 [RFC5790] is a simplified

I'd change this to;

"Lightweight MLDv2 [RFC5790] is a simplified subset of the original
MLDv2 specification that omits EXCLUDE filter mode specifying
undesired source(s)."

>    [RFC4604] and [RFC4607].

Ok.

> Nodes supporting applications that expect

"Nodes supporting applications that expect to only take advantage of
MLDv2's INCLUDE functionality as well as Any-Source Multicast will
find it sufficient to support MLDv2 as defined in [RFC5790]."

>    the link operate in version 1 compatibility mode.

"In all cases, however, nodes are strongly encouraged to implement
MLDv2 or Lightweight MLDv2 rather than MLDv1, as the presence of a 
single MLDv1 participant on a link requires that all other nodes on
the link operate in version 1 compatibility mode."

Regards,
--
Hitoshi Asaeda

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Apr 2011 08:58:23 -0400

Good clarifications. I have revised the text. Thanks!

Thomas