2.5.4 Inter-Domain Multicast Routing (idmr)

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

Chair(s):

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:

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 Inter-Domain Multicast Routing (IDMR) WG

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

First session

Deborah Estrin gave an overview of BGMP. There are two protocols related to BGMP: MASC, which creates a mapping of Class D address ranges to AS's, and BGP4+, which distributes these mappings into a G-RIB. These protocols have their own working groups (MALLOC and IDR, respectively) so were not discussed at IDMR.

BGMP is a multicast tree construction protocol which constructs bidirectional shared trees of domains. Each group has a root domain (determined by MASC and distributed in the G-RIB); joins flow across domains towards this root domain. Senders which are not also members of the multicast group simply forward traffic towards the root domain using the G-RIB.

If desired (for example, by the MIGP), and the source-specific tree branch does not overlap a shared tree branch, BGMP can build source-specific state. This can be useful for multi-homed domains running MIGPs like DVMRP, PIM-DM and MOSPF which route based solely on source address; if a given source comes in via the "wrong" border router then BGMP has to encapsulate it to the "right" border router; if a source-specific branch is built then the data can be brought in via the "right" border router in the first place. Similarly, if a PIM-SM interior router sends PIM join messages for an individual source, BGMP can trigger generation of a source-specific tree branch.

BGMP generates inter-domain joins in response to knowledge of group membership inside a domain (e.g., via Domain-Wide Reports), and source-specific state (as above) triggers a source-specific join. For PIM-SM and CBT domains, the border towards a given group's root domain (as determined by MASC) is used as the RP or Core for that group.

Brad Cain talked about IGMPv3. IGMPv3 adds source filtering ("only some" or "all but some" sources) to the host membership protocol. Routers merge requests from different hosts so that everyone gets at least what they want (but maybe more). Previous versions of IGMP attempted to reduce the group membership protocol traffic by having hosts suppress group memberships that had already been reported. With source filtering, suppression becomes trickier, so the intent is not to do it, and send reports to the all-routers multicast group. This takes the complex burden of merging multiple requests off the hosts and puts it on the routers. There are three types of report: "current state", "filter mode change" and "source list change". The "current state" report is used in response to the router's periodic queries, and the "filter mode change" and "source list change" (collectively known as "state change records") are used when the host's state changes in response to an application request. Queries are backwards compatible, so that an IGMPv3 router may send a single message and get responses back from IGMPv3, IGMPv2 and IGMPv1 hosts.

IGMPv3 open issues:

Bill Fenner then talked about multicast traceroute. Although the multicast traceroute draft was written from a DVMRP-centric viewpoint, the intent of multicast traceroute is to forward using any state possible, and also to use the state that would be created if traffic were flowing. For example, a PIM-SM router would look for (S,G), (*,G), (*,*,RP) state, and if it had none it would forward the request towards the RP for the group in the request. In order to be able to trace towards a source when there is no state, the group in the mtrace request may be set to 0. In order to be able to trace for a group when there is source-specific state, the source in the mtrace request may be set to 255.255.255.255 . In these cases, the statistics are not expected to be meaningful; these are only useful for topology discovery.

With most routing protocols, a single multicast traceroute can travel hop-by-hop from the traffic destination to the source. However, when using CBT, source-specific traces are not possible (since there's no source-specific state). Therefore, a two step process is required. First, perform a multicast traceroute from the destination to the core. Then, perform a multicast traceroute from the sender to the core. Remove the common hops (if any), reverse the sender's trace, and append it to the destination's trace.

The second traceroute in the example may be difficult to get if the sender is not a member of the group and so is not on the multicast tree. Normally, a third-party multicast traceroute request is multicasted to the group. If the sender is off the tree, its DR will not receive such a request. Therefore, the request may be unicasted to the sender with the Router Alert option set. Each router along the path will look at the packet (because of the Router Alert option) and either forward it or act upon it if it's the appropriate last-hop router.

Bill Fenner then talked about open issues with Domain Wide Reports. Unsolicited reports are necessary, just as in IGMP, for a low join latency (the time between an application joins a group and it gets packets destined for that group). However, if the domain is not performing the Domain-Wide Report protocol, these packets can be extraneous. One possibility is to only send unsolicited reports if the router has previously heard a domain-wide query, indicating that the domain-wide report protocol is in use in the domain. However, if an interior router reboots, it will not know whether or not to send unsolicited reports. The suggested solution is to allow configuration of interior routers if a domain administrator is worried about the extra traffic in the domain, but to default to sending unsolicited reports.

It had previously been suggested that the non-authoritative domain-wide leave simply added complexity without adding functionality, in that in pruning-based protocols, the border routers could simply notice that a group had been pruned all the way to the border and send an authoritative domain-wide leave. However, the non-authoritative domain-wide leave doesn't increase the complexity very much, and relying on pruning increases the latency of the leave which increases the time that (potentially expensive) inter-domain state exists. Therefore, it was decided to include the non-authoritative domain-wide leave message.

A group address mask was suggested. Since nothing uses it now, it was decided that these could be specified using the option extension mechanism.

Tony Ballardie talked about CBT border router behavior. CBT domains use (*, core) state to get packets to border routers to export them from the domain, to inject external data into the domain, and to propagate transit data. (*, core) state is useful to minimize state but doesn't allow you to prune individual groups. It avoids encapsulation when transiting but causes traffic to go everywhere. It's possible to trade off using (*, core) vs. multiple (*, G) entries dynamically. When a domain has a non-member sender, the interior CBT node sends a special type of domain-wide report to make the border routers join to export the traffic.

Propagation of inter-domain control messages: Joins/Prunes get unicasted to the D-BR for S for (S,G) or root(G) for (*,G). If (S,G) join, notify D-BR (for (*,G)) of new "come-from" path for this (S,G) so that the D-BR blocks out (S,G). The ingress BR matches (S,G) prunes with joins and propagates prunes only if all joins were pruned, in which case it cancels (S,G) "come-from" path and revert to the original.

When using CBT as an intra-domain protocol for BGMP, the core for G should be the border router pointing towards root of G.

Michael Speer talked about distributed access control for group membership. There are three normal answers to wanting to control who can participate in a session: use unicast, use encryption (not exportable, doesn't prevent traffic analysis, makes transcoding hard, still lets anyone send), or trust the ISPs to do it for you.

Michael presented a three part plan for access control: use private class D addresses and [temporary] ownership of those addresses, routers verify host's permission to join, and routers prevent rogue senders. This is done by publishing a public key in the DNS, and giving the private key to listeners. Routers can then verify the private key against the published key when joining.

This scheme can perform access control on per-group or per-source basis. It needs an out-of-band mechanism to distribute the private keys to the approved listeners, and doesn't have any way to prevent one approved listener from supplying the key to a non-approved listener. It also requires extensions to the host membership protocol to pass the keys from the hosts to the routers.

Steve Deering noted that trusted routers (e.g., ISP routers) are probably far from the first hop, so this may end up being access control for a domain as opposed to access control for hosts.

Slides

None Received

Attendees List

go to list

Previous PageNext Page