MLD
Multicast Listener Discovery (MLD) is the IPv6 version of IGMP and belongs to the Source Specific Multicast (SSM) service model. The purpose of MLD is to allow each IPv6 router to identify multicast listeners on its directly connected links and determine which multicast groups those neighboring nodes are interested in.
MLD is a sub-protocol of ICMPv6. MLD message types are a subset of the set of ICMPv6 messages, and MLD messages are identified in IPv6 packets by a preceding next header value of 58. All MLD messages are sent with a link-local IPv6 source address, a hop limit of 1, and an IPv6 router alert option in the hop-by-hop options header.
- MLDv1 (RFC 2710), derived from IGMPv2
- MLDv2 (RFC 3810), derived from IGMPv3
MLDv1
Similar to IGMPv2, MLDv1 reports only include the multicast group addresses that listeners are interested in and do not include the source addresses. To work with the PIM-SSM model, a similar SSM translation function is required when MLDv1 is used.
SSM translation allows an MLDv1 device to join an SSM multicast network through the router that provides such a translation capability. SSM translation per interface offers the flexibility of having the same (*, G) mapped to two different (S, G) on two different interfaces.
MLDv2
MLDv2 is backward compatible with MLDv1 and allows a node to report interest in listening to packets from a specific multicast group, either from particular source addresses or all sources except specified addresses.
MLD configuration
The routers use MLD to manage membership for a multicast session.
MLD is configured by enabling mld admin-state under the
network-instance protocols context.
The mld model allows the configuration of MLD parameters in both the
default and non-default network-instances, with the ability to apply specific
configurations to individual interfaces.
When enabled, at least one interface must be specified in the MLD context, as MLD is an interface function. Traffic can only flow away from the router to an MLD interface and to and from a PIM interface. A router directly connected to a source must have PIM enabled on the interface to that source. The traffic travels in a network from the PIM interface to the PIM interface and arrives finally on an MLD enabled interface.
When MLD static group membership is enabled, data is forwarded to an interface without receiving membership reports from host members.
If static MLD group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static MLD group entries do not generate join messages toward the RP. When a host wants to receive multicast sessions, the host sends a join message for each multicast group it wants to join. A leave message may be sent for each multicast group with which it no longer needs to participate.
A multicast router keeps a list of multicast group memberships for each attached network and an interval timer for each membership. Hosts issue a multicast group membership report when they want to receive a multicast session. The reports are sent to all multicast routers.
MLD basic configuration
MLD is configured by enabling mld admin-state under the
network-instance protocols context.
Configuring MLD for a default network-instance
The following example shows a configuration of MLD for a default network instance
(srl_default_instance). It includes enabling MLD, configuring
basic MLD parameters, such as configuring MLD on an interface, specifying the MLD
version for an interface, and setting up the query interval.
--{ +* candidate shared default }--[ ]--
info network-instance srl_default_instance
network-instance srl_default_instance {
type default
interface ethernet-1/1.2 {
interface-ref {
interface ethernet-1/1
subinterface 2
}
}
protocols {
mld {
admin-state enable
interface ethernet-1/1.2 {
version 1
query-interval 125
query-last-member-interval 1
query-response-interval 10
}
}
}Configuring MLD for an ip-vrf network-instance
The following example shows a configuration of MLD for an ip-vrf
type network instance (srl_ipvrf_instance). It includes enabling
MLD, configuring basic MLD parameters, such as configuring MLD on an interface,
specifying the MLD version for an interface, setting up the query interval, and
trace options.
--{ +* candidate shared default }--[ ]--
info network-instance srl_ipvrf_instance
network-instance srl_ipvrf_instance {
type ip-vrf
admin-state enable
interface ethernet-1/1.1 {
interface-ref {
interface ethernet-1/1
subinterface 1
}
}
protocols {
mld {
admin-state enable
query-interval 125
query-last-member-interval 1
query-response-interval 10
trace-options {
trace {
interface {
name ethernet-1/1.1
}
}
}
interface ethernet-1/1.1 {
version 1
}
}
}
}Configuring a static MLD group membership
Static MLD group memberships can be configured to test multicast forwarding without a receiver host. When MLD static group membership is enabled, data is forwarded to an interface without receiving membership reports from host members.
When static MLD group entries on point-to-point links that connect routers to a rendezvous point (RP) are configured, the static MLD group entries do not generate join messages toward the RP.
Configuring a static MLD group membership with a specific source IP
The following example configures a static MLD group membership to ensure that the multicast traffic from source 2001:db8::1 is forwarded to the specified multicast group range ff0e::db8:7 to ff0e::db8:9 without requiring dynamic MLD join requests from the hosts.--{ + candidate shared default }--[ ]--
info network-instance srl_default_instance protocols mld interface ethernet-1/1.1 static-membership-groupss
network-instance srl_default_instance {
protocols {
mld {
interface ethernet-1/1.1 {
static-membership-groups {
group-range ff0e::db8:7 end ff0e::db8:9 {
source 2001:db8::1 {
}
}
}
}
}
}
}Configuring a static MLD multicast group with a specific address range and static (*,G) entry for the group
The following example configures a static MLD group membership to ensure that the multicast traffic from any source is forwarded to the specified multicast group range ff0e::db8:7 to ff0e::db8:9 without requiring dynamic MLD join requests from the hosts.--{ + candidate shared default }--[ ]--
info network-instance srl_default_instance protocols mld interface ethernet-1/1.1 static-membership-groups
network-instance srl_default_instance {
protocols {
mld {
interface ethernet-1/1.1 {
static-membership-groups {
group-range ff0e::db8:7 end ff0e::db8:9 {
starg
}
}
}
}
}
}Configuring SSM translation
You can configure static MLD SSM mappings on the last-hop router to provide SSM support for receiver hosts that are running MLDv1. Configuring the IGMP SSM mapping enables the multicast router to translate (*, G) information in MLDv1 Report messages to (G, INCLUDE, (S1, S2..)) information, enabling SSM service for MLDv1 hosts.
Configuring SSM mapping
In the following configuration, SSM mapping is set up to translate MLDv1 join requests for multicast group rangeff0e::db8:7 to ff0e::db8:9 into SSM join
requests with specific sources. The SSM mapping ensures that any host attempting to join
one of the multicast groups within this range is mapped to the source IP address
2001:db8::1. This means that even if a host does not
explicitly specify the source when making a join request (as is the case with MLDv1),
the SSM mapping automatically associates the join request with the source
2001:db8::1.--{ + candidate shared default }--[ ]--
info network-instance srl_default_instance protocols mld interface ethernet-1/1.1 ssm mappings
protocols {
mld {
interface ethernet-1/1.1 {
ssm {
mappings {
group-range ff0e::db8:7 end ff0e::db8:9 {
source 2001:db8::1 {
}
}
}
}
}
}
}
}