Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation July 26, 2003 Expires in January 2004 SS7 MTP2-User Adaptation Layer (M2UA) SS7 Test Specifications M2UA-SS7TEST Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress'. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html To learn the current status of any Internet-Draft, please check the Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This Internet-Draft provides information for the Internet community on the implementation of test cases for testing the SS7 MTP2-User Adaptation Layer [M2UA] Signalling Gateway (SG) based on the conformance test specifications for SS7 MTP Level 2 [Q.780..M2PATEST04]. B. Bidulock Version 0.0 Page 1 Internet-Draft M2UA-SS7TEST July 26, 2003 1. Introduction This draft provides details for implementation of testing of SS7 MTP-User Adaptation Layer [M2UA] Signalling Gateways (SG) based on the test specifications for SS7 MTP Level 2 [Q.780..M2PATEST04]. The general aspects for SS7 protocol testing [Q.780, M2PATEST04] describes the requirement for an MTP Level 3 Simulator in the test environment for SS7 MTP Level 2 testing [Q.781, M2PATEST04]. This MTP Level 3 Simulator is responsible for issuing and accepting request and indication primitives as well as sending and receiving signalling messages [Q.780, M2PATEST04]. This memo describes how the MTP Level 3 Simulator would use SS7 MTP2-User Adaptation Layer messages to test a Signalling Gateway implementation of [M2UA]. 1.1. Scope Although the SS7 MTP Level 2 test cases [Q.781, M2PATEST04] are applicable in entirety to SS7 signalling links implemented at the M2UA Signalling Gateway, this memo details the mapping of M2UA messages to SS7 Message Transfer Part (MTP) Signalling Link [Q.703, M2PA09] signals used in the SS7 MTP Level 2 tests [Q.781, M2PATEST04]. 1.2. Abbreviations ANSI --American National Standards Institute. ASP --Application Server Process. BSNT --Backward Sequence Number Transmitted. CPT --Compatibility Test. ETSI --European Telecommunications Standards Institute. FSNC --Forward Sequence Number Confirmed. I-D --Internet-Draft. IETF --Internet Engineering Task Force. IOT --Interoperability Test. IPSP --IP Signalling Point. ITU --International Telecommunications Union. IUT --Implementation Under Test. M2PA --SS7 MTP2-User Peer-to-Peer Adaptation Layer. M2UA --SS7 MTP2-User Adaptation Layer. MTP2 --MTP Level 2. MTP --Message Transfer Part. PT --Protocol Tester. RFC --Request For Comments. RTB --Retransmission Buffer. SCTP --Stream Control Transmission Protocol. SG --Signalling Gateway. SGP --Signalling Gateway Process. SP --Signalling Point. SS7 --Signalling System No. 7. TC --Test Case. B. Bidulock Version 0.0 Page 2 Internet-Draft M2UA-SS7TEST July 26, 2003 TS --Test Suite. VAT --Validation Test. 1.3. Terminology Compatibility Test (CPT)-- A test where multiple implementations are tested in interaction with each other to test for compatibility between implementations. Implementation Under Test (IUT)-- An implementation being tested (the object of testing) as part of a validation, compatibility or interoperability test within the test environment. Interoperability Test (IOT)-- A test where multiple implementations are tested in interaction with each other to test for interoperability between implementations. M2UA Monitor-- A device or function used to monitor, capture, record and analyze the exchange of M2UA messages across and IP network between implementations or protocol testers. This device function may be integrated with a protocol tester. MTP Level 3 Simulator-- A device or function used to simulate the SS7 MTP Level 3 [Q.704] to SS7 MTP Level 2 [Q.703, M2PA09] implementation. This device or function may be integrated within the Test Environment. This device or function is normally required for SS7 MTP Level 2 Test Specifications [Q.781, M2PA09] validation, compatibility or interoperability tests. Protocol Tester (PT)-- A device or function used to generate normal or abnormal messages and test sequences for the purpose of validation testing. Signalling Link-- A signalling link, SS7 [Q.703] or M2PA [M2PA09], used to carry SS7 MTP Level 2 signalling between IUT and PT. Test Case-- A particular sequence of messages and patters that make up a single validation, compatibility or interoperability test. Test Environment-- The environment that contains the testing device and functiosn necessary and sufficient for executing a test suite. Test Suite-- A collection of test cases meant to acheive a specific objective of validation, compatibility or interoperability testing. Validation Test (VAT)-- A test where a single implementation is tested in interaction with a protocol tester to test for validation of the implementation to a technical specification. B. Bidulock Version 0.0 Page 3 Internet-Draft M2UA-SS7TEST July 26, 2003 1.4. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [RFC 2119]. 2. Test Environment The test environment for SS7 MTP Level 2 [Q.781, M2PATEST04] testing is described in the General Aspects of SS7 testing [Q.780, M2PATEST04]. There are two types of testing that are accomodated as follows: Validation Testing -- consists of validating a single Implementation Under Test (IUT). This is performed by connecting the IUT to a Protocol Tester (PT) within the test enviroment. Validation testing is more extensive that compatibility testing. This is because it is possible, with the use of the Protocol Tester (PT), to generate messages and patterns, that cannot normally be generated from an implementation, to test the response of the Implementation Under Test (IUT) to abnormal conditions. Compatibility Testing -- consists of testing the compatiability of one Implementation Under Test (IUT) with another. This is performed by connecting the IUTs together within the test environment. Compatibility testing is less extensive than validation testing. This is because it is not normally possible to generate non- compliant test patterns with an implementation that conforms to validation testing. However, compatibility tests are better at testing the interoperability of two implementations. Interoperability Testing -- consists of testing the interoperability of one Implementation Under Test (IUT) with another. This is performed by connecting the IUT together within the test environment. Interoperability testing is more extensive than compatibility testing and less extensive than validation testing. Where compatibility testing assumes that the IUT have passed validation testing, interoperability testing makes no such assumption. In addition, the test environment is expected to have more control over the IUT in interoperability testing than in compatibility testing. It may be possible to generate some message and command or response sequences that would not normally by possible with an IUT during compatibility testing. The objectives of interoperability testing are often different than compatibility testing. The object of compatibility testing is to assure that an implementation that passes validation testing is, in other respects not tested by validation testing, compatible with other such implementations. The object of interoperability B. Bidulock Version 0.0 Page 4 Internet-Draft M2UA-SS7TEST July 26, 2003 testing is to show that there exist implementations with which each of the IUT being tested can indeed function. Although they have different objectives, the test environment configuration for interoperability testing is the same as that for compatibility testing. 2.1. Test Configurations This section details the Validation and Compatibility test configurations used for testing M2UA SG and ASP for SS7 MTP Level 2 conformance. 2.1.1. Validation Test Configuration Validation testing consists of validating a single Implementation Under Test (IUT) for SS7 MTP Level 2 conformance. Several test configurations can be used with M2UA Signalling Gateways (SG) and Application Server Processes (ASP) as follows: 2.1.1.1. SS7 Validation Test Configuration Figure 1 illustrates the Validation Test configuration. As described in the SS7 Test Specification [Q.780, M2PATEST04], the SS7 Level 2 validation testing environment consists of the following components: (1) The Implementation Under Test (IUT) that is being validated a position "SP A". _____________________________________________________________ | | | TEST ENVIRONMENT | | MTP Level 3 Simulator | | ___________ _____|_____ | | | | | | | | | PT |____________________| IUT | | | | SP B | | Signalling | SP A | | | |___________| | Link |___________| | | SS7 PT | M2UA SG | | | | | ____|____ | | | | | | | Link | | | | Monitor | | | |_________| | | | |_____________________________________________________________| Figure 1. Validation Test Configuration #1 B. Bidulock Version 0.0 Page 5 Internet-Draft M2UA-SS7TEST July 26, 2003 (2) The MTP Level 3 Simulator attached to the IUT at position "SP A". (3) The Protocol Tester (PT) performing validation tests at position "SP B". (4) A Signalling Link [Q.703 or M2PA09] between the PT at position "SP B" and the IUT at position "SP A". (5) A Link Monitor monitoring the message exchange accross the Signalling Link [Q.703 or M2PA09]. This function MAY be integrated with the Protocol Tester or the Test Environment. For this configuration, the interface between the Implementation Under Test (IUT) and the MTP Level 3 Simulator is that described in the SS7 Test Specification [Q.780, M2PATEST04]. This is the normal configuration for SS7 MTP Level 2 testing [Q.781, M2PATEST04] and is not modified by this memo. Normal SS7 MTP Level 2 testing SHOULD be performed on the M2UA SG before performing validation, compatibility or interoperability tests in the other configurations described in this memo. 2.1.1.2. SG Validation Test Configuration Figure 2 illustrates the Validation Test configuration. As described in the SS7 Test Specification [Q.780, M2PATEST04], the SS7 Level 2 validation testing environment consists of the following components: _____________________________________________________________ | | | TEST ENVIRONMENT | | MTP Level 3 Simulator | | | | | M2UA | SCTP | | | Association | | ___________ _____|_____ | | | | | | | | | PT |____________________| IUT | | | | SP B | | Signalling | SP A | | | |___________| | Link |___________| | | SS7 PT | M2UA SG | | | | | ____|____ | | | | | | | Link | | | | Monitor | | | |_________| | | | |_____________________________________________________________| Figure 2. Validation Test Configuration #2 B. Bidulock Version 0.0 Page 6 Internet-Draft M2UA-SS7TEST July 26, 2003 (1) The Implementation Under Test (IUT) that is being validated at position "SP A". (2) An MTP Level 3 Simulator attached to the IUT at position "SP A". (3) The Protocol Tester (PT) performing validation tests at position "SP B". (4) A Signalling Link [Q.703 or M2PA09] between the PT at position "SP B" and the IUT at position "SP A". (5) A Link Monitor monitoring the message exchange accross the Signalling Link [Q.703 or M2PA09]. This function MAY be integrated with the Protocol Tester or the Test Environment. In addition, this memo specifies the interface between the Implementation Under Test (IUT) and the MTP Level 3 Simulator [Q.780, M2PATEST04] within the test environment. The MTP Level 3 Simulator SHALL be attached to the IUT a position "SP A" using an M2UA SCTP Association. The MTP Level 3 Simulator SHALL inject and collect M2UA messages to and from the IUT during the performance of SS7 MTP Level 2 testing [Q.781, M2PATEST04]. The MTP Level 3 Simulator SHALL inject and collect the M2UA messages as decribed in Section 4 of this document. 2.1.1.3. SG-ASP Validation Test Configuration Figure 3 illustrates a Validation Test Configuration that includes an ASP in the validation tests. In this case the MTP Level 3 Simulator is connected at the ASP rather than directly to the SG. In this configuration, the combination of ASP and SG form the Implementation Under Test (IUT). For this configuration the interface between the MTP Level 3 Simulator and the M2UA ASP is the same as for normal SS7 MTP Level 2 Testing [Q.780..M2PATEST04]. The test envirnoment SHOULD include monitoring of the M2UA SCTP Association to ensure the mapping between SS7 MTP Level 2 [Q.703, M2PA09] signals, SS7 MTP Level 2 Test Specification [Q.781, M2PATEST04] commands, and SS7 MTP2-User Adaptation Layer [M2UA] messages as described in Section 4. 2.1.2. Compatibility Test Configurations Compatibility testing consists of testing two Implementations Under Test (IUT) for compatibility with each other. Several test configurations can be used with M2UA Signalling Gateways (SG) and Application Server Processes (ASP) as follows: 2.1.2.1. SS7 Compatibility Test Configuration Figure 4 illustrates the Compatibility Test configuration. As described in the SS7 Test Specification [Q.780, M2PATEST04], The SS7 B. Bidulock Version 0.0 Page 7 Internet-Draft M2UA-SS7TEST July 26, 2003 _____________________________________________________________ | | | TEST ENVIRONMENT | | MTP Level 3 Simulator | | _____|_____ | | | | | | | IUT | M2UA | | | SP A | ASP | | |___________| | | | | | M2UA | SCTP | | | Association | | ___________ _____|_____ | | | | | | | | | PT |____________________| IUT | | | | SP B | | Signalling | SP A | | | |___________| | Link |___________| | | Protocol | M2UA SG | | Tester | | | ____|____ | | | | | | | Link | | | | Monitor | | | |_________| | | | |_____________________________________________________________| Figure 3. Validation Test Configuration #3 _____________________________________________________________ | | | TEST ENVIRONMENT | | | | MTP Level 3 Simulator MTP Level 3 Simulator | | _____|_____ _____|_____ | | | | | | | | | IUT |____________________| IUT | | | | SP B | | Signalling | SP A | | | |___________| | Link |___________| | | M2UA SG | M2UA SG | | | | | ____|____ | | | | | | | Link | | | | Monitor | | | |_________| | | | |_____________________________________________________________| Figure 4. Compatibility Test Configuration #1 Level 2 compatibility testing environment consists of the following components: B. Bidulock Version 0.0 Page 8 Internet-Draft M2UA-SS7TEST July 26, 2003 (1) One Impementation Under Test (IUT) for compatibility testing at position "SP A". (2) An MTP Level 3 Simulator attached to the IUT at position "SP A". (3) Another Impementation Under Test (IUT) for compatibility testing at position "SP B". (4) Another MTP Level 3 Simulator attached to the IUT at position "SP B". (5) A Signalling Link [Q.703 or M2PA09] between IUT at position "SP A" and IUT at position "SP B". (6) A Link Monitor monitoring the message exchange accross the Signalling Link [Q.703 or M2PA09]. For this configuration, the interface between each Implementation Under Test (IUT) and the MTP Level 3 Simulator is that described in the SS7 Test Specifications [Q.780, M2PATEST04]. This is the normal configuration for SS7 MTP Level 2 testing [Q.781, M2PATEST04] and is not modified by this memo. Normal SS7 MTP Level 2 testing SHOULD be peformed on the M2UA SG before performing compatibility tests in the other configurations described in this memo. 2.1.2.2. SG Compatibility Test Configuration _____________________________________________________________ | | | TEST ENVIRONMENT | | | | MTP Level 3 Simulator MTP Level 3 Simulator | | | | | | M2UA | SCTP M2UA | SCTP | | | Association | Association | | _____|_____ _____|_____ | | | | | | | | | IUT |____________________| IUT | | | | SP B | | Signalling | SP A | | | |___________| | Link |___________| | | M2UA SG | M2UA SG | | | | | ____|____ | | | | | | | Link | | | | Monitor | | | |_________| | | | |_____________________________________________________________| Figure 5. Compatibility Test Configuration #2 B. Bidulock Version 0.0 Page 9 Internet-Draft M2UA-SS7TEST July 26, 2003 Figure 5 illustrates the Compatibility Test configuration. As described in the SS7 Test Specification [Q.780, M2PATEST04], The SS7 Level 2 compatibility testing environment consists of the following components: (1) One Impementation Under Test (IUT) for compatibility testing at position "SP A". (2) An MTP Level 3 Simulator attached to the IUT at position "SP A". (3) Another Impementation Under Test (IUT) for compatibility testing at position "SP B". (4) Another MTP Level 3 Simulator attached to the IUT at position "SP B". (5) A Signalling Link [Q.703 or M2PA09] between IUT at position "SP A" and IUT at position "SP B". (6) A Link Monitor monitoring the message exchange accross the Signalling Link [Q.703 or M2PA09]. In addition, this memo specifies the interface between the Implementation Under Test (IUT) and the MTP Level 3 Simulator [Q.780, M2PATEST04] within the test environment. The MTP Level 3 Simulators SHALL be attached to the IUT at position "SP A" and the IUT at position "SP B" using an M2UA SCTP Association. The MTP Level 3 Simulator SHALL inject and collect M2UA messages to and from the IUT during the performance of SS7 MTP Level 2 testing [Q.781, M2PATEST04]. The MTP Level 3 Simulator SHALL inject and collect the M2UA messages as decribed in Section 4 of this document. 2.1.2.3. SG-ASP Compatibility Test Configuration Figure 6 illustrates a Compatibility Test Configuration that includes an ASP in the compatibility tests. In this case the MTP Level 3 Simulator is connected at the ASP rather than directly to the SGs. IN this configuration, the combination of each ASP and SG form the two Implementations Under Test (IUT). For this configuration, the interface between the MTP Level 3 Simulator and the M2UA ASP is the same as for normal SS7 MTP Level 2 Testing [Q.780..M2PATEST04]. The test environment SHOULD include monitoring of the M2UA SCTP Association to ensure the mapping between SS7 MTP Level 2 [Q.703, M2PA09] signals, SS7 MTP Level 2 Test Specification [Q.781, M2PATEST04] commands, and SS7 MTP2-User Adaptation Layer [M2UA] messages as described in Section 4. 2.2. Testing Methodologies B. Bidulock Version 0.0 Page 10 Internet-Draft M2UA-SS7TEST July 26, 2003 _____________________________________________________________ | | | TEST ENVIRONMENT | | | | MTP Level 3 Simulator MTP Level 3 Simulator | | _____|_____ _____|_____ | | | | | | | | | IUT | M2UA | IUT | M2UA | | | SP A | ASP | SP B | ASP | | |___________| |___________| | | | | | | M2UA | SCTP M2UA | SCTP | | | Association | Association | | _____|_____ _____|_____ | | | | | | | | | IUT |____________________| IUT | | | | SP A | | Signalling | SP B | | | |___________| | Link |___________| | | M2UA SG | M2UA SG | | | | | ____|____ | | | | | | | Link | | | | Monitor | | | |_________| | | | |_____________________________________________________________| Figure 6. Compatibility Test Configuration #3 2.2.1. Test Sequence Testing of a particular M2UA SG implementation SHOULD be performed in the following order. (1) Validation Test Configuration #1 -- validation tests [Q.781 or M2PATEST04] directly. (2) Validation Test Configuration #2 -- validation tests [Q.781 or M2PATEST04] with M2UA interface between SG and MTP Level 3 Simulator. (3) Compatibility Test Configuration #1 -- compatibility tests [Q.781 or M2PATEST04] directly. (4) Compatibility Test Configuration #2 -- compatibility tests [Q.781 or M2PATEST04] with M2UA interface between SG and MTP Level 3 Simulator. Testing of a particular M2UA ASP implementation against an SG implementation (already tested per above) SHOULD be performed in the following order: B. Bidulock Version 0.0 Page 11 Internet-Draft M2UA-SS7TEST July 26, 2003 (5) Validation Test Configuration #3 -- validation tests [Q.781 or M2PATEST04] directly, with SG/ASP interaction within the IUT. (6) Compatibility Test Configuration #3 -- compatibility tests [Q.781 or M2PATEST04] directly, with SG/ASP interaction within the IUT. In addtion, validation testing of the M2UA protocol between ASP and SG SHOULD be performed independent of SS7 MTP Level 2 validation testing in accordance with a validation test suite for M2UA[1]. Also, compatibility testing of the M2UA protocol between ASP and SG SHOULD be performed independent of SS7 MTP Level 2 compatibility testing in accordance with a compatibility test suite for M2UA[2]. The normal methodology for testing SS7 MTP Level 2 [Q.781, M2PATEST04] is to perform validation testing on an IUT before performing compatibility testing. The tests presented in [Q.781 and M2PATEST04] test the functionality of the MTP Level 2 state machines; however, they do not adequately test the L2 to L3 interface. To complete validation and compatibility testing of M2UA, the validation and compatibility tests presented in the SS7 MTP Level 3 Test Specification [Q.782] SHOULD be performed with the M2UA ASP in the test environment to assure that the M2UA IUT has properly implemented the L2 to L3 interface. The test environment for executing [Q.782] tests are outside the scope of this document. (7) MTP Level 3 Validation Tests -- validation tests [Q.781] performed with SG/ASP interaction within the IUT. (8) MTP Level 3 Compatibility Tests -- compatibility tests [Q.781] performed with SG/ASP interaction within the IUT. Notes for Section 2 [1] At the time of writing this memo, there did not exist an IETF validation test suite specification for the M2UA protocol. The author of this memo is working on the development of such a specification. [2] At the timer of writing this memo, there did not exist an IETF compatibility test suite specificaiton for the M2UA protocol. There does exist, however, several M2UA Interop test plans that come close to such a specification. The author of this memo is also working on the development of such a specification. 3. Tests This section details the validation and compatibility tests to be performed. B. Bidulock Version 0.0 Page 12 Internet-Draft M2UA-SS7TEST July 26, 2003 3.1. Test Cases In each test configuration, the applicable Validation tests or Compatibility tests of the SS7 MTP Level 2 Test Specification [Q.781, M2PATEST04], or other applicatble SS7 MTP Level 2 test specification, SHALL be performed. 4. Mapping of Signals The mapping of SS7 MTP Level 2 [Q.703, M2PA09] signals, SS7 MTP Level 2 Test [Q.781, M2PATEST04] commands, and SS7 MTP2-User Adaptation Layer [M2UA] messages are listed in Table 1. Each [Q.703, M2PA09] signal SHALL be mapped onto a [Q.781, M2PATEST04] command or indication and onto a [M2UA] message. When the SS7 MTP Level 2 [Q.781, M2PATEST04] test case calls for a given [Q.703, M2PA09] signal or [Q.781, M2PATEST04] command or indication, the corresponding [M2UA] message SHALL be injected or collected by the MTP Level 3 Simulator. Table 1. Mapping of Q.703 Signals, Q.781 Commands and M2UA Messages M2UA | M2UA | Q.703 | Q.781 Message | Parameter | Signal | Notation ------------+----------------------+--------------+------------ ESTABLISH | | Start | :start Request | | | ------------+----------------------+--------------+------------ ESTABLISH | | In Service | <1> Confirm | | | ------------+----------------------+--------------+------------ RELEASE | | Stop | :stop Request | | | ------------+----------------------+--------------+------------ RELEASE | | <5> | <5> Confirm | | | ------------+----------------------+--------------+------------ RELEASE | | Link | <2> Indication | | Failure | ------------+----------------------+--------------+------------ STATE | STATUS_LPO_SET | Local | :set LPO Request | | Processor | | | Outage | +----------------------+--------------+------------ | STATUS_LPO_CLR | Local | :clear LPO | | Processor | | | Recovered | +----------------------+--------------+------------ | STATUS_EMER_SET | Emergency | :set EM +----------------------+--------------+------------ | STATUS_EMER_CLR | Emergency | :clear EM | | Ceases | +----------------------+--------------+------------ B. Bidulock Version 0.0 Page 13 Internet-Draft M2UA-SS7TEST July 26, 2003 M2UA | M2UA | Q.703 | Q.781 Message | Parameter | Signal | Notation ------------+----------------------+--------------+------------ | STATUS_FLUSH_BUFFERS | Flush | <3> | | Buffers | +----------------------+--------------+------------ | STATUS_CONTINUE | Continue | <3> +----------------------+--------------+------------ | STATUS_CLEAR_RTB | Clear | <3> | | RTB | +----------------------+--------------+------------ | STATUS_CONG_ACCEPT | Congestion | <4> | | Accept | +----------------------+--------------+------------ | STATUS_CONG_DISCARD | Congestion | :make | | Discard | congestion | | | state +----------------------+--------------+------------ | STATUS_CONG_CLEAR | No | :clear | | Congestion | congestion | | | state ------------+----------------------+--------------+------------ STATE | | <5> | <5> Confirm | | | ------------+----------------------+--------------+------------ STATE | EVENT_RPO_ENTER | Remote | <9> Indication | | Processor | | | Outage | +----------------------+--------------+------------ | EVENT_RPO_EXIT | Remote | <9> | | Processor | | | Recovered | ------------+----------------------+--------------+------------ DATA | ACTION_RTRV_BSN | Retrieve | <7> RETRIEVAL | | BSNT | Request +----------------------+--------------+------------ | ACTION_RTRV_MSGS | Retrieval | <7> | | Request | | | and FSNC | ------------+----------------------+--------------+------------ DATA | ACTION_RTRV_MSGS | Retrieved | <7> RETRIEVAL | | Message | Confirm +----------------------+--------------+------------ | ACTION_RTRV_BSN | BSNT | <7> ------------+----------------------+--------------+------------ DATA | | Retrieval | <7> RETRIEVAL | | Complete | COMPLETE | | | Indication | | | ------------+----------------------+--------------+------------ CONGESTION | | <6> | <6> Indication | | | ------------+----------------------+--------------+------------ B. Bidulock Version 0.0 Page 14 Internet-Draft M2UA-SS7TEST July 26, 2003 M2UA | M2UA | Q.703 | Q.781 Message | Parameter | Signal | Notation ------------+----------------------+--------------+------------ DATA | | <5> | <5> Acknowledge | | | ------------+----------------------+--------------+------------ DATA | | Message | <8> Request | | for | | | Transmission | ------------+----------------------+--------------+------------ DATA | | Received | Indication | | Message | ------------+----------------------+--------------+------------ <10> | | Power On | :power ON ------------+----------------------+--------------+------------ <10> | | -- | :tx break ------------+----------------------+--------------+------------ Notes for Table 1: <1> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not provide a notation for "In Service" indication; however, in a number of test cases it is necessary to establish that the link is in the "In Service" state. The ESTABLISH Confirm [M2UA] message sent by the SG can be used to confirm that the link has acheived the "In Service" state. <2> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not provide a notation for "Link Failure" indication; however, in a number of test cases it is necessary to establish that the link has failed. The RELEASE Indication [M2UA] message sent by the SG can be used to confirm that the link has failed. <3> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not provide a notation for "Flush Buffers," "Clear RTB," "Continue," or "Resume." However, use of these primitives is necessary in some test cases (e.g. test case 4.1 [Q.781], test case 3.4.1 [M2PATEST04]). The STATE Request [M2UA] message with the STATUS_FLUSH_BUFFERS, STATUS_CLEAR_RTB or STATUS_CONTINUE state values SHOULD be used to perform these functions. <4> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not require the use of this request. <5> There are no SS7 MTP Level 2 [Q.703, M2PA09] signals or SS7 MTP Level 2 Test [Q.781, M2PATEST04] actions that correspond to these [M2UA] messages; however, these messages are required by the [M2UA] specifications and it SHOULD be verified that the SG issues these messages to the test enviroment under the appropriate conditions during testing. B. Bidulock Version 0.0 Page 15 Internet-Draft M2UA-SS7TEST July 26, 2003 <6> Although SS7 MTP Level 2 [Q.703, M2PA09] provides signals to SS7 MTP Level 3 [Q.704] indicating congesiton onset and abatement that use these [M2UA] messages, SS7 MTP Level 2 Tests [Q.781, M2PATEST04] do not perform congestion testing that would generate these indications to the test environment. <7> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not test retrieval. Retrieval tests are performed by SS7 MTP Level 3 testing [Q.782]. <8> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not have a notation for signalling messages (other than indicating that an MSU is sent or received); however, signalling messages are exchanged between L2 and L3 as a normal course of most of the SS7 MTP Level 2 tests [Q.781, M2PATEST04]. <9> MTP Level 2 Test Specifications [Q.781, M2PATEST04] do not provide a notation for "Remote Processor Outage" or "Remote Processor Recovered" indications. These indications are not required in SS7 MTP Level 2 tests [Q.781, M2PATEST04]; however, these indications SHOULD be delivered to the test environment on entry and exit from the "Remote Processour Outage" state. <10> MTP Level 2 Test Specifications [Q.781, M2PATEST04] defines these signals, and these signals are required within the test environment [Q.780, M2PATEST04]; however, these signals are outside the scope of the SS7 MTP2-User Adaptation Layer [M2UA] protocol and SHOULD be generated by other means. Note that it is possible that some implementations might use the REGISTRATION Request or ASP-ACTIVE [M2UA] messages for powering on the signalling link. All of the applicable validation or compatibility tests of the SS7 MTP Level 2 Test Specification [Q.781, M2PATEST04] SHALL be performed in this fashion with the mapping presented in Table 1. For other SS7 Conformance Test Specifications, a similar mapping and the test configurations presented SHOULD be used. 5. Examples Security Considerations There are no security considerations for this draft. IANA Considerations There are no IANA considerations for this draft. B. Bidulock Version 0.0 Page 16 Internet-Draft M2UA-SS7TEST July 26, 2003 0. Change History This section provides historical information on the changes made to this draft. This section will be removed from the document when the document is finalized. 0.0. Version 0.0 This is the first version of this document. 0.0.0. Change Log $Log: draft-bidulock-sigtran-m2ua-ss7test-00.me,v $ Revision 0.8.2.3 2003/07/28 13:10:34 brian Reformatting. Revision 0.8.2.2 2003/07/27 08:15:27 brian Checking in changes. Revision 0.8.2.1 2003/07/26 23:19:03 brian Minor corrections to table. Revision 0.8 2003/07/26 19:10:57 brian Added new drafts. B. Bidulock Version 0.0 Page 17 Internet-Draft M2UA-SS7TEST July 26, 2003 R. References R.1. Normative References [M2UA] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and Heitz, J., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer," RFC 3331, Internet Engineering Task Force - Signalling Transport Working Group (September, 2002). [Q.780] ITU, "Signalling System No. 7 Test Specification -- General Description," ITU-T Recommendation Q.780, ITU-T Telecommunication Standardization Sector of ITU, Geneva (October 1995). (Previously "CCITT Recommendation") [Q.781] ITU, "Signalling System No. 7 - MTP Level 2 Test Specification," ITU-T Recommendation Q.781, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [M2PATEST04] Bidulock, B., "SS7 MTP-User Peer-to-Peer Adaptation Layer Test Specifications (M2PA-TEST)," , Internet Engineering Task Force - Signalling Transport Working Group (July 26, 2003). Work In Progress. [Q.703] ITU, "Signalling System No. 7 - Signalling Link," ITU-T Recommendation Q.703, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [M2PA09] George, T., Bidulock, B., Dantu, R., Kalla, M., Schwarzbauer, H. J. and Morneault, K., "SS7 MTP2-User Peer-to- Peer Adaptation Layer," , Internet Engineering Task Force - Signalling Transport Working Group (June 29, 2003). Work In Progress. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119 - BCP 14, The Internet Society (March 1997). R.2. Informative References [Q.704] ITU, "Message Transfer Part - Signalling Network Functions and Messages," ITU-T Recommendation Q.704, ITU-T Telecommunication Standardization Sector of ITU, Geneva (March 1993). (Previously "CCITT Recommendation") [Q.782] ITU, "Specifications of Signalling System No. 7 -- Test Specification -- MTP Level 3 Test Specification," ITU-T Recommendation Q.782, ITU-T Telecommunication Standardization Sector of ITU, Geneva (July 1996). (Previously "CCITT Recommendation") B. Bidulock Version 0.0 Page 18 Internet-Draft M2UA-SS7TEST July 26, 2003 Author's Addresses Brian Bidulock Phone: +1-780-490-1141 OpenSS7 Corporation Email: bidulock@openss7.org 1469 Jeffreys Crescent URL: http//www.openss7.org/ Edmonton, AB T6L 6T1 Canada This draft expires January 2004. B. Bidulock Version 0.0 Page 19 Internet-Draft M2UA-SS7TEST July 26, 2003 List of Tables Table 1. Mapping of Q.703 Signals, Q.781 Commands and M2UA Messages ..................................................... 13 List of Illustrations Figure 1. Validation Test Configuration #1 ...................... 5 Figure 2. Validation Test Configuration #2 ...................... 6 Figure 3. Validation Test Configuration #3 ...................... 8 Figure 4. Compatibility Test Configuration #1 ................... 8 Figure 5. Compatibility Test Configuration #2 ................... 9 Figure 6. Compatibility Test Configuration #3 ................... 11 Table of Contents Status of this Memo ............................................. 1 Copyright ....................................................... 1 Abstract ........................................................ 1 1 Introduction .................................................. 2 1.1 Scope ....................................................... 2 1.2 Abbreviations ............................................... 2 1.3 Terminology ................................................. 3 1.4 Conventions ................................................. 4 2 Test Environment .............................................. 4 2.1 Test Configurations ......................................... 5 2.1.1 Validation Test Configuration ............................. 5 2.1.2 Compatibility Test Configurations ......................... 7 2.2 Testing Methodologies ....................................... 10 2.2.1 Test Sequence ............................................. 11 Notes for Section 2 ............................................. 12 3 Tests ......................................................... 12 3.1 Test Cases .................................................. 13 4 Mapping of Signals ............................................ 13 5 Examples ...................................................... 16 Security Considerations ......................................... 16 IANA Considerations ............................................. 16 0 Change History ................................................ 17 0.0 Version 0.0 ................................................. 17 0.0.0 Change Log ................................................ 17 R References .................................................... 18 R.1 Normative References ........................................ 18 R.2 Informative References ...................................... 18 Author's Addresses .............................................. 19 List of Tables .................................................. 20 List of Illustrations ........................................... 20 Table of Contents ............................................... 20 B. Bidulock Version 0.0 Page 20 Internet-Draft M2UA-SS7TEST July 26, 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedure for copyrights defined in the Internet Standards process must be followed, or as required to translate into languages other than English. The limited permission granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. B. Bidulock Version 0.0 Page 21