Beruflich Dokumente
Kultur Dokumente
26601 Agoura Road, Calabasas, CA 91302 | Tel: 818.871.1800 | Fax: 818.871.1805 | www.ixiacom.com
Contents
1. 2. Introduction 1 What Is Multicast? 1
2.1 2.2 Multicast Taxonomy 1 Historical Perspective/Evolution 3 Multicast Groups 4 Multicast Addressing 5 Multicast Scope/Time-To-Live (TTL) 6 Multicast Routing 6 Multicast Distribution Trees 7 Multicast Distribution Trees 7 Dynamic Registration 7 Multicast Group Management Protocols 8 Multicast Routing Protocols 9 Why Test for Multicast Conformance? 12 Why Test for Multicast Scalability and Performance? 12 Why Test for Multicast Conformance? 12 Why Test for Multicast Scalability and Performance? 12 Optimized Hardware Platform 13 Routing Protocol Emulation 13 Integrated Control and Data Plane Testing 13 Traffic Generation 13 Automation 13 Multicast Scalability and Performance Testing 13
3.
4.
Multicast Protocols8
4.1 4.2
5.
5.
6.
7. 8. 9.
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.
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 recipientsin 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 challengesand Ixias 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 groupa 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 besteffort 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.
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.
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.
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.
Figure 5: Multicast source, routers, and receiver group, showing the network segments that form the multicast path between them as black arrows.
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.
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.
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.
10
11
12
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.
13
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.
14
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.
15
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.
16
17
9.1.3. Parameters
DUT Hostname IP First Unused Net IP Unused Net Mask IP Number Unused Nets Multicast group address Interface Entries 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. 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. An IPv4 Multicast group address to be advertised by IxANVL. A number of layer 2 and 3 entries required to enable a particular interface.
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. 2. Specify DUT capabilities and commands, typically via command scripts such as Expect scripts, if the test suite will be automated. 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.
18
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).
19
20
9.2.3. Parameters
Parameter Duration No. of Trials No. of Iterations Initial Rate Increment First Group Address Total Group Addresses Description The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. Select how many times you want to test each frame size. Specify the number of times the test increments or decrements the frame rate. The starting rate at which frames are transmitted. Specify this value as a percentage of the maximum theoretical frame rate. The percentage increase (positive value) or decrease (negative value) in the transmission rate for each iteration. IP address of the first multicast group. 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. The IGMP version to use: 1 or 2. 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. 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. Sets the IP header Send Router Alert bit in messages. Specify the frame sizes that should be tested in sequence for each iteration. The duration of the test in hours, minutes and seconds, which is used to calculate the number of frames that need to be transmitted. Select how many times you want to test each frame size. Specify the number of times the test increments or decrements the frame rate. The starting rate at which frames are transmitted. Specify this value as a percentage of the maximum theoretical frame rate. The percentage increase (positive value) or decrease (negative value) in the transmission rate for each iteration. IP address of the first multicast group. 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. The IGMP version to use: 1 or 2. 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 Enable Router Alert Frame size Duration No. of Trials No. of Iterations Initial Rate Increment First Group Address Total Group Addresses
21
9.2.4. Methodology
1. 2. 3. 4. 5. 6. 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) To simplify configuration, configure the DUTs interface IP addresses in incrementing order (i.e., 192.168.0.1/24, 192.168.1.1/24, 192.168.2.1/24, etc.) At the workstation, Launch IxScriptMate and connect to an Ixia Chassis. Expand the IP Multicast (RFC 2432) test suite, and select the latency test script. Specify the frames sizes that will be tested for each iteration or trial. Specify the source and gateway IP addresses for each interface. If the DUTs interface IP addresses are incremented by one, then simply specify the first source and gateway IP address and specify which octet to increment by. 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. Start the test. The following is a methodology summary of this test: 9. 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.
7.
8.
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 Files\Ixia\TclScripts.
22
9.2.5. Results
Latency (ns) per Multicast group, frame counts for Transmit and Receive ports, and frame loss.
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.
23
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
Parameter DHCPv6 Description 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 Can be specified manually or configured for DHCPv6 resolution Specifies if VLAN are enabled on a port and the valid range of VLAN identification Number of multicast groups available that an IPv6 host can join IPv6 Multicast group address IPv6 Network Prefix Percent of line rate for a particular Multicast group address Destination Port Diffserv Code Points for IPv6 multicast source traffic Number of simulated PCs. Default is one. Either specify all or the respective list of indices representing the various multicast groups Specify either fixed or random. If random, specify min and max number of groups Specify either fixed or random. If random, specify min and max times in seconds Specify either fixed or random. If random, specify minimum and maximum times in seconds
IPv6 interface addresses VLAN # Traffic Groups - MCast Addr - Size % Rate Dst Port DSCP Number PCs MLD Group numbers to select from Number of groups to join Delay before joining a group How long to stay in group
24
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).
25
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. 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).
6.
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.
26
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.
27
9.4.3. Parameters
Parameter Multicast Traffic Flow Multicast Group Count Description An IPv4 packet with a unicast source IPv4 address and a multicast IPv4 address. 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. By default it can be any router on port B except for the first hop router (FHR). 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. When one or more unicast IPv4 traffic flows are used to simulate heterogeneous traffic.
28
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.
29
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 PIMSM 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.
30
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
31
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)
5,000
4,500
4,000
3,000
2,500
2,000
1,500
1,000
500
0 300
400
500
600
800
900
1,000
1,100
32
Traffic Engineering
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
34