Subject: MLD version for node req. draft

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 21 Feb 2011 17:00:33 +0800 (HKT)

Hi,

I have a comment about the description of MLD version in the node
requirement draft;
http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-07

In MBONED WG, the Lightweight MLDv2 [RFC5790] that simplifies the
protocol spec of MLDv2 is published as the proposed standard RFC.
Hence I recommend to change two sentences in the section 5.9 of this
draft as follows;

"Nodes that need to join multicast groups SHOULD also implement MLDv2
 [RFC3810]."
to
"Nodes that need to join multicast groups SHOULD also implement either
 MLDv2 [RFC3810] or Lightweight MLDv2 [RFC5790]."

and

"if the node has applications that need support for Source-Specific
 Multicast [RFC3569], the node MUST support MLDv2 as defined in
 [RFC3810], [RFC4604] and [RFC4607]."
to
"if the node has applications that need support for Source-Specific
 Multicast [RFC3569], the node MUST support either MLDv2 as defined in
 [RFC3810], [RFC4604] and [RFC4607] or Lightweight MLDv2 [RFC5790]."

Regards,
--
Hitoshi Asaeda

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Feb 2011 10:30:03 -0500

>  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?

Thomas

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 22 Feb 2011 11:02:00 +0800 (HKT)

> 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