Current Meeting Report
Slides


2.3.9 Multicast & Anycast Group Membership (magma)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/30/2002

Chair(s):
Bill Fenner <fenner@research.att.com>
Brian Haberman <bkhabs@nc.rr.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@sun.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:
AUG 01  Submit SSM considerations for IGMPv3 specification as Proposed Standard.
DEC 01  Submit IGMPv3 Interactions with routing protocols document as Informational.
DEC 01  Submit MLDv2 specification as Proposed Standard.
DEC 01  Submit IGMP Snooping Considerations document as Informational.
DEC 01  Submit Extensions to MLD for Anycast as Proposed Standard.
DEC 01  Submit Mixed-version IGMP Proxying as Proposed Standard.
DEC 01  Submit Multicast Source Filtering API as Informational
DEC 01  Submit SSM considerations for MLD specification as Proposed Standard
MAR 02  Submit IGMPv3 MIB as Proposed Standard.
MAR 02  Submit MSNIP for IPv4 specification as Proposed Standard.
MAR 02  Submit MLDv2 MIB as Proposed Standard.
MAR 02  Submit MLD Snooping Considerations document as Informational.
MAR 02  Submit MSNIP for IPv6 specification as Proposed Standard.
MAR 02  Submit MLDv2 Interactions with routing protocols document as Informational.
MAR 02  Submit MLD Proxying specification as Proposed Standard.
Internet-Drafts:
  • - draft-ietf-magma-msf-api-03.txt
  • - draft-vida-mld-v2-03.txt
  • - draft-ietf-magma-igmpv3-and-routing-02.txt
  • - draft-ietf-magma-snoop-02.txt
  • - draft-ietf-magma-mrdssm-00.txt
  • - draft-ietf-magma-msnip-00.txt
  • - draft-ietf-magma-rfc2933-update-00.txt
    • Request For Comments:
    RFCStatusTitle
    RFC3228BCPIANA Considerations for IGMP

    Current Meeting Report

     MAGMA Minutes

    Key
    Q = Question
    A = Answer
    C = Comment

    Document Status

    Ready for last call: MLD version 2
    Multicast source filtering API

    ...and will send out last call after the IETF meeting.

    draft-ietf-magma-mrdssm-00.txt is out of charter, but published in this working
    group anyway. Oops. Holdover from IDMR.

    IGMPv3 MIB
    draft-ietf-magma-rfc2933-update-00.txt
    Reflect IGMPv3 source filtering changes (INCLUDE/EXCLUDE)
    Source list table added
    Filter mode object in Cache table added (INCLUDE/EXCLUDE)
    IGMPv2 host and querier timers
    Combine MLDv2 and IGMPv3 MIBs?

    Toerless Eckert: MIB does not allow for explicit tracking of state. Proposed
    including "explicit tracking" related objects as optional MIB variables.
    Bill Fenner : Neither does the underlying IGMP spec, and IGMP spec does not
    require explicit tracking.

    MCOP
    draft-lehtonen-magma-mcop-00.txt

    Goals: Control multicast receivers and sources
    Protection against DoS
    Centralized policy tool
    No crypto
    No mods to IGMP/MLD
    No mods to core routers
    Independent of multicast routing protocol

    Strategy: MCOP-enabled first-hop multicast router applies policy based on MCA
    (Multicast Control Agent) definition and management.

    Dave Thaler Q: Clarify goals & requirements? What is the threat you're trying to
    protect against?

    A: Protecting against DoS on the routed infrastructure, not on the local
    subnet/link.

    C: Please reword goal to be more specific.

    Q: Did not see anything that the host had to do. Is that right? If so, very
    good.

    C: Yes, nothing like that required.

    Q: If you have an MCA doesn't control a range, it's probably not useful to
    protect against DoS attacks.

    C: Would also like to see more detail on attacks to be protected against.

    Q: Underlying assumption: is the full ACL too large or too dynamic to push down
    into the router? Why use the MCA rather than putting it into the router
    directly?

    C: If that's assumption, please state as part of applicability domain.

    C: Bursty source problem; can drop first or early packets in a burst while the
    MCA response is created. Please state.

    C: Easiest way to notify may be to respond to IGMP or MLD, but concur that end
    nodes should be notified.

    C: May be more appropriate for MSEC working group.

    Eric Youngmark Q: Could use more detail about attacks the draft is trying to
    protect against.

    A: If interest, yes can.

    Bill Fenner Q: Have you thought about using Diameter instead of special
    protocol?

    A: No.

    Q: Inter-domain or not? Multiple servers across different ASes?

    A: Intra-domain focus, inside one AS. Can control local senders and receivers,
    even if the groups are Internet-wide.

    Q: You have to worry about same-subnet traffic.

    A: Yes, need to use some other mechanism.

    C: Talk to MSEC. Add more info on why not use more general management framework.


    Toerless Eckert C: Would like to see stronger reasoning why some other
    management protocol is not being used, as multicast-specific protocols are hard
    to justify.

    C: IGMP snooping switches may also require such policy control.

    Bill Fenner: C: Would like to see ability for source/receiver to discover that
    blocking happened.

    Ketan Talaulikar: Q: Consider hierarchical MCA?

    A: Did consider, but not easy, especially cross-domain.

    C: Looks more like policy protocol.

    IP Multicast Metrics
    draft-stephan-ippm-multicast-metrics-00.txt

    Needed for: designing multicast tree inside network
    accounting for multicast service
    controlling quality
    controlling inter-domain service performance

    Measure hop-by-hop delay, hop-to-hop sequence, end-to-end delay, loss, source to
    listeners average delay.

    Reporting of listener numbers.

    SNMP Trap to setup measurement and to report on the fly.

    Mark Olivier Q: Test packet is part of the same group?

    A: Yes, but you can use any group you want.

    Q: That means each element that needs to be part of the test, will need to
    inspect each packet to see if it's part of the test?

    A: It will not receive the packet if it has not joined the group.

    C: This will probably have forwarding performance impact.

    Q: How do you measure loss? Your test packet may not follow the same path
    especially if it builds the tree.

    A: Use a sequence number in the measurement packet, and set the number of times
    to repeat the test packet.

    C: Need to discuss this question in more detail offline.

    Bill Fenner Q: Do you require synchronized clocks?

    A: Yes, and that's doable.

    C: Although there are a number of multicast experts in this group, it's probably
    not the right group for multicast measurement.
    Perhaps MBONED? Would encourage this work.

    MAGMA Milestones Update

    We've missed all our milestones so it's time to rewrite them!

    Original thought was to finish the IPv4 stuff first, and then work on the IPv6
    stuff later. However, some of the IPv6 stuff is creeping in already, so intent
    is to require IPv4 and IPv6 applicability for each draft.

    Are the requirements for IPv6 ASM going away?

    Dave Thaler: should not remove IPv6 ASM from the charter, but it can be a very
    low priority and the last work item.

    Slides

    Measuring the performance of multicast services
    Multicast Control Protocol (MCOP)
    GMP MIB Extensions