2.5.1 Inter-Domain Multicast Routing (idmr)

NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98


Tony Ballardie <ballardie@dial.pipex.com>
Bill Fenner <fenner@parc.xerox.com>

Routing Area Director(s):

Joel Halpern <jhalpern@newbridge.com>

Routing Area Advisor:

Joel Halpern <jhalpern@newbridge.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:

Existing inter-domain multicast routing protocols are not scalable to a large internetwork containing very large numbers of active wide-area groups. The purpose of the IDMR Working Group, therefore, is to discuss proposed inter-domain multicast routing protocols, and put forward one (or a hybrid of several) as a Proposed Standard to the IESG.

Several proposals have been made to date, including Core-Based Tree (CBT) multicasting, Core-Based Join (CBJ) multicasting, and Scalable Reverse Path Multicasting (SRPM). Some of the above have yet to be reviewed.

Goals and Milestones:



Post the Core Based Trees architecture as an Internet-Draft.



Meet at IETF. All proposals must be submitted by this date. Discuss all proposals which have been submitted.

Dec 93


Submit the Core Based Trees architecture Internet-Draft to the IESG to be published as an Informational RFC.



Meet at IETF. Discuss security issues with respect to the proposed protocol(s).

Aug 94


Post an Internet-Draft for a single protocol (which may be one of the proposals, or a combination of proposals), and an Internet-Draft serving as a protocol analysis document for that protocol (as required by RFC 1264).

Jan 95


Submit the single protocol to the IESG as a Proposed Standard.

Mar 95


Post an Internet-Draft for an IDMR MIB.

Jul 95


Submit the IDMR MIB Internet-Draft to the IESG as a Proposed Standard.


Request For Comments:







Scalable Multicast Key Distribution



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



Core Based Trees (CBT) Multicast Routing Architecture



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



Internet Group Management Protocol, Version 2

Current Meeting Report

Minutes of the Inter-Domain Multicast Routing (idmr) Working Group

Reported by Bill Fenner.

First session:

Brad Cain talked about CBT version 3. There are two major changes from CBTv2. The first is the addition of source-specific state on branches between a border router and the core, to allow CBT to better act as a transit in an inter-domain situation. The second is that in CBTv2, nodes downstream from the core keep track of their upstream neighbors, but not vice versa. In CBTv3, the upstream neighbors keep track of the downstreams as well.

Jeffrey Zhang talked about CBT Border Routers in an inter-domain context. Border routers instantiate (*, Core) state between the border router and each core in the domain. Border routers that forward to downstream domains are thought of as group members within this domain; Domain Wide Reports are used to learn of internal group membership and downstream domain group membership. CBT Quit/Prune messages cause interfaces to go unidirectional; traffic may still be injected via a path that has been pruned. A point was brought up that the use of Domain-Wide Reports to learn of group members in "downstream domains" assumes a tree of domains, and that if not done carefully could cause loops of Domain-Wide Reports even after there are no group members left.

Anindo Banerjea talked about QoSMIC, a new QoS-sensitive multicast routing protocol. In QoSMIC, instead of an RP or Core as in PIM-SM or CBT, there is a "Managing Router". The managing router is in charge of tree construction, but data need not flow through it. This reduces the "core placement" problem to some extent, since poor placement of the managing router should simply affect join and leave latency and not actual data flow. QoSMIC supports both shared and source-specific trees; if you can't get the QoS that you want from the shared tree you may join a source-specific tree and specify your QoS requirements. A tree may be joined in two ways. One way is for the receiver to search for a node already on the tree with a bounded expanding-ring search. The other is for the tree to look for the new receiver by extending pseudo-branches from the tree towards the receiver. Each router which is a candidate for attachment sends a "Bid" message to the new receiver, describing the QoS of the path it could supply. The receiverpicks the best bid that matches its QoS requirements. In simulation over the MBone topology from 1994, QoSMIC built very efficient trees.

Finally, Brad Cain described the IGMP Multicast Router Discovery draft. The is a protocol to help IGMP-snooping bridges discover the presence of multicast routers on a network; it is not in any way an attempt to standardize IGMP snooping. This protocol is very similar to ICMP Router Discovery in that it uses a periodic announcement message along with a solicitation message for quick startup after reboot. The periodic advertisements are sent to the ALL-ROUTERS multicast group, and can contain options including values of the tunable IGMP protocol constants in order to allow IGMP-snooping bridges to set their timers properly. It was suggested that a new group be allocated in order not to bother IP-layer devices which don't care about these messages; that suggestion was taken under advisement. It was also suggested to simply snoop on multicast routing protocol messages (e.g., PIM, CBT, DVMRP, etc.) but it was pointed out that this doesn't help when a new multicast routing protocol is introduced. The question of whether this protocol should use IGMP or ICMP was raised; this topic needs more discussion.

Second session:

Cheng-Yin Lee talked about PIM-SM over ATM using Proxy PAR. Existing solutions for PIM-SM require manual configuration of PIM peers on the ATM LIS. Proxy-PAR allows server-based registration; routers may register themselves and query what other routers have been registered. Future work includes other options for distributing RP-Set messages and Bootstrap messages instead of flooding, and using leaf-initiated ATM point-to-multipointing VCs.

Dave Thaler talked about BGMP. The changes since the last meeting are the removal of the internal peering requirement and the completion of the packet formats. The internal peering requirement was removed because it is redundant when Domain-Wide Reports are available. Since domains are organized in a tree, loops cannot form so Domain-Wide Reports may be used to propagate membership information across a domain. By using Domain-Wide Reports, the join/prune rules are the same as specified in the multicast interoperability document. Internal peerings are still permitted if required by the multicast IGP or if required to implement policy. The packet formats are derived from BGP; the Open, Notify and Keepalive messages are the same; Update messages in BGMP include integrated v4/v6 support and nested type-length-value options. The nested TLV options allow powerful and flexible specification of joins and prunes. BGMP retains BGP's TCP connection collision detection and capability negotiation; path attributes and the "marker" in the header were not retained. The spec is thought to be complete, except for some details of interoperability with source-specific multicast IGP's. An implementation in gated is beginning.

Dave Thaler talked about multicast over multi-path unicast. Questions include how to RPF to multiple interfaces, where to send a join if the upstream neighbor is connected via multiple interfaces, how to forward mtrace, and worries about changes causing duplicates or data loss as well as the normal unicast problems of MTU, reordering, asymmetric bandwidth, etc. These problems are avoided if each "session" (meaning all sources to a specific group or an individual source sending to a specific group) uses a single next-hop; this allows load-balancing among sessions, but not per-packet. The requirements for the algorithm used to choose a link for a "session" are much the same as choosing an RP from a list, so for example you can compute F(S, G, iif) for some F. The question of using multiple links between a single pair of routers was brought up, e.g. to create a larger aggregate link, in which case it could be desirable to use more than a single link for a "session". This is outside the scope of this proposal, but could be done using multi-link PPP or other similar mechanisms.

Continuing the marathon, Dave Thaler talked about multicast over exchanges. Although exchanges are normally shared media, not everyone on the exchange peers with everyone else on the exchange. Dave's solution is to create "mini-domains" over which you can run a routing protocol (perhaps PIM-DM) in these "mini-domains". Dave presented three methods of handling these "mini-domains."

1. Replicated unicast using tunnels or MAC-layer unicast. This is relatively straightforward; instead of multicasting a packet on the exchange, the upstream router replicates it via MAC-layer unicast to its downstream neighbors. This requires extra forwarding state (to list the neighbors), wastes bandwidth, and adds delay because of the requirement that the router generate the replicas.

2. "Logical Clusters" - create clusters consisting of sets of routers which all peer with each other, using MAC-layer multicast groups or IP multicast with IP encapsulation. This is similar to creating VLANs using ethernet multicast. It saves bandwidth, since it can use MAC-layer multicast, and saves forwarding state, since all outgoing neighbors don't have to be individually listed. However, it's hard to coordinate, since the set of routers which all peer with each other can grow or shrink based upon changes in peering arrangements. In addition, it's possible that a router might receive multiple copies of a given packet, since it may be a member of multiple clusters.

3. "Logical P2MP links" - create a single (MAC-layer or encapsulated IP) multicast group per router. All of X's peers join X's group. This has the advantage that you can send only a single packet and receive only a single packet. However, it wastes some bandwidth; if router Y peers with router X and thus is a member of router X's group, router Y has to forward the packets it receives from router X to router Y's group. If router Y's group are all already receiving the data from router X, they all have to prune router Y. This has medium state requirements and is straightforward due to the single packet transmitted and single copy received, but wastes some bandwidth.

Kurt Windisch talked about issues that arose when implementing PIM-DM. One issue is that the Dense-Mode spec relies on the Sparse-Mode spec for some details, including timers. However, the two specifications differ somewhat; the Sparse-Mode spec was updated and the Dense-Mode spec was not. Kurt had to implement compromises to work around these disagreements - for example, for a certain join timer, the DM spec says 3 seconds and the SM spec says 4.5 seconds; the compromise is to send the join after 3 seconds but not prune until 5 seconds pass without receiving a join. A second issue arose with respect to Assert messages; if an Assert occurs, and a downstream router sends a prune to the Assert winner but the prune has a longer lifetime than the Assert, then the Assert loser can start forwarding while the downstream router's prune is still active. It's not clear whether prunes should be allowed to outlive Asserts, or if they should be retransmitted to the new upstream neighbor when an Assert times out, or something else.


None Received

Attendees List

go to list