Guidelines for Writing Ipv6 Testing Specifications

Guidelines for Writing IPv6 Testing Specifications< 2Reference ???Keywords Test Specification, Interoperability Testing, Conformance Testing, Test Suit Structure (TSS), Implementation Conformance Statements (PICS)ETSI650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCETel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88Important noticeIndividual copies of the present document can be downloaded from: http://www.etsi.orgThe present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status /If you find errors in the present document, send your comment to: [email protected]Copyright NotificationNo part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute yyyy. All rights reserved.ETSI 3Contents Foreword...... 5 1 Introduction...... 6 References...... 7 2 Definitions and abbreviations...... 7 2.1 Definitions...... 7 2.2 Abbreviations...... 8 3 Purpose of this document...... 8 4 Basic principles...... 8 4.1 What is a test specification?...... 8 4.2 Implementing a test specification...... 9 5 Guidelines for writing conformance test specifications...... 9 5.1 Overview of the main components...... 9 5.2 Protocol Implementation Conformance Statement (PICS)...... 10 5.3 Abstract Test Architecture...... 10 5.4 Protocol Implementation eXtra Information for Testing (PIXIT)...... 10 5.5 Test Suite Structure (TSS)...... 10 5.6 Test purposes...... 11 5.6.1 Identifier of a test purpose...... 11 5.6.2 Reference to the base standards...... 11 5.7 Test description...... 11 5.7 TTCN-3 Abstract Test Suite...... 13 5.8 Developing conformance test specification...... 13 6 Writing an interoperability test specification...... 14 6.1 Specification of abstract test architecture...... 15 6.2 IFS...... 16 6.3 TSS&TP and TD...... 16 6.4 PIXIT...... 16 6.5 TTCN-3 Abstract Test Suite...... 16 6.6 Developing Interoperability Test Specifications...... 16 Annex A (informative): Part of example conformance test specification (RFC2460 – IPv6 Specification)...... 18 A.1 Introduction...... 18 A.1.1 Abbreviations and conventions...... 18 A.1.1 PICS Proforma...... 18 A.1.2 TP structure...... 18 A.1.3 TD structure...... 19 A.2 PICS Proforma...... 19 A.2.1 Guidance for completing the PICS proforma...... 19 A.2.2 Identification of the implementation...... 19 A.2.2.1 Date of the statement...... 19 A.2.2.2 Implementation Under Test (IUT) identification...... 19 A.2.2.3 System Under Test (SUT) identification...... 19 A.2.2.4 Product supplier...... 19 A.2.2.5 Client (if different from product supplier)...... 20 A.2.2.6 PICS contact person...... 20 A.2.3 Identification of RFC2460...... 20 A2.4 Global statement of conformance...... 20 A2.5 Roles...... 21 A.3 Reference to the base standards...... 21 A.4 Abstract test architecture...... 21 A.5 PIXIT...... 21 A.5 Test suite structure...... 23ETSI 4A.6 Test purposes...... 24 5.2 Test Purposes for IPv6 Basic Header...... 24 5.2.1 Version...... 24 5.2.1.1 Valid behaviour...... 24 5.2.2 Traffic Class...... 24 A.6 Test Description...... 25 A.6.1 Common Test Setup...... 25 A.6.1.1 Common Test Setup A...... 25 A.6.1.2 Common Test Setup B...... 25 A.6.1.2 Common Test Setup C...... 25 A.6.1.4 Common Postamble...... 25 A.6.1 Basic IPv6 header...... 25 A.6.1.1 Version!=4 Packets...... 25 A.7.1.2 Version=4 Packets...... 26 A.8 TTCN-3 Abstract Test Suite...... 27 Annex B (informative): Part of example interoperability test specification (RFC2460 – IPv6 Specification)...... 27 B.1 Introduction...... 27 B.2 IFS Proforma...... 27 A.2.1 Implementation Identification...... 27 A.2.2 Protocol Summary, IPv6 Specification...... 28 A.2.3 IPv6 Entities...... 29 A.2.3.1 Roles...... 29 A.2.3.2 Host capabilities...... 29 A.2.3.2.1 Basic IPv6 functionality...... 29 A.2.3.2.2 Advanced functionalities...... 30 A.2.3.2 Router capabilities...... 30 B.3 Abstract architecture...... 30 B.3 References to base standards...... 31 A.2.4 Test Suite Structure...... 31 B.2.5 IIXIT...... 31 B.2.5 Test Purpose...... 32 B.2.5.1 Basic Host Functionality...... 32 B.2.5.1.1 Reachability...... 32 B.2.5.1.1.1 Valid behaviour...... 32B.2.6 Test Description...... 32 B.2.6.1 Reachability through on-link, link-local address...... 32 B.2.6 TTCN-3 Abstract Test Suite...... 32 History...... 32ETSI 5ForewordThis <long doctype> (<doctype>) has been produced by {ETSI Technical Committee|ETSI Project|<other>} <long techbody> (<short techbody>){|, and is now submitted for the {ETSI standards {Membership Approval Procedure|One- step Approval Procedure|<approval phase> phase of the ETSI standards Two-step Approval Procedure}}}.The present document is part , sub-part <j> of a multi-part deliverable covering [the] <common element of the title>, as identified below:Part 1: ""<part element of the title>"";⋮Part : ""<part element of the title>"";Sub-part 1: ""<sub-part element of the title>"";⋮Sub-part <j>: ""<sub-part element of the title>"";⋮Sub-part <m>: ""<sub-part element of the title>"".⋮Part <n>: ""<part element of the title>""ETSI 61 Introduction** [AW] This clause needs a full review - not done yet**This document, ""Recommendations for Writing IPv6 Test Specifications"", gives general guidance on the specification of conformance and interoperability tests for Internet Protocol Version 6 (IPv6) family. It provides a guideline within which test specifications for IPv6 protocols can be developed. The guidelines are expressed as recommendations rather than strict rules and leave enough freedom to allow test specifiers to adopt and adapt processes to suit each particular project while still ensuring that test specifications accurately reflect the requirements of the base standards and can be executed consistently across a range of configurations.Test specifications for IPv6 protocols are foreseen to cover both conformance testing and interoperability testing for IPv6 core protocols (such as IPv6 specification, neighbour discovery and stateless address auto-configuration) and extended protocols (such as security, mobility, and transition). On one hand, conformance testing is necessary to 1) exercise most, if not all, of the possible ways of achieving each of a component’s function, 2) determine whether an IPv6 implementation’s behaviour conforms to the requirements laid out in its base specifications (RFCs) including the full range of error and exception conditions which can only be induced or replicated by dedicated conformance tests. However, it is difficult for such testing to be able to prove that the implementation will interoperate with similar implementations in other products. On the other hand, interoperability testing can clearly demonstrate that two implementations will cooperate to provide the specified end-to-end functions but cannot easily prove that either of them conforms to the detailed requirements of the protocol specification.The purpose of interoperability testing is not only to show that products from different manufacturers can work together but also to show that these products can interoperate using a specific protocol. Without this additional aspect, interoperability testing could be considered to be almost meaningless. Within the context of standardization, it is of little interest to know that two products can interoperate unless there is a guarantee that they are connected together by means of a standardized protocol. It is, therefore, advisable to conformance test an implementation before testing for interoperability with other (similarly tested) implementations.As currently specified, like other IETF standards, the IPv6 protocols contain many implementation choices, with recommended and optional parameters and even within mandatory parameters. Given that it is unlikely that two network operators have the same implementation choices, testing must be performed to check the compatibility of the implementations.In order to ascertain that this test specification meets the above objectives, the following criteria are used:• A test specification may not be aimed to non-exhaustive testing of all aspects of a function’s relation, but its selection criteria and coverage limitation must be identified. Aligned with the international standardized testing framework and methodology [1, 1], it is recommended to use Protocol Implementation Conformance Statement (PICS) to specify the selection criteria for each parameter choices (e.g., MUST, SHOULD and MAY), and use Test Suite Structure (TSS) to specify each test. • A test specification must be well-defined and self-explained. It must contain a precisely and unambiguously defined objective, clear reference to the base standards, precisely stated expected initial conditions and cleanup, an explicit, exhaustive and unambiguous test procedure, explicitly described observable results and test assessment criteria. When necessary, a test requirements/constraints part can be added to describe certain valid/invalid parameter values or necessary relations to other tests.This distinguishes itself from other way by the level of clarity, extensibility and flexibility that is offered. It is anticipated that it will lead to a much greater acceptance of IPv6 test products and certified implementations. This document provides recommendations for formatting and producing test specifications with a couple of examples:- Recommendations for formatting IPv6 test specifications (normative)- Recommendation for producing IPv6 test specifications (informative)- Test specification examples (informative)ETSI 7ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.- References are either specific (identified by date of publication and/or edition number or version number) or non-specific.- For a specific reference, subsequent revisions do not apply.- For a non-specific reference, the latest version applies.[1] ISO/IEC 9646 Information Technology – Open Systems Interconnection – Conformance Testing Methodology and Framework – Parts 1-7[2] ETSI DTS/TIPHON-06025-1R4, Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 4; Interoperability test methods & approaches; Part 1: Generic approach to interoperability testing, October 2003[2] ANSI/IEEE Std. 100, Authoritative Dictionary of IEEE Standards Terms (Seventh Edition) [3] DoD MIL-STD-2045-14502-1, Military standard – Information Technology – DoD Standardized Transport Profile – Internet Transport Profile for DoD Communications, Part 1: Transport and Internet Services, July 1994[5] IETF RFC 2460, Internet Protocol Version 6 (IPv6) Specification, December 1998[6] IETF RFC 2461, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, December 1998[7] IETF RFC 3513, IP Version 6 Addressing Architecture, April 2003[8] IETF RFC 2461, Neighbor Discovery for IP Version 6 (IPv6), December 1998[9] IETF RFC 2462, IPv6 Stateless Address Autoconfiguration, December 1998[10] EG 201 058, Methods for Testing and Specification (MTS); Implementation Conformance Statement (ICS) proforma style guide, April 19982 Definitions and abbreviations 3 DefinitionsFor the purposes of the present document, the following terms and definitions apply: conformance: compliance with requirements specified in applicable standards [1]. conformance testing: testing the extent to which an Implementation Under Test (IUT) satisfies both static and dynamic conformance requirements [1]. That is, the purpose of conformance testing is to determine to what extent a single implementation of a particular standard conforms to the individual requirements of that standard.Equipment Under Test (EUT): a grouping of one or more protocol implementations which has not been previously shown to interoperate with previously Qualified Equipment (QE). interoperability: the ability of two systems to interoperate using the same protocol. interoperability testing: the activity of proving that end-to-end functionality between (at least) two implementations is as required by the base standard(s) on which those implementations are based.ETSI 8 interoperability test suite: a collection of test cases designed to prove the ability of two (or more) systems to interoperate.Implementation Under Test (IUT): an IPv6 implementation to be tested for its conformance. In this document it is equivalent to a Node Under Test (NUT), and can be either Host Under Test (HUT) or Router Under Test (RUT).Protocol Implementation Conformance Statement (PICS): statement of an implementation or system claimed to conform to a given protocol specification, stating which capabilities are implemented.Qualified Equipment (QE): a grouping of one or more protocol implementations that has been shown, by rigorous and well-defined testing, to interoperate with other equipment. NOTE: Once an EUT has been successfully tested against a QE, it may be considered to be a QE, itself.Test Specification (TS): a collective term covering a set of test documents. This set of documents will be different depending on whether it refers to a conformance test specification or to an interoperability test specification. 4 AbbreviationsFor the purposes of the present document, the following abbreviations apply:EUT Equipment Under Test I Invalid IUT Implementation Under Test NUT Node Under Test O Inopportune PICS Protocol Implementation Conformance Statement PIXIT Protocol Implementation eXtra Information for Testing QE Qualified Equipment RUT Router Under Test SUT System Under Test TD Test Description TP Test Purpose TSS Test Suite Structure V Valid3 Purpose of this documentThis present document provides a methodological framework within which both conformance and interoperability test specifications can be developed for IPv6. It should be regarded as a complement to ISO/IEC 9646/1 [1] and ETSI TS 102 237-1 [2] rather than a replacement. This framework should not be considered as a set of hard and fast rules but as broad guidance within which there is freedom to adapt to specific testing situations. NOTE: Although the immediate application area for this present document is IPv6 testing and all examples and specific terminology are oriented in that direction, this does not preclude it being used in other areas.This document is divided into two main parts:- Guidelines for writing conformance test specifications (see clause 5 and example in Appendix A); and- Guidelines for writing interoperability test specifications (see clause 6 and example in Appendix B).4 Basic principles 4.1 What is a test specification?A test specification has two main purposes which are to define WHAT to test and then to define HOW the test is to be achieved. Table 1 shows the typical components (documents) that make up a test specification. ETSI 9Table 1: Categorization of the components of a test specificationConformance Interoperability PICS IFS WHAT TSS&TP TSS&TP (may move to HOW) Test Architecture In the scope of PIXIT IIXIT standardisation HOW Test Architecture (ETSI) Test Description Test Description TTCN-3 Abstract Test Suite TTCN-3 Abstract Test Suite (if required) IMPLEMENTATION Executable Test Suite Executable Test Suite Not in the scope of (if relevant) standardisationNOTE: These components may be separate documents or combined into one documents. For example, it would not be unusual to combine the TSS&TP and the Test Description in a single document (this is especially true for an interoperability test suite). 4.2 Implementing a test specificationThe Executable Test Suite (ETS) is not part of a standardised test specification but it has been included in Table 1 for completeness. It may be compiled from the TTCN-3 code (if it exists) or derived manually from the test description.5 Guidelines for writing conformance test specifications 5.1 Overview of the main componentsThe main components of a of test specifications include:- an identification of the base standard(s) to which the test specification applies; - an identification of the relevant Protocol Implementation Conformance Statement (PICS) proforma which describes standards requirements and the supplier’s support for these requirements;- a specification of the abstract test architecture;- a Protocol Implementation eXtra Information for Testing (PIXIT) proforma which provides additional information regarding parameters and values or their ranges.- a Test Suite Structure (TSS) identifying each test that is to be defined and a grouping of the tests into a structure which is appropriate to the particular;- a Test Purpose (TP) for each identified test. A TP consists of:- a unique TP identifier;- a status specifying whether the test purpose is mandatory or optional according to the associated PICS;- references (usually by (sub)section number and paragraph number) to the requirements in the base standard(s) covered by the TP;- a description of the purpose of the test in plain language.- for each test (which **may encompass more than one TP**?) a Test Description (TD) which comprises- a unique test identifier- a brief description of the objective of the test, making reference to the TPs included;- references to the requirements in the base standard(s) covered by the test (taken directly from the associated TPs);- references to the individual PICS and PIXIT items covered by the test;ETSI 10- pre-conditions describing the static configuration of the test scenario;- the test procedure in a series of steps written in plain or structured language. This should include any preamble to establish the SUT into a known initial condition prior to the test and postamble to return it to a specific quiescent state after the completion of the test;- for each step, a description of the results which constitute a PASS condition;As their name implies, guidelines are only for guidance and the actual process followed should use and adapt whichever of these guidelines are most applicable in each particular situation. In some cases this may mean the application of all aspects. 5.2 Protocol Implementation Conformance Statement (PICS)The purpose of a PICS is to identify those standardized functions which an IUT must support, those which are optional and those which are conditional on the presence of other functions. Although not strictly part of the IPv6 test suite, the PICS helps to provide a means for selection of the suite of tests which will subsequently be developed. In addition, the PICS can be used as a proforma by an IPv6 implementation supplier in identifying which functions an IUT will support when interoperating with similar equipment from other suppliers. The information in a PICS is usually presented in tabular form as recommended in ISO/IEC 9646-7 [4].Guidance 1:A PICS should clearly identify the mandatory and optional requirements and conditions which apply to the protocol to be tested. The PICS can be considered as a set of “"switches”" which specify the capability of supporting the requirement in base standards to be tested. It is possible that with different choices in a PICS proforma, several different set of TPs will be necessary. Part of an example PICS table can be found in Annex A. 5.3 Abstract Test ArchitectureAn abstract test architecture provides a general framework within which specific test arrangements must fit in order to perform the specified suite of tests. It describes the entities involved with the protocol being tested and their means of communication, for example, the definition and placement of IUT, test components and test drivers.Abstract test architectures can be depicted through diagrams or equivalent tables. An example abstract test architecture is provided in Appendix A. 5.4 Protocol Implementation eXtra Information for Testing (PIXIT)A Protocol Implementation eXtra Information for Testing (PIXIT) proforma identifies which PICS items are to be tested and which parameters to be instantiated for the TSS&TP being developed. The production of a PIXIT Proforma is based specified in on ISO/IEC 9646-6 [1]. A supplier, providing an IUT for conformance testing, is required to produce complete a PIXIT proforma, which contains additional questions that need to be answered in order to turn on/off the “"switches”" and identify Means of Testing (MOT) for a particular Implementation Under Test (IUT). Any needed additional information can be found in [1]. 5.5 Test Suite Structure (TSS)There is no hard and fast rule that can be used to determine how a test suite should be divided up into Test Groups other than to say that there should be a logical basis to the choice of groups. In many cases, the division will be rather arbitrary and based on the preferences of the author(s). However, the following categorizations should be considered when identifying appropriate Test Groups within a Test Suite Structure (TSS):- Abstract Test Configuration: A Test Group for each valid configuration specified. For example:- host-to-host direct;ETSI 11- host-to-host via a router;- host-to-host via an interconnecting network.- functionality: A Test Group for each of the major functions (and sub-functions, when necessary) supported. For example:- basic IPv6 header;- extension headers;- fragmentation.- success, inclusive or failure: Test Groups for normal behaviour, inclusive behaviour and exceptional behaviour.Example TSS (for conformance testing of RFC2460) can be found in Annex A. 5.6 Test Purposes (TPs)TPs identify the individual requirements from the bases standard(s) and PICS that are to be tested by the test specification. Each TP is uniquely identified and includes all necessary references back to the base specifications.Test purposes are derived from the standards and PICS, and specify the purposes of individual tests for conformance of IUT functionalities. A test purpose’s structure consists of the following items: 5.6.1 Identifier of a test purposeThe role of the identifier part of a Test Purpose is to identify it unambiguously. In addition, it is supposed to establish the link between the Test Purpose and the relevant entry in the Test Suite Structure.Guidance 2:Test Purpose should be identified by the same referencing scheme as the Test Suite Structure, for the purpose of checking the coverage of test purposes. 5.6.2 Reference to the base standardsThis reference should precisely indicate in which place in the base standards the corresponding test requirements are expressed, in order to relate to support for the function by the purpose.The recommended form is RFCxxxx [ref], clause xxx.xxx, (if necessary) paragraph xx-yy, (if necessary) lines xx-yy. 5.7 Test Description (TD)A TD specifies in informal natural language the procedure to be followed in performing a specific test. Although the language is informal, the structure of a TD is quite precise and should include:- the a unique test identifier this may relate to more than one TP Identifier- the objective of the test;- references to the base standard(s);- references to the specific PICS&PIXIT items;- any pre-conditions;- the test procedure itself; a test procedure consists of a preamble, one or more sequential test step descriptions associated with pass conditions (verdicts) which should explicitly describe the observable events to be used to assess the result of the test, as well as a postamble. ETSI 12Example: The following text represents a clear and unambiguous specification of a pass condition:""After sending an ICMPv6 Echo Request destined to the NUT, the TN1 cannot receive any packet from the NUT within 30 seconds.""Editor's Note: I am not sure that this is a good example. It should be specified as "Do something. If something else happens then pass" (or fail or whatever)The pre-conditions should define precisely the expected state of the IUT at the beginning of the test.Guidance 3:Pre-conditions should define which test architecture is to be used, with which observable external parameters in order to allow an unambiguous identification of the status of the IUT before starting the test. What is not clear: The tester transmits an Echo Request to the IUT and responds to Neighbor Solicitations from the IUT. Wait for an Echo Reply from the IUT. This should cause the IUT to resolve the tester’s address and create a Neighbour Cache entry for the tester in state REACHABLE.In the above example, the information (and the procedure) is confusing the way in which the test specifier can follow and check that the IUT is in the desired state. The semantic action like IUT moves in state REACHABLE. What is clearer: The tester transmits an Echo Request to the IUT. If the tester receives a Neighbor Solicitation from the IUT, responds a Neighbor Advertisement to the IUT, and send another Echo Request to the IUT. Ensure that IUT is added in Neighbour Cache entry of the tester with state REACHABLE (reception of an Echo Response from IUT in respond to the Echo Request).Guidance 4:A preamble should describe the operation that needs to be performed to meet the observable and operatable operable requirement for the specific test procedure. “"None”" can be expressed in the preamble if there is no such requirement for the test procedure.Guidance 5:Test Procedures defined in a test purpose TD should be able to be performed in an explicit, exhaustive and unambiguous manner. Guidance 6:Several independent test proceduresTPs, if defined in a single test descriptionTD, should have the same PICS status and reflect a same entry in TSS. Guidance 7: No assumptions should be made about the knowledge of the IUT or SUT possessed by the person (or machine) carrying out the test. The sequence of actions involved in each test case should be specified in full.Test assessment should explicitly describe the precise criteria (observable events) to be used to assess the result of the test. The observable event may be direct or indirect; in other words, it may concern an action on another layer.What is not clear: The IUT must silently discard the ICMPv6 Echo Request and not send any packets to the tester.In this case, there is no actual indication of the assessing criteria. The expression “"silently discard the ICMPv6 Echo Request”" is only a semantic action, “"and not send any packets to the tester”" is overlapping but stronger than the previous statement (it looks like “"all packets including discovery packets etc. are also blocked”"), which makes the whole assessment not clear. What is clearer:ETSI 13 After sending an ICMPv6 Echo Request destined to the IUT, the tester cannot receive any packet from the IUT within 30 seconds.A clearly-defined preamble procedures to be performed before the test procedure is necessary when any node participating in the test needs a particular temporary status for to be placed in a particular initial state prior to the start of the test.A clearly-defined postamble procedure to be performed after the test procedure is necessary when any node participating in the test falls into an unrecoverable statusis required to return to a known quiescent condition after the test has completed. 5.7 TTCN-3 Abstract Test Suite** 5.8 Developing conformance test specificationThe steps involved in the process of developing a conformance test specification are as follows:- identify all the conformance requirements (for conformance testing) and/or observable interworking requirements (for interoperability testing) of the base standards;- prepare draft Abstract Test Configuration;- identify the PICS entry(ies) corresponding to these requirements;- structure the requirements into nested homogeneous groups, leading to the definition of a first Test Suite Structure (TSS);- compare this first draft of TSS with the basic guidance provided by ISO/IEC 9646-2 and identify the potential gaps; thus leading to an amended draft of TSS;- define Test Purposes (TPs) which correspond to (set of) the requirements identified (note guidance 6);- “"feed”" TSS tree with these TPs;- refine the TSS and the TP (this step may be iterative);- develop TDs- develop ATS- check the coverage of the TSS & TP with the base standard;This way of developing test specification is preferred because it starts from the requirements of the base standards and is able to identify the coverage of the TSS & TP, since the TSS structure applicable to a given standard result from the process of requirement analysis. Furthermore, PICS provides a means to specify selection criteria for each requirement identified.This process is illustrated in Figure 5.ETSI 14: Base StandardWrite Protocol Implementation Specify Abstract Test Conformance Statement Architecture: PICS : Abstract ArchitectureDevelop Test Suite Structure: Test Suite StructureWrite Test Purposes: Test PurposeWrite Test Descriptions: Test DescriptionsWrite Abstract Test Suite: Abstract Test SuiteCheck Consistency with Base Standard: Test SpecificationFigure 1: Process of Developing a Conformance Test Specification6 Writing an interoperability test specificationFor a certification (or branding or logo) scheme to be meaningful, it is necessary that interoperability testing is carried out in accordance with a comprehensive and structured suite of tests. In the context of this document, it is exactly this type of testing which is referred to as ""Interoperability Testing"". The purpose of interoperability testing is to prove that interworking behaviorsthe end-to-end functionality between (at least) two communicating systems are is as required by the standard(s) on which those systems are based.The important factors which characterize interoperability testing are [2]:- the Equipment Under Test (EUT) and the Qualified Equipment (QE) together define the boundaries for testing;- the EUT and QE come from different suppliers (or, at least, different product lines);- interoperability tests are performed at interfaces that offer only normal user control and observation;- interoperability tests are based on functionality as experienced by a user (i.e., they are not specified at the protocol level). In this context a user may be human or a software application;ETSI 15- the tests are performed and observed at functional interfaces such as Man-Machine Interfaces (MMIs), protocol service interfaces and Application Programming Interfaces (APIs).The fact that interoperability tests are performed at the end points and at functional interfaces means that interoperability test cases can only specify functional behaviour. They cannot explicitly cause or test protocol error behaviour. 6.1 Specification of abstract test architectureAn interoperability test architecture shows the relationship between the EUT, the QEs and Test Operators/Drivers can be derived from. Defining this architecture at an early stage should help to provide a structure for the test cases specified later. Abstract Architectures can be expressed in diagrammatic, tabular or textual form and should clearly identify:- the EUT;- the QE(s);- the communications paths between the EUT and QE(s);- valid types of equipment for the EUT and QE(s);- if required, the expected protocol to be used in providing communication between the EUT and QE(s).Guidance 8: The abstract architecture should be derived reflect from the requirements of the base protocol standard(s), and should be specified in a form that makes it simple to map each element of a concrete test scenario to it.Figure 2 shows in diagrammatic form an example of an abstract architecture for the testing of an IPv6 NUTnode. In this example, the IPv6 NUT node is identified as the EUT with one or two IPv6 hosts as QE(s) (and, optionally, plus an intervening network as another QE which can be a single qualified IPv6 router) identified as QEs. Each QE can have a test driver (not shown in the figure). 1QE14 2 3EUT QE2 QE3Figure 2: Example abstract architecture diagramThis abstract architecture could equally well be represented in a table, as shown in Table 2.Table 2: Example abstract architecture tableItem EUT/QE Equipment Type Connected to Item 1 QE IPv6 host 4 2 QE IPv6 network 3 4 3 QE IPv6 host 2 4 EUT IPv6 node (host or 1 router) 2 The architecture can be extended for the following three types of test:ETSI 16- End-to-end host direct (“"on-link”");- End-to-end host via a Router (“"off-link”");- End-to-end host via an intervening network (“"off-link”"). 6.2 IFSThe Interoperable Functions Statement (IFS) is a statement of which functions supported by the protocol have been implemented. The purpose of IFS is to identify those standardized functions which an EUT must support, those which are optional and those which are conditional on the presence of other functions. Although not strictly part of the interoperability test suite, the IFS helps to provide a structure to the suite of tests which will subsequently be developed.In addition, the IFS can be used as a proforma by a manufacturer in identifying which functionalities that an EUT will support when interoperating with similar equipment from other manufacturers. For example, the reachability of a link- local address as source or destination address, the functionality of fragmentation and processing of hop limit field and extension headers can could be part of the IFS for an IPv6 core interoperability testing.The structure of an IFS proforma is similar to the Protocol Implementation Conformance Statement (PICS). If it exists, the ideal starting point in the development of an IFS is the PICS which should then clearly identify the options and conditions which apply to the protocol to be tested. Like the PICS, the IFS should be considered switches for implementation functionalities of the base protocol specification.At early stage of the test specification development, the IFS can only be considered as a working draft. As the test specification evolves, it is possible that errors and omissions in the IFS will be identified. These should be recorded for correction at a later stage (see clause 6.6). Examples of an IFS (for the proforma of part of IPv6 specification) can be found in Appendix B. 6.3 TSS&TP and TDThe formats of the TSS&TP and TDs in interoperability testing are similar to the conformance testing. Test groups can be identified according to the functionalities as specified in the IFS, it is possible a set of functionalities would be covered in TSS&TP, depending on the testing methodology used (for example, a simple interoperability test system with only a passive monitor but no an active test component to generate special IPv6 packets). 6.4 PIXITPIXIT for interoperability testing is similar to that for conformance testing. It can be more restrictive than the latter due to the limited means for interoperability testing of specific functionalities. 6.5 TTCN-3 Abstract Test Suite*** 6.6 Developing Interoperability Test SpecificationsThe development of an interoperability test specification should follow a similar path to that taken when developing a conformance test specification. A close parallel can also be seen between the component parts of each type of test specification.The steps involved in the process of developing an interoperability test specification are as follows:- specify Abstract Architecture;- prepare draft Interoperable Functions Statement (IFS);- specify Test Suite Structure (TSS);- write Test Purposes (TP);- write Test Descriptions;- validate Test Descriptions;ETSI 17- write Abstract Test Suite (ATS), if required- finalize IFS.This process is expressed graphically in Figure 3 using a UML Activity Diagram.: Base StandardWrite Interoperable Specify Abstract Test Functions Statement Architecture: IFS : Abstract ArchitectureDevelop Test Suite Structure: Test Suite StructureWrite Test Purposes: Test PurposeWrite Test Descriptions: Test DescriptionsWrite Abstract Test Suite: Abstract Test SuiteValidate Abstract Test Suite: Test SpecificationFigure 3: Process of Developing an Interoperability Test SpecificationAnnex A (informative): Part of example conformance test specification (RFC2460 – IPv6 Specification) A.1 IntroductionThis document provides a test specification for the IPv6 implementation in compliance with the relevant requirements specified in IETF RFC 2460 “"Internet Protocol Version 6 (IPv6) Specification”". It is applicable for conformance (and/or interoperability) testing.ETSI 18A.1.1 Abbreviations and conventionsFor the purposes of the present document, the following terms and definitions apply: Terms defined in IETF RFC2460 [5]; Terms defined in ISO/IEC 9646, 1-7 [1]; Terms defined in this document “"Guidelines for Writing IPv6 Test Specifications”"Test Purpose (TP): non-formal high-level description of a test, mainly using textInopportune (O): test group that handles invalid signalling exchanges of messages, which are properly structured and correctly encodedInvalid (I): test group that handles valid signalling exchanges of messages, which are either not properly structured or incorrectly encoded Valid (V): test group that handles valid signalling exchanges of messages, which are properly structured and correctly encoded A.1.1 PICS ProformaThe purpose of the PICS proforma is to provide a mechanism whereby a supplier of an implementation of the requirements defined in RFC2460 [5] may provide information about the implementation in a standardized manner.The PICS proforma is subdivided into clauses for the following categories of information: - guidance for completing the PICS proforma; - identification of the implementation; - identification of requirements of RFC2460; - global statement of conformance; - roles; - major capabilities; - PDUs; - PDU parameters.A.1.2 TP structureEach test purpose is comprised of the following parts: The TPId gives a unique identifier to each test purpose; The Status specifies whether the test purpose or the group is mandatory or optional according to RFC 2460 [5]. The group status applies to all test purposes belonging to this group;The Ref. outlines the references in RFC 2460 [5] used to derive the test purpose;The purpose describes the objective of the test. A.1.3 TD structureEach test description is presented in a tabular way and comprised of the following parts: Reference TPs gives a reference to the test purposes, and may also repeat the Purpose text in the TP for the readability of the TD; The PICS Ref. and PIXIT Ref.;Test Procedure and Assessment;The Reference gives the references in RFC 2460 [5].ETSI 19A.2 PICS Proforma A.2.1 Guidance for completing the PICS proformaThe supplier of the implementation shall complete the PICS proforma in each of the spaces provided. In particular, an explicit answer shall be entered, in each of the support or supported column boxes provided, using the notation described in ISO/IEC 9647-7 [1]. A template of the PICS proforma is given in EG 201 058 [10].However, the tables containing in ""Host"" clause shall only be completed for HUT implementations, and the tables containing in ""Router"" clause shall only be completed for RUT implementations. If necessary, the supplier may provide additional comments in space at the bottom of the tables or separately. More detailed instructions are given at the beginning of the different clauses of the PICS proforma.A.2.2 Identification of the implementationIdentification of the Implementation Under Test (IUT) and the system in which it resides (the System Under Test (SUT)) should be filled in so as to provide as much detail as possible regarding version numbers and configuration options.The product supplier information and client information should both be filled in if they are different.A person who can answer queries regarding information supplied in the PICS should be named as the contact person.A.2.2.1 Date of the statement...... A.2.2.2 Implementation Under Test (IUT) identificationIUT name: ...... IUT version: ...... A.2.2.3 System Under Test (SUT) identificationSUT name: ...... Hardware configuration: ...... Operating system: ...... A.2.2.4 Product supplierName: ...... Address: ...... Telephone number: ...... Facsimile number: ...... E-mail address: ...... ETSI 20Additional information: ...... A.2.2.5 Client (if different from product supplier)Name: ...... Address: ...... Telephone number: ...... Facsimile number: ...... E-mail address: ...... Additional information: ...... A.2.2.6 PICS contact person(A person to contact if there are any queries concerning the content of the PICS) Name: ...... Telephone number: ...... Facsimile number: ...... E-mail address: ...... Additional information: ...... A.2.3 Identification of RFC2460This proforma applies to the protocols described in the following standard: RFCA2.4 Global statement of conformanceAre all mandatory capabilities implemented? (Yes/No) ...... NOTE: Answering ""No"" to this question indicates non-conformance to the TS 102 000 specification. Non-supported mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is non- conforming, on pages attached to the PICS proforma. A2.5 RolesTable A.1: Roles Item Role Reference Status Support 1 Host (HUT) RFC2460 [5] o.1 2 Router (RUT) RFC2460 [5] o.1 o.1 o.1: It is mandatory to support at least one of these items.ETSI 21A.3 Reference to the base standardsRFC 2460 [5]. A.4 Abstract test architectureAn abstract test architecture is shown in Figure A.1. It can be also 1 2Tester Tester5 3 4IUT Tester TesterFigure A.1 Abstract Test Architecture for IPv6 conformance testing A.5 PIXIT A.5.1 Identification summaryPIXIT Number: ______Test Laboratory Name: ______Date of Issue: ______Issued to: ______A.5.2 ATS summaryProtocol Specification:Protocol to be tested:ATS (or Test description) Specification:Abstract Test Method: A.5.3 Test laboratoryTest Laboratory Identification: Test Laboratory Manager:Means of Testing:SAP Address: A.5.4 Client identificationClient Identification:Client Test manager:ETSI 22Test Facilities required: A.5.5 SUTName:Version:System Conformance Statement (SCS) Number:Machine configuration:Operating System Identification:IUT Identification:Limitations of the SUT:Environmental Conditions:A.5.6 Protocol layer information A.5.6.1 Protocol identificationName:Version: A.5.6.2 IUT informationTable A.xx: Capabilities Name Type Comments Value (True/False) PC_ROUTER boolean Does the IUT behave as a router? PC_HOST boolean Does the IUT behave as a host? PC_FRAGMENT boolean Does the IUT support fragmentation? PC_REASSEMBLE boolean Does the IUT support reassembly of fragments? PC_LLA boolean Does the IUT use link-local address? PC_SLA boolean Does the IUT use site-local address? PC_GA boolean Does the IUT use global address? PC_SHOULD boolean Does the IUT support SHOULD requirements for RFC2460 [5]? PC_REDIRECT boolean Does the IUT support redirect function? PC_IP4 boolean Does the IUT support processing IPv4 packets? PC_AUTOCONF boolean Does the IUT use stateless address autoconfiguration (RFC2463 [6])? PC_PING_LARGE boolean Does the IUT’s ping6 support sending an echo request larger than 64K? PC_PING_SRC boolean Does the IUT’s ping6 support specifying an echo request’s source address? (more…)Table A.xx: IP/L2 parameters Name Type Comments Value PX_TSR_MAC charstring MAC address(es) used by the tester to exchange test IPv6 packets PX_TSR_IP6ADDR charstring IPv6 address(es) used by the tester PX_IUT_MAC charstring MAC address(es) used by the IUT PX_IUT_IP6ADDR charstring IPv6 address(es) used by the IUT PX_ETS_MTU integer MTU supported by the tester PX_IUT_MTU integer MTU supported by the IUT (more…)Table A.xx: Location parameters Name Type Comments ValueETSI 23PX_IUT_NET charstring Identity of the IUT network domain (i.e., prefix) PX_TSR_NET charstring Identity of the tester’s network domain (more…)Table A.xx: Header parameters Name Type Comments Value PX_TRAFFICCLASS charstring Traffic class field value(s) understood by the IUT PX_FLOWLABLE boolean Do non-zero flow label values understood by the IUT? PX_HBH_OPTION charstring Hop-by-hop option type(s) understood by the IUT PX_DEH_OPTION charstring Destination option type(s) understood by the IUT PX_ROH boolean Does the IUT support routing header? PX_FRAGMENT boolean Does the IUT support fragmentation header? (more…)Table A.xx: Timers Name Type Comments Value PX_IUT_TFRAG float Value for waiting not all fragments belonging to a same identifier (for IUT) PX_TSR_TFRAG float Value for waiting not all fragments belonging to a same identifier (for tester) (more…) A.5 Test suite structureThe following figure shows the Test Suite Structure (TSS) for conformance testing of RFC 2460 [5]. Last Sub groups may be subdivided in three subgroups: Valid behaviour (V), Invalid behaviour (I), Inopportune behaviour (O). The identifier part is the prefix of corresponding TP-IDs introduced in A.5.Test Suite Main Functionalities Role Functionalities subgroups Test group Identifier IPv6 IPv6 header Host/router Version V-I-O IP6_NOD_HDR_VER specification Source address V-I IP6_NOD_HDR_SOA Destination address V-I IP6_NOD_HDR_DEA Flow label V-I-O IP6_NOD_HDR_FLL Traffic class V-I-O IP6_NOD_HDR_TRC Payload length V-I IP6_NOD_HDR_PAL Hop limit V-I IP6_NOD_HDR_HOL Next header V-I IP6_NOD_HDR_NEH IPv6 extension headers Host/router General (next header, V-I IP6_NOD_EHR_GEN header length, order of headers) Hop-by-hop options header V-I IP6_NOD_EHR_HBH Destination options header V-I IP6_NOD_EHR_DSH Fragmentation header V-I IP6_NOD_EHR_FRH Routing header V-I IP6_NOD_EHR_ROH Fragmentation and MTU Host/router Fragmentation/MTU V-I IP6_NOD_EHR_MTU supportETSI 24A.6 Test purposesThe TP identifier naming conventions for this document are as follows.Table 1: TP identifier naming convention scheme in RFC 2460 TPIdentifier: <protocol>_<main functionality>_<role>_<functionality>_<type>_<nnn><protocol> IPv6 specification (IP6)<main functionality> Header (HDR), Extension header (EHR), <role> Host (HST), Router (RTR), Node (NOD) Source Host (SOH), Destination Host (DEH) <functionality> (optional) General (GEN), hop-by-hop options header (HBH), destination options header (DSH), routing header (ROH), fragmentation header (FRH), IPsec headers (SEC)<sub-functionality> (optional)<type> Valid Behaviour (V), Invalid Behaviour (I), Inopportune Behaviour (O) , Timers (TI).<nnn> sequential number (001-999). 5.2 Test Purposes for IPv6 Basic Header 5.2.1 VersionGroupSelection: Version=6 being listed in RFC 2460[5] as the only mandatory value, the test purpose is necessary to ensure an IUT will not crash or generate invalid packets on receipt of Version!=6 packets.Status: Mandatory 5.2.1.1 Valid behaviourTPId: IP6_HDR_NOD_GEN_VIO_001Status: MandatoryRef: RFC 2460 [5], clause 3Purpose: Ensure that the IUT is able to process packets with Version field = 6 but discard Version = {1-3, 5, 7-15} packets it receives.TPId: IP6_HDR_NOD_GEN_VIO_002Status: OptionalRef: RFC 2460 [5], clause 3Purpose: Ensure that the IUT, if declared to support processing IPv4 packets, is able to respond to IPv4 request packets. 5.2.2 Traffic Class…ETSI 25A.6 Test Description A.6.1 Common Test SetupA test description may refer to a common test setup procedure or a common test postamble procedure defined for this section. Unless otherwise specified in the test description, each tester will respond to Neighbor Solicitations from the IUT with standard Neighbor Advertisements. A.6.1.1 Common Test Setup AIn the test architecture shown in Figure A.1:1. If the IUT is a host, tester 1 transmits a Router Advertisements the all-nodes multicast address. The Router Advertisement includes a Prefix Advertisement with a global prefix and the L and A bits set. (Note: this should cause the IUT to add tester 1 to its Default Router List, configure a global address, and compute Reachable Time.) The router and Prefix Lifetimes are long enough such that they do not expire during the test. 2. If the IUT is a router, configure a default router with tester 1 as the next hop. 3. Tester 1 transmits an Echo Request to the IUT and responds to Neighbor Solicitations from the IUT. Wait for an Echo Reply from the IUT. (note: This should cause the IUT to resolve the address of tester 1 and create a Neighbor Cache entry for tester 1 in state REACHABLE.) A.6.1.2 Common Test Setup BIn the test architecture shown in Figure A.1:1. Tester 1 and tester 2 each transmits a Router Advertisements the all-nodes multicast address. The Router Advertisement includes a Prefix Advertisement with a global prefix and the L and A bits set. (Note: this should cause the IUT to add both nodes (tester 1 and tester 2) to its Default Router List, configure a global address, and compute Reachable Time.) The router and Prefix Lifetimes are long enough such that they do not expire during the test. 2. Tester 1 and Tester 2 each transmits an Echo Request to the IUT and responds to Neighbor Solicitations from the IUT. Wait for an Echo Reply from the IUT. (note: This should cause the IUT to resolve the address of tester 1 and tester2, and create Neighbor Cache entries for tester 1 and tester 2 in state REACHABLE.) A.6.1.2 Common Test Setup CIn the test architecture shown in Figure A.1: 1. Tester 1, tester 2 and tester 3 each transmits a Router Advertisements the all-nodes multicast address. The Router Advertisement includes a Prefix Advertisement with a global prefix and the L and A bits set. (Note: this should cause the IUT to add all three nodes (tester 1, tester 2 and tester 3) to its Default Router List, configure a global address, and compute Reachable Time.) The router and Prefix Lifetimes are long enough such that they do not expire during the test. 2. Tester 1, tester 2 and tester 3 each transmits an Echo Request to the IUT and responds to Neighbor Solicitations from the IUT. Wait for an Echo Reply from the IUT. (note: This should cause the IUT to resolve the address of testers 1, 2, 3 and create Neighbor Cache entries for testers 1, 2 and 3 in state REACHABLE.) A.6.1.4 Common PostambleIn the test architecture shown in Figure A.1:1. For any tester transmitted a Router Advertisement in the Test Preamble or Procedure, let it transmit a Router Advertisement with the Router Lifetime and each Prefix Lifetime, if applicable, set to zero. 2. Each tester in the test transmits a Neighbor Advertisement for each Neighbor Cache Entry with a Source Link- layer Address Option containing a different cached address. The Override flag should be set. 3. Each tester transmits an Echo Request to the IUT and waits for an Echo Reply. 4. Disable all testers from responding to further Neighbor Solicitations.ETSI 26A.6.1 Basic IPv6 header A.6.1.1 Version!=4 PacketsThis subsection describes an example TP for conformance testing for “"Non-4 Version Packets”", the purpose is to ensure that an IPv6 IUT MUST be able to process Version=6 packets and discard Version={1-3, 5, 7-15} packets it receives.Test Identifier IP6_HDR_NOD_GEN_VIO_001 Test Objective To ensure that an IPv6 IUT is able to process Version=6 packets and discard Version={0-3, 5, 7- 15} packets it receives (Clause 5.1.1) Standard Reference RFC2460 [5] clause 3, figure 1 PICS Reference (in this document) Clause A.2 (only Version=0, 5, 7, 15 are tested) PIXIT Reference (in this document) Clause A. Pre-Conditions In the test configuration (shown in Figure A.1), run Common Test Setup A.6.1.1 Step Action Pass Condition Preamble None 1 The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT 2a The tester transmits an Echo request to the IUT with an In each of the three attempts, the tester does not IPv6 header having Version field set to 0; repeat three receive any invalid packet from the IUT within times 30 seconds 2b The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT 3a The tester transmits an Echo request to the IUT with an In each of the three attempts, the tester does not IPv6 header having Version field set to 5; repeat three receive any invalid packet from the IUT within times 30 seconds 3b The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT 4a The tester transmits an Echo request to the IUT with an In each of the three attempts, the tester does not IPv6 header having Version field set to 7; repeat three receive any invalid packet from the IUT within times 30 seconds 4b The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT 5a The tester transmits an Echo request to the IUT with an In each of the three attempts, the tester does not IPv6 header having Version field set to 15; repeat three receive any invalid packet from the IUT within times 30 seconds 5b The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT Postamble Run the common test postamble (clause A. 6.1.4) A.7.1.2 Version=4 PacketsThis subsection describes an example TP for conformance testing for “"Version 4”", the purpose is to ensure that an IPv6 IUT MAY be able to process Version=4 packets it receives. .Test identifier IP6_HDR_NOD_GEN_VIO_002 Test Objective To ensure that an IPv6 IUT is able to either discard or process Version=4 packets it receives (Clause 5.1.1) Standard Reference RFC2460 [5] clause 3, figure 1 PICS Reference (in this document) Clause A.2 (only Version=4 are tested) PIXIT Reference (in this document) Clause A.xx Pre-Conditions In test configuration (shown in Figure A.1), run the test setup A.6.1.1. Step Action Pass Condition Preamble None 1 The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT 2a The tester transmits an Echo request to the IUT with an In each of the three attempts, the tester does not IPv6 header having Version field set to 4; repeat three receive any invalid packet from the IUT within times 30 seconds 2b The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the ETSI 27IPv6 header having Version field set to 6 IUT 3a The tester transmits an Echo request to the IUT with an In each of the three attempts, the tester receives IPv4 header having Version field set to 4; repeat three an IPv4 echo response; does not receive any times invalid packet from the IUT within 30 seconds 3b The tester transmits an Echo request to the IUT with an The tester receives an Echo response from the IPv6 header having Version field set to 6 IUT Postamble Run common test postamble (clause A.6.1.4)A.8 TTCN-3 Abstract Test Suite***Annex B (informative): Part of example interoperability test specification (RFC2460 – IPv6 Specification) B.1 IntroductionThe following documentations comprise an interoperability test specification:- Interoperable Features Statement (IFS) Proforma- Abstract Test Architecture - Test Suite Structure (TSS)- Test Purposes (TP) - Test Description and/or TTCN-3 Test Suite- Interoperable Implementation eXtra Information for Testing (IIXIT) ProformaWhere, the formats of IFS proforma, IIXIT proforma are very similar to PICS proforma and PIXIT proforma in conformance test specification. This Appendix gives an example test specification (in part) for RFC2460 interoperability testing of an IUT. B.2 IFS ProformaThe supplier of a protocol implementation which is claimed to conform to Standard RFC 2460 may complete the following Interoperable Functions Statement (IFS) proforma if the implementation is to be submitted for interoperability testing.The following table gives an example part of IFS for RFC2460 interoperability testing. A.2.1 Implementation IdentificationSupplierContact point for queries about the IFSImplementation Name(s) and Version(s) (NOTE)Other information necessary for full identification - e.g., name(s) and version(s) for machines and/or operating systems; System name(s)NOTE The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model).ETSI 28A.2.2 Protocol Summary, IPv6 SpecificationProtocol version Addenda Implemented (if applicable) Amendments Implemented Date of StatementETSI 29A.2.3 IPv6 EntitiesTable A.1: IPv6 entities Item IPv6 entities Reference Support NE1 Host NE2 RouterComments:A.2.3.1 RolesTable A.2: Host rolesItem Role Reference Support HE1 Requesting host HE2 Responding host Comments: The roles ""requesting"" and ""responding"" apply to a host’s role regarding an end-to-end communication. Since a host is going to take both positions during its usage the capabilities are not listed separately in the following subsections. If there are capabilities that apply only for one role the status field will show a ""condition"" that will be explained below the corresponding table.Table A.3: Router rolesItem Role Reference Support RE1 Router Comments: A.2.3.2 Host capabilities A.2.3.2.1 Basic IPv6 functionalityTable A.4: Host basic functionalitiesItem Function Reference Status Support H_LLA Send to another host’s unicast link-local [5] … M address, and respond IPv6 packets destined to its link-local address H_SLA …Site-local address [5].. O H_GL …Global address [5].. M H_NO_FWD Drop IPv6 packets it receives which is [5].. M not destined to one of its addresses H_HOP_LMT Send IPv6 packets with different [5] M Hop_LimitComments:ETSI 30A.2.3.2.2 Advanced functionalitiesTable A.5: Host advanced capabilitiesItem Function Reference Status Support H_FRAG Fragment a packet if exceeding MTU [5] O H_REASM Reassemble received fragments [5] M belonging to a same IP packet H_DEH_CRT Create and send packets with a [5] O.1 destination option header H_DEH_PRO Perform special processing based on [5] O.1 the destination option header in packets it receives H_HBH_CRT Create and send packets witha hop- [5] O.1 by-hop option header H_HBH_PRO Perform special processing based on [5] O.1 a hop-by-hop option header in packets it receives H_ROH_CRT Create and send packets with a [5] O.1 routing header in packets H_ROH_PRO Process packets with a routing header [5] MComments: 1. If declared to support a given option type, must perform special processing for that type.A.2.3.2 Router capabilities… B.3 Abstract architectureFigure B. illustrates an example for general architecture for IPv6 interoperability testing. QE1Intervening network EUT (QE2) QE3Figure B.: General abstract architecture of IPv6 interoperability testingThis architecture can be further identified as several abstract architectures such as shown in Figure B.2, Figure B.3, Figure B.4 and Figure B.5.EUT QEFigure B.2: test architecture for an IPv6 host’s interoperability (without intervening network)ETSI 31QE Intervening QE network Figure B.3: test architecture for an IPv6 host’s interoperability (with intervening network)QE EUT QEFigure B.4: test architecture for an IPv6 router’s interoperability (without intervening network)QEEUT Intervening QE network Figure B.5: test architecture for an IPv6 host’s interoperability (with intervening network)B.3 References to base standardsRFC 2460 [], RFC 2461 [], RFC 3513 [], RFC 2461 [], RFC 2462 []. A.2.4 Test Suite StructureTest Suite Main Functionalities Role Functionalities subgroups Test group Identifier Basic Basic functionality Host Reachability V-I-O IP6_H_IOP_REACH interoperabili Hop limit V-I IP6_H_IOP_HOPLMT ty Router Reachability V-I-O IP6_R_IOP_REACH Hop limit V-I IP6_R_IOP_HOPLMT Advanced functionality Host Hop by hop option header V-I-O IP6_H_IOP_HBH Destination header V-I-O IP6_H_IOP_DEH Routing header V-I-O IP6_H_R_IOP_ROH Fragmentation V-I-O IP6_H_IOP_FRAG Reassembly V-I-O IP_H_IOP_REASM Router …B.2.5 IIXITSimilar to PIXIT and skip here.ETSI 32B.2.5 Test Purpose B.2.5.1 Basic Host Functionality B.2.5.1.1 ReachabilityGroupSelection: Source and destination addresses listed in RFC 2460[5] can be link local address, the test purpose is necessary to ensure an EUT will be able to respond and send packets to the QE locating in the same network using link-local address.Status: Mandatory B.2.5.1.1 Valid behaviourTPId: IP6_H_IOP_REACH_001Status: MandatoryRef: RFC 2460 [5], clause xPurpose: Ensure that the EUT is able to send packets to the QE’s link-local address in the same link using its link-local address.… B.2.6 Test Description B.2.6.1 Reachability through on-link, link-local addressTP Identifier IP6_H_IOP_REACH_001 TP Objective Ensure that the EUT is able to send packets to the QE’s link-local address in the same link using its link-local address. Standard Reference [5] clause 3; [6] clause 4; [7] clause 2.5, 2.8 IFS ref. PIXIT ref. Initial Conditions Abstract test architecture B.2, wait for 5 minutes after restarting both the NUT and the QE. Step Step description Pass Conditions Preamble 1 The QE transmits an IPv6 Echo The QE receives an Echo reply for its link local address from request to the EUT’s link local the EUT address 2 The EUT transmits an IPv6 Echo The QE receives an Echo reply for its link local address from request to the QE’s link local the EUT address PostambleB.2.6 TTCN-3 Abstract Test Suite***HistoryDocument history 12.12.03 First draftETSI

Guidelines for Writing Ipv6 Testing Specifications

Details

Download

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

Support