Using computer networking in multicast .

White Paper
Multicast: Conformance and
Performance Testing
26601 Agoura Road, Calabasas, CA 91302 | Tel: 818.871.1800 | Fax: 818.871.1805 | www.ixiacom.com

Contents
1. Introduction··························································································································· 1
2. What Is Multicast? ···················································································································1
2.1 Multicast Taxonomy ························································································································ 1
2.2 Historical Perspective/Evolution········································································································· 3
3. How Does Multicast Work? ·······································································································4
3.1 Multicast Groups ·····························································································································4
3.2 Multicast Addressing ······················································································································· 5
3.3 Multicast Scope/Time-To-Live (TTL)··································································································· 6
3.4 Multicast Routing···························································································································· 6
3.5 Multicast Distribution Trees··············································································································· 7
3.6 Multicast Distribution Trees··············································································································· 7
3.7 Dynamic Registration ······················································································································ 7
4. Multicast Protocols··················································································································8
4.1 Multicast Group Management Protocols ·······························································································8
4.2 Multicast Routing Protocols ···············································································································9
5. Multicast Testing Challenges ··································································································12
5.1 Why Test for Multicast Conformance?································································································12
5.2 Why Test for Multicast Scalability and Performance? ············································································12
5. Multicast Testing Challenges ··································································································12
5.1 Why Test for Multicast Conformance?································································································12
5.2 Why Test for Multicast Scalability and Performance? ············································································12
6. Test Solution Requirements····································································································13
6.1 Optimized Hardware Platform ··········································································································13
6.2 Routing Protocol Emulation ·············································································································13
6.3 Integrated Control and Data Plane Testing··························································································13
6.4 Traffic Generation··························································································································13
6.5 Automation···································································································································13
7. Ixia’s Approach to Multicast Testing ························································································14
7.1 Multicast Scalability and Performance Testing ·····················································································13
8. Conclusion···························································································································16
9. Appendix: Multicast Testing Example·······················································································17
9.1 PIM-SM Conformance Test ·············································································································17
9.2 IPv4 Multicast Benchmarking Test ····································································································20
9.3 Pv6 Multicast Listener Discovery (MLD) Performance Test·····································································23
9.4 PIM-SM Shortest-Path Tree Switchover Test·······················································································28
10. Glossary of Terms ·················································································································33
11. Bibliography·························································································································34
12. Acknowledgments·················································································································34
Copyright © 2005 by Ixia
All rights reserved
IXIA
26601 West Agoura Road, Calabasas, CA 91302
(877) FOR-IXIA
This Test Plan Primer contains a general outline for testing a particular technology. Not all the capabilities of Ixia
technology have been exposed in this document. Please feel free to contact us if additional capabilities are required.

Multicast: Conformance and Performance Testing Copyright © Ixia, 2005 1
1. Introduction
The sustained expansion of Internet communications continues to generate new services and network applications. At the same
time, the exponential growth in the number of concurrent users who want to simultaneously access shared data in corporate
intranets, as well as the global Internet, has generated the need for applications that provide data access while minimizing
bandwidth requirements. The implementation strategy adopted by many of these emerging applications involves sending packets
from one or more senders to a group of recipients—in a single operation. This technique is referred to as “IP Multicast.”
This paper presents a review of IP multicast, but given the immensity of the field and its continuing evolution, this review is by no
means exhaustive. It also includes an overview of multicast test challenges—and Ixia’s approach to testing multicast technologies
to determine the scalability and performance of a multicast system. Finally, this paper reviews the importance of validating the
conformance of various multicast technologies to the growing number of Internet Engineering Task Force (IETF) Drafts and RFCs
associated with multicast. Multicast testing before, as well as after, deployment of network equipment helps ensure a fully
operational multicast system.
2. What is Multicast?
IP multicast is defined in RFCs 966 and 988 as the transmission of an IP datagram to a “host group”—a set of hosts identified by a
single IP destination address. A multicast datagram is delivered to all members of its destination host group with the same “best-
effort” reliability as regular unicast IP datagrams, i.e., the datagram is not guaranteed to arrive at all members of the destination
group or in the same order relative to other datagrams.
Multicast was developed as an efficient method of data delivery over an IP packet-switched network that allows a server to send a
single data stream to a local multicast-capable router that then redistributes it to other local hosts. In multicast, each packet is sent
from one sender to multiple receivers with a single "transmit" operation.
2.1 Multicast Taxonomy
A multicast application can be characterized as one of three types: One-to-Many, Many-to-Many, or Many-to-One.
One-to-Many applications (see Figure 1) are similar to standard television or radio broadcasts. Examples include: “push media”
content distribution of news, sports, weather, etc.; security monitoring; distribution of stock market prices, manufacturing process
information, schedule announcements, keys, and network times; and file distribution and caching.
Figure 1: One-to-Many multicast transmission from a single host to all intended recipient hosts. The sender dispatches a
multicast packet addressed to the multicast group of receivers. Multicast routes are indicated with the thicker, red arrows.

2 Copyright © Ixia, 2005 Multicast: Conformance and Performance Testing
An important distinction to be noted is that one-to-many Netcasting does NOT imply multicast. There are various applications that
implement unicast Netcasting to provide one-to-many “broadcast-like” services. The one-to-many Netcasting applications distribute
information using separate unicast IP streams for each user, providing broadcast-like services such as Real Audio and Real Video,
as well as several servers for MP3 file distribution.
Many-to-Many applications (see Figure 2) include interactive distance learning, interactive multi-player games, jam sessions,
multimedia teleconferencing (voice/video phones and whiteboards), chat groups, shared editing and collaboration tools, parallel
computing, as well as distributed interactive simulations.
Figure 2: Many-to-Many multicast transmission from two senders to all intended recipient hosts. The senders dispatch
multicast packets addressed to the multicast group of receivers. Multicast routes are indicated with the thicker, red arrows.
Many-to-One applications (see figure 3) usually require a request and response mechanism. Examples include polling and data
collection, resource and service location discovery (Anycast), on-line auctions, as well as various jukebox and real-time multimedia
playing applications.
Figure 3: Many-to-one multicast transmission from two senders to a single receiver. The senders dispatch multicast packets
addressed to the multicast group of receivers. In the illustrated example above, the group consists of a single host. Multicast routes
are indicated with the thicker, red arrows.

2.2 Historical Perspective/Evolution
Early efforts in the 1980s to define a multicast-capable Internet resulted in a RFC 966, “Host Groups: A Multicast Extension to the
Internet Protocol” (1985). IP multicast concepts evolved through additional RFCs (988 and 1054), resulting in the multicast standard,
in RFC 1112, “Host Extensions for IP Multicasting” (1989).
Additional work in the early 90s led to the creation of Virtual Internet Backbone for Multicast IP or MBone, which was an
experimental test bed system for multicast application and protocol development. Mbone was first deployed in 1992 as a virtual
network, with application-layer packet replication: one packet in, one or more packets out. From Mbone’s flat, virtual set of networks
in 1992, all under the same Autonomous System (AS) or domain, multicast routing has evolved from an intra-domain routing
emphasis to a broader scope of inter-domain routing in the late 1990’s, supporting a hierarchical set of domains. [1]
The earliest multicast routing protocol, Distance Vector Multicast Routing Protocol (DVMRP), was defined in RFC 1075. DVMRP is a
distance-vector-routing protocol, similar to the RIP unicast routing protocol, but with DVMRP used exclusively for multicast. This type
of multicast routing is termed “Dense Mode.” It operates by flooding multicast packets in all directions, based on the assumption that
the network is densely populated with multicast receivers that want to receive these packets. In practice, however, many networks
are not densely populated, and for this reason other multicast methods are preferred. Additionally, Dense Mode multicasting is
subject to significant scaling problems.
Alternatively, “Sparse Mode” protocols, such as Protocol Independent Multicast – Sparse Mode (PIM-SM), are more efficient for
transmitting to multicast groups whose members are thinly distributed. PIM-SM receivers must explicitly request membership in
the multicast group. Due to its scalability, PIM-SM is currently the most commonly used multicast routing protocol.
Figure 4 shows the differences in the data transmission between Dense Mode and Sparse Mode multicast protocols.
Figure 4: Differences between Dense Mode and Sparse Mode multicast packet transmission. For Sparse Mode,
multicast packets will be sent only to Receivers that have indicated interest.

3. How Does Multicast Work?
Multicast routing delivers a single stream of transmitted data packets to a multicast group IP address. However, in contrast with a
broadcast operation, it only attempts to distribute the packet stream to the set of hosts that are part of the recipient group—not to all
hosts. Multicast differs from unicast technologies because it delivers a single stream of information to a potentially large group, with
only one copy of the packet stream traveling over any individual link. This can result in significant traffic reduction, maximizing the
use of network bandwidth. Another important difference between multicast and unicast is that while unicast applications can use
TCP or UDP at the transport layer, the only available transport protocol for multicast applications is UDP. For this reason, the
application layer must provide the reliability data transfer mechanisms, such as sequence numbers, timers, and retransmissions,
for multicast operations.
IP multicast involves both hosts and routers, with a multicast topology consisting of sources and groups of receivers. Usually, the
source and destination receiver are hosts, while routers distribute multicast traffic across the network or set of networks that
connects them. The multicast router must find multicast sources on the network, send out copies of packets on several interfaces,
prevent routing loops, connect interested destinations with the proper source, and keep the flow of unwanted packets to a minimum.
A multicast source transmits its data to a specific group of receivers, represented by a multicast group of IP addresses. To receive
that data, receivers join the relevant group by explicit request. The source initially sends multicast data to the receiving group in a
single stream of datagrams/packets. If a datagram reaches a point (router) on the network where some multicast receivers cannot
be reached by continuing to use a single, common path, the router duplicates the datagram, and then streams it out over the fewest
paths possible to the next hop routers in the network.
Figure 5 shows an example of a group of four multicast receivers that are interested in receiving data, voice, and video information
from the source. These hosts that form the receiver multicast group indicate their interest in the source’s information by sending a
message to the routers in the network. In order to deliver the data from the source to the receivers, the routers dynamically generate
a multicast distribution tree.
Figure 5: Multicast source, routers, and receiver group, showing the network segments that form the multicast path
between them as black arrows.
3.1. Multicast Groups
Multicast receivers are required to contact their local multicast router and to “join,” or request a connection to, a multicast group (or
“channel” for Source-Specific Multicast /SSM). Group membership is dynamic, where hosts may join and leave groups at any time.
A host need not be a member of a group to send datagrams to it, and a host can be a member of more than one group at a time.
When a group has no members and no sources, the states associated with the group will cease to exist on the router after a pre-
specified timeout. There are no restrictions on location or number of member hosts per group, but membership in a group may be
restricted to only those hosts possessing a private access key.

3.2. Multicast Addressing
The IETF has divided the IPv4 address space into four classes. Classes A, B, and C are used for unicast traffic. Class D
addresses are reserved for multicast traffic, and are allocated dynamically.
Figure 6: Multicast Addressing Classification
The Class D range of IP multicast addresses starts with “1110” for the high-end bits, and leaves 28 bits to identify the destination
multicast group.
Multicast addresses designate either permanent or transient multicast groups. A permanent multicast group is associated with an
IP multicast address that is registered with the Internet Assigned Numbers Authority (IANA).
Permanent special multicast groups are the all hosts group with address 224.0.0.1, which designates all hosts and all routers on a
network, and the all routers group with address 224.0.0.2, which designates all routers on a network. Several protocols reserve
permanent multicast groups. For example, the IP address 224.0.0.9 is used by RIP2 protocol to designate all RIP2 routers on a
network, and 224.0.0.4 is the group of all routers that use the DVMRP multicast routing protocol.
Addresses with the prefix 233.0.0.0/8 (GLOP addresses per RFC 3180) are reserved for owners of autonomous systems and are
used as follows. The AS number of an autonomous system is converted to a 16-bit number, and these 16 bits are assigned to the
second and third bytes of the IP address. Then each autonomous system can use the fourth byte to designate a set of 256 reserved
multicast addresses. For example, if the AS number of an autonomous system is 0x8080, the autonomous system effectively owns
the multicast addresses in the range from 233.128.128.0 to 233.128.128.255.
All addresses that do not designate permanent multicast groups designate transient groups. Addresses for these groups are
assigned dynamically. An application implicitly allocates a multicast address by starting to transmit to a transient group. The
address is released implicitly when there is no sender and no receiver for this group. If two applications use the same multicast
address, IP multicast treats the applications as a single multicast group, and packets sent by any of the applications are delivered
to both applications.

3.3. Multicast Scope/Time-To-Live (TTL)
The Time-To-Live (TTL) field in IP multicast datagrams limits the scope of the IP datagram. The TTL, denoting the allowed number
of hops between routers, can be a value from 0 to 255. The default value is 0, which means that all multicast packets are forwarded
out the interface. By setting a TTL threshold for a given interface, only multicast packets with a TTL value greater than the threshold
are forwarded out the interface.
Setting the TTL to different values allows different applications to use the same IP multicast group address without interfering with
each other. In this way, problems occur only if there is overlap between the scope of the IP datagrams transmitted by different
applications that use the same multicast group. Packets with addresses in the range 224.0.0.0- 224.0.0.255 are sent with the
TTL field set to one, and, therefore, the scope of the corresponding groups is limited to the local network.
TTL Value Description
0 Restrict to the same host. No output by any interface.
1 Restricted to the same subnet. Not forwarded by a router.
15 Restricted to the same site, organization, or department.
63 Restricted to the same region.
127 Worldwide.
191 Worldwide; Limited Bandwidth.
255 Unrestricted in scope; Global.
Table 1: Multicast Time-To-Live (TTL) values and descriptions
3.4. Multicast Routing
Multicast routing protocols make possible the exchange of messages between routers, the assembly of distribution trees, and the
forwarding of multicast packets. Multicast routing is different from standard IP routing in several aspects. First, the network focuses
on routing traffic from the source host or hosts to the receiver group of hosts. Second, while all receiver hosts share the same
multicast group IP address, they can be arbitrarily scattered throughout the network. Third, the receivers can join and leave
multicast groups arbitrarily, as well.
Figure 7: Comparison of Multiple Unicast transmissions and Multicast transmissions.

With multicast routing, a router or switch sends packets to a specific group of hosts without using broadcasts or multiple unicast
transmissions (see Figure 7), and without routing loops or excess transmissions. Multicast destinations can include hosts that reside
on a local LAN, hosts that reside on different sites within a private network, or hosts that are scattered throughout the Internet.
Networks must be able to build distribution trees that connect sources to all receivers. A primary goal of these packet distribution
trees is to ensure that each packet appears exists only one time on any given network link (that is, if there are multiple receivers on
a given branch, there should only be one copy of the packets on that branch). The goal of multicast routing is to find a tree of links
that connects all of the routers that have attached hosts belonging to the multicast group. Multicast packets will then be routed along
this tree from the sender to all of the hosts belonging to the multicast tree. Of course, the tree may contain routers that do not have
attached hosts belonging to the multicast group.
3.5. Multicast Distribution Trees
There are two distinct methods used for creating the multicast distribution tree (MDT): the group-shared tree approach, and the
source-based tree approach. In the group-shared tree approach, a single routing tree is constructed for the entire multicast group
and is used to distribute the traffic from all senders in the group. The links that are not connected to those host members of the
multicast group are not included in the tree. Note that the links are bi-directional, since packets can flow in either direction on a link.
In a source-based tree approach, an individual, source-specific routing tree is constructed for each sender in the multicast group. In
a multicast group with N hosts, N different routing trees will be constructed for that single multicast group. Packets will be routed to
multicast group members in a source-specific manner, depending on which was the initiating source host. Note that not only are
there different links than in the group-shared tree case, but that some links may also be used only in a single direction.
3.6. Dynamic Registration
Identification and registration of the receivers is the initial step in multicast operations. In IPv4 networks, this is achieved between
multicast-group member hosts and the corresponding local router via the Internet Group Management Protocol (IGMP). In IPv6
networks, receivers use Multicast Listener Discovery (MLD) to inform the network of their multicast group membership. These
protocols are described below.

4. Multicast Protocols
There are a number of different routing protocols for intra-domain multicast routing, a number of protocols for inter-domain multicast
routing, and some that are well suited to serve both intra- and inter-domain multicast routing implementations.
The following sections describe several of the most widely used multicast routing protocols, including Protocol-Independent
Multicast (PIM), Distance Vector Multicast Routing Protocol (DVMRP), and Multicast Open Shortest Path First Protocol (MOSPF).
The task of these multicast routing protocols is to create efficient multicast delivery paths through the network, with each protocol
using different algorithms to achieve this efficiency. Also discussed below are the multicast group membership discovery (group
management) protocols, IGMP and MLD.
4.1. Multicast Group Management Protocols
The multicast group management protocols are IGMP and MLD and are described in detail in the following sections.
4.1.1. Internet Group Management Protocol (IGMP)
The Internet Group Management Protocol (IGMP) is used by IPv4 systems to report their IP multicast group memberships to
neighboring multicast routers. Hosts use IGMP to register their dynamic multicast group membership, and the connected routers
use IGMP to discover these group members. Hosts join groups by sending Join messages to the multicast routers on their LAN.
These routers listen for IGMP messages and periodically send queries to find out which groups are active on particular subnets.
IGMP is essentially an asymmetric protocol, specified from the point of view of a host.
IGMP Version 1 is specified in RFC 1112 (August 1989), and Version 2 is specified in RFC 2236 (August 1997). IGMP Version 3,
specified in RFC 3376 (August 2002), is interoperable with Versions 1 and 2.
Version 3 adds support for "source filtering," which enables a system to report interest in receiving packets only from specific source
addresses, as required to support Source-Specific Multicast (SSM), or from all but specific source addresses, sent to a particular
multicast address. SSM is defined in draft-ietf-ssm-arch-xx, and uses a restricted set of multicast addresses.
4.1.2. Multicast Listener Discovery (MLD)
The purpose of the Multicast Listener Discovery (MLD) protocol is to enable an IPv6 router to discover the presence of multicast
listeners (receivers) on links directly attached to it, and to determine specifically which multicast addresses are of interest to which
attached nodes. This protocol was originally defined by RFC 2710. Its first version, MLDv1, supports “join” and “leave” functions
similar to IGMP.
MLD Version 2, defined by RFC 3810 and designed to be interoperable with MLDv1, adds the ability for a node to report
interest in listening to packets with a particular multicast group address—but only those packets from specific source addresses,
or from all sources except for specific source addresses. The added support for "source filtering" in MLDv2 thus supports Source-
Specific Multicast (RFC3569) from specific source addresses, or from all BUT specific source addresses, sent to a particular
multicast address.

4.2. Multicast Routing Protocols
This section describes several Multicast Routing Protocols, including PIM-SM, SSM, MBGP, MSDP, and DVMRP.
4.2.1. Protocol Independent Multicast-Sparse Mode (PIM-SM)
Protocol Independent Multicast – Sparse Mode (PIM-SM) Version 2 is defined in RFC 2362 (and updated by other existing
IETF drafts, designed to obsolete the current RFC 2362).
Dense mode protocols present significant scaling problems since flooding packets in all directions (and periodically re-flooding to
reach new receivers) is inherently inefficient, especially when there are only a few receivers. To address this shortcoming, sparse
mode protocols such as Protocol-Independent Multicast – Sparse Mode (PIM-SM) were developed. Sparse mode protocols make
the more realistic assumption that the network will be sparsely populated with multicast receivers. Instead of flooding the
transmission in all directions, a multicast router sends the transmission only to a specific Rendezvous Point (RP), which plays the
role of a proxy for both receivers and senders and is available to all members of a multicast group for that transmission. Receivers
must explicitly request membership in the multicast group. This is sometimes called an explicit join distribution method. Because
sparse mode protocols generally provide more efficient use of the available bandwidth, they are the basis for most current multicast
development and implementations.
PIM-SM maintains the traditional IP multicast service model of receiver-initiated membership and uses explicit joins that propagate
hop-by-hop from directly connected member routers along the distribution tree. PIM-SM is not dependent on a specific unicast
routing protocol.
With the PIM-SM protocol, there is one Rendezvous Point (RP) router per multicast domain, which serves as the root of a
unidirectional shared distribution tree whose leaves are multicast receivers. The term “upstream” is used to indicate the direction
toward the root of the tree; “downstream” indicates the direction away from the root of the tree. The address of the RP can be
configured statically by an administrator, or configured via a Bootstrap router (BSR) mechanism. In addition, if the flow of data
packets from the source(s) to the multicast group is great enough, PIM-SM can create an optional shortest-path tree for an
individual source (where the source is the root).
The robustness, flexibility, and scaling properties of this architecture make it well suited to large heterogeneous inter-networks.
Figure 8: PIM-SM Example Diagram

4.2.2. Source-Specific Multicast (SSM)
The Source-specific multicast (SSM) protocol identifies multicast traffic by both source and group address. SSM is an extension
that allows datagram traffic to be forwarded to receivers from only those multicast sources for which the receivers have explicitly
expressed interest. Thus, SSM requires support in receiver hosts and applications to signal source specific membership. Based on
IETF guidelines, successful deployment of SSM requires IGMP and an end-to-end multicast-enabled network, with applications that
use an IGMPv3 stack.
RFC 3569 provides an overview of SSM, and the more recent IETF draft-ietf-ssm-arch-06.txt defines an extension to the Internet
network service that applies to datagrams sent to SSM addresses, and defines the host and router requirements to support the
extension.
An IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by
subscribing to “channel” (S,G). SSM provides host applications with a channel abstraction, in which each channel has exactly
one source and any number of receivers.
4.2.3. Multiprotocol BGP (MBGP)
Defined in RFC 2283, Multiprotocol BGP (MP-BGP or MBGP) is an extension to BGP-4 that enhances BGP, allowing it to carry
IP multicast routes. MBGP enables multicast routing policy throughout the Internet and can be used to connect multicast topologies
within and between BGP autonomous systems. (The acronym MBGP is often read as “Multicast BGP,” but the correct name is
“Multiprotocol BGP”.)
Although BGP is a unicast, exterior gateway protocol, its multicast counterpart recognizes that a multicast network need not be
congruent with that of the unicast network due to differences caused by topology and/or policy constraints. MBGP is a simple way
to distribute two sets of routes simultaneously—one set for unicast routing and one set for multicast routing. The routes associated
with multicast routing are used by the multicast routing protocols to build data distribution trees.
With MBGP, both unicast and multicast routes are carried in the same session but in different routing tables. MBGP carries multicast
routes by adding the Subsequent Address Family Identifier (SAFI) to either of two new path attributes, the Multiprotocol Reachable
Network Layer Reachability Information (NLRI) and the Multiprotocol Unreachable NLRI. The SAFI specifies whether the forwarding
information is unicast, multicast, or unicast/multicast. Because MBGP is an enhanced version of BGP-4, all of the familiar BGP
policy and configuration tools are also available for multicast.
The main advantages of MBGP are that an Internet can support non-congruent unicast and multicast topologies, and when the
unicast and multicast topologies are congruent, they can support differing policies. Also, MBGP provides greater control over
multicast paths, and it is valuable when having multi-homed scenarios with multiple multicast feeds. Another important advantage is
that with MBGP, a router needs to know only its own internal topology and the path to each of the other ASs rather than the entire
flat multicast topology, and that MBGP is backward compatible with BGP-4 (routers that do not understand the extended attributes
simply ignore them.)
The two main drawbacks to MBGP are the increased routing table size and the potential storage of redundant information, which
can result in routers storing multiple sets of routes for the same prefixes.
4.2.4. Multicast Source Discovery Protocol (MSDP)
Multicast Source Discovery Protocol (MSDP) is a mechanism used to communicate between routers passing information about
multicast sources. Its two forms Comes - internal MSDP and external MSDP- are identical. External MSDP is spoken across the
boundaries between PIM clouds, internal MSDP is spoken between RPs within a PIM cloud.
Multicast Source Discovery Protocol (MSDP) is a mechanism used to connect multiple routing domains, generally PIM-SM domains.
MSDP allows sources for a multicast group to be known to all of the rendezvous points (RPs) in different domains. Each MSDP
router establishes adjacencies with internal and external MSDP peers, informing each other about active sources within the domain.
When they detect active sources, the routers can send PIM sparse-mode explicit Join messages to the active source. When an RP
in a PIM-SM domain learns of a new sender, for example, through PIM register messages, it constructs a "Source-Active" (SA)
message and forwards it to all its MSDP peers. To discover multicast sources in other domains, RPs run MSDP over TCP and
exchange source list messages to set paths to sources of interest, in other domains. Multicast data is delivered to receivers in those
domains of interest, over the normal, source-tree building mechanism in PIM-SM.

4.2.5. Distance Vector Multicast Routing Protocol (DVMRP)
The Distance Vector Multicast Routing Protocol (DVMRP) establishes multicast delivery paths over a series of routing devices.
DVMRP is a distance-vector-routing protocol, based on the Bellman-Ford algorithm, implementing the Truncated Reverse Path
Broadcasting algorithm.
DVMRP establishes the appropriate paths (i.e., a distribution tree) between a multicast source and a receiver through a method
called Reverse Path Forwarding (RPF). When a multicast router receives a packet, it sends the packet out in all paths except the
one that leads back to the packet’s source through a mechanism called “flooding the packet.” This method allows the data stream
to reach all downstream LANs, possibly more than once. If a router is attached to a set of LANs with no receiving members for a
particular Multicast transmission, the router sends a message back up the distribution tree to stop subsequent packets, thus
“pruning” the branch of the tree beyond that router.
Multicast routers exchange distance vector updates that contain lists of destinations and the distance in router hops to each
destination. They maintain this information in a routing table.
DVMRP uses the Internet Group Management Protocol (IGMP) to exchange routing datagrams. It is an Interior Gateway Protocol
(IGP) suitable for use within a single autonomous system, but not between different autonomous systems. Similar to the Routing
Information Protocol (RIP), DVMRP exclusively routes only multicast datagrams. One crucial difference between DVMRP and RIP
is that while RIP operates in terms of routing and forwarding datagrams to a particular destination, the purpose of DVMRP is to keep
track of the return paths to the source of multicast datagrams.

5. Multicast Testing Challenges
Multicast test tools must be able to perform a wide variety of functions to test and validate devices and systems adequately.
For conformance testing, the test solution must be able to fully exercise the control plane of the device or system under test.
Because the ability to receive multicast does not guarantee the ability to source this type of traffic for performance and scalability
testing, the test solution must be able to emulate multicast routers at the control plane level and scale up for large capacity testing,
checking both traffic being sent and traffic being received by the system under test. In addition, this solution must be able to drive
traffic through the system at the data plane level to fully stress the device being tested.
5.1. Why Test for Multicast Conformance?
Multicast standards and implementations are dynamic. There are typically multiple IETF drafts associated with multicast, in addition
to scores of RFCs. In this constantly changing environment, maintaining compliance with standards is a significant challenge—and
a crucial one, since compliance is essential to the ongoing interoperability of network equipment from various vendors. Equipment
vendors find themselves at the leading edge of these challenges as they repeatedly update their feature sets to conform to the latest
standards and options, while at the same time improving performance and scalability. They must do this both to remain competitive
in their markets and to meet the demands of their customers.
Development test and quality assurance groups, therefore, need an efficient way to verify the suitability of their implementations.
Formalized conformance testing against standards supplies this confidence. Beyond ensuring product interoperability and quality,
conformance testing can also accelerate product development by detecting bugs or correcting design issues early in the
development cycle, thereby reducing the product’s time to market and hence increasing profitability.
Multi-vendor environments are the reality today for both service providers and enterprise organizations. Such a reality is untenable
without the assurance of equipment interoperability that is driven by standards-based implementations. Networks are also dynamic;
so when upgrades are required, conformance and regression testing are crucial to ensure that new software releases do not break
existing services.
To achieve adequate test coverage for compliance to a standard, hundreds of conformance test cases are typically necessary to
cover a given protocol, and these tests must be appropriately updated as necessary. To address these challenges, most vendors
and service providers rely on conformance testing products that are maintained and supported by a dedicated third party.
5.2. Why Test for Multicast Scalability and Performance?
Standards compliance and interoperability are prerequisites to a working multicast system, but the ultimate success of an
implementation depends on its performance in a real network. Given the complexity of the protocols involved, scalability and
performance are often genuine concerns. Equipment vendors typically test and publish the scalability and performance capabilities
of their products to facilitate compliance assessment. End users will often validate the numbers while additionally testing specific
network scenarios unique to their own deployment.
Scalability is typically viewed as the biggest challenge in service provider networks today. Providers must understand the dynamics
of growth in their networks as new customers are added, as well as the ultimate performance limits of their networks.
Determination of routing capacity, verification of branch creation and proper traffic routing, measurement of the latency or the time
it takes for multicast receivers to join a group, and how that time is affected by the group’s size, are some of the metrics used to
determine scalability and performance in a multicast system.
Together, scalability and performance metrics can be competitive differentiators for equipment vendors. For service providers and
network managers, they are key selection criteria between vendors. Characterizing these elements is critical, since they directly
impact the service quality that can be delivered to the end customer.

6. Test Solution Requirements
Multicast test tools must be able to perform a wide variety of functions to adequately test and validate multicast devices and
systems. For conformance testing, the test solution must be able to fully exercise the control plane of the device or system under
test. For performance and scalability testing, the test solution must be able to emulate a wide variety of topologies and hierarchies
at the control plane level and scale up for large capacity testing. The solution must also be able to drive wire-speed traffic through
the system at the data plane level to fully stress the device under test.
6.1. Optimized Hardware Platform
While simple router emulations can be run on PCs or workstations, an optimized test system must be employed to provide complete
testing capabilities and high levels of scalability. For example, to emulate a large network, a network interface on a test tool must
support hundreds or even thousands of IP interfaces and MAC addresses—requirements that standard off-the-shelf hardware
cannot support. Purpose-built test hardware is required to provide the flexibility and scalability needed to adequately test multicast
equipment.
6.2. Routing Protocol Emulation
The test solution must be able to emulate the full range of routing protocols used in today’s networks, including OSPF, IS-IS, RIP,
BGP, and BGP+. These routing protocols are used to advertise the underlying network topologies over which the multicast system is
established. In addition, the multicast testing solution supports the emulation of essential multicast protocols, such as IGMP, MLD,
PIM-SM and PIM-SMv6, SSM, and MBGP.
Testing equipment must be able to fully stress the dual-stack data planes of dual stack routers, generating and analyzing multicast
IPv4 and IPv6 packets at wire-speed.
6.3 Integrated Control and Data Plane Testing
Another significant requirement for the test tool is the ability to integrate control and data plane testing. This capability requires test
tools to emulate large and complex topologies and networks, and then target data traffic over the advertised topology with an
integrated traffic generator. The test tool must be able to run signaling protocols simultaneously with the routing protocols on the
same network interface. The traffic is used to determine device and network performance, and to verify the proper operation of the
control plane. Automated data plane traffic generation tied to the control plane emulation is necessary to eliminate the need to
manually configure traffic to all destination networks.
6.4 Traffic Generation
Once the network has been established and all connections signaled, the test tool must be able to inject multicast data traffic into
the network topology, at speeds up to line rate, and it must be able to receive traffic as well. This means sending traffic over all of
paths configured on the test interfaces. On the receiving side, the test tool must be able to gather statistics and capture the traffic for
analysis. An increasingly common requirement for test tools is to emulate real enterprise applications over the network. This allows
for the characterization of the network in terms the end user really cares about, namely, how their applications will perform.
6.5 Automation
The complexity of multicast testing with intricate setup and analysis requirements, conditions tests to be repeatable and often
automated. Scripting languages, such as Tcl (Tool Command Language), are used to provide automation in and to enable quality
assurance and manufacturing environments to perform repeatable regression tests necessary to ensure product functionality
and quality.
Generally, setting up a large test bed consisting of a large number of multicast routers and receivers is not economically feasible.
Instead, dedicated multicast test tools designed to emulate the same type of test topology are needed to solve the problem.

7. Ixia’s Approach to Multicast Testing
7.1. Multicast Conformance Testing
Ixia has addressed the challenges of protocol conformance testing by developing IxANVL (Ixia Automated Network Validation
Library), the industry standard conformance test suite.
IxANVL™
IxANVL (Automated Network Validation Library) is a data network testing solution that validates the protocol implementations and
operational robustness of networking devices. For protocol conformance testing, IxANVL supports over 30 protocols overall, and the
multicast protocol conformance suite includes support for PIM-SM, PIM-DM, IGMP, MLD, and DVMRP. IxANVL provides positive as
well as negative test cases against the RFCs that specify these standards. Negative tests help validate device response to "killer
packets."
IxANVL performs its tests as a dialogue: it sends packets to the router being tested, receives the packets sent in response, and then
analyzes the response to determine the next action to take. This allows IxANVL to test complicated situations or reactions in a much
deeper and flexible way than can be done by simple packet generation and capture devices.
IxANVL can run on standalone workstations or via Ixia's optimized test platforms. IxANVL can be completely automated using a
scripting interface. IxANVL source code is also available to users for customization, allowing a great degree of testing flexibility.
7.2. Multicast Scalability and Performance Testing
Ixia’s IP multicast emulation offers the most comprehensive tools for testing scalability and performance of multicast routers,
including automation. The general methodology employed by Ixia for testing the scalability and performance of multicast routers
involves first surrounding the device or system under test (DUT/SUT) with Ixia hardware test interfaces. The Ixia system then
emulates everything else needed to test the device, including other multicast routers, IP route injection, host receivers, and traffic
transmission. In this way, large and complex topologies can be simulated to test the DUT/SUT in realistic system environments with
a minimum of hardware requirements.
Ixia has developed two primary applications for Multicast performance testing, IxExplorer/IxRouter and IxScriptMate, each with a
distinct testing focus.
IxExplorer™ and IxRouter™
IxExplorer provides a high level of flexibility and functionality in protocol emulation, traffic generation, and analysis. IxExplorer is the
primary controlling application for Ixia’s purpose-built hardware test platform, allowing detailed configuration of protocols and
analysis of test results. As part of IxExplorer, IxRouter provides protocol emulation capabilities, including a comprehensive set of IP
multicast protocols, as well as other routing and signaling protocols such as OSPF, IS-IS, RIP, BGP, LDP, and RSVP-TE.
IxRouter provides routing protocol emulation with layer 2 and 3 packet-generation and traffic analysis capabilities. IxRouter’s GUI
exposes many of the packet parameters so that complex IP unicast, and IP multicast packets can be created. IxRouter provides
support for the emulation of versions 1, 2, and 3 of the Internet Group Membership Protocol (IGMP), and support Multicast Listener
Discovery (MLD) Protocol version 1 and 2 for testing IPv4, IPv6, and dual-stack routers. These protocols are designed for Ixia’s
Load Modules, which integrate a CPU per port, offering unparalleled scalability and performance.
IxRouter’s spreadsheet GUI facilitates the entry of large and complex configurations, where, for example, displaying only the
relevant protocol and stream parameters can customize a test environment. IxRouter can log and graph statistics, and can be run
simultaneously on one or many ports, in conjunction with line-rate traffic, to simulate realistic Internet scenarios.
Ixia’s PIM-SM multicast routing emulation offers the capability to extensively test PIM-SM enabled routers. Designed for Ixia’s Load
Modules, Ixia’s PIM-SM emulation offers unparalleled scalability and performance. Hundreds of PIM neighbors are supported per
port. Also, any combination of PIM Register and Join/Prune Messages can be advertised from a port to simulate traffic from
multicast sources and destinations. Besides scalability, Ixia’s protocol emulations can simulate any number of topologies to validate
a System under Test’s (SUT’s) ability to create unidirectional, shared trees rooted at an RP per group, and shortest-path trees per
source. Ixia’s PIM-SM multicast routing emulation can be run with any combination of IGP and signaling protocols. To properly test
Reverse Path Forwarding functionality, routing protocol emulation, such as the emulation of OSPF, IS-IS, RIP, or RIPng, must be
used to advertise the sender source addresses. Also, Ixia’s IGMP and MLD multicast emulations can be used to replicate hosts
joining/leaving multicast groups, and can be used in conjunction with PIM-SM to simulate a variety of multicast topologies.

IxScriptMate™
IxScriptMate provides a framework for running automated test scenarios. Numerous test suites have been developed within the
IxScriptMate environment for testing Multicast traffic throughput performance, latency, delay of multicast group Joins or Leaves,
group capacity, and scalability. IxScriptMate simplifies the configuration process by defining a configuration for the test and
displaying the relevant parameters for user input. Tests then run automatically, and the results are presented to the user.
Figure 9: Ixia Emulation of Multicast Protocols. Here Ixia is emulating IGMP, as well as MLD clients.

8. Conclusion
Multicast is a crucial component of the Internet. It enables a wide variety of applications that require sending packets from one or
more senders to a group of recipients, in a single operation.
The long list of applications based on Multicast includes content distribution of news, security monitoring, file distribution and
caching, interactive multimedia games and distance learning, multimedia teleconferencing and whiteboards, chat groups, polling
and data collection, on-line auctions, parallel and distributed computing, etc.
As Multicast continues to expand its functionalities through ongoing development, it has already proven to be a complex technology,
encompassing a wide range of services and applications. Equipment vendors, carriers and service providers, as well as enterprise
customers depend on the interoperability, scalability, and performance of their network equipment to perform multiple services,
critical to their communications and core infrastructures. Handling Multicast's dynamic complexity requires proficient testing tools
and proper test methodologies to help network managers and Multicast equipment vendors in several critical areas:
• Conformance to standards, to ensure interoperability in a complex, multi-vendor environment.
• Network scalability, to understand network limitations.
• Performance characterization, to avoid bottlenecks.
Ixia provides that solution with
• IxANVL, the industry standard conformance test suite.
• IxRouter and IxExplorer, providing flexibility and functionality in protocol emulation, traffic generation, and analysis.
• IxScriptMate, providing the efficiency of automated testing.
Together, these tools enable the providers of next-generation Multicast products and services to ensure the reliability, performance,
scalability, and profitability of their offerings.
The following appendix section provides sample test plans that demonstrate several multicast testing methods and scenarios.

9. Appendix: Multicast Testing Example
This section provides four test case examples for testing conformance and performance of networking equipment enabled for
multicast forwarding. The first test case is an example of conformance testing. The second test case is an example of using
automated scripts to quickly generate test results. The third demonstrates Ixia's Custom Engineering capability for creating a custom
application for a specific technology. The last test case presents an example of utilizing a GUI test application to configure a
complex test and take precise measurements.
9.1. PIM-SM Conformance Test
9.1.1. Objective
To characterize a router’s protocol compliance with PIM-SM RFC standards. IxANVL offers conformance test suites to validate the
vendor’s protocol implementations of PIM-DM and PIM-SM. In this example, we will focus only on the PIM-SM test suites.
9.1.2. Test Setup
The IxANVL software runs a Linux workstation and it supports Ethernet interfaces for Multicast conformance tests. A minimum of
two test ports is required to run most tests. A third test port will be required if the full test suite is run. Optionally, IxANVL can also
utilize Ixia’s Ethernet Load Modules that have a CPU per port for the multicasting test suites. In this configuration, the IxANVL Linux
workstation communicates with an Ixia chassis to take ownership of the respective ports and runs the respective test scripts through
the port CPUs.
For each test, IxANVL simulates a portion of a topology in order to test the DUT in various network configurations. Up to 17
simulated topologies are utilized by the test suite. For example, in Figure 10, IxANVL simulates two multicast-enabled routers
connected to two DUT interfaces. One of these simulated routers is the BSR and RP; the other is downstream from the DUT.
Figure 10: PIM-SM Conformance Sample Topology

9.1.3. Parameters
DUT Hostname The name of the device under test, a PIM router
IP First Unused Net A starting IP address in dotted-decimal format.
IP Unused Net Mask Specifies the network mask in dotted-decimal format.
IP Number Unused Nets Specifies the number of networks that IxANVL can use for advertised routes.
Multicast group address An IPv4 Multicast group address to be advertised by IxANVL.
Interface Entries A number of layer 2 and 3 entries required to enable a particular interface.
Table 2: PIM-SM Configuration Parameters
The above entries are the minimum parameters necessary to run test cases manually. Ixia also provides additional entries to
automate IxANVL testing. These entries specify capabilities (or limitations) of the specific DUT, or commands to configure the
DUT for certain tests.
9.1.4. Methodology
IxANVL runs a number of test cases against the DUT based on direct interpretation of the PIM-SM IETF
draft-ietf-pim-sm-v2-new-07.
Enter values for required configuration parameters in the IxANVL Configuration tab (see Figure 11). Configure each
IxANVL network interface with the appropriate network parameters, including those of the DUT such as IP address, MAC
address, gateway, etc.
1. Specify DUT capabilities and commands, typically via command scripts such as Expect scripts, if the test suite will
be automated.
2. Select the set of IxANVL PIM-SM test cases to run during the test session (see Figure 12). The tree view allows
selecting or deselecting a test case, an entire test branch, or the entire test suite. In addition, test cases can be
filtered based on the RFC interpretation of “MUST”, “Should”, or “May” statements.
Figure 11: PIM-SM Conformance Test Configuration

Figure 12: PIM-SM Conformance Test Case Selection
IxANVL allows the callouts of command scripts that configure the DUT as required between test cases to match the respective test
requirements. If command scripts are not specified then IxANVL will pause at predetermined times to allow the user to configure the
DUT for a particular test case. IxANVL also provides logs showing the steps the test is executing as well as the packet exchange
that took place with the DUT.
9.1.5. Results
Number of tests passed/failed, including reasons for failed cases (see Figure 13).
Figure 13: PIM-SM Conformance Test Results

9.2. IPv4 Multicast Benchmarking Test
9.2.1. Objective
To evaluate the performance of an IP multicast enabled router per RFC 2432, “Terminology for IP Multicast Benchmarking.”
IxScriptMate offers a number of test cases to measure multicast throughput, latency, delay of multicast group Joins or Leaves, and
group capacity. This particular example measures the average latency of multicast frames sent to clients on multiple subnets (ports).
The Latency test reveals how much processing overhead the DUT requires, on average, to forward multicast frames. Parameters
such as frame rate and frame size can be altered to determine the effect on multicast forwarding latency.
9.2.2. Test Setup
This test requires a minimum of two ports: one to transmit multicast traffic and at least one port to receive the resulting traffic. In
Figure 14, six ports are being used. One to transmit the multicast group packets and the remaining ports are configured as IGMP
hosts. A multicast routing protocol must be enabled at the router for the test to properly execute. The IxScriptMate application,
running on a workstation, controls the test running on the Ixia hardware.
Figure 14: IPv4 Multicast Performance Sample Topology

9.2.3. Parameters
Parameter Description
Duration The duration of the test in hours, minutes and seconds, which is used to calculate
the number of frames that need to be transmitted.
No. of Trials Select how many times you want to test each frame size.
No. of Iterations Specify the number of times the test increments or decrements the frame rate.
Initial Rate The starting rate at which frames are transmitted. Specify this value as a
percentage of the maximum theoretical frame rate.
Increment The percentage increase (positive value) or decrease (negative value) in the
transmission rate for each iteration.
First Group Address IP address of the first multicast group.
Total Group Addresses The number of group addresses that will be assigned to each port. During the
test, each port will join this number of groups starting with the group specified by
the First Group Address parameter.
IGMP Version The IGMP version to use: 1 or 2.
Group Type Determines how addresses are allocated among ports:
• If Accumulated, the same addresses are duplicated on each port.
• If Distributed, the total number of addresses is divided up and
loaded onto all ports evenly.
Enable Leave Group If you check this box, the hosts simulated by the Ixia port send IGMP Leave
Group messages to the DUT at the end of the iteration.
Enable Router Alert Sets the IP header Send Router Alert bit in messages.
Frame size Specify the frame sizes that should be tested in sequence for each iteration.
Duration The duration of the test in hours, minutes and seconds, which is used to calculate
the number of frames that need to be transmitted.
No. of Trials Select how many times you want to test each frame size.
No. of Iterations Specify the number of times the test increments or decrements the frame rate.
Initial Rate The starting rate at which frames are transmitted. Specify this value as a
percentage of the maximum theoretical frame rate.
Increment The percentage increase (positive value) or decrease (negative value) in the
transmission rate for each iteration.
First Group Address IP address of the first multicast group.
Total Group Addresses The number of group addresses that will be assigned to each port. During the
test, each port will join this number of groups starting with the group specified by
the First Group Address parameter.
IGMP Version The IGMP version to use: 1 or 2.
Group Type Determines how addresses are allocated among ports:
• If Accumulated, the same addresses are duplicated on each port.
• If Distributed, the total number of addresses is divided up and
loaded onto all ports evenly.
Table 3: IPv4 Multicast Benchmarking Parameters

9.2.4. Methodology
1. Enable both IP forwarding and IGMP on the DUT. Also, an IP multicast routing protocol must be enabled and
configured (i.e., DVMRP, PIM-SM or PIM-DM)
2. To simplify configuration, configure the DUT’s interface IP addresses in incrementing order (i.e., 192.168.0.1/24,
192.168.1.1/24, 192.168.2.1/24, etc.)
3. At the workstation, Launch IxScriptMate and connect to an Ixia Chassis.
4. Expand the IP Multicast (RFC 2432) test suite, and select the latency test script.
5. Specify the frames sizes that will be tested for each iteration or trial.
6. Specify the source and gateway IP addresses for each interface. If the DUT’s interface IP addresses are
incremented by one, then simply specify the first source and gateway IP address and specify which octet to
increment by.
7. Specify the port mapping from the multicast source port to the client receiver ports. This configuration step can be
simplify if the all port used in the test are grouped together and collocated on the same chassis. If so, the automatic
mapping can be used. Simply specify the starting and ending port numbers, and the port number of the port
assigned as the multicast source.
8. Start the test. The following is a methodology summary of this test:
• The test begins by calculating the number of frames to send as validation traffic based on the values for the
Duration and Max Rate parameters.
• The receive ports send IGMP Join requests to the DUT at the rate specified for Rate. The value for IGMP Version
determines the format of the Join messages.
• After the receive ports have sent their Join messages, the transmit port sends validation traffic (IP frames)
addressed to each group.
• While the transmit port is transmitting the validation traffic, the test tags a special frame and inserts it into the
stream of normal frames.
• When the receive ports receive the tagged frame, the test compares its timestamp with the current time and
calculates difference between the two. The difference is the latency.
9. At the conclusion of the test, click on the result tab to review the test results. By default, the log and result files are
stored locally at the client workstation at C:Program FilesIxiaTclScripts.

9.2.5. Results
Latency (ns) per Multicast group, frame counts for Transmit and Receive ports, and frame loss.
Figure 15: IPv4 Multicast Benchmarking Sample Results
9.3. IPv6 Multicast Listener Discovery (MLD) Performance Test
9.3.1. Objective
To evaluate the performance of an IPv6 multicast enabled router when enabled for MLD. This custom application measures the
expected and actual IPv6 forwarding performance when one or more IPv6 edge gateways with attached IPv6 PC hosts are joining
and leaving a user-specified number of IPv6 multicast group addresses. The resulting data and charts provide aggregate
measurements as well as measurements per VLAN ID and VLAN priority.

9.3.2. Test Setup
This test requires a minimum of two ports: one to transmit, and one to receive.
Figure 16: MLD Performance Tester
All ports support neighbor discovery. In addition, the interfaces downstream from the DUT also support DHCPv6 and VLANs.
9.3.3. Parameters
DHCPv6 The following information will be used for “Client Identifier” of DHCPv6 request.
• Router MAC address (or Link Layer Address)
• Preferred Lifetime in IA Prefix
• Valid Lifetime in IA Prefix
• Prefix address in IA Prefix
IPv6 interface addresses Can be specified manually or configured for DHCPv6 resolution
VLAN Specifies if VLAN are enabled on a port and the valid range of VLAN
identification
# Traffic Groups Number of multicast groups available that an IPv6 host can join
- MCast Addr IPv6 Multicast group address
- Size IPv6 Network Prefix
% Rate Percent of line rate for a particular Multicast group address
Dst Port Destination Port
DSCP Diffserv Code Points for IPv6 multicast source traffic
Number PC’s Number of simulated PCs. Default is one.
MLD Group numbers to select from Either specify all or the respective list of indices representing the various
multicast groups
Number of groups to join Specify either fixed or random. If random, specify min and max number of groups
Delay before joining a group Specify either fixed or random. If random, specify min and max times in seconds
How long to stay in group Specify either fixed or random. If random, specify minimum and maximum times
in seconds
Table 4: IPv6 MLD Performance Parameters

9.3.4. Methodology
1. Click on the port selection tab and select the chassis chain. Add a chassis by entering its DNS name or the IPv4
address. Once attached, the chassis branch can be expanded to display cards and ports as shown in Figure 17.
Ownership can be set and cleared on the selected ports.
Figure 17: MLD Port Selection
2. Click on the DHCPv6 Configuration. This script does not capture or analyze the “Router Advertisement packets”
from DUT. Instead, this script will track the number of Router advertisements and then respond with a “request
packet” encoded with the following parameters.
Figure 18: MLD DHCPv6 Configuration
Note that the script requires that the Prefix address have vlan-id embedded. In Figure 18, “5” is VLAN-id (this will be
automatically inserted by “Port Configuration” tab”). Please adjust DUT prefix delegation settings to this rule. Also
note that the “Transaction-id” and “time value in client-id” will be always the same in all emulated gateways. The
IAID will be unique in each emulated gateway.
3. Click on the port configuration tab and identify the port that will be the IPv6 Multicast traffic port (see Figure 19).
Only one port can be configured as the traffic port. Multiple ports can be configured as emulated gateways but the
VLAN ID must be unique in each port. Note the VLAN ID must be a contiguous range (always incrementing by one).
Figure 19: MLD Port Configuration

4. Figure 20 shows the test configuration parameters. Here the test can be configured to run indefinitely, for a period
of time, or a number of iterations. In addition, the test application can configure ports to re-advertise neighbor
solicitations and DHCPv6 requests, or even drop the link after each iteration.
Figure 20: MLD IPv6 Multicast Traffic Configuration
5. The IPv6 traffic profile is also constructed on this tab. Specify the number of IPv6 Multicast groups and their
respective parameters. The traffic port will generate IPv6 UDP Multicast traffic coded with the respective DSCP
values.
6. The Client configuration tab provides the capability to simulate the behavior of PCs joining and leaving multicast
groups behind every emulated gateway. In Figure 21, the home gateway tree lists the four emulated gateways are
configured back at the port configuration tab (see Figure 19).
Figure 21: MLD Simulated Client Configuration
The PC operational behavior can be configured at every branch. If done at the top branch then the number of PCs
and the respective multicast parameters will be applied to all emulated gateways. In addition, the multicast group
parameters can be customized down to a particular PC configuration.
Once the operational behavior is configured for the emulated gateways, then a MLD join and Leave schedule can
be generated.

9.3.5. Results
The MLD performance tester can plot bit rates of expected and actual multicast traffic. The differences between expected and
actual traffic rates indirectly depict the join and leave delays. Figure 22 shows black solid and dotted lines for total actual and
total expected bit rates; respectively. The solid line is shifted to the right indicating the delay in the join- and leave-messages.
In addition, real-time bit rate statistics are also plotted in the figure in a different color, for the actual and expected data for each
emulated gateway.
Figure 22: MLD Performance Real-time Charts
The result tab as shown in Figure 23 shows the individual and aggregated totals, and indicates the distinct bit rates per VLAN
priority. This is especially useful if the DUT is being loaded with additional unicast or multicast traffic and the user wishes to verify
the effect on the performance of particular multicast traffic with specific VLAN priorities.
Figure 23: MLD Result Summary Page

9.4. PIM-SM Shortest-Path Tree Switchover Test
9.4.1. Objective
To evaluate the switching and forwarding performance of a PIM enabled router when a downstream router issues a (S,G) Join
message to the DUT. An OSPF and PIM-SM topology is emulated, and a simulated downstream router is used to transmit (*,G)
and (S,G) join messages. Traffic flowing to the downstream router is then examined to measure the switching and forwarding
performance.
This example demonstrates the capability of the Ixia’s IxRouter application to create a custom multicast topology and then to utilize
IPv4 multicast flows to measure the multicast performance.
9.4.2. Test Setup
This test requires a minimum of three Ixia ports, as shown in Figure 24. Port A will generate multicast traffic flows along the source
tree, Port B will generate the same flows as Port A—but at half the rate—along the shared tree, and Port C will monitor the received
multicast traffic. All ports will maintain an OSPF adjacency and a PIM session. The DUT is to be configured for PIM-SM with the
Rendezvous Point (RP) set statically to the address of one of the simulated routers on Port B.
Figure 24: PIM-SM Shortest-Path Tree Switchover Topology
9.4.3. Parameters
Multicast Traffic Flow An IPv4 packet with a unicast source IPv4 address and a multicast IPv4 address.
Multicast Group Count Five multicast group addresses are used in this test plan but the minimum
number would be one multicast group. This parameter can be used to test the
SPT switchover sensitively of a router as the number of multicast groups
increase.
PIM-SM Rendezvous Point (RP) By default it can be any router on port B except for the first hop router (FHR).
Frame Sizes In this example, only one frame size was used. However, any combination of
frame sizes can be use across one or more multicast traffic flows.
Unicast Traffic Profile When one or more unicast IPv4 traffic flows are used to simulate heterogeneous
traffic.
Table 5: PIM-SM Shortest-Path Tree Switchover Parameters

9.4.4. Methodology
1. Launch IxExplorer and click on the protocol icon to access the IxRouter Protocol Window.
Figure 25: IxExplorer Main View
2. Log in to an Ixia chassis and take ownership of three Ixia ports. Enable OSPF and PIM-SM on all ports.
Figure 26: Enabling Ixia Ports for Emulation in IxRouter
3. Create an IPv4 address for each port and verify connectivity by either issuing “ARP requests” for Ethernet interfaces, or by
using PING.
Figure 27: Configuring IPv4 Interfaces

4. Configure an OSPF adjacency on each port. For maximum flexibility, configure the networks using the User LSA mode. As
shown in Figure 28, construct a 1x3 OSPF network range grid on Port A and a 1x2 grid on Port B. Make sure that last router in
both grids has the same router ID. Link the two grids by altering the Router LSA for the last router on each port -- by adding the
subnet information from the other grid attached to the last router. The new information will indicate that the routers are
connected to each other. Figure 28 illustrates how this can be done. The subnet 12.24.12.0/24 was automatically created in
the OSPF grid for Port B. It was added to the Router LSA for the advertising router ID 19.68.13.1 in the Port A configuration.
Likewise, the 38.138.23.0/24 subnet was created in the OSPF grid for Port A. It will be added to the Router LSA for the last
router in the User LSA list for Port B.
Figure 28: Linking Two OSPF Grids
5. The PIM-SM configuration is fairly straightforward. The PIM-SM state machines will be running on all ports, but only Port C will
be issuing (*,G) and (S,G) Join messages. Ports A and B will be sending out PIM-SM Hello messages to indicate that a PIM-
SM neighbor is attached. In Figure 29, three PIM-SM Join messages are constructed. The first is to verify streams from the
source tree, the second is to verify streams from the shared tree, and the last is used to automatically switch from (*,G) to
(S,G) Join messages after a user-specified interval. This “(*,G)->(S,G)” message facilitates data capture since statistics
reporting does not need to be started until just before the switchover.
Figure 29: Configuring PIM-SM messages on Port C

6. Configure the initial set of multicast streams by clicking on the Traffic Generation Map and adding an entry for Port C (as
destination), as shown in Figure 30. Traffic will be originated from Ports A and B. Once the streams have been generated,
differentiate the streams from Ports A and B by doubling the traffic rate from Port A and also by adding a packet group id to
the UDP payload for the traffic from Port A.
Figure 30: Configuring Multicast Streams from the Protocol Window
7. Enable Port C for packet group mode and specify the offset for the signature and the packet group ID.
9.4.5 Results
The primary results will be the frame rates at the switchover time. Secondary results will be packet loss, throughput, and
convergence measurements. (See Figure 31.)
Figure 31: Configuring Window Layout for PIM-SM SPT Switchover Test

Figure 32 illustrates how the user can capture very accurate convergence measurements with Ixia. Latency over Time provides a
data series that can be graphed to depict very accurate convergence times. In this example, latency over time was used to capture
data at 10 ms intervals. The chart shows that it takes 30 ms for the router to drop the traffic from the shared tree and forward the
traffic using the source (shortest-path) tree.
(Measured at Port C)
0
500
1,000
1,500
2,000
2,500
3,000
3,500
4,000
4,500
5,000
300 400 500 600 700 800 900 1,000 1,100
Elapsed Time (ms)
Frame
Rates
(fps) RX Traffic from Shared Tree
RX Traffic from Source Tree
Figure 32: IPv4 Multicast Traffic Profile at SPT Switchover

10. Glossary of Terms
Autonomous System
(AS)
A collection of routers, typically operated by a single administrative function, coordinated to
implement the same routing policy.
IANA Internet Assigned Numbers Authority—The agency that controls the assignment of Internet
address ranges and subranges.
Internal Gateway
Protocol (IGP)
Protocol used to exchange routing information between collaborating routers in the Internet.
Examples of IGPs include Routing Information Protocol (RIP) and Open Shortest Path First
(OSPF).
IS-IS An OSI/IP routing protocol, IS-IS stands for Intermediate System to Intermediate System
(i.e., router to router).
Open Shortest Path
First (OSPF)
A link-state routing protocol used by IP routers located within a single Autonomous System (AS)
to determine routing paths. MPLS traffic engineering parameters can be distributed with OSPF
using extensions to the protocol (OSPF-TE).
Path Vector (PV)
Algorithm
The PV routing algorithm supplements the advertisement of reachable destinations with
information that describes various properties of the paths to these destinations. A path is the
recorded sequence of AS numbers through which the reachability information has passed.
Each AS is considered equal, independently of its size and internal composition.
A route is defined by the tight coupling of the path to a destination and its attributes, instead of
the single distance metric used by Bellman-Ford and other traditional distance-vector algorithms.
Different autonomous domains can have different route optimality notions, as PV only standardizes
the results of route selection while allowing heterogeneous criteria across domains. Each AS can
have its own policies for route selection.
The Path Vector Algorithm is described in RFC 1322.
Protocol Independent
Multicast (PIM)
Multicast routing protocol that enables the addition of IP multicast on existing IP networks. It is
unicast routing protocol independent, and it can operate in dense mode or sparse mode.
Multicast - Dense
Mode (PIM-DM)
Dense mode PIM, where dense means that it does flood-and-prune instead of only forwarding
where requested.
Multicast - Sparse
Mode (PIM-SM)
Sparse Mode PIM, where sparse refers to the fact that it only forwards where requested.
See RFC 2362.
Prefix Set of contiguous bits, from 0 to the length of an address, representing all addresses that start with
such set of preceding bits. It condenses a (usually large) number of addresses in a compact
format.
The prefix attribute of a route determines a section of IP space. For example, IPv4 Class B
networks (also known as /16 networks) have a 16-bit network prefix followed by a 16-bit host
number. The two highest order bits are set to 1-0, with a 14-bit network number completing the
network-prefix (i.e., 128.0.x.x to 191.255.x.x).
Rendezvous Point
(RP)
An RP is a router with a well known IP address (location) where information about multicast
sources can be found. It acts as the gatekeeper for multicasts to and from other domains. At least
one RP exists in each PIM cloud, and all routers within the PIM cloud are told about the RP.
Time-To-Live (TTL) Time-To-Live field in the IP multicast datagrams limits the scope of an IP datagram. TTL, in hops,
can be a value from 0 to 255. The default value is 0, which means that all multicast packets are
forwarded out the interface.
Traffic Engineering Techniques and processes that optimize the routing of network traffic. Traffic engineering
mechanisms enable network administrators to manage network traffic’s bandwidth, delay,
and congestion.

11. Bibliography
[1] Developing the Evolution of Multicast: From the MBone to Inter-Domain Multicast to Internet2 Deployment
Kevin Almeroth, , IEEE Network, (Jan/Feb 2000), Pages 1-20.
[2] Developing IP Multicast Networks (volume 1)
Beau Williamson. Publisher: Cisco Press, (2000). (ISBN: 1-57870-077-9).
[3] Interdomain Multicast Routing
Brian M. Edwards, Leonard A. Guiliano, Brian R. Wright. Publisher: Addison-Wesley (2002).
[4] Internetworking Technologies Handbook, Fourth Edition
Cisco Systems. Publisher: Cisco Press, (2003). (ISBN: 1587051192).
[5] TCP/IP Illustrated, Volume 2: The Implementation
W. Richard Stevens. Publisher: Addison-Wesley. (ISBN: 0201633469).
[6] Multicast Transport Protocols: A Survey and Taxonomy
Katia Obraczka. IEEE Communications magazine, January 1998, vol. 36, No. 1.
[7] RFC 2362: Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V.
Jacobson, C. Liu, P. Sharma, L. Wei, (June 1998).
[8] RFC 2432: Terminology for IP Multicast Benchmarking
K. Dubray, (October 1998).
[9] RFC 2858: Multiprotocol Extensions for BGP-4
T. Bates,Y. Rekhter, R. Chandra, D. Katz, (June 2000).
[10] RFC 3376: Internet Group Management Protocol, Version 3.
B. Cain, S. Deering, I. Kouvelas, B. Fenner, and A. Thyagarajan, (October 2002).
12. Acknowledgements
Authors: Dr. Diego Dugatkin, Tony De La Rosa

Using computer networking in multicast .

More Related Content

Similar to Using computer networking in multicast . (20)

Recently uploaded (20)

Using computer networking in multicast .