Hitoshi Asaeda <asa...@sfc.wide.ad.jp> 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 <asa...@sfc.wide.ad.jp> 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
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
