Igmp Snooping: A VLAN-Based Multicast Protocol

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 6

IGMP Snooping: A VLAN-Based Multicast Protocol

Jun Wang, LiMin Sun, Xiu Jiang, and ZhiMei Wu


Institute of Software, Chinese Academy of Sciences
P.O. Box 8718, Beijing 100080, China
Tel: +86-10-62645407, E-mail: (wyj,slmjiangxiu,wzm)@isdn.iscas.ac.cn

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

Nowadays, more and more network applications, such as


data distribution, distant education and distributed
database, work on the multicast communication mode.
For the future merge of networks, the computer network
needs the multicast capability to support the traditional
TV Broadcast business. So how to support the multicast
communication in the network is the network
researchers important direction. Over the Intemet, the IP
Multicast has been implemented and used for a long
time. But multicast in the Intranet has not got the same
rapid development.
Ethernet is the most common Intranet and access
network. Previous Ethemet is a network shared by all
hosts. It cant support the group communication. So
Multicast is treated just as Broadcast. Now the Switch
Ethernet with VLAN capability can support the TRUE
multicast. By using VLAN, the Switch Ethernet can
separate the network into several broadcast domains. In
case of a multicast traffic, only those hosts in this
broadcast domain can send and receive the multicast
data. Compared with the IP Multicast, the Multicast over
Switch Ethernet does not need to support the Multicast
Route function. It only needs a Dynamic Group
Management Protocol to manage the relations between
hosts and multicast groups.
Our work is motivated by the need to support multicast
in Switch Network. In this paper, we present a VLANbased multicast protocol, which support the dynamic
group management in the second layer of OSI. The rest
of this document is structured as follows. In Section 2,
we present our main idea and related work. In Section 3,
we present an overview of our protocol, while in Section
4, we offer a more detailed description. In Section 5, we
design an experiment and give .an analysis of
experiments procedures. In the last Section, we
summarize our work.

In case of an IP multicast session, a sender or a receiver


register himself in the local router by sending IGMP
message. The local router will forward the senders
multicast data to the local registered receiver. And for the
remote receivers, a multicast distribution tree must be
built between routers. When multicasting packets, source
sender only sends one copy of this packet. The router in
the multicast distribution tree forwards a copy of this
packet, and cant duplicate another copy to send until it
has a path of branch. In this way, the bandwidth of Bone
Network can be saved to accept more traffic. However,
the multicast on Ethernet cant benefit from the IP
Multicast. When a IP multicast packet reach the Layer 2
switch at the edge of network, the multicast packet will
be broadcast to all of the host in the LAN, so that the
LAN will be blocked by the broadcast flow. The main
reason is that the Layer 2 switch doesnt know which
host joins which multicast group. So a novel protocol
must be implemented to enable the Layer 2 switch to
know the relations between host and multicast group.
Then the Layer 2 switch can map the multicast group to
the set of switch ports. The networks topology is just as
the following figure. Apparently, this multicast protocol
should be deployed in a Layer 2 switches.

0-7803-7600-5/02/$17.00@2002 IEEE

Hat

Hat

Hat

Figure 1 The Topology of Network.


There are several methods to address the problem of
Layer 2 multicast. CGMP, named Cisco Group
Management Protocol, defined by Cisco, is used between

335

routers and Layer 2 switches. Using IGMP, the router


can know about that which host joins which multicast
group, and also know the MAC addresses of these hosts.
In CGMP, the router passes the hosts MAC address and
back to the switch. For the switch can locate the ports
connected with the hosts, it forward the packets with the
specified multicast MAC address only to these ports. In
this way, each host will receive and only receive the
multicast packets it asked for. The basic idea of CGMP is
that router let the switch know which port in which
multicast group. This protocol can be easily
implemented, and the switches dont need to manage the
group information. But the router must understand and
install CGMP. This will bring on the problem of
incompatibilitywith other manufacturersrouter.
Another approach is GMRP, named GARF Multicast
Registration Protocol, which is part of IEEE 802.14. The
idea is for the PC to use a special protocol named GARP
(Generic Attribute Registration Protocol) to notify the
switch about the multicast group it wishes to join. The
switch maintains a table of the couple of registered
address and multicast group. In this way, the multicast
session over Ethernet can be independent of router. It
also can work well together with other upper layers
protocol, such as IPX, AppleTalk. Compared with
CGMP, it supports more multicast session, and the
transmit rate is more fast. But its drawbacks must be
noticed, too. GARP is used for a PC to register
membership in a VLAN. The question is whether your
NIC card dnvers support GARP and whether your PC
viewer applications have a standard way to tell the NIC
card to send the GARP packet. In fact, most of the NIC
drivers and the applications cant do these.
If using CGMP, the router must upgrade a CGMP
module. If using GMRP, the hosts NIC drivers need to
support GARP, and the applications maybe need to be
rewritten to support the way of telling NIC card to send
GARP packet. What we mostly wanted IS to get the
multicast capability in Switch Ethemet, at the same time
the router and hosts configuration are not changed. So
we must find other way to overcome the above problem.
In order to overcome the drawbacks of the above
approaches, a VLAN-based IGMP snooping protocol is
proposed in this paper. As implied by the name, IGMP
snooping allows the switch to listen in on the IGMP
session between hosts and routers. When a switch hears
an IGMP host report from a host for a given multicast
group, the switch adds the port connected to the host to
the VLAN specially allocated for the given multicast
group. And, when the switch hears an IGMP leave
message or a timeout is expired, it removes the port from
the VLAN. So the VLAN is comprised of the ports
connected to the hosts currently need the multicast
group. When the switch receives a multicast packet, it
just only forwards this packet to the corresponding
VLAN.

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.

Figure 2 The Framework of Protocols.


This protocol needs to manage the join and the leave
message of hosts, and to maintain the map of VLAN and
multicast address, and also to be adapted to the maps
changes. So it has the following functions: Snooping the
IGMP messages; Maintaining a form of VLAN and
multicast address; Preserving the coherence of hosts
IGMP state and routers IGMP state; Addressing the
host report flooding problem. The details of these
functions are described as the following:
(1) The capabilities of snooping the IGMP packets and
forwarding the packets with special MAC address in a
VLAN generally are supported by the hardware part of
switch.
(2) From the IGMP join messages and the MAC address
cache table, the switch can get the requested multicast
addresses and the source ports that the join message
comes from. Then it builds a VLAN, which contains and
only contains the ports that request to join a given
multicast group. So a VLAN is mapped and only mapped
a multicast address. Later, the switch analysis each
IGMP packets and timeout events, to add a port to or
delete a port from VLAN, so as to maintain the mapped
relationship between VLAN and multicast address.
(3) In IGMP, router stands at the state of Member
present, if and only if there is a host at the state of
Delaying Member or Idle Member state. This asserts
make certain of the validity of Group Management
Protocol. In order to keep the validity, IGMP Snooping
protocol analysis the information of the IGMP packets,
and then update own state to implement the VLAN-based
multicast. At the same time, the protocol entity of switch
generates and sends the corresponding IGMP packet to
another IGMP entity, so to make sure the correctness of a
communication process in IGMP. In this protocol, two
asserts must be insured: A switchs port stands at the
Member present state, if and only if there is one host
connected to this port at the state of Delaying Member
or Idle Member; Router stands at the Member
present state, if and only if there is a port of the switch
at the state of Member present.

336

(4) The report flooding problem is when a IGMP query


message is sent to hosts of this LAN, all of the hosts will
send a IGMP report message to router, the router just
need one report message will be blocked by the flooding
belonging to the multicast group of report messages. In
IGMP, one approach has been proposed. In that way,
when a host receives an IGMP query, rather than sending
IGMP report immediately, it starts a randomly-chosen
report delay timer for each of its group memberships on
the network interface of the incoming IGMP query.
When a timer expires, an IGMP report is generated for
the corresponding host group. When other hosts receive
this report during expiring their timer, they stops the
timer and dont send any report. This can be done well in
some of Ethemets when all of the hosts share the channel
communicating with the router. But in Switch Ethemet,
hosts connected directly to the switchs ports. A host
cant receive other hosts report messages. So the switch
must filter the report messages. Each report message will
cause the ports state change, but only the first report
message corresponding to an IGMP query process will
be forwarded to the router, the other report messages will
be discarded. This way will strict the report messages
flooding, and at the same time it does not bring on the
influence for the hosts and routers state.

4 Detailed Description of the Protocol


4.1 Basic Data Structure
(1)

IGMP messages Format

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 tables Format

VLAN

Port

T,,

VLAN: The serial number of a switchs VLAN (0-4095),


16 bits.
Port: The number of a switchs port (0-255), 8 bits.
Tport:
The lifetime during which the port is in the VLAN
(Units: seconds), 32 bits.

(3)

The Map Table of VLAN and Multicast Group

I MuIticastAddress I

VLAN

Tpu)uD

Multicast Address: The address of an IP multicast


group, 32 bits.
VLAN: The serial number in the VLAN table, 16 bits.
Tgroup:
The lifetime of the multicast group, 32 bits. -

4.2 Timer and Constant


Query Interval (QI): 125 seconds (the interval between
general queries sent by router)
Query Response Interval (QRI): 10 seconds (max
response time of a host receiving a general query)
Group Membership Interval (GMI): 260 seconds as
default (the max time before a router decides there are no
more members of a group on a network)
Last Member Query Interval (LMQI): 1 seconds (max
response time of a host receiving a group query)
Last Member Query Count (LMQC): 2 (the number of
group query sent by router)
Group Timer (GT): 2 seconds, equal to LMQI*LMQC
Tport:(default: 188 seconds) Used to decide the
membership of one port. The timer starts up when the
switch receive a General Membership Query. At this
time, T,,= min(T,,, R), which R is ten times of the
value of Max RTime field in this General
Membership Query. Each Tponbelongs to a port of a
multicast group. The port would be removed from the
multicast group if the switch didnt receive a
Membership Report from this port before Tm is
expired.
Tgroup:
(default: 260 seconds) Present the lifetime period
of a multicast group. This timer starts up and is updated
when the switch receives a Membership Report. When
the timer is expired, it means that no members on the
network want to receive the multicast packet, so the
multicast group and VLAN will be removed from the
table. Each T,
belongs to a specified multicast group.

4.3 Procedure and Running States


The IGMP Snooping protocol has four processes to
describe the transaction of IGMP messages and Timer
events, The entities of a process are a router, a switch
and n number of hosts. For describing the process more
clearly, we assume each hosts connected to only one port
of the switch. In fact, the instance of multi-hosts
connected to one port can be easily interpreted by the
communication process of only one host connected to.
The hosts, which are connected to a same port, follow
the standard IGMP process.
(I) Initial Process
At the beginning, the IGMP snooping protocol
creates an all-hosts multicast group (224.0.0.1, the

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.

In Figure 3, the General membership query sent


by the Router is forwarded to each host, H1, H2 and
H3, by the Switch. HI, H2 and H3 start up each
timer when receive the query at the time of to. The
timer of HI is expired at tl, and H1 sent a
Membership report to the Switch, and then the
Switch forward it to the Router. When H2 and H3
met timeout at t2 and t3 and sent their reports, the
Switch suppressed the forwarding for these
messages.
(3) Leave Group Process
In the Leave process of IGMPv2, the host that is
going to leave send a Leave Group message to
the router. After the router receives the message, it
sends to all hosts on the network several (counts of
LMQI) Group-Specific Membership Query
messages, which filed of Max RTime is set to
LMQI and amount number is LMQC. At the same
time, a Group Timer is started up, which value
equals to LMQI*LMQC. During the group timer, if
no reports are received by the router, it will delete
the multicast group from its forwarding table, or if
received, the router will continue the normal query
process.
In IGMP Snooping, it is the switch that receives the
Leave Group message. After receives this
message, the switch forwards it to the all-routers
multicast group. Then the router having IGMP will
send the same Group-Specific Membership Query
to the switch. The switch will forward it to the
multicast group which is specified in the messages
field of Group Address. Before forwarding it, the
T, belonging to the port which the Leave Group
is received from, is set to the value of Max
RTime in the query message. The hosts will do the
same as in IGMP.
(4) Timeout Process
T, and Tgroup
minus a defined value every one time
slice. The timeout event is notified when T, or
TmoW
reach to zero. And their values can be updated
when the switches receive a message from host or
router.
The timeout event of TPr; It means that all of the
hosts connected to this port are not in this multicast
group during the time specified by T,,.
So the
switch deletes the port from the corresponding
VLAN when notified by this event. And after this,
the switch even deletes the VLAN and the items
related to this VLAN in the map table if it no longer
contains any of ports. The Tproupof the specified
multicast group will be stopped.
The timeout event of T,,,:
It means that all of the
hosts on the network dont respond to the query
message during the time specified by T,,, and there
is no member in this multicast group. So when
receives the event, the switch deletes VLAN from its
VLAN table, remove the item of this VLAN from
the map table and stop the timer of this T,.

Figure 3 Query and Report Processes

338

4.4 States and States-Change Diagram


The states-change diagram of hosts and routers in IGMP
can be described by the following figure. (The detailed
description can be seen in [6, 111).
The IGMP Snooping protocol of switch has a stateschange diagram for every multicast group. The diagram
use one T,, timer for each ports and one TBoup
timer for
the multicast group. It contains of seven sub processes.
And the events that lead to the states change are the
event of Initial, event of receiving General
Membership Query, event of receiving Group-Specific
Query, event of receiving Membership Report, event
of Leave Group and the timeout event of T,, and
TgfO&Y

Channel

smcr
~

HostA

HostB

HosrC

HostD

I
Figure 5 The Topology of Experimental Network

The Channel Server provides two kinds of programs,


each served by one multicast group. One channel of
program come from the Source A of File Program and
the other one come from the Source B of Satellite
Program. We compiled a network sniffer to check the
packets sent by the network devices. Also the switch can
dump all of the IGMP packets received and sent. So we
can track each data-exchange and states-change
processes of the protocol. The following is a description
and analysis of a typical communication process using
Loc*lcdi
5
IGMP Snooping.
Figure 4 IGMP Snooping State Diagram
When initialized, the switch has only a VLAN of allrouter multicast group in existence. Assumed the router
The following are the details of processes in the diagram.
connected to port 1 of Switch, host A connected to port 2
Action 0: Add all of the ports to the VLAN of
and orderly B to 3, C to 4, D to 5.
224.0.0.1 group; Add the ports connected to routers to
When host A ordered the program from Source A, it sent
the VLAN of 224.0.0.2 group; Set all of T, and Tgroup a Membership Report to the switch. After received this
to infinite value.
message, the switch added the port 2 to the VLAN,
Action 1: Forward the General Membership Query to
which is created for the Source As multicast group. And
the ports of 224.0.0.1 group; Set the from-ports T, to
then it forwarded the message to Router. Router didnt
min(T,,,
R); Clear all groups HAVE-BEENforward Source As data to switch until it received this
REPORTED flag.
report message. Finally, the switch broadcasted the
Action 2: Set the from-ports Tport
to default value; Then
multicast data to the VLAN by the map table. This is a
check the HAVE-BEEN-REPORTED flag; If not set,
typical process of join group, and the delay from host
forward this report message to the ports of 224.0.0.2 A beginning to join to receiving multicast data is less
group and set the to Tmup default value; If set, do
than 200 ms.
nothing.
Subsequently,host B joined Source As program, host C
Action 3: Corresponding to the process when notified by
and D joined Source Bs program. At this time, the
timeout event of Tp,.
VLAN of As multicast group contains of port 1,2 and 3,
Action 4: Corresponding to the process when notified by
the VLAN of Bs have port 1, 4 and 5. The switch
timeout event of Tu,,.
forwarded the General Membership Query sent by
Action 5: Forward the Leave group to the ports of
router to all of host every an interval of QI. This lets the
224.0.0.2 group.
host must respond a report in a period of QI. So by
Action 6: Forward the Group-Specific Query to the
updating the time live of a VLAN when a report message
ports of specific group, and set T, of each port to the
is received, the switch can avoid the VLAN of active
value of the Max RTime field in the query message.
multicast group being deleted.
Notice: forward means that the switch sends the
Host B sent a Leave Group to the switch when it
original message to a set of ports which exclude the port
stopped receiving the program. The switch forwarded
from which the message was received.
this message to Router. Then the router sent Groupspecific Query to the switch and the switch forwarded
5 Experimental Results
this message to all hosts of this group. After the
forwarding, the switch set a timer for each port and
For the object of testing the reliability and validity of the
waited the hosts response. During the timer, the switch
VLAN-based multicast protocol, we designed and
received the response of host A and not received
implemented the protocol in a Layer 2 Ethemet Switch,
anything from host B. So the port 3 was deleted from the
which support one couple of lOOOM interface and 32 of
VLAN of Source As multicast group. The delay from
10/10OM interfaces. An experimental network was
when host B sent leave message to when the port 3 was
constructed to carry out our test process. The topology of
deleted was less than 1S s .
this network is just as the following figure.
Achon

339

[ l l ] William R. Parkhurst, Cisco Multicast Routing


And Switching, 1999

By the above analysis, we consider the fact that our


protocol in the switch can manage the dynamic joining
and leaving of the members, and can implement the
Layer 2 multicast with the IGMP support of hosts and
router.

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

You might also like