Network Working Group Brian Bidulock INTERNET-DRAFT OpenSS7 Corporation October 16, 2005 Expires in April 2006 SS7 MTP2-User Adaptation Layer (M2UA) SS7 Test Specifications M2UA-SS7TEST Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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. This Internet-Draft will expire in April 2006. Copyright Copyright (C) The Internet Society (2005). 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..M2PATEST05]. B. Bidulock Version 0.2 Page 1 Internet-Draft M2UA-SS7TEST October 16, 2005 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..M2PATEST05]. The general aspects for SS7 protocol testing [Q.780, M2PATEST05] describes the requirement for an MTP Level 3 Simulator in the test environment for SS7 MTP Level 2 testing [Q.781, M2PATEST05]. 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, M2PATEST05]. 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, M2PATEST05] 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, M2PA] signals used in the SS7 MTP Level 2 tests [Q.781, M2PATEST05]. 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.2 Page 2 Internet-Draft M2UA-SS7TEST October 16, 2005 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, M2PA] 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, M2PA] 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 [M2PA], 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.2 Page 3 Internet-Draft M2UA-SS7TEST October 16, 2005 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, M2PATEST05] testing is described in the General Aspects of SS7 testing [Q.780, M2PATEST05]. 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.2 Page 4 Internet-Draft M2UA-SS7TEST October 16, 2005 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, M2PATEST05], 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.2 Page 5 Internet-Draft M2UA-SS7TEST October 16, 2005 (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 M2PA] 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 M2PA]. 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, M2PATEST05]. This is the normal configuration for SS7 MTP Level 2 testing [Q.781, M2PATEST05] 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, M2PATEST05], 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.2 Page 6 Internet-Draft M2UA-SS7TEST October 16, 2005 (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 M2PA] 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 M2PA]. 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, M2PATEST05] 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, M2PATEST05]. 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..M2PATEST05]. The test envirnoment SHOULD include monitoring of the M2UA SCTP Association to ensure the mapping between SS7 MTP Level 2 [Q.703, M2PA] signals, SS7 MTP Level 2 Test Specification [Q.781, M2PATEST05] 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, M2PATEST05], The SS7 B. Bidulock Version 0.2 Page 7 Internet-Draft M2UA-SS7TEST October 16, 2005 _____________________________________________________________ | | | 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.2 Page 8 Internet-Draft M2UA-SS7TEST October 16, 2005 (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 M2PA] 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 M2PA]. 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, M2PATEST05]. This is the normal configuration for SS7 MTP Level 2 testing [Q.781, M2PATEST05] 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.2 Page 9 Internet-Draft M2UA-SS7TEST October 16, 2005 Figure 5 illustrates the Compatibility Test configuration. As described in the SS7 Test Specification [Q.780, M2PATEST05], 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 M2PA] 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 M2PA]. In addition, this memo specifies the interface between the Implementation Under Test (IUT) and the MTP Level 3 Simulator [Q.780, M2PATEST05] 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, M2PATEST05]. 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..M2PATEST05]. The test environment SHOULD include monitoring of the M2UA SCTP Association to ensure the mapping between SS7 MTP Level 2 [Q.703, M2PA] signals, SS7 MTP Level 2 Test Specification [Q.781, M2PATEST05] commands, and SS7 MTP2-User Adaptation Layer [M2UA] messages as described in Section 4. 2.2. Testing Methodologies B. Bidulock Version 0.2 Page 10 Internet-Draft M2UA-SS7TEST October 16, 2005 _____________________________________________________________ | | | 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 M2PATEST05] directly. (2) Validation Test Configuration #2 -- validation tests [Q.781 or M2PATEST05] with M2UA interface between SG and MTP Level 3 Simulator. (3) Compatibility Test Configuration #1 -- compatibility tests [Q.781 or M2PATEST05] directly. (4) Compatibility Test Configuration #2 -- compatibility tests [Q.781 or M2PATEST05] 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.2 Page 11 Internet-Draft M2UA-SS7TEST October 16, 2005 (5) Validation Test Configuration #3 -- validation tests [Q.781 or M2PATEST05] directly, with SG/ASP interaction within the IUT. (6) Compatibility Test Configuration #3 -- compatibility tests [Q.781 or M2PATEST05] 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, M2PATEST05] is to perform validation testing on an IUT before performing compatibility testing. The tests presented in [Q.781 and M2PATEST05] 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.2 Page 12 Internet-Draft M2UA-SS7TEST October 16, 2005 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, M2PATEST05], 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, M2PA] signals, SS7 MTP Level 2 Test [Q.781, M2PATEST05] commands, and SS7 MTP2-User Adaptation Layer [M2UA] messages are listed in Table 1. Each [Q.703, M2PA] signal SHALL be mapped onto a [Q.781, M2PATEST05] command or indication and onto a [M2UA] message. When the SS7 MTP Level 2 [Q.781, M2PATEST05] test case calls for a given [Q.703, M2PA] signal or [Q.781, M2PATEST05] 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.2 Page 13 Internet-Draft M2UA-SS7TEST October 16, 2005 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.2 Page 14 Internet-Draft M2UA-SS7TEST October 16, 2005 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, M2PATEST05] 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, M2PATEST05] 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, M2PATEST05] 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 [M2PATEST05]). 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, M2PATEST05] do not require the use of this request. <5> There are no SS7 MTP Level 2 [Q.703, M2PA] signals or SS7 MTP Level 2 Test [Q.781, M2PATEST05] 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.2 Page 15 Internet-Draft M2UA-SS7TEST October 16, 2005 <6> Although SS7 MTP Level 2 [Q.703, M2PA] 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, M2PATEST05] do not perform congestion testing that would generate these indications to the test environment. <7> MTP Level 2 Test Specifications [Q.781, M2PATEST05] do not test retrieval. Retrieval tests are performed by SS7 MTP Level 3 testing [Q.782]. <8> MTP Level 2 Test Specifications [Q.781, M2PATEST05] 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, M2PATEST05]. <9> MTP Level 2 Test Specifications [Q.781, M2PATEST05] 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, M2PATEST05]; 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, M2PATEST05] defines these signals, and these signals are required within the test environment [Q.780, M2PATEST05]; 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, M2PATEST05] 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.2 Page 16 Internet-Draft M2UA-SS7TEST October 16, 2005 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.2. Changes from Version 0.1 to Version 0.2 (1) Updated first and last page to IETF boiler plate. Updated dates, versions and references. 0.1. Changes from Version 0.0 to Version 0.1 Updated dates and references. 0.0. Version 0.0 This is the first version of this document. 0.0.0. Change Log $Log: draft-bidulock-sigtran-m2ua-ss7test-02.me,v $ Revision 0.9.2.3 2005/10/17 11:53:44 brian - updated drafts for republication Revision 0.9.2.2 2005/05/14 08:33:15 brian - copyright header correction Revision 0.9.2.1 2004/08/21 10:14:37 brian - Force checkin on branch. Revision 0.9 2004/02/17 09:44:31 brian - Baseline for documentation. 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.2 Page 17 Internet-Draft M2UA-SS7TEST October 16, 2005 R. References R.1. Normative References [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119 - BCP 14, The Internet Society (March 1997). [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") [M2PATEST05] Bidulock, B., "SS7 MTP-User Peer-to-Peer Adaptation Layer Test Specifications (M2PA-TEST)," , Internet Engineering Task Force - Signalling Transport Working Group (February 24, 2005). 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") [M2PA] George, T., Bidulock, B., Dantu, R., Schwarzbauer, H. J. and Morneault, K., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)-User Peer-to-Peer Adaptation Layer (M2PA)," RFC 4165, Internet Engineering Task Force - Signalling Transport Working Group (September 2005). 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.2 Page 18 Internet-Draft M2UA-SS7TEST October 16, 2005 Author's Addresses Brian Bidulock OpenSS7 Corporation 1469 Jeffreys Crescent Edmonton, AB T6L 6T1 Canada Phone: +1-780-490-1141 Email: bidulock@openss7.org URL: http//www.openss7.org/ This draft expires April 2006. B. Bidulock Version 0.2 Page 19 Internet-Draft M2UA-SS7TEST October 16, 2005 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.2 Changes from Version 0.1 to Version 0.2 ..................... 17 0.1 Changes from Version 0.0 to Version 0.1 ..................... 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.2 Page 20 Internet-Draft M2UA-SS7TEST October 16, 2005 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. B. Bidulock Version 0.2 Page 21