2.3.7 Multicast & Anycast Group Membership (magma)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-04

Isidor Kouvelas <kouvelas@cisco.com>
Brian Haberman <brian@innovationslab.net>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.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 WG.

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 Standard. 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: draft-ietf-idmr-msnip-00

- 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 RFC. - 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
Done  Submit IGMP & MLD Snooping Considerations as Informational
Done  Submit SSM considerations for IGMPv3 & MLDv2 as Proposed Standard
Done  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-holbrook-idmr-igmpv3-ssm-06.txt
  • - draft-vida-mld-v2-08.txt
  • - draft-ietf-magma-igmpv3-and-routing-05.txt
  • - draft-ietf-magma-snoop-10.txt
  • - draft-ietf-magma-igmp-proxy-04.txt
  • - draft-ietf-magma-mrdssm-03.txt
  • - draft-ietf-magma-mgmd-mib-02.txt
  • - draft-ietf-magma-mrdisc-00.txt
  • Request For Comments:
    RFC3228BCPIANA Considerations for IGMP
    RFC3590 PS Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
    RFC3678 I Socket Interface Extensions for Multicast Source Filters

    Current Meeting Report

    Minutes for IETF 59 MAGMA Working Group meeting taken by Dave Thaler.
      Brian Haberman <brian@innovationslab.net>
      Isidor Kouvelas <kouvelas@cisco.com>
    > Multicast & Anycast Group Membership WG (magma)
    > Tuesday, March 2 at 1415-1515
    > ==============================
    > AGENDA:
    >      1. Intro & Agenda Bashing                chairs           5 
    >      2. Document Status                       Haberman        10 
    router disc newly picked up from IDMR
    msfapi is now an RFC
    MGMD MIB updated, will be presented today
    >           - draft-vida-mld-v2-08.txt
    MLDv2 is at RFC editor queue
    >           - draft-ietf-magma-snoop-10.txt
    in RFC queue but blocked on refs (MRD, proxy)
        authors want to update text to make refs informative
    Haixiang He: question about how to handle multiple routers on 
    different switch ports will send a note to the authors with suggested text
    fenner: if not simple wording clarification, it will get kicked back to 
    toerless: what is target status?
    haberman: informational
    >           - 
    in RFC queue but blocked on normative refs
    >           - 
    addresses comments from 2nd WG last call
    ready to advance
    to be obsoleted by draft-holbrook-ssm-scoping-00
    not feasible anyway since MRD no longer allows options
    revision pending.  
    will be simplified to use fixed SSM range per holbrook draft
    >      3. Group Management MIB                  Chesterfield    10 
    >           - draft-ietf-magma-mgmd-mib-02.txt
    >           - Goal: status update
    clarified HostCacheStatus
    added HostCacheUp
    fixed various typos
    interval timers range - what is the right range restriction?
    thaler: not currently implementable since tables changed and OIDs 
    conflict with IGMP MIB
    >      4. Multicast Router Discovery            Martin          10 
    >           - draft-ietf-magma-mrdisc-00.txt
    >           - Goal: status update
    went to IESG in June 2003, several issues were raised
    v6/4 not treated equally
    option format inconsistent with NDP
    concern about use of NDP for v6
    insufficient security section
    use of All-Systems causes extra processing on uninterested nodes
    other problems
    TLV option format overkill for this application easy DoS attack with old 
    Terminate message
    Changes in -00:
    protocol agnostic
    IGMP for v4, MLD (not NDP) for v6
    removed TLV options
    replaced with fixed Query Interval, Robustness fields
    TTL/Hop Limit is consistently 1
    defined All-Snoopers group
    Terminate now triggers Solicitation rather than shutdown of 
    forwarding security statement identifies risks and points at SEND
    after -00:
    suggestion to add Link Local to draft name
    specify encoding of Query Interval ala IGMP/MLD
    validate that src addr is subnet-local for the interface
    add SEND to informative ref
    specify which type (informative) for type codes
    daley: security issues - do you want to secure MLD query?
    thaler: how do you prevent implosion of solicitations
    martin: only switches send them, and there's a random delay
    discussion of TLV options
    kouvelas: want options, e.g. for MSNIP capable, etc capabilities of 
    multicast router
    thaler: either don't put TLV encoding in the spec or put some options in the 
    spec so you can use and test it
    daley: could just define pad option 


    Document Status
    Group Management MIB
    Multicast Router Discovery