| draft-jimenez-morneault-iua-test-spec-00 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-jimenez-morneault-iua-test-spec-00.txt.
Network Working Group Jose Luis Jimenez Ramirez
INTERNET-DRAFT Ericsson
Ken Morneault
Cisco Systems
Expires in six months Jan 2001
ISDN Q.921-User Adaptation Layer Test Specification
<draft-jimenez-morneault-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-----------------------------
4.3 Configuration for testing the IUA at SG-----------------------------
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 SG
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
|
Documentation