| draft-ietf-sigtran-m3ua-01Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-m3ua-01.txt.
Network Working Group G. Sidebottom, L. Ong, Guy Mousseau
INTERNET-DRAFT Nortel Networks
Ian Rytina
Ericsson
Hanns-Juergen Schwarzbauer
Siemens
Ken Morneault
Cisco
Mallesh Kalla
Telcordia
Expires in six months 15 February 2000
SS7 MTP3-User Adaptation Layer (M3UA)
<draft-ietf-sigtran-m3ua-01.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This Internet Draft defines a protocol for the transport of any SS7
MTP3-User signaling (e.g., ISUP and SCCP messages) over IP using the
Simple Control Transport Protocol. Also, provision is made for
protocol elements that enable a seamless operation of the MTP3-User
peers in the SS7 and IP domains. This protocol would be used between a
Signaling Gateway (SG) and a Media Gateway Controller (MGC) or IP-
resident Database. It is assumed that the SG receives SS7 signaling
over a standard SS7 interface using the SS7 Message Transfer Part (MTP)
to provide transport.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 1]
Internet Draft MTP3-User Adaptation Layer Feb 2000
TABLE OF CONTENTS
1. Introduction..............................................3
2. Protocol Elements........................................11
3. Procedures...............................................21
4. Examples.................................................26
5. Security.................................................27
6. Acknowledgements.........................................27
7. References...............................................27
8. Author's Addresses.......................................28
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 2]
Internet Draft MTP3-User Adaptation Layer Feb 2000
1. Introduction
1.1 Scope
There is a need for SCN signaling protocol delivery from an SS7
Signaling Gateway (SG) to a Media Gateway Controller (MGC) or IP-
resident Database as described in the Framework Architecture for
Signalling Transport [1]. The delivery mechanism should meet the
following criteria:
* Support for transfer of all SS7 MTP3-User Part messages (e.g., ISUP,
SCCP, TUP, etc.)
* Support for the seamless operation of MTP3-User protocol peers
* Support for the management of SCTP transport associations and
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
management
In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols
and deliver ISUP, SCCP and/or any other MTP3-User protocol messages
over SCTP transport associations to MTP3-User peers in MGCs or IP-
resident Databases.
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 instance. An example of an Application Server is a virtual
switch element handling all call processing for a unique range of PSTN
trunks, identified by an SS7 DPC/OPC/CIC_range. Practically speaking,
an AS is modeled at the SG as an ordered list of one or more unique
Application Server Processes, of which one or more is normally actively
processing traffic.
Application Server Process (ASP) - A process instance of an Application
Server. An Application Server Process serves as an active or standby
process of an Application Server (e.g., part of a distributed virtual
switch or database element).
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of MTP3-User
protocol data units and M3UA adaptation layer peer messages.
Fail-over - The capability to re-route signaling traffic as required to
an alternate Application Server Process, or group of ASPs, within an
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 3]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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.
IP Database - The IP-resident analogue of a PSTN Service Control Point
(SCP) or wireless Home Location Register (HLR).
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
(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.
1.3 Signaling Transport Architecture
1.3.1 Protocol Architecture.
The framework architecture that has been defined for SCN signaling
transport over IP [1] uses multiple components, including 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.
Within the framework architecture, this document defines an MTP3-User
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 4]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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
is transmitted and received from the PSTN over a standard SS7 network
interface, using the SS7 Message Transfer Part (MTP) [14,15,16] to
provide reliable transport of the ISUP/SCCP signaling messages to and
from an SS7 Signaling End Point (SEP) or Signaling Transfer Point
(STP). The SG then provides a functional inter-working of transport
functions with the IP transport, in order to transfer the ISUP/SCCP
signaling messages to and from an Application Server Process where the
peer ISUP/SCCP protocol layer exists.
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.
Where ATM-base High Speed Links are used in the SS7 network, it is
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:
1.3.1.1 Example 1: ISUP transport
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 5]
Internet Draft MTP3-User Adaptation Layer Feb 2000
******** SS7 ***************** IP ********
* SEP *---------* SG *--------* ASP *
******** ***************** ********
+------+ +------+
| ISUP | | ISUP |
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | UDP | | UDP |
+------+ +------+ +------+ +------+
|_______________| |______________|
SEP - SS7 Signaling End Point
SCTP - Simple Control Transport Protocol
Within the SG, MTP-TRANSFER indication primitives received from the MTP
Level 3 upper layer interface are sent to the local M3UA-resident
network address translation and mapping function for ongoing routing to
the final IP destination. MTP-TRANSFER primitives received from the
local M3UA network address translation and mapping function are sent to
the MTP Level 3 upper layer interface as MTP-TRANSFER request
primitives for on-going MTP Level 3 routing to an SS7 SEP.
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:
******** SS7 ***************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** ***************** ********
+------+ +---------------+ +------+
| SCCP | | SCCP | | SCCP |
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | UDP | | UDP |
+------+ +------+ +------+ +------+
|_______________| |______________|
STP - SS7 Signaling Transfer Point
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 6]
Internet Draft MTP3-User Adaptation Layer Feb 2000
In this example, the SG contains an instance of the SS7 SCCP protocol
layer that may, for example, perform the SCCP Global Title Translation
(GTT) function for messages logically addressed to the SG SCCP. If the
result of a GTT for an SCCP message yields an SS7 DPC or DPC/SSN
address result of an SCCP peer located in the IP domain, the resulting
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.
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.
It is possible that the above SCCP GTT at the SG could yield the
address of an SCCP peer in the IP domain and the resulting MTP-TRANSFER
primitive would be sent back to the M3UA for delivery to an IP
destination.
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 below the SCCP and routes MTP-TRANSFER
messages to/from both the MTP3 and the M3UA, based on the SS7 DPC or
DPC/SSN address information. This nodal inter-working function has no
visible peer protocol with either the ASP or SEP.
Note that the services and interface provided by M3UA are the same as
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.
1.3.1.3 Example 3 - Seamless Handling of MTP3 Management
******** SS7 ***************** IP ********
* SEP *---------* *--------* *
* or * * SG * * ASP *
* STP * * * * *
******** ***************** ********
+------+ +------+-+------+ +------+
| MTP3 | | MTP3 | | M3UA | | M3UA |
+------| +------+ +------+ +------+
| MTP2 | | MTP2 | | SCTP | | SCTP |
+------+ +------+ +------+ +------+
| L1 | | L1 | | UDP | | UDP |
+------+ +------+ +------+ +------+
|_______________| |______________|
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 7]
Internet Draft MTP3-User Adaptation Layer Feb 2000
In the case of SS7 MTP3 network management, it is required that the
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.
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.
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
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 8]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 9]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 10]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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
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,
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 11]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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.
1.4.1 Support for the transport of MTP3-User Messages
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.
Note that M3UA does not itself impose a 272-octet user information
block limit as specified by the MTP Level 3. Larger information blocks
can be accommodated directly by M3UA/SCTP without the need for an upper
layer segmentation/re-assembly procedure such as specified in recent
SCCP or ISUP versions. However, in the context of an SG, the maximum
272-octet block size must be followed when inter-working to a SS7
network that does not support the transfer of larger information blocks
to the final destination, as is possible in the Broadband MTP [20].
This will avoid ISUP or SCCP fragmentation requirements at the SG.
However, if the SS7 network is provisioned to support the Broadband
MTP, the information block size limit may be increased past 272 octets.
1.4.2 Native Management Functions
The M3UA may provide management of the underlying SCTP transport
protocol to ensure that SG-ASP transport is available to the degree
called for by the MTP3-User signaling applications.
The M3UA provides the capability to indicate errors associated with
received M3UA messages and to notify, as appropriate, local management
and/or the remote peer M3UA.
1.4.3 Inter-working with MTP3 Network Management Functions
At the SG, the M3UA must also provide inter-working with MTP3
management functions to support seamless operation of the user SCN
signaling applications in the SS7 and IP domains. This includes:
- Providing an indication to MTP3-Users at an ASP that a remote
destination in the SS7 network is not reachable.
- Providing an indication to MTP3-Users at an ASP that a remote
destination in the SS7 network is now reachable.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 12]
Internet Draft MTP3-User Adaptation Layer Feb 2000
- Providing an indication to MTP3-Users at an ASP that messages to a
remote MTP3-User peer in the SS7 network are experiencing SS7
congestion
- Providing an indication to MTP3-Users at an ASP that a remote MTP3-
User peer is unavailable.
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.
1.4.4 Support for the management of SCTP associations between the SG
and AN.
The M3UA layer at the SG maintains the availability state of all
configured remote ASPs, in order to manage the SCTP Associations and
the traffic between the SG and ASPs. As well, the active/inactive
state of remote ASPs is also maintained - Active ASPs are those
currently receiving traffic from the SG.
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
indication primitive. For example, the M3UA may inform local management
of the reason for the release of an SCTP association, determined either
locally within the M3UA layer or by a primitive from the SCTP.
Also the M3UA layer may need to inform the local management of the
change in availability status of an ASP. This can be achieved using
the M-ASP STATUS primitive to change and indicate the status of an ASP.
1.5 Internal Functions Provided in the M3UA Layer
1.5.1 Address Translation and Mapping at the SG M3UA
In order to direct messages received from the MTP3 network to the
desired IP destination, the SG M3UA must perform address translation
and mapping functions using information from the received ISUP/SCCP
message.
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.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 13]
Internet Draft MTP3-User Adaptation Layer Feb 2000
This table is assumed to be dynamic, taking into account the
availability status of the individual ASPs in the list, configuration
changes, and possible fail-over mechanisms. The M3UA protocol includes
messages to convey the availability status of the individual ASPs as
input to a fail-over mechanism.
Possible SS7 address/routing information that may comprise a routing
key entry includes, for example, the OPC, DPC, SIO, ISUP CIC range or
SCCP Called Party Address. The particular information used in an SG
M3UA is implementation dependent.
1.5.2 SG Redundancy
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 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 load-sharing
case is possible where the signaling messages are load-shared across
two (or more) SGs.
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
of an implementation-dependent function (e.g., an implementation-
dependent indication from the SCTP of IP network congestion). When an
SG determines that the transport of SS7 messages to an MTP3 Management
Cluster is encountering congestion, the SG may optionally trigger SS7
MTP3 Transfer Controlled management messages to originating SS7 nodes.
The triggering of SS7 MTP3 Management messages from an SG is an
implementation-dependent function. At an ASP, congestion is indicated
to local MTP3-Users by means of an MTP-Status primitive indicating
congestion, to invoke appropriate upper layer responses, as per current
MTP3 procedures.
1.5.5 Seamless Network Management Inter-working.
The M3UA at an SG must maintain knowledge of SS7 node and MTP3
Management Cluster status in their respective domains in order to
perform as seamless as possible inter-working of the two domains. For
example, SG M3UA knowledge of the availability and/or congestion status
of MTP3 Management Cluster and SS7 nodes must be maintained and
disseminated in the respective networks so that end-to-end operation is
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 14]
Internet Draft MTP3-User Adaptation Layer Feb 2000
transparent to the communicating SCN protocol peers at the SS7 node and
ASP.
When an SG M3UA determines that the transport of SS7 messages to an
MTP3 Management Cluster is encountering congestion, the SG may
optionally inform the MTP3 route management function (by an
implementation-dependent mechanism). This information is used by the
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 M3UA determines that the transport of SS7 messages to all
ASPs in a particular MTP3 Management Cluster is interrupted, 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 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.
When an SG M3UA determines that the transport of SS7 messages to an ASP
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.
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.
1.5.6 Management Inhibit/Uninhibit
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.
1.5.7 Active Association Control
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).
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 15]
Internet Draft MTP3-User Adaptation Layer Feb 2000
1.6 Definition of M3UA Boundaries
1.6.1 Definition of the boundary between M3UA and an MTP3-User.
>From ITU Q.701 [2]:
MTP-TRANSFER request
MTP-TRANSFER indication
MTP-PAUSE indication
MTP-RESUME indication
MTP-STATUS indication
1.6.2 Definition of the boundary between M3UA and SCTP
The upper layer primitives provided by the SCTP are provided in [13]
2.0 M3UA Protocol Elements
The general M3UA message format includes a Common Message Header
followed by zero or more parameters as defined by the Message Type.
For forward compatibility, all Message Types may have attached
parameters even if none are specified in this version.
2.1 Common Message Header
The protocol messages for MTP3-User Adaptation require a message
structure which contains a version, message type, message length, and
message contents. This message header is common among all signaling
protocol adaptation layers:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Spare | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
All fields in an M3UA message MUST be transmitted in the network byte order,
unless otherwise stated.
2.1.1 M3UA Protocol Version
The version field (Vers.) contains the version of the M3UA adaptation
layer. The supported versions are:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 16]
Internet Draft MTP3-User Adaptation Layer Feb 2000
0000 0001 Release 1.0 protocol
2.1.2 Message Types
The following list contains the message types for the defined messages.
Transfer Messages
Data 0101
SS7 Signaling Network Management (SSNM) Messages
Destination Unavailable (DUNA) 0201
Destination Available (DAVA) 0202
Destination State Audit (DAUD) 0203
SS7 Network Congestion State (SCON) 0204
Destination User Part Unavailable (DUPU) 0205
Application Server Process Maintenance (ASPM) messages
ASP Up 0301
ASP Down 0302
ASP Active 0401
ASP Inactive 0402
Management (MGMT) Messages
Error 0000
2.1.3 Message Length
The Message Length defines the length of the message in octets, not
including the header.
2.2 ISUP/SCCP Transfer Messages
The following section describes the ISUP/SCCP Transfer messages and
parameter contents. The general message format includes a Common
Message Header together with a list of zero or more parameters as
defined by the Message Type. All Message Types can have attached
parameters.
2.2.1 Data Message
The Data message contains SS7 MTP3-User protocol data, which is an MTP-
TRANSFER primitive, including the complete MTP3 Routing Label. The Data
message contains the following parameters:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 17]
Internet Draft MTP3-User Adaptation Layer Feb 2000
PROTOCOL IDENTIFIER (Optional)
NETWORK APPEARANCE (Optional)
PROTOCOL DATA
The format for the Data 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Protocol Identifier parameter identifies explicitly the MTP3-User
Part being transported, where the SCN protocol carried is
not known implicitly in the context of a particular SCTP
association/stream or Network Appearance/SIO. The Protocol Id defines
the protocol type, variant, and version, and thereby specifies the
components and encoding of the Protocol Data parameter. Protocol Ids
will be maintained by IANA outside of this document and may be
registered on an "as needed" basis. The Protocol Id is not required in
Data messages if the Protocol Id information is pre-configured or
identified at Association or Path establishment.
Ed Note: The Protocol Id format is an OID as defined in .....
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
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 18]
Internet Draft MTP3-User Adaptation Layer Feb 2000
according to network operator policy. The Network Appearance string
should be padded to 32-bit boundaries.
The Protocol Data field contains the MTP3-User application message,
which is in effect an MTP-TRANSFER primitive. As defined for a
specific value of the Protocol Identifier, this will include the MTP-
User Data and includes the MTP Routing Label (SS7 OPC, DPC, SLS), and
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.1 Destination Unavailable (DUNA)
The DUNA message is sent from the SG to all concerned ASPs to indicate
that the SG has determined that an SS7 destination is unreachable. The
MTP3-User at the ASP is expected to stop traffic to the affected
destination through the SG initiating the DUNA.
The DUNA message contains the following parameters:
Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code
Info String (Optional)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (MTP) Protocol Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Spare | Affected DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 19]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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.
The Network Appearance is defined as in Section 2.2.1
The INFO String parameter can carry any meaningful 8-BIT ASCII
character string along with the message. Length of the INFO String
parameter is from 0 to 255 characters. No procedures are presently
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
debugging purposes.
The Affected DPC is provisionally a three-octet parameter to allow 14-,
16- and 24-bit binary formatted SS7 Point Codes.
2.3.2.2 Destination Available (DAVA)
The DAVA message is sent from the SG to all concerned ASPs to indicate
that the SG has determined that an SS7 destination is now reachable.
The ASP MTP3-User protocol is expected to resume traffic to the
affected destination through the SG initiating the DUNA.
The DAVA message contains the following parameters:
Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code
Info String (Optional)
The format and description of DAVA Message parameters is the same as
for the DUNA message (See Section 2.3.2.1.)
2.3.2.3 Destination State Audit (DAUD)
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
DAUD may be sent periodically after the ASP has received a DUNA, until
a DAVA is received. The DAUD can also be sent when an ASP recovers
from isolation from the SG.
The DAUD message contains the following parameters:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 20]
Internet Draft MTP3-User Adaptation Layer Feb 2000
Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code
Info String (Optional)
The format and description of DAUD Message parameters is the same as
for the DUNA message (See Section 2.3.2.1.)
2.3.2.4 SS7 Network Congestion (SCON)
The SCON message can be sent from the SG to all concerned ASPs to
indicate that the congestion level in the SS7 network to a specified
destination has changed.
The SCON message contains the following parameters:
Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code
Info String (Optional)
Congestion Level (Optional)
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cong. Level | Affected DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 21]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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 the optional Congestion Level parameter are shown
in the following table.
Value Description
00 No Congestion or Undefined
01 Congestion Level 1
02 Congestion Level 2
03 Congestion Level 3
The congestion levels are as defined in the national congestion method
in the ITU MTP recommendation [14] or in the ANSI MTP standard [15].
For MTP versions/variants without congestion levels, for example the
ITU international method, the parameter is always Undefined.
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
MTP3-User User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable.
The DUPU message contains the following parameters:
Protocol Identifier (Optional)
Network Appearance (Optional)
Affected Destination Point Code
Info String (Optional)
Reason
The format for DUPU Message parameters is as follows:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 22]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Appearance* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | Affected DPC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0xx) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Define Value Description
UPU-Unknown 01 MTP User Part Unavailable, No Reason Given
UPU-Unequipped 02 MTP User Part Unavailable, Unequipped
UPU-Inaccessible 03 MTP User Part Unavailable, Inaccessible
2.3.3 Application Server Process Maintenance (ASPM) Messages
2.3.3.1 ASP Up (ASPUP)
The ASP UP (ASPUP) message is used to indicate to a remote M3UA peer
that the Adaptation layer is ready to receive traffic or maintenance
messages.
The ASPUP message contains the following parameters:
Adaptation Layer Identifer (optional)
Protocol Identifier (optional)
INFO String (optional)
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 23]
Internet Draft MTP3-User Adaptation Layer Feb 2000
The format for ASPUP 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 (0x2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Layer Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x3) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Identifier* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Protocol Identifier and Info
String parameters is the same as for the DUNA message (See Section
2.3.2.1.)
The optional Adaptation Layer Identifier (ALI) is a string that
identifies the adaptation layer. This string must be set to "M3UA"
which results in a length of 4. The ALI would normally only be used in
the initial ASP Up message across a new SCTP association to ensure both
peers are assuming the same adaptation layer protocol.
Note: Strings are padded to 32-bit boundaries. The length field
indicates the end of the string.
2.3.3.2 ASP Down (ASPDN)
The ASP Down (ASPDN) message is used to indicate to a remote M3UA peer
that the adaptation layer is not ready to receive traffic or
maintenance messages.
The ASPDN message contains the following parameters:
Reason
INFO String (Optional)
The format for the ASPDN message parameters is as follows:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 24]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format and description of the optional Info String parameter is the
same as for the DUNA message (See Section 2.3.2.1.)
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)
The ASPAC message is sent by an ASP to indicate to an SG that it is
Active and ready to be used.
The ASPAC message contains the following parameters:
Routing Context (Optional)
INFO String (Optional)
The format for the ASPAC message 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Context* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| INFO String* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 25]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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)
The ASPIA message is sent by an ASP to indicate to an SG that it is no
longer an active ASP to be used from within a list of ASPs. The SG
will respond with an ASPIA message and either discard incoming messages
or buffer for a timed period and then discard.
The contains the following parameters:
Routing Context (Optional)
INFO String (Optional)
The format for the ASPIA message parameters is as follows:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 26]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.1 Error (ERR)
The ERR message is sent when an invalid value is found in an incoming
message.
The ERR message contains the following parameters:
Error Code
The format for the ERR message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Code can be one of the following values:
Invalid Version 0x1
Invalid Network Appearance 0x2
Invalid SCN Version 0x3
Invalid Adaptation Layer Identifier 0x4
Invalid Stream Identifier 0x5
Invalid Message Type 0x6
3.0 Procedures
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 27]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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
peer M3UA layers. This section describes the M3UA procedures in
response to these events.
3.1 Procedures to support the services of the M3UA layer
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.
3.1.1 Receipt of Local primitives
On receiving an MTP-Transfer primitive from an upper layer, or the
nodal inter-working function at an SG, the M3UA layer will send a
corresponding Data message (see Section 2) to its M3UA peer. The M3UA
layer must fill in various fields of the common and specific headers
correctly.
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.
In addition, the message needs to be sent on the appropriate SCTP
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.1 Layer Management primitives procedures
On receiving these primitives from the local layer management, the M3UA
layer will send the corresponding management message (Error) to its
peer. The M3UA layer must fill in the various fields of the common and
specific headers correctly.
3.2.2 Receipt of Peer Management messages
Upon receipt of Management messages, the M3UA layer must invoke the
corresponding Layer Management primitive indications (M-ERROR ind.) to
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 28]
Internet Draft MTP3-User Adaptation Layer Feb 2000
the local layer management.
3.3 Procedures to support the M3UA services in Section 1.4.4
These procedures support the M3UA management of SCTP Associations and
ASP Paths between SGs and ASPs
3.3.1 State Maintenance
The M3UA layer on the SG needs to maintain the state of each ASP as
input to the SGs address translation and mapping function.
3.3.1.1 ASP States
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:
* Reception of messages from peer M3UA layer
* Reception of indications from the SCTP layer
The ASP state transition diagram is shown in Figure 4. The possible
states of an ASP are:
ASP-DOWN: The Application Server Process is unavailable. Initially all
ASPs will be in this state.
ASP-UP: The Application Server Process is available but application
traffic is stopped.
ASP-ACTIVE: The Application Server Process is available and application
traffic is active (for a particular Routing Context or set of Routing
Contexts).
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 29]
Internet Draft MTP3-User Adaptation Layer Feb 2000
Figure 4: ASP State Transition Diagram
+-------------+
|-------->| |
| | ASP-ACTIVE |
| +-------------+
| ^ |
| ASP | | ASP
| Active | | Inactive
| | v
| +-------------+
ASP Down / | | |
SCTP CDI | | ASP-UP |
| +-------------+
| ^ |
| ASP | | ASP Down /
| Up | | SCTP CDI
| | v
| +-------------+
| | |
|-------->| |
| ASP-DOWN |
+-------------+
SCTP CDI: The local SCTP layer's Communication Down Indication to the
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
layer.
3.3.1.2 AS States
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:
* ASP state transitions
* Recovery timer triggers
The possible states of an AS are:
AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS. Initially
the AS will be in this state.
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
none in the ASP-Active state).
AS-ACTIVE: The Application Server is available and application traffic
is active. This state implies that one ASP is in the ASP-ACTIVE state.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 30]
Internet Draft MTP3-User Adaptation Layer Feb 2000
AS-PENDING: An active ASP has transitioned from active to inactive or
down and it was the last remaining active ASP in the AS. A recovery
timer T(r) will be started and all incoming SCN messages will be queued
by the SG. If an ASP becomes active before T(r) expires, the AS will
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
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-DOWN state.
Figure 5: AS State Transition Diagram
+----------+ one ASP trans ACTIVE +-------------+
| |------------------------>| |
| AS-UP | | AS-ACTIVE |
| | | |
| |< -| |
+----------+ \ / +-------------+
^ | \ Tr Trigger / ^ |
| | \ at least one / | |
| | \ ASP in UP / | |
| | \ / | |
| | \ / | |
| | \ /---/ | |
one ASP | | \ / one ASP | | ACTIVE ASP
trans | | all ASP \-/----\ trans to | | trans to UP or
to UP | | trans to / \ ACTIVE | | DOWN
| | DOWN / \ | |
| | / \ | |
| | / \ | |
| | /all ASP \ | |
| v / trans to \ | v
+----------+ / DOWN \ +-------------+
| |<--/ -| |
| AS-DOWN | | AS-PENDING |
| | | (queueing) |
| |<------------------------| |
+----------+ Tr Trigger no ASP +-------------+
in UP state or
Tr = Recovery Timer
3.3.2 ASPM procedures for primitives
Before the establishment of an SCTP association the ASP state at both
the SG and ASP is assumed to be "Down".
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 31]
Internet Draft MTP3-User Adaptation Layer Feb 2000
When the M3UA layer receives an M-SCTP ESTABLISH request primitive from
the Layer Management, the M3UA layer will try to establish an SCTP
association with the remote M3UA peer. Upon reception of an eventual
SCTP-Communication Up confirm primitive from the SCTP, the M3UA layer
will invoke the primitive M-SCTP ESTABLISH confirm to the Layer
Management.
Alternatively, if the remote M3UA-peer establishes the SCTP association
first, the M3UA layer will receive an SCTP Communication Up indication
primitive from the SCTP. The M3UA layer will then invoke the primitive
M-SCTP ESTABLISH indication to the Layer Management.
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
Management using the primitive M-ASP STATUS. Based on the status of
the local M3UA-User, the local ASP M3UA Application Server Process
Maintenance (ASPM) function will initiate the ASPM procedures, using
the ASP-Up/-Down/-Active/-Inactive messages to convey the ASP-state to
the SG - see Section 3.3.3.
If the M3UA layer subsequently receives an SCTP-Communication Down
indication from the underlying SCTP layer, it will inform the Layer
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.
At an ASP, the Layer Management may try to reestablish the SCTP
association using M-SCTP ESTABLISH request primitive.
3.3.3 ASPM procedures for peer-to-peer messages
3.3.3.1 ASP-Up
[Ed Note: text required to specify what SG does before first ASP-Up
received]
The SG will mark the path as up if an explicit ASP UP (ASPUP) message
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 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.
The ASP will send ASPUP messages every 2 seconds until the path comes
up (i.e. until it receives a ASPUP message from the SG for that path).
The ASP may decide to reduce the frequency (say to every 5 seconds) if
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 32]
Internet Draft MTP3-User Adaptation Layer Feb 2000
the an acknowledgement is not received after a few tries.
The ASP should wait for the ASPUP message from the SG before
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
The SG will mark the ASP as down and send an ASPDN message to the ASP
if one of the following events occur:
- an ASP Down(ASPDN) message is received from the ASP,
- 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
a ASPDN) message is received from the ASP.
The ASP 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 (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
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
sender which version the receiving node supports.
This is useful when protocol version upgrades are being performed. A
node with the newer version should support the older versions used on
other nodes it is communicating with.
The version field in the Error message header associated will indicate
the version supported by the node.
3.3.3.4 ASP Active
When an ASP Active (ASPAC) message is received, the SG will start
routing to that ASP. Reception of a ASPAC message overrides any
previous ASPAC messages and results in the ASP associated with the
ASPAC message to become the newly active ASP.
3.3.3.5 ASP Inactive
When a ASPIA message is received, message transmission to that ASP
ceases. The SG will either discard all incoming messages or start
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
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 33]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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.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
between an SG and an ASP is shown below. It is assumed that an SCTP
association is already set-up.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 34]
Internet Draft MTP3-User Adaptation Layer Feb 2000
SG ASP1
|
|<---------ASP Up---------|
|-------ASP Up (Ack)----->|
| |
|<-------ASP Active-------|
|----ASP Active (Ack)---->|
| |
4.1.2 Two ASPs in Application Server ("1+1" sparing)
Establishment of Associations between an SG and Multiple ASPs in the
same Application Server (Primary/Back-up case). In this case ASP1 will
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.
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|-------ASP Up (Ack)----->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up (Ack)---------->|
| | |
...
| | |
|<-------ASP Active-------| |
|----ASP Active (Ack)---->| |
| | |
4.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing
case)
SG ASP1 ASP2
| | |
|<---------ASP Up---------| |
|-------ASP Up (Ack)----->| |
| | |
|<------------------------------ASP Up---------------|
|-----------------------------ASP Up (Ack)---------->|
| | |
...
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 35]
Internet Draft MTP3-User Adaptation Layer Feb 2000
| | |
|<--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)------>|
| |
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 36]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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:
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 37]
Internet Draft MTP3-User Adaptation Layer Feb 2000
? 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.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 38]
Internet Draft MTP3-User Adaptation Layer Feb 2000
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.
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 39]
Internet Draft MTP3-User Adaptation Layer Feb 2000
SG ASP
| |
--MTP-STATUS ind.-->|------DUPU Message ----->|--MTP-STATUS ind.-->
| |
5.0 Security
M3UA relies upon IPSEC to ensure confidentiality of user payload.
Consult [RFC 2401, "Security Architecture for the Internet Protocol",
S. Kent, R. Atkinson, November 1998] for more information on
configuring IPSEC services.
6.0 Acknowledgements
The authors would like to thank John Loughney, Neil Olson, Norm Glaude,
and Michael Tuexen for their valuable comments and suggestions.
7.0 References
[1] RFC 2719, "Framework Architecture for Signaling Transport"
[2] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7)
- ISDN User Part (ISUP)'
[3] ANSI T1.113 - 'Signaling System Number 7 - ISDN User Part
[4] ETSI ETS 300 356-1 "Integrated Services Digital Network (ISDN);
Signalling System No.7; ISDN User Part (ISUP) version 2 for the
international interface; Part 1: Basic services"
[5] ITU-T Recommendations Q.711-714, 'Signalling System No. 7 (SS7) -
Signalling Connection Control Part (SCCP)'
[6] ANSI T1.112 'Signaling System Number 7 - Signaling Connection
Control Part'
[7] ETSI ETS 300 009-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Signalling Connection Control Part (SCCP)
(connectionless and connection-oriented class 2) to support
international interconnection; Part 1: Protocol specification"
[8] ITU-T Recommendations Q.720, 'Telephone User Part'
[9] ITU-T Recommendation Q.771-775 'Signalling System No. 7 SS7) -
Transaction Capabilities (TCAP)
[10] ANSI T1.114 'Signaling System Number 7 - Transaction Capabilities
Application Part'
Sidebottom draft-ietf-sigtran-m3ua-01.txt [Page 40]
Internet Draft MTP3-User Adaptation Layer Feb 2000
[11] ETSI ETS 300 287-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Transaction Capabilities (TC) version 2;
Part 1: Protocol specification"
[12] RANAP
[13] Simple Control Transport Protocol <draft-ietf-sigtran-sctp-
05.txt>, Dec. 1999, Work in Progress
[14] ITU-T Recommendations Q.701-Q.705, 'Signalling System No. 7 (SS7)
- Message Transfer Part (MTP)'
[15] ANSI T1.111 'Signalling System Number 7 - Message Transfer Part'
[16] ETSI ETS 300 008-1, "Integrated Services Digital Network (ISDN);
Signalling System No.7; Message Transfer Part (MTP) to support
international interconnection; Part 1: Protocol specification"
[17] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - Service
Specific Coordination Function for signaling at the Network Node
Interface (SSCF at NNI)
[18] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - Service
Specific Connection Oriented Protocol (SSCOP)
[19] MTP2-User Adaptation Layer <draft-ietf-sigtran-m2ua-01.txt>, Nov.
1999, Work in Progress
[20] ITU-T Recommendation Q.2210 'B-ISDN MTP'
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
Telcordia Technologies
MCC 1J211R
445 South Street
Morristown, NJ, USA 07960
EMail: kalla@research.telcordia.com
This draft expires July 2000.
| ||||||||||||||||
| Last modified: Thu, 13 Nov 2014 20:43:08 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||