2.5.4 Inter-Domain Multicast Routing (idmr)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

Tony Ballardie <ABallardie@acm.org>
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:

Done

  

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

Done

  

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.

Done

  

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.

Internet-Drafts:

Request For Comments:

RFC

Status

Title

 

RFC1949

E

Scalable Multicast Key Distribution

RFC2117

E

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

RFC2201

E

Core Based Trees (CBT) Multicast Routing Architecture

RFC2189

E

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

Current Meeting Report

Minutes of the IDMR Working Group Meeting

IDMR met during one session in Munich. There were four presentations in all: GUM/MASC, Multicast BGP, IGMP Layer 2 Issues, Multicast DHCP Address Allocation.

GUM (presented by Dave Thaler) builds a shared tree of domains, the shared tree comprising bi-directional branches. This proposal is dependent on the allocation of multicast address blocks/prefixes to each domain, which is achieved via a separate protocol, the name of which is currently MASC. Allocating address blocks to domains is thought to improve multicast address utilization and provide potential to aggregate group addresses, if only small numbers of groups. A short presentation of MASC was given (Deborah Estrin), but it is only in the early stages of development, with several issues/mechanisms still to be resolved.

Whilst GUM has the capability to build shortest-path (inter-domain) branches, the motivations for doing so are different than for PIM. The primary reason being to avoid data packet encapsulation when data enters a domain; if the multicast IGP is based on RPF, the inter-domain multicast paths can result in data being injected at a point which would result in the internal RPF check failing. Hence the need to encapsulate and deliver to the "correct RPF" BR.

It was questioned whether a domain could inject data via multiple border routers, and have the multicast IGP ensure no duplicates are distributed internally. The point was made that, if Multicast BGP is assumed to operate between domains, it would provide only one data injection point, and therefore multiple injection points are irrelevant. It turns out that GUM does not necessarily assume multicast BGP, and therefore either method could be adopted.

Tony Ballardie presented a review/update of Multicast BGP. Multicast BGP is about establishing "come from" AS-paths for the purpose of multicast routing, enabling ASs to specify multicast-specific policy that can be independent of unicast policy. One of the goals of this work is to reach consensus about what is needed in BGP for the purpose of multicast, then pass on any proposal(s) to IDR for eventual inclusion in BGP-4.

The presentation made clear the need to distinguish multicast path information from unicast path information in BGP. Where topologies and policy are congruent there should also be the capability to advertise this congruence. This functionality has recently been provided for within the BGP-4 multiprotocol framework proposed by Bates et al. (draft-bates-bgp4-multiprotocol-03.txt).

One possible strategy for evolving the Mbone to support multicast BGP was also presented, whereby tunnel (unicast) paths could be enumerated for assisting in the multicast path decision process. However, several wg members thought that no special case for this should be made, and that such information should not be propagated as part of the path information. Other virtual networks (e.g., the 6bone) also use tunnels, but do not "expand" them.

Shantam Biswas presented a proposal for extending to IGMP, whereby multicast routers use a generic message that is periodically advertised to the all-routers group address. Such a message is potentially useful to LANs comprising layer 2 switches, which are becoming more prominent. Currently, layer 2 switches have to "snoop" on the control messages of each multicast routing protocol, which are sent to the corresponding protocol's reserved locally scoped multicast address.

The point was made that the use of a generic IGMP message, periodically advertised by multicast routers to the all-routers group address, would make the job of a layer 2 switch considerably easier; switches have to forward all multicast data traffic to all multicast routers on the LAN. It was also proposed that such a message could contain "other useful information."

Several wg members were opposed to IGMP being used for this purpose, and no wg members expressed their support for such use of IGMP. However, it was acknowledged this problem exists for switches, and it was suggested that the problem be solved in the context of another protocol, perhaps Router Discovery.

Baiju Patel presented a multicast address allocation scheme based on extensions to DHCP. The proposed scheme is hierarchical, in that address blocks are allocated to domains (ASs) from the top-level servers, then a domain's AS allocates sub-blocks to DHCP servers within the domain. It was suggested that the scheme could be used in conjunction with MASC, presented earlier. A protocol is required under the scheme that is responsible for communicating the allocations between the servers at each level. This is not defined at the current time.

Several wg group members were opposed to this scheme. The point was made that hierarchical address allocation uses up the address space really fast, and evidence exists to prove this. It was also pointed out that DHCP would perhaps be better used for multicast service discovery rather than address allocation, but in general DHCP already seems to be too overloaded with uses. It was also questioned as to how long DHCP would survive.

Finally, the wg was reminded that there are several IDMR documents in their last call. The message I sent out 6th August follows:

Subject: IDMR wg Last Calls
Date: Wed, 06 Aug 1997 16:32:32 -0700
From: Tony Ballardie <ballardie@dial.pipex.com>
To: idmr@cs.ucl.ac.uk
CC: fenner@parc.xerox.com, jhalpern@newbridge.com

This is a wg last call for the following documents:

draft-ietf-idmr-igmp-v2-06.txt (to Proposed Standard)
draft-ietf-idmr-multicast-routmib-05.txt (to Proposed Standard)
draft-ietf-idmr-igmp-mib-05.txt (to Proposed Standard)
draft-ietf-idmr-pim-mib-03.txt (to Experimental)

The MIBs will be subject to review by a designated Net Mgmt Advisory Board person before any final advancement.

Since this last call encompasses four separate documents, this last call expires end of August.

Slides

None Received

Attendees List

go to list

Previous PageNext Page