2.3.9 Multicast & Anycast Group Membership (magma)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-20

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:
JAN 03  Submit Multicast Source Filtering API as International
FEB 03  Submit IGMP/MLD Proxying Specification as Proposed Standard
FEB 03  Submit IGMPv3/MLDv2 Interfactions with Routing Protocols as Informational
FEB 03  Submit SSM considerations for IGMPv3 & MLDv2 as Proposed Standard
MAR 03  Submit IGMP & MLD Snooping Considerations as Informational
MAR 03  Submit MSNIP for IPv4 & IPv6 Specification as Proposed Standard
JUL 03  Submit IGMPv3/MLDv2 MIB as Proposed Standard
  • - draft-ietf-magma-msf-api-03.txt
  • - draft-holbrook-idmr-igmpv3-ssm-04.txt
  • - draft-vida-mld-v2-06.txt
  • - draft-ietf-magma-igmpv3-and-routing-04.txt
  • - draft-ietf-magma-snoop-06.txt
  • - draft-ietf-magma-igmp-proxy-02.txt
  • - draft-ietf-magma-mrdssm-02.txt
  • - draft-ietf-magma-msnip-02.txt
  • - draft-ietf-magma-rfc2933-update-00.txt
  • - draft-ietf-magma-mld-source-05.txt
  • Request For Comments:
    RFC3228BCPIANA Considerations for IGMP

    Current Meeting Report

    commentsMagma IETF 56
    Agenda bashing
    Bill Fenner has decided that with his AD work he cannot co-chair so  
    Isidor Kouvelas is the new co-chair.
    Bill - So long and thanks for all the fish !
    Julien Chesterfield - MIB update
    IGMPv3 and MLDv2 MIBs
    missed new draft deadline but is available on line
    Name was changed to Multicast Group Membership Discovery (MGMD)
    Time granularity changed to 10’s of seconds and milliseconds
    New InetAddressType variable to sort between IPv4 and IPv6
    Open issues
    What variables should have read / write access ?
    Discussion on this with Dave Thaler - variables that the IGMP RFC says 
    should be configurable, may have read write access.
    Should statistics be per-port as well as per-interface or just 
    per-interface ?
    Tom  Pusateri I would like to see a separate group table per 
    Dave Thaler - Today the IGMP MIB sorts everything by group address. It was 
    thought to be more interesting to say, “what interfaces does this group 
    have ?” rather than “What groups does this interface have?” This could be 
    changed, as this was settled about 8 years ago and conditions are rather 
    different today, but if you want the upgrade to be simple you should keep 
    this the same as the IGMP MIB
    Bill Fenner - I very much like the source list, as an additional table.
    Julian - I will add that to the next draft.
    Tom  Pusateri - We have the concept of a local group join on a box, so that 
    the router  can join the group.
    Bill Fenner - Could you represent this as a join on the loopback 
    interface ?
    Brian Haberman - I have actually done this - if the router joins to the 
    Bill Fenner - I think that Tom is talking about the case where the router 
    does not generate any IGMP data and it is not really joined on any 
    Tom  Pusateri - There is no interface.
    Dave Thaler - It’s great to see so much discussion on a MIB in a non-ops 
    In IGMP there is a mixture of information when you are a host or a 
    router, and if you split this into two tables things are much simpler.
    Brian Haberman - Is there anyone here who would object to splitting this 
    into a router specific and a host specific part ?
    <No complaints>
    So, I ‘ll make a note to Julian to ask him to  make this change.
    Brian Haberman - Document Status
    3 documents are backed up at the IESG
    Proxy draft
    MRD SSM Option
    IGMPv3 / MLDv2 Interactions
    Other documents are at or just through working group last call.
    Every document except the IGMPv3/MLDv2 MIB document is at working group 
    last call status or later.
    Dave Thaler
    Multicast Source Filter API
    This document also missed the ID deadline.
    Recap :
    No open issues on the Basic (Delta-Based) API
    API could be useful even if IGMPv3 / MLDv2 is not available
    Mute and unMute is called Block and Unblock.
    Some IPv4 specific socket options as the way you identify an interface is 
    IPv4 specific uses IP address
    Advanced API is where the open issues are
    Need to both get and set filter mode and source list
    One open issue is whether the API should use getsockopt or even new 
    functions instead of ioctl
    Austin Group (POSIX) discussion
    3 principles
    Lack of type safety is a bad thing which should be avoided
    Name space pollution should be avoided
    Existing practices should be standardized.
    Neither getsockopt or ioctl is type safe.
    The group seems to favor defining a new function
    This allows you to put a wrapper over getsockopt or ioctl to implement the 
    new function
    Therefore, for draft 04 want to
    -take old ioctl api to Appendix as historical
    - Define new type safe functions
    - Added comments on implementation freedoms
    A requirement
    - Applications should be able to detect when the new source filter 
    API’s are not available and to fail gracefully
    Is this still a requirement ? Can it be done ? Should we restrict the 
    implementation freedom in any way ?
    Bill Fenner - Are there still getsockopt calls ?
    Dave Thaler - For the basic API there are still getsockopt calls, yes.
    I believe that this requirement is atrun time, not compile time.
    Pekka - The first part of the requirement is essential. The second is not.
    Dave Thaler - We expect that most people will use the basic API and will not 
    use the advanced API.
    I am taking this discussion as tentative confirmation that new 
    functions are the way to go.
    Bill Nickless - Why does this API include the interface ?
    Dave Thaler - You can always pass a zero if you do not know what 
    interface to use. It just supports the use of a specific interface if you 
    need to do that.
    Bill Fenner. This is again one of these things where you cannot tell if the 
    buffer is completely filled when you do the call. If the buffer gets 
    completely filled you don’t know if it is exactly filled or if there is 
    Dave Thaler - You could return an error and give the buffer as filled as a 
    special error case.
    <groans from the audience>
    Bill Fenner - You could return how many items are available total when you do 
    the call as an additional parameter
    Dave Thaler - We should consider this and take it to the list.
    (some discussion followed which revealed that the socket was missing from 
    the getipv4sourcefilter and the setipv4sourcefilter  parameter list, 
    whereupon it was duely added.)
    Bill Fenner - since all of the other functions contain buffer lengths, you 
    need it here for the group as well.
    We will add the socklen_t for the group list
    Audience member - Question about interface index = 0
    Dave Thaler - It is illegal for interface index to start with zero.
    Given that this has changed enough, I think that we should go for 
    another working group last call.
    Brian Haberman - I think that we should put this to the list once the new 
    document comes out for another WG last call.
    Dave Thaler
    Operational Problems with IGMP snooping switches -
    Good news - we are seeing IGMPv3 in operational use
    Bad news - Since the start of 2003, at least three independent reports of a 
    Problem - Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host
    Router sends IGMPv3 query, which tells the host to use IGMPv3
    Hosts send IGMPv3 reports
    What then happens ?
    Switch does one of these 3  :
    1.) Doesn’t forward reports
    2.) Forwards reports but does not forward data
    3.) Forwards reports and data but no queries, data then times out
    Result - Multicast breaks when you upgrade a router or host 
    (whichever is last) to IGMPv3.
    Operational workarounds :
    1.) Router is the authority. So only configure IGMPv3 on an interface 
    where there are _no_ IGMPv2 only switches.
    - Problem is switch and router may be owned by different 
    - If two customers share the same link, this means that the other 
    customer cannot run SSM ! (Without upgrading or changing the 
    2.) Customers have requested that hosts be configurable to force IGMPv2 use 
    even though the RFC would use IGMPv3
    - SSM would not work anyway
    - This requries manual configuration on every node.
    Isidor K. - If the IGMPv3 queries do not go through, then there is still a 
    3.) Disable IGMP snooping entirely.
    Does this affect the snooping draft ?
    John Zwiebel - Let’s just fix this and not do kludgy work-arounds.
    Dave Thaler - the problem is that there are not very many 
    IGMPv3-capable switches yet
    Bill Nickless - there may be a hole in the spec if the host and the 
    router cannot tell what version of the protocol is in use.
    Dave Thaler - The draft says that you
    - flood any unrecognized IGMP
    - flood the data to router ports (configurable to all ports) if there are no 
    reports for a group
    - doesn’t cover the case where the report was received
    This problem should be at least documented if not fixed if possible in the 
    snooping draft.
    Brian Haberman - Another possible option
    Joel Jaeggli - this is a problem with existing switches not a 
    potential problem, so adding new features for the switch does not help 
    Dino F. There is no type variable in the query to tell the difference 
    between IGMPv2 and v3, the only clue is the length, and it may be a lot to 
    ask a snooping switch to look at that.
    Morten Jagd Christensen
    IGMP and MLD snooping
    Substantial comments
    -Switch must not reject membership reports  because of source IP =
    Dave Thaler - this is critical to have in there for the v6 section, even 
    more so than for the v4 section.
    - Should be more systematic about topology changes
    Don’t send a geneal query on all ports becuase a host is added to an 
    unused port.
    We will take these changes and produce version 7
    So, the real question is, what do we do next ?
    Brian Haberman - The number of changes are enough that we should bring this 
    before the group briefly before we take it to working group last call.


    Combined IGMPv3 and MLDv2 MIBs
    Multicast Source Filter API
    IGMP and MLD snooping