2.5.5 Inter-Domain Multicast Routing (idmr)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 18-Oct-99


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

Internet-Draft Multicast Remnants met in a single session at the DC IETF. The minutes were taken by Bill Fenner.

Bill Fenner gave a summary of the documents in the Working Group and their status. The DVMRPv3 spec and MIB had finished a Working Group Last Call immediately before the meeting, however a comment on the DVMRPv3 spec was brought up at the meeting so it will have to go through another revision. The DVMRP applicability statement had been sent to the IDMR mailing list before the meeting; comments were solicited at the meeting but none arose.

IGMPv2 needs a revision before being progressed to Draft. The IGMP MIB is ready for IETF Last Call; David Oran (Routing co-AD) promised to find out its status. IGMPv3 is just about ready for WG last call; another revision is expected in January. The IGMP Proxying document finished a WG Last Call without comments, and the IGMP router discovery spec is close to finished.

The multicast routing and PIM MIBs are also ready for IETF Last Call.

Domain-Wide Reports finished a WG Last Call with no comments.

Multicast Interoperability Rules was published as RFC2715.

Multicast Traceroute needs to be updated to discuss asynchronous counters - routers that update packet counters in the forwarding engine but only make that information available to the CPU periodically and not on demand.

Brad Cain gave a summary of the updates to IGMPv3 in draft -02. Major changes include cleanup of the document, especially the state tables, and the ability to split group information across reports if a host has too many sources in an INCLUDE. Splitting doesn't really work in EXCLUDE mode. Updates still to be done include adding the Query Interval and Robustness Variable to Query messages so that Non-Queriers may set their timers based upon the values in the message (instead of having to synchronize configuration across all routers), explicitly state that the first message sent when joining a group should be a State Change, and updates to the compatibility and security sections. This update is expected in January.

There is an opaque field in the IGMPv3 spec to allow hosts to supply authentication information related to joining a group; the question was raised of whether or not people are thinking about how to use that field. The answer was that when someone comes up with a way to use it, the API will be defined at that point.

Brad also talked about IGMP Router Discovery. An extension to IPv6 neighbor discovery was added to allow Multicast Router Discovery to occur in the normal IPv6 Neighbor Discovery process, while in IPv4 it remains separate from IPv4 ICMP Router Discovery. The issue of using ICMP vs. IGMP in IPv4 was brought up, as well as whether to extend IPv4 Router Discovery or create a new protocol with the same state machine.

Ajit Thyagarahan talked about some limitations in the DVMRPv3 spec. These are:


None received.