2.3.8 Multicast & Anycast Group Membership (magma)

Last Modified: 2003-07-29

Isidor Kouvelas <kouvelas@cisco.com>
Brian Haberman <brian@innovationslab.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Margaret Wasserman <mrw@windriver.com>
Mailing Lists:
General Discussion: magma@ietf.org
To Subscribe: magma-request@ietf.org
In Body: subscribe
Archive: http://www1.ietf.org/mail-archive/working-groups/magma/index.html
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.
  - draft-ietf-idmr-msf-api-01.txt

- 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:
    - draft-ietf-idmr-igmp-proxy-00

    - draft-he-mixed-igmp-proxy-00

- Source-Specific Multicast (SSM) consideration document.  This work
  will describe the use of IGMPv3/MLDv2 in an SSM environment.
  - draft-holbrook-idmr-igmpv3-ssm-01.txt

- 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
  - draft-ietf-idmr-igmpv3-and-routing-00.txt

- Extensions to MLD supporting anycast group memberships including
  authentication and access control mechanisms
  - draft-haberman-ipngwg-host-anycast-00.txt

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 Informational
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 Standard
Aug 03  Submit Multicast Source Filtering API as Informational
Dec 03  Submit MSNIP for IPv4 & IPv6 Specification as Proposed Standard
Dec 03  Submit IGMPv3/MLDv2 MIB as Proposed Standard
  • - draft-ietf-magma-msf-api-05.txt
  • - draft-holbrook-idmr-igmpv3-ssm-04.txt
  • - draft-vida-mld-v2-07.txt
  • - draft-ietf-magma-igmpv3-and-routing-04.txt
  • - draft-ietf-magma-snoop-09.txt
  • - draft-ietf-magma-igmp-proxy-03.txt
  • - draft-ietf-magma-mrdssm-03.txt
  • - draft-ietf-magma-msnip-04.txt
  • - draft-ietf-magma-mld-source-07.txt
  • - draft-ietf-magma-mgmd-mib-00.txt
  • Request For Comments:
    IANA Considerations for IGMP (RFC 3228) (6473 bytes)

    Current Meeting Report

    Minutes for IETF 57 MAGMA Working Group meeting - Brian Haberman
    <brian@innovationslab.net> and Isidor Kouvelas 
    <kouvelas@cisco.com> presiding.
    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 
    interoperability testing.
    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 
    these reports.
    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