2.3.8 Multicast & Anycast Group Membership (magma)
Last Modified: 2003-07-29
Isidor Kouvelas <email@example.com>
Brian Haberman <firstname.lastname@example.org>
Internet Area Director(s):
Thomas Narten <email@example.com>
Margaret Wasserman <firstname.lastname@example.org>
Internet Area Advisor:
Margaret Wasserman <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
In Body: subscribe
Description of Working Group:
Group management protocols are crucial to the operation of multicast
within the Internet, and there are some benefits in extending group
management protocols to also be able to support anycast. These
protocols allow hosts to inform routers of their membership status
within groups. This working group will be responsible for developing
the functionalities required for group membership reporting and other
related actions. This group will also address the initial
authentication and access control issues associated with anycast group
membership; this is likely to be limited to shared secrets and message
authentication codes (MACs) much like current routing protocol
security. Other aspects of Anycast, including architecture and
routing, are outside the groups scope.
The draft names listed below are the starting point for the work in the
MAGMA specifications will include:
- Core IGMPv3/MLDv2 specifications. These specifications will describe
the protocol used between hosts and routers to share group membership
information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding
two types of source-specific filtering; "include" (in which the
system tells the router exactly which sources it desires) and
"exclude" (in which the system tells the router that it does *not*
desire a list of sources).
- IGMPv3: The IDMR working group has submitted this for Proposed
MAGMA takes ownership after publication as RFC.
- MLDv2: draft-vida-mld-v2-00.txt
- Multicast Source Filtering API. This specification describes the API
used to interact with IGMPv3 and MLDv2 to indicate source filters.
- Host determination of network group membership. In a multicast
environment, systems may be interested in learning whether or not
there are any group members, in order to save the trouble of sending
data that nobody is listening to.
- Multicast Source Notification of Interest Protocol:
- Multicast forwarding in tree topologies using IGMP/MLD Proxying
- Create a single document from:
- Source-Specific Multicast (SSM) consideration document. This work
will describe the use of IGMPv3/MLDv2 in an SSM environment.
- Considerations for "IGMP snooping" switches (switches that watch IGMP
exchanges in order to determine multicast forwarding behavior)
- Multicast Router Discovery: The IDMR working group has submitted this
for Proposed Standard. MAGMA takes ownership after publication as
- Snooping Considerations: draft-ietf-idmr-snoop-00.txt
- Group management MIBs
- update RFC 2933 for IGMPv3
- update RFC 3019 for MLDv2
- Interaction between IGMP/MLD and routing protocols
- Extensions to MLD supporting anycast group memberships including
authentication and access control mechanisms
In addition, this working group will coordinate with other IETF working
groups where multicast and anycast group management protocols are
utilized as well as coordinating with the Multicast Security WG.
Goals and Milestones:
|Done|| ||Submit IGMPv3/MLDv2 Interfactions with Routing Protocols as
|Done|| ||Submit IGMP/MLD Proxying Specification as Proposed Standard |
|Jul 03|| ||Submit IGMP & MLD Snooping Considerations as Informational |
|Jul 03|| ||Submit SSM considerations for IGMPv3 & MLDv2 as Proposed
|Aug 03|| ||Submit Multicast Source Filtering API as Informational |
|Dec 03|| ||Submit MSNIP for IPv4 & IPv6 Specification as Proposed
|Dec 03|| ||Submit IGMPv3/MLDv2 MIB as Proposed Standard |
Request For Comments:
IANA Considerations for IGMP (RFC 3228) (6473 bytes)
Current Meeting Report
Minutes for IETF 57 MAGMA Working Group meeting - Brian Haberman
<firstname.lastname@example.org> and Isidor Kouvelas
Reported by Marshall Eubanks
There is a new version of the MLDv2 draft. The revised draft (-07) is
awating AD followup. There are also implementations available for Linux.
Rolland Vida - The revised draft reflects all the comments received from the
Toerless Eckert - On the router side we (Cisco) have it too. Isidor -
Cisco also has a full host side implementation. Venkata Jagana from IBM - We
also have an implementation and would like to do
Rolland Vida - A full host and router side implementation is available
since September 2001 for FreeBSD. It was developed at LIP6-Paris
(actually, in collaboration with LSIIT-Strasbourg).
Brian - As a work item for myself I will talk to the IPv6 Node
Requirements author about including MLDv2 in the Node
The IGMP/MLD Proxy draft has been resubmitted following AD comments.
The SSM option for Multicast Router Discover has gone to last call but may be
affected by more general issues, such as whether or not there should be an
admin-scoped SSM address range and whether it (the SSM range) should be
The MSF API draft has passed working group last call.
Dave Thaler - To my knowledge, everything that has been brought up has been
Brian - So we should be able to go to the IESG ?
Dave - Yes
The IGMPv3.MLDv2 draft is awaiting revisions to go to last call.
Isidor Kouvelas - MSNIP Update
The big issue is the support for ad hoc networks - i.e., networks which
have no routers.
Ad-hoc support requirement is that there is no modificiation in code in
existing receivers. Source control can only happen withing 232/8
Toerless Eckert - Why can't you configure a different range?
Isidor - Well you can, and that's one of the things that we have to
In regard to the state issue (state being kept by source hosts as a
result of explicit tracking of (local) recevers) there was some
discussion on the mailing list and the consensus seemed to be that this was
not a big deal.
For robustness purposes there has to be a dummy querier, and the dummy
querier has to implement pretty much the full router side IGMPv3
protocol. Full router side requierment is because if a real router shows up,
they could loose the Querier election and then things will break.
Dave Thaler - I think that it would be OK to run without keeping any state
except for state on your own broadcasts.
Dave Thaler - As far as I know, this protocal is as scalable as the
underlying IGMPv3 protocols.
Toerless - IGMP is prone to attacks anyway
Dave Thaler - The WG messed up by not documenting the requirements in the
first place, when they were originally discussed.
Isidore. A new dummy bit is needed to distinguish dummy from real
queriers. Senders have to detect that they are on an ad-hoc link and join
the ALL_IGMPv3_Routers group. Potential senders need to directly process
Pekka - I think it is interesting the huge amount of complexity that is
being added to account for this special case. I think that the working
group needs to consider carefully the need for this.
Isadore - The complexity is significant.
Dave Thaler - But then you need to know whether you are on an ad hoc
This should have been part of the requirements document, but this
document was never completed.
Brian Haberman - The basic question for the Group is where do we want to go
with this? I will have Isidor send a note to the mailing list.
IGMPv3 - MLDv2 MIB - now has separate tables for host and router. Is this
what people want?
Dave Thaler - Yes, Except that the source list table also needs to be
split, and there is some useless information, such as for MLDv1 hosts.
I saw that it allows you to disable MLD snooping, which should not be
Also, right now it only allows you to manage a MLDv1 or IGMPv2 host. That
should be changed.
Multicast and Anycast Group Membership (MAGMA) IETF 57