| draft-ietf-sigtran-iua-01 Description: Request For Comments
You can download source copies of the file as follows:
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
|
Documentation