1.2836248

Evaluating the Multicast Control Protocol on
a Multicasting Network Architecture
Cite as: AIP Conference Proceedings 963, 943 (2007); https://doi.org/10.1063/1.2836248
Published Online: 08 January 2008
E. Stergiou, G. Meletiou, D. C. Vasiliadis, G. E. Rizos, and S. V. Margariti
AIP Conference Proceedings 963, 943 (2007); https://doi.org/10.1063/1.2836248
© 2007 American Institute of Physics.
963, 943
Evaluating the Multicast Control Protocol on a
Multicasting Network Architecture
E. Stergiou1, G. Meletiou1, D. C. Vasiliadis1,2, G. E. Rizos1,2 and S. V.
Margariti1
1
A.T.E.I of Epirus
GR-471 00 Arta Greece
[email protected], [email protected], [email protected]
2
University of Peloponnese
GR-221 00 Tripolis Greece
[email protected] , [email protected]
Abstract. In this paper a reliable multicasting architecture presented. This architecture operates using a
Multicasting Firewall over the Multicast Control Protocol (MCP). Our aim was to evaluate the transition
times of specific packets such as the IGMPv2 reports in the proposed multicasting network. In our study,
multicasting experiments presented and analyzed. The obtained results of our experiments clearly show that
the average validation times of IGMP reports on the Multicast Control Server smoothly increase versus the
number of clients.
Keywords: Multicasting Network (MN), Multicasting Architecture, Packet Transaction time,
Multicasting Firewall (MF).
PACS: 07.05.Tp, 07.05.Fb
INTRODUCTION
New applications like videoconferences, Internet TV, and multi-player computer games are
considerably affected by the available network resources. Those news applications cannot be efficiently
managed using a typical unicast communication scheme. On the other hand, the scalability of the Internet
services may be enhanced through a multicast communication scheme.
The Multicast Control Protocol is a new protocol developed to give a way for controlling multicast
receivers and senders in individual level by providing remote access control along with centralized
information database [2-3]. Also, this protocol is independent from multicast clients, routing protocols
and multicast applications. Furthermore, participating to the network does not require any changes to
current multicast infrastructure or applications.
In this paper, the results of our experiments in the context of the performance evaluation of Multicast
Control Protocol presented. The benefits, the operation, and the techniques of Multicast Control Protocol
are also introduced.
The remainder of this paper is organized as follows. Section 2 presents the basic operation of
Multicast Control Protocol in a multicasting environment. Section 3 explains the architecture of
multicasting Network that used for our experiments and measurements and is explained the role of the
multicast firewall that used in our experiments. Section 4 gives the results of measurements for the IGMP
packets. Finally, section 5 concludes this paper.
USING MULTICAST PROTOCOL FOR NETWORK MANAGEMENT
The Multicast Control Protocol [2-4] wasATTACHMENT
used in all our experiments, as a basic protocol, providing a
CREDIT
LINE
(BELOW) This
TO BE
INSERTED
FIRST
PAGE OF
EACH and
PAPER
OF ability
multicast
network
management.
protocol
can beON
usedTHE
in one
autonomous
domain,
has the
VOLUME
2,
PART
B
to control multicasting traffic, using the appropriate access-lists; it is also independent of IP multicast
routing protocols [5- 6]. Multicast receivers and sources are efficiently controlled by MCP , providing
thus a centralized multicast control policy tool. Multicast control is based on filtering the IGMP/MLD
CP963, Vol. 2 Part B, Computation in Modern Science and Engineering, Proceedings of the International Conference on
Computational Methods in Science and Engineering 2007, edited by T. E. Simos and G. Maroulis
© 2007 American Institute of Physics 978-0-7354-0478-6/07/$23.00
943
reports, and direct connected multicast sources. It is used between directly connected hosts and MCOP
routers to retrieve the control information from the hosts. The Multicast Control Protocol supports the
following basic phases: discovery, initialization, source receiver validation, and reset phase.
The protocol has the ability to control both the reception and the transmission of multicast traffic
within administrative networks [1]. According to specifications of the protocol, we used it for
communicating two different network elements in a multicasting system. The one of those elements
called Multicast Control Client (MCC) and the other called Multicast Control Server (MCS).
The MCC is designated for controlling multicast traffic in direct connected machines. The MCC has
the ability to filter the IGMP/MLD reports given by invalid hosts. Furthermore, MCC has the ability to
filter the direct connected multicast sources.
The MCS keeps a main database within a controlled multicasting system, which has all needed
information about the multicasting groups; all information data are controlled by the MCC. More
analytically, MCS keeps information about all valid receivers and sources of each multicasting group.
Thus, when a host desires to be a valid receiver, then it has to communicate with MCS machine. If this
connection to MCS doesn’t be available – for any reason- then the MCC is unable to filter IGMP or UDP
packets. Thus, all multicast traffic must be flow within the MCC until the communication with MCS be
established. Finally, MCS is designated to serve many MCCs simultaneously.
ARCHITECTURE OF MULTICASTING NETWORK FOR OUR
EXPERIMENTS
At Figure 1, the proposed novel network architecture presented, which is used for evaluating the
transition times of IGMP packets in a MCOP-based multicast network. Figure 1 depicts that MCOP
Router, MCC, and MCS are protected by a Multicasting Firewall. The Multicasting Firewall makes the
operation more efficient, and reliable. The role of MCOP Router and Multicasting Firewall is analyzed at
the following.
MCOP Router: This device is a basic networking component that filters multicast traffic and
IGMP/MLD reports based on the information it gets. Moreover, it maintains information in local cache
for retrieving directly connected active groups.
Multicasting Firewall (MF): The deployment of Multicasting architecture, usually have to face some
constrains such as the lack of multicast routers, and the inability to protect network from being collapsed
by multicast traffic. The MF acts as a multicast Forwarder and a Bandwidth Manager to regulate the
transmission of multicast data among interconnected sub-networks. The usage of MF is designated to
overcome the above limitations. The Multicast Firewall is defined in [9]. The basic futures of Multicast
Firewall are the following.
First of all, they can perform multicast packet forwarding across existing routers. Moreover, they have
the ability to perform packet replication optimization via multicast group management. They have also
the ability to perform subnet bandwidth management, by assigning priorities to multicast addresses, and
filtering packets in each group according to given criteria. Finally, the multicast group is simplified since
the packet forwarding is performed internally to the firewall. The first two features are common in a
typical multicast capable router, while the third one making the difference between the multicast firewall
and a typical router.
In the proposed Multicasting Experiment Network the MCC connected back to back with the MCOP
router, in order to forward only the validated multicast groups to operate among the VLANs. According
to the specifications of the IGMP packets, there were two possible scenarios of IGMP usage. One
scenario was to use the IGMP without source-filtering capability (i.e. IGMPv2), and the other was to use
the IGMP with source filtering capability (i.e. IGMPv3). Our implementation was based on the first
scenario.
The Internet Group Management Protocol (IGMP) protocol operates between hosts and last-hop
routers (IGMP routers) of a multicast tree to manage host's membership information. For example the
IGMP is used by clients to communicate with the first-hop router, when they desire to join or to leave
from a multicast group [8].
944
VLAN (1)
- Bandwidth Filter and
- Prioritization Filter
(100 hosts)
……………
IGMP Report
Multicasting
Firewall
VLAN (2)
(100 hosts)
……………
MCOP
Router
IGMP Report
MCC
MCS
Init Request
VLAN (3)
IGMP Report
Init
(100 hosts)
……………
Validate
Result
VLAN (4)
IGMP Report
(100 hosts)
……………
Autonomous Network
FIGURE 1 Multicasting Experiment Network
EVALUATION OF PACKET TRANSACTION TIME FOR IGMP PACKETS
Avg remote validation time
(msec)
An experimental four VLANs network was used as a testbed for the experiments. When MCC has
multicast clients in its directly connected networks, MCC must control IGMP packets sent from them. In
our experimental environment 400 different IGMP packets were sent from directly connected clients. All
IGMP packets were intercepted by the MCC, which invoked the remote validation to the MCS.
20
15
10
5
0
0
100
200
300
400
Number of Clients
Average time delay in MCS
MCOP message transaction time
FIGURE 2 Average remote Validation time for IGMP Packets in MCS
The first curve at figure 2 depicts the average remote validation time for each IGMP packet. Figure 2
shows the number of IGMP packets, which is equivalent to the amount of stored Group Member Object
information. It also presents the transaction time for an IGMP packet. The transaction time is defined as
the time an arriving packet at MCC is stayed until it is served by the application. In this time included the
MCOP message transaction time inside MCS and the network delay between MCC and MCS. The roundtrip time between MCC and MCS was around 0.46 milliseconds. Figure 2 shows that, the remote
945
validation time is slightly increasing as the number of the clients increased. The following measurements
were obtained by our extensive experiments:
Number of Clients
0
100
200
300
Average total remote validation time
4.22
6.9
9,5
12.3
(ms)
TABLE 1 Results for remote validation time for IGMP packets
398
15.3
Although the remote validation time is increasing as the number of client increases, the inclination of
the validation time is rather small (table 1). In addition, the remote validation takes place only one time
per a new client for a multicast group. This means that, the MCC is working in a scalable way in the case
of IGMP packet transaction.
At Fig. 2 the second curve which is a steady line, shows the MCOP message transaction time inside
MCS during the remote validation. This time was measured from the time that MCS application received
a Validation message to the time that MCS returned a Result message to MCC. Recall from figure 2, we
notice that the packet transaction time of MCS does not remain constant. Since MCS database contains
only the information of the allowed hosts, the amount of the information inside the database is not
proportional to the number of multicast clients. In addition, since MCS is storing policy information by
aggregating addresses with network mask value, the amount of the information stored in the database is
not proportional to the number of the allowed multicast clients. Therefore, MCS shows a good scalability.
At first in our experiments, a set of approximately 400 IGMP packets was used; then the same 400 IGMP
packets were transmitted from those directly connected multicast clients. The MCC had policy
information for those clients, and the MCC had already set policy in the local repository. Thus, none of
the transmitted packets were remotely validated.
Every IGMP Report comes up to the MCC application layer. From all the arriving packets, only the
first IGMP Report had remotely validated, while all the next packets were validated locally. As far as the
local validation was always the first step of the remote validation process, the local validation time for
packets was always a part of the remote validation time in the same situation. Therefore, the local
validation time can be estimated based on the remote validation times depicted in figure 2. The local
validation time was slightly increased, but it never reached at considerable levels. Furthermore, IGMP
Reports were normally sent with such a long interval (approx. 125 seconds) that it did not cause over
charging to MCC.
CONCLUSIONS
The experiments outlined in our paper evaluated the performance of the MCOP protocol in terms of
packet transaction times over controlling IGMP signalling through the network. An experimental four
VLANs network was used as a testbed for the experiments.
The measurements of our implementation were exemplified on a middle size network (over 400
virtual nodes). We found that, although the remote validation time was increasing as the number of clients
increased, the inclination of the validation time was rather small, providing a scalable property to the
Multicast Control Protocol.
REFERENCES
1.
2.
3.
4.
5.
6.
7.
8.
9.
S. Deering and D. Cheriton. “Multicast routing in datagram inter-networks and extended LANs,” ACM
Transactions on Computer Systems, 8(2):85-110, May 1990.
R. Lehtonen, J. Soini, J. Majalainen, H. Vatiainen, M. Tammi. MCOP operation for first hop routers. IETF
Internetdraft, expired. December 2003.
H. Vatiainen, R. Lehtonen, J. Soini. Multicast Control Protocol (MCOP) over COPS. IETF Internet-draft,
expired. December 2003.
R. Lehtonen, J. Harju. Controlled Multicast Framework. . November 2002.
B. Quinn, K. Almeroth. IP Multicast Applications: Challenges and Solutions. RFC 3170. September 2001.
K. Almeroth The evolution of multicast: From the MBone to inter-domain multicast to Internet2
deployment., IEEE Network. January/February 2000.
J. Moy. Multicast Extensions to OSPF. RFC 1584. , March 1994.
W. Fenner. Internet Group Management Protocol, version 2. RFC 2236., November 1997.
T. C. Wan, C. H. Leong, R. W. Thum, Multicast Firewall for Intranet Multimedia Applications, Proceeding
WEC ’99, Subang, Kuala Lumpur, Malaysia, Jul. 19-22, 1999.
946