Professional Documents
Culture Documents
Igmp Snooping: A VLAN-Based Multicast Protocol
Igmp Snooping: A VLAN-Based Multicast Protocol
Igmp Snooping: A VLAN-Based Multicast Protocol
Abstract
This paper introduces a VLAN-based multicast protocol, which supports the multicast communication over switch
Ethernet. This protocol restricts the multicast traffic of an IP multicast group in a VLAN. It starts with a table including
an IP multicast group and the corresponding VLAN. Then it can get the multicast session info to maintain the table by
snooping the IGMP messages sent by hosts or routers. In this paper, we will give the basic idea, syntax and semantics
of this protocol. At the last, an experiment and its results are also provided.
Keywords: IGMP snooping, VLAN, Switch Ethernet, CGMP, GMRP
1 Introduction
2 Research Background
0-7803-7600-5/02/$17.00@2002 IEEE
Hat
Hat
Hat
335
3 Overview
To run IGMP Snooping, the IP Multicast address must
have a map to the MAC multicast address. This is the
basic function of each host and network devices
supporting multicast. Another requirement is the switch
should be Layer 3 aware and have the basic VLAN
capability. Now, most of the Layer 2 switches have these
features.
The framework of protocols using IGMP Snooping can
be described by the following figure.
336
15 16
31
MarRTime I
Checksum
G r o w Address
Type: Ox 11 = Membership Query
0x12 = IGMP Version 1 Membership Report
Ox16 = IGMP Version 2 Membership Report
Ox 17 = Leave Group
Max RTime: Max response time which the host can wait
until it response the Membership Query. Unit is 0.1s and
the default value is QRI (explained later on).
Checksum: A 16-bit the ones complement sum of the
whole IGMP message, including the entire IP payload.
Group Address: 32-bit IP multicast addresses. When the
type field is 0x11 and the group address field is set to
zero, this packet present a General Membership Query
message; when the type field is 0x1 1 and the group
address field is set to a IP multicast address, this packet
present a Group-Specific Membership Query message;
when the type field is Ox16 or 0x17, the group address
field holds the IP multicast group address of the group
begin reported or left.
Notice: In IGMP, some IP multicast address have special
meanings. For example: 224.0.0.1 presents the group
of all of the hosts and routers in the Local sub-network,
224.0.0.2 presents the group of all of routers in the
Local sub-network.
0
78
Type
(2)
VLAN
Port
T,,
(3)
I MuIticastAddress I
VLAN
Tpu)uD
337
specific VLAN contains all ports), and an allrouters multicast group (224.0.0.2, the specific
VLAN contains all ports connected to a router).
And the protocol of switch sets all of T,
and T,
to an infinite value.
(2) Query and Report Process
During the traditional Query and Report process
of IGMP, the router periodical sends General
Membership Query messages. When the host
receives the general query, it starts up a timer,
which value is set randomly from 0 1.0 Max
RTime. The host whose timer is expired will send
a Membership Report message to the router. If a
host received a member report respond for this
query before timer is expired, it will stop the timer
and doesnt send anything. The router will reset its
specified-groups timer when it receives the
member report. If the router receives nothing during
the groups timer, it will stop transmitting the
multicast packets of specified-groupto the network.
In IGMP Snooping protocol, the switch updates all
valid T,, of VLAN table to min(T,,
R), when it
receive the general query sent by a router. Then the
switch will forward this IGMP message to all ports
in the group of all-hosts multicast group. If it
receives a member report from one port of the
group, the switch will only forward the first report
message to the ports of all-routers multicast group,
and the later received report response to the same of
query are discarded. This kind of behavior will be
reset after next query process. And it will not lead
to a wrong decision for the switch to judge if one
multicast group is being in existence while the
router reduces the process time for i.he reports.
Another action when a report is received is the
switch need to reset the specific TPr, and specific
T,,,
to a default value. The communication of
processes in hosts and routers are same as the
processes in original IGMP. The flow of this
process is shown by Figure 3.
338
Channel
smcr
~
HostA
HostB
HosrC
HostD
I
Figure 5 The Topology of Experimental Network
339
6 Conclusion
We propose a VLAN-based multicast protocol, which
supports the Layer 2 multicast. Our protocol gets the
information of multicast group and their members by
snooping the IGMP packets, creates one VLAN for every
multicast group, and dynamic updates the set of VLAN.
The switch broadcast the multicast packet on the
corresponding VLAN, and act as multicasting to the
hosts. When an existed network is added Layer 2
multicast, our protocol only needs to upgrade the switch,
and the host and routers keep no changes. So our
protocol provides a simple and effective scheme for the
multicast applications of Ethemet. In future, several
functions, such as the router discovery, will be developed
and added to the protocol. And the compatibility with
IGMPV3 will be considered.
References
Brad Cain, Steve Deering, Bill Fenner, Isidor
Kouvelas, Ajit Thyagarajan. Intemet Group
Management Protocol, Version 3. Mirror Image
Intemet, Cisco Systems, AT&T Labs-Research and
Ericsson. Internet-Draft, March 2001.
M. Christensen, Vitesse, F. Solensky, Gotham
Networks. IGMP and MLD snooping switches,
Intemet-Draft, June 200 1.
Rolland Vida, Steve Deering, Bill Fenner, Isidor
Kouvelas, Brian Haberman. Multicast Listener
Discovery Version 2 (MLDv2) for IPv6. LIP6,
Cisco Systems, AT&T Labs-Research and Nortel
Networks. Internet-Draft, July 2001.
Bill Fenner, Haixiang He, Brian Haberman, Hal
Sandick. IGMP-based Multicast Forwarding
(IGMP Proxying). AT&T-Research, Nortel
Networks.Intemet-Draft, July, 2001.
S. Biswas, B. Haberman and B. Cain.IGMP
Multicast Router Discovery. Nortel Networks and
Cereva Networks. Intemet-Draft, June 2,001
W.Fenner.
Xerox
PARC.Intemet
Group
Management Protocol, Version 2.RFC 2236,
Novemeber, 1997.
Deering, S . , Host Extensions for IP Multicasting,
STD 5, RFC 11 12, August 1989.
Cisco System. Gigabit Campus Network DesignPrinciples and Architecture. White Paper, 1999.
Peter Wang, Melody Moh. 3Com Coip.&San Jose
State University. Ethemet Growing Up:The
Extensible Broadband Access Infrastructure.
2000.
[ 101 John Roese, Systems Implementation Group
Deploying IP Multicast Switching. 2000.
340