2.5.4 Inter-Domain Multicast Routing (idmr)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 29-Feb-00


Bill Fenner <fenner@research.att.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:idmr@cs.ucl.ac.uk
To Subscribe: idmr-request@cs.ucl.ac.uk
Archive: http://www.jnx.com/~pusateri/idmr

Description of Working Group:

The Internet-Draft Multicast Remnants (idmr) working group is chartered to finish certain parts of the work started in the Inter-Domain Multicast Routing (idmr) working group. The group is expected to live only long enough to see the existing work items progress through the standards track, and is not expected to take on new work items.

The specific work items are:

DVMRP, DVMRP MIB, Domain Wide Reports, IGMP MIB, IGMP Proxying, IGMPv2, IGMPv3, Multicast Interop, Multicast Router Discovery, Multicast Routing MIB, and Multicast Traceroute.

Goals and Milestones:

Nov 99


All specs to at least Proposed Standard. MIBs may lag.

Mar 00


All MIBs to at least Proposed.

Jul 00


Address any spec issues; all documents to Draft if no major problems

Nov 00


All documents to Standard if no major problems. Disband WG.


Request For Comments:







Scalable Multicast Key Distribution



Core Based Trees (CBT) Multicast Routing Architecture



Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --



Internet Group Management Protocol, Version 2



Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification



Interoperability Rules for Multicast Routing Protocols

Current Meeting Report

IDMR met in one session at the Adelaide IETF. These minutes were collected by Bill Fenner.

Bill Fenner spoke on IDMR document status. The DVMRPv3 spec needs an update for GenID per interface (and perhaps some others), and DVMRPv3 needs an applicability statement. The DVMRP MIB is ready but is blocked on the spec. Multicast Traceroute had a recent update (presented later) and was going to be put to WG Last Call except for a suggestion of an appendix on the heuristics that the mtrace client currently uses to get good data from buggy sources. The Multicast Router Discovery spec has expired and needs to be updated. IGMPv2 needs to be updated based on Erik Nordmark's MLD spec comments in order to go to Draft Standard. IGMPv3 was recently updated (presented later) and a little more needs to be done. The IGMPv3 API spec is brand new and needs comments from the WG.

The Domain Wide Report and IGMP Proxying specs are in "working group chair limbo" -- they both passed their WG Last Calls but the chair never submitted them to the IESG. The PIM, IPMROUTE and IGMP MIBs are in the IESG black hole; Rob Coltun said something about MIB compiler flags that I didn't understand but we decided to take it offline.

Bill Fenner continued on the multicast traceroute document update. These details are available both in the updated document and in the slides; please refer to one or the other to find out what's changed. The document will be updated again to include known implementation problems and workarounds in an appendix, and then be submitted for Working Group Last Call.

Isidor Kouvelas then gave an update on the IGMPv3 spec. Refer to the slides for the details of the changes. The comment was made that the document says that reserved bits MUST be 0 when receiving; this precludes certain types of forward compatibility so should be changed.

Dave Thaler presented the new Multicast Source Filtering API; this is a concrete API for both group membership and source filtering in IPv4 (i.e. IGMPv1,v2 and v3) and IPv6 (i.e. MLD and ??). The original specification of the advanced API used a setsockopt() to set the filter, and ioctl() to get the filter. Dave made the proposal to change them both to ioctl() for symmetry, and the WG had no objections.

Dave Thaler then talked about treating IPv6 in the existing multicast MIBs. His plan is to submit protocol-independent IPMROUTE and PIM MIBs; these will be useful for both IPv4 and IPv6. IGMP and MLD are similar but not the same protocol, so it doesn't necessarily make sense to have a single MIB for IGMP (IPv4) and MLD (IPv6).

Hugh Holbrook then talked about IGMP and Source-Specific Multicast. This is Appendix I of draft-holbrook-ssm-00.txt . No changes tohost IP stacks are required; a normal IGMPv3 host stack can handle the requirements of source-specific multicast. Source-Specific applications are required to only use the IGMPv3 API to join source-specific sessions; if a host stack sends a 'join group' (e.g. IGMPv2 membership or IGMPv3 exclude-none), it will simply be ignored.

IGMP-speaking routers doing source-specific multicast are configured with the group range (currently 232/8 but could change in the future) that is to be used for source-specific sessions. These routers only pay attention to IGMPv3 'include'-style requests for these groups; any request to join the entire group is ignored.

There was some discussion about whether or not it makes sense to restrict the range in this way; the current IANA assignment says that behavior is undefined if you join the whole group (e.g. a router could do Internet Standard Multicast). The assertion was made that one of the reasons content providers want Source-Specific multicast is to prevent reception of other sources, thus Internet Standard Multicast is unacceptable. No consensus was reached in this discussion.


Multicast Source Filter API
IPv6 Multicast Routing MIBs
IGMP Version 3