NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 01-Mar-99
Chair(s):
Tony Ballardie <ABallardie@acm.org>
Bill Fenner <fenner@parc.xerox.com>
Routing Area Director(s):
Rob Coltun <rcoltun@lightera.com>
Routing Area Advisor:
Rob Coltun <rcoltun@lightera.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:
· Protocol Independent Multicast-Sparse Mode (PIM-SM): Motivation and Architecture
· Internet Group Management Protocol MIB
· Protocol Independent Multicast MIB
· A ''traceroute'' facility for IP Multicast.
· Distance Vector Multicast Routing Protocol
· Core Based Tree (CBT) Multicast Border Router Specification
· Border Gateway Multicast Protocol (BGMP): Protocol Specification
· Domain Wide Multicast Group Membership Reports
· Internet Group Management Protocol, Version 3
· PIM Version 2 DR Election Priority Option
· IGMP Multicast Router Discovery
· Core Based Trees (CBT version 3) Multicast Routing -- Protocol Specification --
· DVMRPv1 Applicability Statement for Historic Status
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 |
IDMR met in one session at the Minneapolis IETF. These minutes were collected by Bill Fenner.
Administrivia: Bill Fenner's new email address is <fenner@research.att.com>
Jennifer Hou presented some QoS extensions to CBT. These extensions provide the capability to ensure a certain QoS along a CBT-built tree. The desired QoS can be specified as an upper or lower bound on some parameter (such as delay, loss, available bandwidth) or as a bound on the inter-receiver difference (e.g. inter-receiver delay jitter bound).
When a QoS-aware member joins, the on-tree router performs an eligibility test, based upon information that was collected as the join traveled towards the tree and information that the on-tree router has, and only replies with a Join-Ack if the test succeeds. On-tree routers need only keep state about the maximum (or minimum) value of a parameter within the subtree rooted at that router.
In simulation, the worst case message overhead was twice unmodified CBT.
Bill Fenner talked about rechartering IDMR. IDMR has been an unfocused "catch-all" working group for all multicast-related issues for years. Previous attempts to get the working group interested in fixing the charter have more or less failed, and the current charter has very little applicability to what the working group has been doing. Bill proposed rechartering IDMR to finish work on the existing "catch-all" documents: IGMPv3, Multicast Router Discovery, Domain-Wide Reports, IGMP Proxying, Multicast Traceroute, the Multicast Interoperability draft, and any others that may have been forgotten. New working groups would be chartered for any other work (such as BGMP); minor issues could be handled in the Routing Area meetings or MADDOGS.
Bill proposed renaming the working group to Internet-Draft Multicast Remnants, and set a firm latest acceptable work item due date of April 2000. The only two comments were positive ones. Bill will send a proposed revised charter to the IDMR mailing list.
Following in the same vein, Bill talked about chartering a BGMP working group. Its charter would effectively be to complete the BGMP protocol specification (and related MIBs) and follow them through the standards track. Goals and Milestones include security, interoperability, monitoring and measurement. Developing a transition plan was added to the goals by suggestion. Bill will send a proposed charter to the BGMP mailing list.
Dave Thaler talked about BGP Path attributes for multicast tree construction. These help provide policies on how routes may be used to construct multicast trees; they are independent of the multicast routing protocol but provide information which "policy-clueful" protocols like BGMP could use.
The two proposed attributes are a forwarder preference and a directional policy attribute. The forwarder preference is a non-transitive attribute which allows the election of a designated forwarder per prefix. Electing the designated forwarder at the time of route exchange eliminates the need for a mechanism like PIM's "Assert" process to resolve multiple forwarders. This procedure is already present in BGMP, but if it were in BGP it could be used by other multicast routing protocols. In addition, there is a race condition when using BGMP to elect a forwarder; if the route is learned via BGP, then data arrives before BGMP has noticed the new route and elected a forwarder, then there is not yet a designated forwarder.
The directional policy attribute allows the annotation of a route as "come-from", "go-to", or "both". "both" is the default, and are the only routes that may be used by bidirectional tree protocols. "Go-to" routes may be useful for non-member senders, especially in a UDLR environment. Come-From routes can be of two types. A Come-From route for a source may be used to perform reverse-path forwarding. A Come-From route for a group indicates that that group requires a unidirectional tree. Come-From routes may optionally be annotated with an encapsulation destination for sending to the root of the bidirectional tree (like PIM's Registers).
One use for the directional policy attribute is that an ISP which only supports unidirectional trees may annotate all routes with the Come-From attribute. This allows the tree to be bidirectional in the parts of the network that support it but unidirectional in the parts that don't. It can also potentially create a debugging nightmare. "Lots of rope".
In discussion, it was mentioned that BGP is not necessarily the right place for these options. In fact, BGP was originally considered but discarded for the Forwarder Preference attribute and that attribute was added to BGMP (introducing the synchronization problem mentioned earlier). The desire for a directional attribute raises the same kind of problem. Since these attributes are (or are considered to be) protocol independent, perhaps they belong in BGP.
Agenda
BGP Path Attributes for Multicast Tree Construction
Qos Extension to CBT