Vivek Bansal Internet Draft Document: draft-vibansal-interop-test-spec- Hughes Software sua-00.txt Systems Expires: February 2005 July 2004 Interoperability Test Spec for SUA (SIGTRAN) draft-vibansal-interop-test-spec-sua-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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. Abstract These test specification are to test the interoperability between different SUA implementations is based on SCCP User Adaptation Layer protocol (SUA), as described in IETF draft Table of Contents Status of this Memo...................................................1 Abstract..............................................................1 1.Introduction.......................................................3 HSS 1 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 2.Test Conditions....................................................3 3.Conventions used in this document..................................3 4.Test Case (Level 1)................................................3 4.1.Single ASP-SGP (No redundancy)..................................3 4.2.One ASP that is serving two AS..................................5 4.3.Single AS & Multiple ASP (AS Traffic Handling modes)............5 4.4.Two SGP's in one SG & one ASP (SGP Traffic Handling Modes)......7 4.5.Basic SSNM Message Test - DUNA, DAVA...........................10 4.6.Bulk Data to ASP...............................................11 4.7.Bulk Data to SG................................................12 5.Test Case (Level 2)...............................................12 5.1.IPSP-IPSP configuration........................................12 5.2.Connection Orinted Traffic between SG and ASP..................16 5.3.Global Title Translation Scenario..............................17 5.4.Global Title Translation Scenario (SG).........................18 5.5.Multiple SG Setup (Detailed SSNM Messages Test)................19 5.6.Segmentation and Re-assembly of CLDT messages..................21 6.Test Case (Level 3)...............................................21 6.1.Dynamic Registration...........................................21 6.2.Relay Functionality............................................23 7.INVALID TEST CASES................................................25 7.1.Invalid Traffic Handling Mode Error............................25 7.2.Invalid Network Appearance or Invalid Routing Context in message26 7.3.Error - Refused - Management Blocking..........................26 8.Test Case Summary.................................................27 9.Security Considerations...........................................27 10. IANA Considerations.............................................27 11. References......................................................27 12. Acknowledgments.................................................28 13. Author's Addresses..............................................28 Vivek 2 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 1. Introduction The scope of this Test Plan is to verify the interoperability between different implementations of SUA [1] layer. 2. Test Conditions The SCTP under the SUA layer MUST be RFC2960 and RFC3309 compliant. The computers hosting the ASP and the SGP are going to be separated, with an IPv4 network between them. There are not going to be real SUA Users, so the vendors should implement a Test Application in order to generate the primitives and to trace the performance of the SUA layer and its messages. The vendors will perform as client and server in the different test cases. These tests assume that there are neither real SCCP nor any other SS7 network emulation at the other side of the SGP node. The scope of this test is to verify the interoperability between different implementations of the SUA layer. The Test cases in this test plan are divided into three different levels based on facts like SGP/ASP only Implementation, IPSP Supported, CL/CO Services, Routing Key types Supported etc. It is expected that Every implemantation should support alteast level 1 test cases. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [8]. 4. Test Case (Level 1) 4.1. Single ASP-SGP (No redundancy) The main aim of this scenario is to verify the basic features of the Vivek 3 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 stack, and interchanging SUA connectionless data traffic between two nodes. Test Configuration: A SG +-------------+ +--------------+ | SGP | | AS DPC = X | | | | ------- | | |-------------------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Routing Key Types :- - DPC - DPC + SSN The following should be tested: - Association establishment, started by the ASP (acting as a client). - Connection establishment between an ASP and an SGP, ordered by the ASP. ¸ The ASP sends the ASPUP message to the SGP. ¸ The SGP sends to the ASP the confirmation for this message, i.e. the ASPUP Ack. ¸ The SGP sends a NTFY (AS-INACTIVE) message to the ASP. - Activation of traffic between the two nodes. ¸ The ASP sends the ASPAC(Override) message to the the SGP. ¸ The SGP responds with the ASPAC Ack (Override), as a confirmation for the ASP. ¸ The SGP sends a NTFY (AS-ACTIVE) message to the ASP. ¸ Sending the Class 0 and 1 Connectionless Messages(CLDT) from both sides (sent by the ASP and the SGP). ¸ (optional) Sending the Class 2 and 3 Connection-oriented Messages from both sides (ASP side initiates connection). - Deactivation of traffic between the two nodes. ¸ The ASP sends an ASPIA message to the SGP. ¸ The SGP responds with the ASPIA Ack, as a confirmation for the ASP. ¸ The SGP sends a NTFY (AS-Pending) to ASP. ¸ The SGP sends a NTFY (AS-INACTIVE) to ASP after timer Tr expires. - ASP disconnection ¸ The ASP sends an ASPDN message to the SGP. ¸ The SGP responds with the corresponding ASPDN-Ack message. - Close association. In this test, it must be checked that the ASP can close (gracefully shutdown) the SCTP association. Vivek 4 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 4.2. One ASP that is serving two AS Test Configuration :B +--------------+ | AS1 DPC X | | | SG | +------------| +-------------+ | | AS2 DPC Y | | | | | ------- | | |----------------------| | | ASP1 | | | SGP | | | ------- | | | +--------------+ | | | | | | +------------+ +-------------+ Routing Key Type :- - DPC - DPC + SSN The SUA in the ASP node must be able to send an ASPAC or an ASPIA messages with more than one Routing Context. - ASP Active message with more than one Routing Context. ¸ The ASP sends ASPAC(Over-ride) message(s) for RC1 & RC2. (Note: sending of RCs is optional) ¸ The SGP sends an ASPAC-Ack(Over-ride) messages. ¸ The SGP sends a NTFY (AS-ACTIVE) message to the ASP. ¸ The SGP sends a CLDT message to the AS1 (with the RC1). ¸ The SGP sends a CLDT message to the AS2 (with the RC2). . The messages should reach ASP1. - ASP Inactive message with more than one Routing Context. ¸ The ASP, sends an ASPIA message(s) (for Routing Context 1 & 2). (Note: Sending of RCs is optional) ¸ The SGP sends an ASPIA-Ack message. ¸ The SGP sends a NTFY (AS-Pending) to ASP. ¸ The SGP sends a NTFY (AS-INACTIVE) to ASP after timer Tr expires. ¸ Sending of User messages by NIF should be refused by both AS. 4.3. Single AS & Multiple ASP (AS Traffic Handling modes) Test Configuration :C Vivek 5 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 +--------------+ SG | AS DPC X | +-------------+ | ------- | | |----------------|-| ASP1 | | | SGP | | ------- | | | | ------- | | | | | ASP2 | | | |----------------|- ------- | +-------------+ +--------------+ Routing Key Type :- - DPC - DPC + SSN Two ASPs serving to the same AS This test case tests Traffic Distribution for the case when two ASPs are serving the same AS in LoadShare, OverRide and Broadcase Traffic Modes. - Connection establishment between an ASP and an SGP ¸ The ASP1 establishes SCTP association with SGP. ¸ The ASP2 establishes SCTP association with SGP. ¸ The ASP1 sends an ASPUP message to the SGP. ¸ The SGP sends an ASPUP-Ack message to the ASP1. ¸ The SGP sends a NTFY (AS-INACTIVE) message to ASP1. ¸ The ASP2 sends an ASPUP message to the SGP. ¸ The SGP sends an ASPUP-Ack message to the ASP2. - Over-Ride mode in the AS. ¸ The ASP2 sends an ASPAC(Over-ride) to the SGP. ¸ The SGP sends an ASPAC-Ack(Over-ride) message to the ASP2. ¸ The SGP sends a NTFY (AS-ACTIVE) message to the ASP. ¸ Send CLDT from SGP, it will be received at ASP2. ¸ The ASP1 sends an ASPAC (Over-ride) message to the SGP. ¸ The SGP sends an ASPAC-Ack (Over-ride) message to the ASP1. ¸ The SGP sends a NTFY (Alt ASP-Act) message to the ASP2. ¸ Send CLDT from SGP, it will be received at ASP1. ¸ The ASP1 sends an ASPIA(Over-ride) to the SGP. ¸ The SGP sends an ASPIA-Ack(Over-ride) message to the ASP1. ¸ The SGP sends a NTFY (AS-INACTIVE/Pending) to ASP1 and ASP2. ¸ In case NTFY (AS-Pending) was sent, Notify (AS-INACTIVE should be sent after timer Tr expires ¸ Send CLDT from SGP, this message should be rejected. - Load-share mode in the AS. ¸ The ASP1 sends an ASPAC (LoadShare) message to the SGP. Vivek 6 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ The SGP sends an ASPAC-Ack (LoadShare) message to the ASP1. ¸ The SGP sends a NTFY (AS-ACTIVE) message to the ASP (Note: the value of n will be set to one on the SG). ¸ Send CLDT from SGP, it will be received at ASP1. ¸ The ASP2 sends an ASPAC (LoadShare) message to the SGP. ¸ The SGP sends an ASPAC-Ack (LoadShare) message to the ASP2. ¸ Send CLDT messages from SGP, they should be distributed between ASP1 and ASP2. ¸ The ASP1 sends an ASPIA to the SGP. ¸ The SGP sends an ASPIA-Ackmessage to the ASP1. ¸ Send CLDT from SGP, it should be not be sent to ASP1 ¸ The ASP2 sends an ASPIA to the SGP. ¸ The SGP sends an ASPIA-Ackmessage to the ASP2. ¸ The SGP sends a NTFY (AS-INACTIVE/Pending) to ASP1 and ASP2. ¸ In case NTFY (AS-Pending) was sent, Notify (AS-INACTIVE should be sent after timer Tr expires ¸ Send CLDT from SGP, this message should be rejected. - Broadcast mode in the AS. ¸ The ASP1 sends an ASPAC (Broadcast) message to the SGP. ¸ The SGP sends an ASPAC-Ack (Broadcast) message to the ASP1. ¸ The SGP sends a NTFY (AS-ACTIVE) message to the ASP. ¸ Send CLDT from SGP, it will be received at ASP1. ¸ The ASP2 sends an ASPAC (Broadcast) message to the SGP. ¸ The SGP sends an ASPAC-Ack (Broadcast) message to the ASP2. ¸ Send CLDT primitive from SGP, it should be received at both ASP1 and ASP2. Note : Correlation ID parameter may be present in CLDT message ¸ The ASP1 Send ASPIA to SGP. ¸ SGP sends ASPIA-Ack message back ASP1 ¸ Send CLDT primitive from SGP, it should be received only at ASP2. - ASP disconnection. ¸ The ASP1 and ASP2 are at Inactive State. ¸ The ASP1 sends an ASPDN message to the SGP. ¸ The SGP sends an ASPDN-Ack message to the ASP1. ¸ The ASP2 sends an ASPDN message to the SGP. ¸ The SGP sends an ASPDN-Ack message to the ASP2. - Close associations. ¸ The ASP1 gracefully shuts down the Association. ¸ The ASP2 gracefully shuts down the Association. 4.4. Two SGP's in one SG & one ASP (SGP Traffic Handling Modes) Test Configuration :D Vivek 7 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 +--------------+ | | +-------------+ | | | |-------------| SGP1(SG) | | ASP1 | | | | | +--------------+ | DPC X | +--------------+ | |-------------| | +-------------+ | | | SGP2(SG) | | | +--------------+ Routing Key Type :- - DPC - DPC + SSN Two SGP serving to the same SG This test case tests Traffic Distribution for the case when two SGPs are serving the same SG in LoadShare, OverRide and Broadcase Traffic Modes. - Activating traffic between the nodes. ¸ The ASP1 establishes SCTP association with SGP1. ¸ The ASP1 establishes SCTP association with SGP2. ¸ The ASP1 sends an ASPUP message to the SGP1. ¸ The SGP1 sends an ASPUP-Ack message to the ASP1. ¸ The SGP1 sends a NTFY (AS-INACTIVE) message to the ASP1. ¸ The ASP1 sends an ASPUP message to the SGP2. ¸ The SGP2 sends an ASPUP-Ack message to the ASP1. ¸ The SGP2 sends a NTFY (AS-INACTIVE) message to the ASP1. - Over-Ride mode of SGPs in SG ¸ The ASP1 sends an ASPAC to the SGP1. ¸ The SGP1 sends an ASPAC-Ack message to the ASP1. ¸ The SGP1 sends a NTFY (AS-ACTIVE) message to the ASP1. ¸ Send CLDT from ASP1, it will be received at SGP1. ¸ The ASP1 sends an ASPAC to the SGP2. ¸ The SGP2 sends an ASPAC-Ack message to the ASP1. ¸ The SGP2 sends a NTFY (AS-ACTIVE) message to the ASP1. ¸ Send CLDT messages from ASP1. The CLDT messages should be sent to a primary SGP (i.e. SGP1). Note : How ASP detects SG traffic mode is implementation dependent. Note : How ASP determines primary SGP is implementation dependent. Vivek 8 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ The ASP1 sends an ASPIA to the primary SGP (SGP1) ¸ The SGP1 sends an ASPIA-Ack message to the ASP1. ¸ The SGP1 sends a NTFY (AS-INACTIVE/Pending) message to the ASP1. ¸ Send CLDT messages from ASP1, it should all go to SGP2. ¸ The ASP1 sends an ASPIA to the SGP2 ¸ The SGP2 sends an ASPIA-Ack message to the ASP1. ¸ The SGP2 sends a NTFY (AS-INACTIVE/Pending) message to the ASP1. ¸ Send CLDT messages from ASP1, it may either be rejected or sent to either SGP - LoadShare mode of SGPs in SG ¸ The ASP1 sends an ASPAC to the SGP1. ¸ The SGP1 sends an ASPAC-Ack message to the ASP1. ¸ The SGP1 sends a NTFY (AS-ACTIVE) message to the ASP1. ¸ Send CLDT from ASP1, it will be received at SGP1. ¸ The ASP1 sends an ASPAC to the SGP2. ¸ The SGP2 sends an ASPAC-Ack message to the ASP1. ¸ The SGP2 sends a NTFY (AS-ACTIVE) message to the ASP1. ¸ Send class 0 CLDT messages from ASP1. The messages should be loadshared across SGP1 and SGP2 ¸ Send class 1 CLDT messages from ASP1. The messages should be loadshared across SGP1 and SGP2 based on sequence number. Messages with the same sequence number should be sent to the same SGP. Note : How ASP detects SG traffic mode is implementation dependent. ¸ The ASP1 sends an ASPIA to the primary SGP (SGP1) ¸ The SGP1 sends an ASPIA-Ackmessage to the ASP1. ¸ The SGP1 sends a NTFY (AS-INACTIVE/Pending) message to the ASP1. ¸ Send CLDT messages from ASP1, it should all go to SGP2. ¸ The ASP1 sends an ASPIA to the SGP2 ¸ The SGP2 sends an ASPIA-Ackmessage to the ASP1. ¸ The SGP2 sends a NTFY (AS-INACTIVE/Pending) message to the ASP1. ¸ Send CLDT messages from ASP1, it may either be rejected or sent to either SGP - Broadcast mode of SGPs in SG ¸ The ASP1 sends an ASPAC to the SGP1. ¸ The SGP1 sends an ASPAC-Ack message to the ASP1. ¸ The SGP1 sends a NTFY (AS-ACTIVE) message to the ASP1. ¸ Send CLDT from ASP1, it will be received at SGP1. ¸ The ASP1 sends an ASPAC to the SGP2. ¸ The SGP2 sends an ASPAC-Ack message to the ASP1. ¸ The SGP2 sends a NTFY (AS-ACTIVE) message to the ASP1. ¸ Send class 0 CLDT messages from ASP1. The messages should be sent to both SGP1 and SGP2 ¸ Send class 1 CLDT messages from ASP1. The messages should be Vivek 9 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 sent to both SGP1 and SGP2 Note : How ASP detects SG traffic mode is implementation dependent. Note : A Corelation ID parameter may be present in CLDT message. ¸ The ASP1 sends an ASPIA to the primary SGP (SGP1) ¸ The SGP1 sends an ASPIA-Ackmessage to the ASP1. ¸ The SGP1 sends a NTFY (AS-INACTIVE/Pending) message to the ASP1. ¸ Send CLDT messages from ASP1, it should all go to SGP2. ¸ The ASP1 sends an ASPIA to the SGP2 ¸ The SGP2 sends an ASPIA-Ackmessage to the ASP1. ¸ The SGP2 sends a NTFY (AS-INACTIVE/Pending) message to the ASP1. ¸ Send CLDT messages from ASP1, it may either be rejected or sent to both SGPs. - Close associations. ¸ The ASP1 gracefully shuts down the Association with SGP1. ¸ The ASP1 gracefully shuts down the Association with SGP2. 4.5. Basic SSNM Message Test - DUNA, DAVA Test Configuration :A SG +-------------+ +--------------+ | SGP | | AS DPC = X, | | | | SSN = Y | | | | ------- | | |-----------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Routing Key Type :- - DPC - DPC + SSN This test case tests Audit Procedure and usage of N-State and N- Pcstate primitives Audit Procedure without SSN in SSNM ¸ Activate the traffic between SGP and ASP as per test case 4.1 ¸ SS7 point code X is configured at ASP to be reachable via SG ¸ The SGP sends a DUNA message (without SSN) to the ASP1 for point code X Vivek 10 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ The SUA at the ASP1 sends N-Pcstate (DOWN)indication to the SCCP User ¸ The SUA at the ASP1 MAY start sending DAUD message to SGP. ¸ The SGP1 (SUA/NIF/SCCP) should respond to DAUD message with DUNA ¸ Send CLDT messages from ASP1, it should be rejected ¸ After some tries send DAVA from SGP1 in response of DAUD message. ¸ The SUA at the ASP1 N-Pcstate (UP) indication to the SCCP User ¸ The SUA at the ASP1 stop sending DAUD message ¸ Send CLDT messages from ASP1, it should be sent to SGP1 Audit Procedure with SSN in SSNM ¸ Activate the traffic between SGP and ASP as per test case 4.1 ¸ SS7 point code X and SSN Y is configured at ASP to be reachable via SG ¸ The SGP sends a DUNA message (with SSN Y) to the ASP1 for point code X ¸ The SUA at the ASP1 sends N-State indication to the SCCP User ¸ The SUA at the ASP1 MAY start sending DAUD message to SGP. ¸ The SGP1 (SUA/NIF/SCCP) should respond to DAUD message with DUNA ¸ Send CLDT messages from ASP1, it MAY be rejected ¸ After some tries send DAVA from SGP1 in response of DAUD message. ¸ The SUA at the ASP1 N-state(UP) indication to the SCCP User ¸ The SUA at the ASP1 stop sending DAUD message ¸ Send CLDT messages from ASP1, it should be sent to SGP1 - Close associations. ¸ The ASP1 gracefully shuts down the Association. 4.6. Bulk Data to ASP Test Configuration: A SG +-------------+ +--------------+ | SGP | | AS DPC = X | | | | | | | | ------- | | |-----------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Routing Key Type :- - DPC Vivek 11 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 - DPC + SSN This test case verifies ASP can handle heavy message traffic. Bulk Data Traffic Procedure ¸ Activate the traffic between SGP and ASP as per test case 4.1 ¸ Generate class 0 CLDT traffic from SGP. Data should have counter in case ASP is able to echo back data . If possible on ASP side, echo back received traffic so that SGP can confirm receipt (by looking at counter in data). 4.7. Bulk Data to SG Test Configuration: C (with single SGP) SG +-------------+ +--------------+ | AS DPC = X | | SGP | | | | | | --------- | | | | | ASP1 |--|-----------------| | | --------- | | | +-------------+ +--------------+ Routing Key Type :- - DPC - DPC + SSN This test case verifies SGP/SG can handle heavy message traffic. Bulk Data Traffic Procedure ¸ Activate the traffic between SGP and ASP as per test case 4.1 ¸ Generate class 0 CLDT traffic from ASP. Data should have counter in case SG/SGP is able to echo back data . If possible on SG/SGP side, echo back received traffic so that ASP can confirm receipt (by looking at counter in data). 5. Test Case (Level 2) 5.1. IPSP-IPSP configuration The main aim of this scenario is to verify the IPSP support feature of the stack, interchanging a little bit of SUA traffic between two IPSP nodes. Test Configuration :E Vivek 12 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 +-------------+ +--------------+ | | | | | IPSP A | | IPSP B | | |---------------------| | | | | | +-------------+ +--------------+ Routing Key Type :- - IP (V4/V6) - IP (V4/V6) + SSN These scenarios show a basic example for IPSP communication for the three phases of the connection (establishment, data exchange, disconnection). Both single exchange and double exchange behavior are included for illustrative purposes. Single exchange: =================== IPSP-A IPSP-B | | |-------------ASP Up------------>| |<----------ASP Up Ack-----------| | | |<------- ASP Active(RCb)--------| RC: Routing Context |-----ASP Active Ack (RCb)------>| (optional) | | | | |<========= DATA (RCb) ========>| | | |<-----ASP Inactive (RCb)--------| RC: Routing Context |----ASP Inactive Ack (RCb)----->| (optional) | | |<-----------ASP Down------------| |---------ASP Down Ack---------->| | | - Activation of Traffic between the nodes. ¸ The IPSP-A makes SCTP association with IPSP-B ¸ The IPSP-A sends an ASPUP message to the IPSP-B ¸ The IPSPB sends an ASPUP-Ack message to the IPSP-A ¸ The IPSP-B sends an ASPAC to the IPSP-A. ¸ The IPSP-A sends an ASPAC-Ack message to the IPSP-B. ¸ The IPSP-A sends a NTFY (AS-ACTIVE) message to the IPSP-B. Vivek 13 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 - Connection Less Data Transfer between the nodes. ¸ Send CLDT from IPSP-A, it will be received at IPSP-B. ¸ Send CLDT from IPSP-B, it will be received at IPSP-A. - Optional : Some large size data can be sent and received using the segmentation parameter in the CLDT messages. Observations in this case can be the value of the segmentation field and the final message at the receiving end. The final message should have the segments arranged in correct order to form a meaningful message. - Connection Oriented Data Transfer between the nodes. ¸ IPSP-A sends CORE message to the IPSP-B. ¸ IPSP-B sends COAK message to the IPSP-A. ¸ IPSP-A sends CODT message to the IPSP-B. ¸ IPSP-B sends CODT message to the IPSP-A. ¸ IPSP-B sends RELRE message to the IPSP-A. ¸ IPSP-A sends RELCO message to the IPSP-B. - Optional : Do not send any data from any side for time T(ias) and then observe that COIT message are being transferred from both sides. - Deactivation of traffic between the two nodes. ¸ The IPSP-B sends an ASPIA to the IPSP-A. ¸ The IPSP-A sends an ASPIA-Ack message to the IPSP-B. ¸ The IPSP-A sends a NTFY (AS-INACTIVE/Pending) message to the IPSP-B. ¸ The IPSP-B sends an ASPDOWN to the IPSP-A. ¸ The IPSP-A sends an ASPDOWN-Ack message to the IPSP-B. ¸ Send CLDT messages from IPSP-A/B, it should be rejected ¸ Send CORE messages from IPSP-A/B, it should be rejected - Close associations. ¸ The IPSP-A gracefully shuts down the Association. Double exchange: =================== IPSP-A IPSP-B | | |<-------------ASP Up------------| |-----------ASP Up Ack---------->| | | |-------------ASP Up------------>| (optional) |<----------ASP Up Ack-----------| (optional) | | |<------- ASP Active(RCb)--------| RC: Routing Context |-----ASP Active Ack (RCb)------>| (optional) | | |------- ASP Active(RCa)-------->| RC: Routing Context |<-----ASP Active Ack (RCa)------| (optional) | | Vivek 14 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 |<========= DATA (RCa) =========| |========== DATA (RCb) ========>| | | |<-----ASP Inactive (RCb)--------| RC: Routing Context |----ASP Inactive Ack (RCb)----->| (optional) | | |------ASP Inactive (RCa)------->| RC: Routing Context |<----ASP Inactive Ack (RCa)-----| (optional) | | |<-----------ASP Down------------| |---------ASP Down Ack---------->| | | |------------ASP Down----------->| |<--------ASP Down Ack-----------| | | - Activation of Traffic between the nodes. ¸ The IPSP-A makes SCTP association with IPSP-B ¸ The IPSP-A sends an ASPUP message to the IPSP-B ¸ The IPSPB sends an ASPUP-Ack message to the IPSP-A ¸ The IPSP-B MAY optionaly send an ASPUP message to the IPSP-A ¸ The IPSP-A sends an ASPUP-ACK message to the IPSP-B ¸ The IPSP-B sends an ASPAC (RCb)to the IPSP-A. ¸ The IPSP-A sends an ASPAC-Ack message to the IPSP-B. ¸ The IPSP-A sends a NTFY (AS-ACTIVE) message to the IPSP-B. ¸ The IPSP-A sends an ASPAC (RCa)to the IPSP-B. ¸ The IPSP-B sends an ASPAC-Ack message to the IPSP-A. ¸ The IPSP-B sends a NTFY (AS-ACTIVE) message to the IPSP-A. - Connection Less Data Transfer between the nodes. ¸ Send CLDT from IPSP-A, it will be received at IPSP-B(RCb). ¸ Send CLDT from IPSP-B, it will be received at IPSP-A(RCa). - Deactivation of traffic between the two nodes. ¸ The IPSP-B sends an ASPIA (RCb)to the IPSP-A. ¸ The IPSP-A sends an ASPIA-Ack message to the IPSP-B. ¸ The IPSP-A sends a NTFY (AS-INACTIVE/Pending) message to the IPSP-B. ¸ The IPSP-A sends an ASPIA (RCa) to the IPSP-B. ¸ The IPSP-B sends an ASPIA-Ack message to the IPSP-A. ¸ The IPSP-B sends a NTFY (AS-INACTIVE/Pending) message to the IPSP-A. ¸ The IPSP-A sends an ASPDOWN to the IPSP-B. ¸ The IPSP-B sends an ASPDOWN-Ack message to the IPSP-A. ¸ The IPSP-B MAY optionaly send an ASPDOWN message to the IPSP- A ¸ The IPSP-A sends an ASPDOWN-ACK message to the IPSP-B ¸ Send CLDT messages from IPSP-A/B, it should be rejected ¸ Send CORE messages from IPSP-A/B, it should be rejected - Close associations. ¸ The IPSP-A gracefully shuts down the Association. Vivek 15 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 In this approach, only one single exchange of ASP Up message can be considered as enough since the response by the other peer can be considered as a notice that it is in ASP-UP state. For the same reason, only one ASP Down message is needed since once that an IPSP receives ASP_Down ack message it is itself considered as being in the ASP-DOWN state and not allowed to receive ASPSM messages. 5.2. Connection Orinted Traffic between SG and ASP Test Configuration: A SG +-------------+ +--------------+ | SGP | | AS DPC = X | | | | | | | | ------- | | |-----------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Routing Key Type :- - DPC - DPC + SSN This test case verifies the exchange of Connection Oriented Traffic between SG and ASP with connection initiated from the ASP side. - Actiation of traffic between nodes ¸ Activate the traffic between SGP and ASP as per test case 4.1 - Connection Oriented Data Transfer between the nodes. ¸ ASP1 sends CORE message to the SGP. ¸ SGP sends COAK message to the ASP1. ¸ ASP1 sends CODT message to the SGP. ¸ SGP sends CODT message to the ASP1. ¸ SGP sends RELRE message to the ASP1. ¸ ASP1 sends RELCO message to the SGP. - Optional : Do not send any data from any side for time T(ias) and then observe that COIT message are being transferred from both sides. Vivek 16 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 - Deactivation of traffic between the two nodes. ¸ De-Activate the traffic between SGP and ASP as per test case 4.1 - Close associations. ¸ The ASP1 gracefully shuts down the Association. 5.3. Global Title Translation Scenario Test Configuration :A SG +-------------+ +--------------+ | SGP | | AS DPC = X | | | | ------- | | |-----------------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Routing Key Type :- - GT - GT + SSN - GT + PC This test case tests the case when Global Title parameter is sent in a CLDT called address parameter between ASP and SGP. - Activation of Traffic between the nodes. ¸ Activate the traffic between SGP and ASP as per test case 4.1 - Global Title without Point Code and SSN ¸ Configure ASP node to accept CLDT with called address having only GT parameter (no PC or SSN) ¸ Send CLDT from SGP with RI= Route on Global Title and GT parameters GTI = 4, No-Digits = 5, Translation Type =1, NP =1, NA =3,Digits=12345 ¸ ASP after receiving CLDT should resolve GT and pass data to SCCP User - Global Title with Point Code ¸ Repeat the above test case with Called Address having PC also ¸ ASP after receiving CLDT should resolve GT and pass data to SCCP User Note: Point Code should be ASP local Point code - Global Title with PC and SSN ¸ Repeat the above test case with Called Address having PC and SSN Vivek 17 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ ASP after receiving CLDT should resolve GT and pass data to SCCP User Note: Point Code should be ASP local Point code and in case GT library does not return any SSN, SSN received in CLDT should be received 5.4. Global Title Translation Scenario (SG) Test Configuration: C (with single SGP) SG +-------------+ +--------------+ | AS DPC = X | | SGP | | | | | | --------- | | | | | ASP1 |--|-----------------| | | --------- | | | +-------------+ +--------------+ Routing Key Type :- - GT - GT + SSN - GT + PC This test case tests the case when Global Title parameter is sent in a CLDT called address parameter between ASP and SGP. - Activation of Traffic between the nodes. ¸ Activate the traffic between SGP and ASP as per test case 4.1 - Global Title without Point Code and SSN ¸ Configure GT information on SGP ¸ Send CLDT from ASP with RI=Route on Global Title and GT parameters GTI = 4, No-Digits = 5, Translation Type =1, NP =1, NA =3, Digits=12345 ¸ SGP should receive the CLDT with GT - Global Title with Point Code ¸ Repeat the above test case with Called Address having PC also ¸ SGP should receive the CLDT with GT Note: SGP would pass point code information to resolved SS7 destination - Global Title with PC and SSN ¸ Repeat the above test case with Called Address having PC and SSN ¸ SGP should receive the CLDT with GT Vivek 18 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 Note: SGP would pass point code and SSN information to resolved SS7 destination 5.5. Multiple SG Setup (Detailed SSNM Messages Test) Test Configuration :F +--------------+ | | +-------------+ | | | |----------| SGP1(SG1) | +--------+ | ASP1 | | |----| | | | +--------------+ | SS7 EP | | DPC Y | +--------------+ | PC X | | |----------| |----| | +-------------+ | | + -------+ | SGP2(SG2) | | | +--------------+ Routing Key Type :- - DPC - DPC + SSN This test case tests the behaviour of DRST, SCON, DUPU messages. In this configuration SS7 point code X is configured at ASP to be reachable via SG1 and SG2. For the purpose of selecting SG, ASP chooses SG based on load sharing between them. - Restricted with equal priority of SGs ¸ SG1 and SG2 have equal priority. ¸ Activate the traffic between ASP and SGP1 as per test case 4.1 ¸ Activate the traffic between ASP and SGP2 as per test case 4.1 ¸ Send CLDT messages from ASP1, it should be distributed between SGP1 and SGP2. ¸ Send DRST message from SGP1 to ASP. ¸ The SUA at the ASP1 MAY start sending DAUD message to SGP1. ¸ Send CLDT messages from ASP1. They should be sent only to SGP2. ¸ Send DUNA message (without SSN) from SGP2 to ASP1 for PC X. ¸ The SUA at the ASP1 MAY start sending DAUD message to SGP2. Note : N-PCSTATE (DOWN) is not sent as PC is reachable via other SG. ¸ Send CLDT messages from ASP1. They should be sent to SGP1. Vivek 19 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ After some tries of DAUD send DAVA from SGP2 in response of DAUD. ¸ Send CLDT messages from ASP1. They should be sent only to SGP2. - Restricted with unequal priorities of the SGs ¸ SG1 has higher priority than SG2. ¸ Activate the traffic between ASP and SGP1 as per test case 4.1 ¸ Activate the traffic between ASP and SGP2 as per test case 4.1 ¸ Send CLDT messages from ASP1. They should be received only SGP1. ¸ Send DRST message from SGP1 to ASP. ¸ The SUA at the ASP1 MAY start sending DAUD message to SGP1. ¸ Send many CLDT messages from ASP1, it should be sent only to SGP1. ¸ Send DUNA message (without SSN) from SGP1 to ASP1 for PC X ¸ The SUA at the ASP1 MAY start sending DAUD message to SGP1. Note : N-PCSTATE (DOWN) is not sent as PC is reachable via other SG ¸ Send CLDT messages from ASP1. They should be sent only to SGP2. - User Part Unavailable ¸ Activate the traffic between ASP and SGP1 as per test case 4.1 ¸ Activate the traffic between ASP and SGP2 as per test case 4.1 ¸ Send CLDT messages from ASP1, it should be distributed between SGP1 and SGP2. ¸ Send DUPU message from SGP1 to ASP. ¸ The SUA at the ASP1 sends N-State (DOWN)indication to the SCCP User Note : Its not clear if SUA should start Audit as SCCP User would not. ¸ Send many CLDT messages from ASP1, it should be sent to SGP1 or SGP2 - Congestion ¸ Activate the traffic between ASP and SGP1 as per test case 4.1 ¸ Activate the traffic between ASP and SGP2 as per test case 4.1 ¸ Send CLDT messages from ASP1. They should be distributed between SGP1 and SGP2. ¸ Send SCON message (without SSN) from SGP1 to ASP. ¸ The SUA at the ASP1 sends N-Pcstate (Congestion)to the SCCP User Vivek 20 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ Send CLDT messages from ASP1. They should be distributed between SGP1 and SGP2. ¸ This messsge may be discarded based on priority of the message. 5.6. Segmentation and Re-assembly of CLDT messages Test Configuration: A SG +-------------+ +--------------+ | SGP | | AS DPC = X | | | | ------- | | |----------------|--| ASP1 | | | | | ------- | +-------------+ +--------------+ Routing Key Types :- - DPC - DPC + SSN This test case tests the behaviour of ASP side on receipt of segmented messages from SGP. In this configuration SS7 point code X is configured at ASP to be reachable via SG. ¸ Activate the traffic between ASP and SGP as per test case 4.1 ¸ Send CLDT messages from SGP, with the segmentation parameter set indicating 1 as remaining parameter. First bit in the segmentation parameter should be set to 1. ¸ Send CLDT messages from SGP, with the segmentation parameter set indicating 0 as remaining parameter. First bit in the segmentation parameter should be set to 0. - ASP gives CLDT indication to the user with the combined data of both the messages. 6. Test Case (Level 3) 6.1. Dynamic Registration Vivek 21 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 The main aim of this scenario is to test Registration/Deregistration of ASP. Test Configuration :A SG +-------------+ +--------------+ | SGP | | AS DPC = X | | | | ------- | | |-----------------|--| ASP | | | | | ------- | +-------------+ +--------------+ Routing Key Types :- - DPC - DPC + SSN - Association establishment, started by the ASP (acting as a client). ¸ The ASP sends the ASPUP message to the SGP. ¸ The SGP sends the ASPUP-Ack message to the ASP - Dynamic Registration of Routing Keys ¸ Send a valid REG-REQ message from ASP to SGP Stack. Note : This RK May/May not be already configured at the SGP. ¸ SUA at SGP send a Indication "REG_IND" to Layer/System Manager ¸ SGP sends a REG_RSP message to ASP side with RC1 and a Registration status as SUCCESS. - Activation of traffic between the two nodes ¸ Send a ASPAC from ASP to SGP for RC1. ¸ SGP sends back ASPAC-ACK to ASP ¸ Send CLDT message from SGP side. The message should be received at the ASP - Deactivation of traffic between the two nodes. ¸ The ASP sends an ASPIA message to the SGP with RC1 (RK1). ¸ The SGP responds with the ASPIA Ack, as a confirmation for the ASP. - Dynamic DeRegistration of Routing Keys ¸ Send a valid DEREG-REQ message from ASP to SGP Stack. ¸ SUA at SGP send a Indication "DEREG_IND" to Layer/System Manager ¸ SGP sends a DEREG_RSP message to ASP side with RC1 and a DeRegistration status as SUCCESS. - ASP disconnection Vivek 22 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ The ASP sends an ASPDN message to the SGP. ¸ The SGP responds with the corresponding ASPDN-Ack message. - Close association ¸ The ASP gracefully shuts down the Association. - Check whether the AS1 gets deleted if it had only one ASP which deregistered (Implementation dependent). The Above test can be done in IPSP Scenario with Routing Key Type :- - IP - IP + SSN 6.2. Relay Functionality The main aim of this scenario is to test Relay Capability of a Node. Test Configuration : G +-------------+ +----------+ +-----------+ | | | | | | | IPSP A | | IPSP B | | IPSP C | | DPC = X |--------| |--------| DPC = Y | | | | | | | +-------------+ +----------+ +-----------+ Routing Key Type :- - PC - PC + SSN - GT - IP (V4/V6) - IP (V4/V6) + SSN - HOSTNAME + SSN - Association establishment, started by the IPSP-A to IPSP-B. - Association establishment, started by the IPSP-B to IPSP-C. - Connection establishment between an IPSP-A and IPSP-B, ¸ The IPSP-A sends the ASPUP message to the IPSP-B. ¸ The IPSP-B sends ASPUP Ack to IPSP-A. - Connection establishment between an IPSP-C and IPSP-B, ¸ The IPSP-C sends the ASPUP message to the IPSP-B. ¸ The IPSP-B sends ASPUP Ack to IPSP-C. - Activation of traffic between the two nodes. ¸ The IPSP-B sends the ASPAC message to the the IPSP-A. Vivek 23 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 ¸ The IPSP-A responds with the ASPAC Ack as a confirmation for the IPSP-B. - Activation of traffic between the two nodes. ¸ The IPSP-B sends the ASPAC message to the the IPSP-C. ¸ The IPSP-C responds with the ASPAC Ack as a confirmation for the IPSP-B. Steps for Connection Less Data transfer :- ------------------------------------------ - Sending the CLDT primitives from IPSP-A with Called Addr contains DPC-Y. ¸ Data is sent from IPSP-A to IPSP-B. ¸ Data is send from IPSP-B to IPSP-C. - Sending the CLDT primitives from IPSP-C with Called Addr contains DPC-X. ¸ Data is sent from IPSP-C to IPSP-B. ¸ Data is send from IPSP-B to IPSP-A. - Observe the value of hop counter parameterat every node. The value of hop counter parameter should decrement by one at each intermediate node. Steps for Connection Oriented Data Transfer :- ---------------------------------------------- - Sending the CORE primitive from IPSP A with called Addr contains DPC-Y. ¸ CORE is sent from IPSP-A to IPSP-B. ¸ CORE is send from IPSP-B to IPSP-C. - Sending the COAK primitive from IPSP C. ¸ COAK is sent from IPSP-C to IPSP-B. ¸ COAK is send from IPSP-B to IPSP-A. - Sending of the CODT primitive from IPSP-A to IPSP-C. ¸ CODT is sent from IPSP-A to IPSP-B. ¸ CODT is send from IPSP-B to IPSP-C. ¸ CODA is sent from IPSP-C to IPSP-B. ¸ CODA is send from IPSP-B to IPSP-A. - Sending of the CODT primitive from IPSP-C to IPSP-A. ¸ CODT is sent from IPSP-C to IPSP-B. ¸ CODT is send from IPSP-B to IPSP-A. ¸ CODA is sent from IPSP-A to IPSP-B. ¸ CODA is send from IPSP-B to IPSP-C. - Sending the RELRE primitive from IPSP C to IPSP-A. ¸ RELRE is sent from IPSP-C to IPSP-B. ¸ RELRE is send from IPSP-B to IPSP-A. Vivek 24 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 - Sending the RELCO primitive from IPSP A to IPSP-C. ¸ RELCO is sent from IPSP-A to IPSP-B. ¸ RELCO is send from IPSP-B to IPSP-C. - Deactivation of traffic between the two nodes. ¸ The IPSP-B sends an ASPIA message to the IPSP-A. ¸ The IPSP-A responds with the ASPIA Ack, as a confirmation to IPSP-B. - Deactivation of traffic between the two nodes. ¸ The IPSP-B sends an ASPIA message to the IPSP-C. ¸ The IPSP-C responds with the ASPIA Ack, as a confirmation to IPSP-B. - ASP disconnection ¸ The IPSP-B sends an ASPDN message to the IPSP-A. ¸ The IPSP-A responds with the corresponding ASPDN-Ack message. - ASP disconnection ¸ The IPSP-B sends an ASPDN message to the IPSP-A. ¸ The IPSP-A responds with the corresponding ASPDN-Ack message. - Association Shutdown, started by the IPSP-A to IPSP-B. - Association Shutdown, started by the IPSP-B to IPSP-C. This test case can be performed with the other configurations also. Configuration :- +-----------+ +----------+ +----------+ | | | | | | | SGP | | ASP | | IPSP | | DPC = X |----------| |------------| DPC = Y| | | | | | | +-----------+ +----------+ +----------+ 7. INVALID TEST CASES 7.1. Invalid Traffic Handling Mode Error Test Configuration: A The aim of the test case is to check that if ASPAC message is received with Type parameter incompatible with the traffic handling mode currently used in AS at SGP, SGP responds with ERROR message containing cause "Invalid Traffic Handling Mode". - Configure Traffic Handling Mode at SGP for AS as Override Mode. - Configure Traffic Handling Mode at ASP for AS as Load Share Mode. Vivek 25 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 - Connection establishment between an ASP and an SGP, ordered by the ASP. . Establish SCTP association between ASP1 and SGP. ¸ The ASP1 sends the ASPUP message to the SGP. ¸ The SGP sends to the ASP1 the confirmation for this message, i.e. the ASPUP Ack. ¸ The ASP2 sends the ASPUP message to the SGP. ¸ The SGP sends to the ASP2 the confirmation for this message, i.e. the ASPUP Ack. - The ASP1 send ASPAC message with Type field filled with Loadshare mode of Traffic handling. - SGP should send ERROR message to ASP containing cause ôInvalid Traffic Handling Modeö. 7.2. Invalid Network Appearance or Invalid Routing Context in message Test Configuration: A To check that if a message with invalid network appearance/ Routing Context i.e. NW APPR/RC not defined at SGP is received, then SGP responds with ERROR message containing cause "Invalid Network Appearance"/ö Invalid Routing Contextö. - Connection establishment between an ASP and an SGP, ordered by the ASP. . Activate the traffic between ASP and SGP as per test case 4.1 . Send DATA message with network appearance B which is not defined at SGP. . SGP should send ERROR message to ASP containing cause ôInvalid Network Appearanceö. . Send the DATA message with non configured Routing Context value. . SGP should send ERROR message to ASP containing cause ôInvalid Routing Contextö. 7.3. Error - Refused - Management Blocking Test Configuration: A To verify ASPUP message when received from blocked ASP, SGP sends error message cause " Refused û Management Blocking" Vivek 26 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 - Connection establishment between an ASP and an SGP, ordered by the ASP. . Establish SCTP association between ASP1 and SGP. ¸ The ASP1 sends the ASPUP message to the SGP. . SGP should send ERROR message to ASP containing cause ôRefused û Management Blockingö. 8. Test Case Summary The following list provides a break down of test cases per configuration. Configuration A: 4.1 4.5 4.6 5.2 5.5 6.1 Configuration B: 4.2 Configuration C: 4.3 4.7 5.3 Configuration D: 4.4 Configuration E: 5.1 Configuration G: 6.2 Configuration F: 5.4 9. Security Considerations Not applicable. 10. IANA Considerations Not applicable. 11. References Normative 1 Signalling Connection Control Part User Adaptation Layer (SUA), draft-ietf-sigtran-sua-16.txt Vivek 27 INTERNET-DRAFT Interoperability Test Spec for SUA August 2004 12. Acknowledgments The author would like to thank Pavan Puri R. Ezhirpavai Ken Morneault for their insightful comments and suggestions. 13. Author's Addresses Vivek Bansal Hughes Software Systems, Ltd. Gurgaon, Haryana, India. 122015. Phone: (91)- 124-6346666.Ex-3080 Email: vibansal@hss.hns.com Vivek 28