IDMR WG Minutes 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: - Should source filters be added to Domain-Wide Reports? - Should routers be able to send source-specific prunes to hosts, in order to save bandwidth on the local lan (and maybe inform the application) when all receivers have pruned this source? 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.