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.