2.5.3 Inter-Domain Multicast Routing (idmr)

NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-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

[These minutes were compiled by Tony Ballardie]

The IDMR working group met during one 2-hour session in Orlando.

Joel Halpern presented the motivation behind Simple Multicast (SM), a relatively new inter-domain multicast proposal. The basic premise was that we should be prepared step back and re-evaluate some of the design decisions made during the days of PIM and CBT development to see if some of the design constraints which we then saw as unsurmountable or invalid can be made acceptable, particularly if the end-result will/might be better.

It is widely acknowledged that bi-directional shared trees scale best overall for Internet-wide multicasting. For single-source type distribution shared trees can be used by placing the core at the source, thus emulating a source tree, both in terms of its delay properties and robustness. Whilst bi-directional shared trees incur the least state overhead for Internet-wide multicasting, they are not necessarily suited to all applications, motivating the requirement to remain flexible in supporting different distribution models.

One of the above-mentioned constraints relates to the host service model (the nature of the host's involvement in joining a group); there was, and remains, fairly strong resistance to change this model - particularly in view of the need to continue supporting different/existing distribution models (tree types). SM need not involve changes to the host service model, but SM would probably involve changing the host API (which is needed by BGMP/MASC too); these changes comprise the host passing a group's core as well as class-D address across the API, both of which are discovered by a means orthogonal to the SM protocol. Both the core and group form an 8-byte group-identifier which must be carried in data packets - the question is how best to do this? Essentially there are two possibilities: use an IP option (this seemed to be the least favoured approach because of it's potential impact on forwarding performance); or carry the information in its own "shim" header immediately behind the IP header. This was the approach that seems more favourable. This method allows for the carrying of additional semantic information - for example, a single bit can indicate whether a packet's TTL is expected reach zero; if it does, it's most likely a looped packet and action can then be taken to remove the loop from the tree.

The proposed transition plan was discussed. The "shim" header on control packets (joins, acks etc.) need and must only be processed by SM-capable routers, giving rise to an auto-tunnelling capability. Data packets, whilst carrying the "shim" header containing <class-D, core>, are IP source addressed by the traffic originating host, and IP destination addressed to the core, though when they hit a SM router whose adjacent next-hop is not SM-capable, the router translates the IP dest address to the next-SM-capable hop. A comment was made that this might not be a good idea because it doesn't allow the remote tunnel end-point to verify where the traffic entered the tunnel, as is possible with encapsulated (IP-in-IP) tunnels. A comment was also made suggesting that making the deployment of tunnels "easy" was not a good idea because the goal of multicast vendors is to get rid of tunnels.

Other comments included:

- non-member senders don't join a tree, and so do not receive on-tree "heartbeats" which filter down from the core, so they have no idea if the core is alive before sending.
- implications of changing the IP multicast API, which requires host changes.
- will debugging/diagnosing problems be harder given that the group-id is now at a higher layer? Most of the current diagnostic tools would probably need some minor mods to accommodate SM.

Graeme Brown (BT Labs, UK) gave a presentation detailing the implementation and testing experience with CBT on the FreeBSD platform. The implementation is publicly available from ftp://ftp.labs.bt.com/Internet-Research/Various test scenarios were illustrated, including fail-over tests, all of which have proven successful. The BT Labs CBT network has been successfully connected to the MBONE (as a stub domain) via their PIM connection to the MBONE. This is achieved by having the CBT core(s) act as a host on its interface to PIM - IGMP group membership report(s) pull the data for the relevant group(s) to the core for distribution on the CBT tree(s).

Some of BT's future CBT work items were outlined - these include continued expansion of the network, inclusion of SNMP, a v6 implementation, and a PIM/DVMRP/CBT Border Router (in a single box).

Mark Handley gave a brief status report on BGMP work in the absence of Rusty Eddy (ISI). He noted that the implementation work is progressing according to plan, but did not give an indication as to when it might be available. Mark solicited input from the community re. inter-domain multicast issues, particularly from ISPs.

Manolo Sola presented Static Multicast. This scheme involves reserving a portion of the Class-D address space (e.g. 225.0.0.0/8) for so-called "static allocation". This scheme involves the use of DNS to map a group name (URL), discovered arbitrarily, to a group address and any other relevant group parameters such as RP/Core(s). For address allocation, the scheme correlates a domain's unicast prefix (e.g. 131.112/16) with the static multicast prefix, so in the above example the domain would be allocated 225.131.112/24. As such it is possible to derive which (unicast) domain is using which multicast prefix.

With regards to interconnecting domain-local trees to an inter-domain tree, the BR/Core/RP in a domain queries DNS to discover other BR/Core/RPs. An explicit join is then sent to the nearest (according to unicast routing) peer BR/Core/RP.

Comments about this scheme included:
- there is a high cost in creating many small teleconference-type groups (impact on DNS, unclear which user and/or computer interactions are involved)
- it's unclear whether inter-domain joins will always converge on a single RP (potential for loops).

Slides

Static Multicast and PIM-SM/CBT-OCBT