Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-ietf-sigtran-iua-01

Description: Request For Comments

You can download source copies of the file as follows:

draft-ietf-sigtran-iua-01.txt in text format.

Listed below is the contents of file draft-ietf-sigtran-iua-01.txt.


Network Working Group                                  Malleswar Kalla
INTERNET-DRAFT                                        Selvam Rengasami
                                                Telcordia Technologies
                                                         Ken Morneault
                                                         Cisco Systems
                                                       Greg Sidebottom
                                                       Nortel Networks

Expires in six months                                         Oct 1999

                  ISDN Q.921-User Adaptation Layer
                  <draft-ietf-sigtran-iua-01.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 Internet Draft defines a protocol for backhauling of ISDN Q.921
User messages over IP using the Simple Control Transmission Protocol
(SCTP). This protocol would be used between a Signaling Gateway (SG)
and Media Gateway Controller (MGC). It is assumed that the SG receives
ISDN signaling over a standard ISDN interface.

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 1]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

                        TABLE OF CONTENTS

1.  Introduction.....................................................2
  1.1  Scope.........................................................2
  1.2  Terminology...................................................3
  1.3  Signaling Transport Architecture..............................3
  1.4  Services Provided by the IUA Layer............................4
  1.5  Functions Implemented by the IUA Layer........................6
  1.6  Definition of IUA Boundaries..................................7
2.  Protocol Elements................................................7
  2.1  Common Message Header.........................................7
  2.2  IUA Message Header............................................8
  2.3  Description of Messages.......................................9
3.  Procedures......................................................13
  3.1  Procedures to Support Service in Section 1.4.1...............13
  3.2  Procedures to Support Service in Section 1.4.2...............14
  3.3  Procedures to Support Service in Section 1.4.3...............14
4. Examples.........................................................18
  4.1 Establishment of associations between SG and MGC examples.....18
  4.2 Q.921/Q.931 primitives backhaul Examples......................19
  4.3 Layer Management Communication Examples.......................20
5.  Security........................................................20
6.  Acknowledgements................................................20
7.  References......................................................20
8.  Author's Addresses..............................................21

1.  Introduction

In this document, the term Q.921 user refers to an upper layer which
uses the services of Q.921, not the user side of ISDN interface. 
Examples of the upper layer would be Q.931 and QSIG.

This section describes the need for ISDN Q.921 User Adaptation (IUA)
layer protocol as well as how this protocol shall be implemented.

1.1 Scope

There is a need for Switched Circuit Network (SCN) signaling protocol
delivery from an ISDN Signaling Gateway (SG) to a Media Gateway
Controller (MGC).  The delivery mechanism should meet the following
criteria

*  Support for transport of the Q.921 / Q.931 boundary primitives
*  Support for communication between Layer Management modules on SG
   and MGC
*  Support for management of active associations between SG and MGC

This draft supports both ISDN Primary Rate Access (PRA) as well as
Basic Rate Access (BRA) including the support for both point-to-point
mode and point-to-multipoint modes of communication.  QSIG adaptation
layer requirements do not differ from Q.931 adaptation layer, hence
the procedures described in this draft are also applicable to QSIG

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 2]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

adaptation layer.  For simplicity, only Q.931 will be mentioned in the
rest of this document.

1.2 Terminology

Interface - For the purposes of this document an interface supports the
relevant ISDN signalling channel. This signalling channel may be a
16 kbps D channel for an ISDN BRA as well as 64 kbps primary or backup
D channel for an ISDN PRA.  For QSIG, the signalling channel is a Qc
channel.

Q.921-User - Any protocol normally using the services of the ISDN
Q.921 (e.g., Q.931, QSIG, etc.).

Backhaul - A SG terminates the lower layers of an SCN protocol and 
backhauls the other layer to MGC for call processing. For the purposes 
of this draft the SG terminates Q.921 and backhauls Q.931 to MGC.

Association - An association refers to a SCTP association.  The
association will provide the transport for the delivery of Q.921-User
protocol data units and IUA adaptation layer peer messages.

Stream - A stream refers to a SCTP stream.  For the purposes of this
document, a stream will be mapped to an ISDN signalling channel. 

Application Server (AS) - A logical entity serving a specific 
application instance.  An example of an Application Server is a MGC 
handling the Q.931 and call processing for D channels terminated by 
the Signaling Gateways.  Practically speaking, an AS is modeled at 
the SG as an ordered list of one or more related Application Server 
Processes (e.g., primary, secondary, tertiary, ). 

Application Server Process (ASP) - A process instance of an Application 
Server.  Examples of Application Server Processes are primary or backup 
MGC instances.

Application Server Process Path (ASP Path or just Path) - A Path to a 
remote Application Server Process instance.  A Path maps 1:1 to an SCTP 
association.

Fail-over - The capability to re-route signalling traffic as required
between related ASPs in the event of failure or unavailability of the
currently used ASP (e.g. from primary MGC to back-up MGC). Fail-over
also applies upon the return to service of a previously unavailable
process.

1.3 Signaling Transport Architecture

The architecture that has been defined [5] for SCN signaling transport
over IP uses multiple components, including an IP transport
protocol, a signaling common transport protocol and an adaptation
module to support the functions expected by a particular SCN signaling
protocol from its underlying protocol layer.

This document defines an adaptation module that is suitable for the
transport of ISDN Q.921 User (Q.931).

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 3]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

In a Signaling Gateway, it is expected that the ISDN signaling is
received over a standard ISDN network termination. The SG then
provides interworking of transport functions with IP Signaling
Transport, in order to transport the Q.931 signaling messages to the
MGC where the peer Q.931 protocol layer exists, as shown below

******   ISDN        ******      IP      *******
* EP *---------------* SG *--------------* MGC *
******               ******              *******

+-----+                                  +-----+
|Q.931|                                  |Q.931|
+-----+           +----------+           +-----+
|     |           |     | IUA|           | IUA |
|     |           |     +----+           +-----+
|Q.921|           |Q.921|SCTP|           |SCTP |
|     |           |     +----+           +-----+
|     |           |     |UDP |           | UDP |
|     |           |     +----+           +-----+
|     |           |     | IP +           | IP  |
+-----+           +-----+----+           +-----+

EP  - ISDN End Point
SCTP - Simple Control Transmission Protocol (Refer to [3])
IUA  - ISDN User Adaptation Layer Protocol

1.3.1 UDP port

A request will be made to IANA to assign a UDP port for IUA.

1.4 Services Provided by the IUA Layer

1.4.1  Support for transport of Q.921/Q.931 boundary primitives

In the backhaul scenario, the Q.921/Q.931 boundary primitives are
exposed.  IUA layer needs to support all of the primitives of this
boundary to successfully backhaul Q.931.

This includes the following primitives [1]

DL-ESTABLISH

The DL-ESTABLISH primitives are used to request, indicate and confirm
the outcome of the procedures for establishing multiple frame
operation.

DL-RELEASE

DL-RELEASE primitives are used to request, indicate, and confirm the
outcome of the procedures for terminating a previously established
multiple frame operation, or for reporting an unsuccessful
establishment attempt.

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 4]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

DL-DATA

The DL-DATA primitives are used to request and indicate SDUs
containing Q.931 PDUs which are to be transmitted, or have been
received, by the Q.921 layer using the acknowledged information
transfer service.

DL-UNIT DATA

The DL-UNIT DATA primitives are used to request and indicate SDUs
containing Q.931 PDUs which are to be transmitted, by the Q.921 layer
using the unacknowledged information transfer service.

1.4.2  Support for communication between Layer Management modules
       on SG and MGC

It is envisioned that the IUA layer needs to provide some services
that will facilitate communication between Layer Management modules on
the SG and MGC. These primitives are pointed out in [2], which are
shown below

MIUA-TEI STATUS

The MIUA-TEI STATUS primitives are used to request, confirm and
indicate the status (in service/out of service) of a TEI.

To facilitate reporting of errors that arise because of backhauling
Q.931 scenario, the following primitive is defined

M-ERROR

The M-ERROR primitive is used to indicate an error with a received
IUA message (e.g., interface identifier value is not known to the SG).

1.4.3 Support for management of active associations between SG and MGC

The IUA layer on the SG keeps the state of various ASPs it is
associated with. A set of primitives between IUA layer and the Layer
Management are defined below to help the Layer Management manage the
association(s) between SG and MGC.

The IUA layer can be instructed by the Layer Management to establish
SCTP association to a peer IUA node. This can be achieved using the
following primitive

M-SCTP ESTABLISH

The M-SCTP ESTABLISH primitives are used to request, indicate, and
confirm the establishment of SCTP association to a peer IUA node.

The IUA layer may also need to inform the status of the SCTP
associations to the Layer Management. This can be achieved using the
following primitive

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 5]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

M-SCTP STATUS

The M-SCTP STATUS primitives are used to request and indicate the
status of the underlying SCTP association(s).

The Layer Management may need to inform the IUA layer of a user status
(i.e., failure, active, etc.), so that messages can be exchanged
between IUA layer peers to stop traffic to the local IUA user.  This
can be achieved using the following primitive.

M-ASP STATUS

The M-ASP STATUS primitives are used to request and indicate the
status of the Application Server Process.

1.5 Functions Implemented by the IUA Layer

1.5.1 Mapping

The IUA layer must maintain a map of the Interface ID to a physical
interface on the Signaling Gateway.  A physical interface would
be a T1 line, E1 line, etc. In addition, for a given interface the SG
must be able to identify the associated signalling channel.

1.5.2 Status of ASPs

The IUA layer on the SG must maintain the state of various ASPs it is
associated with. The state of an ASP changes because of reception of
peer-to-peer messages or reception of indications from the local SCTP
association. ASP state transition procedures are described in
section 3.3.1.

1.5.3 SCTP Stream Management

SCTP allows a user specified number of streams to be opened during the
initialization. It is the responsibility of the IUA layer to ensure
proper management of these streams. Because of the unidirectional
nature of streams, IUA layers are not aware of the stream information
from the peer IUA layers. For the purposes of this draft, it is
assumed that a separate stream will be used for each D channel.

1.5.4 Seamless Network Management Interworking

The IUA layer on the SG should pass an indication of unavailability of
the IUA-User (Q.931) to the local Layer Management, if the currently
active ASP moves from the ACTIVE state. The Layer Management could
instruct Q.921 to take some action, if it deems appropriate.

1.5.5 Management Inhibit/Uninhibit

Local Management may wish to stop traffic across an SCTP association
in order to temporarily remove the association from service or to
perform testing and maintenance activity.  The function could

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 6]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

optionally be used to manage the start of traffic on to a newly
available SCTP association.

1.6 Definition of IUA Boundaries

1.6.1 Definition of IUA/Q.921 boundary

DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA

1.6.2 Definition of IUA/Q.931 boundary

DL-ESTABLISH
DL-RELEASE
DL-DATA
DL-UNIT DATA

1.6.3 Definition of SCTP/IUA Boundary

The upper layer primitives provided by SCTP are available in
Reference [3] section 9.

1.6.4 Definition of IUA/Layer-Management Boundary

M-ERROR
M-SCTP ESTABLISH
M-SCTP STATUS
M-ASP STATUS
MIUA-TEI STATUS

2. Protocol Elements

This section describes the format of various messages used in this 
protocol.

2.1 Common Message Header

The protocol messages for Q.921 User Adaptation require a message
header which contains the adaptation layer version, the message type,
and message length. All types of messages contain this header. This
message header is common among all SCN signaling protocol adaptation
layers.

    0     7 8    15 16           31
   +---------------+---------------+
   | Vers | Spare  |   Msg Type    |
   +---------------+---------------+
   |        Message Length         |
   +-------------------------------+
     Figure 1 Common Header Format

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 7]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

2.1.1 Version

The version field (vers) contains the version of the IUA adaptation
layer.  The supported versions are

      01   Release 1.0 protocol

2.1.2  Message Types

The following list contains the message names for the defined
messages.

     Q.921/Q.931 Boundary Primitives Transport (QAUP) Messages

        Data Request Message                       0501
        Data Indication Message                    0502
        Unit Data Request Message                  0503
        Unit Data Indication Message               0504
        Establish Request                          0505
        Establish Confirm                          0506
        Establish Indication                       0507
        Release Request                            0508
        Release Confirm                            0509
        Release Indication                         0510

      Application Server Process Maintenance (ASPM) messages

        ASP Up                                     0301
        ASP Down                                   0302
        ASP Active                                 0401
        ASP Inactive                               0402

     Management (MGMT) Messages

        Error Indication                           0000
        TEI Status Request                         0101
        TEI Status Confirm                         0102
        TEI Status Indication                      0103

2.1.3 Message Length

The Message length defines the length of the message in octets, not
including the common Message header.

2.2 IUA Message Header

In addition to the common message header, there will be a specific
message header for QAUP and TEI related MGMT messages.  The IUA
message header will immediately follow the common message header in
these messages.

This message header will contain the Interface Identifier and Data
Link Connection Identifier(DLCI). The Interface Identifier identifies

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 8]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

the physical interface terminating the signalling channel at the SG
for which the signaling messages are sent/received.  The interface
identifier follows the same endpoint naming scheme provided in
MGCP [4]. The length field indicates the end of the string.
For example, if a Signaling Gateway terminates a T1 and the D channel
is on timeslot 24, the interface id could be the following

t1/24@sgw1.example.net

The use of wildcards is not acceptable.

Ed's Note:  The Interface Identifier string should be padded to 32-bit
boundaries.

    0     7 8    15 16           31
    +---------------+---------------+
    |   Tag (0x1)   |     Length    |
    +-------------------------------+

    |    Interface Identifier       |

    +-------------------------------+
    |  DLCI         |   Spare       |
    +-------------------------------+
     Figure 2 IUA Message Header

The DLCI format is shown below in Figure 3.

      0     1     2     3     4     5     6     7
   +-----+-----+-----+-----+-----+-----+-----+-----+
   |  0  | SPR |      SAPI                         |
   +-----------------------------------------------+
   |  1  |            TEI                          |
   +-----------------------------------------------+
     Figure 3 DLCI Format

SPR  Spare, 2nd bit in octet 1
SAPI Service Access Point Identifier, 3rd thru 8th bits in octet 1
TEI  Terminal Endpoint Identifier, 2nd thru 8th bits in octet 2

The DLCI field (including the SAPI and TEI) is coded in accordance
with Q.921.

2.3 Description of Messages

2.3.1  Establish Messages (Request, Confirm, Indication)

The Establish Messages are used to establish a data link on the
signalling channel or to confirm that a data link on the signalling
channel has been established.

Kalla, Rengasami, Morneault, & Sidebottom                     [Page 9]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

The Establish messages contain the common message header followed by
IUA message header. It does not contain any additional parameters.

2.3.2  Release Messages (Request, Indication, Confirmation)

The Release Request message is used to release the data link on the
signalling channel. The Release Confirm and Indication messages are
used to indicate that the data link on the signalling channel has
been released.

The Release messages contain the common message header followed by
IUA message header. The Release confirm message is in response to
a Release Request message and it does not contain any additional
parameters. The Release Request and Indication messages contain the
following parameters

     REASON

    0            15 16           31
   +---------------+---------------+
   |            Reason             |
   +---------------+---------------+

The valid values for Reason are shown in the following table.

      Define     Value           Description
   RELEASE_MGMT   0x0     Management layer generated release.
   RELEASE_PHYS   0x1     Physical layer alarm generated release.
   RELEASE_DM     0x2     Specific to a request. Indicates Layer 2
                          should release and deny all requests from
                          far end to establish a data link on the
                          signalling channel (i.e. if SABME is
                          received send a DM)
   RELEASE_OTHER  0x3     Other reasons

Note Only RELEASE_MGMT, RELEASE_DM and RELEASE_OTHER are valid
reason codes for a Release Request message.

2.3.3 Data Messages (Request, Indication)

The Data message contains an ISDN Q.921-User Protocol Data Unit (PDU)
corresponding to acknowledged information transfer service.

The Data messages contain the common message header followed by IUA
message header. The Data message contains the following parameters

     PROTOCOL DATA           

    0            15 16           31
   +---------------+---------------+
                   ...
   |        Protocol Data          |
                   ...
   +---------------+---------------+

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 10]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

The protocol data contains upper layer signalling message e.g.
Q.931, QSIG.

2.3.4 Unit Data Messages (Request, Indication)

The Unit Data message contains an ISDN Q.921-User Protocol Data Unit
(PDU) corresponding to unacknowledged information transfer service.

The Unit Data messages contain the common message header followed by
IUA message header. The Unit Data message contains the following
parameters

     PROTOCOL DATA           

    0            15 16           31
   +---------------+---------------+
                   ...
   |        Protocol Data          |
                   ...
   +---------------+---------------+

2.3.5 ASP Messages (Up, Down, Active, Inactive)

The ASP messages are exchanged between IUA layer peers to notify the
state of the Application Server Process.

The ASP messages contain the common message header and the following
optional parameters

     Adaptation Layer Identifier 
     SCN Protocol Identifier
     Info String
     
The Adaptation Layer Identifier is a string that identifies the
adaptation layer. This string must be set to "IUA".

The Protocol Identifier field contains the identity of the specific
SCN signaling protocol being transported.  The Protocol ID defines the 
protocol type, variant, and version, and thereby specifies the
components and encoding of the PROTOCOL DATA field. The Protocol
Identifier also defines what SCN protocol message components are
included in the PROTOCOL DATA field.

(Ed's Note Need encoding of mime-type value or OID or fixed 
string/integer that will be administered outside of this document 
(IANA). Also, perhaps bring in text from Christian's mime document -
See "draft-ietf-sigtran-mime-isup.txt" for an example of an
application/ISUP media type defined according to the rules defined in
RFC 2048.)

Info String field can be used for implementation specific diagnostic
information.

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 11]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

The format for the ASP messages is as follows

    0            15 16           31
   +---------------+---------------+
   |   Tag (0x2)   |    Length     |
   +---------------+---------------+
    
   |  Adaptation Layer Identifier  |

   +---------------+---------------+
   |   Tag (0x3)   |    Length     |
   +---------------+---------------+
    
   |    SCN Protocol Identifier     |

   +---------------+---------------+
   |   Tag (0x4)   |    Length     |
   +---------------+---------------+
    
   |          Info String          |

   +---------------+---------------+

Ed's Note  Strings are padded to 32-bit boundaries.  The length field
indicates the end of the string.

2.3.6 TEI Status Messages (Request, Confirm and Indication)

The TEI Status messages are exchanged between IUA layer peers to
request, confirm and indicate the status of a particular TEI.

The TEI Status messages contain the common message header followed by
IUA message header. The TEI Status Request message does not contain
any additonal parameters.

The TEI Status Indication, and Confirm messages contain the following
parameters

     STATUS

    0      7     15 16           31
   +---------------+---------------+
   |           Status              |
   +-------------------------------+

The valid values for Status are shown in the following table.

      Define     Value           Description
   IN_SERVICE     0x0     TEI is in service
   OUT_OF_SERVICE 0x1     TEI is out of service

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 12]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

2.3.7 Error Message (Indication)

The Error Message is used to indicate any errors occured because of
the backhaul architecture.

The Error messages contain the common message header followed by
IUA message header. The Error Message contains the following
parameters

     REASON
     OTHER INFORMATION

    0            15 16           31
   +---------------+---------------+
   |            Reason             |
   +---------------+---------------+

   |      Other Information        |

   +---------------+---------------+

The valid values for Reason are shown in the following table.

      Define     Value           Description
   INVALID_TEI    0x0     Invalid TEI 
   INVALID_IFID   0x1     Invalid interface ID
   UNDEFINED_MSG  0x2     An unexpected message was received
   VERSION_ERR    0x3     The IUA layers are of different version
   INVALID_STID   0x4     Invalid SCTP stream identifier
   INVALID_SCNV   0x5     Invalid SCN version
   INVALID_ALI    0x6     Invalid Adaptation Layer Identifier

Other Information field can contain diagnostic information related to
the error. It can contain a copy of the received message that
resulted in the error.

3.0 Procedures

The IUA layers needs to respond to various primitives it receives from
other layers as well as messages it receives from the peer-to-peer
messages. This section describes various procedures involved in
response to these events.

3.1 Procedures to support service in section 1.4.1

These procedures achieve the IUA layer's "Transport of Q.921/Q.931
boundary" service.

3.1.1 Q.921 or Q.931 primitives procedures

On receiving these primitives from the local layer, the IUA layer will
send the corresponding QAUP message (Data, Unit Data, Establish,
Release) to its peer. While doing so, the IUA layer needs to fill
various fields of the common and specific headers correctly. In

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 13]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

addition the message needs to be sent on the SCTP stream that
corresponds to the D channel.

3.1.2 QAUP message procedures

On receiving QAUP messages from a peer IUA layer, the IUA layer on an
SG or MGC needs to invoke the corresponding layer primitives
(DL-ESTABLISH, DL-DATA, DL-UNIT DATA, DL-RELEASE) to the local Q.921
or Q.931 layer.

3.2 Procedures to support service in section 1.4.2

These procedures achieve the IUA layer's "Support for Communication
between Layer Managements" service.

3.2.1 Layer Management primitives procedures

On receiving these primitives from the local layer, the IUA layer will
send the corresponding MGMT message (TEI Status, Error) to its peer.
While doing so, the IUA layer needs to fill various fields of the
common and specific headers correctly.

3.2.2 MGMT message procedures

On receiving MGMT messages the IUA layer needs to invoke the
corresponding Layer Management primitives (MIUA-TEI STATUS, M-ERROR)
to the local layer management.

3.3 Procedures to support service in section 1.4.3

These procedures achieve the IUA layer's "Support for management of
active associations between SG and MGC" service.

3.3.1 State Maintenance

The IUA layer on the SG needs to maintain the states of each ASP as
well as the state of the AS.

3.3.1.1  ASP States

The state of the each ASP is maintained in the IUA layer on the SG.
The state of an ASP changes due to events. The events include

* Reception of messages from peer IUA layer
* Reception of indications from SCTP layer

The possible states of an ASP are

ASP-DOWN Application Server Process is unavailable. Initially all
ASPs will be in this state.

ASP-UP Application Server Process is available but application
traffic is stopped.

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 14]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

ASP-ACTIVE Application Server Process is available and application
traffic is active.  At most one ASP per AS can be in the active state.
                

                 Figure 4 ASP State Transition Diagram

                               +-------------+
                     |-------->|             |      
                     |         |  ASP-ACTIVE |
                     |         |             |
                     |         |             |
                     |         +-------------+
                     |             ^     | 
                     |      ASP    |     | ASP
                     |      Active |     | Inactive
                     |             |     v    
                     |         +-------------+
                     |         |             |
         ASP Down /  |         |             |
          SCTP CDI   |         |  ASP-UP     |
                     |         |             |
                     |         |             |
                     |         +-------------+
                     |             ^    |
                     |        ASP  |    | ASP Down /
                     |        Up   |    | SCTP CDI
                     |             |    v
                     |         +-------------+
                     |         |             |        
                     |-------->|             |  
                               |  ASP-DOWN   |
                               |             |
                               |             |
                               +-------------+

SCTP CDI: Local SCTP layer's Communication Down Indication to the
Upper Layer Protocol (IUA) on an SG. SCTP will send this indication
when it detects the loss of connectivity to ASP's SCTP layer.

3.3.1.2  AS States

The state of the AS is maintained in the IUA layer on the SG.
The state of an AS changes due to events. These events include

* ASP state transitions
* Recovery timer triggers

The possible states of an AS are

AS-DOWN Application Server is unavailable.  This state implies that
  all ASPs are in the ASP-DOWN state for this AS. Initially the AS will
  be in this state.

AS-UP One or more ASPs are in the ASP-UP state.

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 15]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

AS-ACTIVE Application Server is available and application traffic is
  active.  This state implies that one ASP is in the ASP-ACTIVE state.

AS-PENDING Currently Active ASP became inactive or SCTP association
  with it is lost. A Recovery timer will be started and in coming SCN
  messages will be queued by the SG. If an ASP becomes Active before the
  recovery timer expires, AS will move to AS-ACTIVE state and all the
  queued messages will be sent to the active ASP. If the recovery timer
  expires before an ASP becomes active, SG stops queuing messages and
  discards all queued messages. AS will move to AS-UP if at least one
  ASP is in ASP-UP state, otherwise it will move to AS-DOWN state.

Ed's Note:  If AS moves from AS-PENDING state to AS-UP or AS-DOWN
states, the Layer Management on MG may take appropriate SCN
notification actions.

                 Figure 5 AS State Transition Diagram

      +----------+  one ASP trans ACTIVE   +-------------+
      |          |------------------------>|             |      
      |  AS-UP   |                         |  AS-ACTIVE  |
      |          |                         |             |
      |          |<                       -|             |
      +----------+ \                     / +-------------+
         ^   |      \ Tr Trigger        /       ^    |
         |   |       \ at least one    /        |    |
         |   |        \ ASP in UP     /         |    |
         |   |         \             /          |    |
         |   |          \           /           |    |
         |   |           \     /---/            |    |
 one ASP |   |            \   /         one ASP |    | ACTIVE ASP
 trans   |   | all ASP     \-/----\     trans   |    | trans to UP or  
 to UP   |   | trans to     /      \    ACTIVE  |    | ACTIVE ASP
         |   | DOWN        /        \           |    | SCTP CDI
         |   |            /          \          |    |
         |   |           /            \         |    |
         |   |          /all ASP       \        |    |
         |   v         / trans to       \       |    v         
      +----------+    /  DOWN            \ +-------------+
      |          |<--/                    -|             |      
      | AS-DOWN  |                         | AS-PENDING  |
      |          |                         |  (queueing) |
      |          |<------------------------|             |
      +----------+    Tr Trigger no ASP    +-------------+
                       in UP state or
                     prev ACTIVE ASP trans
                        to DOWN state    

Tr = Recovery Timer Trigger

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 16]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

3.3.2 ASP procedures for primitives

3.3.2.1 MGC Procedures

When the IUA layer on a MGC receives M-SCTP ESTABLISH primitive, the
IUA layer will try to establish an SCTP association with the SG. Or
alternatively, if SG establishes the SCTP association first, the IUA
layer will receive a SCTP Communication Up indication. The IUA layer
will invoke the primitive M-SCTP ESTABLISH (confirm or indication) to
the layer management. The IUA layer will then find out the state of
its user from the Layer Management using the primitive M-ASP STATUS.
The IUA layer will convey the status of the Q.931 layer to its peer
IUA layer using the ASP (Up/Down/Active/Inactive) message. The IUA
layer on MGC will eventually receive the acknowledgement of the ASP
message from its peer IUA layer on SG, which it notifies to the Layer
Management.

If the IUA layer receives a SCTP-Communication Down indication from
the underlying SCTP layer, it will inform the Layer Management by
invoking the M-SCTP STATUS primitive. The Layer Management may try to
reestablish the SCTP association using M-SCTP ESTABLISH primitive.

3.3.2.2 SG Procedures

The SG MUST receive Establish message from the IUA layer on the MGC,
before it will try to establish the data link on the signalling
channel or respond to the Q.921 peer entity requesting establishment
of a data link on the signalling channel.

Ed's Note Procedures to prevent Q.921 from establishing a data link
on the signalling channel (in response to peer requests) are still
under investigation.

When the IUA layer on a SG receives M-SCTP ESTABLISH primitive, the
IUA layer will try to establish an SCTP association with the MGC. Or
alternatively, if MGC establishes the SCTP association first, the IUA
layer will receive a SCTP Communication Up indication. The IUA layer
will invoke the primitive M-SCTP ESTABLISH (confirm or indication) to
the layer management and change the state of that ASP to ASP-UP. If AS
is in state AS-DOWN, it will move to AS-UP state.

If the IUA layer receives a SCTP-Communication Down indication from
the underlying SCTP layer, it will inform the Layer Management by
invoking the M-SCTP STATUS primitive and change the state of that ASP
to ASP-DOWN. If the AS is in state AS-UP and this ASP is the only one
UP at that time, the AS state will move to AS-DOWN. If the AS is in
state AS-ACTIVE and the ASP that moved to ASP-DOWN state is the active
ASP, then AS will move to AS-PENDING state. The IUA layer on SG shall
start the recovery timer and follow procedures described for
AS-PENDING state in section 3.3.1.2. The IUA layer may optionally send
ASP Down messages to all ASPs in the UP state to inform the failure of
the primary ASP. The Layer Management may try to reestablish the SCTP
association using M-SCTP ESTABLISH primitive on receiving the M-SCTP
STATUS primitive from IUA. If the SCTP association(s) comes up the SG
should wait for MGC to send ESTABLISH message before initiating
procedures for establishing the Q.921 data link(s).

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 17]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

3.3.3 ASP procedures for peer-to-peer messages

3.3.3.1 MGC procedures

On receiving ASP Down message from the IUA layer on SG, the IUA layer
on MGC learns that the primary ASP is down for that SG. So, the IUA
layer invokes the primitive M-ASP STATUS to the layer management. The
Layer Management may choose to become the active ASP, in which case it
will invoke the primitive M-ASP STATUS (with status equal to
"ACTIVE"). The IUA layer will then inform the peer IUA layer on SG
that it will be taking over using the ASP Active message.

3.3.3.2 SG procedures

On receiving any ASP message from the IUA layer on the MGC, the IUA
layer on SG MUST respond with the same ASP message to acknowledge it.

Reception of the ASP Down message from the peer shall be treated
similar to reception of SCTP-Communication Down indication from the
lower layer (section 3.3.2.2).

On receiving ASP Up message, it should mark the state of that ASP as
ASP-UP and inform the status of the ASP to Layer Management using the
M-ASP STATUS primitive. The state transition of the ASP to ASP-UP will
result in AS state transition to AS-UP, only if the AS was in the
AS-DOWN state.

On receiving the ASP Active message the IUA layer shall change the
state of that ASP to ASP-ACTIVE if the earlier state is ASP-UP. The
IUA layer shall inform the Layer Management of the new status of the
ASP. The state of AS will move to AS-ACTIVE.

On receiving the ASP Inactive message, the IUA layer should change the
state to UP, if the earlier state is ASP-ACTIVE, and inform Layer
Management. The state of the AS shall be changed to AS-PENDING and IUA
shall follow the procedures described for this scenario in section
3.3.2.2.

4. Examples

4.1 Establishment of associations between SG and MGC examples

An example of the message flows for establishing active associations
between SG and MGC is shown below.

                  SG                  ASP1
        
                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 18]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

An example of message flows for establishment of associations with two
ASPs and the message flows for take-over of the primary (ASP1) by the
secondary (ASP2).

                 SG                    ASP1               ASP2

                        <----------- ASP Up
                  ASP Up ---------->
                  (ACK)
                        <------------------------------ ASP Up
                  ASP Up ------------------------------>
                  (ACK)
                        <----------- ASP Active
              ASP Active ---------->
              (ACK)
                              ...
        
                        <----------- ASP Inactive
            ASP Inactive ---------->
            (ACK)

                         (this message is optional)
            ASP Inactive ------------------------------>
                        <------------------------------ ASP Active
              ASP Active ------------------------------>
              (ACK)

4.2 Q.921/Q.931 primitives backhaul Examples

An example of the message flows for establishing a data link on a
signalling channel, passing PDUs and releasing a data link on a
signalling channel is shown below. An active association between MGC
and SG is established (section 4.1) prior to the following message
flows.

            SG                             MGC

                        <----------- Establish Request
      Establish Response ---------->

                        <----------- Data Request
         Data Indication ----------->
                        <----------- Data Request
         Data Indication ----------->
                        <----------- Data Request
                        <----------- Data Request
         Data Indication ----------->

                        <----------- Release Request (RELEASE_MGMT)
        Release Confirm  ---------->

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 19]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

An example of the message flows for a failed attempt to establish a
data link on the signalling channel is shown below.  In this case, the
gateway has a problem with its physical connection (e.g. Red Alarm),
so it cannot establish a data link on the signalling channel.

            SG                             MGC
        
                        <----------- Establish Request (ESTABLISH_START)
      Release Indication ---------->
      (RELEASE_PHYS)

4.3 Layer Management Communication Examples

An example of the message flows for communication between Layer
Management modules between SG and MGC is shown below. An active
association between MGC and SG is established (section 4.1) prior to
the following message flows.

                  SG                       MGC
        
                        <----------- Data Request
                   Error ---------->
                   (INVALID_TEI)

                        <----------- TEI Status 
              TEI Status ---------->

5.0  Security

SCN adaptation layers rely on SCTP to provide security.
 
6.0  Acknowledgements

The authors would like to thank Ming-te Chao, Keith Drage, and many
others for their valuable comments and suggestions.

7.0  References

[1] ITU-T Recommendation Q.920, 'Digital Subscriber Signalling 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] Simple Control Transmission Protocol,
    draft-ietf-sigtran-sctp-00.txt, Octtember 1999

[4] Media Gateway Control Protocol (MGCP),
    draft-huitema-megaco-mgcp-v1-03.txt, August 1999

Kalla, Rengasami, Morneault, & Sidebottom                    [Page 20]

Internet Draft        ISDN Q.921 User Adaptation Layer        Oct 1999

[5] Framework Architecture for Signaling Transport,
    draft-ietf-sigtran-framework-arch-03.txt, June 1999

8.0 Author's Addresses

Malleswar Kalla                                   Tel +1-973-829-5212
Telcordia Technologies             EMail kalla@research.telcordia.com
MCC 1J211R
445 South Street
Morristown, NJ 07960
USA

Selvam Rengasami                                  Tel +1-732-758-5260
Telcordia Technologies                   EMail srengasa@telcordia.com
NVC-2Z439
331 Newman Springs Rd
Red Bank, NJ 07701
USA

Ken Morneault                                     Tel +1-703-484-3323
Cisco Systems Inc.                           EMail kmorneau@cisco.com
13615 Dulles Technology Drive
Herndon, VA. 20171
USA

Greg Sidebottom                                   Tel +1-613-763-7305
Nortel Networks                     EMail gregside@nortelnetworks.com
3685 Richmond Rd,
Nepean, Ontario 
Canada  K2H5B7



Last modified: Thu, 13 Nov 2014 04:31:52 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.