Hi Thomas, >> >> "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.
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. > 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] 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. > 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. 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 > subset of the original MLDv2 specification that omits EXCLUDE > functionality. 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)." > 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]. Ok. > 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]. "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]." > 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. "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." > When MLDv1 is used, the rules in the Source Address Selection for the > Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be > followed. > > Thomas Regards, -- Hitoshi Asaeda > Hitoshi Asaeda <[email protected]> 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 protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
