Page 1 of 1 ***************************************************************** ATM Forum/98-0410 ***************************************************************** Title: Proposed modified text for Methodology for Implementing Scalable Test Configurations ***************************************************************** Abstract: This contribution provides revised text for Appendix B on scalable configurations. ***************************************************************** Source: Arian Durresi (1), Raj Jain (1), Gojko Babic (1), and Bruce Northcote (2) ********************************************************************** Date: Portland, July 26-31, 1998 ********************************************************************** Distribution: ATM Forum Technical Working Group Members (AF-TEST, AF-TM) ********************************************************************** Notice: This contribution has been prepared to assist the ATM Forum. It is offered to the Forum as a basis for discussion and is not a binding proposal on the part of any of the contributing organizations. The statements are subject to change in form and content after further study. Specifically, the contributors reserve the right to add to, amend or modify the statements contained herein. ***************************************************************** (1)The Ohio State University Department of CIS, Columbus, OH 43210-1277 Phone: 614-292-3989, Fax: 614-292-2911, Email: Jain@ACM.Org The presentation, by these authors, of this contribution at the ATM Forum is sponsored by NASA. (2) Fujitsu Network Communications 289 Great Rd, Acton, MA 01720 Phone: 978-266-4594, Fax: 978-266-2300, Email: bsn@nexen.com In the April ‘98 ATM Forum meeting at Berlin, it was decided that all text on scalable configurations employing loopbacks should be moved from the normative text of [1] to an informative appendix. That decision is addressed in af98-0452. Also, it was agreed that there existed additional scalable configurations, other than those that employ loopbacks, that may be used to load an IUT without requiring a 1-to-1 correspondence between traffic generators and IUT ports. The purpose of this contribution is to provide a more concise text for the informative appendix on scalable configurations, and we therefore propose a revision of Appendix B in [1]. The new scalable configurations that were discussed in Berlin rely on employing the point-to-multipoint capability of an another switching system (in addition to the IUT). As such, we consider such a configuration to provide a “Parallel Traffic Replication” capability, whereas scalable configurations using loopbacks may be considered to provide a “Serial Traffic Replication” capability. This revision of Appendix B addresses these distinct configuration categories in separate sections. Appendix B of the current baseline draft [1] contains two different types of scalable configurations with loopbacks. These can be called unidirectional and bi-directional configurations, respectively. The configuration rules presented here in the section on “Serial Traffic Replication” combine the best features of both of these types of configurations and present one set of unified configurations. Motion: Replace Appendix B by the remaining text of this contribution (other than the references section and footnotes). Appendix B: Methodology for Implementing Scalable Test Configurations B.1. Introduction Throughout this appendix it is assumed, for improved readability, that the IUT consists of a single switch, although the methodologies presented here apply equally to test cases in which the IUT is a network of switches or, alternatively, a subset of modules of a single switch. The notation Pij is used to refer to the jth port of the ith module of the IUT, and (Pab, Pcd) indicates that a connection (either internal or external to the IUT) exists between Pab and Pcd. In Sections 4.1.5 and 4.2.6, a number of connection configurations have been presented for throughput and latency measurements. In most of the cases, these configurations require one traffic generator and/or analyzer for each switch port. Thus, the number of generators and/or analyzers increases as the number of ports increases. Since this equipment is rather expensive, it is desirable to define scalable configurations that can be used with a limited number of generators. However, one problem with scalable configurations is that there are many ways to set up the connections and measurement results could vary with the setup. For example, In the case of unicast, it may not be possible to overload a port with only one generator. Using two generators in scalable configurations may exhibit different behavior, such as overloading, that may not show up with one generator.1 Performance testing requires two kinds of virtual channel connections (VCCs): foreground VCCs (traffic that is measured) and background VCCs (traffic that simply interferes with the foreground traffic). The methodology for generating configurations of both types of VCCs is covered by this appendix. The VCCs are formed by setting up connections between ports of the switch. The connections are internal through the switch fabric and external through some transmission medium or wires (which could be cables, fibers, or even wireless links), depending on the port technology. In this Appendix, internal connections are shown by thin lines and external connections by thick lines. An arrow indicates the direction of the connection. If a connection is bi-directional, which is often the case, arrows are not used. It should be noted that whenever external connections are used in the test configurations, only permanent VCCs can be established.2 Two generic categories of scalable configuration are presented in this appendix, namely: 1. “Parallel Traffic Replication” configurations, discussed in Section B.2, which employ the point-to-multipoint capability of a switching system (other than the IUT) to artificially generate more traffic than is possible with a limited number of traffic generators, and 2. “Serial Traffic Replication” configurations, discussed in Section B.3, which employ external connections to serially relay traffic egressing from the IUT back in to the IUT, thereby emulating additional traffic generators. B.2. Parallel Traffic Replication The point-to-multipoint capability of a switching system is a very powerful method for traffic replication, intended primarily for broadcast communication services, but which also lends itself well to the task of generating the traffic inputs to the IUT that are required for the test configurations shown in Figure 4.2. Identical ATM cells are broadcast in parallel from multiple output ports – hence ‘parallel traffic replication’. Given a single traffic generator, and a switching system (other than the IUT) with a point-to-multipoint capability (a multicast switch), an IUT may receive traffic on as many input ports as the multicast switch has available output ports. This form of scalable configuration is depicted in Figure B.1, where G is the single traffic generator. Internal to the IUT, any of the configurations from Figure 4.2 may be used. Note that if the multicast switch does not support multipoint-to- point connections, then this form of parallel traffic replication cannot support bi-directional connection configurations. In such cases, it may be necessary to use serial traffic replication, as described in the next section. [Figure B.1. A parallel traffic replication scalable configuration B.3. Serial Traffic Replication] An example test configuration employing serial traffic replication is provided in Figure B.2, which shows a 4-port switch with ports labeled as P11, P12, P21 and P22. Of these, ports P21 and P12 are connected by a wire W1, while port P22 has a “loopback” wire LB that connects the output of the port to its input. Internally, a PVC has been set up to connect ports P11 with P21 and P12 with P22. Note that all external connections (wires) and internal connections (PVCs) in this case are bi- directional, except the loopback. During testing with this configuration, cells first enter the switch at P11 and are passed through every port of the switch in series, before looping back at P22 and following the reverse path back to exit the switch for the last time at P11. The methodology presented here has two phases. During the first phase the switch ports are connected externally by numbered wires, as in Section B.3.1. The second phase consists of setting up PVCs, i.e. internal connections between ports, as explained in Section B.3.2. The sequence of concatenated connections (internal and external) is called a VCC Chain. For example, the VCC shown in Figure B.2.b. is formed by setting up a VCC chain starting from P11-In. ATM cells flow internally from P11-In to P21-Out, externally via wire W1 to P12-In, internally to P22-Out, externally via wire LB to P22-In, internally to P12-Out, externally through wire W1 to P21-In, finally exiting at P11-Out. This VCC chain can be indicated as: Generator-P11-P21-P12-P22-P22-P12-P21-P11-Analyzer. Of these connections, P22-P22 is a unidirectional external connection (loopback, denoted as LB) and P12-P21 is a bi- directional external connection (wire, denoted as W). All of the internal connections (VCCs) are bi-directional. The sequence of external connections used in this VCC chain is: Generator-W1-LB- W1-Analyzer. Both the above notations are symmetric in the sense that the second half of the chain is a mirror image of the first half. For example, W1-LB is the mirror image of LB-W1. [ Figure B.2. A VCC chain that can implement the 4–to-4 straight configuration.] Another possible configuration for this "n-to-n single generator scalable configuration" is P11-P12-P21-P22-P22-P21-P12-P11. The various VCC chains may be distinguished by the order of, and the direction through which, each wire is initially traversed by the generated traffic. The four-port switch shown in Figure B.2 consists of two modules with two ports each. The measured performance for a given test configuration may depend upon whether the internal connections of the VCC chain are inter-module, intra-module, or a mixture of both. The methodology presented in this appendix ensures that it is possible for exclusively inter-module, or intra-module traffic to be carried. B.3.1. Implementation of External Connections The methodology for implementing the external connections consists of the following three steps: 1. Identify the modules to be included in the IUT and label the ports (using Pij format). 2. Connect the generators and analyzers to appropriate ports. 3. Establish and number external connections (wires) to use all the remaining ports of the IUT. These steps are now explained. Step 1. Identifying the modules to be included in the IUT In order to ensure that it is possible for the configuration to support exclusively inter-module and/or intra-module internal connections, the IUT should consist of pairs of similar modules. If this constraint is not satisfied, the VCCs that are established may be a mixture of inter-module and intra-module connections. It is not necessary that the modules/ports be labeled, although we use the Pij format here to assist in the description of the methodology. Consider a switch with several modules of different port types. The ports could be different in speed and/or connector type. Each module may have a different number of ports. For example, a switch may have two modules of eight and six 155-Mbps single-mode fiber ports, respectively, another module with eight 155-Mpbs UTP ports and a fourth module with six 25-Mbps UTP ports. Figure B.3 shows an example IUT where the modules are grouped by type. The first group consists of two 25-Mbps UTP modules, the second group consists of two 155-Mbps single fiber modules. External connections may only be established between ports that are co- located within the same group (hence the constraint that modules come in pairs for inter-module connectivity). [Figure B.3. Example partitioning of modules into groups.] Step 2. Connect the generators and analyzers to appropriate ports A port must be reserved for each generator/analyzer that is to be used in the test. These reserved ports cannot be used in the next step that establishes external connections. The methodology presented here allows any given number, r