From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3918.txt | 1739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1739 insertions(+) create mode 100644 doc/rfc/rfc3918.txt (limited to 'doc/rfc/rfc3918.txt') diff --git a/doc/rfc/rfc3918.txt b/doc/rfc/rfc3918.txt new file mode 100644 index 0000000..ac30af5 --- /dev/null +++ b/doc/rfc/rfc3918.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group D. Stopp +Request for Comments: 3918 Ixia +Category: Informational B. Hickman + Spirent Communications + October 2004 + + + Methodology for IP Multicast Benchmarking + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + The purpose of this document is to describe methodology specific to + the benchmarking of multicast IP forwarding devices. It builds upon + the tenets set forth in RFC 2544, RFC 2432 and other IETF + Benchmarking Methodology Working Group (BMWG) efforts. This document + seeks to extend these efforts to the multicast paradigm. + + The BMWG produces two major classes of documents: Benchmarking + Terminology documents and Benchmarking Methodology documents. The + Terminology documents present the benchmarks and other related terms. + The Methodology documents define the procedures required to collect + the benchmarks cited in the corresponding Terminology documents. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Key Words to Reflect Requirements. . . . . . . . . . . . . . . 3 + 3. Test Set Up. . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Test Considerations. . . . . . . . . . . . . . . . . . . 4 + 3.1.1. IGMP Support. . . . . . . . . . . . . . . . . . . 5 + 3.1.2. Group Addresses . . . . . . . . . . . . . . . . . 5 + 3.1.3. Frame Sizes . . . . . . . . . . . . . . . . . . . 5 + 3.1.4. TTL . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.5. Trial Duration. . . . . . . . . . . . . . . . . . 6 + 4. Forwarding and Throughput. . . . . . . . . . . . . . . . . . . 6 + 4.1. Mixed Class Throughput . . . . . . . . . . . . . . . . . 6 + 4.2. Scaled Group Forwarding Matrix . . . . . . . . . . . . . 8 + 4.3. Aggregated Multicast Throughput. . . . . . . . . . . . . 9 + + + +Stopp & Hickman Informational [Page 1] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + 4.4. Encapsulation/Decapsulation (Tunneling) Throughput . . . 10 + 4.4.1. Encapsulation Throughput. . . . . . . . . . . . . 10 + 4.4.2. Decapsulation Throughput. . . . . . . . . . . . . 12 + 4.4.3. Re-encapsulation Throughput . . . . . . . . . . . 14 + 5. Forwarding Latency . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. Multicast Latency. . . . . . . . . . . . . . . . . . . . 16 + 5.2. Min/Max Multicast Latency. . . . . . . . . . . . . . . . 18 + 6. Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.1. Group Join Delay . . . . . . . . . . . . . . . . . . . . 20 + 6.2. Group Leave Delay. . . . . . . . . . . . . . . . . . . . 22 + 7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 7.1. Multicast Group Capacity . . . . . . . . . . . . . . . . 24 + 8. Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 8.1. Forwarding Burdened Multicast Latency. . . . . . . . . . 25 + 8.2. Forwarding Burdened Group Join Delay . . . . . . . . . . 27 + 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 28 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 11. Contributions. . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 12.2. Informative References . . . . . . . . . . . . . . . . . 29 + 13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31 + +1. Introduction + + This document defines tests for measuring and reporting the + throughput, forwarding, latency and Internet Group Management + Protocol (IGMP) group membership characteristics of devices that + support IP multicast protocols. The results of these tests will + provide the user with meaningful data on multicast performance. + + A previous document, "Terminology for IP Multicast Benchmarking" + [Du98], defined many of the terms that are used in this document. + The terminology document should be consulted before attempting to + make use of this document. + + This methodology will focus on one source to many destinations, + although many of the tests described may be extended to use multiple + source to multiple destination topologies. + + Subsequent documents may address IPv6 multicast and related multicast + routing protocol performance. Additional insight on IP and multicast + networking can be found in [Hu95], [Ka98] and [Mt98]. + + + + + + + +Stopp & Hickman Informational [Page 2] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + +2. Key Words to Reflect Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 + [Br97]. RFC 2119 defines the use of these key words to help make the + intent of standards track documents as clear as possible. While this + document uses these keywords, this document is not a standards track + document. + +3. Test set up + + The set of methodologies presented in this document are for single + ingress, multiple egress multicast scenarios as exemplified by + Figures 1 and 2. Methodologies for multiple ingress and multiple + egress multicast scenarios are beyond the scope of this document. + + Figure 1 shows a typical setup for an IP multicast test, with one + source to multiple destinations. + + +------------+ +--------------+ + | | | destination | + +--------+ | Egress(-)------->| test | + | source | | | | port(E1) | + | test |------>(|)Ingress | +--------------+ + | port | | | +--------------+ + +--------+ | Egress(-)------->| destination | + | | | test | + | | | port(E2) | + | DUT | +--------------+ + | | . . . + | | +--------------+ + | | | destination | + | Egress(-)------->| test | + | | | port(En) | + +------------+ +--------------+ + + Figure 1 + + If the multicast metrics are to be taken across multiple devices + forming a System Under Test (SUT), then test frames are offered to a + single ingress interface on a device of the SUT, subsequently + forwarded across the SUT topology, and finally forwarded to the test + apparatus' frame-receiving components by the test egress interface(s) + of devices in the SUT. Figure 2 offers an example SUT test topology. + If a SUT is tested, the test topology and all relevant configuration + details MUST be disclosed with the corresponding test results. + + + + +Stopp & Hickman Informational [Page 3] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + *-----------------------------------------* + | | + +--------+ | +----------------+ | +--------+ + | | | +------------+ |DUT B Egress E0(-)-|->| | + | | | |DUT A |--->| | | | | + | source | | | | | Egress E1(-)-|->| dest. | + | test |--|->(-)Ingress, I | +----------------+ | | test | + | port | | | | +----------------+ | | port | + | | | | |--->|DUT C Egress E2(-)-|->| | + | | | +------------+ | | | | | + | | | | Egress En(-)-|->| | + +--------+ | +----------------+ | +--------+ + | | + *------------------SUT--------------------* + + Figure 2 + + Generally, the destination test ports first join the desired number + of multicast groups by sending IGMP Group Report messages to the + DUT/SUT. To verify that all destination test ports successfully + joined the appropriate groups, the source test port MUST transmit IP + multicast frames destined for these groups. After test completion, + the destination test ports MAY send IGMP Leave Group messages to + clear the IGMP table of the DUT/SUT. + + In addition, test equipment MUST validate the correct and proper + forwarding actions of the devices they test in order to ensure the + receipt of the frames that are involved in the test. + +3.1. Test Considerations + + The methodology assumes a uniform medium topology. Issues regarding + mixed transmission media, such as speed mismatch, headers + differences, etc., are not specifically addressed. Flow control, QoS + and other non-essential traffic or traffic-affecting mechanisms + affecting the variable under test MUST be disabled. Modifications to + the collection procedures might need to be made to accommodate the + transmission media actually tested. These accommodations MUST be + presented with the test results. + + An actual flow of test traffic MAY be required to prime related + mechanisms, (e.g., process RPF events, build device caches, etc.) to + optimally forward subsequent traffic. Therefore, prior to running + any tests that require forwarding of multicast or unicast packets, + the test apparatus MUST generate test traffic utilizing the same + addressing characteristics to the DUT/SUT that will subsequently be + + + + + +Stopp & Hickman Informational [Page 4] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + used to measure the DUT/SUT response. The test monitor should ensure + the correct forwarding of traffic by the DUT/SUT. The priming action + need only be repeated to keep the associated information current. + + It is the intent of this memo to provide the methodology for basic + characterizations regarding the forwarding of multicast packets by a + device or simple system of devices. These characterizations may be + useful in illustrating the impact of device architectural features + (e.g., message passing versus shared memory; handling multicast + traffic as an exception by the general purpose processor versus the + by a primary data path, etc.) in the forwarding of multicast traffic. + + It has been noted that the formation of the multicast distribution + tree may be a significant component of multicast performance. While + this component may be present in some of the measurements or + scenarios presented in this memo, this memo does not seek to + explicitly benchmark the formation of the multicast distribution + tree. The benchmarking of the multicast distribution tree formation + is left as future, more targeted work specific to a given tree + formation vehicle. + +3.1.1. IGMP Support + + All of the ingress and egress interfaces MUST support a version of + IGMP. The IGMP version on the ingress interface MUST be the same + version of IGMP that is being tested on the egress interfaces. + + Each of the ingress and egress interfaces SHOULD be able to respond + to IGMP queries during the test. + + Each of the ingress and egress interfaces SHOULD also send LEAVE + (running IGMP version 2 or later) [Ca02] [Fe97] after each test. + +3.1.2. Group Addresses + + There is no restriction to the use of multicast addresses [De89] to + compose the test traffic other than those assignments imposed by + IANA. The IANA assignments for multicast addresses [IANA1] MUST be + regarded for operational consistency. Address selection does not + need to be restricted to Administratively Scoped IP Multicast + addresses [Me98]. + +3.1.3. Frame Sizes + + Each test SHOULD be run with different multicast frame sizes. For + Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280, + and 1518 byte frames. + + + + +Stopp & Hickman Informational [Page 5] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Other link layer technologies MAY be used. The minimum and maximum + frame lengths of the link layer technology in use SHOULD be tested. + + When testing with different frame sizes, the DUT/SUT configuration + MUST remain the same. + +3.1.4. TTL + + The data plane test traffic should have a TTL value large enough to + traverse the DUT/SUT. + + The TTL in IGMP control plane messages MUST be in compliance with the + version of IGMP in use. + +3.1.5. Trial Duration + + The duration of the test portion of each trial SHOULD be at least 30 + seconds. This parameter MUST be included as part of the results + reporting for each methodology. + +4. Forwarding and Throughput + + This section contains the description of the tests that are related + to the characterization of the frame forwarding of a DUT/SUT in a + multicast environment. Some metrics extend the concept of throughput + presented in RFC 1242. Forwarding Rate is cited in RFC 2285 [Ma98]. + +4.1. Mixed Class Throughput + + Objective: + + To determine the throughput of a DUT/SUT when both unicast class + frames and multicast class frames are offered simultaneously to a + fixed number of interfaces as defined in RFC 2432. + + Procedure: + + Multicast and unicast traffic are mixed together in the same + aggregated traffic stream in order to simulate a heterogeneous + networking environment. + + The following events MUST occur before offering test traffic: + + o All destination test ports configured to receive multicast + traffic MUST join all configured multicast groups; + o The DUT/SUT MUST learn the appropriate unicast and + multicast addresses; and + + + + +Stopp & Hickman Informational [Page 6] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + o Group membership and unicast address learning MUST be + verified through some externally observable method. + + The intended load [Ma98] SHOULD be configured as alternating + multicast class frames and unicast class frames to a single ingress + interface. The unicast class frames MUST be configured to transmit + in an unweighted round-robin fashion to all of the destination ports. + + For example, with six multicast groups and 3 destination ports with + one unicast addresses per port, the source test port will offer + frames in the following order: + + m1 u1 m2 u2 m3 u3 m4 u1 m5 u2 m6 u3 m1 ... + + Where: + + m = Multicast Frame + u = Unicast Frame + + Mixed class throughput measurement is defined in RFC 2432 [Du98]. A + search algorithm MUST be utilized to determine the Mixed Class + Throughput. The ratio of unicast to multicast frames MUST remain the + same when varying the intended load. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Total number of multicast groups + o Traffic distribution for unicast and multicast traffic + classes + o The ratio of multicast to unicast class traffic + + The following results MUST be reflected in the test report: + + o Mixed Class Throughput as defined in RFC 2432 [Du98], + including: Throughput per unicast and multicast traffic + classes. + + + + + + + + +Stopp & Hickman Informational [Page 7] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The Mixed Class Throughput results for each test SHOULD be reported + in the form of a table with a row for each of the tested frame sizes + per the recommendations in section 3.1.3. Each row SHOULD specify + the intended load, number of multicast frames offered, number of + unicast frames offered and measured throughput per class. + +4.2. Scaled Group Forwarding Matrix + + Objective: + + To determine Forwarding Rate as a function of tested multicast groups + for a fixed number of tested DUT/SUT ports. + + Procedure: + + This is an iterative procedure. The destination test port(s) MUST + join an initial number of multicast groups on the first iteration. + All destination test ports configured to receive multicast traffic + MUST join all configured multicast groups. The recommended number of + groups to join on the first iteration is 10 groups. Multicast + traffic is subsequently transmitted to all groups joined on this + iteration and the forwarding rate is measured. + + The number of multicast groups joined by each destination test port + is then incremented, or scaled, by an additional number of multicast + groups. The recommended granularity of additional groups to join per + iteration is 10, although the tester MAY choose a finer granularity. + Multicast traffic is subsequently transmitted to all groups joined + during this iteration and the forwarding rate is measured. + + The total number of multicast groups joined MUST not exceed the + multicast group capacity of the DUT/SUT. The Group Capacity (Section + 7.1) results MUST be known prior to running this test. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + + The following results MUST be reflected in the test report: + + o The total number of multicast groups joined for that + iteration + + + +Stopp & Hickman Informational [Page 8] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + o Forwarding rate determined for that iteration + + The Scaled Group Forwarding results for each test SHOULD be reported + in the form of a table with a row representing each iteration of the + test. Each row or iteration SHOULD specify the total number of + groups joined for that iteration, offered load, total number of + frames transmitted, total number of frames received and the aggregate + forwarding rate determined for that iteration. + +4.3. Aggregated Multicast Throughput + + Objective: + + To determine the maximum rate at which none of the offered frames to + be forwarded through N destination interfaces of the same multicast + groups are dropped. + + Procedure: + + Offer multicast traffic at an initial maximum offered load to a fixed + set of interfaces with a fixed number of groups at a fixed frame + length for a fixed duration of time. All destination test ports MUST + join all specified multicast groups. + + If any frame loss is detected, the offered load is decreased and the + sender will transmit again. An iterative search algorithm MUST be + utilized to determine the maximum offered frame rate with a zero + frame loss. + + Each iteration will involve varying the offered load of the multicast + traffic, while keeping the set of interfaces, number of multicast + groups, frame length and test duration fixed, until the maximum rate + at which none of the offered frames are dropped is determined. + + Parameters to be measured MUST include the maximum offered load at + which no frame loss occurred. Other offered loads MAY be measured + for diagnostic purposes. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Total number of multicast groups + + + +Stopp & Hickman Informational [Page 9] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + + The following results MUST be reflected in the test report: + + o Aggregated Multicast Throughput as defined in RFC 2432 + [Du98] + + The Aggregated Multicast Throughput results SHOULD be reported in the + format of a table with a row for each of the tested frame sizes per + the recommendations in section 3.1.3. Each row or iteration SHOULD + specify offered load, total number of offered frames and the measured + Aggregated Multicast Throughput. + +4.4. Encapsulation/Decapsulation (Tunneling) Throughput + + This sub-section provides the description of tests related to the + determination of throughput measurements when a DUT/SUT or a set of + DUTs are acting as tunnel endpoints. + + For this specific testing scenario, encapsulation or tunneling refers + to a packet that contains an unsupported protocol feature in a format + that is supported by the DUT/SUT. + +4.4.1. Encapsulation Throughput + + Objective: + + To determine the maximum rate at which frames offered to one ingress + interface of a DUT/SUT are encapsulated and correctly forwarded on + one or more egress interfaces of the DUT/SUT without loss. + + Procedure: + + Source DUT/SUT Destination + Test Port Test Port(s) + +---------+ +-----------+ +---------+ + | | | | | | + | | | Egress|--(Tunnel)-->| | + | | | | | | + | |------->|Ingress | | | + | | | | | | + | | | Egress|--(Tunnel)-->| | + | | | | | | + +---------+ +-----------+ +---------+ + + Figure 3 + + + + + + +Stopp & Hickman Informational [Page 10] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Figure 3 shows the setup for testing the encapsulation throughput of + the DUT/SUT. One or more tunnels are created between each egress + interface of the DUT/SUT and a destination test port. Non- + Encapsulated multicast traffic will then be offered by the source + test port, encapsulated by the DUT/SUT and forwarded to the + destination test port(s). + + The DUT/SUT SHOULD be configured such that the traffic across each + egress interface will consist of either: + + a) A single tunnel encapsulating one or more multicast address + groups OR + b) Multiple tunnels, each encapsulating one or more multicast + address groups. + + The number of multicast groups per tunnel MUST be the same when the + DUT/SUT is configured in a multiple tunnel configuration. In + addition, it is RECOMMENDED to test with the same number of tunnels + on each egress interface. All destination test ports MUST join all + multicast group addresses offered by the source test port. Each + egress interface MUST be configured with the same MTU. + + Note: when offering large frames sizes, the encapsulation process may + require the DUT/SUT to fragment the IP datagrams prior to being + forwarded on the egress interface. It is RECOMMENDED to limit the + offered frame size such that no fragmentation is required by the + DUT/SUT. + + A search algorithm MUST be utilized to determine the encapsulation + throughput as defined in [Du98]. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Total number of multicast groups + o MTU size of DUT/SUT interfaces + o Originating un-encapsulated frame size + o Number of tunnels per egress interface + o Number of multicast groups per tunnel + o Encapsulation algorithm or format used to tunnel the + packets + + + + + +Stopp & Hickman Informational [Page 11] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The following results MUST be reflected in the test report: + + o Measured Encapsulated Throughput as defined in RFC 2432 + [Du98] + o Encapsulated frame size + + The Encapsulated Throughput results SHOULD be reported in the form of + a table and specific to this test there SHOULD be rows for each + originating un-encapsulated frame size. Each row or iteration SHOULD + specify the offered load, encapsulation method, encapsulated frame + size, total number of offered frames, and the encapsulation + throughput. + +4.4.2. Decapsulation Throughput + + Objective: + + To determine the maximum rate at which frames offered to one ingress + interface of a DUT/SUT are decapsulated and correctly forwarded by + the DUT/SUT on one or more egress interfaces without loss. + + Procedure: + + Source DUT/SUT Destination + Test Port Test Port(s) + +---------+ +-----------+ +---------+ + | | | | | | + | | | Egress|------->| | + | | | | | | + | |--(Tunnel)-->|Ingress | | | + | | | | | | + | | | Egress|------->| | + | | | | | | + +---------+ +-----------+ +---------+ + + Figure 4 + + Figure 4 shows the setup for testing the decapsulation throughput of + the DUT/SUT. One or more tunnels are created between the source test + port and the DUT/SUT. Encapsulated multicast traffic will then be + offered by the source test port, decapsulated by the DUT/SUT and + forwarded to the destination test port(s). + + + + + + + + + +Stopp & Hickman Informational [Page 12] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The DUT/SUT SHOULD be configured such that the traffic across the + ingress interface will consist of either: + + a) A single tunnel encapsulating one or more multicast address + groups OR + b) Multiple tunnels, each encapsulating one or more multicast + address groups. + + The number of multicast groups per tunnel MUST be the same when the + DUT/SUT is configured in a multiple tunnel configuration. All + destination test ports MUST join all multicast group addresses + offered by the source test port. Each egress interface MUST be + configured with the same MTU. + + A search algorithm MUST be utilized to determine the decapsulation + throughput as defined in [Du98]. + + When making performance comparisons between the encapsulation and + decapsulation process of the DUT/SUT, the offered frame sizes SHOULD + reflect the encapsulated frame sizes reported in the encapsulation + test (See section 4.4.1) in place of those noted in section 3.1.3. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Total number of multicast groups + o Originating encapsulation algorithm or format used to + tunnel the packets + o Originating encapsulated frame size + o Number of tunnels + o Number of multicast groups per tunnel + + The following results MUST be reflected in the test report: + + o Measured Decapsulated Throughput as defined in RFC 2432 + [Du98] + o Decapsulated frame size + + The Decapsulated Throughput results SHOULD be reported in the format + of a table and specific to this test there SHOULD be rows for each + originating encapsulated frame size. Each row or iteration SHOULD + specify the offered load, decapsulated frame size, total number of + offered frames and the decapsulation throughput. + + + +Stopp & Hickman Informational [Page 13] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + +4.4.3. Re-encapsulation Throughput + + Objective: + + To determine the maximum rate at which frames of one encapsulated + format offered to one ingress interface of a DUT/SUT are converted to + another encapsulated format and correctly forwarded by the DUT/SUT on + one or more egress interfaces without loss. + + Procedure: + + Source DUT/SUT Destination + Test Port Test Port(s) + +---------+ +---------+ +---------+ + | | | | | | + | | | Egress|-(Tunnel)->| | + | | | | | | + | |-(Tunnel)->|Ingress | | | + | | | | | | + | | | Egress|-(Tunnel)->| | + | | | | | | + +---------+ +---------+ +---------+ + + Figure 5 + + Figure 5 shows the setup for testing the Re-encapsulation throughput + of the DUT/SUT. The source test port will offer encapsulated traffic + of one type to the DUT/SUT, which has been configured to re- + encapsulate the offered frames using a different encapsulation + format. The DUT/SUT will then forward the re-encapsulated frames to + the destination test port(s). + + The DUT/SUT SHOULD be configured such that the traffic across the + ingress and each egress interface will consist of either: + + a) A single tunnel encapsulating one or more multicast address + groups OR + b) Multiple tunnels, each encapsulating one or more multicast + address groups. + + The number of multicast groups per tunnel MUST be the same when the + DUT/SUT is configured in a multiple tunnel configuration. In + addition, the DUT/SUT SHOULD be configured such that the number of + tunnels on the ingress and each egress interface are the same. All + destination test ports MUST join all multicast group addresses + offered by the source test port. Each egress interface MUST be + configured with the same MTU. + + + + +Stopp & Hickman Informational [Page 14] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Note that when offering large frames sizes, the encapsulation process + may require the DUT/SUT to fragment the IP datagrams prior to being + forwarded on the egress interface. It is RECOMMENDED to limit the + offered frame sizes, such that no fragmentation is required by the + DUT/SUT. + + A search algorithm MUST be utilized to determine the re-encapsulation + throughput as defined in [Du98]. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Total number of multicast groups + o MTU size of DUT/SUT interfaces + o Originating encapsulation algorithm or format used to + tunnel the packets + o Re-encapsulation algorithm or format used to tunnel the + packets + o Originating encapsulated frame size + o Number of tunnels per interface + o Number of multicast groups per tunnel + + The following results MUST be reflected in the test report: + + o Measured Re-encapsulated Throughput as defined in RFC 2432 + [Du98] + o Re-encapsulated frame size + + The Re-encapsulated Throughput results SHOULD be reported in the + format of a table and specific to this test there SHOULD be rows for + each originating encapsulated frame size. Each row or iteration + SHOULD specify the offered load, Re-encapsulated frame size, total + number of offered frames, and the Re-encapsulated Throughput. + +5. Forwarding Latency + + This section presents methodologies relating to the characterization + of the forwarding latency of a DUT/SUT in a multicast environment. + It extends the concept of latency characterization presented in RFC + 2544. + + + + + + +Stopp & Hickman Informational [Page 15] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The offered load accompanying the latency-measured packet can affect + the DUT/SUT packet buffering, which may subsequently impact measured + packet latency. This SHOULD be a consideration when selecting the + intended load for the described methodologies below. + + RFC 1242 and RFC 2544 draw a distinction between device types: "store + and forward" and "bit-forwarding." Each type impacts how latency is + collected and subsequently presented. See the related RFCs for more + information. + +5.1. Multicast Latency + + Objective: + + To produce a set of multicast latency measurements from a single, + multicast ingress interface of a DUT/SUT through multiple, egress + multicast interfaces of that same DUT/SUT as provided for by the + metric "Multicast Latency" in RFC 2432 [Du98]. + + The procedures below draw from the collection methodology for latency + in RFC 2544 [Br96]. The methodology addresses two topological + scenarios: one for a single device (DUT) characterization; a second + scenario is presented or multiple device (SUT) characterization. + + Procedure: + + If the test trial is to characterize latency across a single Device + Under Test (DUT), an example test topology might take the form of + Figure 1 in section 3. That is, a single DUT with one ingress + interface receiving the multicast test traffic from frame- + transmitting component of the test apparatus and n egress interfaces + on the same DUT forwarding the multicast test traffic back to the + frame-receiving component of the test apparatus. Note that n + reflects the number of TESTED egress interfaces on the DUT actually + expected to forward the test traffic (as opposed to configured but + untested, non-forwarding interfaces, for example). + + If the multicast latencies are to be taken across multiple devices + forming a System Under Test (SUT), an example test topology might + take the form of Figure 2 in section 3. + + The trial duration SHOULD be 120 seconds to be consistent with RFC + 2544 [Br96]. The nature of the latency measurement, "store and + forward" or "bit forwarding", MUST be associated with the related + test trial(s) and disclosed in the results report. + + + + + + +Stopp & Hickman Informational [Page 16] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + A test traffic stream is presented to the DUT. It is RECOMMENDED to + offer traffic at the measured aggregated multicast throughput rate + (Section 4.3). At the mid-point of the trial's duration, the test + apparatus MUST inject a uniquely identifiable ("tagged") frame into + the test traffic frames being presented. This tagged frame will be + the basis for the latency measurements. By "uniquely identifiable", + it is meant that the test apparatus MUST be able to discern the + "tagged" frame from the other frames comprising the test traffic set. + A frame generation timestamp, Timestamp A, reflecting the completion + of the transmission of the tagged frame by the test apparatus, MUST + be determined. + + The test apparatus will monitor frames from the DUT's tested egress + interface(s) for the expected tagged frame(s) and MUST record the + time of the successful detection of a tagged frame from a tested + egress interface with a timestamp, Timestamp B. A set of Timestamp B + values MUST be collected for all tested egress interfaces of the + DUT/SUT. See RFC 1242 [Br91] for additional discussion regarding + store and forward devices and bit forwarding devices. + + A trial MUST be considered INVALID should any of the following + conditions occur in the collection of the trial data: + + o Unexpected differences between Intended Load and Offered + Load or unexpected differences between Offered Load and the + resulting Forwarding Rate(s) on the DUT/SUT egress ports. + o Forwarded test frames improperly formed or frame header + fields improperly manipulated. + o Failure to forward required tagged frame(s) on all expected + egress interfaces. + o Reception of tagged frames by the test apparatus more than + 5 seconds after the cessation of test traffic by the source + test port. + + The set of latency measurements, M, composed from each latency + measurement taken from every ingress/tested egress interface pairing + MUST be determined from a valid test trial: + + M = { (Timestamp B(E0) - Timestamp A), + (Timestamp B(E1) - Timestamp A), ... + (Timestamp B(En) - Timestamp A) } + + where (E0 ... En) represents the range of all tested egress + interfaces and Timestamp B represents a tagged frame detection event + for a given DUT/SUT tested egress interface. + + A more continuous profile MAY be built from a series of individual + measurements. + + + +Stopp & Hickman Informational [Page 17] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Offered load + o Total number of multicast groups + + The following results MUST be reflected in the test report: + + o The set of all latencies with respective time units related + to the tested ingress and each tested egress DUT/SUT + interface. + + The time units of the presented latency MUST be uniform and with + sufficient precision for the medium or media being tested. + + The results MAY be offered in a tabular format and should preserve + the relationship of latency to ingress/egress interface for each + multicast group to assist in trending across multiple trials. + +5.2. Min/Max Multicast Latency + + Objective: + + To determine the difference between the maximum latency measurement + and the minimum latency measurement from a collected set of latencies + produced by the Multicast Latency benchmark. + + Procedure: + + Collect a set of multicast latency measurements over a single test + duration, as prescribed in section 5.1. This will produce a set of + multicast latencies, M, where M is composed of individual forwarding + latencies between DUT frame ingress and DUT frame egress port pairs. + E.g.: + + M = {L(I,E1),L(I,E2), ..., L(I,En)} + + where L is the latency between a tested ingress interface, I, of the + DUT, and Ex a specific, tested multicast egress interface of the DUT. + E1 through En are unique egress interfaces on the DUT. + + + + + +Stopp & Hickman Informational [Page 18] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + From the collected multicast latency measurements in set M, identify + MAX(M), where MAX is a function that yields the largest latency value + from set M. + + Identify MIN(M), when MIN is a function that yields the smallest + latency value from set M. + + The Max/Min value is determined from the following formula: + + Result = MAX(M) - MIN(M) + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Offered load + o Total number of multicast groups + + The following results MUST be reflected in the test report: + + o The Max/Min value + + The following results SHOULD be reflected in the test report: + + o The set of all latencies with respective time units related + to the tested ingress and each tested egress DUT/SUT + interface. + + The time units of the presented latency MUST be uniform and with + sufficient precision for the medium or media being tested. + + The results MAY be offered in a tabular format and should preserve + the relationship of latency to ingress/egress interface for each + multicast group. + +6. Overhead + + This section presents methodology relating to the characterization of + the overhead delays associated with explicit operations found in + multicast environments. + + + + + + +Stopp & Hickman Informational [Page 19] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + +6.1. Group Join Delay + + Objective: + + To determine the time duration it takes a DUT/SUT to start forwarding + multicast frames from the time a successful IGMP group membership + report has been issued to the DUT/SUT. + + Procedure: + + The Multicast Group Join Delay measurement may be influenced by the + state of the Multicast Forwarding Database of the DUT/SUT. The + states of the MFDB may be described as follows: + + o State 0, where the MFDB does not contain the specified + multicast group address. In this state, the delay measurement + includes the time the DUT/SUT requires to add the address to + the MFDB and begin forwarding. Delay measured from State 0 + provides information about how the DUT/SUT is able to add new + addresses into MFDB. + + o State 1, where the MFDB does contain the specified multicast + group address. In this state, the delay measurement includes + the time the DUT/SUT requires to update the MFDB with the + newly joined node and begin forwarding to the new node + plus packet replication time. Delay measured from State 1 + provides information about how well the DUT/SUT is able to + update the MFDB for new nodes while transmitting packets to + other nodes for the same IP multicast address. Examples + include adding a new user to an event that is being promoted + via multicast packets. + + The methodology for the Multicast Group Join Delay measurement + provides two alternate methods, based on the state of the MFDB, to + measure the delay metric. The methods MAY be used independently or + in conjunction to provide meaningful insight into the DUT/SUT ability + to manage the MFDB. + + Users MAY elect to use either method to determine the Multicast Group + Join Delay; however the collection method MUST be specified as part + of the reporting format. + + In order to minimize the variation in delay calculations as well as + minimize burden on the DUT/SUT, the test SHOULD be performed with one + multicast group. In addition, all destination test ports MUST join + the specified multicast group offered to the ingress interface of the + DUT/SUT. + + + + +Stopp & Hickman Informational [Page 20] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Method A: + + Method A assumes that the Multicast Forwarding Database of the + DUT/SUT does not contain or has not learned the specified multicast + group address; specifically, the MFDB MUST be in State 0. In this + scenario, the metric represents the time the DUT/SUT takes to add the + multicast address to the MFDB and begin forwarding the multicast + packet. Only one ingress and one egress MUST be used to determine + this metric. + + Prior to sending any IGMP Group Membership Reports used to calculate + the Multicast Group Join Delay, it MUST be verified through + externally observable means that the destination test port is not + currently a member of the specified multicast group. In addition, it + MUST be verified through externally observable means that the MFDB of + the DUT/SUT does not contain the specified multicast address. + + Method B: + + Method B assumes that the MFDB of the DUT/SUT does contain the + specified multicast group address; specifically, the MFDB MUST be in + State 1. In this scenario, the metric represents the time the + DUT/SUT takes to update the MFDB with the additional nodes and their + corresponding interfaces and to begin forwarding the multicast + packet. One or more egress ports MAY be used to determine this + metric. + + Prior to sending any IGMP Group Membership Reports used to calculate + the Group Join Delay, it MUST be verified through externally + observable means that the MFDB contains the specified multicast group + address. A single un-instrumented test port MUST be used to join the + specified multicast group address prior to sending any test traffic. + This port will be used only for insuring that the MFDB has been + populated with the specified multicast group address and can + successfully forward traffic to the un-instrumented port. + + Join Delay Calculation + + Once verification is complete, multicast traffic for the specified + multicast group address MUST be offered to the ingress interface + prior to the DUT/SUT receiving any IGMP Group Membership Report + messages. It is RECOMMENDED to offer traffic at the measured + aggregated multicast throughput rate (Section 4.3). + + After the multicast traffic has been started, the destination test + port (See Figure 1) MUST send one IGMP Group Membership Report for + the specified multicast group. + + + + +Stopp & Hickman Informational [Page 21] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The join delay is the difference in time from when the IGMP Group + Membership message is sent (timestamp A) and the first frame of the + multicast group is forwarded to a receiving egress interface + (timestamp B). + + Group Join delay time = timestamp B - timestamp A + + Timestamp A MUST be the time the last bit of the IGMP group + membership report is sent from the destination test port; timestamp B + MUST be the time the first bit of the first valid multicast frame is + forwarded on the egress interface of the DUT/SUT. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o IGMP version + o Total number of multicast groups + o Offered load to ingress interface + o Method used to measure the join delay metric + + The following results MUST be reflected in the test report: + + o The group join delay time in microseconds per egress + interface(s) + + The Group Join Delay results for each test MAY be reported in the + form of a table, with a row for each of the tested frame sizes per + the recommendations in section 3.1.3. Each row or iteration MAY + specify the group join delay time per egress interface for that + iteration. + +6.2. Group Leave Delay + + Objective: + + To determine the time duration it takes a DUT/SUT to cease forwarding + multicast frames after a corresponding IGMP Leave Group message has + been successfully offered to the DUT/SUT. + + + + + + + + + +Stopp & Hickman Informational [Page 22] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Procedure: + + In order to minimize the variation in delay calculations as well as + minimize burden on the DUT/SUT, the test SHOULD be performed with one + multicast group. In addition, all destination test ports MUST join + the specified multicast group offered to the ingress interface of the + DUT/SUT. + + Prior to sending any IGMP Leave Group messages used to calculate the + group leave delay, it MUST be verified through externally observable + means that the destination test ports are currently members of the + specified multicast group. If any of the egress interfaces do not + forward validation multicast frames then the test is invalid. + + Once verification is complete, multicast traffic for the specified + multicast group address MUST be offered to the ingress interface + prior to receipt or processing of any IGMP Leave Group messages. It + is RECOMMENDED to offer traffic at the measured aggregated multicast + throughput rate (Section 4.3). + + After the multicast traffic has been started, each destination test + port (See Figure 1) MUST send one IGMP Leave Group message for the + specified multicast group. + + The leave delay is the difference in time from when the IGMP Leave + Group message is sent (timestamp A) and the last frame of the + multicast group is forwarded to a receiving egress interface + (timestamp B). + + Group Leave delay time = timestamp B - timestamp A + + Timestamp A MUST be the time the last bit of the IGMP Leave Group + message is sent from the destination test port; timestamp B MUST be + the time the last bit of the last valid multicast frame is forwarded + on the egress interface of the DUT/SUT. + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o IGMP version + o Total number of multicast groups + o Offered load to ingress interface + + + + + +Stopp & Hickman Informational [Page 23] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The following results MUST be reflected in the test report: + + o The group leave delay time in microseconds per egress + interface(s) + + The Group Leave Delay results for each test MAY be reported in the + form of a table, with a row for each of the tested frame sizes per + the recommendations in section 3.1.3. Each row or iteration MAY + specify the group leave delay time per egress interface for that + iteration. + +7. Capacity + + This section offers a procedure relating to the identification of + multicast group limits of a DUT/SUT. + +7.1. Multicast Group Capacity + + Objective: + + To determine the maximum number of multicast groups a DUT/SUT can + support while maintaining the ability to forward multicast frames to + all multicast groups registered to that DUT/SUT. + + Procedure: + + One or more destination test ports of DUT/SUT will join an initial + number of multicast groups. + + After a minimum delay as measured by section 6.1, the source test + ports MUST transmit to each group at a specified offered load. + + If at least one frame for each multicast group is forwarded properly + by the DUT/SUT on each participating egress interface, the iteration + is said to pass at the current capacity. + + For each successful iteration, each destination test port will join + an additional user-defined number of multicast groups and the test + repeats. The test stops iterating when one or more of the egress + interfaces fails to forward traffic on one or more of the configured + multicast groups. + + Once the iteration fails, the last successful iteration is the stated + Maximum Group Capacity result. + + + + + + + +Stopp & Hickman Informational [Page 24] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + Reporting Format: + + The following configuration parameters MUST be reflected in the test + report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o IGMP version + o Offered load + + The following results MUST be reflected in the test report: + + o The total number of multicast group addresses that were + successfully forwarded through the DUT/SUT + + The Multicast Group Capacity results for each test SHOULD be reported + in the form of a table, with a row for each of the tested frame sizes + per the recommendations in section 3.1.3. Each row or iteration + SHOULD specify the number of multicast groups joined per destination + interface, number of frames transmitted and number of frames received + for that iteration. + +8. Interaction + + Network forwarding devices are generally required to provide more + functionality than just the forwarding of traffic. Moreover, + network-forwarding devices may be asked to provide those functions in + a variety of environments. This section offers procedures to assist + in the characterization of DUT/SUT behavior in consideration of + potentially interacting factors. + +8.1. Forwarding Burdened Multicast Latency + + Objective: + + To produce a set of multicast latency measurements from a single + multicast ingress interface of a DUT/SUT through multiple egress + multicast interfaces of that same DUT/SUT as provided for by the + metric "Multicast Latency" in RFC 2432 [Du98] while forwarding meshed + unicast traffic. + + Procedure: + + The Multicast Latency metrics can be influenced by forcing the + DUT/SUT to perform extra processing of packets while multicast class + traffic is being forwarded for latency measurements. + + + + + +Stopp & Hickman Informational [Page 25] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The Burdened Forwarding Multicast Latency test MUST follow the + described setup for the Multicast Latency test in Section 5.1. In + addition, another set of test ports MUST be used to burden the + DUT/SUT (burdening ports). The burdening ports will be used to + transmit unicast class traffic to the DUT/SUT in a fully meshed + traffic distribution as described in RFC 2285 [Ma98]. The DUT/SUT + MUST learn the appropriate unicast addresses and verified through + some externally observable method. + + Perform a baseline measurement of Multicast Latency as described in + Section 5.1. After the baseline measurement is obtained, start + transmitting the unicast class traffic at a user-specified offered + load on the set of burdening ports and rerun the Multicast Latency + test. The offered load to the ingress port MUST be the same as was + used in the baseline measurement. + + Reporting Format: + + Similar to Section 5.1, the following configuration parameters MUST + be reflected in the test report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o Test duration + o IGMP version + o Offered load to ingress interface + o Total number of multicast groups + o Offered load to burdening ports + o Total number of burdening ports + + The following results MUST be reflected in the test report: + + o The set of all latencies related to the tested ingress and + each tested egress DUT/SUT interface for both the baseline + and burdened response. + + The time units of the presented latency MUST be uniform and with + sufficient precision for the medium or media being tested. + + The latency results for each test SHOULD be reported in the form of a + table, with a row for each of the tested frame sizes per the + recommended frame sizes in section 3.1.3, and SHOULD preserve the + relationship of latency to ingress/egress interface(s) to assist in + trending across multiple trials. + + + + + + + +Stopp & Hickman Informational [Page 26] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + +8.2. Forwarding Burdened Group Join Delay + + Objective: + + To determine the time duration it takes a DUT/SUT to start forwarding + multicast frames from the time a successful IGMP Group Membership + Report has been issued to the DUT/SUT while forwarding meshed unicast + traffic. + + Procedure: + + The Forwarding Burdened Group Join Delay test MUST follow the + described setup for the Group Join Delay test in Section 6.1. In + addition, another set of test ports MUST be used to burden the + DUT/SUT (burdening ports). The burdening ports will be used to + transmit unicast class traffic to the DUT/SUT in a fully meshed + traffic pattern as described in RFC 2285 [Ma98]. The DUT/SUT MUST + learn the appropriate unicast addresses and verified through some + externally observable method. + + Perform a baseline measurement of Group Join Delay as described in + Section 6.1. After the baseline measurement is obtained, start + transmitting the unicast class traffic at a user-specified offered + load on the set of burdening ports and rerun the Group Join Delay + test. The offered load to the ingress port MUST be the same as was + used in the baseline measurement. + + Reporting Format: + + Similar to Section 6.1, the following configuration parameters MUST + be reflected in the test report: + + o Frame size(s) + o Number of tested egress interfaces on the DUT/SUT + o IGMP version + o Offered load to ingress interface + o Total number of multicast groups + o Offered load to burdening ports + o Total number of burdening ports + o Method used to measure the join delay metric + + The following results MUST be reflected in the test report: + + o The group join delay time in microseconds per egress + interface(s) for both the baseline and burdened response. + + + + + + +Stopp & Hickman Informational [Page 27] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + The Group Join Delay results for each test MAY be reported in the + form of a table, with a row for each of the tested frame sizes per + the recommendations in section 3.1.3. Each row or iteration MAY + specify the group join delay time per egress interface, number of + frames transmitted and number of frames received for that iteration. + +9. Security Considerations + + As this document is solely for the purpose of providing metric + methodology and describes neither a protocol nor a protocol's + implementation, there are no security considerations associated with + this document specifically. Results from these methodologies may + identify a performance capability or limit of a device or system in a + particular test context. However, such results might not be + representative of the tested entity in an operational network. + +10. Acknowledgements + + The Benchmarking Methodology Working Group of the IETF and + particularly Kevin Dubray, Juniper Networks, are to be thanked for + the many suggestions they collectively made to help complete this + document. + +11. Contributions + + The authors would like to acknowledge the following individuals for + their help and participation of the compilation of this document: + Hardev Soor, Ixia, and Ralph Daniels, Spirent Communications, both + who made significant contributions to the earlier versions of this + document. In addition, the authors would like to acknowledge the + members of the task team who helped bring this document to fruition: + Michele Bustos, Tony De La Rosa, David Newman and Jerry Perser. + +12. References + +12.1. Normative References + + [Br91] Bradner, S., "Benchmarking Terminology for Network + Interconnection Devices", RFC 1242, July 1991. + + [Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, March 1999. + + [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement + Levels, RFC 2119, March 1997. + + [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC + 2432, October 1998. + + + +Stopp & Hickman Informational [Page 28] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + + [IANA1] IANA multicast address assignments, + http://www.iana.org/assignments/multicast-addresses + + [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching + Devices", RFC 2285, February 1998. + + [Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, + RFC 2365, July 1998. + +12.2. Informative References + + [Ca02] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. + + [De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, + RFC 1112, August 1989. + + [Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", + RFC 2236, November 1997. + + [Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995. + + [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to + Interactive Corporate Networks", John Wiley & Sons Inc., + 1998. + + [Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise", + Prentice-Hall, 1998. + + + + + + + + + + + + + + + + + + + + + + +Stopp & Hickman Informational [Page 29] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + +13. Authors' Addresses + + Debra Stopp + Ixia + 26601 W. Agoura Rd. + Calabasas, CA 91302 + USA + + Phone: + 1 818 871 1800 + EMail: debby@ixiacom.com + + + Brooks Hickman + Spirent Communications + 26750 Agoura Rd. + Calabasas, CA 91302 + USA + + Phone: + 1 818 676 2412 + EMail: brooks.hickman@spirentcom.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Stopp & Hickman Informational [Page 30] + +RFC 3918 Methodology for IP Multicast Benchmarking October 2004 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Stopp & Hickman Informational [Page 31] + -- cgit v1.2.3