| draft-ietf-sigtran-iua-test-specDescription: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-iua-test-spec.txt. Network Working Group Jose Luis Jimenez Ramirez INTERNET-DRAFT Siemens Ken Morneault Cisco Systems Expires in six months Jan 2001 ISDN Q.921-User Adaptation Layer Test Specification <draft-ietf-sigtran-iua-test-spec-00.txt> Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 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). Abstract This document presents a test specification for RFCXXXX which defines the ISDN Q.921-User Adaptation prototocol. This test specifcation can be used to test IUA implementations for conformance to the IUA protocol definition. Table of Contents 1 Introduction-------------------------------------------------------- 2 General Principles of IUA Tests------------------------------------- 2.1 Terminology--------------------------------------------------------- 2.2 Presentation of test descriptions----------------------------------- 3. Test Environment for IUA on MGC Side-------------------------------- 3.1 IUA validation testing---------------------------------------------- 3.2 IUA Test Tool ------------------------------------------------------ 3.3 Link Monitor-------------------------------------------------------- 4. Test Configurations------------------------------------------------- 4.1 Presentation of test configurations--------------------------------- 4.2 Configuration for testing the IUA at AS----------------------------- 5. Test Cases for Testing IUA at MGC----------------------------------- 5.1 AS management------------------------------------------------------- 5.2 ERROR management---------------------------------------------------- 5.3 ASP configuration--------------------------------------------------- 5.4 Q.921/Q.931 primitives backhaul------------------------------------- 6. Test Cases for Testing IUA at SG------------------------------------ 6.1 AS management------------------------------------------------------- 6.2 ERROR management---------------------------------------------------- 6.3 ASP configuration--------------------------------------------------- 6.4 Q.921/Q.931 primitives backhaul------------------------------------- 7. Acknowledgement----------------------------------------------------- 8. Authors Address----------------------------------------------------- 9. References---------------------------------------------------------- 1. Introduction This document provides a test specification for the IUA protocol. The document provides test scenarios for the IUA implementation for Media Gateway Controller (MGC) and the Signaling Gateway (SG). It should be pointed out that IUA Protocol is an asymmetric protocol. The requirements of the IUA on the MGC differ from those on the SG. Thus, the MGC and SG will have different implementations of IUA. The list of test is an initial proposal and covers almost all the categories of test, and graphical representation of various scenarios help easy understanding of the protocol testing . 2. General Principles of IUA Tests These tests aim to verify a given implementation of an IUA protocol implementation in accordance with RFCXXXX. This specification is independent of a given implementation and does not generally imply any modification of the endpoint under test. However, it is recognized that certain tests require capabilities of the system that are not explicitly defined in RFCXXXX, and these capabilities may not be present in all implementations. As a consequence, some tests may not apply to all implementations. 2.1 Terminology The terminology from Section 1.2 of RFCXXXX applies to this document. 2.2 Presentation of test descriptions 2.2.1 Pre Test Condition Before starting the test we need to get the setup into a condition from where test can be started. These conditions are specified in Pre-Test condition in each test. 3. Test Environment for IUA on MGC Side. ------------------- | | | Test Interface | | | | | -------------------- | | | | | | ------------ -----|-----|---|------ | | | V V | | | Simulated | | ------------- | | | | | | IUA |LMG| | | | SG | | ------------- | | | | | | | V | | | | ----------------- | | | | | SCTP |LMG| | | | | ----------------- | | | | | | | | | | |<------------------>| MGC | | | | | | ------------ | ---------------------- | | An ASP process under Test is | running on Host (e.g. MGC) | | ------------- | | |Link Monitor | | | ------------- 3.1 IUA validation testing The IUA test environment consists of the following items (see Figure 2) * a MGC with an IUA Test Interface * a simulated Signaling Gateway * the link monitor * the IP link 3.2 IUA Test Interface In order to perform an optimum test of the IUA Layer, a Test Interface MAY be used. This Test Interface should covers the simulation of IUA Traffic User, IUA layer Manager (LMG) and SCTP Layer manager (optional). During the IUA tests, it is necessary to inject messages and indications to and from the IUA endpoint under test. It is desirable that the IUA user function used is the actual IUA user of the IUA with some additional functions for test purposes or a more controlled user function. The application should also provide means to check the interface interaction with the IUA implementation under test. 3.3 Simulated SG Test Tool During IUA testing, it will be necessary to inject some abnormal messages (as well as normal messages) to fully test the IUA under test. The Simulated SG should have this function. The generation of certain abnormal sequences of messages should also be a capability of this test tool. 3.4 Link Monitor During IUA testing, it will be necessary to monitor the various messages being exchanged between the two IUA endpoints. A link monitor, or network sniffer, should have this function. It should also have the capability to show all the parameters of the message. 4. Test Configurations The set of tests described in this document assumes that the point under test is inserted in a test environment called "test configuration". 4.1 Presentation of test configurations There should be different configurations for testing the IUA protocol. These configurations and hence test cases can be divided on the basis of IUA at SG and IUA at MGC. This document proposed describes configuration for testing the IUA protocol in the Media Gateway Controller (MGC) side (ASP's view). 4.2 Configuration for testing the IUA at AS This subsection describes test scenarios for the IUA protocol in the Media Gateway Controller (MGC) side, so A and B and some other scenarios that could be added in future, refer to ASP's point of view. 4.2.1 Configuration M1 This simple configuration is used for all the procedures of tests concerning only one SG. Configuration M1 is shown in Figure 1. The ASP is handling the traffic from a list of Interface Identifiers in the SG. Host 1 ------------- -------------- | ASP1 | | SG | | under Test | | | | |-------------------------------| | | | | | ------------- -------------- Figure 1 Configuration M1 4.2.2 Configuration M2 This configuration is used for all the procedures of tests concerning two SGs connected to the same ASP. In this case, the ASP will be part of two differents AS. An AS is modeled at the SG, in practical terms, as an ordered list of one or more related Application Server Processes (e.g., primary, secondary, tertiary), configured to process Q.921-User messages from certain Interface Identifiers. -------------- Host 1 | SG1 | ------------- | | | |-------------------------------| | | ASP | | | | Under Test | -------------- | | -------------- | |-------------------------------| SG2 | ------------- | | | | | | -------------- Figure 2 Configuration M2 4.3 Configuration for testing the IUA at AS This subsection describes test scenarios for the IUA protocol in the Signaling Gateway (SG) side, so Configuration S1 and Configuration S2 and some other scenarios that could be added in future, refer to SG's point of view. 4.3.1 Configuration S1 This simple configuration is used for all the procedures of tests concerning only one ASP (1+0 failover scenario). Configuration S1 is shown in Figure 3. The ASP is handling the traffic from a list of Interface Identifiers in SG. ------------- ------------- -------------- | PBX | | SG | | ASP | | or | | under Test | | | | PBX sim |--------------| |-----------| | | | | | | | ------------- ------------- -------------- Fig 3 Configuration S1 4.2.2 Configuration S2 This configuration is used for all the procedures of tests concerning a single SG connected to two ASPs representing a single AS (1+1 failover scenario). Only one ASP will be active at a given point in time. This scenario will be useful for testing failover scenarios. -------------- | ASP1 | ------------- | | | |-------------------------------| | | SG | | | | Under Test | -------------- | | -------------- | |-------------------------------| ASP2 | ------------- | | | | | | -------------- Figure 4 Configuration S2 5. Test Cases for Testing IUA at MGC 5.1 AS management 5.1.1 ASP Transition to Active State ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: ASP reachs to Active State ---------------------------------------------------------------------- PURPOSE: To check that if LMG sends primitive to send ASP management messages to the SG then the corresponding message is sent to the SG. ASP sends the ASP status primitives messages sequence that transitions the ASP to the Active state. After this sequence a new sequence taking the ASP to the Down State will be sent. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG <--------- ASP-Up <----------- ASPUP ACK(ASP-Up) ------------> Status Ind ---------> <--------- ASP-Active <----------- ASPAC ACK(ASP-Active) ------------> Status Ind ---------> <--------- ASP-Inactive <----------- ASPIA ACK(ASP-Inactive) ------------> Status Ind ---------> <--------- ASP-Down <----------- ASPDN ACK(ASP-Down) ------------> Status Ind ---------> TEST DESCRIPTION 1. Send ASP-Up Primitive message from ASP to SG. 2. Check A ASPUP message will be received at the SG. SG should send an ACK(ASP-Up) in response to the ASPUP message on stream 0. 3. Check B ASPM messages are sent on stream 0. 4. Repeat the test case for primitives like, ASP-Active and ASP-Down. ASPDN, ASPAC and ASPUP messages will be sent from ASP to SG with parameters passed from LMG (i.e Test Interface LMG functionality). 5. Check C Interface Id Ranges AND/OR Interface Id List can be used indistinctly in ASP-Active, ASP-Inactive, ACK(ASP-Active) and ACK(ASP-Inactive) messages. 5.1.2 SG rejects ASPUP message from ASP ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: ASP can not reach Up state; SG rejects ASPUP message ---------------------------------------------------------------------- PURPOSE: To check that if an ASPUP msg is acknowledged with a ACK(ASP-Down), ASP remains in Down State. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG <--------- ASP-Up <------------ ASPUP ACK(ASP-Down) ------------> Status Ind ---------> TEST DESCRIPTION 1. Send ASP-Up Primitive message from ASP to SG. 2. Check A ASPUP message will be received at the SG. SG should send an ACK(ASP-Down) in response to the ASPUP message on stream 0. 3. ASPUP will be sent from ASP to SG with parameters passed from LMG (i.e Test Interface LMG functionallity). 4. SG Simulator responds ACK(ASP-Down) with reason parameter set to Management Blocking. 5.1.3 Notify Alternate ASP Active ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: Notify Alternate ASP Active ---------------------------------------------------------------------- PURPOSE: To check that if an ASP in Active State is informed by SG that an alternate ASP has overriden it, the ASP will be moved to Inactive State. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG <--------- ASP-Up <----------- ASPUP ACK(ASP-Up) ------------> Status Ind ---------> <--------- ASP-Active <----------- ASPAC ACK(ASP-Active) ------------> Status Ind ---------> NTFY(ASP-Alternate ------------> ASP Active) Status Ind ---------> TEST DESCRIPTION 1. ASP become to Active State. 2. A NTFY(ASP-Alternate ASP Active) msg is received from SG. 3. Check A ASPM messages are sent on stream 0. 4. Check B ASP is moved to Inactive State. 5. Check C Interface Id Ranges AND/OR Interface Id List can be used indistinctly in ASP-Active and ACK(ASP-Active) messages. 5.1.4 SCTP Communication Down Indication ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: SCTP Communication Down Indication ---------------------------------------------------------------------- PURPOSE: To check that if the local SCTP sends this indication due to the loss of connectivity to the ASP's peer, ASP will be moved to Down State. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Up. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG <--------- ASP-Active <----------- ASPAC ACK(ASP-Active) ------------> Status Ind ---------> -----X X-----SCTP COMMLOST====> ASP moves to Down State Status Ind ---------> TEST DESCRIPTION 1. ASP become to Active State. 2. A loss of connectivity (SCTP Association) happens. 3. Check A ASPM messages are sent on stream 0. 4. Check B ASP is moved to Down State. 5. Check C Interface Id Ranges AND/OR Interface Id List can be used indistinctly in ASP-Active and ACK(ASP-Active) messages. [KAM] - should add to test. SCTP communication restored. ASP should go back to Active state without input from Test Interface? 5.2 ERROR management 5.2.1 Invalid Version Error ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Invalid Version Error ---------------------------------------------------------------------- PURPOSE: To check that if any message with Invalid version is received at the ASP then ASP responds with ERROR message containing cause "Invalid Version" and diagnostic information filled with the version that the SG supports. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Active (The same Test Case could be done with ASP being Up). ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP SM ASP is Active Message XXXX ------------> (Version = 2) <----------- ERROR Cause = Invalid Version TEST DESCRIPTION 1. A message is received from SG with an invalid version in the Common Message Header. 2. Check A ASP sends an Invalid Version Error message to SG. 5.2.2 Unsupported Message Type ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Unsupported Message Type ---------------------------------------------------------------------- PURPOSE: To check that if a message with an undefined message type is received at AS, AS responds with ERROR message containing cause "Unsupported Message Type".To check that if an error is received then this error is reported to the User.Further action at the MGC are implementation dependent. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Active (The same Test Case could be done with ASP being Up). ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG ASP is Active Message XXXX ----------------> Msg Class= any valid value Msg Type= 199 <--------------- ERROR Cause = Unsupported Message Type Error -------> TEST DESCRIPTION 1. A message with an undefined message typeis received at ASP from SG. 2. Check A AS responds with ERROR message containing cause "Unsupported Message Type" 3. Check B Error is reported to the User 5.2.3 Unsupported Message Class ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Unsupported Message Class ---------------------------------------------------------------------- PURPOSE: To check that if a message with message class not defined is received at AS, AS responds with ERROR message containing cause "Unsupported Message Class". To check that if an error is received then this error is reported to the User. Further action at the MGC are implementation dependent. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Active (The same Test Case could be done with ASP being Up). ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG ASP is Active Message XXXX ----------------> Msg Class=199 Msg Type= any valid value <--------------- ERROR Cause = Unsupported Message Class Error -------> TEST DESCRIPTION 1. A message with message type not defined is received at ASP is received from SG. 2. Check A AS responds with ERROR message containing cause "Unsupported Message Type" 3. Check B Error is reported to the User 5.2.4 Unexpected QPTM message ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Unexpected QPTM message ---------------------------------------------------------------------- PURPOSE: To check that if a QPTM message from an SG is received while ASP was in the Inactive state , the "Unexpected Message" error would be sent by the ASP. (the ASP could optionally drop the message and not send an Error) ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Inactive. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 3.3.3.1 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP LMG ASP is Inactive DATA --------------> <--------------- ERROR Unexpected Message Error -------> TEST DESCRIPTION 1. A QPTM message from an SG is received. ASP is in Inactive State 2. Check A ERROR messages are sent. 5.3 ASP configuration 5.3.1 ASP configured to handle traffic for more than one AS ---------------------------------------------------------------------- TITLE: ASP configuration ---------------------------------------------------------------------- SUBTITLE: ASP configured to handle traffic for more than one AS ---------------------------------------------------------------------- PURPOSE: To check that if an ASP has been configured to handle traffic for more than one AS. The IUA layer at the SG maintains the availability state of all dynamically registered remote ASPs, in order to manage the SCTP Associations and the traffic between the SG and ASPs. As well, the active/inactive state of remote ASP(s) are also maintained. Active ASPs are those currently receiving traffic from the SG. ---------------------------------------------------------------------- TEST Configuration: M2 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: An SCTP association is established between each SG and ASP. ASP has been configured to handle traffic from two SG. ASP is Down for AS1 and AS2. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 1.3.3 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE (ASP's view) SG1 SG2 ASP1 (AS1= ASP1,ASP3,...,ASPn) (AS1= ASP1,ASP2,...,ASPm) | | | | |<-------ASP Up -----------| | |--------ASP Up Ack------->| | | | |<---------------------------------ASP Up----------------| |----------------------------------ASP Up Ack----------->| | | | | | | | |<-------ASP Active--------| | |--------ASP Active Ack--->| | | | |<---------------------------------ASP Active------------| |----------------------------------ASP Active Ack------->| | | | | | | | |<-----ASP Inactive--------| | |------ASP Inactive Ack--->| | | | |<-------------------------------ASP Inactive------------| |--------------------------------ASP Inactive Ack------->| | | | | | | TEST DESCRIPTION 1. Send ASP-Up primitive from LMG to ASP. ASPUP message will be sent from ASP to SG1. Send ACK(ASP-Up) from the SG. 2. Repeat the above test case for SG2. 3. Repeat the test case for primitives like, ASP-Active and ASP-Inactive. ASPAC and ASPIA messages will be sent from ASP to SGs with parameters passed from LMG (i.e Test Tool LMG functionality). 4. Check A ASPAC message is received at the SG containing a list of Interface Identifiers that the sending ASP is configured/registered to receive from that SG. If no Interface Identifiers are included, the message is for all provisioned Interface Identifiers within the AS(s) in which the ASP is provisioned. 5.4 Q.921/Q.931 primitives backhaul 5.4.1 Send and Receive Q.921/Q.931 primitives ---------------------------------------------------------------------- TITLE: Q.921/Q.931 primitives backhaul ---------------------------------------------------------------------- SUBTITLE: Establishing of a Data Link on a Signaling Channel. ---------------------------------------------------------------------- PURPOSE: To check that a Data Link on a Signaling Channel is established and Traffic User PDUs can be exchanged. ---------------------------------------------------------------------- TEST Configuration: M1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is in ASP-Active state. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.1.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE (ASP's view) SG ASP Traffic User ASP is Active (Q.931) <--------- DL-Establish Req <------------------------------ Establish Request Establish Confirm -------------------------> ---------> DL-Establish Comf <--------- DL-Data Req <-------------------------------- Data Request Data Indication ----------------------------> ---------> DL-Data Ind <--------- DL-Data Req <-------------------------------- Data Request Data Indication ----------------------------> ---------> DL-Data Ind <--------- DL-Data Req <-------------------------------- Data Request <--------- DL-Data Req <-------------------------------- Data Request Data Indication ----------------------------> ---------> DL-Data Ind <--------- DL-Release Req <-------------------------------- Release Request Release Confirm ---------------------------> ---------> DL-Release Conf TEST DESCRIPTION 1. MGC desires the D channel to be in-service, it will send the Establish Request message to establish a data link to the SG on the signalling channel. DL-Establish Req Primitive is invoked at ASP to send Establish Request message to the SG. This message should be acknownledged by Establish Confirm message. 2. Check A The message is sent on the SCTP stream that corresponds to the D channel (Interface Identifier). 3. Now (Q.931) DATA message from MGC and SG containing Protocol Data can be transmitted or received by the Data link. 4. Check B DATA message is received at MGC and SG containing the data passed by the Traffic User 5. Invoke DL-Release Req Primitive from the LMG at ASP to send Release Request message to the SG. This message should be acknownledged by Release Confirm message. The Data Link is now released. 6. Test Cases for Testing IUA at SG 6.1 AS management 6.1.1 ASP Transition to Active State ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: ASP reachs to Active State ---------------------------------------------------------------------- PURPOSE: To check that if LMG sends primitive to send ASP management messages to the SG then the corresponding message is sent to the SG. ASP sends the ASP status primitives messages sequence that transitions the ASP to the Active state. After this sequence a new sequence taking the ASP to the Down State will be sent. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP <----------- ASPUP ACK(ASP-Up) ------------> <----------- ASPAC ACK(ASP-Active) ------------> <----------- ASPIA ACK(ASP-Inactive) -----------> <----------- ASPDN ACK(ASP-Down) ------------> TEST DESCRIPTION 1. Send ASP-Up Primitive message from ASP to SG. 2. SG should send an ACK(ASP-Up) in response to the ASPUP. 3. Check B ASPM messages are sent on stream 0. 4. Repeat the test case for primitives like, ASP-Active and ASP-Down. ASPDN, ASPAC and ASPUP messages will be sent from ASP to SG. 5. Check C Interface Id Ranges AND/OR Interface Id List can be used indistinctly in ASP-Active, ASP-Inactive, ACK(ASP-Active) and ACK(ASP-Inactive) messages. 6.1.2 ASP Active Before ASP Up ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: ASP Active sent Before ASP Up ---------------------------------------------------------------------- PURPOSE: To check that ASP Active is rejected if ASP not in Up state. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP <----------- ASPAC ACK(ASP-Down) ------------> TEST DESCRIPTION 1. Send ASPAC message from ASP to SG. 2. SG should send an ACK(ASP-Down) in response to the ASPAC message on stream 0. 6.1.3 Notify AS Pending ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: Notify AS Pending ---------------------------------------------------------------------- PURPOSE: To check that Notify (AS-Pending) will be sent if Active ASP transitions to Inactive. ---------------------------------------------------------------------- TEST Configuration: S2 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP associations are established between SG and both ASPs. ASPs are down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP1 ASP2 <----------- ASPUP ACK(ASP-Up) ------------> <--------------------------------------- ASPUP ACK(ASP-Up) --------------------------------------> <----------- ASPAC ACK(ASP-Active) ------------> <----------- ASPIA ACK(ASP-Inactive) ------------> Notify (AS-Pending) ---------------------------------> <--------------------------------------- ASPAC ACK(ASP-Active) -------------------------------------> TEST DESCRIPTION 1. ASP Up sent from both ASPs. 2. ASP1 sends ASP Active to transition to Active State. 3. ASP1 sends ASP Inactive to transition to Inactive State. 4. SG sends a NTFY(AS-Pending) message to ASP2. 5. ASP2 sends ASP Active (if and when it is willing to transition to Active state). 6.1.4 Notify Alternate ASP Active ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: Notify Alternate ASP Active ---------------------------------------------------------------------- PURPOSE: To check that SG will send Notify (Alternate ASP Active) if one ASP overrides another ASP. ---------------------------------------------------------------------- TEST Configuration: S2 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP associations are established between SG and both ASPs. ASPs are Down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP1 ASP2 <----------- ASPUP ACK(ASP-Up) ------------> <--------------------------------------- ASPUP ACK(ASP-Up) --------------------------------------> <----------- ASPAC ACK(ASP-Active) ------------> <--------------------------------------- ASPAC ACK(ASP-Active) -------------------------------------> Notify (Alt ASP Active) ----> TEST DESCRIPTION 1. Both ASPs transition to Up state. 2. ASP1 transitions to Active state. 3. ASP2 transitions to Active state. 4. SG sends a NTFY(Alternate ASP Active) to ASP1 to notify it that ASP2 has overridden it. 6.1.5 SCTP Communication Down Indication ---------------------------------------------------------------------- TITLE: AS management ---------------------------------------------------------------------- SUBTITLE: SCTP Communication Down Indication ---------------------------------------------------------------------- PURPOSE: To check that if the local SCTP sends this indication due to the loss of connectivity to the ASP's peer, ASP will be moved to Down State. SCTP CDI is understood as either a SHUTDOWN COMPLETE notification and COMMUNICATION LOST notification from the SCTP. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Up. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP <----------- ASPAC ACK(ASP-Active) ------------> <----------- Establish Request Establish Confirm ----------> <----------- Establish Request Establish Confirm ----------> <=====SCTP COMM LOST====> ASP moves to Down State <=====SCTP COMM RESTORED====> <----------- ASPAC ACK(ASP-Active) ------------> <----------- Establish Request Establish Confirm ----------> <----------- Establish Request Establish Confirm ----------> TEST DESCRIPTION 1. ASP become to Active State. 2. Two D channels established. 3. A loss of connectivity (SCTP Association) occurs. 4. Check B ASP is moved to Down State. Note effect on D channel state. 5. A restoration of connectivity (SCTP Association) occurs. 6. ASP should re-establish previous ASP state and D channel state. 6.2 ERROR management 6.2.1 Invalid Version Error ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Invalid Version Error ---------------------------------------------------------------------- PURPOSE: To check that if any message with Invalid version is sent from SG if it receives a message that contains a version it does not support. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP <----------- ASP Up (Version = 2) Error ------------> (Invalid Version) TEST DESCRIPTION 1. A message is received by SG with an invalid version in the Common Message Header. 2. Check A SG sends an Invalid Version Error message to ASP. 6.2.2 Unsupported Message Type ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Unsupported Message Type ---------------------------------------------------------------------- PURPOSE: To check that if a message with an undefined message type is received at SG, SG responds with ERROR message containing cause "Unsupported Message Type". ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Active (The same Test Case could be done with ASP being Up). ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP ASP is Active <----------- Message XXXX (Msg Class = any valid value, Msg Type = 199) Error ------------> (Unsupported Message Type) TEST DESCRIPTION 1. A message with an undefined message type is sent from ASP to SG. 2. Check A SG responds with ERROR message containing cause "Unsupported Message Type". 6.2.3 Unsupported Message Class ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Unsupported Message Class ---------------------------------------------------------------------- PURPOSE: To check that if a message with message class not defined is received at SG, SG responds with ERROR message containing cause "Unsupported Message Class". ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Active (The same Test Case could be done with ASP being Up). ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP ASP is Active <----------- Message XXXX (Msg Class = 199, Msg Type = any valid value) Error ------------> (Unsupported Message Class) TEST DESCRIPTION 1. A message with message class that is not defined is received by SG. 2. Check A SG responds with ERROR message containing cause "Unsupported Message Type". 6.2.4 Invalid Interface Identifier ---------------------------------------------------------------------- TITLE: ERROR Management ---------------------------------------------------------------------- SUBTITLE: Invalid Interface Identifier ---------------------------------------------------------------------- PURPOSE: To check that the SG will respond with Error (Invalid Interface Identifier) if the ASP sends a message for an Invalid Interface Identifier (one that is not configured on SG). ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is Active (The same Test Case could be done with ASP being Up). ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.3.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP ASP is Active <----------- Establish Request ( with invalid Interface Identifier) Error ------------> (Invalid Interface Identifier) TEST DESCRIPTION 1. ASP sends Establish Request with an invalid Interface Identifier. 2. Check A SG responds with ERROR message containing cause "Invalid Interface Identifier". 6.2.5 Unexpected QPTM message ---------------------------------------------------------------------- TITLE: ERROR management ---------------------------------------------------------------------- SUBTITLE: Unexpected QPTM message ---------------------------------------------------------------------- PURPOSE: To check that if a QPTM message is sent from ASP while ASP is not Active, the SG will send "Unexpected Message" error in response. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 3.3.3.1 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP <----------- ASPUP ACK(ASP-Up) ------------> <----------- Establish Request Error (Unexpected Msg) -----> TEST DESCRIPTION 1. Send ASP-Up Primitive message from ASP to SG. 2. Check A ASPUP message will be received at the SG. 3. Send a QPTM (i.e. Establish Request) message from the MGC. 4. Check A ERROR message with Unexpected Message is sent. 6.3 ASP configuration 6.3.1 SG supports more than one ASP (optional) ---------------------------------------------------------------------- TITLE: ASP configuration ---------------------------------------------------------------------- SUBTITLE: SG configured to support >1 ASP ---------------------------------------------------------------------- PURPOSE: To check that if an SG can support more than one ASP. In this case, one ASP will support a number of Interface Identifiers and the other ASP will support other Interface Identifiers. Note: The Interface Identifiers must not overlap between ASPs. ---------------------------------------------------------------------- TEST Configuration: S2 (ASPs are independent, not in failover configuration) ---------------------------------------------------------------------- PRE-TEST CONDITIONS: An SCTP association is established between each SG and ASP. Both ASPs are Down. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 1.3.3 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP1 ASP2 <----------- ASPUP ACK(ASP-Up) ------------> <--------------------------------------- ASPUP ACK(ASP-Up) --------------------------------------> <----------- ASPAC ACK(ASP-Active) ------------> <--------------------------------------- ASPAC ACK(ASP-Active) -------------------------------------> <----------- Establish Request Establish Confirm ----------> <--------------------------------------- Establish Request Establish Confirm -----------------------------------> TEST DESCRIPTION 1. Both ASPs transition to Active state. 2. Both ASPs bring a D channel in-service. 6.4 Q.921/Q.931 primitives backhaul 6.4.1 Send and Receive Q.921/Q.931 primitives ---------------------------------------------------------------------- TITLE: Q.921/Q.931 primitives backhaul ---------------------------------------------------------------------- SUBTITLE: Establishing of a Data Link on a Signaling Channel. ---------------------------------------------------------------------- PURPOSE: To check that a Data Link on a Signaling Channel is established and Traffic User PDUs can be exchanged. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is in ASP-Active state. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.1.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE (ASP's view) SG ASP ASP is Active <------------------------------ Establish Request Establish Confirm -------------------------> <-------------------------------- Data Request Data Indication ----------------------------> <-------------------------------- Data Request Data Indication ----------------------------> <-------------------------------- Data Request <-------------------------------- Data Request Data Indication ----------------------------> <-------------------------------- Release Request Release Confirm ---------------------------> TEST DESCRIPTION 1. MGC desires the D channel to be in-service, it will send the Establish Request message to establish a data link to the SG on the signalling channel. DL-Establish Req Primitive is invoked at ASP to send Establish Request message to the SG. This message should be acknownledged by Establish Confirm message. 2. Check A The message is sent on the SCTP stream that corresponds to the D channel (Interface Identifier). 3. Now (Q.931) DATA message from MGC and SG containing Protocol Data can be transmitted or received by the Data link. 4. Check B DATA message is received at MGC and SG containing the data passed by the Traffic User 5. Invoke DL-Release Req Primitive from the LMG at ASP to send Release Request message to the SG. This message should be acknownledged by Release Confirm message. The Data Link is now released. 6.4.2 Send Release Indication ---------------------------------------------------------------------- TITLE: Release Indication ---------------------------------------------------------------------- SUBTITLE: Release Indication Sent when Upon failure of Data Link ---------------------------------------------------------------------- PURPOSE: To check that a SG will send Release Indication when Data Link fails. ---------------------------------------------------------------------- TEST Configuration: S1 ---------------------------------------------------------------------- PRE-TEST CONDITIONS: SCTP association is established between SG and ASP. ASP is in ASP-Active state. ---------------------------------------------------------------------- Reference: RFCXXXX Clause 4.1.2 ---------------------------------------------------------------------- EXPECTED MESSAGE SEQUENCE SG ASP ASP is Active <------------------------------ Establish Request Establish Confirm -------------------------> <-------------------------------- Data Request Data Indication ----------------------------> <-------------------------------- Data Request Data Indication ----------------------------> <-------------------------------- Data Request <-------------------------------- Data Request Data Indication ----------------------------> <==== Data Link Disconnected ====> ---------------------------------> Release Indication TEST DESCRIPTION 1. MGC desires the D channel to be in-service, it will send the Establish Request message to establish a data link to the SG on the signalling channel. DL-Establish Req Primitive is invoked at ASP to send Establish Request message to the SG. This message should be acknownledged by Establish Confirm message. 2. Check A The message is sent on the SCTP stream that corresponds to the D channel (Interface Identifier). 3. Now (Q.931) DATA message from MGC and SG containing Protocol Data can be transmitted or received by the Data link. 4. Check B DATA message is received at MGC and SG containing the data passed by the Traffic User 5. Disconnect D channel physical interface. SG should generate Release Indication message. NEED TO ADD HEARTBEAT FAILURE 7. Acknowledgement The authors are highly grateful to Maria Pilar Sanchez, Maria Sonia Vazquez, Pablo Alonso Martin, Maria de Miguel, Jaime Olivares and Antonio Alonso for their valuable comments and suggestions. 8. Author Address Jose Luis Jimenez Ramirez EMail ecejljr@ece.ericsson.se Ericsson Spain s.a. Torre Urbis.C/Ombu, 3 28045 Madrid Spain Ken Morneault EMail kmorneau@cisco.com Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA 9. References [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - General Aspects' [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a Voice over Packet Network' [3] Stream Control Transmission Protocol, RFC 2960, October 2000 [4] Architectural Framework for Signaling Transport, RFC 2719 , October 1999 [5] ISDN Q.921-User Adaptation Layer, RFC XXXX, January 2001 [6] Site Security Handbook, RFC 2196, September 1997 [6] Security Architecture for the Internet Protocol, RFC 2401 | ||||||||||||||||
Last modified: Mon, 26 Aug 2024 23:28:00 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. |