Last Modified: 2003-01-20
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
- 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.
|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|
|RFC3228||BCP||IANA Considerations for IGMP|
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 10s 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 interface. 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 group 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 interface Tom Pusateri - There is no interface. Dave Thaler - Its great to see so much discussion on a MIB in a non-ops area. 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 different 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 APIs 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 dont know if it is exactly filled or if there is more. 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 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.) Doesnt 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 organizations - If two customers share the same link, this means that the other customer cannot run SSM ! (Without upgrading or changing the topology.) 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 problem. 3.) Disable IGMP snooping entirely. Does this affect the snooping draft ? John Zwiebel - Lets 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 - doesnt 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 much. 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 = 0.0.0.0 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 Dont 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.