You are on page 1of 35

Multicast Test Plan Test Plan Primer

Contents
Overview...........................................................................................................................................3 1. Multicast Conformance Testing..................................................................................................3 2. Multicast Host Protocol Testing..................................................................................................6 2.1 Multicast Join/Leave Latency Test....................................................................................6 2.2 Multicast Data Latency Test..............................................................................................9 2.3 Multicast No-Drop Throughput Test................................................................................11 2.4 Multicast Group Capacity Test........................................................................................13 2.5 IGMP Snooping Functionality Test..................................................................................15 3. Multicast Routing Protocol Testing...........................................................................................19 3.1 PIM-SM Rendezvous Point (RP) Functionality Test ........................................................19 3.2 PIM-SM Last Hop Router (LHR) Functionality Test........................................................22 3.3 PIM-SM First Hop Router (FHR) Functionality Test ........................................................25 3.4 PIM-SM Reverse Path Forwarding (RPF) Functionality Test ........................................28 3.5 PIM-SM Rendezvous Point Tree (RPT) to Shortest Path Tree (SPT) Switchover Functionality Test...................................................................................................................... 31

Copyright 2005 Ixia. All rights reserved. The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Ixia. Ixia assumes no responsibility or liability for any errors or inaccuracies that may appear in this document. Ixia and the Ixia logo are trademarks of Ixia. All other companies, product names, and logos are trademarks or registered trademarks of their respective holders.

Ixia 26601 W. Agoura Road Calabasas, CA 91302 Phone: Fax: Email: Internet: (818) 871-1800 (818) 871-1805 info@ixiacom.com www.ixiacom.com

 Copyright Ixia, 2005

Multicast Test Plan

v
Overview
Multicast is an efficient way to deliver traffic from one sender to many potential receivers. There are multiple multicast applications that operate today over the Internet, and service providers are searching for solutions to support ever increasing multicast traffic. Thorough and rigorous testing of multicast devices is essential to guarantee appropriate functioning of multicast applications. The varied multicast protocols in use today range from host protocols (IGMP, MLD) to routing protocols (MOSPF, DVMRP, PIM-DM, and PIM-SM/SSM). Earlier versions of multicast routing protocols suffered from limitations and scalability issues of one type or another. For these and other reasons, the PIM-SM/SSM has emerged as the most popular multicast routing protocol for most service providers today. This test plan is divided to three sections. Section 1 deals with multicast conformance testing. The PIM-SM/SSM test suite is used as sample technology, and the methodology described is directly applicable to other test suites. Section 2 deals with multicast host protocol testing. IGMPv2 is used in all sample tests, and you can easily modify the test to include other flavors of host protocols. Section 3 deals with multicast routing protocol testing. Again, PIM-SM/SSM is used in the sample tests.

1. Multicast Conformance Testing

Objective To ensure the DUTs conformance to relevant RFCs and protocol standards by testing each and every protocol state to verify exact implementation of all protocol messaging and responses. Ixia offers a complete list of multicast conformance suites, from multicast host protocols (e.g., IGMP, MLD) to multicast routing protocols (e.g., DVMRP, PIM-SM/SSM). PIMSM/SSM is used in this sample test; however, the test methodology used is applicable to all other conformance suites. Setup A minimum of two test ports are required to run most tests. A third test port will be required if the full test suite is run. For each test, test ports simulate a portion of the multicast topology to verify the DUTs conformance in various network configurations. Up to 17 simulated topologies are utilized by Ixias IxANVL PIM-SM/SSM test suite. As shown in Figure 1, the IxANVL Linux PC communicates with an Ixia chassis to take ownership of the respective ports, and then run the individual test on the CPUs that are integrated in the Ixia test ports. Alternatively, IxANVL can also be directly run on a Linux workstation.

 Copyright Ixia, 2005

Multicast Test Plan

Figure 1. PIM-SM/SSM conformance sample topology

Input Parameters

Parameter DUT Hostname IP First Unused Net IP Unused Net Mask IP Number Unused Nets

Description The name of the device under test, a PIM router A starting IP address in dotted-decimal format Specifies the network mask in dotted-decimal format Specifies the number of networks that IxANVL can use for advertised routes Table 1. PIM-SM/SSM configuration parameters

The above parameters are the minimum required to run test cases manually. Additional parameters must be specified to automate testing. These parameters specify the capabilities, or limitations, of the DUT or of the commands themselves in configuring the DUT for certain tests. Methodology This test runs a number of cases against the DUT based on direct interpretation of the PIMSM IETF draft-ietf-pim-sm-v2-new-07. 1. Enter values for required configuration parameters (see Table 1) for the conformance tester (see Figure 2).

 Copyright Ixia, 2005

Multicast Test Plan

Figure 2: PIM-SM/SSM conformance test configuration

. Configure each network interface to be used with the appropriate network parameters, including those of the DUT, such as IP address, MAC address, gateway, etc. 3. Specify DUT capabilities and commands, typically via command scripts such as Expect scripts, if the test suite will be automated. 4. Select the set of PIM-SM test cases to be executed during the test session (see Figure 3). 5. Test cases may be chosen based on the RFC interpretation of Must, Should, or May statements. 6. Command scripts that configure the DUT as required between test cases may be required to match the respective test requirements.

Figure 3. PIM-SM/SSM conformance test case selection


 Copyright Ixia, 2005 Multicast Test Plan

Results Number of tests passed/failed, including reasons for failed cases (see Figure 4).

Figure 4: PIM-SM conformance test results

2. Multicast Host Protocol Testing

2.1

Multicast Join/Leave Latency Test

Objective To characterize the multicast group join/leave latency with respect to frame size and the number of groups in test. The group join latency is defined as the elapsed time between the receipt by the DUT of a group of IGMP/MLD Join requests and the time when the multicast clients begin receiving traffic for the groups they joined. The group leave latency is defined as the elapsed time between the receipt by the DUT of a group of IGMP/MLD Leave requests and the time when the multicast clients stop receiving traffic for the groups they left. Setup A minimum of three ports are required for this test: one to transmit, two to receive. IxScriptMate supports a suite of powerful scripts that can be used to provide RFC 2432 multicast benchmark testing in addition to performance testing for specific topology setups. In particular, ScriptMates Multicast Group Join and Group Leave latency tests are used to execute this test.

 Copyright Ixia, 2005

Multicast Test Plan

Figure 5. Test setup for multicast group join and leave latency test Input Parameters

Parameter Frame Size Host Protocol Groups to Join/Leave Group Type Frame Rate

Description Multicast traffic frame size IGMPv1, IGMPv2, IGMPv3, MLDv1, or MLDv2 Total number of groups to join or leave Accumulated or Distributed the receivers are either joining/ leaving the same groups or different groups Multicast traffic rate

Table 2. Test input parameters for testing multicast join/leave latency Methodology 1. Configure the DUT to act as FHR, RP and LHR routers. . Set up the tester ports to simulate IGMP clients and multicast sources only (no involvement in routing). Test Port 1 will be used as the multicast source and Test Port 2 and Test Port 3 will be used as receivers. 3. Select a lower frame rate (e.g., 10 frames/second) to start the test. Gradually increase the frame rate if needed. 4. A higher frame rate may cause DUT to congest when the number of multicast groups becomes big, and this may negatively impact latency results. 5. Alter frame size, and the number of groups to join and leave and observe latency result changes. 6. In addition to average latency results, the min and max value should also be examined.

 Copyright Ixia, 2005

Multicast Test Plan

Results Both multicast group join and leave latency are measured using different frame sizes with different number of groups under test (10 and 100 as an example). As shown below, frame size has little influence on group join and leave latency while the number of multicast groups under test has dramatic impact on the latency results.

Figure 6. Group join latency for 10 multicast groups

Figure 7. Group join latency for 100 multicast groups

Figure 8. Group leave latency for 10 multicast groups

 Copyright Ixia, 2005

Multicast Test Plan

Figure 9. Group leave latency for 100 multicast groups

2.2

Multicast Data Latency Test

Objective To characterize the data plane latency with respect to frame size and number of multicast groups in the test. Setup A minimum of three ports are required for this test: one to transmit, two to receive. The IxScriptMate Multicast Latency test can be used to execute this test.

Figure 10. Test setup for measuring multicast data latency

 Copyright Ixia, 2005

Multicast Test Plan

Input Parameters Parameter Frame Size Host Protocol Groups to Join/Leave Group Type Frame Rate Description Multicast traffic frame size IGMPv1, IGMPv2, IGMPv3, MLDv1, or MLDv2 Total number of groups to join or leave Accumulated or Distributed the receivers are either joining/ leaving the same groups or different groups Multicast traffic rate

Table 3. Test input parameters for testing multicast data plane latency

Methodology 1. Configure the DUT to act as FHR, RP and LHR routers. . Set up the tester ports to simulate IGMP clients and multicast sources only (no involvement in routing). Test Port 1 will be used as the multicast source, and Test Port 2 and Test Port 3 will be used as receivers. 3. Select a lower frame rate (e.g., 10 frames/second) to start the test. Gradually increase the frame rate if needed. A higher frame rate may cause DUT to congest when the number of multicast groups becomes big, and this may negatively impact latency results. 4. Alter frame size and the number of groups to join and leave, and observe data latency changes. 5. In addition to average latency results, the min and max value should also be examined.

Results As expected, data plane latency does not changing when the number of groups under test increases. It only changes with respect to data frame size.

Figure 11. Data plane latency for 10 multicast groups

10 Copyright Ixia, 2005

Multicast Test Plan

Figure 12. Data plane latency for 100 multicast groups

2.3

Multicast No-Drop Throughput Test

Objective To discover the maximum rate at which the DUT can forward multicast traffic with varying frame size. Setup A minimum of three test ports are required for this test: one to transmit and two to receive. Further, scalability tests can be executed simply by increasing number of receiver ports. The IxScriptMate Multicast Throughput No Drop Rate test can be used to execute this test.

Figure 13. Test setup for no drop throughput test

11 Copyright Ixia, 2005

Multicast Test Plan

Input Parameters Parameter Frame Size Host Protocol # of Multicast Groups Throughput Search Method Loss Tolerance Description Multicast traffic frame size IGMPv1, IGMPv2, IGMPv3, MLDv1, or MLDv2 Total number of multicast groups Binary or linear Loss Tolerance for the specified search method

Table 4. Test input parameters for testing multicast no drop throughput Methodology 1. Configure the DUT to act as FHR, RP, and LHR routers. . Set up the tester ports to simulate IGMP clients and multicast sources only (no involvement in routing). Test Port 1 will be used as the multicast source, and Test Port 2 and Test Port 3 will be used as receivers. 3. Select frame size of interest and start the test. 4. Adjust initial throughput rate for quicker convergence if needed.

Results Figure 14 illustrates no-drop throughput for various frame sizes, in addition to data latency and errors at the measured throughput.

Figure 14. No-drop throughput summary results

2.4

Multicast Group Capacity Test

Objective To discover the maximum number of multicast groups supported by a given DUT. Setup A minimum of three test ports are required for this test. Test Port 1 will simulate multicast source, and Test Port 2 and Test Port 3 will simulate multicast receivers. Further scalability tests can be executed simply by increasing the number of test ports. The IxScriptMate Multicast Group Capacity test can be used to execute this test.

12 Copyright Ixia, 2005

Multicast Test Plan

Figure 15. Test setup for group capacity test

Input Parameters Parameter Frame Size Host Protocol Step Size of Group Increase Group Type Description Multicast traffic frame size IGMPv1, IGMPv2, IGMPv3, MLDv1, or MLDv2 Number of new groups added after each successful iteration Accumulated or Distributed the receivers are either joining/leaving the same groups or different groups

Table 5. Test input parameters for testing multicast group capacity Methodology 1. Configure the DUT to act as FHR, RP and LHR routers. . Set up the tester ports to simulate IGMP clients and multicast sources only (no involvement in routing). Test Port 1 will be uses as the multicast source and Test Port 2, and Test Port 3 will be used as receivers. 3. Select frame sizes of interest and start the test. 4. Adjust initial number of groups and the step size for quicker convergence if needed. Some DUTs may have a port-level capacity as well as chassis-level capacity. 5. Change group type to observe any difference in terms of total number of groups supported by the DUT (per port and per chassis).

13 Copyright Ixia, 2005

Multicast Test Plan

Results Figure 16 illustrates that the DUT has a group capacity on per port basis. When two test ports or three test ports are used as receiver ports, per port group capacity doesnt change (approximately 175 groups). One can easily verify this behavior by adding more receiver ports. The total group capacity of the DUT would be simply a multiplication of number of ports times per port group capacity).

Figure 16. Group capacity discovered based on acceptable frame loss ratio

Figure 17. Group capacity per port summary stats

2.5

IGMP Snooping Functionality Test

Objective Some Layer 2 devices have the ability to keep track of IGMP membership by passively monitoring join and leave requests and building a corresponding membership table so traffic can be forwarded to the right ports instead of broadcasting it to all ports. The objective of this test is to ensure that when the DUT is functioning as Layer 2 snooping device, it can successfully build and maintain the membership table and deliver the traffic to the right ports. Setup A minimum of three test ports are required. Two setups are possible with this test as shown below. Test Port 3 can be used to emulate an RP router as well as the FHR in the case of a lack of a real multicast router. A more realistic setup is to have a multicast router functioning as RP router in conjunction with a Layer 2 snooping switch with Test Port 1 and Test Port 2 simulating distinct IGMP clients, and Test Port 3 emulating FHR and multicast sources.

14 Copyright Ixia, 2005

Multicast Test Plan

Figure 18. Test setup for testing IGMP snooping Input Parameters Parameter IGP Protocol Description IGP protocols used by the FHR to communicate reachability of multicast sources to the RP router (OSPF or ISIS) IGMPv1, IGMPv2, IGMPv3, MLDv1, or MLDv2 DUT RP address Number of FHR emulated by the source port Number of sources that are generating multicast traffic Number of groups requested by all receivers and the starting group address

Host Protocol RP address # of Emulated Routers at Source port Source Addr count # of Groups and Starting Group Addr

Table 6. Test input parameters for testing IGMP snooping

15 Copyright Ixia, 2005

Multicast Test Plan

Methodology 1. Configure all ports on the Layer 2 snooping switch in the same VLAN, including the port that is connected to the RP router. This is to ensure that all ports are in the same broadcast domain. When IGMP snooping is disabled, multicast frames are supposed to be broadcasted to all receivers in the same VLAN. . Configure the needed protocols on both the IGMP client side (e.g., IGMPv2) and the source port side (e.g., OSPF, PIM-SM), and ensure that the RP address is pointed to the RP router that connects the source port and the Layer 2 snooping switch. 3. Define, for example, 5 unique IGMP groups on both Test Port 1 and Test Port 2 and have the source evenly distribute traffic to all groups at a fixed rate (e.g., 100 frames per second). Ensure end-to-end traffic. If all parameters are set correctly, each of the Test Port 1 and Test Port 2 should receive 50 frames per second, as typically IGMP snooping is enabled when VLAN is created. 4. Toggle IGMP snooping off on the DUT (e.g., no ip igmp snooping). Note that there is usually a global command available to toggle IGMP snooping on and off for all VLANs. Optionally there is command to turn IGMP snooping on and off for a specific VLAN (e.g., no ip igmp snooping vlan 100). 5. Observe the change of receiving rate for both Test Port 1 and Test Port 2. When snooping is on, about 50 frames per second should be expected on each of the two ports. When the snooping is off, each of the two ports should receive 100 frames per second. 6. Scale the test by adding more groups either evenly or unevenly to ensure that the receiving rate is proportional to the number of groups defined in the test port. 7. Add more IGMP client ports to scale the test even further. If performance is of interest, one can easily benchmark the time taken when the snooping is first off and then on and vice versa.

Results As illustrated in Figure 19 below, when snooping is on, each of the test port receives about 50 frames per second while the source is sending at 100 frames per second. As illustrated in Figure 20, when the snooping is off, each of the two receiver ports receives 100 frames per second. Toggle snooping on and off and record the traffic rate change in a graph. See Figure 21.

16 Copyright Ixia, 2005

Multicast Test Plan

Figure 19. When snooping is on, traffic is sent to intended receivers only

Figure 20. When snooping is off, traffic is broadcasted to all receivers

17 Copyright Ixia, 2005

Multicast Test Plan

Figure 21: v

3. Multicast Routing Protocol Testing

3.1

PIM-SM Rendezvous Point (RP) Functionality Test

Objective To ensure that when the DUT operates as a PIM-SM RP router it can register a number of new receivers to one or more specified groups, and deliver the traffic from the source to the receivers successfully. Setup A minimum of two test ports are required to perform the test. Test Port 1 simulates the First Hop Router(s) (FHR) communicating to the RP router (DUT) as well as simulating multicast source hosts. Test Port 2 simulates the Last Hop Router(s) (LHR) and all the IGMP clients that are requesting to join to different multicast groups. Ixias IxRouter can be used to execute this test.

18 Copyright Ixia, 2005

Multicast Test Plan

Figure 22. Setup for testing RP router Input Parameters Parameter IGP Protocol Description IGP protocols used by the FHR to communicate reachability of all multicast sources to the RP router (OSPF or ISIS) DUT RP address Number of FHR emulated by the source port Number of sources that are generating multicast traffic Number of LHR emulated by the receiver port when PIM-SM/SSM is used as receiver protocol Number of groups requested by all receivers and the starting group address Number of receivers per emulated LHR

RP address # of Emulated Routers at Source port Source Addr count # of Emulated routers at Receiver port # of Groups and Starting Group Addr # of Receivers

Table 7. Test input parameters for testing a Rendezvous Point DUT Methodology 1. Configure Test Port 1 to emulate a few FHRs and multiple sources behind each FHR. . Select the right IGP for the FHR (OSPF or ISIS) to communicate the location of each source to the DUT. 3. Enable multicast routing on the DUT and configure the DUT as RP router. Make sure the RP address is referenced correctly in the setup of Test Port 1. 4. Configure Test Port 2 as the receiver. Select the right receiver protocols (IGMP or PIM-SM/ SSM). Ensure multicast group addresses entered match the group addresses set on Test Port 1. 5. Start protocol emulation on all interfaces involved. Ensure all protocols (IGMP, PIM-SM/ SSM, OSPF) are entering stable state.

19 Copyright Ixia, 2005

Multicast Test Plan

6. Configure traffic on Test Port 1 to send multicast traffic with predefined source addresses and multicast group addresses. Ensure traffic can pass thru the DUT and be received successfully by Test Port 2. This can be done by checking Test Port 2s receive rate with respect to the sending rate on Test Port 1. 7. Capture traffic on Test Port 2 and manually examine multicast source addresses of the captured packets to ensure traffic from all sources are indeed getting thru the DUT. 8. Increase the sending rate on Test Port 1 and observe that the receiving rate on Test Port 2 is increased accordingly. 9. Examine DUTs multicast routing table to ensure all multicast groups have their corresponding multicast routing entries.

Results Traffic sent from Test Port 1 should all pass through the DUT and be received by Test Port 2. You can increase the traffic rate on Test Port 1 and observe that receiving rate on Test Port 2 increases accordingly. Examine the multicast routing table on the DUT to ensure all multicast groups have corresponding multicast routing entries.

Figure 23. Receiving rate on Port 2 matches sending rate on Port 1

20 Copyright Ixia, 2005

Multicast Test Plan

Figure 24. Increase the sending rate and observe the receiving rate matches accordingly

Figure 25. DUT shows multicast routing entries for all multicast groups

3.2

PIM-SM Last Hop Router (LHR) Functionality Test

Objective To ensure that when the DUT is acting as a Last Hop Router(LHR) it will initiate new PIM Join requests to the RP router when new clients are registering either to a new group or to an existing group via an IGMP message. Ensure multicast traffic can reach the clients successfully.

21 Copyright Ixia, 2005

Multicast Test Plan

Setup A minimum of two test ports are required for the test. One port emulates receivers that are requesting to join new groups and the other port emulates the FHR router, as well as the multicast sources behind the FHR. In addition to acting as the LHR, the DUT can also function as an RP in this configuration. Ixias IxRouter can be used to execute this test.

Figure 26. Setup for testing LHR Input Parameters Parameter IGP Protocol Description IGP protocols used by the FHR to communicate reachability of all multicast sources to the RP router (OSPF or ISIS) RP address DUT RP address # of Emulated Routers at Source port Number of FHR emulated by the source port Source Addr count Number of sources that are generating multicast traffic # of Receivers Number of receivers # of Groups and Starting Group Addr Number of groups requested by all receivers and the starting group address Table 8. Test input parameters for testing an LHR

Methodology 1. Configure Test Port 1 to emulate a few FHRs and multiple sources behind each emulated FHR. . Select the right IGP for the FHR (OSPF or ISIS) to communicate the location of each source to the DUT. 3. Enable multicast routing on the DUT and configure the DUT as RP router. Make sure the RP address is referenced correctly in the setup of Test Port 1. 4. Configure Test Port 2 as the receiver. Select IGMP as the receiver protocol so no LHRs are emulated. The DUT will function as both the RP and LHR in this case. Ensure that
22 Copyright Ixia, 2005 Multicast Test Plan

multicast group addresses entered match the group addresses set on Test Port 1. 5. Start protocol emulation on all interfaces involved. Ensure all protocols (IGMP, PIM-SM/ SSM, OSPF) are entering stable state. 6. Configure the traffic source to send multicast traffic with predefined sources. Ensure traffic from all sources on Test Port 1 can successfully pass through the DUT and be received by Test Port 2. This can be done by checking Test Port 2s receiving rate with respect to the sending rate on Test Port 1. 7. Capture traffic on Test Port 2 and manually examine source addresses of the captured packets to ensure traffic from all sources are indeed getting through the DUT. 8. Increase the sending rate on Test Port 1 to observe that the receiving rate on Test Port 2 is increased accordingly. 9. Examine DUTs multicast routing table to ensure all multicast groups have corresponding multicast routing entries.

Results Traffic sent from Test Port 1 should all pass through the DUT and be received by Test Port 2. Increase traffic rate on Test Port 1 and observe that the receiving rate on Test Port 2 increases accordingly. Examine the multicast routing table on the DUT to ensure all multicast groups have corresponding multicast routing entries.

Figure 27. Receiving rate on Port 2 matches sending rate on Port 1

23 Copyright Ixia, 2005

Multicast Test Plan

Figure 28. Increase the sending rate and observe the receiving rate matches accordingly

Figure 29. DUT shows multicast routing entries for all multicast groups

3.3

PIM-SM First Hop Router (FHR) Functionality Test

Objective To ensure that when the DUT is acting as the First Hop Route (FHR), it will deliver the multicast source traffic to the RP router in an encapsulated register message, and will subsequently send multicast traffic in its native format after receiving a register-stop from the RP router. Setup A minimum of two test ports are required to perform this test. One port emulates the RP router, LHR, and multiple receivers behind the LHR. The other port is simply emulating a multicast source that sends continuous multicast traffic to the DUT that acts as the FHR. Ixias IxRouter can be used for this test.
24 Copyright Ixia, 2005 Multicast Test Plan

Figure 30. Test Setup for Testing FHR Input Parameters Parameter IGP Protocol RP address Source Addr # of Groups and Starting Group Addr Description IGP protocols used by the FHR to communicate reachability of all multicast sources to the RP router (OSPF or ISIS) Tester port 2 RP address Multicast Source address emulated by tester Port 1 Number of groups requested by all receivers and the starting group address

Table 9. Test input parameters for testing a FHR Methodology 1. Configure Test Port 2 to emulate the RP, LHR, and multicast receivers behind the LHR. . Enable multicast routing on the DUT, and configure the DUTs RP address to point to the emulated RP address on Test Port 2. 3. Enable OSPF (or ISIS) on both the DUT and Test Port 1 and make sure the emulated RP is ping-able from the DUT. 4. Configure Test Port 1 to send multicast traffic at a low frame rate. This is to ensure that the capture buffer has sufficient space to capture control messages during register and register stop transition. 5. Ensure IP source address can be reachable by IGP protocol and the destination address is the multicast group address. The destination MAC address needs to be in the format of 01 00 5E xx xx xx where the last three bytes corresponds to the lower 23 bits value of the multicast group address. 6. Start protocol emulation on all interfaces involved. Ensure all protocols (PIM-SM/SSM, OSPF) are entering stable state.

25 Copyright Ixia, 2005

Multicast Test Plan

7. Start capturing traffic on Test Port 2 to ensure that all the protocol transition messages are captured during the next test steps. By default, the multicast join request from the emulated LHR will be (*,G) format. 8. Configure Test Port 2 such that it will automatically send register-stop message to the FHR (DUT) either after a pre-defined number of register packets being received or when a certain time interval has expired. 9. View the captured data with a protocol analyzer to examine protocols messages during the register and register-stop transition. 10.Increase number of groups and number of sources and observe the same protocols messages occur for all groups and sources.

Results As shown in the following Ethereal capture, multicast traffic was initially sent in an encapsulated format by the DUT via the unicast register message, and then sent in a multicast native format as soon as it received a register-stop message from the tester.

Figure 31. DUT sends multicast traffic in native format as soon as receiving register-stop

3.4

PIM-SM Reverse Path Forwarding (RPF) Functionality Test

Objective To ensure that the RPF is functioning correctly in delivering multicast traffic. Multicast traffic coming from a port that is NOT used to deliver unicast traffic back to the source address as seen by IGP (OSPF or ISIS) should not be forwarded to the receiver.

26 Copyright Ixia, 2005

Multicast Test Plan

Setup A minimum of 3 test ports are required to perform this test. Test Port 3 emulates IGMP clients that will join a number of multicast groups. Both Test Port 1 and Test Port 2 are used to emulate FHRs and various distinct multicast sources behind them. All sources will generate traffic towards all multicast groups in a full-mesh manner. Ixias IxRouter can be used to perform this test.

Figure 32. Setup for Testing RPF Algorithm Input Parameters Parameter Receiver Multicast Protocol Description Either PIM-SM or IGMP to emulate clients with or without LHRs. In the case of no LHR, DUT will act as RP as well as LHR. IGP Protocol IGP protocols used by the FHR to communicate reachability of all multicast sources to the RP router (OSPF or ISIS) RP address DUT RP address # of Emulated Routers at Source port Number of FHR emulated by the source port Source Addr count Number of sources that are generating multicast traffic # of Emulated routers at Receiver Number of LHR emulated by the receiver port when port PIM-SM/SSM is used as receiver protocol # of Groups and Starting Group Addr Number of groups requested by all receivers and the starting group address Table 10. Test input parameters for testing RPF algorithm Methodology 1. Configure Test Port 1 and Test Port 2 such that each port emulates a few FHRs and multiple sources behind them. . Select the right IGP for the FHR (OSPF or ISIS) to communicate the location of each source to the DUT.
27 Copyright Ixia, 2005 Multicast Test Plan

3. Enable multicast routing on the DUT and configure the DUT as RP router. Make sure the RP address is referenced correctly in the setup of both Test Port 1 and Test Port 2. 4. Configure Test Port 3 as the receiver. Select the right receiver protocols (e.g., IGMP or PIMSM/SSM). Ensure that the multicast group addresses entered match the group addresses set on both Test Port 1 and Test Port 2. 5. Start protocol emulation on all interfaces involved. Ensure all protocols (e.g., IGMP, PIMSM/SSM, OSPF) are entering stable state. 6. Configure traffic source to send multicast traffic with predefined sources. Ensure traffic from all sources on both Test Port 1 and Test Port 2 can successfully pass through the DUT and be received by Test Port 3. This can be done by checking Test Port 3s receiving rate with respect to the sending rate on both Test Port 1 and Test Port 2. Also, capture traffic on Test Port 3 and manually examine source addresses of the captured packets to ensure traffic from all sources are indeed getting thru the DUT. 7. Swap traffic source on Test Port 1 and Test Port 2. Notice that no traffic should be passed through the DUT and Test Port 3 should report count of zero. These packets are considered as coming from the wrong port and are being discarded by DUT per the RPF algorithm. 8. Now only swap partial source addresses on Test Port 1 and Test Port 2. Notice that DUT should forward the traffic with correct source address and discard those that have wrong addresses. Traffic received on Test Port 3 should be proportional to the ratio of correct sources in Test Port 1 and Test Port 2.

Results The DUT should pass 100 percent, 0 percent, or partial traffic when the multicast sources are correct (i.e., not swapped), totally swapped, or partially swapped respectively per the RPF algorithm. In this example, 100 frames-per-second is generated on both Test Port 1 and Test Port 2. Test Port 3 received 200 frames-per-second when sources are correct, i.e., not swapped as shown in Figure 33; 0 frames-per-second are received when sources are totally swapped as shown in Figure 34; and 50 frames-per-second each are received when half of the sources are swapped in Test Port 1 or Test Port 2 as shown in Figure 35 and Figure 36, respectively.

28 Copyright Ixia, 2005

Multicast Test Plan

Figure 33. Traffic with correct source addresses are all going through DUT

Figure 34. No traffic is going thru DUT when source addresses are totally swapped

29 Copyright Ixia, 2005

Multicast Test Plan

Figure 35. 50% traffic is going through when half of the sources are swapped at Port 1

Figure 36. 50% traffic is going through when half of the sources are swapped at Port 2

3.5 PIM-SM Rendezvous Point Tree (RPT) to Shortest Path Tree (SPT) Switchover Functionality Test
Objective To ensure that the DUT can construct both RPT and SPT based on source and receiver location, and that the DUT can switch traffic over from RPT to SPT once the SPT is constructed. Setup A minimum of three test ports are required for this test. Test Port 1 will simulate a few FHRs with a better path to the multicast source while Test Port 2 will simulate a RP router and a few FHRs with a less-than-optimal path to the same multicast source. Test Port 3
30 Copyright Ixia, 2005 Multicast Test Plan

will simulate LHRs and multicast receivers. The DUT act as a regular multicast router that participates as both an RPT and SPT in delivering multicast traffic. IxRouter can be used to execute this test.

Figure 37. Test setup for testing RPT to SPT switchover Input Parameters Parameter IGP Protocol Description IGP protocols used by the FHR to communicate reachability of multicast sources to the RP router (OSPF or ISIS) IGP cost metric OSPF or ISIS metric to determine optimal vs. lessthan-optimal path RP address RP address emulated by Test Port 2 # of Emulated Routers at Source port Number of FHR emulated by the source port Source Addr count Number of sources that are generating multicast traffic LHR Join/Prune Options Sending (S,G) vs. (*,G) by sending (S,G) join request, it will force DUT to switch from RPT to SPT # of Groups and Starting Group Addr Number of groups requested by all receivers and the starting group address Table 11. Test input parameters for testing RPT to SPT switchover Methodology 1. Configure both Test Port 1 and Test Port 2 as OSPF and PIM-SM/SSM capable. . Set both ports to generate traffic from exactly the same multicast source(s) to exactly the same multicast groups. Test Port 1 will be generating for example 100 frames per second while Port 2 is generating at 200 frames per second. 3. Configure the OSPF route(s) to the multicast source(s) on Test Port 1 to have less metric than the same routes on Test Port 2 as shown below.

31 Copyright Ixia, 2005

Multicast Test Plan

4. Configure the DUT to reference Test Port 2 as the RP router. Multicast traffic will initially flow from source to the DUT via Test Port 2 (RPT) and reach the receivers. On switching from RPT to SPT, multicast traffic should flow instead from Test Port 1 to reach the receivers. 5. Set Test Port 3 to emulate LHR and a few receivers behind it. 6. Configure the group Join/Prune option to send (*,G) initially. Make sure multicast traffic can initially flow from source to receiver successfully. Then force the LHR to send a (*,G) -> (S,G) request and ensure the S value matches the multicast source. This should trigger the DUT to switch from RPT to SPT and multicast traffic should flow from Test Port 1 at this point, as evidenced by its lower sending rate. 7. Optionally, you can configure the LHR (emulated by Test Port 3) to send source specific join request at all time. Traffic will initially flow via RPT for a short period of time but should quickly switch to SPT as soon as the DUT finished the construction of both RPT and SPT. Again, the way verify that traffic is through SPT or RPT to reach the receivers is by observing the traffic rate. 8. Scale the test by adding more multicast sources, or by increasing number of multicast groups/receivers. In order to benchmark switchover performance, measurement of the variation of latency over time is required. This type of measurement provides historical timestamps per packet group during the sampling interval. Care must be taken to assign the sampling interval so that the user has sufficient time to react and cause RPT to SPT switchover. Ensure the switchover is occurring within the measuring duration. A latency-based measurement provides much more accurate results than packet loss based methods. To get an accurate measurement of switchover time, locate the first timestamp where a mixture of packets start to appear (i.e., the receiver sees traffic from both sources - an indication of start of switchover) and find the last timestamp where a single packet group re-appears (i.e., completion of switchover).

Results When PIM-SM and OSPF are first started, multicast traffic immediately follows the RPT path (e.g., 200 frames per second). After manually triggering the LHR to send source specific join requests to the DUT, traffic will follow the SPT path as evidenced by the lower rate (100 frames per second). A brief disruption of traffic is due to temporary disabling of (*,G) join requests and the re-enabling of (S,G) join requests on the LHR.

32 Copyright Ixia, 2005

Multicast Test Plan

Figure 38. Manually Trigger RPT->SPT Switchover When the LHR (emulated by Test Port 3) is constantly sending source specific join requests from the beginning, the DUT switches to SPT as soon as it is constructed. Traffic initially follows the RPT path until the switchover to the SPT.

Figure 39. Switchover occurs as soon as the SPT is constructed When configured with 1000 multicast groups, the DUT shows latency in switchover from RPT to SPT. During this time, traffic from both sources is passing through the DUT and being received by the receiver.

33 Copyright Ixia, 2005

Multicast Test Plan

Figure 40. DUT shows latency in switchover when configured with large number of multicast groups When history timestamps shows a mixture of Packet Group ID (PGID) (a unique identifier of traffic source), its an indication of the start of a switchover. Record the timestamp in hex value with 20ns resolution.

Figure 41. Latency bin shows a mixture of traffic from both sources start of switchover process When history timestamps shows single PGID, its an indication of the completion of a switchover. Record the timestamp again. In this example, the switchover time is simply the difference between the two timestamps in hex value and multiplied by 20ns resolution, which yields 989 ms.

34 Copyright Ixia, 2005

Multicast Test Plan

Figure 42. Latency bin shows traffic from second source only completion of switchover

35 Copyright Ixia, 2005

Multicast Test Plan

You might also like