2.5.2 Inter-Domain Multicast Routing (idmr)

NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 17-Aug-98

Chair(s):

Tony Ballardie <ABallardie@acm.org>
Bill Fenner <fenner@parc.xerox.com>

Routing Area Director(s):

Rob Coltun <rcoltun@fore.com>

Routing Area Advisor:

Rob Coltun <rcoltun@fore.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

RFC2201

E

Core Based Trees (CBT) Multicast Routing Architecture

RFC2189

E

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

RFC2236

PS

Internet Group Management Protocol, Version 2

RFC2362

E

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

Current Meeting Report

IDMR met in two sessions at the Chicago IETF. These minutes were compiled by
Bill Fenner.

The first session was a joint meeting with the MBone Deployment WG, in an attempt
to have an interactive discussion about the IP multicast service model. There have been
some proposals put forth to change the IP multicast service model (e.g. EXPRESS
multicast), with the assertion that the current service model does not address the needs
of Internet Service Providers. David Meyer presented an introduction to set a basis for
the conversation, with a taxonomy of multicast sessions: "few to few", "many to many",
"few to many". In discussion, it was brought out that this taxonomy has lots of
underlying assumptions, and that the real scaling factors are "number of multicast trees"
and "membership dynamics of the trees". Without some method of aggregation, state
in backbone routers scales with the number of multicast trees, and state flux in routers
scales with the membership dynamics. The desire is to minimize both state and state flux.

After the presentation, opinions about the future direction of IDMR were solicited from
the audience. The major opinion expressed was that we should keep the current IP
multicast service model and continue on the path of BGMP/MASC. Although we don't
know how to solve all of the scaling problems that we forsee, most of the growth in the
Internet has occurred when coming close to a scaling problem and someone comes up
with a "just-in-time" solution. Another suggestion was to talk to service providers and
find out what their requirements really are, and a request for service providers to look
at BGMP/MASC and see if it solves their problems. In response to a suggestion to throw
everything out and start over, perhaps with IPv6, a service provider stood up and said
that he wasn't willing to throw out the effort that he's spent on deploying the current work.

An action item taken was to write up these ideas so that we have a common language in
which to talk about people's requirements.

Also see the MBone Deployment wg (mboned) minutes for another view of this session.

Second session:

Brad Cain presented joint work with Brian Levine on Using Multicast to Provide an
Anycast Service. Anycast receivers join a special multicast group, and the multicast
routers use a simple distance-vector protocol to determine the nearest member of the
group. Packets sent to a group are sent only to the nearest member, instead of over the
whole tree. This works best with sparse-mode protocols that build the tree based upon
membership as opposed to traffic; how it works with dense-mode protocols is yet to be
determined. If "at least one" semantics are acceptable, current multicast can be used,
and the transition towards using the additional anycast protocol will move the network
closer to providing true anycast as opposed to multicast.

Dave Thaler talked second, on BGMP on Multi-Access LANs. Until recently, BGMP
did not have a mechanism of its own to handle multi-access LANs; it required treating
the LAN as a domain and running a routing protocol inside it (like dense mode PIM).
This would require keeping source-specific state at each router, as well as allowing
duplicate traffic while the PIM Assert process happens, so it was decided that BGMP
needed its own solution for this problem. BGMP now elects a forwarder per route
(where a route may either be for a group-prefix or a source-prefix) at the time that the
route is learned. When a route is learned, routers exchange BGMP messages including
a FWDR_PREF attribute for that route. The router with the best FWDR_PREF is
considered to be the elected forwarder for that route. Since this election occurs at
route exchange time instead of when traffic starts flowing, there is no period of duplicate
or looping traffic as there can be when using the PIM Assert mechanism. In addition,
since the FWDR_PREF can be set individually on each router, this mechanism allows
the expression of routing policy.

Norihiro Ishikawa presented his work on IGMP Authentication in Local Domains. The
desire is to authenticate dialup customers as multicast senders and receivers. Ishikawa's
protocol extends IGMP to include a challenge-response to determine if receivers are
permitted to receive and extends the multicast service model to allow senders to identify
and authenticate themselves as well. There was some confusion as to why a separate
mechanism was needed, since on a dialup server you've probably already authenticated
who is on the other end, so you can use that information to determine authorization to
send or receive. Unfortunately, there was not time in the session to discuss the issue,
so hopefully this discussion will happen on the mailing list.

Finally, Radia Perlman presented her thoughts on how to simplify IP multicast. By
pushing much of the complexity out of the network into the application or even all the
way out to the user, Radia's model makes the network much simpler. The use of
bidirectional trees significantly reduces the "third-party dependency" problem (although
it still exists to some extent). The question of whether or not it's desirable to change
the IP multicast service model in this way remains open and was not addressed during
this session due to time constraints. This presentation was also given in the Routing
Area meeting; see the minutes for that session for the presentation slides.

Slides

Proposal for IP Anycast
BGMP over LANs
Thoughts on Multicast

Attendees List

go to list