Good clarifications. I have revised the text. Thanks! Thomas
Hitoshi Asaeda <[email protected]> writes: > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
