draft-ietf-sigtran-m3ua-00.txt   draft-ietf-sigtran-m3ua-01.txt 
skipping to change at line 12 skipping to change at page 1, line 13
INTERNET-DRAFT Nortel Networks INTERNET-DRAFT Nortel Networks
Ian Rytina Ian Rytina
Ericsson Ericsson
Hanns-Juergen Schwarzbauer Hanns-Juergen Schwarzbauer
Siemens Siemens
Ken Morneault Ken Morneault
Cisco Cisco
Mallesh Kalla Mallesh Kalla
Telcordia Telcordia
Expires in six months 8 October 1999 Expires in six months 15 February 2000
SS7 MTP3-User Adaptation Layer (M3UA) SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-00.txt> <draft-ietf-sigtran-m3ua-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at line 44 skipping to change at page 1, line 45
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This Internet Draft defines a protocol for transport of SS7 MTP3-User This Internet Draft defines a protocol for the transport of any SS7
signaling (e.g., ISUP and SCCP messages) over IP using the Simple MTP3-User signaling (e.g., ISUP and SCCP messages) over IP using the
Control Transport Protocol. Also, provision is made for protocol Simple Control Transport Protocol. Also, provision is made for
elements that enable a seamless, or as seamless as possible, operation protocol elements that enable a seamless operation of the MTP3-User
of the MTP3-User peers in the SS7 and IP domains. This protocol would peers in the SS7 and IP domains. This protocol would be used between a
be used between a Signaling Gateway (SG) and a Media Gateway Controller Signaling Gateway (SG) and a Media Gateway Controller (MGC) or IP-
(MGC) or IP-resident database but could also be used between two SGs resident Database. It is assumed that the SG receives SS7 signaling
if desired. It is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Message Transfer Part (MTP)
over a standard SS7 interface using the SS7 Message Transfer Part to provide transport.
(MTP) to provide transport.
NOTE: THIS DRAFT REPLACES <draft-ietf-sigtran-itun-00.txt>
1
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction..............................................3 1. Introduction..............................................3
2. Protocol Elements........................................11 2. Protocol Elements........................................11
3. Procedures...............................................21 3. Procedures...............................................21
4. Examples.................................................26 4. Examples.................................................26
5. Security.................................................27 5. Security.................................................27
6. Acknowledgements.........................................27 6. Acknowledgements.........................................27
7. References...............................................27 7. References...............................................27
8. Author's Addresses.......................................28 8. Author's Addresses.......................................28
2
1. Introduction 1. Introduction
1.1 Scope 1.1 Scope
There is a need for SCN signaling protocol delivery from an SS7 There is a need for SCN signaling protocol delivery from an SS7
Signaling Gateway (SG) to a Media Gateway Controller (MGC). The Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP-
delivery mechanism should meet the following criteria: resident Database as described in the Framework Architecture for
Signalling Transport [1]. The delivery mechanism should meet the
following criteria:
* Support for transfer of SS7 MTP3-User Part messages (e.g., ISUP, * Support for transfer of all SS7 MTP3-User Part messages (e.g., ISUP,
SCCP, TUP, etc.) SCCP, TUP, etc.)
* Support for the seamless operation of MTP3-User peers * Support for the seamless operation of MTP3-User protocol peers
* Support for the management of SCTP * Support for the management of SCTP transport associations and
transport associations between an SG and an MGC or IP Database) traffic between an SG and one or more MGCs or IP-resident Databases
* Support for MGC or IP-resident Database failover and loadsharing
* Support for the asynchronous reporting of status changes to * Support for the asynchronous reporting of status changes to
management management
In other words, the SG will terminate SS7 MTP2 and MTP3 protocols and In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols
deliver ISUP, SCCP and/or any other MTP3-User protocols to IP-resident and deliver ISUP, SCCP and/or any other MTP3-User protocol messages
Application Server Processes over an SCTP transport association over SCTP transport associations to MTP3-User peers in MGCs or IP-
resident Databases.
1.2 Terminology 1.2 Terminology
Application Node (AN) - A physical node in an IP network (i.e., an MGCU
or Database node), with one or more unique IP network addresses. An AN
supports one or more SCTP end-points and one or more Application Server
Processes.
Application Server (AS) - A logical entity serving a specific Application Server (AS) - A logical entity serving a specific
application instance. An example of an Application Server is a virtual application instance. An example of an Application Server is a virtual
switch handling all call processing for a particular SS7 switch element handling all call processing for a unique range of PSTN
OPC/DPC/CIC_range. Practically speaking, an AS is modeled at the SG as trunks, identified by an SS7 DPC/OPC/CIC_range. Practically speaking,
an ordered list of one or more related Application Server Processes an AS is modeled at the SG as an ordered list of one or more unique
(e.g., primary, secondary, tertiary, ...). Application Server Processes, of which one or more is normally actively
processing traffic.
Application Server Process (ASP) - A process instance of an Application Application Server Process (ASP) - A process instance of an Application
Server. Examples of Application Server Processes are primary or backup Server. An Application Server Process serves as an active or standby
MGC instances. process of an Application Server (e.g., part of a distributed virtual
switch or database element).
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
Application Server Cluster (ASC) - A group of one or more Application
Servers represented to the SS7 network by the same SS7 Point Code. An
SG cannot send MTP Level 3 management messages relating to the
availability/congestion status of an SS7 destination in the IP domain
unless the status is true across all members of the Application Server
Cluster.
Association - An association refers to an SCTP association. The Association - An association refers to an SCTP association. The
association will provide the transport for the delivery of MTP3-User association provides the transport for the delivery of MTP3-User
protocol data units and M3UA adaptation layer peer messages. protocol data units and M3UA adaptation layer peer messages.
Fail-over - The capability to re-route signaling traffic as required to Fail-over - The capability to re-route signaling traffic as required to
a next-preferred Application Server Process within an Application an alternate Application Server Process, or group of ASPs, within an
Server in the event of failure or unavailability of the currently used
3 Application Server in the event of failure or unavailability of a
currently used Application Server Process. Fail-back may apply upon
the return to service of a previously unavailable Application Server
Process.
Application Server Process (e.g., from primary MGC to back-up MGC). IP Database - The IP-resident analogue of a PSTN Service Control Point
Fail-over may also apply upon the return to service of a previously (SCP) or wireless Home Location Register (HLR).
unavailable Application Server Process.
MTP3 Management Cluster (MMC) - A group of one or more Application
Servers represented to the SS7 network under the same SS7 Destination
Point Code. MMCs are used to sum the availability/congestion status of
an SS7 destination that is distributed in the IP domain, for the
purpose of supporting MTP Level 3 management procedures.
MTP3-User - Any protocol normally using the services of the SS7 MTP3 MTP3-User - Any protocol normally using the services of the SS7 MTP3
(e.g., ISUP, SCCP, TUP, etc.). (e.g., ISUP, SCCP, TUP, etc.).
Network Appearance - The Network Appearance identifies the SS7 network
context for the purposes of logically separating the signaling traffic
between the SG and the Application Server Processes over common SCTP
Associations. An example is where an SG is logically partitioned to
appear as an element in four separate SS7 national networks. A Network
Appearance uniquely defines the SS7 Destination Point Code, Network
Indicator and MTP3 protocol type/variant/version used within each
network. An SS7 route-set or link-set at an SG can appear in only one
network appearance.
Network Byte Order: Most significant byte first, a.k.a Big Endian.
Routing Context - An Application Server Process may be configured to
process traffic within more than one Application Server. From the
perspective of an ASP, a Routing Context defines a range of signaling
traffic that the ASP is currently configured to receive from the SG.
For example, an ASP could be configured to support call processing for
multiple ranges of PSTN trunks and therefore receive related signaling
traffic, identified by separate SS7 DPC/OPC/CIC_ranges.
Stream - A stream refers to an SCTP stream. Stream - A stream refers to an SCTP stream.
1.3 Signaling Transport Architecture 1.3 Signaling Transport Architecture
The architecture that has been defined for SCN signaling transport 1.3.1 Protocol Architecture.
over IP uses multiple components, including an IP transport
protocol, a signaling common transport protocol and an adaptation
module to support the services expected by a particular SCN signaling
protocol from its underlying protocol layer.
In reference to the SIGTRAN framework architecture [xx], This document The framework architecture that has been defined for SCN signaling
defines an MTP3-User adaptation module that is suitable for the transport over IP [1] uses multiple components, including a signaling
transport of SS7 ISDN User Part (ISUP) and Signalling Connection common transport protocol and an adaptation module to support the
Control Part (SCCP) messages but could be used equally to transport services expected by a particular SCN signaling protocol from its
other SS7 MTP3-User Part messages such as, for example, TUP. Note: underlying protocol layer.
SCCP-Users (e.g., INAP/TC or ISUP) are supported implicitly as SCCP
payload. Within the framework architecture, this document defines an MTP3-User
adaptation module that is suitable for the transport of SS7 ISDN User
Part (ISUP) [2,3,4] and Signalling Connection Control Part (SCCP)
[5,6,7] messages but could be equally used to transport other SS7 MTP3-
User Part messages such as, for example, the Telephone User Part (TUP)
[8]. TCAP [9,10,11] or RANAP [12] messages are transported
transparently by the M3UA as SCCP payload, as they are SCCP-User
protocols. The M3UA uses the services of the Simple Common Transport
protocol [13] as the underlying reliable signaling common transport
protocol.
In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling In a Signaling Gateway, it is expected that the SS7 ISUP/SCCP signaling
is transmitted and received over a standard SS7 network interface, is transmitted and received from the PSTN over a standard SS7 network
using the SS7 Message Transfer Part (MTP) to provide transport of interface, using the SS7 Message Transfer Part (MTP) [14,15,16] to
ISUP/SCCP signaling messages to and from an SS7 Signaling End Point provide reliable transport of the ISUP/SCCP signaling messages to and
(SEP) or Signaling Transfer Point (STP). The SG then provides from an SS7 Signaling End Point (SEP) or Signaling Transfer Point
interworking of transport functions with IP Signaling Transport, in (STP). The SG then provides a functional inter-working of transport
order to transfer the ISUP/SCCP signaling messages to and from the ASP functions with the IP transport, in order to transfer the ISUP/SCCP
where the peer ISUP/SCCP protocol layer exists. Three general cases signaling messages to and from an Application Server Process where the
are shown below to cover the routing options in the event of ISUP or peer ISUP/SCCP protocol layer exists.
SCCP transport across the SG as shown below:
1.3.1 Case 1: ISUP transport The use of standard MTP Level 2 signaling links in the SS7 network
interface is not the only possibility. ATM-based High Speed Links
could also be used, using the services of the Signaling ATM Adaptation
Layer (SAAL) [17,18]. For that matter, it is possible that IP-based
links could be present, using the services of the MTP2-User Adaptation
Layer (M2UA) [19]. Also note that STPs may be present in the SS7 path
between the SS7 SEP and the SG.
****** SS7 ****** IP ****** Where ATM-base High Speed Links are used in the SS7 network, it is
*SEP *-----------* SG *-----------*ASP * possible for the SG to use the services of the MTP-3b [20] for reliable
****** ****** ****** transport to and from an SS7 SEP or STP. The maximum Service Data Unit
(SDU) supported by the MTP-3b is 4096 octets compared to the 272 octet
maximum of the MTP. However, for MTP3-Users to take advantage of the
larger SDU between MTP3-User peers, network architects should ensure
that MTP3-b is used end-to-end between the SG and the SS7-resident
peer.
+----+ +----+ Three example cases are shown below:
|ISUP| |ISUP|
+----+ +---------+ +----+
|MTP | |MTP |M3UA| |M3UA|
|L3 | |L3 +----+ +----+
|L2 | |L2 |SCTP| |SCTP|
|L1 | |L1 +----+ +----+
| | | |UDP | |UDP |
+----+ +---------+ +----+
SEP - SS7 Signaling End Point 1.3.1.1 Example 1: ISUP transport
SCTP - Simple Control Transport Protocol [5] ******** SS7 ***************** IP ********
* SEP *---------* SG *--------* ASP *
******** ***************** ********
4 +------+ +------+
| ISUP | | ISUP |
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | UDP | | UDP |
+------+ +------+ +------+ +------+
|_______________| |______________|
Note: The use of MTP Level 2 signaling links in the SS7 network is SEP - SS7 Signaling End Point
shown as an example. ATM-based High Speed Links could also be used, SCTP - Simple Control Transport Protocol
using MTP3/SSCF/SSCOP [3,4]. For that matter, it is possible that IP-
based links could present, using MTP3/M2UA/SCTP. Also, STPs may be
present in the SS7 path between the SEP and the SG.
To enable a seamless, or as seamless as possible, operation of the Within the SG, MTP-TRANSFER indication primitives received from the MTP
MTP3-User peers in the SS7 and IP domains, the SG implements for Level 3 upper layer interface are sent to the local M3UA-resident
modeling purposes a nodal interworking function. The interworking
function purpose is to deliver MTP-TRANSFER indication primitives
received from the MTP Level 3 upper layer interface to an M3UA-resident
network address translation and mapping function for ongoing routing to network address translation and mapping function for ongoing routing to
the final IP destination. This internal SG function also delivers MTP- the final IP destination. MTP-TRANSFER primitives received from the
TRANSFER request primitives to the MTP Level 3 upper layer interface local M3UA network address translation and mapping function are sent to
from the M3UA network address translation and mapping function for the MTP Level 3 upper layer interface as MTP-TRANSFER request
ongoing MTP Level 3 routing to the SS7 node. This nodal interworking primitives for on-going MTP Level 3 routing to an SS7 SEP.
function is described for modeling purposes only - it is a nodal
implementation-dependent function that does not affect the peer
protocol exchanges.
1.3.2 Case 2: SCCP transport where an SCCP function at the SG is For internal SG modelling purposes, this may be accomplished with the
use of an implementation-dependent nodal inter-working function within
the SG that serves as a local user of the MTP3 and M3UA. This nodal
inter-working function has no visible peer protocol with either the ASP
or SEP.
1.3.1.2 Example 2: SCCP transport where an SCCP function at the SG is
invoked: invoked:
****** SS7 ****** IP ******* ******** SS7 ***************** IP ********
*SEP *-----------* SG *------------* ASP * * SEP *---------* *--------* *
* or * * * * * * or * * SG * * ASP *
*STP * * * * * *STP * * * * *
****** ****** ******* ******** ***************** ********
+----+ +---------+ +-----+ +------+ +---------------+ +------+
|SCCP| | SCCP | |SCCP | |SCCP| | SCCP | |SCCP |
+----+ +---------+ +-----+ +------+ +------+-+------+ +------+
|MTP | |MTP |M3UA| |M3UA | | MTP3 | | MTP3 | | M3UA | | M3UA |
|L3 | |L3 +----+ +-----+ +------| +------+ +------+ +------+
|L2 | |L2 |SCTP| |SCTP | | MTP2 | | MTP2 | | SCTP | | SCTP |
|L1 | |L1 +----+ +-----+ +------+ +------+ +------+ +------+
| | | |UDP | | UDP | | L1 | | L1 | | UDP | | UDP |
+----+ +---------+ +-----+ +------+ +------+ +------+ +------+
|_______________| |______________|
Note: An SEP can be an SCP or SSP STP - SS7 Signaling Transfer Point
In this case, the SCCP at the SG performs Global Title Translation In this example, the SG contains an instance of the SS7 SCCP protocol
(GTT) for messages in either direction that do not yet have a final SS7 layer that may, for example, perform the SCCP Global Title Translation
MTP Destination Point Code address (and possibly SCCP Subsystem). Use (GTT) function for messages logically addressed to the SG SCCP. If the
of the SCCP at the SG will avoid a requirement for a GTT function result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN
within the M3UA protocol. The SG nodal interworking function delivers address result of an SCCP peer located in the IP domain, the resulting
an MTP-TRANSFER indication primitive incoming from the SS7 network to MTP-TRANSFER request primitive is sent to the local M3UA-resident
network address translation and mapping function for ongoing routing to
the final IP destination.
5 Similarly, the SCCP instance in an SG can perform the SCCP GTT service
for messages logically addressed to it from SCCP peers in the IP
domain. In this case, MTP-TRANSFER messages are sent from the local
M3UA-resident network address translation and mapping function to the
SCCP for GTT. If the result of the GTT yields the address of an SCCP
peer in the SS7 network then the resulting MTP-TRANSFER request is
given to the MTP3 for delivery to an SS7-resident node.
an M3UA-resident network address translation and mapping function for It is possible that the above SCCP GTT at the SG could yield the
ongoing routing to the final IP destination, but only after the SCCP address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER
GTT has been performed and a new Destination Point Code (and possibly primitive would be sent back to the M3UA for delivery to an IP
Subsystem) have been determined. The M3UA network address translation destination.
and mapping function then determines the final IP destination. It is
possible that the SCCP GTT result could be a non-final GTT result and
M3UA would then actually be determining an IP destination that will
perform the next GTT.
Similarly messages from the IP network can be addressed to the SG for For internal SG modelling purposes, this may be accomplished with the
SCCP GTT. The SG nodal interworking function would deliver these MTP- use of an implementation-dependent nodal inter-working function within
TRANSFER request primitives to the SCCP from M3UA. The SCCP GTT will the SG that effectively sits below the SCCP and routes MTP-TRANSFER
then determine an SS7 Destination Point Code (and possibly Subsystem) messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or
before delivery into the SS7 network. It is possible that after SCCP DPC/SSN address information. This nodal inter-working function has no
GTT the DPC (and possibly Subsystem) result could represent an IP-based visible peer protocol with either the ASP or SEP.
ASP and be sent by the nodal interworking function back to the M3UA-
resident network address translation and mapping function for ongoing
routing to an IP destination.
1.3.3 Case 3: SCCP transport where an SCCP function at the SG is not Note that the services and interface provided by M3UA are the same as
invoked: in Example 1 and the functions taking place in the SCCP entity are
transparent to M3UA. The SCCP protocol functions are not reproduced in
the M3UA protocol.
****** SS7 ****** IP ******* 1.3.1.3 Example 3 - Seamless Handling of MTP3 Management
*SEP *-----------* SG *------------* ASP *
* or * * * * * ******** SS7 ***************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
*STP * * * * * *STP * * * * *
****** ****** ******* ******** ***************** ********
+----+ +-----+ +------+ +------+-+------+ +------+
|SCCP| |SCCP | | MTP3 | | MTP3 | | M3UA | | M3UA |
+----+ +---------+ +-----+ +------| +------+ +------+ +------+
|MTP | |MTP |M3UA| |M3UA | | MTP2 | | MTP2 | | SCTP | | SCTP |
|L3 | |L3 +----+ +-----+ +------+ +------+ +------+ +------+
|L2 | |L2 |SCTP| |SCTP | | L1 | | L1 | | UDP | | UDP |
|L1 | |L1 +----+ +-----+ +------+ +------+ +------+ +------+
| | | |UDP | | UDP | |_______________| |______________|
+----+ +---------+ +-----+
For this case, the SG nodal interworking function operates as in Case In the case of SS7 MTP3 network management, it is required that the
1. MTP3-User protocols at ASPs receive indications of SS7 signaling point
availability, SS7 network congestion and User Part availability as
would be expected an SS7 SEP node. To accomplish this, the MTP-PAUSE,
MTP-RESUME and MTP-STATUS indication primitives received at the MTP3
upper layer interface at the SG need to be made available to the remote
MTP3-User lower layer interface at the AN. Note: These indication
primitives are also made available to any existing local MTP3-Users at
the SG, such as the SCCP in the previous example.
1.3.4 UDP Port For internal SG modelling purposes, this may be accomplished with the
use of an implementation-dependent nodal inter-working function within
the SG that effectively sits above the MTP3 and delivers MTP-PAUSE,
MTP-RESUME and MTP-STATUS indication primitives received from the MTP
Level 3 upper layer interface to the local M3UA-resident management
function. This nodal inter-working function has no visible peer
protocol with either the ASP or SEP.
A request will be made to IANA to assign a UDP port for M3UA. It is important to clarify that MTP3 management messages such as TFPs
or TFAs received from the SS7 network are not "encapsulated" and sent
blindly to the ASPs. Rather, the existing MTP3 management procedures
are followed within the MTP3 function of the SG to re-calculate the
MTP3 route set status and initiate any signaling-route-set-test
procedures into the SS7 network. Only when a route set status changes
are MTP-PAUSE or MTP-RESUME primitives invoked. These primitives can
also be invoked due to local SS7 link set conditions as per existing
MTP3 procedures.
1.3.2 Signaling Network Architecture
A Signaling Gateway is used to support the transport of ISUP/SCCP
signaling traffic received from the SS7 network to multiple distributed
Application Nodes (e.g., MGCUs and IP Databases). Clearly, an SG-ASP
protocol description cannot in itself meet any performance and
reliability requirements for such transport. A physical network
architecture is required, with data on the availability and transfer
performance of the physical nodes involved in any particular exchange
of information. The protocol used must simply be flexible enough allow
its operation and management in a variety of physical configurations
that will enable Network Operators to meet their performance and
reliability requirements.
To meet the stringent SS7 signaling reliability and performance
requirements for carrier grade networks, these Network Operators should
ensure that there is no single point of failure provisioned in the end-
to-end network architecture between an SS7 SEP and an IP Application
Node. Depending of course on the reliability of the SG and AN
functional elements, this can typically be met by the use of redundant
SGs, the provision of redundant QOS-bounded IP network paths for SCTP
Associations between SCTP End Points, and redundant Application Nodes.
The distribution of ASPs within the available Application Nodes is also
important. For a particular Application Server, the related ASPs
should be distributed over at least two physical Application Nodes.
An example physical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 1 below:
******** **************
* *__________________________________________* ******** * AN1
* * * * ASP1 * *
* SG1 * SCTP Associations * ******** *
* *_______________________ * ******** *
* * | * * ASP2 * *
* * | * ******** *
* * | * ******** *
* * | * * ASP3 * *
******** | * ******** *
| * . *
******** | * . *
* *------------------------------------------* *
* * | * ******** *
* SG2 * SCTP Associations | * * ASPn * *
* *____________ | * ******** *
* * | | **************
* * | | **************
* * | |__________________* ******** * AN2
* * | * * ASP1 * *
******** | * ******** *
|_____________________________* ******** *
* * ASP2 * *
* ******** *
* ******** *
* * ASP3 * *
* ******** *
* . *
* . *
* *
* ******** *
* * ASPn * *
* ******** *
**************
.
.
.
Figure 1 - Physical Model
For carrier grade networks, Operators should ensure that under failure
or isolation of a particular AN, stable calls or transactions are not
lost. This implies that Application Nodes need, in some cases, to
share the call/transaction state or be able to pass the
call/transaction state between each other. Also, in the case of MGC
Application Nodes, coordination may be required with the related Media
Gateway to transfer the MGC control for a particular trunk termination.
However, this sharing or communication is outside the scope of this
document.
1.3.3 SS7 Point Code Representation
A Signaling Gateway is charged with representing the IP network nodes
into the SS7 network for routing purposes. The SG itself, as a
physical node in the SS7 network, must be addressable with an SS7
Destination Point Code for MTP3 Management purposes. This DPC will
also be used to address any local MTP3-Users such as an SG-resident
SCCP function. An SG may also be addressable with multiple DPCs where
the SG is logically partitioned to operate in multiple SS7 network
appearances. Alias DPCs may also be used within an SG or an SG network
appearance, but SG MTP3 management messages to/from the SS7 network
will not use the alias DPCs.
The M3UA places no restrictions on the SS7 Destination Point Code (DPC)
representation of any of the ASPs. ASPs can be represented under the
same DPC of the SG, their own individual Destination Point Codes (DPCs)
or grouped with other ASPs for Point Code preservation purposes. A
single DPC may be used for the SG and all the ASPs together, if
desired. Note: there are potential SS7 traffic engineering
restrictions in some arrangements as there is a maximum number of SS7
links within a unique link-set to an adjacent SS7 node.
If an ASP or group of ASPs is available to the SS7 network via more
than one SG, it is recommended that the ASP(s) be represented by a
Destination Point Code that is separate from any SG DPC. This allows
some SGs to be viewed from the SS7 network as "STPs", each having a
"route" to the same ASP. Under failure conditions where an ASP becomes
unavailable from one of the SGs, this approach enables MTP3 route
management messaging between the SG and SS7 network, allowing simple
re-routing through an alternate SG.
1.3.4 ASP Fail-over Model and Terminology
The network address translation and mapping function of the M3UA
supports ASP fail-over functions in order to support a high
availability of call and transaction processing capability. All
ISUP/SCCP messages incoming to an SG from the SS7 network are assigned
to a unique Application Server, based on the information in the
message. The information examined may be one or more of the MTP DPC,
OPC, SLS, or any MTP3-User specific fields such as, for example, the
ISUP CIC, SCCP SSN, or TCAP TRID. Some example possibilities are the
DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
DPC/SSN combination. The information used to point to an AS is not
limited by the M3UA and none of the examples are mandated.
The Application Server is in practical terms an ordered list of all
ASPs configured/registered to process ISUP/SCCP messages within a
certain range of routing information, known as a Routing Key. One or
more ASPs in the list are normally handling traffic while any others
are inactive but available in the event of failure or unavailability of
the active ASP(s).
The fail-over model supports an "n+k" redundancy model, where "n" ASPs
is the minimum number of redundant ASPs required to handle traffic and
"k" ASPs are available to take over for a failed or unavailable ASP.
Note that "1+1" active/standby redundancy is a subset of this model. A
simplex "1+0" model is also supported as a subset, with no ASP
redundancy.
To avoid a single point of failure, it is recommended that a minimum of
two ASPs be resident in the list, resident in separate physical
Application Nodes and therefore available over different SCTP
Associations. For example, in the network shown in Figure 1, all
messages to DPC x could be sent to ASP1 in AN1 or ASP1 in AN2. The AS
ordered list at SG1 would look like this:
Application Server 1 - Routing Key {DPC=x)
ASP1/AN1 - Up, Active
ASP1/AN2 - Up, Inactive
In this "1+1" redundancy case, ASP1 in AN1 would be sent any incoming
message with DPC=x. ASP1 in AN2 could be brought to the active state
upon failure of, or loss of connectivity to, ASP1/AN1. Both ASPs are
Up, meaning that the related SCTP association and far-end M3UA peer is
ready.
In the process of fail-over or fail-back, it is recommended that in the
case of MGCs, stable calls do not fail. It is possible that calls in
"transition" may fail, although measures of communication between the
MGCs involved may mitigate this. For example, the two MGCs may share
call state via shared memory, or may use an MGC-MGC protocol to pass
call state information.
1.3.5 UDP Port
A request will be made to IANA to assign a well-known UDP port for
M3UA.
1.4 Services Provided by the M3UA Layer 1.4 Services Provided by the M3UA Layer
1.4.1 Support for the transport of MTP3-User/MTP boundary primitives The M3UA Layer at the ASP provides the equivalent set of primitives at
its upper layer to the MTP3-Users as provided by the MTP Level 3 to its
local users at an SS7 SEP. In this way, the ISUP and/or SCCP layer at
an ASP is unaware that the expected MTP3 services are offered remotely
from an MTP3 Layer at an SG and not by a local MTP3 layer. In effect,
6 the M3UA extends access to the MTP3 layer services to a remote ASP -
the M3UA does not itself provide the MTP3 services so does not
duplicate MTP3 procedures.
The SS7 MTP Level 3 upper layer interface is retained at the ASP, so 1.4.1 Support for the transport of MTP3-User Messages
the M3UA protocol layer is required to provide the equivalent set of
services to its users as provided by the MTP Level 3.
This includes the following services: The M3UA provides the transport of MTP-TRANSFER primitives across SCTP
associations between an SG and an ASP. The MTP-TRANSFER primitives are
encoded as ISUP/SCCP messages with attached MTP3 Routing Labels as
described in the message format sections of the SCCP and ISUP
recommendations. In this way, the SCCP and ISUP messages received from
the SS7 network are not re-encoded into a different format for
transport to/from the ASP. As well, all the required MTP3 Routing Label
information (OPC, DPC, SIO) is available at the ASP as is expected by
the ISUP/SCCP layer. For ISUP messages the CIC is available, in its
native format. The CIC together with the OPC and DPC uniquely identify
all PSTN trunk circuits within a given MTP network instance.
M3UA provides the ability to transfer MTP3-User messages (in this Note that M3UA does not itself impose a 272-octet user information
Case, ISUP/SCCP PDUs) across SCTP associations. Note that M3UA does block limit as specified by the MTP Level 3. Larger information blocks
not itself impose a 256 octet user information block limit as specified can be accommodated directly by M3UA/SCTP without the need for an upper
by the MTP Level 3. Larger blocks can be accommodated directly by layer segmentation/re-assembly procedure such as specified in recent
M3UA/SCTP without the need for an upper layer segmentation/re-assembly SCCP or ISUP versions. However, in the context of an SG, the maximum
procedure such as in the ITU White Book SCCP [6] or ISUP segmentation 272-octet block size must be followed when inter-working to a SS7
procedures. However, in the context of an SG the maximum 256 octet network that does not support the transfer of larger information blocks
block size must be followed when interworking to an SS7 network that to the final destination, as is possible in the Broadband MTP [20].
does not support the transfer of larger blocks to the final This will avoid ISUP or SCCP fragmentation requirements at the SG.
destination. This will avoid ISUP or SCCP fragmentation at the SG. However, if the SS7 network is provisioned to support the Broadband
However,if the SS7 network supports the Broadband MTP [7] the MTP, the information block size limit may be increased past 272 octets.
block size limit can be increased past 256 octets. In the future,
M3UA/SCTP could be specified for use between two IP Nodes directly to
carry larger ISUP+ (BICC) [8] or MAP/TCAP [9] messages.
Provision is made for a seamless, or as seamless as possible, operation 1.4.2 Native Management Functions
of the MTP3-User peers in the SS7 and IP domains. This includes:
- Providing an indication to MTP3-Users at an ASP that a remote The M3UA may provide management of the underlying SCTP transport
MTP3-User peer in the SS7 network is not protocol to ensure that SG-ASP transport is available to the degree
reachable, as expected by all MTP3-User protocols. called for by the MTP3-User signaling applications.
- Providing an indication to MTP-Users at an ASP that a remote MTP3- The M3UA provides the capability to indicate errors associated with
User peer in the SS7 network is now reachable, as expected by all MTP3- received M3UA messages and to notify, as appropriate, local management
User protocols. and/or the remote peer M3UA.
- Providing an indication to MTP3-Users at an ASP that messages to a 1.4.3 Inter-working with MTP3 Network Management Functions
remote MTP3-
User peer in the SS7 network are experiencing SS7 congestion or the
remote MTP3-User peer is unavailable, as expected by all MTP3-User
protocols.
1.4.2 Support for communication between Layer Management Modules on the At the SG, the M3UA must also provide inter-working with MTP3
SG and ASP management functions to support seamless operation of the user SCN
signaling applications in the SS7 and IP domains. This includes:
An M-ERROR primitive is used to indicate an error with a received M3UA - Providing an indication to MTP3-Users at an ASP that a remote
message (e.g., unknown parameter value). destination in the SS7 network is not reachable.
********* - Providing an indication to MTP3-Users at an ASP that a remote
Ed Note: This section is ffs destination in the SS7 network is now reachable.
*********
1.4.3 Support for management of SCTP associations and ASP Paths between - Providing an indication to MTP3-Users at an ASP that messages to a
the SG and ASP remote MTP3-User peer in the SS7 network are experiencing SS7
congestion
The M3UA layer at the SG keeps the state of all configured ASPs. A set - Providing an indication to MTP3-Users at an ASP that a remote MTP3-
User peer is unavailable.
7 The M3UA layer at an ASP may initiate an audit of the availability of
remote SS7 destinations. This information is requested from the M3UA
at the SG.
of primitives between the Layer Management and the M3UA layer are 1.4.4 Support for the management of SCTP associations between the SG
defined below for the layer Management to manage the ASP Paths and the and AN.
traffic between the SG and the ASPs.
The M3UA layer can be instructed by the Layer Management to establish The M3UA layer at the SG maintains the availability state of all
an SCTP association to a peer M3UA node. This can be achieved using configured remote ASPs, in order to manage the SCTP Associations and
the M-SCTP ESTABLISH primitive to request, indicate and confirm the the traffic between the SG and ASPs. As well, the active/inactive
establishment of an SCTP association to a peer M3UA node. state of remote ASPs is also maintained - Active ASPs are those
currently receiving traffic from the SG.
The M3UA layer may also need to inform Layer Management of the status The M3UA layer at either the SG or ASP can be instructed by local
management to establish an SCTP association to a peer M3UA node. This
can be achieved using the M-SCTP ESTABLISH primitive to request,
indicate and confirm the establishment of an SCTP association with a
peer M3UA node.
The M3UA layer may also need to inform local management of the status
of the underlying SCTP associations using the M-SCTP STATUS request and of the underlying SCTP associations using the M-SCTP STATUS request and
indication primitive. For example, the M3UA may inform Layer Management indication primitive. For example, the M3UA may inform local management
of the reason for the release of an SCTP association, determined either of the reason for the release of an SCTP association, determined either
locally within the M3UA layer or by a primitive from the SCTP. locally within the M3UA layer or by a primitive from the SCTP.
Layer Management may inform the M3UA layer of a change in the local Also the M3UA layer may need to inform the local management of the
M3UA User status (e.g., failure, available). Also the M3UA layer may change in availability status of an ASP. This can be achieved using
need to inform the Layer Management of the change in status of an ASP the M-ASP STATUS primitive to change and indicate the status of an ASP.
or ASP Path. This can be achieved using the M-ASP STATUS primitive to
change and indicate the status of an ASP.
*** Ed Note: This will be moved to a procedures section*****
The M3UA layer may be informed of a local M3UA-User failure by means of
an indication from local Layer Management. In response, a peer
protocol is invoked with the remote M3UA layer to stop traffic over the
SCTP association until recovery of the local M3UA-Users. When the
M3UA-User layer recovers, local Layer Management informs the M3UA layer
and a message is sent to the remote M3UA layer indicating traffic can
be restarted over the SCTP association. The M3UA layer maintains
status of the local M3UA-User availability.
***********************************************
1.5 Internal Functions Provided in the M3UA Layer 1.5 Internal Functions Provided in the M3UA Layer
1.5.1 Address Translation and Mapping 1.5.1 Address Translation and Mapping at the SG M3UA
The M3UA layer maps primitives received from the ASP-User lower layer
boundary, or SG nodal interworking function, to the SCTP reliable
transport upper layer boundary and maps signals received from the SCTP
to the ASP MTP3-User lower layer boundary, or SG nodal interworking
function. For example, the MTP-TRANSFER request primitive received
from an MTP3-User is mapped to an SCTP Send primitive and the SCTP
Receive primitive is mapped to an MTP-TRANSFER indication primitive
to the MTP3-User.
To support this mapping, the M3UA layer at the SG must additionally In order to direct messages received from the MTP3 network to the
maintain a network address translation table of incoming SS7 desired IP destination, the SG M3UA must perform address translation
address/routing information keys to Application Servers. The and mapping functions using information from the received ISUP/SCCP
Application Server represents an ordered list of one or more possible message.
Application Server Processes. Normally, one of the ASPs in the ordered
list will be the active ASP for a particular routing key entry. Note
that in certain failure and transition cases it is possible that there
may not be an active ASP.
8 To support this mapping, the SG must maintain a network address
translation table, mapping incoming SS7 information to an ordered list
of an Application Server Processes. Note that in certain failure and
transition cases it is possible that there may not be an active ASP
available.
This table is required in order to route the SS7 ISUP/SCCP messages This table is assumed to be dynamic, taking into account the
incoming from the SS7 network domain to the appropriate ASP in the IP availability status of the individual ASPs in the list, configuration
network domain. This mapping is dynamic, taking into account the changes, and possible fail-over mechanisms. The M3UA protocol includes
availability status of the individual ASP Paths in the list, messages to convey the availability status of the individual ASPs as
configuration changes, and possible fail-over mechanisms. input to a fail-over mechanism.
Possible SS7 address/routing information to be considered as a routing Possible SS7 address/routing information that may comprise a routing
key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or
SCCP Called Party Address. The network address translation function in SCCP Called Party Address. The particular information used in an SG
effect defines the SS7 address representation of the Application M3UA is implementation dependent.
Servers within the IP domain. As such, the implementation of this
function must be flexible enough to handle the SS7 address vision of
network operator(s). For example, some network operators may choose to
represent the SG and Application Servers with a single SS7 point code.
Other operators may choose to represent each SG and Application Server
with individual SS7 point codes, or may group logical groups of
Application Servers under point codes.
From the perspective of the M3UA instance at an Application Server 1.5.2 SG Redundancy
Process, it is possible that the ASP could route signaling messages
destined to the SS7 network through more than one SG. A primary/back-
up case is possible where the unavailability of a the ASP Path to a
primary SG,or the unavailability of the SS7 destination node from the
primary SG, could be used to reroute to a next-preferred SG. Also, a
loadsharing case is possible where the signaling messages are load-
shared across two (or more) SGs.
1.5.2 SCTP Stream Mapping. M3UA also supports the assignment of It is possible that the ASP could route signaling messages destined to
traffic into streams within an SCTP association. Traffic that requires the SS7 network through more than one SG. A primary/back-up case is
sequencing should be assigned to the same stream. For example, SS7 possible where the unavailability of the ASP Path to a primary SG, or
traffic may be assigned to individual streams based on the SLS value in the unavailability of the SS7 destination node from the primary SG,
the MTP3 Routing Label or the ISUP CIC assignment, subject of course to could be used to reroute to a next-preferred SG. Also, a load-sharing
the maximum number of streams supported by the underlying SCTP case is possible where the signaling messages are load-shared across
association. Traffic that does not require sequencing can be assigned two (or more) SGs.
to an unsequenced stream.
1.5.3 Congestion Control. 1.5.3 SCTP Stream Mapping. The M3UA at both the SG and ASP also
supports the assignment of signaling traffic into streams within an
SCTP association. Traffic that requires sequencing must be assigned to
the same stream. To accomplish this, ISUP/SCCP traffic may be assigned
to individual streams based on the SLS value in the MTP3 Routing Label
or the ISUP CIC assignment, subject of course to the maximum number of
streams supported by the underlying SCTP association.
1.5.4 Congestion Control.
The M3UA Layer is informed of local and IP network congestion by means The M3UA Layer is informed of local and IP network congestion by means
of an implementation-dependent function (e.g., an implementation- of an implementation-dependent function (e.g., an implementation-
dependent indication from the SCTP of IP network congestion). When an dependent indication from the SCTP of IP network congestion). When an
SG determines that the transport of SS7 messages to an Application SG determines that the transport of SS7 messages to an MTP3 Management
Server Cluster is encountering congestion, the SG may optionally Cluster is encountering congestion, the SG may optionally trigger SS7
trigger SS7 MTP3 Transfer Controlled management messages to originating MTP3 Transfer Controlled management messages to originating SS7 nodes.
SS7 nodes. The triggering of SS7 MTP3 Management messages from an SG is The triggering of SS7 MTP3 Management messages from an SG is an
an implementation-dependent function. At an ASP, congestion is implementation-dependent function. At an ASP, congestion is indicated
indicated to local MTP3-Users by means of an MTP-Status primitive to local MTP3-Users by means of an MTP-Status primitive indicating
indicating congestion, to invoke appropriate upper layer responses, as congestion, to invoke appropriate upper layer responses, as per current
per current MTP3 procedures. Congestion Control mechanisms are for MTP3 procedures.
further study.
9
1.5.4 Seamless Network Management Interworking.
(Ed. Note: It is ffs if this function is modeled in the M3UA layer at 1.5.5 Seamless Network Management Inter-working.
an SG or is part of an independent relay function at the SG that is a
user of the M3UA layer and MTP-3 layer.)
The SG must maintain knowledge of SS7 node and Application Server The M3UA at an SG must maintain knowledge of SS7 node and MTP3
Cluster status in their respective domains in order to perform as Management Cluster status in their respective domains in order to
seamless as possible interworking of the two domains. For example, SG perform as seamless as possible inter-working of the two domains. For
knowledge of the availability and/or congestion status of Application example, SG M3UA knowledge of the availability and/or congestion status
Server Clusters and SS7 nodes must be maintained and disseminated in of MTP3 Management Cluster and SS7 nodes must be maintained and
the respective networks so that end-to-end operation is transparent to disseminated in the respective networks so that end-to-end operation is
the communicating SCN protocol peers at the SS7 node and ASP.
When an SG determines that the transport of SS7 messages to an transparent to the communicating SCN protocol peers at the SS7 node and
Application Server Cluster is encountering congestion, the SG may ASP.
optionally issue MTP Transfer Controlled (TFC) messages to the SS7 SEPs
which are generating signalling traffic to the affected Application
Server Cluster, as per current MTP procedures [2].
When an SG determines that the transport of SS7 messages to an When an SG M3UA determines that the transport of SS7 messages to an
Application Server Cluster is interrupted, the SG may optionally issue MTP3 Management Cluster is encountering congestion, the SG may
MTP Transfer Prohibited (TFP) messages to the adjacent SS7 nodes which optionally inform the MTP3 route management function (by an
are generating signalling traffic to the affected Application Server implementation-dependent mechanism). This information is used by the
Clusters per current MTP procedures [2]. MTP3 to mark the route to the affected destination as congested and to
trigger MTP Transfer Controlled (TFC) messages to any SS7 SEPs
generating traffic to the congested DPC, as per current MTP3
procedures.
When an SG determines that the transport of SS7 messages to an When an SG M3UA determines that the transport of SS7 messages to all
Application Server Cluster can now be resumed, the SG may optionally ASPs in a particular MTP3 Management Cluster is interrupted, the SG
issue MTP Transfer Allowed (TFA) messages to the adjacent SS7 nodes to M3UA may similarly optionally inform the MTP3 route management
resume signalling traffic to the affected Application Server Clusters function. This information is used by the MTP3 to mark the route to the
per current MTP procedures [2]. affected destination as unavailable and to trigger MTP Transfer
Prohibited (TFP) messages to the adjacent SS7 nodes which are
generating traffic to the unavailable DPC as per current MTP
procedures.
Triggering of the MTP-3 management messages is an implementation When an SG M3UA determines that the transport of SS7 messages to an ASP
dependent function. in a particular MTP3 Management Cluster can be resumed, the SG M3UA may
similarly optionally inform the MTP3 route management function. This
information is used by the MTP3 to mark the route to the affected
destination as available and to trigger MTP Transfer Allowed (TFA)
messages to the adjacent SS7 nodes as per current MTP3 procedures.
1.5.5 Management Inhibit/Uninhibit Note: In some SS7 network architectures, the sending of TFP and TFA
messages from the SG into the SS7 network should be suppressed. For
example, in the case where an SG seen by the adjacent SS7 node as an
SEP (i.e., in ANSI MTP terms they are connected via A-links or F-
links), TFP or TFA messages would not normally be expected by the
adjacent SS7 node.
Local Management may wish to stop traffic across an SCTP association in 1.5.6 Management Inhibit/Uninhibit
order to temporarily remove the association from service or to perform
testing and maintenance activity. The function could optionally be
used to manage the start of traffic on to a newly-available SCTP
association.
1.5.6 Active Association Control Local Management at an ASP or SG 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 optionally be used to control the start of traffic on to a newly-
available SCTP association.
An Application Server Process can have associated back-up process. 1.5.7 Active Association Control
When, for example, both a primary and a back-up ASP are available, then
peer protocol is required to control which ASP,
and hence ASP Path, is currently active. The ordered list of ASPs
related to an Application Server is kept updated to reflect the active
Application Server Process instance.
10 At an SG, an Application Server list may contain active and inactive
ASPs to support ASP loads-haring and fail-over procedures. When, for
example, both a primary and a back-up ASP are available, M3UA peer
protocol is required to control which ASP is currently active. The
ordered list of ASPs within a logical Application Server is kept
updated in the SG to reflect the active Application Server Process(es).
1.6 Definition of M3UA Boundaries 1.6 Definition of M3UA Boundaries
1.6.1 Definition of the boundary between M3UA and an MTP3-User. 1.6.1 Definition of the boundary between M3UA and an MTP3-User.
From ITU Q.701 [2]: >From ITU Q.701 [2]:
MTP-TRANSFER request MTP-TRANSFER request
MTP-TRANSFER indication MTP-TRANSFER indication
MTP-PAUSE indication MTP-PAUSE indication
MTP-RESUME indication MTP-RESUME indication
MTP-STATUS indication MTP-STATUS indication
1.6.2 Definition of the boundary between M3UA and SCTP 1.6.2 Definition of the boundary between M3UA and SCTP
The upper layer primitives provided by the SCTP are provided in [5] The upper layer primitives provided by the SCTP are provided in [13]
1.6.3 Definition of the Boundary between M3UA and the Layer Management
M-SCTP ESTABLISH
M-SCTP RELEASE
M-SCTP STATUS
M-ASP STATUS
M-ERROR
(Ed Note: more text to be added)
2.0 Protocol Elements 2.0 M3UA Protocol Elements
The general message format includes a Common Message Header together The general M3UA message format includes a Common Message Header
with a list of zero or more parameters as defined by the Message Type. followed by zero or more parameters as defined by the Message Type.
For forward compatability, all Message Types may have attached For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version. parameters even if none are specified in this version.
2.1 Common Message Header 2.1 Common Message Header
The protocol messages for MTP3-User Adaptation require a message The protocol messages for MTP3-User Adaptation require a message
structure which contains a version, message type, message length, and structure which contains a version, message type, message length, and
message contents. This message header is common among all signaling message contents. This message header is common among all signaling
protocol adaptation layers: protocol adaptation layers:
0 7 8 15 16 31 0 1 2 3
+-------+-------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Vers | Spare | Msg Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------+-------+---------------+ | Version | Spare | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length | | Message Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
2.1.1 M3UA Protocol Version
The version field (vers) contains the version of the M3UA adaptation All fields in an M3UA message MUST be transmitted in the network byte order,
unless otherwise stated.
11 2.1.1 M3UA Protocol Version
The version field (Vers.) contains the version of the M3UA adaptation
layer. The supported versions are: layer. The supported versions are:
01 Release 1.0 protocol 0000 0001 Release 1.0 protocol
2.1.2 Message Types 2.1.2 Message Types
The following list contains the message types for the defined messages. The following list contains the message types for the defined messages.
ISUP/SCCP Tunneling (ITUN) Messages Transfer Messages
Data Message 0101 Data 0101
SS7 Signalling Network Management (SSNM) Messages SS7 Signaling Network Management (SSNM) Messages
Destination Unavailable (DUNA) 0201 Destination Unavailable (DUNA) 0201
Destination Available (DAVA) 0202 Destination Available (DAVA) 0202
Destination State Audit (DAUD) 0203 Destination State Audit (DAUD) 0203
SS7 Network Congestion State (SCON) 0204 SS7 Network Congestion State (SCON) 0204
Destination User Part Unavailable (DUPU) 0205 Destination User Part Unavailable (DUPU) 0205
Application Server Process Maintenance (ASPM) messages Application Server Process Maintenance (ASPM) messages
ASP Up 0301 ASP Up 0301
skipping to change at line 590 skipping to change at page 17, line 39
Management (MGMT) Messages Management (MGMT) Messages
Error 0000 Error 0000
2.1.3 Message Length 2.1.3 Message Length
The Message Length defines the length of the message in octets, not The Message Length defines the length of the message in octets, not
including the header. including the header.
2.2 ITUN Messages 2.2 ISUP/SCCP Transfer Messages
The following section describes the ITUN messages and parameter The following section describes the ISUP/SCCP Transfer messages and
contents. The general ITUN message format includes a Common Message parameter contents. The general message format includes a Common
Header together with a list of zero or more parameters as defined by Message Header together with a list of zero or more parameters as
the Message Type. All Message Types can have attached parameters. defined by the Message Type. All Message Types can have attached
parameters.
2.2.1 Data Message 2.2.1 Data Message
The Data message contains SS7 MTP3-User protocol data, which is an MTP- The Data message contains SS7 MTP3-User protocol data, which is an MTP-
TRANSFER primitive, normally including the complete MTP3 Routing Label. TRANSFER primitive, including the complete MTP3 Routing Label. The Data
The Data message contains the following parameters: message contains the following parameters:
SCN PROTOCOL IDENTIFIER (Optional) PROTOCOL IDENTIFIER (Optional)
INTERFACE IDENTIFIER (Optional) NETWORK APPEARANCE (Optional)
PROTOCOL DATA PROTOCOL DATA
12
The format for the Data Message parameters is as follows: The format for the Data Message parameters is as follows:
0 15 16 31
+---------------+---------------+ 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCN Protocol Identifier* | | Protocol Identifier* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier* | | Network Appearance* |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
| Protocol Data | | Protocol Data |
...
+---------------+---------------+
The SCN Protocol Identifier parameter identifies explicitly the SCN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
signaling protocol being transported, where the SCN protocol carried is
not known implicitly in the context of a particular association or
stream. The SCN Protocol Id defines the protocol type, variant, and
version, and thereby specifies the components and encoding of the
Protocol Data parameter. The SCN Protocol Id may also define what SCN
Protocol Data components are omitted in the Protocol Data (e.g.,
whether or not the Protocol Data contains an MTP routing label). SCN
Protocol Ids will be maintained by IANA outside of this document and
may be registered on an "as needed" basis. The SCN Protocol ID is not
required in Data messages if the Protocol Id information is pre-
configured or identified at Association or Path establishment.
*********** The Protocol Identifier parameter identifies explicitly the MTP3-User
ED Note: The SCN Protocol Identifier parameter format is for further Part being transported, where the SCN protocol carried is
study. The protocol identifier values should be maintained outside of not known implicitly in the context of a particular SCTP
this document by IANA to allow registration of values without re- association/stream or Network Appearance/SIO. The Protocol Id defines
issuing the adaptation layer protocol document. We need decision on the protocol type, variant, and version, and thereby specifies the
encoding of mime-type value or fixed string/integer. If mime-type need components and encoding of the Protocol Data parameter. Protocol Ids
to refer to "draft-ietf-sigtran-mime-isup.txt" for an example of an will be maintained by IANA outside of this document and may be
application/ISUP media type defined according to the rules defined in registered on an "as needed" basis. The Protocol Id is not required in
RFC 2048. Data messages if the Protocol Id information is pre-configured or
************ identified at Association or Path establishment.
The Interface Identifier optionally identifies the physical interface, Ed Note: The Protocol Id format is an OID as defined in .....
or network, at the SG for which the signaling messages are
sent/received. The format is an ASCII string, the values of which are
assigned according to network operator policy. The interface Identifier
string should be padded to 32-bit boundaries.
13 The Network Appearance identifies the SS7 network context for the
message, for the purposes of logically separating the signaling traffic
between the SG and the Application Server Processes over common SCTP
Associations. An example is where an SG is logically partitioned to
appear as an element in four different national networks. A Network
Appearance implicitly defines the SS7 Destination Point Code, Network
Indicator and MTP3 protocol type/variant/version used within each
network.
************** The format is an ASCII string, the values of which are assigned
Ed Note: The identification of the interface can be very useful at MGCs
that are receiving signaling from multiple national networks and cannot according to network operator policy. The Network Appearance string
rely on the SS7 NI value to tell their signalling traffic apart. should be padded to 32-bit boundaries.
However, no procedures are specified.
**************
The Protocol Data field contains the MTP3-User application message, The Protocol Data field contains the MTP3-User application message,
which is an MTP-TRANSFER primitive. As defined for a specific value of which is in effect an MTP-TRANSFER primitive. As defined for a
the Protocol Identifier, this will include the MTP-User Data and specific value of the Protocol Identifier, this will include the MTP-
normally includes the MTP Routing Label (SS7 OPC, DPC, SLS), and the User Data and includes the MTP Routing Label (SS7 OPC, DPC, SLS), and
SIO (Network Indicator & optional Message Priority codes). the SIO (Service Indicator, Network Indicator & optional Message
Priority codes). In the case of ISUP messages, the Circuit
Identification Code is also included.
2.3.2 SS7 Signaling Network Management (SSNM) Messages 2.3.2 SS7 Signaling Network Management (SSNM) Messages
2.3.2.1 Destination Unavailable (DUNA) 2.3.2.1 Destination Unavailable (DUNA)
The DUNA message is sent from the SG to the ASP to indicate that The DUNA message is sent from the SG to all concerned ASPs to indicate
the SG has determined that an SS7 destination is unreachable. The MTP- that the SG has determined that an SS7 destination is unreachable. The
User at the ASP is expected to stop traffic to the affected destination MTP3-User at the ASP is expected to stop traffic to the affected
through the SG initiating the DUNA. destination through the SG initiating the DUNA.
The DUNA message contains the following parameters: The DUNA message contains the following parameters:
Protocol Identifier (Optional) Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code Affected Destination Point Code
Info String (Optional) Info String (Optional)
The format for DUNA parameter is as follows: The format for DUNA Message parameters is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 7 8 15 16 31 | (MTP) Protocol Identifier* |
+---------------+---------------+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* | | Network Appearance* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Affected DPC | | Spare | Affected DPC |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Identifier parameter is defined similarly to the SCN
14 The Protocol Identifier parameter is defined similarly to Section 2.2.1
but in this case defines the MTP3 version/variant. In this context it
defines the format of the Affected DPC parameter. By identifying the
MTP variant and version, the point code length (e.g., 14-, 16-, or 24-
bit) and sub-field definitions (e.g., ANSI network/cluster/member, ITU-
international zone/region/signal_point, many national field variants,
...) can be determined.
Protocol Id but in this case defines the MTP3 version/variant. In this The Network Appearance is defined as in Section 2.2.1
context it defines the format of the Affected DPC parameter. By
identifying the MTP variant and version, the point code size (e.g., 14-
, 16-, or 24-bit) and sub-field definitions (e.g., ANSI
network/cluster/member, ITU-international zone/region/signal_point,
many national field variants, ...) can be determined.
The INFO String parameter can carry any meaningful 8-BIT ASCII The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message. Length of the INFO String character string along with the message. Length of the INFO String
parameter is from 0 to 255 characters. No procedures are presently parameter is from 0 to 255 characters. No procedures are presently
identified for its use but the INFO String can be used by Operators to identified for its use but the INFO String may be used by Operators to
identify in text form the location reflected by the Affected DPC for identify in text form the location reflected by the Affected DPC for
debugging purposes. debugging purposes.
The Affected DPC is provisionally a three-octet parameter to allow 14-, The Affected DPC is provisionally a three-octet parameter to allow 14-,
16- and 24-bit binary formatted SS7 Point Codes. 16- and 24-bit binary formatted SS7 Point Codes.
2.3.2.2 Destination Available (DAVA) 2.3.2.2 Destination Available (DAVA)
The DAVA message is sent from the SG to the ASP to indicate that the SG The DAVA message is sent from the SG to all concerned ASPs to indicate
has determined that an SS7 destination is now reachable. The ASP MTP3- that the SG has determined that an SS7 destination is now reachable.
User protocol is expected to resume traffic to the affected destination The ASP MTP3-User protocol is expected to resume traffic to the
through the SG initiating the DUNA. affected destination through the SG initiating the DUNA.
The DAVA message contains the following parameters: The DAVA message contains the following parameters:
Protocol Identifier (Optional) Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code Affected Destination Point Code
Info String (Optional) Info String (Optional)
The parameter format and definitions for the DAVA message is the same The format and description of DAVA Message parameters is the same as
as for the DUNA message (See Section 2.3.2.2). for the DUNA message (See Section 2.3.2.1.)
2.3.2.3 Destination State Audit (DAUD) 2.3.2.3 Destination State Audit (DAUD)
The DAUD message can be sent from the ASP to the SG to query the The DAUD message can be sent from the ASP to the SG to query the
availability state of the SS7 routes to an affected destination. A availability state of the SS7 routes to an affected destination. A
DAUD is sent periodically after the ASP has received a DUNA, until a DAUD may be sent periodically after the ASP has received a DUNA, until
DAVA is received. The DAUD can also be sent when an ASP recovers from a DAVA is received. The DAUD can also be sent when an ASP recovers
interruption of the transport path to the SG. from isolation from the SG.
The DAUD message contains the following parameters:
Protocol Identifier (Optional) Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code Affected Destination Point Code
Info String (Optional) Info String (Optional)
The format and description of DAUD parameters is the same as for the The format and description of DAUD Message parameters is the same as
DUVA message (See Section 2.3.2.1.) for the DUNA message (See Section 2.3.2.1.)
***********
Ed Note: It is for further study whether multiple Affected
Destination Point Codes can be included as a list in one DAUD message
and in responding DUVA messages.
***********
15
The SG receiving the DAUD should reply with the availability state of
the queried destination in a DUNA or DAVA message.
2.3.2.4 SS7 Network Congestion (SCON) 2.3.2.4 SS7 Network Congestion (SCON)
The SCON message can be sent from the SG to the ASP to indicate that The SCON message can be sent from the SG to all concerned ASPs to
the congestion level in the SS7 network to a specified destination has indicate that the congestion level in the SS7 network to a specified
changed. destination has changed.
The SCON message contains the following parameters: The SCON message contains the following parameters:
Protocol Identifier (Optional) Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code Affected Destination Point Code
Info String (Optional) Info String (Optional)
Congestion Level (Optional) Congestion Level (Optional)
0 7 8 15 16 31 The format for SCON Message parameters is as follows:
+---------------+---------------+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* | | Protocol Identifier* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Affected DPC |
+---------------+---------------+ | Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cong. Level | Affected DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+---------------+---------------+
| Congestion Level* |
+-------------------------------+
The format and description of the Protocol Identifier, Affected DPC and The format and description of the Protocol Identifier, Network
Info String parameters is the same as for the DUVA message (See Section Appearance, Affected DPC and Info String parameters is the same as for
2.3.2.1.) the DUNA message (See Section 2.3.2.1.)
The valid values for the optional Congestion Level are shown in the The valid values for the optional Congestion Level parameter are shown
following table. in the following table.
16 Value Description
Define Value Description 00 No Congestion or Undefined
Level 0 0000 No Congestion or Undefined 01 Congestion Level 1
Level 1 0001 Congestion Level 1 02 Congestion Level 2
Level 2 0002 Congestion Level 2 03 Congestion Level 3
Level 3 0003 Congestion Level 3
The congestion levels are as defined in the national congestion method The congestion levels are as defined in the national congestion method
in the ITU MTP recommendation [2] or in the ANSI MTP standard [10]. in the ITU MTP recommendation [14] or in the ANSI MTP standard [15].
For MTPs without congestion levels, for example the ITU international For MTP versions/variants without congestion levels, for example the
method, the parameter is omitted. ITU international method, the parameter is always Undefined.
The ASP receiving the SCON message is expected to follow the currently
defined MTP3-User protocol reaction to an indication of SS7 network
congestion.
2.3.2.5 Destination User Part Unavailable (DUPU) 2.3.2.5 Destination User Part Unavailable (DUPU)
The DUPU message is used by a SG to inform an ASP that a remote peer The DUPU message is used by a SG to inform an ASP that a remote peer
MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable. MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable.
The DUPU message contains the following parameters: The DUPU message contains the following parameters:
Protocol Identifier (Optional) Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code Affected Destination Point Code
Info String (Optional) Info String (Optional)
Reason Reason
The format for optional DUPU message is as follows: The format for DUPU Message parameters is as follows:
0 7 8 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* | | Protocol Identifier* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+---------------+---------------+
| Affected DPC |
+---------------+---------------+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | Network Appearance* |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length | | Tag (0xx) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason | Affected DPC |
+-------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | INFO String* |
The format and description of the Protocol Identifier, Affected DPC and +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Info String parameters is the same as for the DUVA message (See Section
2.3.2.1.) The format and description of the Protocol Identifier, Network
Appearance, Affected DPC and Info String parameters is the same as for
the DUNA message (See Section 2.3.2.1.)
The valid values for Reason are shown in the following table. The valid values for Reason are shown in the following table.
Define Value Description Define Value Description
UPU-Unknown 0x4 MTP User Part Unavailable, No Reason Given UPU-Unknown 01 MTP User Part Unavailable, No Reason Given
UPU-Unequipped 0x5 MTP User Part Unavailable, Unequipped UPU-Unequipped 02 MTP User Part Unavailable, Unequipped
UPU-Inaccessible 0x6 MTP User Part Unavailable, Inaccessible UPU-Inaccessible 03 MTP User Part Unavailable, Inaccessible
The ASP receiving the DUPU message is expected to follow the currently
defined MTP3-User protocol reaction to an indication of remote user
part unavailabilty.
2.3.3 Application Server Process Maintenance (ASPM) Messages 2.3.3 Application Server Process Maintenance (ASPM) Messages
2.3.3.1 ASP Up (ASPUP) 2.3.3.1 ASP Up (ASPUP)
The ASP-UP message is used to indicate to a remote M3UA peer that the The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer
Adaptation layer is ready to receive traffic or maintenance messages. that the Adaptation layer is ready to receive traffic or maintenance
messages.
The ASPUP message contains the following parameters: The ASPUP message contains the following parameters:
Adaptation Layer Identifer (optional) Adaptation Layer Identifer (optional)
SCN Protocol Identifier (optional) Protocol Identifier (optional)
INFO String (optional) INFO String (optional)
The format for the ASPUP message is as follows: The format for ASPUP Message parameters is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x2) | Length | | Tag (0x2) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Layer Identifier* | | Adaptation Layer Identifier* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length | | Tag (0x3) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* | | Protocol Identifier* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18
The format and description of the optional Protocol Identifier and Info The format and description of the optional Protocol Identifier and Info
String parameters is the same as for the DUVA message (See Section String parameters is the same as for the DUNA message (See Section
2.3.2.1.) 2.3.2.1.)
The optional Adaptation Layer Identifier is a string that identifies The optional Adaptation Layer Identifier (ALI) is a string that
the adaptation layer. This string must be set to "M3UA" which results identifies the adaptation layer. This string must be set to "M3UA"
in a length of 4. The ALI would normally only be used in the initial which results in a length of 4. The ALI would normally only be used in
ASP Up message across a new SCTP association to ensure both peers are the initial ASP Up message across a new SCTP association to ensure both
assuming the same adaptation layer protocol. peers are assuming the same adaptation layer protocol.
Note: Strings are padded to 32-bit boundaries. The length field Note: Strings are padded to 32-bit boundaries. The length field
indicates the end of the string. indicates the end of the string.
2.3.3.2 ASP Down (ASPDN) 2.3.3.2 ASP Down (ASPDN)
The ASP-DN message is used to indicate to a remote M3UA peer that the The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer
adaptation layer is not ready to receive traffic or maintenance that the adaptation layer is not ready to receive traffic or
messages. maintenance messages.
The ASPDN message contains the following parameters: The ASPDN message contains the following parameters:
Reason
INFO String (Optional) INFO String (Optional)
The format for the ASPDN message is as follows: The format for the ASPDN message parameters is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
**************** The format and description of the optional Info String parameter is the
Ed Note: Need to add a reason code parameter. Reasons could be failure same as for the DUNA message (See Section 2.3.2.1.)
or management inhibit.
**************** The Reason parameter indicates the reason that the remote M3UA
adaptation layer is unavailable. The valid values for Reason are shown
in the following table.
Value Description
0x1 Processor Outage
0x2 Management Inhibit
2.3.3.3 ASP Active (ASPAC) 2.3.3.3 ASP Active (ASPAC)
The ASPAC message is sent by an ASP to indicate to an SG that it is The ASPAC message is sent by an ASP to indicate to an SG that it is
the active ASP to be used from within a list of primary and back-up Active and ready to be used.
ASPs for a particular AS.
The ASPAC message contains the following parameters: The ASPAC message contains the following parameters:
Routing Context (Optional)
INFO String (Optional) INFO String (Optional)
The format for the ASPAC message is as follows: The format for the ASPAC message is as follows:
19 0 1 2 3
0 15 16 31 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Type parameter identifies the ASPAC as an Over-ride or Load-share
Active message. The valid values for Type are shown in the following
table.
Value Description
0x1 Over-ride
0x2 Load-share
Within a particular Routing Context, only one Type can be used. An SG
that receives an ASPAC with an incorrect type for a particular Routing
Context will respond with an Error Message.
The optional Routing Context parameter contains (a list of) integers
indexing the Application Server traffic that the sending ASP is
conigured to receive. There is one-to-one relationship between an
index entry and an AS Name. Because an AS can only appear in one
Network Appearance, the Network Appearance parameter is not required in
the ASPAC message
An Application Server Process may be configured to process traffic for
more than one logical Application Server. From the perspective of an
ASP, a Routing Context defines a range of signaling traffic that the
ASP is currently configured to receive from the SG. For example, an
ASP could be configured to support call processing for multiple ranges
of PSTN trunks and therefore receive related signaling traffic,
identified by separate SS7 DPC/OPC/CIC_ranges.
The format and description of the optional Info String parameter is the
same as for the DUNA message (See Section 2.3.2.1.)
2.3.3.4 ASP Inactive (ASPIA) 2.3.3.4 ASP Inactive (ASPIA)
The ASPIA message is sent by an ASP to indicate to an SG that it is The ASPIA message is sent by an ASP to indicate to an SG that it is no
no longer the the active ASP to be used from within a list of primary longer an active ASP to be used from within a list of ASPs. The SG
and back-up ASP for a particular AS. The SG will respond with an ASPIA will respond with an ASPIA message and either discard incoming messages
message and either discard incoming messages or buffer for a timed or buffer for a timed period and then discard.
period and then discard.
The ASPIA message contains the following parameters: The contains the following parameters:
Routing Context (Optional)
INFO String (Optional) INFO String (Optional)
The format for the ASPIA message is as follows: The format for the ASPIA message parameters is as follows:
0 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length | | Tag (0x4) | Length |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* | | INFO String* |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Routing Context and Info
String parameters is the same as for the ASPAC message (See Section
2.3.3.3.)
2.3.4 Management Messages 2.3.4 Management Messages
2.3.4.1 Error (ERR) 2.3.4.1 Error (ERR)
The ERR message is sent when an invalid value is found in an incoming The ERR message is sent when an invalid value is found in an incoming
message. message.
The ERR message contains the following parameters: The ERR message contains the following parameters:
Error Code Error Code
The format for the ERR message is as follows: The format for the ERR message is as follows:
0 7 8 15 16 31 0 1 2 3
+---------------+---------------+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+---------------+---------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20
The Error Code can be one of the following values: The Error Code can be one of the following values:
Invalid Version 0x1 Invalid Version 0x1
Invalid Interface Identifier 0x2 Invalid Network Appearance 0x2
Invalid SCN Version 0x3 Invalid SCN Version 0x3
Invalid Adaptation Layer Identifier 0x4 Invalid Adaptation Layer Identifier 0x4
Invalid Stream Identifier 0x5 Invalid Stream Identifier 0x5
Invalid Message Type 0x6 Invalid Message Type 0x6
3.0 Procedures 3.0 Procedures
The M3UA layer needs to respond to various local primitives it receives The M3UA layer needs to respond to various local primitives it receives
from other layers as well as the messages that it receives from the from other layers as well as the messages that it receives from the
peer M3UA layers. This section describes the M3UA procedures in peer M3UA layers. This section describes the M3UA procedures in
response to these events. response to these events.
3.1 Procedures to support the M3UA services in Section 1.4.1 3.1 Procedures to support the services of the M3UA layer
These procedures support the M3UA transport of MTP3-User/MTP3 boundary The services of the M3UA layer are described in Section 1.4.1. These
procedures support the M3UA transport of MTP3-User/MTP3 boundary
primitives. primitives.
3.1.1 Receipt of Local primitives 3.1.1 Receipt of Local primitives
On receiving a primitive from the upper layer, the M3UA layer will On receiving an MTP-Transfer primitive from an upper layer, or the
send the corresponding ITUN or SSNM message (see Section 2) to its nodal inter-working function at an SG, the M3UA layer will send a
peer. The M3UA layer must fill in various fields of the common and corresponding Data message (see Section 2) to its M3UA peer. The M3UA
specific headers correctly. In addition the message needs to be sent layer must fill in various fields of the common and specific headers
on the appropriate SCTP stream. correctly.
3.1.2 Receipt of ITUN or SSNM Messages from the Peer M3UA At an SG, the M3UA address translation and mapping function determines
the logical Application Server based on the information in the incoming
message. From an ordered list of ASPs within the AS table, the Active
ASP is selected and the Data message is constructed and issued on the
corresponding SCTP Association. If more than one ASP is active (i.e.,
traffic is to be load-shared across all the active ASPs), one of the
active ASPs from the list is selected. The selection algorithm is
implementation dependent but could be based on, for example, the SLS or
ISUP CIC.
On receiving ITUN or SSNM messages from the remote M3UA Peer, the M3UA In addition, the message needs to be sent on the appropriate SCTP
layer invokes the appropriate primitive indications to the M3UA-User stream, taking care to conserve the message sequencing needs of the
signaling application.
Ed Note: Further description of stream assignment and/or examples are
required
3.2 Procedures to support the M3UA services in Section 1.4.2 3.2 Procedures to support the M3UA services in Section 1.4.2
3.2.1 Layer Management primitives procedures 3.2.1 Layer Management primitives procedures
On receiving these primitives from the local layer management, the M3UA On receiving these primitives from the local layer management, the M3UA
layer will send the corresponding management message (Error) to its layer will send the corresponding management message (Error) to its
peer. The M3UA layer must fill in the various fields of the common and peer. The M3UA layer must fill in the various fields of the common and
specific headers correctly. specific headers correctly.
3.2.2 Receipt of Peer Management messages 3.2.2 Receipt of Peer Management messages
Upon receipt of Management messages, the M3UA layer must invoke the Upon receipt of Management messages, the M3UA layer must invoke the
corresponding Layer Management primitive indications (M-ERROR ind.) to corresponding Layer Management primitive indications (M-ERROR ind.) to
the local layer management.
3.3 Procedures to support the M3UA services in Section 1.4.3 the local layer management.
21 3.3 Procedures to support the M3UA services in Section 1.4.4
These procedures support the M3UA management of SCTP Associations and These procedures support the M3UA management of SCTP Associations and
ASP Paths between SGs and ASPs ASP Paths between SGs and ASPs
3.3.1 State Maintenance 3.3.1 State Maintenance
The M3UA layer on the SG needs to maintain the state of each ASP as The M3UA layer on the SG needs to maintain the state of each ASP as
well as the state of the related ASs. input to the SGs address translation and mapping function.
3.3.1.1 ASP States 3.3.1.1 ASP States
The state of each ASP is maintained in the M3UA layer in the SG. The The state of each ASP is maintained in the M3UA layer in the SG. The
state of an ASP changes due to events. The events include: state of an ASP changes due to events. The events include:
* Reception of messages from peer M3UA layer * Reception of messages from peer M3UA layer
* Reception of indications from the SCTP layer * Reception of indications from the SCTP layer
The ASP state transition diagram is shown in Figure 4. The possible The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are: states of an ASP are:
ASP-DOWN: The Application Server Process is unavailable. Initially all ASP-DOWN: The Application Server Process is unavailable. Initially all
ASPs will be in this state. ASPs will be in this state.
ASP-UP: The Application Server Process is available but application ASP-UP: The Application Server Process is available but application
traffic is stopped. traffic is stopped.
ASP-ACTIVE: The Application Server Process is available and application ASP-ACTIVE: The Application Server Process is available and application
traffic is active. At most one ASP per AS can be in the active state. traffic is active (for a particular Routing Context or set of Routing
Contexts).
Figure 4: ASP State Transition Diagram Figure 4: ASP State Transition Diagram
+-------------+ +-------------+
|-------->| | |-------->| |
| | ASP-ACTIVE | | | ASP-ACTIVE |
| +-------------+ | +-------------+
| ^ | | ^ |
| ASP | | ASP | ASP | | ASP
| Active | | Inactive | Active | | Inactive
skipping to change at line 1135 skipping to change at page 30, line 29
| ^ | | ^ |
| ASP | | ASP Down / | ASP | | ASP Down /
| Up | | SCTP CDI | Up | | SCTP CDI
| | v | | v
| +-------------+ | +-------------+
| | | | | |
|-------->| | |-------->| |
| ASP-DOWN | | ASP-DOWN |
+-------------+ +-------------+
22
SCTP CDI: The local SCTP layer's Communication Down Indication to the SCTP CDI: The local SCTP layer's Communication Down Indication to the
Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this Upper Layer Protocol (M3UA) on an SG. The local SCTP will send this
indication when it detects the loss of connectivity to the ASP's SCTP indication when it detects the loss of connectivity to the ASP's SCTP
layer. layer.
3.3.1.2 AS States 3.3.1.2 AS States
The state of the AS is maintained in the M3UA layer on the SG. The state of the AS is maintained in the M3UA layer on the SG.
The state of an AS changes due to events. These events include: The state of an AS changes due to events. These events include:
skipping to change at line 1164 skipping to change at page 31, line 5
that all related ASPs are in the ASP-DOWN state for this AS. Initially that all related ASPs are in the ASP-DOWN state for this AS. Initially
the AS will be in this state. the AS will be in this state.
AS-UP: The Application Server is available but no application traffic AS-UP: The Application Server is available but no application traffic
is active (i.e., one or more related ASPs are in the ASP-UP state, but is active (i.e., one or more related ASPs are in the ASP-UP state, but
none in the ASP-Active state). none in the ASP-Active state).
AS-ACTIVE: The Application Server is available and application traffic AS-ACTIVE: The Application Server is available and application traffic
is active. This state implies that one ASP is in the ASP-ACTIVE state. is active. This state implies that one ASP is in the ASP-ACTIVE state.
AS-PENDING: The Active ASP has transitioned from active to inactive or AS-PENDING: An active ASP has transitioned from active to inactive or
down. A recovery timer T(r) will be started and all incoming SCN down and it was the last remaining active ASP in the AS. A recovery
messages will be queued by the SG. If an ASP becomes active before T(r) timer T(r) will be started and all incoming SCN messages will be queued
expires, the AS will move to AS-ACTIVE state and all the queued by the SG. If an ASP becomes active before T(r) expires, the AS will
messages will be sent to the active ASP. move to AS-ACTIVE state and all the queued messages will be sent to the
active ASP.
If T(r) expires before an ASP becomes active, the SG stops queuing If T(r) expires before an ASP becomes active, the SG stops queuing
messages and discards all previously queued messages. The AS will move messages and discards all previously queued messages. The AS will move
to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it will move
to AS-DOWN state. to AS-DOWN state.
23
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
+----------+ one ASP trans ACTIVE +-------------+ +----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| | | |------------------------>| |
| AS-UP | | AS-ACTIVE | | AS-UP | | AS-ACTIVE |
| | | | | | | |
| |< -| | | |< -| |
+----------+ \ / +-------------+ +----------+ \ / +-------------+
^ | \ Tr Trigger / ^ | ^ | \ Tr Trigger / ^ |
| | \ at least one / | | | | \ at least one / | |
skipping to change at line 1229 skipping to change at page 32, line 21
Alternatively, if the remote M3UA-peer establishes the SCTP association Alternatively, if the remote M3UA-peer establishes the SCTP association
first, the M3UA layer will receive an SCTP Communication Up indication first, the M3UA layer will receive an SCTP Communication Up indication
primitive from the SCTP. The M3UA layer will then invoke the primitive primitive from the SCTP. The M3UA layer will then invoke the primitive
M-SCTP ESTABLISH indication to the Layer Management. M-SCTP ESTABLISH indication to the Layer Management.
Once the SCTP association is established, The M3UA layer at an ASP will Once the SCTP association is established, The M3UA layer at an ASP will
then find out the state of its local M3UA-user from the Layer then find out the state of its local M3UA-user from the Layer
Management using the primitive M-ASP STATUS. Based on the status of Management using the primitive M-ASP STATUS. Based on the status of
the local M3UA-User, the local ASP M3UA Application Server Process the local M3UA-User, the local ASP M3UA Application Server Process
24
Maintenance (ASPM) function will initiate the ASPM procedures, using Maintenance (ASPM) function will initiate the ASPM procedures, using
the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to
the SG - see Section 3.3.3. the SG - see Section 3.3.3.
If the M3UA layer subsequently receives an SCTP-Communication Down If the M3UA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer indication from the underlying SCTP layer, it will inform the Layer
Management by invoking the M-SCTP STATUS indication primitive. The Management by invoking the M-SCTP STATUS indication primitive. The
state of the ASP will be moved to "Down" at both the SG and ASP. state of the ASP will be moved to "Down" at both the SG and ASP.
At an ASP, the Layer Management may try to reestablish the SCTP At an ASP, the Layer Management may try to reestablish the SCTP
association using M-SCTP ESTABLISH request primitive. association using M-SCTP ESTABLISH request primitive.
3.3.3 ASPM procedures for peer-to-peer messages 3.3.3 ASPM procedures for peer-to-peer messages
3.3.3.1 ASP-Up 3.3.3.1 ASP-Up
The SG will mark the path as up if an explicit ASP UP (ASPUP) message is [Ed Note: text required to specify what SG does before first ASP-Up
received and internally the path is allowed to come up (i.e., not in a received]
locked local maintenance state). An ASP UP (ASPUP) message will be sent
to acknowledge the received ASPUP. The SG will respond to a ASPUP with a
ASPDN message if the path is in a locked maintenance state.
The SG will send a ASPUP message in response to a received ASPUP message The SG will mark the path as up if an explicit ASP UP (ASPUP) message
from the MGC even if that path was already marked as UP at the SG. is received and internally the path is allowed to come up (i.e., not in
a locked local maintenance state). An ASP UP (ASPUP) message will be
sent to acknowledge the received ASPUP. The SG will respond to a ASPUP
with a ASPDN message if the path is in a locked maintenance state.
The paths are controlled by the MGC. The SG will only send ASPUP in The SG will send a ASPUP message in response to a received ASPUP
message from the ASP even if that path was already marked as UP at the
SG.
The paths are controlled by the ASP. The SG will only send ASPUP in
response to the reception of a ASPUP message. response to the reception of a ASPUP message.
The MGC will send ASPUP messages every 2 (add text regarding this being The ASP will send ASPUP messages every 2 seconds until the path comes
a configurable timer) seconds until the path comes up (i.e. until it up (i.e. until it receives a ASPUP message from the SG for that path).
receives a ASPUP message from the SG for that path). The MGC may decide The ASP may decide to reduce the frequency (say to every 5 seconds) if
to reduce the frequency (say to every 5 seconds) if the an acknowledge-
ment is not received after a few tries.
The MGC should wait for the ASPUP message from the SG before transmitting the an acknowledgement is not received after a few tries.
ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will
risk message loss. The ASPUP message received from the SG is not The ASP should wait for the ASPUP message from the SG before
acknowledged by the MGC. transmitting ASP maintenance messages (ASPIA or ASPAC) or M3UA messages
or it will risk message loss. The ASPUP message received from the SG
is not acknowledged by the ASP.
3.3.3.2 ASP Down 3.3.3.2 ASP Down
The SG will mark the ASP as down and send a ASPDN message to the MGC if The SG will mark the ASP as down and send an ASPDN message to the ASP
one of the following events occur: if one of the following events occur:
- a ASP Down(ASPDN) message is received from the MGC, - an ASP Down(ASPDN) message is received from the ASP,
- the ASP is locked by local maintenance. - the ASP is locked by local maintenance at the SG.
The SG will also send a ASPDN message when the ASP is already down and The SG will also send a ASPDN message when the ASP is already down and
a ASPDN) message is received from the MGC. a ASPDN) message is received from the ASP.
The MGC will send ASPDN whenever it wants to take down a ASP. Since the
ASPDN messages to the SG or the ASPDN responses from the SG can be lost
25
(for example, during a MGC node failover), the MGC can send ASPDN messages The ASP will send ASPDN whenever it wants to take down a ASP. Since
every 2 seconds until the path comes down (i.e. until it receives a ASPDN the ASPDN messages to the SG or the ASPDN responses from the SG can be
message from the SG for that path). lost (for example, during fail-over), the MGC can send ASPDN messages
every 2 seconds until the path comes down (i.e. until it receives a
ASPDN message from the SG for that path).
3.3.3.3 ASP Version Control 3.3.3.3 ASP Version Control
If a ASP Up message with an unknown version is received, the receiving If a ASP Up message with an unknown version is received, the receiving
end will respond with an Error message. This will indicate to the end will respond with an Error message. This will indicate to the
sender which version the receiving node supports. sender which version the receiving node supports.
This is useful when protocol version upgrades are being performed. A This is useful when protocol version upgrades are being performed. A
node with the newer version should support the older versions used on node with the newer version should support the older versions used on
other nodes it is communicating with. other nodes it is communicating with.
The version field in the Error message header associated will indicate the The version field in the Error message header associated will indicate
version supported by the node. the version supported by the node.
3.3.3.4 ASP Active 3.3.3.4 ASP Active
When a ASP Active (ASPAC) message is received, the SG will start routing When an ASP Active (ASPAC) message is received, the SG will start
to that ASP. Reception of a ASPAC message overrides any previous ASPAC routing to that ASP. Reception of a ASPAC message overrides any
messages and results in the ASP associated with the ASPAC message to previous ASPAC messages and results in the ASP associated with the
become the newly active ASP. ASPAC message to become the newly active ASP.
3.3.3.5 ASP Inactive 3.3.3.5 ASP Inactive
When a ASPIA message is received, message transmission to that ASP ceases. When a ASPIA message is received, message transmission to that ASP
The SG will either discard all incoming messages or start buffering the ceases. The SG will either discard all incoming messages or start
incoming messages for T(r)seconds after which messages will be discarded. buffering the incoming messages for T(r)seconds after which messages
will be discarded.
If the ASP is down, all of the Paths that were supported by that ASP If the ASP is down, all of the Paths that were supported by that ASP
are, by default, down. are, by default, down.
3.4 Procedures to support the M3UA services in Section 1.4.3
3.4.1 At an SG
On receiving an MTP-PAUSE, MTP-RESUME, or MTP-STATUS indication
primitive from the inter-working function at an SG, the M3UA layer will
send a corresponding SSNM DUNA, DAVA, SCON, or DUPU message (see
Section 2) to the concerned M3UA peers. The M3UA layer must fill in
various fields of the common and specific headers correctly.
The M3UA address translation and mapping function determines the set of
ASPs to be informed based on the network appearance for which the
indication is relevant. All ASPs configured to send/receive traffic
within a particular network appearance are informed. If the SG
operates within a single network appearance, then all ASPs are
informed. It may be possible to suppress DUPU messages to ASPs that do
not implement an MTP3-User protocol peer for the affected MTP3-User,
but this is not mandatory.
In addition, the DUNA, DAVA, SCON messages need to be sent on a
sequenced stream as these primitives should arrive in order. This is
not required for the DUPU message, which may optionally be sent un-
sequenced.
3.4.2 At an ASP
At an ASP, upon receiving an SSNM message from the remote M3UA Peer,
the M3UA layer invokes the appropriate primitive indications to the
M3UA-User. Local management is informed but no state is maintained in
the M3UA layer.
4.0 Examples of M3UA Procedures 4.0 Examples of M3UA Procedures
4.1 Establishment of associations between an SG and an ASP 4.1 Establishment of Association and Traffic between SGs and ASPs
4.1.1 Single ASP in an Application Server ("1+0" sparing)
An example of the message flows for establishing an active association An example of the message flows for establishing an active association
between an SG and ASP is shown below. between an SG and an ASP is shown below. It is assumed that an SCTP
association is already set-up.
SG ASP1 SG ASP1
|
|<---------ASP Up---------|
|-------ASP Up (Ack)----->|
| |
|<-------ASP Active-------|
|----ASP Active (Ack)---->|
| |
<----------- ASP Up 4.1.2 Two ASPs in Application Server ("1+1" sparing)
ASP Up ---------->
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
An example of message flows for establishment of associations with two Establishment of Associations between an SG and Multiple ASPs in the
ASPs and the message flows for take-over of the primary (ASP1) by the same Application Server (Primary/Back-up case). In this case ASP1 will
secondary (ASP2). be the primary ASP for the AS and ASP2 will be a standby in the event
of failure of the withdrawal from service of ASP1. ASP could act as a
hot, warm, or cold standby depending on the extent to which ASP1 and
ASP2 share call state or can communicate call state under
failure/withdrawal events.
26
SG ASP1 ASP2 SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|-------ASP Up (Ack)----->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up (Ack)---------->|
| | |
<----------- ASP Up
ASP Up ---------->
(ACK)
<------------------------------ ASP Up
ASP Up ------------------------------>
(ACK)
<----------- ASP Active
ASP Active ---------->
(ACK)
... ...
<----------- ASP Inactive | | |
ASP Inactive ----------> |<-------ASP Active-------| |
(ACK) |----ASP Active (Ack)---->| |
| | |
(this message is optional) 4.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing
ASP Inactive ------------------------------> case)
<------------------------------ ASP Active
ASP Active ------------------------------>
(ACK)
4.2 M3UA/MTP3-User Boundary Examples SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|-------ASP Up (Ack)----->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up (Ack)---------->|
| | |
***************** ...
Ed Note: Text to be added
***************** | | |
|<--ASP Active (Ldshr)----| |
|----ASP Active (Ack)---->| |
| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active (Ack)------>|
| | |
4.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing
case)
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|----ASP Up (Ack)--->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASP Up (Ack)--->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up (Ack)--->|
| | | |
...
| | | |
|<-ASP Act. (Ldshr)--| | |
|---ASP Act. (Ack)-->| | |
| | | |
|<--------------------ASP Act. (Ldshr)---| |
|----------------------ASP Act. (Ack)--->| |
| | | |
4.3 ASP Traffic Fail-over Examples
4.3.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
Following on from the example in Section 4.1.2, and ASP withdraws from
service:
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|---ASP Inactive (Ack)--->| |
|----------------------------ASP Active (Optional)-->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active (Ack)------>|
| |
Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or
detection of SCTP failure), the initial SG-ASP1 ASP Inactive message
exchange would not occur.
4.3.2 (1+1 Sparing, Back-up Over-ride)
Following on from the example in Section 4.1.2, and ASP2 wishes to
over-ride ASP1 and take over the traffic:
SG ASP1 ASP2
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active (Ack)------>|
| | |
|------ASP Inactive------>| |
|<--ASP Inactive (Ack)----| |
| | |
4.3.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)
Following on from the example in Section 4.1.4, and ASP1 withdraws from
service:
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.-----| | |
|--ASP Inact. (Ack)->| | |
| | | |
|---------------------------------------ASP Act. (Optional)->|
| | | |
|<-----------------------------------------ASP Act. (Ldshr)--|
|-------------------------------------------ASP Act. (Ack)-->|
| | | |
Note: If the SG detects loss of the M3UA peer (M3UA heartbeat loss or
detection of SCTP failure), the first SG-ASP1 ASP Inactive message
exchange would not occur.
4.4 M3UA/MTP3-User Boundary Examples
4.4.1 At an ASP
This section describes the primitive mapping from the MTP3 User to M3UA
at an ASP.
4.4.1.1 Support for MTP-Transfer
When the MTP3-User has data to send into the SS7 network, it will use
the MTP-Transfer indication primitive. The M3UA on the ASP will do the
following when it receives an MTP-Transfer:
? Determine the correct SG
? Determine the correct association to the chosen SG
? Determine the correct stream in the association (e.g., based on SLS)
? Map the MTP-Transfer into the Payload of a Data message
? Send the Data message to the remote M3UA peer, over the SCTP
association
SG ASP
| |
|<-----Data Message-------|<--MTP-Transfer req.
| |
or
| |
|------Data Message------>|---MTP-Transfer ind.?
| |
4.4.1.2 Support for ASP Querying of SS7 Destination States
There are situations such as temporary loss of connectivity to the SG
that may cause the M3UA on the ASP to audit SS7 destination
availability states. Note: there is no primitive for the MTP3-User to
request this audit from the M3UA as this is initiated by an internal
M3UA management function.
The M3UA on the MGC / AN would send Destination State Audit (DAUD)
messages for each of the destinations that the MGC / AN supports.
SG ASP
| |
|<-----DAUD Message ------|
|<-----DAUD Message ------|
|<-----DAUD Message ------|
| |
| |
4.4.2 At an SG
This section describes the primitive mapping from the MTP3 Upper layer
boundary to the M3UA at the SG.
The MTP-PAUSE, MTP-RESUME and MTP-STATUS indication primitives from the
MTP3 upper layer interface at the SG need to be made available to the
remote MTP3-User lower layer interface at the ASP.
4.4.2.1 Destination Unavailable
The MTP3 on the SG will generate an MTP-PAUSE primitive when it
determines locally that an SS7 destination is unreachable. The M3UA
will map this primitive to a Destination Unavailable (DUNA) message.
It will determine which ASP(s) to send the DUNA based on the Network
Appearance information.
SG ASP
| |
--MTP-PAUSE ind.-->|------DUNA Message ----->|--MTP-PAUSE ind.-->
| |
4.4.2.2 Destination Available
The MTP3 on the SG will generate an MTP-RESUME primitive when it
determines locally that an SS7 destination that was previously
unreachable is now reachable. The M3UA will map this primitive to a
Destination Unavailable (DAVA) message. It will determine which ASP(s)
to send the DUNA based on the Network Appearance information.
SG ASP
| |
--MTP-RESUME ind.-->|------DAVA Message ----->|--MTP-RESUME ind.-->
| |
4.4.2.3 SS7 Network Congestion
The MTP3 on the SG will generate an MTP-STATUS primitive when it
determines locally that the route to an SS7 destination is congested.
The M3UA will map this primitive to a SS7 Network Congestion State
(SCON) message. It will determine which ASP(s) to send the DUPU to
based on the intended Application Server.
SG ASP
| |
--MTP-STATUS ind.-->|------SCON Message ----->|--MTP-STATUS ind.-->
| |
4.4.2.4 Destination User Part Unavailable
The MTP3 on the SG will generate an MTP-STATUS primitive when it
determines locally that an SS7 destination User Part is unavailable.
The M3UA will map this primitive to a Destination User Part Unavailable
(DUPU) message. It will determine which ASP(s) to send the DUPU to
based on the intended Application Server.
SG ASP
| |
--MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.-->
| |
5.0 Security 5.0 Security
M3UA relies upon IPSEC to ensure confidentiality of user payload. Consult M3UA relies upon IPSEC to ensure confidentiality of user payload.
[RFC 2401, "Security Architecture for the Internet Protocol", S. Kent, R. Consult [RFC 2401, "Security Architecture for the Internet Protocol",
Atkinson, November 1998] for more information on configuring IPSEC S. Kent, R. Atkinson, November 1998] for more information on
services. configuring IPSEC services.
6.0 Acknowledgements 6.0 Acknowledgements
The authors would like to thank John Loughney for his valuable comments The authors would like to thank John Loughney, Neil Olson, Norm Glaude,
and suggestions. and Michael Tuexen for their valuable comments and suggestions.
7.0 References 7.0 References
[1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling [1] RFC 2719, "Framework Architecture for Signaling Transport"
System No. 7 (SS7)'
[2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 [2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7)
(SS7) - Message Transfer Part (MTP)' - ISDN User Part (ISUP)'
[3] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - [3] ANSI T1.113 - 'Signaling System Number 7 - ISDN User Part
27 [4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN);
Service Specific Coordination Function for signaling at the Network Signalling System No.7; ISDN User Part (ISUP) version 2 for the
Node Interface (SSCF at NNI) international interface; Part 1: Basic services"
[4] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - [5] ITU-T Recommendations Q.711-714, 'Signalling System No. 7 (SS7) -
Service Specific Connection Oriented Protocol (SSCOP) Signalling Connection Control Part (SCCP)'
[5] Simple Control Transport Protocol [6] ANSI T1.112 'Signaling System Number 7 - Signaling Connection
draft-ietf-sigtran-sctp-00.txt, Sept. 1999, Work in Progress Control Part'
[6] ITU-T Recommendation Q.711-714 'Signalling System No. 7 [7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
(SS7) - Signaling Connection Control Part (SCCP)' Signalling System No.7; Signalling Connection Control Part (SCCP)
(connectionless and connection-oriented class 2) to support
international interconnection; Part 1: Protocol specification"
[7] ITU-T Recommendation Q.2210 'B-ISDN MTP' [8] ITU-T Recommendations Q.720, 'Telephone User Part'
[8] ITU-T Recommendation Q.xxxx 'ISUP BICC' [9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) -
Transaction Capabilities (TCAP)
[9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 [10] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities
(SS7) - Transaction Capabilities (TCAP) Application Part'
[10] ANSI T1.111 'Signaling System Number 7 - Message Transfer Part' [11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification"
5.0 Author's Addresses [12] RANAP
Lyndon Ong [13] Simple Control Transport Protocol <draft-ietf-sigtran-sctp-
Nortel Networks 05.txt>, Dec. 1999, Work in Progress
4401 Great America Pkwy
Santa Clara, CA, USA 95054
long@nortelnetworks.com
Greg Sidebottom [14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7)
Nortel Networks - Message Transfer Part (MTP)'
3685 Richmond Rd,
Nepean, Ontario, Canada K2H 5B7
gregside@nortelnetworks.com
Guy Mousseau [15] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
Nortel Networks
3685 Richmond Rd
Nepean, Ontario, Canada K2H 5B7
Ian Rytina [16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
Ericsson Australia Signalling System No.7; Message Transfer Part (MTP) to support
37/360 Elizabeth Street international interconnection; Part 1: Protocol specification"
Melbourne, Victoria 3000, Australia
ian.rytina@ericsson.com
Hanns Juergen Schwarzbauer [17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service
SIEMENS AG Specific Coordination Function for signaling at the Network Node
Hofmannstr. 5181359 Interface (SSCF at NNI)
Munich, Germany
HannsJuergen.Schwarzbauer@icn.siemens.de
28 [18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service
Specific Connection Oriented Protocol (SSCOP)
Ken Morneault [19] MTP2-User Adaptation Layer <draft-ietf-sigtran-m2ua-01.txt>, Nov.
Cisco Systems Inc. 1999, Work in Progress
13615 Dulles Technology Drive
Herndon, VA, USA 20171 [20] ITU-T Recommendation Q.2210 'B-ISDN MTP'
EMail: kmorneau@cisco.com
5.0 Author's Addresses
Lyndon Ong Guy Mousseau
Nortel Networks Nortel Networks
4401 Great America Pkwy 3685 Richmond Rd
Santa Clara, CA, USA 95054 Nepean, Ontario, Canada K2H 5B7
long@nortelnetworks.com
Greg Sidebottom Ian Rytina
Nortel Networks Ericsson Australia
3685 Richmond Rd, 37/360 Elizabeth Street
Nepean, Ontario, Canada K2H 5B7 Melbourne, Vic 3000 Australia
gregside@nortelnetworks.com ian.rytina@ericsson.com
Hanns Juergen Schwarzbauer Ken Morneault
SIEMENS AG Cisco Systems Inc.
Hofmannstr. 51 13615 Dulles Technology Rd
81359 Munich, Germany Herndon, VA 20171 USA
HannsJuergen.Schwarzbauer@icn.siemens.de kmorneau@cisco.com
Malleswar Kalla Malleswar Kalla
Telcordia Technologies Telcordia Technologies
MCC 1J211R MCC 1J211R
445 South Street 445 South Street
Morristown, NJ, USA 07960 Morristown, NJ, USA 07960
EMail: kalla@research.telcordia.com EMail: kalla@research.telcordia.com
This draft expires April 2000. This draft expires July 2000.
29
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/