[rbridge] FYI: Where IGMP snooping and multicast router discovery are written up
Radia Perlman
Radia.Perlman at sun.com
Thu Apr 6 20:20:40 PDT 2006
There's two documents that Bill Fenner pointed me to, and I will put
pointers into
the protocol draft (rather than duplicating all the mechanisms).
One document explains how to find multicast routers. This is important
because
multicast packets and IGMP reports
must be sent to each every link on which there is a multicast router.
The multicast router discovery is explained in:
http://tools.ietf.org/html/rfc4286
Since this is an RFC, so we don't have to duplicate what's in it, and we can just
point to it.
The other document explains how to recognize IGMP packets of
various sorts.
http://tools.ietf.org/wg/magma/draft-ietf-magma-snoop/draft-ietf-magma-snoop-12.txt
It is unfortunately an internet draft, but hopefully it will become
an RFC. Does anyone know whether it will? If it will, then we can point to it, rather
than duplicating the content. I'll have to read it carefully, but it's possible RBridges
will want to distribute the IGMP messages slightly differently than bridges would,
for instance, by announcing receivers in link state information rather than
learning it from forwarding IGMP announcements. IGMP announcements still need to
be forwarded, but only to links with multicast routers. The magma draft says
to only filter at the last hop, but since RBridges will be informing each other of
the location of multicast routers, IGMP reports can be suppressed upstream, though
this isn't a large optimization.
Anyway, since RBridges can work a little differently from bridges,
we can't just point
to this document. On the other hand, it's real nice not to have to explain the
format of IGMP messages of various versions. If n documents in k different working
groups all try to do that, then if a new version of IGMP occurs, it will be very
difficult to find all affected documents.
I'll read this document carefully and as much as possible point to it rather than
duplicating its content, but others may also want to read it and think about what
differences we might want in the RBridge world.
Unless of course this isn't intended to ever be an RFC, in which case we'll have
to capture all the relevant content...I assume someone will let us know the intention
of the magma draft.
Radia
More information about the rbridge
mailing list