2.3.14 Multicast & Anycast Group Membership (magma)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-18


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://www.ietf.org/mail-archive/web/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

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 MAGMA group has taken ownership of this draft over from IDMR.
  It will be revised and submitted as a Proposed Standard.

- Snooping Considerations: draft-ietf-magma-mrdisc-00.txt
  (previous revisions draft-ietf-idmr-snoop-XX.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
Jul 04  Submit IGMPv3/MLDv2 MIB as Proposed Standard
Sep 04  Submit MRD as Proposed Standard
Sep 04  Submit MSNIP for IPv4 & IPv6 Specification as Proposed Standard


  • draft-holbrook-idmr-igmpv3-ssm-08.txt
  • draft-ietf-magma-igmpv3-and-routing-05.txt
  • draft-ietf-magma-snoop-12.txt
  • draft-ietf-magma-igmp-proxy-06.txt
  • draft-ietf-magma-mgmd-mib-04.txt
  • draft-ietf-magma-mrdisc-04.txt

    Request For Comments:

    RFC3228 BCP IANA Considerations for IGMP
    RFC3590 PS Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
    RFC3678 I Socket Interface Extensions for Multicast Source Filters
    RFC3810 Standard Multicast Listener Discovery Version 2 (MLDv2) for IPv6

    Current Meeting Report

    Magma Meeting IETF 62
    March 8, 2005
    4:30 PM

    Isidor Kouvelas <kouvelas@cisco.com>
    Brian Haberman <brian@innovationslab.net>

    Minutes for IETF 62 MAGMA Working Group meeting taken by Marshall Eubanks.

    Brian Haberman - Agenda

    Where do things stand ?
    We are in good shape.

    MRD is in AD follow-up

    MIB has completed WG last call
    one more rev to fix SMI issues

    other documents are all in the RFC editor's queue

    MRD Changes -
    Jim Martin jim@netzwert.ag

    Some followup work after 04

    Changes in 04

    Russ Housley pointed out that we used IPSec AH.
    Should switch to ESP. This is required by RFC2401bis, and AH
    lacks a signature mechanism.

    Added the potentiality of using a null encryption mechanism.

    Key selection was unclear - now a symmetric key manually configured.

    Thomas Narten - Several unclear references to advertisements.

    NeighborDeadInterval is now 3 times the received Advertisement Interval.

    Header field defined protocol to IGMP - so added ICMPv6 for IPv6

    He thought that jitter was too large. They did not.

    Bert Wijnen had some comments.
    Alex Zinin asked for some clarifications.

    So, those were the 03 to 04 changes. Thomas came back and was
    unhappy with the checksum calculation, but they convinced him that
    their calculation was OK, as it is consistent with the way
    that other protocols are doing it.

    He was unhappy about the jitter, so we changed it to what he suggested for 05 (but independently), with an explicit jitter interval.

    We are waiting for further comments before submitting 05

    Question : Isn't the jitter was the same ?

    A. We narrowed the window on the jitter

    Pekka Savola : There is a push in security for automatic key management.
    Ross might through it back asking for that.

    Dave Thaler : In the change from AH to ESP, you lose checking of
    IP options and header fields. Given that the draft uses header fields

    Someone pointed out that they could spoof a packet and send it to me by unicast. Maybe there should be language saying drop it.

    Jim Martin : That is reasonable.

    Pekka : It still needs to be a valid neighbor, otherwise the
    ESP transport will fail. If this is a MUST, its ok, but if it says that you SHOULD use ESP, then there needs to be further checking.

    Dave Thaler : It does not say MUST.

    Bill Fenner : About the check sums. It wasn't clear to me - did you have to change it ?

    Brian - for Julian Chesterfield - the MIB

    Currently, after comments during last call, removed the RowStatus
    ReadCreate functionality from the cache tables for security reasons.

    We ran it through Smilint, and there were a few errors, which Julian will fix, and it will be ready for the IESG. If anyone has issues with the MIB, I would like to see them raised.

    Brian - the Working Group Future

    The two documents discussed here are the last ones we have. Of the
    other two that were at one time considered, we are going to let MSNIP die a graceful or ungraceful death, and also the SSM MRD extension.

    So, unless anyone has any issues that we should be raising, this will be the last WG meeting. Does anyone have any issues ?

    Pekka : The working group will be closed ?

    Brian : The working group will be closed when the document goes to the RFC editor's queue.

    Scott Bradener : It's not when the document goes into the queue, but when they go out of the tree.

    Dave Thaler : I would like to complement the working group for accomplishing what they set up to do. If there were going to be any changes in a new IGMP, that should be in a new working group.

    Pekka : What has been debated on and off is extensions to anycast.

    And there is also MAGMA security analysis document, which would be very useful.

    Brian : There has been push back from the universe about how anycast should be and could be deployed.

    Toerless : Why is anycast different ? Other groups do things that have had push back.

    Brian : At one point we had discussed putting in anycast, but there didn't seem to be any interest and so it died.

    Greg Daley : I think that we can get the MAGMA security document into the groups mailing list before it shuts down.


    Multicast Router Discovery
    Group Management MIB
    Group Management MIB