wg-multicast - Re: On avoiding the need to require snooping switches
Subject: All things related to multicast
List archive
- From: Bill Nickless <>
- To: Havard Eidnes <>
- Cc: , , ,
- Subject: Re: On avoiding the need to require snooping switches
- Date: Tue, 13 Aug 2002 09:09:25 -0500
At 12:15 AM 8/10/2002 +0200, Havard Eidnes wrote:
I wonder if it wouldn't be an architecturally better idea (and
something which is likely to produce a better longer-term stable
solution) to standardize a protocol which the L3 devices (routers)
could use to speak to the L2 devices to control the distribution of
multicast traffic whithin the L2 network. That way, if one decide to
tweak the L3 protocol, the L3-to-L2 protocol would not necessarily
need to change.
I think you're referring to the IEEE GARP/GMRP protocol. This protocol operates entirely at L2, communicating the desire of devices to receive or not receive frames with certain multicast MAC addresses.
See http://www.ieee802.org/1/mirror/8021/tobagi/garp-gmrp-timers.pdf for a basic introduction to that protocol. The rest of this note is an excerpt from that document. Note that the "multicast group" in this context is the IEEE 802 MAC multicast group, not the IP multicast group.
II. Description of GARP/GMRP
GARP/GMRP is a scheme defined in IEEE802.1p which allows stations to dynamically register/deregister for a multicast group. The design objectives behind GARP/GMRP include simplicity, robustness and scalability, consistently
with the design objectives of transparent bridges; furthermore, its design takes advantage of the broadcast nature of LANs whenever possible, and guarantees the propagation of information about the whereabouts of destinations throughout the entire network along the spanning tree.
The basic goal of the scheme is to determine at any point in time if a port in a bridge is to forward the traffic for a particular multicast group out on that port; this would be the case if some stations reachable by that port are
interested in receiving that traffic; by following this rule for all ports in all bridges, the interested stations would be in a position to receive the appropriate multicast traffic, regardless of where the sources for these multicast groups happen to be. To achieve this goal, the scheme makes use of two control messages; namely:
1.the JOIN message which is sent by a station to express its interest in receiving traffic destined to a group;
2. the LEAVE message which is sent by a station to express its interest in leaving a group.
===
Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7
- Re: IPv6 Multicast - ASM vs. SSM, (continued)
- Re: IPv6 Multicast - ASM vs. SSM, Bill Owens, 08/07/2002
- RE: IPv6 Multicast, Michael Luby, 08/07/2002
- RE: IPv6 Multicast, Greg Shepherd, 08/07/2002
- Re: IPv6 Multicast, Marshall Eubanks, 08/07/2002
- Re: IPv6 Multicast, Guy T Almes, 08/09/2002
- On avoiding the need to require snooping switches, Guy T Almes, 08/09/2002
- Re: On avoiding the need to require snooping switches, Tim Ward, 08/09/2002
- Re: On avoiding the need to require snooping switches, Havard Eidnes, 08/09/2002
- Re: On avoiding the need to require snooping switches, John Kristoff, 08/09/2002
- Re: On avoiding the need to require snooping switches, Guy T Almes, 08/12/2002
- Re: On avoiding the need to require snooping switches, Bill Nickless, 08/13/2002
- Re: IPv6 Multicast, Alan Crosswell, 08/07/2002
- Re: IPv6 Multicast, Kevin C. Almeroth, 08/07/2002
- Re: IPv6 Multicast, Alan Crosswell, 08/07/2002
- Re: IPv6 Multicast, Joel Jaeggli, 08/07/2002
- RE: IPv6 Multicast, Alan Crosswell, 08/07/2002
- RE: IPv6 Multicast, Kevin C. Almeroth, 08/07/2002
- RE: IPv6 Multicast, Michael H. Lambert, 08/07/2002
- Re: IPv6 Multicast, David Meyer, 08/07/2002
- Re: IPv6 Multicast, Marshall Eubanks, 08/07/2002
- Re: IPv6 Multicast, David Meyer, 08/07/2002
- RE: IPv6 Multicast, Michael H. Lambert, 08/07/2002
- RE: IPv6 Multicast, Kevin C. Almeroth, 08/07/2002
Archive powered by MHonArc 2.6.16.